Oracle® Fusion Middleware

Oracle WebLogic Serverサーバー環境の管理

12c (12.2.1.1.0)

E77282-02(原本部品番号:E72093-02)

2016年7月

このドキュメントでは、WebLogic Server環境を設計、構成、管理する方法について説明します。インストールされたWebLogic Serverの実装に携わるシステム管理者およびオペレータを対象としています。

Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理, 12c (12.2.1.1.0)

E77282-02

Copyright © 2015, 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 概要とロードマップ

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

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

- 関連ドキュメント

- このリリースでの新機能と変更された機能

2 ワーク・マネージャを使用したスケジューリング済み作業の最適化

- WebLogic Serverでのスレッド・プールの使用方法の理解

- ワーク・マネージャの理解

- リクエスト・クラス

- 制約

- スタック・スレッドの処理

- 自己チューニング・スレッド・プール

- 自己チューニング・スレッド・プール・サイズ

- ThreadLocalの除去

- ワーク・マネージャのスコープ

- デフォルトのワーク・マネージャ

- デフォルトのワーク・マネージャのオーバーライド

- ワーク・マネージャを使用する必要があるとき

- グローバル・ワーク・マネージャ

- アプリケーション・スコープのワーク・マネージャ

- ワーク・マネージャ、リクエスト・クラス、および制約の使い方

- EJBのディスパッチ・ポリシー

- Webアプリケーションのディスパッチ・ポリシー

- デプロイメント記述子の例

- ワーク・マネージャと実行キュー

- 実行キューの有効化

- 実行キューからワーク・マネージャへの移行

- MBeanを使用してのワーク・マネージャへのアクセス

- WebLogic ServerでのCommonJの使い方

- CommonJワーク・マネージャへのアクセス

- WebLogic Serverワーク・マネージャへのCommonJのマッピング

3 過負荷の回避と管理

- 過負荷状態を回避するためのWebLogic Serverの構成

- スレッド・プール内のリクエスト数の制限

- ワーク・マネージャとスレッド・プールの抑制

- HTTPセッションの制限

- メモリー不足例外発生時の終了

- スタック・スレッドの処理

- WebLogic Serverの自動モニター

- 過負荷ヘルス状態

- WebLogic Serverの終了コード

4 ネットワーク・リソースの構成

- ネットワーク構成の概要

- ネットワーク・チャネルの理解

- チャネルとは

- チャネルの構成の注意点

- カスタム・チャネルによるデフォルト・チャネル属性の継承

- ネットワーク・チャネルを使用する理由

- チャネルの障害の処理

- RMIのサービス品質レベルについて

- WebLogic Serverの標準チャネル

- デフォルト・ネットワーク・チャネル

- 管理ポートと管理チャネル

- 管理ポートの機能

- 管理ポートの制限事項

- 管理ポートで必須のSSL

- 管理ポートの構成

- 管理ポートを使用するための管理対象サーバーの起動

- 管理チャネルを使用するための管理対象サーバーの起動

- カスタム管理チャネル

- 内部チャネルの使い方

- チャネルの選択

- クラスタ内の内部チャネル

- チャネルの構成

- チャネルの構成のガイドライン

- チャネルとサーバー・インスタンス

- チャネルの動的な構成

- チャネルとアイデンティティ

- チャネルとプロトコル

- 予約済みの名前

- チャネル、プロキシ・サーバー、およびファイアウォール

- クラスタにおけるネットワーク・チャネルの構成

- クラスタの作成

- ネットワーク・チャネルの作成および割当て

- レプリケーション・チャネルの構成

- 多数チャネルの使用時におけるパケット・サイズの増大

- EJBへのカスタム・チャネルの割当て

- IPv4でのIPv6の使用

5 Webサーバー機能の構成

- Webサーバー・コンポーネントの構成の概要

- サーバーの構成

- リスニング・ポートの構成

- Webアプリケーション

- Webアプリケーションとクラスタリング

- 仮想ホスティングの構成

- 仮想ホスティングとデフォルトWebアプリケーション

- 仮想ホストの設定

- WebLogic ServerによるHTTPリクエストの解決方法

- HTTPアクセス・ログの設定

- ログ・ローテーション

- 共通ログ・フォーマット

- 拡張ログ・フォーマットを使用したHTTPアクセス・ログの設定

- Fieldsディレクティブの作成

- サポートされるフィールド識別子

- IPアドレス関連フィールド

- DNS関連フィールド

- 診断メッセージ相関フィールド

- カスタム・フィールド識別子の作成

- HttpAccountingInfoオブジェクトのgetメソッド

- POSTサービス拒否攻撃の防止

- HTTPトンネリングのためのWebLogic Serverの設定

- HTTPトンネリング接続の設定

- クライアントからのWebLogic Serverへの接続

- ネイティブI/Oを使用した静的ファイルの提供(Windowsのみ)

6 Oracle Virtual Assembly Builder用プラグインの使用

- 概要

- Oracle Virtual Assembly Builderについて

- WebLogic Serverイントロスペクション・プラグインについて

- WebLogic Serverイントロスペクション・プラグインの設定

- イントロスペクション・プラグインのパラメータ

- 参照システムの前提条件

- プラグイン使用の要件

- 作成されるアーティファクト・タイプ

- ワイヤリング

- ワイヤリング・プロパティ

- WebLogic Serverアプライアンスのプロパティ

- アセンブリレベルのシステム・プロパティ

- 管理サーバーおよび管理対象サーバーのアプライアンスに共通するプロパティ

- 管理サーバー・アプライアンスのプロパティ

- Oracle Coherence*Webイントロスペクション拡張

- サポートされるテンプレート・タイプ

7 同時管理対象オブジェクトの構成

- Java EE Concurrency Utilitiesについて

- WebLogic ServerでのConcurrency 1.0のコード・サンプル

- 同時管理対象オブジェクトによるWebLogic Serverコンテナへの同時実行性の装備

- WebLogic Serverによるアプリケーション・コンポーネントの非同期タスクの処理

- 同時管理対象オブジェクト(CMO)

- CMOとCommonJ API

- CMOコンテキストの伝播

- 伝播されるコンテキスト・タイプ

- コンテキスト呼出しポイント

- CMOタスクの自己チューニング

- CMOが停止する場合のスレッドの中断

- 長時間実行スレッドに対するCMOの制約

- 最大同時長時間実行リクエストの制限の設定

- 最大同時新規スレッドの制限の設定

- デフォルトのJava EE CMO

- デフォルト管理対象エグゼキュータ・サービス

- デフォルト管理対象スケジュール済エグゼキュータ・サービス

- デフォルト・コンテキスト・サービス

- デフォルト管理対象スレッド・ファクトリ

- 構成ファイル内のカスタマイズ済CMO

- WebLogic構成ファイルでのCMOの定義

- アプリケーション・コンポーネント環境でのJNDIに対するCMOのバインド

- <resource-env-ref>を使用したJNDIバインディング

- @Resourceを使用したJNDIバインディング

- カスタムCMOモジュールの更新済スキーマ

- CMOの更新済システム・モジュールBean

- カスタム管理対象エグゼキュータ・サービスの構成要素

- デプロイメント記述子の例

- カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素

- ScheduledFuture.get()メソッド

- デプロイメント記述子の例

- カスタム管理対象スレッド・ファクトリの構成要素

- MTFで作成されるスレッドのコンテキスト

- デプロイメント記述子の例

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

- MESおよびMSESのトランザクション管理

- コンテキスト・サービスのトランザクション管理

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

- グローバルCMOテンプレート

- 管理コンソールを使用したCMOテンプレートの構成

- MBeanでのCMOテンプレートの構成

- 同時制約の構成

- 管理コンソールを使用した同時制約の構成

- ドメイン・レベルの同時制約

- サーバー・レベルの同時制約

- 動的クラスタ・レベルの同時制約

- MBeanでの同時制約の構成

- CMOの問合せ

- 管理コンソールでのCMOスレッドのモニタリング

- デプロイされているすべてのアプリケーションおよびモジュールのJSR236 CMOのモニター

- デプロイされているEARまたはモジュールのJSR236 CMOのモニター

- MBeanを使用したCMOの監視

- MBeanを使用した同時制約の監視

8 バッチ・ランタイムの使用

- バッチ・ジョブについて

- WebLogic ServerでのBatch 1.0のコード・サンプル

- Derbyデータベースでのデフォルトのバッチ・ランタイム構成の使用

- 専用データベースを使用するためのバッチ・ランタイムの構成

- 前提条件ステップによるJobRepository表、バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスの構成

- JobRepository表の作成

- RCUを使用したJobRepository表の作成

- SQLスクリプトを使用したJobRepository表の作成

- JobRepositoryのJDBCデータ・ソースの作成

- 管理対象エグゼキュータ・サービス・テンプレートの作成(オプション)

- 専用バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスを使用するためのバッチ・ランタイムの構成

- 管理コンソールを使用したバッチ・ランタイムの構成

- WLSTを使用したバッチ・ランタイムの構成

- バッチ・ランタイムの問合せ

- 管理コンソールを使用したバッチ・ランタイムの問合せ

- すべてのバッチ・ジョブの詳細の取得

- ジョブの実行に関する詳細の取得

- ジョブのステップ実行に関する詳細の取得

- ランタイムMBeanを使用したバッチ・ランタイムの問合せ

- getJobDetailsを使用したすべてのバッチ・ジョブの詳細の取得

- getJobExecutionsを使用したジョブ実行の詳細の取得

- getStepExecutionsを使用したジョブ・ステップ実行の詳細の取得

- トラブルシューティングのヒント

- JobRepository表が含まれるデータベースが実行していることを確認する

はじめに

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

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

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 概要とロードマップ

この項では、『Oracle WebLogic Serverサーバー環境の管理』の内容と構成について説明します。

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

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

- 関連ドキュメント

- このリリースでの新機能と変更された機能

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

このドキュメントでは、WebLogic Server環境を設計、構成、管理する方法について説明します。インストールされたWebLogic Serverの実装に携わるシステム管理者およびオペレータを対象としています。このドキュメントのスコープは、開発からテストおよび本番まで、ソフトウェア・プロジェクトのすべての段階に関連しています。

Java EE技術、Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

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

このドキュメントの構成は次のとおりです。

- この章「概要とロードマップ」では、このガイドの構成および関連ドキュメントについて説明します。

- 「ワーク・マネージャを使用したスケジューリング済作業の最適化」では、WebLogic Serverの実行モデルについて解説し、実行キューへアプリケーションのアクセスを構成する手順について説明します。

- 「過負荷の回避と管理」では、過負荷状態の検知と回避、および過負荷状態からのリカバリについて説明します。

- 「ネットワーク・リソースの構成」では、使用中のネットワークに対するWebLogic Serverドメインの最適化について説明します。

- 「Webサーバー機能の構成」では、WebLogic ServerをWebサーバーとして使用する方法について説明します。

- 「Oracle Virtual Assembly Builder用プラグインの使用」では、Oracle Virtual Assembly Builder用のWebLogic Serverイントロスペクション・プラグインについて説明します。このプラグインを使用して、単一のWebLogicドメインおよびそのドメインが存在するMiddlewareホーム・ディレクトリを調べることができます。

- 「同時管理対象オブジェクトの構成」では、Concurrency Utilities for Java EE 1.0 (JSR 236)の定義および実装をサポートする目的でWebLogic Serverが実装する同時管理対象オブジェクト(CMO)について説明しています。

- 「バッチ・ランタイムの使用」では、Batch Applications for the Java Platform (JSR 352)のJava EE 7に定義されているように、バッチ・ジョブの定義、実装および実行をサポートする目的でWebLogic Serverが実装するバッチ・ランタイムについて説明しています。

関連ドキュメント

- Oracle WebLogic Serverドメインの構成の理解

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

このリリースでの新機能と変更された機能

本リリースのWebLogic Serverでは、次の機能を含むJava EE 7のサポートが追加されています。

- Concurrency Utilities for Java EE 1.0 (JSR 236)。詳細は、「同時管理対象オブジェクトの構成」を参照してください。

- Batch Applications for the Java Platform (JSR 352)。詳細は、「バッチ・ランタイムの使用」を参照してください。

このリリースで導入されたWebLogic Serverの総合的な新機能一覧は、「Oracle WebLogic Serverの新機能」 12.2.1.1.0を参照してください。

2 ワーク・マネージャを使用したスケジューリング済み作業の最適化

この章では、WebLogic Server で、アプリケーションがワーク・マネージャを使用してその作業に優先順位を付ける仕組みを構成する方法について説明します。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク・マネージャを定義し、これをWebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用します。

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

- WebLogic Serverでのスレッド・プールの使用方法の理解

- ワーク・マネージャの理解

- ワーク・マネージャのスコープ

- ワーク・マネージャ、リクエスト・クラス、および制約の使い方

- デプロイメント記述子の例

- ワーク・マネージャと実行キュー

- MBeanを使用してのワーク・マネージャへのアクセス

- WebLogic ServerでのCommonJの使い方

WebLogic Serverでのスレッド・プールの使用方法の理解

以前のバージョンのWebLogic Serverでは、複数の実行キューで処理を実行していました。異なるクラスの作業は、優先度や順序の要件に基づいて、また、デッドロックを回避するために、別々のキューで実行されていました。デフォルトの実行キュー(weblogic.kernel.default)に加え、内部管理トラフィック専用にあらかじめ構成されたキュー(weblogic.admin.HTTP、weblogic.admin.RMIなど)がありました。

ユーザーは、デフォルト・キューのスレッドの数を変更することでスレッドの使用状況を制御したり、特定のアプリケーションが全体のシステム負荷に関係なく一定数のスレッドにアクセスできるようカスタム実行キューを構成したりできました。

このバージョンのWebLogic Serverでは、1つのスレッド・プールですべてのタイプの作業を実行するようになりました。作業の優先順位は、ユーザーが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際にリクエストを実行するのにかかった時間、リクエストをプールに出し入れする割合、などがあります。

共通スレッド・プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニターし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。この新しい戦略により、管理者は、カスタムの実行キューを構成、モニター、チューニングする際の手間や複雑さを避けて、より簡単に処理リソースを割り当てたり、パフォーマンスを管理したりできるようになりました。

ワーク・マネージャの理解

WebLogic Serverでは、管理者が定義したパラメータと実行時の実際のパフォーマンスおよびスループットを考慮にいれた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。

管理者は、一連のスケジューリング・ガイドラインを構成し、それらを1つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション・コンポーネントに関連付けたりできます。たとえば、スケジューリング・ガイドラインのセットを1つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っているリクエストが実行スレッドに割り当てられます。

注意:

すべてのワーク・マネージャからの作業リクエストは、1つのスレッド・プールによって実行されます。それぞれのワーク・マネージャに対して別々のスレッド・プールは作成されません。

アプリケーション内の作業を管理するには、以下のうち1つまたは複数のワーク・マネージャ・コンポーネントを定義します。

- フェア・シェアリクエスト・クラス

- レスポンス時間リクエスト・クラス

- 最小スレッド数制約

- 最大スレッド数制約

- 容量制約

- コンテキストリクエスト・クラス

これらのコンポーネントの詳細は、「リクエスト・クラス」または「制約」を参照してください。

これらのワーク・マネージャ・コンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらのすべてのコンポーネント(コンテキスト・リクエスト・クラス以外。「例2-3」を参照)をカプセル化したワーク・マネージャを定義し、このワーク・マネージャの名前をアプリケーションのデプロイメント記述子で参照することもできます。複数のワーク・マネージャを定義することも可能です。ワーク・マネージャの適正数は、WebLogic Serverでホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。

ワーク・マネージャは、次のいずれかの構成ファイルまたはWebLogic Server管理コンソールを使用して、ドメイン・レベル、アプリケーション・レベル、およびモジュール・レベルで構成できます。

- config.xml - config.xmlで指定したワーク・マネージャは、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。

- weblogic-application.xml - アプリケーション・レベルで指定したワーク・マネージャは、そのアプリケーション、またはそのアプリケーションのコンポーネントに割り当てることができます。

- weblogic-ejb-jar.xmlまたはweblogic.xml - コンポーネント・レベルで指定したワーク・マネージャは、そのコンポーネントに割り当てることができます。

- weblogic.xml - Webアプリケーション用に指定したワーク・マネージャ。

例 2-1に、ワーク・マネージャの定義の例を示します。

- リクエスト・クラス

- 制約

- スタック・スレッドの処理

例 2-1ワーク・マネージャ・スタンザ

<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</min-threads-constraint>
</work-manager>

例2-1のワーク・マネージャを割り当てて、Webアプリケーション全体のディスパッチ・ポリシーを制御するには、例2-2のコードをWebアプリケーションのweblogic.xmlファイルに追加します。

例 2-2 Webアプリケーションでのワーク・マネージャの参照

<wl-dispatch-policy>highpriority-workmanager</wl-dispatch-policy>

ワーク・マネージャを割り当てて、特定のサーブレットのディスパッチ・ポリシーを制御するには、次のコードをWebアプリケーションのweb.xmlファイルに追加します。

<servlet>
...
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>highpriority_workmanager</param-value>
</init-param>
...
</servlet>

ワーク・マネージャで定義および使用できるコンポーネントについては次の項で説明します。

リクエスト・クラス

リクエスト・クラスは、リクエストへのスレッドの割当てに使用するスケジューリング・ガイドラインを表現します。リクエスト・クラスを使用すると、優先度の高い作業が優先度の低い作業より後に送信された場合でも、優先度の高い作業を優先度の低い作業より前にスケジューリングすることができます。WebLogic Serverでは、各モジュールがリクエストを完了するのにかかる時間が考慮されます。

リクエスト・クラスはベスト・エフォートを定義します。リクエスト・クラスは、構成された割合の一貫性が維持されることを保証しません。観測された割合は、十分な要求の期間中に次のようないくつかの要素によって変化する場合があります。

- 特定の時点におけるキュー内にある様々なリクエスト・クラスからのリクエストの混在。たとえば、ワーク・マネージャ・キューで優先度の高いリクエスト・クラスから十分なリクエストがない場合、構成された割合よりも多い数のリクエストが優先度の低いリクエスト・クラス用に処理される可能性があります。

- 割合はスレッドの使用時間によって指定されるため、数が少なく、時間のかかるリクエストと同じスレッド使用時間で、時間のかからないリクエストの方が多く処理される可能性があります。

リクエスト・クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング・ガイドラインを表現します。1つのワーク・マネージャに、リクエスト・クラスを1つだけ指定することもできます。

- fair-share-request-class: リクエストの処理に必要な平均スレッド使用時間を指定します。デフォルトのフェア・シェア値は50です。
たとえば、WebLogic Serverで2つのモジュールを実行しているとします。ModuleAのワーク・マネージャではfair-share-request-classが80に設定されており、ModuleBのワーク・マネージャではfair-share-request-classが20に設定されています。

各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッドの数を超えている状態)が続く間は、スレッド使用時間の80%がModuleAに、20%がModuleBに割り当てられます。

注意:

フェア・シェア・リクエスト・クラスの値は、割合ではなく相対値で指定します。したがって、上の例でリクエスト・クラスを400と100に設定しても相対値としては同じです。

- response-time-request-class - レスポンス時間の目標値をミリ秒単位で指定します。レスポンス時間の目標値は、個々のリクエストには適用されません。かわりに、そのクラスのリクエストの許容可能な待機時間を、レスポンス時間の目標値から観察された平均スレッド使用時間を減算することで算出し、そのクラスのリクエストの平均的な待機が許容可能な待機時間に比例するようにリクエストをスケジューリングします。
たとえば、前の例のようにModuleAとModuleBがあり、レスポンス時間の目標値がそれぞれ2000ミリ秒と5000ミリ秒に設定されており、個々のリクエストの実際のスレッド使用時間がレスポンス時間の目標値よりも短いとします。レスポンスとリクエストの間に「思考時間」による遅延がないとすると、各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッドの数を超えている状態)が続く間は、ModuleAとModuleBに対するリクエストは平均レスポンス時間が2対5の割合になるようにスケジューリングされます。ModuleAとModuleBの実際の平均レスポンス時間はレスポンス時間の目標値より長くなったり短くなったりしますが、設定されている目標値の常分数または倍数になります。たとえば、ModuleAのリクエストの平均レスポンス時間が1,000ミリ秒である場合、ModuleBのリクエストの平均レスポンス時間は2,500ミリ秒になります。

前の項では、同じリクエスト・クラスを使用して別の作業にスケジューリングを関連付けることで、フェア・シェアとレスポンス時間に基づいたリクエスト・クラスについて説明しました。フェア・シェアとレスポンス時間リクエスト・クラスを併用すると、レスポンス時間スケジューリングに著しく偏ったスケジューリングになります。

- context-request-class - コンテキスト情報(現在のユーザー、現在のユーザーのグループなど)に基づいてリクエスト・クラスをリクエストに割り当てます。
たとえば、例2-3のcontext-request-classでは、リクエストのsubjectおよびroleプロパティの値に基づいてリクエスト・クラスがリクエストに割り当てられます。

例2-3のcontext_workmanagerによって参照されるhigh_fairshareリクエスト・クラスとlow_fairshareリクエスト・クラスは、config.xmlで次のように定義できます。

<self-tuning>
...
<fair-share-request-class>
<name>high_fairshare</name>
<target>myserver</target>
<fair-share>75</fair-share>
</fair-share-request-class>
<fair-share-request-class>
<name>low_fairshare</name>
<target>myserver</target>
<fair-share>25</fair-share>
</fair-share-request-class>
...
</self-tuning>

注意:

Webアプリケーションのワーク・マネージャがコンテキスト・リクエスト・クラスを参照している場合、最初のユーザー呼出しはデフォルトのリクエスト・クラスを通じて実行され、同じセッションの以降の呼出しはユーザー定義のリクエスト・クラスを通じて実行されます。

コンテキスト・リクエスト・クラスを使用するとき、セッション・タイムアウト値を設定すると、ワーク・マネージャ・キューでリクエストが待機中にセッションの期限が切れなくなります。

例 2-3コンテキストリクエスト・クラス

<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>

制約

制約を使用すると、リクエストを実行するために割り当てられるスレッドの最小数と最大数、およびWebLogic Serverがリクエストを拒否し始めるまでにキューに入れたり実行したりできるリクエストの総数を定義できます。

以下のタイプの制約を定義できます。

- max-threads-constraint - 制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、統合された3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。
max-threads-constraintは、リクエストが依存するリソース(たとえば接続プール)の可用性の観点から定義できます。

max-threads-constraintは、リクエスト・クラスによるスレッドのフェア・シェアの実現やレスポンス時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行の数が制限値を下回るまで、このタイプのリクエストはスケジューリングされません。制限値を下回ると、フェア・シェアまたはレスポンス時間の目標値に基づいて作業がスケジューリングされます。

- min-threads-constraint - 制約対象のリクエストに割り当てられるスレッドの数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraintの値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に便利です。
min-threads-constraintによってフェア・シェアが向上するとは限りません。このタイプの制約は、主にサーバー・インスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス・クラス内のリクエストがフェア・シェアを超えていた場合でも、この制約によってリクエストがスケジューリングされます。

- capacity - サーバーは容量に達したときにのみリクエストを拒否します。デフォルトは-1です。容量には、制約対象の作業セットからの全リクエスト(キューにあるリクエストと実行中のリクエスト)が含まれます。個々の容量しきい値を超えた場合、またはグローバル容量を超えた場合に作業が拒否されます。この制約は、グローバル・キューのしきい値とは無関係です。
リクエストがWebLogic Server管理者グループに属するユーザーによって行われる場合、capacity制約は適用されません。

スタック・スレッドの処理

スタック・スレッドに応じて、スタック・スレッド・ワーク・マネージャ・コンポーネントを定義できます。このコンポーネントを使用すると、ワーク・マネージャを停止したり、アプリケーションを管理モードにしたり、サーバー・インスタンスを障害が発生したものとしてマークしたりできます。

たとえば、例 2-4で定義するワーク・マネージャは、2つのスレッドが30秒を超えてスタックすると停止します。

例 2-4スタック・スレッド・ワーク・マネージャ

<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>

自己チューニング・スレッド・プール

WebLogic Serverは、自己チューニング・スレッド・プール用に3つのスレッド・グループを管理します。

- 実行スレッド: ワーク・マネージャに送信された作業リクエストを現在実行しているスレッド

- アイドル・スレッド: 作業リクエストをアイドル状態で待機しているスレッド
アイドル・スレッドには、前の作業リクエストを完了し、新しいリクエストを待っているスレッドおよび将来の作業負荷を予想するために使用量統計情報に基づいて自己チューニング・スレッド・プールによって作成されるスレッドが含まれます。

- スタンバイ・スレッド: 現在作業リクエストを処理していないまたは作業リクエスト待ちではないスレッド
スタンバイ・スレッドは、自己チューニング・スレッド・プールのスレッド数にカウントされません。自己チューニング・スレッド・プールが使用量統計情報に基づいてスレッド数を減らすことを決定すると、スレッドはアイドル・スレッドのグループからスタンバイ・スレッドのグループに移動します。逆に、自己チューニング・スレッド・プールがスレッド数を増やすことを決定すると、まずスタンバイ・スレッド・グループでスレッドを探し、アイドル・スレッド・グループに移動しようとします。自己チューニング・スレッド・プールは、スタンバイ・グループに十分なスレッドがない場合のみ新しいスレッドを作成します。

スタンバイ・スレッド数が内部の最大制限値の256に達するとスレッドはシャットダウンします。作業負荷が大きいときにWebLogic Serverインスタンスが新しいスレッドの作成を回避できるように、WebLogic Serverが自己チューニング・スレッド・プール数を増やす必要がある場合に多数のスタンバイ・スレッドが準備されていることが理想です。スタンバイ・スレッドは、最小スレッド制約を満たすためにも作成して使用できます。詳細は、「制約」を参照してください。

自己チューニング・スレッド・プール・サイズ

デフォルトでは、自己チューニング・スレッド・プール・サイズの制限は400です。この制限には、すべての実行スレッドおよびアイドル・スレッドが含まれますが、スタンバイ・スレッドは含まれません。KernelMBeanのSelfTuningThreadPoolSizeMax属性を使用してこの制限値を構成できます。自己チューニング・スレッド・プールがスレッド数の上限値に達したときでも、システムが追加の作業負荷をサポートできる場合、サイズの制限値を上げることができます。逆に、CPUなどのシステム・リソースが少ないスレッド数で過負荷になる場合、制限値を下げることができます。ただし、SelfTuningThreadPoolSizeMaxの制限値を下げる場合、設定値が低すぎるとシステムの作業負荷を処理するために十分なスレッドを自己チューニング・スレッド・プールが作成できなくなる場合があることに注意してください。この結果、一部のワーク・マネージャで保留中の作業リクエストのバックログが発生する可能性があります。

注意:

最小スレッド制約は、特にWebLogic Serverインスタンスの負荷が大きい場合にワーク・マネージャの作業リクエストを実行しているスレッド数に影響する可能性があります。

自己チューニング・スレッド・プールは、割り当てられた最小スレッド制約を満たすために新しいスタンバイ・スレッドを作成してワーク・マネージャの受信作業リクエストを処理する際にSelfTuningThreadPoolSizeMax属性を考慮しません。これは、サーバー間のデッドロックを回避するために使用するように設計されている最小スレッド制約を使用してワーク・マネージャの作業リクエストを処理するためにスレッドを割り当てることが重要であるためです。

この結果、構成した数のスレッドが構成したすべての最小スレッド制約に割り当てられる最悪シナリオを考慮すると、自己チューニング・スレッド・プールによって維持されるスレッドの最大可能数は、構成したSelfTuningThreadPoolSizeMax属性値の合計とWebLogic Serverインスタンスで構成されたすべての最小スレッド制約値の合計です。

