Failover für Stateful-Session-Beans im EJB-Container

Sie können WebSphere Application Server verwenden, um Anwendungen zu erstellen, die Stateful-Session-Beans verwenden, die nicht durch unerwartete Serverfehler eingeschränkt werden. Das Produkt nutzt die Funktionen des Datenreplikationsservice (DRS) und des Workload-Management (WLM), sodass Sie das Failover für Stateful-Session-Beans aktivieren können.

Vielleicht möchten Sie nicht für jede im EJB-Container (Enterprise JavaBeans) installierte Stateful-Session-Bean das Failover aktivieren. In diesem Fall können Sie die Einstellungen für den EJB-Container auf Anwendungsebene oder auf der Ebene des EJB-Moduls überschreiben. Auf beiden genannten Ebenen können Sie das Failover aktivieren oder inaktivieren. Schauen Sie sich hierzu die folgenden Situationsbeispiele an:
  • Sie möchten das Failover für alle Anwendungen bis auf eine aktivieren. Aktivieren Sie in diesem Fall das Failover auf der Ebene des EJB-Containers und überschreiben Sie die Einstellung auf Anwendungsebene, um das Failover für die eine Anwendung außer Kraft zu setzen.
  • Sie möchten das Failover für eine installierte Anwendung aktivieren. Inaktivieren Sie hierfür das Failover auf der Ebene des EJB-Containers. Überschreiben Sie dann die Einstellung auf Anwendungsebene, um das Failover für die eine Anwendung zu aktivieren.
  • Sie möchten das Failover für alle Anwendungen mit Ausnahme eines Moduls einer Anwendung aktivieren. Aktivieren Sie in diesem Fall das Failover auf der Ebene des EJB-Containers. Überschreiben Sie dann die Einstellung auf Anwendungsmodulebene, um das Failover für das eine Modul zu inaktivieren.
  • Sie möchten das Failover für ein installiertes EJB-Modul aktivieren. Inaktivieren Sie hierfür das Failover auf der Ebene des EJB-Containers. Überschreiben Sie dann die Einstellung auf EJB-Modulebene, um das Failover für das eine EJB-Modul zu aktivieren.
Informationen zum Aktivieren des Failover für Stateful-Session-Beans in der Administrationskonsole finden Sie in den folgenden Artikeln:
  • Failover für Stateful-Session-Beans in der Anzeige für EJB-Container aktivieren oder inaktivieren
  • Failover für Stateful-Session-Beans in der Anzeige für Unternehmensanwendungen aktivieren oder inaktivieren
  • Failover für Stateful-Session-Beans in der Anzeige für EJB-Module aktivieren oder inaktivieren

Aktivierungsrichtlinie für Stateful-Session-Beans bei aktiviertem Failover

Während der Anwendungsassemblierung können Sie eine Aktivierungsrichtlinie für Stateful-Session-Beans angeben. Beachten Sie unbedingt, dass der EJB-Container das Failover nur zu dem Zeitpunkt vorbereitet, zu dem die Stateful-Session-Bean inaktiviert wird. Zur Vorbereitung des Failover repliziert der EJB-Container die Daten der Stateful-Session-Bean mit dem DRS. Wenn Sie die Bean mit einer Aktivierungsrichtlinie des Typs Einmal aktivieren (Standardrichtlinie) konfigurieren, wird die Bean nicht schnell genug inaktiviert, um für das Failover von Stateful-Session-Beans hilfreich zu sein. Wenn Sie das Failover aktivieren, ignoriert der EJB-Container deshalb die konfigurierte Aktivierungsrichtlinie für die Bean und verwendet automatisch die Aktivierungsrichtlinie An Transaktionsgrenze aktivieren. Diese Aktion stellt sicher, dass die Bean inaktiviert wird und die Beandaten repliziert werden, wenn diese bei einer ausgeführten Transaktion registriert wird.

