I would guess that your requests acquire (shared) read locks when the
transaction starts and then fail/deadlock when they try to upgrade this
to a write lock in your insert/update statement. Maybe it would help to
start the transactions with "BEGIN IMMEDIATE" or "BEGIN EXCLUSIVE"...?
Ulrich Schöbel wrote:
> Hi all,
>
> I'm using sqlite3 inside a Tcl module (mod_websh) of
> apache. Everything works fine, except when it comes
> to concurrent write accesses.
>
> There's a small transaction where I update two rows.
> When I stress the web server it generates a
> "database locked" error. I invoke a "db timeout 2000"
> just before the transaction, but it doesn't seem to
> have any effect.
>
> When I stumbled over this problem I increased the
> timeout to 500000, which is much longer than the
> stress test takes, but the error persists. What's
> going wrong here?
>
> Here's a short code snippet:
>
> db timeout 500000
> db transaction {
> set last_acc [lindex [db eval {
> select acc_time from last_hit where site = $site and from_ip = $ip
> }] 0]
> if {![string length $last_acc]} {
> db eval {
> insert into last_hit values ($site , $ip , $now)
> }
> set last_acc 0
> } else {
> db eval {
> update last_hit set acc_time = $now where site = $site and from_ip =
> $ip }
> }
> ......
> } ;# end of transaction
>
> There's another update inside this transaction, but
> it's always the one above that fails.
>
> Maybe the "busy" method is better suited here, but
> the docs say nothing about its usage.
>
> Thanks for any help
>
> Ulrich
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
