Departamento de Lenguajes y Sistemas Informticos

Avda Reina Mercedes s/n. 41012 Sevilla Tlf/Fax 954 557 139 E-mail lsi@lsi.us.es www.lsi.us.es
E.T.S. Ingeniera Informtica

Diseo de Bases de Datos Concurrencia

Sevilla, octubre 2004 V 2004.02.1

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

INTRODUCCIN AL PROBLEMA .........................................................................................................................................3

1.1 1.2
2

CONSISTENCIA DE LA BD ...................................................................................................... 3 PROBLEMAS DE CONCURRENCIA ........................................................................................... 3 DEFINICIONES ...................................................................................................................... 4 PLANES SERIALIZABLES ......................................................................................................... 4 RELACIN DE PRECEDENCIA ENTRE TRANSACCIONES. ........................................................ 5

EJECUCIONES LIBRES DE CONFLICTOS...........................................................................................................................4

2.1 2.2 2.3

3

PROTOCOLO DE BLOQUEO EN DOS-FASES (TWO-PHASE LOCKING PROTOCOL)..................................................6

3.1 ESTRUCTURAS DE DATOS ....................................................................................................... 6 3.2 DEFINICIONES ...................................................................................................................... 6 3.3 ALGORITMO DE BLOQUEO EN DOS-FASES .............................................................................. 7 3.3.1 Correccin de algoritmo......................................................................................................................... 9 3.4 EL ABRAZO MORTAL (DEADLOCK) ....................................................................................... 10 3.4.1 Concepto de abrazo mortal ................................................................................................................. 10 3.4.2 Tratamiento de situaciones de abrazo mortal ................................................................................... 10
4 ALGORITMOS DE ORDENACIN POR TIMESTAMP...................................................................................................... 13

4.1 4.2 4.3 4.4

5

DEFINICIONES .................................................................................................................... 13 ALGORITMOS DE ORDENACIN POR TIMESTAMP TOTAL. .................................................... 13 ALGORITMOS DE ORDENACIN POR TIMESTAMP PARCIAL................................................... 14 ALGORITMOS DE ORDENACIN POR TIMESTAMP MULTIVERSIN. ...................................... 15

ALGORITMOS OPTIMISTAS................................................................................................................................................. 17

Pg. 2 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

1 Introduccin al problema
1.1 Consistencia de la BD
Un esquema de BD incluye la descripcin de los datos y las restricciones de integridad. Las restricciones de integridad (RI) son consistentes en s mismas si no incluyen contradicciones desde el punto de vista semntico. Un estado de la BD es consistente si las RI son consistentes en s mismas y dicho estado no viola las RI (satisface las RI: E=RI(E))

1.2 Problemas de concurrencia

El propsito del control de concurrencia es mantener la consistencia de la BD cuando sta es actualizada por mltiples usuarios. Existen casos en los que las transacciones ejecutadas aisladamente originan nuevos estados consistentes, sin embargo las mismas transacciones ejecutadas concurrentemente pueden originar efectos como prdidas de operaciones y/o violacin de restricciones de integridad; a continuacin se ilustran algunos casos tpicos de anomalas.

Transaccin T1
LEER x1 X

Transaccin T2

Transaccin T1
LEER x1 X IMPRIMIR x1

Transaccin T2

LEER x2 X x2 1 + x2 ESCRIBIR X x2 x1 1 + x1 ESCRIBIR X x1

LEER x2 X x2 1 + x2 ESCRIBIR X x2 LEER x1 X IMPRIMIR x1

Fig. 1. Prdida de operaciones.

Fig. 2. No reproduccin de lecturas.

Transaccin T1
LEER a1 A a 1 1 + a1 ESCRIBIR A a1

Transaccin T2

Transaccin T1
LEER a1 A a 1 1 + a1 ESCRIBIR A a1

Transaccin T2

A=B

A=B

LEER a2 A IMPRIMIR a2 LEER b2 B IMPRIMIR b2 LEER b1 B b1 1 + b1 ESCRIBIR B b1

LEER a2 A a2 2.a2 ESCRIBIR A a2 LEER b2 B b2 2.b2 ESCRIBIR B b2 LEER b1 B b1 1 + b1 ESCRIBIR B b1

Fig. 3. Salidas inconsistentes.

Fig. 4. Introduccin de inconsistencias en la BD.

Pg. 3 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Ejecuciones libres de conflictos

