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,

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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev 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

I think we're discussing about two different things here. My question was a general one: what if an XAResouce ack the commit to the TransactionManager and then the Recovery Process (TM-side process independent of Infinispan) determines that the given transaction is in doubt. As per Jonathan's email the TM doesn't handle this well. In our case with async commit the scenario above is possible when the node crashes after ack the commit to the TM and before broadcasting the CommitCommand. So we simply shouldn't support async commit when the users want recovery. HTH On 16 May 2013, at 10:32, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > Mircea, I think I'm missing something here. Why would the originator send a TxCompletionNotificationCommand at all if the commit command was asynchronous? > > 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.) 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