10

I am using Tomcat 7 connection pooling (as a Tomcat resource in server.xml and context.xml) in a web application and it works.
My question is: Is it possible to "tell"/"force" tomcat to dispose the connection pool after it is created?

The reason I ask is the following:
I am using H2 and run into some "racing" issue on shutdown.
H2 remains open as long as there is a connection open but Tomcat does not dispose the connection pool and so connections remain open. And as a result I have various issues on shutdown.

I found that I could issue an SQL SHUTDOWN command to close H2 but I want to explore all the alternatives for my case.

So is it possible to "tell"/"force" tomcat to dispose the connection pool (at least on shutdown)?

Jim
  • 18,826
  • 34
  • 135
  • 254
  • 1
    Have you considered using ServletContextListener ? ContextDestroyed will be called when your app is going to shutdown, allowing to do these kinds of cleanups. – NiranjanBhat Apr 03 '12 at 06:32
  • @coderbhatta:how can I tell Tomcat to dispose the connection pool? – Jim Apr 03 '12 at 06:34
  • so u mean you are using connection pool as a Tomcat resource here ? – NiranjanBhat Apr 03 '12 at 08:35
  • @coderbhatta:Yes.And I would like to know if I can dispose it in my code – Jim Apr 03 '12 at 08:40
  • check this link: here they show you how to close the data source from the client using ServletContextListener – NiranjanBhat Apr 03 '12 at 10:12
  • @coderbhatta:Where is the link?You didn't copy it here – Jim Apr 03 '12 at 10:47
  • My bad :) here it is: http://stackoverflow.com/questions/3320400/to-prevent-a-memory-leak-the-jdbc-driver-has-been-forcibly-unregistered – NiranjanBhat Apr 03 '12 at 11:00
  • @coderbhatta:I see the link but `DataSource` does not have a `close` method to use as mentioned in the link! – Jim Apr 03 '12 at 11:27
  • ok, I am not very confident about the DataSource APIs that your are using. Also I would ask you to check the code where you are using the dataSource so that if you have any connections unclosed that are got from the datasource. This is also one of the issues that Tomcat have mentioned that leads to datasource hang issues. – NiranjanBhat Apr 03 '12 at 11:40
  • @coderbhatta:I always close the connection to be send back to the pool. I am using the `javax.sql.DataSource` in my code.The standard API.It doesn't have a `close` – Jim Apr 03 '12 at 11:47
  • Are you storing connection variables as instance variables in your code ? If this is the case try to change these instance variables to local variables and check if this clears the datastore access. – NiranjanBhat Apr 03 '12 at 11:56
  • No I don't store them.I get a connection from datasource, use it and then close it – Jim Apr 04 '12 at 06:15

5 Answers5

1

I think you can try to put debug log on and check whether its issue with connection not released by application or something else like datasource configuration parameter in server.xml.

mostly it should be the case where application is not releasing connection.

awsbz77
  • 649
  • 5
  • 8
1

How about writing a custom ServletContextListener and then having it shut down the pool when the context is destroyed. Here's an article about ServletContextListener being used to create shutdown hooks:

shutdown hook for java web application

The API for context listeners seems pretty straightforward:

http://docs.oracle.com/javaee/5/api/javax/servlet/ServletContextListener.html

Community
  • 1
  • 1
Zeki
  • 5,107
  • 1
  • 20
  • 27
0

please see my answer in : Context specific JNDI parameters problem in tomcat 6. There's a lot of stuff you can do with jndi resource.

<Resource name="jdbc/NAME" auth="Container" type="javax.sql.DataSource"
               maxActive="100" minIdle="10" maxWait="10000" removeAbandoned="true"
               removeAbandonedTimeout="60" logAbandoned="true"
               testWhileIdle="true" testOnBorrow="true" testOnReturn="false"
               timeBetweenEvictionRunsMillis="5000"
               validationQuery="SELECT 1" initialSize="10"
               username="usrname" password="password"   
               driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/databb?autoReconnect=true"/>
Community
  • 1
  • 1
Mitja Gustin
  • 1,723
  • 13
  • 17
  • `There's a lot of stuff you can do with jndi resource`.Can you do what the OP asks about though? – Jim Aug 24 '12 at 08:44
  • there was a possibility in tomcat's 5.5 GUI Administration tool to restart or disable / enable resource pool by hand. The administration tool of WebLogic 11g has similar functionality. In tomcat6-7 manager application you can however only list jndi resources. There is NO way to restart container managed (that is tomcat) JNDI resource from web application which only get's installed into that container. If you shutdown tomcat, the pool get destroyed. Any connections still as a result of some web application not closing connections properly, will be logged as abandoned in catalina.out. – Mitja Gustin Sep 06 '12 at 13:21
  • Tomcat should dispose connection pool on shutdown. Look at the source code for tomcat7 (Class JDBCConnectionPoolLeakPrevention). Otherwise, you have the option to use JConsole and connect to driver's exposed MBean (if any is available). In both cases, it will require some time to fiddle with this. – Mitja Gustin Jan 14 '13 at 13:33
0

As described in documentation http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions it possible to set closeMethod of container datasource. I'm not sure about 'disposing' connection pool, but i think it worth a try.

Name of the zero-argument method to call on a singleton resource when it is no longer required. This is intended to speed up clean-up of resources that would otherwise happen as part of garbage collection. This attribute is ignored if the singleton attribute is false. If not specificed, no default is defined and no close method will be called.

Also you can deploy DataSource programmatically and start/stop it in ServletContextListener, example for dbcp (sorry, it from my unit-tests, but easy to rewrite):

import org.apache.commons.dbcp.BasicDataSource;

static BasicDataSource bds = new BasicDataSource();

@BeforeClass
public void setUp() throws Exception {
    bds.setDefaultAutoCommit(false);
    bds.setDriverClassName("org.h2.Driver");
    bds.setInitialSize(0);
    bds.setMaxActive(2);
    bds.setMaxWait(10000);
    bds.setPassword(null);
    bds.setUrl("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1");
    bds.setUsername("sa");
    bds.setValidationQuery("select 1 as test");
}

@AfterClass
public void tearDown() throws Exception {
    bds.close();
}
user1516873
  • 5,060
  • 2
  • 37
  • 56
0

Maybe I don't understand the question. To be more clear, if you shutdown Tomcat (and hence it's JVM), then neither Tomcat nor it's connection pools, nor any of it's daemon threads would still be alive ... and thus no memory references would be left in tack.

How exactly have you come to the conclusion that a Tomcat resource has a reference to a connection pool, after Tomcat is shutdown? You wouldn't be able to see that in a profiler, and frankly, it doesn't quite make sense. For example, is it possible that the OS keeps connections open for a short period of time before destroying them? Have you tried the same tests using the same OS, but instead with a different container, something like Jetty? Are you using keep-alives, or some form of persistent connections?

If you want to get down-and-dirty with Tomcat's management of a resource exposed through JNDI, you can make your own DataSource implementation that delegates to the H2 DataSource. You can do this my using the factory-method attribute within your server.xml (or context.xml)

Here's a working example on github : https://github.com/tvollmer/connection-factory

Beyond that, it would help if you could further clarify what you mean by "various issues on shutdown". Those details matter, and it's not clear to me how you've logically gone from "various issues" to saying that Tomcat "does not dispose the connection pool". You could be dealing with 2 completely separate issues here, and you may want to check out antiResourceLocking and antiJARLocking settings for Tomcat on Windows.

Volt0
  • 101
  • 6