Control de concurrencia

Transacciones• Ejecución simultánea de programas de usuario es

esencial para el buen desempeño de DBMS.– Debido a que los accesos a disco son frecuentes, y

relativamente lentos, es importante mantener el CPU trabajando en varios programas de usuario al mismo tiempo.

• Un programa de usuario puede llevar a cabo varias operaciones en los datos recuperados de la base de datos, pero el DBMS sólo está preocupado por los datos que se leen / escriben desde / hacia la base de datos.

• Una transacción es una vista abstracta del DBMS de un programa de usuario: una secuencia de lecturas y escrituras.

Concurrencia en un DBMS• Los usuarios envían las transacciones, y se

puede pensar de cada transacción , que se ejecuta por sí mismo.– Se logra concurrencia por el DBMS, que entrelaza las

acciones (lee / escribe de objetos BD) de las diversas transacciones.

– Cada transacción debe dejar la base de datos en un estado consistente si la BD es consistente cuando comienza la transacción.

• El DBMS no entiende la semántica de los datos. (por ejemplo, no entiende cómo se calcula el interés en una cuenta bancaria).

Atomicidad de las transacciones• Una transacción puede hacer commit después

de completar todas sus acciones, o puede abortar(o ser abortado por el DBMS) después de ejecutar algunas acciones.

• Una propiedad muy importante garantizada por el DBMS para todas las transacciones es que son atómicas. – DBMS registra en logs todas las acciones para que

se pueda deshacer las acciones de las operaciones abortadas.

ACID• Atómico• Consistencia

– debe dejar la base de datos en un estado consistente

• Aislamiento (Isolation)– "Protegido" de los efectos de programar

concurrentemente otras transacciones• durabilidad

– Los efectos deben persistir incluso si el sistema falla antes de que todos los cambios se reflejen en disco.

Ejemplo

• Considere dos transacciones :

T1: BEGIN A=A+100, B=B-100 ENDT2: BEGIN A=1.06*A, B=1.06*B END

Intuitivamente, la primera transacción transfiere $100 de la cuenta B a la cuenta A. La segunda es la acreditación de las dos cuentas con un pago de interés del 6%.

No hay garantía de que T1 se ejecutará antes de T2 o viceversa, si ambos se envían juntos. Sin embargo, el efecto neto debe ser equivalente a las dos transacciones ejecutándose en serie en algún orden.

Ejemplo(Cont.)

• Considere un posible entrelazado (horario):

T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B

Esto está bien. Pero qué ocurre si:T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B

La vista del DBMS del segunda horario:

T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)

Programando Transacciones• Horario serial: Programa no entralaza las acciones

de las diferentes transacciones.• Horario equivalentes: Para cualquier estado de

base de datos, el efecto (en el conjunto de objetos en la base de datos) de la ejecución del primera horario es idéntica a los efectos de la ejecución del segundo horario.

• Horario Serializable : Un programa que es equivalente a alguna ejecución en serie de las transacciones.(Nota: Si cada transacción mantiene consistencia, todos los horarios serializables preservan la consistencia.)

Anomalías con ejecuciones entrelazadas

• Lectura de datos sin confirmar (conflictos WR, "lecturas sucias"):

• Lecturas Irrepetibles (conflictos RW):

T1: R(A), W(A), R(B), W(B), AbortT2: R(A), W(A), C

T1: R(A), R(A), W(A), CT2: R(A), W(A), C

Anomalía (Cont.)

• Sobrescribir datos no confirmados (conflictos WW):

T1: W(A), W(B), CT2: W(A), W(B), C

Bloqueo basado en Control de concurrencia• Protocolo Estricto bloqueo de dos fases (2PL estricto):

– Cada transacción debe obtener un bloqueo S (compartido) en el objeto antes de leer, y un bloqueo X (exclusivo) en el objeto antes de escribir.

– Todos los bloqueos efectuados por una transacción se liberan cuando se complete la transacción

• (No estricto) 2PL Variante: libera los bloqueos en cualquier momento, pero no pueden adquirir bloqueos después de la liberación de cualquier bloqueo.

– Si una transacción mantiene un bloqueo X en un objeto, ninguna otra transacción puede obtener un bloqueo (S o X) en ese objeto.

• 2PL estricto sólo permite horarios serializables.– Además, simplifica la anulación de transacciones– (No estricto) 2PL también permite sólo horarios

serializables, pero implica procesos más complejos de abortar

Cancelación de una transacción• Si una transacción Ti se aborta, todas sus

acciones tienen que ser deshechas. No sólo eso, si Tj lee un objeto escrito últimamente por Ti, Tj debe ser abortado también!

• La mayoría de los sistemas evitan estos abortos en cascada liberando un bloqueo de una transacción sólo durante el commit.– Si Ti escribe un objeto, Tj puede leer esto sólo

después que Ti hace commit.• Con el fin de deshacer las acciones de una

transacción anulada, el DBMS mantiene un registro en el que se registra cada escritura. Este mecanismo se utiliza también para recuperarse de los fallos del sistema: todas las transacciones activas en el momento del accidente se anulan cuando el sistema vuelve a funcionar.

El Log• Las siguientes acciones se registran en el log:

– Ti escribe un objeto: el valor antiguo y el nuevo valor.• El log debe ir a la disco antes de la página que ha cambiado!

– Ti commits/aborta: un log que indique esta acción.• Las entradas de registro se encadenan por id de

