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:
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...
Maybe that is a clue?
Jeff Butler
On 10/7/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
The cache is transaction sc
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 any
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
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,
ClintonOn 10/5/06, Jeff Butler <[EMAIL PROTECTED]> wrote:
I just discovered a test case that bre
