1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
<!--$Id: limits.so,v 10.38 2004/08/18 19:57:37 bostic Exp $-->
<!--Copyright 1997-2004 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Transaction limits</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<a name="2"><!--meow--></a>
<table width="100%"><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Transaction Subsystem</dl></h3></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>
</td></tr></table>
<p>
<h3 align=center>Transaction limits</h3>
<h3>Transaction IDs</h3>
<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 <b>st_last_txnid</b> value in
the transaction statistics information, and can be displayed by the
<a href="../../utility/db_stat.html">db_stat</a> utility.</p>
<h3>Cursors</h3>
<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>
<h3>Multiple Threads of Control</h3>
<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>
<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>
</td></tr></table>
<p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2004</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font>
</body>
</html>
|
