XA transaction Specification

Before talking about the Xa specification, you must first understand the concept of Distributed Transaction Processing (DTP. Transaction, or transaction, refers to a set of processes for executing certain functions in one or more resources, such as databases or files, of a program or program segment.
Distributed Transaction Processing means that a transaction may involve multiple database operations. The key to distributed transaction processing is that there must be a way to know all the actions performed by the transaction anywhere, the decision to commit or roll back a transaction must generate a unified result (all commit or all rollback ).
X/open organization (the current open group) defines the Distributed Transaction processing model. X/Open DTP model (1994) includes four parts: Application (AP), Transaction Manager (TM), Resource Manager (RM), and Communication Resource Manager (CRM. Generally, the common Transaction Manager (TM) is the transaction middleware, the common resource manager (RM) is the database, and the Common Communication Resource Manager (CRM) is the message middleware. For the sake of convenience, we will describe it in common forms in this article.
Generally, transactions in a database, such as operations on multiple tables, are treated as local transactions. The transaction processing object of the database is a local transaction, and the distributed transaction processing object is a global transaction.
A global transaction is a global transaction in a distributed transaction processing environment where multiple databases may need to work together. For example, several different databases may be updated in a transaction. Database operations occur everywhere in the system but must be committed or rolled back. At this time, the submission of operations performed by a database on its own depends not only on whether the operation is successful, but also on whether the operations of other databases related to global transactions are successful. If any operation of any database fails, all operations performed by all databases involved in this transaction must be rolled back.
Generally, a database cannot know what other databases are doing. Therefore, transaction middleware is required in a DTP environment, it notifies and coordinates the submission or rollback of relevant databases. However, a database only shadows its own operations (recoverable) into global transactions.
XA is the interface specification (interface function) between transaction middleware and databases defined by X/Open DTP ), transaction middleware uses it to notify the start, end, commit, and rollback of database transactions. XA interface functions are provided by the database vendor.


Xa and two-phase commit protocol

Generally, transaction middleware and databases use two-phase commit to complete a global transaction through the Xa interface specification. The Xa specification is based on the two-phase commit protocol.
In the first stage, transaction middleware requests the transaction branches of all relevant databases to prepare (pre-commit) to confirm whether all relevant databases can submit their respective transaction branches. After a database receives a pre-commit, if it can submit its own transaction branch, it will record its operations in the transaction branch, then, a transaction middleware is given a response that agrees to be submitted. At this time, the database cannot add any operations to the transaction branch, but the database does not actually commit the transaction at this time, the database's operations on shared resources have not been released (locked ). If, for some reason, the database cannot submit its own transaction branch, it rolls back all its operations, releases the lock on the shared resources, and returns the failure response to the transaction middleware.
In the second stage, transaction middleware reviews the pre-commit results returned by all databases. If all databases can be submitted, transaction middleware will require all databases to be formally submitted so that the global transaction is committed. If any database fails to return the result of the pre-commit, transaction middleware requires all other databases to roll back their operations, so that the global transaction is rolled back.
Taking a global transaction as an example, the AP first notifies the transaction middleware to start a global transaction. The transaction middleware notifies the database to start the transaction through the Xa interface function, and then the AP can operate on the resources managed by the database, the database system records all the operations performed by transactions on local resources. After the operation is complete, the transaction middleware notifies the database through the Xa interface function to complete the operation. Transaction middleware records the databases (transaction branches) operated by the AP ). The AP notifies the transaction middleware to submit the global transaction according to the situation. The transaction middleware requires each database to be pre-submitted through the Xa interface function. After all databases return successfully, each database is required to be formally submitted, at this time, a global transaction ends.
The biggest benefit of the Xa specification for applications is that transaction integrity is controlled by transaction middleware and databases through the Xa interface. The AP only needs to focus on processing the application logic of the database, without worrying too much about transaction integrity, application design and development will be much simpler.
Specifically, if there is no transaction middleware, the application system must directly notify the database within the program to start, end, and commit transactions, in case of exceptions, a dedicated program must perform reverse operations on the database to complete rollback. If there are global transactions with many transaction branches, the rollback will become abnormal and complex. When the Xa interface is used, the commit of global transactions is controlled by the transaction middleware. The application only needs to notify the transaction middleware to commit or roll back the transaction, you can control all commit or rollback of the entire transaction (which may involve multiple remote databases), and the application does not need to consider the positive logic at all.