<p>The server rolled back an XA transaction branch because a lock deadlock was detected.</p>
<p>MySQL Error 1614: ER_XA_RBDEADLOCK signals that an XA transaction branch was rolled back after the server detected a deadlock. Release conflicting locks or redesign the two-phase commit flow to eliminate circular waits, then retry the transaction.</p>
XA_RBDEADLOCK: Transaction branch was rolled back:
The error appears when MySQL aborts a branch of a distributed XA transaction during the prepare or commit phase because a deadlock was discovered. The server rolls back the branch and returns SQLSTATE XA102.
In two-phase commit, consistency outranks liveness. When InnoDB detects that locks held by one XA branch block another in a circular wait, it rolls back the youngest victim to break the deadlock and preserve atomicity across resources.
The message surfaces during XA START, XA END, XA PREPARE, or XA COMMIT statements if the branch still holds row or metadata locks that conflict with another session running inside the same global transaction or a separate workload.
The rolled-back branch loses its uncommitted changes, but other branches of the XA transaction remain intact until a decision is taken. Coordinators should detect the RB reply and decide whether to issue XA ROLLBACK to all participants or retry.
Classic InnoDB deadlocks involve local transactions. ER_XA_RBDEADLOCK is specific to distributed transactions and guarantees that the participant unilaterally rolled back, requiring the coordinator to react.
Two XA branches update the same rows in reverse order, creating a circular wait on row locks.
Range queries with LOCK IN SHARE MODE under REPEATABLE READ hold gap locks that block inserts from another branch.
A branch keeps locks open between XA END and XA PREPARE, increasing the window for deadlocks.
Autocommit statements executed in the same session as an XA branch introduce extra locks and contention.
Standard InnoDB deadlock during local transactions; no XA involvement.
Participant reports a resource manager error during XA operation.
The XA transaction identifier is unknown or already completed.
Generic rollback of an XA branch for reasons other than deadlock.
Yes. The branch reporting the error is already rolled back. The coordinator should decide whether to roll back the entire global transaction or retry the failed branch.
You can lower the isolation level to READ COMMITTED or enable innodb_locks_unsafe_for_binlog, but you risk phantom reads and data inconsistency. Prefer proper lock ordering.
Enable performance_schema tables like events_transactions_summary_by_thread. Poll them or use Galaxy alerts to flag repeat deadlocks.
The code is emitted by MySQL, but any storage engine that supports XA and deadlock detection could trigger it. In practice, InnoDB is the common source.
.avif)
.avif){kind=logo}
