Why does HttpServlet implement Serializable?

Question

In my understanding of Servlet, the Servlet will be instantiated by the Container, its init() method will be called once, and the servlet will live like a singleton until the JVM shuts down.

I do not expect my servlet to be serialized, since it will be constructed new when the app server recovers or is starts up normally. The servlet should hold no session-specific members, so it does not make sense for it to be written to disk and re-instantiated. Is there a practical use for this?

My concerns are, that I put some non-serializable fields within there and then my app will mysteriously fail in a production environment where a different sort of session replication will take place.

Hepcat

Similar: Purpose of Serialization in webapplication – Referent

Answer 1

Technically, I believe the servlet container is allowed to "passivate" the servlet object to disk, in a similar way that EJB session beans can be. So you're correct to ask the question if your app will fail due to non-serializable fields.

In practise, I've never heard of a container doing this, so it's really just legacy baggage from the bad old days of early J2EE. I wouldn't worry about it.

Hick

But who needs passivate a servlet, when it shall be thread-safe, and have no conversation state? – Karli

It is so as to make cluster servers not fail and map session across in case o failures a similar bug verifies it, issues.apache.org/bugzilla/show_bug.cgi?id=30809 – Dibucaine

@dev the bug is about non-serializable session attributes, NOT about any serialization of servlets. – Henni

This can be triggered by having <distributable /> in web.xml. – Dionnedionysia

Actually I experienced this in real life: The IBM Websphere was doing this... – Bossism

Answer 2

HttpServlet can be serialized to disk and survive restart of servlet container. For example, Tomcat allows you to set up a flag which enables this kind of survive. The next option is transfer using JNDI. This is not garbage, it is used only in extreme use cases.

Saleem

Is JNDI the only right way to set fields which aren't serialisable? It's so horrible. :( – Bergson

Answer 3

Google seems to suggest that this was done so that container authors can have the option, if they want it.

You're correct that the servlet should hold no session-specific members, in fact I would think you'd want as little state at all as possible. If you store everything in either Session or ServletConfig, I think you'd be able to survive serialization.

Sherl

Well the Session is far more likely to be serialized than the servlet, so storing it there wouldn't mitigate the problem. – Hick

@matt b: the concern is not so much session-specific state as the servlet's own dependencies (e.g. service layer objects) – Refresher

Answer 4

Just like Session objects are serialized to survive caches for those servletcontainers giving the cluster option, there might be an option for a container to transfer a Servlet instance as well to another cluster node ?? I'm just guessing here

Camire

Answer 5

Serializable is used as a marker interface for session's attributes in distributed environment.

SRV.7.7.2 Distributed Environments (JSR-154)

Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine (“JVM”) at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately. The following restrictions are imposed to meet these conditions:

• The container must accept objects that implement the Serializable interface.
• Migration of sessions will be handled by container-specific facilities.

The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot support the mechanism necessary for migration of the session storing them.

The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable.

(...)

The Container Provider can ensure scalability and quality of service features like load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system. If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.

Smilax

This is a misleading answer. A servlet instance is normally not stored in the session. – Paintbrush