<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">After spending some hours on ISPN-1284, I think we have a few conceptual problems with using Synchronizations.<div><br></div><div>Here is the topic branch containing my work:</div><div><br></div><div><a href="https://github.com/maniksurtani/infinispan/tree/t_1284">https://github.com/maniksurtani/infinispan/tree/t_1284</a></div><div><br></div><div>So far what I have done is:</div><div><br></div><div>* Changed defaults</div><div>* Changed config validations to emit a warning and disable synchronisations if recovery is enabled</div><div>* Update some tests that rely on XA to specifically set synchronisations to false</div><div><br></div><div>But there are still some issues, and what specifically worry me is behaviour demonstrated by these two test failures:</div><div><br></div><div><div> testModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)</div><div> testNoModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)</div></div><div><br></div><div>They both attempt to abort a transaction by throwing an exception during prepare. Now since we use Synchronizations by default, these failures do *not* abort the transaction since it is only seen by the SynchronizationAdapter in afterCommit(). Where does this stand, conceptually? With optimistic transactions, locks may not be able to be acquired at prepare-time. These transactions should fail.</div><div><br></div><div>Cheers</div><div>Manik</div><div><div apple-content-edited="true">
<div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>