[infinispan-issues] [JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

[Mircea Markus (JIRA)]

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

Mircea Markus commented on ISPN-2990:
-------------------------------------

The problem here is that with async caches there's no ordering between the invalidation message and the any get message:

1. A reads k1. This is an OOB call.
2. B processes the read message and sends back the response
3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
4. A processes(ignores) the invalidation message 
5. A puts the stale value sent at 2 in L1

In order for this to work we need the 2 and 4 messages to be delivered in order to A.
I'm not sure it is possible ATM with jgroups to have a message sent as OOB and a response sent in order (non-OOB). [~belaban] care to comment?



  
                
> L1ManagerImpl doesn't reliably invalidate with async caches
> -----------------------------------------------------------
>
>                 Key: ISPN-2990
>                 URL: https://issues.jboss.org/browse/ISPN-2990
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Distributed Cache
>    Affects Versions: 5.2.1.Final
>            Reporter: Sebastian Tusk
>            Assignee: William Burns
>              Labels: onboard
>
> B is owner of k,v1
> A has k,v1 in L1
> 1. TX: A puts k,v2
> 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit)
> 3. TX: A removes k,v1 from L1
> 4. A putForExternalRead k,v1 and has it in L1 again
> 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin
> Result: A has k,v1 and B has k,v2
> Solution: For async caches send invalidation to origin too.
> The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent.

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