jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Concurrency Question
Date Thu, 31 Jan 2013 09:17:35 GMT
Please ignore my message, Marcel answered my questions.

On 31 January 2013 20:15, Ian Boston <ieb@tfd.co.uk> wrote:
> On 31 January 2013 19:21, Thomas Mueller <mueller@adobe.com> 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

View raw message