@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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> JBoss DataGrid QA >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <[email protected]> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
