Definición
Una transacción es un grupo de operaciones sobre la base de datos que se tratan como una unidad indivisible: o se aplican todas, o no se aplica ninguna.
El ejemplo clásico es una transferencia bancaria: restar cien euros de una cuenta y sumarlos en otra. Si el sistema se cae justo en medio, el dinero no puede desaparecer. Con una transacción, si la segunda operación falla, la primera se deshace sola.
En una aplicación de gestión el mismo problema aparece constantemente: crear un pedido implica insertar la cabecera, insertar diez líneas, descontar stock y apuntar un movimiento. Si eso se queda a la mitad, tienes un pedido sin líneas o un stock descontado sin pedido.
Las cuatro garantías: ACID
Atomicidad. Todo o nada. Es la garantía principal.
Consistencia. Al terminar, las reglas de la base de datos siguen cumpliéndose: claves foráneas válidas, restricciones respetadas. No puedes dejar la base en un estado imposible.
Aislamiento. Dos transacciones a la vez no se pisan. Lo que una está haciendo a medias no lo ve la otra. Hay varios niveles de aislamiento, con distinto equilibrio entre seguridad y velocidad.
Durabilidad. Una vez confirmada, sobrevive a un corte de luz. El motor la ha escrito en disco.
Cómo se usa
BEGIN;
INSERT INTO pedidos (cliente_id, fecha) VALUES (42, NOW());
INSERT INTO pedido_lineas (pedido_id, articulo, cantidad) VALUES (...);
UPDATE stock SET unidades = unidades - 10 WHERE articulo = 'REF-001';
COMMIT; -- confirma todo
-- ROLLBACK; -- deshace todo
Entre el BEGIN y el COMMIT, nada de lo que hagas es definitivo. Si algo falla, un ROLLBACK lo deshace como si no hubiera ocurrido.
En el código, el patrón es siempre el mismo: abrir la transacción, hacer el trabajo dentro de un bloque de captura de errores, confirmar al final y deshacer si salta cualquier excepción.
Ejemplo práctico
En el CRM de IMDICA, aceptar un presupuesto y convertirlo en pedido toca cinco tablas: marca el presupuesto como aceptado, crea el pedido, copia las líneas, crea el expediente de seguimiento y apunta el evento en el historial.
Sin transacción, un fallo de red en el paso tres deja un presupuesto marcado como aceptado y un pedido sin líneas. El comercial ve el pedido en su lista, entra y está vacío. Y lo peor: la base de datos no sabe que está mal, así que nadie se entera hasta que el cliente reclama.
Con transacción, ese mismo fallo deja todo exactamente como estaba antes. El usuario ve un error, vuelve a intentarlo y ya está.
Un detalle que no es evidente: no todo lo que ocurre en esa operación puede ir dentro de la transacción. Enviar el correo de confirmación al cliente, por ejemplo, no se deshace con un ROLLBACK. Si mandas el correo dentro de la transacción y luego algo falla, la base vuelve atrás pero el correo ya salió.
La regla que uso: dentro de la transacción, solo la base de datos. Todo lo que tenga efectos fuera —correos, llamadas a otras APIs, escribir ficheros— va después del COMMIT.
Errores comunes
- Transacciones demasiado largas. Si mantienes una abierta mientras esperas la respuesta de una API externa, estás bloqueando filas y haciendo esperar a los demás. Corta y rápida.
- Meter efectos externos dentro. Correos, pagos, ficheros. No se deshacen.
- Olvidar el
ROLLBACKen el manejo de errores. Una transacción abierta y abandonada mantiene bloqueos hasta que caduca. - Suponer que hay transacción cuando no la hay. Muchos motores están en confirmación automática por defecto: cada instrucción se confirma sola. Si no abres la transacción explícitamente, no la tienes.
- Usar MyISAM en MySQL. Ese motor de almacenamiento no soporta transacciones. Hay que usar InnoDB, que es el de por defecto desde hace años, pero en bases antiguas todavía aparece.
- Interbloqueos. Dos transacciones que se esperan mutuamente. Se reducen accediendo siempre a las tablas en el mismo orden, y se manejan reintentando.
Cuándo usarlas
Siempre que una operación de negocio toque más de una tabla, o más de una fila que tenga que quedar coherente entre sí. Pedidos, facturas, movimientos de stock, cualquier cosa con dinero.
No hacen falta para una lectura simple, ni para un UPDATE de una sola fila que no depende de nada más.
Y una advertencia práctica: si tu base de datos es SQLite, las transacciones funcionan perfectamente, pero solo permite un escritor a la vez. Con transacciones largas y varios procesos escribiendo, verás errores de base bloqueada. Es otra razón para hacerlas cortas.
