Transacciones Distribuidas

El acceso a los datos en los sistemas distribuidos se realiza mediante transacciones, que deben conservar las propiedades A.C.I.D. vistas en el capítulo anterior. Hay que tener en cuenta que en un esquema distribuido existen dos tipos de transacciones diferentes: transacciones locales y transacciones globales.[Gray et al., 1993] [CAE 1991]

Las transacciones locales son las que tienen acceso y actualizan datos sólo en una BD local, residente en un nodo o localidad, en tanto que las transacciones globales tienen acceso y actualizan datos en varios nodos o localidades de la red. Asegurar las propiedades de A.C.I.D. de las transacciones locales es similar al proceso realizado en entornos centralizados.

Sin embargo, en caso de transacciones globales, esta tarea es mucho más compleja y requiere un estudio mucho más detallado. El capítulo siguiente presenta diversas técnicas para la implementación de protocolos que aseguren la integridad de la BDD. El capítulo 5, en tanto, presenta los estudios de realizados, los resultados y las conclusiones obtenidas.

2.8.1. Arquitectura del sistema de transacciones

distribuidas

Cada localidad de la red tiene su propio gestor de transacciones locales, cuya función es asegurar las propiedades de A.C.I.D. de las transacciones que se ejecutan en ese emplazamiento. Los diferentes gestores, de cada nodo, cooperan para llevar a cabo la ejecución de las transacciones globales [Eppinger et al., 1991]. El modelo distribuido para transacciones contiene dos subsistemas:

¾ Gestor de transacciones: gestiona la ejecución de las transacciones que tienen acceso a los datos guardados en un nodo particular. Estas transacciones pueden ser locales o globales a ese nodo.

¾ Coordinador de transacciones: coordina la ejecución de las transacciones iniciadas en ese localidad.

La estructura del gestor de transacciones es parecida en muchos aspectos, a la utilizada para sistemas centralizados. El gestor es responsable de conservar registros históricos con fines de recuperación (bitácora, doble paginación, etc.) y participar en un esquema adecuado de control de concurrencia. Estos esquemas deben ser modificados para adaptarse a entornos distribuidos.

El coordinador de transacciones es una módulo exclusivo para sistemas distribuidos, este coordinador es responsable de:

¾ Iniciar la ejecución de la transacción

¾ Dividir las transacciones en subtransacciones y distribuir estas subtransacciones para su ejecución en los nodos adecuados (siempre que la transacción sea global)

¾ Coordinar la terminación de transacciones.

El capítulo siguiente aborda el tema de fallos en entornos distribuidos y los protocolos disponibles para asegurar integridad en la información.

2.9. Control de concurrencia distribuido

Se presentan algunos esquemas de control de concurrencia discutidos anteriormente de modo que puedan ser utilizados en entornos distribuidos. Se supone que cada emplazamiento participa en la ejecución de un protocolo de compromiso para asegurar la atomicidad de la transacción global. [Bassiouni 1988]

2.9.1. Protocolos de concurrencia

Basado en bloqueo

Los protocolos de bloqueo vistos en el capítulo anterior pueden utilizarse en entornos distribuidos, con algunas modificaciones. Estas modificaciones giran en torno del gestor de bloqueos.

Existen diversos enfoque para implementar el gestor de bloqueos, cada uno de ellos con ventajas y desventajas. Se describen y analizan a continuación los principales enfoques:

¾ Gestor único de bloqueo: el sistema conserva un único gestor de bloqueos que reside en un único emplazamiento o nodo. Todas las solicitudes de bloqueo y desbloqueo se realizan sobre él. Cada transacción solicita a esta localidad los bloqueos que necesita y luego, en caso de lectura, la misma se

realiza sobre cualquier copia. Si es una escritura se debe resolver sobre todas las copias.

Esta solución tiene por ventaja una implementación muy sencilla (exige dos mensajes para tratar las solicitudes de bloqueo y uno para tratar las de desbloqueo) y un también un tratamiento muy sencillo para deadlock

