Bug 1021362 - Inconsistent L1 in tx distributed cache
Summary: Inconsistent L1 in tx distributed cache
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER4
: 6.2.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
: 1024937 (view as bug list)
Depends On:
Blocks: 1017190
TreeView+ depends on / blocked
 
Reported: 2013-10-21 07:27 UTC by Radim Vansa
Modified: 2018-09-12 22:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
With L1 enabled, a node may cache an already overwritten entry. Further reads on this node will return out-of-date value.
Clone Of:
Environment:
Last Closed:
Type: Bug

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-3648 0 Critical Resolved Inconsistent L1 in tx distributed cache 2014-05-23 06:57:22 UTC

Description Radim Vansa 2013-10-21 07:27:06 UTC 
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.
Comment 1 Radim Vansa 2013-10-21 07:28:08 UTC 
This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1017796
Comment 3 JBoss JIRA Server 2013-10-21 21:47:08 UTC 
William Burns <wburns> updated the status of jira ISPN-3648 to Coding In Progress
Comment 4 JBoss JIRA Server 2013-10-21 22:33:59 UTC 
William Burns <wburns> made a comment on jira ISPN-3648

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.
Comment 5 JBoss JIRA Server 2013-10-21 22:43:34 UTC 
William Burns <wburns> made a comment on jira ISPN-3648

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.
Comment 6 JBoss JIRA Server 2013-10-22 00:06:55 UTC 
William Burns <wburns> made a comment on jira ISPN-3648

I can reproduce the issue, however L1 in TX mode has always been invalidated by the owner node, which in this case just won't work.  I will need to think over what I can do for this.  I am guessing we only want to do this invalidation inside the LastChance and leave the normal L1Interceptor alone.
Comment 7 JBoss JIRA Server 2013-10-22 16:53:13 UTC 
William Burns <wburns> made a comment on jira ISPN-3648

Actually this is also an exact match for ISPN-3426
Comment 8 Radim Vansa 2013-12-10 10:12:48 UTC 
*** Bug 1024937 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.