Memoria caché local replicada de igual

Debe asegurarse de que la memoria caché esté sincronizada si existen varios procesos con instancias de memoria caché independientes. Para asegurarse de que las instancias de memoria caché están sincronizadas, habilite una memoria caché replicada por un igual con JMS (Java Message Service).

WebSphere eXtreme Scale incluye dos plug-ins que propagan automáticamente los cambios de las transacciones entre instancias de ObjectGrid de un igual. El plug-in JMSObjectGridEventListener propaga automáticamente los cambios de eXtreme Scale mediante JMS.
Figura 1. La memoria caché duplicada por un igual con los cambios que se propagan con JMS
JMS propaga los cambios entre dos instancias de ObjectGrid que se ejecutan en distintas máquinas virtuales Java. Cada instancia de ObjectGrid se asocia a una aplicación.
Si ejecuta un entorno WebSphere Application Server, el plug-in TranPropListener también está disponible. El plug-in TranPropListener utiliza el gestor de alta disponibilidad (HA) para propagar los cambios a cada instancia de memoria caché de igual.
Figura 2. La memoria caché duplicada por un igual con los cambios propagados con el High Availability Manager.
El gestor HA propaga los cambios entre dos instancias de ObjectGrid que se ejecutan en distintas máquinas virtuales Java. Cada instancia de ObjectGrid se asocia a una aplicación.

Ventajas

  • Los datos son más válidos porque se actualizan con más frecuencia.
  • Con el plug-in TranPropListener, igual que el entorno local, eXtreme Scale se puede crear a través de programa o de forma declarativa con el archivo XML de descriptor de despliegue de eXtreme Scale o con otras infraestructuras como, por ejemplo, Spring. La integración con el High Availability Manager se realiza de forma automática.
  • Cada BackingMap se puede ajustar independientemente para obtener un uso y una simultaneidad óptimos de la memoria.
  • Las actualizaciones de BackingMap se pueden agrupar en una única unidad de trabajo y se pueden integrar como último participante en transacciones de 2 fases como, por ejemplo, transacciones JTA (Java Transaction Architecture).
  • Ideal para topologías de pocas JVM con un conjunto de datos razonablemente pequeño o para almacenar en memoria caché datos de acceso frecuente.
  • Los cambios en eXtreme Scale se duplican en todas las instancias de eXtreme Scale de igual. Los cambios son coherentes mientras se utilice una suscripción duradera.

Desventajas

  • La configuración y el mantenimiento de JMSObjectGridEventListener pueden ser complejos. eXtreme Scale puede crearse mediante programación o de forma declarativa con el archivo XML de descriptor de despliegue de eXtreme Scale o con otras infraestructuras como Spring.
  • No es escalable: el volumen de memoria que requiere la base de datos puede desbordar la JVM.
  • Funciona de forma incorrecta cuando se añade Máquinas virtuales Java:
    • Los datos no se pueden particionar fácilmente.
    • La operación de invalidación es muy costosa.
    • Cada memoria caché debe calentarse de manera independiente.

Cuándo se debe utilizar

Utilice topología de despliegue solo cuando la cantidad de datos que se deben almacenar en memoria caché sea pequeña, pueda caber en una única JVM y sea relativamente estable.