diff options
Diffstat (limited to 'docs/programmer_reference/txn_limits.html')
| -rw-r--r-- | docs/programmer_reference/txn_limits.html | 95 |
1 files changed, 52 insertions, 43 deletions
diff --git a/docs/programmer_reference/txn_limits.html b/docs/programmer_reference/txn_limits.html index 5c8e87f8..c30639c6 100644 --- a/docs/programmer_reference/txn_limits.html +++ b/docs/programmer_reference/txn_limits.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="txn_config.html">Prev</a> </td> - <th width="60%" align="center">Chapter 19. - The Transaction Subsystem - </th> + <th width="60%" align="center">Chapter 19. The Transaction Subsystem </th> <td width="20%" align="right"> <a accesskey="n" href="sequence.html">Next</a></td> </tr> </table> @@ -42,17 +40,17 @@ <dl> <dt> <span class="sect2"> - <a href="txn_limits.html#idp3173248">Transaction IDs</a> + <a href="txn_limits.html#idp2936928">Transaction IDs</a> </span> </dt> <dt> <span class="sect2"> - <a href="txn_limits.html#idp3049928">Cursors</a> + <a href="txn_limits.html#idp2856976">Cursors</a> </span> </dt> <dt> <span class="sect2"> - <a href="txn_limits.html#idp3082656">Multiple Threads of Control</a> + <a href="txn_limits.html#idp2907576">Multiple Threads of Control</a> </span> </dt> </dl> @@ -61,58 +59,71 @@ <div class="titlepage"> <div> <div> - <h3 class="title"><a id="idp3173248"></a>Transaction IDs</h3> + <h3 class="title"><a id="idp2936928"></a>Transaction IDs</h3> </div> </div> </div> - <p>Transactions are identified by 31-bit unsigned integers, which means -there are just over two billion unique transaction IDs. When a database -environment is initially created or recovery is run, the transaction ID -name space is reset, and new transactions are numbered starting from -0x80000000 (2,147,483,648). The IDs will wrap if the maximum -transaction ID is reached, starting again from 0x80000000. The most -recently allocated transaction ID is the <span class="bold"><strong>st_last_txnid</strong></span> value in -the transaction statistics information, and can be displayed by the -<a href="../api_reference/C/db_stat.html" class="olink">db_stat</a> utility.</p> + <p> + Transactions are identified by 31-bit unsigned integers, + which means there are just over two billion unique + transaction IDs. When a database environment is initially + created or recovery is run, the transaction ID name space + is reset, and new transactions are numbered starting from + 0x80000000 (2,147,483,648). The IDs will wrap if the + maximum transaction ID is reached, starting again from + 0x80000000. The most recently allocated transaction ID is + the <span class="bold"><strong>st_last_txnid</strong></span> value + in the transaction statistics information, and can be + displayed by the <a href="../api_reference/C/db_stat.html" class="olink">db_stat</a> utility. + </p> </div> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> - <h3 class="title"><a id="idp3049928"></a>Cursors</h3> + <h3 class="title"><a id="idp2856976"></a>Cursors</h3> </div> </div> </div> - <p>When using transactions, cursors are localized to a single transaction. -That is, a cursor may not span transactions, and must be opened and -closed within a single transaction. In addition, intermingling -transaction-protected cursor operations and non-transaction-protected -cursor operations on the same database in a single thread of control is -practically guaranteed to deadlock because the locks obtained for -transactions and non-transactions can conflict.</p> + <p> + When using transactions, cursors are localized to a + single transaction. That is, a cursor may not span + transactions, and must be opened and closed within a + single transaction. In addition, intermingling + transaction-protected cursor operations and + non-transaction-protected cursor operations on the same + database in a single thread of control is practically + guaranteed to deadlock because the locks obtained for + transactions and non-transactions can conflict. + </p> </div> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> - <h3 class="title"><a id="idp3082656"></a>Multiple Threads of Control</h3> + <h3 class="title"><a id="idp2907576"></a>Multiple Threads of Control</h3> </div> </div> </div> - <p>Because transactions must hold all their locks until commit, a single -transaction may accumulate a large number of long-term locks during its -lifetime. As a result, when two concurrently running transactions -access the same database, there is strong potential for conflict. -Although Berkeley DB allows an application to have multiple outstanding -transactions active within a single thread of control, great care must -be taken to ensure that the transactions do not block each other (for -example, attempt to obtain conflicting locks on the same data). If two -concurrently active transactions in the same thread of control do -encounter a lock conflict, the thread of control will deadlock so that -the deadlock detector cannot detect the problem. In this case, there -is no true deadlock, but because the transaction on which a transaction -is waiting is in the same thread of control, no forward progress can be -made.</p> + <p> + Because transactions must hold all their locks until + commit, a single transaction may accumulate a large number + of long-term locks during its lifetime. As a result, when + two concurrently running transactions access the same + database, there is strong potential for conflict. Although + Berkeley DB allows an application to have multiple + outstanding transactions active within a single thread of + control, great care must be taken to ensure that the + transactions do not block each other (for example, attempt + to obtain conflicting locks on the same data). If two + concurrently active transactions in the same thread of + control do encounter a lock conflict, the thread of + control will deadlock so that the deadlock detector cannot + detect the problem. In this case, there is no true + deadlock, but because the transaction on which a + transaction is waiting is in the same thread of control, + no forward progress can be made. + </p> </div> </div> <div class="navfooter"> @@ -130,9 +141,7 @@ made.</p> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Chapter 20. - Sequences - </td> + <td width="40%" align="right" valign="top"> Chapter 20. Sequences </td> </tr> </table> </div> |