Protocolo de confirmación de dos fases (gestión de transacciones distribuidas)

Considere que tenemos un conjunto de tiendas de comestibles donde el jefe de todas las tiendas quiere consultar sobre el inventario de desinfectantes disponibles en todas las tiendas para mover el inventario de una tienda a otra para equilibrar la cantidad de inventario de desinfectantes en todas las tiendas. La tarea es realizada por una sola transacción T que es el componente T _n en la n ^-ésima tienda y una tienda S ₀ corresponde a T ₀ donde se encuentra el gerente. La siguiente secuencia de actividades que realiza T son las siguientes:

a) El componente de la transacción ( T ) T ₀ se crea en el sitio central (oficina central).

b) T ₀ envía mensajes a todas las tiendas para ordenarles que creen componentes T _i .

c) Cada Ti ejecuta una consulta en la tienda “ _i ” para conocer la cantidad de desinfectantes disponibles en el inventario y reporta este número a T _o .

d) Cada tienda recibe instrucciones y actualiza el nivel de inventario y realiza el envío a otras tiendas donde lo requiera.

Pero hay algunos problemas que podemos enfrentar durante la ejecución de este proceso:

1) La propiedad de atomicidad puede violarse porque cualquier tienda (S _n ) puede recibir instrucciones dos veces para enviar el inventario que puede dejar la base de datos en un estado inconsistente. Para garantizar la propiedad de atomicidad, la Transacción T debe comprometerse en todos los sitios o debe abortar en todos los sitios. 

2) Sin embargo, el sistema en la tienda T _n puede colapsar, y T _n nunca recibe las instrucciones de T ₀ debido a cualquier problema de red y cualquier otra razón. Entonces surge la pregunta de qué sucederá con la transacción distribuida que se ejecuta, ya sea que se cancele o se confirme. ¿Se recupera o no?

Este protocolo está diseñado con la intención central de resolver los problemas anteriores. Considere que tenemos varias bases de datos distribuidas que funcionan desde diferentes servidores (sitios), digamos S ₁ , S ₂ , S ₃ , ….S _n . Donde cada S _i realizado para mantiene un registro de registro separado de todas las actividades correspondientes y la transición T también se ha dividido en las subtransacciones T ₁ , T ₂ , T ₃ , …., T _n y cada T _i se asignan a S _i .Todo esto lo mantiene un administrador de transacciones separado en cada S _i . Asignamos a cualquier sitio como Coordinador.  

Algunos puntos a considerar con respecto a este protocolo:

a) En una confirmación de dos fases, asumimos que cada sitio registra acciones en ese sitio, pero no hay un registro global. 

b) El coordinador (C _i ), juega un papel vital en la confirmación de si la transacción distribuida abortaría o se comprometería.

c) En este protocolo se hacen mensajes para enviar entre el coordinador (C _i ) y los otros sitios. A medida que se envía cada mensaje, sus registros se anotan en cada sitio de envío, para ayudar en la recuperación en caso de que sea necesario.

Las dos fases de este protocolo son las siguientes:

a) En primer lugar, el coordinador (C _i ) coloca un registro de registro <Preparar T> en el registro de registro en su sitio.

b) Luego, el coordinador (C _i ) envía un mensaje Prepare T a todos los sitios donde se ejecutó la transacción (T).

c) El administrador de transacciones en cada sitio al recibir este mensaje Prepare T decide si comprometer o abortar su componente (porción) de T. El sitio puede demorar si el componente aún no ha completado su actividad, pero eventualmente debe enviar una respuesta.

d) Si el sitio no desea comprometerse, debe escribir en el registro <sin T>, y el administrador de transacciones local envía un mensaje de cancelación de T a C _i .

e) Si el sitio quiere comprometerse, debe escribir en el registro <ready T> , y el administrador de transacciones local envía un mensaje ready T a C _i . Una vez que se envía el mensaje T listo en C _i , nada puede evitar que comprometa su parte de la transacción T, excepto el Coordinador (C _i ).

La segunda fase comenzó como la respuesta abortar T o confirmar T recibida por el coordinador (C _i ) de todos los sitios que están ejecutando en colaboración la transacción T. Sin embargo, es posible que algún sitio no responda; puede estar caído o ha sido desconectado por la red. En ese caso, después de un tiempo de espera adecuado, se dará un tiempo de espera, después de ese tiempo se tratará el sitio como si hubiera enviado abortar T . El destino de la transacción depende de los siguientes puntos:

a) Si el coordinador recibe T listo de todos los sitios participantes de T, entonces decide cometer T . Luego, el coordinador escribe en el registro de su sitio <Commit T>  y envía un mensaje commit T a todos los sitios involucrados en T. 

b) Si un sitio recibe un mensaje de confirmación T , confirma el componente de T en ese sitio y lo escribe en los registros de registro <Commit T> .

c) Si un sitio recibe el mensaje abortar T , aborta T y escribe el registro de registro <Abortar T>.

d) Sin embargo, si el coordinador ha recibido el aborto T de uno o más sitios, registra <Abort T> en su sitio y luego envía mensajes de aborto T a todos los sitios involucrados en la transacción T.

Desventajas :

a) La principal desventaja del protocolo de compromiso de dos fases se presenta cuando la falla del sitio del coordinador puede resultar en un bloqueo, por lo que la decisión de comprometer o cancelar la Transacción (T) puede tener que posponerse hasta que el coordinador se recupere.

b) Problema de bloqueo : considere un escenario, si una Transacción (T) mantiene bloqueos en elementos de datos de sitios activos, pero en medio de la ejecución, si el coordinador falla y los sitios activos no mantienen un registro adicional excepto <readt T> como <abortar> o <comprometer>. Por lo tanto, se vuelve imposible determinar qué decisión se ha tomado (si <commit> /<abort> ). Entonces, en ese caso, la decisión final se retrasa hasta que el Coordinador sea restablecido o arreglado. En algunos casos, esto puede tardar un día o muchas horas en restaurarse y durante este período de tiempo, los elementos de datos bloqueados permanecen inaccesibles para otras transacciones (T _i ).Este problema se conoce como problema de bloqueo.