Control de Concurrencia

Lic. Brbara da Silva Sistemas de Bases de Datos Distribuidas - UCV

Esquema de la Clase
Caracterizacin de una Transaccin Formalizacin del concepto de transaccin Discusin Tarea Control de Concurrencia Teora 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

Caracterizacin de una Transaccin

Una transaccin lee y escribe data. Entonces: RS = Conjunto de elementos de datos de la BD leidos por una transaccin. WS = Conjunto de elementos de datos escritos por una transaccin.

Por tanto el conjunto base de una transaccin es: BS = RS U WS

Formalizacin del Concepto de Transaccin

Oij(x) = Una operacin Oj de la transaccin 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 condicin de terminacin para Ti. Ni {abort, commit}

Una transaccin Ti es un orden parcial sobre las operaciones y la condicin de terminacin. Ese orden parcial se denota como: Ti = {i, <i} Indica el orden de ejecucin (precede a)

Formalizacin del Concepto de Transaccin

1. i = Osi U {Ni}

2. 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
3. Oij Osi Oij <i Ni

Formalizacin del Concepto de Transaccin

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 Acclico (DAG) de T

R(x) W(y) R(y) C

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 anomalas: Se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos Pueden presentarse recuperaciones de informacin inconsistentes.

Teora 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 Si Si No

Schedule 1 x = 0; x = x+1; x = 0; x = x+2; x = 0; x = x+3; Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x+3; Schedule 3 x = 0; x = 0; x = x+1; x = 0; x = x+2; x = x+3;

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

Seriabilidad en BD Centralizadas
Dos transacciones Ti y Tj se ejecutan serialmente en una historia S si la ltima operacin de Ti precede la primera operacin 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 estn 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.

Seriabilidad en BD Centralizadas
Condicin 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

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 ejecucin de un conjunto de transacciones distribuidas.

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 ejecucin de las transacciones ya que Ti < Tj en S1 y Tj < Ti en S2.

Condicin de Seriabilidad en BDD

La ejecucin de transacciones T1, T2,...,Tn es correcta si:

1. Cada historia local Sk es serializable.

2. 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.

Condicin 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 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 condicin de seriabilidad

S3 = Tj Tk

Condicin de Seriabilidad en BDD

Proposicin:

Sean

T = {T1, T2, ..., Tn} un conjunto de transacciones E = {S1, S2,..., Sm} una ejecucin 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 slo permite ejecuciones correctas de transacciones distribuidas

Taxonoma de los mecanismos de control de concurrencia

Taxonoma de los mecanismos de control de concurrencia

Pesimistas: Sincronizan la ejecucin concurrente de las transacciones lo ms temprano posible. Optimista: Dejan la sincronizacin de las transaccin hasta su terminacin.

Mecanismo de Bloqueos
El mtodo de bloqueo es un mecanismo de serializacin que asegura que solo una transaccin accede a un objeto en cualquier momento. Cada recurso (objeto, dato) posee una llave.

Si una transaccin accede un dato, este debe ser bloqueado.

Si una transaccin quiere bloquear un dato ya bloqueado por otra transaccin, debe esperar hasta que la transaccin que lo posee lo libere.

Taxonoma 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.

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 adquisicin de recursos Fase de liberacin de recursos Existen dos mecanimos: - Two-Phase Locking - Strict Two-Phase Locking

Two-Phase Locking
Punto de bloqueo Nmero de bloqueos Adquisicin de Recursos Liberacin de Recursos

Tiempo

En la fase de liberacin se liberan los candados obtenidos uno por uno. Se pueden dar Abortos en Cascada porque si una transaccin aborta despus de liberar un recurso, otras transacciones que hayan accedido al mismo dato tambin van a abortar.

Strict Two-Phase Locking

Punto de bloqueo Nmero de bloqueos Adquisicin de Recursos Liberacin de Recursos

Tiempo

Se liberan todos los recursos cuando la transaccin termina (bien sea validando abortando)

Ordenamiento de Timestamps
A diferencia del mecanismo de bloqueo, no mantienen la seriabilidad por exclusin mutua. Seleccionan un orden de serializacin a priori y ejecutan las transacciones de acuerdo a ese orden. Cuando una transaccinTi se inicia, el TM le asigna un timeStamp nico ts(Ti). El timestamp debe ser nico y montono creciente. Cada manejador de transacciones asigna un timestamp basado en su contador local y el identificador del manejador de transacciones.

