HTTP-Sitzungsmanager für verschiedene Anwendungsserver konfigurieren

WebSphere eXtreme Scale ist mit einer Sitzungsverwaltungsimplementierung gebündelt, die den Standardsitzungsmanager für einen Web-Container überschreibt. Diese Implementierung bietet Sitzungsreplikation, hohe Verfügbarkeit, eine bessere Skalierbarkeit und Konfigurationsoptionen. Sie können den Sitzungsreplikationsmanager von WebSphere eXtreme Scale und den generischen Start integrierter ObjectGrid-Container aktivieren.

Informationen zu diesem Vorgang

Sie können den HTTP-Sitzungsmanager mit anderen Anwendungsservern verwenden, in denen WebSphere Application Server nicht ausgeführt wird, z. B. WebSphere Application Server Community Edition. Zum Konfigurieren des Datengrids in anderen Anwendungsservern müssen Sie Ihre Anwendung verbinden und die JAR-Dateien von WebSphere eXtreme Scale in Ihre Anwendung integrieren.

Vorgehensweise

  1. Fügen Sie Ihre Anwendung so zusammen, dass sie den Sitzungsmanager verwenden kann. Wenn Sie den Sitzungsmanager verwenden möchten, müssen Sie die entsprechenden Filterdeklarationen den Webimplementierungsdeskriptoren für die Anwendung hinzufügen. Außerdem werden die Konfigurationsparameter des Sitzungsmanagers in Form von Initialisierungsparametern für den Servlet-Kontext in den Implementierungsdeskriptoren an den Sitzungsmanager übergeben. Es gibt drei Methoden, mit denen Sie diese Informationen in Ihre Anwendung einführen können:
    • Script addObjectGridFilter:

      Verwenden Sie ein Befehlszeilenscript, das mit eXtreme Scale bereitgestellt wird, um eine Anwendung mit Filterdeklarationen und Konfigurationen in Form von Initialisierungsparametern für den Servlet-Kontext zusammenzufügen. Das Script WXS-Ausgangsverzeichnis/session/bin/addObjectGridFilter.sh|bat akzeptiert zwei Parameter: den absoluten Pfad zur EAR-Datei oder WAR-Datei, die Sie verbinden möchten, und den absoluten Pfad zur Datei "splicer.properties", die verschiedene Konfigurationseigenschaften enthält. Das Syntaxformat dieses Scripts ist wie folgt:

      [Windows]
      addObjectGridFilter.bat <EAR-_oder_WAR-Datei> <Datei_splicer.properties>
      [Unix]
      addObjectGridFilter.sh <EAR-_oder_WAR-Datei> <Datei_splicer.properties>

      [Unix] Beispiel mit einer Installation von eXtreme Scale in einem eigenständigen Verzeichnis unter UNIX:

      1. cd WXS-Ausgangsverzeichnis/session/bin
      2. addObjectGridFilter.sh /tmp/mySessionTest.ear WXS-Ausgangsverzeichnis/session/samples/splicer.properties
      Der Servlet-Filter, der eingefügt wird, verwaltet die Standardwerte für Konfigurationswerte. Sie können diese Standardwerte mit Konfigurationsoptionen überschreiben, die Sie in der Eigenschaftendatei im zweiten Argument angeben. Eine Liste der Parameter, die Sie verwenden können, finden Sie im Abschnitt Initialisierungsparameter für den Servlet-Kontext.

      Sie können die Musterdatei splicer.properties ändern und verwenden, die mit der Installation von eXtreme Scale bereitgestellt wird. Sie können auch das Script "addObjectGridServlets" verwenden, das den Sitzungsmanager einfügt, indem Sie jedes Servlet erweitern. Das empfohlene Script ist jedoch das Script "addObjectGridFilter".

    • Ant-Build-Script:

      Im Lieferumfang von WebSphere eXtreme Scale ist eine Datei build.xml enthalten, das von Apache Ant verwendet werden kann, und im Ordner WAS-Stammverzeichnis/bin einer Installation von WebSphere Application Server enthalten ist. Sie können die Datei build.xml bearbeiten, um die Konfigurationseigenschaften des Sitzungsmanagers zu ändern. Die Konfigurationseigenschaften sind identisch mit den Eigenschaftsnamen in der Datei splicer.properties. Rufen Sie nach der Änderung der Datei build.xml den Ant-Prozess auf, indem Sie ant.sh, ws_ant.sh (UNIX) bzw. ant.bat, ws_ant.bat (Windows) aufrufen.

    • Webdeskriptor manuell aktualisieren:

      Editieren Sie die mit der Webanwendung gepackte Datei web.xml, um die Filterdeklaration, die Servlet-Zuordnung und die Initialisierungsparameter für den Servlet-Kontext zu integrieren. Verwenden Sie diese Methode nicht, weil sie fehleranfällig ist.

    Eine Liste der Parameter, die Sie verwenden können, finden Sie im Abschnitt Initialisierungsparameter für den Servlet-Kontext.
  2. Integrieren Sie die JAR-Dateien des Sitzungsreplikationsmanagers von WebSphere eXtreme Scale in Ihre Anwendung ein. Sie können die Dateien in das Verzeichnis WEB-INF/lib des Anwendungsmoduls oder in den Klassenpfad des Anwendungsservers integrieren. Die erforderlichen JAR-Dateien variieren je nach Typ der verwendeten Container:
    • Ferne Container-Server: ogclient.jar und sessionobjectgrid.jar
    • Integrierte Container-Server: objectgrid.jar und sessionobjectgrid.jar
  3. Optional: Wenn Sie ferne Container-Server verwenden, starten Sie die Container-Server. Einzelheiten finden Sie im Abschnitt Container-Server starten.
  4. Implementieren Sie die Anwendung. Führen Sie dazu die Schritte aus, die Sie gewöhnlich für einen Server oder Cluster verwenden. Nach der Implementierung der Anwendung können Sie die Anwendung starten.
  5. Greifen Sie auf die Anwendung zu. Sie können jetzt auf die Anwendung zugreifen, die mit dem Sitzungsmanager und mit WebSphere eXtreme Scale interagiert.

