1 Reply Latest reply: Apr 30, 2012 4:46 AM by Galder Zamarreño RSS

Dirty Read Problem

PISA DR Newbie

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

<namedCache name="MyCache">

      <clustering mode="replication">

                     <async          asyncMarshalling="true"/>

               </clustering>

      <transaction      transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"                              syncRollbackPhase="false"                     syncCommitPhase="false"  useEagerLocking="false"                              eagerLockSingleNode="false" cacheStopTimeout="20000" />

          </namedCache>

 

Code Snippet -

     a)  Tx.begin()

     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.

 

Kindly help.

  • 1. Re: Dirty Read Problem
    Galder Zamarreño Master

    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.