Manejo de Transacciones Distribuidas

Hasta este momento, las primitivas básicas de acceso que se han considerado son las consultas (queries). Sin embargo, no se ha discutido qué pasa cuando, por ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o si ocurre una falla del sistema durante la ejecución de una consulta. Dada la naturaleza de una consulta, de lectura o actualización, a veces no se puede simplemente reactivar la ejecución de una consulta, puesto que algunos datos pueden haber sido modificados antes la falla. El no tomar en cuenta esos factores puede conducir a que la información en la base de datos contenga datos incorrectos.

El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto de una transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable.

5.1 Definición de una transacción

Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. 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 entra 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 (Ver Figura 5.1)

Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.

Figura 5.1. Un modelo de transacción.

Ejemplo 5.1. Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.

UPDATE J

SET BUDGET = BUDGET*1.1

WHERE JNAME = "CAD/CAM"

Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre:

Begin_transaction ACTUALIZA_PRESUPUESTO

begin

UPDATE J

SET BUDGET = BUDGET*1.1

WHERE JNAME = "CAD/CAM"

end.

¨

Ejemplo 5.2. Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones:

FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )

CUST( CNAME, ADDR, BAL )

FC( FNO, DATE, CNAME, SPECIAL )

Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción:

Begin_transaction Reservación

begin

input( flight_no, date, customer_name );

EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1

WHERE FNO = flight_no

AND DATE = date

EXEC SQL INSERT

INTO FC( FNAME, DATE, CNAME, SPECIAL )

VALUES (flight_no, date, customer_name, null )

output("reservación terminada");

end.

¨

Condiciones de terminación de una transacción

Una transacción siempre termina, aun en la presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un commit (se usará el término en inglés cuando no exista un término en español que refleje con brevedad el sentido del término en inglés). Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta. Cuando la transacción es abortada, su ejecución es detenida y todas sus acciones ejecutadas hasta el momento son deshechas (undone) regresando a la base de datos al estado antes de su ejecución. A esta operación también se le conoce como rollback.

Ejemplo 5.3. Considerando de nuevo el Ejemplo 5.2, veamos el caso cuando no esisten asientos disponibles para hacer la reservación.

Begin_transaction Reservación

begin

input( flight_no, date, customer_name );

EXEC SQL SELECT STSOLD, CAP

INTO temp1, temp2

FROM FLIGHT

WHERE FNO = flight_no AND DATE = date

if temp1 = temp2 then

output( "no hay asientos libres" )

Abort

else

EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1

WHERE FNO = flight_no AND DATE = date

EXEC SQL INSERT

INTO FC( FNAME, DATE, CNAME, SPECIAL )

VALUES (flight_no, date, customer_name, null )

Commit

output("reservación terminada");

endif

end.

Caracterización de transacciones

Observe que en el ejemplo anterior las transacciones leen y escriben datos. Estas acciones se utilizan como base para caracterizar a las transacciones. Los elementos de datos que lee una transacción se dice que constituyen el conjunto de lectura (RS). Similarmente, los elementos de datos que una transacción escribe se les denomina el conjunto de escritura (WS). Note que los conjuntos de lectura y escritura no tienen que ser necesariamente disjuntos. La unión de ambos conjuntos se le conoce como el conjunto base de la transacción (BS = RS U WS).

Ejemplo 5.4. Los conjuntos de lectura y escritura de la transacción del Ejemplo 5.3 son:

RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }

WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME, FC.SPECIAL }

¨

Formalización del concepto de transacción

Sea Oij(x) una operación Oj de la transacción Ti la cual trabaja sobre alguna entidad x. Oj Î {read, write} y Oj es una operación atómica, esto es, se ejecuta como una unidad indivisible. Se denota por OSi = U j Oij al conjunto de todas las operaciones de la transacción Ti. También, se denota por Ni la condición de terminación para Ti, donde, Ni Î {abort, commit}.

La transacción Ti es un orden parcial, Ti = { S i, <i }, donde

  1. S i = OSi U {Ni}
  2. Para cualesquiera dos operaciones, Oij, Oik Î OSi, si Oij = R(x) y Oik = W(x) para cualquier elemento de datos x, entonces, ó Oij <i Oik ó Oik <i Oij
  3. " Oij Î OSi, Oij <i Ni

Ejemplo 5.5. Considere una transacción simple T que consiste de los siguientes pasos:

Read( x )

Read( y )

x ¬ x + y

Write( x )

Commit

