Open Session In View Vrs o que deveria ser feito na teoria

Bom dia pessoal do GuJ!

Tenho aqui uma dúvida que tem me deixado meio cabreeero…
Na minha empresa temos um produto Web onde as conexões (utilizando Hibernate) sao feitas de uma maneira meio braçal usando o método openSession()
Como assim? em CADA método das DAOs ele faz um getSession(), e no final do método ele fecha a transação. Só que eu nao fiquei contente com isso por que imagine se na camada de negócio ele precisa acessar dois métodos de alguma DAO?! então ele faria dois getSession() pra depois fechar manualmente!!

Fui pesquisar sobre boas maneiras de gerenciar a sessão do Hibernate e lembrei que no meu trabalho anterior usávamos o Open Session In View, porém, quando eu fiz meu primeiro cursinho em Java o professor falou “quanto menos tempo a conexão ficar aberta, melhor!”, acontece que o Open Session In View abre a conexão na View e Só fecha após todos os trabalhos no lado do servidor, isso inclui trabalhos que não necessitariam mais de uma conexão alocada para o cliente, ficando assim conexão aberta quando não deveria! (? é aqui a minha dúvida, a conexão fica realmente alocada?? )

O que vocês acham? é realmente assim que funciona? Pelo que li sobre o método openSession() ele abre uma nova conexão cada vez que esse método é chamado, quando a DAO faz um getSession(), na verdade, de modo encapsulado, é executado um openSession().

O meu questionamento é válido? :roll: eu queria abrir sessão no banco sem ter que em cada inicio e fim de método de cada DAO ter que ficar pedindo e fechando manualmente.

vlw

Bom dia!

Vamos lá…

Realmente para aplicações não é muito saudável deixar a conexão aberta por muito tempo.

Também não é muito adequado a cada acesso ao DAO abrir uma conexão…

O que podemos fazer então?

Podemos ter um método getSession que pega uma sessão nova apenas caso não exista uma conexão vinculada na sessão. Dessa forma fugimos do open session in view e evitamos que uma nova conexão seja aberta toda hora.

O commit ainda fica na camada de visão, mas a abertura fica no DAO, diminuindo o tempo de conexão aberta. Caso chame dois DAO’s como o getSession faz o papel de um singleton de request, ele não vai abrir duas conexões.

Espero ter ajudado.

Att,

É uma boa solução o Open Session in View (ou Transacion View).

Você tem que ter certeza de sempre fechar suas conexões ao finalizar o processamento da página do usuário (geralmente acontece em um filtro).

Existem algumas soluções, mas caso você não utilize CMT realmente o controle na unha será necessário.

[quote=thiagomont]
O que podemos fazer então?

Podemos ter um método getSession que pega uma sessão nova apenas caso não exista uma conexão vinculada na sessão.[/quote]

Nesse caso, eu usaria então o método getCurrentSession(), correto??? Seria essa sugestão?

Uma coisa que costumava fazer antes de aprender o Open Session In View era na instanciação de cada DAO eu pedir dentro do método construtor (da DAO) uma conexão e atrelar essa conexão a uma variável private da DAO.
Assim todos os métodos usaria a conexão dessa variável, o maior problema seria que ao sair da DAO a conexão ficaria aberta, jogando a responsabilidade para a camada superior de fechar a conexão…

[quote=jakefrog ]
geralmente acontece em um filtro [/quote]
Sim, fazia isso em um filtro , mas como o produto já usa filtro do Struts eu não quero me arriscar em colocar mais um filtro na aplicação e assim criar problemas para mim.

obrigado aos dois!!

Não tenho muito conhecimento em aspectos, mas poderia ser uma alternativa para o controle mais automatizado também.

A melhor forma de definir o que vc precisa para o controle transacional é ver o tamanho da sua aplicação e o custo da estrutura transacional que você tem hoje. Se esse custo for relativamente baixo e sua aplicação tiver poucos usuários o open session in view pode já resolver.

Outros controles transacionais mais apurados aumentam complexidade da solução e como você deve saber o aumento de complexidade deve ter um ganho real para aplicação para valer a pena.

Se quiser melhorar o controle transacional mesmo assim apresente um diagrama de sequencia resumindo a estrutura do projeto com a conversação entre as camadas. Para mim isso sempre ajudou a definir essas estruturas transacionais.

Espero ter ajudado.