[infinispan-dev] rethinking ISPN transactions
Dan Berindei
dan.berindei at gmail.com
Tue Nov 19 11:14:02 EST 2013
Sorry, I was confusing things - the timeout I was thinking of happened in
the transaction manager itself, and it didn't matter whether we were
registering a synchronization or a full XA resource.
Replication timeout sounds like something that could be easily removed for
commit command RPCs, but there may be plenty of other things that could
fail without the caller knowing. So the question remains, should give up on
synchronizations (except maybe with asynchronous commit/1PC, if we decide
to keep that)?
On Tue, Nov 19, 2013 at 6:01 PM, Dan Berindei <dan.berindei at gmail.com>wrote:
> Maybe synchronization support is another thing that we should scrap in
> 7.0, then?
>
> 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.
>
>
> On Tue, Nov 19, 2013 at 4:40 PM, Erik Salter <an1310 at hotmail.com> wrote:
>
>>
>> -> this is quite a subtle aspect of JTA transactions (is
>> Synchronisation.afterCompletion failures are not propagated to the user) -
>> you have a very good point here, thanks!
>>
>> This right here has burned me very badly. I think this really needs to be
>> called out, especially if we're using this mode rather than full-blown XA.
>>
>> Erik
>>
>> _______________________________________________
>> 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/20131119/c1c13db0/attachment.html
More information about the infinispan-dev
mailing list