Thanks again for nice explanation Jonathan!
@Pedro - seems like you're doing the right thing by encouraging people to be properly paranoid :-)
Otherwise we'd leak tx logs (in infinispan parlance the PrepareCommands in the recovery cache) which would not be nice.
On 15 May 2013, at 13:32, Jonathan Halliday <jonathan.halliday@redhat.com> wrote:
>
> No, it's out of scope for the TM, at least as far as the JTA/XA specs
> are concerned. The TM would not retain any txlog information to allow it
> to perform useful recovery anyhow. Usually you just log it in the hope
> a human notices and sorts out the mess. Of course properly paranoid
> humans don't use async commit in the first place.
>
> There has been various talk around making JTA TM.commit() support an
> async callback, such that the business logic thread can continue as soon
> as the prepare phase is successful, whilst still receiving a callback
> handler invocation if the commit phase subsequently fails. Extending
> that to the XA protocol would be nice, but won't happen as there is no
> upward (RM->TM) communication in XA - it's all driven top down. So as
> you point out, adding the failed tx to the in-doubt list is the only way
> of signalling a problem. That's bad, since you'd also need a positive
> 'it worked' callback in the proto to allow GC of the txlog, otherwise
> you have to throw away the log eagerly and can't then do anything useful
> with the subsequent error callback anyhow.
>
> Associated with that discussion is the expectation around the semantics
> of afterCompletion, which may mean 'after successful prepare' or 'after
> successful commit' in such case, the latter effectively removing the
> need for a new JTA callback api in the first place.
>
> If you don't need a callback at all, then there is already an async
> commit option in the TM config, it's just non-standard and marginally
> dangerous. It simply logs commit phase failures and hopes a human notices.
>
> Jonathan.
>
> On 05/15/2013 01:13 PM, Mircea Markus wrote:
>> Hi Jonathan,
>>
>> In the scope of ISPN-3063 [1] we came to a problem we need some advice on :-)
>>
>> Would a transaction manager expect/handle this situation: for a transaction the commit is successful but at a further point the same transaction would be reported as "in-doubt" to the recovery process. In our case this can happen when we send the commit async and this might only fail after the commit is acknowledged to the TM.
>>
>> [1] https://issues.jboss.org/browse/ISPN-3063
>>
>> Cheers,
>>
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
> (USA), Charlie Peters (USA)
> _______________________________________________
> 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