Bug #44203

Session implementation is still racy

Added by Helmut Hummel almost 9 years ago. Updated about 8 years ago.

Needs Feedback
Should have
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Has patch:


Disclaimer: I did not test anything, but only making assumptions by reading the code. Just close this ticket if I'm mistaken.

Just want to make you aware that the session handling introduced in #43376 is racy.
The old session handling relied on the basic PHP session implementation. This is protected against concurrent requests.
Consider this simple script:


if (!empty($_GET['test'])) $_SESSION['test'] ++;

if (!empty($_GET['sleep'])) sleep(15);


When you call it first with http://localhost/session.php?test=1&sleep=1 and in a second tab with http://localhost/session.php?test=1 The second request waits on session_start() until the first request is completed. This ensures consistent session data over multiple concurrent requests, which are quite common especially when using asynchronous Ajax calls.

PHP obviously does locking for sessions, the new session implementation of Flow does not (or the locking code is somewhere well hidden ;)

Maybe that's not a big deal (the session implementation of TYPO3 CMS is also racy as hell and still does it's job most of the time), but I wanted to let you know that this could cause troubles especially in Neos...

Related issues

Related to TYPO3.Flow - Bug #53262: FileBakend have some race conditionNewDominique Feyer2013-11-01


Updated by Karsten Dambekalns almost 9 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Robert Lemke

Updated by Karsten Dambekalns almost 9 years ago

  • Project changed from TYPO3 Flow Base Distribution to TYPO3.Flow

Updated by Karsten Dambekalns almost 9 years ago

  • Category set to Session
  • Has patch set to No

Updated by Karsten Dambekalns about 8 years ago

  • Target version changed from 2.0 to 2.0.1

Also available in: Atom PDF