Cómo deshabilitar el almacenamiento en memoria caché de hibernación

Question

Estoy tratando de escribir una clase de prueba unitaria que tendrá que usar la misma consulta para obtener los resultados de la base de datos dos veces en el mismo método de prueba. Pero como la memoria caché de Hibernate está habilitada por segunda vez, no está llegando a la base de datos y simplemente buscando los resultados de la memoria caché.

¿Puede alguien responder cómo deshabilitar el almacenamiento en caché en persistence.xml.

He intentado deshabilitar cambiando las propiedades hibernate.cache.use.query_cache = false y hibernate.cache.use_second_level_cache = false.

Pero no funcionó.

Answer 1

¿Puede alguien responder cómo deshabilitar el almacenamiento en caché en persistence.xml.

El caché de segundo nivel y la caché de consultas están desactivados por defecto (y consultas no se almacenan en caché a menos que explícitamente caché de ellos). El caché de primer nivel no se puede deshabilitar.

Me trataron de desactivar por las propiedades cambiantes (...)

esto podría desactivar el caché de segundo nivel y la caché de consultas, si estaban activadas.

Pero no funcionó.

Para ser honesto, "no funcionó" es una descripción muy pobre de la conducta actual frente a la esperada. Proporcionar más detalles, (pseudo) código, rastreos de SQL probablemente sería útil.

Dicho esto, si la pregunta es sobre HQL, una consulta HQL definitivamente debe golpear la base de datos en la ejecución posterior (sin ningún caché de consultas). Active el registro de SQL si es necesario para observar esto.

Si la pregunta es sobre Session#get() o Session#load(), entonces se podría recargar el estado de una entidad utilizando Session#refresh() o llame Session#clear() para borrar por completo la sesión.

Answer 2

De acuerdo con un chico del equipo de hibenrate:

El caché de segundo nivel no tiene nada que ver con el primer nivel (sesión o contexto persistencia) de caché. La caché de contexto/sesión de persistencia es obligatoria por varias razones. En el hecho , no entendiendo esta parte crucial y haciendo caso omiso de ella en la aplicación la arquitectura es una receta para el desastre. No hay una solución rápida aquí, estudio alguna documentación.

Fuente: https: //forum.hibernate.org/viewtopic.php p = 2383408
Es posible utilizar seesion.evict (el objeto) antes de reintentar la misma consulta?.

Answer 3

Uso StatelessSession:

http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/batch.html

Answer 4

Usted puede utilizar:

session.setCacheMode(CacheMode.IGNORE)

después de su:

session.createQuery("from Table") comunicado.

Esto asegurará que Hibernate no interactúe con la memoria caché de segundo nivel para ninguna entidad devuelta por esta consulta.

Answer 5

Si crea una nueva sesión (diferente) dentro de la prueba de su unidad, "no" usará la anterior. O si se llama a clear() en primer lugar (otra opción), etc.

Answer 6

Hibernate tiene dos niveles de caché,

1. caché de sesión (caché de primer nivel) es la memoria caché por defecto y no existe un mecanismo deshabilitar.

2. Caché de nivel de SessionFactory (segundo nivel): tenemos que configurar esto en el archivo cfg de Hibernate por configurando cache_provider.

   Tenía un requerimiento para cargar datos pesados ​​de DB, y usé sesión sin estado debido a las siguientes funciones.

   a. Stateless session does not support session cache and never interact with 
       second level cache. 
   b. Stateless session does not support automatic dirty check. 
   c. Stateless session does not support cascading to associated entities. 
   

   sintaxis para crear la sesión sin estado:

   StatelessSession statelessSession = sessionFactory.openStatelessSession(); 
   

Answer 7

Después de la primera vez que se consulta el resultado, llaman Session.clear y luego la misma consulta se golpeó la base de datos en lugar de caché de nivel 1