Hi, I did not follow this thread form the beginning, but I can provide a few tips about using connection pools in tomcat. 1. DBCP has quite a few problems in the area of scalability. We have our own modified version of the source that makes it more concurrent, and I believe some of those changes were integrated into DBCP. Use the latest stable version of DBCP form the commons project. It is a jar file in tomcat that you can easily replace. The fixes do not require using concurrent, that part of the code is not causing the problems. 2. If your JDBC driver supports caching of prepared statements and metadata, do it in the driver and disable this in DBCP. IMO DBCP does a poor job at best in caching. We use mysql and its JDBC driver is doing an excellent job. 3. Your JDBC driver may already be caching metadata that DBCP is caching. In this case you are caching the same data twice. Make sure it dose not happen, it is a big memory overload on the JVM. 4. Tomcat has a problem doing a clean shutdown of DBCP, and other JNDI resources. I traced in the debugger dangling connection pools that are created during the shutdown process. If your pool is configure to ping the connections once in a while, they can stay open for a long time, possibly forever. Our solution is custom extension that cleans up pools, which works in conjunction with our extended implementation of DBCP. 5. The connection pool leak is caused mostly when war files are replaced under load. If you are experiencing a problem of leaks in those conditions, then some common options are: A. Write custom extension to the pooling mechanism as we did. This is not a 100% solution. B. Avoid hot deployment of apps by shutting down tomcat before updates. This is safer, but also not 100% clean. C. Block Tomcat during the update. If you have a load balancer, redirect traffic to other tomcat instances, and then do the update while tomcat has no load. This reduces the problems significantly.
When you do a full tomcat shutdown, there will still be connections that are not closed, but the process itself will finish, and the database will clean up the connections after some time. This is of course not as clean as closing all the connections on server shutdown, but I don't know of any better option. I believe our custom cleanup code does close most connections on shutdown, but I have no 100% certainty or evidence that this is actually true. However it does do a lot of closing that did not happen before. I am not aware of any way to completely avoid dangling connection pool after hot deployment under load. We tried to fix this but it got too complicated, it is much easier to restart Tomcat and swallow the bitter pill. You can still do hot deployment of war files that do not access the database, though it is possible that the same leaks will leave lots of hanging objects of other types (like email clients, JMS clients, thread pools, HttpClient, etc). E On 10/26/09, Mark Thomas <ma...@apache.org> wrote: > Bill Davidson wrote: >> Christopher Schultz wrote: >>>When you've played with it for a bit, tell us how things turned out. >> >> It's looking like optimal is caching about 40 PreparedStatement objects. >> However, I should qualify that noting that it's with our application and >> specifically with our little pummeling benchmark, which requests a >> specific >> subset of services, and probably isn't even a great test of real world >> traffic. >> It was mainly designed to see how the app handled being heavily stressed >> (like getting hit with 1000 requests at a time). >> >> The system is still about 3-4% slower with DBCP than with our old pooling >> library. Our old pooling library did not wrap the Connection objects like >> DBCP does, though it did close old Connection objects so that they only >> got reused for up to two minutes at a time. I'm actually a little >> surprised by >> this. I would have expected that to make DBCP faster, since it keeps them >> open. > > The current DBCP (actually commons-pool) can struggle under very heavy > load in multi-thread environments. There are plans afoot for a pool 2.0 > that will be based on java.util.concurrent that should enable much > better multi-threaded performance. > > As always, it is best to check with a profiler to see what is actually > slowing you down. > > Mark > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
