Ampliacin de BD

5. Gestin de transacciones distribuidas

5.1. Transacciones distribuidas
El concepto de transaccin proporciona un mecanismo para describir las unidades lgicas del procesamiento de una BD. Una transaccin es una unidad lgica de procesamiento de la BD que incluye una o ms operaciones de acceso a la BD, que pueden ser de insercin, eliminacin, modificacin o recuperacin. Una transaccin es una unidad atmica de trabajo que se realiza por completo o bien no se efecta en absoluto. Para fines de recuperacin el sistema necesita mantenerse al tanto de cuando la transaccin se inicia, termina y se confirma o aborta. As pues, el SGBD se mantiene al tanto de las siguientes operaciones: begin_transaction: marca el principio de la ejecucin de la transaccin. end_transaction: marca el fin de la ejecucin de la transaccin. Sin embargo, en este punto puede ser necesario verificar si los cambios introducidos por la transaccin se pueden aplicar permanentemente a la BD o si la transaccin debe abortarse por alguna razn. commit: seala que la transaccin termin con xito y que cualquier actualizacin ejecutada por ella se puede confirmar sin peligro en la BD y que no se deshar. abort: indican que la transaccin termin sin xito y que cualquier cambio o efecto que pueda haberse aplicado a la BD debe deshacerse. En el caso de las BD Distribuidas, una transaccin est formada por un conjunto de procesos, denominados agentes, cada uno de los cuales se va a ejecutar en un nodo diferente. Un agente es, por tanto, un proceso local que realiza algunas acciones para una transaccin. Para llevar a cabo los subprocesos, los agentes tienen que comunicarse; esto se realiza a travs de mensajes. Hay varias formas de organizar los agentes para construir una estructura de proceso cooperativo. En principio, asumimos que: 1. Existe un agente raz que arranca la transaccin; el lugar donde reside se denomina nodo origen de la transaccin 2. El agente raz tiene la responsabilidad de emitir las operacin begin_transaction, commit y abort, cuando corresponda. Ejemplo de transferencia de fondos: a) Nivel global:
Read (terminal, $vsldocta, $vnumorig, $vnumdest); Begin_transaction select isldocta into $isldocta from CUENTA where numcta = $vnumorig; If ($isldocta - $vsldocta) < 0 then Write else update CUENTA set isldocta = isldocta - $vsldocta where numcta = $vnumorig; update CUENTA set isldocta = isldocta + $vsldocta where numcta = $vnumdest; end; commit

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 25

Ampliacin de BD b) Constituida por dos agentes:

Read (terminal, $vsldocta, $vnumorig, $vnumdest); Begin_transaction select isldocta into $isldocta from CUENTA where numcta = $vnumorig; If ($isldocta - $vsldocta) < 0 then Write else update CUENTA set isldocta = isldocta - $vsldocta where numcta = $vnumorig; create AGENTE1 send to AGENTE1($vsldocta, $vnumdest) end; commit

Subtransaccin ejecutada por el AGENTE1 Receive from AGENTE_RAIZ ($vsldocta, $vnumdest) update CUENTA set isldocta = isldocta + $vsldocta where numcta = $vnumdest;

Si asumimos que las cuentas estn distribuidas en nodos diferentes de la red (p.ej: sucursales de un banco), la ejecucin de la transaccin ser realizada gracias a la cooperacin de varios agentes, dando lugar a un conjunto de subtransacciones. Las sentencias send y commit pueden no tener siempre esa secuencia de ejecucin; as, si el AGENTE1 falla, no podra emitirse un commit y habra que deshacer la primera actualizacin. Vamos a asumir que las sentencias begin_transaction, commit y abort son emitidas por el agente raz, no son locales; afectan a todos los agentes de la aplicacin.

5.2. Atomicidad de las transacciones distribuidas

