Re: Memory leak ?
| От | Guillaume Cottenceau |
|---|---|
| Тема | Re: Memory leak ? |
| Дата | |
| Msg-id | 87hbab6492.fsf@mnc.ch обсуждение исходный текст |
| Ответ на | Memory leak ? (Pierre Le Mouëllic <pierre.lemouellic@xgs-france.com>) |
| Ответы |
Re: Memory leak ?
|
| Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: