1<!--$Id: stability.so,v 10.30 2005/02/10 20:02:34 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Cursor stability</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,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><a name="3"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></b></td> 14<td align=right><a href="../am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Cursor stability</b></p> 17<p>In the absence of locking, no guarantees are made about the stability 18of cursors in different threads of control. However, the Btree, Queue 19and Recno access methods guarantee that cursor operations, interspersed 20with any other operation in the same thread of control will always 21return keys in order and will return each non-deleted key/data pair 22exactly once. Because the Hash access method uses a dynamic hashing 23algorithm, it cannot guarantee any form of stability in the presence of 24inserts and deletes unless transactional locking is performed.</p> 25<p>If locking was specified when the Berkeley DB environment was opened, but 26transactions are not in effect, the access methods provide repeatable 27reads with respect to the cursor. That is, a <a href="../../api_c/dbc_get.html#DB_CURRENT">DB_CURRENT</a> call 28on the cursor is guaranteed to return the same record as was returned 29on the last call to the cursor.</p> 30<a name="4"><!--meow--></a><a name="5"><!--meow--></a> 31<p>In the presence of transactions, the Btree, Hash and Recno access 32methods provide degree 3 isolation (serializable transactions). The 33Queue access method provides degree 3 isolation with the exception that 34it permits phantom records to appear between calls. That is, deleted 35records are not locked, therefore another transaction may replace a 36deleted record between two calls to retrieve it. The record would not 37appear in the first call but would be seen by the second call. For 38readers not enclosed in transactions, all access method calls provide 39degree 2 isolation, that is, reads are not repeatable. A transaction 40may be declared to run with degree 2 isolation by specifying the 41<a href="../../api_c/db_cursor.html#DB_READ_COMMITTED">DB_READ_COMMITTED</a> flag. Finally, Berkeley DB provides degree 1 isolation 42when the <a href="../../api_c/db_open.html#DB_READ_UNCOMMITTED">DB_READ_UNCOMMITTED</a> flag is specified; that is, reads 43may see data modified in transactions which have not yet committed.</p> 44<p>For all access methods, a cursor scan of the database performed within 45the context of a transaction is guaranteed to return each key/data pair 46once and only once, except in the following case. If, while performing 47a cursor scan using the Hash access method, the transaction performing 48the scan inserts a new pair into the database, it is possible that 49duplicate key/data pairs will be returned.</p> 50<table width="100%"><tr><td><br></td><td align=right><a href="../am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> 51</td></tr></table> 52<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 53</body> 54</html> 55