I have a web app I have developed under Tomcat 6.0.18 and have added in the dbcp system. As it stands now, It wants to make connections only after the first request to the app. I want the dbcp system to initialize x number of connections on app/server startup. I know if I want to initialize things on startup I include the <load-on-startup>1</load-on-startup> in the web.xml for the app; which will load the servlet and execute what’s in the init method. My question is this: Am I to assume that I need to OPEN and CLOSE x number of connections in the init section of the servlet to load the pool with live connections? Otherwise, I don’t see how it will create those connections and load the pool on startup. I seem to be missing or overlooking a method call in the api that will actually load the pool with live connections. Not sure if it makes a difference, but I also have the dbcp being set up in a ServletContextListener.
Any Help is greatly appreciated, have spent to much time on this trying to get it to work like I want or as it's supposed to.
From my understanding of apache commons DBCP, you'll only need to set up the Datasource once. This DataSource instance will include the pool of 'x' connections. The DataSource will also have the necessary support to get and close a connection. Anyways, getting and closing a connection simply retrieves and returns a connection instance from and to the pool.
Now, if I accurately comprehend the scenario you're describing, what you need to do is set up the DataSource at the starting up of your web application. As you've mentioned, you can set a particular [initialisation] servlet to load on startup and put in the logic of establishing the DataSource in its init() method. The 'x' number of connections you want in your pool should already be defined in the JNDI configuration of your DataSource. However, you do have to open and close the connections at the various points in your application where you need to use one. It will serve no purpose to open and close connections in the init() method of your initialisation servlet.
You should include the logic of flushing the pool and closing each of the connections explicitly in the destroy() method of the initialisation servlet.
This does help. I think I am looking at it the wrong way. I have been looking at it as a collection of static connections that are managed. i.e., putting 8 connections in an array or hashtable and grabbing them when needed and letting something check them every so often to keep them refreshed. It has been suggested that the pooling mechanism is a dynamic caching system; and looking at it as a caching system is starting to make more sense to me. where it just keeps x number of connections arround at any given point in time.
Your answer has saved me some time. I think you are correct. looking at it as a caching system, If I tried to open and close x number of connections in the init it really wouldn't get me much. You are also correct in that I could set the datasource stuff up in the init section of the servlet and just proceed from there, I have chosen to set it up in a ServletContextListener so that the datasource is global to the app. I don't know if this is a sound architectural choice, but it seemed to make sense. do you think it would make any difference in setting the datasource up in a separate servlet as oppossed to a ServletContextListener?
Thanks again for your help! I really appreciate it.
Oh, sure, you could do that. Or you could eat some pie. While reading this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop