¿Por qué HttpServlet implementa Serializable?

Question

En mi comprensión de Servlet, el Servlet será instanciado por el Contenedor, se llamará una vez al método init(), y el servlet vivirá como un singleton hasta que la JVM se apague.

No espero que mi servlet sea serializado, ya que se construirá nuevo cuando el servidor de aplicaciones se recupere o se inicie normalmente. El servlet no debe contener miembros específicos de la sesión, por lo que no tiene sentido que se escriba en el disco y vuelva a crear instancias. ¿Existe un uso práctico para esto?

Mi preocupación es que coloque algunos campos no serializables y mi aplicación fallará misteriosamente en un entorno de producción donde se producirá un tipo diferente de replicación de la sesión.

Answer 1

Técnicamente, creo que el contenedor de servlets puede "pasivar" el objeto de servlet al disco, de forma similar a como lo hacen las beans de sesión EJB. Así que está en lo correcto al hacer la pregunta si su aplicación fallará debido a campos no serializables.

En la práctica, nunca he oído hablar de un contenedor que haga esto, por lo que en realidad es solo un equipaje heredado de los viejos tiempos malos de J2EE. Yo no me preocuparía por eso.

Answer 2

Google parece sugerir que esto se hizo para que los autores del contenedor puedan tener la opción, si lo desean.

Tiene razón en que el servlet no debería contener miembros específicos de la sesión, de hecho, creo que querría el menor estado posible. Si almacena todo en Session o ServletConfig, creo que podrá sobrevivir a la serialización.

Answer 3

Al igual que los objetos de sesión se serializan para sobrevivir los cachés para aquellos servletcontainers que dan la opción de clúster, ¿podría haber una opción para que un contenedor transfiera una instancia de servlet a otro nodo de clúster? Solo estoy adivinando aquí

Answer 4

HttpServlet debe serializarse en el disco y sobrevivir al reinicio del contenedor de servlets. Por ejemplo, tomcat te permite configurar un marcador que habilite este tipo de supervivencia. La siguiente opción es la transferencia usando JNDI. Esto no es basura, solo se usa en casos de uso extremo.

Answer 5

Serializable se utiliza como una interfaz de marcador para los atributos de la sesión en el entorno distribuido.

SRV.7.7.2 entornos distribuidos (JSR-154)

Dentro de una aplicación marcada como distribuible, todas las solicitudes que son parte de una sesión debe ser manejado por uno virtual de Java Máquina ("JVM") a la vez. El contenedor debe ser capaz de manejar todos los objetos colocados en instancias de la clase HttpSession usando los métodos setAttribute o putValue apropiadamente. Las siguientes restricciones se imponen para satisfacer estas condiciones:

• El recipiente debe aceptar objetos que implementan la interfaz Serializable.
• La migración de las sesiones se realizará mediante instalaciones específicas del contenedor.

El contenedor de servlets distribuido debe lanzar una IllegalArgumentException de objetos en los que el contenedor no puede apoyar el mecanismo necesario para la migración de la sesión almacenar ellos.

El contenedor servlet distribuido debe ser compatible con el mecanismo necesario para objetos que migran que implementan Serializable.

(...)

El proveedor de contenedores puede garantizar la escalabilidad y calidad de servicio características como el balanceo de carga y conmutación por error tener la capacidad de mover un objeto de sesión, y su contenido, de cualquier activo nodo del sistema distribuido en un nodo diferente del sistema. Si distribuidos contenedores persisten o migran sesiones para proporcionar una calidad de características de servicio, que no se limitan al uso de la JVM mecanismo de serialización nativa para serializar HttpSessions y sus atributos . Los desarrolladores no tienen garantizado que los contenedores llamarán a los métodos readObject y writeObject en los atributos de sesión si los implementan, pero tienen garantizado que el cierre de de Serializable se conservarán sus atributos.