¿Cuáles son los cachés de primer y segundo nivel en Hibernate?
Respuestas:
1.1) caché de primer nivel
El caché de primer nivel siempre se asocia con el objeto Session . Hibernate usa este caché por defecto. Aquí, procesa una transacción tras otra, lo que significa que no procesará una transacción muchas veces. Principalmente reduce la cantidad de consultas SQL que necesita generar dentro de una transacción dada. Es decir, en lugar de actualizar después de cada modificación realizada en la transacción, actualiza la transacción solo al final de la transacción.
1.2) caché de segundo nivel
El caché de segundo nivel siempre se asocia con el objeto Session Factory . Mientras ejecuta las transacciones, en el medio carga los objetos en el nivel de Session Factory, de modo que esos objetos estarán disponibles para toda la aplicación, no para un solo usuario. Dado que los objetos ya están cargados en la memoria caché, cada vez que la consulta devuelve un objeto, en ese momento no es necesario realizar una transacción de base de datos. De esta manera funciona el caché de segundo nivel. Aquí también podemos usar el caché de nivel de consulta.
Citado de: http://javabeat.net/introduction-to-hibernate-caching/
Hay una muy buena explicación del almacenamiento en caché de primer nivel en el blog Streamline Logic .
Básicamente, el almacenamiento en caché de primer nivel ocurre por sesión, donde el almacenamiento en caché de segundo nivel se puede compartir en varias sesiones.
Aquí una explicación básica de la caché de hibernación ...
El primer nivel de caché está asociado con el objeto "sesión". El alcance de los objetos de caché es de sesión. Una vez que se cierra la sesión, los objetos en caché desaparecen para siempre. El caché de primer nivel está habilitado de manera predeterminada y no puede deshabilitarlo. Cuando consultamos una entidad por primera vez, se recupera de la base de datos y se almacena en el caché de primer nivel asociado con la sesión de hibernación. Si consultamos el mismo objeto nuevamente con el mismo objeto de sesión, se cargará desde la caché y no se ejecutará ninguna consulta SQL. La entidad cargada se puede eliminar de la sesión utilizando el evict()método. La próxima carga de esta entidad volverá a hacer una llamada a la base de datos si se ha eliminado mediante el evict()método. Todo el caché de la sesión se puede eliminar mediante el clear()método. Eliminará todas las entidades almacenadas en caché.
La caché de segundo nivel está separada de la caché de primer nivel que está disponible para ser utilizada globalmente en el alcance de la fábrica de la sesión. el caché de segundo nivel se crea en el ámbito de la fábrica de sesiones y está disponible para usarse en todas las sesiones que se crean utilizando esa fábrica de sesiones en particular. También significa que una vez que se cierra la fábrica de sesiones, todo el caché asociado con él muere y el administrador de caché también se cierra. Cada vez que la sesión de hibernación intenta cargar una entidad, el primer lugar donde busca una copia en caché de la entidad en el caché de primer nivel (asociado con una sesión de hibernación particular). Si la copia en caché de la entidad está presente en el caché de primer nivel, se devuelve como resultado del método de carga. Si no hay una entidad en caché en el caché de primer nivel, entonces se busca la caché de segundo nivel para la entidad en caché. Si el caché de segundo nivel tiene una entidad en caché, se devuelve como resultado del método de carga. Pero, antes de devolver la entidad, también se almacena en el caché de primer nivel, de modo que la próxima invocación para cargar el método para la entidad devolverá la entidad desde el caché de primer nivel y no será necesario volver al caché de segundo nivel. Si la entidad no se encuentra en el caché de primer nivel y el caché de segundo nivel también, entonces se ejecuta la consulta de la base de datos y la entidad se almacena en ambos niveles de caché, antes de regresar como respuesta deload() método.
Esta es una pregunta muy común, por lo que esta respuesta se basa en este artículo que escribí en mi blog.
Caché de primer nivel
Hibernate intenta diferir el Contexto de persistencia hasta el último momento posible. Como expliqué en este artículo , esta estrategia se conoce tradicionalmente como reescritura transaccional.
La escritura rezagada está más relacionada con el enjuague de Hibernate que con cualquier transacción lógica o física. Durante una transacción, la descarga puede ocurrir varias veces.
Los cambios vaciados son visibles solo para la transacción actual de la base de datos. Hasta que se confirme la transacción actual, otras transacciones concurrentes no podrán ver ningún cambio.
Debido al caché de primer nivel, Hibernate puede hacer varias optimizaciones:
Caché de segundo nivel
Una solución de almacenamiento en caché adecuada tendría que abarcar varias sesiones de Hibernate y esa es la razón por la que Hibernate también admite un caché de segundo nivel adicional.
El caché de segundo nivel está vinculado al ciclo de vida de SessionFactory, por lo que se destruye solo cuando SessionFactoryestá cerrado (generalmente cuando la aplicación se está cerrando). El caché de segundo nivel está orientado principalmente a entidades, aunque también admite una solución opcional de almacenamiento en caché de consultas.
Para más detalles, mira este artículo .
de forma predeterminada, NHibernate utiliza el almacenamiento en caché de primer nivel que se basa en objetos de sesión. pero si está ejecutando en un entorno multiservidor, entonces el caché de primer nivel puede no ser muy escalable junto con algunos problemas de rendimiento. Esto sucede debido al hecho de que tiene que hacer viajes muy frecuentes a la base de datos, ya que los datos se distribuyen en varios servidores. en otras palabras, NHibernate proporciona una caché L1 básica, no tan sofisticada en proceso, lista para usar. Sin embargo, no proporciona características que una solución de almacenamiento en caché debe tener para tener un impacto notable en el rendimiento de la aplicación.
así que la pregunta de todos estos problemas es el uso de un caché L2 que está asociado con los objetos de fábrica de la sesión. reduce los largos viajes a la base de datos, por lo que, en última instancia, aumenta el tiempo de respuesta de la aplicación.
Caché de primer nivel
El objeto de sesión contiene los datos de caché de primer nivel. Está habilitado por defecto. Los datos de caché de primer nivel no estarán disponibles para toda la aplicación. Una aplicación puede usar muchos objetos de sesión.
Caché de segundo nivel
El objeto SessionFactory contiene los datos de caché de segundo nivel. Los datos almacenados en el caché de segundo nivel estarán disponibles para toda la aplicación. Pero necesitamos habilitarlo explícitamente.
En un caché de segundo nivel, los archivos hbm de dominio pueden ser de mutable clave y de valor falso. Por ejemplo, en esta clase de dominio, parte de la duración en un día permanece constante como la verdad universal. Por lo tanto, se puede marcar como inmutable en todas las aplicaciones.