[
https://issues.apache.org/jira/browse/OAK-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821331#comment-13821331
]
Marcel Reutegger commented on OAK-1170:
---------------------------------------
>From what I can see MongoMK and tests currently make various assumptions about
>visibility of changes across cluster node instances, which are not in
>accordance with the MVCC model in Oak.
MongoNodeStore.publishRevision() is called when a committing thread encounters
a revision, which is newer than the current commit revision. A foreign newer
revision is then published to the RevisionComparator with a causual
relationship (happened-before denoted by ->): current-head-revision ->
foreign-revision -> new-commit-revision. At the end publishRevision() makes the
foreign revision visible by setting a new head revision (actually newer than
new-commit-revision). Later when the commit finishes, the head revision is set
to the new-commit-revision. This means the the head is set to an older revision
again.
I think is is also questionable if the foreign revision should be made visible
at all at the point. The _lastRev values of foreign cluster nodes are likely
not yet written back and not in sync with the foreign-revision. This may lead
to situations where a foreign revision is visible but not reflected in
_lastRev. I think it would be better to solely rely on the background
operations to make foreign changes visible. This however means one assumption
we currently make in some of the tests must be revised. Every now and then we
expect that a foreign change becomes visible after a conflict is detected.
While this works for the isolated case of single node, it does not work well
looking at the whole hierarchy. Again, foreign _lastRev may not be consistent
with revisions visible to the current MongoMK instance.
IMO, foreign (external) changes should only become visible with background
operations. This ensures a strict separation of changes done by the local
MongoMK instance and external changes. This is also a requirement we have from
the observation part in Oak.
The tricky part is how this affects conflict handling. A change may not succeed
on one cluster node because external changes are not yet visible. Though, the
same changes may succeed on the cluster node where the external changes were
done, because these are already visible. I don't think we can do much about
this.
To be more specific, here's what I propose:
- Do not publish newer foreign revisions to the RevisionComparator, but treat
them as FUTURE Revisions. These are always newer than the current head
revision. Thus, not visible. This avoid inconsistencies between visible
revisions and _lastRev values.
- External changes do not become visible anymore when a conflict is detected.
External changes only become visible with background operations. This avoids
updates of the head revision while commits are in progress and guarantees
external changes are not intermingled with local changes.
> Inconsistent reads with concurrent benchmark tests
> --------------------------------------------------
>
> Key: OAK-1170
> URL: https://issues.apache.org/jira/browse/OAK-1170
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
>
> Running concurrent benchmark tests with multiple Oak+MongoMK instances may
> lead to inconsistent reads. It may happen that a MongoMK instance reads child
> nodes at a given revision and then later finds out some of those children do
> not exist anymore at the same revision.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
