Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

Si tenemos múltiples transacciones dentro de una aplicación que se ejecutan en la base de datos, necesitamos aislar los datos subyacentes para cada transacción. Eso es lo que controlamos usando los diferentes niveles de aislamiento de transacciones. Nos brindan concurrencia de transacciones para ejecutar múltiples transacciones en paralelo sin afectarse entre sí. Para comprender los niveles de aislamiento de transacciones, debe comprender tres anomalías de bases de datos o anomalías de transacciones que existen.

Anomalías de base de datos o transacciones

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

Estas anomalías se pueden evitar mediante el uso de niveles de aislamiento de transacciones. En los mundos de JavaEE y Spring Framework, hay cuatro niveles de aislamiento de transacciones:

TRANSACTION_READ_UNCOMMITTED
TRANSACTION_READ_COMMITTED
TRANSACTION_REPEATABLE_READ
TRANSACTION_SERIALIZABLE.

Si usamos READ_UNCOMMITTED, la transacción puede leer datos no confirmados (‘comiteados’). Aquí es donde ocurrirán las Dirty Reads. Si usamos este nivel, pueden ocurrir Dirty Reads, Non-repeatable Reads, y Phantom Reads. Todas las anomalías ocurrirán si usamos este nivel.

El segundo es READ_COMMITTED. Asegura que nuestras transacciones lean solo los datos confirmados (‘comiteados’). Entonces, si usamos este nivel, evitaremos Dirty Reads. Aún así, tendrá el problema de Non-Repeatable reads. Se evitan las Dirty Reads. Todavía pueden ocurrir Non-repeatable Reads y Phantom Reads.

Hibernate Transactions

Luego viene REPEATABLE_READ, este es e lnivel más popular y el más usado por defecto. Muchas bases de datos tienen este transaction isolation level como predeterminado. Aquí es donde también podemos prevenir el problema Non-repeatable Read. Pero las Phantom Reads aún pueden ocurrir.

Finalmente, tenemos SERIALIZABLE que es el nivel de aislamiento de transacciones más estricto y también el de menor rendimiento. A medida que aumenta el nivel de aislamiento de la transacción, a medida que cambiamos de Lectura no confirmada a Lectura confirmada y luego a Lectura repetible y Serializable, el rendimiento de nuestra aplicación disminuirá porque nos acercamos a Serializable. Si usamos SERIALIZABLE, eso significa que es casi como si dos transacciones no pudieran acceder al mismo conjunto de datos. Al mismo tiempo, podría ser un bloqueo a nivel de tabla de base de datos. Todas las anomalías serán evitadas. con este nivel.

Summary

En esta publicación, hemos aprendido sobre las diferentes anomalías existentes: Dirty Reads, Non-repeatable Reads, and Phantom Reads, también hemos aprendido que estas tres anomalías pueden evitarse usando los diferentes niveles de aislamiento. TRANSACTION_SERIALIZABLE es el nivel de aislamiento más estricto y de menor rendimiento; los otros tres se pueden usar según el tipo de aplicación que esté desarrollando. TRANSACTION_REPEATABLE_READ es el nivel de aislamiento de transacciones más popular y más utilizado.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

Anomalías de base de datos o transacciones

Dirty Read

NON-REPEATABLE READ

PHANTOM READ

Transaction Isolation Levels

Summary

Dejar un comentario

Deja una respuesta Cancelar la respuesta

Buscar

Suscríbete a nuestro Blog

JlvbCoop

Transaction Isolation Levels

Hibernate and JPA with Spring Boot: Transaction Isolation Levels

Compartir esta entrada

Anomalías de base de datos o transacciones

Transaction Isolation Levels

Summary

Dejar un comentario

Deja una respuesta Cancelar la respuesta

Buscar

Suscríbete a nuestro Blog

JlvbCoop