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/20/2004 06:15:23 AM
List:com.mysql.lists.java

On Wed, 2004-10-20 at 00:57 -0700, Kevin A. Burton wrote:

Mark Matthews wrote:

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 ;)

FYI. I removed this functionality and compiled my own JDBC driver and I'd like to see an option to disable this support in the current driver.

I'm able to get about an 8x -> 10x performance update by parsing the JDBC resultset just-in-time when I need it.

Kevin,

I'm confused by what you mean when you say you're parsing it just-in- time. I know that you have written about this before, but I'm still confused as to what you're doing. I would be interested to hear about the concept, though.

This is common in most OR layers. They take all the rows... parse all the values... stick them into objects... then stick the objects into lists.

I bypass all of this and do lazy binding and only get values if they've never been parsed before. MUCH MUCH faster :)

The driver itself just returns a byte array and once the data has been sent to the client theres no need to close the result set ever.

Actually, there is, and it's to release resources on the client side.

I assume that with MySQL 4.1 and streaming results this will change but I'd need to re-investigate. It looks like the streaming results aren't even enabled by default in 4.1 but I might be wrong.

It will be even more important with MySQL-5.0, because closing the result set releases resources on the _server_ side as well.

-Mark

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