Transactions 管理者ガイド

JBoss Enterprise Application Platform 5

JBoss Enterprise Application Platform 5 向け

エディッション 5.1.2

概要

本書は、JBoss Enterprise Application Platform 5およびその修正リリースのJBoss Transactions 管理者ガイドとなっています。

第1章 はじめに

JBoss Transaction Serviceではほとんど管理タスクが生成されません。JBoss Transaction Service は基盤のオペレーティングシステムやインフラストラクチャが正しく機能しているかにより影響を受けます。管理者として、以下に留意してください。
  1. JBoss Transaction Serviceは、セキュリティ層を提供せず、JBoss Transactions Object Store に格納されるオブジェクトは通常、そのオブジェクトを作成したアプリケーションを実行しているユーザが所有することになります。 Object Store および Object Manager の機能はオブジェクトの所有を強化するものではなく、Transaction Manager は、オブジェクトの所有について確認や強化は行いません。
  2. Object Store で作成された永続オブジェクトは、StateManager.destroy メソッドが オブジェクト上で呼び出されない限り、あるいは、あるアプリケーションプログラムが明示的にオブジェクトを削除しない限りは、決して消失することはありません。つまり、特にアプリケーション開発やテストフェーズにObject Store が徐々にガーベッジを集積していることを意味します。 JBoss Transaction Serviceでは、自動のガーベッジコレクション機能は存在しません。このようにガーベッジコレクションがないため、懸垂参照が作られてしまう可能性があります。懸垂参照の例を以下に示します。ObjectA と呼ばれる永続オブジェクトが永続オブジェクトであるObjectB の Uid をディスクにパッシブ表現で格納しているとします。アプリケーションは、ObjectA 内に ObjectB への参照を含んでいるにも拘らず、ObjectBを削除可能です。ObjectA が次回に有効化されObjectB にアクセスしようとすると、ランタイムエラーが発生します。
  3. JBoss Transaction Serviceには、クラス構成が変更になった場合、 データベースの再構成やオブジェクトのバージョン管理に関する機能はありません。 永続オブジェクトクラスの定義を変更する場合、Object Store にあるオブジェクトの既存インスタンスが新しい表現に変換されるようにしてください。JBoss Transactions Service ソフトウェアは新しいオペレーションバージョンで旧オブジェクトの状態への参照を検出あるいは修正することができません、 またこの逆もできません。
  4. オブジェクトストア管理はトランザクションサービスにとって非常に重要となります。

第2章 ObjectStore 管理

Transaction Serviceの設定では、Object Store はトランザクションが作成されるたび、あるいは Java 用のTransaction Object が使用される場合、定期的に更新されます。障害のない環境では、オブジェクトストア内のオブジェクトステートのみがJava API 向けのTransactional Object で作成されるオブジェクトを表現するものとなります。
ただし、障害が発生すると、クラッシュリカバリ機能がトランザクションを解決するまでトランザクションログはオブジェクトストア内に残る可能性があります。そのため、疑わしいトランザクションの解決が不可能になってしまうため、オブジェクトストアの内容を誤って削除してしまわないようにすることが非常に重要です。また、 複数のユーザーが同じオブジェクトストアを共有する場合、専有のリソースではなく、十分な配慮なしにトランザクションログを削除しないよう理解することが必要です。

第3章 OTS および J2EE Transaction Service 管理

3.1. Run-time Systemの開始

