IBM 000-8697 사용자 설명서

Product Environment

If the coordinator database server process fails before it makes a decision or
after it decides to roll back a transaction, it is up to each participant OnLine
to initiate automatic recovery. This responsibility is part of the presumed-
abort optimization.

Optimization is realized because the coordinator is not required to flush the
logical log record

(BEGPREP

) that indicates a two-phase commit protocol has

begun. This logical log can be buffered, which represents the most significant
part of the streamlined processing. (Refer to

for more information

about the logical log records written and flushed during the two-phase
commit protocol.)

To a lesser extent, message traffic is reduced because the coordinator receives
acknowledgment only when a transaction commits. Participants do not
acknowledge rollbacks.

Manual two-phase commit recovery is needed whenever the protocol is
interrupted by an action that is independent of, and in opposition to, the
decision that the coordinator would reach. Manual recovery is an extremely
complicated administrative procedure and should be avoided.

Independent action during a two-phase commit protocol is rare, but it can
occur in four specific situations:

■

The participant’s piece of work develops into a long-transaction
error and is rolled back by the executing database server process.

■

An administrator kills a participant database server process during
the postdecision phase of the protocol using tbmode -z.

■

An administrator kills a participant transaction (piece of work)
during the postdecision phase of the protocol using tbmode -Z.

■

An administrator kills a global transaction at the coordinator OnLine
server using tbmode -z or tbmode -Z after the coordinator issued a
commit decision and became aware of a participant failure. (This
action always results in an error, specifically error -716. Refer to

.)