The big picture

    Application code that uses only the Berkeley DB access methods might appear as follows:

    The underlying Berkeley DB architecture that supports this is

    As you can see from this diagram, the application makes calls into the access methods, and the access methods use the underlying shared memory buffer cache to hold recently used file pages in main memory.

    When applications require recoverability, their calls to the Access Methods must be wrapped in calls to the transaction subsystem. The application must inform Berkeley DB where to begin and end transactions, and must be prepared for the possibility that an operation may fail at any particular time, causing the transaction to abort.

    An example of transaction-protected code might appear as follows:

    1. /* Begin the transaction. */
    2. if ((ret = dbenv->/txn_begin(dbenv, NULL, &tid, 0)) != 0) {
    3. dbenv->/err(dbenv, ret, "dbenv->/txn_begin");
    4. exit (1);
    5. }
    6. /* Store the key. */
    7. /* Success: commit the change. */
    8. printf("db: %s: key stored.\n", (char *)key.data);
    9. if ((ret = tid->/commit(tid, 0)) != 0) {
    10. dbenv->/err(dbenv, ret, "DB_TXN->/commit");
    11. exit (1);
    12. }
    13. return (0);
    14. case DB_LOCK_DEADLOCK:
    15. /* Failure: retry the operation. */
    16. if ((t_ret = tid->/abort(tid)) != 0) {
    17. dbenv->/err(dbenv, t_ret, "DB_TXN->/abort");
    18. exit (1);
    19. }
    20. if (fail++ == MAXIMUM_RETRY)
    21. return (ret);
    22. continue;

    There are actually five major subsystems in Berkeley DB, as follows:

    Access Methods

    The access methods subsystem provides general-purpose support for creating and accessing database files formatted as Btrees, Hashed files, and Fixed- and Variable-length records. These modules are useful in the absence of transactions for applications that need fast formatted file support. See DB->open() and for more information. These functions were already discussed in detail in the previous chapters.

    Memory Pool

    The Memory Pool subsystem is the general-purpose shared memory buffer pool used by Berkeley DB. This is the shared memory cache that allows multiple processes and threads within processes to share access to databases. This module is useful outside of the Berkeley DB package for processes that require portable, page-oriented, cached, shared file access.

    Transaction

    Locking

    The Locking subsystem is the general-purpose lock manager used by Berkeley DB. This module is useful outside of the Berkeley DB package for processes that require a portable, fast, configurable lock manager.

    Logging

    The Logging subsystem is the write-ahead logging used to support the Berkeley DB transaction model. It is largely specific to the Berkeley DB package, and unlikely to be useful elsewhere except as a supporting module for the Berkeley DB transaction subsystem.

    Here is a more complete picture of the Berkeley DB library:

    9. Berkeley DB Architecture - 图1

    The underlying subsystems can be used independently by applications. For example, the Memory Pool subsystem can be used apart from the rest of Berkeley DB by applications simply wanting a shared memory buffer pool, or the Locking subsystem may be called directly by applications that are doing their own locking outside of Berkeley DB. However, this usage is not common, and most applications will either use only the access methods subsystem, or the access methods subsystem wrapped in calls to the Berkeley DB transaction interfaces.