Control de Concurrencia

1. Control de Concurrencia Lic. Bárbara da Silva Sistemas de Bases de Datos Distribuidas - UCV

2. Esquema de la Clase • Caracterización de una Transacción • Formalización del concepto de transacción • Discusión Tarea • Control de Concurrencia • Teoría de la Seriabilidad • Seriabilidad en BD Centralizadas • Seriabilidad en BDD Distribuidas • Mecanismos - Algoritmos de Control de Concurrencia • Manejo de Abrazo Mortal • Control de Concurrencia en Transacciones Anidadas

3. Caracterización de una Transacción Una transacción lee y escribe data. Entonces: RS = Conjunto de elementos de datos de la BD leidos por una transacción. WS = Conjunto de elementos de datos escritos por una transacción. Por tanto el conjunto base de una transacción es: BS = RS U WS

4. Formalización del Concepto de Transacción Oij(x) = Una operación Oj de la transacción Ti que opera sobre la entidad x de la BD. Donde Oij Є {R(x), W(x)} El conjunto de todas las operaciones en Ti se puede definir como: Osi = UjOij Ni = La condición de terminación para Ti. Ni Є {abort, commit} Una transacción Ti es un orden parcial sobre las operaciones y la condición de terminación. Ese orden parcial se denota como: Ti = {∑i, <i} ‹ Indica el orden de ejecución (precede a)

5. Formalización del Concepto de Transacción • ∑i = Osi U {Ni} • Para dos operaciones cualesquiera Oij, Oik Є Osi si Oij = {R(x) ó W(x)} y Oik = W(x) Para cualquier x, Entonces Oij < Oik ó Oik < Oij • Oij ЄOsi Oij <i Ni

6. Formalización del Concepto de Transacción BEGIN_TRANSACTION Read(x) Read(y) y = y * x; Write(y) Commit END_TRANSACTION T = { ∑, <} ∑ = {R(x), R(y), W(y), C} < = {(R(x), W(y)), (R(y), W(y)), (R(x), C), (R(y), C), (W(y), C)} = {R(x), R(y), W(y), C} Grafo Dirigido Acíclico (DAG) de T R(x) W(y) C R(y)

7. Control de Concurrencia El Mecanismo de Control de Concurrencia de un DDBMS asegura que se mantiene la consistencia de la base de datos en un ambiente distribuido multiusuario. Sino se hace un adecuado control de concurrencia, se pueden presentar dos anomalías: Se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos Pueden presentarse recuperaciones de información inconsistentes.

8. Teoría de la Seriabilidad Establece que un algoritmo de control de concurrencia es correcto cuando sus resultados son los mismos que si se hubiese procesado secuencialmente. BEGIN_TRANSACTION X = 0; X = X + 1; END_TRANSACTION BEGIN_TRANSACTION X = 0; X = X + 2; END_TRANSACTION BEGIN_TRANSACTION X = 0; X = X + 3; END_TRANSACTION

9. Seriabilidad en BD Centralizadas Sean las transacciones Ti = Ri(x) Wi(y) Tj = Rj(x) Wj(x) Tk = Rk(y) Por definición la ejecución serial de Ti Tj Tk es correcta Si tenemos una historia de ejecución S1 = Ri(x) Rj(x) Wi(y) Rk(y) Wj(x) Queremos saber si es correcta

10. Seriabilidad en BD Centralizadas Dos transacciones Ti y Tj se ejecutan serialmente en una historia S si la última operación de Ti precede la primera operación de Tj en S o viceversa, en otro caso ellas se ejecutan concurrentemente. Seriabilidad: Una historia es correcta si ésta es serializable, esto es, ella es equivalente a una historia serial. Operaciones en Conflicto: Dos operaciones Oi y Oj están en conflicto si 1. Son emitidas por transacciones diferentes 2. Operan sobre el mismo dato y una de ellas es una escritura. Ejemplo: (Ri(x) Wj(x)) y (Wi(x) Wj(x)) son operaciones en conflicto.

