mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 09:06:25 +00:00
103 lines
5.5 KiB
HTML
103 lines
5.5 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 11.2.5.3</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>
|