Research on distributed transaction, two-phase commit, one-stage commit, best efforts 1PC mode and transaction compensation mechanism

This text connection: http://blog.csdn.net/bluishglc/article/details/7612811, reprint please indicate the source!

1.XA

XA is a specification of distributed transactions presented by the X/open organization. The XA specification primarily defines the interface between the (global) transaction manager (Transaction Manager) and (local) resource Manager (Resource Manager). The XA interface is a two-way system interface that forms a communication bridge between the transaction manager (Transaction Manager) and one or more resource managers (Resource Manager). The reason why XA needs to introduce a transaction manager is that in a distributed system, theoretically (referring to a paper such as Fischer), two machines are theoretically unable to achieve a consistent state, requiring a single point of coordination. The transaction manager controls the global transaction, manages the transaction life cycle, and coordinates the resources. The resource manager is responsible for controlling and managing actual resources, such as databases or JMS queues. Describes the relationship between the transaction manager, the resource manager, and the application:

Figure 1. Relationships among the various participants in distributed transactions under the XA specification

2.JTA

As the transaction specification JTA (Java Transaction API) on the Java platform also defines support for XA transactions, in fact, JTA is modeled on an XA-based architecture, in JTA, The transaction manager is abstracted as an Javax.transaction.TransactionManager interface and implemented through the underlying transaction service (i.e., JTS). Like many other Java specifications, JTA only defines the interface, the specific implementation is provided by the supplier (such as a Java EE vendor), the current implementation of JTA mainly by the following:

JTA implementations provided by the 1.J2EE container (JBoss)
2. Independent JTA implementations: such as Jotm,atomikos. These implementations can be used in environments that do not use the Java EE Application Server to provide distributed transaction assurance. such as Tomcat,jetty and common Java applications.

3. Phase Two submission

All of the introduction to distributed transactions is bound to refer to two-phase commits, as it is the key to implementing XA distributed transactions (specifically, two-phase commits guarantee the atomicity of distributed transactions: that is, all nodes are either full or not). The so-called two phases are: The first phase: the preparatory phase and the second phase: the submission phase.

Figure 2. Two phase commit (excerpt from the Java Transaction Design strategy published in info)

1. Preparation Phase: The transaction Coordinator (transaction manager) sends a prepare message to each contributor (Resource Manager), each of which either returns a failure directly (such as a permission validation failure), performs a transaction locally, writes the local redo and undo logs, but does not commit to a state of "everything is ready, only owed to the east Wind". (about what each participant specifically did at the preparatory stage I have not yet made reference to the exact information, but one thing is quite certain: the participants completed almost all formal submissions during the preparation phase, and some of the materials were "tentative submissions", Only the last step takes a very short time-consuming formal commit operation to the second stage of execution. )

2. Submission Phase: If the coordinator receives a failure message from the participant or times out, sends a rollback (ROLLBACK) message directly to each participant, otherwise commits the commit message, and the contributor performs a commit or rollback operation based on the coordinator's instructions, releasing the lock resources used during all transaction processing. (Note: The lock resource must be released at the last stage)

The goal of splitting submissions into two phases is clear: Commit the transaction as late as possible, and let the transaction do as much work as possible before committing, so that the final commit phase will be a very short, minimal operation that fails in a distributed system with a very small probability of failure-the so-called " Network communication Crisis "is very short, this is the two-phase commit to ensure the atomicity of distributed transactions is the key. (The only theoretical two-phase commit problem is when the facilitator issues a persistent error, such as a disk failure, when the coordinator issues the commit command, causing the transaction to be untraceable and recoverable)

From the way the two-phase commit works, it is clear that the process of committing a transaction requires coordination between multiple nodes, and that the release of the lock resource by each node must wait until the transaction is finally committed, so that the two-phase commit consumes more time to execute the same transaction than the one-phase commit. The extension of transaction execution time means that the probability of conflict of lock resources increases, and when the concurrency of a transaction reaches a certain amount, there will be a large backlog of transactions or even deadlock, and the system performance will be severely declined. This is the use of XA transactions

4. One-stage submission (best efforts 1PC mode)

Unlike a two-phase commit, a one-phase commit is straightforward, which is the process of returning the results to the application from the time the application sends a request to the database to complete the commit or rollback of the database. A phase commit does not require a "coordinator" role, there is no coordination between the nodes, so its transaction execution time is shorter than the two-phase commit, but the committed "critical" is the actual commit time of each transaction, compared to the two-phase commit, the probability of one-phase commit appearing "inconsistent" becomes larger. But we have to note that when infrastructure problems occur (such as network outages, downtime, etc.), it is possible for a one-stage submission to be "inconsistent", and many teams will choose this option compared to its performance advantage. about how to implement a phase commit in a spring environment, there is a very good article worth reference: Http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=5

5. Transaction compensation mechanism

Like best efforts 1PC this mode, if the application can get all the data sources, and then use the same transaction manager (this is the spring's transaction manager) to manage the transaction. The most typical application scenario for this model is non-database sharding. But for those highly autonomous (autonomy)-based distributed system interfaces built on Web SERVICE/RPC/JMS, the best efforts 1PC model is powerless, and in such scenarios there is a final way to help us achieve "final consistency", That is the transaction compensation mechanism. Regarding the transaction compensation mechanism is a big topic, this article only briefly mentions, later will make the specialized research and the introduction.

6. How to choose between a standard distributed transaction based on two-phase commit and the best efforts 1PC

In general, the number of subsystems that require interaction is small, and the entire system will not or seldom introduce new subsystems in the future and the load remains stable for a long time, that is, without scaling requirements, you can choose to use distributed transactions, considering the complexity of the development and the workload. For systems with high performance requirements that are not time-critical, you should consider using the best efforts 1PC or transaction compensation mechanism. For those systems that need to be sharding modified, the distributed transaction should not be considered at all, since sharding opens the database horizontally Scaled window, and the use of distributed transactions seems to add a yoke to the newly opened window.

Add: About the crisis of network communication

Any program that waits for a response after a request is at risk of losing contact because of a network communication failure that can occur at any time. This danger occurs after the request is made, the server returns an answer, if the network communication fails during this period, the requesting party will not be able to receive a response, so it is unable to determine whether the server has successfully processed the request, because the response may not receive the request is not successfully sent to the server, may be the service The response cannot be passed back to the requester after processing is complete. This period of time is called the critical phase of network communication (in-doubt times). Obviously, the critical point of network communication is another reliability problem which needs to be considered in the distributed system besides the single points of reliability.

Resources:

1. Baidu Encyclopedia
2.http://en.wikipedia.org/wiki/java_transaction_api
3.http://www.nosqlnotes.net/archives/62#more-62
4.http://hi.baidu.com/javaopensource/blog/item/0a2b764ec501b10cb3de05ba.html

Research on distributed transaction, two-phase commit, one-stage commit, best efforts 1PC mode and transaction compensation mechanism