Two-phase commit process

In a distributed system, the actions of a logical unit of work might occur at more than one system.

When these actions update recoverable resources, the commit process ensures that either all the effects of the logical unit of work persist, or none of the effects persist. The commit process ensures this outcome despite component, system, or communications failures.

Db2 uses a two-phase commit process to communicate between subsystems. The two-phase commit process is controlled by one of the subsystems, called the coordinator. The other systems that are involved are called the participants. Db2, CICS®, or WebSphere® Application Server are always the coordinator when they interact with Db2. In transactions that include those systems, Db2 is always a participant. Db2 is always the coordinator when it interacts with TSO, and Db2 completely controls the commit process in these interactions. In interactions with other DBMSs, including other Db2 subsystems, your local Db2 can be either the coordinator or a participant.

The following figure illustrates the two-phase commit process. Events in the coordinator (IMS, CICS, or Db2) are shown on the upper line, events in the participant on the lower line.
Figure 1. Time line illustrating a commit that is coordinated with another subsystem
Begin figure description. This figure is a time line that depicts the actions that a coordinator subsystem and a participant subsystem take in coordinated commit. End figure description.

The numbers below are keyed to the timeline in the figure. The resultant state of the update operations at the participant are shown between the two lines.

  1. The data in the coordinator is at a point of consistency.
  2. An application program in the coordinator calls the participant to update some data, by executing an SQL statement.
  3. This starts a unit of recovery in the participant.
  4. Processing continues in the coordinator until an application synchronization point is reached.
  5. The coordinator then starts commit processing. IMS can do that by using a DL/I CHKP call, a fast path SYNC call, a GET UNIQUE call to the I/O PCB, or a normal application termination. CICS uses a SYNCPOINT command or a normal application termination. A Db2 application starts commit processing by an SQL COMMIT statement or by normal termination. Phase 1 of commit processing begins.
  6. The coordinator informs the participant that it is to prepare for commit. The participant begins phase 1 processing.
  7. The participant successfully completes phase 1, writes this fact in its log, and notifies the coordinator.
  8. The coordinator receives the notification.
  9. The coordinator successfully completes its phase 1 processing. Now both subsystems agree to commit the data changes because both have completed phase 1 and could recover from any failure. The coordinator records on its log the instant of commit—the irrevocable decision of the two subsystems to make the changes.

    The coordinator now begins phase 2 of the processing—the actual commitment.

  10. The coordinator notifies the participant that it can begin phase 2.
  11. The participant logs the start of phase 2.
  12. Phase 2 is successfully completed, which establishes a new point of consistency for the participant. The participant then notifies the coordinator that it is finished with phase 2.
  13. The coordinator finishes its phase 2 processing. The data that is controlled by both subsystems is now consistent and available to other applications.

On some occasions, the coordinator invokes the participant when no participant resource has been altered since the completion of the last commit process. This can happen, for example, when a SYNCPOINT is issued after performance of a series of SELECT statements or when end-of-task is reached immediately after a SYNCPOINT is issued. When this occurs, the participant performs both phases of the two-phase commit during the first commit phase and records that the user or job is read-only at the participant.