[infinispan-issues] [JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

[William Burns (JIRA)]

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

William Burns edited comment on ISPN-3648 at 10/21/13 6:43 PM:
---------------------------------------------------------------

It sounds like the issue is that the non owner requests a get but only the backup owner answers and the get doesn't reach the primary until after the update occurs causing it to cache an invalid value.

I am thinking this may be due to the fact that the tx l1 code only did invalidates if the context is local, which sounds like to be more consistent we have to do it on a Commit command even if it isn't local.

I will try to make up a test case of both an implicit tx and a explicit tx that is started not on an owner node.
                
      was (Author: william.burns):
    So if I understand correctly what you are saying is more that the issue is that the non owner requests a get but only the backup owner answers and the get doesn't reach the primary until after the update occurs causing it to cache an invalid value.

I am thinking this may be due to the fact that the tx l1 code only did invalidates if the context is local, which sounds like to be more consistent we have to do it on a Commit command even if it isn't local.

I will try to make up a test case of both an implicit tx and a explicit tx that is started not on an owner node.
                  
>  Inconsistent L1 in tx distributed cache
> ----------------------------------------
>
>                 Key: ISPN-3648
>                 URL: https://issues.jboss.org/browse/ISPN-3648
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Distributed Cache
>    Affects Versions: 6.0.0.CR1
>            Reporter: Radim Vansa
>            Assignee: William Burns
>            Priority: Critical
>              Labels: jdg62blocker
>
> In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes.
> This issue is very similar to https://issues.jboss.org/browse/ISPN-3617

--
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