Introducción a Transacciones.

=Introducción=

Desde el punto de vista del usuario la interacción con la base de datos se lleva a cabo mediante operaciones con significado en el modelo semántico (por ejemplo, una transferencia de fondos en un banco)

Desde el punto de vista de la base de datos estas operaciones pueden estar formadas por varias operaciones elementales (por ejemplo, quitar fondos de una cuenta y añadírselos a otra).

Se llama Transacción a una colección de operaciones que forman una unidad lógica de trabajo. Una Transacción es un unidad de la ejecución de un programa que accede y, posiblemente, actualiza varios elementos de datos.

Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción (la transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y fin transacción).

=Concepto de transacción=

Como ya se había comentado anteriormente una Transacción es una unidad de la ejecución de un programa que accede y, posiblemente, actualiza varios elementos de datos.

Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción (la transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y fin transacción).

=Propiedades de una Transacción=

Propiedades de las transacciones que debe mantener el sistema de base de datos para garantizar la integridad de los datos.

Atomicidad: O se realizan adecuadamente, en la base de datos, todas las operaciones de la transacción o no se realiza ninguna de ellas.

Antes de ejecutar Ti: El valor de A es 1000€ y el valor de B es 2000€, durante la ejecución de Ti: Se produce un fallo que impide que la transacción finalice con éxito (fallos de alimentación, fallos de hardware, errores software, etc.)

Ti: leer(A);

A := A - 50;

escribir(A);

leer(B);

B := B + 50;

escribir(B);

Valores reflejados en la Base de Datos:

El valor de A es 950€ y el valor de B es 2000€.

El estado del sistema deja de reflejar el estado real del mundo que se supone que modela à estado inconsistente.

Inconsistente:

Hay que asegurarse que las inconsistencias no sean visibles en un sistema de base de datos, un sistema puede alcanzar en algún momento un estado inconsistente àIncluso si Ti se ejecuta completamente existe un momento en que la base de datos está en

estado inconsistente los estados inconsistentes sólo deben aparecen durante la ejecución de la transacciones la responsabilidad de asegurar la atomicidad es del sistema de base de datos (en concreto del componente de gestión de transacciones)

Consistencia:

La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute concurrentemente) conserva la consistencia de la base de datos.

El requisito de consistencia es que la suma de A y B no se vea alterada al ejecutar la transacción Si una base de datos es consistente antes de ejecutar una transacción, tiene que seguir siéndolo después de ejecutar dicha transacción.

La responsabilidad de asegurar la consistencia es del

programador que codifica la transacción (la comprobación

de las restricciones de integridad puede ayudar)

Aislamiento: Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza cada transacción ignora al resto de transacciones (para cada Ti el resto de Tj no ha comenzado o ya ha acabado) incluso tras asegurar las propiedades de atomicidad

y consistencia para cada transacción pueden ocurrir problemas si varias transacciones concurrentes entrelazaran sus operaciones de modo no deseado (produciendo un estado inconsistente)

Ti: leer(A);

A := A - 50;

escribir(A);

leer(B); ß una segunda transacción que modifique A y/o B (a porcentaje)

B := B + 50;

escribir(B);

una segunda transacción que

modifique A y/o B (a porcentaje)

La Base de Datos puede quedar en un estado inconsistente aunque las dos transacciones terminen.

Durabilidad:

Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.

-------------------------CONDICIONES-------------------------

Una vez que se completa con éxito la ejecución de una transacción no puede suceder que un fallo del sistema produzca la pérdida de datos.

1.- Las modificaciones realizadas por la transacción se guardan en disco antes de finalizar la transacción.

2.- La información guardada en disco de las modificaciones realizadas por transacción es suficiente para reconstruir dichas modificaciones Condiciones.

La responsabilidad de asegurar la durabilidad es del sistema de base de datos (en concreto del componente de gestión de recuperaciones)

Ejemplos de propiedades.

Sistema Bancario simplificado:

-Constituido por varias cuentas y un conjunto de transacciones que acceden y actualizan dichas cuentas.

