Two-phase commit

To RRS, a unit of recovery consists of a set of changes that is to be made as one unit. A unit of recovery represents an application program's changes to resources since the last commit or backout. For the first unit of recovery, a unit of recovery represents changes since the beginning of the application. Each unit of recovery is associated with a context. The context consists of the unit of recovery together with the associated application programs, resource managers, and protected resources. A context represents a work request in an application, and the life of a context consists of a series of units of recovery, with zero or one unit of recovery associated with the context at any point in time.

In processing the first record management request of a transaction, DFSMStvs calls RRS to register an interest in a unit of recovery. When an application is ready to commit or back out its changes, the application invokes RRS. The invocation begins either the two-phase commit protocol or the backout of the changes.

The two-phase commit protocol is a set of actions. These actions are used to ensure that an application program makes either all changes to the resources represented by a unit of recovery or makes no changes to the resources. The protocol verifies that the all-or-nothing changes (sometimes called atomic changes) are made even if the application program, the system, RRS, or a resource manager fails. The data sets and the transaction are at a point of consistency based on the data committed with the last sync point, including when DFSMStvs restarts.

The first phase of the commit process is called prepare, the second phase is called commit. The phases of commit processing are described as follows:

Phase 1, prepare

During the prepare phase, the commit coordinator, RRS, invokes the prepare exits of each of the participating resource managers. In these exits, each of the resource managers determine whether they can make the changes permanent during the commit phase. This means that they must keep their backout information until the commit phase, in case they are told to back out the changes.

The process of making the changes permanent is called committing. If all of the resource managers are able to commit their changes, processing continues with the second phase of commit processing. If any of the resource managers is unable to perform the commit function, RRS directs all of the resource managers to back out the unit of recovery.

For data sets that have the forward recovery attribute, backout creates compensating forward recovery records. After a media failure and the restoration of a dated backup copy of the data, forward recovery reapplies all updates since that backup.

Phase 2, commit

In the second phase, the resource managers either commit or back out the changes represented by a unit of recovery, and they release the held locks. When all resource managers have completed the task, the following processing occurs:

The application is notified.
The unit of recovery is completed.
The locks are released.
The two-phase commit protocol ends.

If a batch application is using recoverable and nonrecoverable data sets, a commit does not affect the nonrecoverable data sets. A close or ENDREQs are required to get buffers written and locks released for nonrecoverable data sets.