Oracle distributed transactions and two phase commit (2PC)

Distributed transactions are transactions that occur between multiple databases, and in Oracle, transactions are handled in a dblink manner, and distributed transactions are much more complex than stand-alone transactions. Most relational databases complete distributed transactions through two-phase commit (2 Phase commit 2PC) algorithms, and the following 2PC algorithms are highlighted below.

1, the composition of distributed transactions

In distributed transactions, there are several main components:

Client: A node that invokes other database information

Database: Accepting nodes from other node requests

Global Coordinator (GC): A node that initiates a distributed transaction

Local Coordinator (LC): A node that deals with native transactions and communicates with other nodes

Commit Point Site (CPS): A node that is specified by global coordinator to first commit or roll back a transaction

In a distributed transaction, the Commit point site is important, it does not need to enter the prepared state of 2PC, because it usually operates the most critical data, so it does not appear in-doubt state. The commit point site always takes precedence over the other database nodes in order to protect the most critical data, which determines whether the entire distributed transaction is committed or rolled back. Other database nodes in a distributed transaction are subsequently submitted (or rolled back) under the command of the GC.

So how do you choose Commit Point site in Oracle? It is based on the parameter Commi_ point_strength largest database as a commit point Site.

2, two-stage submission (2PC)

The two-stage commit protocol can guarantee the strong consistency of data, and many distributed relational data management systems use this protocol to complete the distributed transaction. It is a distributed algorithm that coordinates all distributed atomic transaction participants and decides to commit or cancel (rollback). It is also the algorithm to solve the consistency problem. This algorithm can solve many temporary system faults (including process, network node, communication, etc.) and is widely used. However, it cannot be configured to solve all failures, and in some cases it requires human involvement to solve the problem.

As the name suggests, two-stage submissions are divided into the following two phases:

1) Prepare Phase (Prepare node)

2 Commit Phase (Submission phase)

1) Prepare Phase

During the request phase, the coordinator notifies the transaction participant to commit or cancel the transaction and then enters the voting process. During the voting process, participants will inform the coordinator of their own decision: consent (the transaction participant's local job execution succeeds) or cancel (local job execution failure).

In order to complete the prep phase, other database nodes, except for the commit point site, follow these steps:

Each node checks whether it is referenced by another node, and if so, notifies the nodes that they are ready to commit (entering the prepare phase).

Each node checks its own running transaction, and if it finds that the locally running transaction does not have the action to modify the data (read-only), skip the subsequent steps and return a read only to the global coordinator.

If the transaction needs to modify the data, the transaction is assigned the appropriate resources to ensure that the modification is normal.

When the above work is successful, return the ready information to the global coordinator and, conversely, return the failed information.