Restrictions on XA transactions in the MySQL database

XA transaction support is limited to INNODB storage engines.

MySQL XA implementations are for external XA, where the MySQL server acts as a resource manager, and the client program acts as the transaction manager. "Internal XA" is not implemented. This allows a separate storage engine within the MySQL server as RM (Resource Manager) and the server itself as a TM (transaction manager). Internal XA is required to handle XA transactions that contain more than 1 storage engines. The implementation of internal XA is incomplete because it requires the storage engine to support two-phase commits at the table handler level, which is currently implemented only for InnoDB.

For XA START, join and resume clauses are not supported.

For the XA end, the suspend [for MIGRATE] clause is not supported.

Within a global transaction, the bqual portion of the XID value should be different for each XA transaction, which is a restriction on the current MySQL XA implementation. It is not part of the XA specification.

If the XA transaction reaches the prepared state and the MySQL server is down, the server can continue to process the transaction after it restarts. As it should have been. However, if the client connection is aborted and the server continues to run, the server rolls back any outstanding XA transactions, even if the transaction has reached the prepared state. It should be able to commit or rollback prepared XA transactions, but this cannot happen without changing the binary log mechanism.