Re: [sqlite] Strange sqlite_busy deadlock behavior

Dave, Regarding: "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." My apologies, Dave. I thought there might actually have been a difference in definition that was adding to your problem. After your reply,

Re: [sqlite] Strange sqlite_busy deadlock behavior

Each thread has it's own connection handle (stated this in the original email). anyone want to see a stack trace? On Wed, Apr 8, 2009 at 2:22 PM, Lawrence Gold wrote: > On Apr 8, 2009, at 3:12 PM, Dave Brown wrote: > > > Thread A is in the process of executing

Re: [sqlite] Strange sqlite_busy deadlock behavior

On Apr 8, 2009, at 3:12 PM, Dave Brown wrote: > 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. Does each

Re: [sqlite] Strange sqlite_busy deadlock behavior

ers-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 >>> >

Re: [sqlite] Strange sqlite_busy deadlock behavior

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 o

Re: [sqlite] Strange sqlite_busy deadlock behavior

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

Re: [sqlite] Strange sqlite_busy deadlock behavior

-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

Re: [sqlite] Strange sqlite_busy deadlock behavior

I think the EXCLUSIVE pill (to avoid calling it poison) should have done the job and the busy state is expected and no dead lock, right ? I would like to assure that sqlite works great in such a thread environment, despite the sqlite parents seems not like the idea...;) Marcus > I tried the

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?? On 4/8/09, D.

Re: [sqlite] Strange sqlite_busy deadlock behavior

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

Re: [sqlite] Strange sqlite_busy deadlock behavior

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? On 4/7/09, D. Richard Hipp wrote: > > On Apr 7,

Re: [sqlite] Strange sqlite_busy deadlock behavior

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