X/open dtp--Distributed Transaction model

Reprint: http://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html

This has been a review of business-related knowledge for a few days, and is ready to give some insight into the previous knowledge of the fur, although this knowledge is not used, but it is necessary to understand the principle of implementation, because knowing the principle, you can also realize it.

In the previous transaction programming model, the main description of the three programming models, in general, we are in touch with a single resource of the transaction, that is, a separate database operation. If you need to ensure transactional consistency across multiple resources

For example, when you withdraw money from an ATM, you need to debit the user's account, and then send a message to the message server (assuming that the message server is implemented in JMS), and the message server asynchronously notifies the user by SMS. If a user fails to withdraw money, the messaging server should not send a text message to the user. How to ensure that the user accounts receivable and message Server message consistency, that is, the success of the withdrawal, the message server persistent message, and then send SMS to the user, the withdrawal failed, the message server rollback message, do nothing.

In this case, you need to use distributed transactions, which are guaranteed data consistency across multiple resources.

X/open DTP (x/open distributed Transaction processing Reference Model) is the standard for a set of distributed transactions defined by this organization, which defines the specification and API interfaces, The specific implementation by this manufacturer. This idea is everywhere in the Java platform.

The X/open DTP defines three components: AP,TM,RM

AP (Application program): This is the application that can be understood as the use of DTP programs

RM (Resource Manager): Resource Manager, which can be understood as a DBMS system, or a messaging server management system, where the application controls resources through the resource manager. Resources must implement XA-defined interfaces

TM (Transaction Manager): Transaction manager, responsible for coordinating and managing transactions, providing access to AP application programming interfaces, and managing resource managers

Wherein, the AP can communicate with the TM and RM, the TM and RM can communicate with each other, the DTP model defines the XA interface, TM and RM through the XA interface for two-way communication, for example: TM notifies RM to commit the transaction or rollback the transaction, RM notifies the TM of the submission result. Between the AP and RM is controlled by the native API provided by RM, which does not carry out the API and specification, and each vendor implements its own resource control, such as Oracle's own database driver.

The following diagram illustrates the relationship between the three:

One of the following concepts is set in DTP:

Transactions: A transaction is a complete unit of work consisting of several separate compute tasks, which are logically atomic.

Global transaction: For a one-time operation of multiple resource manager transactions, the global transaction

Branch transactions: In a global transaction, a resource manager has its own independent task, a collection of these tasks as a branch task for this explorer

Control thread: Used to represent a worker thread, primarily a thread that associates Ap,tm,rm, which is the transactional context. Simply put, you need to identify the relationship between a global transaction and a branch transaction.

Two phase commit agreement: If a transaction manager manages multiple resource managers, if you control global and branch transactions, the two-phase commit protocol is described in DTP

Phase I: Preparation phase

The transaction manager notifies the resource manager to prepare the branch transaction, and the resource manager tells the transaction manager to prepare the result

Phase II: Submission phase

The transaction manager notifies the resource manager to commit the branch transaction, and the explorer tells the transaction manager results

The following illustration shows a two-phase commit under normal circumstances,

If a resource pre-commit fails in the first phase, the second phase rolls back the resource that has been pre-committed for the first phase

The above is a relatively normal situation, but because RM has the right to submit or roll back their own branch transactions (the official saying is:heuristic decision) that three, the following situation may occur:

1 the RM Branch Transaction has been committed before the TM notifies RM that the transaction has been committed

2 RM Branch transactions are all rolled back before the TM notifies RM to commit the transaction

3 the RM branch transaction part rolls back before the TM notifies RM to commit the transaction

For a branch transaction with the heuristic decision tag, RM must save the branch transaction information until the TM notifies RM forget it, and when the TM resumes the transaction from the failure, notifies RM forget the branch transaction, at which time the RM does not actually complete the transaction.

For the previous two cases, the TM would be better handled, and when the transaction was resumed, either the global transaction was marked as successful, or the global transaction was marked for rollback, notifying RM that the branch transaction could be completed. For the third situation, it may be necessary to make a decision, this specific how to deal with, seemingly DTP does not explain the details, can be handed to the application to judge.

DTP programming Model

Although the interior of the DTP is relatively complex, the DTP programming model is relatively simple.

1 APs get transactions via TM

2 AP affirms which Rm,tm are required to register RM

3 AP uses RM to complete branch transactions

4 AP submits transactions via TM

5 TM Notification RM COMMIT TRANSACTION

The implementation of DTP services needs to consider the following issues:

• How do I get a TM?
• How to start and end a transaction
• How to identify a transaction
• How to save and pass transaction contexts
• How to apply shared resources through Resource Manager
• How the resource Manager implements the preparation phase and the logic with the commit phase
• How to implement a two-phase commit protocol
• How to implement transaction recovery in exceptional situations

In fact, if you understand these problems, you can implement a two-phase commit distributed transaction model.

X/open dtp--Distributed Transaction model