3.3 Diseño y procesamiento de transacciones

TRANSACCIONES

Una transacción es una unidad lógica de trabajo o procesamiento (ejecución de un programa que incluye operaciones de acceso a la base de datos). Una transacción es una secuencia de operaciones que llevan la base de datos desde un estado de consistencia1 a otro estado de consistencia, por esto suele decirse también que la transacción es una unidad lógica de integridad. Cuando múltiples transacciones son introducidas en el sistema por varios usuarios, es necesario evitar que interfieran entre ellas de forma tal que provoquen que la BD quede en un estado no consistente; desde este punto de vista, podemos ver una transacción como una unidad lógica de concurrencia. Cuando ocurre un fallo que provoca la caída del sistema, en el momento en el que había varias transacciones en curso de ejecución, muy probablemente dejará erróneos los datos en la BD (estado inconsistente); en estas circunstancias, se debe garantizar que la BD pueda ser recuperada a un estado en el cual su contenido sea consistente, por esto una transacción es considerada también una unidad lógica de recuperación. La idea clave es que una transacción debe ser atómica, es decir, las operaciones que la componen deben ser ejecutadas en su totalidad o no ser ejecutadas en absoluto. Una sentencia de definición o manipulación de datos ejecutada de forma interactiva (por ejemplo utilizar el SQL*Plus de Oracle para realizar una consulta) puede suponer el inicio de una transacción. Asimismo, la ejecución de una sentencia SQL por parte de un programa que no tiene ya una transacción en progreso, supone la iniciación de una transacción. Toda transacción finaliza con una operación de commit (confirmar) o bien con una operación de rollback (anular, abortar o revertir). Tanto una operación como la otra puede ser de tipo explícito (si la propia transacción (su código) contiene una sentencia COMMIT o ROLLBACK) o implícito (si dicha operación es realizada por el sistema de forma automática, por ejemplo tras detectar una terminación normal (éxito) o anormal (fallo) de la transacción). Por defecto, una vez finalizada una transacción, si todas sus operaciones se han realizado con éxito, se realiza un COMMIT implícito de dicha transacción; y si alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implícito de la transacción (es decir, se deshacen todas las operaciones que había realizado hasta el momento del fallo).

Una transacción delimita el principio y el final de una serie de operaciones de acceso a datos ejecutadas en una conexión. Sujeto a las funcionalidades transaccionales del origen de datos, el objeto Connection también permite crear y administrar transacciones. Por ejemplo, mediante el proveedor de Microsoft OLE DB para SQL Server para acceder a una base de datos en Microsoft SQL Server, puede crear varias transacciones anidadas para los comandos que ejecute.

ADO garantiza que los cambios en un origen de datos resultantes de las operaciones en una transacción se produzcan correctamente juntos o no en absoluto.

Si cancela la transacción o si se produce un error en una de sus operaciones, el resultado será como si no se produjese ninguna de las operaciones de la transacción. El origen de datos permanecerá tal como estaba antes de que comenzara la transacción.

ADO proporciona los métodos siguientes para controlar las transacciones: BeginTrans, CommitTrans y RollbackTrans. Use estos métodos con un objeto Connection cuando desee guardar o cancelar una serie de cambios realizados en los datos de origen como una sola unidad. Por ejemplo, para transferir dinero entre cuentas, resta una cantidad de una y agrega la misma cantidad a la otra. Si se produce un error en cualquiera de las actualizaciones, las cuentas ya no se equilibra. La realización de estos cambios dentro de una transacción abierta garantiza que se realicen todos o ninguno de los cambios.

PROPIEDADES

Atomicidad Todas las operaciones de la transacción son ejecutadas por completo, o no se ejecuta ninguna de ellas (si se ejecuta la transacción, se hace hasta el final)

Consistencia Una transacción T transforma un estado consistente de la base de datos en otro estado consistente, aunque T no tiene por qué preservar la consistencia en todos los puntos intermedios de su ejecución. Un ejemplo es el de la transferencia de una cantidad de dinero entre dos cuentas bancarias.

Aislamiento (Isolation) Una transacción está aislada del resto de transacciones. Aunque existan muchas transacciones ejecutándose a la vez, cualquier modificación de datos que realice T está oculta para el resto de transacciones hasta que T sea confirmada (realiza COMMIT). Es decir, para cualesquiera T1 y T2, se cumple que - T1 ve las actualizaciones de T2 después de que T2 realice COMMIT, o bien - T2 ve las modificaciones de T1, después de que T1 haga un COMMIT Pero nunca se cumplen ambas cosas al mismo tiempo. Nota: esta propiedad puede no imponerse de forma estricta2; de hecho, suelen definirse niveles de aislamiento de las transacciones.

Durabilidad Una vez que se confirma una transacción, sus actualizaciones sobreviven cualquier fallo del sistema. Las modificaciones ya no se pierden, aunque el sistema falle justo después de realizar dicha confirmación. El Subsistema de Recuperación del SGBD es el encargado de conseguir el cumplimiento de las propiedades de atomicidad y durabilidad de las transacciones. La conservación de la consistencia es una propiedad cuyo cumplimiento han de asegurar, por un lado los programadores de base de datos, y por otro el Subsistema de Integridad del SGBD. El Subsistema de Control de Concurrencia es el encargado de conseguir el aislamiento de las transacciones.

INICIO DE TRANSACCIÓN Operación que marca el momento en el que una transacción comienza a ejecutarse.

LEER o ESCRIBIR Operaciones de lectura/escritura de elementos de la base de datos, que se realizan como parte de una transacción.

FIN DE TRANSACCIÓN Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si la transacción debe abortarse por alguna razón (si viola el control de concurrencia, por ejemplo), o bien si los cambios realizados por la transacción (hasta ahora en buffers de memoria volátil) pueden aplicarse permanentemente a la base de datos en disco (es decir, si puede realizarse una operación de CONFIRMAR (COMMIT)).

CONFIRMAR La transacción terminó con éxito, todos los cambios que ha realizado se pueden confirmar sin peligro en la BD y ya no serán cancelados.

ABORTAR La transacción terminó sin éxito y toda actualización que ha realizado se debe cancelar. Algunas técnicas de recuperación necesitan operaciones adicionales como las siguientes:

DESHACER Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción completa.

REHACER Especifica que algunas de las operaciones realizadas por una transacción deben repetirse, para asegurar que todas las operaciones realizadas por una transacción que ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es decir, los cambios hayan quedado grabados físicamente en disco).