Diego Plentz

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

Popularity: 32% [?]