On Wed, Sep 14, 2011 at 7:48 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > Wouldn't the node performing the operation always do an RPC anyway iff > the intended operation is to replace a specific value? >
I was thinking along the same lines, if there is no value in the InvocationContext (L0 cache?) then there's no point in doing any write skew check. > 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. > I see a problem with this reasoning, as either with Jokre or with the forthcoming void put() operation in JSR-107 the user will not make a conscious decision to skip the return value. But I still don't think the write skew check is useful if the value was not previously read by the user in that transaction. > - 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.) > I thought the write skew check only applied to write operations. But it would be nice to force a write skew check on a key without a write (like an optimistic equivalent of lock()). > - 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. > The way I understood it #1 forces the remote get even if the user didn't request it, but as you said it could just skip the write skew check in that case. #2 looks to me like it doesn't fetch the remote version at all, but I'm having trouble understanding how the owner will perform the write skew check. Dan > Sanne > > > On 14 September 2011 16:03, Manik Surtani <ma...@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 >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
