1 Reply Latest reply on Jun 7, 2010 8:28 AM by Mircea Markus

    Questions about locks, transaction and asynchronous API

    Chun Li Newbie

      I have read through the user guide and transaction, locks, and asynchronous API, and I have some  questions about these topics.

       

      Actually all my questions are to ensure we correctly handle a transaction that versioning is really critical, and get much concurrency as possible. It can be simplified as following code.

       

      tx.begin();    //(a)

      cache.getAdvancedCache().lock(k); //(b)

      Integer v=cache.get(k); //(c)

      cache.putAsync(k, v + increasement); //(d)

      tx.commit();  //(e)

       

       

      So here are my questions.

       

      1)  Regarding the API of AdvancedCache, we can load an object from cache through:

           cache.getAdvancedCache.withFlags(Flag.FORCE_WRITE_LOCK).get(key);

       

            what's the difference is this from

       

           cache.getAdvancedCache().lock(key);

           cache.get(key) ?

       

           Is the lock obtained by .withFlags(Flag.FORCE_WRITE_LOCK) also a cluster wide lock?

       

      2) If using asynchronous api, what happens during a transaction prepare phase and commit phase? For example

       

           tx.begin()
           cache.putAsync(K,V5) 
           tx.commit()

       

          If eagerlocking is set to false, concluded from document about asynchronous API, I think a cluster wide lock will be acquired during the prepare phase. Will the replication complete before transaction comitted or after that?  It seems to be before transaction committed since the lock will be released after transaction committed, and we need this lock during replication. However, if the replication must be completed before transaction is committed, can we still get the benifit with asynchronous API?

       

       

      3) During the prepare phase, if other transaction is processing commiting and has a lock on the same key in other node, will the XAResource wait for the lock to be granted util timeout? or will it fails the transaction immediately?

       

      4) For my example, replace and put operation both works, which one is recommended for better performance.

       

      Thanks in advance for your response.

        • 1. Re: Questions about locks, transaction and asynchronous API
          Mircea Markus Master

          1.  cache.getAdvancedCache().lock(k) is an rager lock. This means that after the method returns the given key is locked across the cluster: the key might not reside on this node (depending on its hash code), so this method will do a RPC and make sure that no other tx is able to write it before this tx finishes (commit/rollback).

          On the other hand,  .withFlags(Flag.FORCE_WRITE_LOCK) forces the acquisition of an write lock even if the operation you are performing is a read. The lock is not being acquired eagerly, meaning that if the key is not on this node, the actual WL is acquired on the key's owner at commit time.

          2. This is an interesting question. I've just added a UT to check it (AsyncWithTxTest on 4.1 branch) and the  cache.putAsync(K,V5) does not run under TX scope. I think this behavior is correct but it should be clearly specified (if it is not already) - other opinions?

          If eagerlocking is set to false, concluded from document about asynchronous API, I think a cluster wide lock will be acquired during the prepare phase. Will the replication complete before transaction comitted or after that?

          yes, cluster wide locks is acquired at prepare phase. The replication is performed before transaction commited: locks being acquired at prepare phase and being commited at commit phase (2PC).

           

          3.

           

          During the prepare phase, if other transaction is processing commiting and has a lock on the same key in other node, will the XAResource wait for the lock to be granted util timeout? or will it fails the transaction immediately?

          it will wait for "lockAcquisitionTimeout" millis (this can be 0).

           

           

          4) For my example, replace and put operation both works, which one is recommended for better performance.

          They have different semantics, so not sure what you mean.

          1 of 1 people found this helpful