Pierre Le Mouëllic <pierre.lemouellic 'at' xgs-france.com> writes:
> With this code :
>
> public class TestJDBC {
[...]
> try {
> sQLStatement.setInt(1, 2602);
> rs = sQLStatement.executeQuery();
> sQLStatement.setInt(1, 2604);
> rs = sQLStatement.executeQuery();
> sQLStatement.setInt(1, 2605);
> rs = sQLStatement.executeQuery();
> } catch (SQLException e) {
> }
> finally{
>
> try {
> if(rs!=null)
> rs.close();
e.g. you explicitely close only the last resultset of the three
you produced (assuming no exception)
> In eclipse Helios profiler, Jdbc3ResultSet live instances increase (and never
> decrease). Same thing with
Garbage collection is not predictable, closing resultsets (and
statements) is strongly adviced if you want to release JDBC
resources in a timely manner.
I have never used this profiler but it would be interesting to
know if any references are keeping these objects alive (then we
could begin thinking of a leak), or if they are only not yet
collected by the GC because it decided not to do it yet for any
reason.
Interestingly, the diff between:
http://download.oracle.com/javase/1.4.2/docs/api/java/sql/Statement.html#close()
and:
http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#close()
shows they've removed "Statement object is automatically closed
when it is garbage collected." no idea why though. probably a
more seasoned PG-JDBC dev/user would have?
--
Guillaume Cottenceau