11. Seriabilidad en BD Centralizadas Condición suficiente para equivalencia Dos historias S1 y S2 son equivalentes si para cada par de operaciones en conflicto Oi y Oj se tiene que: Si Oi precede a Oj en S1 => Oi precede a Oj en S2 Ejemplo: S1 = Ri(x) Rj(x) Wj(y) Wi(x) S2 = Rj(x) Wj(y) Ri(x) Wi(x) -> Es una historia serial: Tj Ti Las operaciones en conflicto son Rj(x) con Wi(x) Rj(x) precede a Wi(x) en S1 y en S2 S1  S2, Por tanto S1 es una historia correcta

12. Seriabilidad en BDD Se dispone de: • n transacciones distribuidas T1, T2,..., Tn sobre m nodos • Un conjunto local de historias S1, S2,..., Sm La seriabilidad de historias locales no es suficiente para asegurar la correctitud de ejecución de un conjunto de transacciones distribuidas.

13. Seriabilidad en BDD Ejemplo: S1 (nodo 1) = Ri(x) Wi(x) Rj(y) Wk(x) S2 (nodo 2) = Wj(z) Wi(z) S3 (nodo 3) = Wj(z) Rk(z) Las tres historias son serializables: S1 = Ti Tj Tk S2 = Tj Ti S3 = Tj Tk Sin embargo no existe una secuencia global de ejecución de las transacciones ya que Ti < Tj en S1 y Tj < Ti en S2.

14. Condición de Seriabilidad en BDD La ejecución de transacciones T1, T2,...,Tn es correcta si: • Cada historia local Sk es serializable. • Existe un ordenamiento total de T1, T2, ... ,Tn tal que si Ti < Tj en el ordenamiento total, entonces existe una historial serial Sk’ tal que Sk es equivalente a SK’ y Ti < Tj en Serial(Sk’) para cada nodo k donde ambas transacciones son ejecutadas.

15. Condición de Seriabilidad en BDD Ejemplo: S1 (nodo 1) = Ri(x) Wi(y) Rj(y) Wk(x) S2 (nodo 2) = Wi(y) Wj(z) S3 (nodo 3) = Wj(z) Rk(z) Las tres historias son serializables: S1 = Ti Tj Tk S2 = Ti Tj S3 = Tj Tk En el nodo 1 Ti < Tj y Tj < Tk En el nodo 2 Ti < Tj En el nodo 3 Tj < Tk Entonces: Ti Tj Tk es un orden total que satisface la condición de seriabilidad

16. Condición de Seriabilidad en BDD Proposición: Sean T = {T1, T2, ..., Tn} un conjunto de transacciones E = {S1, S2,..., Sm} una ejecución de T E es serializable si existe un ordenamiento total de las transacciones tal que para cada par de operaciones en conflicto Oi y Oj de las transacciones Ti y Tj respectivamente Oi < Oj en cualquier historia de E si y solo si Ti < Tj en el ordenamiento total. Un mecanismo de control de concurrencia es correcto si éste sólo permite ejecuciones correctas de transacciones distribuidas

17. Taxonomía de los mecanismos de control de concurrencia

18. Taxonomía de los mecanismos de control de concurrencia Pesimistas: Sincronizan la ejecución concurrente de las transacciones lo más temprano posible. Optimista: Dejan la sincronización de las transacción hasta su terminación.

19. Mecanismo de Bloqueos El método de bloqueo es un mecanismo de serialización que asegura que solo una transacción accede a un objeto en cualquier momento. Cada recurso (objeto, dato) posee una llave. Si una transacción accede un dato, este debe ser bloqueado. Si una transacción quiere bloquear un dato ya bloqueado por otra transacción, debe esperar hasta que la transacción que lo posee lo libere.

20. Taxonomía de los mecanismos de control de concurrencia Los algoritmos basados en Bloqueo: Centralizado: un nodo es designado como nodo primario donde se almacenan todas las tablas de bloqueo y es el responsable de garantizar los bloqueos de las transacciones. Copia Primaria: Una de las copias de cada “unidad de bloqueo” es designada como la copia primaria y esta es la copia que debe ser bloqueada para acceder al dato. Si el dato está duplicado uno de los nodos donde está duplicado es el que lo controla. Distribuido: El manejo del bloqueo es compartido por todos los nodos de la red.

