Introduction to Distributed Transactions

The task of maintaining database integrity and consistency can be difficult if an application uses more than one database or attachment to a database during a single transaction. To make this task easier, Oracle Rdb uses the two-phase commit protocol provided by DECdtm services. DECdtm services are part of the OpenVMS operating system. (This manual often refers to DECdtm services as DECdtm.)

The two-phase commit protocol coordinates the activity of participants in a transaction to ensure that every required operation is completed before a transaction is made permanent, even if the transaction is a distributed transaction.

A distributed transaction groups more than one database or more than one database attachment together into one transaction, even if the databases are located on different nodes. If one operation in a transaction cannot be completed, none of the operations is completed. This "all or nothing" approach guarantees that databases involved in a distributed transaction remain logically consistent with one another.

The major benefit of using the two-phase commit protocol is that you can create applications that access several different databases without compromising the integrity or consistency of your data.

This chapter describes:

When to use the two-phase commit protocol and distributed transactions
What the two-phase commit protocol and distributed transactions are
What other products you can use with Oracle Rdb in a distributed transaction
How a distributed transaction terminates
How to complete unresolved transactions

1.1 Deciding When to Use Distributed Transactions

Use the two-phase commit protocol when your application starts a distributed transaction. As stated previously, a distributed transaction is a transaction that groups more than one database or more than one database attachment together into one transaction. The following are distributed transactions:

A transaction that attaches more than once to an Oracle Rdb database
A transaction that attaches to more than one Oracle Rdb database
A transaction that attaches to more than one data management system or resource manager that supports DECdtm services

Often, a transaction attaches to more than one database, and the databases are separated geographically. For example, a bank in Switzerland transfers $1,000,000 from a local account to a bank account in the United States. First, the application debits $1,000,000 from the Swiss bank, then it credits $1,000,000 to the U.S. account. Because the transaction involves two different databases, without the two-phase commit protocol this transaction must be committed sequentially. That is, the debit is committed, then the credit is committed. However, if the network connection fails after the application debits the funds from the Swiss account but before it credits the funds to the U.S. account, the bank could lose $1,000,000. With the two-phase commit protocol, if the network connection fails before it credits the funds to the U.S. account, the entire transaction is rolled back.

Without the two-phase commit protocol, keeping remote databases consistent with one another can be difficult. The two-phase commit protocol coordinates the transaction components and ensures consistency among the databases. With the two-phase commit protocol, if the transaction does not complete successfully, the changes to both databases are rolled back.

In another example, an engineering company has a central Oracle CODASYL DBMS database, and also Oracle Rdb databases for each division---the East division and the West division. The central database contains information about employees from both divisions. The Oracle Rdb database for each division contains more detailed information about its employees, but only employees in that division. When an employee joins the company, an application adds the employee to the central database and to either the East or West database. The application performs both operations in one distributed transaction to ensure the information in the central Oracle CODASYL DBMS database remains logically consistent with the information in each division's Oracle Rdb database.

1.2 Using Distributed Transactions with Other Products

In addition to using the two-phase commit protocol with more than one attachment to an Oracle Rdb database, you can use the two-phase commit protocol when you have information in more than one type of data management system. The two-phase commit protocol does not limit you to using only Oracle Rdb databases. An application can start a distributed transaction using an Oracle Rdb database and any resource that implements the two-phase commit protocol using DECdtm services. Products that support the two-phase commit protocol include the following:

Oracle CODASYL DBMS
For information about using Oracle CODASYL DBMS with distributed transactions, see the Oracle CODASYL DBMS documentation.
RMS Journaling
For information about using RMS Journaling with distributed transactions, see the RMS Journaling documentation.

Although products other than database products support DECdtm services' implementation of the two-phase commit protocol, for simplicity, this manual usually describes distributed transactions as operating on one or more databases.

Note
To use the two-phase commit protocol, the DECdtm software must be running on all nodes involved in the transaction.

1.3 Understanding the Two-Phase Commit Protocol and Distributed Transactions

Oracle Rdb uses the two-phase commit protocol to coordinate a distributed transaction and to ensure consistency among databases involved in the transaction. The two-phase commit protocol guarantees that either all changes in the distributed transaction are made, or else none of them is made.

