En informática , y particularmente en bases de datos , una transacción como una reserva, una compra o un pago se implementa a través de una serie de operaciones que cambian la base de datos de un estado A - antes de la transacción - a un estado B posterior y los mecanismos hacen es posible obtener que esta secuencia sea a la vez atómica , coherente , aislada y duradera ( ACID ).
La mayoría de los sistemas de gestión de bases de datos tanto jerárquicos como relacionales del mercado permiten realizar transacciones atómicas, coherentes, aisladas y sostenibles. Los sistemas NoSQL afirman esto.
El concepto de transacción se basa en el concepto de punto de sincronización ( sync point ) que representa un estado estable del sistema informático considerado, en particular de sus datos.
Atomicidad Una transacción debe realizarse en todo o en nada, es decir, en su totalidad o en nada; Consistencia La coherencia de los datos debe garantizarse en todos los casos, incluso en los casos de error en los que el sistema necesita volver al estado coherente anterior. La coherencia se establece mediante reglas funcionales. Ejemplo: una transacción inmobiliaria puede llevar mucho tiempo. Se considerará TI como un procedimiento funcional compuesto por varias transacciones de TI (reserva, propuesta de compra, compromiso, escritura notarial). Por lo tanto, las etapas intermedias se gestionan funcionalmente a través del estado del objeto Apartamento. Incluso si el procedimiento está en progreso, entre cada paso el sistema permanece consistente. En caso de abandono del procedimiento (una especie de reversión de la transacción inmobiliaria), las reglas funcionales vuelven a poner el apartamento a la venta. Hay muchos casos de procedimiento que no pueden manejarse con una sola transacción de TI. El diseñador debe especificar las reglas funcionales que controlan los cambios de estado de los objetos en cuestión y gestionar manualmente el equivalente del compromiso y la reversión del procedimiento; Aislamiento La transacción funcionará en modo aislado donde solo ella podrá ver los datos que está modificando, mientras espera un nuevo punto de sincronización; el sistema garantiza otras transacciones, ejecutadas en paralelo en el mismo sistema, visibilidad de datos pasados. Esto se obtiene gracias a los bloqueos del sistema establecidos por el DBMS. El siguiente ejemplo ilustra un aislamiento más funcional que implementa el bloqueo de una aplicación: Un actor coloca un pedido en vista de un contexto. Este contexto no debe haber cambiado cuando valida su orden, de lo contrario la orden puede perder todo su significado. Para evitar que el contexto cambie, es posible bloquearlo antes de leerlo. Pero a menudo es un consumidor de recursos informáticos y un inconveniente para los demás, especialmente si la reflexión y la entrada duran varios minutos. En la gestión, generalmente es suficiente simplemente comprobar en el momento de la actualización que el contexto no ha cambiado: de manera optimista, el aislamiento se comprueba a posteriori; Durabilidad Cuando se completa la transacción, el sistema se encuentra en un estado estable duradero, ya sea después de un cambio transaccional exitoso o después de una falla que resulta en un retorno al estado estable anterior. La sostenibilidad suele estar involucrada en el procesamiento por lotes ( batch ) o la replicación asincrónica que produce emisiones. La aplicación descendente no tiene derecho a cuestionar la transacción anterior que emitió el evento, de lo contrario, esto significaría que esta transacción no dejó el sistema en un estado consistente. Por lo tanto, la aplicación anterior debe verificar todo cuidadosamente antes de difundir la información. Cuando la arquitectura funcional no es pura, a menudo es necesario gestionar los rechazos. Estos tratamientos excepcionales deben especificarse luego para que los rechazos se reciclen mediante un procedimiento funcional a menudo complejo. De ahí la importancia de la coherencia de la transacción en relación con todo el sistema.Por ejemplo, durante una operación de computadora para transferir dinero de una cuenta bancaria a otra cuenta bancaria, hay una tarea de retirar dinero de la cuenta de origen y una tarea de depósito de la cuenta de destino. El programa informático que realiza esta transacción garantizará que ambas operaciones se puedan realizar sin errores y, en este caso, el cambio se hará efectivo en ambas cuentas. Si este no es el caso, la operación se cancela. Ambas cuentas mantienen sus valores iniciales. Esto garantiza la coherencia de los datos entre las dos cuentas.
Las transacciones informáticas se utilizan ampliamente en los DBMS.
Esta técnica antigua, practicada con monitores transaccionales tales como IBM CICS , TDS de Bull, Siemens UTM, es ahora ampliamente utilizado en aplicaciones web arquitecturas , y en cliente-servidor de aplicaciones .
De hecho, nada se parece más a una página web que una pantalla sincrónica:
El problema que se plantea en este modo de funcionamiento es que a veces se necesita una secuencia de varias pantallas o páginas para desarrollar una transacción ACID completa . Fue la metodología Merise la que definió estos conceptos por primera vez:
Esta tarea se asimila a una pseudo-transacción que, desde el punto de vista del monitor, es una transacción técnica, pero por supuesto que no es realmente funcional hasta que finaliza la secuencia.
Pero :
Preguntas :
Las respuestas de los ancianos son también las que se utilizan hoy en día en las “nuevas” tecnologías:
Entendemos por qué si establecemos bloqueos del sistema (SGBD) a lo largo de la cadena, cuya duración es incontrolable, el sistema colapsaría. Este es el objetivo de lo pseudo transaccional. Pero la estrategia de control de aislamiento es fundamentalmente funcional.
La pseudo transacción es, por tanto, ACID, pero las reglas funcionales son tales que la coherencia entre cada pseudo transacción en una secuencia está garantizada por la ausencia de cualquier actualización de la base de datos.
Una aplicación cliente / servidor bien diseñada también utiliza pseudotransacciones, pero el contexto se gestiona en la aplicación cliente, lo que alivia la tensión del servidor. El diagrama típico es el siguiente:
Lo que da N + 1 pseudo-transacciones.