Brad,
its my understanding that Locking occurs at the Database level, not the table
level.
http://www.sqlite.org/lockingv3.html
Brad House <[EMAIL PROTECTED]> wrote: > Here are my results after modifying
the "begin transaction" to a "begin exclusive"
> Begin transaction is a bit Lazy
[EMAIL PROTECTED] wrote:
>> It appears that if 2 threads start transactions at the same time,
>> both inserting into the same table, neither thread can finish until
>> one has rolled back.
> The behavior is deliberate because it gives you, the programmer,
> more control and better concurrency in so
> Here are my results after modifying the "begin transaction" to a "begin
> exclusive"
> Begin transaction is a bit Lazy in that the lock escalation doesnt occur
> until the pager escalates the lock due to a write.
>
> You'll see that the begin exclusive acquires a lock immediately and avoid
Brad House <[EMAIL PROTECTED]> wrote:
> I've read http://www.sqlite.org/cvstrac/wiki?p=MultiThreading under the
> "Case in point: a benchmark application I've written for this purpose"
> and found that current releases of SQLite do not appear to behave in
> this manner. I cannot find any documenta
Brad,
Here are my results after modifying the "begin transaction" to a "begin
exclusive"
Begin transaction is a bit Lazy in that the lock escalation doesnt occur until
the pager escalates the lock due to a write.
You'll see that the begin exclusive acquires a lock immediately and avoids th
I've read http://www.sqlite.org/cvstrac/wiki?p=MultiThreading under the
"Case in point: a benchmark application I've written for this purpose"
and found that current releases of SQLite do not appear to behave in
this manner. I cannot find any documentation which clearly states
the intended behavio
6 matches
Mail list logo
