From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/lock_config.html | 77 +++++++++++++++++------------- 1 file changed, 43 insertions(+), 34 deletions(-) (limited to 'docs/programmer_reference/lock_config.html') diff --git a/docs/programmer_reference/lock_config.html b/docs/programmer_reference/lock_config.html index 7659a481..d582e11d 100644 --- a/docs/programmer_reference/lock_config.html +++ b/docs/programmer_reference/lock_config.html @@ -14,7 +14,7 @@ -

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.

+

+ 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. +

-- cgit v1.2.1