jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging
Date Thu, 21 Oct 2010 19:23:32 GMT

> See section 7 "Vector Time". Also see [1] from slide 14 onwards for a more
> approachable reference.
> [1] http://www.cambridge.org/resources/0521876346/6334_Chapter3.pdf

Thanks! From what I read so far it sounds like my idea is called "Time
Warp" / "Virtual Time".

On page 10 and 11 there is the notion of "Total Ordering": "The main
problem in totally ordering events is that two or more events at
different processes may have identical timestamp." - "A tie-breaking
mechanism is needed to order such events." - "Process identifiers are
linearly ordered and tie among events with identical scalar timestamp
is broken on the basis of their process identifiers." This is what I
meant with "+ clusterNodeId"

Vector time and Matrix time: I think it would need too much memory -
if the dimension of vector clocks is the number of cluster nodes, then
the number of dimensions would change whenever you add a cluster node.

Time Warp matches my suggestion: Page 33 says "Time Warp relies on the
general lookahead-rollback mechanism where each process executes
without regard to other processes having synchronization conflicts." -
it sounds like my proposal (I specially like the term "Time Warp").
"If a conflict is discovered, the offending processes are rolled back
to the time just before the conflict and executed forward along the
revised path." "Virtual time is implemented a collection of several
loosely synchronized local virtual clocks."


View raw message