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

Question

Hello

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.

Scenario:
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 https://portal.azure.com/, but result is same (Session, Strong, Bounded staleness). Is this expected?

Answer 1

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

Regards
Geetha

Answer 2

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.

Regards
Geetha

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