Hinweise zu Verbindungen bei der Migration von Servlets, JavaServer Pages und Enterprise-Session-Beans

Falls Sie ein Upgrade auf WebSphere Application Server Version 7.0 oder höher planen und Anwendungen von der Spezifikation Java™ 2 Platform, Enterprise Edition (J2EE) Version 1.2 auf eine höhere Version, z. B. Java Platform, Enterprise Edition (Java EE) Version 1.4 migrieren, müssen Sie beachten, dass das Produkt gemeinsam nutzbare und nicht gemeinsam nutzbare Verbindungen für Anwendungskomponenten mit einer höheren Version als Version 1.2 unterschiedlich zuordnet. Für einige Anwendungen kann dieser Unterschied Leistungseinbußen zur Folge haben.

Nachteilige Verhaltensänderungen

Da WebSphere Application Server die Abwärtskompatibilität mit Anwendungsmodulen unterstützt, die auf der Spezifikation J2EE 1.2 basieren, können Sie die Datenquellen der Version 4 weiterhin verwenden, wenn Sie eine Migration auf WebSphere Application Server Version 7.0 oder höher durchführen. Solange Sie die Datenquellen der Version 4 nur für J2EE-Module der Version 1.2 konfigurieren, ändert sich das Verhalten Ihrer Anwendungskomponenten für Datenzugriff nicht.

Wenn Sie im Rahmen der Migration auf WebSphere Application Server Version 7.0 oder höher die Umstellung auf eine neuere Version der J2EE-Spezifikation durchführen, kann sich das Verhalten der Datenzugriffskomponenten jedoch ändern. Dies gilt insbesondere für Anwendungen, die Servlets, JSP-Dateien oder Enterprise-Session-Beans enthalten, die über gemeinsam genutzte Verbindungen in lokalen Transaktionen ausgeführt werden. Eine Änderung im Verhalten von Datenzugriffskomponenten kann sich nachteilig auf die Verbindungen in solchen Anwendungen auswirken.

Diese Änderungen betrifft alle Anwendung, die die folgenden Methoden enthalten:

Fehlersymptome:

Anmerkung: Sie stellen diese Symptome möglicherweise auch bei Anwendungen fest, die die zuvor beschriebenen Komponenten und Methoden enthalten, wenn Sie ein Upgrade von J2EE-Modulen der Version 1.2 in WebSphere Application Server Version 7.0 oder höher durchführen.

Zuordnung von gemeinsam nutzbaren und nicht gemeinsam nutzbaren Verbindungen

Für J2EE-Module der Version 1.2, die Datenquellen der Version 4 verwenden, erzeugt WebSphere Application Server nicht gemeinsam nutzbare Verbindungen zu JSP-Dateien, Servlets und Enterprise-Session-Beans. Für alle anderen Anwendungskomponenten werden gemeinsam nutzbare Verbindungen erstellt. Bei J2EE-Modulen der Version 1.3 und höher erzeugt der Anwendungsserver jedoch gemeinsam nutzbare Verbindungen zu allen logisch benannten Ressourcen (Ressourcen, die an einzelne Referenzen gebunden sind), sofern Sie die Verbindungen in den einzelnen Ressourcenreferenzen nicht als nicht gemeinsam nutzbar deklarieren. Die Verwendung von nicht gemeinsam nutzbaren Verbindungen in diesem Kontext hat folgende Auswirkungen:

  • Alle Verbindungen, die außerhalb des Geltungsbereichs einer Benutzertransaktion empfangen und verwendet werden, werden nicht an den Pool freier Verbindungen zurückgegeben, bis die einbindende Methode zurückgegeben wird, selbst wenn die Verbindungskennung einen Aufruf close() absetzt.
  • Alle Verbindungen, die außerhalb des Geltungsbereichs einer Benutzertransaktion empfangen und verwendet werden, werden nicht mit anderen Komponenteninstanzen (d. h., anderen Servlets, JSP-Dateien oder Enterprise-Beans) gemeinsam genutzt. Beispiel: Session-Bean 1 fordert eine Verbindung an und ruft dann Session Bean 2 auf, die ebenfalls eine Verbindung anfordert. Selbst wenn alle Eigenschaften identisch sind, erhält jede Session-Bean eine eigene Verbindung.

Wenn Sie diese Änderung im Verbindungsverhalten nicht erwarten, führt möglicherweise die Art und Weise, wie Sie den Anwendungscode strukturieren, dazu, dass übermäßig viele Verbindungen verwendet werden, insbesondere im Falle von JSP-Includes, RequestDispatcher.include()-Routinen, RequestDispatcher.forward()-Routinen, Session-Beans mit Bean-gesteuerten Transaktionen oder Aufrufen, die von diesen Methoden an andere Komponenten abgesetzt werden. Als Folge davon können Sitzungen blockiert werden, das Zeitlimit der Sitzungen kann ablaufen oder Verbindungen können verloren gehen.

Beispielszenario

Servlet A ruft eine Verbindung ab, schließt den Vorgang ab, schreibt die Verbindung fest und ruft close() für die Verbindung ab. Dann ruft Servlet A RequestDispatcher.include() auf, um Servlet B aufzunehmen, das dieselben Schritte durchführt wie Servlet A. Da die Verbindung von Servlet A nicht in den Pool der freien Verbindungen zurückgegeben wird, bis sie von der aktuellen Methode zurückgegeben wird, sind jetzt zwei Verbindungen belegt. Auf diese Weise sind in Ihrer Anwendung möglicherweise mehr Verbindungen belegt als beabsichtigt. Wenn diese Verbindung in der Einstellung Maximalanzahl der Verbindungen im Verbindungspool nicht berücksichtigt werden, kann dieses Verhalten dazu führen, dass der Pool zu wenige Verbindungen enthält. Dies führt dazu, dass eine ConnectionWaitTimeOutExceptions ausgelöst wird. Wenn die zulässige Wartezeit für eine Verbindung nicht aktiviert ist oder für die zulässige Wartezeit für eine Verbindung ein hoher Wert festgelegt wurde, können diese Threads scheinbar blockiert sein, da sie auf Verbindungen warten, die nie in den Pool zurückgegeben wurden. Threads, die auf neue Verbindungen warten, geben die Verbindungen, die sie derzeit nutzen, nicht zurück, wenn keine neuen Verbindungen verfügbar sind.

Problemlösung

Gehen Sie wie folgt vor, um diese Fehler zu beheben:

  1. Verwenden Sie Verbindungen, die nicht gemeinsam verwendet werden.

    Wenn Sie eine nicht gemeinsam verwendete Verbindung verwenden und keine Benutzertransaktion ausführen, wird die Verbindung in den Pool der freien Verbindungen zurückgegeben, wenn Sie einen Aufruf close() absetzen (vorausgesetzt, Sie schreiben die Verbindung fest oder setzen sie zurück).

  2. Erhöhen Sie die maximale Anzahl der Verbindungen.

    Zur Berechnung der Anzahl der erforderlichen Verbindungen müssen Sie die Anzahl der konfigurierten Threads mit der tiefsten Ebene der Verschachtelung von Komponentenaufrufen multiplizieren (für Aufrufe, die Verbindungen nutzen). Der Abschnitt Beispielszenario enthält eine Beschreibung der Verschachtelung von Aufrufen.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



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