Concurrencia - adimen.si.ehu.es

1

Concurrencia

© O. Díaz, A. Illarramendi UPV/EHU 2

Índice

Transacción. Definición.Motivación de la ConcurrenciaPlanificadorControl de concurrencia basado en la técnica de reserva

Protocolo de dos fasesEl planificador. ¿Cómo usa los locks?Granularidad múltiple

Control de Concurrencia basado en la marca de tiempoControl de Concurrencia basado en la técnica de validaciónNiveles de aislamiento en SQL2 (ORACLE)


Bibliografía

Database System ImplementationH. García Molina, J.D. Ullman, J. WidomPrentice 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


Definición de transacción

Unidad lógica de procesamiento de la B.D. que incluye una o más operaciones de acceso a la BD que pueden ser de inserción, eliminación, modificación o recuperación.

Cjto. de lecturas/escrituras sobre la BD


Limites de la transacción

Begin Transaction (set_transaction)End Transaction (commit, rollback)

Todas las operaciones entre los límites se considera que forman parte de la transacción.Una aplicación puede contener más de una transacción (si contiene varios límites)


Propiedades de la Transacción

Principio ACID (su cumplimiento debe estar asegurado por el SGBD)Se ejecuta como unidad (Atomicity) Gestor de transacciones, Gestor de recuperación

Preserva la consistencia(Consistency) Gestor de Rest. de integridad

Una transacción no muestra los cambios que produce hasta que finaliza (Isolation) Gestor de Control de Concurrencia

Si termina correctamente, sus cambios permanecen (Durability) Gestor de Recuperaciones


Fin de una transacción

COMMIT. Con éxito. Las actualizaciones que realiza la transacción se graban

ROLLBACK. Con fracaso. Las actualizaciones que realiza la transacción deben deshacerse.


Ejemplo de transacción (1)

• Transacción: unidad de interacción con la BD• No puede quedarse a medias a riesgo de dejar la BD en un estado inconsistente• Es la aplicación (y no el SGBD) el que define que cjto. de acciones constituyen una

transacción• Si se quiere asegurar un orden entre las acciones, englobarlas dentro de una misma

transacción o poner condiciones

% transferencia de 1000 entre dos cuentas corrientasset_transaction

leer(c1.saldo);c1.saldo = c1.saldo - 1000;escribir(c1.saldo);leer(c2.saldo);c2.saldo = c2.saldo + 1000;escribir(c2.saldo);

Commit


Ejemplo de transacción (2)

• Durante la transacción puede NO cumplirse las rest. de integridad• Al finalizar la transacción, todas las restricciones deben ser satisfechas• La transacción es una unidad de consistencia

% Sean las tablas:PASAJERO(Nombre....)VUELO(Codigo....)PAS_VUE(Nombre,Codigo)

con dos restriccionesrest1: todo pasajero debe estar en un vuelorest2: todo vuelo tiene al menos un pasajero

Transacción: asignar el primer pasajero a un aviónset_transaction

insert into VUELO values (123...);insert into PASAJERO values (‘aitor’,....);insert into PAS_VUE values (‘aitor’,123);

Commit


SGBD multi-usuario

Un SGBD es un recurso compartido por varios usuarios accediendo simultáneamenteEsto se soporta mediante:

la multiprogramación, si tenemos sólo una CPUacceso simultáneo, si tenemos varias CPU (procesamiento paralelo)

Acceso a la CPU. Multiprogramación

proceso A

proceso B


Motivación

Premisa: cada transacción ejecutada individualmente preserve la consistencia de la BDPero la ejecución concurrente de las transacciones no nos lleva necesariamente a un estado consistenteProblemas:

pérdida de actualizaciones actualizaciones asumidas lecturas inconsistentes


Motivación

Los mecanismos de concurrencia se fijan principalmente en las operaciones de acceso a la BD de una transacción.

Conclusión: se necesita un mecanismo de control de la concurrencia que asegure que la ejecución concurrente de las transacciones preserve la consistencia.


Ejecución en serieT1 T2

READ(A,t)t := t - 50WRITE(A,t)READ(B,t)t := t + 50WRITE(B,t)

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)READ(B,t)t := t + auxWRITE(B,t)

T1 T2READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)READ(B,t)t := t + auxWRITE(B,t)

