Departamento de Lenguajes y Sistemas Informáticos

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. Ingeniería
Informática

Diseño de Bases de Datos

Concurrencia

Sevilla, octubre 2004

V 2004.02.1
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

1 INTRODUCCIÓN AL PROBLEMA .........................................................................................................................................3

1.1 CONSISTENCIA DE LA BD ...................................................................................................... 3

1.2 PROBLEMAS DE CONCURRENCIA ........................................................................................... 3
2 EJECUCIONES LIBRES DE CONFLICTOS...........................................................................................................................4

2.1 DEFINICIONES ...................................................................................................................... 4

2.2 PLANES SERIALIZABLES ......................................................................................................... 4
2.3 RELACIÓN DE PRECEDENCIA ENTRE TRANSACCIONES. ........................................................ 5
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 Corrección 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 ORDENACIÓN POR TIMESTAMP...................................................................................................... 13

4.1 DEFINICIONES .................................................................................................................... 13

4.2 ALGORITMOS DE ORDENACIÓN POR TIMESTAMP TOTAL. .................................................... 13
4.3 ALGORITMOS DE ORDENACIÓN POR TIMESTAMP PARCIAL................................................... 14
4.4 ALGORITMOS DE ORDENACIÓN POR TIMESTAMP MULTIVERSIÓN. ...................................... 15
5 ALGORITMOS OPTIMISTAS................................................................................................................................................. 17

Pág. 2 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

1 Introducción al problema
1.1 Consistencia de la BD
Un esquema de BD incluye la descripción 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
semántico. 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 propósito del control de concurrencia es mantener la consistencia de la BD cuando ésta es actualizada
por múltiples 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 pérdidas de operaciones y/o violación de restricciones de integridad; a continuación se
ilustran algunos casos típicos de anomalías.

Transacción T1 Transacción T2 Transacción T1 Transacción T2

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

Fig. 1. – Pérdida de operaciones. Fig. 2. – No reproducción de lecturas.

Transacción T1 Transacción T2 Transacción T1 Transacción T2

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

Fig. 3. – Salidas inconsistentes. Fig. 4. – Introducción de inconsistencias en la BD.

Pág. 3 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

2 Ejecuciones libres de conflictos

2.1 Definiciones

Es conveniente definir previamente una serie de conceptos básicos:

Gránulo. Unidad de datos controlada individualmente por el subsistema de concurrencia.

Acción. Primitiva unitaria de manipulación de un gránulo tal que ejecutada individualmente

por un usuario forzaría la integridad del gránulo.

Transacción. 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 ejecución Sea {T1, T2 .. Tn} un conjunto de transacciones; un plan de ejecución (schedule) será
de un conjunto de una secuencia de acciones de T1, T2 .. Tn respetando el orden de ejecución en cada
transacciones transacción.
(Schedule).
Plan serial. Un Plan S de {T1, T2 .. Tn} es serial si existe una permutación ∏ de {1, 2, …n} tal
que S = < T ∏1, T∏2 .. T∏n >

Plan serializable. Un Plan S de {T1, T2 .. Tn} es serializable si tras su ejecución se alcanza el mismo
estado final que con un plan serial de {T1, T2 .. Tn}

Acciones Dos acciones ai y aj son permutables si es indiferente su orden de ejecución en lo

permutables. 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 gránulo; una lectura
y escritura sobre gránulos distintos. En general las lecturas y escrituras sobre el
mismo gránulo no son permutables.

2.2 Planes serializables

Una condición suficiente para que un plan S sea serializable es que pueda ser transformado mediante permutación de acciones
permutables en un plan serial

