And really there are quite a few classes at phpclasses.org that might be helpful to you. See: http://www.phpclasses.org/search.html?words=mysql+session and http://www.phpclasses.org/browse/package/1518.html for the specific class Pedro mentions.

One way to deal with locking sessions is to use db backed sessions and roll your own locking mechanism. You need to use transactions, and in order to handle the occasional high-latency or interrupted request, you’re going to want to set up your locks to expire if another request has been waiting a while. To balance fast response with avoiding having high traffic situations result in an exponential growth of db access, you’ll want to have the sleep period between polls to see if the lock is available grow rapidly and geometrically/exponentially. It’s also wise to have available read-only sessions that don’t acquire a lock and only use locking when it is necessary, to minimize overhead. A request should be able to decide it needs a write log part way through it’s execution and ask for it.

Some databases already have a locking mechanisms that makes building this kind of setup easier.

@Andy, Keith, and Taylor: the article comments suggest that PHP already ensures only one thread has access to $_SESSION at a time.

That comment is wrong. If you overload the session handler, there is no locking function, which would be necessary in order to fully lock sessions when you have multiple web servers. This would suggest that, while it might do locking if storing sessions in files, no locking can be done when you write your own session handler (like using mysql to store session data, for example).

The article comments suggest that PHP already ensures only one thread has access to $_SESSION at a time. The first thread that session_start()s gets exclusive access until it finishes or calls session_write_close(). While locked, other threads hault execution at the point they call session_start(). When the lock is released, execution continues in the next script. I can’t find this in the PHP manual, but it should be trivial to verify.

Nope, it doesn’t. Each request has a seperate copy of the session, which is loaded on session_start() and saved on session_write_close(). No locking occurs; instead, the previous copy of the session is overwritten.

This behaviour is usually sufficient when you’re dealing with people browsing a site. The time between two requests in the same session is almost always great enough that this race condition is never an issue. However, when you’re dealing with a piece of code making simultaneous overlapping requests, the crap hits the fan.

It also has to be said that if PHP did use the highly pessimistic locking scheme you described, the uses of sessions could cause it to run like treacle, with each request tied to a certain session being serialised. You’d run into problems with memory consumption, tied up file handles, request timeouts, &c. It’s not a pleasant scenario.

I’d think the easiest way to avoid the situation described is to add to your AJAX class the ability to keep track of requests that write to certain session vars. The client app can then decide if it should allow a 2nd write request to be sent before receiving the response from the 1st.

Safer might be to batch and/or serialise any such requests on the client. Wrap the XHR object in another object that maintains a queue of all pending requests and a list of any sent and pending completion (for callback). When the XHR object is free, send any pending requests together in one batch. It takes a little extra processing on each side to build and seperate each of the logical requests and responses, but it’s worth it.

リンク: Ajaxian ? Troubles with Asynchronous Ajax Requests and PHP Sessions Ajaxian�サイト�掲載�

I’d think the easiest way to avoid the situation described is to add to your AJAX class the ability to keep track of requests that write to certain session vars. The client app can then decide if it should allow a 2nd write request to be sent before receiving the response from the 1st.

The real problem is that PHP doesn’t have any locking primitives.

Why in the hell would you want to write and read the same variable with different calls?

You do, each time you access any variables shared across a set of processes or threads. Few webservers process requests serially. PHP’s lack of support for access control to shared datastructures (such as $_SESSION) is a definite flaw in the langauge, cf. Java’s synchronized keyword or ColdFusion’s <CFLOCK> tag, both of which allow concurrent threads to access shared state without stepping on each other’s toes.

You (and Tom, especially Tom for that ill-informed remark) should read up on concurrency. Web applications tend to be highly concurrent, and nobody developing them should be without, at the very least, a solid grounding in concurrency.

And as Andy noted, this is a problem with most dynamic langauges at the moment, not just PHP. Very few provide proper support for taking read-only and excusive locks on shared state.

The main issue here is that there are no built-in concurrency controls across multiple requests in popular server-side programming/scripting languages, so you’d have to roll your own. Things like atomic increment in memcached or get_lock/release_lock in mysql can help. One may have to forgo using PHP’s session handling to get finer grained locks, which means rolling your own session variable storage engine also.