5 results found

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

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   10 comments  ·  Transactions  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Lock on session start level with provided keys

   Scenario:
   Parallel DB updates with transactions on multiple collections that use same documents.
   Example: Calculate some common stuff to embed it in extra collections to avoid lookups.

   Problem:
   Lock and timeout on documents uses up valuable time and performance.
   Also lock conflicts produce a huge amount of exceptions that need to be handled.

   Idea:
   Key-based sessions

   Example:
   Session A with Keys 1 and 2 is started.
   Session B tries to start with Key 1. Key 1 is locked with Session A. Session B waits till Session A is finished.

   In this case transaction doesn't start with updating and failing. Waiting for session doesn't use up resources.

   Scenario:
   Parallel DB updates with transactions on multiple collections that use same documents.
   Example: Calculate some common stuff to embed it in extra collections to avoid lookups.

   Problem:
   Lock and timeout on documents uses up valuable time and performance.
   Also lock conflicts produce a huge amount of exceptions that need to be handled.

   Idea:
   Key-based sessions

   Example:
   Session A with Keys 1 and 2 is started.
   Session B tries to start with Key 1. Key 1 is locked with Session A. Session B waits till Session A is finished.

   In this case transaction doesn't start with updating and failing. Waiting… more

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Transactions  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Support for Transaction Savepoints (Nested Transactions)

   The ability to partially rollback transactions to a specified point.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Transactions  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Cascading delete for DBRefs

   Since transactions have been added in 2018, which work across collections (https://www.mongodb.com/docs/manual/core/transactions/) and across shards (https://www.mongodb.com/docs/manual/core/transactions-sharded-clusters/), shouldn't cascading deletes be possible now? I only worked with sql transactions in the past, but my intuition would be that it should be fairly easy to do this in a client:

   1. start a transaction
   2. fetch document
   3. look for dbref fields
   4. fetch those docs
   5. continue at 2 until all docs have been found, stopping at branches when a doc has already been fetched
   6. go back in reverse and delete all of them
   7. commit transaction

   If this is possible to do in a client, it should be possible to do on the server as well, shouldn't it?

   Old and possibly outdated feature request: https://jira.mongodb.org/browse/SERVER-1298?signupSource=Account

   Since transactions have been added in 2018, which work across collections (https://www.mongodb.com/docs/manual/core/transactions/) and across shards (https://www.mongodb.com/docs/manual/core/transactions-sharded-clusters/), shouldn't cascading deletes be possible now? I only worked with sql transactions in the past, but my intuition would be that it should be fairly easy to do this in a client:

   1. start a transaction
   2. fetch document
   3. look for dbref fields
   4. fetch those docs
   5. continue at 2 until all docs have been found, stopping at branches when a doc has already been fetched
   6. go back in reverse and delete all of them
   7. commit transaction

   If this is possible to do… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Transactions  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Lock the document field (not the entire document)

   Hi
   according to this reference: https://www.mongodb.com/blog/post/how-to-select--for-update-inside-mongodb-transactions

   When I lock a document with a field with a new ObjectID, the whole document is locked!

   Idea :

   Operations:
   i have three fields : A , B , C
   I locked field A with new ObjectID in transaction T1.
   i locked field B with new ObjectID in transaction T2.

   Behaviors (high performance) :
   - In transaction T2: if field A is updated, writeConflict error occurs.
   - In transaction T1: if field B is updated, writeConflict error occurs.
   - Outside of transactions: If field A is updated, it waits for T1.
   - Outside of transactions: If field B is updated, it waits for T2.
   - T1 and T2 transaction can be commit at same time. (high performance)

   https://www.mongodb.com/community/forums/t/lock-on-sub-document-in-mongo/140245

   Hi
   according to this reference: https://www.mongodb.com/blog/post/how-to-select--for-update-inside-mongodb-transactions

   When I lock a document with a field with a new ObjectID, the whole document is locked!

   Idea :

   Operations:
   i have three fields : A , B , C
   I locked field A with new ObjectID in transaction T1.
   i locked field B with new ObjectID in transaction T2.

   Behaviors (high performance) :
   - In transaction T2: if field A is updated, writeConflict error occurs.
   - In transaction T1: if field B is updated, writeConflict error occurs.
   - Outside of transactions: If field A is updated, it waits for … more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Transactions  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close