As the statements in a distributed transaction are issued, the database defines a session tree of all nodes participating in the transaction.

A session tree is a hierarchical model that describes the relationships among sessions and their roles. Figure 34-2 illustrates a session tree:

Figure 34-2 Example of a Session Tree

Description of "Figure 34-2 Example of a Session Tree"

All nodes participating in the session tree of a distributed transaction assume one or more of the following roles:

The role a node plays in a distributed transaction is determined by:

• Whether the transaction is local or remote

• The commit point strength of the node ("Commit Point Site ")

• Whether all requested data is available at a node, or whether other nodes need to be referenced to complete the transaction

• Whether the node is read-only

A node acts as a client when it references information from a database on another node.

The referenced node is a database server. In Figure 34-2, the node sales is a client of the nodes that host the warehouse and finance databases.

A database server is a node that hosts a database from which a client requests data.

In Figure 34-2, an application at the sales node initiates a distributed transaction that accesses data from the warehouse and finance nodes. Therefore, sales.example.com has the role of client node, and warehouse and finance are both database servers. In this example, sales is a database server and a client because the application also modifies data in the sales database.

A node that must reference data on other nodes to complete its part in the distributed transaction is called a local coordinator.

In Figure 34-2, sales is a local coordinator because it coordinates the nodes it directly references: warehouse and finance. The node sales also happens to be the global coordinator because it coordinates all the nodes involved in the transaction.

A local coordinator is responsible for coordinating the transaction among the nodes it communicates directly with by:

• Receiving and relaying transaction status information to and from those nodes

• Passing queries to those nodes

• Receiving queries from those nodes and passing them on to other nodes

• Returning the results of queries to the nodes that initiated them

The node where the distributed transaction originates is called the global coordinator.

The database application issuing the distributed transaction is directly connected to the node acting as the global coordinator. For example, in Figure 34-2, the transaction issued at the node sales references information from the database servers warehouse and finance. Therefore, sales.example.com is the global coordinator of this distributed transaction.

The global coordinator becomes the parent or root of the session tree. The global coordinator performs the following operations during a distributed transaction:

• Sends all of the distributed transaction SQL statements, remote procedure calls, and so forth to the directly referenced nodes, thus forming the session tree

• Instructs all directly referenced nodes other than the commit point site to prepare the transaction

• Instructs the commit point site to initiate the global commit of the transaction if all nodes prepare successfully

• Instructs all nodes to initiate a global rollback of the transaction if there is a terminate response

Unlike a transaction on a local database, a distributed transaction involves altering data on multiple databases. Consequently, distributed transaction processing is more complicated, because the database must coordinate the committing or rolling back of the changes in a transaction as a self-contained unit. In other words, the entire transaction commits, or the entire transaction rolls back.

The database ensures the integrity of data in a distributed transaction using the two-phase commit mechanism. In the prepare phase, the initiating node in the transaction asks the other participating nodes to promise to commit or roll back the transaction. During the commit phase, the initiating node asks all participating nodes to commit the transaction. If this outcome is not possible, then all nodes are asked to roll back.

All participating nodes in a distributed transaction should perform the same action: they should either all commit or all perform a rollback of the transaction. The database automatically controls and monitors the commit or rollback of a distributed transaction and maintains the integrity of the global database (the collection of databases participating in the transaction) using the two-phase commit mechanism. This mechanism is completely transparent, requiring no programming on the part of the user or application developer.

The commit mechanism has the following distinct phases, which the database performs automatically whenever a user commits a distributed transaction:

• Steps in the Commit Phase
  The commit phase in the two-phase commit process includes specific steps.
• Guaranteeing Global Database Consistency
  Each committed transaction has an associated system change number (SCN) to uniquely identify the changes made by the SQL statements within that transaction.

After the participating nodes notify the commit point site that they have committed, the commit point site can forget about the transaction.

The following steps occur:

1. After receiving notice from the global coordinator that all nodes have committed, the commit point site erases status information about this transaction.

2. The commit point site informs the global coordinator that it has erased the status information.

3. The global coordinator erases its own information about the transaction.

