Berkeley DB Reference Guide:
Locking Subsystem


Configuring locking

The DB_ENV->set_lk_detect function specifies that the deadlock detector should be run whenever a lock blocks. 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 argument to the DB_ENV->set_lk_detect function indicates which transaction to abort when a deadlock is detected. It can take on any one of the following values:

Abort the most recently started transaction.
Abort the transaction holding the greatest number of locks.
Abort the transaction holding the fewest locks.
Abort the transaction holding the fewest write locks.
Abort the longest-lived transaction.
Abort whatever transaction the deadlock detector happens to find first.
Use the default policy.

In general, DB_LOCK_DEFAULT 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 aborts.

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

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


Copyright Sleepycat Software