COMMIT ON EXIT considered harmful

Hace unos 7 años, publiqué un artículo donde proponía algunas mejoras para la propiedad Commit on Exit, pues es una de las cosas que resulta mas difícil de explicar a quienes recién comienzan a programar con GeneXus.

Estamos en proceso de BetaTesting de la GeneXus Tero y seria bueno revisar el uso que le damos esta propiedad.

Que cosas resultan confusas?


Es difícil de explicar a un novato, que si un procedure que tiene Commit on exit = YES, no hace commit. Solo lo hace, cuando se hace un UPDATE/DELETE/INSERT en la base de datos y tiene la propiedad en YES. En cualquier otro caso, no hace commit. La documentacion del wiki si bien lo dice, es confusa.

Es difícil de encontrar, cuales son los objetos que hace commit en un árbol de llamadas. La búsqueda por propiedades nunca funciono del todo bien, y de esta forma, es bien difícil encontrar donde se esta  rompiendo la integridad transaccional.

En los BC, no se toma en cuenta la propiedad, lo cual hace mas confuso aun la cosa.

Creo que algunas de las sugerencias planteadas hace unos años, siguen siendo totalmente necesarias:

1) Tener algún mecanismo para que se puedan los procedures nuevos generados, queden con Commit on Exit =  NO. Seria cambiar el valor default a nivel de la KB.

2) Cambiar los valores posibles del COMMIT on EXIT a: 
  • NO – No hace commit
  • YES – Hace commit SIEMPRE
  • ON UPDATE/INSERT/DELETE – Hace lo que hoy realiza el valor YES (y seria el valor default). 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. 

Como solucionar estos inconvenientes?


En particular, en KB grandes, hemos decidido no utilizar la propiedad Commit on exit (o sea, ponerla en todos los casos en NO) y hacer commit explicito. 
T ambien se puede definir un procedure que se llame DoCommit, sin parámetros que lo único que haga se hacer el commit en forma explicita. 

De esta forma, viendo las referencias del objeto DoCommit, es fácil encontrar cuales son los objetos que hacen commit. 

Comentarios

  1. Muy bueno el blog. Hace tiempo optamos por llamar a un proc PCommit q es lo único q hace. Por lo q decís, entonces seguiremos usando lo mismo. Tal cual , las UTLs son muy importantes, y difícil de hacer búsqueda rápida en Gx.

    ResponderBorrar
  2. Me alegro que te guste el blog.

    Conozco varios colegas que estan haciendo lo mismo. Es una "solución" para un problema que tal vez necesita alguna herramienta adicional para hacerlo mejor.
    Si se pudiera ver en forma explicita cuales son los objetos que hacen commit y ver eso en un treeview o en diagrama seria mas facil y haria innecesaria el inventar un procedimiento pCommit. En un tiempo, Marcos Crispino habia desarrollado una herramienta para hacer exactamente eso, pero luego creo que fue discontinuada.

    ResponderBorrar
  3. También es muy confuso el tema de los commits en GxFlow.

    ResponderBorrar
    Respuestas
    1. No conozco en profundidad el uso de Commits en GXFlow, pero por comentarios, me han dicho que no esta claro cuales son las operaciones que hacen commits y cuales no lo hacen. Tal vez se puedan beneficiar de una herramienta que analice commits y los muestre en forma de diagrama.

      Borrar

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

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

Aplicación monolítica o distribuida?

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