La investigación principal en este artículo es la introducción y ejemplos de nivel de aislamiento de transacciones de primavera, como sigue.
Cuando dos transacciones operan en registros en la misma base de datos, ¿cuál es el impacto entre ellas? Esto plantea el concepto de nivel de aislamiento de transacciones. El aislamiento de la base de datos tiene mucho que ver con el control de concurrencia. El nivel de aislamiento de la base de datos es parte del ácido de la característica transaccional de la base de datos. Ácido, es decir, atomicidad, consistencia, aislamiento y durabilidad. Spring tiene cuatro niveles de aislamiento de transacciones: READ_UNCOMMITTED , READ_COMMITTED , REPEATABLE_READ y SERIALIZABLE . Otro es el nivel de aislamiento predeterminado del DEFAULT de la base de datos, y MySQL predeterminado a REPEATABLE_READ .
Echemos un vistazo en detalle a continuación.
Como su nombre lo indica, READ_UNCOMMITTED significa que una transacción puede leer registros de transacciones que no se ha cometido otra transacción. En otras palabras, una transacción puede leer los datos que aún no están comprometidos por otras transacciones. Este es el nivel de aislamiento más débil para las transacciones de primavera. Vea la figura a continuación, la transacción A se enciende y se escribe un registro. En este momento, la transacción B lee los datos y lee este registro, pero luego la transacción A se remonta. Por lo tanto, los datos leídos por la transacción B no son válidos (la base de datos está en un estado no válido). Esta situación se llama Dirty Read. Además del problema de lectura sucia, READ_UNCOMMITTED también puede tener non-repeatable read (no lectura repetitiva) y phantom read (lectura fantasma).
El nivel de aislamiento READ_COMMITTED indica que una transacción solo puede leer los registros comprometidos y no puede leer los registros no comprometidos. En otras palabras, una transacción solo puede leer los datos comprometidos, y no puede leer los datos no comprometidos. Por lo tanto, la situación de lectura sucia ya no ocurre, pero pueden ocurrir otros problemas. Vea la imagen a continuación.
Entre las dos lecturas de la transacción A, la transacción B modifica esa grabación y la comete. Por lo tanto, los registros leídos antes y después de la transacción A son inconsistentes. Este problema se llama lectura no repetible (no se puede leer repetidamente). (Los registros leen de manera inconsistente entre las dos veces, y las lecturas repetidas encontrarán problemas).
Además del problema de lectura no repetible, READ_COMMITTED también puede tener un problema de lectura fantasma.
Repetible_read significa que una transacción puede leer un registro de la base de datos varias veces, y el registro se lee varias veces son las mismas, lo mismo. Este nivel de aislamiento puede evitar el problema de la lectura sucia y la lectura no repetible, pero puede ocurrir el problema de la lectura fantasma. Como se muestra en la figura a continuación.
La transacción A lee una serie de registros de la base de datos dos veces, durante la cual, la transacción B inserta un registro y lo envía. Cuando la transacción A lee la segunda vez, se leerá el registro de que se acaba de insertar la transacción B. Durante una transacción, una serie de registros leídos por transacción a dos veces es inconsistente, y este problema se llama Phantom Read.
Serializable es el nivel de aislamiento más fuerte de Spring. Cuando se ejecuta una transacción, se bloqueará en todos los niveles, como cuando se lee y escriba, como si la transacción se llevara a cabo de manera serial, en lugar de suceder juntos. Esto evita la lectura sucia, la lectura no repetible y la lectura fantasma, pero causará la degradación del rendimiento.
MySQL predeterminado es REPEATABLE_READ .
Veamos un ejemplo a continuación. Abra una transacción en la base de datos MySQL y no se comprometa. Entonces otra transacción lee el registro.
Al principio, los registros en la base de datos son los que se muestran en la figura
A continuación, abra la transacción A en la base de datos MySQL e inserte un registro.
El atributo de transacción de la clase de servicio en el servicio está configurado como READ_UNCOMMITTED .
@TransActional (Isolation = Isolation.Read_uncommited) Public ClasserService {private Accountdao Accountdao; public Accountdao getAcCountDao () {return Accountdao;} public void setacCountDao (cuenta de cuentas de cuentas de dooo) {this.accountdao = cuento {Accountdao.outMoney (de, dinero); Accountdao.inmoney (a, dinero);} public void readalluser () {list <Capition> cuentas = cuentoo.getAllUser (); para (Cuenta de cuenta: cuentas) {System.out.println (Account);}}Ejecute la siguiente clase de prueba
paquete com.chris.service; import static org.junit.assert.*; import org.junit.test; import org.junit.runner.runwith; import org.springframework.beans.factory.annotation.autowired; import og.springframework.test.context.contexciguration; org. {CuagingService.ReadAllUser ();}}Los resultados son los siguientes:
Se puede ver que esta transacción lee datos no comprometidos.
En este momento, retrocede la transacción A se abrió en MySQL.
MySQL> Rollback;
Ejecutar el programa nuevamente y el resultado es
Cuenta [nombre = Michael, dinero = 1000.0]
Cuenta [nombre = Jane, dinero = 1000.0]
Cuenta [nombre = kate, dinero = 1000.0]
Lo anterior es todo el contenido de este artículo sobre la introducción al nivel de aislamiento de transacciones de primavera y el análisis de ejemplos. Espero que sea útil para todos. Los amigos interesados pueden continuar referiéndose a otros temas relacionados en este sitio. Si hay alguna deficiencia, deje un mensaje para señalarlo. ¡Gracias amigos por su apoyo para este sitio!