[jboss-svn-commits] JBL Code SVN: r35417 - labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Oct 4 21:16:14 EDT 2010
Author: misty at redhat.com
Date: 2010-10-04 21:16:13 -0400 (Mon, 04 Oct 2010)
New Revision: 35417
Modified:
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/General_Transaction_Issues.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Overview.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Revision_History.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Tools.xml
labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml
Log:
Spell-checking and last minute changes, as well as fixing the revision history.
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -13,7 +13,7 @@
class., which provides static getter methods for one or more
<classname><replaceable>name</replaceable>EnvironmentBean</classname> classes. An example is
<classname>com.arjuna.ats.arjuna.commmon.arjPropertyManager</classname>. These environment beans are standard
- javabeans containing properties for each configuration option in the system. Typical usage is of the form:
+ JavaBean containing properties for each configuration option in the system. Typical usage is of the form:
</para>
<programlisting language="Java" role="JAVA"><xi:include href="extras/defaultTimeout.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
@@ -33,7 +33,7 @@
</step>
<step>
<para>
- If not, the default filename for the product is used.
+ If not, the default file name for the product is used.
</para>
</step>
</substeps>
@@ -79,7 +79,7 @@
<para>
The file is treated as being of standard java.util.Properties xml format and loaded accordingly. The entry
names are of the form EnvironmentBeanClass.propertyName:<code><entry
- key="CoordinatorEnvironmentBean.commitOnePhase">YES</entry></code>. Valid values for boolean
+ key="CoordinatorEnvironmentBean.commitOnePhase">YES</entry></code>. Valid values for Boolean
properties are case-insensitive, and may be one of:
</para>
<itemizedlist>
@@ -115,7 +115,7 @@
</listitem>
</itemizedlist>
<para>
- In the case of properties that take multiple values, they are whitespace-delimited.
+ In the case of properties that take multiple values, they are white-space-delimited.
</para>
<example>
<title>Example Environment Bean</title>
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -107,7 +107,7 @@
</section>
<section>
- <title><methodname>enque</methodname> and <methodname>dequeue</methodname> methods</title>
+ <title><methodname>enqueue</methodname> and <methodname>dequeue</methodname> methods</title>
<para>
If the operations of the <classname>queue</classname> class are to be coded as atomic actions, then the enqueue
operation might have the structure given below. The <methodname>dequeue</methodname> operation is similarly
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/General_Transaction_Issues.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/General_Transaction_Issues.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/General_Transaction_Issues.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -128,7 +128,7 @@
resources as well.
</para>
<para>
- In order to utilise the LRCO, your participant must implement the
+ In order to utilize the LRCO, your participant must implement the
<interfacename>com.arjuna.ats.arjuna.coordinator.OnePhase</interfacename> interface and be registered with the
transaction through the <methodname>BasicAction.add</methodname> operation. Since this operation expects instances
of <classname>AbstractRecord</classname>, you must create an instance of
@@ -159,7 +159,7 @@
</para>
<para>
The committing or aborting of a nested action does not automatically affect the outcome of the action within which
- it is nested. This is application dependant, and allows a programmer to structure atomic actions to contain
+ it is nested. This is application dependent, and allows a programmer to structure atomic actions to contain
faults, undo work, etc.
</para>
</section>
@@ -201,7 +201,7 @@
<title>Independent top-level transactions</title>
<para>
In addition to normal top-level and nested atomic actions, TxCore 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
+ which can be used to relax strict serializability 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. 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.
@@ -283,7 +283,7 @@
</para>
<note>
<para>
- Default timeout values for other JBossTS components, such as JTS, may be different and you should consult the
+ Default timeout values for other JBoss Transaction Service components, such as JTS, may be different and you should consult the
relevant documentation to be sure.
</para>
</note>
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Overview.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Overview.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Overview.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -123,7 +123,7 @@
<programlisting language="Java" role="JAVA"> <xi:include href="extras/StateManager-signature.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
</example>
<para>
- Objects are assumed to be of three possible flavours.
+ Objects are assumed to be of three possible flavors.
</para>
<variablelist>
<title>Three Flavors of Objects</title>
@@ -191,7 +191,7 @@
linkend="txoj-lifecycle" />.
</para>
<figure id="txoj-lifecycle">
- <title>Lifecycle of a persistent Object in TXOJ</title>
+ <title>Life cycle of a persistent Object in TXOJ</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/txoj-lifecycle.png" format="PNG"/>
@@ -303,7 +303,7 @@
<classname>StateManager</classname> to record sufficient information for crash recovery mechanisms to complete the
transaction in the event of failures. It has methods for starting and terminating the transaction, and, for those
situations where programmers need to implement their own resources, methods for registering them with the current
- transaction. Because TxCore supports subtransactions, if a transaction is begun within the scope of an already
+ transaction. Because TxCore supports sub-transactions, if a transaction is begun within the scope of an already
executing transaction it will automatically be nested.
</para>
<para>
@@ -435,7 +435,7 @@
</para>
<para>
The class <classname>LockManager</classname> uses the facilities of <classname>StateManager</classname> and
- <classname>Lock</classname> to provide the concurrency control required for implementing the serialisability
+ <classname>Lock</classname> to provide the concurrency control required for implementing the serializability
property of atomic actions. The concurrency control consists of two-phase locking in the current implementation.
The implementation of atomic action facilities is supported by <classname>AtomicAction</classname> and
<classname>TopLevelTransaction</classname>.
@@ -490,7 +490,7 @@
<classname>O</classname>.
</para>
<para>
- It is important to realise that all of the above work is automatically being performed by TxCore on behalf of the
+ It is important to realize that all of the above work is automatically being performed by TxCore on behalf of the
application programmer. The programmer need only start the transaction and set an appropriate lock; TxCore and
<application>TXOJ</application> take care of participant registration, persistence, concurrency control and
recovery.
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Revision_History.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Revision_History.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Revision_History.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -4,24 +4,25 @@
%BOOK_ENTITIES;
]>
<appendix id="appe-ArjunaCore_Development_Guide-Revision_History">
- <title>Revision History</title>
- <simpara>
- <revhistory>
- <revision>
- <revnumber>0</revnumber>
- <date>Fri Sep 24 2010</date>
- <author>
- <firstname>Dude</firstname>
- <surname>McPants</surname>
- <email>Dude.McPants at example.com</email>
- </author>
- <revdescription>
- <simplelist>
- <member>Initial creation of book by publican</member>
- </simplelist>
- </revdescription>
- </revision>
- </revhistory>
- </simpara>
+ <title>Revision History</title>
+ <simpara>
+ <revhistory>
+ <revision>
+ <revnumber>0</revnumber>
+ <date>Fri Sep 24 2010</date>
+ <author>
+ <firstname>Misty</firstname>
+ <surname>Stanley-Jones</surname>
+ <email>misty at redhat.com</email>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>Convert existing documentation to Publican.</member>
+ <member>Update to 4.13.</member>
+ </simplelist>
+ </revdescription>
+ </revision>
+ </revhistory>
+ </simpara>
</appendix>
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Tools.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Tools.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Tools.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -11,7 +11,7 @@
<section>
<title>Starting the Transaction Service tools</title>
<para>
- The transaction service tools are started differently, depending on your perating system.
+ The transaction service tools are started differently, depending on your operating system.
</para>
<procedure id="starting-tools">
@@ -207,7 +207,7 @@
</itemizedlist>
<para>
Click the <guilabel>View</guilabel> link to display and operate on the attributes and operations exposed by this
- MBean. You can view readable attributes, alter writeable attributes, and invoke operations.
+ MBean. You can view readable attributes, alter writable attributes, and invoke operations.
</para>
<section>
@@ -215,7 +215,7 @@
<para>
When you click the <guilabel>View</guilabel> link, the <guilabel>View JMX Attributes and Operations</guilabel>
window appears. You can view all readable attributes exposed by the selected MBean. You can also alter
- writeable attributes. If an attribute is read-only then you cannot alter an attribute's value. To alter an
+ writable attributes. If an attribute is read-only then you cannot alter an attribute's value. To alter an
attribute's value, just double-click the current value and enter the new value. If the
<guibutton>Edit</guibutton> button is enabled, then you can click it to open an advanced editor. If the
attribute type is a <systemitem>JMX object name</systemitem>, clicking this button displays the JMX attributes
@@ -304,22 +304,22 @@
<section>
<title>Writing an OSV</title>
<para>
- Writing an OSV plugin allows you to extend the capabilities of the Object Store browser to show the state of
+ Writing an OSV plug-in allows you to extend the capabilities of the Object Store browser to show the state of
user-defined abstract records. An OSV plug-in is a class which implements the interface
<interfacename>com.arjuna.ats.tools.objectstorebrowser.stateviewers.StateViewerInterface </interfacename>.
Package it in a JAR within the <filename>plugins</filename> directory. This example shows how to create an OSV
- plugin for an abstract record subclass which looks as follows:
+ plug-in for an abstract record subclass which looks as follows:
</para>
<programlisting language="Java" role="JAVA"><xi:include href="extras/abstract_record_subclass.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
When this abstract record is viewed in the object store browser, showing the current value is simple. You can
read the state into an instance of the abstract record and call <methodname>getValue()</methodname>. The
- following is the object store browser plugin source code:
+ following is the object store browser plug-in source code:
</para>
<programlisting language="Java" role="JAVA"><xi:include href="extras/osv_plugin.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
<para>
- The method <methodname>uidNodeExpanded</methodname> is invoked when a UID representing the given type is
- expanded in the object store hierarchy tree. This is not required by this plugin as this abstract record is
+ The method <methodname>uidNodeExpanded</methodname> is invoked when a Uid representing the given type is
+ expanded in the object store hierarchy tree. This is not required by this plug-in as this abstract record is
not visible in the object store directly, but only via one of the lists in an atomic action. The method
<methodname>entrySelected</methodname> is invoked when an entry is selected from the object view which
represents an object with the given type. In both methods the State Panel is used to display information
@@ -362,7 +362,7 @@
</para>
<para>
To add this plug-in to the object store browser, package it into a JAR file with a name that is prefixed with
- <filename>osbv-</filename>. The JAR file must contain certain information within the manifest file so that the
+ <filename>osv-</filename>. The JAR file must contain certain information within the manifest file so that the
object store browser knows which classes are plug-ins. See <xref linkend="osv-plugin-ant" /> for how to do
this using Apache Ant.
</para>
Modified: labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml 2010-10-04 17:45:18 UTC (rev 35416)
+++ labs/jbosstm/trunk/ArjunaCore/docs/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml 2010-10-05 01:16:13 UTC (rev 35417)
@@ -114,7 +114,7 @@
their parents at commit time.
</para>
<para> <!-- This is the exact same stuff that is in the Recovery & Persistence chapter of Overview.xml -->
- Objects are assumed to be of three possible flavours.
+ Objects are assumed to be of three possible flavors.
</para>
<variablelist>
<title>Three Flavors of Objects</title>
@@ -277,7 +277,7 @@
<term><type>boolean</type> <methodname>save_state</methodname>(<type>OutputObjectState</type> <varname>state</varname>, <type>int</type><varname>ObjectType</varname>)</term>
<listitem>
<para>
- Invoked whenever the state of an object might need to be saved for future use, priqmarily for recovery
+ Invoked whenever the state of an object might need to be saved for future use, primarily for recovery
or persistence purposes. The <parameter>ObjectType</parameter> parameter indicates the reason that
<methodname>save_state</methodname> was invoked by TxCore. This enables the programmer to save different
pieces of information into the <classname>OutputObjectState</classname> supplied as the first parameter
@@ -412,7 +412,7 @@
<title>LockManager</title>
<para>
The concurrency controller is implemented by the class <classname>LockManager</classname>, which provides
- sensible default behaviour, while allowing the programmer to override it if deemed necessary by the particular
+ sensible default behavior, while allowing the programmer to override it if deemed necessary by the particular
semantics of the class being programmed. The primary programmer interface to the concurrency controller is via
the <methodname>setlock</methodname> operation. By default, the TxCore runtime system enforces strict two-phase
locking following a multiple reader, single writer policy on a per object basis. Lock acquisition is under
@@ -445,7 +445,7 @@
xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
</example>
<para>
- The <methodname>setlock</methodname> operation must be parameterised with the type of lock required (READ or
+ The <methodname>setlock</methodname> operation must be parametrized with the type of lock required (READ or
WRITE), and the number of retries to acquire the lock before giving up. If a lock conflict occurs, one of the
following scenarios will take place:
</para>
@@ -486,7 +486,7 @@
ensure that the locks are released at the correct time. This frees the programmer from the burden of explicitly
freeing any acquired locks if they were acquired within atomic actions. However, if locks are acquired on an
object outside of the scope of an atomic action, it is the programmer's responsibility to release the locks when
- required, using the corresponding releaselock operation.
+ required, using the corresponding <methodname>releaselock</methodname> operation.
</para>
</section>
@@ -523,7 +523,7 @@
Recall that TxCore objects can be recoverable, recoverable and persistent, or neither. Additionally each object
possesses a unique internal name. These attributes can only be set when that object is constructed. Thus
<classname>LockManager</classname> provides two protected constructors for use by derived classes, each of which
- fulfils a distinct purpose
+ fulfills a distinct purpose
</para>
<variablelist>
<title>Protected Constructors Provided by <classname>LockManager</classname></title>
@@ -546,7 +546,7 @@
<literal>ANDPERSISTENT</literal>), or neither (indicated by <literal>NEITHER</literal>). If an object is
marked as being persistent then the state of the object will be stored in one of the object stores. The
shared parameter only has meaning if it is <literal>RECOVERABLE</literal>. If the object model is
- <literal>SINGLE</literal> (the default behaviour) then the recoverable state of the object is maintained
+ <literal>SINGLE</literal> (the default behavior) then the recoverable state of the object is maintained
within the object itself, and has no external representation). Otherwise an in-memory (volatile) object
store is used to store the state of the object between atomic actions.
</para>
@@ -577,7 +577,7 @@
As above, this constructor allows access to an existing persistent object, whose internal name is given by
the <varname>objUid</varname> parameter. Objects constructed using this operation will normally have their
prior state (identified by <varname>objUid</varname>) loaded from an object store automatically by the
- system. If the object model is <literal>SINGLE</literal> (the default behaviour), then the object will not
+ system. If the object model is <literal>SINGLE</literal> (the default behavior), then the object will not
be reactivated at the start of each top-level transaction.
</para>
</listitem>
More information about the jboss-svn-commits
mailing list