The two-phase commit mechanism ensures that all nodes either commit or perform a rollback together. What happens if any of the three phases fails because of a system or network error? The transaction becomes in-doubt.

Distributed transactions can become in-doubt in the following ways:

• A server system running Oracle Database software crashes

• A network connection between two or more Oracle Databases involved in distributed processing is disconnected

• An unhandled software error occurs

The RECO process automatically resolves in-doubt transactions when the system, network, or software problem is resolved. Until RECO can resolve the transaction, the data is locked for both reads and writes. The database blocks reads because it cannot determine which version of the data to display for a query.

• Failure During the Prepare Phase
  An example illustrates the steps that are followed when there is a failure during the prepare phase of a two-phase transaction.
• Failure During the Commit Phase
  An example illustrates the steps that are followed when there is a failure during the commit phase of a two-phase transaction.

In some cases, you must resolve an in-doubt transaction manually.

You should only need to resolve an in-doubt transaction manually in the following cases:

• The in-doubt transaction has locks on critical data or undo segments.

• The cause of the system, network, or software failure cannot be repaired quickly.

Resolution of in-doubt transactions can be complicated. The procedure requires that you do the following:

• Identify the transaction identification number for the in-doubt transaction.

• Query the DBA_2PC_PENDING and DBA_2PC_NEIGHBORS views to determine whether the databases involved in the transaction have committed.

• If necessary, force a commit using the COMMIT FORCE statement or a rollback using the ROLLBACK FORCE statement.

  See Also:

  The following sections explain how to resolve in-doubt transactions:

  • "Deciding How to Handle In-Doubt Transactions"

  • "Manually Overriding In-Doubt Transactions"

A system change number (SCN) is an internal timestamp for a committed version of the database. The Oracle Database server uses the SCN clock value to guarantee transaction consistency.

For example, when a user commits a transaction, the database records an SCN for this commit in the redo log.

The database uses SCNs to coordinate distributed transactions among different databases. For example, the database uses SCNs in the following way:

1. An application establishes a connection using a database link.

2. The distributed transaction commits with the highest global SCN among all the databases involved.

3. The commit global SCN is sent to all databases involved in the transaction.

SCNs are important for distributed transactions because they function as a synchronized commit timestamp of a transaction, even if the transaction fails. If a transaction becomes in-doubt, an administrator can use this SCN to coordinate changes made to the global database. The global SCN for the transaction commit can also be used to identify the transaction later, for example, in distributed recovery.

In this scenario, a company has separate Oracle Database servers, sales.example.com and warehouse.example.com. As users insert sales records into the sales database, associated records are being updated at the warehouse database.

This case study of distributed processing illustrates:

• The definition of a session tree

• How a commit point site is determined

• When prepare messages are sent

• When a transaction actually commits

• What information is stored locally about the transaction

An example illustrates the first stage in distributed transaction processing.

At the Sales department, a salesperson uses SQL*Plus to enter a sales order and then commit it. The application issues several SQL statements to enter the order into the sales database and update the inventory in the warehouse database:

CONNECT scott@sales.example.com ...;
INSERT INTO orders ...;
UPDATE inventory@warehouse.example.com ...;
INSERT INTO orders ...;
UPDATE inventory@warehouse.example.com ...;
COMMIT;

These SQL statements are part of a single distributed transaction, guaranteeing that all issued SQL statements succeed or fail as a unit. Treating the statements as a unit prevents the possibility of an order being placed and then inventory not being updated to reflect the order. In effect, the transaction guarantees the consistency of data in the global database.

As each of the SQL statements in the transaction executes, the session tree is defined, as shown in Figure 34-7.

Figure 34-7 Defining the Session Tree

Description of "Figure 34-7 Defining the Session Tree"

Note the following aspects of the transaction:

• An order entry application running on the sales database initiates the transaction. Therefore, sales.example.com is the global coordinator for the distributed transaction.

• The order entry application inserts a new sales record into the sales database and updates the inventory at the warehouse. Therefore, the nodes sales.example.com and warehouse.example.com are both database servers.

• Because sales.example.com updates the inventory, it is a client of warehouse.example.com.

