Procesamiento de Transacciones

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

Contenido

„

Definiciones Básicas

…Transacciones

„

Control de Concurrencia:Problemas

…Equivalencia Secuencial …Operaciones Conflictivas

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

(2)

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

Contenido

„

Recuperación de Transacciones

Definiciones

„

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??

(3)

Definiciones

„

Llamaremos transacción a un requerimiento de un usuario a un manejador de Base de Datos (DBMS).

„

Sistemas que usan BD: Bancos, líneas aéreas y otros sistemas de reservación, bases de datos estadísticas que contienen datos de la población, del tiempo, etc.

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 El Banco Santander a finales de los noventa. Se hacían las actualizaciones de noche

„ La tendencia actual en los bancos es la de mantener información actualizada al instante.

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.

(4)

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.

Operaciones Atómicas

„ Cuando la operación termina exitosamente todos sus efectos visibles se hacen permanentes (Propiedad de Durabilidad). Si falla o es abortada deliberadamente, no tiene ningún efecto (Todo_o_Nada)

„ Aislamiento: cada transacción debe ser ejecutada sin interferencias de otras transacciones, es decir, los resultados intermedios de una transacción no deben ser visibles a otras transacciones.

Operaciones Atómicas

Atomicidad ante fallas: los efectos son atómicos aun cuando el servidor falla.

Los datos que se mantienen en disco

deben sobrevivir ante la falla del

servidor.

(5)

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)

„ Durabilidad (Durability)

Propiedades ACID

„ Para soportar la atomicidad ante fallas y la durabilidad, los objetos de datos deben ser recuperables (estar disponibles en

almacenamiento permanente).

„ Cuando cae un servidor (falla de hardware o software) los cambios de todas las

transacciones que culminaron deben estar disponibles en el almacenamiento permanente.

Cuando el servidor sea reemplazado se recuperarán los objetos para reflejar TODO o NADA.

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.

(6)

Control de Concurrencia

Transacciones

Operaciones compuestas B

A C A B C

Serialización de operaciones conflictivas

Operaciones conflictivas Delay Ejecución

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.

Terminación

„

El manejador de transacciones puede abortar una transacción si “observa” que no puede garantizar la equivalencia secuencial. La operación de “abort”

también puede estar disponible para los

programadores: una transacción formada

por: solicitud de saldo-retiro , puede

abortar si no hay dinero suficiente.

(7)

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.

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.

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

(8)

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

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.

Transacciones Anidadas

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

transacciones. Ya que una transacción consiste de varios transacciones, es posible tener más concurrencia dentro de una sola transacción.

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

(9)

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.

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.

Transacciones Anidadas

„ Reglas para el commit de transacciones anidadas:

…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

(10)

T: Transacción de Niver Superior

T2:

T1:

T11 T12 T21

T211 Commit provisional

Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

Control de Concurrencia

„

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.

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.

(11)

„

Ejemplo:

…write(x, 100); write(x, 200) -> el valor final de x es 200

…write(x,200); write(x,100) -> el valor final de x es 100.

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.

Estado Consistente

„

Un estado consistente se logra ejecutando las transacciones de forma serial.

„

En este caso no hay posibilidad de que una transacción interfiera en lo que está haciendo la otra.

„

Esto no obstante, trae problemas de

desempeño.

(12)

S: leer-balance (cuenta A) S: leer-balance (cuenta B) S: Imprimir (A + B) T: debito(cuenta A, 1000) T: crédito(cuenta B, 1000)

T: debito(cuenta A, 1000) S: leer-balance (cuenta A) S: leer-balance (cuenta B) S: Imprimir (A + B) T: crédito(cuenta B, 1000) T: debito(cuenta A, 1000)

T: crédito(cuenta B, 1000) S: leer-balance (cuenta A) S: leer-balance (cuenta B) S: Imprimir (A + B)

Ejecución Serial Ejecución Serial

Ejecución Entre-mezclada

La tercera ejecución no es equivalente a ninguna de las dos ejecuciones hay una inconsistencia, S lee actualizaciones intermedias de T, está viendo un estado inconsistente.

Control de Concurrencia: Problemas que generan las operaciones conflictivas ejecutándose concurrentemente

„ Actualizaciones Perdidas: otro ejemplo.

