On May 28, 2014, at 11:48, Galder ZamarreƱo <galder(a)redhat.com> wrote:
On 27 May 2014, at 18:47, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>
> On May 13, 2014, at 14:58, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
>>
>>
>>
>> On Mon, May 12, 2014 at 1:54 PM, Radim Vansa <rvansa(a)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&p...
You are right, retrying is better client experience than failing blindly.
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)