On Sep 26, 2010, at 1:10 AM, ROZE Samuel wrote:

> Hello,
> 
> I'm working with sessions in my PHP applications. My pages can take long time 
> to be executed (~500ms) and I've simultaneous requests for the same session 
> (Ajax requests). My problem is that I close sessions at the end of my PHP 
> script, so my sessions files are locked for half a second. So, simultaneous 
> requests (for the same session) can't be executed... simultaneously!
> 
> My question is if I use memcached to store sessions, will my sessions be 
> locked or can I access to them in the same time? If there aren't it should 
> solve my problem.
> 
> A second question is performances: is memcached sessions faster the PHP 
> default sessions? I think yes because it doesn't make disk I/O..?
> 

No, the default memcache session handler has no locking.

But that presents you with a new problem of a race condition.

This is why you shouldn't keep any actual data in sessions:

R1:[initial request start, session is read and has X=1]
A1:[ajax request 1 reads session, X=1]
A2:[user clicks "add 1 to my shopping cart", X = X+1 = 2]
A2:[displays shopping cart with X == 2]
A2:[faster than A1, session over, write session with X = 2]
A1:[session over, write session with X = 1]

DOH!

There has to be some kind of locking on data between read/write to maintain 
consistency.

One way you can get around this is by *not* using the session for mutable data, 
and just using it to store a key to the data in your backend, and then only 
writing when you must.

The above becomes

R1:[initial request start, session is read and has shopping cart SID=1]
A1:[ajax request 1 reads session, SID=1]
A2:[user clicks "add 1 to my shopping cart", UPDATE carts SET X = X + 1 WHERE 
SID = 1]
A2:[displays shopping cart with X == 2]
A2:[faster than A1, session over, write session with SID=1]
A1:[session over, write session with SID=1]

Also, the memcache session handler can be dangerous in that it might choose to 
delete your session before expiration if memcached fills up, so be aware of 
this.

Good luck!


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to