"Em ambiente de desenvolvimento minha aplicação funciona que é uma beleza, mas quando em produção, experimento alguns problemas relacionados a utilização do banco de dados. Algumas transações não fecham corretamente, retornando-me exceções de timeout e coisas do tipo."
Se você utiliza Hibernate e já passou por algo semelhante, pode ter sido vítima do seu gerenciador de pool de conexões.
O Hibernate é, de longe, o framework MOR (Mapeamento Objeto Relacional) mais utilizado no mercado, pois implementa as especificações JPA e mais alguma coisa. Parece-me até que o JPA é feito baseado no Hibernate e não o contrário. Também pudera, seu idealizador Gavin King, é dos maiores colaboradores das JSRs que consolidam detalhes das especificações EJB 3.0, JPA e JDO. E muitos irão concordar comigo, trata-se de umas das melhores ferramentas a disposição dos javeiros de plantão, fala sério.
Ocorre é que com tantos recursos a disposição, realizar o fine tunning do Hibernate não é um trabalho tão trivial.
Dentre todas as opções configuráveis para melhoria de performance, segurança e escalonamento, tais como cache de segundo nível, configurações de mapeamentos e locks, destaco neste post o pool de conexões.
Sabemos que há muito, os bancos de dados relacionais utilizam-se de tal recurso para acelerar o atendimento a requisições de conexões em ambientes de concorrência. Trata-se de iniciar o serviço com algumas conexões já criadas, e em ir atendendo as requisições com estas conexões, variando entre limites mínimos e máximos em relação a quantidade de conexões criadas. A este conjunto de conexões automaticamente criadas pelo serviço de banco de dados, chamamos pool de conexões.
O Hibernate também trabalha assim. Em linhas gerais, ao ser inicializado, ele pega um número de conexões com o banco de dados e utiliza estas conexões para atender as requisições de suas sessões. O problema é que o gerenciador de pool de conexões do Hibernate não é otimizado o suficiente para uso em produção, apresentando uma série de problemas como referências a conexões encerradas e performance. Isto é dito na própria documentação do Hibernate, que pode ser verificado na página 8 da referência da versão 3.5.6 final, a que utilizei para estudar a questão.
Se você não implementar um dos gerenciadores de pool de conexão de terceiros, suportados pelo Hibernate, nas saídas de console ao iniciar sua aplicação, desde que seu mecanismo de logger esteja configurado para os warnings do Hibernate, poderá ver alguma recomendação sobre o tema, além de experimentar alguns problemas como o relatado na abertura deste post.
Para solucionar a questão, basta implementar um gerenciador de pool de conexão de terceiros suportado pelo Hibernate. O mais utilizado é o c3p0 e para configurá-lo basta incluir o seu .jar no classpath da aplicação e configurar seus parâmetros no seu arquivo de configuração do hibernate. Para quem utiliza o hibernate.cfg.xml, basta incluir neste arquivo as seguintes linhas:
<property name="hibernate.c3p0.min_size">3</property>
<property name="hibernate.c3p0.max_size">10</property>
<property name="hibernate.c3p0.timeout">90</property>
<property name="hibernate.c3p0.idle_test_period">120</property>
No trecho acima, configuramos, respectivamente, o número mínimo de conexões no pool, o número máximo de conexões no pool, o tempo, em segundos, em que cada conexão irá expirar se não houver atividade e de quanto em quanto tempo, em segundos, a vida das conexões no pool deverá ser testada.
Em versões mais recentes do Hibernate, também pode ser necessário informar quem fará a gerência do pool de conexões com a seguinte linha no mesmo arquivo hibernate.cfg.xml, complementando as configurações já comentadas:
<property name="hibernate.connection.provider_class"> org.hibernate.connection.c3p0ConnectionProvider
</property>
Existem outros parâmetros configuráveis do c3p0.
Para decidir que parâmetros configurar e com que valores, é necessário um estudo dos requisitos não funcionais da aplicação e a realização de testes em busca da melhor configuração para o cenário pretendido.
Veja um exemplo com base nas configurações anteriormente citadas (hibernate.c3p0.max_size = 10): Para descobrir o número máximo de transações para o seu cenário, basta que você conheça o tempo de sua transação mais demorada. Imaginemos que a transação mais demorada para o seu caso seja de 2 segundos. Significa dizer que se você tiver 10 acessos concorrentes, o 11o. visitante a requisitar uma conexão, na pior das hipóteses, teria que esperar 2 segundos. Em outras palavras seria possível, no pior cenário, atender 5 requisições transações simultâneas por segundo, 300 por minuto e 18000 por hora . Portanto, cuidado com os números que vai escolher!
ATENÇÃO: Não se esqueça de compatibilizar os números de conexões no pool do c3p0 com os números de conexões no pool do banco de dados que você utiliza. Não adianta muito configurar o c3p0 para o máximo de 30 conexões no pool se o seu banco está configurado para um máximo de 5 conexões no pool.
Existem também outros gerenciadores de pool para o Hibernate como o proxool e o dbcp pool da Apache.
Espero que este post possa servir de ajuda assim como estas informações também me foram úteis um dia.
Para referência:
http://docs.jboss.org/hibernate/core/3.5/reference/pt-BR/pdf/hibernate_reference.pdf
http://blog.caelum.com.br/2010/04/14/as-dependencias-do-hibernate-3-5/
http://blog.caelum.com.br/2008/09/02/vazamento-de-memoria-e-de-conexoes/
Comente, critique e participe. De antemão já te agradeço.
