[infinispan-issues] [JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931791#comment-12931791 ] 

Radim Vansa commented on ISPN-3838:
-----------------------------------

Similar situation happens in transactional mode.
                
> 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: Distributed Cache
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Vansa
>            Assignee: William Burns
>            Priority: Critical
>
> 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 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