Hibernate no Java SE x Java EE

O Hibernate pode ser utilizado tanto em aplicações Java SE, por exemplo apli- cações desktop cliente/servidor utilizando Swing; quanto em aplicações Java EE, não importa se usam ou não EJB, ou qual o framework Web adotado.

Para o programador, a grande maioria do código é exatamente o mesmo em qualquer ambientes, o que leva muitos a cometerem o erro de aprenderem apenas a configurar o Hibernate para o ambiente Java SE, deployando assim aplicações que serão ineficientes e pouco escaláveis em ambiente de servidor de aplicações.

Uma aplicação Hibernate inclui configurações específicas para o próprio framework, que podem ser fornecidas programaticamente, por arquivos de propriedades ou, na opção mais popular, por um arquivo XML chamado hi- bernate.cfg.xml. A Listagem 5.1 apresenta um trecho deste arquivo em uma aplicação típica:

Listagem 5.1 – Configuração do Hibernate para uma aplicação Java SE 13 <hibernate-configuration> 14 15 <session-factory> 16 <property name="connection.driver">org.postgresql.Driver</property> 17 <property name="connection.url"> 18 jdbc:postgresql://127.0.0.1/tarefas 19 </property> 20 <property name="connection.user">jboss</property> 21 <property name="connection.password">jboss</property> 22 <property name="transaction.factory_class"> 23 org.hibernate.transaction.JDBCTransactionFactory 24 </property> 25 <property name="connection.pool_size">10</property> 26 <property name="dialect">org.hibernate.dialect.PostgreSQLDialect 27 </property> 28 <property name="show_sql">false</property>

O aluno atento irá logo perceber que as configurações de conexão ao banco de dados estão embutidos na configuração do Hibernate, de modo que em um ambiente Java EE estaríamos violando um princípio básico da plataforma: o de que é o servidor de aplicações quem deve gerenciar recursos externos, como conexões a um banco de dados.

Alguns alegam que o Hibernate incluir seu próprio pool de conexões, configu- rável em termos de máximos e mínimos, entre outras coisas. Então o uso do pool de conexões gerenciado pelo servidor de aplicações seria dispensável. Este argumento falha em dois pontos:

1. O administrador estaria abrindo mão das facilidades gerência deste pool, pois usando o pool gerenciado pelo Hibernate ele não teria visibilidade sobre a utilização das conexões, nem informações de depuração para lidar com eventuais leaks;

2. Usando o pool gerenciado pelo Hibernate, o administrador aprender a lidar com a configuração e tuning de pelo menos duas implementações de pool de conexões: a do servidor de aplicações, para aplicações que não usem Hibernate, além de uma das opções inclusas no próprio Hibernate. Estas configurações podem se tornar não-triviais quando ocorrem problemas de integração com firewall e clusters de banco de dados. Então seria mais produtivo o administrador se concetrar em ter um bom domínio das configurações do servidor, e que todas as aplicações fizessem uso delas.

utra questão a ser observada na configuração do Hibernate é a integração com o gerenciador de transações JTA do servidor de aplicações. Caso contrário, aplicações Hibernate não irão participar de transações distribuí- das, mesmo que seja utilizado um Datasource gerenciado pelo servidor de aplica- ções.

O

A integração entre o Hibernate e o JTA pode ser feita tanto em CMT (Contain-

er-Managed Transactions) quando em BMT (Bem-Managed Transactions). Es-

pecialmente quando o Hibernate for utilizado em conjunto com EJBs, reco- menda-se o uso do CMT. Sem o CMT, o desenvolvedor é responsável por deli- mitar o início e fim das unidades lógicas de trabalho, o que complica em muito o código e limita as possibilidades de reaproveitamento e integração entre aplicações15_.

A Listagem 5.2 apresenta um exemplo de como seria a configuração reco- mendada para uso em um servidor de aplicações JBoss AS:

Listagem 5.2 – Configuração do Hibernate para uma aplicação Java EE 1 <hibernate-configuration> 2 3 <session-factory> 4 <property name="connection.datasource"> 5 java:/comp/env/jdbc/Tarefas 6 </property> 7 <property name="transaction.factory_class"> 8 org.hibernate.transaction.CMTTransactionFactory

15 O CMT é tão importante para o desenvolvimento que aqueles que não gostam de usar EJB acabam optando pelo Spring principalmente para usar seus recursos de gerenciamento automático de transações.

5.3. Hibernate no Java SE x Java EE 9 </property> 10 <property name="hibernate.transaction.manager_lookup_class"> 11 org.hibernate.transaction.JBossTransactionManagerLookup 12 </property> 13 <property name="dialect"> 14 org.hibernate.dialect.PostgreSQLDialect 15 </property> 16 <property name="show_sql">false</property> Observe que na configuração recomendada:

• O Hibernate utiliza um DataSource JCA;

• É é utilizada a gerência de transações do servidor de aplicações em vez

de diretamente a do banco de dados subjacente.

• Dentro das melhores práticas do Java EE, estamos utilizando uma refe-

rência local ao DataSource (java:comp/env).

Outra observação importante é que, embora a configuração do Hibernate não contenha mais parâmetros de conexão banco de dados utilizado, ele ainda ne- cessita saber qual o produto utilizado. Sem esta informação o Hibernate não será capaz de gerar código SQL otimizado, ou poderá até gerar comandos não reconhecidos pelo banco de dados16_.

A configuração Java EE do Hibernate deve ser modificada de acordo com o servidor de aplicações utilizado, pois o Hibernate necessita se comunicar com o gerenciador de transações de maneiras não previstas pelo Java EE. Então o administrador do JBoss AS deve estar preparado para inspecionar a configura- ção do Hibernate e verificar se está correta e se é a mais eficiente possível.

arquivo de configuração do Hibernate (hibernate.cfg.xml) normalmente é acessado como um recurso do classpath – na verdade deveria sempre ser acessado desta forma em ambiente Java EE – então ele estará junto aos bytecodes da aplicação, na raiz de um pacote EJB-JAR ou dentro de WEB- INF/classes em um pacote WAR, em vez de estar ao lado dos descritores de de- ployment dos pacotes WAR ou EJB-JAR. Na verdade ele poderia ser colocado na raiz de qualquer pacote JAR da aplicação, mas recomendamos apenas as duas al- ternativas citadas para facilitar sua localização e customização pelo administra- dor.

O

16 Apesar de todos os bancos de dados populares se declararem aderentes ao padrão SQL ANSI, a maioria deles emprega tipos de dados customizados, sintaxes diferentes para campos auto-incrementados, outer joins concatenação de strings, formatos de data/hora e vários outros “detalhes” utilizados por virtualmente qualquer aplicação.