Memory/Heap Status after closing ResultSet in JDBC

Question

1. ResultSet fetches records from database.
2. After using the resultset object we finally close the resultset.

Question is , once rs.close() is called, will it free the delete the fetched records from memory? or when JVM is facing shortage of space, garabage collector will be called to delete the resultSet?

If JVM is invoking GC when it faces shortage of memory, is it a good practice to call the Garbage collector manually in the java program to free up the space?

Answer 1

Result Sets are often implemented by using a database cursor . Calling resultSet.close() will release that cursor, so it will immediately free resources in the database .

The data read by a Result Set is often received in blocks of records. Calling resultSet.close() might "release" the last block, making it eligible for GC, but that would happen anyway once the resultSet itself goes out of scope and becomes eligible for GC, and that likely happens right after calling close() , so it really doesn't matter if calling close() releases Java memory early.

Java memory is only freed by a GC run. You don't control when that happens (calling System.gc() is only a hint , you don't have control).

You're considering the wrong things. What you should focus on is:

• Making sure resources ¹ are always closed as soon a possible to free up database and system resources.

  This is best done using try-with-resources .

• Making sure you don't keep too much data, eg don't create objects for every row retrieved if you can process the data as you get it.

  This is usually were memory leaks occur, not inside the JDBC driver.

^{1) Eg ResultSet , Statement , Connection , InputStream , OutputStream , Reader , Writer , etc.}

Answer 2

ResultSet.close() will immediately release all resources, except Blob, Clob and NClob objects. Release means resources will be freed when Garbage Collector decides so. Usually we don't have to worry about it.

However, some memory used by JDBC may remain used. Suppose that the driver has some sort of cache built in, and that cache is connection-scoped. To release that memory, you'd have to close JDBC Connection.

Eg MySQL JDBC has default fetch size of 0, meaning it loads entire table into memory and keeps it in the memory for all of your statements. What's the scope of this in-memory buffer? ;)

Anyway, if you suspect memory issues, have a look at your JDBC driver specifics.

Rule of thumb, explicit GC is never good idea. But for a quick look to determine if ResultSet.close()/Connection.close() release any resources, give it a try: inspect used/free memory, close(), gc(), inspect memory again. Without explicit GC you will hardly see any changes.

Answer 3

Explicit GC is a burden on JVM as it has to frequently check the memory usage and decide when to trigger it. Where as, setting the appropriate GC as per application requirement would be sufficient to handle the above scenarios.

ResultSet.close will mark the resources for garbage collection ie freed up the reference to mark the memory blocks as non-reachable. Also, for a jdbc, connection needs to be closed so that memory holding the connection cache can also be marked for gc.