Una transacción es una interacción con una estructura de datos compleja, compuesta por varios procesos que se han de aplicar uno después del otro. La transacción debe realizarse de una sola vez y sin que la estructura a medio manipular pueda ser alcanzada por el resto del sistema hasta que se hayan finalizado todos sus procesos.
Se puede poner como ejemplo una transferencia de fondos entre dos cuentas corrientes de un banco. Si se quiere transferir, supongamos, 5000€ de la cuenta corriente de A a B y las cuentas tienen, respectivamente, 20000€ y 0€ de saldo los pasos lógicos serían:
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 A ni B estarán contentos, y hubiesen preferido que la transacción nunca hubiese sido iniciada.
Este ejemplo ilustra por qué las transacciones tienen un comportamiento deseado de todo o nada, o se realiza completamente o no debe tener ningún efecto.
Las transacciones deben cumplir cuatro propiedades, denominadas ACID:
La atomicidad frente a fallos se suele implementar con mecanismos 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:
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 aplicar_cambios y ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos y, más recientemente, se han visto incorporadas a cómo gestiona un sistema operativo la interacción con un sistema de archivos (como varias características de las bases de datos, debido a que son muy similares arquitectónicamente).
Una transacción en un sistema de gestión de bases de datos es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional si es capaz de mantener la integridad de datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado. Una transacción debe contar con ACID (un acrónimo inglés) que quiere decir: Atomicidad, consistencia, aislamiento y durabilidad.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language) provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.
En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.
Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que se incrementa el saldo de la cuenta destino. Para garantizar la integridad del sistema (es decir, para que no aparezca o desaparezca dinero) las dos operaciones deben ser atómicas, o sea que el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.
Escribe un comentario o lo que quieras sobre Transacción (base de datos) (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)