La atomicidad es una propiedad de las transacciones que asegura que o bien son realizadas todas las operaciones o ninguna. La atomicidad requiere que si una transaccin es interrumpida por un fallo, sus resultados parciales sean restaurados a las condiciones iniciales. Las razones tpicas por las que una transaccin no finaliza son la cancelacin o ruptura del sistema. La finalizacin puede ser solicitada por la propia transaccin (o el usuario) debido a que alguna de sus entradas sea errnea o porque algunas condiciones hacen que la terminacin de la transaccin sea inadecuada.

5.2.1.

Fallos de comunicacin en BD Distribuidas

Los mecanismos de recuperacin del SGBD se construyen para permitir la vuelta a un punto anterior consistente despus de producirse un fallo. En caso de las BD Distribuidas, los mecanismos de recuperacin debern tratar, adems de los fallos propios de las BD centralizadas (prdida de informacin de memoria, del disco, etc.), aquellos que pueden ocurrir en las comunicaciones entre nodos. Cuando se enva un mensaje desde el nodo X al nodo Y, se requiere de la red de comunicacin el siguiente comportamiento:

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 26

Ampliacin de BD 1. X recibe una contestacin positiva despus de una demora que es menor que algn valor mximo dmax. 2. El mensaje es distribuido a Y en una secuencia adecuada con respecto a otros mensajes enviados entre X e Y. 3. El mensaje es correcto Hay gran variedad de posibles fallos con respecto a la especificacin anterior; por ejemplo, el mensaje podra ser incorrecto, podra estar fuera de secuencia, etc. Actualmente, las redes de comunicacin son capaces de eliminar la mayora de los errores, por lo que asumimos que: 1. Si un mensaje de X a Y es distribuido a Y, entonces el mensaje es correcto y est en secuencia con respecto a otros mensajes enviados entre X e Y. 2. Si X recibe una contestacin, el mensaje ha sido distribuido. Sin embargo, existen otros fallos de comunicacin que el SGBD Distribuido debe controlar. Por un lado, est la prdida de mensajes. As, si despus de una demora dmax, el nodo X no ha recibido contestacin, X no puede saber si el mensaje ha sido distribuido o no. Esta incertidumbre es debida al hecho que la falta de contestacin puede significar dos cosas: o el mensaje original se perdi, y por lo tanto no ha habido contestacin, o el mensaje original fue distribuido, pero la contestacin se perdi. En este caso, X tpicamente intenta enviar el mensaje un nmero finito de veces asumiendo que la comunicacin con el nodo Y ha fallado. Otro tipo de fallo de comunicacin se produce con la aparicin de particiones en la red. Con las redes de comunicacin actuales, que son capaces de encaminar los mensajes, se asume lo siguiente: si X no puede comunicarse con Y pero s con Z, entonces Z no puede comunicarse tampoco con Y. En este caso, cuando dos nodos X e Y no pueden comunicarse, significa que no hay ruta de encaminamiento disponible entre ellos, y la red se dice que est particionada en dos o ms subredes desconectadas, una incluyendo X (y Z) y otra incluyendo Y. Todos los nodos que pertenecen a la misma subred pueden comunicarse entre ellos; sin embargo no pueden comunicarse con los nodos que pertenecen a una subred diferente hasta que la particin sea reparada.

5.2.2.

Recuperacin de transacciones distribuidas

El gestor de transacciones distribuidas (Distributed Transaction Management, DTM) requiere que en cada nodo haya un gestor de transacciones local (denominado Local Transaction Managemente, LTM), con capacidad para asegurar la atomicidad de las subtransacciones. Cada agente puede, por lo tanto, emitir las operaciones begin_transaction, commit y abort a su LTM (denominadas local_begin, local_commit y local_abort para distinguirlas de las primitivas de las transacciones distribuidas). El hecho de que los gestores locales garanticen atomicidad para las transacciones locales no es por s mismo suficiente para proporcionar la atomicidad a nivel distribuido. Para asegurarse que o todas las acciones de una transaccin distribuida se realizan o ninguna se necesitan dos condiciones: 1. En cada nodo se realizan todas las acciones o ninguna 2. Todos los nodos deben tomar la misma decisin con respecto a la confirmacin o cancelacin de las subtransacciones. La relacin entre gestin de transacciones distribuidas y locales se representa en el modelo de referencia de la figura siguiente:

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 27

