-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard,
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 tested. | 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. Agreed. | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkihmQgACgkQ9CaO5/Lv0PCT+gCfcnyqkmwMAyiCZUlsCr0QjmIV /0sAnj5FOECT7QlfIad7PMX8xg0Tc6ud =HbMZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]