On 14-11-2016 14:26, Radim Vansa wrote: > Hi, > > I was thinking about ISPN-3918 [1] and I've realized that while this > happens in current implementation only rarely during state transfer, > with Triangle v4 this could happen more often. > > Conditional command is always executed on primary owner, and so far > during the execution of conditional command (incl. replication to > backup-owners) the other commands to the same key were blocking in the > locking layer. Triangle v4 removes this blocking, and if in thread T1 > you do: > > T1: replace(key, A, B) > > and in second thread T2 > > T2: replace(key, A, C) > T2: get(key) > > the T2.replace can now fail before the T1.replace (successful) is > replicated to backup owner. When T2 is, by chance, the backup owner, the > T2.replace completes with false, the T2.get will be served locally and > it will still returns A. > > We should decide if this is an issue, and either close ISPN-3918 (not a > bug) or think about triangle routing of unsuccessful commands.
well... I think we could send the unsuccessful ack in FIFO order(*1). In this way, it would force the backup owner to process the T1 operation before processing the ack. get() will then return the correct value. *1 or send only in FIFO when the backup owner is the originator and the command is unsuccessful. *1 or merge the ack command + backup-write command and send them in FIFO > > Radim > > [1] https://issues.jboss.org/browse/ISPN-3918 > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev