ÁCIDO

Las transacciones suelen estar compuestas por múltiples sentencias . La atomicidad garantiza que cada transacción se trate como una "unidad" única, que se completa con éxito o falla por completo: si alguna de las sentencias que la componen no se completa, la transacción entera falla y la base de datos permanece inalterada. Un sistema atómico debe garantizar la atomicidad en todas y cada una de las situaciones, incluyendo cortes de energía, errores y fallos del sistema. ^{[ 6 ]} Una garantía de atomicidad evita que las actualizaciones de la base de datos se produzcan solo parcialmente, lo que puede causar mayores problemas que rechazar toda la serie directamente. En consecuencia, otro cliente de la base de datos no puede observar que la transacción esté en curso. En un momento dado, aún no ha ocurrido, y en el siguiente, ya se ha completado (o no ha ocurrido nada si la transacción se canceló en curso).

La consistencia garantiza que una transacción solo pueda llevar la base de datos de un estado consistente a otro, preservando las invariantes de la base de datos : cualquier dato escrito en la base de datos debe ser válido según todas las reglas definidas, incluidas las restricciones , las cascadas , los disparadores y cualquier combinación de estos. Esto evita la corrupción de la base de datos por una transacción ilegal. Un ejemplo de invariante de la base de datos es la integridad referencial , que garantiza la relación entre la clave primaria y la clave externa . ^{[ 7 ]}

Las transacciones suelen ejecutarse simultáneamente (por ejemplo, varias transacciones leen y escriben en una tabla al mismo tiempo). El aislamiento garantiza que la ejecución concurrente de transacciones deje la base de datos en el mismo estado que se habría obtenido si las transacciones se hubieran ejecutado secuencialmente. El aislamiento es el objetivo principal del control de concurrencia ; dependiendo del nivel de aislamiento utilizado, los efectos de una transacción incompleta podrían no ser visibles para otras transacciones. ^{[ 8 ]}

La durabilidad garantiza que, una vez confirmada una transacción, permanecerá confirmada incluso en caso de fallo del sistema (por ejemplo, un corte de energía o un fallo del sistema). Esto generalmente significa que las transacciones completadas (o sus efectos) se registran en memoria no volátil . ^{[ 9 ]}

La atomicidad garantiza que una serie de operaciones de base de datos en una transacción atómica se ejecutarán todas (una operación exitosa) o ninguna (una operación fallida). La serie de operaciones no puede separarse ejecutando solo algunas de ellas, lo que la hace "indivisible". La garantía de atomicidad impide que las actualizaciones de la base de datos se realicen solo parcialmente, lo que puede causar problemas mayores que rechazar la serie completa por completo. En otras palabras, atomicidad significa indivisibilidad e irreductibilidad. ^{[ 10 ]} Alternativamente, podemos decir que una transacción lógica puede estar compuesta por varias transacciones físicas. Hasta que todas las transacciones físicas que la componen se ejecuten, la transacción lógica no se habrá producido.

Un ejemplo de transacción atómica es una transferencia monetaria de la cuenta bancaria A a la cuenta B. Consta de dos operaciones: retirar el dinero de la cuenta A y depositarlo en la cuenta B. No querríamos ver el importe retirado de la cuenta A antes de estar seguros de que también se ha transferido a la cuenta B. Realizar estas operaciones en una transacción atómica garantiza que la base de datos permanezca en un estado consistente ; es decir, no se debita ni se acredita dinero si alguna de estas dos operaciones falla. ^{[ 11 ]}

La consistencia es un término muy general que exige que los datos cumplan con todas las reglas de validación. En el ejemplo anterior, la validación es un requisito que A + B = 100. Todas las reglas de validación deben verificarse para garantizar la consistencia. Supongamos que una transacción intenta restar 10 de A sin modificar B. Dado que la consistencia se verifica después de cada transacción, se sabe que A + B = 100 antes de que comience la transacción. Si la transacción resta 10 de A correctamente, se logrará la atomicidad. Sin embargo, una verificación de validación mostrará que A + B = 90 , lo cual es inconsistente con las reglas de la base de datos. Toda la transacción debe cancelarse y las filas afectadas deben revertirse a su estado anterior a la transacción. Si hubiera habido otras restricciones, disparadores o cascadas, cada operación de cambio se habría verificado de la misma manera que la anterior antes de que se confirmara la transacción. Pueden surgir problemas similares con otras restricciones. Es posible que hayamos requerido que los tipos de datos de A y B sean enteros. Si luego introdujéramos, por ejemplo, el valor 13.5 para A , la transacción se cancelaría o el sistema podría generar una alerta en forma de disparador (siempre que este se haya configurado para tal fin). Otro ejemplo serían las restricciones de integridad, que impedirían eliminar una fila de una tabla cuya clave primaria sea referenciada por al menos una clave foránea en otras tablas.

