[infinispan-dev] Reliability of return values

[Mircea Markus]

On May 28, 2014, at 11:48, Galder Zamarreño <galder at redhat.com> wrote:

> On 27 May 2014, at 18:47, Mircea Markus <mmarkus at redhat.com> wrote:
> 
>> 
>> On May 13, 2014, at 14:58, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Mon, May 12, 2014 at 1:54 PM, Radim Vansa <rvansa at redhat.com> wrote:
>>> @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.
>>> 
>>> The problem, as I see it, is that users also expect methods that throw an exception to *not* modify the cache.
>>> So we would break some of the users' expectations anyway.
>> 
>> I don't see how we can guarantee that if a method throws an exception nothing has been applies without a 2PC/TX. I think this should be a expectation for non-tx caches. i.e. if an operation throws an exception, then the state of the data is inconsistent.
> 
> If we did that, our retry logic would remain badly broken for situations like the one mentioned in ISPN-2956. Unless you want to get rid of the retry logic altogether and let the client users decide what to do, I think we should improve the retry logic to better deal with such situations, and we have ways to do so [1]
> 
> [1] https://issues.jboss.org/browse/ISPN-2956?focusedCommentId=12970541&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12970541

You are right, retrying is better client experience than failing blindly.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)