Fusion Middleware Oracle WebLogic Serverサーバー環境の構成

11g リリース1 (10.3.6)

B60987-04(原本部品番号:E13701-06)

目次

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

はじめに

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

- ルール

1 概要とロードマップ

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

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

- 関連ドキュメント

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

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

- WebLogic Serverでのスレッド・プールの使用方法について

- ワーク・マネージャについて

- リクエスト・クラス

- 制約

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

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

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

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

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

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

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

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

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

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

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

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

- 実行キューの有効化

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

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

- WebLogic ServerでのCommonJの使い方

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

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

3 過負荷の回避と管理

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

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

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

- HTTPセッションの制限

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

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

- WebLogic Serverの自動モニター

- 過負荷ヘルス状態

- WebLogic Serverの終了コード

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

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

- ネットワーク・チャネルについて

- チャネルとは

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

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

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

- チャネルの障害の処理

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

- WebLogic Serverの標準チャネル

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

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

- 内部チャネルの使い方

- チャネルの選択

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

- チャネルの構成

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

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

- チャネルの動的な構成

- チャネルとプロトコル

- 予約済みの名前

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

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

- クラスタの作成

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

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

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

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

5 Webサーバー機能の構成

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

- サーバーの構成

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

- Webアプリケーション

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

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

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

- 仮想ホストの設定

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

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

- ログ・ローテーション

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

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

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

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

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

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

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

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

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

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

6 WebLogic永続ストアの使い方

- 永続ストアの概要

- 永続ストアの特長

- 高パフォーマンスのスループットとトランザクション・サポート

- ファイル・ストアとJDBC対応ストアの比較

- 永続ストアの高可用性

- 永続ストアの移行

- 高可用性ストレージ・ソリューション

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

- デフォルト・ストアの場所

- デフォルト・ファイル・ストアの例

- カスタム・ファイル・ストアとJDBCストアの使い方

- カスタム永続ストアを使用すべき状況

- カスタム永続ストアの作成方法

- カスタム永続ストアのパラメータの変更

- カスタム(ユーザー定義)ファイル・ストアの作成

- カスタム・ファイル・ストアを構成する主な手順

- カスタム・ファイル・ストアの例

- 同期書込みポリシーの構成のガイドライン

- Direct-Write-With-Cacheポリシー

- Direct-Writeポリシー

- Cache-Flushポリシー

- 無効化ポリシー

- JDBC対応ストアの作成

- JDBC TLogストアの使用

- JDBC TLOGストアを構成する主な手順

- JDBC TLOGストアの例

- 構成のガイドライン

- 追加の考慮事項

- JDBC TLOGストア使用時のサーバー移行

- JDBC TLOGストアの監視

- セキュリティの考慮事項

- JDBCストアの使用

- JDBCストアを構成する主な手順

- JDBCストアの例

- サポートされるJDBCドライバ

- デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成

- JDBCストア表の管理

- JDBCストアの構成のガイドライン

- JDBCストアのI/Oマルチスレッド処理の有効化

- 永続ストアのモニター

- ストアのモニター

- ストア接続のモニター

- 永続ストアの管理

- Javaコマンド・ラインを使用したストア管理

- ストア管理ヘルプの使用

- ファイル・ストアの内容のダンプ

- ファイル・ストアの圧縮

- WLSTを使用したストア管理

- ストア管理ヘルプの使用

- WLSTを使用したJDBCストアの内容のダンプ

- WLSTを使用したファイル・ストアの圧縮

- セキュリティの考慮事項

- 永続ストアの制限事項

Oracle® Fusion Middleware

Oracle WebLogic Serverサーバー環境の構成

11g リリース1 (10.3.6)

B60987-04(原本部品番号:E13701-06)

2011年11月

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

Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成, 11g リリース1 (10.3.6)

B60987-04

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

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

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

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

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

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

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

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

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

はじめに

この章では、『Oracle WebLogic Serverサーバー環境の構成』で使用されるアクセシビリティ機能および表記規則について説明します。

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

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プログラミング言語について読者が精通していることを前提としています。

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

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

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

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

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

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

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

- 第6章「WebLogic永続ストアの使い方」では、永続ストアの構成およびモニターについて説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込の高性能なストレージ・ソリューションを提供します。

関連ドキュメント

- Oracle WebLogic Serverドメインの構成について

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

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

このリリースにはJDBC TLOGストアの新機能が含まれ、これを使用するとトランザクション・ログをデフォルトの永続ストアではなくデータベースに永続化できます。詳細は、「JDBC TLogストアの使用」を参照してください。

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

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つまたは複数のワーク・マネージャ・コンポーネントを定義します。

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

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

- 最小スレッド数制約

- 最大スレッド数制約

- 容量制約

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

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

これらのワーク・マネージャ・コンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらのすべてのコンポーネント(コンテキスト・リクエスト・クラス以外。「例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アプリケーションのweb.xmlファイルに追加します。

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

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

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

- リクエスト・クラス

- 制約

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

リクエスト・クラス

リクエスト・クラスは、リクエストへのスレッドの割当てに使用するスケジューリング・ガイドラインを表現します。リクエスト・クラスを使用すると、優先順位の高い作業が優先順位の低い作業より後に送信された場合でも、優先順位の高い作業を優先順位の低い作業より前にスケジューリングすることができます。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コンテキストリクエスト・クラス

<work-manager>
<name>responsetime_workmanager</name>
<response-time-request-class>
<name>my_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
</work-manager>

<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>

注意:
Webアプリケーションのワーク・マネージャがコンテキスト・リクエスト・クラスを参照している場合、最初のユーザー呼出しはデフォルトのリクエスト・クラスを通じて実行され、同じセッションの以降の呼出しはユーザー定義のリクエスト・クラスを通じて実行されます。
コンテキスト・リクエスト・クラスを使用するとき、セッション・タイムアウト値を設定すると、ワーク・マネージャ・キューでリクエストが待機中にセッションの期限が切れなくなります。

制約

制約を使用すると、リクエストを実行するために割り当てられるスレッドの最小数と最大数、および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です。容量には、制約対象の作業セットからの全リクエスト(キューにあるリクエストと実行中のリクエスト)が含まれます。個々の容量しきい値を超えた場合、またはグローバル容量を超えた場合に作業が拒否されます。この制約は、グローバル・キューのしきい値とは無関係です。

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

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

たとえば、例 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>

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

基本的に、ワーク・マネージャには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を参照してください。

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

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

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

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

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.2/weblogic-ejb-jar.xsd

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

- weblogic.xml schema - 『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.2/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.2/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.3/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.3/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で動作したときと同じように動作します。詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic 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およびトランザクション・マネージャによって過負荷管理されるため、ここでは対象外となります。

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

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

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

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

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が自動的に再起動するように構成し、ダウンタイムを最短にできます。

これを構成するには、管理コンソールを使用するか、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リソース(ネットワーク・チャネルやドメイン全体の管理ポートなど)を使用すると、アプリケーションをホストするマシンのネットワーク機能を効果的に利用してサービスの質を管理できる方法について説明します。

以下の項では、構成可能なWebLogic Serverネットワーク・リソース、それらの使用例、および構成プロセスについて説明します。

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

- ネットワーク・チャネルについて

- チャネルの構成

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

ネットワーク構成の概要

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

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

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

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

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

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

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

ネットワーク・チャネルについて

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

チャネルとは

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

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

- リスニング・アドレス

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

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

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

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

チャネル構成のルール

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

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

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

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

- 非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)を提供します。リスニング・アドレスとリスニング・ポートは、管理コンソールの「構成」>「一般」ページで構成できます; 割り当てた値は、ServerMBeanおよびSSLMBeanの属性に格納されます。

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

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

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

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

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

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

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

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

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

ドメインにはオプションの管理ポートを定義できます。構成された管理ポートは、ドメインの各管理対象サーバーで、ドメインの管理サーバーとの通信用に排他的に使用されます。

管理ポートの機能

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

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

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

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

管理ポートが有効になっている場合、WebLogic Serverはサーバー・インスタンスの起動時にポート設定に基づいて自動的に管理チャネルを生成します。

管理ポートの制限事項

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

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

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

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

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

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

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

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

管理ポートで必須のSSL

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

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

デフォルトでは、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では、クラスタ間の管理トラフィックや通信を処理するためのネットワーク・チャネルを作成できるようになりました。この機能は、以下の状況において有用です。

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

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

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

チャネルの選択

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

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

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

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

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

- 管理トラフィック

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

チャネルの構成

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

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

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

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

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

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

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

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

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

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

チャネルの動的な構成

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

チャネルとプロトコル

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

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

予約済みの名前

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

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

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

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

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

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

クラスタの作成

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

- 『Oracle WebLogic Serverクラスタの使用』のクラスタリングされたドメインの作成の手順に従い、構成ウィザードを使用してクラスタリングされたドメインを新しく作成します。

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

WebLogic Serverクラスタの構成の情報とガイドラインは、『Oracle WebLogic Serverクラスタの使用』の「始める前に」を参照してください。

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

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

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

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

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

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

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

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

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

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 WebLogic Enterprise JavaBeansのプログラミング』のnetwork-access-pointを参照してください。

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.system.enableSetUIDプロパティを(必要に応じてweblogic.system.enableSetGIDプロパティも)trueに設定することで、WebLogic Serverがポート80にバインドした後にUNIXユーザーID(UID)を切り替えるための内部プロセスを有効にできます。これらに対応するweblogic.system.nonPrivUserプロパティとweblogic.system.nonPrivGroupプロパティは、WebLogic Serverの起動後の実行に使用する権限のないUNIXユーザー・アカウント(必要に応じてグループ名)を識別します。

注意:
UNIXマシンで実行されているノード・マネージャを使用して管理サーバーを起動する際、次のJavaシステム・プロパティを使用すると、これらのオプションを設定できます。-Dweblogic.system.enableSetUID=true、-Dweblogic.system.nonPrivUser=weblogic、-Dweblogic.system.enableSetGID=true、-Dweblogic.system.nonPrivGroup=group。

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

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

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

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

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

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

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

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

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

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

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

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