(dado que todas las solicitudes de bloqueo y desbloqueo se realizan en un solo nodo, se puede aplicar los métodos definidos para control de concurrencia en entornos concurrentes).

Los inconvenientes que se presentan son: se convierte en cuello de botella (el nodo que actúa como “revolvedor” recibe todos los mensajes y peticiones y debe procesarlas) y además es muy vulnerable a fallos (similar al anterior, si esa estación de trabajo se “cae”, no se pueden resolver más los pedidos de elementos de dato).

Es una solución que no se implementa, dado que contradice una de las principales características de sistemas distribuidos: no existencia de sitio central.

¾ Varios coordinadores: la función de gestión de bloqueos está distribuida entre varias localidades. Cada gestor de bloqueos administra las solicitudes de bloqueo y desbloqueo de un subconjunto de elementos de datos. Cada gestor de bloqueos reside en un emplazamiento diferente. Este enfoque disminuye la condición de cuello de botella del coordinador, pero hace más complicado el tratamiento de deadlock, dado que las solicitudes de bloqueo y desbloqueo no se realizan en un único emplazamiento.

¾ Protocolo de mayoría: cada localidad presenta un gestor de bloqueos local cuya función es gestionar las solicitudes de bloqueo y desbloqueo de los datos residentes en ella. Cuando una transacción desea bloquear un dato X, que no está replicado y que reside en un nodo Y particular, se envía un mensaje al gestor de bloqueos de ese nodo para solicitar el bloqueo. Si el elemento de dato X está bloqueado en un modo incompatible, la solicitud se pospone hasta que pueda concederse. Una vez que se ha determinado que se pude conceder la solicitud de bloqueo, el gestor de bloqueos devuelve un mensaje al solicitante para indicar que ha concedido la solicitud de bloqueo. Este esquema tiene la ventaja de su sencilla implementación. Exige dos transferencias de mensajes para tratar las solicitudes de bloqueo y una para las de desbloqueo. Sin embargo, el tratamiento de deadlockes más complejo, debido a que las solicitudes de datos y posteriores liberaciones se realizan sobre múltiples estaciones de trabajo (todas las que tengan elementos de datos de la BD), se discute posteriormente.

Ahora bien, si el elemento X se encuentra replicado en varias localidades, hay que enviar un mensaje con la solicitud de bloqueo a más de la mitad de esos nodos. Cada gestor determina si se puede o no conceder el pedido. La transacción no opera sobre el dato X hasta obtener una respuesta afirmativa de, al menos, la mitad más uno de las réplicas.

El método es descentralizado, lo que lo hace viable para entornos distribuidos pero genera inconvenientes con el número de mensajes que deben utilizarse para bloqueos

{

}

{

n el número de localidades con el dato X. Además, el tratamiento de

deadlocks es más complejo.

}

¾ Protocolo sesgado: se basa en el modelo del protocolo de mayoría. La diferencia es que las solicitudes de bloqueo compartidos reciben un tratamiento más favorable que los bloqueos exclusivo. El sistema conserva un gestor de bloqueo en cada emplazamiento. Cada administrador gestiona los bloqueos de todos los datos guardados en él, los bloqueos compartidos simplemente se solita a un nodo que contenga el dato. Los bloqueos exclusivos se deben efectuar sobre todos los nodos que tengan réplicas.

La ventaja que presenta este protocolo ante operaciones que solo involucren lectura es obvia. Sin embargo añade una sobrecarga mucho mayor si se trata de operaciones de escritura. Es un protocolo muy beneficioso si las operaciones de lectura son superiores a la de escrituras.

¾ Copia principal: se puede seleccionar una de las réplicas como copia principal. Así, para cada elemento de dato, la copia principal debe residir en un nodo o localidad. Cuando una transacción necesita bloquear un dato, solicita el bloqueo a la localidad donde reside la copia principal. Es esta localidad la encargada de resolver el problema del bloqueo. La copia principal permite que el control de la concurrencia para los datos replicados se trate de manera parecida a los datos no replicados. Esta semejanza permite una implementación sencilla. Sin embargo, si la localidad de la copia principal falla el dato queda inaccesible.

