<div dir="ltr">Mircea, I think I'm missing something here. Why would the originator send a TxCompletionNotificationCommand at all if the commit command was asynchronous?<br><br><div class="gmail_extra">I don't think recovery should require the originator to send a TxCompletionNotificationCommand. Our commit commands can't fail anyway, so the only way for a transaction to become in-doubt would be if the cache crashed before sending the command. (Or maybe if another resource's commit phase failed.)<br>
<br></div><div class="gmail_extra">Cheers<br></div><div class="gmail_extra">Dan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 15, 2013 at 5:06 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks again for nice explanation Jonathan!<br>
@Pedro - seems like you're doing the right thing by encouraging people to be properly paranoid :-)<br>
Otherwise we'd leak tx logs (in infinispan parlance the PrepareCommands in the recovery cache) which would not be nice.<br>
<div class="HOEnZb"><div class="h5"><br>
On 15 May 2013, at 13:32, Jonathan Halliday <<a href="mailto:jonathan.halliday@redhat.com">jonathan.halliday@redhat.com</a>> wrote:<br>
<br>
><br>
> No, it's out of scope for the TM, at least as far as the JTA/XA specs<br>
> are concerned. The TM would not retain any txlog information to allow it<br>
> to perform useful recovery anyhow. Usually you just log it in the hope<br>
> a human notices and sorts out the mess. Of course properly paranoid<br>
> humans don't use async commit in the first place.<br>
><br>
> There has been various talk around making JTA TM.commit() support an<br>
> async callback, such that the business logic thread can continue as soon<br>
> as the prepare phase is successful, whilst still receiving a callback<br>
> handler invocation if the commit phase subsequently fails. Extending<br>
> that to the XA protocol would be nice, but won't happen as there is no<br>
> upward (RM->TM) communication in XA - it's all driven top down. So as<br>
> you point out, adding the failed tx to the in-doubt list is the only way<br>
> of signalling a problem. That's bad, since you'd also need a positive<br>
> 'it worked' callback in the proto to allow GC of the txlog, otherwise<br>
> you have to throw away the log eagerly and can't then do anything useful<br>
> with the subsequent error callback anyhow.<br>
><br>
> Associated with that discussion is the expectation around the semantics<br>
> of afterCompletion, which may mean 'after successful prepare' or 'after<br>
> successful commit' in such case, the latter effectively removing the<br>
> need for a new JTA callback api in the first place.<br>
><br>
> If you don't need a callback at all, then there is already an async<br>
> commit option in the TM config, it's just non-standard and marginally<br>
> dangerous. It simply logs commit phase failures and hopes a human notices.<br>
><br>
> Jonathan.<br>
><br>
> On 05/15/2013 01:13 PM, Mircea Markus wrote:<br>
>> Hi Jonathan,<br>
>><br>
>> In the scope of ISPN-3063 [1] we came to a problem we need some advice on :-)<br>
>><br>
>> 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.<br>
>><br>
>> [1] <a href="https://issues.jboss.org/browse/ISPN-3063" target="_blank">https://issues.jboss.org/browse/ISPN-3063</a><br>
>><br>
>> Cheers,<br>
>><br>
><br>
> --<br>
> Registered in England and Wales under Company Registration No. 03798903<br>
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson<br>
> (USA), Charlie Peters (USA)<br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
</div></div><div class="im HOEnZb">Cheers,<br>
--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
<br>
<br>
<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>