Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング

11gリリース1 (10.3.6)

B61631-05(原本部品番号:E13731-06)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- このリリースでの新機能と変更点

2 トランザクションについて

- WebLogic Serverアプリケーションのトランザクションの概要

- トランザクションのACIDプロパティ

- サポートされているプログラミング・モデル

- サポートされているAPIモデル

- 分散トランザクションと2フェーズ・コミット・プロトコル

- ビジネス・トランザクションのサポート

- どのような状況で使用するのか

- トランザクションの仕組み

- WebLogic Server EJBアプリケーションのトランザクション

- コンテナ管理のトランザクション

- Bean管理のトランザクション

- WebLogic Server RMIアプリケーションのトランザクション

- トランザクションのサンプル・コード

- トランザクションのサンプルEJBコード

- パッケージをインポートする

- JNDIを使用してオブジェクト参照を返す

- トランザクションを開始する

- トランザクションを完了する

- トランザクションのサンプルRMIコード

- パッケージをインポートする

- JNDIを使用してUserTransactionオブジェクトへのオブジェクト参照を返す

- トランザクションを開始する

- トランザクションを完了する

3 トランザクションの構成

- トランザクション構成の概要

- JTAの構成

- リソース登録解除の猶予期間

- トランザクションを管理するための追加属性

- ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

- トランザクション通信の要件

- ドメイン間トランザクションに対する通信の構成

- ドメイン内トランザクションに対するドメインの構成

- クロス・ドメイン・セキュリティの構成

- クロス・ドメイン・セキュリティは推移的ではない

- トランザクションへの参加に基づいて除外リストにドメインを追加する

- クロス・ドメイン・セキュリティを構成する際の重要な考慮事項

- セキュリティの相互運用モードの構成

- ドメイン信頼を確立する

- セキュリティの相互運用モードの構成

- 管理ユーザーを必要とするJNDIルックアップ用にドメインを構成する

- トランザクション・ログ・ファイル

- デフォルト永続ストアの使い方

- デフォルト永続ストアへのパスの設定

- デフォルト永続ストアの同期書込みポリシーの設定

- JDBC JTOGストアの使い方

- 読取り専用1フェーズ・コミットの最適化

- 読取り専用1フェーズ・コミットの最適化と2フェーズ・コミット無効化の設定

- 読取り専用1フェーズ・トランザクション統計の監視

4 トランザクションの管理

- トランザクションのモニタリング

- ヒューリスティックな終了の処理

- サーバーの移動

- トランザクションの破棄

- トランザクション処理のチューニング

- 現在(処理中)のトランザクションの手動での解決

- 手動でのコミットとロールバックのオプション

- サーバーに障害が発生した後のトランザクションのリカバリ

- クラッシュ後のトランザクション・リカバリ・サービスのアクション

- WebLogicプロキシ・プラグインを備えたApacheを使用する際のクラスタリング・フェイルオーバー

- クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ

- クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ

- サーバーの移行

- トランザクション・リカバリ・サービスの手動移行

- トランザクション・リカバリ・サービスの自動移行

- 管理対象サーバーの独立性

- トランザクション・リカバリ・サービスの移行に対する制限

- トランザクション・リカバリ・サービスの移行準備

- トランザクション・リカバリ・サービスの移行先になるサーバーの制限

- トランザクション・リカバリ・サービスの現在のオーナーの表示

- トランザクション・リカバリ・サービスの元のサーバーへの手動による移行

- トランザクション・レコードの削除方法

- LLRデータベースでのTLOGの削除方法

- デフォルト・ストアからのTLOGファイルの削除方法

- JDBC TLOGストアからのTLOGの削除方法

5 トランザクション・サービス

- トランザクション・サービスについて

- 機能と制限

- 軽量クライアントと委託コミット

- クライアントが開始するトランザクション

- トランザクションの整合性

- トランザクションの終了

- フラット・トランザクション

- トランザクション・サービスのトランザクション処理との関係

- マルチスレッド・トランザクション・クライアントのサポート

- トランザクションID

- トランザクションの名前とプロパティ

- トランザクション・ステータス

- トランザクションの統計

- 一般的な制約

- トランザクションのスコープ

- EJBアプリケーションでのトランザクション・サービス

- RMIアプリケーションでのトランザクション・サービス

- OTSとの相互運用をサポートするトランザクション・サービス

- サーバー間の2PC

- クライアントによって境界設定されたトランザクション

6 Java Transaction APIとOracle WebLogicの拡張機能

- JTA APIの概要

- JTAに対するOracle WebLogicの拡張機能

7 ロギング・ラスト・リソース・トランザクションの最適化

- LLR最適化トランザクションの最適化について

- ロギング・ラスト・リソース処理の詳細

- LLRデータベース表の詳細

- LLR表のトランザクション・ログ・レコード

- LLRの障害とリカバリ処理

- サーバー・クラッシュの調整

- JDBC接続障害

- サーバー起動時のLLRトランザクション・リカバリ

- LLRのフェイルオーバーに関する考慮事項

- LLRでのパフォーマンス最適化

- トランザクション・コーディネータの場所の最適化

- LLRデータ・ソースを使用した読取り専用操作のパフォーマンスの変動

- データ・ソース別のLLR表の指定

- 制限事項

8 EJBアプリケーションのトランザクション

- 始める前に

- ガイドライン

- トランザクション属性

- EJBのトランザクション属性について

- コンテナ管理のトランザクションのトランザクション属性

- Bean管理のトランザクションのトランザクション属性

- トランザクションへの参加

- トランザクション・セマンティクス

- コンテナ管理のトランザクションのトランザクション・セマンティクス

- ステートフル・セッションBeanのトランザクション・セマンティクス

- ステートレス・セッションBeanのトランザクション・セマンティクス

- エンティティBeanのトランザクション・セマンティクス

- Bean管理のトランザクションのトランザクション・セマンティクス

- ステートフル・セッションBeanのトランザクション・セマンティクス

- ステートレス・セッションBeanのトランザクション・セマンティクス

- セッションの同期

- トランザクション時の同期

- トランザクション・タイムアウトの設定

- EJBトランザクションでの例外処理

9 RMIアプリケーションのトランザクション

- 始める前に

- ガイドライン

10 WebLogic ServerでのJDBC XAドライバの使い方

- XAドライバの概要

- XAドライバの表

- Oracle Thin/XA Driverの使い方

- Oracle Thin/XA Driverのソフトウェア要件

- Oracle Thin/XA Driverの環境の設定

- WebLogic Serverの構成

- XAのデータベース・サーバーでの有効化

- Oracle Thin/XA Driverの構成プロパティ

- Sybase jConnect 5.5および6.0/XA Driverの使い方

- XAをサポートするためのSybaseサーバーの構成

- XAとSybase Adaptive Server

- Sybase Adaptive Serverにおける実行スレッドとトランザクション

- デタッチされたトランザクションに対するタイムアウトの設定

- Sybase Adaptive Serverでのトランザクションの動作

- Javaクライアントの構成プロパティ

- Sybase jConnect 5.5および6.0/XAの確認済みの問題

- その他のXAドライバの使い方

11 WebLogic Serverトランザクション・マネージャでのXAResourceの調整

- 外部XAResourceと分散トランザクションの調整の概要

- XAResourceのトランザクションへの参加の登録

- トランザクションにおけるXAResourceの登録と登録解除

- 標準的な登録

- 動的な登録

- 静的な登録

- コミット処理

- リカバリ

- リソース・ヘルス監視

- Java EEコネクタ・アーキテクチャのリソース・アダプタ

- 実装のヒント

- WebLogic Serverトランザクション・ログの共有

- トランザクションのグローバル・プロパティ

- TxHelper.createXid

- リソース登録名の変更点

- FAQ

- JTAに関するその他のドキュメント

12 サード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加

- 外部管理トランザクションへの参加の概要

- クライアント介在トランザクション・マネージャでのトランザクションのインポート

- クライアント介在トランザクション・マネージャの取得

- 介在トランザクション・マネージャからのXAResourceの取得

- クライアント介在トランザクション・マネージャの制限

- サーバー介在トランザクション・マネージャでのトランザクションのインポート

- サーバー介在トランザクション・マネージャの取得

- サーバー介在トランザクション・マネージャの制限

- インポート済みトランザクションのトランザクション処理

- インポート済みトランザクションのトランザクション処理の制限

- インポート済みトランザクションのコミット処理

- インポート済みトランザクションのリカバリ

13 トランザクションのトラブルシューティング

- 概要

- トラブルシューティング・ツール

- 例外

- トランザクション識別子

- トランザクションの名前とプロパティ

- トランザクション・ステータス

- トランザクションの統計

- トランザクションのモニタリング

- JTAリソースのデバッグ

- デバッグの有効化

- コマンド・ラインを使用してデバッグの有効化

- WebLogic Server管理コンソールを使用してデバッグの有効化

- WebLogic Scripting Toolを使用してデバッグの有効化

- config.xmlファイルの変更内容

- JTAのデバッグ・スコープ

Oracle® Fusion Middleware

Oracle WebLogic Server JTAのプログラミング

11gリリース1 (10.3.6)

B61631-05(原本部品番号:E13731-06)

2011年11月

このドキュメントは、WebLogic Server環境で動作するトランザクション対応Javaアプリケーションの構築に関心のあるアプリケーション開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング, 11gリリース1 (10.3.6)

B61631-05

Copyright © 2007, 2011, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Server JTAのプログラミング』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド(『WebLogic JTAのプログラミング』)の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- このリリースでの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic Server環境で動作するトランザクション対応Javaアプリケーションの構築に関心のあるアプリケーション開発者を対象としています。読者は、WebLogic Serverプラットフォーム、Java Platform, Enterprise Edition (Java EE)プログラミング、およびトランザクション処理の概念に精通していることが前提となっています。

このドキュメントの手引き

- この章第1章「概要とロードマップ」では、このガイドの構成について説明します。

- 第2章「トランザクションについて」では、WebLogic Server環境で動作するEJBおよびRMIアプリケーションにおけるトランザクションについて紹介します。また、この章では、エンタープライズ・アプリケーションの分散トランザクションと2フェーズ・コミット・プロトコルについて説明します。

- 第3章「トランザクションの構成」では、WebLogic Server環境でのトランザクションの管理方法について説明します。

- 第4章「トランザクションの管理」では、トランザクションの管理に使用される管理タスクについて説明します。

- 第5章「トランザクション・サービス」では、WebLogic Serverトランザクション・サービスについて説明します。

- 第6章「Java Transaction APIとOracle WebLogicの拡張機能」では、Java Transaction API (JTA)の概要を説明します。

- 第8章「EJBアプリケーションのトランザクション」では、EJBアプリケーション内でトランザクションを実装する方法について説明します。

- 第9章「RMIアプリケーションのトランザクション」では、RMIアプリケーション内でトランザクションを実装する方法について説明します。

- 第10章「WebLogic ServerでのJDBC XAドライバの使い方」では、トランザクションにおいてサード・パーティのXAドライバを構成する方法および使用する方法について説明します。

- 第11章「WebLogic Serverトランザクション・マネージャでのXAResourceの調整」では、サード・パーティ・システムを構成して、WebLogic Serverトランザクション・マネージャが調整するトランザクションに参加する方法について説明します。

- 第12章「サード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加」では、外部で管理されるトランザクションに対する構成および参加のプロセスについて説明します。

- 第13章「トランザクションのトラブルシューティング」では、JTAを使用するアプリケーションに対するトラブルシューティング作業の実行方法について説明します。

関連ドキュメント

このドキュメントには、JTA固有の設計および開発上の情報が含まれています。WebLogic Serverアプリケーションを開発、デプロイ、およびモニターするための包括的なガイドラインについては、以下のドキュメントを参照してください。

- 『Oracle WebLogic Serverアプリケーションの開発』は、WebLogic Serverアプリケーションの開発ガイドです。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、WebLogic Serverアプリケーションのデプロイメントについての主要な情報源です。

サンプルとチュートリアル

このマニュアルの他にも、トランザクション対応アプリケーションの開発に関するさまざまなコード・サンプルやチュートリアルが用意されています。それらのサンプルとチュートリアルはWebLogic Serverの動作を例示し、主要なアプリケーション開発タスクを実行する実際的な手順を示します。サンプル・サーバーは、Windowsマシンの「スタート」メニューから起動できます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\wl_serverディレクトリからサンプル・サーバーを起動できます。WL_HOMEは、WebLogic Platformの最上位のインストール・ディレクトリです。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecはWebLogic Server配布キットに含まれており、Windowsマシンの「スタート」メニューからアクセスできます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動します。WL_HOMEは、WebLogic Platformの最上位のインストール・ディレクトリです。

このリリースでの新機能と変更点

WebLogic Serverのこのリリースに追加された新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 トランザクションについて

この章では、トランザクションの基本的な概要、トランザクションをいつ使用するか、トランザクションが処理される方法、およびサンプル・トランザクション・コードについて説明します。

- WebLogic Serverアプリケーションのトランザクションの概要

- どのような状況で使用するのか

- トランザクションの仕組み

- トランザクションのサンプル・コード

WebLogic Serverアプリケーションのトランザクションの概要

この節の内容は以下のとおりです。

- トランザクションのACIDプロパティ

- サポートされているプログラミング・モデル

- サポートされているAPIモデル

- 分散トランザクションと2フェーズ・コミット・プロトコル

- ビジネス・トランザクションのサポート

トランザクションのACIDプロパティ

WebLogic Serverの最も基本的な機能の1つはトランザクション管理です。トランザクションは、データベースの変更を正確に完了させるための手段です。また、トランザクションによって、以下のような高性能トランザクションのすべてのACIDプロパティがデータベース・トランザクションに備わります。

- 原子性 - トランザクションによるデータベースへの変更はすべて1つの単位として行われ、そうでない場合にはすべての変更がロールバックされます。

- 一貫性 - トランザクションが正常に実行されると、データベースが前の有効状態から新しい有効状態に変化します。

- 隔離性 - トランザクションによるデータベースへの変更は、トランザクションが処理を完了するまで他の処理からは見えません。

- 持続性 - トランザクションによるデータベースへの変更は、システムまたは媒体の障害が発生しても失われません。

WebLogic Serverはデータベースの更新が正確に行われるようにする優れたインフラストラクチャを備えているので、様々なリソース・マネージャにまたがる場合であってもトランザクションの整合性が保護されます。1つの処理でエラーが起きた場合は、関連するすべての処理がロールバックされます。

サポートされているプログラミング・モデル

WebLogic Serverでは、Java Platform, Enterprise Edition (Java EE)プログラミング・モデルのトランザクションがサポートされています。WebLogic Serverは、Enterprise JavaBeans (EJB)仕様3.0に準拠して、Enterprise JavaBeansを使用するJavaアプリケーションにおけるトランザクションを完全にサポートします。また、WebLogic Serverは、Java Transaction API (JTA)仕様1.1もサポートします。どちらの仕様も次の場所で公開されています:

仕様

場所

EJB 3.0

http://www.oracle.com/technetwork/java/javaee/ejb/index.html

JTA 1.1

http://www.oracle.com/technetwork/java/javaee/jta/index.html

サポートされているAPIモデル

WebLogic Serverでは、Java Transaction API (JTA)がサポートされています。JTAは、以下のアプリケーションで使用されます。

- WebLogic Server EJBコンテナ内のEnterprise JavaBean (EJB)アプリケーション

- WebLogic Serverインフラストラクチャ内のRemote Method Invocation (RMI)アプリケーション

JTAの詳細は、以下のAPI Javadocを参照してください。

- javax.transactionおよびjavax.transaction.xa (http://docs.oracle.com/javaee/5/api/index.html)

- Java Transaction API仕様(http://www.oracle.com/technetwork/java/javaee/jta/index.html)

分散トランザクションと2フェーズ・コミット・プロトコル

WebLogic Serverでは、エンタープライズ・アプリケーションの分散トランザクションと2フェーズ・コミット・プロトコルがサポートされます。分散トランザクションとは、複数のリソース・マネージャ(データベースなど)が調和的に更新されるトランザクションのことです。一方、ローカル・トランザクションは、内部的にAPI呼出しを調整する1つのリソース・マネージャに対して、トランザクションを開始およびコミットします。このため、トランザクション・マネージャはありません。2フェーズ・コミット・プロトコルは、複数のリソース・マネージャにまたがって1つのトランザクションを調整する手段です。これにより、トランザクションによる更新を関連するデータベースのすべてでコミットするか、またはすべてのデータベースから完全にロールバックし、トランザクション開始前の状態に戻すことで、データの整合性が保証されます。つまり、関連するすべてのデータベースが更新されるか、またはどのデータベースも更新されないか、のどちらかだということです。

分散トランザクションには、以下のものが参加します。

- トランザクション・オリジネータ - トランザクションを開始します。トランザクション・オリジネータとしては、ユーザー・アプリケーション、Enterprise JavaBean、またはJMSクライアントがあります。

- トランザクション・マネージャ - アプリケーション・プログラムにかわってトランザクションを管理します。トランザクション・マネージャは、トランザクションの開始と完了を行うアプリケーション・プログラムからのコマンドを、それらのトランザクションに関わるすべてのリソース・マネージャと通信することで調整します。リソース・マネージャがトランザクション中に失敗した場合、トランザクション・マネージャはリソース・マネージャが保留中のトランザクションをコミットするかロールバックするかを決定するのを支援します。

- リカバリ可能なリソース - データの永続ストレージを提供します。ほとんどの場合はリソースとしてデータベースが使用されます。

- リソース・マネージャ - 情報やプロセスへのアクセス手段を提供します。リソース・マネージャとしてはトランザクション対応JDBCドライバがよく使用されます。リソース・マネージャはトランザクションの機能とアクションの永続性を提供します(これらは分散トランザクションの中でアクセスおよび管理されるエンティティ)。リソース・マネージャと特定のリソースとの通信は、トランザクション・ブランチと呼ばれます。

2フェーズ・コミット・プロトコルの最初のフェーズは準備フェーズと呼ばれます。要求される更新がトランザクション・ログ・ファイルに記録され、リソースは、リソース・マネージャを通じて変更の準備ができていることを表明する必要があります。リソースは、更新をコミットするのか、または前の状態にロールバックするのかを意思表示できます。第2フェーズで何が行われるかは、リソースの意思表示によって決まります。すべてのリソースがコミットを支持すると、トランザクションに関わっているすべてのリソースが更新されます。1つまたは複数のリソースがロールバックを支持した場合は、トランザクションに関わっているすべてのリソースが前の状態にロールバックされます。

ビジネス・トランザクションのサポート

WebLogic JTAでは、ビジネス・トランザクションが以下のようにサポートされています。

- クライアント・アプリケーションがトランザクションを開始したときに一意のトランザクション識別子が作成されます。

- トランザクションが表すビジネス・プロセスを説明するトランザクション名(オプション)がサポートされます。トランザクション名を使用すると統計やエラー・メッセージが、より有意義になります。

- トランザクションに関わっており、したがってトランザクションのコミット段階で調整しなければならないオブジェクトを追跡するためにWebLogic Serverインフラストラクチャが連係して機能します。

- トランザクションでアクセスされるときに、リソース・マネージャ(たいていはデータベース)が通知を受けます。通知を受けたリソース・マネージャは、トランザクションが終了するまでアクセス対象のレコードをロックします。

- トランザクションの完了時に2フェーズ・コミットが調整されます。この調整により、トランザクションに関わっているすべてのリソースで更新が同時にコミットされます。コミットの調整は、Open GroupのXAプロトコルを使用して更新されるすべてのデータベースで行われます。この規格は、普及している多くのリレーショナル・データベースでサポートされています。

- トランザクションを停止する必要があるときにロールバック処理が実行されます。

- 障害が起きたときにリカバリ処理が実行されます。クラッシュの時点でアクティブだったトランザクションが確認され、そのトランザクションをロールバックするのかコミットするのかが判断されます。

- トランザクションのタイムアウトが管理されます。ビジネス処理にあまりにも多くの時間がかかる場合、またはビジネス処理が障害のために途中で終了している場合は、トランザクションのタイムアウトが自動的に発行され、データベース・ロックなどのリソースが解放されます。

どのような状況で使用するのか

トランザクションは、以下のような状況で使用するのが適しています。各状況は、WebLogic Serverシステムでサポートされているトランザクション・モデルを表現しています。分散トランザクションは、ユーザー入力の複数の画面にまたがってはいけないことに注意してください。もっと複雑でハイ・レベルなトランザクションは、連続する分散トランザクションで実装する必要があります。

- オブジェクトに対する1回のクライアント呼出しで、オブジェクトによりデータベースのデータが複数回にわたって編集されます。いずれかの編集が失敗した場合、オブジェクトではすべての編集をロールバックすることが必要となります。この状況では、個々のデータベース編集は必ずしもEJBまたはRMIの呼出しではありません。アプレットなどのクライアントでは、JNDIを使用してTransactionオブジェクトおよびTransactionManagerオブジェクトの参照を取得し、トランザクションを開始することができます。
たとえば、銀行のアプリケーションを考えてください。クライアントでは、出納オブジェクトに対して送金処理を要求します。送金処理においては、出納オブジェクトは銀行のデータベースで以下の呼出しを行わなければなりません。

- 1つの口座で送金メソッドを呼び出します。

- 別の口座で入金メソッドを呼び出します。

データベースで入金が失敗した場合、アプリケーションでは直前の送金をロールバックすることが必要となります。

- クライアント・アプリケーションでは、サーバー・アプリケーションで管理されるオブジェクトとの対話を必要とし、特定のオブジェクト・インスタンスに対する複数の呼出しを行う必要があります。その対話には、次のような特徴の1つまたは複数が備わっています。

- データは、連続する各呼出しの間または後でメモリーにキャッシュされるか、データベースに書き込まれます。

- データは、対話の終わりにデータベースに書き込まれます。

- クライアント・アプリケーションでは、各呼出し間のインメモリー・コンテキストを保持するオブジェクトが必要となります。つまり、連続する各呼出しでは、対話の全体を通してメモリーに保持されているデータが使用されます。

- 対話の最後に、クライアント・アプリケーションでは対話の途中または最後に行われたデータベースへの書込み処理をすべて取り消す機能が必要となります。

トランザクションの仕組み

ここでは以下について説明します。

- WebLogic Server EJBアプリケーションのトランザクション

- WebLogic Server RMIアプリケーションのトランザクション

WebLogic Server EJBアプリケーションのトランザクション

図2-1は、WebLogic Server EJBアプリケーションにおいてトランザクションがどのように機能するのかを図示したものです。

図2-1 WebLogic Server EJBアプリケーションでのトランザクションの仕組み

「図2-1 WebLogic Server EJBアプリケーションでのトランザクションの仕組み」の説明

WebLogic Serverでは、WebLogic Server EJBアプリケーションで以下の2種類のトランザクションがサポートされています。

- コンテナ管理のトランザクションでは、WebLogic Server EJBコンテナによってトランザクションの境界設定が管理されます。EJBデプロイメント記述子のトランザクション属性では、各メソッド呼出しでWebLogic Server EJBコンテナがどのようにトランザクションを処理するのかが指定されます。デプロイメント記述子の詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEnterprise Java Beansの実装に関する項を参照してください。

- Bean管理のトランザクションでは、EJBによってトランザクションの境界設定が管理されます。EJBは、UserTransactionオブジェクトに対する明示的なメソッド呼出しを行って、トランザクションの開始、コミット、およびロールバックを行います。詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.UserTransactionを参照してください。

トランザクション・イベントのシーケンスは、コンテナ管理のトランザクションとBean管理のトランザクションで異なります。

コンテナ管理のトランザクション

トランザクションがコンテナで管理されるEJBアプリケーションの場合、基本的なトランザクションは次のように機能します。

1. Beanプロバイダまたはアプリケーション・アセンブラは、EJBのデプロイメント記述子で、トランザクションの種類(transaction-type)としてコンテナ管理の境界設定(Container)を指定します。

2. Beanプロバイダまたはアプリケーション・アセンブラは、EJBのデプロイメント記述子で、EJBのデフォルトのトランザクション属性(trans-attribute要素)を指定します。トランザクション属性としては、NotSupported、Required、Supports、RequiresNew、Mandatory、またはNeverを設定します。これらの設定の詳細は、Enterprise JavaBeans仕様2.0のセクション17.6.2を参照してください。

3. 必要に応じて、Beanプロバイダまたはアプリケーション・アセンブラは、EJBのデプロイメント記述子で、1つまたは複数のメソッドのtrans-attributeを指定します。

4. クライアント・アプリケーションによってEJBのメソッドが呼び出されると、EJBコンテナはデプロイメント記述子でそのメソッドのtrans-attribute設定を調べます。メソッドの設定が指定されていない場合は、そのEJBのデフォルトのtrans-attribute設定が使用されます。

5. EJBコンテナは、trans-attributeの設定に応じて適切に動作します。

- たとえば、trans-attributeの設定がRequiredの場合、EJBコンテナは既存のトランザクション・コンテキストでメソッドを呼び出します。クライアントがトランザクション・コンテキストなしで呼出しを行った場合、EJBコンテナはメソッドを実行する前に新しいトランザクションを開始します。

- trans-attributeの設定がMandatoryの場合、EJBコンテナは既存のトランザクション・コンテキストでメソッドを呼び出します。クライアントがトランザクション・コンテキストなしで呼出しを行った場合、EJBコンテナはjavax.transaction.TransactionRequiredException例外をスローします。

6. ビジネス・メソッドの呼出しの途中で、ロールバックが必要だと判断された場合、ビジネス・メソッドではEJBContext.setRollbackOnlyメソッドが呼び出されます。このメソッドでは、メソッド呼出しの終了時にトランザクションをロールバックしなければならないことがEJBコンテナに通知されます。

注意:

EJBContext.setRollbackOnlyメソッドの呼出しは、意味のあるトランザクション・コンテキストを持つメソッドの場合だけ許可されます。

7. メソッドの実行が終了して、その結果がクライアントに送信される前に、EJBコンテナはコミットするかまたはロールバックすることによってトランザクションを完了します。トランザクションがロールバックされるのは、EJBContext.setRollbackOnlyメソッドが呼び出された場合です。

Bean管理のトランザクション

トランザクションの境界設定がBeanで管理されるEJBアプリケーションの場合、基本的なトランザクションは次のように機能します。

1. Beanプロバイダまたはアプリケーション・アセンブラは、EJBのデプロイメント記述子で、トランザクションの種類(transaction-type)としてコンテナ管理の境界設定(Bean)を指定します。

2. クライアント・アプリケーションは、JNDIを使用して、WebLogic ServerドメインのUserTransactionオブジェクトに対するオブジェクト参照を取得します。

3. クライアント・アプリケーションは、UserTransaction.beginメソッドを使用してトランザクションを開始し、EJBコンテナを通じてEJBへのリクエストを発行します。EJBでのすべての処理は、トランザクションのスコープ内で実行されます。

- いずれかの処理の呼出しで例外が(明示的に、または通信エラーの結果として)生成された場合は、その例外を捕捉し、UserTransaction.rollbackメソッドを使用してトランザクションをロールバックできます。

- 例外が生成されない場合、クライアント・アプリケーションはUserTransaction.commitメソッドを使用して現在のトランザクションをコミットします。このメソッドは、トランザクションを終了して処理を開始します。トランザクションは、そのトランザクションに関わっているすべてのリソースがコミットに同意した場合だけコミットされます。

4. UserTransaction.commitメソッドが呼び出されると、EJBコンテナはトランザクションを完了するためにトランザクション・マネージャを呼び出します。

5. トランザクション・マネージャの役割は、リソース・マネージャと協力してデータベースを更新することです。

WebLogic Server RMIアプリケーションのトランザクション

図2-2は、WebLogic Server RMIアプリケーションでトランザクションがどのように機能するのかを図示したものです。

図2-2 WebLogic Server RMIアプリケーションでのトランザクションの仕組み

「図2-2 WebLogic Server RMIアプリケーションでのトランザクションの仕組み」の説明

RMIのクライアント・アプリケーションとサーバー・アプリケーションの場合、基本的なトランザクションは次のように機能します。

1. アプリケーションは、JNDIを使用して、WebLogic ServerドメインのUserTransactionオブジェクトに対するオブジェクト参照を返します。
オブジェクト参照を取得すると、アプリケーションとそのオブジェクトが会話状態に入ります。会話状態は、コミットかロールバックによってトランザクションが完了するまで続きます。インスタンス化されたRMIオブジェクトは、解放されるまで(たいていはサーバーの停止時)メモリー内でアクティブな状態を維持します。トランザクションの間は、WebLogic Serverインフラストラクチャによって非アクティベーションやアクティベーションは実行されません。

2. クライアント・アプリケーションは、UserTransaction.beginメソッドを使用してトランザクションを開始し、サーバー・アプリケーションへのリクエストを発行します。サーバー・アプリケーションでのすべての処理は、トランザクションのスコープ内で実行されます。

- いずれかの処理の呼出しで例外が(明示的に、または通信エラーの結果として)生成された場合は、その例外を捕捉し、UserTransaction.rollbackメソッドを使用してトランザクションをロールバックできます。

- 例外が生成されない場合、クライアント・アプリケーションはUserTransaction.commitメソッドを使用して現在のトランザクションをコミットします。このメソッドは、トランザクションを終了して処理を開始します。トランザクションは、そのトランザクションに関わっているすべてのリソースがコミットに同意した場合だけコミットされます。

3. UserTransaction.commitメソッドが呼び出されると、WebLogic Serverはトランザクションを完了するためにトランザクション・マネージャを呼び出します。

4. トランザクション・マネージャの役割は、リソース・マネージャと協力してデータベースを更新することです。

詳細については、第9章「RMIアプリケーションのトランザクション」を参照してください。

トランザクションのサンプル・コード

この節の内容は以下のとおりです。

- トランザクションのサンプルEJBコード

- トランザクションのサンプルRMIコード

トランザクションのサンプルEJBコード

この節では、EJBアプリケーションのクラスから抜粋したサンプル・コードを利用して段階的な説明を行います。ここでは以下について説明します。

- パッケージをインポートする

- JNDIを使用してオブジェクト参照を返す

- トランザクションを開始する

- トランザクションを完了する

サンプル・コードでは、Bean管理によるトランザクションの境界設定でUserTransactionオブジェクトが使用されます。このBeanのデプロイメント記述子では、トランザクションの種類(transaction-type要素)としてBean管理によるトランザクションの境界設定(Bean)が指定されます。

注意:

グローバル・トランザクションでは、EJBが実行されているWebLogic Serverインスタンス上の、ローカルJDBCデータ・ソースからデータベース接続を使用します。リモートWebLogic Serverインスタンス上のJDBCデータ・ソースからは接続を使用しないでください。

これらのコード・フラグメントは、WebLogic Serverに付属するサンプル・アプリケーションから抜粋したものではありません。単に、EJBアプリケーションでのUserTransactionオブジェクトの利用を説明するために用意されたものです。

パッケージをインポートする

例2-1は、トランザクションで必要なパッケージのインポートを示しています。必要なパッケージには以下のものがあります。

- javax.transaction.UserTransaction。このオブジェクトに関連付けられているメソッドのリストについては、オンラインのJavadocを参照してください。

- システム例外。例外のリストについては、オンラインのJavadocを参照してください。

例2-1 パッケージのインポート

import javax.naming.*;
import javax.transaction.UserTransaction;
import javax.transaction.SystemException;
import javax.transaction.HeuristicMixedException
import javax.transaction.HeuristicRollbackException
import javax.transaction.NotSupportedException
import javax.transaction.RollbackException
import javax.transaction.IllegalStateException
import javax.transaction.SecurityException
import java.sql.*;
import java.util.*;

JNDIを使用してオブジェクト参照を返す

例2-2に記述されているのは、JNDIツリー上でオブジェクトをルックアップするためのコードです。

例2-2 JNDIルックアップの実行

Context ctx = null;
Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");

// Parameters for the WebLogic Server.
// Substitute the correct hostname, port number
// user name, and password for your environment:
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "Fred");
env.put(Context.SECURITY_CREDENTIALS, "secret");

ctx = new InitialContext(env);

UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");

トランザクションを開始する

例2-3に記述されているのは、UserTransactionオブジェクトを取得し、javax.transaction.UserTransaction.begin()メソッドを呼び出すことによって、トランザクションを開始するコードです。このメソッド呼出しの後、トランザクションが完了するまでに行われるデータベースの処理は、このトランザクションのスコープ内に存在します。

例2-3 トランザクションの開始

UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
tx.begin();

トランザクションを完了する

例2-4に記述されているのは、このトランザクションのスコープ内で試行されたいずれかのデータベース処理で例外がスローされたかどうかに応じて、トランザクションを完了するコードです。

- いずれかのデータベース処理で例外がスローされた場合は、アプリケーションによってjavax.transaction.UserTransaction.rollback()メソッドが呼び出されます。

- 例外がスローされなかった場合は、アプリケーションによってjavax.transaction.UserTransaction.commit()メソッドが呼び出され、すべてのデータベース処理が正常に終了した後にトランザクションのコミットが試行されます。このメソッドが呼び出されると、トランザクションが終了し、処理が開始されて、WebLogic Server EJBコンテナによってトランザクションを完了するためにトランザクション・マネージャが呼び出されます。トランザクションは、そのトランザクションに関わっているすべてのリソースがコミットに同意した場合だけコミットされます。

例2-4 トランザクションの完了

tx.commit();

// or:

tx.rollback();

トランザクションのサンプルRMIコード

この節では、RMIアプリケーションのクラスから抜粋したサンプル・コードを利用して段階的な説明を行います。ここでは以下について説明します。

- パッケージをインポートする

- JNDIを使用してUserTransactionオブジェクトへのオブジェクト参照を返す

- トランザクションを開始する

- トランザクションを完了する

サンプル・コードでは、RMIトランザクションでUserTransactionオブジェクトが使用されます。RMIアプリケーションでトランザクションを使用する際のガイドラインについては、第9章「RMIアプリケーションのトランザクション」を参照してください。

注意:

これらのコード・フラグメントは、WebLogic Serverに付属するサンプル・アプリケーションから抜粋したものではありません。単に、RMIアプリケーションでのUserTransactionオブジェクトの利用を説明するために用意されたものです。

パッケージをインポートする

例2-5に記述されているのは、必要なパッケージをインポートするコードです。必要なパッケージには、トランザクションの処理に使用する以下のパッケージが含まれます。

- javax.transaction.UserTransaction。このオブジェクトに関連付けられているメソッドのリストについては、オンラインのJavadocを参照してください。

- システム例外。例外のリストについては、オンラインのJavadocを参照してください。

例2-5 パッケージのインポート

import javax.naming.*;
import java.rmi.*;
import javax.transaction.UserTransaction;
import javax.transaction.SystemException;
import javax.transaction.HeuristicMixedException
import javax.transaction.HeuristicRollbackException
import javax.transaction.NotSupportedException
import javax.transaction.RollbackException
import javax.transaction.IllegalStateException
import javax.transaction.SecurityException
import java.sql.*;
import java.util.*;

これらのクラスがインポートされた後に、UserTransactionオブジェクトのインスタンスがnullに初期化されます。

JNDIを使用してUserTransactionオブジェクトへのオブジェクト参照を返す

例2-6に記述されているのは、JNDIツリーの検索し、適切なWebLogic ServerドメインのUserTransactionオブジェクトに対するオブジェクト参照を返すためのコードです。

注意:

オブジェクト参照を取得すると、アプリケーションとそのオブジェクトが会話状態に入ります。会話状態は、コミットかロールバックによってトランザクションが完了するまで続きます。インスタンス化されたRMIオブジェクトは、解放されるまで(たいていはサーバーの停止時)メモリー内でアクティブな状態を維持します。トランザクションの間は、WebLogic Serverインフラストラクチャによって非アクティベーションやアクティベーションは実行されません。

例2-6 JNDIルックアップの実行

Context ctx = null;
Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");

// Parameters for the WebLogic Server.
// Substitute the correct hostname, port number
// user name, and password for your environment:
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "Fred");
env.put(Context.SECURITY_CREDENTIALS, "secret");

ctx = new InitialContext(env);

UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");

トランザクションを開始する

例2-7に記述されているのは、javax.transaction.UserTransaction.begin()メソッドを呼び出してトランザクションを開始するためのコードです。このメソッド呼出しの後、トランザクションが完了するまでに行われるデータベースの処理は、このトランザクションのスコープ内に存在します。

例2-7 トランザクションの開始

UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
tx.begin();

トランザクションを完了する

例2-8に記述されているのは、このトランザクションのスコープ内で試行されたいずれかのデータベース処理で例外がスローされたかどうかに応じて、トランザクションを完了するコードです。

- いずれかのデータベース処理で例外がスローされた場合は、アプリケーションによってjavax.transaction.UserTransaction.rollback()メソッドが呼び出されます。

- 例外がスローされなかった場合は、アプリケーションによってjavax.transaction.UserTransaction.commit()メソッドが呼び出され、すべてのデータベース処理が正常に終了した後にトランザクションのコミットが試行されます。このメソッドが呼び出されると、トランザクションが終了し、処理が開始されて、WebLogic Serverによってトランザクションを完了するためにトランザクション・マネージャが呼び出されます。トランザクションは、そのトランザクションに関わっているすべてのリソースがコミットに同意した場合だけコミットされます。

例2-8 トランザクションの完了

tx.commit();

// or:

tx.rollback();

3 トランザクションの構成

この章では、トランザクション関連の基本的な構成タスクについて説明します。これらのタスクには、JTAの使用、セキュアなトランザクション通信の構成、トランザクション・ログ(TLOG)ファイルの使用、読取り専用の1フェーズ・コミット最適化の使用があります。

- トランザクション構成の概要

- JTAの構成

- ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

- トランザクション・ログ・ファイル

- 読取り専用1フェーズ・コミットの最適化

トランザクション構成の概要

管理コンソールは、WebLogic JTAなどのWebLogic Serverの機能を構成するために使用するインタフェースを備えています。構成プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。

- トランザクションのタイムアウトと制限

- トランザクション・マネージャの動作

また、EJB、JDBCデータ・ソース、JMSなど、トランザクションに参加可能なJava EEコンポーネントの管理についてもよく理解しておく必要があります。

注意:

トランザクション関連の構成には、WebLogic Scripting Tool (WLST)(『Oracle WebLogic Scripting Tool』を参照)またはJMX(『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照)を使用することもできます。

JTAの構成

WebLogic JTAおよび任意のトランザクション参加コンポーネントを構成すると、システムはJTA APIおよびWebLogic JTA拡張機能を使用してトランザクションを管理できます。次の点に注意してください。

- JTA(トランザクション)の構成設定は、ドメイン・レベルで適用できます。つまり、構成属性の設定はドメイン内のすべてのサーバーに適用されることになります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの構成に関する項を参照してください。

- JTAのモニター・タスクは、サーバー・レベルで実行されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAのモニターに関する項を参照してください。

- 参加リソース(JDBCデータ・ソースなど)の構成設定は、構成されるオブジェクトごとに行われます。設定は、特定のオブジェクトのすべてのインスタンスに対して適用されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のJDBCデータ・ソース・トランザクション・オプションに関する項およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのグローバル・トランザクション・オプションの構成に関する項を参照してください。

リソース登録解除の猶予期間

アプリケーションと一緒にパッケージ化されたJDBCデータ・ソース・モジュールなど、必要に応じてアンデプロイしたり再デプロイしたりすることのあるリソースについては、ドメインに対して「リソース登録解除の猶予期間」を設定することで、リソースが登録解除されていたためにトランザクションが破棄される可能性を最小限にできます。猶予期間とは、リソースが登録解除される前に、トランザクション・マネージャがトランザクションの完了を待機する秒数です。

指定された猶予期間の間、unregisterResource呼出しは自身が返るまでブロックを行い、関連するリソースに対して新しいトランザクションは開始されません。リソースに対して未処理のトランザクションの数が0になると、unregisterResource呼出しは即座に返ります。

猶予期間の終わりに、まだリソースに関連する未処理のトランザクションがある場合は、unregisterResourceが返り、リソースが以前登録されていたサーバー上にログ・メッセージが書き込まれます。

トランザクションを管理するための追加属性

デフォルトでは、グローバル・トランザクションに参加しているXAリソースがWebLogic Serverトランザクション・マネージャからのXA呼出しに応答しないと、そのリソースに異常があって使用できないことを示すフラグが付加されます。また、リソースのスレッドを保持するため、このリソースに対する以降のすべての呼出しがブロックされます。障害は、トランザクションに異常がある場合でも、リソースに異常がある場合でも発生する可能性があります。これら2つの原因の間に区別はありません。どちらの場合も、リソースに異常があるものとしてマークされます。

この制約を緩和するため、WebLogic Serverには表3-1に列記したような構成属性が用意されています。

表3-1 XAリソースのヘルス監視構成属性

属性

MBean

定義

ResourceHealthMonitoring

weblogic.managment.configuration.JDBCXAParamsBean

JDBCXAParamsBean MBeanのResourcehealthMonitoring属性。

JDBCデータ・ソースのリソースのヘルス監視を有効または無効にします。この属性は、データベース接続にXA JDBCドライバを使用するデータ・ソースにのみ適用されます。非XA JDBCドライバを使用している場合は無視されます。

trueに設定すると、リソースのヘルス監視が有効になります。MaxXACallMillis属性に指定した期間内にXAリソースがXA呼出しへの応答に失敗すると、データ・ソースに異常があるものとしてマークされ、リソースに対する以降の呼出しがすべてブロックされます。

falseに設定すると、この機能が無効になります。

デフォルト: true

JDBCデータ・ソースの「リソース・ヘルス監視」属性は、管理コンソールの「JDBCデータ・ソース」→「構成」→「接続プール」タブで設定します。

MaxXACallMillis

weblogic.management.configuration.JTAMBean

XAリソースに対するXA呼出しの最長許容期間をミリ秒で設定します。この設定は、ドメイン全体に適用されます。

デフォルト値: 120000

MaxResourceUnavailableMillis

weblogic.management.configuration.JTAMBean

XAリソースが異常とマークされる最長期間(ミリ秒)。この期間を過ぎると、トランザクション・マネージャでXAリソースを明示的に再登録しなくても、リソースが再び使用可能と宣言されます。この設定は、ドメイン全体に適用されます。

デフォルト値: 1800000

MaxResourceRequestOnServer

weblogic.management.configuration.JTAMBean

ドメイン内の各サーバーで許容するリソースへの同時リクエストの最大数。

デフォルト値: 50

最小値: 10

最大値: java.lang.Integer.MAX_VALUE

JDBCデータ・ソースの「リソース・ヘルス監視」を除き、これらの属性は、ドメインが非アクティブの時にconfig.xmlファイルで直接設定します。これらの属性は、管理コンソールでは使用できません。次の例は、これらの属性に関する部分を構成ファイルから抜粋したものです。

...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
/>

ドメイン間およびドメイン内トランザクションのセキュアな通信の構成

分散トランザクションを管理するトランザクション・マネージャの場合、トランザクション・マネージャは、トランザクションを準備して、コミットまたはロールバックするためにすべての参加サーバーやリソースと通信できるようにしておく必要があります。通信チャネルの構成は、トランザクション・ルートが次のどちらであるかによって異なります。

- ドメイン間 - トランザクション通信は、同じドメイン内ではないトランザクションに参加するサーバー間で行われます。

- ドメイン内 - トランザクション通信は、同じドメイン内のトランザクションに参加するサーバー間で行われます。

通信チャネルは、悪質なサード・パーティがトランザクションの結果に影響を与える中間者攻撃を使用できず、1つ以上のドメイン間で管理制御を取得できないようにセキュアにしておく必要があります。WebLogic Serverには、通信チャネルをセキュアにする次のオプションが用意されています。

- クロス・ドメイン・セキュリティ - 資格証明マッパーを使用して、ドメイン間トランザクションのサーバー間で互換性のある通信チャネルを構成できます。この場合、複雑な構成が必要になりますが、クロス・ドメイン・セキュリティを使用すると、各ドメイン間の信頼を調整できます。

- セキュリティの相互運用モード - すべてのドメインのセキュリティの資格証明を同じ値に設定して、トランザクションに参加するすべてのドメイン間での信頼を確立します。これにより、あるWebLogic Serverインスタンスのサブジェクトのプリンシパルが、別のインスタンスのプリンシパルとして受け入れられます。クロス・ドメイン・セキュリティを構成するよりも簡単ですが、「セキュリティの相互運用モード」の一部の設定は、ドメイン信頼に依存するため、クロス・ドメイン・セキュリティよりもセキュリティの程度は低くなります。

次の項では、トランザクション時にサーバー間でセキュアな通信を構成する方法について説明します。

- トランザクション通信の要件

- ドメイン間トランザクションに対する通信の構成

- ドメイン内トランザクションに対するドメインの構成

- クロス・ドメイン・セキュリティの構成

- セキュリティの相互運用モードの構成

トランザクション通信の要件

トランザクション環境に通信チャネルを構成する場合、次の要件に注意してください。

- ドメイン名およびすべての参加リソースの名前は一意でなければなりません。したがって、JDBCデータ・ソース、サーバー、またはドメインを、別のドメイン内や同じドメイン内のオブジェクトと同じ名前にすることはできません。

- プロセスで使用されるすべてのドメインについて、クロス・ドメイン・セキュリティを構成するか、セキュリティの相互運用モードを設定します。どちらの設定もドメイン・レベルで設定されるため、ドメインがクロス・ドメイン・セキュリティとセキュリティの相互運用モードの両方が設定された混在モードになる可能性があります。

- WebLogic Server 8.1ドメインと相互運用している場合、JMX 1.0とJMX 1.2の間に互換性がないことに伴って、ドメイン間トランザクションを実行する際に問題が発生する場合があることが知られています。この非互換性に伴う問題を解決するには、JVMフラグ-Djmx.serial.form=1.0を使用します。詳細は、『Oracle WebLogic Serverアップグレード・ガイド』のJMX 1.2実装に関する項を参照してください。

- 次の2つの属性が両方とも次のように設定されているデータ・ソースは、グローバル・トランザクションには1つしか参加させることができません。この制約は、データ・ソースがどのドメインに構成されているかに関係なく適用されます。

- 「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を選択しています。

- データ・ソースで、非XAドライバを使用してデータベース接続を作成しています。

ドメイン間トランザクションに対する通信の構成

グローバル・トランザクションに参加するすべてのドメインについて、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードを使用し、互換性のある通信チャネルを適切に構成する必要があります。次を参照してください。

- クロス・ドメイン・セキュリティの構成

- セキュリティの相互運用モードの構成

次の表を参考に、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードを使用するタイミングを決定します。

表3-2 チャネル構成の選択

チャネル構成

長所

短所

クロス・ドメイン・セキュリティ

- ドメインのペア間で通信を確立するように特定のユーザーが構成されます。

- SSLを使用する場合、中間者攻撃を防止します。

- 構成がより複雑になります。

- トランザクション・フローの変更(参加者、参加者ロール(コーディネータとリソースまたはサブコーディネータ)の変更、ドメインの追加や削除、トランザクション・ルートの変更など)には、構成の変更が必要です。

セキュリティの相互運用モード

- 構成が非常に簡単です。

- セキュリティの相互運用モードの構成時にトランザクション・フローを理解する必要はありません。

- WebLogic 8.1との後方互換性があります。

- defaultモードで管理チャネルを使用すると、中間者攻撃が防止されます。

- 信頼は推移的です: ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合、ドメインAはドメインCを信頼します。

- compatibilityに設定すると、ドメイン間信頼によって、ドメイン間での管理者権限が付与されます。つまり、ドメイン間で信頼が確立されている場合、ドメインAの管理者にはドメインBの管理者権限があります。

- 一部の構成では、中間者攻撃の可能性がわずかにあります。

ドメイン間トランザクション用にどのタイプの通信チャネルを構成する必要があるかについては、次の表を参考に判断してください。

表3-3 ドメイン間トランザクション用の通信チャネルの構成

ドメイン

10.xおよび9.2 MP2以上

9.0、9.1、および9.2 MP1以下

8.1 SP5以上

8.1 SP4以下

10.xおよび9.2 MP2以上

両方のドメインをクロス・ドメイン・セキュリティ用に構成する

または

セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、9.0、9.1、または9.2 MP1以下のドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、両方のドメインを「パフォーマンス」に設定する

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、10.xまたは9.2 MP2以上のドメインを「互換性」に設定する

9.0、9.1、および9.2 MP1以下

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、9.0、9.1、または9.2 MP1以下のドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する

両方のドメインを「デフォルト」または「パフォーマンス」に設定する

両方のドメインを「パフォーマンス」に設定する

9.xのドメインを「互換性」に設定する

8.1 SP5以上

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、両方のドメインを「パフォーマンス」に設定する

両方のドメインを「パフォーマンス」に設定する

両方のドメインを「パフォーマンス」に設定する

8.1 SP5以上のドメインを「互換性」に設定する

8.1 SP4以下

10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する

または

セキュリティの相互運用モードを使用し、10.xまたは9.2 MP2以上のドメインを「互換性」に設定する

9.xのドメインを「互換性」に設定する

8.1 SP5以上のドメインを「互換性」に設定する

なし

注意:

セキュリティの相互運用モードが「パフォーマンス」に設定されている場合、ドメイン間のドメイン信頼の設定は必須ではありません。

ドメイン内トランザクションに対するドメインの構成

セキュリティの相互運用モードを使用して、同じドメイン内のトランザクションに参加するサーバー間に、互換性のある通信チャネルを正しく構成する必要があります。「セキュリティの相互運用モードの構成」を参照してください。

WebLogic Server 10.xドメインのサーバーの場合は、参加サーバーをdefault、performance、またはcompatibilityに設定します。

クロス・ドメイン・セキュリティの構成

クロス・ドメイン・セキュリティでは、資格証明マッパーを使用することで、グローバル・トランザクション内のサーバー間に、互換性のある通信チャネルを構成することを可能にしています。トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを1つずつ構成します。CrossDomainConnectorセキュリティ・ロールに属する資格証明は、ドメイン・ペアごとに異なっていてもかまいません(詳細は、『Oracle WebLogic Serverの保護』のクロス・ドメイン・ユーザーの構成に関する項を参照してください)。

『Oracle WebLogic Serverの保護』のWebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化に関する項およびクロス・ドメイン・セキュリティの資格証明マッピングの構成に関する項を参照してください。

クロス・ドメイン・セキュリティは推移的ではない

トランザクションに参加する複数のサーバーでは、相互にクロス・ドメインの資格証明マッピングを設定します。ドメイン信頼とは異なり、クロス・ドメイン・セキュリティの構成は推移的ではありません。つまり、AがBを信頼し、BがCを信頼していても、それによってAがCを信頼しているということにはなりません。

以下のシナリオについて考察します。

- DomainAにはServer1があります(コーディネータ)

- DomainBにはServer2があります(サブコーディネータ)

- DomainCにはServer3とServer4があります(Server3はサブコーディネータ)

- DomainDにはServer5があります(トランザクションには参加しません)

このシナリオでクロス・ドメインの資格証明マッピングを設定するには、次の操作を行います。

1. DomainAにおいてDomainBのクロス・ドメイン・セキュリティを設定します。

2. DomainBにおいてDomainAのクロス・ドメイン・セキュリティを設定します。

3. DomainAにおいてDomainCのクロス・ドメイン・セキュリティを設定します。

4. DomainCにおいてDomainAのクロス・ドメイン・セキュリティを設定します。

5. DomainBにおいてDomainCのクロス・ドメイン・セキュリティを設定します。

6. DomainCにおいてDomainBのクロス・ドメイン・セキュリティを設定します。

DomainDはトランザクションに参加しないため、クロス・ドメインの資格証明マッピングを使用する必要はありません。ただし、「トランザクションへの参加に基づいて除外リストにドメインを追加する」にある、より詳細な説明を参照してください。

これらを分かりやすい形で表したのが、表3-4です。表のセルに「必要」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。

表3-4 参加ドメインが3つの場合のクロス・ドメイン・セキュリティの設定

--

DomainA

DomainB

DomainC

DomainD

DomainA

いいえ

はい

はい

いいえ

DomainB

はい

いいえ

はい

いいえ

DomainC

はい

はい

いいえ

いいえ

DomainD

いいえ

いいえ

いいえ

いいえ

その上でクロス・ドメイン・セキュリティの構成にDomainDを追加し、さらにDomainEも追加する場合、クロス・ドメインの資格証明マップは表3-5のようになります。表のセルに「必要」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。

表3-5 参加ドメインが5つの場合のクロス・ドメイン・セキュリティの設定

DomainA

DomainB

DomainC

DomainD

DomainE

DomainA

いいえ

はい

はい

はい

はい

DomainB

はい

いいえ

はい

はい

はい

DomainC

はい

はい

いいえ

はい

はい

DomainD

はい

はい

はい

いいえ

はい

DomainE

はい

はい

はい

はい

いいえ

トランザクションへの参加に基づいて除外リストにドメインを追加する

除外リストでは、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと、クロス・ドメイン・セキュリティがサポートされていないか、有効になっていない別のドメインのサーバーがトランザクションに参加するためのメカニズムが提供されます。

クロス・ドメイン・セキュリティが構成されていないドメインのサーバーが、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと一緒にトランザクションに参加する場合、クロス・ドメイン・セキュリティが構成されているドメインの除外リストに該当ドメインを追加します。「クロス・ドメイン・セキュリティを構成する場合の重要な考慮事項」の説明に従い、セキュリティの相互運用モードを使用して、参加ドメインの通信チャネルを確立します。

クロス・ドメイン・セキュリティが構成されているドメインすべての除外リストにドメインを追加する必要はありません。ただし、除外リストへ追加する必要があるケースでは、ドメインとのトランザクションへの参加を明示的に行う必要があります。

以下のシナリオについて考察します。

- トランザクション#1:

- DomainAにはServer1があります(コーディネータ)

- DomainBにはServer2があります(サブコーディネータ)

- DomainCにはServer3とServer4があります(Server3はサブコーディネータ)

- DomainDにはServer5があります(トランザクションには参加せず、クロス・ドメイン・セキュリティは構成されていません)

- トランザクション#2:

- DomainBにはServer6があります(コーディネータ)

- DomainDにはServer5があります(サブコーディネータで、クロス・ドメイン・セキュリティは構成されていません)

この場合、トランザクション#2のためにDomainDをDomainBの除外リストに追加する必要があります。

DomainAおよびDomainCのサーバーとのトランザクションには参加していないため、これら2つのドメインの除外リストにはDomainDを含める必要はありません。

クロス・ドメイン・セキュリティを構成する際の重要な考慮事項

クロス・ドメイン・セキュリティを構成する際には、以下のガイドラインを考慮に入れてください。

- クロス・ドメイン・セキュリティでは、ドメイン信頼は必須ではありません。

- トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを正しく構成する必要があります - CrossDomainConnectorセキュリティ・ロールに属する資格証明のセットを設定しなければなりません。資格証明マッピングが正しくないと、参加ドメイン間のトランザクションは失敗します。『Oracle WebLogic Serverの保護』のクロス・ドメイン・セキュリティの資格証明マッピングの構成に関する項を参照してください。

