Product Environment 9-27
Two-Phase Commit and Automatic Recovery
If the participant does not receive contact from the coordinator by the time
specifiedas TXTIMEOUT (refer to page 9-57), the tbinit process at the partic-
ipant OnLine reads the value ofSQLEXEC to fork a new database server
process. (IfSQLEXEC is not set, tbinit uses the pathname$INFOR-
MIXDIR/lib/sqlturbo.The database server process is owned by the user who
startedtbinit, either informix or root.)
This server process acts as the new participant. It attempts to determine the
statusof the transaction. To do this, it forks a new database server process at
thecoordinating OnLine. (To do this, an sqlexecd process must be running at
the coordinator OnLine.)
A message is sent from the database server at the participant OnLine to the
database server at the coordinator OnLine. If the state of the transaction is
“unknown,” meaning no entry exists in the coordinator OnLine shared-
memory transaction table, the participant assumes that the transaction was
rolledback. (This situation is one example of what is meant by presumed-abort
optimization in the two-phase commit protocol.)
Thedatabase server process at the participant OnLine rolls back the piece of
work, frees shared-memory resources, and removes the transaction entry
fromits shared-memory transaction table. When the database server process
exits, it also removes the database server process at the coordinator OnLine.
Ifthe participant is unable to contact the coordinator or if execution errors are
detected,messages are recorded in the OnLine message log. The transaction
renewsits waiting for another period of time specified by TXTIMEOUT. When
the specified time has again elapsed,tbinit spawns another database server
process and the procedure repeats.