La especificación de su transacción de acuerdo con la notación formal que se ha introducido es la siguiente:

å = { R(x), R(y), W(x), C }

<i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }

¨

Note que la relación de ordenamiento especifica el orden relativo de todas las operaciones con respecto a la condición de terminación. Esto se debe a la tercera condición de la definición de transacción. También note que no se define el ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido un orden parcial.

 

Propiedades de las transacciones

La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aun no se ha dado ninguna justificación para afirmar que las transacciones son unidades de procesamiento consistentes y confiables. Las propiedades de una transacción son las siguientes:

  1. 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 deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperación de transacciones. La actividad de asegurar la atomicidad en presencia de caídas del sistema se le llama recuperación de caídas.

     

  2. Consistencia. La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva 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.

     

  3. Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. 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 (seriabilidad).

     

  4. Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas.

     

En resumen, las transacciones proporcionan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de réplicas (en el caso de que se soporten).

Tipos de Transacciones

Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser agrupadas a lo largo de las siguientes dimensiones:

  1. Areas de aplicación. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos.

     

  2. Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por accesar un porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos.

     

     

  3. Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción.

     

 

Estructura de transacciones

Las transacciones planas consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end. Por ejemplo,

Begin_transaction Reservación

. . .

end.

En las transacciones anidadas las operaciones de una transacción pueden ser así mismo transacciones. Por ejemplo,

Begin_transaction Reservación

. . .

Begin_transaction Vuelo

. . .

end. {Vuelo}

. . .

Begin_transaction Hotel

. . .

end.

. . .

end.

Una transacción anidada dentro de otra transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. Más aún, el commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas también serán abortadas.

Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varios transacciones, es posible tener más concurrencia dentro de una sola transacción. Así también, es posible recuperarse de fallas de manera independiente de cada subtransacción. Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo de la recuperación sea menor.

En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como generales. En contraste, si se restringe o impone que un dato deber ser leído antes de que pueda ser escrito entonces se tendrán transacciones restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de dos pasos. Finalmente, existe un modelo de acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par <read,write> tiene que ser ejecutado de manera atómica.

 

Ejemplo 5.6. Los siguientes son algunos ejemplos de los modelos de transacción mencionados antes.

General: T1: { R(x), R(y), W(y), R(z), W(x), W(z), W(w), C}

Dos pasos: T2: { R(x), R(y), R(z), W(x), W(y), W(z), W(w), C}

Restringida: T3: { R(x), R(y), W(y), R(z), W(x), W(z), R(w), W(w), C}

Restringida y de dos pasos:

T4: { R(x), R(y), R(z), R(w), W(y), W(x), W(z), W(w), C}

Acción: T5: { [R(x), W(x)], [R(y), W(y)], [R(z), W(z)], [R(w), W(w)], C}

note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica

¨

Aspectos relacionados al procesamiento de transacciones

Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:

     

  1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.

     

     

  2. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.

     

     

  3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.

     

     

  4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.

     

     

  5. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

     

Incorporación del manejador de transacciones a la arquitectura de un SMBD

Con la introducción del concepto de transacción, se requiere revisar el modelo arquitectural presentado en el capítulo 2. En esta sección, se expande el papel del monitor de ejecución distribuida.

El monitor de ejecución distribuida consiste de dos módulos: El administrador de transacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura 5.2, el administrador de transacciones es responsable de coordinar la ejecución en la base de datos de las operaciones que realiza una aplicación. El despachador, por otra parte, es responsable de implementar un algoritmo específico de control de concurrencia para sincronizar los accesos a la base de datos.

Un tercer componente que participa en el manejo de transacciones distribuidas es el administrador de recuperación local cuya función es implementar procedimientos locales que le permitan a una base de datos local recuperarse a un estado consistente después de una falla.

Figura 5.2. Un modelo del administrador de transacciones.

Los administradores de transacciones implementan una interfaz para los programas de aplicación que consiste de los comandos:

  1. Begin_transaction.
  2. Read.
  3. Write.
  4. Commit.
  5. Abort.

En la Figura 5.3 se presenta la arquitectura requerida para la ejecución centralizada de transacciones. Las modificaciones requeridas en la arquitectura para una ejecución distribuida se pueden apreciar en las Figura 5.4. En esta última figura se presentan también los protocolos de comunicación necesarios para el manejo de transacciones distribuidas.

Figura 5.3. Ejecución centralizada de transacciones.

Figura 5.4. Ejecución distribuida de transacciones.