[infinispan-dev] Triangle and ISPN-3918

[Pedro Ruivo]

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
>