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 Mon, 11 Aug 2008 14:12:08 GMT
Hash: SHA1


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
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