Strange behavior of transactions - mongodb/cosmosdb dont seem to prevent skewed writes.

Alicja Celigowska [C] 21 Reputation points


Im testing cosmos db if it can be used in place of firestore (for mongodb - version 4.2, just the newest available). I created test db with some test collection. I started testing basic features to check if cosmos db is viable option. I encountered very strange issues when checking transactions.

Before transactions started, I created two resources: A and B
First transaction: Read A and B, updates A
Second transaction: Read A and B, updates B

Both transactions sleep a bit before making update, so they both read initial version of resources. I expected one of them to fail and be repeated. However it did not really happen, both were processed successfully at the first approach. Same code written for firestore is working as expected - one transaction is aborted and repeated.

Im unsure if I did something wrong or not. Tried different consistency levels with, but result is same (Session, Strong, Bounded staleness). Is this expected?

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,535 questions
0 comments No comments
{count} votes

Accepted answer
  1. GeethaThatipatri-MSFT 29,012 Reputation points Microsoft Employee

    @Alicja Celigowska [C] Sorry for the delay in my response
    Here’s a suggested workaround
    Read A, Read B, and update B (but only if neither A nor B has been changed in the meantime).

    If you look at Mongo DB which suffers from the same limitation, they recommend altering item A to basically lock it as part of the transaction: How To SELECT ... FOR UPDATE inside MongoDB Transactions | MongoDB

    And you could do something similar in Cosmos DB. Using a Stored Procedure (where everything is executed inside a single transaction) you could:

    • Update A on some dummy fields which will lock it for writing
    • Read A
    • Read B
    • Update B
    • When the Stored Proc Commits, all those operations will succeed, or all will fail and you’ll have to run it again.

    I think this should work, however, I have not tested it yet.

    Please refer Work with stored procedures, triggers, and UDFs in Azure Cosmos DB | Microsoft Learn and there’s always the option of using a relational database where you have a richer capability around multi-operation transactions.


    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
  1. GeethaThatipatri-MSFT 29,012 Reputation points Microsoft Employee

    Hi, @Alicja Celigowska [C] Welcome to the Microsoft Q&A Platform, and thanks for your query.
    If I understand correctly testing basic features to check if cosmos DB is a viable option with the above example you have provided you are seeing strange behavior and you also want to know if this is expected behavior.
    It sounds like you’re trying to do a multi-document transaction. This is only supported in Cosmos DB for Mongo in an unshared collection: Use multi-document transactions in Azure Cosmos DB for MongoDB | Microsoft Learn
    Is there a reason you’re evaluating Cosmos DB for Mongo rather than Cosmos DB for NoSQL (Core API as it used to be called)? the query language is not identical to Mongo so if you’re migrating anyway you might as well go for the NoSQL API and open the door to more features and potentially better performance.
    If you used the NoSQL (Core) API you could use optimistic concurrency to deal with the example you mentioned: Database transactions and optimistic concurrency control in Azure Cosmos DB | Microsoft Learn

    Please let me know if you are looking for any additional information.


    Please don't forget to click on 130616-image.png or upvote 130671-image.png button whenever the information provided helps you. Original posters help the community find answers faster by identifying the correct answer.