tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Huntrods" <>
Subject Re: Would like to monitor memory use offline
Date Mon, 11 Aug 2008 23:23:20 GMT
> 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).

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.

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

> |> 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?
Yea - looked further and I have seen try/catch blocks in finally code.

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.

> | 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.
I will not disagree with this. That's why the finally is there in the 
first place.

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

> | 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.
I am for now, but I still want to resolve this so that I can keep 
current with the connectors. It's pretty much  guaranteed at some point 
in the future a new version of MySQL will need the new connector in 
order to work. ;-)


> - -chris 

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

View raw message