2.1 Definiciones
Es conveniente definir previamente una serie de conceptos bsicos: Grnulo. Unidad de datos controlada individualmente por el subsistema de concurrencia. Accin. Transaccin. Primitiva unitaria de manipulacin de un grnulo tal que ejecutada individualmente por un usuario forzara la integridad del grnulo. Secuencia de acciones T{a1, a2 .. an} ejecutadas por un usuario de modo que se respeta la consistencia de la BD; puede verse como una secuencia de transformaciones tal que si S es un estado consistente (S I), entonces :

T ( S) =an an-1 ...a2 ( a1 ( S) ) ; T(S) I,

Plan de ejecucin de un conjunto de transacciones (Schedule). Plan serial. Sea {T1, T2 .. Tn} un conjunto de transacciones; un plan de ejecucin (schedule) ser una secuencia de acciones de T1, T2 .. Tn respetando el orden de ejecucin en cada transaccin. Un Plan S de {T1, T2 .. Tn} es serial si existe una permutacin de {1, 2, n} tal que S = < T 1, T2 .. Tn > Plan serializable. Acciones permutables. Un Plan S de {T1, T2 .. Tn} es serializable si tras su ejecucin se alcanza el mismo estado final que con un plan serial de {T1, T2 .. Tn} Dos acciones ai y aj son permutables si es indiferente su orden de ejecucin en lo relativo a la consistencia de la BD, es decir si E es un estado consistente: ai ( aj ( E ) ) = aj ( ai ( E ) ) . p. ej. dos lecturas sobre el mismo grnulo; una lectura y escritura sobre grnulos distintos. En general las lecturas y escrituras sobre el mismo grnulo no son permutables.

( (

))

2.2 Planes serializables

Una condicin suficiente para que un plan S sea serializable es que pueda ser transformado mediante permutacin de acciones permutables en un plan serial Justificacin. Por definicin de accin permutable, el resultado ser el mismo tras cada permutacin de acciones; si al final se alcanza un plan serial que origina el mismo estado final (con una permutacin serial) se habr conseguido demostrar que es serializable. El plan S1 es serializable ya que las acciones ESCRIBIR A a2 y ESCRIBIR B b1 son permutables por tratarse de distintos grnulos; reordenando relativamente a las transacciones los bloque de operaciones se obtendra el plan S1 que es un plan serial, luego S1 es serializable. Pg. 4 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Transaccin T1

Transaccin T2

Transaccin T1

Transaccin T2

A=B
LEER a1 A a 1 1 + a1 ESCRIBIR A a1 LEER a2 A a2 2.a2 ESCRIBIR A a2 LEER b1 B b1 1 + b1 ESCRIBIR B b1 LEER b2 B B2 2.b2 ESCRIBIR B b2

A=B
LEER a1 A a 1 1 + a1 ESCRIBIR A a1 LEER b1 B b1 1 + b1 ESCRIBIR B b1

LEER a2 A a2 2. a2 ESCRIBIR A a2 LEER b2 B b2 2. b2 ESCRIBIR B b2

Fig. 5. Plan S1.

Fig. 6. Plan S1 serial tras la permutacin.

2.3 Relacin de precedencia entre transacciones.

Precedencia. Grafo de Precedencia. Ti precede a Tj en S{T1, T2 .. Tn} si existen dos acciones no-permutables ai y aj tales que ai es ejecutada por Ti antes que Tj ejecute aj; se expresa Ti < Tj. Grafo orientado cuyos nodos son transacciones y un arco de Ti a Tj denota la relacin de precedencia Ti < Tj .

La condicin suficiente anterior puede expresarse como Es condicin suficiente para que un plan S sea serializable que su grafo de precedencia no incluya ciclos. Justificacin. Sea un plan S con un grafo Gs sin ciclos; este grafo representa las relaciones de precedencia que se deben a operaciones no permutables; es posible definir un orden parcial de transacciones asociado a Gs <Ti1, T i2, .. Tin> y reordenar el resto de operaciones permutables con arreglo a l; este orden parcial puede dar lugar a un orden total de transacciones originando una permutacin serial de transacciones, con lo cual S sera serializable.

Pg. 5 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

3 Protocolo de bloqueo en dos-fases (two-phase locking protocol)

Corresponde a una de las orientaciones, la clsica, para afrontar la problemtica originada por la concurrencia de transacciones.

3.1 Estructuras de datos

Matriz de compatibilidad. Matriz cuadrada C=[Cij] donde Cij = 1 si el modo-i1 es compatible con el modo-j y Cij = 0 en caso contrario. p. ej. Si m1=lectura y m2=actualizacin: C = 1 0 0 0 Para cada grnulo g se considera el vector de bits A(g) donde aj = 1 si g est bloqueado en modo mj por alguna transaccin.

