Enrique Medina Montenegro

Twitter  |  LinkedIn

Con más de 14 años de experiencia en el mundo de las TI, donde comenzó desarrollando aplicaciones de escritorio en Delphi o Visual Basic, este Ingeniero en Informática por la Universidad de Alicante (1991-1996) ha ido perfilando su actividad profesional hacia las arquitecturas J2EE, donde siempre ha seguido muy atento, e incluso colaborado en ocasiones, con proyectos open-source como MyFaces, Spring, Hibernate, Groovy o Grails. Ocupando puestos desde Programador Junior hasta Arquitecto Senior de Soluciones, Enrique ha sido testigo de cómo ha ido evolucionando la tecnología en torno al desarrollo de aplicaciones web, adquiriendo un conocimiento y experiencia que le permiten evaluar con detalle las necesidades de cada proyecto y aplicar las herramientas que maximizan su productividad. Actualmente, Enrique se ha especializado en el framework de desarrollo Grails, y ejerce la Dirección Técnica de proyectos basados, entre otras, en esta tecnología.

En el día a día, nuestro equipo de desarrollo Grails se encuentra con algunas incidencias que inicialmente no tienen explicación, pero que una vez se analizan y depuran, se convierten en una lección aprendida para futuros proyectos. Y como nuestra filosofía es compartir el conocimiento con todos nuestros amigos del Observatorio, pues aquí os dejamos un consejo que creemos os puede ahorrar muchos quebraderos de cabeza y horas perdidas (Grails 1.2.1 con plugin Hibernate 1.2.1).

El caso es que en una de nuestras clases del dominio habíamos definido un mapa para poder almacenar valores por clave; un ejemplo típico es una clase que representa un usuario, y queremos almacenar su “nick” en función del programa de chat que utiliza:

class Usuario implements Serializable {

	String login
	String passwd
	String nombre
	String apellidos

	// Diferentes 'nicks' por tipo de chat.
	// ['MSN':'emedina_msn', 'GTalk':'e.medina.m', 'Yahoo':'emedinam', ...]
	Map nicks
}

Cuando definimos un campo de tipo Map en nuestra clase del dominio sin especificar ningún tipo de configuración adicional, Grails genera una tabla auxiliar para almacenar los distintos pares ‘clave:valor’ del mapa, como se observa al generar el esquema de BD:

create table usuario (id bigint generated by default as identity (start with 1), version bigint not null, nombre varchar(255) not null, passwd varchar(255) not null, apellidos varchar(255) not null, login varchar(255) not null, primary key (id));
create table usuario_nicks (nicks bigint, nicks_idx varchar(255), nicks_elt varchar(255) not null);

Además, por defecto, Grails siempre indica como tipo para las columnas que almacenarán la clave y el valor (_idx y _elt, respectivamente) un VARCHAR(255), que puede que no sea lo que estamos buscando. En tal caso, es posible indicar el tipo y el tamaño usando algo de configuración adicional en la clase anterior:

class Usuario implements Serializable {

	String login
	String passwd
	String nombre
	String apellidos

	// Diferentes 'nicks' por tipo de chat.
	// ['MSN':'emedina_msn', 'GTalk':'e.medina.m', 'Yahoo':'emedinam', ...]
	Map nicks

	// Redundante, pero para que se vea el efecto.
	static hasMany = [nicks: String]

	static mapping = {
		nicks indexColumn:[length:50], length:100
	}
}

Lo que siempre decimos en nuestros artículos: Grails hace por ti, pero si quieres cambiarlo, es posible y sencillo. Una vez tenemos nuestra clase ‘Usuario’ creada y configurada como nos interesa, vamos a explicar el asunto principal de este artículo, que es advertiros sobre el uso de la ‘caché’ para este tipo de campos.

Si queremos activar la caché de segundo nivel para optimizar el acceso a datos, lo primero que intentamos es cachear las instancias de ‘Usuario’. Para ello, únicamente debemos añadir lo siguiente a la sección ‘mapping’ de la clase:

class Usuario implements Serializable {

	String login
	String passwd
	String nombre
	String apellidos

