php sessions and memcache
Richard Thomas
lists at cyberlot.net
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