Return-Path: Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: (qmail 76854 invoked from network); 28 Apr 2010 11:17:56 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Apr 2010 11:17:56 -0000 Received: (qmail 94755 invoked by uid 500); 28 Apr 2010 11:17:56 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 94479 invoked by uid 500); 28 Apr 2010 11:17:54 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 94471 invoked by uid 99); 28 Apr 2010 11:17:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 11:17:54 +0000 X-ASF-Spam-Status: No, hits=-1359.9 required=10.0 tests=ALL_TRUSTED,AWL X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 11:17:53 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o3SBHWHx008720 for ; Wed, 28 Apr 2010 11:17:33 GMT Message-ID: <26466916.55721272453452871.JavaMail.jira@thor> Date: Wed, 28 Apr 2010 07:17:32 -0400 (EDT) From: "Sebb (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (DBCP-332) Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak In-Reply-To: <29618407.175781272130910629.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861770#action_12861770 ] Sebb commented on DBCP-332: --------------------------- Is it possible for multiple data sources to register the same driver? If so, won't deregistering it in one cause problems for the others? > Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak > --------------------------------------------------------------------------- > > Key: DBCP-332 > URL: https://issues.apache.org/jira/browse/DBCP-332 > Project: Commons Dbcp > Issue Type: Bug > Affects Versions: 1.3, 1.4 > Reporter: Grzegorz Borkowski > Fix For: 1.3.1, 1.4.1 > > > BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload: > SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. > I was able to fix it by overriding close method this way: > {code} > public class XBasicDataSource extends BasicDataSource { > @Override > public synchronized void close() throws SQLException { > DriverManager.deregisterDriver(DriverManager.getDriver(url)); > super.close(); > } > } > {code} > but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.