- Why Transactions?
- Terminology
- Application Structure
- Opening the Environment
- Opening the Databases
- Recoverability and Deadlock Avoidance
- Atomicity
- Repeatable Reads
- Transactional Cursors
- Nested Transactions
- Environment Infrastructure
- Deadlock Detection
- Performing Checkpoints
- Database and Log File Archival Procedures
- Log File Removal
- Recovery Procedures
- Recovery and Filesystem Operations
- Berkeley DB Recoverability
- Transaction Throughput
This chapter is from the book
This chapter is from the book
This chapter is from the book
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 are when the application is doing a read-modify-write operation and so requires atomicity, and when an application requires the ability to repeatedly access a data item knowing that it will not have changed. A repeatable read simply means that, for the life of the transaction, every time a request is made by any thread of control to read a data item, it will be unchanged from its previous value; that is, that the value will not change until the transaction commits or aborts.