-Base de datos residente en disco pero con una porción de la misma

en memoria principal.

-Acceso a través de dos operaciones: leer(X) y escribir(x) (transfiere el dato X desde la Base de Datos/memoria intermedia local de la transacción a una memoria intermedia local de la transacción/Base de Datos)

=Niveles de aislamiento de una transacción=

Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transacción de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o ficticias.

Control de los niveles de aislamiento de transacción:

• Controla si se realizan bloqueos cuando se leen los datos y qué tipos de bloqueos se solicitan.
• Duración de los bloqueos de lectura.
• Si una operación de lectura que hace referencia a filas modificadas por otra transacción:
• Se bloquea hasta que se libera el bloqueo exclusivo de la fila.
• Recupera la versión confirmada de la fila que existía en el momento en el que empezó la instrucción o la transacción.
• Lee la modificación de los datos no confirmados.

El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:

Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.

• Lectura norepetible. Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados o eliminados por una transacción cursada.
• Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de registros que satisfacen una condición de búsqueda y encuentra que otros registro que satisfacen la condición han sido insertadas por otra transacción cursada.

Los niveles de aislamiento SQL son definidos basados en si ellos permiten a cada uno de los eventos definidos anteriormente. Es interesante notar que el estándar SQL no impone un esquema de cierre específico o confiere por mandato comportamientos particulares, pero más bien describe estos niveles de aislamiento en términos de estos teniendo muchos mecanismos de cierre/coincidencia, que dependen del evento de lectura.

Niveles de aislamiento:

Comportamiento permitido

|-----------------------Nivel de Lectura-----------------------|

Nivel de Aislamiento	Sucia	No Repetible	Fantasma
Lectura no Comprometida	Si	Si	Si
Lectura Comprometida	No	Si	Si
Lectura Repetible	No	No	Si
Secuenciable	No	No	No

Según el estándar SQL, SQL Server permite todos estos niveles, Oracle sólo permite la lectura comprometida y secuenciable. Los niveles se pueden establecer en ambos para cada transacción. Sin embargo esto no es necesariamente cierto.

El estándar SQL trataba de establecer los niveles de aislamiento que permitirían a varios grados de consistencia para querys ejecutadas en cada nivel de aislamiento. Las lecturas repetibles "REPEATABLE READ" es el nivel de aislamiento que garantiza que un query un resultado consistente. En la definición SQL estándar, la lectura comprometida "READ COMMITTED" no regresa resultados consistentes, en la lectura no comprometida"READ UNCOMMITTED" las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.

A mayor grado de aislamiento, mayor precisión, pero a costa de menor concurrencia.
El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para las instrucciones SQL.

=Grado de Consistencia=

Consistencia es un término más amplio que el de integridad. Podría definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia. Pero la consistencia también puede perderse por razones de funcionamiento.

Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia).

· Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

· Si se anula los cambios que ha efectuado son deshechos.

La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de integridad definidas).

· Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

· Si se anula los cambios que ha efectuado son deshechos.

Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados.

· Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.

· Parcialmente comprometida (Uncommited): Después de ejecutarse la ultima transacción.

· Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.

· Abortada (Rolled Back): Después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.

· Comprometida (Commited): Tras completarse con éxito.

>>Aspectos relacionados al procesamiento de transacciones

Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:

· Modelo de estructura de transacciones: Es importante considerar si las transacciones son planas o pueden estar anidadas.

· Consistencia de la base de datos interna: Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.

· Protocolos de confiabilidad: En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.

· Algoritmos de control de concurrencia: Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.

· Protocolos de control de réplicas: El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

= Instrucciones COMMIT y ROLLBACK =

Una transacción tiene dos finales posibles, COMMIT y ROLLBACK. Por defecto, MySQL trae activado el modo autocommit, es decir, realizada una transacción

(por ejemplo un INSERT, UPDATE o DELETE)

el mismo es confirmado apenas es ejecutado. Para desactivar el autocommit, se puede desactivar el autocomit ejecutando el comando:

SET AUTOCOMMIT=0;

