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

Search Results: 130 of 151 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .__.. ,.__..___. . \| \| \./ \| \|[__ \|_/ \|__\ \| \|__\[___\| \
Comment	>>>> 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.
Attachment
Watch this ticket

Saved Queries