Ampliacin de BD

Agente raz
INTERFAZ 1 Begin_transaction Commit Abort Create

mensajes

mensajes

Agente

Agente

TRANSACCIN DISTRIBUIDA

mensajes

mensajes

Agente DTM

Agente DTM

Agente DTM

DTM

INTERFAZ 2

Local_begin Local_commit Local_abort Local_create

LTM nodo1

LTM nodo2

LTM nodo3

LTM

Figura 3.- Modelo de referencia de recuperacin de una transaccin distribuida

En el nivel ms bajo se encuentran los gestores locales, que no necesitan comunicarse entre ellos. Los LTMs implementan la Interfaz2: local_begin, local_commit y local_abort. Se incluye tambin la primitiva local_create, debido a que la creacin del agente es una funcin de los sistemas locales. En el siguiente nivel est el gestor de transacciones distribuidas DTM, que est implementado por un conjunto de agentes DTM que intercambian mensajes entre ellos. DTM implementa la Interfaz1: begin_transaction, commit, abort y create remoto. La creacin de un nuevo agente es una primitiva que emite el DTM para conocer qu agentes constituyen la transaccin distribuida. En el nivel ms alto est la transaccin distribuida, constituida por el agente raz y los otros agentes. Ya que nicamente el agente raz puede emitir un begin_transaction, commit y abort, la Interfaz 1 es usada solamente por el agente raz. Este modelo de referencia no debe ser considerado como la organizacin de ejecucin de una transaccin distribuida; de hecho la mayora de los sistemas no implementan explcitamente todos los niveles en tiempo de ejecucin. Se trata de un modelo conceptual para comprender cmo trabajan los algoritmos y a qu nivel pertenece una operacin, y no es necesariamente una estructura de implementacin. Vamos a analizar cmo el gestor de transacciones distribuidas implementa las primitivas de la Interfaz 1: Begin_transaction: cuando el agente raz emite una primitiva begin_transaction, el DTM tendr que emitir una primitiva local_begin al LTM del nodo origen y a todos los nodos en los que hay agentes activos de la misma aplicacin, transformando todos los agentes en subtransacciones; desde este momento la activacin de un nuevo agente por la misma transaccin requiere que el LTM emita un local_begin donde el agente est activo, por lo que el nuevo agente se crea como una nueva subtransaccin. En la Figura 4, las primitivas y mensajes mostrados son emitidos por los diferentes componentes del modelo de referencia para la ejecucin de la transaccin de transferencia de fondos. Los nmeros indican el orden en que son realizadas las acciones y enviados los mensajes.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 28

Ampliacin de BD

Agente raz Begin_transaction Create AGENTE1 Send to AGENTE1

Agente 1 receive

1 3
Agente DTM Agente DTM

Local_begin Send create

4
Local_create Local_begin

2
LTM nodo1 Begin_transaction

5 7

LTM nodo2 Begin_transaction

Figura 4.-Acciones y mensajes durante la primera parte de la transferencia de fondos

Abort: cuando el agente raz emite un abort, todas las subtransacciones existentes deben ser canceladas. Esto se realiza por peticin de local_abort a los LTMs en todos los lugares donde est activa una subtransaccin. Commit: la implementacin de una primitiva commit es la ms difcil y cara. La principal dificultad est en el hecho de que la confirmacin correcta de una transaccin distribuida requiere que todas las subtransacciones tengan confirmacin local. No es aceptable que una subtransaccin cancele debido a un fallo y que otra subtransaccin confirme. Para implementar esta primitiva se realiza una confirmacin en 2 fases (2PC).

