php sessions and memcache
lists at cyberlot.net
Tue Jul 18 12:16:32 UTC 2006
Its the same problem regardless
With file based backends file locking to prevent corruption, not "Two
processes fight for CPU time" as mentioned in that article.
In a normal PHP session there is a write EVERY page load.. Only 1
process can write to a file at a time so the other process gets held up
till the first process is done.
This is the same with SQL, if 2 processes try to update a table at the
same time, MySQL does table level locking so the second process has to
wait for the first process to finish and the table lock to end.
You can avoid that by
1. Reducing the amount of times your updates take IE not trying to
update all the session data when the session hasn't changed
2. Not doing any updates if there not needed.
Richard Thomas - CEO
Cyberlot Technologies Group Inc.
507.398.4124 - Voice
> On Mon, 2006-07-17 at 21:21 -0500, Richard Thomas wrote:
>>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
>>3. When I do update just the expire time I do it low priority
> Uh, at this point, I think we're talking about different things, so
>>>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.
> The race condition I'm referring to, and that I had solved for, is
> mentioned at
> which transcends the storage backend used.
More information about the memcached