Transactions Development Quick Start Guide


JBoss Enterprise Application Platform 5

Erste Schritte mit dem JBoss Transaction Service

Ausgabe 5.1.0

Andrew Dinn

Red Hat

Mark Little

Red Hat

Jonathan Halliday

Red Hat
Herausgegeben von

Misty Stanley-Jones

Red Hat

Zusammenfassung

Dieses Handbuch ist eine schnelle Einführung für Java-Entwickler, die Anwendungen mittels der JBoss Transaction Service APIs schreiben möchten.

Kapitel 1. Erste Schritte mit JTA

Dieses Kapitel fasst die Schlüsselfeatures zusammen, die zur Konstruktion einer Java Transactions API (JTA)-Anwendung benötigt werden. Falls Sie nicht mit dem JTA vertraut sind, beginnen Sie bitte damit, dass Sie den ersten Abschnitt des Transactions Development Guide lesen, der als Teil des Enterprise Application Platform Dokumentationssatzes geliefert wird.

1.1. Paket-Layout

Alles, was Sie brauchen, um einfache JTA-Anwendungen zu schreiben ist in der Enterprise Application Platform enthalten. Die Schlüsselpakete werden in Pakete, die mit dem JTA zu tun haben erläutert.

Pakete, die mit dem JTA zu tun haben

com.arjuna.ats.jts
Enthält die JBoss Transaction Service Implementierung des JTS und JTA APIs (Application Programming Interfaces).
com.arjuna.ats.jta
Enthält lokalen und remote JTA-Implementierungssupport.
com.arjuna.ats.jdbc
Enthält transaktionalen JDBC 2.0 Support.

1.2. Einstellung der Properties

Sie können JBossJTA zur Runtime durch Einstellung verschiedener Property-Attribute konfigurieren. Dies kann entweder zur Runtime über die Befehlszeile oder durch eine Properties-Datei erfolgen. Die anfängliche Properties-DAtei befindet sich in $JBOSS_HOME/server/default/conf/jbossts-properties.xml.

1.2.1. Festlegung des "Object Store" Speicherorts

JBossJTA verwendet einen "Object Store" zur persistenten Speicherung der Transaktionsergebnisse, die im Falle von Ausfällen verwendet werden. Zur Anpassung des Speicherorts des Object Stores müssen Sie den Speicherort eingeben wenn Sie die Anwendung ausführen wie in Beispiel 1.1, »Spezifikation des Object Store« dargestellt.

Beispiel 1.1. Spezifikation des Object Store

	  java –Dcom.arjuna.ats.arjuna.objectstore.objectStoreDir=/location/of/objectstore myprogram
Copy to Clipboard Toggle word wrap
Standardmäßig befindet sich der Object Store in einem Verzeichnis unterhalb des aktuellen Ausführungsverzeichnisses.
Standardmäßig werden alle Objektstati innerhalb des defaultStoreUnterverzeichnisses des Objektspeicherroot verwahrt. Sie können das Unterverzeichnis ändern, indem Sie die com.arjuna.ats.arjuna.objectstore.localOSRoot-Propertyvariable einstellen.

1.3. Demarkierung von Transaktionen

Das JBossJTA API besteht aus drei Elementen:
  • Ein Appliaktionstransaktion-Demarations-Interface auf hoher Ebene
  • Ein für den Applikationsserver vorgesehenesTransaktions-Manager-Interface auf hoher Ebene
  • und ein Standard Java-Mapping des X/Open XA-Protokolls, das für den transaktionalen Ressourcen-Manager vorgesehen ist
Alle JTA-Klassen und Interfaces befinden sich im javax.transaction-Paket und die entsprechenden JBossJTA-Implementierungen im com.arjuna.ats.jta-Paket.

1.3.1. UserTransaction

Das UserTransaction-Interface gestattet es Applikationen, die Transaktionsgrenzen zu kontrollieren.
Sie können UserTransaction-Implementierungen via JNDI erhalten.

Beispiel 1.2. Steuerung von Transaktionen

	  // Initialize the context and get UserTransaction
	  InitialContext ic = new InitialContext();
	  UserTransaction utx = ic.lookup("java:comp/UserTransaction")
	  // start transaction work..
	  utx.begin();
	  .. do work
	  utx.commit();
Copy to Clipboard Toggle word wrap

1.3.2. TransactionManager

Das TransactionManager-Interface gestattet dem Applikationsserver die Kontrolle der Transaktionsgrenzen für die verwaltete Applikation.
Sie können TransactionManager-Implementierungen via JNDI erhalten.
	// Initialize the context and get the TransactionManager
	InitialContext ic = new InitialContext();
	TransactinoManager utm = ic.lookup("java:/TransactionManager")
Copy to Clipboard Toggle word wrap

1.3.3. Transaction

Das Transaction-Interface gestattet die Durchführung von Operationen an der mit dem Zielobjekt assoziierten Transaktion. Jede Transaktion auf oberster Ebene wird mit einem Transaction-Objekt assoziiert, wenn die Transaktion erstellt wird. Das Transaction-Objekt hat mehrere Anwendungsfälle wie in Anwendungsfälle des Transaction-Interface beschrieben.

Anwendungsfälle des Transaction-Interface

  • Beteiligt die durch die Applikation verwendeten transaktionalen Ressourcen.
  • Registrieren Sie sich für Transaktionssynchronisations-Callbacks
  • Schreiben Sie die Transaktion fest oder setzen Sie sie zurück.
  • Erhalten Sie den Status der Transaktion.
Sie können ein Transaction-Objekt erhalten, indem Sie die getTransaction-Methode des TransactionManager-Interface aufrufen wie in Beispiel 1.3, »Erhalt einer Transaktion« dargestellt.

Beispiel 1.3. Erhalt einer Transaktion

	  Transaction txObj = TransactionManager.getTransaction();
Copy to Clipboard Toggle word wrap

1.4. Lokale versus distribuierte JTA-Implementierungen

Sie sollten sich für die Transaktionsfortpflanzung zwischen Transaktions-Managern auf die JTS/OTS-Spezifikationen verlassen, um die Interoperabilität zwischen JTA-Applikationen sicherzustellen.

Prozedur 1.1. Wahl der lokalen JTA-Implementierung

  1. Setzen Sie die om.arjuna.ats.jta.jtaTMImplementation-Property auf com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple.
  2. Setzen Sie die com.arjuna.ats.jta.jtaUTImplementation-Property auf com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple.

Prozedur 1.2. Auswahl der distribuierten JTA-Implementierung

  1. Setzen Sie die com.arjuna.ats.jta.jtaTMImplementation-Property auf com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple.
  2. Setzen Sie die com.arjuna.ats.jta.jtaUTImplementation-Property auf com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple.

1.5. JDBC und Transaktionen

JBossJTA unterstützt die Erstellung von sowohl lokalen als auch distribuierten transaktionalen Anwendungen, die unter Verwendung der JDBC 2.0 APIs auf Datenbanken zugreifen. JDBC 2.0 unterstützt eine Zwei-Phasen-Festschreibung von Transaktionen und ist dem XA X/Open-Standard ähnlich. Der JDBC 2.0 Support befindet sich im com.arjuna.ats.jdbc-Paket.
JBossJTA integriert JDBC-Verbindungen innerhalb von Transaktionen, indem es transaktionale JDBC-Treiber bereitstellt, durch die alle Interaktionen erfolgen. Diese Treiber fangen alle Aufrufe ab und stellen sicher, dass diese bei den entsprechenden Transaktionen registriert und gelenkt werden. Es existiert ein einzelner Typ von transaktionalem Treiber durch den beliebige JDBC-Treiber gesteuert werden können. Dieser Treiber ist om.arjuna.ats.jdbc.TransactionalDriver, und er implementiert das java.sql.Driver-Interface.
Eine Weise der Herstellung der Verbindung ist die java.sql.DriverManager.getConnection-Methode. Nach Verbindungsherstellung überwacht JBossJTA alle Operationen. Sie können solche Verbindungen auf dieselbe Weise verwenden wie jede andere JDBC-Treiberverbindung.
JBossJTA-Verbindungen können simultan mit mehreren verschiedenen Transaktionen verwendet werden. Verschiedene Threads mit unterschiedlichen Begriffen der aktuellen Transaktion können dieselbe JDBC-Verbindung nutzen. JBossJTA führt für jede Transaktion innerhalb der JDBC-Verbindung Connection-Pooling durch. Obwohl mehrere Threads dieselbe Instanz der JDBC-Verbindung nutzen können, kann intern eine andere Verbindungsinstanz per Transaktion verwendet werden. Mit Ausnahme der close-Methode werden alle an der Verbindung durchgeführten Operationen auf Anwendungsebene nur an dieser transaktionsspezifischen Verbindung durchgeführt.
JBossJTA registriert die JDBC-Treiberverbindung über eine entsprechende Ressource automatisch bei der Transaktion. Endet die Transaktion, so schreibt diese Ressource Änderungen an der zugrundeliegenden Datenbank durch entsprechende Aufrufe am JDBC-Treiber entweder fest oder setzt diese zurück.

1.6. Konfigurierbare Optionen

Wichtige konfigurierbare Optionen zeigt die wichtigsten Konfigurationsfeatures sowie die möglichen Werte und Standards. Weitere Informationen finden Sie im Transactions Development Guide.

Wichtige konfigurierbare Optionen

com.arjuna.ats.jta.supportSubtransactions

Mögliche Werte

  1. Ja (Standard)
  2. Nein
com.arjuna.ats.jta.jtaTMImplementation

Mögliche Werte

  1. com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple
  2. com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple
com.arjuna.ats.jta.jtaUTImplementation

Mögliche Werte

  1. com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple
  2. com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple
com.arjuna.ats.jta.xaBackoffPeriod

Mögliche Werte

  1. Zeit in Sekunden
com.arjuna.ats.jdbc.isolationLevel

Mögliche Werte

  1. Jede unterstützte JDBC-Ebene

Kapitel 2. Erste Schritte mit JTS / OTS

Dieses Kapitel behandelt die Schlüsselfeatures, die zur Konstruktion einer einfachen OTS (Object Transaction Service)-Anwendung mittels der OTS-Interfaces wie in der Object Management Group (OMG)-Spezifikation definiert benötigt werden. Diese Arbeit richtet ihr Augenmerk auf Implementierungsdetails. Im Transactions Development Guide finden Sie einen konzeptuellen Überblick.

2.1. Paket-Layout

Expand
Tabelle 2.1. Wichtige Pakete, die zur Erstellung von OTS-Anwendungen benötigt werden
Paket
Beschreibung
com.arjuna.orbportability
Dieses Paket enthält die Klassen, die die ORB-Portabilitätsbibliothek und andere nützliche Dienstprogrammklassen bilden.
org.omg.CosTransactions
Dieses Paket enthält die Klassen, die das CosTransactions.idl-Modul bilden.
com.arjuna.ats.jts
Dieses Paket enthält die JBoss Transaction Service Implementierungen des JTS und JTA.
com.arjuna.ats.arjuna
Dieses Paket enthält weitere Klassen, die für die JBoss Transaction Service Implementierung des JTS benötigt werden.
com.arjuna.ats.jta
Dieses Paket enthält lokalen und remote JTA-Implementierungssupport.
com.arjuna.ats.jdbc
Dieses Paket enthält transaktionalen JDBC 2.0 Support.

2.2. Einstellung von Properties

Der JBoss Transaction Service ist zur Runtime mittels der verschiedenen Property-Attribute konfigurierbar, die in nachfolgenden Abschnitten beschrieben werden. Sie können diese Attribute zur Runtime in der Befehlszeile bereitstellen. Es ist jedoch oft praktischer sie durch die jbossts-properties.xml zu liefern, was an allen genannten Speicherorten stattfinden kann, in Suchreihenfolge, in Mögliche Speicherorte der jbossts-properties.xml-Datei . properties-Datei.

Mögliche Speicherorte der jbossts-properties.xml-Datei

  1. Das aktuelle Arbeitsverzeichnis.
  2. Das Home-Verzeichnis des ausführenden Benutzers.
  3. Der CLASSPATH mittels der getResource-Methode.
Wird die Properties-Datei gefunden, so werden alle ihre Einträge zu den System-Properties hinzugefügt und setzen die Standards außer Kraft. Sie können auch andere, nicht für den Transaction Service spezifische Properties festlegen.

2.3. Start und Stop von ORB und BOA/POA

BOA steht für Basic Object Adapter und POA steht für Portable Object Adepter.
Der JBoss Transaction Service muss ordnungsgemäß initialisiert sein, ehe ein Applikationsobjekt erstellt wird. Um dies zu gewährleisten, müssen Sie die initORB-Methode und entweder die initBOA oder die initPOA-Methoden der ORBInterface-Klasse verwenden, die im ORB Portability Handbuch beschrieben ist. Verwenden Sie nicht die im zugrunde liegenden ORB bereitgestellten ORB_init BOA_init oder create_POA-Methoden, da dies zum fehlerhaften Betrieb der Applikationen führen kann.

Beispiel 2.1. ORB-Initialisierung

public static void main (String[] args)
{
    ORBInterface.initORB(args, null);
    ORBInterface.initOA();
    . . .
};
Copy to Clipboard Toggle word wrap

ORBInterface-Methoden

orb
Gibt Referenzen zum ORB wieder
boa
Gibt Referenzen zum BOA wieder
poa
Gibt Referenzen zum POA wieder
rootPoa
Gibt Referenzen zum Root-POA wieder
shutdownOA
Fahren Sie das BOA herunter. Führen Sie dies vor shutdownORB aus und ehe Sie die Applikation beenden.
shutdownORB
Fahren Sie das ORB herunter. Verwenden Sie dies vor shutdownOA und ehe Sie die Applikation beenden.
Verwenden Sie nacheinander die shutdownOA und shutdownORB Methoden, ehe Sie eine Applikation beenden. Dies gestattet es dem JBoss Transaction Service die notwendigen Bereinigungsvorgänge durchzuführen. Der shutdownOA Vorgang fährt entweder BOA oder POA herunter, je nach verwendetem ORB.

Beispiel 2.2. Herunterfahren des ORB

public static void main (String[] args)
{
    . . .
    ORBInterface.shutdownOA();
    ORBInterface.shutdownORB();
};
Copy to Clipboard Toggle word wrap
Verwenden Sie keine CORBA-Objekte mehr nachdem Sie shutdown aufgerufen haben. Sie müssen BOA/POA und ORB reinitialisieren, ehe Sie weitere CORBA-Objekte verwenden.

Anmerkung

Der Begriff Object Adapter wird im Rest dieses Handbuchs für sowohl BOA als auch POA verwendet. Wo möglich verwendet dieses Handbuch die ORB Portability Klassen, um die Unterschiede zwischen POA und BOA zu verdecken.

2.4. Festlegung des "Object Store"-Speicherorts

Der JBoss Transaction Service uses verwendet einen Object Store für die persistente Speicherung der Ergebnisse von Transaktionen für Failure Recovery. Sie können den Speicherort des Object Store mittels der objectStoreDir-Property festlegen.

Beispiel 2.3. Festlegung des Object Store bei Applikationsausführung

	java Dcom.arjuna.ats.arjuna.objectstore.objectStoreDir=/var/tmp/ObjectStore myprogram
Copy to Clipboard Toggle word wrap
Standardmäßig befindet sich der Object Store in einem Verzeichnis unter dem aktuellen Ausführungsverzeichnis. In der Standardkonfiguration sind alle Objektstati im defaultStore gespeichert. Dieses Unterverzeichnis kann jedoch durch Einstellung der com.arjuna.ats.arjuna.objectstore.localOSRoot-Property-Variable geändert werden.

2.5. Implizite Transaktionsfortpflanzung und Interposition

Sie können Transaktionen innerhalb einer Domain erstellen und sie innerhalb einer anderen verwenden. Informationen zu einer Transaktion mit Namen transaction context müssen daher zwischen diesen Domains fortgepfalnzt werden.

Fortpflanzung des Transaktionskontext

Explizite Fortpflanzung
Eine Applikation gibt Kontextobjekte als explizite Parameter weiter. Diese Objekte sind entweder Instanzen des Control-Interface oder der PropagationContext-Struktur und sind durch den Transaktionsdienst definiert. Es ist effizienter die PropagationContext-Struktur statt das Control-Interface zu verwenden.
Implizite Fortpflanzung
Anfragen an Objekten werden implizit mit der Transaktion des Clients assoziiert und teilen den Transaktionskontext des Clients. Der Kontext wird implizit an die Objekte übertragen, ohne direkte Intervention des Clients.
Bei den das Control interface unterstützenden OTS-Objekten handelt es sich um standardmäßige CORBA-Objekte. Wird das Interface als ein Parameter in einem Operationsaufruf an einen Remote-Server witergegeben, so wird nur eine Objektreferenz weitergegeben. Sämtliche Operationen, die das Remote-Objekt am Interface durchführt, werden am echten Objekt durchgeführt.
Dieses Verhalten kann zu maßgeblichen Sanktionen bei Applikationen führen, die diese Interfaces häufig verwenden, aufgrund von Overheads des Remote-Aufrufs. Um diesen Overhead zu vermeiden, unterstützt JBoss Transaction Service interposition. Bei Interposition erstellt der Server ein lokales Objekt, das als ein Proxy für die Remote Transaktion fungiert, der alle Anfragen auffängt, die normalerweise zurück zum Urheber. Dieses lokale Objekt registriert sich selbt beim Original Transaktionskoordinator, damit es ordnungsgemäß an der Beendigung der Transaktion teilhaben kann. Eingefügte Koordinatoren bilden eine Baumstruktur mit ihren übergeordneten Koordinatoren, wie in Abbildung 2.1, »Interposition« dargestellt.
Interposition

Abbildung 2.1. Interposition

Anmerkung

Implizite Transaktionsfortpflanzung bedeutet nicht, dass Interposition auch am Server verwendet wird. Stattdessen erfordert Interposition in der Regel implizite Fortpflanzung.
Falls Sie implizite Kontextfortpflanzung und Interposition benötigen, stellen Sie sicher dass der JBoss Transaction Service ordnungsgemäß initialisiert ist ehe Sie Objekte erstellen. Client und Server müssen übereinstimmen, ob implizite Fortpflanzung oder Interposition oder keines davon verwendet wird. Implizite Kontextfortpflanzung ist nur an denjenigen ORBs möglich, die Filter und Interzeptoren unterstützen oder die das CosTSPortability-Interface unterstützen. JacORB und das JDK miniORB liefern beide den erforderlichen Support.

Aktivierung der Fortpflanzung

Implizite Kontextfortpflanzung
Setzen Sie die com.arjuna.ats.jts.contextPropMode-Property-Variable auf CONTEXT.
Interposition
Setzen Sie die com.arjuna.ats.jts.contextPropMode-Property-Variable auf INTERPOSITION.

Anmerkung

Um das fortgeschrittene API des JBoss Transaction Service zu benutzen, müssen Sie Interposition verwenden.

2.6. Erhalt von Current

Sie erhalten das Current-Pseudo-Objekt von der com.arjuna.ats.jts.OTSManager-Klasse, indem Sie dessen get_current-Methode verwenden.

2.7. Beendigung der Transaktion

Wie lange ein Control Zugriff auf eine beendete Transaktion hat, ist implementierungsspezifisch. Beim JBoss Transaction Service werden alle Informationen zu einer Transaktion gelöscht wenn diese endet, wenn Sie das Current-Pseudo-Objekt verwenden.Aus diesem Grund sollten Sie keine Control-Referenzen zu der Transaktion verwenden, nachdem Sie den Festschreibungs- oder Zurücksetzungsvorgang ausgegeben haben.
Wenn Sie die Transaktion jedoch explizit mittels des Terminator-Interface beenden, so werden Informationen zu der Transaktion nur entfernt, wenn alle ausstehenden Referenzen zu ihr gelöscht wurden. Sie können signalisieren, dass die Transaktionsinformationen nicht mehr benötigt werden, indem Sie die destroyControl-Methode der OTS-Klasse benutzen, die Sie im com.arjuna.CosTransactions-Paket finden. Nachdem das Programm anzeigt, dass die Transaktionsinformationen nicht mehr benötigt werden, sollten Sie keine Control-Referenzen zur Transaktion mehr verwenden.

2.8. Transaction Factory

Standardmäßig verwendet der JBoss Transaction Service keinen separaten Transaktionsmanager beim Erstellen von Transaktionen durch das Current-Interface. Jeder transaktionale Client hat im Wesentlichen seinen eigenen Transaktionsmanager, die TransactionFactory, die sich am selben Ort damit befindet. Um dieses Verhalten zur Runtime außer Kraft zu setzen, setzen Sie die com.arjuna.ats.jts.transactionManager-Property-Variable auf YES. Um die Transaction Factory auszuführen, führen Sie das start-transaction-service-Skript aus, das sich im ATS_ROOT/bin-Verzeichnis befindet.
Current findet die Factory in der Regel mittels der CosServices.cfg-Datei im $JBOSS_HOME/etc-Verzeichnis. Diese Datei ähnelt der resolve_initial_references-Datei und wird automatisch erstellt oder aktualisiert, wenn die Transaction Factory an einer bestimmten Maschine gestartet wird. Diese Datei muss lokal an alle Maschinen kopiert werden, die sich dieselbe Transaction Factory teilen.

Anmerkung

Die Informationen über CosServices.cfg beziehen sich auf den Standardnamen und Speicherort der Konfigurationsdatei. Um den Namen der Datei zu ändern, verwenden Sie die com.arjuna.orbportability.initialReferencesFile-Variable. Um deren Speicherort zu ändern, stellen Sie die com.arjuna.orbportability.initialReferencesRoot-Variable ein.

Beispiel 2.4. Anpassung der "Initial References"-Datei

	java –Dcom.arjuna.orbportability.initialReferencesFile=ref –Dcom.arjuna.orbportability.initialReferencesRoot=c:\\temp prog
Copy to Clipboard Toggle word wrap
Sie können den standardmäßigen Speicherortmechanismus durch Einstellung der com.arjuna.orbportability.resolveService-Property-Variablen mit den in ResolveService-Parameter aufgeführten Parametern außer Kraft setzen.

ResolveService-Parameter

CONFIGURATION_FILE
Das System verwendet die CosServices.cfg-Datei. Dies ist das Standardverhalten.
NAME_SERVICE
Der JBoss Transaction Service versucht mit einem Nameservice die Transaction Factory zu finden. Wird dies nicht unterstützt, so wird eine Ausnahme gemeldet.
BIND_CONNECT
Der JBoss Transaction Service verwendet den ORB-spezifischen Bindemechanismus. Wird dies nicht unterstützt, so wird eine Ausnahme gemeldet.
Ist com.arjuna.orbportability.resolveService festgelegt wenn die Transaction Factory ausgeführt wird, registriert die Factory sich selbst mit dem festgelegten Resolutionsmechanismus.

2.9. Recovery Manager

Sie müssen das Recovery Manager Untersystem starten um sicherzustellen, dass Transaktionen im Falle eines Ausfalls wiederherstellbar sind. Um den Recovery Manager zu starten, führen Sie das start-recovery-manager-Skript in $ATS_ROOT/bin aus.

Kapitel 3. Erste Schritte mit Web Services Transactions und XTS

3.1. Konfiguration der Web Services Komponente

Ausführliche Informationen zu JBoss Transactions XTS finden Sie im XTS-Abschnitt des Transactions Development Guide, der Teil des Dokumentationssatzes für die Enterprise Application Platform.
Expand
Tabelle 3.1. Web Services Konfiguration
Property
Mögliche Werte
com.arjuna.orbportability.initialReferencesFile
CosServices.cfg
com.arjuna.orbportability.initialReferencesRoot
Das Verzeichnis, das die Datei arjuna.properties enthält.
ArjunaJTS_LicenceKey
Systemspezifische Lizenz.
com.arjuna.orbportability.resolveService
CONFIGURATION_FILE
NAME_SERVICE
BIND_CONNECT
com.arjuna.ats.arjuna.objectstore.objectStoreDir
Jeder Speicherort in den die Anwendung schreiben kann.
com.arjuna.ats.arjuna.objectstore.localOSRoot
defaultStore
PROPERTIES_FILE
arjuna.properties
com.arjuna.ats.arjuna.coordinator.asyncPrepare
YES/NO
com.arjuna.ats.arjuna.coordinator.asyncCommit
YES/NO
com.arjuna.ats.arjuna.coordinator.commitOnePhase
YES/NO
com.arjuna.ats.arjuna.coordinator.transactionSync
ON/OFF
com.arjuna.ats.arjuna.coordinator.enableStatistics
ON/OFF
com.arjuna.ats.jts.alwaysPropagateContext
YES/NO
com.arjuna.ats.jts.defaultTimeout
No timeout
com.arjuna.ats.jts.supportRollbackSync
YES/NO
com.arjuna.ats.jts.supportInterposedSynchronization
YES/NO
com.arjuna.ats.jts.supportSubtransactions
YES/NO
com.arjuna.ats.jts.checkedTransactions
YES/NO
com.arjuna.ats.jts.transactionManager
YES/NO
com.arjuna.ats.jts.needTranContext
YES/NO
com.arjuna.ats.arjuna.coordinator.txReaperTimeout
120000000 Mikrosekunden
com.arjuna.ats.arjuna.coordinator.txReaperMode
NORMAL
DYNAMIC
com.arjuna.ats.jts.contextPropMode
NONE
CONTEXT
INTERPOSITION

Anhang A. Änderungsverzeichnis

Versionsgeschichte
Version 5.1.0-2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 5.1.0-22012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 5.1.0-100Mon Jul 18 2011Mie Yamamoto
Übersetzung ins Japanische

Rechtlicher Hinweis

Copyright © 2010 Red Hat.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red Hat
Nach oben