Webアプリケーション

HTTPアプリケーションとWebアプリケーションは、サーブレット仕様2.4およびJSP仕様2.0に従ってデプロイされます。これらの仕様では、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の時差(大カッコで囲まれて示されます)。

"request"

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

ステータス

使用可能な場合、サーバーによって戻された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通信に関する記録情報のタイプと順序を指定できます。このフォーマットを有効にするには、管理コンソールの「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>です。

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

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

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

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は、以下のURLで参照できます。

- http://download.oracle.com/javaee/5/api/javax/servlet/ServletRequest.html

- http://download.oracle.com/javaee/5/api/javax/servlet/ServletResponse.html

- http://download.oracle.com/javaee/5/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();

サーブレットのサービス・メソッドがデータをクライアントへ書き戻すのにかかる時間を戻します。

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 WebLogic永続ストアの使い方

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

- 永続ストアの概要

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

- カスタム・ファイル・ストアとJDBCストアの使い方

- カスタム(ユーザー定義)ファイル・ストアの作成

- JDBC対応ストアの作成

- 永続ストアのモニター

- セキュリティの考慮事項

- 永続ストアの制限事項

永続ストアの概要

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたはデータベースのJDBC対応ストアの永続性をサポートします。

表6-1に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。

表6-1 永続ストアのユーザー

サブシステム/サービス

格納対象

詳細についての参照先

診断サービス

ログ・レコード、データ・イベント、収集されたメトリック

『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDF構成について

JMSメッセージ

永続メッセージ、恒久サブスクライバ

『Oracle WebLogic Server JMSのプログラミング』のメッセージング・モデルについて

JMSページング・ストア

各JMSサーバーに1つ。ページされた永続メッセージと非永続メッセージ。

『Oracle WebLogic Server JMSの構成と管理』の基本JMSシステム・リソースの構成の主な手順

JTAトランザクション・ログ(TLOG)

サーバーによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報TLOGは、デフォルトの永続ストアまたはJDBC TLOGストアに保存できます。

- 『Oracle WebLogic Server JTAのプログラミング』のトランザクションの管理

- JDBC TLogストアの使用

パス・サービス

メッセージのグループからメッセージング・リソースへのマッピング

『Oracle WebLogic Server JMSの構成と管理』のWebLogicパス・サービスの使用

ストア・アンド・フォワード(SAF)サービス・エージェント

SAF送信エージェントからSAF受信エージェントに再転送するメッセージ

『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』のストア・アンド・フォワード・サービスについて

Webサービス

信頼性のあるWebLogic Webサービスの呼出しによるSOAPリクエスト・メッセージおよびレスポンス・メッセージ

『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』の信頼性のあるSOAPメッセージングの使い方

EJBタイマー・サービス

EJBタイマー・オブジェクト

『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のEnterprise JavaBeansを参照してください。

ストアの接続IDの詳細は、「ストア接続のモニター」を参照してください。

永続ストアの特長

永続ストアの主な特徴は以下のとおりです。

- 各サーバー・インスタンスのデフォルト・ファイル・ストアは構成不要です。

- すべてのサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定している場合のみ、デフォルト・ストアおよびカスタム・ストアを複数のサブシステムで共有できます。

- 構成すると、JDBC TLOGストアには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報が格納されます。アプリケーションのニーズに応じて、TLOG情報をデフォルト・ストアまたはJDBC TLOGストアのどちらに保持するかを選択できます。「JDBC TLogストアの使用」を参照してください。

- 高パフォーマンスのスループットとトランザクション・サポート

- パラメータを修正してカスタム・ファイル・ストアやJDBCストアを作成できる

- 永続ストアの統計情報と開いているストア接続をモニターできる

- クラスタリング環境では、サーバー全体レベルまたはサービス・レベルで、JDBC TLOGストアおよびカスタマイズしたストアを異常のあるサーバーからバックアップ・サーバーに移行できます。

高パフォーマンスのスループットとトランザクション・サポート

永続ストアのパフォーマンス上の主な目標はスループットの向上です。複数のサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定していれば、これらのサブシステムで同じデフォルトまたはカスタム・ストアを共有できます。

注意:
JDBC TLOGストアは、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持する場合にのみ使用されます。他のサブシステムによって共有できません。

この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション・マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、TLOG、JMSとEJBのタイマーが1つのファイル・ストアを共有し、JMSメッセージとEJBタイマーが単一のトランザクションで作成された場合、そのトランザクションは1フェーズとなり、リソースの書込みは1回しか発生しません。一方、2フェーズの場合であれば、リソースごとに2回ずつで合計4回のリソース書込みが発生し、加えてトランザクション・ログでのトランザクション・エントリの書込みが1回発生することになります。

ファイル・ストアおよびJDBCストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。

ファイル・ストアとJDBC対応ストアの比較

次に、ファイル・ストアとJDBC対応ストアの類似点と相違点を挙げます。

- デフォルトの永続ストアはファイル・ストアにしかできません。したがって、JDBCストアはデフォルトの永続ストアとしては使用できません。

- どちらもトランザクションのセマンティクスと保証を備えています。JDBCストアの書込みと同様、ファイル・ストアの書込みでもディスクへの保存が保証されており、単に中間キャッシュ(つまり、安全性が保障されないキャッシュ)に保存されるわけではありません。

- どちらも同じアプリケーション・インタフェースを備えています(アプリケーション・コードに違いがありません)。

- すべての条件が同じ場合、一般的にファイル・ストアの方がJDBCストアよりスループットが高くなります。

注意:
データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Serverがそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBCストアの方がパフォーマンスが良くなる場合もあります。

- 通常、ファイル・ストアの方が構成および管理が簡単であり、WebLogicのサブシステムが外部コンポーネントに依存する必要もありません。

- ファイル・ストアは、ネットワーク・トラフィックを生成しません。JDBCストアは、データベースがWebLogic Serverとは異なるマシンに存在する場合にネットワーク・トラフィックを生成します。

- JDBCストアの方が障害リカバリが容易。JDBCインタフェースが同じネットワーク上の任意のマシンからデータベースにアクセスできるからです。ファイル・ストアの場合、ディスクが共有または移行されている必要があります。

永続ストアの高可用性

高可用性の点では、永続ファイルベースのストア(デフォルトまたはカスタム)は、サーバー全体レベルの移行機能の一部としてその親サーバーとともに移行できます。この場合、サービス・レベルではなく、サーバー・レベルで自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの使用』のサーバー全体の移行を参照してください。ただし、ファイルベースのストアは、クラスタ内の移行可能なターゲット・サーバーからアクセスできる共有ディスク上に構成する必要があります。

永続ストアの移行

ファイルベースのストアおよびJDBC対応ストアも、ストアを使用してデータを維持するJMS関連サービス(JMSサーバー、SAFエージェント、パス・サービスなど)のサービス・レベル移行の一部として移行できます。サービス・レベルの移行は、JMS関連サービスをグループ化した移行可能なターゲットに制御されます。移行可能なターゲットは、クラスタ内の1つの物理サーバーのみでホストされます。ホストされているサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行可能なターゲットによってホストされるJMSサービスは、サーバー障害への対処として、または定期的なサーバー・メンテナンスの一環として手動でも移行できます。移行可能なターゲットを移行すると、そのターゲットによってホストされているすべての固定サービスも移行されます。サービス・レベルの移行の詳細は、『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。

移行可能なJMS関連サービスで、デフォルトのファイル・ストアを使用することはできません。したがって、カスタムのファイル・ストアまたはJDBCストアを構成し、関連付けたJMSサーバー、SAFエージェント、またはパス・サービスと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。

注意:
パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。

移行可能なファイル・ストアは、クラスタ内の移行可能なターゲットからアクセスできる共有ディスク上に構成するか、または移行前/移行後スクリプトを使用してファイル・ストアのデータをバックアップ・サーバーに移行できます。詳細は、『Oracle WebLogic Serverクラスタの使用』のJMSサービスで使用できるカスタム・ストアを参照してください。

高可用性ストレージ・ソリューション

JMSサーバーまたはJTAトランザクション・ログの移行後に、リモート・マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ・ソリューションのいずれかを実装する必要があります。

- ファイル・ベース・ストア(デフォルトまたはカスタム) - デュアルポートSCSIディスクまたはストレージ領域ネットワーク(SAN)などのハードウェア・ソリューションを実装して、共有可能ディスクやリモート・マシンからもファイル・ストアを利用できるようにします。

注意:
ファイル・ストアが切断されて再接続された場合、永続JMSメッセージの送受信を正常に続行するには、ホスト・サーバー・インスタンスを再起動する必要があります。たとえば、ファイル・ストアを含むファイル・システムがアンマウントされた後再びマウントされた場合、ホスト・サーバーを再起動せずに永続JMSメッセージを送信しようとするとJMS例外が生成されます。

- JDBC対応ストア - JDBCストアまたはJDBC TLOGストアを構成し、JDBCを使用してこのストアにアクセスします。このストアは、別のサーバーに存在する場合もあります。そのあと、アプリケーションでは、データベース・ベンダーによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバー・ソリューションを利用できます。また、JDBCストアではGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされるため、Oracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーが可能です。詳細については、以下を参照。

- 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCマルチ・データ・ソースの構成

- 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のGridLinkデータ・ソースの使用

- 任意の永続ストア - WebLogic Serverベースのアプリケーション用のすぐに使用できる統合ソリューションを提供する、高可用性クラスタリング・ソフトウェアを使用します。

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

管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトの記憶域メカニズムを使用することで最適に動作するサブシステムから使用できます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。

デフォルト・ストアは、DefaultFileStoreMBeanパラメータを直接操作して構成できます。このMBeanがドメインの構成ファイルで定義されていない場合は、DefaultFileStoreMBeanには、構成サブシステムによってデフォルト値が確保されます。

