Here are some definitions that will be helpful in
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 a 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 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
- Recovery is what makes the
database consistent after a system or application
failure. The recovery process includes 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. Whenever system or application failure
occurs, applications must usually run
recovery.
-
Deadlock
- Deadlock, in its simplest
form, 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.