13 messages in com.mysql.lists.javaRe: Article in JDJ
FromSent OnAttachments
Teemu Kuulasmaa19 Oct 2004 04:35 
Mark Matthews19 Oct 2004 07:10 
Jim Tyrrell19 Oct 2004 10:22 
Mark Matthews19 Oct 2004 11:05 
Kevin A. Burton20 Oct 2004 00:57 
Kevin A. Burton20 Oct 2004 00:58 
Teemu Kuulasmaa20 Oct 2004 05:06 
Mark Matthews20 Oct 2004 06:15 
Mark Matthews20 Oct 2004 06:19 
Kevin A. Burton20 Oct 2004 11:26 
Teemu Kuulasmaa20 Oct 2004 22:08 
Youngho Cho27 Oct 2004 16:53 
Youngho Cho28 Oct 2004 00:41 
Subject:Re: Article in JDJ
From:Mark Matthews (ma@mysql.com)
Date:10/19/2004 11:05:42 AM
List:com.mysql.lists.java

On Tue, 2004-10-19 at 10:23 -0700, Jim Tyrrell wrote:

Mark et al,

I was reading last night in the newly arrived JDJ about JDBC. Paraphrasing a comment the writer made.

You had better explicitly close all your JDBC objects and not count on the Connection.close() method to also cascade up the chain to all your ResultSet, Statement, and PreparedStatement objects etc.

Jim,

This behavior is _required_ by the JDBC spec (and actually tested for in the compliance testsuite).

Connector/J will close all outstanding statements when you call Connection.close(), which in turn will call .close() on all outstanding result sets. (Take a look at Connection.realClose() and Connection.closeAllOpenStatements() if you don't believe me ;)

Where the author got this wrong (in my opinion), is that it is better if _you_ control the timing of the .close() calls, as in many cases each instance holds both client and server-side resources, which will cause performance issues if held on to for longer than they need to be (for example waiting for a finally block or other code to call Connection.close()).

However, if you are using a connection pool, you will want to check that the authors of the connection pool implemented their wrappers correctly to do the same thing (which again is required by the JDBC spec), as the connection pooling code isn't going to call Connection.close() on your physical connection until the pool is done with it.

Regards,

-Mark

See you at MySQL ComCon November 8-10! mysqlcomconeurope.com