Estoy tratando de averiguar qué estrategia de simultaneidad de caché debo usar para mi aplicación (para actualizaciones de entidades, en particular). La aplicación es un servicio web desarrollado con Hibernate, se implementa en clúster Amazon EC2 y funciona en Tomcat, por lo que no hay servidor de aplicaciones allí.Hibernate L2 cache. ¿Estrategia de concurrencia de lectura/escritura o de caché transaccional en el clúster?
Sé que hay no estricta-lectura-escritura \ lectura-escritura y estrategias de concurrencia de caché de transacciones de datos que pueden ser actualizados y no son, listas para producción proveedores de caché 2L populares maduros para la hibernación: Infinispan, Ehcache, Hazelcast.
Pero no entiendo por completo la diferencia entre el transaccional y de lectura y escritura cachés de la documentación de Hibernate. Pensé que el caché transaccional es la única opción para una aplicación de clúster, pero ahora (después de leer algunos temas), no estoy tan seguro de eso.
Así que mi pregunta es acerca de la lectura-escritura caché. ¿Es seguro para clústeres? ¿Garantiza la sincronización de datos entre la base de datos y el caché, así como la sincronización entre todos los servidores conectados? ¿O solo es adecuado para aplicaciones de servidor único y siempre debería preferir la caché transaccional ?
Por ejemplo, si una transacción de base de datos que se actualiza un campo de entidad (nombre de pila, etc.) y no se ha deshecho, será la lectura y escritura caché descartar los cambios o se acaba de llenar los malos datos (el primer nombre actualizado) a todos los otros nodos? ¿Requiere una transacción JTA para esto?
El tema Concurrency strategy configuration for JBoss TreeCache as 2nd level Hibernate cache dice:
'READ_WRITE` es una combinación interesante. En este modo, Hibernate funciona como un XA-coordinador liviano, por lo que no requiere un XA externo completo . Breve descripción de cómo funciona:
- En este modo, Hibernate gestiona las transacciones en sí. Todas las acciones de DB deben estar dentro de una transacción, el modo de confirmación automática no funcionará.
- Durante el proceso de limpieza() (que puede aparecer varias veces durante la vida útil de la transacción , pero generalmente ocurre justo antes de la confirmación) Hibernate realiza una búsqueda y busca objetos actualizados/insertados/eliminados. Estos objetos se guardan primero en en la base de datos, y luego se bloquean y actualizan en la memoria caché para que las transacciones simultáneas no puedan ni actualizarlos ni leerlos.
- Si la transacción se retrotrae (explícitamente o debido a algún error ), los objetos bloqueados simplemente se liberan y desalojan del caché , para que otras transacciones puedan leerlos o actualizarlos.
- Si la transacción se realiza correctamente, los objetos bloqueados son que se han liberado y otros hilos pueden leerlos/escribirlos.
¿Hay alguna documentación sobre cómo funciona esto en un entorno de clúster?
Parece que la memoria caché transaccional funciona correctamente para esto, pero requiere entorno JTA con un administrador de transacciones independiente (como JBossTM, atomikos, Bitronix), el origen de datos XA y una gran cantidad de cambios de configuración y pruebas. Logré implementar esto, pero todavía tengo algunos problemas con mis frameworks. Por ejemplo, Google Guice IoC no admite transacciones JTA y tengo que reemplazarlo con Spring o mover el servicio a algún servidor de aplicaciones y usar EJB.
Entonces, ¿qué camino es mejor?
¡Gracias de antemano!
¿Quiere decir que la estrategia de caché de lectura/escritura es segura para clústeres pero la mayoría de las veces se usa transaccional? –
No. La lectura y escritura puede hacer que las cosas sean consistentes, pero debería tener algún tipo de método de 2PC u otro para garantizar la consistencia en un clúster. Depende de la implementación de 2LC. Infinispan elige omitir las transacciones de lectura y escritura, que se utilizan para abarcar todas las operaciones y actuar atómicamente alrededor del clúster. –