Concurrencia

Concurrencia
Índice
? Control de concurrencia basado en la técnica de reserva
Concurrencia
?
Protocolo de dos fases
?
El planificador. ¿Cómo usa los locks?
?
Granularidad múltiple
? Control de Concurrencia basado en la marca de tiempo
? Control de Concurrencia basado en la técnica de validación
? Niveles de aislamiento en SQL2 (ORACLE)
© O. Díaz, A. Illarramendi UPV/EHU
1
Planificación serializable
Protocolos de concurrencia
?En la práctica es difícil comprobar la
serializabilidad de una planificación.
?Para asegurar que las transacciones se “enreden” de
forma serializable, el SGBD impone unas reglas en
el momento de utilizar los gránulos: el protocolo
?Por ello la estrategia que se sigue en casi
todos los sistemas prácticos es encontrar
métodos que garanticen la serializabilidad
sin tener que verificar las planificaciones.
© O. Díaz, A. Illarramendi UPV/EHU
?Tres protocolos:
?
?
?
3
Control de Concurrencia basado en
la técnica de reserva
?Ya que los conflictos se producen por acceder a los
mismos datos, una forma de asegurar la seriabilidad es
controlar el acceso.
?Reserva (Bloqueo). Cuando una transacción está
accediendo a la BD, una reserva puede denegar el
acceso a otras transacciones con el fin de impedir que
se produzcan resultados incorrectos.
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
2
5
el de reserva, de Bloqueo (locks)
el de la marca de tiempo (time stamping)
el de validación
© O. Díaz, A. Illarramendi UPV/EHU
4
Control de Concurrencia basado en
la técnica de reserva
?
cada gránulo se encuentra en un estado de
reserva (disponible,compartido,exclusivo)
?
protocolo:
? antes
de acceder a un dato, se realiza una petición de
reserva (lock) compartida (si se va a leer) o en
exclusiva (si se va a escribir)
? si la petición no puede ser atendida, la transacción
tendrá que esperar hasta que el gr ánulo se libere
© O. Díaz, A. Illarramendi UPV/EHU
6
1
Concurrencia
Modos mediante los cuales se
pueden bloquear los datos
Protocolo basado en la reserva
?Compartido (Shared). Si una transacción Ti
obtiene un bloqueo en modo compartido
sobre el elemento Q, entonces Ti puede leer
Q pero no lo puede escribir
?Exclusivo. Si una transacción Ti obtiene un
bloqueo en modo exclusivo sobre el
elemento Q entonces Ti puede tanto leer
como escribir Q
© O. Díaz, A. Illarramendi UPV/EHU
?El planificador utiliza una tabla de locks
Peticiones de las Transacciones
7
Utilización de las op. de reserva
?Protocolo:
Una transacción no realizará una petición de
reserva (compartida o exclusiva) para un
elemento X si ya posee una reserva (compartida
o exclusiva) para dicho elemento X. (Esta regla puede
tener excepciones).
Una transacción no realizará una petición de
unlock para X a menos que ya posea una reserva
(compartida o exclusiva) para el elemento X.
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
© O. Díaz, A. Illarramendi UPV/EHU
8
Utilización de las op. de reserva
?Operaciones de reserva sobre los elementos:
? solicitud de reserva compartida (lectura): lock_S(G)
? solicitud de reserva exclusiva (escritura): lock_X(G)
? liberación de la reserva: unlock(G)
?Proceso: matriz de compatibilidad
S- Shared (Compartido) X Exclusive (Exclusivo)
solicitud S solicitud X
estado disp
si
si
estado S
si
no
estado
no
no
9
© O. Díaz, A. Illarramendi
UPV/EHUX
?
Planificación Serializable
?Elementos de la Tabla: para cada gránulo se guarda
el estado en el que se encuentra: disponible,
compartido, exclusivo
Implementación
?
PLANIFICADOR
Tabla
Lock
( v$LOCK)
11
T1
? Protocolo:
?
?
antes de acceder a un dato,
se realiza una petición de
reserva compartida (si se va
a leer) o en exclusiva (si se
va a escribir)
si la petición no puede ser
atendida, la transacción
tendrá que esperar hasta que
el gránulo se libere
? Las op. de reserva las
realiza el planificador
LOCK_X(A)
READ(A,t)
t := t - 50
WRITE(A,t)
LOCK_S(B)
.....
.....
.....
UNLOCK(A)
.....
.....
READ(B,t)
UNLOCK(B)
T2
LOCK_X(A)
READ(A,t)
aux := t * 0,1
t := t - aux
WRITE(A,t)
UNLOCK(A)
LOCK_S(B)
READ(B,t)
UNLOCK(B)
© O. Díaz, A. Illarramendi UPV/EHU
10
Utilización de las op. de reserva
T1
LOCK_X(A)
READ(A,t)
t := t - 50
WRITE(A,t)
UNLOCK(A)
T2
LOCK_X(A)
READ(A,t)
aux := t * 0,1
t := t - aux
WRITE(A,t)
UNLOCK(A)
LOCK_X(B)
READ(B,t)
t := t + aux
WRITE(B,t)
UNLOCK(B)
LOCK(B)
READ(B,t)
t := t + 50
WRITE(B,t)
© O. Díaz,
A. Illarramendi UPV/EHU
UNLOCK(B)
? Se podría pensar en
mejorar la concurrencia,
liberando los gr ánulos lo
antes posible
? Pero... no garantiza la
seriabilidad
? En el ejemplo, T2 ve
?
?
el dato A después de
modificarlo T1
el dato B antes de
modificarlo T1
12
2
Concurrencia
Protocolo de dos fases (2PL)
(Básico)
Protocolo de dos fases (2PL)
(Básico)
? Para garantizar que sea serializable en conflicto se añade una tercera regla:
?
en toda transacción, todas las peticiones de reserva deben preceder a
cualquier petición de liberación (Bloqueo en 2 fases 2PL)
? Puede demostrarse que si toda transacción de una
planificación sigue el protocolo de bloqueo en dos fases,
puede garantizarse que la planificación será serializable en
términos de conflictos (Eswaran et al. 1976)
? Problemas que no resuelve el 2PL:
?
?
? Dentro de la transacción se distinguen dos fases:
? de crecimiento o reserva de datos (durante la cual se puede reservar pero no liberar)
? de encogimiento o liberación de datos (durante la cual se puede liberar perno no reservar)
© O. Díaz, A. Illarramendi UPV/EHU
?
? 2PL NO permite todos los planes seralizables. Puede limitar
la concurrencia.
13
Anulaciones en Cascada (ejemplo)
T2
T1
ROLLBACK
ROLLBACK
© O. Díaz, A. Illarramendi UPV/EHU
15
Protocolo de 2PL. Interbloqueos
Problema (Abrazo mortal). Técnicas para
gestionarlos
T2
LOCK_X(A)
READ(A,t)
t := t - 50
WRITE(A,t)
?Evitar los interbloqueos (deadlocks):
?
LOCK_S(B)
READ(B,t)
LOCK_S(A)
LOCK_X(B)
esperando por A
técnicas de prevención
?Detectar los interbloqueos
?
ABD 2006-2007
Variantes del protocolo de 2
fases.
? 2PL (B2F) Riguroso. Una transacción no libera ninguna de sus reservas
(exclusivas o compartidas) hasta después de confirmarse o abortar.
(evita anulaciones en cascada)
LOCK_S(A)
ROLLBACK
© O. Díaz, A. Illarramendi UPV/EHU
14
? 2PL (B2F) Estricto. Una transacción no libera ninguna de sus reservas
exclusivas antes de confirmarse o abortar. (variante más usada en la
práctica).
LOCK_X(A)
READ(A,t)
t:=t+100
WRITE(A,t)
UNLOCK(A)
esperando por B
© O. Díaz, A. Illarramendi UPV/EHU
? 2PL (B2F) Conservador o estático. Una transacción debe reservar todos
los elementos a los que tendrá acceso antes de comenzar a ejecutarse,
pre-declarando su conjunto de lectura y conjunto de escritura. (no
produce el abrazo mortal) (difícil de usar en la práctica)
T3
LOCK_X(A )
READ(A,t)
LOCK_S(B)
t := t – 50
READ(B,s)
WRITE(A,t)
UNLOCK(A )
T1
Anulaciones en Cascada
El deadlock (abrazo mortal, interbloqueo)
Bloqueo indefinido
© O. Díaz, A. Illarramendi UPV/EHU
Protocolo de 2PL. Interbloqueos
PREVENCIÓN
?Temporizaciones
17
DETECCIÓN
? Técnica
? Técnica:
? Periódicamente, el sistema comprueba
? cada transacción reserva todos
que no se han producido bloqueos
sus datos desde el principio
entre las transacciones
(conservador)
? Mecanismos: grafo de espera,
? la reserva de datos es tratada
“ timeout”
como unidad atómica (si no es posible
? Atractiva si sabemos que va a haber
obtener alguna de las reservas no se reservara
ninguno de ellos)
técnicas de detección
16
poca interferencia entre las
transacciones
? Problemas
? Riesgo de bloqueo. Factores:
? requiere conocer todos los datos
? nº de gránulos utilizados
que se van a utilizar a lo largo
? tamaño del gránulo
de la transacción
? grado de “ compartición” de gránulos
? los datos están reservados
? duración de las transacciones
durante más tiempo
© O. Díaz, A. Illarramendi UPV/EHU
18
3
Concurrencia
Protocolo de 2PL. Interbloqueos
Recuperación cuando se detecta un
interbloqueo
?Temporizaciones:
? Se necesitará abortar una o más transacciones. En algunas
circunstancias, la elección de las transacciones que hay que abortar
puede ser obvia, en otras puede que no sea clara. Interés: abortar
transacciones que supongan el mínimo coste. Consideraciones:
?
?
?
Cuánto tiempo lleva ejecutándose la transacción (menor)
Cuántos elementos de datos han sido actualizados por la transacción
(pocos)
Cuántos elementos de datos debe todavía actualizar la transacción
(muchos)
© O. Díaz, A. Illarramendi UPV/EHU
19
Protocolo de 2PL. Problema
Espera Indefinida
?
21
Protocolo 2PL. Técnica del
upgrading (promocionar)
? Un patrón frecuente es
primero leer un gránulo
para más tarde
modificarlo...
T1
LOCK_S(A1)
LOCK_S(A2)
LOCK_S(A3)
LOCK_S(An)
READ(A1,t1)
READ(A2,t2)
? En estos casos, para reducir
el tiempo en el que el
gránulo está reservado en
exclusiva, se reserva
primero en S, y sólo cuando
se va a escribir se solicita la
reserva en X
sólo durante este intervalo
reservadoUPV/EHU
en X
© O.está
Díaz,A1
A. Illarramendi
ABD 2006-2007
20
LOCK_X(A1)
LOCK_S(A2)
LOCK_S(A3)
LOCK_S(An)
READ(A1,t1)
READ(A2,t2)
?Mientras tanto, T2 tiene
que esperar
READ(A3,t3)
.......
?A veces se reserva antes de
necesitarlo.
READ(An,tn)
WRITE(A1,t1)
UNLOCK(A1)
UNLOCK(A2)
UNLOCK(A3)
..
UNLOCK(An)
T2
LOCK_S(A1)
READ(A1,t)
© O. Díaz, A. Illarramendi UPV/EHU
22
Técnica del upgrading. Problema
T2
•La promoción puede tener lugar sólo en la fase de crecimiento.
•Si T es la única transacción con reserva de lectura S para A en el
momento en que emite la operación de reserva X para A, es posible
promocionar el bloqueo, de lo contrario la transacción debe esperar.
•Con la técnica del upgrading se pueden producir un tipo adicional de
inter-bloqueo
LOCK_S(A1)
READ(A1,t1)
LOCK_S(A2)
READ(A2,t2)
UNLOCK(A1)
UNLOCK(A2)
T1
LOCK_S(A)
READ(A,t1)
READ(An,tn)
LOCK_X(A1)
WRITE(A1)
UNLOCK(A1)
..
UNLOCK(An)
© O. Díaz, A. Illarramendi UPV/EHU
?A1 no se puede liberar
hasta que se haya reservado
el último gránulo
uso de una cola del tipo “el que llega primero tiene
prioridad”.
Almacenar el número de veces que una transacción ha
sido seleccionada como víctima y fijar un límite superior
© O. Díaz, A. Illarramendi UPV/EHU
Una transacción que solicite un bloqueo esperará
únicamente durante un periodo de tiempo
definido por el sistema. Si no se concede el
bloqueo dentro de ese periodo, se aborta y
reinicia la transacción.
Protocolo 2PL. Limita la
concurrenciaT1
?Una transacción no puede continuar durante un
periodo indeterminado mientras que otras
transacciones continúan con normalidad
?Posibles soluciones
?
Protocolo de 2PL. Interbloqueos
T2
LOCK_S(A)
READ(A,t1)
LOCK_X(A)
LOCK_X(A)
permite que T2 se ejecute
concurrentemente con T1
23
© O. Díaz, A. Illarramendi UPV/EHU
24
4
Concurrencia
Solución: update locks
•Update lock: LOCK_U(G)
•permite sólo leer
•únicamente el LOCK U(G) puede promocionar
después. La reserva S no puede promocionar.
T1
LOCK_S(A)
READ(A,t1)
Solución: update locks
T2
LOCK_U(A)
READ(A,t1)
LOCK_X(A)
LOCK_X(A)
WRITE(A)
......
• Para evitar inter-bloqueos, sólo una
transacción puede tener este privilegio:
matriz de compatibilidad asimétrica
estado S
estado X
estado U
solicitud
S
si
solicitud
X
no
solicitud
U
no
no
no
no
no
no
si
T1
LOCK_U(A)
READ(A,t1)
T2
LOCK_S(A)
LOCK_X(A)
así T1 puede
promocionar a X
© O. Díaz, A. Illarramendi UPV/EHU
25
Protocolo de 2PL. incremental
locks
?Interesante en algunas situaciones.
?“Muchas” transacciones operan en la BD
únicamente incrementando y disminuyendo valores
almacenados.
?La propiedad interesante de estas acciones
(incremento y disminución) es que conmutan entre
si (ya que las dos transacciones añaden constantes
al mismo elemento de la BD) pero no con las
operaciones de lectura y escritura.
© O. Díaz, A. Illarramendi UPV/EHU
27
Protocolo de 2PL. incremental
locks
?INC
?
entra en conflicto con otras lecturas o escrituras
es conmutativa con otras INC
?matriz
solicitud solicitud
de compatibilidad
S
X
estado S
si
no
estado X
no
no
estado INC
no
no
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
© O. Díaz, A. Illarramendi UPV/EHU
26
Protocolo de 2PL. incremental
locks
?INC(A,cte,t) = {READ(A,t); t := t + cte;
WRITE(A,t)} Operación con ejecución atómica.
? Ejemplos de transacciones (transacciones de cargo y abono)
? transferencia entre dos cuentas corrientes
? venta de billetes que disminuye el número de plazas disponibles
INCT1(A,2,t)
INCT2(A,10,t)
A=7
A=5
A = 17
INCT2(A,10,t)
INCT(A,c,t) significa:
READ(A,t), t:=t+c,
A = 15
©
O.
Díaz,
A.
Illarramendi
UPV/EHU
WRITE(A,t)
INCT1(A,2,t)
28
El planificador. ¿Cómo usa los
locks?
•el planificador es el responsable
de las reservas y liberaciones
•(las transacciones NO)
? Puede producir planes correctos que no sean serializables
?
?Se puede dar LOCKU en (A) cuando existan
reservas de tipo S sobre A pero una vez que exista
un LOCKU sobre A no podemos dar ningún otro
tipo de reserva sobre A (de lo contrario podría no
promocionar nunca)
la transacción
READ(A,t) + ¿ se leerá A?
planificador I
tabla de
reservas
solicitud
INC
no
no
si
LOCK_S(A); READ(A,t)
planificador II
29
•los gránulos son liberados
cuando el gestor de transacciones
indica que la transacción ha
o ha sido
confirmada
©abortado
O. Díaz, A. Illarramendi
UPV/EHU
READ(A,t)
buffers
30
5
Concurrencia
El planificador. Tabla de
reserva
Tabla de reserva
Para aquellos gránulos que están siendo reservados, se guarda:
• Group mode: reserva más fuerte de las realizadas sobre G por una transacción.
• Waiting?: indica si hay al menos una transacción esperando por G
• List: lista de transacciones que tienen o esperan una reserva sobre G
Id. Gránulo
Group mode
Waiting?
List
G1
S
no
List1
G2
U
YES
List2
G3
S
no
List3
LIST es una lista de registros con los siguientes campos
. Nombre de la Transacci ón
• Mode: tipo de reserva
• Wait ?: indica si la transacci ón tiene o espera hacer una reserva
• Tnext: enlace a la siguiente reserva sobre G hecha por esta transacción
• Next: enlace entre reservas
T1 | S | no | |
T1 | U| no | |
31
procedure realizar_acción(A: acción, G:gránulo, T: transacción)
case A do
write, read:
hacer A sobre la BD
lock
:
consultar tablaDeReserva(G);
if lock sobre G posible
then realizar el lock
else poner en espera T;
actualizar tablaDeReserva(A,G,T)
commit,abort:
liberar los gránulos de T
actualizar tablaDeReserva(A,G,T)
if trans. esperando por gránulos liberados
then reanudar estas transacciones
32
? Ante la liberación de un gránulo G, ¿a cuál de las transacciones en
espera se le asigna G?
? FIFO. Asignar G a la transacción que más tiempo lleve esperando.
Se evita así que una transacción este en una espera continua (efecto
inanición)
Recordar que antes de write/read se realiza el “lock” correspondiente
© O. Díaz, A. Illarramendi UPV/EHU
© O. Díaz, A. Illarramendi UPV/EHU
Planificador. Política de liberaciones
El planificador. Algoritmo
33
Granularidad múltiple
?
Priorizar a las transaccions que quieren leer. Se conceden todas
las peticiones S, y una petición U. Se posponen las peticiones X.
Se puede producir la muerte por inanición
?
Priorizar a las transacciones que quieren promocionar (upgrade)
© O. Díaz, A. Illarramendi UPV/EHU
34
Granularidad múltiple. Niveles
? El tamaño de la unidad de reserva (gránulo) afecta a:
? la concurrencia (inversamente)
? la eficiencia del mecanismo de concurrencia (inversamente)
Tabla
? ¿Cuál es el mejor tamaño del gránulo? Depende de los tipos de transacciones
implicadas.
? Cada transacción puede tener unas necesidades diferentes dependiendo del:
? nº de datos a los que necesite acceder
? duración de la transacción
propagación
del
bloqueo
(implícito)
Bloq1
tupla1
? La granularidad múltiple permite definir distintos niveles de granularidad: tabla,
bloque, tupla
ABD 2006-2007
?Tamaño proporcional al número de
elementos del lock (NO al tama ño de la BD)
T2 | X | yes| |
© O. Díaz, A. Illarramendi UPV/EHU
© O. Díaz, A. Illarramendi UPV/EHU
?Posible implementación como una tabla hash
35
tupla2
Bloq2
Bloq3
tupla3
Cuando una transacción bloquea un nodo, también bloquea todos
los descendientes de ese nodo con el mismo modo de bloqueo.
© O. Díaz, A. Illarramendi UPV/EHU
36
6
Concurrencia
Granularidad múltiple. Ejemplo
Granularidad múltiple
T1: (nivel tabla)
?Supongamos que:
{...... % casi todos los alumnos > 10
UPDATE Alumno
SET nota = nota +1
WHERE edad > 10 .........}
T1:X
?
Alumno
T2: (nivel tupla)
{.......% pocos alumnos son de Berrobi
SELECT *
FROM Alumno
WHERE ciudad=“ Berrobi”....}
juan
?
ana edurnelorena
T2:S
© O. Díaz, A. Illarramendi UPV/EHU
37
Granularidad múltiple
?
39
Bloqueos de intención
ABD 2006-2007
solicitud
IX
si
si
no
no
solicitud
S
si
no
si
no
solicitud
X
no
no
no
no
© O. Díaz, A. Illarramendi UPV/EHU
40
Protocolo de Reservas
?1. Hacer la reserva sobre el nodo raíz.
?2. Un nodo se puede reservar por la
transacción T en modo S o IS sólo si el nodo
padre está reservado en modo IS.
?3. Un nodo se puede reservar por la
transacción T en modo X o IX sólo si el nodo
padre está reservado en modo IX.
?IS: permite leer en nodos inferiores. Implica que
se esta haciendo bloqueo explicito S en un nivel
inferior (o se pedirá).
?IX: permite escribir en nodos inferiores. Implica
que se esta haciendo bloqueo X(y en S) en un nivel
inferior (o se pedirá).
solicitud
IS
estado IS
si
estado IX
si
estado S
si
estado
X
no
© O. Díaz,
A. Illarramendi
UPV/EHU
38
?La solución a la gestión de locks con niveles
diferentes implica el manejo de un nuevo tipo de
locks denominados “warnings” descritos con una I(Intención) inicial.
?Reserva de bloqueo intencional
?Idea: Una transacción indique, a lo largo del camino
desde la raíz hasta el nodo deseado, que tipo de
bloqueo requerirá de uno de los descendientes del
nodo.
Se concede la reserva a T2
Después al considerar la solicitud de T1, el
SGBD debe verificar todas las tuplas para ver si
hay conflicto de reservas. Poco eficiente.
© O. Díaz, A. Illarramendi UPV/EHU
© O. Díaz, A. Illarramendi UPV/EHU
Granularidad múltiple
?¿Qué ocurre si T2 solicita antes que T1?
?
1. T1 solicita y obtiene una reserva exclusiva para la
tabla. Todas las tuplas se reservan de modo exclusivo
(beneficio para T1)
2. T2 solicita una reserva compartida en la tupla “Juan”.
EL SGBD debe verificar la compatibilidad de la reserva
solicitada con las reservas existentes (recorrer el árbol
hacia la raíz). Si aparece un conflicto en cualquier
momento, la reserva no se concede.
41
© O. Díaz, A. Illarramendi UPV/EHU
42
7
Concurrencia
Modo SIX
Bloqueos de intención
?SIX (S+IX): es el “group mode” correspondiente a
un S e IX hechos por la misma transacción
{....
select numCue into :top from CuentaCorriente
where saldo = (select MAX(saldo) from CuentaCorriente)
solicitud solicitud
IS
IX
estado IS
si
si
estado IX
si
si
estado S
si
no
estado SIX
si
no
estado X
no
no
update CuentaCorriente set saldo = saldo + 10000
numCueGroup
= :top
Id.where
Gránulo
mode
cuentaCorriente
SIX
....}
tupla Top
X
Waiting?
no
no
List
List1
List2
T - S - no
T - IX - no
T - X - no
© O. Díaz, A. Illarramendi UPV/EHU
43
?
la transacción NO se ve obligada a reservar más datos de
los necesarios por trabajar con un gránulo grande
?
el número de reservas/liberaciones es menor ya que el
gránulo se ajusta al volumen de datos manejados por la
transacción
© O. Díaz, A. Illarramendi UPV/EHU
?Los SGBD también soportan otro tipo de bloqueos,
denominado cerrojo, que se mantiene durante un
periodo de tiempo mucho más corto que un bloqueo
normal.
?Los cerrojos se usan antes de leer o escribir una
página en disco, con el fin de garantizar que la
operación sea atómica.
?Los cerrojos no necesitan adaptarse al protocolo
normal de control de concurrencia.
ABD 2006-2007
1) transacciones cortas que acceden sólo a unos
pocos elementos
2)transacciones largas que acceden a ficheros
completos
© O. Díaz, A. Illarramendi UPV/EHU
46
Control de Concurrencia basado en la
marca de tiempo
Cerrojos
© O. Díaz, A. Illarramendi UPV/EHU
?Esta técnica resulta adecuada a la hora de
procesar una combinación de transacciones
que incluyen:
?
45
44
Granularidad múltiple. Ventajas
?
?Mejora la eficiencia del mecanismo de reserva
solicitud
X
no
no
no
no
no
?El modo SIX no se solicita. Es un agregado de
S+IX para comodidad del planificador
© O. Díaz, A. Illarramendi UPV/EHU
Granularidad múltiple. Ventajas
?Intensifica la concurrencia
solicitud
S
si
no
si
no
no
47
?Técnica optimista
?
arregla el problema cuando se produce. La técnica de
bloqueo es pesimista, previene el problema
?Cada transacción tiene asociada una marca de tiempo
(mt) (timestamp) asignada por el sistema al empezar
su ejecución (no tiene que ser necesariamente de tipo
time)
?Si T2 llega al sistema después de T1, mt(T1) <
mt(T2). Las mt se asignan en orden ascendente.
© O. Díaz, A. Illarramendi UPV/EHU
48
8
Concurrencia
Implementación
Diferencia respecto a las
Técnicas de Locking
? Elementos. Cada gránulo G tiene asociado dos marcas de tiempo, obtenidas
de la mayor mt.(transacción más reciente) entre todas las transacciones que:
? hayan leído G: marca READ_MT(G)
? hayan escrito G: marca WRITE_MT(G)
? Operaciones
? Las mt. son gestionadas internamente por el sistema
? Proceso
? Al acceder un trans. T a un gránulo G, se compara la mt de T con la de G
para comprobar que la planificación en serie equivalente no es violada
? Si este orden es violado, se hace rollback de T
? T nunca espera, por tanto T nunca se queda bloqueado
? Si T aborta, también deberá abortarse cualquier transacción que pueda
haber usado un valor escrito por T (y así en cascada)
?T. Marca de tiempo:
?
?
cuando algo va mal aborta la transacción
Ordenan la ejecución de las transacciones según un plan
en serie equivalente
?T. Locking:
?
?
no abortan, retrasan.
Las planificaciones serializables producidas tienen sus
planes equivalentes basados en el orden en que las
transacciones en ejecución reservan los elementos que
requieren
© O. Díaz, A. Illarramendi UPV/EHU
49
© O. Díaz, A. Illarramendi UPV/EHU
Implementación
Marcas de Tiempo (básico)
planif. en serie
T1,T2,T3,T4
? Definición: planificación en serie que resulta de ordenar las
transacciones según su marca de tiempo
? mt(T1) < mt(T2) < mt(T3) ?
planif. en serie: {T1,T2, T3}
? Este orden serial puede violarse si se adelanta alguna trans. con m.t.
mayor,
1ª transacción T1
2ª transacción T2
Granulo A
planificador
•READ_MT:
•WRITE_MT
3ª transacción T3
4ª transacción T4
© O. Díaz, A. Illarramendi UPV/EHU
51
? Proceso:
cuando T
si antes otra transacción
quiere ...
con m.t. mayor ha ...
READ(G)
READ(G)
WRITE(G)
READ(G)
READ(G)
WRITE(G)
WRITE(G)
WRITE(G)
T2
READ(A,t)
READ(A,t)
t := t - 50
WRITE(A,t)
READ(B,u)
READ(B,u)
1ª planif. en serie
T1,T2,T3,T4
?esta planificación es
serializable
ABD 2006-2007
READ_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
52
2ª planif. en serie
T1,--,T3,T4, T62
Abortar T2.
La antigua T2 se vuelve a enviar,
y al entrar en el sistema se la bautiza como T62.
?es detectada por el
protocolo de marca de
tiempo
T2
© O. Díaz, A. Illarramendi UPV/EHU
¿cómo se detecta?
¿Qué ocurre al abortar una trans.?
display(t + u)
u := u + 50
WRITE(B,u)
entonces
pasa ...
continuar
abortar
abortar
abortar
© O. Díaz, A. Illarramendi UPV/EHU
Ejemplo
T1
50
T62
?NO es detectada por el
protocolo de reserva
53
© O. Díaz, A. Illarramendi UPV/EHU
54
9
Concurrencia
Control de Concurrencia
basado en la marca de tiempo
básico
Control de Concurrencia
basado en la marca de tiempo
estricto
?Genera planificaciones serializables en conflicto.
?No permite todos los posibles planes serializables
?No tiene lugar el abrazo mortal
?Puede producirse la espera indefinida (una
transacción se aborta y reinicia continuamente)
?Asegura:
?
?
Para ello una transacción que solicita una lectura o
escritura se detiene hasta que una transacción
anterior que escribió el valor haga COMMIT o
ROLLBACK
(Interesante para situaciones donde la mayoría de las
transacciones son de lectura)
© O. Díaz, A. Illarramendi UPV/EHU
55
Control de Concurrencia
basado en la marca de tiempo.
Regla de Thomas
si antes otra transacción
con m.t. mayor ha ...
READ(G)
READ(G)
WRITE(G)
WRITE(G)
entonces
pasa ...
continuar
abortar
abortar
READ_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
© O. Díaz, A. Illarramendi UPV/EHU
57
Marca de tiempo multiversión
MT(T2)=
200
MT(T3)
=175
MT(T4)
=225
A. versión O
A.versión 150
read.MT = 150
read.MT = 200
write.MT = 150
READ(A)
READ(A)
ABD 2006-2007
entonces
pasa ...
continuar
abortar
abortar
ignorar
¿cómo se detecta?
READ_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
WRITE_MT(G) > MT(T)
© O. Díaz, A. Illarramendi UPV/EHU
58
A.versión 200
read.MT = 225
write.MT = 200
© O. Díaz, A. Illarramendi UPV/EHU
si antes otra transacción
con m.t. mayor ha ...
READ(G)
READ(G)
WRITE(G)
WRITE(G)
Marca de tiempo multiversión
READ(A)
WRITE(A)
READ(A)
WRITE(A)
cuando T
quiere ...
READ(G)
WRITE(G)
READ(G)
WRITE(G)
? Como otra transacción más joven se ha adelantado, T lee una
versión de G anterior, con un WRITE_MT mas pequeño
* the Thomas write rule
MT(T1)
=150
56
?Idea: mantener versiones antiguas de los gránulos
?Cada operación escribir crea una nueva versión
?Objetivo: evitar la siguiente situación:
¿cómo se detecta?
ignorar la escritura
y continuar
© O. Díaz, A. Illarramendi UPV/EHU
Marca de tiempo multiversión
(variante)
? No asegura planificaciones serializables en conflicto pero
rechaza menos operaciones de tipo write.
cuando T
quiere ...
READ(G)
WRITE(G)
READ(G)
WRITE(G) *
Planificaciones serializables en conflicto
Con recuperación frente a rollbacks en cascada
59
? Si T escribe G,
? se comprueba que no haya habido otra transacción con MT mayor que haya leído
G (viendo el READ_MT de la versión anterior). (2º conflicto). Si no es posible:
rollback
? se crea una nueva versión de G con WRITE_MT(G) y READ_MT(G) la marca de
tiempo de T
? Si T lee G,
? se busca una versión tal que
? WRITE_MT(G) ? MT(T)
? no existe otra versión G’ tal que WRITE_MT(G) < WRITE_MT(G’) ? MT(T)
? se asigna a READ_MT (G) el valor más alto entre MT(T) y el READ_MT de
la versión actual
? Se destruye una versión de G cuando ya no queda ninguna transacción con MT menor
60
que
el Díaz,
WRITE_MT(G)
© O.
A. Illarramendi UPV/EHU
10
Concurrencia
Diferencia respecto a la técnica
de marca de tiempo clásica
Comparación de métodos
Todas las
planificaciones
?T. Multiversión: mantiene un registro sobre lo que
hacen las transacciones activas. Requiere más
espacio de almacenamiento para mantener múltiples
versiones de los elementos de la Base de Datos.
SV
SC
MT
2PL
?T. Marca de tiempo clásica: mantiene por cada
gránulo las marcas de tiempo de los READ y
WRITE
© O. Díaz, A. Illarramendi UPV/EHU
61
© O. Díaz, A. Illarramendi UPV/EHU
Control de Concurrencia
basado en la técnica de
validación
Control de Concurrencia
basado en la técnica de
validación
? Otro tipo de t écnica de control de concurrencia optimista
? No se efectúa verificación alguna durante la ejecuci ón de las transacciones
? La transacción se ejecuta en tres fases:
? de lectura: sólo se lee valores correctos (con COMMIT) (escritura en variables locales)
? de validaci ón, cuando se comprueba la seriabilidad
? de escritura, cuando se escriben los datos en el buffer global, supuesto T ha pasado
la validaci ón (en caso contrario la transacción se aborta y se reinicia posteriormente)
lectura
validación
62
escritura
?Técnica adecuada si:
?
?
Hay poca interferencia entre las transacciones,
casi todas se validaran sin dificultad
Sin embargo, si hay mucha interferencia, se
desecharan los resultados de muchas
transacciones que se ejecutaran hasta su término
y estas tendrán que reiniciarse posteriormente.
buffer global
© O. Díaz, A. Illarramendi UPV/EHU
63
? Elementos: No están asociados a los gránulos sino a las T:
? READ_SET(T), cjto. de gránulos leídos por T
? WRITE_SET(T), cjto. de gránulos escritos por T
? START(T), momento comienzo fase de lectura
? VAL(T), momento comienzo fase de validación
? END(T), momento finaliza la fase de escritura
?
?
? Se utiliza un enfoque similar a la técnica de marca de
tiempo, pero aquí ...
? ... la marca de tiempo de una transacción es el momento de
su validación. Por tanto...
? ... la planificación en serie equivalente es la que resulta de
ordenar las transacciones en función del comienzo de la fase
de validación
START, transacciones que han comenzado pero no
completado la validación.
VAL, transacciones validadas en fase de escritura
END, transac. que ya han concluido la fase de escritura
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
64
Implementación. Proceso de
validación
Implementación
?
© O. Díaz, A. Illarramendi UPV/EHU
? Suponemos que la fase de escritura es instantánea
65
© O. Díaz, A. Illarramendi UPV/EHU
66
11
Concurrencia
Implementación. Proceso de
validación
Comparación
Una trans. T pasa con éxito la fase de validación, si para cualquier
otra trans. U anterior a la planificación en serie:
? caso 1:
?
U ? END
?
?
T
end(U) < start(T)
cond: true
?
? caso 2:
?
U ? VAL
?
?
start(T) < end(U) < val(T)
cond: RS(T) ? WS(U) = ?
cond: (RS(T) ? WS(T)) ? WS(U) = ?
se guarda el “ estado” para
cada gránulo
? Marca de tiempo
?
T
?
? caso 3:
?
U ? STAR
?
val(U) < val(T)
?
Almacenamiento
? Reserva:
MT por cada gránulo
MT por cada transacción
? Validación
?
T
?
MT por cada transacción
RS, WS por cada trans.
Eficiencia
? Reserva
?
evita rollbacks” incluso con un
alto solapamiento entre
transacciones
? Marca de tiempo, Validación
?
eficientes si trans de sólo lectura
o con poco solapamiento
? Validación
?
detecta la no-seriabilidad más
tarde que las otras técnicas
Se verifica, caso 1, caso 2, caso 3
© O. Díaz, A. Illarramendi UPV/EHU
67
Soporte de transacciones en
SQL
© O. Díaz, A. Illarramendi UPV/EHU
68
Soporte de transacciones en
SQL
?La definición de una transacción SQL es similar al
concepto de transacción ya definido. Es decir, es
una unidad lógica de trabajo y se garantiza que es
atómica.
?A toda transacción se le atribuyen ciertas
características que se especifican con la sentencia
SET TRANSACTION de SQL2. Entre las características
están el modo de acceso y el .
?Con SQL no hay una sentencia explícita
begin_transaction. Sin embargo, toda transacción ha de
tener una sentencia explícita al final (COMMIT o
ROLLBACK)m
© O. Díaz, A. Illarramendi UPV/EHU
69
?Modo de acceso: puede especificarse como READ
ONLY (solo lectura), o READ WRITE (leer y escribir).
Valor por defecto READ WRITE.
© O. Díaz, A. Illarramendi UPV/EHU
70
Soporte de transacciones en
SQL
Niveles de aislamiento en SQL2
Principio ACID
?Una transacción no muestra los cambios que
produce hasta que finaliza (Isolation) Gestor de
Control de Concurrencia
? El nivel de aislamiento especifica el comportamiento de los “locks” en una transacció n. A
menor nivel de aislamiento menor la duració n de las reservas.
? Nivel de aislamiento: representa cómo un SGBD mantiene la integridad
de los datos contra los problemas de lecturas sucias, lecturas fantasmas
y lecturas irrepetibles, las cuales pueden ocurrir debido a transacciones
concurrentes. Se especifica utilizando la sentencia ISOLATION LEVEL
<aislamiento> donde el valor para aislamiento puede ser:
? READ UNCOMMITED
? READ COMMITED
? REPETEABLE READ
? SERIALIZABLE
(por defecto Serializable)
El uso del término SERIALIZABLE se basa en no permitir
violaciones que causen lecturas sucias, lecturas no repetibles ni
fantasmas.(diferente de la noción de seriabilidad vista anteriormente)
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
71
© O. Díaz, A. Illarramendi UPV/EHU
72
12
Concurrencia
El problema de los “dirty reads
(lecturas sucias)”
Lectura Sucia
? Un dato se dice “sucio” si ha sido
escrito por una transacción que
todavía no ha sido confirmada.
T1
T2
LOCK_X(A)
READ(A,t)
t := t - 50
WRITE(A,t)
LOCK_S(B)
UNLOCK(A)
? Una transacción T2 “depende” de
una T1, si T2 lee datos “sucios”
escritos por T1. Si T1 falla, T2
habrá leído un valor incorrecto.
LOCK_X(A)
READ(A,t)
aux := t * 0,1
t := t - aux
WRITE(A,t)
UNLOCK(A)
? “cascading rollback”. Cuando una trans. T1 aborta, todas
aquellas otras trans. que hubieran leído datos “ensuciados” por
T1 (por ejemplo T2), también se ven obligadas a abortar.
? Este es un proceso en “cascada” ya que las trans. depedientes de
T2 se ven a su vez obligadas a abortar. Y así sucesivamente
start_T1
write(A )
error
read(A)
write(B)
start_T2
read(B)
ABORT
© O. Díaz, A. Illarramendi UPV/EHU
start_T3
73
? “Problema de lecturas fantasma (phantom reads)”. Una
trans. A realiza un select con una condición C. Luego, otra
transacción modifica o introduce nuevas tuplas que
satisfacen la condición C. La trans. A vuelve a realizar el
mismo select, y ve estas nuevas tuplas “fantasmas”
75
- aislamiento +
+ concurrencia -
Niveles de aislamiento en
SQL2
© O. Díaz, A. Illarramendi UPV/EHU
76
Niveles de aislamiento en SQL
? “ serializable”. La trans. se ejecuta como si fuera instant ánea: sólo ve UN
estado confirmado de la BD
? “repeatable read”.(lectura repetible) La trans. sólo puede leer datos
confirmados, y si se leé dos veces el mismo dato (una tabla) las tuplas leídas
inicialmente tienen que seguir ahí
? “read committed” (lectura confirmada). La trans. sólo puede leer datos
confirmados, pero cada dato puede estar en un estado diferente.
Nivel de
aislamiento
Dirty-reads
Non-repeatable
reads
Phantom reads
Serializable
No
No
No
Repeatable read
No
No
Sí
Read committed
No
Sí
Sí
Read
uncommitted
Sí
Sí
Sí
SI: significa que el nivel de aislamiento no previene el problema
NO: significa que el nivel de aislamiento previene el problema
? “read uncommitted ” (lectura no confirmada . Se pueden leer datos no
confirmados. (ej. Apl. de procesamiento estadístico)
ABD 2006-2007
74
Fantasmas
?Una transacción T1 puede leer un determinado
valor de una tabla. Si otra transacción T2 actualiza
más tarde dicho valor y T1 lee de nuevo el valor,
T1 verá un valor diferente.
© O. Díaz, A. Illarramendi UPV/EHU
commit
© O. Díaz, A. Illarramendi UPV/EHU
Lecturas no repetibles
© O. Díaz, A. Illarramendi UPV/EHU
commit
READ(B,t)
77
© O. Díaz, A. Illarramendi UPV/EHU
78
13
Concurrencia
Definición de transacciones
Bibliografía
? Inicio:
SET TRANSACTION <modo de acceso>, ISOLATION LEVEL <nivel aislamiento>
<modo de acceso> ::= READ WRITE| READ ONLY
<nivel aislamiento> ::= READ UNCOMMITTED | READ COMMITTED |
REPEATABLE READ | SERIALIZABLE
READ ONLY indica que la trans. sólo contiene SELECTs (sin “ for update”)
READ WRITE indica que la trans. puede contener cualquier instrucción del LMD
? Final:
COMMIT
ROLLBACK
© O. Díaz, A. Illarramendi UPV/EHU
ABD 2006-2007
79
?
Database System Implementation
H. García Molina, J.D. Ullman, J. Widom
Prentice Hall 2000
?
Fundamentals of Database Systems (4. edición 2004) Fundamentos de
Sistemas de Bases de Datos (3. Edición 2002).
R.A. Elmasri, S. B. Navathe . Addison Wesley
?
Sistemas de Bases de Datos. Un enfoque pr áctico para diseño,
implementación y gestión. (4. edición, 2005)
T. Connolly, C. Begg Addison- Wesley
© O. Díaz, A. Illarramendi UPV/EHU
80
14