Control de concurrencia basado en componentes para una base de datos distribuida Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. CONTROL DE CONCURRENCIA BASADO EN COMPONENTES PARA UNA BASE DE DATOS DISTRIBUIDA. TESIS PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE:. MAESTRÍA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA POR:. MAXIMILIANO CANCHÉ EUÁN MONTERREY, NUEVO LEÓN; DICIEMBRE DE 2002.

(2) INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES PROGRAMAS DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES Los miembros del comité de tesis recomendamos que la presente tesis de Maximiliano Canché Euán sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en Tecnología Informática. Comité de tesis:. ______________________________ Juan Carlos Lavariega Jarquín, PhD. Asesor. ______________________________ Lorena Gómez Martínez, PhD. Sinodal. ______________________________ José Ignacio Icaza Acereto, PhD. Sinodal. _________________________________________ David Alejandro Garza Salazar, PhD. Director del Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Diciembre de 2002.

(3) CONTROL DE CONCURRENCIA BASADO EN COMPONENTES PARA UNA BASE DE DATOS DISTRIBUIDA. POR: MAXIMILIANO CANCHÉ EUÁN. TESIS. Presentada al Programa de Graduados en Electrónica, Computación, Información y Comunicaciones.. Este trabajo es requisito parcial para obtener el grado de Maestro en Ciencias en Tecnología Informática. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY DICIEMBRE DE 2002.

(4) Dedicatoria. A mi madre, por todo el apoyo y amor que me ha dado siempre.. - iv -.

(5) Agradecimientos. A ti padre, por la seguridad que creía haber perdido y me devolviste. A mi papá, mis hermanos, y abuelos por estar siempre conmigo. A mis primos por los ánimos que me dieron en el camino recorrido. A mis tíos, que como siempre me apoyaron en este nuevo proyecto. A Vicky por todo el tiempo que le dedique a la maestría y no te dediqué a ti. A todos mis amigos por todos los grandes momentos que pasamos juntos. A mi asesor, Dr. Juan Carlos Lavariega Jarquín, por toda su valiosa ayuda, paciencia, y conocimientos transmitidos en el desarrollo de este proyecto. A mis sinodales Dra. Lorena Gómez Martínez y Dr. José Icaza Acereto, por sus revisiones, acertados consejos y comentarios de gran valor en el desarrollo de este trabajo. A mi amigo Francisco Alvarez un agradecimiento especial, por su valioso apoyo en la elaboración de ese trabajo. A todas las personas que de una forma u otra intervinieron en esta etapa de mi vida. Gracias..... -v-.

(6) Resumen. Actualmente los sistemas basados en componentes prometen beneficios sustanciosos al tener la capacidad de dividir responsabilidades. Con este enfoque, en vez de desarrollar un sistema completo podemos adaptar uno existente a nuestras necesidades, adicionándole la funcionalidad requerida. De ese modo es posible modificar el comportamiento de un sistema agregando, quitando o intercambiando componentes. Algunos de los principales beneficios al desarrollar componentes como piezas independientes de un sistema son: la reducción de costos, reducción de esfuerzos de implementación, así como la promoción del reuso de sistemas de gran escala. Dado que actualmente no existe una arquitectura bien definida para Sistemas Manejadores de Base de Datos Distribuidos, las empresas comerciales aplican el concepto de la distribución de manera diferente. Una opción para obtener la funcionalidad de un Sistema Manejador de Base de Datos Distribuido es extender un Sistema Manejador de Base de Datos de manera fragmentada, es decir, adicionando ó reemplazando funcionalidad de una forma modular. En este trabajo, diseñamos y desarrollamos un componente de control de concurrencia para una Base de Datos Relacional con el fin de describir las ventajas al implantarlo como extensión de un Sistema Manejador de Base de Datos monolítico. El componente tiene la funcionalidad para sincronizar el acceso a los datos de una Base de Datos Distribuida. El desarrollo del componente debe envolver para fines prácticos la utilización de herramientas de dominio público y Sistemas Open Source, esto por el hecho de que dichos elementos proporcionan una relativa facilidad a mejoras posteriores por parte de sus usuarios. Específicamente este trabajo utiliza las herramientas de dominio publico: Java (como lenguaje de programación), MySQL (como Sistema Manejador de Base de Datos), y Linux (como sistema operativo Open Source).. - vi -.

(7) Contenido Dedicatoria............................................................................................................ iv Agradecimientos ................................................................................................... v Resumen ............................................................................................................... vi Lista de Figuras.................................................................................................... ix Capítulo 1. Introducción ....................................................................................... 1 1.1 Antecedentes................................................................................................. 1 1.2 Objetivo de la tesis. ....................................................................................... 2 1.3 Justificación ................................................................................................... 3 1.4 Organización de la tesis. ............................................................................... 3 Capítulo 2. Marco teórico ..................................................................................... 5 2.1 Sistemas Open Source.................................................................................. 5 2.2 DDB y DDBMS .............................................................................................. 5 2.3 Modelo de datos ............................................................................................ 6 2.4 Componentes de Software ............................................................................ 7 2.5 Extensiones en DBMS´s................................................................................ 7 2.6 Componentes como extensiones a un DBMS: CDBMS ................................ 9 2.6.1 Fundamentos de CDBMS: ComponentWare .......................................... 9 2.6.2 Descripción de un Modelo CDBMS: Componente-Arquitectura.............. 9 2.6.3 Una implementación de CDBMS: Object Relational DBMS (ORDBMS) 11 2.6.4 Implementación de extensiones con lenguajes de propósito general ... 11 2.7 Transacciones ............................................................................................. 12 2.7.1 Tipos de Transacciones ........................................................................ 13 2.8 Transacciones Distribuidas.......................................................................... 14 2.8.1 Agentes en aplicaciones Distribuidas.................................................... 14 2.9 Manejador de Transacciones Distribuidas (DTM)........................................ 16 2.9.1 El protocolo 2-phase-commit (2PC) ...................................................... 18 2.10 Descripción de una Arquitectura de DTM .................................................. 19 2.11 Control de Concurrencia Distribuido .......................................................... 21 Capítulo 3. Control de Concurrencia en transacciones en una DDB ............. 23 3.1 Antecedentes de Algoritmos de Control de Concurrencia ........................... 23 3.2 Clasificación de Algoritmos.......................................................................... 24 3.2.1 Algoritmos basados en bloqueo............................................................ 25 - vii -.

(8) 3.2.2 Algoritmos basados en ordenamiento por marcas de tiempo ............... 26 3.3 Bloqueo 2PL Centralizado ........................................................................... 27 3.3.1 Bloqueo de dos fases (2PL).................................................................. 28 3.3.2 Bloqueo de dos fases Centralizado (C2PL) .......................................... 30 3.4 Control de Concurrencia en el DBMS comercial DB2 ................................. 31 3.6 Control de Concurrencia en el DBMS Open Source MySQL....................... 32 3.6 Consideraciones sobre Control de Concurrencia en DBMS´s ..................... 33 Capitulo 4. El Componente LockManager......................................................... 35 4.1 Entorno Distribuido del Componente ........................................................... 35 4.2 Especificaciones funcionales del componente ............................................ 36 4.2.1 Objetivo del Componente LockManager ............................................... 36 4.2.2 Servicios proporcionados a un Manejador de Transacciones............... 36 4.3 Especificaciones del diseño......................................................................... 37 4.4 Detalle de los elementos de LockManager.................................................. 38 4.4.1 La clase LockManager .......................................................................... 38 4.4.2 La clase LockObject.............................................................................. 39 4.4.3 La clase abstracta Restriction ............................................................... 40 4.4.4 Extensiones de la clase Restriction....................................................... 42 4.4.5 Base de Datos DBLock ......................................................................... 43 4.5 Componentes adicionales considerados ..................................................... 45 4.6 Lógica de interacciones con el Componente ............................................... 45 4.7 Herramientas utilizadas en la implementación. ........................................... 47 Capítulo 5. Experiencias..................................................................................... 49 5.1 Ventajas....................................................................................................... 49 5.2 Desventajas................................................................................................ 50 5.3 Escenario de prueba ................................................................................... 51 Capítulo 6. Conclusiones y trabajo futuro ........................................................ 52 6.1 Conclusiones ............................................................................................... 52 6.2 Trabajo futuro .............................................................................................. 53 Anexo ................................................................................................................... 54 A. Clases del Componente genérico ................................................................. 54 B. Acceso a LockManager................................................................................. 67 Referencias.......................................................................................................... 69 Vita ....................................................................................................................... 71. - viii -.

