second example cache java hibernate orm ehcache second-level-cache

java - example - Estrategia de caché de hibernación



hibernate-ehcache maven (4)

¿Cómo decido qué CacheConcurrencyStrategy usar?

  • NonstrictReadWriteCache ,
  • ReadOnlyCache ,
  • ReadWriteCache ,
  • TransactionalCache .

Leí https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html , pero no lo explico con suficiente detalle.

  1. Transaccional: use esta estrategia para leer sobre todo datos donde es crítico prevenir datos obsoletos en transacciones concurrentes, en el caso raro de una actualización.

  2. Lectura-escritura: vuelva a utilizar esta estrategia para leer principalmente los datos en los que es fundamental evitar datos obsoletos en transacciones concurrentes, en el caso poco frecuente de una actualización.

  3. Lectura-escritura no estricta: esta estrategia no garantiza la coherencia entre el caché y la base de datos. Utilice esta estrategia si los datos casi nunca cambian y una pequeña probabilidad de datos obsoletos no es una preocupación crítica.

  4. Solo lectura: una estrategia de concurrencia adecuada para datos, que nunca cambia. Úselo sólo para datos de referencia.

Espero que esto aclare tu duda!

La documentación de Hibernate hace un buen trabajo definiéndolos:

19.2.2. Estrategia: solo lectura

Si su aplicación necesita leer, pero no modificar, instancias de una clase persistente, se puede usar un caché de solo lectura. Esta es la estrategia de desempeño más simple y óptima. Incluso es seguro para su uso en un clúster.

19.2.3. Estrategia: leer / escribir

Si la aplicación necesita actualizar los datos, un caché de lectura / escritura podría ser apropiado. Esta estrategia de caché nunca debe usarse si se requiere un nivel de aislamiento de transacción serializable. Si el caché se usa en un entorno JTA, debe especificar la propiedad hibernate.transaction.manager_lookup_class y nombrar una estrategia para obtener el TransactionManager JTA. En otros entornos, debe asegurarse de que la transacción se complete cuando se Session.close() o Session.disconnect() . Si desea utilizar esta estrategia en un clúster, debe asegurarse de que la implementación de la memoria caché subyacente admita el bloqueo. Los proveedores de caché incorporados no admiten el bloqueo.

19.2.4. Estrategia: leer / escribir sin restricciones

Si la aplicación solo ocasionalmente necesita actualizar datos (es decir, si es extremadamente improbable que dos transacciones intenten actualizar el mismo elemento simultáneamente), y no se requiere un aislamiento estricto de las transacciones, puede ser apropiado un caché de lectura y escritura no estricto. Si el caché se utiliza en un entorno JTA, debe especificar hibernate.transaction.manager_lookup_class . En otros entornos, debe asegurarse de que la transacción se complete cuando se Session.close() o Session.disconnect() .

19.2.5. Estrategia: transaccional

La estrategia de caché transaccional proporciona soporte para proveedores de caché totalmente transaccionales como JBoss TreeCache. Tal caché solo se puede utilizar en un entorno JTA y debe especificar hibernate.transaction.manager_lookup_class .

En otras palabras:

  • Solo lectura: útil para datos que se leen con frecuencia pero nunca se actualizan (por ejemplo, datos referenciales como los países). Es simple. Tiene las mejores actuaciones de todos (obviamente).

  • Lectura / escritura: deseable si sus datos necesitan actualizarse . Pero no proporciona un nivel de aislamiento SERIALIZABLE , las lecturas fantasmas pueden ocurrir (puede ver al final de una transacción algo que no estaba allí al principio). Tiene más gastos generales que solo lectura.

  • Lectura / escritura sin restricciones: de forma alternativa, si es poco probable que dos hilos de transacciones independientes puedan actualizar el mismo objeto, puede utilizar la estrategia de lectura no escrita sin restricciones. Tiene menos sobrecarga que la lectura-escritura. Este es útil para los datos que rara vez se actualizan .

  • Transaccional: si necesita un caché completamente transaccional . Solo apto en un entorno JTA.

Por lo tanto, elegir la estrategia correcta depende del hecho de que los datos se actualicen o no, la frecuencia de las actualizaciones y el nivel de aislamiento requerido. Si no sabe cómo responder a estas preguntas para los datos que desea poner en la memoria caché, tal vez solicite ayuda a un DBA.

READ_ONLY: se usa solo para entidades que nunca cambian (se lanza una excepción si se intenta actualizar dicha entidad). Es muy sencillo y performante. Muy adecuado para algunos datos de referencia estáticos que no cambian.

NONSTRICT_READ_WRITE: La memoria caché se actualiza después de que se confirmó una transacción que modificó los datos afectados. Por lo tanto, no se garantiza una consistencia sólida y hay una pequeña ventana de tiempo en la que se pueden obtener datos obsoletos del caché. Este tipo de estrategia es adecuado para casos de uso que pueden tolerar la consistencia eventual.

READ_WRITE: Esta estrategia garantiza una consistencia sólida que logra al usar los bloqueos ''blandos'': cuando se actualiza una entidad en caché, también se almacena un candado en la caché para esa entidad, que se libera después de que se realiza la transacción. Todas las transacciones simultáneas que acceden a las entradas con bloqueo suave obtendrán los datos correspondientes directamente de la base de datos.

TRANSACCIONAL: Los cambios de caché se realizan en transacciones XA distribuidas. Un cambio en una entidad en caché se confirma o se revierte tanto en la base de datos como en la caché en la misma transacción XA.