0IABerkeley DB Reference Guide: Transaction Subsystem[P;

Berkeley DB Reference Guide: Transaction Subsystem



&

Cursor Stability



EIn the absence of locking, no guarantees are made about the stability-of cursors in different processes or threads.MHowever, the btree and recno access methods guarantee that cursor operations,Cinterspersed with other cursor or non-cursor operations in the same<thread of control (i.e., thread or single-threaded process),Awill always return keys in order and will return each non-deletedkey/data pair exactly once.@Because the hash access method uses a dynamic hashing algorithm,Hit cannot guarantee any form of stability in the presence of inserts and$deletes unless locking is performed.

>If locking was specified when the Berkeley DB file was opened,#but transactions are not in effect,Gthe access methods provide repeatable reads with respect to the cursor.IThat is, a DB_CURRENT call on the cursor is guaranteed to return the same6record as was returned on the last call to the cursor.

GIn the presence of transactions, the access method calls between a call·to txn_begin and a call to txn_abort or txn_commitprovide degree 3 consistency.For all access methods,Ka 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,Ithe transaction performing the scan inserts a new pair into the database,>it is possible that duplicate key/data pairs will be returned.

AIÿÿ