When people first start using JDBC, there can sometimes be a natural tendency to rely on closing the connection to close everything that came from that connection including statements and result sets. In reality, this can cause serious problems in two distinct cases as follows:

Buggy JDBC Driver. Unfortunately in the Java world you cannot rely on JDBC drivers to be perfectly written. They tend have quite a few bugs, incomplete implementation of the JDBC specification or just be downright flakey. Some of the drivers (and I'm not naming names here), do not release resources when a connection or a statement is closed. In particular, some of them do not close the result set properly despite the statement being closed.

Application Servers. The way most application servers implement connection pooling is by wrapping the native JDBC connection for a given driver in their own proxy connection. When you call the connection's close method, the proxy does not close the underlying connection but instead returns it to the pool. Thus if that connection had 100 statements opened against it during the course of normal processing, those statements will remain active while the connection is kept open by the pool. Symptoms of this problem include the database running out of available connections, high memory usage and poor database performance.

The point is that the acquisition of all JDBC resources should be protected and released properly. The try..finally construct is the perfect way to protect JDBC resources and ensure they are released correctly. Every allocation of a JDBC resource should be protected in this way.