balance = b.obtenBalance(); 200$

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

c.débito(balance/10) balance = b.obtenBalance(); 200$

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

a.débito(balance/10)

U:

balance = b.obtenBalance();

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

balance = b.obtenBalance();

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

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

„

El problema viene por paralelizar o

pretender que las 2 transacciones se

ejecuten concurrentemente cuando deben

ejecutarse en forma secuencial.

(13)

„ Recuperaciones Inconsistentes

Total = a.obtenbalance();

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

a.débito(100) $100

b.crédito(100) $300 W:

Unasucursal.totalSucursal();

V:

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

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

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

Control de Concurrencia: Sol. a actualizaciones perdidas.

balance = b.obtenBalance(); 220$

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

c.Débito(balance/10) balance = b.obtenBalance(); 200$

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

a.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 secuenciamiento + cierto grado de concurrencia.

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 secuencializarse con respecto a su acceso por otras transacciones.

(14)

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

Control de Concurrencia

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

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

Z=lee(i) x = lee(i)

escribe(i,10)

escribe(j,20)

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, U lee j antes que T

A B C T D

U

Todos los objetos tienen que ser accedidos por las transacciones en el mismo orden.

i: T luego U j: U luego T

(15)

Control de Concurrencia: Problemas que generan las operaciones conflictivas

„ Recuperaciones Inconsistentes

Total = a.obtenbalance();

total = total + b.balance;

total = total + c.balance():

a.Débito(100) $100

b.Crédito(100) $300 W:

Unasucursal.totalSucursal();

V:

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

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

V accede a antes que W. V accede a b después de W.

a: V, W b: W, V

Sol. Del problema de

Recuperaciones Inconsistentes.

W:

Total = a.obtenbalance();

total = total + b.balance;

total = total + c.balance():

V:

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

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

b: V, W

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.

(16)

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

Control de Concurrencia

„

Una forma de evitar abortos en cascada es sólo permitir a las transacciones leer objetos que fueron escritos por

transacciones consumadas. Es decir, implementar de forma estricta la propiedad de aislamiento.

Control de Concurrencia

Escrituras Prematuras

a= 105$

a.Crédito(+5) 110$

a= 100$

a. Crédito(+5) 105$

U:

b.crédito(+5) T:

a.crédito(+5)

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.

(17)

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)

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.

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.

(18)

C C C

Transaction Manager scheduler

TPS

Recovery Manager Cache Manager Data Manager

Estructura de un Sistema de Manejo de Transacciones

„El Planificador usa alguna estrategia para permitir una ejecución concurrente que sea secuencialmente equivalente.

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.

Control de Concurrencia: Bloqueos

balance = b.obtenBalance(); 220$

b.ponBalance(balance*1.1) 242$

c.Extrae(balance/10) balance = b.obtenBalance(); 200$

b.ponBalance(balance*1.1) 220$

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

(19)

Control de Concurrencia:Bloqueos

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 TransactionDesbloquea B,C BeginTransaction

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

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

U:

balance = b.obtenBalance();

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

balance = b.obtenBalance();

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

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)

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.

(20)

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)

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

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.

(21)

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

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.

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 un mejor paralelismo al permitir que se realicen concurrentemente transacciones que hagan operaciones no conflictivas.

(22)

Algoritmo de locking o bloqueo

Se toma un lock de lectura, y se promueve a un bloqueo de escritura cuando se va a escribir sobre el mismo objeto.

Cuando una transacción posterior desea leer, debe esperar hasta que se libere el lock de escritura.

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.

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.

(23)

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. Esto garantiza que puedan mantenerse los bloqueos hasta que se haya consumado o abortado la transacción a nivel superior.

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.

Algoritmo de locking o bloqueo

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

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

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

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

b.Débito Espera por U Bloqueo en B

U T

(24)

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.

T U T U

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

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

(25)

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.

• 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

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.

„ Otros esquemas (Ver en el material de apoyo)

…Bloqueo de Versiones

…Jerárquico

(26)

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.

„

Recuperación de Transacciones

Algoritmo Optimista

Se permite que las transacciones procedan como si no hubiera posibilidad de conflicto con otras transacciones hasta que el cliente complete su tarea y solicite un

