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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev