+IABerkeley DB Reference Guide: Transaction Subsystem[P;

Berkeley DB Reference Guide: Transaction Subsystem



C

Transactions and non-Berkeley DB applications



EIt is possible to use the locking, logging and transaction subsystemsKof Berkeley DB to provide transaction semantics to objects other than thoseMdescribed by the Berkeley DB access methods. In these cases, the applicationFwill need more explicit customization of the subsystems as well as theFdevelopment of appropriate data-structure-specific recovery functions.

HFor example, consider an application that provides transaction semanticsFto data stored in plain UNIX files accessed using the read(2) write(2)Isystem calls. The operations for which transaction protection is desiredare bracketed by calls to txn_begin and txn_commit.

HBefore data are referenced, the application must make a call to the lockkmanager, lock_open, for a lock of the appropriate type (e.g.,Jread) on the object being locked. The object might be a page in the file,Fa byte, a range of bytes, or some key. It is up to the application toIensure that appropriate locks are acquired. Before a write is performed,Gthe application should acquire a write lock on the object, by making aniappropriate call to the lock manager, lock_open. Then, theiapplication should make a call to the log manager, log_open, toHrecord enough information to redo the operation in case of failure afterGcommit and to undo the operation in case of abort. As discussed in thellog_open manual page, the application is responsible for providingHany necessary structure to the log record. For example, the applicationFmust understand what part of the log record is an operation code, whatGpart identifies the file being modified, what part is redo information,"and what part is undo information.

EAfter the log message is written, the application may issue the writeEsystem call. After all requests are issued, the application may calltxn_commit. When txn_commit returns, the caller isCguaranteed that all necessary log writes have been written to disk.

mAt any time, the application may call txn_abort, which will resultFin the appropriate calls to the recover function to restore theDdatabase to a consistent pre-transaction state. (The recoverHfunction must be able to either re-apply or undo the update depending on4the context, for each different type of log record.)

>If the application should crash, the recovery process uses thehlog_open interface to read the log and call the recover7function to restore the database to a consistent state.

hThe txn_prepare function provides the core functionality to>implement distributed transactions, but it does not manage the@notification of distributed transaction managers. The caller iscresponsible for issuing txn_prepare calls to all sitesEparticipating in the transaction. If all responses are positive, thegcaller can issue a txn_commit. If any of the responses arejnegative, the caller should issue a txn_abort. In general, themtxn_prepare call requires that the transaction log be flushed todisk.



A