また、管理コンソールを使用してデフォルト・ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書込みポリシーを変更できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更を参照してください。

デフォルト・ストアの場所

デフォルト・ストアのデータは、ドメインのルート・ディレクトリのservernameサブディレクトリにあるdata\store\defaultディレクトリに保持されます。

たとえば、デフォルト・ファイル・ストアのディレクトリ名が指定されていない場合、次のディレクトリがデフォルトになります。

MW_HOME\user_projects\domains\domain-name\servers\server-name\data\store\default

domainnameはドメインのルート・ディレクトリ(通常はc:\oracle\user_projects\domains\domainname)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\oracle\wlserver_10.3)に対応するディレクトリです。

ただし、DefaultFileStoreMBeanパラメータを直接操作するか、管理コンソールを使用してデフォルト・ストアの場所を変更できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更を参照してください。

デフォルト・ファイル・ストアの例

ドメインの構成ファイルでのデフォルト・ファイル・ストアの定義例を示します。この例では、デフォルトのディレクトリと同期書込みポリシーの設定がオーバーライドされています。

<server
<name>myserver</name>
<default-file-store>
<directory>C:/store</directory>
<synchronous-write-policy>Disabled</synchronous-write-policy>
</default-file-store>
</server>

カスタム・ファイル・ストアとJDBCストアの使い方

デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、カスタム・ファイル・ストアを作成して、特定のストレージ・デバイスにデータを保持したり、ファイル・ストアにアクセスするJMSサービスがクラスタ内の別のサーバー・メンバーにストアを移行できるようにしたりすることも可能です。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。

JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ソースを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。JDBCストアでは、JMSサービスを自動または手動で移行する移行可能ターゲットをサポートすることもできます。

永続ストアの構成の詳細は、「カスタム永続ストアを使用すべき状況」を参照してください。

カスタム永続ストアを使用すべき状況

WebLogic Serverでは、カスタム・ファイル・ストアやJDBC対応のストアを作成するための構成オプションが用意されています。たとえば、次のような状況が考えられます。

- ファイル・ストアのファイルを特定のデバイスに配置します。

- 特定のサーバー・インスタンスで、ファイル・ストアの代わりにJDBCストアを使用します。トランザクション・ログを保持する場合は、JDBC TLOGストアを使用します。「JDBC TLogストアの使用」を参照してください。

- クラスタ内のすべての物理ストアで同じ論理名を共有します。

- 異なるサービスを論理的に分けて、別々のファイルや表を使用します。(これにより、パフォーマンスは下がりますが、管理や保守は容易になります。)

- 移行可能なJMS関連サービスでは、デフォルトの永続ストアは使用できません。したがって、カスタム・ストアを構成し、移行可能なJMSサービスと同じ移行可能なターゲットにターゲット指定する必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。

カスタム永続ストアの作成方法

カスタム永続ストアは、次の方法で構成できます。

- 管理コンソールを使用する。カスタム・ファイル・ストアまたはJDBCストアの構成については、『Oracle WebLogic Server管理コンソール・ヘルプ』の永続ストアの構成に関する項を参照してください。JDBC TLOGストアの構成については、『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。

- 永続ストアをホストするサーバー・インスタンスの構成ファイル(config.xml)を直接編集します。

- WebLogic Java Management Extensions(JMX)を使用して永続ストアを作成します。JMXは、ネットワーク上のリソースを監視および管理するためのJava EEソリューションです。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

- WebLogic Scripting Tool (WLST)を使用して永続ストアを作成します。WLSTは、WebLogic Serverインスタンスとドメインに対して、相互作用や構成のために使用するコマンド・ライン・スクリプト・インタフェースです。詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

- WebLogic構成ウィザードを使用して、デフォルト永続ストアのオプションを変更します。構成ウィザードを使用して永続ストアを構成する方法の詳細は、『構成ウィザードによるドメインの作成』のWebLogicドメインの作成を参照してください。

カスタム永続ストアのパラメータの変更

JDBCストアの接頭辞やファイル・ストアのディレクトリなど、特定のカスタム・ストアの構成オプションの変更において次を実行する場合、サーバーの再起動は必ずしも必要ではありません。

1. (カスタム・ストアを使用するJMSサーバーなど)依存するサービスのターゲットをnullに設定し、カスタム・ストアのターゲットをnullに設定します(サービスのターゲットをnullに設定すると、暗黙的にサービスが停止します)。

2. カスタム・ストアのターゲットを元の値に戻し、依存するリソースのターゲットを元の値に戻すことによってプロセスを元に戻します。

カスタム・ストアとJMSサーバーが移行可能ターゲットを共有する場合、移行可能ターゲットを管理的に再起動することができます。

カスタム(ユーザー定義)ファイル・ストアの作成

次の項では、カスタム・ファイル・ストアの例を示し、同期書込みポリシーを選択する上での構成ガイドラインについて説明します。

カスタム・ファイル・ストアを作成する場合は、デフォルトのFileStoreMBeanパラメータを直接変更できます。管理コンソールを使用してカスタム・ファイル・ストアを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成を参照してください。

カスタム・ファイル・ストアを構成する主な手順

カスタム・ファイル・ストアを作成するための主な手順は次のとおりです。

1. ファイル・ストアのデータを格納するディレクトリを作成します。

2. カスタム・ファイル・ストアを作成し、作成したディレクトリの場所を指定します。

3. カスタム・ファイル・ストアにアクセスするサブシステムまたは移行可能ターゲットに、以下の方法でカスタム・ファイル・ストアを関連付けます。

- JMSサーバーの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

- ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

- パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

カスタム・ファイル・ストアの例

ドメインの構成ファイルでのデフォルト・ファイル・ストアの定義例を示します。この例では、ファイルが/disk1/jmslogディレクトリに保持されるように定義されています。

<file-store>
<name>SampleFileStore</name>
<target>myserver</target>
<directory>/disk1/jmslog</directory>
</file-store>

表6-2に、ファイル・ストアの変更可能な構成パラメータについて簡単にまとめます。

表6-2 カスタム・ファイル・ストアの構成オプション

オプション

必須

機能

名前

はい

ファイル・ストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。

ターゲット

はい

ファイル・ストアをターゲット指定するサーバー・インスタンスまたは移行可能ターゲット。複数のサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定していれば、これらのサブシステムで同じファイル・ストアを共有できます。

注意: JMSサービスで移行可能なターゲットを使用する場合は、ファイル・ストアをJMSサービスで使用するのと同じターゲットにターゲット指定する必要があります。『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。

ディレクトリ

はい

ファイル・ストアを保持するディレクトリのファイル・システム上のパス名。

注意: ファイル・ストアに移行可能なターゲットを指定する場合、ストア・ディレクトリは移行可能なターゲットのすべての候補サーバー・メンバーからアクセスできる必要があります。最高レベルの可用性を実現するには、SAN(ストレージ領域ネットワーク)またはデュアルポートSCSIディスクのいずれかを使用してください。詳細は、『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。

既存のファイル・ストアのディレクトリを変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

CacheDirectory

いいえ

この設定は、直接書込み - キャッシュありファイル・ストアの同期書込みポリシーにのみ適用されます。詳細は、「同期書込みポリシーの構成のガイドライン」を参照してください。

論理名

いいえ

必要に応じて、EJBなどのサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。

同期書込みポリシー

いいえ

個別の書込み操作の永続性を含む、ファイル・ストアのIO動作を定義します。指定できる値は、直接書込み(デフォルト)、直接書込み - キャッシュあり、キャッシュ・フラッシュ、および無効です。

詳細は、「同期書込みポリシーの構成のガイドライン」を参照してください。

管理コンソールを使用してカスタム・ファイル・ストアを構成する手順は、Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成を参照してください。

同期書込みポリシーの構成のガイドライン

ファイル・ストアで使用できる複数の同期書込みポリシーがあります。同期書込みポリシーでは、ファイル・ストアの書込み操作の動作が決まります。環境に最適で、実行時のパフォーマンスや万が一のクラッシュ発生後のデータ整合性のニーズを満たすポリシーを選択する必要があります。同期書込みポリシーのチューニングとパフォーマンスおよびファイル・ストアの他のオプションの詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic永続ストアのチューニングを参照してください。

注意:
実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの同期書込みポリシーとドライバを表示するには、サーバー・ログのWL-280008およびWL-280009メッセージを確認してください。

直接書込み - キャッシュありポリシー

ほとんどのシナリオでは、直接書込み - キャッシュありポリシーをご使用をお薦めします。このポリシーを選択すると、WebLogic Serverは、ネイティブなI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期的に書き込みます。また、WebLogic Serverは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書き込みます。これは、OSメモリーにより、プライマリ・データ・ファイル用の出力バッファとしてキャッシュ・ファイル・ブロックをキャッシュすることで、暗示的に実行されます。キャッシュ・ファイルは、実行時と起動時のパフォーマンスの最適化、およびリカバリのために使用されます。ネイティブ・ファイル・ドライバによる直接的な書込みおよび対応するキャッシュ・ファイルの組合の使用により、ディスクへの書込みが最も安全に実施され、全体的に最良のパフォーマンスが実現されます。

このオプションでは、他のポリシーの約2倍のディスク領域が使用され、ファイルは2つの場所に格納されます。これらの場所のディスク領域の割当を考慮し、両方の場所を確保しておく必要が場合があります。

直接書込み - キャッシュありポリシーでファイルの場所を構成する場合は、高可用性(サーバー全体の移行またはサービスの自動移行)のために構成する場合であっても、CacheDirectory属性の場所はローカル・ディレクトリである必要があります。キャッシュ・ファイルはパフォーマンスの最適化のためにのみ使用されます。メッセージの実際の永続ストレージは、ファイル・ストアの構成のDirectory属性によって定義されます。移行されたWebLogic ServerインスタンスまたはJMSサービスは、移行後にこのディレクトリのみを使用できる必要があります。障害時リカバリの場合も同様ですが、Directory場所で定義されたファイルをバックアップ・サイトにレプリケートする必要があります。

