Hi, looks like the pdf in svn is outdated. Please use the open office source instead (http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-2/ibatis-2-docs/en/iBATIS-SqlMaps-2_en.sxw).
I've opened a Jira Issue to address this: https://issues.apache.org/jira/browse/IBATIS-578 btw: statementCachingEnabled is set to true by default, so if you didn't disable it it should be already on Regards Kai --- Original Nachricht --- Absender: M. Goodell Datum: 01.02.2009 01:44 > I downloaded this documentation from the website. I am assuming since it's > the only Developers Guide available on the website that it was the latest > version. Am I mistaken? Where can I get the latest version of the docs? > > -----Original Message----- > From: Chema [mailto:demablo...@gmail.com] > Sent: Saturday, January 31, 2009 2:18 PM > To: user-java@ibatis.apache.org > Subject: Re: SQL-Map / CDATA Performance Issue > > > Yes, yours is old. > > Mine is dated on November 30, 2006 (2.3.x ) > > > > > 2009/1/31 M. Goodell <mggl...@comcast.net>: >> Thanks for your help. I do not see a reference to statementCaching in my >> version of the docs. >> >> See: >> > http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-2/ibatis-2-docs/en/ >> iBATIS-SqlMaps-2_en.pdf >> >> Is there more recent docs available other than the ones I have? >> >> -----Original Message----- >> From: Chema [mailto:demablo...@gmail.com] >> Sent: Saturday, January 31, 2009 1:54 PM >> To: user-java@ibatis.apache.org >> Subject: Re: SQL-Map / CDATA Performance Issue >> >> >> About docs: >> >> statementCachingEnabled (iBATIS versions 2.3.0 and later) >> With this setting enabled, iBATIS will maintain a local cache of >> prepared statements. This can lead to significant performance >> improvements. >> Example: statementCachingEnabled="true" >> Default: true (enabled) >> >> I asked you this question because: >> >> - I can understand that formatted XML could be parsed slower, but in >> millis terms >> - I guess that iBatis builds your query as a prepared statement and, >> if prepared statements cache is working fine, your query should be >> cached, so >> - I think that althought you execute it 10.000 times, XML is parsed >> just one time. But this conclusion is only based on how I think >> prepared statements caching works. But I can be wrong :-) >> >> >> >> 2009/1/31 M. Goodell <mggl...@comcast.net>: >>> >>> Version: ibatis-2.3.4.726 >>> >>> Not using statement caching as far as I know. >>> >>> Could you please provide a brief example of turning on statement caching? >> I >>> have read without it there is a performance hit. >>> >>> Thanks! >>> >>> M. Goodell >>> >>> -----Original Message----- >>> From: Chema [mailto:demablo...@gmail.com] >>> Sent: Saturday, January 31, 2009 1:12 PM >>> To: user-java@ibatis.apache.org >>> Subject: Re: SQL-Map / CDATA Performance Issue >>> >>> >>> What version are you using ? >>> Do you have statement caching enabled ? >>> >>> >>> 2009/1/31 M. Goodell <mggl...@comcast.net>: >>>> Looking further into this it seems to have little to do with the CDATA >> tag >>>> but the formatting of the SQL statement. The more formatting applied to >>> the >>>> SQL statement, the slower the performance. >>>> >>>> Format A is much slower than Format A >>>> >>>> (Format A) >>>> INSERT INTO >>>> people ( >>>> last_name, >>>> first_name, >>>> age >>>> ) VALUES ( >>>> #lastName#, >>>> #firstName#, >>>> #age#); >>>> >>>> (Format B) >>>> INSERT INTO people (last_name,first_name,age) VALUES >>>> (#lastName#,#firstName#,#age#); >>>> >>>> -----Original Message----- >>>> From: M. Goodell [mailto:mggl...@comcast.net] >>>> Sent: Saturday, January 31, 2009 12:52 PM >>>> To: Chema; user-java@ibatis.apache.org; mggl...@comcast.net >>>> Subject: RE: SQL-Map / CDATA Performance Issue >>>> >>>> >>>> Here is some more information: >>>> >>>> 1.) Using (Format A) and inserting 10,000 records this takes roughly >> 12-15 >>>> seconds. >>>> >>>> (Format A) >>>> <![CDATA[ >>>> INSERT INTO people ( >>>> last_name, >>>> first_name, >>>> age >>>> ) VALUES ( >>>> #lastName#, >>>> #firstName#, >>>> #age# >>>> ); >>>> ]]> >>>> >>>> 2.) Using (Format B) and inserting 10,000 records this takes roughly 7-8 >>>> seconds. >>>> >>>> (Format B) >>>> INSERT INTO people ( >>>> last_name, >>>> first_name, >>>> age >>>> ) VALUES ( >>>> #lastName#, >>>> #firstName#, >>>> #age# >>>> ); >>>> >>>> 3.) Using (Format C) and inserting 10,000 records this takes roughly 3-4 >>>> seconds. >>>> >>>> (Format C) >>>> INSERT INTO people (last_name, first_name, age) VALUES >>>> (#lastName#,#firstName#,#age#); >>>> >>>> Again, thanks for any help. >>>> >>>> -----Original Message----- >>>> From: Chema [mailto:demablo...@gmail.com] >>>> Sent: Saturday, January 31, 2009 12:24 PM >>>> To: user-java@ibatis.apache.org; mggl...@comcast.net >>>> Subject: Re: SQL-Map / CDATA Performance Issue >>>> >>>> >>>> And without CDATA tag ? Same performance ? >>>> Indeed, I don't know why you use it for that query >>>> >>>> >>>> 2009/1/31 MGG List Subscription <mggl...@comcast.net>: >>>>> When I format the SQL within my insert element like Example 1.0 and > time >>>>> several application calls the performance is degraded *substantially*. >>>>> However, if I format the SQL as shown in Example 1.1 the performance >>>>> improves dramatically. >>>>> >>>>> It seems the larger the SQL statement and the more "pretty" formatting >>>> that >>>>> is applied to the embedded SQL statement causes the performance to >>>> degrade. >>>>> I have read the manual sections on applying the CDATA XML tag to the > SQL >>>> but >>>>> it seems to not make a difference unlsess the SQL is compacted on to > one >>>>> line. >>>>> >>>>> Thank you in advance for any help! >>>>> >>>>> Example 1.0: >>>>> >>>>> <insert id="insertPerson" parameterClass="springibatis.Person"> >>>>> <![CDATA[ >>>>> INSERT INTO people ( >>>>> last_name, >>>>> first_name, >>>>> age >>>>> ) VALUES ( >>>>> #lastName#, >>>>> #firstName#, >>>>> #age# >>>>> ); >>>>> ]]> >>>>> </insert> >>>>> >>>>> >>>>> Example 1.1: >>>>> >>>>> <insert id="insertPerson" parameterClass="springibatis.Person"> >>>>> <![CDATA[ >>>>> INSERT INTO people (last_name, first_name, age) VALUES >>> (#lastName#, >>>>> #firstName#, #age#); >>>>> ]]> >>>>> </insert> >>>>> No virus found in this outgoing message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: >>> 01/30/09 >>>>> 17:31:00 >>>>> >>>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: >> 01/30/09 >>>> 17:31:00 >>>> >>>> No virus found in this outgoing message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: >> 01/30/09 >>>> 17:31:00 >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: >> 01/30/09 >>>> 17:31:00 >>>> >>>> No virus found in this outgoing message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: >> 01/30/09 >>>> 17:31:00 >>>> >>>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: > 01/30/09 >>> 17:31:00 >>> >>> No virus found in this outgoing message. >>> Checked by AVG - www.avg.com >>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: > 01/30/09 >>> 17:31:00 >>> >>> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> No virus found in this outgoing message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 > 17:31:00 > > No virus found in this outgoing message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 > 17:31:00 > >
