6 Replies Latest reply on Feb 18, 2010 10:49 AM by vblagojevic

    Locking in the distributed cache

      The distributed cache cannot be locked by AdvancedCache.lock method unless it was updated in a same thread in a same server. Because InvocationContext (affectedKeys) is managed in ThreadContext, DistributionInterceptor does not distribute LockControlCommand.
      How can I distribute a lock for cache updated from other server or other thread?
        • 1. Re: Locking in the distributed cache
          vblagojevic

          Hi,

           

          I am not sure what are you trying to achieve? Rationale behind eager locking is explained on wiki pages along with pseudo code examples http://community.jboss.org/wiki/InfinispanTechnicalFAQs#Does_Infinispan_support_distributed_eager_locking

           

           

          Regards,

          Vladimir

          • 2. Re: Locking in the distributed cache
            I am trying to lock a cached object between some servers in the same way as the FAQ ("explicit eager locking"). In this way, a lock (LockControlCommand) is not sent to remote servers unless a locked object is updated in same thread in local server.
            • 3. Re: Locking in the distributed cache
              vblagojevic

              If you invoke locking explicitly ("explicit eager locking") using cache#lock(keys) the invocation is propagated to other Infinispan nodes if and only if InvocationContext#isOriginLocal returns true. Otherwise we would ping-pong locking invocation endlessly between the nodes. Is that what you are referring to?

              • 4. Re: Locking in the distributed cache
                I wonder why the locking behavior is different depending on whether a cache object has been updated or not. And I wonder why affected nodes (1st parameter at RpcManager#invokeRemotely) are acquired from ThreadContext.

                For example, a deadlock occurs in the following sequence. And if communications are asynchronous, a deadlock does not occurs, a cached object will not match between servers.

                Server A:
                  tx.begin();
                  cache.lock(K);  // K is locked in the Server A but a lock is not distributed to Server B.
                  tx.put(K, V1);
                  tx.commit();

                Server B:
                  tx.begin();
                  cache.lock(K);  // K is locked in the Server B but a lock is not distributed to Server A.

                Server A:
                  tx.begin();
                  cache.lock(K);  // A lock is distributed to Server B, and waits for the lock to be released from Server B.

                Server B:
                  tx.put(K, V2);
                  tx.commit();  // A put message is distributed to Server A, and becomes deadlock.
                • 5. Re: Locking in the distributed cache
                  mircea.markus
                  I'm not sure I can follow the parallel execution described. I see that explicit locking is used, this means that if Server A acquires a lock on K then server B won't be able to acquire lock A release it. So even if at a further point A (which still holds the lock) operates on that key, it will succeed.
                  • 6. Re: Locking in the distributed cache
                    vblagojevic

                    Takuro,

                     

                    I am sorry but I do not understand what you are saying. Can you demonstrate what you perceive to be the problem using a test case? You can use SyncReplLockingTest [1] as a starting point for some ideas. You would have to check out Infinispan source tree and add your test demonstrating this issue.

                     

                    Best regards,

                    Vladimir

                     

                    [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/replication/SyncReplLockingTest.java