mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
620 lines
26 KiB
HTML
620 lines
26 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>The Locking Subsystem</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
|
||
<link rel="up" href="txnconcurrency.html" title="Chapter 4. Concurrency" />
|
||
<link rel="prev" href="blocking_deadlocks.html" title="Locks, Blocks, and Deadlocks" />
|
||
<link rel="next" href="isolation.html" title="Isolation" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">The Locking Subsystem</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="blocking_deadlocks.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 4. Concurrency</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="isolation.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="lockingsubsystem"></a>The Locking Subsystem</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="toc">
|
||
<dl>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="lockingsubsystem.html#configuringlock">Configuring the Locking Subsystem</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="lockingsubsystem.html#configdeadlkdetect">Configuring Deadlock Detection</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="lockingsubsystem.html#deadlockresolve">Resolving Deadlocks</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="lockingsubsystem.html#setpriority">Setting Transaction Priorities</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</div>
|
||
<p>
|
||
In order to allow concurrent operations, DB provides the locking
|
||
subsystem. This subsystem provides inter- and intra- process
|
||
concurrency mechanisms. It is extensively used by DB concurrent
|
||
applications, but it can also be generally used for non-DB
|
||
resources.
|
||
</p>
|
||
<p>
|
||
This section describes the locking subsystem as it is used to
|
||
protect DB resources. In particular, issues on configuration are
|
||
examined here. For information on using the locking subsystem to
|
||
manage non-DB resources, see the
|
||
<em class="citetitle">Berkeley DB Programmer's Reference Guide</em>.
|
||
</p>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="configuringlock"></a>Configuring the Locking Subsystem</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
You initialize the locking subsystem by specifying
|
||
<span>
|
||
<code class="literal">DB_INIT_LOCK</code> to the
|
||
|
||
<code class="methodname">DbEnv::open()</code>
|
||
method.
|
||
</span>
|
||
|
||
</p>
|
||
<p>
|
||
Before opening your environment, you can configure various
|
||
values for your locking subsystem. Note that these
|
||
limits can only be configured before the environment is
|
||
opened. Also, these methods configure the entire environment,
|
||
not just a specific environment handle.
|
||
</p>
|
||
<p>
|
||
Finally, each bullet below identifies the
|
||
<code class="filename">DB_CONFIG</code> file parameter that can be used
|
||
to specify the specific locking limit. If used, these
|
||
<code class="filename">DB_CONFIG</code> file parameters override any
|
||
value that you might specify using the environment handle.
|
||
</p>
|
||
<p>
|
||
The limits that you can configure are as follows:
|
||
</p>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<p>
|
||
The number of lockers supported by the environment.
|
||
This value is used by the environment when it is
|
||
opened to estimate the amount of space that it
|
||
should allocate for various internal data
|
||
structures. By default, 1,000 lockers are
|
||
supported.
|
||
</p>
|
||
<p>
|
||
To configure this value, use the
|
||
|
||
<span>
|
||
|
||
<code class="methodname">DbEnv::set_memory_init()</code>
|
||
method to configure the <code class="literal">DB_MEM_LOCKER</code> structure.
|
||
</span>
|
||
|
||
</p>
|
||
<p>
|
||
As an alternative to this method, you can configure this
|
||
value using the <code class="filename">DB_CONFIG</code> file's
|
||
<code class="literal">set_lk_max_lockers</code> parameter.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
The number of locks supported by the environment.
|
||
By default, 1,000 locks are supported.
|
||
</p>
|
||
<p>
|
||
To configure this value, use the
|
||
<span>
|
||
|
||
<code class="methodname">DbEnv::set_memory_init()</code>
|
||
method to configure the <code class="literal">DB_MEM_LOCK</code> structure.
|
||
</span>
|
||
|
||
</p>
|
||
<p>
|
||
As an alternative to this method, you can configure this
|
||
value using the <code class="filename">DB_CONFIG</code> file's
|
||
<code class="literal">set_lk_max_locks</code> parameter.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
The number of locked objects supported by the
|
||
environment. By default, 1,000 objects can be
|
||
locked.
|
||
</p>
|
||
<p>
|
||
To configure this value, use the
|
||
<span>
|
||
|
||
<code class="methodname">DbEnv::set_memory_init()</code>
|
||
method to configure the <code class="literal">DB_MEM_LOCKOBJECT</code> structure.
|
||
</span>
|
||
|
||
</p>
|
||
<p>
|
||
As an alternative to this method, you can configure this
|
||
value using the <code class="filename">DB_CONFIG</code> file's
|
||
<code class="literal">set_lk_max_objects</code> parameter.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<p>
|
||
For a definition of lockers, locks, and locked objects, see
|
||
<a class="xref" href="blocking_deadlocks.html#lockresources" title="Lock Resources">Lock Resources</a>.
|
||
</p>
|
||
<p>
|
||
For example, to configure the number of locks that your
|
||
environment can use:
|
||
</p>
|
||
<pre class="programlisting">#include "db_cxx.h"
|
||
|
||
...
|
||
|
||
int main(void)
|
||
{
|
||
u_int32_t env_flags = DB_CREATE | // If the environment does not
|
||
// exist, create it.
|
||
DB_INIT_LOCK | // Initialize locking
|
||
DB_INIT_LOG | // Initialize logging
|
||
DB_INIT_MPOOL | // Initialize the cache
|
||
DB_THREAD | // Free-thread the env handle.
|
||
DB_INIT_TXN; // Initialize transactions
|
||
|
||
std::string envHome("/export1/testEnv");
|
||
DbEnv myEnv(0);
|
||
|
||
try {
|
||
|
||
// Configure max locks
|
||
myEnv.set_lk_max_locks(5000);
|
||
myEnv.set_memory_init(DB_MEM_LOCK, 5000);
|
||
|
||
myEnv.open(envHome.c_str(), env_flags, 0);
|
||
|
||
} catch(DbException &e) {
|
||
std::cerr << "Error opening database environment: "
|
||
<< envHome << std::endl;
|
||
std::cerr << e.what() << std::endl;
|
||
return (EXIT_FAILURE);
|
||
}
|
||
|
||
try {
|
||
myEnv.close(0);
|
||
} catch(DbException &e) {
|
||
std::cerr << "Error closing database environment: "
|
||
<< envHome << std::endl;
|
||
std::cerr << e.what() << std::endl;
|
||
return (EXIT_FAILURE);
|
||
}
|
||
|
||
return (EXIT_SUCCESS);
|
||
} </pre>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="configdeadlkdetect"></a>Configuring Deadlock Detection</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
In order for DB to know that a deadlock has occurred,
|
||
some mechanism must be used to perform deadlock
|
||
detection. There are three ways that deadlock detection can
|
||
occur:
|
||
</p>
|
||
<div class="orderedlist">
|
||
<ol type="1">
|
||
<li>
|
||
<p>
|
||
Allow DB to internally detect deadlocks as they
|
||
occur.
|
||
</p>
|
||
<p>
|
||
To do this, you use
|
||
|
||
<span><code class="methodname">DbEnv::set_lk_detect()</code>.</span>
|
||
|
||
This method causes DB to walk its internal lock table
|
||
looking for a deadlock whenever a lock request
|
||
is blocked. This method also identifies how DB decides which lock
|
||
requests are rejected when deadlocks are detected. For example,
|
||
DB can decide to reject the lock request for the transaction
|
||
that has the most number of locks, the least number of locks,
|
||
holds the oldest lock, holds the most number of write locks, and
|
||
so forth (see the API reference documentation for a complete
|
||
list of the lock detection policies).
|
||
</p>
|
||
<p>
|
||
You can call this method at any time during your application's
|
||
lifetime, but typically it is used before you open your environment.
|
||
</p>
|
||
<p>
|
||
Note that how you want DB to decide which thread of control should break a deadlock is
|
||
extremely dependent on the nature of your application. It is not unusual for some performance
|
||
testing to be required in order to make this determination. That said, a transaction that is
|
||
holding the most number of locks is usually indicative of the transaction that has performed
|
||
the most amount of work. Frequently you will not want a transaction that has performed a lot of
|
||
work to abandon its efforts and start all over again. It is not therefore uncommon for
|
||
application developers to initially select the transaction with the <span class="emphasis"><em>minimum</em></span>
|
||
number of write locks to break the deadlock.
|
||
</p>
|
||
<p>
|
||
Using this mechanism for deadlock detection means
|
||
that your application will never have to wait on a
|
||
lock before discovering that a deadlock has
|
||
occurred. However, walking the lock table every
|
||
time a lock request is blocked can be expensive
|
||
from a performance perspective.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Use a dedicated thread or external process to perform
|
||
deadlock detection. Note that this thread must be
|
||
performing no other database operations beyond deadlock
|
||
detection.
|
||
</p>
|
||
<p>
|
||
To externally perform lock detection, you can use
|
||
either the
|
||
|
||
<code class="methodname">DbEnv::lock_detect()</code>
|
||
|
||
method, or use the
|
||
<span class="command"><strong>db_deadlock</strong></span> command line
|
||
utility. This method (or command) causes DB to walk the
|
||
lock table looking for deadlocks.
|
||
</p>
|
||
<p>
|
||
Note that like
|
||
|
||
<span><code class="methodname">DbEnv::set_lk_detect()</code>,</span>
|
||
|
||
you also use this method (or command line utility)
|
||
to identify which lock requests are rejected in the
|
||
event that a deadlock is detected.
|
||
</p>
|
||
<p>
|
||
Applications that perform deadlock detection in
|
||
this way typically run deadlock detection between every few
|
||
seconds and a minute. This means that your
|
||
application may have to wait to be notified of a
|
||
deadlock, but you also save the overhead of walking
|
||
the lock table every time a lock request is blocked.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Lock timeouts.
|
||
</p>
|
||
<p>
|
||
You can configure your locking subsystem such that
|
||
it times out any lock that is not released within a
|
||
specified amount of time. To do this, use the
|
||
|
||
<span><code class="methodname">DbEnv::set_timeout()</code></span>
|
||
|
||
method.
|
||
Note that lock timeouts are only checked when a
|
||
lock request is blocked or when deadlock
|
||
detection is otherwise performed. Therefore, a lock can have timed out and still be held for
|
||
some length of time until DB has a reason to examine its locking tables.
|
||
</p>
|
||
<p>
|
||
Be aware that extremely long-lived transactions, or
|
||
operations that hold locks for a long time, may be
|
||
inappropriately timed out before the transaction or
|
||
operation has a chance to complete. You should
|
||
therefore use this mechanism only if you know your
|
||
application will hold locks for very short periods
|
||
of time.
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<p>
|
||
For example, to configure your application such that DB
|
||
checks the lock table for deadlocks every time a lock
|
||
request is blocked:
|
||
</p>
|
||
<pre class="programlisting">#include "db_cxx.h"
|
||
|
||
...
|
||
|
||
int main(void)
|
||
{
|
||
u_int32_t env_flags = DB_CREATE | // If the environment does not
|
||
// exist, create it.
|
||
DB_INIT_LOCK | // Initialize locking
|
||
DB_INIT_LOG | // Initialize logging
|
||
DB_INIT_MPOOL | // Initialize the cache
|
||
DB_THREAD | // Free-thread the env handle
|
||
DB_INIT_TXN; // Initialize transactions
|
||
|
||
std::string envHome("/export1/testEnv");
|
||
DbEnv myEnv(0);
|
||
|
||
try {
|
||
|
||
// Configure db to perform deadlock detection internally, and to
|
||
// choose the transaction that has performed the least amount
|
||
// of writing to break the deadlock in the event that one
|
||
// is detected.
|
||
myEnv.set_lk_detect(DB_LOCK_MINWRITE);
|
||
myEnv.open(envHome.c_str(), env_flags, 0);
|
||
|
||
// From here, you open your databases, proceed with your
|
||
// database operations, and respond to deadlocks as
|
||
// is normal (omitted for brevity).
|
||
|
||
|
||
...</pre>
|
||
<p>
|
||
Finally, the following command line call causes
|
||
deadlock detection to be run against the
|
||
environment contained in <code class="literal">/export/dbenv</code>. The
|
||
transaction with the youngest lock is chosen to break the
|
||
deadlock:
|
||
</p>
|
||
<pre class="programlisting">> /usr/local/db_install/bin/db_deadlock -h /export/dbenv -a y</pre>
|
||
<p>
|
||
For more information, see the
|
||
<a class="ulink" href="http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/db_deadlock.html" target="_top">
|
||
<code class="literal">db_deadlock</code> reference documentation.
|
||
</a>
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="deadlockresolve"></a>Resolving Deadlocks</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
When DB determines that a deadlock has occurred, it will
|
||
select a thread of control to resolve the deadlock and then
|
||
|
||
<span>
|
||
throws <code class="literal">DbDeadlockException</code> in that
|
||
thread.
|
||
</span>
|
||
|
||
|
||
If a deadlock is detected, the thread must:
|
||
</p>
|
||
<div class="orderedlist">
|
||
<ol type="1">
|
||
<li>
|
||
<p>
|
||
Cease all read and write operations.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Close all open cursors.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Abort the transaction.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Optionally retry the operation. If your application
|
||
retries deadlocked operations, the new attempt must
|
||
be made using a new transaction.
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>
|
||
If a thread has deadlocked, it may not make any
|
||
additional database calls using the handle that has
|
||
deadlocked.
|
||
</p>
|
||
</div>
|
||
<p>
|
||
For example:
|
||
</p>
|
||
<pre class="programlisting">// retry_count is a counter used to identify how many times
|
||
// we've retried this operation. To avoid the potential for
|
||
// endless looping, we won't retry more than MAX_DEADLOCK_RETRIES
|
||
// times.
|
||
|
||
// txn is a transaction handle.
|
||
// key and data are DBT handles. Their usage is not shown here.
|
||
while (retry_count < MAX_DEADLOCK_RETRIES) {
|
||
try {
|
||
envp->txn_begin(NULL, txn, 0);
|
||
dbp->put(txn, &key, &data, 0);
|
||
txn->commit(0);
|
||
return (EXIT_SUCCESS);
|
||
} catch (DbDeadlockException &de) {
|
||
try {
|
||
// Abort the transaction and increment the
|
||
// retry counter
|
||
txn->abort();
|
||
retry_count++;
|
||
// If we've retried too many times, log it and exit
|
||
if (retry_count >= MAX_DEADLOCK_RETRIES) {
|
||
envp->errx("Exceeded retry limit. Giving up.");
|
||
return (EXIT_FAILURE);
|
||
}
|
||
} catch (DbException &ae) {
|
||
envp->err(ae.get_errno(), "txn abort failed.");
|
||
return (EXIT_FAILURE);
|
||
}
|
||
} catch (DbException &e) {
|
||
try {
|
||
// For a generic error, log it and abort.
|
||
envp->err(e.get_errno(), "Error putting data.");
|
||
txn->abort();
|
||
} catch (DbException &ae) {
|
||
envp->err(ae.get_errno(), "txn abort failed.");
|
||
return (EXIT_FAILURE);
|
||
}
|
||
}
|
||
} </pre>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="setpriority"></a>Setting Transaction Priorities</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
Normally when a thread of control must be selected to
|
||
resolve a deadlock, DB decides which thread will
|
||
perform the resolution; you have no way of knowing in
|
||
advance which thread will be selected to resolve the
|
||
deadlock.
|
||
</p>
|
||
<p>
|
||
However, there may be situations where you know it is
|
||
better for one thread to resolve a deadlock over another
|
||
thread. As an example, if you have a background thread
|
||
running data management activities, and another thread
|
||
responding to user requests, you might want deadlock
|
||
resolution to occur in the background thread because you
|
||
can better afford the throughput costs there. Under these
|
||
circumstances, you can identify which thread of control
|
||
will be selected for resolved deadlocks by setting a
|
||
transaction priorities.
|
||
</p>
|
||
<p>
|
||
When two transactions are deadlocked, DB will abort the
|
||
transaction with the lowest priority. By default, every
|
||
transaction is given a priority of 100. However, you can
|
||
set a different priority on a transaction-by-transaction
|
||
basis by using the
|
||
|
||
<code class="methodname">DbTxn::set_priority()</code>
|
||
|
||
method.
|
||
</p>
|
||
<p>
|
||
When two or more transactions are tied for the lowest
|
||
priority, the tie is broken based on the policy provided to
|
||
<span>
|
||
the
|
||
|
||
<code class="methodname">DbEnv::lock_detect()</code>
|
||
method's <code class="literal">atype</code> parameter.
|
||
</span>
|
||
|
||
</p>
|
||
<p>
|
||
A transaction's priority can be changed at any time after
|
||
the transaction handle has been created and before the
|
||
transaction has been resolved (committed or aborted).
|
||
For example:
|
||
</p>
|
||
<pre class="programlisting">#include "db_cxx.h"
|
||
|
||
...
|
||
|
||
int main(void)
|
||
{
|
||
...
|
||
|
||
try {
|
||
|
||
...
|
||
// Database and environment open omitted for brevity.
|
||
...
|
||
DbTxn *txn = NULL;
|
||
myEnv.txn_begin(NULL, &txn, 0);
|
||
<strong class="userinput"><code>txn->set_priority(200);</code></strong>
|
||
|
||
try {
|
||
db->put(txn, &key, &data, 0);
|
||
txn->commit(0);
|
||
} catch (DbException &e) {
|
||
std::cerr << "Error in transaction: "
|
||
<< e.what() << std::endl;
|
||
txn->abort();
|
||
}
|
||
|
||
} catch(DbException &e) {
|
||
std::cerr << "Error opening database and environment: "
|
||
<< file_name << ", "
|
||
<< envHome << std::endl;
|
||
std::cerr << e.what() << std::endl;
|
||
}
|
||
|
||
...
|
||
|
||
} </pre>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="blocking_deadlocks.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="txnconcurrency.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="isolation.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Locks, Blocks, and Deadlocks </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Isolation</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|