Bug 1032545 - L1 requestor registered after value read
Summary: L1 requestor registered after value read
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: CR1
: 6.2.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-20 11:36 UTC by Radim Vansa
Modified: 2014-01-08 07:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat One Jira Issue Tracker ISPN-3737 Critical Resolved L1 requestor registered after value read 2014-01-08 07:51:05 UTC

Description Radim Vansa 2013-11-20 11:36:32 UTC
As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent.
Consider this interleaving of operations (G=get request from other node, C=commit)

R: read value -> old value
C: update old -> new
C: notify requestors for key
R: add requestor for key

Comment 2 JBoss JIRA Server 2013-11-27 16:04:15 UTC
William Burns <wburns@redhat.com> updated the status of jira ISPN-3737 to Coding In Progress

Comment 3 JBoss JIRA Server 2013-11-27 16:05:45 UTC
William Burns <wburns@redhat.com> made a comment on jira ISPN-3737

Good catch!  Normally just putting the registration of the requestor before the get completes would have an inverse effect (we could invalidate something that isn't present), but because of the L1 rewrite to not store L1 values if a concurrent invalidation occurs while waiting on a remote get, that should be a more than feasible fix.

Comment 4 JBoss JIRA Server 2013-11-27 19:41:18 UTC
William Burns <wburns@redhat.com> made a comment on jira ISPN-3737

Also this only affects RepeatableRead since Read Committed would return the correct value and thus would have cached the proper value.  I will have to add in some Repeatable Read unit tests.

Comment 5 JBoss JIRA Server 2013-12-02 09:03:36 UTC
Radim Vansa <rvansa@redhat.com> made a comment on jira ISPN-3737

I have experienced that with RC. But you can check out as soon as you get the unit test reproducing this with RR.


Note You need to log in before you can comment on or make changes to this bug.