mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-17 01:26:25 +00:00
129 lines
6 KiB
HTML
129 lines
6 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>Terminology</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_why.html" title="Why transactions?" />
|
|||
|
|
<link rel="next" href="transapp_fail.html" title="Handling failure in Transactional Data Store applications" />
|
|||
|
|
</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">Terminology</th>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td width="20%" align="left"><a accesskey="p" href="transapp_why.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_fail.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_term"></a>Terminology</h2>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<p>Here are some definitions that will be helpful in understanding
|
|||
|
|
transactions:</p>
|
|||
|
|
<div class="variablelist">
|
|||
|
|
<dl>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Thread of control</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd>Berkeley DB is indifferent to the type or style of threads being used by the
|
|||
|
|
application; or, for that matter, if threads are being used at all —
|
|||
|
|
because Berkeley DB supports multiprocess access. In the Berkeley DB documentation,
|
|||
|
|
any time we refer to a <span class="emphasis"><em>thread of control</em></span>, it can be read as
|
|||
|
|
a true thread (one of many in an application's address space) or a
|
|||
|
|
process.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Free-threaded</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd>A Berkeley DB handle that can be used by multiple threads simultaneously
|
|||
|
|
without any application-level synchronization is called
|
|||
|
|
<span class="emphasis"><em>free-threaded</em></span>.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Transaction</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd>A <span class="emphasis"><em>transaction</em></span> is a one or more operations on one or more
|
|||
|
|
databases that should be treated as a single unit of work. For example,
|
|||
|
|
changes to a set of databases, in which either all of the changes must be
|
|||
|
|
applied to the database(s) or none of them should. Applications specify
|
|||
|
|
when each transaction starts, what database operations are included in
|
|||
|
|
it, and when it ends.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Transaction abort/commit</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd>Every transaction ends by <span class="emphasis"><em>committing</em></span> or <span class="emphasis"><em>aborting</em></span>.
|
|||
|
|
If a transaction commits, Berkeley DB guarantees that any database changes
|
|||
|
|
included in the transaction will never be lost, even after system or
|
|||
|
|
application failure. If a transaction aborts, or is uncommitted when
|
|||
|
|
the system or application fails, then the changes involved will never
|
|||
|
|
appear in the database.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">System or application failure</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd><span class="emphasis"><em>System or application failure</em></span> is the phrase we use to
|
|||
|
|
describe something bad happening near your data. It can be an
|
|||
|
|
application dumping core, being interrupted by a signal, the disk
|
|||
|
|
filling up, or the entire system crashing. In any case, for whatever
|
|||
|
|
reason, the application can no longer make forward progress, and its
|
|||
|
|
databases are left in an unknown state.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Recovery</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd><span class="emphasis"><em>Recovery</em></span> is what makes the database consistent after a system
|
|||
|
|
or application failure. The recovery process includes review of log
|
|||
|
|
files and databases to ensure that the changes from each committed
|
|||
|
|
transaction appear in the database, and that no changes from an
|
|||
|
|
unfinished (or aborted) transaction do. Whenever system or application
|
|||
|
|
failure occurs, applications must usually run recovery.</dd>
|
|||
|
|
<dt>
|
|||
|
|
<span class="term">Deadlock</span>
|
|||
|
|
</dt>
|
|||
|
|
<dd><span class="emphasis"><em>Deadlock</em></span>, in its simplest form, happens when one thread of
|
|||
|
|
control owns resource A, but needs resource B; while another thread of
|
|||
|
|
control owns resource B, but needs resource A. Neither thread of
|
|||
|
|
control can make progress, and so one has to give up and release all
|
|||
|
|
its resources, at which time the remaining thread of control can make
|
|||
|
|
forward progress.</dd>
|
|||
|
|
</dl>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div class="navfooter">
|
|||
|
|
<hr />
|
|||
|
|
<table width="100%" summary="Navigation footer">
|
|||
|
|
<tr>
|
|||
|
|
<td width="40%" align="left"><a accesskey="p" href="transapp_why.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_fail.html">Next</a></td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td width="40%" align="left" valign="top">Why transactions? </td>
|
|||
|
|
<td width="20%" align="center">
|
|||
|
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
|
</td>
|
|||
|
|
<td width="40%" align="right" valign="top"> Handling failure in Transactional Data Store applications</td>
|
|||
|
|
</tr>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|