On 1/16/15, James K. Lowden <[email protected]> wrote: > On Sat, 10 Jan 2015 00:58:25 -0700 > "Keith Medcalf" <[email protected]> wrote: > >> > there's no way to hook two SELECTs together to make them see one >> >database state. That's what JOIN is for. :-) >> >> Yes, it is a part of the SQL Standard isolation levels in excess of >> the default default of READ COMMITTED. Different vendors call the >> isolation levels by different names -- MS SQL Server calls them Read >> Uncomitted, Read Committed, Repeatable Read, Snapshot, and >> Serializable; DB/2 calls them No Commit (similar to autocommit), >> Uncommitted Read, Cursor Stability, Read Stability, Repeatable Read. >> DB/2 Repeatable Read = MS Serializable (which is the SQL Standard >> Serializable isolation level). Cursor Stability = Read Committed. > > Keith, I just want to thank you for relieving me of my > misunderstanding. I think some years ago I must have decided that for > my purposes Repeatable Read & friends don't exist because of their > effect on performance and concurrency. I've always thought the > standard was paradoxical in the sense that the more you need isolation > (because of concurrent updates), the less useful it is to the extent > that restricts the system's abiltity to support concurrent updates. > > To bring it back to SQLite, we have two logging modes and two > isolation levels. IIUC, given two connections it can be boiled down > thusly: > > mode transaction isolation > Journal implicit Read Committed > WAL implicit Read Committed > journal explicit Repeatable Read > WAL explicit Repeatable Read
I think the isolation in SQLite is always Serializable. Except if you have two connections in the same process in shared cache mode and they set "PRAGMA read_uncommitted=ON" then the isolation is Read Uncommitted. But otherwise, isolation in SQLite is always Serializable. > > with the difference being concurrency: > > * in journal mode a writer is blocked by a reader, whereas > * in WAL mode a writer can commit while a reader continues to work, > in isolation, unaffected. > > --jkl > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
