tomcat7 - jdbc datasource - This is very likely to create a memory leak

I get the following messages in catalina.out log file when tomcat is shutdown. I am using Tomcat 7.x and the Tomcat JDBC data source.

Mar 26, 2013 1:17:52 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc 
SEVERE: The web application [/my_webapp] registered the JDBC 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. 
Mar 26, 2013 1:17:52 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/my_webapp] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak.

The first one claims that the DataSource has been forcibly unregistered so that is fine. However it is strange Because I have configured the destroy-method like so:

<bean name="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource" destroy-method="close">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/mydb"/>
    <property name="username" value="root"/>
    <property name="password" value="password"/>
</bean>  

Not sure why I get the second one. The one about the "MySQL Statement Cancellation Timer".

Any help is appreciated

EDIT 1: I tried the fix suggested by @Zelldon and it gets rid of the first error. However the MySQL Statement Cancellation Timer related issue still persists

Solution 1:

Try to put the sql Connector/Driver in the tomcat/lib and not in the war. Because every time you deploy the war the connector/driver will be created sometimes the garbage collector cant remove them which will ends in a memory leak. So try to move the connector on the tomcat/lib folder.

Please read the following answers:

Why must the JDBC driver be put in TOMCAT_HOME/lib folder?

How to configure Tomcat to connect with MySQL

Solution 2:

It could be related to this bug in the MySQL jdbc connector: http://bugs.mysql.com/bug.php?id=65909.

You can wait for the MySQL team to fix it, or you try to use the Drizzle JDBC connector which works fine with MySQL (you have just to change the parameter in the url connection) and, in my tests, doesn't have this kind of bug.