• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Release the memory of Statement

 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi friends

I have a question for releasing the memory of Statement.
Statement stmt = conn.createStatement();
Whether the "stmt.close()" can release the memory of stmt object or "stmt = null" can release the memory of stmt object ? I'm not sure.

Thanks in advance!
  
 
 
Ranch Hand
Posts: 201
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mark Guo wrote:Hi friends

I have a question for releasing the memory of Statement.
Statement stmt = conn.createStatement();
Whether the "stmt.close()" can release the memory of stmt object or "stmt = null" can release the memory of stmt object ? I'm not sure.

Thanks in advance!
  
 



You want to do something like this:
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hola people. I come in peace. I will rephrase the question:
Does garbage collector releases resources of a Statement object?

I've found the answer (which is allright with what i was thinking) here:
http://stackoverflow.com/questions/8652336/jdbc-garbage-collection

Every object in java holds some piece of the heap memory. Nullifying that object like stmt = null makes that object eligible for garbage collection, (the other thing what makes it eligible for a garbage collection is when a method is ended in which the object is instantiated, or something like that, ) and that means that the garbage collector will free that piece of the heap memory which was reserved for that object, but in this case, this object, not only holds the piece of the heap memory, but in collaboration with other objects together , as a mechanism, they hold the 'resources', which can be sometimes files on a hard disk, or in this case I don't know, but anyway outside of the heap memory, yet still, for takeing care about those resources, some parts of the heap could be occupied with objects to hold information about resources, to manipulate with resources. I can imagine a situation that even when those little pieces of memory could be wiped that resources are still holded somehow, becouse it's about the larger "mechanism". I'm skiing here.
I guess that here it is a little bit a question: what does "releasing the memory of Statement" mean, what does "the memory of Statement" mean?

Because there are two things.
-resources
-memory


stmt.close() will not make that object eligible for a garbage collection, but it will release resources

stms = null will make that object eligible for a garbage collection, but it will not release resources.



Few usefull links:
-
http://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#closing_connections
This line is from tutorial. In tutorial it looks like this:



-
https://coderanch.com/t/303444/JDBC/java/Closing-Statement-object-prior-committing

Roger Chung-Wee wrote:

The Connection encapsulates database connection functionality, the Statement encapsulates SQL queries and execution.



Reid M. Pinchback wrote:

FYI, if you are using a mature connection pool (e.g. in WebLogic or JBoss) and prepared statements, the whole situation might be moot. Servers can maintain a cache of the prepared statements, so "close" just closes a wrapper object. Basically you are just telling the server you are done with using the cached object.

The most important objects to close when you are done is ResultSet and some of the JDBC metadata objects. Those are associated with database cursors. If you invoke multiple queries before closing a connection but fail to close cursors between queries, you can run out of cursors pretty rapidly. If you are just doing a single query and then closing the connection, there is no need to explicitly close statements and result sets because the connection close automatically closes all open JDBC objects associated with the connection.






-
http://stackoverflow.com/questions/4507440/must-jdbc-resultsets-and-statements-be-closed-separately-although-the-connection

Quote from there:

The reason I say its good practice... For example, if for some reason you are using a "primitive" type of database pooling and you call connection.close(), the connection will be returned to the pool and the ResultSet/Statement will never be closed and then you will run into many different new problems!

So you can't always count on connection.close() to clean up.





Remember, there are always two things.
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vanja Sanjin wrote:Hola people. I come in peace. I will rephrase the question:



What do you mean "I will rephrase the question"? This isn't your thread - please don't hijack someone else's topic.
 
Vanja Sanjin
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry.
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vanja Sanjin wrote:Sorry.



Now it's my turn to be sorry. When I first started reading your post it seemed like you were hijacking it. I can see now clearly you weren't. So I apologize to you.
 
Vanja Sanjin
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. I feel easier. [edit] becaouse I was not sure
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vanja Sanjin wrote:Thanks. I feel easier. [edit] becaouse I was not sure



Good I am glad ;)
 
Vanja Sanjin
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
: ) Me too (I laughed a bit from happines, thanks)
 
Bill Johnston
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vanja Sanjin wrote:: ) Me too (I laughed a bit from happines, thanks)



Good - sorry I was a grouch. Best Regards,

~Bill
 
Vanja Sanjin
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's ockay. I was acting smart, and I am not enough expert for that, otherwise, what I wrote would sound better with less acting. I think I've deserved it at least a bit. Don't worry. Full respect to You too.

Vanja

Bye
 
reply
    Bookmark Topic Watch Topic
  • New Topic