[infinispan-issues] [JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state

[William Burns (JIRA)]

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

William Burns commented on ISPN-2965:
-------------------------------------

Actually getting a minute to think about your second case - is there a reason the ClusteredGetCommand value returned is kept in the tx context and not just directly written to the data container?  We aren't updating the value with this and it would be fully consistent.  If the tx updates the key after it will be contained in the tx context and eventually overwrite the L1 cached value and if it is rolled back then we still have a consistent L1 cache.
                
> L1 and early invalidation leaves inconsistent state
> ---------------------------------------------------
>
>                 Key: ISPN-2965
>                 URL: https://issues.jboss.org/browse/ISPN-2965
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Distributed Cache, Transactions
>    Affects Versions: 5.2.1.Final
>            Reporter: Sebastian Tusk
>            Assignee: William Burns
>              Labels: 5.2.x
>             Fix For: 5.3.0.Final
>
>
> In a distributed transactional cache with L1 enabled I can observe the following.
> Prepare cache by adding an entry with Cache.put( k, v1 ).
> 1. Node B starts with adding a changed value. Cache.put( k, v2 )
> 2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations.
> 3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1.
> 4. Node B proceeds with transaction.
> The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2.
> It seems the invalidation is either send to early or must be synchronized in some way with the transaction.
> Cache config:
>     <namedCache name="entity">
>         <jmxStatistics enabled="true" />
>         <clustering mode="dist">
>             <stateTransfer fetchInMemoryState="false" timeout="20000" />
>             <async />
>             <l1 enabled="true" />
>             <hash numOwners="1"/>
>         </clustering>
>         <locking isolationLevel="READ_COMMITTED"
>             lockAcquisitionTimeout="15000" useLockStriping="false" />
>         <eviction maxEntries="10000" strategy="LRU" />
>         <expiration maxIdle="100000" wakeUpInterval="5000"/>
>         <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
>         <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
>     </namedCache>

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