Na última semana estive ajudando um amigo no fórum do GUJ a resolver uma situação no web container Tomcat. A questão era o seguinte: todas as vezes que é feito um stop/undeploy em um war, o “gatinho tom” não liberava o numero de conexões abertas no pool. Ou seja, a cada atualização em projeto war, (stop ou undeploy + start) o tomcat simplesmente duplicava o numero de conexões no pool. E por ai você já deve imaginar os problemas resultantes disso. Após montar um ambiente de teste, pude comprovar que a coisa realmente estava acontecendo. Depois disso passei a procurar a natureza do problema, e após algum tempo de estudo consegui descobrir. Sendo assim, hoje resolvi compartilhar a solução.
O Tomcat por padrão vem configurado para usar o commons dbcp como provedor de DataSource que é o componente responsável por controlar o pool de conexões das aplicações JEE. Este camarada ai constrói o pool no deploy da aplicação, mas não o destrói no stop/undeploy da mesma. Isso quer dizer que esse problema não vai existir caso seu ambiente de produção Tomcat seje desligando nas atualizações. Caso você precisar atualizar um war sem desligar o Tomcat, tenha certeza que você será mais uma vitima dessa situação. Como resolver? Existem dois caminhos:
- Trocar o provedor de DataSource para outro que libere as conexões no undeploy. Nessa opção você fica livre para escolher o de preferência, uma vez que existem varias outras boas opções.
- Implementar um servlet context listener que libera as conexões no undeploy, já que o commons dbcp não o faz . Segue minha sugestão para essa opção:
public class ContextoListener implements ServletContextListener { public void contextInitialized(ServletContextEvent ev) { public void contextDestroyed(ServletContextEvent ev) { |
Java2html |
Me coloco a disposição para ajudar qualquer um relacionado com o contexto. Até a próxima
.
Pingback: Tomcat 7 Corrige Fechamento do DataSource « Fernando Franzini Java Blog