Niveles de aislamiento de las transacciones

Anomalías de base de datos

Las anomalías de base de datos son resultados generados que parecen incorrectos cuando se observan desde el ámbito de una sola transacción, pero que son correctos cuando se observan desde el ámbito de todas las transacciones. A continuación se describen los diversos tipos de anomalías de base de datos:

• Se producen lecturas sucias cuando:
  1. La transacción A inserta una fila en una tabla.
  2. La transacción B lee la fila nueva.
  3. La transacción A efectúa una retrotracción.

  La transacción B puede haber realizado trabajo en el sistema basándose en la fila insertada por la transacción A, pero la fila nunca ha pasado a formar parte permanente de la base de datos.

• Se producen lecturas no repetibles cuando:
  1. La transacción A lee una fila.
  2. La transacción B cambia la fila.
  3. La transacción A lee la misma fila por segunda vez y obtiene los resultados nuevos.
• Se producen lecturas fantasma cuando:
  1. La transacción A lee todas las filas que satisfacen una cláusula WHERE de una consulta SQL.
  2. La transacción B inserta una fila adicional que satisface la cláusula WHERE.
  3. La transacción A vuelve a evaluar la condición WHERE y recoge la fila adicional.

Niveles de aislamiento de las transacciones JDBC

Existen cinco niveles de aislamiento de transacciones en la API JDBC de IBM® Developer Kit para Java™. A continuación figuran los niveles ordenados del menos restrictivo al más restrictivo:

JDBC_TRANSACTION_NONE

Esta es una constante especial que indica que el controlador JDBC no da soporte a las transacciones.

JDBC_TRANSACTION_READ_UNCOMMITTED

Este nivel permite que las transacciones vean los cambios no comprometidos en los datos. En este nivel son posibles todas las anomalías de base de datos.

JDBC_TRANSACTION_READ_COMMITTED

Este nivel indica que los cambios efectuados dentro de una transacción no son visibles fuera de ella hasta que se compromete la transacción. Esto impide que las lecturas sucias sean posibles.

JDBC_TRANSACTION_REPEATABLE_READ

Este nivel indica que las filas que se leen retienen bloqueos para que otra transacción no pueda cambiarlas si la transacción no ha finalizado. Esto no permite las lecturas sucias y las lecturas no repetibles. Las lecturas fantasma siguen siendo posibles.

JDBC_TRANSACTION_SERIALIZABLE

Se bloquean las tablas de la transacción para que otras transacciones que añaden valores a la tabla o los eliminan de la misma no puedan cambiar condiciones WHERE. Esto impide todos los tipos de anomalías de base de datos.

Puede utilizar el método setTransactionIsolation para cambiar el nivel de aislamiento de las transacciones para una conexión.

Consideraciones

Una malinterpretación común es que la especificación JDBC define los cinco niveles transaccionales mencionados anteriormente. Se cree generalmente que el valor TRANSACTION_NONE representa el concepto de ejecución sin control de compromiso. La especificación JDBC no define TRANSACTION_NONE de la misma forma. TRANSACTION_NONE se define en la especificación JDBC como un nivel en el que el controlador no soporta las transacciones y que no es un controlador compatible con JDBC. El nivel NONE nunca se indica cuando se llama al método getTransactionIsolation.

La cuestión se complica tangencialmente por el hecho de que el nivel de aislamiento de transacciones por omisión del controlador JDBC queda definido por la implementación. El nivel por omisión de aislamiento de transacciones para el controlador JDBC nativo es NONE. Esto permite que el controlador trabaje con archivos que no tienen diarios, y no es necesario que el usuario realice especificaciones, como por ejemplo los archivos de la biblioteca QGPL.

El controlador JDBC nativo permite pasar JDBC_TRANSACTION_NONE al método setTransactionIsolation o especificar none como propiedad de conexión. Sin embargo, el método getTransactionIsolation siempre indica JDBC_TRANSACTION_READ_UNCOMMITTED cuando el valor es none. Es responsabilidad de la aplicación efectuar el seguimiento del nivel que se está ejecutando, si la aplicación lo necesita.

En releases anteriores, el controlador JDBC manejaba la especificación de true por parte del usuario para el compromiso automático cambiando el nivel de aislamiento de las transacciones a none, debido a que el sistema no tenía el concepto de modalidad de compromiso automático true. Esta era una aproximación bastante exacta a la funcionalidad, pero no proporcionaba los resultados correctos en todos los escenarios. Esto ya no se realiza; la base de datos desasocia el concepto de compromiso automático del concepto de nivel de aislamiento de las transacciones. Por tanto, es completamente válida la ejecución al nivel JDBC_TRANSACTION_SERIALIZABLE con el compromiso automático habilitado. El único escenario que no es válido es la ejecución al nivel JDBC_TRANSACTION_NONE sin modalidad de compromiso automático. La aplicación no puede tomar el control sobre los límites del compromiso si el sistema no se está ejecutando con un nivel de aislamiento de transacción.

Niveles de aislamiento de transacciones entre la especificación JDBC y la plataforma IBM i

La plataforma IBM i tiene nombres comunes para sus niveles de aislamiento de transacciones que no coinciden con los nombres que proporciona la especificación JDBC. En la tabla que sigue se proporciona una correspondencia con los nombres utilizados por la plataforma IBM i, pero no son equivalentes a los utilizados por la especificación JDBC.

* En esta tabla, por cuestión de claridad, el valor JDBC_TRANSACTION_NONE se hace corresponder con los niveles *NONE y *NC de IBM i. Esta no es una correspondencia directa entre especificación y nivel de IBM i.