JBoss Transaction Service のRun-timeサポートには、Run-time パッケージとOTS Transaction Manager サーバーが含まれています。デフォルトでは、JBoss Transaction Service は別途Transaction Manager サーバーを利用しません。その代わり、トランザクションマネージャは各アプリケーションプロセスと同一場所に配置されています。これは、アプリケーションが正しく機能するように他のサービスへ外的依存していたものを取り除くことで、パフォーマンスやアプリケーションの耐障害性を高めています。
ご利用中のアプリケーションが別のトランザクションマネージャを必要とする場合、com.arjuna.ats.jts.transactionManager の環境変数をyesに設定します。このシステムは、ORB固有のメカニズムを使いトランザクションマネージャを検索します。このトランザクションマネージャは、ネームサーバーに登録、ORBの初期参照に追加、JBoss Transaction Service 固有の参照ファイルに追加、あるいはORB固有のロケーションメカニズムにより検索されるでしょう。
com.arjuna.orbportability.resolveService の環境変数を以下の値の１つに設定することで、デフォルトの登録メカニズムをオーバーライドすることができます。
デフォルト値のCONFIGURATION_FILE
システムがCosServices.cfg ファイルを使用するようにさせます。
NAME_SERVICE
JBoss Transaction Service は、ネームサービスを使いトランザクションファクトリを登録しようとします。ORBがこのような動作に対応していない場合は、例外がスローされます。
BIND_CONNECT
JBoss Transaction Service はORB固有のバインドメカニズムを使用します。ORBがこれに対応していない場合は、例外がスローされます。
RESOLVE_INITIAL_REFERENCES
JBoss Transaction Service は、トランザクションサービスをORBの初期サービス参照に登録しようとします。

3.2. OTS設定ファイル

RESOLVE_INITIAL_REFERENCES オプションのように、JBoss Transaction Serviceは、特定のサービスへの参照を格納しランタイム時に使用可能にする初期参照ファイルに対応しています。CosServices.cfgのファイルにはservice name (OTSサーバーを利用の場合は常にTransactionService) とIORのカラム２つで構成されており、それぞれスペース１つで区切られています。CosServices.cfgは通常、JBoss Transaction Service 設定のetcディレクトリに置かれています。ただし、実際の場所はランタイム時にCLASSPATHを検索しTransactionService properties file ディレクトリの場所あるいはetc ディレクトリにあるこのファイルの複製を検索しすることで決定されます。
OTSサーバーはこのファイルが見つからない場合、ファイルを作成しそのファイル内に登録します。古くなった情報は自動的に削除されます。同じトランザクションサーバーを共有するマシンは、このファイル自体あるいは複製へアクセスできるようになっていなければなりません。
ファイル名にはcom.arjuna.orbportability.initialReferencesFile と 場所にはcom.arjuna.orbportability.initialReferencesRoot を使うことで、それぞれオーバーライドすることができます。 
com.arjuna.orbportability.initialReferencesFile=myFile
com.arjuna.orbportability.initialReferencesRoot=c:\\temp

3.3. ネームサービス

ご利用中のORBがネームサービスに対応しており、JBoss Transaction Service がそのサービスを使うように設定されている場合、トランザクションマネージャは自動的にそのサービスに登録されます。

注記

JacORBには、このオプションは使いません。

3.4. RESOLVE_INITIAL_REFERENCES

このオプションは現在、JacORBへの対応はしていません。

3.5. 解決サービスの表

以下の表にて、特定のORBでOTSトランザクションマネージャを検索する様々な方法をまとめています。

表3.1 OTSトランザクションマネージャサーバーの検索

解決メカニズム ORB
OTS設定ファイル 利用可能なORBすべて
ネームサービス JacORB
resolve_initial_references JacORB

第4章 XA 固有の管理

JBoss Transaction Service が作成するXA Xid は、それぞれに対して固有のノード識別子が埋め込まれているようにしなければなりません。JBoss Transaction Service は、指定のノード識別子と一致しているトランザクションや状況のみ回復することができます。このノード識別子はcom.arjuna.ats.arjuna.xa.nodeIdentifier プロパティ経由でJBoss Transaction Service へ渡されます。この値は、JBoss Transaction Service インスタンスの中で固有でなければなりません。何も値が渡されない場合、JBoss Transaction Service は、値を生成しロギングインフラストラクチャ経由でその値を報告します。

4.1. XA リカバリ

XA リカバリを実行時、JBoss Transaction Service にどの型のXid を回復しているのか伝える必要があります。使用するノード識別子をcom.arjuna.ats.jta.xaRecoveryNode名から始まるプロパティにて、JBoss Transaction Service に提供する必要があります。ノード識別子に拘らず、* の値があると、JBoss Transaction Service が強制的に全トランザクションを回復 (場合によってはロールバック) するようにします。このオプションを使用する場合は極めて慎重に行ってください。
リカバリに関する詳細情報は、障害および回復の項にて提供しています。

