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

Moodle's documented session handling supports several backends, including the default database handler and optional Redis and Memcached handlers configured under Site administration > Server > Session handling. The documentation also describes an exclusive per-session lock that Moodle takes while serving a request, intended to prevent race conditions when one session is active in more than one request.

The goal is to decide whether moving session storage from the database to Redis changes the latency profile of pages that issue several parallel requests — for example, AJAX blocks or web-service calls — for the same logged-in user. The uncertainty is whether the Redis handler implements the same lock semantics as the database handler, or whether lock wait behavior, timeouts, and failure modes differ between handlers and across recent Moodle releases (4.x and 5.x).

Specific questions:

• Does the Redis session handler acquire the same exclusive session lock, so concurrent requests from one session still serialize?
• Are lock wait and timeout behaviors documented consistently for the database, Redis, and Memcached handlers in currently supported Moodle versions?
• What should be verified in a staging environment before standardizing on Redis sessions for pages with high per-user concurrency?