> We'd need to revise the MicroKernel contract for that, essentially to > require that a commit be rejected if it isn't based on the latest > revision. Without separate journals like in the SegmentMK, that would > introduce a major scalability bottleneck.
hmm, I don't think so. the contract allows the implementation to merge concurrent changes when the commit() (or merge()) isn't done with the current head revision. the contract isn't very specific and definitively needs an update to include the conflict handling work Michael did for rebase(), but I don't see why this is a scalability problem. e.g. the MongoMK performs conflict detection on the MongoDB document level without the use of a journal or some other global synchronization point. the only downside of this design is that it only guarantees snapshot isolation and permits write skew anomalies. see also previous discussions we had on this list. regards marcel
