File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Potential Connection/Memory Leak

 
James Swan
Ranch Hand
Posts: 403
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 57
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic