Re: [infinispan-dev] Versioned entries - overview of design, looking for comments
On 9/16/11 12:58 PM, Manik Surtani wrote:
On 15 Sep 2011, at 15:41, Paolo Romano wrote:
> Do you want to increase the value stored in the i-th entry of each
> data item updated by a committing transaction independently (i.e.
> data_item.VC[i]=data_item.VC[i]+1 instead of
> data_item.VC[i]=++Node_clock_at_i)?
I think the latter should be sufficient. As you say it means less
data on the wire, but also it scales better as you don't need to
maintain one counter per node per data item. Can you think of why
this approach may fall short?
- with the latter approach, the ids of two subsequent
versions of the
same data item created by the same node can have "gaps" (non-consecutive
version ids). Thus a node that had to reconcile two versions v', v'' of
a data item created by node i, where v'[i]>v''[i]+1, would not be able
to figure out if it missed just a single update of i, or more than one
(although it could determine that v' is more recent than v''). I imagine
this would not normally be an issue for reconciliation, but the
reconciliation logic is ultimately highly application dependent, so it's
hard to tell...
- version identifiers may run out more rapidly, so wrap-arounds could
become more frequent. But the wrap-around issue should be addressed
anyway... and even at high throughput, using longs to store version
identifiers, this should still be a rare event (though I didn't do the
math).
+ an other advantage of the latter solution is that it allows for
temporally (total) ordering the versions of two *different* data items
created/updated by the same node (by comparing the ids stored in the
entry of the updating node). I guess that this information might be
exploited in some reconciliation scenarios.
P