Propiedades comunes de propagación de transacciones de bases de datos y niveles de aislamiento admitidos por Spring
Entonces, ¿cuánto sabes sobre las propiedades comunes de propagación de transacciones de bases de datos y los niveles de aislamiento admitidos por Spring?
Entonces, me pregunto cuánto sabe sobre las propiedades comunes de propagación de transacciones de bases de datos y los niveles de aislamiento admitidos por Spring.
Creo que todo el mundo conoce las propiedades ACID (atomicidad, coherencia, aislamiento, durabilidad) de las transacciones de bases de datos, así que no escribiré sobre ello aquí:
Todos lo sabemos, el El propósito de las transacciones es garantizar la integridad de la base de datos y garantizar que los lotes de declaraciones SQL se ejecuten por completo o no se ejecuten en absoluto.
¿Pero qué pasa si un método anida otros métodos? Si el método actual y los métodos relacionados tienen transacciones, o solo unos pocos métodos tienen transacciones, ¿qué transacción se debe utilizar?
Comportamiento de propagación de transacciones: cuando un método se ejecuta en un método habilitado para transacciones, ya sea que el método actual utilice la transacción original o abra una nueva transacción.
El comportamiento de propagación de transacciones se establece mediante la propagación en la anotación @Transaction.
Hay siete comportamientos de propagación de transacciones:
Aquí hay una pequeña demostración para ayudarlo a comprenderlo más rápido.
Nota: El campo de saldo en la tabla de cuentas está configurado como sin firmar (es decir, no puede ser negativo).
Este proyecto es un proyecto de Spring normal.
El proceso de simulación consiste en comprar un libro, el saldo de la cuenta no es suficiente, pero se compran varios libros a la vez y se pagan juntos.
Luego pruebe la diferencia en el comportamiento de propagación de transacciones allí y vea cómo cambian los datos.
Código inicial:
Código de capa del asignador
Prueba 1: Comportamiento de propagación de transacciones predeterminado
Estamos en proceso de pago vacío(int userId, @ se agrega tanto a la Lista isbns) como a la compra anulada (int userId, int isbn). Transacción
El monto actual en la cuenta es $100 y los precios de los dos libros son $60 y $50 respectivamente. Dado que estamos utilizando un proceso de compra recurrente, ¿crees que obtendremos un libro o un libro? ¿Tampoco puedes conseguirlo?
La respuesta es no, porque en la anotación @Transactional, el atributo de propagación de transacción predeterminado es REQUERIDO, lo que significa que el método comercial debe ejecutarse en una transacción. Si el método ya está en una transacción cuando se ejecuta, se une a ella; de lo contrario, crea una nueva transacción para sí mismo. Entonces, la compra nula (int userId, int isbn) en realidad usa la misma transacción que el método que la llama. Un diagrama simple:
Prueba 2: Prueba -->Atributo REQUIRES_NEW
Excepto por la anotación comprada @Transactional(propagation = Propagation.REQUIRES_NEW), el resto del código permanece sin cambios Cambiar .
REQUIRES_NEW: Independientemente de si existe una transacción, el método comercial siempre inicia una nueva transacción por sí mismo. Si el método ya se está ejecutando dentro de una transacción, la transacción original se suspenderá y se creará una nueva transacción hasta que finalice la ejecución del método, momento en el cual la nueva transacción se considerará completada y la transacción original reanudará su ejecución.
¿Crees que la respuesta es la misma que la anterior?
La respuesta es diferente. En la prueba 1, en realidad estamos usando una transacción al finalizar la compra en lugar de una transacción al momento de la compra, puedes ver esto en la imagen.
Las propiedades de propagación de transacciones para la Prueba 2 son las siguientes:
Por lo tanto, es posible comprar un libro.
Hay muchos más, cuyos significados se han explicado, y no todos se pueden medir.
Supongamos que tenemos dos transacciones A y B ejecutándose simultáneamente.
1) Lectura sucia: una transacción lee nuevas actualizaciones que aún no han sido confirmadas por otra transacción
2) Lectura no repetible: múltiples lecturas en la misma transacción Los mismos datos, devolver resultados diferentes (para operaciones de actualización)
3) Lectura fantasma: una transacción lee una inserción que ha sido confirmada por otra transacción (para operaciones de inserción)
3) Lectura fantasma: una La transacción lee una inserción que ha sido confirmada por otra transacción.
Aislamiento de transacciones de la base de datos: el sistema de base de datos debe tener la capacidad de aislar transacciones concurrentes para que no se afecten entre sí para evitar diversos problemas de concurrencia.
El grado en el que una transacción está aislada de otras transacciones se denomina nivel de aislamiento. La base de datos proporciona múltiples niveles de aislamiento de transacciones. Diferentes niveles de aislamiento corresponden a diferentes grados de interferencia. Cuanto mayor sea el nivel de aislamiento, mejor será la coherencia de los datos, pero más débil será la concurrencia.
En el código, podemos usar.
La base de datos proporciona cuatro niveles de aislamiento:
Nota: Se deben simular las condiciones de concurrencia.
1) Pruebe el nivel de aislamiento predeterminado de mysql:
El código de prueba es muy simple, pero como lo estoy simulando manualmente, tengo que interrumpirlo y comenzar a depurar,
Al ejecutar la primera instrucción doble bookPrice = bookShopMapper.getBookPriceByIsbn (isbn), debes cambiar el precio del libro en mysql para que puedas ver el resultado.
Luego continúa la ejecución. Vea cuál es el resultado.
El resultado final sigue siendo 50, 50. Debido a que el nivel de intervalo de transacción predeterminado de MySQL es Lectura repetible, esto significa que dentro de la misma transacción, puede leer repetidamente.
Nota: Dado que se trata de una modificación directa de la base de datos, el comportamiento de la operación no es ideal, esto es sólo para fines de simulación. A veces los resultados no siempre son precisos.