EndTransaction. Cuando aparece un conflicto se abortará la transacción.

Las modificaciones/accesos se hacen sobre espacios privados o provisionales y se lleva registro de los datos que han sido modificados/accedidos. Al momento del commit, se chequea que los espacios privados sean válidos, de no serlos, se aborta la transacción.

A toda transacción se le asigna un identificador (orden secuencial ascendente).

Algoritmo Optimista

Cada transacción cumple tres fases:

Ejecución:Todos los reads se ejecutan inmediatamente sobre la última versión “consumada” del dato. Los writes crean versiones tentativas. Se mantiene un conjunto de lectura (datos leídos) y un conjunto de escritura (versiones tentativas de los datos). No hay posibilidad de “lecturas sucias”, sólo se leen valores consumados.

Validación: Ante la solicitud de un commit, se valida si la transacción realizó operaciones conflictivas con otras transacciones. Si la validación tiene éxito se puede hacer COMMIT. Si falla, se debe usar alguna forma de resolución de conflictos (abortar alguna de

(27)

Algoritmo Optimista

Actualización: Si la transacción es validada, todos los cambios hechos sobre los espacios privados se actualizan en las versiones originales.

Algoritmo Optimista

Fase de validación:

Ante el End_transaction, a cada transacción se le asigna un número (secuencial ascendente, i) que define su posición en el tiempo.

Algoritmo Optimista

Fase de validación (Tv):

La validación se basa en las siguientes reglas : Tv Ti Regla (i<v)

1. write read Ti no debe leer datos escritos por Tv

2. read write Ti no debe escribir datos leídos por Tv

3. write write Ti no debe escribir datos que está escribiendo o haya escrito Tv y Tv no debe escribir datos que está escribiendo o haya escrito Ti

Simplificación: fases de validación y escritura son secciones críticas (muy cortas), se supondrá que no pueden solaparse 2 transacciones en estas fases; se satisface la regla 3. Sólo hay que validar las reglas 1 y 2

(28)

Algoritmo Optimista

Validación hacia atrás:

Los reads de las Ti se realizaron antes que la validación (por tanto escritura) de Tv, entonces se cumple la regla 1.

Sólo se valida la regla 2 para cada Ti (Ti(write), Tv(read)): que Tv no haya leído un valor sin consumar.

valid= true;

for (Ti=startTn+1;Ti<=finishTn,Ti++) { if (“read_set” of Tv intersects “write_set” Ti)

valid=false;

}

Algoritmo Optimista

Validación hacia atrás:

startTn: Ti más grande asignado a una transacción committed al momento que Tv entra a su fase de trabajo.

finishTn: Ti más grande asignado a una transacción committed al momento que Tv entra a su fase de validación

Hay que validar con las Ti que hacen Commit durante la fase de ejecución de Tv.

Algoritmo Optimista

Validación hacia atrás:

Sólo es necesario validar los conjuntos de lectura. Las transacciones que sólo hacen escritura no se validan (lo que ella escriba lo validarán otras transacciones mayores posteriormente).

Si Tv no es válida, se aborta

(29)

Algoritmo Optimista

Validación hacia atrás:

T1

T2 T3

Tv activa1

activa2

Transacciones anteriores committed

Transacción en validación

Trabajo Validación Escritura

Algoritmo Optimista

„ Validación hacia atrás: requiere que los conjuntos de escritura de las versiones antiguas de los objetos ya consumadas sean retenidas hasta que no hayan transacciones solapadas, aún no validadas, con la que pudieran entrar en conflicto. En un entorno con transacciones largas, el mantener estos conjuntos puede ser un problema.

Algoritmo Optimista

„Validación hacia adelante: el conjunto de

escritura de Tv se compara con el

conjunto de transacciones activas que se

solapan, aquellas que están aún en su

fase de trabajo.

(30)

Algoritmo Optimista

Fase de validación:

La validación se basa en las siguientes reglas : Tv Ti Regla (v<i)

1. write read Tv no debe escribir datos leídos por Ti 2. read write Tv no debe leer datos escritos por Ti 3. write write Ti no debe escribir datos que está escribiendo o

haya escrito Tv y Tv no debe escribir datos que está escribiendo o haya escrito Ti

Validación hacia adelante:

Se satisface la regla 2 porque las transacciones activas no escriben mientras que Tv no se ha completado.

Sólo se valida la regla 1 para cada Ti: se compara el conjunto de escritura de Tv con los conjuntos de lectura de las transacciones activas.

valid= true;

for (Tid=activa1;Tid<=activaN,Tid++) { if (“write_set” of Tv intersects “read_set” of Ti)

valid=false;

}

Algoritmo Optimista

Validación hacia delante:

activaX: Representan transacciones que aún no han entrado a la fase de validación

Las transacciones que sólo hacen lecturas no requieren ser validadas

Si Tv no es válida:

Abortar las activas y consumar Tv Abortar Tv

Algoritmo Optimista

(31)

Algoritmo Optimista

Validación hacia adelante:

T1

T2 T3

Tv activa1

activa2

Transacciones anteriores committed

Transacción en validación

Trabajo Validación Escritura

Algoritmo Optimista

Desventajas:

Hay posibilidad se inanición: una transacción puede abortar indefinidas veces y no se contempla un mecanismo para evitarlo.

Este algoritmo no serviría para nada en sistemas con transacciones largas o muchas transacciones en conflicto.

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.

(32)

Algoritmo por Marcas de Tiempo

Las operaciones se validan al momento de ser ejecutadas.

Cuando una transacción comienza, se le asigna un timestamp

La regla de ordenación básica por marca de tiempo está basada en los conflictos de operación:

Una solicitud de una transacción para escribir un objeto es válida sólo si ese objeto fue leído y escrito por última vez por transacciones anteriores en el tiempo.

Una petición de lectura a un objeto es válida sólo si el objeto fue escrito por última vez por una transacción anterior en el tiempo.

Algoritmo por Marcas de Tiempo

Se trabaja con versiones tentativas. Las versiones tentativas de los objetos son consumadas en el orden determinado por las marcas de tiempo de las transacciones que las realizaron.

Cada item de datos tiene asociado:

Un timestamp de escritura (Twrite_commit), un timestamp de lectura (Tread) y un conjunto de versiones tentativas con su propio timestamp

Un write aceptado genera una versión tentativa Un read se dirige a la versión con el máximo timestamp menor que el timestamp de la transacción

Algoritmo por Marcas de Tiempo

Para saber cuando una operación de escritura es válida se aplica el siguiente algoritmo:

Sea Tj una transacción que desea hacer unaoperación de escriturasobre el objeto D.

If ((Tj >= Max (Tread en D)) &&

(Tj > write_commit en D))

Proceder con el write sobre una versión tentativa nueva, con marca de tiempo Tj

else // write is too late Abortar Tj;

(33)

Algoritmo por Marcas de Tiempo

Regla de escritura (No se muestran las marcas de lectura) a) T3->write b) T3-> write

