Berkeley DB: DbEnv::open
Description: Berkeley DB: An embedded database programmatic toolkit.
Keywords: embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++

# DbEnv::open |

`

###

    #include <db_cxx.h>

    int
    DbEnv::open(const char *db_home, u_int32_t flags, int mode);

# Description

The DbEnv::open method is the interface for opening the Berkeley DB environment. It provides a structure for creating a consistent environment for processes using one or more of the features of Berkeley DB.

The db_home argument to DbEnv::open (and file name resolution in general) is described in Berkeley DB File Naming.

The flags argument specifies the subsystems that are initialized and how the application's environment affects Berkeley DB file naming, among other things.

The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more of the following values.

As there are a large number of flags that can be specified, they have been grouped together by functionality. The first group of flags indicate which of the Berkeley DB subsystems should be initialized:

DB_INIT_CDB
  Initialize locking for the Berkeley DB Concurrent Data Store product. In this mode, Berkeley DB provides multiple reader/single writer access. The only other subsystem that should be specified with the DB_INIT_CDB flag is DB_INIT_MPOOL.

  Access method calls are largely unchanged when using this flag, although any cursors through which update operations (e.g., Dbc::put, Dbc::del) will be made must have the DB_WRITECURSOR value set in the flags parameter to the cursor call that creates the cursor. See Db::cursor for more information.

DB_INIT_LOCK
  Initialize the locking subsystem. This subsystem should be used when multiple processes or threads are going to be reading and writing a Berkeley DB database, so that they do not interfere with each other. If all threads are accessing the database(s) read-only, then locking is unnecessary. When the DB_INIT_LOCK flag is specified, it is usually necessary to run the deadlock detector, as well. See db_deadlock and DbEnv::lock_detect for more information.

DB_INIT_LOG
  Initialize the logging subsystem. This subsystem is used when recovery from application or system failure is necessary.

  The log is stored in one or more files in the environment directory. Each file is named using the format log.NNNNNNNNNN, where NNNNNNNNNN is the sequence number of the file within the log. For further information, see Log File Limits.

  If the log region is being created and log files are already present, the log files are reviewed and subsequent log writes are appended to the end of the log, rather than overwriting current log entries.

DB_INIT_MPOOL
  Initialize the shared memory buffer pool subsystem. This subsystem is used whenever the application is using any Berkeley DB access method.

DB_INIT_TXN
  Initialize the transaction subsystem. This subsystem is used when recovery and atomicity of multiple operations and recovery are important. The DB_INIT_TXN flag implies the DB_INIT_LOG flag.

The second group of flags govern what recovery, if any, is performed when the environment is initialized:

DB_RECOVER
  Run normal recovery on this environment before opening it for normal use. If this flag is set, the DB_CREATE flag must also be set since the regions will be removed and recreated.

DB_RECOVER_FATAL
  Run catastrophic recovery on this environment before opening it for normal use. If this flag is set, the DB_CREATE flag must also be set since the regions will be removed and recreated.

A standard part of the recovery process is to remove the existing Berkeley DB environment and create a new one in which to perform recovery. If the thread of control performing recovery does not specify the correct region initialization information (e.g., the correct memory pool cache size), the result can be an application running in an environment with incorrect cache and other subsystem sizes. For this reason, the thread of control performing recovery should either specify correct configuration information before calling the DbEnv::open method, or it should remove the environment after recovery is completed, leaving creation of the correctly sized environment to a subsequent call to DbEnv::open.

All Berkeley DB recovery processing must be single-threaded, that is, only a single thread of control may perform recovery or access a Berkeley DB environment while recovery is being performed. As it is not an error to specify DB_RECOVER for an environment for which no recovery is required, it is reasonable programming practice for the thread of control responsible for performing recovery and creating the environment to always specify the DB_RECOVER flag during startup.

The DbEnv::open function returns successfully if DB_RECOVER or DB_RECOVER_FATAL is specified and no log files exist, so it is necessary to ensure all necessary log files are present before running recovery. For further information, consult db_archive and db_recover.

The third group of flags govern file naming extensions in the environment:

DB_USE_ENVIRON
  The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming. As permitting users to specify which files are used can create security problems, environment information will be used in file naming for all users only if the DB_USE_ENVIRON flag is set.

DB_USE_ENVIRON_ROOT
  The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming. As permitting users to specify which files are used can create security problems, if the DB_USE_ENVIRON_ROOT flag is set, environment information will be used for file naming only for users with appropriate permissions (e.g., on IEEE/ANSI Std 1003.1 (POSIX) systems, users with a user-ID of 0).

Finally, there are a few additional, unrelated flags:

DB_CREATE
  Cause Berkeley DB subsystems to create any underlying files, as necessary.

DB_LOCKDOWN
  Lock shared Berkeley DB environment files and memory mapped databases into memory.

DB_NOMMAP
  Always copy read-only database files in this environment into the local cache instead of potentially mapping them into process memory (see the description of the DbEnv::set_mp_mmapsize method for further information).

DB_PRIVATE
  Specify that the environment will only be accessed by a single process (although that process may be multi-threaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads.

  This flag should not be specified if more than a single process is accessing the environment, as it is likely to cause database corruption and unpredictable behavior, e.g., if both a server application and the Berkeley DB utility db_stat will access the environment, the DB_PRIVATE flag should not be specified.

DB_SYSTEM_MEM
  Allocate memory from system shared memory instead of from memory backed by the filesystem. See Shared Memory Regions for more information.

DB_THREAD
  Cause the DbEnv handle returned by DbEnv::open to be free-threaded, that is, useable by multiple threads within a single address space.

DB_TXN_NOSYNC
  Do not synchronously flush the log on transaction commit or prepare. This means that transactions exhibit the ACI (atomicity, consistency and isolation) properties, but not D (durability), i.e., database integrity will be maintained but it is possible that some number of the most recently committed transactions may be undone during recovery instead of being redone.

  The number of transactions that are potentially at risk is governed by how often the log is checkpointed (see db_checkpoint for more information) and how many log updates can fit on a single log page.

On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB are created with mode mode (as described in chmod(2)) and modified by the process' umask value at the time of creation (see umask(2)). The group ownership of created files is based on the system and directory defaults, and is not further specified by Berkeley DB. If mode is 0, files are created readable and writeable by both owner and group. On Windows systems, the mode argument is ignored.

The DbEnv::open method either returns a non-zero error value or throws an exception that encapsulates a non-zero error value on failure, and returns 0 on success.

# Environment Variables

DB_HOME
  The environment variable DB_HOME may be used as the path of the database home as described in Berkeley DB File Naming.

# Errors

The DbEnv::open method may fail and throw an exception or return a non-zero error for the following conditions:

EAGAIN
  The shared memory region was locked and (repeatedly) unavailable.

EINVAL
  An invalid flag value or parameter was specified.

  The DB_THREAD flag was specified and spinlocks are not implemented for this architecture.

  The DB_HOME or TMPDIR environment variables were set but empty.

  An incorrectly formatted NAME VALUE entry or line was found.

ENOSPC
  HP-UX only: a previously created Berkeley DB environment for this process still exists.

The DbEnv::open method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. If a catastrophic error has occurred, the DbEnv::open method may fail and either return DB_RUNRECOVERY or throw an exception encapsulating DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.

### Class

DbEnv

# See Also

DbEnv::close, DbEnv::open, DbEnv::remove, DbEnv::err, DbEnv::strerror, DbEnv::version, DbEnv::set_cachesize, DbEnv::set_errcall, DbEnv::set_errfile, DbEnv::set_error_stream, DbEnv::set_errpfx, DbEnv::set_paniccall, and DbEnv::set_verbose.`

Copyright Sleepycat Software