Estava olhando alguns exemplos de DAO com Hibernate utilizando ThreadLocal e percebi que o getSession fica dentro dos métodos do DAO, mas o fechamento da sessão não.
Qual o local mais apropriado para fechar a sessão?
Vc deve iniciar e terminar a sessão de acordo com o ciclo de vida da sua aplicação.
Se for uma aplicação web pode ser dentro de um filter, por exemplo.
[quote=“Lorchaos”]Estava olhando alguns exemplos de DAO com Hibernate utilizando ThreadLocal e percebi que o getSession fica dentro dos métodos do DAO, mas o fechamento da sessão não.
Qual o local mais apropriado para fechar a sessão?[/quote]
exatamente, assim todos os DAO’s utilizam a mesma session.
vc só fecha a session no fim da transação, pode ser um filter como o louds falou…
no struts eu sempre tenho uma Action mãe que inicia a transação, chama um método abstrato que as subclasses precisam implementar, entao depois que a subclasse terminar de executar eu fecho a transação. E o pattern te garante que a mesma session foi utilizada.
no webwork pode ser usado um interceptor para isso.
Vale lembrar que Session é um objeto bem leve a partir da versão 2.0 do hibernate. Então o custo de criá-la todo request não é muito grande.
Voce também pode manter ela dentro da http session do teu usuario e desconectá-la no final de cada request para simular transações longas e reaproveitar o cache.
Fala, Louds. Eu fiz um profiling aqui num sistema nosso, e a primeira Session que vc pede pra SessionFactory demora, depois vem rápido. Mas reconnect()/disconnect() ainda é uma ordem de grandeza mais rápido.
Ainda tem duas outras vantagens de reaproveitar Sessions:
-
vc reutiliza o Session cache, a ponto de fazer quase que um “cache-per-user”.
-
de 1. vem que vc segura o uso de memória pra baixo, sem prejudicar as conexões com o banco.
O lado ruim é que vc introduz novos estados (Session aberta e disconectada), novos erros (disconnect() lança HibernateException - o que fazer?), e aumenta portanto a complexidade do programa, e com isso a probabilidade dele ter bugs.
[]s!