mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
118 lines
5.8 KiB
HTML
118 lines
5.8 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>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>
|