[jboss-svn-commits] JBL Code SVN: r35396 - in labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US: extras and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Oct 4 02:38:28 EDT 2010
Author: misty at redhat.com
Date: 2010-10-04 02:38:27 -0400 (Mon, 04 Oct 2010)
New Revision: 35396
Added:
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/EnvironmentBeans.xml
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/defaultTimeout.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/default_layout.txt
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/jdbcaccess.java
Modified:
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Appendix_Object_Store_Implementations.xml
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Development_Guide.xml
Log:
Committed Appendix Asvn add en-US/extras/*svn add en-US/extras/*svn add en-US/extras/*
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Appendix_Object_Store_Implementations.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Appendix_Object_Store_Implementations.xml 2010-10-04 03:23:17 UTC (rev 35395)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Appendix_Object_Store_Implementations.xml 2010-10-04 06:38:27 UTC (rev 35396)
@@ -11,78 +11,297 @@
<section>
<title>The ObjectStore</title>
<para>
-
+ This appendix examines the various TxCore object store implementations and gives guidelines for creating other
+ implementations and plugging into an application.
</para>
-
+ <para>
+ This release of JBoss Transaction Service contains several different implementations of a basic object store. Each
+ serves a particular purpose and is generally optimized for that purpose. Each of the implementations is derived
+ from the <interfacename>ObjectStore</interfacename> interface, which defines the minimum operations which must be
+ provided for an object store implementation to be used by the Transaction Service. You can override the default
+ object store implementation at runtime by setting the
+ <varname>com.arjuna.ats.arjuna.objectstore.objectStoreType</varname> property variable to one of the types
+ described below.
+ </para>
+ <example>
+ <title>Class <classname>StateStatus</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/appendix_StateStatus.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ JBoss Transaction Service programmers do not usually need to interact with any of the object store implementations
+ directly, apart from possibly creating them in the first place. Even this is not necessary if the default store
+ type is used, since JBoss Transaction Service creates stores as necessary. All stores manipulate instances of the
+ class <classname>ObjectState</classname>. These instances are named using a <systemitem>type</systemitem> (via the
+ object's <methodname>type()</methodname> operation) and a <systemitem>Uid</systemitem>.
+ </para>
+ <para>
+ For atomic actions purposes, object states in the store can be principally in two distinct states:
+ <literal>OS_COMMITTED</literal> or <literal>OS_UNCOMMITTED</literal>. An object state starts in the
+ <literal>OS_COMMITTED</literal> state, but when it is modified under the control of an atomic action, a new second
+ object state may be written that is in the <literal>OS_UNCOMMITTED</literal> state. If the action commits, this
+ second object state replaces the original and becomes <literal>OS_COMMITTED</literal>. If the action aborts, this
+ second object state is discarded. All of the implementations provided with this release handle these state
+ transitions by making use of shadow copies of object states. However, any other implementation that maintains this
+ abstraction is permissible.
+ </para>
+ <para>
+ Object states may become hidden, and thus inaccessible, under the control of the crash recovery system.
+ </para>
+ <para>
+ You can browse the contents of a store through the <methodname>allTypes</methodname> and <methodname>allObjUids</methodname> operations. <methodname>allTypes</methodname> returns
+ an <classname>InputObjectState</classname> containing all of the type names of all objects in a store, terminated by a null
+ name. <methodname>allObjUids</methodname> returns an <classname>InputObjectState</classname> containing all of the Uids of all objects of a given type,
+ terminated by the special <methodname>Uid.nullUid()</methodname>.
+ </para>
<section>
<title>Persistent object stores</title>
<para>
-
+ This section briefly describes the characteristics and optimizations of each of the supplied implementations of
+ the persistent object store. Persistent object states are mapped onto the structure of the file system supported
+ by the host operating system.
</para>
- </section>
- <section>
- <title>Common functionality</title>
- <para>
-
- </para>
+ <section>
+ <title>Common functionality</title>
+ <para>
+ In addition to the features mentioned earlier, all of the supplied persistent object stores obey the following
+ rules:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Each object state is stored in its own file, which is named using the Uid of the object.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The type of an object, as given by the <methodname>type()</methodname> operation, determines the directory
+ into which the object is placed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ All of the stores have a common root directory that is determined when JBoss Transaction Service is
+ configured. This directory name is automatically prepended to any store-specific root information.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ All stores also have the notion of a localized root directory that is automatically prepended to the type
+ of the object to determine the ultimate directory name. The localized root name is specified when the
+ store is created. The default name is <literal>defaultStore</literal>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <screen><xi:include href="extras/default_layout.txt" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></screen>
+ </section>
- </section>
-
- <section>
- <title>The shadowing store</title>
- <para>
-
- </para>
-
- </section>
+ <section>
+ <title>The shadowing store</title>
+ <para>
+ The shadowing store s the original version of the object store, which was provided in prior releases. It is
+ implemented by the class <classname>ShadowingStore</classname>. It is simple but slow. It uses pairs of files
+ to represent objects. One file is the shadow version and the other is the committed version. Files are opened,
+ locked, operated upon, unlocked, and closed on every interaction with the object store. This causes a lot of
+ I/O overhead.
+ </para>
+ <para>
+ If you are overriding the object store implementation, the type of this object store is
+ <literal>ShadowingStore</literal>.
+ </para>
+ </section>
-
- <section>
- <title>No file-level locking</title>
- <para>
-
- </para>
- </section>
-
- <section>
- <title>The hashed store</title>
- <para>
-
- </para>
+ <section>
+ <title>No file-level locking</title>
+ <para>
+ Since transactional objects are concurrency-controlled through <classname>LockManager</classname>, you do not
+ need to impose additional locking at the file level. The basic ShadowingStore implementation handles
+ file-level locking. Therefore, the default object store implementation for JBoss Transaction Service,
+ <systemitem>ShadowNoFileLockStore</systemitem>, relies upon user-level locking. This enables it to provide
+ better performance than the <systemitem>ShadowingStore</systemitem> implementation.
+ </para>
+ <para>
+ If you are overriding the object store implementation, the type of this object store is
+ <literal>ShadowNoFileLockStore</literal>.
+ </para>
+ </section>
- </section>
+ <section>
+ <title>The hashed store</title>
+ <para>
+ The HashedStore has the same structure for object states as the ShadowingStore, but has an alternate directory
+ structure that is better suited to storing large numbers of objects of the same type. Using this store,
+ objects are scattered among a set of directories by applying a hashing function to the object's Uid. By
+ default, 255 sub-directories are used. However, you can override this by setting the
+ <varname>ObjectStoreEnvironmentBean.hashedDirectories</varname> environment variable accordingly.
+ </para>
+ <para>
+ If you are overriding the object store implementation, the type of this object store is <literal>HashedStore</literal>.
+ </para>
+ </section>
-
- <section>
- <title>The JDBC store</title>
- <para>
-
- </para>
- </section>
-
- <section>
- <title>The cached store</title>
- <para>
-
- </para>
+ <section>
+ <title>The JDBC store</title>
+ <para>
+ The JDBCStore uses a JDBC database to save persistent object states. When used in conjunction with the
+ Transactional Objects for Java API, nested transaction support is available. In the current implementation,
+ all object states are stored as <firstterm>Binary Large Objects (BLOBs)</firstterm> within the same table. The
+ limitation on object state size imposed by using BLOBs is <literal>64k</literal>. If you try to store an
+ object state which exceeds this limit, an error is generated and the state is not stored. The transaction is
+ subsequently forced to roll back.
+ </para>
+ <para>
+ When using the JDBC object store, the application must provide an implementation of the
+ <interfacename>JDBCAccess</interfacename> interface, located in the com.arjuna.ats.arjuna.objectstore package:
+ </para>
+ <example>
+ <title>Interface <interfacename>JDBCAccess</interfacename></title>
+ <programlisting language="Java" role="JAVA"> <xi:include href="extras/jdbcaccess.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ The implementation of this class is responsible for providing the <classname>Connection</classname> which the
+ JDBC ObjectStore uses to save and restore object states:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term><methodname>getConnection</methodname></term>
+ <listitem>
+ <para>
+ Returns the Connection to use. This method is called whenever a connection is required, and the
+ implementation should use whatever policy is necessary for determining what connection to return. This
+ method need not return the same <classname>Connection</classname> instance more than once.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>putConnection</term>
+ <listitem>
+ <para>
+ Returns one of the <classname>Connections</classname> acquired from
+ <methodname>getConnection</methodname>. Connections are returned if any errors occur when using them.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>initialise</term>
+ <listitem>
+ <para>
+ Used to pass additional arbitrary information to the implementation.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ The JDBC object store initially requests the number of <classname>Connections</classname> defined in the
+ <varname>ObjectStoreEnvironmentBean.jdbcPoolSizeInitial</varname> property and will use no more than defined
+ in the <varname>ObjectStoreEnvironmentBean.jdbcPoolSizeMaximum property</varname>.
+ </para>
+ <para>
+ The implementation of the <interfacename>JDBCAccess</interfacename> interface to use should be set in the
+ <varname>ObjectStoreEnvironmentBean.jdbcUserDbAccess</varname> property variable.
+ </para>
+ <para>
+ If overriding the object store implementation, the type of this object store is <type>JDBCStore</type>.
+ </para>
+ <para>
+ A JDBC object store can be used for managing the transaction log. In this case, the transaction log
+ implementation should be set to <literal>JDBCActionStore</literal> and the <classname>JDBCAccess</classname>
+ implementation must be provided via the <varname>ObjectStoreEnvironmentBean.jdbcTxDbAccess property</varname>
+ variable. In this case, the default table name is <systemitem>JBossTSTxTable</systemitem>.
+ </para>
+ <para>
+ You can use the same <classname>JDBCAccess</classname> implementation for both the user object store and the
+ transaction log.
+ </para>
+ </section>
- </section>
+ <section>
+ <title>The cached store</title>
+ <para>
+ This object store uses the hashed object store, but does not read or write states to the persistent backing
+ store immediately. It maintains the states in a volatile memory cache and either flushes the cache
+ periodically or when it is full. The failure semantics associated with this object store are different from
+ the normal persistent object stores, because a failure could result in states in the cache being lost.
+ </para>
+ <para>
+ If overriding the object store implementation, the type of this object store is <type>CacheStore</type>.
+ </para>
+ <variablelist>
+ <title>Configuration Properties</title>
+ <varlistentry>
+ <term>ObjectStoreEnvironmentBean.cacheStoreHash</term>
+ <listitem>
+ <para>
+ sets the number of internal stores to hash the states over. The default value is 128.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ObjectStoreEnvironmentBean.cacheStoreSize</term>
+ <listitem>
+ <para>
+ the maximum size the cache can reach before a flush is triggered. The default is 10240 bytes.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ObjectStoreEnvironmentBean.cacheStoreRemovedItems</term>
+ <listitem>
+ <para>
+ the maximum number of removed items that the cache can contain before a flush is triggered. By default,
+ calls to remove a state that is in the cache will simply remove the state from the cache, but leave a
+ blank entry (rather than remove the entry immediately, which would affect the performance of the
+ cache). When triggered, these entries are removed from the cache. The default value is twice the size of
+ the hash.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ObjectStoreEnvironmentBean.cacheStoreWorkItems</term>
+ <listitem>
+ <para>
+ the maximum number of items that are allowed to build up in the cache before it is flushed. The default
+ value is 100. <varname>ObjectStoreEnvironmentBean.cacheStoreScanPeriod</varname> sets the time in
+ milliseconds for periodically flushing the cache. The default is 120 seconds.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ObjectStoreEnvironmentBean.cacheStoreSync</term>
+ <listitem>
+ <para>
+ determines whether flushes of the cache are sync-ed to disk. The default is <literal>OFF</literal>. To
+ enable, set to <literal>ON</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
-
- <section>
- <title>LogStore</title>
- <para>
-
- </para>
+ <section>
+ <title>LogStore</title>
+ <para>
+ This implementation is based on a traditional transaction log. All transaction states within the same process
+ (VM instance) are written to the same log (file), which is an append-only entity. When transaction data would
+ normally be deleted, at the end of the transaction, a <systemitem>delete</systemitem> record is added to the
+ log instead. Therefore, the log just keeps growing. Periodically a thread runs to prune the log of entries
+ that have been deleted.
+ </para>
+ <para>
+ A log is initially given a maximum capacity beyond which it cannot grow. After it reaches this size, the
+ system creates a new log for transactions that could not be accommodated in the original log. The new log and
+ the old log are pruned as usual. During the normal execution of the transaction system, there may be an
+ arbitrary number of log instances. These should be garbage collected by the system,(or the recovery
+ sub-system, eventually.
+ </para>
+ <para>
+ Check the Configuration Options table for how to configure the LogStore.
+ </para>
+ </section>
</section>
-
-
</section>
-
-</appendix>
-
+</appendix>
\ No newline at end of file
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml 2010-10-04 03:23:17 UTC (rev 35395)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Configuration_Options.xml 2010-10-04 06:38:27 UTC (rev 35396)
@@ -3,25 +3,223 @@
<!ENTITY % BOOK_ENTITIES SYSTEM "ArjunaCore_Development_Guide.ent">
%BOOK_ENTITIES;
]>
-<chapter>
+<chapter id="chap-configuration-options">
<title>Configuration options</title>
- <para>
- </para>
<section>
<title>Loading a configuration</title>
<para>
-
+ Each module of the system contains a <classname><replaceable>module</replaceable>propertyManager</classname>
+ 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:
</para>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/defaultTimeout.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ These beans are singletons, instantiated upon first access, using the following algorithm.
+ </para>
+ <procedure>
+ <title>Algorithm for environment bean instantiation</title>
+ <step>
+ <para>
+ The properties are loaded and populated from a properties file named and located as follows:
+ </para>
+ <substeps>
+ <step>
+ <para>
+ If the properties file name property is set, its value is used as the file name.
+ </para>
+ </step>
+ <step>
+ <para>
+ If not, the default filename for the product is used.
+ </para>
+ </step>
+ </substeps>
+ </step>
+ <step>
+ <para>
+ The file thus named is searched for by, in order
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ absolute path
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ user.dir
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ user.home
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ java.home
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ directories contained on the classpath
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ a default file embedded in the product .jar file.
+ </para>
+ </listitem>
+ </orderedlist>
+ </step>
+ <step>
+ <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
+ properties are case-insensitive, and may be one of:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ NO
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ YES
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ FALSE
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ TRUE
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ OFF
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ON
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ In the case of properties that take multiple values, they are whitespace-delimited.
+ </para>
+ <example>
+ <title>Example Environment Bean</title>
+ <programlisting language="XML" role="XML"> <xi:include href="extras/EnvironmentBeans.xml" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ </step>
+ <step>
+ <para>
+ After the file is loaded, it is cached and is not re-read until the JVM is restarted. Changes to the
+ properties file require a restart in order to take effect.
+ </para>
+ </step>
+ <step>
+ <para>
+ After the properties are loaded, the EnvironmentBean is then inspected and, for each field, if the properties
+ contains a matching key in the search order as follows, the <methodname>setter</methodname> method for that field is invoked with the
+ value from the properties, or the system properties if different.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Fully.Qualified.NameEnvironmentBean.propertyName
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ NameEnvironmentBean.propertyName (this is the preferred form used in the properties file)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ the old com.arjuna... properties key (deprecated, for backwards compatibility only).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </step>
+ <step>
+ <para>
+ The bean is then returned to the caller, which may further override values by calling setter methods.
+ </para>
+ </step>
+ </procedure>
+ <para>
+ The implementation reads most bean properties only once, as the consuming component or class is instantiated. This
+ usually happens the first time a transaction is run. As a result, calling <methodname>setter</methodname> methods
+ to change the value of bean properties while the system is running typically has no effect, unless it is done
+ prior to any use of the transaction system. Altered bean properties are not persisted back to the properties file.
+ </para>
+ <para>
+ You can configure the system using a bean wiring system such as JBoss Microcontainer or Spring. Take care when
+ instantiating beans, to obtain the singleton via the static getter (factory) method on the module property
+ manager. Using a new bean instantiated with the default constructor is ineffective, since it is not possible to
+ pass this configured bean back to the property management system.
+ </para>
</section>
<section>
<title>Options</title>
<para>
-
+ The canonical reference for configuration options is the Javadoc of the various
+ <classname>EnvironmentBean</classname> classes, For ArjunaCore these are:
</para>
-
+ <itemizedlist>
+ <listitem>
+ <para>
+ <classname>com.arjuna.common.internal.util.logging.LoggingEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.common.internal.util.logging.basic.BasicLogEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.ats.txoj.common.TxojEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>com.arjuna.ats.arjuna.common.CoreEnvironmentBean.java </classname>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Additional modules built on ArjunaCore may include further beans containing module-specific configuration
+ options. Refer to the documentation for the specific modules for more information.
+ </para>
</section>
</chapter>
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml 2010-10-04 03:23:17 UTC (rev 35395)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Constructing_A_Transactional_Objects_For_Java_Application.xml 2010-10-04 06:38:27 UTC (rev 35396)
@@ -134,7 +134,7 @@
<note>
<para>
The <methodname>setValue</methodname> method is not implemented here, but is similar in structure to <xref
- linkend="example-queue-inspectValue" />.
+ linkend="example_queue-inspectValue" />.
</para>
</note>
<example id="example_queue-inspectValue">
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Development_Guide.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Development_Guide.xml 2010-10-04 03:23:17 UTC (rev 35395)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Development_Guide.xml 2010-10-04 06:38:27 UTC (rev 35396)
@@ -14,6 +14,7 @@
<xi:include href="Hints_and_Tips.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Tools.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Constructing_A_Transactional_Objects_For_Java_Application.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Configuration_Options.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Appendix_Object_Store_Implementations.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Appendix_Class_Definitions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/EnvironmentBeans.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/EnvironmentBeans.xml (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/EnvironmentBeans.xml 2010-10-04 06:38:27 UTC (rev 35396)
@@ -0,0 +1,4 @@
+<entry key="RecoveryEnvironmentBean.recoveryExtensions">
+ com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule
+ com.arjuna.ats.internal.txoj.recovery.TORecoveryModule
+</entry>
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/defaultTimeout.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/defaultTimeout.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/defaultTimeout.java 2010-10-04 06:38:27 UTC (rev 35396)
@@ -0,0 +1,2 @@
+int defaultTimeout =
+ arjPropertyManager.getCoordinatorEnvironmentBean().getDefaultTimeout();
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/default_layout.txt
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/default_layout.txt (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/default_layout.txt 2010-10-04 06:38:27 UTC (rev 35396)
@@ -0,0 +1,11 @@
+<ObjectStore root Directory from configure> <filename>/JBossTS/ObjectStore/</filename>
+ <ObjectStore Type1> <filename>FragmentedStore/</filename>
+ <Default root> <filename>defaultStore/</filename>
+ <StateManager> <filename>StateManager</filename>
+ <LockManager> <filename>LockManager/</filename>
+ <User Types>
+ <Localised root 2> <filename>myStore/</filename>
+ <StateManager> <filename>StateManager/</filename>
+
+ <ObjectStore Type2> <filename>ActionStore/</filename>
+ <Default root> <filename>defaultStore/</filename>
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/jdbcaccess.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/jdbcaccess.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/jdbcaccess.java 2010-10-04 06:38:27 UTC (rev 35396)
@@ -0,0 +1,6 @@
+public interface JDBCAccess
+{
+ public Connection getConnection () throws SQLException;
+ public void putConnection (Connection conn) throws SQLException;
+ public void initialise (Object[] objName);
+}
\ No newline at end of file
More information about the jboss-svn-commits
mailing list