第5章 Web Service Transaction のサービス管理

トランザクショナルなWeb Services アプリケーションに関する基本的なビルディングブロックは以下の通りです。
  • アプリケーション自体
  • アプリケーションが消費する Web services
  • Transaction Manager
  • これらの Web services をサポートするトランザクションのパーティシパント
通常のデプロイメントでは、開発者一人でこれらの役割をすべて対応する可能性は低くなっています。開発者は通常サービスやサービスを消費するアプリケーションを作りだし、システム管理者はトランザクション管理のインフラストラクチャを動かすため、概要を提示しています。

5.1. Transaction Manager

トランザクションマネージャは、JBoss Transaction Serviceのトランザクションを手配するWeb サービスで、エンドユーザコードに対応するのではなくネットワークサービスとして直接実行されるJBoss Transaction Serviceの中で唯一のソフトウェアコンポーネントとなっています。また、トランザクションマネージャは、JAXM リクエスト/レスポンスの Web サービスとして実行されます。

重要

JBoss Transaction Service をデプロイしているアプリケーションサーバーインスタンスを開始すると、端末あるいはログにて様々なエラーメッセージが表示されるでしょう。以下にメッセージの一例を示しています。 
16:53:38,850 ERROR [STDERR] Message Listener Service: started, message listener jndi name activationcoordinator
このようなメッセージは情報提供を目的としており実際のエラーではありません。

5.1.1. Transaction Manager の設定

Transaction Managerと関連のインフラストラクチャはプロパティファイルを使って設定されます。
  • wscf.xml
  • wst.xml
  • wstx.xml
これらのファイルはconf にあり、デモアプリケーションやスタンドアローンモジュールを設定する際に使用します。
多くの場合、これらのファイルにあるデフォルト値を変更する必要はありません。ただし、com.arjuna.ats.arjuna.objectstore.objectStoreDirプロパティは、トランザクションの状態を記録するのに使用する永続ストアの場所を決定します。C:/temp/ObjectStoreのデフォルト値は、ご利用中のシステムに合わせて値を変更してください。本番環境では、このディレクトリはRAIDアレーなど、耐障害メディアに設置するようにしてください。
アプリケーションがスタンドアローンのコーディネータを使用する場合、wstx.xmlファイルのプロパティを２つ追加で有効化、修正する必要があります。
  • com.arjuna.mw.wst.coordinatorURL
  • com.arjuna.mw.wst.terminatorURL
これらのプロパティは、スタンドアローンのコーディネータと接触する際にクライアントアプリケーションが利用するURLを表示します。スタンドアローンコーディネータのホスト名とポートを正しく設定する必要があります。

注記

JBoss Transactin Service は極めてモジュラー型となっており、個別コンポーネントを柔軟にデプロイ可能にするには、複数の設定ファイルにて同じプロパティ値が必要となってくる場合もあります。設定の大半においては、複数のファイルにて定義されたプロパティに対して、一貫した値を保つ必要があります。

5.1.2. Transaction Manager のデプロイ

Transaction ServiceのWeb Service Transaction Manager コンポーネントには、アプリケーションのクラスファイルを含む多数のJARファイル、そして必要なサービスを公開するWeb サービス (WAR) ファイルから構成されています。アプリケーション開発時、プログラマはアプリケーションのEARファイルにあるこれらのコンポーネントを全てふくめ、トランザクションインフラストラクチャのデプロイメントを簡素化します。本番では、Transaction Manager をスタンドアローンのアプリケーションとしてインストールし、サーバーレベルで設定と管理を集約することができます。JBoss Transaction Serverに同梱されているデモのアプリケーションには、アプリケーションにTransaction Manager コンポーネントを含むサンプルの配備記述子が含まれています。
JBoss Transaction Service は、基盤となるプロトコル通信に固定のエンドポイントを使います。そのため、Transaction Serviceを利用する複数のアプリケーションが同じサーバーに同時にデプロイされると問題が発生する可能性があります。同じサーバーにトランザクショナルなアプリケーションを複数デプロイするには、個別アプリケーションのデプロイメント内に埋め込むのではなく、Transaction Manager を別のアプリケーションとしてデプロイします。
JBoss Transaction Service設定のcoordinator ディレクトリにより、スタントアローンのトランザクションマネージャを設定、デプロイメントしやすくなります。これを利用するには、以下が必須となります。
  • JBoss Enterprise Application Platform 5をインストールすること
  • ant 1.4 以降をインストールすること

