It happens quite often that a JDBC connection is declared as the instance-level variable. The actual connection is then obtained at construction time. All methods of the object that need database access will then just use the same, already opened database connection. This makes the code run faster, because obtaining a database connection is usually the main time consuming operation.

The question that arises when using this approach is: how do you release a database connection? Some programmers think that it is not necessary, because when the object is no longer used (i.e., all references to it are dropped), GC will eventually come across and reclaim its memory. At this time, all the references that the object is holding will be freed as well. And, of course, every decent implementation of the JDBC Connection would make sure that the database connection is closed when the connection object is deleted.

The problem with that theory is that GC usually kicks out when the VM is low on available memory. This means that the object may sit unused in memory for quite a long time, keeping the database connection opened.

There are several ways to deal with this:

1. Obtain database connection inside the method call, and release it in the finally{} block. This may slow down the code a little bit, so if performance is crucial, using connection pool can help.

2. Have some public method on the class that, when called, explicitly closes database connection. This approach works better if the method is made part of some interface, like ResourceConsumerIfc. That way all the classes that cache some scarce resources at the instance level (JDBC connection, streams, naming contexts, etc.) can implement this interface and indicate that they do cache some resources. They will also provide the means to explicitly release those resources. As a safe guard, you may want to also override finalizer to call this method.