Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer

[Markus Schiltknecht]

Hi Nathaniel,

Nathaniel Smith wrote:
> I'm not sure the solution is as simple as that.

Full ACK, it's certainly not a quick solution. Adding support for 
Postgres would come with it's very own can of worms. You'd have to 
reduce round-trips from monotone to the database dramatically. Or let 
(parts of) monotone run within the scope of the Postgres backend 
process, which isn't exactly simple either.

> Postgres isn't magic;

Oh, but WRT concurrency it comes pretty close to being magic. :-)

No seriously: it provides MVCC, which allows for (some) concurrency for 
writing transactions. That in turn would make the transaction 
multiplexing unnecessary.

> are you sure you aren't just moving the problem around?  Which
> transaction isolation level would you be planning to use?

For the problem at hand, it doesn't matter that much if you are using 
READ COMMITTED or SERIALIZABLE: as long as you have one single 
transaction per netsync session, you can atomically commit or abort it 
at the end.

However, both serialization levels would have their pros and cons for 
netsync: with READ COMMITTED, you'd have fewer or to no aborts due to 
serialization errors. But the netsync code would have to cope with a 
changing snapshot of the database - I'm not sure how badly that hurts 
the current netsync implementation. OTOH with SERIALIZABLE, you'd get a 
single consistent snapshot. But in case of a serialization error you'd 
have to rerun the complete transaction, which is certainly problematic 
for netsync. Then again, I'd suppose netsync transactions to conflict 
only very rarely - given a reasonable implementation, that is.

Anyway, my point is: better use a bigger RDBMS if you need it's 
features! SQLite is very good at being an embedded SQL database, as long 
you only need one writer at a time. Trying to go beyond that is not 
within the scope of SQLite, because only MVCC or some sort of row level 
locking would help solving the consistency problem posed upthread.

Regards

Markus