Estou fazendo alguns testes com J2EE (Glassfish) e percebi o seguinte:
Estou utilizando um managed bean com escopo de sessão e pelo que pude perceber o Glassfish não está destruindo o objeto depois que a sessão é encerrada ( invalidate() ).
Fiz o teste um println() no constructor e no método finalize() do bean:
public IndiceMB() {
System.out.println("*** CRIOU MB");
}
....
@Override
public void finalize() {
System.out.println("***** DESTRUIU MB");
}
O constructor é chamado normalmente quando o mb é criado, porém o finalize não é chamado nunca, nem muito tempo depois da sessão ter sido invalidada.
A questão é: Existe alguma configuração a ser feita para que o Glassfish libere estes objetos da memória? Ou isso têm de ser feito manualmente pelo programador?
Olá TiagoW,
ainda não consegui identificar a solução, mas tenho uma informação a mais do que vc passou, talvez seja útil.
Fazendo uns testes percebi que o servidor de aplicação só chama o finalize do bean de sessão após decorrido o tempo do timeout (configurado no web.xml).
estou tentando achar uma ligação entre o invalidate e o timeout…
Primeiramente obrigado pelo interesse…
Descobri agora, que o objeto é destruído, porém apenas 1 hora depois da sessão ter sido encerrada.
Eu imagino que o invalidate não exclui realmente a sessão, então esse prazo de 1 hora seria um timeout para limpar os dados da sessão.
Provavelmente isso deve ter alguma configuração no glassfish para reduzir este tempo, mas de qualquer forma a solução ideal seria mesmo limpar todos os objetos vinculados a sessão assim que ela é invalidada a fim de otimizar o consumo de memória.
Bem, vou continuar pesquisando aqui. Mais uma vez obrigado.
Desculpa postar nessa thread antiga, mas é que estou tendo o mesmo problema. Quando invalido a sessão os managedBeans que estão em escopo de sessão continuam na mamória. Você conseguiu resolver isso?!
Ainda não descobri uma forma de forçar os objetos da sessão a sairem da memória quando a sessão é invalidada.
Teoricamente, estes objetos só são finalizados e retirados realmente da memória quando ocorre um GarbageCollector, o que é imprevisível.