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,
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
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
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
>>>
>
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
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
-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
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
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.
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
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,
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
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
13 matches
Mail list logo