[infinispan-dev] Triangle and ISPN-3918

Radim Vansa rvansa at redhat.com
Mon Nov 14 09:26:45 EST 2016


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.

Radim

[1] https://issues.jboss.org/browse/ISPN-3918

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team



More information about the infinispan-dev mailing list