[
https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-3266:
-------------------------------------
I am not for sure but it looks like all that is required here is:
{code}
diff --git a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticL
index ba9714a..39ff611 100644
--- a/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
+++ b/core/src/main/java/org/infinispan/interceptors/locking/PessimisticLockingI
@@ -63,6 +63,9 @@ public final Object visitGetKeyValueCommand(InvocationContext
try {
if (command.hasFlag(Flag.FORCE_WRITE_LOCK)) {
boolean skipLocking = hasSkipLocking(command);
+ if (!skipLocking) {
+ acquireRemoteIfNeeded(ctx, command, cdl.localNodeIsPrimaryOwner(
+ }
long lockTimeout = getLockAcquisitionTimeout(command, skipLocking);
lockKeyAndCheckOwnership(ctx, command.getKey(), lockTimeout, skipLo
}
{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
Affects Versions: 5.3.0.Final
Reporter: William Burns
Assignee: Pedro Ruivo
Fix For: 6.0.0.CR1
Attachments: DistSyncL1PessimisticFuncTest.java
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