14. Control de la concurrencia

14. Control de la concurrencia Objetivos Conocer la problemática asociada a la concurrencia de transacciones en los sistemas de bases de datos Entender el significado de la seriabilidad y su aplicación al control de la concurrencia Comprender algunas técnicas para el control de concurrencia empleadas por el sistema gestor de bases de datos. Tema 14. Control de la concurrencia 1 14. Control de la concurrencia Contenidos 1. Introducción y problemas de la concurrencia 2. Seriabilidad de los planes de transacciones 3. Técnicas de control de la concurrencia 4. Granularidad de datos Anexo 1. Niveles de aislamiento de transacciones en SQL-92 Anexo 2. Acerca del control de la concurrencia en Oracle Tema 14. Control de la concurrencia 2

14. Control de la concurrencia Bibliografía [EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos de Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley. (Cap. 19 y 20) [EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos fundamentales. 2ª Edición. Addison-Wesley Iberoamericana. (Cap. 17 y 18) [CBS 1998] Connolly, T.; Begg C.; Strachan, A.: Database Systems: A Practical Approach to Design, Implementation and Management. 2 nd Edition. Addison- Wesley. (Cap. 17) Tema 14. Control de la concurrencia 3 14.1 Introducción y problemas de la concurrencia Los sistemas de bases de datos, según el número de usuarios que pueden utilizarlos de forma concurrente, se clasifican en monousuario multiusuario El que varios usuarios puedan usar un mismo equipo a la vez, se debe a la multiprogramación: el computador puede procesar al mismo tiempo varias transacciones Si el equipo tiene varias CPU, es posible el procesamiento simultáneo de transacciones Si sólo hay una CPU, el SO de multiprogramación reparte el tiempo de CPU entre los programas: ejecución concurrente intercalada (*modelo que supondremos*) Véase figura 1 Varias transacciones introducidas por los usuarios, que se ejecutan de manera concurrente, pueden leer/modificar los mismos elementos almacenados en la base de datos Tema 14. Control de la concurrencia 4

14.1 Introducción y problemas de la concurrencia Por qué es necesario el control de la concurrencia?... porque pueden surgir problemas cuando las transacciones concurrentes se ejecutan de manera no controlada Ejemplo sencillo: sistema de bases de datos que permite hacer y anular reservas de vuelos Se almacena un registro por cada vuelo, que incluye, entre otras cosas, el número de asientos reservados en el vuelo Sean dos transacciones T1 y T2 concurrentes: T1 transfiere N reservas realizadas en un vuelo V_X a otro vuelo V_Y T2 reserva M plazas en el vuelo V_X Véase figura 2 Dentro de este sistema de BD, un programa para la reserva o cancelación de vuelos tiene como parámetros: Los números de vuelos, sus fechas, el número de plazas que reservar/cancelar Así que un mismo programa puede usarse para ejecutar muchas transacciones (ejecución específica de un programa transacción) Tema 14. Control de la concurrencia 5 14.1 Introducción y problemas de la concurrencia Problemas La actualización perdida T1 y T2 que acceden a los mismos datos, tienen sus operaciones intercaladas de modo que hacen incorrecto el valor de algún dato La actualización temporal (o lectura sucia) T1 actualiza un elemento X de la BD y luego falla, pero antes de que se restaure el valor original de X, T2 tiene acceso al «valor temporal» de X El resumen incorrecto T1 calcula una función agregada de resumen sobre varios registros, mientras otras transacciones actualizan dichos registros: puede que T1 considere algunos registros antes de que se actualicen y otros después de actualizarse. La lectura no repetible T1 lee un elemento X dos veces y otra transacción T2 modifica dicho X entre las dos lecturas: T1 recibe diferentes valores para el mismo elemento Véase figura 3 Tema 14. Control de la concurrencia 6

14.2 Seriabilidad de los planes de transacciones Planes de transacciones Un plan es un orden de ejecución de las operaciones de varias transacciones que se ejecutan de manera concurrente e intercalada Un plan P de n transacciones T 1, T 2,..., T n es un ordenamiento de las operaciones de las transacciones, sujeto a la restricción de que para cada transacción T i que participa en P, sus operaciones deben aparecer en P en el mismo orden en que ocurren en T i En P, las operaciones de otras T k pueden intercalarse con las de T i Véase figura 4 Tema 14. Control de la concurrencia 7 14.2 Seriabilidad de los planes de transacciones Operaciones interesantes en un plan de transacciones Para fines de control de concurrencia (y recuperación de fallos), interesa prestar mayor atención a estas operaciones de transacción: Operación LEER_ELEMENTO ESCRIBIR_ELEMENTO COMMIT ROLLBACK abreviatura Ejemplo de dos planes de transacciones P a : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; P b : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; r 1 ; l e c r Tema 14. Control de la concurrencia 8

14.2 Seriabilidad de los planes de transacciones Planes y seriabilidad Si no se permite la intercalación de operaciones de varias transacciones, T1 y T2, sólo hay dos formas de ordenar tales operaciones: Ejecutar las operaciones de T1, seguidas de las de T2 en secuencia Ejecutar las operaciones de T2, seguidas de las de T1 en secuencia Véase figuras 4(a) y (b) Si se permite la intercalación, existen muchos órdenes posibles Véase figura 4(c) cuáles son correctos? existen técnicas de control de concurrencia que eviten planes incorrectos? ** Teoría de la Seriabilidad ** Tema 14. Control de la concurrencia 9 14.2 Seriabilidad de los planes de transacciones Planes en serie Un plan P es en serie si, para cada transacción T que participa en el plan, todas sus operaciones se ejecutan consecutivamente en el plan de lo contrario (si hay intercalación), P es un plan no en serie si las transacciones son independientes entre sí, todo plan en serie se considera correcto toda transacción es correcta si se ejecuta sin interferencias (propiedad de Conservación de la Consistencia) y Ninguna transacción necesita de otra para ejecutarse (independencia) no importa cuál se ejecute primero: resultado final correcto Pero los planes en serie limitan la concurrencia en general, son inaceptables en la práctica (ineficiencia) Hemos de determinar qué planes no en serie... siempre dan un resultado correcto y cuáles pueden dar un resultado erróneo Tema 14. Control de la concurrencia 10

14.2 Seriabilidad de los planes de transacciones Planes seriables Un plan P es seriable si es equivalente a algún plan en serie de las mismas n transacciones Un plan que no es equivalente a ningún plan en serie, es no seriable Si un plan no en serie P es seriable, entonces P es correcto Pero... cuándo son equivalentes dos planes? Si producen el mismo estado final en la base de datos Equivalencia por resultados Y si eso se cumple por casualidad? --- no sirve! Véase figura 5, si X=100 (además, son transacciones distintas!!) Si las operaciones sobre cada dato afectado por los planes, se aplican al elemento en el mismo orden en ambos planes Equivalencia por conflictos Equivalencia de vistas Tema 14. Control de la concurrencia 11 14.2 Seriabilidad de los planes de transacciones Operaciones en conflicto dentro de un plan Dos operaciones de un plan P están en conflicto si pertenecen a diferentes transacciones, tienen acceso al mismo elemento X, y al menos una de ellas es ESCRIBIR_ELEMENTO(X) Operaciones en conflicto en P a : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; Operaciones NO en conflicto en P a : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; etc. Tema 14. Control de la concurrencia 12

14.2 Seriabilidad de los planes de transacciones Planes seriables por conflictos Dos planes son equivalentes por conflictos si el orden de cualesquiera dos operaciones en conflicto es el mismo en ambos planes Un plan P es seriable por conflictos si es equivalente por conflictos a algún plan en serie S El orden de las operaciones en conflicto en P coincide con el orden en que se ejecutarían en algún plan en serie Podremos reordenar las operaciones de P que no estén en conflicto, hasta obtener el plan en serie S equivalente a P» El plan D de la figura 4(c) es equivalente al plan A de la figura 4(a), así que D es un plan seriable» El plan C de la figura 4(c) no es equivalente a A ni tampoco a B, por lo que el plan C no es seriable Tema 14. Control de la concurrencia 13 14.2 Seriabilidad de los planes de transacciones Prueba de la seriabilidad por conflictos de un plan Algoritmo de comprobación de si un plan P es seriable por conflictos Considerar operaciones LEER_ELEMENTO y ESCRIBIR_ELEMENTO Construir el grafo de precedencia dirigido G=(N, A) N = {T 1, T 2,... T n } conjunto de nodos crear un nodo por cada transacción T i en P T i A = {a 1, a 2,... a m } conjunto de arcos dirigidos ai = (T j fit k ), con 1 j n, 1 k n si una operación de T j aparece en el plan antes que alguna operación en conflicto de T k, crear el arco desde T j a T k Véase figura Algoritmo T j T k Tema 14. Control de la concurrencia 14

14.2 Seriabilidad de los planes de transacciones Prueba de la seriabilidad por conflictos de un plan (y 2) Si hay un ciclo en el grafo, P no es seriable por conflictos Un ciclo es una secuencia de aristas C=((T j T k ), (T k T p ),... (T i T j )) Si no hay ciclos en el grafo, P es seriable es posible crear un plan en serie S equivalente a P, mediante una ordenación de las transacciones T j T k indica que T j debe ir antes que T k en un plan en serie equivalente a P pues dos operaciones en conflicto aparecen en dicho orden en P Véase figuras 6 y 7 Tema 14. Control de la concurrencia 15 14.2 Seriabilidad de los planes de transacciones Plan de transacciones completo Un plan P es completo si... 1. Las operaciones de P son las de T 1, T 2,..., T n incluida una última operación de COMMIT o ROLLBACK para cada transacción en el plan 2. Para cualquier par de operaciones de una transacción T i, su orden de aparición en P es el mismo que su orden de aparición en T i 3. Para cualesquiera dos operaciones en conflicto, una de ellas debe ocurrir antes que la otra en el plan Esto permite que dos operaciones que no estén en conflicto, ocurran en P sin determinar cuál se ejecuta primero un plan es un orden parcial de las operaciones de n transacciones Pero es necesario especificar un orden total entre... cualquier par de operaciones de la misma transacción T i (condición 2) todo par de operaciones en conflicto (condición 3) Nunca contiene transacciones activas al final del plan Todas hacen COMMIT o ROLLBACK (condición 1) Tema 14. Control de la concurrencia 16

14.2 Seriabilidad de los planes de transacciones Proyección confirmada de un plan En un sistema de procesamiento de transacciones es difícil encontrar planes completos, pues continuamente se introducen transacciones en el sistema Así pues... cuándo comienza y termina un plan? La teoría de la seriabilidad considera la proyección confirmada de un plan P, C(P), que incluye sólo las operaciones de P que pertenecen a transacciones confirmadas Un plan P es seriable si su proyección confirmada C(P) es equivalente a algún plan en serie, ya que el SGBD sólo garantiza las transacciones confirmadas Tema 14. Control de la concurrencia 17 14.2 Seriabilidad de los planes de transacciones Aplicaciones de la seriabilidad Un plan P seriable, además de ser correcto (como un plan en serie) permite la concurrencia Pero es muy difícil comprobar por anticipado la seriabilidad de P Planificador de Tareas del SO Orden de las operaciones de un plan P Carga del sistema Momento de introducción de las transacciones Prioridades de procesos ( transacciones)... Parece, pues, que ha de comprobarse si el plan P es seriable una vez ejecutadas la transacciones incluidas en P... Tema 14. Control de la concurrencia 18

14.2 Seriabilidad de los planes de transacciones Aplicaciones de la seriabilidad (y 2) Ejecución de Transacciones P seriable? SI NO Cancelar el efecto del Plan enfoque muy poco práctico!! OK Es necesario encontrar métodos que garanticen la seriabilidad, sin tener que verificar los planes Tema 14. Control de la concurrencia 19 Métodos basados en la teoría de la seriabilidad, que definen un conjunto de reglas (o protocolo) tal que... si todas las transacciones las cumplen, o el subsistema de control de concurrencia del SGBD las impone (automáticamente)... aseguran la seriabilidad de todo plan de transacciones Tipos de protocolos Basados en bloqueos Basados en marcas de tiempo Técnicas de multiversión Protocolos optimistas Tema 14. Control de la concurrencia 20

Protocolos basados en bloqueos: Candados Un candado... Es una variable asociada a un elemento de información X Describe su estado respecto a las operaciones aplicables a X Sincroniza el acceso al elemento X por parte de transacciones concurrentes El Gestor de Bloqueos (subsistema del SGBD) gestiona y controla el acceso a los candados Tipos de candados Candados binarios Candados de modo múltiple Tema 14. Control de la concurrencia 21 Protocolos basados en bloqueos: Candados binarios Un candado binario tiene dos estados o valores posibles: Bloqueado (1) Desbloqueado (0) Si candado(x)=1, ninguna transacción T que solicite X tendrá acceso a X Si candado(x)=0, T podrá acceder a X cuando lo solicite Las transacciones deben incluir las operaciones... BLOQUEAR(X), para solicitar acceso al elemento X (LOCK) DESBLOQUEAR(X), después de usar el elemento X (UNLOCK) Véase figura 8 Exclusión mutua sobre X Tema 14. Control de la concurrencia 22

Protocolos basados en bloqueos: Candados binarios (y 2) Reglas en el bloqueo binario 1. T debe emitir BLOQUEAR(X) antes de que se realice cualquier operación LEER_ELEMENTO(X) o ESCRIBIR_ELEMENTO(X) en T 2. T debe emitir DESBLOQUEAR(X) después de haber completado todas las operaciones LEER_ELEMENTO(X) y ESCRIBIR_ELEMENTO(X) en T 3. T no emitirá BLOQUEAR(X) si ya bloqueó X (posee su candado) 4. T no emitirá DESBLOQUEAR(X) salvo si posee el bloqueo de X Sólo una transacción puede poseer el candado de X Dos transacciones no pueden tener acceso concurrente al mismo elemento Bastante restrictivo! Tema 14. Control de la concurrencia 23 Protocolos basados en bloqueos: Candados múltiples Un candado de modo múltiple tiene tres estados posibles: Bloqueado para lectura Bloqueado para escritura Desbloqueado Las transacciones deben incluir las operaciones... BLOQUEAR_LECTURA(X) BLOQUEAR_ESCRITURA(X) DESBLOQUEAR(X) Un elemento X bloqueado para... lectura tiene un CANDADO COMPARTIDO: otras T s pueden leer X escritura tiene un CANDADO EXCLUSIVO: T posee X en exclusiva Véase figura 9 Tema 14. Control de la concurrencia 24

Protocolos basados en bloqueos: Candados múltiples (2) Reglas en el bloqueo de modo múltiple 1. T debe emitir BLOQUEAR_LECTURA(X) o BLOQUEAR_ESCRITURA(X) antes de que se realice cualquier operación LEER_ELEMENTO(X) en T 2. T debe emitir BLOQUEAR_ESCRITURA(X) antes de realizar cualquier operación ESCRIBIR_ELEMENTO(X) en T 3. T debe emitir DESBLOQUEAR(X) una vez completadas todas las operaciones LEER_ELEMENTO(X) y ESCRIBIR_ELEMENTO(X) de T 4. T no emitirá BLOQUEAR_LECTURA(X) si ya posee un candado de lectura (compartido) o de escritura (exclusivo) para X *puede permitir excepciones* 5. T no emitirá BLOQUEAR_ESCRITURA(X) si ya posee un candado de lectura o de escritura para el elemento X *esta regla puede permitir excepciones* 6. T no emitirá DESBLOQUEAR(X) salvo si posee un candado de lectura (compartido) o de escritura (exclusivo) para X Tema 14. Control de la concurrencia 25 Protocolos basados en bloqueos: Candados múltiples (y 3) Excepciones para las reglas 5 y 4 Promoción y Degradación de candados Si T emitió BLOQUEAR_LECTURA(X), luego puede promover el candado emitiendo BLOQUEAR_ESCRITURA(X) OK si T es la única que tiene X bloqueado para lectura, si no, T debe esperar y reintentarlo después Si T emitió BLOQUEAR_ESCRITURA(X), luego puede degradar el candado emitiendo BLOQUEAR_LECTURA(X) Así permite que otras transacciones lean X Tema 14. Control de la concurrencia 26

Protocolos basados en bloqueos El uso de candados para la programación de transacciones no garantiza la seriabilidad de los planes Véase figura 10 Es necesario seguir un protocolo adicional que indique dónde colocar las operaciones de bloqueo y desbloqueo de candados dentro de las transacciones El protocolo más conocido, que permite emitir de forma adecuada las operaciones de bloqueo y desbloqueo, es el Protocolo de Bloqueo en Dos Fases (B2F) Tema 14. Control de la concurrencia 27 Bloqueo en dos fases básico, B2F Una transacción T sigue el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo preceden a la primera operación de desbloqueo De este modo, podemos ver T dividida en dos fases: Fase de expansión (o crecimiento) T puede adquirir (o promover) candados T no puede liberar ningún candado Fase de contracción T puede liberar candados existentes T nopuede adquirir ningún candado Tema 14. Control de la concurrencia 28

Bloqueo en dos fases básico, B2F (2) Si se permite promover/degradar candados, ha de variarse la definición general del protocolo: La promoción debe realizarse en la fase de expansión Toda degradación de un candado debe realizarse en la fase de contracción de una transacción Dentro del código de T, un BLOQUEAR_LECTURA(X) que degrada un candado de escritura sobre X, sólo puede aparecer en la fase de contracción de T Véase figuras 10 y 11 Tema 14. Control de la concurrencia 29 Bloqueo en dos fases básico, B2F (y 3) Si toda transacción de un plan sigue el protocolo de bloqueo en dos fases, entonces el plan es seriable Ya no es necesario comprobar la seriabilidad de los planes Al imponer las reglas de bloqueo, también se impone la seriabilidad El B2F puede limitar el grado de concurrencia en un plan Es el precio que hay que pagar por garantizar la seriabilidad de todos los planes sin tener que examinarlos Emplear candados puede provocar problemas de... Bloqueo mortal (Véase figura 12) Espera indefinida Tema 14. Control de la concurrencia 30

Bloqueo en dos fases conservador o estático T debe bloquear todos los elementos a los que tendrá acceso (lectura o escritura) antes de comenzar a ejecutarse Si no es posible bloquear algún elemento, T no bloqueará ninguno y esperará para reintentarlo más tarde Protocolo libre de bloqueo mortal Bloqueo en dos fases estricto el más utilizado T no libera ningún candado de escritura hasta terminar (con COMMIT o ROLLBACK) Ninguna otra transacción lee o escribe un elemento modificado por T, salvo si T se ha completado plan de transacciones estricto No libre de bloqueo mortal (salvo si se combina con B2F conservador) Bloqueo en dos fases riguroso más restrictivo que el B2F estricto T no libera ningún candado hasta terminar (con COMMIT o ROLLBACK) Tema 14. Control de la concurrencia 31 El problema del bloqueo (o abrazo) mortal Cada una de dos o más transacciones espera que otra libere su candado sobre cierto elemento de información Véase figura 12 Para resolver el problema, se puede seguir diferentes enfoques: Protocolos de prevención del bloqueo mortal Bloqueo por adelantado Ordenamiento Uso de marcas de tiempo de transacción Protocolo de no esperar Protocolo de espera cautelosa Uso de tiempos predefinidos Protocolos de detección del bloqueo mortal Uso de grafos de espera Tema 14. Control de la concurrencia 32

Protocolos de prevención del bloqueo mortal Bloqueo por adelantado Empleado en el B2F conservador Toda T debe bloquear por adelantado todos los elementos que necesita (lectura y/o escritura) Si no puede bloquearlos todos, espera y lo reintenta después» Concurrencia muy limitada Ordenamiento Ordenar los elementos de BD y asegurar que si T necesita varios elementos, los bloqueará en ese orden» Concurrencia muy limitada» El programador debe conocer el orden elegido --- poco práctico! Tema 14. Control de la concurrencia 33 Protocolos de prevención del bloqueo mortal (2) Uso de marca de tiempo de transacción Si T j está implicada en un posible bloqueo mortal, debe esperar, abortar o hacer que otra transacción T k aborte? Marca de tiempo de transacción MT(T): Identificador único para T Las MT se ordenan según se inician las transacciones La T más antigua tiene la MT(T) menor Dos esquemas que usan marcas de tiempo y evitan el bloqueo mortal: Sea T j que intenta bloquear el elemento X, pero X ya está bloqueado por T k con un candado en conflicto Esperar - Morir Herir - Esperar Tema 14. Control de la concurrencia 34

Protocolos de prevención del bloqueo mortal (3) Esperar - Morir si MT(T j ) < MT(T k ) entonces T j puede esperar si no, se aborta T j (T j muere) y se reinicia después con la misma marca de tiempo» Una T j más antigua espera a que termine otra T k más reciente» Una T j más reciente que solicita un elemento bloqueado por una T k más antigua, es abortada y reiniciada Herir - Esperar si MT(T j ) < MT(T k ) entonces se aborta T k (T j hiere a T k ) y se reinicia después con la misma MT si no, T j puede esperar» Una T j más reciente espera a que termine una T k más antigua» Una T j más antigua que solicita un elemento bloqueado por una T k más reciente, hace que la más reciente sea abortada y reiniciada Tema 14. Control de la concurrencia 35 Protocolos de prevención del bloqueo mortal (4) Ventajas e inconvenientes del uso de marcas de tiempo Protocolos libres de bloqueo mortal Ambos hacen que sean abortadas y reiniciadas transacciones que podrían provocar un bloqueo mortal, aunque tal cosa nunca ocurriera! En el esquema Esperar-Morir, una T j podría abortar y reiniciarse varias veces seguidas si T k más antigua sigue bloqueando el X que T j solicita Tema 14. Control de la concurrencia 36

Protocolos de prevención del bloqueo mortal (5) Protocolo de no esperar Si T no puede obtener un candado, es abortada y reiniciada después Al abortar T, no se comprueba si ocurrirá o no un bloqueo mortal» Demasiados abortos y reinicios innecesarios Protocolo de espera cautelosa Si T k no está detenida (esperando algún otro elemento bloqueado) entonces T j se detiene y espera Si no, se aborta T j Protocolo libre de bloqueo mortal Uso de tiempos predefinidos Si T espera un tiempo > tiempo predefinido por el sistema entonces el sistema supone que T está en bloqueo mortal y aborta T Al abortar T, no se comprueba si realmente está o no en un bloqueo mortal Tema 14. Control de la concurrencia 37 Protocolos de detección del bloqueo mortal Verificación periódica del estado del sistema está en un bloqueo mortal? Conviene detectar el bloqueo mortal cuando se sabe que hay poca interferencia entre transacciones (casi nunca acceden a los mismos datos al mismo tiempo), es decir si... las transacciones son cortas y bloquean pocos elementos, o la carga de transacciones es pequeña Y conviene prevenir el bloqueo mortal cuando... Las transacciones son largas y bloquean muchos elementos, o si la carga de transacciones es elevada Tema 14. Control de la concurrencia 38

Protocolos de detección del bloqueo mortal (2) Uso de grafos de espera para detectar un bloqueo mortal Crear un nodo por cada transacción en ejecución, etiquetado con el identificador de la transacción, T Si T j espera para bloquear el elemento X, ya bloqueado por T k, crear un arco dirigido desde T j a T k X Cuando T k libera el candado sobre X, borrar la arista correspondiente T j T j T k T k Si en algún momento, existe un ciclo en el grafo de espera, entonces se ha detectado un bloqueo mortal entre las transacciones Tema 14. Control de la concurrencia 39 Protocolos de detección del bloqueo mortal (y 3) Pero... cuándo hay que verificar el estado del sistema? Cuando hay cierto número de transacciones en ejecución, o Cuando varias transacciones en ejecución están cierto tiempo esperando bloquear elementos Véase figura 12 Si el sistema está en un estado de bloqueo mortal, es necesario abortar algunas de las transacciones que lo provocan... pero cuáles? selección de víctimas No elegir transacciones que lleven mucho tiempo en ejecución y hayan realizado muchas modificaciones Seleccionar como víctimas transacciones que... nohan realizado muchos cambios participan en varios ciclos de bloqueo mortal en el grafo de espera Tema 14. Control de la concurrencia 40

El problema de la espera indefinida Una transacción no puede seguir durante un tiempo indeterminado, mientras otras transacciones continúan ejecutándose con normalidad Ocurre si el esquema de espera da más prioridad a unas transacciones que a otras esquema de espera injusto Dos protocolos de prevención de espera indefinida Consiguen un esquema de espera justo El primero que llega, es el primero en ser atendido Las T s puede bloquear el elemento X en el orden en que solicitaron su bloqueo Aumento de prioridad en la espera Cuanto más espera T, mayor es su prioridad Cuando T tiene la prioridad más alta de todas, continúa su ejecución Tema 14. Control de la concurrencia 41 El problema de la espera indefinida (y 2) Es un problema que puede surgir debido a los algoritmos de resolución del bloqueo mortal (selección de víctimas) Una transacción es seleccionada para ser abortada (víctima) sucesivamente: nunca termina su ejecución La solución es asignar prioridades más altas a las T abortadas varias veces, para no ser siempre las víctimas Los esquemas utilizados en Esperar-Morir y Herir-Esperar evitan la espera indefinida Tema 14. Control de la concurrencia 42

14.4 Granularidad de datos Elementos de bases de datos y granularidad Toda técnica de control de concurrencia supone que la base de datos está constituida por un conjunto de elementos de datos con nombre Un elemento puede ser... un valor de campo de un registro de la BD un registro de la BD un bloque de disco un fichero la BD completa Granularidad = tamaño del elemento de información Granularidad fina elementos de tamaño pequeño Granularidad gruesa elementos grandes Tema 14. Control de la concurrencia 43 14.4 Granularidad de datos Elección del tamaño adecuado del elemento de datos Para cada elemento se tiene un candado distinto En el contexto del bloqueo, el tamaño del elemento afecta al grado de concurrencia de las transacciones: tamaño(elemento) Grado de concurrencia Pero también... número de elementos en la BD (y de candados) trabajo para el gestor de candados, y espacio ocupado por la tabla de bloqueos Pero... cuál es el tamaño adecuado para los elementos?... pues depende del tipo de las transacciones implicadas... Si una T representativa accede a pocos registros elegir granularidad de registro Si T accede a muchos registros de un mismo fichero elegir granularidad de bloque o de fichero Tema 14. Control de la concurrencia 44