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

Reply via email to