XA transaction support is limited to the
InnoDB storage engine.
For “external XA,” a MySQL server acts as a
Resource Manager and client programs act as Transaction
Managers. For “Internal XA”, storage engines within
a MySQL server act as RMs, and the server itself acts as a TM.
Internal XA support is limited by the capabilities of individual
storage engines. Internal XA is required for handling XA
transactions that involve more than one storage engine. The
implementation of internal XA requires that a storage engine
support two-phase commit at the table handler level, and
currently this is true only for
RESUME clauses are recognized but have no
SUSPEND [FOR MIGRATE]
clause is recognized but has no effect.
The requirement that the
xid value be different for
each XA transaction within a global transaction is a limitation
of the current MySQL XA implementation. It is not part of the XA
If an XA transaction has reached the
state and the MySQL server is killed (for example, with
kill -9 on Unix) or shuts down abnormally,
the transaction can be continued after the server restarts.
However, if the client reconnects and commits the transaction,
the transaction will be absent from the binary log even though
it has been committed. This means the data and the binary log
have gone out of synchrony. An implication is that XA cannot be
used safely together with replication.
It is possible that the server will roll back a pending XA
transaction, even one that has reached the
PREPARED state. This happens if a client
connection terminates and the server continues to run, or if
clients are connected and the server shuts down gracefully. (In
the latter case, the server marks each connection to be
terminated, and then rolls back the
XA transaction associated with it.) It should be possible to
commit or roll back a
transaction, but this cannot be done without changes to the
binary logging mechanism.
FLUSH TABLES WITH READ LOCK is
not compatible with XA transactions.