[infinispan-issues] [JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
William Burns (JIRA)
jira-events at lists.jboss.org
Wed Jun 5 16:34:55 EDT 2013
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779643#comment-12779643 ]
William Burns commented on ISPN-2990:
-------------------------------------
[~mircea.markus] I wouldn't think this would occur with a synchronous cache. In that case the remove would block until the owning nodes had updated their internal state. In that case the get would return the proper value from the owning node. If you had interleaving puts from an additional node that should be okay with sync as well since they both would cause invalidations to occur for each other node, except for the bug in ISPN-2965. Unless I am missing something this one seems specific to async caches.
> 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: William Burns
> Labels: onboard
>
> 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
More information about the infinispan-issues
mailing list