ThreadLocalの除去

アプリケーションやサード・パーティ・ライブラリによる不要なThreadLocalの使用をなくすには、KernelMBeanのeagerThreadLocalCleanup属性を構成します。eagerThreadLocalCleanup属性では、各作業リクエストの処理を完了した後に、自己チューニング・スレッド・プールからすべてのThreadLocalストレージを除去するかどうかを指定します。

デフォルトでは、eagerThreadLocalCleanup属性はfalseに設定されます。この場合、自己チューニング・スレッド・プールでは、スレッドがスタンバイ・プールに戻り、アプリケーションをアンデプロイした後、ThreadLocalストレージのみを除去します。

eagerThreadLocalCleanup属性をtrueに設定すると、新しいリクエストの作業を実行する際、スレッド・プールのすべてのスレッドに以前のリクエストのThreadLocal値は残りません。ただし、各作業リクエストの後にThreadLocalストレージを除去して、新しいリクエストごとにThreadLocal値を復元すると、オーバーヘッドが発生します。一部のアプリケーションでは、作成に費用がかかるオブジェクトのキャッシュをThreadLocalストレージに格納するため、各リクエスト後にThreadLocal値を除去する場合、それらのアプリケーションのパフォーマンスに悪影響を与える可能性があります。

ワーク・マネージャのスコープ

基本的に、ワーク・マネージャには3つのタイプがあります。各タイプは、スコープおよび定義と使用のされ方によって特徴付けられます。

- デフォルトのワーク・マネージャ

- グローバル・ワーク・マネージャ

- アプリケーション・スコープのワーク・マネージャ

デフォルトのワーク・マネージャ

スレッド管理を処理し、自動チューニングを実行するため、WebLogic Serverではデフォルトのワーク・マネージャが実装されています。このワーク・マネージャは、アプリケーションのデプロイメント記述子で他のワーク・マネージャが指定されていない場合に、アプリケーションによって使用されます。

多くの場合、デフォルトのワーク・マネージャはほとんどのアプリケーション要件を十分に満たしていると考えられます。WebLogic Serverのスレッド処理アルゴリズムは、デフォルトで各アプリケーションに、フェア・シェアを割り当てます。各アプリケーションは、スレッドに対して同等の優先度を与えられており、スレッドを独占できないようになっています。

デフォルトのワーク・マネージャのオーバーライド

デフォルトのワーク・マネージャの動作をオーバーライドするには、defaultというグローバル・ワーク・マネージャを作成および構成します。これにより、WebLogic Serverのデフォルトのスレッド処理動作を制御できます。

注意:

デフォルトのワーク・マネージャをオーバーライドすると、すべてのインスタンスがオーバーライドされます。

ワーク・マネージャを使用する必要があるとき

以下は、ワーク・マネージャを使用してスレッド管理のカスタマイズをする必要がある場合を判断するためのガイドラインです。

- デフォルトのフェア・シェア(50)が不十分です。
これは通常、あるアプリケーションに、他のアプリケーションよりも高い優先度を与える必要があるという状況において起こります。

- レスポンス時間の目標値が必要です。

- サーバーのデッドロックを防止するため、最小スレッド数制約を指定することが必要です。

グローバル・ワーク・マネージャ

サーバーにデプロイされているすべてのアプリケーションおよびモジュールで使用できるグローバル・ワーク・マネージャを、WebLogic Server管理コンソールまたはconfig.xmlで作成できます。

アプリケーションは、グローバルに定義されたワーク・マネージャをテンプレートとして使用します。各アプリケーションは、そのアプリケーションと関連付けられた作業を処理する、自身のインスタンスを作成し、その作業を他のアプリケーションから分離します。そうすることで、同じディスパッチ・ポリシーを使用している2つのアプリケーションに向かうトラフィックを処理できます。各アプリケーションの作業を別個に処理することで、別のアプリケーションのスレッド管理に影響を及ぼすことなく、アプリケーションを停止できます。各アプリケーションには、専用のワーク・マネージャ・インスタンスが実装されていますが、基底となるコンポーネントは共有されます。

アプリケーション・スコープのワーク・マネージャ

グローバル・スコープのワーク・マネージャに加えて、特定のアプリケーションまたはモジュールのみで使用できるワーク・マネージャも作成できます。アプリケーション・スコープのワーク・マネージャは、WebLogic Server管理コンソールと次の記述子で定義できます。

- weblogic-application.xml

- weblogic-ejb-jar.xml

- weblogic.xml

ワーク・マネージャが明示的に割り当てられていないアプリケーションでは、デフォルトのワーク・マネージャが使用されます。

ワーク・マネージャにメソッドを割り当てるには、デプロイメント記述子で<dispatch-policy>要素を使用します。後方互換性を維持するため、<dispatch-policy>でカスタム実行キューも指定できるようになっています。例については、例 2-2を参照してください。

ワーク・マネージャ、リクエスト・クラス、および制約の使い方

ワーク・マネージャ、リクエスト・クラス、および制約では、以下が必要になります。

- 定義。ワーク・マネージャ、リクエスト・クラスおよび制約は、WebLogic Server管理コンソールを使用してドメインの構成内にグローバルに定義するか(WebLogic Server管理コンソールの「環境」>「ワーク・マネージャ」)、上に挙げたデプロイメント記述子のいずれかを使用して定義します。どちらの場合も、それぞれに名前を割り当てます。

- マッピング。デプロイメント記述子で、ワーク・マネージャ、リクエストクラス、または制約のいずれかを、その名前を使用して参照します。

EJBのディスパッチ・ポリシー

weblogic-ejb-jar.xml - weblogic-enterprise-beanの既存のdispatch-policyタグの値は、名前付きのdispatch-policyになります。後方互換性のため、ExecuteQueueを指定することもできます。また、現在のisolation-levelタグと同様に、dispatch-policy、max-threadsおよびmin-threadsでは、メソッドのリストに名前付きの(または制約が数値で名前がない)ポリシーおよび制約を指定することもできます。

Webアプリケーションのディスパッチ・ポリシー

weblogic.xml - web.xmlのfilter-mappingと同様のマッピングもサポートします。名前付きのdispatch-policy、max-threadsまたはmin-threadsが、URLパターンまたはサーブレット名にマップされます。

デプロイメント記述子の例

この項では、様々なデプロイメント記述子を使用したワーク・マネージャの定義例を示します。

必要に応じて、各デプロイメント記述子のスキーマも参照してください。

- weblogic-ejb-jar.xml schema: http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.6/weblogic-ejb-jar.xsd

- weblogic-application.xml schema: http://xmlns.oracle.com/weblogic/weblogic-application/1.7/weblogic-application.xsd

- weblogic.xmlのスキーマ - 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

例2-5 ワーク・マネージャのエントリを含むweblogic-ejb-jar.xml

<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar
http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.6/weblogic-ejb-jar.xsd">

<weblogic-enterprise-bean>
<ejb-name>WorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name>
<dispatch-policy>weblogic.kernel.System</dispatch-policy>
</weblogic-enterprise-bean>

<weblogic-enterprise-bean>
<ejb-name>NonSystemWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name>
<dispatch-policy>workbean_workmanager</dispatch-policy>
</weblogic-enterprise-bean>

<weblogic-enterprise-bean>
<ejb-name>MinThreadsWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name>
<dispatch-policy>MinThreadsCountFive</dispatch-policy>
</weblogic-enterprise-bean>

<work-manager>
<name>workbean_workmanager</name>
</work-manager>

<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>

<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</min-threads-constraint>
</work-manager>

<work-manager>
<name>lowpriority_workmanager</name>
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
</work-manager>

<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
</work-manager>

<work-manager>
<name>veryhighpriority_workmanager</name>
<fair-share-request-class>
<name>veryhigh_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
</work-manager>

例2-6のEJBは、依存するリソース(接続プールおよびアプリケーション・スコープの接続プール)のインスタンスと同数のスレッドを取得するように構成されています。

例2-6 接続プール・ベースの最大スレッド数制約を含むweblogic-ejb-jar.xml

<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar
http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.6/weblogic-ejb-jar.xsd">

<weblogic-enterprise-bean>
<ejb-name>ResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name>
<dispatch-policy>test_resource</dispatch-policy>
</weblogic-enterprise-bean>

<weblogic-enterprise-bean>
<ejb-name>AppScopedResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB
</jndi-name>
<dispatch-policy>test_appscoped_resource</dispatch-policy>
</weblogic-enterprise-bean>

<work-manager>
<name>test_resource</name>
<max-threads-constraint>
<name>pool_constraint</name>
<pool-name>testPool</pool-name>
</max-threads-constraint>
</work-manager>

<work-manager>
<name>test_appscoped_resource</name>
<max-threads-constraint>
<name>appscoped_pool_constraint</name>
<pool-name>AppScopedDataSource</pool-name>
</max-threads-constraint>
</work-manager>
</weblogic-ejb-jar>

例2-7 CommonJワーク・マネージャを含むweblogic-ejb-jar.xml

CommonJの使い方については、「WebLogic ServerでのCommonJの使い方」およびCommonJのJavadocを参照してください。

例2-8 weblogic-application.xml

<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application
http://xmlns.oracle.com/weblogic/weblogic-application/1.7/weblogic-application.xsd">

<max-threads-constraint>
<name>j2ee_maxthreads</name>
<count>1</count>
</max-threads-constraint>

<min-threads-constraint>
<name>j2ee_minthreads</name>
count>1</count>
</min-threads-constraint>

<work-manager>
<name>J2EEScopedWorkManager</name>
</work-manager>
</weblogic-application>

例2-9のWebアプリケーションは、例2-8で定義したエンタープライズ・アプリケーションの一部としてデプロイされます。このWebアプリケーションの記述子では、2つのワーク・マネージャを定義しています。どちらのワーク・マネージャも、アプリケーションのweblogic-application.xmlファイルで定義した同じ最大スレッド数制約(j2ee_maxthreads)を参照しています。レスポンス時間のリクエスト・クラスは、ワーク・マネージャごとに異なっています。

例2-9 Webアプリケーション記述子

<weblogic xmlns="http://xmlns.oracle.com/weblogic"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic
http://xmlns.oracle.com/weblogic/1.0/weblogic.xsd">

<work-manager>
<name>fast_response_time</name>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name>
</work-manager>

<work-manager>
<name>slow_response_time</name>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>5000</goal-ms>
</response-time-request-class>
</work-manager>

</weblogic>

例2-10の記述子は、context-request-classを使用してワーク・マネージャを定義します。

例2-10 Webアプリケーション記述子

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.8/weblogic-web-app.xsd">
<work-manager>
<name>foo-servlet-1</name>
<request-class-name>test-fairshare2</request-class-name>
<max-threads-constraint>
<name>foo-mtc</name>
<pool-name>oraclePool</pool-name>
</max-threads-constraint>
</work-manager>

<work-manager>
<name>foo-servlet</name>
<context-request-class>
<name>test-context</name>
<context-case>
<user-name>anonymous</user-name>
<request-class-name>test-fairshare1</request-class-name>
</context-case>

<context-case>
<group-name>everyone</group-name>
</context-request-class>
</work-manager>
</weblogic-web-app>

ワーク・マネージャと実行キュー

この項では、実行キューとの後方互換性を有効にし、実行キューのかわりにワーク・マネージャを使用するようアプリケーションを移行する方法について、説明します。

実行キューの有効化

WebLogic Serverバージョン8.1では、スレッド管理の処理のために実行キューを実装していました。実行キューを使用すると、スレッド・プールを作成して、作業負荷の処理方法を決定できました。WebLogic Serverは、引続き後方互換性のために実行キューを提供しています。これは主に、アプリケーションの移行を支援するためです。ただし、新しいアプリケーションを開発する際には、ワーク・マネージャを利用して、より効率的にスレッド管理を行うことが必要です。

実行キューの有効化は、次のようにして行うことができます。

- コマンド行オプション-Dweblogic.Use81StyleExecuteQueues=trueを使用する

- config.xmlのカーネルMBeanを介してUse81StyleExecuteQueuesプロパティを設定

実行キューを有効にすると、すべてのワーク・マネージャの構成とスレッドの自動チューニングが無効になります。実行キューは、WebLogic Server 8.1で動作したときと同じように動作します。

有効化されたワーク・マネージャは、以下のルールに基づき、実行キューに変換されます。

- ワーク・マネージャで最小スレッド数制約または最大スレッド数制約が実装されている場合、実行キューはワーク・マネージャと同じ名前で作成されます。実行キューのスレッド数は、制約で定義された値に基づいています。

- ワーク・マネージャで制約が実装されていない場合、グローバル・デフォルト実行キューが使用されます。

実行キューからワーク・マネージャへの移行

アプリケーションがWebLogic Server 8.1から移行される場合、移行より前にサーバー構成で定義された実行キューはすべて、そのまま存続します。実行キューのワーク・マネージャへの変換は自動的に行われるわけではありません。

WebLogic Server 9.xに、実行キューを実装した8.1アプリケーションがデプロイされると、リクエストに応じてスレッド管理の処理するため、実行キューが作成されます。しかし、この機能が活用されるのは、ディスパッチ・ポリシーが実行キューにマップされるリクエストにおいてのみです。

MBeanを使用してのワーク・マネージャへのアクセス

ワーク・マネージャには、WorkManagerMBean構成MBeanを使用してアクセスすることができます。詳細は、「WorkManagerMBean」を参照してください。

WorkManagerMBeanへは、アプリケーションのワーク・マネージャへのアクセス方法に応じて、実行時ツリーまたは構成ツリーでアクセスします。

- ワーク・マネージャがモジュール・レベルで定義されている場合、対応するComponentRuntimeMBeanを介して、WorkManagerRuntime MBeanが使用できます。

- ワーク・マネージャがアプリケーション・レベルで定義されている場合、ApplicationRuntimeを介して、WorkManagerRuntimeが使用できます。

- ワーク・マネージャがconfig.xml内でグローバルに定義されている場合、各アプリケーションは、専用のワーク・マネージャ・インスタンスを作成します。各アプリケーションには、アプリケーション・レベルで使用できる、専用の対応するWorkManagerRuntimeがあります。

WebLogic ServerでのCommonJの使い方

WebLogic Serverワーク・マネージャでは、管理者がサーブレットおよびEJBに対してディスパッチ・ポリシーを設定できるよう、サーバー・レベルの構成を提供しています。

WebLogic Serverはまた、アプリケーション内からプログラム的に作業を処理するための方法も用意しています。これは、CommonJ APIを通じて提供されます。Weblogic Serverは、CommonJ仕様のcommonj.workパッケージおよびcommonj.timersパッケージを実装しています。

WebLogic ServerにおけるCommonJの実装に関する個別の情報は、「CommonJのJavadoc」を参照してください。

CommonJのWebLogic Server実装を使用すると、アプリケーションは、WebLogic Serverで構成済みの複数のワーク・マネージャを使用して、1つのリクエストのタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます。作業項目を同時に実行する必要のないアプリケーションでも、構成済みのワーク・マネージャを使用することができます。それには、デプロイメント記述子でワーク・マネージャを参照または作成するか、Java EEコネクタの場合はJCA APIを使用します。

WebLogic Server実装とCommonJ仕様の相違点をいくつか、以下に示します。

- RemoteWorkItemインタフェースは、CommonJ仕様によって提供された任意指定のインタフェースであり、WebLogic Serverではサポートされていません。WebLogic Serverでは、独自のクラスタ・ロード・バランシングおよびフェイルオーバー・ポリシーを実装しています。作業負荷管理は、これらのポリシーに基づいて行われます。

- WebLogic CommonJタイマーの動作は、java.util.Timerとは異なります。WebLogic CommonJタイマーは、実行が所定期間の2倍を超えると、それ以上の遅延を防止するため、いくらかの期間をスキップします。java.util.Timerは、このような処理を行いません。

- WebLogic Server環境では、スレッドがスタック状態になった時にWorkListener.WorkRejectedメソッドが呼び出されます。

CommonJワーク・マネージャへのアクセス

WebLogic Serverワーク・マネージャにアプリケーションからアクセスするにはディスパッチ・ポリシーを使用する必要がありますが、CommonJワーク・マネージャはアプリケーションから直接アクセスできます。次のサンプル・コードに、JNDIを使用してCommonJワーク・マネージャをルックアップする方法を示します。

InitialContext ic = new InitialContext();
commonj.work.WorkManager wm =
(commonj.work.WorkManager)ic.lookup("java:comp/env/wm/myWM");

CommonJワーク・マネージャの使い方の詳細は、CommonJのJavadocを参照してください。

WebLogic Serverワーク・マネージャへのCommonJのマッピング

外部定義したCommonJワーク・マネージャは、WebLogic Serverワーク・マネージャにマッピングできます。たとえば、次の例のように、記述子ejb-jar.xmlで定義したCommonJワーク・マネージャがあるとします。

<resource-ref>
<res-ref-name>minthreads_workmanager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

これをWebLogic Serverワーク・マネージャにリンクさせるには、WebLogic Serverの記述子(たとえばweblogic-ejb-jar.xml)のname要素を完全に一致させます。

<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<count>5</count>
</min-threads-constraint>
</work-manager>

この手順は、web.xmlに定義したresource-refと同様です。WebLogic Serverワーク・マネージャは、モジュール記述子(たとえばweblogic-ejb-jar.xmlやweblogic.xml)またはアプリケーション記述子(weblogic-application.xml)で定義できます。

3 過負荷の回避と管理

この章では、過負荷状態の検知と回避、および過負荷状態からのリカバリに関するWebLogic Server の機能を説明します。WebLogic Serverの過負荷保護機能を使用すると、システムの容量が一杯になった後もリクエストの受け付けを継続することで生じる悪影響を回避できます。こうした悪影響には、アプリケーションのパフォーマンスと安定性の低下があります。

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

- 過負荷状態を回避するためのWebLogic Serverの構成

- WebLogic Serverの自動モニター

- WebLogic Serverの終了コード

過負荷状態を回避するためのWebLogic Serverの構成

システムの容量が一杯になった後もアプリケーション・サーバーがリクエストの受け付けを継続すると、アプリケーションのパフォーマンスと安定性が低下します。次の項では、WebLogic Serverを構成して、システムへの過負荷の悪影響を最小限に抑える方法について説明します。

スレッド・プール内のリクエスト数の制限

WebLogic Serverでは、システム管理に関わるリクエストも、アプリケーション・アクティビティに関わるリクエストも、すべて1つのスレッド・プールで処理されます。管理者は、キューの最大長を定義することで、スレッド・プールを抑制できます。構成した値を超えると、WebLogic Serverによってリクエストが拒否されます。ただし、管理チャネルからのリクエストは拒否されません。

注意:

管理チャネルにアクセスできるのは管理者のみです。スレッド・プールの最大長に達した後も管理者がシステムにアクセスできるようにするため、実行キューの長さを制限しても、管理チャネルからのリクエストには影響しないようになっています。スレッド・プール内の管理リクエストの数を制限するには、管理チャネルのMaxConnectedClients属性を設定します。

キューに入っているリクエストの数が最大数に達すると、以下のリクエストが即座に拒否され始めます。

- Webアプリケーション・リクエスト

- フェア・シェアが低い(最小のフェア・シェアで始まる)トランザクション非対応のRMIリクエスト。
過負荷状態が継続する場合は、より優先度の高いリクエストが拒否されるようになります。ただし、JMSリクエストとトランザクション関連のリクエストは、JMSおよびトランザクション・マネージャによって過負荷管理されるため、ここでは対象外となります。

スレッド・プールを制限するには、WebLogic Server管理コンソールの「ワーク・マネージャの共有容量」フィールド(「環境」>「サーバー」>「server_name」>「構成」>「オーバーロード」を参照してください)を設定します。このフィールドのデフォルト値は65536です。

ワーク・マネージャとスレッド・プールの抑制

ワーク・マネージャを構成することで、スレッド・プールをより細かいレベル(パフォーマンス、可用性、信頼性の要件が似ているリクエストのセット)で管理できます。ワーク・マネージャでは、特定のリクエスト・クラスのリクエストを、最高でいくつまでキューに入れることができるかを指定できます。ワーク・マネージャで定義した最大リクエスト数は、グローバル・スレッド・プールの値と併用されます。先に制限値に達したほうが優先されます。

「ワーク・マネージャを使用したスケジューリング済作業の最適化」を参照してください。

HTTPセッションの制限

管理者は、低メモリー状態の検知に基づいて、アクティブなHTTPセッションの数を制限できます。これは、メモリー不足状態を回避するうえで便利な機能です。

構成したしきい値に達すると、新しいHTTPセッションを作成するリクエストが拒否されます。WebLogic Serverクラスタでは、拒否されたリクエストがプロキシ・プラグインによってクラスタ内の別の管理対象サーバーにリダイレクトされます。クラスタリングされていないサーバー・インスタンスの場合は、リクエストを代替サーバー・インスタンスにリダイレクトできます。

サーブレット・コンテナは、セッション数が最大数に達すると以下のいずれかのアクションを実行します。

- サーバー・インスタンスがクラスタ内にある場合は、サーブレット・コンテナによってSessionCreationExceptionがスローされます。アプリケーション・コードでは、この実行時例外を処理して適切なレスポンスを送信する必要があります。
過負荷保護を実装するためには、この例外を処理して503レスポンスを明示的に送信する必要があります。このレスポンスは、プロキシまたはロード・バランサで処理できます。

同時HTTPセッション数の制限は、Webアプリケーションのデプロイメント記述子で設定します。たとえば、次の要素ではセッション数の制限が12に設定されています。

<session-descriptor>
<max-in-memory-sessions>12</max-in-memory-sessions>
</session-descriptor>

メモリー不足例外発生時の終了

管理者は、メモリー不足例外が発生したらWebLogic Serverが終了するように構成できます。この機能によりメモリー不足状態の影響を最小限に抑えることができ、自動停止はアプリケーションの不安定性の回避に役立ちます。ノード・マネージャなどの高可用性(HA)ツールを使用してWebLogic Serverが自動的に再起動するように構成し、ダウンタイムを最短にできます。

これを構成するには、WebLogic Server管理コンソールを使用するか、config.xmlで次のように要素を編集します。

<overload-protection>
<panic-action>system-exit</panic-action>
</overload-protection>

詳細は、OverloadProtectionMBeanの属性を参照してください。

スタック・スレッドの処理

WebLogic Serverでは、スタック・スレッドが定期的にチェックされます。すべてのアプリケーション・スレッドがスタックすると、サーバー・インスタンスが障害が発生したものとしてマークされ、終了するように構成されていれば終了します。障害から自動的にリカバリするようにするには、ノード・マネージャやサード・パーティの高可用性ソリューションでサーバーが再起動するように構成します。

すべてのスレッドがスタックしていなくても、スタック・スレッドの数が構成したしきい値を超えたら、これらのアクションが発生するように構成できます。

- スタック・スレッドのあるワーク・マネージャを停止します。停止したワーク・マネージャは、新しい作業を拒否するとともに、拒否メッセージを送信してキュー内の既存の作業を拒否します。クラスタでは、クラスタリングされたクライアントが別のクラスタ・メンバーにフェイルオーバーします。

- アプリケーション内にスタック・スレッドがある場合は、そのアプリケーションが停止します。アプリケーションは、管理モードに移行することで停止します。アプリケーションに属するすべてのワーク・マネージャが停止し、前項で説明した動作が行われます。スタック・スレッド条件が解消されると、アプリケーションは自動的に実行モードに復帰します。

- サーバー内にスタック・スレッドがある場合は、サーバー・インスタンスが障害が発生したものとしてマークし、停止します。クラスタでは、クラスタリングされたクライアントのうち、接続されているか接続を試行しているクライアントが別のクラスタ・メンバーにフェイルオーバーします。

詳細は、OverloadProtectionMBeanの属性を参照してください。

WebLogic Serverの自動モニター

次の項では、過負荷状態を検知して報告するためのWebLogic Server機能について説明します。

過負荷ヘルス状態

WebLogic Serverでは、ヘルス状態としてOVERLOADEDがあり、このヘルス状態は、ライフ・サイクルの状態がRUNNINGになっているサーバー・インスタンスが過負荷状態になると、ServerRuntimeMBean.getHealthState()によって返されます。この状態が発生するのは、低メモリー状態になったときです。

OVERLOADED状態になると、サーバー・インスタンスがワーク・マネージャのキューからのリクエストの拒否を開始し(ワーク・マネージャが構成されている場合)、HTTPリクエストが503エラー(サービス利用不可)を返します。また、クラスタリングされている場合はRMIリクエストが別のサーバーにフェイルオーバーされ、クラスタリングされていない場合はクライアントにリモート例外が返されます。

過負荷状態が解消すると、サーバー・インスタンスのヘルス状態はOKに戻ります。オーバーロードになったサーバー・インスタンスは、管理者が一時停止または停止できます。

WebLogic Serverの終了コード

WebLogic Serverが終了すると、終了コードが返されます。シェル・スクリプトまたはHAエージェントは、終了コードを使用して、サーバーを再起動するかどうかを判断します。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic Serverの終了コードと障害後の再起動に関する項を参照してください。

4 ネットワーク・リソースの構成

この章では、ネットワーク・チャネルやドメイン全体の管理ポートなどの、WebLogic Serverネットワーク・リソースを構成する方法について説明します。こうした構成可能なネットワーク・リソースを使用すると、アプリケーションをホストするマシンのネットワーク機能を効果的に利用してサービス品質を管理できます。

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

- ネットワーク構成の概要

- ネットワーク・チャネルの理解

- チャネルの構成

- EJBへのカスタム・チャネルの割当て

- IPv4でのIPv6の使用

ネットワーク構成の概要

多くの開発環境では、管理対象サーバーのリスニング・アドレスとリスニング・ポートを指定するだけで、WebLogic Serverネットワーク・リソースを簡単に構成できます。ただし、ほとんどの本番環境では、管理者がネットワークに対する要求と照らし合わせて限られたネットワーク・リソースのバランスをとる必要があります。アプリケーションの可用性を維持するタスクは、アプリケーションの特定の要件、セキュリティの考慮事項、およびメンテナンス・タスク(予定どおりのものと予定外のものの両方)によって複雑化します。

WebLogic Serverでは、アプリケーションに関連するネットワーク・トラフィックを様々な方法で制御したり、アプリケーションやエンド・ユーザーの多様な要件を満たすように環境を構成したりできます。次のことができます。

- 異なるタイプのネットワーク・トラフィックごとに、管理対象サーバーで使用するネットワーク・インタフェース・カード(NIC)とポートを指定する

- 複数のプロトコルとセキュリティ要件をサポートする

- 接続とメッセージのタイムアウトを指定する

- メッセージのサイズ制限を課する

これらおよび他の接続特性を指定するには、ネットワーク接続を管理するための主要な構成可能なWebLogic Serverリソースであるネットワーク・チャネルを定義します。ネットワーク・チャネルは、WebLogic Server管理コンソール(「サーバー」>「プロトコル」>「チャネル」)を使用するか、NetworkAccessPointMBeanを使用して構成します。

ネットワーク・チャネルの理解

以降の項では、ネットワーク・チャネル、WebLogic Serverで事前に構成されている標準チャネル、およびチャネル用の一般的なアプリケーションについて説明します。

チャネルとは

ネットワーク・チャネルは、WebLogic Serverに対するネットワーク接続の属性を定義する構成可能なリソースです。たとえば、ネットワーク・チャネルでは以下の項目を定義できます。

- 接続がサポートするプロトコル

- リスニング・アドレス

- セキュア通信および非セキュア通信のリスニング・ポート

- ログイン・タイムアウト値や最大メッセージ・サイズなどの接続プロパティ

