99

Muchos manejadores de bases de datos (DBMSs) cuentan con sistemas de recuperacin ante fallos, que permiten dejar la base de datos en estado consistente cuando ocurren imprevistos tales como apagones o cadas del sistema.

100

Los manejadores de bases de datos (DBMSs) que ofrecen integridad transaccional permiten establecer unidades de trabajo lgicas (UTLs), que corresponden ni ms ni menos que al concepto de transacciones de base de datos.

101

Podemos ver que una unidad de trabajo lgica (UTL) queda definida por el conjunto de operaciones entre un par de Commits.

102

103

Es importante aclarar que GeneXus incluye la sentencia COMMIT en los programas generados asociados a transacciones y procedimientos, slo en ambientes de trabajo Cliente/Servidor (incluyendo, por tanto, los ambientes Web). El motivo de esto es que en ambientes Cliente/Servidor existe un DBMS que asegura la integridad transaccional, por lo tanto GeneXus efecta la tarea de definir las unidades de trabajo lgicas (UTLs). Dnde incluye GeneXus COMMIT exactamente? En cada procedimiento: al final del programa fuente. En cada transaccin: inmediatamente antes de las reglas con evento de disparo AfterComplete (E inmediatamente despus de las BeforeComplete). Es decir, que por cada iteracin completa que se efecte en tiempo de ejecucin por medio de la transaccin, habr un COMMIT, justo antes de las reglas con evento de disparo AfterComplete. Nota: El tipo de datos Business Component que veremos ms adelante permite actualizar la base de datos desde cualquier objeto GeneXus, pero tambin como veremos, no realiza automticamente un COMMIT.

104

GeneXus ofrece una propiedad a nivel de cada objeto transaccin y procedimiento, para definir si se desea que su programa generado efecte COMMIT, o no. El nombre de la propiedad es Commit on Exit y su valor por defecto es Yes (por eso, toda transaccin y procedimiento por defecto efecta COMMIT). Si se desea que cierta transaccin o procedimiento no tenga en su programa generado COMMIT, bastar con cambiar el valor de la propiedad Commit on Exit a No.

105

Por qu motivo se puede necesitar no efectuar COMMIT en una transaccin o procedimiento? Para personalizar una unidad de trabajo lgica (UTL). Es decir, podemos necesitar ampliar una unidad de trabajo lgica (UTL) para que varias transacciones1 y/o procedimientos, conformen una nica unidad de trabajo lgica (UTL). Ejemplo (mostrado arriba): La transaccin X invoca al procedimiento Y, y se desea que ambos objetos conformen una nica UTL. La transaccin actualiza ciertos registros, y el procedimiento otros, y se desea que ese conjunto total de operaciones conforme una nica UTL (para asegurarnos de que si ocurre una falla, quede efectuado el conjunto completo de actualizaciones a la base de datos, o nada). Para lograrlo podemos eliminar el COMMIT del procedimiento y dejar que se realice en la transaccin (al retornar del procedimiento a la transaccin, para que se ejecute al final de todas las operaciones); de modo que configuraramos la propiedad Commit on Exit del procedimiento con valor: No y dejaramos la propiedad Commit on Exit de la transaccin con el valor por defecto: Yes. Pero adems de esto, es fundamental que la invocacin al procedimiento se realice antes de que se ejecute el COMMIT en la transaccin (ya que la idea es que ambos objetos conformen una nica UTL, y para ello el COMMIT debe efectuarse en la transaccin al retornar del procedimiento); as que la invocacin al procedimiento deber definirse en la transaccin, con un evento de disparo que ocurra antes de la ejecucin del COMMIT (dependiendo de si la transaccin es de un nivel o ms, y de los requerimientos, podra servir AfterInsert por ejemplo, AfterUpdate, o AfterLevel Level Atributo del 2do nivel, o BeforeComplete, pero no AfterComplete). No existe una nica solucin para personalizar una UTL. Lo fundamental es analizar cul objeto puede hacer COMMIT (pudiendo haber ms de una posibilidad) y una vez que se decida cul objeto efectuar COMMIT, las invocaciones que se requieran hacer, debern efectuarse en momentos adecuados, considerando si ya se efectu el COMMIT o no.

