java - serialize - ¿Por qué HttpServlet implementa Serializable?
serialize class (5)
En mi comprensión de Servlet, el Servlet será instanciado por el Contenedor, su método init() 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.
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í
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.
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.
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.
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 deben ser manejadas por una Máquina Virtual Java ("JVM") a la vez. El contenedor debe poder gestionar todos los objetos colocados en las instancias de la clase HttpSession utilizando los métodos setAttribute o putValue de forma adecuada. Las siguientes restricciones se imponen para cumplir 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 lanzar una IllegalArgumentException para los objetos donde el contenedor no puede admitir el mecanismo necesario para la migración de la sesión que los almacena .
El contenedor de servlet distribuido debe admitir el mecanismo necesario para migrar objetos que implementan Serializable .
(...)
El proveedor de contenedores puede garantizar la escalabilidad y la calidad de las características del servicio, como el equilibrio de carga y la conmutación por error al tener la capacidad de mover un objeto de sesión y sus contenidos desde cualquier nodo activo del sistema distribuido a un nodo diferente del sistema. Si los contenedores distribuidos persisten o migran sesiones para proporcionar características de calidad de servicio, no están limitados a utilizar el mecanismo de serialización JVM nativo para serializar HttpSessions y sus atributos. Los desarrolladores no tienen garantizado que los contenedores invoquen los métodos readObject y writeObject en los atributos de sesión si los implementan, pero se les garantiza que se conservará el cierre Serializable de sus atributos .