[
https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin....
]
Sebastian Tusk commented on ISPN-2990:
--------------------------------------
Actually sending the invalidation to origin isn't enough.
B is owner of k,v1
A has k,v1 in L1
1. A calls remove(k)
2. A starts retrieval of k
3. B sends k to A
4. B removes k
5. B sends invalidation to A
6. A removes k
7. A puts k into L1
L1ManagerImpl doesn't reliably invalidate with async caches
-----------------------------------------------------------
Key: ISPN-2990
URL:
https://issues.jboss.org/browse/ISPN-2990
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.2.1.Final
Reporter: Sebastian Tusk
Assignee: Mircea Markus
B is owner of k,v1
A has k,v1 in L1
1. TX: A puts k,v2
2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit)
3. TX: A removes k,v1 from L1
4. A putForExternalRead k,v1 and has it in L1 again
5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin
Result: A has k,v1 and B has k,v2
Solution: For async caches send invalidation to origin too.
The problem is that the owner updates the cache entry asynchronously. This gives the
origin of the transaction time to request the entry. Here an outdated version is received
and placed in L1. The owner never invalidates the entry and as result the cache is
inconsistent.
--
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