<?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 class="navheader">
<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>