- 接続でトンネリングをサポートするかどうか

- 接続は、ドメイン内の他のWebLogic Serverインスタンスとの通信に使用できるか、クライアントとの通信にのみ使用するか

チャネル構成のルール

チャネルを構成するときには、次のガイドラインに従ってください。

- 特定のチャネルは1つのサーバー・インスタンスのみに割り当てることができる

- サーバー・インスタンスには複数のチャネルを割り当てることができます。

- 特定のサーバー・インスタンスに割り当てられた各チャネルは、リスニング・アドレス、リスニング・ポート、およびプロトコルの組み合わせが一意でなければならない

- カスタム・アイデンティティ・キーストアおよびその他のチャネル固有のSSL属性を構成できます。これらは、管理対象サーバー・インスタンスまたはドメインのデフォルトのキーストアおよびSSL構成の設定とは分離されていて、これらをオーバーライドします。

- 非SSLチャネルとSSLチャネルを同じサーバー・インスタンスに割り当てる場合は、同じポート番号が使用されないようにする

カスタム・チャネルによるデフォルト・チャネル属性の継承

チャネルをサーバー・インスタンスに割り当てない場合は、WebLogic Serverにより、ServerMBeanまたはSSLMBeanの属性に基づいて自動的に構成されるWebLogic Serverのデフォルト・チャネルが使用されます。オペレーティング・システムにより、ネットワーク・インタフェースが決定されます。デフォルト・チャネルの詳細は、「デフォルト・ネットワーク・チャネル」を参照してください。

ServerMBeanとSSLMBeanは、サーバー・インスタンスとそのSSL構成を表します。「サーバー」>「構成」>「一般」ページを使用してサーバー・インスタンスのリスニング・アドレス、リスニング・ポート、およびSSLリスニング・ポートを構成すると、それらの値はサーバー・インスタンスのServerMBeanおよびSSLMBeanに格納されます。

カスタム・チャネル定義で特定の接続属性を指定しない場合、チャネルはServerMBeanの属性で指定されている値を継承します。たとえば、チャネルを作成し、そのリスニング・アドレスを定義しない場合、チャネルはServerMBeanで定義されるリスニング・アドレスを使用します。同様に、管理対象サーバーがチャネルで構成されたリスニング・アドレスまたはリスニング・ポートにバインドできない場合、その管理対象サーバーはServerMBeanまたはSSLMBeanのデフォルト値を使用します。

ネットワーク・チャネルを使用する理由

ネットワーク・チャネルを使用すると、サービス品質の管理、様々な接続要件への適合、システム・リソースやネットワーク・リソースの利用の効率化を行えます。たとえば、ネットワーク・チャネルを使用すると次のことができます。

- 様々なタイプのネットワーク・トラフィックの分離 - チャネルが送信接続をサポートするかどうかを構成できます。2つのチャネル(送信接続をサポートするチャネルとサポートしないチャネル)をサーバー・インスタンスに割り当てると、クライアント接続とサーバー接続で独立してネットワーク・トラフィックを構成し、クライアント・ネットワーク・トラフィックとサーバー・ネットワーク・トラフィックを別々のリスニング・アドレスまたはリスニング・ポートに物理的に分けることができます。
送信専用のネットワーク・チャネルは作成できません。チャネルに関連付けられた、対応する受信用インタフェース、ポート、およびプロトコルが常に必要です。ただし、トラフィックをチャネルに直接送信することを避けたり、ファイアウォールを使用してブロックしたりすることは可能です。なお、カスタム・チャネルはプロトコル専用のため、プロトコル(HTTP、HTTPS、t3、t3sなど)ごとに定義されたネットワーク・チャネルが必要になります。「NetworkAccessPointMBean.OutboundEnabled」も参照してください。

ドメイン全体の管理ポートまたは管理チャネルを構成すると、インスタンスの管理トラフィックとアプリケーション・トラフィックを分離することもできます。詳細は、「管理ポートと管理チャネル」を参照してください。

- 同じ管理対象サーバーで多様なアプリケーションまたはユーザー要件をサポート - 管理対象サーバーで複数のチャネルを構成して、複数の異なるプロトコルをサポートしたり、セキュアなトラフィックと非セキュアなトラフィックのプロパティを調整できます。
ネットワーク・チャネルを構成してカスタム・アイデンティティ・キーストアを使用することによって、管理対象サーバーまたはドメイン用に構成されたアイデンティティとは異なる該当のチャネルのアイデンティティをアサートできます。

- 内部アプリケーションのネットワーク・トラフィックの分離 - 特定のチャネルをEJBに割り当てることができます。

マルチホーム・マシン上のサーバー・インスタンスでネットワーク・チャネルを使用する場合は、ServerMBeanまたはチャネルで、有効なリスニング・アドレスを入力する必要があります。チャネルおよびServerMBeanのリスニング・アドレスが空白な場合、またはlocalhostアドレス(IPアドレス0.0.0.0または127.*.*.*)を指定する場合は、サーバーはネットワーク・チャネルのリスニング・ポートとSSLリスニング・ポートを、マルチホーム・マシンで使用可能なすべてのIPアドレスにバインドします。ServerMBeanのリスニング・アドレスの設定は、「デフォルト・ネットワーク・チャネル」を参照してください。

チャネルの障害の処理

リモート・サーバーとの接続を開始するときに、必要な宛先、プロトコル、およびサービス品質が同じ複数のチャネルが存在する場合、WebLogic Serverは接続が確立されるか、試してみるチャネルがなくなるまでそれぞれを順番に試していきます。

RMIのサービス品質レベルについて

RMIルックアップの場合にだけ、WebLogic Serverは送信接続のサービス・レベルをアップグレードできます。たとえば、RMIルックアップを実行するためにT3接続が必要なときに、既存のチャネルでT3Sしかサポートしていない場合、ルックアップはT3Sチャネルを使用して実行されます。

URL自体にプロトコルが組み込まれているため、このアップグレードの動作はURLを使用するサーバー・リクエストには適用されません。たとえば、サーバーでは、https://のみをサポートするチャネルから、http://で始まるURLリクエストを送信することはできません。

WebLogic Serverの標準チャネル

WebLogic Serverでは、明示的に定義する必要のない定義済みチャネルが提供されます。

- デフォルト・チャネル - すべての管理対象サーバーにデフォルト・チャネルがあります。

- 管理チャネル - ドメイン全体の管理ポートを構成すると、WebLogic Serverではドメイン内の管理対象サーバーごとに管理チャネルが構成されます。

デフォルト・ネットワーク・チャネル

すべてのWebLogic Serverドメインには、WebLogic Serverによって自動的に生成されるデフォルト・チャネルがあります。デフォルト・チャネルは、ServerMBeanおよびSSLMBeanで定義されているリスニング・アドレスとリスニング・ポートに基づきます。それは、単一のリスニング・アドレス、HTTP(非セキュア)通信用の1つのポート(デフォルトは7001)、およびHTTPS(セキュア)通信用の1つのポート(デフォルトは7002)を提供します。リスニング・アドレスとリスニング・ポートは、WebLogic Server管理コンソールの「構成」>「一般」ページで構成できます。割り当てた値は、ServerMBeanおよびSSLMBeanの属性に格納されます。

デフォルトの構成は、次の場合に使用できます。

- 単純なネットワーク要件を備えたテスト環境にインストールしている場合。

- 1つのNICだけを使用し、デフォルト・ポート番号によって、ドメイン内のネットワーク・トラフィックを分割するのに十分な柔軟性が提供される場合。

デフォルトの構成を使用すると、サード・パーティの管理ツールと新しいインストールとの互換性が確保されます。ネットワーク構成の属性は、この場合もServerMBeanおよびSSLMBeanに格納されているためです。

ドメインにカスタム・ネットワーク・チャネルを定義して使用しても、デフォルト・チャネルの設定はServerMBeanとSSLMBeanにそのまま格納され、必要に応じてサーバー・インスタンスに接続を提供するために使用されます。

注意:

指定しない場合、WebLogic Serverはクラスタ通信に非セキュアなデフォルト・チャネルを使用し、クラスタ・メンバー間でセッション情報を送信します。非セキュア・チャネルを無効化した場合、クラスタ・セッション情報の非セキュア通信にはデフォルトで使用可能なチャネルは他にありません。これを解決するには:

- クラスタが通信にセキュア・チャネルを使用するようにClusterMBeanのsecureReplicationEnabled属性を有効化します。「レプリケーション・チャネルの構成」を参照してください

- 非セキュア通信用のカスタム・チャネルを作成します。「カスタム・チャネルはデフォルト・チャネル属性を継承可能」を参照してください

管理ポートと管理チャネル

オプションの管理ポートを定義にすることにより、ドメイン内で管理トラフィックとアプリケーション・トラフィックを分離できます。構成された管理ポートは、ドメインの各管理対象サーバーで、ドメインの管理サーバーとの通信用に排他的に使用されます。管理ポートが有効になっている場合、WebLogic Serverはサーバー・インスタンスの起動時にポート設定に基づいて自動的にドメインの管理チャネルを生成します。管理チャネルは、管理トラフィックを処理するためのリスニング・アドレスおよびリスニング・ポートを用意します。

管理ポートの機能

管理ポートを使用すると、以下のことができます。

- サーバーをスタンバイ状態で起動します。これにより、他のネットワーク接続がクライアント接続を受け入れない状態で管理対象サーバーを管理できます。スタンバイ状態の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のSTANDBY状態に関する項を参照してください。

- ドメイン内で、管理トラフィックをアプリケーション・トラフィックから分離します。本番環境では、トラフィックを分離すると、同じネットワーク接続上でクリティカルな管理操作(サーバーの起動と停止、サーバーの構成の変更、およびアプリケーションのデプロイ)が大量のアプリケーション・トラフィックと競争せずに済みます。

- WLSTを使用して、デッドロック状態のサーバー・インスタンスを管理します。管理ポートを構成しないと、threadDumpやshutdownなどの管理コマンドがデッドロック状態のサーバー・インスタンスで機能しません。

管理ポートの制限事項

管理ポートはセキュアなSSLトラフィックのみを受け付け、管理ポート経由の接続はすべて認証を必要とします。管理ポートを有効にすると、ドメインに以下の制約が課せられます。

- ドメイン内の管理サーバーとすべての管理対象サーバーは、SSLプロトコルをサポートするように構成する必要がある。SSLをサポートしない管理対象サーバーは、起動時に管理サーバーに接続できません - それらを構成するためには、管理ポートを無効にする必要があります。

- ドメイン内のすべてのサーバー・インスタンスが同時に管理ポートを有効または無効にする必要があるため、管理ポートはドメイン・レベルで構成します。個々の管理対象サーバーの管理ポート番号は変更できますが、管理対象サーバーごとに管理ポートを有効または無効にすることはできません。ポート番号を変更できると、同じリスニング・アドレスを持つサーバー・インスタンスが複数存在する場合に便利です。

- 管理ポートを有効にした後にドメイン内の管理対象サーバーを起動するには、管理サーバーへのSSL接続を確立する必要があります。この制限は、管理対象サーバーをコマンド行から起動するのか、またはノード・マネージャを使用して起動するのかに関係なく適用されます。SSL接続の確立方法については、「管理ポートで必須のSSL」を参照してください。

- 管理ポートを有効にした後は、すべてのWebLogic Server管理コンソールのトラフィックについて管理ポートを介した接続が必須になります。

- ドメイン全体の管理ポートを使用するドメイン内の同一のコンピュータ上で複数のサーバー・インスタンスが実行される場合には、以下のいずれかを行う必要があります。

- サーバー・インスタンスをマルチホーム・マシンでホストし、各サーバー・インスタンスに一意のリスニング・アドレスを割り当てます。

- または、マシン上にある、1つを除くすべてのサーバー・インスタンスにドメイン全体のポートをオーバーライドします。ポートをオーバーライドするには、WebLogic Server管理コンソールの「サーバー」>「接続」>SSLポートページの詳細属性の「ローカル管理ポートのオーバーライド」オプションを使用します。

管理ポートで必須のSSL

管理ポートではSSLが必要です。SSLは、WebLogic Serverをインストールするとデフォルトで有効になります。ドメインのいずれかのサーバー・インスタンス(管理サーバーとすべての管理対象サーバーを含む)でSSLが無効になっている場合は、WebLogic Server管理コンソールの「サーバー」>「構成」>「全般」ページを使用して再び有効にする必要があります。

ドメイン内の各サーバー・インスタンスでは、デフォルト・リスニング・ポートまたはデフォルトSSLリスニング・ポートが構成されている必要があります。デフォルト・ポートは、WebLogic Server管理コンソールの「サーバー」>「構成」>「全般」ページで割り当てます。デフォルト・ポートは、構成された管理ポートにサーバーがバインドできない場合に必要となります。追加のデフォルト・ポートが使用できる場合、サーバーは起動を続行します。その後で管理ポートを適切な値に変更できます。

デフォルトでは、WebLogic Serverはデモ用の証明書ファイルを使用するように構成されます。本番用のセキュリティ・コンポーネントを構成するには、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項の手順に従ってください。

管理ポートの構成

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの有効化に関する項に従って、管理ポートを有効にします。

管理ポートを構成した後は、その新しい管理ポートを使用するために、管理サーバーとすべての管理対象サーバーを再起動する必要があります。

管理ポートを使用するための管理対象サーバーの起動

コマンド行または起動スクリプトで管理対象サーバーを再起動する場合は、URLのポート部分で管理ポートを指定します。URLは、次のように、接頭辞としてhttp://ではなくhttps://を指定する必要があります。

-Dweblogic.management.server=https://host:admin_port

注意:

ノード・マネージャを使用して管理対象サーバーを再起動する場合は、管理対象サーバーの起動設定または引数を修正する必要はありません。ノード・マネージャは、正確なURLを自動的に取得し、それを使用して管理対象サーバーを起動します。

URLのホスト名が管理サーバーの証明書のホスト名と同じでない場合は、次のように、コマンド行または起動スクリプトでホスト名検証を無効にします。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

管理チャネルを使用するための管理対象サーバーの起動

管理対象サーバーが再起動の際に管理チャネルにバインドできるようにするには、次のコマンド行オプションを使用します。

-Dweblogic.admin.ListenAddress=<addr>

これにより、管理対象サーバーは、管理チャネルを使用して起動できるようになります。最初のブート・ストラップ接続後、標準の管理チャネルが使用されます。

注意:

このオプションは、config.xmlのダウンロード前に、確実に適切なNICセマンティクスが使用されるようにするのに役立ちます。

カスタム管理チャネル

標準のWebLogic Server管理チャネルで必要条件が満たされない場合は、管理トラフィック用にカスタム・チャネルを構成できます。たとえば、カスタム管理チャネルを使用すると、管理トラフィックを独立したNICに分けることができます。

管理トラフィック用のカスタム・チャネルを構成するには、「チャネルの構成」の説明に従ってチャネルを構成し、チャネル・プロトコルとして「admin」を選択します。以下の参照先で説明されている構成と使用方法のガイドラインに注意してください。

- 管理ポートで必須のSSL

- 管理ポートを使用するための管理対象サーバーの起動

内部チャネルの使い方

以前のバージョンのWebLogic Serverでは、外部トラフィック用に複数のチャネルを構成することは可能でしたが、サーバー・インスタンス間の内部トラフィックにはデフォルト・チャネルを使用する必要がありました。WebLogic Serverでは、クラスタ間の管理トラフィックや通信を処理するためのネットワーク・チャネルを作成できるようになりました。この機能は、以下の状況において有用です。

- 内部管理トラフィックを、他のネットワーク・トランザクションとは別にセキュアな接続で発生させる必要がある

- 他のタイプのネットワーク・トラフィック(たとえばレプリケーション・データ)を、別のネットワーク接続で発生させる必要がある

- 特定のタイプのネットワーク・トラフィックをモニターする必要がある

チャネルの選択

すべての内部トラフィックは、ネットワーク・チャネルを介して処理されます。管理トラフィックやクラスタリングされたトラフィックを処理するためのカスタム・ネットワーク・チャネルを作成していない場合は、接続に必要なプロトコルに基づいてデフォルト・チャネルが自動的に選択されます。デフォルト・チャネルの詳細は、「デフォルト・ネットワーク・チャネル」を参照してください。

クラスタ内の内部チャネル

クラスタ内には、以下のタイプのサーバー間接続を処理するための内部チャネルを作成できます。

- マルチキャスト・トラフィック

- レプリケーション・トラフィック

- 管理トラフィック

クラスタ内のチャネルの構成については、「クラスタにおけるネットワーク・チャネルの構成」を参照してください。

チャネルの構成

ネットワーク・チャネルは、WebLogic Server管理コンソールの「サーバー」>「プロトコル」>「チャネル」ページを使用するか、NetworkAccessPointMBeanを使用して構成します。

クラスタリングされている管理対象サーバーのチャネルを構成するには、「クラスタにおけるネットワーク・チャネルの構成」を参照してください。

ネットワーク・チャネルに関する主要な事実の要約と、その構成のガイドラインについては、「チャネルの構成のガイドライン」を参照してください。

チャネルの構成のガイドライン

チャネルを構成するときには、次のガイドラインに従ってください。

チャネルとサーバー・インスタンス

- 特定のサーバー・インスタンスで構成した各チャネルは、リスニング・アドレス、リスニング・ポート、およびプロトコルの組み合わせが一意である必要があります

- チャネルは1つのサーバー・インスタンスに割り当てることができます。

- サーバー・インスタンスには複数のチャネルを割り当てることができます。

- 非SSLチャネルとSSLチャネルを同じサーバー・インスタンスに割り当てる場合は、アドレスとポート番号の同じ組み合わせが使用されないようにする必要があります。

チャネルの動的な構成

- WebLogic Serverでは、サーバーを再起動せずにネットワーク・チャネルを構成できます。また、動的に構成されたチャネルを、サーバーの実行中に開始したり停止したりできます。ただし、サーバーの実行中にチャネルを停止した場合、進行中のタスクの正常な終了は試行されません。

チャネルとアイデンティティ

- デフォルトでは、ネットワーク・チャネルを構成するとき、チャネルはサーバー・インスタンス用に設定されているSSL構成を使用します。つまり、チャネルは、サーバー用に確立されるものと同じアイデンティティと信頼を使用します。サーバーは、サーバー・インスタンスおよびドメインの構成方法に応じて、そのサーバー固有のカスタム・アイデンティティを使用する場合とドメイン全体で1つのアイデンティティを使用する場合があります。

- ネットワーク・チャネルを構成して、そのチャネル固有のカスタム・アイデンティティ・キーストアおよびその他のSSL属性を使用できます。このことによって、サーバー用に構成されたアイデンティティと異なるアイデンティティをそのチャネルで使用できます。この機能を使用して、特定のクライアントと通信するときに異なるアイデンティティに切り替えることができるようにサーバーを構成できます。
詳細は、Oracle WebLogic Serverのセキュリティの管理のネットワーク・チャネルに固有のアイデンティティ・キーストアの構成に関する項を参照してください。

チャネルとプロトコル

- 一部のプロトコルではチャネルの特定の機能がサポートされていません。特に、COMプロトコルではSSLまたはトンネリングがサポートされていません。

- サーバー・インスタンスでサポートする必要のある各プロトコルで、別々のチャネルを定義する必要があります(HTTPを除きます)。
RMIプロトコルは通常、スタブとクラスをダウンロードするためにHTTPのサポートを必要とするため、チャネルを作成するとHTTPはデフォルトで有効になります。HTTPのサポートは、WebLogic Server管理コンソールの「サーバー」>「プロトコル」>「チャネル」ページの「詳細オプション」部で無効にできます。

予約済みの名前

- WebLogic Serverは、内部チャネル名.WLDefaultChannelおよび.WLDefaultAdminChannelを使用します。.WL接頭辞はチャネル名用に予約されています。カスタム・チャネルの名前の先頭に.WLを使用しないでください。

チャネル、プロキシ・サーバー、およびファイアウォール

プロキシWebサーバーとクラスタの間のファイアウォールが構成に含まれており(『Oracle WebLogic Serverクラスタの管理』のプロキシ・レイヤーとクラスタの間のファイアウォールに関する項を参照)、クラスタリングされたサーバーが、HTTPSトラフィックとHTTPトラフィックを分離するために2つのカスタム・チャネルで構成されている場合、それらのチャネルでは同じリスニング・アドレスを共有する必要があります。さらに、HTTPトラフィックとHTTPSトラフィックの両方をサポートする必要がある場合は、それぞれに対してカスタム・チャネルが必要となります。どちらかでデフォルト構成を使用することはできません。

それらのチャネルのいずれかで(ファイアウォールの存在から予想されるように)PublicAddressが定義されている場合、両方のチャネルでPublicAddressを定義する必要があり、かつ両方とも同じPublicAddressを定義する必要があります。

クラスタにおけるネットワーク・チャネルの構成

クラスタリングされている管理対象サーバーのチャネルを構成するには、「チャネルの構成のガイドライン」の情報に注意し、以降の項で説明されているガイドラインに従ってください。

クラスタの作成

クラスタがまだ構成されていない場合は、次のことができます。

- 『Oracle WebLogic Serverクラスタの管理』のクラスタリングされたドメインの作成に関する項に従って、構成ウィザードを使用してクラスタリングされたドメインを新たに作成します。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの作成と構成に関する項に従って、WebLogic Server管理コンソールを使用して既存のドメインでクラスタを作成します。

WebLogic Serverクラスタの構成の詳細およびガイドラインは、『Oracle WebLogic Serverクラスタの管理』の「開始する前に」を参照してください。

ネットワーク・チャネルの作成および割当て

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのネットワーク・チャネルの構成に関する項に従って、クラスタ内の各管理対象サーバーで新しいネットワーク・チャネルを作成します。新しいチャネルを作成する場合は、次のようにします。

- クラスタで使用するチャネルごとに、クラスタ内の各管理対象サーバーで名前も含めてまったく同じようにチャネルを構成します。

- 各管理対象サーバーのチャネルで定義したリスニング・ポートとSSLリスニング・ポートが、管理対象サーバーのデフォルト・リスニング・ポートと必ず異なるようにします。カスタム・チャネルで管理対象サーバーのデフォルト・ポートと同じポートが指定される場合は、カスタム・チャネルと管理対象サーバーのデフォルト・チャネルがそれぞれ同じポートにバインドしようとするので、管理対象サーバーを起動できなくなります。

- クラスタでクラスタ・アドレスが明示的に構成されている場合は、「サーバー」>「プロトコル」>「チャネル」>「構成」ページの「クラスタ・アドレス」フィールドにそのアドレスが表示されます。
動的なクラスタのアドレス指定を使用している場合は、「クラスタ・アドレス」フィールドが空白になっており、クラスタ・アドレスを指定する必要はありません。クラスタ・アドレスの詳細、およびWebLogic Serverでクラスタ・アドレスを動的に生成する方法については、『Oracle WebLogic Serverクラスタの管理』のクラスタ・アドレスに関する項を参照してください。

注意:

動的なクラスタ・アドレッシングを使用する場合は、「サーバー」>「プロトコル」>「チャネル」>「構成」ページでクラスタ・アドレスを指定しないようにしてください。クラスタ・アドレスを明示的に指定すると、その値が優先され、クラスタ・アドレスが動的に生成されなくなります。

レプリケーション・チャネルの構成

レプリケーション・チャネルは、クラスタ間でレプリケーション情報を転送するためのネットワーク・チャネルです。レプリケーション・チャネルが明示的に定義されていない場合、レプリケーション情報はデフォルトのネットワーク・チャネルで転送されます。

WebLogic Serverでデフォルトのネットワーク・チャネルをレプリケーション・チャネルとして使用する場合、SSL暗号化はデフォルトでは使用されません。ClusterMBeanのsecureReplicationEnabled属性を使用してSSL暗号化を有効にする必要があります。この設定は、WebLogic Server管理コンソールから更新することもできます。

SSL暗号化を有効にすると、設計上、セッション・レプリケーションによってブロックされるため(つまり、レプリケーションが完了するまでレスポンスがクライアントに送信されないため)、クラスタリングされたアプリケーションのスループットに直接影響する可能性があります。レプリケーション・チャネルでSSLを有効にする場合は、この点を考慮に入れるようにしてください。

レプリケーション・チャネルが明示的に定義されている場合は、そのチャネルのプロトコルを使用してレプリケーション・トラフィックが転送されます。

多数チャネルの使用時におけるパケット・サイズの増大

1つのクラスタ内でおよそ20以上のチャネルを使用すると、ヘッダーのマルチキャスト送信がデフォルトの最大パケット・サイズを超過することがあります。config.xmlのServer要素に含まれるMTUSize属性では、関連するネットワーク・カードを使用して、送信されるパケットの最大サイズを1500に設定しています。MTUSizeの値を超えるパケットを送信すると、java.lang.NegativeArraySizeExceptionが送出されます。パケットのサイズがMTUSizeを超えることから生じる例外を防止するには、MTUSizeの値をデフォルト値の1500より大きくします。

EJBへのカスタム・チャネルの割当て

EJBにカスタム・チャネルを割り当てることができます。カスタム・チャネルを構成したら、weblogic-ejb-jar.xmlのnetwork-access-point要素を使用してEJBに割り当てます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のnetwork-access-pointに関する項を参照してください。

IPv4でのIPv6の使用

WebLogic Serverは、インターネット・プロトコル(IP)バージョン4または6 (IPv4またはIPv6)のいずれかを使用するように構成されているホスト・マシンをサポートします。

ネットワーク通信でIPv4を使用するマシンとIPv6を使用するマシンが混在しているドメインがあり、管理サーバーがIPv4を使用するマシンにホストされている場合、IPv6を使用するマシンにホストされている管理対象サーバー・インスタンスのステータスはWebLogic Server管理コンソールで「不明」と表示される場合があります。

WebLogic Server管理コンソールでこれらの管理対象サーバー・インスタンスのステータスを確認できるようにするには、これらのリスニング・アドレスを指定する必要があります。サーバーが動作中の場合、リスニング・アドレスを指定した後にサーバーを再起動する必要があります。WebLogic Server管理コンソールを使用した既存のドメインの管理対象サーバーのリスニング・アドレスの割当ての詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・アドレスの構成に関する項を参照してください。

構成ウィザードを使用して構成する場合、管理対象サーバーのリスニング・アドレスも指定できます。「管理対象サーバー」ページで、「リスニング・アドレス」フィールドに各管理対象サーバーの物理IPアドレスを入力し、変更を保存して構成を続行します。

5 Webサーバー機能の構成

この章では、WebLogic Server にホストされているJava EE Webアプリケーションを構成し、標準HTTP Webサーバーがホストする静的コンテンツとして機能させる方法について説明します。Webアプリケーションでは、JSPおよびサーブレットなどの動的コンテンツもホストできます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。

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

- Webサーバー・コンポーネントの構成の概要

- サーバーの構成

- Webアプリケーション

- 仮想ホスティングの構成

- WebLogic ServerによるHTTPリクエストの解決方法

- HTTPアクセス・ログの設定

- POSTサービス拒否攻撃の防止

- HTTPトンネリングのためのWebLogic Serverの設定

- ネイティブI/Oを使用した静的ファイルの提供(Windowsのみ)

Webサーバー・コンポーネントの構成の概要

WebLogic Serverは、動的なJavaベース分散アプリケーションをホストする他にも、大容量Webサイトを処理する高機能Webサーバーとして、HTMLファイルや画像ファイルなどの静的ファイル、およびサーブレットとJavaServer Pages (JSP)を提供します。WebLogic Serverでは、HTTP 1.1規格をサポートしています。

サーバーの構成