- 中間者攻撃からトランザクションを保護するには、一方向SSLを構成して通信のセキュリティを強化します。

- クロス・ドメイン・セキュリティをサポートしない(またはクロス・ドメイン・セキュリティが無効になっている)WebLogicドメインと相互運用するには、それらのドメインを、クロス・ドメイン・セキュリティが有効になっているすべての参加WebLogic Serverドメインの「除外するドメイン名」リストに追加する必要があります。「除外するドメイン名」およびCrossDomainSecurityEnabledフラグの構成が、すべての参加ドメインで統一されていない場合、トランザクションのブランチは失敗します。

- Cross Domain Security Enabledフラグが無効になっているか、ドメインがExcluded Domain Namesリストに含まれている場合は、セキュリティの相互運用モードを使って参加ドメインとの通信チャネルが確立されます。

- 「クロス・ドメイン・セキュリティの有効化」フラグの有効/無効の設定を切り替えると、しばらくの間トランザクションや他のリモート呼出しが失敗することがあります。トランザクションにおいてコミット・リクエストが失敗した場合は、構成の変更が完了した後にコミットが再試行されます。トランザクションのRMI呼出しが失敗した場合は、トランザクションがタイムアウトしてロールバックされます。ロールバックは、AbandonTimeoutSecondsが経過するまで再試行されます。

セキュリティの相互運用モードの構成

「セキュリティの相互運用モード」を使用すると、グローバル・トランザクション内のサーバー間に、互換性のある通信チャネルを構成できます。次の手順に従って、セキュリティの相互運用モードを構成します。

1. ドメイン信頼を確立する

2. 表3-3の値を使用して、セキュリティの相互運用モードの構成を行います。

注意:

セキュリティの相互運用モードが「パフォーマンス」に設定されている場合、ドメイン間のドメイン信頼の設定は必須ではありません。

ドメイン信頼を確立する

すべての参加ドメインのセキュリティ資格証明を同じ値に設定することにより、ドメイン信頼を確立します。

- 8.xドメインについては、『WebLogicセキュリティの管理』のWebLogicドメイン間の信頼の有効化に関する項(http://docs.oracle.com/cd/E13222_01/wls/docs81/secmanage/domain.html#domain_interop)を参照してください。

- 9.xドメインについては、Oracle WebLogic Server管理コンソール・ヘルプのドメイン間での信頼の有効化に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html)を参照してください。

- 10.xドメインについては、Oracle WebLogic Server管理コンソール・ヘルプのドメイン間での信頼の有効化に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html)を参照してください。

セキュリティの相互運用モードの構成

参加しているすべてのサーバーの「セキュリティの相互運用モード」パラメータを同じ値に設定する必要があります。

有効な値は以下のとおりです。

- default - トランザクション・コーディネータでは、カーネルIDを使用し、管理チャネル(有効化されている場合)を介して呼出しを行います。管理チャネルが構成されていない場合、セキュリティの相互運用モードの動作は、performanceを使用する場合と同じになります。

- performance - トランザクション・コーディネータでは、常にanonymousを使用して呼出しを行います。この設定では、悪意のあるサード・パーティが中間者攻撃を通じてトランザクションの結果に影響を与える可能性があるため、セキュリティ上、リスクを伴います。

- compatibility - トランザクション・コーディネータでは、カーネルIDで非セキュアなチャネルを使用して呼出しを行います。このモードは、セキュリティの相互運用モードをサポートしていないWebLogic Serverサーバーと対話する場合に必要です。中間者攻撃が成功すると、攻撃者は双方のドメインに対する管理制御権を得ることができるため、セキュリティ上のリスクが高くなります。この設定は、強固なネットワーク・セキュリティが確立されている場合にのみ使用してください。

参加しているサーバーのセキュリティの相互運用モードを構成する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- WebLogic Server 10.xドメイン内のサーバーについては、セキュリティの相互運用性モードの構成に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)を参照してください。

- WebLogic Server 9.xドメイン内のサーバーについては、XAトランザクションのセキュリティ・モードの構成に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)を参照してください。

- WebLogic Server 8.1ドメイン内のサーバーについては、セキュリティの相互運用性モードの使用に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/jta.html#CR241279)を参照してください。

管理ユーザーを必要とするJNDIルックアップ用にドメインを構成する

以下では、管理ユーザーを必要とするJNDIルックアップをトランザクションが使用する際にセキュリティの相互運用モードを構成する方法について説明します。

- WebLogic Serverドメインが9.0、9.1、9.2およびMP以上、または10.xおよびMP以上の場合は、以下のいずれかを行います。

- セキュリティの相互運用モードを「デフォルト」に設定し、管理チャネルを構成し、ドメイン信頼を有効にします。

- セキュリティの相互運用モードを「互換性」に設定し、ドメイン信頼を有効にします。

- WebLogic Serverドメインが8.1SP5以上の場合は、SecurityInteropMode=compatibilityを設定し、ドメイン信頼を有効にします。

セキュリティの相互運用モードを「互換性」に設定すると、中間者攻撃を受ける可能性があります。

トランザクション・ログ・ファイル

各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。トランザクション・ログを直接見ることはできません。レコードはバイナリ形式で、サーバーのデフォルト永続ストアまたはJDBC TLOGストアに格納されます。

デフォルト永続ストアの使い方

クラスタ内のサーバーに対するトランザクション・リカバリ・サービスの移行機能を利用するには、トランザクション・ログをサーバーとそのバックアップ・サーバーが使用できる場所(デュアル・ポートSCSIディスクまたはSAN (Storage Area Network)を推奨)に格納する必要があります。詳細については、「デフォルト永続ストアへのパスの設定」を参照してください。

デフォルトのストアがトランザクション・ログ・レコードの保存先とするファイル・システムで領域が不足したり、アクセス不能になったりすると、commit()によりSystemExceptionがスローされ、トランザクション・マネージャによってシステム・エラー・ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。

デフォルト永続ストアへのパスの設定

管理サーバーを含む、各サーバー・インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイル・ベースのストアです。トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。多くの場合、デフォルトの永続ストアは、構成を必要としません。ただし、トランザクション・リカバリ・サービスの移行を有効化するには、オリジナルのサーバーで障害が発生した場合に、クラスタ内の別のサーバーで使用できる、永続ストレージ・ソリューションに、データ・ファイルを格納するよう、デフォルトの永続ストアを構成する必要があります。

手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。

デフォルト永続ストアの同期書込みポリシーの設定

WebLogic Serverは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。デフォルト・ストアの書込みポリシーを選択し、WebLogic Serverがレコードをディスクに書き込む方法を変更します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』の同期書込みポリシーの構成ガイドラインに関する項を参照してください。

手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。

JDBC JTOGストアの使い方

JDBC TLOGストアを構成して、トランザクション・ログをデータベースに永続化することができます。こうすることで、基礎となるデータベースのレプリケーションやHAの活用、障害回復の単純化、トランザクション回復サービスの移行の改善が可能になります。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のJDBC TLogの使用に関する項を参照してください。

読取り専用1フェーズ・コミットの最適化

Oracle Database (AQおよびRACを含む)などのリソース・マネージャによって読取り専用最適化が提供される場合、Oracle WebLogicで読取り専用1フェーズ・コミットの最適化を提供することができます。これによって、同一XAトランザクションの複数の接続を有効にする場合でも、Oracle WebLogicとリソース・マネージャの両方に、XAResource.prepareネットワーク・コールの消去やトランザクション・ログ書込みなどの様々な利点がもたらされます。

注意:

読取り専用1フェーズ・コミットの最適化には、Oracle DB 11.1.0.7.3PSU以上が必要です。

2フェーズ・コミット・トランザクションを必要としないアプリケーションの場合、WebLogicの「2フェーズ・コミット」プロトコルを無効にすることで、パフォーマンスをさらに最適化できます。このプロトコルは、2つ以上のリソース・マネージャ全体のトランザクションを調整します。2フェーズ・コミットを無効にするには、次の手順を実行します。

- 永続的なインダウト・ロギングおよびロック、ならびにデータベースのブックキーピング・オーバーヘッドを削除します。

- WebLogicのすべてのチェックポイント・ロギングを削除します。

- 特定のサーバー・インスタンスが2フェーズ・コミットを必要としないという前提を、施行またはテスト(あるいはその両方を実行)します。

- WebLogic移行(サーバーまたはサービス全体)リカバリの必要性を排除します。これによって、その移行に関わる追加のアセット/キャパシティ、管理などの必要性が排除されます。

読取り専用1フェーズ・コミットの最適化と2フェーズ・コミット無効化の設定

読取り専用1フェーズ・コミットの最適化を有効にし、2フェーズ・コミットを無効化するには、次のJTAドメイン構成属性を設定します。

- XA呼出しの並列実行 - falseに設定すると、読取り専用1フェーズ・コミットの最適化が有効になります。

- 2フェーズ・コミットの有効化 - (オプション)falseに設定すると、2フェーズ・コミットが無効になります。これによって、チェックポイント・レコードを含むすべてのトランザクション・ロギングが無効になります。2フェーズ・コミットの使用を試行すると、RollbackExceptionがスローされます。
重要:「2フェーズ・コミットの有効化」設定(デフォルトではtrueに設定されている)は、読取り専用最適化を提供するリソース・マネージャ(Oracleデータベースなど)のみをアプリケーションが使用すること、あるいは単一のリソース・マネージャへの単一の接続のみをアプリケーションが使用することが周知されている場合を除き、falseには設定してはなりません。

注意:

XAリソースがXA_OK投票を準備から返し(例: 対象がOracleデータベースではない場合)、その後ロールバックが発生する前にWebLogicインスタンスがクラッシュする場合は、インダウト・レコードが存在し、ロックがリソース・マネージャ(データベース)で保持されるため、手動で解決する必要があります。

すべてのJTAドメイン構成オプションの詳細は、WebLogic管理コンソール・オンライン・ヘルプのJTAドメインの構成に関する項を参照してください。

読取り専用1フェーズ・トランザクション統計の監視

監視目的のため、JTAの「監視」ページには5つのトランザクション処理統計があります。これらの統計はともに「コミット済みトランザクション総数」統計を分類し、あらゆる読取り専用1フェーズ・トランザクション統計を追跡しやすくします。

- リソースのないコミット済みトランザクションの合計数 - サーバーの起動以降コミットされた、リソースが確保されていないトランザクションの合計数。

- 1リソース1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降1フェーズ・コミットされた、1リソースのみが確保されたトランザクションの合計数。

- 読取り専用1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降、読取り専用最適化のために1フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。

- 2フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降2フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。

- LLRコミット済みトランザクション合計数 - サーバーの起動以降コミットされたLLRトランザクションの合計数。
注意: JTAトランザクションに列記された唯一のリソースがLLRデータ・ソースの場合、そのトランザクションは「LLRコミット済みトランザクション合計数」カテゴリではなく、「1リソース1フェーズ・コミット済みトランザクション合計数」カテゴリの下に含まれます。

JTA監視統計の詳細は、WebLogic管理コンソール・オンライン・ヘルプのJTA統計の監視に関する項を参照してください。

4 トランザクションの管理

この章では、トランザクションの管理に使用される管理タスクに関する情報を提供します。これらのタスクには、トランザクションの監視、ヒューリスティックな終了の処理、トランザクションの破棄方法、処理中のトランザクションの解決、およびトランザクションのリカバリが含まれます。

- トランザクションのモニタリング

- ヒューリスティックな終了の処理

- サーバーの移動

- トランザクションの破棄

- 現在(処理中)のトランザクションの手動での解決

- サーバーに障害が発生した後のトランザクションのリカバリ

統計およびモニターの機能を使用して、サーバー上のトランザクションをモニターできます。管理コンソールでは、それらの機能を構成したり、結果出力を表示したりできます。

トランザクションのモニタリング

管理コンソールで、ドメイン内の各サーバーのトランザクションをモニターできます。トランザクションの統計は、ドメイン全体ではなく、特定のサーバーについて表示されます。

手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。

- 「トランザクション統計の表示」(および「サーバー: モニター: JTA: 概要」)

- 「名前付きトランザクションの統計の表示」(および「サーバー: モニター: JTA: トランザクション(名前指定)」)

- 「XAリソースのトランザクション統計の表示」(および「サーバー: モニター: JTA XAリソース」)

- 「非XAリソースのトランザクション統計の表示」(および「サーバー: モニター: JTA: 非XAリソース」)

- 「現在のトランザクションの表示」(および「サーバー: モニター: JTA: トランザクション」)

- 「トランザクション・リカバリの統計の表示」(および「サーバー: モニター: JTA: リカバリ・サービス」)

ヒューリスティックな終了の処理

ヒューリスティックな終了 (ヒューリスティックな決定)は、更新をコミットまたはロールバックする分散トランザクションの終了段階で、リソースが一方だけの決定を行ったときに発生します。これにより、分散されたデータは不確定な状態のままになります。ヒューリスティックな終了の原因としては、ネットワークの障害またはリソースのタイムアウトが考えられます。ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかがスローされます。

- HeuristicRollback - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のロールバックを自発的に決定した場合。トランザクション・マネージャがトランザクションのコミットを決定すると、そのリソースによるヒューリスティックなロールバックの決定は不正になり、トランザクションの他のブランチはコミットされるため、矛盾した結果を招きます。

- HeuristicCommit - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のコミットを自発的に決定した場合。トランザクション・マネージャがトランザクションのロールバックを決定すると、そのリソースによるヒューリスティックなコミットの決定は不正になり、トランザクションの他のブランチはロールバックされるため、矛盾した結果を招きます。

- HeuristicMixed - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になったことを、トランザクション・マネージャで認識している場合。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。

- HeuristicHazard - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になった可能性があることを、トランザクション・マネージャで認識している場合。ただし、システムまたはリソースに障害があるため、HeuristicMixedの結果が確かに発生したかどうかを確認できません。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。

ヒューリスティックな終了が発生すると、サーバー・ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース・ベンダーが提供するドキュメントを参照してください。

一部のリソース・マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース・マネージャのデータの矛盾を解決するときに便利です。WebLogicコンソールのJTAパネルでForgetHeuristics属性が選択されている(trueに設定されている)場合、この情報はヒューリスティックな終了の後で削除されます。コンテキスト情報を保存するリソース・マネージャを使用するときには、ForgetHeuristics属性をfalseに設定することをお薦めします。

サーバーの移動

サーバー・インスタンスは、そのURL (IPアドレスまたはDNS名にリスニング・ポートの番号を付加したもの)によって特定されます。サーバーを新しいマシンに移動したり、同じマシン上でサーバーのリスニング・ポートを変更したりした結果URLが変わると、サーバーを移動したことになり、トランザクション・ログに保持されている情報ではサーバーを特定できなくなる場合があります。

- 新しいサーバーのURLが古いサーバーと同じである場合、トランザクション・リカバリ・サービスは、すべてのトランザクション・ログ・ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。詳細については、「クラッシュ後のトランザクション・リカバリ・サービスのアクション」を参照してください。

- コーディネータ・サーバーがサブコーディネータと同じドメイン内に存在し、サーバーURLが変更する場合、コーディネータは、サブコーディネータの新しいURLに関して管理サーバーに問合せを行います。新しいトランザクションおよびコミットまたはロールバック中のすべてのトランザクションの伝播では、新しいURLを使用します。URLの変更がリカバリ不能になる前に、トランザクションは、保留中のコミット・レコードがコーディネータのトランザクション・ログ・ファイルに格納されている状態でサブコーディネータに分岐します。コーディネータのトランザクション・ログ・ファイルは適宜削除できます。この手順により、AbandonTimeoutSecondsパラメータの値を超えるまで、トランザクション・リカバリ・サービスはこれらのトランザクションを解決できません。詳細は、「トランザクションの破棄」および「トランザクション・レコードの削除方法」を参照してください。

- トランザクションが複数のドメインにまたがり、リモート・トランザクションのサブコーディネータとして機能するサーバーに障害が発生してそのURLが変更になった場合は、コーディネータがリモート・ドメインの管理サーバーと通信できなくなるため、実行中のどのトランザクションも完了しません(コミットまたはロールバックされます)。コーディネータは、新しいURLを使用してサブコーディネータと通信できなくなり、実行中のトランザクションは失敗します。コーディネータは、AbandonTimeoutSecondsの値を超えるまでリクエストのコミットまたはロールバックを試行します。詳細は、「トランザクションの破棄」を参照してください。新しいトランザクションは、コーディネータがサブコーディネータと通信できないため、失敗します。コーディネータおよびサブコーディネータ(移行したサーバー・ドメインを除く)のTLOGは削除してください。「トランザクション・レコードの削除方法」を参照してください。

移植性を向上させるため、サーバー・インスタンスにはIPアドレスではなくDNS名を使用することをお薦めします。

サーバーを新しいマシンに移動する必要がある場合は、「クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。

トランザクションの破棄

指定した時間の経過後に未完了のトランザクションを破棄することもできます。分散トランザクションの2フェーズ・コミット・プロセスでは、トランザクション・マネージャはトランザクションに参加するすべてのリソース・マネージャを調整します。すべてのリソース・マネージャがコミットまたはロールバックを支持すると、トランザクション・マネージャはリソース・マネージャに、変更に対してコミットまたはロールバックのいずれかの動作を行うよう通知します。2フェーズ・コミット・プロセスにおける、この第2フェーズでは、トランザクション・マネージャはすべてのリソース・マネージャでトランザクションの終了が示されるまで、トランザクションを終了しようとし続けます。AbandonTimeoutSeconds属性を使用すると、トランザクション・マネージャがコミット・プロトコルの第2フェーズでトランザクションの終了を試み続ける最長時間を秒単位で設定できます。デフォルト値は86400秒、つまり24時間です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション・マネージャは破棄されるトランザクションにかわってトランザクションをロールバックし、ロックを解放してから、サーバー・ログにヒューリスティック・エラーを書き込みます。

以下の関連情報を参考にできます。

- AbandonTimeoutSeconds属性の設定手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの構成に関する項を参照してください。

トランザクション処理のチューニング

2フェーズ・コミット・プロトコルの最初のフェーズは準備フェーズと呼ばれます。要求される更新がトランザクション・ログ・ファイルに記録され、リソースは、リソース・マネージャを通じて変更の準備ができていることを表明する必要があります。リソースは、更新をコミットするのか、または前の状態にロールバックするのかを意思表示できます。第2フェーズまたはコミット・フェーズで何が行われるかは、リソースの意思表示によって決まります。すべてのリソースがコミットを支持すると、トランザクションに関わっているすべてのリソースが更新されます。1つまたは複数のリソースがロールバックを支持した場合は、トランザクションに関わっているすべてのリソースが前の状態にロールバックされます。WebLogic Serverには、トランザクションの処理にかかる時間を調整する次のパラメータがあります。

- トランザクションの開始から、トランザクションの最初のフェーズの終わりまでの処理にかかる最大時間は、transaction-timeout属性の値を設定して制御します。

- トランザクションの第2フェーズの処理にかかる最大時間は、completion-timeout-seconds属性の値を設定して制御します。

WebLogic Server 10.3.3以前では、第2フェーズの処理の最大所要時間は、デフォルトのtransaction-timeoutの値(最大値120秒、調整不可能)の約2倍でした。ほとんどの環境の場合、第2フェーズの完了に割り当てられる時間は十分なものです。ただし、システムの負荷が高い環境やネットワークの待機時間が長い環境では、コミット・フェーズの完了に使用可能な最大時間を超える可能性があり、トランザクション・マネージャはSystemExceptionをスローします。SystemExceptionは、トランザクションの結果に対して決定的ではないため、アプリケーション環境では、この場合の特別な例外処理を用意する必要があります。この例外処理には、トランザクション・アクティビティやトランザクションに関連するリソースの状態を手動で解析する処理も含まれる場合があります。アプリケーション・スタックは、より複雑になるため、トランザクションの結果の解決はさらに難しくなります。completion-timeout-seconds属性では、コミット・フェーズにより長い処理時間を割り当てることで、多くの場合、成功するか決定的な完了になります。

completion-timeout-secondsの値が、abandon-timeout-secondsに設定された値を超えると、abandon-timeout-secondsは、completion-timeout-secondsの値をオーバーライドします。トランザクションを破棄する場合、SystemExceptionがスローされます。一般に、transaction-completion-seconds属性に大きな値が必要なトランザクションは、システムのチューニングが必要になります。

注意:

abandon-timeout-seconds値が60秒未満に設定されている場合は、デフォルトのcompletion-timeout-seconds設定によって無効にされるので注意してください。また、トランザクション・サービスが起動してから最初の600秒(10分)以内に、abandon-timeout-seconds設定は完全に無効になります。

構成情報の詳細は次のトピックを参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの高度なドメインJTAオプションの構成に関する項

- Oracle WebLogic Server MBeanリファレンスのCompletionTimeoutSecondsに関する項

注意:

completion-timeout-seconds属性は、JCAトランザクションなどのインポート済トランザクションや、リカバリ・トランザクションには適用されません。

現在(処理中)のトランザクションの手動での解決

場合によってはトランザクションが完了しないことがあります。通常は、システムまたはネットワークの障害が原因です。このような状況では、保留中のトランザクションのためにロックが保持され、他のトランザクションの進捗を妨げている可能性があります。「破棄タイムアウト」の期間が経過すると、WebLogic Serverトランザクション・マネージャが内部データ構造からトランザクションを削除し、サーバー・ログにヒューリスティック・エラーを書き込みます。「行き詰まった」トランザクションを手動で解決することもできます。

トランザクションを手動で解決するには、「サーバー」>「監視」>「JTA」タブでサーバーの現在の(処理中)トランザクションを表示し(Oracle WebLogic Server管理コンソール・ヘルプの現在のトランザクションの表示に関する項を参照)、トランザクションIDをクリックして特定のトランザクションの詳細を表示します。その後、トランザクションのステータスに応じてコミットまたはロールバックを強制できます。

注意:

トランザクションのステータスはサーバーごとに異なることがあります。たとえば、調整を行うサーバーではトランザクションがコミットされていても、リモートの参加者がコミットの指示を受け取っていない場合があります。

次の表は、トランザクションのステータスと解決のオプションに関する情報を示します。

表4-1 トランザクション・ステータスの定義と手動解決のオプション

ステータス

定義

強制コミット

強制ロールバック

アクティブ

アプリケーションがトランザクションを処理しています。トランザクションは、まだ2フェーズ・コミット処理には到達していません。

Y

準備中

トランザクション・マネージャが2PCプロトコルの最初のフェーズでjavax.transaction.Synchronization beforeCompletion()コールバック処理を開始してから、すべての参加者がコミット可能と応答するまでの間隔に対応します。

Y

準備完了

すべての参加者がコミット・ポイント(コミット・ログ・レコードがディスクにフラッシュされる)に備えるように反応してから、ロールバック処理開始までの間隔です。

Y

Y

コミット中

コミットの決定が行われてから、すべての参加者に結果が通知されて、javax.transaction.Synchronization afterCompletion()コールバックの処理が完了するまでの期間。

Y

コミット完了

トランザクションがコミットされました。ヒューリスティックが存在する可能性が高いです。あるいは、トランザクションが完了していて、現在のトランザクションのリストに表示されません。

Y

ロールバック中

この状態になるのは、ロールバック処理が開始されてから、すべての参加者がロールバックを指示されて、javax.transaction.Synchronization afterCompletion()コールバックの処理が完了するまでの期間です。

Y

ロールバック済

トランザクションがロールバックされました。ヒューリスティックが存在する可能性が高いです。あるいは、トランザクションが破棄されていて、現在のトランザクションのリストに表示されません。

Y

マーク済ロールバック

トランザクションがロールバックに関してマークされました。おそらく、setRollbackOnly操作の結果です。

Y

トランザクションなし

不明

現在のステータスを判別できません。

Y

Y

手動でのコミットとロールバックのオプション

トランザクションを手動で解決するときは次に示すオプションから選択できます。オプションの制約は、表4-1「トランザクション・ステータスの定義と手動解決のオプション」で説明しています。

- ローカル・コミットの強制: サーバーに登録されている各参加リソースで、特定のトランザクションに対するコミット処理が発行され、トランザクションはローカル・トランザクション・マネージャのデータ構造から削除されます。ローカル・サーバーがトランザクションのコーディネータの場合、コミット・レコードがリリースされます。Oracle WebLogic Server管理コンソール・ヘルプのローカル・コミットの強制に関する項を参照してください。

- グローバル・コミットの強制: 特定のトランザクションに対するローカル・コミット処理が各参加サーバーで試行されます。このオプションが、調整を行うサーバー以外で起動された場合、コーディネータに処理を行うよう通知されます。調整を行うサーバーは、各参加サーバーに非同期リクエストを発行します。Oracle WebLogic Server管理コンソール・ヘルプのグローバル・コミットの強制に関する項を参照してください。

- ローカル・ロールバックの強制: ローカル・サーバーに登録されている各参加リソースで、特定のトランザクションに対するロールバック処理が発行されます。トランザクションはローカル・トランザクション・マネージャのデータ構造から削除されます。Oracle WebLogic Server管理コンソール・ヘルプのローカル・ロールバックの強制に関する項を参照してください。

- グローバル・ロールバックの強制: 特定のトランザクションに対するローカル・ロールバック処理が各参加サーバーで試行されます。このオプションが、調整を行うサーバー以外で起動された場合、コーディネータに処理を行うよう通知されます。調整を行うサーバーは、各参加サーバーに非同期リクエストを発行します。Oracle WebLogic Server管理コンソール・ヘルプのグローバル・ロールバックの強制に関する項を参照してください。

注意:

これらのオプションからどれを選択しても、WebLogic Serverによってサーバー・ログにエントリが書き込まれます。

ローカル・オプションとグローバル・オプションの違いは、ローカル・オプションが、現在のサーバー・リソース(管理コンソールの左側のペインにあるナビゲーション・ツリーで選択したサーバーのリソース)だけに作動するのに対して、グローバル・オプションはすべての参加サーバーで操作を実行しようとすることです。グローバル操作が、ローカル・サーバーによって調整されていないトランザクションに対して起動されると、そのトランザクションのコーディネータが操作を実行するように指示されます。コーディネータと通信できない場合、操作はjavax.transaction.SystemExceptionで失敗します。

このケースでは、調整を行うサーバーではトランザクションがコミットされている(コミット済ステータス)ときに、リモートの参加者がコミットの指示を受け取っていません(準備完了ステータス)。リモート参加者でローカル・コミットを強制すると、このトランザクションを完了できます。このケースでは、トランザクションの状態は準備完了のままであるため、リモート参加者でロールバックを強制することもできます。ただし、トランザクションはヒューリスティックに完了します。グローバル・ロールバックの強制を試行すると、コーディネータの状態がコミット中であるため、操作が失敗します。コミット中のステータスではトランザクションをロールバックできません。

サーバーに障害が発生した後のトランザクションのリカバリ

WebLogic Serverのトランザクション・マネージャは、ユーザーによる最低限の介入でシステムのクラッシュからリカバリするように設計されています。トランザクション・マネージャは、クラッシュが何度も発生した後や、クラッシュのリカバリ中であっても、リソース・マネージャによって準備されたトランザクション・ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。

クラッシュ後のリカバリを容易にするため、WebLogic Serverではトランザクション・リカバリ・サービスを提供しています。このサービスでは、システムの起動時にトランザクションの回復が自動的に行われます。「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、起動時にすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。

トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に処理するよう設計されているため、サーバーがクラッシュした場合は再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。

サーバーがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザーによる処理が必要になることがあります。サーバーの障害発生後にトランザクションをリカバリする手順は、WebLogic Serverの環境によって異なります。クラスタリングされていないサーバーの場合は、手動でサーバー(およびデフォルト永続ストアのDATファイル)を別のシステム(マシン)に移動することでトランザクションをリカバリできます。詳細は、「クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタ内のサーバーについては、同じクラスタ内の別のサーバーに、サーバー全体またはトランザクション・リカバリ・サービスを手動で移行できます。トランザクション・リカバリ・サービスの移行には、トランザクションをリカバリするためのトランザクション・ログにアクセスできるサーバーを選択し、次に管理コンソールまたはWebLogicコマンドライン・インタフェースを使用してサービスを移行することが必要です。

注意:

クラスタリングされていないサーバーの場合は、サーバー全体を新しいシステムに移動することしかできません。クラスタリングされたサーバーの場合は、サーバー全体を移行することも、トランザクション・リカバリ・サービスを一時的に移行することも可能です。

トランザクション・リカバリ・サービスの移行に関する詳細は、「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタの詳細は、『Oracle WebLogic Serverクラスタの使用』を参照してください。

次の項では、障害発生後にトランザクションをリカバリする方法について説明します。

- クラッシュ後のトランザクション・リカバリ・サービスのアクション

- クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ

- クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ

- トランザクション・レコードの削除方法

クラッシュ後のトランザクション・リカバリ・サービスのアクション

クラッシュ後にサーバーを再起動したり、トランザクション・リカバリ・サービスを別の(バックアップ)サーバーに移行したりすると、トランザクション・リカバリ・サービスは以下の処理を行います。

- 2フェーズ・コミットの第2フェーズの準備が整っているトランザクションを終了します。
コミットの決定が行われたが2フェーズ・コミット・プロセスの第2フェーズが終了していないトランザクション(トランザクション・ログに記録されているトランザクション)については、トランザクション・リカバリ・サービスがコミット・プロセスを終了させます。

- 準備されたトランザクションを解決します。
トランザクション・マネージャによってリソース・マネージャとの準備が整っているトランザクション(2フェーズ・コミット・プロセスの第1フェーズのトランザクション)の場合、トランザクション・リカバリ・サービスはクラッシュ・リカバリ中に、各リソース・マネージャに対してXAResource.recover()を呼び出す必要があります。次に、commit()、rollback()、またはforget()メソッドを呼び出すことで、recover()によって返されたすべてのトランザクションIDを最終的に解決します。

- ヒューリスティックな終了を報告します。
リソース・マネージャによってヒューリスティックな例外が報告されると、トランザクション・リカバリ・サービスはそのヒューリスティックな例外をサーバー・ログに記録し、「ヒューリスティックを無視」構成属性が有効になっている場合は、forget()を呼び出します。「ヒューリスティックを無視」構成属性が有効になっていない場合は、データベース・ベンダーのドキュメントでヒューリスティックな終了の解決に関する情報を参照してください。詳細については、「ヒューリスティックな終了の処理」を参照してください。

トランザクション・リカバリ・サービスには、次のような利点があります。

- 複数のリソースにわたって一貫性を維持します。
トランザクション・リカバリ・サービスは、一貫した予測しやすい方法でトランザクション・リカバリ処理を行います。クラッシュ前にコミットが決定されたがまだ行われておらず、XAResource.recover()からトランザクションIDが返されるトランザクションの場合、トランザクション・リカバリ・サービスは一貫してXAResource.commit()を呼び出します。クラッシュ前にコミットが決定しておらず、XAResource.recover()からトランザクションIDが返されるトランザクションの場合、トランザクション・リカバリ・サービスは一貫してXAResource.rollback()を呼び出します。トランザクションのリカバリが一貫性のある予測しやすいものであるため、トランザクション・マネージャがクラッシュしても、一部のブランチがコミットされ一部がロールバックされるという混合ヒューリスティックの終了は発生しません。

- トランザクションの解決に固執します。
リソース・マネージャがクラッシュすると、トランザクション・リカバリ・サービスでは準備されている各トランザクションについてcommit()またはrollback()を呼び出さなければなりません。commit()またはrollback()の呼出しは成功するまで続けられます。トランザクション解決の試行は、AbandonTimeoutSeconds構成属性を設定することで制限できます。詳細は、「トランザクションの破棄」を参照してください。

WebLogicプロキシ・プラグインを備えたApacheを使用する際のクラスタリング・フェイルオーバー

WebLogicプロキシ・プラグインを備えたApacheをクラスタのフロントエンドとして使用する際、プラグインは複数の構成パラメータを使用して、WebLogic Serverホストへの接続を待機する時間や、接続の確立後は、プラグインがレスポンスを待機する時間を判断します。

- Apacheのidempotentフラグの設定を検証します。idempotentがONに設定されているときに、指定したWLIOTimeoutSecs値内でサーバーが応答しない場合は、プラグインがフェイルオーバーします。idempotentがONに設定され、サーバーがREAD_ERROR_FROM_SERVERなどのエラーで応答する場合にもプラグインはフェイルオーバーします。OFFに設定されている場合、プラグインはフェイルオーバーしません。詳細は、『Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のWebサーバー・プラグインのパラメータに関する項を参照してください。

- WebLogicプロキシ・プラグインの再試行メカニズムの設定を確認します; たとえば、許可される再試行の最大回数が、ConnectTimeoutSecs値をConnectRetrySecs値で除算した値と等しいかどうかなどを確認します。詳細は、『Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のフェイルオーバー、Cookie、およびHTTPセッションに関する項を参照してください。

クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ

障害が発生したサーバーでトランザクションをリカバリするには、次の手順に従います。

1. すべてのトランザクション・ログ・レコードが含まれる永続ストアDATファイルを、障害が発生したサーバーから新しいサーバーへ移動します(新しいサーバーで利用できるようにします)。

2. デフォルト永続ストアへのパスを、データ・ファイルへのパスと共に設定します。「デフォルト永続ストアへのパスの設定」を参照してください。

3. 新しいサーバーを起動します。「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、すべてのトランザクション・ログ・ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。

サーバーに障害が発生した後でトランザクション・ログ・レコードを移動する場合は、すべてのトランザクション・ログ・レコードを新しいマシンで使用可能にしてから、そのマシンでサーバーを起動します。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション・データに矛盾が発生する場合があります。このような移行は、両方のマシンで使用可能なデュアル・ポート・ディスクに永続ストアのデータ・ファイルを格納することで実現できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、デフォルトのファイル・ストアのdirectory属性を新しいパス名で更新してからサーバーを起動します。

注意:

トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバーがクラッシュした場合は、新しいマシンにサーバーを移動するよりも、サーバーを再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。

クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ

クラスタリングされたサーバーで障害が発生した場合、以下のいずれかの方法でトランザクションをリカバリできます。

- サーバーの移行

- トランザクション・リカバリ・サービスの手動移行

サーバーの移行

クラスタリングされたサーバーの場合、WebLogic Serverでは、トランザクション・リカバリ・サービスを含めて、障害が発生したサーバーを新しいマシンに移行できます。サーバーを別のマシンに移行する場合、トランザクションを完了またはリカバリするには、サーバーがトランザクション・ログ・レコードを見つけられるようにする必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。障害が発生したときに、クラスタリングされたサーバーを移行する計画がある場合は、障害が発生した移行可能なサーバーの移行先となり得る任意のマシンにアクセスできる、共有ストレージ・システムにレコードを格納するよう、デフォルト永続ストアを設定する必要があります。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。

サーバーの移行に関する詳細は、『Oracle WebLogic Serverクラスタの使用』のサーバー全体の移行に関する項を参照してください。

デフォルト永続ストア・オプションの設定の詳細は、以下を参照してください。

- デフォルト永続ストアへのパスの設定

- デフォルト永続ストアの同期書込みポリシーの設定

トランザクション・リカバリ・サービスの手動移行

クラスタリングされたサーバーがクラッシュした場合は、管理コンソールまたはコマンドライン・インタフェースを使用して、同じクラスタ内でクラッシュしたサーバーから別のサーバーへ、トランザクション・リカバリ・サービスを手動で移行できます。管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。

シングルトン・サービスのWebLogic Serverヘルス監視を使用して、トランザクション・リカバリ・サービスが正常な候補サーバーに自動的に移行されるように構成することも可能です。「トランザクション・リカバリ・サービスの自動移行」を参照してください。

トランザクション・リカバリ・サービスの移行の仕組み

手動または自動のサービス移行が実施されると、以下のイベントが発生します。

1. トランザクション・ログの所有権がクラッシュしたサーバーからバックアップ・サーバーのトランザクション・リカバリ・サービスに移ります。

2. 「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、障害が発生したサーバーからのすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。

3. バックアップ・サーバーのトランザクション・リカバリ・サービスにより、障害が発生したサーバーで未完了のトランザクションがすべて正常に終了すると、サーバーでは障害が発生したサーバーのトランザクション・リカバリ・サービスに対する所有権が解放され、障害が発生したサーバーが再起動時にその所有権を再び要求できるようになります。

サーバーでは、障害が発生した複数のサーバーに対してトランザクション・リカバリを行うことができます。他のサーバーのトランザクションを回復している間に、バックアップ・サーバーは自身のトランザクションの処理および回復を続けます。リカバリ中にバックアップ・サーバーで障害が発生した場合は、さらに別のサーバーにトランザクション・リカバリ・サービスを移行できます。この別のサーバーで、トランザクション・リカバリは続行されます。また、管理コンソールまたはコマンドライン・インタフェースを使用して、トランザクション・リカバリ・サービスを元の障害が発生したサーバーに手動で移行して戻すこともできます。詳細は、「トランザクション・リカバリ・サービスの元のサーバーへの手動による移行」を参照してください。

サーバーのトランザクション・リカバリがバックアップ・サーバーで完了すると、バックアップ・サーバーではトランザクション・リカバリ・サービスの所有権が、障害が発生したサーバーに解放されます。障害が発生したサーバーを再起動すると、このサーバーはトランザクション・リカバリ・サービスの所有権を再び要求しようとします。障害が発生したサーバーを再起動したときに、バックアップ・サーバーがトランザクション・リカバリ処理中だった場合、バックアップ・サーバーはトランザクションのリカバリを中止し、内部クリーンアップを行い、トランザクション・リカバリ・サービスの所有権を解放して、障害が発生したサーバーがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバーでは、自身のトランザクション・リカバリを完了します。

障害が発生したサーバーのトランザクション・リカバリ・サービスがまだバックアップ・サーバーで所有されており、障害が発生したサーバーを再起動しようとしたときにバックアップ・サーバーが非アクティブだった場合、バックアップ・サーバーがトランザクション・リカバリ・サービスの所有権を解放できないため、障害が発生したサーバーは起動しません。これは、フェイルバック・メカニズムが失敗した場合や、バックアップ・サーバーが管理サーバーと通信できない場合にも当てはまります。トランザクション・リカバリの移行は、管理コンソールまたはコマンドライン・インタフェースを使用して手動で行えます。

トランザクション・リカバリ・サービスの自動移行

サーバー・ヘルス監視サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバーのトランザクション処理をバックアップ・サーバーで完了できます。『Oracle WebLogic Serverクラスタの使用』のJTAトランザクション・リカバリ・サービスの自動移行を構成するロードマップに関する項を参照してください。

管理対象サーバーの独立性

WebLogic Server 10.0より前のリリースでは、クラスタのプライマリ管理対象サーバーの起動時に管理サーバーにアクセスできない場合(ほとんどの場合は管理サーバーがまだ起動していないことが原因)、プライマリ管理対象サーバーは自動的に管理対象サーバー独立(MSI)モードに移行し、ローカルの構成情報を使用して起動を続行していました。この状況では、トランザクション・リカバリ・サービスを手動で移行している間、プライマリ管理対象サーバーのかわりにバックアップ・サーバーでまだTLOGデータをリカバリ中である可能性があり、これらのサーバーがTLOGに同時にアクセスしてTLOGが破損するリスクがありました。

このTLOG破損のリスクを回避するためのプロパティが、JTAMigratableTargetMBeanのstrictOwnershipCheckです。このプロパティを使用することで、プライマリ管理対象サーバーの起動中に管理サーバー(JTA手動移行ポリシーの場合)またはシングルトン・マスター(JTA自動移行ポリシーの場合)に接続できないことが判明すると、次に示すようにstrictOwnershipCheckの値に従って管理対象サーバーの独立性が検証されるようになりました。

- True - これが推奨設定です。プライマリ管理対象サーバーは、例外をスローして起動に失敗します。

- False - プライマリ管理対象サーバーは、トランザクション・リカバリ・サービスのフェイルバックをスキップして正常に起動します。この場合は、WebLogic Server 9.2以前と同じようにTLOGが破損するリスクがあります。

トランザクション・リカバリ・サービスの移行に対する制限

トランザクション・リカバリ・サービスを自動または手動で移行する場合は、以下の制限があります。

- トランザクション・リカバリ・サービスを、実行中のサーバーからバックアップ・サーバーへ移行することはできません。トランザクション・リカバリ・サービスを移行する前に、サーバーを停止する必要があります。

- バックアップ・サーバーでは、障害が発生したサーバーに対する新しいトランザクション処理は受け付けません。終了していないトランザクションを処理するだけです。

- バックアップ・サーバーでは、ヒューリスティック・ログ・ファイルは処理しません。

- バックアップ・サーバーは、WebLogic Serverによって書き込まれたログ・レコードのみを処理します。WebLogic Tuxedoコネクタなどのゲートウェイ実装によって書き込まれたログ・レコードの処理は行いません。

以上の制限に加え、WebLogic Server 10.0以降でトランザクション・リカバリ・サービスが自動的に移行されるように構成する場合は以下のルールも適用されます。

- 以前のWebLogic Serverリリースのサーバーがクラスタに含まれている場合でも、プライマリ・サーバーとバックアップ・サーバーはWebLogic Server 10.0以降にする必要があります。自動移行が有効になっている場合にこのルールが強制的に適用されるようにするため、管理コンソールの候補サーバーの「使用可能」リストにはWebLogic Server 10.0以降のサーバーのみが表示されるようになっています。

- リリース9.2以前のサーバーとリリース10.0以降のサーバーの間の手動サービス移行は、移行スクリプトを使用していない場合にのみサポートされます。

トランザクション・リカバリ・サービスの移行準備

クラスタ内の障害が発生したサーバーから同じクラスタ内の別のサーバー(バックアップ・サーバー)にトランザクション・リカバリ・サービスを移行するには、障害が発生したサーバーのトランザクション・ログ・レコードにバックアップ・サーバーがアクセスできる必要があります。したがって、クラスタ内のすべての潜在的なバックアップ・サーバーにとって使用可能な永続ストレージ上に、デフォルト永続ストア・データ・ファイルを格納する必要があります。次の点を考慮してください。

- ストレージ・エリア・ネットワーク(SAN)が推奨されます。

- NFSファイル・システムを使用する場合、ディスク書込みがキャッシュされないようにNFSサーバーを構成します。

- ストレージ・ソリューションにかかわらず、フェイルオーバーと移行をテストします。
一部のストレージ・ソリューション、特に一部のバージョンのNFSでは、ファイルのロックが問題になる可能性があります。ファイル・ロックを効率的に処理するようにストレージ・サーバーを構成するか、WebLogicファイル・ストアのファイル・ロックを停止する必要があります。

重要:

NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーがDisabled以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。Disabledの同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。『Oracle WebLogic Serverパフォーマンスおよびチューニング』のファイル・ロックとNFSに関する項を参照してください。

トランザクション・リカバリ・サービスを自動または手動で移行する際は、永続ストアに関する以下のルールが適用されます。

- デフォルト永続ストアを、JTAを始めとする移行可能サービスの間で共有することはできません。移行可能ターゲットにターゲット指定されている他の移行可能サービス(たとえばJMSサービス)では、別途カスタム・ストアを使用する必要があります。

- デフォルト・ストアのマウントやアンマウントを実行する移行前/移行後スクリプトを指定する場合は、候補マシンごとにノード・マネージャを構成して実行する必要があります。

プライマリ・サーバーが起動、フェイルオーバー、またはフェイルバックする際には、管理サーバーがアクセス可能な状態になっている必要があります。これは、トランザクション・リカバリ・サービスが、そのTLOGの排他的な所有権を競合なく適切に取得できるようにするためです。プライマリ・サーバーの起動時には、トランザクション・リカバリ・サービスが管理サーバーに接続し、JTAに関する最新の情報を取得します。フェイルオーバーやフェイルバックが発生した場合は、トランザクション・リカバリ・サービスがその最新情報を管理サーバーに保存します。

トランザクション・リカバリ・サービスをサーバーから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバーを停止する必要があります。元のサーバーがまだ実行中の場合は、そこからトランザクション・リカバリ・サービスを移行することはできません。

移行に参加するサーバーはすべて、構成においてリスニング・アドレスが指定されている必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・アドレスの構成に関する項を参照してください。

トランザクション・リカバリ・サービスの移行先になるサーバーの制限

クラスタ内のサーバーに対してトランザクション・リカバリ・サービスのバックアップ・サーバーとして使用するサーバーの選択肢を制限することもできます。たとえば、クラスタ内のすべてのサーバーがサーバーのトランザクション・ログ・レコードにアクセスできるとは限りません。管理コンソールの「サーバー: 構成: 移行」ページでは、使用可能な宛先サーバーを制限できます。手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの移行先とする候補サーバーの構成に関する項を参照してください。

注意:

必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻せるように、「選択済み」リストに移行元のサーバーを含めておく必要があります。管理コンソールでは、この規則に従わなくてはなりません。

トランザクション・リカバリ・サービスの現在のオーナーの表示

トランザクション・リカバリ・サービスをクラスタ内の別のサーバーに移行した場合、そのトランザクション・リカバリ・サービスの所有権は、未完了のトランザクションがすべて完了するまでバックアップ・サーバーに割り当てられます。トランザクションの完了後、バックアップ・サーバーはトランザクション・リカバリ・サービスの所有権を解放し、元のサーバーは所有権の返還を要求できます。現在のオーナーは、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 制御: 移行」ページで確認できます。次の手順に従います。

1. 管理コンソールの「ドメイン構造」ツリーで、「環境」を展開して「サーバー」をクリックします。

2. トランザクション・リカバリ・サービスの移行元のサーバーを選択し、さらに「制御」>「移行」タブを選択します。

3. 「詳細設定」をクリックします。「JTA移行」オプションの下の「ホスト・サーバー」に、トランザクション・リカバリ・サービスの現在のオーナーが表示されます。

トランザクション・リカバリ・サービスの元のサーバーへの手動による移行

バックアップ・サーバーは、障害が発生したサーバーのトランザクションのリカバリが完了すると、トランザクション・リカバリ・サービスの所有権を解放します。そのため、元のサーバーは再起動時にその所有権の返還を要求できます。トランザクションのリカバリが完了する前になんらかの理由でバックアップ・サーバーが停止(クラッシュ)すると、元のサーバーはトランザクション・リカバリ・サービスの所有権の返還を要求できなくなり、起動しません。

また、移行先サーバーとして元のサーバーを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻すことができます。元のサーバーにトランザクション・リカバリ・サービスを手動で移行して返還するときには、バックアップ・サーバーが稼動していてはいけません。次の手順に従います。

注意:

以下の点に注意してください。

- トランザクション・リカバリ・アクションの完了前にバックアップ・サーバーで障害が発生した場合、プライマリ・サーバーは、トランザクション・リカバリ・サービスの所有権を要求できず、サーバーの再起動後にリカバリは再試行されません。そのため、トランザクション・リカバリ・サービスを別のバックアップ・サーバーに手動で再移行する必要があります。

- バックアップ・サーバーによるトランザクションのリカバリ中に元のサーバーを再起動した場合は、バックアップ・サーバーが正常にトランザクション・リカバリ・サービスの所有権を解放します。バックアップ・サーバーを停止する必要はありません。「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。

管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。

トランザクション・レコードの削除方法

TLOGを削除する前に、できるだけ多くのトランザクションを完了できるようにWebLogic Serverインスタンスを正常に停止する必要があります。

注意:

TLOGを削除する必要があるのは極端な場合のみです。TLOGを削除すると、トランザクション・レコードが削除されるため、ヒューリスティック障害が発生します。たとえば、「サーバーの移行」を参照してください。

TLOGの場所は、デフォルトのストアとJDBC TLOGストアのどちらを使用しているか、またLLRがトランザクションの参加リソースであるかどうかによって異なります。

- トランザクションに関連する1つのリソースがLLRの場合、TLOGは2箇所に格納されます。

- トランザクション・レコードは、データベース表に格納されます。「LLRデータベースでのTLOGの削除方法」を参照してください。

- サーバーとリソースのチェックポイントは、デフォルトのストアまたはJDBC TLOGに格納されます。「デフォルト・ストアからのTLOGファイルの削除方法」および「JDBC TLOGストアからのTLOGの削除方法」を参照してください。

- トランザクションに参加LLRがない場合、トランザクション・レコード、サーバー・チェックポイント、リソース・チェックポイントはすべて、デフォルト・ストアまたはJDBC TLOGストアのTLOGファイルに保存されます。「デフォルト・ストアからのTLOGファイルの削除方法」および「JDBC TLOGストアからのTLOGの削除方法」を参照してください。

LLRデータベースでのTLOGの削除方法

LLR表のデフォルト名はWL_LLR_SERVERNAMEで、SERVERNAMEは、サーバー・インスタンスの名前です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: 全般」の「JDBC LLR表名」を参照してください。データベースに保持されているLLR TLOGを削除するには、drop table WL_LLR_SERVERNAMEを発行して、表からすべてのレコードを削除します。

デフォルト・ストアからのTLOGファイルの削除方法

デフォルト・ストアのTLOGを削除するには、次のパターンのファイルをすべて削除します。

$DOMAIN_HOME/servers/servername/data/store/default/_WLS_SERVERNAMExxxxxx.DAT

ここで、xxxxxxは、0から9の整数です。

注意:

構成済のJMSファイル・ストアがデフォルト・ストアに含まれる場合、TLOGを削除すると、JMSファイル・ストアも削除されます。この場合、TLOGファイルを削除する前に、JMSメッセージを別の場所にエクスポートします。その後、TLOGファイルを安全に削除して、JMSメッセージを元のストアにインポートすることができます。『Oracle WebLogic Server JMSの構成と管理』のJMSメッセージの管理に関する項を参照してください。

JDBC TLOGストアからのTLOGの削除方法

JDBC TLOGストアの名前は、JDBC TLOGストアをホストするサーバー名の前に接頭辞名、最後に「_」を付けたものです。たとえば、デフォルトの接頭辞名を使用した有効なJDBC TLOGストア名はTLOG_MyServer_です。この場合、TLOG_が接頭辞名、MyServerがJDBC TLOGストアをホストするサーバーの名前です。データベース管理者が既存のTLOG情報をJDBC TLOGストアから削除できます。

5 トランザクション・サービス

この章では、WebLogic Serverサーバーで使用するトランザクション・アプリケーションを作成するために使用される情報を説明します。トピックには、トランザクション・サービスの機能や制限、EJBでの使用方法およびObject Transaction Service (OTS)が含まれます。

この章では、以下のトピックについて説明します。

- トランザクション・サービスについて

- 機能と制限

- トランザクションのスコープ

- EJBアプリケーションでのトランザクション・サービス

- RMIアプリケーションでのトランザクション・サービス

- OTSとの相互運用をサポートするトランザクション・サービス

トランザクション・サービスについて