(9) Lista de Figuras Figura 2.1 Una DDB dispersa en una red ............................................................... 6 Figura 2.2 Dos componentes plug-in agregando funcionalidad al DBMS ............. 10 Figura 2.3 Un DBMS Configurable........................................................................ 10 Figura 2.4 Aplicación TRANSFIERE_FONDOS.................................................... 15 Figura 2.5 Un modelo para el Manejo de Transacciones Distribuido .................... 17 Figura 2.6 Modelo detallado de DTM (Monitor de Ejecución Distribuido) ............. 20 Figura 2.7 Ejecución de Transacciones ................................................................ 21 Figura 3.1 Clasificación de algoritmos de Control de Concurrencia...................... 24 Figura 3.2 Proceso general de sistemas basados en bloqueo.............................. 28 Figura 3.3 Bloqueo de dos fases........................................................................... 29 Figura 3.4 Bloqueo de dos fases estricto .............................................................. 30 Figura 3.5 Comunicación en un C2PL .................................................................. 30 Figura 4.1 Arquitectura y entorno distribuido de componentes ............................. 35 Figura 4.2 Interacción de los elementos del Componente .................................... 38 Figura 4.3 La clase LockManager ......................................................................... 38 Figura 4.4 La clase LockObject............................................................................. 40 Figura 4.5 La clase abstracta Restriction .............................................................. 41 Figura 4.6 Jerarquía de clases Restriction............................................................ 43 Figura 4.7 Datos en tableLM ................................................................................. 44 Figura 4.8 Datos en tableLR ................................................................................. 44 Figura 4.9 Interfaz del agente local (servidor en cada sitio) .................................. 45 Figura 4.10 Transacciones compitiendo por LockManager................................... 46 Figura 4.11 Secuencia de ejecución de una Transacción..................................... 46 Figura 4.12 Secuencia del método RequestLock de LockManager ...................... 47 Figura 5.1 Aplicación de Transferencia entre Cuentas. ........................................ 51. - ix -.

(10) Capítulo 1. Introducción. En este capítulo se describen los antecedentes de este trabajo de tesis, así como el objetivo y justificación del porque se eligió el tópico. También se describe de una manera breve la organización de la tesis para su adecuado seguimiento. 1.1 Antecedentes Actualmente vivimos en un mundo que depende de la información; cada día surgen necesidades de aplicaciones que nos obligan a tener la capacidad de construirlas con menor tiempo de desarrollo y bajo costo. Los sistemas de información deben tener la capacidad de adaptarse a los cambios. Es deseable que las aplicaciones sean diseñadas con el enfoque de facilitar la extensión de su funcionalidad cuando sea necesario, sin peligro de ocasionar perjuicios a partes establecidas. Esto conlleva a dos requerimientos importantes en el diseño: independencia y adaptabilidad. Una manera de lograr las requerimientos mencionados es desarrollando aplicaciones a partir de elementos previamente elaborados, basados en una estructura de componentes. De este modo se puede disminuir el tiempo de construcción, dado que en vez de desarrollar un sistema completo podemos adaptar uno existente a nuestras necesidades, adicionándole la funcionalidad requerida. Con este enfoque es posible modificar el comportamiento de un sistema agregando, quitando o intercambiando componentes. Una de las tecnologías que nos ayuda en la construcción de aplicaciones basadas en componentes facilitando la adaptabilidad e independencia requerida son los Sistemas Open Source. Los Sistemas Open Source (de fuente abierta) [RSTA00] han introducido conceptos de innovación en los últimos años. Entre ellos se encuentra la posibilidad de integrar dispositivos de varias procedencias en un sistema, y se produce una rápida adopción de la nueva tecnología, gracias a la competencia existente, además que los costos de las tecnologías abiertas disminuyen rápidamente en comparación a los costos de las tecnologías propietarias. Por otra parte, la tecnología de Base de Datos Distribuida (DDB) [TOZS92] ha sido uno de los desarrollos más importantes desde la década pasada. Los temas de investigación de DDB han sido tópicos de intenso estudio, culminando en la liberación de Sistemas Manejadores de Bases de Datos Distribuidas (DDBMS) comerciales de “primera generación”.. -1-.

(11) El procesamiento de datos distribuidos es una necesidad que hoy en día muchas organizaciones tratan de satisfacer. En la DDB se realizan transacciones, las cuales deben ser coordinadas por Sistemas Manejadores de Base de Datos (DBMS), en particular por el administrador de transacciones, con el fin de mantener ciertas propiedades deseables para el funcionamiento correcto de su organización. El acceso concurrente en transacciones es una necesidad por la naturaleza misma de la información y de los múltiples usuarios que desean accederla al mismo tiempo. Cuando esto ocurre es necesario para el DDBMS garantizar la serialización en las transacciones, es decir el resultado debe ser el mismo que si estuvieran ejecutándose secuencialmente en un orden específico. El problema de Control de Concurrencia para transacciones en Bases de Datos Distribuidas ha recibido una especial atención desde hace algún tiempo. Este control requiere un algoritmo de sincronización distribuido que debe asegurar que las transacciones concurrentes no sean solo serializadas en cada sitio donde se están ejecutando, sino que también sean serializadas globalmente. Esto implica que el orden en que se ejecutan en cada sitio debe ser idéntico. En términos de las propiedades ACID, los Algoritmos de Control de Concurrencia mantienen las propiedades de consistencia y aislamiento de transacciones, de ahí la importancia del Control de Concurrencia como componente clave en las mismas [TOZS99]. Una característica deseable en las arquitecturas de los DBMS´s es definirlas en fragmentos (componentes) de tal manera que nuevos componentes puedan ser adicionados ó componentes existentes puedan ser intercambiados de una manera flexible. Con este enfoque es posible adaptar funciones distribuidas al comportamiento de un DBMS. Con este proyecto de tesis, enfocado a la implementación de un componente de control de concurrencia, se pretende tener un marco de referencia para proveer extensibilidad a un DBMS monolítico (que utilice el modelo relacional). Se analiza la alternativa que ofrece el concepto de la adaptación de dicho componente prefabricado al DBMS de tal modo que proporcione la funcionalidad necesaria para sincronizar el acceso a los elementos de una Base de Datos Distribuida y mantener la consistencia de éstos. 1.2 Objetivo de la tesis. El objetivo primordial de este trabajo es determinar las ventajas y funcionalidad de adaptar un mecanismo de control de concurrencia basado en componentes de software prefabricados, así como proveer un marco de referencia que proporcione extensibilidad a un DBMS monolítico para obtener la funcionalidad necesaria para sincronizar el acceso a los elementos de una Base de Datos Distribuida y mantener la consistencia de los mismos. Como meta adicional se estableció su entorno de operación sobre Sistemas Open Source. -2-.

