Pregunta ¿Por qué HttpServlet implementa Serializable?


En mi comprensión de Servlet, el Servlet será instanciado por el contenedor, es init() El método se llamará una vez 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. ¿Hay un uso práctico para esto?

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


74
2017-10-07 18:33


origen


Respuestas:


Técnicamente, creo que el contenedor de servlets puede "pasivar" el objeto de servlet al disco, de forma similar a como lo hacen los beans de sesión de 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 había oído hablar de un contenedor que hiciera esto, por lo que en realidad se trata simplemente de un equipaje heredado de los viejos tiempos de J2EE. Yo no me preocuparía por eso.


57
2017-10-07 21:01



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.


10
2017-10-07 18:38



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.


1
2017-10-07 18:41



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


0



Serializable se usa como un 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 manejada por una máquina virtual Java   ("JVM") a la vez. El contenedor debe ser capaz de manejar todos los objetos   colocado en instancias de la clase HttpSession usando setAttribute   o métodos putValue apropiadamente. Las siguientes restricciones son   impuesto para cumplir con estas condiciones:

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

El contenedor de servlet distribuido debe arrojar un   IllegalArgumentException para objetos donde el contenedor no puede   admite el mecanismo necesario para la migración del almacenamiento de la sesión   ellos.

El contenedor de servlet distribuido debe admitir el mecanismo necesario   para    migrando objetos que implementan Serializable.

(...)

El proveedor de contenedores puede garantizar la escalabilidad y la calidad del servicio   características como equilibrio de carga y conmutación por error por tener la capacidad de   mover un objeto de sesión, y su contenido, desde cualquier nodo activo de la   sistema distribuido a un nodo diferente del sistema. Si distribuido   contenedores persistir o migrar sesiones para proporcionar calidad de   características del servicio, no están restringidas a usar la JVM nativa   Mecanismo de serialización para serializar HttpSessions y sus   atributos. Los desarrolladores no tienen garantizado que los contenedores llamarán   los métodos readObject y writeObject en los atributos de sesión si   implementarlos, pero se garantiza que el cierre Serializable de   sus atributos serán preservados.


-3