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 : atomicity.html

<html>
<head>
<title>Berkeley DB Reference Guide: Atomicity</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/put.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/inc.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Atomicity
The second reason listed for using transactions was atomicity.
Atomicity means that multiple operations can be grouped into a single
logical entity, that is, other threads of control accessing the database
will either see all of the changes or none of the changes. Atomicity
is important for applications wanting to update two related databases
(for example, a primary database and secondary index) in a single
logical action. Or, for an application wanting to update multiple
records in one database in a single logical action.
Any number of operations on any number of databases can be included in
a single transaction to ensure the atomicity of the operations. There
is, however, a trade-off between the number of operations included in
a single transaction and both throughput and the possibility of
deadlock. The reason for this is because transactions acquire locks
throughout their lifetime and do not release the locks until commit or
abort time. So, the more operations included in a transaction, the more
likely it is that a transaction will block other operations and that
deadlock will occur. However, each transaction commit requires a
synchronous disk I/O, so grouping multiple operations into a transaction
can increase overall throughput. (There is one exception to this: the
<a href="../../api_c/env_set_flags.html#DB_TXN_WRITE_NOSYNC">DB_TXN_WRITE_NOSYNC</a> and <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a> flags cause
transactions to exhibit the ACI (atomicity, consistency and isolation)
properties, but not D (durability); avoiding the write and/or
synchronous disk I/O on transaction commit greatly increases transaction
throughput for some applications.)
When applications do create complex transactions, they often avoid
having more than one complex transaction at a time because simple
operations like a single <a href="../../api_c/db_put.html">DB-&gt;put</a> are unlikely to deadlock with
each other or the complex transaction; while multiple complex
transactions are likely to deadlock with each other because they will
both acquire many locks over their lifetime. Alternatively, complex
transactions can be broken up into smaller sets of operations, and each
of those sets may be encapsulated in a nested transaction. Because
nested transactions may be individually aborted and retried without
causing the entire transaction to be aborted, this allows complex
transactions to proceed even in the face of heavy contention, repeatedly
trying the suboperations until they succeed.
It is also helpful to order operations within a transaction; that is,
access the databases and items within the databases in the same order,
to the extent possible, in all transactions. Accessing databases and
items in different orders greatly increases the likelihood of operations
being blocked and failing due to deadlocks.
<table width="100%"><tr><td> </td><td align=right><a href="../transapp/put.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/inc.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 : atomicity.html