Transacciones
Definición
Una transacción SQL es un conjunto de sentencias SQL que se ejecutan
formando una unidad lógica de trabajo (LUW del inglés Logic
Unit of Work), es decir, en forma indivisible o
atómica.
Una transacción SQL finaliza con un COMMIT, para aceptar
todos los cambios que la transacción ha realizado en la base de datos, o
un ROLLBACK para deshacerlos.
MySQL nos permite realizar transacciones en sus tablas si hacemos uso
del motor de almacenamiento InnoDB (MyISAM no
permite el uso de transacciones).
El uso de transacciones nos permite realizar operaciones de forma
segura y recuperar datos si se produce algún fallo en el servidor
durante la transacción, pero por otro lado las transacciones pueden
aumentar el tiempo de ejecución de las instrucciones.
Las transacciones deben cumplir las cuatro propiedades
ACID.
Propiedades ACID
Las propiedades ACID garantizan que las
transacciones se puedan realizar en una base de datos de forma segura.
Decimos que un Sistema Gestor de Bases de Datos es ACID
compliant cuando permite realizar transacciones.
ACID es un acrónimo de Atomicity, Consistency,
Isolation y Durability.
Atomicidad: Esta propiedad quiere decir que una
transacción es indivisible, o se ejecutan todas la sentencias o no se
ejecuta ninguna.
Consistencia: Esta propiedad asegura que después
de una transacción la base de datos estará en un estado válido y
consistente.
Aislamiento: Esta propiedad garantiza que cada
transacción está aislada del resto de transacciones y que el acceso a
los datos se hará de forma exclusiva. Por ejemplo, si una transacción
que quiere acceder de forma concurrente a los datos que están siendo
utilizados por otra transacción, no podrá hacerlo hasta que la primera
haya terminado.
Durabilidad: Esta propiedad quiere decir que los
cambios que realiza una transacción sobre la base de datos son
permanentes.
AUTOCOMMIT
Algunos Sistemas Gestores de Bases de Datos, como MySQL (si
trabajamos con el motor InnoDB) tienen activada por
defecto la variable AUTOCOMMIT. Esto quiere decir que
automáticamente se aceptan todos los cambios realizados después
de la ejecución de una sentencia SQL y no es posible
deshacerlos.
Aunque la variable AUTOCOMMIT está activada por defecto
al inicio de una sesión SQL, podemos configurarlo para indicar si
queremos trabajar con transacciones implícitas o explícitas.
Podemos consultar el valor actual de AUTOCOMMIT
haciendo:
Para desactivar la variable AUTOCOMMIT hacemos:
Si hacemos esto siempre tendríamos una transacción abierta y los
cambios sólo se aplicarían en la base de datos ejecutando la sentencia
COMMIT de forma explícita.
Para activar la variable AUTOCOMMIT hacemos:
Para poder trabajar con transacciones en MySQL es necesario utilizar
InnoDB.
Se recomienda la lectura del siguiente documento SQL
Transactions.
START TRANSACTION,
COMMIT y ROLLBACK
Los pasos para realizar una transacción en MySQL son los
siguientes:
- Indicar que vamos a realizar una transacción con la sentencia
START TRANSACTION, BEGIN o
BEGIN WORK.
- Realizar las operaciones de manipulación de datos sobre la base
datos (insertar, actualizar o borrar filas).
- Si las operaciones se han realizado correctamente y queremos que los
cambios se apliquen de forma permanente sobre la base de datos usaremos
la sentencia
COMMIT. Sin embargo, si durante las
operaciones ocurre algún error y no queremos aplicar los cambios
realizados podemos deshacerlos con la sentencia
ROLLBACK.
A continuación se muestra la sintaxis que aparece en la documentación
oficial para realizar transacciones en MySQL.
START TRANSACTION
[transaction_characteristic [, transaction_characteristic] ...]
transaction_characteristic: {
WITH CONSISTENT SNAPSHOT
| READ WRITE
| READ ONLY
}
BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET autocommit = {0 | 1}
Ejemplo 1:
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
Ejemplo 2:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cliente (
id INT UNSIGNED PRIMARY KEY,
nombre CHAR (20)
);
START TRANSACTION;
INSERT INTO cliente VALUES (1, 'Pepe');
COMMIT;
-- 1. ¿Qué devolverá esta consulta?
SELECT *
FROM cliente;
SET AUTOCOMMIT=0;
INSERT INTO cliente VALUES (2, 'Maria');
INSERT INTO cliente VALUES (20, 'Juan');
DELETE FROM cliente WHERE nombre = 'Pepe';
-- 2. ¿Qué devolverá esta consulta?
SELECT *
FROM cliente;
ROLLBACK;
-- 3. ¿Qué devolverá esta consulta?
SELECT *
FROM cliente;
Ejemplo 3:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
INSERT INTO cuentas VALUES (2, 2000);
INSERT INTO cuentas VALUES (3, 0);
-- 1. Consultamos el estado actual de las cuentas
SELECT *
FROM cuentas;
-- 2. Suponga que queremos realizar una transferencia de dinero entre dos cuentas bancarias con la siguiente transacción:
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;
-- 3. ¿Qué devolverá esta consulta?
SELECT *
FROM cuentas;
-- 4. Suponga que queremos realizar una transferencia de dinero entre dos cuentas bancarias con la siguiente transacción y una de las dos cuentas no existe:
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 9999;
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;
-- 5. ¿Qué devolverá esta consulta?
SELECT *
FROM cuentas;
-- 6. Suponga que queremos realizar una transferencia de dinero entre dos cuentas bancarias con la siguiente transacción y la cuenta origen no tiene saldo:
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 3;
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;
-- 7. ¿Qué devolverá esta consulta?
SELECT *
FROM cuentas;
Puede encontrar más información en la documentación
oficial.
SAVEPOINT,
ROLLBACK TO SAVEPOINT y RELEASE SAVEPOINT
Si trabajamos con tablas InnoDB en MySQL también es
posible hacer uso de las sentencias: SAVEPOINT,
ROLLBACK TO SAVEPOINT y RELEASE SAVEPOINT.
SAVEPOINT: Nos permite establecer un punto de
recuperación dentro de la transacción, utilizando un identificador. Si
en una transacción existen dos SAVEPOINT con el mismo
nombre sólo se tendrá en cuenta el último que se ha definido.ROLLBACK TO SAVEPOINT: Nos permite hacer un
ROLLBACK deshaciendo sólo las instrucciones que se hayan
ejecutado hasta el SAVEPOINT que se indique.RELEASE SAVEPOINT: Elimina un
SAVEPOINT.
A continuación se muestra la sintaxis que aparece en la documentación
oficial para crear SAVEPOINT.
SAVEPOINT identifier
ROLLBACK [WORK] TO [SAVEPOINT] identifier
RELEASE SAVEPOINT identifier
Ejemplo:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE producto (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
nombre VARCHAR(100) NOT NULL,
precio DOUBLE
);
INSERT INTO producto (id, nombre) VALUES (1, 'Primero');
INSERT INTO producto (id, nombre) VALUES (2, 'Segundo');
INSERT INTO producto (id, nombre) VALUES (3, 'Tercero');
-- 1. Comprobamos las filas que existen en la tabla
SELECT *
FROM producto;
-- 2. Ejecutamos una transacción que incluye un SAVEPOINT
START TRANSACTION;
INSERT INTO producto (id, nombre) VALUES (4, 'Cuarto');
SAVEPOINT sp1;
INSERT INTO producto (id, nombre) VALUES (5, 'Cinco');
INSERT INTO producto (id, nombre) VALUES (6, 'Seis');
ROLLBACK TO sp1;
-- 3. ¿Qué devolverá esta consulta?
SELECT *
FROM producto;
Acceso concurrente a los
datos
Cuando dos transacciones distintas intentan acceder concurrentemente
a los mismos datos pueden ocurrir los siguientes problemas:
Dirty Read (Lectura sucia). Sucede
cuando una segunda transacción lee datos que están siendo modificados
por una transacción antes de que haga COMMIT.
Non-Repeatable Read (Lectura No
Repetible). Se produce cuando una transacción consulta el mismo
dato dos veces durante la ejecución de la transacción y la segunda vez
encuentra que el valor del dato ha sido modificado por otra
transacción.
Phantom Read (Lectura fantasma). Este
error ocurre cuando una transacción ejecuta dos veces una consulta que
devuelve un conjunto de filas y en la segunda ejecución de la consulta
aparecen nuevas filas en el conjunto que no existían
cuando se inició lo transacción.
Ejemplos
Ejemplo de Dirty
Read (Lectura sucia)
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1; |
|
|
SELECT saldo FROM cuentas WHERE id = 1; |
ROLLBACK |
|
Ejemplo de Non-Repeatable
Read (Lectura No Repetible)
SELECT saldo FROM cuentas WHERE id = 1; |
|
|
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1; |
SELECT saldo FROM cuentas WHERE id = 1; |
|
Ejemplo de Phantom
Read (Lectura fantasma)
SELECT SUM(saldo) FROM cuentas; |
|
|
INSERT INTO cuentas VALUES (4, 3000); |
SELECT SUM(saldo) FROM cuentas; |
|
Niveles de aislamiento
Para evitar que sucedan los problemas de acceso concurrente que hemos
comentado en el punto anterior podemos establecer diferentes niveles de
aislamiento que controlan el nivel de bloqueo durante el acceso a los
datos. El estándar ANSI/ISO de SQL (SQL92) define cuatro niveles de
aislamiento.
Read Uncommitted. En este nivel no se
realiza ningún bloqueo, por lo tanto, permite que sucedan los tres
problemas
Read Committed. En este caso los datos
leídos por una transacción pueden ser modificados por otras
transacciones, por lo tanto, se pueden dar los problemas
Non-Repeteable Read y Phantom Read.
Repeatable Read. En este nivel ningún
registro leído con un SELECT puede ser modificado en otra
transacción, por lo tanto, sólo puede suceder el problema del
Phantom Read.
Serializable. En este caso las
transacciones se ejecutan unas detrás de otras, sin que exista la
posibilidad de concurrencia.
El nivel de aislamiento que utiliza InnoDB por
defecto es Repeatable Read.
La siguiente tabla muestra los problemas de lectura que pueden
ocurrir en cada uno de los modos de aislamiento.
| Read Uncommitted |
Es posible |
Es posible |
Es posible |
| Read Committed |
- |
Es posible |
Es posible |
| Repeatable Read |
- |
- |
Es posible |
| Serializable |
- |
- |
- |
Podemos consultar el nivel de aislamiento que estamos utilizando,
consultando el contenido de la variable global y de sesión
@@transaction_isolation.
-- Variable global
SELECT @@GLOBAL.transaction_isolation;
-- Variable de sesión
SELECT @@SESSION.transaction_isolation;
También podemos consultar el contenido de la variable de sesión sin
utilizar la palabra reservada SESSION.
SELECT @@transaction_isolation;
Ejemplo: Evaluación de los
niveles de aislamiento ante el problema Dirty Read.
En este ejemplo vamos a simular que hay dos usuarios que quieren
acceder de forma concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos terminales para conectarnos
a un servidor MySQL. Desde el terminal A vamos a
ejecutar las siguientes sentencias SQL:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
INSERT INTO cuentas VALUES (2, 2000);
INSERT INTO cuentas VALUES (3, 0);
-- 1. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 2. Ejecutamos una transacción para transfereir dinero entre dos cuentas
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
NOTA: Observe que la transacción que
estamos ejecutando en el terminal A todavía no ha finalizado, porque no
hemos ejecutado COMMIT ni ROLLBACK.
Ahora desde el terminal B ejecute las siguientes
sentencias SQL:
-- 1. Seleccionamos la base de datos
USE test;
-- 2. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 3. Iniciamos una transacción y observamos los datos que existen en la tabla cuentas
START TRANSACTION;
SELECT * FROM cuentas WHERE id = 1;
Ahora ejecute ROLLBACK en el terminal A
para finalizar la transacción que estaba sin finalizar.
-- 3. Deshacemos las operaciones realizadas en la transacción
ROLLBACK;
Desde el terminal B vuelva a ejecutar esta
sentencia:
-- 4. Observamos los datos que existen en la tabla cuentas
SELECT * FROM cuentas WHERE id = 1;
¿Qué es lo que ha sucedido? Repita el ejercicio utilizando los otros
niveles de aislamiento (READ COMMITTED,
REPEATABLE READ y SERIALIZABLE). Tendrá que
configurar el nivel de aislamiento que va a utilizar durante la sesión
con las siguientes sentencias:
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Ejemplo: Evaluación de los
niveles de aislamiento ante el problema Non-Repeatable
Read.
En este ejemplo vamos a simular que hay dos usuarios que quieren
acceder de forma concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos terminales para conectarnos
a un servidor MySQL. Desde el terminal A vamos a
ejecutar las siguientes sentencias SQL:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
INSERT INTO cuentas VALUES (2, 2000);
INSERT INTO cuentas VALUES (3, 0);
-- 1. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 2. Ejecutamos una transacción para transfereir dinero entre dos cuentas
START TRANSACTION;
SELECT * FROM cuentas WHERE id = 1;
NOTA: Observe que la transacción que
estamos ejectando en el terminal A todavía no ha finalizado, porque no
hemos ejecutado COMMIT ni ROLLBACK.
Ahora desde el terminal B ejecute las siguientes
sentencias SQL:
-- 1. Seleccionamos la base de datos
USE test;
-- 2. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 3. Iniciamos una transacción y atualizamos los datos de la tabla cuentas
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
-- 4. Finalizamos la transacción con COMMIT
COMMIT;
Ahora volvemos a ejecutar en el terminal A la misma
consulta que ejecutamos al inicio de la transacción.
-- 4. Volvemos a ejecutar la misma sentencia para observar los datos que existen en la tabla cuentas
SELECT saldo FROM cuentas WHERE id = 1;
¿Qué es lo que ha sucedido? Repita el ejercicio utilizando los otros
niveles de aislamiento (READ COMMITTED,
REPEATABLE READ y SERIALIZABLE). Tendrá que
configurar el nivel de aislamiento que va a utilizar durante la sesión
con las siguientes sentencias:
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Ejemplo: Evaluación de los
niveles de aislamiento ante el problema Phantom Read.
En este ejemplo vamos a simular que hay dos usuarios que quieren
acceder de forma concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos terminales para conectarnos
a un servidor MySQL. Desde el terminal A vamos a
ejecutar las siguientes sentencias SQL:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
INSERT INTO cuentas VALUES (2, 2000);
INSERT INTO cuentas VALUES (3, 0);
-- 1. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 2. Ejecutamos una transacción para transfereir dinero entre dos cuentas
START TRANSACTION;
SELECT SUM(saldo) FROM cuentas;
NOTA: Observe que la transacción que
estamos ejectando en el terminal A todavía no ha finalizado, porque no
hemos ejecutado COMMIT ni ROLLBACK.
Ahora desde el terminal B ejecute las siguientes
sentencias SQL:
-- 1. Seleccionamos la base de datos
USE test;
-- 2. Configuramos que en esta sesión vamos a utilizar el nivel de aislamiento READ UNCOMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 3. Iniciamos una transacción y atualizamos los datos de la tabla cuentas
START TRANSACTION;
INSERT INTO cuentas VALUES (4, 3000);
-- 4. Finalizamos la transacción con COMMIT
COMMIT;
Ahora volvemos a ejecutar en el terminal A la misma
consulta que ejecutamos al inicio de la transacción.
-- 4. Volvemos a ejecutar la misma sentencia para observar los datos que existen en la tabla cuentas
SELECT SUM(saldo) FROM cuentas;
¿Qué es lo que ha sucedido? Repita el ejercicio utilizando los otros
niveles de aislamiento (READ COMMITTED,
REPEATABLE READ y SERIALIZABLE). Tendrá que
configurar el nivel de aislamiento que va a utilizar durante la sesión
con las siguientes sentencias:
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
## Políticas de bloqueo
Cuando una transacción accede a los datos lo hace de forma exclusiva,
de modo que una transacción no podrá acceder a los datos que están
siendo utilizados por una transacción hasta que ésta haya terminado.
El bloqueo de los datos se puede realizar a nivel de:
- Base de datos.
- Tabla.
- Fila.
- Columna.
InnoDB realiza por defecto un bloqueo a nivel de
fila.
Ejemplo
En este ejemplo vamos a simular que hay dos usuarios que quieren
acceder de forma concurrente a los mismos datos de una tabla. Para
simular los dos usuarios vamos a iniciar dos terminales para conectarnos
a un servidor MySQL. Desde el terminal A vamos a
ejecutar las siguientes sentencias SQL:
DROP DATABASE IF EXISTS test;
CREATE DATABASE test CHARACTER SET utf8mb4;
USE test;
CREATE TABLE cuentas (
id INTEGER UNSIGNED PRIMARY KEY,
saldo DECIMAL(11,2) CHECK (saldo >= 0)
);
INSERT INTO cuentas VALUES (1, 1000);
INSERT INTO cuentas VALUES (2, 2000);
INSERT INTO cuentas VALUES (3, 0);
-- 1. Ejecutamos una transacción para transfereir dinero entre dos cuentas
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
NOTA: Observe que la transacción no que
estamos ejectando en el terminal A todavía no ha finalizado, porque no
hemos ejecutado COMMIT ni ROLLBACK.
Ahora desde el terminal B ejecute las siguientes
sentencias SQL:
-- 1. Seleccionamos la base de datos
USE test;
-- 2. Observamos los datos que existen en la tabla cuentas
SELECT *
FROM cuentas;
-- 3. Intentamos actualizar el saldo de una de las cuentas que está siendo utilizada en la transacción del terminal A
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
¿Qué es lo que ha ocurrido en el terminal B? ¿Puedo
acceder a los datos para consultaros? ¿Y para modificarlos? ¿Puedo
modificar desde el terminal B una cuenta bancaria que
no esté siendo utilizada por la transacción del terminal
A?
Ahora ejecute COMMIT en el terminal A
para finalizar la transacción que estaba sin finalizar. ¿Qué es lo que
ha sucedido?
Cómo realizar transacciones con
procedimientos almacenados
Podemos utilizar el manejo de errores para decidir si hacemos
ROLLBACK de una transacción. En el siguiente ejemplo vamos
a capturar los errores que se produzcan de tipo
SQLEXCEPTION y SQLWARNING.
Ejemplo:
DELIMITER $$
CREATE PROCEDURE transaccion_en_mysql()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
-- ERROR
ROLLBACK;
END;
DECLARE EXIT HANDLER FOR SQLWARNING
BEGIN
-- WARNING
ROLLBACK;
END;
START TRANSACTION;
-- Sentencias SQL
COMMIT;
END
$$
En lugar de tener un manejador para cada tipo de error, podemos tener
uno común para todos los casos.
DELIMITER $$
CREATE PROCEDURE transaccion_en_mysql()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION, SQLWARNING
BEGIN
-- ERROR, WARNING
ROLLBACK;
END;
START TRANSACTION;
-- Sentencias SQL
COMMIT;
END
$$