Fehler vermeiden Fehler vermeiden: Wenn der DRS Daten zur Replikation erhält, repliziert er die Daten auf N-1 Anwendungsservern, wobei N die Anzahl der verfügbaren Replikate bezeichnet. Wenn der erstellende Server und alle Server, auf denen die Sicherungskopien gespeichert sind, ausfallen oder gestoppt werden, gehen die replizierten Daten verloren, es sei denn, der DRS-Konsument repliziert die Daten erneut. gotcha

Stateful-Session-Beans mit containergesteuerten oder Bean-gesteuerten Arbeitseinheiten bei aktiviertem Failover

Die relevanten Arbeitseinheiten sind in diesem Fall Transaktionen und Activity Sessions. Das Produkt unterstützt das Stateful-Session-Bean-Failover für containergesteuerte Transaktionen (CMT, Container-managed Transaction), Bean-gesteuerte Transaktionen (BMT, Bean-managed Transaction), containergesteuerte Activity Sessions und Bean-gesteuerte Activity Sessions. Bei den containergesteuerten Transaktionen und Sitzungen erfolgt die Vorbereitung des Failover jedoch nur, wenn der Versuch, eine Anforderung nach dem Aufruf einer Enterprise-Bean-Methode an einen Server zu senden, durch einen Ausfall der Serververbindung scheitert. Fällt der Server aus, nachdem er eine an ihn gesendete Anforderung bestätigt hat, findet kein Failover statt. Kommt es mitten in einer Anforderung oder Arbeitseinheit zu einem Ausfall, kann WLM nicht sicher auf einen anderen Server wechseln, ohne dass Kompensationscode von der Anwendung ausgeführt wird. In einem solchen Fall empfängt die Anwendung eine CORBA-Ausnahme und Nebencode mit der Information, dass ein transparentes Failover nicht möglich ist, weil es während der Ausführung einer Arbeitseinheit zum Ausfall gekommen ist. Sie müssen die Anwendung so schreiben, dass sie die CORBA-Ausnahme und den Nebencode erkennt und den Ausfall kompensieren kann. Nach Ausführung des Kompensationscodes kann die Anwendung die Anforderungen wiederholen. Falls ein Pfad zu einem Ausweichserver vorhanden ist, leitet WLM die neue Anforderung an einen neuen Primärserver für die Stateful-Session-Bean weiter.

[AIX Solaris HP-UX Linux Windows][IBM i]Weitere Informationen finden Sie im Artikel zu den Corba-Nebencodes.

Weitere Informationen finden Sie im Artikel zum Workload-Management für alle Plattformen mit Ausnahme von z/OS.

Das gleiche gilt für Bean-gesteuerte Arbeitseinheiten wie Transaktionen oder Activity Sessions. Bei Bean-gesteuerten Arbeitseinheiten kommt jedoch ein anderer Faktor hinzu, der berücksichtigt werden muss.

Bei Bean-gesteuerten Arbeitseinheiten kann der Failoverprozess nicht immer erkennen, dass eine von einer Stateful-Session-Bean gestartete Transaktion oder Activity Session nicht abgeschlossen wurde. So ist ein Failover durch einen neuen Server möglich, obwohl sich der Ausfall mitten in einer Transaktion oder Sitzung ereignet hat. Da die Arbeitseinheit implizit zurückgesetzt wird, verhält sich WLM so, als ob ein transparentes Failover durch einen anderen Server möglich wäre, obwohl unter Umständen Kompensationscode erforderlich ist. Der EJB-Container erkennt dieses Verhalten auf dem neuen Server und löst eine Ausnahme aus. Diese Ausnahme wird in folgendem Szenario ausgelöst:
  1. Eine Methode einer Stateful-Session-Bean, die Bean-gesteuerte Transaktionen oder ActivitySessions verwendet, ruft die Methode "begin" in einer UserTransaction auf, die sie vom SessionContext-Objekt abruft. Die Methode führt einige Schritte in der gestarteten Arbeitseinheit aus, beendet die die Transaktion oder Sitzung jedoch nicht vor der Rückkehr zum Aufrufenden der Methode.
  2. Nach dem Aufruf der Methode setzt der EJB-Container die von der Methode gestartete Arbeit aus. Diese Aktion wird von der EJB-Spezifikation (Enterprise JavaBeans) für Bean-gesteuerte Arbeitseinheiten gefordert, wenn die Bean eine Stateful-Session-Bean ist.
  3. Der Client startet mehrere andere Methoden für die Stateful-Session-Bean. Bei jedem Aufruf nimmt der EJB-Container die ausgesetzte Transaktion oder Activity Session wieder auf, teilt den Methodenaufruf zu und setzt die Arbeit erneut aus, bevor er zum Aufrufenden zurückkehrt.
  4. Der Client ruft für die Stateful-Session-Bean eine Methode auf, die die in Schritt 1 gestartete Transaktion oder Sitzung beendet.

