Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

If we have multiple transactions within an application that run against the database we need to isolate the underlying data for each transaction. That is what we control using the different transaction isolation levels. They give us transaction concurrency to run multiple transactions in parallel without affecting each other. To understand the transaction isolation levels you need to understand three database anomalies or transaction anomalies that exist.

Database or transaction anomalies

Dirty Read
Another transaction reads the modified value before a given transaction is committed.

Transaction A:
```
update product price=1000 where productNo=123
```
Before Transaction A commits, Transaction B comes in and reads some data from the database.
```
select * product where productNo=123
```
At some point, if Transaction A rolls back the transaction, transaction B would have already used the data which will leave the customer unhappy if the price was less than 1000 before.
NON-REPEATABLE READ
When I’m reading the same value twice during the transaction, I get different values because some of the transaction has updated that value. This problem is called up non-repeatable. Will read when I’m trying to read the same thing twice, I’m getting two different values. It’s not repeatable.

Transaction A comes in and reads some data from the database.
```
select * product where productNo=123
```
Transaction B comes in and updates the price:
```
update product price=1000 where productNo=123
```
Now Transaction A read the data again:
```
select * product where productNo=123
```
Transaction A will see a different set of information as transaction B has committed the data.
There is a difference between when Transaction A reads the data for the first time and when it reads it again in the same business logic.
PHANTOM READ
At different times. I’m getting a different number of rows in the same transaction in transaction one.

Transaction A comes in and reads all the products that have price more than 2000:
```
select * product where price>2000
```
Then Transaction B comes in and inserts a new product with a price of 3000:
```
insert into product (id,price) values(123,3000)
```
Now Transaction A read the data again with the same logic:
```
select * product where price>2000
```
Transaction A will get a different set, and an additional product will come back in the results. This is called Phantom Read.

Transaction Isolation Levels

These anomalies can be avoided by using transaction isolation levels. In the JavaEE and Spring Framework worlds, there are four transaction isolation levels:

TRANSACTION_READ_UNCOMMITTED
TRANSACTION_READ_COMMITTED
TRANSACTION_REPEATABLE_READ
TRANSACTION_SERIALIZABLE.

If we use READ_UNCOMMITTED, the transaction can read uncommitted data. This is where dirty reads will happen. If we use this read uncommitted level, Dirty Reads, Non-repeatable Reads, and Phantom Reads can occur. All of the anomalies will occur if we use the first level.

The second one is READ_COMMITTED. Ensures that our transactions read only the committed data. So if we use this level, then we will avoid Dirty Reads. Still, will have the Non-Repeatable reads problem. Dirty Reads are prevented. Non-repeatable Reads and Phantom Reads can still occur.

Hibernate Transactions

Then comes the REPEATABLE_READ, this is the popular one and most used one by default. Many databases have this as the default Transaction Repeatable Read. This is where we can prevent the Non-repeatable Read problem as well. But the Phantom Reads can still occur.

Finally, we have SERIALIZABLE which is the most strict transaction isolation level and also the less performing. As the transaction isolation level increases, as we switch from Read Uncommitted to Read Committed and then to Repeatable Read and Serializable, the performance of our application will go down because as we move closer to Serializable. If we use SERIALIZABLE, that means it’s almost like no two transactions can access the same set of data. At the same time, it could be a table-level lock. All the anomalies will be avoided.

Summary

So in this post, you have learned the different anomalies basically: Dirty Reads, Non-repeatable Reads, and Phantom Reads, and you also learned that these three can be avoided using the different isolation levels. TRANSACTION_SERIALIZABLE is the most strict and less performing isolation level, the other three are okay to use based on the type of application you are developing. TRANSACTION_REPEATABLE_READ is the most popular and most used transaction isolation level.

0 replies

Want to join the discussion?
Feel free to contribute!

Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

Database or transaction anomalies

Dirty Read

NON-REPEATABLE READ

PHANTOM READ

Transaction Isolation Levels

Summary

Leave a Reply

Leave a Reply Cancel reply

Search

Suscribe to our Blog

JlvbCoop

Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

Compartir esta entrada

Database or transaction anomalies

Transaction Isolation Levels

Summary

Leave a Reply

Leave a Reply Cancel reply

Search

Suscribe to our Blog

JlvbCoop