Basado en hora de entrada

El protocolo discutido en el capítulo anterior es, en líneas generales, igual para entornos distribuidos. El inconveniente consiste en generar marcas de tiempo únicas para cada transacción, luego el protocolo se aplica siguiendo los mismos preceptos.

Hay dos métodos principales para generar marcas temporales únicas, uno centralizado y otro distribuido. El esquema centralizado elige una localidad única encargada de distribuir las marcas temporales. Los inconvenientes de esta solución son similares a los discutidos anteriormente: cuello de botella y punto único de fallo.

El esquema distribuido permite que cada localidad genere su marca de tiempo local única. La marca temporal global única se obtiene concatenando la marca temporal local única con el identificador de la localidad, el cual es único para la red. Esta técnica puede sufrir dos inconvenientes. El primero de ellas es que se debe concatenar de manera que las marcas temporales globales de un nodo no sean siempre mayores que las generadas por otro. Se concatena, pues, primero la marca local única y luego la identificación de la localidad.

El segundo inconveniente surge cuando un nodo genera marcas más rápido que los otros, esto puede provocar que aquellas localidades que generen más lento sus transacciones siempre obtengan fracaso ante las operaciones que quieren llevar a cabo. Hace falta un mecanismo que asegure que las marcas temporales locales se generen de manera homogénea en todo el sistema. Para asegurar la sincronización intra-localidades, el contador de cada localidad es actualizado con la información que recibe. Esto es, cuando un nodo recibe una transacción global, además de cooperar en su resolución, observa el contador de ella y con este actualiza su propio generador. De esta forma, siempre los contadores se mantienen aproximadamente con el mismo valor.

2.9.2. Tratamiento de Deadlock

El tratamiento del interbloqueo o deadlock es similar a los sistemas centralizados. Por ejemplo, puede se puede utilizar el protocolo de árbol definiendo un árbol global entre los datos del sistema. [Chandy et al., 1983]

La prevención de deadlock puede dar lugar a esperas y retrocesos innecesarios. Además, puede que algunas técnicas de prevención exijan que se impliquen más nodos en la ejecución de las transacciones de lo normal. Si se permite que se produzcan deadlock y se confía en su detección, el problema principal en sistemas distribuidos radica en decidir la manera de conservar el grafo de espera. Las técnicas habituales exigen que cada localidad conserve un grafo de espera local, con todas las transacciones, locales y globales, que se ejecutan en ese nodo.

Si cualquier grafo local de espera tiene un ciclo, se habrá producido un interbloqueo. Por otro lado, el hecho que no haya ciclos en los grafos locales no significa que no hay deadlock. Existen esquemas para organizar los grados de espera locales a fin de determinar si el sistema distribuido tiene deadlock:

¾ Enfoque centralizado: se genera y conserva un único nodo de la red con un grafo global de espera, resultante de la unión de todos los grafos locales. Este nodo actúa como coordinador de detección de interbloqueo. Este grafo refleja una “aproximación” de los pedidos de datos en la BDD. Se habla de aproximación porque resulta muy costoso mantener actualizado en todo momento la información contenida en el grafo. Generalmente existen momentos en los cuales es conveniente construir el grafo: periódicamente, cuando haya tenido lugar cierto número de cambios en un grafo local, o siempre que el coordinador de detección de deadlock necesite invocar el algoritmo de detección de ciclos. En general, esta solución centralizada presenta los mismos inconvenientes que cualquier otra solución planteada bajo esta suposición en sistemas distribuidos.

¾ Enfoque completamente distribuido: en este caso todos los controladores comparten por igual la responsabilidad de detectar deadlock. En este esquema, cada nodo construye un grafo de espera que representa una parte del grafo total en función del comportamiento dinámico del sistema. La idea es que si existe un deadlock, aparecerá un ciclo en, como mínimo, uno de los grafos parciales. Se han desarrollado algoritmos que implica la construcción de grafos parciales en cada nodo [Silberschatz et al, 1998]

3. Integridad de