Yes - the Oracle driver is
very sensitive to cursor leaks
In a web application environment, "closing" your connection just returns it to the pool, so you shouldn't rely on your connection close to close all other resources either.
This is
not enough in all cases. The close methods may throw SQLException, and a failure to close the result set, for example, will prevent the connection from being returned to the pool. In a web application environment a single problematic statement might now deplete your connecton pool in a matter of seconds, depending on how clever the application server's connection pool is. To be robust without making too many assumptions about the environment, execution of all close statements should be guaranteed:
We aren't there yet. Any exception thrown by the close statement will will obscure the exception thrown inside the try block, which is bad because the first exception will be the most informative about the root cause of the problem.
If you want to write good JDBC code, you'll write over two dozen lines of clutter to execute one pesky SQL query. Unsurprisingly, almost no-one does this, and virtual all JDBC code suffers from potential resource leaks and/or obscured exceptions. This is why frameworks such as the
Spring JDBC template or the higher-level
iBatis are IMHO indispensable tools. Never write raw JDBC. It's just too hard and cumbersome to get right.
- Peter
[ August 25, 2004: Message edited by: Peter den Haan ]