Confirmación atómica

En el campo de la informática , una confirmación atómica es una operación que aplica un conjunto de cambios distintos como una sola operación. Si los cambios se aplican, se dice que la confirmación atómica ha tenido éxito. Si se produce un fallo antes de que la confirmación atómica pueda completarse, todos los cambios realizados en ella se revierten. Esto garantiza que el sistema siempre quede en un estado consistente. La otra propiedad clave del aislamiento proviene de su naturaleza como operaciones atómicas . El aislamiento garantiza que solo se procese una confirmación atómica a la vez. Los usos más comunes de las confirmaciones atómicas se encuentran en los sistemas de bases de datos y los sistemas de control de versiones .

El problema con las confirmaciones atómicas es que requieren coordinación entre múltiples sistemas. ^{[ 1 ]} Dado que las redes informáticas son servicios poco fiables, esto significa que ningún algoritmo puede coordinarse con todos los sistemas, como se demuestra en el Problema de los Dos Generales . A medida que las bases de datos se vuelven cada vez más distribuidas, esta coordinación aumentará la dificultad de realizar confirmaciones verdaderamente atómicas. ^{[ 2 ]}

Las confirmaciones atómicas son esenciales para las actualizaciones de datos en varios pasos. Esto se puede mostrar claramente en un ejemplo sencillo de una transferencia de dinero entre dos cuentas corrientes. ^{[ 3 ]}

Este ejemplo se complica por una transacción para verificar el saldo de la cuenta Y durante una transferencia de 100 dólares de la cuenta X a la cuenta Y. Para empezar, primero se retiran 100 dólares de la cuenta X. Luego, se añaden 100 dólares a la cuenta Y. Si la operación no se completa como una única confirmación atómica, podrían surgir varios problemas. Si el sistema falla a mitad de la operación, después de retirar el dinero de X y antes de añadirlo a Y, los 100 dólares simplemente desaparecen. Otro problema surge si se verifica el saldo de Y antes de añadir los 100 dólares; en ese caso, se informará un saldo incorrecto para Y.

Con las confirmaciones atómicas, ninguno de estos casos es posible. En el primer caso, si el sistema falla, la confirmación atómica se revertiría y el dinero se devolvería a X. En el segundo caso, la solicitud del saldo de Y no puede realizarse hasta que la confirmación atómica se haya completado por completo.

Las confirmaciones atómicas en los sistemas de bases de datos cumplen dos de las propiedades clave de ACID , ^{[ 4 ]} atomicidad y consistencia . La consistencia solo se logra si cada cambio en la confirmación atómica es consistente.

Como se muestra en el ejemplo, las confirmaciones atómicas son fundamentales para las operaciones de varios pasos en las bases de datos. Debido al diseño moderno del hardware del disco físico donde reside la base de datos, las confirmaciones verdaderamente atómicas no pueden existir. El área más pequeña en la que se puede escribir en el disco se conoce como sector. Una sola entrada de la base de datos puede abarcar varios sectores diferentes. Solo se puede escribir en un sector a la vez. Este límite de escritura es la razón por la que las confirmaciones verdaderamente atómicas no son posibles. Después de que las entradas de la base de datos en memoria se han modificado, se ponen en cola para escribirse en el disco. Esto significa que los mismos problemas identificados en el ejemplo se han repetido. Cualquier solución algorítmica a este problema seguirá encontrándose con el problema de los dos generales. El protocolo de confirmación de dos fases y el protocolo de confirmación de tres fases intentan resolver este y algunos de los otros problemas asociados con las confirmaciones atómicas.

El protocolo de confirmación en dos fases requiere que un coordinador mantenga toda la información necesaria para recuperar el estado original de la base de datos si algo sale mal. Como su nombre indica, hay dos fases: votación y confirmación .

Durante la fase de votación, cada nodo escribe los cambios de la confirmación atómica en su propio disco. A continuación, los nodos informan de su estado al coordinador. Si algún nodo no informa al coordinador o se pierde su mensaje de estado, el coordinador asume que la escritura del nodo ha fallado. Una vez que todos los nodos han informado al coordinador, comienza la segunda fase.

Durante la fase de confirmación, el coordinador envía un mensaje de confirmación a cada uno de los nodos para que lo registren en sus registros individuales. Hasta que este mensaje se agregue al registro de un nodo, cualquier cambio realizado se registrará como incompleto. Si alguno de los nodos informa un fallo, el coordinador enviará un mensaje de reversión. Esto eliminará cualquier cambio que los nodos hayan escrito en el disco. ^{[ 5 ] [ 6 ]}

El protocolo de confirmación en tres fases busca solucionar el principal problema del protocolo de confirmación en dos fases, que se produce cuando un coordinador y otro nodo fallan simultáneamente durante la fase de confirmación, sin que ninguno pueda determinar qué acción debe realizarse. Para resolver este problema, se añade una tercera fase al protocolo. La fase de preparación para la confirmación se lleva a cabo después de la fase de votación y antes de la fase de confirmación .

En la fase de votación , similar a la confirmación en dos fases, el coordinador solicita que cada nodo esté listo para confirmar. Si algún nodo falla, el coordinador agotará el tiempo de espera mientras espera a que el nodo fallido responda. En ese caso, el coordinador envía un mensaje de cancelación a todos los nodos. Se realizará la misma acción si alguno de los nodos devuelve un mensaje de error.

