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

[Sanne Grinovero]

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.

 - 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.

- 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.

Sanne


On 14 September 2011 16:03, Manik Surtani <manik at jboss.org> wrote:
> So I've been hacking on versioned entries for a bit now, and want to run the designs by everyone. Adding an EntryVersion to each entry is easy, making this optional and null by default easy too, and a SimpleVersion a wrapper around a long and a PartitionTolerantVersion being a vector clock implementation.  Also easy stuff, changing the entry hierarchy and the marshalling to ensure versions - if available - are shipped, etc.
>
> Comparing versions would happen in Mircea's optimistic locking code, on prepare, when a write skew check is done.  If running in a non-clustered environment, the simple object-identity check we currently have is enough; otherwise an EntryVersion.compare() will need to happen, with one of 4 possible results: equal, newer than, older than, or concurrently modified.  The last one can only happen if you have a PartitionTolerantVersion, and will indicate a split brain and simultaneous update.
>
> Now the hard part.  Who increments the version?  We have a few options, all seem expensive.
>
> 1) The modifying node.  If the modifying node is a data owner, then easy.  Otherwise the modifying node *has* to do a remote GET first (or at least a GET_VERSION) before doing a PUT.  Extra RPC per entry.  Sucks.
>
> 2) The data owner.  This would have to happen on the primary data owner only, and the primary data owner would need to perform the write skew check.  NOT the modifying node.  The modifying node would also need to increment and ship its own NodeClock along with the modification. Extra info to ship per commit.
>
> I'm guessing we go with #2, but would like to hear your thoughts.
>
> Cheers
> Manik
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>