Ian,

> Just to let you all know that I have fixed the problem I had with
> the database process growing massively. It was a problem with my
> Java code. Below is a code snippet of how I was accessing the
> database.
>
> ResultSet rs;
> Connection con = null;
> con = pm1.getConnection("Intelus");
> rs = con.createStatement().executeQuery("select * from users");
> rs.close();
> con.commit();
> pm1.freeConnection("Intelus",con);
>
> I have found that if I add a
> rs.getStatement().close();
> before the rs.close() the memory doesn't increase any more. I guess
> that Interserver isn't closing the statements properly when they are
> garbage collected.
>
> The problem was worse because of the connection pool. If I closed
> the connection, the memory growth stopped.

When you close the connection "in theory" the resultset would also be
closed.

IMHO this is not very tight code. We would

a) create an explicit statement object and close if. But we would close
it after closing the resultset, that is safer if you switch between
different databases.

b) You don't show any exception handling (probably just to save space in
the email). We have a try ... finally to do the closing and we have
separate try ... catch for the resultset and statement close calls so
that even if one fails we try the other.

c) the return to the connection pool also needs to be protected by
try...finally.

We have found a lot of inconsistancy between jdbc drivers (having codied
for 5 dbms and 7 or more jdbc drivers) about these kinds of issues so
that we are very rigid about always closing and always making sure that
we are fully protected against exceptions.

Boring I know, but your dbms persistance layer in your java application
should handle most of it for you.

Regards

Dave