6

My case is as follow:

  • I have to maintain a server, with Tomcat(6) as web server, that has a bunch of webapps on it. These webapps are maintained by others. Our server has a connection to another department's DB server, which has information that our webapps need to display. Without proper pooling strategy, our server soon turned to disaster.

  • Now that I introduce Pooling to everyone (I chose BoneCP - 0.7), we are going to create single pool that stays on Tomcat's global JNDI Context and let everyone get connection from it. That should solve the problem, i guess.

My concern is: How can I fully control this Pooling ? I have some requirements:

  • I want to reload DataSource configuration at runtime, either manually or programatically (will try to connect to a backup server in the time of need)

  • Change number of connection (min, max, idle connections) that can change from time to time

  • Keep Tomcat alive is preferable

  • I intent to build an alert system that use JMX to connect and retrieve information, and have a button to reload the Pool (I know that all Pooling strategy have some kind of recovering, but the other DB server crash periodically, so restart connections by hand is somewhat preferable).

I think of some possible solutions:

  • Tell Tomcat to restart its Global JNDI Context
  • Tell Tomcat to restart its DataSource object
  • Tell BoneCP to restart its pool, and recreate connections if necessary
  • Restart Tomcat itself

My Question are:

  1. Can I safely perform those above solutions without affect Tomcat (and other webapps) ?
  2. Should I bother doing this at all ? (Just restart Tomcat, I guess)
bkhnjkt
  • 91
  • 1
  • 3

1 Answers1

2

(Why does anyone choose BoneCP? Every question I've ever heard about that involves BoneCP is resolved by the poster switching to another CP and everything works. BoneCP isn't even at v1.0, yet. I guess it's the next big thing. Just hasn't yet arrived.)

Tomcat comes with support for Apache commons-dbcp and Tomcat's own tomcat-pool built-in: just configure your JNDI connection pool as per the Tomcat docs and you're off.

Unfortunately, Tomcat does not currently support a re-load of the DataSource at runtime. You can change properties via JMX, but the changes have no effect. You can also close the pool, but you just end up with a closed pool which is then worthless.

Logging an enhancement in Tomcat's bugzilla would probably be a good thing to do.

Christopher Schultz
  • 20,221
  • 9
  • 60
  • 77
  • I guess because the built-in dbcp isn't good enough. That why they keep reinvent the wheel but for good reasons. I kind of respect that. – bkhnjkt Jan 23 '13 at 16:09
  • What do you mean "I guess..."? You don't know why you are using an alternate connection pool? You should at least check-out [tomcat-pool](http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html) – Christopher Schultz Jan 25 '13 at 23:09