Justificación. Por definición de acción permutable, el resultado será el mismo tras cada permutación de
acciones; si al final se alcanza un plan serial que origina el mismo estado final (con una permutación 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 gránulos; reordenando relativamente a las transacciones los bloque de operaciones se
obtendría el plan S’1 que es un plan serial, luego S1 es serializable.
Pág. 4 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

Transacción T1 Transacción T2 Transacción T1 Transacción T2

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

Fig. 5. – Plan S1. Fig. 6. – Plan S’1 serial tras la permutación.

2.3 Relación de precedencia entre transacciones.

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 de Grafo orientado cuyos nodos son transacciones y un arco de Ti a Tj denota la

Precedencia. relación de precedencia Ti < Tj .

La condición suficiente anterior puede expresarse como “Es condición suficiente para que un plan S sea serializable
que su grafo de precedencia no incluya ciclos”.

Justificación. 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 permutación serial de transacciones, con
lo cual S sería serializable.

Pág. 5 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

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

Corresponde a una de las orientaciones, la clásica, para afrontar la problemática originada por la
concurrencia de transacciones.

3.1 Estructuras de datos

Matriz de Matriz cuadrada C=[Cij] donde Cij = 1 si el modo-i1 es compatible con el modo-j
compatibilidad. y Cij = 0 en caso contrario. p. ej. Si m1=lectura y m2=actualización:

C = 1 0 
0 0

Tablas de bloqueos.
 a1  Para cada gránulo g se considera el vector de bits A(g) donde aj = 1 si g está
.  bloqueado en modo mj por alguna transacción.
 
A(g) =  a j 
 
. 
 a k 
m1 Por otro lado asociado a un gránulo, puede considerarse el vector Mp donde
.  consten todas las peticiones de bloqueos BLOQUEO(Tp, Mp, g) solicitadas por la
  transacción Tp; en él mj=1 si se ha solicitado el modo Mj sobre el gránulo g.
M p = mj 
 
. 
 m k 

3.2 Definiciones

Modo de operación. Propiedad que caracteriza a una operación de manipulación de datos,

determinando su compatibilidad con otras operaciones. p. ej. Son modos
lectura, inserción, actualización, eliminación, lectura protegida, etc.

BLOQUEO(Tp, Mp, g) Especificación al gestor de tareas de que la transacción Tp efectúe sobre un

gránulo g una operación en modo Mp; cuando se admita, el gestor de tareas
bloqueará (reservará) g en modo Mp.
DESBLOQUEO(Tp,Mp,g) Especificación al gestor de tareas de la petición de la transacción Tp de
liberación del granulo g. Se desbloqueará del modo Mp.

Pueden considerarse los operadores Booleanos: ⌐ negación de un vector Booleano, ⋀ intersección de dos
vectores, ⋁ unión de dos vectores, ⊃ ⊇ inclusión de vectores, y el producto de matrices lógicas ( • )
donde la multiplicación se sustituye por la intersección lógica y la suma por la unión lógica.

1
Modo de operación: Propiedad que caracteriza a una operación de manipulación de datos, determinando su compatibilidad con
otras operaciones. p. ej. Son modos lectura, inserción, actualización, eliminación, lectura protegida, etc.

Pág. 6 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

Es posible afirmar que los modos de operación solicitados durante una operación primitiva
BLOQUEO(Tp,Mp,g) ejecutadas por una transacción Tp son compatibles con los modos de bloqueo activos
sobre un gránulo g debidos a otras transacciones si se cumple ¬ ( ¬C • A( g ) ) ⊇ Mp

Justificación:
A( g ) Es un vector de bits cuyo bit i = 1 si g está bloqueado en modo mj por alguna
transacción.

¬C • A( g ) Es un vector de bits cuyo bit i = 1 si Mj es incompatible con cualquier otro

modo de operación en el que g esté bloqueado por alguna transacción.

¬ ( ¬C • A( g ) ) Será lo contrario de lo anterior, conteniendo 1’s todos los modos de operación

compatibles con los modos de bloqueo solicitados por la transacción.

Entonces cualquier vector M incluido en el anterior corresponderá a la combinación de modos admisibles

por el gránulo 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 gránulo g
(gránulo ocupado) de transacciones en espera hasta que dicho gránulo 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 transacción <i, M>.

3.3 Algoritmo de bloqueo en dos-fases

Bloqueo(Tj1,Mj1,g)

Bloqueo(Tjs,Mjs,g) Bloqueo(Tp,Mp,g)
g

Desbloqueo(T’p,M’p,g,)

Bloqueo ganado Espera

A(g) = Q(g)

Bloqueo(Tq1,Mq1, g)
∨j Bloqueo(Tj,Mj, g) ,
.
. Bloqueo (Tqr, Mqr, g)

Fig. 7. – Situación de peticiones de bloque y desbloqueo.

Pág. 7 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

A continuación se especifican las primitivas de bloqueo y desbloqueo implícitas en las operaciones de

manipulación de la base de datos en función de los modos de bloqueo asociados a cada operación (lectura,
actualización, eliminación, etc.). Las primitivas se activarán al recibir peticiones de una transacción Tp.

Sea V 0 un vector de bits con todos los componentes a cero.

Se utilizará para inicializar la tabla de bloqueos del gránulo A(g).

BLOQUEO (Tp, Mp, g )

Si ∃/A( g )
A( g ) = V 0;
Si Mp ⊆ ¬ ( ¬C • A( g ) ) 'El vector de bloqueo solicitado es compatible
A( g ) =A( g ) ∨ Mp 'Se añade (suma booleana de vectores) Mp al estado de bloqueo del gránulo;
'Tp gana bloqueo
sino
Q( g ) =Q( g ) ∪ Mp; 'Se añade Tp , Mp a la cola de espera Q(g) del gránulo; Tp queda en espera
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 ) ) 'El vector de bloqueo T q es ahora compatible
A( g ) =A( g ) ∨ M q 'Se añade M q al estado de bloqueo del gránulo ; T q gana bloqueo
Q ( g ) = Q ( g ) − M q; '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 transacción se provocará el desbloqueo de todos los gránulos accedidos. La
implementación de éstas dos acciones puede ser automática (responsabilidad del SGBD) o bien explícita en
las transacciones, incluyéndose como sentencias en las interfases con el DBMS de los lenguajes de
programación.

