What is commit and rollback?

In transaction systems, commit and rollback refers to the set of actions used to ensure that an application program either makes all changes to the resources represented by a single unit of recovery (UR), or makes no changes at all. The two-phase commit protocol provides commit and rollback. It verifies that either all changes or no changes are applied even if one of the elements (like the application, the system, or the resource manager) fails. The protocol allows for restart and recovery processing to take place after system or subsystem failure.

The two-phase commit protocol is initiated when the application is ready to commit or back out its changes. At this point, the coordinating recovery manager, also called the syncpoint manager, gives each resource manager participating in the unit of recovery an opportunity to vote on whether its part of the UR is in a consistent state and can be committed. If all participants vote YES, the recovery manager instructs all the resource managers to commit the changes. If any of the participants vote NO, the recovery manager instructs them to back out the changes. This process is usually represented as two phases.

In phase 1, the application program issues the syncpoint or rollback request to the syncpoint coordinator. The coordinator issues a PREPARE command to send the initial syncpoint flow to all the UR agent resource managers. In response to the PREPARE command, each resource manager involved in the transaction replies to the syncpoint coordinator stating whether it is ready to commit or not.

When the syncpoint coordinator receives all the responses back from all its agents, phase 2 is initiated. In this phase the syncpoint coordinator issues the commit or rollback command based on the previous responses. If any of the agents responded with a negative response, the syncpoint initiator causes all of the syncpoint agents to roll back their changes.

The instant when the coordinator records the fact that it is going to tell all the resource managers to either commit or roll back is known as the atomic instant. Regardless of any failures after that time, the coordinator assumes that all changes will either be committed or rolled back. A syncpoint coordinator usually logs the decision at this point. If any of the participants abnormally end (or abend) after the atomic instant, the abending resource manager must work with the syncpoint coordinator, when it restarts, to complete any commits or rollbacks that were in process at the time of the abend.

On z/OS®, the primary syncpoint coordinator is called Resource Recovery Services (RRS). Also, the IBM® transaction manager product, CICS®, includes its own built-in syncpoint coordinator.

During the first phase of the protocol, the agents do not know whether the syncpoint coordinator will commit or roll back the changes. This time is known as the indoubt period. The UR is described as having a particular state depending on what stage it is at in the two-phase commit process:

Before a UR makes any changes to a resource, it is described as being In-reset.
While the UR is requesting changes to resources, it is described as being In-flight.
Once a commit request has been made (Phase 1), it is described as being In-prepare.
Once the syncpoint manager has made a decision to commit (phase 2 of the two-phase commit process), it is In-commit.
If the syncpoint manager decides to back out, it is In-backout.

Figure 1 illustrates the two-phase commit.

Figure 1. Two-phase commit

Most widely used transaction management systems on z/OS, such as CICS or IMS™, support two-phase commit protocols. CICS, for example, supports full two-phase commit in transactions with IMS and the DB2® database management system, and supports two-phase commit across distributed CICS systems.

There are many restrictions imposed on application developers attempting to develop new applications that require updates in many different resource managers, perhaps across a number of systems. Many of these new applications use technologies like DB2 stored procedures and Enterprise Java™ Beans, and use client attachment facilities of CICS or IMS that do not support two-phase commit. If any of these resource managers are used by an application to update resources, it is not possible to have a global coordinator for the syncpoint.

The lack of a global syncpoint coordinator might influence an application design for the following reasons:

The application is not capable of having complex and distributed transactions if not all of the resource managers are participating in the two-phase commit protocol.
The application cannot be designed as a single application (or unit of recovery) across multiple systems (except for CICS).

The application programmer would have to program around these limitations. For example, the programmer could limit the choice of where to put the business data to ensure that all the data could be committed in a single unit of recovery.

Also, these limitations could affect the recoverability of the protected resources or their integrity in case of a failure of one of the components, because resource managers have no way to either commit or roll back the updates.