On Wed, Apr 28, 2010 at 5:22 PM, Toby Ferguson <toby.fergu...@oracle.com>wrote:
> 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.... Actually, neither I nor anybody else on the SQLite core team had anything to do with the BDB port of the SQLite front-end. That was a 100% Oracle undertaking. We didn't even know about it until it was nearly complete. > 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:guillaume.duranc...@amadeus.com] > Sent: Wednesday, April 28, 2010 8:20 AM > To: sqlite-users@sqlite.org > 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 > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- --------------------- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