c) T3->write d) T3-> write T2

después antes

T2 T3

T1

después antes

T1 T2 T2

T3

T1

después antes

T1 T3 T4

T4

T4

después antes

T4

T3 Aborta Versión tentativa Versión committ

Algoritmo por Marcas de Tiempo

Para saber cuando rechazar o aceptar inmediatamente una operación de lectura

Sea Tj una transacción que desea hacer un read sobre el objeto D.

If ((Tj > Max (Write_Commit en D))

Sea Ds la versión de D con la máxima marca de tiempo de escritura menor a Tj (commited o no)

Si se ha consumado Ds: realiza la operación de lectura.

Si no, espera hasta que la transacción que hizo la versión Ds haga commit o abort.

else // write is too late Abortar Tj;

Algoritmo por Marcas de Tiempo

Regla de lectura

a) T3->read b) T3-> read

c) T3->read d) T3-> read

T2 T2 T4

T1 T2 T4 T3 Aborta

Versión tentativa Versión committ Seleccionado

(Ds)

read se ejecuta inmediatamente

Seleccionado (Ds)

read se ejecuta inmediatamente

Seleccionado read espera

(34)

Algoritmo por Marcas de Tiempo

„

Las versiones commit (consumadas) de cada objeto deben crearse en el orden de las marcas de tiempo.

„

Un coordinador necesita esperar, a veces, que se completen las transacciones anteriores antes de escribir todas las versiones consumadas de los objetos.

