0I:Berkeley DB Reference Guide: Access Methods[P4

Berkeley DB Reference Guide: Access Methods



B

Record backing file (re_source, DB_SNAPSHOT)



KIt is possible to back any Recno database (either fixed or variable length)Jwith a flat-text source file. The reason for this is to provide fast readI(and potentially write) access to databases that are normally created andFstored as flat-text files. The backing source file may be declared asepart of the db_open call to open the database, specifically bylsetting the re_source element of the DB_INFO structure.

HThe backing source file will be read to initialize the database. In theHcase of variable length records, the records are assumed to be separatedjby the re_delim element of the DB_INFO structure. ForIexample, standard UNIX byte stream files can be interpreted as a sequenceAof variable length records separated by ASCII newline characters.

CIn addition, when cached data would normally be written back to the„underlying database file (e.g., DB->close or DB->syncIfunctions are called), the in-memory copy of the database will be written back to the backing source file.

IBy default, the backing source file is read lazily, i.e., records are notAread from the backing source file until they are requested by theFapplication. If multiple processes (not threads) are accessing a recnoCdatabase concurrently and either inserting or deleting records, theJbacking source file must be read in its entirety before more than a singleGprocess accesses the database, and only that process should specify thedbacking source file as part of the db_open call. This can bejaccomplished by setting the DB_SNAPSHOT flag in theDB_INFO structure.

<Reading and writing the backing source file cannot beHtransactionally protected because it involves filesystem operations thatNare not part of the Berkeley DB transaction methodology. For this reason, if aJtemporary database is used to hold the records, i.e., a NULL was specifiedaas the file argument to db_open, it is possible to loseKthe contents of the backing source file, e.g., if the system crashes atJthe right instant. If a permanent file is used to hold the database, i.e.,ha file name was specified as the file argument to db_open, normalGdatabase recovery on that file can be used to prevent information loss,Jalthough it is still possible that the contents of the backing source file*itself will be lost if the system crashes.

HThe backing source file must already exist (but may be zero-length) when:db_open is called. 

JFor all of the above reasons, the backing source file is generally used toKspecify databases that are read-only for Berkeley DB applications, and thatFare either generated on the fly by software tools, or modified using a*different mechanism, e.g., a text editor. 

HAJÿÿ