should the DB utility classes be used for closing the connections, if the connections is also obtained using the same DB utility classe. Since the connection returned from the getConnection() method has still a reference to the connection object which is never closed.
for example in the below mentioned example the connection is not null even after calling the metod for closing rhe connection.
A few things are going on here. First, note those helper methods could be static since there is no state stored.
In the close method, dbConnection=null; is setting the parameter passed in to null. The callers value is not null. This is ok, it just doesn't seem to be what you are expecting. Once you call close, the caller has a connection object reference to something that isn't a live connection and will receive errors if trying to call it.
The most important thing is that with this pattern, you have to remember to close the connection everywhere you get one. Some people use a superclass to avoid this problem.
In the closeConnection() method, the dbConnection variable does indeed receive the value "null". The reason the conn variable in the main() method does not become null, is because in Java parameters are always passed by value. That is, the value of the variable conn (which is the address of the Connection object) is copied into the parameter variable dbConnection. Note that in closeConnection(), because dbConnection now contains the same address as conn, they refer to the same Connection object in the heap. dbConnection then receives the value null. However, because the pass-by-value parameter passing scheme is used, this value is NOT copied back to conn. conn still refers to the Connection object, which still exists in the heap, although it is closed and may therefore not be used anymore. Note that, as long as the Connection is closed, it doesn't matter that it is still in the heap - the space that it occupies will be freed by the Java runtime garbage collector eventually.
I suggest that you read up about parameter passing modes to be able to understand this concept better. For instance, have a look at http://pages.cs.wisc.edu/~hasti/cs368/CppTutorial/NOTES/PARAMS.html.
Finally, whenever you create about any kind of connection, you must ensure that it will always eventually be closed. This should be done by using a finally-block.
Note that in your main() method, if an exception is thrown between lines 43 and 45, the Connection will never be closed.
The correct version of your main() method is:
Joined: Nov 25, 2003
Thanks to all of you for your inputs. Connection object is closed in main() and no operation will be allowed on the same object ,but, since the reference object in main is still not null, will it still be eligible for garbage collection ?
I just wanted some input regarding the performance issue considering the same scenario in a web application, since there could be multiple request which will be opening up connection objects, if those connectio objects are closed but not NULL, will it impact the performance of the application ?
Joined: Aug 05, 2009
Since conn still references the Connection object within your main() method, the Connection object will not be freed up by the garbage collector. However, as soon as the main() method returns, conn goes out of scope, and the Connection object will be eligible for garbage collection. To me this is ok, however, if for some reason you would like the Connection to be eligible for garbage collection while conn is still within scope (i.e. while the main() method is still executing), just set conn equal to null in main().
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com