The db_appinit function is the standard function for creating
or joining a database environment.
Every transaction-protected or multi-process application should call
db_appinit before making any other calls to the Berkeley DB library.
There are several flags that you can set to customize db_appinit:
Files that are opened read-only in the pool (and that satisfy a few other
criteria) are, by default, mapped into the process address space instead
of being copied into the local cache. This can enhance performance or
degrade it, depending on the architecture where it is done. Setting the
DB_NOMMAP flag causes Berkeley DB to never map such files into memory,
instead, they are read into the cache using the standard read system calls.
On transaction commit, do not synchronously flush the log. This means
that Berkeley DB will provide atomicity, consistency, and isolation for your
transactions, but not durability. Upon recovery, some previously committed
transactions may be lost, but your database will be restored to a consistent
Use environment variables as part of file naming for users with
Almost all applications either specify only the DB_INIT_MPOOL
flag or they specify all four flags, DB_INIT_MPOOL,
DB_INIT_LOCK, DB_INIT_LOG and DB_INIT_TXN.
The former configuration is for applications that simply want to use the
basic Access Method interfaces with a shared underlying buffer pool, but
don't care about recoverability after failure. The latter is for
applications that need recoverability. There are situations where other
combinations of the initialization flags make sense, but they are quite
The flag DB_RECOVER is specified by applications that want to
perform any necessary database recovery when they start running, i.e., if
there was a system or application failure the last time they ran, they
want the databases to be made consistent before they start running again.
(It is not an error to specify this flag when no recovery needs to be
done.) The flag DB_RECOVER_FATAL is more special-purpose. It
performs catastrophic database recovery, and normally requires that some
initial arrangements be made, i.e., archived log files be brought back
into the filesystem. Applications should not normally specify this flag.
Instead, under these rare conditions, the db_recover utility
should be used.