Mi granito de java: JBoss Cache

Google+ Badge

martes, 14 de junio de 2011

JBoss Cache

Es un cache transaccional, clusterizado y basado en una estructura de árbol. Obviamente también puede funcionar en modo “standalone“ y sin clusterizarlo.

Lo podemos bajar de su page oficial: http://www.jboss.org/jbosscache en la sección Downloads. Si leemos la documentación oficial veremos que hay una versión que especial para trabajar con clases POJOs y el cache viene prreparado para trabajar sus relaciones. No vamos a tener en cuenta esta particular versión.

Sus ventajas más importantes son:
  • API simple para trabajar el cache.
  • Es eficiente y “thread-safe”.
  • Posibilidad de replicar a algunos o todos los clusters.
  • Persistencia a disco o remota.
  • Garbage collector inteligente.

Como funciona.

Esta organizado como un árbol, con un único elemento raiz. Cada nodo del árbol que tiene un Map donde guarda objetos que hayan implementado la interface java.io.Serializable.
La forma más sencilla de comenzar a utilizarlo es mediante su interface Cache que se puede obtener mediante un CacheFactory que se basa en un xml u objeto java. Una vez que se tenga acceso al Cache, se puede navegar su estructura para guarda u obtener datos.

Aqui un ejemplo de como he creado un cache:

El ejemplo sigue así: he colocado 2000 objetos del tipo String y luego los he obtenido. Si vemos la salida por consola observamos que se perdió más tiempo en colocarlo que en obtenerlos.

Para colocar y obtener datos he utilizado 2 métodos:


Los nombres de los nodos es arbritario y es recomendable verlo como un grupo lógico de datos. La clase Fully Qualified Name (Fqn) encapsula un patch a una ruta determinada del árbol.
La interface Cache también publica los métodos put/get/remove que reciben un Fqn como parámetro. Esto evita tener que trabajar con nodos:



Tipos de Cache
Se pueden setear diversos tipos de Cache:
  • LOCAL: local, sin cluster.
  • REPL_SYNC: replica de manera sincronizada con los otros cluster. Implica que los cambios son replicados y el cluster que disparó el cambio de datos se bloquea hasta tener el OK del resto.
  • REPL_ASYNC: replica de manera asincrónica. Es decir, que el cluster que dispara el cambio no se bloquea, sique trabajando.
  • INVALIDATION_SYNC: cuando un dato es actualizado en uno de los clusters, no lo replica, solo envía un mensaje al resto diciendo que sus datos son inválidos. Trabaja de manera sincronizada.
  • INVALIDATION_ASYNC: ídem anterior, pero trabaja de manera asincrónica.

En mi ejemplo, no he utilizado clusters por lo tanto lo seteo de manera local:



Cache Listerners

Hay varios tipos de eventos que podemos “escuchar” si fuese necesario. Como son muchos, no voy a nombrar todos aquí. Les recomiendo que vean el siguiente link para ver todas las posibilidades que hay: http://docs.jboss.org/jbosscache/3.2.1.GA/userguide_en/html_single/index.html#api.listener

Los eventos más comunes para escuchar son:
@CacheStarted
@CacheStopped
@NodeCreated
@NodeModified
@NodeRemoved
@CacheBlocked
@CacheUnblocked

Por suerte los nombres son muy descriptivos y no necesitan mayor explicación. Se utiliza de la siguiente manera:



¿Que más nos ofrece JBoss?
Si quieren seguir investigando hay muchos temas adicionales para ver como CacheLoaders, manejo de transacciones, politicas de Eviction, configuración por xml y estadísticas entre los temas mas importantes.
Publicar un comentario