,INBerkeley DB Reference Guide: Transaction Protected Applications[PH

Berkeley DB Reference Guide: Transaction Protected Applications



"

Introduction



GSo far, this Reference Guide has discussed how applications can use theGBerkeley DB Access Methods to store and retrieve data items to and from7database files. This chapter will discuss how to writeFapplications to include transactional support. First, there are a fewterms that will be helpful:

r

System or application failure
This is the phrase that we will use to describe when something bad happensInear your data. It can be an application dumping core, being interruptedHby a signal, the disk filling up, or the entire system crashing. In anyIcase, for whatever reason, the application can no longer continue to makeforward progress.Y

Transaction
A transaction is a group of changes, to one or more databases, thatCshould be treated as a single unit of work. That is, either all of>the changes must be applied to the database(s) or none of them should. TheIapplication specifies when each transaction starts, what database changes%are included in it, and when it ends.\

Transaction commit
Every transaction ends by committing or aborting.OIf a transaction commits, then Berkeley DB guarantees that the database changesGinside it will never be lost, even after system or application failure.HIf a transaction aborts, or is unfinished when the system or applicationCfails, then the changes involved will never appear in the database.Z

Deadlock
Deadlock, in its simplest form, happens when one thread of control ownsFresource A, but needs resource B, while another thread of control ownsEresource B, but needs resource A. Neither thread of control can makeEprogress, and so one has to give up and release all of its resources,9at which point the other can again make forward progress.Z

Recovery
Whenever system or application failure occurs, the application must runHrecovery. Recovery is what makes the database consistent, i.e., reviewsDthe log files and the databases to ensure that the changes from eachBcommitted transaction appear in the database, and that none of the9changes from any unfinished (or aborted) transactions do.

KTo run recovery, all applications in the environment must exit Berkeley DB.D(Normally, and always, of course, in the case of system failure, the)applications will stop running entirely.)

GOnce none of the applications are still using the database environment,?recovery is performed by calling the Berkeley DB interface with¬special flags (either DB_RECOVER or DB_RECOVER_FATAL).

FWhen recovery is complete, the database environment is again availablefor normal use.j

Write-ahead-logging
This is a term that describes the underlying implementation that Berkeley DBDuses to ensure recovery. What it means is that before any change isKmade to a database, information about the change is written to the databaseKlog. During recovery, the log is read, and databases are checked to ensureJthat changes described in the log for committed transactions appear in theGdatabase. Changes that appear in the database but which are related toKaborted or unfinished transactions in the log are undone from the database.


EThere are a number of reasons for using transactional support in yourprograms. The most common are:

\

Recoverability
Applications often need to ensure that, no matter how the system orGapplication fails, previously saved data is available the next time theapplication runs.c

Deadlock avoidance
When multiple threads of control are changing the database at the sameDtime, there is usually the possibility of deadlock. The way this isDresolved is that one of the transactions involved has to release theFresources it owns so that the other one can proceed. (The transactionHthat releases its resources is usually just tried again later.) However,Jusing transactions is necessary so that any changes that have already beenGmade to the database can be undone, so that the database doesn't end up corrupted.]

Atomicity
Applications often need to make multiple changes, but want to ensure thatJeither all of the changes happen, or none of them. Transactions guaranteeDthat a group of changes are atomic, i.e., that if the application orHsystem fails, either all of the changes will appear when the applicationnext runs, or none of them.]

Repeatable reads
Applications sometimes need to ensure that, while doing a group ofBoperations on a database, that the value returned as a result of aEdatabase retrieval doesn't change, i.e., if you retrieve the same keyGmore than once, the data item will be the same each time. Transactionsguarantee this behavior.


HALÿÿ