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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
  Ticket             | 13231
  Updated By         | arjen+horde at de-korte.org
  Summary            | Hashtable session handler doesn't unlock on session
                     | close
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


arjen+horde at de-korte.org (2014-05-28 12:50) wrote:

> 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.