You can use instructions in this topic to handle transactions performing
work on a remote system after the 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), you
must 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, you must 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.