1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
<!--$Id: why.html,v 1.1.1.1 2003/11/20 22:14:22 toshok Exp $-->
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Why transactions?</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
</head>
<body bgcolor=white>
<table width="100%"><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
<td align=right><a href="../../ref/transapp/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/term.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p>
<h1 align=center>Why transactions?</h1>
<p>Perhaps the first question to answer is "Why transactions?" There are
a number of reasons to include transactional support in your applications.
The most common ones are the following:
<p><dl compact>
<p><dt>Recoverability<dd>Applications often need to ensure that no matter how the system or
application fails, previously saved data is available the next time the
application runs.
<p><dt>Atomicity<dd>Applications may need to make multiple changes to one or more databases,
but ensure that either all of the changes happen, or none of them
happens. Transactions guarantee that a group of changes are atomic;
that is, if the application or system fails, either all of the changes
to the databases will appear when the application next runs, or none of
them.
<p><dt>Isolation<dd>Applications may need to make changes in isolation, that is, ensure that
only a single thread of control is modifying a key/data pair at a time.
Transactions ensure each thread of control sees all records as if all
other transactions either completed before or after its transaction.
</dl>
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/transapp/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/term.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
</body>
</html>
|