Figure 1-1 illustrates the logic of the two-phase commit protocol.

Figure 1-1 Executing the Two-Phase Commit Protocol

The two-phase commit protocol operates in a distributed transaction environment that includes the following participants:

Resource manager
The resource manager is a database management system, such as Oracle Rdb. The resource manager is responsible for maintaining and recovering its own resources. From the perspective of the application, the resource manager is a single attachment to an Oracle Rdb database. In addition, other products that support the two-phase commit protocol as implemented by DECdtm services can be resource managers.
Transaction manager
The transaction manager coordinates the actions of the resource managers that are located on the same node (local resource managers) as the transaction manager. DECdtm provides the transaction manager. (A transaction manager may also act as the coordinator under specific circumstances.)
Coordinator
The coordinator is the transaction manager on the node where the application started the transaction. The coordinator orchestrates the distributed transaction by communicating with transaction managers on other nodes (remote transaction managers) and with resource managers on the same node (local resource managers). DECdtm provides the transaction manager that acts as coordinator.

Figure 1-2 shows the participants in a distributed transaction that involves databases on three nodes. Oracle Rdb and DECdtm software are installed on all three nodes.
Figure 1-2 Participants in a Distributed Transaction

When your application starts a distributed transaction, the coordinator checks that DECdtm software is running on all the nodes participating in the transaction. (If the DECdtm software is not running, Oracle Rdb returns an error and does not start the distributed transaction.) Then, the coordinator generates a distributed transaction identifier and associates the identifier with all the participants in that particular transaction. Section 2.1 describes this process in more detail.
When the application is ready to commit all the changes to the databases involved in the distributed transaction, all the nodes in the transaction must execute the two phases of the two-phase commit protocol, the preparephase and the commit phase.
During the prepare phase, the coordinator asks each resource manager participating in the transaction whether or not it is prepared to commit the transaction. If the coordinator receives yes responses (or votes) from allthe resource managers, the coordinator instructs the participants in the transaction to enter the commit phase.
During the commit phase, the coordinator instructs the resource managers to make permanent all changes to the database, that is, to commit the changes. Then, the resource managers commit the changes and the transaction is completed.
The next section describes the circumstances under which distributed transactions are committed or rolled back.

1.3.1 Terminating Distributed Transactions

The two-phase commit protocol ensures that if one database involved in a distributed transaction cannot commit the changes, none of the databases involved in the transaction commits the changes.
Table 1-1 summarizes the circumstances under which distributed transactions are committed or rolled back.

**Table 1-1 Committing or Rolling Back Distributed Transactions**
When This Happens:	This Is the Result:
Application instructs the transaction to roll back.	Transaction rolls back.
Process or image failure occurs before all participants vote.	Transaction rolls back.
Any participant votes no.	Transaction rolls back.
All participants vote yes.	Transaction commits.
Process or image failure occurs after all participants have voted and the coordinator has received all yes votes.	Transaction commits.
Process or image failure occurs after all participants have voted and the coordinator has received one or more no votes.	Transaction rolls back.

The two-phase commit protocol coordinates the actions of the individual transaction participants so that either the entire transaction is committed or the entire transaction is rolled back, even if there is a subsequent process or image failure. See Chapter 2 for more information about completing transactions and handling unplanned terminations of transactions.

1.3.2 Completing Unresolved Transactions

On rare occasions, an unexpected failure occurs that causes the coordinator to be unreachable for an extended period of time. For example, the network connection may be lost or the node itself may suffer some irreparable damage. If these situations occur after the participants vote, but before transactions are completed on all nodes, the distributed transaction is unresolved. If you cannot wait for the connection to the coordinator to be restored or if the damage cannot be repaired, you can force the distributed transaction to commit or roll back.
To recover from an unresolved distributed transaction, you use commands provided by the resource manager. For Oracle Rdb databases, you use commands provided by Oracle RMU, the Oracle Rdb management utility.Section 2.4 describes unresolved transactions and Chapter 5 explains in detail how to recover databases from unresolved transactions.

This chapter provided an introduction to the two-phase commit protocol. It described the two-phase commit protocol, when to use it, and how it works. Chapter 2 describes in more detail how the two-phase commit protocol and distributed transactions work.

Kumar's Blog

Monday, November 25, 2013