Berkeley DB Reference Guide: Access Methods
Record backing file (re_source, DB_SNAPSHOT)
It is possible to back any Recno database (either fixed or variable length) with a flat-text source file. The reason for this is to provide fast read (and potentially write) access to databases that are normally created and stored as flat-text files. The backing source file may be declared as part of the db_open call to open the database, specifically by setting the re_source element of the DB_INFO structure.
The backing source file will be read to initialize the database. In the case of variable length records, the records are assumed to be separated by the re_delim element of the DB_INFO structure. For example, standard UNIX byte stream files can be interpreted as a sequence of variable length records separated by ASCII newline characters.
In addition, when cached data would normally be written back to the underlying database file (e.g., DB->close or DB->sync functions are called), the in-memory copy of the database will be written back to the backing source file.
By default, the backing source file is read lazily, i.e., records are not read from the backing source file until they are requested by the application. If multiple processes (not threads) are accessing a recno database concurrently and either inserting or deleting records, the backing source file must be read in its entirety before more than a single process accesses the database, and only that process should specify the backing source file as part of the db_open call. This can be accomplished by setting the DB_SNAPSHOT flag in the DB_INFO structure.
Reading and writing the backing source file cannot be transactionally protected because it involves filesystem operations that are not part of the Berkeley DB transaction methodology. For this reason, if a temporary database is used to hold the records, i.e., a NULL was specified as the file argument to db_open, it is possible to lose the contents of the backing source file, e.g., if the system crashes at the right instant. If a permanent file is used to hold the database, i.e., a file name was specified as the file argument to db_open, normal database recovery on that file can be used to prevent information loss, although it is still possible that the contents of the backing source file itself will be lost if the system crashes.
The backing source file must already exist (but may be zero-length) when db_open is called.
For all of the above reasons, the backing source file is generally used to specify databases that are read-only for Berkeley DB applications, and that are either generated on the fly by software tools, or modified using a different mechanism, e.g., a text editor.
