[jbosscache-commits] JBoss Cache SVN: r8319 - enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US.

jbosscache-commits at lists.jboss.org jbosscache-commits at lists.jboss.org
Thu Dec 10 00:36:25 EST 2009


Author: laubai
Date: 2009-12-10 00:36:24 -0500 (Thu, 10 Dec 2009)
New Revision: 8319

Modified:
   enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml
   enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml
   enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml
   enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml
   enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml
Log:
Added second part of changes for JBPAPP-2964.

Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml
===================================================================
--- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml	2009-12-10 05:35:51 UTC (rev 8318)
+++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml	2009-12-10 05:36:24 UTC (rev 8319)
@@ -169,7 +169,7 @@
            </para>
            <para>
               In addition to being visitable, commands are also replicable.  The JBoss Cache marshallers know how to
-              efficiently marshall commands and invoke them on remote cache instances using an internal RPC mechanism
+              efficiently marshal commands and invoke them on remote cache instances using an internal RPC mechanism
               based on JGroups.
            </para>
         </section>
@@ -184,13 +184,11 @@
             which sits at the start of the interceptor chain.
          </para>
          <para>
-            <literal>InvocationContext</literal>
-            , as its name implies, holds contextual information associated with a single cache
+            <literal>InvocationContext</literal>, as its name implies, holds contextual information associated with a single cache
             method invocation. Contextual information includes associated
             <literal>javax.transaction.Transaction</literal>
             or
-            <literal>org.jboss.cache.transaction.GlobalTransaction</literal>
-            ,
+            <literal>org.jboss.cache.transaction.GlobalTransaction</literal>,
             method invocation origin (
             <literal>InvocationContext.isOriginLocal()</literal>
             ) as well as
@@ -240,13 +238,11 @@
             in delegating classes, such as
             <literal>SingletonStoreCacheLoader</literal>
             or
-            <literal>AsyncCacheLoader</literal>
-            ,
+            <literal>AsyncCacheLoader</literal>,
             or may add the
             <literal>CacheLoader</literal>
             to a chain using the
-            <literal>ChainingCacheLoader</literal>
-            .
+            <literal>ChainingCacheLoader</literal>.
          </para>
       </section>
 

Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml
===================================================================
--- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml	2009-12-10 05:35:51 UTC (rev 8318)
+++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml	2009-12-10 05:36:24 UTC (rev 8319)
@@ -141,7 +141,7 @@
             a chain. The impact is that the cache will look at all of the cache
             loaders in the order they've been configured, until it finds a valid,
             non-null element of data. When performing writes, all cache loaders are
-            written to (except if the
+            written to, except if the
             <literal>ignoreModifications</literal>
             element has been set to
             <literal>true</literal>
@@ -190,8 +190,7 @@
             whereas a database implementation might define the database URL, name
             and password to establish a database connection. This configuration is
             passed to the cache loader implementation via
-            <literal>CacheLoader.setConfig(Properties)</literal>
-            . Note that
+            <literal>CacheLoader.setConfig(Properties)</literal>. Note that
             backspaces may have to be escaped.
         </para>
 
@@ -214,7 +213,6 @@
             else. Anything else is loaded lazily when accessed. Preloading makes
             sense when one anticipates using elements under a given subtree
             frequently.
-            .
         </para>
 
         <para>
@@ -243,22 +241,20 @@
             <literal>async</literal>
             element
             defaults to
-            <literal>false</literal>
-            .
+            <literal>false</literal>.
         </para>
 
-        <para>
-            <emphasis role="bold">Note on using the
-                <literal>async</literal>
-                element:
-            </emphasis>
+        <note>
+          <title>Note on using the <literal>async</literal> element</title>
+          <para>
             there is always the possibility of dirty reads since
             all writes are performed asynchronously, and it is thus impossible to
             guarantee when (and even if) a write succeeds. This needs to be kept in
             mind when setting the
             <literal>async</literal>
             element to true.
-        </para>
+          </para>
+        </note>
 
         <para>
             <literal>ignoreModifications</literal>
@@ -271,10 +267,8 @@
             used by all servers in
             the network. This feature allows you to write to the 'local' file cache
             loader but not the shared
-            <literal>JDBCCacheLoader</literal>
-            . This property defaults to
-            <literal>false</literal>
-            , so writes are propagated to all cache loaders
+            <literal>JDBCCacheLoader</literal>. This property defaults to
+            <literal>false</literal>, so writes are propagated to all cache loaders
             configured.
         </para>
 
@@ -357,10 +351,8 @@
                 <literal>class</literal>
                 element that specifies the implementation class that provides the
                 singleton store functionality. This class must extend
-                <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal>
-                , and if absent, it defaults to
-                <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal>
-                .
+                <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal>, and if absent, it defaults to
+                <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal>.
             </para>
 
             <para>
@@ -395,8 +387,7 @@
                 <literal>true</literal>
                 if each node's cache loader is configured with a different
                 location. Default value is
-                <literal>true</literal>
-                .
+                <literal>true</literal>.
             </para>
 
             <para>
@@ -412,13 +403,10 @@
                 if exceeded. Default value is 20000.
             </para>
 
-            <para>
-                <emphasis role="bold">Note on using the
-                    <literal>singletonStore</literal>
-                    element:
-                </emphasis>
-                setting
-                up a cache loader as a singleton and using cache passivation (via
+            <note>
+                <title>Note on using the <literal>singletonStore</literal> element</title>
+              <para>
+                Setting up a cache loader as a singleton and using cache passivation (via
                 evictions) can lead to undesired effects. If a node is to be passivated
                 as a result of an eviction, while the cluster is in the process of
                 electing a new coordinator, the data will be lost. This is because no
@@ -426,7 +414,8 @@
                 the cluster will store the passivated node. A new coordinator is elected
                 in the cluster when either, the coordinator leaves the cluster, the
                 coordinator crashes or stops responding.
-            </para>
+              </para>
+            </note>
         </section>
 
     </section>
@@ -447,7 +436,7 @@
                 configuration element
                 contains a
                 <literal>location</literal>
-                property, which maps to a directory to be used as a persistent store.
+                property, which maps to a directory to be used as a persistent store
                 (e.g.,
                 <literal>location=/tmp/myDataStore</literal>
                 ). Used mainly for testing and not recommended for production use.
@@ -501,21 +490,16 @@
 
                 <listitem>
                     <para>
-                        <literal>BdbjeCacheLoader</literal>
-                        , which is a cache loader implementation based on the Oracle/Sleepycat's
-                        <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition
-                        </ulink>
-                        .
+                        <literal>BdbjeCacheLoader</literal>, which is a cache loader implementation based on the Oracle/Sleepycat's
+                        <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition</ulink>.
                     </para>
                 </listitem>
 
                 <listitem>
                     <para>
-                        <literal>JdbmCacheLoader</literal>
-                        , which is a cache loader
+                        <literal>JdbmCacheLoader</literal>, which is a cache loader
                         implementation based on the
-                        <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink>
-                        , a fast and free alternative to
+                        <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink>, a fast and free alternative to
                         BerkeleyDB.
                     </para>
                 </listitem>
@@ -524,7 +508,7 @@
             <para>Note that the BerkeleyDB implementation is much more efficient than
                 the filesystem-based implementation, and provides transactional
                 guarantees, but requires a commercial license if distributed with an
-                application (see http://www.oracle.com/database/berkeley-db/index.html for
+                application (see <ulink url="http://www.oracle.com/database/berkeley-db/index.html">http://www.oracle.com/database/berkeley-db/index.html</ulink> for
                 details).
             </para>
 
@@ -594,7 +578,10 @@
             <para>
                 <literal>Fqn</literal>s are stored as strings. Node content is stored
                 as a BLOB.
-                <emphasis>WARNING:</emphasis>
+            </para>
+            
+            <warning>
+              <para>
                 JBoss Cache does not impose any
                 limitations on the types of objects used in
                 <literal>Fqn</literal>
@@ -602,8 +589,7 @@
                 cache loader requires
                 <literal>Fqn</literal>
                 to contain only objects of type
-                <literal>java.lang.String</literal>
-                . Another limitation for
+                <literal>java.lang.String</literal>. Another limitation for
                 <literal>Fqn</literal>
                 is its
                 length. Since
@@ -612,7 +598,8 @@
                 <literal>VARCHAR</literal>
                 which can store text values up to some
                 maximum length determined by the database in use.
-            </para>
+              </para>
+            </warning>
 
             <para>See
                 <ulink url="http://www.jboss.org/community/docs/DOC-10864">this wiki page</ulink>
@@ -832,7 +819,7 @@
   </loaders>
 ]]></programlisting>
 
-                    <para>Cconfiguration example for a cache loader using c3p0 JDBC connection pooling:</para>
+                    <para>Configuration example for a cache loader using c3p0 JDBC connection pooling:</para>
 
                     <programlisting role="XML"><![CDATA[
  <loaders passivation="false" shared="false">
@@ -982,7 +969,7 @@
                         <listitem><para>
                             <literal>cache.s3.secure</literal>
                             -
-                            The default is<literal>false</literal>:
+                            The default is <literal>false</literal>:
                             Traffic is sent unencrypted over the public Internet.
                             Set to
                             <literal>true</literal>
@@ -996,7 +983,7 @@
                             Name of the bucket to store data.
                             For different caches using the same access key, use a different bucket name.
                             Read the S3 documentation on the definition of a bucket.
-                            The default value is<literal>jboss-cache</literal>.</para>
+                            The default value is <literal>jboss-cache</literal>.</para>
                         </listitem>
 
                         <listitem><para>
@@ -1005,13 +992,13 @@
                             One of<literal>PATH</literal>,<literal>SUBDOMAIN</literal>, or
                             <literal>VANITY</literal>.
                             Read the S3 documentation on the use of calling domains.
-                            The default value is<literal>SUBDOMAIN</literal>.</para>
+                            The default value is <literal>SUBDOMAIN</literal>.</para>
                         </listitem>
 
                         <listitem><para>
                             <literal>cache.s3.optimize</literal>
                             -
-                            The default is<literal>false</literal>.
+                            The default is <literal>false</literal>.
                             If true,
                             <literal>put(Map)</literal>
                             operations
@@ -1342,11 +1329,11 @@
                 the FileCacheLoader), or a shared database. Because both nodes access
                 the same store, they don't necessarily need state transfer on
                 startup.
-                <footnote>
+                <note>
                     <para>Of course they can enable state transfer, if they want to
                         have a warm or hot cache after startup.
                     </para>
-                </footnote>
+                </note>
                 Rather, the
                 <literal>FetchInMemoryState</literal>
                 attribute could be set to false, resulting in a 'cold' cache, that
@@ -1427,7 +1414,7 @@
                 cache are (a) replicated across the cluster and (b) persisted using
                 the cache loader. This means that all datastores have exactly the same
                 state. When replicating changes synchronously and in a transaction,
-                the two phase commit protocol takes care that all modifications are
+                the two-phase commit protocol takes care that all modifications are
                 replicated and persisted in each datastore, or none is replicated and
                 persisted (atomic updates).
             </para>

Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml
===================================================================
--- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml	2009-12-10 05:35:51 UTC (rev 8318)
+++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml	2009-12-10 05:36:24 UTC (rev 8319)
@@ -161,12 +161,14 @@
             <literal>/a</literal>
             and<literal>/a/b</literal>.
          </para>
-         <para>
-            N.B. when adding attributes to a resident node, e.g.
-            <literal>cache.put("/a", "k", "v")</literal>
-            in the above example, it would make sense to mark the nodes
-            as non-resident again and let them be considered for eviction..
-         </para>
+         <note>
+          <para>
+              When adding attributes to a resident node, e.g.
+              <literal>cache.put("/a", "k", "v")</literal>
+              in the above example, it would make sense to mark the nodes
+              as non-resident again and let them be considered for eviction.
+          </para>
+        </note>
       </section>
    </section>
 

Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml
===================================================================
--- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml	2009-12-10 05:35:51 UTC (rev 8318)
+++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml	2009-12-10 05:36:24 UTC (rev 8319)
@@ -75,9 +75,8 @@
                asynchronous or synchronous mode, JBoss Cache will use either a single
                phase or
                <ulink
-                     url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two phase
-                  commit
-               </ulink>
+                     url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two-phase
+                  commit</ulink>
                protocol, respectively.
             </para>
 
@@ -179,8 +178,7 @@
                   which contains the logic used to
                   select buddies in a network. JBoss Cache currently ships with a
                   single implementation,
-                  <literal>NextMemberBuddyLocator</literal>
-                  ,
+                  <literal>NextMemberBuddyLocator</literal>,
                   which is used as a default if no implementation is provided. The
                   <literal>NextMemberBuddyLocator</literal>
                   selects the next member in
@@ -226,8 +224,7 @@
                <title>BuddyPools</title>
 
                <para>Also known as
-                  <emphasis>replication groups</emphasis>
-                  , a buddy
+                  <emphasis>replication groups</emphasis>, a buddy
                   pool is an optional construct where each instance in a cluster may
                   be configured with a buddy pool name. Think of this as an 'exclusive
                   club membership' where when selecting buddies,
@@ -489,8 +486,7 @@
                         <literal>InactiveOnStartup</literal>
                         property
                         is
-                        <literal>true</literal>
-                        . This property is used in
+                        <literal>true</literal>. This property is used in
                         conjunction with region-based marshalling.
                      </para>
                   </listitem>
@@ -547,10 +543,8 @@
                   the
                   <literal>InactiveOnStartup</literal>
                   property is set to
-                  <literal>false</literal>
-                  . If it is
-                  <literal>true</literal>
-                  , state
+                  <literal>false</literal>. If it is
+                  <literal>true</literal>, state
                   transfer amongst the buddies only occurs when the application
                   activates the region on the various members of the group.
                </para>
@@ -586,8 +580,7 @@
                <para>"In-memory" state transfer is enabled by setting the cache's
                   <literal>FetchInMemoryState</literal>
                   configuration attribute to
-                  <literal>true</literal>
-                  .
+                  <literal>true</literal>.
                </para>
             </listitem>
 
@@ -603,8 +596,7 @@
                   loader's
                   <literal>fetchPersistentState</literal>
                   attribute to
-                  <literal>true</literal>
-                  . If multiple cache loaders are configured
+                  <literal>true</literal>. If multiple cache loaders are configured
                   in a chain, only one can have this property set to true; otherwise
                   you will get an exception at startup.
                </para>
@@ -616,8 +608,7 @@
                   cache loader has
                   <literal>fetchPersistentState</literal>
                   set to
-                  <literal>true</literal>
-                  .
+                  <literal>true</literal>.
                </para>
             </listitem>
          </orderedlist>

Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml
===================================================================
--- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml	2009-12-10 05:35:51 UTC (rev 8318)
+++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml	2009-12-10 05:36:24 UTC (rev 8319)
@@ -230,7 +230,7 @@
          <literal>TransactionManager</literal>.
       </para>
 
-      <para>When the transaction commits, we initiate either a one- two-phase commit
+      <para>When the transaction commits, we initiate either a one-phase or two-phase commit
          protocol. See <xref linkend="replication.tx" /> for details.
       </para>
 



More information about the jbosscache-commits mailing list