Does mongodb read uncommitted by default?

[j-xzy_N_A]

From the docs:

Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.

Read uncommitted is the default isolation level and applies to mongod standalone instances as well as to replica sets and sharded clusters.

Do these two descriptions conflict?

[kevinadi (Kevin Adistambha)]

Hi @j-xzy_N_A welcome to the community!

I agree this is a bit confusing. I’ll try to explain.

In regular RDBMS terms, “read uncommitted” basically means the query can return inconsistent data from a not-yet-committed transaction. This is typically bad for most use cases.

However in this instance, “uncommitted” here is in terms of a distributed system. In MongoDB in particular, it basically means that the query can return data that can be rolled back in the context of a replica set (read concern local). I guess the corresponding term for “read committed” in MongoDB would be read concern majority, where it will not return data that can be rolled back by the replica set.

Here the term “transaction” refers to multi-document transaction, similar to the concept of transaction in typical RDBMS, although it’s scoped to multiple nodes in a distributed system vs. a single node as per typical RDBMS deployment.

For MongoDB deployment, read concern local means:

• For standalone: it won’t return uncommitted transaction data.
• For replset, it can return data that’s not majority-acked (can be rolled back). But it won’t return uncommitted transaction data.
• For sharded cluster, it can depend on each shard based on the replset explanation above.

So basically, the term “uncommitted” here is applied slightly differently, although it refers to the same concept.

A related explanation is in https://www.mongodb.com/docs/manual/core/transactions-production-consideration/#outside-reads-during-commit where it shows the behaviour of outside reads and transactions.

Best regards
Kevin

[Kobe_W]

Kevin is correct.

When talking about isolation (the “I” in ACID), it means to single node operation. here the commit/uncommitted means transaction commit, since everything in SQL is a transaction.

In mongoDB, it means “majority committed” meaning if you use something like local/available read concern, the read data might be subsequently rolled back.

But any changes made inside a transaction are not visible to readers outside of the transaction

In mongo, not everything is a transaction implicitly which is different from SQL world. So in many cases, the doc has to be clear about the context (e.g. in a session or not, casual consistent or not, transaction or not). Sometimes the doc can lack the detailed context and can cause confusion.