Dieses Szenario beschreibt eine Arbeitseinheit, die von einer Sticky-Bean gesteuert wird. Die Transaktion oder Activity Session bleibt für mehr als eine Methode der Stateful-Session-Bean erhalten. Wenn eine Anwendung eine Transaktion oder Activity Session verwendet, die von einer Sticky-Bean gesteuert wird, und der Server nach Abschluss einer Sticky-Arbeitseinheit und vor Beginn einer neuen Sticky-Arbeitseinheit ausfällt, gelingt das Failover. Fällt der Server jedoch aus, vor dem Abschluss einer Sticky-Transaktion oder Sticky-Activity-Session aus, ist kein Failover möglich. Leitet der Failoverprozess die Stateful-Session-Bean-Anforderung stattdessen an einen neuen Server weiter, erkennt der EJB-Container, dass der Ausfall während einer aktiven Sticky-Transaktion oder Sticky-Activity-Session eingetreten ist. In diesem Fall leitet der EJB-Container eine Ausnahme ein.

Dieser Prozess zeigt an, dass das Failover bei containergesteuerten und Bean-gesteuerten Arbeitseinheiten scheitert, wenn die Transaktion oder Activity Session noch aktiv ist. Der einzige Unterschied ist der, dass eine Ausnahme für Bean-gesteuerte Arbeitseinheiten ausgegeben wird.

Hinweise zum Anwendungsentwurf

