[
https://issues.apache.org/jira/browse/OAK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566322#comment-13566322
]
Michael Dürig commented on OAK-585:
-----------------------------------
bq. some exceptions (eg. concurrent updates) should cause retry
Generally yes. However, when this happens the system might be already under
load. Hitting it with more load by an immediate retry will only make things
worse. IMO the best thing to do here is to have some kind of an exponential
back off with a little randomisation added. If committing still does not
succeed after a couple of tries, I'd throw an exception "gave up".
> Reduce cost of commit retry
> ---------------------------
>
> Key: OAK-585
> URL: https://issues.apache.org/jira/browse/OAK-585
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Affects Versions: 0.6
> Reporter: Marcel Reutegger
> Attachments: OAK-585-1&2.patch, OAK-585-1&2.patch, OAK-585-1.patch,
> OAK-585-2.patch, OAK-585-3.patch
>
>
> MongoMK currently has a retry mechanism when it commits changes. Its main
> purpose is to make sure the headRevId in the sync collection is updated
> consistently and concurrent conflicting commits are detected. Under higher
> concurrency it may happen that commits are retried multiple times, even when
> commits are non-conflicting. In this case its only about consistently
> updating the headRevId. When this happens the commit will get a new revision
> and the nodes of the commit are written again with the new revision, even
> though no changes to the nodes are needed. Only the revision needed an update.
> The cost of a retry should be reduced in this case. At least a commit retry
> should not leave garbage in the nodes and commits collections.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
