On Mon, Apr 30, 2012 at 8:35 PM, Sean Cui <s...@gemcomsoftware.com> wrote: > > Thanks very much for the replies. > > It'd be nice to have the online documentation of WAL mode updated to include > the clarification of readers' visibility on uncommitted data. > > I think lot of developers will have the same question after reading the > current doc of "...readers do not block writers and a writer does not block > readers. Reading and writing can proceed concurrently." >
I had thought the docs on WAL to be pretty clear a while ago and this thread puzzled me. So I went back and read the first paragraph in the "Concurrency" section of that page. ------------- http://www.sqlite.org/wal.html ------------- Concurrency When a read operation begins on a WAL-mode database, it first remembers the location of the last valid commit record in the WAL. Call this point the "end mark". Because the WAL can be growing and adding new commit records while various readers connect to the database, each reader can potentially have its own end mark. But for any particular reader, the end mark is unchanged for the duration of the transaction, --> thus ensuring that a single read transaction only sees the database content as it existed at a single point in time. ------------- Richard Hipp: You asked how to improve the documentation... I would modify the Pros#2 to contain some of the explanation in the last sentence I highlighted in the paragraph above. Since Pros#2 seems to stress WAL is a solution to "blocking", I would just add what the beauty of not blocking is like. Oh and I would move it to #1 since I guess "faster in most scenarios" depends if there is blocking involved or not (among other "scenarios"). Simon _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
