On 9 Jan 2012, at 11:43, Mircea Markus wrote: > > On 9 Jan 2012, at 13:36, Manik Surtani wrote: > >> >> On 9 Jan 2012, at 10:50, Mircea Markus wrote: >> >>> >>> On 7 Jan 2012, at 18:57, Manik Surtani wrote: >>> >>>> After spending some hours on ISPN-1284, I think we have a few conceptual >>>> problems with using Synchronizations. >>>> >>>> Here is the topic branch containing my work: >>>> >>>> https://github.com/maniksurtani/infinispan/tree/t_1284 >>>> >>>> So far what I have done is: >>>> >>>> * Changed defaults >>>> * Changed config validations to emit a warning and disable >>>> synchronisations if recovery is enabled >>>> * Update some tests that rely on XA to specifically set synchronisations >>>> to false >>>> >>>> But there are still some issues, and what specifically worry me is >>>> behaviour demonstrated by these two test failures: >>>> >>>> testModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest) >>>> testNoModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest) >>>> >>>> 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. >>> 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. >>> However in the case of optimistic transactions the prepare happens during >>> beforeCompletion and it would fail causing the tx to roll back. >> >> So Synchronizations and pessimistic locking are incompatible? :) > Well this is very similar to what happens in the case of optimistic locking > when the CommitCommand cannot be broadcasted: the transaction silently fails.
Then the tests need to be re-written in this case, if we make synchronisations a default? :) -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