各WebLogic ServerがHTTPリクエストをリスニングするポートを指定できます。任意の有効なポート番号を指定できますが、ポート80を指定した場合、HTTPを介してリソースにアクセスするために使用するHTTPリクエストからポート番号を省略できます。たとえば、リスニング・ポートとしてポート80を定義した場合、http://hostname:portnumber/myfile.htmlではなく、http://hostname/myfile.htmlという形式を使用できます。

UNIXシステムでは、プロセスを1025より小さいポートにバインドする場合は、権限があるユーザー(通常はroot)で行う必要があります。したがって、WebLogic Serverがポート80をリスニングするようにするには、権限があるユーザーとしてWebLogic Serverを起動しなければなりません。しかし、セキュリティの観点からすると、WebLogic Serverのように長時間にわたって実行するプロセスを、必要以上の権限で実行するのは望ましくありません。WebLogic Serverにroot権限が必要なのは、ポートがバインドされるまでです。

WebLogic Serverでは、ポート80にバインドした後、そのUNIXユーザーID (UID)またはUNIXグループID (GID)、あるいはその両方を切り替えることができます。UID(またはGID)は、WebLogic Server管理コンソールを介して(「リスニング・ポートの構成」を参照)、またはWLSTを使用してUnixMachineMBeanにアクセスすることにより変更できます。UIDはUnixMachineMBbean.setPostBindUID()を使用して設定し、UnixMachineMBean.setPostBindUIDEnabled()をtrueに設定してスイッチを有効化します。同様に、GIDはUnixMachineMBean.setPostBindGID()メソッドおよびUnixMachineMBean.setPostBindGIDEnabled()メソッドを使用して変更できます。

UNIXアカウントは、ほとんどのUNIXシステムで権限が最も低い「nobody」に切り替えることができます。必要な場合は、WebLogic Serverの実行専用のUNIXユーザー・アカウントを作成します。権限のないユーザーは、WebLogic Serverで必要になるファイル(ログ・ファイル、WebLogicクラスなど)にアクセスできるように設定してください。WebLogicプロセスの所有権が権限のないユーザーに切り替わると、WebLogicの読み込み、書き込み、および実行の許可がそのユーザーと同じになります。

リスニング・ポートは、非SSLのリクエストとセキュアな(SSLを使用した)リクエストで別個に定義します。リスニング・ポートの構成の詳細は、「ネットワーク・チャネルの理解」を参照してください。

リスニング・ポートの構成

1. WebLogic Server管理コンソールを使用して、リスニング・ポートにポート80を設定します。「リスニング・ポートの構成」を参照してください。

2. WebLogic ServerをホストしているマシンでWindowsが動作している場合、ステップ8へ進みます。

3. WebLogic Server管理コンソールを使用して新しいUNIXマシンを作成します。「マシンの作成と構成」を参照してください。

4. 「バインド後のユーザーIDを有効化」フィールドを選択します。

5. 「バインド後のユーザーID」フィールドに、WebLogic Serverを実行するユーザーの名前を入力します。

6. 「バインド後のグループIDを有効化」フィールドを選択します。

7. 「バインド後のグループIDを有効化」フィールドに、WebLogic Serverを実行するグループの名前を入力します。

8. 「保存」をクリックします。

9. WebLogic Server管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

Webアプリケーション

HTTPアプリケーションとWebアプリケーションは、Java EE サーブレット仕様3.0およびJSP仕様2.2に従ってデプロイされます。これらの仕様では、WebアプリケーションがWebベース・アプリケーションのコンポーネントをグループ化するための標準として定義されています。これらのコンポーネントには、JSPページ、HTTPサーブレット静的リソース(HTMLページや画像ファイルなど)が含まれます。またWebアプリケーションは、エンタープライズEJBやJSPタグ・ライブラリなどの外部リソースにアクセスすることもできます。各サーバーは、任意の数のWebアプリケーションのホストになることができます。通常、Webアプリケーションの名前は、そのWebアプリケーションからリソースをリクエストするために使用するURIの一部として使用します。

詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください

Webアプリケーションとクラスタリング

Webアプリケーションは、WebLogic Serverクラスタにデプロイできます。ユーザーがWebアプリケーションのリソースをリクエストすると、そのリクエストはそのWebアプリケーションがホストするクラスタ内のサーバーの1つに転送されます。アプリケーションがセッション・オブジェクトを使用する場合、そのセッションはクラスタ内の全ノードにレプリケートする必要があります。セッションのレプリケートにはいくつかの方法があります。

詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

仮想ホスティングの構成

仮想ホスティングを使用すると、サーバーまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic ServerインスタンスまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を、DNSを使って指定します。また、仮想ホストによって提供されるWebアプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード・バランシング機能により、DNSホスト名の1つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。

たとえば、booksというWebアプリケーションが仮想ホスト名www.books.comのリクエストに応答し、これらのリクエストがWebLogic Server A、B、およびCに向けられるよう指定し、一方、carsというWebアプリケーションが仮想ホスト名www.autos.com に応答し、これらのリクエストがWebLogic Server DおよびEに向けられるよう指定できます。アプリケーションとWebサーバーの要件に合わせて、仮想ホスト、WebLogic Serverインスタンス、クラスタ、およびWebアプリケーションの様々な組合せを構成できます。

また、定義した各仮想ホストに対して、個別にHTTPパラメータとHTTPアクセス・ログを定義できます。仮想ホストに対して設定されたHTTPパラメータとアクセス・ログは、サーバーに対して設定されたHTTPパラメータとアクセス・ログをオーバーライドします。指定できる仮想ホストの数に制限はありません。

仮想ホスティングをアクティブ化するには、仮想ホストをサーバーまたはサーバー・クラスタに割り当てます。クラスタに割り当てられた仮想ホスティングは、そのクラスタ内のすべてのサーバーに適用されます。

仮想ホスティングとデフォルトWebアプリケーション

各仮想ホストに対して、デフォルトWebアプリケーションを指定することもできます。仮想ホストのデフォルトWebアプリケーションは、同じサーバーまたはクラスタで仮想ホストとしてデプロイされている別のWebアプリケーションで解決できないすべてのリクエストに応答します。

他のWebアプリケーションとは異なり、デフォルトWebアプリケーションの名前(コンテキスト・パスともいう)は、そのデフォルトWebアプリケーションのリソースにアクセスするために使うURIの一部として使用されません。

たとえば、www.mystore.comという仮想ホスト名を定義し、shoppingというWebアプリケーションをデプロイしたサーバーにその仮想ホストを割り当てた場合、shoppingのcart.jspというJSPにアクセスするには、次のURIを使用します。

http://www.mystore.com/shopping/cart.jsp

しかし、shoppingをこの仮想ホストwww.mystore.comのデフォルトWebアプリケーションとして宣言した場合は、次のURIを使用してcart.jspにアクセスします。

http://www.mystore.com/cart.jsp

詳細は、「WebLogic ServerによるHTTPリクエストの解決方法」を参照してください。

複数の仮想ホストを別々のデフォルトWebアプリケーションで使用する場合は、シングル・サインオンは使用できません。それぞれのWebアプリケーションが、以前のWebアプリケーションに設定されたJSESSIONID Cookieを上書きしてしまうためです。これは、すべてのデフォルトWebアプリケーションでCookieName、CookiePath、およびCookieDomainをまったく同じにしても発生します。

仮想ホストの設定

1. を使用して仮想ホストを定義します。「仮想ホスト」を参照してください。

2. 仮想ホスト名を確実に解決できるように、サーバー上のetc/hostsファイルに仮想ホストのネーミングの行を追加します。

WebLogic ServerによるHTTPリクエストの解決方法

WebLogic ServerがHTTPリクエストを受信すると、WebLogic Serverは、URLの様々な部分を解析し、その情報を利用してどのWebアプリケーションとサーバーがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。表5-1では、Webアプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストの様々な組み合わせとそのレスポンスを示します。

注意:

Webアプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化する場合は、Webアプリケーションへのリクエストの解決に使用するために、Webアプリケーションに別の名前を指定できます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください

表5-1に、WebLogic Serverによって提供されるURLとファイルのサンプルを示します。「索引ディレクトリはチェックされているか」の列は、特定のファイルがリクエストされなかった場合にディレクトリ・リストを提供するかどうかを制御する索引ディレクトリ属性の設定を示します。

表5-1 WebLogic ServerによるURLの解決例

URL

索引ディレクトリはチェックされているか

レスポンスで提供されるファイル

http://host:port/apples

いいえ

apples Webアプリケーションに定義されているウェルカム・ファイル*

http://host:port/apples

はい

apples Webアプリケーションの最上位レベルのディレクトリのリスト

http://host:port/oranges/naval

どちらでもよい

oranges Webアプリケーション内の/navalという<url-pattern>でマップされているサーブレット。

サーブレット・マッピングには、いくつかの考慮事項があります。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。

http://host:port/naval

どちらでもよい

oranges Webアプリケーション内の/navalという<url-pattern>にマップされているサーブレットがデフォルトWebアプリケーションとして定義されています。

詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。

http://host:port/apples/pie.jsp

どちらでもよい

apples Webアプリケーションの最上位ディレクトリにあるpie.jsp

http://host:port

はい

デフォルトWebアプリケーションの最上位レベルのディレクトリのリスト

http://host:port

いいえ

デフォルトWebアプリケーションのウェルカム・ファイル*

http://host:port/apples/myfile.html

どちらでもよい

apples Webアプリケーションの最上位レベルのディレクトリにあるmyfile.html

http://host:port/myfile.html

どちらでもよい

デフォルトWebアプリケーションの最上位レベルのディレクトリにあるmyfile.html

http://host:port/apples/images/red.gif

どちらでもよい

apples Webアプリケーションの最上位ディレクトリのimagesサブディレクトリにあるred.gif

http://host:port/myFile.html

myfile.htmlがapples Webアプリケーションに存在せず、デフォルト・サーブレットが定義されていない場合

どちらでもよい

エラー404

http://www.fruit.com/

いいえ

www.fruit.comというホスト名を持つ仮想ホストのデフォルトWebアプリケーションのウェルカム・ファイル

http://www.fruit.com/

はい

www.fruit.comというホスト名を持つ仮想ホストのデフォルトWebアプリケーションの最上位レベルのディレクトリのリスト

http://www.fruit.com/oranges/myfile.html

どちらでもよい

www.fruit.comというホスト名の仮想ホストに関連付けられているoranges Webアプリケーションのmyfile.html

HTTPアクセス・ログの設定

WebLogic Serverは、HTTPトランザクションのログを、共通ログ・フォーマットまたは拡張ログ・フォーマットのいずれかのフォーマットでテキスト・ファイルに保存します。デフォルトは共通ログ・フォーマットです。拡張ログ・フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバー・インスタンスまたは各仮想ホストに対して、HTTPアクセス・ログの動作を定義する属性を設定できます。

サーバーまたは仮想ホストに対するHTTPログを設定するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- 「HTTPログの有効化と構成」

- 「仮想ホストのHTTPログ・ファイル設定の構成」

ログ・ローテーション

ログ・ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションさせることができます。どちらかの条件が満たされると、現在のアクセス・ログ・ファイルが閉鎖され、新しいログ・ファイルが開始されます。ログ・ローテーションを設定しないと、HTTPアクセス・ログ・ファイルは無限に大きくなります。アクセス・ログ・ファイルの名前は、いつファイルがローテーションされたのかを示す日付と時刻のスタンプが含まれるように構成できます。タイムスタンプを構成しない場合、ローテーションされた各ファイルの名前にはローテーションごとにインクリメントされる数値が含まれます。HTTPアクセス・ログは、定義した仮想ホストごとに保存されます。

共通ログ・フォーマット

ログに記録されるHTTP情報のデフォルトのフォーマットは、共通ログ・フォーマットです(http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-formatを参照)。この標準フォーマットのパターンは以下のとおりです。

host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes

説明:

host

リモート・クライアントのDNS名またはIP番号。

RFC931

リモート・クライアントのIDENTDによって戻された情報。WebLogic Serverでは、ユーザー識別はサポート対象外。

auth_user

リモート・クライアントのユーザーが認証用にユーザーIDを送信した場合、そのユーザー名。それ以外の場合は「-」。

day/month/year:hour:minute:second UTC_offset

日、月、年、時間(24時間形式)、および現地時間とGMTの時差(大カッコで囲まれて示されます)。

"リクエスト"

リモート・クライアントによって送信されたHTTPリクエストの最初の行(二重引用符で囲まれて示されます)。

status

使用可能な場合、サーバーによって戻されたHTTPステータス・コード。それ以外の場合は「-」。

bytes

既知の場合、HTTPヘッダーでコンテンツ長として示されるバイト数(HTTPヘッダーは含まない)。それ以外の場合は「-」

拡張ログ・フォーマットを使用したHTTPアクセス・ログの設定

WebLogic Serverは、拡張ログ・ファイル・フォーマットのバージョン1.0もサポートしています。これはW3C (http://www.w3.org/TR/WD-logfile.html)の仕様草案で定義された新しく拡大しつつある標準です。この件について現在、最も信頼性のある参照先は「W3C Technical Reports and Publications」ページ(http://www.w3.org/TR/)です。

拡張ログ・フォーマットを使用すると、各HTTP通信に関する記録情報のタイプと順序を指定できます。WebLogic Server管理コンソールでこのフォーマットを有効化する手順は次のとおりです。

1. 「server-name」→「ロギング」→「HTTP」ページに移動します。

2. 「HTTPアクセス・ログ・ファイルの有効化」チェック・ボックスが選択されていることを確認します。

3. 「詳細」をクリックします。

4. 「フォーマット」フィールドで、「拡張」を選択します。

「拡張ロギング・フォーマットのフィールド」フィールドでは、「サポートされるフィールド識別子」に記載されている1つ以上のフィールドを選択できます。HTTPアクセス・ログ・ファイルにカスタム・フィールドを追加する場合は、「カスタム・フィールド識別子の作成」を参照してください。

このフォーマットでは、ログ・ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ・ファイルに組み込まれます。ディレクティブは、新しい行からシャープ記号(#)で始まります。ログファイルが存在しない場合、デフォルト・ディレクティブが記述された新しいログ・ファイルが作成されます。しかし、サーバーの起動時にログ・ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが記述されている必要があります。

Fieldsディレクティブの作成

ログ・ファイルの最初の行には、そのログ・ファイル・フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fieldsディレクティブが存在しなければなりません。

#Version: 1.0
#Fields: xxxx xxxx xxxx ...

ここで各xxxxは、記録されるデータ・フィールドを表します。フィールド・タイプは、W3C仕様に定義されているとおり、単純な識別子として指定されるか、または接頭辞-識別子というフォーマットを取ります。例:

#Fields: date time cs-method cs-uri

この識別子は、HTTPアクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト・メソッド、およびリクエストのURIを記録するようサーバーに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ・ファイルに追加されます。

注意:

ログ・ファイル内の#Fieldsディレクティブの後には新しい行が続かなければなりません。これは、最初のログ・メッセージがディレクティブと同じ行に追加されないようにするためです。

サポートされるフィールド識別子

以下の識別子がサポートされています。接頭辞は必要ありません。

date

トランザクションが完了した日付。W3C仕様で定義されているフィールド・タイプは<date>。

time

トランザクションが完了した時間。W3C仕様で定義されているフィールド・タイプは<time>。

time-taken

トランザクションが完了するまでの時間。W3C仕様で定義されているフィールド・タイプは<fixed>。

bytes

転送されたバイト数。フィールド・タイプは<integer>。

W3C仕様で定義されているcachedフィールドは、WebLogic Serverではサポートされていません。

以下の識別子は接頭辞を必要とし、単独では使用できません。ここでは、サポートされている個々の接頭辞の組み合わせについて説明します。

IPアドレス関連フィールド

これらのフィールドには、リクエストを行ったクライアントまたは応答したサーバーのいずれかのIPアドレスとポートが記録されます。W3C仕様で定義されているフィールド・タイプは<address>です。サポートされるフィールドは、次のとおりです。

c-ip

クライアントのIPアドレス。

s-ip

サーバーのIPアドレス。

DNS関連フィールド

これらのフィールドには、クライアントまたはサーバーのドメイン名が記録されます。W3C仕様で定義されているフィールド・タイプは<name>です。サポートされるフィールドは、次のとおりです。

c-dns

リクエストを送信したクライアントのドメイン名。

s-dns

リクエストを受信したサーバーのドメイン名。

sc-status

レスポンスのステータス・コード。たとえば、(404)は「File not found」というステータスを表します。W3C仕様で定義されているフィールド・タイプは<integer>です。

sc-comment

ステータス・コードと一緒に戻されるコメント(「File not found」など)。このフィールド・タイプは<text>です。

cs-method

リクエスト・メソッド(GETやPOSTなど)。W3C仕様で定義されているフィールド・タイプは<name>です。

cs-uri

完全なリクエストURI。W3C仕様で定義されているフィールド・タイプは<uri>です。

cs-uri-stem

URIの基本部分のみ(問合せを省略)。W3C仕様で定義されているフィールド・タイプは<uri>です。

cs-uri-query

URIの問合せ部分のみ。W3C仕様で定義されているフィールド・タイプは<uri>です。

診断メッセージ相関フィールド

これらのフィールドには、診断メッセージのメッセージ相関情報が記録されます。これは、コンポーネント全体のメッセージ間の関係を判断する際に役立ちます。これらのフィールドは、診断コンテキストが存在する場合、および実行されたリクエストに対して作成される場合に記録されます。診断コンテキストは、受信リクエストでサーバーに伝搬された場合には存在する可能性があり、診断コンテキストが有効な場合にWebLogic Serverによってリクエストに対して作成される可能性があります。サポートされるフィールドは、次のとおりです。

ctx-ecid

実行コンテキストID (ECID)。ECIDは、特定のリクエストの実行に関連付けられたグローバル一意識別子です。

ctx-rid

関係ID (RID)。RIDは、あるプロセスのあるスレッドで行われた作業と、同じリクエストを受けて同じプロセスおよび別のプロセスの別のスレッドで行われた作業を区別します。

診断コンテキストが存在しない場合、またはECIDとRIDの値が診断コンテキストで使用できない場合、その値としてハイフン(-)が記録されます。ECIDおよびRIDの詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルおよびコンポーネント全体におけるメッセージの相関関係に関する項を参照してください。

カスタム・フィールド識別子の作成

拡張ログ・フォーマット(ELF)を使用するHTTPアクセス・ログ・ファイルに追加するために、ユーザー定義のフィールドを作成することもできます。カスタム・フィールドを作成するには、ELFログ・ファイルでFieldsディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成されるJavaクラスを作成します。フィールドごとに別々のJavaクラスを作成することも、複数のフィールドを出力するJavaクラスを作成することもできます。このようなクラスのJavaソースの例については、例5-1を参照してください。

カスタム・フィールドを作成するには:

1. 次の形式を使用して、Fieldsディレクティブにフィールド名を追加します。

x-myCustomField.

myCustomFieldは完全修飾クラス名です。

Fieldsディレクティブの詳細は、「Fieldsディレクティブの作成」を参照してください

2. Fieldsディレクティブで定義したカスタム・フィールド(myCustomFieldなど)と同じ完全修飾クラス名を持つJavaクラスを作成します。このクラスではカスタム・フィールドにロギングする情報を定義します。Javaクラスには次のインタフェースを実装する必要があります。

weblogic.servlet.logging.CustomELFLogger

Javaクラスでは、logField()メソッドを実装しなければなりません。このメソッドは、HttpAccountingInfoオブジェクトとFormatStringBufferオブジェクトを引数として取ります。

- HttpAccountingInfoオブジェクトを使用して、HTTPリクエストとカスタム・フィールドに出力できるレスポンス・データにアクセスします。この情報にアクセスするためのゲッター・メソッドが提供されています。getメソッドの完全なリストについては、「HttpAccountingInfoオブジェクトのgetメソッド」を参照してください。

- FormatStringBufferクラスを使用して、カスタム・フィールドのコンテンツを作成します。適切な出力を作成するためのメソッドが提供されています。

3. Javaクラスをコンパイルして、WebLogic Serverの起動に使用されるCLASSPATH文にクラスを追加します。WebLogic Serverの起動に使用するスクリプト内のCLASSPATH文を変更する必要があります。

注意:

このクラスを、展開形式またはjar形式で、Webアプリケーションまたはエンタープライズ・アプリケーションの内部に配置しないでください。

4. 拡張ログ・フォーマットを使用するようにWebLogic Serverを構成します。詳細は、「拡張ログ・フォーマットを使用したHTTPアクセス・ログの設定」を参照してください。

注意:

カスタム・フィールドを定義するJavaクラスの記述では、システムの処理速度を低下させるようなコードは実行しないでください(たとえば、DBMSへのアクセス、大量のI/O、またはネットワークの呼び出しなど。)HTTPアクセス・ログ・ファイルのエントリはHTTPリクエストごとに作成されます。

注意:

複数のフィールドを出力する場合は、タブでフィールドを区切ります。複数のフィールドを区切る方法や、その他のELFフォーマット問題の詳細は、http://www.w3.org/TR/WD-logfile-960221.htmlの「Extended Log Format」を参照してください。

HttpAccountingInfoオブジェクトのgetメソッド

次のメソッドはHTTPリクエストに関する様々なデータを戻します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、およびjavax.servlet.http.HttpServletResponseの様々なメソッドと似ています。

これらのインタフェースのJavadocは、次の場所で入手できます。

- http://docs.oracle.com/javaee/7/api/javax/servlet/ServletRequest.html

- http://docs.oracle.com/javaee/7/api/javax/servlet/ServletResponse.html

- http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html

これらのメソッドの詳細は、次の表に示すJavaインタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。

表5-2 HttpAccountingInfoのゲッター・メソッド

HttpAccountingInfoのメソッド

メソッドに関する情報

Object getAttribute(String name);

javax.servlet.ServletRequest

Enumeration getAttributeNames();

javax.servlet.ServletRequest

String getCharacterEncoding();

javax.servlet.ServletRequest

int getResponseContentLength();

javax.servlet.ServletResponse.setContentLength()

このメソッドはレスポンスのコンテンツ長を取得し、setContentLength()メソッドと共に設定します。

String getContentType();

javax.servlet.ServletRequest

Locale getLocale();

javax.servlet.ServletRequest

Enumeration getLocales();

javax.servlet.ServletRequest

String getParameter(String name);

javax.servlet.ServletRequest

Enumeration getParameterNames();

javax.servlet.ServletRequest

String[] getParameterValues(String name);

javax.servlet.ServletRequest

String getProtocol();

javax.servlet.ServletRequest

String getRemoteAddr();

javax.servlet.ServletRequest

String getRemoteHost();

javax.servlet.ServletRequest

String getScheme();

javax.servlet.ServletRequest

String getServerName();

javax.servlet.ServletRequest

int getServerPort();

javax.servlet.ServletRequest

boolean isSecure();

javax.servlet.ServletRequest

String getAuthType();

javax.servlet.http.HttpServletRequest

String getContextPath();

javax.servlet.http.HttpServletRequest

Cookie[] getCookies();

javax.servlet.http.HttpServletRequest

long getDateHeader(String name);

javax.servlet.http.HttpServletRequest

String getHeader(String name);

javax.servlet.http.HttpServletRequest

Enumeration getHeaderNames();

javax.servlet.http.HttpServletRequest

Enumeration getHeaders(String name);

javax.servlet.http.HttpServletRequest

int getIntHeader(String name);

javax.servlet.http.HttpServletRequest

String getMethod();

javax.servlet.http.HttpServletRequest

String getPathInfo();

javax.servlet.http.HttpServletRequest

String getPathTranslated();

javax.servlet.http.HttpServletRequest

String getQueryString();

javax.servlet.http.HttpServletRequest

String getRemoteUser();

javax.servlet.http.HttpServletRequest

String getRequestURI();

javax.servlet.http.HttpServletRequest

String getRequestedSessionId();

javax.servlet.http.HttpServletRequest

String getServletPath();

javax.servlet.http.HttpServletRequest

Principal getUserPrincipal();

javax.servlet.http.HttpServletRequest

boolean isRequestedSessionIdFromCookie();

javax.servlet.http.HttpServletRequest

boolean isRequestedSessionIdFromURL();

javax.servlet.http.HttpServletRequest

boolean isRequestedSessionIdFromUrl();

javax.servlet.http.HttpServletRequest

boolean isRequestedSessionIdValid();

javax.servlet.http.HttpServletRequest

byte[] getURIAsBytes();

HTTPリクエストのURIをバイト配列として戻します。たとえば、HTTPリクエストの最初の行がGET /index.html HTTP/1.0である場合、/index.htmlをバイト配列として戻します。

long getInvokeTime();

currentTimeMillis()の開始時間を戻します。

サーブレットがクライアントにレスポンスを送信するときにかかる時間の長さを取得するには、次のコードを使用します。

long milsec = System.currentTimeMillis() - metrics.getInvokeTime();

Float sec = new Float(milsec / 1000.0);

int getResponseStatusCode();

javax.servlet.http.HttpServletResponse

String getResponseHeader(String name);

javax.servlet.http.HttpServletResponse

例5-1 カスタムELFフィールドを作成するJavaクラス

import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* This example outputs the User-Agent field into a
custom field called MyCustomField
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}

POSTサービス拒否攻撃の防止

サービス拒否攻撃とは、偽りのリクエストによってサーバーを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の1つは、HTTP POSTメソッドで膨大な量のデータを送信するというものです。WebLogic Serverでは、3つの属性を設定して、この種の攻撃を防くことができます。これらの属性は、コンソールの「サーバー」または「仮想ホスト」で設定します。これらの属性を仮想ホストに対して設定した場合、その値は「サーバー」で設定した値をオーバーライドします。

PostTimeoutSecs

HTTP POSTに含まれる大量のデータをWebLogic Serverが受信する間隔。

PostTimeoutSecsのデフォルト値は30です。

MaxPostTimeSecs

WebLogic ServerがPOSTデータを受信するために費やす最長時間。この制限を超えた場合、PostTimeoutExceptionがスローされ、次のメッセージがサーバー・ログに記録されます。

Post time exceeded MaxPostTimeSecs.

MaxPostTimeSecsのデフォルト値は30です。

MaxPostSize

単一のPOSTリクエストで受領するデータの最大バイト数。この制限を超えた場合、MaxPostSizeExceeded例外がスローされ、次のメッセージがサーバー・ログに記録されます。

POST size exceeded the parameter MaxPostSize.

HTTPエラー・コード413 (Request Entity Too Large)がクライアントに返されます。

クライアントがリスニング・モードの場合、クライアントはこれらのメッセージを取得します。クライアントがリスニング・モードでない場合は、接続は切断されます。

MaxPostSizeのデフォルト値は -1です。

HTTPトンネリングのためのWebLogic Serverの設定

HTTPトンネリングとは、HTTPプロトコルしか使用できないときに、WebLogic ServerとJavaクライアントの間にステートフルなソケット接続をシミュレートするための手段です。通常セキュリティ・ファイアウォール内のHTTPポートを「トンネリング」するために使用されます。HTTPはステートレスなプロトコルですが、WebLogic Serverはトンネリング機能を提供して接続を通常のT3Connectionのように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。

HTTPトンネリング接続の設定

HTTPプロトコルでは、クライアントはリクエストを送信し、サーバーから応答を受信することしかできません。サーバーは自主的にクライアントと通信できず、プロトコルはステートレスです - これは、連続的な双方向接続ができないことを意味します。

WebLogic HTTPトンネリングは、HTTPプロトコル経由でT3Connectionをシミュレートすることによって、こうした制限を打開します。には、トンネリング接続を調整してパフォーマンスが向上するように構成できる属性がいくつかあります。接続に関する問題が発生しないかぎり、これらの制限を克服します。サーバーは、これらのプロパティを使用して、クライアント接続が有効であるかどうか、またはクライアントが有効であるかを判断します。

トンネリングを有効化

HTTPトンネリングを有効または無効にします。HTTPトンネリングはデフォルトでは無効です。

HTTPトンネリングを使用するには、サーバーでHTTPプロトコルとT3プロトコルの両方がサポートされている必要があります。

トンネリング・クライアントPing

HTTPトンネリング接続が設定されると、クライアントは自動的にリクエストをサーバーに送信し、サーバーは自主的にクライアントにレスポンスできるようになります。また、クライアントはリクエストに指示を含めることができますが、この処理はクライアント・アプリケーションがサーバーと通信する必要があるかどうかに関係なく発生します。この属性で設定された秒数以内にサーバーがクライアントのリクエストに(アプリケーション・コードの一部として)応答しない場合、クライアントはその処理を行います。クライアントはレスポンスを受信し、自動的に別のリクエストを即座に送信します。

デフォルトは45秒で、有効な範囲は20 - 900秒です。

トンネリング・クライアント・タイムアウト

クライアントがサーバーに対して(レスポンスに対する)リクエストを最後に送信してから、この属性で設定された秒数が経過した場合、サーバーはクライアントを応答なしと見なしてHTTPトンネル接続を終了します。サーバーはこの属性によって指定された間隔で経過時間をチェックし、それまでにクライアントからリクエストがあればそれにレスポンスします。

デフォルトは40秒で、有効な範囲は10 - 900秒です。

クライアントからのWebLogic Serverへの接続

クライアントがWebLogic Serverへの接続をリクエストする場合、HTTPトンネリングを使用するために必要なことはURLにHTTPプロトコルを指定することだけです。例:

Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);