Para demostrar el aislamiento, suponemos que dos transacciones se ejecutan simultáneamente, cada una intentando modificar los mismos datos. Una de ellas debe esperar a que la otra finalice para mantener el aislamiento.

Consideremos dos transacciones:

• T ₁ transfiere 10 de A a B.
• T ₂ transfiere 20 de B a A.

En conjunto, hay cuatro acciones:

1. T ₁ resta 10 de A.
2. T ₁ suma 10 a B.
3. T ₂ resta 20 de B.
4. T ₂ suma 20 a A.

Si estas operaciones se realizan en orden, se mantiene el aislamiento, aunque T2 _deba esperar. Consideremos qué sucede si T1 _falla a mitad del proceso. La base de datos elimina los efectos de T1 _y T2 _solo ve datos válidos.

Al intercalar las transacciones, el orden real de las acciones podría ser:

1. T ₁ resta 10 de A.
2. T ₂ resta 20 de B.
3. T ₂ suma 20 a A.
4. T ₁ suma 10 a B.

Consideremos nuevamente qué sucede si T1 _falla al modificar B en el paso 4. Para cuando T1 _falla , T2 _ya ha modificado A; no se puede restaurar al valor que tenía antes de T1 _sin dejar una base de datos inválida. Esto se conoce como una contención de escritura-escritura , ^{[ 12 ]} porque dos transacciones intentaron escribir en el mismo campo de datos. En un sistema típico, el problema se resolvería revirtiendo al último estado válido conocido, cancelando la transacción fallida T1 _y reiniciando la transacción interrumpida T2 _desde el estado válido.

Consideremos una transacción que transfiere 10 de A a B. Primero, se retiran 10 de A y luego se suman 10 a B. En este punto, se le informa al usuario que la transacción fue exitosa. Sin embargo, los cambios aún permanecen en la cola de almacenamiento en disco , a la espera de ser guardados. Se produce un fallo eléctrico y los cambios se pierden, pero el usuario asume (comprensiblemente) que se conservan.

Muchas bases de datos dependen del bloqueo para proporcionar funcionalidades ACID. El bloqueo implica que la transacción marca los datos a los que accede, de modo que el sistema de gestión de bases de datos (DBMS) sepa que no debe permitir que otras transacciones los modifiquen hasta que la primera transacción se complete con éxito o falle. El bloqueo siempre debe adquirirse antes de procesar los datos, incluso aquellos que se leen pero no se modifican. Las transacciones complejas suelen requerir un gran número de bloqueos, lo que genera una sobrecarga considerable y bloquea otras transacciones. Por ejemplo, si el usuario A está ejecutando una transacción que debe leer una fila de datos que el usuario B desea modificar, el usuario B debe esperar a que la transacción del usuario A finalice. El bloqueo en dos fases se suele aplicar para garantizar un aislamiento completo.

Una alternativa al bloqueo es el control de concurrencia multiversión , en el que la base de datos proporciona a cada transacción de lectura la versión anterior, sin modificar, de los datos que está siendo modificada por otra transacción activa. Esto permite a los lectores operar sin adquirir bloqueos; es decir, las transacciones de escritura no bloquean a las de lectura, y los lectores no bloquean a los escritores. Volviendo al ejemplo, cuando la transacción del usuario A solicita datos que el usuario B está modificando, la base de datos proporciona a A la versión de esos datos que existía cuando el usuario B inició su transacción. El usuario A obtiene una vista consistente de la base de datos incluso si otros usuarios están modificando datos. Una implementación, denominada aislamiento de instantánea , flexibiliza la propiedad de aislamiento.

Garantizar las propiedades ACID en una transacción distribuida a través de una base de datos distribuida , donde ningún nodo individual es responsable de todos los datos que afectan a una transacción, presenta complicaciones adicionales. Las conexiones de red pueden fallar, o un nodo puede completar con éxito su parte de la transacción y luego verse obligado a revertir sus cambios debido a una falla en otro nodo. El protocolo de confirmación en dos fases (que no debe confundirse con el bloqueo en dos fases ) proporciona atomicidad para las transacciones distribuidas para asegurar que cada participante en la transacción esté de acuerdo en si la transacción debe confirmarse o no. ^{[ 13 ]} Brevemente, en la primera fase, un nodo (el coordinador) interroga a los demás nodos (los participantes), y solo cuando todos responden que están preparados, el coordinador, en la segunda fase, formaliza la transacción.