Journaling Procedures › Journal Files › Two-Phase Commit Journaling

Two-Phase Commit Journaling

Journaling and Two-Phase Commit

Journaling is integral to the two-phase commit process. As a distributed transaction progresses through the commit process, distributed checkpoint records are written to the journal file to record its changing state. These checkpoints are used in the event of a system failure to rebuild incomplete transactions so that they can be completed through a process of resynchronization with other systems.

Note: For a complete discussion of two-phase commit within CA IDMS, see Chapter 20, “Two-Phase Commit Processing".

Distributed Checkpoints

The following distributed checkpoints can be written in support of a two-phase commit operation:

• DIND (In doubt) - Written by a participant after it has successfully prepared its resources for commit and prior to returning an OK response to its coordinator.
• DCOM (Commit) - Written by a coordinator to signify that a transaction's changes will be committed. Its existence separates the first and second phases of the commit process. A participant also writes a DCOM immediately upon receiving a Commit request from its coordinator.
• DBAK (Backout) - Written by a coordinator to signify that a transaction's changes will be backed out. Its existence demarcates the first and second phases of the commit process. A participant also writes a DBAK immediately upon receiving a Backout request from its coordinator, but only if a DIND had been previously written.
• DPND (Pending) - Written by a coordinator during the second phase of a commit operation if some participant is unable to complete its commit processing due to a failure. By writing this record, the coordinator is able to forget some participants while remembering others. It is also written to record the heuristic completion of a transaction.
• DFGT (Forget) - Written by coordinators and participants when they have completed their two-phase commit processing for a transaction. A DFGT record is written only if some other distributed checkpoint record was previously written.

Each distributed checkpoint contains a distributed transaction identifier (DTRID), a 16-byte value assigned by CA IDMS to uniquely identify a distributed transaction across all participating systems.

Relating Local and Distributed Journal Entries

BGIN, COMT, ENDJ and ABRT checkpoints and BFOR and AFTR journal entries log work done by a transaction branch within the local system. They contain a 4-byte local identifier (LID) that uniquely identifies this work. To associate work done locally with a distributed transaction, DIND, DCOM and DBAK checkpoints contain a list of LID values representing the local work units that are part of the distributed work unit.

The following illustrates the sequence in which local and distributed journal records may be written to a journal file for a distributed transaction:

• BGIN - indicating the start of work done locally
• BFOR/AFTR - one or more pairs
• DIND - on a participant only
• DCOM or DBAK - on a participant and a coordinator
• COMT or ENDJ - if a DCOM was written
• ABRT - if a DBAK was written
• DPND - on a coordinator if the commit operation was interrupted; on a participant if the transaction was heuristically completed
• DFGT - on a participant and a coordinator if any other distributed checkpoint was written

Participants and Coordinators

DIND, DCOM, DBAK and DPND records also contain information about a participant's coordinator and about a coordinator's participants. The specific information that is recorded varies depending on the type of the coordinator or participant. For example, the node name, resource name, and remote transaction branch identifier are recorded for CA IDMS participants. The RRS URID (Unit of Recovery Identifier) is recorded for an RRS coordinator or participant.

Splitting Distributed Checkpoints

Distributed checkpoint records can be larger than a single disk journal block. If this is the case, they are split into as many journal blocks as are necessary to hold the entire record. It is also possible for a distributed checkpoint to be split across disk journal files and, hence, across archive files. The manual recovery utilities reassemble the record, provided that all necessary archive files are processed in a single execution of the utility. They ignore partial records in which not all segments are present in the input file.