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

[Dan Berindei]

Yeah, I got a bit confused because you didn't say anything about nodes
crashing or how the question actually related to Infinispan. So I assumed
it had something to do with https://issues.jboss.org/browse/ISPN-3063 :)


On Thu, May 16, 2013 at 6:50 PM, Mircea Markus <mmarkus at redhat.com> wrote:

> 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 at gmail.com> 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 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/5f680beb/attachment.html