TRANSACCIONES

DISTRIBUIDAS

Cristian Andres Bohorquez Lopez

Viviana Carolina Mora Álvarez
Julian Andres Pianda R
 Definición

Las transacciones distribuidas o globales permiten a las aplicaciones

clientes incluir en una transacción diversos recursos de datos en dos
o más sistemas en red.
En las transacciones distribuidas, un gestor de transacciones
coordina y gestiona la transacción entre dos o más gestores de
recursos.

Como cualquier otra transacción, una transacción distribuida debe

incluir las cuatro propiedades ACID (atomicidad, consistencia,
aislamiento, durabilidad). Dada la naturaleza del trabajo, la
atomicidad es importante para garantizar un resultado de todo o
nada para el paquete de operaciones (unidad de trabajo).
 Características

● (Atomicity)Atómicas: Cada unidad de trabajo es una

operación todo o nada (ante un fallo del sistema la
operación no puede quedarse a medias)
● (Consistency)Consistentes: La operación no rompe
las reglas y directrices de integridad de la base de
datos.
● (Isolation)Aisladas: Cada transacción se ejecuta de
forma aislada e independiente, sin afectar a otras
transacciones.
● (Durability)Durables: una vez cometida la transacción
los cambios son permanentes.
 Gestor de recursos

Un gestor de recursos es un subsistema informático que posee y gestiona

recursos a los que las aplicaciones pueden acceder y que pueden actualizar. A
continuación, se muestran algunos ejemplos de gestores de recursos:

Un gestor de colas de IBM MQ, con recursos que son las colas

Una base de datos de Db2, con recursos que son las tablas
 Primitivas sobre transacciones

● begin_transaction: Inicia una transacción y devuelve

un identificador
● close_transaction (commit, abort):
○ commit: termina exitosamente y sus efectos van a
almacenamiento permanente
○ abort: no se reflejan cambios, ocurrió un fallo
interno ya sea natural o conflicto con otra
transacción
● abort_transaction: aborto intencional
● read, write: una transacción se compone de una serie
de cálculos, lecturas y escrituras
 Transacciones simples y anidadas
Las transacciones distribuidas pueden ser simples o anidadas

● Simples: ● Anidadas:
TRANSACCIONES DISTRIBUIDAS PLANAS

En una transacción plana, el cliente

hace requerimientos a más de un
servidor. Cada transacción accede a
los objetos en los servidores
secuencialmente. El cliente de la
transacción plana espera completar
todos sus requerimientos antes de
pasar a la próxima.
TRANSACCIONES ANIDADAS

En una transacción
anidada, la transacción de
mayor nivel puede abrir
subtransacciones y, a su
vez cada subtransacción
puede abrir otras en
niveles más bajos de
anidamiento.
 Características
Las transacciones pueden contener sub transacciones .

Problema: Si una transacción interna realiza commit y una más

externa abort, se pierden las propiedades de atomicidad y
aislamiento por cumplir con la durabilidad.

Generalmente la durabilidad sólo se considera para la transacción

más externa.

En algunos sistemas, la transacción superior puede decidir hacer

commit aún cuando alguna sub transacción aborta.
 Confirmación de Fase Única

La confirmación en una sola fase es un proceso en el que solo participa un

gestor de recursos en el proceso de transacción y en un proceso de
confirmación en dos fases hay más de un gestor de recursos participando
en la transacción.
 Confirmación en dos fases
2PC

En el proceso de confirmación en dos fases, el gestor de transacciones

envía una llamada de preparación para comprobar si todos los gestores
de recursos están preparados para confirmar. Cuando se recibe el acuse
de recibo de todos los gestores de recursos, se emite la llamada de
confirmación. En caso contrario, tendrá lugar una retrotracción de toda la
transacción.
Protocolo de consolidación en dos fases
 Servicios WEb

● Permite a los clientes interactuar con los servidores de

una manera más general que como los navegadores lo
hacen. Los clientes acceden a las operaciones en la
interfaz de un servicio web a través de solicitudes y
respuestas con formato en XML Transacciones
distribuidas (eXtensible Markup Language) y
generalmente se transmite a través protocolos HTTP
(Hypertext Transfer Protocol)
Servicios WEB
 DEADLOCK

