1<!--$Id: atomicity.so,v 10.3 2002/05/17 15:48:41 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Atomicity</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></b></td> 13<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> 14</td></tr></table> 15<p align=center><b>Atomicity</b></p> 16<p>The second reason listed for using transactions was <i>atomicity</i>. 17Atomicity means that multiple operations can be grouped into a single 18logical entity, that is, other threads of control accessing the database 19will either see all of the changes or none of the changes. Atomicity 20is important for applications wanting to update two related databases 21(for example, a primary database and secondary index) in a single 22logical action. Or, for an application wanting to update multiple 23records in one database in a single logical action.</p> 24<p>Any number of operations on any number of databases can be included in 25a single transaction to ensure the atomicity of the operations. There 26is, however, a trade-off between the number of operations included in 27a single transaction and both throughput and the possibility of 28deadlock. The reason for this is because transactions acquire locks 29throughout their lifetime and do not release the locks until commit or 30abort time. So, the more operations included in a transaction, the more 31likely it is that a transaction will block other operations and that 32deadlock will occur. However, each transaction commit requires a 33synchronous disk I/O, so grouping multiple operations into a transaction 34can increase overall throughput. (There is one exception to this: the 35<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 36transactions to exhibit the ACI (atomicity, consistency and isolation) 37properties, but not D (durability); avoiding the write and/or 38synchronous disk I/O on transaction commit greatly increases transaction 39throughput for some applications.)</p> 40<p>When applications do create complex transactions, they often avoid 41having more than one complex transaction at a time because simple 42operations like a single <a href="../../api_c/db_put.html">DB->put</a> are unlikely to deadlock with 43each other or the complex transaction; while multiple complex 44transactions are likely to deadlock with each other because they will 45both acquire many locks over their lifetime. Alternatively, complex 46transactions can be broken up into smaller sets of operations, and each 47of those sets may be encapsulated in a nested transaction. Because 48nested transactions may be individually aborted and retried without 49causing the entire transaction to be aborted, this allows complex 50transactions to proceed even in the face of heavy contention, repeatedly 51trying the suboperations until they succeed.</p> 52<p>It is also helpful to order operations within a transaction; that is, 53access the databases and items within the databases in the same order, 54to the extent possible, in all transactions. Accessing databases and 55items in different orders greatly increases the likelihood of operations 56being blocked and failing due to deadlocks.</p> 57<table width="100%"><tr><td><br></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> 58</td></tr></table> 59<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 60</body> 61</html> 62