tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Would like to monitor memory use offline
Date Tue, 12 Aug 2008 14:07:04 GMT
Hash: SHA1


Richard S. Huntrods wrote:
| Everything is local except the pooled connections, so I would say this
| is the problem. This code was originally written before tomcat had good
| connection pools, and so I had to write my own. The pool is basically a
| vector of connections.

I wouldn't want to blame your connection pool just yet; I'm just saying
that it is a possibility. The open-source connection pools have a /lot/
of users and a /lot/ of eyes looking at them, and tend to be very
stable. Your in-house connection pool may not have been as thoroughly

| At a more fundamental level, I still don't think the new connector is
| working correctly (and I've read many of the forum discussions about
| this...).

Has anyone mentioned the behavior you are observing? Were those posts
anything but idle speculation, or has anyone come to an actual
conclusion about the cause of the errors?

| If I close the resultset AND the statement, then the connector
| should release all the objects created by those two. The connection is,
| after all, just a pipe between the database and the java code. The
| connector should not (IMO) be hanging on to statement or resultset
| objects just because the connection is still in existance.

I completely agree. Two things that I can think of that might be causing
problems with the Connector itself:

1. ResultSetMetadata -- use of the metadata methods can cause additional
queries to be executed, which means more ResultSet objects, Fields, etc.
I didn't see any use of this in your sample code, so I suspect this is
not the issue.

2. Client-side PreparedStatement caching. Have you enabled any of the
caching options provided by the driver? I'm guessing not, since you were
using a 3.x driver before, which IIRC does not support such caching.

| Still - this is most clearly NOT my problem as I can verify my code is
| working "normally" (i.e. no exceptions happening) and thus properly
| closing both the resultset and the statement.


| For fun I put try-catch blocks with additional resultset and statemtent
| calls to close in the finally block and it made no difference to the
| memory leak.

Right. I would not have predicted that you would change anything by
doing this -- it's just a good practice to get into in the event that
exceptions /do/ start cropping up.

| Yea - the code was developed a long while ago. There's also a single
| version that can run under Tomcat or as offline processes and I don't
| want to have to write two different database mechanisms to support the
| application outside of Tomcat.

Tomcat uses JNDI DataSources to provide connection pooling. This is very
easy to do outside of Tomcat if you are interested. Another option would
be gut your existing CP implementation and replace it with pass-through
calls to a library like commons-dbcp. This is exactly what I did with a
project that I inherited a few years ago and many, many JDBC-related
problems went away (more to do with connection leakage than memory leakage).

My last suggestion would be to use a real memory profiler. These tools
can typically tell you exactly where in your code a particular object
was instantiated. After you run your program for a while, inspect the
heap (and all those Field objects) and see where they are being created.
You may find that you are looking at fixing the wrong method in your own
code -- or that the driver itself is leaking Field objects (which would
be unlikely, but certainly possible).

Good luck,
- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message