I have been reviewing the knowledge related to affairs for the past few days, and I am also going to make some in-depth summaries of the previous knowledge of fur. Although this knowledge is not used, it is still necessary to understand the principle of its implementation, because knowing the principle, You can make it happen too.
In the previous section on the programming model of transactions, three programming models are mainly described. In general, we are dealing with a single resource transaction, that is, operating on a database alone. If you need to ensure transactional consistency across multiple resources
For example: when withdrawing money from an ATM, the user's account needs to be debited, and then a message is sent to the message server (assuming that the message server is implemented with JMS), and the message server asynchronously informs the user through SMS. If the user's withdrawal fails, then the messaging server should not send an SMS to the user. How to ensure that the user's account deduction is consistent with the message server's message, that is, the message server persists the message if the withdrawal is successful, and then sends a short message to the user. If the withdrawal fails, the message server rolls back the message and does nothing.
In the above case, it is necessary to use distributed transactions, that is, to ensure data consistency across multiple resources.
X/Open DTP (X/Open Distributed Transaction Processing Reference Model) is a set of distributed transaction standards defined by the organization X/Open, that is, it defines specifications and API interfaces, which are implemented by the manufacturer. This idea is everywhere in the java platform.
X/Open DTP defines three components: AP, TM, RM
AP (Application Program): that is, an application program, which can be understood as a program that uses DTP
RM (Resource Manager): Resource manager, here can be understood as a DBMS system, or a message server management system, the application controls resources through the resource manager. The resource must implement the interface defined by XA
TM (Transaction Manager): transaction manager, responsible for coordinating and managing transactions, providing AP application programming interfaces and managing resource managers
Among them, AP can communicate with TM and RM, TM and RM can communicate with each other, XA interface is defined in DTP model, TM and RM communicate bidirectionally through XA interface, for example: TM notifies RM to submit transaction or rollback transaction, RM Notify the TM of the submission result. Resource control is performed between AP and RM through the Native API provided by RM. There is no API and specification for this. Each manufacturer implements its own resource control, such as Oracle's own database driver.
The following figure illustrates the relationship between the three:
Among them, the following concepts are defined in DTP:
Transaction: A transaction is a complete unit of work consisting of multiple independent computing tasks that are logically atomic.
Global transaction: For a transaction that operates multiple resource managers at one time, it is a global transaction
Branch transaction: In a global transaction, a resource manager has its own independent tasks, and the collection of these tasks is used as the branch task of this resource manager
Control thread: used to represent a worker thread, mainly a thread associated with AP, TM, and RM, that is, the transaction context. Simply put, it is necessary to identify the relationship between a global transaction and a branch transaction.
Two-phase commit protocol : If a transaction manager manages multiple resource managers, if it controls global transactions and branch transactions, the two-phase commit protocol is described in DTP
Phase 1: Preparation Phase
The transaction manager informs the resource manager to prepare the branch transaction, and the resource manager informs the transaction manager of the preparation result
Phase 2: Commit Phase
The transaction manager notifies the resource manager to commit the branch transaction, and the resource manager informs the transaction manager of the result
The following figure demonstrates a two-phase commit in a normal situation,
If a resource pre-commit fails in the first stage, the second stage rolls back the resources that have been pre-committed successfully in the first stage
The above is a relatively normal situation, but since RM has the right to submit or roll back its own branch transaction according to the situation (the official statement is: Heuristic Decision ), then the following situations may occur:
1 The RM branch transaction has been committed before the TM notifies the RM to commit the transaction
2 Before the TM notifies the RM to commit the transaction, the RM branch transaction is all rolled back
3 The RM branch transaction is partially rolled back before the TM notifies the RM to commit the transaction
For a branch transaction marked by Heuristic Decision, before the TM notifies RM to forget it, the RM must save the information of the branch transaction. After the TM recovers the transaction from the failure, it informs the RM to forget the branch transaction. At this time, the RM actually completes the transaction.
For the first two cases, TM will handle it better. When doing transaction recovery, either mark the global transaction as successful, or mark the global transaction as rollback, and notify RM that the branch transaction can be completed. For the third case, it may be necessary to make a decision. How to deal with this, it seems that DTP does not explain the details, and it can be left to the application to judge.
DTP programming model
Although the internal implementation of DTP is more complex, it is relatively simple for the DTP programming model
1 AP gets transaction via TM
2 AP declares which RM is required, TM registers RM
3 AP uses RM to complete branch transaction
4 AP commits transaction via TM
5 TM notifies RM to commit transaction
The implementation of DTP services needs to consider the following issues:
- How to get TM?
- How to start and end a transaction
- How to identify a transaction
- How to save and pass transaction context
- How applications share resources through resource manager operations
- How the resource manager implements the prepare phase and the logic associated with the commit phase
- How to implement a two-phase commit protocol
- How to implement transaction recovery under abnormal conditions
In fact, if you understand these issues clearly, you can implement a distributed transaction model with two-phase commit by yourself.
Reprinted from: http://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html