14. control de la concurrencia - adimen serveradimen.si.ehu.es/~rigau/teaching/ehu/abd/altres...

1

Tema 14. Control de la concurrencia 1

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 concurrenciaempleadas por el sistema gestor de bases de datos.



Contenidos

1. Introducción y problemas de la concurrencia2. Seriabilidad de los planes de transacciones3. Técnicas de control de la concurrencia4. Granularidad de datos

Anexo 1. Niveles de aislamiento de transacciones en SQL-92Anexo 2. Acerca del control de la concurrencia en Oracle

2


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 Approachto Design, Implementation and Management. 2nd Edition. Addison-Wesley. (Cap. 17)



• 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

14.1 Introducción y problemas de la concurrencia

3


• ... 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)


¿Por qué es necesario el control de la concurrencia?


• 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 T1considere 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 elementoVéase figura 3


Problemas

4


• Un plan es un orden de ejecución de las operaciones devarias 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 Pen 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

14.2 Seriabilidad de los planes de transacciones

Planes de transacciones


• Para fines de control de concurrencia (y recuperación de fallos), interesa prestar mayor atención a estas operaciones de transacción:

• Ejemplo de dos planes de transacciones

Pa: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ;Pb: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; r1 ;


Operaciones interesantes en un plan de transacciones

abreviaturaOperación

rROLLBACKcCOMMIT eESCRIBIR_ELEMENTOlLEER_ELEMENTO

5


• 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 posiblesVéase figura 4(c)

¿cuáles son correctos?¿existen técnicas de control de concurrencia

que eviten planes incorrectos?

** Teoría de la Seriabilidad **


Planes y seriabilidad


• 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


Planes en serie

6


• 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


Planes seriables


• 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) ; e1(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) ; c1 ;

Operaciones NO en conflicto en Pa: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) ; c1;

etc.


Operaciones en conflicto dentro de un plan

7


• 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


Planes seriables por conflictos


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 = {T1, T2, ... Tn} conjunto de nodos

§ crear un nodo por cada transacción Ti en P

– A = {a1, a2, ... 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 conflictode Tk, crear el arco desde Tj a Tk

Véase figura “Algoritmo”

Ti


Prueba de la seriabilidad por conflictos de un plan

Tj Tk

8


• 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 serieequivalente a P

– pues dos operaciones en conflicto aparecen en dicho orden en P

Véase figuras 6 y 7


Prueba de la seriabilidad por conflictos de un plan (y 2)


• 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 plan2. 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)


Plan de transacciones completo

9


• 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 confirmadade 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


Proyección confirmada de un plan


• 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

Orden de las operaciones de

un plan P

• Carga del sistema• Momento de introducciónde las transacciones

• Prioridades de procesos ( transacciones)...

Planificador de Tareas del SO


Aplicaciones de la seriabilidad

• Parece, pues, que ha de comprobarse si el plan P es seriable una vez ejecutadas la transacciones incluidas en P...

10


Æ Es necesario encontrar métodos que garanticen la seriabilidad, sin tener que verificar los planes

Ejecución de Transacciones

¿P seriable?NO

SI

OK

Cancelar el efecto del Plan ¡¡enfoque muy

poco práctico!!


Aplicaciones de la seriabilidad (y 2)


• 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

14.3 Técnicas de control de concurrencia

11


• 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


Protocolos basados en bloqueos: Candados


• 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


Protocolos basados en bloqueos: Candados binarios

12


Reglas en el bloqueo binario1. T debe emitir BLOQUEAR(X) antes de que se realice cualquier

operación LEER_ELEMENTO(X) o ESCRIBIR_ELEMENTO(X) en T2. T debe emitir DESBLOQUEAR(X) después de haber completado todas

las operaciones LEER_ELEMENTO(X) y ESCRIBIR_ELEMENTO(X) en T3. 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!


Protocolos basados en bloqueos: Candados binarios (y 2)


• 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


