Two questions about transactions / data consistency levels in MongoDB

Hello.

I have two questions related to transactions in MongoDB.

Before version 4.0 (where transactions with ACID guarantees were inserted in multiple documents) how did MongoDB work with the transactions part? Or how did MongoDB manage the consistency of operations? Before version 4.0 did MongoDB already provide this guarantee of ACID properties?

Were there any transactions implicit in the CRUD operations before version 4.0?

I ask this because I noticed that since version 3.2 it was already possible to use some parameters to adjust the consistency level of operations using write concern, read concern, journal and read preference.

Hello @morcelicaio ,

According to this documentation of MongoDB server version 4.0.

New in version 4.0.

In MongoDB, an operation on a single document is atomic. Because you can use embedded documents and arrays to capture relationships between data in a single document structure instead of normalizing across multiple documents and collections, this single-document atomicity obviates the need for multi-document transactions for many practical use cases.

However, for situations that require atomicity for updates to multiple documents or consistency between reads to multiple documents:

Starting in version 4.0 , MongoDB provides the ability to perform multi-document transactions against replica sets.

In terms of atomicity, yes MongoDB provided atomic operations even before 4.0. However this is only for single documents. In contrast, MongoDB 4.0 allows multi-document transactions. To learn more about how MongoDB was providing atomicity before v4.0, please go through MongoDB ACID Transactions general availability blog.

This was used mostly for durability and not consistency, for reference MongoDB v3.2 write Acknowledgement documentation.

Avoid using a "majority" write concern with a (P-S-A) or other topologies that require all data-bearing voting members to be available to acknowledge the writes. Customers who want the durability guarantees of using a "majority" write concern should instead deploy a topology that does not require all data bearing voting members to be available (e.g. P-S-S).

Regards,
Tarun

2 Likes

Hello @Tarun_Gaur ,

Those atomic operations you comment before version 4.0. Did they already provide ACID guarantees?

When you say read consistency for multiple documents. In this case you say readings of several documents in different collections or in the same collection?

Yes, for single document.

Yes, because the transaction is against the session so you can ready multiple documents from different collections, below is a blob from Transactions Manual v6.0

For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports multi-document transactions. With distributed transactions, transactions can be used across multiple operations, collections, databases, documents, and shards.

Please note that MongoDB v3.0 and v4.0 are out of support so if you are still using them I would recommend you to upgrade to at-least MongoDB v4.2.

Thanks for the instructions @Tarun_Gaur .

Other questions are as follows:

Does “snapshot” read concern only work when it’s set within a transaction? Or outside of transactions is it also possible to use this read concern?

About defining causal consistency. Is it possible to define causal consistency for the operation only within a session? Or outside the session if I set write concern “majority” and read concern “majority” am I already implicitly defining the operation as causally consistent?

Outside of transactions the default write concern is “w:1” ?
Outside transactions the default read concern is readConcernLevel: “local” ?

Regards,
Caio

I would recommend you to go through below links as these can explain about Transactions in great detail and better than I can in short posts.