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

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-2990:
------------------------------------

The problem is not just with the ordering of the messages, the order of events on node B could be something like this:

1. Receive {{get(k1)}} command from A. Store the value v1 in the invocation context.
2. Receive {{put(k1, v2)}} command from A. Commit the value in the DataContainer.
3. Send an invalidate(k1) command to A
4. Send the response v1 for the {{get(k1)}} command to A.
5. Send the response v1 for the {{put(k1, v2)}} command to A.

The description of the bug implies that we don't do step 3 at the moment (i.e. we don't send an invalidation command to the originator of the put command). But even if we did, the {{get(k1)}} response is very likely to be processed on A after the {{invalidate(k1)}} command - meaning A will still keep v1 in its DataContainer.

                
> 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