DocsTec-971

Vista previa del material en texto

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
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
 
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 
 
Dedicatoria 
 
 
 
 
 
A mi madre, por todo el apoyo y amor que me ha dado siempre. 
 
- iv - 
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 - 
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 - 
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 Algoritmosde Control de Concurrencia ........................... 23 
3.2 Clasificación de Algoritmos.......................................................................... 24 
3.2.1 Algoritmos basados en bloqueo............................................................ 25 
 
- vii - 
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 - 
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 - 
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 deinnovació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 - 
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 - 
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 - 
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 - 
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 licenciaa 
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 - 
 
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 - 
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: 
Es un paquete coherente de una implementación de software que puede 
ser desarrollado independientemente de otras aplicaciones 
(independencia). 
Tiene interfaces explícitas y bien especificadas para informar los 
servicios que provee e interactuar con otros componentes 
(interoperabilidad). 
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 - 
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: 
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. 
Los usuarios tendrían que pagar un alto precio para adicionar 
funcionalidad, aun si ellos no necesitan cada parte de esto. 
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 - 
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 
tercerosy 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: 
la dimensión Componente, que representa la funcionalidad de Base de 
Datos o tarea del DBMS, y 
la dimensión Arquitectura, que representa la arquitectura genérica del 
DBMS que permite la adición de componentes. 
 
- 9 - 
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 - 
 
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 - 
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]: 
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). 
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). 
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. 
Durabilidad: Una transacción es durable porque en terminaciones exitosas, 
los resultadossobrevivirá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 - 
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: 
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. 
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: 
Transacciones generales (general), que mezclan sus acciones de lectura y 
escritura sin algún orden específico. 
Transacciones de dos pasos (two-step), si son restringidas a que todas las 
acciones de lectura son ejecutadas antes de cualquier acción. 
Transacciones restringidas (restricted o read-before-write), si son 
restringidas a que un dato tiene que ser leído antes de que sea actualizado. 
Transacciones restringida de dos pasos (restricted two-step), si es una 
transacción restringida y de dos pasos. 
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: 
Transacciones planas (flat), que tienen un punto de inicio simple 
(Begin_transaction) y un punto de terminación simple (End_transaction). 
Transacciones anidadas (nested), que permiten a una transacción incluir 
otras subtransacciones con sus propios puntos de begin y commit. El nivel 
 
- 13 - 
de anidación es generalmente abierto, permitiendo a las subtransacciones 
mismas tener subtransacciones anidadas. 
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 begin-
transaction, 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 - 
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 
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; 
 
 (a) ) Transacción TRANSFIERE FONDOS a 
nivel global 
(b) Transacción TRANSFIERE FONDOS con 2 
agentes 
Figura 2.4 Aplicación TRANSFIERE_FONDOS [SCER85] 
 
- 15 - 
2.9 Manejador de Transacciones Distribuidas (DTM) 
Es importante definir el papel que juega el Manejador de Transacciones 
Distribuidas (DTM) en un DDBMS. Estese enfoca en tres problemas principales 
[SCER85]: 
Confiabilidad 
Control de Concurrencia 
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, begin-
transaction, 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: 
Asegurar la atomicidad de una subtransacción. 
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: 
En cada sitio todas las acciones son realizadas ó ninguna. 
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 - 
LTM
en 
Sitio i
LTM
en 
Sitio j
LTM
en 
Sitio k
Local
Transaction
Managers (LTM)
DTM-
AGENT
DTM-
AGENT
DTM-
AGENT
Distribuited
Transaction
Manager (DTM)
ROOT
AGENT AGENT AGENT
Distributed
Transaction
2
1 1 1
Interfaz 1: Local_Begin, Local_Commit, Local_Abort, Local_Create
Interfaz 2: Begin_Transaccion, Commit, Abort, Create
LTM
en 
Sitio i
LTM
en 
Sitio j
LTM
en 
Sitio k
Local
Transaction
Managers (LTM)
DTM-
AGENT
DTM-
AGENT
DTM-
AGENT
Distribuited
Transaction
Manager (DTM)
ROOT
AGENT AGENT AGENT
Distributed
Transaction
2
1 1 1
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: 
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. 
Abort. Cuando un abort es emitido por el agente root, todas las 
subtransacciones deben ser abortadas. Esto es realizado enviando 
 