Tras recibir mensajes de confirmación de cada nodo en la fase de votación, comienza la fase de preparación para la confirmación . Durante esta fase, el coordinador envía un mensaje de preparación a cada nodo. Cada nodo debe confirmar la recepción del mensaje y responder. Si no se recibe ninguna respuesta o si algún nodo indica que no está preparado, el coordinador envía un mensaje de cancelación. Cualquier nodo que no reciba un mensaje de preparación antes de que expire el tiempo de espera cancelará la confirmación.

Una vez que todos los nodos hayan respondido al mensaje de preparación, comienza la fase de confirmación . En esta fase, el coordinador envía un mensaje de confirmación a cada nodo. Cuando cada nodo recibe este mensaje, realiza la confirmación propiamente dicha. Si el mensaje de confirmación no llega a un nodo debido a que se perdió o a que el coordinador falló, realizará la confirmación si expira el tiempo de espera. Si el coordinador falla al recuperarse, enviará un mensaje de confirmación a cada nodo. ^{[ 7 ]}

En los libros de contabilidad distribuidos descentralizados, donde los nodos operan en un entorno adverso (bizantino), los protocolos de confirmación estándar de dos fases introducen riesgos de centralización y puntos únicos de fallo. Para abordar esto, los sistemas masivamente fragmentados han adoptado protocolos de confirmación "entrelazados". Como se analiza en investigaciones recientes sobre bases de datos, estos protocolos logran la atomicidad al garantizar que la confirmación de una transacción en un fragmento dependa criptográficamente de su confirmación en todos los demás fragmentos relacionados. Este enfoque fusiona eficazmente las vistas de consenso entre particiones sin requerir un coordinador central, mitigando los problemas de vivacidad inherentes a los mecanismos de bloqueo tradicionales. ^{[ 8 ]}

Las confirmaciones atómicas son una característica común del software de control de versiones y cruciales para mantener un estado consistente en el repositorio. ^{[ 9 ]} La mayoría del software de control de versiones no aplicará ninguna parte de una confirmación que falle. Las excepciones notables son CVS , VSS e IBM Rational ClearCase (cuando está en modo UCM). ^{[ 10 ]}

Por ejemplo, si el software de control de versiones encuentra un conflicto de fusión que no se puede resolver automáticamente, ninguna parte del conjunto de cambios se fusiona. En su lugar, el desarrollador tiene la oportunidad de revertir sus cambios o resolver el conflicto manualmente.

Esto evita que todo el proyecto entre en un estado defectuoso debido a un conjunto de cambios aplicado parcialmente, donde un archivo de una confirmación se confirma correctamente, pero otro archivo con cambios dependientes falla. ^{[ 11 ]}

Las confirmaciones atómicas también pueden referirse a la capacidad de realizar cambios simultáneamente en múltiples proyectos utilizando software de control de versiones en una sola operación, utilizando una estrategia de desarrollo de software de control de versiones conocida como monorepo . ^{[ 9 ]}

Al utilizar sistemas de control de versiones, una convención común es usar confirmaciones pequeñas. A estas se las denomina a veces confirmaciones atómicas, ya que (idealmente) solo afectan a un único aspecto del sistema. Estas confirmaciones atómicas permiten una mayor comprensión, un menor esfuerzo para revertir los cambios y una identificación de errores más sencilla. ^{[ 12 ]}

La mayor comprensibilidad se debe al pequeño tamaño y la naturaleza específica de la confirmación. Es mucho más fácil entender qué se ha cambiado y el razonamiento detrás de los cambios si uno solo busca un tipo de cambio. Esto cobra especial importancia al realizar cambios de formato en el código fuente. Si se combinan cambios de formato y funcionales, resulta muy difícil identificar cambios útiles. Imagínese que si el espaciado en un archivo cambia de tabulaciones a tres espacios, todas las tabulaciones del archivo aparecerán como modificadas. Esto se vuelve crítico si también se realizan algunos cambios funcionales, ya que un revisor podría simplemente no ver los cambios funcionales. ^{[ 13 ] [ 14 ]}

Si solo se realizan confirmaciones atómicas, resulta mucho más sencillo identificar las que introducen errores. No es necesario revisar cada confirmación para determinar si fue la causa del error; solo se deben examinar las que afectan a esa funcionalidad. Si se desea revertir el error, las confirmaciones atómicas simplifican aún más el proceso. En lugar de tener que volver a la revisión problemática y eliminar los cambios manualmente antes de integrar cualquier cambio posterior, el desarrollador puede simplemente revertir los cambios de la confirmación identificada. Esto también reduce el riesgo de que un desarrollador elimine accidentalmente cambios no relacionados que se encontraban en la misma confirmación.

Las confirmaciones atómicas también permiten revisar fácilmente las correcciones de errores si solo se confirma una a la vez. En lugar de tener que revisar varios archivos potencialmente no relacionados, el revisor solo debe revisar los archivos y cambios que afectan directamente al error que se está corrigiendo. Esto también significa que las correcciones de errores se pueden empaquetar fácilmente para su prueba, ya que solo los cambios que solucionan el error están incluidos en la confirmación.

• Protocolo de compromiso en dos fases
• Protocolo de compromiso de tres fases
• Confirmar (gestión de datos)
• Operación atómica