Beim Entwerfen von Anwendungen, die den Failoverprozess für Stateful-Session-Beans nutzen, sollten Sie Folgendes berücksichtigen:
  • Um die im vorherigen Abschnitt beschrieben Ausnahme zu vermeiden, sollten Sie Ihre Anwendung so schreiben, dass containergesteuerte Transaktionen (Container Managed Transactions, CMT) und nicht Bean-gesteuerte Transaktionen (Bean Managed Transactions, BMT) verwenden.
  • Falls Sie Failover wünschen und Ihre Anwendung eine HTTP-Sitzung oder eine Stateful-Session-Bean erstellt, die eine Referenz auf eine andere Stateful-Session-Bean speichert, muss der Administrator sicherstellen, dass die HTTP-Sitzung und die Stateful-Session-Bean für die Verwendung derselben DRS-Replikationsdomäne konfiguriert sind.
  • Verwenden Sie nicht eine lokale und ferne Referenz auf eine Stateful-Session-Bean.

    Eine Instanz einer Stateful-Session-Bean mit einem gegebenen Primärschlüssel kann normalerweise zu einem gegebenen Zeitpunkt nur auf einem Server vorhanden sein. Das Failover kann dazu führen, dass die Bean von einem Server auf einen anderen verschoben wird. In einem solchen Fall existiert die Bean jedoch nicht auf mehreren Servern gleichzeitig. Es gibt allerdings einige recht unwahrscheinliche Szenarien, die zur Folge haben können, dass eine Bean-Instanz (mit einem Primärschlüssel) gleichzeitig auf mehreren Servern vorhanden ist. Sollte dies geschehen, hat keine der Bean-Kopien Kenntnis von der Existenz der jeweils anderen, sodass es nicht zu einer Synchronisation der beiden Instanzen kommt, um die Übereinstimmung der Daten zu gewährleisten. Die Ergebnisse Ihrer Anwendung sind somit nicht vorhersehbar.

    Achtung: Sie können eine solche Situation vermeiden, indem Sie bedenken, dass Ihre Anwendung bei aktiviertem Failover in keinem Fall eine lokale Referenz (EJBLocalObject) und eine ferne Referenz (EJBObject) auf dieselbe Stateful-Session-Bean-Instanz enthalten darf.
  • Vermeiden Sie die Verwendung ferner asynchroner Methoden in Stateful-Session-Beans.

    Wenn eine asynchrone Methode aufgerufen wird, reiht der ferne Server die asynchrone Methodenanforderung in die Warteschlange ein und gibt ein Future-Objekt an den Client zurück. Da die Methodenanforderung nur in dem Server mit der Instanz der Stateful-Session-Bean in die Warteschlange eingereiht wird, ist das Future-Objekt an diesen Server gebunden, und es findet kein Failover statt. Wenn Sie ferne asynchrone Methoden für Stateful-Session-Beans verwenden müssen, schreiben Sie die Anwendung so, dass sie fehlgeschlagene Aufrufe des Future-Objekts erkennt und einen synchronen Aufruf an die Stateful-Session-Bean absetzt, um festzustellen, ob die Transaktion, die von der asynchronen Methode gestartet wurde, erfolgreich abgeschlossen wurde.

  • Vermeiden Sie die Referenzierung nicht persistenter EJB-Zeitgeber in der Stateful-Session-Bean-Instanz, wenn das Failover aktiviert ist.

    Wenn eine Stateful-Session-Bean ein Handle zu einer automatisch oder über das Programm erstellten nicht persistenten Zeitgeberinstanz enthält, ist das Handle nach dem Failover der Stateful-Session-Bean ungültig, und es wird eine Ausnahme des Typs "javax.ejb.NoSuchObjectLocalException" ausgegeben, wenn dieses Handle verwendet wird. Wenn die Anwendung nicht persistente Zeitgeber in Stateful-Session-Beans referenzieren muss, schreiben Sie die Anwendung so, dass das ungültige Handle berücksichtigt wird.

    Achtung: Handles zu automatisch oder über das Programm erstellten persistenten Zeitgebern in Stateful-Session-Beans werden übernommen und können nach dem Failover einer Stateful-Session-Bean verwendet werden.
[z/OS]

Nur für Benutzer von z/OS

Das Failover von Stateful-Session-Beans in WebSphere Application Server Network Deployment for z/OS weicht geringfügig von dem im Produkt WebSphere Application Server Network Deployment ab. Zusätzlich zu der hier beschriebenen Failoverlösung können z/OS-Benutzer das Failover für Servants in einem nicht verwalteten Server aktivieren. Weitere Informationen finden Sie in den folgenden Artikeln:
  • Mehrere Servants
  • Peerneustart und Peerwiederherstellung konfigurieren
  • Cluster für die Implementierung von Stateful-Session-Beans

Da das z/OS-Produkt eine Steuerregion oder Servantregionen hat und das Produkt WebSphere Application Server Network Deployment nicht, gibt es es ein spezielles Failoverszenario für z/OS. Dies ist das Failover von einer Servantregion in eine andere (Verlust eines Servants ohne Verlust des Controllers).

Wenn Sie die HFS-basierte Technik unter z/OS verwenden, fahren Sie mit dieser Technik fort.

In einem nicht verwalteten z/OS-Server kann das Failover für Stateful-Session-Beans aktiviert werden. Das Failover findet nur zwischen den Servants eines bestimmten nicht verwalteten Servers statt. Wenn ein nicht verwalteter z/OS-Server nur einen Servant hat, hat das Aktivieren des Failover keine Wirkung. Ein nicht verwalteter z/OS-Server, in dem das Failover aktiviert ist, wird nicht von einem anderen nicht verwalteten z/OS-Server übernommen. Informationen zum Aktivieren des Failover in einem nicht verwalteten Server finden Sie im Artikel "Failover von Servants aktivieren".


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_sfsbf
Dateiname:cejb_sfsbf.html