Transacciones distribuidas planas y anidadas

Introducción: 
una transacción es una serie de operaciones de objetos que deben realizarse de manera compatible con ACID.

• Atomicidad : 
  la transacción se completa en su totalidad o no se completa en absoluto.
• Consistencia – 
  Es un término que se refiere a la transición de un estado consistente a otro.
• Aislamiento – 
  Se realiza separadamente de otras transacciones.
• Durabilidad: una vez completado, es de larga duración. 

Transacciones – Comandos :

• Comenzar:
  iniciar una nueva transacción.
• Confirmar: 
  finaliza una transacción y se guardan los cambios realizados durante la transacción. Además, permite que otras transacciones vean las modificaciones que has realizado.
• Abortar: 
  finaliza una transacción y se deshacen todos los cambios realizados durante la transacción.

Se asignan varios roles para ejecutar una transacción con éxito:

• Cliente: 
  las transacciones son emitidas por los clientes.
• Coordinador: 
  controla la ejecución de toda la transacción (maneja Begin, commit & abort).
• Servidor:
  cada componente que accede o modifica un recurso está sujeto al control de transacciones. El coordinador debe ser conocido por el servidor transaccional. El servidor transaccional registra su participación en una transacción con el coordinador.

Una transacción plana o anidada que accede a objetos manejados por diferentes servidores se denomina transacción distribuida.
Cuando una transacción distribuida llega a su fin, para mantener la propiedad de atomicidad de la transacción, es obligatorio que todos los servidores involucrados en la transacción confirmen la transacción o la aborten.  
Para hacer esto, uno de los servidores asume el trabajo de coordinador, lo que implica garantizar que se logre el mismo resultado en todos los servidores. 
El método por el cual el coordinador logra esto está determinado por el protocolo seleccionado. El protocolo más utilizado es el «protocolo de confirmación de dos fases»..’ Este protocolo permite que los servidores se comuniquen entre sí para llegar a una decisión conjunta sobre si comprometer o cancelar la transacción completa. 

Transacciones distribuidas planas y anidadas:
si una transacción de cliente llama a acciones en varios servidores, se dice que está distribuida. Las transacciones distribuidas se pueden estructurar de dos maneras diferentes: 

1. Transacciones planas
2. Transacciones anidadas

TRANSACCIONES PLANAS:
una transacción plana tiene un solo punto de inicio (comienzo) y un solo punto final (confirmar o cancelar). Por lo general, son muy simples y generalmente se usan para actividades cortas en lugar de actividades más grandes.
Un cliente realiza requests a múltiples servidores en una transacción plana. La transacción T, por ejemplo, es una transacción plana que realiza operaciones en objetos en los servidores X, Y y Z. 
Antes de pasar a la siguiente solicitud, una transacción de cliente plana completa la anterior. Como resultado, cada transacción visita el objeto del servidor en orden. 
Una transacción solo puede esperar un objeto a la vez cuando los servidores utilizan el bloqueo.

Limitaciones de una transacción plana:

• Todo el trabajo se pierde en caso de accidente.
• Solo se puede usar un DBMS a la vez.
• No es posible una reversión parcial.

TRANSACCIONES ANIDADAS:
Una transacción que incluye otras transacciones dentro de su punto de inicio y un punto final se conoce como transacciones anidadas. Entonces, el anidamiento de las transacciones se realiza en una transacción. Las transacciones anidadas aquí se denominan subtransacciones.
La transacción de nivel superior en una transacción anidada puede abrir subtransacciones, y cada subtransacción puede abrir más subtransacciones hasta cualquier profundidad de anidamiento.
 La transacción T de un cliente abre dos subtransacciones, T1 y T2, que acceden a objetos en los servidores X e Y, como se muestra en el siguiente diagrama. 
T1.1, T1.2, T2.1 y T2.2, que acceden a los objetos en los servidores M, N y P, son abiertos por las subtransacciones T1 y T2. 

Se realiza la ejecución simultánea de las subtransacciones que están al mismo nivel, en la estrategia de transacción anidada. Aquí, en el diagrama anterior, T1 y T2 invocan objetos en diferentes servidores y, por lo tanto, pueden ejecutarse en paralelo y, por lo tanto, son concurrentes.
T1.1, T1.2, T2.1 y T2.2 son cuatro subtransacciones. Estas subtransacciones también pueden ejecutarse en paralelo. 

Considere una transacción distribuida (T) en la que un cliente transfiere:

• Rs. 105 de la cuenta A a la cuenta C y
• Posteriormente, Rs. 205 de la cuenta B a la cuenta D.

Puede ser visto/pensado como:

Transaction T :
Start
Transfer Rs 105 from A to C : 
Deduct Rs 105 from A(withdraw from A) & Add Rs 105 to C(depopsit to C)
Transfer Rs 205 from B to D : 
Deduct Rs 205 from B (withdraw from B)& Add Rs 205 to D(depopsit to D)
End

Asumiendo :

1. La cuenta A está en el servidor X
2. La cuenta B está en el servidor Y, y
3. Las cuentas C y D están en el servidor Z.

La transacción T implica cuatro requests: 2 para depósitos y 2 para retiros. Ahora pueden tratarse como subtransacciones (T1, T2, T3, T4) de la transacción T.
Como se muestra en la figura a continuación, la transacción T está diseñada como un conjunto de cuatro transacciones anidadas: T1, T2, T3 y T4.

Ventaja: 
 el rendimiento es superior al de una sola transacción en la que se invocan cuatro operaciones una tras otra en secuencia. 

Entonces, la Transacción T se puede dividir en sub-transacciones como:

//Start the  Transaction
T = open transaction
//T1
openSubtransaction
a.withdraw(105);
//T2
openSubtransaction
b.withdraw(205);
//T3
openSubtransaction
c.deposit(105);
//T4
openSubtransaction
d.deposit(205);
//End the trsnaction
close Transaction

Rol del coordinador:
cuando se compromete la transacción distribuida, los servidores que están involucrados en la ejecución de la transacción, para una coordinación adecuada, deben poder comunicarse entre sí.
Cuando un cliente inicia una transacción, se envía una solicitud de «transacción abierta» a cualquier servidor coordinador. El coordinador contactado realiza el “openTransaction” y devuelve el identificador de la transacción al cliente.

Los identificadores de transacciones distribuidas deben ser únicos dentro del sistema distribuido. 
Una forma sencilla es generar un TID que contenga dos partes: el «identificador del servidor» (ejemplo: dirección IP) del servidor que lo creó y un número único para el servidor.
El coordinador que inició la transacción se convierte en el coordinador de la transacción distribuida y tiene la responsabilidad de abortarla o confirmarla. 

Cada servidor que administra un objeto al que accede una transacción es un participante en la transacción y proporciona un objeto que llamamos participante . Los participantes son responsables de trabajar junto con el coordinador para completar el proceso de compromiso. 

El coordinador cada vez, registra al nuevo participante en la lista de participantes. Cada participante conoce al coordinador y el coordinador conoce a todos los participantes. Esto les permite recopilar la información que se necesitará en el momento de la confirmación y, por lo tanto, trabajar en coordinación.