1<!--$Id: bigpic.so,v 8.32 2003/11/27 18:25:57 bostic Exp $-->
2<!--Copyright (c) 1997,2008 Oracle.  All rights reserved.-->
3<!--See the file LICENSE for redistribution information.-->
4<html>
5<head>
6<title>Berkeley DB Reference Guide: The big picture</title>
7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
9</head>
10<body bgcolor=white>
11<table width="100%"><tr valign=top>
12<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Architecture</dl></b></td>
13<td align=right><a href="/java/faq.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/arch/progmodel.html"><img src="/images/next.gif" alt="Next"></a>
14</td></tr></table>
15<p align=center><b>The big picture</b></p>
16<p>The previous chapters in this Reference Guide have described
17applications that use the Berkeley DB access methods for fast data storage
18and retrieval.  The applications described in the following chapters
19are similar in nature to the access method applications, but they are
20also threaded and/or recoverable in the face of application or system
21failure.</p>
22<p>Application code that uses only the Berkeley DB access methods might appear
23as follows:</p>
24<blockquote><pre>switch (ret = dbp-&gt;put(dbp, NULL, &key, &data, 0)) {
25case 0:
26	printf("db: %s: key stored.\n", (char *)key.data);
27	break;
28default:
29	dbp-&gt;err(dbp, ret, "dbp-&gt;put");
30	exit (1);
31}</pre></blockquote>
32<p>The underlying Berkeley DB architecture that supports this is</p>
33<p align=center><img src="smallpic.gif" alt="small">
34<p>As you can see from this diagram, the application makes calls into the
35access methods, and the access methods use the underlying shared memory
36buffer cache to hold recently used file pages in main memory.</p>
37<p>When applications require recoverability, their calls to the Access
38Methods must be wrapped in calls to the transaction subsystem.  The
39application must inform Berkeley DB where to begin and end transactions, and
40must be prepared for the possibility that an operation may fail at any
41particular time, causing the transaction to abort.</p>
42<p>An example of transaction-protected code might appear as follows:</p>
43<blockquote><pre>for (fail = 0;;) {
44	/* Begin the transaction. */
45	if ((ret = dbenv-&gt;txn_begin(dbenv, NULL, &tid, 0)) != 0) {
46		dbenv-&gt;err(dbenv, ret, "dbenv-&gt;txn_begin");
47		exit (1);
48	}
49<p>
50	/* Store the key. */
51	switch (ret = dbp-&gt;put(dbp, tid, &key, &data, 0)) {
52	case 0:
53		/* Success: commit the change. */
54		printf("db: %s: key stored.\n", (char *)key.data);
55		if ((ret = tid-&gt;commit(tid, 0)) != 0) {
56			dbenv-&gt;err(dbenv, ret, "DB_TXN-&gt;commit");
57			exit (1);
58		}
59		return (0);
60	case DB_LOCK_DEADLOCK:
61	default:
62		/* Failure: retry the operation. */
63		if ((t_ret = tid-&gt;abort(tid)) != 0) {
64			dbenv-&gt;err(dbenv, t_ret, "DB_TXN-&gt;abort");
65			exit (1);
66		}
67		if (fail++ == MAXIMUM_RETRY)
68			return (ret);
69		continue;
70	}
71}</pre></blockquote>
72<p>In this example, the same operation is being done as before; however,
73it is wrapped in transaction calls.  The transaction is started with
74<a href="/api_c/txn_begin.html">DB_ENV-&gt;txn_begin</a> and finished with <a href="/api_c/txn_commit.html">DB_TXN-&gt;commit</a>.  If the
75operation fails due to a deadlock, the transaction is aborted using
76<a href="/api_c/txn_abort.html">DB_TXN-&gt;abort</a>, after which the operation may be retried.</p>
77<p>There are actually five major subsystems in Berkeley DB, as follows:</p>
78<br>
79<b>Access Methods</b><ul compact><li>The access methods subsystem provides general-purpose support for
80creating and accessing database files formatted as Btrees, Hashed files,
81and Fixed- and Variable-length records.  These modules are useful in
82the absence of transactions for applications that need fast formatted
83file support.  See <a href="/api_c/db_open.html">DB-&gt;open</a> and <a href="/api_c/db_cursor.html">DB-&gt;cursor</a> for more
84information.  These functions were already discussed in detail in the
85previous chapters.</ul>
86<b>Memory Pool</b><ul compact><li>The Memory Pool subsystem is the general-purpose shared memory buffer pool
87used by Berkeley DB.  This is the shared memory cache that allows multiple
88processes and threads within processes to share access to databases.  This
89module is useful outside of the Berkeley DB package for processes that require
90portable, page-oriented, cached, shared file access.</ul>
91<b>Transaction</b><ul compact><li>The Transaction subsystem allows a group of database changes to be
92treated as an atomic unit so that either all of the changes are done,
93or none of the changes are done.  The transaction subsystem implements
94the Berkeley DB transaction model.  This module is useful outside of the Berkeley DB
95package for processes that want to transaction-protect their own data
96modifications.</ul>
97<b>Locking</b><ul compact><li>The Locking subsystem is the general-purpose lock manager used by Berkeley DB.
98This module is useful outside of the Berkeley DB package for processes that
99require a portable, fast, configurable lock manager.</ul>
100<b>Logging</b><ul compact><li>The Logging subsystem is the write-ahead logging used to support the
101Berkeley DB transaction model.  It is largely specific to the Berkeley DB package,
102and unlikely to be useful elsewhere except as a supporting module for
103the Berkeley DB transaction subsystem.</ul>
104<br>
105<p>Here is a more complete picture of the Berkeley DB library:</p>
106<p align=center><img src="bigpic.gif" alt="large">
107<p>In this model, the application makes calls to the access methods and to
108the Transaction subsystem.  The access methods and Transaction subsystems
109in turn make calls into the Memory Pool, Locking and Logging subsystems
110on behalf of the application.</p>
111<p>The underlying subsystems can be used independently by applications.
112For example, the Memory Pool subsystem can be used apart from the rest
113of Berkeley DB by applications simply wanting a shared memory buffer pool, or
114the Locking subsystem may be called directly by applications that are
115doing their own locking outside of Berkeley DB.  However, this usage is not
116common, and most applications will either use only the access methods
117subsystem, or the access methods subsystem wrapped in calls to the Berkeley DB
118transaction interfaces.</p>
119<table width="100%"><tr><td><br></td><td align=right><a href="/java/faq.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/arch/progmodel.html"><img src="/images/next.gif" alt="Next"></a>
120</td></tr></table>
121<p><font size=1>Copyright (c) 1996,2008 Oracle.  All rights reserved.</font>
122</body>
123</html>
124