Quem programa em Java e nunca passou por esse problema? Você está desenvolvendo, tudo funciona perfeitamente, quando a aplicação vai para produção e os usuários começam a usar você percebe que o contador de conexões disponíveis no seu pool só diminui.

As razões para isso podem ser as mais variadas (sendo a maioria deles problemas da aplicação e não algo ligado ao data source, servidor de aplicação ou mesmo driver jdbc), mas as mais comuns são:

• ausência de chamada ao connection.close();
• falta de um tratamento de excessões, e conseqüentemente, o método close() não é chamado;

É importante saber, que sempre que você estiver lidando diretamente com Connection (o que não é algo muito aconselhável, sabendo que já existem diversos frameworks que abstraem/simplificam a utilização de jdbc), você deve fechar ela através do método close() e o mesmo deve estar dentro de um bloco finally{}, para que ele seja executado mesmo se ocorrer um problema durante a execução do seu código.

Mas e quando você já revisou “todo” seu código e mesmo assim as conexões continuam vazando? Você olha as conexões do seu pool e elas simplesmente parecem ir para o limbo. Aqui alguns já podem começar a se perguntar, “mas tem como eu monitorar as conexões do meu pool?”. E é aqui que entra um recurso não muito conhecido (e menos ainda, usado): Java Management Extensions ou simplesmente JMX.

Copiando o site da Sun:

JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks. By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future.

A maioria (se não todos) dos application servers já vem com recursos JMX prontos pra monitoramento e diagnóstico de connection leaks. Ativar o monitoramento do data source pode muitas vezes sacrificar um pouco da performance da aplicação (principalmente em um arquitetura Database-Centered), mas normalmente é um custo aceitável para descobrir os pontos de perda das conexões.

No JBoss, servidor de aplicação que eu utilizo no meu atual projeto, ligar o monitoramento é bem simples. Quando ativo, ele basicamente armazena o stack trace de todos os pontos onde temos chamadas à getConnection(), até que essa conexão sehja devolvida ao pool. Para ligar o monitoramento, altere o arquivo de configuração do seu data source(provavelmente um *-ds.xml) adicionando a linha abaixo
<local-tx-datasource>
.....
<track-statements>true</track-statements>
</local-tx-datasource>

Agora basta acessar o mbean CachedConnectionManager através da interface JMX do Jboss e invocar listInUseConnections() para ver o stack trace das conexões que não foram fechadas. Provavelmente vai ser algo semelhante à essa. Se você quizer apenas ver como anda seu pool, acesse o mbean ManagedConnectionPool, procurando principalmente pelos seguinte valores:

• AvailableConnectionCount – total de conexões disponíveis no pool
• InUseConnectionCount – total de conexões sendo usadas atualmente
• ConnectionCount – indica o total de conexões abertas atualmente no pool

Utilizando esses recursos e tendo um pouco de paciência, fica bem mais fácil achar os pontos de vazamento da aplicação.

Mais informações:

• Jboss DataSources
• Connection Leak Tracing – Sun Application Server
• Bea WebLogic – Profile Connection Leak
• IBM Web Sphere Aplication Server – Connection Leak Diagnostics
• The Joy of Finding Connection Leaks

Uns meses atrás tive um problema com o uso do Hibernate, em um caso um tanto quanto incomum: o projeto usava Ingres, um banco de dados muito pouco usado, e com algumas particularidades idiotas (sendo gentíl com eles). O tipo responsável por armazenar as datas no Ingres, diferentemente de todos os outros bancos que já vi, aceita três “estados” nas colunas de data: uma data (óbvio), null, ” – sim, uma empty string.

Com isto, eu não poderia usar as classes padrão para datas no Java, acabei criando uma classe Data para tratar desses estados. Como o tipo foi criado por mim, o Hibernate não oferece nada pronto (por razões óbvias), tive que achar uma alternativa.

Lendo um pouco a referência, mais especificamente o capítulo Custom value types, descobri que para esses casos especiais, onde muitos já apelariam para alguma forma menos ortodoxa, o Hibernate oferece um mecanismo muito poderoso : os UserTypes.

Um UserType é basicamente uma interface que permite a implementação de como um determinado tipo será recuperado e persistido no seu banco de dados. Este recurso é extremamente útil e me salvou graciosamente.

E porque estou escrevendo isso tudo? Recebi hoje uma dúvida bem interessante por mensagem privada no GUJ. O usuário perguntava se haveria possibilidade de usar Hibernate em conjunto com o banco PostGIS – focado em armazenar dados geométricos.

O principal desafio é como mapear os dados que são armazenados em Geometry, como são chamados os tipos geométricos no PostGIS. Como não existe nenhum tipo nativo do Java que seria correspondente (e nem a especificação do JDBC preve isso – tipos clob, lobs e variantes não contam!), o trabalho pode ser um pouco mais complicado que se imagina.

Dando uma pesquisada, acabei encontrado uma thread da lista de users do PostGIS que trata exatamente disso. Nela é apresentada uma solução elegante para o tratamento dos tipos no Hibernate – e que acabou virando parte do projeto. SpatialEJB3 nada mais é que um UserType (GeometryType no caso) com a implementação responsável por tratar o tipo Geometry. Ele pode ser usadao tanto com Hibernate puro, quanto para EJB3. Só achei estranho que as classes ainda não estão no postgis.jar.

Para usar o recurso, fica extremamente simples:

@Type(type = "org.postgis.hibernate.GeometryType")
public Geometry getLocation(){
return location;
}

No site é possível encontrar a documentação do projeto.

Por mais vasta que a documentação do Hibernate seja, sempre ficam pontos da API que precisam de melhorias na documentação. Um exemplo claro disso é esclarecer qual a diferença entre dois métodos da Session, o save() e o persist(). Ambos tem a mesma função: tornar uma instância transient em persistent. Segundo a doc da API:

• persist() – Make a transient instance persistent.
• save() – Persist the given transient instance, first assigning a generated identifier.

O método persist(), não garante que será atribuito um id à instância imediatamente, sendo que a associação ocorrerá quando o flush ocorrer. Além disso, ele garante que só irá executar um insert se estiver dentro do contexto de uma transaction. Já o save(), atribui a chave imediatamente, não importando se isso exige um insert (no caso do identity generator) ou se existe um contexto de transação. Isso explica também porque o save() retorna o Id gerado e o persist() é void.

Mais informações podem ser encontradas no Jira e no fórum do Hibernate.

update: não é somente eu que acha que a documentação precisa de melhorias nesse caso: HHH-1682

update 2: acabei de comitar a alteração na documentação, para a próxima versão do Hibernate (3.2.5), a seção Making objects persistent irá trazer informações mais detalhadas sobre a diferença entre os dois métodos.