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. ;-)
-R
- -chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
