IBM 000-8697 User Manual

Product Environment

Within a client/server network, the identity of the coordinator OnLine is
dynamic. In any transaction that includes multiserver modifications, the role
of coordinator is assumed by the OnLine database server that is managing
the current database. Thus, if the first statement in the

 example

were changed to specify the current database as stores5@france, the two-
phase commit protocol would assign the role of coordinator to france.
However, the role of the coordinator cannot change during a single trans-
action. The coordinator for a transaction is displayed in the transaction
coordinator field of the tbstat -u output. (Refer to

.)

Transactions that include multiserver modifications use the two-phase
commit protocol to achieve two goals:

■

Ensure that all participating OnLine database servers receive the
same instruction from the coordinator, either to commit or to roll
back a transaction

■

Ensure that all participating OnLine database servers implement the
same action, regardless of local or network failures during the
protocol

The two-phase commit protocol occurs in three steps. First is the precommit
phase, in which the coordinator directs each participant database server to
prepare to commit the transaction.

The second step is the coordinator decision. After the coordinator directs the
participants to prepare to commit, it waits until it receives a response from
each participating OnLine server, indicating whether or not the participant
can commit the transaction. After all the responses are received, the coordi-
nator makes its decision whether or not to commit the transaction.

If every participant indicates it can commit the modifications, the coordinator
decides to commit the transaction. If any participant is unable to precommit
the modifications, the coordinator decides to roll back the transaction. The
decision marks the end of the second step and the beginning of the third step
of the protocol, the postdecision phase.