head 1.2; access; symbols RPM_4_2_1:1.1.1.5 RPM_4_2:1.1.1.5 RPM_4_1_1:1.1.1.5 RPM_4_1:1.1.1.4 RPM_4_0_5:1.1.1.3 RPM_4_0_4:1.1.1.2 RPM_4_0_3:1.1.1.1 RPM:1.1.1; locks; strict; comment @# @; 1.2 date 2008.01.02.09.55.16; author rse; state dead; branches; next 1.1; commitid z4cpSiAhOCXk5PLs; 1.1 date 2001.07.23.20.45.37; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.07.23.20.45.37; author rse; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2002.01.08.00.30.12; author rse; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2003.01.18.13.49.02; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2001.10.15.03.47.34; author rse; state Exp; branches; next 1.1.1.5; 1.1.1.5 date 2003.01.18.14.05.00; author rse; state Exp; branches; next ; desc @@ 1.2 log @remove the ancient RPM 4.2.1 source tree copy @ text @
|
![]() ![]() ![]() |
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:
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 @ 1.1 log @Initial revision @ text @d1 1 a1 1 @ 1.1.1.1 log @Import: RPM 4.0.3 @ text @@ 1.1.1.2 log @Import: RPM 4.0.4 @ text @d1 1 a1 1 d19 2 a20 2 should be run whenever a lock is about to block. This option provides for rapid detection of deadlocks at the expense of potentially frequent d23 18 a40 10 choice. An option argument to the DB_ENV->set_lk_detect function indicates which lock requests should be rejected.
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). d43 1 a43 1 DB_ENV->lock_detect interface. @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d2 1 a2 1 a3 1 d18 1 a18 1
The DB_ENV->set_lk_detect method specifies that the deadlock detector d23 1 a23 1 choice. An option argument to the DB_ENV->set_lk_detect method d36 1 a36 1
The DB_ENV->set_lk_conflicts method allows you to specify your own @ 1.1.1.4 log @Import: RPM 4.1 @ text @d2 1 a2 1 d4 1 d19 1 a19 1
The DB_ENV->set_lk_detect function specifies that the deadlock detector d24 1 a24 1 choice. An option argument to the DB_ENV->set_lk_detect function d37 1 a37 1
The DB_ENV->set_lk_conflicts function allows you to specify your own @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d2 1 a2 1 a3 1 d18 1 a18 1
The DB_ENV->set_lk_detect method specifies that the deadlock detector d23 1 a23 1 choice. An option argument to the DB_ENV->set_lk_detect method d36 1 a36 1
The DB_ENV->set_lk_conflicts method allows you to specify your own @