Tickets :: Comment on [#13231] Hashtable session handler doesn't unlock on session close

Search Results: 435 of 574 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ .___. .. . [ __[__)[__ \|\/\|\| \| [_./\| [___\| \|\|__\|
Comment	> I'm using Firefox 29 which, like most browsers, will allow a limited > number of simultaneous connections to the same server (in this > version, six). When listing the events for my calendar, it will fire > off 15 processes, each handling a single calendar resource. It will > run 6 processes in parallel, so far so good. > > Now the hairy part. With the builtin-, File- and Sql-sessionhandlers > these 6 processes will run concurrently and all 15 are handled in > about half a second. Very acceptable performance and switching > between month views is pretty much instantaneous. > > With the Hashtable sessionhandler things are quite different. Each > process will attempt to get a lock on the (same) session data that is > stored during session_start(). Obviously, only one of 6 listEvents > calls succeeds to get the lock (so the locking mechanism works), the > others have to wait until the session is closed again. So > effectively, the listEvents calls are handled sequentially for the > Hashtable sessionhandler. This means that switching between month > views takes well over two seconds. Not impressive at all. > > As far as I can see, the listEvents call from the Calendar will not > have to change the session data. In this case, it might be useful to > open the session data readonly, in which case no locking is used (nor > needed), so multiple processes can use the same data concurrently.
Attachment
Watch this ticket

Saved Queries