[jboss-svn-commits] JBL Code SVN: r29319 - labs/jbosstm/enterprise/tags/EAP_5_0_0/Administrators_Guide/en-US.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Sun Sep 13 21:22:10 EDT 2009
Author: irooskov at redhat.com
Date: 2009-09-13 21:22:10 -0400 (Sun, 13 Sep 2009)
New Revision: 29319
Modified:
labs/jbosstm/enterprise/tags/EAP_5_0_0/Administrators_Guide/en-US/Chapter.xml
Log:
updated doc with new info from JTS admin guide
Modified: labs/jbosstm/enterprise/tags/EAP_5_0_0/Administrators_Guide/en-US/Chapter.xml
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_5_0_0/Administrators_Guide/en-US/Chapter.xml 2009-09-13 16:58:45 UTC (rev 29318)
+++ labs/jbosstm/enterprise/tags/EAP_5_0_0/Administrators_Guide/en-US/Chapter.xml 2009-09-14 01:22:10 UTC (rev 29319)
@@ -1,5 +1,5 @@
<?xml version='1.0'?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
@@ -39,8 +39,286 @@
</section>
<section><title>ObjectStore management</title>
<para>Within the transaction service installation, the object store is updated regularly whenever transactions are created, or when Transactional Objects for Java is used. In a failure free environment, the only object states which should reside within the object store are those representing objects created with the Transactional Objects for Java API. However, if failures occur, transaction logs may remain in the object store until crash recovery facilities have resolved the transactions they represent. As such it is very important that the contents of the object store are not deleted without due care and attention, as this will make it impossible to resolve in doubt transactions. In addition, if multiple users share the same object store it is important that they realise this and do not simply delete the contents of the object store assuming it is an exclusive resource.</para>
+ <para>
+ Apart from ensuring that the run-time system is executing normally, there is little continuous administration needed for the JBossTS software. There are a few points however, that should be made:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The present implementation of the JBossTS system provides no security or protection for data. It is recommended that the objects stored in the JBossTS are owned by user arjuna. The Object Store and Object Manager facilities make no attempt to enforce even the limited form of protection that Unix and Windows provides. There is no checking of user or group IDs on access to objects for either reading or writing.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Persistent objects created in the Object Store never go away unless the <methodname>StateManager.destroy</methodname> method is invoked on the object or some application program explicitly deletes them. This means that the Object Store gradually accumulates garbage (especially during application development and testing phases). At present we have no automated garbage collection facility. Further, we have not addressed the problem of dangling references. That is, a persistent object, A, may have stored a UID for another persistent object, B, in its passive representation on disk. There is nothing to prevent an application from deleting B even though A still contains a reference to it. When A is next activated and attempts to access B, a run-time error will occur.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ There is presently no support for version control of objects or database reconfiguration in the event of class structure changes. This is a complex research area that we have not addressed. At present, if you change the definition of a class of persistent objects, you are entirely responsible for ensuring that existing instances of the object in the Object Store are converted to the new representation. The JBossTS software can neither detect nor correct references to old object state by new operation versions or vice versa.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Object store management is critically important to the transaction service.
+ </para>
+ </listitem>
+ </itemizedlist>
</section>
+<section>
+ <title>OTS and J2EE Transaction service management </title>
+ <section>
+ <title>Starting the run-time system</title>
+ <para>
+ The JBossTS run-time support consists of run-time packages and the OTS transaction manager server. By default JBossTS does not use a separate transaction manager server: transaction managers are co-located with each application process to improve performance and improve application fault-tolerance (the application is no longer dependant upon another service in order to function correctly).
+ </para>
+ <para>
+ When running applications which require a separate transaction manager, you must set the <varname>com.arjuna.ats.jts.transactionManager</varname> environment variable to have the value <literal>yes</literal>. The system will then locate the transaction manager server in a manner specific to the ORB being used. The server can be located in a number of ways: by being registered with a name server, added to the ORB’s initial references, via a JBossTS specific references file, or by the ORB’s specific location mechanism (if applicable).
+ </para>
+ <para>
+ It is possible to override the default registration mechanism by using the <varname>com.arjuna.orbportability.resolveService</varname> environment variable. This can have one of the following values:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>CONFIGURATION_FILE</literal>: the default, this causes the system to use the <filename>CosServices.cfg</filename> file.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>NAME_SERVICE</literal>: JBossTS will attempt to use a name service to register the transaction factory. If this is not supported, an exception will be thrown.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>BIND_CONNECT</literal>: JBossTS will use the ORB-specific bind mechanism. If this is not supported, an exception will be thrown.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>RESOLVE_INITIAL_REFERENCES</literal>: JBossTS will attempt to register the transaction service with the ORBs initial service references.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <note>
+ <para>
+ This may not be supported on all ORBs. An exception will be thrown in that case and another option will have to be used.
+ </para>
+ </note>
+ <formalpara>
+ <title>OTS configuration file</title>
+ <para>
+ Similar to the resolve_initial_references, JBossTS supports an initial reference file where references for specific services can be stored and used at runtime. The file, CosServices.cfg, consists of two columns: the service name (in the case of the OTS server TransactionService) and the IOR, separated by a single space. CosServices.cfg normally resides in the etc directory of the JBossTS installation; the actual location is determined at runtime by searching the CLASSPATH for an old copy of the file resident within an etc directory, or, if one is not found, the location of the TransactionService properties file directory.
+ </para>
+ </formalpara>
+ <para>
+ The OTS server will automatically register itself in this file (creating it if necessary) if this option is being used. Stale information is also automatically removed. Machines which wish to share the same transaction server should have access to (or a copy of) this file.
+ </para>
+ <para>
+ The name and location of the file can be overridden using the <property>com.arjuna.orbportability.initialReferencesFile</property> and <property>com.arjuna.orbportability.initialReferencesRoot</property> property variables, respectively. It is recommended that the <property>com.arjuna.orbportability.initialReferencesRoot</property> variable is set. For example:
+ </para>
+<screen>
+com.arjuna.orbportability.initialReferencesFile=myFile
+com.arjuna.orbportability.initialReferencesRoot=c:\\temp
+</screen>
+ <formalpara>
+ <title>Name Service</title>
+ <para>
+ If the ORB you are using supports a name service, and JBossTS has been configured to use it, then the transaction manager will automatically be registered with it. There is no further work required. This option is not used for JacORB
+ </para>
+ </formalpara>
+ <formalpara>
+ <title>resolve_initial_references</title>
+ <para>
+ Currently this option is only supported for JacORB.
+ </para>
+ </formalpara>
+ <formalpara>
+ <title>Resolution service table</title>
+ <para>
+ The following table summarizes the different ways in which the OTS transaction manager may be located on specific ORBs:
+ </para>
+ </formalpara>
+ <table>
+ <title>Locating the OTS transaction manager server</title>
+ <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+ <thead>
+ <row>
+ <entry>Resolution Mechanism</entry>
+ <entry>ORB</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>OTS configuration file</entry>
+ <entry>All available ORBs</entry>
+ </row>
+ <row>
+ <entry>Name Service</entry>
+ <entry>JacORB</entry>
+ </row>
+ <row>
+ <entry>resolve_initial_references</entry>
+ <entry>JacORB</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ <section>
+ <title>XA specific management</title>
+ <para>
+ Each XA Xid that JBossTS creates must have a unique node identifier encoded within it and JBossTS will only recover transactions and states that match a specified node identifier. The node identifier to use should be provided to JBossTS via the <property>com.arjuna.ats.arjuna.xa.nodeIdentifier</property> property. You must make sure this value is unique across your JBossTS instances. If you do not provide a value, then JBossTS will fabricate one and report the value via the logging infrastructure.
+ </para>
+ <para>
+ When running XA recovery it is therefore necessary to tell JBossTS which types of Xid it can recover. Each Xid that JBossTS creates has a unique node identifier encoded within it and JBossTS will only recover transactions and states that match a specified node identifier. The node identifier to use should be provided to JBossTS via a property that starts with the name <property>com.arjuna.ats.jta.xaRecoveryNode</property>; multiple values may be provided. A value of <code>*</code> will force JBossTS to recover (and possibly rollback) all transactions irrespective of their node identifier and should be used with caution.
+ </para>
+ </section>
+</section>
+<section>
+ <title>Web Service Transaction service management</title>
+ <para>
+ The basic building blocks of a transactional Web Services application are the application itself, the Web services that the application consumes, the Transaction Manager, and the transaction participants which support those Web services. Though it is unlikely in a typical deployment that a single developer will be expected to support all of these roles, the concepts are presented here so that a global model can be visualized. It will often be the case that developers will produce services, or applications that consume services, whilst system administrators will run the transaction-management infrastructure.
+ </para>
+ <section>
+ <title>The Transaction Manager</title>
+ <para>
+ The transaction manager is a Web service which coordinates JBossTS transactions. It is the only software component in JBossTS that is meant to be run directly as a network service, rather than to support end-user code. The transaction manager runs as a JAXM request/response Web service.
+ </para>
+ <important>
+ <para>
+ When starting up an application server instance that has JBossTS deployed within it, you may see various <emphasis>error</emphasis> messages in the console or log. For example <code>16:53:38,850 ERROR [STDERR] Message Listener Service: started, message listener jndi name activationcoordinator</code>. These are for information purposes only and are not actual errors.
+ </para>
+ </important>
+ <formalpara>
+ <title>Configuring the Transaction Manager</title>
+ <para>
+ The Transaction Manager and related infrastructure are configured by means of properties files: <filename>wscf.xml</filename>, <filename>wst.xml</filename> and <filename>wstx.xml</filename>. These files can be found in the conf directory and are used for configuring the demo application and the standalone module.
+ </para>
+ </formalpara>
+ <para>
+ For the most part the default values in these files need not be altered. However, the <property>com.arjuna.ats.arjuna.objectstore.objectStoreDir</property> property determines the location of the persistent store used to record transaction state. The default value of <filename>C:/temp/ObjectStore</filename> should be changed to a value appropriate to your system. For production environments this directory should reside on fault tolerant media such as a RAID array.
+ </para>
+ <para>
+ When a standalone coordinator is being used by an application it is necessary to enable and modify two further properties in <filename>wstx.xml</filename>, <property>com.arjuna.mw.wst.coordinatorURL</property> and <property>com.arjuna.mw.wst.terminatorURL</property>. These contain the URLs necessary for the client application to contact the standalone coordinator and should be configured with the correct hostname and port of the standalone coordinator.
+ </para>
+ <para>
+ JBossTS is highly modular so in order to allow for flexible deployment of individual components, the same property values are sometimes required to appear in more than one configuration file. For the majority of configurations, you should maintain consistent values for properties that are defined in more than one file.
+ </para>
+ <formalpara>
+ <title>Deploying the Transaction Manager</title>
+ <para>
+ The JBossTS Web Service Transaction Manager component consists of a number of JAR files containing the application’s class files, plus Web service (WAR) files which expose the necessary services. Programmers will typically include all these components in their application EAR file during application development, simplifying deployment of the transaction infrastructure. For production usage the Transaction Manager may be installed as an application in its own right, allowing for centralized configuration and management at the server level, independent of specific applications. The demonstration application shipped with JBossTS provides a sample deployment descriptor illustrating how the Transaction Manager components can be included in an application.
+ </para>
+ </formalpara>
+ <para>
+ JBossTS 4.0 uses fixed endpoints for its underlying protocol communication. Therefore, problems may arise if multiple applications using JBossTS are deployed to the same server concurrently. If you wish to deploy several transactional applications in the same server, the Transaction Manger must be deployed as a separate application and not embedded within the deployment of individual applications.
+ </para>
+ <para>
+ The coordinator directory in the JBossTS installation has been provided to assist in the configuration and deployment of a stand-alone transaction manager. In order to use this, you must:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Have JBoss Enterprise Application Platform 5 installed
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Install ant 1.4 or later.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <important>
+ <para>
+ It is important that a separate application server installation be used from the one that clients and services are deployed into since otherwise conflicts may occur between the various JBossTS components.
+ </para>
+ </important>
+ <para>
+ You must then edit the build.xml included with coordinator to point to the application server installation where the transaction coordinator will be deployed and the location of the JBossTS installation. The files <filename>ws-c_jaxm_web-app.xml</filename> and <filename>ws-t_jaxm_web-app.xml</filename> in the <filename>dd</filename> directory of coordinator are the deployment descriptors for the WS-C and WS-T WAR files. These files contain templated URLs. During the build phase, ant will substitute the hostname and port values you specify in the <filename>build.xml</filename> into these files.
+ </para>
+ <para>
+ Run <code>ant</code>, with <code>target deploy-weblogic</code>, <code>deploy-jboss</code> or <code>deploy-webmethods</code>, to create and deploy a new coordinator into the correct application server installation.
+ </para>
+ <para>
+ Now all you need to do is point your client at the required coordinator. To do this, generate the demo application specifying the port and hostname of the coordinator.
+ </para>
+ <formalpara>
+ <title>Deployment descriptors</title>
+ <para>
+ In general, it should not be necessary to change the contents of the various deployment descriptors used by JBossTS. However, if you do need to modify them they are all included in the coordinator module.
+ </para>
+ </formalpara>
+ <para>
+ Not all JBossTS components have ready access to the information in the deployment descriptors. Therefore, if you modify the JNDI names used by any of the WS-C or WS-T deployment descriptors you may need to inform other JBossTS components at runtime. This can be accomplished by setting an appropriate property in the <filename>wstx.xml</filename> configuration file.
+ </para>
+ <para>
+ The following table shows the default JNDI name used by the deployment descriptors and the corresponding property to set if the default value is changed.
+ </para>
+ <table>
+ <title>Deployment descriptor values and properties</title>
+ <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+ <thead>
+ <row>
+ <entry>JNDI Name</entry>
+ <entry>Property</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Activationrequester</entry>
+ <entry>com.arjuna.mw.wst.at.activationrequester</entry>
+ </row>
+ <row>
+ <entry>Activationcoordinator</entry>
+ <entry>com.arjuna.mw.wst.at.activationcoordinator</entry>
+ </row>
+ <row>
+ <entry>Completionparticipant</entry>
+ <entry>com.arjuna.mw.wst.at.completionparticipant</entry>
+ </row>
+ <row>
+ <entry>Registrationrequester</entry>
+ <entry>com.arjuna.mw.wst.at.registrationrequester</entry>
+ </row>
+ <row>
+ <entry>durable2pcdispatcher</entry>
+ <entry>com.arjuna.mw.wst.at.durable2pcdispatcher</entry>
+ </row>
+ <row>
+ <entry>durable2pcparticipant</entry>
+ <entry>com.arjuna.mw.wst.at.durable2pcparticipant</entry>
+ </row>
+ <row>
+ <entry>volatile2pcdispatcher</entry>
+ <entry>com.arjuna.mw.wst.at.volatile2pcdispatcher</entry>
+ </row>
+ <row>
+ <entry>volatile2pcparticipant</entry>
+ <entry>com.arjuna.mw.wst.at.volatile2pcparticipant</entry>
+ </row>
+ <row>
+ <entry>businessagreementwithparticipantcompletiondispatcher</entry>
+ <entry>com.arjuna.mw.wst.ba.businessagreementwpcdispatcher</entry>
+ </row>
+ <row>
+ <entry>businessagreementwithparticipantcompletionparticipant</entry>
+ <entry>com.arjuna.mw.wst.ba.businessagreementwpcparticipant</entry>
+ </row>
+ <row>
+ <entry>businessagreementwithcoordinatorcompletiondispatcher</entry>
+ <entry>com.arjuna.mw.wst.ba.businessagreementwccdispatcher</entry>
+ </row>
+ <row>
+ <entry>businessagreementwithcoordinatorcompletionparticipant</entry>
+ <entry>com.arjuna.mw.wst.ba.businessagreementwccparticipant</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+</section>
<section><title>JBoss Transactions runtime information</title>
<para>Each module that comprises JBoss Transactions possesses a class called Info. These classes all provide a single toString method that returns an XML document representing the configuration information for that module. So, for example:</para>
@@ -257,55 +535,123 @@
com.arjuna.ats.internal.ts.arjuna.recovery.ExpiredTransactionStatusManagerScanner</programlisting></section>
</section>
-<section><title>Errors and Exceptions</title>
- <para>In this section we shall cover the types of errors and exceptions which may be thrown or reported during a transactional application and give probable indications of their causes.</para>
+<section><title>Selecting the JTA implementation</title>
+ <para>Two variants of the JTA implementation are now provided and accessible through the same interface. These are:</para>
<para><orderedlist>
+ <listitem>
+ <para>A purely local JTA, which only allows non-distributed JTA transactions to be executed. This is the only version available with the JBoss Transactions product.</para>
+ </listitem>
+ <listitem>
+ <para>A remote, CORBA-based JTA, which allows distributed JTA transactions to be executed. This version is only available with the ArjunaJTS product and requires a supported CORBA ORB.</para>
+ </listitem>
+
+ <listitem>
+ <para>both of these implementations are fully compatible with the transactional JDBC driver provided with JBoss Transactions.</para>
+ </listitem>
+ </orderedlist></para>
+ <para>In order to select the local JTA implementation it is necessary to perform the following steps:</para>
+ <para><orderedlist>
+ <listitem>
+ <para>make sure the property <literal>com.arjuna.ats.jta.jtaTMImplementation</literal> is set to <literal>com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple</literal>.</para>
+ </listitem>
+ <listitem>
+ <para>make sure the property <literal>com.arjuna.ats.jta.jtaUTImplementation</literal> is set to <literal>com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>these settings are the default values for the properties and do not need to be specified if the local implementation is required.</para>
+ </listitem>
+ </orderedlist>
+ </para>
+</section>
+
+<section>
+ <title>ORB specific configurations</title>
+ <formalpara>
+ <title>JacORB</title>
+ <para>
+ For JacORB to function correctly it is necessary to ensure there is a valid <filename>jacorb.properties</filename> or <filename>.jacorb_properties</filename> file in one of the following places:
+ </para>
+ </formalpara>
+ <itemizedlist>
<listitem>
- <para>NO_MEMORY: the application has run out of memory (thrown an <classname>OutOfMemoryError</classname>) and JBoss Transactions has attempted to do some cleanup (by running the garbage collector) before re-throwing the exception. This is probably a transient problem and retrying the invocation should succeed.</para>
+ <para>
+ The classpath.
+ </para>
</listitem>
<listitem>
- <para>com.arjuna.ats.arjuna.exceptions.FatalError: an error has occurred which means that the transaction system must shut down. Prior to this error being thrown the transaction service will have ensured that all running transactions have rolled back. If caught, the application should tidy up and exit. If further work is attempted, application consistency may be violated.</para>
+ <para>
+ The home directory of the user running the JBoss Transaction Service. The home directory is retrieved using <code>System.getProperty( “user.home” );</code>
+ </para>
</listitem>
<listitem>
- <para>com.arjuna.ats.arjuna.exceptions.LicenceError: an attempt has been made to use the transaction service in a manner inconsistent with the current licence. The transaction service will not allow further forward progress for existing or new transactions.</para>
+ <para>
+ The current directory.
+ </para>
</listitem>
<listitem>
- <para>com.arjuna.ats.arjuna.exceptions.ObjectStoreError: an error occurred while the transaction service attempted to use the object store. Further forward progress is not possible.</para>
+ <para>
+ The <filename>lib</filename> directory of the JDK used to run your application. This is retrieved using <code>System.getProperty( “java.home” );</code>
+ </para>
</listitem>
+ </itemizedlist>
+ <para>
+ The above places are searched in the order given. A template <filename>jacorb.properties</filename> file can be found in the JacORB installation directory.
+ </para>
+ <para>
+ Within the JacORB properties file there are two important properties which must be tailored to suit your application, they are:
+ </para>
+ <itemizedlist>
<listitem>
- <para>Object store warnings about access problems on states may occur during the normal execution of crash recovery. This is the result of multiple concurrent attempts to perform recovery on the same transaction. It can be safely ignored. </para>
+ <para>
+ <property>jacorb.poa.thread_pool_max</property>
+ </para>
</listitem>
- </orderedlist></para>
+ <listitem>
+ <para>
+ <property>jacorb.poa.thread_pool_min</property>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ These properties specify the minimum and maximum number of request processing threads that JacORB will use in its thread pool. If there aren’t a sufficient number of threads available in this thread pool then the application may appear to become deadlocked. For more information on configuring JacORB please reference the JacORB documentation.
+ </para>
+ <note>
+ <para>
+ JacORB comes with its own implementation of the classes defined in the <filename>CosTransactions.idl</filename> file. Unfortunately these are incompatible with the version shipped with JBossTS. Therefore, it is important that the JBossTS jar files appear in the <code>CLASSPATH</code> before any JacORB jars.
+ </para>
+ </note>
+ <para>
+ When running the recovery manager it is important that it always uses the same well known port for each machine on which it runs. You should not use the OAPort property provided by JacORB unless the recovery manager has its own <filename>jacorb.properties</filename> file or this is provided on the command line when starting the recovery manager. If the recovery manager and other components of JBossTS share the same <filename>jacorb.properties</filename> file, then you should use the <filename>com.arjuna.ats.jts.recoveryManagerPort</filename> and <filename>com.arjuna.ats.jts.recoveryManagerAddress</filename> properties.
+ </para>
</section>
-<section><title>Selecting the JTA implementation</title>
- <para>Two variants of the JTA implementation are now provided and accessible through the same interface. These are:</para>
+<section>
+ <title>Initializing JBossTS applications</title>
+ <para>
+ It is important that JBossTS is correctly initialized prior to any application object being created. In order to guarantee this, the programmer should use the <methodname>ORB_init</methodname> and <methodname>create_POA</methodname> methods. <!-- described in the Orb Portability Guide. Consult the Orb Portability Guide if direct use of the <methodname>ORB_init</methodname> and <methodname>create_POA</methodname> methods provided by the underlying ORB is required. -->
+ </para>
+</section>
+
+<section><title>Errors and Exceptions</title>
+ <para>In this section we shall cover the types of errors and exceptions which may be thrown or reported during a transactional application and give probable indications of their causes.</para>
<para><orderedlist>
<listitem>
- <para>A purely local JTA, which only allows non-distributed JTA transactions to be executed. This is the only version available with the JBoss Transactions product.</para>
+ <para>NO_MEMORY: the application has run out of memory (thrown an <classname>OutOfMemoryError</classname>) and JBoss Transactions has attempted to do some cleanup (by running the garbage collector) before re-throwing the exception. This is probably a transient problem and retrying the invocation should succeed.</para>
</listitem>
<listitem>
- <para>A remote, CORBA-based JTA, which allows distributed JTA transactions to be executed. This version is only available with the ArjunaJTS product and requires a supported CORBA ORB.</para>
+ <para>com.arjuna.ats.arjuna.exceptions.FatalError: an error has occurred which means that the transaction system must shut down. Prior to this error being thrown the transaction service will have ensured that all running transactions have rolled back. If caught, the application should tidy up and exit. If further work is attempted, application consistency may be violated.</para>
</listitem>
-
<listitem>
- <para>both of these implementations are fully compatible with the transactional JDBC driver provided with JBoss Transactions.</para>
+ <para>com.arjuna.ats.arjuna.exceptions.LicenceError: an attempt has been made to use the transaction service in a manner inconsistent with the current licence. The transaction service will not allow further forward progress for existing or new transactions.</para>
</listitem>
- </orderedlist></para>
- <para>In order to select the local JTA implementation it is necessary to perform the following steps:</para>
- <para><orderedlist>
<listitem>
- <para>make sure the property <literal>com.arjuna.ats.jta.jtaTMImplementation</literal> is set to <literal>com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple</literal>.</para>
+ <para>com.arjuna.ats.arjuna.exceptions.ObjectStoreError: an error occurred while the transaction service attempted to use the object store. Further forward progress is not possible.</para>
</listitem>
<listitem>
- <para>make sure the property <literal>com.arjuna.ats.jta.jtaUTImplementation</literal> is set to <literal>com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple</literal>.</para>
+ <para>Object store warnings about access problems on states may occur during the normal execution of crash recovery. This is the result of multiple concurrent attempts to perform recovery on the same transaction. It can be safely ignored. </para>
</listitem>
-
- <listitem>
- <para>these settings are the default values for the properties and do not need to be specified if the local implementation is required.</para>
- </listitem>
- </orderedlist>
-</para>
+ </orderedlist></para>
</section>
</chapter>
More information about the jboss-svn-commits
mailing list