READ(A,t)t := t - 50WRITE(A,t)READ(B,t)t := t + 50WRITE(B,t)

A B1000 2000

A B855 2145

T1,T2 A B1000 2000

A B850 2150

T2,T1

tiem

po


Ejecución concurrenteT1 T2

READ(A,t)t := t - 50WRITE(A,t)

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)

READ(B,t)t := t + 50WRITE(B,t)

READ(B,t)t := t + auxWRITE(B,t)

T1 T2READ(A,t)t := t - 50

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)READ(B,t)

WRITE(A,t)READ(B,t)t := t + 50WRITE(B,t)

t := t + auxWRITE(B,t)

A B1000 2000

A B855 2145

T1,T2 A B1000 2000

A B950 2100

T2,T1

tiem

po


Problema. La actualización perdida

leer(x);x:= x - 100;

escribir(x);leer(y);

y := y + 100;escribir(y)

leer(x);x := x + 33;

escribir(x);

T1 T2

tiem

po

x tiene un valor incorrecto porque

su actualización por T1 se sobre-escribió


Problema. La actualización “sucia”(Modificación Temporal)

leer(x);x:= x - 100;escribir(X);

leer(y);errorerror--abortarabortar

leer(x);x := x +50;escribir(x);

T1 T2

tiem

po

T2 ha leído un valor “temporal”

incorrecto de x(valor sucio)


Problema. El resumen incorrecto

leer(x);x:= x - 100;escribir(X);

leer(y);y := y + 100;escribir(y);

suma := 0;leer(A);suma := suma + A;..leer(x);suma := suma + x;leer(y);suma := suma + y;

T1 T2

tiem

po

T2 ha leído el valor de x después de restar n, y

el valor de y antes de sumar n.El valor “suma” no será correcto.


Planificador

Hay que regular el orden en el que se ejecutan las acciones de las diferentes transacciones.

Encargado de la función de control: Planificador (Scheduler)


El planificador (scheduler)

Planificadorle llegan peticiones de lectura/escritura, y bien las ejecuta en los buffers o bien las retrasa

¿Cuándo es problemática la ejecución concurrente?¿Cómo controlar que estos problemas no se dan?

Gestor detransacciones

PlanificadorBuffer

peticionesREAD/WRITE

o.k/wait/abort


Operaciones básicas

Las operaciones básicas de acceso a una BD que una transacción puede incluir son:

leer-elemento (READ)escribir-elemento (WRITE)INPUTOUTPUT

BD

buffer global

buffer local buffer local buffer local buffer local

read/write

input/outputbloque

memoria volátil memoria estable

Área de trabajo privada para cada transacción


Planificación (Plan)

Definición: serie intercalada de acciones de distintas transacciones donde se respeta el orden relativo de la acción dentro de cada transacción. Las acciones que nos interesan son únicamente lecturas/escrituras sobre la base de datos

T1 = {a11,a12,a13} ; T2 = {a21,a22} ; T3 = {a31,a32,a33}Planif(T1,T2,T3) = {a11,a21,a12,a31,a22,a13,a32,a33}

Planificación en SERIE es aquella donde NO se solapan las transacciones

con “n” transacciones tenemos “n!” planificaciones en serieno hay concurrencia

poco eficientesobviamente, no existen los problemas de la ejecución concurrente


Principio de corrección

Cualquier transacción ejecutada de forma aislada transforma un estado consistente en otro estado consistente.

Pero!!!!!!!!!!! Las transacciones se ejecutan concurrentemente


Planificación serializable

Definición: planificación que no siendo en serie, produce un resultado equivalente a una planificación en serie

¿Condición para asegurar que una planificación sea serializable?


Noción de “conflicto”

Conflicto: par de acciones de una planificación tal que si se altera su orden, el resultado de al menos una de las transacciones involucradas puede cambiar. Los conflictos sólo se dan al trabajar sobre un mismo gránulo G.

Gránulo: unidad de reserva

Acción 1 Acción 2 ¿conflicto?READ(G,t) READ(G,t) NOREAD(G,t) WRITE(G,t) SIWRITE(G,t) READ(G,t) SIWRITE(G,t) WRITE(G,t) SI


Conflicto

Dos acciones de dos transacciones diferentes NO se pueden intercambiar (están en conflicto) si:

