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

noreply at bugs.horde.org noreply at bugs.horde.org
Thu May 29 00:17:11 UTC 2014


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

Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
  Ticket             | 13231
  Updated By         | Michael Slusarz <slusarz at horde.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             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-05-28 18:17) wrote:

>>> You rather mean *inside* Horde_Memcache#lock()?
>>
>> Yes. When six processes attempt to lock the session data more or less
>> at the same time, at most one will succeed in doing so, while the
>> others sleep for 100 ms. If after that the session data is still
>> locked (or locked again), this repeats until all have completed.
>
> Well, that's how locking works. The question is, why is unlocking  
> not working during the session.

It *is* working.  I'm guessing the issue lies more with our current  
polling choice - 0.1 seconds.

You can't compare memcache with other sessionhandlers re: locking,  
since other sessionhandlers (i.e. file, sql) have built-in lock  
mechanisms (flock, SQL row locking) that are going to be  
instantaneous.  For memcache, our only solution is a poll-based  
solution.

Lowering the poll delay is not a viable option.  At 10 polls/second  
(per request), that is already quite a bit of network/protocol overhead.

Maybe it would be better to implement a logarithmically increasing  
delay mechanism.  Or for true performance, a hybrid flock/memcache  
system.

Moral of the story: as I've tried to tell some of my clients, memcache  
is NOT the ideal session storage backend.  Memcache might be useful if  
you are running a pool of PHP servers, but on a single server setup  
there remains zero reason to use anything other than file-based  
sessions.





More information about the bugs mailing list