When the session lock is getting hammered for whatever bad reasons, it's generally a poor user experience to sit and wait around for the session to unlock. The root causes are many and being tackled elsewhere ie MDL-58018, MDL-64449.

But if the session is locked, and the request is idempotent, ie a simple GET request which wouldn't change any critical state on the server, then it would be a much better UX to just abort the request and say 'hey you are doing things in another tab or the site is super busy' rather than waiting around forever.

This also happens when thing have gone south during massive scaling events, which makes things worse as all these requests queue up and sit there waiting and polling the session store. It is also worse because if a user reloads the page and / or aborts the request, the front ends can't detect this and kill the process until after they've got a session lock, and then do stuff and then try to write to the socket, which will then fail and abort the process. It's way too late in the process.

So I'm proposing to have two session lock timeouts, one for basic idempotent / reads which could be configured to something very short like 10-20 seconds., and one for things which change state which could be a couple minutes so the user is less likely to lose data.

The heuristics I have in mind are:

• must be GET
• must not have a sesskey in the url
• must not have NO_OUTPUT_BUFFERING set (these long running ones should unlock the session anyway)

Also I am thinking of refactoring as part of this and introducing the two generic timeouts as

$CFG->session_lock_timeout

$CFG->session_lock_idempotent_timeout

and making all the core session stores honor these new settings as well as their respective existing store specific settings.