On 15 February 2016 at 14:49, Marcel Reutegger <[email protected]> wrote:
> Hi, > > On 12/02/16 17:11, "[email protected] on behalf of Ian Boston" wrote: > >Is there an assumption that the revisions listed in _revisions are > >ordered ? > > There is no requirement that entries in _revisions map > are ordered at the storage layer, but the DocumentStore > will order them when it reads the entries. The entries > are sorted according to the timestamp of the revision, > then revision counter and finally clusterId. > > >If not, then how is the order of the revisions be determined, given that > >the clocks on each node in a cluster will have different offsets ? > > Oak 1.0.x and 1.2.x maintain a revision table (in RevisionComparator) > for each cluster node, which allows it to compare revision across > cluster nodes even when there are clock differences. At least for > the 60 minutes timeframe covered by the RevisionComparator. > > Oak 1.4 uses revision vectors and does not maintain a revision > table anymore. See OAK-3646. At the same time it also simplifies > how revisions are compared and how changes are pulled in from > other cluster nodes. The background read operation ensures that > external changes made visible all have a lower revision timestamp > than the local clock. This ensure that all local changes from that > point on will have a higher revision timestamp than externally > visible changes. This part was also backported to 1.0 and 1.2. > See OAK-3388. > So, IIUC, (based on Revision.compareTo(Revision) used by StableRevisionComparitor. If one instance within a cluster has a clock that is lagging the others, and all instances are making changes at the same time, then the changes that the other instances make will be used, even the the lagging instance makes changes after (in real synchronised time) the others ? I can see that this won't matter for the majority of nodes, as collisions are rare, but won't the lagging instance be always overridden in the root document _revisions list ? Are there any plans to maintain a clock difference vector for the cluster ? Best Regards Ian > > Regards > Marcel > >
