Niveles de aislamiento en DB2

Cuando varias transacciones DB2 se ejecutan simultáneamente, pueden darse los problemas que se detallan a continuación:

• Actualizaciones perdidas: se producen cuando dos transacciones leen los mismos datos e intentan actualizarlos a la vez, lo que provoca que una de los dos actualizaciones se pierda. Por ejemplo: las transacciones A y B leen la misma fila y calculan nuevos valores para la misma basados en los originales. Si la transacción 1 actualiza la fila con su nuevo valor e inmediatamente después la transacción 2 hace lo mismo con el suyo, se perderá la actualización de la transacción 1
• Lecturas sucias: fenómeno que se da cuando una transacción lee una fila que acaba de ser actualizada pero que se encuentra a la espera de commit. Por ejemplo: la transacción 1 modifica una fila y la transacción 2 lee dicha fila antes de que se haga commit. Si la transacción 1 hace rollback del cambio, la transacción 2 habrá leído datos que nunca existieron realmente.
• Lecturas no repetibles: se producen si una transacción lee la misma fila dos veces y obtiene resultados diferentes cada vez. Por ejemplo: la transacción 1 lee una fila y a continuación la transacción 2 modifica o borra dicha fila. Si la transacción 1 intenta leer de nuevo la fila, recuperará valores diferentes (si se actualizó la fila) o se encontrará con que no existe (si se borró).
• Lecturas fantasma: ocurren cuando una fila cumple determinado criterio de selección, pero no aparece inicialmente en las consultas. Por ejemplo: la transacción 1 recupera un conjunto de filas que cumplen un criterio de selección. Después la transacción 2 inserta una fila que también cumple el criterio de la transacción 1. Si la transacción 1 vuelve a ejecutar la consulta original, obtendrá un conjunto de filas diferente (se habrá añadido la fila insertada por la transacción 2).

Para evitar estos problemas de concurrencia, DB2 ofrece los niveles de aislamiento (isolation levels), que se definen al hacer el bind del programa (opción ISOLATION [RR | RS | CS | UR] del comando BIND). Son los siguientes:

• Repeatable Read (RR – Lectura repetible )
• Read Stability (RS – Estabilidad de lectura)
• Cursor Stability (CS – Estabilidad de cursor )
• Uncommitted Read (UR – Lectura no confirmada)

En la siguiente tabla vemos los fenómenos que se pueden producir con cada nivel de aislamiento.

Como se puede ver en la tabla, el problema de las actualizaciones perdidas queda eliminado bajo cualquier nivel de aislamiento , ya que el gestor de base datos coloca un bloqueo exclusivo sobre cada fila insertada, actualizada o eliminada. Por lo tanto, todos los niveles de aislamiento garantizan que cualquier fila modificada por una transacción no será modificada por otra transacción mientras dure la ejecución de la transacción original.
A continuación se detallan las características de los diferentes niveles de aislamiento.

Repeatable Read (RR – Lectura repetible)
El nivel de aislamiento Repeatable Read es el más restrictivo. Cuando se aplica a una transacción, los efectos de la misma están completamente aislados de los efectos del resto de transacciones que se ejecuten a la vez. Esto implica que no puedan producirse actualizaciones perdidas, lecturas no repetibles, lecturas sucias ni lecturas fantasma.

Con el nivel de aislamiento Repeatable Read, todas las filas a las que accede la transacción quedan bloqueadas durante el periodo de ejecución de la transacción. Por tanto, si se ejecuta la misma SELECT varias veces dentro de la transacción, el conjunto de filas obtenido será siempre el mismo y la transacción podrá realizar cualquier operación sobre ellas. Las transacciones que se ejecutan bajo este nivel de aislamiento pueden recuperar el mismo conjunto de filas un número ilimitado de veces y realizar cualquier operación sobre las mismas. El resto de transacciones tienen prohibido realizar operaciones de insert, update o delete que puedan modificar las filas a las que accede la transacción propietaria (con nivel de aislamiento Repeatable Read) mientras esta esté activa.

Para garantizar que una transacción con este nivel de aislamiento no se vea afectada por otras transacciones, se bloquean todas las filas referenciadas (no solo las recuperadas o modificadas). Por tanto, si la transacción escanea 1.000 filas para recuperar 10, el bloqueo se adquiere y mantiene sobre las 1.000 filas escaneadas.

Read Stability (RS – Estabilidad de lectura)
El nivel de aislamiento Read Stability no es tan restrictivo como Repeatable Read. Por ello, no aísla totalmente a la transacción del resto de transacciones que se ejecutan simultáneamente. Cuando se utiliza este nivel de aislamiento, no pueden darse actualizaciones perdidas, lecturas sucias ni lecturas no repetibles; pero sí pueden darse lecturas fantasma. Esto es debido a que con Read Stability solo se bloquean las filas recuperadas o modificadas por la transacción que se aisla. Si una transacción escanea 1.000 filas para recuperar 10, solo se adquieren y mantienen bloqueos sobre las 10 filas recuperadas. El hecho de que se adquieran menos bloqueos permite que más transacciones puedan ejecutarse simultáneamente; pero si la transacción aislada ejecuta la misma consulta varias veces, pueden obtenerse resultados diferentes cada vez.

Igual que con el nivel de aislamiento Repeatable Read, las transacciones que se ejecutan bajo Read Stability, pueden recuperar un conjunto de filas y realizar cualquier operación sobre ellas. El resto de transacciones en ejecución tienen prohibido realizar operaciones de actualización y borrado que puedan afectar al conjunto de filas recuperadas por la transacción que se aísla (mientras la transacción permanece activa).

Como el resto de transacciones pueden insertar en cualquier tabla o vista actualizable de la base de datos, es posible que se inserten filas que cumplan el criterio de selección de la transacción aislada. Dichas filas aparecerán como lecturas fantasma en los conjuntos de filas recuperados por consultas posteriores.

Cursor Stability (CS – Estabilidad de cursor)
El nivel de aislamiento Cursor Stability es aún menos restrictivo que Read Stability. Cuando se utiliza este nivel de aislamiento, no se pueden producir actualizaciones perdidas ni lecturas sucias, pero sí lecturas no repetibles y lecturas fantasma.

Con este nivel de aislamiento solo se bloquea la fila a la que apunta el cursor actualizable que se utiliza para recuperar los datos. La duración del bloqueo dependerá de si se ha modificado la fila o no: si se ha modificado, el bloqueo se mantiene hasta que se hace commit. Si no se ha modificado, se libera al recuperar la siguiente fila del cursor o cuando termina la transacción.

Cursor Stability es el nivel de aislamiento por defecto.

Uncommitted read (UR – Lectura no confirmada)
El nivel de aislamiento Uncommited Read es el menos restrictivo de todos, ya que generalmente no aísla la transacción de otras transacciones que se ejecuten simultáneamente. Con este nivel no pueden producirse actualizaciones perdidas, pero sí el resto de fenómenos: lecturas sucias, lecturas no repetibles y lecturas fantasma.

El funcionamiento de UR depende del tipo de cursor que se utilice

• Si el cursor es de solo lectura, las transacciones que se ejecutan bajo este nivel de aislamiento pueden acceder a cambios en datos realizados por otras transacciones antes de que se haga commit de los mismos. Sin embargo, no ocurre lo mismo cuando otras acciones hacen altas y o bajas de objetos de base de datos (tablas, índices y vistas). En estos casos, la transacción que crea o elimina el/los objeto/s debe hacer commit antes de que la transacción con nivel de aislamiento UR pueda verlos.
• Si el cursor es actualizable, el comportamiento es exactamente igual que bajo el nivel de aislamiento CS.

Se utiliza habitualmente cuando la transacción accede a tablas o vistas de solo lectura, o cuando no supone un inconveniente acceder a datos modificados pero no no confirmados (commit).

Fuentes:
https://www.ibm.com/developerworks/data/tutorials/db2-cert6106/index.html
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.admin.perf.doc/doc/c0004121.html