(12) Para esto se diseño e implementó un mecanismo prototipo con el fin de mantener la consistencia de los datos y el aislamiento entre transacciones en una DDB, desempeñándose con soporte primario de Sistemas Open Source (construyéndolo y adaptándolo con herramientas de dominio publico), para orientar la evolución de las DDB en dichos sistemas. Otra de las características esenciales que el mecanismo cubre es la posibilidad de modificarlo (característica de código de dominio público), así como ser suficientemente independiente de otros componentes, como por ejemplo la distribución de datos. Fue necesario identificar esta independencia a lo largo del desarrollo de la tesis para llegar al objetivo cuidando las restricciones para un funcionamiento adecuado de la DDB. 1.3 Justificación La razón principal por la cuál se hizo el estudio de este tópico fue la necesidad de adicionar o intercambiar elementos de un DBMS monolítico para proporcionarle una funcionalidad necesaria a dicho DBMS, en particular a la sincronización del acceso a los elementos de una DDB, de tal modo que mantenga la consistencia de los datos. Entre los beneficios que se obtienen al implementar componentes de software con herramientas de dominio público se encuentran: la reducción de costos en aplicaciones, la reducción del tiempo de desarrollo por las características que representa el reuso de componentes, así como la posibilidad de mejorar o cambiar elementos para proveer funcionalidad adecuada a la aplicación. Otra razón por la que se investigó este tema fue al desconocimiento de las ventajas de un componente bajo las limitantes de un DBMS monolítico y los estándares de los Sistemas Open Source. Entre las ventajas obtenidas en este trabajo se encuentran: la facilidad de integración a distintos tipos de DBMS, simplicidad para adicionar componentes distribuidos, facilidad de migración a otra plataforma, independencia de la aplicación en desarrollo, y un código reutilizable y fácil de extender a otros tipos de datos. Con este trabajo se pretende aportar un marco de referencia al uso de componentes de software para proveer extensibilidad a aplicaciones con una arquitectura monolítica (ó centralizada) para su uso como elementos de una Base de Datos Distribuida. 1.4 Organización de la tesis. El resto de este documento de tesis está organizado de la siguiente forma: El capítulo dos presenta el marco teórico referente a los sistemas Open Source, base de datos distribuidas, componentes de software y su relación con los DBMS´s para extensibilidad, así como conceptos de transacciones y control de concurrencia en algunos DBMS´s de tipo comercial y Open Source. El capítulo tres comprende una descripción detallada sobre los enfoques de control de. -3-.

(13) concurrencia, así como su clasificación y referencia al mecanismo a implementar en esta tesis. El capítulo cuatro especifica el diseño del componente del mecanismo de control de concurrencia, se definen sus funciones e interacciones con el sistema. El capítulo cinco presenta las experiencias obtenidas en el trabajo, que incluyen ventajas y desventajas del uso de componentes en DBMS´s. El capítulo seis presenta conclusiones obtenidas en el trabajo de investigación en base a las experiencias obtenidas, así como un trabajo futuro de investigación. Al final se incluyen dos anexos que contienen el código en Java de las clases principales que implementan el prototipo elaborado y pruebas de acceso al componente.. -4-.

(14) Capítulo 2. Marco teórico. En este capítulo se presenta el marco teórico referente a Sistemas Open Source, componentes de software y su relación con los DBMS´s para proveerle extensibilidad, así como conceptos básicos de transacciones distribuidas y control de concurrencia en algunos DBMS´s de tipo comercial y Open Source. Esto con el fin de tener un mejor entendimiento de los conceptos involucrados en la elaboración del componente. 2.1 Sistemas Open Source Los Sistemas “Open-Source,” son productos de software desarrollados por una comunidad de profesionales en el área de tecnologías de información cuyo propósito es proporcionar una alternativa al software comercial. De acuerdo a [RSTA00] se menciona lo siguiente sobre el término Open Source: “Open Source se refiere a que el uso del sistema no requiere el pago de algún tipo de licencia a una empresa desarrolladora de software, y que viene acompañado del código fuente para futuras mejoras o implementaciones por parte del usuario que lo utiliza”. El software libre proporciona a los usuarios la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software para adaptarlo a sus necesidades. Una de las características de la licencia de este tipo de software es la inclusión del código fuente, lo cual le permite a un usuario experimentado, como se mencionó anteriormente, realizar las adaptaciones que él considere necesarias. Esto conlleva a ventajas que reporta el uso del software libre, siendo una de las más significativas el hecho de que los productos sean susceptibles a mejoras posteriores por parte de sus usuarios. Las características de los Sistemas Open Source se deberán percibir en el componente de software creado en este trabajo. 2.2 DDB y DDBMS La necesidad de integrar y compartir información, dio origen al nacimiento de una nueva tecnología capaz de conformar de manera consistente la información de las organizaciones. Esta tecnología que trabaja en dicho problema es la de Bases de Datos Distribuidas (DDB). Una DDB [TOZS99] es una colección de múltiples Bases de Datos interrelacionadas lógicamente, distribuidas sobre una red de computadoras (donde cada sitio en la red tiene capacidad de procesamiento autónomo y puede ejecutar aplicaciones locales), mientras que un DDBMS [DBEL92] es el sistema de software que permite la administración de la DDB y hace la distribución transparente a los usuarios. El esquema de una DDB se muestra en la figura 2.1.. -5-.

(15) Figura 2.1 Una DDB dispersa en una red. [GALV99]. Debido a la naturaleza dispersa de la información, razones económicas, interconexión de Bases de Datos existentes, consideraciones de desempeño, confiabilidad, rendimiento y disponibilidad, se ha observado una tendencia hacia la distribución de sistemas de cómputo en diversos sitios interconectados a través de una red de comunicaciones. Dicha distribución produce un aumento en la complejidad de diseño e implementación de nuevos sistemas. 2.3 Modelo de datos Existen tres modelos de DB que han sido usados tradicionalmente: el jerárquico, el de redes y el relacional. Con el tiempo han surgido otros modelos, como el orientado a objetos y el objeto-relacional. Un DBMS soporta un solo modelo de datos y, dado que este afecta las características del esquema global conceptual (que representa una DB virtual cuyos datos se encuentran almacenados en distintas DB´s) es necesario señalar el utilizado. En esta investigación, se trabaja con el modelo de datos relacional dada la simplicidad y el conocimiento que se tiene sobre él. El modelo de datos relacional [TOZS99] representa los datos a manera de tablas bidimensionales, compuestas de renglones y columnas. Cada una de estas tablas recibe el nombre de relación y la colección de las mismas conforma una base de datos relacional.. -6-.

(16) 2.4 Componentes de Software Por componente de software se puede entender cualquier objeto de software con existencia independiente. Puede ser un procedimiento, un objeto ó una aplicación completa. Un componente puede ser una clase o un conjunto de clases interrelacionadas, y su propósito es servir como bloque de construcción de una aplicación. Una característica deseable de un componente es que tenga una interfaz o un punto lógico de conexión entre el mismo y el sistema. Una interfaz debe ocultar los detalles de implementación del componente, pero debe proveer información necesaria sobre sus características al sistema. De esta manera un componente puede representar un elemento visual en una interfaz de usuario como son una entidad en algún dominio, o un manejador de base de datos [AMOL00]. En [DITT00] se menciona que los componentes son cajas negras, lo cual significa que los usuarios pueden usar sus propiedades sin conocer su implementación (propiedad de encapsulación). La interfaz de un componente y su implementación deben ser separados de tal modo que puedan existir múltiples implementaciones para una interfaz y las implementaciones puedan ser intercambiadas. De acuerdo con [DSOU99] un componente de software se define como sigue: x Es un paquete coherente de una implementación de software que puede ser desarrollado independientemente de otras aplicaciones (independencia). x Tiene interfaces explícitas y bien especificadas para informar los servicios que provee e interactuar con otros componentes (interoperabilidad). x Puede estar constituido por otros componentes mediante la especialización de sus propiedades (función específica), sin que esto signifique modificar los componentes mismos. Es importante la manera en que se definen los componentes con el fin de proporcionar el reuso de los mismos. Para que estos puedan ser reutilizados, deben de proveer una función específica, así como tener una interfaz mediante el cual se acceda su funcionalidad, pero que a la vez oculte los detalles de su implementación [AMOL00]. 2.5 Extensiones en DBMS´s Un problema general en escenarios de Base de Datos es la estructura monolítica del DBMS tradicional. La estructura monolítica o arquitectura. -7-.

