Hi,

I have a 3 node replicated clustered cache functioning as a high frequency "lock then process" type application. Each iteration tries to lock a record in the cache, if successful it does stuff, then writes back (sometimes). If lock fails, it moves on to the next record.

I'm using the following config:

return new ConfigurationBuilder()

  .locking()

  .concurrencyLevel(3)

  .lockAcquisitionTimeout(3000L)

  .isolationLevel(IsolationLevel.REPEATABLE_READ)

  .useLockStriping(false)

  .clustering()

  .cacheMode(CacheMode.REPL_SYNC)

  .transaction()

  .transactionManagerLookup(new JBossTransactionManagerLookup())

  .lockingMode(LockingMode.PESSIMISTIC)

  .transactionMode(TransactionMode.TRANSACTIONAL)

  .useSynchronization(true)

  .autoCommit(false)

  .syncCommitPhase(true)

  .syncRollbackPhase(true)

  .build();

version:           jboss-as-clustering-infinispan-7.2.0.Final.jar

lock flags:       Flag.FAIL_SILENTLY,Flag.FORCE_SYNCHRONOUS

I'm wondering if the following workflow should be supported:

txBegin()

if(txLock(key))

get(key)

// process and decide not to put(key)

txRollback()

else

txRollback()

I'm finding that if the lock is successful and then a rollback is called, the locks get into an inconsistent state across the cluster and then no one can lock that particular record (not even the guy with the lock)

node1:     AbstractPerEntryLockContainer{locks={}}

node2:     AbstractPerEntryLockContainer{locks={5a594cd4-405c-4c50-9086-5deb0bda6571=org.infinispan.util.concurrent.locks.OwnableRefCountingReentrantLock@149cb662[State = 1, empty queue][Locked by GlobalTransaction:<node3/mycache>:43:remote][References: 1]}}

node3:     AbstractPerEntryLockContainer{locks={}}

*at this point all nodes fail on a lock attempt to 5a594cd4-405c-4c50-9086-5deb0bda6571

If I change the workflow slightly to commit the transaction regardless of what happens in the processing phase the problem goes away:

i.e:

txBegin()

if(txLock(key))

get(key)

// process and decide not to put(key)

txCommit()

else

txRollback()

Is this expected behavior? If my processing fails, and I do not update the record, is it better to rollback the transaction, or commit the transaction without changing the record?

Cheers,

Jason Separovic