Hibernate estrategia de caché

Question

¿Cómo decido qué CacheConcurrencyStrategy usar?

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

https: //www.hibernate. org / hib_docs / v3 / api / org / hibernación / cache / CacheConcurrencyStrategy.html , pero no explica en detalle suficiente.

Answer 1

El Hibernate documentación hace un muy buen trabajo en su definición:

  

19.2.2. Estrategia: sólo lectura

     

Si su aplicación tiene que leer, pero   no modificar, las instancias de un persistente   clase, un caché de sólo lectura se puede utilizar.   Esta es la más sencilla y óptima   la realización de la estrategia. Incluso es segura   para su uso en un clúster.

     

19.2.3. Estrategia: lectura / escritura

     

Si la aplicación necesita actualizar   datos, un caché de lectura y escritura podría ser   apropiado. Esta estrategia de caché   Nunca se debe utilizar si serializable   nivel de aislamiento es   necesario. Si la caché se utiliza en una   entorno JTA, debe especificar el   propiedad   hibernate.transaction.manager_lookup_class   y nombrar una estrategia para obtener   la TransactionManager JTA. En otra   ambientes, debe asegurarse de que   la transacción se completa cuando   Session.close() o   Session.disconnect() se llama. Si tu   que desee utilizar esta estrategia en una   clúster, debe asegurarse de que la   aplicación de caché subyacente   admite bloqueo. La memoria caché integrada   los proveedores no son compatibles con bloqueo.

     

19.2.4. Estrategia: no estricta lectura / escritura

     

Si la aplicación sólo de vez en cuando   tiene que actualizar los datos (es decir, si se trata de   muy poco probable que dos   transacciones tratarían de actualizar la   mismo elemento al mismo tiempo), y la estricta   no se requiere aislamiento de transacción,   una caché de lectura y escritura no estricta, podría ser   apropiado. Si la caché se utiliza en una   entorno JTA, se debe especificar   hibernate.transaction.manager_lookup_class.   En otros entornos, que debiera   asegurarse de que la transacción es   completado cuando Session.close() o   Session.disconnect() se llama.

     

19.2.5. Estrategia: transaccional

     

La estrategia de caché transaccional   proporciona soporte para completamente   proveedores de caché transaccionales como   JBoss TreeCache. una memoria caché de este tipo sólo puede   ser utilizado en un entorno JTA y   debe especificar   hibernate.transaction.manager_lookup_class.

En otras palabras:

• Sólo lectura: Útil para los datos que se ofrecen en actualizados leer con frecuencia, pero nunca (por ejemplo, los datos referenciales como países). Es simple. Tiene las mejores actuaciones de todos (obviamente).

• Lectura / escritura: deseable si sus necesidades de datos ser actualizado . Pero no proporciona una SERIALIZABLE nivel de aislamiento , lecturas fantasma puede ocurrir (es posible que aparezca al final de una transacción de algo que no estaba allí en el inicio). Cuenta con más sobrecarga de sólo lectura.

• no estricta lectura / escritura: Por otra parte, si se trata de dos hilos separados de transacción poco probable Puede actualizar el mismo objeto, es posible utilizar la estrategia de lectura no estricta-escritura. Tiene menos espacio que los de lectura y escritura. Éste es útil para los datos que se encuentran en raramente actualizados .

• transaccional: Si necesita un completamente transaccional caché. Sólo apto en un entorno JTA.

Por lo tanto, la elección de la estrategia correcta depende del hecho de que los datos se actualizan o no, requieren la frecuencia de cambios y el nivel de aislamiento. Si usted no sabe cómo responder a estas preguntas para los datos que desea poner en la memoria caché, quizás pide una cierta ayuda de un DBA.

Answer 2

READ_ONLY: Se utiliza sólo para las entidades que nunca cambian (excepción si se hace un intento de actualizar dicha entidad). Es muy simple y performante. Muy adecuado para algunos datos de referencia estática que no cambian.

NONSTRICT_READ_WRITE: caché se actualiza después de una operación que cambia los datos afectados se ha cometido. Por lo tanto, consistencia fuerte no está garantizada y hay una ventana de tiempo pequeña en la que los datos obsoletos se pueden obtener de la memoria caché. Este tipo de estrategia es adecuada para los casos de uso que pueden tolerar consistencia eventual.

READ_WRITE: Esta estrategia garantiza consistencia fuerte que logra mediante el uso de cerraduras 'blandas': Cuando se actualiza una entidad en caché, un bloqueo de software se almacena en la memoria caché para esa entidad, así, que es lanzado después de que se confirme la transacción. Todas las transacciones simultáneas que acceder a las entradas-suaves bloqueado obtendrá los datos correspondiente directamente de la base de datos.

TRANSACTIONAL: cambios de caché se realiza en transacciones XA distribuidas. Un cambio en una entidad en caché se confirma o deshace, tanto en la base de datos y la memoria caché en la misma transacción XA.

Answer 3

Lectura de API Docs es bueno, pero también se debe leer la documentación (es increíble) también, Segundo Nivel caché -. Estrategias

Answer 4

1. transaccional -. Utilice esta estrategia para la lectura en la mayoría de datos donde es crítico para evitar que datos antiguos en transacciones concurrentes, en el raro caso de una actualización

2. lectura y escritura -. Una vez más utilizar esta estrategia para la lectura en la mayoría de datos donde es crítico para evitar que datos antiguos en transacciones concurrentes, en el raro caso de una actualización

3. lectura-escritura no estricta - Esta estrategia no hace ninguna garantía de coherencia entre el caché y la base de datos. Utilizar esta estrategia si los datos casi nunca cambia y una pequeña probabilidad de que los datos rancio no es una preocupación crítica.

4. Sólo lectura - Una estrategia adecuada para la concurrencia de datos, que nunca cambia. Utilizarlo durante datos de referencia.

Espero que esto aclare sus dudas!