MTL MTE {} S

S,U MTL MTE {} S {T}

S,T

T {U}

T,U MTL MTE {} S

S,T T BeginT

Bal=b.obtenBalance() Espera por T

….

Bal=b.obtenBalance() b.Crédito() c.Débito() beginT

Bal=b.obtenBalance() b.crédito(balance*1.1)

a.Débito() Commit

c b a

U T

Algoritmo por Marcas de Tiempo

La última marca de lectura Corresponde a la transacción T

S < T < U. En negritas se colocan las operaciones ya consumadas

Ejercicio

BeginT escribe(i,55) escribe(j,66)

Commit BeginT

X=lee(i) Escribe(j,44)

U T

BeginT Escribe(i,55) Escribe(j,66) commit BeginT

X=lee(i) Escribe(j,44)

U T

Corra el algoritmo de secuenciación por marcas de tiempo. Las marcas de tiempo iniciales de lectura y escritura son t0.

(35)

BeginT

Escribe(i,55) Escribe(j,66) Commit BeginT

y = lee(k)

x = lee(i)

Escribe(j,44) Commit

U T

Qué pasa cuándo va a terminar la transacción T si corremos el algoritmo Optimista con validación hacia atrás, hacia adelante???

Ejercicio

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

Lee(i) devuelve el valor de ai Escribe(i,valor) asigna el valor “valor” a ai

Las transacciones T y U se definen como sigue:

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

1. Cómo funciona o escriba una secuencia de ejecución con bloqueo estricto de dos fases.

2. Describa un solapamiento de las transacciones T y U en el que los bloqueos se Liberan prontamente y se obtiene un efecto que no es secuencialmente equivalente.

Transacciones

Distribuidas

(36)

Contenido

„

Transacciones Distribuidas

…Transacciones Planas y Anidadas …Commit y Abort en un Sistema Distribuido …Control de Concurrencia

„Por Bloqueo

„Optimista

„Marcas Temporales …Recuperación

Transacciones Distribuidas

„

Sus actividades involucran múltiples servidores.

„

Se usa el término transacciones

distribuidas para referirse a transacciones

planas o anidadas que acceden a objetos administrados por múltiples servidores.

Las transacciones distribuidas pueden ser planas o anidadas.

Cliente:

begin_transaction a.extrae(4) c.deposita(4) b.extrae(3);

d.deposita(3);

end_transaction

cliente

X

Z Y

Transacción Plana:

Un cliente realiza peticiones a más de un servidor.

Las peticiones son secuenciales

A

B

C y D

(37)

Transacciones Distribuidas

Transascción distribuida anidada: las transacciones del mismo nivel son concurrentes. Si están en Servidores distintos pueden ejecutarse en paralelo.

T Cliente

X T1

Y T2

M T11

P T22 T12N T21

Transacciones Anidadas

Sea una transacción distribuida donde el cliente transfiere

$10 de la cuenta A a C y $20 de B a D. Las cuentas A y B están separadas en servidores X e Y y las cuentas C y D están en el servidor Z.

Si la transacción se estructura como un conjunto de cuatro transacciones anidadas, los cuatro requerimientos ( dos depósitos y dos retiros) pueden correr en paralelo y el efecto total es lograr mayor rendimiento que una transacción simple ejecutando las cuatro operaciones secuencialmente.

(38)

Procesamiento de transacciones distribuidas

„

Un cliente comienza una transacción enviando un begin_transaction a cualquier servidor TPS. Éste se convierte en el coordinador y los que se tengan que contactar a partir de aquí se convierten en participantes.

C

D B A beginTransaction

endTransaction

Cliente

Unirse

Unirse Unirse

b.extrae(T,3) Coord.

a.extrae(4)

b.extrae(3)

c.deposita(4)

d.deposita(3) SucursalZ

SucursalY SucursalX

Nota: el coordinador está en uno de los Servidores, por ejemplo SucursalX

Participante

Participante

Participante

Procesamiento de transacciones distribuidas

El coordinador que inició la transacción es el responsable final de consumarla o abortarla.

Durante el progreso de una transacción el coordinador registra la lista de referencias de participantes, y cada participante registra una referencia hacia el coordinador.

(39)

Procesamiento de transacciones distribuidas

