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." -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp Sent: April-30-12 5:20 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Concurrency On Mon, Apr 30, 2012 at 8:10 PM, Sean Cui <s...@gemcomsoftware.com> wrote: > Here is a simple scenario to explain what the OP meant: > > Under WAL mode, > > In connection A, we issue SQL "UPDATE Employee SET Salary=0" to SQLite. > > While the command is executing, from another connection, we issue > "SELECT Salary FROM Employee". > When you say "while the command [UPDATE] command is executing", I assume you mean *before* it commits. In that case, the SELECT statement will see a snapshot of the database file as it existed before the UPDATE was started. Even if the UPDATE commits a second or two later, and the SELECT continues running for hours, the SELECT will still only continue to see the snapshot of the database as it existed prior to the start of the UPDATE, since that was the state of the database when the SELECT was started. You can have multiple concurrent SELECT statements running, and if they were all started at different times (with database changes in between) then each will see a different snapshot of the database file - a full and complete image of the database file exactly as it existed when the SELECT was first started. > > In this case, even under WAL, the SELECT command will still be blocked > by the UPDATE command, right? > > > Thanks, > > Sean > > > > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto: > sqlite-users-boun...@sqlite.org] On Behalf Of Harnek Manj > Sent: April-30-12 5:04 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Concurrency > > Hi Igor, > > Sorry about that. What I meant was "really latest committed data". > > As you answered that "It will read most recent", so as per the > scenario I mentioned in my previous post does it mean that read will > wait for the current write operation to finish? > > Regards > Harnek > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto: > sqlite-users-boun...@sqlite.org] On Behalf Of Igor Tandetnik > Sent: April-30-12 4:56 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Concurrency > > On 4/30/2012 7:46 PM, Harnek Manj wrote: > > So what I am confused is, if there is a Write (update) operation and > > it > creates a WAL file and subsequently a read operation comes in and the > read is trying to access the same data what write is working on. Does > in this scenario read will wait or it will grab the data from the > original database file > > The latter - it will read the most recently committed data. > > > which is not really data? > > I don't understand this statement. What is it, if not data? > -- > Igor Tandetnik > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