Trabajan con el mismo elemento de la BDAl menos una de ellas es una operación de escritura


Planificaciones equivalentes enconflictos

Dos planificaciones son “equivalentes en conflictos” si se puede convertir una en otra siguiendo una secuencia de intercambios no conflictivos (es decir, sin cambiar el resultado final) entre acciones adyacentes

Se cumple que el orden de dos acciones cualesquiera en conflicto es el mismo en ambas planificaciones.

Nota: La equivalencia por resultados no sirve para definir la equivalencia entre planificaciones


Planificación serializable en conflictos

Una planificación es “serializable en conflicto” si es equivalente en conflicto a una planificación en serie


¿Cuál es su planif. en serie equivalenteT1 T2


READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)

READ(B,t)t := t + 50WRITE(B,t)

READ(B,t)t := t + auxWRITE(B,t)

T1 T2READ(A,t)t := t - 50

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)READ(B,t)

WRITE(A,t)READ(B,t)t := t + 50WRITE(B,t)

t := t + auxWRITE(B,t)

planif. en serie: T1,T2 No es serializable en conflictos


Condición de serializable en conflictos

De cara a garantizar la seriabilidad, esta condición (la “de serializable en conflictos”) es suficiente. Lo imponen los sistemas comerciales

planificaciones serializables

planificaciones serializables en conflictos


Grafo de precedencia de una planif. (Grafo de serialización)

Nodo: para cada una de las transacciones de la planificación

Arco de T1 a T2 si existe una acción a1 de T1 y una acción a2 de T2 tal que:

a1 se encuentra antes que a2 en la planif.a1 y a2 actuan sobre el mismo gránulobien a1 ó a2 es una escritura

El grafo precedencia de una planif. en serie NO tiene ciclosEl grafo de precedencia de una planif serializable NO puede tener ciclos

Nota: Existe un algoritmo para construir grafos de precedencia


Planificación serializable

En la práctica es difícil comprobar la seriabilidad de una planificación.

Por ello la estrategia que se sigue en casi todos los sistemas prácticos es encontrar métodos que garanticen la seriabilidad sin tener que verificar las planificaciones.


Protocolos de concurrencia.

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

Tres protocolos:el de reserva (locks)el de la marca de tiempo (time stamping)el de validación


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:

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


Modos mediante los cuales se pueden bloquear los datos

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 escribirExclusivo. Si una transacción Ti obtiene un bloqueo en modo exclusivo sobre el elemento Q entonces Ti puede tanto leer como escribir Q


Protocolo basado en la reserva

El planificador utiliza una tabla de locks

Elementos de la Tabla: para cada gránulo se guarda el estado en el que se encuentra: disponible, compartido, exclusivo

PLANIFICADORTablaLock

Peticiones de las Transacciones

Planificación Serializable


Implementación

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 compatibilidadS- Shared (Compartido) X Exclusive (Exclusivo)

solicitud S solicitud Xestado disp si si

estado S si noestado X no no


Utilización de las op. de reserva

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

T2

LOCK_X(A)

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)UNLOCK(A)LOCK_S(B)READ(B,t)UNLOCK(B)

T1LOCK_X(A) READ(A,t)t := t - 50

WRITE(A,t)LOCK_S(B) ...............UNLOCK(A)..........READ(B,t)UNLOCK(B)



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.



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 T1el dato B antes de modificarlo T1

T1 T2LOCK_X(A)READ(A,t) LOCK_X(A)t := t - 50WRITE(A,t)UNLOCK(A)

READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)UNLOCK(A)LOCK_X(B)READ(B,t)t := t + auxWRITE(B,t)UNLOCK(B)

LOCK(B)READ(B,t)t := t + 50WRITE(B,t)UNLOCK(B)


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

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)

Un problema que no resuelve el 2PL es el deadlock (abrazo mortal)2PL NO permite todos los planes seralizables. Puede limitar la concurrencia.


Variantes del protocolo de 2 fases.

2PL (B2F) Conservador o estático. Una transacción debe reservar todoslos elementos a los que tendrá acceso antes de comenzar a ejecutarse, predeclarando su conjunto de lectura y conjunto de escritura. (no produce el abrazo mortal) (difícil de usar en la práctica)

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

2PL (B2F) Riguroso. Una transacción no libera ninguna de sus reservas (exclusivas o compartidas) hasta después de confirmarse o abortar.


