Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Unknown
-
Description
Problem
Importing (refreshing) an extension from the Repository application UI on extensions.xwiki.org fails almost every time on the first attempt, and succeeds when the very same import is retried immediately.
The failure is:
XWikiException 3201: Exception while saving document extensions:Extension.<Extension Name>.WebHome <- PersistenceException / GenericJDBCException: could not execute statement <- java.sql.SQLException: (conn=308488) Record has changed since last read in table 'xwikidoc' at RepositoryManager.updateExtension:980 -> saveDocument:1301 -> XWiki.saveDocument -> XWikiHibernateStore.saveXWikiDoc:770 (commit)
It started on 29 Aug 2026 - the first "Updated last version of the extension" revision interleaved with an import revision in the history of extensions:Extension.Release Notes Application.WebHome dates from that day.
Cause
Record has changed since last read is MariaDB ER_CHECKREAD (error 1020). Per the MariaDB documentation it is raised only when innodb_snapshot_isolation is ON: that variable adds write/write conflict detection to REPEATABLE READ, so an UPDATE that tries to lock a row whose current version is not in the transaction's read view is refused and the transaction is rolled back (MariaDB says to treat it like a deadlock). The variable exists since 10.6.18 / 10.11.8 / 11.4.2 and is ON by default since MariaDB 11.6.2 (MDEV-35124).
So a database upgrade, not an XWiki change, made this visible: two writers race on the same xwikidoc row during an import (the Repository app saves, at the end of the import, a clone of the extension page it took before the long Nexus work, while the extension updater listener saves the same page in between, reacting to the version pages the import just created). Before snapshot isolation that race was a silent lost update; MariaDB now refuses the write instead.
What is needed here
- Confirm the setting on the database serving extensions.xwiki.org:
SELECT @@version, @@innodb_snapshot_isolation;
Expected: MariaDB >= 11.6.2 and ON.
- Set innodb_snapshot_isolation = OFF - both globally (SET GLOBAL innodb_snapshot_isolation = OFF;) and in the server configuration file so it survives a restart. That restores the pre-11.6.2 behaviour and unblocks extension imports.
The same database serves the other xwiki.org wikis, so any long XWiki operation that ends by updating a document it read earlier is exposed to the same failure, not just the Repository app.
Note
Turning the variable off is a workaround, not the fix: it brings back the silent lost update that the setting was detecting. The real fixes are application-side and need their own issues in the XWIKI project:
- Repository application: stop saving a stale snapshot at the end of an import (re-read the extension document just before the final save, or make the import guard actually cover the paths where a version page is saved during an import).
- Platform: recognise ER_CHECKREAD / HA_ERR_RECORD_CHANGED in the Hibernate store and either retry the transaction or throw a dedicated "document concurrently modified" error, instead of wrapping it as an opaque Error number 3201.
Attachments
Issue Links
- is related to
-
XWIKI-24908 MariaDB write/write conflicts (ER_CHECKREAD) when saving a document are reported as an opaque Error number 3201
-
- Open
-
-
XWIKI-24907 Importing an extension in the repository may saves a stale document and overwrites the concurrent last-version update
-
- Closed
-