When multiple resources are to be updated, at a synchronization point OpenTP1 determines whether or not to update the resources in a procedure called a two-phase commit. The two-phase commit separates a commit operation into two phases:

• prepare processing
• commit processing

The prepare processing is preparing to update resources. The commit processing is actually updating the resources. Separating the commit operation into two phases enables multiple resources to be updated without contradiction.

As illustrated in Figure 3-4, in the first phase, at a synchronization point the root transaction branch requests all the transaction branches in the global transaction to prepare for a commit operation. Each transaction branch then notifies the root transaction branch whether it completed preparation for the commit operation or whether it performed a rollback operation.

In the second phase, at the synchronization point OpenTP1 performs a transaction determination to decide whether a commit operation or a rollback operation should be executed on the global transaction:

• If all the transaction branches completed their preparations for the commit operation, the root transaction branch orders a commit operation on the entire global transaction.
• If one or more transaction branches performed rollback operations during the first phase, the root transaction branch orders a rollback operation on the entire global transaction.

All the transaction branches in the global transaction follow the decision of the root transaction branch.

If a system failure occurs after the transaction determination, the history information for the transaction during phase 2 processing is collected into a system journal: the TJ transaction journal.

Figure 3-4 shows the processing for a two-phase commit operation.

Figure 3-4 Processing in a two-phase commit

If a communication error occurs after the root transaction branch instructs the transaction branches to prepare for a commit operation, the root transaction branch's decision of whether to perform a commit or rollback operation might not be sent to the transaction branches. This is called a heuristic hazard.

If a heuristic hazard occurs, the OpenTP1 administrator can use a command (e.g., trncmt, trnrbk, or trnfgt) to forcibly apply the results of a transaction determination to each transaction branch. In a heuristic decision, the results of a transaction determination are applied to an individual transaction branch regardless of the decision of the root transaction branch. In a heuristic commit operation the commit operation is executed for an individual transaction branch. In a heuristic rollback operation the rollback operation is executed for an individual transaction branch.

The OpenTP1 administrator must avoid conflicts between the transaction determination of the root transaction branch and the individual determinations at each transaction branch. To avoid such conflict the user should:

• use the status display command trnls to check whether the transaction determination at the root transaction branch resulted in a decision to perform a commit operation or a rollback operation
• force the transaction branch to perform the same operation (either commit or rollback) that was performed at the root transaction branch.

The user is responsible for any forced determination of a transaction caused by a command such as trncmt, trnrbk, or trnfgt. If a user uses a command to perform a forced determination at a transaction branch, OpenTP1 does not assure the consistency of resources. A conflict between the transaction determination of the root transaction branch and the action at a transaction branch is called a heuristic mix. Users must take care to avoid causing heuristic mixes when using a command to perform a forced determination. Figure 3-5 shows the processing for a heuristic decision.

Figure 3-5 Processing in a heuristic decision