Commit de dos fases , la enciclopedia libre

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada. Busca fuentes: «Commit de dos fases» – noticias · libros · académico · imágenes Este aviso fue puesto el 12 de junio de 2011.

El protocolo de consolidación en dos fases, confirmación en dos fases^[1]​ o commit en dos fases, también conocido por las siglas 2PC (del inglés 2-phase commit), es un protocolo de consenso distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para consolidar a una transacción. Típicamente es usado en bases de datos distribuidas. El objetivo del protocolo es que todos los nodos realicen un commit de la transacción o la aborten.

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 de commit» o consolidación, en la cual el coordinador completa las transacciones a todos los demás participantes.

El algoritmo está basado en la existencia de un coordinador (al resto de nodos de la red se les llama participantes) y se divide en dos fases:^[2]​

• Fase de preparación de commit, en la cual el coordinador intenta preparar a todos para el commit contactando con todas las réplicas que participan, las cuales contestan si aceptan o abortan la transacción.

• Fase commit. Cuando todas las réplicas han respondido el coordinador busca los conflictos si los hay.
  • Si se detecta un conflicto en los mensaje enviados por las réplicas o una réplica indica que la transacción tiene que ser abortada, el acuerdo será abortado y el coordinador enviará un mensaje a todas las réplicas para que aborten la transacción.
  • Si no se detectan conflictos entonces el coordinador indica a todos realizar el commit. Después de que todas las réplicas realizan la consolidación, envían un mensaje de confirmación al coordinador.

El protocolo asume que:

• Hay almacenamiento estable en cada nodo con un sistema de registro de escritura por anticipado (implica que aunque el nodo se caiga estos datos nunca se pierden o corrompen).
• Los nodos no están siempre caídos. Si alguna réplica o el coordinador falla siempre el sistema falla.
• Dos nodos cualquiera pueden comunicarse unos con los otros. Esto no es muy restrictivo, ya que la comunicación de redes puede ser reenrutada normalmente.

Las primeras dos suposiciones son fuertes ya que si un nodo está totalmente destruido se pone en riesgo estas suposiciones.

1. El coordinador envía un mensaje-consulta a todos los participantes para hacer un commit.
2. Los participantes ejecutan la transacción hasta el punto donde ellos serán preguntados para la consolidación. Pueden escribir una entrada a su registro de deshacer (undo log) y una entrada a su registro de rehacer (redo log).
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.

Si el coordinador de esta página 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.

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

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

La mayor desventaja del protocolo de 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á bloqueado 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 se reciba un commit o un rollback. Si el coordinador está permanentemente caído, el participante quedará bloqueado indefinidamente, a menos que pueda obtener la decisión global de abortar una consolidación desde uno de los participantes.

Cuando el coordinador ha enviado una consulta para consolidación a los participantes, esto los bloqueará hasta que todos los participantes hayan enviado su decisión local al respecto. Más aún, si un participante está permanentemente caído, el coordinador no quedará bloqueado indefinidamente. Dado que el coordinador es el único en decidir si la decisión es una instrucción commit o una abort el bloqueo permanente puede evitarse introduciendo un temporizador. Si el coordinador no ha recibido todos los mensajes esperados cuando ha expirado el temporizador, entonces decidirá abortar la consolidación.

Además el protocolo presupone el buen funcionamiento del coordinador. Otra versión de este protocolo no necesita coordinador y permite que los clientes envíen los mensajes de preparación a todas las réplicas. Quitando al coordinador, el rendimiento del sistema debería mejorar. La desventaja es un incremento en la probabilidad de conflicto ya que múltiples clientes pueden sugerir distintos valores.^[2]​

El texto que sigue es una traducción defectuosa. Si quieres colaborar con Wikipedia, busca el artículo original y mejora esta traducción. Copia y pega el siguiente código en la página de discusión del autor de este artículo: {{subst:Aviso mal traducido|Commit de dos fases}} ~~~~

Una variante común del 2PC es el protocolo 2PC en árbol (T2PC). En esta variante el coordinador es la raíz de un árbol de comunicaciones, mientras los participantes son los 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 envíe 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 de consolidación de dos fases dinámico (dynamic two-phase commitment, D2PC) es una variante del T2PC sin coordinador predeterminado. Los mensajes acuerdo comienzan propagándose a todas las hojas, cada hoja cuando completa sus tareas a favor 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.

• commit atómico
• Consolidación o commit
• Consolidación en tres fases
• XA