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 > >
