Problemas de transacciones concurrentes

1.1 Introducción

Y ahora comienza la diversión: la teoría de cómo funcionan las transacciones. ¿Cómo mantener el sistema funcionando cuando cambia los mismos datos en diferentes hilos? ¿O quieres ejecutar una transacción en otra? Comenzaremos a buscar respuestas a estas preguntas estudiando el aislamiento de las transacciones...

El nivel de aislamiento de transacciones es un valor condicional que determina hasta qué punto, como resultado de la ejecución de transacciones lógicamente paralelas en el DBMS, se permiten datos inconsistentes. La escala de niveles de aislamiento de transacciones contiene una serie de valores, clasificados de menor a mayor; un mayor nivel de aislamiento corresponde a una mejor consistencia de los datos, pero su uso puede reducir el número de transacciones físicamente paralelas.

Por el contrario, un nivel de aislamiento más bajo permite transacciones más paralelas, pero reduce la precisión de los datos. Por lo tanto, al elegir el nivel de aislamiento de transacciones utilizado, el desarrollador del sistema de información, en cierta medida, ofrece la posibilidad de elegir entre la velocidad de trabajo y garantizar la consistencia garantizada de los datos recibidos del sistema.

Problemas de acceso concurrente usando transacciones

Cuando las transacciones se ejecutan en paralelo, son posibles los siguientes problemas:

• actualización perdida : si un bloque de datos se cambia simultáneamente por diferentes transacciones, todos los cambios se pierden, excepto el último;
• lectura "sucia" (eng. Lectura sucia) : lectura de datos agregados o modificados por una transacción, que posteriormente no se confirmará (revertirá);
• lectura no repetible (eng. lectura no repetible) : cuando se vuelve a leer dentro de la misma transacción, se cambian los datos leídos anteriormente;
• Lecturas fantasma : una transacción durante su ejecución varias veces selecciona muchas filas de acuerdo con los mismos criterios. Otra transacción entre estas extracciones agrega filas o modifica columnas de algunas de las filas utilizadas en los criterios de recuperación de la primera transacción y finaliza correctamente. Como resultado, resultará que las mismas selecciones en la primera transacción dan diferentes conjuntos de filas.

Considere situaciones en las que estos problemas pueden ocurrir.

1.2 Actualización perdida

La situación cuando, cuando un bloque de datos es cambiado simultáneamente por diferentes transacciones, uno de los cambios se pierde.

Supongamos que hay dos transacciones ejecutándose al mismo tiempo:

En ambas transacciones, el valor del campo f2 cambia, al completarse, el valor del campo debe incrementarse en 45. De hecho, puede ocurrir la siguiente secuencia de acciones:

1. Ambas transacciones leen simultáneamente el estado actual del campo. Aquí no se requiere concurrencia física exacta, es suficiente que la segunda operación de lectura en orden se complete antes de que otra transacción escriba su resultado.
2. Ambas transacciones calculan el nuevo valor del campo sumando 20 y 25, respectivamente, al valor leído anteriormente.
3. Las transacciones intentan volver a escribir el resultado del cálculo en el campo f2. Dado que es físicamente imposible realizar dos escrituras al mismo tiempo, en realidad una de las operaciones de escritura se realizará antes y la otra después. La segunda operación de escritura sobrescribirá el resultado de la primera.

Como resultado, el valor del campo f2, al completar ambas transacciones, puede aumentar no en 45, sino en 20 o 25, es decir, una de las transacciones de cambio de datos "desaparecerá".

1.3 Lectura "sucia"

Lectura de datos agregados o modificados por una transacción que luego no se confirmará (reversión).

Supongamos que tenemos dos transacciones abiertas por diferentes aplicaciones que ejecutan las siguientes sentencias SQL:

En la transacción 1 se cambia el valor del campo f2 y luego en la transacción 2 se selecciona el valor de este campo. Después de eso, se revierte la transacción 1. Como resultado, el valor recibido por la segunda transacción diferirá del valor almacenado en la base de datos.

1.4 Lectura no repetible

La situación cuando, al volver a leer dentro de la misma transacción, los datos leídos anteriormente resultan ser cambiados.

Supongamos que tenemos dos transacciones abiertas por diferentes aplicaciones que ejecutan las siguientes sentencias SQL:

En la transacción 2, se selecciona el valor del campo f2, luego en la transacción 1, se cambia el valor del campo f2. Si vuelve a intentar seleccionar un valor del campo f2 en la transacción 2, se obtendrá un resultado diferente. Esta situación es especialmente inaceptable cuando los datos se leen para modificarlos parcialmente y volver a escribirlos en la base de datos.

1.5 Lectura de "fantasmas"

La situación cuando, durante la lectura repetida dentro de la misma transacción, la misma selección da diferentes conjuntos de filas.

Supongamos que hay dos transacciones abiertas por diferentes aplicaciones que ejecutan las siguientes sentencias SQL:

La transacción 2 ejecuta una sentencia SQL que utiliza todos los valores del campo f2. Luego, se inserta una nueva fila en la transacción 1, lo que provoca que la nueva ejecución de la instrucción SQL en la transacción 2 produzca un resultado diferente. Esta situación se denomina lectura fantasma (phantom reading). Se diferencia de la lectura no repetible en que el resultado del acceso repetido a los datos ha cambiado no debido al cambio/eliminación de los datos en sí, sino a la aparición de nuevos datos (fantasma).