Pourquoi ne HttpServlet Sérialisable?

Dans ma compréhension de la Servlet, la Servlet sera instancié par le Conteneur, son init() méthode sera appelée une fois, et la servlet va vivre comme un singleton jusqu'à ce que la machine s'arrête.

Je ne m'attends pas mon servlet pour être sérialisé, car il sera construit de nouvelles lorsque le serveur d'application récupère ou démarre normalement. La servlet doit pas détenir la session de membres, de sorte qu'il ne fait pas de sens pour lui d'être écrites sur le disque et re-instancié.
Est-il pratique à utiliser pour cela?

Mes préoccupations, que j'ai mis quelques non sérialisable des champs à l'intérieur et puis mon application va mystérieusement échouer dans un environnement de production où une sorte différente de la réplication de session aura lieu.

InformationsquelleAutor |
  1. 59

    Techniquement, je crois que le conteneur de servlet est permis de "mettre en pause" la servlet objet de disque, de la même manière que les EJB session beans peuvent être. Donc vous avez raison de poser la question si votre application ne fonctionnera pas car non sérialisable champs.

    Dans la pratique, je n'ai jamais entendu parler d'un conteneur de faire cela, donc c'est vraiment juste l'héritage des bagages depuis l'époque du début de J2EE. Je ne serais pas s'inquiéter à ce sujet.

    • Mais qui a besoin de mettre en pause un servlet, alors qu'il doit être thread-safe, et n'ont pas l'état de la conversation?
    • C'est pour faire des serveurs de cluster est pas l'échec et la carte de session dans le cas o défaillances d'un bug similaire vérifie, issues.apache.org/bugzilla/show_bug.cgi?id=30809
    • le bug est sur le non sérialisable les attributs de session, PAS sur toute la sérialisation des servlets.
    • Cela peut être déclenché par avoir <distributable /> dans web.xml.
    InformationsquelleAutor skaffman
  2. 10

    HttpServlet devrait par sérialisé sur le disque et de survivre redémarrage de conteneur de servlet. Par exemple tomcat permet de configurer drapeau qui permettent ce genre de survivre. L'option suivante est de transférer en utilisant JNDI. Ce n'est pas des ordures, il est à utiliser que dans des cas d'utilisation.

    • Est JNDI la seule bonne façon de définir les champs qui ne sont pas serialisable? C'est tellement horrible. 🙁
    InformationsquelleAutor Rastislav Komara
  3. 1

    Google semble suggérer que cela a été fait afin que le conteneur auteurs ont la possibilité, s'ils le veulent.

    Vous avez raison que la servlet doit pas détenir la session de membres, en fait, je pense que vous voulez tant que petit état, à tous les possibles. Si vous stockez tout soit en Session ou ServletConfig, je pense que vous seriez en mesure de survivre à la sérialisation.

    • Bien que la Session est beaucoup plus susceptibles d'être sérialisé que la servlet, afin de le stocker, il n'y aurait pas d'atténuer le problème.
    • b: le problème n'est pas tant à la session de l'etat en tant que servlet propres dépendances (par exemple les objets de la couche)
    InformationsquelleAutor matt b
  4. 0

    Tout comme les objets de Session sont sérialisés pour survivre caches pour ceux servletcontainers donnant l'option de cluster, il y a peut être une option pour un conteneur pour le transfert d'un Servlet instance ainsi à un autre nœud de cluster ?? Je suis juste deviner ici

    InformationsquelleAutor anjanb
  5. -3

    Serializable est utilisé comme un interface marqueur pour la session d'attributs dans l'environnement distribué.

    SRV.7.7.2 les Environnements Distribués (JSR-154)

    Au sein d'une application marqué comme distribuable, toutes les demandes qui
    font partie d'une session doivent être traitées par une Machine Virtuelle Java
    (“JVM”) à la fois. Le conteneur doit être capable de gérer tous les objets
    placé dans les instances de la HttpSession classe à l'aide de la setAttribute
    ou putValue méthodes de façon appropriée. Les restrictions suivantes sont
    imposée pour répondre à ces conditions:

    • Le conteneur doit accepter les objets qui implémentent l'interface Serializable.
    • Migration des sessions seront gérées par le conteneur des installations spécifiques.

    Distribués conteneur de servlet doit lancer un
    IllegalArgumentException pour les objets où la conteneur ne peut pas
    soutenir le mécanisme nécessaire pour la migration de la session stockage
    leur    .

    Distribués conteneur de servlet doit prendre en charge le mécanisme nécessaire
    pour
    la migration des objets qui Sérialisable.

    (...)

    Le Fournisseur de Conteneurs peut garantir l'évolutivité et de la qualité de service
    des caractéristiques comme l'équilibrage de charge et basculement par ayant la capacité de
    déplacer un objet de session, et de son contenu, de n'importe quel nœud actif de la
    système distribué à un autre nœud du système.     Si distribuées
    conteneurs persistent ou migrer des séances de pour fournir une qualité de
    les fonctions de service, ils ne sont pas limités à l'utilisation de la native de la JVM
    Mécanisme de sérialisation pour la sérialisation HttpSessions et leur
    les attributs. Les développeurs ne sont pas garantis que les conteneurs d'appel
    readObject et writeObject sur les attributs de session si ils
    leur mise en œuvre, mais sont garantis que le Serializable fermeture de
    leurs attributs seront préservés    .

    • C'est une fausse réponse. Une servlet instance est normalement pas stockées dans la session.
    InformationsquelleAutor