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

[noreply at bugs.horde.org]

BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE  
E-MAIL-ADRESSE WERDEN NICHT GELESEN.

Ticket-URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
  Ticket           | 13231
  Aktualisiert Von | Jan Schneider <jan at horde.org>
  Zusammenfassung  | Hashtable session handler doesn't unlock on session close
  Warteschlange    | Horde Framework Packages
  Version          | Git master
  Typ              | Bug
  Status           | Feedback
  Priorität        | 1. Low
  Milestone        |
  Patch            |
  Zuständige       |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2014-05-28 15:12) hat geschrieben:

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