[infinispan-dev] commit not failing but transaction reported as in-doubt

[Dan Berindei]

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
Dan


On Wed, May 15, 2013 at 5:06 PM, Mircea Markus <mmarkus at redhat.com> wrote:

> 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 at 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 at 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 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/20130516/001347aa/attachment.html