Filter
Top Products
Product Environment 9-27
Two-Phase Commit and Automatic Recovery
If the participant does not receive contact from the coordinator by the time
specified as TXTIMEOUT (refer to page 9-57), the tbinit process at the partic-
ipant OnLine reads the value of SQLEXEC to fork a new database server
process. (If SQLEXEC is not set, tbinit uses the pathname $INFOR-
MIXDIR
/lib/sqlturbo. The database server process is owned by the user who
started tbinit, either informix or root.)
This server process acts as the new participant. It attempts to determine the
status of the transaction. To do this, it forks a new database server process at
the coordinating 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
rolled back. (This situation is one example of what is meant by presumed-abort
optimization in the two-phase commit protocol.)
The database server process at the participant OnLine rolls back the piece of
work, frees shared-memory resources, and removes the transaction entry
from its shared-memory transaction table. When the database server process
exits, it also removes the database server process at the coordinator OnLine.
If the participant is unable to contact the coordinator or if execution errors are
detected, messages are recorded in the OnLine message log. The transaction
renews its 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.