重要

アプリケーションサーバーの設定はクライアントとサービスのデプロイ先とは違うものでなければなりません。そうでなければ、様々なJBoss Transaction Service コンポーネント間で矛盾が発生する可能性があります。
コーディネータに含まれているbuild.xmlを編集し、トランザクションコーディネータがデプロイされているアプリケーションサーバー設定と、JBoss Transaction Service 設定の場所を指定するようにします。コーディネータのdd/ ディレクトリにあるws-c_jaxm_web-app.xml と ws-t_jaxm_web-app.xmlファイルは、WS-CおよびWS-T WARファイルの配備記述子となっています。これらのファイルにはテンプレート化されたURLが含まれています。構築フェーズで、ant は、build.xmlからのhostname と port値をこれらのファイルに代入します。
target deploy-weblogic、deploy-jboss あるいは deploy-webmethodsを使いantを実行し、正しいアプリケーションサーバー設定に新しいコーディネータを作成、デプロイします。
次に、デモアプリケーションを生成し、コーディネータのポートとホスト名を指定することで、必要とされるコーディネータにご利用中のクライアントを指定します。

5.1.3. 配備記述子

通常、JBoss Transaction Service で利用される様々な配備記述子のコンテンツを変更する必要はありません。しかし、変更の必要がある場合は、コーディネータモジュールにすべて含まれます。
JBoss Transaction Service コンポーネントのすべてが、配備記述子にある情報へアクセスする準備ができているわけではありません。そのため、WS-C あるいは WS-T 配備記述子が利用するJNDI名を変更すると、wstx.xml設定ファイルに適切なプロパティを設定することで、ランタイム時に他のJBoss Transaction Service コンポーネントに通知する必要がある場合もあります。
表5.1「配備記述子の値とプロパティ」の表にて、配備記述子が使うデフォルトのJNDI名とデフォルト値を変更する場合に設定する該当のプロパティが表示されています。

表5.1 配備記述子の値とプロパティ

JNDI 名 プロパティ
Activationrequester com.arjuna.mw.wst.at.activationrequester
Activationcoordinator com.arjuna.mw.wst.at.activationcoordinator
Completionparticipant com.arjuna.mw.wst.at.completionparticipant
Registrationrequester com.arjuna.mw.wst.at.registrationrequester
durable2pcdispatcher com.arjuna.mw.wst.at.durable2pcdispatcher
durable2pcparticipant com.arjuna.mw.wst.at.durable2pcparticipant
volatile2pcdispatcher com.arjuna.mw.wst.at.volatile2pcdispatcher
volatile2pcparticipant com.arjuna.mw.wst.at.volatile2pcparticipant
businessagreementwithparticipantcompletiondispatcher com.arjuna.mw.wst.ba.businessagreementwpcdispatcher
businessagreementwithparticipantcompletionparticipant com.arjuna.mw.wst.ba.businessagreementwpcparticipant
businessagreementwithcoordinatorcompletiondispatcher com.arjuna.mw.wst.ba.businessagreementwccdispatcher
businessagreementwithcoordinatorcompletionparticipant com.arjuna.mw.wst.ba.businessagreementwccparticipant

第6章 JBoss Transaction Server ランタイム情報

JBoss Transaction Serverの各モジュールには、Infoクラスが含まれます。このクラスはtoString メソッドを提供しており、該当のモジュールに対する設定情報のXMLダンプを返します。出力例については例6.1「toStringメソッドの使用」 を参照してください。

例6.1 toStringメソッドの使用

