]
Manik Surtani updated JBCACHE-1201:
-----------------------------------
JBoss Forum Reference:
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
Affects Versions: 2.1.0.BETA1
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.1.0.CR1
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: