[jboss-cvs] JBossAS SVN: r93193 - in projects/docs/enterprise: 4.3.6/Installation_Guide/en-US and 1 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Sep 3 18:27:08 EDT 2009
Author: irooskov at redhat.com
Date: 2009-09-03 18:27:07 -0400 (Thu, 03 Sep 2009)
New Revision: 93193
Modified:
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Architecture.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Author_Group.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Batch_Index.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Book_Info.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Configuration.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Feedback.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Getting_Started.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Introduction.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Lucene_Native.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Mapping.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Optimize.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Preface.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Query.pot
projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Revision_History.pot
projects/docs/enterprise/4.3.6/Installation_Guide/en-US/Getting_Started.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
Log:
updated
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Architecture.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Architecture.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Architecture.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Author_Group.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Author_Group.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Author_Group.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Batch_Index.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Batch_Index.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Batch_Index.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Book_Info.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Book_Info.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Book_Info.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
@@ -17,7 +17,7 @@
#. Tag: title
#: Book_Info.xml:6
#, no-c-format
-msgid "Hibernate Search Reference Guide CP05 FP01"
+msgid "Hibernate Search Reference Guide CP05"
msgstr ""
#. Tag: subtitle
@@ -30,8 +30,7 @@
#: Book_Info.xml:8
#, no-c-format
msgid ""
-"For use with JBoss Enterprise Application Platform 4.3.0 Cumulative Patch 5 "
-"Feature Pack 1"
+"For use with JBoss Enterprise Application Platform 4.3.0 Cumulative Patch 5"
msgstr ""
#. Tag: para
@@ -39,7 +38,7 @@
#, no-c-format
msgid ""
"This book is a Reference Guide to Hibernate Search for JBoss Enterprise "
-"Application Platform 4.3.0 CP05 FP01"
+"Application Platform 4.3.0 CP05"
msgstr ""
#. Tag: phrase
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Configuration.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Configuration.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Configuration.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
@@ -130,12 +130,10 @@
"cluster."
msgstr ""
-#. Tag: entry
-#: Configuration.xml:56
+#. Tag: para
+#: Configuration.xml:56 Configuration.xml:81
#, no-c-format
-msgid ""
-"<entry>DirectoryProvider typically used on slave nodes using a JMS back end."
-"</entry>"
+msgid "DirectoryProvider typically used on slave nodes using a JMS back end."
msgstr ""
#. Tag: para
@@ -182,14 +180,6 @@
"inconsistent search results, 2 local copies are kept."
msgstr ""
-#. Tag: para
-#: Configuration.xml:81
-#, no-c-format
-msgid ""
-"<para>DirectoryProvider typically used on slave nodes using a JMS back end.</"
-"para>"
-msgstr ""
-
#. Tag: entry
#: Configuration.xml:97
#, no-c-format
@@ -1000,18 +990,38 @@
msgid ""
"There are two sets of parameters allowing for different performance settings "
"depending on the use case. During indexing operations triggered by database "
-"modifications, the following ones are used: <itemizedlist> <listitem> "
-"<para><literal>hibernate.search.[default|<indexname>].transaction."
-"merge_factor</literal></para> </listitem> <listitem> "
-"<para><literal>hibernate.search.[default|<indexname>].transaction."
-"max_merge_docs</literal></para> </listitem> <listitem> "
-"<para><literal>hibernate.search.[default|<indexname>].transaction."
-"max_buffered_docs</literal></para> </listitem> </itemizedlist>When indexing "
-"occurs via <literal>FullTextSession.index()</literal> (see <xref linkend="
-"\"Hibernate_Search-Batch_Index\"/>), the following properties are used:"
+"modifications, the following ones are used:"
msgstr ""
#. Tag: literal
+#: Configuration.xml:481
+#, no-c-format
+msgid "hibernate.search.[default|<indexname>].transaction.merge_factor"
+msgstr ""
+
+#. Tag: literal
+#: Configuration.xml:485
+#, no-c-format
+msgid "hibernate.search.[default|<indexname>].transaction.max_merge_docs"
+msgstr ""
+
+#. Tag: literal
+#: Configuration.xml:489
+#, no-c-format
+msgid ""
+"hibernate.search.[default|<indexname>].transaction.max_buffered_docs"
+msgstr ""
+
+#. Tag: para
+#: Configuration.xml:491
+#, no-c-format
+msgid ""
+"When indexing occurs via <literal>FullTextSession.index()</literal> (see "
+"<xref linkend=\"Hibernate_Search-Batch_Index\"/>), the following properties "
+"are used:"
+msgstr ""
+
+#. Tag: literal
#: Configuration.xml:495
#, no-c-format
msgid "hibernate.search.[default|<indexname>].batch.merge_factor"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Feedback.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Feedback.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Feedback.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Getting_Started.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Getting_Started.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Getting_Started.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Introduction.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Introduction.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Introduction.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Lucene_Native.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Lucene_Native.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Lucene_Native.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Mapping.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Mapping.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Mapping.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Optimize.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Optimize.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Optimize.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Preface.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Preface.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Preface.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Query.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Query.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Query.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Revision_History.pot
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Revision_History.pot 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.5/Hibernate/Hibernate_Search/pot/Revision_History.pot 2009-09-03 22:27:07 UTC (rev 93193)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2009-03-23 03:01+0000\n"
+"POT-Creation-Date: 2009-07-16 03:51+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc at kde.org>\n"
Modified: projects/docs/enterprise/4.3.6/Installation_Guide/en-US/Getting_Started.xml
===================================================================
--- projects/docs/enterprise/4.3.6/Installation_Guide/en-US/Getting_Started.xml 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/4.3.6/Installation_Guide/en-US/Getting_Started.xml 2009-09-03 22:27:07 UTC (rev 93193)
@@ -11,7 +11,24 @@
</para>
<section id="Pre_Requisites-Hardware_and_Operating_System_Requirements">
<title>Hardware and Operating System Requirements</title>
-
+ <!-- <formalpara>
+ <title>Minimum Hardware Requirements</title>
+ <para>
+ Detailed in this section are the minimum hardware requirements in reguards to a server using the <classname>production</classname> configuration shipped with the JBoss Enterprise Application Platform.
+ </para>
+ </formalpara>
+ <itemizedlist>
+ <listitem>
+ <para>
+ 1GB of disk space. This includes 240MB required for the installation or unpacked distribution and disk space necessary for the server log files.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ </itemizedlist> -->
<para>For the latest information on supported Operating System / JVM combinations and supported Database platforms, please refer to <ulink url="http://www.jboss.com/products/platforms/application/testedconfigurations">http://www.jboss.com/products/platforms/application/testedconfigurations</ulink>.
</para>
<!-- <para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-09-03 19:41:47 UTC (rev 93192)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Transactions.xml 2009-09-03 22:27:07 UTC (rev 93193)
@@ -1,193 +1,544 @@
<?xml version='1.0'?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
-]>
-<chapter id="transaction"><title>JBoss Transactions</title>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<chapter id="transaction">
+ <title>Transaction Management</title>
+ <section>
+ <title>Overview</title>
+ <para>Transaction support in JBoss EAP is provided by JBossTS, a mature, modular,
+ standards based, highly configurable transaction manager. By default the
+ server runs with the local-only JTA module of JBossTS installed. This module
+ provides an implementation of the standard JTA API for use by other internal
+ components, such as the EJB container, as well as direct use by application
+ code. It is suitable for coordinating ACID transactions that involve one or
+ more XA Resource managers, such as databases or message queues.</para>
+ <para>Two additional, optional, JBossTS transaction modules are also shipped with
+ JBossEAP and may be deployed to provide additional functionality if
+ required. These are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>JBossTS JTS, a transaction manager capable of distributing
+ transaction context on remote IIOP method calls, thus
+ creating a single distributed transaction spanning multiple
+ JVMs. This is useful for e.g. large scale applications that
+ span multiple servers, or for standards based
+ interoperability with transactional business logic running
+ in CORBA based systems. The functionality of this module can
+ be accessed through the standard JTA API, making it a
+ drop-in replacement that does not require changes to
+ transactional business logic. It is necessary only to change
+ the server configuration. Details of this process are given
+ below.</para>
+ </listitem>
+ <listitem>
+ <para>JBossTS XTS, an XML based transaction service implementing the
+ WS-AtomicTransaction (WS-AT) and WS-BusinessActivity (WS-BA)
+ version 1.2 specifications. This additional module utilizes
+ core transaction support provided by the JTA or JTS, as well
+ as web services functionality provided by JBossWS Native. It
+ is deployed into the server as an application, a process
+ detailed below. Applications may use WS-AT to provide
+ standards based, distributed ACID transactions in a manner
+ broadly similar to JTS but using a web services transport
+ rather than a CORBA one. The WS-BA implementation
+ compliments this by providing an alternative, compensation
+ based transaction model, well suited to coordinating long
+ running, loosely coupled business processes. XTS also
+ implements a WS-Coordination service which, usually, is only
+ accessed internally by the local WS-AT and WS-BA
+ implementations. However, this WS-C service can also be used
+ to provide remote coordination for WS-AT and WS-BA
+ transactions created in other JBoss AS instances or
+ non-JBoss containers.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section>
+ <title>Configuration Essentials</title>
+ <para>Configuration of the default JBossTS JTA is managed though a combination of
+ the transaction manager's own properties file and the application server's
+ deployment configuration. The configuration file resides at
+ server/[name]/conf/jbossts-properties.xml It contains defaults for the most
+ commonly used properties. Many more are detailed in the accompanying JBossTS
+ documentation and can be added to the configuration file as needed. All also
+ have hard-coded defaults, but the system may not function exactly as
+ expected in the absence of a properties file. The configuration given in
+ this file is supplemented by the microcontainer beans configuration found in
+ the server/[name]/deploy/transaction-jboss-beans.xml file. This ties the
+ transaction manager into the wider server configuration, overriding the
+ transaction config file settings with application server specific values
+ where appropriate. In particular, it uses the service binding manager to set
+ port binding information and overrides selected other properties.
+ Configuration properties are read by JBossTS at server initialization and
+ changes made thereafter, either to the properties file, beans file, or
+ programatically, will not have an effect until server (JVM) restart.</para>
+ <para>The most critical bean properties are:</para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>transactionTimeout – the default time, in seconds,
+ after which a transaction will be considered to be
+ stuck and may be rolled back by the transaction
+ manager.</para>
+ <para>The transaction timeout functionality is useful to
+ prevent poorly written code, such as large SQL
+ queries, from blocking the system indefinitely. The
+ default value is 300 seconds. This should be
+ adjusted to suit your environment and
+ workload.</para>
+ <para>Note that transaction timeouts are processed
+ asynchronously, a design decision which can take
+ some applications by surprise. See the transaction
+ timeout handling section below for more
+ details.</para>
+ </listitem>
+ <listitem>
+ <para>objectStoreDir - the directory to which transaction
+ data will be logged. This bean property overrides
+ the jbossts-properties.xml config file value for
+ com.arjuna.ats,arjuna,objectstore.objectStoreDir</para>
+ <para>This transaction log is required to complete
+ transactions in the case of system failures. The
+ performance and reliability of the storage device
+ used for it are critical. In general, local RAID
+ disk should be preferred. Remote storage may be used
+ provided it correctly implements file locking.
+ However, requiring network I/O for this storage can
+ be a significant bottleneck on performance. The
+ ObjectStore will normally contain one file per
+ in-flight transaction, each a few kbytes in size.
+ These are distributed over a directory tree for
+ optimal performance. The small file size and rapid
+ creation/deleting of files lends itself well to SSD
+ based storage devices, although traditional hard
+ drives may of course still be used. If a RAID
+ controller is used, it should be configured for
+ write through cache, in much the same manner as
+ database storage devices. Writing of the transaction
+ log is automatically skipped in the case of
+ transactions that are rolling back or contain only a
+ single resource.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
-<para>
- <indexterm><primary>JBoss Enterprise Application Platform</primary><secondary>transactions</secondary></indexterm>
- <indexterm><primary>JBoss Transactions</primary></indexterm>
-JBoss Transactions runs in the <emphasis>all</emphasis> server configuration or customized configurations based on the <emphasis>all</emphasis> configuration. </para>
-
-
-<figure id="transactions_architecture">
- <title>Transactions Architecture</title>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/transactions-architecture.png" />
- </imageobject>
- </mediaobject>
-</figure>
-
-
-<section><title>Why you need JBoss Transactions</title>
- <para>
- In todays business environment data corruption can have serious consequences for the enterprise including service unavailability, system reconciliation costs, and damage to customer relationships and business reputation. The JBoss Transaction Service (JBossTS) protects businesses from data corruption by guaranteeing complete, accurate business transactions for Java based applications (including those written for the JEE and EJB frameworks) thereby eliminating the risks and costs associated with time-consuming manual reconciliation that follow failures.
- </para>
-
-</section>
-
-
-<section><title>JBoss Transactions Java EE 5 Support</title>
-<para>In the modern business environment of system consolidations, worldwide utilization, and <emphasis>always on</emphasis> availability, enterprises need distributed transaction processing infrastructure. This enables businesses to build reliable, sophisticated applications that can guarantee absolute completion and accuracy of business processes. Transaction services ensure that sequences of database updates have been accurately and reliably committed as a single complete unit of work or that, in the event of failure, the database information is recovered. <emphasis>Multimodal Transaction Processing</emphasis> is the term coined by Gartner to describe the new generation of transactional application required to face the challenges posed by new business requirements, technologies and innovative computing architectures. </para>
-<note>
-<para>"Multimodal transaction processing will emerge. Users' adoption of client/server, the Internet, service-oriented architecture, Web services, mobile and wireless devices, and event-driven architectures means that the next generation of transaction processing applications will have to be implemented in very different ways to respond to new business strategies, including multichannel, the real-time enterprise and business process fusion." Predicts 2004: Prepare for Multimodal Transaction Processing, M. Pezzini, Gartner, 19 December 2003 </para></note>
-
-<para>JBoss Transaction Services is a middleware solution that supports mission-critical applications in distributed computing environments. It plays a critical role in building reliable, sophisticated e-business applications guaranteeing absolute completion and accuracy of business processes; supporting <emphasis>multimodal transaction processing</emphasis> by enabling reliable transactions to span from front-end e-commerce applications to back office systems and beyond the enterprise firewall to business partners across any system, anywhere in the world. </para>
-<para>Building on the industry proven Java EE 5 transaction technology, native support is included for Web service transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web service-based applications with minimal effort. The product supports the <classname>WS-AtomicTransaction</classname> and <classname>WS-BusinessActivity</classname> specifications. </para>
-</section>
-
-<section>
- <title>JBoss Transactions Web Services Support</title>
-
-<para>In traditional ACID transaction systems, transactions are short lived, resources (such as databases) are locked for the duration of the transaction and participants have a high degree of trust with each other. With the arival of the Internet and Web services, the scenario that is now emerging requires involvement of participants unknown to each other in distributed transactions. These transactions have the following characteristics: </para>
-<para>
-<orderedlist>
-<listitem>
-<para>Transactions may be of a long duration, sometimes lasting hours, days, or more. </para>
-</listitem>
-<listitem>
-<para>Participants may not allow their resources to be locked for long durations. </para>
-</listitem>
-<listitem>
-<para>The communication infrastructure between participants may not be reliable. </para>
-</listitem>
-<listitem>
-<para>Some of the ACID properties of traditional transactions are not mandatory. </para>
-</listitem>
-<listitem>
-<para>A transaction may succeed even if only some of the participants choose to confirm and others cancel. </para>
-</listitem>
-<listitem>
-<para>All participants may choose to have their own coordinator (Transaction Manager), because of lack of trust. </para>
-</listitem>
-<listitem>
-<para>All activities are logged. </para>
-</listitem>
-<listitem>
-<para>Transactions that have to be rolled back have the concept of compensation. </para>
-</listitem>
-</orderedlist>
-</para>
-</section>
-
-<section>
- <title>How JBossTS address these issues</title>
- <para>Programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product includes protocol support for the <classname>WS-AtomicTransaction</classname> and <classname>WS-BusinessActivity</classname> specifications. JBoss Transaction Services included with the JBoss Enterprise Application Platform is designed to support multiple coordination protocols and assist to future-proof transactional applications. For a more detailed description of the product capabilities, see the full feature list below. </para>
-<para>JBoss Transaction Services is a pure Java multi-modal transaction service that supports distributed transactions in CORBA, JEE and Web services environments.</para>
-<orderedlist>
-<listitem>
-<para>Standards compliance </para>
-<orderedlist>
-<listitem>
-<para>CORBA Object Transaction Service (OTS) </para>
-</listitem>
-<listitem>
-<para>Java Enterprise (JEE) transactions </para>
-<orderedlist>
-<listitem>
-<para>Java Transaction API (JTA) </para>
-</listitem>
-<listitem>
-<para>Java Transaction Service (JTS) </para>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<para>Web services transactions </para>
-<orderedlist>
-<listitem>
-<para>Web Services Coordination (WS-Coordination) </para>
-</listitem>
-<listitem>
-<para>Web Services Atomic Transaction (WS-AtomicTransaction) </para>
-</listitem>
-<listitem>
-<para>Web Services Business Activity Framework (WS-BusinessActivity) </para>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<para>JEE and CORBA transactioning features </para>
-<orderedlist>
-<listitem>
-<para>Complete distributed transaction support </para>
-</listitem>
-<listitem>
-<para>Automated failure recovery system </para>
-</listitem>
-<listitem>
-<para>Flexible deployment: centralized and distributed transaction manager options </para>
-</listitem>
-<listitem>
-<para>Interposition support for improved distributed transaction performance </para>
-</listitem>
-<listitem>
-<para>POA ORB support </para>
-</listitem>
-<listitem>
-<para>Support for both checked and unchecked transaction behaviour </para>
-</listitem>
-<listitem>
-<para>Support for both flat and nested transaction models, with nested-aware resources and resource adapters </para>
-</listitem>
-<listitem>
-<para>Support for CosTransaction::Current API </para>
-</listitem>
-<listitem>
-<para>Direct and indirect transaction management </para>
-</listitem>
-<listitem>
-<para>Synchronization interface support </para>
-</listitem>
-<listitem>
-<para>Transaction heuristic support </para>
-</listitem>
-<listitem>
-<para>Explicit and implicit transaction context propagation </para>
-</listitem>
-<listitem>
-<para>Multi-thread aware </para>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<para>Web services transactioning features </para>
-<orderedlist>
-<listitem>
-<para>Ensures reliable coordination and application data consistency for business processes that involve Web services. </para>
-</listitem>
-<listitem>
-<para>Supports transaction models for both intra-enterprise (EAI) and inter-enterprise (supply chain) Web services integration. </para>
-</listitem>
-<listitem>
-<para>Allows for consistent real-time updates across any component or resource involved in the business process. </para>
-</listitem>
-<listitem>
-<para>Fully automated crash recovery provides fast, unattended restoration of service after component failures. </para>
-</listitem>
-<listitem>
-<para>Future-proof, generic coordination engine architecture supports pluggable protocols. </para>
-</listitem>
-<listitem>
-<para>Currently supports the WS-Coordination WS- AtomicTransaction and WS-BusinessActivity specifications. Supports the leveraging of existing transaction infrastructure investments. </para>
-</listitem>
-<listitem>
-<para>Architected for portability across a wide- range of Web services platforms. Supports the open source JBoss application server for highly cost effective development and deployment. </para>
-</listitem>
-<listitem>
-<para>Close integration with enterprise Java standards, allowing Web services transactions to seamlessly integrate with JEE application servers, messaging systems and database back- ends. </para>
-</listitem>
-<listitem>
-<para>Easy to use Java programming interfaces, based on the emerging JAXTX standard. A rich programming framework reduces overhead in adding transactioning capabilities to Web services. </para>
-</listitem>
-<listitem>
-<para>Leverages Arjuna's long history in transaction software, including the industry proven coordination engine, ArjunaCore - as used in the Bluestone and HP application servers. </para>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</section>
-
+ <para>The following additional configuration properties present in the
+ jbossts-properties.xml may also be of interest:</para>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>com.arjuna.common.util.logging.DebugLevel</para>
+ <para>This setting determines the internal log threshold for
+ the transaction manager codebase. It is independent
+ of the server's wider log4j logging configuration
+ and represents an additional hurdle that log
+ messages must pass before being printed. The default
+ value is “0x00000000” i.e. no debug logging. INFO
+ and WARN messages will still be printed by default.
+ This provides optimal performance. The value
+ “0xffffffff” should be used when full debug logging
+ is required. This is very verbose and will result in
+ large log files. Log messages that pass the internal
+ DebugLevel check will be passed to the server's
+ logging system for further processing. Thus it may
+ also be necessary to set appropriate configuration
+ for “com.arjuna” code in the
+ server/[name]/conf/jboss-log4j.xml file. Note that
+ whilst a value of “0xffffffff” may be left in place
+ permanently and the log4j settings used to turn
+ logging on or off, this is less performant than
+ using the internal DebugLevel checking.</para>
+ </listitem>
+ <listitem>
+ <para>com.arjuna.ats.arjuna.coordinator.commitOnePhase</para>
+ <para>This setting determines if the transaction manager
+ will automatically apply the one-phase commit
+ optimization to the transaction completion protocol
+ in cases where only a single resource is registered
+ with the transaction. It is enabled (“YES”) by
+ default to provide optimal performance, since no
+ transaction log write is necessary in such cases.
+ Some resource managers may not be compatible with
+ this optimization and it is occasionally necessary
+ to disable it. This can be done by changing the
+ value to “NO”.</para>
+ </listitem>
+ <listitem>
+ <para>com.arjuna.ats.arjuna.objectstore.transactionSync</para>
+ <para>This setting controls the flushing of transaction logs
+ to disk during the transaction termination. It is
+ enabled (“ON”) by default, which results in a
+ FileDescriptor.sync call for each committing
+ transaction. This is required to provide recovery
+ guarantees and hence ACID properties. If the
+ applications running in the server can tolerate data
+ inconsistency or loss, greater performance may be
+ achieved by disabling this behavior by setting the
+ property value to “OFF”. This is not recommended –
+ it is usually preferable to recraft such
+ applications to avoid using the transaction manager
+ entirely.</para>
+ </listitem>
+ <listitem>
+ <para>com.arjuna.ats.arjuna.xa.nodeIdentifier and
+ com.arjuna.ats.jta.xaRecoveryNode</para>
+ <para>These properties determine the behavior of the
+ transaction recovery system. Correct configuration
+ is essential to ensure transactions are resolved
+ correctly in the event of a server crash and
+ restart. See the crash recovery section below for
+ details.</para>
+ <para>Additional properties that may be added to the
+ jbossts-properties.xml include the following. Care
+ should be taken to place these in the appropriate
+ section of the file, or they may not be correctly
+ processed.</para>
+ </listitem>
+ <listitem>
+ <para>com.arjuna.ats.arjuna.coordinator.enableStatistics</para>
+ <para>This property enables the gathering of transaction
+ statistics, which may be viewed via methods on the
+ TransactionManagerService bean or, more commonly,
+ its corresponding JMX MBean. This option is disabled
+ by default, as the additional locking needed to
+ record statistics accurately may cause a slight
+ performance impact. Thus the statistics getter
+ methods will thus normally return zero values. To
+ enable the option, set its value to “YES” in the
+ properties file.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+ <section>
+ <title>Transactional Resources</title>
+ <para>The transaction manger coordinates the update of state via XAResource
+ implementations, which are provided by the various resource managers. In
+ most instances, resource managers will be databases, message queues or 3rd
+ party JCA resource adapters. The list of JDBC database drivers and servers
+ certified for use with JBoss EAP can be found on the redhat.com website. In
+ addition there is a reasonable probability of any driver that complies with
+ the relevant standards functioning correctly. However, interpretation of the
+ XA specification does differ from one vendor to another, as does quality of
+ driver code. For maximum surety in transactional applications, thorough
+ testing is essential, especially with regard to recovery behavior. </para>
+ <para>Database connection pools configured via the application server's -ds.xml
+ files using <![CDATA[<xa-datasource>]]> (see chapter 11) will automatically
+ interact with the transaction manager. i.e. Connections obtained by looking
+ up such datasource in JNDI and calling getConnection will automatically
+ participate correctly in an ongoing transaction. This is the dominant use
+ case and should be preferred where transactional guarantees for data access
+ are required. For cases where the database cannot support XA transactions,
+ it it also feasible to deploy a connection pool using
+ <![CDATA[<local-xa-datasource>]]> Such datasources participate in the
+ managed transaction using the last resource commit optimization (see below)
+ and as such provide more limited transactional guarantees. Applications
+ using this approach should be aware of the limitations and implemented
+ accordingly. Connections obtained from a <![CDATA[<no-tx-datasource>]]> will
+ not interact with the transaction manager and any work done on such
+ connections must be explicitly committed or rolled back by the application
+ via the JDBC API.</para>
+ <para>Many databases require additional configuration if they are to be used as XA
+ resource managers. For example, MS SQL Server requires configuration of the
+ DTC service and installation of a server side component of the JDBC drivers.
+ Some versions of Oracle similarly require a server side package to be
+ installed in the database instance. PostgreSQL installations may require an
+ alteration to the number of outstanding transactions they permit – the
+ default is normally too low for production usage. MySQL has significant
+ limitations on its XA implementation and is not recommended for use in an XA
+ transaction. If it is used, the InnoDB storage engine must be configured.
+ Please consult your DBA or database documentation for further product
+ specific information. In addition, it is important to take any further
+ database configuration steps needed to support XA recovery, see the recovery
+ section below.</para>
+ <para>JBoss Messaging provides an XA aware driver and can participate in XA
+ transactions. This is also the case for many 3rd party message queuing (JMS)
+ products, subject to the same caveats on product specific configuration as
+ with databases.</para>
+ </section>
+ <section>
+ <title>Last Resource Commit Optimization (LRCO)</title>
+ <para>Although the XA transaction protocol is designed to provide ACID properties by
+ using a two phase commit protocol, it is recognized that this is not
+ possible in all circumstances. In particular, it is occasionally necessary
+ to have a resource manager that is not XA aware participate in the
+ transaction. This is often the case with data stores that can't or won't
+ support distributed transactions. For such circumstances it is possible to
+ employ a technique variously known as the Last Resource Gambit or last
+ Resource Commit Optimization. Using this technique, the one phase resource
+ is processed last in the prepare phase of the transaction, at which time an
+ attempt is made to commit it. If successful, the transaction log is written
+ and the remaining resources go through the phase two commit. If the last
+ resource fails to commit, the transaction is rolled back. Whilst this
+ protocol allows for most transactions to complete normally, certain types of
+ error can cause an inconsistent transaction outcome. Therefore, we recommend
+ using this approach only when no alternative is available. Where a single
+ <![CDATA[<local-tx-datasource>]]> is used in a transaction, the LRCO will be
+ automatically applied to it. For other cases it is possible to designate a
+ last resource by using a special marker interface. See the JBossTS
+ documentation for details.</para>
+ <para>It is not transactionally safe (or rather, it is even more unsafe) to use more
+ than a single one-phase resource in the same transaction. For this reason
+ JBossTS treats an attempt to enlist a second such resource as an error and
+ will terminate the transaction. This use case is most commonly found in
+ applications migrating from JBossAS 4.0.x servers, where this usage was not
+ considered an error. Whenever possible the <![CDATA[<local-tx-datasource>]]>
+ should be changed to <![CDATA[<xa-datasource>]]> to resolve the difficulty.
+ Where this is not possible, the transaction manager may be configured to
+ allow multiple last resources. Although this is not recommended, details of
+ the configuration steps may be found on the jboss.org wiki.</para>
+ </section>
+ <section>
+ <title>Transaction Timeout Handling</title>
+ <para>In order to prevent indefinite locking of resources, the transaction manager
+ will abort in-flight transactions that have not completed after a specified
+ interval. This abort is done by a set of background processes, coordinated
+ by the TransactionReaper. It should be noted that the reaper will rollback
+ transactions without interrupting any threads that may be operating within
+ their scope. This prevents instability that can result from interrupting
+ threads executing arbitrary code. Furthermore, it allows for timely abort of
+ transactions where the business logic thread may be executing
+ non-interruptable operations such as network I/O calls. This approach may,
+ however, cause unexpected behavior in code that is not designed to handle
+ multithreaded transactions. Warning or error messages may be printed from
+ e.g. hibernate or other transaction aware components as a result of the
+ unexpected transaction status change. These should not affect the
+ transaction outcome. The problem can be minimized by appropriate turning of
+ the transaction timeout.</para>
+ </section>
+ <section>
+ <title>Recovery Configuration</title>
+ <para>To ensure that the transaction manager can, upon server restart after a crash,
+ successfully complete any prepared transactions, it is necessary to
+ configure the recovery system correctly.</para>
+ <para>After the prepare phase of the transaction commit, the transaction manager
+ writes state information to disk in order that, should a failure occur, it
+ can still complete the transaction and thereby assure ACID properties. The
+ transaction log storage, which JBossTS terms the ObjectStore, should be
+ configured in accordance with the guidance provided above. In addition, it
+ is necessary to configure the recovery system to process the logs.</para>
+ <para>The information that is written into the logs includes the transaction
+ identity and the xid values associated to the XAResources enlisted with the
+ transaction. In case where the XAResource itself implements Serializable, it
+ is also written to the log. Such cases simplify recovery considerably, but
+ unfortunately are a minority. Most XAResources, including those presented to
+ the transaction manager by the application server's
+ <![CDATA[<xa-datasource>]]>, are not Serializable. Therefore, it is
+ necessary to explicitly provide the transaction manager with sufficient
+ information to instantiate a new XAResource instance connected to the same
+ resource manager upon server restart. For resource managers configured by
+ <![CDATA[<xa-datasource>]]> elements in -ds.xml files, this is best achieved
+ by using the AppServerJDBCXARecovery plugin. One instance is required for
+ each resource manager. JBoss Messaging includes its own recovery plugin,
+ which must be configured if messaging operations are required within a
+ transaction. Refer to the JBoss Messaging documentation for further details.
+ Users may develop their own plugins for resource managers not covered by the
+ previous cases, by implementing the XAResourceRecovery interface. See the
+ JBossTS documentation for further details.</para>
+ <para>In addition to configuring the recovery plugins, it is necessary to set a
+ unique identifier for each JBossTS (i.e. application server) instance and to
+ configure which node identifiers each server will attempt to recover. For
+ most situations it is recommended that each server instance operate
+ independently, using its own ObjectStore and recovering its own
+ transactions. In such cases the com.arjuna.ats.arjuna.xa.nodeIdentifier and
+ com.arjuna.ats.jta.xaRecoveryNode properties in each server instance should
+ share the same value and this value should be unique to the instance.</para>
+ </section>
+ <section>
+ <title>Troubleshooting</title>
+ <para>This section presents guidance on the possible causes are resolutions for
+ common transaction related problems.</para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>I turned on debug logging, but nothing shows
+ up.</para>
+ <para>JBossTS sends log statements though two levels of
+ filters. Firstly, its own internal logging
+ abstraction layer, then the application server's
+ log4j. A log statement must pass both filters to be
+ printed. The most likely case is that's you have
+ enabled only one or the other. See information on
+ the DebugLevel property above.</para>
+ </listitem>
+ <listitem>
+ <para>My server logs show <code>WARN Adding multiple last
+ resources is disallowed.</code> and my
+ transactions are aborted. Why?</para>
+ <para>You are probably using
+ <![CDATA[<local-xa-datasource>]]> rather than
+ <![CDATA[<xa-datasource>]]> See the Last Resource
+ Commit Optimization section above and refer to
+ http://www.jboss.org/community/wiki/Multiple1pc</para>
+ </listitem>
+ <listitem>
+ <para>My server crashed (or was killed). Now it's running
+ again, but my logs are filling with <code>WARN
+ [com.arjuna.ats.jta.logging.loggerI18N]
+ [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa]
+ Could not find new XAResource to use for
+ recovering non-serializable
+ XAResource</code></para>
+ <para>You probably forgot to configure recovery for one or
+ more resource managers used in a transaction. See
+ the recovery section above and
+ http://www.jboss.org/community/wiki/TxNonSerializableXAResource</para>
+ </listitem>
+ <listitem>
+ <para>My transactions take a long time and sometimes strange
+ things happen. The server log contains <code>WARN
+ [arjLoggerI18N] [BasicAction_58] - Abort of action
+ id ... invoked while multiple threads active
+ within it.</code></para>
+ <para>Transactions which exceed their timeout may be rolled
+ back. This is done by a background thread, which can
+ confuse some application code that may be expecting
+ an interrupt. See the transaction timeout handling
+ section above and
+ http://www.jboss.org/community/wiki/TxMultipleThreads</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>Additional information on these and other issues may be found in the JBossTS
+ documentation and on the wiki at
+ http://www.jboss.org/community/wiki/JBossTransactions</para>
+ </section>
+ <section>
+ <title>Installing JBossTS JTS</title>
+ <para>Users who require transaction propagation between business logic in different
+ servers will benefit from installing the JTS component. Although the JTS
+ does have its own API, it is most commonly accessed via the standard JTA
+ classes. In such cases, it's a drop in replacement for the default
+ local-only JTA implementation. The necessary implementation classes are
+ already in place, it is required only to modify the relevant config file to
+ move between the JTA and JTS modules. The directory
+ docs/examples/transactions/ contains a version of the jbossts-properties.xml
+ file suitable for running the JTS mode. It also contains a README.txt file
+ detailing the changes necessary to various other files, including the
+ transactions-jboss-beans.xml. An ant script which will perform these steps
+ on your behalf is also included. However, we strongly recommend to consult
+ the README file for additional information before running the script, as
+ well as backing up any server configuration files which may be changed. Note
+ that it is necessary to install the JTS into a server configuration that
+ also contains the CORBA ORB service, as the JTS relies on this. We recommend
+ the 'all' configuration as a starting point for this. The selection of
+ distributed JTA (JTS, also known internally as jtax) or local-only JTA (the
+ default) is done at the server level. The additional complexity of the JTS
+ carries a slight performance overhead, so it is recommended to install the
+ JTS only for servers which host applications requiring transaction context
+ distribution. Servers running JTA will log:</para>
+ <para>
+ <code>INFO [TransactionManagerService] JBossTS Transaction Service (JTA
+ version - ...)</code>
+ </para>
+ <para>at startup, whereas those running the JTS will log:</para>
+ <para>
+ <code>INFO [TransactionManagerService] JBossTS Transaction Service (JTS
+ version - ...)</code>
+ </para>
+ </section>
+ <section>
+ <title>Installing JBossTS XTS</title>
+ <para>The Web Services transaction component, XTS, may be installed to provide WS-AT
+ and WS-BA support for web services hosted in the server. The application is
+ packaged as a .sar file found in docs/examples/transactions/ and should be
+ installed by unpacking this archive into the a new jbossxts.sar directory
+ which you should create in the server/[name]/deploy/ directory of a suitable
+ server. Consult the README.txt in docs/examples/transactions/ for any
+ additional deployment information. The server must also be running either
+ JBossTS JTA or JTS and JBossWS Native. Note that XTS is not currently
+ expected to work with other JBossWS backends such as CXF. The default XTS
+ configuration is suitable for most usage and will automatically pick up
+ network interface and port binding information from the application server
+ configuration. Manual configuration changes are necessary only for
+ deployments where applications require use of a transaction coordinator on a
+ separate host, for which the XTS documentation should be consulted. The
+ directory tree created by unpacking the jbossxts.sar file will contain a
+ jbossxts-api.jar Developers may link against this .jar at build time, but
+ should not package it with their applications in order to avoid classloading
+ problems. The remaining .jar files contain internal implementation classes
+ and should not be used directly by application code.</para>
+ </section>
+ <section>
+ <title>Transaction Management Console</title>
+ <para>To facilitate investigation of issues resulting from heuristic or unrecovered
+ transactions, a simple GUI tool is available for inspection of the internal
+ state of the ObjectStore, in which transaction state logs are recorded. The
+ tool allows users to view transactions and their enlisted resources, as well
+ as forcing transaction resolutions i.e. commit or rollback. The tool is an
+ unsupported experimental prototype and should be used at your own risk. It
+ is available from docs/example/transactions/ and the README.txt file in that
+ directory describes how it may be deployed. </para>
+ </section>
+ <section>
+ <title>Experimental Components</title>
+ <para> In addition to the supported components of JBossTS that ship as part of JBoss
+ EAP, there is ongoing feature work that may eventually find its way into
+ future releases of the product. Meanwhile these prototype components are
+ available via from the jboss.org community site. Users are cautioned that
+ there is no guarantee these will work correctly and nor are they covered by
+ the EAP support agreement. However, some of the advanced functionality
+ available may nevertheless be attractive to projects in the early stages of
+ development. Users downloading these prototypes must be aware of the
+ limitations concerning module compatibility, in accordance with the 'source
+ code and customization' section below.</para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>txbridge</para>
+ <para>For certain use cases it is desirable to be able to
+ invoke traditional transaction components such as
+ EJBs, within the scope of a Web Services
+ transaction. Likewise, such components may wish to
+ invoke transactional web services. This involves two
+ distinct transaction types: JTA i.e. XA based
+ transactions for the JEE components and WS-AT
+ transactions for the web services. It is necessary
+ to integrate these transactions into a single entity
+ spanning all the involved components. It is this
+ problem that the transaction bridge
+ addresses.</para>
+ </listitem>
+ <listitem>
+ <para>BA Framework</para>
+ <para>The techniques required for writing extended,
+ compensation based transactions for WS-BA are still
+ in their infancy. The API provided by XTS is low
+ level, requiring the business programmer to
+ undertake much of the transaction plumbing work. The
+ BA Framework provides high level annotations that
+ move responsibility for much of the transaction
+ handling into the application server middleware.
+ Using the framework, programmers can focus on
+ writing business logic and thus be considerably more
+ productive.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+ <section>
+ <title>Source code and upgrading</title>
+ <para> Most transaction related problems can be diagnosed by JBoss support, upon
+ provision of debug logs from the server. However, it is occasionally
+ desirable to be able to step though transaction code in a debugger, or
+ simply to review the code to help understanding of the provided
+ functionality.</para>
+ <para> The source code for JBossTS can be downloaded direct from the project's svn
+ repository at http://anonsvn.jboss.org/repos/labs/labs/jbosstm/ To find the
+ version matching the binaries in JBoss EAP, consult your server logs. At
+ startup the server prints a string similar to:</para>
+ <para>INFO [TransactionManagerService] JBossTS Transaction Service (JTA version -
+ tag:JBOSSTS_4_6_1_GA_CP02) - JBoss Inc.</para>
+ <para>The value given for the tag corresponds to a tree under /tags/ in the svn
+ repository. Note that the version refers to the JBossTS releases consumed by
+ EAP, not the EAP release numbering. Users building the EAP from source may
+ also consult the version.jboss.jbossts value in
+ component-matix/pom.xml</para>
+ <para>Please note that installing any version of JBossTS other than those provided
+ with the EAP distribution or its CP releases is not supported. Also note
+ that, whilst some JBossTS components are packaged individually, it is not
+ supported to mix and match versions. i.e. do not run the JTA from one tag
+ with the XTS from another. API and functionality changes between releases
+ may make this unstable.</para>
+ </section>
</chapter>
More information about the jboss-cvs-commits
mailing list