21. Mecanismo de Bloqueos Los bloqueos-lectura y los bloqueos-escritura generaran cronogramas consistentes si y solo si las transacciones se procesan en dos fases (Papadimitriu-1998) El protocolo de bloqueo posee 2 fases: Fase de adquisición de recursos Fase de liberación de recursos Existen dos mecanimos: - Two-Phase Locking - Strict Two-Phase Locking

22. Two-Phase Locking Punto de bloqueo Adquisición de Recursos Liberación de Recursos En la fase de liberación se liberan los candados obtenidos uno por uno. Se pueden dar “Abortos en Cascada” porque si una transacción aborta después de liberar un recurso, otras transacciones que hayan accedido al mismo dato también van a abortar. Número de bloqueos Tiempo

23. Strict Two-Phase Locking Punto de bloqueo Adquisición de Recursos Liberación de Recursos Se liberan todos los recursos cuando la transacción termina (bien sea validando ó abortando) Número de bloqueos Tiempo

24. Ordenamiento de Timestamps A diferencia del mecanismo de bloqueo, no mantienen la seriabilidad por exclusión mutua. Seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ese orden. Cuando una transacciónTi se inicia, el TM le asigna un timeStamp único ts(Ti). El timestamp debe ser único y monótono creciente. Cada manejador de transacciones asigna un timestamp basado en su contador local y el identificador del manejador de transacciones.

25. Ordenamiento de Timestamps 1. Básico: El TM asigna también un ts a las operaciones solicitadas por una transacción. A cada elemento de datos x se le asigna un ts de lectura rts(x) y de escritura wts(x). Sus valores indican el ts más grande para cualquier lectura y escritura de x respectivamente. El ordenamiento de los ts se realiza según la siguiente regla: Dada dos operaciones en conflicto Oij y Okl, perteneciendo a las transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y solo si, ts(Ti) < ts(Tk). Ti -> transacción más vieja y Tk -> transacción más joven.

26. Ordenamiento de Timestamps Rechazar la operación significa que la transacción que la envió necesita reiniciarse para obtener el ts más reciente del dato e intentar hacer nuevamente la operación sobre el mismo.

27. Ordenamiento de Timestamps 1. Conservador: Se retrasan las operaciones de la transacción hasta que un orden de ejecución pueda ser establecido tal que los rechazos no son posibles. Cada manejador de transacciones(i) posee una cola Qij en donde almacena todas las operaciones que recibe de un majeador j en orden creciente asignándole un timestamp. Cuando esté seguro de que ninguna otra operación con un ts menor puede llegar al despachador ejecutan las operaciones en el orden de las colas. Pero este delay introduce la posibilidad de abrazo mortal.

28. Ordenamiento de Timestamps 1. Multiversión: Cada operación de escritura crea una nueva versión del item de dato. Esta versión es marcada con el ts de la transacción que la creó.

29. Algoritmos Optimistas Pesimistas: Validación -> lectura -> cálculo -> escritura Optimistas: Lectura -> cálculo -> validación -> escritura Las operaciones nunca son retardadas. Cada transacción hace sus actualizaciones sobre copias de elementos de datos locales. La fase de validación consiste en chequear si las actualizaciones pueden mantener la consistencia de la BD. Si la mantienen se realizan los cambios sino la transacción es abandonada y reiniciada.

30. Manejo de Abrazo Mortal Debido al mecanismo de bloqueo pueden ocurrir situaciones de abrazo mortal. En un abrazo mortal (AM) cada miembro de un conjunto esta esperando por otro miembro del mismo conjunto. Nadie del conjunto está procesando y ninguno lo hará hasta que algún elemento del conjunto termine. Una solución es nunca esperar sino cancelar cualquier requerimiento que pueda hacer esperar, abandonar y reiniciar el programa. Problema: Se puede crear una situación de vivir-bloqueado.

