Product Environment 9-29

Independent Action and Manual Recovery

Presumed-Abort Optimization

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.
Optimizationis realized because the coordinator is not required to flush the
logicallog record (BEGPREP) that indicates a two-phase commit protocol has
begun.This logical log can be buffered, which represents the most significant
partof the streamlined processing. (Refer to page 9-44 for more information
about the logical log records written and flushed during the two-phase
commit protocol.)
Toa lesser extent, message traffic is reduced because the coordinatorreceives
acknowledgment only when a transaction commits. Participants do not
acknowledge rollbacks.
Independent Action and Manual Recovery
Manual two-phase commit recovery is needed whenever the protocol is
interrupted by an action that is independent of, and in opposition to, the
decisionthat 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 usingtbmode -z.
■An administrator kills a participant transaction (piece of work)
during the postdecision phase of the protocol usingtbmode -Z.
■Anadministrator kills a global transaction at the coordinator OnLine
server using tbmode -zor tbmode -Z after the coordinator issued a
commit decisionand became aware of a participant failure. (This
action always results in an error, specifically error -716. Refer to
page 9-43.)