- Berkeley DB Reference Guide:
- Access Methods
|
|
It is possible to back any Recno database (either fixed or variable length) with a flat-text source file. This provides fast read (and potentially write) access to databases that are normally created and stored as flat-text files. The backing source file may be specified by calling the DB->set_re_source function.
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 as described for the DB->set_re_delim function interface. For example, standard UNIX byte stream files can be interpreted as a sequence of variable length records separated by ASCII newline characters. This is the default.
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.
The backing source file must already exist (but may be zero-length) when DB->open is called. 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 calling the DB->set_flags function with the DB_SNAPSHOT flag.
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 (a NULL was specified as the file argument to DB->open), it is possible to lose the contents of the backing source file if the system crashes at the right instant. If a permanent file is used to hold the database (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. It is still possible that the contents of the backing source file itself will be corrupted or lost if the system crashes.
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 such as a text editor.
|
|