Protocolos basados en bloqueos: Candados múltiples

13


Reglas en el bloqueo de modo múltiple1. T debe emitir BLOQUEAR_LECTURA(X) o BLOQUEAR_ESCRITURA(X) antes de

que se realice cualquier operación LEER_ELEMENTO(X) en T2. T debe emitir BLOQUEAR_ESCRITURA(X) antes de realizar cualquier

operación ESCRIBIR_ELEMENTO(X) en T3. T debe emitir DESBLOQUEAR(X) una vez completadas todas las

operaciones LEER_ELEMENTO(X) y ESCRIBIR_ELEMENTO(X) de T4. 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


Protocolos basados en bloqueos: Candados múltiples (2)


Excepciones para las reglas 5 y 4Promoció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 candadoemitiendo BLOQUEAR_LECTURA(X)– Así permite que otras transacciones lean X


Protocolos basados en bloqueos: Candados múltiples (y 3)

14


• El uso de candados para la programación de transacciones no garantiza la seriabilidad de los planesVé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)


Protocolos basados en bloqueos


• Una transacción T sigue el protocolo de bloqueo en dos fasessi todas las operaciones de bloqueo preceden a la primeraoperació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


Bloqueo en dos fases básico, B2F

15


• 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


Bloqueo en dos fases básico, B2F (2)


• 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

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


Bloqueo en dos fases básico, B2F (y 3)

16


• 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 conservador o estático

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 porT, 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)


• Cada una de dos o más transacciones espera que otra libere su candado sobre cierto elemento de informaciónVé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


El problema del bloqueo (o abrazo) mortal

17


• 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!


Protocolos de prevención del bloqueo mortal


• 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


Protocolos de prevención del bloqueo mortal (2)

18


• Esperar - Morirsi MT(Tj) < MT(Tk) entonces Tj puede esperarsi no, se aborta Tj (Tj muere) y

se reinicia después con la misma marca de tiempo

» Una Tj más antigua espera a que termine otra Tk más reciente» Una Tj más reciente que solicita un elemento bloqueado por una Tk

más antigua, es abortada y reiniciada

• Herir - Esperarsi MT(Tj) < MT(Tk) entonces se aborta Tk (Tj hiere a Tk) y

se reinicia después con la misma MTsi no, Tj puede esperar

» Una Tj más reciente espera a que termine una Tk más antigua» Una Tj más antigua que solicita un elemento bloqueado por una Tk

más reciente, hace que la más reciente sea abortada y reiniciada




• Ventajas e inconvenientes del uso de marcas de tiempo

☺☺– Protocolos libres de bloqueo mortal

LL– 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 variasveces seguidas si Tk más antigua sigue bloqueando el X que Tj solicita



19


• Protocolo de no esperarSi 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 cautelosaSi Tk no está detenida (esperando algún otro elemento bloqueado)

entonces Tj se detiene y esperaSi no, se aborta Tj

– Protocolo libre de bloqueo mortal

• Uso de tiempos predefinidosSi 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




• 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


Protocolos de detección del bloqueo mortal

20


• 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 Tj espera para bloquear el elemento X, ya bloqueado por Tk, crear un arco dirigido desde Tj a 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


Protocolos de detección del bloqueo mortal (2)

Tj Tk

XTj Tk


• 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 elementosVé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


Protocolos de detección del bloqueo mortal (y 3)

21


• 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


El problema de la espera indefinida


• 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


El problema de la espera indefinida (y 2)

22


• 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

14.4 Granularidad de datos

Elementos de bases de datos y granularidad


• 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 concurrenciaPero también...a Ç número de elementos en la BD (y de candados) a Ç trabajo para el gestor de candados, ya Ç 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

14.4 Granularidad de datos

Elección del tamaño adecuado del elemento de datos

14. control de la concurrencia - adimen serveradimen.si.ehu.es/~rigau/teaching/ehu/abd/altres...

Documents