Each of the Berkeley DB subsystems within an environment is described by one or more regions, or chunks of memory. The regions contain all of the per-process and per-thread shared information (including mutexes), that comprise a Berkeley DB environment. These regions are created in one of three types of memory, depending on the flags specified to the DB_ENV->open() method:
If the DB_PRIVATE flag is specified to the
DB_ENV->open() method, regions are created in per-process
heap memory; that is, memory returned by
malloc(3).
If this flag is specified, then you cannot open more than a single handle for the environment. For example, if both a server application and Berkeley DB utilities (for example, the db_archive utility, the db_checkpoint utility or the db_stat utility) are expected to access the environment, the DB_PRIVATE flag should not be specified because the second attempt to open the environment will fail.
If the DB_SYSTEM_MEM flag is specified to DB_ENV->open(), shared regions are created in system memory rather than files. This is an alternative mechanism for sharing the Berkeley DB environment among multiple processes and multiple threads within processes.
The system memory used by Berkeley DB is potentially useful past the lifetime of any particular process. Therefore, additional cleanup may be necessary after an application fails because there may be no way for Berkeley DB to ensure that system resources backing the shared memory regions are returned to the system. DB_ENV->remove() can be called to free up system resources when the shared memory regions are not used any more.
The system memory that is used is
architecture-dependent. For example, on systems
supporting X/Open-style shared memory interfaces, such
as UNIX systems, the shmget(2) and
related System V IPC interfaces are used.
Additionally, VxWorks systems use system memory. In
these cases, an initial segment ID must be specified
by the application to ensure that applications do not
overwrite each other's database environments, so that
the number of segments created does not grow without
bounds. See the DB_ENV->set_shm_key() method for more
information.
On Windows platforms, the use of the DB_SYSTEM_MEM flag is problematic because the operating system uses reference counting to clean up shared objects in the paging file automatically. In addition, the default access permissions for shared objects are different from files, which may cause problems when an environment is accessed by multiple processes running as different users. See the Windows Notes section in the Berkeley DB Installation and Build Guide for more information.
Any files created in the filesystem to back the regions are created in the directory set by calling DB_ENV->set_region_dir(). If no region directory is set then the files are created in the environment home directory specified to the DB_ENV->open() call. These files are named __db.### (for example, __db.001, __db.002 and so on). When region files are backed by the filesystem, one file per region is created. When region files are backed by system memory, a single file will still be created because there must be a well-known name in the filesystem so that multiple processes can locate the system shared memory that is being used by the environment.
Statistics about the shared memory regions in the environment can be displayed using the -e option to the db_stat utility.