Almacenamiento en caché con Hibernate + Spring-algunas preguntas!

Hibernate soporta las siguientes caches: Caché de 1er Nivel, Caché de 2do Nivel, Caché de Consulta

Sí.

Spring admite las siguientes posibilidades de almacenamiento en caché: solo Método de almacenamiento en caché

Spring 3.1 introduce la nueva abstracción de almacenamiento en caché basada en anotaciones alrededor de los métodos, sí.

La Caché de 1er Nivel es parte de CADA aplicación de Hibernación.

Sí.

La Caché de 1er nivel se crea para cada sesión de hibernación.

Sí, aunque puede borrarlo manualmente en cualquier momento.

¿Qué se guarda en la Caché de 1er nivel? Objetos o solo los valores de sus propiedades? consultas y sus resultados?

Es un mapa de todos los objetos obtenidos durante la vida de una sesión, si carga el mismo objeto por id por segunda vez, se cargará desde L1.

Me enteré: la caché de segundo nivel se usa UNA vez por aplicación. ¿no es falso? no se utiliza UNA vez por sessionfactory? y: múltiples sessionfactorys = múltiples cachés de nivel 2 posible?

Tiene razón, normalmente solo hay una fábrica de sesión por aplicación (base de datos), de ahí el acceso directo.

Lo que se guarda en la Caché de segundo nivel: en mi opinión solo los valores que pertenecen a un registro, no los objetos en sí.

Las mismas cosas que en L1, pero viven más tiempo. L2 es típicamente respaldado por algún caché de fuerza industrial, mientras que L1 es solo un mapa(ni siquiera tiene que ser seguro para hilos). Almacena entidades completas, incluidas las relaciones cargadas de pereza.

Cuando se almacenan valores de un registro en Caché de 2do nivel, ¿es posible almacenar valores relacionados (de objetos conectados a través de una clave externa) con él también?

No administras L2 manualmente, sucede automáticamente.

Al actualizar los valores de un objeto en la caché de 2do nivel, es posible actualizar los valores de los objetos conectados ¿con él en el caché también?

Véase supra.

Cuando los valores de un objeto están cambiando, ¿cómo puedo actualizar la caché de segundo nivel? flush? ¿puedo simplemente actualizar una parte de la caché o debe actualizarse toda la caché?

Ver arriba - Hibernate resolverá esto para usted. Nunca interactúas con L2 directamente.

¿Dónde tiene sentido el caché de 2do nivel y dónde no?

Medida. En aplicación que lee muchos datos por clave primaria y el factor de lectura a escritura es muy alto, L2 tiene un impacto significativo en su rendimiento.

El modo de caché: ¿cada modo de caché proporciona una estrategia diferente de almacenamiento en caché? por ejemplo, con el modo de caché "solo lectura", ¿no es necesaria la sincronización de la base de datos y la caché? ¿otros modos de caché proporcionan sincronización? Pensé que la sincronización debía ser hecha por el propio desarrollador.

El modo de caché ayuda a Hibernar para elegir la mejor estrategia para el almacenamiento en caché y la invalidación. Para instancia si la caché es de solo lectura, Hibernate no se molestará en invalidarla (o no lo hará tan a menudo). Pero la caché de solo lectura (entidad de solo lectura), por supuesto, prohibirá cualquier actualización.

¿Cuál es la diferencia entre la Caché de Consulta y la Caché de segundo nivel? en mi opinión: en la Caché de consulta se guardan los conjuntos de resultados, pero no con sus valores, solo con sus ID. cuando la consulta se utiliza de nuevo y el conjunto de resultados sigue siendo "correcto" , los valores pertenecientes a los ids se consultan desde el Caché de 2do nivel.

Exactamente, pero este es un tema muy amplio. Especialmente el conjunto de resultados sigue siendo la parte "correcta".

Para la Caché de Consulta SE debe utilizar una Caché de segundo nivel?

Sí, sin la caché L2, la caché de consulta no tiene sentido y ralentizará drásticamente la aplicación.

¿Dónde tiene sentido la Caché de consultas y dónde no?

Pregunta difícil, por lo general, cuando se está ejecutando la misma consulta una gran cantidad de times y el universo de parámetros de consulta es bajo (para cada conjunto de parámetros de consulta se crea una nueva caché de consulta con todos los identificadores de registros como los resultados).

¿Spring ofrece más posibilidades de almacenamiento en caché que el método de almacenamiento en caché?

No, la primavera es más o menos solo un pegamento para su propio código.

El almacenamiento en caché de métodos no está vinculado al almacenamiento en caché de hibernación.

La primavera no está vinculada a la hibernación, por lo que...

Pero: para el método de almacenamiento en caché un 2do nivel es necesario, como ehcache (que puede ser utilizado por hibernación también)

L2 es concepto de hibernación. Si desea almacenar métodos en caché, necesita algún caché subyacente. Que sea EhCache, no importa. por supuesto que debe ser seguro para el hilo.

¿Se puede usar el almacenamiento en caché de métodos sin consultas de base de datos?

La primavera no tiene nada que ver con la hibernación. Puede almacenar en caché cálculos que no tienen nada que ver con la base de datos.

Si se usa ehcache para hibernar como caché de nivel 2 y ehcache para spring para el almacenamiento en caché de métodos, ¿puedo usar la misma instancia de ehcache? ¿hay alguna posibilidad de que algo se mezcle?

Puede usar la misma CacheManager y configuración de caché que Hibernate para facilitar la implementación. Mientras los nombres de caché no se superpongan, son completamente independientes, incluso aunque trabajen dentro del mismo administrador.

Al usar caché de 1er nivel y caché de 2do nivel, ¿pueden confundirse? al consultar la base de datos, ¿dónde se encuentra el resultado entonces vienen de, el 1er o 2do nivel de caché? ¿funciona la caché de 1er nivel con la caché de 2do nivel?

Simplemente funcionan, siempre y cuando alguna abstracción no se filtre :-). Cuando consulta por clave primaria, primero se examina L1 (es más rápido), luego L2.

¿Algo más que pueda confundirse usando los cachés que mencioné? :-)

Ver arriba, las abstracciones tienden a filtrarse. Pero los peores problemas vienen cuando se cambia la base de datos y Hibernar no sabe respecto. También agrupamiento sin replicación adecuada le causará un dolor de cabeza. Y el mayor problema-muy a menudo el almacenamiento en caché incorrecto en realidad ralentiza la aplicación (caché de consulta es el más peligroso aquí).