Automatic-recovery mechanisms for participant failure
Participant recovery occurs whenever a participant thread precommits an item of work that is terminated before the two-phase commit protocol can be completed. The goal of participant recovery is to complete the two-phase commit protocol according to the decision reached by the coordinator.
Participant recovery is driven by either the coordinator or the participant, depending on whether the coordinator decided to commit or to roll back the global transaction.
Important: To support automatic recovery after a subordinate
server is shut down or restarted while a cross-server transaction
is open, the sqlhosts file must include an entry
for every database server from which distributed operations might
be initiated. During automatic recovery, the name of the coordinator
is recovered from the logical logs, and the subordinate server reconnects
with the coordinator to complete the transaction. Because the coordinator
always identifies itself to the participants using the name that is
in the DBSERVERNAME configuration parameter in its own onconfig file,
the DBSERVERNAME setting of the coordinator must be an Internet protocol
connection name known to the participants, but you can also define
at least one DBSERVERALIASES setting with the correct connection protocol
for connectivity between the coordinator and the subordinate servers.
The subordinate server must be able to connect to the coordinator
using either the DBSERVERNAME setting or a DBSERVERALIASES setting
of the coordinator.