- 17 - 
local_aborts a los LTM´s en todos los sitios donde hay una subtransacción 
activa. 
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: 
El coordinador escribe “prepare” en la bitácora y envía un mensaje donde 
pregunta a todos los participantes si preparan el commit (PREPARE). 
Cada participante escribe “ready” (y registra las subtransacciones) en su 
propia bitácora si está listo o “abort” de lo contrario. 
Cada participante responde con un mensaje READY o ABORT al 
coordinador. 
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 - 
Fase dos: 
El coordinador registra la decisión tomada en almacenamiento estable; es 
decir, escribe “global_commit” o “global_abort” en la bitácora. 
El coordinador envía mensaje de COMMIT o ABORT según sea el caso 
para su ejecución. 
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). 
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. 
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: 
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, 
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 
distribuidases 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. 
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 - 
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. 
Write. El TM coordina la actualización del valor de x en cada sitio donde 
este reside. 
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. 
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 - 
 
 
 
(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 - 
Actualizaciones perdidas, cuando los efectos de alguna transacción 
no son reflejados en la base de datos. 
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: 
Lectura sucia: Una transacción lee valores que otra transacción ha 
modificado sin hacer commit. 
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. 
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 - 
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]: 
Bloqueo de 2 fases (2PL). 
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 - 
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 
Pessimistic Optimistic 
Centralized 
Primary 
Copy 
Distributed 
Locking Timestamp 
OrderingLocking Timestamp 
Ordering 
Hybrid 
Basic 
Multi 
Version
Conservative 
 Figura 3.1 Clasificación de algoritmos de Control de Concurrencia [TOZS99]
 
- 24 - 
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: 
Las transacciones indican sus intenciones al solicitar bloqueo al Manejador 
de Bloqueo (Lock Manager ó LM). 
Los bloqueos son read lock (rl) o write lock (wl, también llamado exclusive 
lock). 
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 - 
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). 
rst(x) = la marca más grande de las lecturas sobre 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 - 
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 - 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.2 Proceso general de sistemas basados en bloqueo 
Manejador de Bloqueo 
Notificar a TMó Liberar Bloqueos)
Si
Mensaje (Liberar Bloqueos)
Operación DB
El modo de 
bloqueo es 
incompatible
La unidad de bloqueo 
que contiene el dato 
está bloqueada 
Manejador de Transacciones
TM 
Establecer bloqueo 
en el modo deseado
Mensaje 
Procesador de Datos
(DP) (DP) 
No
Retardar Operación 
Si
Si
No
Operación DB
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, unatransacció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 - 
una fase de crecimiento (growing phase), donde esta obtiene bloqueos y accesos 
a los datos, y una fase de decrecimiento (shrinking phase), durante la cual libera 
bloqueos. El punto de bloqueo es el momento cuando la transacción ha 
conseguido todos sus bloqueos pero todavía no ha empezado a liberar alguno de 
ellos. Así, el punto de bloqueo determina el fin de la fase de crecimiento y el inicio 
de la fase de decrecimiento. Lo anterior se ilustra en la Figura 3.3. 
fase 2 fase 1 
Obtiene bloqueo 
Libera bloqueo 
INICIO FIN 
Numero 
 de 
 bloqueos 
PUNTO DE BLOQUEO
Duración de la Transacción 
 
