Transacción
Keywords: Transacción, Algoritmo, Journaling, SQL
Una transacción consiste en una interacción con una estructura de datos que, aún siendo compleja y estár compuesta por varios procesos que se han de aplicar uno después del otro, queremos que sea equivalente a una interacción atomica. Es decir, que se realice de una sola vez y que la estructura a medio manipular no sea jamás alcanzable por el resto del sistema.
Un ejemplo típico es el de la transferéncia de fondos entre dos cuentas corrientes de un banco. Si queremos transferir, pongamos 5000€ de la cuenta corriente de Armando a la de Benito (A y B a partir de ahora) y las cuentas tienen, respectivamente, 20000€ y 0€ de saldo los pasos lógicos serían:
- Comprobar si en la cuenta A hay dinero suficiente.
- Restar 5000€ de la cuenta de A, con lo que su saldo pasa a ser de 15000€.
- Sumar 5000€ a la cuenta de B, con lo que los saldos quedan A=15000€ y B=5000€
Ahora bien, si entre el paso 2 y el 3 el sistema sufre una parada o error inesperado las cuentas quedarían como A=15000 y B=0 con lo cual... Se han volatilizado 5000€ y presumiblemente ni Armando ni Benito estarán contentos, y hubiesen preferido que la transacción nunca hubiese sido iniciada.
Este ejemplo ilustra porqué las transacciones tienen un comportamiento deseado de Todo o nada, o se realiza completamente o no debe tener ningún efecto.
Las propiedades deseables en una transacción son:
- Atomicidad: Han de ser atómicas (indivisibles) delante de:
- Fallos.
- Procesos que estén accediendo simultáneamente a los datos.
- Serializables: Si dos transacciones se ejecutan en paralelo el resultado ha de ser el mismo que si se ejecutase una después de la otra.
- Permanentes: Una vez realizadas los efectos sobre los datos han de ser, efectivamente, visibles al resto del sistema de forma permanente.
La atomicidad frente a fallos se suele impoementar con mecanimos de journaling, y la protección frente a accesos concurrentes mediante bloqueos en las estructuras afectadas.
La serialibilidad viene garantizada por la atomicidad.
La permanencia se suele implementar forzando a los periféricos encargados de almacenar los cambios a confirmar la completa y definitiva transmisión de los datos al medio (generalmente, el disco).
La forma algorítmica que suelen tener las transacciones es la siguiente:
iniciar transacción (lista de recursos a bloquear)
ejecución de las operaciones individuales.
if (todo_ok){
aplicar_cambios
}
else{
cancelar_cambios
}
En cualquier momento, el programa podría decidir que es necesario hacer fallar la transacción, con lo que el sistema deberá revertir todos los cambios hechos por las operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a la aplicar_datos, y ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos, y, mas recientemente, se han visto incorporadas a como gestiona un sistema operativo la interación con un sistema de archivos (como varias características de las bases de datos, debido a que son muy similares arquitecturalmente).