There is a use case of need to make an update in MongoDB and also send a message to RabbitMQ. Both these actions have to be successful or both have to rollback.

@Paul I like to think that most of the pain points have been addressed - at least we have tried very hard :-) I invite you to try it - it's unlike Weblogic or Websphere. And without monoliths, XA is even more relevant today. For instance, BASE is unreliable without the exactly-once processing enabled by XA, so yes even your coffee shop could use it :-) Gregor himself / the coffee shop was talking about a big giant XA transactions across distributed components, which is often not required at all of course.

Having suffered at the hands of XA, using WebLogic with Oracle RAC and MQ Series back in the day, I am not personally a fan of dragging modern applications back into those monolithic dark ages. Nowadays, XA/2PC transactions have increasingly come to be regarded as problematic, perhaps introducing more issues than they solve, such as: * Poor performance due to a ‘pessimistic’ locking approach, plus excessive use of network ‘hand-shaking’ between participants * Operational complexity * Interoperability issues and software bugs due to complexity in implementing the XA specification * Eventual consistency of the final commits fulfilled by each participant system * Reduced high availability, especially where the ‘transaction coordinator’ invariably becomes a potential single point of failure Here's some views which talk to these points: * Section ‘Distributed Transactions and Consensus’ in Chapter 9 of the book Designing Data-Intensive Applications by Martin Kleppmann (O'Reilly, 2016). * "Your Coffee Shop Doesn’t Use Two-Phase Commit" by Gregor Hohpe * "Myth: Why Banks Are BASE Not Acid - Availability Is Revenue" by Eric Brewer * "The Hardest Part About Microservices: Your Data" by Christian Posta * "SHOCKER: XA Distributed Transactions are only Eventually Consistent!" by Paul Done * "It’s Time to Move on from Two Phase Commit" by Daniel Abadi (I can't seem to hyperlink here, but if you google each title/author above you should hit the articles straight away) How can I DOWNVOTE? ;)

@Charles: This is very error prone. Developers should not care about what resources in what sequence communicate with transaction manager. It should just work.

@Charles That does not work if the commit succeeds in Mongo but the ack times out. There would be no way to know if it committed, and rolling back the rest would violate atomicity.

You can actually do this already if the other resource(s) are XA aware. You just have to prepare on the XA resource(s) (no prepare for Mongo), then commit mongo first and, if successful, commit the XA transaction. So the XA transaction wraps the single non-XA resource between the XA prepare and XA commit.

Personnaly i am asking myself if global transaction is really need for MongoDb. It seems it has a replication mechanism to validate CRUD action. But it's a good subject, i will try to collect informations around me.

Sounds like a good idea. I reckon that like most companies we aren't using MongoDB exclusively and it would be a nice option to span transactions across multiple DB engines.

It will be of great benefit to have asynchronous processing with guaranteed consistency. I was looking for it during spring integration asynchronous flow design (PollableChannelbacked by Mongo storage).

The prepare method is missing - which is crucial for proper XA. Mongo can contact https://www.atomikos.com for help with implementing XA. For database vendors, this help is usually free.