This issue has been created
 
 
XWiki Platform / cid:jira-generated-image-avatar-e673a06a-29ba-4086-bb53-8b00df4266ed XWIKI-24908 Open

MariaDB write/write conflicts (ER_CHECKREAD) when saving a document are reported as an opaque Error number 3201

 
View issue   ยท   Add comment
 

Issue created

 
cid:jira-generated-image-avatar-759f5c57-f1c8-4aee-ac45-3cf85e9e40c4 Vincent Massol created this issue on 15/Sep/26 14:17
 
Summary: MariaDB write/write conflicts (ER_CHECKREAD) when saving a document are reported as an opaque Error number 3201
Issue Type: cid:jira-generated-image-avatar-e673a06a-29ba-4086-bb53-8b00df4266ed Bug
Affects Versions: 17.10.13
Assignee: Unassigned
Components: Old Core
Created: 15/Sep/26 14:17
Priority: cid:jira-generated-image-static-major-296d3094-e5ac-4f49-9879-13b2dc38821e Major
Reporter: Vincent Massol
Description:

Problem

MariaDB 11.6.2 and later enable innodb_snapshot_isolation by default (MDEV-35124; the variable exists since 10.6.18 / 10.11.8 / 11.4.2). It adds write/write conflict detection to REPEATABLE READ: an UPDATE that tries to lock a row whose current version is not in the transaction's read view is refused with ER_CHECKREAD (error 1020, "Record has changed since last read") and the transaction is rolled back. The MariaDB documentation says such an error is to be treated the same way as a deadlock, i.e. retried.

XWiki does not handle it when saving a document:

  • No retry, and no mapping to a dedicated error. The failure surfaces as XWikiException Error number 3201 ("Exception while saving document"), which tells an administrator nothing about what happened and is indistinguishable from a genuine save failure.
  • The conflict window is as wide as possible: XWikiHibernateStore.saveXWikiDoc sets FlushMode.COMMIT (XWikiHibernateStore.java:569), so the UPDATE is only issued at commit time and the window covers the whole save (attachments, all xobjects, the archive rewrite), not a single statement.
  • documentSavingLockMap (XWikiHibernateStore.java:534) does not help here: it serializes saves of the same document inside one JVM, whereas these conflicts are decided by the transactions' read views.

Before the setting existed, the same race was a silent lost update, so this is not a regression in XWiki - but it is newly visible, and any long operation that reads a document, does other work and saves it at the end is exposed when running on MariaDB 11.6.2 or later.

An occurrence in the wild: extension imports on extensions.xwiki.org fail on the first attempt and succeed when retried - XINFRA-496 for the server side, and the repository-specific race has its own issue.

Proposal

Recognise ER_CHECKREAD / HA_ERR_RECORD_CHANGED in the Hibernate store and either retry the transaction, as MariaDB recommends for deadlock-like errors, or throw a dedicated "document concurrently modified" exception, so that callers and administrators get an actionable error instead of Error number 3201.