Pág. 8 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

3.3.1 Corrección de algoritmo

Transacción bien Transacción que bloquea en los modos correctos de operación todos los
formada gránulos accedidos antes de una operación sobre ellos y los desbloquea
después de dicha operación.

Transacción en dos Transacción bien formada que no ejecuta un BLOQUEO después de haber
fases ejecutado un DESBLOQUEO.

Pueden formularse las siguientes reglas asociadas al protocolo de bloqueo en dos fases:

R1 Cada transacción debe ejecutar un BLOQUEO con los modos de operación correctos sobre los
gránulos a acceder antes de ejecutar una operación sobre dichos gránulos.

R2 Cada transacción debe ejecutar un DESBLOQUEO sobre los gránulos bloqueados después de
operar sobre ellos.

R3 Una transacción no puede ejecutar un BLOQUEO después de emitir un DESBLOQUEO .

Nº de
gránulos
bloqueados
El número de gránulos bloqueados crece en la
primera fase hasta un máximo y en la segunda fase
decrece hasta la liberación si la transacción termina
con éxito.

1ª FASE 2ª FASE t
Comienzo Tp Fin Tp

Fig. 10. – Escalada de bloqueos

En estas condiciones Cada plan de una transacción bien formada en dos-fases es serializable.
Justificación . 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 después de que Ti1 lo desbloquea.

Ti3 bloquea el granulo gi2 después de que Ti2 lo desbloquea.
.
.
Ti1 bloquea el granulo gin después de que Tin lo desbloquea.

ya que cada transacción es en dos-fases desbloquearán sólo después de que han completado todos sus
BLOQUEOS, luego Ti1 desbloquea gi1 antes de ejecutar el BLOQUEO sobre gin luego Ti1 no es en dos-
fases, lo que contradice la hipótesis inicial.

Pág. 9 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

3.4 El abrazo mortal (deadlock)

3.4.1 Concepto de abrazo mortal
Este problema se presenta cuando los gránulos se han bloqueado en una secuencia tal que un grupo de
transacciones no pueden ser despachadas porque hay transacciones que se esperan mutuamente.

Situación de abrazo Situación en que un grupo de transacciones satisface las siguientes

mortal propiedades:
• Cada transacción del grupo está bloqueada esperando un gránulo.
• La terminación de cada transacción que no pertenece al grupo no permite
a cualquier transacción del grupo entrar en desbloqueo (ser despachada
por el plan).

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

Fig. 11. – Situación de abrazo mortal

Grafo de espera. Grafo G(T, W) donde T es un conjunto de transacciones activas {T1, T2, ..Tn}
compartiendo gránulos {G1, G2, ..Gm} y W es la relación de “espera“ definida como sigue: Tp espera a Tq
si Tp demanda el bloqueo de un gránulo Gi y dicha operación 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 situación: prevención y detección.

