Berkeley DB Reference Guide: RAM-only configurations
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++

### Berkeley DB Reference Guide: Programmer Notes |

### RAM-only configurations

Berkeley DB supports RAM-only configurations, however, Berkeley DB does not guarantee writes will never be attempted to disk.

You can configure RAM-only databases by not specifying a physical file name to the DB->open method. Databases created in this way will never be written to disk unless Berkeley DB runs out of cache space. Running out of cache space happens when the application attempts to create a new database page and there is no spare room in the cache, nor is there a clean page which can simply be evicted from the cache, and a dirty page must be written from the cache to disk to make room to create the new page. When Berkeley DB runs out of cache space, it will attempt to create a temporary backing file to make new room in the cache, which is not what you want.

You can create RAM-only database environments (in which you can work with both RAM-only and disk-backed databases) in two different types of memory: in heap memory or in system shared memory. To create the database environment in heap memory, specify the DB_PRIVATE flag to the DB_ENV->open method. Database environments created in heap memory are only accessible to the threads of a single process, however. To create the database environment in system shared memory, specify the DB_SYSTEM_MEM flag to the DB_ENV->open method. Database environments created in system memory are accessible to multiple processes. However, database environments created in system shared memory do create a small (roughly 8 byte) file in the file system read by the processes to identify the system shared memory segments to use.

Finally, if your database environment is intended to be transactionally protected or recoverable after application or system failure (that is, if you configure either the locking or transaction subsystems in the database environment), both the databases and database environment log files must be written to disk. There is currently no way in the Berkeley DB database environment to support transactions without writing log files to disk.

Copyright (c) 1996-2003 Sleepycat Software, Inc. - All rights reserved.