クライアント側では、特殊なタグがhttpプロトコルに付加されます。このためWebLogic Serverは、これが通常のHTTPリクエストではなくトンネリング接続であることを認識します。この処理では、アプリケーション・コードを変更する必要はありません。

クライアントは、ポートが80の場合でもURLにポートを指定しなければなりません。WebLogic ServerインスタンスはHTTPリクエストを任意のポートでリスニングするように設定できますが、ファイアウォールを介したポート80へのリクエストは許可されるのが通例であるため、ポート80を使用するのが最も一般的です。

WebLogic Server用のリスニング・ポートは、の「サーバー」ノードの「ネットワーク」タブで指定します。

ネイティブI/Oを使用した静的ファイルの提供(Windowsのみ)

WebLogic ServerをWindows NT/2000/XPで実行している場合は、HTMLファイル、テキスト・ファイル、画像ファイルなどの静的ファイルを提供する際に、Javaメソッドではなくネイティブ・オペレーティング・システム・コールTransmitFileを使用するように指定できます。ネイティブI/Oを使用することで、サイズの大きい静的ファイルを提供する際のパフォーマンスが向上します。

ネイティブI/Oを使用するには、ネイティブI/Oを使用して提供するファイルを含むWebアプリケーションのweb.xmlデプロイメント記述子に2つのパラメータを追加します。1つめのパラメータはweblogic.http.nativeIOEnabledです。これをTRUEに設定することで、ネイティブI/Oによるファイル提供が有効になります。2つめのパラメータは、weblogic.http.minimumNativeFileSizeです。このパラメータには、ネイティブI/Oを使用する際の最小ファイル・サイズを指定します。提供するファイルのサイズがこの値より大きいと、ネイティブI/Oが使用されます。このパラメータを指定しない場合のデフォルト値は4Kです。

ネイティブI/Oを使用すると、通常であれば大きなファイルを提供する際のパフォーマンスが向上しますが、WebLogic Serverを実行しているマシンへの負荷が増大するため、パフォーマンスがそれほど向上しない場合もあります。weblogic.http.minimumNativeFileSizeの値を調節して、適切な値を見つける必要があります。

web.xmlデプロイメント記述子に追加する必要のあるすべてのエントリの例を示します。これらのエントリは、web.xmlファイルの<distributable>要素の後、<servlet>要素の前に追加する必要があります。

<context-param>
<param-name>weblogic.http.nativeIOEnabled</param-name>
<param-value>TRUE</param-value>
</context-param>
<context-param>
<param-name>weblogic.http.minimumNativeFileSize</param-name>
<param-value>500</param-value>
</context-param>

weblogic.http.nativeIOEnabledも、FileServletのコンテキスト・パラメータとして設定できます。

6 Oracle Virtual Assembly Builder用プラグインの使用

この章では、単一のWebLogicドメインを調べる、Oracle Virtual Assembly Builder用のWebLogic Serverイントロスペクション・プラグインについて説明します。指定されたドメインおよびOracleホームが取得されます。

注意:

この章では、WebLogic Serverのインストール・プログラムに含まれているWebLogic Serverプラグインについて説明します。このプラグインの旧バージョンは、Oracle Virtual Assembly Builderのインストール・プログラムに含まれています。旧バージョンのプラグインの使用方法については、Oracle Virtual Assembly Builderリリース・ノートを参照してください。

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

- 概要

- イントロスペクション・プラグインのパラメータ

- 参照システムの前提条件

- プラグイン使用の要件

- 作成されるアーティファクト・タイプ

- ワイヤリング

- ワイヤリング・プロパティ

- WebLogic Serverアプライアンスのプロパティ

- Oracle Coherence*Webイントロスペクション拡張

- サポートされるテンプレート・タイプ

概要

次の項では、Oracle Virtual Assembly BuilderおよびWebLogic Serverイントロスペクション・プラグインの概要を説明します。

- Oracle Virtual Assembly Builderについて

- WebLogic Serverイントロスペクション・プラグインについて

Oracle Virtual Assembly Builderについて

Oracle Virtual Assembly Builderは、インストールされたOracleコンポーネントを仮想化して変更した後、各自の環境にデプロイするためのツールです。Oracle Virtual Assembly Builderを使用して、ソフトウェア・アプライアンスと呼ばれるアーティファクト内の既存のソフトウェア・コンポーネントの構成を取得します。アプライアンスをグループ化して、その関係をソフトウェア・アセンブリと呼ばれるアーティファクトに定義できます。アセンブリは、完全な複数層アプリケーション・トポロジを記述するブループリントを提供します。

Oracle Virtual Assembly Builderでは、アセンブリ内のアプライアンス間の論理接続を、アセンブリ編集と呼ばれるプロセスで再構成できます。目的のアセンブリ構成を実現した後は、Oracle Virtual Assembly Builderを使用してデプロイメント用のアセンブリを準備し、それをご使用の環境にデプロイします。

詳細は、『Oracle Virtual Assembly Builderの使用』を参照してください。

WebLogic Serverイントロスペクション・プラグインについて

イントロスペクションとは、アプライアンスまたはアセンブリを作成するために、ソフトウェア・コンポーネントまたは関連コンポーネントのグループに対して実行される操作です。イントロスペクション時には、Oracle Virtual Assembly BuilderでコンポーネントのXML記述が作成された後、コンポーネント固有の構成ファイルのセットが取得されます。この情報が、イントロスペクション時におけるコンポーネントの構成のスナップショットを形成します。

イントロスペクション・アーキテクチャは、プラグイン・ベースです。WebLogic Server用プラグインを含め、サポートされるコンポーネント・タイプごとにプラグインがあります。通常、コンポーネントのイントロスペクションを行うと、アプライアンスが作成されます。ただし、Oracle Virtual Assembly Builderを使用してWebLogic Serverドメインをイントロスペクトすると、イントロスペクション・プラグインはアセンブリを生成します。生成されるアセンブリには、次のものが含まれます。

- 管理サーバーを表すアプライアンス。

- スタンドアロン管理対象サーバーごとに1つのアプライアンス。

- クラスタごとに1つのアプライアンス。(このアプライアンスには、そのクラスタに含まれるすべての管理対象サーバー・インスタンスが含まれます。)

WebLogic Serverイントロスペクション・プラグインは、動的クラスタおよび動的サーバーで構成されるWebLogicドメインを完全にサポートします。

WebLogic Serverイントロスペクション・プラグインの設定

次の手順は、Oracle Virtual Assembly BuilderでWebLogic Serverイントロスペクション・プラグインを使用可能にするためのプロセスの概要です。

1. 『Oracle Fusion Middlewareのインストールのプランニング』の説明に従って、Oracle Fusion Middlewareインフラストラクチャ・ソフトウェア(wls_jrf_generic.jar)をインストールします。

インストール・タイプとして、Fusion Middlewareインフラストラクチャを選択します。

2. 『Oracle Virtual Assembly Builderのインストール』の説明に従って、Oracle Virtual Assembly Builderをインストールします。

3. 次のコマンドで、Oracle Virtual Assembly Builder用のWebLogic Serverプラグインをインストールします。

$AB_INSTANCE/bin/abctl installPlugins -productRoot $ORACLE_HOME/wlserver

このコマンドの$AB_INSTANCEは、Studioインスタンスのホーム・ディレクトリに設定されている環境変数です。

イントロスペクション・プラグインのパラメータ

表6-1は、Oracle Virtual Assembly Builder用のWebLogic Serverプラグインのイントロスペクション・パラメータを示しています。使用できる具体的なパラメータ・セットは、abctlコマンドを使用しているか、Oracle Virtual Assembly Builder Studioを使用しているかによって異なります。「コマンド行サポート」列は、対応するパラメータをabctlコマンドで指定できるかどうかを示しています。「必須」列は、プラグインでパラメータを指定する必要があるかどうかを示しています。

表6-1 WebLogic Serverプラグインのイントロスペクション・パラメータ

パラメータ

説明

コマンド行サポート

必須

domainRoot

イントロスペクトするドメインへの完全修飾パス。configディレクトリを含むディレクトリである必要があります。

はい

はい

wlsHome

WebLogicホーム・ディレクトリへの完全修飾パス。たとえば、/u01/Oracle/Middleware/Oracle_Home/wlserverです。

はい

はい

adminUser

WebLogicドメインの管理ユーザー。

はい

はい

adminPassword

adminUserパラメータに対応する管理ユーザーのパスワード。

いいえ

はい

nodeManagerUser

ノード・マネージャ・ユーザー名。イントロスペクション時にこのパラメータを指定すると、指定されたユーザー名がドメインのリハイドレート時に使用されます。abctlコマンドでこのオプションを指定すると、nodeManagerPasswordが自動的に要求され、それがデハイドレーション時に使用されます。

このパラメータを指定しないと、adminUserパラメータの値がノード・マネージャ・ユーザーとしてデフォルトで使用されます。

はい

いいえ

nodeManagerPassword

nodeManagerUserパラメータで指定されたユーザーのパスワード。

いいえ

はい[1]

nodeManagerDir

ノード・マネージャ構成を含むデフォルト以外のディレクトリ。このパラメータを指定しないと、デフォルトで次の値が使用されます。

$WL_HOME/common/nodemanager

はい

いいえ

identityKeystorePassPhrase

カスタム・アイデンティティ・キー・ストアの使用がドメインで構成されている場合に使用するアイデンティティ・キーストアのパスワード。

いいえ

いいえ

privateKeyPassPhrase

カスタム・アイデンティティ・キーストアに含まれるプライベート・キーのパスワード。

いいえ

いいえ

参照システムの前提条件

ドメインの管理サーバーが実行中であり、イントロスペクションのターゲットが管理サーバーのホスト・マシンである必要があります。

プラグイン使用の要件

表6-2は、イントロスペクション・プラグインの使用に関する要件とその説明を示しています。この表に示されている要件は、WebLogic Serverプラグインに関するものと、Oracle Virtual Assembly Builder全体に関するものがあります。詳細は、『Oracle Virtual Assembly Builderのインストール』を参照してください。

表6-2 イントロスペクション・プラグインの使用に関する要件

要件

説明

編集可能なドメイン

イントロスペクションの対象であるWebLogicドメインが、編集できるように構成されている必要があります。これによって、デプロイ時の編集が正しく行われます。詳細は、『Oracle WebLogic Serverドメイン構成の理解』を参照してください。

Oracle Internet Directory

参照システムでは、LDAPアイデンティティ・ストアとして、ファイルベースのLDAPサーバーではなく、Oracle Internet Directoryを使用することをお薦めします。ファイルベースLDAPは、同期の問題が原因で、デプロイされたシステムで正しく動作しません。

リモート・ユーザー

WebLogic Serverのリモート・イントロスペクション用に指定するリモート・ユーザーは、WebLogic Serverプロセスの所有ユーザーが作成したファイルにアクセスできる必要があります。可能な場合は、指定するリモート・ユーザーを、WebLogic Serverプロセスの所有ユーザーと同じにすることをお薦めします。

Webサービスにアクセスするアプリケーション

WebLogic Server参照システムでホストされるWebサービスにアクセスするアプリケーションごとに、次の操作を行う必要があります。

1. 新しいOracle VMホスト上のWebサービスWSDLにアクセスするように、アプリケーションを更新します。

2. 『Oracle WebLogic Serverの理解』のシステム管理ツールおよびAPIのまとめに関する項にリストされている管理ツールのいずれかを使用してアプリケーションをOracle VM WebLogic Server環境に再デプロイします。

個々のサーバーでテンプレートを作成しない

WebLogic Server内の個々のサーバーでテンプレートを作成しないでください。このようなテンプレートは、特定のデプロイメント・アーティファクト(ドメイン・テンプレートのjarファイル、アセンブリ・レベルのデータ)がないため、デプロイできません。

管理サーバーURL

ゲストOSのコンテキストから手動で起動するには、StartManagedServerスクリプトを手動で変更して、適切な管理サーバーURL(管理サーバーのホスト名)を指定する必要があります。これは、デフォルトの管理サーバーURLに正しい値を指定するために必要です(テンプレートの作成時には、管理サーバーのマシン名は不明です)。

作成されるアーティファクト・タイプ

管理サーバーのアプライアンスと、検出されたクラスタのアプライアンスおよび検出されたスタンドアロン(クラスタ化されていない)管理対象サーバーのアプライアンスが含まれる、原始性アセンブリ。クラスタ内の管理対象サーバーの数にかかわらず、1つのクラスタに対して1つのアプライアンスが作成されます。WebLogic Serverプラグインでは、クラスタ内のすべての管理対象サーバーが同様に構成されていると想定しています。クラスタ内の管理対象サーバーの名前と数は、アプライアンス・メタデータにスケール・アウト情報として保存されます。

注意:

原始性アセンブリを編集して、アプライアンスを追加したり削除することはできません。他のアプライアンスをWebLogic Server原始性アセンブリに関連付けるには、非原始性アセンブリを作成し、WebLogic Serverアセンブリをその非原始性アセンブリに追加する必要があります。

ワイヤリング

ドメイン内のサーバーがリスニングしているすべてのチャネルについて、WebLogic Serverアセンブリで入力が作成されます。通常、Oracle HTTP Server出力はWebLogic Server入力に接続されます。

見つかった次のタイプの構成について、WebLogic Serverアセンブリで出力が作成されます。

- JDBC

- LDAP

- JMSメッセージング・ブリッジ

- 外部JMS

これらの出力はすべて、デプロイメントの前に外部リソースまたはアプライアンスに接続する必要があります。出力および出力でサポートされるプロトコルの記述から、出力の接続先となり得るアプライアンス・タイプに関するヒントが与えられます。

ワイヤリング・プロパティ

すべての入力エンドポイントは、次のワイヤリング・プロパティを持ちます。

- 2つの編集可能なプロパティ: port、description。

- 1つの編集不可のプロパティ: protocolsのリスト。protocolsは、入力に接続できる出力のタイプを示します。

すべての出力エンドポイントは、次のワイヤリング・プロパティを持ちます。

- 1つの編集可能なプロパティ: description。

- 編集不可の次のプロパティ。

- protocol: 出力に接続できる入力のタイプを示します。

- singleton: 出力を接続できるアプライアンスのタイプを示します。singletonがtrueの場合、出力を接続できるのは、スケーラビリティ絶対最大値が1のアプライアンスの入力のみです。

表6-3は、WebLogic Serverアプライアンスの共通入力ユーザー・プロパティを示しています。

表6-3 WebLogic Serverアプライアンスの共通入力ユーザー・プロパティ

名前

型

必須

デフォルト

説明

keepLocalHost

Boolean

いいえ

なし

この入力が元はローカルホストに明示的にバインドされていた場合、このプロパティは存在し、trueに設定されます。このプロパティが存在し、その値がfalseにオーバーライドされていない場合、この入力への接続は作成しないでください。

readymetric-naming-password

String

いいえ

なし

準備完了メトリック・チェックを実行する際に、サーバーへの接続で使用するパスワード。

readymetric-naming-protocol

String

いいえ

なし

準備完了メトリック・チェックに使用される接続の名前付けで指定できるオプションのプロトコル(例: iiop)。

readymetric-naming-user

String

いいえ

なし

準備完了メトリック・チェックを実行する際に、サーバーへの接続で使用するユーザー(例: weblogic)。

readymetric-server-protocol

String

いいえ

なし

準備完了メトリック・チェックを実行する際に、サーバーへの接続で使用するプロトコル(例: iiop)。

表6-4は、WebLogic Serverアプライアンスの共通入力プロパティを示しています。ユーザーは、これらのプロパティを変更できません。

表6-4 WebLogic Serverアプライアンスの共通入力プロパティ

名前

型

必須

デフォルト

説明

originalBindAddresses

String

いいえ

なし

イントロスペクトされたシステムの元のアドレス。

originalDefaultHostname

String

いいえ

なし

イントロスペクトされたシステムの元のホスト名。(例: example.com)。

表6-5は、管理サーバー・アプライアンスの入力システム・プロパティを示しています。

表6-5 管理サーバー・アプライアンスの入力プロパティ

名前

型

必須

デフォルト

説明

admin-password

String

はい

なし

管理ユーザーのパスワード。これはユーザーが変更できるプロパティで、デプロイメント・プランに指定されます。デプロイヤはこれを使用して既知のドメインのイントロスペクションとデプロイメントを何度でも実行できます。デプロイされる各インスタンスは、カスタム・パスワードを持ちます。

admin-username

String

はい

なし

管理サーバーに接続するための管理ユーザー名(例: weblogic)。

表6-6から表6-9は、管理サーバー・アプライアンスのJDBC、外部JMS、JMSメッセージング・ブリッジおよびLDAP用の出力ユーザー・プロパティを示しています。

表6-6は、管理サーバー・アプライアンスのJDBC用の出力ユーザー・プロパティおよびシステム・プロパティを示しています。passwordプロパティおよびusernameプロパティがユーザー・プロパティで、original-urlがシステム・プロパティです。

表6-6 管理サーバー・アプライアンスの出力プロパティ: JDBC

名前

型

必須

デフォルト

説明

password

String

いいえ

<空>

データ・ソース接続で必要なユーザーのパスワード。

username

String

いいえ

なし

データ・ソース接続で必要なユーザー。値は、データ・ソース接続の元のユーザーになります。

original-url

String

いいえ

なし

イントロスペクトされたWebLogicドメインからの元のJDBC URL。たとえば、jdbc:oracle:thin:@adc2100927.example.com:1521:orclです。

表6-7は、管理サーバー・アプライアンスの外部JMS用の出力ユーザー・プロパティを示しています。

表6-7 管理サーバー・アプライアンスの出力プロパティ: 外部JMS

名前

型

必須

デフォルト

説明

original-connection-url

String

いいえ

なし

外部JMSサーバーの元のURL。

表6-8は、管理サーバー・アプライアンスのJMSメッセージング・ブリッジ用の出力システム・プロパティを示しています。

表6-8 管理サーバー・アプライアンスの出力プロパティ: JMSメッセージング・ブリッジ

名前

型

必須

デフォルト

説明

original-url

String

いいえ

なし

JMSメッセージング・ブリッジ・サーバーの元のURL。

original-username

String

いいえ

なし

JMSメッセージング・ブリッジ・サーバーの元のユーザー名。

original-password

String

いいえ

なし

暗号化された、JMSメッセージング・ブリッジ・サーバーの元のパスワード。

表6-9は、管理サーバー・アプライアンスのLDAP用の出力システム・プロパティを示しています。

表6-9 管理サーバー・アプライアンスの出力プロパティ: LDAP

名前

型

必須

デフォルト

説明

original-name

String

いいえ

なし

LDAPセキュリティ・プロバイダの元の名前。

original-host

String

いいえ

なし

LDAPセキュリティ・プロバイダの元のホスト。

original-port

String

いいえ

なし

LDAPセキュリティ・プロバイダの元のポート。

original-user

String

いいえ

なし

LDAPセキュリティ・プロバイダの元のユーザー。

WebLogic Serverアプライアンスのプロパティ

この項では、WebLogic Serverアプライアンスを含むアセンブリの次のプロパティについて説明します。これらのプロパティには、アセンブリレベルのプロパティ、各アプリケーションの入力および出力に関するプロパティ、およびアプライアンス自体のプロパティが含まれます。この項の内容は次のとおりです。

- アセンブリレベルのシステム・プロパティ

- 管理サーバーおよび管理対象サーバーのアプライアンスに共通するプロパティ

- 管理サーバー・アプライアンスのプロパティ

アセンブリレベルのシステム・プロパティ

表6-10は、アセンブリレベルのシステム・プロパティを示しています。

表6-10 アセンブリレベルのシステム・プロパティ

名前

型

必須

デフォルト

説明

admin-password

String

はい

なし

ドメインの管理ユーザー・パスワード。

admin-username

String

はい

なし

ドメインの管理ユーザー(例: weblogic)。

admsvr-jmx-input

String

はい

なし

JMX接続で使用する管理サーバー・アプライアンスの入力を示します(例: Default)。

admsvr-jmx-protocol

String

はい

なし

管理サーバーへのJMX接続で使用するプロトコル(例: iiop)。

domain-name

String

いいえ

なし

イントロスペクトされたドメインのドメイン名(例: test_domain)。

usesOracleHomes

boolean

はい

なし

これがコアのWebLogic Serverインストールではなく、Oracleホームが関連付けられていることを示します。SOAおよびWebCenterドメインの場合、これはtrueです。指定可能な値はtrueおよびfalseです。

管理サーバーおよび管理対象サーバーのアプライアンスに共通するプロパティ

ここでは、管理サーバーおよび管理対象サーバーのアプライアンスに共通するプロパティについて説明します。

表6-11は、WebLogic Serverアプライアンスの共通ユーザー・プロパティを示しています。

表6-11 WebLogic Serverアプライアンスの共通ユーザー・プロパティ

名前

型

必須

デフォルト

説明

NodeManagerPort

Integer

はい

5556

ノード・マネージャがリスニングするポート(例: 5556)。これは、参照システムで構成されているノード・マネージャが検出された場合のみ存在します。

readymetric-attribute-compare-type

String

いいえ

EQUALS

準備完了メトリックの属性値とプロパティreadymetric-attribute-valueに指定された値との間で行われる比較。

有効な値は、EQUALS、LESSER_THAN、GREATER_THAN、LESSER_THAN_OR_EQUALおよびGREATER_THAN_OR_EQUALです。

readymetric-attribute-name

String

いいえ

State

チェックするMBean属性。

readymetric-attribute-type

String

いいえ

STRING

MBean属性の型。

有効な値(ただし、調べられる属性に適した値)は、STRING、INTEGER、SHORT、LONG、DOUBLE、FLOATおよびBOOLEANです。

readymetric-attribute-value

String

いいえ

RUNNING

チェックが成功と見なされるために、プロパティreadymetric-attribute-nameが保持する必要がある値。

readymetric-instance-name-0

String

いいえ

com.bea:Name=AdminServer,Type=ServerRuntime

JMX準備完了メトリック・チェックで使用するインスタンス名。

readymetric-max-wait-period

String

いいえ

600

準備完了メトリック・チェックの成功を待機する最大時間(秒)。

readymetric-naming-input

String

いいえ

なし

準備完了メトリック・チェックで使用する入力(例: Default)。

readymetric-polling-period

String

いいえ

なし

準備完了メトリック・チェックの接続試行間の間隔(秒)。

readymetric-server-input

String

いいえ

なし

準備完了メトリック・チェックで使用する入力(例: Default)。

readymetric-trust-store-0

String

いいえ

なし

準備完了メトリック・チェックがSSL対応ポートを使用している場合、使用するトラスト・ストアの場所。

readymetric-type

String

いいえ

JMX

アプライアンスで使用する準備完了メトリックのタイプ。

readymetric-verify

String

いいえ

はい

このプロパティがtrueに設定されている場合、準備完了メトリック・チェックが実行されます。それ以外の場合は省略されます。

useTemplate

String

いいえ

OEL

アプライアンスのテンプレートの作成時にデフォルトで使用するテンプレート・タイプを指定します。

管理サーバー・アプライアンスのプロパティ

表6-12は、管理サーバー・アプライアンスのシステム・プロパティを示しています。

表6-12 管理サーバー・アプライアンスのシステム・プロパティ

名前

型

必須

デフォルト

説明

admin-input-name

String

いいえ

なし

管理サーバーのadmin-input-protocolへの接続で使用する入力(例: Default)。

admin-input-protocol

String

いいえ

なし

管理サーバーへの接続で使用するプロトコル(例: http)。

表6-13は、管理サーバー・アプライアンスのユーザー・プロパティを示しています。

表6-13 管理サーバー・アプライアンスのユーザー・プロパティ

名前

型

必須

デフォルト

説明

<cluster name>-cluster-address

String

いいえ

<空>

プロパティ名の最初の部分で指定されているクラスタのクラスタ・アドレス。

<cluster name>-frontend-host

String

いいえ

<空>

プロパティ名の最初の部分で指定されているクラスタのフロントエンド・ホスト。

<cluster name>-frontend-http-port

String

いいえ

<空>

プロパティ名の最初の部分で指定されているクラスタのセキュアでないフロントエンド・ポート。

<cluster name>-frontend-https-port

String

いいえ

<空>

プロパティ名の最初の部分で指定されているクラスタのセキュアなフロントエンド・ポート。

Oracle Coherence*Webイントロスペクション拡張

Oracle Coherence*Webイントロスペクション拡張は、WebLogic Serverイントロスペクタの機能を拡張します。また、WebLogicドメインの一部として構成されたCoherenceキャッシュ・クラスタおよびサーバーの構成を調べます。詳細は、Oracle Coherenceのドキュメントを参照してください。

サポートされるテンプレート・タイプ

サポートされるテンプレート・タイプは、Oracle Enterprise Linux (OEL)です。

[1]
ノード・マネージャのユーザー名を指定した場合にのみ必要となります。

7 同時管理対象オブジェクトの構成

この章では、Concurrency Utilities for Java EE 1.0 (JSR 236)の定義および実装をサポートする目的でWebLogic Serverが実装する同時管理対象オブジェクト(CMO)について説明します。

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

- Java EE Concurrency Utilitiesについて

- 同時管理対象オブジェクトによるWebLogic Serverコンテナへの同時実行性の装備

- デフォルトのJava EE CMO

- 構成ファイル内のカスタマイズ済CMO

- グローバルCMOテンプレート

- 同時制約の構成

- CMOの問合せ

Java EE Concurrency Utilitiesについて

Concurrency Utilities for Java EE 1.0 (JSR 236)は、サーブレットやEJBなどのJava EEアプリケーション・コンポーネントに非同期実行機能を提供する標準APIを実装しています。

Java EE 7のチュートリアルで説明するように、同時実行の2つの主要概念はプロセスとスレッドになります。

- プロセスは、主にオペレーティング・システム(OS)で実行するアプリケーションに関連付けられます。プロセスには、JVMプロセスと同様に、基本のOSと連携して他のリソース(独自のメモリーなど)を割り当てる固有のランタイム・リソースがあります。JVMは、実際はプロセスになります。

