configures file buffers to be flushed during transaction commits.
configures file buffers to be flushed during transaction commits.
db4o uses a resume-commit-on-crash strategy to ensure ACID transactions. When a transaction commits,
- (1) a list "pointers that are to be modified" is written to the database file,
- (2) the database file is switched into "in-commit" mode,
- (3) the pointers are actually modified in the database file,
- (4) the database file is switched to "not-in-commit" mode.
If the system is halted by a hardware or power failure
- before (2)
all objects will be available as before the commit
- between (2) and (4) the commit is restarted when the database file is opened the next time, all pointers will be read from the "pointers to be modified" list and all of them will be modified to the state they are intended to have after commit
- after (4) no work is necessary, the transaction is committed.
In order for the above to be 100% failsafe, the order of writes to the storage medium has to be obeyed. On operating systems that use in-memory file caching, the OS cache may revert the order of writes to optimize file performance.
db4o enforces the correct write order by flushing file buffers after every single one of the above steps during transaction commit. Flush calls have a strong impact on performance. It is possible to tune an application by turning flushing off, at the risc of less security for hardware-, power- or operating system failures.
Configuration Interface | com.db4o.config Namespace