注意:
ファイル・ストアのネイティブwlfileioドライバがロードできない場合は、ストアは代替の特化された直接書込みポリシー・モードで自動的に実行されます。実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの構成済と実際の同期書込みポリシーとドライバを表示するには、サーバー・ログでWL-280008とWL-280009メッセージを確認してください。
以前のいくつかのバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了が誤って報告される可能性があります。システム・クラッシュや停電の発生はレコード/メッセージの失敗や重複につながる可能性があるため、これは、Direct-Write(デフォルト)またはDirect-Write-With-Cacheポリシーで構成されたファイル・ストアを含む、(Oracle固有でない)トランザクション製品のトランザクション・セマンティクスに違反します。目に見える兆候の1つは、この問題がストレージ・デバイスの物理的な容量を超える高い永続メッセージ/トランザクション・スループットとして現れることです。この問題を解決するには、Microsoftから提供されるパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護されたストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。

直接書込みポリシー

直接書込みポリシーを選択すると、WebLogic Serverでは、ネイティブのI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所にあるプライマリ・ファイルのセットに同期に書き込まれます。このポリシーは直接書込み - キャッシュありポリシーより処理速度が遅いが、少ないディスク領域を使用し、管理する環境の考慮事項もより少ないです。通常は、直接書込みポリシーの処理速度はキャッシュ・フラッシュポリシーより速いです。

注意:
以前のいくつかのバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了が誤って報告される可能性があります。システム・クラッシュや停電の発生はレコード/メッセージの失敗や重複につながる可能性があるため、これは、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、(Oracle固有でない)トランザクション製品のトランザクション・セマンティクスに違反します。目に見える兆候の1つは、この問題がストレージ・デバイスの物理的な容量を超える高い永続メッセージ/トランザクション・スループットとして現れることです。この問題を解決するには、Microsoftから提供されるパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護されたストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。

キャッシュ・フラッシュ・ポリシー

キャッシュ・フラッシュポリシーを選択すると、WebLogic Serverでは、オペレーティング・システムとストレージ・デバイスのデフォルトのファイル書込み動作が有効になります。デフォルトのファイル書込み動作では、基本的にキャッシングとファイルの書込みのスケジューリングを行いますが、トランザクションが完了する前にキャッシュのディスクへのフラッシュを強制します。書込みがすべてディスクにフラッシュされるまで、トランザクションが完了できません。このポリシーは信頼性と拡張性があり、同時ユーザーの増加に対応できます。このポリシーは、トランザクションが安全ですが、通常のユース・ケースの場合は(同時プロデューサやコンシューマが多数の場合を除く)、実行時のパフォーマンスが直接書込みポリシーより低くなります。

無効ポリシー

無効ポリシーを選択すると、WebLogic Serverはオペレーティング・システムとストレージ・デバイスのデフォルト・ファイル書込み動作に依存します。ほとんどの場合は、ファイル書込みはメモリーにキャッシュされ、ディスクに直接書き込まれることはなく、書込みはスケジューリングされます。通常は、無効ポリシーは、ファイル・ストアのパフォーマンスを大幅に向上しますが、オペレーティング・システムのクラッシュまたはハードウェア障害に伴い、送信メッセージの紛失や受信メッセージの重複が生成する可能性があります。トランザクションは、ディスクへの書込みを待機することなく、書込みがメモリーにキャッシュされた時点で完了するためです。オペレーティング・システムの正常シャットダウンや、WebLogic Serverプロセスの中断でこのような障害が発生することはありません。オペレーティング・システムは、正常シャットダウンの際にすべての未処理の書込みをフラッシュするためです。ビジー・サーバーの電源を突然切断すると、このようなのエラーが発生します。

JDBC対応ストアの作成

次の項では、JDBC対応ストアを構成および使用する方法について説明します。

- JDBC TLogストア: トランザクション・ログ(TLOGs)をデータベースに保持します。「JDBC TLogストアの使用」を参照してください。

- JDBCストア: WebLogic Serverインスタンス・サービスとサブシステム情報をデータベースに保持します(ただし、TLOGは除きます)。「JDBCストアの使用」を参照してください。

JDBC TLogストアの使用

JDBC TLOGストアを構成すると、トランザクション・ログをデータベースに保持できます。これには次の利点があります。

- 基本データベースのレプリケーションとHA特性を活用できます。

- データベースの状態とTLOGを簡単に同期できるため、災害からのリカバリを簡素化できます。

- 実行するトランザクション・ログを新しい場所に移行(コピー)する必要がないため、トランザクション・リカバリ・サービスの移行が向上します。

JDBC TLOGストアを構成する主な手順

JDBC TLOGストアを作成するための主な手順は次のとおりです。

1. JDBCストアへのインタフェースとなるJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースを作成します。「データ・ソースの選択」を参照してください。

2. JDBC TLOGストアを作成し、これを手順1で作成したJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースに関連付けます。『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。

3. オプション。接頭辞オプションに、構成するJDBC TLOGストア表ごとに1つの一意の値を構成することを強くお薦めします。

4. 高可用性のため、データ・ソースをバックアップ・サーバーで利用できるようにします。第6章「JDBC TLOGストア使用時のサーバー移行」を参照してください。

データ・ソースの選択

ご使用のWebLogic Serverライセンスとアプリケーションのニーズに応じて、次のデータ・ソース・タイプのいずれかを選択できます。

- 汎用データ・ソース - 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCデータ・ソースの作成に関する項およびOracle RACでの接続時間フェイルオーバーの使用に関する項を参照してください。

- GridLinkデータ・ソース - 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のGridLinkデータ・ソースの使用に関する項を参照してください。

- マルチ・データ・ソース - 完全にレプリケーションされたゼロ・レイテンシ・データベース(Oracle RACなど)によってバックアップされます。『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCマルチ・データ・ソースの構成に関する項およびOracle RACでマルチ・データ・ソースの使用に関する項を参照してください。

JDBC TLOGストアの例

ドメインの構成ファイルでのJDBC TLOGストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。

<server>
<transaction-log-jdbc-store>
<data-source>MyDataSource</data-source>
<prefix-name>TLOG_MS1</prefix-name>
<create-table-ddl-file>myDDL/myCreateTable.sql</create-table-ddl-file>
<max-retry-seconds-before-tlog-fail>120</max-retry-seconds-before-tlog-fail>
</transaction-log-jdbc-store>
</server>

表6-4に、JDBCストアの変更可能な構成パラメータを示します。

表6-3 JDBC TLOGストアの構成オプション

オプション

必須

機能

データ・ソース

はい

ストアのデータベース表(WLStore)にアクセスするために、このJDBCストアによって使用されるJDBCデータ・ソースまたはマルチ・データ・ソース。このデータ・ソースまたはマルチ・データ・ソースは、JDBCストアと同じサーバー・インスタンスにターゲット指定される必要があります。

注意:グローバル(XA)トランザクションをサポートするように構成されたJDBCデータ・ソースは指定できません。したがって、指定されたJDBCデータ・ソースは非XA JDBCドライバを使用する必要があります。また、このデータ・ソースで「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を有効にすることはできません。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

接頭辞名

いいえ

通常、JDBCストアの表の接頭辞は[[[catalog.]schema.]prefix]というフォーマットで指定します。

複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。また、2つのJDBCストアで同じデータベース表を共有することはできません。詳細は、「JDBCストアでの接頭辞の使い方」を参照してください。

既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

DDLファイルからの表の作成

いいえ

JDBCストアのデータベース表(WLStore)を作成するために、オプションで、サポートされるDDLファイルで使用されます。JDBCストアのデータベース表がすでに存在する場合は、このオプションは無視されます。詳細は、「デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。

バッチごとに削除(最大)

デフォルトは20です。

データベースを呼び出すごとに削除される最大表行数。

バッチごとに挿入(最大)

デフォルトは20です。

データベースを呼び出すごとに挿入される最大表行数。

ステートメントごとに削除(最大)

デフォルトは20です。

データベースを呼び出すごとに削除される最大表行数。

MaxRetrySecondsBeforeTLogFail

デフォルトは300です。

WebLogic ServerがJDBC TLogストア障害からのリカバリを試行する最大時間(秒単位)。この期間後でもストアを使用できない場合は、WebLogic Serverによって正常性状態がHEALTH_FAILEDに設定されます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちに正常性状態がHEALTH_FAILEDに設定されます。

MaxRetrySecondsBeforeTXRollback

デフォルトは60です。

トランザクションの処理中にWebLogic ServerがJDBC TLogストア障害からのリカバリを試行するまでの最大待機時間(秒単位)。この期間後でもストアを使用できない場合は、影響を受けるトランザクションはWebLogic Serverによってロールバックされます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちにトランザクションはロールバックされます。実際の最大値は、MaxRetrySecondsBeforeTLogFailの現在の値よりも小さくなります。

RetryIntervalSeconds

デフォルトは5です。

ストア障害発生後に、WebLogic ServerがTLOGストアの正常性を検証する試行を実行するまでの最大待機時間(秒単位)。

管理コンソールを使用してJDBC TLOGストアを構成する手順は、『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。

構成のガイドライン

次の項では、JDBC TLOGストアの構成に関するガイドラインを示します。

- JDBC TLOGストアをターゲットにできるのは、グローバル・スコープ(アプリケーション・スコープではありません)のデータ・ソースのみです。

- 1台のWebLogic Serverごとに構成できるJDBC TLOGストアの数は1つのみです。逆に、複数のWebLogic Serverで1つのJDBC TLOGストアを共有できません。

- JDBC TLOGストアを構成する必要があります。デフォルトでは、TLOG情報をサーバーのデフォルト永続ストアに保持するよう設定されています。

