Skip to content

How can we improve the MongoDB Database?

← Database

XA Support

Is there any plan to implement distributed transaction that involves more than one data stores (for e.g. an RDBMS and Mongo)? We have one such requirement and tried a simple POC by creating a simple class extending XAResource (MongoXAResource implements XAResource) and overriding below methods.

@Override
public void commit(Xid xid, boolean b) throws XAException {
clientSession.commitTransaction();
}

@Override
public void rollback(Xid xid) throws XAException {
clientSession.abortTransaction();
}

It appears to work but i think there is a lot more to do. Is there any plan to implement by MongoDB team?

49 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Aravindan shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Albert commented  ·   ·  Report

    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.

  • Guy commented  ·   ·  Report

    @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.

  • Paul commented  ·   ·  Report

    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? ;)

  • Alexander commented  ·   ·  Report

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

  • Guy commented  ·   ·  Report

    @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.

  • Charlie commented  ·   ·  Report

    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.

  • Alain Thuret commented  ·   ·  Report

    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.

  • Klaus commented  ·   ·  Report

    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.

  • Sabyasachi commented  ·   ·  Report

    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).

  • Guy commented  ·   ·  Report

    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.

Database: Transactions

Categories

Feedback and Knowledge Base

(thinking…)