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

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