Sindbad~EG File Manager
<?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>Atomicity</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_put.html" title="Recoverability and deadlock handling" />
<link rel="next" href="transapp_inc.html" title="Isolation" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 18.1.40</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Atomicity</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="transapp_put.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_inc.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_atomicity"></a>Atomicity</h2>
</div>
</div>
</div>
<p>
The second reason listed for using transactions was
<span class="emphasis"><em>atomicity</em></span>. 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.
</p>
<p>
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_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> and <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">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.)
</p>
<p>
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_reference/C/dbput.html" class="olink">DB->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.
</p>
<p>
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.
</p>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="transapp_put.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_inc.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Recoverability and deadlock handling </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Isolation</td>
</tr>
</table>
</div>
</body>
</html>
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists