You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Jeff Butler <je...@gmail.com> on 2006/10/05 20:36:24 UTC
Prepared Statement Caching in 2.2.1?
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
Re: Prepared Statement Caching in 2.2.1?
Posted by Clinton Begin <cl...@gmail.com>.
Weeee! At least we know it only blows up if logging is enabled... ;-)
I'll have a look.
Clinton
On 10/9/06, Jeff Butler <je...@gmail.com> wrote:
>
> Hi Clinton,
>
> It took me nearly forever to figure out what was different in my setup
> from the iBATIS build. I almost ended up fixing the problem, but I wanted
> to leave some of the fun for you! It ended up that I didn't need to commit
> any changes or new tests.
>
> Here's how to break it...
>
> 1. Go into .../test/log4j.properties and enable logging on
> java.sql.Connection (just uncomment the 11th line).
>
> 2. Run the build. You'll see two errors/failures. Both caused by
> "statement is closed" - the error I'm seeing in my test enviornment.
>
> Jeff Butler
>
>
>
>
> On 10/7/06, Clinton Begin <cl...@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
> >
>
>
Re: Prepared Statement Caching in 2.2.1?
Posted by Jeff Butler <je...@gmail.com>.
Hi Clinton,
It took me nearly forever to figure out what was different in my setup from
the iBATIS build. I almost ended up fixing the problem, but I wanted to
leave some of the fun for you! It ended up that I didn't need to commit any
changes or new tests.
Here's how to break it...
1. Go into .../test/log4j.properties and enable logging on
java.sql.Connection (just uncomment the 11th line).
2. Run the build. You'll see two errors/failures. Both caused by
"statement is closed" - the error I'm seeing in my test enviornment.
Jeff Butler
On 10/7/06, Clinton Begin <cl...@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
>
Re: Prepared Statement Caching in 2.2.1?
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@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
> > > >
> > > >
> > >
> > >
> >
>
Re: Prepared Statement Caching in 2.2.1?
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@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 <cl...@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
> > >
> > >
> >
> >
>
Re: Prepared Statement Caching in 2.2.1?
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@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 <je...@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
> >
> >
>
>
Re: Prepared Statement Caching in 2.2.1?
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@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
>
>