(17) monolítica, se refiere a que el DBMS es una unidad simple cuyas partes son conectadas a otra y es dependiente de otra a tal grado que las modificaciones y extensiones no son posibles llevarlas a cabo fácilmente. Los DBMS monolíticos en ocasiones deben cumplir nuevos requerimientos. Aparentemente tienen que ser extendidos para incluir nueva funcionalidad. Sin embargo, mejorar un sistema simple con módulos, implementando todas las funciones nuevas no es un enfoque viable por algunas razones: x Los DBMS podrían llegar a ser más grandes y, en consecuencia, más complejos que no podrían ser mantenidos a un costo razonable. x Los usuarios tendrían que pagar un alto precio para adicionar funcionalidad, aun si ellos no necesitan cada parte de esto. x Un proveedor de DBMS podría no tener la experiencia para realizar tales extensiones y podrían no tener los recursos para comprometer todas las extensiones en un periodo razonable. Una opción para esto es considerar la alternativa de extender el DBMS de manera fragmentada, es decir, adicionando funcionalidad (o reemplazando) de una forma modular, como sea necesario. Dado que las extensiones modulares a un DBMS afectan su arquitectura, requieren que ciertos pre-requisitos sean cumplidos, en otras palabras se requiere que una arquitectura de software bien definida sea impuesta al DBMS. Esta arquitectura debe definir claramente los lugares en el sistema donde las extensiones sean posibles. En general, las extensiones deberían ser colocadas en algunos lugares bien definidos en el sistema, y los efectos y modificaciones sobre otras partes deberían ser evitadas o al menos minimizadas. Una característica deseable en las arquitecturas de los DBMS´s es definirlas en fragmentos (componentes) de tal manera que nuevos componentes puedan ser adicionados o componentes existentes puedan ser intercambiados de una manera flexible. De este modo la arquitectura del DBMS especificaría y restringiría la forma en que un elemento puede ser configurado para una función específica. A fin de cuentas, la arquitectura también define la noción de componente, así como el dominio de extensiones válidas a un DBMS [DITT00]. Esta necesidad de una arquitectura de DBMS fragmentada tiene sus orígenes en el concepto de DBMS´s extensibles [FAND99], los cuales han sido desarrollados e implementados en prototipos de investigación, y posteriormente estuvieron comercialmente disponibles.. -8-.

(18) 2.6 Componentes como extensiones a un DBMS: CDBMS Con la incorporación del concepto de arquitectura de componentes en DBMS, es posible implantar las extensiones sin requerir que otras partes del sistema sean sobrescritas. Los componentes pueden ser suministradas por terceros y posiblemente por usuarios, incrementando la base desarrolladora de un DBMS. De ahí surge el concepto de DBMS´s Componentes ó CDBMS´s [DITT00]. Aunque existen diferentes formas de CDBMS’s, su base común es una arquitectura de componentes y la implementación de componentes con alguna clase de función de DB como soporte. Estos componentes pueden ser adicionados a un DBMS ó usados de alguna manera para obtener el soporte a la DB. Por otra parte, una arquitectura de CDBMS también define lugares en el sistema (la parte variable) donde los componentes pueden ser adicionados. 2.6.1 Fundamentos de CDBMS: ComponentWare La arquitectura CDBMS toma la noción de ComponentWare [DITT00]. Esto es un paradigma propuesto recientemente para direccionar las cuestiones de reusabilidad (reusability), extensibilidad (extensibility), apertura (openness), e interoperabilidad (interoperability) de Sistemas de Base de Datos. Esta es la noción que los sistemas de software son elaborados de una manera disciplinada para construir bloques con propiedades específicas, llamados componentes. También se considera que un componente no debería tener un alto número de relaciones a otros componentes, pues esto podría restringir su potencial reuso. Los principios de ComponentWare se utilizan para entender mejor, abstraer, y clasificar los distintos enfoques para extender y personalizar DBMS´s. Además las características de ComponentWare son requerimientos cruciales para extensibilidad sistemática y bien definida, así como para integración. Por consiguiente las extensiones a un DBMS en este contexto son representadas como componentes, esto significa que deben cumplir las propiedades antes mencionadas de los componentes. 2.6.2 Descripción de un Modelo CDBMS: Componente-Arquitectura En esta sección se presenta un modelo de CDBMS discutida en [DITT00]. Bajo este enfoque se consideran dos dimensiones: x la dimensión Componente, que representa la funcionalidad de Base de Datos o tarea del DBMS, y x la dimensión Arquitectura, que representa la arquitectura genérica del DBMS que permite la adición de componentes.. -9-.

(19) Para el propósito de este trabajo se describen las características del componente y la arquitectura que se pretenden utilizar: Componente Plug-in y Arquitectura de DBMS configurable. Componentes Plug-in. Este tipo de componentes permite “conectar” al DBMS características no estándar ó funcionalidades que aún no son soportadas. De este modo, un sistema puede ser funcionalmente completo y cumplir requerimientos básicos, mientras las extensiones adicionan más funcionalidad para necesidades específicas. Los componentes de esta clase de CDBMS son típicamente familias de tipos de datos abstractos o implementaciones de alguna función de DBMS tales como nuevas estructuras de índices. La figura 2.2 muestra el concepto de plug-in en DBMS.. Figura 2.2 Dos componentes plug-in agregando funcionalidad al DBMS [DITT00] Arquitectura de DBMS Configurable. Una arquitectura de DBMS con este enfoque permite desarrollar e integrar nuevas partes al mismo. A estas partes se les pueden considerar tareas desligadas del DBMS que pueden ser mezcladas y unidas posteriormente para dar soporte a la base de datos. Estos elementos son en realidad, subsistemas. Bajo este concepto, al desarrollar componentes selectos para un DBMS, se implementa la funcionalidad deseada y se obtiene un DBMS por configurar y ensamblar los componentes seleccionados. El DBMS es de ese modo, un DBMS completo. Este enfoque se muestra en la figura 2.3.. Figura 2.3 Un DBMS Configurable [DITT00]. - 10 -.

(20) 2.6.3 Una implementación de CDBMS: Object Relational DBMS (ORDBMS) Un DBMS Componente (CDBMS) define un framework de sistemas de software para que los desarrolladores de aplicaciones puedan extender el DBMS al insertar módulos de programación lógica en éste. Estas extensiones implementan elementos de una Base de Datos tales como nuevos tipos de datos, algoritmos específicos, y facilidades externas de acceso a datos. Un DBMS Objeto-Relacional (ORDBMS) es una clase de CDBMS [DITT00]. El principal objetivo del diseño ORDBMS fue reunir los beneficios de los modelos relacional y de objetos tales como escalabilidad para soportar extensiones de tipos de datos. Toda la información de la DB es almacenada en tablas, pero algunas de las entradas pueder tener estructuras de datos complejas, denomidadas tipos de datos abstractos (abstract data types ó ADT´s) [RDEV01]. Un ORDBMS puede soportar mecanismos de extensibilidad de componentes. Los usuarios finales enviando una query al sistema no tienen idea de cómo está implementada la extensión lógica que ellos invocan. Lo que distingue un ORDBMS de otros frameworks componentes - tales como DBMS orientados a objetos, Middleware, y servidores de aplicaciones de propósito general -, es la manera en que, una vez integrados dentro del ORDBMS, los componentes son organizados y manipulados usando un lenguaje de Base de Datos declarativo, en vez de un lenguaje de programación procedural [DITT00]. Actualmente, los proveedores de software líderes – tales como Oracle, Informix, Microsoft, IBM y Sybase – han extendido sus sistemas para llegar a ser ORDBMS, aunque la funcionalidad dada por cada uno es ligeramente diferente. El concepto de ORDBMS, como un híbrido de RDBMS y OODBMS (DBMS Orientado a Objetos), es muy atractivo, preservando la riqueza del conocimiento y experiencia que ha sido adquirido con el RDBMS [RDEV01]. 2.6.4 Implementación de extensiones con lenguajes de propósito general Un enfoque para escribir extensiones a CDBMS es utilizar lenguajes de programación compilados de propósito general tal como C o C++. Estos lenguajes generan código objeto o ensamblador, lo que hace que sean ejecutadas instrucciones a bajo nivel en el hardware. Los lenguajes compilados proveen la ejecución más rápida posible, y se puede hacer uso, con lenguajes como C ó C++, de las funciones incluidas con sus librerías de lenguaje estándar. Sin embargo, los lenguajes compilados tienen algunos inconvenientes, por ejemplo las librerías compiladas son portables solo si se asumen hardware y entorno de sistema. - 11 -.

