>
> What you described about the locking is correct. The threading isn't
> strictly relevant; locking is done on a per-connection basis, not
> per-thread.
>
Yes, I think this was what was missed in our application's original
implementation; it was not fully appreciated that locking was
per-connec
http://www.sqlite.org/lockingv3.html
where A3 means the processes 3rd connection.
A1 - Shared (select)
B2 - Pending (insert)
A3 - Shared (select)
Looks like a deadlock at A3. B2 has a pending Lock and can not make further
progress until A1 completes. But A3 is now waiting on B2.
Eith
On 8/29/07, Ben Mann <[EMAIL PROTECTED]> wrote:
> The problem is that connection A is calling a function which is attempting
> to open a new SHARED connection. Since it can't (B's PENDING prevents this,
> because of A's earlier SHARED connection), A blocks.
>
> If instead, A does not open a new c
Thanks Dan,
The problem is that connection A is calling a function which is attempting
to open a new SHARED connection. Since it can't (B's PENDING prevents this,
because of A's earlier SHARED connection), A blocks.
If instead, A does not open a new connection, but uses what it already has
open,
On Thu, 2007-08-30 at 13:25 +0800, Ben Mann wrote:
> I have a multithreaded application which is exhibiting some unexpected
> behaviour in the form of SQLITE_BUSY api return codes. I've traced
> this back to a fairly simple way to model the problem, but I can't
> seem to find any documentation whic
I have a multithreaded application which is exhibiting some unexpected
behaviour in the form of SQLITE_BUSY api return codes. I've traced
this back to a fairly simple way to model the problem, but I can't
seem to find any documentation which explicitly describes this issue.
I'll summarise the probl
6 matches
Mail list logo