La operación BeginTransaction devuelve el TID. Los identificadores de las transacciones deben ser únicos dentro del sistema

distribuido.

Una forma sencilla de obtener identificadores únicos esto es que cada TID tenga dos partes: el identificador del servidor (e.g.

dirección IP) y un número único dentro del servidor.

Procesamiento de transacciones distribuidas

„ Existen dos aspectos importantes a considerar en las transacciones distribuidas:

…La Consumación de una Transacción

…Control de concurrencia

„ Se supone que existe una comunicación entre TPSs a través de un protocolo de aplicación.

Estos protocolos se implementan sobre RPC o pase de mensajes.

Transacciones Distribuidas

Cuando una transacción distribuida termina, la propiedad de atomicidad exige que todos los servidores acuerden lo mismo (commit) o todos aborten (abort). Existen protocolos para llegar a compromisos (Two-Phase-Commit)

Las transacciones distribuidas deben ser globalmente serializadas. Existen protocolos de control de concurrencia distribuida.

(40)

Protocolos de Consumación Atómica

Cuando el coordinador recibe un requerimiento Commit de una transación, tiene que asegurar:

Atomicidad: Todos los nodos se comprometen con los cambios o ninguno lo hace y cualquier otra transacción percibe los cambios en todos los nodos o en ninguno.

Aislamiento:Los efectos de la transacción no son visibles hasta que todos los nodos hayan tomado la decisión irrevocable commit o abort.

Consumación en una fase

„ Commit de una fase atómico

Una manera simple de completar una transacción en forma atómica por el coordinador es

comunicar el requerimiento de commit o abort (por parte del cliente) a todos los participantes de la transacción y mantenerse enviando el requerimiento hasta

que todos ellos respondan con un ACK indicando que han realizado la tarea.

El protocolo no contempla que la decisión de abortar venga de uno de los participantes. Sólo puede venir del cliente.

Consumación en Dos Fases

„ Permite que cualquier participante aborte su parte de la transacción.

„ En la primera fase del protocolo cada participante vota para que la transacción sea consumada o abortada.

Una vez que el participante ha votado commit, no se le permite que aborte. Por lo tanto, antes de un participante votar por commit debe asegurarse que será capaz de llevar a cabo su parte del protocolo de consumación, incluso si falla.

„ Se dice que un participante está en estado “preparado”

si finalmente será capaz de consumar la transacción en proceso.

(41)

Consumación en Dos Fases

„

En la segunda fase: El coordinador recoge el resultado de las votaciones. Si alguno de los participantes vota por abortar, la decisión es abortar. Si todos los participantes votan consumar, ésta será la decisión.

Consumación en Dos Fases

„

Si uno de los participantes o el Cliente decide abortar (antes de la solicitud del coordinador) se le informa al resto. No se activa el protocolo de consumación.

Protocolo de Consumación en dos Fases

Fase 1 (votación)

…1. El Coordinador envía una petición (commit?) a cada participante en la transacción

…2. Cuando un participante recibe una petición commit? Responde al Coordinador con su voto (si o no). Antes de votar Sí se prepara para hacer commit guardando los objetos en almacenamiento permanente. Si el voto es No. El participante aborta de forma inmediata.

(42)

Protocolo de Consumación en dos Fases

Fase 2(finalización en función del resultado de la votación)

„ 3. El coordinador recoge los votos (incluyendo el propio)

…Si no hay fallos y todos los votos son Sí, el coordinador decide consumar la transacción y envía peticiones de COMMIT a cada uno de los participantes.

…En otro caso, el Coordinador decide abortar la transacción y envía peticiones Aborta a todos los que votaron Sí.

„ 4. Los participantes que han votado Sí están esperando por una petición de Commit o Abort por parte del Coordinador. Cuando se reciben uno de estos mensajes, se actúa en función de ellos. En caso de COMMIT se retorna al servidor:haveCOMMITTed.

Protocolo de Consumación en dos Fases

„ El protocolo podría fallar debido a la caída de uno o más servidores o debido a un corte en la comunicación.

„ Para cubrir la posibilidad de caidas, cada servidor guarda la información correspondiente al protocolo en un dispositivo de

almacenamiento permanente. Esta información la puede recuperar un nuevo proceso que se inicie para reemplazar al servidor caído.

