Re:Re:[Aporte] Agregando caches a MLookupFactory

Inicio Foros Foro principal Desarrolladores [Aporte] Agregando caches a MLookupFactory Re:Re:[Aporte] Agregando caches a MLookupFactory

#34806
Javier AderJavier Ader
Participante

Todo se cachea en el cliente; el servidor de aplicaciones no se usa. Optimiza el tiempo de carga inicial de las ventanas y el sistema en general (ya que se evitan muchos accesos al servidor; esto mejora a todos los clientes, ya que compiten menos a nivel de postgres y de red); la contra de esto es que puede generar una carga de memoria un poco mas grande por parte de los clientes y que como dije, para el desarrollo, puede molestar un poco.
Todo este tipo de optimizaciones las encuentro intentando ver porque tarda en mi maquina cargar las ventanas; esta bien que mi maquina es lenta, pero accede a un servidor que recide en la misma (e.d casi no hay penalidades de red ni compentencia con otros clientes). Algunos tests me llevaban a que la ventana de EC tarde en abrirse cerca de 20 segundos; despues de la primer apertura (por que el codigo acutal algunas cosas si cachea) cerca de 10 segundos; con las mejoras bajaba a 14 para la primer carga y algo asi como 6.5.

Bueno, aprovecho y pongo otra mejora de caches: la función de acceso a DB es MLookup.isRecordID; en el caso de la carga de la ventana EC esta funcion genera algo asi como 60 accesos al servidor. Esta función es llamada solo desde MLookup.getDisplay (asi que seguro que genera accesos innesarios incluso despues de la carga de la ventana). EL codigo proviene de una modificación de Dataware (al menos eso dice el coentario) y mas alla de si es de dudosa utilidad o no , la idea de isRecordID es obviamente cachaeble: es el nombre de una columna “Record_ID”? Los nombres de las columnas dificilmente cambien, asi que ir al servidor a cada rato para verificar esto es costo innecesario. Lo que hice fue modificar isRecordID y delegar siempre este chequeo a la clase UpdateRecord_IDReports (por que supongo que esta relacionada con la modificación hecha; pienso que es un lugar correcto). El nuevo isRecordID() es simplemente

Code:
private boolean isRecordID() {

///Ader: mejora: MLookup.isRecordID
//se delega SIEMPRE a UpdateRecord_IDReports
return UpdateRecord_IDReports.isRecordID(m_info.Column_ID);
}

E.d no genera un acceso al servidor.
UpdateRecord_IDReports tiene el nuevo metodo isRecordID que tiene una cache de cuales ids de columnas tienen el nombre “Record_ID” (son muy pocas, asi que mantenerla en memoria es poco costoso). También tiene otra cache, pero esta vez asociada al metodo UpdateRecord_IDReports.HaveNameColumn ya existente (este metodo es llamado menos veces que el MLookup.isRecordID, pero bueno, de nuevo, no tiene sentido no cachear esta info).

Acá les pongo el UpdateRecord_IDReports directamente; la modificación para la primer cache es poco mas complicada (UpdateRecord_IDReports se tiene que dar cuenta cuando la cache es vaciada; tengo un usar un Listener del evento que dispara CCache).
http://www.eltita.com.ar/libertya/caching/UpdateRecord_IDReports.java