Procesamiento de Transacciones

101  Download (0)

Full text

(1)

Procesamiento de Transacciones

Material basado en los capítulos 12 y 13 del libro: Sistemas Distribuidos. CyD. G.

Coulouris, J. Dollimore and T. Kindberg.

(2)

Transacciones Planas

Concurrencia

Bloqueos

Durabilidad

Consistencia

Transacciones Distribuidas

Two phase commit

Gestor de Transacciones

Roll Back

Aislamiento Commit

Atomicidad

(3)

Contenido

Definiciones Básicas

Transacciones

Problemas del Control de Concurrencia

Equivalencia Secuencial

Operaciones Conflictivas

Problemas causados por el aborto de las transacciones

(4)

Contenido

Mecanismos de Control de Concurrencia

Control de Concurrencia a través de bloqueos

Control Optimista de la Concurrencia

Ordenación por marcas de tiempo

(5)

Contenido

Transacciones Distribuidas

Sistema Manejador de Transacciones

Transacciones Planas y Anidadas

Commit y Abort en un Sistema Distribuido

Control de Concurrencia

Por Bloqueo

Optimista

Marcas Temporales

(6)

Contenido

Recuperación de Transacciones

(7)
(8)

Exclusión mutua

Comunicación entre hilos

Java

Wait: Un hilo llama a wait en un objeto para suspenderse él mismo y permitir a otro hilo ejecutar un método en ese objeto.

Notify: Un hilo llama a notify en un objeto para informar a cualquier hilo que esta esperando en el objeto que ha cambiado alguno de sus datos.

- Uso eficiente de los recursos (CPU) - Polítcasjustas que eviten starvation

(9)

Transacciones

Una transacción es una colección de acciones que hacen transformaciones de los estados de un sistema preservando la consistencia del

sistema

Una transacción indica una operación atómica exitosa, tal como por ejemplo la transferencia de dinero de una cuenta a otra.

Trasferencia:

1) Débito, 2) Crédito

Ya sea una operación compuesta o no.

(10)

Definiciones

Consiste en una secuencia de operaciones que se ejecuta en forma atómica (indivisible)

Todo o Nada

Aislamiento

(11)

Transacciones

Solicitudes atómicas:

Aislamiento

Efectos intermedios no visibles

Todo o Nada

Todas las operaciones o ninguna  Atomicidad de fallo, durabilidad. Objetos Recuperables

(12)

Propiedades ACID de las Transacciones

Atomicidad (Atomicity): todo o nada.

Consistencia (Consistency): una transacción

hace pasar el sistema de un estado consistente a otro. Es generalmente responsabilidad de los programadores de servidores y clientes el

asegurar que los datos queden en un estado consistente.

Aislamiento (Isolation) efecto equivalente a una ejecución secuencial.

Durabilidad (Durability) los efectos de una transacción consumada no se pierden, perduran.

(13)

Implementación de las Transacciones

El aislamiento se garantiza por protocolos de control de concurrencia

La atomicidad y durabilidad se garantizan

mediante protocolos de recuperación.

(14)

Modelo de fallo para Transacciones

Lampson propuso un modelo de fallos para

transacciones distribuidas que considera los fallos en: Discos, Servidores y Comunicación. En el

modelo se intenta que los algoritmos trabajen

correctamente en presencia de fallos predecibles, pero no se hacen consideraciones cuando ocurre un desastre. El modelo establece lo siguiente:

Las escrituras pueden fallar (no se escribe nada, o se escribe un valor incorrecto). En este caso las lecturas al disco pueden detectar (mediante una suma de

comprobación) cuando un bloque de datos es incorrecto.

(15)

Modelo de fallo para Transacciones

Los servidores pueden fallar ocasionalmente. Cuando el servidor se reemplaza por otro, el nuevo proceso debe realizar un proceso de recuperación utilizando la memoria permanente y la información que le

puedan suministrar otros procesos. Las fallas pueden ocurrir en cualquier instante de tiempo, incluso durante un proceso de recuperación.

Puede existir un retardo arbitrario antes de que llegue un mensaje. Un mensaje se puede perder, duplicar o modificar. Se pueden detectar mensajes modificados.

Los mensajes falsificados y corruptos que no se puedan detectar se les considera como desastres.

(16)

C C C

Transaction Manager scheduler

TPS

Recovery Manager

Cache Manager

Data Manager

Estructura de un Sistema de Manejo de Transacciones

En los servidores se puede añadir manejo transaccional, mediante un SMT. Este

Coordinador o manejador , provee operaciones para el manejo de las transacciones.

(17)

Estructura de un Sistema de Manejo de Transacciones

El manejador de transacciones

(Coordinador) dá a cada transacción un identificador TID

Operaciones disponibles al Cliente:

