mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
254 lines
12 KiB
HTML
254 lines
12 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>Recoverability and deadlock handling</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="Berkeley DB Programmer's Reference Guide" />
|
||
<link rel="up" href="transapp.html" title="Chapter 11. Berkeley DB Transactional Data Store Applications" />
|
||
<link rel="prev" href="transapp_data_open.html" title="Opening the databases" />
|
||
<link rel="next" href="transapp_atomicity.html" title="Atomicity" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.2</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Recoverability and deadlock handling</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="transapp_data_open.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 11.
|
||
Berkeley DB Transactional Data Store Applications
|
||
</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="transapp_atomicity.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="transapp_put"></a>Recoverability and deadlock handling</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The first reason listed for using transactions was recoverability. Any
|
||
logical change to a database may require multiple changes to underlying
|
||
data structures. For example, modifying a record in a Btree may require
|
||
leaf and internal pages to split, so a single <a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> method
|
||
call can potentially require that multiple physical database pages be
|
||
written. If only some of those pages are written and then the system
|
||
or application fails, the database is left inconsistent and cannot be
|
||
used until it has been recovered; that is, until the partially completed
|
||
changes have been undone.</p>
|
||
<p><span class="emphasis"><em>Write-ahead-logging</em></span> is the term that describes the underlying
|
||
implementation that Berkeley DB uses to ensure recoverability. What it means
|
||
is that before any change is made to a database, information about the
|
||
change is written to a database log. During recovery, the log is read,
|
||
and databases are checked to ensure that changes described in the log
|
||
for committed transactions appear in the database. Changes that appear
|
||
in the database but are related to aborted or unfinished transactions
|
||
in the log are undone from the database.</p>
|
||
<p>For recoverability after application or system failure, operations that
|
||
modify the database must be protected by transactions. More
|
||
specifically, operations are not recoverable unless a transaction is
|
||
begun and each operation is associated with the transaction via the
|
||
Berkeley DB interfaces, and then the transaction successfully committed. This
|
||
is true even if logging is turned on in the database environment.</p>
|
||
<p>Here is an example function that updates a record in a database in a
|
||
transactionally protected manner. The function takes a key and data
|
||
items as arguments and then attempts to store them into the database.</p>
|
||
<pre class="programlisting">int
|
||
main(int argc, char *argv)
|
||
{
|
||
extern int optind;
|
||
DB *db_cats, *db_color, *db_fruit;
|
||
DB_ENV *dbenv;
|
||
int ch;
|
||
|
||
while ((ch = getopt(argc, argv, "")) != EOF)
|
||
switch (ch) {
|
||
case '?':
|
||
default:
|
||
usage();
|
||
}
|
||
argc -= optind;
|
||
argv += optind;
|
||
|
||
env_dir_create();
|
||
env_open(&dbenv);
|
||
|
||
/* Open database: Key is fruit class; Data is specific type. */
|
||
db_open(dbenv, &db_fruit, "fruit", 0);
|
||
|
||
/* Open database: Key is a color; Data is an integer. */
|
||
db_open(dbenv, &db_color, "color", 0);
|
||
|
||
/*
|
||
* Open database:
|
||
* Key is a name; Data is: company name, cat breeds.
|
||
*/
|
||
db_open(dbenv, &db_cats, "cats", 1);
|
||
|
||
<span class="bold"><strong> add_fruit(dbenv, db_fruit, "apple", "yellow delicious");</strong></span>
|
||
|
||
return (0);
|
||
}
|
||
|
||
<span class="bold"><strong>int
|
||
add_fruit(DB_ENV *dbenv, DB *db, char *fruit, char *name)
|
||
{
|
||
DBT key, data;
|
||
DB_TXN *tid;
|
||
int fail, ret, t_ret;
|
||
|
||
/* Initialization. */
|
||
memset(&key, 0, sizeof(key));
|
||
memset(&data, 0, sizeof(data));
|
||
key.data = fruit;
|
||
key.size = strlen(fruit);
|
||
data.data = name;
|
||
data.size = strlen(name);
|
||
|
||
for (fail = 0;;) {
|
||
/* Begin the transaction. */
|
||
if ((ret = dbenv->txn_begin(dbenv, NULL, &tid, 0)) != 0) {
|
||
dbenv->err(dbenv, ret, "DB_ENV->txn_begin");
|
||
exit (1);
|
||
}
|
||
|
||
/* Store the value. */
|
||
switch (ret = db->put(db, tid, &key, &data, 0)) {
|
||
case 0:
|
||
/* Success: commit the change. */
|
||
if ((ret = tid->commit(tid, 0)) != 0) {
|
||
dbenv->err(dbenv, ret, "DB_TXN->commit");
|
||
exit (1);
|
||
}
|
||
return (0);
|
||
case DB_LOCK_DEADLOCK:
|
||
default:
|
||
/* Retry the operation. */
|
||
if ((t_ret = tid->abort(tid)) != 0) {
|
||
dbenv->err(dbenv, t_ret, "DB_TXN->abort");
|
||
exit (1);
|
||
}
|
||
if (fail++ == MAXIMUM_RETRY)
|
||
return (ret);
|
||
break;
|
||
}
|
||
}
|
||
}</strong></span></pre>
|
||
<p>Berkeley DB also uses transactions to recover from deadlock. Database
|
||
operations (that is, any call to a function underlying the handles
|
||
returned by <a href="../api_reference/C/dbopen.html" class="olink">DB->open()</a> and <a href="../api_reference/C/dbcursor.html" class="olink">DB->cursor()</a>) are usually
|
||
performed on behalf of a unique locker. Transactions can be used to
|
||
perform multiple calls on behalf of the same locker within a single
|
||
thread of control. For example, consider the case in which an
|
||
application uses a cursor scan to locate a record and then the
|
||
application accesses another other item in the database, based on the
|
||
key returned by the cursor, without first closing the cursor. If these
|
||
operations are done using default locker IDs, they may conflict. If the
|
||
locks are obtained on behalf of a transaction, using the transaction's
|
||
locker ID instead of the database handle's locker ID, the operations
|
||
will not conflict.</p>
|
||
<p>There is a new error return in this function that you may not have seen
|
||
before. In transactional (not Concurrent Data Store) applications
|
||
supporting both readers and writers, or just multiple writers, Berkeley DB
|
||
functions have an additional possible error return:
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a>. This means two threads of control deadlocked,
|
||
and the thread receiving the <code class="literal">DB_LOCK_DEADLOCK</code> error return has
|
||
been selected to discard its locks in order to resolve the problem.
|
||
When an application receives a <code class="literal">DB_LOCK_DEADLOCK</code> return, the
|
||
correct action is to close any cursors involved in the operation and
|
||
abort any enclosing transaction. In the sample code, any time the
|
||
<a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> method returns <code class="literal">DB_LOCK_DEADLOCK</code>, <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a> is
|
||
called (which releases the transaction's Berkeley DB resources and undoes any
|
||
partial changes to the databases), and then the transaction is retried
|
||
from the beginning.</p>
|
||
<p>There is no requirement that the transaction be attempted again, but
|
||
that is a common course of action for applications. Applications may
|
||
want to set an upper bound on the number of times an operation will be
|
||
retried because some operations on some data sets may simply be unable
|
||
to succeed. For example, updating all of the pages on a large Web site
|
||
during prime business hours may simply be impossible because of the high
|
||
access rate to the database.</p>
|
||
<p>The <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a> method is called in error cases other than deadlock.
|
||
Any time an error occurs, such that a transactionally protected set of
|
||
operations cannot complete successfully, the transaction must be
|
||
aborted. While deadlock is by far the most common of these errors,
|
||
there are other possibilities; for example, running out of disk space
|
||
for the filesystem. In Berkeley DB transactional applications, there are
|
||
three classes of error returns: "expected" errors, "unexpected but
|
||
recoverable" errors, and a single "unrecoverable" error. Expected
|
||
errors are errors like
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_NOTFOUND">DB_NOTFOUND</a>,
|
||
which indicates that a
|
||
searched-for key item is not present in the database. Applications may
|
||
want to explicitly test for and handle this error, or, in the case where
|
||
the absence of a key implies the enclosing transaction should fail,
|
||
simply call <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a>. Unexpected but recoverable errors are
|
||
errors like
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a>,
|
||
which indicates that an operation
|
||
has been selected to resolve a deadlock, or a system error such as EIO,
|
||
which likely indicates that the filesystem has no available disk space.
|
||
Applications must immediately call <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a> when these returns
|
||
occur, as it is not possible to proceed otherwise. The only
|
||
unrecoverable error is
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_RUNRECOVERY">DB_RUNRECOVERY</a>,
|
||
which indicates that the
|
||
system must stop and recovery must be run.</p>
|
||
<p>The above code can be simplified in the case of a transaction comprised
|
||
entirely of a single database put or delete operation, as operations
|
||
occurring in transactional databases are implicitly transaction
|
||
protected. For example, in a transactional database, the above code
|
||
could be more simply written as:</p>
|
||
<pre class="programlisting">
|
||
<strong class="userinput"><code>for (fail = 0; fail++ <= MAXIMUM_RETRY &&
|
||
(ret = db->put(db, NULL, &key, &data, 0)) == DB_LOCK_DEADLOCK;)
|
||
continue;
|
||
return (ret == 0 ? 0 : 1);</code></strong></pre>
|
||
<p>and the underlying transaction would be automatically handled by Berkeley DB.</p>
|
||
<p>Programmers should not attempt to enumerate all possible error returns
|
||
in their software. Instead, they should explicitly handle expected
|
||
returns and default to aborting the transaction for the rest. It is
|
||
entirely the choice of the programmer whether to check for
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_RUNRECOVERY">DB_RUNRECOVERY</a>
|
||
explicitly or not — attempting new Berkeley DB
|
||
operations after
|
||
<a class="link" href="program_errorret.html#program_errorret.DB_RUNRECOVERY">DB_RUNRECOVERY</a>
|
||
is returned does not worsen the
|
||
situation. Alternatively, using the <a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV->set_event_notify()</a> method to
|
||
handle an unrecoverable error and simply doing some number of
|
||
abort-and-retry cycles for any unexpected Berkeley DB or system error in the
|
||
mainline code often results in the simplest and cleanest application
|
||
code.</p>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="transapp_data_open.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="transapp.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="transapp_atomicity.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Opening the databases </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Atomicity</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|