Bestimmte Aufgaben sollten im Hintergrund nur einmal ausgeführt werden.
Das Problem sollte sich relativ einfach lösen lassen. Der Service, welcher die Aufgabe übernimmt, setzt eine Sperre. Wenn er diese bekommt, dann führt er die Aufgabe aus, andernfalls nicht. Die Sperre könnte in einer gemeinsamen Datenbank gesetzt werden oder mit Hilfe einer Datei in einem gemeinsamen Dateisystem. Wichtig ist dabei, dass die Sperre entfernt wird, wenn der sperrende Service nicht mehr lebt, damit ein anderer Rechner im Cluster die Aufgabe übernehmen kann.
Außerdem ist es für das Caching der Datenbank auch interessant, wenn die Entitäten mitbekommen, dass Sie auf dem anderen Server verändert wurden.
In einer Read-Only-Umgebung/Tabelle kann jede Instanz den eigenen Cache weiterverwenden. Man muss nur dafür sorgen, dass Objekte im Cache regelmäßig verfallen, um keine veralteten Daten auszuliefern.
Für Objekte, welche durch Nutzer verändert werden, bietet es sich an, die Cluster mit Sitzungsaffinität einzurichten. Damit wird sichergestellt, dass der Benutzer für die Dauer seiner Sitzung mit demselben Rechner im Cluster interagiert. Dies kann auch die Cache-Nutzung verbessern, da derselbe Benutzer normalerweise auf dieselben Daten zugreift.
Bei Objekten, die hauptsächlich zum Schreiben verwendet werden, kann die beste Lösung darin bestehen, den Cache für diese Objekte zu deaktivieren. Die Zwischenspeicherung bietet keine Vorteile für Einfügungen, und die Kosten für die Vermeidung veralteter Daten bei Aktualisierungen können bedeuten, dass die Zwischenspeicherung von Objekten, die immer aktualisiert werden, keinen Nutzen bringt. Ein großer Cache wirkt sich auch auf die Garbage Collection aus. Wenn der Cache also keinen Nutzen bringt, sollte er deaktiviert werden, um diesen Overhead zu vermeiden.
Abhängig von der Komplexität der Objekte, wenn das Objekt viele komplexe Beziehungen aufweist und nur ein Teil des Objekts aktualisiert wird, kann sich die Zwischenspeicherung dennoch lohnen. Eine Möglichkeit ist die Verwendung eines Messaging-Frameworks zur Koordinierung der Caches zwischen den Rechnern im Cluster. JMS oder JGroups können in Kombination mit JPA oder Anwendungsereignissen verwendet werden, um Nachrichten zu versenden, welche die Caches auf anderen Rechnern ungültig machen, wenn eine Aktualisierung stattfindet. Einige JPA- und Cache-Anbieter unterstützen die Cache-Koordination in einer Cluster-Umgebung, zB.: TopLink / EclipseLink : Unterstützen die Cache-Koordination in einer Cluster-Umgebung mit JMS oder RMI.
Eine weiter Möglichkeit wäre verteilter Cache, der auf beiden Rechnern im Cluster verteilt ist. Jedes Objekt wird nur auf einem oder beiden Rechnern gespeichert. So werden veraltete Daten vermieden, denn wenn auf den Cache zugegriffen oder er aktualisiert wird, wird das Objekt immer vom selben Ort abgerufen und ist somit immer auf dem neuesten Stand. Der Nachteil ist, dass der Zugriff auf den Cache möglicherweise einen Netzwerkzugriff erfordert. Diese Lösung funktioniert am besten, wenn die Rechner im Cluster über dasselbe Hochgeschwindigkeitsnetz miteinander verbunden sind und wenn der Datenbankrechner nicht so gut angebunden ist oder unter Last steht.
