Diferencias drásticas que puede esperar si almacena en caché lo que es bueno almacenar en caché y evita almacenar en caché datos que no deberían almacenarse en caché en absoluto. Al igual que la belleza está en el ojo del espectador, lo mismo ocurre con la actuación. Aquí hay varios aspectos que debe tener en cuenta al usar hibernate como proveedor de caché de segundo nivel:
Sin serialización personalizada:uso intensivo de memoria
Si usa el almacenamiento en caché de segundo nivel, no podrá usar marcos de serialización rápidos como Kryo y tendrá que ceñirse a Java serializable, lo cual apesta.
Además de esto, para cada tipo de entidad, tendrá una región separada y dentro de cada región, tendrá una entrada para cada clave de cada entidad. En términos de eficiencia de la memoria, esto es ineficiente.
Carece de la capacidad de almacenar y distribuir objetos valiosos
La mayoría de los cachés modernos también presentan una funcionalidad de cuadrícula de cómputo que hace que sus objetos se fragmenten en muchas piezas pequeñas, lo que reduce su capacidad para ejecutar tareas distribuidas con ubicación compartida de datos garantizada. Eso depende un poco del proveedor de Grid, pero para muchos sería una limitación.
Rendimiento subóptimo
Según el rendimiento que necesite y el tipo de aplicación que tenga, usar la memoria caché de segundo nivel de hibernación puede ser una buena o mala elección. Bueno en cuanto a que es plug and play......" tipo de..." malo porque nunca exprimirás el rendimiento que hubieras obtenido. Además, diseñar modelos enriquecidos significa más trabajo inicial y más programación orientada a objetos.
Capacidades de consulta limitadas EN el propio caché
Eso depende del proveedor de caché, pero algunos de los proveedores realmente no son buenos haciendo JOIN con la cláusula Where diferente a la ID. Si intenta crear un índice de memoria para una consulta en Hazelcast, por ejemplo, verá lo que quiero decir.
