Tenho enfrentado alguns problemas de memory leak em aplicações legadas… e após investigação, constatei que era devido o armazenamento de objetos no httpsession.
Devido a persistência de sessão do tomcat, caso de objetos não limpos da sessão, estavam gerando memory leak, que como consequência dava problema de redeploy e tudo terminava num stop/start do tomcat para voltar a funcionar perfeitamente bem.
Infelizmente tem pessoas que acham um stop/start normal (não é o meu caso)…
Então veio a duvida. Se usamos objetos na sessão, devemos limpar. Mas isto é uma boa prática ? Ou o melhor seria nunca usar objetos no httpsession ?
Também veio a duvida, se formos armazenar objetos no httpsession, o melhor lugar para limpar é no contextDestroyed de um servletContextListener ? Ou em que momento ?
Usou o recurso e não precisa mais dele? Descarta.
Depende do que você precisa fazer, do escopo da tua aplicação e de como você quer que ela funcione.
Mas, creio que o problema seja maior que apenas objetos na sessão…
[quote=drsmachado]Usou o recurso e não precisa mais dele? Descarta.
Depende do que você precisa fazer, do escopo da tua aplicação e de como você quer que ela funcione.
Mas, creio que o problema seja maior que apenas objetos na sessão…[/quote]
Há armazenamento de algumas coisas na sessão após autenticação do usuário… como permissões de acesso por exemplo!
A limpeza da sessão resolveu o problema, entretanto levantou a duvida de onde é mais correto mexer. Se é sempre invalidar as sessões no contextDestroyed, ou fazer isso na unha pelo tomcat, ou ainda não usar objetos na sessão.
Não acredito que seja má prática usar objetos na sessão… somente não podemos esquecer de limpa-los, seja na unha ou pelo contextDestroyed, mas gostaria da opnião de outras pessoas.
Como disse, o que define isto é a arquitetura e as necessidades do projeto.
Imagine ter que colocar todos os dados em campos hidden nas páginas, como acontece com o projeto em que trabalho (claro, dados do usuário não)?
[quote=drsmachado]Como disse, o que define isto é a arquitetura e as necessidades do projeto.
Imagine ter que colocar todos os dados em campos hidden nas páginas, como acontece com o projeto em que trabalho (claro, dados do usuário não)?[/quote]
Ah sim… com certeza… tem casos que pode-se deixar a sessão de lado… tem casos que uma simples string na sessão resolve, mas tem casos que é melhor guardar objetos mesmo! Isso claro que depende… e por esse motivo acho que guardar objetos na sessão não é uma má prática, desde que se destrua eles de alguma forma depois… se isso depende também… ok! mesmo assim gostaria de mais opniões a respeito, principalmente de como é melhor lidar com essa destruição de objetos!
Realmente isso é uma coisa que o pessoal costuma abusar demais.
Tem alguns projetos em que todos os dados que se utiliza (resultado de consultas) são colocados na Sessão, mesmo que seja só para mostrar nessa tela mesmo.
Outros usam a sessão como um serviço de cache para evitar acesso ao banco de dados, e aí cada usuário logado tem em sua sessão uma cópia de algumas das tabelas de acesso mais frequente.
E por aí vai…
Na minha opinião, o que é válido colocar na Sessão:
-> Informações que efetivamente estão atreladas à Sessão de utilização. Isso significa: dados do usuário corrente e seus acessos.
-> Dados de transações que o usuário precisa ir avançando por várias telas para concluir. Nesse caso, ficar ligado na limpeza! Chame a limpeza da sessão em todos os pontos possível, no botão Ok, no Cancelar, nos cliques do menu…
-> Esse item aqui já não é tão correto, mas é um pecado que eu também cometo: usar lista na sessão para consultas paginadas. O ideal é fazer a consulta paginada de verdade, ou seja, tratar na consulta ao banco, só que os componentes de tabela (displaytag, datatable, etc) acabam obrigando a fornecer a lista inteira.
-> Só quando não tiver jeito mesmo: quando precisar fazer um Redirect e na volta mostrar uma determinada informação, pode usar a sessão para fazer aquele “ei, segura aí pra mim que eu já volto”. Limpe o dado da sessão assim que usá-lo no próximo request.
E veja que desses itens apenas o primeiro é realmente coisa para guardar na Sessão!
O segundo, o terceiro e o quarto são workarounds para simular escopos mais interessantes, como Conversation, View ou Flash. Em frameworks mais modernos alguns desses usos podem ser eliminados.
Agora só de curiosidade: esse cara escreveu um post sobre como eliminar completamente da sua vida a HTTPSession:
http://www.objectzilla.com.br/2010/06/05/o-uso-de-sessao-em-aplicacoes-web/
Eu sinceramente não consigo, e vocês ? 