- XA JDBCドライバを使用するよう構成されたデータ・ソースや、グローバル・トランザクションをサポートするよう構成されたデータ・ソースは使用できません。非XAデータ・ソースを使用します。

- JDBC対応ストアに関する一般ルールについては、「JDBCストアの構成のガイドライン」を参照してください。

追加の考慮事項

次の項では、JDBC TLOGストアの動作と制約に関する追加の考慮事項について説明します。

- TLOG情報の保存に使用されるデータベースは、サーバー起動時に使用可能な状態である必要があります。データベースが使用できない場合は、WebLogic Serverインスタンスの起動が失敗します。

- JDBC TLOGストアを使用し、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持できるのは、JTAサブシステムのみです。それ以外のシステムはJDBC TLOGストアにアクセスできません。

- JDBC TLOGストアを使用してもLLR動作は変更されません。JDBC TLOGストアはLLRの有無に関係なく使用できます。LLRトランザクションと連動して使用すると、情報をコミットするトランザクションはLLR表に保存されますが、チェックポイント・レコードとヒューリスティック・ログはJDBC TLOGストアに保存されます。

- TLOGストアのタイプが別のタイプに変更されたり、場所が別の場所に変更される場合、変更内容は再起動後にのみ有効となり、古いストア内に保留中のすべてのトランザクションは新しいストアにコピーされません。TLOGストアのストア・タイプまたは場所を変更する前に、保留中のトランザクションがないことを確認する必要があります。

- JDBC TLOGストアが使用できない場合、JTAの正常性状態はFAILEDに遷移し、あらゆるグローバル・トランザクションは失敗します。同様に、サーバーのライフサイクルもFAILEDに変更されます。JTAトランザクション・リカバリ・システムは、可能な場合は一時的なランタイム・エラーからの復旧を試行し、インダウト・トランザクションを解決します。「JDBC TLOGストア使用時のサーバー移行」を参照してください。

- TLOGの保存に使用されるデータベースが破損しているため復旧できない場合、保留中のトランザクション情報はすべて失われます。

- JDBC TLOGストアによって使用されるデータベースの表または行がなんらかの理由でデータベース内でロックされている場合、データベース管理者が手動でこのロック状態を解除する必要があります。これを行わないと、JTAサブシステムはブロックされ、ロックを解除するまで一時停止状態となります。また、ロックによる例外が発生します。JTAサブシステムは、ロックを解除するか、またはMaxRetrySecondsBeforeTLOGFailの値が超過するまで、正常に実行されません。

注意:
ロックされたローカル・トランザクションに関する機能は、データベースの種類によって異なります。一部のデータベースでは、データベースのロック状態をただちに解決することが難しい場合があります。アプリケーション環境で基本的な行ロックの問題が発生する場合は、詳細情報についてデータベース管理者に連絡する必要があります。

JDBC TLOGストア使用時のサーバー移行

WebLogic Serverでは、JDBC TLOGストアの使用時にトランザクション・リカバリ・サービスの移行について、手動および自動の両方で実行する機能をサポートしています。JDBC TLOGストアによって使用されるデータ・ストアは、プライマリ・サーバー・インスタンスとバックアップ・サーバー・インスタンスの両方でターゲットにする必要があります。クラスタ内のすべてのサーバー・インスタンスをデータ・ソースのターゲットに指定することをお勧めします。詳細は、『Oracle WebLogic Server JTAのプログラミング』のサーバーに障害が発生した後のトランザクションのリカバリに関する項を参照してください。

JDBC TLOGストアの監視

トランザクション・ログ・ストアの統計および開かれている各ストア接続の統計情報をモニターできます。永続ストアを監視する方法の詳細については、「永続ストアのモニター」を参照してください。

JDBC TLOGストアの正常性状態を監視する方法

WebLogic ServerでJDBC TLOGストアを使用するように構成すると、次の形式の名前を使用して重要ではないサブシステムとしてストアは正常性管理システムに登録されます。

PersistentStore.TLOG_servername

ここで、servernameは、プライマリTLOGストアをホストしているWebLogic Server インスタンスの名前を示します。

管理コンソールでJDBC TLOGストアの正常性状態を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のサーバーの正常性の監視に関する項を参照してください)。

トランザクション・ログ・ストア統計情報を監視する方法

管理コンソールでトランザクション・ログ・ストア統計情報を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のサーバーのトランザクション・ログ統計情報の表示に関する項を参照してください)。

トランザクション・ログ・ストア接続を監視する方法

管理コンソールでトランザクション・ログ・ストア接続を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のTLOGストア接続の統計情報の表示に関する項を参照してください)。

セキュリティの考慮事項

JDBC TLOGストア表をはじめ、アプリケーション環境は適切に保護します。これを怠ると、次の現象が発生する可能性があります。

- 悪意を持って、あるいは意図せずに情報を削除します。このような削除によって、トランザクション情報が損失し、影響を受けるグローバル・トランザクションがヒューリスティックに完了されます。

- 悪意を持って、あるいは意図せずに情報を改変します。このような改変によって、予期しない動作が発生する可能性があります。

- トランザクションの開始時や関与するリソース情報などの機密トランザクション情報を読み取ります。

- データベース・インスタンスやデータベース・マシンにアクセスします。

- JTAとデータベース間のネットワークにアクセスし、データの妨害、閲覧、または改変などが行われる可能性があります。

第6章「セキュリティの考慮事項」を参照してください。

JDBCストアの使用

次の項では、JDBCストアの例を示し、既存のDDL、カスタムDDLを使用したJDBCストア用のデータベースの作成について説明します。DDLファイルでOracle blobレコード列を使用にする方法について説明します。

デフォルトのJDBCStoreMBeanパラメータを直接変更してJDBCストアを作成できます。管理コンソールを使用してJDBCストアを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成を参照してください。

JDBCストアで接頭辞を使用する場合の構成ガイドライン、およびJDBCデータ・ソースの推奨設定については、「JDBCストアの構成のガイドライン」を参照してください。

JDBCストアを構成する主な手順

JDBCストアを作成するための主な手順は次のとおりです。

1. JDBCストアへのインタフェースとなるJDBCデータ・ソースまたはマルチ・データ・ソースを作成します。

2. JDBCストアを作成し、これをJDBCデータ・ソースまたはマルチ・データ・ソースに関連付けます。

3. 接頭辞オプションに、構成するJDBCストア表ごとに1つの一意の値を構成することを強くお勧めします。

4. JDBCストアを使用するサブシステムに、JDBCストアを関連付けます。

- JMSサーバーの場合は、「構成:全般」ページでJDBCストアを選択します。

- ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでJDBCストアを選択します。

- パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

JDBCストアの例

ドメインの構成ファイルでのJDBCストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。

<jdbc-store>
<name>SampleJDBCStore</name>
<target>yourserver</target>
<data-source>MyDataSource</data-source>
<logical-name>Baz</logical-name>
</jdbc-store>

表6-4に、JDBCストアの変更可能な構成パラメータを示します。

表6-4 JDBCストアの構成オプション

オプション

必須

機能

名前

はい

JDBCストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。

ターゲット

はい

JDBCストアをターゲット指定するサーバー・インスタンスまたは移行可能ターゲット。複数のサブシステムが同じサーバー・インスタンスまたは移行可能なターゲットをターゲット指定していれば、これらのサブシステムで同じJDBCストアを共有できます。

注意: JMSサービスで移行可能なターゲットを使用する場合は、JDBCストアをJMSサービスで使用するのと同じ移行可能なターゲットにターゲット指定する必要があります。『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。

データ・ソース

はい

ストアのデータベース表(WLStore)にアクセスするために、このJDBCストアによって使用されるJDBCデータ・ソースまたはマルチ・データ・ソース。このデータ・ソースまたはマルチ・データ・ソースは、JDBCストアと同じサーバー・インスタンスにターゲット指定される必要があります。

注意:グローバル(XA)トランザクションをサポートするように構成されたJDBCデータ・ソースは指定できません。したがって、指定されたJDBCデータ・ソースは非XA JDBCドライバを使用する必要があります。また、このデータ・ソースで「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を有効にすることはできません。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

接頭辞名

いいえ

通常、JDBCストアの表の接頭辞は[[[catalog.]schema.]prefix]というフォーマットで指定します。

複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。また、2つのJDBCストアで同じデータベース表を共有することはできません。詳細は、「JDBCストアでの接頭辞の使い方」を参照してください。

既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

論理名

いいえ

必要に応じて、EJBなどのWebLogic Serverサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。

DDLファイルからの表の作成

いいえ

JDBCストアのデータベース表(WLStore)を作成するために、オプションで、サポートされるDDLファイルで使用されます。JDBCストアのデータベース表がすでに存在する場合は、このオプションは無視されます。詳細は、「デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。

管理コンソールを使用してJDBCストアを構成する手順は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成を参照してください。

サポートされるJDBCドライバ

JDBCストアを使用する場合、JDBCドライバを介してアクセスできるデータベースであればバッキング・データベースにできます。WebLogic Serverでは、サポートされるデータベース用の一部のドライバが自動的に検出されます。

これらのデータベースごとに対応するDDL (データ定義言語)ファイルがあり、MW_HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jarファイル内のweblogic/store/io/jdbc/ddlディレクトリに格納されています。MW_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。

表6-5 サポートされるJDBCドライバと対応するDDLファイル

データベース

DDLファイル

IBM DB2

db2.ddl
db2v6.ddl

Informix

informix.ddl

Microsoft SQL (MSSQL) Server

mssql.ddl

MySQL

mysql.ddl

Oracle

oracle.ddl
oracle_blob.ddl
oracle_blob_securefile.ddl

Sybase

sysbase.ddl

DDLファイルは、JDBCストアのデータベース表(WLStore)を作成するためのSQLコマンド(末尾がセミコロン)を含むテキスト・ファイルです。したがって、このリストに含まれていないデータベースを使用する場合は、そのデータベースに合わせて既存のDDLファイルを編集します。詳細は、「カスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。

デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成

「JDBCストア構成」ページには「DDLファイルからの表の作成」オプションがあります。このオプションを使用してJDBCストアのバッキング表(WLStore)の作成に使用する構成済のDDLファイルにアクセスできます。JDBCストアのバッキング表がすでに存在する場合、このオプションは無視されます。このオプションを使用するのは、未サポートのデータベース用に作成したカスタムDDLファイルを指定する場合や、以前のリリースのJMS JDBCストア表を最新のJDBCストア表にアップグレードする場合などです。

「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されておらず、バッキング表が存在しないことがJDBCストアによって検出されると、データベース・ベンダー固有の構成済DDLファイルが実行され、自動的に表が作成されます(「サポートされるJDBCドライバ」を参照してください)。

「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されており、バッキング表が存在しないことがJDBCストアによって検出されると、まずファイル・パスに指定したDDLファイルが検索され、見つからない場合はCLASSPATH内のDDLファイルが検索されます。ファイルが見つかった時点で、DDLファイル内のSQLが実行され、JDBCストアのバッキング表が作成されます。構成済のファイルが見つからず、既存の表も存在しない場合、JDBCストアは起動に失敗します。

カスタムDDLファイルを使用したJDBCストア表の作成

「サポートされるJDBCドライバ」のリストにないデータベースを使用する場合は、既存のDDLテンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。

1. JDKで用意されているJARユーティリティを使用すると、次のコマンドでDDLファイルを/weblogic/store/io/jdbc/ddlディレクトリに抽出できます。

jar xf com.bea.core.store.jdbc_1.0.0.0.jar /weblogic/store/io/jdbc/ddl

注意:
weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。