<module-info>
  <source-identifier>unknown</source-identifier>
  <build-information>
    Arjuna Technologies [mlittle] (Windows 2000 5.0)
  </build-information>
  <version>unknown</version>
  <date>2002/06/15 04:06 PM</date>
  <notes></notes>
  <configuration>
    <properties-file dir="null">arjuna.properties</properties-file>
    <object-store-root>null</object-store-root>
  </configuration>
</module-info>

第7章 JBoss Transaction Service のリソースリカバリ

7.1. はじめに

JBoss Transaction Serviceは、クラッシュに耐えるトランザクションマネージャです。<xa-datasource>で定義されているJDBC接続や２フェーズトランザクションにてJBoss Messagingを使用するJMS接続などのXAResources を登録時、JBoss Transaction Service はアプリケーションサーバーがトランザクション中にクラッシュした場合にリカバリができるようトランザクションログを取ります。適切なリカバリモジュールを設定している場合は、全リソースが再度利用可能になった時点で、失敗したトランザクションの大半が自動回復されます。

7.2. 前提条件

ここで記載した設定オプションは、サーバー設定の conf ディレクトリにある jbossts-properties.xml ファイルにデフォルトで含まれています。default 設定を使いJBOSS_HOME にインストールされているサーバーの場合、正しいファイルパスは、 JBOSS_HOME/server/default/conf/jbossts-properties.xml です。

7.3. クラスターに関する注記

各アプリケーションサーバーのインスタンスは、コーディネートしたトランザクションのリカバリを担当します。通常、データベース１つで複数のアプリケーションサーバーに対応するため、複数のコーディネータからのトランザクションに参加します。リカバリ時は、JBoss Transaction Service は、疑いのあるトランザクションでリカバリできる可能性のあるものの一覧を各アプリケーションサーバーからリクエストします。データベースは、指定のインスタンスによりコーディネートされていないものも含め、疑いのあるトランザクションをすべて返します。各ノードのトランザクションを効果的に区別するには、共通のデータベースを共有するアプリケーションサーバーのインスタンスごとに固有のノードid を設定しなければなりません。これは以下のプロパティに対して固有の値を設定することで行います。 
<property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="1"/>
また、リカバリが必要なノードを指定する要素も必要です。これは上で設定した nodeIdentifier に一致する必要があります。 
<property name="com.arjuna.ats.jta.xaRecoveryNode" value="1"/>

7.4. リカバリモジュール

リカバリをしたい各XA リソースには、jbossjta-properties.xmlの"jta" セクションに設定されている該当のリカバリモジュールが必要となります。各リカバリモジュールは、com.arjuna.ats.jta.recovery.XAResourceRecoveryを継承する必要があり、Red Hat は JDBC およびJMS XA リソースに対する実装を提供しています。

7.4.1. JDBC リカバリ

JBoss Enterprise Application Platform にはJCAのリカバリ自動登録を含むようになりました。そのため、以前のリリースで使われていたAppServerJDBCXARecovery はデフォルトで無効になっており、当プラットフォームの今後のリリースでは本プロパティは完全に削除される予定です。

7.4.1.1. ベンダー固有のデータベース情報

Oracle
Oracle が正しく設定されていない場合、ログファイルに以下のフォローが示されるでしょう。 
WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
このエラーを解決するには、Oracle ユーザが適切なテーブルへアクセスしリカバリを完了できるようにします。 
GRANT SELECT ON sys.dba_pending_transactions TO user;
GRANT SELECT ON sys.pending_trans$ TO user;
GRANT SELECT ON sys.dba_2pc_pending TO user;
GRANT EXECUTE ON sys.dbms_xa TO user;
上記では、user はJBoss からOracle に接続するために定義されたユーザという前提です。また、Oracle 10g R2 (bug 5945463修正済み) あるいは 11gの使用を前提としており、11g 以前のパッチが当てられていないバージョンを使っている場合は、最後のGRANT EXECUTEを以下に変更してください。 
GRANT EXECUTE ON sys.dbms_system TO user;
PostgreSQL
用意した (XA など) トランザクションを有効化する方法については、PostgreSQL 文書を参照してください。PostgreSQLのJDBCドライバがバージョン8.4-701 は、org.postgresql.xa.PGXAConnection に問題があり、特定の状況でリカバリーを中断してしまいます。新しいバージョンでこれは修正されています。
MySQL
http://bugs.mysql.com/bug.php?id=12161によると、XA トランザクションリカバリは MySQL を使用するとできないようです。MySQL 6.1 で対応される予定です。JBoss Enterprise Application Platform 5 リリースノートの JBPAPP-2576 も参照してください。
DB2
DB2 は、クラッシュ／障害が起こった後にアプリケーションサーバーが再起動されると指定の再同期ステージになりますが、その再同期中にのみXAResource.recover の呼出しを期待します。これは、DB2 の設計における問題で、本書では対象外となっています。

