[jboss-cvs] JBossAS SVN: r103394 - projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US.

[jboss-cvs-commits at lists.jboss.org]

Author: laubai
Date: 2010-04-01 02:43:47 -0400 (Thu, 01 Apr 2010)
New Revision: 103394

Modified:
   projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
   projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Transactions.xml
Log:
JBPAPP-2649 Corrections to JBoss Cache chapter.

Modified: projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml
===================================================================
--- projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml	2010-04-01 06:33:58 UTC (rev 103393)
+++ projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache.xml	2010-04-01 06:43:47 UTC (rev 103394)
@@ -142,7 +142,7 @@
 		    you look at the standard configurations the Enterprise Application Platform ships; they include 
             all the major elements. The types and properties of the various java 
             beans that make up a JBoss Cache configuration can be seen in the 
-            JBoss Cache javadocs.  Here is a fairly complete example:</para>
+            JBoss Cache Javadocs.  Here is a fairly complete example:</para>
             
             <programlisting><![CDATA[
 <bean name="StandardSFSBCacheConfig" class="org.jboss.cache.config.Configuration">
@@ -285,7 +285,7 @@
             the cache instance sends a message to its peers notifying them of the
             change(s) and before returning waits for them to acknowledge that 
             they have applied the same changes. If the changes are made as part
-            of a JTA transaction, this is done as part of a 2 phase-commit 
+            of a JTA transaction, this is done as part of a two-phase commit 
             process during transaction commit.  Any locks are held until this
             acknowledgment is received. Waiting for acknowledgement from
             all nodes adds delays, but it ensures consistency around the cluster.
@@ -430,7 +430,7 @@
          <para>There are three choices for <literal>nodeLockingScheme</literal>:
          <itemizedlist>
          <listitem>
-         <para><emphasis role="bold">MVCC</emphasis> or multi-versioned concurrency 
+         <para><emphasis role="bold">MVCC</emphasis> or multi-version concurrency 
          control, is a locking scheme commonly used by modern database implementations 
          to control fast, safe concurrent access to shared data. JBoss Cache 3.x uses 
          an innovative implementation of MVCC as the default locking scheme. MVCC 
@@ -965,11 +965,15 @@
      <section id="jbosscache-custom-deployment-service.xml">
        <title>Deployment Via a <literal>-service.xml</literal> File</title>
        
-       <para>As in JBoss 4.x, you can also deploy a JBoss Cache instance as
+       <para>As in JBoss Enterprise Application Platform 4.x, 
+        you can also deploy a JBoss Cache instance as
        an MBean service via a <literal>-service.xml</literal> file.
-       The primary difference from JBoss 4.x is the value of the <literal>code</literal>
-       attribute in the <literal>mbean</literal> element. In JBoss 4.x, this
-       was <literal>org.jboss.cache.TreeCache</literal>; in JBoss 5.x it is
+       The primary difference from JBoss Enterprise Application Platform
+       4.x is the value of the <literal>code</literal>
+       attribute in the <literal>mbean</literal> element. In 
+       JBoss Enterprise Application Platform 4.x, this
+       was <literal>org.jboss.cache.TreeCache</literal>; in
+       JBoss Enterprise Application Platform 5.x it is
        <literal>org.jboss.cache.jmx.CacheJmxWrapper</literal>. Here's an
        example:</para>
        
@@ -977,7 +981,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 
 <server>
-  <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" 
+  <mbean code="org.jboss.cache.jmx.CacfheJmxWrapper" 
          name="foo:service=ExampleCacheJmxWrapper">
       
      <attribute name="TransactionManagerLookupClass">

Modified: projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Transactions.xml	2010-04-01 06:33:58 UTC (rev 103393)
+++ projects/docs/enterprise/5.0.1/Administration_And_Configuration_Guide/en-US/Transactions.xml	2010-04-01 06:43:47 UTC (rev 103394)
@@ -259,7 +259,7 @@
         <section>
                 <title>Last Resource Commit Optimization (LRCO)</title>
                 <para>Although the XA transaction protocol is designed to provide ACID properties by
-                        using a two phase commit protocol, it is recognized that this is not
+                        using a two-phase commit protocol, it is recognized that this is not
                         possible in all circumstances. In particular, it is occasionally necessary
                         to have a resource manager that is not XA aware participate in the
                         transaction. This is often the case with data stores that can't or won't