Arquitecturas almacenamiento cache - Tensho97/Aprende-a-Aprender GitHub Wiki
A continuación se describen algunas particularidades que deben ser contempladas al aplicar cache en las distintas capas de una aplicación web.
Capa web o de presentación
Capa de negocio
En esta capa la caché se aplicará a los métodos de los servicios que presenten un elevado tiempo de cómputo o que sean invocados con mucha frecuencia para los mismos parámetros.
La gestión de la caché en esta capa puede ser delegada a Spring, aplicando una capa de abstracción cuya configuración se aplicará automáticamente mediante aspectos a través de las anotaciones @Cacheable y sus derivados.
Capa de persistencia de datos
Resulta de gran utilidad aplicar mecanismo de cache para gestionar el acceso a la base de datos.
Para ello, podemos apoyarnos en Hibernate como gestor ORM (Object/Relational Mapping).
Hibernate permite especificar los siguientes tipos básicos de caché:
-
Caché L1 o caché de primer nivel: Este nivel de caché siempre está activo y hace referencia a la caché de sesión de Hibernate. Dentro de una transacción se habría una sesión de persistencia en la que Hibernate mantendrá los objetos que se recuperan de base de datos, o que están listos para guardarse. Este tipo de caché no es necesario configurarla.
-
Caché L2 o caché de segundo nivel: El nivel 2 de caché se refiere a la capacidad de mantener datos de caché entre sesiones de persistencia, es decir, entre transacciones. Además, a diferencia de la caché de primer nivel, este tipo de caché se comparte entre todos los usuarios de la aplicación.
-
Query caché: Caché que permite el almacenamiento del resultado de la ejecución de queries. Al igual que la caché de segundo nivel este tipo de caché es compartida entre usuarios.
A la hora de aplicar la caché, ésta se podrá indicar de las siguientes formas: * A nivel de entity. * A nivel de query.
En el nivel de entity se marca como cacheable toda una tabla y/o las relaciones que pudiese contener. Este tipo de configuración es adecuada para el caso de tablas que almacenan datos maestros o que se sabe que serán inmutables a lo largo de toda una ejecución de la aplicación.
En el nivel de query se marca como cacheable una sentencia concreta (téngase en cuenta que la sentencia se ejecuta empleando el api de Hibernate, generalmente criterias, y no directamente contra base de datos) activando el flag de cacheable y estableciendo la cacheRegion. Este tipo de configuración es adecuada para sentencias complejas, que involucran joins con distintas tablas, pero cuyo resultando no cambia cuando se emplean los mismos parámetros.
Autor: Richard