DB1 Unidad 9: Concurrencia

Bases de Datos Carrera de Software
Ph.D. Franklin Parrales 1
05/03/2022
Concurrencia
Unidad 9
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Bases de datos

05/03/2022
Control de la concurrencia
Objetivos
▪ Conocer la problemática asociada a la
concurrencia de transacciones en los sistemas de
bases de datos
▪ Entender el significado de la serializabilidad y su
aplicación al control de la concurrencia
▪ Comprender algunas técnicas para el control de la
concurrencia empleadas por los sistemas gestores
de bases de datos

05/03/2022
Control de la concurrencia
Bibliografía
▪ [CB 2005] Connolly, T.; Begg C.: Sistemas de bases
de datos. 4ª Edición. Pearson Educación. Addison
Wesley. (Cap. 20)
▪ [EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos
de Sistemas de Bases de Datos. 3ª Edición. Addison-
Wesley. (Cap. 19 y 20)
▪ [EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de
bases de datos. Conceptos fundamentales. 2ª
Edición. Addison-Wesley Iberoamericana. (Cap. 17 y
18)

05/03/2022
Contenido
▪ Introducción y problemas de la concurrencia
▪ Serializabilidad
▪ Técnicas de control de la concurrencia
▪ Granularidad de datos
▪ Niveles de aislamiento en MySQL
▪ Políticas de bloqueo en MySQL

05/03/2022
▪ Los sistemas de bases de datos, según el número de
usuarios que pueden utilizarlos de forma concurrente,
se clasifican en sistemas monousuario y
multiusuario
▪ Varios usuarios pueden usar un mismo equipo a la vez
gracias a la multiprogramación: el computador
puede procesar al mismo tiempo varias transacciones
• Si el equipo tiene varias CPU, es posible el procesamiento
simultáneo (paralelo) de transacciones
• Si sólo hay una CPU, el SO de multiprogramación
reparte el tiempo de CPU entre las transacciones:
ejecución concurrente intercalada
 modelo que supondremos

05/03/2022
▪ Varias transacciones introducidas por usuarios, que
se ejecutan de manera concurrente, pueden
leer/modificar los mismos elementos almacenados
en la base de datos
▪ Razones para permitir la concurrencia:
• Aumentar la productividad: número de transacciones
ejecutadas por minuto.
• Aumentar la utilización de la CPU (menos tiempo ociosa) y
Control del disco.
• Reducir el tiempo medio de respuesta de transacciones
(las ‘pequeñas’ no esperan a las ‘grandes’).

05/03/2022
▪ ... porque pueden surgir problemas si las transacciones
concurrentes se ejecutan de manera no controlada
▪ Ejemplo sencillo:
sistema de bases de datos que permite hacer y anular
reservas de plazas en vuelos de diferentes compañías
aéreas.
• Se almacena un registro por cada vuelo, que incluye, entre
otras cosas, el número de asientos reservados en el vuelo
• Sean dos transacciones T1 y T2 concurrentes:
• T1 transfiere N reservas realizadas en un vuelo X a otro vuelo Y
• T2 reserva M plazas en el vuelo X
¿Por qué es necesario el control de la concurrencia?

05/03/2022
Problemas potenciales provocados por la concurrencia
Transacción T1
leer_elemento(X);
X:= X-N;
escribir_elemento(X);
leer_elemento(Y);
Y:=Y+N;
escribir_elemento(Y);
Transacción T2
leer_elemento(X);
X:= X+M;
• Aunque las transacciones pueden ser perfectamente
correctas en sí mismas, la ejecución concurrente de T1 y T2
puede producir un resultado incorrecto, debido a la
intercalación de sus operaciones, poniendo en cuestión
la integridad y la coherencia de la base de datos

05/03/2022
▪ La actualización perdida
• T1 y T2 que acceden a los mismos datos, tienen sus
operaciones intercaladas de modo que hacen incorrecto
el valor de algún dato
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T2
leer_elemento(X);
X:= X+M;
El elemento X tiene un valor
incorrecto porque su
actualización por T1 se
‘perdió’ (se sobreescribió)

05/03/2022
▪ La actualización temporal (o lectura sucia/Dirty Read)
• T1 actualiza un elemento X de la BD y luego falla, pero antes de
que se restaure el valor original de X, T2 tiene acceso al «valor
temporal» de X
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
…
T2
leer_elemento(X);
X:= X+M;
T1 falla y debe devolver a X su
antiguo valor; pero mientras, T2
ha leído el valor ‘temporal’
incorrecto de X (dato sucio)

05/03/2022
▪ La actualización temporal (o lectura sucia/Dirty Read)
• Sucede cuando una segunda transacción lee datos que están
siendo modificados por una transacción antes de que haga
COMMIT.
Transacción 1 Transacción 2
UPDATE cuentas SET saldo =
saldo - 100 WHERE id = 1;
SELECT saldo FROM cuentas
WHERE id = 1;
ROLLBACK

05/03/2022
▪ El resumen incorrecto/Lectura fantasma (Phantom Read)
• Otra transacción T3 calcula una función agregada de resumen
sobre varios registros (suma las plazas reservadas para todos los
vuelos), mientras otras transacciones, como T1, actualizan dichos
registros: puede que T3 considere unos registros antes de ser
actualizados y otros después
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T3
suma:=0;
leer_elemento(A);
suma:= suma+A;
…
…
…
leer_elemento(X);
suma:= suma+X;
leer_elemento(Y);
suma:= suma+Y;
…
…
…
T3 lee X después de
restar N, pero lee Y
antes de sumar N, así
que el resultado es un
resumen incorrecto
(discrepancia de N)

05/03/2022
▪ El resumen incorrecto/Lectura fantasma (Phantom
Read)
• Este error ocurre cuando una transacción ejecuta dos veces
una consulta que devuelve un conjunto de filas y en la segunda
ejecución de la consulta aparecen nuevas filas en el
conjunto que no existían cuando se inició lo transacción.
SELECT SUM(saldo) FROM
cuentas;
INSERT INTO cuentas
VALUES (4, 3000);
SELECT SUM(saldo) FROM
cuentas;

05/03/2022
▪ La lectura no repetible (Non-Repeatable Read)
• T4 lee un elemento X dos veces y otra transacción, como
T1, modifica dicho X entre las dos lecturas: T4 recibe
diferentes valores para el mismo elemento
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T4
leer_elemento(X);
…
leer_elemento(X);
…
T4 lee X antes de
restar N
T4 lee X después
de restar N

05/03/2022
▪ La lectura no repetible (Non-Repeatable Read)
• Se produce cuando una transacción consulta el mismo
dato dos veces durante la ejecución de la transacción y la
segunda vez encuentra que el valor del dato ha sido
modificado por otra transacción.
WHERE id = 1;
UPDATE cuentas SET saldo =
saldo - 100 WHERE id = 1;
WHERE id = 1;

05/03/2022
Contenido

05/03/2022
▪ Objetivo de un protocolo de control de concurrencia:
• Planificar las transacciones de forma que no ocurran
interferencias entre ellas, y así evitar la aparición de los
problemas mencionados
▪ Solución obvia: no permitir intercalación de operaciones
de varias transacciones
Motivación
Planificación A
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T2
leer_elemento(X);
X:= X+M;
Planificación B
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T2
leer_elemento(X);
X:= X+M;

05/03/2022
• Pero el objetivo de un SGBD multiusuario también es
maximizar el grado de concurrencia del sistema
• Si se permite la intercalación de operaciones, existen
muchos órdenes posibles de ejecución de las transacciones
Motivación
¿Existe algún modo de identificar las ejecuciones que está garantizado que
protegen la consistencia de la base de datos?
Teoría de la Serializabilidad
Planificación C: actualización perdida!
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T2
leer_elemento(X);
X:= X+M;
Planificación D: correcta!
T1
leer_elemento(X);
X:= X-N;
leer_elemento(Y);
Y:=Y+N;
T2
leer_elemento(X);
X:= X+M;

05/03/2022
• Cada transacción comprende una secuencia de operaciones
que incluyen acciones de lectura y escritura en la BD, que
finaliza con una confirmación (commit) o anulación (rollback)
• Una planificación P de n transacciones concurrentes
T1, T2 ... Tn es una secuencia de las operaciones realizadas
por dichas transacciones, sujeta a la restricción de que
para cada transacción Ti que participa en P,
sus operaciones aparecen en P
en el mismo orden en el que ocurren en Ti
Planificación de transacciones

05/03/2022
• Para el control de la concurrencia (y recuperación de fallos)
interesa prestar mayor atención a estas operaciones:
• Ejemplos de planificaciones de transacciones
– El subíndice de cada operación indica la transacción que la realiza
PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ;
PB: l2(X) ; e2(X) ; c2 ; l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;
PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ;
PD: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;
PE: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; r1 ;
Planificación de transacciones
operación abreviatura
leer_elemento l
escribir_elemento e
commit c
rollback r

05/03/2022
• Una planificación serie P es aquella en la que las
operaciones de cada transacción se ejecutan
consecutivamente sin que se intercalen operaciones de
otras transacciones
PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ;
PB: l2(X) ; e2(X) ; c2 ; l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;
• Toda planificación serie es correcta BD consistente
• Pero no se garantiza que los resultados de todas las
ejecuciones en serie de las mismas transacciones sean
idénticos
– Ejemplo: cálculo del interés de una cuenta bancaria antes o después de realizar
un ingreso considerable
en general, son inaceptables en la práctica (ineficiencia)
Planificación serie

05/03/2022
• Una planificación no serie P es aquella en la que las
operaciones de un conjunto de transacciones
concurrentes se ejecutan intercaladas
PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ;
• Hemos de determinar qué planificaciones no serie
permiten llevar la BD a un estado al que pueda
llegarse mediante una ejecución en serie
Planificación no serie
Este es el objetivo de la
Serializabilidad
KO

05/03/2022
• Una planificación P (no serie) es serializable si es
equivalente a alguna planificación serie de las
mismas n transacciones
– Una planificación que no es equivalente a ninguna ejecución en
serie, es una planificación no serializable
• Toda planificación serializable es correcta
– Produce los mismos resultados que alguna ejecución en serie
• Dos maneras de definir la equivalencia entre planificaciones:
– Equivalencia por conflictos
– Equivalencia de vistas
Planificación serializable

05/03/2022
• Si dos transacciones únicamente leen un determinado
elemento de datos, no entran en conflicto entre sí y el
orden de las operaciones no es importante
• Si hay dos transacciones que leen o escriben elementos
de datos independientes, no entran en conflicto entre sí y
el orden de las operaciones no es importante
• Si una de las transacciones escribe un elemento de datos
y la otra lee o escribe el mismo elemento, entran en
conflicto y el orden de las operaciones sí es
importante
Equivalencia por conflictos

05/03/2022
• En una planificación, 2 operaciones están en conflicto si
– pertenecen a diferentes transacciones,
– tienen acceso al mismo elemento X,
– y al menos una de ellas es escribir_elemento(X)
Operaciones en conflicto en las planificaciones PC y PD:
PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1;
• Dos planes son equivalentes por conflictos si el orden
de cualesquiera dos operaciones en conflicto es el
mismo en ambos planes
Equivalencia por conflictos

05/03/2022
• Una planificación P es serializable por conflictos si
equivale por conflictos a alguna planificación serie S
Podremos intercambiar cada dos operaciones de P consecutivas de
transacciones distintas y sin conflicto, hasta obtener la planificación
serie equivalente
PD : l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;
PD1: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; c2 ; e1(Y) ; c1 ;
PD2: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c2 ; c1 ;
PD3: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c1 ; c2 ;
PD4: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; c1 ; c2 ;
PD5: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; e2(X) ; c1 ; c2 ;
PD6: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; c1 ; e2(X) ; c2 ;
PD7: l1(X) ; e1(X) ; l1(Y) ; l2(X) ; e1(Y) ; c1 ; e2(X) ; c2 ;
PD8: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; l2(X) ; c1 ; e2(X) ; c2 ;
PD9: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ;
Planificación serializable por conflictos
¡Es una planificación serie!
PD es serializable

05/03/2022
• Construcción del grafo de precedencia (o de serialización)
– Es un grafo dirigido G = ( N, A )
– N es un conjunto de nodos y A es un conjunto de aristas dirigidas
– Algoritmo:
▪ Crear un nodo por cada transacción Ti en P
▪ Crear una arista Tj →Tk si Tk lee el valor de un elemento después
de que Tj lo haya escrito
▪ Crear una arista Tj →Tk si Tk escribe el valor de un elemento
después de que Tj lo haya leído
▪ Crear una arista Tj →Tk si Tk escribe el valor de un elemento
después de que Tj lo haya escrito
Ti
Detección de la serializabilidad por conflictos
Tj Tk

05/03/2022
• Una arista Tj → Tk indica que Tj debe aparecer antes que Tk
en una planificación serie equivalente a P, pues dos
operaciones en conflicto aparecen en dicho orden en P
• Si el grafo contiene un ciclo, P no es serializable por
conflictos
– Un ciclo es una secuencia de aristas C=((Tj →Tk), (Tk →Tp),... (Ti →Tj))
• Si no hay ciclos en el grafo, P es serializable
Es posible obtener una planificación serie S equivalente a
P, mediante una ordenación topológica de los nodos
Detección de la serializabilidad por conflictos (y 2)
T1 T2
PA
T1 T2
PB
T1 T2
PC
T1 T2
PD

05/03/2022
Planificación E
Ejemplo de planificación no serializable
Transacción T1
leer_elemento(X);
leer_elemento(Y);
Transacción T2
leer_elemento(Z);
leer_elemento(Y);
leer_elemento(X);
Transacción T3
leer_elemento(Y);
leer_elemento(Z);
escribir_elemento(Z);
T1
leer_elemento(X);
leer_elemento(Y);
T2
leer_elemento(Z);
leer_elemento(Y);
leer_elemento(X);
T3
leer_elemento(Y);
leer_elemento(Z);
T1 T2
Y
X
T3
Y,Z
Y
Hay dos ciclos:
T1→T2→T1 y
T1→T2→T3→T1

05/03/2022
Planificación F
Ejemplo de planificación serializable
Transacción T1
leer_elemento(X);
leer_elemento(Y);
Transacción T2
leer_elemento(Z);
leer_elemento(Y);
leer_elemento(X);
Transacción T3
leer_elemento(Y);
leer_elemento(Z);
T1
leer_elemento(X);
leer_elemento(Y);
T2
leer_elemento(Z);
leer_elemento(Y);
leer_elemento(X);
T3
leer_elemento(Y);
leer_elemento(Z);
T1 T2
X,Y
T3
Y,Z
Y
La planificación
serie equivalente
es T3 → T1 → T2

05/03/2022
Es el SO el que distribuye los recursos
para los procesos, y determina la
intercalación de las operaciones de las
transacciones concurrentes
(ejecutadas como procesos del SO)
Planificación P
(ordenamiento de
las operaciones)
• Carga del sistema
• Momento de
introducción de las
transacciones
• Prioridades de los
procesos
...
Planificador de
Tareas del SO
Aplicaciones de la serializabilidad
Es necesario encontrar técnicas que garanticen la
serializabilidad, sin tener que verificar a posteriori
¡¡enfoque muy
poco práctico!!
Parece, pues, que habría que
comprobar si P es serializable
una vez ejecutadas las
transacciones incluidas en P...
Ejecución de
Transacciones
NO
SI
OK
Cancelar el
efecto de P
reintentar
¿P serializable?

05/03/2022
Contenido

05/03/2022
• Métodos basados en la teoría de la serializabilidad,
que definen un conjunto de reglas (o protocolo) tal que...
– si todas las transacciones las cumplen, o
– el subsistema de control de concurrencia del SGBD las
impone (automáticamente)
... se asegura la serializabilidad de toda planificación
de transacciones
• Clasificación
– Métodos de bloqueo
– Métodos de marca de tiempo
– Técnicas de multiversión
– Métodos optimistas

05/03/2022
• Uso de bloqueos para controlar el acceso concurrente a los
elementos de datos almacenados en la base de datos
• Reglas básicas del bloqueo:
– Bloqueo compartido: si una transacción tiene un bloqueo
compartido sobre un elemento de datos, puede leer el elemento,
pero no actualizarlo (escribir)
▪ Varias transacciones pueden mantener a la vez bloqueos compartidos
sobre el mismo elemento
– Bloqueo exclusivo: si una transacción tiene un bloqueo exclusivo
sobre un elemento de datos, puede leer y actualizar (escribir) el
elemento
▪ Un bloqueo exclusivo proporciona acceso exclusivo al elemento
Métodos de bloqueo

05/03/2022
Reglas de uso de los bloqueos
1. T debe emitir bloquear_lectura(X) o bloquear_escritura(X) antes de
ejecutar una operación leer_elemento(X)
2. T debe emitir bloquear_escritura(X) antes de realizar una
operación escribir_elemento(X) en T
3. T debe emitir desbloquear(X) una vez completadas todas las
operaciones leer_elemento(X) y escribir_elemento(X)
4. Si T ya posee un bloqueo, compartido o exclusivo, sobre X
no emitirá bloquear_lectura(X) ni bloquear_escritura(X)
*esta regla puede permitir excepciones: mejora y reducción de bloqueos*
5. T no emitirá desbloquear(X) salvo si posee un bloqueo,
compartido o exclusivo, sobre X
Métodos de bloqueo

05/03/2022
• Cuando una transacción T solicita un bloqueo…
– Si el elemento no ha sido ya bloqueado por otra transacción, se
le concede el bloqueo
– Si el elemento sí está bloqueado, el SGBD determina si la solicitud
es compatible con el bloqueo existente:
▪ Si se pide un bloqueo compartido sobre un elemento que ya tiene un
bloqueo compartido, el bloqueo será concedido a T
▪ En otro caso, T debe esperar hasta que se libere el bloqueo existente
• Una transacción que obtiene un bloqueo lo mantiene hasta
que lo libera explícitamente o termina (commit o rollback)
– Sólo cuando se libera un bloqueo exclusivo los efectos de la escritura
serán visibles para las demás transacciones
Métodos de bloqueo

05/03/2022
• Algunos sistemas permiten la mejora (o promoción) y la
reducción (o degradación) de bloqueos
– Aumenta el nivel de concurrencia del sistema
• Si T emitió bloquear_lectura(X), más tarde puede mejorarlo a
bloqueo exclusivo emitiendo bloquear_escritura(X)
– Si T es la única que tiene un bloqueo compartido sobre X, se le
concede la solicitud
– En otro caso, T debe esperar
• Si T emitió bloquear_escritura(X), más tarde puede reducirlo a
un bloqueo compartido emitiendo bloquear_lectura(X)
– Así permite que otras transacciones lean X
Métodos de bloqueo

05/03/2022
• El uso de bloqueos para la programación de transacciones
no garantiza la serializabilidad de las planificaciones
Métodos de bloqueo
Planificación G
T4
bloquear_lectura(Y);
leer_elemento(Y);
desbloquear(Y);
bloquear_escritura(X);
leer_elemento(X);
X:=X+Y;
desbloquear(X);
T5
bloquear_lectura(X);
leer_elemento(X);
desbloquear(X);
bloquear_escritura(Y);
leer_elemento(Y);
Y:=X+Y;
desbloquear(Y);
Transacción T4
leer_elemento(Y);
desbloquear(Y);
leer_elemento(X);
X:=X+Y;
desbloquear(X);
Transacción T5
leer_elemento(X);
desbloquear(X);
leer_elemento(Y);
Y:=X+Y;
desbloquear(Y);
Valores iniciales: X=20, Y=30
Resultados de las planificaciones serie:
T4→T5: X=50, Y=80
T5→T4: X=70, Y=50
Resultado de la planificación G:
X=50, Y=50 (No serializable!)

05/03/2022
Es necesario seguir un protocolo adicional que indique
dónde colocar las operaciones de bloqueo y
desbloqueo dentro de las transacciones
• El más conocido es el Bloqueo en Dos Fases (B2F)
• Una transacción T sigue el protocolo de bloqueo en dos
fases si todas las operaciones de bloqueo preceden a
la primera operación de desbloqueo
De este modo, podemos ver T dividida en dos fases:
– Fase de expansión (o crecimiento)
▪ T puede adquirir bloqueos
▪ T no puede liberar ningún bloqueo
– Fase de contracción
▪ T puede liberar bloqueos existentes
▪ T no puede adquirir ningún bloqueo
Métodos de bloqueo: Bloqueo en dos fases

05/03/2022
• Si el sistema permite mejorar y reducir bloqueos…
– La mejora sólo puede tener lugar en la fase de expansión
– La reducción sólo puede realizarse en la fase de contracción
En el código de T, un bloquear_lectura(X) puede aparecer en la fase de
contracción de T sólo si reduce un bloqueo exclusivo a uno compartido
Bloqueo en dos fases
Transacción T4’
leer_elemento(Y);
desbloquear(Y);
leer_elemento(X);
X:=X+Y;
desbloquear(X);
Transacción T5’
leer_elemento(X);
desbloquear(X);
leer_elemento(Y);
Y:=X+Y;
desbloquear(Y);

05/03/2022
• Si toda transacción de una planificación sigue el
protocolo de bloqueo en dos fases, entonces la
planificación es serializable
• Ventaja
– Ya no es necesario comprobar la serializabilidad de las
planificaciones
• Inconvenientes
– El B2F puede limitar el grado de concurrencia en un plan
– Emplear bloqueos puede provocar problemas de ...
▪ Interbloqueo (bloqueo mortal o abrazo mortal)
▪ Bloqueo indefinido (o espera indefinida)
Bloqueo en dos fases

05/03/2022
• T debe bloquear todos los elementos a los que tendrá
acceso (lectura o escritura) antes de comenzar a ejecutarse
– Si no es posible bloquear algún elemento, T no bloqueará
ninguno y esperará para reintentarlo más tarde
– Protocolo libre de interbloqueo
Bloqueo en dos fases conservador o estático
Bloqueo en dos fases estricto el más utilizado
• T no libera ningún bloqueo exclusivo hasta terminar (con
COMMIT o ROLLBACK)
– Ninguna transacción lee o escribe un elemento modificado
por T, salvo si T se ha completadoplanificación estricta
– Puede sufrir interbloqueo (salvo si se combina con B2F conservador)
Bloqueo en dos fases riguroso más restrictivo que el B2F estricto
• T no libera ningún bloqueo compartido ni exclusivo hasta
terminar (con COMMIT o ROLLBACK) planificación estricta

05/03/2022
• Situación en la que cada una de dos (o más)
transacciones está esperando a que se libere un
bloqueo establecido por la otra transacción
El problema del interbloqueo
T6
leer_elemento(X);
X:=X-10;
[… en espera …]
T7
leer_elemento(Y);
Y:=Y+100;
[… en espera …]
• El SGBD ha de reconocer un interbloqueo y romperlo:
– Abortar una o más transacciones
▪ Se deshacen sus escrituras y se liberan sus bloqueos
Así, el resto de transacciones podrá continuar su ejecución
– Reiniciar automáticamente las transacciones abortadas

05/03/2022
• Hay 3 técnicas generales para gestionar los interbloqueos
– Temporizaciones de bloqueos
– Prevención de interbloqueos
– Detección de interbloqueos
• Conviene detectar interbloqueos cuando se sabe que hay
poca interferencia entre transacciones, es decir si...
– Las transacciones son cortas y bloquean pocos elementos, o
– La carga de transacciones es pequeña
• En otro caso, conviene usar temporizaciones o técnicas de
prevención
Es más difícil prevenir que utilizar temporizaciones o que
detectarlos y romperlos, por lo que en la práctica los
sistemas no suelen emplear las técnicas de prevención
El problema del interbloqueo

05/03/2022
• Una transacción que solicita un bloqueo sólo esperará
durante un período de tiempo predefinido por el sistema
• Si no se concede el bloqueo durante ese tiempo, se
producirá un ‘fin de temporización’: el SGBD asumirá que la
transacción está interbloqueada (aunque puede que no),
la abortará y la reiniciará automáticamente
Es una solución muy sencilla y práctica
Pero puede hacer que sean abortadas y reiniciadas
transacciones que en realidad no están en un interbloqueo
Temporizaciones de bloqueos

05/03/2022
• Ordenar las transacciones usando marcas temporales de
transacción MT(T):
▪ Identificador único para T
▪ Las MT se ordenan según se inician las transacciones
▪ La T más antigua tiene la MT(T) menor
Sea Tj que intenta bloquear el elemento de datos X ,
pero X ya está bloqueado por Tk con un candado en conflicto
• Algoritmo Esperar - Morir
si MT(Tj) < MT(Tk) entonces Tj puede esperar
si no, se aborta Tj (Tj muere) y
se reinicia después con la misma marca de tiempo
 Una Tj más antigua espera a que termine otra Tk más reciente
 Una Tj más reciente que solicita un elemento bloqueado por una Tk
más antigua, es abortada (muere) y reiniciada
Prevención de interbloqueos

05/03/2022
• Algoritmo Herir - Esperar
si MT(Tj) < MT(Tk) entonces se aborta Tk (Tj hiere a Tk) y
se reinicia después con la misma MT
si no, Tj puede esperar
 Una Tj más reciente espera a que termine una Tk más antigua
 Una Tj más antigua que solicita un elemento bloqueado por una Tk
más reciente, hace que la más reciente sea abortada (es herida) y reiniciada
• Inconvenientes
– Ambos algoritmos hacen que sean abortadas y reiniciadas
transacciones que podrían provocar un bloqueo mortal, aunque
tal cosa nunca ocurriera!
– En el algoritmo Esperar-Morir, una Tj podría abortar y reiniciarse
varias veces seguidas si Tk más antigua sigue bloqueando el X que
Tj solicita
Prevención de interbloqueos

05/03/2022
• Verificación periódica del estado del sistema
¿está en un bloqueo mortal?
• Creación de un grafo de espera que muestra las
dependencias entre transacciones
– Crear un nodo por cada transacción en ejecución, etiquetado con el
identificador de la transacción, T
– Si Tj espera para bloquear el elemento X, ya bloqueado por Tk, crear
una arista dirigida desde Tj a Tk
– Cuando Tk libera el candado sobre X, borrar la arista
correspondiente
• Si existe un ciclo en el grafo de espera, entonces se ha
detectado un interbloqueo entre las transacciones
Detección de interbloqueos
Tj Tk
X
Tj Tk

05/03/2022
• Pero... ¿cuándo hay que verificar el estado del sistema
(ejecutar el algoritmo que genera el grafo de espera)?
– A intervalos uniformes de tiempo, o
– A intervalos de tiempo desiguales :
▪ Iniciar algoritmo de detección con un tamaño de intervalo inicial
▪ Cada vez que no se detecta interbloqueo, incrementar el intervalo
– Por ejemplo, al doble del anterior
▪ Cada vez que se detecta interbloqueo, reducir el intervalo
– Por ejemplo a la mitad
▪ Existirán límites superior e inferior del tamaño del intervalo

05/03/2022
• Si el sistema está en un estado de interbloqueo, el SGBD
necesita abortar algunas transacciones...
• ¿Cuáles?  Selección de víctimas
– Es mejor abortar transacciones que lleven poco tiempo en
ejecución
– Es mejor abortar una transacción que haya hecho pocos cambios
en la base de datos
– Es mejor abortar una transacción que todavía debe hacer muchos
cambios en la base de datos
▪ Puede que el SGBD no conozca esta información
Se trata de abortar las transacciones que supongan el
mínimo coste
• Es necesario evitar la inanición

05/03/2022
• Una transacción sufre inanición cuando es seleccionada
para ser abortada (víctima) sucesivamente: nunca
termina su ejecución
– Es similar al bloqueo indefinido
• La solución es asignar prioridades más altas a las
transacciones abortadas varias veces, para no ser siempre
las víctimas
Detección de interbloqueos: el problema de la inanición

05/03/2022
• El protocolo de control de concurrencia nunca selecciona
a una transacción que está esperando para
establecer un bloqueo, mientras otras transacciones
continúan ejecutándose con normalidad
– Ocurre si el esquema de espera da más prioridad a unas
transacciones que a otras  esquema de espera injusto
• Dos algoritmos de prevención de bloqueo indefinido
– Consiguen un esquema de espera justo
▪ El primero que llega, es el primero en ser atendido
• Las transacciones puede bloquear el elemento X en el orden en
que solicitaron su bloqueo
▪ Aumento de prioridad en la espera
• Cuanto más espera T, mayor es su prioridad
• Cuando T tiene la prioridad más alta de todas, obtiene el bloqueo
y continúa su ejecución
El problema del bloqueo indefinido

05/03/2022
Contenido

05/03/2022
• Toda técnica de control de concurrencia supone que la base
de datos está constituida por un conjunto de elementos de
datos con nombre
• Normalmente, un elemento de datos será uno de estos:
– un valor de campo de un registro de la BD
– un registro de la BD
– una página (uno o varios bloques de disco)
– un fichero
– la BD completa
• Granularidad = tamaño del elemento de información
– Granularidad fina  elementos de tamaño pequeño
– Granularidad gruesa elementos grandes
Elementos de bases de datos y granularidad

05/03/2022
• En el contexto de los métodos de bloqueo, el tamaño del
elemento de datos afecta al grado de concurrencia:
 tamaño(elemento)   Grado de concurrencia
Y también...
  número de elementos en la BD
  carga de trabajo para la gestión de bloqueos, y
  espacio ocupado por la información de bloqueo
• Pero... ¿Cuál es el tamaño adecuado para los elementos?
Pues depende de la naturaleza de las transacciones:
– Si una T representativa accede a pocos registros
▪ elegir granularidad de registro
– Si T accede a muchos registros de un mismo fichero
▪ elegir granularidad de página o de fichero
Elección del tamaño adecuado del elemento de datos

05/03/2022
NIVEL DE ABSTRACCIÓN
LÓGICO O CONCEPTUAL:
• Definición del nivel de
aislamiento de cada transacción
(por parte del usuario o, por
omisión, el propio SGBD)
• Control explícito de bloqueos
(operación LOCK) por parte del
usuario, si se permiten niveles de
aislamiento inferiores a
SERIALIZABLE
NIVEL DE ABSTRACCIÓN
FÍSICO O INTERNO:
• El SGBD implementa los niveles
de aislamiento definidos por el
usuario para las transacciones
siguiendo una o varias técnicas
o protocolos
• Por ejemplo el SGBD Oracle usa
dos:
– Bloqueos
– Multiversión
Estos conceptos se tratan en
el anexo de este tema
Estos conceptos se han estudiado
en la teoría de este tema
Aclaración ...

05/03/2022
Contenido

05/03/2022
Niveles de aislamiento en MySQL
▪ Para evitar que sucedan los problemas de acceso concurrente que
hemos comentado en el punto inicial de esta unidad, podemos
establecer diferentes niveles de aislamiento que controlan el nivel
de bloqueo durante el acceso a los datos. El estándar ANSI/ISO de
SQL (SQL92) define cuatro niveles de aislamiento.
• Read Uncommitted. En este nivel no se realiza ningún bloqueo, por lo
tanto, permite que sucedan los tres problemas
• Read Committed. En este caso los datos leídos por una transacción
pueden ser modificados por otras transacciones, por lo tanto, se pueden
dar los problemas Non-Repeteable Read y Phantom Read.
• Repeatable Read. En este nivel ningún registro leído con un SELECT
puede ser modificado en otra transacción, por lo tanto, sólo puede
suceder el problema del Phantom Read.
• Serializable. En este caso las transacciones se ejecutan unas detrás
de otras, sin que exista la posibilidad de concurencia.
▪ El nivel de aislamiento que utiliza InnoDB por defecto es
Repeatable Read.

05/03/2022
▪ La siguiente tabla muestra los problemas de lectura
que pueden ocurrir en cada uno de los modos de
aislamiento.
Nivel
Dirty Read (Lectura
sucia)
Non-Repeatable
Read (Lectura No
Repetible)
Phantom Read
(Lectura fantasma)
Read Uncommitted Es posible Es posible Es posible
Read Committed - Es posible Es posible
Repeatable Read - - Es posible
Serializable - - -

05/03/2022
▪ Podemos consultar el nivel de aislamiento que estamos
utilizando, consultando el contenido de la variable global y
de sesión @@transaction_isolation.
▪ También podemos consultar el contenido de la variable de
sesión sin utilizar la palabra reservada SESSION.
-- Variable global
SELECT @@GLOBAL.transaction_isolation;
-- Variable de sesión
SELECT @@SESSION.transaction_isolation;
SELECT @@transaction_isolation;

05/03/2022
Ejemplo 1: Evaluación de los niveles de
aislamiento ante el problema Dirty Read.
▪ En este ejemplo vamos a simular que hay dos
usuarios que quieren acceder de forma
concurrente a los mismos datos de una tabla.
▪ Para simular los dos usuarios vamos a iniciar dos
terminales para conectarnos a un servidor MySQL.
▪ Desde el terminal A vamos a ejecutar las
siguientes sentencias SQL:

05/03/2022
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
-- 1. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 2. Ejecutamos una transacción para transfereir dinero entre dos cuentas
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
NOTA: Observe que la transacción que estamos ejecutando en el terminal A todavía no ha
finalizado, porque no hemos ejecutado COMMIT ni ROLLBACK.

05/03/2022
Ahora desde el terminal B ejecute las siguientes sentencias SQL:
-- 1. Seleccionamos la base de datos
USE test;
-- 3. Iniciamos una transacción y observamos los datos que existen en la tabla cuentas
START TRANSACTION;
SELECT * FROM cuentas WHERE id = 1;
Ahora ejecute ROLLBACK en el terminal A para finalizar la transacción que estaba sin
finalizar.
-- 3. Deshacemos las operaciones realizadas en la transacción
ROLLBACK;
Desde el terminal B vuelva a ejecutar esta sentencia:
-- 4. Observamos los datos que existen en la tabla cuentas

05/03/2022
aislamiento ante el problema Dirty Read.
▪ ¿Qué es lo que ha sucedido? Repita el ejercicio utilizando los otros
niveles de aislamiento (READ COMMITTED, REPEATABLE READ
y SERIALIZABLE). Tendrá que configurar el nivel de aislamiento
que va a utilizar durante la sesión con las siguientes sentencias:
• SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
• SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
• SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

05/03/2022
Ejemplo 2: Evaluación de los niveles de aislamiento
ante el problema Non-Repeatable Read.
concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos

05/03/2022
USE test;
);
START TRANSACTION;

05/03/2022
Ahora volvemos a ejecutar en el terminal A la misma consulta que ejecutamos al inicio de
la transacción.
USE test;
-- 3. Iniciamos una transacción y atualizamos los datos de la tabla cuentas
START TRANSACTION;
-- 4. Finalizamos la transacción con COMMIT
COMMIT;
-- 4. Volvemos a ejecutar la misma sentencia para observar los datos que existen en la tabla cuentas
SELECT saldo FROM cuentas WHERE id = 1;

05/03/2022
Ejemplo 2: Evaluación de los niveles de aislamiento
ante el problema Non-Repeatable Read.
▪ ¿Qué es lo que ha sucedido? Repita el ejercicio utilizando los otros
niveles de aislamiento (READ COMMITTED, REPEATABLE READ
y SERIALIZABLE). Tendrá que configurar el nivel de aislamiento
que va a utilizar durante la sesión con las siguientes sentencias:
• SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
• SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
• SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

05/03/2022
aislamiento ante el problema Phantom Read.
concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos

05/03/2022
USE test;
);
START TRANSACTION;
SELECT SUM(saldo) FROM cuentas;

