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

[Dan Berindei]

On Wed, Sep 14, 2011 at 7:48 PM, Sanne Grinovero <sanne at 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 <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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev