summaryrefslogtreecommitdiff
path: root/db/docs/ref/am_misc/stability.html
diff options
context:
space:
mode:
authorjbj <devnull@localhost>2001-05-13 19:58:25 +0000
committerjbj <devnull@localhost>2001-05-13 19:58:25 +0000
commit2af040895b279eca8fb5a44240da7e42c8b4ac66 (patch)
tree1b74621cfd1f4531a39786c4b06a59bc0e92dbf7 /db/docs/ref/am_misc/stability.html
parent9b44f1b7168b70652f7fad2e0da6fdade4b965d7 (diff)
downloadlibrpm-tizen-2af040895b279eca8fb5a44240da7e42c8b4ac66.tar.gz
librpm-tizen-2af040895b279eca8fb5a44240da7e42c8b4ac66.tar.bz2
librpm-tizen-2af040895b279eca8fb5a44240da7e42c8b4ac66.zip
Initial revision
CVS patchset: 4782 CVS date: 2001/05/13 19:58:25
Diffstat (limited to 'db/docs/ref/am_misc/stability.html')
-rw-r--r--db/docs/ref/am_misc/stability.html54
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>