We are using infinispan 5.0 version.
The problem occurs when we receive messages from application server cluster (4 nodes) environment. We do some calculation on values reterieved from cache, and then set the updated value in the cache (for MODE=REPLICATION).
Snippets of infinispan_cache_config.xml -
<locking isolationLevel="REPETABLE_READ" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="5000" useLockStriping="false" />
<transaction transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" syncRollbackPhase="false" syncCommitPhase="false" useEagerLocking="false" eagerLockSingleNode="false" cacheStopTimeout="20000" />
Code Snippet -
b) Lock the key = XX
c) Get value from cache (cache.get(XX))
d) Upodate value from ZZ to ZZZZ for key = XX
e) Call cache.put(XX, New Value()) to replicate the value across cluster
Test Case -
a) Create one entry in cache with key = X and value = Y
b) Update the value where key = X. Updated value = Y+1;
c) For testing purpose, we pring the value reterieved from cache (it prints, key=X, value = Y+1)
If we receive multiple messages to update the same key, somehow the second thread is reading the old value (which is Y). This is not happening consistently.
It happens if we send more than 100 messages to the cluster for the same key.
We tried implicit/explicit eager locking, but it did not solve the problem.
Reads never block in Infinispan, and unless the transaction has committed, the second thread can be reading the old value. Locking the key means the key is locked for writing, i.e. read-for-update style of operation. However, if the 2nd thread updates the value too and it was working of the old Y value, you'll see a write skew exception when transaction commits, if, and only if, writeSkewCheck is enabled, but in your config this is disabled.
|Retrieving data ...|