Oracle® Fusion Middleware

Oracle WebLogic ServerメッセージドリブンBeanの開発

12c (12.2.1.2.0)

E82861-01(原本部品番号:E78009-02)

2016年11月

このドキュメントは、Java Platform, Enterprise Edition 7を使用して、WebLogic Server メッセージドリブンBean (MDB)を含むアプリケーションを開発するソフトウェア開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanの開発, 12c (12.2.1.2.0)

E82861-01

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

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(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 Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

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

- 表記規則

1 メッセージドリブンBeanの理解

- JCAベースのMDB

2 MDBのライフサイクル

- 概要

- MDBと並行処理

- マルチスレッド・トピックMDBの制限事項

3 MDBとメッセージング・モデル

- ポイントツーポイント(キュー)モデル: リスナーごとに1つのメッセージ

- パブリッシュ/サブスクライブ(トピック)モデル

- 「必ず1回」の処理

4 MDBのデプロイ

- 宛先とMDB: 連結と非連結

- 連結された宛先/MDB

- 連結されていない宛先/MDB

- JMS分散宛先

- ベスト・プラクティス

5 MDBのプログラミングと構成: 主な手順

- 必須のJMS構成

- MDBクラスの作成とデプロイメント要素の構成

6 MDBのプログラミングと構成: 詳細

- 宛先タイプの構成

- MDBのトランザクション管理戦略の構成

- 宛先を考慮したMDBの構成

- 外部JMSサーバー・マッピングを使用するかどうか

- provider-urlの設定方法

- initial-context-factoryの設定方法

- destination-jndi-nameの設定方法

- connection-factory-jndi-nameの設定方法

- 一般的な宛先のシナリオ:イラストと主な要素の設定

- メッセージ処理動作の構成

- メッセージ受信順序の保証

- 重複メッセージの防止と処理

- 再配信と例外処理

- メッセージドリブンBeanコンテキストの使用

- JMSリソース停止中のメッセージ配信の中断の構成

- メッセージ配信の手動による中断と再開

- JMS接続を中断する秒数の構成

- EJBコンテナによってJMS接続の中断時間が決定される仕組み

- JMS接続の中断を無効化する

- メッセージドリブンBeanのセキュリティIDの構成

- クロス・ドメイン・セキュリティとMDBの使い方

- EJBの構成による論理メッセージ宛先の使用

- 個々のMDBの論理JMSメッセージ宛先を構成する

- アプリケーション・スコープの論理JMSメッセージ宛先を構成する

7 EJB 3.2準拠MDBの使用

- EJB 3.2準拠MDBの実装

- EJB 3.2準拠MDBのプログラミング

- アノテーションを使用するMDBサンプル

8 クラスタ化MDBの移行とリカバリ

9 メッセージドリブンBeanでのバッチの使用

- MDBトランザクション・バッチ処理の構成

- MDBトランザクション・バッチ処理の仕組み

10 JMSトピックを使用したMDBの構成とデプロイ

- サポートされるトピック・タイプ

- 最もよく使用されるMDB属性

- JMS宛先、宛先タイプ、および接続ファクトリの設定

- サブスクリプション永続性の設定

- 恒久サブスクリプションの自動削除の設定

- コンテナ管理対象トランザクションの設定

- メッセージ・フィルタリング(JMSセレクタ)の設定

- MDB同時実行性の制御

- サブスクリプション識別子の設定

- メッセージ分散チューニングの設定

- topicMessagesDistributionModeの設定

- distributedDestinationConnectionの設定

- ベスト・プラクティス

- 互換性モード使用時の非トランザクションMDBについての警告

- 恒久的なMDBとローカルRDTを併用する際の警告

- 恒久的なMDB属性、トピック・タイプ、EJB名の変更についての警告

- パーティション化されたトピックとレプリケートされたトピックのどちらを選択するか

- MDBトピック・メッセージ分散モードの選択

- サブスクリプションの管理と表示

- 不均一なメッセージ・ロードおよび/またはメッセージ処理の遅延の処理方法

- サービス移行の構成

- 以前のリリースからのアプリケーションのアップグレード

- トピックMDBのサンプル

11 MDBのデプロイメント要素とアノテーション

A トピックのデプロイメント・シナリオ

- 構成の順列がデプロイメント・アクションを決定する仕組み

- 一般的なシナリオ

- スタンドアロン(非分散)トピック・シナリオ

- One-Copy-Per-Server

- One-Copy-Per-Application

- レプリケートされた分散トピック・シナリオ

- シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ2: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ3: レプリケートされたDT、サーバーごとに1つのコピー、リモート・デプロイメント

- シナリオ4: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ5: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ6: レプリケートされたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

- パーティション化された分散トピック・シナリオ

- シナリオ7: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ8: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ9: パーティション化されたDT、サーバーごとに1つのコピー、リモート・デプロイメント

- シナリオ9: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ11: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ12: パーティション化されたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

B トピックのサブスクリプション識別子

C WebLogic MDBがWebLogic JMS拡張を活用する方法

はじめに

ここでは、このガイド『Oracle WebLogic ServerメッセージドリブンBeanの開発』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

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

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 メッセージドリブンBeanの理解

メッセージドリブンBean (MDB)とは、Java EEアプリケーションが非同期でメッセージを処理できるようにするエンタープライズBeanのことです。MDBは、JMSまたはJCAメッセージ・リスナー(イベントのかわりにメッセージを受信することを除いてイベント・リスナーと同様)として機能します。メッセージは、どのJava EEコンポーネント(アプリケーション・クライアント、別のエンタープライズBean、またはWebコンポーネント)または非Java EEアプリケーションからでも送信できます。

メッセージドリブンBeanの主な特長は以下のとおりです。

- クライアントはインタフェースを通じてメッセージドリブンBeanにアクセスしません。メッセージドリブンBeanが持つのはBeanクラスのみです。

- メッセージドリブンBeanのインスタンスは、特定クライアントのデータや会話状態を維持しません。メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのメッセージドリブンBeanインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。

メッセージ受信時に、コンテナはメッセージドリブンBeanのonMessageメソッドを呼び出してメッセージを処理します。onMessageメソッドは、ヘルパー・メソッドを呼び出すか、またはセッション/エンティティBeanを呼び出してメッセージ内の情報を処理したり、データベース内に情報を保存します。

メッセージはトランザクション・コンテキスト内のメッセージドリブンBeanに配信することもできます。そうすれば、onMessageメソッドのすべての処理が単一トランザクションに属することになります。メッセージの処理がロールバックされた場合、そのメッセージは再配信されます。

メッセージドリブンBeanを設計する上での選択肢については、「MDBとメッセージング・モデル」を参照してください

EJB開発プロセス全体については、『Oracle WebLogic Server Enterprise JavaBeansの開発』を参照してください。

JCAベースのMDB

JCA仕様に定義されているとおり、MDBはJCA 1.7準拠のリソース・アダプタからメッセージを受信するように構成できます。MDBがJCAを使用するように構成するには、resource-adapter-jndi-nameデプロイメント記述子を設定します。

詳細は、JCA 1.7仕様と、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のresource-adapter-jndi-nameに関する項を参照してください。

2 MDBのライフサイクル

この章では、メッセージドリブンBeanインスタンスのライフサイクルのフェーズと、ライフサイクルを制御するMDBの構成について説明します。

この章には次の項が含まれます:

- 概要

- MDBと並行処理

- マルチスレッド・トピックMDBの制限事項

概要

メッセージドリブンBeanは、リクエストに対するレスポンスが即時である必要のない疎結合(非同期)のビジネス・ロジックを実装します。メッセージドリブンBeanは、JMSキューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス・ロジックを実行します。それは、EJBとJMSの間の非同期インタフェースです。

メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのMDBインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。

EJBコンテナは、必要に応じてBeanのインスタンスを作成し、JMSメッセージをインスタンスに渡すことによってメッセージドリブンBeanと直接対話します。コンテナは、デプロイメント時にBeanのインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除できます。

MDBと並行処理

MDBは、トピックとキューの両方で並行処理をサポートしています。トピックとキューの詳細は、「MDBとメッセージング・モデル」を参照してください

Oracle WebLogic Serverインスタンスでは、各MDBデプロイメントは1つ以上のMDBインスタンス・プール(フリー・プールともいう)を保持します。このプールは、現在リクエストを送信していないMDBインスタンスも保持します。フリー・プール内のMDBインスタンスの最大数は、max-beans-in-free-pool属性の値、スレッド・プール内の利用可能なスレッド数、スレッド・プールの種類、およびその他の要因などによって制御されます。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項 を参照してください。

MDBデプロイメントに関連付けられたフリー・プールの数は、MDBデプロイメントが接続される宛先の種類に依存します。通常、MDBデプロイメントは、デプロイメントをホストする各Oracle WebLogic Serverインスタンス上で1つのフリー・プールに関連付けられます。ただし、デプロイメントをホストする各Oracle WebLogic Serverインスタンス上では、WebLogic JMS分散宛先に接続したMDBデプロイメントが分散宛先に関連付けられた各物理宛先に対して1つのフリー・プールを持つ場合があります。フリー・プールの数は、EJBコンテナによって自動的に決定されます。JMS宛先に関連付けられたMDBの場合、各MDBフリー・プールは常に1つのJMS接続に対応します。

キュー・ベースのJMSアプリケーション(ポイントツーポイント・モデル)では、各MDBインスタンスは単一の内部JMSセッションを作成し、MDBスレッドに対応します。

トピック・ベースのJMSアプリケーション(パブリッシュ/サブスクライブ・モデル)には単一のインスタンスが必要になり、複数のインスタンス間で単一のJMSセッションを共有するか、または各インスタンスに対してセッションを作成できます。これは、MDBアプリケーション設定、トピックの種類、ワークマネージャ、およびmax-beans-in-free-pool設定によって指定されるメッセージ処理パターンに基づいて、MDBコンテナによって自動的に決定されます。JMSトピックを使用したMDBの構成とデプロイを参照してください。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項も参照してください。

マルチスレッド・トピックMDBの制限事項

非トランザクション・トピックMDBのデフォルト動作は、メッセージ処理のマルチスレッド化です。使用時には次のいくつかの制約があります。

- 外部(WebLogic以外の)トピックを使用して機能する非トランザクション・トピックMDB

- WebLogic JMSトピックから消費し、WebLogic JMSの順序単位(UOO)の値を持つメッセージを処理する非トランザクション・トピックMDB

詳細は、「MDB同時実行性の制御」の注意を参照してください

3 MDBとメッセージング・モデル

この章では、MDBのメッセージング・モデルについて説明し、その処理を比較します。Oracle WebLogic Server MDBは、ポイント・ツー・ポイント(キュー)またはパブリッシュ/サブスクライブ(トピック)メッセージング・モデルのいずれかで使用できます。これらのモデルについては、Oracle WebLogic Server JMSアプリケーションの開発で詳しく説明されています。

この章には次の項が含まれます:

- ポイントツーポイント(キュー)モデル: リスナーごとに1つのメッセージ

- パブリッシュ/サブスクライブ(トピック)モデル

- 「必ず1回」の処理

ポイントツーポイント(キュー)モデル: リスナーごとに1つのメッセージ

ポイントツーポイント・モデルでは、JMSキューからのメッセージが1つのMDBリスナーによって取り出され、処理されるまでキューに留まります。そのMDBがダウンした場合、メッセージはMDBが再びアクティブになるのをキューの中で待ちます。

例: ある売り場では、1日を通して売れた品目を反映してバックエンドの在庫システムを更新する必要があります。在庫の値を減らす各メッセージは、必ず一度だけ処理されなければなりません。メッセージはそれが生成された直後に処理されたり、特定の順序で処理されたりする必要はありませんが、各メッセージが必ず処理されることが重要です。

図3-1は、ポイント・ツーポイント・アプリケーションを示しています。各メッセージは、MDB_Aの1つのインスタンスによって処理されます。メッセージ「M1」はMDB_A(1)で処理され、「M2」はMDB_A(2)で処理され、「M3」はMDB_A(3)で処理されます。

図3-1 ポイントツーポイント・モデル

パブリッシュ/サブスクライブ(トピック)モデル

パブリッシュ/サブスクライブ・モデルでは、JMSトピックは各メッセージのコピーを各論理サブスクリプションにパブリッシュします。論理サブスクリプションは、1つ以上の物理的なサブスクリプションから構成され、各物理サブスクリプションは分散トピックの異なるメンバーに関連付けられます。スタンドアロン(非分散)トピックの場合、論理サブスクリプションは常にトピック上の単一の物理サブスクリプションから構成されます。MDBがダウンする場合、トピックが恒久サブスクリプション・トピックでないかぎり、当該MDBはメッセージを見失います。恒久サブスクリプションの情報および構成の手順は、サブスクリプション恒久性の設定を参照してください。

例: 金融ニュース・サービスは、株価と金融情報をサブスクライバ(ニュース配信サービスなど)にブロードキャストします。各メッセージは、各サブスクライバに配信されます。

図3-2は、パブリッシュ/サブスクライブ・アプリケーションを示します。ポイント・ツー・ポイント・アプリケーションとは対照的に、パブリッシュ/サブスクライブ・モデルでは、メッセージのコピーは論理サブスクリプションのそれぞれに対して処理されます。この図では、2つの論理サブスクリプションがあり、各論理サブスクリプションは単一のトピック上の個別の物理サブスクリプションから構成されます。MDB_Aには、単一の専用サブスクリプションのメッセージを処理する2つのインスタンスがあります。同様に、MDB_Bには、異なる単一の専用サブスクリプションのメッセージを処理する2つのインスタンスがあります。メッセージM1は、MDB_AのインスタンスおよびMDB_Bのインスタンスによって処理されます。同様に、メッセージM2は、サブスクライブ側の各MDBのインスタンスによって処理されます。

図3-2 パブリッシュ/サブスクライブ・モデル

「必ず1回」の処理

MDBアプリケーションは各メッセージを1回以上処理します。メッセージは、複数回処理される場合もあります。

- onMessage()メソッドの途中、またはこのメソッドが完了した後で、メッセージが確認応答またはコミットされる前にアプリケーションで障害が起きるか、トランザクションがロールバックされるか、ホスト・サーバー・インスタンスで障害が発生した場合、メッセージは再配信されて再び処理されます。

- 非永続的なメッセージも障害時には再配信されますが、メッセージのホストJMSサーバーが停止またはクラッシュしたときは除きます(この場合はメッセージが破棄されます)。

メッセージが必ず1回処理されるようにするには、コンテナ管理によるトランザクションを使用します。そうすれば、障害が発生したときにトランザクションMDBの処理がロールバックされ、メッセージが強制的に再配信されます。

4 MDBのデプロイ

この章では、MDBをデプロイするための様々な手法とMDBがリスニングするJMS宛先について説明します。

この章には次の項が含まれます:

- 宛先とMDB: 連結と非連結

- 連結された宛先/MDB

- 連結されていない宛先/MDB

- JMS分散宛先

宛先とMDB: 連結と非連結

リスニング元または個別のサーバー・インスタンス上のJMS宛先として、同一のサーバー・インスタンス上でMDBをデプロイできます。それらの選択肢はそれぞれ、連結および非連結と呼ばれます。

連結された宛先/MDB

MDBとそのリスニング対象の宛先を連結すると、メッセージ・トラフィックが常にローカルになり、ネットワークの往復がなくなります。連結は、Oracle WebLogic Server JMSを使用し、メッセージ処理の待機時間とネットワーク・トラフィックを最小限に抑えたい場合に最適です。

MQ SeriesなどのOracle WebLogic Serverで動作できないサード・パーティJMSプロバイダを使用する場合は、MDBとJMS宛先を連結できません。

図4-1と図4-2は、関連付けられたJMS宛先をホストするサーバー・インスタンスにMDBアプリケーションがデプロイされるアーキテクチャを示しています。これらのアーキテクチャは、前者には分散宛先が含まれ、後者には含まれないという点で異なります。分散宛先を使用するアプリケーションでは、MDBは分散宛先セットのメンバーをホストする各サーバー・インスタンスにデプロイされます。分散宛先の詳細は、「JMS分散宛先」を参照してください図4-1に示されているように、メッセージ「M1」は分散宛先とMDB_Aがデプロイされている各サーバー・インスタンス上のMDB_Aのインスタンスに配信されます。図4-1は、One-Copy-Per-Serverトピック・メッセージ宛先モード・パターンを示しています。トピック・パターンは、topicMessagesDistributionModeの設定でさらに詳しく説明します。

図4-1 連結された宛先/MDB、分散トピック、One-Copy-Per-Serverパターン

図4-2 連結された宛先とMDB、非分散宛先

連結されていない宛先/MDB

図4-3は、リスニング対象のJMS宛先からの別のサーバー・インスタンスでMDBが動作するアーキテクチャを示しています。

図4-3 連結されていないアプリケーション、非分散宛先

リスニング対象のJMS宛先とは別のサーバー・インスタンスでMDBを実行するのが適切なのは、以下の場合です。

- アプリケーションでサード・パーティ製のJMSプロバイダ(MQ Seriesなど)が使用されます。

- JMSのインフラストラクチャからアプリケーション・コード(MDB)を分離する必要があります。JMS宛先とMDBを別々のサーバー・インスタンスに配置することで、アプリケーションの問題(たとえばMDBが仮想マシンのメモリーをすべて消費するなど)でJMSインフラストラクチャの処理が妨げられるのが防止されます。

- MDBアプリケーションが非常にCPUを消費します。別のマシンにあれば、アプリケーションはJMSインフラストラクチャの処理に影響を与えずにCPUパワーを100%使用することができます。

- 構成中の1つのマシンが、同じ構成の他のマシンよりも処理能力、ディスク領域やメモリーの点で優れています。

JMS宛先とMDBは、非クラスタ化サーバー、同じクラスタ内の複数のサーバー、または別々のクラスタのサーバーにもデプロイできます。

注意:
WebLogic Serverでは、移行可能なターゲットに宛先をデプロイする場合、クラスタ内の連結されていない宛先およびMDBはサポートされていません。

JMS分散宛先

MDBアプリケーションがOracle WebLogic Serverクラスタで動作している場合は、複数の物理的宛先(キューまたはトピック)を、メッセージ・プロデューサやコンシューマからは1つの宛先に見える分散宛先として構成できます。

分散宛先を構成する場合、WebLogic JMSは、分散宛先の使用可能なメンバー全体に渡ってメッセージング・ロードを分散します。宛先のメンバーがサーバー障害によって使用できなくなる場合、メッセージ・トラフィックは、分散宛先セットにある他の使用可能な物理的な宛先にリダイレクトされます。weblogic-ejb-jar.xmlファイルのdistributed-destination-connection要素またはdistributedDestinationConnectionアノテーションを使用して、同一クラスタ内のWebLogic分散キューにアクセスするMDBが、すべての分散宛先メンバーから消費するか、または現在のOracle WebLogic Serverに対してローカルのメンバーのみから消費するかどうかを管理できます。同様に、JMSトピックを使用したMDBの構成とデプロイおよびトピック・デプロイメント・シナリオで説明されているように、この設定は一部のトピックMDBシナリオの動作を管理します。

MDBおよび関連する分散キューを同一のクラスタにデプロイする場合、Oracle WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーが少なくとも1つのMDBプールによってサービスされることを保証します。分散キューについては、distributedDestinationConnectionがLocalOnly(デフォルト)のとき、各ローカル・メンバーに1つのMDBプールがあることになります。それ以外の場合、キューについては、distributedDestinationConnectionがEveryMemberに設定されているとき、各Oracle WebLogic Serverインスタンスは複数のローカルMDBプール(各ローカル・メンバーに1つ + 各リモート・メンバーに1つ)を作成します。

MDBおよびその関連付けられたキューを異なるクラスタにデプロイする場合、Oracle WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーがMDBクラスタ内の各サーバー上にあるMDBプールによってサービスが提供されることを保証します。たとえば、分散キューに3つのメンバーが含まれる場合、MDBクラスタ内の各JVMは3つのMDBプールを作成します。

分散トピックの詳細は、JMSトピックを使用したMDBの構成とデプロイを参照してください。

ベスト・プラクティス

WebLogicクラスタリングおよびWebLogic JMS分散宛先は、拡張性と高可用性を増加します。適切にロード・バランシングされたメッセージ処理を保証するために、クラスタをホストするマシンが同一または同程度の処理能力、ディスク容量、およびメモリーを持つことをお薦めします。同様に、特定のWebLogicクラスタ内のOracle WebLogic Serverインスタンスは、均一のJMS構成およびMDBデプロイメントを持つことをお薦めします。

例については、図4-1を参照してください。分散宛先の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。

5 MDBのプログラミングと構成:主な手順

この章では、EJB 3.0以前の型式のXML記述子を使用してMDBの動作を構成するためのMDB実装に関して、ステップごとの説明を表示されます。EJB 3.2のアノテーション・サンプルは、次を参照してください

MDBの主要デプロイメント要素のまとめは、MDBのデプロイメント要素とアノテーションを参照してください。トピックMDBの主要デプロイメント要素の紹介は、JMSトピックを使用したMDBの構成とデプロイを参照してください。

この章には次の項が含まれます:

- 必須のJMS構成

- MDBクラスの作成とデプロイメント要素の構成

必須のJMS構成

次の項の手順は、次の適切なJMSコンポーネントへのアクセス権を持っているものと想定しています。

- JMS接続ファクトリ。
接続ファクトリは、トランザクションMDBをサポートするために、XAトランザクション(グローバルJTAトランザクション)に対応している必要があります。

デフォルトのWebLogic JMS MDB接続ファクトリはXAに対応しており、WebLogicクラスタ上で自動生成され、WebLogic JMS宛先から消費するMDBの大部分には十分です。WebLogic JMSのデフォルト接続ファクトリの詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic Serverにより定義されたデフォルト接続ファクトリの使用に関する項を参照してください。

カスタムWebLogic JMS接続ファクトリを作成する方法の手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールにおける接続ファクトリの作成に関する項を参照してください。

他のJMSプロバイダでは、デフォルトの動作と構成方法は異なります。Oracle以外のJMSプロバイダ接続ファクトリを使用する場合は、そのベンダー提供のドキュメントを参照してください。

- JMS宛先
WebLogic JMS宛先の構成手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージングの構成に関する項を参照してください。

注意:

JMSプロバイダがリモートのOracle WebLogic Server JMSプロバイダか外部JMSプロバイダであり、「外部JMSサーバー・マッピングを使用するかどうか」でお薦めされているラッパー手法を使用する場合は、ローカルではないJMSコンポーネントを構成するだけでなく、ローカルのJNDIツリーで外部接続ファクトリと外部JMS宛先も構成する必要があります。

MDBクラスの作成とデプロイメント要素の構成

メッセージドリブンBeanを実装するには、次の手順を実行します。

1. javax.ejb.MessageDrivenBeanインタフェースとjavax.jms.MessageListenerインタフェースの両方を実装するソース・ファイル(メッセージドリブンBeanクラス)を作成します。

MDBクラスでは、以下のメソッドを定義する必要があります。

- MDBの各新規インスタンス作成後にコンテナが呼び出す1つのejbCreate()メソッド。

- EJBのコンテナがメッセージを受け取ったときに呼び出すonMessage()メソッドを1つ。このメソッドには、メッセージを処理するビジネス・ロジックが格納されます。

- 環境について情報(特定のデプロイメント記述子の値)をBeanのインスタンスに提供するsetMessageDrivenContext{}メソッドを1つ。「メッセージドリブンBeanコンテキストの使用」を参照してください。

- メッセージドリブンBeanインスタンスをフリー・プールから削除するejbRemove()メソッドを1つ。

注意:

大半のEJB 3.2アプリケーションは、単一のメソッドonMessage()を定義するjavax.jms.MessageListenerのみを実装します。ただし、メッセージドリブンBeanはメソッドのないリスナー・インタフェースの実装を許可されています。メソッドのないインタフェースを実装するBeanは、Beanクラス、およびjava.lang.Objectを除いた任意のスーパークラスのすべての非静的パブリック・メソッドをメッセージ・リスナー・メソッドとして公開します。

2. 次の例のように、ejb-jar.xmlでMDBを宣言します。

<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>...</ejb-name>
<ejb-class>...</ejb-class>
<transaction-type>Container</transaction-type>
<acknowledge-mode>auto_acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>...</ejb-name>
<method-name>onMessage()</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

構成する主要な動作は以下のとおりです。

- トランザクション管理戦略 - MDBのトランザクション管理戦略(transaction-type要素)。手順については、「MDBのトランザクション管理戦略の構成」を参照してください

- 宛先タイプ - MDBがリスニングする宛先のタイプ。詳細については、「宛先タイプの構成」を参照してください

3. weblogic-ejb-jar.xmlのmessage-driven-descriptor要素でMDBのWebLogic固有の動作を構成します。例:

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>exampleMessageDrivenA</ejb-name>
<message-driven-descriptor>
<pool>...</pool>
<timer-descriptor>...</timer-descriptor>
<destination-jndi-name>...</destination-jndi-name>
<initial-context-factory>...</initial-context-factory>
<provider-url>...</provider-url>
<connection-factory-jndi-name>...</connection-factory-jndi-name>
<jms-polling-interval-seconds>...</jms-polling-interval-seconds>
<jms-client-id>...</jms-client-id>
<generate-unique-jms-client-id>...</generate-unique-jms-client-id>
<durable-subscription-deletion>...</durable-subscription-deletion>
<max-messages-in-transaction>...</max-messages-in-transaction>
<init-suspend-seconds>...</init-suspend-seconds>
<max-suspend-seconds>...</max-suspend-seconds>
</message-driven-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>

構成する際の重要な要素は、宛先へのアクセス方法の指定です。通常、ベスト・プラクティスに従うアプリケーションでは、initial-context-factoryやprovider-urlフィールドを指定する必要はありません。手順については、「宛先用のMDBの構成」を参照してください

4. 『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のJavaソースのコンパイルに関する項の手順に従い、MDBクラスをコンパイルして生成します。

5. 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションおよびモジュールのデプロイメント準備に関する項の手順に従い、BeanをOracle WebLogic Serverにデプロイします。

デプロイメント時にOracle WebLogic ServerでMDBのJMS宛先を見つけることができない場合、デプロイメントは成功しますが、宛先が見つからなかったことを示すメッセージがOracle WebLogic Serverから出力されます。その場合、MDBは、JMSキューへの接続が成功するまで、定期的に接続を試行します。詳細については、「クラスタ化MDBの移行とリカバリ」を参照してください

6 MDBのプログラミングと構成: 詳細

この章では、MDBのプログラミングと構成について説明し、「MDBのプログラミングと構成: 主な手順」の内容を補足します。

注意:

この章では、EJB 3.0以前のデプロイメント記述子を使用して基本MDB構成を説明します。EJB 3.2アノテーションを使用する場合は、MDBのデプロイメント要素とアノテーションを参照してください。また、同等の設定に関しては、EJB 3.2準拠MDBの使用を参照してください。

この章には次の項が含まれます:

- 宛先タイプの構成

- MDBのトランザクション管理戦略の構成

- 宛先を考慮したMDBの構成

- メッセージ処理動作の構成

- メッセージドリブンBeanコンテキストの使用

- JMSリソース停止中のメッセージ配信の中断の構成

- メッセージ配信の手動による中断と再開

- JMS接続を中断する秒数の構成

- メッセージドリブンBeanのセキュリティIDの構成

- クロス・ドメイン・セキュリティとMDBの使い方

- EJBの構成による論理メッセージ宛先の使用

宛先タイプの構成

MDBがリスニングする宛先のタイプは、ejb-jar.xmlのmessage-driven-destination要素のdestination-type要素で、またはアノテーションを使用して、構成します。

- トピックを指定するには、destination-typeをjavax.jms.Topicに設定します。宛先がトピックの場合は、subscription-durabilityをDurableまたはNonDurableのいずれかで指定します。トピック関連の重要な追加設定は、JMSトピックを使用してMDBの構成とデプロイおよびMDBのデプロイメント要素とアノテーションを参照してください。

- キューを指定するには、destination-typeをjavax.jms.Queueに設定します。キュー関連設定の詳細は、MDBのデプロイメント要素とアノテーションを参照してください。

MDBのトランザクション管理戦略の構成

MDBは独自にトランザクションを管理するか、トランザクション管理をコンテナに委ねることができます。

記述子の要素を使用してコンテナ・レベルのトランザクション管理を構成するには、次の手順を従います。

- ejb-jar.xmlファイルのmessage-driven要素のtransaction-type要素をContainerに設定します。

- ejb-jar.xmlのcontainer-transaction要素のtrans-attribute要素をRequiredに設定します。

注意:

transaction-typeがContainerに設定されていて、trans-attributeが設定されていない場合は、デフォルトのtransaction-attribute値が適用されます: EJB 3.2 MDBの場合はrequired、EJB 3.0より前のMDBの場合はNotSupportedです。Oracle WebLogic Serverでは、MDBをデプロイでき、準拠エラーをログに記録することもできます。ただし、この構成エラーを犯した場合、MDBはトランザクション的には実行されません。トランザクションの途中で障害が発生した場合、その障害の前に行われた更新はロールバックされません。

- トランザクションのタイムアウト期間を変更するには、weblogic-ejb-jar.xmlのtransaction-descriptor要素のtrans-timeout-secondsを設定します。タイムアウトしたトランザクションはロールバックされ、メッセージが再配信されます。デフォルトでは、トランザクションは30秒後にタイムアウトになります。トランザクションの時間が長いアプリケーションでは、タイムアウトの期間を長くする方がいいかもしれません。

EJBアノテーションを使用してコンテナ・レベルのトランザクション管理を構成するには、次の手順を従います。

import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
...
@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
public void onMessage(Message msg) {
...

記述子の要素を使用してBeanレベルのトランザクション管理を構成するには、次の手順を従います。

- ejb-jar.xmlファイルのmessage-driven要素のtransaction-type要素をBeanに設定します。

- acknowledge-mode要素で、目的のJMS確認応答セマンティクスを以下のいずれかに設定します。

- AUTO_ACKNOWLEDGE (デフォルト)。http://www.oracle.com/technetwork/java/jms/index.html#AUTO_ACKNOWLEDGEを参照してください。

- DUPS_OK_ACKNOWLEDGE。http://www.oracle.com/technetwork/java/jms/index.html#DUPS_OK_ACKNOWLEDGEを参照してください。

詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のセッションに関する項を参照してください。

宛先を考慮したMDBの構成

Oracle WebLogic Server MDBは、WebLogic JMS宛先と外部(非Oracle) JMSプロバイダの宛先をサポートしています。

ローカル宛先とは、MDBと同じマシンまたは同じクラスタで動作する宛先のことです。リモート宛先とは、別のマシンで動作しており、MDBと同じクラスタのメンバーではない宛先のことです。宛先がローカルであるかリモートであるかは、その宛先とMDBが同じJNDIコンテキストを共有しているかどうかに依存します。

お互いがお互いをローカルと見なすようにするには、MDBとその関連するJMS宛先が両方とも同じマシン上、または同じOracle WebLogic Serverクラスタ内で動作する必要があります。同じOracle WebLogic Serverクラスタ内のサーバー・インスタンス上のMDBとJMS宛先は、それらが別々のマシン上にあってもお互いにローカルな存在です。Oracle WebLogic Serverクラスタ内のサーバー・インスタンスはそれぞれ同じクラスタ全体のJNDIツリーのコピーを所有しているからです。

非OracleのJMSプロバイダで動作する宛先は、外部と表現されます。外部JMSプロバイダにはそれ専用のJNDIプロバイダがあり、外部JMSオブジェクトはOracle WebLogic Server MDBと同じコンテキストを共有しません(外部JMSオブジェクトがラッパーを使用してMDBのJNDIコンテキストに含まれるように構成されていないかぎり)。その手法については、「外部JMSサーバー・マッピングを使用するかどうか」を参照してください

宛先の性質(ローカルかリモートか、WebLogic JMSか非Oracleか)によって利用可能な構成オプションが決まり、weblogic-ejb-jar.xmlのMDBのmessage-destination-descriptorの以下の主な要素の構成方法はある程度決定します。

- initial-context-factory

- provider-url

- destination-jndi-name

- connection-factory-jndi-name

外部でリモートの宛先の場合、もっともシンプルな構成戦略はOracle WebLogic Server JMS外部JMSサーバー・マッピングを使用することです。これらのマッピングを使用すると、サード・パーティJNDIプロバイダあるいは別のOracle WebLogic ServerクラスタまたはドメインのJMSオブジェクトとローカルWebLogic JNDIツリーのオブジェクトの間に「シンボリック・リンク」を作成できます。

外部JMSサーバー・マッピングをいつ使用するのか、およびweblogic-ejb-jar.xmlでmessage-driven-descriptorを構成するルールの詳細は、次の項を参照してください。

- 外部JMSサーバー・マッピングを使用するかどうか

- provider-urlの設定方法

- initial-context-factoryの設定方法

- destination-jndi-nameの設定方法

- connection-factory-jndi-nameの設定方法

特定のシナリオでmessage-driven-descriptorの要素を構成するには、「一般的な宛先のシナリオ:イラストと主な要素の設定」を参照してください

外部JMSサーバー・マッピングを使用するかどうか

マッピングを使用するということは、リモートJMSオブジェクト(非OracleまたはWebLogic JMS)に対応する外部接続ファクトリおよび外部宛先をローカルJNDIツリーのエントリとして構成するということです。

- 外部JMSプロバイダまたはリモートWebLogic JMSプロバイダを使用する場合には、マッピングの使用をお薦めします。JMSマッピング・クラスの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の「WebLogic JMSをEJBやサーブレットと使用するための拡張サポート」のリモートまたは外部JMSプロバイダへの簡略化されたアクセスに関する項を参照してください。

- 接続ファクトリまたは宛先のいずれかでマッピングを使用する場合は、それらのオブジェクトの両方でマッピングを作成する必要があります。

マッピングを使用するかどうかで、initial-context-factoryとdestination-jndi-nameの構成方法が決まります。

provider-urlの設定方法

provider-urlは、MDBがリスニングする宛先のJMSプロバイダで使用されるJNDIサービスのURLを指定します。

- JMSプロバイダがMDBにとってローカルである(定義により、WebLogic JMSである)場合は、provider-urlを指定しないでください。

- JMSプロバイダがリモートで(WebLogic JMSか外部プロバイダに関係なく)、かつ:

- マッピングを使用しない場合は、provider-urlを指定します。

- マッピングを使用する場合は、provider-urlは指定しないでください。URLはマッピングで暗黙的に暗号化されます。

initial-context-factoryの設定方法

initial-context-factoryは、JMSプロバイダで使用される初期コンテキスト・ファクトリを実装するクラスを指定します。

- JMSプロバイダがWebLogic JMSの場合は、ローカルかリモートかに関係なく、initial-context-factoryは指定しないでください。

- JMSプロバイダが外部の場合で、

- マッピングを使用しない場合は、JMSプロバイダで使用される初期コンテキスト・ファクトリを指定します。

- マッピングを使用する場合は、initial-context-factoryを指定しないでください。

destination-jndi-nameの設定方法

destination-jndi-nameは、MDBがリスニングする宛先のJNDI名を指定します。

- JMSプロバイダがローカルの場合は、宛先のローカルJNDIツリーでバインドされた名前を指定します。

- JMSプロバイダが外部の場合で、

- マッピングを使用しない場合は、外部プロバイダのJNDIツリーでバインドされている宛先の名前を指定します。

- マッピングを使用する場合は、リモートまたは外部宛先に対応するローカルJNDIツリーで設定した外部宛先の名前を指定します。

connection-factory-jndi-nameの設定方法

connection-factory-jndi-nameは、JMSプロバイダで使用される接続ファクトリのJNDI名を指定します。

- JMSプロバイダがローカルの場合は、MDBが使用するカスタム接続ファクトリを構成していないかぎりconnection-factory-jndi-nameを指定しないでください。
カスタム接続ファクトリは、デフォルトのOracle WebLogic Server接続ファクトリではアプリケーションの要件を満たせない場合に使用します。たとえば、MessagesMaximum属性で特定の必要な値を指定するためにカスタム接続ファクトリを構成する場合もあります。接続ファクトリの構成手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの構成に関する項を参照してください。

注意:

MDBのカスタムJMS接続ファクトリを構成する場合は、必ず確認応答ポリシー属性をPreviousに設定し、UserTransactionsEnabled属性が有効であるようにしてください。

- JMSプロバイダがリモートまたは外部の場合で、

- マッピングを使用しない場合は、リモートJNDIツリーでバインドされている、JMSプロバイダで使用される接続ファクトリの名前を指定します。

- マッピングを使用する場合は、リモートまたは外部のJMSプロバイダの接続ファクトリに対応するローカルJNDIツリーで設定した外部接続ファクトリを指定します。

一般的な宛先のシナリオ:イラストと主な要素の設定

この項の図は、一般的な宛先の構成を示しています。リモートおよび外部の宛先については、マッピング「あり」と「なし」のシナリオが用意されています。

- 図6-1

- 図6-2

- 図6-3

- 図6-4

表6-1は、各シナリオのweblogic-ejb-jar.xmlのmessage-driven-descriptor要素に含まれる要素の構成方法を示しています。

図6-1 A. ローカルWebLogic JMSサーバーの宛先

図6-2 B. リモートWebLogic JMSサーバーの宛先(マッピングなし)

図6-3 C. 外部JMSサーバー上の宛先(マッピングなし)

図6-4 D. リモートOracle WebLogic Serverまたは外部JMSサーバーの宛先(マッピングあり)

表6-1 一般的な構成シナリオ

シナリオ

宛先が次に存在する場合...

マッピングが構成済か?

destination-jndi-name

initial-context-factory

provider-url

connection-factory-jndi-name

A

ローカルWebLogic JMSサーバー

ローカルWebLogic JMSサーバーには適用なし

ローカルのJNDIツリーでバインドされている、ローカル宛先の名前

指定しません

指定しません

カスタム接続ファクトリを使用する場合のみ指定します

B

リモートWebLogic JMSサーバー

マッピングが構成されていません

リモートのJNDIツリーでバインドされている、リモート宛先の名前

指定しません

リモートWebLogic JMSサーバーのURLまたはクラスタ・アドレス

リモート・プロバイダでカスタム接続ファクトリを使用する場合のみ指定します

C

外部JMSプロバイダ

マッピングが構成されていません

リモートのJNDIツリーでバインドされている、リモート宛先の名前

リモートのJNDIツリーでバインドされている、リモート初期コンテキスト・ファクトリの名前

外部JMSプロバイダにアクセスするためのURL

外部接続ファクトリのJNDI名

D

リモートWebLogic JMSサーバー

または

外部JMSサーバー

マッピングが構成済

リモートまたは外部宛先に対応する、ローカルJNDIツリーでバインドされている外部宛先の名前

指定しません

指定しません

リモートまたは外部接続ファクトリに対応する、ローカルJNDIツリーでバインドされている外部接続ファクトリの名前

メッセージ処理動作の構成

以下のトピックでは、メッセージの配信に関連する動作のガイドラインを示します。

- メッセージ受信順序の保証

- 重複メッセージの防止と処理

- 再配信と例外処理

メッセージ受信順序の保証

MDBのビジネス・ロジックが非同期メッセージ処理を許可していることを確認します。クライアントがメッセージを発行する順序でMDBがメッセージを受信するとは仮定しないでください。

WebLogic JMS宛先を使用するとき、厳密な順序付けが必要な場合は「順序単位」機能を使用することをお薦めします。この機能を使用すると、MDBを変更せずにあらゆる状況で順序付けを強制したり、同一宛先内に存在する下位順序の同時実行処理を可能にしたりします。なおこの機能は、構成を介して有効化するか、または必要に応じてプログラムを介して有効にできます。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

受信順序がクライアントによるメッセージの送信順序に一致することを保証するために、順序単位を使用するWebLogic宛先を使用しない場合、次の操作を実行する必要があります。

- MDBのmax-beans-in-free-poolを1に設定します。これでMDBがメッセージの唯一のコンシューマになります。

- MDBをクラスタにデプロイする場合は、それらをクラスタの1つのノードにデプロイします。図6-5を参照してください。

トランザクションのロールバックおよびリカバリ時にメッセージの順序付けを保証するには、MessagesMaximumを1に設定したカスタム接続ファクトリを構成し、再配信遅延が構成されていないことを確認します。外部ベンダーは、同等の設定に対して異なる名前を持ちます。この設定は、コンシューマが現在のメッセージ処理を完了する前に、ベンダーがコンシューマにプッシュできるメッセージ数を管理します。

詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の順序付けられたメッセージの再配信に関する項を参照してください。

MessageListenerインタフェース(javax.jms MessageListener.onMessage())に関するJavaのドキュメント(http://download.oracle.com/javaee/1.2.1/api/javax/jms/MessageListener.html)を参照してください。

重複メッセージの防止と処理

JMSベンダーは、MDBが受信メッセージの確認応答をするのを待ち受けます。MDBがメッセージを受信したが、確認応答の送信に失敗した場合、JMSベンダーは同じメッセージを再送信します。

MDBの設計は、重複メッセージの可能性を考慮に入れているはずです。重複メッセージは、特定の状況では有害になります。たとえば、MDBのonMessage()メソッドに銀行口座の借方に記入するコードが含まれている場合、そのメッセージを2回受信して処理すると借方への記入が2回行われることになります。また、メッセージが再送信されると、処理リソースがより多く消費されることになります。

重複メッセージの配信を防止する最適な方法は、コンテナ管理によるトランザクションを使用することです。コンテナ管理によるトランザクションでは、トランザクションの中でメッセージの受信と確認応答が行われます(つまり両方行われるか、両方とも行われません)。ただし、これはBean管理のトランザクションを使用するよりも信頼性が高くなりますが、パフォーマンスは犠牲になります。コンテナ管理によるトランザクションでは、より多くのCPUリソースとディスク・リソースが使用されるからです。

MDBがそれ自身のトランザクションを管理する場合は、受信と確認応答がトランザクションの外で行われるので、onMessage()のコードで重複メッセージを処理する必要があります。一部のアプリケーションは、重複メッセージの受信と処理に対応しています。銀行口座のシナリオのような他のケースでは、トランザクションがBean管理の場合は、Beanのコードで重複メッセージの処理を防止する必要があります。たとえば、MDBではデータベースですでに消費されているメッセージを追跡できます。

MDBのonMessage()メソッドが正常に完了する場合でも、onMessage()の完了とコンテナによるメッセージ配信の確認応答の間にサーバーがクラッシュすると、MDBは重複メッセージを受信することになります。図6-5は、そのシナリオを示しています。

図6-5 onMessage()の完了とコンテナによる配信の確認応答の間のサーバー・クラッシュ

再配信と例外処理

MDBがメッセージを消費している最中に予期しないエラーが発生した場合、MDBはシステム例外をスローできます。その例外により、JMSの構成に応じてJMSは再送信、遅延後に再送信、または放棄を行います。

トランザクションMDBでメッセージの再配信を強制するには、Beanのコンテキストを使用して setRollbackOnly()を使用します。

トランザクション対応かどうかに関係なく、MDBでメッセージの再配信を強制するには、MDBによってスローされるRuntimeExceptionまたはErrorから派生した例外をスローできます。このようにすると、MDBインスタンスは破棄および再作成され、パフォーマンスの低下につながります。実行例外をスローする一方で、破棄や再作成のオーバーヘッドを避ける場合は、WebLogic拡張機能を使用できます。たとえば、次のようにweblogic.ejb.NonDestructiveRuntimeExceptionのインスタンスをスローします。

throw new weblogic.ejb.NonDestructiveRuntimeException("force redelivery");

再配信遅延は、MDBのonMessage()メソッドが実行するタスクの種類に基づいて構成できます。場合によっては、たとえばニュース・サービスに速報を流すアプリケーションなどで、再配信は即時に行うことが必要になります。その他の場合、たとえばデータベースのダウンが原因でMDBが例外をスローする場合、再配信はデータベースが復帰した後でないかぎりすぐでなくてもかまいません。

注意:

順序単位機能を使用しない、完全に順序付けられたMDBの場合、再配信遅延を設定しないでください。

再配信遅延と、MDBで使用できる他のJMS例外処理機能の構成手順については、『Oracle WebLogic Server JMSアプリケーションの開発』のロールバック、リカバリ、再配信、または期限切れメッセージの管理に関する項を参照してください。

メッセージドリブンBeanコンテキストの使用

Oracle WebLogic Serverは、setMessageDrivenContext()を呼び出してMDBインスタンスとコンテナ・コンテキストを関連付けます。また、EJB 3.2 MDBアプリケーションはMDBコンテキストを注入するアノテーションを指定できます。これはクライアント・コンテキストではありません。クライアント・コンテキストは、JMSメッセージと一緒には渡されません。

MDBインスタンス内からコンテナ・コンテキストのプロパティにアクセスするには、MessageDrivenContextインタフェースの以下のメソッドを使用します。

- getCallerPrincipal() - EJBContextインタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。

- isCallerInRole() - EJBContextインタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。

- setRollbackOnly() - コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。

- getRollbackOnly() - コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。

- getUserTransaction() - Bean管理によるトランザクションの境界設定を使用するEJBでのみ使用できます。

注意:

getEJBHome()もMessageDrivenContextインタフェースの一部として継承されますが、メッセージドリブンBeanにはホーム・インタフェースがありません。MDBのインスタンスからgetEJBHome()を呼び出すと、IllegalStateExceptionがスローされます。

JMSリソース停止中のメッセージ配信の中断の構成

このリリースのOracle WebLogic Serverでは、EJBコンテナがJMSリソースの停止を検出したときのMDBの動作(同じ例外を10回連続でスローする)を構成できます。

次のように構成できます。

- EJBコンテナがJMSリソースの停止を検出したときに、MDBはJMS接続を中断し、以後のメッセージの受信を停止します。この構成を選択した場合、次を指定できます。

- MDBがメッセージの受信を再開するまで待機する初期秒数。

- MDBがメッセージの受信を再開するまで待機する最大秒数。

- EJBコンテナがJMSリソースの停止を検出したときに、MDBはJMS接続を中断しません。

JMS接続が中断されると、その接続に関連付けられているすべてのJMSセッションでのメッセージ配信が中断されます。デフォルトによって、JMSリソースの停止を検出したEJBコンテナは、MDBのJMS接続をinit-suspend-seconds秒中断します。

メッセージ配信の手動による中断と再開

WebLogic Server管理コンソールを使用して、デプロイされているMDBへのメッセージ配信を手動で中断および再開できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのMDBのJMS接続の中断と再開に関する項を参照してください。

JMS接続を中断する秒数の構成

リソースが停止している間JMS接続を中断したい場合は、MDBから同じ例外が10回連続でスローされるように定義します。

MDBのJMS接続を中断するには、weblogic-ejb-jar.xmファイル内の以下の要素を構成します。

- init-suspend-seconds - EJBコンテナがJMSリソースの停止を検出したときにJMS接続を中断する時間(秒数)の初期値です。デフォルト値は5です。

- max-suspend-seconds - EJBコンテナがJMSリソースの停止を検出したときにJMS接続を中断する時間(秒数)の最大値です。デフォルト値は60です。

EJBコンテナによってJMS接続の中断時間が決定される仕組み

EJBコンテナでは、init-suspend-secondsとmax-suspend-secondsに基づき、次のアルゴリズムでJMS接続の中断時間を決定します。

まず、EJBコンテナがJMSリソースの停止を検出します。

1. MDBのJMS接続を、init-suspend-secondsに指定された時間だけ中断します。

2. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

3. init-suspend-secondsの値がmax-suspend-seconds以上である場合はステップ9に進みます。

4. 前回の中断時間に2を掛けて、次回の中断時間(Xseconds)を算出します。

5. MDBのJMS接続を、Xsecondsに指定された時間だけ中断します。

6. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

7. init-suspend-secondsの値がmax-suspend-seconds以上である場合はステップ9に進みます。

8. ステップ4に進みます。

9. MDBのJMS接続を、max-suspend-secondsに指定された時間だけ中断します。

10. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

11. ステップ9に進みます。

12. 処理を続行します。

JMS接続の中断を無効化する

EJBコンテナがリソースの停止を検出したときにMDBのJMS接続が中断しないようにするには、max-suspend-secondsの値を0に設定します。max-suspend-secondsの値が0の場合、init-suspend-secondsの値は無視されます。

メッセージドリブンBeanのセキュリティIDの構成

メッセージドリブンBean (MDB)がJMSキューまたはトピックからメッセージを受信すると、EJBコンテナは資格証明マッピング・プロバイダおよび資格証明マップを使用して、JMS接続の確立時に使用するセキュリティID (ユーザー名とパスワード)を取得し、onMessage()メソッドを実行します。この資格証明マッピングは、MDBの起動時に一度だけ行われます。

EJBコンテナが一度接続されると、JMSプロバイダは確立されたセキュリティIDを使用してすべてのメッセージを受信します。

MDBのセキュリティIDを構成するには:

1. MDBのWebLogicユーザーを作成します。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。JMS接続を確立するためにOracle以外のJMSプロバイダが要求するユーザー名とパスワードをユーザーに割り当てます。

2. ejb-jar.xmlデプロイメント記述子で、次のようにMDBのrun-as IDを定義します。

<security-identity>
<run-as>
<role-name>admin</role-name>
</run-as>
</security-identity>

3. security-identityを作成するために、ejb-jar.xmlのassembly-descriptor要素の中にsecurity-roleを定義する必要があります。

<assembly-descriptor>
<security-role>
<role-name>jmsrole</role-name>
</security-role>
....
</assembly-descriptor>

4. weblogic-ejb-jar.xmlデプロイメント記述子で、次のように、ステップ2で定義されたユーザーにrun-as IDをマップします。
http://docs.oracle.com/middleware/1213/wls/WLACH/taskhelp/ejb/CreateEJBComponentCredentialMappings.html
usernameは、ステップ1で作成したユーザーのユーザー名です。

5. JMSプロバイダがWebLogic JMSではない場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBコンポーネントの資格証明マッピングの作成に関する項の説明に従って資格証明マッパーを構成します。

注意:

JMSプロバイダがWebLogic JMSの場合は、資格証明マッパーを構成する必要はありません。

クロス・ドメイン・セキュリティとMDBの使い方

MDBでは、クロス・ドメイン・セキュリティを構成する必要があります。ただし、MDBを実装する場合には、次のガイドラインを念頭に置いてください。

- MDBでトランザクション・メッセージを処理する必要がある場合には、すべての参加ドメインについて、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードのいずれかを適切に構成する必要があります。
クロス・ドメイン・セキュリティ構成およびセキュリティの相互運用モードに関して、プロセスで使用されるすべてのドメインの対称性を維持します。どちらの設定もドメイン・レベルで設定されるため、ドメインが混在モードになる(つまり、ドメインがクロス・ドメイン・セキュリティとセキュリティの相互運用モードの組合せを持つ)可能性があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のセキュアなドメイン間およびドメイン内トランザクション通信の構成に関する項を参照してください。

- MDBが異なるドメインの分散宛先をリスニングする場合には、クロス・ドメイン・セキュリティを構成する必要があります。

- 非トランザクション・メッセージを処理するMDBでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、1つのドメインにクロス・ドメイン・セキュリティが構成されていて、任意のドメインでMDBがリスニングする分散宛先のメンバーシップが変更される場合は、プロセスの通信対象となるすべてのドメインに対して、クロス・ドメイン・セキュリティを構成する必要があります。別のドメインにある分散宛先がリスニングするMDBの場合、クロス・ドメイン・セキュリティを構成する必要があります。
ベスト・プラクティスは、クロス・ドメイン・セキュリティ構成およびセキュリティの相互運用モードに関して、プロセスで使用されるすべてのドメインの対称性を維持することです - つまり、すべてのドメインがクロス・ドメイン・セキュリティを使用する(適切な例外リストに含まれる)か、または、どのドメインについてもクロス・ドメイン・セキュリティを構成しないかです。『Oracle WebLogic Serverセキュリティの管理』のクロス・ドメイン・セキュリティの構成に関する項を参照してください。

EJBの構成による論理メッセージ宛先の使用

注意:

論理宛先およびアプリケーション・スコープの宛先は、通常は使用されず、上級ユーザー向けのみとなります。大半のユーザーの場合、「宛先用のMDBの構成」で説明したメソッドの使用をお薦めします

EJBのデプロイメント記述子に論理メッセージ宛先を宣言して、実際のメッセージ宛先(JMSキュー、JMSトピック、MDBなど)にマップできます。論理メッセージ宛先を宣言したら、その宛先にリンクするメッセージ宛先の参照を作成できます。EJBは、論理メッセージ宛先の名前を使用してJNDIルックアップを実行し、実際のメッセージ宛先にアクセスします。論理JMSメッセージ宛先は、個々のMDBまたはアプリケーション全体を対象として定義できます。

未解決および使用不可なメッセージ宛先の処理方法については、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBとメッセージ宛先のリファレンスに関する項を参照してください

個々のMDBの論理JMSメッセージ宛先を構成する

個々のMDBの論理JMSメッセージ宛先を構成できます。

MDBを構成して、実際のメッセージ宛先にリンクする論理メッセージ宛先を使用するには:

1. weblogic-ejb-jar.xmlのmessage-destination-descriptor要素でメッセージ宛先を宣言します。

2. ejb-jar.xmlの以下の要素で、メッセージ宛先の参照を宣言します。

- message-destination-ref

- message-destination-ref-name - メッセージ宛先に対応する、エンタープライズBeanコードで使用される環境名。java:comp/envを基準とします。例: <message-destination-ref>jms/StockQueue</message-destination-ref>。

- message-destination-type - 参照される宛先の期待されるタイプ(例: <message-destination-type>javax.jms.Queue</message-destination-type>)。

- message-destination-usage - メッセージが宛先から消費されるか、宛先用に生成されるか、またはその両方かを指定します(例: <message-destination-usage>Produces<message-destination-usage>)。

- message-destination-link - メッセージ宛先の参照を実際のメッセージ宛先にリンクします。この値は、weblogic-ejb-jar.xmlファイルのmessage-destination-name要素で定義する宛先と一致する必要があります。

アプリケーション・スコープの論理JMSメッセージ宛先を構成する

このリリースのOracle WebLogic Serverでは、アプリケーションのリソースを構成できます。構成するアプリケーション全体のリソースを、アプリケーション・スコープ・リソースと呼びます。この項では、EJBアプリケーションのアプリケーション・スコープ論理JMS宛先について説明します。JMSやJDBCなどのアプリケーション・スコープ・リソースの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』および『Oracle WebLogic Server JDBCアプリケーションの開発』を参照してください。

EJBのアプリケーション・スコープ・リソース(論理JMSメッセージ宛先など)は、アプリケーションのすべてのMDBに適用されます。個々のMDBのアプリケーション・スコープJMSをオーバーライドするには、MDBを構成して、実際のメッセージ宛先にリンクする論理メッセージ宛先を使用します(個々のMDBの論理JMSメッセージ宛先を構成するを参照)。

EJBのアプリケーション・スコープJMSを構成するには:

1. weblogic-ejb-jar.xmlのmessage-destination-descriptor要素でメッセージ宛先を宣言します。

2. ejb-jar.xmlの以下の要素で、メッセージ宛先の参照を宣言します。

- message-driven

- message-destination-type - 参照される宛先の期待されるタイプ(例: <message-destination-type>javax.jms.Queue</message-destination-type>)。

- message-destination-usage - メッセージが宛先から消費されるか、宛先用に生成されるか、またはその両方かを指定します(例: <message-destination-usage>Produces<message-destination-usage>)。

- message-destination-link - メッセージ宛先の参照を実際のメッセージ宛先にリンクします。<message-destination-link>ExpenseProcessingQueue<message-destination-link>)。この値は、weblogic-ejb-jar.xmlファイルのmessage-destination-name要素で定義する宛先と一致する必要があります。

- message-destination

- message-destination-name - メッセージ宛先の名前(例: <message-destination-name>ExpenseProcessingQueue<message-destination-name>)。この値は、weblogic-ejb-jar.xmlのmessage-destination-name要素で定義する宛先と一致する必要があります。

7 EJB 3.2準拠MDBの使用

この章では、EJB 3.2準拠MDBのプログラミングと実装の方法について説明します。

この章には次の項が含まれます:

- EJB 3.2準拠MDBの実装

- EJB 3.2準拠MDBのプログラミング

EJB 3.2準拠MDBの実装

EJB 3.2準拠のMDBを実装するには、『Oracle WebLogic Server Enterprise JavaBeansの開発』のEJB開発プロセスの概要に関する項で説明している手順を実行します。

EJB 3.2準拠MDBのプログラミング

EJB 3.2準拠MDBをプログラミングするには、『Oracle WebLogic Server Enterprise JavaBeansの開発』のBeanファイルのプログラミング: 通常の手順に関する項で説明している手順を実行します。

EJBタイプをメッセージドリブンとして宣言するには、@javax.ejb.MessageDrivenアノテーションを使用する必要があります。次のオプション属性を指定できます。

- messageListenerInterface - メッセージ・リスナー・インタフェースを明示的に実装していない場合や、Beanに追加のインタフェースを実装する場合に、メッセージ・リスナー・インタフェースを指定します。

注意:

Beanでサポートするメッセージング・タイプに必要なメッセージ・リスナー・インタフェース(またはそのメッセージ・リスナー・インタフェースのメソッド)を、Beanクラスに直接的または間接的に実装する必要があります。JMSの場合であれば、メッセージ・リスナー・インタフェースはjavax.jms.MessageListenerインタフェースになります。

- activationConfig: 動作環境でBeanを構成する配列構成プロパティを指定します。
アクティブ化構成プロパティは、MDBのデプロイ時にMDBコンテナに渡される名前と値のペアです。このプロパティは、ejb-jar.xmlデプロイメント記述子内または、MDB Beanクラスで@ActivationConfigPropertyアノテーションを使用するかのいずれかの方法で宣言できます。@ActivationConfigPropertyアノテーションを使用する例は、例7-1に示されています。ejb-jar.xmlデプロイメント記述子を使用する例は、例7-2に示されています。

ejb-jar.xml記述子でアクティブ化構成プロパティを設定するには、例7-2で示されているように、message-drivenスタンザのactivation-config-property要素を使用します。

アクティブ化構成プロパティは、ejb.jarデプロイメント記述子内か、またはactivationConfigPropertyアノテーション・プロパティを使用することで設定できるため、両方の場所で同じ名前が使用される場合には競合が起こる場合があります。3.0以前のバージョンのEJBまたは独自のOracle WebLogic Server EJBアノテーションから同一の名前のプロパティを使用することによっても、競合が起こる可能性があります。このような競合は、高から低の順番で次の優先順序に従うと解決されます。:

1. weblogic-ejb-jar.xmlデプロイメント記述子に設定されるプロパティ

2. 固有のOracle WebLogic Server 10.0 (以降)のアノテーション

3. ejb-jar.xmlデプロイメント記述子に設定されるactivation-config-propertyプロパティ

4. activationConfigPropertyアノテーション・プロパティ

たとえば、同一のプロパティがweblogic-ejb-jar.xml記述子およびejb-jar.xml記述子に存在する場合、weblogic-ejb-jar.xmlの方のプロパティが優先度が高くなり、ejb-jar.xmlの値をオーバーライドします。あるいは、同一のプロパティがejb-jar.xml記述子の要素およびactivationConfigPropertyアノテーションの両方に設定されている場合、記述子の要素の方が優先され、アノテーションは無視されます。

アクティブ化構成プロパティの詳細は、『Oracle WebLogic Server Enterprise JavaBeansの開発』のjavax.ejb.ActivationConfigPropertyに関する項を参照してください。表11-1では、Oracle WebLogic Serverによってサポートされるアクティブ化構成プロパティをまとめてあるので、こちらも参照してください。

注意:

Enterprise JavaBean仕様に基づき、javax.ejb.ActivationConfigPropertyアノテーションはMDBでのみ使用されます。このアノテーションは、セッションまたはエンティティBeanでは使用されません。

「MDBとメッセージング・モデル」で説明されているメッセージング・モードをサポートするMDBの開発の詳細は、「MDBのプログラミングと構成: 詳細」を参照してください。

例7-1 @ActivationConfigPropertyコード例

. . .
@ActivationConfigProperties(
{
@ActivationConfigProperty(
name="connectionFactoryJndiName", value="JNDINameOfMDBSourceCF"
),
@ActivationConfigProperty(
name="initialContextFactory", value="weblogic.jndi.WLInitialContextFactory"
)
}
)
. . .

例7-2 ejb-jar.xmlで設定されるアクティブ化構成プロパティ

<message-driven>
. . .
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationLookup</activation-config-property-name>
<activation-config-property-value>myQueue</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
<activation-config-property>
</activation-config>
. . .
</message-driven>
<message-driven>
. . .
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationLookup</activation-config-property-name>
<activation-config-property-value>myQueue</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
<activation-config-property>
</activation-config>
. . .
</message-driven>

アノテーションを使用するMDBサンプル

例7-3はWebLogic MDBを示します。これは、(Oracle WebLogic Server 10.3.4以降の)WebLogic JMSキューへのサブスクリプションを使用し、メッセージ・トランザクションを処理してターゲットの宛先にメッセージを転送します。

JMS接続ファクトリMyCFを使用してMDBは接続し、キューMyQueueから受信します。そして、接続ファクトリMyTargetCFから生成された接続を使用して、メッセージをMyTargetDestに転送します。

リソース参照プーリング・ノート: MDBは、リソース参照を使用してMyTargetCFにアクセスします。『Oracle WebLogic Server JMSアプリケーションの開発』の「WebLogic JMSをEJBやサーブレットと使用するための拡張サポート」で説明されているように、リソース参照によりJMSプロデューサのプーリングが自動的に可能になります。

キューではなくトピックを使用する同様のサンプルは、例10-1を参照してください。

これはWebLogic 10.3.4/11gR1PS3またはそれ以降のJMSトピックに恒久的にサブスクライブするサンプルOracle WebLogic MDBで、メッセージ・トランザクションを処理してターゲットの宛先にメッセージを転送します。

JMS接続ファクトリ"MyCF"を使用してMDBは接続し、トピック"MyTopic"から受信します。そして、接続ファクトリ"MyTargetCF"から生成された接続を使用して、メッセージを"MyTargetDest"に転送します。

リソース参照プーリング・ノート: MDBは、リソース参照を使用して"MyTargetCF"にアクセスします。リソース参照は、『Oracle WebLogic Server JMSのプログラミング』の「WebLogic JMSをEJBおよびサーブレットと併用するための拡張サポート」の章のとおりに、自動的にJMSプロデューサ・プーリングを有効化します。

例7-3 分散キューを使用するMDBのサンプル

package test;
import javax.annotation.Resources;
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.MessageDrivenContext;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.jms.*;

@MessageDriven(
name = "MyMDB",
activationConfig = {
@ActivationConfigProperty(propertyName  = "destinationType",
propertyValue = "javax.jms.Queue"),

@ActivationConfigProperty(propertyName  = "connectionFactoryJndiName",
propertyValue = "MyCF"), // External JNDI Name

@ActivationConfigProperty(propertyName  = "destinationJndiName",
propertyValue = "MyQueue") // Ext. JNDI Name
}
)

@Resources ({
@Resource(name="targetCFRef",
mappedName="MyTargetCF",   // External JNDI name
type=javax.jms.ConnectionFactory.class),

@Resource(name="targetDestRef",
mappedName="MyTargetDest", // External JNDI name
type=javax.jms.Destination.class)
})

public class MyMDB implements MessageListener {

// inject a reference to the MDB context

@Resource
private MessageDrivenContext mdctx;

// cache targetCF and targetDest for re-use (performance)

private ConnectionFactory targetCF;
private Destination targetDest;

@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
public void onMessage(Message message) {

System.out.println("My MDB got message: " + message);

// Forward the message to "MyTargetDest" using "MyTargetCF"

Connection jmsConnection = null;

try {
if (targetCF == null)
targetCF = (javax.jms.ConnectionFactory)mdctx.lookup("targetCFRef");

if (targetDest == null)
targetDest = (javax.jms.Destination)mdctx.lookup("targetDestRef");

jmsConnection = targetCF.createConnection();
Session s = jmsConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer mp = s.createProducer(null);

mp.send(targetDest, message);

} catch (JMSException e) {

System.out.println("Forcing rollback due to exception " + e);
e.printStackTrace();
mdctx.setRollbackOnly();

} finally {

// Closing a connection automatically returns the connection and
// its session plus producer to the resource reference pool.

try { if (jmsConnection != null) jmsConnection.close(); }
catch (JMSException ignored) {};
}

// emulate 1 second of "think" time

try { Thread.currentThread().sleep(1000); }
catch (InterruptedException ie) {
Thread.currentThread().interrupt(); // Restore the interrupted status
}
}

}

8 クラスタ化MDBの移行とリカバリ

この章では、クラスタ化されたMDBの移行とリカバリについて説明します。Oracle WebLogic Serverは、クラスタ化されたJMS宛先の移行とリカバリをサポートします。障害の発生時に、異なるJVM上でJMS宛先をオンラインに復帰させることが可能です。サーバー・インスタンスでエラーが発生したとき、JMS宛先をクラスタ内の障害が発生したサーバーから使用可能なサーバー・インスタンスに自動的に移行するように、クラスタを設計できます。

その結果、移行したJMS宛先に関連付けられたMDBデプロイメントは自動的に更新されます。このような更新には、MDBプールの終了と再初期化および/またはJMS宛先への再接続が含まれます。

警告:

サービスの移行は、次の場合にはお薦めできません。このような場合、移行はメッセージの損失またはメッセージ処理の重複という結果になる可能性があります。

ケース1 次のすべてがtrueの場合。

- MDBのtopicMessagesDistributionModeがOne-Copy-Per-Serverです

- MDBのdistributedDestinationConnectionがLocalOnlyです

- MDBがDurableです

- 宛先が重複した分散トピックの論理名として構成されています

ケース2 次のすべてがtrueの場合。

- MDBのtopicMessagesDistributionModeがCompatibilityです

- MDBがDurableです

- 宛先が分散トピックの論理名として構成されています

ケース3 次のすべてがtrueの場合。

- MDBのtopicMessagesDistributionModeがOne-Copy-Per-Applicationです

- MDBのdistributedDestinationConnectionがLocalOnlyです

- 移行ターゲット・サーバーにMDBインスタンスが含まれていません。この問題を避けるためのベスト・プラクティスは、MDBデプロイメントをクラスタ全体にターゲット指定することです。

トピック・メッセージ処理の詳細は、JMSトピックを使用したMDBの構成とデプロイを参照してください。

注意:

移行可能サービスは、クラスタ化サーバーを使用する場合にのみ機能します。WebLogic JMS宛先は、クラスタ内の別のサーバーに移行できますが、異なるクラスタには移行できません。

WebLogic JMS宛先が別のサーバーに移行した後、MDBデプロイメントまたは「接続ポーラー」は移行されたJMS宛先に再接続し、JMS宛先からメッセージをもう一度受信を開始します。MDBは、必要に応じてプールを作成して終了することも可能です。

MDBは、クラスタまたは個別のOracle WebLogic Serverインスタンスにターゲット指定できますが、移行可能ターゲットには指定できません。MDBが同一のクラスタで移行可能な宛先として稼働している場合、MDBのソース宛先がホストされる可能性がある場所にMDBがデプロイされていることを確認する必要があります。それは、次の2つの方法で行うことができます。

- MDBを均一にクラスタにデプロイします。(推奨)

- 宛先をホストするJMSサーバーによって使用されるconfig.xmlファイル内の移行可能ターゲットの候補リストに存在するすべてのOracle WebLogic ServerインスタンスがMDBのターゲット・セットに含まれていることを確認します。移行可能ターゲットの構成の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ内の移行可能ターゲット・サーバーの理解に関する項を参照してください。

移行可能サービスの実装手順、およびクラスタ化されたアーキテクチャのWebLogic JMSの移行サービスおよび回復サービスの背景情報については、『Oracle WebLogic Server JMSリソースの管理』のクラスタ内での移行可能サービスとしてのJMSサービスに関する項を参照してください。

9 メッセージドリブンBeanでのバッチの使用

この章では、MDBトランザクションのバッチ処理について説明します。MDB内では、データベース・トランザクションを含む場合もあるビジネス・ロジックは、onMessage()メソッド内で実行されます。EJBアプリケーション内では、複数のMDBは複数のonMessage()呼出しを同時に実行できます。各onMessage()呼出しがコンテナ管理対象トランザクションを実行する場合、多数のオーバーヘッドが作成されます。

Oracle WebLogic Serverは、onMessage()が単一のトランザクションの下で同時に呼び出す、複数のコンテナ管理対象トランザクションMDBをグループ化するためのメカニズムを提供します。このメカニズムは、異なるonMessage呼出しのすべての処理を単一のリクエストに暗黙的にグループ化することによって、EJBアプリケーションのパフォーマンス向上に役立ちます。

MDB内でのトランザクション管理については、「MDBのトランザクション管理戦略の構成」を参照してください

注意:

トランザクション・バッチ処理は、すべてのMDBアプリケーションに対して有効というわけではありません。たとえば、MDBがデータベースに対して複数の呼出しを行うアプリケーションでは、データベースのデッドロックが発生する場合があります。トランザクション・バッチ処理機能を使用すると、MDBはトランザクションにつき、より多くの行をロックするようになり、これがデータベースのデッドロックを引き起こす場合があります。

この章には次の項が含まれます:

- MDBトランザクション・バッチ処理の構成

- MDBトランザクション・バッチ処理の仕組み

MDBトランザクション・バッチ処理の構成

max-messages-in-transaction要素を定義するか、またはactivationConfigPropertyで同等のプロパティを使用することによって、MDBトランザクションのバッチ処理を有効化できます。この要素は、weblogic-ejb-jar.xmlデプロイメント記述子のmessage-driven-descriptor要素の一部です。

max-messages-in-transactionは、Oracle WebLogic ServerがonMessage()トランザクションを処理する際に使用するバッチ・サイズを定義します。ただし、バッチ・サイズを増やすと、レイテンシが増大する場合があります。最初は5など、小さな値から設定してください。この値は、アプリケーションのパフォーマンスで許容される範囲で増やすことができます。

MDBバッチ処理の使用時に、トランザクションごとに処理されるメッセージ数が増加します。これによって、各トランザクションで実行中の処理が増加するため、タイムアウトするトランザクションの数が増加することがあります。weblogic-ejb-jar.xmlのtrans-timeout-seconds属性の値を増加させることによって、トランザクション・タイムアウトを増加できます。あるいは、次のように@TransactionTimeoutSecondsアノテーションを使用できます。

import weblogic.javaee.TransactionTimeoutSeconds;
...;
@TransactionTimeoutSeconds(value = 60);
...;
public class MyMDB ...

MDBトランザクション・バッチ処理の仕組み

MDBトランザクション・バッチ処理では、アプリケーション・コードを変更する必要がありません。アプリケーションに関しては、個々のメッセージは1つずつ処理されます。アプリケーション・レベルのメッセージ・リストはありません。

内部では、Oracle WebLogic Serverがバッチ処理用のトランザクションを作成します。トランザクション内のメッセージ数が、max-messages-in-transactionによって定義されるバッチ・サイズまたはactivationConfigProperty内の同等のプロパティと等しくなるまで、メッセージがトランザクションに追加されます。メッセージ数がmax-messages-in-transactionに等しくなるか、またはトランザクションに追加される次のメッセージが存在しない場合、トランザクションは処理用に送信されます。図9-1を参照してください。

図9-1 MDBトランザクション・バッチ処理のトランザクション処理フロー

1つのonMessage()呼出しが失敗すると、バッチ全体がロールバックされます。その失敗が、weblogic-ejb-jar.xmlのtrans-timeout-seconds属性で定義されるトランザクションのタイムアウトに起因している場合、MDBコンテナはバッチ・サイズを一時的に減らし、小さなバッチでトランザクションの処理を試行します。

別の理由による失敗の場合、MDBは、失敗したバッチ内の各メッセージを個別のトランザクションとして再処理します。これによって、個々のonMessage()呼出しによって、バッチ全体が恒久的にハングする事態を回避できます。

10 JMSトピックを使用したMDBの構成とデプロイ

この章では、JMSトピックのサブスクリプションを自動的に設定し、サブスクリプション・メッセージを処理するMDBを開発する方法を説明します。JMSトピックにパブリッシュされるメッセージは、一致するセレクタ・フィルタを持つすべてのサブスクリプションにレプリケートされます。

デプロイされた単一のMDBは複数のトピック・サブスクリプションを作成し、ホストOracle WebLogic Serverインスタンスごとに1つ以上のフリー・プールを持つことが可能です。この動作は、MDB属性設定、トピック・タイプ、および同一のクラスタまたはJVMでトピックとしてMDBが実行されているかどうかによって制御されます。(MDBフリー・プールの詳細は、「MDBおよび同時実行処理」を参照してください。)

また、この章では、トピックMDBとWebLogic JMS分散トピックを併用する方法も説明します。WebLogic JMS分散トピックとは、複数の物理的なトピックから構成される論理トピックであり、各物理トピックは異なるJMSサーバー・インスタンス上でホストされます。この分散トピックの機能は、拡張性と高可用性を向上するためにOracle WebLogic Server 10.3.4で飛躍的に強化されました。この機能拡張には、リモートでホストされる分散トピック、複数の物理的なサブスクリプション全体に渡る単一の論理サブスクリプションの完全分散処理、および同一の物理的なサブスクリプションからメッセージを処理するための複数のJVMなどに関する直接サポートが含まれます。

この章には次の項が含まれます:

- サポートされるトピック・タイプ

- 最もよく使用されるMDB属性

- ベスト・プラクティス

- サービス移行の構成

- 以前のリリースからのアプリケーションのアップグレード

- トピックMDBのサンプル

JMSトピックの詳細は、次を参照してください。

- トピック・デプロイメント・シナリオ

- トピック・サブスクリプション識別子

- WebLogic MDBがWebLogic JMS拡張を活用する方法

- 『Oracle WebLogic Server JMSアプリケーションの開発』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』のWebLogic JMSのチューニングに関する項

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項

この章をお読みになる前にこのマニュアルの前の章を見直すことをお薦めします。

サポートされるトピック・タイプ

WebLogic MDBは次の種類のトピックをサポートします。

- シングルトン・トピック -- シングルトン・トピックは、非分散WebLogic JMSトピック、またはWebLogic JMS分散トピックの特定メンバー・トピックへの参照のいずれかです。WebLogic JMSの共通分散トピック・メンバーのJNDI名構文は、jms-server-name@jndi-name-of-distributed-topicメンバーをホストするJMSサーバー名に基づきます。

- 外部プロバイダ・トピック -- WebLogic以外のJMSトピックは、外部プロバイダ・トピックと呼ばれます。MDBは、シングルトン・トピックと同様に外部プロバイダを処理します。このようなトピックは通常、リモートとみなされます。

- レプリケートされた分散トピック -- WebLogic JMS分散トピックは、複数の物理トピックで構成される論理トピックで、各物理トピックは同一クラスタ内の異なるJMSサーバー・インスタンス上でホストされます。Oracle WebLogic Server 10.3.4以前のリリースでは、分散トピックのメンバーに送信される各メッセージは常に、分散トピックのすべての他のメンバー上のすべてのサブスクリプションに自動的にレプリケーション(転送)されます。この種類の分散トピックは依然としてサポートされていますが、レプリケートされた分散トピック(短縮形はRDT)と呼ばれます。

- パーティション化された分散トピック: WebLogic JMS分散トピックは、複数の物理トピックで構成される論理トピックで、各物理トピックは同一クラスタ内の異なるJMSサーバー・インスタンス上でホストされます。パーティション化された分散トピック(短縮形はPDT)は、メンバー間でメッセージを転送しません。PDTメンバーにパブリッシュされるメッセージは、該当メンバー上のサブスクリプションにのみコピーされます。パーティション化された分散トピックは、Oracle WebLogic Server 10.3.4以降でサポートされています。

分散トピック・タイプを構成するには、PartitionedまたはReplicatedをJMS分散トピック構成属性のJMS転送ポリシーの値として設定します。詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

最もよく使用されるMDB属性

最もよく使用されるトピックMDB属性は次のとおりです。

- JMS宛先と接続ファクトリ

- サブスクリプション永続性

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

- メッセージ分散チューニング

他の役に立つトピックMDB属性は次のとおりです。

- フリー・プール・サイズ

- デプロイ解除時の自動検出

- メッセージ・フィルタリング(JMSセレクタ)

- サブスクリプション識別子

メッセージ分散チューニング設定には、topicMessagesDistributionMode、distributedDestinationConnection、およびgenerate-unique-client-id属性が含まれます。

大半の属性は、アノテーションを使用するか、または記述子のXMLスタンザを介するかのいずれかの方法で構成できます。なお、記述子のXMLスタンザおよびアノテーションの固有の属性名は、MDBのデプロイメント要素およびアノテーションの表でまとめられています。

JMS宛先、宛先タイプ、および接続ファクトリの設定

トピックMDBの構成は、構成のJMS接続ファクトリ、宛先、および宛先タイプの場所を適切に指定する必要があります。通常、次の操作を実行すると指定できます。

1. トピック・タイプの指定。ejb-jar.xmlのmessage-driven-destination要素では、destination-typeをjavax.jms.Topicに設定します。あるいは、アノテーションを使用する場合、ActivationConfigPropertyをpropertyName = "destinationType"およびpropertyValue = "javax.jms.Topic"と共に指定します。

2. 接続ファクトリのJNDI名および宛先JNDI名の指定。接続ファクトリのJNDI名の指定は通常、接続ファクトリが同一のクラスタまたはサーバー上でMDBとしてホストされている場合には必要ではありません。通常はデフォルトで十分です。

3. 宛先がMDBプールとして同一クラスタまたはサーバーで存在していない場合、管理上、リモート宛先および接続ファクトリのJNDIエントリからのマッピングを、#2で指定されたエントリに一致するローカルJNDIエントリに構成します。リモート・リソースを参照する方法には別の選択肢がありますが、オラクル社がお薦めするベスト・プラクティスはマッピングする方法です。

各フリー・プールでは、MDBコンテナが指定した接続ファクトリを使用して接続を作成し、接続を使用してその宛先上の1つ以上のサブスクリプションを検索または作成して、最後に接続を使用してサブスクリプションからメッセージを受信するJMSコンシューマを作成します。

接続ファクトリと宛先MDB属性の固有名、およびお薦めのJNDIマッピング構成については、「宛先用のMDBの構成」を参照してください

サブスクリプション永続性の設定

MDBは、JMSトピック上でサブスクリプションを自動作成します。JMSトピックは、恒久および非恒久の2種類のサブスクリプションをサポートします。

- 非恒久サブスクリプションは、サブスクライバの存続期間中のみ存在します。サブスクリプションにこれ以上サブスクライバが含まれないとき、そのサブスクリプションは自動的に削除されます。非恒久サブスクリプションに保存されるメッセージは、JMSサーバーが停止またはクラッシュすると絶対に復元されません。

- 恒久サブスクリプションを使用すると、サブスクライバ・アプリケーションが使用できない期間にパブリッシュされるメッセージをサブスクライバが受信できるようになります。トピック上の各恒久サブスクリプションでは、メッセージの送信時にサブスクリプション上でアクティブなサブスクライバが存在しない場合でも、JMSは送信されるまで(または期限が切れるまで)ファイルまたはデータベース内のパブリッシュされた永続メッセージのそれぞれのコピーを保存します。また、JMSは各恒久サブスクリプション内の非永続メッセージそれぞれのコピーも保存しますが、JMSサーバーが停止またはクラッシュするとそのようなメッセージは復元されません。
非恒久サブスクリプションはデフォルトです。恒久サブスクリプションを指定するには、ejb-jar.xmlのmessage-driven-destination要素で、subscription-durabilityをDurableに設定します。あるいは、アノテーションを使用する場合、ActivationConfigPropertyをpropertyName = "subscriptionDurability"およびpropertyValue = "Durable"と共に指定します。

恒久サブスクリプションの自動検出の設定

MDBのデプロイが解除されるか、またはMDBがサーバーから削除されたとき、恒久トピック・サブスクリプションを自動削除するようにMDBを構成できます。恒久トピック・サブスクリプションを自動削除するようにMDBを構成するには、durable-subscription-deletionをTrueに設定します。デフォルトでは、durable-subscription-deletionはFalseに設定されています。

コンテナ管理対象トランザクションの設定

「MDBのトランザクション管理戦略の構成」を参照してください

メッセージ・フィルタリング(JMSセレクタ)の設定

JMSは、標準的なJMSメッセージ・ヘッダー・フィールドとメッセージ・プロパティに基づいてメッセージをフィルタリングするためのSQLスタイルの構文を提供します。また、WebLogic JMSはセレクタ構文への拡張機能をサポートします。これを使用すると、XMLコンテンツに基づいたXMLメッセージのフィルタリングに使用されるXMLの「xpath」式を含むセレクタを指定できます。

メッセージ・セレクタを指定するには、propertyName = "messageSelector"を持つActivationConfigPropertyのpropertyValueとしてセレクタを指定します。

JMSセレクタの構文は、javax.jms.MessageクラスのJavadocで詳細に説明されています。WebLogicのxpathのセレクタ拡張構文の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージのフィルタリングに関する項を参照してください。

MDB同時実行性の制御

トピック・デプロイメント・シナリオで説明されているように、MDBデプロイメントは1つ以上のMDBフリー・プールを作成できます。max-beans-in-free-poolおよびdispatch-policy descriptor属性が共に機能し、次に示すようにMDBフリー・プール内でMDBスレッドの同時実行性を制御します。

- 同時実行性MDBの数を決定する方法の説明は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の同時実行性MDBの数の決定に関する項を参照してください。

- MDBのtopicMessagesDistributionModeがCompatibilityに設定され、MDBがコンテナ管理対象トランザクションを使用するとき、同時実行性MDBの呼出しは妨害されます。また、max-beans-in-free-poolは、外部(WebLogic以外の)トピックによって主導されるBean管理対象トランザクションMDB用に明示的に1に設定する必要があります。

警告:

非トランザクション外部トピック: 外部(WebLogic以外の)トピックと共に機能する非トランザクションMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。この設定に不具合があると、MDBアプリケーションがRuntimeまたはErrorの例外をスローするなど、特定の失敗がある場合にメッセージの損失につながる可能性があります。

順序単位: WebLogic JMSトピックから消費してWebLogic JMSの「順序単位」値を持つメッセージを処理する非トランザクション「互換性」モードのMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。このユース・ケースのような「順序単位」メッセージは、max-beans-in-free-poolを1に設定しない場合、順序通りに処理されない可能性があります。

詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項を参照してください。

サブスクリプション識別子の設定

各JMSトピック・サブスクリプションは、MDB構成設定の数に基づいてMDBが生成する、それぞれの「サブスクリプション識別子」に基づいて作成および参照されます。生成されたサブスクリプション識別子の構文の説明は、トピック・サブスクリプション識別子を参照してください。

メッセージ分散チューニングの設定

この項では、メッセージ分散チューニングの設定に関する方法と時期について説明します。これには、すべてのトピック・タイプ(シングルトン、外部、および分散)に適用される情報が含まれます。この設定には、topicMessagesDistributionMode、distributedDestinationConnection、およびgenerate-unique-client-id属性が含まれます。これらの属性によって、トピック・サブスクリプションが作成される場所、サブスクリプション識別子の種類、パブリッシュされたトピック・メッセージそれぞれに対してMDBが1回のみ処理するか、あるいはサーバーごとに1回のみ処理するかどうかが制御されます。

結果的に自動生成されるサブスクリプションID、サブスクリプションの場所、およびデプロイされたMDBフリー・プールの場所の詳細と図解は、トピック・デプロイメント・シナリオおよびトピック・サブスクリプション識別子を参照してください。

topicMessagesDistributionModeの設定

topicMessagesDistributionMode設定をdistributedDestinationConnection設定またはgenerate-unique-client-id設定と組み合せて使用し、トピック・メッセージ処理動作を制御します。topicMessagesDistributionModeを設定するには、同じ名前を持つ@ActivationConfigPropertyアノテーションを使用するか、またはejb-jar.xmlデプロイメント記述子で<activation-config-property>を指定します。

topicMessagesDistributionModeの有効な値は次のとおりです。

- One-Copy-Per-Application -- アプリケーションをホストするサーバーの数に関係なく、MDBアプリケーションが分散トピックに1度パブリッシュされた各メッセージを全体的に受信するように指定します。このモードは、Oracle WebLogic Server 10.3.4以降のWebLogic JMSシングルトンおよび分散トピックで機能します。

- One-Copy-Per-Server -- MDBアプリケーションの各デプロイメント・インスタンスが、分散トピックにパブリッシュされたすべてのメッセージを受信するように指定します。このモードは、Oracle WebLogic Server 10.3.4以降のWebLogic JMSシングルトンおよび分散トピックで機能します。

- 互換性 - (デフォルト) MDBアプリケーションが、10.3.4以前のOracle WebLogic Serverリリースで処理されたのと同じ方法で、分散トピックからのメッセージを処理するよう指定します。このモードは、外部(WebLogic以外の)トピック、ローカルでレプリケートされた分散トピック(RDT) 、およびシングルトンWebLogicトピックを使用する恒久/非恒久サブスクリプションをサポートします。また、リモートRDTを使用する非恒久サブスクリプションもサポートします。詳細は、互換性に関する注意事項を参照してください。

注意:

最新のアプリケーションには、One-Copy-Per-ApplicationおよびOne-Copy-Per-Serverモードを使用することをお薦めします。ただし、Oracle WebLogic Server 10.3.4以前のバージョンにおけるWebLogic JMSトピックまたは外部(WebLogic以外の)トピックから消費する必要があるアプリケーションは除きます。

トピック分散モードは、次の制約を持つ様々なトピック・タイプおよびバージョンをサポートします。

- One-Copy-Per-ApplicationおよびOne-Copy-Per-Serverモードは、WebLogicシングルトンおよびOracle WebLogic Server 10.3.4以降の分散トピックを使用する場合のみ機能します。WebLogicのMDBは、外部(WebLogic以外の)トピック使用時またはOracle WebLogic Serverリリース10.3.4以前からのWebLogicトピックの使用時には警告を記録し、前述のモードを使用するメッセージを処理しません。

- One-Copy-Per-ApplicationトピックMDBの内、恒久的かつ、ローカル RDTをサブスクライブし、distributedDestinationConnection属性にデフォルトのLocalOnly値を使用するものは、サービスの移行をサポートせず、Oracle WebLogic Serverインスタンスごとに1つのトピック・メンバーのみを構成するように求めます。サービスの移行が実行される場合、ローカル・トピック・メンバーが構成される場合、またはサーバーごとに1つ以上のトピック・メンバーがデプロイされる場合、アプリケーションではメッセージの重複または損失が発生し、未処理のメッセージを蓄積する中止サブスクリプションも作成する場合があります。サービスの移行が必要な場合、distributedDestinationConnection属性にデフォルトのLocalOnlyではなく、EveryMemberオプションを使用します。

- 互換性モードは、外部(WebLogic以外の)トピック、ローカルでレプリケートされた分散トピック(RDT) (後述する制限を持つ)、およびシングルトンWebLogicトピックを使用する恒久/非恒久サブスクリプションをサポートします。また、互換性モードはリモートRDTを使用する非恒久サブスクリプションもサポートします。リモートRDTの論理JNDI名をサブスクライブする恒久的なMDBのデプロイメントは正常に実行されますが、MDBデプロイメントは接続に失敗し、警告ログ・メッセージが表示されます。同様に、WebLogic PDTをサブスクライブするMDBのデプロイメントは正常に実行されますが、MDBデプロイメントは接続に失敗し、警告ログ・メッセージが表示されます。詳細は、「topicMessagesDistributionModeの互換性モードについての注意点」を参照してください。

- ローカルRDTをサブスクライブする恒久的なMDBの互換性モードは、「topicMessagesDistributionModeの互換性モードについての注意点」を参照してください

MDBが生成したサブスクリプション、サブスクリプションID、およびフリー・プールの場所の詳細と図解は、トピック・デプロイメント・シナリオおよびトピック・サブスクリプション識別子を参照してください。

distributedDestinationConnectionの設定

ローカル分散トピックについてtopicMessagesDistributionModeのOne-Copy-Per-ApplicationおよびOne-Copy-Per-Serverモードの動作を任意で詳細にチューニングするには、distributedDestinationConnectionアクティブ化構成プロパティを使用できます。あるいは、weblogic-ejb-jar.xmlデプロイメント記述子のdistributed-destination-connection要素を使用できます。有効な値は、LocalOnlyおよびEveryMemberです。

distributedDestinationConnection設定は、Oracle WebLogic Server MDBコンテナがクラスタ全体の各サブスクリプションに対してローカルMDBフリー・プールを設定するか(EveryMember)、あるいは現在のOracle WebLogic Serverにローカルなメンバー上のサブスクリプションに対してのみローカル・フリー・プールを設定するかどうかを指定します(LocalOnly: デフォルト)。

distributedDestinationConnectionの使用は次のように制限されます: リモート・クラスタをサブスクライブするMDBに対して指定する場合は、警告メッセージが表示されてオプションが無視されます。互換性モードで使用する場合、警告メッセージが表示されてオプションが無視されます。

EveryMemberを使用する理由の1つは、恒久的なMDBのLocalOnlyには、One-Copy-Per-Serverモード時のローカルRDTに関する制限があるからです。「恒久的なMDBとローカルRDTを併用する際の警告」を参照してください

EveryMemberを使用するもう1つの理由は、不均一なメッセージ・ロードまたはメッセージ処理の遅延を最適に処理するためです。詳細は、「不均一なメッセージ・ロードおよび/またはメッセージ処理の遅延の処理方法」を参照してください。

topicMessagesDistributionModeの互換性モードについての注意点

- サポートされるトピック・タイプとバージョンの説明は、「topicMessagesDistributionModeの設定」を参照してください。

- topicMessagesDistributionModeの互換性を非トランザクションMDBと組み合せて使用しており、トピックが外部(WebLogic以外の)宛先であるか、またはトピックが順序単位(UOO)メッセージを使用するWebLogic宛先の場合、警告については、「MDB同時実行性の制御」を参照してください。

- 動作を変更するには、generate-unique-client-id属性を設定します。

- generate-unique-client-idがtrueに設定されている場合、恒久的なMDBフリー・プールはそれぞれ固有のサブスクライバIDを生成します。それぞれのMDBフリー・プールは、パブリッシュされたメッセージそれぞれのコピーを受信します。詳細は、トピック・サブスクリプション識別子を参照してください。フリー・プールの詳細は、MDBおよび同時実行性処理およびトピック・デプロイメント・シナリオを参照してください。

- generate-unique-client-idがfalse (デフォルト)に設定されている場合、恒久的なMDBによってサブスクリプションが1つのみ作成され、1つのMDBフリー・プールのみが恒久サブスクリプションに正常に接続されます(残りのMDBプールは接続に失敗し、警告を記録して再試行を続けます)。

- ローカルでレプリケートされた分散トピック(ローカルRDT)の論理名をサブスクライブする恒久サブスクリプションMDBの場合、「恒久的なMDBとローカルRDTを併用する際の警告」で説明される構成のみがサポートされます。

- リモートでレプリケートされたトピック(リモートRDT)の論理名をサブスクライブする恒久サブスクリプションMDBの場合、次のようになります。

- RDTの論理JNDI名をサブスクライブする恒久的なMDBのデプロイメントは正常に実行されますが、MDBデプロイメントは接続に失敗し、警告ログが表示されます。

- リモートでレプリケートされたトピックの特定のメンバー宛先をサブスクライブする恒久サブスクリプションMDBの場合、次のようになります。

- RDTメンバーを直接サブスクライブする恒久MDBのデプロイメントは正常に実行されますが、後続の動作はgenerate-unique-client-id設定によって決定されます。共通分散宛先の場合、特定のメンバーのJNDI名は"jms-server-name@udd-jndi-name"となります。

- ローカルでレプリケートされた分散トピック(ローカルRDT)の論理名、リモートでレプリケートされたトピック(リモートRDT)、外部トピック、またはシングルトン・トピックの論理名をサブスクライブする非恒久サブスクリプションMDBの場合、各サーバーはトピックに送信された各メンバーのコピーを受信します。

- distributedDestinationConnectionオプションは、互換性モードには適用されません。設定すると、警告メッセージが表示され、オプションは無視されます。

ベスト・プラクティス

MDBの構成に役立てるため、次の項の情報を検討します。

互換性モード使用時の非トランザクションMDBについての警告

topicMessagesDistributionModeの互換性モードを非トランザクションMDBと組み合せて使用しており、トピックが外部(WebLogic以外の)宛先であるか、またはトピックが順序単位(UOO)メッセージを使用するWebLogic宛先の場合、警告については、「MDB同時実行性の制御」を参照してください。

恒久的なMDBとローカルRDTを併用する際の警告

互換性モードでは、ローカルでレプリケートされた分散トピック(ローカルRDT)の論理名をサブスクライブする恒久サブスクリプションMDBの場合、次の構成のみがサポートされます。

- 常にgenerate-unique-client-idをtrueに設定します。

- クラスタ内の各Oracle WebLogic ServerがRDTのメンバーのみをホストしていることを確認します。

- WebLogic JMS service-migrationは使用しないでください。このユース・ケースには対応していません。ただし、「サーバー全体の移行」を使用できます。

- 各サーバーは、トピックに送信された各メッセージのコピーを受信することに注意します。メッセージがRDTの物理的なトピック・メンバーのいずれかに着信すると、メッセージのコピーが他のトピック・メンバーそれぞれに転送されることをRDTが自動的に確認します。

同様に、distributedDestinationConnectionがLocalOnlyに設定されているときにOne-Copy-Per-Applicationモードでは、ローカルでレプリケートされた分散トピック(ローカルRDT)の論理名をサブスクライブする恒久サブスクリプションMDBの場合、次の構成のみがサポートされます。

- 使用中の構成がお薦め構成と一致しない場合、メッセージの損失、メッセージの重複、メッセージのスタックなどの非確定的動作が発生する可能性があります。別の選択肢を含む詳細は、「topicMessagesDistributionModeの設定」を参照してください。

恒久的なMDB属性、トピック・タイプ、EJB名の変更についての警告

MDBまたはJMS設定を変更すると、恒久サブスクリプション上の現在のメッセージが削除されたり、新規の恒久サブスクリプションに従って既存の恒久サブスクリプションが中止、削除、または置換されたりする可能性があります。このような設定には、トピック・タイプ、JMSセレクタ、分散チューニング、サブスクリプション永続性、ejb-name、およびclient-idが含まれます。

中止された恒久サブスクリプションは、MDBがメッセージを処理していない場合でもメッセージを蓄積し続けます。これによって、割当の例外やJVMメモリー不足エラーが発生し、これ以上メッセージがトピックにパブリッシュされなくなってしまう可能性があります。

中止サブスクリプションの検索および削除の説明は、『Oracle WebLogic Server JMSアプリケーションの開発』の恒久サブスクリプションの管理に関する項を参照してください。サブスクリプションIDおよび場所の説明は、トピック・サブスクリプション識別子を参照してください。

パーティション化されたトピックとレプリケートされたトピックのどちらを選択するか

「サポートされるトピック・タイプ」では、2種類のWebLogic分散トピック(パーティション化されたトピックとレプリケートされたトピック)を説明しています。一般的に、次の2つの使用事例を除き、使用できる場合はパーティション化されたトピック(PDT)の使用をお薦めします。

- 従来のアプリケーションまたはMDB以外のアプリケーションと同時に使用するために、レプリケートされたトピック(RDT)の動作が必要な場合。

- 特定のメッセージ・ロードの下、One-Copy-Per-Server LocalOnlyのローカルRDTの場合。メッセージ・ロードは、PDTのOne-Copy-Per-Serverモードにおいて完全に接続されたトポロジに必要なネットワーク・トラフィックの増加と比較して、RDTに組み込まれた転送オーバーヘッドの負荷のコストが低くなっているかどうかを判定します。一般的に、非永続性または「軽量の」永続性メッセージ・ロードには、PDTを使用する方が無難です。

分散トピック・タイプを構成するには、PartitionedまたはReplicatedをWebLogic JMS分散トピック構成属性のJMS転送ポリシーの値として設定します。詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

MDBトピック・メッセージ分散モードの選択

最新のアプリケーションには、One-Copy-Per-ApplicationおよびOne-Copy-Per-Serverモードを使用することをお薦めします。ただし、Oracle WebLogic Server 10.3.4以前のバージョンにおけるWebLogic JMSトピックまたは外部(WebLogic以外の)トピックから消費する必要があるアプリケーションは除きます。これら2つのモードは、Oracle WebLogic Server 10.3.4以降のWebLogic JMSトピックを使用する場合にのみ機能します。

サブスクリプションの管理と表示

サブスクリプションの名前と場所の説明は、トピック・デプロイメント・シナリオおよびトピック・サブスクリプション識別子を参照してください。

『Oracle WebLogic Server JMSアプリケーションの開発』の恒久サブスクリプションの管理に関する項も参照してください。

不均等なメッセージ負荷および/またはメッセージ処理の遅延の処理方法

不均等なメッセージ負荷または予期しないメッセージ処理の遅延が発生したアプリケーションでは、次の事項を検討する必要があります。

- ローカル分散トピックの場合、トピック分散モードがOne-Copy-Per-ServerまたはOne-Copy-Per-Applicationのとき、distributedDestinationConnectionをEveryMemberにチューニングします。LocalOnlyオプションは、不要なネットワーク・トラフィックを回避するため、極めて良好なパフォーマンスを発揮できますが、ユース・ケースによっては、LocalOnly最適化のネットワークの節約よりも、バランシングされていないキューの負荷のためにクラスタ内のすべてのJVM間でメッセージ処理をできるかぎり均等に分散するメリットのほうが勝ります。これは特に、メッセージのバックログがクラスタ全体で不均等に生じ、メッセージ処理にコストがかかる場合に問題になる可能性があります。このようなユース・ケースでは、恒久サブスクリプションを使用するEveryMemberシナリオを採用し、LocalOnly構成は避けるべきです。

- 各プロデューサのメッセージがクラスタ全体でラウンドロビン方式に基づいて均一に処理されるように、RDTのかわりにPDTを使用して、プロデューサの接続ファクトリでプロデューサのロード・バランシングをチューニングします。受信メッセージは、WebLogic JMS接続ファクトリの「サーバー・アフィニティの有効化」および「ロード・バランシングの有効化」属性を使用して、分散トピック・メンバー間でロード・バランシングされます。アフィニティを無効化すると、ネットワーク・オーバーヘッドが増加しますが、メッセージはクラスタ全体に渡って均一にロード・バランシングされることが保証されます。アフィニティ設定はRDTに何の影響を及ぼしません。『Oracle WebLogic Server JMSリソースの管理』の分散宛先全体でのメッセージのロード・バランシングに関する項を参照してください。

- WebLogic JMS非同期メッセージ・パイプラインのサイズを1まで下げ、前のメッセージ処理ですでにブロックされているMDBスレッドにこれ以上メッセージがプッシュされないようにします。この設定のデフォルトは10です。この値は、(a) 「最大メッセージ数」属性が 1にチューニングされ「XA有効化」が「true」に設定されたカスタムWebLogic接続ファクトリを構成する、(b) 接続ファクトリを分散トピックをホストする同一のクラスタにターゲット指定する、および(c) カスタム接続ファクトリを参照するようにMDBを変更することで構成できます。

サービス移行用の構成

恒久サブスクリプションの場合、JMSサービス移行(自動または手動)は、LocalOnlyがローカルでレプリケートされたトピックで適用されるとサポートされません。通常、LocalOnlyとは、分散トピック・メンバーが別のサーバーに移行されると、MDBデプロイメント・インスタンスがローカル分散トピック・メンバーに固定されることを示します。MDBデプロイメント・インスタンスは、再起動後に同一の元の分散メンバーをサブスクライブできません。実行した場合は、警告メッセージが表示される可能性があります。つまり、JMSサービス移行を使用するには、EveryMemberとして構成する必要があります。サーバー全体の移行は両クラスでサポートされています。

以前のリリースからのアプリケーションのアップグレード

この章全体を通して説明しているように、緩和されたクライアントID、共有可能なサブスクリプション、およびパーティション化された恒久トピックなどのOracle WebLogic Server 10.3.4の新しいJMS機能を使用すると、拡張性と高可用性の拡張を提供するMDBを実装してデプロイできるようになります。これらの機能を活用するには、Oracle WebLogic Server 10.3.4以前のリリース用に記述されたMDBアプリケーションをアップグレードする必要があります。

Oracle WebLogic Server 10.3.4以前のリリースで実行するために記述されたアプリケーションは、互換性モードを使用すると変更せずに実行を継続できます。これは、「topicMessagesDistributionModeの設定」で説明したように、topicMessagesDistributionModeのデフォルト設定です。

以前のリリースからアプリケーションをアップグレードするには、次の手順を実行します。

1. パーティション化された分散トピックへの変更を検討します。「パーティション化されたトピックとレプリケートされたトピックのどちらを選択するか」を参照してください。

2. topicMessagesDistributionModeをOne-Copy-Per-ServerまたはOne-Copy-Per-Applicationに設定し、distributedDestinationConnectionオプションをチューニングします。「メッセージ分散チューニングの設定」を参照してください。

警告:

互換性モードから変更すると、現在のメッセージは保存されません。「恒久的なMDB属性、トピック・タイプ、EJB名の変更についての警告」を参照してください

トピックMDBのサンプル

例10-1はWebLogic MDBを示します。これは、(Oracle WebLogic Server 10.3.4以降の) JMSトピックへの恒久サブスクリプションを使用し、メッセージ・トランザクションを処理してターゲットの宛先にメッセージを転送します。

JMS接続ファクトリMyCFを使用してMDBは接続し、トピックMyTopicから受信します。そして、接続ファクトリMyTargetCFから生成された接続を使用して、メッセージをMyTargetDestに転送します。

リソース参照プーリング・ノート: MDBは、リソース参照を使用してMyTargetCFにアクセスします。『Oracle WebLogic Server JMSアプリケーションの開発』の「WebLogic JMSをEJBやサーブレットと使用するための拡張サポート」で説明されているように、リソース参照によりJMSプロデューサのプーリングが自動的に可能になります。

トピックではなくキューを使用する同様のサンプルは、例7-3を参照してください。

例10-1 分散トピックを使用するMDBのサンプル

package test;
import javax.annotation.Resources;
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.MessageDrivenContext;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.jms.*;

@MessageDriven(
name = "MyMDB",
activationConfig = {
@ActivationConfigProperty(propertyName  = "destinationType",
propertyValue = "javax.jms.Topic"),

@ActivationConfigProperty(propertyName  = "subscriptionDurability",
propertyValue = "Durable"),

@ActivationConfigProperty(propertyName  = "connectionFactoryJndiName",
propertyValue = "MyCF"), // External JNDI Name

@ActivationConfigProperty(propertyName  = "destinationJndiName",
propertyValue = "MyTopic"), // Ext. JNDI Name

@ActivationConfigProperty(propertyName  = "topicMessagesDistributionMode",
propertyValue = "One-Copy-Per-Application")
}
)

@Resources ({
@Resource(name="targetCFRef",
mappedName="MyTargetCF",   // External JNDI name
type=javax.jms.ConnectionFactory.class),

@Resource(name="targetDestRef",
mappedName="MyTargetDest", // External JNDI name
type=javax.jms.Destination.class)
})

public class MyMDB implements MessageListener {

// inject a reference to the MDB context

@Resource
private MessageDrivenContext mdctx;

// cache targetCF and targetDest for re-use (performance)

private ConnectionFactory targetCF;
private Destination targetDest;

@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
public void onMessage(Message message) {

System.out.println("My MDB got message: " + message);

// Forward the message to "MyTargetDest" using "MyTargetCF"

Connection jmsConnection = null;

try {
if (targetCF == null)
targetCF = (javax.jms.ConnectionFactory)mdctx.lookup("targetCFRef");

if (targetDest == null)
targetDest = (javax.jms.Destination)mdctx.lookup("targetDestRef");

jmsConnection = targetCF.createConnection();
Session s = jmsConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer mp = s.createProducer(null);

mp.send(targetDest, message);

} catch (JMSException e) {

System.out.println("Forcing rollback due to exception " + e);
e.printStackTrace();
mdctx.setRollbackOnly();

} finally {

// Closing a connection automatically returns the connection and
// its session plus producer to the resource reference pool.

try { if (jmsConnection != null) jmsConnection.close(); }
catch (JMSException ignored) {};
}

// emulate 1 second of "think" time

try { Thread.currentThread().sleep(1000); }
catch (InterruptedException ie) {
Thread.currentThread().interrupt(); // Restore the interrupted status
}
}

}

11 MDBのデプロイメント要素とアノテーション

この章は、MDBの動作に影響を及ぼすデプロイメント要素と構成プロパティを示します。表11-1の各行は、デプロイメント要素(EJBデプロイメント記述子で使用)およびそれに関連する構成プロパティ(アノテーションで指定)を記載しています。すべての要素が関連プロパティを持つとは限りません。

デプロイメント記述子の使用とMDBのアノテーションの詳細は、「EJB 3.2準拠MDBのプログラミング」を参照してください。

注意:

関連構成プロパティを持つ要素の場合、要素のかわりに該当するプロパティを使用することをお薦めします。

表11-1は、次のように構成されています。

- 要素列の各要素の後には、カッコの中に要素が使用されるデプロイメント記述子名が続きます。weblogic-ejb-jar.xml記述子の要素は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のweblogic-ejb-jar.xmlのデプロイメント記述子のリファレンスに関する項に記載されている要素の詳細説明にリンクしています。ejb-jar.xmlの要素については、http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsdのスキーマを参照してください。

- 特に断りのないかぎり、構成プロパティ列にリスト表示されているすべてのプロパティは、アクティブ化構成プロパティです。つまり、ejb-jar.xml記述子のmessage-drivenスタンザにある@ActivationConfigPropertyアノテーションまたはactivation-config-property要素を使用して定義されたプロパティです。@ActivationConfigPropertyの使用に関する詳細は、EJB 3.2準拠MDBのプログラミングに関する項を参照してください

注意:

Enterprise JavaBean仕様に基づき、javax.ejb.ActivationConfigPropertyアノテーションはMDBでのみ使用されます。このアノテーションは、セッションまたはエンティティBeanでは使用されません。

- また、構成プロパティ列は、アノテーションや@ActivationConfigPropertyプロパティ以外のプロパティもリストしています。これらの場合、プロパティの後にはアノテーション名および当該アノテーションの使用に必要なimport文が続きます。

表11-1 MDBのデプロイメント要素とアノテーション

要素

構成プロパティ

説明

有効な値

デフォルト値

activation-config-property

(ejb-jar.xml)

acknowledgeMode

メッセージが受信および処理されたことをJMSプロバイダに通知します。コンテナ管理トランザクションを使用する場合は、確認応答モードは無視されます。(確認応答はトランザクションのコンテキストで実行されます。)

- AUTO_ACKNOWLEDGE: メッセージはただちに確認されます

- DUPS_OK_ACKNOWLEDGE: 確認応答は遅延し、重複メッセージが受信される可能性があります

AUTO_ACKNOWLEDGE

connection-factory-jndi-name

(weblogic-ejb-jar.xml)

connectionFactoryLookup

JMSメッセージドリブンBeanのメッセージの受信元であるJMSプロバイダに接続するために使用するJMS接続ファクトリのルックアップ名。

有効なルックアップ名

weblogic.jms.MessageDrivenBeanConnectionFactory

connection-factory-jndi-name

(weblogic-ejb-jar.xml)

connectionFactoryJndiName

キューおよびトピックを作成するためにMDBがルックアップするJMS ConnectionFactoryのJNDI名。「connection-factory-jndi-nameの設定方法」を参照してください

有効なJNDI名

weblogic.jms.MessageDrivenBeanConnectionFactory

connection-factory-resource-link

(weblogic-ejb-jar.xml)

connectionFactoryResourceLink

ejb-jar.xmlに定義されているJMSモジュール内のリソースをOracle WebLogic Serverの実際のJMSモジュール参照にマップします。ほとんど使用されません。

JMSモジュール内の有効なリソース

なし

destination-jndi-name

(weblogic-ejb-jar.xml)

destinationLookup

JMSメッセージドリブンBeanのメッセージの受信元であるJMSキューまたはトピックのルックアップ名。

有効なルックアップ名

なし

destination-jndi-name

(weblogic-ejb-jar.xml)

destinationJndiName

Oracle WebLogic Server JNDIツリーにデプロイされている実際のJMSキューまたはトピックにMDBを関連付けるために使用するJNDI名。「destination-jndi-nameの設定方法」を参照してください

有効なJNDI名

なし

destination-resource-link

(weblogic-ejb-jar.xml)

destinationResourceLink

ejb-jar.xmlに定義されているJMSモジュール内のリソースをOracle WebLogic Serverの実際のJMSモジュール参照にマップします。ほとんど使用されません。

JMSモジュール内の有効なリソース

なし

dispatch-policy

(weblogic-ejb-jar.xml)

なし

このオプション要素を使用すると、Beanに特定のWorkManagerを指定できるようになります。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項を参照してください。

有効な実行キューの名前

なし

distributed-destination-connection

(weblogic-ejb-jar.xml)

distributedDestinationConnection

同一クラスタ内のWebLogic JMS分散宛先(トピックまたはキュー)にアクセスするMDBが、すべての分散宛先メンバーから消費するか、または現在のOracle WebLogic Serverインスタンスに対してローカルの分散宛先メンバーのみから消費するかを指定します。すべてのユース・ケースに適用することはできません。JMS分散宛先およびJMSトピックを使用したMDBの構成とデプロイを参照してください。

- LocalOnly

- EveryMember

LocalOnly

durable-subscription-deletion

(weblogic-ejb-jar.xml)

durableSubscriptionDeletion

MDBがアンデプロイまたは削除されるときに恒久トピック・サブスクリプションが自動的に削除されるようにするかどうかを指定します。

- True

- False

False

generate-unique-jms-client-id

(weblogic-ejb-jar.xml)

weblogic.javaee.JMSClientIDアノテーションのgenerateUniqueClientID属性を参照してください。

EJBコンテナが一意のclient-idをMDBのすべてのインスタンスに対して生成するかどうかを示します。この設定は、topicMessagesDistributionModeが互換性(デフォルト)に設定されているときにのみ使用する必要があります。JMSトピックを使用したMDBの構成とデプロイを参照してください。

- True

- False

False

initial-beans-in-free-pool

(weblogic-ejb-jar.xml)

なし

フリー・プールの初期サイズを設定します。Oracle WebLogic Serverは起動時に、Beanクラスごとに指定された数のBeanインスタンスをフリー・プールに格納します。この方法でBeanインスタンスをフリー・プールに格納しておくと、要求が来てから新しいインスタンスを生成せずにBeanに対する初期リクエストが可能になるため、MDBの初期レスポンス時間が短縮されます。

0からmaxBeans

0

initial-context-factory

(weblogic-ejb-jar.xml)

initialContextFactory

接続ファクトリの作成にEJBコンテナが使用する初期コンテキスト・ファクトリ。「initial-context-factoryの設定方法」を参照してください

初期コンテキスト・ファクトリの有効な名前

weblogic.jndi.WLInitialContextFactory

init-suspend-seconds

(weblogic-ejb-jar.xml)

initSuspendSeconds

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する初期秒数。「JMSリソース停止中のメッセージ配信の中断の構成」を参照してください

任意の整数

5

jms-client-id

(weblogic-ejb-jar.xml)

clientID

JMSメッセージドリブンBeanのメッセージの受信元であるJMSプロバイダに接続する際に使用するクライアントID。

なし

topicMessagesDistributionModeアクティブ化構成プロパティに依存し、generate-unique-client-idにも依存する可能性があります。トピック・サブスクリプション識別子を参照してください

jms-client-id

(weblogic-ejb-jar.xml)

jmsClientId

JMS宛先に接続時のMDBのクライアントID。オプションです。JMSトピックへの恒久サブスクリプションに使用されます。詳細は、トピック・サブスクリプション識別子を参照してください。

なし

topicMessagesDistributionModeアクティブ化構成プロパティに依存し、generate-unique-client-idにも依存する可能性があります。トピック・サブスクリプション識別子を参照してください

jms-polling-interval-seconds

(weblogic-ejb-jar.xml)

jmsPollingIntervalSeconds

アクセスできなくなっているJMS宛先にEJBコンテナが再接続しようとする試みの秒間隔。「クラスタ化MDBの移行とリカバリ」を参照してください

任意の整数

10秒

max-beans-in-free-pool

(weblogic-ejb-jar.xml)

なし

MDBフリー・プール内のBeanインスタンスの最大数。また、インスタンスの実際の数は、スレッド・プール・サイズおよびその他の要因によっても制限されます。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージドリブンBeanのチューニングに関する項を参照してください。

0からmaxBeans

1000

max-messages-in-transaction

(weblogic-ejb-jar.xml)

maxMessagesInTransaction

MDBのトランザクションに入れることができるメッセージの最大数を指定します。

すべての正の整数

なし

max-suspend-seconds

(weblogic-ejb-jar.xml)

maxSuspendSeconds

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する最大秒数。「JMSリソース停止中のメッセージ配信の中断の構成」を参照してください

任意の整数

60

message-destination-type

(ejb-jar.xml)

destinationType

JMS宛先のタイプ(宛先で実装されるJavaインタフェース)を指定します。

- javax.jms.Queue

- javax.jms.Topic

なし

messages-maximum

(weblogic-ejb-jar.xml)

messagesMaximum

非同期セッション向けに存在でき、メッセージ・リスナーにまだ渡されていないメッセージの最大数。値-1は、メッセージ数に制限がないことを示します。ただし、この場合、残っている仮想メモリーの量に制限が設定されます。

メッセージ数が特定の値に到達すると、次の対応が行われます。

- マルチキャスト・セッションでは、指定された超過時のポリシーに従って新しいメッセージが破棄され、DataOverrunExceptionがスローされます。

- 非マルチキャスト・セッションでは、新しいメッセージはフロー制御されるか、アプリケーションがメッセージに対応できるようになるまでサーバーに保持されます。

マルチキャスト・セッションでは、接続が停止された場合、メッセージは蓄積され続けますが、指定された最大値に到達するまでの間にかぎられます。一度最大値に達すると、メッセージは超過時のポリシーに基づいて破棄されます。

-1および1–263-1

10

message-selector

(ejb-jar.xml)

messageSelector

ヘッダー・フィールド参照およびプロパティ参照ごとに、関連のあるメッセージを指定するためにクライアントによって使用される文字列。ヘッダーとプロパティ値がセレクタに一致するメッセージのみが送信されます。

メッセージ・プロパティまたはメッセージ・ヘッダーを使用する条件式

NULL

messaging-type

(ejb-jar.xml)

なし

ほとんど使用されません。

javax.jms.MessageListener

なし

provider-url

(weblogic-ejb-jar.xml)

providerURL

InitialContextで使用されるURLプロバイダ。通常はhost:portです。「provider-urlの設定方法」を参照してください

有効なURL

NULL

resource-adapter-jndi-name

(weblogic-ejb-jar.xml)

resourceAdapterJndiName

JCAドリブンMDBの場合、このMDBがメッセージを受信する元のリソース・アダプタを識別します。

なし

なし

security-role-assignment

(weblogic-ejb-jar.xml)

なし

ejb-jar.xmlファイルのアプリケーション・ロールをOracle WebLogic Serverのセキュリティ・プリンシパルの名前にマップします。

なし

なし

start-mdbs-with-application

(weblogic-application.xml)

なし

MDBがいつメッセージの処理を開始するのかを制御します。trueに設定すると、Oracle WebLogic Serverが完全に起動していなくても、MDBはそのデプロイメントと同時にメッセージの処理を開始します。このため、MDBアプリケーションは起動の途中で初期化されていないサービスやアプリケーションにアクセスし、失敗することがあります。

falseに設定すると、Oracle WebLogic Serverがそのリスニング・ポートを開くまでメッセージの処理が延期されます。

- True

- False

False

subscription-durability

(ejb-jar.xml)

subscriptionDurability

JMSトピック・サブスクリプションがDurableまたはNonDurableかを指定します。詳細は、「サブスクリプション永続性の設定」を参照してください

- Durable

- NonDurable

NonDurable

activation-config-property

(ejb-jar.xml)

subscriptionName

トピックにパブリッシュされたメッセージを受信するように想定されている場合のサブスクリプション名。恒久または非恒久トピック・サブスクライバにこのプロパティを設定できます。

なし

なし

なし

topicMessagesDistributionMode

トピック・メッセージの配信モードを設定します。JMSトピックを使用したMDBの構成とデプロイを参照してください。

- One-Copy-Per-Application

- One-Copy-Per-Server

- Compatibility

Compatibility

transaction-type

(ejb-jar.xml)

「trans-attribute」を参照してください。

エンタープライズBeanのトランザクション管理タイプを指定します。詳細は、「MDBのトランザクション管理戦略の構成」を参照してください

- Bean

- Container

Container

trans-attribute

(ejb-jar.xml)

@TransactionAttributeのTransactionAttributeTypeプロパティです。例:

import javax.ejb.TransactionAttribute
@TransactionAttribute(TransactionAttributeType.REQUIRED)

メソッドの呼出しをエンタープライズBeanのビジネス・メソッドに委託するときにコンテナがトランザクションの境界をどのように管理するのかを指定します。

注意: コンテナ管理トランザクションの境界設定を使用するようにBeanが指定されている場合、メッセージ・リスナー・メソッドにREQUIREDまたはNOT_SUPPORTEDトランザクション属性を使用する必要があり、タイムアウト・コールバック・メソッドにREQUIRED、REQUIRES_NEWまたはNOT_SUPPORTEDトランザクション属性を使用する必要があります。詳細は、「MDBのトランザクション管理戦略の構成」を参照してください

- Required

- NotSupported

- Supports

- RequiresNew

- Mandatory

- Never

Required

trans-timeout-seconds

(weblogic-ejb-jar.xml)

@TransactionTimeoutSeconds

import weblogic.javaee.TransactionTimeoutSeconds

EJBのコンテナで初期化されたトランザクションの最長継続時間(秒単位)。この時間を過ぎると、トランザクションはロールバックされます。「MDBのトランザクション管理戦略の構成」を参照してください

0からmax

トランザクション・タイムアウトが指定されていない、または0に設定されている場合、ドメインに構成されているトランザクション・タイムアウトが使用されます。ドメインにタイムアウトが構成されていない場合、デフォルトは30です。

use81-style-polling

(weblogic-ejb-jar.xml)

use81StylePolling

Oracle WebLogic Serverバージョン8.1方式のポーリングの後方互換性を有効にします。

- True

- False

False

activation-config-property

(ejb-jar.xml)

aqMDBReceiveNoWait

AQ JMSがMDBのJMSプロバイダで、このプロパティがtrueに設定されている場合、同期ポーリングはMessageConsumer.receiveNoWait()メソッドを使用して、QA JMSデキュー・パフォーマンスを最適化します。

- True

- False

False

activation-config-property

(ejb-jar.xml)

mdbDestinationPollIntervalMillis

JMS宛先にメッセージがなく、MDBに対して同期ポーリングが使用されている場合、このプロパティはメッセージ・ポーリング間隔をミリ秒で設定します。MDBがAQ JMSと相互運用し、minimizeAQSessionsがtrueに設定されている場合、このプロパティを5000より大きい値に設定することでデータベース接続使用のバーストを回避できます。この構成では、複数のMDBが開始されると、ランダムにメッセージ・ポーリングを開始します。

0以上(整数)

0

activation-config-property

(ejb-jar.xml)

minimizeAQSessions

このプロパティは、MDBがAQ JMSと相互作用する場合にのみ使用されます。このプロパティがtrueに設定されると、動的にAQ JMSセッションを終了することでデータベース・リソースの使用を減らします。

- True

- False

False

activation-config-property

(ejb-jar.xml)

TopicMessagePartitionMode

別々のパーティションにデプロイされたMDBが同じトピック宛先にサブスクライブされると、このプロパティではWebLogic Server Multitenant (MT)環境のパーティション間のMDBトピック・サブスクリプション共有が管理されます。

- Isolated

- Shared

分離されている

window.name='dist_topic_scenarios' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
A トピック・デプロイメント・シナリオ

この付録では、様々なトピックのMDB構成におけるMDBのデプロイメント・アクションについて説明します。アクションには、MDBフリー・プールが作成される場所およびその数、サブスクリプションが作成される場所およびその数、所定のメッセージング消費パターンを達成するためにサブスクライバが共に機能する仕組みなどが含まれます。

この項では、topicMessagesDistributionModeがCompatibilityに設定されている場合、トピックが外部の(WebLogic以外の)トピックの場合、またはトピックがOracle WebLogic Serverリリース10.3.4以前のWebLogic JMSトピックの場合に発生するレガシー動作の詳細は説明しません。

お薦めの設定を含むアプリケーションの適切なシナリオ(順列)を決定するためのヘルプは、JMSトピックを使用したMDBの構成とデプロイを参照してください。

この付録の内容は次のとおりです。

- 構成の順列がデプロイメント・アクションを決定する仕組み

- 一般的なシナリオ

構成の順列がデプロイメント・アクションを決定する仕組み

次の設定は、(Oracle WebLogic Server 10.3.4以降の) WebLogic JMSトピックから消費するWebLogic MDBが、MDBフリー・プールのインスタンス、サブスクリプションのネーミング、サブスクリプションの場所を作成する方法、およびメッセージがMDBプール・インスタンスに配信される方法を決定します。

- (MDBデプロイメントとしての同一クラスタまたはサーバー内、あるいはリモート・クラスタまたはサーバー上の)トピックの場所。

- トピック・タイプ(シングルトンWebLogicトピック、レプリケートされた分散トピックまたはパーティション化された分散トピック)。

- subscriptionDurability設定。

- topicMessagesDistributionModeおよびdistributedDestinationConnection設定。

表A-1は、可能な構成の順列および対応するデプロイメント・アクションを説明しています。最初の2列が構成の順列を説明し、最後の2列は結果のデプロイメントを説明します。列は次のとおりです。

- topicMessagesDistributionMode -- topicMessagesDistribution構成オプションの値。つまり、One-Copy-Per-ServerまたはOne-Copy-Per-Applicationです。従来の互換性モードは、この表に変換されません。

- トピック・タイプの順列: オプションには次が含まれます。

- LocalまたはRemote -- トピックが、MDB (ローカル)として同一のクラスタまたはサーバーにデプロイされるか、あるいは異なるクラスタまたはサーバー(リモート)にデプロイされるかどうか。

- PDT、RDT、または単一のWebLogic JMSトピック: トピックの種類が、パーティション化された分散トピック(PDT)、レプリケートされた分散トピック(RDT)、または単一のWebLogic JMSトピックのいずれであるかを示します。

- EveryMemberまたはLocalOnly -- distributedDestinationConnectionの値。同一クラスタ内のLocal分散トピックにアクセスするMDBが、すべての分散トピック・メンバーから消費するか、または現在のサーバーに対してローカルの分散トピック・メンバーのみから消費するかを指定します。EveryMemberとLocalOnlyのどちらも指定されない場合、順列はdistributedDestinationConnectionの設定に関係なく適用されます。

たとえば、トピック・タイプの順列「Local RDT LocalOnly」は、「MDBは同一クラスタ(Local)に、レプリケートされたトピック(RDT)としてデプロイされ、そのMDBは同じOracle WebLogic Server上のトピック・メンバーからのみ(LocalOnly)消費するように構成される」ことを意味します。

- 各サーバーのサブスクライブ先 -- Oracle WebLogic Serverインスタンスが作成するMDBプールの数、およびMDBインスタンスのサブスクライブ対象となる分散トピックのメンバー。例:

- 「各サーバーのサブスクライブ先 ... すべてのメンバー」は、「コンテナは分散トピックの各メンバーに対して1つのローカルMDBプールを作成する」ことを意味します。

- 「各サーバーのサブスクライブ先 ... すべてのローカル・メンバー」は、「コンテナは、同一サーバー上で稼働中の各メンバーに対して1つのMDBプールを作成し、各MDBプールはそれらのメンバーのいずれか1つをサブスクライブする」ことを意味します。

- サーバーごとにMDBプール -- クラスタ内の各サーバー上のMDBデプロイメント・インスタンスの数(およびそれによる分散トピック・メンバーへの接続数)。M = 分散トピック・メンバー数(スタンドアロン・トピックの場合はM=1)。

表A-1 構成の順列およびその結果として起こるデプロイメント・アクション

MDB構成

デプロイメント・アクション

topicMessagesDistributionMode

トピック・タイプの順列

各サーバーのサブスクライブ先

サーバーごとにMDBプール

One-Copy-Per-Server

- RDT Local LocalOnly脚注 1

ローカル・メンバーの1つ

1つ

One-Copy-Per-Server

- RDT Remote (非恒久のみ)脚注 2

リモート・メンバーの1つ

1つ

One-Copy-Per-Server

- PDT Local EveryMember脚注 3

- PDT Remote脚注

- RDT Local EveryMember

- RDT Remote (恒久サブスクリプションのみ)脚注

- 単一のWebLogic JMS (M=1)

すべてのメンバー

M

One-Copy-Per-Application

- PDT Local LocalOnly

- RDT Local LocalOnly

すべてのローカル・メンバー

ローカル・メンバーごとに1つ

One-Copy-Per-Application

- PDT Local EveryMember

- PDT Remote脚注

- RDT Local EveryMember

- RDT Remote脚注

- 単一のWebLogic JMS (M=1)

すべてのメンバー

M

脚注 1

「One-Copy-Per-Server、RDT、Local、LocalOnly」の順列は、一部の構成トポロジにおける恒久サブスクリプションではサポートされていません(詳細は、シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費を参照してください)。

脚注 2

リモート分散トピックの場合、「One-Copy-Per-Server, Replicated Distributed Topic, Remote」の順列の非恒久サブスクリプションは除き、Oracle WebLogic Serverは常にすべてのトピック・メンバーに対してサブスクリプションを作成します。この場合、任意のリモート・メンバーに対して1つのサブスクリプションのみが作成されます。(シナリオ3: レプリケートされたDT、サーバーごとに1つのコピー、リモート・デプロイメントを参照してください)

脚注 3

LocalOnly設定は、「One-Copy-Per-Server, Partitioned Distributed Topic, Local」の順列で常にEveryMemberと自動的に置換されます。(シナリオ7: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費を参照してください)

一般的なシナリオ

次の項では、MDBアプリケーションの予想されるデプロイメント・シナリオを示します。

- スタンドアロン(非分散)トピック・シナリオ

- レプリケートされた分散トピック・シナリオ

- パーティション化された分散トピック・シナリオ

シナリオ内の図で使用されるイメージおよびラベルは、表A-2で説明されます。

表A-2 シナリオ内で使用されるイメージおよびテキストの説明

イメージまたはテキスト

説明

分散トピックにパブリッシュされるメッセージ。

メッセージは重複し、コピーが他のトピック・メンバーに転送されます。つまり、トピックはレプリケートされた分散トピックということになります。

DTメンバーn

分散トピックのメンバー。

MDBプール

MDBフリーBeanプール。

サブスクリプション。矢印の一端にあるMDBは、矢印のもう一端にあるトピックからのメッセージをリスニングして消費します。

共有サブスクリプション。

非共有サブスクリプション。S1は管理対象サーバー1のサブスクリプション、S2は管理対象サーバー2のサブスクリプションなどとなります。

スタンドアロン(非分散)トピック・シナリオ

スタンドアロン・トピック・シナリオは次のとおりです。

One-Copy-Per-Server

MDBアプリケーションをホストする各Oracle WebLogic Serverインスタンスでは、MDBプールは、トピックが同一のクラスタ内または異なるクラスタ内のどちらで実行されているかに関係なく、トピックに対して作成されます。N個のノードのMDBクラスタでは、N個のMDBプールが作成されます。各MDBプールはトピック上に個別のサブスクリプションを作成し、異なるMDBプールからのサブスクライバは同一のサブスクリプションを共有しません。

One-Copy-Per-Application

MDBアプリケーションをホストする各Oracle WebLogic Serverインスタンスでは、MDBプールは、トピックが同一のクラスタ内または異なるクラスタ内のどちらで実行されているかに関係なく、トピックに対して作成されます。N個のノードのMDBクラスタでは、N個のMDBプールが作成されます。同一のMDBアプリケーションのMDBプールによって作成されるすべてのサブスクライバは、同一のサブスクリプションを共有します。

レプリケートされた分散トピック・シナリオ

レプリケートされた分散トピックでは、すべての物理的なトピック・メンバーは各送信済メッセージを受信します。メッセージが物理的なトピック・メンバーのいずれかに着信すると、メッセージのコピーが内部で自動的に他のトピック・メンバーに転送されます。

次は、レプリケートされた分散トピックの予想されるデプロイメント・シナリオです。

- シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ2: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ3: レプリケートされたDT、サーバーごとに1つのコピー、リモート・デプロイメント

- シナリオ4: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ5: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ6: レプリケートされたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

図A-1は次の構成を示します。

- レプリケートされた分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Server

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = LocalOnly

図A-1 シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

このシナリオでは、

- メッセージのコピーは、RDTによってクラスタ内の他のサーバーに転送されます。

- 1つのMDBプールは、ローカル・クラスタ内の各サーバー上に作成されます。

- 各MDBプールは、同一サーバー上の分散トピック・メンバーのいずれか1つをリスニングします。

この方法では、すべてのメッセージングがローカルとなり(ネットワーク・コール全体に渡るメッセージの転送が回避)、すべての分散トピック・メンバーがMDBコンシューマによってサービスを提供されることが保証されるため、「RDT, One Copy Per Server, Local Deployment, EveryMember」よりも高いパフォーマンスが発揮されます。ただし、一部の使用状況では、「不均一なメッセージ・ロードおよび/またはメッセージ処理の遅延の処理方法」で説明されるトレードオフに基づき、EveryMemberを選択した方がパフォーマンスが上がる場合があります

このシナリオは、同一サーバー上に複数のメンバーが存在する場合、MDBアプリケーションをホストするローカル・サーバーのいずれかにメンバーが存在しない場合、またはJMSサービス移行(自動/手動)が関連する場合、恒久サブスクリプションでは適切に機能しません。

シナリオ2: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

図A-2は次の構成を示します。

- レプリケートされた分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Server

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = EveryMember。

図A-2 シナリオ2: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

このシナリオでは、

- メッセージのコピーはRDTによってクラスタ内の他のサーバーに転送されますが、MDBサブスクリプションによってフィルタ・アウト(無視)されます。

- MDBプールは、ローカル・クラスタ内の各サーバー上にある分散トピック・メンバーに対して作成されます。

- 各MDBプールは、クラスタ内の分散トピック・メンバーのいずれか1つをリスニングします。

- MDBアプリケーションをホストする各Oracle WebLogic Serverインスタンスは、分散トピックのすべてのメンバーをリスニングします。

- DTの同一メンバー上にある各サーバーのサブスクライバは、それぞれ独自のサブスクリプションを所有します。つまり、異なるサーバーから同一メンバーへのサブスクライバは、サブスクリプションを共有しません。

この構成では柔軟性が高くなるので、RDTが必要なアプリケーションには最適です。ただし、必ずしも正確にサーバーごとに1つのメンバーとなることは保証できません。移行などが原因で構成が変わることがあります。

この構成は、特に、移行が関連せず、各管理対象サーバー上に分散トピック・メンバーが1つのみ存在する静的環境では、「シナリオ1: レプリケートされたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費」と比較すると最高のパフォーマンスを発揮しません。移行が関連せず、各管理対象サーバー上に分散トピック・メンバーが1つのみ存在するアプリケーションでは、シナリオ1を使用できます。

シナリオ3: レプリケートされたDT、サーバーごとに1つのコピー、リモート・デプロイメント

図A-3は次の構成を示します。

- レプリケートされた分散トピック

- 恒久サブスクリプション

- topicMessagesDistributionMode = One-Copy-Per-Server

- MDBおよびトピックは、異なる(リモート)クラスタにデプロイされます。

- リモート・デプロイメントでは、distributedDestinationConnectionは無視されます。

図A-3 シナリオ3: レプリケートされたDT、サーバーごとに1つのコピー、リモート・デプロイメント

このシナリオでは、

- メッセージのコピーはRDTによってクラスタ内の他のサーバーに転送されますが、MDBサブスクリプションによってフィルタ・アウト(無視)されます。

- 各分散トピック・メンバーのMDBプールは、リモート・クラスタ内の各サーバー上で作成されます。

- MDBアプリケーションをホストする各Oracle WebLogic Serverインスタンスは、分散トピックのすべてのメンバーをリスニングします(各リモート・メンバーに対して1つのローカル・プール)。

- DTの同一メンバー上にある各サーバーのサブスクライバは、それぞれ独自のサブスクリプションを所有します。つまり、異なるサーバーから同一メンバーへのサブスクライバは、サブスクリプションを共有しません。

注意すべきは、恒久サブスクリプションの場合の動作であるということです。非恒久サブスクリプションの場合、各Oracle WebLogic Serverインスタンスは、最適化としてメンバーのいずれか1つ(任意のメンバー)に接続する単一のMDBプールを作成します。

シナリオ4: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

図A-4は次の構成を示します。

- レプリケートされた分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = LocalOnly

図A-4 シナリオ4: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

このシナリオでは、

- メッセージのコピーはRDTによってクラスタ内の他のサーバーに転送されますが、MDBサブスクリプションによってフィルタ・アウト(無視)されます。

- 1つのMDBプールが各ローカル・メンバーのローカル・クラスタ内の各サーバー上で作成されます(図A-5は、各Oracle WebLogic Serverインスタンスが1つのメンバーをホストする構成を示します。同一のローカルOracle WebLogic Serverインスタンス上に複数のメンバーが存在する場合、複数のMDBプールがサーバー上で作成されます)。

- メッセージは1つのMDBプールにのみ送信されます。

- 同一メンバー上のすべてのサブスクライバは、同一のサブスクリプションを共有します。

シナリオ5: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

図A-5は次の構成を示します。

- レプリケートされた分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = EveryMember。

図A-5 シナリオ5: レプリケートされたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

このシナリオでは、

- メッセージのコピーはRDTによってクラスタ内の他のサーバーに転送されますが、MDBサブスクリプションによってフィルタ・アウト(無視)されます。

- 1つのMDBプールは、各メンバーのローカル・クラスタ内の各サーバー上で作成されます。

- メッセージは1つのMDBプールにのみ送信されます。

- 同一メンバー上のすべてのサブスクライバは、同一のサブスクリプションを共有します。

シナリオ6: レプリケートされたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

図A-6は次の構成を示します。

- レプリケートされた分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、異なる(リモート)クラスタにデプロイされます。

- リモート・デプロイメントでは、distributedDestinationConnectionは無視されます。

図A-6 シナリオ6: レプリケートされたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

このシナリオでは、

- メッセージのコピーはRDTによってクラスタ内の他のサーバーに転送されますが、MDBサブスクリプションによってフィルタ・アウト(無視)されます。

- 1つのMDBプールは、リモート・クラスタ内の各メンバーのローカル・クラスタ内にある各サーバー上で作成されます。

- メッセージは1つのMDBプールにのみ送信されます。

- 同一メンバー上のすべてのサブスクライバは、同一のサブスクリプションを共有します。

パーティション化された分散トピック・シナリオ

パーティション化されたトピックを使用すると、

- メッセージ受信側の分散トピック・メンバーは、メッセージを認識する唯一のメンバーです。メッセージは他のメンバーに転送されず、他のメンバー上のサブスクライバはメッセージのコピーを取得しません。

- 受信メッセージは、JMSのAffinityおよびLoad Balance属性を使用して、分散トピック・メンバー間でロード・バランシングされます。詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックのロード・バランシングに関する項を参照してください。

次は、パーティション化された分散トピックの予想されるデプロイメント・シナリオです。

- シナリオ7: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ8: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ9: パーティション化されたDT、サーバーごとに1つのコピー、リモート・デプロイメント

- シナリオ9: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

- シナリオ11: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

- シナリオ12: パーティション化されたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

シナリオ7: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

このシナリオでは、distributedDestinationConnectionの設定は無視され、警告メッセージのログが記録されます。かわりに、設定は強制的にEveryMemberとなります。動作はEveryMemberの場合と同じになります(「シナリオ8: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費」を参照してください)。

シナリオ8: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

図A-7は次の構成を示します。

- パーティション化された分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Server

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = EveryMember。

図A-7 シナリオ8: パーティション化されたDT、サーバーごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

このシナリオでは、

- メッセージは分散トピック・メンバーに個別に配信されます。メッセージは重複したり、クラスタ内の他のメンバーにコピーされたりすることはありません。

- MDBプールは、ローカル・クラスタ内の各サーバー上にある分散トピック・メンバーに対して作成されます。

- DTの同一メンバー上にある各サーバーのサブスクライバは、それぞれ独自のサブスクリプションを所有します。つまり、特定のサーバーから同一メンバーへのサブスクライバは、別のサーバーのサブスクライバとサブスクリプションを共有しません。

シナリオ9: パーティション化されたDT、サーバーごとに1つのコピー、リモート・デプロイメント

このシナリオの詳細は、MDBデプロイメントおよびPDTが異なるクラスタ内にある点を除いて前のシナリオと同一です。

シナリオ9: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

図A-8は次の構成を示します。

- パーティション化された分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = LocalOnly

図A-8 シナリオ9: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費

このシナリオでは、

- メッセージは分散トピック・メンバーに個別に配信されます。メッセージは重複したり、クラスタ内の他のメンバーにコピーされたりすることはありません。

- 1つのMDBプールが各ローカル・メンバーのローカル・クラスタ内の各サーバー上で作成されます(図A-9は、各Oracle WebLogic Serverが1つのメンバーをホストする構成を示します。同一のローカルOracle WebLogic Serverインスタンス上に複数のメンバーが存在する場合、複数のMDBプールが各Oracle WebLogic Serverインスタンス上で作成されます)。

このシナリオは、高パフォーマンスのOne-Copy-Per-ApplicationおよびLocal PTの構成にお薦めできます。ただし、一部の使用状況では、「不均一なメッセージ・ロードおよび/またはメッセージ処理の遅延の処理方法」で説明されるトレードオフに基づき、EveryMemberを選択した方がパフォーマンスが上がる場合があります

シナリオ11: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

図A-10は次の構成を示します。

- パーティション化された分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、同一の(ローカル)クラスタにデプロイされます。

- distributedDestinationConnection = EveryMember。

図A-9 シナリオ11: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、すべてのメンバーが消費

パーティション化された分散トピック、アプリケーションごとに1つのコピー、ローカル・デプロイメントの組合せでは、「シナリオ9: パーティション化されたDT、アプリケーションごとに1つのコピー、ローカル・デプロイメント、ローカルのみの消費」で示されるように、大半のユース・ケースでLocalOnly消費を使用する方が無難です。ただし、「不均一なメッセージ・ロードおよび/またはメッセージ処理の遅延の処理方法」で説明されるトレードオフがこの場合は適用されます。

シナリオ12: パーティション化されたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

図A-10は次の構成を示します。

- パーティション化された分散トピック

- topicMessagesDistributionMode = One-Copy-Per-Application。

- MDBおよびトピックは、異なる(リモート)クラスタにデプロイされます。

- リモート・デプロイメントでは、distributedDestinationConnectionは無視されます。

図A-10 シナリオ12: パーティション化されたDT、アプリケーションごとに1つのコピー、リモート・デプロイメント

このシナリオでは、

- メッセージは分散トピック・メンバーに個別に配信されます。メッセージは重複したり、クラスタ内の他のメンバーにコピーされたりすることはありません。

- サブスクリプションはすべての分散トピック・メンバー上で動的に自動作成されます。

- メッセージは1つのMDBプールにのみ送信されます。

- 同一メンバー上にある同一MDBアプリケーションのすべてのサブスクライバは、同一のサブスクリプションを共有します。

window.name='topic_sub_ids' function footdisplay(footnum,footnote) { var msg = window.open('', 'NewWindow' + footnum, 'directories=no,height=120,location=no,menubar=no,resizable=yes,' + 'scrollbars=yes,status=no,toolbar=no,width=598'); msg.document.open('text/html'); }
B トピックのサブスクリプション識別子

この付録では、トピック・サブスクリプション識別子について説明します。JMSでは、サブスクリプションは次に基づいて識別および特定されます。

1. サブスクリプションが関連付けられているトピック

2. サブスクリプションにアクセスするために使用する接続に対して指定する、接続「クライアントID」文字列

3. 恒久サブスクリプションを使用する場合、サブスクリプション名。サブスクリプション名は次のいずれかによって設定されます。

- 恒久サブスクリプションが作成される場合

- SubscriptionName構成プロパティによって

SubscriptionNameプロパティを指定した場合、このプロパティを使用します。それ以外の場合、サブスクリプションが作成されると、サブスクリプション名が生成されます。

4. 「クライアントIDポリシー」オプション。これを使用しても、サブスクリプションはWebLogic JMSで識別されます。同一物理トピック上の2つのWebLogic JMSサブスクリプション参照が、同一のクライアントIDとサブスクリプション名を持つ場合、その参照は次のようになります。

- クライアントIDポリシーも同じ場合、単一のサブスクリプション

- クライアントIDポリシーが異なる場合、2つの異なるサブスクリプション

WebLogic MDBコンテナは、次の設定に基づいて、前述のリストの項目1から4を自動的に生成します。

- ejb-name

- jms-client-id

- topicMessagesDistributionMode

- SubscriptionName構成プロパティ

- distributedDestinationConnection

- generate-unique-client-id

- subscriptionDurability

- MDBデプロイメントおよびJMS構成の他の要素

最後の4つの設定は、互換性モードのMDBにのみ適用されます。

表B-1は、設定がサブスクリプションIDの生成に使用される仕組みをまとめています。

表B-1 サブスクリプションIDが生成される仕組み

設定

ClientID

恒久サブスクリプションの場合のサブスクリプション名

WebLogicトピックのクライアントIDポリシー

topicMessagesDistributionMode = One-Copy-Per-Application

jmsClientIDBase

SubscriptionNameプロパティ(使用する場合)。または、ejb-name

非制限

topicMessagesDistributionMode = One-Copy-Per-Server

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ currentServerName

SubscriptionNameプロパティ(使用する場合)。または、ejb-name

非制限

topicMessagesDistributionMode = Compatibility

generateUniqueClientID = true

distributedDestinationConnection = LocalOnly

subscriptionDurability = Durable脚注 1

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ uniqueKey

ClientIdまたはSubscriptionNameプロパティと同じ(使用する場合)

制限

次を除いて前の行と同一。

distributedDestinationConnection = EveryMember

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ uniqueKey

+ "_"

+ DDMemberName

ClientIdまたはSubscriptionNameプロパティと同じ(使用する場合)

制限

topicMessagesDistributionMode = Compatibility

generateUniqueClientID = false

subscriptionDurability = Durable脚注

jmsClientIDBase

ClientIdまたはSubscriptionNameプロパティと同じ(使用する場合)

制限

脚注 1

非恒久互換性モードのMDBは、クライアントIDまたはサブスクリプション名を設定せず、デフォルト制限クライアントIDポリシーを使用します。

キー:

- jms-client-id = MDB記述子またはアノテーションによって設定されるオプションのMDB属性文字列。あるいは(ただし、まれですが)、jms-client-idは、結果的に構成済のclient-idを持つカスタムJMS接続ファクトリを参照するためにMDBを変更することによって、設定できます

- SubscriptionName = 恒久サブスクリプション名を生成するオプションの設定。指定した場合、この設定は自動的に生成された名前よりも優先されます。

- ejb-name = EJB名

- jmsClientIDBase = jms-client-id (ユーザーによって指定される場合)またはejb-name (jms-client-idが指定されない場合)

- currentDomainName = MDBを実行するWebLogicドメイン名

- currentServerName = MDBが実行されているOracle WebLogic Server名

- uniqueKey = 一部のMDBデプロイメント要素を含む文字列(currentServerNameである可能性があります)。宛先が、移行可能なターゲットを使用しているJMSサーバーによってホストされるWebLogic宛先である場合、この文字列には移行可能なターゲット名が含まれています。

- DDMemberName = 分散宛先メンバー名。あるいは、トピックがシングルトンまたはOracle WebLogic Server 10.3.4より前のリリースの分散宛先の場合には、宛先名。

クライアントIDの一意性は次のとおりに強制されます。

- 外部(WebLogic以外)のJMSベンダーの場合: JMSベンダーの中には、1つ以上の接続が同一の接続クライアントIDを指定できなくするものがあります。(2番目の接続の作成を試行すると例外がスローされます。)1つ1つのフリー・プールが、他のフリー・プール接続と同じクライアントIDを持つ可能性がある単一のJMS接続を作成するため、この制限によって1つ以上のフリー・プールが同一のクライアントIDを使用できなくなる可能性があります。MDBの最初のフリー・プール・インスタンスがクラスタ内のサーバー・インスタンスを起動した後、EJBの追加インスタンスは別のクラスタ化サーバー上で正常にデプロイできます。ただし、MDBがJMS接続の作成を試行すると、クライアントIDの競合が検出され、MDBの当該インスタンスはJMSへの完全接続に失敗します。

- WebLogic JMSの場合: Oracle WebLogic Server 10.3.4以前のリリースのWebLogic JMSでは、JMS接続が制限されていたため、クラスタ範囲内に同一クライアントIDでの接続が1つのみ存在できました。ただし、Oracle WebLogic Server 10.3.4以降では、WebLogic JMS接続ファクトリまたは接続は、この制限を制御するために任意でクライアントIDポリシーを設定できます。クライアントIDポリシーをRESTRICTEDにすると、10.3.4以前の動作は残りますが、クライアントIDポリシーをUNRESTRICTEDにすると、制限は解除されます。詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』を参照してください。非制限クライアントIDを使用すると、複数のWebLogicサブスクライバ接続およびサブスクリプションが同一のクライアントIDを共有できるようになります。One-Copy-Per-ServerおよびOne-Copy-Per-Applicationのトピック・メッセージ配信モードは、ClientIDPolicyを非制限に設定します。同一物理トピック上の2つのWebLogic JMSサブスクリプション参照が、同一のクライアントIDと恒久サブスクリプション名を持つ場合、その参照は、クライアントIDポリシーも同一の場合には単一のサブスクリプションになり、クライアントIDポリシーが異なる場合は2つの異なるサブスクリプションになることに注意します。

C WebLogic MDBがWebLogic JMS拡張を活用する方法

この付録では、MDBが特定のWebLogic JMS機能を活用する方法について説明します。MDBデプロイメント・シナリオは、次のJMS機能を利用できるトピック・デプロイメント・シナリオに記述されています。

- 共有サブスクリプション -- 共有サブスクリプションによって、サブスクライバが異なるMDBサーバーから作成される場合でも、複数のサブスクライバは1つのサブスクリプションを共有できるようになります。同一のサブスクリプションを共有するすべてのサブスクライバは、トピックにパブリッシュされたすべてのメッセージをまとめて処理します。各メッセージは、サブスクライバのいずれか1つのみによって処理されます。たとえば、S1とS2というサブスクライバが2つあり、M1、M2、M3という3つのメッセージがある場合、S1はM1とM2を受信し(ただしM3は受信しません)、S2はM3を受信します(ただしM1とM2は受信しません)。
これによって、アプリケーションは単一のサブスクリプションのトピック・メッセージに関してラウンドロビン方式の分散処理または並列処理を採用できるようになります。MDBは、恒久/非恒久に関係なく、同一のサブスクリプション識別子で複数のサブスクライバを作成できます。JMSサブスクリプション共有ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』の共有サブスクリプションの構成に関する項を参照してください。

- 非制限クライアントID -- 制限クライアントIDを使用すると、複数の同時実行性アクティブ接続が同一のクライアントIDを使用できるようになります。JMSのclientIDはJMS接続を識別し、当該接続上で恒久サブスクリプションを識別するために使用されます。clientIDをUnrestrictedに設定すると、複数の物理的なサブスクリプションを異なる宛先上で同一名で作成できるようになります。これによって、同一名のサブスクリプションは同一の分散トピックの異なるメンバー上に存在できるようになり、同時に、このようなサブスクリプションは単一の論理サブスクリプションとして処理できます。詳細は、『Oracle WebLogic Server JMSリソースの管理』の無制限のクライアントIDの構成に関する項を参照してください。

topicMessagesDistributionModeは、メッセージが分散トピックに配信される仕組みを制御するために、JMS属性SubscriptionSharingPolicyおよびClientIdPolicyの順列(接続ファクトリ上で設定)を定義します。Oracle WebLogic Serverは、表C-1で示されるようにこれらの値を設定します。

表C-1 topicMessagesDistributionMode設定とJMS接続ファクトリ上の設定間の関係

topicMessagesDistributionMode

SubscriptionSharingPolicy

ClientIdPolicy

One-Copy-Per-ServerまたはOne-Copy-Per-Application

Sharable

Unrestricted

Compatibility (レプリケートされた分散トピックおよび外部トピックのみ)

Exclusive

Restricted

接続ファクトリ上の設定がこれらの値ではない場合、Oracle WebLogic Serverは値をオーバーライドし、警告メッセージを表示します。Oracle WebLogic Serverがなんらかの理由で値をオーバーライドできない場合、例外がスローされ、管理者がJMS接続ファクトリ上で設定を変更しないかぎり、MDBはメッセージを処理できません。プログラム的にこのような属性を接続ファクトリ上で直接設定できません。そのかわり、topicMessagesDistributionModeを使用すると、MDBデプロイメントは接続インスタンス上で値を設定します。