From my understanding Drupal implement fast session by delaying writes. I think this may generates handy bugs with parallel requests from the same session. I can think of two places where these bugs can occurs:
* ajax parallel requests (parallel uploads for examples)
* using multiple tabs in the brwoser

I understand that the defaut session locking system from PHP may have great performance impact, session_start() locks the session file until session_write_close is called. So a parallel session (we're of course talking of the same user/same session) will have to wait.

So the first thing is to prevent lock on session_start. If the session write operations are done after each session modification you'll get a lot of IO, and you may have to handle a lot of locks & wait. If you delay session writes and do only onewrite you have only one lock & wait operation. But you may loose data, the last request end write is own version of the session and previous parallel sessions writes are lost. Note that without delaying the write to the end you may losse some datas between session, but only if you write the same keys, using different keys (attributes) on the same session SHOULD not make a loose.

From my understanding with Drupal we're on the 'last speaking' rule, with a delayed to end write. And the session content is cached in request execution environment.

So this is certainly fast with session reads, and we should not implement something impacting performances in all requests. But I'd like to have a settings:

$conf['session_use_write_locking_mechanism'] = TRUE;

Then at the first write operation performed on $_SESSION a session lock would be used (different implementation sessid_lock-like cache id in memcache, lockfile with files, etc. So if any parallel session has already set this lock the session write operation would wait until this lock is released (with maybe some race conditions in that short-time locking system). And the release would be done after the final session write.
If session writes are not used a lot in Drupal this should not impact requests which do not write anything in the session --session_start() is not locked--. But you could effectively have a more robust session support (no data loss). We may investigates how sessions are used in Drupal and avoid useless session writes (to use the caching system instead), but this would be another issue.

Comments

regilero’s picture

Nice and Clean sesion locking problems explanied here, with some hints for memcached/mysql and the lock release problems:
http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-...

pounard’s picture

Version: » 7.x-1.0-alpha1
Status: Active » Postponed

Let's be honest, 3 years without doing anything is what I definitely call "postponed".