Resumen. El control de transacciones concurrentes en una base de datos
brinda un eficiente desempeño del Sistema de Base de Datos,
puesto que permite controlar la ejecución de transacciones que
operan en paralelo, accesando a información compartida y, por lo
tanto, interfiriendo potencialmente unas con otras. El hecho de
reservar un asiento en una avión mediante un sistema basado en
aplicaciones web, cuando decenas de personas en el mundo pueden
reservarlo también, nos da una idea de lo importante y crucial
que es el control de concurrencia en un sistema de base de datos a
mediana o gran escala.
1 Introducción:
Por más de treinta años, las organizaciones han realizado sus
actividades de procesamiento de datos en línea. Muchas
organizaciones, tales como aerolíneas y bancos, no pueden
funcionar correctamente cuando sus sistemas informáticos en
línea se detienen. Sus bases de datos en línea deben
estar correctamente actualizadas todo el tiempo.
En parte, el requerimiento de correctitud y confiabilidad es el
principal tema de preocupación de los programadores de
aplicaciones. Ellos escriben aplicaciones que realizan las
funciones básicas de una organización : realizar un depósito
o un retiro, reservar un asiento o comprar un pasaje, comprar o
vender algún producto, etc. Cada una de estas aplicaciones
está diseñada y probada para desempeñar su función
correctamente. Sin embargo, aún las aplicaciones implementadas
más cuidadosamente son vulnerablea a ciertos errores que están
fuera de su control. Estos errores potenciales surgen debido a dos
factores : concurrencia y fallas.
La multiprogramación es esencial para alcanzar un alto
desempeño, puesto que permite que muchas aplicaciones intercalen
sus ejecuciones. Es decir, se ejecutan concurrentemente.
Pero tales programas pueden interferir cuando intercalan sus
accesos a la base de datos. El hecho de evitar esta interferencia
es conocido como el problema de control de concurrencia.
Los sistemas que tratan el problema de control de concurrencia
permiten que sus usuarios asuman que cada una de sus aplicaciones
se ejecutan atómicamente, como si no existieran otras
aplicaciones ejecutándose concurrentemente. Esta abstracción
de una ejecución atómica y confiable de una aplicación se
conoce como una transacción.
Un algoritmo de control de concurrencia asegura que las
transacciones se ejecuten atómicamente controlando la
intercalación de transacciones concurrentes, para dar la
ilusión de que las transacciones se ejecutan serialmente, una
después de la otra, sin ninguna intercalación. Las ejecuciones
intercaladas cuyos efectos son los mismos que las ejecuciones
seriales son denominadas serializables y son correctos ya
que soportan la ilusión de la atomicidad de las transacciones.
El concepto principal es el de transacción.
Informalmente, una transacción es la ejecución de ciertas
instrucciones que accesan a una base de datos compartida. El
objetivo del control de concurrencia y recuperación es asegurar
que dichas transacciones se ejecuten atómicamente, es decir
- cada transacción accede a información compartida sin
interferir con otras transacciones, y
- si una transacción termina normalmente, todos sus efectos
son permanentes, en caso contrario no tiene afecto alguno.
El propósito de este documento es dar a entender el significado
e importancia del control de concurrencia de transacciones en una
base de datos, motivo por el cual, en la sección 2 se presenta
un panorama general de las transacciones, definición,
propiedades fundamentales, entre otros puntos. El problema de
control de concurrencia es abordado en la tercera sección,
mostrando ejemplos claros y concisos acerca de dos de los
incovenientes más frecuentes que resultan de una ejecución
incorrecta de transacciones concurrentes.
Puesto que la teoría de seriabilidad es una herramienta
básica que permite determinar cuáles ejecuciones concurrentes
producen resultados correctos, en la sección 4 se presentan
los conceptos más importantes de esta teoría para luego
revisar brevemente los métodos existentes de control de
concurrencia (Sección 5). En la sexta sección, se presenta
uno de los métodos más utilizados para controlar las
ejecuciones concurrentes en las bases de datos; se trata de un
método pesimista basado en bloqueos, conocido como Bloqueo de
Dos Fases.
2 Transacciones
Una transacción puede ser definida como la ejecución de una
colección de acciones que realiza una función administrativa
accesando a una base de datos compartida transformando los estados
de ésta, usualmente en representación de un usuario y que
preserva la consistencia del sistema. Por ejemplo, reservar o
comprar un pasaje aéreo, verificar el saldo de una trajeta de
crédito, ordenar la compra de un producto usando un catálogo
en Internet, bajar un videoclip, etc.
Una base de datos está en un estado consistente si obedece todas
las restricciones de integridad definidas sobre ella. Los cambios
de estado ocurren debido a actualizaciones, inserciones y
supresiones de información. Por supuesto, se quiere asegurar que
la base de datos nunca entre en un estado de inconsistencia. Sin
embargo, durante la ejecución de una transacción, la base de
datos puede estar temporalmente en un estado inconsistente. El
punto importante aquí es asegurar que la base de datos
regresa a un estado consistente al fin de la ejecución de una
transacción.
Fig. 1. Un modelo de Transacción
Las propiedades fundamentales de una transacción son las
siguientes :
Atomicidad Se refiere al hecho de que una
transacción se trata como una unidad de operación. Por lo
tanto, o todas las acciones de la transacción se realizan o
ninguna de ellas se lleva a cabo. La atomicidad requiere que si
una transacción se interrumpe por una falla, sus resultados
parciales sean anulados.
Consistencia La consistencia de una transacción es
simplemente su correctitud. En otras palabras, una transacción
es un programa correcto que lleva a la base de datos de un estado
consistente a otro con la misma característica. Debido a
esto, las transacciones no violan las restricciones de integridad
de una base de datos.
Aislamiento Una transacción en ejecución no
puede revelar sus resultados a otras transacciones concurrentes
antes de finalizar. Más aún, si varias transacciones se
ejecutan concurrentemente, los resultados deben ser los mismos que
si ellas se hubieran ejecutado de manera secuencial.
Permanencia Es la propiedad de las transacciones que
asegura que una vez que una transacción finaliza exitosamente,
sus resultados son permanentes y no pueden ser borrados de la base
de datos por alguna falla posterior. Por lo tanto, los sistemas
manejadores de base de datos aseguran que los resultados de una
transacción sobrevivirán a fallas del sistema. Esta propiedad
motiva el aspecto de recuperación de base de datos, el cual
trata sobre cómo recuperar la base de datos a un estado
consistente donde todas las acciones que han finalizado con
éxito queden reflejadas en la base.
En esencia, lo que se persigue con el procesamiento de
transacciones es, por una parte, obtener una transparencia
adecuada de las acciones concurrentes a una base de datos y por
otra, manejar adecuadamente las fallas que se puedan presentar en
una base de datos.
La mayoría de medianas y grandes compañías modernas
utilizan el procesamiento de transacciones para sus sistemas de
producción, y es tan inprescindible que las organizaciones no
pueden funcionar en ausencia de él. El procesamiento de
transacciones representa una enorme y significativa porción del
mercado de los sistemas informáticos (más de cincuenta
billones de dólares al año) y es, probablemente, la
aplicación simple más amplia de las computadoras. Además, se
ha convertido en el elemento que facilita el comercio
electrónico.
Como puede percibirse, el procesamiento de transacciones es una de
las tareas más importantes dentro de un sistema de base de
datos, pero a la vez, es una de las más difíciles de
manejar debido a diversos aspectos, tales como :
Confiabilidad Puesto que los sistemas de
base de datos en línea no pueden fallar.
Disponibilidad Debido a que los sistemas de
base de datos en línea deben estar actualizados correctamente
todo el tiempo.
Tiempos de Respuesta En sistemas de este
tipo, el tiempo de respuesta de las transacciones no debe ser
mayor a doce segundos.
Throughput Los sistemas de base de datos en
línea requieren procesar miles de transacciones por segundo.
Atomicidad En el procesamiento de
transacciones no se aceptan resultados parciales.
Permanencia No se permite la eliminación
en la base de datos de los efectos de una transacción que ha
culminado con éxito.
Dado que un sistema de base de datos (DBS) es una colección de
datos y programas, es lógico pensar que existen ciertos comandos
que permiten acceder a la base de datos, conocidos como
operaciones. Las operaciones más importantes son Leer y
Escribir. Leer(x) devuelve el valor almacenado en el dato x,
mientras que Escribir(x,val) cambia el valor de x a bval.
El DBS ejecuta cada operación atómicamente; es decir, se
comporta como si ejecutara operaciones secuencialmente, esto es,
una a la vez. Para lograr este desempeño, el DBS puede, en
realidad, ejecutar operaciones secuencialmente; sin embargo,
frecuentemente ejecutará operaciones concurrentemente. Esto
quiere decir que pueden existir ocasiones en que se esté
ejecutando más de una operación a la vez; no obstante,
aún cuando se ejecuten operaciones concurrentemente, el efecto
final debe ser el mismo que alguna ejecución secuencial.
Por ejemplo, supongamos que los datos x y y están
almacenados en dos dispositivos diferentes. El DBS puede
ejecutar las operaciones sobre x y y en el siguiente orden:
- ejecutar Leer(x);
después que el paso 1 ha finalizado, concurrentemente ejecutar Escribir(x,1) y Leer(y);
después que el paso 2 ha finalizado, ejecutar
Escribir(y,0).
Aunque Escribir(x,1) y Leer(y) son ejecutados concurrentemente
puede considerarse que se hayan ejecutado atómicamente. Esto
debido a que la ejecución tiene el mismo efecto que una
ejecución secuencial, tal como Leer(x), Escribir(x,1),
Leer(y), Escribir(y,0).
El DBS también soporta operaciones de
transacción:Start, Commit y Abort. Un programa le indica al DBS
que va comenzar a ejecutar la nueva transacción usando la
operación Start. Le indica la terminación de una
transacción usando tanto la operación Commit como la
operación Abort. Al usar un Commit, el programa le
transmite al DBS que la transacción ha terminado normalmente y
que todos sus efectos deben ser hechos permanentes. Mientras que
usando un Abort el programa le indica al DBS que la transacción
ha terminado anormalmente y que todos sus efectos deben ser
anulados.
Una transacción puede ser una ejecución concurrente de
dos o más programas. Es decir la transacción puede enviar dos
operaciones al DBS antes que el éste haya respondido a alguna de
ellas. Sin embargo, la última operación de la transacción
debe ser un Commit o un Abort. Por lo tanto, el DBS debe
rechazar el procesamiento de una operación de una transacción
si ésta llega después que el DBS ha ejecutado el Commit o el
Abort de dicha transacción.
Los usuarios interactúan con un DBS invocando programas. Desde
el punto de vista de los usuarios, una transacción es la
ejecución de uno o más programas que incluyen operaciones de
base de datos y de transacciones.
Por ejemplo, consideremos una base de datos de un banco que
contiene un archivo de cuentas de los clientes, llamado Cuentas,
cada una de cuyas entradas contiene el saldo en una cuenta. Una
transacción útil para esta base de datos es aquella que
transfiere dinero de una cuenta a otra.
Procedure Transfiere(CuentaOrigen, CuentaDestino, Monto)
begin
Start;
temp := Leer(Cuentas[CuentaOrigen]);
if temp $<$ Monto then
begin
output("Insuficientes fondos");
Abort;
end
else
begin
Escribir(Cuentas[CuentaOrigen],temp-Monto);
temp := Leer(Cuentas[CuentaDestino]);
Escribir(Cuentas[CuentaDestino],temp+Monto);
Commit;
output("Transferencia finalizada");
end
end
Después que el DBS ejecuta una operación de transacción
Commit (o Abort), se dice que la transacción está
confirmada (o cancelada). Una transacción que ha
ejecutado su operación Start, pero aún no se ha confirmado o
cancelado se llama activa. Una transacción está
sin confirmar si está cancelada o activa.
Una transacción ejecuta una operación Abort si ésta no puede
ser completada correctamente. La transacción por sí misma
puede invocar un Abort porque ha detectado un error del cual no se
puede recuperar, tal como la condición de "Insuficientes fondos"
en Transferir. O el Abort puede ser impuesto en un transacción
por circunstancias fuera de su control. Por ejemplo, supongamos
que una falla del sistema interrumpe la ejecución de una
transacción Transferir después de haber descargado una cuenta
pero antes de cargar la otra. Asumiendo que el estado interno de
Transferir se pierde como consecuencia de la falla, no puede
continuar su ejecución. Entonces, cuando el sistema se recupera,
el DBS debería hacer que la ejecución de Transferir sea
cancelada. En tal caso, aún se ve que el Abort es una
operación de la transacción, aunque fue el DBS quien realmente
invocó la operación.
Cuando una transacción es cancelada, el DBS elimina todos sus
efectos. La posibilidad de que una transacción pueda ser
cancelada requiere de la habilidad para determinar el punto
después del cual el DBS garantiza al usuario que la
transacción no será cancelada y sus efectos serán
permanentes. Por ejemplo, en el procesamiento de un depósito a
través de un cajero automático, un cliente no quiere retirarse
antes de estar seguro que la transacción no será cancelada.
Similarmente, desde el punto de vista del banco, al procesar un
retiro, el cajero automático no debe entregar dinero alguno
antes de cerciorarse que la transacción de retiro no será
cancelada.
La operación Commit brinda esta garantía. Su invocación
significa que una transacción ha terminado "normalmente" y que
sus efectos deben ser permanentes. La ejecución del Commit de
una transacción constituye una garantía por parte del
DBS que no cancelaría la transacción y que los efectos de la
transacción resistirán futuras fallas del sistema.
|