05/03/2022
Ahora volvemos a ejecutar en el terminal A la misma consulta que ejecutamos al inicio de
la transacción.
USE test;
-- 3. Iniciamos una transacción y atualizamos los datos de la tabla cuentas
START TRANSACTION; INSERT INTO cuentas VALUES (4, 3000);
-- 4. Finalizamos la transacción con COMMIT
COMMIT;
-- 4. Volvemos a ejecutar la misma sentencia para observar los datos que existen en la tabla cuentas
SELECT SUM(saldo) FROM cuentas;

05/03/2022
Contenido

05/03/2022
Políticas de bloqueo en MySQL
▪ Cuando una transacción accede a los datos lo hace
de forma exclusiva, de modo que una transacción no
podrá acceder a los datos que están siendo utilizados
por una transacción hasta que ésta haya terminado.
▪ El bloqueo de los datos se puede realizar a nivel de:
• Base de datos.
• Tabla.
• Fila.
• Columna.
▪ InnoDB realiza por defecto un bloqueo a nivel de fila.

05/03/2022
USE test;
);
START TRANSACTION;
En este ejemplo vamos a simular que hay dos usuarios que quieren acceder de forma
concurrente a los mismos datos de una tabla. Para simular los dos usuarios vamos a iniciar dos
terminales para conectarnos a un servidor MySQL. Desde el terminal A vamos a ejecutar las

05/03/2022
USE test;
-- 2. Observamos los datos que existen en la tabla cuentas
SELECT * FROM cuentas;
-- 3. Intentamos actualizar el saldo de una de las cuentas que está siendo utilizada en la transacción del
terminal A
¿Qué es lo que ha ocurrido en el terminal B? ¿Puedo acceder a los datos para consultaros?
¿Y para modificarlos? ¿Puedo modificar desde el terminal B una cuenta bancaria que no esté
siendo utilizada por la transacción del terminal A?
Ahora ejecute COMMIT en el terminal A para finalizar la transacción que estaba sin finalizar.
¿Qué es lo que ha sucedido?

05/03/2022
Concurrencia
Unidad 9
Final de la unidad
Y del curso…. !Muchas gracias
a todos!

DB1 Unidad 9: Concurrencia

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a DB1 Unidad 9: Concurrencia

Similar a DB1 Unidad 9: Concurrencia (20)

Más de Franklin Parrales Bravo

Más de Franklin Parrales Bravo (20)

DB1 Unidad 9: Concurrencia