About distributed transactions II: Distributed Transaction Management Model Based on DTC [Part II]

Document directory

• 1. Phase 1 (Phase I): preparation (Prepare)
• 2. Phase 2 (Phase II): Commit or Abort)
• 3. Handling of pending (In-Doubt) Transactions
• 4. Single-Phase Commit (SPC: Single-Phase Commit) Optimization

[Part 1] When LTM-based or KTM-based transactions are upgraded to DTC-based distributed transactions, DTC becomes the manager of all transaction resource managers on the local machine. In addition, when a transaction operation exceeds the scope of the local machine and a cross-machine call occurs, the local DTC needs assistance from the DTC of the machine where the caller is located. The upper-level management of the lower-level (including the local DTC to all the resource managers of the local machine, as well as the upper-level DTC) is provided that the lower-level register at the upper-level, that is, the Transaction registration (Transaction Enlist ). All transaction participants, including all resource managers and transaction managers (that is, DTC), form a tree-like hierarchy after transaction levels are completed, the formation of this structure is possible for subsequent transactions, so we call it the Transaction Commit Tree ). I. Transaction Enlisting and Transaction Commit Tree)

The purpose of transaction registration is to establish the relationship between transaction participants (as long as the resource manager and Transaction Manager DTC) and promote collaboration between them. Let's take a look at how the entire transaction registration is conducted. The entire transaction registration process is roughly as follows:Figure 1.

Figure 1 transaction registration process

Figure 1The transaction shown in involves the interaction between the deployment and the two services on Machine A and Machine B. The transaction is initialized by the Service and is propagated to Machine B when Service2 is called, in this way, the resource manager distributed on two machines is incorporated into the same transaction. Next, we will introduce the entire process in detail.

First, Service A starts A new Transaction and runs the environment Transaction (Ambient Transaction) in the most context ). When Service A calls the local resource manager, it will include the resource manager in this transaction (for the System we will introduce later. transactions, such as SQL Server, Oracle, MSMQ, and other resource managers can automatically perceive the current environmental Transactions ). At this time, the Resource Manager (RM) registers transactions with the local DTC, and establishes a parent-child relationship between the DTC and the resource manager.

When Service A calls Service B, it encapsulates some information about the current transaction, such as the ID of the distributed transaction and information about the local DTC in the message (generally the SOAP header) to the other party. When Service B receives the Service call request message, it extracts the transaction-related information and reconstructs the transaction locally as the current environmental transaction, the transaction has the same ID as the original transaction. At the same time, according to the obtained information about the DTC of Machine A, let the local DTC register the DTC of Machine A, and then let the DTC of the two machines establish the parent-subordinate relationship.

Like the resource manager that Service A accesses to the local Machine, the resource manager of Machine B is called by Service B and incorporated into the current transaction, and registers the transaction with the local DTC.

After the transaction registration process described above is complete, the DTC and resource manager involved in the entire Distributed Transaction FormFigure 2As shown in the Tree hierarchy, because the structure is mainly built for the end of the Commit service for the entire Transaction, we generally call it the Transaction Commit Tree ). The root of the transaction Commit tree is the DTC of the machine where the transaction initialization service is located. Throughout the transaction Commit process, it is the overall Coordinator, also known as the Global Commit Coordinator (GCC: Global Commit Coordinator ). The resource manager acts as the leaf node of the transaction commit tree. Its parent node is the local DTC. DTC distributed on different machines forms a parent-child relationship according to the path of transaction propagation.

Figure 2 transaction commit tree

The construction of the transaction commit tree makes it possible to commit distributed transactions. The commit of distributed transactions is implemented using the two-phase protocol. Next we will introduce the transaction commit mechanism based on the two-phase commit protocol in detail.

Ii. transaction Commit mechanism based on the Two-Phase Commit (2 PC: Two-Phase Commit) Protocol

Unlike local transactions based on a single resource manager, implementing a distributed transaction involving multiple resource managers in a distributed environment is much more troublesome to implement the four attributes of ACID in transactions. When the transaction initializes the service (the application or component, which is called the service for better closeness to WCF) to complete all related operations, it is decided to submit the transaction. For the commit of distributed transactions, there are two final results: If all operations can be completed smoothly, the persistent data needs to be written to the target resource by the corresponding resource manager; if any stage fails, all persistent resource managers restore data to the original state. The entire Commit process of distributed transactions is completed using the Two-Phase Commit (2 PC: Two-Phase) Commit protocol. As the name implies, "two-phase commit" means that the entire transaction commit phase is divided into two phases. Now we will detail what we are doing in these two phases.

Note:Before the transaction initialization service decides to commit the transaction, any participant can Abort the transaction. the suspension of the transaction by any participant will lead to the rollback of the entire distributed transaction.

1. Phase 1 (Phase I): preparation (Prepare)

In the first phase, the DTC as the root node initiates a request to all transaction participants along the path of the transaction commit tree and requires them to vote on the results of the local transaction. The requested participant returns the local transaction result to his superiors. For the resource manager, his superiors are the local DTC. If he or she is a DTC, the parent node is the DTC at the parent node of the transaction commit tree. Based on the execution of specific transaction operations, participants can vote for the following types:

