Re: [infinispan-dev] Versioned entries - overview of design, looking for comments
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(a)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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev