[infinispan-dev] JGroupsDistSync and ISPN-83

[Vladimir Blagojevic]

Hi,

Would you please confirm my understanding and reading of javadoc for 
ReentrantReadWriteLock under section for "lock downgrading". It says: 
"Reentrancy also allows downgrading from the write lock to a read lock, 
by acquiring the write lock, then the read lock and then releasing the 
write lock. However, upgrading from a read lock to the write lock is not 
possible." ReentrantReadWriteLock javadoc code example with class 
CacheData also shows how a thread owning a read lock first has to 
release it in order to obtain a write lock! So a thread owning a read 
lock first has to release a read lock in order to obtain a write lock?

This is very symptomatic in logs of ISPN-83 such as this one 
https://issues.jboss.org/secure/attachment/12341409/server1.log

Recall how FLUSH stops all invocations on cluster and therefore all read 
lock acquisitions in JGroupsDistSync ultimately enabling smooth write 
lock acquisitions for state transfer and what not. In conclusion this 
leads me wondering if the culprit of all this FLUSH mess is rooted in 
read/write lock semantics from above?

Regards,
Vladimir