[infinispan-dev] Versioned entries - overview of design, looking for comments

[Paolo Romano]

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