This is in relation to JBCACHE-1201.
So this is in no way an easy fix. The main problem here is that when a cache enters it's prepare phase, modifications are broadcast, but the remote cache hasn't really entered the prepare phase so locks aren't acquired when you use OL. When the originating cache enters it's commit phase, then commit() is called on the remote cache's tx - which then causes it to enter it's prepare phase - and acquire locks - and then commit.
The only real solution I can think of, given the way we replicate at transaction boundary, is to actually use the PLI on remote caches, so that even when the originating cache enters it's prepare phase, remote caches obtain locks. But this opens up all sorts of other problems. Maybe the OptimisticLockInterceptor should obtain WLs for all method calls if the call's origin is remote, i.e., part of a remote prepare. Still, potentially a hairy situation - I'd rather defer for now given that there is a workaround (to set SyncCommitPhase and SyncRollbackPhase to true). Potentially even not fix this, given that this will change pretty drastically with MVCC.
Well, for sure it sounds like too much to fix in 2.1.0. I suppose whether it's worth fixing at all depends on when the MVCC stuff will be ready. Sounds like a discussion point for the December meeting.
I'll be sure the Hibernate configs use SyncCommitPhase=true.