Hi, 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 OAK-585.
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. Regards Marcel [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:[email protected]] > Sent: Donnerstag, 31. Januar 2013 09:21 > To: [email protected] > 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 >
