Acquiring a document lock fails when the lock is removed concurrently

Symptom

A request to lock a page can fail, leaving the page unlocked, when the same page is being unlocked at the same time. Nobody is told about it: the lock request answers with an error that the browser ignores, so the user believes the page is locked while other users can start editing it without being warned.

This happens, for instance, when navigating between administration sections: leaving a section unlocks XWiki.XWikiPreferences while the section being opened locks it again, in two concurrent requests.

WARN  c.x.x.w.XWikiAction - Uncaught exception [.../bin/lock/XWiki/XWikiPreferences?ajax=1&action=admin]
com.xpn.xwiki.XWikiException: Error number 13007 in 3: Exception while loading lock
    at XWikiHibernateStore.loadLock
    at XWikiDocument.getLock
    at LockAction.action(LockAction.java:56)
Caused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.xpn.xwiki.doc.XWikiLock#...]

Cause

XWikiHibernateStore#loadLock first checks that a lock row exists for the document, then loads it with a second statement. When the transaction isolation level is READ COMMITTED, each statement sees the latest committed data, so if an unlock commits between the two statements the load fails.

READ COMMITTED has always been the default isolation level of PostgreSQL and Oracle. Since XWIKI-24997 it is also the default for MySQL and MariaDB, which made the failure visible there.

Reproduction

On MySQL (default configuration), a stress test that replays concurrently the requests sent when switching between two administration sections hit this 3 times in 300 rounds, always on the page that is unlocked and locked at the same time.