(21) operativo homogéneos. Los lenguajes semicompilados como Java, tienen todas las ventajas de lenguajes de programación de propósito general sin algunos de los inconvenientes que padecen por la inmovilidad de código compilado. Java es compilado en un formato portable. Es de mucha importancia que el entorno de ejecución de Java ha sido diseñado para trabajar en una amplia variedad de sistemas. De hecho el motor de ejecución o maquina virtual puede ser enlazado al entorno de un CDBMS correctamente implementado tal como cualquier otra librería compilada [DITT00]. 2.7 Transacciones Una transacción [JGRA93] es una serie de operaciones realizada en una DB mediante la cual un estado consistente de la DB se transforma en otro estado consistente. Es una aplicación o parte de una aplicación (a veces llamada unidad lógica de trabajo). Los Sistemas Manejadores de Base de Datos (DBMS) deben proveer soporte para que se cumplan las propiedades ACID (Atomicidad, Consistencia, aIslabilidad, y Durabilidad) de transacciones [SCER85]: x Atomicidad: Una transacción es una unidad atómica de ejecución, es decir o se ejecutan todas las acciones o ninguna. Los posibles estados de una transacción al estarse ejecutando son: commit (terminación) o abort (abortar). x Consistencia: Una transacción es consistente cuando transforma un estado consistente de la Base de Datos a otro estado consistente de la Base de Datos (por ejemplo no faltan ni sobran datos). x Aislabilidad: Una transacción es aislada de otras porque oculta sus modificaciones hasta que se complete y no accede a las modificaciones que otras transacciones están haciendo concurrentemente a la Base de Datos. x Durabilidad: Una transacción es durable porque en terminaciones exitosas, los resultados sobrevivirán en cualquier falla subsiguiente del sistema. Si varias transacciones están ejecutándose concurrentemente sobre una Base de Datos Distribuida, el resultado debe ser el mismo que si estuvieran ejecutándose secuencialmente en un orden. La actividad de garantizar la serialización (o secuencialidad) en transacciones es llamada Control de Concurrencia [TOZS92]. Si un sistema provee control de concurrencia, el programador puede escribir la transacción como si solo ésta estuviera ejecutándose. Normalmente, después de su invocación por el usuario, la aplicación inicia una primitiva begin-transaction; a partir de este momento, todas las acciones que serán ejecutadas por la aplicación, hasta que una primitiva commit ó abort se lleve a cabo, serán consideradas parte de una misma transacción. En algunos sistemas, el inicio de una transacción está implícitamente asociado con el inicio de. - 12 -.

(22) la aplicación, y la primitiva commit finaliza una transacción y automáticamente inicia otra nueva si es necesario, así que la primitiva begin-transaction no es necesaria. 2.7.1 Tipos de Transacciones Existen varios modelos de transacciones propuestos de acuerdo a distintos criterios. De acuerdo a [TOZS92] los criterios más comunes son: por su duración, por la organización de acciones de lectura y escritura, y de acuerdo a su estructura. Las transacciones que abarca el criterio de duración son: x Transacciones short-life, caracterizadas por su corta ejecución/tiempo de respuesta, y por acceder a una porción relativamente pequeña de la base de datos. Esta clase de transacciones probablemente cubre una gran porción de transacciones de aplicaciones actuales. x Transacciones long-live, que toman largo tiempo de ejecución /tiempo de respuesta, y acceso a una gran porción de la base de datos. Con respecto a la organización de acciones de lectura y escritura las transacciones se pueden clasificar en: x Transacciones generales (general), que mezclan sus acciones de lectura y escritura sin algún orden específico. x Transacciones de dos pasos (two-step), si son restringidas a que todas las acciones de lectura son ejecutadas antes de cualquier acción. x Transacciones restringidas (restricted o read-before-write), si son restringidas a que un dato tiene que ser leído antes de que sea actualizado. x Transacciones restringida de dos pasos (restricted two-step), si es una transacción restringida y de dos pasos. x Transacciones de acción (action), que son transacciones restringidas con la restricción adicional que cada par <read, write> sea ejecutado atómicamente. Las transacciones también pueden ser clasificadas de acuerdo a su estructura. Aquí se distinguen cuatro grandes categorías en complejidad incremental: x Transacciones planas (flat), que tienen un punto de inicio simple (Begin_transaction) y un punto de terminación simple (End_transaction). x Transacciones anidadas (nested), que permiten a una transacción incluir otras subtransacciones con sus propios puntos de begin y commit. El nivel. - 13 -.

(23) de anidación es generalmente abierto, permitiendo a las subtransacciones mismas tener subtransacciones anidadas. x Transacciones workflow, que son modeladas como actividades que consisten de un conjunto de tareas con relaciones de precedencia bien definidas entre ellas. 2.8 Transacciones Distribuidas Las aplicaciones distribuidas ejecutan transacciones en sitios a los cuales ellas acceden la base de datos local. Para realizar funciones en distintos sitios, una aplicación distribuida tiene que ejecutar varios procesos en estos sitios. En [SCER85] se les denomina agentes de la aplicación a dichos procesos. Un agente es además un proceso local que realiza algunas acciones en representación de una aplicación. Se debe notar que en esta definición de agente no interesa saber si el agente ejecuta un programa escrito por el programador de aplicaciones o una función primitiva del sistema. 2.8.1 Agentes en aplicaciones Distribuidas Para cooperar en la ejecución de la operación global requerida por la aplicación, los agentes tienen que comunicarse. Como ellos están residentes en diferentes sitios, la comunicación entre agentes es realizada a través de mensajes [SCER85]. Existen diferentes maneras en la cual los agentes pueden ser organizados para construir una estructura de procesos cooperativos. Para la cuestión de la atomicidad, se puede asumir que: 1. Existe un agente root (root agent) que inicia toda la transacción, así que cuando el usuario solicita la ejecución de una aplicación, el agente root es iniciado; el sitio del agente root es llamado el sitio de origen de la transacción. 2. El agente root tiene la responsabilidad de emitir las primitivas begintransaction, commit y abort. 3. Solamente el agente root puede solicitar la creación de un nuevo agente. Un ejemplo de aplicación distribuida se ilustra en la figura 2.4. Ejemplo 2.1. Consideremos un ejemplo de transacción distribuida. La figura 2.4a muestra una transacción que fue escrita por un programador a un nivel global. La transacción realiza una “transferencia de fondos” entre dos cuentas. Esto se lleva a cabo sobre una relación global CUENTA(No_cuenta, Monto). La aplicación inicia leyendo de la terminal el monto que tiene que ser transferido ($Monto) y los números de cuenta donde el monto es tomado y donde es transferido ($De_cuenta y $A_cuenta respectivamente). Entonces la aplicación emite una primitiva begin-transaction, y a partir de este momento, las propiedades. - 14 -.

