*
The moose likes JDBC and the fly likes Potential Connection/Memory Leak Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Potential Connection/Memory Leak" Watch "Potential Connection/Memory Leak" New topic
Author

Potential Connection/Memory Leak

James Swan
Ranch Hand

Joined: Jun 26, 2001
Posts: 403
I was tracking down an issue today where some process that queries an Oracle database was blowing up with "maximum open cursors exceeded" exception.
We know this is to do with not closing ResultSet/Statement/Connection objects when they are finished being used, turned out the close calls needed to be put into a finally block.
Now I came across some code that has got me a little confused, my initial thoughts is this could be a potential leak:

I am used to doing it this way:

So my question is (I guess I should read up on the Java Language Specification), what happens when you call a method that returns an object but you don't assign that return object to a variable, eg. the first code snippet, the executeQuery() on the Statement object returns a ResultSet, but it is not being assigned to a variable.
Can this be a potential issue?
Thanks.
Peter Reinhardt
Ranch Hand

Joined: Aug 02, 2002
Posts: 57
I don't think the language spec will help you.
Basically the question is: If you execute executeQuery(), do you have to close the (internally created) resultset yes or no. A ResultSet holds on to a DB cursor which you have to release. so does executeQuery() already open a cursor or is the cursor opened when you call the first time resultset.hasNext().
I don't know and I guess it is not part of the JDBC spec as well. to be on the safe side, I would always close the resultset once you call executeQuery().
Peter.


SCJP 1.2, SCJD, SCEA, IBM 484, Weblogic 7
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Potential Connection/Memory Leak