This stage completes the definition of the session tree for this distributed transaction. Each node in the tree has acquired the necessary data locks to execute the SQL statements that reference local data. These locks remain even after the SQL statements have been executed until the two-phase commit is completed.

An example illustrates the second stage in distributed transaction processing.

The database determines the commit point site immediately following the COMMIT statement. sales.example.com, the global coordinator, is determined to be the commit point site, as shown in Figure 34-8.

Figure 34-8 Determining the Commit Point Site

Description of "Figure 34-8 Determining the Commit Point Site"

An example illustrates the third stage in distributed transaction processing.

The prepare stage involves the following steps:

1. After the database determines the commit point site, the global coordinator sends the prepare message to all directly referenced nodes of the session tree, excluding the commit point site. In this example, warehouse.example.com is the only node asked to prepare.

2. Node warehouse.example.com tries to prepare. If a node can guarantee that it can commit the locally dependent part of the transaction and can record the commit information in its local redo log, then the node can successfully prepare. In this example, only warehouse.example.com receives a prepare message because sales.example.com is the commit point site.

3. Node warehouse.example.com responds to sales.example.com with a prepared message.

As each node prepares, it sends a message back to the node that asked it to prepare. Depending on the responses, one of the following can happen:

• If any of the nodes asked to prepare responds with an abort message to the global coordinator, then the global coordinator tells all nodes to roll back the transaction, and the operation is completed.

• If all nodes asked to prepare respond with a prepared or a read-only message to the global coordinator, that is, they have successfully prepared, then the global coordinator asks the commit point site to commit the transaction.

Figure 34-9 Sending and Acknowledging the Prepare Message

Description of "Figure 34-9 Sending and Acknowledging the Prepare Message"

An example illustrates the fourth stage in distributed transaction processing.

The committing of the transaction by the commit point site involves the following steps:

1. Node sales.example.com, receiving acknowledgment that warehouse.example.com is prepared, instructs the commit point site to commit the transaction.

2. The commit point site now commits the transaction locally and records this fact in its local redo log.

Even if warehouse.example.com has not yet committed, the outcome of this transaction is predetermined. In other words, the transaction will be committed at all nodes even if the ability of a given node to commit is delayed.

An example illustrates the fifth stage in distributed transaction processing.

This stage involves the following steps:

1. The commit point site tells the global coordinator that the transaction has committed. Because the commit point site and global coordinator are the same node in this example, no operation is required. The commit point site knows that the transaction is committed because it recorded this fact in its online log.

2. The global coordinator confirms that the transaction has been committed on all other nodes involved in the distributed transaction.

An example illustrates the sixth stage in distributed transaction processing.

The committing of the transaction by all the nodes in the transaction involves the following steps:

1. After the global coordinator has been informed of the commit at the commit point site, it tells all other directly referenced nodes to commit.

2. In turn, any local coordinators instruct their servers to commit, and so on.

3. Each node, including the global coordinator, commits the transaction and records appropriate redo log entries locally. As each node commits, the resource locks that were being held locally for that transaction are released.

In Figure 34-10, sales.example.com, which is both the commit point site and the global coordinator, has already committed the transaction locally. sales now instructs warehouse.example.com to commit the transaction.

Figure 34-10 Instructing Nodes to Commit

Description of "Figure 34-10 Instructing Nodes to Commit"

An example illustrates the seventh stage in distributed transaction processing.

The completion of the commit of the transaction occurs in the following steps:

1. After all referenced nodes and the global coordinator have committed the transaction, the global coordinator informs the commit point site of this fact.

2. The commit point site, which has been waiting for this message, erases the status information about this distributed transaction.

3. The commit point site informs the global coordinator that it is finished. In other words, the commit point site forgets about committing the distributed transaction. This action is permissible because all nodes involved in the two-phase commit have committed the transaction successfully, so they will never have to determine its status in the future.

4. The global coordinator finalizes the transaction by forgetting about the transaction itself.

After the completion of the COMMIT phase, the distributed transaction is itself complete. The steps described are accomplished automatically and in a fraction of a second.