Commit de tres fases

En redes de ordenadores y Base de datos, el protocolo de commit de tres fases (3PC) es un algoritmo distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para hacer commit a una transacción. Al contrario del protocolo de commit de dos fases (2PC), el 3PC no es bloqueante. Específicamente, 3PC situa un límite superior de la cantidad de tiempo requerido antes de que una transacción haga el commit o aborte. Esta propiedad asegura que si una transacción dada esta intentando hacer commit vía 3PC y mantiene algún recurso bloqueado (locking), puede liberar los bloqueos después del límite de tiempo (timeout).

El protocolo 3PC fue originalmente descrito por Dale Skeen y Michael Sonebraker en su artículo "A Formal Model of Crash Recovery in a Distributed System." En este trabajo, ellos modelaron 2PC como un sistema de "máquina de estado finito no determinística" y probaron que no es resistente a un fallo aleatorio de un único nodo. La observación básica es que en 2PC, mientras un nodo está en el estado de "preparado para commit", el otro puede estar tanto en el estado de "commit" como en el de "abortar". A partir de este análisis, desarrollaron 3PC para evitar dichos estados y por tanto ser resistente a dichos fallos.

Descripción del protocolo

Para describir el protocolo usaremos una terminología similar a la utilizada en el protocolo de commit de dos fases. Por tanto tenemos un único nodo coordinador liderando la transacción y un grupo de uno o mas participantes que son dirigidos por el coordinador.

Coordinador

Diagrama de estados del coordinador

1. El coordinador recibe una solicitud de transacción. Si hay un fallo en este momento, el coordinador aborta la transaccion (en cuanto se recupere hace la transición por fallo). En caso contrario, el coordinador envía un mensaje de inicio de transacción a los participantes y cambia al estado de en espera.
2. Si hay un fallo, timeout, o si el coordinador recibe un mensaje de no se iniciará la transacción en el estado de en espera, el coordinador aborta la transacción y envía un mensaje de abortar a todos los participantes. En caso contrario el coordinador recibirá mensajes de puede comenzar la transacción desde todos los participantes dentro de la ventana de tiempo, y por tanto envía mensajes de commit a todos los participantes y cambia al estado de preparados.
3. Si el coordinador falla en el estado de preparados, cambiará al estado de commit. Sin embargo si el coordinador se pasa de tiempo mientras espera un un reconocimiento de un participante, abortará la transacción. En el caso de que todos los reconocimientos son recibidos, el coordinador cambia también al estado de commit.

Participante

Diagrama de estados del participante

1. El participante recibe un mensaje de inicio de transacción desde el coordinador. Si el participante está de acuerdo, contesta con un mensaje de se iniciará la transacción(OK) al coordinador, y cambia al estado de en espera. En caso contrario envía un mensaje de no se iniciará la transacción y aborta. Si hay un fallo, cambia al estado de abortar.
2. En el estado de en espera, si el participante recibe un mensaje de abortar desde el coordinador, tiene un fallo, o se pasa de tiempo esperando un commit, aborta. Si el participante recibe un mensaje de preparado, contesta con un mensaje ack y pasa al estado de pendiente.
3. Una vez en el estado de pendiente, al recibir un mensaje de commit, hace el commit. En caso de fallo o de timeout también hace commit.

Desventajas

La principal desventaja de este algoritmo es que no puede recuperarse en el caso de que la red sea segmentada de alguna forma. Dicho de otra forma, si la red de nodos fueran separadas en dos mitades, cada mitad continuaría a su aire.

Véase también

• commit atómico
• Commit
• Commit de dos fases