[jboss-jira] [JBoss JIRA] Created: (JBCACHE-1201) OPTIMISTIC locking requires SyncCommitPhase to be true

Brian Stansberry (JIRA) jira-events at lists.jboss.org
Wed Oct 17 14:55:03 EDT 2007


OPTIMISTIC locking requires SyncCommitPhase to be true
------------------------------------------------------

                 Key: JBCACHE-1201
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1201
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Replication
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
             Fix For: 2.1.0.BETA1


When using OPTIMISTIC and REPL_SYNC, I find I need to set SyncCommitPhase=true in order for the following to work:

tm.begin();
cache1.put(fqn, KEY, VALUE1);
tm.commit();
      
assertEquals("Correct node2 value", VALUE1, cache2.get(fqn, KEY));

With SyncCommitPhase=false, cache2.get(fqn, KEY) consistently returns null.

A simple sleep after the commit call will also make this test pass

My understanding of distributed optimistic locking is that at the end of the prepare phase, on all nodes in the cluster the originating node's workspace modifications should have been applied to the main tree, with normal write locks held on the updated nodes.  The commit call then causes the locks to be released, as in pessimistic locking.

The above test result implies this is not the case. That implies more work is going on in the commit phase than is appropriate for a Synchronization.afterCompletion() callback.

Test for this is o.j.c.optimistic.FullStackInterceptorTest.testAsynchronousCommit()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list