• Prevención del abrazo mortal

Consiste en evitar una de las situaciones que fuerzan la situación cuando se diseña el algoritmo de
control de concurrencia. Una posibilidad es la ordenación previa de transacciones usando timestamp2;
se conocen dos enfoques DIE-WAIT y WOUND-WAIT.

• DIE-WAIT. Solo la transacción más vieja puede esperar por una transacción más joven (con mayor
timestamp de inicio); es decir Ti espera por Tj si i < j y se aborta en otros casos (muere la
transacción más joven). Cuando una transacción muere, se reinicia con el mismo timestamp; así
tarde o temprano pasará a ser la transacción activa más 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.

2 Identificador cronológico de una transacción (contador, reloj del sistema, etc.)

Pág. 10 de 18
Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

• WOUND-WAIT. Es el inverso del método anterior; en este caso, sólo una transacción más joven
puede esperar por una transacción más vieja: Ti espera por Tj si i > j. Para evitar el rollback
permanente, la transacción que solicita el BLOQUEO de un gránulo bloqueado por una transacción
más joven, la transacción más vieja remplaza a la más joven que se aborta; así si Ti solicita
BLOQUEO de un gránulo g bloqueado por Tj; Tj se mata si i<j y conseguirá Ti el BLOQUEO.

• Detección del abrazo mortal

Se presentará un método que comprueba en un grafo de espera la existencia de circuitos, eliminando
sucesivamente los vértices terminales. En un grafo de espera un vértice es terminal si la transacción
que representa no está esperando para bloquear ningún gránulo. Sea N(k) el número de gránulos que la
transacción Tk está esperando bloquear; una reducción inicial del grafo puede consistir en eliminar
aquellos vértices donde N(k)=0 y a continuación recalcular los valores de N(k) para la siguiente
iteración, contando las solicitudes que pueden ser satisfechas después de cada reducción y
decrementando N(k) para cada solicitud de Tk. Este método tiene dos requerimientos especiales:
• Es necesario marcar las peticiones en un orden tal que no se cuenten más de una vez
• Hay que utilizar un procedimiento para comprobar si una petición es satisfecha, contabilizando los
estados de bloqueo de las transacciones que todavía no han sido eliminadas del grafo de espera.

N(1)=1 N(2)=3 N(4)=0

T1 T2 T4
g1 g2 g3

T3 N(5)=0
g5
T5
N(3)=1 g4

N(1)=1 N(2)=1
T1 T2
g1 g2

T3
g5

N(3)=1

Fig. 12. – Detección del abrazo mortal en un grafo de espera.

Pág. 11 de 18
Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

Sea BLOQUEO-TENTATIVO (Gi,R,K) un procedimiento Booleano que comprueba si la petición R

de la transacción Tk sobre el gránulo Gi puede ser satisfecha, contabilizando el bloqueo de gránulos
realizados por transacciones Tj tales que N(j) ≠ 0 (transacciones todavía en espera). Este procedimiento
devolverá true si la petición puede ser satisfecha y false en caso contrario. El procedimiento es similar
al procedimiento del BLOQUEO excepto que no se modificarán los estados de bloqueos de
transacciones.

Cuando se detecta un abrazo mortal el problema consistirá en seleccionar una transacción a reiniciar. El
algoritmo presenta la lista de transacciones en la situación. Una posible solución es reiniciar la
transacción involucrada en la situación que bloquea el mayor número de otras transacciones;
corresponderá a vértices que tienen un gran número de arcos entrantes en le grafo de espera.

Para reducir el coste de la detección, este algoritmo puede ser invocado sólo cuando una transacción ha
estado en espera durante un tiempo límite (unos pocos segundos); con esto último, el enfoque de
detección puede ser una solución aceptable al abrazo mortal; extensible incluso a sistemas distribuidos.

DETECCIÓN()
T:= {Tj tales que N(j) ≠ 0}
L:= {gránulos bloqueados por Ts € T}

Para cada G € L
Para cada “petición 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”
“Añadir los gránulos bloqueados de Tk a L” ;
Si T= ∅
DETECCIÓN := false
sino
DETECCIÓN := true ;