- スレッドは一部の機能をプロセスと共有します。これは、どちらもOSまたは実行環境のリソースを消費するためです。ただし、スレッドの方がプロセスよりも作成しやすく、消費するリソースはかなり少なくなります。

同時実行性ユーティリティのプライマリ・コンポーネントは次のとおりです。

- ManagedExecutorService (MES): 発行されたタスクを非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ManagedScheduledExecutorService (MSES): 発行されたタスクを特定の時点で非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ManagedThreadFactory (MTF): 管理対象スレッドを作成するためにアプリケーションによって使用されます。スレッドは、コンテナによって開始および管理されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

- ContextService: コンテナのコンテキストを取得する動的プロキシ・オブジェクトを作成して、アプリケーションがそのコンテキスト内で後で実行されるようにするか、管理対象エグゼキュータ・サービスに発行されるようにするために使用されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。

詳細は、Java EE 7チュートリアルのConcurrency Utilities for Java EEに関する項を参照してください。「Java Specification Request 236: Concurrency Utilities for Java EE 1.0」(http://jcp.org/en/jsr/detail?id=236)も参照してください。

WebLogic ServerでのConcurrency 1.0のコード・サンプル

サンプルを備えたWebLogic Server一式をインストールする場合、サンプル・ソース・コードは、EXAMPLES_HOME\examples\src\examplesディレクトリに配置されます。デフォルト・パスはORACLE_HOME\wlserver\samples\serverです。このディレクトリから、サンプル・ドメインを設定せずに、Concurrency 1.0サンプルのソース・コードと手順ファイルにアクセスできます。

ORACLE_HOME\user_projects\domains\wl_serverディレクトリには、WebLogic Serverのサンプル・ドメインが含まれています。このドメインには、アプリケーション、アプリケーションおよびOracle WebLogic Serverの動作を定義するXML構成ファイル、および起動スクリプトと環境スクリプトが含まれます。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

- Concurrency ContextServiceの使用 - ContextServiceインタフェースを使用して動的プロキシ・オブジェクトを作成する方法を示します。

EXAMPLES_HOME/wl_server/examples/src/examples/javaee7/concurrency/dynamicproxy

- Concurrency Executorの使用 - タスク発行用のjavax.enterprise.concurrent.ManagedExecutorServiceの使用方法を示します。

EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/executor

- Concurrency Scheduleの使用 - 遅延タスクまたは定期タスク発行用のjavax.enterprise.concurrent.ManagedScheduledExecutorServiceの使用方法を示します。

EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/schedule

- Concurrency Threadsの使用: javax.enterprise.concurrent.ManagedThreadFactoryを使用して、Java EEコンテナからスレッドを取得する方法を示します。

EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/threads

同時実行を使用する独自のアプリケーションをプログラミングする前に、これらのサンプルを実行することをお薦めします。

同時管理対象オブジェクトによるWebLogic Serverコンテナへの同時実行性の装備

この項では、Concurrency UtilitiesのAPIをワーク・マネージャと関連付けてスレッドをコンテナ管理にすることで、WebLogic ServerがJava EEアプリケーションに同時機能を提供する方法について説明します。

- WebLogic Serverによるアプリケーション・コンポーネントの非同期タスクの処理

- 同時管理対象オブジェクト(CMO)

- CMOとCommonJ API

- CMOコンテキストの伝播

- CMOタスクの自己チューニング

- CMOが停止する場合のスレッドの中断

- 長時間実行スレッドに対するCMOの制約

WebLogic Serverによるアプリケーション・コンポーネントの非同期タスクの処理

JSR236 Concurrent Utilitiesを使用する場合、WebLogic Serverでは、サーバー・アプリケーション・コンポーネントの非同期タスクを認識し、次の方法で管理できます。

- 適切な実行コンテキストの提供。「CMOコンテキストの伝播」を参照してください。

- 単一のサーバー側自己チューニング・スレッド・プールにタスクを発行し、定義済ルールおよび実行時メトリックに基づき、それらの優先順位を決定。「CMOタスクの自己チューニング」を参照してください。

- タスクを作成したコンポーネントの停止時にタスクが実行されるスレッドを中断。「CMOが停止する場合のスレッドの中断」を参照してください。

- タスクが自己チューニング・スレッド・プールへのディスパッチに適していない場合、管理対象オブジェクトで作成される新しい実行スレッドの数を制限。「長時間実行スレッドに対するCMOの制約」を参照してください。

同時管理対象オブジェクト(CMO)

WebLogic Serverでは、非同期タスク管理は、4種類の同時管理対象オブジェクト(CMO)によって行われます。

表7-1に、非同期タスク管理を行うCMOの概要を示します。

表7-1 非同期タスク管理を行うCMO

管理対象オブジェクト

コンテキストの伝播

自己チューニング

停止時のスレッド中断

同時長時間実行新規スレッドの制限

管理対象エグゼキュータ・サービス(MES)

コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。

短時間実行タスクのみが、指定されたワーク・マネージャによって単一の自己チューニング・スレッド・プールにディスパッチされます。「CMOタスクの自己チューニング」を参照してください。

ワーク・マネージャの停止中に、すべての未完了タスクが取り消されます。「CMOが停止する場合のスレッドの中断」を参照してください。

過剰な数のスレッドによってサーバーが悪影響を受けないように、MESやMSESによって作成される長時間実行スレッドの最大数を構成できます。「長時間実行スレッドに対するCMOの制約」を参照してください。

管理対象スケジュール済エグゼキュータ・サービス(MSES)

コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。

MESと同じ動作。「CMOタスクの自己チューニング」を参照してください。

MESと同じ動作。「CMOが停止する場合のスレッドの中断」を参照してください。

MESと同じ動作。「長時間実行スレッドに対するCMOの制約」を参照してください。

コンテキスト・サービス

コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。

該当なし

該当なし

該当なし

管理対象スレッド・ファクトリ(MTF)

コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。

newThread()メソッドによって戻されるスレッドは、単一の自己チューニング・スレッド・プールからのスレッドではなく、タスクの完了時にこのスレッド・プールに入れられることはありません。「CMOタスクの自己チューニング」を参照してください。

newThread()メソッドによって作成されたスレッドは、MTFの停止時に中断されます。「CMOが停止する場合のスレッドの中断」を参照してください。

過剰な数のスレッドによってサーバーが悪影響を受けないように、MTFによって作成される新規スレッドの最大数を構成できます。「長時間実行スレッドに対するCMOの制約」を参照してください。

WebLogic Serverには3つのタイプのJSR236 CMOがあり、各CMOは、そのスコープ、およびその定義方法や使用方法で特徴付けられます。

- デフォルトJava EE CMO - アプリケーションがデフォルト・リソースを利用できるようにJava EE標準で必要となり、これらのデフォルト・リソースに固有のJNDI名を定義します。

- 構成ファイル内のカスタマイズ済CMO - アプリケーションおよびモジュール・レベルで定義するか、JNDIにバインドされたアプリケーション・コンポーネント環境(ENC)から参照できます。

- グローバルCMOテンプレート - WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でテンプレートとしてグローバルに定義できます。

グローバルCMOテンプレートは、ワーク・マネージャと同様に、WebLogic Server管理コンソールまたは構成MBeanを使用して、ドメイン・レベルまたはサーバー・レベルで定義できます。詳細は、「管理コンソールを使用したCMOテンプレートの構成」および「MBeanを使用したCMOテンプレートの構成」を参照してください。

CMOとCommonJ API

WebLogic ServerのCommonJ API (commonj.work)は、アプリケーションがコンテナ内で複数の作業項目を同時に実行できるようにするインタフェースのセットを提供します。CMOとCommonJ APIは同じレベルで機能します。つまり、どちらもタスクをワーク・マネージャにディスパッチして、アプリケーション内の作業をプログラムで処理します。ただし、CMOとCommonJ APIには、次のような明らかな違いがあります。

- CommonJ APIはWeblogicに固有であり、CMOは標準化されています。

- CommonJ APIには、CMO管理対象エグゼキュータ・サービス、管理対象スケジュール済エグゼキュータ・サービスのような機能がありますが、管理対象スレッド・ファクトリやコンテキスト・サービスのようなCMO機能はありません。

CommonJ APIの使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server CommonJアプリケーションの開発』のタイマーおよびワーク・マネージャAPIの使用に関する項を参照してください。

CMOコンテキストの伝播

この項では、CMOについて伝播される4つのコンテキスト・タイプと、MESおよびMSES管理対象オブジェクトに関するWebLogic Serverでのコンテキスト呼出しポイントについて説明します。

伝播されるコンテキスト・タイプ

表7-2に、4種類の管理対象オブジェクトについて伝播されるコンテキスト・タイプの概要を示します。

表7-2 伝播されるコンテキスト・タイプ

コンテキスト・タイプ

説明

実行されるコンテキスト・タスク

JNDI

JNDIネームスペース

MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのアプリケーション・スコープ指定JNDIツリー(java:app、java:module、java:compなど)にアクセスできます。

MTFの場合、タスクは、ManagedThreadFactoryインスタンスを作成したコンポーネントのアプリケーション・スコープ指定JNDIツリーにアクセスできます。

ClassLoader

コンテキスト・クラス・ローダー

MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのコンテキスト・クラス・ローダーで実行します。

MTFの場合、タスクは、ManagedThreadFactoryインスタンスを作成したコンポーネントのクラス・ローダーで実行します

セキュリティ

サブジェクト・アイデンティティ

MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのサブジェクト・アイデンティティで実行します。MTFの場合、匿名のサブジェクトで実行します。

ワークエリア

PropagationModeのWORKによるWorkAreaコンテキスト

MES、MSESおよびContext Serviceの場合、新しいWorkAreaコンテキスト・タイプがあるため、すべてのタスクはWorkContextMapで実行します。この中には、WORKモードによる発行スレッドのコンテキストがすべて含まれます。

MTFの場合、すべてのタスクは空のWorkContextMapで実行します。

注意: WorkContextMapは新しいインスタンスですが、含まれる値は新しいものではないため、値の内容を更新すると、発行スレッドの内容に影響を与える場合があります。

コンテキスト呼出しポイント

表7-3に、WebLogic Serverでのコンテキスト呼出しポイントのコールバック・メソッドと、MESおよびMSES管理対象オブジェクトの場合にコンテキスト呼出しポイントが実行するコンテキストの概要を示します。

表7-3 コンテキスト呼出しポイント

同時管理対象オブジェクト

コンテキスト呼出しポイント

コンテキスト呼出しポイントが実行するコンテキスト

ManagedExecutorService

コールバック・メソッド: javax.enterprise.concurrent.ManagedTaskListener

コンテキスト呼出しポイントは、submit()、invokeAll()およびinvokeAny()メソッドをコールしたアプリケーション・コンポーネント・インスタンスのコンテキストで実行します。

ManagedScheduledExecutorService

コールバック・メソッド: javax.enterprise.concurrent.ManagedTaskListenerおよびjavax.enterprise.concurrent.Trigger

submit()、invokeAll()、invokeAny()、schedule()、scheduleAtFixedRate()、scheduleWithFixedDelay()メソッドをコールしたアプリケーション・コンポーネント・インスタンス。

CMOタスクの自己チューニング

MESまたはMSESに発行される短時間実行タスクは、デプロイメント・ディスクリプタで指定されるワーク・マネージャに関連付けることで、単一の自己チューニング・スレッド・プールにディスパッチされます。

タスクの実行は、指定のワーク・マネージャに定義されているルールと一致します。MESおよびMSESの実行メソッドに発行されるタスクの場合、ワーク・マネージャの過負荷ポリシーによってタスクが拒否されると、次のイベントが発生します。

- java.util.concurrent.RejectedExecutionExceptionは、発行メソッドまたは実行メソッドでスローされます。

- weblogic.work.Workに渡される過負荷理由パラメータは、RejectedExecutionExceptionに設定されます。

- ユーザーがタスクをManagedTaskListenerに登録した場合、ユーザーはRejectedExecutionException経由で過負荷メッセージを受信できるため、このリスナーには通知されません。
注意: ManagedTaskListenerは、タスクの将来の状態を監視する場合に使用されます。詳細は、「Package javax.enterprise.concurrent」を参照してください。

MESおよびMSESのinvokeAll()メソッドおよびinvokeAny()メソッドでは、ワーク・マネージャの過負荷ポリシーで拒否される発行済タスクの場合、次のイベントが発生します。

- ユーザーが登録したManagedTaskListenerのtaskSubmitted()メソッドが呼び出されます。

- ユーザーが登録したManagedTaskListenerのtaskDone()メソッドが呼び出され、throwableParamがjavax.enterprise.concurrent.AbortedExceptionになります。

- weblogic.work.Workに渡される過負荷理由パラメータは、AbortedExceptionに設定されます。

schedule()、scheduleAtFixRate()、scheduleAtFixDelay()およびschedule(Trigger)()メソッドの場合、ワーク・マネージャの過負荷ポリシーによってタスクが拒否されると、次のイベントが発生します。

- ユーザーが登録したManagedTaskListenerのtaskDone()メソッドがコールされ、throwableParamはjavax.enterprise.concurrent.AbortedExceptionになります。

- weblogic.work.Workに渡される過負荷理由パラメータは、AbortedExceptionに設定されます。

- タスクが周期的な場合、タスクの次の実行は引き続きスケジュールされます。

CMOが停止する場合のスレッドの中断

MESまたはMSESのいずれかが停止した場合:

- 待機中のタスクは実行されません。

- 実行中のタスクはすべて中断されます。ユーザーは、Thread.isInterrupted()メソッドを確認して、そのタスクを終了する必要があります。これは、WebLogic Serverによって強制的に終了されないためです。

- Future.get()メソッドをコールする場合、エグゼキュータが返すFutureオブジェクトによって、java.util.concurrent.CancellationException()がスローされます。

- ユーザーが登録したManagedTaskListenerのtaskAborted()メソッドがコールされ、paramThrowableはCancellationException()になります。

MTFが停止した場合:

- newThread()メソッドを使用して作成されたメソッドはすべて中断されます。これらのスレッドに対してManageableThreadインタフェースでisShutdown()メソッドをコールすると、trueが返されます。

- newThread()メソッドの後続のすべてのコールで、java.lang.IllegalStateExceptionがスローされます。

ContextServiceの場合、スレッドは中断されません。ただし、次の例外があります。

- プロキシされたインタフェース・メソッドの呼出しはすべて、java.lang.IllegalStateExceptionが発生して失敗します。

長時間実行スレッドに対するCMOの制約

前述のように、MESおよびMSESに発行された長時間実行タスクと、MTFのnewThread()メソッドのコールでは、自己チューニング・スレッド・プールの一部として管理されない新しいスレッドを作成する必要があります。実行中のスレッドの数が過大になると、サーバーのパフォーマンスと安定性に悪影響を与える可能性があるため、同時実行性ユーティリティAPIによって作成される実行中のスレッドの最大数を指定する構成が用意されています。

最大同時長時間実行リクエストの制限の設定

MESおよびMSESに発行される同時長時間実行リクエストの制限は、管理対象オブジェクト・レベルとサーバー・レベルで指定できます。すべての構成レベルは独立しており、最大同時長時間実行リクエストはそれらのいずれも超えることはできません。

表7-4は、デプロイメント・ディスクリプタで定義できるmax-concurrent-long-running-requests要素を含む同時長時間実行リクエストの制限をまとめたものです。

表7-4 同時長時間実行リクエストの制限

有効範囲

デプロイメント・ディスクリプタ

説明

<max-concurrent-long-running-requests>要素の詳細

サーバー

config.xml内:

<domain><server>または<domain><server-template>のサブ要素

該当サーバーに指定される同時長時間実行リクエストの制限。

省略可能

範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます

デフォルト値: 100

管理対象オブジェクト

weblogic-application.xml、weblogic-ejb-jar.xmlまたはweblogic.xml内:

<managed-executor-service>または<managed-scheduled-executor-service>のサブ要素

config.xml内:

<managed-executor-service-template>または<managed-scheduled-executor-service-template>のサブ要素

該当のMESまたはMSESに指定される同時長時間実行リクエストの制限。

デフォルト値が10であることを除き、前述と同様です。

指定された制限を超えた場合、MESまたはMSESは、発行された新しい長時間実行タスクに対して次のアクションを実行します。

- タスク発行APIを呼び出すときにjava.util.concurrent.RejectedExecutionExceptionがスローされます。

- ユーザーがManagedTaskListenerを使用してタスクを登録している場合、発行メソッドが失敗しているためこのリスナーには通知されません。

前述の規則は、invokeAll()メソッドとinvokeAny()メソッドには適用されないことに注意してください。これらのメソッドによって発行されたすべてのタスクは、指定済の制限によって拒否され、次のイベントが発生します。

- ユーザーが登録したManagedTaskListenerのtaskSubmitted()メソッドが呼び出されます。

- ユーザーが登録したManagedTaskListenerのtaskDone()メソッドが呼び出され、throwableParamがjavax.enterprise.concurrent.AbortedExceptionになります。

- その他の発行済タスクは影響を受けません。

- メソッドは、RejectedExecutionExceptionをスローしません。

例7-1に、config.xml内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。

例7-1 config.xml内のmax-concurrent-long-running-requestsの配置例

<domain>
<server>
<name>myserver</server>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 1)
</server>
<max-concurrent-long-running-requests>10</max-concurrent-long-running-requests> (place 2)
<server-template>
<name>mytemplate</name>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 3)
</server-template>
</domain>

- place 1 - サーバー・インスタンスmyserverで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50だけ作成できます。

- place 2 – ドメインで定義されるMESおよびMSESにのみ影響します。ドメインで実行するすべてのMESおよびMSESは、長時間実行リクエストを合計で最大10作成できます。

- place 3 - テンプレートmytemplateに適用されるサーバー・インスタンスで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50だけ作成できます。

例7-2に、config.xml内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。

例7-2 max-concurrent-long-running-requestsの構成のサンプル

server1(100)
|---application1
|---managed-scheduled-executor-service1(not specified)
|---module1
|---managed-executor-service1(20)
|---managed-scheduled-executor-service2(not specified)
|---application2

次の場合は、いずれの制限も超過しておらず、前述のアクションは実行されません。

- 120の長時間実行タスクがmanaged-executor-service1に発行され、それらのうち115は完了し、5つが実行中であると仮定すると、1つの長時間実行タスクがmanaged-executor-service1に追加で発行された場合、制限は超えていないため実行されます。

次の場合は、1つの制限が超過しているため、前述のアクションが実行されます。

- 10の長時間実行タスクがmanaged-scheduled-executor-service1によって実行されていると仮定すると、1つの長時間実行タスクがmanaged-scheduled-executor-service1に追加で発行された場合、managed-scheduled-executor-service1の制限を超過します。

- 10の長時間実行タスクがapplication1によって実行され、90がapplication2によって実行されていると仮定すると、1つの長時間実行タスクがapplication1またはapplication2に追加で発行された場合、server1の制限を超過します。

最大同時新規スレッドの制限の設定

MTFのnewThread()メソッドを呼び出して作成された同時新規実行スレッドの制限は、管理対象オブジェクト、ドメインおよびサーバー・レベルで指定できます。すべての構成レベルは独立しており、同時新規実行スレッドの最大数はそれらのいずれも超えることはできません。

実行スレッドとは、MTFによって作成され、そのrun()メソッドがまだ完了していないスレッドであることに注意してください。

表7-5は、デプロイメント・ディスクリプタで定義できる要素<max-concurrent-new-threads>を含む同時新規実行スレッドの制限をまとめたものです。

表7-5 同時新規実行スレッドの制限

有効範囲

デプロイメント・ディスクリプタ

説明

<max-concurrent-long-running-requests>要素の詳細

サーバー

config.xml内:

<domain><server>または<domain><server-template>のサブ要素

該当サーバーに指定される新しい同時実行スレッドの制限。

省略可能

範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます

デフォルト値: 100

管理対象オブジェクト

weblogic-application.xml、weblogic-ejb-jar.xmlまたはweblogic.xml内:

<managed-executor-service>または<managed-scheduled-executor-service>のサブ要素

config.xml内:

<managed-executor-service-template>または<managed-scheduled-executor-service-template>のサブ要素

該当のManagedThreadFactoryに指定される新しい同時実行スレッドの制限

デフォルト値が10であることを除き、前述と同様です。

指定された制限を超えた場合、MTFのnewThread()メソッドへの呼出しでは、ThreadFactory.newThread Javadocに一致するようにnullを返します。

max-concurrent-new-threadsを使用したスニペットの例については、例7-2を参照してください。

デフォルトのJava EE CMO

Java EE標準では、アプリケーションが特定のデフォルト・リソースにアクセスできるようにすることが指定され、それらのデフォルト・リソースに固有のJNDI名が定義されます。WebLogic Serverでは、次のようにして、Java EE標準のJNDI名を特定のWebLogic Serverリソースにマップする論理JNDI名を使用することで、それらの名前を使用可能にします。

- デフォルト管理対象エグゼキュータ・サービス

- デフォルト管理対象スケジュール済エグゼキュータ・サービス

- デフォルト・コンテキスト・サービス

- デフォルト管理対象スレッド・ファクトリ

デフォルト管理対象エグゼキュータ・サービス

アプリケーションごとにデフォルトのMESインスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedExecutorServiceのデフォルトJNDI名に自動でバインドされます。

- デフォルトのワーク・マネージャをディスパッチ・ポリシーとして使用

- すべてのコンテキスト情報の伝播

- 長時間実行リクエストの制限のデフォルトは10

- 長時間実行スレッドの優先順位をデフォルトでnormalに設定

アプリケーションのデフォルトのMESを@Resourceアノテーションとともに使用することもできます。例:

package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedExecutorService  service;

デフォルトMESのオーバーライド

デフォルトMESの動作は、次の方法でオーバーライドできます。

- config.xmlでDefaultManagedExecutorServiceというエグゼキュータ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMESを作成します。

- デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムのmanaged-executor-serviceを定義します。これにより、アプリケーションのconfig.xmlでデフォルトMESの定義もオーバーライドされます。「カスタム管理対象エグゼキュータ・サービスの構成要素」を参照してください。

weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedExecutorServiceというデフォルト・エグゼキュータを定義できません。定義した場合、デプロイメントが失敗します。

デフォルト管理対象スケジュール済エグゼキュータ・サービス

デフォルトMSESインスタンスは、デフォルトMESインスタンスと似ていますが、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedScheduledExecutorServiceのデフォルトJNDI名に自動でバインドされます。デフォルト設定は同じで、すべてのコンテキスト情報が伝播されます。

アプリケーションのデフォルトのMSESを@Resourceアノテーションとともに使用することもできます。例:

package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedScheduledExecutorService  service;

デフォルトMSESのオーバーライド

デフォルトMSESの動作は、次の方法でオーバーライドできます。

- config.xmlでDefaultManagedScheduledExecutorServiceというスケジュール済エグゼキュータ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMSESを作成します。

- デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムの<managed-scheduled-executor-service>を定義します。これにより、アプリケーションのconfig.xmlでデフォルトMSESの定義もオーバーライドされます。「カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素」を参照してください。

weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedExecutorServiceというデフォルトのスケジュール済エグゼキュータを定義できません。定義した場合、デプロイメントが失敗します。

デフォルト・コンテキスト・サービス

アプリケーションごとにデフォルトのコンテキスト・サービス・インスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultContextServiceのデフォルトJNDI名に自動でバインドされ、すべてのタイプのサポート対象コンテキストが伝播されます。

デフォルト・コンテキスト・サービスは、resource-env-refまたは@Resourceアノテーションを使用して、アプリケーション・コンポーネント環境(ENC)でjava:comp/env/concurrent/csにバインドすることもできます。

デフォルト・コンテキスト・サービスの動作はオーバーライドできないことに注意してください。

例7-3に、resource-env-ref要素を使用して、webl.xmlファイルでデフォルト・コンテキスト・サービスを使用する方法を示します。

例7-3 Webアプリケーションでの<resource-env-ref>によるデフォルト・コンテキスト・サービスの使用

<!-- web.xml -->
<resource-env-ref>
<resource-env-ref-name>concurrent/cs</resource-env-ref-name>
<resource-env-ref-type>javax.enterprise.concurrent.ContextService</resource-env-ref-type>
</resource-env-ref>

例7-4に、@Resourceアノテーションを使用して、サーブレットでデフォルト・コンテキスト・サービスを使用する方法を示します。

例7-4 サーブレットでの@Resourceによるデフォルト・コンテキスト・サービスの使用

// when using @Resource, the following 2 ways are correct.
@Resource(lookup="java:comp/env/concurrent/cs")
// @Resource(name="concurrent/cs")
private ContextService service;

// when using JNDI Naming Context to lookup:
// initialContext.lookup("java:comp/env/concurrent/cs")

デフォルト管理対象スレッド・ファクトリ

アプリケーションごとにデフォルトのMTFインスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedThreadFactoryのデフォルトJNDI名に自動でバインドされます。

- 新しいスレッドに対してサポートされるすべてのタイプのコンテキストを伝播

- newThread()で作成される長時間実行スレッドのデフォルトの優先順位はnormal

- 新しい同時スレッドの実行のデフォルト制限は10

アプリケーションのデフォルトのMTFを@Resourceアノテーションとともに使用することもできます。例:

package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedThreadFactory  service;

デフォルトMTFのオーバーライド

デフォルトMTFの動作は、次の方法でオーバーライドできます。

- config.xmlでDefaultManagedThreadFactoryというスレッド・ファクトリ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMTFを作成します。

- デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムのmanaged-thread-factoryを定義します。これにより、アプリケーションのconfig.xmlでデフォルトMTFの定義もオーバーライドされます。「カスタム管理対象スレッド・ファクトリの構成要素」を参照してください。

weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedThreadFactoryというデフォルト・スレッド・ファクトリを定義できません。定義した場合、デプロイメントが失敗します。

構成ファイル内のカスタマイズ済CMO

カスタマイズ済CMOは、アプリケーションおよびモジュール・レベルで定義するか、JNDIにバインドされるアプリケーション・コンポーネント環境(ENC)から参照できます。

- WebLogic構成ファイルでのCMOの定義

- アプリケーション・コンポーネント環境でのJNDIに対するCMOのバインド

- カスタム管理対象エグゼキュータ・サービスの構成要素

- カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素

- カスタム管理対象スレッド・ファクトリの構成要素

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

注意:

現行リリースでは、カスタム・コンテキスト・サービスは構成できません。

WebLogic構成ファイルでのCMOの定義

カスタマイズ済CMOは、次のいずれかの構成ファイルで、アプリケーションおよびモジュール・レベルで定義できます。

- weblogic-application.xml - アプリケーション・レベルで指定したCMOは、そのアプリケーション、またはそのアプリケーションのコンポーネントに割り当てることができます。

- weblogic-ejb-jar.xmlまたはweblogic.xml - コンポーネント・レベルで指定したCMOは、そのコンポーネントに割り当てることができます。

アプリケーション・コンポーネント環境でのJNDIに対するCMOのバインド

エグゼキュータおよびスレッド・ファクトリCMOは、resource-env-ref要素または@Resourceアノテーションを使用して、アプリケーション・コンポーネント環境(ENC)でJNDIにバインドすることもできます。CMOを参照するresource-env-refは、web.xml、ejb-jar.xmlまたはapplication.xmlでのみ定義できます。

4つのENCネームスペース(java:comp、java:module、java:applicationおよびjava:global)は、resource-env-ref-nameおよび@Resourceに対してサポートされます。

アプリケーションAppAでエグゼキュータをjava:global JNDIネームスペースにバインドする場合、そのエグゼキュータを別のアプリケーションAppBで参照および使用できます。AppBで発行されるタスクは、AppAまたはAppBが停止すると取り消されます

