13 messages in com.mysql.lists.javaRe: Article in JDJ| From | Sent On | Attachments |
|---|---|---|
| Teemu Kuulasmaa | 19 Oct 2004 04:35 | |
| Mark Matthews | 19 Oct 2004 07:10 | |
| Jim Tyrrell | 19 Oct 2004 10:22 | |
| Mark Matthews | 19 Oct 2004 11:05 | |
| Kevin A. Burton | 20 Oct 2004 00:57 | |
| Kevin A. Burton | 20 Oct 2004 00:58 | |
| Teemu Kuulasmaa | 20 Oct 2004 05:06 | |
| Mark Matthews | 20 Oct 2004 06:15 | |
| Mark Matthews | 20 Oct 2004 06:19 | |
| Kevin A. Burton | 20 Oct 2004 11:26 | |
| Teemu Kuulasmaa | 20 Oct 2004 22:08 | |
| Youngho Cho | 27 Oct 2004 16:53 | |
| Youngho Cho | 28 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
-- Mark Matthews MySQL AB, Software Development Manager - Client Connectivity Office: +1 708 332 0507 www.mysql.com
See you at MySQL ComCon November 8-10! mysqlcomconeurope.com




