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

* 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? > >> 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.
Attachment
Watch this ticket