FIN DETECCIÓN();
Fig. 13. – Algoritmo de detección de abrazo mortal.

Pág. 12 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

4 Algoritmos de ordenación por TIMESTAMP.

4.1 Definiciones
Se engloban bajo este título una serie de algoritmos que evitan la producción de planes no-serializables
asegurando que las peticiones conflictivas sobre gránulos tienen lugar en las transacciones en un orden
determinado. Para controlar el ordenamiento de operaciones se utiliza un identificador único asociado a
cada transacción: el timestamp de transacción.

Timestamp de Valor numérico asociado a una transacción que permite que sean ordenadas
transacción respecto a otras transacciones.
Es normal utilizar contadores generados por un sistema central o bien el
propio reloj del sistema.

Timestamp de gránulo Variable numérica asociada a un gránulo que almacena el timestamp de la

última transacción que operó sobre dicho gránulo.

Pueden distinguirse timestamp de gránulos asociados a distintos modos de

operación (lectura, escritura), función de las transacciones que accedieron al
gránulo en dicho modo.

4.2 Algoritmos de ordenación por timestamp total.

Consiste en la verificación de que el acceso transaccional a los gránulos 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 gránulo, el gestor de tareas asegurará que Ti precede a Tj; no se
distinguen modos de operación pero, sin embargo, puede implementase sólo con un tipo de timestamp de
gránulo.

LEER (Ti:transacción, g:gránulo) g es el gránulo accedido por Ti, S(g) es el

Si S(g) ≤ i timestamp del gránulo y ABORTAR es el
“realizar lectura” procedimiento que cáusa el rearranque de Ti o Tj.
S(g) := i
sino Puede haber un tratamiento diferente en función
ABORTAR; de qué transacción se aborta (Ti :solicita el gránulo
FIN LEER(); o Tj :tiene el gránulo); en el primer caso Ti debe
ser reiniciada con un nuevo timestamp de
ESCRIBIR (Ti:transacción, g:gránulo) transacción i’ > j, con lo que se eliminará el
Si S(g) ≤ i conflicto con Tj; de cualquier modo, ahora Ti(i=i’)
“realizar escritura” podría entrar en conflicto con una nueva
S(g) := i transacción Tj , y así sucesivamente. En el
sino segundo caso Tj debe reiniciarse con el mismo
ABORTAR; timestamp; un rearranque de Tj requerirá la
FIN ESCRIBIR (); restauración de todos los gránulos accedidos por
Fig. 14. – Algoritmo de ordenación por timestamp total. ella.

Pág. 13 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

Puede darse una situación conflictiva conocida como efecto dominó, que sucede cuando las
actualizaciones de Tj fueron leídas por otras transacciones; estas transacciones deben ser reiniciadas, es
decir, abortar Tj puede generar una situación donde una actualización realizada por Tj es deshecha mientras
que su efecto fue visible por una transacción Tk, lo cual puede requerir que también se aborte Tk, pudiendo
generarse esta situación en cadena. Esta situación se resuelve provocando una ordenación de los COMMIT
s de las transacciones de acuerdo con el timestamp de las mismas.

4.3 Algoritmos de ordenación 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 gránulos: SR, timestamp de lectura de la
transacción más reciente que efectuó una lectura y SW, timestamp de escritura del gránulo.

Cuando una transacción 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 transacción debe ser mayor que el valor del
timestamp de escritura del gránulo), p.ej. si un gránulo ha sido actualizado por T2, se tendrá SW=2 ; si ha
sido leído por la transacción más joven T7 será SR=7; en esta situación cualquier transacción con timestamp
igual o mayor que 2 podrá leer sin problemas.

Si una transacción ejecuta un ESCRIBIR, el gestor de tareas comprobará la correcta secuencia de la

operación 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 gránulo.
En el ejemplo anterior, sólo las transacciones con timestamp igual o mayor que 7 podrán escribir el gránulo.
Este algoritmo propicia también el efecto dominó aunque abortaría menos transacciones que el de
ordenación por timestamp total.

LEER (Ti:transacción, g:gránulo)

