[jboss-svn-commits] JBL Code SVN: r32295 - labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US.

jboss-svn-commits at lists.jboss.org jboss-svn-commits at lists.jboss.org
Tue Mar 30 00:09:39 EDT 2010


Author: laubai
Date: 2010-03-30 00:09:38 -0400 (Tue, 30 Mar 2010)
New Revision: 32295

Modified:
   labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter.xml
   labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_02.xml
   labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_03.xml
Log:
Corrected use of mediaobject tags.

Modified: labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter.xml	2010-03-30 01:27:21 UTC (rev 32294)
+++ labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter.xml	2010-03-30 04:09:38 UTC (rev 32295)
@@ -20,13 +20,14 @@
         <note><para>When the manual talks about using persistence and concurrency control facilities it assumes that the <emphasis>Transactional Objects for Java</emphasis> (TXOJ) classes are being used. If this is not the case then the programmer is responsible for all of these issues.</para></note>
         
         <para><classname>TxCore</classname> exploits object-oriented techniques to present programmers with a toolkit of Java classes from which application classes can inherit to obtain desired properties, such as persistence and concurrency control. These classes form a hierarchy, part of which is shown below and which will be described later in this document.</para>
-        
-        <mediaobject id="figure_1"><title>TXCore Class Heirarchy</title>
+        <figure id="figure_1"><title>TXCore Class Hierarchy</title>
+        <mediaobject>
             <imageobject>
                 <imagedata align="center" fileref="images/TXCore_class_hierarchy.png" />
             </imageobject>
             <caption> Txcore class hierarchy </caption>
         </mediaobject>
+        </figure>
         
         <para>Apart from specifying the scopes of transactions, and setting appropriate locks within objects, the application programmer does not have any other responsibilities: <classname>TxCore</classname> and <emphasis>Transactional Objects for Java</emphasis> (TXOJ) guarantee that transactional objects will be registered with, and be driven by, the appropriate transactions, and crash recovery mechanisms are invoked automatically in the event of failures.</para>
         
@@ -125,13 +126,14 @@
             <title>The life-cycle of a Transactional Object for Java </title>
             
             <para>A persistent object not in use is assumed to be held in a <emphasis>passive</emphasis> state with its state residing in an object store and <emphasis>activated</emphasis> on demand. The fundamental life cycle of a persistent object in <emphasis>TXOJ</emphasis> is shown in <xref linkend="figure_2"/>.</para>
-            
-            <mediaobject id="figure_2"><title>Persistent Object Lifecycle</title>
+          <figure id="figure_2"><title>Persistent Object Lifecycle</title>
+            <mediaobject>
                 <imageobject>
 			<imagedata align="center" fileref="images/Persistent_Object_Lifecycle.png" />
                 </imageobject>
                 <caption> The lifecycle of a persistent object. </caption>
             </mediaobject>
+          </figure>
             
             <itemizedlist>
                 <listitem><para>The object is initially passive, and is stored in the object store as an instance of the class <classname>OutputObjectState</classname>.</para></listitem>
@@ -289,4 +291,4 @@
         
     </section>
     
-</chapter>
\ No newline at end of file
+</chapter>

Modified: labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_02.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_02.xml	2010-03-30 01:27:21 UTC (rev 32294)
+++ labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_02.xml	2010-03-30 04:09:38 UTC (rev 32295)
@@ -276,24 +276,26 @@
             
             <itemizedlist>
                 <listitem><para><literal>SINGLE</literal>: only a single copy of the object exists within the application; this will reside within a single JVM, and all clients must address their invocations to this server. This model provides better performance, but represents a single point of failure, and in a multi-threaded environment may not protect the object from corruption if a single thread fails.</para>
-                
-                    <mediaobject id="figure_3"><title>Single Object Model</title>
+                <figure id="figure_3"><title>Single Object Model</title>
+                    <mediaobject>
                         <imageobject>
                             <imagedata align="center" fileref="images/Single_Object.png" />
                         </imageobject>
                         <caption> Single Object Model</caption>
                     </mediaobject>
+                </figure>
                 
                 </listitem>
                 <listitem><para>MULTIPLE: logically a single instance of the object exists, but copies of it are distributed across different JVMs; the performance of this model is worse than the SINGLE model, but it provides better failure isolation.</para>
                 
-                
-                    <mediaobject id="figure_4">
+                <figure id="figure_4"><title>Multiple Object Model</title>
+                    <mediaobject>
                         <imageobject>
                             <imagedata align="center" fileref="images/Multiple_Object.png" />
                         </imageobject>
                         <caption> Multiple Object Model</caption>
                     </mediaobject>
+                  </figure>
                 </listitem>
             </itemizedlist>
             

Modified: labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_03.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_03.xml	2010-03-30 01:27:21 UTC (rev 32294)
+++ labs/jbosstm/enterprise/tags/EAP_4_2_9/Programmers_Guide/en-US/Chapter_03.xml	2010-03-30 04:09:38 UTC (rev 32295)
@@ -146,13 +146,15 @@
             <title>Independent top-level transactions</title>
             
             <para>In addition to normal top-level and nested atomic actions <emphasis>TxCore</emphasis> also supports independent top-level actions, which can be used to relax strict serialisability in a controlled manner. An independent top-level action can be executed from anywhere within another atomic action and behaves exactly like a normal top-level action, that is, its results are made permanent when it commits and will not be undone if any of the actions within which it was originally nested abort.</para>
-            
-            <mediaobject id="figure_5"><title>Independent Top-Level Action</title>
+        
+            <figure id="figure_5"><title>Independent Top-Level Action</title>
+              <mediaobject>
                 <imageobject>
                     <imagedata align="center" fileref="images/Independent_Top-Level.png" />
                 </imageobject>
-                <caption> Independent Top-Level Action</caption>
-            </mediaobject>
+                <caption>Independent Top-Level Action</caption>
+              </mediaobject>
+            </figure>
             
             <para><xref linkend="figure_5"/> shows a typical nesting of atomic actions, where action B is nested within action A. Although atomic action C is logically nested within action B (it had its Begin operation invoked while B was active) because it is an independent top-level action, it will commit or abort independently of the other actions within the structure. Because of the nature of independent top-level actions they should be used with caution and only in situations where their use has been carefully examined.</para>
             
@@ -244,4 +246,4 @@
     </section>
     
     
-</chapter>
\ No newline at end of file
+</chapter>



More information about the jboss-svn-commits mailing list