[
https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-3266:
-------------------------------------
This is as simple as the following: however this wouldn't be in a test since the write
lock should block the put causing the test to not complete, will attach a real test
{code}
String key = "some-key";
String value = "some-value";
String otherValue = "some-new-value";
final Cache<Object, String> nonOwner = getFirstNonOwner(key);
Cache<Object, String> owner = getFirstOwner(key);
owner.put(key, value);
// Get put in L1
nonOwner.get(key);
assertIsInL1(nonOwner, key);
TransactionManager mgr = TestingUtil.getTransactionManager(nonOwner);
mgr.begin();
try {
nonOwner.getAdvancedCache().withFlags(Flag.FORCE_WRITE_LOCK).get(key);
// Owner now does a write
owner.put(key, otherValue);
} finally {
mgr.commit();
}
assertIsNotInL1(nonOwner, key);
{code}
Pessimistic Force Write Lock doesn't acquire remote lock
--------------------------------------------------------
Key: ISPN-3266
URL:
https://issues.jboss.org/browse/ISPN-3266
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache, Locking and Concurrency
Reporter: William Burns
Assignee: Mircea Markus
Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in
PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a
remote lock on the primary node. Currently this isn't going to block writes at all.
I am guessing this was just an oversight when redoing the locking mechanism.
This causes other issues such as L1 inconsistencies which is how I ran into this and the
locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira