~ubuntu-branches/ubuntu/maverick/evolution-data-server/maverick-proposed

transactional interfaces, <a href="../../api_c/txn_begin.html">DB_ENV->txn_begin</a> and <a href="../../api_c/txn_commit.html">DB_TXN->commit</a>, and

the transaction's locker ID will be used to acquire relevant read and

write locks.

<p>Before data is accessed, the application must make a call to the lock

manager, <a href="../../api_c/lock_get.html">DB_ENV->lock_get</a>, for a lock of the appropriate type (for

example, read) on the object being locked. The object might be a page

in the file, a byte, a range of bytes, or some key. It is up to the

application to ensure that appropriate locks are acquired. Before a

write is performed, the application should acquire a write lock on the

object by making an appropriate call to the lock manager,

<a href="../../api_c/lock_get.html">DB_ENV->lock_get</a>. Then, the application should make a call to the log

manager, <a href="../../api_c/log_put.html">DB_ENV->log_put</a>, to record enough information to redo the

operation in case of failure after commit and to undo the operation in

case of abort.

<p>When designing applications that will use the log subsystem, it is

important to remember that the application is responsible for providing

any necessary structure to the log record. For example, the application

must understand what part of the log record is an operation code, what

part identifies the file being modified, what part is redo information,

and what part is undo information.

<p>After the log message is written, the application may issue the write

system call. After all requests are issued, the application may call

<a href="../../api_c/txn_commit.html">DB_TXN->commit</a>. When <a href="../../api_c/txn_commit.html">DB_TXN->commit</a> returns, the caller is

guaranteed that all necessary log writes have been written to disk.

<p>At any time before issuing a <a href="../../api_c/txn_commit.html">DB_TXN->commit</a>,

the application may call <a href="../../api_c/txn_abort.html">DB_TXN->abort</a>, which will

result in restoration of the database to a consistent pretransaction

state. (The application may specify its own recovery function for this

purpose using the <a href="../../api_c/env_set_app_dispatch.html">DB_ENV->set_app_dispatch</a> method. The recovery

function must be able to either reapply or undo the update depending on

the context, for each different type of log record.)

<p>If the application crashes, the recovery process uses the log to restore

the database to a consistent state.

<p>Berkeley DB includes tools to assist in the development of application-specific

logging and recovery. Specifically, given a description of information

to be logged in a family of log records, these tools will automatically

create log-writing functions (functions that marshall their arguments

into a single log record), log-reading functions (functions that read

a log record and unmarshall it into a structure containing fields that

map into the arguments written to the log), log-printing functions

(functions that print the contents of a log record for debugging), and

templates for recovery functions (functions that review log records

during transaction abort or recovery). The tools and generated code

are C-language and POSIX-system based, but the generated code should be

usable on any system, not just POSIX systems.

<p>A sample application that does application-specific recovery is included

in the Berkeley DB distribution, in the directory <b>examples_c/ex_apprec</b>.

</td></tr></table>

<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>

</body>

</html>

Older »