For developers:
1/ run the functional DB tests under sqlsrv. Verify that no error related with "test_session_locks" happens.
2/ no need to perform the tests under other DBs, nothing has changed there (last week we introduced and tested that).

Description

On many of our hosted sites we sometimes get periods of unavailability or out of memory conditions which trace back to a single user.

Most often in these cases, the user will be performing some long-running process (e.g backup, users upload) and attempts to continue opening things from another browser tab. The new requests get backed up behind the long request waiting to grab a session lock. This can also be triggered by bug, especially infinite loops in code sections with increased time limit.

This results in stuck server processes which may not be freed for hours, and can cause out-of-memory issues if more processes are started to handle other requests.

Over time, it should be a goal to migrate these long processes out of web requests and into background processing but it would be nice to have some kind of catchall to prevent these and bugs from causing site unavailability.

The suggestion is to, where possible, place a time limit on how long Moodle will wait to acquire a session lock before giving up. While this does cause an error to the user, they do not get hung browser windows forever, and the site remains available.

Please see the linked patch for an attempt at doing this for Postgres.

For developers:
1/ create simple moodle script with sleep(1000) in it;
2/ open in one window, then open other window with normal page
3/ observer timeout behaviour and verify timeout errors

For developers:
1/ create simple moodle script with sleep(1000) in it;
2/ open in one window, then open other window with normal page
3/ observer timeout behaviour and verify timeout errors
4/ run the functional DB tests under the 5DBs (mysql, pgsql, mssql, sqlsrv and oci). Verify that no error related with "test_session_locks" happens.

Warn: it's very important to test it under sqlsrv because the fix there has been implemented in "blind-mode" and the 2 developer involved have no, right now, access to run under that DB.

For developers:
1/ create simple moodle script with sleep(1000) in it;
2/ open in one window, then open other window with normal page
3/ observer timeout behaviour and verify timeout errors
4/ run the functional DB tests under the 5DBs (mysql, pgsql, mssql, sqlsrv and oci). Verify that no error related with "test_session_locks" happens.

Warn: it's very important to test it under sqlsrv because the fix there has been implemented in "blind-mode" and the 2 developer involved have no, right now, access to run under that DB.

For developers:
1/ run the functional DB tests under sqlsrv. Verify that no error related with "test_session_locks" happens.

2/ no need to perform the tests under other DBs, nothing has changed there (last week we introduced and tested that).