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
