Servlet-Pooling inaktivieren: Empfohlene Methoden und Hinweise
Sie können den Zusammenschluss (Pooling) von Anforderungen und Antworten inaktivieren, wenn Ihre Anwendung Threads innerhalb der Anwendung erstellt oder wenn Sie verhindern möchten, dass der Web-Container Anforderungs- und Antwortobjekte wiederverwendet.
Pooling von Anforderungen und Antworten inaktivieren
- Die Anwendung erstellt Threads innerhalb der Anwendung.
Die Spezifikation Servlet 2.4 beschreibt Folgendes:
SRV.4.10 - Lebensdauer des Anforderungsobjekts Jedes Anforderungsobjekt ist nur im Geltungsbereich der Servicemethode eines Servlets oder im Geltungsbereich der Methode doFilter eines Filters gültig. Normalerweise stoppen Container Anforderungsobjekte und starten sie dann erneut, um Leistungseinbußen durch die Erstellung von Anforderungsobjekten zu vermeiden. Der Entwickler muss wissen, dass die Verwendung von Referenzen auf Anforderungsobjekte außerhalb des zuvor beschriebenen Geltungsbereichs nicht empfehlenswert ist, da dies zu unerwarteten Ergebnisse führen kann.
SRV.5.6 - Lebensdauer des Antwortobjekts Jedes Antwortobjekt ist nur im Geltungsbereich der Servicemethode eines Servlets oder im Geltungsbereich der Methode doFilter eines Filters gültig. Normalerweise stoppen Container Antwortobjekte und starten sie dann erneut, um Leistungseinbußen durch die Erstellung von Antwortobjekten zu vermeiden. Der Entwickler muss wissen, dass die Verwendung von Referenzen auf Antwortobjekte außerhalb des zuvor beschriebenen Geltungsbereichs nicht empfehlenswert ist, da dies zu unerwarteten Ergebnissen führen kann.
- Sie möchten verhindern, dass der Web-Container
Anforderungs- und Antwortobjekte wiederverwendet.
Da diese Objekte wiederverwendet werden, haben Sie das Potenzial für zwei Anforderungen in zwei eigenständigen Anwendungen, die Zugriff auf dasselbe Anforderungs- oder Antwortobjekt haben, wie im Abschnitt zur Threadsicherheit der Spezifikation Servlet 2.4 beschrieben.
SRV.2.3.3.3 - Threadsicherheit Implementierungen der Anforderungs- und Antwortobjekte sind nicht garantiert threadsicher. Das bedeutet, dass sie nur im Geltungsbereich des Anforderungsverarbeitungsthreads verwendet werden sollten.
Referenzen auf die Anforderungs- und Antwortobjekte sollten nicht Objekten, die in anderen Threads aktiv sind, zugeordnet werden, da dies zu unerwarteten Ergebnissen führen kann. Wenn der von der Anwendung erstellte Thread die containergesteuerten Objekte, z. B. das Anforderungs- oder das Antwortobjekt, verwendet, darf der Zugriff auf diese Objekte nur im Geltungsbereich des Servlet-Service erfolgen. Also sollte der Thread selbst einen Lebenszyklus innerhalb des Lebenszyklus der Servlet-Servicemethode haben, da der Zugriff auf diese Objekte nach der Beendigung der Servicemethode nicht vorhersehbare Probleme zur Folge haben kann. Denken Sie daran, dass die Anforderungs- und Antwortobjekte nicht threadsicher sind. Wenn auf diese Objekte in mehreren Threads zugegriffen wurde, muss der Zugriff synchronisiert oder über den Wrapper durchgeführt werden, um die Threadsicherheit hinzuzufügen. Beispiele: Synchronisation des Aufrufs der Methoden für den Zugriff auf das Anforderungsattribut oder Verwendung eines lokalen Ausgabedatenstroms für das Antwortobjekt in einem Thread.