5.2.3.

Confirmacin en dos fases (2PC)

En el protocolo bsico, hay un agente coordinador y el resto de los agentes que deben confirmar juntos se denominan participantes. El coordinador es responsable de tomar la decisin final de confirmacin o cancelacin. Cada participante corresponde a una subtransaccin que ha realizado alguna operacin de escritura sobre la BD local. La idea bsica del 2PC es determinar una decisin nica para todos los participantes con respecto a la confirmacin o cancelacin de subtransacciones locales. Si un participante no puede confirmar su subtransaccin local, todos los participantes deben cancelar localmente. El protocolo se realiza en dos fases. La meta de la primera fase es alcanzar una decisin comn, y la de la segunda fase es implementar esta decisin. Veamos el protocolo cuando hay ausencia de fallos:

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 29

Ampliacin de BD

Coordinador: enviar mensaje prepare y activar un timeout Participantes: esperar por el mensaje prepare si el participante puede confirmar entonces enviar el mensaje de respuesta ready al coordinador en caso contrario enviar el mensaje abort al coordinador Coordinador: esperar por el mensaje (ready o abort) de todos los participantes o al timeout si el timeout expir o alguna respuesta es abort entonces enviar el mensaje abort a todos los participantes en caso contrario enviar un mensaje commit a todos los participantes Participantes: esperar un mensaje del coordinador enviar el mensaje ACK al coordinador ejecutar el mensaje recibido Coordinador: esperar el ACK de todos los participantes
Figura 5.- Protocolo bsico de confirmacin en dos fases

Como se puede observar en la Figura anterior, el protocolo tiene 2 fases: FASE 1: el coordinador pregunta a todos los participantes para prepararse para un commit; cada participante responde ready si est preparado para confirmar y puede confirmar. Tambin activa un mecanismo de timeout, que causar una interrupcin en el caso de que se alcance un intervalo de tiempo determinado. Cuando un participante est seguro que puede confirmar su subtransaccin (siguiendo las tcnicas de recuperacin propias de una BD centralizada), entonces responde ready. El coordinador decide si la transaccin se confirma o cancela como resultado de las respuestas que ha recibido de los participantes. Si todos los participantes han respondido ready, decide confirmar la transaccin. Si alguno ha respondido abort o no ha respondido cuando el timeout ha expirado, decide abortar la transaccin. FASE 2: el coordinador comienza la segunda fase informando a todos los participantes de su decisin. Estos envan entonces el mensaje final de ACK, y realizan las acciones requeridas para confirmar o cancelar la subtransaccin. En caso de que se produzca un fallo originado por una prdida de mensajes, el comportamiento del protocolo 2PC es el siguiente: a) Un mensaje de respuesta ready o abort de un participante se pierde: En este caso, el timeout del coordinador expira, y la transaccin se cancela. b) Un mensaje prepare se pierde: En este caso, el participante permanece en espera. El resultado es el mismo que en el caso previo, porque el coordinador no recibe respuesta. c) Un mensaje commit/abort se pierde: Con el protocolo de la Figura 5 el participante destino permanece con incertidumbre respecto a la decisin. Para eliminar este problema debe introducirse un timeout en el participante. De este modo, si no se ha recibido ningn comando despus del intervalo de timeout de la respuesta, se enva una peticin de repeticin del comando. d) Un mensaje ACK se pierde: Con el protocolo de la Figura 5, el coordinador no sabe si el participante ha recibido el mensaje de comando. El problema se elimina introduciendo un timeout en el coordinador; si no se recibe un mensaje ACK desde el intervalo de timeout de la transmisin del comando, el coordinador reenva el comando.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 30

Ampliacin de BD

5.2.4.

Estructura de comunicacin para protocolos de confirmacin

