Transacciones

Usando Transacciones

Autor: J. Booth

Traducido por: Pablo Roca

Previamente habíamos hablado sobre TableUpdate y TableRevert() y hemos visto como nos permiten controlar actualizaciones mientras usamos "buffering" en tablas y cursores. Estas dos opciones son muy buenas para manejar la actualización o la reversión de una sóla tabla o cursor, pero cómo coordinamos las actualizaciones o cancelaciones de varias tablas relacionadas. Aquí entran las Transacciones.

Pero, ¿qué es una transacción?

Hay situaciones en las que necesitamos actualizar más de una tabla o cursor y la combinación de actualizaciones representa una de las acciones en la Base de Datos. Esta acción debería ser una operación "todo o nada", es decir, Todo si todo va bien o Nada si algo falla. Por ejemplo, cuando escribimos código para guardar una nueva factura tenemos que añadir un registro en la tabla de cabecera de facturas, añadir un grupo de registros en la tabla de líneas de factura, modificar el saldo en el registro del cliente ya añadir un registro en la tabla de recibos. Si alguna de estas operaciones falla necesitamos deshacer todas las operaciones anteriores que sí han funcionado y asegurarnos que no se han realizado cambios en los datos. Las transacciones se han diseñado para este propósito.

Utilizaremos la instrucción BEGIN TRANSACTION para comenzar el seguimiento de la transacción en Visual FoxPro y la instrucción ENDTRANSACTION para terminar correctamente la transacción o la intrucción ROLLBACK para deshacer la transacción.

¿Cómo funcionan las transacciones?

Cuando VFP encuentra un BEGIN TRANSACTION comienza a hacer un seguimiento de las operaciones de actualización de fichero que se realizan. Para cada modificación VFP obtiene los bloquedos adecuados pero no realiza la actualización todavía. Cuando encuentra un ENDTRANSACTION Visual FoxPro realiza todas las escrituras de fichero involucradas en la transacción y libera los bloqueos que se había procurado con anterioridad. Si encuenta un ROLLBACK, Visual FoxPro abandona los bloqueos sin realizar ninguna operación de escritura.

Gracias a este proceso, Visual FoxPro es capaz de asegurar que todos los cambios se realizarán o no se realizará ninguno. Como podemos apreciar examinando este proceso es una muy buena idea poner las instrucciones BEGIN TRANSACTION y ENDTRANSACTION/ROLLBACK lo más cerca posible una de otra en el código como sea posible. Haciendo esto reduciremos el tiempo en el que los recursos están bloqueados.

¿Qué tablas y cursores pueden participar en una transacción?

En Visual FoxPro las transacciones sólo están disponibles para tablas que están en Bases de Datos (DBC). Las tablas libres no pueden participar en una transacción, y un rollback (roll back es literalmente "enrollar") u otro final anormal de una transacción no afecta a las modificaciones realizadas sobre tablas libres durante una transacción.

Esto puede causar efectos sorprendentes si una tabla libre es la fuente de datos de una tabla local que es gestionada por una transacción. Vamos a examinar los pasos del proceso con una transacción ficticia. En esta transacción hay una tabla perteneciente a una Base de Datos que se llama Tabla1 y una vista llamada Vista1 que consigue los datos de una tabla libre que se llama (originalidad sin fronteras) Tabla2. El código para la transacción es el que sigue:

BEGIN TRANSACTION
IF TableUpdate( 1, .F., "Vista1")

IF TableUpdate ( 1, .F., "Tabla1")

END TRANSACTION

ELSE

ROLLBACK

ENDIF
ELSE

ROLLBACK

ENDIF

Ahora las preguntas, si el TableUpdata de Tabla1 falla, ¿puede el ROLLBACK deshacer los cambios de Vista1 y dejarla en el estado anterior a la transacción? La respuesta es sí, puede deshacer los cambios en Vista1. ¿Pueden los cambios hechos en Table2 como resultado de la actualización de Vista1 ser deshechos por el ROLLBACK? No, porque Tabla2 es una tabla libre y, como tal, no participa en la transacción. Esto puede dejar tus datos en un estado inconsistente, deberías manejar la tabla libre por ti mismo. Lo mejor en no depender de transacciones cuando estén relacionadas tablas libres.

