Control de Transacciones
Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.
Estructura de las 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.
Transacciones Centralizada y Distribuidas
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:
Begin_transaction.
Read.
Write.
Commit.
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.
No hay comentarios.:
Publicar un comentario