GeneXus - Cache de Sentencias
He estado alejado del Blog, pues tuvimos que migrar una aplicacion programada en GeneXus de generar Visual FoxPro a Java.
Si bien es una tarea posible, dio mas trabajo que el esperado, por errores de programacion propios, por errores de GeneXus y por diferencias en la arquitectura de la apliccion (**Mas de esto en un blog posterior).
Una de las grandes ventajas que trae el Generador Java, que lo diferencia del de Visual FoxPro, es la posibilidad de la utilizacion de Cache de Sentencias SQL, en la aplicacion.
La habilitacion de dicha funcionalidad, es trivial:
Simplemente se cambia una propiedad del modelo
Ademas mejora la escalabilidad de la misma, pues la base de datos, reacciona mucho mejor.
Como toda cosa simple y poderosa, tiene su lado peligroso. Enumero alguno de los casos que encontre.
Tabla de Cotizaciones
Es una tabla que guarda la cotizacion diaria de las monedas con las que opera el sistema. Dicha cotizacion se ingresa una vez al dia, y luego es utilizada ampliamente por todo el sistema.
Dicha tabla, seria una muy buena candidata a ser incorporada al Cache, con una frecuencia de cambio baja.
Sin embargo, si una aplicacion, va a buscar la cotización y dicha cotizacion no esta ingresada, durante todo el tiempo de vida que se le ingreso a esa tabla (60 o 600 minutos) va a seguir diciendo que no existe dicha cotizacion, lo cual es muy malo.
Tabla de Calculos, en Sueldos/Nominas.
Dicha tabla tiene la lista de los impuestos/recargos/descuentos y lo s calculos que se deben realizar para obtener una liquidacion de sueldos, que utiliza esta tabla en forma intensiva.
Seria muy bueno, poder hacer el cache de dicha tabla, porque se modifica muy poco y se utiliza en forma intensiva, al menos en la liquidacion de sueldos.
La contra que tiene, es que esta tabla, siempre es modificada,minutos antes de hacerse la liquidacion, para hacer algun ajuste de ultima hora, para reflejar la normativa y leyes laborales, que en Uruguay son muy variantes.
Por lo tanto, tambien es muy peligroso marcarla como cacheable a esa tabla.
Posibles soluciones.
Una de las soluciones posibles, seria tener la posibilidad de Invalidar el Cache. Para una aplicacion de 2 capas, esto es posible, pero invalida el cache que tiene la conexion que estoy manejando. Tambien seria bueno una invalidacion del Cache, pero a nivel de toda la base de datos, por lo que al manejador de cache, habria que agregarle algun mecanismo de cola de mensajes o algun tipo de suscripcion.
TTL variables en el tiempo o por proceso..
Seria bueno poder setear el Tiempo de vida (TTL) de las sentencias en runtime. Esto complicaria muchisimo la especificacion, pero daria bastante mas potencia.
Por ejemplo lo que me interesa es que durante la duracion de la liquidacion de sueldos, la tabla de impuestos sea cacheada y no varie, durante toda la corrida (que puede demorar 2 minutos o 10 horas, dependiendo la cantidad de registros que tenga).
Si bien es una tarea posible, dio mas trabajo que el esperado, por errores de programacion propios, por errores de GeneXus y por diferencias en la arquitectura de la apliccion (**Mas de esto en un blog posterior).
Una de las grandes ventajas que trae el Generador Java, que lo diferencia del de Visual FoxPro, es la posibilidad de la utilizacion de Cache de Sentencias SQL, en la aplicacion.
La habilitacion de dicha funcionalidad, es trivial:
Simplemente se cambia una propiedad del modelo
Se clasifican las tablas como:
- No Cacheable (Si esa tabla esta en una sentencia no se guarda en el cache)
- Se modifica muy poco (La sentencias tienen tiempo de vida de 600 min, esto es configurable)
- Se modifica poco (La sentencia tiene un tiempo de vida de 60 min)
- No se modifica nunca (La sentencias son inmortales!).
Ademas mejora la escalabilidad de la misma, pues la base de datos, reacciona mucho mejor.
Como toda cosa simple y poderosa, tiene su lado peligroso. Enumero alguno de los casos que encontre.
Tabla de Cotizaciones
Es una tabla que guarda la cotizacion diaria de las monedas con las que opera el sistema. Dicha cotizacion se ingresa una vez al dia, y luego es utilizada ampliamente por todo el sistema.
Dicha tabla, seria una muy buena candidata a ser incorporada al Cache, con una frecuencia de cambio baja.
Sin embargo, si una aplicacion, va a buscar la cotización y dicha cotizacion no esta ingresada, durante todo el tiempo de vida que se le ingreso a esa tabla (60 o 600 minutos) va a seguir diciendo que no existe dicha cotizacion, lo cual es muy malo.
Tabla de Calculos, en Sueldos/Nominas.
Dicha tabla tiene la lista de los impuestos/recargos/descuentos y lo s calculos que se deben realizar para obtener una liquidacion de sueldos, que utiliza esta tabla en forma intensiva.
Seria muy bueno, poder hacer el cache de dicha tabla, porque se modifica muy poco y se utiliza en forma intensiva, al menos en la liquidacion de sueldos.
La contra que tiene, es que esta tabla, siempre es modificada,minutos antes de hacerse la liquidacion, para hacer algun ajuste de ultima hora, para reflejar la normativa y leyes laborales, que en Uruguay son muy variantes.
Por lo tanto, tambien es muy peligroso marcarla como cacheable a esa tabla.
Posibles soluciones.
Una de las soluciones posibles, seria tener la posibilidad de Invalidar el Cache. Para una aplicacion de 2 capas, esto es posible, pero invalida el cache que tiene la conexion que estoy manejando. Tambien seria bueno una invalidacion del Cache, pero a nivel de toda la base de datos, por lo que al manejador de cache, habria que agregarle algun mecanismo de cola de mensajes o algun tipo de suscripcion.
TTL variables en el tiempo o por proceso..
Seria bueno poder setear el Tiempo de vida (TTL) de las sentencias en runtime. Esto complicaria muchisimo la especificacion, pero daria bastante mas potencia.
Por ejemplo lo que me interesa es que durante la duracion de la liquidacion de sueldos, la tabla de impuestos sea cacheada y no varie, durante toda la corrida (que puede demorar 2 minutos o 10 horas, dependiendo la cantidad de registros que tenga).
Comentarios
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.