- 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
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Terminology
The following are some definitions that will be helpful for understanding transactions:
Thread of control. Berkeley DB is indifferent to the type or style of threads being used by the application; or, for that matter, if threads are being used at all, because Berkeley DB supports multiprocess access. In the Berkeley DB documentation, any time we refer to a thread of control, it can be read as a true thread (one of many in an application's address space) or a process.
Free-threaded. A Berkeley DB handle that can be used by multiple threads simultaneously without any application-level synchronization is called free-threaded.
Transaction. A transaction is one or more operations on one or more databases that should be treated as a single unit of work. For example, changes to a set of databases, in which either all of the changes must be applied to the database(s) or none of them should. Applications specify when each transaction starts, what database operations are included in it, and when it ends.
Transaction abort/commit. Every transaction ends by committing or aborting. If a transaction commits, Berkeley DB guarantees that any database changes included in the transaction will never be lost, even after system or application failure. If a transaction aborts, or is uncommitted when the system or application fails, then the changes involved will never appear in the database.
System or application failure. System or application failure is the phrase that we use to describe something bad happening near your data. It can be an application dumping core, being interrupted by a signal, the disk filling up, or the entire system crashing. In any case, for whatever reason, the application can no longer make forward progress, and its databases are left in an unknown state.
Recovery. Whenever system or application failure occurs, the application must run recovery. Recovery is what makes the database consistent; that is, the recovery process includes a review of log files and databases to ensure that the changes from each committed transaction appear in the database, and that no changes from an unfinished (or aborted) transaction do.
Deadlock. In its simplest form, deadlock happens when one thread of control owns resource A, but needs resource B; while another thread of control owns resource B, but needs resource A. Neither thread of control can make progress, and so one has to give up and release all its resources, at which time the remaining thread of control can make forward progress.