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

[Alvaro Herrera]

Zack Weinberg wrote:
> On Dec 25, 2007 1:37 PM, Alvaro Herrera <address@hidden> wrote:
> > Zack Weinberg wrote:
> > > The way forward is pretty clear --
> > [...]
> > Wow.  This is so much a lot of work for something that the database
> > system should be doing on its own!
> 
> I don't see how you could possibly think that.  Most of the problem is
> that Monotone isn't telling the database when it only needs read-only
> access; no matter what database we were using, we'd have to fix that.

Why would the database care?  If the appropriate constraints are in
place, the database itself would alert Monotone when an operation it is
attempting would conflict with another ongoing operation.

Conflicting updates would perhaps be detected as serialization failures,
which are obviously a problem only for writers and would need to be
retried in the writer that failed.  The assumption here is that a write
conflict is a rare event, so the extra cost of having to retry is not
too onerous anyway.  (My assumption here is that not all writes to the
database conflict -- i.e. if process A updates file F, then process B
can be updating file G without a conflict.  Perhaps this is mistaken.)

Readers need not know nor care whether a write is in flight or not.  If
two readers (or however many, really) are using the database, they would
simply never see any transaction abort from the database system.  If a
writer is updating and a reader comes about, it would not see the
effects of the writer.

I think the problem stems from assuming that the database is a stupid
system.  SQLite gains its simplicity from that assumption, which is fine
for an embedded database, but other RDBMSs are not necessarily like
that.

-- 
Alvaro Herrera                  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)