tid BeginTransaction() para el comienzo de una transacción, devuelve el TID

EndTransaction(tid), devuelve abort o commit dependiendo si la transacción

se ha podido o no realizar

Abort(tid): El cliente puede abortar la transacción y todas las actualizaciones deben eliminarse.

(18)

Historia de vida de una Transacción

Con éxito Abortado por el cliente Abortado por el servidor

AbreTransacción AbreTransacción AbreTransacción

Operación Operación Operación

Operación Operación Operación

El servidor aborta la transacción

Operación Operación ERROR en la operación

informado al cliente CierraTransacción AbortaTransacción

(19)

Condiciones de Terminación

Una transacción siempre termina, aun en la

presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un commit (consumación)

Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta.

Cuando la transacción es abortada, su

ejecución se detiene y todas las acciones ejecutadas hasta el momento se deshacen (undone) regresando a la base de datos al

estado antes de su ejecución. A esta operación también se le conoce como rollback.

(20)

Condiciones de Terminación

Las versiones provisionales se transfieren a los objetos sólo cuando una transacción hace commit; en este caso se transfieren también a memoria permanente.

Cuando una transacción aborta, sus

versiones provisionales se borran.

(21)

Historia de vida de una Transacción

Ruptura de un proceso:

Acciones en el servidor: (Falla en un

Servidor) se reemplaza, se abortan todas las transacciones que no han finalizado, usa un procedimiento de recuperación para obtener los valores de transacciones consumadas.

(Falla en un Cliente): los servidores dan un tiempo de expiración y abortan las

transacciones que no hayan finalizado en ese tiempo.

(22)

Historia de vida de una Transacción

Ruptura del proceso:

Acciones en el cliente: Si falla el servidor, al cliente, después de un tiempo se le devolverá un código de error. El cliente debe tener un plan para reintentar la operación o abandonar la tarea que estaba realizando.

(23)

Estructura de las Transacciones

Planas: consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave Begin Transaction y End Transaction. Por ejemplo,

Begin_transaction Reservación . . .

End transaction

(24)

Estructura de las Transacciones

Anidadas: las operaciones de una

transacción pueden ser transacciones

. Por ejemplo,

Begin_transaction Reservación . . .

Begin_transaction Vuelo . . .

end. {Vuelo}

. . .

Begin_transaction Hotel

end {Hotel}

End_transaction Reservación

(25)

T: Transacción de Nivel Superior

T2:

T1:

T11 T12 T21

T211 Commit provisional

Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit subtransacción

(26)

Transacciones anidadas

Subtransacción  Atómica

Subtransacciones del mismo nivel 

concurrentes pero sus accesos a objetos comunes son secuencializados.

Pueden consumar o abortar independientemente

http://sistemas-distribuidos.wikispaces.com/3.8.+Transacciones+distribuidas.

(27)

Transacciones Anidadas

Una transacción anidada dentro de otra

transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella.

Existen restricciones obvias para una transacción anidada:

Debe empezar después que su padre y debe terminar antes que él.

El commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las

subtransacciones hijas también serán abortadas.

(28)

Transacciones Anidadas

Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre

transacciones. Las transacciones de un mismo nivel se pueden ejecutar en forma concurrente pero sus accesos se deben secuencializar.

(29)

Transacciones Anidadas

Las transacciones pueden hacer commit o abort de forma independiente. Cuando

una subtransacción aborta, la transacción

padre puede elegir una sub-transacción

alternativa para completar su tarea.

(30)

Transacciones Anidadas

Reglas para el commit de transacciones anidadas:

Una transacción puede hacer commit o abort sólo después que han terminado las

transacciones hijas.

Cuando una subtransacción finaliza, decide de forma independiente si hace un commit provisional o aborta. Una decisión de abortar es definitiva.

(31)

Transacciones Anidadas

Reglas para el commit de transacciones anidadas (cont):

Cuando un padre aborta, todas las subtransacciones abortan (aún cuando éstas hayan realizado un

commit provisional)

Cuando una subtransacción aborta, el padre puede decidir abortar o no.

Si las transacciones de alto nivel hacen COMMIT, se pueden consumar también todas las

subtransacciones que hayan realizado un COMMIT provisional. Los efectos de una subtransacción no son permanentes hasta que no se consuma la

transacción de nivel superior

(32)

T: Transacción de Niver Superior

T2:

T1:

T11 T12 T21

T211 Commit provisional

Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

(33)

Problemas de la Concurrencia

Las aplicaciones de BD manejan una gran cantidad de datos “persistentes”, es decir datos almacenados en dispositivos de

memoria secundaria.

Un usuario típico de una BD, realiza

“queries” sobre los datos, como por

ejemplo: cuál es el saldo actual de mi

cuenta bancaria??

(34)

Necesidad de Concurrencia

