Symfony Session lock serialization for concurrent same-session requests

The Symfony Session component delegates to PHP's native session handler by default. The design question is how the exclusive session lock lifetime interacts with concurrent requests that share the same session id, and where the lock release decision belongs in application code.

With the default file-based handler, the lock is held for the request duration unless released explicitly. Changing storage to Redis or Memcached changes where the lock is held and its performance characteristics, but does not remove the need to manage lock lifetime. Early release can reduce serialization for read-only work but raises uncertainty about subsequent session writes in the same request.

Under default Symfony session configuration with PHP native handling, at what point in the request lifecycle is the exclusive session lock released if no explicit close is performed? Does an explicit early release make later session modifications in the same request unsafe or silently lost? How does the choice of session storage handler affect the observable serialization of concurrent same-session requests?