<resource-env-ref>を使用したJNDIバインディング

例7-5に、MyExecutorというMESをjava:comp/env JNDIネームスペースにマップする方法を示します。

例7-5 <resource-env-ref>を使用した、エグゼキュータのJNDIへのバインド

weblogic.xml
<resource-env-description>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name>
<resource-link>MyExecutor</resource-link>
</resource-env-description>

web.xml
<resource-env-ref>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name>
<resource-env-ref-type>javax.enterprise.concurrent.ManagedExecutorService</resource-env-ref-type>
</resource-env-ref>

weblogic.xmlでは、resource-link要素によって、マップするエグゼキュータが指定されます。例7-5ではMyExecutorが指定されています。

weblogic.xmlで定義されているエグゼキュータが最初に検索され、次にweblogic-application.xml、config.xmlのmanaged-executor-service-templateの検索が続き、resource-linkで指定されたエグゼキュータに一致するエグゼキュータ名属性を見つけます。

resource-env-descriptionをweblogic-ejb-jar.xmlで定義する場合、weblogic-ejb-jar.xmlが最初に検索され、次にweblogic-application.xml、config.xmlの検索が続きます。

@Resourceを使用したJNDIバインディング

@Resourceアノテーションのマッピング・ルールは、resource-env-refのルールに相当しますが、次の異なる命名規則を使用します。

- resource-env-ref-nameは、@Resourceのname属性値です。

- resource-linkは、@Resourceで定義されるmappedName属性値に相当します。

Webコンポーネントで@Resourceを使用する場合、web.xmlでのresource-env-refの定義に相当します

EJBコンポーネントで@Resourceを使用する場合、ejb-jar.xmlでのresource-env-refの定義に相当します。

Java EE仕様で定義されるように、アノテーションをクラスまたはメソッドで使用することもできます。

resource-env-ref定義を使用する例7-5は、@Resourceを使用する例7-6に相当します。

例7-6 @Resourceを使用した、エグゼキュータのJNDIへのバインド

package com.example;
public class TestServlet extends HttpServlet {
@Resource(name="concurrent/MyExecutor" mappedName="MyExecutor")
private ManagedExecutorService  service;

この例では、@ResourceのmappedName属性を指定しない場合、デフォルトのエグゼキュータが使用されます。

resource-env-refと@Resourceをどちらも定義し、@Resourceのresource-env-ref-nameとname属性が同じ場合、resource-env-ref定義のエグゼキュータは@Resourceフィールドに挿入されます。

参照属性またはInitialContext.lookupで@Resourceを使用して、resource-env-refによってバインドされるエグゼキュータを見つけることもできます。

カスタムCMOモジュールの更新済スキーマ

次のWebLogic Serverスキーマには、CMOデプロイメント・ディスクリプタを構成するための要素が含まれています。

- weblogic-javee.xsd – WebLogic固有のすべてのデプロイメント・ディスクリプタ間で共有される共通の要素を記述します。
http://xmlns.oracle.com/weblogic/weblogic-javaee/1.4/weblogic-javaee.xsd

- weblogic-application.xml - application.xml Java EEデプロイメント・ディスクリプタを拡張したWebLogic Server固有のデプロイメント・ディスクリプタです。ここでは、アプリケーションやEJBキャッシングで参照される共有Java EEライブラリなどの機能を構成します。
『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』のweblogic-application.xmlのデプロイメント・ディスクリプタ要素に関する項を参照してください。

- weblogic-web-app.xsd – WebアプリケーションのWebLogic Server固有のデプロイメント・ディスクリプタ。
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

- weblogic-ejb-jar.xsd – EJBデプロイメントのWebLogic固有のXMLスキーマベース(XSD)デプロイメント・ディスクリプタ・ファイル。
Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント・ディスクリプタのリファレンスに関する項を参照してください。

例7-7に、weblogic-web-app.xsdのCMO関連要素を示します。

例7-7 weblogic-web-app.xsdのCMO要素

<xs:complexType name="weblogic-web-appType">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
...
<!-- added for JSR236 -->
<xs:element name="managed-executor-service" type="wls:managed-executor-serviceType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="managed-scheduled-executor-service" type="wls:managed-scheduled-executor-serviceType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="managed-thread-factory" type="wls:managed-thread-factoryType" minOccurs="0" maxOccurs="unbounded"/>
<!-- added end -->
...

CMOの更新済システム・モジュールBean

次のWebLogic Serverシステム・モジュールBeanには、アプリケーションおよびモジュールでCMOを構成するための属性が含まれています。

- ManagedExecutorServiceBean

- ManagedScheduledExecutorServiceBean

- ManagedThreadFactoryBean

- WeblogicApplicationBean

- WebLogicEjbJarBean

- WebLogicWebAppBean

詳細は、Oracle WebLogic Server MBeanリファレンスのWebLogic Serverシステム・モジュールMBeanに関する項を参照してください。

カスタム管理対象エグゼキュータ・サービスの構成要素

この項では、管理対象エグゼキュータ・サービスの構成要素を定義します。

表7-6 管理対象エグゼキュータ・サービスの構成要素

名前

説明

必須

デフォルト値

範囲

name

MESの名前。

同じ名前のMESを同じスコープで構成することはできません。たとえば、同じMES名をアプリケーションまたはモジュールのスコープで使用する場合、そのアプリケーションのデプロイメントが失敗します。

MESでは、ContextServiceなど他の種類の管理対象オブジェクトと同じ名前をスコープ内で使用できますが、その間に関連はありません。

同じ名前のMESは、次の場合、異なるスコープでのみ構成できます。

- サーバー・テンプレート、パーティション・テンプレートまたはアプリケーション・スコープで構成される同じ名前のMESが複数ある場合、パーティションMESテンプレート・エグゼキュータは、サーバー・テンプレートをオーバーライドし、アプリケーション・スコープMESはそれ以外の2つのレベルをオーバーライドします。

- モジュール・スコープで定義されるMES Aがあり、その名前が、サーバー・テンプレート、パーティション・テンプレートまたはアプリケーション・スコープで定義されるエグゼキュータBと同じであるとします。AとBはどちらも存在します。どちらのエグゼキュータを使用するかは、エグゼキュータを参照する場所によって決まります。

はい

該当なし

任意の空でない文字列。

dispatch-policy

ワーク・マネージャの名前。どのワーク・マネージャを使用するかについてのルールは次のとおりです。

- 管理対象エグゼキュータ・サービスをモジュール・スコープで定義する場合、モジュール・スコープのワーク・マネージャを最初に検索します。

- 見つからない場合は、アプリケーション・レベルを検索します。

- それでも見つからない場合は、デフォルトのワーク・マネージャが使用されます。(この動作は、サーブレットおよびEJBのディスパッチ・ポリシー解決戦略に一致します。)

いいえ

デフォルトのワーク・マネージャ

該当なし

max-concurrent-long-running-requests)

同時長時間実行タスクの最大数。

「最大同時長時間実行リクエストの制限の設定」を参照してください。

いいえ

10

[0-65534].

範囲外の場合、デフォルト値が使用されます。

long-running-priority

長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。

「最大同時新規スレッドの制限の設定」を参照してください。

いいえ

Thread.NORM_PRIORITY

1-10

Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

デプロイメント記述子の例

例7-8は、Webアプリケーションのweblogic.xmlファイルでのカスタムMES定義の例です。

例7-8 デプロイメント・ディスクプタを使用した、アプリケーションでのカスタムMESの定義

<!-- weblogic.xml -->
<managed-executor-service>
<name>MyExecutor</name>
<dispatch-policy>MyWorkManager</dispatch-policy>
<long-running-priority>10</long-running-priority>
<max-concurrent-long-running-requests>10</max-concurrent-long-running-requests>
</managed-executor-service>

例7-9は、<resource-env-ref>要素を使用した、weblogic.xmlディスクリプタでのカスタムMES参照の例です。

例7-9 <resource-env-ref>を使用した、アプリケーションでのカスタムMESの参照

weblogic.xml
<resource-env-description>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name
<resource-link>MyExecutor</resource-link>
</resource-env-description>

例7-10は、<resource-env-ref>要素を使用した、webl.xmlファイルでのカスタムMES参照の例です。

例7-10 <resource-env-ref>を使用した、WebアプリケーションでのカスタムMESの参照

web.xml
<resource-env-ref>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name
<resource-env-ref-type>javax.enterprise.concurrent.ManagedExecutorService</resource-env-ref-type>
</resource-env-ref>

例7-11は、@Resourceアノテーションを使用した、サーブレットでのカスタムMES参照の例です。

例7-11 @Resourceを使用した、サーブレットでのカスタムMESの参照