En algunos sistemas no es crítico que los datos estén actualizados al instante; dichas

actualizaciones pueden diferirse y hacerse en batch. Este enfoque simplifica enormemente el manejo de los datos.

Por ejemplo algunos Bancos a finales de los noventa, hacían las actualizaciones en las cuentas de los usuarios por la noche

La tendencia actual en los bancos es la de

mantener información actualizada al instante.

(35)

Necesidad de Concurrencia

En algunos sistemas las actualizaciones no pueden diferirse: por ejemplo un sistema de reserva de líneas aéreas o de compra de

entradas al teatro. Se necesita saber

inmediatamente si se ha podido reservar el asiento.

En este tipo de aplicaciones pueden llegar

requerimientos simultáneos de muchos clientes:

Necesidad de concurrencia y de los problemas que esto acarrea.

La concurrencia, permite también realizar procesos más eficientes.

(36)

Propiedades ACID

Un servidor que soporta transacciones debe sincronizar las operaciones para asegurar que se satisface el requisito de aislamiento. Una forma de hacerlo es serializando o

secuencializando las operaciones. Esto puede ser inaceptable desde el punto de vista del

desempeño.

La idea de los servidores es maximizar la concurrencia, se permitirá entonces que se entremezclen las transacciones (o sus

componentes), si el efecto es el mismo que si se ejecutarán secuencialmente. Es decir son

secuencialmente equivalentes.

(37)

Recuperaciones Inconsistentes Actualizaciones perdidas

Solución: equivalencia secuencial Problemas que trae la Concurrencia

Problemas que trae el aborto de las transacciones Lecturas sucias

Escrituras prematuras Abortos en Cascada

Los protocolos tratarán de evitar estos problemas

(38)

Actualizaciones Perdidas:

T:

balance = b.obtenBalance();

b.crédito(balance*1.1) a.debito(balance/10)

U:

balance = b.obtenBalance();

b.crédito(balance*1.1) c.debito(balance/10)

balance = b.obtenBalance(); 200$

b.crédito(balance*1.1) 220$

a.débito(balance/10) 80$

balance = b.obtenBalance(); 200$

b.crédito(balance*1.1) 220$

c.débito(balance/10) 280$

El valor final de B ha debido ser 242$, no 220$. U leyó un valor antes de que T lo actualizara.

Los balances iniciales de A, B y C son 100$, 200$ y 300$

(39)

El problema viene por paralelizar, o pretender que las 2 transacciones se

ejecuten concurrentemente cuando deben

ejecutarse en forma secuencial.

(40)

Recuperaciones Inconsistentes

V:

a.débito(100) b.crédito(100)

/* El valor inicial de ambas cuentas es 200 */

W:

Unasucursal.totalSucursal();

a.débito(100) $100

b.crédito(100) $300

Total = a.obtenbalance();

total = total + b.balance(); // total=300 total = total + c.balance():

W vé el valor nuevo de a y el valor viejo de b. No se está cumpliendo la propiedad de aislamiento.

Los balances iniciales de A, B son de 200$

(41)

Control de Concurrencia:

Solución al problema de actualizaciones perdidas.

balance = b.obtenBalance(); 200$

b.Crédito(balance*1.1) 220$

a.Débito(balance/10)

balance = b.obtenBalance(); 220$

b.Crédito(balance*1.1) 242$

c.Débito(balance/10)

-Se puede conseguir serialización o algo equivalente (equivalencia secuencial) secuenciando el acceso al objeto.

-La tabla es un ejemplo de secuenciación + cierto grado de concurrencia.

(42)

Serialización de Transacciones y Equivalencia Secuencial

Operaciones conflictivas: 2 operaciones son conflictivas

cuando sus efectos combinados dependen del orden en el cual fueron ejecutadas.

Se consideran conflictivas las siguientes operaciones:

read read no conflictivas read write conflictivas write write conflictivas

Cuando dos o más transacciones son conflictivas es necesario su serialización para asegurar la consistencia de los datos

después de su ejecución.

(43)

Operaciones Conflictivas (no conmutativas)

En el caso de un objeto bancario:

Crédito y débito a una cuenta son

conmutativas? (el valor final es el mismo)

crédito y crédito son conmutativas

débito y débito son conmutativas

read-balance y crédito no son conmutativas

read-balance y débito no son conmutativas.

(44)

Control de Concurrencia

Equivalencia secuencial:

Para cualquier par de transacciones es posible

determinar un orden de operaciones conflictivas sobre objetos accedidos por ambas. La

equivalencia secuencial se logra de la siguiente forma:

a. - Todos los accesos de una transacción a un objeto particular (operaciones conflictivas)

deben secuenciarse con respecto a su acceso

por otras transacciones.

(45)

Control de Concurrencia

Equivalencia secuencial:

