diff options
Diffstat (limited to 'docs/programmer_reference/transapp_nested.html')
| -rw-r--r-- | docs/programmer_reference/transapp_nested.html | 112 |
1 files changed, 65 insertions, 47 deletions
diff --git a/docs/programmer_reference/transapp_nested.html b/docs/programmer_reference/transapp_nested.html index 0312ae47..61765982 100644 --- a/docs/programmer_reference/transapp_nested.html +++ b/docs/programmer_reference/transapp_nested.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_cursor.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_admin.html">Next</a></td> </tr> </table> @@ -38,48 +36,67 @@ </div> </div> </div> - <p>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.</p> - <p>Normally, when beginning a transaction, the application will pass a NULL -value for the parent argument to <a href="../api_reference/C/txnbegin.html" class="olink">DB_ENV->txn_begin()</a>. If, however, the -parent argument is a <a href="../api_reference/C/txn.html" class="olink">TXN</a> 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 -<span class="emphasis"><em>child transactions</em></span>.</p> - <p>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.</p> - <p>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.</p> - <p>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.</p> - <p>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.</p> + <p> + 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. + </p> + <p> + Normally, when beginning a transaction, the application will + pass a NULL value for the parent argument to <a href="../api_reference/C/txnbegin.html" class="olink">DB_ENV->txn_begin()</a>. If, + however, the parent argument is a <a href="../api_reference/C/txn.html" class="olink">TXN</a> 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 <span class="emphasis"><em>child + transactions</em></span>. + </p> + <p> + 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. + </p> + <p> + 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. + </p> + <p> + 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. + </p> + <p> + 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. + </p> </div> <div class="navfooter"> <hr /> @@ -96,7 +113,8 @@ prepared.</p> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Environment infrastructure</td> + <td width="40%" align="right" valign="top"> Environment + infrastructure</td> </tr> </table> </div> |