Bom dia pessoal!
Onde trabalho foi desenvolvido um framework MVC próprio, até que ele funciona bem, porém estou tendo alguns problemas para gerenciar o EntityManager, vamos aos detalhes.
O framework trabalha parecido com o JSF no modo ViewScope, ou seja, ele possui uma classe que representa a tela e essa classe é instanciada quando abre a tela e removida quando a tela fecha. O problema é que todos os objetos ficam “vivos” e amarrados aos componentes visuais, se o entity manager fechar a cada requisição os objetos ficaram desatachados e será obrigado a usar o merge, e se usar o merge quebra o visual, pelo fato da tela estar apontando para objetos que não existem mais. Enfim minha dúvida é:
Deixar o entitymanger vivo durante toda a tela pode estourar a memória?
Estou abertos a dicas, criticas e sugestoes rss
vlw
[quote=mauricioadl]Deixar o entitymanger vivo durante toda a tela pode estourar a memória?[/quote]Sim.
Tem alguma idéia para resolver o problema?
Tem alguma idéia para resolver o problema?[/quote]1) entenda ciclo de vida de uma entity
2) adote algum tipo de estratégia para controle de transação:
a) open session in view
b) na mão
c) algum factory cdi
d) spring ou algum outro framework de injeção
O que é você quer já é implementado por meio de “CONVERSATION”. Isso existe no JBoss Seam, CDI, e já vi gente que criou um escopo personalizado no Spring para obter o mesmo resultado. Usando escopo de “CONVERSATION” o seu contexto persistente (entity manager) vai ficar aberto por vários cilos de requisição/resposta.
Então assim, eu não diria que é uma má prática porque inclusive já existe bastante gente por ai usando isso há anos. Agora com certeza esse tipo de estratégia, como tudo na vida, tem seus contras. Muitas vezes ficar gerenciando várias entidades vinculadas a um contexto persistente (attached) pode trazer problemas de updates acidentais por exemplo. Existem peculiaridades que você só vai se dar conta mesmo depois que começar a utilizar. Mas acho uma estratégia interessante que compensa em muitos casos. O overhead de memória claro que é maior, mas as conversations normalmente são definidas com timeout pequeno para minimizar esse custo.
O que recomendaria era você não implementar a sua própria solução e sim tentar usar uma dessas que já existe. Principalmente usando JBoss Seam ou CDI.
Bem que eu queria usar jboss ou qualquer coisa do tipo, mas como disse tem um framework proprio aqui q complica tudo as coisas.
Vou ler sobre esse “CONVERSATION” parece ser oq eu preciso.
[]'s
Tem tanto framework MVC por ai. Implementar o próprio realmente é complicado 
Abraços!
[quote=rodrigo.uchoa]Tem tanto framework MVC por ai. Implementar o próprio realmente é complicado
Abraços![/quote]
Concordo! mas se eu ficar pensando muito nisso eu peço a conta. 
Então acho que pra você não seria viável implementar esse esquema de conversation não. Ou consiga usar os que já existem, Spring, JBoss Seam, CDI… Ou abandone a idéia e continue fazendo seus entityManager.merge()
