Warum implementiert HttpServlet Serializable?

Lesezeit: 4 Minuten

Nach meinem Verständnis von Servlet wird das Servlet vom Container instanziiert, its init() -Methode wird einmal aufgerufen, und das Servlet bleibt wie ein Singleton, bis die JVM heruntergefahren wird.

Ich erwarte nicht, dass mein Servlet serialisiert wird, da es neu erstellt wird, wenn der App-Server wiederhergestellt oder normal gestartet wird. Das Servlet sollte keine sitzungsspezifischen Mitglieder enthalten, daher ist es nicht sinnvoll, es auf die Festplatte zu schreiben und erneut zu instanziieren. Gibt es dafür einen praktischen Nutzen?

Meine Bedenken sind, dass ich dort einige nicht serialisierbare Felder einfüge und meine App dann auf mysteriöse Weise in einer Produktionsumgebung fehlschlägt, in der eine andere Art der Sitzungsreplikation stattfindet.

  • Ähnlich: Zweck der Serialisierung in der Webanwendung

    – Basilikum Bourque

    27. Mai 2017 um 23:07 Uhr

Technisch glaube ich, dass der Servlet-Container das Servlet-Objekt auf der Festplatte “passivieren” darf, ähnlich wie es EJB-Session-Beans sein können. Sie stellen also zu Recht die Frage, ob Ihre App aufgrund nicht serialisierbarer Felder fehlschlagen wird.

In der Praxis habe ich noch nie von einem Container gehört, der dies tut, also ist es wirklich nur Altlasten aus den schlechten alten Tagen der frühen J2EE. Ich würde mir keine Sorgen machen.

  • Aber wer muss ein Servlet passivieren, wenn es Thread-sicher sein und keinen Konversationsstatus haben soll?

    – Amir Paschazadeh

    27. Januar 2013 um 10:56 Uhr

  • Es dient dazu, Cluster-Server nicht ausfallen zu lassen und Sitzungen zuzuordnen, falls ein ähnlicher Fehler dies bestätigt. issues.apache.org/bugzilla/show_bug.cgi?id=30809

    – Entw

    10. Januar 2014 um 10:35 Uhr


  • @dev Der Fehler betrifft nicht serialisierbare Sitzungsattribute, NICHT die Serialisierung von Servlets.

    – Arend v. Reinersdorff

    11. Januar 2017 um 22:39 Uhr

  • Dies kann durch Haben ausgelöst werden <distributable /> in web.xml.

    – Archimedes Trajano

    6. Mai 2017 um 2:45 Uhr

  • Eigentlich habe ich das im wirklichen Leben erlebt: Die IBM Websphere tat dies …

    – Lonzak

    9. Dezember 2021 um 7:39 Uhr

HttpServlet sollte auf die Festplatte serialisiert werden und den Neustart des Servlet-Containers überstehen. Mit Tomcat können Sie beispielsweise Flags einrichten, die diese Art des Überlebens ermöglichen. Die nächste Option ist die Übertragung mit JNDI. Dies ist kein Müll, es wird nur in extremen Anwendungsfällen verwendet.

  • Ist JNDI der einzig richtige Weg, um Felder festzulegen, die nicht serialisierbar sind? Es ist so schrecklich. 🙁

    – Hakanai

    21. Juni 2017 um 4:47 Uhr

Google scheint vorzuschlagen, dass dies getan wurde, damit Container-Autoren die Möglichkeit haben, wenn sie es wollen.

Sie haben Recht, dass das Servlet keine sitzungsspezifischen Mitglieder enthalten sollte. Tatsächlich würde ich denken, dass Sie so wenig Status wie möglich haben möchten. Wenn Sie alles entweder in Session oder ServletConfig speichern, könnten Sie meiner Meinung nach die Serialisierung überleben.

  • Nun, die Sitzung wird mit größerer Wahrscheinlichkeit serialisiert als das Servlet, daher würde das Speichern dort das Problem nicht entschärfen.

    – Skaffmann

    7. Oktober 2008 um 18:40 Uhr

  • @matt b: Das Anliegen ist nicht so sehr der sitzungsspezifische Zustand als die eigenen Abhängigkeiten des Servlets (z. B. Service-Layer-Objekte)

    – Andreas Schwan

    7. April 2009 um 4:38 Uhr

Genauso wie Sitzungsobjekte serialisiert werden, um Caches für jene Servletcontainer zu überleben, die die Cluster-Option angeben, könnte es eine Option für einen Container geben, eine Servlet-Instanz auch auf einen anderen Cluster-Knoten zu übertragen. Ich vermute hier nur

Serializable wird als verwendet Marker-Schnittstelle für Sitzungsattribute in einer verteilten Umgebung.

SRV.7.7.2 Verteilte Umgebungen (JSR-154)

Innerhalb einer als gekennzeichneten Anwendung verteilbarmüssen alle Anforderungen, die Teil einer Sitzung sind, jeweils von einer Java Virtual Machine („JVM“) verarbeitet werden. Der Container muss in der Lage sein, alle Objekte zu verarbeiten, die in Instanzen der HttpSession-Klasse platziert werden, indem die Methoden setAttribute oder putValue entsprechend verwendet werden. Die folgenden Einschränkungen werden auferlegt, um diese Bedingungen zu erfüllen:

  • Der Container muss Objekte akzeptieren, die die Serializable-Schnittstelle implementieren.
  • Die Migration von Sitzungen wird von containerspezifischen Einrichtungen gehandhabt.

Der verteilte Servlet-Container muss eine IllegalArgumentException für Objekte auslösen, bei denen die Container können den für die Migration der Sitzung, in der sie gespeichert sind, erforderlichen Mechanismus nicht unterstützen.

Der verteilte Servlet-Container muss den dafür erforderlichen Mechanismus unterstützen
Migrieren von Objekten, die Serializable implementieren.

(…)

Der Container Provider kann Skalierbarkeit und Servicequalitätsfunktionen wie Load-Balancing und Failover durch sicherstellen mit der Fähigkeit, ein Sitzungsobjekt und seinen Inhalt von jedem aktiven Knoten des verteilten Systems zu einem anderen Knoten des Systems zu verschieben. Bei verteilten Containern Sitzungen beibehalten oder migrieren Um Quality-of-Service-Funktionen bereitzustellen, sind sie nicht auf die Verwendung des nativen JVM-Serialisierungsmechanismus zum Serialisieren von HttpSessions und ihren Attributen beschränkt. Entwicklern wird nicht garantiert, dass Container readObject- und writeObject-Methoden für Sitzungsattribute aufrufen, wenn sie diese implementieren. es wird jedoch garantiert, dass der serialisierbare Abschluss ihrer Attribute erhalten bleibt.

  • Dies ist eine irreführende Antwort. Eine Servlet-Instanz wird normalerweise nicht in der Sitzung gespeichert.

    – BalusC

    5. November 2011 um 20:11 Uhr

  • Dies ist eine irreführende Antwort. Eine Servlet-Instanz wird normalerweise nicht in der Sitzung gespeichert.

    – BalusC

    5. November 2011 um 20:11 Uhr

1205120cookie-checkWarum implementiert HttpServlet Serializable?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy