ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Henricksen" <T...@A-t-g.com>
Subject RE: javaTypes and jdbcTypes in result maps
Date Fri, 27 Jul 2007 13:50:48 GMT
Jeff thanks for your response.  I just wanted to pass along some
follow-up from this co-worker.  They also noticed when running the same
query 100 times that without the types in the resultMap that it was
using more memory than with types.   Would iBatis have to instantiate
the objects to perform reflection on them? 

 

Thanks,

Tom

 

-----Original Message-----
From: Jeff Butler [mailto:jeffgbutler@gmail.com] 
Sent: Thursday, July 26, 2007 10:14 PM
To: user-java@ibatis.apache.org
Subject: Re: javaTypes and jdbcTypes in result maps

 

I did a fairly extensive test on this a year or so ago.  I found no
discernable performance difference either way.

 

As with all performance claims - your milage may vary.  It's best to try
it out in your environment to verify.

 

Jeff Butler



 

On 7/26/07, Tom Henricksen <TomH@a-t-g.com> wrote: 

A co-worker who uses the .Net version of iBatis mentioned that it is
strongly suggested to add javaTypes and jdbcTypes in resultMaps.  I
presume this is the same for Java? 

 

This:

<result property="provider.rowVersion" column="H_PRVDRID" jdbcType="int"
javaType="java.lang.Integer" /> 

 

instead of this:

<result property="provider.rowVersion" column="H_PRVDRID" />

 

They said that doing this in Java they noticed a faster initial response
than without.  I imagine the reflection used to determine the types is
time consuming.  Then after that they run the same.  I presume the types
are cached somehow?  Also how long does it cache?  Is that determined on
available memory or some other setting? 

 

http://www.nabble.com/When-to-use-jdbcType-or-javaType-tf2048046.html#a5
748022

 

According to this they may help performance and are useful in
resultMaps, correct?

 

 

Thanks,

 

Tom Henricksen 
Consultant
Advanced Technologies Group, Inc.

 


Mime
View raw message