	// Diferentes 'nicks' por tipo de chat.
	// ['MSN':'emedina_msn', 'GTalk':'e.medina.m', 'Yahoo':'emedinam', ...]
	Map nicks

	// Redundante, pero para que se vea el efecto.
	static hasMany = [nicks: String]

	static mapping = {
		nicks indexColumn:[length:50], length:100

		cache true
	}
}

Ahora, al pedir por primera vez un determinado usuario, se ejecutarán 2 consultas SQL contra la BD: una para obtener el usuario, y otra para obtener los distintos nicks de ese usuario, ya que dichos nicks se encuentran en una tabla separada de la de usuario en BD, como se ha explicado más arriba; sin embargo, en subsecuentes peticiones del mismo usuario, nos ahorraremos una de las consultas SQL, porque Hibernate nos devolverá la instancia cacheada a nivel de JVM del usuario (recordad que estamos hablando de caché de segundo nivel, es decir, a nivel de JVM), pero todavía seguirá ejecutando una consulta SQL para obtener los nicks. Vamos a intentar optimizarlo más aún:

class Usuario implements Serializable {

	String login
	String passwd
	String nombre
	String apellidos

	// Diferentes 'nicks' por tipo de chat.
	// ['MSN':'emedina_msn', 'GTalk':'e.medina.m', 'Yahoo':'emedinam', ...]
	Map nicks

	// Redundante, pero para que se vea el efecto.
	static hasMany = [nicks: String]

	static mapping = {
		nicks indexColumn:[length:50], length:100, fetch:'join', cache:true

		cache true
	}
}

¿Véis la diferencia? Hemos complementado la variable ‘nicks’ de la sección ‘mappings’ con el modo de ‘fetching’ (cómo debe traerse la asociación con ‘nicks’, si a través de varias ‘select’ adicionales o mediante un ‘outer join’ en una única ‘select’) e indicando que queremos que se cachee el mapa de valores ‘nicks’. Si ahora volvemos a realizar el experimento de pedir el usuario, Hibernate sólo generará una consulta SQL para obtener tanto el usuario como sus nicks, y para ello utilizará un ‘outer join’. Además, en teoría, una vez obtenidos los ‘nicks’ del usuario, los cacheará junto con el propio usuario. Pero, si ya estamos cacheando al propio usuario, y además le decimos que cachee al mapa ‘nicks’ indicando el modo ‘fetch’, se produce un comportamiento curioso que no es el esperado: Hibernate sólo cachea el primero de los ‘nicks’ disponibles, y no el resto, de forma que cuando más adelante pedimos un ‘nick’ distinto del que se ha cacheado, pues nos devuelve un ‘null’ y tenemos un problema.

Aunque parece algo enreversado, la explicación es que a Hibernate no le gusta que se le indique para un mapa el modo ‘fetch’ y que además se cachee. Sin embargo, si quitamos el modo ‘fetch’:

class Usuario implements Serializable {

	String login
	String passwd
	String nombre
	String apellidos

	// Diferentes 'nicks' por tipo de chat.
	// ['MSN':'emedina_msn', 'GTalk':'e.medina.m', 'Yahoo':'emedinam', ...]
	Map nicks

	// Redundante, pero para que se vea el efecto.
	static hasMany = [nicks: String]

	static mapping = {
		nicks indexColumn:[length:50], length:100, cache:true

		cache true
	}
}

Ahora todo funciona a la perfección: en la primera petición de un usuario determinado, se ejecutan 2 consultas SQL, pero a partir de ese momento, y mientras el usuario esté en nuestra caché, no se volverá a molestar a la BD para nada, con la consecuente mejora en rendimiento asociada. Interesante, ¿verdad?

Y esto es todo amigos. En futuros artículos seguiremos profundizando en las tripas de GORM para poder sacarle todo el jugo que podamos. Como dicen mis amigos americanos, ¡stay tuned!

Y no os olvidéis de dejarnos vuestros comentarios si alguno de nuestros artículos os ha sido de utilidad, o si encontráis algo incorrecto o que no podéis hacer funcionar desde vuestro lado. Estaremos encantados de echaros una mano.