On Wed, Apr 28, 2010 at 05:20:26PM +0200, Guillaume Duranceau scratched on the wall: > 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.
> 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 ? Once (some) pages are written to disk, you have uncommitted changes in the database file. Allowing readers could "leak" those uncommitted changes to other database connections, which is not allowed under the ACID transaction model. Further, because only some pages get written out, the database file might very well be inconsistent and unusable. You need the full picture of file pages plus cached pages to have a consistent database image. At that point in time, the file alone cannot provide that. Everything is still safe, thanks to the journal file, but no readers can touch the file until the transaction is either fully committed or fully rolled back. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
