jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: Concurrency Question
Date Thu, 31 Jan 2013 08:34:48 GMT

to elaborate a bit more on this topic. with the current mongomk
implementation the serializing aspect of the sync collection leaks
into the commit collection. that is, even though mongomk allows
two collections to concurrently write nodes and commits, it eventually
has to serialize on the sync update. but if that fails and in most
cases it will fail when you have concurrent commits, then it currently
means one of the writes will have to retry, which includes writing
the nodes and the commit document again. This is captured in

As mentioned in the issue [0] a scheduler may help here to avoid
retries. An alternative approach was brought up by Jukka in his
MongoMK^2 proposal. Maintain multiple Journals in a hierarchy at
the cost of consistency. The way this could be implemented in the
current MongoMK is to have multiple documents in the sync
collection (aka journal heads). A process then needs to merge those
Journals regularly and handle conflicts.


[0] https://issues.apache.org/jira/browse/OAK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566335#comment-13566335

> -----Original Message-----
> From: Thomas Mueller [mailto:mueller@adobe.com]
> Sent: Donnerstag, 31. Januar 2013 09:21
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: Concurrency Question
> 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 :-)
> Regards,
> Thomas

View raw message