7.4.2. JMS リカバリ

Messaging に関連するため、リカバリに関してはJBoss Messaging ガイドを参照してください。これらのガイドはhttp://docs.redhat.comのEnterprise Application Platform の文書スイートにて提供されています。

7.5. JMS クラスタリングに関する注記

JBoss Messaging クラスタのノード１つが停止した場合、クラスタ内のバディが停止したサーバーのメッセージをデータベースから全てロードします。
停止したノードが停止時にXAトランザクションを実行している場合、トランザクションログが記述される場合もありますが、関連メッセージはクラスタの別のサーバーに移動されます。
停止したサーバーが起動すると、リカバリマネージャはトランザクションログに格納されたトランザクションのリカバリを試行します。このメッセージが別のサーバーに移動されている場合、関連メッセージがそのサーバーにないため、ローカルのJMSプロバイダーから適切なXAREsource を取得することができません。その結果、JBoss Transaction Serviceは以下を返します。 
Could not find new XAResource to use for recovering non-serializable XAResource
これを解決するには、クラスタにある各ノードのJMS プロバイダやRecovery Manager を追加してください。例えば、クラスタにノードが３つあったとすると、以下をjbossts-properties.xmlに追加します。 
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGREMOTE1"
          value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/RemoteJMSProvider1"/>
   
      <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGREMOTE2"
          value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/RemoteJMSProvider2"/>
リモートのプロバイダは、JBOSS_HOME/server/default/deploy/jms-ds.xml で設定されます。 
<mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.jms:service=JMSProviderLoader,name=RemoteJMSProvider">
   <attribute name="ProviderName">MyRemoteJMSProvider</attribute>
   <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
   <attribute name="FactoryRef">XAConnectionFactory</attribute>
   <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
   <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
   <attribute name="Properties">
      java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
      java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
      java.naming.provider.url=192.168.1.172:1099
   </attribute>
</mbean>

注記

java.naming.provider.url はリモート JMS インスタンスの IP アドレスとポートに解決する必要があります。
JNDI プロパティを設定し、クラスタにあるリモートノードに接続します。正しくリカバリを行うには、クラスタにある他の全ノードにそれぞれプロバイダとリカバリマネージャを追加します。

第8章 JTA 実装の選択

JTA 実装には２つの種類が提供されており、同じインターフェースを使いアクセスできます。種類は以下の通りです。
  1. ローカルの JTA。これは非分散 JTA トランザクションのみを実行できるようにします。これは JBoss Transactions Serviceで提供されている唯一の バージョンです。
  2. リモートのCORBA ベース JTA。これは分散 JTA トランザクションを実行できるようにします。このバージョンは ArjunaJTS 製品と合わせてでなければ取得できず、対応のCORBA ORB を必要とします。
これらの実装は両方、JBoss Transaction Serviceで提供されているトランザクショナル JDBC ドライバと完全互換しています。
ローカル JTA 実装を選択するためには、以下の手順を実行する必要が あります:
  1. com.arjuna.ats.jta.jtaTMImplementationプロパティを com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple に設定します。
  2. com.arjuna.ats.jta.jtaUTImplementation をcom.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImpleに設定します。
これらの設定はデフォルト値で、ローカル実装を使用する際には設定する必要がありません。

第9章 ORB 固有の設定

JacORB

