[
https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727326#comment-14727326
]
Marcel Reutegger edited comment on OAK-3042 at 9/2/15 2:53 PM:
---------------------------------------------------------------
Turning the data of a test run into a stacked graph shows something like this:
!commit-graph.png|width=100%!
Every now and then the commit rate drops to zero for a session and sometimes
only one session makes progress.
was (Author: mreutegg):
Turning the data of a test run into a stacked graph shows something like this:
!commit-graph.png|with=100%!
Every now and then the commit rate drops to zero for a session and sometimes
only one session makes progress.
> Suspend commit on conflict
> --------------------------
>
> Key: OAK-3042
> URL: https://issues.apache.org/jira/browse/OAK-3042
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Labels: resilience
> Fix For: 1.3.6
>
> Attachments: OAK-3042.patch, commit-graph-patched.png,
> commit-graph.png
>
>
> A DocumentNodeStore cluster currently shows a conflict behavior, which
> is not intuitive. A modification may fail with a conflict even though
> before and after the conflict, the external change is not visible to
> the current session. There are two aspects to this issue.
> 1) a modification may conflict with a change done on another cluster
> node, which is committed but not yet visible on the current cluster node.
> 2) even after the InvalidItemStateException caused by the conflict, a
> refreshed session may still not see the external change.
> The first aspect is a fundamental design decision and cannot be changed
> easily.
> The second part can be addressed by suspending the commit until the external
> conflict becomes visible on the current cluster node. This would at least
> avoid the awkward situation where the external change is not visible after
> the InvalidItemStateException.
> The system would also become more deterministic. A commit currently goes
> into a number of retries with exponential back off, but there's no guarantee
> the external modification becomes visible within those retries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