Tablas de bloqueos.
a1 . A(g) = a j . ak m1 . M p = mj . mk

Por otro lado asociado a un grnulo, puede considerarse el vector Mp donde consten todas las peticiones de bloqueos BLOQUEO(Tp, Mp, g) solicitadas por la transaccin Tp; en l mj=1 si se ha solicitado el modo Mj sobre el grnulo g.

3.2 Definiciones
Modo de operacin. Propiedad que caracteriza a una operacin de manipulacin de datos, determinando su compatibilidad con otras operaciones. p. ej. Son modos lectura, insercin, actualizacin, eliminacin, lectura protegida, etc.

BLOQUEO(Tp, Mp, g)

Especificacin al gestor de tareas de que la transaccin Tp efecte sobre un grnulo g una operacin en modo Mp; cuando se admita, el gestor de tareas bloquear (reservar) g en modo Mp. DESBLOQUEO(Tp,Mp,g) Especificacin al gestor de tareas de la peticin de la transaccin Tp de liberacin del granulo g. Se desbloquear del modo Mp. Pueden considerarse los operadores Booleanos: negacin de un vector Booleano, interseccin de dos vectores, unin de dos vectores, inclusin de vectores, y el producto de matrices lgicas ( ) donde la multiplicacin se sustituye por la interseccin lgica y la suma por la unin lgica.

Modo de operacin: Propiedad que caracteriza a una operacin de manipulacin de datos, determinando su compatibilidad con otras operaciones. p. ej. Son modos lectura, insercin, actualizacin, eliminacin, lectura protegida, etc.

Pg. 6 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Es posible afirmar que los modos de operacin solicitados durante una operacin primitiva BLOQUEO(Tp,Mp,g) ejecutadas por una transaccin Tp son compatibles con los modos de bloqueo activos sobre un grnulo g debidos a otras transacciones si se cumple ( C A( g ) ) Mp Justificacin: A( g )
C A( g )

Es un vector de bits cuyo bit i = 1 si g est bloqueado en modo mj por alguna transaccin. Es un vector de bits cuyo bit i = 1 si Mj es incompatible con cualquier otro modo de operacin en el que g est bloqueado por alguna transaccin.

