Participant failure
Whenever a participant in a distributed transaction that
uses the heterogeneous protocol fails, the coordinator sends the following
error message:
-441 Possible inconsistent data at the target DBMS name due to an
aborted commit.In addition, the database server
sends the following message to the message log:
Data source accessed using gateway name might be in an inconsistent state.A
participant failure is not limited to the failure of a database server
or gateway. In addition, a failure of the communication link between
the coordinator and the gateway is considered a gateway failure. The
gateway terminates if a link failure occurs. The gateway must terminate
because it does not maintain a transaction log and therefore cannot
reestablish a connection with the coordinator and resume the transaction.
Because of this restriction, some scenarios exist in which a gateway
failure might leave data in an inconsistent state. The following table
summarizes these scenarios.
| Point of participant failure | Expected result |
|---|---|
| After participant receives commit transaction message from coordinator, but before participant performs commit | Data consistency is maintained. |
| After participant receives commit transaction message from coordinator and commits the transaction, but before the participant replies to coordinator | Data is inconsistent. |
| After participant commits the transaction and sends a reply to coordinator | If the communications link fails before the coordinator receives the reply, then data is inconsistent. If the coordinator receives the reply, then data is consistent (provided the coordinator does not fail before writing the COMMIT record). |
The recovery procedure that the database server follows when a participant fails is identical to the procedure that is followed in two-phase commit. For more information about this procedure, see How the two-phase commit protocol handles failures.