[jboss-user] [JBoss Cache] Document updated/added: "JBossCacheDistributedLockManagerDesign"

User development, The document "JBossCacheDistributedLockManagerDesign", was updated Feb 22, 2010 by Manik Surtani. To view the document, visit: http://community.jboss.org/docs/DOC-10260#cf Document: -------------------------------------------------------------- h2. Distributed Lock Manager   h3. Background   JBossCache locking is not distributed, but consists of a series of local locks.  When locks are obtained on a cache to write some state, the lock is not cluster-wide, but local to the instance.  When a transaction commits, the cache then attempts to lock all remote instances accordingly to apply the changes.   The purpose behind this approach is scalability and performance, since acquiring locks on all instances in a cluster and holding them for the entire duration of a transaction leads to poor concurrency, as well as poor scalability.   On the other hand, using local locks allows for the possibility of concurrent writes, causing transactions to fail at commit time if remote locks cannot be obtained.  Also, these failures are only detected at commit time and not earlier, when the write takes place.   With recent developments such as http://community.jboss.org/docs/DOC-10272 and http://community.jboss.org/docs/DOC-10278, the drawbacks are mitigated since (1) reads are lock-free with MVCC and (2) state is owned on a limited subset of the cluster thanks to partitioning, reducing the impact of distributed locks on scalability.   Another recent refactoring, the creation of a http://fisheye.jboss.org/browse/JBossCache/core/branches/2.2.X/src/main/j... in JBossCache 2.2.0, makes it easy to implement alternate lock managers.   h3. Cooperative Distributed Lock Manager   This approach uses a LockCommand (that implements http://fisheye.jboss.org/browse/JBossCache/core/branches/2.2.X/src/main/j...) and is broadcast to the entire cluster (or just the partition or buddy group).  This is performed by the CooperativeDistributedLockManager synchronously, and waits for all responses.  The LockCommand's perform() method then obtains a local lock.  Once all responses have been received, the CooperativeDistributedLockManager returns from it's lock method.   Similarly, unlock methods on CooperativeDistributedLockManager broadcast an UnlockCommand.   One drawback to this approach is that on rollback, UnlockCommands still need to be broadcast.     --------------------------------------------------------------