I tried the BEGIN EXCLUSIVE method, but now the problem is that thread-A is in the middle of a query doing sqlite3_step() to get results, and thread-B tries a "begin exclusive" and gets back SQLITE_BUSY in the deadlock situation :)
I guess I am forced to use your 2nd method?? On 4/8/09, D. Richard Hipp <d...@hwaci.com> wrote: > > On Apr 8, 2009, at 2:13 AM, Dave Brown wrote: > >> But why is this deadlocking at all? I thought there shouldn't be a >> problem doing this, especially since thread B is using a transaction. >> Shouldn't either A or B prevent the other one from accessing the >> database until they are done? > > > It is a problem because people have asked for more concurrency. So we > provide more concurrency. But concurrency comes at a price: namely > the danger of a deadlock. > > You can do "BEGIN EXCLUSIVE" to absolutely prevent the deadlock. This > will also prevent any possibility of concurrency. > > Or, since you are dealing with threads within a process, enable shared- > cache mode and then on the reader thread set "PRAGMA > read_uncommitted=ON". This will allow the reader to see uncommitted > changes from the writer, and hence never block for anything. You will > get great concurrency and no possibility of deadlock. The downside > there is that you lose isolation - the "I" in "ACID". > > Choose your poison. > > D. Richard Hipp > d...@hwaci.com > > > > _______________________________________________ > 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
