Troubleshooting transactions and commitment control

 

This information might help you troubleshoot commitment control errors, detect deadlocks, recover transactions after communications failure, know when to force commit and rollback operations, and when to cancel resynchronization and end long-running rollbacks.

• Commitment control errors
  When you use commitment control, it is important to understand which conditions cause errors and which do not.

• Detecting deadlocks
  A deadlock condition can occur when a job holds a lock on an object, object A, and is waiting to obtain a lock on another object, object B. At the same time, another job or transaction currently holds a lock on object B and is waiting to obtain a lock on object A.

• Recovering transactions after communications failure
  These instructions help you handle transactions performing work on a remote system after communication with that system fails.

• 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.

• Ending a long-running rollback
  You might want to end long-running rollbacks that consume critical processor time, lock resources, or take up storage space.

 

Parent topic:

Commitment control