b. Todos los pares de operaciones conflictivas de dos transacciones se deben ejecutar en el mismo orden sobre los objetos a los que ambas acceden. Si las transacciones T y U acceden a los objetos i y j en forma conflictiva, Se requiere:

T acceda i antes que U y T accede j antes que U

U acceda a i antes que T y U acceda a j antes que T

(46)

A B C T D

U

Todos los objetos sobre los cuales existan operaciones conflictivas tienen que ser accedidos por las transacciones en el mismo orden.

i: T luego U j: U luego T

(47)

Control de Concurrencia

Transacciones

Operaciones compuestas B

A C A B C

Serialización de operaciones conflictivas

Operaciones conflictivas Delay Ejecución

(48)

Control de Concurrencia

T: x=lee(i); escribe(i,10); escribe(j,20) U: y=lee(j); escribe(j,30); z=lee(i)

x = lee(i) escribe(i,10)

escribe(j,20)

y = lee(j) Escribe(j,30)

Z=lee(i)

No es secuencialmente equivalente porque los pares de operaciones conflictivas No se hacen en el mismo orden en todos los objetos. Aunque si se cumple la Primera condición.

T U

T lee i antes que U lo acceda, T no escribe j antes de que U la acceda i: T luego U

j: U luego T

(49)

Control de concurrencia

Ejercicio 12.9 del libro:

Un servidor gestiona los objetos a1, a2, … an. El servidor proporciona dos operaciones a sus clientes:

lee(i) devuelve el valor de ai

escribe (i, valor) asigna Valor a ai

Las transacciones T y U se definen de la siguiente forma:

T: x=lee(j), escribe(j,44);

U: x=escribe(i,55); escribe (j,66);

(50)

Control de concurrencia

Un servidor gestiona los objetos a1, a2, … an. El servidor proporciona dos operaciones a sus clientes:

lee(i) devuelve el valor de ai

escribe (i, valor) asigna Valor a ai

Las transacciones T y U se definen de la siguiente forma:

T: x=lee(j); y=lee(i); escribe(j,44); escribe (i,33);

U: x=lee(k); escribe(i,55); y=lee(j); escribe (k,66);

Proporcione tres solapamientos serialmente equivalentes de las transacciones T y U

(51)

Control de Concurrencia: Problemas que generan las operaciones conflictivas

Recuperaciones Inconsistentes

V:

a.Débito(100) b.Crédito(100)

/* El valor inicial de ambas cuentas es 200 */

W:

Unasucursal.totalSucursal();

a.Débito(100) $100

b.Crédito(100) $300

Total = a.obtenbalance();

total = total + b.balance;

total = total + c.balance():

V accede a «a» antes que W. V no accede a b antes de W.

a: V, W b: W, V

(52)

Solución al problema de

Recuperaciones Inconsistentes.

V:

a.extrae(100) $100 b.Deposita(100) $300

W:

Total = a.obtenbalance();

total = total + b.balance;

total = total + c.balance():

Solución: Ejecución Secuencial a: V,W

b: V, W

(53)

Recuperaciones Inconsistentes Actualizaciones perdidas

Problemas que trae la Concurrencia

Problemas que trae el aborto de las transacciones Lecturas sucias

Escrituras prematuras Abortos en Cascada

Los protocolos trataran de evitar estos problemas

(54)

Control de Concurrencia: Abortos, más sobre la propiedad de

aislamiento.

No obstante pueden aparecer problemas aún en presencia de ejecuciones secuencialmente

equivalentes. Esto es porque no hemos

considerado que una transacción puede abortar.

Se ha demostrado que la ejecución

secuencialmente equivalente es necesaria pero no suficiente para la ejecución concurrente de transacciones.

(55)

Control de Concurrencia

Las transacciones pueden abortar, ante esta situación

surgen otros problemas: lecturas sucias y escrituras prematuras

Lecturas Sucias

Transacción T Transacción U a.getBalance() (100$)

a.crédito(+10) (110$)

a.getBalance() (110$) a.crédito(+20) (130$) commit

aborta

Se restaura el valor de a a 100. U tomó el valor 110$ que ahora no es válido.

- La estrategia para la recuperación es retrasar la acción de commit de U hasta que T finalice

- Esto conlleva a la posibilidad de Abortos en Cascada (si T aborta, U debe abortar también)

Lectura Sucia

(56)

Control de Concurrencia

Una forma de evitar abortos en cascada es permitir a las transacciones únicamente leer objetos que fueron escritos por

transacciones consumadas. Es decir, implementar de forma estricta la

propiedad de aislamiento.

(57)

Control de Concurrencia

Escrituras Prematuras

T:

a.crédito(+5)

U:

b.crédito(+5)

a= 100$

a. Crédito(+5) 105$

a= 105$

a.Crédito(+5) 110$

