The unit of recovery changes from state to state throughout the course of the two-phase commit protocol. Figure 1 shows the flow of the two-phase commit process. In the first in-reset state, the application is at the start of its unit of recovery and has not used any protected resources. When protected resources are accessed for add, delete or update, the unit of recovery moves into the in-flight state with the resource manager expressing interest in the unit of recovery. Once the application issues its commit, the in-prepare state is entered. Phase one begins when the syncpoint manager tells each resource manager to prepare its resources to move forward or backward. When all resource managers reply positively, the unit of recovery transitions to the in-commit state and phase 2 begins. The syncpoint manager tells each resource manager to make its changes permanent.

When all resource managers have completed the task, the application is notified, the unit of recovery is completed, and the two-phase commit protocol ends. The application might have altered protected resources using multiple resource managers (for example, DB2®, IMS™, and DFSMStvs) within a recoverable unit of work.

The protocol also has provisions if a resource manager replies negatively to the prepare notification. In this case, the in-commit state becomes an in-backout state, and resource managers are told to back out any changes.

Figure 1. Two-phase commit processing actions