JacORB が正しく機能するには、以下の場所のいずれかに有効なjacorb.properties ファイル、あるいは .jacorb_properties ファイルが存在するようにします。

  • CLASSPATH.
  • ユーザがJBoss Transaction Service を実行するホームディレクトリ。ホームディレクトリは、System.getProperty( “user.home” );を使ってリトリーブします。
  • 現在のディレクトリ
  • アプリケーションを実行するのに利用するJDKのlib ディレクトリ。これは、System.getProperty( “java.home” );を使ってリトリーブします。
上記の場所を指定の順番で検索します。テンプレートのjacorb.properties ファイルは、JacORB installation ディレクトリにあります。
JacORB プロパティファイルには、重要なプロパティが２つ含まれており、ご利用中のアプリケーションに合わせて設定する必要があります。この重要なプロパティは以下の通りです。
  • jacorb.poa.thread_pool_max
  • jacorb.poa.thread_pool_min
これらのプロパティは、JacORB がスレッドプールで使用するリクエスト処理スレッドの最大数、最小数を指定します。利用可能なスレッドが少なすぎる場合は、アプリケーションはデッドロックになります。JacORB 設定の詳細情報については、JacORB の文書を参照してください。

注記

JacORB にはCosTransactions.idl ファイルにて定義されているクラスの独自実装が含まれています。残念ながら、JBoss Transaction Service に同梱されているバージョンとの互換性はありません。そのため、JBoss Transaction Service JAR ファイルは、いかなる JacORB JARより前にCLASSPATH に表示される必要があります。
リカバリマネージャは、常にリカバリマネージャが実行されているマシンに対し、それぞれ同じ既知ポートを使う必要があります。リカバリマネージャが独自のjacorb.properties ファイルを所有するか、リカバリマネージャ起動時にコマンドライン上でそのポートが提供されない限り、JacORBが提供するOAPort プロパティを使うべきではありません。リカバリマネージャやその他のJBoss Transaction Service のコンポーネントは、同じjacorb.properties ファイルを共有している場合、com.arjuna.ats.jts.recoveryManagerPort および com.arjuna.ats.jts.recoveryManagerAddressプロパティを利用する必要があります。

第10章 JBoss Transactions Serviceのアプリケーションの初期化

アプリケーションオブジェクトを作成する前に、JBoss Transaction Serviceを正しく初期化する必要があります。これを確認するには、ORB_init とcreate_POA メソッドを利用します。

第11章 エラーと例外

トランザクション適用時のエラーと例外

NO_MEMORY
アプリケーションはメモリの空きがなくなり、OutOfMemoryErrorの例外をスローしました。 JBoss Transactions は例外が再度出される前に、ガーベッジコレクションを何度か試行しました。これは、一時的な問題の場合があり、呼出しを再試行すると成功する場合もあります。
com.arjuna.ats.arjuna.exceptions.FatalError
トランザクションシステムで致命的なエラーが発生し、シャットダウンする必要があります。このエラーの前に、トランザクションサービスは、実行中のトランザクションがすべてロールバックされていることを確認します。何か問題があれば、アプリケーションは整理を行い、終了されるはずです。さらなる作業を試行する場合、アプリケーションの整合性が無視される可能性があります。
com.arjuna.ats.arjuna.exceptions.LicenceError
現在のライセンスと矛盾した形でトランザクションサービスを利用しようとしました。トランザクションサービスは、これ以上既存のトランザクションあるいは新規トランザクションを進めることができないようにします。
com.arjuna.ats.arjuna.exceptions.ObjectStoreError
トランザクションサービスが Object Store の使用を試みた時にエラーが発生しました。これ以上進めることはできません。
Object store warnings about access problems on states
同じトランザクションで複数のリカバリを同時試行すると、通常のクラッシュリカバリ実行時にこのエラーが発生することがあります。これは無視しても問題ありません。

付録A 改訂履歴

改訂履歴
改訂 5.1.2-2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
改訂 5.1.2-22012-07-18Anthony Towns
Rebuild for Publican 3.0
改訂 5.1.2-100Thu 8 December 2011Russell Dickenson
JBoss Enterprise Application Platform 5.1.2 GA の変更が含まれます。このガイドの内容の変更については、『『リリースノート 5.1.2 (Release Notes 5.1.2)』』を参照してください。