php sessions and memcache

[Richard Thomas]

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


Andy wrote:
> 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 
>>resources updating
>>
>>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
> nevermind.
> 
> 
>>Andy wrote:
>>
>>>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
> 
> http://ajaxian.com/archives/troubles-with-asynchronous-ajax-requests-and-php-sessions
> 
> which transcends the storage backend used.
>