<!--$Id: config.so,v 10.21 2003/10/18 19:16:02 bostic Exp $--> <!--Copyright 1997-2003 by Sleepycat Software, Inc.--> <!--All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Configuring locking</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <a name="2"><!--meow--></a> <table width="100%"><tr valign=top> <td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Locking Subsystem</dl></h3></td> <td align=right><a href="../lock/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/max.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p> <h3 align=center>Configuring locking</h3> <p>The <a href="../../api_c/env_set_lk_detect.html">DB_ENV->set_lk_detect</a> 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 <a href="../../api_c/env_set_lk_detect.html">DB_ENV->set_lk_detect</a> method indicates which lock requests should be rejected.</p> <p>In general, when applications are not specifying lock and transaction timeout values, the <a href="../../api_c/env_set_lk_detect.html#DB_LOCK_DEFAULT">DB_LOCK_DEFAULT</a> 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, <a href="../../api_c/env_set_lk_detect.html#DB_LOCK_YOUNGEST">DB_LOCK_YOUNGEST</a> 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).</p> <p>The alternative to using the <a href="../../api_c/env_set_lk_detect.html">DB_ENV->set_lk_detect</a> method is to explicitly perform deadlock detection using the Berkeley DB <a href="../../api_c/lock_detect.html">DB_ENV->lock_detect</a> method.</p> <p>The <a href="../../api_c/env_set_lk_conflicts.html">DB_ENV->set_lk_conflicts</a> method allows you to specify your own locking conflicts matrix. This is an advanced configuration option, and is almost never necessary.</p> <table width="100%"><tr><td><br></td><td align=right><a href="../lock/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/max.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2003</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font> </body> </html>
distrib
>
Mandriva
>
2007.0
>
x86_64
>
media
>
main-release
>
by-pkgid
>
a4c98df40e78f6c892308fd6841f950a
>
files
>
951
