[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