Mecanismos de control de transacciones para una BDD
Una
transacción de una sola instancia de Motor de base de datos que abarque dos o
más bases de datos es, de hecho, una transacción distribuida. La instancia
administra la transacción distribuida internamente; para el usuario funciona
como una transacción local.
En la aplicación, una transacción distribuida al
final de la transacción, la aplicación pide que se confirme o se revierta la
transacción.
Fase de
preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación,
envía un comando de preparación a todos los administradores de recursos
implicados en la transacción. Cada administrador de recursos hace lo necesario
para que la transacción sea duradera y todos los búferes que contienen imágenes
del registro de la transacción se pasan a disco. A medida que cada
administrador de recursos completa la fase de preparación, notifica si la
preparación ha tenido éxito o no al administrador de transacciones.
Fase de
confirmación
Si el administrador de
transacciones recibe la notificación de que todas las preparaciones son
correctas por parte de todos los administradores de recursos, envía comandos de
confirmación a cada administrador de recursos. A continuación, los
administradores de recursos pueden completar la confirmación. Si todos los
administradores de recursos indican que la confirmación ha sido correcta, el
administrador de transacciones envía una notificación de éxito a la aplicación.
Si algún administrador de recursos informó de un error al realizar la
preparación, el administrador de transacciones envía un comando para revertir
la transacción a cada administrador de recursos e indica a la aplicación que se
ha producido un error de confirmación.
Requiere:
Existe un agente raíz que inicia toda la
transacción, así que cuando el usuario requiere la ejecución de una aplicación
distribuida el agente raíz es iniciado; el sitio del agente raíz es llamado el
sitio origen de la transacción.
El agente raíz tiene la responsabilidad de asegurar
BEGIN-TRANSACTION, COMMIT O ROLLBACK de toda la transacción distribuida.
Recuperación
de transacciones distribuidas
·
Para
realizar la recuperación de transacción distribuidas se asume que cada sitio
tiene su propio manejador de transacción local (LTM).
·
Cada
agente utiliza de manera local las primitivas asociadas a sus transacciones.
Podemos llamar a los agentes subtransacciones, lo cual origina distinguir las
primitivas BEGIN-TRANSACTION, COMMIT Y ROLLBACK asociado a la transacción
distribuida de la primitivas locales utilizada por
·
cada
agente en LTM; para poder distinguir una de las otras, a las ultimas les
llamaremos:
·
LOCAL-BEGIN,
LOCAL-COMMIT Y LOCALROLLBACK.
·
Para
propósito del manejador de transacciones distribuidas (DTM), requieren que los
LTM se conformen de la siguiente manera:
1.
Asegurar
la atomicidad de su transacción.
2.
Grabar en
bitácora por ordenes de la transacción distribuida.
Para asegurar
que todas las acciones de una transacción distribuida son ejecutadas o no
ejecutadas dos condiciones son necesarias:
·
En cada
sitio todas las acciones son ejecutadas o ninguna es ejecutada.
·
Todos los
sitios deberán tomar la misma decisión respecto al COMMIT o ROLLBACK de la
transición global.
Estados de una transacción
• Activa: Durante su ejecución Ficheros y bases
de datos
• Parcialmente comprometida: Después de ejecutar
su última instrucción.
• Fallida: Imposible de continuar su ejecución
normal.
• Abortada: Transacción retrocedida y base de
datos restaurada al estado anterior a su
ejecución. Se puede reiniciar o cancelar.
Diagrama de estados de una transacción:
No hay comentarios:
Publicar un comentario