Los agentes DTM tienen diferentes estructuras para implementar los protocolos de confirmacin: a) Centralizada: Es la requerida por el protocolo 2PC. En este caso, la comunicacin se realiza siempre entre el agente DTM coordinador y los participantes, pero no entre los participantes directamente.

b) Jerrquica: Se puede modificar el protocolo anterior para obtener una estructura jerrquica, donde el coordinador es el agente DTM y la raz del rbol. La comunicacin entre el coordinador y los participantes no es realizada directamente, sino propagando los mensajes hacia arriba y abajo en el rbol. Cada agente DTM, que es un nodo interno del rbol de comunicacin, colecciona los mensajes de sus hijos o les enva los mensajes directamente.

c) Lineal: En este caso, se define una ordenacin de los nodos, de modo que cada nodo (excepto el primero y el ltimo) tiene un predecesor y un sucesor. En vez de emitir un mensaje desde el coordinador a todos los participantes, el mensaje se encamina desde cada participante a su sucesor. Un protocolo lineal trabaja de la siguiente forma: 1. El agente raz requiere un commit global al DTM agente 1. 2. El DTM agente 1 decide si quiere cancelar o confirmar la transaccin; si decide cancelar, enva la informacin hacia atrs, al agente raz; de otra forma enva la decisin de confirmar al DTM agente 2. El DTM agente 2 acta de la misma manera, enviando la decisin de cancelar atrs al agente 1 o la decisin de confirmar hacia delante al DTM agente 3. Este proceso contina hasta que se propaga una cancelacin al agente raz o una confirmacin alcanza el ltimo agente DTM 3. El agente DTM N enva un mensaje de confirmacin o cancelacin hacia atrs al DTM agente (N-1); este mensaje se propaga hasta llegar al agente raz; todos los participantes reciben esta informacin y toman la accin oportuna.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 31

Ampliacin de BD

LINEAL
prepare / ready

commit / abort

El protocolo lineal reduce el nmero de mensajes requeridos respecto al protocolo centralizado, pero tiene la desventaja de la prdida de paralelismo en el proceso. Todos los participantes deciden en secuencia, mientras que en un protocolo centralizado todos los participantes deciden al mismo tiempo. Esto tiene impacto en el tiempo de respuesta. d) Distribuido: En este caso, cada agente DTM se comunica con los otros participantes. El nmero de mensajes es mucho mayor que en los casos anteriores, por lo que slo es aplicable en redes cuyos mensajes sean muy baratos, tpicamente redes locales. La demora es menor que en el caso centralizado. La transformacin del protocolo centralizado 2PC en uno distribuido no es difcil: 1. El agente raz arranca la fase de confirmacin preguntando al agente DTM en su nodo para iniciar el proceso de confirmacin. 2. El agente DTM enva el mensaje prepare. 3. Cada agente enva su respuesta a los dems agentes. 4. Cada agente recibe respuestas de los otros agentes y decide con esta informacin si confirmar o cancelar localmente.

A modo de resumen, veamos una comparativa de estos cuatro protocolos en funcin del nmero de mensajes intercambiados entre nodos y el tiempo de espera para la finalizacin de una transaccin: 1. Los cuatro protocolos requieren un nmero de mensajes que dependen del nmero N de participantes: a. Los protocolos centralizados y jerrquicos requieren 4N mensajes b. El protocolo lineal requiere 2N mensajes c. El protocolo distribuido requiere N(N-1) mensajes El mensaje ACK no es necesario en el protocolo lineal, ni tiene significado en el distribuido. 2. La demora requerida para la confirmacin depende del tiempo T de una transmisin a. El protocolo centralizado tiene una demora de 4T b. El protocolo lineal 2NT c. El jerrquico tiene una demora entre el centralizado y el lineal d. El protocolo distribuido 2T BIBLIOGRAFA Distributed Databases. Principles & Systems. Stefano Ceri, Giuseppe Pelagatti. McGraw-Hill

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 32