[infinispan-issues] [JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784183#comment-12784183 ] 

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