Symfony Session lock serialization for concurrent same-session requests

Direct answer

Under Symfony's default configuration, the session component delegates to PHP's native session handling. With the default file-based handler, the exclusive lock is acquired at session_start() (which Symfony triggers lazily when the session is first used) and is held until PHP's request shutdown, after the response has been sent — unless you explicitly close the session earlier. There is no automatic mid-request release; the lock lifetime is effectively the request lifetime.

An explicit early release via session_write_close() (exposed in Symfony through $session->save()) is not a neutral operation. Once the session is closed, the storage handle is released and any subsequent writes to $_SESSION in the same request are silently discarded — they modify the in-memory array but are never persisted. No error is raised. So early release is only safe when you can guarantee the remaining work is strictly read-only with respect to the session.

How the storage handler changes observable serialization

Changing the handler changes where the lock lives and its cost, not whether lock lifetime matters:

• Files (default): the lock is an flock() on the session file, held by the PHP process for the request duration. Concurrent same-session requests queue behind it. Note that in PHP-FPM, different workers are different processes, but the file lock still serializes them correctly.
• Redis: Symfony's RedisSessionHandler implements its own lock (a spin-lock on a Redis key with a TTL). Concurrent same-session requests still serialize, but the lock now has an independent lifetime (lock TTL) that you must size correctly, or a long request can outlive its lock.
• Memcached: the standard handler does not provide durable locking semantics comparable to the file handler; concurrent same-session writes can race. If you move to Memcached for speed, you may need application-level coordination for session writes.

Recommended pattern

For long-running, read-only endpoints (polling, progress checks, streaming), close the session as early as possible, before the expensive work:

public function poll(SessionInterface $session): JsonResponse
{
    $data = $session->get('progress'); // read what you need first
    $session->save();                  // releases the lock (session_write_close)
    // ... slow read-only work; do NOT touch $session again
    return new JsonResponse($data);
}

The critical discipline: after $session->save(), treat the session as gone. Any flash messages, attribute writes, or authentication state changes after that point will appear to succeed and then vanish.

Verifying the behavior yourself

Because lock internals vary across Symfony 5.x/6.x and PHP versions, confirm on your stack:

1. Create a controller that sleeps 5 seconds after starting the session, and another that timestamps how long session_start() blocks. Fire both concurrently with the same session cookie (e.g., two curl requests sharing a cookie jar).
2. Repeat with $session->save() before the sleep in the first controller — the second request's blocking should disappear.
3. For Redis, watch MONITOR or inspect lock keys during a slow request to observe lock acquisition and TTL.

One caveat worth flagging: the exact lock TTL defaults and whether reads bypass the lock differ by handler and Symfony version, so treat the Redis/Memcached rows above as design guidance and verify against your installed version before relying on them in production.