mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 09:06:25 +00:00
94 lines
4.8 KiB
HTML
94 lines
4.8 KiB
HTML
<?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>Cursor stability</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="am_misc.html" title="Chapter 4. Access Method Wrapup" />
|
||
<link rel="prev" href="am_misc_error.html" title="Error support" />
|
||
<link rel="next" href="am_misc_dbsizes.html" title="Database limits" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">Cursor stability</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="am_misc_error.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 4.
|
||
Access Method Wrapup
|
||
</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="am_misc_dbsizes.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="am_misc_stability"></a>Cursor stability</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>In the absence of locking, no guarantees are made about the stability
|
||
of cursors in different threads of control. However, the Btree, Queue
|
||
and Recno access methods guarantee that cursor operations, interspersed
|
||
with any other operation in the same thread of control will always
|
||
return keys in order and will return each non-deleted key/data pair
|
||
exactly once. Because the Hash access method uses a dynamic hashing
|
||
algorithm, it cannot guarantee any form of stability in the presence of
|
||
inserts and deletes unless transactional locking is performed.</p>
|
||
<p>If locking was specified when the Berkeley DB environment was opened, but
|
||
transactions are not in effect, the access methods provide repeatable
|
||
reads with respect to the cursor. That is, a <a href="../api_reference/C/dbcget.html#dbcget_DB_CURRENT" class="olink">DB_CURRENT</a> call
|
||
on the cursor is guaranteed to return the same record as was returned
|
||
on the last call to the cursor.</p>
|
||
<p>In the presence of transactions, the Btree, Hash and Recno access
|
||
methods provide degree 3 isolation (serializable transactions). The
|
||
Queue access method provides degree 3 isolation with the exception that
|
||
it permits phantom records to appear between calls. That is, deleted
|
||
records are not locked, therefore another transaction may replace a
|
||
deleted record between two calls to retrieve it. The record would not
|
||
appear in the first call but would be seen by the second call. For
|
||
readers not enclosed in transactions, all access method calls provide
|
||
degree 2 isolation, that is, reads are not repeatable. A transaction
|
||
may be declared to run with degree 2 isolation by specifying the
|
||
<a href="../api_reference/C/dbcget.html#dbcget_DB_READ_COMMITTED" class="olink">DB_READ_COMMITTED</a> flag. Finally, Berkeley DB provides degree 1 isolation
|
||
when the <a href="../api_reference/C/dbopen.html#dbopen_DB_READ_UNCOMMITTED" class="olink">DB_READ_UNCOMMITTED</a> flag is specified; that is, reads
|
||
may see data modified in transactions which have not yet committed.</p>
|
||
<p>For all access methods, a cursor scan of the database performed within
|
||
the context of a transaction is guaranteed to return each key/data pair
|
||
once and only once, except in the following case. If, while performing
|
||
a cursor scan using the Hash access method, the transaction performing
|
||
the scan inserts a new pair into the database, it is possible that
|
||
duplicate key/data pairs will be returned.</p>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="am_misc_error.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="am_misc.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="am_misc_dbsizes.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Error support </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Database limits</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|