Re: [infinispan-dev] Triangle and ISPN-3918
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