31. Manejo de Abrazo Mortal Vivir-bloqueado (VB): cada miembro del conjunto puede rápidamente querer esperar por otro miembro del conjunto, resultando en otro abandono y re-inicio. VB es una situación peor que el AM debido a que es más difícil de detectar ya que esta gasta recursos. Otra técnica es Evitar el Abrazo Mortal: se ordenan linealmente los recursos y se deben adquirir los mismos en ese orden. Un AM requiere un ciclo en el grafo de espera de las transacciones. Un orden lineal (o cualquier orden parcial) evita tales ciclos.

32. Manejo de Abrazo Mortal También se puede Detectar el AM: ¿Cómo lo detecta? Timeout -> Cuando una transacción espera más de un cierto tiempo, declara que algo anda mal y abandona. Pero Timeout es un detector muy pesimista porque cualquier espera larga la declara como un AM. La técnica es detectarlo a través de un grafo de espera, ya que en todo instante las transacciones definen un grafo de espera dirigido.

33. Manejo de Abrazo Mortal En el grafo: Todas las transacciones son los nodos del grafo. Existe un arco de una transacción T a otra transacción T’ si: • T esta esperando por un objeto mantenido por T’ • T eventualmente esperara por un objeto que le será asignado a T’. Ambas esperan por el mismo objeto, y T está después de T’ en la lista de espera. Un ciclo en el grafo de espera es llamado un AM. Entonces la detección de AM consiste en buscar ciclos en el grafo de espera.

34. Manejo de Abrazo Mortal En BDD el grafo de espera está distribuido porque las transacciones están distribuidas. Cada nodo mantiene un fragmento local de la lista de transacciones que están en espera -> las transacciones de ese nodo que están esperando. Cada nodo con un grafo de espera apuntando a una transacción ubicada en otro nodo hace una traza desde el inicio del grafo hasta ese nodo, esta traza es enviada al segundo nodo. El segundo nodo agrega ese eje y realiza lo mismo. Si existen ciclos, uno o más nodos en la vía del ciclo lo encontraran.

35. Manejo de Abrazo Mortal Una vez encontrado el AM este debe ser solucionado -> Encontrar el conjunto de transacciones que tengan el log más corto y romper todos los ciclos. El problema de este algoritmo es pueden detectarse ciclos causados por arcos que ya no existan, ya que no es posible obtener una imagen consistente del mismo porque el grafo de espera está constantemente cambiando.

36. Control de Concurrencia en Transacciones Anidadas • Una hoja puede obtener un bloqueo sobre un objeto, si el objeto esta libre o todas las transacciones que posean bloqueo sobre dicho objeto son sus ancestros. En caso contrario debe esperar. • Cuando una subtransacción abandona sus bloqueos son liberados. Los ancestros que lo posean lo seguirán manteniendo. • Cuando una subtransacción valida su bloqueos son heredados por su madre. • Cuando una transacción raíz valida los bloqueos que haya heredado serán liberados. • Una vez que una transacción obtiene un bloqueo, no puede liberarlo antes de terminar. Varias transacciones pueden poseer el bloqueo sobre un objeto al mismo tiempo pero SOLO UNA lo posee por demanda.

37. TA TA1 TA2 TA11 TA12 TA21 TA22 TA23 TA224 TA221 TA222 TA223 Control de Concurrencia en Transacciones Anidadas TA12 solicita c (ok) TA221 solicita a (ok) TA224 solicita b (ok) TA11 solicita b (espera) TA224 solicita a (espera) TA222 solicita c (espera) TA221 termina (TA22 hereda a) TA224 obtiene a TA224 obtiene a TA224 termina (TA22 hereda a y b) TA22 termina (TA2 hereda a y b) TA2 termina (TA hereda a y b) TA11 obtiene b

38. Control de Concurrencia en Transacciones Anidadas TA TA1 TA2 TA11 TA224 TA11 TA12 TA21 TA22 TA23 TA224 TA221 TA222 TA12 TA224 TA221 TA222 TA223 Grafo de Espera Grafo de Espera Completo