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 <
[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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
