[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