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
1
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. 2nd Edition. AddisonWesley. (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
2
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
3
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 T1, T2, ..., Tn es un
ordenamiento de las operaciones de las transacciones,
sujeto a la restricción de que
para cada transacción Ti que participa en P,
sus operaciones deben aparecer en P
en el mismo orden en que ocurren en Ti
• En P, las operaciones de otras Tk pueden intercalarse con
las de Ti
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
l
e
c
r
• Ejemplo de dos planes de transacciones
Pa: l1(X) ; l2(X) ; e1 (X) ; l1 (Y) ; e2 (X) ; c 2 ; e1(Y) ; c1 ;
Pb: l1(X) ; e1 (X) ; l2 (X) ; e 2(X) ; c2 ; l1 (Y) ; r1 ;
Tema 14. Control de la concurrencia
8
4
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
5
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 Pa:
l1(X) ; l2(X) ; e 1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1;
l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1;
l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c 1 ;
Operaciones NO en conflicto en Pa:
l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e 1(Y) ; c1;
l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c 1;
etc.
Tema 14. Control de la concurrencia
12
6
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, T2, ... Tn} conjunto de nodos
§ crear un nodo por cada transacción Ti en P
– A = {a 1, a 2, ... am} conjunto de arcos dirigidos
§ ai = (Tj → Tk), con 1 j n , 1 k n
§ si una operación de Tj aparece en el plan
antes que alguna operación en conflicto
de Tk, crear el arco desde Tj a Tk
Ti
Tj
Tk
Véase figura “Algoritmo”
Tema 14. Control de la concurrencia
14
7
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=((Tj →Tk), (Tk →Tp),... (T i →Tj))
• 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
• Tj → Tk indica que Tj debe ir antes que Tk 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 T1, T2, ..., Tn 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 Ti , su orden de
aparición en P es el mismo que su orden de aparición en Ti
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 Ti (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
8
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
9
14.2 Seriabilidad de los planes de transacciones
Aplicaciones de la seriabilidad (y 2)
Ejecución de
Transacciones
¿P seriable?
NO
SI
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
14.3 Técnicas de control de concurrencia
• 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
10
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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
11
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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
12
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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
13
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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 no puede adquirir ningún candado
Tema 14. Control de la concurrencia
28
14
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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
J
Ya no es necesario comprobar la seriabilidad de los planes
− Al imponer las reglas de bloqueo, también se impone la seriabilidad
L
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
15
14.3 Técnicas de control de concurrencia
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 a 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
14.3 Técnicas de control de concurrencia
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
16
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
Protocolos de prevención del bloqueo mortal (2)
• Uso de marca de tiempo de transacción
– Si Tj está implicada en un posible bloqueo mortal, ¿debe esperar, abortar o
hacer que otra transacción Tk 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 Tj que intenta bloquear el elemento X,
pero X ya está bloqueado por Tk con un candado en conflicto
§ Esperar - Morir
§ Herir - Esperar
Tema 14. Control de la concurrencia
34
17
14.3 Técnicas de control de concurrencia
Protocolos de prevención del bloqueo mortal (3)
• Esperar - Morir
si MT(Tj) < MT(Tk) entonces Tj puede esperar
si no, se aborta Tj (Tj 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(Tj) < MT(Tk) entonces se aborta Tk (Tj hiere a Tk) y
se reinicia después con la misma MT
si no, Tj 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
14.3 Técnicas de control de concurrencia
Protocolos de prevención del bloqueo mortal (4)
• Ventajas e inconvenientes del uso de marcas de tiempo
J
– Protocolos libres de bloqueo mortal
L
– 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 Tj podría abortar y reiniciarse varias
veces seguidas si Tk más antigua sigue bloqueando el X que Tj solicita
Tema 14. Control de la concurrencia
36
18
14.3 Técnicas de control de concurrencia
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 Tk no está detenida (esperando algún otro elemento bloqueado)
entonces Tj se detiene y espera
Si no, se aborta Tj
– 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
14.3 Técnicas de control de concurrencia
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
19
14.3 Técnicas de control de concurrencia
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
Tj
Tk
– Si Tj espera para bloquear el elemento X, ya bloqueado por Tk, crear un
arco dirigido desde Tj a Tk
X
Tj
Tk
– Cuando Tk libera el candado sobre X, borrar la arista correspondiente
• 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
14.3 Técnicas de control de concurrencia
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...
§ no han realizado muchos cambios
§ participan en varios ciclos de bloqueo mortal en el grafo de espera
Tema 14. Control de la concurrencia
40
20
14.3 Técnicas de control de concurrencia
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
14.3 Técnicas de control de concurrencia
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
21
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) a Ç Grado de concurrencia
Pero también...
a Ç número de elementos en la BD (y de candados)
a Ç trabajo para el gestor de candados, y
a Ç 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
22