0 Replies Latest reply on Jun 13, 2015 4:51 PM by Jason Separovic

    is "lock then rollback" supported?

    Jason Separovic Newbie

      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