Una vez deshabilitado el autocommit, tendremos que utilizar obligatoriamente el COMMIT para confirmar o ROLLBACK para deshacer la transacción.

Si se quiere deshabilitar el autocommit para una serie de comandos, lo ideal es utilizar START TRANSACTION (sin necesidad de setear el AUTOCOMMIT en 0).

Al ejecutar una transacción, el motor de base de datos nos garantizará la atomicidad, consistencia, aislamiento y durabilidad (ACID) de la transacción (o conjunto de comandos) que se utilice.

Veremos un ejemplo completo, extraído del articulo fuente de esta publicación, donde utilizaremos START TRANSACTION (no es necesario AUTOCOMMIT en 0)

CREATE TABLE `departamentos` (
`CODIGO` INTEGER(11) NOT NULL DEFAULT ’0′,
`NOMBRE` VARCHAR(100),
`PRESUPUESTO` INTEGER(11) DEFAULT NULL,
PRIMARY KEY (`CODIGO`)
)ENGINE=InnoDB

Ahora, insertaremos registros de la tabla departamentos_externos a departamentos mediante una transacción:

START TRANSACTION;
SELECT @A := presupuesto
FROM departamentos_externos
WHERE codigo =11;
INSERT INTO departamentos( codigo, nombre, presupuesto )
VALUES ( 11, ‘Department test’, @A );
COMMIT;

En el ejemplo anterior se guardo el presupuesto del departamento externo 11 en la variable @A y luego fue asignado al presupuesto en la tabla departamentos.

Ejemplo:

START TRANSACTION;
SELECT @A := presupuesto, @B := codigo, @C := nombre
FROM departamentos_externos
WHERE codigo=33;
INSERT INTO departamentos( codigodep, nombredep, presupuesto ) VALUES (@B , @C , @A );
COMMIT ;

Ejemplo:

START TRANSACTION;
SELECT @A:=PRESUPUESTO FROM departamentos_externos WHERE codigo=11;
UPDATE departamentos SET PRESUPUESTO = PRESUPUESTO + @A WHERE codigo=33;
COMMIT;

Utilizando uno de los ejemplos de arriba sale el ejemplo de RollBack.

usando el ejemplo del amigo de arriba.

START TRANSACTION;

SELECT @A:=PRESUPUESTO FROM departamentos_externos WHERE codigo=11;

UPDATE departamentos SET PRESUPUESTO = PRESUPUESTO + @A WHERE codigo=33;

INSERT INTO departamentos_externos(RESUPUESTO) VALUES(‘valor’) WHERE codigo=11;

ROLLBACK;

Siempre recordando que COMMIT se usa para aceptar la transacción y ROLLBACK si deseamos cancelar la transacción.

Una vez que se realizo una o varias consultas (SELECT,UPDATE,DELETE,INSERT…) Tenemos dos opciones:

Aceptar la transacción o cancelar la transacción, para aceptar la transacción y los datos sean ingresados, actualizados, borrados (depende la sentencia que empleo usado) a la base de datos, utilizas COMMIT.
Para cancelar la transacción (es decir cancelar todas las sentencias realizadas) utilizas ROLLBACK. Y cabe recordar que una vez utilizada la sentencia COMMIT ya no puedes usar ROLLBACK.

Al realizar una transacción SQL hay que tener en cuenta que apenas se realice un INSERT, UPDATE o DELETE se genera un bloqueo sobre la tabla y que otros clientes no pueden acceder para escribir esta tabla. Otros clientes podrán realizar SELECTs sobre la tabla, pero no podrán ver los datos del primer cliente hasta que los mismos sean confirmados. Prometo pronto, tratar con más detalle el tema de bloqueos, específicamente el procesamiento concurrente de transacciones.

un ejemplo de cada uno en la norma SQL el comienzo de una transacción se especifica

explícitamente (usualmente begin/start transaction) las transacciones terminan con una de las siguientes instrucciones:

-commit work (compromete la transacción actual)

-rollback work (provoca que la transacción aborte)

Si el programa termina sin ninguna de estas órdenes, los cambios se comprometen o abortan según indique cada sistema.

Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)