In concurrency, multiple transactions take place, leading to the problem of data mismanagement. Isolation helps us keep the data in a consistent state by locking the mechanism. Unless one of the transactions that is dealing with data is not complete, it will keep the lock on it. Once the transaction completes its operation, another transaction is allowed to use the data.

The read uncommitted, read committed, repeatable read, and serializable are the isolation levels. Let's consider a scenario with A and B as two transactions and find out how these transactions are different from each other. Let's discuss them as follows:

• Read uncommitted: Transaction A updated one of the rows in the table, but has not yet committed it. Transaction B now reads the uncommitted data and the changes made by it are visible. This is the lowest isolation level.
• Read committed: Transaction A is updating a row in a table, but has not yet committed the update. The changes will not be visible to transaction B until A commits the transaction. It will be done by keeping the lock until the process gets completed.
• Repeatable read: This provides the concurrency by keeping the lock on both read and write processes until the end of the transaction.
• Serializable: This is the highest isolation level that locks the selected used data so that the problem occurred in phantom read will be avoided.

As we now understand, the isolation levels, let's discuss them with the help of a reading phenomena one by one.

Dirty read: Let's consider two transactions, A and B, running on the set of data. Transaction A makes some changes, but has not yet committed them. Meanwhile, transaction B reads the data along with the uncommitted changed data. If transaction A successfully completes its operation, both the transactions have the same state of data. However, if transaction A fails, the data changed by it will be rolled back. The set of data with A and that with B will be different as B reads the uncommitted data. Transaction B is using stale data, leading to the failure of the business logic of the application.

Non-repeatable read: Let's again consider transaction A and B that are running to complete a few operations. Both of them read the data--transaction A changes some of the values and commits them successfully, and transaction B is still working on the previous set of the data, which is stale, leading to the undesirable effect. The situation can be avoided by keeping the lock on the data, unless the first transaction is not completed.

Phantom read: Transaction A and B have the set of data. With one of the criteria, transaction A has performed a searching operation. Let's say, A is searching for data based on the name of a book. There are 8 rows in the database that are returned to transaction A. Meanwhile, transaction B inserted a row in the table, having the same value for the name A was searching. A got stale data as, actually, there are nine rows in the table, but A got just eight.

Repeatable read: Transaction A and B have the same set of data. With one of the criteria, transaction A has performed a searching operation. Meanwhile, transaction B started to update the data. Here, transaction B will wait for transaction A to complete as it has a row whose update operation will be done by transaction B. This was the case to update a data used by both the transactions. What if transaction B wants to add a new data? The new data can be added by transaction B without delay. However, it's not allowed to modify the data by transaction B, which has been used in select query in transaction A.

The following are the default isolation levels supported by databases: