I do finalize it - the steps I wrote were just pseudocode, but yes after the thread-A statement executes I call finalize ( or reset if I'm going to use it again ). The problem is that thread-A *never* gets to the finalize/reset call. It's thread-A which is stuck in winSleep().
On Tue, Apr 7, 2009 at 3:20 PM, D. Richard Hipp <d...@hwaci.com> wrote: > > On Apr 7, 2009, at 6:11 PM, Dave Brown wrote: > > > I am seeing the equivalent of a deadlock, with SQLITE_BUSY being > > returned > > forever from my code which has 2 threads using SQLite. I can repro > > this at > > will. Each thread is using it's own connection to the sqlite > > database, so > > they are not sharing the same connection. > > > > Here is what is happening in chronological order: > > > > Thread A: Prepare statement-A > > Thread B: Prepare statement-B > > Thread B: Bind some variables to statement-B > > Thread B: Prepare and execute "BEGIN IMMEDIATE" statement. > > Thread B: Execute statement-B > > Thread A: Bind variables to statement-A > > Thread A: Execute statement-A ( statement-A is a one-line simple SQL > > query > > like "SELECT name FROM table WHERE id= ?;" ) > > Thread B: Prepare and execute "COMMIT" statement. > > > > At this point, thread A is deep into sqlite code calling winSleep(), > > and > > thread B is getting SQLITE_BUSY returned. I can even set the busy > > timeout > > to 100 seconds and the same thing happens -- hangs until 100 seconds > > elapse, > > then busy returned. > > > > Anyone know why??? > > You didn't finalize the statement in thread-A. It is still holding a > read-lock which is preventing the COMMIT from running in thread-B. > > 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