Protocolo de 2PL. Inter-bloqueosProblema (Abrazo mortal)

T1 T2LOCK_X(A)READ(A,t)t := t - 50WRITE(A,t)

LOCK_S(B)READ(B,t)LOCK_S(A)

LOCK_X(B)

esperando por B esperando por A

Evitar los inter-bloqueos (deadlocks):

técnicas de prevención

Detectar los inter-bloqueos

técnicas de detección


Protocolo de 2PL. Inter-bloqueos

Técnica:cada transacción reserva todossus datos desde el principiola reserva de datos es tratada como unidad atómica (si no es posible obtener alguna de las reservas no se reservara ninguno de ellos)

Problemasrequiere conocer todos los datos que se van a utilizar a lo largo de la transacciónlos datos están reservados durante más tiempo

TécnicaPeriódicamente, el sistema compruebaque no se han producido bloqueos entre las transaccionesMecanismos: grafo de espera, “timeout”Atractiva si sabemos que va a haber poca interferencia entre las transacciones

Riesgo de bloqueo. Factores:nº de gránulos utilizadostamaño del gránulogrado de “compartición” de gránulosduración de las transacciones

PREVENCIÓN DETECCIÓN


Protocolo de 2PL. Problema Espera Indefinida

Una transacción no puede continuar durante un periodo indeterminado mientras que otras transacciones continúan con normalidad

Posible solución: uso de una cola del tipo “el que llega primero tiene prioridad”.


Protocolo 2PL. Limita la concurrencia

A1 no se puede liberar hasta que se haya reservado el último gránulo

Mientras tanto, T2 tiene que esperar

A veces se reserva antes de necesitarlo.

T1 T2LOCK_X(A1)LOCK_S(A2)LOCK_S(A3)LOCK_S(An) READ(A1,t1)READ(A2,t2) LOCK_S(A1)

READ(A3,t3) .......

READ(An,tn)WRITE(A1,t1)UNLOCK(A1)UNLOCK(A2) READ(A1,t)UNLOCK(A3)..UNLOCK(An)


Protocolo 2PL. Técnica del upgrading (promocionar)

T1 T2LOCK_S(A1)LOCK_S(A2)LOCK_S(A3)LOCK_S(An) READ(A1,t1) LOCK_S(A1)

READ(A1,t1)READ(A2,t2) LOCK_S(A2)

READ(A2,t2)UNLOCK(A1)UNLOCK(A2)

READ(An,tn)

LOCK_X(A1)WRITE(A1)UNLOCK(A1)..UNLOCK(An)

sólo durante este intervaloestá A1 reservado en X

permite que T2 se ejecuteconcurrentemente con T1

Un patrón frecuente es primero leer un gránulo para más tarde modificarlo...

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


Técnica del upgrading. Problema

T1 T2LOCK_S(A)READ(A,t1) LOCK_S(A)

READ(A,t1)LOCK_X(A)

LOCK_X(A)

•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


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.

• Para evitar inter-bloqueos, sólo una transacción puede tener este privilegio: matriz de compatibilidad asimétrica

solicitudS

solicitudX

solicitudU

estado S si no siestado X no no noestado U no no no

T1 T2LOCK_S(A)READ(A,t1) LOCK_U(A)

READ(A,t1)LOCK_X(A)

LOCK_X(A)WRITE(A)......

T1 T2LOCK_U(A)READ(A,t1) LOCK_S(A)

LOCK_X(A)

así T1 puedepromocionar a X


Solución: update locks

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)


Protocolo de 2PL. incremental locks

INC(A,cte,t) = {READ(A,t); t := t + cte; WRITE(A,t)}Ejemplos de transacciones (transacciones de cargo y abono)

transferencia entre dos cuentas corrientesventa de billetes que decrementa el número de plazas disponibles

Esta operación es conmutativa consigo mismaEl orden de ejecutar las operaciones conmutativas no es importante

A = 5

A = 15

A = 7A = 17

INCT1(A,2,t)

INCT1(A,2,t)

INCT2(A,10,t)

INCT2(A,10,t)INCT(A,c,t) significa:READ(A,t), t:=t+c,

WRITE(A,t)


Protocolo de 2PL. incremental locks

Puede producir planes correctos que no sean serializablesINC

