En el desarrollo de software definimos una transacción como un conjunto de pasos que deben ejecutarse de forma ordenada. El ejemplo más común en el que solemos pensar es en las transacciones de las bases de datos, pero se utilizan en muchos más ambitos, como por ejemplo: una transacción distribuida en micro-servicios, blockchains o incluso puede que debamos desarrollar un sistema de transacciones que hayamos creado de cero para nuestro proyecto.
Es por ello que si deseamos disponer de transacciones que operen de la forma más estable posible, lo ideal es que cumplan las características ACID:
Tabla de Contenidos
Atomicity (atomicidad)
La definición original sería la siguiente:
Por cada paso en una secuencia de acciones realizada dentro de los límites de una transacción, ésta debe, o completarse correctamente, o en caso contrario todo el trabajo debería ser revertido.
Martin Fowler ~ Patterns of Enterprise Application Architecture
Esta característica, viene a indicar que sólo podemos dar una transacción como completada, cuando todos los pasos que la componen finalicen correctamente. Si hay un problema en cualquiera de los pasos, habrá que desechar todos los pasos realizados hasta ahora.
Consistency (consistencia)
Los recursos de un sistema deben permanecer en un estado consistente y no corrupto, tanto al principio como al final.
Martin Fowler ~ Patterns of Enterprise Application Architecture
Este principio, lo que nos viene a decir, es que no deberíamos tener datos que incongruentes o incorrectos en cualquier paso de la transacción. Cada paso, debe dejar el estado totalmente consistente.
Isolation (aislamiento)
El resultado de una transacción no debe ser visible a otras transacciones abiertas hasta que no termine correctamente.
Martin Fowler ~ Patterns of Enterprise Application Architecture
Al aislar las transacciones hasta que finalicen, conseguiremos aumentar la consistencia de nuestro sistema. Ya que si no cumplimos esta norma, imaginad que hay un error en un paso de una transacción y otra accede en ese momento a los datos. La transacción que haya fallado, revertiría los cambios, con lo que la segunda transacción tendrá datos incorrectos. Es por ello que hasta que no termine la primera, la segunda no podrá acceder al resultado ni la información generada.
Durability (durabilidad)
Cualquier resultado de una transacción que haya terminado correctamente debe ser permanente.
Martin Fowler ~ Patterns of Enterprise Application Architecture
Finalmente, con el último de los principios, lo que se viene a decir es que una vez que una transacción ha terminado, los datos deben quedan realizados de forma permanente, es decir, que para modificarlos, debe lanzarse otra transacción que opere con ellos, pero éstos no deben ser revertidos parcialmente si la transacción finalizó correctamente.
Conclusión
Si tienes que trabajar con transacciones, ya conoces los principios ACID, que se deberían cumplir para mantener un sistema lo más consistente y robusto posible.
Todo esto ha sido extraído de un libro que es prácticamente de lectura obligada si queréis profundizar en la arquitectura del software. El autor es el gran maestro Martin Fowler, y el libro en cuestión es Patterns of Enterprise Application Architecture.
En el desarrollo de software definimos una transacción como un conjunto de pasos que deben ejecutarse de forma ordenada. El ejemplo más común en el que solemos pensar es en las transacciones de las bases de datos, pero se utilizan en muchos más ambitos, como por ejemplo: una transacción distribuida en micro-servicios, blockchains o incluso puede que debamos desarrollar un sistema de transacciones que hayamos creado de cero para nuestro proyecto.
Es por ello que si deseamos disponer de transacciones que operen de la forma más estable posible, lo ideal es que cumplan las características ACID:
Tabla de Contenidos
Atomicity (atomicidad)
La definición original sería la siguiente:
Esta característica, viene a indicar que sólo podemos dar una transacción como completada, cuando todos los pasos que la componen finalicen correctamente. Si hay un problema en cualquiera de los pasos, habrá que desechar todos los pasos realizados hasta ahora.
Consistency (consistencia)
Este principio, lo que nos viene a decir, es que no deberíamos tener datos que incongruentes o incorrectos en cualquier paso de la transacción. Cada paso, debe dejar el estado totalmente consistente.
Isolation (aislamiento)
Al aislar las transacciones hasta que finalicen, conseguiremos aumentar la consistencia de nuestro sistema. Ya que si no cumplimos esta norma, imaginad que hay un error en un paso de una transacción y otra accede en ese momento a los datos. La transacción que haya fallado, revertiría los cambios, con lo que la segunda transacción tendrá datos incorrectos. Es por ello que hasta que no termine la primera, la segunda no podrá acceder al resultado ni la información generada.
Durability (durabilidad)
Finalmente, con el último de los principios, lo que se viene a decir es que una vez que una transacción ha terminado, los datos deben quedan realizados de forma permanente, es decir, que para modificarlos, debe lanzarse otra transacción que opere con ellos, pero éstos no deben ser revertidos parcialmente si la transacción finalizó correctamente.
Conclusión
Si tienes que trabajar con transacciones, ya conoces los principios ACID, que se deberían cumplir para mantener un sistema lo más consistente y robusto posible.
Todo esto ha sido extraído de un libro que es prácticamente de lectura obligada si queréis profundizar en la arquitectura del software. El autor es el gran maestro Martin Fowler, y el libro en cuestión es Patterns of Enterprise Application Architecture.
jose