Empfohlene Methoden für die Verwendung von HTTP-Sitzungen
Dieser Artikel beschreibt empfohlene Methoden für die Implementierung von HTTP-Sitzungen.

- Sicherheitsintegration zum Schutz von HTTP-Sitzungen aktivieren
HTTP-Sitzungen haben Sitzungs-IDs. Eine Sitzungs-ID ist eine Pseudozufallsnummer, die zur Laufzeit generiert wird. Das "Sichaneignen" (oder Entführen) von Sitzungen ist eine bekannte Hackerattacke und kann verhindert werden, wenn alle im Netz übertragenen Anforderungen über ein sichere Verbindung (d. h. HTTPS) gesendet werden. Aber nicht jede Konfiguration in einer Kundenumgebung berücksichtigt diese Vorgabe aufgrund der Leistungseinbußen, die SSL-Verbindungen mit sich bringen. In diesem gelockerten Modus ist die HTTP-Sitzung anfällig für Attacken. Deswegen bietet WebSphere Application Server eine Option für eine feste Integration von HTTP-Sitzungen und der Sicherheit von WebSphere Application Server. Aktivieren Sie die Sicherheit in WebSphere Application Server so, dass die Sitzungen auf eine Weise geschützt sind, dass nur Benutzer, die die Sitzungen erstellt haben, auf sie zugreifen können.
- Geben Sie HttpSession-Objekte nach dem Abschluss mit javax.servlet.http.HttpSession.invalidate()
frei.HttpSession-Objekte bleiben im Web-Container, bis eine der folgenden Bedingungen zutrifft:
- Die Anwendung gibt das entsprechende Objekt mit der Methode javax.servlet.http.HttpSession.invalidate explizit und über das Programm frei. Häufig ist die Invalidierung über das Programm Teil der Abmeldefunktion der Anwendung.
- Der WebSphere Application Server löscht die zugeordnete HTTP-Sitzung, wenn sie abläuft (Standardeinstellung = 1800 Sekunden oder 30 Minuten). Der WebSphere Application Server kann basierend auf den Einstellungen zur Sitzungsverwaltung nur eine bestimmte Anzahl von HTTP-Sitzungen im Speicher verwalten. Bei verteilten Sitzungen, wenn die maximale Cachegröße im Speicher erreicht ist, entfernt das Dienstprogramm für Sitzungsverwaltung die LRU-Sitzung (Least Recently Used) aus dem Cache, um Platz für eine Sitzung freizumachen.
- Vermeiden Sie den Versuch, das HttpSession-Objekt außerhalb der
einzelnen Servlet- oder JSP-Datei zu speichern und wieder zu verwenden.
Das HttpSession-Objekt ist eine Funktion von HttpRequest (der Abruf ist nur über die Methode req.getSession möglich), und eine Kopie der Anforderung ist nur für die Lebensdauer der Methode service des Servlet oder der JSP-Datei gültig. Sie haben nicht die Möglichkeit, das HttpSession-Objekt zwischenzuspeichern und außerhalb des Bereichs eines Servlet oder einer JSP-Datei auf das Objekt zu verweisen.
- Implementieren Sie die Schnittstelle "java.io.Serializable" bei der Entwicklung neuer, in der
HTTP-Sitzung zu speichernder Objekte.
Die Serialisierbarkeit einer Klasse wird von der Klasse durch Implementierung der Schnittstelle "java.io.Serializable" aktiviert. Die Implementierung der Schnittstelle "java.io.Serializable" ermöglicht eine ordnungsgemäße Serialisierung des Objekts, wenn verteilte Sitzungen verwendet werden. Die Zustände der Klassen, die diese Schnittstelle nicht implementieren, werden weder serialisiert noch entserialisiert. Wenn eine Klasse die Schnittstelle "Serializable" nicht implementiert, kann die JVM ihren Zustand nicht persistent in der Datenbank oder in einer anderen JVM speichern. Alle Subtypen einer serialisierbaren Klasse sind serialisierbar. Beispiel:
public class MyObject implements java.io.Serializable {...}
Vergewissern Sie sich, dass alle Instanzvariablenobjekte, die nicht als temporär markiert wurden, serialisierbar sind. Ein nicht serialisierbares Objekt kann nicht zwischengespeichert werden.
In Konformität mit der Spezifikation für Java™-Servlets muss der Container für verteilte Servlets eine Ausnahme des Typs IllegalArgumentException für Objekte erzeugen, wenn der Container den Mechanismus nicht unterstützt, der für die Migration der Sitzung, in der die Objekte gespeichert werden, erforderlich ist. Es wird nur dann eine Ausnahme erzeugt, wenn Sie die Option für Verteilung (distributable) ausgewählt haben.
- Verwenden Sie in der Datenbank oder in WebSphere eXtreme Scale die Option <codeph>write frequency=END_OF_SERVICE</codeph> wenn Sie Sitzungsfailover aktivieren, um zu verhindern, dass während eines Failover Daten verloren gehen. Datenverlust wird dann durch das Speichern von Sitzungsdaten in der Datenbank oder im Datengrid am Ende jeder Anforderung vermieden. Dieses Verhalten führt zu längeren Anforderungszeiten, was wiederum die Leistung vermindert.
- Vergewissern Sie sich, dass die Java-Objekte,
die Sie zu einer Sitzung hinzufügen, im richtigen Klassenpfad angegeben sind.
Wenn Sie Java-Objekte einer Sitzung hinzufügen, geben Sie die Klassendateien für diese Objekte im richtigen Klassenpfad an (Klassenpfad der Anwendung bei gemeinsamer Verwendung der Objekte durch Webmodule in einer Unternehmensanwendung oder Klassenpfad des Webmoduls bei gemeinsamer Verwendung der mit Servlet 2.2 kompatiblen Sitzungen). Sie haben auch die Möglichkeit, die Java-Objekte in dem Verzeichnis, das andere in WebSphere Application Server verwendete Servlets enthält, abzulegen. Beim Sitzungs-Clustering wird diese Aktion auf jeden Knoten im Cluster angewendet.
Da das HttpSession-Objekt von den Servlets, auf die der Benutzer möglicherweise zugreift, gemeinsam verwendet wird, sollten Sie vielleicht für die gesamte Site eine Namenskonvention verwenden, um Konflikte zu vermeiden.
- Vermeiden Sie die Speicherung großer Objektdiagramme im HttpSession-Objekt.
In den meisten Anwendungen erfordert jedes Servlet nur einen Abschnitt der gesamten Sitzungsdaten. Wenn Sie die Daten jedoch als ein großes Objekt im HttpSession-Objekt speichern, zwingt eine Anwendung den WebSphere Application Server, bei jedem Zugriff alle Daten zu verarbeiten.
- Verwenden Sie die Sitzungsaffinität, um
mehr Cachezugriffe in WebSphere
Application Server zu erzielen.
Der WebSphere Application Server stellt Funktionen im HTTP-Server-Plug-in zur Unterstützung der Sitzungsaffinität bereit. Das Plug-in liest die Cookiedaten (bzw. den verschlüsselten URL) im Browser und hilft, die Anforderung an die entsprechende Anwendung zu leiten bzw. basierend auf dem zugeordneten Sitzungsschlüssel zu klonen. Diese Funktionalität erweitert die Verwendung des Speichercache und reduziert die Häufigkeit der Datenbankaufrufe bzw. einer anderen Instanz von WebSphere Application Server.
- Verwenden Sie mehr Sitzungsaffinität und vermeiden Sie die Unterbrechung der Affinität.
Mit richtiger Verwendung der Sitzungsaffinität können Sie die Leistung von WebSphere Application Server verbessern. Die Sitzungsaffinität in der Umgebung von WebSphere Application Server bietet die Möglichkeit, den Speichercache von Sitzungsobjekten zu vergrößern und die Menge der Lesezugriffe auf die Datenbank oder eine andere Instanz von WebSphere Application Server zu reduzieren. Die Sitzungsaffinität wird dadurch erzielt, dass Sie die Sitzungsobjekte in der Serverinstanz der Anwendung, mit der ein Benutzer interagiert, zwischenspeichern. Wenn die Anwendung auf mehreren Servern einer Servergruppe implementiert wird, kann die Anwendung den Benutzer an einen dieser Server weiterleiten. Wenn der Benutzer auf Server1 gestartet und später an Server2 weitergeleitet wird, muss der Server alle Sitzungsdaten in das externe Verzeichnis schreiben, damit die Serverinstanz, auf der Server2 ausgeführt wird, die Datenbank lesen kann. Sie können diesen Lesezugriff auf die Datenbank vermeiden, wenn Sie mit Sitzungsaffinität arbeiten. Bei Verwendung der Sitzungsaffinität startet der Benutzer mit der ersten Anforderung auf server1. Bei jeder nachfolgenden Anforderung wird der Benutzer an server1 zurückgeleitet. Server1 muss nur den Cache prüfen, um die Sitzungsdaten abzurufen, er muss keinen Aufruf an die Sitzungsdatenbank absetzen, um die Daten abzurufen.
Sie können die Leistung verbessern, wenn Sie die Sitzungsaffinität nicht unterbrechen. Es folgen einige Vorschläge, die helfen sollen, das Unterbrechen der Sitzungsaffinität zu vermeiden:- Kombinieren Sie alle Webanwendungen, falls möglich, zu einer Einzelinstanz eines Anwendungsservers, und stellen Sie über das Modellieren oder Klonen die Failoverunterstützung bereit.
- Erstellen Sie die Sitzung für die Rahmenseite, erstellen Sie jedoch innerhalb des Rahmens keine Sitzungen, wenn Sie JSP-Dateien mit mehreren Rahmen verwenden. (Weiter unten wird dies ausführlich erläutert.)
- Führen Sie bei Verwendung der nachfolgenden Richtlinien folgende Schritte durch:
- Erstellen Sie eine Sitzung in nur einem Rahmen, bevor Sie auf Rahmengruppen zugreifen. Wenn Sie z. B. annehmen, dass dem Browser noch keine Sitzung zugeordnet wurde und ein Benutzer auf eine JSP-Datei mit mehreren Rahmen zugreift, gibt der Browser gleichzeitige Anforderungen für diese JSP-Dateien aus. Da die Anforderungen nicht Teil einer Sitzung sind, erstellen die JSP-Dateien schließlich mehrere Sitzungen, und alle Cookies werden an den Browser zurückgeschickt. Der Browser akzeptiert nur das letzte eintreffende Cookie. Daher kann nur der Client die Sitzung, die dem letzten Cookie zugeordnet ist, abrufen. Es wird empfohlen, vor dem Zugriff auf Seiten mit mehreren Rahmen, die JSP-Dateien verwenden, eine Sitzung zu erstellen.
- Standardmäßig rufen JSP-Dateien eine HTTPSession mit der Methode request.getSession(true) ab. Daher erstellen die JSP-Dateien standardmäßig eine neue Sitzung, wenn keine Sitzung für den Client vorhanden ist. Jede JSP-Seite im Browser ruft eine neue Sitzung ab, pro Browserinstanz wird jedoch nur eine Sitzung verwendet. Ein Entwickler kann die Einstellung <% @ page session="false" %> verwenden, um die automatische Sitzungserstellung durch die JSP-Dateien, die nicht auf die Sitzung zugreifen, zu inaktivieren. Wenn die Seite dann auf die Sitzungsdaten zugreifen muss, kann der Entwickler die Einstellung <%HttpSession session = javax.servlet.http.HttpServletRequest.getSession(false); %> verwenden, um die bereits vorhandene Sitzung, die von der ursprünglichen JSP-Datei erstellt wurde, abzurufen. Diese Aktion hilft, die Unterbrechung der Sitzungsaffinität für das anfängliche Laden der Rahmenseiten zu verhindern.
- Aktualisieren Sie die Sitzungsdaten mit nur einem Rahmen. Bei der Verwendung von Rahmengruppen gehen Anforderungen gleichzeitig auf dem HTTP-Server ein. Es wird empfohlen, die Sitzungsdaten in nur einem Rahmen zu ändern, so dass Sitzungsänderungen nicht versehentlich durch Sitzungsänderungen in einem anderen Rahmen überschrieben werden.
- Vermeiden Sie es, JSP-Seiten mit mehreren Rahmen zu verwenden, in denen die Rahmen auf verschiedene Webanwendungen zeigen. Diese Aktion führt dazu, dass die von einer anderen Webanwendung erstellte Sitzung verloren geht, da das Cookie JSESSIONID, das von der ersten Webanwendung erstellt wird, durch das Cookie JSESSIONID der zweiten Webanwendung überschrieben wird.
- Sichern Sie alle Seiten (nicht nur einige), wenn Sie die Sicherheitskomponente auf Servlets oder JSP-Dateien anwenden, die Sitzungen mit aktivierter Sicherheitsintegration verwenden.
Beim Sitzungsschutz schützen sind keine Zwischenlösungen möglich. Es macht keinen Sinn, den Zugriff auf den Sitzungsstatus nur für einen bestimmten Zeitraum zu schützen. Wenn die Sicherheitsintegration im Tool für die Sitzungsverwaltung aktiviert ist, müssen alle Ressourcen, mit denen eine Sitzung erstellt wird bzw. mit denen auf die Sitzung zugegriffen wird, geschützt oder ungeschützt sein. Sie können geschützte und ungeschützte Ressourcen nicht mischen.
Wenn Sie nur einige Seiten schützen, haben Sie das Problem, dass die auf geschützten Seiten erstellten Sitzungen unter der Identität des authentifizierten Benutzers erstellt werden. Nur ein und derselbe Benutzer kann auf Sitzungen zugreifen, die sich auf anderen geschützten Seiten befinden. Zum Schutz dieser Sitzungen vor unbefugten Benutzern ist der Zugriff über eine ungeschützte Seite nicht möglich. Wenn eine Anforderung über eine ungeschützte Seite erfolgt, wird der Zugriff verweigert und der Fehler UnauthorizedSessionRequestException ausgelöst. (UnauthorizedSessionRequestException ist eine Laufzeitausnahmebedingung, die für den Benutzer protokolliert wird.)
- Verwenden Sie die manuelle Aktualisierung, und führen Sie bei Anwendungen,
die Sitzungsdaten lesen, die Methode sync() bzw. einen zeitbasierten Schreibzugriff aus. Führen Sie die Aktualisierung selten durch.
Wenn eine Anwendung Sitzungen verwendet und immer, wenn ein Lese- oder Schreibzugriff auf Daten in dieser Sitzung erfolgt, wird der Wert im Feld "Letzte Zugriffszeit" aktualisiert, vorausgesetzt, END_OF_SERVICE ist als Schreibfrequenz angegeben. Bei der Verwendung von Datenbanksitzungen wird ein neuer Schreibzugriff auf die Datenbank durchgeführt. Diese Aktivität stellt eine Leistungsbeeinträchtigung dar, die Sie mit der manuellen Aktualisierung vermeiden können. Bei dieser Form der Aktualisierung werden Datensätze nur im Falle einer tatsächlichen Aktualisierung der Datenwerte und nicht bei jedem Lese- oder Schreibzugriff in die Datenbank geschrieben.
Möchten Sie die manuelle Aktualisierung verwenden, aktivieren Sie sie im Session Management Service. (Die Tabellen weiter oben enthalten Informationen zu den Positionen.) Außerdem muss der Anwendungscode die Klasse com.ibm.websphere.servlet.session.IBMSession anstelle der generischen HttpSession verwenden. Im Objekt IBMSession gibt es eine Methode mit dem Namen sync. Diese Methode weist WebSphere Application Server an, die Daten des Sitzungsobjekts in die Datenbank zu schreiben. Diese Aktivität hilft dem Entwickler, die Gesamtleistung zu verbessern, da die Sitzungsdaten nur bei Bedarf persistent gespeichert werden.
Anmerkung: Eine Alternative zur manuellen Aktualisierung sind zeitverzögerte Aktualisierungen. Diese werden verwendet, um Daten in verschiedenen Zeitintervallen persistent zu speichern. Diese Aktion bietet ähnliche Ergebnisse wie das Schema für manuelle Aktualisierung. - Führen Sie die folgenden Schritte aus, um eine hohe Leistung zu erzielen:
- Wenn die Anwendungen die Sitzungsdaten nicht häufig ändern, verwenden Sie die manuelle Aktualisierung und die Funktion sync bzw. die zeitverzögerte Intervallaktualisierung, um Sitzungsdaten persistent speichern zu können.
- Speichern Sie in der Sitzung so wenig Daten wie möglich. Da es sehr einfach ist, Daten in Sitzungen zu speichern, werden manchmal zu viele Daten in den Sitzungsobjekten gespeichert. Achten Sie auf den richtigen Ausgleich zwischen Datenspeicherung und Leistung, um Sitzungen effektiv nutzen zu können.
- Wenn Sie mit Datenbanksitzungen arbeiten, verwenden Sie eine dedizierte Datenbank als Sitzungsdatenbank. Vermeiden Sie es, die Anwendungsdatenbank zu verwenden. Auf diese Weise können Sie Konfliktsituationen für JDBC-Verbindungen leichter vermeiden und eine bessere Datenbankleistung erzielen.
- Wenn Sie mit speicherübergreifenden Sitzungen arbeiten, nutzen Sie die Partitionierungsfeatures (Gruppe oder einzelnes Replikat), weil Ihre Cluster anwachsen können und die Skalierungsmöglichkeiten abnehmen.
- Vergewissern Sie sich, dass Sie die aktuellsten Fixpacks für WebSphere Application Server verwenden.
- Verwenden Sie die folgenden Tools, um die Sitzungsleistung zu überwachen.
- Führen Sie das Servlet com.ibm.servlet.personalization.sessiontracking.IBMTrackerDebug aus. Zur Ausführung dieses Servlet müssen Sie das Servlet Invoker in der Webanwendung ausführen, in der Sie das genannte Servlet ausführen möchten. Sie haben auch die Möglichkeit, dieses Servlet explizit in der auszuführenden Anwendung auszuführen.
- Verwenden Sie die Ressourcenanalyse von WebSphere Application Server, die mit WebSphere Application Server geliefert wird, um aktive Sitzungen und Statistiken für die Umgebung von WebSphere Application Server zu überwachen.
- Verwenden Sie Tools zur Datenbanküberwachung, wie z. B. "Monitoring" bei DB2. (Siehe entsprechende Dokumentation zum verwendeten Datenbanksystem.)