Application deadlocks

When you use multiple connections to access the same database resources concurrently, you create general contention for database resources. Timeouts and deadlocks can result from this contention.

The Db2 subsystem detects deadlocks and performs rollbacks on the necessary connections to resolve these deadlocks. However, the Db2 subsystem cannot detect a deadlock if the contention that created that deadlock involves application resources. An application that creates multiple connections with multithreading or multiple-context support can potentially create deadlocks if the following sequence occurs:
  1. Two Language Environment® threads connect to the same data source using two Db2 threads.
  2. One Language Environment thread holds an internal application resource (such as a mutex) while its Db2 thread waits for access to a database resource.
  3. The other Language Environment thread has a lock on a database resource while waiting for the internal application resource.

When this sequence of events occurs, the Db2 subsystem does not detect a deadlock because the Db2 subsystem cannot monitor the internal resources of the application. Although the Db2 subsystem cannot detect the deadlock itself, it does detect and handle any Db2 thread timeouts that result from that deadlock.