Nächste Schritte

Sie können die meisten Konfigurationsparameter des Sitzungsmanagers ändern, wenn Sie Ihre Anwendung für die Verwendung des Sitzungsmanagers instrumentieren. Zu diesen Attributen gehören Varianten des Replikationstyps (synchron oder asynchron), die Größe der speicherinternen Sitzungstabelle usw. Abgesehen von den Attributen, die während der Instrumentierung der Anwendung geändert werden können, sind die einzigen Attribute, die Sie nach der Anwendungsimplementierung ändern können, die Attribute, die sich auf die WebSphere eXtreme Scale-Serverclustertopologie beziehen, und die Art und Weise, in der Clients (Sitzungsmanager) eine Verbindung zu diesen Servern herstellen.
Verhalten bei einem fernen Szenario: Wenn das gesamte Datengrid, in dem die Anwendungssitzungsdaten gehostet werden, über den Web-Container-Client nicht verfügbar ist, verwendet der Client stattdessen den Basis-Web-Container des Anwendungsservers für die Sitzungsverwaltung. Das Datengrid kann in den folgenden Szenarien nicht erreichbar sein:
  • Es besteht ein Netzproblem zwischen dem Web-Container und den fernen Container-Servern.
  • Die fernen Container-Server-Prozesse wurden gestoppt.
Die Anzahl der im Speicher verwalteten Sitzungsreferenzen, die mit dem Parameter sessionTableSize angegeben wird, wird auch auch dann beibehalten, wenn die Sitzungen im Basis-Web-Container gespeichert werden. Die Sitzungen, die am längsten nicht mehr verwendet wurden, werden aus dem Sitzungscache des Web-Containers entfernt, wenn der Wert von sessionTableSize überschritten wird. Wenn das ferne Datengrid wieder verfügbar ist, können Sitzungen, die aus dem Web-Container-Cache entfernt wurden, Daten aus dem fernen Datengrid abrufen und die Daten in eine neue Sitzung laden. Wenn das gesamte ferne Datengrid nicht verfügbar ist und die Sitzung aus dem Sitzungscache entfernt wird, gehen die Sitzungsdaten des Benutzers verloren. Aufgrund dieses Problems sollten Sie nicht das gesamte Produktionsdatengrid beenden, wenn das System unter Last ausgeführt wird.