Si SW(g) ≤ i
“realizar lectura”
SR(g) := MAX(SR(g),i)
sino
ABORTAR;
FIN LEER ();

ESCRIBIR (Ti:transacción, g:gránulo)

Si SW(g) ≤ i ∧ SR(g) ≤ i
“realizar escritura”
SW(g) := i
sino
ABORTAR;
FIN ESCRIBIR ();
Fig. 15. – Algoritmo de ordenación por timestamp parcial.

Pág. 14 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

4.4 Algoritmos de ordenación por timestamp multiversión.

La estrategia anterior puede ser mejorada preservando varias versiones del mismo gránulo. Para cada
gránulo g, el sistema debería preservar un conjunto de timestamp de escritura del gránulo {SWi(g)} con los
valores asociados del gránulo en dichas versiones {Vi(g)}, y del mismo modo un conjunto de timestamp de
lectura del gránulo {SRi(g)}. Así un gránulo versión i está definido por la tupla < SWi(g), SRi(g), Vi(g) >. Se
creará una versión i para cada actualización del gránulo g efectuada por una transacción Ti. Se propone el
siguiente algoritmo para otorgar y crear versiones del mismo gránulo en memoria (buffer pool).

LEER (Ti:transacción, g:gránulo)

j:= “índice de la última versión de g”;
Mientras SWj(g) > i
j:= “índice de la versión previa de g”;
Fin Mientras;
“realizar lectura previa de g versión j”
SRj(g) := MAX(SRj(g), i)
FIN LEER()

ESCRIBIR (Ti:transacción, g:gránulo)

j:= “índice de la última versión de g”;
Mientras SWj (g) > i
j:= “índice de la versión previa de g”;
Fin Mientras;
Si SRj(g) > i
ABORTAR
sino
“Crear nueva versión i de g después de la versión j” ;
FIN ESCRIBIR ()
Fig. 16. – Algoritmo de ordenación por timestamp multiversión.

Por ejemplo para un gránulo g que ha sido sucesivamente actualizado por T1, T5 y T10 y recuperado por
transacciones T7 y T11 tendría la siguiente tabla de versiones:

Gránulo g Transacción Acción SW SR Versión

t T1 Escribir 1 1 1
T5 Escribir 5 5 5
T7 Leer 5 7 5
T10 Escribir 10 10 10
T11 Leer 10 11 10
Fig. 17.- Situación 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
transacción Ti que solicita una lectura del gránulo g con la versión cuyo timestamp de escritura del gránulo
es inmediatamente inferior o igual a i.

Pág. 15 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

Si una transacción Ti requiere una lectura del gránulo, se le suministrará la versión inmediatamente inferior.
Para tratar las escrituras de una Ti se insertarán nuevas versiones creadas por las transacciones justo después
de encontrar un timestamp de escritura del gránulo inmediatamente más bajo, Vi’. Si, de cualquier modo,
antes de las acciones de escritura de Ti, una transacción 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 había terminado; normalmente es preferible reiniciar Ti con un
nuevo timestamp i’ (i’>i) y así evitar rehacer el pasado que se confirmó.

Análisis de casos de transacciones concurrentes

Caso 1. T6 solicita el gránulo g en lectura. La tabla de versiones no se ve afectada por esta operación, ya que
se suministraría la versión 5 del gránulo cuyo timestamp de lectura es SR=7, mayor que 6 que es el
timestamp de T6.
Caso 2. T8 solicita el gránulo g en lectura. La tabla de versiones anterior se ve modificada, pues según el
algoritmo de lectura, hay que otorgar la versión 5, modificándose su timestamp de lectura, pues el valor
anterior era SR=7 y se otorga a una transacción con mayor timestamp.

Después de las dos acciones anteriores, la tabla de versiones quedaría:

Gránulo g Transacción Acción SW SR Versión

T6 Leer 5 7 5
T8 Leer 5 8 5
Fig. 18.- Situación de versiones después de lecturas

Caso 3. T6 solicita una escritura sobre el gránulo g; en este caso corresponderá darle la versión
inmediatamente anterior, versión 5 con timestamps SW=5, SR=7, cumpliéndose que el timestamp de
lectura del gránulo es mayor (T7 vió esta versión) que el timestamp de la transacción (T6). Hay que abortar
alguna transacción en vuelo (T6 o T7 según el algoritmo, pudiendo elegir entre las dos sólo si T7 no ha
alcanzado el commit).

