[IBM][CLI Driver][DB2/NT64] SQL0911N The current transaction has
been rolled back because of a deadlock or timeout. Reason code
The current unit of work was involved in an unresolved contention for
use of an object and had to be rolled back.
The reason codes are as follows:
The transaction was rolled back due to a deadlock.
The transaction was rolled back due to a lock timeout.
The transaction was rolled back due to a DB2 Data Links Manager
error during the transaction.
The transaction was rolled back because a queuing threshold
such as the CONCURRENTDBCOORDACTIVITIES threshold caused two or
more activities to reach a deadlock state. For more
information, see "CONCURRENTDBCOORDACTIVITIES threshold" in the
DB2 Information Center.
The application was rolled back to the previous COMMIT.
The changes associated with the unit of work must be entered again.
To help avoid deadlock or lock timeout, issue frequent COMMIT
operations, if possible, for a long-running application, or for an
application likely to encounter a deadlock.
Federated system users: the deadlock can occur at the federated server
or at the data source. There is no mechanism to detect deadlocks that
span data sources and potentially the federated system. It is possible
to identify the data source failing the request (refer to the problem
determination guide to determine which data source is failing to process
the SQL statement).
Deadlocks are often normal or expected while processing certain
combinations of SQL statements. It is recommended that you design
applications to avoid deadlocks to the extent possible.
For more detailed information about preventing deadlocks or lock
timeouts search the DB2 Information Center
(DB2 Database for Linux, UNIX, and Windows
) using phrases such
as "deadlock prevention", and terms such as "deadlocks" and "lock
If a deadlock state was reached because of a queuing threshold such as
the CONCURRENTDBCOORDACTIVITIES threshod, increase the value of the