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

Manik Surtani manik at jboss.org
Thu Sep 15 08:59:22 EDT 2011


On 14 Sep 2011, at 17:48, Sanne Grinovero wrote:

> Wouldn't the node performing the operation always do an RPC anyway iff
> the intended operation is to replace a specific value?
> 
> Examples:
> 
> - If I do a put() operation which doesn't skip the return value, the
> RPC has to be perfomed, we get the current version value which is what
> we will check to be unchanged when committing the write operation.
> This includes putIfAbsent, and all other "atomic" operations, which
> are of common use and all need an RPC anyway. This means that L1
> caches will contain the version number as well.

Yes, if we don't skip the return value there is no extra penalty.

> 
> - If I do a put() operation in which I skip the return value, or a
> remove() without any check (nor lock), it seems the user intention is
> to overwrite/delete whatever was there without any further check at
> commit time. In fact this doesn't "acquire" the optimistick lock.

Overwriting is fine, but the version is still needed to increment it.  If we're using a simple version based on a long, there is no issue, but if we're using a vector clock, each node maintains a counter.

> - any read operation will need an RPC anyway, (If relevant: I guess
> for this case we could have different options if to rollback or
> proceed when detecting stale reads at commit time.)
> 
> - any lock() operation will force such an RPC.
> 
> I don't think I understood the difference between #1 - #2. In both
> cases the writing node needs to retrieve the version information, and
> the key owner will perform the version increment at commit time, if
> the skew check is happy.

Not really.  In the case of #1, the writer requests the version, increments the version and sends out the new version to the data owner for write skew check and commit.  In the case of #2, the writer just sends the data + its own incremented "local counter" (or nothing if not using a vector clock) and the data owner merges this incremented counter with the entry's full vector clock and then does the write skew check and commit.

Cheers
Manik

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org






More information about the infinispan-dev mailing list