Re: [dna-dev] Non-XA compliant resource participation in distributed transactions

I'd agree - I wasn't suggesting to replace compensating transactions, just to offer this as an additional option for those that must, for whatever reason, use XA transactions. I should also clarify the type of non-XA resource I'm referring to must still at least be transactional for the "XA-compliant" tag to still apply. Randall Hauch wrote: > I agree that what you are suggesting is still transactional (except > for the last source, which is not transactional). But we will > likely need to supporting several non-XA sources (e.g., file > systems, applications, etc.) within an XA system. And, if we know > the individual changes to each node for each source, we shouldn't > we also be able to use compensating transactions to "rollback" > changes to the non-XA system? > > I think there's value to supporting both. I just think the odds of > having more than one non-XA source is pretty high. > > On May 14, 2008, at 4:22 PM, John P. A. Verhaeg wrote: > >> The big difference here seems to be the exposure of the updates >> before the distributed transaction is committed. What I'm >> suggesting is still XA-compliant, while compensating transactions >> are not. >> >> Randall Hauch wrote: >>> This is the behavior allowed by JBoss Transactions (Arjuna), and >>> it seems useful. However, I wonder if we can do compensating >>> transactions, is there still an advantage to supporting n-1 XA >>> plus 1 non-XA? >>> >>> Cheers, >>> >>> Randall >>> >>> On May 14, 2008, at 4:10 PM, John P. A. Verhaeg wrote: >>> >>>> Seems like we ought to strive to support n-1 XA resources for >>>> distributed transactions, allowing for the last participant in a >>>> transaction (thus, this participants updates can't be done in >>>> parallel with the other resources) to not support XA >>>> transactions, but still participate in a distributed transaction >>>> with other XA-compliant resources. Unlike compensating >>>> transactions, the non-XA participant would appear transactional >>>> and none of the updates would be visible until the entire >>>> transaction was complete. It seems like this could open up many >>>> more possible configurations for customers. >>>> _______________________________________________ >>>> dna-dev mailing list >>>> dna-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/dna-dev >>> >>> >> _______________________________________________ >> dna-dev mailing list >> dna-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/dna-dev > > _______________________________________________ dna-dev mailing list dna-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/dna-dev