Figura 3.3 Bloqueo de dos fases [TOZS99] 
El bloqueo de 2 fases [PBER81] sincroniza lectura y escritura 
explícitamente al detectar conflictos entre operaciones concurrentes. Antes de leer 
un dato x, una transacción debe tener un “readlock” (bloqueo de lectura) sobre x. 
Antes de escribir en x, debe aplicar un “writelock” (bloqueo de escritura) sobre x. 
Las ventajas que presentan este clase de algoritmos son: 
Cualquier planificación generada por la regla 2PL es serializada. 
Incrementa el grado de concurrencia al liberar bloqueos tan pronto 
como se usan. 
Sus desventajas: 
Difícil de implementar dado que el LM tiene que saber que la 
transacción ha obtenido todos sus bloqueos y no necesitará bloquear 
otros datos. 
Si la transacción aborta después de liberar un bloqueo, causa que 
otras transacciones que tengan accedido un dato desbloqueado 
aborten también. Esto se conoce como aborto en cascada. 
Debido a las dificultades presentadas, muchos planificadores 2PL 
implementan el bloqueo de dos fases estricto (Strict 2PL) [TOZS99] que libera 
todos los bloqueos juntos cuando la transacción termine (commits o aborts). Esto 
se muestra en la figura 3.4. 
 
- 29 - 
Obtiene bloqueo
Libera bloqueo 
INICIO FIN 
Numero 
 de 
 bloqueos 
Duración de la Transacción 
Periodo de uso de datos 
Figura 3.4 Bloqueo de dos fases estricto [TOZS99] 
3.3.2 Bloqueo de dos fases Centralizado (C2PL) 
En el ambiente de un DBMS distribuido el implementar este tipo de bloqueo 
implica delegar la responsabilidad del manejo de bloqueos a un sitio. Esto significa 
que solo uno de los sitios tiene un manejador de bloqueo (LM) considerado 
distribuido; los manejadores de transacción (TM) en los otros sitios se comunican 
con éste más que con sus propios LM´s. 
La comunicación entre los sitios cooperativos que ejecutan una transacción 
de acuerdo a un algoritmo C2PL se muestra en la figura 3.5. Esta comunicación se 
da entre el TM en el sitio donde la transacción se inicia (llamado el TM 
coordinador), el LM en el sitio central, y los Procesadores de Datos (DP) en los 
otros sitios participantes. Los sitios participantes son estos en los cuales la 
operación se lleva a cabo [TOZS99]. 
Solicitud de Bloqueo
1
2
Bloqueo
 Conced
ido
3
Operaci
on
Fin de Operacion
4
Libera Bloqueos
5
Procesadores de Datos
En Sitios participantes
TM Coordinador LM en Sitio Central
Solicitud de Bloqueo
1
2
Bloqueo
 Conced
ido
3
Operaci
on
Fin de Operacion
4
Libera Bloqueos
5
Procesadores de Datos
En Sitios participantes
TM Coordinador LM en Sitio Central
 
Figura 3.5 Comunicación en un C2PL [TOZS99] 
 
- 30 - 
Al implementar el algoritmo para el TM centralizado se tiene que 
implementar el protocolo de control de replica si la DB está replicada. Al 
implementar el LM centralizado, este no envía las operaciones a los DP´s 
respectivos; esto es hecho por el TM coordinador. 
Una crítica para los algoritmos C2PL es que un cuello de botella puede 
formarse rápidamente alrededor del sitio central. Además el sistema puede ser 
menos confiable dado que la falla o inaccesibilidad del sitio central causaría fallas 
más graves [TOZS99]. 
3.4 Control de Concurrencia en el DBMS comercial DB2 
En [IBML02] se describe que DB2 emplea un mecanismo de bloqueo 
patentado que almacena bloqueos en memoria. Este manejador considera a los 
bloqueos como objetos transitorios que no requieren persistencia en fallas de 
servidor, por lo que no escribe la información de bloqueo en disco. Por ejemplo, si 
hay una pausa en la DB, al reiniciarla no se necesita conocer que bloqueos fueron 
concedidos en el tiempo de la falla. Esto debido a que se considera que no se 
debe desperdiciar espacio en disco para almacenar objetos y que la memoria es el 
mejor recurso para usar para bloquear información. 
La manera de trabajar de DB2 al solicitarle bloqueos es como sigue: 
Cada bloqueo solicitado tiene un nombre (conocido como Lock Request 
Block o LRB). Cuando un bloqueo es solicitado, es almacenado en un área de 
memoria conocida como lista de bloqueo (Lock List). El tamaño de esta lista es 
determinada por un parámetro de configuración de DB llamado LOCKLIST. Por 
default, 200K de memoria es establecido para bloqueos, aunque el tamaño 
apropiado se determina por el tipo de aplicación y requerimientos de uso. Si 
múltiples aplicaciones intentan bloquear el mismo registro en modo exclusivo 
(update) DB2 crea una lista de enlace a estas solicitudes de bloqueo en memoria 
(el primero en llegar es servido). Múltiples transacciones pueden estar 
compartiendo un bloqueo al mismo tiempo cuando ambos están leyendo el 
registro pero no actualizándolo. La lista de enlace de solicitudes de bloqueo 
contiene tanto las transacciones usando el bloqueo como las transacciones 
esperando el bloqueo. Cuando una transacción está esperando un bloqueo, está 
implícitamente esperando el acceso controlado por un semáforo. Cuando la 
primera transacción de la lista libera su bloqueo, este se elimina de la cadena de 
bloqueo y envía un mensaje a la siguiente transacción en la secuencia para 
permitirle continuar y posesionarse de ese bloqueo. De este modo se evitan 
conflictos entre solicitudes, ya que son procesadas en la secuencia que son 
solicitadas. 
Cuando una aplicación inicia a adquirir un número inusual de bloqueos 
grandes e inicia usando mucha memoria. En este caso, DB2 tiene un algoritmo 
automático (SMART) para reducir los requerimientos de memoria en el sistema. 
 
- 31 - 
El proceso es considerado un evento poco frecuente si un sistema tiene suficiente 
memoria física y es ajustada apropiadamente. Si el área de memoria LOCKLIST 
está llena o si una aplicación adquiere muchos bloqueos, entonces DB2 invoca un 
algoritmo de reducción de requerimiento de memoria conocido como escalamiento 
de bloqueo. El número máximo de bloqueos es definido por el administrador de la 
DB en un parámetro de configuración llamado MAXLOCKS. Por default es 
establecido al 22% de LOCKLIST, así que si una aplicación adquiere más que el 
22%, DB2 debe utilizar el escalamiento de bloqueo. Cuando un escalamiento de 
bloqueo ocurre, en la aplicación manteniendo muchos bloqueos (y en 
consecuencia utilizando mucha memoria) los bloqueos a nivel fila podrán ser 
convertidos a nivel tabla (si es posible), reduciendo los requerimientos de memoria 
en el sistema. 
3.6 Control de Concurrencia en el DBMS Open Source MySQL 
El DBMS MySQL [GTAR02] provee un subsistema simple que realiza la 
función de facilitar la concurrencia en el acceso a los datos. Proporciona el 
bloqueo a nivel tabla para asegurar que los múltiples usuarios que accedan a la 
información, lo hagan de manera consistente. Aunque el bloqueo a nivel tabla se 
considera una desventaja desde algunos puntos de vista, todos los bloqueos en 
MySQL son libres de deadlock. Esto, es conseguido por la secuencia seguida en 
las solicitudes de bloqueo en las querys. En versiones recientes se han hecho 
fusiones entre DBMS tales como el MySQL e InnoDB, consiguiendo tener el 
bloqueo a nivel registro [INNO02]. 
El método de bloqueo de MySQL [MYSQL02] realiza lo siguiente para 
bloqueos de escritura (WRITE): 
Si no hay bloqueos