[
https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-2965:
--------------------------------
Fix Version/s: (was: 5.3.0.CR1)
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: Adrian Nistor
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