Open cursors are NOT closed only by closing the ResultSet or Statement

Question

I've realised that the open cursors are only closed by closing the connection.
In my example code I have for-loop with a vector of table-names. For every table-name I start a query to retrieve metainformation (row-size, column-names). Although I close the ResultSet (which automatically closes the PreparedStatement/Statement) I reached after the 150th loop a max-cursor-exception (ora-01000) ?!
It seems that there is only the workaround to close and re-open the connection at the end of the for-loop. Which is performance-side pretty bad :-(.
Is there really no other solution?
Besides: does anyone know WHY the statement.close() also closes the ResultSet?? I think this is a bad design (hence to tight dependency between both classes). What if the garbage collector closes the statement (and hence to the JDOC the statement.close()-method also closes the ResultSet)? For example if a method uses a local Statement and returns a ResultSet (and the Statement-garbage is collected), then the ResultSet would cause an exception?!
Thanks for the help in advance
Tai

Answer 1

I've realised that the open cursors are only closed by
closing the connection.Or by closing the Statement!
In my example code I have for-loop with a vector of
table-names. For every table-name I start a query to
retrieve metainformation (row-size, column-names).
Although I close the ResultSet (which automatically
closes the PreparedStatement/Statement) I reached
after the 150th loop a max-cursor-exception
(ora-01000) ?!Closing the ResutSet does not automatically close the PreparedStatement/Statement.
>
It seems that there is only the workaround to close
and re-open the connection at the end of the for-loop.
Which is performance-side pretty bad :-(.
Is there really no other solution?
Just explicitly close the PreparedStatement/Statement!
Besides: does anyone know WHY the statement.close()
also closes the ResultSet?? You need to think of a resultset as a live connection to the database.
Consider SELECT * FROM ABIGTABLE, it would be inefficient to populate the Resultset with all of the rows (could even eat up all memory) so the first n rows are returned ( n = Statement.getFetchSize() ) and the next n rows are returned as needed.
I think this is a bad
design (hence to tight dependency between both
classes). What if the garbage collector closes the
statement (and hence to the JDOC the
statement.close()-method also closes the ResultSet)?
For example if a method uses a local Statement and
returns a ResultSet (and the Statement-garbage is
collected), then the ResultSet would cause an
exception?!You should use a statment and resultset, read all your data into a collection or a CachedRowSet (http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html) then close the statment as soon as possible. Never return a resultset form your data tier: that is tight coupling between the tiers of your application!