Author: roberto
Date: Wed Mar 29 19:55:33 2006
New Revision: 389985
URL: http://svn.apache.org/viewcvs?rev=389985&view=rev
Log:
IBATISNET-141 Updated for typo spotted by Noriyuki
Modified:
ibatis/trunk/cs/docs/dataMapperGuide/src/en/working.xml
Modified: ibatis/trunk/cs/docs/dataMapperGuide/src/en/working.xml
URL:
http://svn.apache.org/viewcvs/ibatis/trunk/cs/docs/dataMapperGuide/src/en/working.xml?rev=389985&r1=389984&r2=389985&view=diff
==============================================================================
--- ibatis/trunk/cs/docs/dataMapperGuide/src/en/working.xml (original)
+++ ibatis/trunk/cs/docs/dataMapperGuide/src/en/working.xml Wed Mar 29 19:55:33
2006
@@ -2508,7 +2508,7 @@
<result property="id" column="ORD_ID"/>
<result property="customerId" column="ORD_CST_ID"/>
...
- <result property="payments" column="<emphasis
role="blue">{itemId=ORD_ID, custId=ORD_CST_ID}</emphasis>"
+ <result property="payments" column="<emphasis
role="blue">itemId=ORD_ID, custId=ORD_CST_ID</emphasis>"
select="<emphasis role="blue">selectOrderPayments"</emphasis>/>
</resultMap>
<resultMaps>
@@ -2527,7 +2527,7 @@
they're in the same order as the parameters. For example:</para>
<informalexample>
- <programlisting><emphasis role="blue">{ORD_ID,
ORD_CST_ID}</emphasis></programlisting>
+ <programlisting><emphasis role="blue">ORD_ID,
ORD_CST_ID</emphasis></programlisting>
</informalexample>
<para>As usual, this is a slight performance gain with an impact on
@@ -3095,20 +3095,21 @@
</statement></programlisting>
</example>
- <sect2>
+ <sect2>
+
+
<title>Read-Only vs. Read/Write</title>
-
- The framework supports both read-only and read/write caches.
Read-only caches are shared among all users and therefore offer greater
performance benefit. However, objects read from a read-only cache should not
be modified. Instead, a new object should be read from the database (or a
read/write cache) for updating. On the other hand, if there is an intention to
use objects for retrieval and modification, a read/write cache is recommended
(i.e. required). To use a read-only cache, set readOnly="true" on the cache
model element. To use a read/write cache, set readOnly="false". The default
is read-only (true).
- </sect2>
+ The framework supports both read-only and read/write caches. Read-only
caches are shared among all users and therefore offer greater performance
benefit. However, objects read from a read-only cache should not be modified.
Instead, a new object should be read from the database (or a read/write cache)
for updating. On the other hand, if there is an intention to use objects for
retrieval and modification, a read/write cache is recommended (i.e. required).
To use a read-only cache, set readOnly="true" on the cache model element. To
use a read/write cache, set readOnly="false". The default is read-only (true).
+ </sect2>
+
+ <sect2>
+
- <sect2>
<title>Serializable Read/Write Caches</title>
-
- As you may agree, caching per-session as described above may
offer little benefit to global application performance. Another type of
read/write cache that can offer a performance benefit to the entire application
(i.e. not just per session) is a serializable read/write cache.
- This cache will return different instances (copies) of the
cached object to each session. Therefore each session can safely modify the
instance returned. Realize the difference in semantics here, usually you would
expect the same instance to be returned from a cache, but in this case you'll
get a different one.
- Also note that every object stored by a serializable cache must
be serializable. This means that you will have difficulty using both lazy
loading features combined with a serializable cache, because lazy proxies are
not serializable. The best way to figure out what combination of caching, lazy
loading and table joining is simply to try it out. To use a serializable
cache, set readOnly="false" and serialize="true". By default cache models are
read-only and non-serializable. Read-only caches will not be serialized
(there's no benefit).
- </sect2>
+
+ As you may agree, caching per-session as described above may offer
little benefit to global application performance. Another type of read/write
cache that can offer a performance benefit to the entire application (i.e. not
just per session) is a serializable read/write cache. This cache will return
different instances (copies) of the cached object to each session. Therefore
each session can safely modify the instance returned. Realize the difference in
semantics here, usually you would expect the same instance to be returned from
a cache, but in this case you'll get a different one. Also note that every
object stored by a serializable cache must be serializable. This means that you
will have difficulty using both lazy loading features combined with a
serializable cache, because lazy proxies are not serializable. The best way to
figure out what combination of caching, lazy loading and table joining is
simply to try it out. To use a serializable cache, set readOnly="fal
se" and serialize="true". By default cache models are read-only and
non-serializable. Read-only caches will not be serialized (there's no benefit).
+ </sect2>
<sect2>
<title>Cache Implementation</title>
