On Thu, Apr 26, 2012 at 4:38 PM, Jos Groot Lipman <donts...@home.nl> wrote:
> From the docs: 'The default isolation level for SQLite is SERIALIZABLE' > > As far as I understand this means: you will not see changes made by other > connections (committed or uncommited) after your transaction started. > My understanding was that Brad is using a single database connection shared between both threads. You are correct that if he had been using separate database connections in each thread, this problem would not come up. > If another connections commits a change, you will not see it. > I would expect: If another connections rollbacks the change, you will not > see it either. > > Why whould anyone want an aborted read-transaction in this case? > > If the PRAGMA read_uncommitted was set you would see the changes from the > other connection even before they where committed. In case of a rollback I > can understand the aborted read-transaction. > > Or am I misunderstanding the ACID isolation levels? > > Jos > > > -----Original Message----- > > From: sqlite-users-boun...@sqlite.org > > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp > > Sent: donderdag 26 april 2012 21:45 > > To: General Discussion of SQLite Database > > Cc: ian > > Subject: Re: [sqlite] SQLite 3.7.11 behavioral change from > > 3.7.10 with concurrency -- bug?? > > > > On Thu, Apr 26, 2012 at 3:34 PM, Brad House <b...@monetra.com> wrote: > > > > > > > > I've got 2 threads with different connections to the same database. > > > > > > This is approximately what I am seeing: > > > Thread 1: SELECT bar,baz FROM foo WHERE ...; > > > Thread 2: BEGIN IMMEDIATE TRANSACTION; > > > INSERT INTO foo VALUES (...); > > > **sqlite3_step returns 6 (SQLITE_LOCKED) > > > ROLLBACK TRANSACTION > > > Thread 1: **sqlite3_step returns 4 (SQLITE_ABORT): abort > > due to ROLLBACK > > > > > > > > > So why, if Thread 2 rolls back does Thread 1 get aborted? > > > > > > > A rollback deletes content out from under other queries. So > > if you have a query pending in thread 1 and thread 2 tries to > > rollback, there are two > > options: (A) The rollback fails (B) The pending query is > > aborted. It used to be that we did (A). (If you had checked > > the return codes from your "ROLLBACK TRANSACTION" statement > > you would have been seeing it fail.) The latest code does > > (B) instead. > > > > Your software depends upon behavior (A). Other users prefer > > behavior (B). > > I don't know how to make everyone happy.... > > > > > > > > -- > > 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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
