On Sat, 10 Jan 2015 00:58:25 -0700 "Keith Medcalf" <kmedc...@dessus.com> 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 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
