Gecko [ 122.154.134.11 ]

Name	Size	Permission
admin.html	3.28 KB	-rw-r--r--
app.html	16.29 KB	-rw-r--r--
archival.html	9.52 KB	-rw-r--r--
atomicity.html	4.19 KB	-rw-r--r--
checkpoint.html	4.7 KB	-rw-r--r--
cursor.html	4.99 KB	-rw-r--r--
data_open.html	5.89 KB	-rw-r--r--
deadlock.html	5.78 KB	-rw-r--r--
env_open.html	6.53 KB	-rw-r--r--
fail.html	4.98 KB	-rw-r--r--
faq.html	7.8 KB	-rw-r--r--
filesys.html	4.22 KB	-rw-r--r--
hotfail.html	5.51 KB	-rw-r--r--
inc.html	6.1 KB	-rw-r--r--
intro.html	2.72 KB	-rw-r--r--
logfile.html	3.57 KB	-rw-r--r--
nested.html	4.19 KB	-rw-r--r--
put.html	10.51 KB	-rw-r--r--
read.html	7.93 KB	-rw-r--r--
reclimit.html	9.7 KB	-rw-r--r--
recovery.html	6.42 KB	-rw-r--r--
term.html	4.09 KB	-rw-r--r--
throughput.html	7.14 KB	-rw-r--r--
transapp.cs	10.34 KB	-rw-r--r--
tune.html	10.76 KB	-rw-r--r--
why.html	2.49 KB	-rw-r--r--
writetest.cs	2.32 KB	-rw-r--r--

Code Editor : why.html

<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,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><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></td>
<td align=right><a href="../transapp/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/term.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Why transactions?
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:
 
Recoverability<ul compact><li>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. This is often called Durability.</ul>
Atomicity<ul compact><li>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.</ul>
Isolation<ul compact><li>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.</ul>
 
<table width="100%"><tr><td> </td><td align=right><a href="../transapp/intro.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/term.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

${this.title}

Code Editor : why.html