On 04/04/2012 13:54, Hermes Flying wrote: > Hi Pid, > > This is the configuration The following entry is in server.xml > > <Resource name="jdbc_GENERIS_RS" auth="Container" > type="javax.sql.DataSource" driverClassName="org.h2.Driver" > url="jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema" > > username="root" password="sa" > maxActive="20" maxIdle="10" maxWait="-1" />
OK. That means it is a server wide connection pool... > And the following entry is under $TOMCAT_HOME/conf/context.xml > > <ResourceLink name="jdbc/GenericDataSource" global="jdbc_GENERIS_RS" > type="javax.sql.DataSource"/> ... that is shared by one or more applications. > Concerning your other questions: 1) Yes I could shut down the > database manually but I would like to do it as a last resort if this > issue is something that can not be fixed since I believe that my > setup is correct and should be supported as is Based on what I have seen so far, I would agree. > 2) You say that it depends if I should close down the connection > myself. But how can I do that? A javax.sql.DataSource does not > provide a close method. I would have to cast to > org.apache.tomcat.dbcp.dbcp.BasicDataSource to call close. I am not > sure if this is the proper approach. I mean I then get bind to this > class, right? Or there is another way? Not that is applies in this case (since the pool is global rather than per application) but as of 7.0.12 yo an set the closeMethod for a resource that should be the name of a zero atg method to call to shut down the resource >> SEVERE: The web application [/GeneralApplication] appears to have >> started a thread named [H2 Log Writer GENERICAPPLICATION] but has >> failed to stop it. This is very likely to create a memory leak. Apr >> 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/GeneralApplication] appears to have started a thread named [H2 >> File Lock Watchdog >> /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db] >> but has failed to stop it. This is very likely to create a memory >> leak. >> >> Why do I get these messages? What is happening is the the JDBC driver is creating threads. When a thread is created the context class loader for the thread is - by default - set to the current context class loader. These threads are being created when the current context class loader is the web application class loader. i.e. they are being created as a result of the web application using the JDBC driver (via the pool). When the web application stops those threads are still in use (since it is a global pool) but the threads retain a reference to the web application class loader and this creates a memory leak. >> Additionally the input from H2 dev is that these messages are a >> Tomcat problem. Tomcat should have first disposed of the connection >> pool and then log the running threads.Their explanation seem >> correct to me. > > That's the usual first response. Let's figure out whether it's > correct... And it is wrong. When H2 creates those threads it should ensure that the context class loader for the threads is set to the same class loader that loaded the JDBC driver. We had similar issues with the evictor thread in Apache Commons Pool (used by DBCP). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
