Auf Peers replizierter lokaler Cache

Sie müssen sicherstellen, dass der Cache synchronisiert wird, wenn mehrere Prozesse mit unabhängigen Cacheinstanzen vorhanden sind. Um sicherzustellen, dass die Cacheinstanzen synchronisiert werden, richten Sie einen auf Peers replizierten Cache mithilfe von Java Message Service (JMS) ein.

WebSphere eXtreme Scale enthält zwei Plug-ins, die Transaktionsänderungen automatisch zwischen Peer-ObjectGrid-Instanzen weitergeben. Das Plug-in "JMSObjectGridEventListener" gibt eXtreme-Scale-Änderungen automatisch über JMS weiter.
Abbildung 1. Auf Peers replizierter Cache mit Änderungen, die über JMS weitergegeben werden
JMS gibt Änderungen zwischen zwei ObjectGrid-Instanzen weiter, die in unterschiedlichen JVMs ausgeführt werden. Jede ObjectGrid-Instanz ist einer Anwendung zugeordnet.
Wenn Sie in einer Umgebung mit WebSphere Application Server arbeiten, ist auch das TranPropListener-Plug-in verfügbar. Das TranPropListener-Plug-in verwendet den High Availability Manager (kurz HA-Manager), um die Änderungen an jede Peer-Cacheinstanz weiterzugeben.
Abbildung 2. Auf Peers replizierter Cache mit Änderungen, die über den High Availability Manager weitergegeben werden
Der HA-Manager gibt Änderungen zwischen zwei ObjectGrid-Instanzen weiter, die in unterschiedlichen JVMs ausgeführt werden. Jede ObjectGrid-Instanz ist einer Anwendung zugeordnet.

Vorteile

  • Die Gültigkeit der Daten ist höher, weil sie häufiger aktualisiert werden.
  • Mit dem TranPropListener-Plug-in kann eXtreme Scale wie die lokale Umgebung über das Programm oder deklarativ über die XML-Implementierungsdeskriptordatei von eXtreme Scale oder mit anderen Frameworks wie Spring erstellt werden. Die Integration mit dem High Availability Manager erfolgt automatisch.
  • Jede BackingMap kann gesondert für eine optimale Speicherauslastung und gemeinsamen Zugriff optimiert werden.
  • BackingMap-Aktualisierungen können zu einer einzigen Arbeitseinheit gruppiert und als letzter Teilnehmer in zweiphasige Transaktionen wie JTA-Transaktionen (Java Transaction Architecture) integriert werden.
  • Ideal für Topologien mit wenigen JVMs und einer angemessen kleinen Dateigruppe oder für das Caching von Daten, auf die häufig zugegriffen wird.
  • Änderungen an eXtreme Scale werden in allen Peer-Instanzen von eXtreme Scale repliziert. Die Änderungen sind so lange konsistent, wie eine permanente Subskription verwendet wird.

Nachteile

  • Die Konfiguration und Verwaltung für JMSObjectGridEventListener kann komplex sein. eXtreme Scale kann über das Programm oder deklarativ über die XML-Implementierungsdeskriptordatei von eXtreme Scale oder mit anderen Frameworks wie Spring erstellt werden.
  • Nicht skalierbar: Die für die Datenbank erforderliche Speicherkapazität kann die JVM möglicherweise nicht bereitstellen.
  • Funktioniert nicht ordnungsgemäß, wenn Java Virtual Machines hinzugefügt werden:
    • Die Daten sind nicht so einfach partitionierbar.
    • Das Ungültigmachen von Einträgen ist kostenintensiv.
    • Jeder Cache muss einzeln vorbereitet werden.

Einsatz

Verwenden Sie die Implementierungstopologie nur, wenn das zwischenzuspeichernde Datenvolumen klein ist, in eine einzige JVM passt und relativ stabil ist.