Brief introduction to Oracle Distributed Transaction concept

As the complexity of the system increases, the distributed systems we face are growing. Distributed file system, distributed Message Queuing system, and so on, in some industries, especially the Internet industry widely used. Distributed DatabaseIt is also one of the most commonly used distributed systems at present.

Simply put, a distributed database is a database organization structure that supports the needs of data access for front-end systems through multiple interconnected database nodes (note not Instance). Each node is independent and self- managing (site Autonomy). The main goals of the distributed database system are: availability (availability), accuracy (Accuray), consistency (concurrence), and recoverability (recoverability).

In some complex system environments spanning multiple departments, multiple data sources, and multiple subsystems, using and organizing distributed databases can be a low-cost and more flexible solution.

1, from the remote Transaction to Distributed Transaction

Database transactions are the core concerns of every DBMS. In a distributed database environment, our transactional objects may span multiple database objects. In order to guarantee the basic transaction rules of acid, the concept of distributed transaction (distributed Transaction) is introduced. First, let's distinguish a few basic types of transactions:

ü local transaction native transaction

The SQL Action Statement Data scope is only limited to the local node.

ü remotely transaction remote transaction

The addition, modification, and deletion of data objects in a transaction are stored on the database at remote remotes . The local database object did not participate in the transaction scope.

ü Distributed transaction Distributed Transaction

The so-called distributed transaction involves the addition, modification, and deletion of local and remote objects in a transactional process.

Note here that the distributed transaction, which we discuss here, is a distributed transaction feature that is implemented through the database's own characteristics. At present, many middleware, such as Jboss, provide middleware-level distributed transaction support. In this case, the middleware will present a distributed transaction management authority to Oracle, and the subsequent transaction management process is delivered to JBoss management. This is not a distributed transaction issue that we are going to discuss today.

2 , transaction object entity

A fully distributed transaction object has several roles, specifically the following types:

ü Client (C) clients: In a distributed transaction, the node object that can obtain the object reference (reference) on the remote database server ;

ü Server (S) servers: A node object that is directly referenced in a distributed transaction, or is requested by another node to obtain data;

ü Global Coordinator (GC) globally coordinated node: is the node that the distributed transaction starts;

ü Local Coordinator (LC) native coordination node: a node object that references data on other nodes to accomplish its own work.

ü commit Point site (CPS) transaction commits the site: The transaction involves the node in the site that has the Commit_point_strength parameter. It is usually one of the most important site objects in a distributed transaction. In the event of a "In-doublt" transaction, the site is not in conflict.

ü commit_point_strength: is an initialization parameter in the Init.ora. Used to determine the CPS site in a distributed environment.

Sql> Show parameter commit_point;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

Commit_point_strength Integer 1

Note that the above-mentioned distributed transactions involve objects, referring to the node roles involved. In the usual distributed transaction, an actual node can act as multiple roles.

3 , two-phase Commit ( two phase submission )

Two-phase commit is a classic transaction model in distributed database system, which is used to solve the problem of the way of transaction submission between multiple database nodes.

The two-phase commit has a total of two phases, namely the preparation phase (Prepare Phase) and the commit phase (commit Phase). A distributed transaction undergoes two stages of process:

ü Preparation stage Prepare Phase

First, the individual nodes involved in the transaction need to determine a commit point site. At the same time, global coordinator sends messages to all other nodes (except commit point site), requiring a distributed commit or rollback action.

as the GC sends messages, the Local coordinators propagates the messages to the nodes on which they depend. Guarantees that messages can be propagated to all node objects involved in a distributed transaction.

For these notified nodes, there are three possible feedback results:prepared, Abort, and Read-only nodes.

Note that if, during this process, the abort process is issued by a node , the entire process is transferred to the global rollback process.

In the feedback results, each node simultaneously sends its own SCN number to the Global coordinator node. GC to determine the largest transaction SCN number in each node .

After the prepared phase, we can enter the commit phase phase. At the end of the prepared phase until the commit phase successfully ended, other transactions except those on commit point site entered the so-called "In-doubt" state.

ü commit phase commit phase

The GC notifies the commit point site to the largest SCN number compared to the comparison. In this case, commit point site commits a commit action or rollback action. Notice that the lock on the CPS is released at this time.

If the CPS succeeds in committing or rollback the action, it notifies the global coordinator at the point in time of submission.

This notification is transmitted through the GC/LC conduction mechanism to all nodes for Commit/rollback action.

If all of the processes are completed successfully, each statement is committed using the same SCN. After that, the RECO process begins a distributed transaction cleanup process, clearing the corresponding information in "dba_2pc_pending" and "dba_2pc_neighbors". After that, each node enters the "Forget" phase and begins to "forget" the transaction information.

ü Forget stage forget phase

When all nodes participating in the distributed transaction have completed the corresponding commit or rollback operation, they will notify the commit point site of the current transaction operation result. Commit Point Site can forget the transaction information.

Each node communication is not directly with the CPS, but with the GC. The GC informs the commit point site of the resulting information and then the CPS clears the information for that transaction.

After the CPS clears the transaction information, it notifies the GC that it already knows the status of the distributed transaction. The GC then knows the transaction information on its own.

4 , conclusions

This article is a pure theory introduction of the article, introduced the Oracle Distributed transaction model content.

Disclaimer: This article has been transferred from http://blog.itpub.net/23890223/viewspace-722195/for learning and use only.

Brief introduction to Oracle Distributed Transaction concept