Moodle sessions on Redis vs the database: lock behavior under concurrent requests

Short answer

Yes — Moodle's Redis session handler still enforces an exclusive per-session lock, so parallel requests from one logged-in user serialize just as they do with the database handler. Moving to Redis changes where the lock lives and how it fails, not whether it exists. The latency profile of concurrent AJAX or web-service calls is therefore unlikely to improve from reduced lock contention; any gain comes from faster reads/writes once a request actually holds the lock.

Confirmed vs. likely

Confirmed by design: Moodle's session manager takes an exclusive lock for the duration of a request and releases it at session_write_close(). The database handler implements this with a row lock; the Redis handler implements it with a lock key in Redis (a SETNX-style acquisition), released when the request ends.

Likely, but verify in your version: The Redis lock has a configurable acquisition timeout (commonly exposed as a redis.session.locking-style setting, with defaults in the tens-to-hundreds of seconds range depending on release). Unlike a database row lock — which dies with the transaction/request — a Redis lock key can outlive a crashed PHP process until its TTL expires. That is the main behavioral difference: a stalled or killed request under Redis can block the session for the full lock TTL, whereas the database lock is released by the connection closing.

Memcached: has no native locking primitive; Moodle emulates locking with a key, and the semantics are weaker. For high per-user concurrency, Memcached is the least safe choice of the three.

Documentation gap

Moodle's admin documentation describes the exclusive session lock concept clearly but is thin on per-handler lock wait/timeout behavior, and the exact setting names and defaults have shifted across 4.x releases. Treat any specific default value (including the ones above) as needs verification against your installed version — check config.php and the handler source in lib/classes/session/ rather than relying on docs.

What to verify in staging

1. Locking is actually on. Inspect config.php for the session handler class and any Redis lock settings; confirm the handler isn't running in a lockless mode.
2. Serialization still happens. Fire N concurrent requests with the same session cookie (e.g., for i in $(seq 1 8); do curl -b \"MoodleSession=...\" -s -o /dev/null -w '%{time_total}\\n' \"$URL\" & done; wait) against a slow page. Response times should stair-step, not overlap.
3. Timeout headroom. Compare the longest observed lock-hold time (slowest page render) against the configured lock wait timeout. If a slow request plus queue depth exceeds the timeout, queued requests fail with session errors instead of just waiting.
4. Crash behavior. Kill a PHP-FPM worker mid-request and confirm the orphaned Redis lock expires via TTL and the session recovers without manual intervention.
5. Logs. Watch for session lock acquisition failures in the Moodle/PHP error log during a load test that mimics your AJAX-heavy pages.

Bottom line

Redis sessions will not unlock parallel requests for the same user — that serialization is intentional and handler-independent. Adopt Redis for scalability of session storage, not for concurrency relief, and only after confirming lock timeout headroom and orphaned-lock recovery in staging.