6:24 a.m.
[
https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-3918:
------------------------------------
The situation is even worse when the topology changes: a {{get}} after a failed
{{putIfAbsent}} can return not only {{null}}, but also a completely different value.
Say {{owners(k) = AB}}, and there is a topology change but the owners of {{k}} stay the
same. In the following scenario, thread _B-app3_ first sees {{putIfAbsent(k, v3) = v2}},
and then {{get(k) = v1}} (_B-appX_ means application thread X on B, and _A-remoteX_ means
remote thread X on A):
# _B-app1_: start putIfAbsent(k, v1)
# _B-app1_: send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: send backup request for putIfAbsent(k, v1) to B
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: write k=v1
# _B-remote1_: send backup ack for putIfAbsent(k, v1)
# _A-remote1_: check topology, send OutdatedTopologyException back to B
# _A-app2_: start putIfAbsent(k, v2)
# _A-app2_: send backup request for putIfAbsent(k, v2) to B
# _A-app2_: write k=v2
# _B-app3_: start putIfAbsent(k, v3)
# _B-app3_: send putIfAbsent(k, v3) to A (primary)
# _A-remote3_: receive putIfAbsent(k, v3)
# _A-remote3_: read v2 from data container, fail the command
# _B-remote3_: receive v2 for putIfAbsent(k, v3)
# *_B-app3_: return v2 for putIfAbsent(k, v3) (put was unsuccessful)*
# _B-app3_: start get(k)
# _B-app3_: read v1 from local container
# *_B-app3_: return v1 for get(k)*
# _B-remote2_: receive putIfAbsent(k, v2) backup command
# _B-remote2_: write k=v2
# _B-remote2_: send backup ack for putIfAbsent(k, v2)
# _A-remote2_: receive backup ack for putIfAbsent(k, v2)
# *_A-app2_: return null for putIfAbsent(k, v2) (put was successful)*
# _B-remote1_: receive OutdatedTopologyException for putIfAbsent(k, v1)
# _B-remote1_: retry, send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: read v2 from data container, fail the command
# _B-remote1_: receive v2 for putIfAbsent(k, v1)
# *_B-app1_: return v2 for putIfAbsent(k, v1) (put was unsuccessful)*
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: 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)