DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(mysql.info) xa-restrictions

Info Catalog (mysql.info) view-restrictions (mysql.info) restrictions
 
 I.5 Restrictions on XA Transactions
 ===================================
 
 XA transaction support is limited to the `InnoDB' storage engine.
 
 The MySQL XA implementation is for `external XA,' where a MySQL server
 acts as a Resource Manager and client programs act as Transaction
 Managers. `Internal XA' is not implemented. This would allow individual
 storage engines within a MySQL server to act as RMs, and the server
 itself to act as a TM. Internal XA is required for handling XA
 transactions that involve more than one storage engine. The
 implementation of internal XA is incomplete because it requires that a
 storage engine support two-phase commit at the table handler level, and
 currently this is true only for `InnoDB'.
 
 For `XA START', the `JOIN' and `RESUME' clauses are not supported.
 
 For `XA END', the `SUSPEND [FOR MIGRATE]' clause is not supported.
 
 The requirement that the BQUAL part of 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 specification.
 
 If an XA transaction has reached the `PREPARED' 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 `PREPARED' XA transaction associated with it.) It should be
 possible to commit or roll back a `PREPARED' XA transaction, but this
 cannot be done without changes to the binary logging mechanism.
 
Info Catalog (mysql.info) view-restrictions (mysql.info) restrictions
automatically generated byinfo2html