Venho aqui hoje não para levantar polemica, mas para discutirmos uma questao muito importante. Sempre desenvolvi utilizando hibernate na empresa em q trabalho e em meus projetos pessoais, agora estamos passando tudo para JPA. Depois de muitos e muitos testes obtive “surpreendentemente” os seguintes resultado.
O Hibernate possui muito mais maturidade em sua linguagem de consulta o TopLink é mais limitado;
O Hibernate possui várias jar, já o TopLink apenas um;
O TopLink demonstrou mais rapidez que o Hibernate;
O As mensagens do TopLink são mais completas que a do Hibernate;
***5) O TopLink recupera um objeto marcado como LAZY mesmo q este objeto esteja marcado como DETACHED já o Hibernate temos q tratar isso manualmente, o que eh muito trabalhoso;
O TopLink eh uma implementação feita do zero já o hibernate pelo q parece eh uma adaptação da api antiga para a JPA;
Aqui estao alguns dos principais pontos que está fazendo escolhermos o TopLink ao inves do Hibernate. Acho q a maioria prefere o Hibernate pois eh uma camada mais antiga e com isso possui mais adeptos, já o TopLink eh mais novo mas pelo q vi está mais “certinho” que o seu concorrente.
Gostaria de saber a opnião e experiência dos amigos em relação a este assunto .
Gostaria que você me respondesse as seguintes questões para me localizar-me:
O TopLink tem código aberto para futuras alterações?
As aplicações feitas com o TopLink está funcionando 100% no Jboss?
Eu particularmente já utilizei o Hibernate em varios projetos e nunca tive problema algum (infelizmente no atual não estou trabalhando com ele, ainda!!!)
Nunca usei o Toplink, então não posso falar nada sobre ele, porém só pelo fato do EJB3 ter usado características do hibernate faz com que ele seja confiável e como você mesmo destacou, ele já está maduro um bom tempo.
[quote]Gostaria que você me respondesse as seguintes questões para me localizar-me:
O TopLink tem código aberto para futuras alterações?
As aplicações feitas com o TopLink está funcionando 100% no Jboss?
[quote]Eu particularmente já utilizei o Hibernate em varios projetos e nunca tive problema algum (infelizmente no atual não estou trabalhando com ele, ainda!!!)
Nunca usei o Toplink, então não posso falar nada sobre ele, porém só pelo fato do EJB3 ter usado características do hibernate faz com que ele seja confiável e como você mesmo destacou, ele já está maduro um bom tempo.[/quote]
Pois eh o problema que mais me atrapalhou em usar o hibernate e mais me motivou a utilizar o TopLink foi o fato do LAZY em objetos DETACHED, no hibernate dá muito trabalho se vc quiser fazer de forma transparente terá q sujar o pojo, já no toplink isso eh automático. Nào entendo como o hibernate nao solucionou isso ainda!!!
Nem nunca vai implementar, essa foi uma das escolhas do pessoal do Hibernate e no longo prazo foi uma das escolhas mais acertadas que eles fizeram na definição do comportamento do framework. Liberar o lazy-load de objetos depois que a sessão deles foi fechada não faz sentido algum, porque se a sessão foi fechada tudo o que seria necessário para executar o processo já deve ter sido carregado. Se não foi, é erro de programação de quem implementou o código.
Querer que objetos que não estão mais relacionados a uma sessão abram uma nova sessão para carregar dados que eram lazy-load é tão bizonho quando esperar que o seu ResultSet se reconecte no banco de dados depois que você mandou fechar ele ou que um Socket que foi fechado pelo cliente fique tentando se reconectar sem lançar uma exceção só porque você quer escrever alguma coisa nele. A maior parte dos problemas com lazy-load do Hibernate acontece porque ele está sendo utilizado de forma incorreta por alguém que não entende o funcionamento do mecanismo de persistência.
Nao faz sentido algum a oracle fazer isso, e me parce que isso nao é JPA compliant, correto?
Outra coisa, isso pode derrubar um servidor! Imagine um monte de getters lazy sendo disparados por um jsp, cada um abrindo um novo manager a ser aberto/pooled? Semelhante a qauntidade enorme de roundtripe que um entity bean 2.x fazia quando usado remotamente!!!
Obviamente algumas estrategias mais inteligentes podem ser usadas… mas mesmo assim.
Imagine a seguinte situacao vc tem cliente que se relaciona com endereco. O usuário precisa fazer uma consulta aos dados do cliente(sem considerar seu endereco), meu procedimento hj eh o seguinte busco o obj cliente e fecho a sessao, se o usuário clicar no botao endereco busco o endereco do cliente atraves do lazy mas a sessao estará fechada, portanto terei q abri-la outra vez certo? esse procedimento o TopLink faz automaticamente. se estou errado como eh q vc faz? deixa a sessão aberta o tempo todo, isso nao pode ser pessimo para a aplicacao tendo em vista q a sessao mantem uma conexao com o banco?
A sessão de quem mantém uma conexão com o banco de dados? A do TopLink?
A sessão do Hibernate só pede uma conexão com banco e dados ao DataSource quando ela é estritamente necessária (para executar uma busca, por exemplo) e ele devolve a conexão para o pool assim que tiver terminado o que tinha que fazer, você pode ter mil sessões abertas e nenhuma conexão com o banco e dados.
E nesse seu caso, vai depender muito da lógica de negócio, se o usuário realmente for ficar disponível em algum contexto, manter a sessão aberta é uma boa idéia, se ele não vai ficar, pode-se muito bem fazer uma outra busca no banco para trazer apenas o endereço.
Sempre ouvi dizer q não era bom ter uma sessao aberta nao era legal até mesmo para o hibernate, o ideal era sempre fecha-la uma dos motivos era justamente essa conexao com o banco … Seria mentira isto? se sim entao nao há motivo pra fechar a sessao do hibernate em momento algum …
Bem rapidamente: o hibernate mantém um cache de objetos na session. Se voce estiver na mesma session e der session.load(Entidade.class, 7L) duas vezes, ele só fara o select uma vez.
Logico que voce pode remover coisas do cache e tal, mas como a sessao foi feita pra ter vida curta (uma por “unit of work”, como dizem), é só fechar que o cache vai embora.
TopLink para rodar no servidor Jboss tem que pagar um licença. Ele é free somente se for utilizado no servidor de aplicação Ias da Oracle, me corrige se eu estou errado.
Claro que há. Uma session é um objeto que não é thread safe, então você não deve acessar ele de várias threads diferentes e ele também só pode conter uma única transação por vez, então, se você tiver mais do que uma transação executando ao mesmo tempo, vai ter que ter outra sessão pra fazer o trabalho.