¡Enséñanos el código!

¿Cómo integraremos transacciones en nuestros formularios? Se puede hacer en un formulario directamente o genéricamente en una clase de formularios. Debajo hay un pseudocódigo que nos dará una idea de cómo es la estructura para incorporar transacciones en nuestras actualizaciones.

* Establecer una variable para el seguimiento de fallos
LOCAL llRollBack
llRollBack = .F.
* Esperar hasta que todo el proceso de datos está completo antes de comenzar la transacción
BEGIN TRANSACTION
* Realizar cada actualización comprobando el resultado
IF NOT TableUpdate( ... )

llRollBack = .T.

ELSE

IF NOT TableUpdate( ... )

llRollBack = .T.

ELSE

IF NOT TableUpdate( ... )

llRollBack = .T.

ENDIF

ENDIF

ENDIF
IF llRollBack

ROLLBACK

ELSE

ENDTRANSACTION

ENDIF

Este código de arriba es pseudocódigo, no lo tomes al pie de la letra. Hemos usado una serie de instrucciones IF anidadas para controlar las acciones. Podríamos haber puesto todos los alias en una matriz y utilizar un bulce FOR/ENDFOR para procesarlos, terminando el bucle cuando hubiera un error o termináramos con todos.

¿Qué puede ir mal?

En el pseudocódigo de arriba asumimos que la transacción falla y que se se ha realizado el ROLLBACK. ¿Qué, exactamente, ha hecho el ROLLBACK? ¿Los "buffers" se han dejado en su estado pre-edición o todavía tienen basura de la edición del usuario?

La respuesta es que los "buffers" se restauran al estado en el que estaban antes del BEGIN TRANSACTION. Esto quiere decir que todavía tenemos que ocuparnos de la edición del usuario. Aquí nosotros decidimos, podemos poner lo editado por el usuario de nuevo en el formulario y dejarle decidir a él, o podemos realizar un TableRevert con todos los alias y descartar lo que ha escrito el usuario. El límite lo ponemos nosotros.

¿Qué ocurre si el ordenador se apaga (o cuelga) durante la transacción? Obviamente VFP no tiene registro de la transacción cuando el sistema es reiniciado. Entonces ¿las tablas se han actualizado o no? Ninguna tabla se modificó y el resultado es como se hubiera ejecutado un ROLLBACK.

Otra situación que puede ocurrir y causar muchos problemas es esta, un desarrollador escribe un formulario y pone un BEGIN TRANSACTION en el evento Init y pone un ENDTRANSACTION o un ROLLBACK en el evento destroy, dependiendo del botón que pulse el usuario para salir del formulario. ¿Qué problema puede causar esto? En primer lugar ningún otro usuario puede hacer nada con las tablas implicadas en la transacción mientras tanto, hasta que el usuario sale del formulario y se eliminan los bloqueos. He visto esta situación usada como argumento contra las transacciones. Bueno, vamos allá, cualquier cosa que se utiliza incorrectamente puede causar problemas. Cuando se usan transacciones correctamente se limitará el tiempo entre el comienzo y el final al mínimo imprescindible. Los eventos Init y Destroy de un formulario NO son el menor periodo de tiempo posible. Este periodo de tiempo no está nunca bajo el control del programador.

He visto escrito que las transacciones de Visual FoxPro no son tan "robustas" como las transacciones que utilizan los servidores de bases de datos cliente/servidor. ¿Y qué?. De hecho, los frenos de un tractor son más "robustos" que los frenos de mi coche, ¿ es eso una razón para NO usar los frenos de mi coche? NO. Las transacciones de Visual FoxPro son útiles y sirven para su propósito. Se deben utilizar, incluso cuando los datos están almacenados en un Base de Datos cliente/servidor.

Resumen

Las transacciones de Visual FoxPro son una utilidad muy valiosa del producto. Nos permiten agrupar varias operaciones de actualización en una operación "todo o nada". Hoy por hoy raramente creamos formularios que sólo gestionan una tabla, el formulario con múltiples tabla se ha convertido en una norma. Gestionar estas actualizaciones de varias tablas se ha convertido en un aspecto muy importante de nuestro trabajo y las transacciones tienen un valor inestimable para hacerlo.