Re: [Monotone-devel] Commit without working copy

[Nathaniel Smith]

On Mon, Dec 06, 2004 at 12:23:07AM +0800, Grzegorz Jakacki wrote:
> Nathaniel Smith wrote:
> >Also, note that you need some locking to make sure that only one
> >'monotone' subprocesses runs at the same time to access the same
> >database; Monotone won't corrupt your data in any case, but will error
> >out rather than blocking and waiting for the DB to become available.
> 
> Is this monotone's or SQLLite's problem? I don't know SQLLite, but it 
> looks like it does not support multiuser access, does it? What if I 
> replace SQLLite with multiuser ACID-compliant database and have many 
> monotones modifying this database concurrently?

It's Monotone's problem.  SQLite does support concurrent access (and
is in fact a multiuser ACID-compliant database, if you can accept
"multiple people have write permission to this file" as how you get
"multi-user").  But Monotone is a single-user single-threaded app,
and 1) the way we use SQLite, we basically lock the database the whole
time we're running, and it would take work to figure out the correct
dance to make this not happen, and 2) having done this, you'd have to
carefully audit the Monotone code to make sure that concurrent access
wouldn't break anything.  Probably a lot of things would work fine,
but no-one really knows for sure.  I don't think we're really
interested in doing this kind of careful checking either, because we
get a _lot_ of benefits in simplicity (= speed, maintainability,
robustness, ...) from side-stepping the whole concurrency issue.  (The
worst part isn't doing the checking, it's redoing it every time we
ever make a change in the future...)

Some sort of filesystem based locking (sentinel files, or flock()) is
a common and pretty well-understood thing in web app design, and not
very hard to implement; I think my recommendation would be just to go
with that.

-- Nathaniel

-- 
.i dei jitfa fanmo xatra