Two-Phase Commit Processing › Two-Phase Commit within CA IDMS › Use of Two-Phase Commit

Use of Two-Phase Commit

Two-Phase in Central Version

Central version always uses a two-phase commit protocol to commit resources. When a commit operation initiates within a central version, that system becomes the coordinator. Any other central version involved in the transaction becomes a participant.

Requesting Two-Phase Commit

The DML commands that an application issues to commit tasks and database transactions (for example, FINISH TASK or COMMIT CONTINUE) always initiate a two phase-commit. This ensures that all changes made even by a distributed transaction are either committed or backed out as a single unit. A number of optimizations are supported to minimize overhead, especially for transactions in which only a single resource manager has made changes. See "Commit Optimizations" later in this section for a description of the optimizations supported by CA IDMS.

Support for Pre-Release 16.0 Central Versions

Prior to Release 16.0, CA IDMS did not support a two-phase commit protocol. Such a system is referred to as a "one-phase commit only" resource manager, since it can accept only a single commit request rather than separate Prepare and Commit requests. CA IDMS supports one-phase commit only resource managers in the following way.

If there is a single one-phase commit only participant in a distributed transaction, CA IDMS first sends Prepare requests to all other participants before sending a commit request to the one-phase commit only participant. If this latter request is successful, then the commit operation proceeds to a successful conclusion; otherwise, the transaction is backed out.

If a distributed transaction has multiple one-phase commit only participants, only one of them can be the last one invoked and so there is an unavoidable possibility that the transaction may complete with mixed results, meaning that some changes are committed while others are backed out.

Support for Batch Applications

All changes made by a batch application are committed or backed out as a single unit provided at least one of the following is true:

• All updates are made through a single transaction
• Updates are made through multiple transactions serviced by a single central version and a task-level commit request is issued.
• Batch RRS support is enabled and all updates are made through transactions executing on one or more central versions running within the same operating system image as the batch application.

Note: For more information about RRS, see the CA IDMS System Operations Guide.