----------------------------------------------------------------------------------------------------------1 En ambiente Web existe una importante restriccin a este respecto: si desde una transaccin se invoca a otra, el Commit que realice una no aplica sobre los registros ingresados/modificados/eliminados por la otra. Es decir, el Commit de cada transaccin solo tiene visibilidad sobre los registros operados por esa transaccin, y no por la otra, por lo que dos transacciones distintas no pueden quedar incluidas en una misma UTL. No puede realizarse personalizacin en este caso.

106

Por ejemplo, para que la transaccin y procedimiento vistos conformen una nica UTL, podramos haber optado tambin por la alternativa de que no efecte COMMIT la transaccin (Commit on Exit = No), sino que lo haga el procedimiento al final de todo; y de hacerlo as, no sera un error como s lo sera en la solucin anteriorinvocar al procedimiento utilizando el evento de disparo AfterComplete, porque la transaccin no har COMMIT, sino que lo har el procedimiento. Concluyendo, es cuestin de decidir cul objeto har COMMIT y que las invocaciones que se deban hacer, se hagan en momentos adecuados, para que la UTL personalizada quede bien definida. Otro ejemplo: Sea la transaccin Invoice estudiada hasta el momento. Supongamos que no modificamos el valor predeterminado de la propiedad Commit on Exit. Supongamos ahora que el usuario ejecuta la transaccin, ingresando la factura 1 con todas sus lneas. Luego pasa a ingresar la factura 2 y cuando est ingresando la 3era. lnea de la misma, ocurre un apagn. Al recuperarse la energa y reiniciarse la ejecucin, qu registros habrn quedado grabados en las tablas y cules se habrn perdido? La factura 1 ntegra estar grabada (cabezal y sus lneas). Por qu? Pues porque al terminar de ingresarla y pasar a ingresar la factura 2, se efectu un Commit. La factura 2 con los registros que se haban grabado hasta el momento de la falla de energa, se habr perdido. Por qu? Pues porque la transaccin realiza el rollback de todo lo que se hubiere efectuado luego del ltimo Commit. El cabezal de la factura 2 y las 2 lneas que se haban ingresado no estaban commiteadas an. Observar entonces que el Commit no es por transaccin entera (es decir, todas las iteraciones del cabezal y sus lneas) sino por cada instancia de cabezal + lneas. Si el Commit se realizara una nica vez antes de cerrar la transaccin, entonces si se hubieran ingresado 29 facturas y a la trigsima se cayera el sistema, se perderan las 29 facturas anteriores (se deshara todo, ya que an no se habra alcanzado el Commit). Esto no es as, y si ocurriera una cada del sistema a la trigsima factura ingresada, las 29 anteriores quedarn grabadas (no as la trigsima).

107

En ambiente Web los registros visibles para ser commiteados por una transaccin son los actualizados por la propia transaccin, y por los procedimientos que sta invoque antes de su Commit, pero no los de otra transaccin. Cada transaccin trabaja, as, sobre UTLs distintas. Es por ello que en el primer ejemplo presentado arriba, donde la transaccin X llama a la transaccin Y luego de haber insertado un registro, aunque la transaccin Y realice un Commit al final de que cabezal y lneas sean ingresados, este Commit no valdr sobre el registro que haba sido ingresado previamente por la transaccin X. Este registro quedar perdido, sin Commit. Por la forma de trabajo en Internet, las transacciones Web viven solamente el tiempo entre que el usuario de un navegador selecciona el link o presiona un botn y la nueva pgina es mostrada. Toda modificacin a la base de datos que se haga durante la vida de la transaccin debe ser confirmada o eliminada antes de que la Transaccin Web termine su ejecucin y retorne la pgina resultante. Como consecuencia, una Transaccin Web inicia una UTL (unidad de trabajo lgica) al comenzar a ejecutar y la cierra (ya sea por COMMIT o ROLLBACK) antes de terminar. No puede formar parte de otra UTL. Si un programa llama a una Transaccin Web, sta iniciar otra (nueva) UTL. En cambio no sucede lo mismo con los procedimientos. En el segundo ejemplo mostrado arriba, vemos que podemos formar una UTL que engloba a la transaccin Y y al procedimiento Z sin embargo no podemos incluir a la transaccin X en la misma UTL.

108

Si se necesita que las operaciones de dos o ms transacciones (con o sin procedimientos incluidos) conformen una misma UTL, se pueden emular las transacciones con Web panels y Business Components y utilizar el comando Commit. Dejamos aqu anotado simplemente el tema, para volver a l luego de estudiados los Business Components, donde nos ser posible comprender esta solucin.

109

110