diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/transapp_atomicity.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/transapp_atomicity.html')
| -rw-r--r-- | docs/programmer_reference/transapp_atomicity.html | 104 |
1 files changed, 59 insertions, 45 deletions
diff --git a/docs/programmer_reference/transapp_atomicity.html b/docs/programmer_reference/transapp_atomicity.html index 8813e7a2..a5d8a748 100644 --- a/docs/programmer_reference/transapp_atomicity.html +++ b/docs/programmer_reference/transapp_atomicity.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </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> + <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> @@ -38,47 +36,63 @@ </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> + <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 /> |