COMMIT ON EXIT : Propiedad de Objetos GeneXus

1271803992F3UWxlFEn los objetos Procedure y Transaction Genexus existe la propiedad “Commit on Exit”, que puede tener los valores   YES y NO.
La documentación del Wiki de la comunidad, explica de una forma no demasiado clara para mi lo siguiente:

Values

Yes: The generated program executes a commit at the end of the LUW.
No: The generated program does not execute a commit at the end of the LUW.
Default Value = Yes

Description

Programs generated by GeneXus execute commits at the end of each transaction (referring to the concept of database transaction, not the GeneXus object). This automatic commit is included in all programs that update the database. It is not included in Reports, Work Panels and Web Panels that do not update the database.
Esto funciona bastante bien para la mayoría de los programas. El problema es que no es trivial saber si un programa hace o no commit con solo mirarlo, pues hay que mirar si esta haciendo algun UPDATE o INSERT en la base de datos, sobre todo para procedimientos largos.
En uno de nuestros sistemas, tenemos procesos batch pesados, que tienen exigencias importantes en cuanto a la integridad transaccional, pues el proceso debe grabar todos los cambios correctamente o no grabar nada. Para esto se utilizan procedimientos.
Nos ha pasado en varias oportunidades, que algunos programadores se confían en que la propiedad Commit on Exit esta en YES y en la practica el commit no se realiza.
El ultimo caso que sufrimos fue el de un procedimiento de cerca de 100 líneas, que en la versión anterior hacia un NEW, agregando registros, pero se cambio a grabar a través de un procedimiento, que como iba a ser llamado desde varios procesos, no hacia commit.
Este simple ejercicio de refactoring, hizo que el proceso que antes hacia commit, ahora no lo hiciera y cuando terminaba el proceso se hacia un ROLLBACK de todos los registros grabados. Demoramos varios días en detectar el problema pues todo ejecutaba correctamente.

Sugerencias para mejorar esta situación.

1) Warning al especificar.
Si un objeto tiene un commit on exit en YES y el mismo no hace actualizaciones en la base de datos, dar un warning de forma de poder detectar ese objeto en forma fácil.

2) Cambiar los valores posibles del COMMIT on EXIT a:
  • NO – No hace commit
  • YES – Hace commit SIEMPRE
  • ON UPDATE/INSERT – Hace lo que hoy realiza el valor YES
Creo que podría ser mas fácil de comprender por los programadores que empiezan a utilizar Genexus.

3) Poder distinguir en el Call Browser que objetos hacen commit (explícitos o por la propiedad)
Estaría bueno pintar de un color diferente los objetos que hacen commit REAL en la base de datos, no solo los que tienen la propiedad. Hay un proyecto llamado Neptuno.NET que hace esto, pero estaria bueno que estuviera integrado dentro de GeneXus.

Comentarios

  1. Bo, que rapidez para contestar..
    Se me escapo el post, con una ultima frase que decia

    "Hay un proyecto..."

    y habia ido a buscar la URL de ese proeycto.. pero se aprete el boton equivocado y publique la pagina en vez de guardarla en borrador.

    En cuanto a tu pregunta, me sirve en parte el Neptuno.NET, pero me gustaria que funcionara totalmente integrado a Genexus.

    ResponderBorrar
  2. Ja ja, lo que pasa que ahora que se que regalás chocolates estoy más atento :P

    Es verdad, sería mejor que estuviera la funcionalidad en GeneXus. Es una lástima que el collaborative project que se había planteado no se haya llevado a cabo.

    ResponderBorrar
  3. De todos modos la documentación está mal.

    Deberia decir:

    Yes: The generated program executes a commit when it finishes

    No: The generated program does not execute a commit when it finishes

    'The end of the LUW' está determinado por esta propiead. Si es Yes, entonces termina la LUW al final del proc, si es No, no la termina

    De acuerdo con lo que sugeris de los valores de la propiedad.

    ResponderBorrar
  4. Yo soy partidario de que a nivel de commit no exista automatismos.

    Ojo, pienso desde el punto de vista de aplicaciones básicas y aplicaciones avanzadas.

    Con lo "avanzado" me refiero al uso fuerte de "transacciones", en donde existe fuerte uso del commit y rollback controlado.
    Un programa con un comando en el stack y podría generar todo tipo de inconsistencias en los datos.

    Están también aquellos casos en que el rollback no les importa, y el hacer commit a cada rato u operación, ayudan tanto a salvar los datos como a minimizar los lockeos.

    Entiendo que están las necesidades de aquellos que por descuido no hacen commit, o aquellos que tienen commit en lugares en donde no deben.

    Hoy se tendría que trabajar en soportar todos esos casos, y permitir controlar a nivel de lenguaje regiones (momentos) en los cuales se tiene permitido o no los comandos de commit o rollback.

    ResponderBorrar
  5. David:
    Totalmente de acuerdo contigo.

    Para algun tipo de aplicaciones puede no importar, pero es indispensable tener una opcion para que manejemos el COMMIT nosotros en forma totalmente explicita, para aplicaciones criticas.

    Hoy no se puede lograr totalmente, pues no podemos hacer que los objetos genexus se creen con commit on exit en NO para todos los objetos.

    En GeneXus 9.0, lo haciamos con los objetos Master Style, pero en GeneXus X perdimos esa posibilidad.

    Gracias por el comentario.

    ResponderBorrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.