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)?
P
Attachments:
- attachment.html (text/html — 3.3 KB)