I understand what a deadlock is, and I know it's not technically a deadlock. This is why I stated the title as deadlock behavior.
Anyway, like I said, I can set the busy timeout to 100 seconds, and it still hangs for 100 seconds, even though the queries being performed by either thread should not take longer than a few millisecs at most. Any thoughts on my latest test with the begin exclusive method? On 4/8/09, Griggs, Donald <donald.gri...@allscripts.com> wrote: > > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dave Brown > Sent: Wednesday, April 08, 2009 1:16 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Strange sqlite_busy deadlock behavior > > 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?? > > ======================== > ======================== > Hi Dave, > > A *deadlock* would mean that neither process will ever proceed. > http://en.wikipedia.org/wiki/Deadlock > > In your situation, Thread-B would simply wait until thread-A finishes > --- either via some sort of inter-thread communication, or via polling > on the part of thread-B. > Thread-B experiences a delay, but no deadlock occurs. > > Presumably, thread-A is designed to "step lively" and not dally > unnecessarily. > > Of course, the 2nd method is great if you have no concerns about > isolation. > ("PRAGMA read_uncommitted=ON") > > _______________________________________________ > 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