entra en conflicto con otras lecturas o escriturases conmutativa con otras INC

matriz de compatibilidadsolicitudS

solicitudX

solicitudINC

estado S si no noestado X no no no

estado INC no no si


El planificador. ¿Cómo usa los locks?

la transacción

planificador I

planificador II

tabla dereservas

READ(A,t) + ¿se escribirá A?

LOCK_S(A); READ(A,t)

READ(A,t)

•el planificador es el responsable de las reservas y liberaciones•(las transacciones NO)

•los gránulos son liberados cuando el gestor de transacciones indica que la transacción ha abortado o ha sido confirmada

buffers


Para aquellos gránulos que estan siendo reservados, se guarda:• Group mode: reserva más fuerte de las realizadas sobre G• Waiting?: indica si hay al menos una transacción esperando por G• List: lista de transacciones que tienen o esperan una reserva sobre G

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

El planificador. Tabla de reserva

Id. Gránulo Group mode Waiting? ListG1 S no List1G2 U YES List2G3 S no List3

T1 | S | no | | T1 | U| no | | T2 | X | yes| |


Tabla de reserva

Posible implementación como una tabla hash

Tamaño proporcional al número de elementos del lock.


El planificador. Algoritmoprocedure realizar_acción(A: acción, G:gránulo, T: transacción)

case A dowrite, read: hacer A sobre la BDlock : consultar tablaDeReserva(G);

if lock sobre G posiblethen realizar el lockelse 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 liberadosthen reanudar estas transacciones

Recordar que antes de write/read se realiza el “lock” correspondiente


Planificador. Política de liberaciones

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)

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)


Granularidad múltiple

El tamaño de la unidad de reserva (gránulo) afecta a:la concurrencia (inversamente)la eficiencia del mecanismo de concurrencia (inversamente)

¿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 accederduración de la transacción

La granularidad múltiple permite definir distintos niveles de granularidad: tabla, bloque, tupla


Granularidad múltiple. Niveles

Tabla

Bloq2 Bloq3Bloq1

tupla1 tupla2 tupla3

propagacióndel

bloqueo(implícito)

Cuando una transacción bloquea un nodo, también bloquea todos los descendientes de ese nodo con el mismo modo de bloqueo.


Granularidad múltiple. EjemploT1: (nivel tabla){...... % casi todos los alumnos > 10UPDATE AlumnoSET nota = nota +1WHERE edad > 10 .........}

T2: (nivel tupla){.......% pocos alumnos son de BerrobiSELECT *FROM AlumnoWHERE ciudad=“Berrobi”....}

Alumno

juan ana edurnelorena

T1:XT2:IS

T2:S



Supongamos que: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)



¿Qué ocurre si T2 solicita antes que T1?Se concede la reserva a T2Después al considerar la solicitud de T1, el SGBD debe verificar todas las tuplas para ver si hay conflicto de reservas. Poco eficiente.



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 intencionalIdea: Una transacción indique, a lo largo del camino desde la raiz hasta el nodo deseado, que tipo de bloqueo requerirá de uno de los descendientes del nodo.


Bloqueos de intención

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á).

solicitudIS

solicitudIX

solicitudS

solicitudX

estado IS si si si noestado IX si si no noestado S si no si noestado X no no no no


AlgoritmopeticionReserva(G:gránulo,R:tipoReserva,T: transacción)if G no es gránuloRaizthen case R do

S, IS: peticiónReserva(G.padre,IS,T)X,IX: peticiónReserva(G.padre,IX,T)

reservar(G,R,T) % comprobar matriz de compatibilidad y actualizar tabla de reserva

peticiónLiberación (G:gránulo,T: transacción)liberar(G,T)if G no es gránuloRaizthen liberar(G.padre,T) % actualizar tabla de reserva


Modo SIX

{....select numCue into :top from CuentaCorrientewhere saldo = (select MAX(saldo) from CuentaCorriente)

update CuentaCorriente set saldo = saldo + 10000where numCue = :top....}

Id. Gránulo Group mode Waiting? ListcuentaCorriente SIX no List1

tupla Top X no List2

T - S - no T - IX - no

T - X - no


Bloqueos de intención

SIX (S+IX): es el “group mode” correspondiente a un S e IX hechos por la misma transacción

