Berkeley DB

Repeatable Reads

The fourth reason listed for using transactions is repeatable reads. Generally, most applications do not need to place reads inside a transaction for performance reasons. The problem is that a transactionally protected cursor, reading each key/data pair in a database, will acquire a read lock on most of the pages in the database, and so will gradually block all write operations on the databases until the transaction commits or aborts. Note, however, that if there are update transactions present in the application, the reading transactions must still use locking, and should be prepared to repeat any operation (possibly closing and reopening a cursor) that fails with a return value of DB_LOCK_DEADLOCK.

The exceptions to this rule ...