Please ignore my message, Marcel answered my questions. Ian
On 31 January 2013 20:15, Ian Boston <[email protected]> wrote: > On 31 January 2013 19:21, Thomas Mueller <[email protected]> wrote: >> Hi, >> >>>no, it's quite different. the equivalent to the journal in Jackrabbit 2.x >>>is rather the commit collection. >>> >>>the sync collection contains only a single document, which points to >>>the head of the commit history. so, it is somewhat similar to the >>>InstanceRevision we have in Jackrabbit 2.x clustering. >> >> Sorry for the confusion, Marcel is right of course. The only way that the >> MongoMK "sync" collection is similar to the Jackrabbit 2.x journal is: >> write access to both is serialized. But that's it. (I hope I got that >> right now :-) > > > IIRC In JR2 each journal update was in a transaction that incremented > the revision number, so the sequence had no holes. > > In MongoMK, am I right in thinking that since the sync collection only > points to the head revision it only needs to be locked for as long as > it takes to write the pointer to the head revision vastly reducing the > time which other writers are blocked. > > Is that right or is the serialisation the same as in JR2 ? > > Also wondering: Do you need a sync at all or would a fuzzy distributed > time signal (as used in Google Spanner) would give you enough padding > between operations to know their sequence ? > Please dont waste any time on this if its a simple "no". > > Ian > > >> >> Regards, >> Thomas >> >>