(24) de transacciones deben ser preservadas por el sistema. El código de la transacción es directo: si el monto de De_cuenta es menor que el monto a transferir, la transacción aborta; en otro caso los dos montos son actualizados, y la transacción emite un commit. Si ahora se asume que las cuentas son distribuidas en distintos sitios de una red, la transacción puede ser ejecutada por varios agentes cooperando. Por ejemplo en la figura 2.4b se muestran dos agentes. Uno de ellos es el agente root. Aquí se asume que la cuenta “De_cuenta” está ubicada en el sitio del agente root y que “A_cuenta” está ubicada en un sitio diferente , donde el agente AGENT1 es ejecutado. Cuando el agente root necesita la ejecución de AGENT1, éste emite la primitiva Create AGENT1; entonces root envía los parámetros necesarios a AGENT1. ̝ El agente root también puede emitir las primitivas begin-transaction, commit, y abort [SCER85]. Estas primitivas no solamente tienen validez local en el sitio del agente root, dado que si un agente falla (AGENT1 en el ejemplo), la transacción como un todo no tiene efecto (propiedad de atomicidad). También se asume que la primitiva end-transaction está implícitamente asociada a las primitivas commit y abort. TRANSFIERE_FONDOS: Read(terminal, $Monto, $De_cuenta, $A_cuenta); Begin-transaction; Select Monto into $De_monto From CUENTA Where No_cuenta=$De_cuenta; If $De_monto - $Monto < 0 then abort Else begin Update CUENTA Set Monto = Monto - $Monto Where No_cuenta = $De_cuenta; Update CUENTA Set Monto = Monto + $Monto Where No_cuenta = $A_cuenta; Commit end. (a) ) Transacción TRANSFIERE FONDOS a nivel global. ROOT-AGENT: Read(terminal, $Monto, $De_cuenta, $A_cuenta); Begin-transaction; Select Monto into $De_monto From CUENTA Where No_cuenta=$De_cuenta; If $De_monto - $Monto < 0 then abort Else begin Update CUENTA Set Monto = Monto - $Monto Where No_cuenta = $De_cuenta; Create AGENT1; Send to AGENT1($Monto,$A_cuenta) Commit End AGENT1: Receive from ROOT_AGENT($Monto,$A_cuenta); Update CUENTA Set Monto = Monto + $Monto Where No_cuenta = $A_cuenta; (b) Transacción TRANSFIERE FONDOS con 2 agentes. Figura 2.4 Aplicación TRANSFIERE_FONDOS [SCER85]. - 15 -.

(25) 2.9 Manejador de Transacciones Distribuidas (DTM) Es importante definir el papel que juega el Manejador de Transacciones Distribuidas (DTM) en un DDBMS. Este se enfoca en tres problemas principales [SCER85]: x Confiabilidad x Control de Concurrencia x Utilización eficiente de los recursos Dado que este trabajo se desarrollará bajo el problema de control de concurrencia solamente abarcará situaciones relacionadas a este tópico en caso de ser necesario, destacando la dependencia o influencia de las mismas. Para construir un DTM que implemente las primitivas globales, begintransaction, commit, y abort, para transacciones distribuidas, es conveniente asumir que se tiene en cada sitio un Manejador de Transacciones Locales (LTM) el cual es capaz de implementar transacciones locales. De esta manera se aprovechan las técnicas existentes de transacciones no distribuidas. Se asume también que cada agente puede emitir las primitivas locales (begin-transaction, commit y abort) a su LTM. Se puede llamar subtransacción al agente después que emita una primitiva begin-transaction a su LTM para reflejar que no es una transacción autónoma. De este modo, el LTM debe tener las siguientes capacidades: x Asegurar la atomicidad de una subtransacción. x Escribir unos registros de almacenamiento estable en representación del DTM. Para asegurarse de que todas ó ninguna de las acciones de una transacción distribuida son realizadas, son necesarias dos condiciones: x En cada sitio todas las acciones son realizadas ó ninguna. x Todos los sitios deben tomar la misma decisión con respecto a la terminación (commit) o aborto (abort) de subtransacciones y deben ser realmente capaces de realizar esto. Las relaciones entre Manejo de Transacciones Distribuidas y Manejo de Transacciones Locales [SCER85] se representa en el modelo de referencia de un DTM mostrado en la figura 2.5. En el nivel inferior se tienen LTM’s, los cuales no necesitan comunicación entre ellos. Los LTM´s implementan interfaces (1): local_begin, local_commit, y local_abort. Una primitiva adicional, local_create, es parte de la interfaz (1), porque la creación de un proceso (agente) es una función de los sistemas locales.. - 16 -.

(26) ROOT AGENT. AGENT. AGENT. Distributed Transaction. DTMAGENT. DTMAGENT. Distribuited Transaction Manager (DTM). 2. DTMAGENT. 1. 1. LTM en Sitio i. 1. LTM en Sitio k. LTM en Sitio j. Local Transaction Managers (LTM). Interfaz 1: Local_Begin, Local_Commit, Local_Abort, Local_Create Interfaz 2: Begin_Transaccion, Commit, Abort, Create. Figura 2.5 Un modelo para el Manejo de Transacciones Distribuido [SCER85] En el siguiente nivel se tiene el DTM. EL DTM es por su naturaleza una capa distribuida; el DTM podrá ser manipulado por un conjunto de agentes-DTM locales los cuales intercambian mensajes entre ellos. El DTM como un todo implementa la interfaz (2): begin_transaction, commit, abort, y create (remoto). La creación de un nuevo agente debe ser emitida al DTM, porque el DTM debe tener una noción de que agentes constituyen una transacción distribuida. En el nivel más alto se tiene la transacción distribuida, constituida por el agente root y los otros agentes. Dado que se asume que solo el agente root puede emitir las primitivas begin_transaction, commit, y abort, la interfaz (2) es usada solo por el agente root. Se hace mención que este modelo de referencia es un modelo conceptual para entender como trabajan los algoritmos y a que nivel empieza su operación, y no es necesariamente una estructura de implementación. La manera en que el DTM implementa las primitivas de la interfaz (2) es la siguiente: x Begin_transaction. Cuando es emitido por el agente root, el DTM emitirá un local_begin al LTM del sitio de origen y a todos los sitios donde hay agentes activos de la misma aplicación, transformando todos los agentes en subtransacciones. x Abort. Cuando un abort es emitido por el agente root, todas las subtransacciones deben ser abortadas. Esto es realizado enviando. - 17 -.

(27) local_aborts a los LTM´s en todos los sitios donde hay una subtransacción activa. x Commit. Su implementación es la más difícil y costosa. Lo difícil reside en el hecho que un commit correcto en una Transacción Distribuida requiere que todas sus subtransacciones hagan commit localmente aun en el caso de fallos. En consecuencia no es aceptable que una subtransacción aborte localmente debido a una falla y las otras subtransacciones hagan commit. Para implementar esta primitiva para una Transacción Distribuida, se ha desarrollado el protocolo 2-phase-commitment (2PC). 2.9.1 El protocolo 2-phase-commit (2PC) [SCER85] considera en el protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol especial. Este es llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados participantes. El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente. Cada participante corresponde a una subtransacción la cual ha realizado alguna acción de escritura en su base de datos local. Se puede asumir que cada participante está en un sitio diferente. Aun si un participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo como si estuvieran en distintos sitios. La idea básica del 2PC es determinar una decisión única para todos los participantes con respecto a hacer commit o abort en todas las subtransacciones locales. El protocolo consiste en dos fases. La primera fase tiene como objetivo alcanzar una decisión común; la meta de la segunda fase es implementar esta decisión. El protocolo procede como sigue: Fase uno: x El coordinador escribe “prepare” en la bitácora y envía un mensaje donde pregunta a todos los participantes si preparan el commit (PREPARE). x Cada participante escribe “ready” (y registra las subtransacciones) en su propia bitácora si está listo o “abort” de lo contrario. x Cada participante responde con un mensaje READY o ABORT al coordinador. x El coordinador decide el commit o abort en la transacción como un resultado de las respuestas que ha recibido de los participantes. Si todos respondieron READY, decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en un intervalo de tiempo determinado se aborta la transacción.. - 18 -.