(43)

Situación en la que un participante ha votado Sí y está

esperando para que el coordinador le informe el resultado de la votación

Fallas en la Comunicación

- El participante está incierto frente al resultado y no puede seguir adelante hasta que obtenga los resultados de la votación por parte del coordinador.

- No puede decidir unilateralmente, debe mantener los objetos. Envía un mensaje al Coordinador de DameDecision. Cuando obtiene la respuesta continua en el paso 4 del protocolo.

- Si el Coordinador ha fallado el participante no podrá obtener una decisión hasta que el servidor sea reemplazado.

Acciones frente a un timeout

El participante ha realizado todas sus tareas y aún no ha recibido el llamado Puede Consumar?? (primera comunicación)

En este caso, como no se ha tomado

ninguna decisión el participante puede

decidir unilateralmente abortar.

(44)

Acciones frente a un timeout

El coordinador puede sufrir retrasos cuando está esperando por los votos de los participantes.

Dado que no está decidido el destino de la transacción, tras cierto periodo de tiempo el coordinador puede abortar. En ese momento, anuncia su decisión a todos los participantes que ya habían votado. Algunos participantes retrasados pudieran votar Sí, sin haber recibido el último mensaje del coordinador. El

coordinador ignora este Sí y el participante pasa al estado incierto.

Transacciones Anidadas

T T2

T1 T11

T12

T21

T22

Aborta en M

Cons. Provisional (en X)

Cons. Provisional (en N)

Cons. Provisional (en N)

Cons. Provisional (en P) Abortado (en M)

T Cliente

X T1

Y T2

M T11

P T22

N T12 T21

(45)

Transacciones Anidadas

„ Cuando finaliza una subtransacción toma una decisión independiente sobre si consumarse de forma provisional (no es lo mismo que estar preparado) o abortar. Una consumación provisionales simplemente una decisión local y no necesariamente se guarda copia en un dispositivo de almacenamiento permanente

„ Las transacciones trabajan y, cuando terminan, el servidor donde se encuentran registra información sobre si se han consumado provisionalmente o han abortado.

Transacciones Anidadas

„ Cuando una transacción anidada se consuma en forma provisional informa de su estado y del estado de sus descendientes a su madre.

„ Cuando una transacción aborta, simplemente informa de haber abortado a su madre.

„ Al final, la transacción a nivel superior recibe una lista de todas las subtransacciones en el árbol junto con el estado de cada una de ellas.

Transacciones Anidadas

„

La transacción a nivel superior juega el

papel de Coordinador en el protocolo de

consumación en 2 fases.

(46)

Transacciones Anidadas

T T2

T1 T11

T12

T21

T22

Aborta en M

Cons. Provisional (en X)

Cons. Provisional (en N)

Cons. Provisional (en N)

Cons. Provisional (en P) Abortado (en M)

La lista de participantes consta de los servidores de todas las subtransacciones que se hayan consumado provisionalmente pero no tienen ascendentes que hayan abortado: T, T1, T12

Transacciones Anidadas

„ La transacción a nivel superior debe intentar consumar lo que quede del árbol. A T1 y T12 se les pedirá que voten para obtener el resultado.

„ Si votan consumar deben preparar las transacciones guardando el estado de los objetos en el dispositivo de almacenamiento permanente.

„ La segunda fase es idéntica:

se recogen los votos y se informa a los participantes en función del resultado.

T T2

T1 T11

T12

T21

T22

Aborta en M Cons. Provisional (en X)

Cons. Provisional (en N)

Cons. Provisional (en N)

Cons. Provisional (en P) Abortado (en M)

Control de Concurrencia: Bloqueos

„ En una transacción distribuida los bloqueos se mantienen localmente (en el mismo servidor).

„ Cada servidor gestiona un conjunto de objetos y es responsable de asegurar que éstos mantienen su consistencia cuando se accede a ellos desde transacciones concurrentes.

„ Cada servidor es responsable de aplicar control de concurrencia sobre sus propios objetos.

„ Los miembros de una colección de transacciones distribuidas son además responsables de garantizar que las transacciones se ejecutan de forma secuencialmente equivalente.

(47)

Control de Concurrencia: Bloqueos

