On Fri, Apr 27, 2012 at 7:04 PM, Richard Hipp <d...@sqlite.org> wrote: > On Fri, Apr 27, 2012 at 6:45 PM, Pavel Ivanov <paiva...@gmail.com> wrote: >> > If two database connections share the same cache, and one connection >> rolls >> > back, that means it will be changing cache content out from under the >> other >> > database connection, so any queries ongoing in the other connection have >> to >> > abort. >> >> Could you please explain this? I understand that this statement is >> true when read_uncommitted is set to 1. But without it in my >> understanding two connections should behave as if they don't have >> shared cache and select query in one connection shouldn't rely on any >> pages changed in another connection. Thus it seems there's no need to >> abort any queries. In what part this statement is not true? What >> changed parts select query can rely on? >> > > In theory, you probably could get it to work such that a rollback in one > connection does not force aborts in another connection as long as > read_uncommitted is not set. But that is yet another special case to write > code for, to test, and to be a magnet for database-corruption bugs. I > don't want to go there. The whole shared cache mechanism is way too > complicated already, even without introducing yet another corner case > optimization.
That's fair enough. And satisfying enough explanation for me. Thank you, Pavel _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
