Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 4. - Access Method Wrapup -	Chapter 4. Access Method Wrapup	Next

@@ -38,38 +36,53 @@

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.

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 DB_CURRENT call -on the cursor is guaranteed to return the same record as was returned -on the last call to the cursor.

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 -DB_READ_COMMITTED flag. Finally, Berkeley DB provides degree 1 isolation -when the DB_READ_UNCOMMITTED flag is specified; that is, reads -may see data modified in transactions which have not yet committed.

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.

+ 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. +

+ 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 DB_CURRENT call on the cursor is guaranteed to + return the same record as was returned on the last call to the + cursor. +

+ 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 DB_READ_COMMITTED flag. Finally, + Berkeley DB provides degree 1 isolation when the + DB_READ_UNCOMMITTED flag is specified; that is, reads may + see data modified in transactions which have not yet + committed. +

+ 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. +