• 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:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

DBUtility for closing connections

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

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.


{ please. ignore some typo mistakes}
 
Bartender
Posts: 2661
19
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Neeraj Vij wrote:Hello,

.... Since the connection returned from the getConnection() method has still a reference to the connection object which is never closed....

Where does the connection returned from the getConnection() method hold a reference to the connection object?
 
author & internet detective
Posts: 41110
848
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Neeraj,
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.
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:


 
Neeraj Vij
Ranch Hand
Posts: 315
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?

Many Thanks,
Neeraj
 
Bernhard Haeussermann
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Neeraj,

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().
 
reply
    Bookmark Topic Watch Topic
  • New Topic