Aquí hay una situación en la que 2PC no está vivo en presencia de una sola falla.
Si el líder _y_ un participante fallara después de que se haya enviado “preparación” a todos los participantes, pero antes de que se haya enviado cualquier mensaje de “confirmación”, el protocolo se detendrá. Para ver por qué, considere lo que debe hacer un nuevo líder, quizás elegido después de que haya transcurrido un tiempo de espera, con la propuesta en curso. Primero debe pedir a todos los participantes en vivo el resultado de la última propuesta. Suponiendo que todos digan ‘ok to commit’, ¿qué debe hacer el líder sin una respuesta del último participante? El líder no puede saber qué responderá el participante fallido, y sin eso no puede saber si cometer o abortar.
En particular, el líder no puede saber si sucedieron las siguientes cosas: el participante fallido respondió ‘ok para comprometerse’ al líder anterior, y el líder anterior luego envió un mensaje ‘commit’ al participante fallido. Luego, el participante fallido tenía una nueva vista del estado del sistema, y es posible que ya haya comunicado esa vista a un cliente externo (p. Ej., Sirvió una lectura de DB). Entonces el líder no puede abortar de manera segura por defecto.
- ¿Es útil tener un firewall doméstico dedicado?
- ¿Cómo funciona el DHCP?
- ¿Cuáles son los diferentes modos de enlace de red en Linux?
- Cómo no quedar atrapado al descargar una gran cantidad de datos en una red de área local
- ¿De qué depende físicamente una conexión de red? Si la tierra explotara, ¿qué pasaría con Internet?
Pero de manera similar, si el participante fallido iba a abortar, y el antiguo líder ya había comenzado a abortar la propuesta, el nuevo líder no puede comprometer la propuesta pendiente con un argumento similar. Por lo tanto, el nuevo líder no puede tomar una decisión segura sobre qué hacer con el protocolo sobresaliente, por lo que no tiene que hacer nada.
