En la especificación SQL estándar, se definen 4 niveles de aislamiento de transacciones. Diferentes niveles de aislamiento manejan las transacciones de manera diferente:
◆Lectura no autorizada (lectura no confirmada): se permiten lecturas de datos sucios. pero no se permite perder las actualizaciones. Si una transacción ha comenzado a escribir datos, no se permite otra operación de escritura de datos al mismo tiempo, pero otras transacciones pueden leer esta fila de datos. Este nivel de aislamiento se puede lograr mediante un "bloqueo de escritura exclusivo".
◆Lectura confirmada: se permiten lecturas no repetibles, pero no se permiten lecturas sucias. Esto se puede lograr mediante "bloqueo de lectura instantánea" y "bloqueo de escritura exclusivo". La transacción que lee los datos permite que otras transacciones continúen accediendo a la fila de datos, pero la transacción de escritura no confirmada evitará que otras transacciones accedan a la fila.
◆Lectura repetible: las lecturas no repetibles y las lecturas sucias están prohibidas, pero a veces pueden aparecer datos fantasma. Esto se puede lograr mediante "bloqueo de lectura ilimitado" y "bloqueo de escritura exclusivo". Las transacciones que leen datos prohibirán las transacciones de escritura (pero permitirán transacciones de lectura), y las transacciones de escritura prohibirán cualquier otra transacción.
◆Serializable: Proporciona un estricto aislamiento de transacciones. Requiere que las transacciones se ejecuten en serie y las transacciones solo se pueden ejecutar una tras otra, pero no al mismo tiempo. Si la serialización de transacciones no se puede lograr únicamente mediante el "bloqueo a nivel de fila", se deben utilizar otros mecanismos para garantizar que la transacción que acaba de ejecutar la operación de consulta no acceda a los datos recién insertados.
Cuanto mayor sea el nivel de aislamiento, más completos y consistentes se podrán garantizar los datos, pero mayor será el impacto en el rendimiento de la concurrencia. Para la mayoría de las aplicaciones, puede dar prioridad a establecer el nivel de aislamiento del sistema de base de datos en Lectura confirmada, lo que puede evitar lecturas sucias y tener un mejor rendimiento de concurrencia. Aunque provocará problemas de concurrencia, como lecturas no repetibles, lecturas virtuales y actualizaciones perdidas de segundo tipo, en situaciones individuales donde pueden ocurrir tales problemas, la aplicación puede controlarlos mediante bloqueos pesimistas o bloqueos optimistas.
De la introducción anterior, ya sabemos que al elegir diferentes niveles de aislamiento, podemos evitar en diversos grados los diversos problemas mencionados anteriormente en el procesamiento de transacciones. Por lo tanto, la selección del nivel de aislamiento de la base de datos es particularmente importante. Al seleccionar el nivel de aislamiento de la base de datos, se debe prestar atención a los siguientes principios de procesamiento:
En primer lugar, se debe excluir la "lectura no autorizada". porque en muchos casos usarlo entre transacciones sería muy peligroso. La operación de reversión o el fracaso de la transacción afectarán otras transacciones concurrentes. Revertir la primera transacción borrará completamente las operaciones de otras transacciones e incluso dejará la base de datos en un estado inconsistente. Es posible que una transacción que se revirtió hasta el final modificó los datos pero terminó con la modificación confirmada, porque la "lectura no autorizada" permitió que otras transacciones leyeran los datos y, finalmente, toda la condición de error se propagó entre otras transacciones.
En segundo lugar, la mayoría de las aplicaciones no necesitan utilizar aislamiento de "serialización" (en términos generales, leer datos fantasma no es un problema), y este nivel de aislamiento también es difícil de medir. Actualmente, las aplicaciones que utilizan aislamiento de serialización generalmente utilizan un bloqueo pesimista, que obliga a serializar y ejecutar todas las transacciones.
El resto es elegir entre “Lectura Autorizada” y “Lectura Repetible”. Consideremos primero las lecturas repetibles. Si todo el acceso a los datos se realiza dentro de una transacción de base de datos atómica unificada, este nivel de aislamiento eliminará la posibilidad de que una transacción sobrescriba los datos durante otra transacción simultánea (el segundo problema de pérdida de actualización de la transacción). Este es un problema muy importante, pero utilizar lecturas repetibles no es la forma de solucionarlo.
Suponiendo que se utilizan "datos de versión", Hibernate utilizará automáticamente los datos de versión. El caché de sesión de primer nivel y los datos de versión de Hibernate ya le brindan la mayoría de las características del "aislamiento de lectura repetible". En particular, los datos de la versión pueden evitar el problema de la pérdida de actualizaciones secundarias. El caché de sesión de primer nivel puede garantizar que el estado de los datos cargados persistentemente esté aislado de las modificaciones de los datos realizadas por otras transacciones. Por lo tanto, si utiliza el aislamiento de lectura autorizado para todas. transacciones de bases de datos y trabajos de datos de versiones.
La "lectura repetible" proporciona una mayor eficiencia para las consultas de bases de datos (solo para aquellas transacciones largas de bases de datos), pero como todavía existen lecturas fantasmas, no es necesario usarlas (para aplicaciones web en términos generales, generalmente es raro consultar la misma tabla dos veces en una transacción de base de datos).
También puede considerar el uso del caché de segundo nivel de Hibernate, que puede proporcionar el mismo aislamiento de transacciones que la transacción de la base de datos subyacente, pero puede debilitar el aislamiento. Si se utiliza mucho una estrategia de concurrencia de caché en el caché de segundo nivel, que no proporciona semántica de lectura repetida (por ejemplo, lectura y escritura, que se analizará en capítulos posteriores, especialmente lectura y escritura no estrictas), es fácil Elija el nivel de aislamiento predeterminado: porque de todos modos Ninguno puede lograr "lecturas repetibles", por lo que no es necesario ralentizar la base de datos. Por otro lado, es posible que no haya un caché de segundo nivel para las clases críticas, o un caché de transacciones completo que proporcione "aislamiento de lectura repetible". Entonces, ¿necesita utilizar "lectura repetible" en su negocio? Si lo desea, por supuesto que puede hacerlo, pero la mayoría de las veces no es necesario pagar este precio.