At any time during a distributed transaction that the database server processes using heterogeneous commit, the coordinator or any number of participants can fail. The database server handles these failures in the same way as in the two-phase commit protocol, except in certain instances. The following sections examine these special instances in detail.
The consistency of data after a coordinator failure depends on the point in the heterogeneous commit process at which the coordinator fails. If the coordinator fails before sending the commit message to the gateway, the entire transaction is stopped upon recovery, as is the case with two-phase commit.
If the coordinator fails after it writes the commit log record, the entire transaction is committed successfully upon recovery, as is the case with two-phase commit.
If the coordinator fails after it sends the commit message to the gateway but before it writes the commit log record, the remote Informix database server sites in the transaction are stopped upon recovery. This can result in inconsistencies if the gateway received the commit message and committed the transaction.
The following table summarizes these scenarios.
| Point of Database Server Coordinator Failure | Expected Result |
|---|---|
| After the coordinator writes the PREPARE log record and before the gateway commit phase | Data consistency is maintained. |
| After the coordinator sends a commit message to the gateway but before it receives a reply | Data is probably inconsistent. No indication of probable data inconsistency from the coordinator. |
| After gateway commit phase but before the coordinator writes a COMMIT record to the logical log | Data consistency is lost. No indication of data inconsistency from the coordinator. |
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 on this procedure, see Participant Failure.
When the database server fails to process a distributed transaction using heterogeneous commit, it returns one of the two error messages that are discussed in the following sections.
If your client application attempts to update data at more than one gateway participant when HETERO_COMMIT is set to 1, the coordinator returns the following error message:
-440 Cannot update more than one non-Informix DBMS within a transaction.
If you receive this error message, rewrite the offending application so that it updates at most one gateway participant in a single distributed transaction.
The database server can fail to commit a distributed transaction while it is using the heterogeneous protocol for one or more of the following reasons:
When such a failure occurs, the coordinator returns the following message:
-441 Possible inconsistent data at the target DBMS name due to an aborted commit.
After the database server sends this message, it rolls back all update sites that are participating in the transaction, with the possible exception of the work done at the site of the gateway participant. The gateway participant might have committed its updates if the failure occurred after the gateway participant processed the commit message. If the gateway participant committed the updates, you must manually rollback these updates.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]