[Tickets #5369] Re: horde not cleaning up memcache session locks properly

[bugs at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/?id=5369
-----------------------------------------------------------------------
 Ticket             | 5369
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | horde not cleaning up memcache session locks properly
 Queue              | Horde Base
 Version            | 3.1.4
 Type               | Bug
-State              | Unconfirmed
+State              | Feedback
 Priority           | 1. Low
 Owners             | 
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2007-05-17 14:03) wrote:

In terms of the lock, what if you put the unlink lines (like this one) in
the _unlockSession function?

        @unlink($this->_params['lock_dir'] . '/lock_' . $id); 

(_unlockSession is called on session_close, but the unlink isn't. In every
other case that _unlockSession is called, we do the unlink).

By the way, the "unknown reason" that the lock is created in the first
place is that guests have sessions too. But there isn't a real reason to
destroy the guest sessions, and while the memcache data is cleaned up
(it's only the lock file that isn't cleaned up - not the actual session),
we don't know the session ids that expire so in gc() we can't go cleaning
up locks. What I'm proposing is that we don't need the lock file after
close() is called; it'll be recreated again when the session is opened,
and that might be a performance hit.

(though I doubt it - apparently I made that change, and I'm not sure why:
http://cvs.horde.org/diff.php?sa=1&r1=1.12&r2=1.13&f=framework%2FSessionHandler%2FSessionHandler%2FAttic%2Fmemcached.php)

The other behavior you're seeing looks like an artifact of how PHP handles
session_destroy() - but I'm really not sure.