-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard,
Richard S. Huntrods wrote: |> Richard, |> |> Richard S. Huntrods wrote: |> | public static Vector listLookup(String table) { |> | // Connection connection = null; // connection is managed by a |> | connection pool |> |> So, is 'connection' a local or not? | It's part of my code (I use my own connection pool class) but not to the | DBMS code. Only if you can't get a connection from the pool | (connection==null) do you create a local one for this method. | | If the connection from the pool is OK, you use it then release it back | to the pool. If it's local (because you could not get one from the pool) | then you close it in the finally block. I think you are misunderstanding me: I'm asking if you are using a shared java.sql.Connection reference among all threads running your db code. If you are, then you've got a big problem, which could explain some of the memory leaks you are seeing. If you have a class-level reference like this: public class MyDBMSMethods { ~ private Connection connection; ~ public List getMyRecords() ~ { ~ connection = getConnectionFromPool(); ~ ... ~ } } ... then you should expect lots of problems. From your posted code, it looks like this is what you are doing. All connection references should be strictly local to each method. Each method should get its own connection from the connection pool, use it, and return it to the pool (unless you accept the connection as a parameter to the method, in which case, you should use it). |> You need to have statement.close() and resultSet.close() in here (in the |> finally block), not up above. Also, most database connection pools |> require that you call connection.close() to return the connection to the |> pool. Are you ever calling connection.close()? | | Um, sorry to disagree, but that is not really correct and also does not | touch my problem. Not closing your resources in a finally block it surely /not/ correct, and you /can/ leak resources in this way. Which part of my statement is not correct? | I am already closing the resultSet and statement in the "normal | execution" part of my code. At no time during the execution of this code | in these tests was an exception thrown in this method It doesn't matter. If you do not close your resources in a finally block, they are not guaranteed to be closed. It might not be your current problem, but it could be your future problem. | so *I was now | correctly closing the statement and resultSet. YET IN SPITE OF THIS the | versions of the connector after 3.1.10 FAIL to release the Field objects. | | The other reason NOT to put close() in the fianlly block is that the | close() methods can throw and exception. That's why you wrap the call to close() in its own try/catch block. | It is very bad programming | practice to put "exception throwing code' in a finally block. Sure, you | could use another "try-catch" structure for the close() statements, but | really - you should have already closed the stuff in the normal | execution (as I did). If you say so. My code doesn't leak DB resources, and it is written in this way. | I did state one thing in error - the finally block (of course) ALWAYS | gets called, so you only want code in that block that must be done after | all else has happened, but you also don't really want to be repeating | code that should go elsewhere (like the close()). |> |> |> Also, which connection pool do you use? | | My own. Is there a compelling reason not to use one of the freely-available, well-supported connection pools available? Tomcat even has one already built into it. | Yea - the problem may be in the connection pool that I wrote, but I | still find it odd that closing the resultSet() and statement() has no | effect using connectors from 3.1.10 and on. Connector 3.0.17b and prior | work just fine and release the objects. If that's the case, I would stick with the Connector/J version that works. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkigSLgACgkQ9CaO5/Lv0PCatgCgkjmgLpyS0ZgGHjr1mHnIWCXO 4kIAnjZHj+16aoc2DY8ScKJmBqP8Y4rx =rQ35 -----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]