O primeiro desafio de um iniciante em Hibernate, antes mesmo de fazer um tutorial prático, como o disponível na apostila FJ-21 da Caelum, é organizar as dependências necessárias. Até o Hibernate 3.3, a maneira a qual ele era distribuído dava trabalho pra quem precisasse usar a JPA: além do zip contendo o hibernate, era necessário fazer o download de um outro jar contendo a implementação do EntityManager e ainda outro contendo as anotações e interfaces da JPA.

A versão 3.5, como a 3.6, além de trazer uma implementação da JPA2, juntou todos esses pacotes em um só. A documentação está ainda mais completa, assim como a parte explicando o processo de setup do seu primeiro projeto. Apesar disso, como se pode ler na documentação, ela é feita assumindo que você esteja usando o maven. Muitos iniciantes em Java ainda tem dificuldades pra encarar o Maven, ou há ainda quem prefira usar o Ant, Ivy ou gerenciar as dependências manualmente. Quais dependências preciso então para rodar uma aplicação com Hibernate 3.5/3.6?

Para facilitar seu trabalho, deixamos aqui um zip com todas essas dependências do Hibernate 3.5.0, além de um arquivo de configuração para o Log4J, um hibernate.cfg.xml e jars opcionais.

Ou então você pode juntar esses jars seguindo o passo a passo: primeiramente precisa baixar a distribuição 3.5/3.6 a partir da página de downloads do hibernate no sourceforge. Ao descompactá-la, encontramos os seguintes arquivos e diretórios:

O hibernate3.jar é um jar contendo as classes fundamentais do Hibernate. Agora, dentro de lib, temos o diretório required, que são dependências que sempre precisaremos utilizar junto com o Hibernate. Todas essas 6 dependências são necessárias:

Dentro de lib, ainda precisamos do jar hibernate-jpa-2.0-api-1.0.0.Final.jar que está na pasta jpa para poder utilizar as anotações do Java EE. Caso você va usar o MySQL, também precisa fazer o download do driver JDBC para ele.

Ainda não terminou. Precisamos do nosso logging funcionando. Se você tentar executar algum exemplo agora, vai receber o conhecido Exception in thread “main” java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder. O SL4J, usado pelo Hibernate, é uma casca para as outras ferramentas de logging, e precisa então de um jar que indique qual logger será utilizado como backend. Na página de distribuições do SL4J você deve baixar a versão correspondente que está usando, seria a 1.5.8 no caso do Hibernate 3.5.0, e pegar o adaptador slf4j-log4j12-1.5.8.jar. Para o Hibernate 3.6.2, é necessário o slf4j-log4j12-1.6.1.jar. Também precisamos do jar do Log4J 1.2.x.

Principais dependências opcionais

Usar o Hibernate facilita muito o desenvolvimento com banco de dados, porém para uma performance e escalabilidade adequada é necessário ficar atento em alguns pontos fundamentais, e também simples, para que ele não se torne um gargalo na sua aplicação. Dentro do diretório optional, destaco como essenciais o c3p0 para pool de conexão e o ehcache para second level cache. O ehcache necessitará do commons-logging por sua vez.

Para você tirar todo o poder da JPA 2, vai querer também usar a api de meta modelos, e pra isso precisa do gerador de modelos do Hibernate.

Passamos então a usar um pool de conexões, e ao colocar o sistema em produção, nos deparamos com outro problema: o broken pipe:

java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2690)
...

No GUJ, são mais de 100 mensagens a respeito de broken pipes! Recentemente Tomaz Lavieri abriu um detalhado tópico sobre esse mesmo assunto, que me incentivou a escrever esse post, dada sua relevância.

Por que essa exception acontece? São dois motivos principais:

O primeiro é que muitos bancos de dados possuem um timeout para conexões inativas (o padrão do MySQL é de 8 horas, mas em alguns hosts isso pode estar configurado em segundos!). Depois de determinado tempo, o banco de dados mata essa conexão ociosa numa tentativa de economizar recursos, pois conclui que alguém simplesmente a esqueceu aberta. Quando, no lado do cliente, seu pool decide usá-la, a socket rapidamente percebe que a conexão foi fechada do outro lado, foi quebrada (daí o nome broken pipe). Muito comum ao começar a usar um pool!

O segundo motivo é que você pode estar tratando suas transações sem o devido cuidado: esquecendo de fazer o commit ou o rollback em alguns casos. O banco de dados então pode matar essa conexão depois de algum timeout de transação, porém o seu pool não sabe disso, e quando for utilizar essa conexão, ela está quebrada!

Solução rápida? Configurar o seu pool para testar se as conexões continuam válidas. No C3P0, pool de conexões que recomendamos fortemente, quando usado com o Hibernate, basta fazer no seu hibernate.cfg.xml:

<property name="hibernate.connection.provider_class">
  org.hibernate.connection.C3P0ConnectionProvider
</property>
<property name="hibernate.c3p0.min_size">1</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.timeout">30</property>
<property name="hibernate.c3p0.idle_test_period">100</property>

É a configuração hibernate.c3p0.idle_test_period que resolve o broken pipe. Nesse caso o C3P0 fara essa verificação de maneira assíncrona: ele cria threads (3 por padrão) que checam de tanto em tanto tempo (100 segundos nesse caso) se alguma das conexões do pool está inválida (broken pipe é um dos casos). Na existência de uma conexão assim, essa será eliminada do seu pool! Você ainda pode ter um azar muito grande, pois uma conexão pode ter algum problema logo depois que a thread a verificou! Se você quer ter uma confiabilidade de 100% em relação a suas conexões, você pode configurar a variável testConnectionOnCheckout no arquivo c3p0.properties que deve ser colocado no seu classpath. Isso não é muito recomendado, pois toda vez que uma conexão é pega do pool, alguma forma de ping será feito no banco de dados para saber se ela é válida, perdendo um pouco de performance.

Vale lembrar de que isso não é motivo para você se descuidar no tratamento de transações, centralizando isso dentro de um interceptador/filtro que faça o uso correto do try, catch e finally, precavendo-se de qualquer vazamento. Transações, assim como qualquer outro recurso caro (arquivos, conexões, sockets, threads, etc…), deve ter seu ciclo de vida tratado com atenção, de preferência de maneira isolada.

Caso você não use Hibernate, Jerônimo Mozer mostra como usar o C3P0 programaticamente.

Mais detalhes podem ser vistos nas configurações de teste de conexões do C3P0, detalhes do seu funcionamento com o Hibernate e a página do próprio Hibernate sobre esse pool, mas que se encontra um pouco defasada. Também vemos muitos detalhes como esses no nosso curso FJ-25.