[jboss-svn-commits] JBL Code SVN: r36959 - labs/jbosstm/trunk/docs/development_guide/en-US.

jboss-svn-commits at lists.jboss.org jboss-svn-commits at lists.jboss.org
Thu Apr 21 05:02:02 EDT 2011


Author: tomjenkinson
Date: 2011-04-21 05:02:02 -0400 (Thu, 21 Apr 2011)
New Revision: 36959

Modified:
   labs/jbosstm/trunk/docs/development_guide/en-US/General_Transaction_Issues.xml
   labs/jbosstm/trunk/docs/development_guide/en-US/The_Resource_Manager.xml
   labs/jbosstm/trunk/docs/development_guide/en-US/Transactions.xml
Log:
JBTM-820 use the product name instead of JBossTS

Modified: labs/jbosstm/trunk/docs/development_guide/en-US/General_Transaction_Issues.xml
===================================================================
--- labs/jbosstm/trunk/docs/development_guide/en-US/General_Transaction_Issues.xml	2011-04-21 08:39:14 UTC (rev 36958)
+++ labs/jbosstm/trunk/docs/development_guide/en-US/General_Transaction_Issues.xml	2011-04-21 09:02:02 UTC (rev 36959)
@@ -251,7 +251,7 @@
     </section>
     <section>
       <title>Transaction Logs</title>
-      <para>JBossTS supports a number of different transaction log implementations. They are
+      <para>&PRODUCT; supports a number of different transaction log implementations. They are
         outlined
         below.</para>
       <section>

Modified: labs/jbosstm/trunk/docs/development_guide/en-US/The_Resource_Manager.xml
===================================================================
--- labs/jbosstm/trunk/docs/development_guide/en-US/The_Resource_Manager.xml	2011-04-21 08:39:14 UTC (rev 36958)
+++ labs/jbosstm/trunk/docs/development_guide/en-US/The_Resource_Manager.xml	2011-04-21 09:02:02 UTC (rev 36959)
@@ -81,7 +81,7 @@
       <para>
         By default, whenever an <interfacename>XAResource</interfacename> object is registered with a JTA-compliant
         transaction service, there is no way to manipulate the order in which it is invoked during the two-phase commit
-        protocol, with respect to other <interfacename>XAResource</interfacename> objects. JBossTS, however, provides
+        protocol, with respect to other <interfacename>XAResource</interfacename> objects. &PRODUCT;, however, provides
         support for controlling the order via the two interfaces
         <interfacename>com.arjuna.ats.jta.resources.StartXAResource</interfacename> and
         <interfacename>com.arjuna.ats.jta.resources.EndXAResource</interfacename>. By inheriting your
@@ -103,7 +103,7 @@
         In order to use the LRCO, your <interfacename>XAResource</interfacename> implementation must extend the
         <interfacename>com.arjuna.ats.jta.resources.LastResourceCommitOptimisation</interfacename> marker interface. A
         marker interface is an interface which provides no methods. When
-        enlisting the resource via method <methodname>Transaction.enlistResource</methodname>, JBossTS ensures that only a single instance of this
+        enlisting the resource via method <methodname>Transaction.enlistResource</methodname>, &PRODUCT; ensures that only a single instance of this
         type of participant is used within each transaction. Your resource is driven last in the commit protocol,
         and no invocation of method <methodname>prepare</methodname> occurs.
       </para>
@@ -151,13 +151,13 @@
           </listitem>
         </itemizedlist>
         <para>
-          If neither of these options is viable, JBossTS support enlisting multiple
+          If neither of these options is viable, &PRODUCT; support enlisting multiple
           one-phase aware resources within the same transaction, using LRCO, which is discussed in the
           <citetitle>ArjunaCore Development Guide</citetitle> in detail.
         </para>
         <warning>
           <para>
-            Even when this support is enabled, JBossTS issues a warning when it detects that the option has been
+            Even when this support is enabled, &PRODUCT; issues a warning when it detects that the option has been
             enabled: <literal>You have chosen to enable multiple last resources in the transaction manager. This is
             transactionally unsafe and should not be relied upon.</literal> Another warning is issued when multiple
             one-phase aware resources are enlisted within a transaction: <literal>This is transactionally unsafe and
@@ -166,7 +166,7 @@
           <para>
             To override the above-mentioned warning at runtime, set the
             <varname>CoreEnvironmentBean.disableMultipleLastResourcesWarning</varname> property to
-            <literal>true</literal>. You will see a warning that you have done this when JBossTS starts up and see the
+            <literal>true</literal>. You will see a warning that you have done this when &PRODUCT; starts up and see the
             warning about enlisting multiple one-phase resources only the first time it happens, but after that no
             further warnings will be output. You should obviously only consider changing the default value of this
             property (false) with caution.
@@ -348,14 +348,14 @@
     </para>
     <para>
       If You do not explicitly set a timeout value for a transaction, or you use a value of <literal>0</literal>, an
-      implementation-specific default value may be used. In JBossTS, property value
+      implementation-specific default value may be used. In &PRODUCT;, property value
       <varname>CoordinatorEnvironmentBean.defaultTimeout</varname> represents this implementation-specific default, in
       seconds. The default value is 60 seconds. A value of <literal>0</literal> disables default transaction timeouts.
     </para>
     <para>
       Unfortunately, imposing the same timeout as the transaction on a resource manager is not always appropriate. One
       example is that your business rules may require you to have control over the lifetimes on resource managers
-      without allowing that control to be passed to some external entity. JBossTS supports an all-or-nothing approach to
+      without allowing that control to be passed to some external entity. &PRODUCT; supports an all-or-nothing approach to
       whether or not method <methodname>setTransactionTimeout</methodname> is called on
       <interfacename>XAResource</interfacename> instances.
     </para>

Modified: labs/jbosstm/trunk/docs/development_guide/en-US/Transactions.xml
===================================================================
--- labs/jbosstm/trunk/docs/development_guide/en-US/Transactions.xml	2011-04-21 08:39:14 UTC (rev 36958)
+++ labs/jbosstm/trunk/docs/development_guide/en-US/Transactions.xml	2011-04-21 09:02:02 UTC (rev 36959)
@@ -147,16 +147,16 @@
       package.
     </para>
     <para>
-      Each Xid created by JBossTS needs a unique node identifier encoded within it, because JBossTS
+      Each Xid created by &PRODUCT; needs a unique node identifier encoded within it, because &PRODUCT;
       can only recover
       transactions and states that match a specified node identifier. The node
       identifier to use should be provided to
-      JBossTS via the
+      &PRODUCT; via the
       <varname>CoreEnvironmentBean.nodeIdentifier</varname>
       property. This value must be unique across
-      your JBossTS instances. The identifier is
+      your &PRODUCT; instances. The identifier is
       alphanumeric and limited to 10 bytes in length. If you do not provide a
-      value, then JBossTS
+      value, then &PRODUCT;
       generates one and reports the value via the logging infrastructure.
     </para>
 
@@ -341,7 +341,7 @@
       transaction semantics have been disabled, or the transaction times out, a
       transaction may terminated by a thread
       other than the one that created it. In this case, the
-      creator usually needs to be notified. JBossTS notifies the
+      creator usually needs to be notified. &PRODUCT; notifies the
       creator during operations
       <methodname>commit</methodname>
       or



More information about the jboss-svn-commits mailing list