m4_comment([$Id: config.so,v 10.21 2003/10/18 19:16:02 bostic Exp $])m4_ref_title(Locking Subsystem,    Configuring locking, @locking configuration, lock/intro, lock/max)m4_p([dnlThe m4_refT(dbenv_set_lk_detect) specifies that the deadlock detectorshould be run whenever a lock is about to block.  This option providesfor rapid detection of deadlocks at the expense of potentially frequentinvocations of the deadlock detector.  On a fast processor with a highlycontentious application where response time is critical, this is a goodchoice.  An option argument to the m4_refT(dbenv_set_lk_detect)indicates which lock requests should be rejected.])m4_p([dnlIn general, when applications are not specifying lock and transactiontimeout values, the m4_ref(DB_LOCK_DEFAULT) option is probably thecorrect first choice, and other options should only be selected basedon evidence that they improve transaction throughput.  If an applicationhas long-running transactions, m4_ref(DB_LOCK_YOUNGEST) will guaranteethat transactions eventually complete, but it may do so at the expenseof a large number of lock request rejections (and therefore, transactionaborts).])m4_p([dnlThe alternative to using the m4_refT(dbenv_set_lk_detect) is toexplicitly perform deadlock detection using the m4_dbm4_refT(lock_detect).])m4_p([dnlThe m4_refT(dbenv_set_lk_conflicts) allows you to specify your ownlocking conflicts matrix.  This is an advanced configuration option,and is almost never necessary.])m4_page_footer