Transacciones

Una transacción es una unidad lógica de trabajo. O informalmente, y trabajando con

SQL, un conjunto de sentencias que se ejecutan como si fuesen una sola. En general,
las sentencias que forman parte de una transacción se interrelacionan entre sí, y no tiene
sentido que se ejecute una sin que se ejecuten las demás.

Las transacciones aportan una fiabilidad superior a las bases de datos. Con el uso de
transacciones podemos tener la certeza de que nunca nos quedaremos a medio camino
de su ejecución. De hecho, podríamos decir que las transacciones aportan una
característica de "deshacer" a las aplicaciones de bases de datos.

La mayoría de las transacciones se inician de forma implícita al utilizar alguna

sentencia que empieza con CREATE, ALTER, DROP, SET, DECLARE, GRANT o
REVOKE, aunque existe la sentencia SQL para iniciar transacciones, que es la

siguiente:

Si queremos actualizar la base de datos utilizaremos la opción READ WRITE, y si no

la queremos actualizar, elegiremos la opción READ ONLY.

Es necesario que las transacciones tengan las propiedades

ACID: atomicidad, consistencia, aislamiento y durabilidad.

— La atomicidad asegura que, o bien todos los efectos de la transacción se reflejan

en la base de datos, o bien ninguno de ellos; un fallo no puede dejar a la base de datos
en un estado en el cual una transacción se haya ejecutado parcialmente.

— La consistencia asegura que, si la base de datos es consistente inicialmente, la

ejecución de la transacción (debido a la misma) deja la base de datos en un estado
consistente.
 — El aislamiento asegura que, en la ejecución concurrente de transacciones, están
aisladas entre sí, de tal manera que cada una tiene la impresión de que ninguna otra
transacción se ejecuta concurrentemente con ella.

— La durabilidad asegura que, una vez que la transacción se ha comprometido, las

actualizaciones hechas por la transacción no se pierden incluso si hay un fallo del
sistema. (Silberschatz & F. Korth, 2002)

COMMIT Y ROLLBACK

Sin embargo, en cambio, una transacción siempre debe acabar explícitamente con
alguna de las sentencias siguientes:

La diferencia entre COMMIT y ROLLBACK es que mientras la sentencia COMMIT

confirma todos los cambios producidos contra la BD durante la ejecución de la
transacción, la sentencia ROLLBACK deshace todos los cambios que se hayan
producido en la base de datos y la deja como estaba antes del inicio de nuestra
transacción. La palabra reservada WORK sólo sirve para aclarar lo que hace la
sentencia, y es totalmente opcional. (Camps pare, y otros, 2005)

Ejemplo 1:

A continuación, proponemos un ejemplo de transacción en el que se quiere disminuir

el sueldo de los empleados que han trabajado en el proyecto 3 en 1.000 euros. y
aumentar el sueldo de los empleados que han trabajado en el proyecto 1 también en
1.000 euros.

Estas dos consultas deben trabajar bien, ¿pero qué sucede si ocurre algún imprevisto
y "se cae" el sistema después de que se ejecuta la primer consulta, pero la segunda aún
no se ha completado? La persona1 tendrá una cantidad de dinero removida de su cuenta,
y creerá que ha realizado su pago, sin embargo, la persona2 estará enfadada puesto
que pensará que no se le ha depositado el dinero que le deben. En este ejemplo tan
sencillo se ilustra la necesidad de que las consultas sean ejecutadas de manera conjunta,
o en su caso, que no se ejecute ninguna de ellas. Es aquí donde las transacciones toman
un papel muy importante.

Los pasos para usar transacciones en MySQL son:

 Iniciar una transacción con el uso de la sentencia BEGIN.

 Actualizar, insertar o eliminar registros en la base de datos.

 Si se quieren los cambios a la base de datos, completar la transacción con el uso

de la sentencia COMMIT. Únicamente cuando se procesa un COMMIT los
cambios hechos por las consultas serán permanentes.

 Si sucede algún problema, podemos hacer uso de la sentencia ROLLBACK para

cancelar los cambios que han sido realizados por las consultas que han sido
ejecutadas hasta el momento.

Ejemplo 2:

Lecturas consistentes

Por default, las tablas ejecutan una lectura consistente (consistent read). Esto significa
que cuando una sentencia SELECT es ejecutada, MySQL regresa los valores presentes
en la base de datos hasta la transacción más reciente que ha sido completada. Si alguna
transacción está en progreso, los cambios hechos por alguna sentencia INSERT o
UPDATE no serán reflejados. Sin embargo, existe una excepción: las transacciones
abiertas si pueden ver sus propios cambios.
 Creamos una base de datos y una tabla con dos registros para muestra de ejemplo

en el que se aplique commit y rollback:

Se inicia la transacción mediante la sentencia BEGIN:

Actualizamos el registro

Verificamos lo sucedido
Si queremos deshacer los cambios, entonces ejecutamos un ROLLBACK.

Verificamos que se deshicieron los cambios:

Vamos a actualizar el registro usando otra transacción.

 Vamos a confirmar que deseamos los cambios.

Compromiso y retroceso

Las aplicaciones pueden comprometerse o retrocederse mediante el uso de las

instrucciones explícitas commit y rollback. Las aplicaciones también pueden emitir
instrucciones begin transaction y end transaction para controlar el ámbito de las
transacciones. No se soportan las transacciones anidadas. Normalmente DB2 libera
todos los bloqueos que se mantienen por una transacción en commit o rollback. Sin
embargo, si se ha declarado una instrucción de cursor mediante la cláusula withhold
entonces se mantienen algunos bloqueos durante los compromisos. (Silberschatz & F.
Korth, 2002)

Bibliografía
Camps pare, r., Casillas Santillán, L., Costal Costa, D., Gibert Ginestà, M., Martín Escofet, C., & Pérez

Mora, O. (2005). Base de datos. barcelona: Universitat Oberta de Catalunya.

Silberschatz, A., & F. Korth, H. (2002). FUNDAMENTOS DE BASES DE DATOS. Madrid: McGRAW-

HILL/INTERAMERICANA DE ESPAÑA, S. A. U.