Algunos sistemas de BD implementan la acción Abort restaurando las imágenes Anteriores.

Si U aborta y T se consuma el balance debe ser de 105$. Correcto.

U se consuma y T Aborta: El balance debería estar en 105$, pero se coloca la imagen anterior a T que es 100$. La escritura de U es prematura, antes de que T haga su commit.

(58)

Control de Concurrencia

Para garantizar resultados correctos en un esquema de recuperación que utiliza

imágenes anteriores, las operaciones de

escritura se deben atrasar hasta que las

transacciones anteriores que actualizaron

los mismos objetos hayan hecho commit o

abort (U no debería escribir)

(59)

Control de Concurrencia

La ejecución de las transacciones se

llama estricta si las lecturas o escrituras de los objetos se retrasa hasta que

todas las transacciones que

previamente escribieron el objeto hayan hecho commit o abort. La ejecución

estricta de las transacciones hace

cumplir la propiedad de aislamiento.

(60)

Control de Concurrencia

Para que un servidor está en capacidad de deshacer cambios si una transacción aborta, debe diseñarse de forma que las

actualizaciones puedan ser eliminadas.

Todas las operaciones de actualización se hacen sobre versiones provisionales de los objetos en memoria volátil.

A cada transacción se le proporciona su

conjunto privado de versiones provisionales de los objetos que ha alterado.

Cuando una transacción se consuma, las VP se llevan a almacenamiento permanente.

(61)

C C C

Transaction Manager scheduler

TPS

Recovery Manager

Cache Manager

Data Manager

Estructura de un Sistema de Manejo de Transacciones

El Manejador de Transacciones valida las peticiones de los

clientes y pasa la transacción al planificador.

El Planificador usa alguna estrategia para permitir una

ejecución concurrente que sea secuencialmente equivalente.

Manejador de Datos: transferir los datos a memoria principal, escribir actualizaciones,

recuperarse ante fallas.

(62)
(63)

Contenido

Mecanismos de Control de Concurrencia

Control de Concurrencia a través de bloqueos

Control Optimista de la Concurrencia

Ordenación por marcas de tiempo

Comparación de métodos.

(64)

Control de Concurrencia: Bloqueos

balance = b.obtenBalance(); 200$

b.ponBalance(balance*1.1) 220$

a.Extrae(balance/10)

balance = b.obtenBalance(); 220$

b.ponBalance(balance*1.1) 242$

c.Extrae(balance/10)

-Se puede conseguir equivalencia secuencial secuenciando el acceso al objeto.

-La tabla es un ejemplo de secuenciamiento + cierto grado de concurrencia.

-Una forma sencilla de serializar es a través del uso de bloqueos exclusivos.

- El acceso a un objeto puede ser restringido mediante un lock. Sólo la transacción que tenga el lock sobre el objeto podrá hacer operaciones sobre él.

(65)

Control de Concurrencia: Bloqueos Exclusivos

T:

balance = b.obtenBalance();

b.ponBalance(balance*1.1) a.Extrae(balance/10)

U:

balance = b.obtenBalance();

b.ponBalance(balance*1.1) c.Extrae(balance/10)

BeginTransaction

balance = b.obtenBalance(); Bloquea B b.crédito(balance*1.1)

a.débito(balance/10) Bloquea A End Transaction Desbloquea A,B

Begin Transaction

balance = b.obtenBalance(); Espera por B Concedido B b.obtenBalance();

b.crédito(balance*1.1)

c.débito(balance/10) Bloquea C End Transaction Desbloquea B,C

(66)

Control de Concurrencia:

Bloqueos

Cada vez que una transacción necesita leer o escribir en un objeto, solicita un “lock” sobre el mismo hasta que la transacción culmine exitosamente (commit). Cualquier otra

transacción que desee hacer alguna

operación sobre dicho objeto tendrá que esperar hasta que el mismo sea

desbloqueado.

(67)

Control de Concurrencia:Bloqueos

Para lograr la equivalencia secuencial, todos los pares de operaciones conflictivas se deben

hacer en el mismo orden.

Para asegurar esto, no está permitido a una

transacción adquirir un nuevo bloqueo después de que ha liberado alguno.

Existen dos fases:

Adquirir bloqueos (Fase de crecimiento)

Liberar bloqueos (Fase de Acortamiento)

(68)

Algoritmo de locking o bloqueo

Two Phase Locking: “obtención” y “liberación”

Durante la fase de “obtención”, la transacción trata de obtener todos los locks que necesite. Si no es posible obtener alguno, entonces espera.

La segunda fase comienza cuando la transacción libera alguno de los locks, a partir de ese momento no podrá solicitar ningún otro lock (si lo hace, será abortada).

Desventaja: si una transacción en la fase de liberación había desbloqueado algunos objetos y los mismos habían sido

