Commit de dos fases

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|Commit de dos fases}} ~~~~

En interconexión de computadores y Base de datos, el protocolo commit de dos fases es un algoritmo distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para hacer commit a una transacción. El resultado del protocolo en que todos los nodos realizan commit de la transacción o abortan, incluso en el caso de fallos en la red o fallos en nodos. Sin embargo, de acuerdo con el trabajo de Dale Skeen y Michael Stonebraker, el protocolo no manejará más que el fallo de un sitio aleatorio a la vez. Las dos fases del algoritmo son la fase de petición de commit, en el cual el coordinador intenta preparar a todos los demás, y la fase commit, en la cual el coordinador completa las transacciones a todos los demás participantes.

Generalidades

El protocolo funciona de la manera siguiente: un nodo es llamado el coordinator, el cual es el site maestro, y el resto de los nodos en la red son designados los participantes. El protocolo asume que hay almacenamiento estable en cada nodo con un sistema de log write-ahead, que los nodos no están siempre caídos, que los datos en el log write-ahead nunca se han perdido o corrompido en una caída(crash), y que dos nodos cualquiera pueden comunicarse unos con los otros. La última suposición no es muy restrictiva, ya que la comunicación de redes puede ser re-enrutada normalmente. Las primeras dos suposiciones son mucho más fuertes; si un nodo está totalmente destruido entonces los datos pueden perderse.

El protocolo es iniciado por el Coordinador después de alcanzar el último paso de la transacción. Los Participantes entonces responden con un mensaje de acuerdo o un mensaje abortar dependiendo del éxito.

Algoritmo básico

Fase de petición del Commit

1. El coordinador envía un mensaje consulta para commit a todos los participantes.
2. Los participantes ejecutan la transacción hasta el punto donde ellos serán preguntados para realizar commit. Ellos pueden escribir una entrada a su log undo(log de deshacer) y una entrada a su log redo(log de rehacer).
3. Cada participante responde con un mensaje acuerdo si la transacción tuvo éxito, o un mensaje abortar si falló la transacción.
4. El Coordinador espera hasta que tenga un mensaje de cada participante.

Fase Commit

Éxito

Si el coordinador recibió un mensaje acuerdo de todos los participantes durante la fase de petición de commit:

1. El coordinador envía un mensaje commit a todos los participantes.
2. Cada participante completa la operación, y libera todos los bloqueos y recursos mantenidos durante la transacción.
3. Cada participante envía un reconocimiento(ack) al coordinador.
4. El coordinador completa la transacción cuando ha recibido todos los reconocimientos.

Fracaso

Si algún participante envió un mensaje abortar durante la fase de petición de commit:

1. El coordinador envía un mensaje rollback a todos los participantes.
2. Cada participante deshace la transacción usando el log undo(log de deshacer), y libera los recursos y bloqueos mantenidos durante la transacción.
3. Cada participante envía un reconocimiento(ack) al coordinador.
4. El Coordinador completa la transacción cuando han sido recibidos los reconocimientos.

Desventajas

La mayor desventaja del protocolo commit en dos fases es el hecho de que es un protocolo bloqueante. Un nodo estará bloqueado mientras esté esperando un mensaje. Esto significa que otros procesos compiten por los bloqueos de recursos mantenidos por los procesos bloqueados tendrán que esperar a que los bloqueos sean liberados. Un nodo individual continuará incluso si otros sites han fallado. Si el coordinador falla permanentemente, algunos participantes nunca resolverán sus transacciones. Esto tiene el efecto de que los recursos están siempre comprometidos. El algoritmo puede bloquear indefinidamente de la siguiente forma: si un participante ha enviado un mensaje acuerdo al coordinador, se bloqueará hasta que un commit o rollback sea recibido. Si el coordinador está permanentemente caído, el participante bloqueará indefinidamente, a menos que pueda obtener la decisión global commit/abort desde uno de los participantes. Cuando el coordinador ha enviado "consulta para commit" a los participantes, esto bloqueará hasta que todos los participantes hayan enviado su decisión local. Más aún, si un participante está permanentemente caído, el coordinador no bloqueará indefinidamente: Dado que el coordinador es el único en decidir si la decisión es 'commit' o 'abort' el bloqueado permanente puede evitarse introduciendo un timeout: Si el coordinador no ha recibido todos los mensajes esperados cuando ha pasado el timeout decidirá 'abortar'. Este comportamiento conservador del protocolo es otra desventaja: Se predispone al caso de aborto en lugar del caso completo.

Se ha realizado muchas investigaciones de base de datos sobre las formas en las cuales obtener la mayoría de los beneficios del protocolo commit de dos fases sin los costes.

Protocolo commit de dos fases en árbol

Una variante común del 2PC(2-Phase Commit) en un sistema distribuido es el Protocolo Tree 2PC(en árbol). En esta variante el coordinador es la raíz ("top") de un árbol de comunicaciones, mientras los participantes son los otros nodos. Los mensajes desde el coordinador son propagados "hacia abajo" en el árbol, mientras los mensajes al coordinador son "recolectados" por un participante desde todos los participantes que hay debajo, antes de que esto envie el mensaje apropiado "hacia arriba" por el árbol (excepto con un mensaje "abortar", el cual es propagado "hacia arriba" inmediatamente hasta que se reciba, o si este participante decide abortar).

El protocolo commit de dos fases dinámico (Dynamic two-phase commitment, D2PC) es una variante del Tree 2PC sin coordinador predeterminado. Los mensajes Acuerdo comienzan propagándose a todas las hojas, cada hoja cuando completa sus tareas a favor(¿behalf?) de la transacción, y el coordinador es determinado dinámicamente por los mensajes de acuerdo en carrera, en los lugares donde se concentran/colisionan. Ellos se concentran/colisionan en un nodo árbol de la transacción, o en un cable. En el último caso uno de los nodos que están al extremo del cable es elegido como un coordinador (cualquier nodo). D2PC es óptimo respecto al tiempo (entre todas las instancias de un árbol de transacción específico, y cualquier implementación de protocolo específica Tree 2PC; todas las instancias tienen el mismo árbol; cada instancia tiene un nodo diferente como coordinador): esto realiza commit al coordinador y cada participante en el tiempo mínimo posible, permitiendo la liberación temprana de los recursos bloqueados.

Véase también

• commit atómico
• Commit
• Commit de tres fases
• XA