mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-17 01:26:25 +00:00
255 lines
12 KiB
HTML
255 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>
|