[jboss-svn-commits] JBL Code SVN: r32078 - in labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US: images and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Sun Mar 14 21:34:03 EDT 2010
Author: misty at redhat.com
Date: 2010-03-14 21:34:02 -0400 (Sun, 14 Mar 2010)
New Revision: 32078
Added:
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JBossTS-Example.xml
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-OTS_Architecture.png
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-control_relationship.png
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-example_sequence_diagram.png
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-thread_and_context_relationship.png
Removed:
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_OTS_architecture.png
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_control-relationship.png
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_thread-and-context-relationships.png
Modified:
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/Interfaces_for_Extending_OTS.xml
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JTS_Programmers_Guide.xml
labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/OTS_Introduction.xml
Log:
Added Example chapter
Modified: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/Interfaces_for_Extending_OTS.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/Interfaces_for_Extending_OTS.xml 2010-03-14 22:18:41 UTC (rev 32077)
+++ labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/Interfaces_for_Extending_OTS.xml 2010-03-15 01:34:02 UTC (rev 32078)
@@ -87,59 +87,60 @@
boolean shouldReplace (in OTSAbstractRecord record);
};
</programlisting>
+ </example>
+ <para>
+ The attributes and methods will now be described:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>typeId</term>
+ <listitem><para>returns the record type of the instance. This is one of the values of the enumerated type Record_type.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>uid</term>
+ <listitem><para>a stringified Uid for this record.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>propateOnAbort</term>
+ <listitem><para>by default, instances of OTSAbstractRecord should not be propagated to the parent transaction if the current transaction rolls back. By returning TRUE, the instance will be propagated.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>propagateOnCommit</term>
+ <listitem><para>by returning TRUE from this method, the instance will be propagated to the parent transaction if the current transaction commits; FALSE means it will not be propagated.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>saveRecord</term>
+ <listitem><para>by returning TRUE from this method <application>JBoss Transaction Service</application> will attempt to save sufficient information about the record to persistent store during commit to enable crash recovery mechanisms to replay the transaction termination in the event of a failure. If FALSE is returned then no information will be saved.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>merge</term>
+ <listitem><para>used when two records need to merge together.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>alter</term>
+ <listitem><para>used when a record should be altered.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>shouldAdd</term>
+ <listitem><para>returns true is the record should be added to the list, false if it should be discarded.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>shouldMerge</term>
+ <listitem><para>returns true is the two records should be merged into single record, false if it should be discarded.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>shouldReplace</term>
+ <listitem><para>returns true if the record should replace an existing one, false otherwise.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ When inserting a new record into the transaction’s intentions list, <application>JBoss Transaction Service</application> uses the following algorithm: if a record with the same type and uid has already been inserted, then the methods shouldAdd etc. will be invoked to determine whether this record should also be added. If no such match occurs, then the record will be inserted in the intentions list based on the type field, and ordered according to the uid, i.e., all of the records with the same type will appear ordered in the intentions list.
+ </para>
+ <note>
<para>
- The attributes and methods will now be described:
+ OTSAbstractRecord is derived from ArjunaSubtranAwareResource. Therefore, all instances of OTSAbstractRecord will also obtain the benefits of this interface.
</para>
- <variablelist>
- <varlistentry>
- <term>typeId</term>
- <listitem><para>returns the record type of the instance. This is one of the values of the enumerated type Record_type.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>uid</term>
- <listitem><para>a stringified Uid for this record.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>propateOnAbort</term>
- <listitem><para>by default, instances of OTSAbstractRecord should not be propagated to the parent transaction if the current transaction rolls back. By returning TRUE, the instance will be propagated.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>propagateOnCommit</term>
- <listitem><para>by returning TRUE from this method, the instance will be propagated to the parent transaction if the current transaction commits; FALSE means it will not be propagated.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>saveRecord</term>
- <listitem><para>by returning TRUE from this method <application>JBoss Transaction Service</application> will attempt to save sufficient information about the record to persistent store during commit to enable crash recovery mechanisms to replay the transaction termination in the event of a failure. If FALSE is returned then no information will be saved.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>merge</term>
- <listitem><para>used when two records need to merge together.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>alter</term>
- <listitem><para>used when a record should be altered.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>shouldAdd</term>
- <listitem><para>returns true is the record should be added to the list, false if it should be discarded.</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>shouldMerge</term>
- <listitem><para>returns true is the two records should be merged into single record, false if it should be discarded.</para></listitem>
- </varlistentry>
- <varlistitem>
- <term>shouldReplace</term>
- <listitem><para>returns true if the record should replace an existing one, false otherwise.</para></listitem>
- </varlistitem>
- </variablelist>
- <para>
- When inserting a new record into the transaction’s intentions list, <application>JBoss Transaction Service</application> uses the following algorithm: if a record with the same type and uid has already been inserted, then the methods shouldAdd etc. will be invoked to determine whether this record should also be added. If no such match occurs, then the record will be inserted in the intentions list based on the type field, and ordered according to the uid, i.e., all of the records with the same type will appear ordered in the intentions list.
- </para>
- <note>
- <para>
- OTSAbstractRecord is derived from ArjunaSubtranAwareResource. Therefore, all instances of OTSAbstractRecord will also obtain the benefits of this interface.
- </para>
- </note>
+ </note>
</section>
<section>
@@ -251,5 +252,6 @@
<para>
When the application returns, or prior to this when it has finished with the interposed hierarchy, the program should call unregisterTransaction to disassociate the thread of control from the hierarchy. This occurs automatically when the ExplicitInterposition object is garbage collected. However, since this may be after the transaction has terminated, <application>JBoss Transaction Service</application> will assume the thread is still associated with the transaction and will issue a warning about trying to terminate a transaction while threads are still active within it.
</para>
+ </section>
</chapter>
Added: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JBossTS-Example.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JBossTS-Example.xml (rev 0)
+++ labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JBossTS-Example.xml 2010-03-15 01:34:02 UTC (rev 32078)
@@ -0,0 +1,326 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter>
+ <title><application>JBoss Transaction Service</application> Example</title>
+ <para>
+ The following example illustrates the concepts and the implementation details for a simple client/server example that uses implicit context propagation and indirect context management.
+ </para>
+ <section>
+ <title>The Basic Example</title>
+ <para>
+ It is relatively simplistic in that only a single unit of work is included within the scope of the transaction; consequently, a two phase commit is not required, but rather a one phase commit.
+ </para>
+ <para>
+ It demonstrates the invocation of the client and server processes using both the implicit propagation command line option, and also the interposition command line option.
+ </para>
+ <para>
+ The idl interface for this example is as follows. Line 1 includes the <filename>CosTransactions.idl</filename>.
+ </para>
+ <para>
+ For the purposes of this worked example, we have defined a single method (see line 12) for the DemoInterface interface. We will use this method in the DemoClient program.
+ </para>
+
+ <programlisting language="Java" role="JAVA">
+ 1 #include <idl/CosTransactions.idl>
+ 2 #pragma javaPackage ""
+ 3
+ 4
+ 5 module Demo
+ 6 {
+ 7 exception DemoException {};
+ 8
+ 9 interface DemoInterface : CosTransactions::TransactionalObject
+ 10 {
+ 11 void work() raises (DemoException);
+ 12 };
+ 13 };
+ </programlisting>
+ <para>
+ We will now describe an example implementation of this interface.
+ </para>
+
+ <section>
+ <title>Resource</title>
+ <para>
+ Here, we have overridden the methods of the <classname>Resource</classname> implementation class; the DemoResource implementation includes the placement of System.out.println statements at judicious points, to highlight when a particular method has been invoked.
+ </para>
+ <para>
+ As mentioned previously, only a single unit of work is included within the scope of the transaction; consequently, we should not expect the <methodname>prepare()</methodname> at line 6, or the <methodname>commit()</methodname> at line 19 to be invoked. However, we should expect the <methodname>commit_one_phase()</methodname> method at line 25 to be called.
+ </para>
+ <programlisting language="Java" role="JAVA">
+ 1 import org.omg.CosTransactions.*;
+ 2 import org.omg.CORBA .SystemException;
+ 3
+ 4 public class DemoResource extends org.omg.CosTransactions .ResourcePOA
+ 5 {
+ 6 public Vote prepare() throws HeuristicMixed, HeuristicHazard,
+ 7 SystemException
+ 8 {
+ 9 System.out.println("prepare called");
+ 10
+ 11 return Vote.VoteCommit;
+ 12 }
+ 13
+ 14 public void rollback() throws HeuristicCommit, HeuristicMixed,
+ 15 HeuristicHazard, SystemException
+ 16 {
+ 17 System.out.println("rollback called");
+ 18 }
+ 19
+ 20 public void commit() throws NotPrepared, HeuristicRollback,
+ 21 HeuristicMixed, HeuristicHazard, SystemException
+ 22 {
+ 23 System.out.println("commit called");
+ 24 }
+ 25
+ 26 public void commit_one_phase() throws HeuristicHazard, SystemException
+ 27 {
+ 28 System.out.println("commit_one_phase called");
+ 29 }
+ 30
+ 31 public void forget() throws SystemException
+ 32 {
+ 33 System.out.println("forget called");
+ 34 }
+ 35 }
+ </programlisting>
+ </section>
+
+ <section>
+ <title>Transactional Implementation</title>
+ <para>
+ At this stage, let’s assume that the <filename>Demo.idl</filename> has been processed by the ORB’s <systemitem>idl</systemitem> compiler to generate the necessary client/server package.
+ </para>
+ <para>
+ Line 14 returns the transactional context for the Current pseudo object. Once we have a Control object, we can derive the Coordinator object (line 16).
+ </para>
+ <para>
+ Lines 17 and 19 create a resource for the transaction, and then inform the ORB that the resource is ready to receive incoming method invocations.
+ </para>
+ <para>
+ Line 20 uses the Coordinator to register a DemoResource object as a participant in the transaction. When the transaction is terminated, the resource will receive requests to commit or rollback the updates performed as part of the transaction.
+ </para>
+
+ <programlisting language="Java" role="JAVA">
+ 1 import Demo.*;
+ 2 import org.omg.CosTransactions.*;
+ 3 import com.arjuna.ats.jts.*;
+ 4 import com.arjuna.orbportability.*;
+ 5
+ 6 public class DemoImplementation extends Demo.DemoInterfacePOA
+ 7 {
+ 8 public void work() throws DemoException
+ 9 {
+ 10 try
+ 11 {
+ 12
+ 13 Control control = OTSManager.get_current().get_control();
+ 14
+ 15 Coordinator coordinator = control.get_coordinator();
+ 16 DemoResource resource = new DemoResource();
+ 17
+ 18 ORBManager.getPOA().objectIsReady(resource);
+ 19 coordinator.register_resource(resource);
+ 20
+ 21 }
+ 22 catch (Exception e)
+ 23 {
+ 24 throw new DemoException();
+ 25 }
+ 26 }
+ 27
+ 28 }
+ </programlisting>
+ </section>
+
+ <section>
+ <title>Server Implementation</title>
+ <para>
+ The first requirement is to initialise the ORB and the POA. Lines 10 through 14 accomplish these tasks.
+ </para>
+ <para>
+ It is the servant class <classname>DemoImplementation</classname> that contains the implementation code for the DemoInterface interface. Furthermore, it is ultimately the responsibility of the servant to service a particular client request. Line 16 instantiates a servant object for the subsequent servicing of client requests.
+ </para>
+ <para>
+ Once a servant has been instantiated, we can connect the servant to the POA, so that it can recognize the invocations on it, and pass them to the correct servant. Line 18 performs this task.
+ </para>
+ <para>
+ Lines 20 through to 21 registers the service through the default naming mechanism. More information about the options available can be found in the ORB Portability Guide.
+ </para>
+ <para>
+ If this registration has been successful, line 23 will output a ‘sanity check’ message.
+ </para>
+ <para>
+ Finally, line 25 places the server process into a state where it can begin to accept requests from client processes.
+ </para>
+
+ <programlisting language="Java" role="JAVA">
+ 1 import java.io.*;
+ 2 import com.arjuna.orbportability.*;
+ 3
+ 4 public class DemoServer
+ 5 {
+ 6 public static void main (String[] args)
+ 7 {
+ 8 try
+ 9 {
+ 10 ORB myORB = ORB.getInstance("test").initORB(args, null);
+ 11 RootOA myOA = OA.getRootOA(myORB).myORB.initOA();
+ 12
+ 13 ORBManager.setORB(myORB);
+ 14 ORBManager.setPOA(myOA);
+ 15
+ 16 DemoImplementation obj = new DemoImplementation();
+ 17
+ 18 myOA.objectIsReady(obj);
+ 19
+ 20 Services serv = new Services(myORB);
+ 21 serv.registerService(myOA.corbaReference(obj), "DemoObjReference", null);
+ 22
+ 23 System.out.println("Object published.");
+ 24
+ 25 myOA.run();
+ 26 }
+ 27 catch (Exception e)
+ 28 {
+ 29 System.err.println(e);
+ 30 }
+ 31 }
+ 32 }
+ </programlisting>
+ <para>
+ After the server has compiled, we can use the following command line options, as defined below, to start a server process. By specifying the usage of a filter on the command line, we will effectively override any contrary setting in the <filename>TransactionService.properties</filename> file.
+ </para>
+ <note>
+ <para>
+ if you specify the interposition filter, you also imply usage of implicit context propagation.
+ </para>
+ </note>
+ </section>
+
+ <section>
+ <title>Client Implementation</title>
+ <para>
+ Our client, like the server, requires us to firstly initialize the ORB and the POA. Lines 14 through 18 accomplish these tasks.
+ </para>
+ <para>
+ Once a server process has been started we can obtain the object reference through the default mechanism we used to publish it in the server. This is done in lines 20 and 21. Initially the reference is an instance of Object. However, if we want to invoke a method on the servant object, it is necessary for us to narrow this instance to an instance of the DemoInterface interface (line 21).
+ </para>
+ <para>
+ Once we have a reference to this servant object, we can start a transaction (line 23), perform a unit of work (line 25) and commit the transaction (line 27).
+ </para>
+
+ <programlisting language="Java" role="JAVA">
+ 1 import Demo.*;
+ 2 import java.io.*;
+ 3 import com.arjuna.orbportability.*;
+ 4 import com.arjuna.ats.jts.*;
+ 5 import org.omg.CosTransactions.*;
+ 6 import org.omg.*;
+ 7
+ 8 public class DemoClient
+ 9 {
+ 10 public static void main(String[] args)
+ 11 {
+ 12 try
+ 13 {
+ 14 ORB myORB = ORB.getInstance("test").initORB(args, null);
+ 15 RootOA myOA = OA.getRootOA(myORB).myORB.initOA();
+ 16
+ 17 ORBManager.setORB(myORB);
+ 18 ORBManager.setPOA(myOA);
+ 19
+ 20 Services serv = new Services(myORB);
+ 21 DemoInterface d = (DemoInterface) DemoInterfaceHelper.narrow(serv.getService("DemoObjReference"));
+ 22
+ 23 OTS.get_current().begin();
+ 24
+ 25 d.work();
+ 26
+ 27 OTS.get_current().commit(true);
+ 28 }
+ 29 catch (Exception e)
+ 30 {
+ 31 System.err.println(e);
+ 32 }
+ 33 }
+ 34 }
+ </programlisting>
+ </section>
+
+ <section>
+ <title>Sequence Diagram</title>
+ <para>
+ The sequence diagram illustrates the method invocations that occur between the client and server. The following aspects are worthy of further discussion:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>The transactional context does not need to be explicitly passed as a parameter (as we are using implicit context propagation) in the work() method.</para>
+ </listitem>
+ <listitem>
+ <para>Specifying the use of interposition when the client and server processes are started (by using appropriate filters/interceptors) creates an interposed coordinator that the servant process can utilize, negating any requirement for cross-process invocations. The interposed coordinator is automatically registered with the root coordinator at the client.</para>
+ </listitem>
+ <listitem>
+ <para>The resource that is responsible for committing or rolling back modifications made to the transactional object is associated (‘registered’) with the interposed coordinator.</para>
+ </listitem>
+ <listitem>
+ <para>The <methodname>commit()</methodname> invocation in the client process calls the root coordinator. The root coordinator calls the interposed coordinator, which in turn calls the <methodname>commit_one_phase()</methodname> method for the resource.</para>
+ </listitem>
+ </itemizedlist>
+
+ <figure>
+ <title>Sequence Diagram</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/figure-example_sequence_diagram.png" format="PNG" />
+ </imageobject>
+ <textobject>
+ <para>Sequence Diagram</para>
+ </textobject>
+ </mediaobject>
+ </figure>
+ </section>
+
+ <section>
+ <title> Interpretation of output</title>
+ <para>
+ The server process firstly stringifies the servant instance, and writes the servant IOR to a temporary file. The first line of output is our sanity check that the operation has been successful.
+ </para>
+ <para>
+ In this simplistic example, our coordinator object has only a single registered resource. Consequently, it will perform a <methodname>commit_one_phase</methodname> operation on the resource object, instead of performing a prepare operation, followed by a <methodname>commit</methodname> or <methodname>rollback</methodname>.
+ </para>
+ <para>
+ The output is identical irrespective of whether the implicit context propagation option was used, or interposition. This is because interposition is essentially an aid to improve performance, where ordinarily a lot of marshalling between a client process, and potentially, a server process may be required.
+ </para>
+ <para>
+ The server output:
+ </para>
+ <screen>
+ Object reference written to file
+ commit_one_phase called
+ </screen>
+ </section>
+ </section>
+
+
+ <section>
+ <title>Default Settings</title>
+ <para>
+ In this section we shall list some of the settings which <application>JBoss Transaction Service</application> uses by default and how these settings can be overridden at run-time using property variables. These property variables can also be specified in the proerties file which typically resides in etc.
+ </para>
+ <itemizedlist>
+ <listitem><para>context propagation: unless a CORBA object is derived from <classname>CosTransactions::TransactionalObject</classname> then no context need be propagated. By default, to preserve distribution transparency <application>JBoss Transaction Service</application> will always propagate a transaction context when calling remote objects, regardless of whether they are marked as transactional objects. This can be overridden by setting the <varname>com.arjuna.ats.jts.alwaysPropagateContext</varname> property variable to <option>NO</option>.</para></listitem>
+ <listitem><para>if an object is derived from <classname>CosTransactions::TransactionalObject</classname> and no client context is present when an invocation is made then <application>JBoss Transaction Service</application> will transmit a null context and subsequent transactions begun by the object will be top-level. If a context is required then set the <varname>com.arjuna.ats.jts.needTranContext</varname> to <option>YES</option>, and <application>JBoss Transaction Service</application> will raise the TransactionRequired exception.</para></listitem>
+ <listitem><para><application>JBoss Transaction Service</application> requires a persistent object store to record information about transactions in the event of failures. (If transactions complete successfully then this object store will have no entries). The default location for this must be set using the <varname>com.arjuna.ats.arjuna.objectstore.objectStoreDir</varname> variable in the properties file.</para></listitem>
+ <listitem><para>if using a separate transaction manager for Current then its location is obtained from the <filename>CosServices.cfg</filename> file located in the <filename>etc</filename> directory of the <application>JBoss Transaction Service</application> distribution. If the file is not present then it will be created when the transaction manager is first started. To override the default name and location of the configuration file use the <varname>com.arjuna.orbportability.initialReferencesFile</varname> and <varname>com.arjuna.orbportability.initialReferencesRoot</varname> variables.</para></listitem>
+ <listitem><para>checked transactions are not enabled by default, i.e., threads other than the transaction creator may terminate the transaction, and no check is made to ensure all outstanding requests have finished prior to transaction termination. To override this, set the <varname>com.arjuna.ats.jts.checkedTransactions</varname> to <option>YES</option>.</para></listitem>
+ <listitem><para>if a value of <option>0</option> is specified for the timeout of a top-level transaction (or no timeout is specified), then <application>JBoss Transaction Service</application> will not impose any timeout on the transaction, i.e., it will be allowed to run indefinitely. This default timeout can be overridden by setting the <varname>com.arjuna.ats.arjuna.coordinator.defaultTimeout</varname> property variable to the required timeout value in seconds.</para></listitem>
+ </itemizedlist>
+ <note>
+ <para>As of <application>JBoss Transaction Service</application> 4.5 transaction timeouts have been unified across all transaction components and are controlled by ArjunaCore. The old JTS configuration property <varname>com.arjuna.ats.jts.defaultTimeout</varname> still remains but is deprecated.</para>
+ </note>
+ </section>
+
+</chapter>
+
Modified: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JTS_Programmers_Guide.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JTS_Programmers_Guide.xml 2010-03-14 22:18:41 UTC (rev 32077)
+++ labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/JTS_Programmers_Guide.xml 2010-03-15 01:34:02 UTC (rev 32078)
@@ -9,6 +9,7 @@
<xi:include href="OTS_Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Constructing_OTS_Application.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Interfaces_for_Extending_OTS.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="JBossTS-Example.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<index />
</book>
Modified: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/OTS_Introduction.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/OTS_Introduction.xml 2010-03-14 22:18:41 UTC (rev 32077)
+++ labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/OTS_Introduction.xml 2010-03-15 01:34:02 UTC (rev 32078)
@@ -27,7 +27,7 @@
<title>OTS Architecture</title>
<mediaobject>
<imageobject>
- <imagedata fileref="images/figure_OTS-Architecture.png" format="PNG"/>
+ <imagedata fileref="images/figure-OTS_Architecture.png" format="PNG"/>
</imageobject>
<textobject>
<para>OTS Architecture</para>
@@ -294,7 +294,7 @@
<title>Thread and Context Relationship</title>
<mediaobject>
<imageobject>
- <imagedata fileref="images/figure_thread-and-context-relationship.png" format="PNG"/>
+ <imagedata fileref="images/figure-thread_and_context_relationship.png" format="PNG"/>
</imageobject>
<textobject>
<para>Thread and Context Relationships</para>
Added: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-OTS_Architecture.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-OTS_Architecture.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-control_relationship.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-control_relationship.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-example_sequence_diagram.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-example_sequence_diagram.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-thread_and_context_relationship.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure-thread_and_context_relationship.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Deleted: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_OTS_architecture.png
===================================================================
(Binary files differ)
Deleted: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_control-relationship.png
===================================================================
(Binary files differ)
Deleted: labs/jbosstm/enterprise/tags/EAP_5_0_1/Transactions_JTS_Programmers_Guide/en-US/images/figure_thread-and-context-relationships.png
===================================================================
(Binary files differ)
More information about the jboss-svn-commits
mailing list