Locking in the distributed cache

[zwq]

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?

[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

[zwq]

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.

[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?

[zwq]

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.

[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.

[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