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

Marcel Reutegger commented on OAK-3646:
---------------------------------------

I started to work on a fix that gets rid of the current RevisionComparator. Its 
use is the primary source of trouble because it does not provide a stable 
comparison of revisions across cluster nodes. Ordering of revisions with 
different clusterIds may change when one of the revision timestamps becomes 
older than one hour.

As a replacement for the RevisionComparator I'd like to introduce a 
RevisionVector. This is a replacement for Revision whenever the 
DocumentNodeStore reads a node state at a given 'revision'. Instead of relying 
on additional information from the RevisionComparator, the RevisionVector 
already contains the information about what Revisions from other cluster nodes 
are visible at that time (local revision).

E.g. given a RevisionVector \[r7-0-1, r4-0-2] for the root node state on 
cluster node 1, this means this cluster nodes sees changes up to r4-0-2 from 
cluster node 2. Traversing down the tree will update the read revision vector 
according to _lastRev entries and explicit modifications on the document. 
Calculating a node state at some read revision vector does not need additional 
information to decide if a change is visible or not. It simply compares the 
revision with the revision vector to decide if the revision is visible or not.

> Inconsistent read of hierarchy 
> -------------------------------
>
>                 Key: OAK-3646
>                 URL: https://issues.apache.org/jira/browse/OAK-3646
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, documentmk
>    Affects Versions: 1.0, 1.2
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>             Fix For: 1.4
>
>
> This is similar to OAK-3388, but about hierarchy information like which child 
> nodes exist at a given revision of the parent node. This issue only occurs in 
> a cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to