On 11/19/2013 08:48 PM, Mircea Markus wrote: > > On Nov 19, 2013, at 4:49 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > >> Is there any reason to use synchronization other than "it's faster"? > > I guess the reason for using synchronization is to invalidate (or updated) an > cache. We obviously don't do that ATM, so indeed wondering if there's any > point at all... > Pedro any idea?
I tried to understand the contract used by Synchronization resources but I didn't find anything concrete. This is what I understood: Synchronization is used as notification for the transaction. The SyncResources are notified that the transaction is going to try to commit. In here, the SyncResources can abort the transaction by invoking transaction.setRollbackOnly() (or similar method). After the first notification, the XaResources tries to commit the transaction and then the SyncResources are notified again with the transaction outcome. In this step, you no longer have the control over the transaction and it is committed/rollbacked. So any fail during the after() will be ignored. Said that, I don't see how synchronization "is faster" than the Xa. The only use case I see for Synchronization (in Infinispan context) is to cache some computational expensive results. In this case, you may want your system to control the logic (and the transaction, then you enlist it as Xa) but Infinispan is only enlist as Synchronization. If the after() fails, it does not affect the application logic because the transaction is committed and probably, the application may be able to re-calculate it. (probably I'm wrong...) > >> >> IMO, the reasoning for removing synchronizations is the same as item 1 in >> your proposal, "Async options for commit/rollback". since you are talking about async commit/rollback, I think it can be useful for Synch enlistment. After all, it makes no sense to wait commit/rollback acks since any exception is ignored... wdyt? >> >> >> On Tue, Nov 19, 2013 at 6:35 PM, Mircea Markus <mmar...@redhat.com> wrote: >> >> On Nov 19, 2013, at 4:01 PM, Dan Berindei <dan.berin...@gmail.com> wrote: >> >>> Maybe synchronization support is another thing that we should scrap in 7.0, >>> then? >> >> I'd still allow them (sync enlistment is there for a resaon), but have >> XA+recovery enabled by default and the batching commit should fail if the tx >> hasn't completed successfully. >> >>> >>> BTW, I've also seen the transaction timeout that Radim mentioned, but only >>> recently. I wonder if we could do anything to increase it for the stress >>> tests. >>> >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > Cheers, > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev