Oracle7 Server Distributed Systems Volume I: Distributed Data

The Session Tree

As the statements in a distributed transaction are issued, Oracle7 defines a session tree of all nodes participating in the transaction. A session tree is a hierarchical model that describes the relationships between sessions and their roles. All nodes participating in the session tree of a distributed transaction assume one or more roles:

a client

a database server

a global coordinator

a local coordinator

the commit point site (see )

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

whether the transaction is local or remote

the commit point strength of that node (see )

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

Figure 5 - 1 below illustrates a simple session tree.

Figure 5 - 1. An example of a Simple Session Tree

Clients

A node acts as a client when it references information from another node's database. The referenced node is a database server. In the above example, the node SALES.ACME.COM is a client of the nodes (database servers) that serve the WAREHOUSE and FINANCE databases.

Servers and Database Servers

A server is a node that is directly referenced in a distributed transaction or is requested to participate in a transaction because another node requires data from its database. A node supporting a database is also called a database server.

In Figure 5 - 1, an application at the node holding the SALES database initiates a distributed transaction which accesses data from the nodes holing the WAREHOUSE and FINANCE databases. Therefore, SALES.ACME.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 is also requesting an update of the SALES database.

Local Coordinators

A node that must reference data on other nodes to complete its part in the distributed transaction is called a local coordinator. In Figure 5 - 1, SALES.ACME.COM, although it happens to be the global coordinator, is also considered a local coordinator because it coordinates the nodes it directly references: WAREHOUSE.ACME.COM and FINANCE.ACME.COM.

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 node

receiving queries from those nodes and passing them on to other nodes

returning the results of queries to the nodes that initiated them

The Global Coordinator

The node where the distributed transaction originates (to which the database application issuing the distributed transaction is directly connected) is called the global coordinator. This node becomes the parent or root of the session tree. The global coordinator performs the following operations during a distributed transaction:

All of the distributed transaction's SQL statements, remote procedure calls, etc. are sent by the global coordinator to the directly referenced nodes, thus forming the session tree.

Figure 5 - 1

The global coordinator instructs all directly referenced nodes other than the commit point site (see below) to prepare the transaction.

If all nodes prepare successfully, the global coordinator instructs the commit point site to initiate the global commit of the transaction.

If there is one or more abort messages, the global coordinator instructs all nodes to initiate a global rollback of the transaction.

For more information about the global coordinator's role, see "A Simple Example"

The Commit Point Site

The job of the commit point site is to initiate a commit or roll back as instructed by the global coordinator. The system administrator always designates one node to be the commit point site in the session tree by assigning all nodes a commit point strength (see below). The node selected as commit point site should be that node that stores the most critical data (the data most widely used)

The commit point site is distinct from all other nodes involved in a distributed transaction with respect to the following two issues:

The commit point site never enters the prepared state. This is potentially advantageous because if the commit point site stores the most critical data, this data never remains in-doubt, even if a failure situation occurs. (In failure situations, failed nodes remain in a prepared state, holding necessary locks on data until in-doubt transactions are resolved.)

In effect, the outcome of a distributed transaction at the commit point site determines whether the transaction at all nodes is committed or rolled back. The global coordinator ensures that all nodes complete the transaction the same way that the commit point site does.

A distributed transaction is considered to be committed once all nodes are prepared and the transaction has been committed at the commit point site (even though some participating nodes may still be only in the prepared state and the transaction not yet actually committed).

The commit point site's redo log is updated as soon as the distributed transaction is committed at that node. Likewise, a distributed transaction is considered not committed if it has not been committed at the commit point site.

Commit Point Strength

Every node acting as a database server must be assigned a commit point strength. If a database server is referenced in a distributed transaction, the value of its commit point strength determines what role it plays in the prepare/commit phases. Specifically, the commit point strength determines whether a given node is the commit point site in the distributed transaction.

This value is specified using the initialization parameter COMMIT_POINT_STRENGTH (see ).

The commit point site is determined at the beginning of the prepare phase. The commit point site is selected only from the nodes participating in the transaction. Once it has been determined, the global coordinator sends prepare messages to all participating nodes.

Of the nodes directly referenced by the global coordinator, the node with the highest commit point strength is selected. Then, the initially-selected node determines if any of its servers (other nodes that it has to obtain information from for this transaction) has a higher commit point strength.

Either the node with the highest commit point strength directly referenced in the transaction, or one of its servers with a higher commit point strength becomes the commit point site. Figure 5 - 2 shows in a sample session tree the commit point strengths of each node (in parentheses) and shows the node chosen as the commit point site.

Figure 5 - 2. Commit Point Strengths and Determination of the Commit Point Site

The following conditions apply when determining the commit point site:

A read-only node (a node which will not change its local data for the transaction) cannot be designated as the commit point site.

If multiple nodes directly referenced by the global coordinator have the same commit point strength, Oracle7 will designate one of these nodes as the commit point site.

If a distributed transaction ends with a rollback, the prepare and commit phases are not needed, consequently a commit point site is never determined. Instead, the global coordinator sends a ROLLBACK statement to all nodes and ends the processing of the distributed transaction.

The commit point strength only determines the commit point site in a distributed transaction. Because the commit point site stores information about the status of the transaction, the commit point site should not be a node that is frequently unreliable or unavailable in case other nodes need information about the transaction's status.

As Figure 5 - 2 illustrates, the commit point site and the global coordinator can be different nodes of the session tree.

The commit point strengths of each nodes is communicated to the coordinator(s) when the initial connections are made. The coordinator(s) retain the commit point strengths of each node they are in direct communication with so that commit point sites can be efficiently selected during prepare/commits. Therefore, it is not necessary for the commit point strength to be exchanged between a coordinator and a node each time a commit occurs.

Specifying the Commit Point Strength of an Instance

Specify a commit point strength for each node that insures that the most critical server will be "non-blocking" if a failure occurs during a prepare/commit phase.

A node's commit point strength should relate to the estimated number of collisions that can result from data locked by in-doubt transactions. For example, mainframe-based database servers will probably have higher commit point strengths than minicomputer-based servers. In turn, minicomputer-based database servers will probably have higher commit point strengths than PC-based database servers. To determine each node's commit point strength, it will be necessary for all administrators of the distributed system to communicate and establish the appropriate values.

A node's commit point strength is set by the initialization parameter COMMIT_POINT_STRENGTH. The range of values is any integer from 0 to 255. For example, to set the commit point strength of a database to 200, include the following line in that database's parameter file:

COMMIT_POINT_STRENGTH=200

Additional Information: See your Oracle operating system-specific documentation for the default value.