El modo SIX no se solicita. Es un agregado de S+IX para comodidad del planificador

solicitudIS

solicitudIX

solicitudS

solicitudX

estado IS si si si noestado IX si si no noestado S si no si no

estado SIX si no no noestado X no no no no


Granularidad múltiple. Ventajas

Intensifica la concurrenciala transacción NO se ve obligada a reservar más datos de los necesarios por trabajar con un gránulo grande

Mejora la eficiencia del mecanismo de reservael número de reservas/liberaciones es menor ya que el gránulo se ajusta al volumen de datos manejados por la transacción


Granularidad múltiple. Ventajas

Esta técnica resulta adecuada a la hora de procesar una combinación de transacciones que incluyen:

1) transacciones cortas que acceden sólo a unos pocos elementos2)transacciones largas que acceden a ficheros completos


Control de Concurrencia basado en lamarca de tiempo

Técnica optimistaarregla 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 T1 llega al sistema después de T2, mt(T1) < mt(T2). Las mt se asignan en orden ascendente.


Diferencia respecto a las Técnicas de Locking

T. Marca de tiempo:cuando algo va mal aborta la transacciónOrdenan 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


Implementación

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)

OperacionesLas mt. son gestionadas internamente por el sistema

ProcesoAl 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 violadaSi este orden es violado, se hace rollback de TT nunca espera, por tanto T nunca se queda bloqueadoSi T aborta, también deberá abortarse cualquier transacción que pueda haber usado un valor escrito por T (y así en cascada)


Implementación

Granulo A•READ_MT:•WRITE_MT

1ª transacción T1

2ª transacción T2

3ª transacción T3

4ª transacción T4

planif. en serieT1,T2,T3,T4

planificador


Planificación en serie equivalente

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,

Proceso:cuando Tquiere ...

si antes otra transaccióncon m.t. mayor ha ...

entoncespasa ...

¿cómo se detecta?

READ(G) READ(G) continuarWRITE(G) READ(G) abortar READ_MT(G) > MT(T)

READ(G) WRITE(G) abortar WRITE_MT(G) > MT(T)WRITE(G) * WRITE(G) ignorar la escritura

y continuarWRITE_MT(G) > MT(T)

* the Thomas write rule


Ejemplo

T1 T2READ(A,t)


READ(B,u)

READ(B,u)

display(t + u)

u := u + 50WRITE(B,u)

esta planificación es serializable

es detectada por el protocolo de marca de tiempo

NO es detectada por el protocolo de reserva


¿Qué ocurre al abortar una trans.?

1ª planif. en serieT1,T2,T3,T4

Abortar T2. La antigua T2 se vuelve a enviar,

y al entrar en el sistema se la bautiza como T62.

2ª planif. en serieT1,--,T3,T4, T62

T2 T62


Control de Concurrenciabasado en la marca de tiempo

No permite todos los posibles planes serializablesNo tiene lugar el abrazo mortalPuede producirse la espera indefinida (una transacción se aborta y reinicia continuamente)


cuando Tquiere ...

si antes otra transaccióncon m.t. mayor ha ...

entoncespasa ...

¿cómo se detecta?

READ(G) READ(G) continuarWRITE(G) READ(G) abortar READ_MT(G) > MT(T)

READ(G) WRITE(G) abortar WRITE_MT(G) > MT(T)WRITE(G) WRITE(G) ignorar WRITE_MT(G) > MT(T)

Marca de tiempo multiversión (variante)

Idea: mantener versiones antiguas de los gránulosCada operación escribir crea una nueva versiónObjetivo: evitar la siguiente situación:

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


Marca de tiempo multiversiónMT(T1)=150

MT(T2)=200

MT(T3)=175

MT(T4)=225

A. versión O A.versión 150 A.versión 200

READ(A)WRITE(A)

read.MT = 150 read.MT = 200write.MT = 150

READ(A)WRITE(A)

read.MT = 225write.MT = 200

READ(A)

READ(A)


Marca de tiempo multiversión

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: rollbackse crea una nueva versión de G con WRITE_MT(G) y READ_MT(G) la marca detiempo 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 menorque el WRITE_MT(G)


Diferencia respecto a la técnica de marca de tiempo clásica

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.

T. Marca de tiempo clásica: mantiene por cada gránulo las marcas de tiempo de los READ y WRITE


Control de Concurrencia basado en la técnica de

validaciónOtro tipo de técnica de control de concurrencia optimistaNo se efectua verificación alguna durante la ejecución de las transaccionesLa transacción se ejecuta en tres fases:

de lectura: sólo se lee (escritura en variables locales)de validación, cuando se comprueba la seriabilidadde escritura, cuando se escriben los datos en el buffer global, supuesto T ha pasado la validación (en caso contrario la transacción se reinicia)

buffer global

lectura escrituravalidación


Control de Concurrencia basado en la técnica de

validaciónTécnica adecuada si:

Hay poca interferencia entre las transacciones, casi todas se validaran sin dificultadSin 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.


Implementación

Elementos: No están asociados a los gránulos sino a las T:READ_SET(T), cjto. de gránulos leídos por TWRITE_SET(T), cjto. de gránulos escritos por TSTART(T), momento comienzo fase de lecturaVAL(T), momento comienzo fase de validaciónEND(T), momento finaliza la fase de escritura

START, transacciones que han comenzado pero no completado la validación.VAL, transacciones validadas en fase de escrituraEND, transac. que ya han concluido la fase de escritura


Implementación. Proceso de validación

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

Suponemos que la fase de escritura es instantánea


Implementación. Proceso de validación

caso 1:U ∈ END end(U) < start(T) cond: true

caso 2:U ∈ VALstart(T) < end(U) < val(T)cond: RS(T) ∩ WS(U) = φ

caso 3:U ∈ STARval(U) < val(T)cond: (RS(T) ∪ WS(T)) ∩ WS(U) = φ

Una trans. T pasa con éxito la fase de validación, si para cualquier otra trans. U anterior a la planificación en serie:

T

T

TSe verifica, caso 1, caso 2, caso 3


Comparación

AlmacenamientoReserva:

se guarda el “estado” para cada gránulo

Marca de tiempoMT por cada gránulo MT por cada transacción

ValidaciónMT por cada transacciónRS, WS por cada trans.

EficienciaReserva

evita rollbacks” incluso con un alto solapamiento entre transacciones

Marca de tiempo, Validacióneficientes si trans de sólo lectura o con poco solapamiento

Validacióndetecta la no-seriabilidad más tarde que las otras técnicas


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.

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)



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 nivel de aislamiento.

Modo de acceso: puede especificarse como READ ONLY (solo lectura), o READ WRITE (leer y escribir). Valor por defecto READ WRITE.


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



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 COMMITEDREPETEABLE READSERIALIZABLE

(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)


Lectura Sucia

Un dato se dice “sucio” si ha sido escrito por una transacción que todavía no ha sido confirmada.

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.

T1 T2LOCK_X(A)READ(A,t)t := t - 50WRITE(A,t)

LOCK_S(B)UNLOCK(A)

LOCK_X(A)READ(A,t)aux := t * 0,1t := t - auxWRITE(A,t)UNLOCK(A)

READ(B,t)ABORT


El problema de los “dirty reads(lecturas sucias)”

“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

error

commit

commit

start_T1

start_T2

start_T3

write(A)

write(B)

read(B)

read(A)


Lecturas no repetibles

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.


Fantasmas

“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”


Niveles de aislamiento en SQL2

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

“read uncommitted” (lectura no confirmada. Se pueden leer datos no confirmados.

-ai

slam

ient

o +

+

conc

urre

ncia

-


Niveles de aislamiento en SQL

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 problemaNO: significa que el nivel de aislamiento previene el problema


Definición de transaccionesInicio: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:COMMITROLLBACK


Transacciones y restricciones

Transacción como unidad de consistencia

Durante la transacción se permiten estados inconsistente

Al definir una restricción se indica cuándo ésta debe ser verificada

inmediatamente, como parte de la misma transaccióndiferida, al final de la transacción


create table pieza(codigo….su_proveedor ….------create constraint restriccion1 foreing key (su-proveedor)

references proveedoron update cascade{ deferrable initially {immediate | deferred} |

initially immediate }

set constraints{all | <identificador restricción>}{deferred | immediate}

• Definición de restricciones

• Cambio de modo de las restricciones diferidas durante la transacción

Transacciones y restricciones

Concurrencia - adimen.si.ehu.es

Documents

Transcript of Concurrencia - adimen.si.ehu.es