The previous example, where we made money out of thin air and ended up transferring 100 pounds out of an account that only had 50 pounds in balance, is a classic example of dirty reads.
A read uncommitted isolation level does not protect us from dirty reads and that is why it is rarely used in production level systems.
The following is the isolation levels versus potential issues:
|
Isolation level |
Lost updates |
Dirty reads |
Non-repeatable reads |
Phantoms |
|
Read uncommitted |
Don't occur |
May occur |
May occur |
May occur |
|
Read committed |
Don't occur |
Don't occur |
May occur |
May occur |
|
Repeatable read |
Don't occur |
Don't occur |
Don't occur |
May occur |
|
Serializable |
Don't occur |
Don't occur |
Don't occur |
Don't occur |
PostgreSQL uses a default (and configurable) isolation level of read committed. As MongoDB is not inherently an RDBMS, using transactions for every operation makes the situation is more complicated.
The equivalent isolation level in these terms is read uncommitted. This may look scary based on the examples previously given, but on the other hand, in MongoDB, there is (again, in general) no concept of transactions or rolling them back. Read uncommitted refers to the fact that changes will be made visible before they are made durable. More details on the made durable part are provided in the following section on durability.