Pre-General Availability Draft: 2017-11-23
An XA transaction progresses through the following states:
XA STARTto start an XA transaction and put it in the
IDLEXA transaction, you can issue either an
XA PREPAREstatement or an
XA COMMIT ... ONE PHASEstatement:
XA PREPAREputs the transaction in the
XA RECOVERstatement at this point will include the transaction's
xidvalue in its output, because
XA RECOVERlists all XA transactions that are in the
XA COMMIT ... ONE PHASEprepares and commits the transaction. The
xidvalue will not be listed by
XA RECOVERbecause the transaction terminates.
Here is a simple XA transaction that inserts a row into a table as part of a global transaction:
mysql> XA START 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO mytable (i) VALUES(10); Query OK, 1 row affected (0.04 sec) mysql> XA END 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> XA PREPARE 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> XA COMMIT 'xatest'; Query OK, 0 rows affected (0.00 sec)
Within the context of a given client connection, XA transactions
and local (non-XA) transactions are mutually exclusive. For
START has been issued to begin an XA transaction, a
local transaction cannot be started until the XA transaction has
been committed or rolled back. Conversely, if a local
transaction has been started with
TRANSACTION, no XA statements can be used until the
transaction has been committed or rolled back.
If an XA transaction is in the
you cannot issue any statements that cause an implicit commit.
That would violate the XA contract because you could not roll
back the XA transaction. You will receive the following error if
you try to execute such a statement:
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state
Statements to which the preceding remark applies are listed at Section 13.3.3, “Statements That Cause an Implicit Commit”.