Hinweise zu Clusterumgebungen für den Zeitgeberservice
In einer Einzelserverumgebung ist eindeutig, welche Serverinstanz die Methode "timeout" der Bean in einer bestimmten Bean aufrufen muss. In einer Clusterumgebung mit mehreren Servern stehen weitere Optionen für die Steuerung des Verhaltens zur Verfügung.
WebSphere Application Server implementiert den EJB-Zeitgeberservice (Enterprise JavaBeans). Basierend auf Ihren Geschäftsanforderungen, können Sie persistente oder nicht persistente Zeitgeber verwenden. Persistente Zeitgeber sind hilfreich, wenn Sie einen Zeitgeber für ein zeitbasiertes Ereignis erstellen, der die Zusicherung der Zeitgeberexistenz über den Lebenszyklus des Servers hinweg erfordert, um das Beenden und den Neustart des Servers zu "überstehen". Bereits gestartete persistente Zeitgeber werden automatisch gestartet, wenn Ihr Server gestartet wird, und erfordern eine Datenbankinstanz.Nicht persistente Zeitgeber verwenden keinen Datenspeicher und werden abgebrochen, wenn der Anwendungsserver gestoppt wird oder den aktiven Status verlässt. Nicht persistente Zeitgeber sind nur in dem Server vorhanden, in dem sie erstellt werden. Wenn Ihre EJB-Anwendung in einer Clusterumgebung einen nicht persistenten Zeitgeber erstellt und diese Anwendung in mehreren Servern gespiegelt ist, hat jeder Server einen eigenen nicht persistenten Zeitgeber, der in dieser Serverumgebung ausgeführt wird. Ein über das Programm erstellter nicht persistenter Zeitgeber wird nur in dem Cluster-Member ausgeführt, in dem er erstellt wurde.
Wenn Sie einen persistenten Zeitgeber in einer Clusterumgebung mit mehreren Servern konfigurieren, berücksichtigen Sie die folgenden Optionen für den Aufruf der Methode "timeout" für eine bestimmte Bean in der Serverinstanz:
- Separate Zeitgeberservicedatenbank für jeden Serverprozess bzw. jedes Cluster-Member. Dies ist die Standardkonfiguration. Es kann jeweils nur die Serverinstanz bzw. das Cluster-Member, die bzw. das den Zeitgeber erstellt hat, auf den Zeitgeber zugreifen und die Methode "timeout" der Bean ausführen. Falls die Serverinstanz nicht verfügbar ist, wird der Zeitgeber nicht zur angegebenen Zeit ausgeführt. Er wird erst dann ausgeführt, wenn der Server erneut gestartet wird. Wenn eine Enterprise-Bean die Methode getTimers() aufruft, werden nur die Zeitgeber, die in der Serverinstanz erstellt wurden, gefunden. Dies kann zu einem nicht erwarteten Verhalten führen, wenn die Enterprise-Bean versucht, alle ihr zugeordneten Zeitgeber abzubrechen, z. B. wenn die Enterprise-Bean entfernt wird. Diese Konfiguration wird für Produktionssysteme NICHT empfohlen.
- Gemeinsam genutzte oder allgemeine Zeitgeberservicedatenbank für den Cluster. Zeitgeber können in jedem Serverprozess oder Cluster-Member erstellt und aufgerufen werden. Zeitgeber, die in einem Serverprozess erstellt wurden, werden von der Methode getTimers() auch in anderen Serverprozessen im Cluster gefunden. Wenn eine Entity-Bean entfernt wird, werden alle Zeitgeber, unabhängig davon, wo sie erstellt wurden, abgebrochen. Alle Zeitgeber werden jedoch in einem Server des Cluster ausgeführt, d. h. die Methode "timeout" der Bean wird für alle Zeitgeber in demselben Server ausgeführt. Welcher Server die Zeitgeber ausführt, richtet sich danach, welcher Serverprozess eine Sperre für die Tabellen der gemeinsamen Datenbank erhält. Wenn der Server, der die Zeitgeber ausführt, ausfällt, übernimmt ein anderer Server oder ein anderes Cluster-Member die Zeitgeber und führt sie zur geplanten Zeit aus. Diese Konfiguration wird für alle Produktionssysteme empfohlen.
- Zur Vermeidung solcher Probleme verwenden Sie die Zugriffsart "wsPessimisticUpdate". Diese Zugriffsart bewirkt, dass die Suchmethode in der Anwendung eine Anweisung select for update anstelle eines generischen Servlet ausführt. Dies wiederum verhindert, dass gegenseitiges Sperren aufgrund von Sperreneskalationen auftreten, wenn mehrere Threads versuchen, ihre Sperren zu eskalieren, um eine Aktualisierung durchzuführen.
Fehler vermeiden: Wenn Sie den EJB-Zeitgeberservice in einer Anwendung verwenden, die mit einer Multithread-Datenbankzugriffen arbeitet, können im Anwendungsverlauf Probleme aufgrund gegenseitiger Sperren auftreten. gotcha