Caso 3a. Se aborta T7 y se reinicia con el mismo timestamp

Gránulo g Transacción Acción SW SR Versión
T6 Escribir 6 6 6
T7 ABORT
T7 Leer 6 7 6
Fig. 19.- Situación de versiones al abortar la transacción que ya había leído.

Caso 3b. Se aborta T6 y se reinicia con timestamp superior a la última versión existente.
Gránulo g Transacción Acción SW SR Versión
T6 ABORT
T12 ≅antiguaT6 Restart
T12 Escribir 12 12 12
Fig. 20.- Situación de versiones al abortar la transacción que solicita la escritura.

Pág. 16 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

5 Algoritmos optimistas.
Los algoritmos de ordenación por timestamp verifican el correcto ordenamiento de las transacciones sobre
cada acceso a los gránulos al igual que los algoritmos de bloqueo; estos dos tipos de algoritmos
implementan un control a priori. Si el gestor de tareas se diseña de modo que deje mayor libertad a las
transacciones y realiza un control de las mismas, en vez de durante su ejecución en tiempo de confirmación
de cambios a la BD se está barajando la idea básica de los métodos optimistas de control de concurrencia. Los
algoritmos optimistas consideran que todas las transacciones preparan sus actualizaciones en buffers
privados durante la ejecución; al finalizar, antes de la confirmación todas las actualizaciones deben sufrir un
proceso de certificación (o validación).

Certificación. Acción especial que controla que la confirmación de actualizaciones de una transacción en la
BD preserva la serializabilidad.

Si la transacción es certificada las actualizaciones preparadas se harán visibles a otras transacciones, y si falla
la transacción se abortará. En definitiva, con un control optimista de la concurrencia, una transacción
sufrirá tres fases: fase de lectura, donde se preparan actualizaciones en áreas de trabajo privadas de las
transacciones, fase de certificación y la posible fase de escritura.

Fase de Fase de Fase de

LECTURA CERTIFICACION ESCRITURA

Ejecución Validación Confirmación

Fig. 21. – Fases de una transacción

El problema principal de estos métodos es la elección del algoritmo de certificación donde el orden de
serialización estará determinado por el orden de certificación. En esta fase se deberá comprobar que una
transacción validada Ti ha visto todas las modificaciones de las precedentes transacciones que también lo
han sido; dicho de otro modo, todos los gránulos leídos por Ti no deben haber sido escritos por cualquier
otra transacción Tj certificada entre el comienzo de Ti y la certificación de Tj. El algoritmo mantendrá los
conjuntos de timestamp de lectura y escritura de cada transacción sobre los gránulos SR(Ti) y SW(Ti); se
aceptará una validación 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 certificación; éste puede rechazar una transacción que no
viola el orden de serializabilidad.

Pág. 17 de 18
 Diseño de Bases de Datos Concurrencia
Sevilla, octubre 2004, V 2004.02.1

INICIO_TRANSACCIÓN (Ti :transacción)

SR(Ti) := ∅
SW(Ti) := ∅
después(Ti) := contador_certificación
FIN INICIO_TRANSACCIÓN ()

CERTIFICACIÓN (Ti :transacción)

Para t = después (Ti) + 1 hasta contador _certificación
Si SR(Ti) ∩ SW(t) ≠∅
ABORTAR(Ti) ;
FIN Para;
Si “No abortada Ti”
contador _certificación := contador _certificación + 1
CONFIRMACIÓN (Ti);
FIN CERTIFICACIÓN ()

CONFIRMACIÓN (Ti :transacción)

Para cada g € SW(Ti)
ESCRIBIR (g);
FIN CONFIRMACIÓN ()
Fig. 22. – Algoritmo de certificación.

Así, el algoritmo de certificación puede ser mejorado rechazando menos transacciones utilizando timestamp
de gránulos. Los algoritmos de certificación 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 sólo en
el contexto de transacciones muy cortas con baja probabilidad de conflicto. También se pueden considerar
eficientes en conjunción con algoritmos de recuperación del tipo NO-UNDO.

Pág. 18 de 18