1) SessionScope: Added a map containing prepared statements keyed by SQL string. Added accessor/mutator methods for working with the prepared statements.
2) SqlExecutor: Created 6 methods: 2x prepareStatement, 2x prepareCall, closeStatement and cleanupBatch. Basically these methods are used in place of the Connection.xxx equivalents. It will check the cache on SessionScope first, then create statements if necessary. I'm not totally happy with the level of code duplication...but I'd rather do a cleanup refactoring exercise after we know it works.
3) TransactionManager: Simply a call to close cached statements if a user provided connection is in use.
4) RequestScope and BatchTest were mostly cosmetic. (my bad, I should not have committed both at once).
Sorry my commit message wasn't more helpful.
Cheers,
Clinton
On 10/7/06, Ron Grabowski <
[EMAIL PROTECTED]> wrote:
Could someone explain what the prepared statement cache changed? I found this revision:
http://svn.apache.org/viewvc?view=rev&revision=439701
but I'm not sure what I should be looking for...
----- Original Message ----
From: Clinton Begin <[EMAIL PROTECTED]>
To: dev@ibatis.apache.org
Sent: Saturday, October 7, 2006 12:58:45 PM
Subject: Re: Prepared Statement Caching in 2.2.1?
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 < [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
