Thread A is in the process of executing sqlite3_step(). I can post the full stack if you want. It goes all the way down to winSleep() in the sqlite3 codebase. After the full busy timeout, thread B (not A) gets SQLITE_BUSY returned.
On 4/8/09, Marcus Grimm <mgr...@medcom-online.de> wrote: > just for my curiosity: > > what is thread A doing after/within the 100 seconds that elapsed > in thread B after trying to get the exclusive transaction? > maybe you simply forgot to finalize the query in thread A ? > > >> 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 >> > > > _______________________________________________ > 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
