[jboss-svn-commits] JBL Code SVN: r35943 - in labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US: extras and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Nov 10 20:22:45 EST 2010
Author: misty at redhat.com
Date: 2010-11-10 20:22:45 -0500 (Wed, 10 Nov 2010)
New Revision: 35943
Added:
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactionaldriver.java
Removed:
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactional_driver.java
Modified:
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Examples.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/JDBC.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Java_Transaction_API.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/The_Resource_Manager.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transaction_Recovery.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transactions.xml
labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Using_JBossTA_In_Application_Servers.xml
Log:
JBTM-805 - Convert ArjunaTA Development Guide to Docbook - complete
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Examples.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Examples.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Examples.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -30,7 +30,7 @@
<para>
This is only a small example of the sorts of things an XAResourceRecovery implementer could do. This implementation
uses a property file that is assumed to contain sufficient information to recreate connections used during the
- normal run of an application so that recovery can be performed on them. Typically, usernames and passwords should
+ normal run of an application so that recovery can be performed on them. Typically, user-names and passwords should
never be presented in raw text on a production system.
</para>
<example>
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/JDBC.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/JDBC.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/JDBC.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -46,7 +46,7 @@
JDBC drivers as conduits for all interactions. These drivers intercept all invocations and ensure that they are
registered with, and driven by, appropriate transactions. The driver
<classname>com.arjuna.ats.jdbc.TransactionalDriver</classname> handles all JDBC drivers, implementing the
- <interfacename>java.sql.Driver</interfacename> interface. If the database is not transactiona, ACID properties
+ <interfacename>java.sql.Driver</interfacename> interface. If the database is not transactional, ACID properties
cannot be guaranteed.
</para>
<section>
@@ -62,7 +62,7 @@
<xi:include href="extras/registering_transactionaldriver_using_jdbc_driver_manager.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
The jdbc.drivers property contains a colon-separated list of driver class names, which the JDBC driver manager
- loads when it is initialized. After the driver is loaded, you can use it to make a connection wtih a
+ loads when it is initialized. After the driver is loaded, you can use it to make a connection with a
database.
</para>
</example>
@@ -82,7 +82,7 @@
<title>Connections</title>
<para>
Because JBossJTA provides JDBC connectivity via its own JDBC driver, application code can support transactions
- witho relatively small code chnges. Typically, the application programmer only needs to start and terminate
+ with relatively small code changes. Typically, the application programmer only needs to start and terminate
transactions.
</para>
<section>
@@ -143,7 +143,7 @@
</para>
<para>
JBossJTA JDBC support can obtain XADataSources through the Java Naming and Directory Interface (JNDI) or dynamic
- class instnatiation.
+ class instantiation.
</para>
<section>
<title>Java naming and directory interface (JNDI)</title>
@@ -174,7 +174,7 @@
<xi:include href="extras/passing_connection_url_to_jdbc.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
The JNDI URL must be pre-pended with <literal>jdbc:arjuna:</literal> in order for the TransactionalDriver to
- recognise that the DataSource must participate within transactions and be driven accordingly.
+ recognize that the DataSource must participate within transactions and be driven accordingly.
</para>
</example>
</section>
@@ -251,7 +251,7 @@
<para>
For each user name and password, JBossJTA maintains a single instance of each connection for as long as that
connection is in use. Subsequent requests for the same connection get a reference to the original connection,
- rather than a new instance. Yuo can try to close the connection, but the connection will only actually be closed
+ rather than a new instance. You can try to close the connection, but the connection will only actually be closed
when all users (including transactions) have either finished with the connection, or issued
<methodname>close</methodname> calls.
</para>
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Java_Transaction_API.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Java_Transaction_API.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Java_Transaction_API.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -50,7 +50,7 @@
recovery.
</para>
<para>
- A resource adaptor is used by an application server or client to connect to a Resource Manager. JDBC
+ A resource adapter is used by an application server or client to connect to a Resource Manager. JDBC
drivers which are used to connect to relational databases are examples of Resource Adapters.
</para>
</entry>
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/The_Resource_Manager.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/The_Resource_Manager.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/The_Resource_Manager.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -42,7 +42,7 @@
<itemizedlist>
<listitem>
<para>
- The resource adaptor implicitly initializes the <interfacename>ResourceManager</interfacename> when the
+ The resource adapter implicitly initializes the <interfacename>ResourceManager</interfacename> when the
resource (the connection) is acquired. There is no equivalent to the <methodname>xa_open</methodname> method
of the interface <interfacename>XA</interfacename>.
</para>
@@ -109,7 +109,7 @@
</para>
<para>
By default an attempt to enlist more than one instance of a LastResourceCommitOptimisation class will fail and
- false will be returned from Transaction.enlistResource. This behaviour can be overridden by setting the
+ false will be returned from Transaction.enlistResource. This behavior can be overridden by setting the
com.arjuna.ats.jta.allowMultipleLastResources to true. However, before doing so you should read the section on
enlisting multiple one-phase aware resources.
</para>
@@ -122,7 +122,7 @@
<section>
<title>Enlisting multiple one-phase-aware resources</title>
<para>
- One-phase commit is used to process a single one-phase aware resource, which does not comform to the
+ One-phase commit is used to process a single one-phase aware resource, which does not conform to the
two-phase commit protocol. You can still achieve an atomic outcome across resources, by using the LRCO, as
explained earlier.
</para>
@@ -131,7 +131,7 @@
database runs within the same transaction as a legacy JMS implementation. In such a situation, you cannot
achieve atomicity of transaction outcome across multiple resources, because none of them enter the
<methodname>prepare</methodname> state. They commit or roll back immediately when instructed by the
- transaction coordinator, without knowledge of other resource states and without a way to undo if subsdequent
+ transaction coordinator, without knowledge of other resource states and without a way to undo if subsequent
resources make a different choice. This can result in data corruption or heuristic outcomes.
</para>
<para>
@@ -192,7 +192,7 @@
<section>
<title>Closing a resource manager</title>
<para>
- The resource adaptor closes a resource manager as a result of destroying the transactional resource. A
+ The resource adapter closes a resource manager as a result of destroying the transactional resource. A
transaction resource at the resource adapter level is comprised of two separate objects:
</para>
<itemizedlist>
@@ -297,7 +297,7 @@
<example id="resource_sharing_example">
<title>Resource sharing example</title>
<programlisting language="Java" role="JAVA">
- <xi:include href="extras/resource_sharing_example.java" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="extras/resource_sharing_example.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" />
</programlisting>
<para>
A transactional resource <systemitem>r1</systemitem>. Global transaction <systemitem>xid1</systemitem> is
@@ -372,7 +372,7 @@
<title>Dynamic registration</title>
<para>
Dynamic registration is not supported in <interfacename>XAResource</interfacename>. There are two reasons this
- kames sense.
+ makes sense.
</para>
<itemizedlist>
<listitem>
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transaction_Recovery.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transaction_Recovery.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transaction_Recovery.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -21,7 +21,7 @@
<interfacename>XAResource</interfacename> objects are not persistent across system failures, so the Transaction
Manager needs a way to acquire the <interfacename>XAResource</interfacename> objects representing the resource
managers which might have participated in the transactions before a system failure. For example, a Transaction
- Manager might use the JNDI lookup mechanism to acquire a connection from each of the transactional resource
+ Manager might use the JNDI look-up mechanism to acquire a connection from each of the transactional resource
factories, before obtaining the corresponding <interfacename>XAResource</interfacename> object for each
connection. The Transaction Manager then invokes the <methodname>XAResource.recover</methodname> method, which
requests each resource manager to return the transactions that are currently in a
@@ -168,7 +168,8 @@
manage state, which adds complexity. Starting with JBossTS 4.4, you can provide an implementation of public
interface <interfacename>XAResourceRecoveryHelper</interfacename>:
</para>
- <programlisting language="Java" role="JAVA"><xi:include href="extras/XAResourceRecoveryHelper.java" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/XAResourceRecoveryHelper.java"
+ xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
During each recovery sweep, method <methodname>getXAResources</methodname> is called and recovery is attempted on
@@ -194,7 +195,7 @@
<para>
The ability to dynamically add and remove instances of <interfacename>XAResourceRecoveryHelper</interfacename>
while the system is running is an attractive option for environments where datasources may be deployed or
- undeployed, such as application servers. Take care with classloading behaviour in such cases.
+ undeployed, such as application servers. Take care with classloading behavior in such cases.
</para>
</section>
@@ -207,8 +208,8 @@
</para>
<para>
These <interfacename>XAResourceRecovery</interfacename> instances are primarily intended for when running JBossTS
- outside of a container such as JBossAS or another application server. This is because they rely upon
- <interfacename>XADataSources</interfacename> as the primary handle to drive recovery. If you are runing JBossTS
+ outside of a container such as JBoss Application Server or another application server. This is because they rely upon
+ <interfacename>XADataSources</interfacename> as the primary handle to drive recovery. If you are running JBossTS
inside an application server or other container, consult the relevant integration documentation, to be sure to use
the right recovery modules.
</para>
@@ -217,7 +218,7 @@
<title>com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery</title>
<para>
<interfacename>com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery</interfacename> expects you to specify an
- XML property file upon creation. It uses this file to read the configuration properties for the datasouce.
+ XML property file upon creation. It uses this file to read the configuration properties for the datasource.
</para>
<example>
<title>Example</title>
@@ -230,7 +231,7 @@
<para>
<interfacename>com.arjuna.ats.internal.jdbc.recovery.JDBCXARecovery</interfacename> should work on any
datasource that is exposed via JNDI. It expects an XML property file to be specified upon creation, and uses the
- file to read the database JNDI name, username and password.
+ file to read the database JNDI name, user-name and password.
</para>
<example>
<title>Example</title>
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transactions.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transactions.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Transactions.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -90,7 +90,7 @@
The <interfacename>TransactionManager</interfacename> maintains the transaction context association with threads
as part of its internal data structure. A thread’s transaction context may be <literal>null</literal> or it may
refer to a specific global transaction. Multiple threads may be associated with the same global transaction. As
- noted in <xref linkend="UserTransaction_definition" />, nested transactions are not supported.
+ noted in <xref linkend="UserTransaction_Definition" />, nested transactions are not supported.
</para>
<para>
Each transaction context is encapsulated by a Transaction object, which can be used to perform operations which
@@ -282,7 +282,8 @@
<para>
Transaction synchronization allows the application server to be notified before and after the transaction
completes. For each transaction started, the application server may optionally register a
- <type>Synchronization</type> call-back object to be invoked by the transaction manager, which will be one of the following:
+ <type>Synchronization</type> call-back object to be invoked by the transaction manager, which will be one of the
+ following:
</para>
<informaltable>
<tgroup cols="2">
Modified: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Using_JBossTA_In_Application_Servers.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Using_JBossTA_In_Application_Servers.xml 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/Using_JBossTA_In_Application_Servers.xml 2010-11-11 01:22:45 UTC (rev 35943)
@@ -11,7 +11,7 @@
<section>
<title>Configuration</title>
<para>
- When JBossJTA runs embedded in JBossAS, the transaction system is configured primarily through the
+ When JBossJTA runs embedded in JBoss Application Server, the transaction system is configured primarily through the
<filename>transaction-jboss-beans.xml</filename> deployment descriptor, which overrides properties read from the
default properties file embedded in the .<filename>jar</filename> file.
</para>
@@ -49,11 +49,11 @@
<section>
<title>Logging</title>
<para>
- To make JBossTS logging semantically consistent with JBossAS, the
+ To make JBossTS logging semantically consistent with JBoss Application Server, the
<interfacename>TransactionManagerService</interfacename> modifies the level of some log messages, by overriding
the value of the <varname>LoggingEnvironmentBean.loggingFactory</varname> property in the
<filename>jbossts-properties.xml</filename> file. Therefore, the value of this property has no effect on the
- logging behavior when running embedded in JBossAS. By forcing use of the <systemitem>log4j_releveler</systemitem>
+ logging behavior when running embedded in JBoss Application Server. By forcing use of the <systemitem>log4j_releveler</systemitem>
logger, the <interfacename>TransactionManagerService</interfacename> changes the level of all
<literal>INFO</literal> level messages in the transaction code to <literal>DEBUG</literal>. Therefore, these
messages do not appear in log files if the filter level is <literal>INFO</literal>. All other log messages behave
@@ -65,13 +65,13 @@
<title>The services</title>
<para>
The <interfacename>TransactionManager</interfacename> bean provides transaction management services to other
- components in JBossAS. There are two different version of this bean and they requires different configuation. Take
+ components in JBoss Application Server. There are two different version of this bean and they requires different configuration. Take
care to select the <filename>transaction-jboss-beans.xml</filename> suitable for your needs (local JTA or JTS).
</para>
</section>
<section>
- <title>Ensuring transactional context is propatated to the server</title>
+ <title>Ensuring transactional context is propagated to the server</title>
<para>
You can coordinate transactions from a coordinator which is not located within the JBoss server
, such as when using transactions created by an external OTS server. To ensure the transaction context is propagated via
Deleted: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactional_driver.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactional_driver.java 2010-11-10 22:50:37 UTC (rev 35942)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactional_driver.java 2010-11-11 01:22:45 UTC (rev 35943)
@@ -1 +0,0 @@
-TransactionalDriver arjunaJDBC2Driver = new TransactionalDriver();
\ No newline at end of file
Copied: labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactionaldriver.java (from rev 35930, labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactional_driver.java)
===================================================================
--- labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactionaldriver.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTA/docs/ArjunaTA_Development_Guide/en-US/extras/instantiating_transactionaldriver.java 2010-11-11 01:22:45 UTC (rev 35943)
@@ -0,0 +1 @@
+TransactionalDriver arjunaJDBC2Driver = new TransactionalDriver();
\ No newline at end of file
More information about the jboss-svn-commits
mailing list