[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