]
Manik Surtani resolved JBCACHE-1201.
------------------------------------
Fix Version/s: (was: 2.2.0.GA)
Resolution: Won't Fix
Unless there is a critical reason as to why OL cannot be used with sync commits, I'm
not fixing this - time better spent on MVCC.
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
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: