Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 11. - Berkeley DB Transactional Data Store Applications -	Chapter 11. Berkeley DB Transactional Data Store Applications	Next

@@ -38,47 +36,63 @@

The second reason listed for using transactions was atomicity. -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.

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 -DB_TXN_WRITE_NOSYNC and DB_TXN_NOSYNC 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.)

When applications do create complex transactions, they often avoid -having more than one complex transaction at a time because simple -operations like a single DB->put() 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.

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.

+ The second reason listed for using transactions was + atomicity. 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. +

+ 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 + DB_TXN_WRITE_NOSYNC and DB_TXN_NOSYNC 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.) +

+ When applications do create complex transactions, they often + avoid having more than one complex transaction at a time + because simple operations like a single DB->put() 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. +

+ 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. +