← Back to branch summary

~ubuntu-branches/ubuntu/edgy/rpm/edgy

« back to all changes in this revision

Viewing changes to db/docs/ref/txn/limits.html

  • Committer: Bazaar Package Importer
  • Author(s): Joey Hess
  • Date: 2002-01-22 20:56:57 UTC
  • Revision ID: james.westby@ubuntu.com-20020122205657-l74j50mr9z8ofcl5
Tags: upstream-4.0.3
Import upstream version 4.0.3

Show diffs side-by-side

added added

removed removed

Lines of Context:
db/docs/ref/txn/limits.html
 
1
<!--$Id: limits.so,v 10.35 2001/05/22 01:44:42 bostic Exp $-->
 
2
<!--Copyright 1997-2001 by Sleepycat Software, Inc.-->
 
3
<!--All rights reserved.-->
 
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,b+tree,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><h3><dl><dt>Berkeley DB Reference Guide:<dd>Transaction Subsystem</dl></h3></td>
 
14
<td align=right><a href="../../ref/txn/config.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/txn/other.html"><img src="../../images/next.gif" alt="Next"></a>
 
15
</td></tr></table>
 
16
<p>
 
17
<h1 align=center>Transaction limits</h1>
 
18
<h3>Transaction IDs</h3>
 
19
<p>Transactions are identified uniquely by 32-bit unsigned integers.  The
 
20
high-order bit of the transaction ID is reserved (and defined to be 1),
 
21
resulting in just over two billion unique transaction IDs.  Each time
 
22
that recovery is run, the beginning transaction ID is reset with new
 
23
transactions being numbered, starting from 1.  This means that recovery
 
24
must be run at least once every two billion transactions.
 
25
<p>It is possible that some environments may need to be aware of this
 
26
limitation.  Consider an application performing 600 transactions a second
 
27
for 15 hours a day.  The transaction ID space will run out in roughly 66
 
28
days:
 
29
<p><blockquote><pre>2^31 / (600 * 15 * 60 * 60) = 66</pre></blockquote>
 
30
<p>Doing only 100 transactions a second exhausts the transaction ID space
 
31
in roughly one year.
 
32
<p>The transaction ID name space is initialized each time a database
 
33
environment is created or recovered.  If you reach the end of the
 
34
transaction ID name space, it must be handled as if an application or
 
35
system failure occurred.  The most recently allocated transaction
 
36
ID is the <b>st_last_txnid</b> value in the transaction statistics
 
37
information, and is displayed by the <a href="../../utility/db_stat.html">db_stat</a> utility.
 
38
<h3>Cursors</h3>
 
39
<p>When using transactions, cursors are localized to a single transaction.
 
40
That is, a cursor may not span transactions, and must be opened and
 
41
closed within a single transaction.  In addition, intermingling
 
42
transaction-protected cursor operations and non-transaction-protected
 
43
cursor operations on the same database in a single thread of control is
 
44
practically guaranteed to deadlock because the locks obtained for
 
45
transactions and non-transactions can conflict.
 
46
<h3>Multiple Threads of Control</h3>
 
47
<p>Because transactions must hold all their locks until commit, a single
 
48
transaction may accumulate a large number of long-term locks during its
 
49
lifetime.  As a result, when two concurrently running transactions
 
50
access the same database, there is strong potential for conflict.
 
51
Although Berkeley DB allows an application to have multiple outstanding
 
52
transactions active within a single thread of control, great care must
 
53
be taken to ensure that the transactions do not block each other (for
 
54
example, attempt to obtain conflicting locks on the same data).  If two
 
55
concurrently active transactions in the same thread of control do
 
56
encounter a lock conflict, the thread of control will deadlock so that
 
57
the deadlock detector cannot detect the problem.  In this case, there
 
58
is no true deadlock, but because the transaction on which a transaction
 
59
is waiting is in the same thread of control, no forward progress can be
 
60
made.
 
61
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/txn/config.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/txn/other.html"><img src="../../images/next.gif" alt="Next"></a>
 
62
</td></tr></table>
 
63
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
 
64
</body>
 
65
</html>