mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
287 lines
13 KiB
HTML
287 lines
13 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 18.1.40</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>
|