Before talking about the XA specification, you must first understand the concept of Distributed Transaction Processing ( DTP ). Transaction , that is, transaction, also known as transaction, refers to a program or program segment, which is a collection of execution processes to complete certain functions on one or more resources such as databases or files. 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 that the transaction is doing anywhere, and the decision to commit or roll back the transaction must produce uniform results (commit all or rollback all). The X/Open organization (now the Open Group ) defines a distributed transaction processing model. The X/Open DTP model ( 1994 ) includes four parts: application program ( AP ), transaction manager ( TM ), resource manager ( RM ), and communication resource manager ( CRM ). Generally, a common transaction manager ( TM ) is a transaction middleware, a common resource manager ( RM ) is a database, and a common communication resource manager ( CRM ) is a message middleware.
Transactions within a database, such as operations on multiple tables, are usually treated as local transactions. The transaction object of the database is the local transaction, and the object of the distributed transaction is the global transaction. The so-called global transaction means that in a distributed transaction processing environment, multiple databases may need to work together to complete a work, which is a global transaction. For example, several different databases may be updated in one transaction. Operations on the database occur throughout the system but must all be committed or rolled back. At this time, the submission of a database's internal operations depends not only on the success of its own operation, but also on the success of other database operations related to the global transaction. If any operation of any database fails, all participating in the transaction will be All operations done by the database must be rolled back. In general, a database cannot know what other databases are doing. Therefore, in a DTP environment, transaction middleware is necessary to notify and coordinate the commit or rollback of related databases. And a database only maps its own operations (recoverable) to global transactions. XA is the interface specification (ie, interface function) between the transaction middleware and the database defined by X/Open DTP . The transaction middleware uses it to notify the database transaction start, end, commit, rollback, etc. XA interface functions are provided by database vendors. XA and the two-phase commit protocol Usually, the transaction middleware and the database use the two-phase commit to complete a global transaction through the XA interface specification. The basis of the XA specification is the two-phase commit protocol.
In the first phase, the transaction middleware requests all the relevant databases to prepare to commit (pre-commit) their respective transaction branches to confirm whether all the relevant databases can commit their respective transaction branches. When a database receives the pre-commit, if it can submit its own transaction branch, it will record its operations in the transaction branch, and give the transaction middleware a response that agrees to submit. At this time, the database will No more operations can be added to the transaction branch, but the database has not actually committed the transaction at this time, and the database's operations on shared resources have not been released (in a locked state). If for some reason the database cannot commit its own transaction branch, it will roll back all its own operations, release the lock on the shared resource, and return a failure response to the transaction middleware. In the second stage, the transaction middleware examines the pre-commit results returned by all databases. If all databases can be submitted, the transaction middleware will require all databases to formally submit, so that the global transaction is submitted. And if any database pre-commit returns and fails, the transaction middleware will ask 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, and the transaction middleware notifies the database to start the transaction through the XA interface function, and then the AP can operate the resources managed by the database, and the database system records all the transactions on the local resources. operate. After the operation is completed, the transaction middleware notifies the database that the operation is completed through the XA interface function. The transaction middleware is responsible for recording which databases (transaction branches) the AP has operated on. The AP informs the transaction middleware to submit the global transaction according to the situation. The transaction middleware will request each database to do pre-submission through the XA interface function. After all the databases return successfully, each database will be required to submit the global transaction. At this time, a global transaction ends. XA
The biggest benefit of the specification to the application is that the transaction integrity is controlled by the transaction middleware and the database through the XA interface. The AP only needs to pay attention to the processing of the application logic with the database, and does not need to care too much about the transaction integrity. Simplified a lot. Specifically, if there is no transaction middleware, the application system needs to directly notify the database to start, end and commit transactions within the program. When an abnormal situation occurs, a special program must perform reverse operations on the database to complete the rollback. In the case of a global transaction with many transaction branches, the situation becomes very complicated when it is rolled back. With the XA interface, the submission of the global transaction is controlled by the transaction middleware, and the application program can control the entire submission or rollback of the entire transaction (which may involve multiple remote databases) only by notifying the transaction middleware to submit or roll back the transaction. Roll, the application does not need to consider the flushing logic at all. In a global transaction involving multiple databases, in order to ensure the integrity of the global transaction, it is necessary for the transaction middleware to control the database to do two-phase commit. However, in a typical two-phase commit, the transaction takes a relatively long time from the beginning to the end (commit or rollback) for the database, and the resources (such as logical logs, various locks) used by the database during transaction processing are not used until the end of the transaction. will release. Therefore, using a typical two-phase commit will take up more resources relatively, and the situation will be more serious when the network conditions are not very good, such as low-speed network and frequent network turbulence. When a global transaction involves only one database, there is an optimization that is one-phase commit. When the AP notifies the transaction middleware to submit the transaction, the transaction middleware directly requests the database to submit the transaction, eliminating the first stage of the two-phase submission, which can shorten the processing time of a transaction and improve the efficiency of transaction processing. As a special case of two-phase commit, like two-phase commit, one-phase commit is standard.
Implementation example
http://eric-hwp.iteye.com/blog/2205763
用框架的话只要配置好对个数据源，和工厂，公用一个JtaTransactionManager事物管理器，一个事物中有多个不同数据库操作不同数据源的时候会自动启用两阶段提交
http://zibo.group.iteye.com/group/topic/6894