[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] RFC: do no exit mtn if database is locked
From: |
Ulf Ochsenfahrt |
Subject: |
Re: [Monotone-devel] RFC: do no exit mtn if database is locked |
Date: |
Fri, 27 Oct 2006 18:58:18 +0200 |
User-agent: |
Icedove 1.5.0.7 (X11/20061013) |
Nuno Lucas wrote:
Also, by always retrying, you can get into a deadlock, as explained in
the documentation you have linked to.
I was very surprised by this, and looked at the linked page:
http://www.sqlite.org/capi3ref.html#sqlite3_busy_handler
It says that retrying could result in a deadlock, when two processes
simultanesouly try to do lock promotion (dunno if mtn uses lock
promotion at all, but if so, it must use two different kinds of lock
promotion in different parts of the code), and to reduce the likelihood
of deadlock, it will then return an error code to one of the processes
instead of calling the busy callback.
I read that as meaning that you can avoid deadlocks in two different ways:
- don't use lock promotion (I'm guessing that mtn doesn't use that anyway)
- when you get an error code of SQLITE_BUSY from sqlite, back off and
release the read lock
So retrying to acquire the read lock, if you don't already hold a lock,
can never result in a deadlock. Correct me if I'm wrong, I don't have
much sqlite experience.
You may want to give a look into the sqliteDefaultBusyCallback()
implementation (in the sqlite source file main.c), which is the one
setup by the sqlite3_busy_timeout() function.
An option to retry the database lock aquiry would help significantly
with the eclipse plugin. :D
Cheers,
-- Ulf
smime.p7s
Description: S/MIME Cryptographic Signature