The tests that I've done aren't as extensive or well documented as the ones in the article but they were done in a real-world application on a real-world database. I could see no performance gain by using either the Statement or the PreparedStatement. Both results were about the same as far as I could tell.
--- "Cote, Robert" <[EMAIL PROTECTED]> wrote: > That's an eye-opening article, and the book it's taken from (Java > Programming with Oracle JDBC - O'Reilly) has received good reviews. > But > while the numbers were generated using objective techniques, they > don't > represent real-world conditions. Inserting 1000 records at a time > isn't a > common end-user task, and there's nothing in the example that > suggests the > database was 'full' in terms of run-time memory processes - SGA, > caches, > etc. - when the metrics were gathered. I'd like to see relative > performance > metrics on a system with a few hundred users that hasn't been > cycled for a > couple months. > > > > -----Original Message----- > From: Matveyenko, Wade [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 5:49 PM > To: JDJList > Subject: [jdjlist] RE: PreparedStatement > > > > In addition, PreparedStatement versus Statement depends on your > database and > driver. In the case of Oracle, this reference > http://www.onjava.com/lpt/a//onjava/excerpt/oraclejdbc_19/index.html > <http://www.onjava.com/lpt/a//onjava/excerpt/oraclejdbc_19/index.html> > states that a you have to do at least 65 iterations of a > PreparedStatement > to overcome the initial overhead and make it more performant than a > Statement. > > Wade Matveyenko > Advisory Engineer > The Cobalt Group, Inc. > 2200 First Avenue South > Seattle, WA 98134 > [EMAIL PROTECTED] > > -----Original Message----- > From: Barr, Dan [ mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > Sent: Friday, May 10, 2002 2:33 PM > To: JDJList > Subject: [jdjlist] RE: PreparedStatement > > > Maybe I misunderstood, but I thought the savings came in database > parse > time. So, if the PreparedStatement was invalidated, it might still > be in the > > database cache and could be reused (even by another connection in > the pool) > by the database without reparsing. > > > -----Original Message----- > > From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > > Sent: Friday, May 10, 2002 5:01 PM > > To: JDJList > > Subject: [jdjlist] RE: PreparedStatement > > > > > > There is a caveat with PreparedStatements and Connection Pools. > > PreparedStatements ofen cannot be used across transactions if > > a Connection > > Pool is involved. I haven't looked recently, but Weblogic > > used to invalidate > > a PreparedStatement on transaction close. > > > > This does not suggest that you shouldn't use > > PreparedStatements. I have > > found that they are better at handling type conversions. With > > a statement > > you have to handle making everything a string. With a > > PreparedStatement, the > > driver handles binding of the types. > > > > Brian Dudley > > > > > > -----Original Message----- > > From: Ramakrishna Kuppa > > To: JDJList > > Sent: 5/10/02 4:47 PM > > Subject: [jdjlist] RE: PreparedStatement > > > > I think we are talking of two different things here: Whether > > you create > > a connection OR pick one from pool, by using the > > PreparedStatement, you > > avoid repeated compilation of the SQL statement. > > > > A good explanation on this is available at > > http://www.theserverside.com/resources/article.jsp?l=Prepared- > <http://www.theserverside.com/resources/article.jsp?l=Prepared-> > Statments > < > http://www.theserverside.com/resources/article.jsp?l=Prepared-Statments > <http://www.theserverside.com/resources/article.jsp?l=Prepared-Statments> > > > > > - Ramakrishna > > -----Original Message----- > From: Jason Kilgrow [ mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > ] > Sent: Friday, May 10, 2002 1:37 PM > To: JDJList > Subject: [jdjlist] PreparedStatement > > What would be the advantage of using a PreparedStatement rather > than > a Statement if I'm using connection pooling? > > I know that the PreparedStatement is precompiled but in my > environment, I typically get a connection from the pool, execute my > > query, process my results, and then free the connection all in one > method. So, if I were using a PreparedStatement, wouldn't the query > > in the PreparedStatement need to be compiled every time the method > is > called anyway? > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Mother's Day is May 12th! > http://shopping.yahoo.com <http://shopping.yahoo.com> < > http://shopping.yahoo.com <http://shopping.yahoo.com> > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > <http://www.sys-con.com/java/list.cfm> > > < http://www.sys-con.com/java/list.cfm > <http://www.sys-con.com/java/list.cfm> > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > <http://www.sys-con.com/java/list.cfm> > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > <http://www.sys-con.com/java/list.cfm> > > > > > The contents of this e-mail are intended for the named addressee > only. It > contains information that may be confidential. Unless you are the > named > addressee or an authorized designee, you may not copy or use it, or > disclose > > it to anyone else. If you received it in error please notify us > immediately > and then destroy it. > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > <http://www.sys-con.com/java/list.cfm> > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > > > > To change your membership options, refer to: > http://www.sys-con.com/java/list.cfm > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To change your membership options, refer to: http://www.sys-con.com/java/list.cfm
