
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global
transaction is in the  NON-EXISTING state

XA RECOVER
----------

The XA RECOVER statement shows information about all transactions which are in
the PREPARED state. It does not matter which connection created the
transaction: if it has been PREPARED, it appears. But this does not mean that
a connection can commit or rollback a transaction which was started by another
connection. Note that transactions using a 1-phase commit are never in the
PREPARED state, so they cannot be shown by XA RECOVER.

XA RECOVER produces four columns:

XA RECOVER;
+----------+--------------+--------------+------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+------+
|        1 |            4 |            0 | test |
+----------+--------------+--------------+------+

MariaDB starting with 10.3.3
----------------------------
You can use XA RECOVER FORMAT='SQL' to get the data in a human readable form
that can be directly copy-pasted into XA COMMIT or XA ROLLBACK. This is
particularly useful for binary xid generated by some transaction coordinators.

formatID is the formatID part of xid.

data are the gtrid and bqual parts of xid, concatenated.

gtrid_length and bqual_length are the lengths of gtrid and bqual, respectevely.

Examples
--------

2-phases commit:

XA START 'test';

INSERT INTO t VALUES (1,2);

XA END 'test';

XA PREPARE 'test';

XA COMMIT 'test';

1-phase commit:

XA START 'test';

INSERT INTO t VALUES (1,2);

XA END 'test';

XA COMMIT 'test' ONE PHASE;

Human-readable:

xa start '12\r34\t67\v78', 'abc\ndef', 3;

insert t1 values (40);

xa end '12\r34\t67\v78', 'abc\ndef', 3;

xa prepare '12\r34\t67\v78', 'abc\ndef', 3;

xa recover format='RAW';
+----------+--------------+--------------+--------------------+
| formatID | gtrid_length | bqual_length | data               |
+----------+--------------+--------------+--------------------+
34      67v78abc       11 |            7 | 12
def |
+----------+--------------+--------------+--------------------+

xa recover format='SQL';
+----------+--------------+--------------+-------------------------------------
---------+
| formatID | gtrid_length | bqual_length | data                               
     |
+----------+--------------+--------------+-------------------------------------
---------+
|        3 |           11 |            7 |
X'31320d3334093637763738',X'6162630a646566',3 |
+----------+--------------+--------------+-------------------------------------
---------+

xa rollback X'31320d3334093637763738',X'6162630a646566',3;

Known Issues
------------

MariaDB Galera Cluster
----------------------

MariaDB Galera Cluster does not support XA transactions.

However, MariaDB Galera Cluster builds include a built-in plugin called wsrep.
Prior to MariaDB 10.4.3, this plugin was internally considered an XA-capable
storage engine. Consequently, these MariaDB Galera Cluster builds have
multiple XA-capable storage engines by default, even if the only "real"
storage engine that supports external XA transactions enabled on these builds
by default is InnoDB. Therefore, when using one these builds MariaDB would be
forced to use a transaction coordinator log by default, which could have
performance implications.

See Transaction Coordinator Log Overview: MariaDB Galera Cluster for more
information.

URL: https://mariadb.com/kb/en/xa-transactions/