[
https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin....
]
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