When to force commit and rollback operations and when to cancel resynchronization
The decision to force a commit or rollback operation is called a heuristic decision. This action enables an operator to manually commit or roll back the resources for a transaction that is in a prepared state.
When you make a heuristic decision, the state of the transaction becomes heuristic mixed if your decision is inconsistent with the results of the other locations in the transaction. You must take responsibility for determining the action taken by all the other locations that participated in the transaction and resynchronizing the database records.
Before you make a heuristic decision, gather as much information as you can about the transaction. Display the jobs that are associated with the commitment definition and make a record of what journals and files are involved. You can use this information later if display journal entries and apply or remove journaled changes manually.
The best place to find out information about a transaction is to look at the location that was the initiator for that transaction. However, the decision to commit or roll back might be owned by an API resource or by a last agent.
If an API resource was registered as a last agent resource, the final decision of whether to commit or roll back is owned by the API resource. You need to look at information about the application and how it uses the API resource to determine whether to commit or to roll back.
If the transaction has a last agent selected, the last agent owns the decision to commit or roll back. Look at the status of the last agent for information about the transaction.
When make heuristic decisions or cancel resynchronization due to a system or communications failure that cannot be repaired, you can find all transactions in doubt by using the following steps:
- In iSeries™ Navigator, expand the system you want to work with.
- Expand Databases and the local database for the system.
- Expand Transactions.
- Expand Database Transactions or Global Transactions.
In this display windows, you can see the commitment definition, resynchronization status, the current unit of work ID, and the current unit of work state for each transaction. Look for transactions with the following information:
- Transactions with a Logical Unit of Work State of Prepared or Last Agent Pending.
- Transactions that show Resynchronization in Progress status of yes.
To work with the job that is participating in the transaction on this system right-click the transaction and select job.
When you right-click the transaction, you can also select Force Commit, Force Rollback, or Cancel Resynchronization.
Before making a heuristic decision or canceling resynchronization, you might want to check the status of the jobs on other systems associated with the transaction. Checking the jobs on remote systems might help you avoid decisions that cause database inconsistencies between systems.
- Right-click the transaction you want to work with.
- Select Resource Status.
- In the Resource Status dialog, select the Conversation tab for SNA connections; select Connection for TCP/IP connections.
Each conversation resource represents a remote system that is participating in the transaction. On the remote systems, you can use iSeries Navigator to see the transactions associated with the transaction.
The base portion of the unit of work ID is the same on all the systems. When you display commitment control information on the remote system, look for the base portion of the unit of work ID that is the same on the local system.
For example, if the unit of work ID on the local system starts with: APPN.RCHASL97.X'112233445566, look for the unit of work ID on the remote system that also starts with APPN.RCHASL97.X'112233445566.
Parent topic:
Troubleshooting transactions and commitment control
Related concepts
XA transaction support for commitment control
Starting commitment control
Related tasks
Detecting deadlocks
Recovering transactions after communications failure
Displaying commitment control information