[infinispan-issues] [JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state
[
https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin....
]
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