el bloqueo mutuo (también conocido como interbloqueo,

traba mortal, deadlock, abrazo mortal) es el bloqueo
permanente de un conjunto de procesos o hilos de
ejecución en un sistema concurrente que compiten por
recursos del sistema o bien se comunican entre ellos.
 Comprensión de consistencia de datos
Consistencia fuerte: cuando se completa la operación de actualización,
cualquier acceso por múltiples procesos o subprocesos posteriores devolverá el
último valor actualizado. Esto es lo más fácil de usar, es decir, lo que el usuario
escribió la última vez, la próxima vez se garantiza que podrá leer.

Consistencia débil: el sistema no garantiza que los procesos o subprocesos

posteriores devuelvan el último valor actualizado. Después de que los datos se
escriben con éxito, el sistema no promete leer el último valor escrito de
inmediato, ni promete específicamente cuánto tiempo estará disponible.
 Comprensión de consistencia de datos

Consistencia eventual: una forma específica de consistencia débil. El

sistema garantiza que bajo la premisa de ninguna actualización posterior,
el sistema finalmente devolverá el valor de la última operación de
actualización.

.
Ejemplo de Transacción distribuida

Un ejemplo clásico de transferencia interbancaria para describir.

● El pseudocódigo del primer paso es el siguiente, deduzca 1W y

asegúrese de que el mensaje de comprobante se inserte en la
tabla de mensajes a través de transacciones locales
Ejemplo de Transacción distribuida

● El segundo paso es notificar a la otra parte que se ha agregado

1W a la cuenta bancaria, generalmente de dos maneras:
○ Usando MQ con alta puntualidad, la otra parte se suscribe
y monitorea mensajes, y automáticamente activa eventos
cuando hay mensajes.
○ El método de sondeo y escaneo regular se utiliza para
verificar los datos de la tabla de mensajes.
Ejemplo de Transacción distribuida

● El segundo paso es notificar a la otra parte que se ha agregado

1W a la cuenta bancaria, generalmente de dos maneras:
○ Usando MQ con alta puntualidad, la otra parte se suscribe
y monitorea mensajes, y automáticamente activa eventos
cuando hay mensajes.
○ El método de sondeo y escaneo regular se utiliza para
verificar los datos de la tabla de mensajes.
Middleware de mensajes
Es difícil para nosotros garantizar que la operación del mensaje de entrega MQ
sea exitosa después de que se complete la deducción.

Analizando las posibles situaciones:

● La operación de la base de datos es exitosa, y la entrega de mensajes

al MQ también es exitosa, todos están contentos.
● No se pudo operar la base de datos, no se enviarán más mensajes a
MQ.
● La operación de la base de datos fue exitosa, pero la entrega del
mensaje a MQ falló. Se descartó una excepción. La operación que se
acaba de realizar para actualizar la base de datos se revertirá.
El middleware RocketMQ de Alibaba admite un mecanismo de
mensaje de transacción para garantizar que las operaciones locales y el
envío de mensajes tengan el mismo efecto que las transacciones
locales.

● Primera etapa
● Segunda etapa
● Tercera etapa
● La primera etapa: can_commit

En esta etapa, el coordinador preguntará a cada participante si puede ejecutar

la transacción normalmente, y el participante responderá con un valor
estimado de acuerdo con su propia situación. Los pasos específicos son los
siguientes:

1. El coordinador envía una notificación de consulta de transacción a cada

participante, preguntándole si la operación de transacción se puede realizar y
esperando una respuesta.

2. Cada participante responde a un valor estimado en función de sus propias

condiciones. Si se estima que puede realizar la transacción normalmente,
devolverá un mensaje de confirmación e ingresará el estado de preparación, de
lo contrario devolverá un mensaje negativo.
● La segunda etapa: pre_compromiso

En esta etapa, el coordinador tomará las acciones

correspondientes de acuerdo con los resultados de la
investigación de la primera etapa. Hay tres resultados
principales de la investigación:

1. Todos los participantes devuelven un mensaje de

confirmación.

2. Uno o más participantes devuelven información negativa.

3. El coordinador espera un tiempo de espera.

● La tercera etapa: do_commit

Si la transacción de la segunda etapa no se interrumpe, el

coordinador de esta etapa decidirá confirmar o revertir la
transacción en función de los resultados devueltos por la ejecución
de la transacción.
Aplicaciones