Transacciones

 TRANSACCIONES

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 se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo SQL, COBOL, C, C++ o Java), y está delimitado por instrucciones (o llamadas a función) de la forma inicio transacción y fin transacción. La transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y el fin transacción.

Propiedades ACID

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

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.

Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones Ti y Tj, se cumple que para los efectos de Ti, o bien Tj ha terminado su ejecución antes de que comience Ti , o bien que Tj ha comenzado su ejecución después de que Ti termine. De este modo, cada transacción ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema.

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.

La responsabilidad de asegurar la consistencia de una transacción es del programador de la aplicación que codifica dicha transacción.

Estados de una Transacción

Una transacción debe estar en uno de los estados siguientes:

• Activa, el estado inicial; la transacción permanece en este estado durante su ejecución.

• Parcialmente comprometida, después de ejecutarse la última instrucción.

• Fallida, tras descubrir que no puede continuar la ejecución normal.

• Abortada, 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, tras completarse con éxito

Una transacción se denomina abortada cuando no termina su ejecución con éxito. Dada la propiedad de atomicidad, una transacción abortada no debe tener efecto sobre el estado de la base de dato.

Una transacción que termina con éxito se dice que está comprometida. Una transacción comprometida que haya hecho modificaciones, transforma la base de datos llevándola a un nuevo estado consistente, que permanece incluso si hay un fallo en el sistema. No se pueden deshacer sus efectos abortándola.

Una transacción se dice que ha terminado si se ha comprometido o bien se ha abortado.

Una transacción comienza en el estado activa. Cuando acaba su última instrucción pasa al estado de parcialmente comprometida. En este punto la transacción ha terminado su ejecución, pero es posible que aún tenga que ser abortada, puesto que los datos actuales pueden estar todavía en la memoria principal y puede producirse un fallo en el hardware antes de que se complete con éxito. Cuando se termina de escribir esta información, la transacción pasa al estado comprometida.

Una transacción llega al estado fallida después de que el sistema determine que dicha transacción no puede continuar su ejecución normal (por ejemplo, a causa de errores de hardware o lógicos). Una transacción de este tipo se debe retroceder. Después pasa al estado abortada.

Esquema copia en la sombra. Este esquema, que se basa en hacer copias de la base de datos, denominadas copias sombra, asume que sólo una transacción está activa en cada momento. El esquema asume que la base de datos es simplemente un archivo en disco. Es un esquema simple pero extremadamente ineficiente.

Ejecuciones Concurrentes

Los sistemas de procesamiento de transacciones permiten normalmente la ejecución de varias transacciones concurrentemente. La razón para usar la ejecución concurrente en una base de datos es esencialmente la misma que para usar multiprogramación en un sistema operativo. El sistema de base de datos debe controlar la interacción entre las transacciones concurrentes para evitar que se destruya la consistencia de la base de dato.

Razones para permitir la concurrencia.

Productividad y utilización de recursos mejoradas: 

 

El CPU y los discos pueden trabajar en paralelo en una computadora. Por tanto, las operaciones de E/S se pueden realizar en paralelo con el procesamiento del CPU. Se puede entonces explotar el paralelismo del CPU y del sistema de E/S para ejecutar varias transacciones en paralelo. Todo esto incrementa la productividad (throughput) del sistema.

Tiempo de espera reducido:

La ejecución concurrente reduce los retardos impredecibles en la ejecución de las transacciones. Además se reduce también el tiempo medio de respuesta: el tiempo medio desde que una transacción comienza hasta que se completa. Si las transacciones operan en partes diferentes de la base de datos es mejor hacer que se ejecuten concurrentemente, compartiendo los ciclos del CPU y los accesos a disco entre ambas.

Planificación

Las planificaciones son secuencias de ejecución. Representa el orden cronológico en el que se ejecutan las instrucciones en el sistema. Obviamente una planificación para un conjunto de transacciones debe consistir en todas las instrucciones de dichas transacciones, y debe conservar el orden en que aparecen las instrucciones en cada transacción individual.

Estas planificaciones son secuenciales. Cada planificación secuencial consiste en una secuencia de instrucciones de varias transacciones, en la cual las instrucciones pertenecientes a una única transacción están juntas en dicha planificación. De este modo, para un conjunto de n transacciones existen n! planificaciones secuenciales válidas distinta.

Si se deja el control de la ejecución concurrente completamente al sistema operativo, son posibles muchas planificaciones, incluyendo las que dejan a la base de datos en un estado inconsistente.

El componente del sistema de base de datos que realiza esta tarea se denomina componente de control de concurrencia.

Secuencialidad

El sistema de base de datos debe controlar la ejecución concurrente de las transacciones para asegurar que el estado de la base sigue siendo consistente.

Secuencialidad en cuanto a conflictos.

Se dice que dos instrucciones i y j están en conflicto si existen operaciones de diferentes transacciones sobre el mismo elemento de datos, y al menos, una de esas instrucciones es escribir.

Secuencialidad en cuanto a vistas.

Se dice que la planificación P es secuenciable en cuanto a vistas si es equivalente a canto a vistas a una planificación secuencial.

Recuperabilidad

Se ejecuta la recuperabilidad, ante la presencia de fallos en una transacción durante una ejecución concurrente. Es necesario ejecutarla para mantener la propiedad de atomicidad de la transacción.

Planificaciones recuperables. Una planificación es recuperable cuando dos transacciones dadas X,Y. La transacción Y lee los elementos de datos que previamente ha escrito la transacción X, La operación comprometer de X aparece antes que la de Y.

Planificaciones sin cascada. Es aquella para la que todo par de transacciones X,Y, tales que Y lee un elemento de datos que ha escrito previamente X, la operación de comprometer de X aparece antes que la operación de lectura de Y.

Retroceso en cascada. Este tipo de planificación ocurre cuando hay que recorrer varias transacciones para recuperar totalmente el estado previo a un fallo en una transacción X.

Implementación del aislamiento

Se han visto las propiedades que debe tener una planificación para dejar a la base de datos en un estado consistente y para permitir fallos en la transacción que se puedan manejar de una manera segura.

Definición de transacciones en SQL.

Las transacciones se terminan con una de las siguientes instrucciones: commit, Rollback.

Commit: Compromete la transacción actual y comienza una nueva.

Rollback: Provoca que la transacción actual aborte.

Videos:Transacciones

             Propiedades ACID

Mas transacciones

Video Uno:   Gestión de transacciones

                                           

Ejemplo de una transacción

BEGIN;
UPDATE cuentas SET balance = balance - 100.00 WHERE nombre = 'Alicia';
SAVEPOINT mi_savepoint;
UPDATE cuentas SET balance = balance + 100.00 WHERE nombre = 'Roberto';

ROLLBACK TO mi_savepoint;
UPDATE cuentas SET balance = balance + 100.00 WHERE nombre = 'Walter';
COMMIT;

END;

Bibliografía:


Páginas  507- 527

 del libro Fundamentos de Base de Datos de 

Silberschatz-Korth-Sudarshan