Atomic Commit
Qué es
Atomic Commit es el problema de decidir un único resultado final para una transacción que involucra varios participantes: todos confirman sus cambios, o todos los abortan. Un participante no puede terminar en commit mientras otro termina en abort para la misma transacción.
El «all-or-nothing» describe ese resultado dentro de una frontera definida. No significa que todos los nodos reciban la decisión al mismo instante, que cualquier lector vea una fotografía global consistente, ni que una llamada externa quede incluida por haber ocurrido durante la transacción.
Un protocolo de atomic commit coordina el desenlace. Two-Phase Commit es una implementación conocida; el concepto no depende de sus dos fases ni de un coordinador único. Gray y Lamport formalizan la estabilidad de las decisiones, la incompatibilidad entre resultados finales y la condición de que todos los participantes estén preparados para poder confirmar. Consensus on Transaction Commit, sección 2.
Qué problema resuelve
Dos cambios pueden ser correctos por separado y violar una regla cuando solo uno se confirma. Consumir un cupón en un store y reservar inventario en otro necesita una política para el caso «cupón consumido, inventario no reservado». Esa separación es una instancia de dual-write-problem.
Una transacción local ya ofrece una frontera conjunta para sus escrituras. Una transacción distribuida extiende la coordinación a varios dominios de commit. Que una base de datos esté físicamente distribuida no implica que la aplicación deba implementar el protocolo: puede recibir una abstracción transaccional que lo resuelva internamente.
Antes de agregar coordinación, conviene preguntar si los datos pueden compartir una transacción local o si el negocio admite una ejecución parcial recuperable. Es una decisión sobre invariantes y observaciones permitidas, no sobre cuántos servicios existen.
Contrato y participantes
Cada participante controla recursos y debe poder cumplir el resultado acordado. El conjunto de participantes tiene que quedar identificado por el protocolo; una escritura que nunca se incorpora no recibe sus garantías.
La coordinación necesita distinguir cuatro obligaciones:
- Acuerdo: no producir decisiones finales incompatibles entre participantes.
- Validez: no confirmar si alguno no puede comprometer su parte; aprobar por mayoría no autoriza a ignorar un recurso requerido.
- Estabilidad: conservar una decisión final ante reintentos y reinicios.
- Progreso: resolver las transacciones pendientes cuando se cumplen las condiciones de recuperación y comunicación del protocolo.
Un coordinador, cuando existe, reúne información y comunica el resultado. No reemplaza la capacidad transaccional de los participantes. Si el inventario promete que puede confirmar pero después descarta su estado necesario, la coordinación por sí sola no puede reconstruir esa promesa.
El modelo de fallo importa: caída de procesos con almacenamiento durable recuperable es distinto de pérdida permanente de logs o participantes que envían respuestas falsas. Una garantía formulada para el primer caso no cubre automáticamente los demás.
Commit, abort y recuperación
Commit vuelve definitivos los cambios incluidos. Abort descarta los cambios transaccionales pendientes. Ninguno borra un correo ya enviado ni cancela automáticamente una acción física ajena a los recursos participantes.
La decisión y su difusión son momentos diferentes. Puede existir un resultado durable conocido por algunos nodos mientras otros esperan información. La recuperación debe propagar esa misma decisión, no elegir otra porque un timeout venció.
| Ventana de fallo | Obligación de recuperación |
|---|---|
| Antes de que un recurso se comprometa a confirmar | Determinar si el intento puede abortarse según su estado y el protocolo. |
| Después de quedar listo, sin resultado conocido | Recuperar la decisión; conservar lo necesario para cumplirla. |
| Después de registrar commit, antes de notificar a todos | Reenviar commit a quienes todavía no lo aplicaron. |
| Después de aplicar el resultado, con respuesta perdida | Reconocer la transacción y responder sin repetir el efecto. |
Un timeout acredita incertidumbre o falta de progreso; no prueba abort. idempotency permite repetir una operación de recuperación sin cambiar otra vez su efecto. delivery-guarantees ayuda a separar «mensaje recibido» de «decisión durable aplicada».
Atomic commit y consenso
Consenso resuelve el acuerdo sobre un valor propuesto bajo un modelo de fallos. Atomic commit agrega una condición específica: el commit depende de la disposición de todos los participantes requeridos. No basta con elegir la palabra commit entre réplicas si un recurso no aceptó participar.
Las dos ideas se pueden combinar. Una coordinación replicada puede usar consenso para conservar decisiones disponibles ante ciertos fallos, mientras el protocolo transaccional sigue reuniendo la preparación de cada recurso. Esa relación no convierte 2PC en un algoritmo de consenso tolerante a fallos ni hace intercambiables votos de participantes y votos de réplicas. Gray y Lamport, secciones 3–4.
Ejemplo y límites
Una compra necesita reservar una unidad y consumir un cupón. Ambos stores participan en la misma transacción. Si el cupón está vencido, el resultado es abort y tampoco queda confirmada la reserva. Si ambos pueden comprometerse y se decide commit, la caída posterior del coordinador exige completar ese resultado al recuperarse.
Un lector que consulta ambos stores independientemente durante la difusión podría recibir vistas de momentos diferentes. Atomic commit no aporta por sí solo aislamiento global: el diseño necesita un contrato de lectura y control de concurrencia compatible con la regla que desea proteger.
Cuándo usarlo y alternativas
Es apropiado cuando el resultado conjunto es obligatorio, los recursos admiten participación transaccional y el costo de latencia, espera y recuperación es aceptable. Reducir la frontera a un store suele simplificarlo. Si el proceso dura horas o integra acciones no transaccionales, puede convenir redefinir el flujo con Saga o reservas mediante TCC, aceptando sus contratos distintos.
No garantiza disponibilidad incondicional durante una partición, ni efectos exactly-once fuera de sus recursos. La decisión de adoptar un protocolo requiere explicitar qué puede quedar pendiente, cuánto puede esperar el negocio y quién resolverá una transacción cuyo resultado aún no se conoce.