Hello all, While running a SQLite transaction writing into the DB (thus holding the RESERVED lock), in case the memory cache becomes full, SQLite will try to write the content of a dirty page into the DB. To do so, it promotes the RESERVED lock to EXCLUSIVE. This can be annoying because afterwards, the EXCLUSIVE lock will be released only when the transaction will finally be committed. In the meantime, database access to readers will be prohibited.
This behaviour is described at http://www.sqlite.org/lockingv3.html, chapter 5.0 "Writing to a database file": <quote> If the reason for writing to the database file is because the memory cache was full, then the writer will not commit right away. Instead, the writer might continue to make changes to other pages. Before subsequent changes are written to the database file, the rollback journal must be flushed to disk again. Note also that the EXCLUSIVE lock that the writer obtained in order to write to the database initially must be held until all changes are committed. That means that no other processes are able to access the database from the time the memory cache first spills to disk until the transaction commits. </quote> I'm wondering why the EXCLUSIVE lock is not downgraded to a RESERVED lock right after writing the dirty page into the DB. This doesn't seem to me as an undoable task (the transition EXCLUSIVE->RESERVED would simply need to be managed by xUnlock functions), but there might be technical/conceptual reasons preventing to do so. What are your views on this ? Regards - Guillaume _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
