php sessions and memcache

Richard Thomas lists at
Tue Jul 18 02:21:36 UTC 2006

The race condition comes from the locking of tables on multiple updates 
to the table at the same time.

There are a couple ways to help prevent that

1. I hash during the read and check the hash during the write, If the 
hash has not changed I only update the expire time not the whole session

2. I only update the expire time every X seconds, this way if there are 
no changes to the session and its only been a few seconds I don't waste 
resources updating

3. When I do update just the expire time I do it low priority

Andy wrote:
> On Mon, 2006-07-17 at 16:29 -0500, Richard Thomas wrote:
>> The problem is extra overhead, no matter what you do serialize and 
>> unserialize are called.
>> So on a read you have to serialize the data even though its already in a 
>> user format, on write you have to unserialize the input to your write 
>> function.
>> Thats 2 serializes called that shouldn't be needed if you could disable 
>> the sessions serializer.
>> That little overhead was enough that in my tests it wasn't really worth it.
> Agreed.  The code I currently have does call serialize on the received
> session values before sticking them in mysql -- using memcached, this
> would not be necessary and the raw value could be passed, letting the
> memcached client code do the serialization.  I essentially replaced the
> entire session handler with an object that implements the PHP5 array
> interfaces -- the PHP set_session_handler code is completely bypassed
> (except for setting the cookie).
> It was actually written to see if session updating race conditions could
> be avoided when, using Ajax, multiple interleaved code paths run
> against, and update, the same session.

More information about the memcached mailing list