transacción, así que es fácil deshacer una transacción específica.

• El log es a menudo duplicado y archivado en un almacenamiento estable.

• Todas las actividades relacionadas al log (y de hecho, todas las actividades relacionadas con el bloqueo / desbloqueo, tratar con bloqueos, etc) se manejan de forma transparente por el DBMS.

Recuperarse de un fallo• Hay tres fases en el algoritmo de recuperación Aries:

– Análisis: Analizar el log hacia adelante(desde el punto de comprobación más reciente) para identificar todos las transacciones que estaban activas, y todas las páginas sucias en el grupo de búferes en el momento del accidente.

– Rehacer: Rehace todas las actualizaciones de las páginas sucias en el búfer pool, según sea necesario, para asegurar que todas las actualizaciones que se registran de hecho se lleven a cabo y sean escritas en el disco.

– Deshacer: Las escrituras de todas las transacciones que estaban activas en el fallo se deshacen (restaurando el valor antes de la actualización, que está en el expediente de registro para la actualización), yendo hacia atrás en el log. (Se debe tener cuidado al manejar el caso de un fallo que ocurra durante el proceso de recuperación!)

Resumen• El control de concurrencia y la recuperación se encuentran

entre las más importantes funciones proporcionadas por un DBMS.

• Los usuarios no necesitan preocuparse acerca de la concurrencia.– El sistema inserta automáticamente peticiones de

bloquear/desbloquear y programa acciones de diferentes transacciones, de tal forma que se garantice que la ejecución resultante es equivalente a ejecutarlas una después de la otra en algún orden.

• Registro de escritura anticipada (WAL) se utiliza para deshacer las acciones de las operaciones abortadas y para restaurar el sistema a un estado consistente después de un fallo.– Estado consistente: sólo los efectos de transacciones con commit se

pueden ver.

Revisión

• DBMSs soportan concurrencia, recuperación de fallos con:– Las transacciones ACID (atómicas,

Consistencia, Aislamiento, Durabilidad)– Registro de las operaciones

• Una ejecución en serie de transacciones es seguro pero lenta– Tratar de encontrar los horarios equivalentes a

la ejecución en serie• Una solución para el horario serializable es

2PL

Conflicto de Horarios serializables

• Dos horarios son equivalentes en conflicto si:– Involucra a las mismas acciones de las

mismas transacciones– Cada par de acciones en conflicto se ordena

de la misma manera• Horario S es serializable en conflicto si S

es equivalente a un conflicto de horario serial

Ejemplo

• Un horario que no tiene conflicto serializable:

• El ciclo en el gráfico revela el problema. La salida de T1 depende de T2 , y viceversa.

T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)

T1 T2A

B

Gráfico de dependencia

Gráfico de dependencia

• Gráfico de dependencia: un nodo por transacción; flecha de Ti a Tj si una operación de Ti tiene conflicto con una operación de Tj y Ti aparece en el calendario antes de la operación en conflicto de Tj.

• Teorema: El horario es conflicto serializable si y sólo si su grafo de dependencias es acíclico

Vista Serializable• Horarios S1 y S2 son equivalentes en vista si:

– Si Ti lee el valor inicial de A en S1, entonces Ti también lee el valor inicial de A en S2

– Si Ti lee el valor de A escrito por Tj en S1, entonces Ti también lee el valor de A escrito por Tj en S2

– Si Ti escribe el valor final de A en S1, entonces Ti también escribe el valor final de A en S2

• Serialización de vista es "más débil" que la serialización conflicto!– Cada horario de conflicto serializable es vista serializable,

pero no al revés! Es decir admite más horarios legales

T1: R(A) W(A)T2: W(A)T3: W(A)

T1: R(A),W(A)T2: W(A)T3: W(A)

Deadlocks

• Deadlock: Ciclo de transacciones esperando por bloqueos que se liberarán por cada uno.

• Dos formas de tratar con deadlocks :– prevención de Deadlock– detección de Deadlock

Prevención de Deadlock• Asignar prioridades en base a

timestamps. Supongamos que Ti quiere un lock que tiene Tj. Dos políticas son posibles:– Wait-Die: Si Ti tiene mayor prioridad, Ti

espera por Tj, de lo contrario se anula Ti– Wound-wait: Si Ti tiene mayor prioridad, se

aborta Tj, de lo contrario Ti espera

Detección de Deadlock

• Crear un gráfico de espera :– Los nodos son las transacciones– Hay una ventaja de Ti a Tj si Ti está

esperando a Tj para liberar un bloqueo

• Revise periódicamente los ciclos en el gráfico de espera

Detección de Deadlock(Cont.)

Ejemplo:

T1: S(A), S(D), S(B)T2: X(B) X(C)T3: S(D), S(C), X(A)T4: X(B)

T1 T2

T4 T3

T1 T2

T4 T3

Detección de Deadlock (cont.)

• En la práctica, la mayoría de los sistemas practican detección – Los experimentos muestran que la mayoría de

espera para los ciclos son de longitud 2 o 3– Por lo tanto, pocas transacciones deben

anularse– Las implementaciones pueden variar

• Puede construir el gráfico y periódicamente buscar ciclos

• Puede hacer un esquema "tiempo fuera" : si usted ha estado esperando un bloqueo desde hace mucho tiempo, se asume que es un deadlock y aborta