(28) Fase dos: x El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe “global_commit” o “global_abort” en la bitácora. x El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución. x Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de asegurar que el efecto de la subtransacción no será perdido). x Finalmente, todos los participantes envían un mensaje de acuse de recibo (ACK) al coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la subtransacción. x Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”. 2.10 Descripción de una Arquitectura de DTM En [TOZS99] se considera una arquitectura de DTM. Aquí se describe que el Manejador de Transacciones Distribuidas (ó Monitor de Ejecución Distribuido) consiste de dos módulos concretos: x Un Manejador de Transacciones (TM), que es responsable de coordinar la ejecución de las operaciones de la DB en representación de una aplicación, x Un Planificador ó Scheduler (SC), que es responsable de la ejecución de un algoritmo de control de concurrencia especifico para el acceso sincronizado a la DB. Un tercer componente que participa en el manejo de transacciones distribuidas es el Manejador de Recuperación (RM) local que existe en cada sitio. Su función es implementar los procedimientos locales con los cuales la DB puede ser recuperada a un estado consistente después de una falla. Cuando una transacción se origina en algún sitio (llamado sitio de origen), la ejecución de las operaciones de la DB de una transacción es coordinada por el TM en el sitio mencionado. Los Manejadores de Transacciones implementan una interfaz para los programas de aplicación que consisten en cinco comandos: begin_transaction, read, write, commit, y abort. x Begin_transaction. Este es para el TM un indicador de que una nueva transacción está iniciando. El TM lleva la contabilidad, tal como guardar el nombre de transacción, la aplicación que la origina, etc.. - 19 -.

(29) x Read. Si un elemento x es almacenado localmente, su valor es leído y devuelto a la transacción. En otro caso, el TM selecciona una copia de x y solicita que sea devuelta. x Write. El TM coordina la actualización del valor de x en cada sitio donde este reside. x Commit. El TM coordina la actualización física de todas las DB´s que contienen copias de cada dato para el cual una escritura previa fue hecha. x Abort. El TM asegura que ningún efecto de la transacción se refleje en la DB. Al proveer estos servicios, un TM puede comunicarse con los SC´s de los distintos sitios con los que tiene relación. De ahí el nombre de Monitor de ejecución distribuido, pues coordina no solo la sincronización de los datos locales, sino también recibe y envía información que ayuda a sincronizar el acceso en otros sitios. La figura 2.6 muestra el esquema descrito.. Figura 2.6 Modelo detallado de DTM (Monitor de Ejecución Distribuido) [TOZS99] En la figura 2.7 se muestra la diferencia y uso del Manejo de transacciones de un TM en un esquema centralizado, que solamente interactúa con su SC local, y un esquema distribuido, que permite la interacción con otros SC en distintos sitios. En la parte (a) se ilustra la ejecución de transacciones en un ambiente centralizado. El TM solamente interactúa con su SC para sincronizar el acceso concurrente a datos y comunicarse por medio de éste con el RM. En la parte (b) el TM se comunica no solamente con su SC, sino puede sincronizar el acceso a otros sitios por medio de los SC de los mismos [TOZS99].. - 20 -.

(30) (a) Ejecución de una transacción Centralizada. (b) Ejecución de una transacción Distribuida. Figura 2.7 Ejecución de Transacciones [TOZS99] 2.11 Control de Concurrencia Distribuido Cuando dos o más transacciones se ejecutan concurrentemente, sus operaciones se realizan en forma entrelazada. Esto es, operaciones de un programa podrían ejecutarse entre dos operaciones de otro programa. Este entrelazamiento puede provocar que los programas funcionen incorrectamente, o se interfieran, obteniendo como resultado una DB inconsistente. Este problema puede ocurrir incluso si cada programa está codificado correctamente y ningún componente tiene alguna falla. El objetivo de tener control de concurrencia en una DDB [TOZS99] es proveer las propiedades de consistencia (simplemente su precisión, es decir mantener el estado consistente de una base de datos cuando finalice la transacción) y aislamiento (cada transacción ve una DB consistente todas las veces) en las transacciones, esto es, evitar que ocurra interferencia para evitar errores. El mecanismo de control de concurrencia distribuido asegura, como se ha mencionado, la consistencia de la DDB cuando la transacción termine (debe notarse que le DB puede ser temporalmente inconsistente durante la ejecución de una transacción), y es además uno de los componentes fundamentales de un DDBMS. Cuando se tiene acceso concurrente a los datos se presenta comúnmente problemas tales como:. - 21 -.

(31) x Actualizaciones perdidas, cuando los efectos de alguna transacción no son reflejados en la base de datos. x Análisis inconsistente, cuando por ejemplo, una transacción lee una vez un dato y siempre está leyendo lo mismo debido a que otra transacción la modifica. Estos problemas, tienen origen en situaciones, llamadas fenómenos, que pueden ocurrir si la propiedad de aislamiento no es mantenida. Tres fenómenos comunes son los siguientes: x Lectura sucia: Una transacción lee valores que otra transacción ha modificado sin hacer commit. x Lectura no repetible: Una transacción intenta leer valores que antes había leído y que otra transacción ha cambiado o borrado obteniendo así, en dos lecturas, diferentes resultados. x Condición fantasma: Cuando una transacción hace una búsqueda y otra transacción inserta nuevas tuplas que satisfagan el predicado. Para resolver los problemas asociados a múltiples clientes solicitando los mismos datos, las transacciones deben estar aisladas unas de otras por bloqueos. Esto se resuelve con un mecanismo eficiente que aísle dichas transacciones. En el siguiente capítulo se presentan distintas clasificaciones y enfoques de mecanismos utilizados para el control de concurrencia en una DDB, esto con el fin de describir los requisitos del componente propuesto en este trabajo.. - 22 -.

(32) Capítulo 3. Control de Concurrencia en transacciones en una DDB. En este capítulo se detallan las técnicas básicas de control de concurrencia, así como su adaptación a un entorno distribuido. También se incluye la descripción de los métodos específicos de control de concurrencia utilizados en un DBMS de tipo comercial y en uno Open Source. Finalmente se mencionan algunas consideraciones importantes referentes al mecanismo elaborado en esta tesis.. 3.1 Antecedentes de Algoritmos de Control de Concurrencia Existen más de veinte mecanismos que han sido propuestos para DDBMS y varios han sido o están siendo implementados. Un mecanismo puede constar de uno o más algoritmos. Estos algoritmos son usualmente complejos. Cada autor proclama que su enfoque es el mejor pero hay poca evidencia para soportar declaraciones [PBER81]. Cada algoritmo de Control de Concurrencia (ACC) puede incluir un subalgoritmo para solucionar cada problema (subproblema). Lo primero que se hace para entender un ACC es aislar el subalgoritmo empleado para cada subproblema. Después de estudiar un largo número de algoritmos propuestos se encontró que ellos son composiciones de solo unos pocos algoritmos. De hecho los subalgoritmos usados por todos los ACC para DDBMS son variaciones de dos técnicas básicas [PBER81]: x Bloqueo de 2 fases (2PL). x Ordenamiento por marcas de tiempo (Timestamping ordering o T/O). Este trabajo de tesis se basará en la clasificación de mecanismos definida en [TOZS99] y en la arquitectura para integrar un control de concurrencia en diferentes entornos descrita en [GHEI95].. - 23 -.

(33) 3.2 Clasificación de Algoritmos Los ACC distribuidos existentes se agrupan en 2 clases generales para sincronización [TOZS99]: pesimista (pessimistic), el cual sincroniza la ejecución concurrente de las solicitudes de usuarios antes que la transacción inicie, y optimista (optimistic), que ejecuta las solicitudes y luego realiza una validación para asegurar que la ejecución no ha comprometido la consistencia de la Base de Datos. Para nuestro interés, el trabajo se centrará en un ACC pesimista dado que es el enfoque actualmente más utilizado y documentado. La clasificación mencionada se ilustra en la Figura 3.1. Los dos enfoques fundamentales que pueden ser usadas tanto en la clase pesimista como en la clase optimista son: bloqueo (locking), que es basado en la exclusión mutua de acceso a datos, y marcas de tiempo (timestamping), donde las transacciones son ejecutadas en algún orden por identificadores. Existen variaciones de estos esquemas conocidos como algoritmos híbridos (hybrid) que intentan combinar los dos mecanismos básicos. Concurrency Control Algorithms. Optimistic. Pessimistic. Locking. Timestamp Ordering. Centralized. Basic. Primary Copy. Multi Version. Distributed. Conservative. Hybrid. Locking. Timestamp Ordering. Figura 3.1 Clasificación de algoritmos de Control de Concurrencia [TOZS99]. - 24 -.

