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

[Paolo Romano]

On 9/15/11 2:51 PM, Manik Surtani wrote:
>
> On 15 Sep 2011, at 14:44, Paolo Romano wrote:
>
>> Concerning costs. For option 2), the prepare message should piggyback
>> the version identifiers of *each* data item that needs to be write-skew
>> checked...which may lead to big messages, if you needed to test a lot of
>> data items. But the ws-check is done only on the data items that are
>> both read and written within the same xact. So I'd expect that normally
>> just a few keys would need to be write-skew checked (at least this would
>> be the case for the wide majority of DBMS/STM benchmarks I've been using
>> so far).  Therefore I would not be too concerned with this issue.
>
> True, but if a vector clock is used as the underlying version scheme, 
> then the updating node would need to send across its local clock for 
> each data item, regardless of whether a ws-check is needed for that 
> data item or not.  Correct?
In fact, my answer was targeting the non-eventual consistency case.

I don't know exactly what's the algorithm you've in your mind for 
eventual consistency, thus I may be missing something here... but if the 
updating node (say node i) increases its node clock (say to value v) 
when one of its transactions commits, then the i-th entry of the vector 
clock of *every* updated data item could be set to the same value, 
namely v. So why not sending v only once?

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)?

     P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110915/c8605739/attachment.html