( C A( g )

Ser lo contrario de lo anterior, conteniendo 1s todos los modos de operacin compatibles con los modos de bloqueo solicitados por la transaccin.

Entonces cualquier vector M incluido en el anterior corresponder a la combinacin de modos admisibles por el grnulo g en el estado en que se encuentra antes de que Tp solicite sus peticiones de bloqueo. Cuando los modos solicitados no son compatibles se generar una cola de espera Q(g) sobre el grnulo g (grnulo ocupado) de transacciones en espera hasta que dicho grnulo quede disponible; esta cola estar ordenada normalmente por esquemas de prioridades de transacciones o en su defecto por orden de llegada. A la cola se le asociar el vector M y el identificador de cada transaccin <i, M>.

3.3 Algoritmo de bloqueo en dos-fases

Bloqueo(Tj1,Mj1,g)

Bloqueo(Tjs,Mjs,g)
Desbloqueo(Tp,Mp,g,) Bloqueo ganado A(g) =

Bloqueo(Tp,Mp,g)

Espera Q(g)

j Bloqueo(Tj,Mj, g)
,

Bloqueo(Tq1,Mq1, g) . . Bloqueo (Tqr, Mqr, g)

Fig. 7. Situacin de peticiones de bloque y desbloqueo.

Pg. 7 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

A continuacin se especifican las primitivas de bloqueo y desbloqueo implcitas en las operaciones de manipulacin de la base de datos en funcin de los modos de bloqueo asociados a cada operacin (lectura, actualizacin, eliminacin, etc.). Las primitivas se activarn al recibir peticiones de una transaccin Tp.

Sea V 0 un vector de bits con todos los componentes a cero. Se utilizar para inicializar la tabla de bloqueos del grnulo A(g). BLOQUEO (Tp, Mp, g ) Si A( g ) / A( g ) = V 0; Si Mp ( C A( g ) A( g ) =A( g ) Mp

'El vector de bloqueo solicitado es compatible 'Se aade (suma booleana de vectores) Mp al estado de bloqueo del grnulo; 'Tp gana bloqueo 'Se aade Tp , Mp a la cola de espera Q(g) del grnulo; Tp queda en espera

sino Q( g ) =Q( g ) Mp; FIN BLOQUEO ()

Fig. 8. Algoritmo de bloqueo en dos fases. Procedimiento BLOQUEO

DESBLOQUEO (Tp , Mp , g ) A ( g ) = M j
j p

Para c ada (T q , M q ) Q ( g ) Si M q ( C A ( g ) A( g ) =A( g ) M q Q ( g ) = Q ( g ) M q;

'El vector de bloqueo T q es ahora compatible 'Se aade M q al estado de bloqueo del grnulo ; T q gana bloqueo 'T q sale del estado de espera

FIN DESBLOQU EO ()
Fig. 9. Algoritmo de bloqueo en dos fases. Procedimiento DESBLOQUEO

Generalmente, al final de una transaccin se provocar el desbloqueo de todos los grnulos accedidos. La implementacin de stas dos acciones puede ser automtica (responsabilidad del SGBD) o bien explcita en las transacciones, incluyndose como sentencias en las interfases con el DBMS de los lenguajes de programacin.

Pg. 8 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

3.3.1

Correccin de algoritmo Transaccin que bloquea en los modos correctos de operacin todos los grnulos accedidos antes de una operacin sobre ellos y los desbloquea despus de dicha operacin. Transaccin bien formada que no ejecuta un BLOQUEO despus de haber ejecutado un DESBLOQUEO.

Transaccin bien formada Transaccin en dos fases

Pueden formularse las siguientes reglas asociadas al protocolo de bloqueo en dos fases: R1 R2 R3 Cada transaccin debe ejecutar un BLOQUEO con los modos de operacin correctos sobre los grnulos a acceder antes de ejecutar una operacin sobre dichos grnulos. Cada transaccin debe ejecutar un DESBLOQUEO sobre los grnulos bloqueados despus de operar sobre ellos. Una transaccin no puede ejecutar un BLOQUEO despus de emitir un DESBLOQUEO .

N de grnulos bloqueados

El nmero de grnulos bloqueados crece en la primera fase hasta un mximo y en la segunda fase decrece hasta la liberacin si la transaccin termina con xito.
1 FASE Comienzo Tp 2 FASE Fin Tp

Fig. 10. Escalada de bloqueos

En estas condiciones Cada plan de una transaccin bien formada en dos-fases es serializable. Justificacin . Sea {T1, T2, ..Tn} un conjunto de transacciones en dos fases; asumiendo la existencia de un circuito en su grafo de precedencia Ti1 < Ti2 < < Tin < Ti1 puede afirmarse que : Ti2 bloquea el granulo gi1 despus de que Ti1 lo desbloquea. Ti3 bloquea el granulo gi2 despus de que Ti2 lo desbloquea. . . Ti1 bloquea el granulo gin despus de que Tin lo desbloquea. ya que cada transaccin es en dos-fases desbloquearn slo despus de que han completado todos sus BLOQUEOS, luego Ti1 desbloquea gi1 antes de ejecutar el BLOQUEO sobre gin luego Ti1 no es en dosfases, lo que contradice la hiptesis inicial. Pg. 9 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

3.4 El abrazo mortal (deadlock)

3.4.1 Concepto de abrazo mortal Este problema se presenta cuando los grnulos se han bloqueado en una secuencia tal que un grupo de transacciones no pueden ser despachadas porque hay transacciones que se esperan mutuamente. Situacin de abrazo mortal Situacin en que un grupo de transacciones satisface las siguientes propiedades: Cada transaccin del grupo est bloqueada esperando un grnulo. La terminacin de cada transaccin que no pertenece al grupo no permite a cualquier transaccin del grupo entrar en desbloqueo (ser despachada por el plan).

T1 Bloqueo(g1,upd)

T2 g2,upd Bloqueo (g2,upd) T1 g1,upd g1, prot_leer g2,upd T2

Bloqueo (g2,upd) Bloqueo (g1,prot_leer)

Fig. 11. Situacin de abrazo mortal

Grafo de espera. Grafo G(T, W) donde T es un conjunto de transacciones activas {T1, T2, ..Tn} compartiendo grnulos {G1, G2, ..Gm} y W es la relacin de espera definida como sigue: Tp espera a Tq si Tp demanda el bloqueo de un grnulo Gi y dicha operacin no puede realizarse porque Gi est bloqueada por Tq. 3.4.2 Tratamiento de situaciones de abrazo mortal Existen dos enfoques de tratamiento de la situacin: prevencin y deteccin.

Prevencin del abrazo mortal Consiste en evitar una de las situaciones que fuerzan la situacin cuando se disea el algoritmo de control de concurrencia. Una posibilidad es la ordenacin previa de transacciones usando timestamp2; se conocen dos enfoques DIE-WAIT y WOUND-WAIT.

DIE-WAIT. Solo la transaccin ms vieja puede esperar por una transaccin ms joven (con mayor timestamp de inicio); es decir Ti espera por Tj si i < j y se aborta en otros casos (muere la transaccin ms joven). Cuando una transaccin muere, se reinicia con el mismo timestamp; as tarde o temprano pasar a ser la transaccin activa ms vieja y por tanto no morir. Esto garantiza la ausencia de circuitos en un grafo de espera y en el entorno de BD de rollback permanente.

Identificador cronolgico de una transaccin (contador, reloj del sistema, etc.)

Pg. 10 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

WOUND-WAIT. Es el inverso del mtodo anterior; en este caso, slo una transaccin ms joven puede esperar por una transaccin ms vieja: Ti espera por Tj si i > j. Para evitar el rollback permanente, la transaccin que solicita el BLOQUEO de un grnulo bloqueado por una transaccin ms joven, la transaccin ms vieja remplaza a la ms joven que se aborta; as si Ti solicita BLOQUEO de un grnulo g bloqueado por Tj; Tj se mata si i<j y conseguir Ti el BLOQUEO.

Deteccin del abrazo mortal Se presentar un mtodo que comprueba en un grafo de espera la existencia de circuitos, eliminando sucesivamente los vrtices terminales. En un grafo de espera un vrtice es terminal si la transaccin que representa no est esperando para bloquear ningn grnulo. Sea N(k) el nmero de grnulos que la transaccin Tk est esperando bloquear; una reduccin inicial del grafo puede consistir en eliminar aquellos vrtices donde N(k)=0 y a continuacin recalcular los valores de N(k) para la siguiente iteracin, contando las solicitudes que pueden ser satisfechas despus de cada reduccin y decrementando N(k) para cada solicitud de Tk. Este mtodo tiene dos requerimientos especiales: Es necesario marcar las peticiones en un orden tal que no se cuenten ms de una vez Hay que utilizar un procedimiento para comprobar si una peticin es satisfecha, contabilizando los estados de bloqueo de las transacciones que todava no han sido eliminadas del grafo de espera.

N(1)=1 T1 g1 g2 T2

N(2)=3 T4 g3

N(4)=0

g5

T3 T5 N(3)=1 g4

N(5)=0

N(1)=1 T1 g1 g2 T2

N(2)=1

g5

T3 N(3)=1

Fig. 12. Deteccin del abrazo mortal en un grafo de espera.

Pg. 11 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Sea BLOQUEO-TENTATIVO (Gi,R,K) un procedimiento Booleano que comprueba si la peticin R de la transaccin Tk sobre el grnulo Gi puede ser satisfecha, contabilizando el bloqueo de grnulos realizados por transacciones Tj tales que N(j) 0 (transacciones todava en espera). Este procedimiento devolver true si la peticin puede ser satisfecha y false en caso contrario. El procedimiento es similar al procedimiento del BLOQUEO excepto que no se modificarn los estados de bloqueos de transacciones. Cuando se detecta un abrazo mortal el problema consistir en seleccionar una transaccin a reiniciar. El algoritmo presenta la lista de transacciones en la situacin. Una posible solucin es reiniciar la transaccin involucrada en la situacin que bloquea el mayor nmero de otras transacciones; corresponder a vrtices que tienen un gran nmero de arcos entrantes en le grafo de espera. Para reducir el coste de la deteccin, este algoritmo puede ser invocado slo cuando una transaccin ha estado en espera durante un tiempo lmite (unos pocos segundos); con esto ltimo, el enfoque de deteccin puede ser una solucin aceptable al abrazo mortal; extensible incluso a sistemas distribuidos.

DETECCIN() T:= {Tj tales que N(j) 0} L:= {grnulos bloqueados por Ts T} Para cada G L Para cada peticin R no-marcada de Tk esperando Gi Si BLOQUEO-TENTATIVO(Gi,R,K) = true marcar R N(K) = N(K) 1 Si N(K) = 0 Eliminar Tk de T Aadir los grnulos bloqueados de Tk a L ; Si T= DETECCIN := false sino DETECCIN := true ; FIN DETECCIN();
Fig. 13. Algoritmo de deteccin de abrazo mortal.

Pg. 12 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

4 Algoritmos de ordenacin por TIMESTAMP.

4.1 Definiciones
Se engloban bajo este ttulo una serie de algoritmos que evitan la produccin de planes no-serializables asegurando que las peticiones conflictivas sobre grnulos tienen lugar en las transacciones en un orden determinado. Para controlar el ordenamiento de operaciones se utiliza un identificador nico asociado a cada transaccin: el timestamp de transaccin. Timestamp de transaccin Valor numrico asociado a una transaccin que permite que sean ordenadas respecto a otras transacciones. Es normal utilizar contadores generados por un sistema central o bien el propio reloj del sistema. Variable numrica asociada a un grnulo que almacena el timestamp de la ltima transaccin que oper sobre dicho grnulo. Pueden distinguirse timestamp de grnulos asociados a distintos modos de operacin (lectura, escritura), funcin de las transacciones que accedieron al grnulo en dicho modo.

Timestamp de grnulo

4.2 Algoritmos de ordenacin por timestamp total.

Consiste en la verificacin de que el acceso transaccional a los grnulos se realiza en el orden asignado por el timestamp de dichas transacciones. Para dos transacciones Ti con timestamp i y Tj con timestamp j tal que i<j que operan sobre el mismo grnulo, el gestor de tareas asegurar que Ti precede a Tj; no se distinguen modos de operacin pero, sin embargo, puede implementase slo con un tipo de timestamp de grnulo. LEER (Ti:transaccin, g:grnulo) Si S(g) i realizar lectura S(g) := i sino ABORTAR; FIN LEER(); ESCRIBIR (Ti:transaccin, g:grnulo) Si S(g) i realizar escritura S(g) := i sino ABORTAR; FIN ESCRIBIR ();
Fig. 14. Algoritmo de ordenacin por timestamp total.

g es el grnulo accedido por Ti, S(g) es el timestamp del grnulo y ABORTAR es el procedimiento que cusa el rearranque de Ti o Tj. Puede haber un tratamiento diferente en funcin de qu transaccin se aborta (Ti :solicita el grnulo o Tj :tiene el grnulo); en el primer caso Ti debe ser reiniciada con un nuevo timestamp de transaccin i > j, con lo que se eliminar el conflicto con Tj; de cualquier modo, ahora Ti(i=i) podra entrar en conflicto con una nueva transaccin Tj , y as sucesivamente. En el segundo caso Tj debe reiniciarse con el mismo timestamp; un rearranque de Tj requerir la restauracin de todos los grnulos accedidos por ella.

Pg. 13 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Puede darse una situacin conflictiva conocida como efecto domin, que sucede cuando las actualizaciones de Tj fueron ledas por otras transacciones; estas transacciones deben ser reiniciadas, es decir, abortar Tj puede generar una situacin donde una actualizacin realizada por Tj es deshecha mientras que su efecto fue visible por una transaccin Tk, lo cual puede requerir que tambin se aborte Tk, pudiendo generarse esta situacin en cadena. Esta situacin se resuelve provocando una ordenacin de los COMMIT s de las transacciones de acuerdo con el timestamp de las mismas.

4.3 Algoritmos de ordenacin por timestamp parcial.

Este algoritmo tiene en cuenta las secuencias de operaciones permutables, verificando que <LEER,ESCRIBIR> < ESCRIBIR,LEER > y < ESCRIBIR,ESCRIBIR> se realizan en el orden prefijado por los timestamps. Se utilizan dos tipos de timestamp de grnulos: SR, timestamp de lectura de la transaccin ms reciente que efectu una lectura y SW, timestamp de escritura del grnulo. Cuando una transaccin ejecuta un LEER, el gestor de tareas controla la secuencia correcta de la lectura respecto de la ltima escritura (el timestamp de lectura de la transaccin debe ser mayor que el valor del timestamp de escritura del grnulo), p.ej. si un grnulo ha sido actualizado por T2, se tendr SW=2 ; si ha sido ledo por la transaccin ms joven T7 ser SR=7; en esta situacin cualquier transaccin con timestamp igual o mayor que 2 podr leer sin problemas. Si una transaccin ejecuta un ESCRIBIR, el gestor de tareas comprobar la correcta secuencia de la operacin respecto a los LEER y ESCRIBIR previos. As el timestamp de escritura de las transacciones debe ser igual o mayor que el valor del timestamp de escritura y que el timestamp de lectura dicho grnulo. En el ejemplo anterior, slo las transacciones con timestamp igual o mayor que 7 podrn escribir el grnulo. Este algoritmo propicia tambin el efecto domin aunque abortara menos transacciones que el de ordenacin por timestamp total. LEER (Ti:transaccin, g:grnulo) Si SW(g) i realizar lectura SR(g) := MAX(SR(g),i) sino ABORTAR; FIN LEER (); ESCRIBIR (Ti:transaccin, g:grnulo) Si SW(g) i SR(g) i realizar escritura SW(g) := i sino ABORTAR; FIN ESCRIBIR ();
Fig. 15. Algoritmo de ordenacin por timestamp parcial.

Pg. 14 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

4.4 Algoritmos de ordenacin por timestamp multiversin.

La estrategia anterior puede ser mejorada preservando varias versiones del mismo grnulo. Para cada grnulo g, el sistema debera preservar un conjunto de timestamp de escritura del grnulo {SWi(g)} con los valores asociados del grnulo en dichas versiones {Vi(g)}, y del mismo modo un conjunto de timestamp de lectura del grnulo {SRi(g)}. As un grnulo versin i est definido por la tupla < SWi(g), SRi(g), Vi(g) >. Se crear una versin i para cada actualizacin del grnulo g efectuada por una transaccin Ti. Se propone el siguiente algoritmo para otorgar y crear versiones del mismo grnulo en memoria (buffer pool). LEER (Ti:transaccin, g:grnulo) j:= ndice de la ltima versin de g; Mientras SWj(g) > i j:= ndice de la versin previa de g; Fin Mientras; SRj(g) := MAX(SRj(g), i) FIN LEER()
realizar lectura previa de g versin j

ESCRIBIR (Ti:transaccin, g:grnulo) j:= ndice de la ltima versin de g; Mientras SWj (g) > i j:= ndice de la versin previa de g; Fin Mientras; Si SRj(g) > i ABORTAR sino FIN ESCRIBIR ()
Crear nueva versin i de g despus de la versin j ; Fig. 16. Algoritmo de ordenacin por timestamp multiversin.

Por ejemplo para un grnulo g que ha sido sucesivamente actualizado por T1, T5 y T10 y recuperado por transacciones T7 y T11 tendra la siguiente tabla de versiones: Grnulo g

Transaccin T1 T5 T7 T10 T11

Accin Escribir Escribir Leer Escribir Leer

SW 1 5 5 10 10

SR 1 5 7 10 11

Versin 1 5 5 10 10

Fig. 17.- Situacin inicial de versiones

De este modo es posible establecer el orden adecuado de operaciones de lectura respecto a operaciones de escritura sin tener que abortar ni reiniciar transacciones; para ello es suficiente con suministrar a una transaccin Ti que solicita una lectura del grnulo g con la versin cuyo timestamp de escritura del grnulo es inmediatamente inferior o igual a i.

Pg. 15 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

Si una transaccin Ti requiere una lectura del grnulo, se le suministrar la versin inmediatamente inferior. Para tratar las escrituras de una Ti se insertarn nuevas versiones creadas por las transacciones justo despus de encontrar un timestamp de escritura del grnulo inmediatamente ms bajo, Vi. Si, de cualquier modo, antes de las acciones de escritura de Ti, una transaccin Tk con timestamp k>i ha leido Vi, entonces alguna de las dos debe ser abortada (Ti o Tk ); es imposible escribir en el pasado (en el sentido de rehacer desde ese momento) sin rehacer sus consecuencias (este pasado fue visto por otras transacciones). De cualquier modo Tk puede ser abortada solo si no haba terminado; normalmente es preferible reiniciar Ti con un nuevo timestamp i (i>i) y as evitar rehacer el pasado que se confirm. Anlisis de casos de transacciones concurrentes Caso 1. T6 solicita el grnulo g en lectura. La tabla de versiones no se ve afectada por esta operacin, ya que se suministrara la versin 5 del grnulo cuyo timestamp de lectura es SR=7, mayor que 6 que es el timestamp de T6. Caso 2. T8 solicita el grnulo g en lectura. La tabla de versiones anterior se ve modificada, pues segn el algoritmo de lectura, hay que otorgar la versin 5, modificndose su timestamp de lectura, pues el valor anterior era SR=7 y se otorga a una transaccin con mayor timestamp. Despus de las dos acciones anteriores, la tabla de versiones quedara: Grnulo g Transaccin T6 T8 Accin Leer Leer SW 5 5 SR 7 8 Versin 5 5 darle la versin el timestamp de Hay que abortar slo si T7 no ha

Fig. 18.- Situacin de versiones despus de lecturas

Caso 3. T6 solicita una escritura sobre el grnulo g; en este caso corresponder inmediatamente anterior, versin 5 con timestamps SW=5, SR=7, cumplindose que lectura del grnulo es mayor (T7 vi esta versin) que el timestamp de la transaccin (T6). alguna transaccin en vuelo (T6 o T7 segn el algoritmo, pudiendo elegir entre las dos alcanzado el commit). Caso 3a. Se aborta T7 y se reinicia con el mismo timestamp Grnulo g Transaccin Accin SW SR T6 Escribir 6 6 T7 ABORT T7 Leer 6 7 Versin 6 6

Fig. 19.- Situacin de versiones al abortar la transaccin que ya haba ledo.

Caso 3b. Se aborta T6 y se reinicia con timestamp superior a la ltima versin existente. Grnulo g Transaccin Accin SW SR Versin T6 ABORT T12 antiguaT6 Restart T12 Escribir 12 12 12
Fig. 20.- Situacin de versiones al abortar la transaccin que solicita la escritura.

Pg. 16 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

5 Algoritmos optimistas.
Los algoritmos de ordenacin por timestamp verifican el correcto ordenamiento de las transacciones sobre cada acceso a los grnulos al igual que los algoritmos de bloqueo; estos dos tipos de algoritmos implementan un control a priori. Si el gestor de tareas se disea de modo que deje mayor libertad a las transacciones y realiza un control de las mismas, en vez de durante su ejecucin en tiempo de confirmacin de cambios a la BD se est barajando la idea bsica de los mtodos optimistas de control de concurrencia. Los algoritmos optimistas consideran que todas las transacciones preparan sus actualizaciones en buffers privados durante la ejecucin; al finalizar, antes de la confirmacin todas las actualizaciones deben sufrir un proceso de certificacin (o validacin). Certificacin. Accin especial que controla que la confirmacin de actualizaciones de una transaccin en la BD preserva la serializabilidad. Si la transaccin es certificada las actualizaciones preparadas se harn visibles a otras transacciones, y si falla la transaccin se abortar. En definitiva, con un control optimista de la concurrencia, una transaccin sufrir tres fases: fase de lectura, donde se preparan actualizaciones en reas de trabajo privadas de las transacciones, fase de certificacin y la posible fase de escritura.

Fase de LECTURA Ejecucin

Fig. 21. Fases de una transaccin

Fase de CERTIFICACION Validacin

Fase de ESCRITURA Confirmacin

El problema principal de estos mtodos es la eleccin del algoritmo de certificacin donde el orden de serializacin estar determinado por el orden de certificacin. En esta fase se deber comprobar que una transaccin validada Ti ha visto todas las modificaciones de las precedentes transacciones que tambin lo han sido; dicho de otro modo, todos los grnulos ledos por Ti no deben haber sido escritos por cualquier otra transaccin Tj certificada entre el comienzo de Ti y la certificacin de Tj. El algoritmo mantendr los conjuntos de timestamp de lectura y escritura de cada transaccin sobre los grnulos SR(Ti) y SW(Ti); se aceptar una validacin de Ti si SR(Ti) SW(Tj) = ,Tj certificada durante la fase de lectura de Ti . En la siguiente figura se propone un algoritmo de certificacin; ste puede rechazar una transaccin que no viola el orden de serializabilidad.

Pg. 17 de 18

Diseo de Bases de Datos

Sevilla, octubre 2004, V 2004.02.1

Concurrencia

INICIO_TRANSACCIN (Ti :transaccin) SR(Ti) := SW(Ti) := despus(Ti) := contador_certificacin FIN INICIO_TRANSACCIN () CERTIFICACIN (Ti :transaccin) Para t = despus (Ti) + 1 hasta contador _certificacin Si SR(Ti) SW(t) ABORTAR(Ti) ; FIN Para; Si No abortada Ti contador _certificacin := contador _certificacin + 1 CONFIRMACIN (Ti); FIN CERTIFICACIN () CONFIRMACIN (Ti :transaccin) Para cada g SW(Ti) ESCRIBIR (g); FIN CONFIRMACIN ()
Fig. 22. Algoritmo de certificacin.

As, el algoritmo de certificacin puede ser mejorado rechazando menos transacciones utilizando timestamp de grnulos. Los algoritmos de certificacin sufren el inconveniente de tener que deshacer al finalizar las transacciones, lo cual se puede agravar cuando, permanentemente, transacciones largas sufren a consecuencia de transacciones cortas. Puede afirmarse que los algoritmos optimistas son aceptables slo en el contexto de transacciones muy cortas con baja probabilidad de conflicto. Tambin se pueden considerar eficientes en conjuncin con algoritmos de recuperacin del tipo NO-UNDO.

Pg. 18 de 18