Release the memory of Statement

[Mark Guo]

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!
　　
　

[Bill Johnston]

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:

if (stmt != null) stmt.close();

[Vanja Sanjin]

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:

} finally {
    if (stmt != null) { stmt.close(); }
}

-
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]

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]

Sorry.

[Bill Johnston]

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]

Thanks. I feel easier. [edit] becaouse I was not sure

[Bill Johnston]

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

Good I am glad ;)

[Vanja Sanjin]

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

[Bill Johnston]

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

Good - sorry I was a grouch. Best Regards,

~Bill

[Vanja Sanjin]

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