libdb/docs/programmer_reference/txn_limits.html
2011-12-19 19:07:10 -05:00

140 lines
5.8 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Transaction limits</title>
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
<link rel="up" href="txn.html" title="Chapter 19.  The Transaction Subsystem" />
<link rel="prev" href="txn_config.html" title="Configuring transactions" />
<link rel="next" href="sequence.html" title="Chapter 20.  Sequences" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 11.2.5.2</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Transaction limits</th>
</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>
<td width="20%" align="right"> <a accesskey="n" href="sequence.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="txn_limits"></a>Transaction limits</h2>
</div>
</div>
</div>
<div class="toc">
<dl>
<dt>
<span class="sect2">
<a href="txn_limits.html#id3975315">Transaction IDs</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="txn_limits.html#id3974049">Cursors</a>
</span>
</dt>
<dt>
<span class="sect2">
<a href="txn_limits.html#id3974034">Multiple Threads of Control</a>
</span>
</dt>
</dl>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3975315"></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>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3974049"></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>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="id3974034"></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>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="txn_config.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="txn.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="sequence.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Configuring transactions </td>
<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>
</tr>
</table>
</div>
</body>
</html>