Guillame, If you have a highly concurrent application then Oracle's latest release of BDB might be what you're looking for. It has a SQLite integration (version 3.6.23, to be precise) and combines the best of SQLite (API, SQL support etc.) with the best of BDB (concurrency, scaling and performance). It's not a SQLite code branch; it's a SQLite integration. So if concurrency is an issue for you then I'd suggest you take a look:
http://www.oracle.com/technology/products/berkeley-db/index.html This integration was performed by Dr. Hipp and is offered under a dual-license - an open-source non-commercial license, or a commercial and fully supported license. (In full disclosure, I am a Senior SC supporting Berkeley at Oracle, and I get a commission on BDB sales.) Toby Ferguson -----Original Message----- From: Guillaume Duranceau [mailto:[email protected]] Sent: Wednesday, April 28, 2010 8:20 AM To: [email protected] Subject: [sqlite] releasing EXCLUSIVE lock after writing dirty pages from the memory cache into the DB ? 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 _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