WebLogic Serverは、EJBアプリケーションとRMIアプリケーションのトランザクションをサポートする「トランザクション・サービス」を提供します。WebLogic Server EJBコンテナでは、このトランザクション・サービスにより、Enterprise JavaBeans仕様3.0 (http://www.oracle.com/technetwork/java/javaee/ejb/index.html)に記載されているトランザクション・サービスの実装が提供されます。

EJBとRMIのアプリケーションに対して、Javaアプリケーション用にJava Transaction API (JTA)を実装するjavax.transactionパッケージおよびjavax.transaction.xaパッケージもWebLogic Serverで提供されます。JTAの詳細は、Java Transaction API (JTA)仕様1.1 (http://www.oracle.com/technetwork/java/javaee/jta/index.html)を参照してください。アプリケーションにおいてトランザクション境界の設定に使用されるUserTransactionオブジェクトの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.UserTransactionを参照してください。

機能と制限

この節の内容は以下のとおりです。

- 軽量クライアントと委託コミット

- クライアントが開始するトランザクション

- トランザクションの整合性

- トランザクションの終了

- フラット・トランザクション

- トランザクション・サービスのトランザクション処理との関係

- マルチスレッド・トランザクション・クライアントのサポート

- 一般的な制約

以降の節では、EJBとRMIのアプリケーションをサポートするトランザクション・サービスの機能と制限について説明します。

軽量クライアントと委託コミット

軽量クライアントは、可用性が一定ではなく、管理のされていない、1ユーザー対象のデスクトップ・システムで動作します。デスクトップ・システムは、使用されないときは所有者によって電源が落とされます。そのような管理されていない、1ユーザー対象のデスクトップ・システムでは、トランザクションの調整などのネットワーク機能を行うべきではありません。特に、管理されていないシステムには、サーバー・リソースが関わるトランザクションにおいて、障害の影響を受けずに原子性、一貫性、隔離性、および持続性というACIDプロパティを維持するという役目を負わせるべきではありません。WebLogic Serverのリモート・クライアントは軽量クライアントです。

トランザクション・サービスを利用すると、軽量クライアントでは委託コミットを実行できます。つまり、軽量クライアントでは、トランザクションの調整をサーバー・マシン上のトランザクション・マネージャにまかせてトランザクションを開始および終了することができるのです。クライアント・アプリケーションは、ローカルのトランザクション・サーバーを必要としませんクライアント・アプリケーションは、ローカル・トランザクション・サーバーを必要としません。EJBクライアントまたはRMIクライアントで使用されるUserTransactionのリモート実装によって、トランザクション調整の実際の作業がサーバー上のトランザクション・マネージャに委託されます。

クライアントが開始するトランザクション

アプレットなどのクライアントでは、JNDIを使用してUserTransactionオブジェクトおよびTransactionManagerオブジェクトの参照を取得できます。クライアントでは、いずれかのオブジェクト参照を使用してトランザクションを開始できます。現在のスレッドのTransactionオブジェクトを取得するには、クライアント・プログラムは((TransactionManager)tm).getTransaction()メソッドを呼び出さなければなりません。

トランザクションの整合性

チェック済トランザクション動作は、そのトランザクションに関わるすべてのトランザクション・オブジェクトでトランザクション・リクエストの処理が完了しないかぎりcommitが成功しないことを保証することで、トランザクションの整合性を提供します。トランザクション・サービスは、The Open Groupが定義しているリクエスト/レスポンスのプロセス間通信モデルにより実現されるものと同等の、チェック済トランザクション動作を提供します。

トランザクションの終了

WebLogic Serverでは、トランザクションはそのトランザクションを生成したクライアントによってのみ終了されることが許されます。

注意:

クライアントは、別のオブジェクトのサービスをリクエストしたサーバー・オブジェクトの場合もあります。

フラット・トランザクション

WebLogic Serverでは、フラット・トランザクション・モデルが実装されています。ネスト・トランザクションはサポートされていません。

トランザクション・サービスのトランザクション処理との関係

トランザクション・サービスは、様々なトランザクション処理のサーバー、インタフェース、プロトコル、および規格と以下のように関連しています。

- Open Group XAインタフェースのサポート。Open Group Resource Managerは2フェーズ・コミット・プロトコルをOpen Group XAインタフェースを通じて管理できるようにすることで分散トランザクションに関与できるリソース・マネージャです。WebLogic ServerではOpen Group Resource Managerとの対話がサポートされています。

- OSI TPプロトコルのサポート。Open Systems Interconnect Transaction Processing (OSI TP)は国際標準化機構(ISO)によって定義されたトランザクション対応プロトコルです。WebLogic ServerではOSI TPトランザクションとの対話はサポートされていません。

- LU 6.2プロトコルのサポート。Systems Network Architecture (SNA) LU 6.2はIBMによって定義されたトランザクション対応のプロトコルです。WebLogic ServerではLU 6.2トランザクションとの対話はサポートされていません。

- ODMG規格のサポート。ODMG-93はObject Database Management Group (ODMG)によって定義された規格であり、Object Database Management Systemにアクセスするための移植可能なインタフェースを規定しています。WebLogic Serverでは、ODMGトランザクションとの対話はサポートされていません。

マルチスレッド・トランザクション・クライアントのサポート

WebLogic Serverでは、マルチスレッド・トランザクション・クライアントがサポートされています。クライアントでは、複数のスレッドで同時にトランザクション・リクエストを行うことができます。

トランザクションID

トランザクション・サービスでは、各トランザクションにトランザクション識別子(Xid)が割り当てられます。このIDは、ログ・ファイル内で特定トランザクションの情報を他と区別するために使用できます。トランザクション識別子は、weblogic.transaction.TransactionインタフェースのgetXIDメソッドを使用して取り出すことができます。トランザクション識別子を取得するメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.Transactionを参照してください。

トランザクションの名前とプロパティ

WebLogic JTAでは、トランザクションの命名とユーザー定義プロパティをサポートするjavax.transaction.Transactionの拡張機能が提供されます。これらの拡張機能は、weblogic.transaction.Transactionインタフェースに含まれています。

トランザクション名は、トランザクションの種類(送金やチケット購入など)を示します。したがって、サーバー上の一意のトランザクションを識別するトランザクションIDとは混同しないでください。トランザクション名を利用すると、例外やログ・ファイルでトランザクションの種類を簡単に識別できます。

ユーザー定義のプロパティはキーと値の組み合わせです。この場合のキーはプロパティを識別する文字列であり、値はプロパティに割り当てられた現在の値です。トランザクション・プロパティの値は、Serializableインタフェースを実装するオブジェクトでなければなりません。アプリケーションでは、weblogic.transaction.Transactionインタフェースで定義されているsetメソッドとgetメソッドを使用してプロパティを管理します。一度設定されたプロパティは、存続期間が終わるまでトランザクションとともに存在し、トランザクションがシステムを移動するときにはマシン間で受け渡しされます。プロパティはトランザクション・ログに保存され、クラッシュのリカバリ処理で復元されます。トランザクション・プロパティが複数回にわたって設定された場合は、最後に設定された値が保持されます。

トランザクション名とトランザクション・プロパティを設定および取得するメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.Transactionを参照してください。

トランザクション・ステータス

Java Transaction APIでは、javax.transaction.Statusクラスを使用してトランザクションのステータス・コードが提供されます。weblogic.transaction.TransactionのgetStatusAsStringメソッドを使用すると、トランザクションのステータスを文字列として返すことができます。文字列には、javax.transaction.Statusで指定されているメジャー状態と、追加のマイナー状態(loggingやpre-preparingなど)が含まれます。

トランザクションの統計

トランザクションの統計は、サーバー上のトランザクション・マネージャで処理されるすべてのトランザクションについて提供されます。それらの統計には、トランザクションの総数、特定の結果(コミット、ロールバック、ヒューリスティックな終了など)を持つトランザクションの数、ロールバックされたトランザクションの理由別の数、およびトランザクションがアクティブな状態を維持した合計時間が含まれます。トランザクションの統計の詳細は、「トランザクションのモニタリング」を参照してください。

一般的な制約

トランザクション・サービスには以下の制約があります。

- WebLogic Serverでは、クライアントまたはサーバー・オブジェクトは別のトランザクションに参加しているオブジェクトのメソッドを呼び出すことができません。クライアントまたはサーバーによってそのようなメソッド呼出しが発行された場合は例外が返されます。

- WebLogic Serverでは、Java Transaction API (Javaアプリケーション用)のサード・パーティ実装を使用するクライアントはサポートされていません。

- トランザクション・ログ・バッファは250KBに制限されています。この値を超えるトランザクション・ログ書込みを必要とする大規模なトランザクションがアプリケーションにある場合、WebLogic Serverは例外をスローします。このような場合、バッファ・サイズの制限に対処するようにアプリケーションを再構成する必要があります。

トランザクションのスコープ

トランザクションのスコープは、そのトランザクションが実行される環境を表します。WebLogic Serverでは、スタンドアロン・サーバーでのトランザクション、クラスタリングされていないサーバー間でのトランザクション、ドメイン内のクラスタリングされたサーバー間でのトランザクション、およびドメイン間のトランザクションがサポートされています。ドメイン間トランザクションのサポートを有効化するには、「ドメイン間およびドメイン内トランザクションのセキュアな通信の構成」を参照してください。

EJBアプリケーションでのトランザクション・サービス

WebLogic Server EJBコンテナでは、WebLogic Server EJBアプリケーションでの以下の2種類のトランザクションをサポートするトランザクション・サービスが提供されます。

- コンテナ管理のトランザクション。コンテナ管理のトランザクションでは、WebLogic Server EJBコンテナによってトランザクションの境界設定が管理されます。EJBデプロイメント記述子のトランザクション属性では、各メソッド呼出しでWebLogic Server EJBコンテナがどのようにトランザクションを処理するのかが指定されます。

- Bean管理のトランザクション。Bean管理のトランザクションでは、EJBによってトランザクションの境界設定が管理されます。EJBは、UserTransactionオブジェクトに対する明示的なメソッド呼出しを行って、トランザクションの開始、コミット、およびロールバックを行います。UserTransactionメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.UserTransactionを参照してください。

EJBアプリケーションにおけるトランザクション管理の概要については、「WebLogic Server EJBアプリケーションのトランザクション」および「トランザクションのサンプルEJBコード」を参照してください。

RMIアプリケーションでのトランザクション・サービス

WebLogic Serverは、WebLogic Server RMIアプリケーションのトランザクションをサポートするトランザクション・サービスを備えています。RMIアプリケーションでは、クライアント・アプリケーションまたはサーバー・アプリケーションがUserTransactionオブジェクトに対する明示的なメソッド呼出しを行って、トランザクションの開始、コミット、およびロールバックが行われます。

UserTransactionのメソッドの詳細は、オンラインのJavadocを参照してください。RMIアプリケーションにおけるトランザクション管理の概要については、「WebLogic Server RMIアプリケーションのトランザクション」および「トランザクションのサンプルRMIコード」を参照してください。

OTSとの相互運用をサポートするトランザクション・サービス

WebLogic Serverは、OTS (Object Transaction Service)との相互運用をサポートするトランザクション・サービスを備えています。Java Transaction Service (JTS)仕様(http://www.oracle.com/technetwork/java/javaee/jts-spec095-1508547.pdf)を参照してください。このリリースのWebLogic Serverでは、以下の状況においてOTSとの相互運用が行われます。

- サーバー間の2PC

- クライアントによって境界設定されたトランザクション

サーバー間の2PC

この状況では、サーバー間の2フェーズ・コミット(2PC)トランザクションを介在によって完了します。発信側サーバーは、Xidを作成し、ターゲット・サーバーにトランザクションを伝播します。ターゲット・サーバーは、自身をリソースとして発信側サーバーに登録します。発信側サーバーが、トランザクションを完了させます。第7章「ロギング・ラスト・リソース・トランザクションの最適化」で説明されているように、ロギング・ラスト・リソース(LLR)トランザクションはサポートされていません。

クライアントによって境界設定されたトランザクション

クライアントが、OTSクライアントAPIを使用してサーバー上でトランザクションを開始します。次に、このトランザクションからXidを取得し、トランザクションがコミットされるまで、このXidをリクエストごとに伝播します。トランザクションを開始するのはクライアントですが、コミット処理はすべてサーバー上で実行されます。

6 Java Transaction APIとOracle WebLogicの拡張機能

この章では、Java Transaction API (JTA)とOracleが提供するJTAの拡張機能について概説します。

- JTA APIの概要

- JTAに対するOracle WebLogicの拡張機能

JTA APIの概要

WebLogic Serverでは、JavaアプリケーションのJava Transaction API (JTA)を実装するjavax.transactionパッケージとjavax.transaction.xaパッケージがサポートされています。JTAの詳細は、Java Transaction API (JTA)仕様(http://www.oracle.com/technetwork/java/javaee/jta/index.html)を参照してください。javax.transactionインタフェースおよびjavax.transaction.xaインタフェースの詳細は、JTAのJavadocを参照してください。

JTAの構成要素は以下のとおりです。

- アプリケーションからトランザクション境界を設定したり、トランザクションを管理したりするためのインタフェースであるjavax.transaction.UserTransaction。このインタフェースは、Javaクライアント・プログラムの一部として、またはEJB内でBean管理のトランザクションの一部として使用します。

- トランザクション・マネージャがアプリケーションのトランザクションの境界を設定したり、トランザクションを管理したりするためのインタフェースであるjavax.transaction.TransactionManager。このインタフェースはコンテナ管理のトランザクションの一部としてEJBコンテナによって使用されます。このインタフェースでは、javax.transaction.Transactionインタフェースを使用して特定のトランザクションで処理が実行されます。

- トランザクション・マネージャがアプリケーション・サーバーにステータスおよび同期の情報を提供するためのインタフェースであるjavax.transaction.Statusとjavax.transaction.Synchronization。これらのインタフェースは、トランザクション・マネージャによってのみアクセスされ、アプリケーション・プログラムの一部として使用することはできません。

- トランザクション・マネージャがXA準拠リソースのリソース・マネージャと連係するためのインタフェースであるjavax.transaction.xa.XAResource、およびトランザクション・マネージャがトランザクションの識別子を取り出すためのインタフェースであるjavax.transaction.xa.Xid。これらのインタフェースは、トランザクション・マネージャによってのみアクセスされ、アプリケーション・プログラムの一部として使用することはできません。

JTAに対するOracle WebLogicの拡張機能

Java Transactions APIの拡張機能は、JTAの仕様で実装の細かな部分がカバーされていないところや補足的な機能が必要なところで提供されます。

Oracle WebLogicでは、JTA仕様の解釈に基づいて以下の機能が提供されます。

- クライアントが開始するトランザクション - JTAトランザクション・マネージャ・インタフェース(javax.transaction.TransactionManager)がJNDIを通じてクライアントやBeanプロバイダから利用可能になります。この機能により、クライアントや、Bean管理のトランザクションを利用するEJBでトランザクションをサスペンドしたり再開したりすることができます。

注意:

サスペンドされたトランザクションは、それがサスペンドされた同じサーバー・プロセスで再開する必要があります。

- トランザクションのスコープ - トランザクションはクラスタとドメインの内部、およびクラスタとドメイン間で機能します。

- 拡張されたjavax.transaction.TransactionSynchronizationRegistryのサポート - WebLogic Serverでは、java:comp/TransactionSynchronizationRegistryの標準名を使用して、JNDI内のTransactionSynchronizationRegistryオブジェクトをルックアップできるようになりました。Oracleでは、このサポートを拡張するため、2つのグローバルJNDI名(javax/transaction/TransactionSynchronizationRegistryとweblogic/transaction/TransactionSynchronizationRegistry)を追加しました。詳細は、javax.transaction.TransactionSynchronizationRegistry (http://docs.oracle.com/javaee/5/api/index.html?javax/transaction/TransactionSynchronizationRegistry.html)を参照してください。

Oracle WebLogicでは、JTAの拡張機能として以下のクラスとインタフェースが提供されます。

- weblogic.transaction.RollbackException (javax.transaction.RollbackExceptionを拡張)
このクラスでは、より包括的な例外情報で使用するためにロールバックの元々の理由が保持されます。

- weblogic.transaction.TransactionManager (javax.transaction.TransactionManagerを拡張)
WebLogic JTAトランザクション・マネージャ・オブジェクトでは、XAリソースが起動時にトランザクション・マネージャに対する登録を行ったり、登録を解除したりできるようにするこのインタフェースがサポートされています。このインタフェースを利用すると、トランザクションをサスペンド後に再開することもできます。

このインタフェースには、以下のメソッドがあります。

- registerStaticResource、registerDynamicResource、およびunregisterResource

- registerResource - (WebLogic Server 8.1で新しく追加されたメソッド)このメソッドでは、トランザクション・マネージャによるリソースの管理方法を指定するためのプロパティがサポートされています。

- getTransaction

- forceResumeおよびforceSuspend

- begin

- weblogic.transaction.Transaction (javax.transaction.Transactionを拡張)
WebLogic JTAトランザクション・オブジェクトでは、ユーザーがトランザクション・プロパティを取得および設定できるようにするこのインタフェースがサポートされています。

このインタフェースには、以下のメソッドがあります。

- setNameおよびgetName

- addProperties、setProperty、getProperty、およびgetProperties

- setRollbackReasonおよびgetRollbackReason

- getHeuristicErrorMessage

- getXIDおよびgetXid

- getStatusAsString

- getMillisSinceBegin

- getTimeToLiveMillis

- isTimedOut

- weblogic.transaction.TransactionHelper
このクラスを使用すると、現在のトランザクション・マネージャおよびトランザクションを取得できます。TxHelperのかわりに使用されます。

このインタフェースには、以下の静的メソッドがあります。

- getTransaction

- getUserTransaction

- getTransactionManager

- weblogic.transaction.TxHelper (非推奨です。かわりにTransactionHelperを使用してください)
このクラスを使用すると、現在のトランザクション・マネージャおよびトランザクションを取得できます。

このインタフェースには、以下の静的メソッドがあります。

- getTransaction、getUserTransaction、getTransactionManager

- status2String

- weblogic.transaction.XAResource (javax.transaction.xa.XAResourceを拡張)
このクラスを使用すると、XAリソースをリストから削除できます。

このインタフェースには、次のメソッドがあります。

- getDelistFlag

- weblogic.transaction.nonxa.NonXAResource
このインタフェースを使用すると、javax.transaction.xa.XAResourceインタフェースをサポートしていないリソースを簡単にWebLogic Serverトランザクション・マネージャに統合できます。トランザクション・マネージャでは、非XAリソースが分散トランザクションに参加することを許可する、最後のエージェントによる2フェーズ・コミットの最適化のバリエーションがサポートされています。プロトコルは、非XAリソースに対して1フェーズ・コミットを発行し、その処理の結果を使用してトランザクションのコミットの決定を行います。

javax.transactionインタフェースおよびjavax.transaction.xaインタフェースに対するWebLogicの拡張機能の詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transactionパッケージの概要に関する項を参照してください。

7 ロギング・ラスト・リソース・トランザクションの最適化

この章では、WebLogic Serverで、JDBCデータ・ソースを通じてロギング・ラスト・リソース(LLR)トランザクションの最適化をサポートする方法を説明します。LLRは、1つのXA以外のリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。

LLRは、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLRリソースは、トランザクション処理にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。

LLR参加リソースによるグローバルな2フェーズ・コミット(2PC)トランザクションでは、WebLogic Serverトランザクション・マネージャは次の基本的な手順に従います。

- 他のすべての(XA対応の)トランザクション参加リソースに対してprepareを呼び出します。

- (ファイル・ベースのトランザクション・ログではなく) LLR参加リソースの表へコミット・レコードを挿入します。

- LLR参加リソースのローカル・トランザクション(トランザクション・コミット・レコードの挿入とアプリケーションのSQL処理の双方を含む)をコミットします。

- その他すべてのトランザクション参加リソースに対してcommitを呼び出します。

- トランザクションが正常に終了したら、データベース・トランザクション・ログ・エントリを、今後のトランザクションの一部として、遅れて削除します。

以下の節は、WebLogic ServerにおけるLLRトランザクション処理の詳細を説明します。

- LLR最適化トランザクションの最適化について

- ロギング・ラスト・リソース処理の詳細

- LLRデータベース表の詳細

- LLRの障害とリカバリ処理

- LLRでのパフォーマンス最適化

LLRの特長に関する詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソースのトランザクション・オプションに関する項を参照してください。

LLR最適化トランザクションの最適化について

多くの場合、グローバル・トランザクションが2フェーズ・コミット(2PC)トランザクションになるのは、データベース操作(JDBCを使用)と、メッセージ・キュー操作(JMSを使用)などの非データベース操作が関与しているためです。このように、2PCトランザクション内のデータベースへの参加リソースが1つの場合、ロギング・ラスト・リソース(LLR)最適化トランザクション・オプションは、データベース処理のXAオーバーヘッドの一部を除去し、JDBC XAドライバ(通常は非XAドライバよりも効率が悪い)の使用を回避することにより、トランザクションのパフォーマンスを著しく向上させられます。LLRトランザクション・オプションでは、「2フェーズ・コミットのエミュレート」JDBCデータ・ソース・オプションやNonXAResourceリソース・アダプタ(コネクタ)オプションの場合のようにデータがリスクを受けることはありません。

ロギング・ラスト・リソース処理の詳細

サーバー起動時またはデータ・ソースのデプロイメント時に、LLRデータ・ソースは、データベース接続のプールを行うデータベース上に、表をロードまたは作成します。表は、データベース接続を作成するよう指定されたユーザーが決定したスキーマ内に作成されます。データベース表が作成またはロードできない場合、サーバーの起動は失敗します。

グローバル・トランザクション内で、LLRデータ・ソースから最初に取得された接続が、そのトランザクション専用の内部JDBC接続を予約します。内部JDBC接続は、トランザクションのコーディネータでもある特定のサーバー上で予約されます。任意のサーバーにある同名のデータ・ソースから取得された接続に対する後続のトランザクション操作は、すべてこの同じ単一の内部JDBC接続にルーティングされます。

LLRトランザクションがコミットされると、WebLogic Serverトランザクション・マネージャはその処理を透過的に扱います。アプリケーション側から見ると、トランザクション・セマンティクスは同じままですが、内部から見ると、トランザクションには標準的なXAトランザクションとは異なった処理が行われています。アプリケーションがグローバル・トランザクションをコミットすると、WebLogic Serverトランザクション・マネージャは、他のトランザクション参加リソースに対してトランザクション作業をコミットする前に、LLR接続に対して原子性を維持しつつローカル・トランザクションをコミットします。2フェーズ・コミット・トランザクションの場合、トランザクション・マネージャは同じローカル・トランザクションの一部として、データベース上に2PCレコードの書込みも行います。ローカル・トランザクションが正常に完了した後、トランザクション・マネージャは他のすべてのグローバル・トランザクション参加リソースに対しcommitを呼び出します。他のすべてのトランザクション参加リソースがコミット・フェーズを完了させると、関連のLLR 2PCトランザクション・レコードは、解放されて削除できるようになります。トランザクション・マネージャは、短い間隔を置いて、または別のローカル・トランザクションで、トランザクション・レコードを遅れて削除します。

アプリケーションがグローバル・トランザクションをロールバックするか、トランザクションがタイムアウトした場合、トランザクション・マネージャはローカル・トランザクションの作業をロールバックし、データベースに2PCレコードを格納しません。

LLRトランザクションの最適化を有効化するには、JDBCデータ・ソースをロギング・ラスト・リソース・トランザクション・プロトコルで作成して、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのLLRを利用可能なJDBCデータ・ソースの作成に関する項を参照してください。また、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソースのトランザクション・オプションに関する項も参照してください。

データ・ソースの構成および使用上の要件と制限事項のリストについては、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の次のトピックを参照してください。

- LLRデータ・ソースに関するプログラミング上の考慮事項と制限事項

- LLRデータ・ソースに関する管理上の考慮事項と制限事項

LLRデータベース表の詳細

各WebLogicサーバー・インスタンスは、JDBC LLRデータ・ソースがデータベース接続をプールするデータベース上に、データベース「LLR」表を保持します。これらの表は、トランザクション・ログ・レコードの格納に使用されるもので、自動的に作成されます。複数のLLRデータ・ソースが同じWebLogicサーバー・インスタンス上にデプロイされて同じデータベース・インスタンスおよびデータベース・スキーマに接続されている場合、これらのデータ・ソースも同じLLR表を共有します。

LLR表名は、管理者が構成することを選択しない限り、自動的に生成されます。デフォルトの表名は、WL_LLR_SERVERNAMEです。一部のDBMSシステムでは、表名の長さが最大18文字に制限されます。環境を構成する際には、表名の最大長を考慮に入れてください。

LLRデータベース表に関しては、次の制限事項があります。

- 起動時にLLR表にアクセスできなかった場合、サーバーは起動しません。サーバー起動時に自動的に実行されるリカバリの期間中に、疑わしいトランザクションを正しく解決するには、LLRトランザクション・レコードが使用できなければなりません。

- 複数のサーバーで同じLLR表を共有することはできません。サーバー起動時に、WebLogic ServerはJDBCデータ・ソースのドメイン名とサーバー名が、表作成時に表に格納されたドメイン名とサーバー名に一致することを確認します。複数のサーバーが同じLLR表を共有していることを検出すると、WebLogic Serverは1つまたはそれ以上のサーバーを停止します。

リソースのトランザクション・ログ・レコードの格納に使用される表名を変更するには、次の手順に従います。

1. 管理コンソール画面の左上の隅にある「チェンジ・センター」で、「ロックして編集」をクリックして、構成編集セッションを開始します。

2. 「サーバー: 構成: 全般」ページで、「詳細」をクリックして、詳細構成のオプションを表示します。次を参照

3. 「JDBC LLR表名」に、リソースのトランザクション・レコードの格納に使用する表の名前を入力し、その後「保存」をクリックします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: 全般」を参照してください。

4. LLRが有効化されたデータ・ソースがデプロイされている各サーバーに対して、ステップ2および3を繰り返します。

5. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

注意:

変更を有効にするには、すべてのサーバーを再起動する必要があります。

LLR表のトランザクション・ログ・レコード

コミットされた各2PC LLRトランザクションについて、トランザクション・マネージャはLLRデータベース表にトランザクション・レコードを自動的に挿入します。LLRトランザクションが完了すると、トランザクション・マネージャはトランザクション・レコードを遅れて削除します。LLR表トランザクション・ログ・レコードの削除が失敗した場合、サーバーは警告メッセージをログに記録し、後で削除を再試行します。

LLRトランザクション・レコードが格納されたデータベースを移動する必要がある場合は、トランザクションが正しく完了できるよう、必ずLLR表のコンテンツを新しいデータベースに移動してください。

注意:

本番システムでは、LLRトランザクション・レコードまたはLLR表を手動で削除しないでください。削除すると、暗黙のヒューリスティックなトランザクションが失敗します。

LLRの障害とリカバリ処理

一般に、WebLogicトランザクション・マネージャは、次のようにしてトランザクションの失敗を処理します。

- ローカル・トランザクションのコミットが試行される前に発生する2フェーズ・コミット・エラーの場合、トランザクション・マネージャは即座にトランザクション・ロールバック例外をスローします。

- ローカル・トランザクションのコミット中に発生する2フェーズ・コミット・エラーの場合、動作はトランザクション・レコードがデータベースに書き込まれるかどうかに応じて異なります。

- レコードが書き込まれるならば、トランザクション・マネージャはトランザクションをコミットします。

- レコードが書き込まれないならば、トランザクション・マネージャはトランザクションをロールバックします。

- レコードが書き込まれるかどうかが分からない場合は、トランザクション・マネージャはあいまいなコミット失敗例外をスローし、トランザクション破棄タイムアウトになるまで、5秒ごとにトランザクションの完了を試行します。トランザクションが未完了のままであれば、トランザクション・マネージャは破棄されたトランザクション・メッセージをログに記録します。

サーバー・クラッシュの調整

LLRリソースがトランザクション・ログ・レコードを格納する前、またはLLRリソースがコミットする前に、トランザクションの調整サーバーがクラッシュした場合、トランザクションはロールバックされます。LLRリソースがコミットされた後にサーバーがクラッシュした場合、トランザクションは最終的には完全にコミットされます。サーバー起動中、トランザクション・コーディネータはLLRリソースを使用してデータベースからトランザクション・ログ・レコードを読み取り、その後、リカバリされた情報を使用して、参加しているすべての非LLR XAリソース上の未完了の作業をすべてコミットします。

JDBC接続障害

LLRリソースのJDBC接続が、2PCトランザクション・レコードの挿入中に失敗した場合、トランザクション・マネージャはトランザクションをロールバックします。

LLRリソースのJDBC接続が、ローカル・トランザクションのコミット中に失敗した場合の結果は、トランザクションが1フェーズ・コミット(LLRリソースが唯一の参加リソースである、1PC)であるか2PCであるかによって異なります。

- 1PCトランザクションの場合、トランザクションは完全にコミットされるか、完全にロールバックされるか、ローカル・トランザクションの解決の待機をブロックします。トランザクションは最終的に完全にコミットされるか、完全にロールバックされるので、その結果は完全にACIDです。

- 2 PCトランザクションの場合の結果は、「LLRの障害とリカバリ処理」で説明したようになります。

サーバー起動時のLLRトランザクション・リカバリ

各WebLogicサーバーのトランザクション・マネージャは、サーバー起動時に、サーバーによって調整される未完了のトランザクション(LLRトランザクションを含む)をリカバリする必要があります。これを行うには、各サーバーは各LLRデータ・ソースのLLRデータベース表から、トランザクション・レコードを読み取ろうとします。サーバーがLLRデータベース表にアクセスできない場合、またはリカバリが失敗した場合、サーバーは起動せず、トランザクション・マネージャにより不正な状態(HealthState.HEALTH_FAILED)としてマークされます。

リカバリの途中でタイムアウトが生じたとすれば、それはLLRログ表内の行をロックした未解決のローカル・トランザクションが原因である場合があります。そのようなローカル・トランザクションを解決して、レコードがロックされた行に格納されているグローバル・トランザクションの状態をトランザクション・マネージャが判断できるようにする必要があります。ローカル・データベース・トランザクションは診断および解決するには、各データベースの固有のツールを使用する必要があります(コマンドはデータベースごとに違います)。

LLRのフェイルオーバーに関する考慮事項

LLRでのフェイルオーバーに関する次の注意事項および制限事項を考慮してください。

- トランザクション・ログ(TLog)は、LLRトランザクションでも必要です。

- TLogは引続きトランザクション・マネージャの「チェックポイント」レコードを格納します。

- TLogはフェイルオーバーでも引続きアクセス可能である、またはコピーされます。

- LLRは、サーバーの移行およびトランザクション・リカバリ・サービスの移行をサポートします。トランザクション・リカバリ・サービスの移行を使用するには、クラスタまたはクラスタ内の候補サーバーのセットのいずれかに各LLRリソースがターゲット指定されていることを確認します。「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。

LLRでのパフォーマンス最適化

この節の内容は、以下のとおりです。

- トランザクション・コーディネータの場所の最適化

- LLRデータ・ソースを使用した読取り専用操作のパフォーマンスの変動

- データ・ソース別のLLR表の指定

トランザクション・コーディネータの場所の最適化

LLR参加リソースでのグローバル・トランザクション内では、WebLogic Serverはすべての接続操作をトランザクションの調整サーバーに自動的にルーティングします。このルーティングが大きな負荷になる場合があります。可能であれば、アプリケーションが調整サーバー上で直接実行されるように、またコーディネータ上で直接ホストされる接続インスタンスを使用するように、最適化を行うと、パフォーマンスが向上すると考えられます。

トランザクションを開始するクライアント・アプリケーションに関しては、トランザクションのコーディネータは、クライアントがそのトランザクションの下で呼出し(RMI、EJB、JDBC、またはJMS呼出しのどれでも可)を行う最初のWebLogicサーバーとなります。JMSの場合、これはクライアントのJMS接続をホストするサーバーです。JMS宛先をホストするサーバーと同じである必要はありません。

サーバー側アプリケーションの場合、トランザクションのコーディネータは、ローカル・リソースが最初に呼び出されたのであれば(JMS宛先、JDBC接続など)ローカル・サーバーとなります。ただし、先にリモート・サーバーが呼び出されていた場合(リモートでホストされるJDBC接続、EJB、RMI呼び出し、またはJMS接続のいずれか)は、その限りではありません。これには、他のクラスタまたはドメインのリモート・サーバーが含まれます。

LLRデータ・ソースを使用した読取り専用操作のパフォーマンスの変動

LLRの最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLRでの読取り操作では、XAでの読取り操作と比べて、幾分パフォーマンスが低下します。最高のパフォーマンスを得るためには、読取り専用操作のためのLLRではないJDBCデータ・ソースを構成する必要があります。

データ・ソース別のLLR表の指定

Oracle RACを使用する環境のパフォーマンスを改善するには、各サーバーに対してではなく各データ・ソースに対してLLR表を指定することで、Oracle RACクラスタでのローカル・ノード・キャッシュの利用効率が上がります。

WebLogic Serverインスタンスの起動時にデータ・ソースごとにLLR表の指定を設定するには、次のシステム・プロパティを使用します。

-Dweblogic.llr.table.datasourcename=tablename

ここで、datasourcenameはデータ・ソースの名前、tablenameは、datasourcenameにマップするLLR表の名前です。

たとえば、次のシステム・プロパティを使用するとします。

-Dweblogic.llr.table.LLRDS1=myllrtable1

サーバーが起動すると、次の操作が行われます。

- INFOメッセージがstdoutに書き込まれます。
LLR data source LLRDS1 using LLR table myllrtable1

- データ・ソースLLRDS1を使用するサーバー用のすべてのLLRエントリは、mylltable1というLLR表に格納されます。

データ・ソースがターゲット指定される各サーバーの各データ・ソースに対して1つの表を定義します。異なるWLSインスタンスで同じ表を共有することはできません。LLRDS1が2つのWebLogic ServerインスタンスS1およびS2にターゲット指定される場合、2つの表S1_LLRDS1とS2_LLRDS1を作成し、各サーバーに適切なシステム・プロパティを指定します。

例:

S1の場合、-Dweblogic.llr.table.LLRDS1=S1_LLRDS1を使用します。

S2の場合、-Dweblogic.llr.table.LLRDS1=S2_LLRDS1を使用します。

注意:

次のリリースのWebLogic Serverでは、node-idは、拡張されたLLR表で自動的に捕捉されるため、データはそれぞれのWebLogic Serverノードにパーティション化されます。データ・ソースごとに表を手動で割り当てる必要はありません。

制限事項

JTAサービス移行では、データ・ソース専用のLLR表はサポートされません。

8 EJBアプリケーションのトランザクション

この章では、Oracle WebLogic Serverで動作するEnterprise JavaBeans (EJB)アプリケーションでトランザクションを実装する方法について説明します。

- 始める前に

- ガイドライン

- トランザクション属性

- トランザクションへの参加

- トランザクション・セマンティクス

- セッションの同期

- トランザクション時の同期

- トランザクション・タイムアウトの設定

- EJBトランザクションでの例外処理

始める前に

開始する前に、第2章「トランザクションについて」(特に次のトピック)を読んでください。

- WebLogic Server EJBアプリケーションのトランザクション

- トランザクションのサンプルEJBコード

ここでは、Enterprise JavaBeansでのトランザクションのOracle WebLogic Server実装について説明します。ここで説明する情報は、「Enterprise JavaBeans仕様2.1」を補足するものです。

注意:

この章を読み進める前に、EJB仕様2.1のドキュメントの内容、特に第16章「Support for Transactions」に記載されている概念やデータをよく理解しておく必要があります。

WebLogic ServerアプリケーションでのEnterprise JavaBeansの実装については、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』を参照してください。

ガイドライン

以下のガイドラインは、WebLogic Server向けのEJBアプリケーションでトランザクションを実装するときに適用されます。

- EJB仕様では、フラット・トランザクションのみがサポートされています。トランザクションをネストすることはできません。

- EJB仕様では、複数のリソース(データベースなど)にまたがる分散トランザクションと、EJB CMP 2.1およびEJB CMP 1.1に対応した2フェーズ・コミット・プロトコルがサポートされています。

- 標準的なプログラミング手法を使用してトランザクション処理を最適化します。たとえば、トランザクションの境界を適切に設定すると、トランザクションの処理が速くなります。

- EJBが実行されているWebLogic Serverインスタンス上の、ローカルTxDataSourceからデータベース接続を使用します。リモートWebLogic Serverインスタンス上のTxDataSourceからは接続を使用しないでください。

- トランザクション対応のEJBアプリケーションでパフォーマンスを最大限に引き出すために、必ずEJBキャッシュを調整します。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』を参照してください。

WebLogic Serverトランザクション・サービスのガイドラインについては、「機能と制限」を参照してください。

トランザクション属性

この節の内容は以下のとおりです。

- EJBのトランザクション属性について

- コンテナ管理のトランザクションのトランザクション属性

- Bean管理のトランザクションのトランザクション属性

EJBのトランザクション属性について

トランザクション属性では、トランザクションがEJBアプリケーションでどのように管理されるのかが指定されます。各EJBについて、トランザクション属性により、トランザクションの境界がWebLogic Server EJBコンテナによって設定されるのか(コンテナ管理のトランザクション)、またはEJB自体によって設定されるのか(Bean管理のトランザクション)が指定されます。EJBがコンテナ管理とBean管理のどちらであるのかは、デプロイメント記述子のtransaction-type要素の設定で決まります。transaction-type要素の詳細は、EJB仕様2.1の第16章「Support for Transactions」と第21章「Deployment Descriptor」を参照してください。

概して、Bean管理のトランザクションよりもコンテナ管理のトランザクションの方がよく使用されます。なぜなら、その方がアプリケーションのコードがシンプルになるからです。たとえば、コンテナ管理のトランザクションでは、トランザクションを明示的に開始する必要がありません。

WebLogic Serverでは、EJB仕様2.1のセクション16.4で定義されているメソッド・レベルのトランザクション属性が完全にサポートされています。

コンテナ管理のトランザクションのトランザクション属性

コンテナ管理のトランザクションの場合、トランザクション属性はデプロイメント記述子のcontainer-transaction要素で指定します。コンテナ管理のトランザクションには、すべてのエンティティBeanと、transaction-typeがContainerに設定されているステートフルまたはステートレスのセッションBeanが含まれます。これらの要素に関する詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』を参照してください。

EJBとそのビジネス・メソッドに対して指定できるトランザクション属性は以下のとおりです。

- NotSupported

- Supports

- Required

- RequiresNew

- Mandatory

- Never

trans-attributeの設定に対するWebLogic Server EJBコンテナの反応については、EJB仕様2.1のセクション17.6.2 (http://www.oracle.com/technetwork/java/javaee/ejb/index.html)を参照してください。

デプロイメント記述子でタイムアウト値が定義されていない場合は、WebLogic Server EJBコンテナによって自動的にトランザクションのタイムアウトが設定されます。コンテナではTimeout Seconds構成パラメータの値が使用されます。デフォルトのtimeout値は30秒です。

コンテナ管理のトランザクションを使用するEJBの場合、EJBはjavax.transaction.UserTransactionインタフェースにアクセスすることができず、また、開始と終了のトランザクション・コンテキストが一致していなければなりません。さらに、コンテナ管理のトランザクションを使用するEJBでは、javax.ejb.EJBContextインタフェースのsetRollbackOnlyメソッドとgetRollbackOnlyメソッドのサポートが制限されています(EJB仕様2.1のセクション16.4.4.2と16.4.4.3で規定されている規則によって呼出しが制限されます)。

Bean管理のトランザクションのトランザクション属性

Bean管理のトランザクションの場合は、Beanがjavax.transaction.UserTransactionインタフェースのメソッドを使用してトランザクションの境界設定を指定します。Bean管理のトランザクションには、transaction-typeがBeanに設定されているステートフルまたはステートレスのセッションBeanが含まれます。エンティティBeanでは、Bean管理のトランザクションは使用できません。

ステートレス・セッションBeanの場合は、開始と終了のトランザクション・コンテキストが一致していなければなりません。ステートフル・セッションBeanの場合は、開始と終了のトランザクション・コンテキストが必ずしも一致している必要はありません。一致していない場合は、WebLogic Server EJBコンテナによってBeanと未終了のトランザクションとの関連付けが維持されます。

Bean管理のトランザクションを使用するセッションBeanでは、javax.ejb.EJBContextインタフェースのsetRollbackOnlyメソッドとgetRollbackOnlyメソッドは使用できません。

トランザクションへの参加

EJB仕様2.1で使用される「トランザクションに参加する」という表現は、Beanが以下のいずれかの条件を満たしていると解釈します。

- Beanがトランザクション・コンテキスト(コンテナ管理のトランザクション)で呼び出されます。

- Beanが、クライアントによって呼び出されたBeanメソッドの中でUserTransaction APIを使用してトランザクションを開始し(Bean管理のトランザクション)、かつ、クライアントによって呼び出された対応するBeanメソッドの終了時にそのトランザクションをサスペンドまたは終了しない。

トランザクション・セマンティクス

この節の内容は以下のとおりです。

- コンテナ管理のトランザクションのトランザクション・セマンティクス

- Bean管理のトランザクションのトランザクション・セマンティクス

EJB仕様2.1では、EJBの種類(エンティティBean、ステートレス・セッションBean、またはステートフル・セッションBean)とトランザクションの種類(コンテナ管理またはBean管理)に基づいてトランザクション処理の動作を決定するセマンティクスが規定されています。それらのセマンティクスでは、メソッドが呼び出されるときのトランザクション・コンテキストが規定されており、また、EJBがjavax.transaction.UserTransactionインタフェースのメソッドにアクセスできるかどうかが定義されています。EJBアプリケーションは、それらのセマンティクスに注意して設計する必要があります。

コンテナ管理のトランザクションのトランザクション・セマンティクス

コンテナ管理のトランザクションの場合、トランザクション・セマンティクスはBeanの種類によって異なります。

ステートフル・セッションBeanのトランザクション・セマンティクス

表8-1は、コンテナ管理のトランザクションのステートフル・セッションBeanのトランザクション・セマンティクスを示したものです。

表8-1 コンテナ管理のトランザクションのステートフル・セッションBeanのトランザクション・セマンティクス

メソッド

メソッドが起動された時点でのトランザクション・コンテキスト

ユーザー・トランザクション・メソッドにアクセスできるか

Constructor

指定なし

いいえ

setSessionContext()

指定なし

いいえ

ejbCreate()

指定なし

いいえ

ejbRemove()

指定なし

いいえ

ejbActivate()

指定なし

いいえ

ejbPassivate()

指定なし

いいえ

ビジネス・メソッド

トランザクション属性によって「はい」または「いいえ」

いいえ

afterBegin()

はい

いいえ

beforeCompletion()

はい

いいえ

afterCompletion()

いいえ

いいえ

ステートレス・セッションBeanのトランザクション・セマンティクス

表8-2は、コンテナ管理のトランザクションのステートレス・セッションBeanのトランザクション・セマンティクスを示したものです。

表8-2 コンテナ管理のトランザクションのステートレス・セッションBeanのトランザクション・セマンティクス

メソッド

メソッドが起動された時点でのトランザクション・コンテキスト

ユーザー・トランザクション・メソッドにアクセスできるか

Constructor

指定なし

いいえ

setSessionContext()

指定なし

いいえ

ejbCreate()

指定なし

いいえ

ejbRemove()

指定なし

いいえ

ビジネス・メソッド

トランザクション属性によって「はい」または「いいえ」

いいえ

エンティティBeanのトランザクション・セマンティクス

表8-3は、コンテナ管理のトランザクションのエンティティBeanのトランザクション・セマンティクスを示したものです。

表8-3 コンテナ管理のトランザクションのエンティティBeanのトランザクション・セマンティクス

メソッド

メソッドが起動された時点でのトランザクション・コンテキスト

ユーザー・トランザクション・メソッドにアクセスできるか

コンストラクタ

指定なし

いいえ

setEntityContext()

指定なし

いいえ

unsetEntityContext()

指定なし

いいえ

ejbCreate()

対応するcreateのトランザクション属性で決まります

いいえ

ejbPostCreate()

対応するcreateのトランザクション属性で決まります

いいえ

ejbRemove()

対応するremoveのトランザクション属性で決まります

いいえ

ejbFind()

対応するfindのトランザクション属性で決まります

いいえ

ejbActivate()

指定なし

いいえ

ejbPassivate()

指定なし

いいえ

ejbLoad()

ejbLoad()を呼び出したビジネス・メソッドのトランザクション属性で決まります

いいえ

ejbStore()

ejbStore()を呼び出したビジネス・メソッドのトランザクション属性で決まります

いいえ

ビジネス・メソッド

トランザクション属性によって「はい」または「いいえ」

いいえ

Bean管理のトランザクションのトランザクション・セマンティクス

Bean管理のトランザクションの場合、トランザクション・セマンティクスはステートフルとステートレスのセッションBeanで異なります。エンティティBeanでは、Bean管理のトランザクションは利用できません。

ステートフル・セッションBeanのトランザクション・セマンティクス

表8-4は、Bean管理のトランザクションのステートフル・セッションBeanのトランザクション・セマンティクスを示したものです。

表8-4 Bean管理のトランザクションのステートフル・セッションBeanのトランザクション・セマンティクス

メソッド

メソッドが起動された時点でのトランザクション・コンテキスト

ユーザー・トランザクション・メソッドにアクセスできるか

コンストラクタ

指定なし

いいえ

setSessionContext()

指定なし

いいえ

ejbCreate()

指定なし

はい

ejbRemove()

指定なし

はい

ejbActivate()

指定なし

はい

ejbPassivate()

指定なし

はい

Business method

通常は、Beanでの直前のメソッド実行がトランザクション・コンテキストの中で終了していないかぎり、「いいえ」

はい

afterBegin()

適用なし

適用なし

beforeCompletion()

適用なし

適用なし

afterCompletion()

適用なし

適用なし

ステートレス・セッションBeanのトランザクション・セマンティクス

表8-5は、Bean管理のトランザクションのステートレス・セッションBeanのトランザクション・セマンティクスを示したものです。

表8-5 Bean管理のトランザクションのステートレス・セッションBeanのトランザクション・セマンティクス

メソッド

メソッドが起動された時点でのトランザクション・コンテキスト

ユーザー・トランザクション・メソッドにアクセスできるか

コンストラクタ

指定なし

いいえ

setSessionContext()

指定なし

いいえ

ejbCreate()

指定なし

はい

ejbRemove()

指定なし

はい

ビジネス・メソッド

いいえ

はい

セッションの同期

コンテナ管理のトランザクションを使用するステートフル・セッションBeanでは、javax.ejb.SessionSynchronizationインタフェースを実装してトランザクション同期通知を提供できます。その場合、ステートフル・セッションBeanのすべてのメソッドでは、REQUIRES_NEW、MANDATORY、またはREQUIREDのいずれかのトランザクション属性をサポートしなければなりません。javax.ejb.SessionSynchronizationインタフェースの詳細は、EJB仕様2.1のセクション6.5.3を参照してください。

トランザクション時の同期

BeanでSessionSynchronizationが実装されている場合、通常、WebLogic Server EJBコンテナではトランザクションのコミット時にBeanに対して次のコールバックが行われます。

- afterBegin()

- beforeCompletion()

- afterCompletion()

EJBコンテナは、beforeCompletionメソッドで他のBeanを呼び出すか、またはXAリソースを追加することができます。呼出しの回数は、beforeCompletionIterationLimit属性によって制限されます。この属性は、トランザクションがロールバックされるまでに処理されるコールバックのサイクル数を指定します。同期サイクルは、登録されているオブジェクトがbeforeCompletionコールバックを受信し、リソースが追加されるか、または以前に同期されていたオブジェクトが再登録されたときに発生します。反復制限を利用することで、同期サイクルが無限に繰り返されることを防止できます。

トランザクション・タイムアウトの設定

EJBアプリケーションのトランザクションには、タイムアウトを指定できます。トランザクションの存続期間がタイムアウトの設定値を超えた場合、トランザクション・サービスによってそのトランザクションは自動的にロールバックされます。

注意:

トランザクションでbegin()を実行する前に、タイムアウトを設定する必要があります。タイムアウトを設定しても、すでに開始されているトランザクションには反映されません。

タイムアウトの指定方法は、トランザクションの種類によって異なります。

- コンテナ管理のトランザクション。weblogic-ejb-jar.xmlデプロイメント記述子でtrans-timeout-seconds属性を構成します。

- Bean管理のトランザクション。アプリケーションによってUserTransaction.setTransactionTimeoutメソッドが呼び出されます。

EJBトランザクションでの例外処理

WebLogic Server EJBアプリケーションでは、トランザクションの途中でスローされた特定の例外を取得して処理する必要があります。例外処理の詳細は、EJB仕様2.1の「Exception Handling」を参照してください。

EJBトランザクションでビジネス・メソッドによって例外がどのようにスローされるのかについては、セクション17.3にある表12 (コンテナ管理のトランザクション)および表13 (Bean管理のトランザクション)を参照してください。

クライアントの観点から見た例外については、セクション17.4を参照してください。特に、セクション12.4.1 (アプリケーション例外)、セクション17.4.2 (java.rmi.RemoteException)、セクション17.4.2.1 (javax.transaction.TransactionRolledBackException)、およびセクション17.4.2.2 (javax.transaction.TransactionRequiredException)の参照をお薦めします。

9 RMIアプリケーションのトランザクション

この章では、Oracle WebLogic Server環境で動作するRMIアプリケーションで、トランザクションを使用するためのガイドラインを説明し、追加のリファレンスを示します。

- 始める前に

- ガイドライン

始める前に

開始する前に、第2章「トランザクションについて」(特に次のトピック)を読んでください。

- WebLogic Server RMIアプリケーションのトランザクション

- トランザクションのサンプルRMIコード

RMIアプリケーションの詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』を参照してください。

ガイドライン

以下のガイドラインは、WebLogic Server向けのRMIアプリケーションでトランザクションを実装するときに適用されます。

- WebLogic Serverでは、フラット・トランザクションのみがサポートされています。トランザクションをネストすることはできません。

- 標準的なプログラミング手法を使用してトランザクション処理を最適化します。たとえば、トランザクションの境界を適切に設定すると、トランザクションの処理が速くなります。

- RMIアプリケーションでは、トランザクションでコールバック・オブジェクトを使用することが推奨されていません(WebLogic Serverで管理できないため)。
デフォルトでは、リモート・オブジェクトにおけるすべてのメソッド呼出しはトランザクション処理です。コールバック・オブジェクトが必要な場合は、WebLogic RMIコンパイラで -nontransactionalフラグを使って、これらのクラスをコンパイルする必要があります。『Oracle WebLogic Server RMIのプログラミング』のWebLogic RMIコンパイラの使い方に関する項およびWebLogic RMIコンパイラのオプションに関する項を参照してください。

- RMIアプリケーションでは、RMIクライアントがトランザクションを開始できますが、すべてのトランザクション処理はWebLogic Serverをホストとするサーバー・オブジェクトまたはリモート・オブジェクト上で行われる必要があります。クライアントJVM上でホストされるリモート・オブジェクトは、トランザクション処理に参加できません。
回避策としては、クライアントJVM上のリモート・オブジェクトを呼び出す前にトランザクションをサスペンドし、リモート処理が終了した後でトランザクションを再開します。

WebLogic Serverトランザクション・サービスのガイドラインについては、「機能と制限」を参照してください。

10 WebLogic ServerでのJDBC XAドライバの使い方

この章では、WebLogic Serverでの様々なXA JDBCドライバの使用方法について説明します。

- XAドライバの概要

- Oracle Thin/XA Driverの使い方

- Sybase jConnect 5.5および6.0/XA Driverの使い方

- その他のXAドライバの使い方

XAドライバの概要

この項では、分散トランザクションにおけるWebLogic ServerでのXA JDBCドライバの使い方について説明します。これらのドライバは、WebLogic Server接続プールとDBMSの間の接続を提供します。分散トランザクションで使用するドライバは、後に「/XA」が続くドライバ名(Oracle Thin/XA Driverなど)によって指定されます。

XAドライバの表

次の表に、これらのJDBC/XAドライバをWebLogic Serverで使用する場合の確認済の機能について示します。

表10-1 2層JDBC/XAドライバ

ドライバ/データベースのバージョン

説明

Oracle Thin Driver XA

「Oracle Thin/XA Driverの使い方」を参照してください。

Sybase jConnect/XA

- バージョン6.0

- バージョン5.5

- Adaptive Server Enterprise 12.0

「Sybase jConnect 5.5および6.0/XA Driverの使い方」を参照してください。

Oracle Thin/XA Driverの使い方

WebLogic Serverに付属するOracle Thin Driver 10gは事前に構成され、そのまま使用できる状態になっています。ドライバを更新する場合や異なるバージョンを使用する場合は、『Oracle WebLogic Server JDBCのプログラミング』のOracle Thin DriverでのOracle拡張機能の使用に関する項を参照してください。

WebLogic ServerでOracle Thin/XA Driverを使用するための情報を以下の節で示します。

Oracle Thin/XA Driverのソフトウェア要件

Oracle Thin/XA Driverのソフトウェア要件は次のとおりです。

- Java 2 SDK 1.4.x以降。

注意:

Java 2 SDK 1.4.Xで使用できるバージョンは、Oracle Thin Driver 10gおよび9.2 (ojdbc14.jar)のみです。

- XAトランザクション・サポート用に構成されたOracleサーバー。

Oracle Thin/XA Driverの環境の設定

以下の節では、Oracle Thin/XA Driverの環境を設定する方法について説明します。

WebLogic Serverの構成

『Oracle WebLogic Server JDBCのプログラミング』のOracle Thin DriverでのOracle拡張機能の使用に関する項を参照してください。

XAのデータベース・サーバーでの有効化

XA用のデータベースを準備するには、以下の操作を実行します。

1. システム・ユーザーとしてsqlplusにログオンします(sqlplus sys/CHANGE_ON_INSTALL@<DATABASE ALIAS NAME>など)。

2. 次のコマンドを実行します。@xaview.sql
スクリプトxaview.sqlは、$ORACLE_HOME/rdbms/adminディレクトリにあります。

3. 以下の権限を与えます。

- grant select on v$xatrans$ to public (or <user>);

- grant select on pending_trans$ to public;

- grant select on dba_2pc_pending to public;

- grant select on dba_pending_transactions to public;

- (Oracle Thin driver 10.1.0.3以降をお使いの場合)
grant execute on dbms_system to <user>;

上の手順をデータベース・サーバー上で実行しない場合、通常のXAデータベース問合せと更新は正常に動作できます。ただし、クラッシュ後の再起動に続き、WebLogic Serverトランザクション・マネージャがリカバリを行うときに、OracleリソースのリカバリはXAER_RMERRになり失敗します。クラッシュのリカバリは、XAリソースに対する標準的な処理です。

Oracle Thin/XA Driverの構成プロパティ

次の表に、JDBCデータ・ソースの構成のためのサンプル・コードを示します。

表10-2 Oracle Thin/XA Driver: 接続プール構成

プロパティ名

プロパティ値

Name

oracleXAPool

URL

jdbc:oracle:thin:@serverName:port(typically 1521 on Windows):sid

DriverClassname

oracle.jdbc.xa.client.OracleXADataSource

Database Username

Scott

Properties

user=scott

Test Table Name

DUAL

Sybase jConnect 5.5および6.0/XA Driverの使い方

Sybase jConnect 5.5および6.0/XA Driverを使用する場合の重要な構成情報とパフォーマンス問題を以下の節で示します。

- XAをサポートするためのSybaseサーバーの構成

- XAとSybase Adaptive Server

- Javaクライアントの構成プロパティ

- Sybase jConnect 5.5および6.0/XAの確認済みの問題

XAをサポートするためのSybaseサーバーの構成

データベース・サーバーで環境を設定するには、以下の説明に従います。

- sp_configure "enable DTM",1を実行して、トランザクションを有効にします。

- sp_configure "enable xact coordination",1を実行します。

- grant role dtm_tm_role to <USER_NAME>を実行します。

- SYBASE_INSTALL\OCS-12_0\sample\xa-dtmサブディレクトリにあるサンプルのxa_configファイルを、3レベル上位のSYBASE_INSTALLにコピーします。SYBASE_INSTALLは、Sybaseサーバーのインストール・ディレクトリです。例:

$ SYBASE_INSTALL\xa_config

- xa_configファイルを編集します。最初のxaセクションで、サンプル・サーバー名を適切なサーバー名に変更します。

トランザクションを実行するときのデッドロックを防ぐために、デフォルトで低レベル・ロックを有効にします。

- sp_configure "lock scheme",0,datarowsを実行します。

注意:

現在、jConnect.jar、jconn2、およびjconn3.jarは、WebLogic Serverの付属ファイルではありません。ただし、Sybaseドライバは、Sybaseから直接ダウンロードできます。

XAとSybase Adaptive Server

XA接続が適切にサポートされているのは、Sybase Adaptive Server Enterprise 12.0以降のバージョンのみになります。WebLogic ServerとのXA接続はSybase Adaptive Server 11.5および11.9ではサポートされていません。

Sybase Adaptive Serverにおける実行スレッドとトランザクション

Adaptive Server 12.0より前のバージョンでは、トランザクションのすべてのリソースが、サーバー上の単一のタスクによって非公開で所有されていました。サーバーは、トランザクションを開始したタスク以外のタスクとはトランザクションを共有できませんでした。Adaptive Serverバージョン12.xには、XA準拠のトランザクション・マネージャ(WebLogic Serverなど)によって使用されるサスペンドおよび結合のセマンティクスに対するサポートが含まれています。トランザクションは異なる実行スレッド間で共有できます。つまり、1つの実行スレッドに関連付けることはできません(デタッチ状態)。

デタッチされたトランザクションに対するタイムアウトの設定

Sybaseサーバーでは、dtm detach timeout periodを設定することで、分散トランザクション・ブランチがデタッチ状態(関連付けられた実行スレッドがない状態)のままでいる時間(分単位)を設定できます。この時間が経過すると、DBMSは自動的にトランザクションをロールバックします。dtm detach timeout periodは、データベース・サーバー上のすべてのトランザクションに適用されます。個々のトランザクションに対しては設定できません。

たとえば、10分のデタッチ状態が経過した後、自動的にトランザクションをロールバックするには、次のコマンドを使用します。

sp_configure 'dtm detach timeout period', 10

WebLogic Serverでトランザクションがタイムアウトする前にデータベース・サーバーによってトランザクションがロールバックされないように、dtm detach timeout periodはトランザクションのタイムアウトより大きい値に設定する必要があります。

dtm detach timeout periodの詳細は、Sybaseのドキュメントを参照してください。

Sybase Adaptive Serverでのトランザクションの動作

Sybaseサーバーでグローバル・トランザクションが開始されているが、完了していない場合、そのトランザクションの結果は、破棄される前のトランザクションの状態によって異なります。

- xa.end呼出しの前にクライアントが終了した場合、トランザクションはロールバックされます。

- xa.end呼出しの後にクライアントが終了した場合、トランザクションはデータベース・サーバー上に残ります(すべての関連するロックを保持します)。

- アプリケーションがxa.startを呼び出したが、xa.endをまだ呼び出していないときに不意に終了した場合は、データベース・サーバーが即座にトランザクションをロールバックし、トランザクションによって保持されていたロックを解放します。

- アプリケーションがxa.startおよびxa.endを呼び出して、アプリケーションが予期せず終了した場合、データベース・サーバーは、dtm detach timeout periodで指定した時間が経過した後でトランザクションをロールバックし、トランザクションによって保持されていたロックを解放します。「デタッチされたトランザクションに対するタイムアウトの設定」を参照してください。

- アプリケーションがxa.startおよびxa.endを呼び出し、トランザクションの準備が完了していたときに、アプリケーションが不意に終了した場合は、正常にリカバリできるようにトランザクションは存続します。トランザクション・マネージャはrollbackまたはcommitを呼び出し、トランザクションを完了する必要があります。

Javaクライアントの構成プロパティ

Javaクライアントを実行する場合の以下の構成プロパティを設定します。

表10-3 Sybase jConnect 5.5/XA Driver: Javaクライアント接続プロパティ

プロパティ名

プロパティ値

ds.setPassword

<password>

ds.setUser

<username>

ds.setNetworkProtocol

Tds

ds.setDatabaseName

<database-name>

ds.setResourceManagerName

<Lrm name in xa_config file>

ds.setResourceManagerType

2

ds.setServerName

<machine host name>

ds.setPortNumber

port (通常は4100)

Sybase jConnect 5.5および6.0/XAの確認済みの問題

次に、既知の問題とOracleの回避策を示します。

表10-4 Sybase jConnect 5.5および6.0の既知の問題と回避策

説明

Sybaseのバグ

コメント/WebLogic Serverの回避策

setAutoCommit (true)を呼び出すと次の例外がスローされます。

java.sql.SQLException: JZ0S3: The inherited method setAutoCommit(true)
cannot be used in this subclass.

10726192

回避策はありません。jConnect 6.0でベンダーにより修正済みです。

分散トランザクションでドライバを使用する場合、XAResource.end(TMSUSPEND)に続けてXAResource.end(TMSUCCESS)を呼び出すと、XAER_RMERRになります。

10727617

WebLogic Serverでは、このバグに対する内部的な回避策を提供しています。

データ・ソースの接続プールのプロパティをXAEndOnlyOnce="true"に設定します。

ベンダーによる修正がリクエストされています。

その他のXAドライバの使い方

その他のXA準拠JDBCドライバを使用するためには、ドライバ・クラス・ライブラリのパスをCLASSPATHで指定した上で、ベンダーの説明に従って操作を行う必要があります。

11 WebLogic Serverトランザクション・マネージャでのXAResourceの調整

この章では、外部のサード・パーティのシステムが、WebLogic Serverトランザクション・マネージャにjavax.transaction.xa.XAResource実装を登録することによって、WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加する方法について説明します。WebLogic Serverトランザクション・マネージャは、2フェーズ・コミット(2PC)プロトコルの一部としてXAResourceを駆動します。これを、「トランザクションのエクスポート」と言います。

サード・パーティ・トランザクション・マネージャがXAResourceインタフェースを実装している場合、トランザクションをエクスポートすることによって、サード・パーティ・トランザクション・マネージャとWebLogic Serverトランザクション・マネージャを統合できます。エクスポートしたトランザクションによって、サード・パーティ・トランザクション・マネージャは、WebLogic Serverトランザクション・マネージャの従属トランザクション・マネージャとして機能できます。

WebLogic Serverも、サード・パーティ・システム(外部トランザクション・マネージャとも呼ばれます)が調整する分散トランザクションに参加できます。WebLogic Serverの処理は、外部トランザクションの処理の一部として行われます。サード・パーティ・トランザクション・マネージャは、コミット処理の一部としてWebLogic Serverのトランザクション・マネージャを駆動します。これは、トランザクションのインポートと呼ばれます。

トランザクションにおけるサード・パーティ・システムの調整(トランザクションのエクスポート)の詳細は、以下の節で説明します。サード・パーティ・システムによって調整されるトランザクションへの参加(トランザクションのインポート)の詳細は、第12章「サード・パーティ・トランザクション・マネージャによって管理されるトランザクションへの参加」を参照してください。WebLogic Server IIOP、WebLogic Tuxedo Connector (WTC)ゲートウェイ、およびOracle Java Adapter for Mainframe (JAM)ゲートウェイでは、これらの章で説明しているものと同じメカニズムを内部的に使用して、WebLogic Serverでのトランザクションのインポートおよびエクスポートを行います。

以下の節では、サード・パーティ・システムを構成して、WebLogic Serverトランザクション・マネージャが調整するトランザクションに参加する方法について説明します。

- 外部XAResourceと分散トランザクションの調整の概要

- XAResourceのトランザクションへの参加の登録

- トランザクションにおけるXAResourceの登録と登録解除

- コミット処理

- リカバリ

- リソース・ヘルス監視

- Java EEコネクタ・アーキテクチャのリソース・アダプタ

- 実装のヒント

- リソース登録名の変更点

- FAQ

- JTAに関するその他のドキュメント

外部XAResourceと分散トランザクションの調整の概要

WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加するには、サード・パーティのシステムでjavax.transaction.xa.XAResourceインタフェースを実装し、そのXAResourceオブジェクトをWebLogic Serverトランザクション・マネージャに登録する必要があります。javax.transaction.xa.XAResourceインタフェースの実装に関する詳細については、次の場所でJava Platform Enterprise Edition, v 5.0 API仕様を参照してください:

http://download.oracle.com/javaee/5/api/javax/transaction/xa/XAResource.html

トランザクション処理時は、サード・パーティ・システムのXAResourceオブジェクトを適切な各トランザクション・オブジェクトに登録する必要があります。

図11-1は、WebLogic Serverトランザクション・マネージャが調整するトランザクションにサード・パーティ・システムが参加するプロセスを示したものです。

図11-1 サード・パーティ参加者と分散トランザクション

「図11-1 サード・パーティ参加者と分散トランザクション」の説明

XAResourceオブジェクトをトランザクションに登録する際に使用する登録モードに応じて、WebLogic Serverは、適切な時にXAResourceオブジェクトを自動的に登録解除する場合があります。登録および登録解除の詳細は、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。XAResourceオブジェクトをWebLogic Serverトランザクション・マネージャで登録する処理の詳細については、「XAResourceのトランザクションへの参加の登録」を参照してください。

XAResourceのトランザクションへの参加の登録

WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加するには、サード・パーティのシステムでjavax.transaction.xa.XAResourceインタフェースを実装し、そのXAResourceオブジェクトをWebLogic Serverトランザクション・マネージャに登録する必要があります。以下の処理のために登録が必要となります。

- XAResourceのトランザクション・ブランチ修飾子の指定。ブランチ修飾子はリソース・マネージャ・インスタンスのトランザクション・ブランチを識別し、リソース・マネージャ(RM)インスタンスが参加するすべての分散トランザクションに使用されます。各トランザクション・ブランチは分散トランザクションの処理の1単位を表し、他のブランチとは分離しています。各トランザクション・ブランチは、2フェーズ・コミット(2PC)処理時に、準備とコミットの呼出しのセットを1つだけ受け取ります。WebLogic Serverトランザクション・マネージャは、トランザクション・ブランチ修飾子としてリソース名を使用します。
リソース・マネージャ・インスタンスはXAResource.isSameRMメソッドによって定義されます。同じリソース・マネージャ・インスタンスに属するXAResourceインスタンスは、isSameRMに対してtrueを返すことになります。トランザクション・ブランチの混乱を避けるために、同じリソース・マネージャ・インスタンスを異なるリソース名(異なるリソース・ブランチ)で登録しないでください。

- 登録モードの指定。リソース・マネージャ・インスタンスが特定の分散トランザクションに参加するには、XAResourceインスタンスをJTA javax.transaction.Transactionオブジェクトに登録する必要があります。WebLogic Serverのトランザクション・マネージャでは、静的、動的、およびオブジェクト指向の3つの登録モードが用意されています。登録モードの詳細は、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。

- WebLogic Serverトランザクション・マネージャがクラッシュのリカバリを行う必要がある場合、XAResourceをブートストラップします。(JTA仕様は、それを行う標準APIを定義していません。http://www.oracle.com/technetwork/java/javaee/jta/index.htmlの「Java Transaction API」を参照してください)。
Java Transaction APIでは、ブランチ修飾子の割当てはトランザクション・マネージャで行うことが推奨されます。ただし、適切にリカバリを行うには、正常な処理時とクラッシュ・リカバリ時の両方において、同じトランザクション・ブランチ修飾子が提供される必要があります。トランザクション・ブランチ修飾子が登録時に指定されるため、WebLogic Serverトランザクション・マネージャでの登録が、クラッシュのリカバリと正常なトランザクション処理をサポートするために必要となります。

リカバリ時に、WebLogic Serverトランザクション・マネージャは以下のタスクを行います。

- トランザクション・マネージャのトランザクション・ログ・レコードと、記録されている分散トランザクションに参加したXAリソースのログ・レコードの読み込み、および2PCプロトコルの第2フェーズの続行と指定したブランチ修飾子のXAリソースのコミット。

- XAResource.recoverを呼び出すことによる、XAリソースのすべての不明なトランザクションの解決。続いて、これに属する返されたトランザクション(Xids)のコミットまたはロールバック。(返されたXidは、すでに特定のブランチ修飾子を持っている場合があります。)

注意:

ここで述べる登録はプロセスごとの処理です(トランザクションごとの登録および登録解除とは異なります)。

XAResource実装をWebLogic Serverトランザクション・マネージャに登録しないと、予期しないトランザクション・ブランチ動作を引き起こす可能性があります。XAリソースがWebLogic Server分散トランザクションに登録される前にこの登録を行わないと、WebLogic Serverトランザクション・マネージャはリソース名(ブランチ修飾子)としてXAResourceインスタンスのクラス名を使用します。これによって、望ましくないリソース名やトランザクション・ブランチの競合が発生する可能性があります。

各リソース・マネージャ・インスタンスが、自身を一度だけWebLogic Serverトランザクション・マネージャに登録するようにしてください。各リソース・マネージャ・インスタンスは登録時にリソース名によって識別されるので、リカバリ、コミット処理、およびヘルス監視時にシステムに過大なオーバーヘッドが加わり、関連する内部データ構造によって使用されるメモリーが増加し、内部マップの検索効率が低下します。したがって、スケーラビリティおよびパフォーマンスの理由から、異なるトランザクション・ブランチでXAResourceインスタンスをむやみに登録しないようにする必要があります。

JTA XAResourceでは明示的なトランザクション・モデルが採用されています。このモデルでは、Xidが常にXAResourceメソッドで明示的に渡され、1つのリソース・マネージャ・インスタンスがすべてのトランザクションを処理します。これは、暗黙的なトランザクション・モデルが採用されているCORBA OTSリソースと対照的です。このモデルでは、参加対象の各トランザクションに対して異なるOTSリソース・インスタンスが存在します。XAResourceを設計する際は、JTAモデルを使用する必要があります。

各外部リソース・マネージャ・インスタンスは、サーバーの起動時にWebLogic Serverトランザクション・マネージャにXAResourceインスタンスを登録する必要があります。WebLogic Serverでは、起動クラスを使用して、外部トランザクション・マネージャを登録できます。

WebLogic Serverトランザクション・マネージャにリソース・マネージャを登録する手順は次のとおりです。

1. JNDIまたはTxHelperインタフェースを使用して、WebLogic Serverトランザクション・マネージャを取得します。

import javax.transaction.xa.XAResource;
import weblogic.transaction.TransactionManager;
import weblogic.transaction.TxHelper;
InitialContext initCtx = ... ; // initialized to the initial context
TransactionManager tm = TxHelper.getTransactionManager();

または

TransactionManager tm = (TransactionManager)initCtx.lookup("weblogic.transaction.TransactionManager");

または

TransactionManager tm = (TransactionManager)initCtx.lookup("javax.transaction.TransactionManager");

2. WebLogic Serverトランザクション・マネージャにXAリソース・インスタンスを登録します。

String name = ... ; // name of the RM instance
XAResource res = ... ; // an XAResource instance of the RM instance
tm.registerResource(name, res); // register a resource with the standard enlistment mode

または

tm.registerDynamicResource(name, res); // register a resource with the dynamic enlistment mode

または

tm.registerStaticResource(name, res); // register a resource with the static enlistment mode

さまざまな登録モードの詳細については、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。XAResourceの登録時に以降に使用される登録モードを指定しますが、その登録プロセスの間に実際にリソースを登録しているわけではありません。実際の登録は、(サーバー起動時ではなく)トランザクションで別のAPIを使用して行う必要があります。詳細については、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。

登録する各XAResourceインスタンスは、複数のトランザクションのリカバリおよびコミット処理に並列的に使用されます。JTA仕様バージョン1.0.1Bのセクション3.4.6で定義されているリソース共有をXAResourceインスタンスがサポートしていることを確認してください。

注意:

同じXAResourceの重複登録は無視されます。

リソースで新しいリクエストを受け付けなくなったら、WebLogic Serverトランザクション・マネージャからXAResourceの登録を解除する必要があります。XAResourceの登録を解除するには、次のメソッドを使用します。

tm.unregisterResource(name, res);

トランザクションにおけるXAResourceの登録と登録解除

XAResourceが分散トランザクションに参加するには、XAResourceインスタンスがトランザクション・オブジェクトに登録される必要があります。登録モードに応じて、異なる処理を実行する必要がある場合があります。WebLogic Serverトランザクション・マネージャでは、以下の登録モードがサポートされています。

- 標準的な登録

- 動的な登録

- 静的な登録

XAResourceはトランザクション・オブジェクトに登録しますが、登録モードが決定するのは、リソースをトランザクションに登録するときではなく、WebLogic Serverトランザクション・マネージャにXAResourceを登録するときです。「XAResourceのトランザクションへの参加の登録」を参照してください。

XAResource.startおよびendの呼出しは、コストがかかる場合があります。WebLogic Serverトランザクション・マネージャでは、これらの呼出しの数を最小化するために以下の最適化方法が提供されています。

- 遅延登録解除
WebLogic Serverトランザクション・マネージャはXAResource実装が明示的な登録解除を行うかどうかに関わらず、XAResourceが登録解除される以下のイベントが発生する直前までは、現在のトランザクションに登録されているすべてのXAResourceインスタンスの登録解除を常に遅延します。

- 呼出しが正常に、または例外として呼出し側に返されます。

- 別のサーバーが呼び出されます。

- 重複登録の無視
WebLogic Serverトランザクション・マネージャは、すでに登録されているXAResourceの明示的な登録をすべて無視します。これは、XAResourceが明示的に登録解除され(前述のようにWebLogic Serverトランザクション・マネージャによって遅延または無視され)、同じ呼出しの間の中で続いて再登録されている場合に起こることがあります。

WebLogic Serverトランザクション・マネージャではデフォルトで、TMSUSPENDフラグが指定されたXAResource.endを呼び出すことによってXAResourceを登録解除します。TMSUSPENDが指定されたXAResource.endが呼び出されると、カーソルが開いたままになるデータベース管理システムもあるので、可能なかぎり、TMSUCCESSを指定したXAResource.endを呼び出してXAResourceを登録解除するようにしてください。これを行うには、javax.transaction.xa.XAResourceのかわりにgetDelistFlagメソッドが含まれるweblogic.transaction.XAResourceインタフェースを実装します。詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.XAResourceを参照してください。

標準的な登録

標準的な登録モードでは、トランザクション・オブジェクトにXAResourceインスタンスを登録するのは一度だけです。また、同じトランザクションに同じブランチのXAResourceインスタンスを2つ以上登録することもできます。WebLogic Serverトランザクション・マネージャでは、すべてのXAResourceインスタンスに対して適切な場合にXAResource.endが呼び出されます(次の説明を参照)。WebLogic Serverトランザクション・マネージャでは、トランザクションのコミット時に、各ブランチが準備とコミットの呼出しのセットを1つだけ受け取ります。ただし、登録済の特定のXAResourceインスタンスの登録は無視されます。

標準的な登録では登録が簡素化されますが、特定のメソッド呼出しの間の中でリソースが全くアクセスされない場合には、XAResourceの不必要な登録および登録解除が生じる可能性もあります。

トランザクション・オブジェクトにXAResourceを登録するには、以下の手順に従います。

1. TransactionHelperインタフェースを使用して現在のトランザクション・オブジェクトを取得します。

import weblogic.transaction.Transaction; // extends javax.transaction.Transaction
import weblogic.transaction.TransactionHelper;
Transaction tx = TransactionHelper.getTransaction();

2. トランザクション・オブジェクトにXAResourceインスタンスを登録します。

tx.enlistResource(res);

XAResourceをトランザクションに登録すると、WebLogic Serverトランザクション・マネージャによって、以降のすべての登録解除(「トランザクションにおけるXAResourceの登録と登録解除」を参照)および再登録が管理されます。標準的な登録モードでは、WebLogic Serverトランザクション・マネージャは、以下の場合に同じトランザクションでXAResourceを再登録します。

- リクエストが実行される前

- 別のサーバーから応答が受信された後(WebLogic Serverトランザクション・マネージャは、別のサーバーにリクエストを送信する前にXAResourceを登録解除します)。

動的な登録

動的な登録モードでは、リソースの各アクセス前にトランザクション・オブジェクトにXAResourceインスタンスを登録する必要があります。この登録モードでは、各トランザクションに一度に登録できるXAResourceインスタンスは、各トランザクション・ブランチから1つのみです。WebLogic Serverトランザクション・マネージャは、最初のインスタンスが登録されてから登録解除されるまでの間、同じトランザクション・ブランチの別のXAResourceインスタンスの登録を無視します。

動的な登録では、XAResourceインスタンスの登録と登録解除は最小限に抑えられます。

XAResourceを登録する手順は、「標準的な登録」で説明した手順と同じです。

静的な登録

静的な登録モードでは、トランザクション・オブジェクトにXAResourceインスタンスを登録する必要はありません。XAResourceは、以下のイベントの際にWebLogic Serverトランザクション・マネージャによって、すべてのトランザクションについて暗黙的に登録されます。

- リクエストが実行される前

- 別のサーバーから応答が受信された後

注意:

静的な登録モードを使用する前に以下の点を考慮する必要があります。

- 静的な登録モードではXAResourceを登録する必要がありません。ただし、リソースが特定のトランザクションで使用されない場合、不必要な登録および登録解除に繋がる可能性があります。

- リソースがトランザクションで使用されない場合でも、問題のあるXAResourceによって、すべてのトランザクションが悪影響を受ける可能性があります。

- 1つのXAResourceインスタンスを使用して異なるトランザクションとスレッドを一度に関連付けます。つまり、複数のスレッドの異なるXidについて、同じXAResourceインスタンス上でXAResource.startおよびXAResource.endを交互に呼び出すことができます。XAResourceがこのような関連付けパターンをサポートするようにする必要があります。これはJTA仕様では要求されていません。

静的な登録には、パフォーマンスに対するオーバーヘッド、アイソレーションの問題、およびトランザクション関連付け要件が厳しいという理由があるため、十分に検討した上で慎重に使用する必要があります。

コミット処理

コミット処理の間、WebLogic Serverトランザクション・マネージャは、2フェーズ・コミットを行うため、トランザクション・マネージャに登録されているXAResourceインスタンスか、トランザクションに現在登録されているXAResourceインスタンスのいずれかを使用します。WebLogic Serverトランザクション・マネージャでは、各トランザクション・ブランチが準備とコミットの呼出しのセットを1つだけ受け取ります。JTA仕様バージョン1.0.1Bのセクション3.4.6で定義されているように、様々なスレッドから同時に複数のトランザクションのコミット処理を行うために、どのようなXAResourceインスタンスも使用できるようにする必要があります。

リカバリ

WebLogic Serverサーバーが再起動されると、WebLogic Serverトランザクション・マネージャは自身のトランザクション・ログ(正常に準備されたが、2PC処理の第2コミット・フェーズを終了していない可能性のあるトランザクションのログ・レコード)を読み込みます。WebLogic Serverトランザクション・マネージャは次に、これらのトランザクションのXAResourceのコミットの再試行を続行します。「XAResourceのトランザクションへの参加の登録」で説明したように、WebLogic Serverトランザクション・マネージャのリソース登録APIは、リカバリを目的としたXAResourceインスタンスのブート・ストラップにも使用されます。サーバーの再起動時にXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されていることを確認する必要があります。WebLogic Serverトランザクション・マネージャは、有効なXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されるまで、コミット呼出しを毎分再試行します。

トランザクション・コーディネータとして機能しているトランザクション・マネージャがクラッシュすると、コーディネータのトランザクション・ログにいくつかの不明なトランザクションが記録されないこともあります。したがって、コーディネータではサーバーの再起動時に、リソース・マネージャに対してXAResource.recoverを呼び出し、記録されなかった不明なトランザクションをロールバックする必要があります。コミットの再試行と同様に、WebLogic Serverトランザクション・マネージャは、有効なXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されるまで、5分間隔でXAResource.recoverを再試行します。

WebLogic Serverトランザクション・マネージャは、新しいXAResourceが最初にWebLogic Serverトランザクション・マネージャに登録される際、トランザクション・ログ・レコードにそのチェックポイントを記録します。サーバーの再起動時に、WebLogic Serverトランザクション・マネージャは、前にチェックポイントが記録され(トランザクション終了後にトランザクション・ログ・レコードから削除され)たすべてのリソースに対してXAResource.recoverを呼び出します。リソースがチェックポイント記録から削除されるのは、最後のPurgeResourceFromCheckpointIntervalSeconds間隔(デフォルトは24時間)にアクセスされていない場合のみです。したがって、リソース・リカバリのオーバーヘッドを軽減するには、WebLogic Serverトランザクション・マネージャに登録されているリソース・マネージャ・インスタンスの数を最小限にする必要があります。

XAResource.recoverを実装する際は、以下に示すX/Open XA仕様で説明されているようにフラグを使用する必要があります。

- WebLogic Serverトランザクション・マネージャで、TMSTARTRSCANが指定されたXAResource.recoverを呼び出すと、不明Xidの最初のバッチがリソースによって返されます。
WebLogic Serverトランザクション・マネージャでは次に、リカバリすべきXidがこれ以上ないことを示すnullまたは長さゼロの配列のいずれかがリソースによって返されるまで、TMNOFLAGSが指定されたXAResource.recoverの呼出しを繰返し行います。前のXAResource.recover(TMSTARTRSCAN)呼出しですべてのXidがリソースによってすでに返されている場合、ここでnullまたは長さゼロの配列が返されるか、前のリカバリ・スキャンがすでに終了および削除されたことを示すXAER_PROTOがスローされることもあります。XAResource.recover実装の一般的な問題は、フラグが無視されることや、XAResource.recover(TMNOFLAGS)に対して常に同じXidのセットが返されることです。これによって、WebLogic Serverトランザクション・マネージャのリカバリが無限ループに陥り、後の失敗が引き起こされます。

- WebLogic Serverトランザクション・マネージャでTMENDRSCANフラグが指定されたXAResource.recoverを呼び出すと、リカバリ・スキャンが終了します。追加のXidがリソースによって返される場合があります。

リソース・ヘルス監視

問題のあるXAResourceに対してサーバー・スレッドを失わないように、WebLogic Server JTAには内部リソース・ヘルス監視のメカニズムがあります。リソースがアクティブであると見なされるのは、保留中のリクエストが存在しない場合、またはXAResourceの保留中のリクエストの結果がXAER_RMFAILではない場合です。XAResourceが2分以内にアクティブにならない場合、WebLogic Serverトランザクション・マネージャはXAResourceを応答なしと宣言します。XAResourceに対する新たなリクエストは拒否され、XAER_RMFAIL XAExceptionがスローされます。

2分という間隔は、maxXACallMillis JTAMBean属性を介して構成できます。これは管理コンソールでは公開されていません。maxXACallMillisは、config.xmlファイル内で構成できます。例:

<Domain>
....
<JTA
MaxXACallMillis="240000"
/>
....
</Domain>

WebLogic Serverトランザクション・マネージャから通知を受信し、リソースが応答なしと宣言されようとしている際に、本当に応答なしかどうかをWebLogic Serverトランザクション・マネージャに通知するには、weblogic.transaction.XAResource(javax.transaction.xa.XAResourceを拡張)を実装し、これをトランザクション・マネージャに登録します。トランザクション・マネージャは、XAResourceが利用できないことを宣言しようとする際に、そのdetectUnavailableメソッドを呼び出します。XAResourceからtrueが返されると、利用できないと宣言されることはありません。XAResourceが本当に利用できない場合には、この機会にクリーンアップおよびトランザクション・マネージャへの再登録を行うこともできます。詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.XAResourceを参照してください。

Java EEコネクタ・アーキテクチャのリソース・アダプタ

WebLogic Serverトランザクション・マネージャに直接登録する他に、Java EEコネクタ・アーキテクチャのリソース・アダプタ・インタフェースを実装することもできます。リソース・アダプタをデプロイする際、リソース・マネージャのXAResourceは、WebLogic Server Java EEコンテナによってWebLogic Serverトランザクション・マネージャに自動的に登録されます。

詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』を参照してください。

実装のヒント

以下の節では、WebLogic Serverトランザクション・マネージャでのトランザクションのエクスポートとインポートのヒントについて説明します。

- WebLogic Serverトランザクション・ログの共有

- トランザクションのグローバル・プロパティ

- TxHelper.createXid

WebLogic Serverトランザクション・ログの共有

WebLogic Serverトランザクション・マネージャは、ゲートウェイなどのシステム・アプリケーションで共有されるようにトランザクション・ログを公開します。これによって、高速ロギングのためにWebLogic Serverトランザクション・マネージャの一括(バッチ)処理のトランザクション・ログ最適化をシステム・アプリケーションで利用できます。トランザクション・ログ・レコードは適時に解放することが重要となります(WebLogic Serverトランザクション・マネージャは、トランザクション・ログ・ファイル内のすべての記録が解放された場合にのみトランザクション・ログ・ファイルを削除します)。これができないと、トランザクション・ログ・ファイルが多数作成され、コミット済みのトランザクションの多くが再コミットされ、極端なケースでは、循環衝突やトランザクション・ログ・ファイルの上書きが発生する可能性があります。

WebLogic Serverトランザクション・マネージャは、トランザクション・ログ機能インタフェースweblogic.transaction.TransactionLoggerを公開しています。これはサーバー上でのみ使用でき、以下の手順で取得できます。

1. サーバー・トランザクション・マネージャを取得します。

import weblogic.transaction.ServerTransactionManager;
import weblogic.transaction.TxHelper;
ServerTransactionManager stm = (ServerTransactionManager)TxHelper.getTransactionManager();

2. TransactionLoggerを取得します。

TransactionLogger tlog = stm.getTransactionLogger();

XAResourceのログ・レコードは、トランザクション・ログに記録されるために、weblogic.transaction.TransactionLoggableインタフェースを実装する必要があります。weblogic.transaction.TransactionLoggerインタフェース、およびTransactionLoggerインタフェースの用途に関する詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.TransactionLoggerを参照してください。

トランザクションのグローバル・プロパティ

WebLogic Server JTAトランザクション・オブジェクトは、ローカルおよびグローバルのプロパティに関連付けられます。グローバル・プロパティは、トランザクション伝播コンテキストでサーバー間を伝播され、トランザクション・ログにログ・レコードの一部としても保存されます。トランザクションのグローバル・プロパティにアクセスするには、以下の手順に従います。

1. トランザクション・オブジェクトを取得します。

import weblogic.transaction.Transaction;
import weblogic.transaction.TransactionHelper;
Transaction tx = TransactionHelper.getTransaction();  // Get the transaction associated with the thread

または

Transaction tx = TxHelper.getTransaction(xid); // Get the transaction with the given Xid

2. トランザクション・オブジェクトのプロパティを取得または設定します。

tx.setProperty("foo", "fooValue");
tx.getProperty("bar");

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.TxHelperを参照してください。

TxHelper.createXid

TxHelper.createXid(int formatId, byte[] gtrid, byte[] bqual)メソッドを使用するとXidを作成できます。作成したXidは、たとえば、リカバリ時にWebLogic Serverトランザクション・マネージャに返すことができます。

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.TxHelperを参照してください。

リソース登録名の変更点

このリリースでは、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。

JTAに登録されたすべてのリソースには、対応する実行時MBeanが存在し、MBeanを通じてそのリソースのXA使用状況の統計が公開されます。今回の変更により、MBeanのJMX ObjectNameが変わる(修飾される)ため、既存のアプリケーションでそのような実行時MBeanのJMXルックアップを名前に基づいて実行している場合は、何らかの影響を受ける可能性があります。旧リリースでは、ドメインmydomainのmydatasourceという名前を持つデータ・ソース構成の場合、JTAリソースの実行時MBeanは、次のようなオブジェクト名で登録されていました。

com.bea:ServerRuntime=myserver,Name=mydatasource,Type=TransactionResourceRuntime,JTARuntime=JTARuntime

このリリースでは、次のように修飾されたオブジェクト名が使用されます。

com.bea:ServerRuntime=myserver,Name=mydatasource_mydomain,Type=TransactionResourceRuntime,JTARuntime=JTARuntime

トランザクション・ブランチ修飾子は、JTAリソース登録名からも派生します。そのため、アップグレード時に存在するXAデータ・ソースの保留トランザクション・ブランチは、アップグレード後にリカバリできないことがあります。アップグレードは、データベース・リソースに保留トランザクションが残っていない状態で実行することをお薦めします。保留データベース・トランザクションが残っていると、場合によってはデータベース管理者がそれらを手動で解消することが必要になります。次を参照

このリリースでは、登録名の修飾を無効にするための次のようなシステム・プロパティが新たに使用できるようになりました。

-Dweblogic.jdbc.qualifyRMName=false

FAQ

- XAResourceのXidにはブランチ修飾子があるのに、トランザクション・マネージャのトランザクションにブランチ修飾子がないのはなぜですか。
WebLogic Server JTAトランザクション・オブジェクトはブランチ修飾子は持ちません(すなわち、TxHelper.getTransaction().getXid().getBranchQualifier()はnullになります)。ブランチ修飾子は個々のリソース・マネージャに固有のため、WebLogic Serverトランザクション・マネージャは、XAResourceメソッドに渡されるXidでのみブランチ修飾子を設定します。

- TxHelper.getTransaction()メソッドの使用目的は何ですか。
WebLogic Server JTAでは、現在のスレッドに関連付けられたトランザクションを返すために、TxHelper.getTransaction() APIが提供されています。ただし、WebLogic Server JTAは、XAResourceメソッドを呼び出す前にトランザクション・コンテキストをサスペンドするので、トランザクションを識別するために信頼できるのは、現在のスレッドに関連付けられたトランザクションではなく、Xid入力パラメータのみです。

JTAに関するその他のドキュメント

接続ベースのリソース使用のシナリオについては、JTA仕様1.0.1Bのセクション4.1を参照してください。トランザクション・マネージャとリソース・マネージャの間のJTA対話について説明されています。JTA仕様はhttp://www.oracle.com/technetwork/java/javaee/jta/index.htmlにあります。

12 サード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加

この章では、WebLogic Serverが、サード・パーティ・システム(外部トランザクション・マネージャと呼ばれる)が調整する分散トランザクションに参加する方法を説明します。WebLogic Serverの処理は、外部トランザクションの処理の一部として行われます。外部トランザクション・マネージャは、コミット処理の一部としてWebLogic Serverのトランザクション・マネージャを駆動します。これを、WebLogic Serverへのトランザクションの「インポート」と言います。

以下の節では、外部管理トランザクションの構成および外部管理トランザクションへの参加のプロセスについて説明します。

- 外部管理トランザクションへの参加の概要

- クライアント介在トランザクション・マネージャでのトランザクションのインポート

- サーバー介在トランザクション・マネージャでのトランザクションのインポート

- インポート済みトランザクションのトランザクション処理

- インポート済みトランザクションのコミット処理

- インポート済みトランザクションのリカバリ

外部管理トランザクションへの参加の概要

WebLogic Serverのトランザクション・マネージャは、weblogic.transaction.InterposedTransactionManagerインタフェースを通じて、javax.transaction.xa.XAResource実装を公開します。外部トランザクション・マネージャは、InterposedTransactionManagerインタフェースにアクセスして、コミット処理時にWebLogic Serverトランザクション・マネージャのXAResourceを調整することができます。

外部トランザクション・マネージャのトランザクションをWebLogic Serverのトランザクション・マネージャにインポートする場合には、外部トランザクション・マネージャに従属マネージャとして、WebLogic Server介在トランザクション・マネージャを登録する必要があります。その結果、WebLogic Serverのトランザクション・マネージャは、インポートされたトランザクションの調整役としてWebLogic Server内で機能します。

WebLogic Serverでは、トランザクションのインポートに関して、次の2つの構成方式がサポートされています。

- クライアント介在トランザクション・マネージャを使用する、WebLogic Serverに外部的に実装されたクライアント側ゲートウェイの使用

- サーバー介在トランザクション・マネージャを使用する、WebLogic Serverインスタンスに実装されたサーバー側ゲートウェイの使用

実装の詳細および制限に関してはいくつかの違いがありますが、どちらの構成もトランザクションのインポートについての基本機能は同じです。

1. WebLogic Serverのトランザクション・マネージャをルックアップし、サード・パーティ・システムでの必要に基づいて、XAResourceとして登録します。

2. トランザクション処理時に適切なトランザクション参加者を登録および登録解除します。

3. 準備メッセージをWebLogic Serverのトランザクション・マネージャに送信します。このトランザクション・マネージャは、従属トランザクション・マネージャとして機能し、WebLogic Server内でトランザクション参加者の準備フェーズを調整します。

4. コミットまたはロールバック・メッセージをWebLogic Serverのトランザクション・マネージャに送信します。このトランザクション・マネージャは、従属トランザクション・マネージャとして機能し、WebLogic Server内でトランザクション参加者の2フェーズ・コミット・プロセスの第2フェーズを調整します。

5. 必要に応じて登録解除します。

クライアント介在トランザクション・マネージャでのトランザクションのインポート

WebLogic Serverでクライアント介在トランザクション・マネージャを使用して、サード・パーティのトランザクション・マネージャが調整するトランザクションに対して2フェーズ・コミット・プロセスを駆動し、WebLogic Server内にJMSリソースやJDBCリソースなどのトランザクション参加者を含めることができます。クライアント介在トランザクション・マネージャは、javax.transaction.xa.XAResourceインタフェースの実装です。クライアント介在トランザクション・マネージャには、サード・パーティ・アプリケーションから直接アクセスします。通常は、サード・パーティ・アプリケーションのゲートウェイからアクセスします。サード・パーティ・システムのトランザクション・マネージャは、準備メッセージおよびコミット・メッセージをゲートウェイに送信し、ゲートウェイがそのメッセージをWebLogic Serverトランザクション・マネージャに伝播します。そして、WebLogic Serverのトランザクション・マネージャが従属トランザクション・マネージャとして機能し、WebLogic Server内でトランザクション参加者を調整します。図12-1は、2つのトランザクション・マネージャとクライアント側ゲートウェイの間の対話を示したものです。

図12-1 クライアント側ゲートウェイを使用したWebLogic Serverへのトランザクションのインポート

「図12-1 クライアント側ゲートウェイを使用したWebLogic Serverへのトランザクションのインポート」の説明

図12-2は、外部トランザクション・マネージャ、WebLogic Serverクライアント側JTAオブジェクト、およびWebLogic Serverトランザクション・マネージャの間の対話フローを示したものです。

図12-2 クライアント介在トランザクション・マネージャを使用したトランザクションのインポート手順を示した状態図

「図12-2 クライアント介在トランザクション・マネージャを使用したトランザクションのインポート手順を示した状態図」の説明

クライアント側ゲートウェイを使用してWebLogic Serverの介在トランザクション・マネージャにアクセスするには、次の手順を行う必要があります。

- クライアント介在トランザクション・マネージャの取得

- 介在トランザクション・マネージャからのXAResourceの取得

クライアント介在トランザクション・マネージャの取得

クライアント側ゲートウェイにおいて、WebLogic Server介在トランザクション・マネージャのXAResourceをgetClientInterposedTransactionManagerメソッドで取得できます。例:

import javax.naming.Context;
import weblogic.transaction.InterposedTransactionManager;
import weblogic.transaction.TxHelper;
Context initialCtx;
String serverName;
InterposedTransactionManager itm = TxHelper.getClientInterposedTransactionManager(initialCtx, serverName);

サーバー名パラメータは、外部トランザクションに対して介在トランザクション・マネージャとして機能するサーバーの名前です。外部トランザクション・マネージャはクラッシュのリカバリ処理を行う際に、同じWebLogic Serverのサーバーに接続して、WebLogic Serverにインポート済の不明なトランザクションのリストを取得する必要があります。

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.TxHelperを参照してください。

介在トランザクション・マネージャからのXAResourceの取得

介在トランザクション・マネージャを取得したら、その介在トランザクション・マネージャに関連付けられたXAResourceオブジェクトを取得する必要があります。

import javax.transaction.xa.XAResource;
XAResource xar = itm.getXAResource();

クライアント介在トランザクション・マネージャの制限

クライアント側のゲートウェイを使用してトランザクションをインポートする際は、次の制限に注意してください。

- クライアント側のゲートウェイでは、TxHelper.getServerInterposedTransactionManager()メソッドを使用できません。

- 一度に使用できるWebLogic Serverクライアント介在トランザクション・マネージャは1つのみです。一度に2つ以上のクライアント介在トランザクション・マネージャ(異なるWebLogic Serverサーバーに接続している)を、トランザクションのインポートに使用しないでください。(この制限の詳細、およびWebLogic Server介在トランザクション・マネージャでのトランザクション処理の詳細については、「インポート済みトランザクションのトランザクション処理」を参照してください。)

サーバー介在トランザクション・マネージャでのトランザクションのインポート

WebLogic Serverでサーバー介在トランザクション・マネージャを使用して、サード・パーティのトランザクション・マネージャが調整するトランザクションに対して2フェーズ・コミット・プロセスを駆動し、WebLogic Server内にJMSリソースやJDBCリソースなどのトランザクション参加者を含めることができます。サーバー介在トランザクション・マネージャは、javax.transaction.xa.XAResourceインタフェースの実装です。WebLogic Serverにサーバー側のゲートウェイを作成して、サード・パーティ・システムからそのゲートウェイにアクセスして、サーバー介在トランザクション・マネージャにアクセスします。サード・パーティ・システムのトランザクション・マネージャから、準備メッセージおよびコミット・メッセージがサーバー側ゲートウェイに送信されます。それらのメッセージは、そのゲートウェイからWebLogic Serverトランザクション・マネージャに伝播します。そして、WebLogic Serverのトランザクション・マネージャが従属トランザクション・マネージャとして機能し、WebLogic Server内でトランザクション参加者を調整します。図12-3は、2つのトランザクション・マネージャとサーバー側ゲートウェイの間の対話を示したものです。

図12-3 サーバー側ゲートウェイを使用したWebLogic Serverへのトランザクションのインポート

「図12-3 サーバー側ゲートウェイを使用したWebLogic Serverへのトランザクションのインポート」の説明

サーバー側ゲートウェイを使用してWebLogic Serverの介在トランザクション・マネージャにアクセスするには、次の手順を行う必要があります。

- サーバー介在トランザクション・マネージャの取得

- 介在トランザクション・マネージャからのXAResourceの取得

サーバー介在トランザクション・マネージャの取得

サーバー側ゲートウェイにおいて、介在トランザクション・マネージャのXAResourceを次のようにして取得できます。

import javax.naming.Context;
import weblogic.transaction.InterposedTransactionManager;
import weblogic.transaction.TxHelper;
InterposedTransactionManager itm = TxHelper.getServerInterposedTransactionManager();

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.TxHelperを参照してください。

介在トランザクション・マネージャを取得したら、XAResourceを取得する必要があります。「介在トランザクション・マネージャからのXAResourceの取得」を参照してください。

サーバー介在トランザクション・マネージャの制限

サーバー側のゲートウェイを使用してトランザクションをインポートする際は、次の制限に注意してください。

- WebLogic Serverサーバーのサーバー側ゲートウェイでは、TxHelper.getClientInterposedTransactionManager()メソッドを使用しません。このメソッドを使用すると、パフォーマンスの問題が発生します。

- 一度に使用できるWebLogic Serverサーバー介在トランザクション・マネージャは1つのみです。一度に2つ以上のサーバー介在トランザクション・マネージャ(同じスレッドにある)を、トランザクションのインポートに使用しないでください。(この制限の詳細、およびWebLogic Server介在トランザクション・マネージャでのトランザクション処理の詳細については、「インポート済みトランザクションのトランザクション処理」を参照してください。)

インポート済みトランザクションのトランザクション処理

外部トランザクションをWebLogic Serverにインポートするには、外部トランザクション・マネージャまたはゲートウェイで、次の操作を行います。

xar.start(foreignXid, TMNOFLAGS);

この操作によって、現在のスレッドとインポート済トランザクションが関連付けられます。トランザクションとスレッドの関連付けが解除されるまで、他のサーバーに対する以降のすべての呼出しで、インポート済WebLogic Serverトランザクションが伝播されます。

注意:

WebLogic Serverトランザクション・マネージャでは、フラグが無視されます。外部Xidが同じWebLogic Serverサーバーにインポート済の場合、WebLogic Serverは現在のスレッドをインポート済のWebLogic Serverトランザクションに関連付けます。

インポート済みのトランザクションと現在のスレッドの関連付けを解除するには、外部トランザクション・マネージャまたはゲートウェイで次の操作を行う必要があります。

xar.end(foreignXid, TMSUCCESS);

WebLogic Serverのトランザクション・マネージャがフラグを無視することに注意してください。

インポート済みトランザクションのトランザクション処理の制限

インポート済みのトランザクションに関して、次の処理の制限と動作に注意してください。

- WebLogic Serverトランザクションが開始されたら、ゲートウェイでは同じスレッド上でstartを再び呼び出すことができません。クライアント側ゲートウェイで、1つのクライアント介在トランザクション・マネージャで一度に呼び出すことができるのは、xar.startのみです。別のクライアント介在トランザクション・マネージャで(最初のトランザクション・マネージャでxar.endを呼び出す前に)、xar.startを呼び出そうとすると、XAER_RMERRのXAExceptionがスローされます。サーバー側ゲートウェイを使用して、クライアントまたはサーバー介在トランザクション・マネージャでxar.startを呼び出そうとすると、現在のスレッドにすでにアクティブなトランザクションが関連付けられている場合、XAER_RMERRのXAExceptionがスローされます。

- WebLogic Server介在トランザクション・マネージャのXAResourceは、異なるWebLogic Serverサーバー上で、疎結合のトランザクション・ブランチ動作を示します。つまり、同じ外部Xidが異なるWebLogic Serverサーバーにおいてインポートされると、異なるWebLogic Serverトランザクションにインポートされます。

- WebLogic Serverのトランザクション・マネージャは、トランザクション・ツリーをフラット化しません。たとえば、前にエクスポートしたWebLogic Serverトランザクションのインポート済トランザクションは、元のWebLogic Serverトランザクションとは別のブランチに配置されます。

- 外部トランザクション・マネージャでは、WebLogic Serverにインポートされるすべての外部Xidが一意で、トランザクション破棄タイムアウト期間およびトランザクションのタイムアウト期間の合計値内で再利用されていないことを確認する必要があります。これができないと、ログ・レコードがWebLogic Serverトランザクション・マネージャで解放されなくなることがあります。その結果、クラッシュのリカバリが効率的に行われないおそれがあります。

インポート済みトランザクションのコミット処理

外部トランザクション・マネージャは、他のXAResourceを駆動するように、2PCプロトコルにおいて介在トランザクション・マネージャを駆動する必要があります。WebLogic Server JTA (EJBコンテナなど)に登録されたbeforeCompletionコールバックは、外部トランザクション・マネージャが介在トランザクション・マネージャのXAResourceを準備する際に呼び出されることに注意してください。afterCompletionコールバックは、XAResource.commitまたはXAResource.rollbackの間に呼び出されます。

WebLogic Server介在トランザクション・マネージャは、http://www.oracle.com/technetwork/java/javaee/jta/index.htmlの「Java Transaction API」に記載されているXAResource規約に準拠しています。

- WebLogic Server介在トランザクション・マネージャは、外部トランザクション・マネージャによって準備されると、トランザクション破棄タイムアウトが経過するまで、外部トランザクション・マネージャからのコミットまたはロールバックを永続的に待機します。

- WebLogic Server介在トランザクション・マネージャは、外部トランザクション・マネージャからトランザクションを無視するように指示されるか、トランザクション破棄タイムアウトが経過するまで、ヒューリスティックな出力を永続的に記憶します。

WebLogic Serverトランザクション・マネージャは、WebLogic Serverのすべての参加者の準備が正常に行われると、インポート済のトランザクションについて、prepareレコードを記録します。インポート済のトランザクションについてWebLogic Serverの参加者が2つ以上ある場合、トランザクション・マネージャはXAResource.commitが1フェーズ・コミットでもprepareレコードを記録します。

インポート済みトランザクションのリカバリ

外部トランザクション・マネージャのクラッシュのリカバリの間、外部トランザクション・マネージャは、WebLogic Server介在トランザクション・マネージャのXAResourceを再び取得し、これに対してrecoverを呼び出す必要があります。WebLogic Server介在トランザクション・マネージャは、準備されたトランザクションまたはヒューリスティックに終了したトランザクションのリストを返します。外部トランザクション・マネージャでは、準備されたトランザクションをコミットまたはロールバックするか、ヒューリスティックに終了したトランザクションに対してforgetを呼び出すかのいずれかの方法で、これらの不明なトランザクションを解決する必要があります。

13 トランザクションのトラブルシューティング

この章では、トランザクション失敗の原因を突き止めたり、問題修正の手段を決定したりするためのトラブルシューティング・ツールおよびタスクについて説明します。

この章では、以下のトピックについて説明します。

- 概要

- トラブルシューティング・ツール

概要

WebLogic Serverでは、実行中のトランザクションをモニターし、ヒューリスティックな終了のケースで適切な情報を確実に取り込むことができます。また、データベース問合せ、トランザクション・リクエスト、およびBeanメソッドのパフォーマンスをモニターすることもできます。

トラブルシューティング・ツール

WebLogic Serverでは、トランザクションのトラブルシューティングで以下の支援を利用できます。

- 例外

- トランザクション識別子

- トランザクションの名前とプロパティ

- トランザクション・ステータス

- トランザクションの統計

- トランザクションのモニタリング

- JTAリソースのデバッグ

例外

WebLogic JTAでは、すべての標準のJTA例外がサポートされています。標準のJTA例外の詳細については、次の各パッケージのAPI Javadoc (http://docs.oracle.com/javase/1.5.0/docs/api/)を参照してください。

- javax.transaction

- javax.transaction.xa

標準のJTA例外に加えて、WebLogic Serverはweblogic.transaction.RollbackExceptionクラスを提供します。このクラスはjavax.transaction.RollbackExceptionを拡張し、ロールバックの元々の理由を保持します。トランザクションをロールバックする前、つまりrollbackonlyに設定する前に、アプリケーションではそのロールバックの理由を提供できます。トランザクション・サービスの中で発生したすべてのロールバックではその理由が設定されます。たとえば、タイムアウト、XAエラー、beforeCompletionでの非検査例外、あるいはトランザクション・マネージャへのアクセス不能などです。一度設定された理由は上書きできません。

トランザクション識別子

トランザクション・サービスでは、各トランザクションにトランザクション識別子(Xid)が割り当てられます。このIDは、ログ・ファイル内で特定トランザクションの情報を他と区別するために使用できます。トランザクション識別子は、weblogic.transaction.TransactionインタフェースのgetXIDメソッドを使用して取り出すことができます。トランザクション識別子を取得するメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.Transactionを参照してください。

トランザクションの名前とプロパティ

WebLogic JTAでは、トランザクションの命名とユーザー定義プロパティをサポートするjavax.transaction.Transactionの拡張機能が提供されます。これらの拡張機能は、weblogic.transaction.Transactionインタフェースに含まれています。

トランザクション名は、トランザクションの種類(送金やチケット購入など)を示します。したがって、サーバー上の一意のトランザクションを識別するトランザクションIDとは混同しないでください。トランザクション名を利用すると、例外やログ・ファイルでトランザクションの種類を簡単に識別できます。

ユーザー定義のプロパティはキーと値の組み合わせです。この場合のキーはプロパティを識別する文字列であり、値はプロパティに割り当てられた現在の値です。トランザクション・プロパティの値は、Serializableインタフェースを実装するオブジェクトでなければなりません。アプリケーションでは、weblogic.transaction.Transactionインタフェースで定義されているsetメソッドとgetメソッドを使用してプロパティを管理します。一度設定されたプロパティは、存続期間が終わるまでトランザクションとともに存在し、トランザクションがシステムを移動するときにはマシン間で受け渡しされます。プロパティはトランザクション・ログに保存され、クラッシュのリカバリ処理で復元されます。トランザクション・プロパティが複数回にわたって設定された場合は、最後に設定された値が保持されます。

トランザクション名とトランザクション・プロパティを設定および取得するメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.transaction.Transactionを参照してください。

トランザクション・ステータス

Java Transaction APIでは、javax.transaction.Statusクラスを使用してトランザクションのステータス・コードが提供されます。weblogic.transaction.TransactionのgetStatusAsStringメソッドを使用すると、トランザクションのステータスを文字列として返すことができます。文字列には、javax.transaction.Statusで指定されているメジャー状態と、追加のマイナー状態(loggingやpre-preparingなど)が含まれます。

トランザクションの統計

トランザクションの統計は、サーバー上のトランザクション・マネージャで処理されるすべてのトランザクションについて提供されます。それらの統計には、トランザクションの総数、特定の結果(コミット、ロールバック、ヒューリスティックな終了など)を持つトランザクションの数、ロールバックされたトランザクションの理由別の数、およびトランザクションがアクティブな状態を維持した合計時間が含まれます。トランザクションの統計に関する詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの監視に関する項を参照してください。

トランザクションのモニタリング

管理コンソールを使用すると、トランザクションを監視できます。監視タスクは、サーバー・レベルで実行されます。トランザクション統計は特定のサーバーごとに表示されます。

JTAリソースのデバッグ

特定のアプリケーションに問題があると突き止めたら、WebLogic Serverのデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。

デバッグを有効化する

デバッグは、適切なServerDebug構成属性を「true」に設定することで有効化できます。必要に応じて、サーバーのStdoutSeverityを「Debug」に設定することもできます。

構成属性は、以下のいずれかの方法で変更できます。

コマンド・ラインを使用してデバッグを有効化する

コマンド・ラインで適切なプロパティを設定します。例:

-Dweblogic.debug.DebugJDBCJTA=true
-Dweblogic.log.StdoutSeverity="Debug"

この方法は静的なものであり、サーバーの起動時にのみ使用できます。

WebLogic Server管理コンソールを使用してデバッグを有効化する

WebLogic Server管理コンソールを使用して、デバッグ値を設定します。

1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックします(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。

2. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

3. 「サーバーの概要」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

4. 「デバッグ」をクリックします。

5. 「デフォルト」を展開します。

6. 変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。

7. 「有効化」(または「無効化」)を選択して、チェックを入れたデバッグ・スコープまたは属性を有効化(または無効化)します。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

9. ただし、すべての変更がすぐに反映されるわけではなく、一部の変更は再起動するまで適用されません(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。
この方法は動的なものであり、サーバーの実行中にデバッグを有効化するのに使用できます。

WebLogic Scripting Toolを使用してデバッグを有効化する

WebLogic Scripting Tool (WLST)を使用してデバッグ値を設定します。たとえば、次のコマンドでは、debug.pyというデバッグ値を設定するためのプログラムが実行されます。

java weblogic.WLST debug.py

debug.py programプログラムには、以下のコードが含まれています。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCJTA','true')
save()
activate()

JavaからもWLSTを使用することができます。次の例では、デバッグ値の設定に使用されるJavaファイルを示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJDBCJTA','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLSTの使用は動的な方法であり、サーバーの実行中にデバッグを有効化できます。

config.xmlファイルの変更内容

コンソール、WLST、またはコマンド・ラインでデバッグ特性を変更すると、その内容がconfig.xmlファイルに反映されます。例13-1を参照してください。

例13-1 JTAのデバッグ・スタンザのサンプル

.
.
.
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcjta>true</debug-jdbcjta>
</server-debug>
</server>
.
.
.

以下のconfig.xmlのサンプル(抜粋)に、トランザクション・デバッグのスコープ(複数のデバッグ属性)および1つのJTA属性を示します。

JTAのデバッグ・スコープ

java weblogic.diagnostics.debug.DebugScopeViewerを使うとDebugScope定義をツリー表示できます。

以下に示すJTA用の登録済みデバッグ・スコープを有効化できます。

- DebugJDBCJTA (スコープweblogic.jdbc.transaction) - 未使用

- DebugJTAXA (スコープweblogic.transaction.xa) - XAリソースのトレース

- DebugJTANonXA (スコープweblogic.transaction.nonxa) - 非XAリソースのトレース

- DebugJTAXAStackTrace (スコープweblogic.transaction.stacktrace) - 様々な重要な場所でのスタック・トレースを出力する詳細なトレース

- DebugJTARMI (スコープweblogic.transaction.rmi) - 未使用

- DebugJTA2PC (スコープweblogic.transaction.twopc) - すべての2フェーズ・コミット処理のトレース

- DebugJTA2PCStackTrace (スコープweblogic.transaction.twopcstacktrace) - スタック・トレースを出力する詳細な2フェーズ・コミット・トレース

- DebugJTATLOG (スコープweblogic.transaction.tlog) - トランザクション・ロギング情報のトレース

- DebugJTAJDBC (スコープweblogic.transaction.jdbc, weblogic.jdbc.transaction) - JTAレコードの読み書きに関する情報のトレース

- DebugJTARecovery (スコープweblogic.transaction.recovery) - リカバリ情報のトレース

- DebugJTAGateway (スコープweblogic.transaction.gateway) - インポートされたトランザクションに関する情報のトレース

- DebugJTAGatewayStackTrace (スコープweblogic.transaction.gatewaystacktrace) - インポートされたトランザクションに関連するスタック・トレース

- DebugJTANaming (スコープweblogic.transaction.naming) - トランザクションの命名情報のトレース

- DebugJTANamingStackTrace (スコープweblogic.transaction.namingstacktrace) - トランザクションの命名情報のトレース

- DebugJTAResourceHealth (スコープweblogic.transaction.resourcehealth) - XAトランザクション・リソースの状態に関する情報のトレース

- DebugJTAMigration (スコープweblogic.transaction.migration) - トランザクション・ログの移行に関する情報のトレース

- DebugJTALifecycle (スコープweblogic.transaction.lifecycle) - トランザクション・サーバーのライフサイクル(初期化、中断、再開、停止)に関する情報のトレース

- DebugJTALLR (スコープweblogic.transaction.llr) - すべてのロギング・ラスト・リソース処理のトレース

- DebugJTAHealth (スコープweblogic.transaction.health) - トランザクション・サブシステムの状態に関する情報のトレース

- DebugJTATransactionName (スコープweblogic.transaction.name) - トランザクション名のトレース

- DebugJTAResourceName (スコープweblogic.transaction.resourcename) - トランザクション・リソース名のトレース

Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved.