]
Radim Vansa commented on ISPN-3918:
-----------------------------------
Dan at point 29, the DC on B should contain v3, shouldn't it? Not that it would change
much...
Inconsistent view of the cache with putIfAbsent in a non-tx cache
during state transfer
---------------------------------------------------------------------------------------
Key: ISPN-3918
URL:
https://issues.jboss.org/browse/ISPN-3918
Project: Infinispan
Issue Type: Bug
Components: Core, State Transfer
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Labels: consistency
Fix For: 9.2.0.Final
Attachments:
NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz,
NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz,
ntpiadjst.log.gz
In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even
though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent
operations on the cache are concurrent putIfAbsent calls.
Say \[B, A, C] are the owners of k (C just joined)
1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
2. B forwards the command to A and C
3. C writes {{k=v1}}
4. C becomes the primary owner of k (owners are now \[C, A])
5. A/B see the new topology before committing and throw an outdatedTopologyException
6. A retries the command, sends it to C
7. C forwards the command to A, which writes {{k=v1}}
8. C doesn't have to update the entry, returns null
If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command,
the command will fail and return {{v1}} (because the primary owner already has a value).
However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and
doesn't have the value.