Zack Weinberg wrote: > On Dec 25, 2007 1:37 PM, Alvaro Herrera <[EMAIL PROTECTED]> 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) _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