accedidos por otras transacciones antes de que la primera hiciera commit, entonces las demás transacciones deberían abortar (esto es abortos en cascada). Pudiera ocurrir: lecturas sucias o escrituras prematuras.

(69)

Algoritmo de locking o bloqueo

Para evitar esto, se mantienen todos los

bloqueos aplicados a los objetos hasta que la

transacción que los posee se consuma (commit) o aborte. Esto se llama Bloqueo en dos fases

estricto.

La fase de “liberación” se realiza sólo cuando la transacción hace commit

Ventaja: evita los abortos en cascada Desventajas:

El nivel de paralelismo se degrada

En algunos casos es inadmisible.

(70)

Algoritmo de locking o bloqueo

Two Phase Locking Strict Two Phase Locking

number of locks

Time

Fase de crecimiento Fase de liberación

number of locks

Time

Fase de crecimiento Fase de liberación

Se liberan todos los locks

(71)

Control de Concurrencia: Bloqueos

Para mejorar la concurrencia:

la porción de objetos a la que se debe secuenciar el acceso debe ser tan pequeño como sea posible.

Problema de los lectores y

escritores: podemos tener muchos lectores accediendo

concurrentemente a los datos.

(72)

Control de Concurrencia: Bloqueos

Nivel de granularidad: tiene que ver con el tamaño del objeto o dato que se está bloqueando. A mayor

granularidad (mayor fineza del grano), más pequeño es el tamaño del objeto: ejm: tabla, registro, campo, etc.

Mientras mayor sea la fineza del grano, mejor será el grado de paralelismo/concurrencia, pero mayor será la complejidad del sistema.

El bloqueo puede ser a nivel de item, página, archivo, base de datos (donde item representa el grano más fino y base de datos corresponde al grano más grueso)

(73)

Algoritmo de locking o bloqueo

lock otorgado lock solicitado

Ninguno read -> OK - write -> OK read read -> OK - write -> Espera write read -> Espera - write -> Espera

Una mejora: utilizar locks de escritura y locks de lectura para ofrecer mayor paralelismo al permitir que se realicen

concurrentemente transacciones que realizan operaciones no conflictivas.

Los bloqueos de lectura se llaman también bloqueos compartidos.

(74)

Bloqueos

Reglas de conflicto

Si una transacción T ha realizado una operación de lectura en un objeto, entonces una transacción

concurrente U no debe escribir ese objeto hasta la consumación de T, o que aborte.

Si una transacción T ha realizado una operación de escritura en un objeto, entonces una transacción concurrente U no debe leer o escribir ese objeto hasta la consumación de T, o que aborte.

(75)

Bloqueos

Uso de bloqueos en un sistema de bloqueos de dos fases estricto.

1. Cuando una operación accede a un objeto en una transacción:

a) Si el objeto no estaba bloqueado, se bloquea y comienza la operación.

b) Si el objeto tiene activado un bloqueo conflictivo con otra transacción, la transacción debe esperar hasta que esté desbloqueado.

c) Si el objeto tiene activado un bloqueo no conflictivo de otra transacción, se comparte el bloqueo y comienza la operación.

d) Si el objeto ya ha sido bloqueado en la misma transacción, el bloqueo será promovido si es necesario y comienza la operación. (Donde la promoción está impedida por un bloqueo conflictivo, se utiliza la regla (b)).

2. Cuando una transacción se consuma o aborta, el servidor desbloquea todos los objetos

bloqueados por la transacción.

(76)

Algoritmo de locking o bloqueo

Para asegurar que se sigan las reglas

de solicitud de locks para los objetos , el cliente no tiene acceso a las

operaciones de bloqueo. Los locks son adquiridos y liberados por el

administrador de transacciones. Todo lo

concerniente al control de concurrencia

es transparente para el programador.

(77)

Implementación de Bloqueos

La concesión de bloqueos será implementado por un objeto separado del servidor que

llamaremos gestor de bloqueos.

El Gertor de Bloqueos mantiene en una estructura de datos los locks concedidos.

Cada bloqueo es una instancia de la clase

Bloqueo que mantiene la siguiente información:

El identificador del objeto bloqueado.

Los identificadores de las transacciones que mantienen actualmente el bloqueo

Un tipo de bloqueo.

(78)

Bloqueos

public class Bloqueo {

private Object objeto; // El objeto que es protegido por el bloqueo private Vector propietarios; // las TID de los propietarios

private TipoBloqueo tipoBloqueo; // el tipo actual

public synchronized void adquiere(IDTrans trans, TipoBloqueo unTipoBloqueo){

while(/* otra transacción posea el bloqueo en modo conflictivo */) { try {

wait( );

}catch (InterruptedException e) {/*...*/ } }

if (propietarios.estaVacio( )) { // ningún TID posee un bloqueo propietarios.agregaElemento(trans);

tipoBloqueo = unTipoBloqueo;

} else if (/*otra transacción posee el bloqueo, lo comparte*/ ) ) {

if (/*esta transacción no es un poseedor*/) propietarios.agregaElemento(trans);

} else if (/* esta transacción es un poseedor pero necesita más de un bloqueo exclusivo*/)

tipoBloqueo.promueve( );

} }

