Lock Client-Side TCP-Extends

Question

Hi,
I am running 2 processes on the same server both connecting to one cluster node.
I need to ensure only one process performs a write operation @ a certain time (i.e. the first one to attain the lock).
I am finding that both the processes are getting the lock, and cannot work-out why...
We are using tcp-extends, and I am using the following related cluster configuration:
<caching-scheme-mapping>
<cache-mapping>
<cache-name>cache.cluster.*</cache-name>
<scheme-name>scheme.cluster.system</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<proxy-scheme>
<scheme-name>scheme.cluster.proxy</scheme-name>
<service-name>service.cluster.proxy</service-name>
<thread-count>4</thread-count>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address system-property="datacloud.node.tcp-extend.bind-address">localhost</address>
<port system-property="datacloud.node.tcp-extend.port">11200</port>
</local-address>
<keep-alive-enabled>true</keep-alive-enabled>
</tcp-acceptor>
</acceptor-config>
<proxy-config>
<cache-service-proxy>
<lock-enabled>true</lock-enabled>
<!--read-only>true</read-only -->
</cache-service-proxy>
</proxy-config>
<autostart>true</autostart>
</proxy-scheme>
<replicated-scheme>
<scheme-name>scheme.cluster.system</scheme-name>
<service-name>ReplicatedCache</service-name>
<lease-granularity>member</lease-granularity>
<member-listener>
<class-name>datacloud.cluster.listeners.ClusterMemberListener</class-name>
</member-listener>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
</replicated-scheme>
</caching-schemes>
The client copies this scheme by using the following:
          <cache-mapping>
               <cache-name>cache.cluster.lock</cache-name>
               <scheme-name>scheme.remote</scheme-name>
          </cache-mapping>
The lock essentially does:
NamedCache cache = CacheFactory.getCache("cache.cluster.lock")
boolean isLockAcquired = cache.lock("KEY", 5000)
try {
if(isLockAcquired) {
(takes 2 seconds to complete)
} finally {
cache.unlock("KEY")
Why can 2 processes acquire the same lock when asked to acquire it @ the same time?
Edited by: 907011 on 10-Jan-2012 03:33

Answer 1

Hi,
This is my explination of why you are seeing the behaviour you are - I think it is correct but I am sure someone will jump in if not.
1. Your cache config has <lease-granularity>member</lease-granularity> which means that a lock taken out by any thread on a member can be released by the same member. It also means that a Member owns the lock so if I do cache.lock() for a key from some code running on a Member and then do cache.lock() again for the same key on the same Member they will both succeed as the Member owns the lock.
2. Now, when your first process calls <tt>boolean isLockAcquired = cache.lock("KEY", 5000)</tt> it gets the lock but it is not your client process that owns the lock, it is the Extend Proxy your client is connected to that owns it.
3. Consequently when process two, connected to the same Extend proxy, asks for the lock, it gets it too, as it is not your client process that owns the lock, it is the Extend Proxy your client is connected to that owns it.
4. Worse, when process one finishes and releases the lock, then it is released, even though your code in process two still thinks it is running inside the lock.
As I said, that is my understanding of it and why locks do not really work from Extend Clients. In fact there are very few occasions where I would bother to use explicit locks in Coherence (hence my unfamiliarity about the exact workings) as there are usually other, more reliable, ways to achieve the same requirements.
JK