(34) 3.2.1 Algoritmos basados en bloqueo La idea principal de este tipo de algoritmos es asegurar que un dato que es compartido por operaciones conflictivas sea accedido por una operación a la vez. Esto es cumplido asociando un “bloqueo” a cada unidad de bloqueo (una unidad de bloqueo es una porción de la DB que contiene el dato que interesa bloquear). En los algoritmos basados en bloqueo: x Las transacciones indican sus intenciones al solicitar bloqueo al Manejador de Bloqueo (Lock Manager ó LM). x Los bloqueos son read lock (rl) o write lock (wl, también llamado exclusive lock). x Existen conflictos entre read locks y write locks (porque las operaciones de lectura y escritura son incompatibles). El enfoque del bloqueo (en un entorno distribuido) puede ser de tipo centralized, primary copy ó distributed [TOZS99]. En el bloqueo de tipo centralized (centralizado) se le delega la responsabilidad solamente a un sitio (sitio primario) donde las tablas de bloqueo para la DB entera son almacenadas, y el cual es responsable de conceder bloqueos a las transacciones. Los manejadores de transacciones de los otros sitios se comunican con él en vez de hacerlo con sus propios manejadores de bloqueo. Este enfoque es también conocido como el algoritmo 2PL de sitio primario. En el bloqueo de tipo primary copy (copia primaria) una de las copias de cada unidad de bloqueo (del dato que se desea bloquear) es designada como copia primaria, y es esta copia que debe ser bloqueada para el propósito de acceder esta unidad particular. Este tipo de bloqueo es una extensión del centralized. Aunque demanda un directorio sofisticado en cada sitio, reduce la carga del sitio central sin causar una larga medida de comunicación entre los manejadores de transacciones y manejadores de bloqueo. En el bloqueo distributed (distribuido), el manejador de bloqueo responsable es compartido por todos los sitios de una red. En este caso, la ejecución de una transacción envuelve la participación y coordinación de planificadores (schedulers) en más de un sitio. Cada planificador local es responsable de las unidades de bloqueo locales en ese sitio. Este tipo de bloqueo depende de la disponibilidad de los manejadores de cada sitio.. - 25 -.

(35) 3.2.2 Algoritmos basados en ordenamiento por marcas de tiempo A diferencia de los algoritmos de bloqueo, los algoritmos basados en ordenamiento por marcas de tiempo (T/O) envuelven la organización del orden de ejecución en transacciones, por lo que mantienen mutua consistencia. Este ordenamiento es mantenido al asignar marcas de tiempo (timestamps) tanto a las transacciones como a los datos que son almacenados en la DB. Una marca de tiempo es un simple identificador que sirve para reconocer cada transacción y para permitir el ordenamiento. Estos algoritmos pueden ser de tipo basic, multiversion, o conservative [TOZS99]. El proceso inicial del ordenamiento T/O es: A una transacción Ti se le asigna una marca única de tiempo ts(Ti). El administrador de transacciones agrega la marca a todas las operaciones ocupadas por la transacción. A cada dato se le asigna una marca de escritura (wts) y una marca de lectura (rts). x rst(x) = la marca más grande de las lecturas sobre x x wst(x) = la marca más grande de las escrituras sobre x Las operaciones conflictivas son resueltas por orden de marcas (timestamp order). De acuerdo a [TOZS99] la regla T/O se especifica formalmente como sigue: “Dadas 2 operaciones conflictivas Oij y Okl, pertenecientes a las transacciones Ti y Tk respectivamente, Oij es ejecutada antes de Okl si y solo si ts(Ti) < ts(Tk)”. En este caso se dice que Ti es la transacción más antigua y Tk es la transacción más reciente. En un algoritmo T/O basic (básico), una transacción que contiene una operación que es rechazada es reiniciada por el administrador de transacciones con una nueva marca de tiempo. Esto asegura que la transacción tenga una oportunidad para ejecutarse en su próximo intento. Un ejemplo de T/O básico es el siguiente: For Ri(x) If ts(Ti) < wts(x) Then rechaza Ri(x) Else Acepta Ri(x) rts(x) <----- ts(Ti). For Wi(x) If ts(Ti) < rts(x) and ts(Ti) < wts(x) Then rechaza Wi(x) Else acepta Wi(x) wts(x) <----- ts(Ti) - 26 -.

(36) En el primer caso (para lectura de x en la transacción i) se tiene que si al comparar con la estampa de tiempo de Ti, la marca de escritura sobre x es más reciente, se rechaza la lectura. De lo contrario se acepta y por consiguiente, se le asigna como marca de lectura la estampa de tiempo de Ti. En el caso de escritura (para x en Ti), se tiene que si al comparar con la estampa de tiempo de Ti, tanto la marca de escritura como la de lectura sobre x son más recientes, se rechaza la escritura. De lo contrario se acepta y se asigna como marca de escritura la estampa de tiempo de Ti. Las versiones del algoritmo T/O se utilizan dependiendo de la carga o rendimiento esperado. Por ejemplo el tipo conservative se utiliza cuando se desea reducir el número de reinicios y aumentar el rendimiento, el tipo multiversion se utiliza cuando se desea tener soporte para versiones de objetos de Bases de Datos (es decir no se modifica la Base de Datos sino se crea una nueva versión de datos). 3.3 Bloqueo 2PL Centralizado En sistemas basados en bloqueo, el scheduler o planificador (figura 2.4) es un manejador de bloqueo (LM), como parte del Monitor de Ejecución Distribuido [TOZS99]. El Manejador de Transacciones (TM) envía al LM la operación de la DB (read o write) e información asociada (tal como el dato que es accedido y el identificador de la transacción que emite la operación de la DB). El LM verifica entonces si la unidad de bloqueo que contiene el dato está bloqueada. Si es así y si el modo de bloqueo existente es incompatible con el de la transacción actual, la operación actual es rechazada o retardada. De otro modo, el bloqueo es establecido en el modo deseado, el TM notificado de la concesión o el rechazo, y la operación de la DB es enviada al Procesador de Datos (DP) para el acceso a la DB. El TM es posteriormente informado de los resultados de la operación. La terminación de una transacción resulta en la liberación de los bloqueos y el inicio de otra transacción que podría estar esperando para acceder al mismo dato. Esto proceso se ilustra en la figura 3.2. El proceso de bloqueo básico aunque tiene ventaja desde el punto de vista de incremento de concurrencia (pues libera los bloqueos tan pronto como se usan), tiene deficiencias en el aislamiento total y en atomicidad (en parte porque las transacciones pueden traslaparse en la ejecución permitiendo planificaciones no seriales).. - 27 -.

(37) Manejador de Transacciones TM. Mensaje (Liberar Bloqueos). (DP). Operación DB. Mensaje. Procesador de Datos. Operación DB ó Liberar Bloqueos). Notificar a TM. No. La unidad de bloqueo que contiene el dato está bloqueada. Si. Establecer bloqueo en el modo deseado. Si. Manejador de Bloqueo. El modo de bloqueo es incompatible No Si Retardar Operación. Figura 3.2 Proceso general de sistemas basados en bloqueo 3.3.1 Bloqueo de dos fases (2PL) Debido a los problemas del algoritmo de bloqueo básico surge el bloqueo de dos fases (2PL). Las reglas del bloqueo de dos fases son [TOZS99]: 1. Una transacción bloquea un objeto antes de usarlo. 2. Cuando un objeto es bloqueado por otra transacción, la transacción solicitante debe esperar (ó en el peor de los casos abortar). 3. Cuando una transacción libera un bloqueo, no puede solicitarlo de nuevo. Se establece claramente que ninguna transacción debe solicitar un bloqueo después que ésta libera uno de sus bloqueos. Alternativamente, una transacción no debe liberar un bloqueo hasta que ésta confirme que no solicitará otro bloqueo. Los algoritmos 2PL ejecutan transacciones en dos fases. Cada transacción tiene - 28 -.