[infinispan-issues] [JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated
RH Bugzilla Integration (JIRA)
issues at jboss.org
Fri May 23 02:32:58 EDT 2014
[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969954#comment-12969954 ]
RH Bugzilla Integration commented on ISPN-3838:
-----------------------------------------------
Radim Vansa <rvansa at redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from ON_QA to VERIFIED
> L1 entry added by ST when already invalidated
> ---------------------------------------------
>
> Key: ISPN-3838
> URL: https://issues.jboss.org/browse/ISPN-3838
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1.
> 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries
> 2. Write on primary owner (B) occurs
> 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore)
> 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container.
> Result: Outdated value is in L1 cache.
> As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value).
> (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
More information about the infinispan-issues
mailing list