2. 使用しているデータベースに合わせてDDLファイルを編集します。SQLコマンドは複数行にわたって指定できます。末尾にはセミコロン(;)を付けます。シャープ記号(#)で始まる行はコメントです。

3. 変更を保存し、新しいDDLの名前を適切な名前に変更します(例: mydatabase.ddl)。

4. Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成の説明に従って、JDBCストアを作成します。

5. 「構成」ページの「DDLファイルからの表の作成」オプションを使用して、カスタムDDLファイルを指定します(例: /mydatabase.ddl)。

注意:
Windowsシステムの場合、フルパス名には必ずドライブ文字を含めます。

Oracle BLOBレコード列の有効化

Oracleデータベースの場合は、oracle_blob.ddlファイルまたはoracle_blob_securefile.ddlファイルを使用してレコード列のタイプがデフォルトのLONG RAWタイプではなく、BLOBレコード列タイプのJDBCストア表を作成できます。oracle_blob.ddlは、Oracleベーシック・ファイルのBLOBの作成に使用され、oracle_blob_securefile.ddlファイルはOracleセキュア・ファイルのBLOBの作成に使用されます。両方のファイル・タイプは、「サポートされるJDBCドライバ」に示すように、WebLogic CLASSPATHにあらかじめ構成されています。

Oracle Database 11gリリース2には、セキュア・ファイル用のゼロ・コピーI/Oパフォーマンス機能改善およびBLOB用の論理キャッシュが含まれます。これらの機能改善を使用すると、メッセージ・サイズが大きい場合やデータベースへのネットワーク接続速度が遅い場合に、JDBCストアによるスループットを向上できます。Oracle LONG RAWデータ型は、データベースへの接続速度が速い場合に、BLOBSよりも通常はパフォーマンスが高くなります。

注意:
すでにOracleのLONG RAW列に入っているデータを保持する必要がある場合は、この方法でBLOBに切り替えないようにしてください。このような場合は、SQL ALTER TABLEコマンドに関するOracleドキュメントを参照してください。

JDBCストアでOracle BLOB DDLを使用するには

1. JDBCストアを使用するサーバー・インスタンスを停止します。

2. 「JDBCストア表の管理」の説明に従って、現在のJDBC表を削除します。

3. サーバー・インスタンスを再起動します。

4. Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成の説明に従って、新しいJDBCストアを作成します。

5. 「全般的な構成」ページの「DDLファイルからの表の作成」フィールドで、次の場所を入力します。

- oracle_blob.ddlファイルは、/oracle_blob.ddl

- oracle_blob_securefile.ddlファイルは、/oracle_blob_securefile.ddl

6. 「完了」をクリックすると、JDBCストアのバッキング表が作成されます。

Oracle BLOBSの使用時に、ThreeStepThresholdの値を調整するとパフォーマンスを向上できる場合があります。

JDBCストア・スキーマには、Oracle BLOB列(ベーシック・ファイルまたはセキュア・ファイル)が含まれ、JDBCストアによって、BLOBデータのサイズに基づいて次の実装のいずれかを使用してBLOBデータが自動的に設定されます。

- JDBCストアによって、1回の手順でBLOBデータを含む行がストア表に直接挿入されます。関与するのが1回の手順のみであるため、JDBC一括挿入も採用されており、データ・サイズが小さい場合はこの方法が最高のパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値以下の場合に使用されます。

- JDBCストアによって、Oracle LOB APIを使用して、3段階でBLOBデータを含む行がストア表に直接挿入されます。この実装は、データ・サイズが大きい場合に良好なパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値より大きい場合に使用されます。

ThreeStepThresholdのデフォルト値は200Kです。

JDBCストア表の管理

JDBC utils.Schemaユーティリティを使用すると、既存のバージョンを削除することで新しいJDBCストア・データベース表(WLStore)を再生成できます。通常、この表は自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存のJDBCストア・データベース表に障害が発生した場合は、utils.Schemaユーティリティを使用して削除できます。

utils.SchemaユーティリティはJavaプログラムで、以下の項目を指定するコマンド・ライン引数をとります。

- JDBCドライバ

- データベース接続情報

- データベース表を作成するSQLデータ定義言語(DDL)コマンドを含むファイルの名前

utils.Schemaユーティリティを使用したJDBCストア表の削除

utils.Schemaコマンドを次のように入力します。

$ java utils.Schema url JDBC_driver [options] DDL_file

注意:
utils.Schemaを実行するには、CLASSPATHにweblogic.jarファイルを指定する必要があります。

表6-6にutils.Schemaのコマンド・ライン引数を示します。

表6-6 utils.Schemaのコマンド・ライン引数

引数

説明

url

データベース接続URL。この値は、JDBC仕様の定義に従ってコロン区切りのURLにします。

JDBC_driver

JDBCドライバ・クラスの完全パッケージ名。

options

省略可能なコマンド・オプション。

データベースの必要に応じて、以下のものを指定します。

- ユーザー名とパスワードを次のように指定します。

-u <username> -p <password>

- JDBCデータベース・サーバーのドメイン・ネーム・サーバー(DNS)名。次のように指定します。

-s <dbserver>

-verboseオプションも指定可能です。このオプションを指定すると、utils.Schemaは実行時にSQLコマンドをエコーします。

DDL_file

実行するSQLコマンドが記されたDDLテキスト・ファイルのフルパス名。詳細は、「サポートされるJDBCドライバ」を参照してください。

たとえば、次のコマンドでは、ユーザー名user1、パスワードfoobarで、OracleサーバーDEMOのMYWLStoreというJDBC表が削除されます。

$ echo "drop MYWLStore;" > drop.ddl

$ java utils.Schema
jdbc:weblogic:oracle:DEMO \
weblogic.jdbc.oci.Driver -u user1 -p foobar -verbose \
drop.ddl

JDBCストアの構成のガイドライン

次の項では、JDBCストアの接頭辞を使用する場合のガイドライン、JDBCストア用のWebLogic JDBCデータ・ソースの推奨設定、およびJDBCストアを使用したJMSトランザクションの処理について説明します。

JDBCストアでの接頭辞の使い方

JDBCストア・データベースには、WLStoreというデータベース表が含まれます。このデータベース表は、WebLogic Serverによって自動的に生成され、内部的に使用されます。JDBCストアには任意指定の接頭辞名パラメータがあり、これを使用するとより正確にデータベース表にアクセスできます。

特に次のような場合、JDBC WLStore表名用に接頭辞を構成するのがベスト・プラクティスです。

- データベースに完全修飾名を指定する必要がある場合(データベース管理者に要確認)。

- 複数のJDBCストアが同じ表を共有できないため、1つのデータベースを複数のJDBCストアのインスタンスで共有している場合。

- データベースに多くの表が含まれている場合。接頭辞を設定することで、起動時にJDBCストアが検索する必要のある表の数が減少します。

JDBCストア表の規則

データ損失を避けるため、次の規則に従ってください。

- JDBCストアの各表名は一意である必要があります。

- 1つの表を複数のJDBCストアが共有すると、動作が不安定となり、データ損失のおそれがあります。

- 2つのデータベース表を1つの表に結合する方法はありません。

接頭辞名のフォーマットのガイドライン

ほとんどのデータベースでは、JDBCストアのバッキング・データベース表の接頭辞名オプションを、構成したJDBCストアごとに次のフォーマットで設定する必要があります。これにより、JDBCストア表名の前に付加されたときに、有効な表名になります。

[[[catalog.]schema.]prefix]

[[[catalog.]schema.]prefix]フォーマット内の各ピリオド記号は重要です。通常、catalogはDBMSが参照するシステム表のセットを識別し、schemaは表オーナー(username)のIDに対応します。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。

たとえば、データベース管理者は、次のように本番データベースで販売部門用の固有の表を管理できます。

[[[Production.]JMSAdmin.]Sales]

この場合、表はJMSAdminスキーマによって本番カタログ内に作成され、SalesWLStoreという名前になります。

Oracleなどの一部のDBMSベンダーの場合、設定または選択するカタログがないので、このフォーマットは[[schema.]prefix]となります。詳細は、お使いのDBMSのドキュメントで表の完全修飾名に関する説明を参照してください。ただし、そのDBMSで指定されている構文が、このオプションに必要なフォーマットとは異なる場合があることに注意します。

警告:
WLStore表がすでにデータベース内にある状態で接頭辞名の設定を変更した場合は、既存の表のデータの保持の面で注意が必要です。この場合、データベース管理者が既存のデータベース表の名前を変更して、新たに構成した表の名前に一致させる必要があります。

JDBCストア用のJDBCデータ・ソースの推奨設定

JDBCストアにJDBCデータ・ソースまたはマルチ・データ・ソースを使用する場合は、以下の設定を推奨します。

障害が発生したデータベースへの自動再接続

WebLogic Serverには、堅牢なJDBCデータ・ソースが用意されています。JDBC接続プールでは、障害が発生したデータベースがオンラインに復旧した場合、WebLogic Serverを再起動しなくても、自動的にこのデータベースとの再接続を確立できます。この機能を活用し、JDBCストアをより堅牢なものとして使用するには、JDBCストアに関連付けられているJDBCデータ・ソースの次のオプションを構成します。

TestConnectionsOnReserve="true"
TestTableName="SYSTABLES"
ConnectionCreationRetryFrequencySeconds="600"

JDBCのデフォルトのテスト対象の表名の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のデータソースの接続テスト・オプションを参照してください。データベースを再接続する試行回数の設定は、『Oracle WebLogic Server JDBCの構成と管理』の接続作成の再試行の有効化を参照してください。

Oracle DB2 Type 4 JDBCドライバの必要設定

JDBCストアとして使用するデータ・ソースでDB2用のOracle Type 4 JDBCドライバを使用する場合は、JMSの内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaroundプロパティを「true」に設定する必要があります。

詳細は、『Oracle WebLogic Server Type 4 JDBCドライバ』のパフォーマンスに関する項を参照してください。

JDBCストアを使用したJMSトランザクションの処理

JDBCストアは、グローバル(XA)トランザクションをサポートするように構成されたJDBCデータ・ソースを使用するように構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。また、このデータ・ソースで「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を有効にすることはできません。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

JDBCストアは、XAResourceインタフェースを実装しているため、JDBCストア自体のリソース・マネージャとして動作し、JDBCドライバ・レベルより上位のトランザクションを処理します。つまり、ストア自体がXAResourceを実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理します。

このため、JDBCストアとデータベース(JMSメッセージが格納されているデータベースと同じ場合でも)を使用する場合、それは常に2フェーズ・コミット・トランザクションになります。

JDBCストアでのJMSトランザクションの使用の詳細は、『Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSでのトランザクションの使い方を参照してください。

パフォーマンスは、以下の方法で向上させることもできます。

- データベース作業に使用するJDBCデータ・ソースを、JMS宛先と同じサーバー上に配置します。この場合、トランザクションは依然として2フェーズですが、より小さいネットワーク・オーバーヘッドで処理されます。

- JDBCストアの代わりにファイル・ストアを使用します。

- 通常同じトランザクション内で呼び出されるサービスが複数あれば、これらのサービスが同じストアを共有するように構成します。

- データベース操作を直接実行するアプリケーションで、同じトランザクション内のストア・サービス(JMSなど)が呼び出される場合は、データベース操作用にロギング・ラスト・リソース(LLR)を有効にしたJDBCデータ・ソースを使用することを検討します。
LLRによる最適化を使用すると、トランザクションは2フェーズ・コミット・プロトコルに従いますが、データベース操作は単一のローカル・トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLRによる最適化の使用の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。

JDBCストアのI/Oマルチスレッド処理の有効化

JDBCストアのI/O負荷が重い環境の場合、複数のJDBC接続を使用して同時にI/O処理を実行するようにJDBCストアを構成すると、パフォーマンスを向上できます。

注意:
付加が軽い環境でI/Oマルチスレッド処理を有効化すると、実際にはパフォーマンスが低下する場合があります。アプリケーションを適切に調整することをお勧めします。

I/Oマルチスレッド処理を有効化するには、Worker Count属性を1より大きい整数値に設定します。構成プロパティのデフォルト値は1で、この状態ではオプションは無効になっています。Worker Count属性によって、JDBCストアがI/Oの処理に使用するワーカー・スレッド数が指定されます。各ワーカー・スレッドによって、ストアの開放時に構成済のデータ・ソース・プールからJDBC接続が1つ取得されます。多くの場合、マルチスレッド処理の利点は同時実行スレッド数が4つを超えると減少する傾向にあります。データベースへの接続速度が遅い場合、マルチスレッド処理によってパフォーマンスが向上しない場合があります。

注意:
Worker Countを接続プールで使用可能な接続数が足りない値に設定すると、JDBCストアの開放に失敗します。

Worker Preferred Batch Size属性の値を変更すると、各ワーカー・スレッドの作業負荷を調整できます。この属性値を増加すると、各ワーカー・スレッドに割り当てられる作業負荷が徐々に増加します。作業負荷はストアのI/Oリクエストから構成されます。これらのリクエストはグループ化され、処理のために各JDBCワーカー・スレッドにプッシュされます。各I/Oリクエストのサイズが共通して非常に大きい場合(1 MBのJMSメッセージを保存するリクエストなど)、Worker Preferred Batch Sizeの値を小さく調整してパフォーマンスを向上させます。

Oracle Database用ストア表索引の再構築

I/Oマルチスレッド処理を有効にすると、ストアI/O処理を同時に実行するために複数のJDBC接続が使用されます。この結果、データベース・リソースの競合が発生する可能性があります。Oracle Database上の競合を低減するには、I/Oマルチスレッド処理の使用時に主キー索引をリバース・キー索引に再構築することをお勧めします。I/Oマルチスレッド処理を使用してから無効にする場合、主キー索引を非リバース・キー索引に再構築することをお勧めします。リバース・キー索引に関する詳細については、『Oracle Databaseの概念』の索引および索引が整理された表に関する項を参照してください。

次の基本手順を実行し、Oracle Database用ストア表索引を再構築します。

1. ストア・スキーマ名の下にあるOracle Databaseにログインします。ストア・スキーマ名は、データ・ソース・ユーザー名と同じでも異なっていても有効です。

2. 『Oracle Database用リバース索引の構築』または「Oracle Database用非リバース索引の構築」に記載したPL/SQLスクリプトを使用し、必要に応じてストア表索引を再構築します。「JDBCストアでの接頭辞の使い方」で説明したように、各スクリプトの<Store Table Name>をストア表名に置き換えます。PL/SQLの詳細については、Oracle DatabaseコンセプトのPL/SQLサブプログラムの実行に関する項を参照してください。

注意:
リバース索引はI/Oマルチスレッド処理に使用し、非リバース索引はシングル・スレッドI/Oに使用することをお勧めします。

Oracle Database用リバース索引の構築

ストア表索引をOracle Database用リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。

declare
idx           user_ind_columns.index_name%TYPE;
alter_stmt    VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild reverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/

Oracle Database用非リバース索引の構築

ストア表索引をOracle Database用非リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。

declare
idx           user_ind_columns.index_name%TYPE;
alter_stmt    VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild noreverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/

非Oracle Databaseでの競合の低減

非Oracle Databaseで競合を低減する方法については、データベース・プロバイダーのドキュメントを参照してください。

永続ストアのモニター

既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニターできます。

ストアのモニター

各永続ストアは、実行時にはPersistentStoreRuntimeMBeanインスタンスによって表わされます。次のオプションが用意されています。

表6-7 永続ストアの実行時オプション

オプション

機能

CreateCount

この永続ストアに対して発行された作成リクエストの数

ReadCount

この永続ストアに対して発行された読込みリクエストの数

UpdateCount

この永続ストアによって発行された更新リクエストの数

DeleteCount

この永続ストアによって発行された削除リクエストの数

ObjectCount

この永続ストアに含まれるオブジェクトの数

Connections

この永続ストアのアクティブな接続の数

PhysicalWriteCount

永続ストアがそのデータを恒久ストレージにフラッシュした回数

ストア接続のモニター

永続ストアは、開かれている各永続ストア接続についてもPersistentStoreConnectionRuntimemMBeanを登録します。以下のオプションが用意されています。

表6-8 永続ストア接続の実行時オプション

オプション

機能

CreateCount

この接続に対して発行された作成リクエストの数

ReadCount

この接続に対して発行された読取りリクエストの数

UpdateCount

この接続によって発行された更新リクエストの数

DeleteCount

この接続によって発行された削除リクエストの数

ObjectCount

この接続に含まれるオブジェクトの数

表6-9に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムのランタイム接頭辞名の大部分を示します。

表6-9 永続ストアのランタイム接頭辞名

サブシステム/サービス

ランタイム接頭辞名

デプロイメント

weblogic.deploy.internal

internalはデプロイメント接続の名前

診断サービス

weblogic.diagnostics.internal

internalは診断アーカイブ接続の論理名

EJBタイマー・サービス

weblogic.ejb.timer.internal

internalは、サーバー・インスタンス内で一意に特定されるEJBデプロイメント

JMSサービス

JMSサーバー

weblogic.messaging.jmsServer.internal

internalはJMSサーバー接続の名前

JMS恒久サブスクライバ

weblogic.messaging.jmsServer.durablesubs.internal

internalは恒久サブスクライバ接続の名前

JTAトランザクション・ログ(TLOG)

weblogic.transaction.internal

internalはTLOG接続の名前

パス・サービス

weblogic.messaging.PathService.internal

internalはパス・サービス接続の名前

SAFサービス

SAFエージェント

weblogic.messaging.SAFAgent@server1.internal

internalはSAFエージェント接続の名前

SAF恒久サブスクライバ

weblogic.messaging.SAFAgent@server1.durablesubs.internal

internalは恒久サブスクライバ接続の名前

Webサービス

weblogic.wsee.server.store.internal

internalはWebサービス接続の名前

永続ストアの管理

WebLogicストア管理ユーティリティを使用すると、管理者はWebLogic永続ストアのトラブルシューティングを行うことができます。ストア・ユーティリティは、実行中のサーバー・インスタンスによって現在開かれていないストアのみで動作します。このユーティリティは、Javaコマンド・ラインまたはWebLogic Scripting Tool(WLST)から実行できます。詳細は、「Javaコマンド・ラインを使用したストアの管理」および「WLSTを使用したストアの管理」を参照してください。

ストア管理の最も一般的な使用例は、サイズを減らすためにファイル・ストアを圧縮する場合や、トラブルシューティングを目的としてファイル・ストアまたはJDBCストアの内容をXMLファイルにダンプする場合です。これらの使用例については後ほど説明します。

表6-10に、JavaおよびWLSTで使用できるストア管理コマンドを示します。

表6-10 永続ストアの管理オプション

Javaコマンド

WLSTメソッド

機能

help

helpstore

使用できるコマンド、使用方法、使用例を表示します。

compact

compactstore

ファイル・ストアによって占有されているスペースを圧縮およびデフラグします。このコマンドはオフラインでのみ機能し、JDBCストアには使用できません。

注意:ファイル・ストアの圧縮は、通常、ファイル・ストアが再び現在のサイズになるとわかっている場合は必要ありません。ファイル・ストアは、削除したレコードによって解放されたスペースを自動的に再利用し、新しいレコードに対して内部スペースが足りない場合にのみ展開します。また、ファイル・ストアは通常、ほとんどの永続レコードは存続期間が短いため、断片化されません。

openfile

openfilestore

それ以降の処理のために既存のファイル・ストアを開きます。ファイル・ストアが存在しない場合は、-createパラメータに基づいて、開かれた状態の新しいファイル・ストアが作成されます。

openjdbc

openjdbcstore

それ以降の処理のために既存のJDBCストアを開きます。JDBCストアが存在しない場合は、開かれた状態の新しいJDBCストアが作成されます。

dump

dumpstore

ストアまたは接続の内容を、人間が読取れる形式でユーザー指定のXMLファイルにダンプします。XMLファイルの形式は、永続ストアの診断イメージで使用する形式と同じです。

list

liststore

ストア名、開かれているストア、またはストア内の接続を一覧表示します。

n/a

getstoreconns

指定したストア内の接続のリストを戻します(スクリプト・アクセス用)。

n/a

getopenstores

開かれているストアのリストを戻します(スクリプト・アクセス用)。

opts

n/a

ストア管理ツールの呼出しオプションを一覧表示します。

verbose

n/a

追加情報(スタック・トレースなど)の表示を制御します。

close

closestore

開かれているストアを閉じます。

quit

exit

ストア管理セッションを終了します。

永続ストアは、ファイル・システム(ファイル・ストア)またはJDBC対応のデータベース(JDBCストア)によってバッキングできます。openfile/openfilestore()オプションとopenjdbc/openjdbcstore()オプションを除けば、これら2種類のストアを操作するオプションに違いはありません。

ほとんどのコマンドとメソッドはストア名に対して実行でき、それ以外のコマンドやメソッドも接続名に対して実行できます。ストア接続は、永続ストア内のレコードの論理グループです。たとえば、JMSおよびJTAサブシステムでは、それぞれに対応するレコードが同じファイル・ストア内の別々の接続に永続化されます。

Javaコマンド・ラインを使用したストア管理

Javaコマンド・ラインから永続ストア管理ユーティリティを起動するには、次のように入力します。

> java weblogic.store.Admin
> storeadmin->

ストア管理ヘルプの使用

helpと入力すると、使用できるストア管理コマンドの詳細な説明と、典型的なコマンド使用例が表示されます。次に示す例は、ストア名、開かれているストア、またはストア内の接続を一覧表示するlistコマンドについての包括的なヘルプです。

storeadmin->help list
Command:
list
Description:
lists store names, open stores, or connections in a store
Usage:
list [-store storename|-dir dir]
Examples:
list #lists all opened stores by storename
list -store store1 #lists all connections in store1
list -dir dir1 #lists all storenames found in dir1

ファイル・ストアの内容のダンプ

ここでは、一連のストア管理コマンドを使用して、myfilestoreに指定したファイル・ストアの内容を、人間が読取れるXMLファイル形式で一時ディレクトリにエクスポートする例を示します。この例では、ストアの接続名や実際のレコードの内容はダンプされません。これらをダンプするには、-connパラメータや-deepパラメータを指定する必要があります。

> storeadmin-> list -dir .
> storeadmin-> openfile -store myfilestore -dir .
> storeadmin-> dump -store myfilestore -out d:\tmp\filestore1-out
> storeadmin-> close -store myfilestore

listコマンドは、現在のディレクトリ内にあるすべてのストア名を表示します。dumpやlist (開かれているストアを一覧表示する場合のみ)などの管理機能を呼び出す前に、まずopenfileコマンドやopenjdbcコマンドを実行してファイルやJDBCストアを開く(または作成して開く)必要があります。開かれているストアの管理操作が完了したら、closeコマンドでストアを閉じる必要があります。

ファイル・ストアの圧縮

ここでは、mystoresディレクトリ内でファイル・ストアによって占有されるスペースを、compactコマンドを使用して圧縮する例を示します。

> storeadmin->compact -dir c:\mystores -tempdir c:\tmp

compactコマンドは、開かれていないファイル・ストアに対してのみ実行できます。-dirソース・ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース・ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース・ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア・ファイルがmystoresディレクトリに格納されます。さらに、tmpディレクトリの下に一意の名前の新しいディレクトリが作成され、圧縮前のストア・ファイルが格納されます。

WLSTを使用したストア管理

WLSTインタフェースには、Javaコマンド・ラインにはないメソッドがいくつか用意されています。たとえば、関連するJavaオブジェクトを戻し、WLSTのスクリプトで使用できるgetopenstoresおよびgetstoreconnsなどです。

注意:
このリリースでは、WebLogic Scripting Tool (WLST)をオフラインで使用する場合には、ThreeStepThreshold、Worker CountおよびWorker Preferred Batch Sizeはサポートされません。

ストア管理ヘルプの使用

WLSTから永続ストア管理ユーティリティにアクセスするには、次のように入力します。

> java weblogic.WLST

helpstore()と入力すると、使用できるストア管理コマンドの詳細な説明と、典型的なコマンド使用例が表示されます。次に示す例は、ストア名、開いているストア、またはストア内の接続を一覧表示するlistコマンドについてのヘルプです。

> wls:/offline> helpstore(liststore)
lists storenames, opened stores, or connections (for interactive access)
Parameters store and dir cannot both be specified concurrently.

Usage: liststore(store='null',dir='null')

@param store [optional] a previously opened JDBC or File store's name.
If store is specified, all connections in the store are listed.
@param dir [optional] directory for which to list available store names
If dir is specified, all store names in the directory are listed.

If neither store nor dir are specified, all open store names are listed.
@return 1 on success, 0 on failure

なお、等号記号「=」が付いているパラメータは省略可能です。たとえば、compactstoreメソッドは、compactstore(dir='storename', tempdir='/tmp')のように呼び出すこともできますが、compactstore(store='storename')のように呼び出してtempdirのデフォルト値を使用することもできます。省略可能なパラメータのデフォルト値は、コマンド固有のヘルプに一覧表示されます。

WLSTを使用したJDBCストアの内容のダンプ

ここでは、dumpstoreメソッド(store、outfile、conn='null'、deep='false')を使用して、myJDBCStoreというJDBCストアの内容を、人間が読めるXMLファイル形式でmystoredump-out.xmlというファイルにエクスポートする例を示します。この例では、ストアの接続名や実際のレコードの内容はダンプされません。これらをダンプするには、オプションのconnとdeepパラメータを指定する必要があります。

> wls:/offline>
(openjdbcstore('myJDBCStore', 'oracle.jdbc.OracleDriver',
'jdbc:oracle:thin:@test2k31:1521:test120a', './wlstoreadmin-dump.props',
'jmstest', 'jmstest', '', 'jdbcstoreprefix')
dumpstore('myJDBCStore', 'mystoredump-out')
closestore('myJDBCStore')

dumpstoreやliststore (開かれているストアを一覧表示する場合のみ)などの管理機能を呼び出す前に、まずopenjdbcstoreメソッドやopenfilestoreメソッドを使用してストアを開く(または作成して開く)必要があります。開かれているストアの管理操作が完了したら、closestoreコマンドでストアを閉じる必要があります。

WLSTを使用したファイル・ストアの圧縮

ここでは、compactstoreメソッド(dir,tempdir='null')を使用してmystoresディレクトリ内でファイル・ストアのファイルによって占有されるスペースを圧縮するWLSTスクリプトの例を示します。

> wls:/offline> compactstore('c:\mystores','c:\tmpmystore.dir')

compactstore()メソッドは、開かれていないファイル・ストアに対してのみ使用できます。「dir」ソース・ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース・ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース・ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア・ファイルがmystoresディレクトリに格納されます。さらに、tmpmystoreディレクトリの下に一意の名前の新しいディレクトリが作成され、圧縮前のストア・ファイルが格納されます。

セキュリティの考慮事項

ファイル・ストア・データのセキュリティを確保するには、すべてのファイル・ストア・ディレクトリに適切なディレクトリ許可を設定する必要があります。データの暗号化が必要な場合は、適切なサード・パーティ暗号化ソフトウェアを使用する必要があります。

永続ストアの制限事項

永続ストアには以下の制限があります。

- 永続ファイル・ストアは、2つのサーバー・インスタンスから同時に開くことはできません。同時に開くと、ファイル内のデータが破損するおそれがあります。永続ストアは、同時に開かれたことが検知できたときにはエラーを戻そうとしますが、この状態が必ず検知できるとは限りません。管理者の責任において、複数のサーバーが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください(名前とディレクトリが同じ2つのファイル・ストアは「同じストア」とみなされます)。

- データが破損するので、2つのJDBCストアで同じデータベース表を共有することはできません。

- 永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。

- ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。

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