487 lines
21 KiB
HTML
487 lines
21 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>Chapter 1. Introduction</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.62.4" />
|
||
<link rel="home" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
|
||
<link rel="up" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
|
||
<link rel="previous" href="preface.html" title="Preface" />
|
||
<link rel="next" href="recovery-intro.html" title="Recoverability" />
|
||
</head>
|
||
<body>
|
||
<div class="navheader">
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Chapter 1. Introduction</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td>
|
||
<th width="60%" align="center"> </th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="chapter" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2>
|
||
</div>
|
||
</div>
|
||
<div></div>
|
||
</div>
|
||
<div class="toc">
|
||
<p>
|
||
<b>Table of Contents</b>
|
||
</p>
|
||
<dl>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="introduction.html#txnintro">Transaction Benefits</a>
|
||
</span>
|
||
</dt>
|
||
<dd>
|
||
<dl>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="introduction.html#sysfailure">A Note on System Failure</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="introduction.html#apireq">Application Requirements</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect2">
|
||
<a href="introduction.html#multithread-intro">Multi-threaded
|
||
and Multi-process
|
||
Applications</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</dd>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="recovery-intro.html">Recoverability</a>
|
||
</span>
|
||
</dt>
|
||
<dt>
|
||
<span class="sect1">
|
||
<a href="perftune-intro.html">Performance Tuning</a>
|
||
</span>
|
||
</dt>
|
||
</dl>
|
||
</div>
|
||
<p>
|
||
This book provides a thorough introduction and discussion on transactions as
|
||
used with Berkeley DB (DB). <span>Both the
|
||
base API as well as the Direct Persistence Layer API is used in this
|
||
manual.</span> It begins by offering a general overview to
|
||
transactions, the guarantees they provide, and the general application
|
||
infrastructure required to obtain full transactional protection for your
|
||
data.
|
||
</p>
|
||
<p>
|
||
This book also provides detailed examples on how to write a
|
||
transactional application. Both single threaded and multi-threaded <span>(as well as multi-process
|
||
applications)</span> are discussed. A detailed description of various
|
||
backup and recovery strategies is included in this manual, as is a
|
||
discussion on performance considerations for your transactional application.
|
||
</p>
|
||
<p>
|
||
You should understand the concepts from the
|
||
<span>
|
||
<i class="citetitle">Getting Started with Berkeley DB</i>
|
||
</span>
|
||
|
||
|
||
guide before reading this book.
|
||
</p>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="txnintro"></a>Transaction Benefits</h2>
|
||
</div>
|
||
</div>
|
||
<div></div>
|
||
</div>
|
||
<p>
|
||
Transactions offer your application's data protection from
|
||
application or system failures. That is, DB transactions offer
|
||
your application full ACID support:
|
||
</p>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<p>
|
||
<span class="bold"><b>A</b></span>tomicity
|
||
</p>
|
||
<p>
|
||
Multiple database operations are treated as a single unit of
|
||
work. Once committed, all write operations performed under
|
||
the protection of the transaction are saved to your databases.
|
||
Further, in the event that you abort a transaction, all write
|
||
operations performed during the transaction are discarded.
|
||
In this event, your database is left in the state it was in
|
||
before the transaction began, regardless of the number or
|
||
type of write operations you may have performed during the
|
||
course of the transaction.
|
||
</p>
|
||
<p>
|
||
Note that DB transactions can span one or more
|
||
database handles.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span class="bold"><b>C</b></span>onsistency
|
||
</p>
|
||
<p>
|
||
Your databases will never see a partially completed
|
||
transaction. This is true even if your application fails while there are
|
||
in-progress transactions. If the application or system fails,
|
||
then either all of the database changes appear when the
|
||
application next runs, or none of them appear.
|
||
</p>
|
||
<p>
|
||
In other words, whatever consistency requirements your application has will never be violated by DB.
|
||
If, for example, your application requires every record to include an employee ID, and your
|
||
code faithfully adds that ID to its database records, then DB will never
|
||
violate that consistency requirement. The ID will remain in the database records until such a time as your
|
||
application chooses to delete it.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span class="bold"><b>I</b></span>solation
|
||
</p>
|
||
<p>
|
||
While a transaction is in progress, your databases will appear
|
||
to the transaction as if there are no other operations
|
||
occurring outside of the transaction. That is, operations
|
||
wrapped inside a transaction will always have a clean and
|
||
consistent view of your databases. They never have to see
|
||
updates currently in progress under the protection of another transaction.
|
||
Note, however, that isolation guarantees can be
|
||
|
||
relaxed from the default setting. See
|
||
<a href="isolation.html">Isolation</a>
|
||
for more information.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span class="bold"><b>D</b></span>urability
|
||
</p>
|
||
<p>
|
||
Once committed to your databases, your modifications will
|
||
persist even in the event of an application or system failure.
|
||
Note that like isolation, your durability guarantee can be
|
||
relaxed. See <a href="usingtxns.html#nodurabletxn">Non-Durable Transactions</a>
|
||
for more information.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="sysfailure"></a>A Note on System Failure</h3>
|
||
</div>
|
||
</div>
|
||
<div></div>
|
||
</div>
|
||
<p>
|
||
From time to time this manual mentions that transactions protect your data against 'system or application
|
||
failure.' This is
|
||
true up to a certain extent. However, not all failures are created equal and no data protection
|
||
mechanism can protect you against every conceivable way a computing system can find to die.
|
||
</p>
|
||
<p>
|
||
Generally, when this book talks about protection against failures, it means that
|
||
transactions offer protection against
|
||
the likeliest culprits for system and application crashes. So long as your data modifications have been
|
||
committed to disk, those modifications should persist even if your application or OS subsequently fails.
|
||
And, even if the application or OS fails in the middle of a transaction commit (or abort), the data on disk
|
||
should be either in a consistent state, or there should be enough data available to bring
|
||
your databases into a consistent state (via a recovery procedure, for example). You may, however,
|
||
lose whatever data you were committing at the
|
||
time of the failure, but your databases will be otherwise unaffected.
|
||
</p>
|
||
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
<p>
|
||
Be aware that many disks have a disk write cache and on
|
||
some systems it is enabled by default. This means that
|
||
a transaction can have committed, and to your
|
||
application the data may appear to reside on disk, but
|
||
the data may in fact reside only in the write cache at
|
||
that time. This means that if the disk write cache is
|
||
enabled and there is no battery backup for it, data can
|
||
be lost after an OS crash even when maximum durability
|
||
mode is in use. For maximum durability, disable the
|
||
disk write cache or use a disk write cache with a
|
||
battery backup.
|
||
</p>
|
||
</div>
|
||
<p>
|
||
Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book
|
||
are only as good as the backups you have taken.
|
||
|
||
|
||
<span>
|
||
By spreading your data and log files across separate disks,
|
||
you can minimize the risk of data loss due to a disk failure, but even in this case it is possible to
|
||
conjure a scenario where even this protection is insufficient (a fire in the machine room, for example) and
|
||
you must go to your backups for protection.
|
||
</span>
|
||
</p>
|
||
<p>
|
||
Finally, by following the programming examples shown in this book, you can write your code so as to protect
|
||
your data in the event that your code crashes. However, no programming API can protect you against logic
|
||
failures in your own code; transactions cannot protect you from simply writing the wrong thing to your
|
||
databases.
|
||
</p>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="apireq"></a>Application Requirements</h3>
|
||
</div>
|
||
</div>
|
||
<div></div>
|
||
</div>
|
||
<p>
|
||
In order to use transactions, your application has certain
|
||
requirements beyond what is required of non-transactional protected
|
||
applications. They are:
|
||
</p>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<p>
|
||
Environments.
|
||
</p>
|
||
<p>
|
||
Environments are optional for non-transactional
|
||
applications, but they are required for transactional
|
||
applications.
|
||
</p>
|
||
<p>
|
||
Environments are optional for non-transactional
|
||
applications that use the base API, but they are required for transactional
|
||
applications. (Of course, applications that use the
|
||
DPL always require the DPL.)
|
||
</p>
|
||
<p>
|
||
Environment usage is described in detail in
|
||
<a href="usingtxns.html">Transaction Basics</a>.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Transaction subsystem.
|
||
</p>
|
||
<p>
|
||
In order to use transactions, you must explicitly
|
||
enable the transactional subsystem for your
|
||
application, and this must be done at the time that
|
||
your environment is first created.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Logging subsystem.
|
||
</p>
|
||
<p>
|
||
The logging subsystem is required for recovery purposes, but
|
||
its usage also means your application may require a
|
||
little more administrative effort than it does when logging
|
||
is not in use. See <a href="filemanagement.html">Managing DB Files</a> for more information.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
|
||
|
||
<span>Transaction</span>
|
||
|
||
handles.
|
||
</p>
|
||
<p>
|
||
In order to obtain the atomicity guarantee offered by
|
||
the transactional subsystem (that is, combine multiple
|
||
operations in a single unit of work), your application must use
|
||
transaction handles. These handles are obtained from your
|
||
|
||
|
||
|
||
<span>Environment</span>
|
||
objects. They should normally be short-lived, and their usage is
|
||
reasonably simple. To complete a transaction and save
|
||
the work it performed, you
|
||
call its <tt class="methodname">commit()</tt> method. To
|
||
complete a transaction and discard its work, you call its
|
||
<tt class="methodname">abort()</tt> method.
|
||
</p>
|
||
<p>
|
||
In addition, it is possible to use auto commit if you want
|
||
to transactional protect a single write operation. Auto
|
||
commit allows a transaction to be used without
|
||
obtaining an explicit transaction handle. See
|
||
<a href="autocommit.html">Auto Commit</a>
|
||
for information on how to use auto commit.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Entity Store
|
||
</p>
|
||
<p>
|
||
If you are using the DPL, then you must
|
||
configure your entity stores for transactional
|
||
support before opening them (that is, before
|
||
obtaining a primary key from them for the first
|
||
time).
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span>Database</span>
|
||
|
||
open requirements.
|
||
</p>
|
||
<p>
|
||
|
||
<span>In addition to using
|
||
environments and initializing the
|
||
correct subsystems, your</span>
|
||
|
||
application must transaction protect the database
|
||
|
||
opens<span>,
|
||
and any secondary index associations,</span>
|
||
|
||
if subsequent operations on the databases are to be transaction
|
||
protected. The database open and secondary index
|
||
association are commonly transaction protected using
|
||
auto commit.
|
||
</p>
|
||
<p>
|
||
Note that if you are using the DPL, you do not
|
||
have to explicitly do anything to the underlying
|
||
databases unless you want to modify their default
|
||
behavior — such as the isolation level that they
|
||
use, for example.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
Deadlock detection.
|
||
</p>
|
||
<p>
|
||
Typically transactional applications use multiple
|
||
threads of control when accessing the database. Any
|
||
time multiple threads are used on a single resource,
|
||
the potential for lock contention arises. In turn, lock
|
||
contention can lead to deadlocks. See
|
||
<a href="blocking_deadlocks.html">Locks, Blocks, and Deadlocks</a>
|
||
for more information.
|
||
</p>
|
||
<p>
|
||
Therefore, transactional applications must frequently
|
||
include code for detecting and responding to deadlocks.
|
||
Note that this requirement is not
|
||
<span class="emphasis"><em>specific</em></span> to transactions
|
||
– you can certainly write concurrent
|
||
non-transactional DB applications. Further, not
|
||
every transactional application uses concurrency and
|
||
so not every transactional application must
|
||
manage deadlocks. Still, deadlock management is so
|
||
frequently a characteristic of transactional
|
||
applications that we discuss it in this
|
||
book. See <a href="txnconcurrency.html">Concurrency</a>
|
||
for more information.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="sect2" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h3 class="title"><a id="multithread-intro"></a>Multi-threaded
|
||
<span>and Multi-process</span>
|
||
Applications</h3>
|
||
</div>
|
||
</div>
|
||
<div></div>
|
||
</div>
|
||
<p>
|
||
DB is designed to support multi-threaded <span>and
|
||
multi-process</span> applications, but their usage means
|
||
you must pay careful attention to issues of concurrency.
|
||
Transactions help your application's concurrency by providing various levels of
|
||
isolation for your threads of control. In addition, DB
|
||
provides mechanisms that allow you to detect and respond to
|
||
deadlocks (but strictly speaking, this is not limited to just
|
||
transactional applications).
|
||
</p>
|
||
<p>
|
||
<span class="emphasis"><em>Isolation</em></span> means that database modifications made by
|
||
one transaction will not normally be seen by readers from another
|
||
transaction until the first commits its changes. Different threads
|
||
use different transaction handles, so
|
||
this mechanism is normally used to provide isolation between
|
||
database operations performed by different threads.
|
||
</p>
|
||
<p>
|
||
Note that DB supports different isolation levels. For example,
|
||
you can configure your application to see uncommitted reads, which means
|
||
that one transaction can see data that has been modified but not yet
|
||
committed by another transaction. Doing this might mean your
|
||
transaction reads data "dirtied" by another transaction,
|
||
but which subsequently might change before that
|
||
other transaction commits its changes.
|
||
On the other hand, lowering your isolation
|
||
requirements means that your application can experience
|
||
improved throughput due to reduced lock contention.
|
||
</p>
|
||
<p>
|
||
For more information on concurrency, on managing isolation
|
||
levels, and on deadlock detection, see <a href="txnconcurrency.html">Concurrency</a>.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="index.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Preface </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Recoverability</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|