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,48 +36,67 @@

Berkeley DB provides support for nested transactions. Nested transactions -allow an application to decompose a large or long-running transaction -into smaller units that may be independently aborted.

Normally, when beginning a transaction, the application will pass a NULL -value for the parent argument to DB_ENV->txn_begin(). If, however, the -parent argument is a TXN handle, the newly created transaction -will be treated as a nested transaction within the parent. Transactions -may nest arbitrarily deeply. For the purposes of this discussion, -transactions created with a parent identifier will be called -child transactions.

Once a transaction becomes a parent, as long as any of its child -transactions are unresolved (that is, they have neither committed nor -aborted), the parent may not issue any Berkeley DB calls except to begin more -child transactions, or to commit or abort. For example, it may not -issue any access method or cursor calls. After all of a parent's -children have committed or aborted, the parent may again request -operations on its own behalf.

The semantics of nested transactions are as follows. When a child -transaction is begun, it inherits all the locks of its parent. This -means that the child will never block waiting on a lock held by its -parent. Further, locks held by two children of the same parent will -also conflict. To make this concrete, consider the following set of -transactions and lock acquisitions.

Transaction T1 is the parent transaction. It acquires a write lock on -item A and then begins two child transactions: C1 and C2. C1 also wants -to acquire a write lock on A; this succeeds. If C2 attempts to acquire -a write lock on A, it will block until C1 releases the lock, at which -point it will succeed. Now, let's say that C1 acquires a write lock on -B. If C2 now attempts to obtain a lock on B, it will block. However, -let's now assume that C1 commits. Its locks are anti-inherited, which -means they are given to T1, so T1 will now hold a lock on B. At this -point, C2 would be unblocked and would then acquire a lock on B.

Child transactions are entirely subservient to their parent transaction. -They may abort, undoing their operations regardless of the eventual fate -of the parent. However, even if a child transaction commits, if its -parent transaction is eventually aborted, the child's changes are undone -and the child's transaction is effectively aborted. Any child -transactions that are not yet resolved when the parent commits or aborts -are resolved based on the parent's resolution -- committing if the -parent commits and aborting if the parent aborts. Any child -transactions that are not yet resolved when the parent prepares are also -prepared.

+ Berkeley DB provides support for nested transactions. Nested + transactions allow an application to decompose a large or + long-running transaction into smaller units that may be + independently aborted. +

+ Normally, when beginning a transaction, the application will + pass a NULL value for the parent argument to DB_ENV->txn_begin(). If, + however, the parent argument is a TXN handle, the newly + created transaction will be treated as a nested transaction + within the parent. Transactions may nest arbitrarily deeply. + For the purposes of this discussion, transactions created with + a parent identifier will be called child + transactions. +

+ Once a transaction becomes a parent, as long as any of its + child transactions are unresolved (that is, they have neither + committed nor aborted), the parent may not issue any Berkeley + DB calls except to begin more child transactions, or to commit + or abort. For example, it may not issue any access method or + cursor calls. After all of a parent's children have committed + or aborted, the parent may again request operations on its own + behalf. +

+ The semantics of nested transactions are as follows. When a + child transaction is begun, it inherits all the locks of its + parent. This means that the child will never block waiting on + a lock held by its parent. Further, locks held by two children + of the same parent will also conflict. To make this concrete, + consider the following set of transactions and lock + acquisitions. +

+ Transaction T1 is the parent transaction. It acquires a + write lock on item A and then begins two child transactions: + C1 and C2. C1 also wants to acquire a write lock on A; this + succeeds. If C2 attempts to acquire a write lock on A, it will + block until C1 releases the lock, at which point it will + succeed. Now, let's say that C1 acquires a write lock on B. If + C2 now attempts to obtain a lock on B, it will block. However, + let's now assume that C1 commits. Its locks are + anti-inherited, which means they are given to T1, so T1 will + now hold a lock on B. At this point, C2 would be unblocked and + would then acquire a lock on B. +

+ Child transactions are entirely subservient to their parent + transaction. They may abort, undoing their operations + regardless of the eventual fate of the parent. However, even + if a child transaction commits, if its parent transaction is + eventually aborted, the child's changes are undone and the + child's transaction is effectively aborted. Any child + transactions that are not yet resolved when the parent commits + or aborts are resolved based on the parent's resolution -- + committing if the parent commits and aborting if the parent + aborts. Any child transactions that are not yet resolved when + the parent prepares are also prepared. +

@@ -96,7 +113,8 @@ prepared.

Home - Environment infrastructure + Environment + infrastructure