(79)

Bloqueos

public synchronized void libera (IDTrans trans ){

holders.removeElement(trans); // elimina este poseedor // establece el tipo de bloqueo a ninguno

notifyAll( );

} }

(80)

Bloqueos

public class GestorBloqueo { private Hashtable losBloqueos;

public void ponBloqueo(Object objeto, IDTrans trans, TipoBloqueo tipoBloqueo){

Bloqueo bloqueoEncontrado;

synchronized (this){

// busca el bloqueo asociado con el objeto

// si no hay ninguno, lo crea y lo agrega a la tabla de dispersión }

bloqueoEncontrado.agrega(trans, tipoBloqueo);

}

//sincroniza este dado que queremos eliminar todas las entradas public synchronized void desBloqueo(TransID trans) {

Enumeration e = losBloqueos.elements( );

while(e.hasMoreElements( )){

Bloqueo unBloqueo = (Bloqueo)(e.nextElement());

if(/* trans is a holder of this lock*/ ) unBloqueo.libera(trans);

} } }

(81)

Bloqueo para Transacciones Anidadas

El propósito de un esquema de bloqueo es

serializar el acceso a los objetos de modo que:

1. Cada conjunto de transacciones anidadas sea la única entidad a la que se debe impedir ver los efectos de otro conjunto de transacciones anidadas

2. Se debe impedir que cada transacción en un conjunto de transacciones anidadas observe los

efectos parciales de otras transacciones del conjunto.

(82)

Bloqueo para Transacciones Anidadas

La primera regla se logra disponiendo que cada bloqueo que adquiere una

subtransacción es heredado por su padre cuando esta finaliza (herencia del hijo al Padre). Esto garantiza que puedan

mantenerse los bloqueos hasta que se haya consumado o abortado la

transacción a nivel superior.

(83)

Bloqueo para Transacciones Anidadas

La segunda regla se hace cumplir así:

No se permite la ejecución concurrente de padre e hijos. Si una transacción padre tiene un bloqueo

sobre el objeto, retiene el bloqueo mientras el hijo se ejecuta. La transacción hijo adquiere temporalmente el bloqueo.

Se permite la ejecución concurrente de transacciones al mismo nivel, por lo que cuando éstas accedan a los mismos objetos el esquema de bloqueo debe secuenciar el acceso.

(84)

Bloqueos (transacciones anidadas)

Reglas que describen la adquisición y liberación del bloqueo:

Para que una subtransacción adquiera un bloqueo de lectura sobre un objeto, ninguna transacción activa puede tener un bloqueo de escritura sobre ese objeto, y los únicos que retienen un bloqueo de escritura son sus ascendientes.

(85)

Bloqueos (transacciones anidadas)

Para que una subtransacción adquiera un bloqueo de escritura sobre un objeto, ninguna otra transacción activa puede tener un bloqueo de lectura o escritura sobre ese objeto, y los únicos que retienen los

bloqueos de lectura y escritura en ese objeto son sus ascendientes.

Cuando se consuma una transacción, sus bloqueos son heredados por su padre, permitiendo al padre retener los bloqueos del mismo modo que el hijo.

Cuando una subtransacción aborta, sus bloqueos son eliminados. Si el padre todavía continúa manteniendo los bloqueos puede continuar haciéndolo.

Las transacciones al mismo nivel que acceden a los mismos objetos realizan turnos para adquirir los objetos retenidos por sus padres.

(86)

T: Transacción de Niver Superior

T2:

T1:

T11 T12 T21

T211 Commit provisional

Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

Desean bloqueo

(87)

T: Transacción de Niver Superior

T2:

T1:

T11 T12 T21

T211 Commit provisional

Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

Adquiere bloqueo que le pasa a T11 para su ejecución. T11

Lo devuelve cuando finaliza. Cuando T1 finaliza devuelve el bloqueo a T Y es en ese momento cuando T2 lo puede adquirir.

(88)

Algoritmo de locking o bloqueo

El problema del algoritmo de bloqueo es que puede ocasionar deadlocks o Interbloqueos.

T U

a.Crédito() bloqueo de escritura para A

b.Débito Espera por U Bloqueo en B

b.Crédito() bloqueo de escritura para B

a.Débito(200) Espera por T.

Bloquea en A

(89)

Interbloqueos

Condiciones para un bloqueo:

