ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Prepared Statement Caching in 2.2.1?
Date Sat, 07 Oct 2006 18:23:38 GMT
Cool.

I don't have my test in yet (don't have that PC with me right now), but I
think it has something to do with multiple selects in a resultMap.  Like
this...

<resultMap id="getCustomer" class="customer">
  <result property="id" column="CUST_ID"/>
  <result property="names" column="CUST_ID" select="getNames"/>
  <result property="phoneNumbers" column="CUST_ID"
select="getPhoneNumbers"/>
  <result property="addresses" column="CUST_ID" select="getAddresses"/>
</resultMap>

Maybe that is a clue?

Jeff Butler



On 10/7/06, Clinton Begin <clinton.begin@gmail.com> wrote:
>
> The cache is transaction scope only, so size will never be a problem
> (unless someone is literally using THOUSANDS of different statements in a
> single transaction with THOUSANDS of threads.
>
> Plus, arbitrarily expiring statements from the cache based on some size
> would probably kill the performance anyway, and trying to be smart about it
> would probably be too complex and would ultimately also kill performance.
> :-)  So cache size configuration is a no go.
>
> But disabling it completely is definitely an option.  Just a global
> setting will do.
>
> Cheers,
> Clinton
>
>
> On 10/7/06, Jeff Butler < jeffgbutler@gmail.com> wrote:
> >
> > Well that should finally put to rest the complaint that iBATIS is
> > hundreds of times slower then "pure" JDBC :)
> >
> > Seriously... I'll commit a test that will break the build later this
> > weekend.  Then maybe you can take a look at the problem.  Sound like a plan?
> >
> > Do you plan to offer a setting to turn this on/off?  And maybe to
> > control the size of the cache?  I'd prefer that personally.
> >
> > Jeff Butler
> >
> >
> >  On 10/7/06, Clinton Begin <clinton.begin@gmail.com > wrote:
> > >
> > > Both myself and another user found this change to make a significant
> > > performance difference (hundreds of times faster).
> > >
> > > This should work.  I'd be interested in learning more about what it
> > > broke.
> > >
> > > Cheers,
> > > Clinton
> > >
> > > On 10/5/06, Jeff Butler <jeffgbutler@gmail.com > wrote:
> > > >
> > > > I just discovered a test case that breaks with the new prepared
> > > > statement caching support.  I haven't taken the time to chase it down
yet.
> > > >
> > > > But it got me wondering if this is something we should turn off for
> > > > 2.2.1.  I turned it off in my test environment by changing the
> > > > method "SessionScope.hasPreparedStatementFor(String sql)" so that it
> > > > always return false.  Maybe there's a better way to disable it?
> > > >
> > > > IMO this seems like a risky thing to add in a maintenance release.
> > > > It also seems unneccessary - as most decent JDBC drivers
> > > > already support caching prepared statements automatically.
> > > >
> > > > Thoughts???
> > > > Jeff Butler
> > > >
> > > >
> > >
> > >
> >
>

Mime
View raw message