1<!--$Id: limits.so,v 10.38 2004/08/18 19:57:37 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Transaction limits</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Transaction Subsystem</dl></b></td> 14<td align=right><a href="/txn/config.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/sequence/intro.html"><img src="/images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Transaction limits</b></p> 17<b>Transaction IDs</b> 18<p>Transactions are identified by 31-bit unsigned integers, which means 19there are just over two billion unique transaction IDs. When a database 20environment is initially created or recovery is run, the transaction ID 21name space is reset, and new transactions are numbered starting from 220x80000000 (2,147,483,648). The IDs will wrap if the maximum 23transaction ID is reached, starting again from 0x80000000. The most 24recently allocated transaction ID is the <b>st_last_txnid</b> value in 25the transaction statistics information, and can be displayed by the 26<a href="/utility/db_stat.html">db_stat</a> utility.</p> 27<b>Cursors</b> 28<p>When using transactions, cursors are localized to a single transaction. 29That is, a cursor may not span transactions, and must be opened and 30closed within a single transaction. In addition, intermingling 31transaction-protected cursor operations and non-transaction-protected 32cursor operations on the same database in a single thread of control is 33practically guaranteed to deadlock because the locks obtained for 34transactions and non-transactions can conflict.</p> 35<b>Multiple Threads of Control</b> 36<p>Because transactions must hold all their locks until commit, a single 37transaction may accumulate a large number of long-term locks during its 38lifetime. As a result, when two concurrently running transactions 39access the same database, there is strong potential for conflict. 40Although Berkeley DB allows an application to have multiple outstanding 41transactions active within a single thread of control, great care must 42be taken to ensure that the transactions do not block each other (for 43example, attempt to obtain conflicting locks on the same data). If two 44concurrently active transactions in the same thread of control do 45encounter a lock conflict, the thread of control will deadlock so that 46the deadlock detector cannot detect the problem. In this case, there 47is no true deadlock, but because the transaction on which a transaction 48is waiting is in the same thread of control, no forward progress can be 49made.</p> 50<table width="100%"><tr><td><br></td><td align=right><a href="/txn/config.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/sequence/intro.html"><img src="/images/next.gif" alt="Next"></a> 51</td></tr></table> 52<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 53</body> 54</html> 55
