[infinispan-dev] Reliability of return values

[Radim Vansa]

@Dan: It's absolutely correct to do the further writes in order to make 
the cache consistent, I am not arguing against that. You've fixed the 
outcome (state of cache) well. My point was that we should let the user 
know that the value he gets is not 100% correct when we already know 
that - and given the API, the only option to do that seems to me as 
throwing an exception.

@Sanne: I was not suggesting that for now - sure, value versioning is (I 
hope) on the roadmap. But that's more complicated, I though just about 
making an adjustment to the current implementation.

Radim

On 05/12/2014 12:02 PM, Sanne Grinovero wrote:
> I don't think we are in a position to decide what is a reasonable
> compromise; we can do better.
> For example - as Radim suggested - it might seem reasonable to have
> the older value around for a little while. We'll need a little bit of
> history of values and tombstones anyway for many other reasons.
>
>
> Sanne
>
> On 12 May 2014 09:37, Dan Berindei <dan.berindei at gmail.com> wrote:
>> Radim, I would contend that the first and foremost guarantee that put()
>> makes is to leave the cache in a consistent state. So we can't just throw an
>> exception and give up, leaving k=v on one owner and k=null on another.
>>
>> Secondly, put(k, v) being atomic means that it either succeeds, it writes
>> k=v in the cache, and it returns the previous value, or it doesn't succeed,
>> and it doesn't write k=v in the cache. Returning the wrong previous value is
>> bad, but leaving k=v in the cache is just as bad, even if the all the owners
>> have the same value.
>>
>> And last, we can't have one node seeing k=null, then k=v, then k=null again,
>> when the only write we did on the cache was a put(k, v). So trying to undo
>> the write would not help.
>>
>> In the end, we have to make a compromise, and I think returning the wrong
>> value in some of the cases is a reasonable compromise. Of course, we should
>> document that :)
>>
>> I also believe ISPN-2956 could be fixed so that HotRod behaves just like
>> embedded mode after the ISPN-3422 fix, by adding a RETRY flag to the HotRod
>> protocol and to the cache itself.
>>
>> Incidentally, transactional caches have a similar problem when the
>> originator leaves the cluster: ISPN-3421 [1]
>> And we can't handle transactional caches any better than non-transactional
>> caches until we expose transactions to the HotRod client.
>>
>> [1] https://issues.jboss.org/browse/ISPN-2956
>>
>> Cheers
>> Dan
>>
>>
>>
>>
>> On Mon, May 12, 2014 at 10:21 AM, Radim Vansa <rvansa at redhat.com> wrote:
>>> Hi,
>>>
>>> recently I've stumbled upon one already expected behaviour (one instance
>>> is [1]), but which did not got much attention.
>>>
>>> In non-tx cache, when the primary owner fails after the request has been
>>> replicated to backup owner, the request is retried in the new topology.
>>> Then, the operation is executed on the new primary (the previous
>>> backup). The outcome has been already fixed in [2], but the return value
>>> may be wrong. For example, when we do a put, the return value for the
>>> second attempt will be the currently inserted value (although the entry
>>> was just created). Same situation may happen for other operations.
>>>
>>> Currently, it's not possible to return the correct value (because it has
>>> already been overwritten and we don't keep a history of values), but
>>> shouldn't we rather throw an exception if we were not able to fulfil the
>>> API contract?
>>>
>>> Radim
>>>
>>> [1] https://issues.jboss.org/browse/ISPN-2956
>>> [2] https://issues.jboss.org/browse/ISPN-3422
>>>
>>> --
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss DataGrid QA
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA