ADMINISTRACIÓN DE BASES DE DATOS. Control de Concurrencia y Recuperación

Transcripción

1 ADMINISTRACIÓN DE BASES DE DATOS Tema 4 Control de Concurrencia y Recuperación Francisco Ruiz González Departamento de Informática Escuela Superior de Informática Universidad de Castilla-La Mancha Resumen: La información en una BD (BD) está sujeta a diversos peligros, tanto deliberados como accidentales. Por tanto, el SGBD deberá ofrecer un conjunto apropiado de controles para proteger la BD contra este tipo de riesgos. Entre los controles necesarios están los de recuperación, concurrencia, seguridad e integridad. Los problemas de recuperación y concurrencia están muy ligados con la noción de procesamiento de transacciones. En este capítulo presentamos el concepto de transacción, usado para representar una unidad lógica de procesamiento de la BD. Estudiaremos las técnicas de control de concurrencia, utilizadas para asegurar que múltiples transacciones realizadas por varios usuarios no interfieren entre sí produciendo resultados incorrectos. También analizaremos las técnicas para la recuperación desde transacciones fallidas. Introducción. En esta introducción vamos a estudiar los conceptos fundamentales que utilizaremos posteriormente al analizar las principales técnicas de control de concurrencia y recuperación. Sistemas monousuario versus multiusuario. Un SGBD multiusuario permite que más de un usuario utilice el sistema a la vez, en caso contrario se llama monousuario. En un SGBD multiusuario, los datos almacenados en la BD son accedidos y modificados de forma concurrente por los programas de los usuarios. La ejecución de un programa que consulta y/o modifica el contenido de la BD recibe el nombre de transacción. El programa puede ser una consulta sencilla en SQL, o un programa complejo realizado en COBOL. Puede darse el caso de que se realicen simultáneamente varias ejecuciones del mismo programa; cada una de ellas es una transacción. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 1

2 Items de datos. La BD se considera subdividida en pequeñas partes (items ó gránulos) que pueden reservarse o bloquearse (lock) por una transacción, y posteriormente liberarse. Cuando una transacción reserva un ítem, puede impedir que otras transacciones accedan al ítem hasta que quede liberado. Una parte del SGBD, llamada Gestor de Bloqueos (Lock Manager), asigna y reserva los items, así como resuelve dos o más peticiones de reserva sobre el mismo ítem. La naturaleza y el tamaño de los items los debe elegir el diseñador del sistema. En el modelo relacional se pueden escoger items grandes o pequeños, disponibles por medio del bloqueo de tablas o de filas respectivamente. La e lección de items grandes disminuye la sobrecarga del sistema debido al mantenimiento, ya que se tienen que tomar menos acciones con respecto a los bloqueos. Sin embargo, la elección de items pequeños permite que muchas transacciones operen en paralelo, ya que hay menos probabilidad de que reserven los mismos items. Necesidad del control de concurrencia. Distintos problemas pueden ocurrir cuando transacciones concurrentes se ejecutan de manera descontrolada, pudiendo producir estados inconsistentes de la BD. Como ejemplo, comentamos el caso de la BD para gestionar las reservas de una compañía aérea. Para cada vuelo se incluye un registro que, entre otros datos almacena el número de asientos reservados. Trabajaremos con dos transacciones de ejemplo: T1 cancela N reservas desde un vuelo que tiene X asientos reservados y las cambia a otro vuelo que tiene Y asientos reservados; y T2 reserva M asientos adicionales a los X ya reservados en el primer vuelo. T 1 X := X-N; Leer_item(Y); Y := Y+N; T 2 X := X+M; Figura 1. Dos transacciones de ejemplo. A continuación estudiamos tres casos típicos de problemas que nos podemos encontrar. El problema de la modificación perdida. Ocurre cuando dos transacciones que acceden a los mismos items tienen sus operaciones intercaladas de tal forma que ponen el valor de algún ítem incorrectamente. Supongamos que las transacciones T1 y T2 comienzan aproximadamente al mismo tiempo, y sus operaciones están intercaladas como muestra la figura 2; el valor final del ítem X será incorrecto porque T2 lee el valor de X antes de que T1 lo cambie en la BD, y el valor modificado resultante de T1 se pierde. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 2

3 T 1 T 2 tiempo X := X-N; Leer-Item(Y); Y := Y+N; Escribir_item(Y); X := X+M; El item X tiene un valor incorrecto porque su modificación por T1 se pierde Figura 2. El problema de la modificación perdida. El problema de la modificación temporal. También se conoce como problema de la lectura sucia. Esta situación ocurre cuando una transacción modifica un ítem y a continuación la transacción falla por alguna razón. El ítem modificado es accedido por otra transacción antes de que el cambio sea desecho y el ítem vuelva a su valor original. La figura 3 muestra un ejemplo en el que T2 lee un valor de X cambiado por T1, y posteriormente T1 falla, por lo que el valor leído por T2 es incorrecto. T 1 T 2 tiempo X := X-N; Leer-Item(Y); X := X+M; La transacción T1 falla y debe cambiar el valor de X a su valor viejo; pero mientras tanto, T2 ha leido el valor temporal incorrecto de X. Figura 3. El problema de la modificación temporal. El problema de la totalización incorrecta. Este problema se produce si una transacción está calculando una función de totalización agregada sobre varios registros mientras otra transacción está modificando algunos de estos registros. La función agregada puede calcular algunos valores antes de que sean modificados y otros después. Por ejemplo, supongamos una transacción T3 que está calculando el número total ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 3

4 de reservas en todos los vuelos; mientras tanto, la transacción T1 se está ejecutando. Si las operaciones están intercaladas como en la figura 4, el resultado de T3 tendrá un déficit en una cantidad N porque T3 lee el valor de X después de que N asientos sean sustraídos y lee el valor de Y antes de que los N asientos le sean adicionados. T 1 T 3 tiempo X := X-N; Leer-Item(Y); Y :=Y+N; Escribir_item(Y); sum :=0; Leer_item(A); sum := sum+a;.. sum := sum+x; Leer_item(Y); sum := sum+y; T3 lee X despues de haberle sustraido N, y lee Y antes de adicionarle N, por tanto el valor de sum obtenido es erróneo. Figura 4. El problema de la totalización incorrecta. El problema de la lectura no repetible. Ocurre cuando una transacción T1 lee un ítem de datos dos veces y otra transacción T2 modifica dicho ítem entre las dos lecturas. Por tanto, T1 recibe dos valores diferentes del mismo ítem en sus lecturas. Necesidad de la Recuperación. Cuando una transacción es remitida a un SGBD para su ejecución, el sistema es responsable de asegurar que ocurra una de las dos situaciones siguientes: a) Todas las operaciones de la transacción son completadas y su efecto es registrado permanentemente en la BD. b) La transacción no tiene ningún efecto en la BD o en alguna otra transacción. Por tanto, el SGBD no debe permitir que algunas operaciones de una transacción T se apliquen a la BD mientras otras no. Esto podría ocurrir si una transacción falla después de ejecutar algunas de sus operaciones pero antes de ejecutar todas. Tipos de fallos en transacciones. Las principales causas de un fallo en medio de la ejecución de una transacción son las siguientes: ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 4

5 1. El computador falla (fallo del sistema): Un error hardware o software ocurre en el sistema durante la ejecución de la transacción. Si el fallo es de hardware, los contenidos de la memoria interna pueden perderse. 2. Un error de sistema en la transacción: Algunas operaciones en las transacciones pueden causar su fallo, por ejemplo, una división por cero. Fallos en la transacción pueden ocurrir también por valores de parámetros erróneos, error lógico del programa, o incluso, porque el usuario interrumpe la transacción - por ejemplo, pulsando CTRL-C. 3. Errores locales o condiciones de excepción detectados por la transacción: Durante la ejecución de una transacción, ciertas condiciones pueden obligar a cancelar la transacción. Por ejemplo, un saldo insuficiente en una retirada de fondos de una cuenta bancaria. Estas cancelaciones pueden realizarse por programación con una orden ABORT ó ROLLBACK dentro de la propia transacción. 4. Imposiciones del control de concurrencia: Los métodos de control de concurrencia pueden decidir abortar una transacción, para ser restaurada después. 5. Fallo de disco: Algunos bloques de disco pueden perder sus datos por un mal funcionamiento de los procesos de lectura y/o escritura física. 6. Problemas físicos y catástrofes: Aquí se incluyen fallos de potencia, fuego, sabotaje, etc. Fallos de los tipos 1-4 son más comunes que los de tipo 5 ó 6. Cuando un fallo de los tipos 1-4 ocurre, es necesario que el sistema guarde suficiente información para recuperar desde el fallo. Transacciones. Como ya hemos mencionado, la ejecución de un programa que incluye operaciones de acceso a la BD se llama transacción. Si las operaciones no modifican ningún dato, sino que sólo recuperan datos, la transacción es de sólo-lectura. Las transacciones más conflictivas pero más habituales, y que por tanto estudiaremos en detalle, son las que modifican la BD. Las transacciones no pueden violar ninguna restricción de integridad de la BD, es decir, si la BD era consistente cuando empezó una transacción, también debe serlo cuando termine con éxito. Operaciones de Lectura y Escritura en Transacciones. En el nivel que nos interesa para el control de la concurrencia y la recuperación, las operaciones de acceso a una BD que una transacción puede incluir son: 1. Leer_ítem(X): Lee el ítem X y almacena su valor en una variable (por sencillez supondremos que el nombre de la variable de programa coincide con el del ítem). 2. Escribir_ítem(X): Graba el valor de la variable de programa X en el ítem X. La ejecución de una operación Leer_ítem(X) supone los siguientes pasos: 1. Encontrar la dirección del bloque de disco que contiene los datos del ítem X. 2. Copiar el bloque de disco a un buffer en memoria principal (si no lo estuviera ya). 3. Copiar el ítem X desde el buffer a la variable X. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 5

6 La ejecución de una operación Escribir_ítem(X) incluye los siguientes pasos: 1. Encontrar la dirección del bloque de disco que contiene los datos del ítem X. 2. Copiar el bloque de disco a un buffer en memoria principal (si no lo estuviera ya). 3. Copiar el ítem X desde la variable X a su localización correcta en el buffer. 4. Almacenar el buffer modificado en el bloque de disco (la grabación física puede no ser inmediata). Estados de una Transacción. Una transacción es una unidad atómica de trabajo que es completada enteramente o no realizada ninguna parte de ella. La colección de operaciones físicas que forman una transacción constituye una unidad lógica de proceso. Para propósitos de recuperación, el sistema necesita conocer cuando una transacción comienza, aborta o termina. El Gestor de Recuperaciones debe conocer la situación de las siguientes operaciones: BEGIN: Esta operación marca el comienzo de la ejecución de la transacción. READ ó WRITE: Especifican operaciones de lectura y/o escritura de items que son ejecutadas como parte de una transacción. END: Indica que las operaciones de lectura y escritura de la transacción han concluido y marca el fin de la ejecución de la transacción. En este punto es necesario chequear si los cambios realizados por la transacción pueden ser aplicados permanentemente a la BD (COMMIT) o si la transacción ha sido abortada. COMMIT: Señala un final adecuado de la transacción y que cualquier modificación de items ejecutada por la transacción puede ser transferida definitivamente a la BD y no será desecha. ROLLBACK (ABORT): Indica que la transacción ha concluido de forma inadecuada y por tanto, cualquier cambio o efecto que la transacción haya podido tener sobre la BD debe ser desecho. Además de las operaciones anteriores, en algunas técnicas de recuperación específicas se utilizan otras operaciones, entre las cuales están: UNDO: Parecido a rollback, excepto que se aplica a una operación simple en vez de a una transacción completa. REDO: Especifica que ciertas operaciones de la transacción deben ser rehechas para asegurar que todas las operaciones han sido sucesivamente aplicadas a la BD. Las operaciones citadas hacen que una transacción cambie de un estado a otro. En la figura 5 se representa un diagrama de transición entre los diversos estados. Una transacción pasa al estado ACTIVO inmediatamente después de comenzar su ejecución, sin cambiar de estado con las diversas operaciones de lectura y escritura de items. Cuando acaba (END) pasa al estado de PARCIALMENTE CONFIRMADO. En este punto, algunas técnicas de control de concurrencia requieren la realización de ciertos chequeos para asegurar que la transacción no interfiere con otras transacciones que se ejecutan al mismo tiempo. Además, algunos protocolos de recuperación necesitan comprobar que un fallo del sistema no inhabilitará la grabación de los cambios de la transacción de forma permanente. Cuando ambos controles se han realizado, se dice que la transacción ha llegado al estado CONFIRMADO ó punto de confirmación (punto commit) y ha concluido su ejecución. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 6

7 READ / WRITE BEGIN ACTIVO END PARCIALMENTE CONFIRMADO COMMIT CONFIRMADO fallo fallo TERMINADA FALLIDO ROLLBACK ABORTADO Figura 5. Diagrama de transición de estados de una transacción. En otros casos, una transacción puede llegar al estado FALLIDO si uno de los chequeos falla o si es abortada durante su estado activo. La transacción puede tener que ser desecha hacia atrás para deshacer los efectos de sus operaciones de escritura sobre la BD, pasando entonces al estado ABORTADO. Una transacción pasa al estado de TERMINADA cuando desaparece del sistema. Las transacciones fallidas o abortadas pueden ser reiniciadas posteriormente, bien automáticamente, o bien reejecutándolas como una nueva transacción. Fichero de bitácora. Para permitir la recuperación de transacciones fallidas, el sistema mantiene un fichero de bitácora o diario (también llamado fichero log ó journal). El fichero de bitácora contiene los datos de todas las operaciones de las transacciones que afectan a valores de los items de la BD. Esta información puede necesitarse para recuperar desde transacciones fallidas. La bitácora está almacenada en disco de forma que no es afectada por ningún tipo de fallo salvo error del propio disco o catástrofe. Las entradas en la bitácora tienen una de las siguientes estructuras: [start_transaction, T]: La transacción T (identificador generado por el sistema que identifica unívocamente a cada transacción) comienza su ejecución. [write_ítem, T, X, valor_viejo, valor_nuevo]: La transacción T cambia el valor del ítem X de valor_viejo a valor_nuevo. [read_ítem, T, X]: La transacción T lee el valor del ítem X. [commit, T]: La transacción T ha completado todos sus accesos a la BD, y sus efectos pueden ser confirmados (registrados permanentemente en la BD). Dado que todos los cambios permanentes en la BD ocurren dentro de transacciones, podremos recuperar la BD desde un fallo de una o varias transacciones deshaciendo o rehaciendo las operaciones individualmente, transacción por transacción, a partir del fichero de bitácora. Si el sistema falla (crash), podemos recuperar a un estado consistente de la BD examinando la bitácora y utilizando diversas técnicas de recuperación comentadas mas adelante. Puesto que la bitácora contiene un registro de cada operación de escritura que cambia el valor de algún ítem de la BD, podemos deshacer el efecto de las operaciones de escritura de una transacción T retrocediendo por el fichero de bitácora y restaurando todos los items cambiados por dichas operaciones a sus valores_viejos. También podemos rehacer el efecto de las operaciones de escritura de una transacción T recorriendo hacia adelante la bitácora y poniendo ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 7

8 todos los items modificados por una operación Write de T a sus valores_nuevos. Esta última operación puede ser necesaria si todos los cambios son registrados en la bitácora pero un fallo ocurre antes de que todos los nuevos valores sean grabados permanentemente en la BD. Punto de Confirmación y Puntos de Control. Una transacción T ha llegado al estado confirmado (punto de confirmación ó punto commit) cuando todas las operaciones de T que acceden a la BD han sido ejecutadas y concluidas y los efectos de todas las operaciones de la transacción sobre la BD han sido registrados en la bitácora. La transacción está confirmada cuando sus efectos son registrados permanentemente en la BD. En este momento se escribe un registro [commit, T] en la bitácora. Si ocurre un fallo del sistema, se busca hacia atrás en la bitácora para encontrar todas las transacciones que han escrito un registro [start_transaction, T] pero no tienen el registro [commit, T] todavía. Estas transacciones tienen que ser deshechas (rollback) para deshacer sus efectos en la BD. Es habitual no grabar un bloque físico del fichero de bitácora hasta que su área o buffer en memoria principal está lleno. esto ahorra muchos grabaciones físicas del mismo bloque del fichero, pero cuando ocurre un fallo del sistema, sólo las entradas del fichero de bitácora que han sido pasadas a disco están disponibles para procesos de recuperación, ya que los contenidos de memoria principal se pueden perder. Por esta razón, cuando una transacción va a pasar a estado confirmado, se graba a disco cualquier porción de la bitácora que no lo haya sido todavía. Este proceso se llama 'forzar la grabación' del fichero de bitácora. Otro tipo de entradas en la bitácora son los puntos de control (checkpoints). Un punto de control es registrado en la bitácora periódicamente en el momento en que el sistema ha grabado en la BD en disco los efectos de todas las operaciones de escritura de las transacciones confirmadas. Por tanto, todas las transacciones que tienen su registro [commit, T] en la bitácora antes de un registro [checkpoint], no requerirán que sus operaciones de escritura sean rehechas en caso de un fallo del sistema. El Gestor de recuperaciones debe decidir el intervalo para tomar puntos de control, bien en medidas de tiempo o en términos de transacciones confirmadas desde el último punto de control. Tomar un punto de control supone las siguientes operaciones por parte del Gestor de recuperaciones: 1. Suspender temporalmente la ejecución de las transacciones. 2. Forzar la grabación en disco de todos los bloques de la BD modificados en memoria principal. 3. Escribir un registro [checkpoint] en la bitácora y forzar su grabación a disco. 4. Reasumir la ejecución de las transacciones. Propiedades de las Transacciones. Hay varias propiedades que las transacciones deben poseer por necesidades de los métodos de control de concurrencia y recuperación del SGBD, aunque algunos métodos no precisan de todas las propiedades. Las propiedades deseables de las transacciones son: 1. Atomicidad: Una transacción es una unidad atómica de procesamiento; es realizada enteramente o no es realizada en nada. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 8

9 2. Preservación de la Consistencia: Una correcta ejecución de una transacción debe pasar la BD desde un estado consistente a otro también consistente. 3. Durabilidad o permanencia: Cuando una transacción cambia la BD y los cambios son confirmados, estos cambios nunca deben perderse por fallos posteriores. 4. Aislamiento: Una transacción no deberá hacer visibles sus modificaciones a otras transacciones hasta que esté confirmada. Esta propiedad es aplicada más o menos estrictamente por diferentes métodos de control de concurrencia y recuperación. 5. Serializabilidad: Este criterio es obligatorio para muchos métodos de control de concurrencia. Varias transacciones son serializables si el efecto de ejecutarlas con operaciones intercaladas es equivalente a ejecutarlas serialmente. La propiedad de atomicidad requiere que una transacción se ejecute completamente, por lo que si se produce un fallo del sistema en la mitad de la ejecución, las técnicas de recuperación deben deshacer cualquier efecto de la transacción sobre la BD. Es responsabilidad del programador asegurar la propiedad de preservación de la consistencia. La durabilidad es responsabilidad del método de recuperación, mientras la serializabilidad lo es del método de control de concurrencia. El aislamiento es forzado por algunos métodos de recuperación, pero otros no obligan a cumplirlo a expensas de técnicas mas complejas de recuperación que incluyen el retroceso (rollback) en cascada, que estudiaremos mas adelante. Planificación de Transacciones. Supongamos que dos usuarios solicitan al SGBD la ejecución de las transacciones T1 y T2, ambas aproximadamente al mismo tiempo. Si no permitimos intercalado, sólo son posibles dos ordenamientos de las operaciones de las transacciones: 1. Ejecutar todas las operaciones de T1 seguidas por todas las operaciones de T2. 2. Ejecutar todas las operaciones de T2 seguidas por todas las operaciones de T1. T 1 T 2 T 1 T 2 tiempo X := X-N; Leer_Item(Y); Y := Y+N; Escribir_item(Y); X := X+M; tiempo X := X-N; Leer_Item(Y); Y := Y+N; Escribir_item(Y); X := X+M; plan A plan B Figura 6. Dos planes seriales con T1 y T2. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 9

10 Estas dos opciones son mostradas en la figura 6. Si intercalamos operaciones, entonces son posibles muchas ordenaciones diferentes para que el sistema ejecute las operaciones individuales de las transacciones. Cada una de estas ordenaciones es llamada un plan (schedule) de ejecución del conjunto de transacciones. En general, un plan S de n transacciones es una ordenación secuencial de las operaciones de las n transacciones, con la restricción de que el orden interno de las operaciones en cada transacción se debe mantener, es decir, para cada transacción T que participa en S, si la operación I es realizada antes que la J en T, entonces la operación I será realizada antes que la J en S. Las operaciones de las diferentes transacciones pueden ser intercaladas arbitrariamente, cada ordenación es un plan diferente. Serializabilidad de Planes. Un aspecto importante del control de concurrencia, llamado Teoría de la Serializabilidad, intenta determinar cuales planes son 'correctos' y cuales no, y desarrollar técnicas para permitir sólo planes correctos. Planes Seriales, No Seriales y Serializables. En la figura 6, los planes A y B se llaman planes seriales porque las operaciones de cada transacción son ejecutadas consecutivamente sin ninguna operación de otra transacción intercalada. En un plan serial, las transacciones completas son realizadas en orden serial: T1 y entonces T2 en A, y T2 seguida de T1 en B. En cambio, los planes C y D mostrados en la figura 7 son no seriales porque las transacciones no son realizadas secuencialmente sin intercalaciones. T 1 T 2 T 1 T 2 tiempo X := X-N; Leer_Item(Y); Y := Y+N; Escribir_item(Y); X := X+M; tiempo X := X-N; Leer_Item(Y); Y := Y+N; Escribir_item(Y); X := X+M; plan C plan D Figura 7. Dos planes con intercalación de operaciones. Formalmente, un plan S es serial si, para cada transacción T participante en el plan, todas las operaciones de T son ejecutadas consecutivamente en el plan; en caso contrario, el plan es no serial. La ejecución concurrente de varias transacciones es correcta si y sólo si su efecto es el mismo que el obtenido al realizar las mismas transacciones en serie. Si las transacciones son ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 10

11 independientes, entonces los planes seriales son correctos. Esto se debe a que al ejecutarse las transacciones completamente cada una antes de empezar la siguiente, los resultados o efectos obtenidos por cada una son idénticos a los obtenidos por la citada transacción de manera aislada. El problema de los planes seriales es que limitan la concurrencia por la falta de intercalación de operaciones. Si una transacción espera a que se complete una operación de E/S, no podemos conceder la CPU a otra transacción, por lo que los planes seriales suelen producir tiempos de procesamiento normalmente inaceptables. Si aplicamos los valores X=90, Y=90, N=3 y M=2 a las transacciones T1 y T2 mostradas en los diferentes planes de las figuras 6 y 7, después de ejecutar T1 y T2 deberemos obtener los valores X=89 y Y=93. La ejecución de los planes seriales A y B produce los resultados correctos; el plan no serial D también conduce a los valores exactos, mientras que el plan no serial C produce el valor erróneo X=92. El plan C produce un resultado erróneo por el problema de la pérdida de modificación, ya estudiado. Como vemos, algunos planes no seriales producen resultados correctos y otros no. El objetivo ahora es determinar los planes no seriales que siempre dan resultados correctos, para ello se define el concepto de serializabilidad. Un plan S de n transacciones es serializable si es equivalente a algún plan serial de las mismas n transacciones. Decir que un plan no serial S es serializable es equivalente a decir que es correcto, porque es equivalente a un plan serial, que por definición es correcto. Equivalencia de Planes. Existen varias formas de definir la equivalencia de planes. En este apartado discutiremos algunas de ellas. Equivalencia en Resultados. La más simple, pero menos satisfactoria definición de equivalencia de planes consiste en comparar los efectos de los planes en la BD. Dos planes son equivalentes en resultado si producen el mismo estado final de la BD. Sin embargo, puede ocurrir que dos planes diferentes produzcan accidentalmente el mismo estado final. Por ejemplo, en la figura 8 los planes S1 y S2 producen el mismo estado final con X=110 si el estado inicial coincide que era X=100. S 1 X := X+10; S 2 X := X*1.1; Figura 8. Dos planes erróneamente equivalentes en resultados (para X=100). Equivalencia en Orden. También conocida como equivalencia por conflictos. Dos planes son equivalentes en orden si cada ítem afectado por los planes tiene exactamente las mismas operaciones y en el mismo orden en ambos planes. Para no tener que examinar las operaciones exactas de una transacción, podemos asumir que la transacción modifica un ítem basándose únicamente en su valor_viejo. De este forma, las únicas ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 11

12 operaciones que nos interesan son las de Leer_ítem(X) y Escribir_Ítem(X). Esta suposición recibe el nombre de Asunción de Escritura Restringida. Como el valor_nuevo de X depende solo del valor_viejo, podemos simplificar la situación con una función f(x) aplicada a X entre las operaciones Leer_ítem(X) y Escribir_ítem(X); y por tanto, podemos especificar dos conjuntos de items para cada transacción: Conjunto-lectura: todos los items leídos en la transacción. Conjunto-escritura: todos los items escritos en la transacción. La Asunción de Escritura No Restringida supone que el valor_nuevo de cada ítem de la BD en el conjunto-escritura depende de los valores de algunos items en el conjunto-lectura. En la figura 9 se muestra un caso de cada tipo de asunción. S 3. (incluye X := f(x)). S 4 Leer_item(Y);. (incluye X :=f(x,y) y Z := g(x,y)). X := X*1.1; Escribir_item(Z); Figura 9. Asunción de Escritura Restringida (S3) y No Restringida (S4). La definición de equivalencia en orden es aplicable en los dos casos, pero la distinción entre las asunciones hechas supone diferencias importantes en las pruebas de serializabilidad de los planes. Equivalencia por serializabilidad. En esta definición, dos planes S1 y S2, en los cuales participan las mismas transacciones T1, T2,..., Tn, son equivalentes si: 1. Para cada operación Leer_ítem(X) ejecutada por la transacción Ti en S1, si el valor de X leído es el último escrito por una operación Escribir_ítem(X) ejecutada por la transacción Tj en S1, entonces la misma operación Leer_ítem(X) de Ti en S2 debe leer el valor escrito por la misma operación Escribir_ítem(X) de Tj en S2. 2. Para cada ítem X para el cual alguna operación Escribir_ítem(X) es aplicada en los planes, si el Escribir_ítem(X) final en el plan S1 es ejecutado por Ti, entonces el Escribir_ítem(X) final en el plan S2 debe ser la misma operación Escribir_ítem(X) ejecutada por Ti. Esta definición establece que cada operación de lectura en S2 debe leer el mismo valor como la correspondiente operación en S1. Además, el último valor escrito en la BD para cada ítem debe ser el mismo para ambos planes. Por ejemplo, el plan D de la figura 7 es equivalente al plan A de la figura 6; y por tanto, como el plan A es serial, el plan D es serializable. En cambio, el plan C de la figura 7 no es equivalente al plan A de la figura 6 porque la operación Leer-Ítem(X) en T2 lee el valor escrito por T1 en el plan A, mientras que en el plan C lee el valor original de X, violando así la regla 1. El plan C tampoco es equivalente al plan B de la figura 6, por tanto, no es serializable. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 12

13 Pruebas de Serializabilidad de un Plan. A continuación comentamos los algoritmos para verificar la serializabilidad de planes, lo cual nos permitirá un mejor entendimiento de los protocolos de control de concurrencia que estudiaremos posteriormente. Prueba de Serializabilidad con Escritura Restringida. El algoritmo siguiente verifica la serializabilidad de un plan S bajo la asunción de escritura restringida (equivalencia por orden). Para ello, se construye un grafo de precedencia para el plan. Dicho grafo es un grafo dirigido G = (N,E) que consiste de un conjunto de nodos N = {T1, T2,..., Tn} y un conjunto de arcos dirigidos E = {e1, e2,..., em}. Existe un nodo en el grafo por cada transacción Ti en el plan. Cada arco ei en el grafo es de la forma Tj Tk, 1<=j<=n, 1<=k<=n, donde Tj es el nodo inicial de ei y Tk es el nodo final. (1) Para cada transacción Ti participante en el plan S crear un nodo etiquetado Ti en el grafo; (2) Para cada caso en S donde Tj ejecuta un Leer_ítem(X) después de que Ti ejecuta un Escribir_ítem(X) crear un arco (Ti Tj) en el grafo; (3) Para cada caso en S donde Tj ejecuta un Escribir_ítem(X) después de que Ti ejecuta un Leer_ítem(X) crear un arco (Ti Tj) en el grafo; (4) Para cada caso en S donde Tj ejecuta un Escribir_ítem(X) después de que Ti ejecuta un Escribir_ítem(X) crear un arco (Ti Tj) en el grafo; (5) El plan S es serializable si y solo si el grafo de precedencias no tiene ciclos; Si en el grafo hay un ciclo, entonces el plan S es no serializable. Un ciclo en un grafo dirigido es una secuencia de arcos C = ((Tj Tk), (Tk Tp),..., (Ti Tj)), con la propiedad de que el nodo inicial de cada arco -excepto para el primero- es el nodo final del anterior, y el nodo inicial del primer arco coincide con el nodo final del último arco, es decir, la secuencia comienza y acaba en el mismo nodo. En el grafo de precedencia, un arco desde Ti a Tj significa que la transacción Ti debe comenzar antes que la transacción Tj en cualquier plan serial equivalente a S. Si en el grafo de precedencia no hay ciclos, entonces podemos crear un plan serial S' equivalente a S ordenándo las transacciones participantes de la siguiente manera: cuando existe un arco de Ti a Tj, entonces Ti debe aparecer antes que Tj en el plan serial equivalente S'. En cambio, si el grafo de precedencia tiene algún ciclo, no podremos crear ningún plan serial equivalente, y por tanto, el plan S será no serializable. En la figura 10 se muestran los grafos de precedencia para los planes A-D ya comentados. El grafo de C tiene un ciclo, y por tanto, C no es serializable. El grafo de D no tiene ciclos, por lo que es serializable, y el plan serial equivalente es T1 seguida de T2, es decir, el plan A. Los grafos de A y B no tienen ciclos, como era de esperar, ya que son planes seriales. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 13

14 T1 T2 X X T1 T2 plan A plan B X T1 T2 T1 X T2 X plan C plan D Figura 10. Grafos de precedencias para los planes A-D. El algoritmo para verificar la serializabilidad bajo la asunción de escritura no restringida, caso mucho más general y realista es muy complejo. En [ULLM82] se presenta una propuesta de algoritmo. Utilización de la Serializabilidad. Como ya hemos comentado anteriormente, decir que un plan S es serializable (equivalente a un plan serial), es tanto como decir que S es correcto. Pero mientras que un plan serial origina un procesamiento ineficiente, un plan serializable aprovecha los beneficios de la ejecución concurrente sin que ello implique incorrecciones. En la práctica, la intercalación de operaciones en transacciones concurrentes es determinada habitualmente por el Planificador (Scheduler). Factores como la saturación del sistema o las prioridades de las transacciones contribuyen a la ordenación de las operaciones en un determinado plan. Sin embargo, es prácticamente imposible determinar de antemano como serán intercaladas las operaciones de un plan para asegurar la serializabilidad. Podríamos pensar en ejecutar las transacciones y después verificar si el plan resultante es serializable. En caso contrario deberíamos cancelar los efectos de todas sus transacciones. Este problema hace esta aproximación impracticable. Por todas estas causas, la aproximación utilizada en muchos sistemas prácticos se basa en determinar métodos que aseguren la serializabilidad sin tener que verificarla después de la ejecución del plan. Protocolos para Control de Concurrencia. Uno de los métodos que podemos emplear utiliza la Teoría de la Serializabilidad para determinar protocolos -conjuntos de reglas- que respetados por cada transacción individual, asegurarán la serializabilidad de todos los planes posibles con dichas transacciones como participantes. Bastará con chequear que cada transacción respeta estos protocolos cuando escribimos un programa que utiliza la BD. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 14

15 La mayoría de los protocolos utilizan técnicas de bloqueo (locking) de los items de datos para prevenir que múltiples transacciones accedan a los items concurrentemente. Otros métodos para el control de concurrencia se basan en el empleo de marcas de tiempo (timestamp) que identifican unívocamente a cada transacción. Estas marcas son generadas por el sistema, de forma que las transacciones pueden ser ordenadas según sus marcas para asegurar la serializabilidad. Protocolos basados en bloqueo. También reciben el nombre de candado. En realidad, un bloqueo es una variable asociada con un ítem de la BD; utilizada para almacenar el estado de ese ítem con respecto a posibles operaciones que le puedan ser aplicadas. Usamos los bloqueos como un medio de sincronizar los accesos de transacciones concurrentes a los items de la BD. Tipos de bloqueos. Existen varios tipos de bloqueo. A continuación explicamos algunos de ellos: Bloqueo binario. Un bloqueo binario puede tener dos estados (o valores): bloqueado (valor=1) y no bloqueado ó desbloqueado (valor=0). Un bloqueo diferente se asocia a cada ítem X de la BD. Si el ítem X está bloqueado, dicho ítem no puede ser accedido por operaciones de la BD. Si está desbloqueado, entonces puede ser accedido. El valor del bloqueo del ítem X lo representaremos por Lock(X). Cuando se utiliza este tipo de bloqueo, en las transacciones se deben incluir dos nuevas operaciones. Para acceder a un ítem X una transacción debe realizar una operación de reserva ó bloqueo del citado ítem: Bloquear_ítem(X): B: Si Lock(X)=0 entonces {ítem desbloqueado} Lock(X) <- 1 {bloquear el ítem} Sino Esperar_que(Lock(X)=0 y el gestor de bloqueos levante la transacción) Ir_a B Fin_Si Cuando la transacción deja de usar el ítem, debe realizar una liberación ó desbloqueo para que X pueda ser accedido por otras transacciones: ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 15

16 Desbloquear_ítem(X): Lock(X) <- 0 {desbloquear el ítem} Si hay transacciones esperando entonces levantar una de ellas Fin_Si Estas dos operaciones se deben ejecutar como unidades indivisibles, es decir, no puede haber intercalación con otras operaciones desde que un bloqueo/desbloqueo comienza hasta que acaba, salvo que la transacción pase al estado de espera. La espera de la operación bloquear_ítem(x) se implementa poniendo la transacción en una cola de espera para el ítem X hasta que dicho ítem es liberado y la transacción puede acceder a él. En la citada cola estarán las otras transacciones que también quieren usar el ítem X. Utilizando el bloqueo binario, cada transacción debe obedecer las siguientes reglas: 1. Una transacción T debe realizar una operación Bloquear_ítem(X) antes que un Leer_Ítem(X) o Escribir_ítem(X). 2. Una transacción T debe realizar una operación Desbloquear_ítem(X) después de que todos los Leer_ítem(X) y Escribir_ítem(X) en T se han completado. 3. Una transacción T no realizará un Bloquear_ítem(X) si ya posee el bloqueo de X. 4. Una transacción T no realizará un Desbloquear_ítem(X) salvo que posea el bloquea de X. Entre las operaciones Bloquear_ítem(X) y Desbloquear_ítem(X) en la transacción T, se dice que T posee el bloqueo de X. Sólo una transacción puede poseer el bloqueo de X en cada momento. Respetando las reglas anteriores, no puede haber dos transacciones accediendo al mismo ítem concurrentemente. Aun así, las transacciones pueden ser procesadas concurrentemente si acceden a diferentes items de la BD. Bloqueos compartidos y exclusivos. El bloqueo binario es muy restrictivo, ya que sería mejor permitir que varias transacciones puedan acceder al mismo ítem X si todas ellas lo requieren sólo con propósitos de lectura. SI una transacción pretende escribir un ítem X, entonces debería ser accedido de forma exclusiva. Para poder hacer esto, usaremos un bloqueo de modo múltiple. En este caso hay tres operaciones de bloqueo diferentes: Bloquear_para_lectura(X), Bloquear_para_escritura(X) y Desbloquear_ítem(X). Un bloqueo asociado con el ítem X, Lock(X), tendrá tres estados posibles: 'bloqueado para lectura', 'bloqueado para escritura', ó 'desbloqueado'. Un ítem bloqueado para lectura se dice que tiene un bloqueo compartido porque otras transacciones también pueden leer el ítem. Por contra, un ítem bloqueado para escritura se dice que tiene un bloqueo exclusivo porque una única transacción posee exclusivamente el bloqueo del ítem. Las tres operaciones citadas se implementan de la siguiente forma: ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 16

17 Bloquear_para_lectura(X): B: Si Lock(X)='desbloqueado' entonces Lock(X) <- 'bloqueado-para-lectura' Nº_lecturas(X) <- 1 Sino Si Lock(X)='bloqueado-para-lectura' entonces Nº_lecturas(X) <- Nº_lecturas(X)+1 Sino Esperar_que(Lock(X)='desbloqueado' y el gestor de bloqueos levante la transacción) Ir_a B Fin_Si Fin_Si Bloquear_para_escritura(X): B: Si Lock(X)='desbloqueado' entonces Lock(X) <- 'bloqueado-para-escritura' Sino Esperar_que(Lock(X)='desbloqueado' y el gestor de bloqueos levante la transacción) Ir_a B Fin_Si Desbloquear_ítem(X): Si Lock(X)='bloqueado-para-escritura' entonces Lock(X) <- 'desbloqueado' Si hay transacciones esperando entonces levantar una de ellas Sino Si Lock(X)='bloqueado-para-lectura' entonces Nº_lecturas(X) <- Nº_lecturas(X)-1 Si Nº_lecturas(X)=0 entonces Lock(X) <- 'desbloqueado' Si hay transacciones esperando entonces levantar una de ellas Fin_Si Fin_Si Fin_Si Fin_Si Fin_Si Cuando se emplea el bloqueo en modo múltiple, cada transacción debe obedecer las siguientes reglas: 1. Una transacción T debe ejecutar la operación Bloquear_para_lectura(X) ó Bloquear_para_escritura(X) antes de cualquier Leer_ítem(X) en T. 2. Una transacción T debe usar la operación Bloquear_para_escritura(X) antes de cualquier Escribir_ítem(X) en T. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 17

18 3. Una transacción T debe usar la operación Desbloquear_ítem(X) después de todas las operaciones Leer_ítem(X) y Escribir_ítem(X) en T. 4. Una transacción T no debe usar una operación Bloquear_para_lectura(X) si ya posee un bloqueo compartido o exclusivo sobre el ítem X. 5. Una transacción T no debe usar una operación Bloquear_para-escritura(X) si ya posee un bloqueo compartido o exclusivo sobre el ítem X. 6. Una transacción T no debe usar una operación Desbloquear(X) a menos que posea un bloqueo compartido o exclusivo sobre el ítem X. Protocolo de bloqueo en dos fases. El empleo sin mas de los tipos de bloqueo comentados no garantiza la serializabilidad de los planes. En la figura 11 se muestra un ejemplo de ello. El plan S usando bloqueos en modo múltiple no es serializable. El problema surge porque el ítem Y en T1 y el ítem X en T2 son desbloqueados demasiado pronto. a) T 1 T 2 Bloquear_lectura(Y); Leer_item(Y); Desbloquear(Y); Bloquear_escritura(X); X := X+Y; Desbloquear(X); Bloquear_lectura(X); Desbloquear(X); Bloquear_escritura(Y); Leer_item(Y); Y := X+Y; Escribir_item(Y); Desbloquear(Y); b) Valores iniciales: X=20, Y=30 Resultados del plan serial T1 seguido por T2: X=50, Y=80 Resultados del plan serial T2 seguido por T1: X=70, Y=50 c) T 1 T 2 tiempo Bloquear_lectura(Y); Leer_item(Y); Desbloquear(Y); Bloquear_escritura(X); X := X+Y; Desbloquear(X); Bloquear_lectura(X); Desbloquear(X); Bloquear_escritura(Y); Leer_item(Y); Y := X+Y; Escribir_item(Y); Desbloquear(Y); Plan S Resultados del plan: X=50, Y=50 (no serializable) Figura 11. Transacciones que no obedecen el protocolo de bloqueo en dos fases. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 18

19 Para garantizar la serializabilidad debemos seguir un protocolo adicional concerniente con la posición de los bloqueos y desbloqueos en cada transacción. Una transacción cumple el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo (Bloquear_para_lectura, Bloquear_para_escritura) preceden a la primera operación de desbloqueo en la transacción. Así, una transacción puede dividirse en dos fases: una fase de expansión, durante la cual se pueden obtener nuevos bloqueos sobre los items pero no se deja ninguno; seguida de una fase de contracción, durante la cual los bloqueos existentes pueden dejarse y no se pueden adquirir bloqueos nuevos. Las transacciones T1 y T2 de la figura 11 no cumplen el protocolo de bloqueo en dos fases debido a la operación Bloquear_para_escritura(X) que sigue a Desbloquear(Y) en T1, y similarmente, a la operación Bloquear_para_escritura(Y) que sigue a Desbloquear(X) en T2. Si forzamos el cumplimiento del protocolo, las transacciones T1 y T2 se transforman en T1' y T2' mostradas en la figura 12. T' 1 valores T' 2 valores Bloquear_lectura(Y); Leer_item(Y); Bloquear_escritura(X); Desbloquear(Y); X := X+Y; Desbloquear(X); Y=30 X=20 X=50 Bloquear_lectura(X); Bloquear_escritura(Y); Desbloquear(X); Leer_item(Y); Y := X+Y; Escribir_item(Y); Desbloquear(Y); X=20 Y=30 Y=50 Figura 12. Transacciones que siguen el protocolo de bloqueo en dos fases. Se puede demostrar que, si cada transacción participante en un plan sigue el protocolo de bloqueo en dos fases, entonces el plan es serializable. Los programadores debe asegurar este cumplimiento del protocolo. Esto es relativamente fácil, puesto que podemos chequear cada transacción individualmente. El protocolo de bloqueo en dos fases puede limitar la concurrencia porque una transacción no realiza todos sus desbloqueos hasta que comienza la fase de contracción, y por tanto, otras transacciones que requieran alguno de los items bloqueados deben permanecer a la espera. Este es el precio que hay que pagar para garantizar la serializabilidad de todos los planes sin tener que chequearlos. El gran beneficio es la garantía de que los resultados obtenidos son correctos. Bloqueo mortal y bloqueo activo. Aunque el protocolo de bloqueo en dos fases garantiza la serializabilidad, el uso de cualquier técnica basada en los bloqueos puede causar dos clase nuevas de problemas. El bloqueo mortal (deadlock) o interbloqueo se produce cuando un par de transacciones están cada una esperando a que la otra libere un ítem. En la 13 se muestra un plan de dos transacciones T1' y T2' que están en situación de bloqueo mortal: T1' está esperando que T2' libere el ítem X, mientras que T2' está esperando a que T1' libere el ítem Y. En esta situación, ninguna de las dos transacciones puede proceder a desbloquear el ítem que requiere la otra; y ninguna otra transacción puede acceder a los items X o Y. El bloqueo mortal es también posible con más de dos transacciones. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 19

20 T' 1 T' 2 Bloquear_lectura(Y); Leer_item(Y); Bloquear_lectura(X); T'1 T'2 tiempo Bloquear_escritura(X); Bloquear_escritura(Y); Figura 13. Plan en estado de bloqueo mortal y su grafo de esperas. Para evitar estas situaciones se puede emplear un protocolo de prevención que requiere que cada transacción bloquee todos los items que va a necesitar; si alguno de ellos no puede ser obtenido, entonces ninguno de los demás items es bloqueado, sino que la transacción pasa a un estado de espera y vuelve a intentar posteriormente obtener el bloqueo de todos los items que necesita. Una segunda aproximación para solucionar este problema es detectar los bloqueos mortales. En vez de asegurar que los bloqueos mortales no ocurran nunca, ejecutamos las transacciones sin control y periódicamente el sistema chequea si existe alguna situación de bloqueo mortal. Una manera simple de detectar un estado de bloqueo mortal es construyendo un grafo de esperas. En estos grafos se crea un nodo por cada transacción que se está ejecutando en el plan. Cuando una transacción Ti está esperando a que se libere el ítem X bloqueado por otra transacción Tj, se dibuja un arco dirigido (Ti Tj). Existe un bloqueo mortal si y solo si el grafo de esperas tiene algún ciclo. En la figura 13 se muestra el grafo de espera de las transacciones T1' y T2'. El ciclo que aparece nos confirma la situación de bloqueo mortal. Si se detecta un bloqueo mortal, alguna de las transacciones causantes de dicha situación debe ser abortada, y cualquier efecto que haya tenido sobre la BD debe ser deshecho (rollback). Un problema con esta aproximación es determinar cuando el sistema debe chequear la existencia de bloqueos mortales. Habitualmente se emplean criterios basados en el número de transacciones que se están ejecutando actualmente o en el período de tiempo que las transacciones están esperando para poseer el bloqueo de items. Otro problema que puede ocurrir es el llamado bloqueo activo (livelock). Una transacción está en un estado de bloqueo activo si no puede procesarse por período de tiempo indefinido mientras otras transacciones continúan normalmente. Por ejemplo, si la transacción T2 está esperando a que T1 libere un ítem X, pero cuando lo libera lo bloquea T3, luego T4, etc, de manera que T2 está esperando a poder bloquear el ítem X indefinidamente. La solución a este problema es tener un algoritmo de esperas adecuado. Una de las técnicas de gestión de esperas utiliza una cola primero_en_llegar/primero_en_servir; de forma que las transacciones tienen acceso al bloqueo sobre un ítem en el mismo orden en el que solicitaron dicho bloqueo. Protocolos basados en Marcas de Tiempo. Una aproximación diferente al empleo de bloqueos para garantizar la serializabilidad es utilizar marcas de tiempo para ordenar la ejecución de las transacciones en un plan serial equivalente. Una marca de tiempo es un identificador único creado por el SGBD para identificar una transacción. Típicamente, los valores de las marcas de tiempo se asignan por el orden en el cual las transacciones son remitidas al sistema, de forma que una marca de tiempo puede ser ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 20

21 considerada como el momento de inicio de una transacción. Nos referiremos a la marca de tiempo de la transacción T como TS(T). Las técnicas de control de concurrencia basadas en marcas de tiempo no utilizan bloqueos y por tanto no se producirán las situaciones de bloqueo mortal ya comentadas, sin embargo, son posibles los bloqueos activos si una transacción es continuamente abortada y restaurada, este problema se conoce como restauración cíclica. Las marcas de tiempo pueden ser generadas de diversas formas. Por ejemplo, se puede utilizar un contador que es incrementado cada vez que su valor es asignado a una transacción; de este forma las marcas estarán numeradas como 1, 2, 3,... Otra posibilidad consiste en utilizar el valor actual del reloj del sistema. Ordenación por Marcas de Tiempo. Un método de control de concurrencia que utiliza las marcas de tiempo consiste en ordenar las transacciones según sus marcas de tiempo. cualquier plan con las transacciones participantes será serializable, y el plan serial equivalente tiene las transacciones ordenadas por los valores de sus marcas de tiempo. Esta técnica se llama ordenación por marcas de tiempo. Para permitir la mayor concurrencia posible, dejaremos que las transacciones se ejecuten libremente. Únicamente deberemos asegurarnos de que, para cada ítem accedido por mas de una transacción en el plan, el orden en el cual el ítem es accedido no viola la serializabilidad de el plan. Para ello, asociamos a cada ítem X de la BD dos marcas de tiempo: 1. TS_lectura(X): Marca de tiempo de lectura del ítem X. Es la mayor entre todas las marcas de tiempo de las transacciones que sucesivamente han leído el ítem X. 2. TS_escritura(X): Marca de tiempo de escritura de X. Es la mayor entre todas las marcas de tiempo de las transacciones que sucesivamente han escrito el ítem X. Cuando alguna transacción T intenta realizar una operación Leer_ítem(X) o Escribir_ítem(X) el algoritmo de control de concurrencia debe chequear si la ordenación por marcas de tiempo de las transacciones es violada en alguno de los siguientes casos: 1. La transacción T intenta una operación Escribir_ítem(X): a) Si TS_lectura(X) > TS(T), entonces abortar y deshacer (rollback) T no realizando la operación. La razón es que alguna otra transacción con una marca de tiempo mayor que TS(T) ya ha leído el valor del ítem X antes de que T realiza la escritura de X, violando de esta forma la ordenación por marcas de tiempo. b) Si TS_escritura(X) > TS(T), entonces no ejecutar la operación de escritura pero continuar procesando. Como alguna transacción con marca de tiempo mayor que TS(T) ya ha escrito el valor de X, debemos ignorar la operación Escribir_ítem(X) de T para evitar que modifique el valor correcto. c) Si no se cumplen las condiciones a) y b), entonces ejecutar la operación Escribir_ítem(X) de T y asignar a TS_escritura(X) el valor de TS(T). 2. La transacción T intenta una operación Leer_ítem(X): a) Si TS_escritura(X) > TS(T), entonces abortar y deshacer T no realizando la operación. Esto es porque alguna transacción con mayor marca de tiempo ya ha escrito el valor del ítem X antes de que T hubiese leído su valor, violando de esta forma la ordenación por marcas de tiempo. ESI-UCLM. Administración de BD 4. Control de Concurrencia y Recuperación. pg. 21