<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 7 Jan 2012, at 18:57, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div 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>&nbsp; testModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)</div><div>&nbsp; testNoModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)</div></div><div><br></div><div>They both attempt to abort a transaction by throwing an exception during prepare. &nbsp;Now since we use Synchronizations by default, these failures do *not* abort the transaction since it is only seen by the SynchronizationAdapter in afterCommit(). &nbsp;Where does this stand, conceptually? &nbsp;With optimistic transactions, locks may not be able to be acquired at prepare-time. &nbsp;These transactions should fail.</div></div></blockquote>With pessimistic transactions, the first phase of 2PC is skipped: that is because locks are acquired and modifications propagated at this stage. So beforeCompletion doesn't do anything.&nbsp;</div><div>However in the case of optimistic transactions the prepare happens during beforeCompletion and it would fail causing the tx to roll back.<br></div><br></body></html>