Limitations on XA transactions in MySQL Databases

XA transaction support is limited to the InnoDB Storage engine. MySQLXA is implemented for external XA, where the MySQL server acts as the resource manager and the client program acts as the Transaction Manager. Internal XA is not implemented. In this way, the separate storage engine in the MySQL server is allowed as RM (Resource Manager), and the server itself is used as TM (Transaction Manager ). Processing contains one

XA transaction support is limited to the InnoDB Storage engine. MySQL XA is implemented for external XA, where the MySQL server acts as the resource manager and the client program acts as the Transaction Manager. Internal XA is not implemented. In this way, the separate storage engine in the MySQL server is allowed as RM (Resource Manager), and the server itself is used as TM (Transaction Manager ). Processing contains one

XA transaction support is limited to the InnoDB Storage engine.

MySQL XA is implemented for external XA, where the MySQL server acts as the resource manager and the client program acts as the Transaction Manager. "Internal XA" is not implemented ". In this way, the separate storage engine in the MySQL server is allowed as RM (Resource Manager), and the server itself is used as TM (Transaction Manager ). Internal XA is required to process XA transactions that contain more than one storage engine. The internal XA implementation is incomplete because it requires the storage engine to support two-phase commit at the table processing program level. Currently, this feature is only implemented for InnoDB.

JOIN and RESUME clauses are not supported for xa start.

For xa end, the SUSPEND [for migrate] clause is not supported.

In a global transaction, for each XA transaction, the bqual part of the xid value should be different, which is a limit on the implementation of the current MySQL XA. It is not part of the XA specification.

If the XA transaction reaches the PREPARED state and the MySQL server is down, the transaction can be processed after the server is restarted. As it should have been. However, if the client connection is terminated and the server continues running, the server rolls back any unfinished XA transactions, even if the transaction has reached the PREPARED status. It should be able to commit or roll back prepared xa transactions, but this is not possible without changing the binary log mechanism.