„ El administrador local de bloqueos puede decidir si otorga un bloqueo o hace que la transacción que lo requirió espere. Al otorgar un bloqueo debe informar al coordinador de la transacción.

„ Sin embargo no puede liberar ningún bloqueo mientras la transacción que los tiene no haya terminado (commit o abort) en todos los servidores involucrados en la transacción.

„ Cuando se usa el bloqueo para control de concurrencia, los objetos permanecen bloqueados y no están disponibles para otras transacciones hasta que se sepa que la transacción ha abortado o se ha consumado en todos los servidores involucrados.

Bloqueos

Dado que los administradores de bloqueos en diferentes servidores otorgan bloqueos independiente de los demás, es posible que diferentes servidores impongan diferente orden sobre las transacciones.

Considérese el siguiente entrelazado de las transacciones T y U en los servidores X e Y:

T U Write(A) en X lock A

Write(B) en Y lock B Read(B) en Y espera U

Read(A) en X espera por T

El objeto A está en el servidor X y el objeto B en el servidor Y A

B Servidor X

Servidor Y

Bloqueos

Se tiene T antes que U en un servidor y U antes que T en

el otro.

„ Cuando se detecta una condición de

interbloqueo las transacciones son abortadas.

„ En este caso el coordinador será informado y abortará las transacciones en los participantes involucrados.

(48)

Algoritmos de Detección de Interbloqueos Distribuidos

1.- Centralizado: basado en grafos de espera

Máquina 0 Máquina 1 Coordinador

S

B R A

T S C

T C S

B R A

Cómo se mantiene el grafo en el coordinador ?

• Cada vez que ocurra una variación en su grafo notifica al coordinador .

• Periodicamente cada máquina notifica sus últimos cambios .

• Periodicamente el coordinador solicita la información.

Transacciones Recursos

Algoritmos de Detección de Interbloqueos Distribuidos

1.- Centralizado: basado en grafos de espera

Máquina 0 Máquina 1 Coordinador

S

B R A

T S

T C S

B R A

Problema: Los 3 casos pueden conducir a un Deadlock falso.

Ejemplo: Si se pierden mensajes

Si B solicita a T y C libera a T y llega primero el mensaje de B al coordinador, entonces el cree que hay deadlock.

Transacciones Recursos

T

1

c 2

Algoritmos de Detección de Interbloqueos Distribuidos

„

Tener el coordinador de bloqueos

centralizado tiene problemas de

escalabilidad, rendimiento, tolerancia a

fallos, etc.

(49)

Algoritmo Distribuido (Caza de Arcos)

„

En esta aproximación el grafo no se construye en forma global, sino que cada uno de los servidores implicados posee información sobre alguno de sus arcos.

„

Los servidores intentan encontrar ciclos mediante el envío de mensajes

denominados sondas.

Interbloqueo Distribuido

Z X

y

C D A

V B W

U

W

V U

Pasos del Algoritmo

„ Iniciación: Cuando un servidor percibe que una transacción T, espera por un recurso que tiene una transacción U (que está en otro servidor), inicia el algoritmo enviando una sonda que contiene el arco <T->U>al servidor que contiene el objeto por el cual está bloqueada la transacción U.

„ Si U está compartiendo el bloqueo (varias transacciones acceden al mismo objeto), se envía la sonda a los servidores responsables de estas transacciones

(50)

Pasos del Algoritmo

„ Detección: consiste en recibir sondas y decidir si se ha producido inter-bloqueo.

Por ejemplo, si un servidor recibe la sonda

<T->U> (T espera por U, que tiene el bloqueo de un objeto local), comprueba si U está también esperando. Si es así, se añade a la sonda la transacción por la que está esperando, ej, V.

<T->U->V>, y si V está esperando por un objeto en otro sitio se vuelve a reenviar la sonda.

Pasos del Algoritmo

„

Detección: Antes de reenviar la sonda, el servidor comprueba si la transacción que ha sido añadida, ej, T

…<T->U->V->T>

Ha ocasionado un ciclo, si es así se ha detectado un interbloqueo.

Pasos del Algoritmo

„

Resolución: cuando se detecta un ciclo, se

aborta una transacción en el ciclo para

romper el interbloqueo.

Figure

Updating...

References

Related subjects :