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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org