42 journal syncs, not 480

OneLite is a SQLite-compatible database written in pure .NET. Its rollback journal code has a detail that decides how many times it hits the disk when the cache overflows.

A rollback journal stores the original copy of every page before the database file is changed. SQLite's atomic commit rules say a page may only be overwritten once its own journal record is durable. The naive way to follow that is to sync the journal before each spilled page. For a 240-page transaction on a 12-page cache that is about 480 syncs.

OneLite does it differently. When the cache has to give up a dirty page, it picks one whose original is already in a durable part of the journal. Only when every dirty page still has its record in the unsynced tail does it sync the journal first. One sync then covers many later spills. Its durability notes give the result: the same 240-page transaction on a 12-page cache syncs the journal 42 times.

The notes also show where the cost comes from. A cache spill needs an exclusive lock on the database file, so if another connection holds a shared lock, the spill fails with SQLITE_BUSY, exactly like the reference shell the project compares against. The statement fails and the transaction stays open.

The same document explains one place where OneLite is stricter than SQLite. It also syncs the directory after deleting the journal under FULL, which the reference does only at EXTRA. The project's crash model drops an unsynced unlink, so without that sync an acknowledged commit could come back as a hot journal and be rolled back.

Source: docs/durability.md in recursive-ai-oss/onelite-csharp.