Given that most session storages don't lock, I'd prefer using a temporary file instead to write atomically. Wdyt?

Given that most session storages don't lock, I'd prefer using a temporary file instead to write atomically. Wdyt?

I'm not sure to understand. The file have to be kept and reopened between each request..

If we don't care about atomicity, then, file_put_content with LOCK_EX + remove unlink should do the trick

See #39816

#39816 is a good shot at avoiding "hard" errors that can occur when the MockFileSession is used by several processes/requests concurrently: Avoid a warning when the session file on disk has been unlink()ed by another process, and avoid garbled data in the file when several processes try to write session data simultaneously and/or one process reads it while the other tries to write.

The more general issue of session locking to avoid soft/logic errors would require that once one process starts a session (= reads session data from disk, memory, whereever), that process would need to hold a write lock on the session data. All other processes trying to read the same session data would have to wait until the first process finished and wrote back the session. That's the way PHP's session_start() behaves. This is not a lock while session data is being read or written, but a lock held throughout a good part of the request's duration (!).

For a session implementation like the one in Symfony, that would probably be a bigger behavioral change, and it should work the same way for all kinds of session storage for consistency. I am not sure this is feasible.

Side note: IIRC, in the context where I reported #39167, we also used the Remember me feature from security, which (if memory serves me correctly) writes updated session data on every request and changes some internal token. Because requests may be interleaved, some of them read old session data or wrote back outdated tokens, eventually losing the "logged in"-state. This is the second, "logic" issue. #39816 is against the race condition when two processes work on the session file at the same time.

I'm not sure we need such advanced behavior in Symfony. Not all adapter provides locking.

People can use native php sessions if they want lockig.