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	>>> Well, that's how locking works. The question is, why is unlocking not >>> working during the session. >> >> I don't think I fully understand this. Should the lock be released >> before or after processing the calendar resource? > > Before: > https://github.com/horde/horde/blob/master/kronolith/lib/Ajax/Application/Handler.php#L113 > >>> Horde_SessionHandler_Storage_Hashtable::close() should be called from >>> PHP, and that should delete() the key from memcache again in >>> Horde_Memcache::unlock(). >> >> That is what happens, since all 15 listEvents are serviced >> eventually. The problem I see (but this may be by design, I don't >> know) is that in the implementation of the current Hashtable >> sessionhandler, the lock seems to be removed only when the listEvent >> completed. Which means that effectively, only one listEvent is >> handled at the same time, while other listEvent processes are waiting >> for the lock to release. >> >> I expected similar behavior as for the Sql or builtin >> sessionhandlers, where all listEvent processes are running >> concurrently and don't seem to have to wait for locks to be released. >> Maybe these don't lock the session data and is that the reason why >> they are a lot faster in updating the calendar view. > > No, sessions are always locked. And this doesn't have anything to do > with Kronolith. Closing a session obviously just doesn't work in the > Memcache implementation. For whatever reason.
Attachment
Watch this ticket

Saved Queries