Configuring locking

The DB_ENV->set_lk_detect() method specifies that the deadlock detector should be run whenever a lock is about to block. This option provides for rapid detection of deadlocks at the expense of potentially frequent invocations of the deadlock detector. On a fast processor with a highly contentious application where response time is critical, this is a good choice. An option argument to the DB_ENV->set_lk_detect() method indicates which lock requests should be rejected.

The application can limit how long it blocks on a contested resource. The DB_ENV->set_timeout() method specifies the length of the timeout. This value is checked whenever deadlock detection is performed, so the accuracy of the timeout depends upon the frequency of deadlock detection.

In general, when applications are not specifying lock and transaction timeout values, the DB_LOCK_DEFAULT option is probably the correct first choice, and other options should only be selected based on evidence that they improve transaction throughput. If an application has long-running transactions, DB_LOCK_YOUNGEST will guarantee that transactions eventually complete, but it may do so at the expense of a large number of lock request rejections (and therefore, transaction aborts).

The alternative to using the DB_ENV->set_lk_detect() method is to explicitly perform deadlock detection using the Berkeley DB DB_ENV->lock_detect() method.

The DB_ENV->set_lk_conflicts() method allows you to specify your own locking conflicts matrix. This is an advanced configuration option, and is almost never necessary.