Por que HttpServlet implementar Serializable?

Question

No meu entendimento de Servlet, o Servlet será instanciado pela Container, seu método init() será chamado uma vez, e o servlet vai viver como um singleton até o JVM é desligado.

Eu não espero que o meu servlet para ser serializado, uma vez que irá ser construído novo quando os recupera de servidores de aplicativos ou é iniciado normalmente. O servlet deve realizar nenhum membro específicos da sessão, por isso não faz sentido para que possa ser gravado em disco e instanciado re-. Existe um uso prático para isso?

As minhas preocupações são, que eu coloquei alguns campos não serializáveis ??dentro lá e, em seguida, meu aplicativo irá falhar misteriosamente em um ambiente de produção, onde um tipo diferente de replicação de sessão terá lugar.

Answer 1

Tecnicamente, acredito que o servlet container é permitido "passivate" o objeto servlet para o disco, de uma forma semelhante que EJB beans de sessão pode ser. Então, você está correto para fazer a pergunta se o seu aplicativo irá falhar devido a campos não serializáveis.

Na prática, eu nunca ouvi falar de um recipiente de fazer isso, por isso é realmente apenas bagagem legado dos maus velhos tempos da J2EE cedo. Eu não me preocuparia com isso.

Answer 2

HttpServlet deve por serializado para o disco e sobreviver reinício do servlet container. Por exemplo tomcat permite configurar bandeira que permitem este tipo de sobreviver. A próxima opção é transferir usando JNDI. Isso não é lixo, é usado apenas em casos de uso extremas.

Answer 3

O Google parece sugerir que isso foi feito para que os autores de contêiner pode ter a opção, se eles querem.

Você está correto que o servlet deve realizar nenhum membro específicos da sessão, na verdade eu acho que você iria querer tão pouco estado em tudo quanto possível. Se você armazenar tudo em qualquer sessão ou ServletConfig, eu acho que você seria capaz de sobreviver a serialização.

Answer 4

Assim como objetos de sessão são serializados para sobreviver caches para esses servletcontainers dando a opção de cluster, pode haver uma opção para um recipiente para transferir uma instância Servlet, bem como para outro nó de cluster ?? Eu estou apenas supondo aqui

Answer 5

Serializable é usado como um marcador de interface para os atributos da sessão em ambiente distribuído.

<> fortes Ambientes SRV.7.7.2 distribuído (JSR-154)

Dentro de uma aplicação marcada como distribuíveis , todas as solicitações que são parte de uma sessão devem ser manuseados por uma Máquina Virtual Java ( “JVM”) de cada vez. O recipiente deve ser capaz de lidar com todos os objetos colocado em instâncias de classe HttpSession usando o setAttribute ou métodos putValue adequadamente. As seguintes restrições são imposta para atender a essas condições:

• O recipiente deve aceitar objetos que implementam a interface Serializable .
• A migração de sessões serão tratadas por instalações específicas do recipiente.

O servlet container distribuído deve lançar uma IllegalArgumentException para objetos onde o recipiente não pode apoiar o mecanismo necessário para a migração do armazenamento sessão -los .

O servlet container distribuído deve apoiar o mecanismo necessário para migração de objetos que implementam Serializable .

(...)

O Provedor de Container pode garantir escalabilidade e qualidade de serviço características como balanceamento de carga e failover por ter a capacidade de mover um objecto de sessão, e o seu conteúdo, a partir de qualquer nó activo do sistema distribuído para um nó diferente do sistema. Se distribuído recipientes persistirem ou sessões Migrar para proporcionar qualidade de características do serviço, não está restrito a utilizar a JVM nativo mecanismo de serialização para serialização HttpSession e sua atributos. Os desenvolvedores não está garantido que os recipientes chamará métodos readObject e writeObject sobre atributos de sessão se eles implementá-los, , mas é garantido que o fechamento Serializable de seus atributos serão preservados .