On Nov 20, 2013, at 11:15 AM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
On 11/19/2013 08:48 PM, Mircea Markus wrote:
>
> On Nov 19, 2013, at 4:49 PM, Dan Berindei <dan.berindei(a)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.
It's way faster actually. The speed difference from all the extra work required by
Transaction Manager to deal with multiple XA resources, make transactions
recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and
the difference was quite big.
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 <mmarkus(a)redhat.com> wrote:
>>
>> On Nov 19, 2013, at 4:01 PM, Dan Berindei <dan.berindei(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org