[infinispan-dev] rethinking ISPN transactions

Dan Berindei dan.berindei at gmail.com
Fri Nov 22 08:52:06 EST 2013


On Fri, Nov 22, 2013 at 10:26 AM, Radim Vansa <rvansa at redhat.com> wrote:

>  On 11/21/2013 05:09 PM, Dan Berindei wrote:
>
>
>
> On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>>
>>
>> On 11/21/2013 03:18 PM, Dan Berindei wrote:
>> > Hmm, couldn't you just disable recovery in the TM to get the same
>> > performance with a XA resource as with a synchronization?
>>
>>  If you are suggesting to mess around with the TM, I don't think that is
>> a good idea. First, the TM is external to Infinispan and second you can
>> have others XaResources associated to the TM.
>>
>
>  I'm not suggesting that Infinispan should change the TM settings, I'm
> just wondering if there's a difference between using synchronization in
> Infinispan and disabling recovery completely (or using an in-memory
> transaction log) from the user's point of view.
>
>  Actually, that might be irrelevant if using synchronization can lead to
> stale locks in Infinispan. If the commit command fails and doesn't release
> the locks, how will the user be able to find out that there are stale locks
> and release them?
>
>
> Infinispan detects the failed commit and sends a rollback command. Only if
> this fails as well, the locks stay unreleased.
> The problem is just that application thinks it has succeeded while the
> transaction may have been rolled back (in Infinispan way, the JTA
> transaction was already committed).
>
>
Ok, maybe I was overreacting a bit :)

But like you said, the rollback command can fail as well. True, the
rollback doesn't have to write anything to the cache stores, so it's less
likely to fail, but we should still consider the possibility.



> Radim
>
>
>
>
>> >
>> >
>> > On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro at infinispan.org
>>  > <mailto:pedro at infinispan.org>> wrote:
>> >
>> >
>> >
>> >     On 11/21/2013 11:34 AM, Galder Zamarreño wrote:
>> >      >
>> >      >
>> >      > 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.
>> >      >
>> >
>> >     you are right. I forgot the recovery mechanism :)
>> >     _______________________________________________
>> >     infinispan-dev mailing list
>>  >     infinispan-dev at lists.jboss.org <mailto:
>> infinispan-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>  >
>> >
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> --
> Radim Vansa <rvansa at redhat.com> <rvansa at redhat.com>
> JBoss DataGrid QA
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131122/d67f1d87/attachment-0001.html 


More information about the infinispan-dev mailing list