Coordinator Applications for a Two-phase Commit
To use a two-phase commit, coordinator applications are used. The coordinator application is responsible for:
• Generating a unique distributed transaction ID for each distributed transaction, and passing this ID to each concerned local DBMS.
• Performing the necessary logging and recovery tasks to handle any failure occurring during the transaction processing. This includes logging the following information:
• Distributed transaction IDs
• The states of all the slave transactions
If the connection between a coordinator application and a local DBMS breaks while a distributed transaction is still open, the action taken by the local recovery process depends on the state of the local transaction associated with the distributed transaction:
• If the local transaction is not in a willing commit state, the local DBMS aborts the transaction.
• If the local transaction is in a willing commit state, the local transaction is not aborted until the connection is re-established by the coordinator application and the transaction is committed or rolled back.
If the connection between a coordinator application and a local DBMS breaks, use the CONNECT statement to re-establish the connection with the local DBMS and transaction. If the local DBMS has rolled back the local transaction associated with the distributed transaction, the DBMS returns an error statement indicating this when issuing the CONNECT statement. Otherwise, after reconnecting, a COMMIT or a ROLLBACK statement can be issued to close the transaction.
If a local DBMS encounters a log file full condition and the oldest transaction is a local transaction that is associated with a distributed transaction and is in the willing commit state, the local logging system does not abort the local transaction. Normally the logging system aborts the oldest transactions first. For details about transaction logging, see the Database Administrator Guide.
Last modified date: 08/28/2024