Ordenamiento de Timestamps
1. Bsico:

El TM asigna tambin un ts a las operaciones solicitadas por una transaccin. 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 ms grande para cualquier lectura y escritura de x respectivamente.
El ordenamiento de los ts se realiza segn 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 -> transaccin ms vieja y Tk -> transaccin ms joven.

Ordenamiento de Timestamps

Rechazar la operacin significa que la transaccin que la envi necesita reiniciarse para obtener el ts ms reciente del dato e intentar hacer nuevamente la operacin sobre el mismo.

Ordenamiento de Timestamps
1. Conservador:

Se retrasan las operaciones de la transaccin hasta que un orden de ejecucin 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 asignndole un timestamp.
Cuando est seguro de que ninguna otra operacin 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.

Ordenamiento de Timestamps
1. Multiversin:

Cada operacin de escritura crea una nueva versin del item de dato. Esta versin es marcada con el ts de la transaccin que la cre.

Algoritmos Optimistas
Pesimistas: Validacin -> lectura -> clculo -> escritura Optimistas: Lectura -> clculo -> validacin -> escritura Las operaciones nunca son retardadas. Cada transaccin hace sus actualizaciones sobre copias de elementos de datos locales. La fase de validacin consiste en chequear si las actualizaciones pueden mantener la consistencia de la BD. Si la mantienen se realizan los cambios sino la transaccin es abandonada y reiniciada.

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 algn elemento del conjunto termine. Una solucin es nunca esperar sino cancelar cualquier requerimiento que pueda hacer esperar, abandonar y reiniciar el programa. Problema: Se puede crear una situacin de vivir-bloqueado.

Manejo de Abrazo Mortal

rpidamente querer esperar por otro miembro del conjunto, resultando en otro abandono y re-inicio. VB es una situacin peor que el AM debido a que es ms difcil de detectar ya que esta gasta recursos. Otra tcnica es Evitar el Abrazo Mortal: se ordenan linealmente los recursos y se deben adquirir los mismos en ese orden.

Vivir-bloqueado (VB): cada miembro del conjunto puede

Un AM requiere un ciclo en el grafo de espera de las transacciones. Un orden lineal (o cualquier orden parcial) evita tales ciclos.

Manejo de Abrazo Mortal

Tambin se puede Detectar el AM:

Cmo lo detecta? Timeout -> Cuando una transaccin espera ms 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 tcnica es detectarlo a travs de un grafo de espera, ya que en todo instante las transacciones definen un grafo de espera dirigido.

Manejo de Abrazo Mortal

En el grafo:

Todas las transacciones son los nodos del grafo. Existe un arco de una transaccin T a otra transaccin 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 despus de T en la lista de espera.
Un ciclo en el grafo de espera es llamado un AM. Entonces la deteccin de AM consiste en buscar ciclos en el grafo de espera.

Manejo de Abrazo Mortal

En BDD el grafo de espera est distribuido porque las transacciones estn distribuidas. Cada nodo mantiene un fragmento local de la lista de transacciones que estn en espera -> las transacciones de ese nodo que estn esperando. Cada nodo con un grafo de espera apuntando a una transaccin 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 ms nodos en la va del ciclo lo encontraran.

Manejo de Abrazo Mortal

Una vez encontrado el AM este debe ser solucionado -> Encontrar el conjunto de transacciones que tengan el log ms 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.

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 subtransaccin abandona sus bloqueos son liberados. Los ancestros que lo posean lo seguirn manteniendo. Cuando una subtransaccin valida su bloqueos son heredados por su madre. Cuando una transaccin raz valida los bloqueos que haya heredado sern liberados. Una vez que una transaccin 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.

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

TA

TA1
TA11 TA12 TA21

TA2
TA22 TA23

TA221

TA222

TA223

TA224

Control de Concurrencia en Transacciones Anidadas

TA

TA11 TA224 TA222

TA224 TA221 TA12

TA11

TA1 TA12 TA221 TA21 TA222

TA2 TA22 TA223 TA23 TA224

Grafo de Espera

Grafo de Espera Completo