> 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:
demablogia <at> gmail.com]
> Sent: Saturday, January 31, 2009 2:18 PM
> To:
user-java <at> 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 <
mgglist <at> 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:
demablogia <at> gmail.com]
>> Sent: Saturday, January 31, 2009 1:54 PM
>> To:
user-java <at> 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 <
mgglist <at> 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:
demablogia <at> gmail.com]
>>> Sent: Saturday, January 31, 2009 1:12 PM
>>> To:
user-java <at> 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 <
mgglist <at> 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:
mgglist <at> comcast.net]
>>>> Sent: Saturday, January 31, 2009 12:52 PM
>>>> To: Chema;
user-java <at> ibatis.apache.org;
mgglist <at> 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:
demablogia <at> gmail.com]
>>>> Sent: Saturday, January 31, 2009 12:24 PM
>>>> To:
user-java <at> ibatis.apache.org;
mgglist <at> 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 <
mgglist <at> 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
>
>
RSS Feed