Pourquoi HttpServlet implémente-t-il Serializable?

Question

Si je comprends bien Servlet, celui-ci sera instancié par le conteneur, sa méthode init () sera appelée une fois et le servlet vivra comme un singleton jusqu'à la fermeture de la machine virtuelle Java.

Je ne m'attends pas à ce que mon servlet soit sérialisé, car il sera construit à nouveau lorsque le serveur d'applications sera restauré ou démarrera normalement. La servlet ne doit contenir aucun membre spécifique à la session. Il n'est donc pas logique qu'elle soit écrite sur le disque et ré-instanciée. Y at-il une utilisation pratique pour cela?

Mes préoccupations sont que je place des champs non sérialisables à l'intérieur, puis mon application échouera mystérieusement dans un environnement de production dans lequel un type de réplication de session différent aura lieu.

Answer 1

Techniquement, je pense que le conteneur de servlets est autorisé à "passiver". l'objet servlet sur le disque, de la même manière que les beans session EJB. Vous avez donc raison de poser la question si votre application va échouer à cause de champs non sérialisables.

En pratique, je n’ai jamais entendu parler d’un conteneur qui le fasse, c’est donc tout simplement le bagage hérité du mauvais vieux temps de J2EE. Je ne m'inquiéterais pas pour ça.

Answer 2

HttpServlet doit être sérialisé sur le disque et survivre au redémarrage du conteneur de servlet. Par exemple, tomcat vous permet de configurer des indicateurs permettant ce type de survie. L'option suivante est le transfert via JNDI. Ce n'est pas un déchet, il est utilisé uniquement dans des cas d'utilisation extrêmes.

Answer 3

Google semble suggérer que cela a été fait pour que les auteurs de conteneurs puissent avoir la possibilité s’ils le souhaitent.

Vous avez raison de dire que le servlet ne doit contenir aucun membre spécifique à une session. En fait, je pense que vous voudriez avoir le moins d’état possible. Si vous stockez tout dans Session ou ServletConfig, je pense que vous pourrez survivre à la sérialisation.

Answer 4

Tout comme les objets de session sont sérialisés pour survivre aux caches de ces conteneurs de servlet donnant l'option de cluster, il est possible qu'un conteneur puisse également transférer une instance de servlet vers un autre nœud de cluster? Je devine juste ici

Answer 5

Serializable est utilisé comme interface de marqueur pour les attributs de session dans un environnement distribué.

  

Environnements distribués SRV.7.7.2 (JSR-154)

     

Dans une application marquée distribuable , toutes les demandes qui   font partie d'une session doivent être gérés par une machine virtuelle Java   (“JVM”) à la fois. Le conteneur doit être capable de gérer tous les objets   placé dans des instances de la classe HttpSession à l'aide de setAttribute   ou méthodes putValue de manière appropriée. Les restrictions suivantes sont   imposées pour remplir ces conditions:

     

  
• Le conteneur doit accepter les objets qui implémentent l'interface Serializable .
  
• La migration des sessions sera gérée par des installations spécifiques aux conteneurs.
  

     

Le conteneur de servlet distribué doit lancer une   IllegalArgumentException pour les objets pour lesquels le conteneur ne peut pas   prend en charge le mécanisme nécessaire à la migration de la session de stockage   les .

     

Le conteneur de servlets distribués doit prendre en charge le mécanisme nécessaire.   pour    objets de migration qui implémentent Serializable .

     

(...)

     

Le fournisseur de conteneurs peut assurer l'évolutivité et la qualité de service   des fonctionnalités telles que l'équilibrage de la charge et le basculement en ayant la capacité de   déplacer un objet de session et son contenu depuis n’importe quel noeud actif du   système distribué sur un autre noeud du système. Si distribué   les conteneurs persistent ou migrent des sessions pour fournir une qualité de   fonctionnalités de service, ils ne sont pas limités à l’utilisation de la machine virtuelle Java native   Mécanisme de sérialisation pour la sérialisation de HttpSessions et de leurs   les attributs. Les développeurs ne sont pas assurés que les conteneurs appellent   méthodes readObject et writeObject sur les attributs de session s'ils   les mettre en œuvre, , mais ont la garantie que la fermeture sérialisable de   leurs attributs seront préservés .