Re: [Monotone-devel] RFC: do no exit mtn if database is locked

[Ulf Ochsenfahrt]

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