On May 28, 2014, at 11:48, Galder Zamarreño <[email protected]> wrote:
> On 27 May 2014, at 18:47, Mircea Markus <[email protected]> wrote: > >> >> On May 13, 2014, at 14:58, Dan Berindei <[email protected]> wrote: >> >>> >>> >>> >>> On Mon, May 12, 2014 at 1:54 PM, Radim Vansa <[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
