Recovering transactions after communications failure
These instructions help you handle transactions performing work on a remote system after communication with that system fails. In case of a communications failure, the system typically completes the resynchronization with any remote system automatically. However, if the failure is catastrophic such that the communications will never be reestablished to the remote system (if, for instance, the communication line is cut), cancel resynchronization and restore transactions yourself. The transactions also might be holding locks that need to be released.
- In iSeries™ Navigator, display commitment control information for the transaction with which you are working.
- Find the transaction of interest that is trying to resynchronize with the remote system. The Resynchronization in Progress field for that transaction is set to yes.
- Look for transactions that had a connection to the remote system by checking the resource Status for individual transactions.
- After identifying transactions, force commit or force rollback depending on the state of the transaction.
- You can make the decision to commit or rollback after you investigate the transaction properties.
- You can use the Unit of Work ID to find other parts of the transaction on other systems.
- You can also determine to commit or rollback from the state of transaction. For example, if a database transaction is performing two-phase commit during communication failure and its state after the failure is "prepared" or "last agent pending", you might choose to force commit on the transaction.
- After forcing a commit or rollback on the transactions in doubt, stop resynchronization on the failed connection for the identified transactions.
Parent topic:
Troubleshooting transactions and commitment control
Related tasks
Displaying commitment control information
When to force commit and rollback operations and when to cancel resynchronization