En computación, un gestor transaccional es un componente que procesa información descomponiéndola de forma unitaria en operaciones indivisibles, llamadas transacciones. Cada transacción debe finalizar de forma correcta o incorrecta como una unidad completa. No puede acabar en un estado intermedio.

Los gestores transaccionales se diseñan para mantener bases de datos en un estado conocido y consistente, asegurando que todas las operaciones que son interdependientes realizadas sobre la base de datos se han completado todas correctamente o se han cancelado todas.

Por ejemplo, tómese un ejemplo típico de una transacción bancaria que requiere mover 500€ de la cuenta de un cliente a otra. Esta transacción es una operación única según la visión del banco, pero requiere al menos dos operaciones desde la visión de la computadora: restar 500€ de la cuenta del cliente origen y sumarle 500€ al cliente destino. Si la operación de resta finaliza correctamente pero la operación de suma no (o viceversa), el balance del banco al final del día no será correcto. Por lo tanto, debe haber una forma de asegurar que ambas operaciones finalizan correctamente o no se ejecutan, y así evitar cualquier tipo de inconsistencia en la base de datos del banco. Un gestor transaccional proporciona esta característica.

Un gestor transaccional permite enlazar varias operaciones individuales automáticamente como una sola transacción indivisible. El gestor garantiza que todas las operaciones finalizan sin errores o ninguna de ellas se ejecuta. Si algunas operaciones finalizaron correctamente pero otras no, el gestor inicia el proceso de rollback de todas las operaciones implicadas (incluso de aquellas que finalizaron correctamente), eliminando todo rastro de la transacción y devolviendo la base de datos a un estado consistente, como lo estaba antes de empezar a procesar la transacción. Si todas las operaciones de la transacción finalizaron correctamente, la transacción realiza commit a los cambios realizados en la base de datos. Una vez se ha hecho commit, los datos de esa transacción quedan consolidados y la transacción no puede hacer rollback de los cambios.

Todas las transacciones se procesan en orden cronológico. Si la transacción n+1 modifica la misma área que la transacción n, la transacción n+1 no puede empezar hasta que la transacción n haya realizado commit de sus cambios. Ninguna transacción puede realizar commit de sus modificaciones hasta que todas las transacciones anteriores que modifiquen la misma área hayan realizado commit (o rollback) de sus cambios. No puede haber «saltos» de secuencia en las transacciones anteriores.

Los principios básicos de cualquier sistema transaccional son los mismos. Sin embargo, la terminología puede variar de un sistema a otro; los términos utilizados aquí no tienen por qué ser universales.

Los gestores transaccionales aseguran la integridad de las bases de datos registrando todos los estados intermedios de una base de datos mientras se modifica. En caso de que la transacción falle, se usan esos registros para devolver la base de datos a un estado consistente. Por ejemplo, se copia información de la base de datos antes de que sea modificada por una transacción, de tal manera que si parte de la transacción acaba incorrectamente, se usan esas copias (llamadas before image) para restablecer la integridad de los datos (rollback).

También es posible mantener una copia (llamada after image) de todas aquellas modificaciones realizadas sobre una base de datos. No es necesario para hacer rollback de las transacciones que finalizaron incorrectamente, pero sí es útil para actualizar la base de datos en el escenario de una recuperación.

Si la base de datos falla estrepitosamente, la restauración se debe iniciar desde la copia de seguridad más reciente, aunque no reflejará aquellos cambios posteriores a la copia. Sin embargo, una vez se ha restablecido la copia de seguridad se aplica la copia after image que contendrá todas las modificaciones entre la copia de seguridad y el fallo de la base de datos. Desgraciadamente, esta copia también contiene todas aquellas modificaciones que estaban en vuelo en el momento del fallo. Por ello, es necesario aplicar la copia before image que hará rollback de las transacciones con un estado intermedio, devolviendo la base de datos a un estado seguro y consistente.

En algunos casos, dos transacciones pueden, en el transcurso de su ejecución, competir por dos recursos al mismo tiempo, de tal manera que impide seguir con su ejecución. Un bloqueo mutuo (o interbloqueo, deadlock en inglés) ocurre, por ejemplo, cuando la transacción A intenta acceder al área X de la base de datos mientras la transacción B intenta acceder al área Y de la base de datos. Si, en algún punto intermedio, la transacción A intenta acceder al área Y mientras la transacción B intenta acceder al área X se genera un bloqueo mutuo que impide a ambas transacciones progresar. Los sistemas transaccionales están diseñados para detectar este tipo de bloqueos cuando ocurren y actuar en concordancia. O bien ambas transacciones son canceladas y el sistema hace rollback de todos los cambios para luego volver a ejecutarlas automáticamente en diferente orden de tal forma que no se vuelva a formar otro bloqueo mutuo, o bien cancelar y hacer rollback de una de ellas y volverla a lanzar después de una pequeña espera.