Re: [Monotone-devel] mtn: error: sqlite error: database is locked

[Zack Weinberg]

On Dec 22, 2007 9:07 PM, Roland McGrath <address@hidden> wrote:
> So, um, wtf?  I've read http://www.venge.net/mtn-wiki/DatabaseLocking.
> Is that still the status quo?  Really?  Verily and forsooth?

I'm afraid so.

[...]
> This sort of issue is making it a bit hard to try to convince
> anyone that monotone is ready for prime time.  (Yeah, yeah, slow-moving
> all-volunteer effort, no guarantees, blah, blah, I do know the drill.)

The present situation is a bit more severe than the usual "slow-moving
volunteer effort" -- there's been very little forward motion on this
or any of the other core issues since, like, last February.  I'm
assuming that this is just that all of the core developers have been
extremely busy since then; that's definitely true for me and
Nathaniel.  I am hoping to have a little more spare hacking time
starting in January and the database locking is definitely close to
the top of my list, but perhaps I can persuade you to put some time
into it?  The way forward is pretty clear --

1) Take the 'db' member out of class app_state.  A database object
should be allocated on the stack by each CMD() function that actually
needs it, and passed down to all underlying layers as a function
argument.  At this stage it would also be good to refactor the
database object using the pointer-to-opaque idiom, so that none of its
instance variables are visible.

2) Split class database into class ro_database and class rw_database,
the former exposing only those member functions that do read-only
database operations.  Adjust all CMD functions to create the
appropriate one for what they do; adjust lower layer function
prototypes to request the one they need.  rw_database should be a
subclass of ro_database so that it's an acceptable argument to
functions that take ro_database.

3) Change transaction_guard so that it takes out a read lock if
created from a ro_database.  Change the "unlocked" sql execute
functions to do the same.

4) It may be necessary to make changes to sqlite so that it opens the
database file read-only, and uses shared file locks, if it's only
being asked to do read operations.
4a) It may also be necessary to distinguish in the type system between
a truly read-only database handle, and a read-only database that will
become read-write later if preconditions are satisfied.

zw