• Ready (Prepared ):The participants agree to commit the transaction and promise to complete the local commit task after receiving the real submit request;
• Read-only ):The participant agrees to commit the transaction, but does not want to receive real transaction commit requests;
• Abort (Aborted ):The participant requested to abort the transaction.

For a non-root node DTC, when it receives a standard "prepare" Request from the parent node, the request is immediately sent along the transaction commit tree to its sub-level (the local resource manager and the sub-level DTC), and the voting result is calculated based on all the voting results received from the sub-level. The specific algorithm is: if all the voting results are "ready" and "read-only", the corresponding result is "submitted". If any voting result is "aborted ", the final result is "suspension". In other words, any transaction participant has a one-vote veto. Finally, DTC sends the calculated voting results to its superiors.

When the root node DTC receives the voting results of all its own resource managers and lower-level DTC, the final result of the entire distributed transaction is determined using the same algorithm as above. After the root node DTC determines the final result of the transaction, the entire commit process enters the second stage.

Note:We can set the transaction timeout period. If the root node DTC does not introduce the voting requests of all participants within the time limit, the entire distributed transaction will be rolled back.

2. Phase 2 (Phase II): Commit or Abort)

As the root node of the transaction commit, DTC performs the final commit or stop operation on the entire transaction based on the final transaction result. Similarly, the commit or stop request is broadcast along the path of the transaction commit tree. The corresponding resource manager implements the final submission or recovery operations based on the request obtained from the local DTC. After the transaction participants complete their respective tasks, similar to the voting in the first stage, the execution results will be reversely fed back to the DTC as the root node along the transaction commit tree.

The root node DTC can ensure that the entire transaction is successfully committed or rolled back only when it receives responses from all transaction participants based on the respective transaction processing. What if the transaction participants finish the first-stage voting and the network is disconnected? This involves processing pending (In-Doubt) transactions.

3. Handling of pending (In-Doubt) Transactions

For participants of a distributed transaction (DTC or resource manager), after the first stage of voting to the upper-level (parent node of the transaction commit tree) indicates that the transaction is committed (Prepared, it does not know the results of local transactions until it receives the final commit or rollback request from the root node DTC. During this period, if the server crashes and the service is restarted, the local service is In an In-Doubt status. Pending transactions only appear on the machine where the non-root node DTC is located. Distributed transactions use the following mechanism to process pending transactions.

After the restart, for all pending transactions on the local machine, DTC will send a query request to the upper-level DTC to obtain the final result of each transaction (submit or stop ). If the upper-level cannot determine the transaction result, the request will be continuously sent along the transaction commit tree (along the root direction) until a clear response is obtained (no matter what, the global commit coordinator at the root node always knows the transaction result ).

In addition, when the lower-level DTC sends the same query request to itself, the DTC will return the obtained results to them. If a pending transaction exists for too long, the system administrator can forcibly commit or stop the transaction.

4. Single-Phase Commit (SPC: Single-Phase Commit) Optimization

For decision makers whose final transaction result (commit or stop), if it has more than one subordinate, the only choice for a two-phase commit protocol based on the voting mechanism is adopted. But if there is only one subordinate, this voting mechanism is unnecessary. In this case, the root node DTC uses an optimized protocol to Commit the entire transaction. We call it a Single-Phase Commit (SPC: Single-Phase Commit ).

As the name suggests, 2 PC means that the entire transaction commit is divided into two stages, while SPC means that it is shortened to one stage. The entire process is very simple. If the root node DTC only has one registered transaction participant (the local resource manager or the lower-level DTC), no matter the lower-level itself has several lower-level, it does not send a "prepare" request to the lower-level like a 2 PC, but directly sends a submit request. We make this request a single-phase commit (SPC) request. The participant who receives the SPC request. If it is the resource manager, the local transaction is committed directly, and the final result (successful submission or failed suspension) is reported to the node DTC.

If the recipient of the SPC request is DTC, the corresponding submission policy is selected based on the number of its subordinates. The specific method is the same as that of the root node DTC submission policy: If you have a unique sub-level, you can use SPC, and vice versa, you can use 2 pcs.

That is to say, not only root node DTC can select SPC to commit transactions, but any DTC with a single lower level can adopt SPC. However, a non-root node DTC can select to submit a transaction through SPC only when it receives a SPC request. For exampleFigure 3Two transaction commit trees are provided (the resource manager is ignored in the figure, and each node represents DTC). For the left Tree, because the root node A and lower-level B have only one unique lower-level, therefore, both A and B adopt SPC. C has two sub-levels, and 2 PC is used. For the tree on the right, because the root node itself has two sub-levels, it determines that all nodes adopt 2 pcs, even for B and C with only one sub-level.

 Figure 3 selection of SPC and 2 PC by DTC 

We will introduce the DTC-based Distributed Transaction Management Model for the entire Windows platform. In the next article, I will introduce the programming of System. Transactions-based Transactions in detail.

 

Distributed Transaction series:
Talk about one of distributed transactions: What transaction control methods does SOA need?
Talk about distributed transactions II: Distributed Transaction Management Model Based on DTC [Part 1]
About distributed transactions II: Distributed Transaction Management Model Based on DTC [Part II]
Distributed Transaction 3: System. Transactions transaction details [Part 1]
About Distributed Transaction 3: System. Transactions transaction details [Part II]

Author: Artech
Source: http://artech.cnblogs.com
The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.