Session Listener

Página 1

Agenda

Código para responder a um evento quando um objeto for adicionado a uma sessão.

Código para responder a um evento quando uma sessão for migrada de uma VM para outra.

Página 2

HttpSession Listeners

A seguir temos os diferentes Listeners da interface HttpSession:

HttpSessionListener

HttpSessionAttributeListener

HttpSessionActivationListener

HttpSessionBindingListener

Página 3

Session Listeners

O listener HttpSessionAttributeListener será disparado quando um objeto for adicionado como atributo da sessão.

As classes Listener e Servlet serão primeiramente criadas.

O Descritor de Implantação ou arquivo web.xml é então configurado em seguida.

Página 4

Servlet Class

Este programa ilustra o listener HttpSessionAttributeListener.

O Servlet_Class será criado primeiro.

O servlet mostra como um atributo é adicionado à sessão.

req.getSession().setAttribute("abc","2");

Posteriormente o atributo criado é impresso na saída e o respectivo atributo criado será removido:

req.getSession().removeAttribute("abc");

Página 5

Listener Class

Quando o atributo "abc" é adicionado à sessão, o Listener HttpSessionAttributeListener é acionado e o código do método attributeAdded() será executado.

Similarmente quando o atributo "abc" for removido da sessão, o Listener HttpSessionAttributeListener será disparado novamente e o código do método attributeRemoved() será executado.

Página 6

The Deployment Descriptor

O descritor de implantação correspondente, onde se define a classe do servlet < servlet-class > e se faz o mapeamento do servlet através de < servlet-mapping > e se define os listeners da aplicação através de < listener-class >

Nesse caso, as mensagens "Attribute Added" e "Attribute Removed" definidas na classe listener serão impressas na janela de saída e não como resposta ao usuário, conforme programado em MySessionAttributeListener.

Página 7

Migração de Sessão

Em um ambiente distribuído, uma aplicação web será duplicada através de múltiplas máquinas virtuais (VMs).

Nessas situações, o ServletContext será duplicado e o ServletConfig também será duplicado através das VMs, no entanto o objeto HttpSession é movido de uma VM a outra quando houver uma requisição.

Página 8

Migração de Sessão (2)

Por exemplo, caso uma requisição venha de um servlet, então o container pode enviar a requisição para a máquina virtual VM1 com um session id particular.

Caso uma outra requisição do mesmo cliente seja direcionada ao mesmo servlet, então o container pode enviar a requisição para a VM2.

De modo a continuar a conversação, o container precisa ver se o objeto session ainda se encontra na VM1, então decide "to passivate" ou retirar o controle do session da VM1 e "to activate", ativar passando o controle do objeto session para a VM2.

Mas uma vez que o container percebe que a sessão ainda se encontra na VM1, decide to "passivate" ou "retirar o controle" do objeto session da VM1 e to "activate", ativar o controle do objeto session na VM2.

Em outras palavras:

Há um ServletContext por VM.

Há um ServletConfig por servlet por VM.

Mas há apenas um objeto HttpSession por "web app".

Página 9

Como funciona a migração de sessão

Página 10

Atributos de sessão

Quando uma sessão é movida, seus atributos devem também serem movidos.

Se os atributos forem objetos "Serializable", não haverá problema.

Por outro lado, se os atributos não forem serializáveis, será necessário fazer com que a classe do atributo em questão implemente o listener HttpSessionActivationListener.

O listener HttpSessionActivationListener possui dois métodos: sessionDidActivate (HttpSessionEvent se) e sessionWillPassivate(HttpSessionEvent se) .

O descritor de implantação será configurado apropriadamente e o servlet também deverá ser criado de acordo com os requisitos.

Página 11

Conclusão

Estudamos sobre:

Um programa o qual ilustra o HttpSessionAttributeListener.

Migração de sessão.