1.- Condición de exclusión mutua. Cada recurso está asignado a un único proceso o está disponible.

2.- Condición de posesión y espera (Hold and Wait).Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos.

3.- Condición de no apropiación. Un proceso no puede ser forzado a dejar los recursos otorgados con anterioridad. El

proceso que los posee debe liberarlos en forma explícita.

4.- Condición de espera circular.Debe existir una cadena circular de dos o más procesos , cada uno de los cuales espera un recurso poseído por el siguiente miembro de la cadena.

(90)

T T

R1

R2

Espera por

Espera por Poseído por

Poseído por

Grafo de Espera Circular: Si hay un ciclo en el grafo significa que hay interbloqueo (deadlock).

(91)

Tratamiento de Interbloqueos

Políticas frente a los bloqueos:

1.- Detectar: dejar que suceda y luego recuperarse.

3.- Evitar que estructuralmente sea posible el deadlock, es decir, asegurar que al menos una de las cuatro

condiciones no se cumpla. (EM, N Apropiación, H and W, Circular Wait)

4.- Predecir: Algoritmo del Banquero: Se necesita

conocer los requerimientos de recursos del proceso.

(No es aplicable en sistemas distribuidos por su complejidad de conocer los requerimientos de recursos de los procesos con anterioridad).

(92)

Tratamiento de Interbloqueos

Políticas frente a los bloqueos:

1.- Detectar:

Se pueden detectar a través de los grafos.

Una vez detectado el ciclo se debe escoger una

transacción y abortarla. La elección de la transacción a abortar no es sencilla. Un factor que puede ser

tomado en cuenta es su edad.

La presencia de ciclos en el grafo se puede detectar cada vez que se añade un arco o cada cierto tiempo para disminuir el overhead.

(93)

• Se basan en asignar a cada transacción un timeout:

A cada bloqueo se le proporciona un tiempo limitado en el que es invulnerable.

•Después de ese tiempo es vulnerable.

•Si ninguna transacción está compititnedo por el objeto, un objeto con bloqueo vulnerable continua bloqueado.

•Sin embargo, si cualquier otra transacción está

esperando por acceder a un objeto con un bloqueo vulnerable, se rompe el bloqueo y se reanuda la

transacción que esperaba. La transacción cuyo bloqueo se ha roto, normalmente aborta.

Algoritmos de Prevención

(94)

Serialización de Transacciones a través de locks.

El manejo de bloqueos (asignación, liberación) causan un overhead adicional, lo mismo que los algoritmos de prevención o detección

Disminuyen la concurrencia.

(95)

EJERCICIO

T U V W

a.deposita(100)

b.deposita(100) b.extrae(100)

c.extrae(100)

a.extrae(100)

c.deposita(100) d.deposita(100)

b.deposita(100) d.Deposita(100)

¿Bloqueo indefinido?

(96)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos de dos versiones

La activación de bloqueos exclusivos se retrasa hasta que una T se

consuma

Bloqueos jerárquicos

Bloqueos de granularidad mixta

(97)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos de dos versiones

Esquema optimista que permite que una transacción escriba versiones tentativas.

Las operaciones de lectura sólo esperan si otra

transacción se está consumando actualmente sobre el mismo objeto.

Tres tipos de bloqueo:

Bloqueo de lectura

Bloqueo de escritura

Bloqueo de consumación

(98)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos de dos versiones

Para un objeto Bloqueo que se establece

Lectura Escritura Consumación

Bloqueo ya establecido Ninguno Bien Bien Bien

Lectura Bien Bien Espera

Escritura Bien Espera

Consumación Espera Espera

(99)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos Jerárquicos

En algunas aplicaciones la granularidad adecuada para una operación no es apropiada para otra.

Para reducir la sobrecarga, se permiten que

coexistan bloqueos de granularidad mezclados.

Propuesta de Gray: La activación de un bloqueo padre tiene el mismo efecto que la activación de todos los bloqueos hijo equivalentes. Intención de bloqueo

(100)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos Jerárquicos

Sucursal

Cuenta

A B C

Semana

Lunes Martes Miércoles Jueves Viernes

9:00–10:00

Intervalos de tiempo 10:00–11:00 11:00–12:00 12:00–13:00 13:00–14:00 14:00–15:00 15:00–16:00

(101)

Incrementando la concurrencia en esquemas de bloqueo

Bloqueos Jerárquicos

Tabla de compatibilidad para bloqueos jerárquicos.

Para un objeto Bloqueo que se va a activar

Lectura Escritura I-Lectura I-Escritura Bloqueo ya activado Ninguno Bien Bien Bien Bien

Lectura Bien Espera Bien Espera

Escritura Espera Espera Espera Espera

I-Lectura Bien Espera Bien Bien

I- Escritura Espera Espera Bien Bien

Figure

Updating...

References

Related subjects :