Why read-uncommitted isolation level might be bad for you
I in the ACID stands for isolation. Isolation means that when more than one transaction runs serially and accessing the same data or resource, they should have some restriction on what to access and what to not, so they can not affect each other. The problem is a transaction might affect other transactions by reading uncommitted data, which will result in inconsistency and retrieval of stale and outdated data. In the following subsection, we illustrate some of the bad scenarios of reading uncommitted data.
The read uncommitted isolation level is more relaxing in forcing constraints compared to other isolation levels. For instance, one user can read data modified by another user during the transaction.
The above figure illustrates one of the in-consistency that results from the read uncommitted isolation level.
The first actor will start a transaction and change the age value in a table in the database from x to y. The second actor will simultaneously read the age value update value (y). The transaction has not been committed(approved) yet. If the first actor decided to cancel the transaction, the age value for user 1 is x, while the age value for user 2 is y which is stale data causing data inconsistency.
A real-life example of this problem is a problem similar to the double-spending problem in the bitcoin, you will find it in the reference section.
A simple solution for this problem is upgrading to more robust isolation levels like read commit. I may dedicate an article to explain different levels of isolation.
References
