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 se aplican los cambios, se dice que la confirmación atómica se realizó correctamente. Si ocurre una falla antes de que se pueda completar la confirmación atómica, todos los cambios completados en la confirmación atómica se revierten. Esto garantiza que el sistema siempre se mantenga 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 sistemas de bases de datos y sistemas de control de versiones .
El problema con los compromisos atómicos es que requieren coordinación entre múltiples sistemas. [1] Como las redes informáticas son servicios poco confiables, 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 distribuyan cada vez más, esta coordinación aumentará la dificultad de realizar confirmaciones verdaderamente atómicas. [2]
Las confirmaciones atómicas son esenciales para las actualizaciones de datos de 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 con una transacción para verificar el saldo de la cuenta Y durante una transacción para transferir 100 dólares de la cuenta X a Y. Para comenzar, los primeros 100 dólares se eliminan de la cuenta X. En segundo lugar, se agregan 100 dólares a la cuenta Y. Si toda la operación no se completa como una confirmación atómica, entonces podrían ocurrir varios problemas. Si el sistema falla en mitad de la operación, después de retirar el dinero de X y antes de añadirlo a Y, entonces 100 dólares simplemente han desaparecido. Otro problema es que si se verifica el saldo de Y antes de agregar los 100 dólares, se informará el saldo incorrecto de Y.
Con los compromisos atómicos ninguno de estos casos puede suceder, en el primer caso de falla del sistema, el compromiso atómico se revertirá y el dinero se devolverá a X. En el segundo caso, la solicitud del saldo de Y no puede ocurrir hasta que el compromiso atómico El compromiso está completamente completado.
Las confirmaciones atómicas en los sistemas de bases de datos cumplen dos de las propiedades clave de ACID , [4] atomicidad y consistencia . La coherencia sólo se logra si cada cambio en el compromiso atómico es coherente.
Como se muestra en el ejemplo, las confirmaciones atómicas son fundamentales para las operaciones de varios pasos en bases de datos. Debido al diseño de hardware moderno del disco físico en el que reside la base de datos, no pueden existir verdaderas confirmaciones atómicas. El área más pequeña en la que se puede escribir en el disco se conoce como sector. Una sola entrada de base de datos puede abarcar varios sectores diferentes. Sólo se puede escribir un sector a la vez. Este límite de escritura es la razón por la que no son posibles verdaderas confirmaciones atómicas. Una vez modificadas las entradas de la base de datos en la memoria , se ponen en cola para escribirse en el disco. Esto significa que han vuelto a ocurrir los mismos problemas identificados en el ejemplo. Cualquier solución algorítmica a este problema seguirá topá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 de 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 compromiso .
Durante la fase de votación , cada nodo escribe los cambios en el compromiso atómico en su propio disco. Luego, los nodos informan su estado al coordinador. Si algún nodo no informa al coordinador o su mensaje de estado se pierde, el coordinador asume que la escritura del nodo falló. 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 registrarlo 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 informó una falla, 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 de tres fases busca eliminar el problema principal con el protocolo de confirmación de dos fases, que ocurre si un coordinador y otro nodo fallan al mismo tiempo durante la fase de confirmación y ninguno puede decir qué acción debe ocurrir. Para solucionar este problema se añade una tercera fase al protocolo. La fase de preparación para el compromiso ocurre después de la fase de votación y antes de la fase de compromiso .
En la fase de votación , similar al compromiso de dos fases, el coordinador solicita que cada nodo esté listo para comprometerse. Si algún nodo falla, el coordinador expirará mientras espera el nodo fallido. Si esto sucede, el coordinador envía un mensaje de aborto a cada nodo. Se emprenderá la misma acción si alguno de los nodos devuelve un mensaje de error.
Al recibir mensajes de éxito de cada nodo en la fase de votación, comienza la fase de preparación para comprometerse . Durante esta fase, el coordinador envía un mensaje de preparación a cada nodo. Cada nodo debe acusar recibo del mensaje de preparación y responder. Si se pierde alguna respuesta o algún nodo informa 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 aborta 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 real. Si el mensaje de confirmación no llega a un nodo debido a que se perdió o el coordinador falla, realizarán la confirmación si expira el tiempo de espera. Si el coordinador falla durante la recuperación, enviará un mensaje de confirmación a cada nodo. [7]
Las confirmaciones atómicas son una característica común del software de control de versiones y son cruciales para mantener un estado coherente en el repositorio. [8] 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án en modo UCM). [9]
Por ejemplo, si el software de control de versiones encuentra un conflicto de fusión que no se puede resolver automáticamente, entonces no se fusiona ninguna parte del conjunto de cambios . En cambio, el desarrollador tiene la oportunidad de revertir sus cambios o resolver manualmente el conflicto.
Esto evita que todo el proyecto entre en un estado roto debido a un conjunto de cambios aplicado parcialmente, donde un archivo de una confirmación se confirma con éxito, pero otro archivo con cambios dependientes falla. [10]
Las confirmaciones atómicas también pueden referirse a la capacidad de realizar cambios simultáneamente en varios 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 . [8]
Cuando se utilizan sistemas de control de revisiones, una convención común es utilizar pequeñas confirmaciones. A veces se les conoce como confirmaciones atómicas, ya que (idealmente) solo afectan un único aspecto del sistema. Estas confirmaciones atómicas permiten una mayor comprensibilidad, menos esfuerzo para revertir los cambios y una identificación de errores más sencilla. [11]
La mayor comprensibilidad proviene del tamaño pequeño y la naturaleza enfocada del compromiso. Es mucho más fácil entender qué ha cambiado y el razonamiento detrás de los cambios si sólo se busca un tipo de cambio. Esto resulta especialmente importante al realizar cambios de formato en el código fuente. Si se combinan los cambios de formato y funcionales, resulta muy difícil identificar cambios útiles. Imagínese si el espaciado en un archivo se cambia de usar tabulaciones a tres espacios, cada pestaña del archivo se mostrará como cambiada. Esto se vuelve crítico si también se realizan algunos cambios funcionales, ya que es posible que un revisor simplemente no vea los cambios funcionales. [12] [13]
Si solo se realizan confirmaciones atómicas, las confirmaciones que introducen errores se vuelven mucho más sencillas de identificar. No es necesario revisar cada confirmación para ver si fue la causa del error, solo se deben examinar las confirmaciones que tratan con esa funcionalidad. Si se va a revertir el error, las confirmaciones atómicas nuevamente simplifican mucho el trabajo. En lugar de tener que volver a la revisión infractora y eliminar los cambios manualmente antes de integrar cambios posteriores; el desarrollador puede simplemente revertir cualquier cambio en 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 única corrección de errores a la vez. En lugar de tener que verificar varios archivos potencialmente no relacionados, el revisor solo debe verificar los archivos y cambios que impactan directamente en el error que se está corrigiendo. Esto también significa que las correcciones de errores se pueden empaquetar fácilmente para realizar pruebas, ya que solo los cambios que corrigen el error están en la confirmación.
{{cite web}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )Una característica que CVS no tiene, y que a muchos equipos les gusta, son las confirmaciones atómicas. Esta característica garantiza que mientras una persona realiza cambios en el repositorio, nadie más puede hacerlo. Por lo tanto, cada confirmación es un proceso separado y el repositorio nunca se encuentra en un estado en el que tenga archivos que no coincidan.