package com.example;
public class TestServlet extends HttpServlet {
@Resource(name="concurrent/MyExecutor" mappedName="MyExecutor")
private ManagedExecutorService  service;

カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素

この項では、管理対象スケジュール済エグゼキュータ・サービスの構成要素を定義します。

表7-7 管理対象スケジュール済エグゼキュータ・サービスの構成要素

名前

説明

必須

デフォルト値

範囲

name

MSESの名前。

ネーミング規則については、表7-6を参照してください。

はい

該当なし

任意の空でない文字列。

dispatch-policy

ワーク・マネージャの名前。

ワーク・マネージャの使用方法の規則については、表7-6を参照してください。

いいえ

デフォルトのワーク・マネージャ

該当なし

max-concurrent-long-running-requests

同時長時間実行タスクの最大数。

「最大同時長時間実行リクエストの制限の設定」を参照してください。

いいえ

10

[0-65534].

範囲外の場合、デフォルト値が使用されます。

long-running-priority

長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。

「最大同時新規スレッドの制限の設定」を参照してください。

いいえ

5 Thread.NORM_PRIORITY

1-1

Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

ScheduledFuture.get()メソッド

ScheduledFuture.get()メソッドは、タスクの最新の実行が完了するまでブロックします。たとえば、Triggerメソッドで、スケジュール予定のタスクを2回実行する必要があり(Trigger.getNextRunTimeは3回目のコールに対してnullを返す)、タスクの最初の実行が時間Aで完了し、タスクの2回目の実行が時間Bで完了する場合、次のようになります。

- 時間Aの前にFuture.get()をコールする場合、最初の実行が完了して最初の実行結果が返されるまで待機します。時間Aの後、時間Bの前にコールする場合、2回目の実行が完了して2回目の実行結果が返されるまで待機します。

- 時間Bの後にFuture.get()をコールする場合、2回目の実行結果がすぐに返されます。また、最初の実行が失敗して例外がスローされる場合、Futhur.getの最初のコールによって該当の例外がスローされ、2回目の実行は引き続きスケジュールされます(これはscheduleAtFixRateでは異なります)。Trigger.skipRunで最初の実行時にtrueが返される場合、Future.getの最初のコールでSkipExceptionがスローされます。

デプロイメント記述子の例

例7-12は、Webアプリケーションのweblogic.xmlファイルでのカスタムMSES定義の例です。

例7-12 デプロイメント・ディスクプタを使用した、アプリケーションでのカスタムMSESの定義

<!-- weblogic.xml -->
<managed-scheduled-executor-service>
<name>MyScheduledExecutor</name>
<dispatch-policy>MyExecutor</dispatch-policy>
</managed-scheduled-executor-service>

カスタム管理対象スレッド・ファクトリの構成要素

この項では、管理対象スレッド・ファクトリの構成要素を定義します。

表7-8 管理対象スレッド・ファクトリの構成要素

名前

説明

必須

デフォルト値

範囲

name

MTFの名前。

ネーミング規則については、表7-6を参照してください。

はい

該当なし

任意の空でない文字列。

priority

スレッドに割り当てる優先度。(数が大きいほど、高い優先度を示します。)

「最大同時新規スレッドの制限の設定」を参照してください。

いいえ

5 Thread.NORM_PRIORITY

1-10 Thread.MIN_PRIORITYとThread.MAX_PRIORITYとの間の範囲。範囲外の場合、デフォルト値が使用されます。

max-concurrent-new-threads

MTFによって作成され、タスクのrun()メソッドを引き続き実行するスレッドの最大数。

「最大同時新規スレッドの制限の設定」を参照してください。

いいえ

10

[0-65534]

範囲外の場合、デフォルト値が使用されます。

MTFで作成されるスレッドのコンテキスト

JSR236に従う場合、管理対象スレッド・ファクトリは、それ以外の管理対象オブジェクトとは異なります。これは、Thread.start()メソッドを使用してスレッドを開始した場合、実行される実行可能ファイルは、ManagedThreadFactoryインスタンスを作成したアプリケーション・コンポーネント・インスタンスのコンテキストで実行するためです。そのため、実行可能ファイルのコンテキストは、MTFインスタンスを作成したアプリケーション・コンポーネントによって異なります。

WebLogic Serverでは、アプリケーションまたはコンポーネントを開始すると、新しいMTFインスタンスが次のように作成されます。(コンポーネントは、WebモジュールまたはEJBを表します。)

1. デフォルトMTFは該当のコンポーネントで作成されます。

2. MTFを取得する@Resourceアノテーションがある場合、MTFインスタンスは該当コンポーネントで作成されます。

3. web.xml/ejb-jar.xmlで<resource-env-ref>が定義されており、MTFの<resource-link>を含むweblogic.xml/weblogic-ejb-jar.xmlで、対応する<resource-env-description>も定義されている場合、MTFインスタンスは該当コンポーネントで作成されます。

4. application.xmlで<resource-env-ref>が定義されており、MTFの<resource-link>を含むweblogic-application.xmlで、対応する<resource-env-description>も定義されている場合、MTFインスタンスは該当アプリケーションで作成されます。

前述の項目1、2、3の場合にMTFがコンポーネントで作成される場合、実行可能ファイルは、次のように該当コンポーネントのコンテキストで実行します。

- ClassLoader: 該当コンポーネントのクラス・ローダー。

- JNDI: java:app、java:moduleおよびjava:compが含まれる該当コンポーネントのJNDIツリー。

- Security: コンポーネントに固有のサブジェクトがないため、匿名サブジェクトに固定されます。

- WorkArea: コンポーネントに固有のWorkContextMapがないため、空のWorkContextMapに固定されます。

4の場合にMTFがアプリケーションで作成される場合、実行可能ファイルは、次のように該当アプリケーションのコンテキストで実行します。

- ClassLoader: 該当アプリケーションのクラス・ローダー。

- JNDI: java:appは含まれるが、java:moduleおよびjava:compは含まれない該当コンポーネントのJNDIツリー。

- Security: アプリケーションに固有のサブジェクトがないため、匿名サブジェクトに固定されます。

- WorkArea: アプリケーションに固有のWorkContextMapがないため、空のWorkContextMapに固定されます。

デプロイメント記述子の例

例7-13は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF定義の例です。

例7-13 デプロイメント・ディスクプタを使用した、アプリケーションでのカスタムMTFの定義

<!-- weblogic.xml -->
<managed-thread-factory>
<name>factory1</name>
<priority>3</priority>
<max-concurrent-new-threads>20</max-concurrent-new-threads>
</managed-executor-service>

例7-9は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF参照の例です。

例7-14 <resource-env-ref>を使用した、アプリケーションでのカスタムMTFの参照

weblogic.xml
<resource-env-description>
<resource-env-ref-name>ref-factory1</resource-env-ref-name
<resource-link>factory1</resource-link>
</resource-env-description>

例7-10は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF参照の例です。

例7-15 <resource-env-ref>を使用した、WebアプリケーションでのカスタムMTFの参照

web.xml
<resource-env-ref>
<resource-env-ref-name>ref-factory1</resource-env-ref-name
<resource-env-ref-type>javax.enterprise.concurrent.ManagedThreadFactory</resource-env-ref-type>
</resource-env-ref>

例7-11は、@Resourceアノテーションを使用した、サーブレットでのカスタムMTF参照の例です。

例7-16 @Resourceを使用した、サーブレットでのカスタムMTFの参照

package com.example;
public class TestServlet extends HttpServlet {
@Resource(lookup="java:comp/env/ref-factory1")
private ManagedThreadFactory factory;

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

この項では、CMOについてトランザクションがWebLogic Serverでどのように管理されるかについて説明します。

MESおよびMSESのトランザクション管理

MESを使用する場合、トランザクションは次のように管理されます。

- タスクを開始する前に、ワーク・マネージャのスレッドに実行中のトランザクションはありません。

- トランザクションAPIを使用して新しいトランザクションを開始する場合を除き、UserTransaction.getStatus()メソッドは常にStatus.STATUS_NO_TRANSACTIONになります。

- ユーザーは、必ずユーザー・タスクでそのトランザクションを完了する必要があります。完了しない場合、トランザクションはロールバックされます。

そのため、ManagedTask.TRANSACTIONおよび関連属性は無視されます。

コンテキスト・サービスのトランザクション管理

デフォルト、または実行プロパティManagedTask.TRANSACTIONの値をManagedTask.SUSPENDに設定する場合:

- スレッドに対して現在アクティブなトランザクションは中断されます。

- ローカルJNDIネームスペースでjava:comp/UserTransactionとしてアクセス可能なjavax.transaction.UserTransactionが利用できるため、コンテキスト・プロキシ・オブジェクトにより、トランザクションの開始、コミット、ロールバックが行われます。

- コンテキスト・プロキシ・オブジェクトで開始されたトランザクションがメソッドの終了前に完了しない場合、WARNINGログが出力され、トランザクションはロールバックされます。

- 元のトランザクションは、いずれかがスレッドに対してアクティブだった場合、タスクまたはコンテキスト・プロキシ・オブジェクトのメソッドが戻ると再開します。

実行プロパティManagedTask.TRANSACTIONの値をManagedTask.USE_TRANSACTION_OF_EXECUTION_THREADに設定する場合:

- トランザクションは、実行スレッドとタスク自体で管理されるため、コンテキスト・プロキシ・オブジェクトのメソッドの開始時に、スレッドに対して現在アクティブなトランザクションが中断されず、コンテキスト・プロキシ・オブジェクトのメソッドが戻ってもトランザクションは再開されません。

- スレッドに対して現在アクティブなトランザクションがある場合、コンテキスト・プロキシ・オブジェクトで使用されるリソースは、該当トランザクションに確保されます。

- コンテキスト・プロキシ・オブジェクトで開始されたトランザクションがメソッドの終了前に完了しない場合、トランザクションがコンテキスト・プロキシ・オブジェクトの別のメソッドで完了する可能性があるため、WebLogic Serverでは何も行われません。

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

MTFを使用する場合、トランザクションは次のように管理されます。

- タスクは明示トランザクションなしで実行されるため(アプリケーション・コンポーネントのトランザクションに確保されない)、新しいトランザクションをタスクで開始する場合を除き、UserTransaction.getStatus()メソッドは、常にStatus.STATUS_NO_TRANSACTIONを返します。

- トランザクションがタスク・メソッドの終了前に完了しない場合、WARNINGログが出力され、トランザクションはロールバックされます。

グローバルCMOテンプレート

JSR236のデフォルトCMOの他に、WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でグローバルCMOをテンプレートとして定義することもできます。config.xmlで指定したCMOは、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。

注意:

マルチテナントのパーティション化されたドメインは、WebLogic Server Premium Editionでのみ使用できます。詳細は、LINK TO INTRO TO WEBLOGIC SERVER MTを参照してください。

注意:

通常は、管理コンソールを使用して、WebLogic Serverの管理可能オブジェクトおよびサービスを構成し、WebLogic Serverでのconfig.xmlファイルの管理を許可する必要があります。

ドメインでは3つのタイプのCMOテンプレートを定義できます。

- 管理対象エグゼキュータ・サービス・テンプレート

- 管理対象スケジュール済エグゼキュータ・サービス・テンプレート

- 管理対象スレッド・ファクトリ・テンプレート

たとえば、managed-executor-service-templateを定義する場合、ドメインにデプロイされているアプリケーションごとに一意のMESインスタンスが作成されます。

管理コンソールを使用したCMOテンプレートの構成

CMOテンプレートは、 WebLogic Server管理コンソールを使用して、ドメインの構成でグローバルに構成できます。

1. 「ドメイン構造」ツリーで、「環境」を展開し、「同時テンプレート」をクリックします。

2. 「新規」をクリックし、次のいずれかのテンプレート・オプションを選択します。

- 管理対象エグゼキュータ・サービス・テンプレート

- 管理対象スケジュール済エグゼキュータ・サービス・テンプレート

- 管理対象スレッド・ファクトリ・テンプレート

3. 新規テンプレートの作成ページで、必要に応じてテンプレートのプロパティを入力します。プロパティは、作成する同時テンプレートのタイプによって異なります。

- カスタム管理対象エグゼキュータ・サービスの構成要素

- カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素

- カスタム管理対象スレッド・ファクトリの構成要素

4. 「次」をクリックします。

5. 同時テンプレートを、特定のWebLogic ServerインスタンスとWebLogic Serverクラスタのどちらにターゲット指定するかを選択します。

選択したサーバーまたはクラスタにデプロイされているアプリケーションのみがこの同時テンプレートを使用できます。

6. 「終了」をクリックします。同時テンプレートのサマリーページが表示され、新しい同時テンプレートがリストされます。

7. 必要に応じてその他の同時テンプレートを作成するには、これらの手順を繰り返します。

WebLogic Server管理コンソールを使用してWebLogic Serverドメインを管理する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

MBeanでのCMOテンプレートの構成

CMOテンプレートは、DomainMBeanで次の構成MBeanを使用して構成できます。

- ManagedExecutorServiceTemplateMBean

- ManagedScheduledExecutorServiceTemplateMBean

- ManagedThreadFactoryTemplateMBean

詳細は、Oracle WebLogic Server MBeanリファレンスのドメイン構成MBeanに関する項を参照してください。

同時制約の構成

制約は、WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でグローバルに定義することもできます。config.xmlで指定した同時制約は、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。

- 管理コンソールを使用した同時制約の構成

- MBeanでの同時制約の構成

管理コンソールを使用した同時制約の構成

同時制約は、管理コンソールを使用して、ドメイン構成、指定のサーバー・インスタンス、および動的クラスタのサーバー・テンプレートで構成できます。

ドメイン・レベルの同時制約

ドメインの同時制約の構成手順:

1. 「ドメイン構造」ツリーで、ツリー最上部のドメイン名を選択します。

2. 「構成」→「同時実行性」タブを選択します。

3. 「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。

- 最大同時長時間実行リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。

- 最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。

4. 「保存」をクリックします。

サーバー・レベルの同時制約

ドメインの特定サーバー・インスタンスに対する同時制約の構成手順:

1. 「ドメイン構造」ツリーで、「環境」を開き、「サーバー」をクリックします。

2. 「サーバーのサマリー」表で、サーバー・インスタンスを選択します。

3. 「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。

- 最大同時長時間実行リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。

- 最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。

4. 「保存」をクリックします。

動的クラスタ・レベルの同時制約

動的クラスタのサーバー・テンプレートに対する同時制約の構成手順:

1. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「サーバー・テンプレート」をクリックします。

2. 「サーバー・テンプレートのサマリー」表で、サーバー・テンプレート・インスタンスを選択します。

3. 「構成」→「同時実行性」タブを選択します。

4. 「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。

- 最大同時長時間リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。

- 最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。

5. 「保存」をクリックします。

MBeanでの同時制約の構成

同時制約は、ドメインの構成、指定のサーバー・インスタンス、および動的クラスタのサーバー・テンプレートで、メソッドDomainMBean、ServerMBean、ServerTemplateMBeanを使用してグローバルに構成できます。

- maxConcurrentLongRunningRequests() – 「最大同時長時間実行リクエストの制限の設定」を参照してください。

- maxConcurrentNewThreads() – 「最大同時新規スレッドの制限の設定」を参照してください。

WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

CMOの問合せ

グローバルCMOには、次の管理ツールを使用して問い合せることができます。

- 管理コンソールでのCMOスレッドのモニタリング

- MBeanを使用したCMOの監視

- MBeanを使用した同時制約の監視

管理コンソールでのCMOスレッドのモニタリング

CMOは、管理コンソールを使用してモニターできます。

サーバー・インスタンスでCMOによって作成されたスレッドをモニターするには:

1. 「ドメイン構造」ツリーで、「環境」を開き、「サーバー」をクリックします。

2. 「サーバー・テンプレートのサマリー」表で、サーバー・テンプレート・インスタンスを選択します。

3. 「設定」ページで、「モニタリング」→「同時実行性」タブを選択します。

このタブには、グローバル・ランタイムで作成されたCMOスレッドの統計が表示されます。

デプロイされているすべてのアプリケーションおよびモジュールのJSR236 CMOのモニター

ドメインのすべてのJSR236 CMOの統計をモニターするには:

1. 「ドメイン構造」ツリーで「デプロイメント」をクリックします。

2. 「デプロイメントのサマリー」ページで、「モニタリング」→「同時実行性」タブを選択します。
このタブには、関連するランタイムMBeanを呼び出すことによって、デプロイされているすべてのアプリケーションおよびモジュールのすべてのCMOの統計が表示されます。

デプロイされているEARまたはモジュールのJSR236 CMOのモニター

ドメインのすべてのJSR236 CMOの統計をモニターするには:

1. 「ドメイン構造」ツリーで「デプロイメント」をクリックします。

2. 「デプロイメントのサマリー」ページで、モニターするEARまたはモジュールを選択します。

3. 「設定」ページで、「モニタリング」→「同時実行性」タブを選択します。
選択したアプリケーションまたはモジュールのタイプに応じて、対応するランタイムMBeanからの統計がタブに表示されます。

- EARアプリケーション – そのアプリケーションのすべての同時オブジェクトの統計が表示されます(ApplicationRuntimeMBeanが呼び出されます)。

- EAR内のWebアプリケーションまたはEJBモジュール – そのモジュールのすべての同時オブジェクトの統計が表示されます(ComponentRuntimeMBeanが呼び出されます)。

- スタンドアロンのWebアプリケーションまたはEJBモジュール – そのWebアプリケーションまたはモジュールのすべての同時オブジェクトの統計が表示されます(ApplicationRuntimeMBeanおよびComponentRuntimeMBeanが呼び出されます)。

MBeanを使用したCMOの監視

CMOは、DomainMBeanで次の実行時MBeanを使用して監視できます。

- ManagedExecutorServiceRuntimeMBean
ManagedExecutorServiceRuntimeMBeanには、次のMBean属性からアクセスできます。

- ApplicationRuntimeMBean.ManagedExecutorServiceRuntimes – 該当アプリケーションのすべての管理対象エグゼキュータ・サービスの統計を提供します。

- ComponentRuntimeMBean.ManagedExecutorServiceRuntimes – 該当モジュールのすべての管理対象エグゼキュータ・サービスの統計を提供します。

Oracle WebLogic Server MBeanリファレンスのManagedExecutorServiceTemplateMBeanに関する項を参照してください。

- ManagedScheduledExecutorServiceRuntimeMBean
ManagedScheduledExecutorServiceRuntimeMBeanには、次のMBean属性からアクセスできます。

- ApplicationRuntimeMBean.ManagedScheduledExecutorServiceRuntimes – 該当アプリケーションのすべての管理対象スケジュール済エグゼキュータ・サービスの統計を提供します。

- ComponentRuntimeMBean.ManagedScheduledExecutorServiceRuntimes – 該当モジュールのすべての管理対象スケジュール済エグゼキュータ・サービスの統計を提供します。

Oracle WebLogic Server MBeanリファレンスのManagedScheduledExecutorServiceRuntimeMBeanに関する項を参照してください。

- ManagedThreadFactoryRuntimeMBean
ManagedThreadFactoryRuntimeMBeanには、次のMBean属性からアクセスできます。

- ApplicationRuntimeMBean.ManagedThreadFactoryRuntimes – 該当アプリケーションのすべての管理対象スレッド・ファクトリの統計を提供します。

- ComponentRuntimeMBean.ManagedThreadFactoryRuntimes – 該当モジュールのすべての管理対象スレッド・ファクトリの統計を提供します。

Oracle WebLogic Server MBeanリファレンスのManagedThreadFactoryRuntimeMBeanに関する項を参照してください。

WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

MBeanを使用した同時制約の監視

サーバーの同時制約は、次のMBean属性からアクセスできるConcurrentManagedObjectsRuntimeMBeanを使用して監視できます。

- ServerRuntimeMBean.ConcurrentManagedObjectsRuntime – グローバル・ランタイムの同時管理対象オブジェクトで作成されるスレッドの統計を提供します。

『Oracle WebLogic Server MBeanリファレンス』のConcurrentManagedObjectsRuntimeMBeanに関する項を参照してください。

WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。

8 バッチ・ランタイムの使用

この章では、Batch Applications for the Java Platform (JSR 352)のJava EE 7に定義されているように、バッチ・ジョブの定義、実装および実行をサポートする目的でWebLogic Serverが実装するバッチ・ランタイムについて説明します。

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

- バッチ・ジョブについて

- Derbyデータベースでのデフォルトのバッチ・ランタイム構成の使用

- 専用データベースを使用するためのバッチ・ランタイムの構成

- バッチ・ランタイムの問合せ

- トラブルシューティングのヒント

バッチ・ジョブについて

バッチ・ジョブは、ユーザー対話なしで実行できるタスクであり、非対話型でバルク指向の長時間実行タスクに最も適しています(これらのタスクは、リソース消費型で、順次実行またはパラレル実行が可能であり、アドホックに開始するか、スケジュールを使用して開始できます)。

Java EE 7のチュートリアルで説明するように、バッチ・フレームワークは次の内容で構成されます。

- XMLに基づくジョブ仕様言語。

- ビジネス・ロジックを実装するアプリケーション・クラスのバッチ・アノテーションおよびインタフェースのセット。

- バッチ・ジョブの実行を管理するバッチ・コンテナ。

- バッチ・コンテナと連携するためのクラスとインタフェースのサポート。

バッチ・ジョブ、バッチ処理およびバッチ処理フレームワークの詳細は、Java EE 7チュートリアルのバッチ処理に関する項を参照してください。「Java Specification Request 352: Batch Applications for the Java Platform」(http://jcp.org/en/jsr/detail?id=352)も参照してください。仕様により、バッチ・アプリケーションのプログラミング・モデルと、バッチ・ジョブのスケジュールおよび実行のランタイムが定義されます。

WebLogic ServerでのBatch 1.0のコード・サンプル

サンプルを備えたWebLogic Server一式をインストールする場合、サンプル・ソース・コードは、EXAMPLES_HOME\examples\src\examplesディレクトリに配置されます。デフォルト・パスはORACLE_HOME\wlserver\samples\serverです。このディレクトリから、サンプル・ドメインを設定せずに、Batch 1.0サンプルのソース・コードと手順ファイルにアクセスできます。

ORACLE_HOME\user_projects\domains\wl_serverディレクトリには、WebLogic Serverのサンプル・ドメインが含まれています。このドメインには、アプリケーション、アプリケーションおよびOracle WebLogic Serverの動作を定義するXML構成ファイル、および起動スクリプトと環境スクリプトが含まれます。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

- Batch Job Operatorの使用 – javax.batch.operations.JobOperatorインタフェースを使用してバッチ・ジョブを発行する方法を示します。JobOperatorインタフェースには、ジョブの起動、停止、再起動および調査を行うための一連の操作が用意されています。このサンプルでは、リスナーを使用して、バッチ処理実行時に発生する特定イベントを通知する方法も示されます。

EXAMPLES_HOME/examples/src/examples/javaee7/batch/joboperator-api

- バッチ並行処理モデルを使用した、パーティション化ジョブ・ステップの実行 – PartitionMapperインタフェースを使用して、並行処理を適切に制御できる方法を示します。

EXAMPLES_HOME/examples/src/examples/javaee7/batch/partition

- Avitek Medical Records (MedRec) – WebLogic ServerおよびJava EEの機能とベスト・プラクティスを例示する総合的な学習用サンプル・アプリケーションです。Java EE 7の場合、Medrecでは、管理者のバックグラウンドに薬品統計を集計することで、バッチ処理機能を示します。統計は、レコード、医師および薬品の観点で、開始日と終了日を含めたコストを1回のバッチでまとめて要約しますが、3つの出力が行われます。
Avitek Medical Recordsは、オプションで、WebLogic Serverと一緒にインストールできます。MedRecは、ORACLE_HOME/user_projects/domains/medrecから起動できます。ORACLE_HOMEは、Oracle WebLogic Serverのインストール時にOracleホームとして指定したディレクトリです。

バッチを使用する独自のアプリケーションをプログラミングする前に、これらのサンプルを実行することをお薦めします。

Derbyデータベースでのデフォルトのバッチ・ランタイム構成の使用

バッチ・アプリケーションは、WebLogic Serverにデプロイしてすぐに開始できます。実行時の構成は必要ありません。これは、大量のデータの処理や格納を行わない比較的小規模の開発環境に役立ちます。

バッチ・ランタイム構成が存在しない場合、WebLogic Serverで使用される内容は次のとおりです。

- バッチ・ジョブの詳細を保持するためにJobRepositoryの更新に必要なデータ・ソースを作成するデモDerbyデータベース。

- java:comp/DefaultManagedExecutorServiceのデフォルトJNDI名にバインドされるエグゼキュータ・サービス(Java EE 7仕様で必要)。

デフォルトのバッチ・ランタイム構成にアクセスするには、startWeblogic.shスクリプトを使用してWebLogic Serverを起動する必要があります。

バッチ・ランタイムの問合せの詳細は、「バッチ・ランタイムの問合せ」を参照してください。

専用データベースを使用するためのバッチ・ランタイムの構成

WebLogic Serverのバッチ・ランタイムでは、XA対応データ・ソースを使用してバッチ・ジョブと管理対象エグゼキュータ・サービスのJobRepository表にアクセスすることで、非同期バッチ・ジョブを実行します。管理対象エグゼキュータ・サービスでジョブを処理して、JobRepositoryデータ・ソースで現在と過去のジョブのステータスを格納します。

WebLogicドメインのデフォルトのバッチ・ランタイムは構成なしで使用できるため、Derbyデモ・データベースのみを必要とする開発モード環境で役立ちます。データベース・スキーマを使用するデータ駆動本番環境では、ドメインの専用JobRepositoryデータ・ソースと管理対象エグゼキュータ・サービスを構成できます。

- 前提条件ステップによるJobRepository表、バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスの構成

- 管理コンソールを使用したバッチ・ランタイムの構成

- WLSTを使用したバッチ・ランタイムの構成

前提条件ステップによるJobRepository表、バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスの構成

大量のデータを処理して格納するエンタープライズ・レベルの本番環境の場合、特定のデータベースにバッチ・ジョブの詳細を格納するように専用バッチ・ランタイムを構成できます。

JobRepository表の作成

データベース管理者は、バッチ・ジョブの詳細を保持するために必要なJobRepository表を作成する必要があります。これらの表の作成に使用されるスキーマ名は、ドメインのバッチ・ランタイムの構成時に、BatchConfigMBeanのgetSchemaName()メソッドで示されます。「専用バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスを使用するためのバッチ・ランタイムの構成」を参照してください。

JobRepository表は、WebLogic Server 12cで使用するためにサポートされるデータベースの場合、リポジトリ作成ユーティリティ(RCU)またはSQLスクリプトを使用して作成できます。これらの表を作成するためのスキーマは、次の場所にあります。

ORACLE_HOME/oracle_common/common/sql/wlservices/batch/dbname

ORACLE_HOMEは、Oracle WebLogic Serverの最上位インストール・ディレクトリ、dbnameはデータベースの名前を表します。

WebLogic Server 12cのサポート対象データベースの詳細は、Oracle Technology Networkの「Oracle Fusion Middleware Supported System Configurations」ページを参照してください。

RCUを使用したJobRepository表の作成

RCUを使用してJobRepository表とスキーマ所有者を作成する場合、次の事項に注意することが重要です。

1. 「コンポーネントの選択」ページで、コンポーネントとして「WebLogicサービス」を選択します。また、「スキーマ所有者」名が、選択したスキーマ接頭辞文字列に「WLS」を加えたもの(JBatch_WLSなど)にデフォルトで設定されることに注意してください。この名前はバッチ・データ・ソースとバッチ・ランタイムの作成時に使用するため書き留めておいてください。

2. 「スキーマ・パスワード」ページで、すべてのスキーマに同じパスワードを選択オプションを選択します。

3. 「終了」をクリックすると、RCUは、バッチ、EJBタイマー、診断など、WebLogic関連のすべてのコンポーネントの表とスキーマを作成します。

これで、「JobRepositoryのJDBCデータ・ソースの作成」の説明に従い、バッチ・データ・ソースを作成できます。「コンポーネントの選択」ページで選択したスキーマ所有者をデータ・ソースのユーザー名として使用する必要があることに注意してください。

注意:

バッチ・ランタイムはスキーマ名をキャッシュします。JobRepository表を更新するために接続を取得すると、その接続に対してスキーマ名を設定します。この制限が原因で、アプリケーションとJobRepositoryの両方に同じデータ・ソースを使用できません(個別のスキーマを使用する場合)。

リポジトリ・クリーン・ユーティリティ(RCU)の詳細は、『Oracle Fusion Middlewareリポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

SQLスクリプトを使用したJobRepository表の作成

RCUユーティリティを使用してバッチのJobRepository表を作成しない場合、SQLコマンド行ユーティリティと付属のbatch.sqlスクリプトを使用して作成できます。たとえば、Oracle DatabaseおよびOracle EBR (Edition-Based Redefinition)のJobRepository表を作成する場合、SQLで表を作成する必要があります。

batch.sql SQLスクリプトは、JobRepository表を作成するためにすべてのサポート対象データベース(mysql、db2など)に用意されており、次の場所にあります。

ORACLE_HOME/oracle_common/common/sql/wlservices/batch/dbname

batch.sql SQLスクリプトを使用して表を作成するには、次の手順を実行します。

1. 使用するデータベースのSQLコマンド行セッションを開きます。

2. batch.sqlスクリプトで識別されるjbatchという新しいユーザーを作成します。

3. ユーザーjbatchにConnect権限を付与します。

4. ユーザーjbatchにResource権限を付与します。

5. OracleデータベースのSQLスクリプトが含まれるディレクトリからbatch.sqlスクリプトを実行します。次に例を示します。

ORACLE_HOME/oracle_common/common/sql/wlservices/batch/oracle/batch.sql

これで、「JobRepositoryのJDBCデータ・ソースの作成」の説明に従い、バッチ・データ・ソースを作成できます。作成したjbatchスキーマ所有者をデータ・ソースのユーザー名として使用する必要があることに注意してください。

JobRepositoryのJDBCデータ・ソースの作成

ドメイン内の専用バッチ・ランタイムの場合、WebLogic管理者は、JobRepository表が含まれるデータベースに対してXA対応データ・ソースを構成する必要があります。Java EEコンポーネントがバッチ・ジョブを発行すると、バッチ・ランタイムは、データ・ソースのJNDI名の参照により取得されるこのXAデータ・ソースを使用してJobRepository表を更新します。

管理コンソールまたはWLSTを使用してバッチ・データ・ソースを作成する場合、「JobRepository表の作成」の説明に従い、RCUで作成したスキーマ所有者(jbatch_wlsなど)またはSQLスクリプトで作成したスキーマ所有者jbatchを使用する必要があります。

JDBCデータ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。

管理対象エグゼキュータ・サービス・テンプレートの作成(オプション)

最適なパフォーマンスを実現するために、バッチ・ランタイムsetBatchJobsManagedExecutorServiceName()と同じ名前を使用する管理対象エグゼキュータ・サービス・テンプレート(MESテンプレート)を構成することで、アプリケーション・スコープ指定の管理対象エグゼキュータ・サービスを使用するようにバッチ・ランタイムを構成できます。バッチ・ランタイムの構成時にMESテンプレートを指定しない場合、(java:comp/DefaultManagedExecutorService)にバインドされるデフォルトのJava EE管理対象エグゼキュータ・サービスをかわりに使用します。

管理対象エグゼキュータ・サービスの新しいインスタンスがMESテンプレートごとに作成される場合、ドメインにデプロイされるアプリケーションに対して発行されるバッチ・ジョブを実行します。たとえば、ドメインにMES1およびMES2という2つのMESテンプレートがある場合、BatchApp1とBatchApp2をデプロイすると、各アプリケーションは、MES1とMES2のインスタンスを取得します。

ただし、setBatchJobsExecutorServiceName("MES2")を設定した場合、BatchApp1またはBatchApp1 (あるいは、ドメインにデプロイされるいずれかのアプリケーション)から発行されたすべてのバッチ・ジョブではMES2を使用します。

管理対象エグゼキュータ・サービス・テンプレートの構成の手順については、「同時管理対象オブジェクトの構成」を参照してください。

専用バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスを使用するためのバッチ・ランタイムの構成

「前提条件ステップによるJobRepository表、バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスの構成」で作成したJobRepositoryデータ・ソースと管理対象エグゼキュータ・サービスは、次のいずれかのWebLogic管理ツールを使用して、専用バッチ・ランタイムを構成するために使用できるようになりました。

- 管理コンソールを使用したバッチ・ランタイムの構成

- WLSTを使用したバッチ・ランタイムの構成

ヒント:

「JobRepository表の作成」で使用されるスキーマ名は、次の項で構成手順を実行する際に指定する必要があります。たとえば、MBeanを使用する場合、スキーマ名は、ドメインのBatchConfigMBeanのgetSchemaName()で示す必要があります。

管理コンソールを使用したバッチ・ランタイムの構成

専用バッチ・ランタイムは、管理コンソールを使用してドメイン・スコープに構成できます。「domain-nameの設定」ページで、「バッチ」ページを開き、次の構成フィールドに入力します。

- データソースJNDI名 – バッチ・ランタイムのJobRepositoryデータ・ソースのJNDI名を選択します。これは、ドメインにデプロイされたアプリケーションから発行されるバッチ・ジョブのデータを格納するために使用されます。

- スキーマ名 – 「JobRepository表の作成」で説明するように、JobRepository表がRCUまたはJBatch SQLスクリプトで作成されたときに使用されたスキーマ名を入力します。
データ・ソースがアプリケーションで共有される場合、このスキーマ名は、アプリケーションが予期するものと同じ名前である必要があります。

- エグゼキュータ・サービス・テンプレート – 管理対象エグゼキュータ・サービス(MES)テンプレートを選択します。これは、ドメインにデプロイされたアプリケーションから発行されるバッチ・ジョブを実行するために使用されます。同じ名前のMESテンプレートが存在し、バッチ・ジョブの発行時にドメイン・スコープにターゲット指定される必要があります。
MESテンプレートを選択しない場合、バッチ・ランタイムは、デフォルトのJNDI名java:comp/DefaultManagedExecutorServiceにバインドされるデフォルトのJava EE管理対象エグゼキュータ・サービスを使用します。

WebLogic Server管理コンソールを使用して、管理対象エグゼキュータ・サービス・テンプレートをドメイン構成で構成するには、「環境」→「同時テンプレート」ページを使用します。詳細は、「同時管理対象オブジェクトの構成」を参照してください。

WLSTを使用したバッチ・ランタイムの構成

WLSTでBatchRuntimeConfigMBeanとDomainMBeanを使用して、JobRepositoryに特定のデータベースを使用するようにバッチ・ランタイムを構成できます。

def update_domain_batch_config(domainName, jndiName, schemaName):
connect('admin','passwd')
edit()
startEdit()
cmo.setDataSourceJndiName(jndiName)
cd('/BatchConfig/' + domainName)
cmo.setSchemaName(schemaName)
save()
activate()

この例では、管理者がJNDI名jdbc/batchDSでデータ・ソースを作成した場合、update_domain_batch_config('mydomain','jdbc/batchDS','BATCH')をコールすると、jndiName: 'jdbc/batchDS'にバインドされたデータ・ソースで指し示されるデータベースのスキーマ'BATCH'にすべてのJobRepository表を格納するようにバッチ・ランタイムが構成されます。

WLSTを使用して、バッチ・ジョブの実行に特定の管理対象エグゼキュータ・サービスを使用するようにバッチ・ランタイムを構成できます。ただし、最初に管理対象エグゼキュータ・サービスを作成し、その管理対象エグゼキュータ・サービスの名前をDomainMBeanに指定する必要があります。

connect('admin','passwd')
edit()
startEdit()
cmo.setBatchJobsExecutorServiceName('mesName')
save()
activate()

ここで、mesNameは、このドメインに対してすでに作成されている(ターゲット指定されている)管理対象エグゼキュータ・サービスの名前になります。

バッチ・ランタイムは、DomainMBeanのgetBatchJobsManagedExecutorServiceName()メソッドを使用して、別の管理対象エグゼキュータ・サービスを使用するように構成できます。ただし、同じ名前の管理対象エグゼキュータ・サービス・テンプレートが存在し、バッチ・ジョブの発行時にドメイン・スコープにターゲット指定される必要があります。

詳細は、Oracle WebLogic Server MBeanリファレンスのBatchConfigMBeanに関する項およびDomainMBeanに関する項を参照してください。

WLSTコマンドの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のオンラインおよびオフラインのWebLogic Server WLSTコマンド・リファレンスに関する項を参照してください。

バッチ・ランタイムの問合せ

次の管理ツールを使用して、ドメイン・スコープについてバッチ・ランタイムのJobRepositorに問い合せることができます。

- 管理コンソールを使用したバッチ・ランタイムの問合せ

- ランタイムMBeanを使用したバッチ・ランタイムの問合せ

注意:

バッチJobRepositoryを格納しているデータベースが実行されていることを確認してください。たとえば、デフォルトのDerbyデータベースは、java weblogic.Serverコマンドを使用してWebLogic Serverをブートしたときに自動的に起動されることはありません。データベースが実行されていない場合は、バッチ・ジョブを発行したときか、WLSTまたは管理コンソールを使用してBatchJobRepositoryRuntimeMBeanにアクセスしたときに、バッチRIによって例外がスローされます。詳細は、「トラブルシューティングのヒント」を参照してください。

管理コンソールを使用したバッチ・ランタイムの問合せ

管理コンソールを使用してJobRepositoryに問い合せることで、ドメインのバッチ・ジョブの詳細を取得できます。

すべてのバッチ・ジョブの詳細の取得

「domain-nameの設定」ページで、「モニタリング」→「バッチ・ジョブ」ページを開き、ドメインにデプロイされたアプリケーションから発行されるすべてのジョブの詳細を表示します。

表8-1 すべてのバッチ・ジョブ

要素名

説明

ジョブ名

バッチ・ジョブの名前。

アプリケーション名

バッチ・ジョブを発行したアプリケーションの名前。

インスタンスID

インスタンスID。

実行ID

実行ID。

バッチ・ステータス

このジョブのバッチ・ステータス。

開始時刻

ジョブの開始時刻。

終了時刻

ジョブの完了時刻。

終了ステータス

ジョブの終了ステータス。

ジョブの実行に関する詳細の取得

ジョブのステップ実行の詳細は、それを選択して「表示」をクリックすることで表示できます。

表8-2 ジョブ実行の詳細

要素名

説明

ジョブ名

バッチ・ジョブの名前。

インスタンスID

インスタンスID。

実行ID

実行ID。

バッチ・ステータス

このジョブのバッチ・ステータス。

開始時刻

ジョブの開始時刻。

終了時刻

ジョブの完了時刻。

終了ステータス

ジョブの終了ステータス。

ジョブのステップ実行に関する詳細の取得

ジョブ実行の各ステップに関するメトリックは、それを選択して「表示」をクリックすることで表示できます。

表8-3 ステップ実行の詳細

要素名

説明

ステップ名

バッチ・ジョブ・ステップの名前。

ステップID

ステップID。

実行ID

実行ID。

バッチ・ステータス

このジョブのバッチ・ステータス。

開始時刻

ジョブの開始時刻。

終了時刻

ジョブの完了時刻。

終了ステータス

ジョブの終了ステータス。

ランタイムMBeanを使用したバッチ・ランタイムの問合せ

WLSTでBatchJobRepositoryRuntimeMBeanを使用してJobRepositoryに問い合せることで、ドメインのバッチ・ジョブの詳細を取得できます。

詳細は、『Oracle WebLogic Server MBeanリファレンス』のBatchJobRepositoryRuntimeMBeanに関する項を参照してください。

getJobDetailsを使用したすべてのバッチ・ジョブの詳細の取得

getJobDetails()属性により、ドメインにデプロイされたアプリケーションによって発行されるすべてのジョブに関する詳細が返されます。コレクションの各エントリには、次の要素の配列が含まれます。

表8-4 getJobDetails()属性の要素

要素名

説明

JOB_NAME

バッチ・ジョブの名前。

APP_NAME

バッチ・ジョブを発行したアプリケーションの名前(文字列)。

INSTANCE_ID

インスタンスID (長)。

EXECUTION_ID

実行ID (長)。

BATCH_STATUS

このジョブのバッチ・ステータス(文字列)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)。

EXIT_STATUS

ジョブの終了ステータス(文字列)。

次に、ドメインにデプロイされたすべてのバッチ・ジョブのリストを出力するgetJobDetails()を使用するWLSTスクリプトの例を示します。

connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobDetails(6)
print "JobName  AppName   InstanceID  ExecutionID  BatchStatus  StartTime  EndTime  ExitStatus"
print e[0], " ", e[1], " ", e[2], "   ", e[3], "  ", e[4], "  ", e[5], " ", e[6],   ",e[7]

次に、getJobDetails()の実行後のサンプル出力を示します。

JobName   InstanceID  ExecutionID   BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015   COMPLETED
PayrollJob     5           5         COMPLETED   Fri Apr 24 10:10:57 PDT 2015   Fri Apr 24 10:10:58 PDT 2015   COMPLETED
PayrollJob     4           4         COMPLETED   Fri Apr 24 10:10:56 PDT 2015   Fri Apr 24 10:10:56 PDT 2015   COMPLETED
PayrollJob     3           3         COMPLETED   Mon Apr 20 11:32:12 PDT 2015   Mon Apr 20 11:32:12 PDT 2015   COMPLETED
PayrollJob     2           2         COMPLETED   Mon Apr 20 11:32:10 PDT 2015   Mon Apr 20 11:32:11 PDT 2015   COMPLETED
PayrollJob     1           1         COMPLETED   Mon Apr 20 11:25:26 PDT 2015   Mon Apr 20 11:25:26 PDT 2015   COMPLETED

getJobExecutionsを使用したジョブ実行の詳細の取得

getJobExections属性により、特定のジョブ実行に関する詳細が返されます。コレクションの各エントリには、次の要素の配列が含まれます。

表8-5 getJobExecutions()属性の要素

要素名

説明

JOB_NAME

バッチ・ジョブの名前(文字列)。

INSTANCE_ID

インスタンスID (長)。

EXECUTION_ID

実行ID (長)。

BATCH_STATUS

このジョブのバッチ・ステータス(文字列)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)。

EXIT_STATUS

ジョブの終了ステータス(文字列)。

次に、特定のExecutionIDの詳細を取得するためにWLSTスクリプトでgetJobExectuions()を使用する例(getJobExecutions(6))を示します。すべてのExecutionIDのリストを取得するには、getJobDetails()メソッドを使用します。

connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobExecutions(6)
print  "JobName    InstanceID   ExecutionID   BatchStatus   StartTime   EndTime    ExitStatus"
for e in executions
print e[0], "  ", e[1], "    ", e[2], "    ", e[3], "    ", e[4], "  ", e[5], "  ", e[6]

次に、getJobExecutions()の実行後のサンプル出力を示します。

JobName   InstanceID  ExecutionID   BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015    COMPLETED

getStepExecutionsを使用したジョブ・ステップ実行の詳細の取得

getStepExecutions属性により、ジョブ実行の各ステップに関するメトリックが返されます。コレクションの各エントリには、次の要素の配列が含まれます。

表8-6 getStepExecutions()属性の要素

要素名

説明

STEP_NAME

バッチ・ジョブ・ステップの名前(文字列)。

STEP_ID

ステップID (長)。

EXECUTION_ID

実行ID (長)。

BATCH_STATUS

このジョブのバッチ・ステータス(文字列)。

START_TIME

ジョブの開始時刻(java.util.Date)。

END_TIME

ジョブの完了時刻(java.util.Date)

EXIT_STATUS

ジョブの終了ステータス(文字列)。

次に、特定のStepExecutionID (getStepExecutions(6))の詳細を取得するためにWLSTスクリプトでgetStepExecutions()を使用する例を示します。すべてのExecutionIDのリストを取得するには、getJobDetails()メソッドを使用します。

connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getStepExecutions(6)
print  "StepName   StepExecutionID   BatchStatus    StartTime    EndTime    ExitStatus"
print e[0], "     ", e[1], "      ", e[2], "     ", e[3], " ", e[4], "   ", e[5], "]

次に、getStepExecutions()の実行後のサンプル出力を示します。

StepName   StepExecutionID  BatchStatus       StartTime                      EndTime                   ExitStatus
PayrollJob     6           6         COMPLETED   Fri Apr 24 10:11:00 PDT 2015   Fri Apr 24 10:11:01 PDT 2015    COMPLETED

トラブルシューティングのヒント

この項では、WebLogic Serverでのバッチ・ランタイムの構成と使用に関するヒントについて説明します。

JobRepository表が含まれるデータベースが実行していることを確認する

Batch RI (参照実装)のユーザーがよく犯す間違いとして、JobRepository表を含むデータベースの起動を怠ることがあります。たとえば、java weblogic.Serverコマンドを使用してWebLogicを起動する場合、Derbyデータベースは自動で起動しません。DBが実行していない場合、バッチ・ジョブを発行するかJobRepositoryRuntimeMBeanにアクセスすると(WLSTまたは管理コンソールのいずれかを使用)、そのジョブは失敗し、Batch RIから次のような不可解な例外がスローされます。

[1] Exception thrown by Refernce Implementation (from IBM):

Caused by: weblogic.common.resourcepool.ResourceSystemException: Cannot load driver class org.apache.derby.jdbc.ClientDataSource for datasource '<<<Data Source name>>>>'

次に、JobRepositoryのデータベースが実行していない場合にBatch RIからスローされる可能性のある別のエラー・メッセージを示します。

Caused By: com.ibm.jbatch.container.exception.PersistenceException:
weblogic.jdbc.extensions.ConnectionDeadSQLException:
weblogic.common.resourcepool.ResourceDeadException:
0:weblogic.common.ResourceException: Could not create pool connection for datasource '_com_oracle_weblogic_batch_connector@_com_oracle_weblogic_batch_connector_impl_@_com_oracle_weblogic_batch_connector_impl_WLSDatabaseConfigurationBean@_com_oracle_batch_internal__derby_batch_DataSource'.
The DBMS driver exception was: java.net.ConnectException : Error connecting to server localhost on port 1,527 with message Connection refused.
at
com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnectionToDefaultSchema(JDBCPersistenceManagerImpl.java:354)
at
com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.isDerby(JDBCPersistenceManagerImpl.java:182)
at
com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.init(JDBCPersistenceManagerImpl.java:143)
at
com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.getService(ServicesManagerImpl.java:404)
at
com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.access$300(ServicesManagerImpl.java:388)

これらのエラーが表示された場合、Batch JobRepositoryが含まれるデータベースが実行していることを確認します。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, 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 Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。