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&gt; 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 > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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.

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

On 15 Sep 2011, at 14:44, Paolo Romano wrote: > Concerning costs. For option 2), the prepare message should piggyback > the version identifiers of *each* data item that needs to be write-skew > checked...which may lead to big messages, if you needed to test a lot of > data items. But the ws-check is done only on the data items that are > both read and written within the same xact. So I'd expect that normally > just a few keys would need to be write-skew checked (at least this would > be the case for the wide majority of DBMS/STM benchmarks I've been using > so far). Therefore I would not be too concerned with this issue. True, but if a vector clock is used as the underlying version scheme, then the updating node would need to send across its local clock for each data item, regardless of whether a ws-check is needed for that data item or not. Correct?

On 15 Sep 2011, at 15:41, Paolo Romano wrote: > Do you want to increase the value stored in the i-th entry of each > data item updated by a committing transaction independently (i.e. > data_item.VC[i]=data_item.VC[i]+1 instead of > data_item.VC[i]=++Node_clock_at_i)? I think the latter should be sufficient. As you say it means less data on the wire, but also it scales better as you don't need to maintain one counter per node per data item. Can you think of why this approach may fall short?

On Sep 14, 2011, at 4:03 PM, Manik Surtani 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. I think we might need support for other versions to be able to deal with external database or JPA versions. I'll be speaking about this next week :)