小结：
1、innodb支持XA事务；
2、XA协议作为资源管理器（数据库）与事务管理器的接口标准；
3、提交或者回滚的点：必须所有的组件被提交或者被回滚；
4、2阶段
PC-1，TM告知所有RM要准备提交，各个RM汇报是否准备好；
PC-2，如果所有RM准备好，则TM告知所有RM提交；否则如果有RM未准备好，则TM告知所有RM回滚。
5、1阶段
当只有一个RM时，2阶段提交退化为one-phase commit 1阶段提交。
XA的Mysql实现是通过在全局事务中扮演资源管理者RM角色来处理XA事务；
连接到Mysql服务器的客户端程序扮演事务管理者TM角色。
MySQL :: MySQL 8.0 Reference Manual :: 13.3.8 XA Transactions https://dev.mysql.com/doc/refman/8.0/en/xa.html
MySQL :: MySQL 8.0 Reference Manual :: C.6 Restrictions on XA Transactions https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html
13.3.8 XA Transactions
Support for XA transactions is available for the InnoDB storage engine. The MySQL XA implementation is based on the X/Open CAE document Distributed Transaction Processing: The XA Specification. This document is published by The Open Group and available athttp://www.opengroup.org/public/pubs/catalog/c193.htm. Limitations of the current XA implementation are described in Section C.6, “Restrictions on XA Transactions”.
On the client side, there are no special requirements. The XA interface to a MySQL server consists of SQL statements that begin with the XAkeyword. MySQL client programs must be able to send SQL statements and to understand the semantics of the XA statement interface. They do not need be linked against a recent client library. Older client libraries also will work.
Among the MySQL Connectors, MySQL Connector/J 5.0.0 and higher supports XA directly, by means of a class interface that handles the XA SQL statement interface for you.
XA supports distributed transactions, that is, the ability to permit multiple separate transactional resources to participate in a global transaction. Transactional resources often are RDBMSs but may be other kinds of resources.
A global transaction involves several actions that are transactional in themselves, but that all must either complete successfully as a group, or all be rolled back as a group. In essence, this extends ACID properties “up a level” so that multiple ACID transactions can be executed in concert as components of a global operation that also has ACID properties. (As with nondistributed transactions, SERIALIZABLE may be preferred if your applications are sensitive to read phenomena. REPEATABLE READ may not be sufficient for distributed transactions.)
Some examples of distributed transactions:
-
An application may act as an integration tool that combines a messaging service with an RDBMS. The application makes sure that transactions dealing with message sending, retrieval, and processing that also involve a transactional database all happen in a global transaction. You can think of this as “transactional email.”
-
An application performs actions that involve different database servers, such as a MySQL server and an Oracle server (or multiple MySQL servers), where actions that involve multiple servers must happen as part of a global transaction, rather than as separate transactions local to each server.
-
A bank keeps account information in an RDBMS and distributes and receives money through automated teller machines (ATMs). It is necessary to ensure that ATM actions are correctly reflected in the accounts, but this cannot be done with the RDBMS alone. A global transaction manager integrates the ATM and database resources to ensure overall consistency of financial transactions.
Applications that use global transactions involve one or more Resource Managers and a Transaction Manager:
-
A Resource Manager (RM) provides access to transactional resources. A database server is one kind of resource manager. It must be possible to either commit or roll back transactions managed by the RM.
-
A Transaction Manager (TM) coordinates the transactions that are part of a global transaction. It communicates with the RMs that handle each of these transactions. The individual transactions within a global transaction are “branches” of the global transaction. Global transactions and their branches are identified by a naming scheme described later.
The MySQL implementation of XA enables a MySQL server to act as a Resource Manager that handles XA transactions within a global transaction. A client program that connects to the MySQL server acts as the Transaction Manager.
To carry out a global transaction, it is necessary to know which components are involved, and bring each component to a point when it can be committed or rolled back. Depending on what each component reports about its ability to succeed, they must all commit or roll back as an atomic group. That is, either all components must commit, or all components must roll back. To manage a global transaction, it is necessary to take into account that any component or the connecting network might fail.
The process for executing a global transaction uses two-phase commit (2PC). This takes place after the actions performed by the branches of the global transaction have been executed.
-
In the first phase, all branches are prepared. That is, they are told by the TM to get ready to commit. Typically, this means each RM that manages a branch records the actions for the branch in stable storage. The branches indicate whether they are able to do this, and these results are used for the second phase.
-
In the second phase, the TM tells the RMs whether to commit or roll back. If all branches indicated when they were prepared that they will be able to commit, all branches are told to commit. If any branch indicated when it was prepared that it will not be able to commit, all branches are told to roll back.
In some cases, a global transaction might use one-phase commit (1PC). For example, when a Transaction Manager finds that a global transaction consists of only one transactional resource (that is, a single branch), that resource can be told to prepare and commit at the same time.
XA_百度百科 https://baike.baidu.com/item/XA
- 中文名
- XA
- 提 出
- Tuxedo
- 组 织
- X/Open
- 支 持
- Oracle、Informix、DB2和Sybase
简介
The goal of XA is to guarantee atomicity in "global transactions" that are executed across heterogeneous back end data stores (such as databases, application servers, message queues, transactional caches, etc.). To guarantee atomicity, XA uses a two-phase commit (2PC) to ensure that all resources either commit or roll back any particular transaction consistently (i.e. all do the same, atomically).
Specifically, XA describes the interface between the global transaction manager and a specific application. An application that wants to use XA will engage an XA transaction manager using a library or separate service. The transaction manager will then keep track of the participants in the transaction (i.e. the various other data stores to which the application is writing), and work with them to carry out the two-phase commit protocol. In other words, the XA transaction manager generally rides on top of the application's existing connections to the servers to which it wants to write a transaction. It maintains a log of its decisions to commit or abort (similar to how a database maintains a log of its own writes), which it can use to recover in case it fails and needs to be restarted.[1]
Many software vendors continue to support XA (meaning the software can participate in XA transactions), including a variety of relational databases and message brokers.[1]
Contents
]
Since XA uses two-phase commit, the advantages and disadvantages of that protocol generally apply to XA. The main advantage is that XA (using 2PC) allows an atomic transaction across multiple heterogeneous technologies (e.g. a single transaction could encompass multiple databases from different vendors as well as an email server and a message broker), whereas traditional database transactions are limited to a single database.
The main disadvantage is that 2PC is a blocking protocol: the other servers need to wait for the transaction manager to issue a decision about whether to commit or abort each transaction. If the transaction manager goes offline while transactions are waiting for its final decision, they will be stuck and hold their database locks until the transaction manager comes online again and issues its decision. This extended holding of locks may be disruptive to other applications that are using the same databases.[1]
Moreover if the transaction manager crashes and its record of decisions cannot be recovered (e.g. due to a bug in how the decisions were logged, or due to data corruption on the server), manual intervention may be necessary. Many XA implementations provide an "escape hatch" for transactions to independently decide whether to commit or abort (without waiting to hear from the transaction manager), but this risks violating the atomicity guarantee and is therefore reserved for emergencies.[1]
]
The XA specification describes what a resource manager must do to support transactional access. Resource managers that follow this specification are said to be XA-compliant.
The XA specification was based on an interface used in the Tuxedo system developed in the 1980s, but adopted by several systems since then.[2]
]