diff options
Diffstat (limited to 'db/docs/ref/am_misc/stability.html')
| -rw-r--r-- | db/docs/ref/am_misc/stability.html | 54 |
1 files changed, 54 insertions, 0 deletions
diff --git a/db/docs/ref/am_misc/stability.html b/db/docs/ref/am_misc/stability.html new file mode 100644 index 000000000..2570f8cc4 --- /dev/null +++ b/db/docs/ref/am_misc/stability.html @@ -0,0 +1,54 @@ +<!--Id: stability.so,v 10.28 2001/04/04 22:32:29 bostic Exp --> +<!--Copyright 1997-2001 by Sleepycat Software, Inc.--> +<!--All rights reserved.--> +<html> +<head> +<title>Berkeley DB Reference Guide: Cursor stability</title> +<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> +<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> +</head> +<body bgcolor=white> + <a name="2"><!--meow--></a> <a name="3"><!--meow--></a> +<table width="100%"><tr valign=top> +<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></h3></td> +<td align=right><a href="../../ref/am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> +</td></tr></table> +<p> +<h1 align=center>Cursor stability</h1> +<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>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_c/dbc_get.html#DB_CURRENT">DB_CURRENT</a> call +on the cursor is guaranteed to return the same record as was returned +on the last call to the cursor. + <a name="4"><!--meow--></a> <a name="5"><!--meow--></a> +<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. Finally, Berkeley DB +provides degree 1 isolation when the <a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> flag is +specified; that is, reads may see data modified in transactions which +have not yet committed. +<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. +<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> +</td></tr></table> +<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> +</body> +</html> |