[infinispan-issues] [JBoss JIRA] (ISPN-3737) L1 requestor registered after value read
[
https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-3737:
-------------------------------------
Good catch! Normally just putting the registration of the requestor before the get
completes would have an inverse effect (we could invalidate something that isn't
present), but because of the L1 rewrite to not store L1 values if a concurrent
invalidation occurs while waiting on a remote get, that should be a more than feasible
fix.
L1 requestor registered after value read
----------------------------------------
Key: ISPN-3737
URL: https://issues.jboss.org/browse/ISPN-3737
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.Final
Reporter: Radim Vansa
Assignee: William Burns
Priority: Critical
Labels: 620
As the L1 requestor is registered only after the value is retrieved from data container,
the (transactional) update of the value may not invalide the entry after write and the
cache gets inconsistent.
Consider this interleaving of operations (G=get request from other node, C=commit)
R: read value -> old value
C: update old -> new
C: notify requestors for key
R: add requestor for key
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira