Cosminexus　機能解説

解説書

3020-3-M03-60

目　　次

前書き

変更内容

はじめに

第1編　概要

1.　Application Serverの概要

1.1　Application Serverとは

1.1.1　アプリケーション実行基盤としての機能

1.1.2　システムの構築を支援する機能

1.1.3　システムの運用を支援する機能

1.1.4　ほかのプログラムと連携する機能

1.2　J2EEアプリケーションを実行するアプリケーションサーバのプロセス

1.2.1　J2EEアプリケーションを実行する場合のプロセス構成

1.2.2　J2EEサーバの構成

1.2.3　J2EEアプリケーションとJ2EEコンポーネント

1.2.4　J2EEコンテナ

1.2.5　J2EEサービス

1.2.6　J2EEリソース

1.2.7　コンテナ拡張ライブラリ

1.2.8　サーバの動作モード

1.3　バッチアプリケーションを実行するアプリケーションサーバのプロセス

1.3.1　バッチアプリケーションを実行する場合のプロセス構成

1.3.2　バッチサーバの構成

1.3.3　バッチアプリケーション

1.3.4　バッチサービス

1.3.5　J2EEサービス

1.3.6　J2EEリソース

1.3.7　コンテナ拡張ライブラリ

2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）

2.1　Application Serverで提供する機能の目的

2.2　J2EEアプリケーション実行基盤の機能の概要

2.2.1　Webコンテナが提供する機能の概要

2.2.2　EJBコンテナが提供する機能の概要

2.2.3　EJBクライアントの実行機能の概要

2.2.4　J2EEアプリケーションの実行機能の概要

2.2.5　ネーミング管理が提供する機能の概要

2.2.6　リソース接続とトランザクション管理が提供する機能の概要

2.2.7　コンテナ拡張ライブラリが提供する機能の概要

2.2.8　CTMが提供する機能の概要

2.2.9　Cosminexusシステムのユーザを統合管理する機能の概要

2.3　システム構築時に使用する機能の概要

2.4　システム運用時に使用する機能の概要

2.4.1　Management Serverによる運用管理機能の概要

2.4.2　システムの日常運用を支援する機能の概要

2.4.3　システムの保守を支援する機能の概要

2.4.4　J2EEアプリケーションの運用機能の概要

2.4.5　システムの監査を支援する機能の概要

2.5　ほかのプログラムと連携する機能の概要

2.5.1　JP1連携による運用管理機能の概要

2.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

2.6　オプション製品の機能

2.6.1　uCosminexus Clientの機能概要

2.6.2　Web Redirectorの機能概要

2.6.3　uCosminexus Operatorの機能概要

2.7　旧バージョンとの互換用の機能

3.　アプリケーションサーバの機能（バッチアプリケーションを実行する場合）

3.1　Application Serverで提供する機能の目的

3.2　バッチアプリケーション実行基盤の機能の概要

3.2.1　バッチアプリケーション実行機能の概要

3.2.2　EJBアクセス機能の概要

3.2.3　ネーミング管理が提供する機能の概要

3.2.4　リソース接続とトランザクション管理が提供する機能の概要

3.2.5　ガーベージコレクション制御機能の概要

3.2.6　コンテナ拡張ライブラリが提供する機能の概要

3.3　システム構築時に使用する機能の概要

3.4　システム運用時に使用する機能の概要

3.4.1　Management Serverによる運用管理機能の概要

3.4.2　システムの日常運用を支援する機能の概要

3.4.3　システムの保守を支援する機能の概要

3.4.4　システムの監査を支援する機能の概要

3.5　ほかのプログラムと連携する機能の概要

3.5.1　JP1連携による運用管理機能の概要

3.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

第2編　J2EEアプリケーション実行基盤としての機能

4.　Webコンテナ

4.1　Webコンテナの機能

4.2　Webアプリケーションの実行

4.2.1　Webアプリケーションのデプロイとアンデプロイ

4.2.2　Webアプリケーションを実行する場合の留意事項

4.2.3　Webアプリケーションでのアノテーション指定

4.3　インプロセスHTTPサーバによるリクエストの受け付け

4.3.1　インプロセスHTTPサーバで使用できる機能

4.3.2　Webクライアントからの接続数とリクエスト処理スレッド数の制御

4.3.3　Webクライアントからの同時接続数の制御

4.3.4　Persistent Connectionによる通信制御

4.3.5　インプロセスHTTPサーバで設定できる通信タイムアウト

4.3.6　アクセスを許可するホストの制限によるアクセス制御

4.3.7　リクエストデータのサイズの制限によるアクセス制御

4.3.8　有効なHTTPメソッドの制限によるアクセス制御

4.3.9　HTTPレスポンスヘッダのカスタマイズ

4.3.10　エラーページのカスタマイズ

4.3.11　リダイレクトによるリクエストの振り分け

4.3.12　ログ・トレースの出力

4.3.13　インプロセスHTTPサーバが返すエラーステータスコード

4.4　セッション管理

4.4.1　セッション情報を管理するオブジェクト

4.4.2　セッションIDの形式

4.4.3　セッションの管理方法

4.4.4　HttpSessionオブジェクト数の上限値の設定

4.4.5　セッションIDおよびCookieへのサーバIDの付加

4.5　文字コード変換

4.6　デフォルトの文字エンコーディング設定

4.6.1　デフォルトの文字エンコーディングの設定単位

4.6.2　設定できる文字エンコーディング

4.6.3　デフォルトの文字エンコーディングの適用個所と適用条件

4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用

4.6.5　デフォルトの文字エンコーディング適用時の注意事項

4.6.6　Servlet仕様での文字エンコーディング設定

4.7　JSPの事前コンパイルとコンパイル結果の保持

4.7.1　JSP事前コンパイル機能とは

4.7.2　JSP事前コンパイルの方法

4.7.3　JSP事前コンパイルの適用例

4.7.4　JSP事前コンパイルの実行時の処理

4.7.5　JSPコンパイル結果のライフサイクルと出力先

4.7.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

4.8　アプリケーションのイベントリスナ

4.9　タグファイルの実行

4.10　JSP ELの実行

4.11　リクエストおよびレスポンスのフィルタリング

4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）

4.11.2　フィルタ連鎖の推奨例

4.12　フィルタリングによるHTTPレスポンスの圧縮

4.12.1　HTTPレスポンス圧縮フィルタの概要

4.12.2　HTTPレスポンス圧縮フィルタを使用するための条件

4.12.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

4.12.4　HTTPレスポンス圧縮機能を使用する場合のDDの定義内容

4.12.5　HTTPレスポンス圧縮機能を使用するDDの定義例

4.13　Webコンテナのセキュリティ管理

4.13.1　SSL使用による認証情報とデータの暗号化

4.13.2　ロールに基づくWebコンテナのユーザ認証

4.13.3　SecurityManagerによるWebコンテナの実行時の保護

4.14　EJBコンテナとの連携

4.14.1　Enterprise Beanの呼び出し方法

4.14.2　Enterprise Bean呼び出しの準備

4.15　データベースとの接続

4.16　Webコンテナによるスレッドの作成

4.16.1　作成するスレッドの種類と数

4.16.2　作成するスレッドの総数

4.17　同時実行スレッド数の制御

4.17.1　スレッド数を制御する単位

4.17.2　同時実行スレッド数制御のパラメタ

4.17.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

4.18　Webコンテナ単位での同時実行スレッド数の制御

4.19　Webアプリケーション単位での同時実行スレッド数の制御

4.19.1　同時実行スレッド数の制御の概要（Webアプリケーション単位）

4.19.2　Webアプリケーション単位の設定パラメタ

4.19.3　同時実行スレッド数および実行待ちキューサイズの設定例

4.19.4　同時実行スレッド数の動的変更

4.19.5　同時実行スレッド数制御の注意事項

4.20　URLグループ単位での同時実行スレッド数の制御

4.20.1　同時実行スレッド数の制御の概要（URLグループ単位）

4.20.2　URLグループ単位の設定パラメタ

4.20.3　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

4.20.4　URLパターンのマッピング処理

4.21　ユーザスレッドで使用できるApplication Serverの機能

4.22　通信タイムアウトの設定

4.22.1　リクエスト送受信時の通信タイムアウト

4.22.2　レスポンス送受信時の通信タイムアウト設定

4.23　Webサーバ（リダイレクタ）によるリクエストの振り分け

4.23.1　リダイレクタを使用したリクエスト振り分けの仕組み

4.23.2　URLパターンでのリクエストの振り分け

4.23.3　ラウンドロビン方式でのリクエストの振り分け

4.23.4　POSTデータサイズでのリクエストの振り分け

4.23.5　リダイレクタが返すエラーステータスコード

4.23.6　Webサーバ連携時の留意事項

4.24　エラーページのカスタマイズ

4.24.1　エラーページのカスタマイズの仕組み

4.24.2　エラーページカスタマイズの注意事項

4.25　ドメイン名指定でのトップページの表示

4.26　Webコンテナへのゲートウェイ情報の通知

4.27　Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレス指定

4.28　静的コンテンツのキャッシュ

4.29　簡易Webサーバ機能

4.30　Webコンテナが返すエラーステータスコード

4.31　前バージョンからのJSPの移行

4.32　サーブレット，JSPの実装

4.32.1　サーブレット，JSP実装時共通の注意事項

4.32.2　サーブレット実装時の注意事項

4.32.3　Servlet 2.4仕様で追加，変更された仕様についての注意事項

4.32.4　JSP実装時の注意事項

4.32.5　JSP 2.0仕様で追加，変更された仕様についての注意事項

4.32.6　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

4.32.7　サーブレットでのアノテーションの使用

4.32.8　カスタムタグのスクリプト変数の定義に関する注意事項

4.32.9　<jsp:useBean>タグのclass属性に関する注意事項

4.32.10　TLDファイルのバージョンに関する注意事項

4.32.11　タグの属性値のExpressionチェックに関する注意事項

4.32.12　タグの属性値に指定するExpressionに関する注意事項

4.32.13　taglibディレクティブのprefix属性に関する注意事項

5.　EJBコンテナ

5.1　EJBコンテナで使用できる機能

5.2　Enterprise Beanの実行

5.2.1　Enterprise Beanの種類

5.2.2　Enterprise Beanのインタフェース

5.2.3　Enterprise Beanのライフサイクル

5.2.4　Enterprise Beanのアノテーション指定

5.2.5　DIの使用

5.2.6　デフォルトインターセプタの使用

5.2.7　アノテーションの参照抑止

5.2.8　EJBのチェック

5.2.9　CMPフィールドとデータ型のマッピング

5.3　EJBコンテナのJNDI名前空間へのリファレンス登録

5.4　外部リソースとの接続

5.5　Enterprise Beanでのトランザクション設定

5.5.1　BMT

5.5.2　CMT

5.6　Entity Beanのコミットオプション指定

5.7　Enterprise Beanのプールの管理

5.7.1　Stateless Session Beanのプーリング

5.7.2　Entity Beanのプーリング

5.7.3　Message-driven Beanのプーリング

5.8　Enterprise Beanへのアクセス制御

5.8.1　Enterprise Beanへのアクセス制御の抑止

5.9　EJBコンテナでのタイムアウトの設定

5.9.1　タイムアウトの種類

5.9.2　Stateful Session Beanのタイムアウト

5.9.3　Entity BeanのEJBオブジェクトのタイムアウト

5.9.4　RMI-IIOP通信のタイムアウト

5.9.5　インスタンス取得待ちのタイムアウト

5.10　Timer Serviceの機能

5.10.1　Timer Serviceの概要

5.10.2　EJBタイマの生成と削除

5.10.3　Timer Serviceの運用

5.10.4　EJBタイマとコールバックの動作についての注意事項

5.10.5　Timer Serviceを使用するアプリケーションの実装

5.11　EJBのリモートインタフェースの呼び出し

5.11.1　EJBのリモートインタフェースでのローカル呼び出しの最適化

5.11.2　EJBのリモートインタフェースの値の参照渡し

5.11.3　EJBのリモートインタフェースの通信障害発生時の動作

5.12　セキュリティ管理

5.12.1　セキュリティアイデンティティを使用した認証

5.12.2　EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション）

5.13　Enterprise Beanの実装

5.13.1　Enterprise Bean共通の注意事項

5.13.2　Stateless Session Bean実装時の注意事項

5.13.3　Stateful Session Bean実装時の注意事項

5.13.4　Entity Bean（BMP）実装時の注意事項

5.13.5　Entity Bean（CMP）実装時の注意事項

5.13.6　Message-driven Bean実装時の注意事項

5.13.7　アノテーション使用時の注意事項（Enterprise Bean）

6.　EJBクライアント

6.1　EJBクライアントで使用できる機能

6.2　Enterprise Beanの呼び出し

6.2.1　Enterprise Beanを呼び出す方法

6.2.2　EJBクライアントアプリケーションからのEnterprise Bean呼び出しの流れ

6.3　JNDIによるEJBホームオブジェクトおよびビジネスインタフェースのリファレンスのルックアップ

6.3.1　自動的にバインドされる名前でのルックアップ

6.3.2　ユーザ指定名前空間で付与した名前でのルックアップ

6.3.3　EJBホームオブジェクトリファレンスの再利用（EJBホームオブジェクトへの再接続機能）

6.4　EJBクライアントアプリケーションでのトランザクションの実装

6.4.1　EJBクライアントでトランザクションを使用する手順

6.4.2　ルックアップを使用したUserTransactionの取得方法

6.4.3　EJBクライアントアプリケーションでのトランザクション実装時の注意事項

6.5　EJBクライアントアプリケーションでのセキュリティの実装

6.5.1　セキュリティを実装する場合の前提条件

6.5.2　セキュリティを実装した場合のサンプルプログラム

6.6　RMI-IIOPスタブ，インタフェースの取得

6.6.1　サーバ管理コマンドによる手動ダウンロード

6.6.2　ダイナミッククラスローディング

6.6.3　uCosminexus Client使用時の注意

7.　J2EEアプリケーションの実行

7.1　実行できるJ2EEアプリケーションの形態

7.2　アーカイブ形式によるJ2EEアプリケーションのデプロイ

7.3　展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ

7.3.1　展開ディレクトリ形式の概要

7.3.2　アプリケーションディレクトリの構成

7.3.3　EARファイル／ZIPファイルの展開ディレクトリ形式でのデプロイ

7.3.4　展開ディレクトリ形式を使用する場合の注意事項

7.4　J2EEアプリケーションのリデプロイ

7.4.1　J2EEアプリケーションの状態と入れ替え

7.4.2　注意事項

7.5　J2EEアプリケーションの更新検知とリロード

7.5.1　更新検知とリロードの概要

7.5.2　更新検知の対象となるファイル

7.5.3　J2EEアプリケーションの更新検知インターバル

7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル

7.5.5　Webアプリケーションのリロード

7.5.6　JSPのリロード

7.5.7　ほかの機能との関係

8.　ネーミング管理

8.1　ネーミング管理の概要

8.1.1　ネーミング管理の機能

8.1.2　ネーミングサービス

8.2　JNDI名前空間へのオブジェクトのバインドとルックアップ

8.2.1　ルックアップで使用する名称の種類

8.2.2　EJBのリファレンスが自動的にバインドされる名称

8.2.3　JNDI名前空間のマッピングとルックアップ

8.2.4　JNDI名前空間の確認方法

8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）

8.3.1　別名を付けられる対象

8.3.2　別名の付与規則

8.3.3　別名の設定方法

8.3.4　別名が登録または削除されるタイミング

8.3.5　クライアントからの検索

8.3.6　ユーザ指定名前空間機能を使用する場合の注意事項

8.4　ラウンドロビンポリシーによるCORBAネーミングサービスの検索

8.4.1　ラウンドロビン検索の範囲

8.4.2　ラウンドロビン検索の動作

8.4.3　ラウンドロビン検索をするために必要な設定

8.4.4　ラウンドロビン検索をする場合の注意事項

8.5　ネーミング管理機能でのキャッシング

8.5.1　キャッシングの流れ

8.5.2　ネーミングで使用したキャッシュのクリア

8.5.3　ネーミングでのキャッシングの注意事項

8.6　CORBAネーミングサービスの切り替え

9.　リソース接続とトランザクション管理

9.1　リソース接続とトランザクション管理の概要

9.2　リソースへの接続の概要

9.2.1　リソースへの接続方法

9.2.2　リソースアダプタの種類

9.2.3　リソースアダプタの使用方法

9.2.4　リソースアダプタの機能

9.2.5　リソースアダプタについての注意事項

9.2.6　リソースアダプタ以外の機能

9.3　トランザクション管理の概要

9.3.1　リソース接続でのトランザクション管理の方法

9.3.2　ローカルトランザクションとグローバルトランザクション

9.3.3　リソースごとに使用できるトランザクションの種類

9.3.4　トランザクションサービスで提供する機能

9.3.5　システム例外発生時のトランザクションの動作

9.3.6　トランザクションマネジャの取得

9.4　データベースへの接続

9.4.1　DB Connectorによる接続の概要

9.4.2　使用できるJ2EEコンポーネントおよび機能

9.4.3　接続できるデータベース

9.4.4　DB Connector（RARファイル）の種類

9.4.5　HiRDBと接続する場合の前提条件と注意事項

9.4.6　Oracleと接続する場合の前提条件と注意事項

9.4.7　SQL Serverと接続する場合の前提条件と注意事項

9.4.8　XDM/RD E2と接続する場合の前提条件と注意事項

9.5　データベース上のキューとの接続

9.5.1　DB Connector for Cosminexus RMとCosminexus RMによる接続の概要

9.5.2　DB Connector for Cosminexus RMとCosminexus RMによる接続の特徴

9.5.3　使用できる機能

9.5.4　接続できるデータベース

9.5.5　DB Connector for Cosminexus RM（RARファイル）の種類

9.5.6　HiRDBのキューに接続する場合の前提条件

9.5.7　Oracleのキューに接続する場合の前提条件

9.6　OpenTP1との接続（SSPまたはTP1/Message Queue）

9.6.1　uCosminexus TP1 Connectorによる接続

9.6.2　TP1/Message Queue - Accessによる接続

9.7　SMTPサーバとの接続

9.8　JavaBeansリソースの利用

9.8.1　JavaBeansリソースの開始処理の流れ

9.8.2　JavaBeansリソースの実装

9.9　そのほかのリソースとの接続

9.9.1　そのほかのリソースとの接続に使用するリソースアダプタ

9.9.2　そのほかのリソースとの接続で使用できる機能

9.10　パフォーマンスチューニングのための機能

9.10.1　コネクションプーリング

9.10.2　コネクションシェアリング・アソシエーション

9.10.3　ステートメントプーリング

9.10.4　ライトトランザクション

9.10.5　インプロセストランザクションサービス

9.10.6　DataSourceオブジェクトのキャッシング

9.10.7　DB Connectorのコンテナ管理でのサインオンの最適化

9.10.8　受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）

9.11　フォールトトレランスのための機能

9.11.1　コネクションの障害検知

9.11.2　コネクション枯渇時のコネクション取得待ち

9.11.3　コネクションの取得リトライ

9.11.4　コネクションプールの情報表示

9.11.5　コネクションプールのクリア

9.11.6　コネクションの自動クローズ

9.11.7　コネクションスイーパ

9.11.8　トランザクションタイムアウトとステートメントキャンセル

9.11.9　トランザクションリカバリ

9.11.10　障害調査用SQLの出力

9.11.11　オブジェクトの自動クローズ

9.12　コネクションプールのクラスタ化

9.12.1　クラスタコネクションプールの概要

9.12.2　クラスタコネクションプールの動作

9.12.3　使用するリソースアダプタ

9.13　そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合）

9.13.1　リソースアダプタのライフサイクル管理

9.13.2　リソースアダプタのワーク管理

9.13.3　メッセージインフロー

9.13.4　管理対象オブジェクトのルックアップ

9.13.5　コネクション定義の複数指定

9.13.6　Application Server独自のConnector 1.5 API仕様

9.13.7　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の注意事項

9.14　リソースへの接続テスト

9.15　ファイアウォール環境での運用のための機能

9.15.1　トランザクションリカバリ用通信ポート

9.15.2　スマートエージェントが使用する通信ポート

9.16　リソースに接続するための実装

9.16.1　アプリケーションからリソースに接続する手順

9.16.2　リソースへのサインオン方式

9.17　トランザクション管理機能の実装

9.17.1　コンテナ管理のトランザクション（CMT）を使用する場合の処理概要と留意点

9.17.2　UserTransactionインタフェースを使用する場合の処理概要と留意点

9.17.3　リソースアダプタ固有のトランザクション管理インタフェースを使用する場合の処理概要と留意点

9.17.4　トランザクションを使用しない場合の処理概要と留意点

9.17.5　JTAによるトランザクション実装時の注意事項

9.18　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項

9.18.1　アプリケーション開発時の注意事項

9.18.2　システム構築時の注意事項

9.18.3　システム運用時の注意事項

10.　コンテナ拡張ライブラリ

10.1　コンテナ拡張ライブラリの利用

10.2　コンテナ拡張ライブラリの利用の指針

10.2.1　コンテナ拡張ライブラリ利用の検討

10.2.2　コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項

10.3　コンテナ拡張ライブラリ利用の流れ

10.4　サーバ起動・停止フック機能の実装

10.4.1　サーバ起動・停止フック機能の実装方法

10.4.2　サーバ起動・停止フック処理の呼び出し順序

10.4.3　サーバ起動・停止フック機能利用時のクラスパスの指定

10.5　スマートエージェント経由でのCORBAオブジェクトの呼び出し

11.　CTMによるリクエストのスケジューリングと負荷分散

11.1　CTMを使用したリクエストのスケジューリングの概要

11.1.1　リクエストをスケジューリングする目的

11.1.2　CTMが制御できるリクエストの種類

11.1.3　リクエストを送信するクライアントアプリケーション

11.2　CTMのプロセス構成

11.2.1　CTMのプロセス構成と配置

11.2.2　プロセス配置の指針

11.2.3　CTMデーモン

11.2.4　CTMレギュレータ

11.2.5　CTMドメインとCTMドメインマネジャ

11.2.6　グローバルCORBAネーミングサービス

11.3　CTMによるリクエストのスケジューリングの仕組み

11.3.1　CTMを使用する場合の処理の流れ

11.3.2　スケジュールキューの構成とキューの共有

11.3.3　スケジュールキューの長さ

11.4　CTMによるリクエストの流量制御と優先制御

11.4.1　リクエストの流量制御

11.4.2　リクエストの優先制御

11.4.3　リクエストの同時実行数の動的変更

11.5　CTMによるリクエストの閉塞制御

11.5.1　オンライン状態でのJ2EEアプリケーションの入れ替え

11.5.2　J2EEアプリケーションの閉塞制御

11.5.3　スケジュールキューの閉塞制御

11.5.4　J2EEサーバ異常終了時のリクエスト保持

11.6　CTMによるリクエストの負荷分散

11.7　CTMによるリクエストのキューの滞留監視

11.8　CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続

12.　J2EEサーバ間のセッション情報の引き継ぎ

12.1　セッションフェイルオーバ機能とは

12.1.1　セッションフェイルオーバの利点

12.1.2　前提条件

12.2　グローバルセッションを利用したセッション管理

12.2.1　グローバルセッションを利用したセッション管理の概要

12.2.2　グローバルセッションID

12.2.3　グローバルセッション情報

12.2.4　グローバルセッションを利用するためのシステム構成要素

12.2.5　グローバルセッション情報が引き継がれるセッションの条件

12.2.6　サーバの状態とグローバルセッション情報の引き継ぎ

12.2.7　グローバルセッションの制御方法

12.2.8　グローバルセッション情報の排他制御

12.2.9　グローバルセッション情報の最大数

12.2.10　グローバルセッション情報のサイズの見積もり

12.3　HTTP Cookieによるグローバルセッションの制御

12.3.1　HTTP Cookieによる制御の概要

12.3.2　HTTP Cookieによる制御の前提条件

12.3.3　グローバルセッションIDを送信するHTTP Cookieの名称

12.3.4　サーブレットコンテキストへの属性追加

12.3.5　HTTP Cookieの有効期限

12.3.6　グローバルセッション破棄に伴うHTTP Cookie情報の破棄

12.4　URL書き換えによるグローバルセッションの制御

12.4.1　URL書き換えによる制御の概要

12.4.2　URL書き換えによる制御の前提条件

12.4.3　グローバルセッションIDの送信に使用するURLのパスパラメタ

12.4.4　URL書き換えによって制御する場合の負荷分散

12.4.5　URL書き換えによって制御する場合の注意事項

12.5　グローバルセッションの制御方法が混在する場合のシステム構成

12.5.1　制御方法ごとにWebアプリケーションを分ける場合

12.5.2　制御方法ごとにWebアプリケーションを分けない場合

12.6　セッションフェイルオーバ機能で実施される処理

12.6.1　セッションフェイルオーバ機能で処理が実施されるタイミング

12.6.2　J2EEサーバ起動時の処理

12.6.3　J2EEアプリケーション開始時の処理

12.6.4　リクエスト実行時の処理

12.6.5　HttpSessionオブジェクトの有効期限が切れた場合の処理

12.6.6　無効なグローバルセッションIDが送られた場合の処理

12.6.7　URL書き換えを使用する場合の処理の違い

12.7　セッションフェイルオーバ機能を使用するアプリケーションの実装

12.7.1　実装時の留意事項

12.7.2　URL書き換えによる制御をする場合のアプリケーションの実装

12.7.3　アプリケーションを実行するときに追加される属性

12.7.4　DDの定義

12.8　障害検知の方法

13.　統合ユーザ管理

13.1　統合ユーザ管理の概要

13.1.1　統合ユーザ管理の目的

13.1.2　レルムを使用したユーザ管理とユーザマッピング

13.1.3　Java標準仕様（JAAS）に準拠したユーザ認証の概要

13.1.4　統合ユーザ管理で使用するユーザ情報の管理方法

13.1.5　ユーザ認証の有効期間と認証状態の引き継ぎ

13.1.6　統合ユーザ管理の処理の流れ

13.2　Cosminexus標準ログインモジュールによるユーザ認証の仕組み

13.2.1　Cosminexus標準ログインモジュールの種類と機能

13.2.2　WebPasswordLoginModule

13.2.3　WebCertificateLoginModule

13.2.4　WebPasswordLDAPLoginModule

13.2.5　WebPasswordJDBCLoginModule

13.2.6　DelegationLoginModule

13.2.7　WebSSOLoginModule

13.2.8　Cosminexus標準ログインモジュールによるリポジトリへのアクセス

13.2.9　パスワード認証時の暗号拡張

13.2.10　ログインモジュールが使用するコンフィグレーションファイルのパラメタ

13.3　統合ユーザ管理のセッション管理

13.3.1　セッションの種類

13.3.2　ログインしたユーザIDの登録

13.3.3　統合ユーザ管理のセッションに登録したユーザIDの削除

13.3.4　JAASのコンフィグレーションファイルの定義例

13.3.5　セッションフェイルオーバ機能を使用したログイン状態の引き継ぎ

13.4　シングルサインオンの利用方法

13.4.1　シングルサインオンをするために必要な手順

13.4.2　既存アプリケーションで行っているユーザ管理の適用

13.5　カスタムログインモジュールの利用

13.5.1　カスタムログインモジュールとは

13.5.2　カスタムログインモジュールの呼び出し

13.6　統合ユーザ管理フレームワークが提供するAPIの概要

13.6.1　JSPタグライブラリ

13.6.2　統合ユーザ管理フレームワークのライブラリ

13.7　統合ユーザ管理フレームワークによるユーザ認証の実装の概要

13.8　APIを使用したユーザ認証の実装

13.8.1　ログイン（APIを使用する場合）

13.8.2　ユーザIDの取得（APIを使用する場合）

13.8.3　ユーザ属性の取得（APIを使用する場合）

13.8.4　ログアウト（APIを使用する場合）

13.8.5　HttpSessionにjava.io.Serializableを継承したSubjectを格納する場合の実装

13.8.6　パスワード認証時の暗号拡張の実装

13.9　タグライブラリを使用したユーザ認証の実装

13.9.1　ログイン（タグライブラリを使用する場合）

13.9.2　ユーザIDの取得（タグライブラリを使用する場合）

13.9.3　ユーザ属性の取得（タグライブラリを使用する場合）

13.9.4　ログアウト（タグライブラリを使用する場合）

13.10　セッションフェイルオーバ機能使用時のユーザ認証の実装

13.10.1　セッションフェイルオーバ機能で引き継げるセッション情報と認証情報

13.10.2　セッションフェイルオーバ機能使用時のユーザ認証の実装

13.10.3　セッションフェイルオーバ機能使用時のDDの定義

13.11　カスタムログインモジュールの実装

13.11.1　Cosminexus標準のログインモジュールと連携するための情報

13.11.2　カスタムログインモジュールの実装時の留意点

13.11.3　カスタムログインモジュールの実装例

13.12　統合ユーザ管理の運用

13.12.1　リポジトリ管理

13.12.2　リポジトリ（LDAPディレクトリサーバ）の接続フェイルオーバ

第3編　バッチアプリケーション実行基盤としての機能

14.　バッチサーバ

14.1　バッチアプリケーション実行環境の概要

14.1.1　バッチアプリケーションを実行するシステム

14.1.2　バッチサーバで提供する機能

14.1.3　バッチアプリケーションの実行環境の構築

14.1.4　バッチアプリケーションの実行環境の運用

14.1.5　マルチバイト文字の使用について

14.2　バッチアプリケーション実行機能

14.2.1　バッチアプリケーション実行機能の概要

14.2.2　バッチアプリケーションの実行

14.2.3　バッチアプリケーションの強制停止

14.2.4　バッチアプリケーションのログ出力

14.3　EJBアクセスで使用できる機能

14.4　ネーミング管理が提供する機能

14.5　リソース接続とトランザクション管理が提供する機能

14.5.1　リソース接続とトランザクション管理の概要

14.5.2　リソース接続への接続方法

14.5.3　トランザクションの管理方法

14.6　ガーベージコレクション制御機能

14.6.1　ガーベージコレクション制御機能とは

14.6.2　ガーベージコレクション制御の処理の流れ

14.7　コンテナ拡張ライブラリ

15.　バッチアプリケーション

15.1　バッチアプリケーションの実行方法

15.1.1　バッチアプリケーションの開始方法

15.1.2　バッチアプリケーションの強制停止の方法

15.1.3　バッチアプリケーションで使用するコマンドの実行について

15.2　バッチアプリケーションの作成

15.2.1　バッチアプリケーションの作成規則

15.2.2　バッチアプリケーション作成時の注意

15.3　リソースに接続するバッチアプリケーションの作成

15.3.1　新規にバッチアプリケーションを作成する場合

15.3.2　既存のバッチアプリケーションから移行する場合

15.3.3　リソースに接続するバッチアプリケーションの注意

15.4　EJBにアクセスするバッチアプリケーションの作成

15.5　Javaアプリケーションからの移行

15.5.1　アプリケーションの移行が必要な場合

15.5.2　実行環境の移行が必要な場合

第4編　構築支援機能

16.　システムの構築

16.1　Cosminexusで提供するシステムの構築支援機能

16.2　Management Serverで構築したシステムの概要

16.2.1　Management Serverが管理する範囲

16.2.2　Management Serverでのサーバ管理

16.3　Smart Composer機能を使用したシステム構築の特長

16.4　Smart Composer機能を使用したシステム構築の流れ

16.5　セットアップウィザードを使用したシステム構築の特長

16.6　セットアップウィザードを使用したシステム構築の流れ

16.7　リソースアダプタやJ2EEアプリケーションの設定

16.7.1　リソースアダプタやJ2EEアプリケーションの設定で使用する構築支援機能

16.7.2　リソースアダプタの設定の流れ

16.7.3　J2EEアプリケーションの設定の流れ

16.8　複数の構築済み実行環境の切り替え

16.8.1　構築済み実行環境の切り替えの概要

16.8.2　構築済み実行環境の切り替えの流れ

16.8.3　構築済み実行環境を切り替える場合の注意

第5編　運用支援機能

17.　システムの日常運用

17.1　システムの日常運用の概要

17.1.1　J2EEアプリケーションの実行環境の日常運用

17.1.2　バッチアプリケーションの実行環境の日常運用

17.2　J2EEサーバまたはバッチサーバの運用とシステムの運用管理者（UNIXの場合）

17.3　システムの起動と停止

17.3.1　日常運用での起動と停止

17.3.2　論理サーバの起動・停止と稼働確認

17.3.3　障害発生時の自動再起動

17.4　ステータスの監視

17.4.1　サービスユニットのステータス監視

17.4.2　論理サーバのステータス監視

17.5　稼働情報の監視（稼働情報収集機能）

17.5.1　稼働情報ファイルの出力

17.5.2　イベントの発行

17.6　稼働情報の監視（運用管理コマンド）

17.7　リソースの枯渇監視

17.7.1　リソース枯渇監視機能の概要

17.7.2　監視できるリソースの種類

17.8　Managementイベントによる処理の自動実行

17.8.1　Managementイベントの通知とManagementアクション

17.8.2　Managementアクションの実行制御

17.9　CTMの稼働統計情報の収集

17.9.1　CTMの稼働統計情報の概要

17.9.2　稼働統計情報ファイルの利用方法

17.10　システムの処理性能の解析

17.10.1　性能解析トレースの概要

17.10.2　性能解析トレースの仕組み

17.10.3　性能解析トレースの構成

17.10.4　トレース情報の利用方法

17.10.5　トレース取得ポイントとPRFトレース取得レベル

17.10.6　トレース情報の取得によるトラブルシュート

17.10.7　性能解析トレースのルートアプリケーション情報の取得のための実装

17.11　サービスユニットの構成監視

18.　システムの保守

18.1　システムの保守の概要

18.2　トラブルシューティングの資料の取得

18.2.1　障害発生時の資料取得の流れ

18.2.2　取得できる資料

18.2.3　障害検知時コマンドによる資料取得

18.2.4　snapshotログの収集

18.3　アプリケーションのユーザログ出力

18.3.1　ユーザログ出力の概要

18.3.2　ログのフォーマット

18.3.3　ユーザログ出力で使用するメソッド

18.3.4　ロガーとハンドラの作成と設定

18.3.5　ログの出力方法

18.3.6　セキュリティポリシーの設定

18.3.7　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法

18.3.8　ユーザログ機能を使用する場合の注意事項

18.3.9　EJBクライアントアプリケーションのユーザログ出力

18.3.10　EJBクライアントアプリケーションでのユーザログ出力の実装

18.4　コンソールログの出力

19.　J2EEアプリケーションの運用

19.1　J2EEアプリケーションの運用の概要

19.2　同時実行数の動的変更

19.3　J2EEアプリケーション実行時間の監視とキャンセル

19.3.1　J2EEアプリケーション実行時間の監視の概要

19.3.2　メソッドタイムアウトとは

19.3.3　メソッドキャンセルとは

19.3.4　タイムアウト値の設定例と設定値の有効範囲

19.3.5　J2EEアプリケーション実行時間の監視機能の実装

19.3.6　使用するスレッド数

19.4　J2EEアプリケーションのサービスの閉塞

19.4.1　Webアプリケーションのサービスの閉塞と閉塞解除

19.4.2　CTMのスケジュールキューの閉塞と閉塞解除

19.5　J2EEアプリケーションの停止

19.5.1　J2EEアプリケーション停止の概要

19.5.2　閉塞処理

19.5.3　停止処理

19.5.4　強制停止処理

19.6　J2EEアプリケーションの入れ替え

19.6.1　J2EEアプリケーション入れ替えの概要

19.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え

19.7　J2EEアプリケーションのテスト機能

19.7.1　テストモードの概要

19.7.2　テストモードで動作しているJ2EEアプリケーションに対する処理

19.7.3　テストモードで動作しているJ2EEアプリケーション情報の取得

19.7.4　テストモードでのJ2EEアプリケーション呼び出し時の注意事項

20.　システムの監査

20.1　システムの監査の概要

20.2　監査ログを使用したシステムの監査

20.2.1　監査ログを使用したシステムの監査の概要

20.2.2　監査ログ出力の前提条件

20.2.3　アプリケーションの監査ログを出力するための実装

20.2.4　監査ログの出力方式

20.3　データベース監査証跡との連携

20.3.1　データベース監査証跡との連携の概要

20.3.2　データベース監査証跡に出力する情報

第6編　ほかのプログラムとの連携機能

21.　JP1と連携したシステムの運用

21.1　JP1と連携して実現できる運用

21.2　システムの集中監視（JP1/IMとの連携）

21.2.1　システムの集中監視の概要

21.2.2　システムの集中監視に必要なプログラム

21.2.3　監視ツリーの自動生成

21.2.4　統合機能メニューからの運用管理ポータルの表示（Windowsの場合）

21.2.5　障害の監視の仕組み

21.3　システムの構成定義および管理（JP1/IM - CMとの連携）

21.3.1　システムの構成定義および管理の概要

21.3.2　システムの構成定義および管理に必要なプログラム

21.3.3　Smart Composer機能でのWebシステム構築

21.3.4　Webシステムの構成情報の収集

21.4　ジョブによるシステムの自動運転（JP1/AJS2との連携）

21.4.1　ジョブによるシステムの自動運転の概要

21.4.2　ジョブによるシステムの自動運転に必要なプログラム

21.4.3　カスタムジョブによるジョブの定義（Windowsの場合）

21.4.4　論理サーバおよびJ2EEアプリケーションの起動と停止の自動化の仕組み

21.5　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）

21.5.1　シナリオによるシステムの自動運転の概要

21.5.2　シナリオによるシステムの自動運転に必要なプログラム

21.5.3　シナリオテンプレートによるシナリオの定義

21.6　監査ログの収集および一元管理（JP1/NETM/Auditとの連携）

21.6.1　監査ログの収集および一元管理の概要

21.6.2　監査ログの収集および一元管理に必要なプログラム

22.　クラスタソフトウェアと連携したシステムの運用

22.1　クラスタソフトウェアと連携して実現できる運用

22.1.1　実行系と待機系を1:1で運用するシステムとは（1:1系切り替えシステム）

22.1.2　相互スタンバイで運用するシステムとは（相互系切り替えシステム）

22.1.3　待機系をリカバリ専用サーバとして運用するシステムとは（N:1リカバリシステム）

22.2　クラスタソフトウェアと連携するための前提条件

22.2.1　系切り替えの管理対象となるサーバ

22.2.2　ライトトランザクション機能の利用

22.2.3　システムの運用方法

22.2.4　実行系の前提条件

22.2.5　待機系の前提条件

22.3　実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）

22.3.1　1:1系切り替えシステムのシステム構成例

22.3.2　系切り替えのタイミング

22.3.3　1:1系切り替えシステムでの系切り替え処理の流れ

22.3.4　系切り替え時のシステムの動作

22.3.5　系切り替え時の情報の引き継ぎ

22.4　相互スタンバイで運用するシステム（相互系切り替えシステム）

22.4.1　相互系切り替えシステムのシステム構成例

22.4.2　相互系切り替えシステムでの系切り替え処理の流れ

22.5　待機系をリカバリ専用サーバとして運用するシステム（N:1リカバリシステム）

22.5.1　N:1リカバリシステムのシステム構成例

22.5.2　リカバリ処理の流れ

22.5.3　系切り替え時の情報の引き継ぎ

付録

付録A　旧バージョンとの互換用機能

付録A.1　互換用のサーバの動作モード

付録A.2　使用できる機能の一覧

付録A.3　サーブレットエンジンモードとJ2EEサーバモードの比較

付録B　ベーシックモードでのリソース接続

付録B.1　接続できるリソースとトランザクションの管理方法

付録B.2　データベース接続の前提条件

付録B.3　データソースによるデータベースへの接続で使用できる機能

付録B.4　リソースへの接続テスト

付録B.5　JTAによるトランザクション実装時の注意事項

付録C　サーブレットエンジンモードで使用できるWebコンテナの機能

付録C.1　Webアプリケーションの実行

付録C.2　Webアプリケーションの更新検知とリロード

付録C.3　JSPファイルのコンパイル結果の保持

付録C.4　アプリケーションのイベントリスナ

付録C.5　リクエストおよびレスポンスのフィルタリング

付録C.6　Webコンテナのセキュリティ管理

付録C.7　EJBコンテナとの連携

付録C.8　データベースとの接続

付録C.9　Webコンテナによるスレッドの作成

付録C.10　同時実行スレッド数の制御

付録C.11　ユーザスレッドで使用できるApplication Serverの機能

付録C.12　ドメイン名指定でのトップページの表示

付録C.13　静的コンテンツのキャッシュ

付録C.14　簡易Webサーバ機能

付録D　サーブレットエンジンモードでのリソース接続

付録D.1　接続できるリソースとトランザクションの管理方法

付録D.2　データベース接続の前提条件

付録D.3　Webコンテナコネクションプール機能によるデータベース接続

付録E　J2EEサーバ起動時のEJBタイマの自動生成

付録E.1　サーブレット方式

付録E.2　Managementイベント方式

付録F　Oracle RACを使用したOracleへの接続

付録F.1　Cosminexusの機能を使用した接続

付録F.2　Oracleの機能を使用した接続

付録G　アプリケーションの開発で使用する文字コード

付録G.1　アプリケーションで扱う文字コード

付録G.2　ブラウザとアプリケーション間の文字コード変換

付録G.3　データベースとアプリケーション間の文字コード変換

付録H　クラスローダの構成

付録H.1　デフォルトのクラスローダ構成

付録H.2　ローカル呼び出し最適化時のクラスローダ構成

付録H.3　下位互換用のクラスローダ構成

付録H.4　クラスローダに設定されるクラスパス

付録I　Cosminexus DABroker Libraryを使用したデータベース接続の実装

付録I.1　Cosminexus DABroker Libraryで開発するアプリケーション

付録I.2　JDBC2.0の概要

付録I.3　JDBC2.0拡張機能の概要

付録I.4　データベース接続の設定

付録I.5　JDBC2.0拡張機能を使用したデータベース接続の設定

付録I.6　エラー時のJDBCドライバの処理

付録I.7　データ型の対応

付録J　用語解説

索引

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2006, 2007, Hitachi, Ltd.

前書き

■ 対象製品

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64）

P-2443-7D74　 uCosminexus Application Server Standard　 07-60
P-2443-7K74　 uCosminexus Application Server Enterprise　 07-60
P-2443-7M74　 uCosminexus Web Redirector　 07-60
P-2443-7S74　 uCosminexus Service Platform　 07-60※

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Vista，Windows XP

P-2443-7E74　 uCosminexus Developer Standard　 07-60
P-2443-7F74　 uCosminexus Developer Professional　 07-60
P-2443-7T74　 uCosminexus Service Architect　 07-60※
P-2443-7U74　 uCosminexus Operator　 07-60※

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Vista，Windows XP

P-2443-7H74　 uCosminexus Client　 07-60

●適用OS：AIX 5L V5.2，AIX 5L V5.3

P-1M43-7D71　 uCosminexus Application Server Standard　 07-60※
P-1M43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-1M43-7M71　 uCosminexus Web Redirector　 07-60※
P-1M43-7S71　 uCosminexus Service Platform　 07-60※

●適用OS：HP-UX 11i V2（IPF），HP-UX 11i V3（IPF）

P-1J43-7D71　 uCosminexus Application Server Standard　 07-60※
P-1J43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-1J43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（x86），Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux ES 3（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）

P-9S43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9S43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9S43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（x86），Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux ES 3（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5（AMD/Intel 64）

P-9S43-7S71　 uCosminexus Service Platform　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（IPF），Red Hat Enterprise Linux AS 4（IPF），Red Hat Enterprise Linux 5 Advanced Platform（Intel Itanium）

P-9V43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9V43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9V43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Solaris 9，Solaris 10

P-9D43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9D43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9D43-7M71　 uCosminexus Web Redirector　 07-60※
P-9D43-7S71　 uCosminexus Service Platform　 07-60※

※印の製品については，サポート時期をご確認ください。
これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
本製品では日立トレース共通ライブラリをインストールします。

■ 輸出時の注意

本製品を輸出される場合には，外国為替および外国貿易法ならびに米国の輸出管理関連法規などの規制をご確認の上，必要な手続きをお取りください。
なお，ご不明な場合は，弊社担当営業にお問い合わせください。

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国における米国International Business Machines Corp.の登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
BIG-IP，3-DNS，iControl Services Manager，FirePass　および F5 は F5 Networks Inc の商標，または登録商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
gzipは，米国FSF(Free Software Foundation)が配布しているソフトウェアです。
HP-UXは，米国Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Intelは，Intel Corporationの会社名です。
Internet Explorerは，米国Microsoft Corporationの米国及びその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国および他の国におけるインテル コーポレーションまたはその子会社の登録商標です。
Java 及びすべてのJava関連の商標及びロゴは，米国及びその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JavaScriptは，米国およびその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JDKは，米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Linuxは，Linus Torvaldsの米国およびその他の国における登録商標あるいは商標です。
Microsoftは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corp.の商品名称です。
Microsoft Office Excelは，米国 Microsoft Corporation の商品名称です。
Microsoft SQL Serverは，米国Microsoft Corp.の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，米国Oracle Corporationの登録商標です。
Oracleは，米国Oracle Corporation及びその子会社，関連会社の登録商標です。
Oracle8iは，米国Oracle Corporationの商標です。
Oracle9iは，米国Oracle Corporationの商標です。
Oracle 10gは，米国Oracle Corporationの商標です。
PA-RISCは，米国Hewlett-Packard Companyの商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
SQL Serverは，米国法人Sybase，Inc.の商標です。
Sun，Sun Microsystems，Javaは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Sun Microsystemsは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
UNIXは，X/Open Company Limited が独占的にライセンスしている米国ならびに他の国における登録商標です。
Windowsは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Windows Serverは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
Windows Vistaは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
X/Openは，X/Open Company Limited の英国ならびに他の国における登録商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，米国Sun Microsystems,Inc.が著作権を有している部分が含まれています。
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，UNIX System Laboratories,Inc.が著作権を有している部分が含まれています。

■ 発行

2006年4月 (第1版) 3020-3-M03
2007年12月 (第4版) 3020-3-M03-60

■ 著作権

All Rights Reserved. Copyright (C) 2006, 2007, Hitachi, Ltd.

変更内容

変更内容（3020-3-M03-60）uCosminexus Application Server Standard 07-60，uCosminexus Developer Standard 07-60，uCosminexus Developer Professional 07-60，uCosminexus Client 07-60，uCosminexus Application Server Enterprise 07-60，uCosminexus Web Redirector 07-60，uCosminexus Service Platform 07-60，uCosminexus Service Architect 07-60，uCosminexus Operator 07-60

追加・変更内容
変更個所

Application Serverで，バッチ処理を実行するアプリケーションの実行基盤をサポートした。これに伴い，バッチアプリケーションおよびバッチサーバに関する説明を追加した。
1.1，1.1.1，1.1.4，1.3，3章，14章，15章，16.2.1，16.2.2，16.4，17.1，17.1.2，17.2，17.4，17.5，17.5.1，17.5.2，17.7.1，17.7.2，17.8.1，17.10.2，17.10.5，17.10.7，
18.1，18.3，18.3.1，18.3.7，19.1，20.1，20.2.1，20.2.3，20.3.1，21.1，21.2.1，21.2.3，21.2.5，21.4.1，21.4.2，21.4.3，22.1，22.1.1，22.1.2，22.1.3，22.2.2，22.2.5，22.3，22.5，付録J

システム構築のツールとして，セットアップウィザード機能をサポートした。これに伴い，セットアップウィザード機能の説明を追加した。
1.1.2，2.3，3.3，16，16.1，16.2，16.2.1，16.5，16.6，付録J

Solarisの記述を追加した。
1.1.4，2.5.2，3.5.2，22.1

次のインタフェースに別名を設定できるようにした。

ローカルホームインタフェース

ローカルビジネスインタフェース

リモートビジネスインタフェース

2.2.3，2.2.5，3.2.2，8.2.1，8.3，8.3.1，8.3.2，8.3.3，8.3.4，8.3.5，8.3.6，8.4，8.4.4，付録A.2

Connector 1.5仕様に準拠したリソースアダプタで，Inboundの通信モデルを使用できるようにした。これに伴い，メッセージインフローの機能を使用できるようにした。
2.2.6，5.2.1，5.5.2，5.13.6，9.1，9.2.1，9.2.2，9.2.4，9.3.3，9.9，9.9.1，9.9.2，9.13，9.13.1，9.13.3，9.13.6，9.14，19.3.3，19.7.1，付録A.2，付録J

Connector 1.5仕様の管理対象オブジェクトをルックアップできるようにした。
2.2.6，8.1.1，9.13.4

Webアプリケーションを実行する場合の留意事項に，クエリ文字列の解析の説明を追加した。
4.2.2，付録C.1

セッションフェイルオーバ機能を使用する場合に，開発環境で使用するグローバルセッション情報のサイズ見積もり機能の説明を追加した。
4.4.4，12.1.2，12.2.3，12.2.10，12.7.4

デフォルトの文字エンコーディング適用時の注意事項を追加した。
4.6.5

ラウンドロビン方式によるリクエストの振り分けを指定する場合の注意事項を追加した。
4.23.3

JSPトランスレーション下位互換機能を追加した。
4.31

EL（Expression Language）のエスケープシーケンスに関する注意事項を追加した。
4.32.5

07-00より前のバージョンと07-00以降のバージョンで，JSPのコンパイルの動作が異なることについての注意事項を追加した。
4.32.9，4.32.10，4.32.11，4.32.12，4.32.13

EJB 2.1のMessage-driven Beanを使用できるようにした。
5.2.1，5.5.1，5.5.2，5.13.1

アノテーション@Resourceで次のリソースタイプを指定できるようにした。

javax.jms.ConnectionFactory

javax.jms.TopicConnectionFactory

javax.jms.Topic

5.2.5

デフォルトインターセプタを使用できるようにした。
5.2.6

コネクションが自動クローズされるタイミングについての説明を追加した。また，自動クローズされたことを確認する方法を追加した。
9.11.6

トランザクションリカバリについての注意事項を追加した。
9.11.9，9.13.5

Message-driven Beanのインスタンスプールとスレッドプーリングとの関係についての説明を追加した。
9.13.2

Connector 1.5仕様のリソースアダプタを使用する場合の注意事項を追加した。
9.13.7

セッションフェイルオーバ機能を使用する場合に，グローバルセッション情報として指定できるセッション情報のデータ型として，直列化可能クラスのオブジェクトの説明を追加した。
12.2.3，12.6.3，12.7.1，12.7.4

セッションフェイルオーバ機能を使用する場合に，HTTPセッションに登録されたすべてのセッション情報をグローバルセッション情報として引き継ぐ設定の説明を追加した。
12.2.3，12.7.4

セッションフェイルオーバ用フィルタの初期化処理後に出力されるメッセージの説明を追加した。
12.6.3

監査ログ出力機能を使用できる製品に，次の製品を追加した。

uCosminexus Developer Standard

uCosminexus Developer Professional

uCosminexus Service Architect

20.2.2

次の製品の適用OSに，Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），およびRed Hat Enterprise Linux 5（AMD/Intel 64）を追加した。

uCosminexus Service Platform

－

次の製品の適用OSにLinux（IPF）を追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

－

次の製品の適用OSにSolarisを追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

uCosminexus Service Platform

－

HP-UX（PA-RISC）のサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

－

次の製品の適用OSからHP-UX（IPF）を削除した。

uCosminexus Service Platform

－

単なる誤字・脱字などはお断りなく訂正しました。

変更内容（3020-3-M03-40）uCosminexus Application Server Standard 07-50，uCosminexus Developer Standard 07-50，uCosminexus Developer Professional 07-50，uCosminexus Client 07-50，uCosminexus Application Server Enterprise 07-50，uCosminexus Web Redirector 07-50，uCosminexus Service Platform 07-50，uCosminexus Service Architect 07-50，uCosminexus Operator 07-50

追加・変更内容

操作を実行するコマンドや機能についての記述を，推奨するコマンドや機能を使用した記述に置き換えた。また，非推奨のコマンドや機能についての記述を削除した。

監査ログを出力する機能を追加した。

データベース監査証跡と連携する機能を追加した。

1.4モードで使用できる機能として，Connector 1.5（outbound）を追加した。

セキュリティ設定のチェック機能を削除した。

JP1/PAM，JP1/Cm2/NNM，およびJP1/PFM/SSOと連携する機能を削除した。

JP1/NETM/Auditと連携した，監査ログの収集と一元管理の機能を追加した。

リダイレクタを使用して，POSTデータサイズでリクエストを振り分ける機能を追加した。

リソースアダプタのライフサイクル管理の機能を追加した。

リソースアダプタのワーク管理の機能を追加した。

コネクション定義の複数指定の機能を追加した。

複数の構築済み実行環境の切り替え機能を追加した。

アノテーションの参照を抑止する機能を追加した。

インプロセスHTTPサーバおよび簡易Webサーバのエラーステータスコードに，Content-Lengthヘッダに関する説明を追加した。

セッション管理で使用するグローバルセッションを，URL書き換えで制御する機能を追加した。

HTTPレスポンス圧縮機能に必要なメモリ量についての情報を追加した。

JSPのカスタムタグで，スクリプト変数を定義する場合の注意事項を追加した。

Unicodeの補助文字の送受信に関する注意を追加した。

EJBホームオブジェクトへの再接続機能を追加した。

J2EEアプリケーションにリソースアダプタを含めて使用する方法を追加した。

使用できるJDBCドライバに，SQL Server 2005 JDBC Driverを追加した。

DB ConnectorでのXDM/RD E2接続で使用できるJDBCドライバに，HiRDB Type4 JDBC Driverを追加した。

DB Connector for Cosminexus RMとCosminexus RMを使用する場合に，ステートメントキャンセル機能を使用できるようにした。

トランザクションマネジャのインタフェースに，javax.transaction.Transactionを追加した。また，トランザクションマネジャを使用する際の注意事項を追加した。

セッションフェイルオーバ機能を使用するための前提となる機能から，HTTP Cookieの有効化を削除した。

セッションフェイルオーバ機能を使用するための前提条件に，HTTPセッションのステッキーの設定を追加した。

HTTP Cookieによるグローバルセッションの制御を追加した。

URL書き換えによるグローバルセッションの制御を追加した。

グローバルセッション情報の最大サイズの説明に，文字種ごとのURLエンコード後のサイズに関する説明を追加した。

java，javawコマンドに関する記述を削除した。

AIX 5L V5.1のサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

uCosminexus Web Redirector

Microsoft(R) Windows(R) 2000 Advanced Server Operating System，Microsoft(R) Windows(R) 2000 Datacenter Server Operating System，およびMicrosoft(R) Windows(R) 2000 Server Operating Systemのサポート中止に伴い，これらのOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

Microsoft(R) Windows(R) 2000 Professional Operating Systemのサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

次の製品の適用OSに，HP-UX（IPF）を追加した。

uCosminexus Service Platform

次の製品の適用OSに，HP-UX 11i V3（IPF）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Web Redirector

次の製品の適用OSに，Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），およびRed Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

uCosminexus Web Redirector

次の製品の適用OSに，Windows Vistaを追加した。

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

変更内容（3020-3-M03-20）uCosminexus Application Server Standard 07-10，uCosminexus Application Server Enterprise 07-10，uCosminexus Developer Standard 07-10，uCosminexus Developer Professional 07-10，uCosminexus Client 07-10，uCosminexus Web Redirector 07-10，uCosminexus Service Platform 07-10，uCosminexus Service Architect 07-10，uCosminexus Operator 07-10

追加・変更機能

HiRDB Version 8に対応した。これに伴い，HiRDB Type4 JDBC Driverに関する記述を追加した。

次のJ2EEの機能に対応した。

JDBC 3.0

JavaMail 1.3

リクエスト，レスポンスおよびJSPファイルのデフォルトの文字エンコーディングを設定する機能を追加した。

受信バッファをプールする機能を追加した。

障害調査用にSQLを出力する機能を追加した。

Stateless Session Beanの場合にremove呼び出しを不要にできるオプションを追加した。

＠Resourceアノテーションで指定できるリソースタイプに次のタイプを追加した。

javax.xml.ws.Service

javax.jws.WebService

トランザクションマネジャを取得できるようにした。

コネクションプールのクラスタ化機能で，自動一時停止したコネクションプールを自動再開させない運用もできるようにした。

Smart Composer機能を使用して，CTMを使用したシステムを構築できるようになった。これに伴い，Smart Composer機能でのCTMに関する説明を追加した。

JP1 Version 8対応に伴い，記述を追加および変更した。

Oracle RACとの接続についての説明を追加した。

uCosminexus Application Server Standard，uCosminexus Application Server EnterpriseおよびuCosminexus Web Redirectorの適用OSに，HP-UX（PA-RISC）を追加した。

uCosminexus Application Server Standard，uCosminexus Application Server EnterpriseおよびuCosminexus Web Redirectorの適用OSに，Linux（IPF）を追加した。

uCosminexus Service Platformの適用OSに，AIXを追加した。

はじめに

このマニュアルは，Cosminexus（コズミネクサス）を使用して構築するアプリケーションサーバの概要と機能について説明したものです。

Cosminexusでは，次に示すプログラムプロダクトを使用してアプリケーションサーバを構築，運用します。なお，これらのプログラムプロダクトを使用して構築したシステムを，Cosminexusシステムといいます。

P-1J43-7D71　uCosminexus Application Server Standard

P-1J43-7K71　uCosminexus Application Server Enterprise

P-1J43-7M71　uCosminexus Web Redirector

P-1M43-7D71　uCosminexus Application Server Standard

P-1M43-7K71　uCosminexus Application Server Enterprise

P-1M43-7M71　uCosminexus Web Redirector

P-1M43-7S71　uCosminexus Service Platform

P-2443-7D74　uCosminexus Application Server Standard

P-2443-7E74　uCosminexus Developer Standard

P-2443-7F74　uCosminexus Developer Professional

P-2443-7H74　uCosminexus Client

P-2443-7K74　uCosminexus Application Server Enterprise

P-2443-7M74　uCosminexus Web Redirector

P-2443-7S74　uCosminexus Service Platform

P-2443-7T74　uCosminexus Service Architect

P-2443-7U74　uCosminexus Operator

P-9D43-7D71　uCosminexus Application Server Standard

P-9D43-7K71　uCosminexus Application Server Enterprise

P-9D43-7M71　uCosminexus Web Redirector

P-9D43-7S71　uCosminexus Service Platform

P-9S43-7D71　uCosminexus Application Server Standard

P-9S43-7K71　uCosminexus Application Server Enterprise

P-9S43-7M71　uCosminexus Web Redirector

P-9S43-7S71　uCosminexus Service Platform

P-9V43-7D71　uCosminexus Application Server Standard

P-9V43-7K71　uCosminexus Application Server Enterprise

P-9V43-7M71　uCosminexus Web Redirector

このマニュアルでは，これらのプログラムプロダクトの構成ソフトウェアのうち，次に示す構成ソフトウェアについて説明しています。

Cosminexus Component Container

Cosminexus Component Container - Client

Cosminexus Operator Plug-in

Cosminexus Component Container - Redirector

Cosminexus Component Transaction Monitor

Cosminexus DABroker Library

Cosminexus Developer's Kit for Java

Cosminexus Performance Tracer

Cosminexus TPBroker

なお，オペレーティングシステム（OS）の種類によって，機能が異なる場合があります。OSごとの違いがある場合の表記方法については，「適用OSの違いによる機能相違点の表記」を参照してください。

対象読者

このマニュアルは，Cosminexusのシステムを設計，構築または運用する方，およびCosminexusで動作するアプリケーションを開発する方を対象としています。

次の内容を理解されていることを前提としています。

システムを設計，構築または運用する方

OS（WindowsまたはUNIX）のシステム構築および運用に関する知識

J2EEに関する知識

SQLおよびリレーショナルデータベースに関する基本的な知識

CORBAに関する基本的な知識

JP1連携機能を使用する場合は，次の内容も理解されていることを前提とします。

JP1の統合管理，ジョブ管理，ネットワーク管理およびアベイラビリティ管理に関する基本的な知識

Microsoft Cluster Service連携機能を使用する場合は，次の内容も理解されていることを前提とします。

Microsoft Cluster Serviceを使用したクラスタ構成に関する基本的な知識

HAモニタ連携機能を使用する場合は，次の内容も理解されていることを前提とします。

HAモニタを使用したクラスタ構成に関する基本的な知識

アプリケーションを開発する方

Windowsの基本操作に関する知識

Javaによるプログラム開発に関する基本的な知識

使用するIDE（Eclipse）に関する基本的な知識

マニュアルの構成

このマニュアルは，次に示す編と付録から構成されています。

第1編　概要

Application Serverの概要，およびApplication Serverで提供するアプリケーションサーバの機能について説明しています。

第2編　J2EEアプリケーション実行基盤としての機能

Application Serverで提供するアプリケーションサーバの機能のうち，J2EEアプリケーション実行基盤としての機能について説明しています。

第3編　バッチアプリケーション実行基盤としての機能

Application Serverで提供するアプリケーションサーバの機能のうち，バッチアプリケーション実行基盤としての機能について説明しています。

第4編　構築支援機能

Application Serverで提供する，システム構築を支援する機能について説明しています。

第5編　運用支援機能

Application Serverで提供する，システム運用を支援する機能について説明しています。

第6編　ほかのプログラムとの連携機能

ほかのプログラムと連携したシステムの運用について説明しています。

付録A　旧バージョンとの互換用機能

旧バージョンとの互換用機能としてのサーバの動作モードについて説明しています。

付録B　ベーシックモードでのリソース接続

ベーシックモードの場合のリソース接続とトランザクション管理について説明しています。

付録C　サーブレットエンジンモードで使用できるWebコンテナの機能

サーブレットエンジンモードの場合に使用できるWebコンテナの機能について説明しています。

付録D　サーブレットエンジンモードでのリソース接続

サーブレットエンジンモードの場合のリソース接続とトランザクション管理について説明しています。

付録E　J2EEサーバ起動時のEJBタイマの自動生成

Timer Service機能で使用するEJBタイマをJ2EEサーバ起動時に自動で生成する方法について説明しています。

付録F　Oracle RACを使用したOracleへの接続

Oracle RACを使用してクラスタ化したOracleに接続する方法について説明しています。

付録G　アプリケーションの開発で使用する文字コード

アプリケーションで使用する文字コードと注意事項について説明しています。

付録H　クラスローダの構成

Cosminexusのクラスローダ構成およびクラスローダに設定されるクラスパスについて説明しています。

付録I　Cosminexus DABroker Libraryを使用したデータベース接続の実装

Cosminexus DABroker Libraryが提供する機能を使用してデータベース接続をする場合の実装方法や注意事項について説明しています。

付録J　用語解説

このマニュアルで使用している用語について説明しています。

関連マニュアル

Cosminexusのマニュアル体系について，次の図に示します。

マニュアル体系図で示した関連マニュアルについて，それぞれの位置づけを次に示します。

Cosminexus　概説

Cosminexusの製品概要について説明しています。

Cosminexus　システム設計ガイド

システム設計時に，システムの目的に応じたシステム構成や運用方法を検討するための指針について説明しています。また，チューニングの方法についても説明しています。

Cosminexus　簡易構築・運用ガイド

セットアップウィザードおよびSmart Composer機能を使用して，システムを構築・運用する手順について説明しています。また，セットアップウィザードおよびSmart Composer機能が提供するコマンドやファイルについても説明しています。

Cosminexus　システム構築ガイド

システム構築時に必要な機能の設定方法について説明しています。

Cosminexus　システム運用ガイド

Cosminexusを使用したシステムの運用方法のうち，Smart Composer機能を使用する運用以外の方法について説明しています。

Cosminexus　アプリケーション設定操作ガイド

Cosminexus Component Containerのサーバ管理コマンド，およびServer Plug-inを使用した操作について説明しています。

Cosminexus　運用管理操作ガイド

Cosminexus Component Containerの運用管理ポータルの使用方法について説明しています。

Cosminexus　リファレンス　コマンド編

Cosminexusのシステムを構築・運用するときに使用するコマンドについて説明しています。

Cosminexus　リファレンス　定義編

Cosminexusのシステムを構築・運用するとき，またはアプリケーションを開発するときに，使用するファイルの形式について説明しています。

Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編，Cosminexus　メッセージ 2　KEOS／KEUC／KFCB編，Cosminexus　メッセージ 3　KFCT／KFDB／KFDJ編

Cosminexusで出力されるメッセージについて説明しています。

Hitachi Web Server

Hitachi Web Server（Webサーバ）の構築，管理方法について説明しています。

TPBroker　ユーザーズガイド

Cosminexus TPBrokerの概要，機能，運用方法について説明しています。

Cosminexus Reliable Messaging

Cosminexus RMを使用したメッセージの非同期通信によるアプリケーションの連携方法について説明しています。

Cosminexus　アプリケーション開発ガイド

構築したCosminexusのシステムで動作させる，アプリケーションの開発方法について説明しています。

Cosminexus　リファレンス　API編

アプリケーションの開発で使用するAPIおよびタグについて説明しています。

また，マニュアル体系図に示したマニュアル以外で，このマニュアルと関連するマニュアルを次に示します。必要に応じてお読みください。

uCosminexus Batch Job Execution Server 使用の手引（3000-3-E02）

Cosminexus XML Processor　ユーザーズガイド（3020-3-M44）

Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド（3020-3-M45）

Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス（3020-3-M46）

Cosminexus　サービスプラットフォーム　概説（3020-3-M71）

Cosminexus　サービスプラットフォーム　システム構築・運用ガイド（3020-3-M73）

uCosminexus Service Coordinator Interactive Workflow システム構築・運用ガイド（3020-3-M80）

uCosminexus Service Coordinator Interactive Workflow AP開発ガイド（3020-3-M81）

高信頼化システム監視機能　HAモニタ　AIX(R)編（3000-9-130）

高信頼化システム監視機能　HAモニタ　HP-UX編（3000-9-131）

高信頼化システム監視機能　HAモニタ　Linux(R)編（3000-9-132）

スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）（3000-6-273）

スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（UNIX(R)/Windows(R)用）（3000-6-276）

スケーラブルデータベースサーバ HiRDB Version 7 SQLリファレンス（UNIX(R)/Windows(R)用）（3000-6-277）

スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用）（3000-6-353）

スケーラブルデータベースサーバ HiRDB Version 7 システム定義（Windows(R)用）（3020-6-273）

スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（Windows(R)用）（3020-6-276）

スケーラブルデータベースサーバ HiRDB Version 7 SQLリファレンス（Windows(R)用）（3020-6-277）

スケーラブルデータベースサーバ HiRDB Version 8 システム定義（Windows(R)用）（3020-6-353）

スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド（3020-6-356）

スケーラブルデータベースサーバ HiRDB Version 8 SQLリファレンス（3020-6-357）

JP1 Version 7i JP1/Integrated Manager - Console システム構築・運用ガイド（3020-3-F01）

JP1 Version 7i JP1/Automatic Job Management System 2 解説（3020-3-F06）

JP1 Version 7i JP1/Automatic Job Management System 2 操作ガイド（3020-3-F09）

JP1 Version 7i JP1/Integrated Manager - Central Information Master システム構築・運用ガイド（3020-3-F21）

JP1 Version 7i JP1/Automatic Job Management System 2 - Scenario Operation（3020-3-F23）

JP1 Version 7i JP1/Performance Analysis（3020-3-F51）

JP1 Version 8 JP1/Integrated Management - Manager システム構築・運用ガイド（3020-3-K01）

JP1 Version 8 JP1/Integrated Management - Central Information Master　システム構築・運用ガイド（3020-3-K04）

JP1 Version 8 JP1/Automatic Job Management System 2 解説（3020-3-K21）

JP1 Version 8 JP1/Automatic Job Management System 2 操作ガイド（3020-3-K24）

JP1 Version 8 JP1/Automatic Job Management System 2 - Scenario Operation（3020-3-K42）

JP1 Version 8 JP1/NETM/Audit（3020-3-L50）

OpenTP1 Version 6 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引（3000-3-838）

OpenTP1 Version 6 OpenTP1　クライアント使用の手引　TP1/Client/J編（3000-3-950）

OpenTP1 Version 7 OpenTP1　クライアント使用の手引　TP1/Client/J編（3000-3-D59）

なお，このマニュアルでは，次のマニュアルについて，対象OSおよびバージョン番号を省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

正式名称 | このマニュアルでの表記
JP1 Version 8 JP1/Automatic Job Management System 2 解説 | JP1/Automatic Job Management System 2 解説
JP1 Version 7i JP1/Automatic Job Management System 2 解説
JP1 Version 8 JP1/Automatic Job Management System 2 操作ガイド | JP1/Automatic Job Management System 2 操作ガイド
JP1 Version 7i JP1/Automatic Job Management System 2 操作ガイド
JP1 Version 8 JP1/Automatic Job Management System 2 - Scenario Operation | JP1/Automatic Job Management System 2 - Scenario Operation
JP1 Version 7i JP1/Automatic Job Management System 2 - Scenario Operation
JP1 Version 8 JP1/NETM/Audit | JP1/NETM/Audit
OpenTP1 Version 7 OpenTP1　クライアント使用の手引　TP1/Client/J編 | OpenTP1　クライアント使用の手引　TP1/Client/J編
OpenTP1 Version 6 OpenTP1　クライアント使用の手引　TP1/Client/J編
高信頼化システム監視機能　HAモニタ　AIX(R)編 | 高信頼化システム監視機能　HAモニタ
高信頼化システム監視機能　HAモニタ　HP-UX編
高信頼化システム監視機能　HAモニタ　Linux(R)編
スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用） | HiRDB システム定義
スケーラブルデータベースサーバ HiRDB Version 8 システム定義（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム定義（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド | HiRDB UAP開発ガイド
スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（UNIX(R)/Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 SQLリファレンス | HiRDB SQLリファレンス
スケーラブルデータベースサーバ HiRDB Version 7 SQLリファレンス（UNIX(R)/Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 SQLリファレンス（Windows(R)用）

読書手順

このマニュアルは，利用目的に合わせて章を選択して読むことができます。利用目的別にお読みいただくことをお勧めします。

マニュアルを読む目的 | 記述個所
Application Serverの概要について知りたい。 | Application Serverの概要について知りたい。 | 1章
J2EEアプリケーションを実行するアプリケーションサーバの機能について知りたい。 | アプリケーションサーバの機能の特長について知りたい。 | 2章
Webコンテナの機能について知りたい。 | 4章
EJBコンテナの機能について知りたい。 | 5章，付録E
EJBクライアントで使用できる機能について知りたい。 | 6章
J2EEサーバで実行できるJ2EEアプリケーションについて知りたい。 | 7章
J2EEサービスとして提供されている機能のうち，ネーミング管理について知りたい。 | 8章
J2EEサービスのトランザクション管理機能と，J2EEサーバで接続できるリソースについて知りたい。 | 9章，付録F
コンテナ拡張ライブラリについて知りたい。 | 10章
J2EEサーバへのリクエストのスケジューリングと負荷分散の方法を知りたい。 | 11章
J2EEサーバ間のセッション情報を引き継ぐためのセッションフェイルオーバ機能について知りたい。 | 12章
統合ユーザ管理機能について知りたい。 | 13章
Application Serverが提供している，システムを構築するための機能について知りたい。 | 16章
システムの日常運用について知りたい。 | 17章
システムの保守について知りたい。 | 18章
J2EEアプリケーションの運用の概要について知りたい。 | 19章
システムの監査について知りたい。 | 20章
JP1と連携したCosminexusシステムの運用方法について知りたい。 | 21章
クラスタソフトウェアと連携したCosminexusシステムの運用方法について知りたい。 | 22章
バッチアプリケーションを実行するアプリケーションサーバの機能について知りたい。 | アプリケーションサーバの機能の特長について知りたい。 | 3章
バッチアプリケーションの実行環境の概要や，バッチサーバで実行できる機能について知りたい。 | 14章
バッチサーバで実行できるバッチアプリケーションについて知りたい。 | 15章
Application Serverが提供している，システムを構築するための機能について知りたい。 | 16章
システムの日常運用について知りたい。 | 17章
システムの保守について知りたい。 | 18章
システムの監査について知りたい。 | 20章
JP1と連携したCosminexusシステムの運用方法について知りたい。 | 21章
クラスタソフトウェアと連携したCosminexusシステムの運用方法について知りたい。 | 22章
旧バージョンとの互換用機能について知りたい。 | 互換用の動作モードと使用できる機能について知りたい。 | 付録A
ベーシックモードでのリソース接続とトランザクション管理機能について知りたい。 | 付録B
サーブレットエンジンモードで使用できるWebコンテナの機能について知りたい。 | 付録C
サーブレットエンジンモードでのリソース接続とトランザクション管理機能について知りたい。 | 付録D
J2EEサーバ起動時にEJBタイマを自動で生成する方法について知りたい。 | 付録E
Oracle RACを使用したOracleへの接続について知りたい。 | 付録F
アプリケーションの開発で使用する文字コードについて知りたい。 | 付録G
Cosminexusのクラスローダ構成について知りたい。 | 付録H
Cosminexus DABroker Libraryを使用したデータベース接続の実装について知りたい。 | 付録I
用語について知りたい。 | このマニュアルで使用する用語について知りたい。 | 付録J

Cosminexusのマニュアルの読書手順

マニュアル体系図で示したマニュアルは，利用目的に合わせて，選択してお読みいただけます。次の案内に従ってお読みいただくことをお勧めします。

ご利用の製品ごとの用語の読み替えについて

ご利用の製品によっては，マニュアルで使用している用語を，ご利用の製品名に読み替える必要があります。

次の表に従って，マニュアルで使用している用語をご利用の製品名に読み替えてください。

ご利用の製品名 | マニュアルで使用している用語
uCosminexus Developer Professional※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Developer Standard※1※2 | Application Server
uCosminexus Service Architect※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Service Platform

注※1　テスト環境で使用している場合にだけ読み替えが必要です。

注※2　uCosminexus Developer StandardとApplication Serverには一部機能差があります。機能差については，マニュアル「Cosminexus　アプリケーション開発ガイド」のDeveloper Standard使用時の注意事項に関する説明を参照してください。

このマニュアルでの表記

このマニュアルで使用している表記と，対応する製品名を次に示します。

表記 | 製品名
Application Server | Application Server Enterprise | uCosminexus Application Server Enterprise
Application Server Standard | uCosminexus Application Server Standard
BJEX | uCosminexus Batch Job Execution Server
Developer | Developer Professional | uCosminexus Developer Professional
Developer Standard | uCosminexus Developer Standard
Eclipse | Eclipse 3.1.1
Excel | Microsoft(R) Office Excel
HiRDBまたはHiRDBサーバ | HiRDB/Parallel Server | HiRDB/Parallel Server Version 7
HiRDB/Parallel Server Version 8
HiRDB/Single Server | HiRDB/Single Server Version 7
HiRDB/Single Server Version 8
HiRDB Run TimeまたはHiRDBクライアント | HiRDB/Run Time Version 7
HiRDB/Run Time Version 8
IPF | Itanium(R) Processor Family
JP1/AJS2 | JP1/AJS2 - Agent | JP1/Automatic Job Management System 2 - Agent
JP1/AJS2 - Light Edition | JP1/Automatic Job Management System 2 - Light Edition
JP1/AJS2 - Manager | JP1/Automatic Job Management System 2 - Manager
JP1/AJS2 - View | JP1/Automatic Job Management System 2 - View
JP1/AJS2 - SO | JP1/AJS2 - SO Manager | JP1/Automatic Job Management System 2 - Scenario Operation Manager
JP1/AJS2 - SO View | JP1/Automatic Job Management System 2 - Scenario Operation View
JP1/Cm2 | JP1/Cm2/ESA | JP1/Cm2/Extensible SNMP Agent
JP1/Cm2/ESA for Extension Mib Runtime | JP1/Cm2/Extensible SNMP Agent for Extension Mib Runtime
JP1/Cm2/NC | JP1/Cm2/NC - Manager | JP1/Cm2/Network Element Configuration - Manager
JP1/Cm2/NC - Manager for Cosminexus | JP1/Cm2/Network Element Configuration - Manager for Cosminexus
JP1/ESP | JP1/Extensible Service Probe
JP1/IM | JP1/IM - Central Console | JP1/Integrated Manager - Central Console
JP1/IM - CM | JP1/Integrated Management - Central Information Master
JP1/Integrated Manager - Central Information Master
JP1/IM - Central Scope | JP1/Integrated Manager - Central Scope
JP1/IM - Manager | JP1/Integrated Management - Manager
JP1/IM - View | JP1/Integrated Management - View
JP1/Integrated Manager - View
JP1/NETM/Audit | JP1/NETM/Audit - Manager
JP1/SC/DPM | JP1/ServerConductor/Deployment Manager Standard Edition
Microsoft Cluster Service | Microsoft(R) Cluster Service
Microsoft IIS | Microsoft IIS 6.0 | Microsoft(R) Internet Information Services 6.0
Oracle | Oracle9i | Oracle9i
Oracle9i R2
Oracle10g | Oracle 10g
Oracle 10g R2
SQL Server | SQL Server 2000 | Microsoft(R) SQL Server(TM) 2000
SQL Server 2005 | Microsoft(R) SQL Server(TM) 2005
SQL ServerのJDBCドライバ | SQL Server 2000 Driver for JDBC | Microsoft(R) SQL Server(TM) 2000 Driver for JDBC
SQL Server 2005 JDBC Driver | Microsoft(R) SQL Server(TM) 2005 JDBC Driver
UNIX | AIX | AIX 5L V5.2
AIX 5L V5.3
HP-UXまたはHP-UX（IPF） | HP-UX 11i V2（IPF）
HP-UX 11i V3（IPF）
Linux | Linux（IPF） | Red Hat Enterprise Linux AS 3（IPF）
Red Hat Enterprise Linux AS 4（IPF）
Red Hat Enterprise Linux 5 Advanced Platform（Intel Itanium）
Linux（x86／AMD64 & Intel EM64T） | Red Hat Enterprise Linux AS 3（x86）
Red Hat Enterprise Linux AS 4（x86）
Red Hat Enterprise Linux 5 Advanced Platform（x86）
Red Hat Enterprise Linux ES 3（x86）
Red Hat Enterprise Linux ES 4（x86）
Red Hat Enterprise Linux 5（x86）
Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T）
Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T）
Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5（AMD/Intel 64）
Solaris | Solaris 9
Solaris 10
Web Redirector | uCosminexus Web Redirector
Windows Server 2003 | Windows Server 2003 Enterprise Edition | Microsoft(R) Windows Server(R) 2003，Enterprise Edition Operating System（x86）
Windows Server 2003 Standard Edition | Microsoft(R) Windows Server(R) 2003，Standard Edition Operating System（x86）
Windows Server 2003 R2 | Windows Server 2003 R2 Enterprise Edition | Microsoft(R) Windows Server(R) 2003 R2，Enterprise Edition Operating System（x86）
Windows Server 2003 R2 Standard Edition | Microsoft(R) Windows Server(R) 2003 R2，Standard Edition Operating System（x86）
Windows Server 2003（x64） | Windows Server 2003 Enterprise x64 Edition | Microsoft(R) Windows Server(R) 2003，Enterprise x64 Edition Operating System
Windows Server 2003 Standard x64 Edition | Microsoft(R) Windows Server(R) 2003，Standard x64 Edition Operating System
Windows Server 2003 R2（x64） | Windows Server 2003 R2 Enterprise x64 Edition | Microsoft(R) Windows Server(R) 2003 R2，Enterprise x64 Edition Operating System
Windows Server 2003 R2 Standard x64 Edition | Microsoft(R) Windows Server(R) 2003 R2，Standard x64 Edition Operating System
Windows Vista | Windows Vista Business | Microsoft(R) Windows Vista(R) Business
Windows Vista Enterprise | Microsoft(R) Windows Vista(R) Enterprise
Windows Vista Ultimate | Microsoft(R) Windows Vista(R) Ultimate
Windows XP | Microsoft(R) Windows(R) XP Professional Operating System
XDM/RD E2 | VOS3 XDM/RD E2

なお，Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Vista，およびWindows XPを総称してWindowsと表記することがあります。

このマニュアルで使用している表記と，対応するCosminexusの機能名を次に示します。

表記 | Cosminexusの機能名
Cosminexus Developer's Kit for Java | Cosminexus Developer's Kit for JavaTM
Cosminexus RM | Cosminexus Reliable Messaging
CTM | Cosminexus Component Transaction Monitor
DB Connector for Cosminexus RM | DB Connector for Cosminexus Reliable Messaging
Management Server | Cosminexus Management Server
PRF | Cosminexus Performance Tracer
Server Plug-in | Cosminexus Server Plug-in
Smart Composer | Cosminexus Smart Composer
TPBroker | Cosminexus TPBroker

このマニュアルで使用している表記と，対応するJava関連用語を次に示します。

表記 | Java関連用語
Connector 1.0 | J2EETM Connector Architecture 1.0
Connector 1.5 | J2EETM Connector Architecture 1.5
DI | Dependency Injection
EAR | Enterprise ARchive
EJBまたはEnterprise JavaBeans | Enterprise JavaBeansTM
EJB QL | EJBTM Query Language
J2EEまたはJava 2 Platform, Enterprise Edition | JavaTM 2 Platform, Enterprise Edition
J2SE | JavaTM 2 Platform, Standard Edition
JAAS | JavaTM Authentication and Authorization Service
JAR | JavaTM Archive
Java | JavaTM
Java 2 Runtime Environment, Standard Edition | JavaTM 2 Runtime Environment, Standard Edition
Java 2 SDK, Standard Edition | JavaTM 2 Software Development Kit, Standard Edition
JavaBeans | JavaBeansTM
JavaMail | JavaMailTM
JAXP | JavaTM API for XML Processing
JCA | J2EETM Connector Architecture
JCE | JavaTM Cryptography Extension
JDBC | JDBCTM
JavaTM Database Connectivity
JDK | JavaTM Development Kit
JMS | JavaTM Message Service
JNDI | Java Naming and Directory InterfaceTM
JNI | JavaTM Native Interface
JSP | JavaServer PagesTM
JTA | JavaTM Transaction API
JTS | JavaTM Transaction Service
Servletまたはサーブレット | JavaTM Servlet
WAR | Web ARchive

適用OSの違いによる機能相違点の表記

このマニュアルは，適用OSがWindows，AIX，HP-UX，Linux，およびSolarisの製品に対応します。OSによって記述を書き分ける場合，次に示す表記を使用して，それぞれの説明にOS名を明記しています。

表記 | 意味
Windowsの場合 | Windowsに該当する表記です。
AIXの場合 | AIXに該当する表記です。
HP-UXの場合 | HP-UXに該当する表記です。
Linuxの場合 | Linuxに該当する表記です。
Solarisの場合 | Solarisに該当する表記です。
UNIXの場合 | UNIX（AIX，HP-UX，Linux，Solaris）に該当する表記です。

このマニュアルで使用している略語

このマニュアルで使用している英略語を次に示します。

英略語 | 英字での表記
API | Application Programming Interface
ASCII | American Standard Code for Information Interchange
BMP | Bean-Managed Persistence
BMT | Bean-Managed Transaction
CMP | Container-Managed Persistence
CMR | Container-Managed Relationship
CMT | Container-Managed Transaction
CORBA | Common Object Request Broker Architecture
CSV | Comma Separated Value
CUI | Character User Interface
DB | Database
DBMS | Database Management System
DD | Deployment Descriptor
DIT | Directory Information Tree
DMZ | Demilitarized Zone
DN | Distinguished Name
DNS | Domain Name System
DTD | Document Type Definition
EIS | Enterprise Information System
EL | Expression Language
EUC | Extended UNIX Code
GUI | Graphical User Interface
HA | High Availability
HTML | Hyper Text Markup Language
HTTP | Hyper Text Transfer Protocol
HTTPS | Hyper Text Transfer Protocol Security
IIOP | Internet Inter-Orb Protocol
JIS | Japanese Industrial Standards
LAN | Local Area Network
LDAP | Lightweight Directory Access Protocol
LDIF | LDAP Data Interchange Format
MIB | Management Information Base
NTP | Network Time Protocol
OID | Object Identifier
OMG | Object Management Group
ORB | Object Request Broker
OS | Operating System
OTM | Object Transaction Monitor
OTS | Object Transaction Service
RAC | Real Application Clusters
RDB | Relational Database
RMI | Remote Method Invocation
RPC | Remote Procedure Call
SHA | Secure Hash Algorithm
SFO | Session Fail Over
SNMP | Simple Network Management Protocol
SOA | Service Oriented Architecture
SOAP | Simple Object Access Protocol
SPI | Service Provider Interface
SPP | Service Providing Program
SSL | Secure Sockets Layer
TAR | Tape Archival and Retrieval format
TCS | Transaction Context Server
UCS | Universal multi-octet coded Character Set
UML | Unified Modeling Language
UNC | Universal Naming Convention
URI | Uniform Resource Identifier
URL | Uniform Resource Locator
UTF | UCS Transformation Format
VM | Virtual Machine
XML | Extensible Markup Language

このマニュアルの図中で使用している記号

このマニュアルの図中で使用している記号を，次のように定義します。

このマニュアルで使用している記号

注意

間違いやすい点，および間違うとトラブルが発生するような項目について説明しています。

ポイント

その説明の要点について説明しています。

参考

補足的な情報を説明しています。

このマニュアルのGUIの説明で使用している記号

このマニュアルでは，次に示す記号を使用してGUIを説明しています。

記号 | 意味
［　　］＋［　　］ | +の前のキーを押したまま，後ろのキーを押すことを表します。
＜　　＞ | ＜＞内の名称がユーザの環境によって異なることを表します。

常用漢字以外の漢字の使用について

このマニュアルでは，常用漢字を使用することを基本としていますが，次に示す用語については，常用漢字以外の漢字を使用しています。

鍵（かぎ）　個所（かしょ）　全て（すべて）　脆弱（ぜいじゃく）　伝播（でんぱ）　汎用（はんよう）　必須（ひっす）　閉塞（へいそく）　漏洩（ろうえい）

KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

1.　Application Serverの概要

この章では，Application Serverの概要について説明します。

Application Serverは，アプリケーションの実行基盤であるアプリケーションサーバを中心としたシステムを構築・運用するための製品です。

＜この章の構成＞

1.1　Application Serverとは

1.2　J2EEアプリケーションを実行するアプリケーションサーバのプロセス

1.3　バッチアプリケーションを実行するアプリケーションサーバのプロセス

1.1　Application Serverとは

アプリケーションサーバは，情報システムの中で，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。アプリケーションの実行環境となるほか，アプリケーションからデータベースやメインフレームなどに接続する機能や，セッション管理，トランザクション管理に必要な機能も提供します。

Application Serverは，アプリケーションサーバを中心としたシステムを構築・運用するための製品です。Application Serverでは，次に示す四つの機能を提供しています。

アプリケーションの実行基盤としての機能

アプリケーションサーバを中心としたシステムの構築を支援する機能

アプリケーションサーバを中心としたシステムの運用を支援する機能

ほかのプログラムと連携する機能

また，Application Serverで構築したシステムでは，業務に応じて次の2種類のアプリケーションを実行できます。

オンライン業務
オンライン業務とは，ネットワーク経由などで送信されるクライアントからのリクエストを処理する業務です。オンライン業務を実行するためのアプリケーションの形式はJ2EEアプリケーションとなります。Application Serverでは，J2EEアプリケーションの実行基盤としての機能を提供しています。J2EEアプリケーションを実行する場合のApplication Serverの機能については，「2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）」を参照してください。

バッチ業務
バッチ業務とは，定型的または定期的な作業をまとめて処理する業務です。バッチ業務を実行するためのアプリケーションの形式は，バッチアプリケーションとなります。Application Serverでは，バッチアプリケーションの実行基盤としての機能を提供しています。バッチアプリケーションを実行する場合のApplication Serverの機能については，「3.　アプリケーションサーバの機能（バッチアプリケーションを実行する場合）」を参照してください。

ここでは，Application Serverの機能を紹介します。

参考

Application Serverは，Cosminexus Component Containerを中心とした，複数の構成ソフトウェアで構成されています。構成ソフトウェアについては，マニュアル「Cosminexus　概説」を参照してください。

＜この節の構成＞

1.1.1　アプリケーション実行基盤としての機能

1.1.2　システムの構築を支援する機能

1.1.3　システムの運用を支援する機能

1.1.4　ほかのプログラムと連携する機能

1.1.1　アプリケーション実行基盤としての機能

Application Serverでは，アプリケーション実行基盤の機能を提供しています。Application Serverで提供するアプリケーション実行基盤の機能には，業務の種類によって次の2種類があります。

J2EEアプリケーションの実行基盤としての機能
オンライン業務（J2EEアプリケーション）実行の基盤となる機能です。J2EEサーバを中心に構成されます。J2EEアプリケーションを実行するときのアプリケーションサーバのプロセスについては，「1.2　J2EEアプリケーションを実行するアプリケーションサーバのプロセス」を参照してください。

バッチアプリケーションの実行基盤としての機能
バッチ業務（バッチアプリケーション）実行の基盤となる機能です。バッチサーバを中心に構成されます。バッチアプリケーションを実行するときのアプリケーションサーバのプロセスについては，「1.3　バッチアプリケーションを実行するアプリケーションサーバのプロセス」を参照してください。

1.1.2　システムの構築を支援する機能

Application Serverではシステムの構築を支援するため，次のような機能を提供しています。

環境構築支援のための機能
システムの環境構築を支援するための機能として，Smart Composer機能およびセットアップウィザードを提供しています。Smart Composer機能のコマンドを使用してシステムを構築すると，複数のサーバに対して一括で設定できます。また，セットアップウィザードを使用すると，対話形式のウィザードプログラムを使用したシステム構築ができます。
Smart Composer機能およびセットアップウィザードで構築したシステムでは，Management Serverというプロセスを使用します。Management Serverは，アプリケーションサーバを構成するプロセスで，システム内のサーバを管理できます。Management Serverを使用することで，システムの一括運用が実現します。

J2EEアプリケーションやリソースアダプタの設定を支援する機能
システムに配置するJ2EEアプリケーションや，リソースとの接続に使用するリソースアダプタの設定を支援する機能として，CUIのサーバ管理コマンド，GUIのServer Plug-inを提供しています。サーバ管理コマンドまたはServer Plug-inを使用することで，J2EEアプリケーションやリソースアダプタのプロパティを設定したり，サーバにデプロイしたりできます。

システムの構築支援機能については，「16.　システムの構築」を参照してください。

1.1.3　システムの運用を支援する機能

Application Serverではシステムの運用を支援するため，次のような機能を提供しています。

Management Serverによる運用管理機能
Cosminexusシステムの運用管理プロセスとして，Management Serverがあります。Management Serverを利用すると，複数のホストで構成されるサーバに対して一括操作できるので，システムの一括運用が実現します。

システムの日常運用を支援する機能

システムの起動・停止機能
Smart Composer機能のコマンドでのシステムの起動・停止ができます。

稼働情報の監視機能
サーバの稼働状態やリソースの使用状況を監視する機能を提供しています。また，稼働情報をファイルに出力することもできます。稼働情報を監視することで，サーバの稼働状態を確認したり，設定パラメタをチューニングしたりできます。

トレース情報の取得・収集機能
システムの内部のイベント単位で，複数のノードやプロセス間にわたるトレース情報を取得する機能を提供しています。この機能によって，一連の処理の中でどの処理がボトルネックになっているかをトレースできます。

システムの日常運用を支援する機能については，「17.　システムの日常運用」を参照してください。

システムの保守を支援する機能

ログ運用および障害検知に使用する機能
ログの出力・収集，トラブルシューティング資料の収集などの機能が利用できます。これらの機能を使用することで，運用しているシステムの稼働状態の確認や，トラブル発生時の障害解析に利用できます。

システムの保守を支援する機能については，「18.　システムの保守」を参照してください。

J2EEアプリケーションの運用機能

J2EEアプリケーションの実行時間を監視する機能
EJBおよびWebアプリケーションのリクエスト実行時間を監視できます。J2EEアプリケーションで障害を検知すると，一定時間内に終了しなかったメソッド処理をキャンセルします。

J2EEアプリケーションの入れ替え機能
サービスの停止期間を最小限に抑えて，J2EEアプリケーションを入れ替えることができます。

J2EEアプリケーションのテスト機能
稼働中のJ2EEサーバ上で，テスト用としてJ2EEアプリケーションを動作できます。本番環境と同じ環境でテストを実施できます。

J2EEアプリケーションの運用機能については，「19.　J2EEアプリケーションの運用」を参照してください。

システムの監査を支援する機能

監査に必要な，操作や処理の履歴を記録する機能
システムやJ2EEアプリケーションに対する操作や処理の履歴など，監査の観点で必要な情報を記録する機能を利用できます。

システムの監査を支援する機能については，「20.　システムの監査」を参照してください。

1.1.4　ほかのプログラムと連携する機能

Application Serverで構築したシステムでは，ほかのプログラムと連携した運用を実現できます。連携できるプログラムについて説明します。

＜この項の構成＞

(1)　データベースとの連携

(2)　JP1との連携

(3)　クラスタソフトウェアとの連携

(1)　データベースとの連携

Application Serverを使用して構築したシステムはデータベースと連携できます。連携できるデータベースは次のとおりです。

HiRDB

Oracle

SQL Server

XDM/RD E2

Cosminexusではこれらのデータベースと接続するためのリソースアダプタを提供しています。

データベース接続については，「9.　リソース接続とトランザクション管理」を参照してください。

(2)　JP1との連携

Application Serverを使用して構築したシステムは，統合システム運用管理用ミドルウェアJP1と連携することで，さらに高い運用性を持つシステムになります。

JP1は，ジョブ管理，アベイラビリティ管理，ネットワーク管理など，システム運用に必要なさまざまな機能を統合管理できるミドルウェアです。JP1と連携すると，CosminexusシステムをJP1による統合運用管理の対象にできます。これによって，ほかの業務システムと統合した環境で，Cosminexusシステムの障害監視や稼働性能監視をしたり，サーバやアプリケーションの起動／停止を自動化したりできるようになります。

JP1と連携すると，次のような運用ができるようになります。

システムの集中監視
JP1/IMと連携して，Cosminexusシステムを含めたシステム全体の監視ができるようになります。集中監視では，障害が発生した場合や，あらかじめ指定しておいたしきい値を超える事象が発生した場合などに，運用管理者に自動アクションで通知するように設定できます。

システムの構成定義および管理
JP1/IM - CMと連携して，ユーザの視点で業務システムの構成を定義したり，定義した構成情報を管理したりできます。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。
なお，JP1/IM - CMと連携できるのは，Cosminexusで提供するSmart Composer機能を使用してシステムを構築する場合だけです。

カスタムジョブによるシステムの自動運転
JP1/AJS2と連携して，Cosminexusシステムの論理サーバやJ2EEアプリケーションの起動や停止のスケジュールをカスタムジョブに定義することで，システムの運用を自動化できます。これによって，日常運用に掛かる手間を削減できるほか，システムが空いている時間に処理ができるようになります。
また，システムに負荷を掛ける処理については，夜間にバッチで実行するなどして，システムリソースを有効に活用できます。JP1/AJS2と連携して，Cosminexusシステムの論理サーバやバッチアプリケーションの開始のスケジュールをカスタムジョブに定義することで，バッチアプリケーションの自動実行ができます。これによって，バッチ処理に掛かる手間を削減できます。

シナリオによるシステムの自動運転
JP1/AJS2 - SOと連携して，Cosminexusシステムの論理サーバやJ2EEアプリケーションの起動や停止のスケジュールをシナリオに定義することで，システムの運用を自動化できます。
なお，シナリオによるシステムの自動運転をする場合は，Smart Composer機能を使用して構築したシステムが前提となります。Cosminexusが提供するシナリオテンプレートを使用することで，Smart Composer機能を使用して構築したシステムの自動運転の定義が容易にできるようになります。

監査ログの収集と一元管理
JP1/NETM/Auditと連携して，Cosminexusが出力する監査ログを自動で収集，および一元管理できます。

JP1連携の詳細な内容については，「21.　JP1と連携したシステムの運用」を参照してください。

(3)　クラスタソフトウェアとの連携

Cosminexusシステムでは，クラスタソフトウェアと連携することで，Cosminexusシステムの信頼性や稼働率を向上できます。

クラスタソフトウェアは，システムを監視し，障害発生時などにサーバプログラムを含めたシステムの系切り替えを実行します。クラスタソフトウェアと連携すると，実行中のサーバシステムに障害が発生した場合，直ちに待機させておいたサーバシステムに自動的に切り替えることができます。これによって，障害によるサーバの不稼働時間を短縮でき，業務処理の中断を最小限に抑えることができます。

(a)　クラスタソフトウェアと連携してできる運用

クラスタソフトウェアと連携すると，次の運用ができるようになります。

実行系と待機系を1:1で運用するシステム
実行系のサーバと待機系のサーバが1:1で対応しているシステムです。これを1:1系切り替えシステムといいます。Cosminexusでは，アプリケーションサーバの1:1系切り替えシステムでの運用と，運用管理サーバの1:1系切り替えシステムでの運用をサポートしています。
1:1系切り替えシステムでは，実行系サーバの障害発生時やサーバを保守するときなどに，実行中のサーバをあらかじめ待機させておいたサーバに切り替えることができます。切り替えは，オペレータが意識することなく，自動でできます。

相互スタンバイで運用するシステム
2台のアプリケーションサーバが現用系として動作しながら，互いの予備系になる構成です。どちらか一方のアプリケーションサーバに障害が発生すると，他方のアプリケーションサーバに自動的に処理が引き継がれます。これを相互系切り替えシステムといいます。Cosminexusでは，アプリケーションサーバの相互系切り替えシステムでの運用をサポートしています。

待機系をリカバリ専用サーバとして運用するシステム
クラスタ構成となっているN台の実行系アプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。これをN:1リカバリシステムといいます。
N:1リカバリシステムでは，クラスタ構成の実行系のアプリケーションサーバで障害が発生したときに，障害が発生したアプリケーションサーバの仕掛かり中のトランザクションを，待機系のリカバリ専用サーバで決着することができます。

(b)　Cosminexusがサポートするクラスタソフトウェア

Cosminexusでは，Microsoft Cluster Service，またはHAモニタと連携したシステムの運用をサポートしています。Cosminexusがサポートするクラスタソフトウェアと実行環境のOSとの対応を次の表に示します。

表1-1　Cosminexusがサポートするクラスタソフトウェアと実行環境のOSとの対応

クラスタソフトウェア | 実行環境のOS種別
Windows※ | AIX | HP-UX | Linux | Solaris
Microsoft Cluster Service | ○ | × | × | × | ×
HAモニタ | × | ○ | ○ | ○ | ×

（凡例）　○：使用できる　　×：使用できない

注※　Microsoft Cluster Serviceと連携する場合，Windows Server 2003 Enterprise Edition，Windows Server 2003 R2 Enterprise Edition，Windows Server 2003 Enterprise x64 Edition，またはWindows Server 2003 R2 Enterprise x64 Editionが前提OSとなります。

クラスタソフトウェアとの連携の詳細な内容については，「22.　クラスタソフトウェアと連携したシステムの運用」を参照してください。

1.2　J2EEアプリケーションを実行するアプリケーションサーバのプロセス

ここでは，J2EEアプリケーションを実行するアプリケーションサーバのプロセス構成とJ2EEサーバの構成について説明します。

＜この節の構成＞

1.2.1　J2EEアプリケーションを実行する場合のプロセス構成

1.2.2　J2EEサーバの構成

1.2.3　J2EEアプリケーションとJ2EEコンポーネント

1.2.4　J2EEコンテナ

1.2.5　J2EEサービス

1.2.6　J2EEリソース

1.2.7　コンテナ拡張ライブラリ

1.2.8　サーバの動作モード

1.2.1　J2EEアプリケーションを実行する場合のプロセス構成

J2EEアプリケーションを実行するアプリケーションサーバは，次の図に示すプロセスで構成されます。

図1-1　J2EEアプリケーションを実行するアプリケーションサーバを構成するプロセス

参考

なお，システムを構築する場合は，これらのプロセスをシステムの要件に合わせて，システム内の各マシンに一つまたは複数配置します。プロセスの配置など，システム構成の検討については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

それぞれのプロセスについて説明します。なお，図中の番号は，(1)～(6)に対応します。

＜この項の構成＞

(1)　J2EEサーバ

(2)　Webサーバ

(3)　CTM

(4)　PRFデーモン（パフォーマンストレーサ）

(5)　運用管理エージェント

(6)　Management Server

(7)　そのほかのプロセス

(1)　J2EEサーバ

J2EEサーバは，J2EEアプリケーションの実行基盤となるプロセスです。J2EEサーバは，J2EEアプリケーション，J2EEコンテナ，J2EEサービス，J2EEリソースなど，複数のプログラムモジュールで構成されます。また，J2EEコンテナは，提供する機能によって，EJBコンテナとWebコンテナに分けられます。J2EEサーバを構成するプログラムモジュールについては，「1.2.2　J2EEサーバの構成」で説明します。

(2)　Webサーバ

Webサーバは，Webブラウザからのリクエスト受信，およびWebブラウザへのデータ送信に関連する処理を実行するプロセスです。J2EEサーバ上で動作するJ2EEアプリケーションにWebブラウザからアクセスするシステムの場合に，Webサーバを使用する必要があります※。なお，Webブラウザからアクセスできるのは，J2EEアプリケーションに含まれるサーブレット，JSP，または静的コンテンツです。

Cosminexusでは，Webサーバとして，Hitachi Web ServerまたはMicrosoft IISを使用できます。Hitachi Web Serverは，Application Serverの構成ソフトウェアの一つです。Hitachi Web Serverの機能については，マニュアル「Hitachi Web Server」を参照してください。

注※

Webサーバを経由しないでJ2EEサーバとWebブラウザ間で直接リクエストを送受信する機能（インプロセスHTTPサーバ機能）を使用する場合，Webサーバに相当するプロセスは不要です。インプロセスHTTPサーバ機能は，Webコンテナの機能です。詳細は，「4.3　インプロセスHTTPサーバによるリクエストの受け付け」を参照してください。

(3)　CTM

CTMは，J2EEアプリケーション内のSession Beanに対するリクエストをスケジューリングするためのプロセス群です。CTMを使用することで，クライアントからのリクエストを適切に分散，スケジューリングできます。これによって，サーバの負荷を抑え，システムの可用性を高めて業務を滞りなく進めるようにできます。

CTMとしての機能は，CTMデーモン，CTMレギュレータ，CTMドメインマネジャなどの，複数のプロセスを使用して実現します。また，ネーミングサービスとして，CORBAネーミングサービスを使用します。

CTMの機能の詳細については，「11.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

ポイント

CTMは，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できます。利用できる製品については，マニュアル「Cosminexus　概説」を参照してください。

(4)　PRFデーモン（パフォーマンストレーサ）

アプリケーションサーバは，リクエストを処理するときに，トレース情報をバッファに出力します。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。PRFデーモンが出力するトレース情報ファイルは，システムのボトルネックを検証したり，トラブルシュートの効率向上を図ったりするために役立ちます。

PRFデーモンの機能の詳細については，「17.10　システムの処理性能の解析」を参照してください。

(5)　運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェント機能を持つプロセスです。なお，論理サーバとは，Management Serverの運用管理の対象になる，サーバまたはクラスタです。

(6)　Management Server

運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行するためのプロセスです。

(7)　そのほかのプロセス

(1)～(6)で示したプロセス以外に，機能に応じて使用するプロセスとして，次のプロセスがあります。

SFOサーバ
セッションフェイルオーバ機能を使用する場合に必要なプロセスです。詳細については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

ユーザサーバ
ユーザサーバとは，ユーザが定義する任意のサービスやプロセスです。ユーザサーバは論理サーバ（論理ユーザサーバ）として定義できます。論理ユーザサーバとして定義することで，特定のサービスやプロセスがManagement Serverの管理対象となります。これによって，ほかの論理サーバと同様に，Management Serverで一括管理できるようになります。

旧バージョンとの互換用のプロセス
旧バージョンとの互換用の機能を使用する場合に使用するプロセスです。

Webコンテナサーバ
サーバの動作モードとしてサーブレットエンジンモードを使用する場合に，Webアプリケーションの実行基盤となるプロセスです。Webコンテナサーバでは，Webコンテナの機能を使用できます。なお，サーブレットエンジンモードの場合のWebコンテナの機能については，「付録C　サーブレットエンジンモードで使用できるWebコンテナの機能」を参照してください。

1.2.2　J2EEサーバの構成

J2EEサーバとは，次に示す五つのプログラムモジュールを実行するJavaアプリケーションです。

J2EEアプリケーション（サーブレット，JSP，Enterprise Beanなど）

J2EEコンテナ

J2EEサービス
JNDI，JavaMail，JTA，RMI-IIOP，JDBC，ネーミング管理，トランザクション管理，セキュリティなど

J2EEリソース

コンテナ拡張ライブラリ

J2EEアプリケーションは，サーブレット，JSP，Enterprise Beanなどによって構成されています。J2EEアプリケーションは，業務の内容に応じて，ユーザが開発します。なお，J2EEアプリケーション以外のプログラムモジュールは，Application Serverで提供されているモジュールです。

J2EEサーバの構造を次の図に示します。

図1-2　J2EEサーバの構造

以降の項で，J2EEサーバの各モジュールの概要を説明します。

1.2.3　J2EEアプリケーションとJ2EEコンポーネント

J2EEアプリケーションは，一つ以上のJ2EEコンポーネントで構成されています。ここでは，J2EEアプリケーションとJ2EEコンポーネントについて説明します。

＜この項の構成＞

(1)　J2EEアプリケーションとJ2EEコンポーネントの関係

(2)　J2EEアプリケーションの構造

(3)　J2EEアプリケーションおよびJ2EEコンポーネントの開発

(1)　J2EEアプリケーションとJ2EEコンポーネントの関係

J2EEアプリケーションは，サーブレット，JSP，Enterprise Beanなどのユーザアプリケーションプログラムで構成されています。J2EEアプリケーションは，J2EEコンテナ上で動作します。

J2EEアプリケーションを構成する，サーブレット，JSP，Enterprise BeanなどをJ2EEコンポーネントといいます。

J2EEアプリケーションとJ2EEコンポーネントの関係を次の図に示します。

図1-3　J2EEアプリケーションとJ2EEコンポーネントとの関係

(2)　J2EEアプリケーションの構造

J2EEアプリケーションは，3層の構造になっています。J2EEアプリケーションの構造を次の図に示します。

図1-4　J2EEアプリケーションの構造

J2EEアプリケーションの最小単位は，階層3のファイル（図中，点線で囲まれたファイル）です。階層3のファイルには，クラスファイルやJSPファイルなどがあります。

そして，階層3のファイルをパッケージしたものが階層2のファイルとなります。この図の場合，階層2のEJB-JARファイルは，階層3に属するEnterprise BeanとDD（ejb-jar.xml）をパッケージしたものとなります。

さらに，階層2のそれぞれのファイルをパッケージしたものが階層1のJ2EEアプリケーションとなります。

ここでは，階層1および階層2のパッケージファイルについて説明します。なお，図中の項番は次の説明の項番と対応しています。

参考

それぞれの階層でファイル形式，およびDDのDTDが規定されています。

DDとは，アプリケーションを運用環境に配置するときの定義情報を記述したファイルを指します。EJB-JARの場合，DDはejb-jar.xml，Webアプリケーションの場合，DDはweb.xml，J2EEアプリケーションの場合，DDはapplication.xmlとなります。

なお，Enterprise Beanでアノテーションを使用する場合，ejb-jar.xmlは不要です。

(a)　J2EEアプリケーション

J2EEアプリケーションは，複数の，EJB-JAR，Webアプリケーション，ライブラリJARと，一つのDD（application.xml）で構成されます。

J2EEサーバで実行できるJ2EEアプリケーションは，アーカイブ形式のJ2EEアプリケーション，および展開ディレクトリ形式のJ2EEアプリケーションです。

アーカイブ形式のJ2EEアプリケーション
EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションです。アーカイブ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，EAR形式またはZIP形式へのアセンブルと，デプロイが必要です。

展開ディレクトリ形式のJ2EEアプリケーション
EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションです。展開ディレクトリ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，デプロイが必要です。

参考

アセンブルとは，単体では動作しないEJB-JARをアプリケーションの1構成要素として位置づけるための組み立て作業のことです。アセンブルでは，EJB-JARを1構成要素として取り込んだJ2EEアプリケーションを構築します。なお，J2EEアプリケーションの構成要素として，EJB-JARのほかにWARファイル，ライブラリJARを含むことがあります。
展開ディレクトリ形式のJ2EEアプリケーションの場合には，EAR形式またはZIP形式へのアセンブルは不要です。

デプロイとは，J2EEアプリケーションをクライアントから実行可能な状態にすることです。

(b)　EJB-JAR

EJB-JARは，EJB-JARファイル形式でパッケージ化されています。複数のEnterprise Beanと一つのDD（ejb-jar.xml）で構成されます。なお，Enterprise Beanでアノテーションを使用している場合は，DD（ejb-jar.xml）は不要です。

(c)　Webアプリケーション

Webアプリケーションは，WARファイル形式でパッケージ化されています。複数のサーブレット，JSP，HTMLと一つのDD（web.xml）で構成されます。

(d)　ライブラリJAR

ライブラリJARは，JARファイル形式でパッケージ化されたものです。複数の共通ライブラリから構成されています。共通ライブラリはJ2EEアプリケーション中のJ2EEコンポーネントが共通で使用できるライブラリです。J2EEアプリケーションのDD（application.xml）の<module>タグ以下に定義されているファイル以外で，拡張子が小文字（.jar）のJARファイルがライブラリJARとみなされます。

(3)　J2EEアプリケーションおよびJ2EEコンポーネントの開発

J2EEアプリケーションでApplication Serverが提供する実行基盤としての機能を使用するためには，機能に応じたアプリケーションの実装が必要です。なお，Cosminexusでは，J2EEアプリケーションおよびJ2EEコンポーネントを開発するための製品として，Developerを提供しています。

J2EEアプリケーションおよびJ2EEコンポーネントの開発方法については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。

1.2.4　J2EEコンテナ

J2EEコンテナとは，J2EEアプリケーションを実行するためのサーバ基盤です。J2EEコンテナは，EJBコンテナとWebコンテナで構成されています。

J2EEコンポーネントはWebコンテナおよびEJBコンテナで提供するAPIを利用して，J2EEコンテナ上で動作します。Cosminexusで提供しているWebコンテナおよびEJBコンテナは，J2EE 1.4に対応しています。これによって，J2EEに準拠する，本格的な基幹業務アプリケーションを迅速かつ容易に構築できます。各APIのバージョンについては，「1.2.8　サーバの動作モード」を参照してください。

＜この項の構成＞

(1)　Webコンテナ

(2)　EJBコンテナ

(1)　Webコンテナ

Webコンテナは，サーブレットとJSPを実行するためのサーバ基盤です。Webクライアントからアクセスを受け取り，要求に応じたサービスを提供します。

Webコンテナでは，サーブレット，JSPのAPIを提供しています。

(2)　EJBコンテナ

EJBコンテナは，Enterprise Beanの実行を制御し，Enterprise Beanに各種のサービスを提供するサーバ基盤です。EJBコンテナでは，EJBのAPIを提供しています。

1.2.5　J2EEサービス

J2EEサービスでは，次に示す機能およびAPIを提供しています。

トランザクション管理，セキュリティ管理，およびネーミング管理の機能

JDNI，JDBC，JTA，RMI-IIOP，JavaMail，JMSなどのAPI

J2EEサービスは，J2EEコンテナの部品機能として利用され，J2EEコンポーネントである，サーブレット・JSP，およびEnterprise Beanに，機能およびAPIを提供します。J2EEサービスのAPIは，J2EEコンポーネントによって，直接，またはJ2EEコンテナ経由で利用されます。

J2EEサービスの位置づけを次の図に示します。

図1-5　J2EEサービスの位置づけ

J2EEサービスでは，Application Serverの構成ソフトウェアの機能のほか，Application Server以外の製品の機能も使用します。J2EEサービスを実現する，ソフトウェア製品またはApplication Serverの構成ソフトウェアを次の表に示します。

表1-2　J2EEサービスを実現する，製品または構成ソフトウェア

分類
製品または構成ソフトウェア

サービス
ネーミング管理
Cosminexus Component Container※
Cosminexus TPBroker※

トランザクション管理

セキュリティ
Cosminexus Component Container※

API
JNDI

JTA

JavaMail

RMI-IIOP
Cosminexus TPBroker※

JDBC Standard Extension
HiRDB Type4 JDBC Driver
Cosminexus DABroker Library※
Oracle JDBC Thin Driver
SQL Server Driver for JDBC

JDBC

JMS
Cosminexus RM※
TP1/Message Queue - Access

注※　Application Serverの構成ソフトウェアです。

1.2.6　J2EEリソース

J2EEサーバはリソースとして，データベース，OpenTP1，SMTPサーバ，およびJavaBeansリソースを利用できます。J2EEリソースは，これらのリソースと接続するために使用します。

Cosminexusで扱うJ2EEリソースには，外部リソースとの接続に利用するリソースアダプタ，およびメールコンフィグレーションがあります。また，このほかに，内部リソースとして利用できるJavaBeansリソースがあります※1。

リソースアダプタ
接続するリソースの種類に応じて，次のリソースアダプタがあります。

DB Connector
データベースとの接続に利用します。

DB Connector for Cosminexus RMおよびCosminexus RM
データベース上のキューとの接続に利用します。

uCosminexus TP1 Connector
OpenTP1のSPPとの接続に利用します。

TP1/Message Queue - Access
TP1/Message Queueとの接続に利用します。

そのほかのConnector 1.0またはConnector 1.5※²に準拠したリソースアダプタ
任意のリソースとの接続に使用します。

メールコンフィグレーション
SMTPサーバとの接続に利用します。

JavaBeansリソース
内部のリソースとして利用できるリソースです。

J2EEリソースの詳細については，「9.　リソース接続とトランザクション管理」を参照してください。

注※1　このほかに，互換用のモードであるベーシックモードで使用するデータソースがあります。データソースについては，「付録B　ベーシックモードでのリソース接続」を参照してください。

注※2　Outboundの通信モデルに対応したリソースアダプタを使用できます。詳細は，「9.2.2(2)　Connector 1.5仕様に準拠したリソースアダプタ」を参照してください。

1.2.7　コンテナ拡張ライブラリ

Enterprise Bean，サーブレット，JSPが利用する共通のライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することによって，Enterprise Bean，サーブレット，JSPからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリについては，「10.　コンテナ拡張ライブラリ」を参照してください。

1.2.8　サーバの動作モード

サーバの動作モードには，J2EEサーバモードとサーブレットエンジンモードがあります。さらに，J2EEサーバモードには，1.4モード，およびベーシックモードの2種類があります。このうち，ベーシックモードとサーブレットエンジンモードは，互換用の動作モードとなります。

このマニュアルのサーバの動作モードに関する記述は，すべて1.4モードの説明となります。なお，ベーシックモードおよびサーブレットエンジンモードについては，「付録A　旧バージョンとの互換用機能」を参照してください。

1.4モードで動作するWebコンテナは，J2EEのほかの要素と連携し，J2EEサーバの一部として動作します。この場合，Webコンテナ上で動作するWebアプリケーションからは，J2EEが定める幾つかのJ2EE関連のAPIを利用できます。

1.4モードで使用できるJ2EEの機能を次に示します。

Servlet 2.3/Servlet 2.4

JSP 1.2/JSP 2.0※1

EJB 2.0

Message-driven Bean

ローカルインタフェース

CMP 1.1

CMP 2.0

EJB 2.1※2

ビジネスインタフェース/アノテーション/DI

JDBC 2.0コア/JDBC 2.0オプションパッケージ

JDBC 3.0※3

JMS 1.0.2※4

JMS 1.1※5

Connector 1.0（JCA 1.0）

Connector 1.5（JCA 1.5）

JTA 1.0.1

local※6

global※7

JavaMail 1.2※8

JavaMail 1.3※8

注※1

JSP 1.1は使用できません。

注※2

CMP機能のうちEJB2.1での拡張部分，<service-ref>タグを使用したWebサービス連携機能は使用できません。

注※3

接続に使用するJDBCドライバが，JDBC 3.0仕様で規定された機能をサポートしている必要があります。

注※4

Cosminexus RMまたはTP1/Message Queue - Accessを使用する場合は，JMS1.0.2であることが前提です。また，Topicを含む一部の機能に制限があります。

注※5

JMS1.1を使用する場合，次の条件があります。

JMSプロバイダがJMS1.1に対応していること

Message-driven BeanがEJB2.1に対応していること（Message-driven Beanを使用する場合）

使用するリソースアダプタがConnector 1.5に対応していること

注※6

リソースアダプタのDD（ra.xml）のtransaction-supportでLocalTransactionを指定し，ビジネスロジック中にリモートでJavaVMの呼び出しをしない場合に，ローカルトランザクションが利用できます。

注※7

ライトトランザクションが有効になっているときは，グローバルトランザクションを使用できません。なお，ライトトランザクションについては，「9.10.4　ライトトランザクション」を参照してください。

注※8

JavaMailで使用できるサービスプロバイダはSMTPだけです。メールの送信機能だけを使用できます（メールの受信機能は使用できません）。

1.3　バッチアプリケーションを実行するアプリケーションサーバのプロセス

ここでは，バッチアプリケーションを実行するアプリケーションサーバのプロセス構成と，バッチサーバの構成について説明します。

＜この節の構成＞

1.3.1　バッチアプリケーションを実行する場合のプロセス構成

1.3.2　バッチサーバの構成

1.3.3　バッチアプリケーション

1.3.4　バッチサービス

1.3.5　J2EEサービス

1.3.6　J2EEリソース

1.3.7　コンテナ拡張ライブラリ

1.3.1　バッチアプリケーションを実行する場合のプロセス構成

バッチアプリケーションを実行するアプリケーションサーバは，次の図に示すプロセスで構成されます。

図1-6　バッチアプリケーションを実行するアプリケーションサーバを構成するプロセス

参考

システムを構築する場合は，これらのプロセスをシステムの要件に合わせて，システム内の各マシンに一つまたは複数配置します。プロセスの配置など，システム構成の検討については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

それぞれのプロセスについて説明します。なお，図中の番号は，(1)～(4)に対応します。

＜この項の構成＞

(1)　バッチサーバ

(2)　PRFデーモン（パフォーマンストレーサ）

(3)　運用管理エージェント

(4)　Management Server

(1)　バッチサーバ

バッチサーバは，バッチアプリケーションの実行基盤となるプロセスです。バッチサーバは，バッチアプリケーション，バッチサービス，J2EEサービス，J2EEリソースなど，複数のプログラムモジュールで構成されます。バッチサーバを構成するプログラムモジュールについては，「1.3.2　バッチサーバの構成」で説明します。

(2)　PRFデーモン（パフォーマンストレーサ）

アプリケーションサーバは，トレース情報をバッファに出力します。PRFデーモン（パフォーマンストレーサ）は，バッファに出力されたトレース情報をファイルに出力するためのI／Oプロセスです。PRFデーモンが出力するトレース情報ファイルは，システムのボトルネックを検証したり，トラブルシュートの効率向上を図ったりするために役立ちます。

PRFデーモンの機能の詳細については，「17.10　システムの処理性能の解析」を参照してください。

(3)　運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェント機能を持つプロセスです。なお，論理サーバとは，Management Serverの運用管理の対象になる，サーバまたはクラスタです。

(4)　Management Server

運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行するためのプロセスです。

参考

バッチサーバの場合，(1)～(4)で示したプロセス以外に，システムの目的に応じてユーザサーバというプロセスを使用できます。ユーザサーバとは，ユーザが定義する任意のサービスやプロセスです。ユーザサーバは論理サーバ（論理ユーザサーバ）として定義できます。論理ユーザサーバとして定義することで，特定のサービスやプロセスがManagement Serverの管理対象となります。これによって，ほかの論理サーバと同様に，Management Serverで一括管理できるようになります。

1.3.2　バッチサーバの構成

バッチサーバとは，次に示す五つのプログラムモジュールを実行するJavaアプリケーションです。

バッチアプリケーション

バッチサービス

J2EEサービス
JNDI，JTA，RMI-IIOP，JDBC，ネーミング管理，トランザクション管理など

J2EEリソース

コンテナ拡張ライブラリ

バッチアプリケーションとは，バッチ処理を実装したJavaアプリケーションです。バッチアプリケーションは，業務の内容に応じてユーザが開発します。なお，バッチアプリケーション以外のプログラムモジュールは，Application Serverで提供されているモジュールです。

バッチサーバの構造を次の図に示します。

図1-7　バッチサーバの構造

バッチサーバでは次に示すJ2EEの機能を使用できます。

JDBC 2.0コア/JDBC 2.0オプションパッケージ

Connector 1.0（DB Connector）※1

JTA 1.0.1（ただし，localだけ）※2

注※1

トランザクションなし，またはローカルトランザクションのDB Connectorを使用できます。

注※2

リソースアダプタのDD（ra.xml）のtransaction-supportでLocalTransactionを指定し，ビジネスロジック中にリモートでJavaVMの呼び出しをしない場合に，ローカルトランザクションが利用できます。

また，バッチサーバから次のEJBを呼び出せます。ただし，EJBの呼び出し方法はリモート呼び出しとなります。ローカル呼び出しはできません。

EJB 2.0

EJB 2.1

ビジネスインタフェース/アノテーション/DI

以降の項で，バッチサーバの各モジュールの概要を説明します。

1.3.3　バッチアプリケーション

バッチアプリケーションとは，バッチ処理を実装したJavaアプリケーションです。バッチアプリケーションは，一つのバッチサーバにつき一つ実行できます。複数のバッチアプリケーションを並行して実行したい場合は，バッチアプリケーションごとにバッチサーバを用意してください。

バッチアプリケーションを開始するには，Cosminexusで提供しているバッチ実行コマンドを使用します。また，JP1/AJS2と連携するとバッチ実行コマンドをJP1のジョブとして定義できるので，バッチアプリケーションの自動実行ができます。

バッチアプリケーションの詳細については，「15.　バッチアプリケーション」を参照してください。

1.3.4　バッチサービス

バッチアプリケーションを実行するアプリケーションサーバでは，バッチサービスを提供しています。バッチサービスとは，バッチアプリケーションを実行するための機能です。バッチサービスでは，次の図に示す機能を提供しています。

図1-8　バッチサービスで提供している機能

バッチアプリケーション実行機能
バッチアプリケーションを開始したり，強制停止したりするための機能を提供しています。

EJBアクセス機能
バッチアプリケーションからJ2EEサーバのEJBにアクセスするための機能を提供しています。EJBアクセス機能はJ2EEサービスを使用します。

リソース接続機能
バッチアプリケーションからデータベースに接続するための機能を提供しています。リソース接続機能は，J2EEサービスおよびJ2EEリソースを使用します。

ガーベージコレクション制御機能
バッチアプリケーションでリソース排他をしているときに，ガーベージコレクションの実行を制御するための機能を提供しています。

ネーミング管理機能
EJBまたはリソースを参照するときに，名前解決をするための機能を提供しています。ネーミング管理機能はJ2EEサービスを使用します。

バッチサービスで提供するそれぞれの機能については，「3.2　バッチアプリケーション実行基盤の機能の概要」を参照してください。

1.3.5　J2EEサービス

J2EEサービスでは，次に示す機能およびAPIを提供しています。

トランザクション管理，およびネーミング管理の機能

JDNI，JDBC，JTA，RMI-IIOPなどのAPI

J2EEサービスは，バッチアプリケーションからデータベースに接続したり，EJBを呼び出したりするときに利用されます。

J2EEサービスでは，Application Serverの構成ソフトウェアの機能のほか，Application Server以外の製品の機能も使用します。J2EEサービスを実現する，ソフトウェア製品またはApplication Serverの構成ソフトウェアを次の表に示します。

表1-3　J2EEサービスを実現する，製品または構成ソフトウェア

分類
製品または構成ソフトウェア

サービス
ネーミング管理
Cosminexus Component Container※
Cosminexus TPBroker※

トランザクション管理

API
JNDI
Cosminexus Component Container※

JTA

RMI-IIOP
Cosminexus TPBroker※

JDBC Standard Extension
HiRDB Type4 JDBC Driver
Cosminexus DABroker Library※
Oracle JDBC Thin Driver
SQL Server Driver for JDBC

JDBC

注※　Application Serverの構成ソフトウェアです。

1.3.6　J2EEリソース

J2EEリソースはリソースと接続するために使用します。バッチサーバではリソースとしてデータベースを利用できます。データベースに接続するには，Cosminexusで扱うJ2EEリソースのうちリソースアダプタを使用します。

J2EEリソースの詳細については，「14.5　リソース接続とトランザクション管理が提供する機能」を参照してください。

1.3.7　コンテナ拡張ライブラリ

アプリケーションが利用する共通のライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することによって，バッチアプリケーションからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリについては，「10.　コンテナ拡張ライブラリ」を参照してください。

2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）

この章では，J2EEアプリケーションを実行するアプリケーションサーバの機能について説明します。また，実行環境で使用するオプション製品の機能や旧バージョンとの互換用の機能についても説明します。

なお，Developerの機能については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。また，uCosminexus Service PlatformおよびuCosminexus Service Architectの機能については，マニュアル「Cosminexus サービスプラットフォーム　概説」を参照してください。

＜この章の構成＞

2.1　Application Serverで提供する機能の目的

2.2　J2EEアプリケーション実行基盤の機能の概要

2.3　システム構築時に使用する機能の概要

2.4　システム運用時に使用する機能の概要

2.5　ほかのプログラムと連携する機能の概要

2.6　オプション製品の機能

2.7　旧バージョンとの互換用の機能

2.1　Application Serverで提供する機能の目的

J2EEアプリケーションを実行するアプリケーションサーバの場合，Application Serverで提供する次の四つの機能を使用できます。

J2EEアプリケーションの実行基盤としての機能

アプリケーションサーバを中心としたシステムの構築を支援する機能

アプリケーションサーバを中心としたシステムの運用を支援する機能

ほかのプログラムと連携する機能

これらの機能は，システムで求められる次のような目的に対応しています。

アベイラビリティとフォールトトレランスの向上

システム性能の向上

効率的で確実な運用・保守の実現

システム規模の変更への柔軟な対応

なお，これらの目的に直接対応しない機能もあります。例えば，画面表示，文字コード変換，システムの構築支援などの機能が該当します。

システムの目的と，対応するアプリケーションサーバの機能の概要について，次の表に示します。

表2-1　システムの目的と対応するアプリケーションサーバの機能の概要

システムの目的※ | 対応するアプリケーションサーバの機能の概要
アベイラビリティとフォールトトレランスの向上［信頼性］ | システムとしての信頼性を高めるための機能を提供しています。アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が含まれます。
システム性能の向上［性能］ | システムの性能を向上させるための機能を提供しています。この機能によって，システムのパフォーマンス・チューニングができます。
効率的で確実な運用・保守の実現［運用・保守］ | システムを効率良く確実に運用・保守する機能を提供しています。
システム規模の変更への柔軟な対応［拡張性］ | システム規模の拡大・縮小および構成の変更に柔軟に対応するための機能を提供しています。
そのほかの目的［そのほか］ | Webブラウザ上での表示に関する機能，文字コード変換機能，システムの構築を支援する機能など，そのほかの目的で使用される機能を提供しています。

注※　［　］内は，以降の節の表に示す「目的」列の表記と対応しています。

また，J2EEアプリケーション実行基盤では，J2EE標準に準拠した機能と，Application Server独自の機能を使用できます。Application Server独自の機能とは，J2EEの機能に加えてApplication Serverが拡張している機能や，J2EE機能と直接は関係ないApplication Server独自で提供する機能のことです。

以降の節では，Application Serverの機能を分類して，それぞれがどの特性に対応するかを示します。また，それぞれの機能の概要についても説明します。

ポイント

2.2以降で記載している表は，次の形式で記載しています。

「機能名」は，機能の名称を示します。

「目的」列は，表2-1で記載したシステムの目的に対応しています。

「J2EE標準への準拠」列は，その機能がJ2EEで規定された機能であるかどうかを示します。

「参照先」は，その機能について詳細に説明している個所を示します。

2.2　J2EEアプリケーション実行基盤の機能の概要

ここでは，Application Serverが提供する機能のうち，J2EEアプリケーション実行基盤としての機能の特性について説明します。J2EEアプリケーション実行基盤の機能として，次に示す機能があります。

Webコンテナが提供する機能

EJBコンテナが提供する機能

EJBクライアントの実行機能

J2EEアプリケーションの実行機能

ネーミング管理が提供する機能

リソース接続とトランザクション管理が提供する機能

コンテナ拡張ライブラリが提供する機能

CTMが提供する機能

Cosminexusシステムのユーザを統合管理する機能（統合ユーザ管理）

＜この節の構成＞

2.2.1　Webコンテナが提供する機能の概要

2.2.2　EJBコンテナが提供する機能の概要

2.2.3　EJBクライアントの実行機能の概要

2.2.4　J2EEアプリケーションの実行機能の概要

2.2.5　ネーミング管理が提供する機能の概要

2.2.6　リソース接続とトランザクション管理が提供する機能の概要

2.2.7　コンテナ拡張ライブラリが提供する機能の概要

2.2.8　CTMが提供する機能の概要

2.2.9　Cosminexusシステムのユーザを統合管理する機能の概要

2.2.1　Webコンテナが提供する機能の概要

Webコンテナが提供する機能の概要について説明します。なお，使用するWebサーバの種類によって，使用できる機能が一部異なります。

機能の詳細，およびWebサーバの種類による機能差異については，「4.　Webコンテナ」を参照してください。

Webアプリケーションの実行
サーブレットとJSPで構成されたWebアプリケーションを実行できます。

インプロセスHTTPサーバによるリクエストの受け付け
Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。

セッション管理
リクエストとWebクライアントを関連づけて管理することによって，同じWebクライアントから複数のWeb画面の操作ができます。これによって，クラスタリング時のクライアント識別や，ログイン済みクライアントの識別ができます。
また，HttpSessionオブジェクト数の上限値を設定したり，セッションIDやCookieにサーバIDを付けたりできます。

文字コード変換
文字コードを指定してデータをアップロードできます。

デフォルトの文字エンコーディング設定
リクエスト，レスポンスなどで使用するデフォルトの文字エンコーディングを，J2EEサーバ単位またはWebアプリケーション単位で設定できます。

JSPの事前コンパイルとコンパイル結果の保持
Webアプリケーションに含まれるJSPファイルを，デプロイ前にコンパイルし，クラスファイルを生成できます。また，デプロイ時にコンパイルされたJSPのコンパイル結果を保持しておき，サーバ再起動時のオーバーヘッドを少なくできます。

アプリケーションのイベントリスナ
セッションオブジェクト，サーブレットコンテキストオブジェクトの状態変化に合わせて処理を実行できます。

タグファイルの実行
JSP 2.0で規定されているJSPの構文に従って作成されたタグファイルを実行できます。

JSP ELの実行
JSP 2.0で規定されているELの構文に従って作成されたEL式を実行できます。

リクエストおよびレスポンスのフィルタリング
サーブレットやJSPからの，リクエストおよびレスポンスをフィルタリングできます。
なお，Cosminexusでは，次に示す機能を使用するためのサーブレットフィルタ（built-inフィルタ）を提供しています。

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）

HTTPレスポンスの圧縮

フィルタリングによるHTTPレスポンスの圧縮
サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスを圧縮できます。この機能は，Webアプリケーションに組み込んで動作させるサーブレットフィルタとして提供されています。これを，HTTPレスポンス圧縮用フィルタといいます。
この機能を使用することによって，WebコンテナとWebクライアント（ブラウザなど）との間のHTTPレスポンス通信に掛かる時間を削減できます。

Webコンテナのセキュリティ管理
SSL，ロール，またはSecurityManagerに基づくWebコンテナのセキュリティ管理ができます。

EJBコンテナとの連携
EJBコンテナと連携して，WebアプリケーションからEnterprise Beanを呼び出せます。

データベースとの接続
データベースにアクセスできます。

Webコンテナによるスレッドの作成
Webサーバ連携用のスレッド，インプロセスHTTPサーバ用のスレッドや，Webアプリケーション用のスレッドなどを，Webコンテナによって作成，制御できます。

同時実行スレッド数の制御
Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位で同時実行スレッド数を制御することで，処理性能の向上が図れます。
なお，Webアプリケーション単位での同時実行スレッド数は，動的に変更できます。

ユーザスレッドの使用
ユーザスレッドとは，ユーザがプログラムの中で明示して生成するスレッドのことです。Cosminexusでは，サーブレットおよびJSPからスレッドを作成して使用できます。

通信タイムアウトの設定
クライアント－Webサーバ間，Webサーバ－Webコンテナ間で，リクエスト送受信時およびレスポンス送受信時の通信タイムアウトを設定しておき，トラブル発生時の応答待ちなどの場合に通信タイムアウトを検知できます。

Webサーバ（リダイレクタ）によるリクエストの振り分け
Webサーバに登録したリダイレクタによって，リクエストをURLパターン，ラウンドロビン方式またはPOSTデータサイズで複数のWebコンテナに振り分けて処理できます。

エラーページのカスタマイズ
クライアントから存在しないリソースに対してアクセスした場合などに，クライアントからのリクエストに対してユーザがカスタマイズしたエラーページを表示できます。エラーページの表示は，リダイレクタが実行します。

ドメイン名指定でのトップページの表示
ドメイン名指定によってWebアプリケーションのトップページを表示するようにできます。

Webコンテナへのゲートウェイ情報の通知
クライアントとWebサーバとの間にSSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知して，welcomeファイルやForm認証画面に自動的に正しくリダイレクトできます。

Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレスの指定
Webサーバ連携，インプロセスHTTPサーバおよび簡易Webサーバで利用するIPアドレスを明示的に指定できます。これによって，複数の物理ネットワークインタフェースを持つホストまたは一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するよう設定できます。

静的コンテンツのキャッシュ
一度アクセスした静的コンテンツをメモリ上にキャッシュして，2回目以降のアクセスではキャッシュからブラウザにレスポンスを返すことで，静的コンテンツのレスポンスタイムを短縮できます。

簡易Webサーバ機能
Webコンテナを簡易Webサーバとして利用できます。スタブをダウンロードするためにこの機能を使用します。

セッションフェイルオーバ機能
J2EEサーバ上のHTTPセッションオブジェクトに登録されたオブジェクトを引き継ぐ機能です。この機能は，Webアプリケーションに組み込んで動作させるサーブレットフィルタとして提供されています。これを，セッションフェイルオーバ用フィルタといいます。
この機能を使用することによって，J2EEサーバに障害が発生して，リクエストがほかのJ2EEサーバに転送された場合でも，障害発生前の状態で業務を続行できます。

Webコンテナが提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-2　Webコンテナが提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

Webアプリケーションの実行
－
－
－
－
－
○
○
4.2

インプロセスHTTPサーバによるリクエストの受け付け
－
○
－
－
－
－
○
4.3

セッション管理
○
－
－
○
－
○
○
4.4

文字コード変換
－
－
－
－
○
○
－
4.5

デフォルトの文字エンコーディング設定
－
－
○
－
－
○
○
4.6

JSPの事前コンパイルとコンパイル結果の保持
－
○
－
－
－
－
○
4.7

アプリケーションのイベントリスナ
－
－
－
－
○
○
－
4.8

タグファイルの実行
－
－
－
－
－
○
－
4.9

JSP ELの実行
－
－
－
－
－
○
－
4.10

リクエストおよびレスポンスのフィルタリング
－
－
○
－
－
○
○
4.11

フィルタリングによるHTTPレスポンスの圧縮
－
○
－
－
－
－
○
4.12

Webコンテナのセキュリティ管理
○
－
－
－
－
○
○
4.13

EJBコンテナとの連携
－
－
－
－
－
○
○
4.14

データベースとの接続
－
－
－
○
－
○
○
4.15

Webコンテナによるスレッドの作成
－
○
－
－
－
－
○
4.16

同時実行スレッド数の制御
－
○
－
－
－
－
○
4.17，4.18，4.19，4.20

ユーザスレッドの使用
－
－
－
－
○
－
○
4.21

通信タイムアウトの設定
○
○
－
－
－
－
○
4.22

Webサーバ（リダイレクタ）によるリクエストの振り分け
○
○
－
○
－
－
○
4.23

エラーページのカスタマイズ
－
－
－
－
○
－
○
4.24

ドメイン名指定でのトップページの表示
－
－
－
－
○
○
－
4.25

Webコンテナへのゲートウェイ情報の通知
－
－
－
－
○
－
○
4.26

Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレスの指定
－
－
－
－
○
－
○
4.27

静的コンテンツのキャッシュ
－
○
－
－
－
－
○
4.28

簡易Webサーバ機能
－
－
－
－
○
－
○
4.29

セッションフェイルオーバ機能
○
－
○
－
－
－
○
4.11.1，12章

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.2　EJBコンテナが提供する機能の概要

EJBコンテナが提供する機能の概要について説明します。

機能の詳細については，「5.　EJBコンテナ」を参照してください。

Enterprise Beanの実行
EJBの仕様に準拠したEnterprise Beanを実行できます。

EJBコンテナのJNDI名前空間へのリファレンス登録
java:comp/envのJNDI名前空間を使用した間接的なルックアップができます。また，Application Serverの拡張機能によってEJBホームオブジェクトリファレンスに別名を付与することで，複数ホスト間でJNDI名前空間の情報を共有できます。

外部リソースとの接続
データベース，OpenTP1およびSMTPサーバとの接続ができます。

Enterprise Beanでのトランザクション設定
BMT（Bean-Managed Transaction）とCMT（Container-Managed Transaction）によるトランザクション管理ができます。

EJBコンテナの動作の最適化
Enterprise Beanのプーリング，キャッシング，タイムアウト，およびリモートインタフェースでのローカル呼び出し最適化などによって，性能向上が図れます。

Enterprise Beanへのアクセス制御
セキュリティアイデンティティ（J2EEサーバによるユーザ認証が成功した時にWebコンテナやEJBコンテナに伝達される認証情報）を使用したセキュリティ管理ができます。

Timer Serviceの機能
指定した時刻，経過時間，または間隔でEnterprise Beanを呼び出せます。時刻を指定した処理を容易に実行できます。

セキュリティ管理
セキュリティアイデンティティを利用したり，通信ポートとIPアドレスを固定したりして，セキュリティを確保できます。

EJBコンテナが提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-3　EJBコンテナが提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

Eneterprise Beanの実行
－
－
－
－
－
○
○
5.2

EJBコンテナのJNDI名前空間へのリファレンス登録※
－
－
－
○
－
○
○
5.3

外部リソースとの接続
－
－
－
○
－
○
－
5.4

Enterprise Beanでのトランザクション設定
－
－
－
－
－
○
－
5.5

EJBコンテナの動作の最適化
Entity Beanのキャッシュモデル（コミットオプション指定）
－
○
－
－
－
○
－
5.6

Stateless Session Bean，Entity Beanのプーリング
－
○
－
－
－
○
○
5.7

タイムアウト
－
○
－
－
－
○
○
5.9

EJBのリモートインタフェースの呼び出し
－
○
－
－
－
○
○
5.11

Enterprise Beanへのアクセス制御
○
－
－
－
－
○
－
5.8

Timer Serviceの機能
－
－
－
－
－
○
○
5.10

セキュリティ管理
○
－
－
－
－
－
○
5.12

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

注※

J2EEサービスのネーミング管理を利用して実現します。

2.2.3　EJBクライアントの実行機能の概要

EJBクライアントの実行機能の概要について説明します。

機能の詳細については，「6.　EJBクライアント」を参照してください。

Enterprise Beanの呼び出し
EJBクライアントアプリケーションからEnterprise Beanを呼び出せます。

JNDIによるEJBホームオブジェクト・ビジネスインタフェースのリファレンスのルックアップ
自動的にバインドされる名称またはユーザ指定名前空間を利用して，EJBホームオブジェクトおよびビジネスインタフェースのリファレンスをネーミングサービスからルックアップできます。

トランザクションの実装
EJBクライアントでトランザクションを使用できます。

セキュリティの実装
Cosminexusが提供するAPIを使用してEJBクライアントアプリケーションでのセキュリティを実装できます。

RMI-IIOP通信のタイムアウト
EJBクライアント－CORBAネーミングサービス間，EJBクライアント－Enterprise Bean間の通信に対して，タイムアウトを設定できます。

RMI-IIOPスタブ，インタフェースの取得
EJBクライアントアプリケーションから，Cosminexus TPBrokerのRMI-IIOPの機能を利用してアプリケーションを呼び出せます。

EJBクライアントの実行機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-4　EJBクライアントの実行機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

Enterprise Beanの呼び出し
－
－
－
○
－
○
○
6.2

JNDIによるEJBホームオブジェクト・ビジネスインタフェースのリファレンスのルックアップ
－
－
－
○
－
○
○
6.3

トランザクションの実装
－
－
－
○
－
○
○
6.4

セキュリティの実装
－
－
－
○
－
○
○
6.5

RMI-IIOP通信のタイムアウト
－
－
－
○
－
○
○
5.9.4

RMI-IIOPスタブ，インタフェースの取得
－
－
－
○
－
○
○
6.6

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.4　J2EEアプリケーションの実行機能の概要

J2EEアプリケーションの実行機能の概要について説明します。

機能の詳細については，「7.　J2EEアプリケーションの実行」を参照してください。

アーカイブ形式によるJ2EEアプリケーションのデプロイ
EJB-JAR，Webアプリケーションなどの構成要素をEARファイルにまとめて，J2EEアプリケーションをJ2EEサーバで実行できます。

展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ
EJB-JAR，Webアプリケーションなどの構成要素を任意のディレクトリに配備して，J2EEアプリケーションをJ2EEサーバで実行できます。

J2EEアプリケーションのリデプロイ
アーカイブ形式のJ2EEアプリケーションを入れ替えるときに，J2EEアプリケーションのすべての属性の情報を引き継ぐことができます。これによって，少ない手順でJ2EEアプリケーションを入れ替えられるようになります。この機能は，システムの運用時にJ2EEアプリケーションの入れ替えを支援する機能として利用します。

J2EEアプリケーションの更新検知とリロード
展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。これによって，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。この機能は，J2EEアプリケーション開発時のテストを支援する機能，またはシステムの運用時にJ2EEアプリケーションの入れ替えを支援する機能として利用します。

J2EEアプリケーションの実行機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-5　J2EEアプリケーションの実行機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

アーカイブ形式によるJ2EEアプリケーションのデプロイ
－
－
－
－
－
○
○
7.2

展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ
－
－
－
－
－
－
○
7.3

J2EEアプリケーションのリデプロイ
－
－
○
－
－
－
○
7.4

J2EEアプリケーションの更新検知とリロード
－
－
○
－
－
－
○
7.5

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.5　ネーミング管理が提供する機能の概要

J2EEサービスのうち，ネーミング管理が提供する機能の概要について説明します。

なお，機能の詳細については，「8.　ネーミング管理」を参照してください。

JNDI名前空間へのオブジェクトのバインドとルックアップ
オブジェクトをJDNI名前空間の名前とバインドして管理します。クライアントからは，バインドされた名前を使用して検索（ルックアップ）できます。

Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）
Enterprise BeanまたはJ2EEリソースに別名を付与できます。クライアントからは，別名として設定した任意の名称でルックアップできます。

ラウンドロビンポリシーによるCORBAネーミングサービスの検索
複数のCORBAネーミングサービスに登録されている同一名称（別名）のEJBホームオブジェクトリファレンスを，ラウンドロビンポリシーに従ってルックアップできます。

ネーミング管理機能でのキャッシング
ルックアップしたEJBホームオブジェクトリファレンスをキャッシングしておき，2回目以降に同じオブジェクトをルックアップする場合の処理を短くできます。

CORBAネーミングサービスの切り替え
ルックアップの対象にするJNDI名前空間を，InitialContextクラスのインスタンスのプリフィックス判定によって切り替えられます。

J2EEサービスのうち，ネーミング管理が提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-6　J2EEサービス（ネーミング管理）が提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

JNDI名前空間へのオブジェクトのバインドとルックアップ
－
－
－
○
－
○
○
8.2

Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）
－
－
－
○
－
－
○
8.3

ラウンドロビンポリシーによるCORBAネーミングサービスの検索
－
－
－
○
－
－
○
8.4

ネーミング管理機能でのキャッシング
－
○
－
－
－
－
○
8.5

CORBAネーミングサービスの切り替え
－
－
－
○
－
－
○
8.6

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.6　リソース接続とトランザクション管理が提供する機能の概要

J2EEサービスのうち，リソース接続とトランザクション管理が提供する機能の概要について説明します。なお，機能の詳細については，「9.　リソース接続とトランザクション管理」を参照してください。

コネクションプーリング
コネクションをメモリ上にプールしておくことで，アプリケーションからの接続要求に対して高速に処理できます。また，次のような機能も使用できます。

例外発生時に該当コネクションをコネクションプールから破棄する機能

サーバ起動時またはリソースアダプタ起動時に，指定した数のコネクションを作成して，それをプールしておくことで，コネクションプール開始直後の接続要求を高速に処理する機能（コネクションプールのウォーミングアップ）

一定間隔で，プール内の不要なコネクションを段階的に減少させる機能（コネクション数調節）

コネクションシェアリング・アソシエーション
コネクションを共有することで，コネクション取得処理に掛かる処理時間を短縮できます。
コネクションシェアリングでは，接続元のサーブレットやEnterprise Beanなどのコネクションである論理コネクションと接続先リソースのコネクションである物理コネクションを多対1で接続します。
コネクションアソシエーションは，コネクションシェアリングができない場合に使用します。接続元のサーブレットやEnterprise Beanなどのコネクションである論理コネクションと接続先リソースのコネクションである物理コネクションを多対1で接続しますが，使用しない物理コネクションを作成する必要があります。

ステートメントプーリング
PreparedStatementおよびCallableStatementを使用する処理の場合に，これらのステートメントをプーリングしておくことで，同じステートメント作成に掛かる処理時間を短縮できます。

ライトトランザクション
ローカルトランザクションを使用するための環境を最適化できます。

インプロセストランザクションサービス
トランザクションサービスを，J2EEサーバのプロセス内で動作させることができます。インプロセスで動作させると，OTSは自動で起動されます。

DataSourceオブジェクトのキャッシング
JNDIインタフェースを使用して，DataSource型のオブジェクトの検索要求をする場合，DataSourceオブジェクトをキャッシングできます。

DB Connectorのコンテナ管理でのサインオンの最適化
コンテナ管理でサインオンをする場合，サインオンの動作を最適化できます。

受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）
実行したSQLに対して返却される実行結果を格納する領域（受信バッファ）をプールリングしておくことで，SQL実行時のオーバーヘッドを削減できます。

コネクションの障害検知
プーリングされているコネクションにトラブルが発生していないかを検知できます。これによって，ユーザプログラムからのコネクション要求に対して，有効なコネクションだけを返却できます。

コネクション枯渇時のコネクション取得待ち
コネクションプールに指定した最大数までコネクションがプールされていて，利用できるコネクションがない場合は，コネクション取得要求を待ち状態にできます。

コネクションの取得リトライ
使用できるコネクションがコネクションプールにない場合や接続先リソースの物理コネクションの確立に失敗した場合に，自動的にコネクションの取得処理を再実行できます。

コネクションプールの情報表示
コマンドを使用して，コネクションプール内のコネクションの情報を表示できます。

コネクションプールのクリア
データベースサーバにトラブルが発生してコネクションが切断された場合などに，不要なコネクションプールをコマンドで削除できます。

コネクションの自動クローズ
コマンドを使用して，コネクションを自動的にクローズできます。

コネクションスイーパ
一定間隔でコネクションプール内の未使用のコネクションを解放できます。

トランザクションタイムアウトとステートメントキャンセル
トランザクション開始時間から一定時間経過した時点でトランザクションをロールバックできます。また，実行中のSQL処理が返ってこない状態でトランザクションタイムアウトが発生した場合は，ステートメントをキャンセルできます。

トランザクションリカバリ
J2EEサーバまたはリソースマネジャにトラブルが発生した場合に，プリペア状態またはヒューリスティック状態になった2フェーズトランザクションを決着できます。

障害調査用SQLの出力
デッドロックやスローダウンなどの障害が発生した時に，発行したSQLをログに出力でき，障害要因の解析に利用できます。

オブジェクトの自動クローズ
ユーザプログラムでオープンしたStatementオブジェクトなどをクローズできなかった場合，DB Connectorによってオブジェクトを自動的にクローズできます。

コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示）
データベースをクラスタ構成にしている場合，障害発生時やメンテナンス時に，コネクションプールを停止したり，再開したりできます。また，それぞれのコネクションプールの状態を表示できます。

リソースアダプタのライフサイクル管理
Connector 1.5仕様に準拠したリソースアダプタを利用する場合に使用できる機能です。J2EEサーバによってリソースアダプタのライフサイクルを管理できます。

リソースアダプタのワーク管理
Connector 1.5仕様に準拠したリソースアダプタを利用する場合に使用できる機能です。リソースアダプタが使用するスレッドをJ2EEサーバによって管理できます。

メッセージインフロー
Connector 1.5仕様に準拠したリソースアダプタを利用する場合に使用できる機能です。メッセージプロバイダからのメッセージを受け付けて，アプリケーションサーバ上のメッセージエンドポイント（Message-driven Bean）を動作させることができます。

管理対象オブジェクトのルックアップ
Connector 1.5仕様に準拠したリソースアダプタで使用できる機能です。メッセージ送信先の情報を管理している管理対象オブジェクトを，ルックアップによって取得できます。

コネクション定義の複数指定
Connector 1.5仕様に準拠したリソースアダプタを利用する場合に，一つのリソースアダプタに対して複数のコネクション定義を指定できます。

リソースへの接続テスト
環境構築時に，リソースアダプタが正しく設定できているかどうかを確認できます。

J2EEサービスのうち，リソース接続とトランザクション管理が提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-7　J2EEサービス（リソース接続とトランザクション管理）が提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

コネクションプーリング
－
○
－
－
－
○
○
9.10.1

コネクションプールのウォーミングアップ
－
○
－
－
－
－
○

コネクションプール数調節機能
－
○
－
－
－
－
○

コネクションシェアリング・アソシエーション
－
○
－
－
－
○
－
9.10.2

ステートメントプーリング
－
○
－
－
－
－
○
9.10.3

ライトトランザクション
－
○
－
－
－
－
○
9.10.4

インプロセストランザクションサービス
－
○
－
－
－
○
－
9.10.5

DataSourceオブジェクトのキャッシング
－
○
－
－
－
－
○
9.10.6

DB Connectorのコンテナ管理でのサインオンの最適化
－
○
－
－
－
－
○
9.10.7

受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）
－
○
－
－
－
－
○
9.10.8

コネクションの障害検知
○
－
－
－
－
○※1
○※1
9.11.1

コネクション枯渇時のコネクション取得待ち
○
－
－
－
－
－
○
9.11.2

コネクションの取得リトライ
○
－
－
－
－
－
○
9.11.3

コネクションプールの情報表示
○
－
－
－
－
－
○
9.11.4

コネクションプールのクリア
○
－
－
－
－
－
○
9.11.5

コネクションの自動クローズ
○
－
－
－
－
○
－
9.11.6

コネクションスイーパ
○
－
－
－
－
－
○
9.11.7

トランザクションタイムアウトとステートメントキャンセル
○
－
－
－
－
○
－
9.11.8

トランザクションリカバリ
○
－
－
－
－
○
－
9.11.9

障害調査用SQLの出力
－
－
○
－
－
－
○
9.11.10

オブジェクトの自動クローズ
○
－
－
－
－
○
－
9.11.11

コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示）
○
－
－
－
－
－
○
9.12

リソースアダプタのライフサイクル管理※2
－
－
－
－
－
○
－
9.13.1

リソースアダプタのワーク管理※2
－
－
－
－
－
○
－
9.13.2

メッセージインフロー※2
－
－
－
－
－
○
－
9.13.3

管理対象オブジェクトのルックアップ※2
－
－
－
－
－
○
－
9.13.4

コネクション定義の複数指定※2
－
－
－
－
－
○
－
9.13.5

リソースへの接続テスト
－
－
○
－
－
－
○
9.14

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

注※1

Connector 1.0の場合は「拡張」です。Connector 1.5の場合は「J2EE標準」です。

注※2

Connector 1.5仕様に準拠したリソースアダプタを使用する場合だけ使用できる機能です。

2.2.7　コンテナ拡張ライブラリが提供する機能の概要

コンテナ拡張ライブラリの概要について説明します。なお，機能の詳細については，「10.　コンテナ拡張ライブラリ」を参照してください。

コンテナ拡張ライブラリの利用
コンテナ拡張ライブラリとは，Enterprise Bean，サーブレット，JSPが利用する共通のライブラリです。このライブラリを利用することによって，Enterprise Bean，サーブレット，JSPからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリの機能の目的，およびJ2EE標準との対応について，次の表に示します。コンテナ拡張ライブラリの機能はApplication Server独自の機能です。

表2-8　コンテナ拡張ライブラリの機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

コンテナ拡張ライブラリの利用
－
－
－
○
－
－
○
10.1

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.8　CTMが提供する機能の概要

CTMが提供する機能の概要について説明します。機能の詳細については，「11.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

CTMによるリクエストの流量制御と優先制御
J2EEサーバで一度に実行される処理数の最大値を設定してリクエストの同時実行数を制限することで，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現できます。
また，リクエストに優先順位を付けることで，優先順位の高いリクエストから順にキューから取り出して処理できます。

CTMによるリクエストの閉塞制御
特定のJ2EEアプリケーションに対するリクエストの受け付けを停止したり，リクエストを滞留したりすることで，システム全体を停止させない状態でのJ2EEアプリケーションの入れ替えや再起動ができます。

CTMによるリクエストの負荷分散
クライアントからのcreateおよびビジネスメソッドの呼び出しを，サーバ間，プロセス間およびスレッド間で負荷分散できます。

CTMによるリクエストのキューの滞留監視
CTMがそれぞれのリクエストを制御するためのキューを，スケジュールキューといいます。キューの滞留監視機能では，スケジュールキューに滞留するリクエストを，一定間隔で監視できます。

CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続
CTMのゲートウェイ機能を利用して，TPBrokerクライアントおよびTPBroker OTMクライアントからアプリケーションサーバ上で動作するJ2EEアプリケーションを呼び出せます。

CTMの稼働統計情報の収集
CTMを使用する場合に，CTMから出力された稼働統計情報を収集できます。この情報を基に，CTMの処理性能を分析できます。

CTMが提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-9　CTMが提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

CTMによるリクエストの流量制御と優先制御
○
○
－
－
－
－
○
11.4

CTMによるリクエストの閉塞制御
○
－
○
－
－
－
○
11.5

CTMによるリクエストの負荷分散
○
○
－
○
－
－
○
11.6

CTMによるリクエストのキューの滞留監視
○
－
○
－
－
－
○
11.7

CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続
－
－
－
○
－
－
○
11.8

CTMの稼働統計情報の収集
－
－
○
－
－
－
○
17.9

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.2.9　Cosminexusシステムのユーザを統合管理する機能の概要

統合ユーザ管理機能の概要について説明します。なお，機能の詳細については，「13.　統合ユーザ管理」を参照してください。

統合ユーザ管理フレームワーク
Java標準仕様（JAAS）に従ったユーザ認証処理を実現するための，次のような機能が使用できます。また，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継ぐことができます。

Cosminexus標準ログインモジュールを使用して，パスワード，クライアント証明書，LDAPディレクトリサーバの認証機能を使用したユーザ認証ができます。

ユーザ情報リポジトリからユーザ情報を検索したり，ユーザ情報リポジトリのパスワード認証を拡張したり，ログインモジュールのカスタマイズをしたりできます。

セッションを管理して，ログインしたユーザIDをセッションに登録，削除できます。

シングルサインオンによって，複数の異なるユーザIDを持つシステム間でログインし直すことなく操作できるようになります。

カスタムログインモジュールを使用して，独自の認証処理とCosminexus標準ログインモジュールの認証処理を組み合わせて使用できます。

クライアントからの認証処理呼び出しに，JSPタグライブラリ，ユーザ認証ライブラリおよびシングルサインオンライブラリを使用できます。

リポジトリ管理
Webブラウザに表示した運用管理ポータル画面から，ユーザ情報を格納したリポジトリ（LDAPディレクトリサーバ）を管理できます。

リポジトリの接続フェイルオーバ
リポジトリ（LDAPディレクトリサーバ）を多重化して，ユーザ情報リポジトリおよびシングルサインオン情報リポジトリの可用性を向上できます。

Cosminexusシステムのユーザを統合管理する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-10　Cosminexusシステムのユーザを統合管理する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

統合ユーザ管理フレームワーク
○
－
○
－
－
○
○
13.2
13.3
13.4
13.5
13.6

リポジトリ管理
－
－
○
－
－
－
○
13.12.1

リポジトリの接続フェイルオーバ
○
－
－
－
－
－
○
13.12.2

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.3　システム構築時に使用する機能の概要

ここでは，アプリケーションサーバの構築を支援する機能について説明します。

システムの構築支援機能
Cosminexusでは，システムの構築支援機能として，Smart Composer機能およびセットアップウィザードを提供しています。
Smart Composer機能を使用して構築したシステムでは，アプリケーションサーバを構成するプロセスである，Management Serverを使用するため，システムの一括構築，および一括運用ができます。また，セットアップウィザードを使用すると，対話形式のウィザードプログラムを使用したシステム構築ができます。ただし，セットアップウィザードで構築できるシステムの構成には制限があります。

リソースアダプタやJ2EEアプリケーションの設定機能
リソースアダプタやJ2EEアプリケーションの設定機能には，次の2種類があります。

サーバ管理コマンド

Server Plug-in

サーバ管理コマンドを使用する場合はCUIでの操作，Server Plug-inを使用する場合はGUIでの操作となります。
なお，Server Plug-inは，UNIX環境では使用できません。Server Plug-inを使用してUNIXの実行環境に対して操作したい場合は，別途，uCosminexus Operatorをインストールしたマシンを用意してください。uCosminexus OperatorのServer Plug-inを使用して運用管理操作を実施します。uCosminexus Operatorについては，「2.6.3　uCosminexus Operatorの機能概要」を参照してください。

複数の構築済み実行環境の切り替え
1台のマシンに，複数の構築済み実行環境を共存させて切り替えられます。これによって，同じ製品のバージョン違いや，パッチ適用の有無などによる動作確認を1台のマシンで検証できます。なお，この機能はWindows環境では使用できません。

Cosminexusシステムの構築時に使用する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-11　システム構築時に使用する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

システムの構築支援機能
－
－
－
－
○
－
○
16章

リソースアダプタやJ2EEアプリケーションの設定機能
－
－
－
－
○
－
○
16.7

複数の構築済み実行環境の切り替え
－
－
－
－
○
－
○
16.8

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.4　システム運用時に使用する機能の概要

ここでは，アプリケーションサーバの運用を支援する機能の概要と特性について説明します。運用を支援する機能を次のように分類して説明します。

Management Serverによる運用管理機能

システムの日常運用を支援する機能

システムの保守を支援する機能

J2EEアプリケーションの運用機能

システムの監査を支援する機能

＜この節の構成＞

2.4.1　Management Serverによる運用管理機能の概要

2.4.2　システムの日常運用を支援する機能の概要

2.4.3　システムの保守を支援する機能の概要

2.4.4　J2EEアプリケーションの運用機能の概要

2.4.5　システムの監査を支援する機能の概要

2.4.1　Management Serverによる運用管理機能の概要

Management Serverによる運用管理機能の概要について説明します。Management Serverは，Smart Composer機能でシステムを構築した場合に利用できます。

運用管理ドメイン内の論理サーバを一括運用管理するために，次の機能が使用できます。

論理サーバの起動と停止が一括実行できます。

論理サーバのアプリケーション管理が一括実行できます。

運用管理ドメイン内の論理サーバの運用監視ができます。

運用管理ドメイン内の性能解析トレースファイルを収集できます。

稼働情報をCSV形式またはSNMP連携形式のファイルとして出力できます。

それぞれの機能の詳細については，「17.1.1　J2EEアプリケーションの実行環境の日常運用」，および「18.1　システムの保守の概要」を参照してください。

2.4.2　システムの日常運用を支援する機能の概要

システムの日常運用を支援する機能の概要について説明します。

稼働情報の監視（稼働情報収集機能）
J2EEサーバの稼働状態を定期的に監視し，サーバ性能やリソースの情報などの稼働情報を取得します。

稼働情報の監視（運用管理コマンド）
運用管理コマンドを使用して，運用管理ドメイン内の論理サーバを監視し，稼働情報を取得します。

リソースの枯渇監視
J2EEサーバおよびSFOサーバを対象に，メモリやスレッドなどのリソースを監視します。監視対象のリソースについての情報は，一定間隔でファイルに出力されます。また，監視対象のリソースの状態が設定したしきい値を超えた場合には，アラートが発生します。アラートが発生すると，メッセージを出力し，Management Serverに対してイベントを通知します。

Managementイベントによる処理の自動実行
J2EEサーバとSFOサーバが稼働中に出力するすべてのメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。

CTMの稼働統計情報の収集
CTMを使用する場合に，CTMから出力された稼働統計情報を収集できます。この情報を基に，CTMの処理性能を分析できます。

システムの処理性能の解析
クライアントからのリクエストを処理するときに，Cosminexusシステムの各機能が出力する性能解析情報を収集する機能です。この情報を基に，システム性能およびボトルネックを分析できます。

システムの日常運用を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-12　システムの日常運用を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

稼働情報の監視（稼働情報の収集機能）
－
－
○
－
－
－
○
17.5

稼働情報の監視（運用管理コマンド）
－
－
○
－
－
－
○
17.6

リソースの枯渇監視
－
－
○
－
－
－
○
17.7

Managementイベントによる処理の自動実行
－
－
○
－
－
－
○
17.8

CTMの稼働統計情報の収集
－
－
○
－
－
－
○
17.9

システムの処理性能の解析
－
－
○
－
－
－
○
17.10

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.4.3　システムの保守を支援する機能の概要

システムの保守を支援する機能の概要について説明します。

ユーザログ出力
J2EEアプリケーションで例外が発生した場合に，メッセージおよびログを日立トレース共通ライブラリ形式で出力できます。

コンソールログ出力
運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などのコンソール出力情報をコンソールログに出力できます。

障害検知時コマンド
Management Serverが論理サーバの障害を検知したときに，トラブルシューティングの資料を取得できます。

snapshotログ収集
Cosminexusの構成ソフトウェアのsnapshotログを出力，収集できます。
例えば，システムにトラブルが発生した場合には，トラブルシューティング情報としてsnapshotログを自動的に収集できます。

システムの保守を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-13　システムの保守を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

ユーザログ出力
－
－
○
－
－
－
○
18.3

コンソールログ出力
－
－
○
－
－
－
○
18.4

障害検知時コマンド
－
－
○
－
－
－
○
18.2.3

snapshotログ収集
－
－
○
－
－
－
○
18.2.4

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.4.4　J2EEアプリケーションの運用機能の概要

J2EEアプリケーションの運用機能の概要について説明します。

J2EEアプリケーションのリクエストの同時実行数の動的変更
Webアプリケーション単位の同時実行数とCTMの同時実行数を，J2EEサーバ起動後，J2EEアプリケーションの運用中に動的に変更できます。

J2EEアプリケーション実行時間の監視とキャンセル
J2EEアプリケーションの実行時間の監視では，EJBおよびWebアプリケーションのリクエスト実行時間を監視します。この機能によって，J2EEアプリケーションで障害を検知すると，一定時間内に終了しなかったメソッド処理をタイムアウトしたり，メソッド処理をキャンセルしたりできます。

J2EEアプリケーションのサービスの閉塞
J2EEアプリケーションのサービスを閉塞することで，業務時間外やシステムのメンテナンス時にサービスを停止できます。

J2EEアプリケーションの停止
J2EEアプリケーションの停止には，通常停止と強制停止があります。処理中のリクエストが終了しないなどの原因で通常停止ができない場合，強制停止を実行すると処理中のリクエストが終了するので，通常停止ができるようになります。

J2EEアプリケーションの入れ替え
J2EEアプリケーションを入れ替えるには，Webアプリケーションのサービスを部分的に閉塞して入れ替える方法と，リデプロイ機能を使用して入れ替える方法，リロード機能を使用して入れ替える方法があります。これらの方法を利用することで，サービスを停止することなく，またはサービスの停止期間を最小限に抑えて，J2EEアプリケーションを入れ替えることができます。

J2EEアプリケーションのテスト機能
テストモードとは，J2EEアプリケーション実行の動作モードの一つです。テストモードでJ2EEアプリケーションを実行すると，稼働中のJ2EEサーバ上でテスト用としてJ2EEアプリケーションを動作させることができるので，本番環境と同じ環境でテストを実施できます。また，テスト後は容易に本番環境に移行できます。

J2EEアプリケーションの運用機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-14　J2EEアプリケーションの運用機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

J2EEアプリケーションのリクエストの同時実行数の動的変更
－
○
－
－
－
－
○
19.2

J2EEアプリケーション実行時間の監視とキャンセル
－
－
○
－
－
－
○
19.3

J2EEアプリケーションのサービスの閉塞
－
－
○
－
－
－
○
19.4

J2EEアプリケーションの停止
－
－
○
－
－
○
○
19.5

J2EEアプリケーションの入れ替え
－
－
○
－
－
○
○
19.6

J2EEアプリケーションのテスト機能
－
－
○
－
－
－
○
19.7

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.4.5　システムの監査を支援する機能の概要

システムの監査を支援する機能の概要について説明します。

監査ログの出力
監査ログに，システムの構築者や運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴を出力することで，システムの監査に利用できます。

データベース監査証跡機能との連携
データベースが提供するデータベース監査証跡機能と連携することで，J2EEアプリケーションがデータベースにアクセスした際に使用したアカウントを記録できます。

システムの監査を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表2-15　システムの監査を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

監査ログの出力
○
－
○
－
－
－
○
20.2

データベース監査証跡機能との連携
○
－
○
－
－
－
○
20.3

（凡例）　○：対応する　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

2.5　ほかのプログラムと連携する機能の概要

ここでは，Application Serverとほかのプログラムを連携させることで実現できる機能の概要と特性について説明します。次に示すプログラムとの連携を説明します。

JP1との連携で実現する機能

クラスタソフトウェアとの連携で実現する機能

参考

この節で説明する機能はすべて，J2EE標準とは関係のない機能です。このため，J2EE標準との対応については説明しません。

＜この節の構成＞

2.5.1　JP1連携による運用管理機能の概要

2.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

2.5.1　JP1連携による運用管理機能の概要

JP1連携による運用管理機能の概要について説明します。

システムの集中監視（JP1/IMとの連携）
業務システム全体のリソースの状態を集中監視することで，稼働性能を把握，調査したり，トラブルの発生を検知して，原因を究明して対策したりできます。この機能はJP1/IMと連携して実現できます。

システムの構成定義および管理（JP1/IM - CMとの連携）
システム構築時にシステム構成を定義したり，定義したシステムについて，リソースやシステム構成に関する情報を集約して管理したりできます。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。この機能はJP1/IM - CMと連携して実現できます。なお，JP1/IM - CMと連携できるのは，Cosminexusで提供するSmart Composer機能を使用してシステムを構築する場合だけです。

ジョブによるシステムの自動運転（JP1/AJS2との連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義して自動化することで，効率的なリソースの配分や業務の効率化，省力化を図れます。JP1/AJS2と連携することで，カスタムジョブによるシステムの自動運転が実現できます。

シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図れます。JP1/AJS2 - SOと連携することで，シナリオによるシステムの自動運転が実現できます。なお，シナリオによるシステムの自動運転をする場合は，Smart Composer機能を使用して構築したシステムが前提となります。

監査ログの一括収集／管理（JP1/NETM/Auditとの連携）
システムの監査で使用する監査ログを，自動で収集して，一括管理できます。この機能はJP1/NETM/Auditと連携して実現できます。

JP1連携による運用管理機能の目的について，次の表に示します。

表2-16　JP1連携による運用管理機能の目的

機能名
目的
参照先

信頼性
性能
運用・
保守
拡張性
そのほか

システムの集中監視（JP1/IMとの連携）
－
－
○
－
－
21.2

システムの構成定義および管理（JP1/IM - CMとの連携）
－
－
○
－
－
21.3

ジョブによるシステムの自動運転（JP1/AJS2との連携）
－
－
○
－
－
21.4

シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
－
－
○
－
－
21.5

監査ログの収集・一元管理（JP1/NETM/Auditとの連携）
－
－
○
－
－
21.6

（凡例）　○：対応する　　－：対応しない

2.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

クラスタソフトウェアとの連携による系切り替え機能の概要について説明します。Cosminexusと連携できるクラスタソフトウェアは，Microsoft Cluster Service（Windowsの場合※），およびHAモニタ（AIX・HP-UX・Linuxの場合）です。なお，Solarisの場合，クラスタソフトウェアと連携したシステム運用はできません。

注※

ただし，使用できるOSは，Windows Server 2003 Enterprise Edition，Windows Server 2003 R2 Enterprise Edition，Windows Server 2003 Enterprise x64 Edition，およびWindows Server 2003 R2 Enterprise x64 Editionとなります。

1:1系切り替えシステム
実行系と待機系が1対1になるシステム構成です。Cosminexusでは，アプリケーションサーバの1:1系切り替えシステムでの運用と，運用管理サーバの1:1系切り替えシステムでの運用をサポートしています。実行系サーバでの障害発生時またはシステムの保守時に，あらかじめ待機させておいたサーバに自動的に切り替えて，業務処理を続行するための機能です。これによって，システムの不稼働時間を短縮し，クライアントの業務処理への影響を減らせます。

相互系切り替えシステム
1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。Cosminexusでは，アプリケーションサーバの相互系切り替えシステムでの運用をサポートしています。

N:1リカバリシステム
複数台の実行系と1台の待機系から成るシステム構成です。実行系では，J2EEアプリケーションを実行します。待機系では，障害が発生した実行系のトランザクションの解決およびリソース解放だけを実施します。これによって，実行系での障害発生時の，システムの運用・保守性が向上します。

クラスタソフトウェアとの連携による系切り替え機能の目的について，次の表に示します。

表2-17　クラスタソフトウェアとの連携による系切り替え機能の目的

機能名
目的
参照先

信頼性
性能
運用・
保守
拡張性
そのほか

1:1系切り替えシステム
○
－
○
－
－
22.3

相互系切り替えシステム
○
－
○
－
－
22.4

N:1リカバリシステム
○
－
○
－
－
22.5

（凡例）　○：対応する　　－：対応しない

2.6　オプション製品の機能

Cosminexusでは，実行環境で使用する製品として，Application Server以外に次の製品を提供しています。

ここでは，実行環境で使用する次のオプション製品の機能について説明します。

uCosminexus Client

Web Redirector

uCosminexus Operator

これらの製品では，Application Serverの機能の一部が使用できます。

＜この節の構成＞

2.6.1　uCosminexus Clientの機能概要

2.6.2　Web Redirectorの機能概要

2.6.3　uCosminexus Operatorの機能概要

2.6.1　uCosminexus Clientの機能概要

uCosminexus Clientは，クライアントのホストでEJBクライアントアプリケーションを実行する場合に利用できます。uCosminexus Clientは，Application Serverで提供されている機能のうち，EJBクライアント環境の構築に必要な機能だけで構成されています。多数のPCなどでEJBクライアントとなるJavaアプリケーションを動作させる場合に，各PCにuCosminexus Clientを導入します。

なお，uCosminexus Clientの対象OSはWindowsだけです。

uCosminexus Clientには，次の機能があります。

EJBクライアントアプリケーションの実行
Session BeanなどをRMI-IIOP通信で呼び出すJavaアプリケーションである，EJBクライアントアプリケーションを実行できます。また，Javaアプリケーションを開始できます。EJBクライアントアプリケーションの実行については，マニュアル「Cosminexus　システム構築ガイド」のEJBアプリケーションの設定と実行に関する説明を参照してください。

性能解析トレース出力
EJBクライアントアプリケーションからリクエストを送信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。性能解析トレース出力については，「17.10　システムの処理性能の解析」を参照してください。

2.6.2　Web Redirectorの機能概要

Web Redirectorは，Webクライアント構成の場合に，Webサーバを配置するホストをアプリケーションサーバとは別に構築したいときに利用できます。Web Redirectorは，Application Serverで提供されている機能のうち，Webリダイレクタ環境の構築に必要な機能だけで構成されています。したがって，それぞれのホストにApplication Serverを導入する場合に比べて，むだのない環境構築ができます。

Web Redirectorには，次の機能があります。

Webサーバの構築
Hitachi Web ServerまたはMicrosoft IISを使用してWebサーバを構築できます。Hitachi Web Serverについては，マニュアル「Hitachi Web Server」を参照してください。

WebコンテナおよびWebサーバの通信タイムアウト
クライアント－Webサーバ間，Webサーバ－Webコンテナ間で，リクエスト受信時およびレスポンス送信時の通信タイムアウトを設定しておき，トラブル発生時の応答待ちなどの場合に通信タイムアウトを検知できます。通信タイムアウトについては，「4.22　通信タイムアウトの設定」を参照してください。

リダイレクタによるリクエスト振り分けの実行
Webサーバに登録したリダイレクタによってWebコンテナへのリクエスト振り分けができます。リクエスト振り分けについては，「4.23　Webサーバ（リダイレクタ）によるリクエストの振り分け」を参照してください。

エラーページのカスタマイズ
クライアントから存在しないリソースに対してアクセスした場合などに，クライアントからのリクエストに対してユーザがカスタマイズしたエラーページを表示できます。エラーページの表示は，リダイレクタが実行します。エラーページのカスタマイズについては，「4.24　エラーページのカスタマイズ」を参照してください。

Webコンテナへのゲートウェイ情報の通知
クライアントとWebサーバとの間にSSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知して，welcomeファイルやFORM認証画面に自動的に正しくリダイレクトできます。Webコンテナへのゲートウェイ情報の通知については，「4.26　Webコンテナへのゲートウェイ情報の通知」を参照してください。

性能解析トレース出力
Webサーバに登録したリダイレクタからリクエストを送信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。
性能解析トレース出力については，「17.10　システムの処理性能の解析」を参照してください。

2.6.3　uCosminexus Operatorの機能概要

uCosminexus Operatorは，Application Serverをインストールした別のマシンに対して運用管理操作をするための製品です。uCosminexus Operatorでは，運用管理操作をするための機能としてServer Plug-inを提供しています。Server Plug-inは，Eclipseのプラグインで，リソースアダプタやJ2EEアプリケーションの設定，論理サーバの起動・停止などの操作ができます。

Application Serverをインストールした実行環境がUNIXの場合，Server Plug-inは使用できません。このような場合に，uCosminexus Operatorをインストールしたマシンを実行環境のマシンとは別に用意すると，uCosminexus OperatorをインストールしたマシンのServer Plug-inから，UNIXの実行環境に対して運用管理操作ができます。なお，uCosminexus OperatorはWindows環境のマシンにだけインストールできます。

Server Plug-inの機能の詳細については，「16.　システムの構築」を参照してください。

参考

uCosminexus Operatorをインストールすると，Server Plug-inのほかに，HCSC-Managerもインストールされます。HCSC-Managerについては，マニュアル「Cosminexus　サービスプラットフォーム　システム構築・運用ガイド」を参照してください。

2.7　旧バージョンとの互換用の機能

Application Serverでは，旧バージョンとの互換用の機能として，次の機能を提供しています。

ベーシックモードでの運用

サーブレットエンジンモードでの運用

どちらも，旧バージョンとの互換用の，サーバの動作モードとなります。ベーシックモードおよびサーブレットエンジンモードについては，「付録A　旧バージョンとの互換用機能」を参照してください。

3.　アプリケーションサーバの機能（バッチアプリケーションを実行する場合）

この章では，バッチアプリケーションを実行するアプリケーションサーバの機能について説明します。

＜この章の構成＞

3.1　Application Serverで提供する機能の目的

3.2　バッチアプリケーション実行基盤の機能の概要

3.3　システム構築時に使用する機能の概要

3.4　システム運用時に使用する機能の概要

3.5　ほかのプログラムと連携する機能の概要

3.1　Application Serverで提供する機能の目的

バッチアプリケーションを実行するアプリケーションサーバの場合，Application Serverで提供する次の四つの機能を使用できます。

バッチアプリケーションの実行基盤としての機能

アプリケーションサーバを中心としたシステムの構築を支援する機能

アプリケーションサーバを中心としたシステムの運用を支援する機能

ほかのプログラムと連携する機能

これらの機能は，システムで求められる次のような目的に対応しています。

アベイラビリティとフォールトトレランスの向上

システム性能の向上

効率的で確実な運用・保守の実現

システム規模の変更への柔軟な対応

なお，これらの目的に直接対応しない機能もあります。例えば，システムの構築支援機能が該当します。

システムの目的と，対応するアプリケーションサーバの機能の概要について，次の表に示します。

表3-1　システムの目的と対応するアプリケーションサーバの機能の概要

システムの目的※ | 対応するアプリケーションサーバの機能の概要
アベイラビリティとフォールトトレランスの向上［信頼性］ | システムとしての信頼性を高めるための機能を提供しています。アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が含まれます。
システム性能の向上［性能］ | システムの性能を向上させるための機能を提供しています。この機能によって，システムのパフォーマンス・チューニングができます。
効率的で確実な運用・保守の実現［運用・保守］ | システムを効率良く確実に運用・保守する機能を提供しています。
システム規模の変更への柔軟な対応［拡張性］ | システム規模の拡大・縮小および構成の変更に柔軟に対応するための機能を提供しています。
そのほかの目的［そのほか］ | システムの構築を支援する機能など，そのほかの目的で使用される機能を提供しています。

注※　［　］内は，以降の節の表に示す「目的」列の表記と対応しています。

また，バッチアプリケーション実行基盤では，J2EE標準に準拠した機能と，Application Server独自の機能を使用できます。Application Server独自の機能とは，J2EEの機能に加えてApplication Serverが拡張している機能や，J2EE機能と直接は関係ないApplication Server独自で提供する機能のことです。

以降の節では，Application Serverの機能を分類して，それぞれがどの特性に対応するかを示します。また，それぞれの機能の概要についても説明します。

ポイント

3.2以降で記載している表は，次の形式で記載しています。

「機能名」は，機能の名称を示します。

「目的」列は，表3-1で記載したシステムの目的に対応しています。

「J2EE標準への準拠」列は，その機能がJ2EEで規定された機能であるかどうかを示します。

「参照先」は，その機能について詳細に説明している個所を示します。

3.2　バッチアプリケーション実行基盤の機能の概要

ここでは，Application Serverが提供する機能のうち，バッチアプリケーション実行基盤としての機能の特性について説明します。バッチアプリケーション実行基盤の機能として，次に示す機能があります。

バッチアプリケーション実行機能

EJBアクセス機能

ネーミング管理が提供する機能

リソース接続とトランザクション管理が提供する機能

ガーベージコレクション制御機能

コンテナ拡張ライブラリの機能

これらの機能はバッチサービスとして提供されています。

＜この節の構成＞

3.2.1　バッチアプリケーション実行機能の概要

3.2.2　EJBアクセス機能の概要

3.2.3　ネーミング管理が提供する機能の概要

3.2.4　リソース接続とトランザクション管理が提供する機能の概要

3.2.5　ガーベージコレクション制御機能の概要

3.2.6　コンテナ拡張ライブラリが提供する機能の概要

3.2.1　バッチアプリケーション実行機能の概要

バッチアプリケーション実行機能の概要について説明します。

なお，機能の詳細については，「14.2　バッチアプリケーション実行機能」を参照してください。

バッチアプリケーションの実行
バッチサーバ上でバッチアプリケーションを実行します。

バッチアプリケーションの強制停止
実行中のバッチアプリケーションを強制停止します。

バッチアプリケーションのログ出力
バッチアプリケーションの実行ログを出力します。

バッチアプリケーション実行機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-2　バッチアプリケーション実行機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

バッチアプリケーションの実行
－
－
－
－
－
－
○
14.2.2

バッチアプリケーションの強制停止
－
－
○
－
－
－
○
14.2.3

バッチアプリケーションのログ出力
－
－
○
－
－
－
○
14.2.4

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.2.2　EJBアクセス機能の概要

バッチアプリケーションからほかのJ2EEアプリケーション内のEJBにアクセスできます。バッチアプリケーションからEJBにアクセスするときに使用できる機能の概要について説明します。

機能の詳細については，「14.3　EJBアクセスで使用できる機能」を参照してください。

Enterprise Beanの呼び出し
バッチアプリケーションからEnterprise Beanを呼び出せます。

JNDIによるEJBホームオブジェクト・ビジネスインタフェースのリファレンスのルックアップ
自動的にバインドされる名称またはユーザ指定名前空間を利用して，EJBホームオブジェクトおよびビジネスインタフェースのリファレンスをネーミングサービスからルックアップできます。

トランザクションの実装
バッチアプリケーションでトランザクションを使用できます。

RMI-IIOP通信のタイムアウト
バッチアプリケーション－CORBAネーミングサービス間，バッチアプリケーション－Enterprise Bean間の通信に対して，タイムアウトを設定できます。

RMI-IIOPスタブ，インタフェースの取得
バッチアプリケーションから，Cosminexus TPBrokerのRMI-IIOPの機能を利用してアプリケーションを呼び出せます。

EJBアクセス機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-3　EJBアクセス機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

Enterprise Beanの呼び出し
－
－
－
○
－
○
○
6.2

JNDIによるEJBホームオブジェクト・ビジネスインタフェースのリファレンスのルックアップ
－
－
－
○
－
○
○
6.3

トランザクションの実装
－
－
－
○
－
○
○
6.4

RMI-IIOP通信のタイムアウト
－
－
－
○
－
○
○
5.9.4

RMI-IIOPスタブ，インタフェースの取得
－
－
－
○
－
○
○
6.6

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。

3.2.3　ネーミング管理が提供する機能の概要

J2EEサービスのうち，ネーミング管理が提供する機能の概要について説明します。

なお，機能の詳細については，「14.4　ネーミング管理が提供する機能」を参照してください。

JNDI名前空間へのオブジェクトのバインドとルックアップ
オブジェクトをJDNI名前空間の名前とバインドして管理します。クライアントからは，バインドされた名前を使用して検索（ルックアップ）できます。

J2EEリソースへの別名付与（ユーザ指定名前空間機能）
J2EEリソースに別名を付与できます。バッチアプリケーションからは，別名として設定した任意の名称でルックアップできます。なお，バッチアプリケーションからデータベースに接続する場合，J2EEリソースには必ず別名を設定してください。

ラウンドロビンポリシーによるCORBAネーミングサービスの検索
複数のCORBAネーミングサービスに登録されている同一名称（別名）のEJBホームオブジェクトリファレンスを，ラウンドロビンポリシーに従ってルックアップできます。

ネーミング管理機能でのキャッシング
ルックアップしたEJBホームオブジェクトリファレンスをキャッシングしておき，2回目以降に同じオブジェクトをルックアップする場合の処理を短くできます。

CORBAネーミングサービスの切り替え
ルックアップの対象にするJNDI名前空間を，InitialContextクラスのインスタンスのプリフィックス判定によって切り替えられます。

J2EEサービスのうち，ネーミング管理が提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-4　J2EEサービス（ネーミング管理）が提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

JNDI名前空間へのオブジェクトのバインドとルックアップ
－
－
－
○
－
○
○
8.2

J2EEリソースへの別名付与（ユーザ指定名前空間機能）
－
－
－
○
－
－
○
8.3※

ラウンドロビンポリシーによるCORBAネーミングサービスの検索
－
－
－
○
－
－
○
8.4

ネーミング管理機能でのキャッシング
－
○
－
－
－
－
○
8.5

CORBAネーミングサービスの切り替え
－
－
－
○
－
－
○
8.6

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

注※

参照先の記述のうち，J2EEリソースに関する説明を参照してください。バッチアプリケーションの場合，Enterprise Beanの説明は該当しません。

3.2.4　リソース接続とトランザクション管理が提供する機能の概要

J2EEサービスのうち，リソース接続とトランザクション管理が提供する機能の概要について説明します。なお，機能の詳細については，「14.5　リソース接続とトランザクション管理が提供する機能」を参照してください。

コネクションプーリング
コネクションをメモリ上にプールしておくことで，アプリケーションからの接続要求に対して高速に処理できます。また，次のような機能も使用できます。

サーバ起動時またはリソースアダプタ起動時に，指定した数のコネクションを作成して，それをプールしておくことで，コネクションプール開始直後の接続要求を高速に処理する機能（コネクションプールのウォーミングアップ）

一定間隔で，プール内の不要なコネクションを段階的に減少させる機能（コネクション数調節）

コネクションシェアリング・アソシエーション
コネクションを共有することで，コネクション取得処理に掛かる処理時間を短縮できます。
コネクションシェアリングでは，論理コネクションと接続先リソースのコネクションである物理コネクションを多対1で接続します。
コネクションアソシエーションは，コネクションシェアリングができない場合に使用します。論理コネクションと接続先リソースのコネクションである物理コネクションを多対1で接続しますが，使用しない物理コネクションを作成する必要があります。

ステートメントプーリング
PreparedStatementおよびCallableStatementを使用する処理の場合に，これらのステートメントをプーリングしておくことで，同じステートメント作成に掛かる処理時間を短縮できます。

ライトトランザクション
ローカルトランザクションを使用するための環境を最適化できます。バッチサーバの場合，ライトトランザクションを有効にします。

DataSourceオブジェクトのキャッシング
JNDIインタフェースを使用して，DataSource型のオブジェクトの検索要求をする場合，DataSourceオブジェクトをキャッシングできます。

DB Connectorのコンテナ管理でのサインオンの最適化
コンテナ管理でサインオンをする場合，サインオンの動作を最適化できます。

受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）
実行したSQLに対して返却される実行結果を格納する領域（受信バッファ）をプールリングしておくことで，SQL実行時のオーバーヘッドを削減できます。

コネクションの障害検知
プーリングされているコネクションにトラブルが発生していないかを検知できます。これによって，ユーザプログラムからのコネクション要求に対して，有効なコネクションだけを返却できます。

コネクション枯渇時のコネクション取得待ち
コネクションプールに指定した最大数までコネクションがプールされていて，利用できるコネクションがない場合は，コネクション取得要求を待ち状態にできます。

コネクションの取得リトライ
使用できるコネクションがコネクションプールにない場合や接続先リソースの物理コネクションの確立に失敗した場合に，自動的にコネクションの取得処理を再実行できます。

コネクションプールの情報表示
コマンドを使用して，コネクションプール内のコネクションの情報を表示できます。

コネクションプールのクリア
データベースサーバにトラブルが発生してコネクションが切断された場合などに，不要なコネクションプールをコマンドで削除できます。

トランザクションタイムアウトとステートメントキャンセル
トランザクション開始時間から一定時間経過した時点で呼び出し先のトランザクションをロールバックします。また，実行中のSQL処理が返ってこない状態でトランザクションタイムアウトが発生した場合は，ステートメントをキャンセルできます。

障害調査用SQLの出力
デッドロックやスローダウンなどの障害が発生した時に，発行したSQLをログに出力でき，障害要因の解析に利用できます。

オブジェクトの自動クローズ
ユーザプログラムでオープンしたStatementオブジェクトなどをクローズできなかった場合，DB Connectorによってオブジェクトを自動的にクローズできます。

コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示）
データベースをクラスタ構成にしている場合，障害発生時やメンテナンス時に，コネクションプールを停止したり，再開したりできます。また，それぞれのコネクションプールの状態を表示できます。

リソースへの接続テスト
環境構築時に，リソースアダプタが正しく設定できているかどうかを確認できます。

J2EEサービスのうち，リソース接続とトランザクション管理が提供する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-5　J2EEサービス（リソース接続とトランザクション管理）が提供する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

コネクションプーリング
－
○
－
－
－
○
○
9.10.1

コネクションプールのウォーミングアップ
－
○
－
－
－
－
○

コネクションプール数調節機能
－
○
－
－
－
－
○

コネクションシェアリング・アソシエーション
－
○
－
－
－
○
－
9.10.2

ステートメントプーリング
－
○
－
－
－
－
○
9.10.3

ライトトランザクション
－
○
－
－
－
－
○
9.10.4

DataSourceオブジェクトのキャッシング
－
○
－
－
－
－
○
9.10.6

DB Connectorのコンテナ管理でのサインオンの最適化
－
○
－
－
－
－
○
9.10.7

受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）
－
○
－
－
－
－
○
9.10.8

コネクションの障害検知
○
－
－
－
－
○
○
9.11.1

コネクション枯渇時のコネクション取得待ち
○
－
－
－
－
－
○
9.11.2

コネクションの取得リトライ
○
－
－
－
－
－
○
9.11.3

コネクションプールの情報表示
○
－
－
－
－
－
○
9.11.4

コネクションプールのクリア
○
－
－
－
－
－
○
9.11.5

トランザクションタイムアウトとステートメントキャンセル
○
－
－
－
－
○
－
9.11.8

障害調査用SQLの出力
－
－
○
－
－
－
○
9.11.10

オブジェクトの自動クローズ
○
－
－
－
－
○
－
9.11.11

コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示）
○
－
－
－
－
－
○
9.12

リソースへの接続テスト
－
－
○
－
－
－
○
9.14

（凡例）　○：対応する　　－：対応しない

注

表中の項目「J2EE標準」と「拡張」の両方に○が付いている機能は，J2EE標準の機能にApplication Server独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.2.5　ガーベージコレクション制御機能の概要

ガーベージコレクション制御機能の概要について説明します。なお，機能の詳細については，「14.6　ガーベージコレクション制御機能」を参照してください。

ガーベージコレクション制御機能
バッチサーバでは，バッチアプリケーションが長時間リソースを排他するのを回避するため，ガーベージコレクション制御機能を提供しています。ガーベージコレクション制御機能を使用すると，リソース排他中のフルガーベージコレクションの実行を回避できます。

ガーベージコレクション制御機能の目的，およびJ2EE標準との対応について，次の表に示します。ガーベージコレクション制御機能はApplication Server独自の機能です。

表3-6　ガーベージコレクション制御機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

ガーベージコレクション制御機能
－
○
－
－
－
－
○
14.6

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.2.6　コンテナ拡張ライブラリが提供する機能の概要

コンテナ拡張ライブラリの概要について説明します。なお，機能の詳細については，「14.7　コンテナ拡張ライブラリ」を参照してください。

コンテナ拡張ライブラリの利用
コンテナ拡張ライブラリとは，アプリケーションが利用する共通のライブラリです。このライブラリを利用することによって，アプリケーションからユーザ作成の共通のライブラリを呼び出せるようになります。

コンテナ拡張ライブラリの機能の目的，およびJ2EE標準との対応について，次の表に示します。コンテナ拡張ライブラリの機能はApplication Server独自の機能です。

表3-7　コンテナ拡張ライブラリの機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

コンテナ拡張ライブラリの利用
－
－
－
○
－
－
○
14.7

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.3　システム構築時に使用する機能の概要

ここでは，アプリケーションサーバの構築を支援する機能について説明します。

システムの構築支援機能
Cosminexusでは，システムの構築支援機能として，Smart Composer機能を提供しています。
Smart Composer機能を使用して構築したシステムでは，アプリケーションサーバを構成するプロセスである，Management Serverを使用するため，システムの一括構築，および一括運用ができます。
なお，バッチアプリケーションを実行するアプリケーションサーバの構築には，セットアップウィザードは使用できません。

リソースアダプタの設定機能
リソースアダプタの設定機能には，次の2種類があります。

サーバ管理コマンド

Server Plug-in

サーバ管理コマンドを使用する場合はCUIでの操作，Server Plug-inを使用する場合はGUIでの操作となります。
なお，Server Plug-inは，UNIX環境では使用できません。Server Plug-inを使用してUNIXの実行環境に対して操作したい場合は，別途，uCosminexus Operatorをインストールしたマシンを用意してください。uCosminexus OperatorのServer Plug-inを使用して運用管理操作を実施します。uCosminexus Operatorについては，「2.6.3　uCosminexus Operatorの機能概要」を参照してください。

複数の構築済み実行環境の切り替え
1台のマシンに，複数の構築済み実行環境を共存させて切り替えられます。これによって，同じ製品のバージョン違いや，パッチ適用の有無などによる動作確認を1台のマシンで検証できます。なお，この機能はWindows環境では使用できません。

Cosminexusシステムの構築時に使用する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-8　システム構築時に使用する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

システムの構築支援機能
－
－
－
－
○
－
○
16章

リソースアダプタの設定機能
－
－
－
－
○
－
○
16.7

複数の構築済み実行環境の切り替え
－
－
－
－
○
－
○
16.8

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.4　システム運用時に使用する機能の概要

ここでは，アプリケーションサーバの運用を支援する機能の概要と特性について説明します。運用を支援する機能を次のように分類して説明します。

Management Serverによる運用管理機能

システムの日常運用を支援する機能

システムの保守を支援する機能

システムの監査を支援する機能

＜この節の構成＞

3.4.1　Management Serverによる運用管理機能の概要

3.4.2　システムの日常運用を支援する機能の概要

3.4.3　システムの保守を支援する機能の概要

3.4.4　システムの監査を支援する機能の概要

3.4.1　Management Serverによる運用管理機能の概要

Management Serverによる運用管理機能の概要について説明します。Management Serverは，Smart Composer機能でシステムを構築した場合に利用できます。

運用管理ドメイン内の論理サーバを一括運用管理するために，次の機能が使用できます。

論理サーバの起動と停止が一括実行できます。

運用管理ドメイン内の論理サーバの運用監視ができます。

運用管理ドメイン内の性能解析トレースファイルを収集できます。

稼働情報をCSV形式またはSNMP連携形式のファイルとして出力できます。

それぞれの機能の詳細については，「17.1.2　バッチアプリケーションの実行環境の日常運用」，および「18.1　システムの保守の概要」を参照してください。

3.4.2　システムの日常運用を支援する機能の概要

システムの日常運用を支援する機能の概要について説明します。

稼働情報の監視（稼働情報収集機能）
バッチサーバの稼働状態を定期的に監視し，サーバ性能やリソースの情報などの稼働情報を取得します。

稼働情報の監視（運用管理コマンド）
運用管理コマンドを使用して，運用管理ドメイン内の論理サーバを監視し，稼働情報を取得します。

リソースの枯渇監視
バッチサーバを対象に，メモリやスレッドなどのリソースを監視します。監視対象のリソースについての情報は，一定間隔でファイルに出力されます。また，監視対象のリソースの状態が設定したしきい値を超えた場合には，アラートが発生します。アラートが発生すると，メッセージを出力し，Management Serverに対してイベントを通知します。

Managementイベントによる処理の自動実行
バッチサーバが稼働中に出力するすべてのメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。

システムの処理性能の解析
Cosminexusシステムの各機能が出力する性能解析情報を収集する機能です。この情報を基に，システム性能およびボトルネックを分析できます。

システムの日常運用を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-9　システムの日常運用を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

稼働情報の監視（稼働情報の収集機能）
－
－
○
－
－
－
○
17.5

稼働情報の監視（運用管理コマンド）
－
－
○
－
－
－
○
17.6

リソースの枯渇監視
－
－
○
－
－
－
○
17.7

Managementイベントによる処理の自動実行
－
－
○
－
－
－
○
17.8

システムの処理性能の解析
－
－
○
－
－
－
○
17.10

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.4.3　システムの保守を支援する機能の概要

システムの保守を支援する機能の概要について説明します。

ユーザログ出力
バッチアプリケーションで例外が発生した場合に，メッセージおよびログを日立トレース共通ライブラリ形式で出力できます。

コンソールログ出力
運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などのコンソール出力情報をコンソールログに出力できます。

障害検知時コマンド
Management Serverが論理サーバの障害を検知したときに，トラブルシューティングの資料を取得できます。

snapshotログ収集
Cosminexusの構成ソフトウェアのsnapshotログを出力，収集できます。
例えば，システムにトラブルが発生した場合には，トラブルシューティング情報としてsnapshotログを自動的に収集できます。

システムの保守を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-10　システムの保守を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

ユーザログ出力
－
－
○
－
－
－
○
18.3

コンソールログ出力
－
－
○
－
－
－
○
18.4

障害検知時コマンド
－
－
○
－
－
－
○
18.2.3

snapshotログ収集
－
－
○
－
－
－
○
18.2.4

（凡例）　○：対応する　　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.4.4　システムの監査を支援する機能の概要

システムの監査を支援する機能の概要について説明します。

監査ログの出力
監査ログに，システムの構築者や運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴を出力することで，システムの監査に利用できます。

データベース監査証跡機能との連携
データベースが提供するデータベース監査証跡機能と連携することで，バッチアプリケーションがデータベースにアクセスした際に使用したアカウントを記録できます。

システムの監査を支援する機能の目的，およびJ2EE標準との対応について，次の表に示します。

表3-11　システムの監査を支援する機能の目的およびJ2EE標準との対応

機能名
目的
J2EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
J2EE標準
拡張

監査ログの出力
○
－
○
－
－
－
○
20.2

データベース監査証跡機能との連携
○
－
○
－
－
－
○
20.3

（凡例）　○：対応する　－：対応しない

注

表中の項目「拡張」だけに○が付いている機能はApplication Server独自の機能であることを示します。

3.5　ほかのプログラムと連携する機能の概要

ここでは，Application Serverとほかのプログラムを連携させることで実現できる機能の概要と特性について説明します。次に示すプログラムとの連携を説明します。

JP1との連携で実現する機能

クラスタソフトウェアとの連携で実現する機能

参考

この節で説明する機能はすべて，J2EE標準とは関係のない機能です。このため，J2EE標準との対応については説明しません。

＜この節の構成＞

3.5.1　JP1連携による運用管理機能の概要

3.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

3.5.1　JP1連携による運用管理機能の概要

JP1連携による運用管理機能の概要について説明します。

システムの集中監視（JP1/IMとの連携）
業務システム全体のリソースの状態を集中監視することで，稼働性能を把握，調査したり，トラブルの発生を検知して，原因を究明して対策したりできます。この機能はJP1/IMと連携して実現できます。

システムの構成定義および管理（JP1/IM - CMとの連携）
システム構築時にシステム構成を定義したり，定義したシステムについて，リソースやシステム構成に関する情報を集約して管理したりできます。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。この機能はJP1/IM - CMと連携して実現できます。なお，JP1/IM - CMと連携できるのは，Cosminexusで提供するSmart Composer機能を使用してシステムを構築する場合だけです。

ジョブによるシステムの自動運転（JP1/AJS2との連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義して自動化することで，効率的なリソースの配分や業務の効率化，省力化を図れます。JP1/AJS2と連携することで，カスタムジョブによるシステムの自動運転が実現できます。

シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図れます。JP1/AJS2 - SOと連携することで，シナリオによるシステムの自動運転が実現できます。なお，シナリオによるシステムの自動運転をする場合は，Smart Composer機能を使用して構築したシステムが前提となります。

監査ログの一括収集／管理（JP1/NETM/Auditとの連携）
システムの監査で使用する監査ログを，自動で収集して，一括管理できます。この機能はJP1/NETM/Auditと連携して実現できます。

JP1連携による運用管理機能の目的について，次の表に示します。

表3-12　JP1連携による運用管理機能の目的

機能名
目的
参照先

信頼性
性能
運用・
保守
拡張性
そのほか

システムの集中監視（JP1/IMとの連携）
－
－
○
－
－
21.2

システムの構成定義および管理（JP1/IM - CMとの連携）
－
－
○
－
－
21.3

ジョブによるシステムの自動運転（JP1/AJS2との連携）
－
－
○
－
－
21.4

シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
－
－
○
－
－
21.5

監査ログの収集・一元管理（JP1/NETM/Auditとの連携）
－
－
○
－
－
21.6

（凡例）　○：対応する　　－：対応しない

3.5.2　クラスタソフトウェアとの連携による系切り替え機能の概要

クラスタソフトウェアとの連携による系切り替え機能の概要について説明します。Cosminexusと連携できるクラスタソフトウェアは，Microsoft Cluster Service（Windowsの場合※），およびHAモニタ（AIX・HP-UX・Linuxの場合）です。なお，Solarisの場合，クラスタソフトウェアと連携したシステム運用はできません。

注※

ただし，使用できるOSは，Windows Server 2003 Enterprise Edition，Windows Server 2003 R2 Enterprise Edition，Windows Server 2003 Enterprise x64 Edition，およびWindows Server 2003 R2 Enterprise x64 Editionとなります。

1:1系切り替えシステム
実行系と待機系が1対1になるシステム構成です。バッチアプリケーション実行環境の場合，アプリケーションサーバの1:1系切り替えシステムでの運用をサポートしています。実行系サーバでの障害発生時またはシステムの保守時に，あらかじめ待機させておいたサーバに自動的に切り替えて，業務処理を続行するための機能です。これによって，システムの不稼働時間を短縮し，クライアントの業務処理への影響を減らせます。
なお，バッチアプリケーション実行環境の場合，運用管理サーバを配置しないため，運用管理サーバの1:1系切り替えシステムは使用できません。

相互系切り替えシステム
1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。Cosminexusでは，アプリケーションサーバの相互系切り替えシステムでの運用をサポートしています。

クラスタソフトウェアとの連携による系切り替え機能の目的について，次の表に示します。

表3-13　クラスタソフトウェアとの連携による系切り替え機能の目的

機能名
目的
参照先

信頼性
性能
運用・
保守
拡張性
そのほか

1:1系切り替えシステム
○
－
○
－
－
22.3

相互系切り替えシステム
○
－
○
－
－
22.4

（凡例）　○：対応する　　－：対応しない

4.　Webコンテナ

この章では，サーブレットとJSPを実行するためのサーバ基盤である，Webコンテナの機能について説明します。Webコンテナの機能は，サーブレットまたはJSPを使用したJ2EEアプリケーションを実行する場合に使用します。

＜この章の構成＞

4.1　Webコンテナの機能

4.2　Webアプリケーションの実行

4.3　インプロセスHTTPサーバによるリクエストの受け付け

4.4　セッション管理

4.5　文字コード変換

4.6　デフォルトの文字エンコーディング設定

4.7　JSPの事前コンパイルとコンパイル結果の保持

4.8　アプリケーションのイベントリスナ

4.9　タグファイルの実行

4.10　JSP ELの実行

4.11　リクエストおよびレスポンスのフィルタリング

4.12　フィルタリングによるHTTPレスポンスの圧縮

4.13　Webコンテナのセキュリティ管理

4.14　EJBコンテナとの連携

4.15　データベースとの接続

4.16　Webコンテナによるスレッドの作成

4.17　同時実行スレッド数の制御

4.18　Webコンテナ単位での同時実行スレッド数の制御

4.19　Webアプリケーション単位での同時実行スレッド数の制御

4.20　URLグループ単位での同時実行スレッド数の制御

4.21　ユーザスレッドで使用できるApplication Serverの機能

4.22　通信タイムアウトの設定

4.23　Webサーバ（リダイレクタ）によるリクエストの振り分け

4.24　エラーページのカスタマイズ

4.25　ドメイン名指定でのトップページの表示

4.26　Webコンテナへのゲートウェイ情報の通知

4.27　Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレス指定

4.28　静的コンテンツのキャッシュ

4.29　簡易Webサーバ機能

4.30　Webコンテナが返すエラーステータスコード

4.31　前バージョンからのJSPの移行

4.32　サーブレット，JSPの実装

4.1　Webコンテナの機能

Webコンテナでは，Webアプリケーションの実行機能を提供するコンテナとしての機能と，Webサーバと連携するためのリダイレクタの機能，およびWebクライアントからのリクエストを受け付けるWebサーバ機能を提供しています。リダイレクタとは，Webコンテナで提供しているライブラリです。リダイレクタをWebサーバに登録することで，WebサーバあてのHTTPリクエストのうち特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできるようになります。

Webコンテナの機能を次の表に示します。

表4-1　Webコンテナの機能

機能 | 参照先
Webアプリケーションの実行 | 4.2
インプロセスHTTPサーバによるリクエストの受け付け | 4.3
セッション管理 | 4.4
文字コード変換 | 4.5
デフォルトの文字エンコーディング設定 | 4.6
JSPの事前コンパイルとコンパイル結果の保持 | 4.7
アプリケーションのイベントリスナ | 4.8
タグファイルの実行 | 4.9
JSP ELの実行 | 4.10
リクエストおよびレスポンスのフィルタリング | 4.11
フィルタリングによるHTTPレスポンスの圧縮 | 4.11.1，4.12
Webコンテナのセキュリティ管理 | 4.13
EJBコンテナとの連携 | 4.14
データベースとの接続 | 4.15
Webコンテナによるスレッドの作成 | 4.16
同時実行スレッド数の制御 | 4.17，4.18，4.19，4.20
ユーザスレッドの使用 | 4.21
通信タイムアウトの設定 | 4.22
Webサーバ（リダイレクタ）によるリクエストの振り分け | 4.23
エラーページのカスタマイズ※ | 4.24
ドメイン名指定でのトップページの表示 | 4.25
Webコンテナへのゲートウェイ情報の通知 | 4.26
Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレスの指定 | 4.27
静的コンテンツのキャッシュ | 4.28
簡易Webサーバ機能 | 4.29
セッションフェイルオーバ機能 | 4.11.1，12章

注※

WebサーバとしてHitachi Web Serverを使用する場合だけ使用できる機能です。Microsoft IISを使用する場合，この機能は使用できません。

参考

アプリケーション開発時に，Cosminexusが提供するcjjsp2javaコマンドを使用することで，JSPファイルからJavaソースファイルを生成し，JSPに記述ミスがないかを確認できます。

なお，Cosminexusで提供するWebコンテナの機能には，J2EEで規定された機能にCosminexus独自の機能を拡張したものと，Cosminexus独自の機能として提供しているものがあります。Cosminexus独自の機能かどうかについては，「2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）」を参照してください。

4.2　Webアプリケーションの実行

Webコンテナでは，Webアプリケーションを実行できます。Webアプリケーションとは，Webコンテナ上で動作するサーバプログラムのことです。

通常のWebサーバは，固定されたHTMLファイルだけを送信します。Webコンテナが機能することによって，Webコンテナ上でWebアプリケーションを実行し，Webクライアントから受け取ったデータを処理したり，その処理の結果に応じて異なるWebページを生成したりできるようになります。

Webアプリケーションは，主に，サーブレットおよびJSPと呼ばれる2種類の技術を使用して開発されたアプリケーションです。サーブレットはJavaプログラムを使い，HTMLを生成したり，Webクライアントから受け取った情報を処理したりする技術です。JSP（JavaServer Pages）はサーブレット技術を基盤に，HTMLページの中にタグやJavaプログラムを埋め込むことで，動的にWeb画面を生成する技術です。JSPはJSPコンパイラによって，一度Javaで記述されたサーブレットプログラムに変換され，そのあと，Javaコンパイラによってコンパイル，実行されます。

CosminexusのWebコンテナでは，Java Servlet 2.4仕様，およびJavaServer Pages（JSP）2.0仕様に準拠したWebアプリケーションを実行できます。Webアプリケーション実行機能の詳細については，Java Servlet Specification v2.4，およびJavaServer Pages Specification v2.0を参照してください。また，Webコンテナを使用してWebアプリケーションを実行するには，WebサーバとしてHitachi Web ServerまたはMicrosoft IISを使用するか，インプロセスHTTPサーバを使用する必要があります。

＜この節の構成＞

4.2.1　Webアプリケーションのデプロイとアンデプロイ

4.2.2　Webアプリケーションを実行する場合の留意事項

4.2.3　Webアプリケーションでのアノテーション指定

4.2.1　Webアプリケーションのデプロイとアンデプロイ

Webアプリケーションは，デプロイすることによって，実行可能な状態になります。

WAR形式のWebアプリケーションを実行可能な状態に配置するには，WebアプリケーションをEAR形式にパッケージ化してアーカイブ形式のJ2EEアプリケーションにするか，または展開ディレクトリ形式のJ2EEアプリケーションにしてデプロイする必要があります。実行できるJ2EEアプリケーションの形態の詳細については，「7.　J2EEアプリケーションの実行」を参照してください。

複数のWebアプリケーションのデプロイを実行した場合，Webアプリケーションごとに独立のクラスローダが作成されます。このため，異なるWebアプリケーションで同一のクラス名のクラス（Loginサーブレットなど）を用いた場合でも，別々のクラスローダ上で独立に扱われます。

なお，J2EEアプリケーションとしてデプロイしたWebアプリケーションをアンデプロイする場合は，J2EEアプリケーションごとアンデプロイします。WAR単位でアンデプロイすることはできません。

4.2.2　Webアプリケーションを実行する場合の留意事項

ここでは，Webアプリケーションを実行する場合の留意事項について説明します。

＜この項の構成＞

(1)　サーブレット/JSPのデフォルトマッピングについて

(2)　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値について

(3)　サーブレットのインスタンス作成数

(4)　サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

(5)　レスポンス送信時に使用されるサーブレットのバッファ

(6)　クエリ文字列の解析について

(1)　サーブレット/JSPのデフォルトマッピングについて

クライアントがリクエストするURLに対してどのサーブレットが呼び出されるかの設定をサーブレットマッピングといいます。Java Servlet Specification v2.4では，サーブレットマッピングをDD（WEB-INF/web.xml）内に記述するように求めています。

これに対して，Webコンテナでデフォルトで定義されているマッピングをデフォルトマッピングといいます。Webコンテナでは，次に示すマッピングをデフォルトで定義しています。

表4-2　Webコンテナで定義されているサーブレット/JSPのデフォルトマッピング

URL
取り扱い

*.jsp
JSPファイルとして取り扱われます。

*.jspx
JSPドキュメントとして取り扱われます。なお，Servlet 2.2およびServlet 2.3の場合は静的コンテンツとして扱われます。

/servlet/*
URLの「*」の部分には，サーブレットの完全修飾クラス名，またはweb.xmlで定義したサーブレット名を指定できます。サーブレットの完全修飾クラス名を指定した場合，指定したサーブレットが実行されます。サーブレット名を指定した場合，web.xmlで定義したサーブレットが実行されます。
実行するサーブレットのクラスは，WEB-INF/classes以下，またはWEB-INF/lib以下に配置されたJARファイルに含まれている必要があります。実行するサーブレットは，サーブレット名から検索されます。
URLに指定された「*」の部分がサーブレット名として定義されていない場合，サーブレットクラスが検索されます。

(2)　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値について

Webコンテナでは，次に示すタグがDD（WEB-INF/web.xml）に設定されていない場合，次に示すデフォルト値を使用します。

表4-3　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値

タグ名
設定されていない場合のデフォルト値

welcome-file-list

<welcome-file-list>
   <welcome-file>
       index.jsp
   </welcome-file>
   <welcome-file>
       index.html
   </welcome-file>
   <welcome-file>
       index.htm
   </welcome-file>
</welcome-file-list>

session-timeout
30

mime-mapping
拡張子とMIMEタイプとの対応づけ。

DD（WEB-INF/web.xml）にこれらのタグを設定している場合には，次の設定となります。

<welcome-file-list>タグに設定された値で，デフォルト値を上書きします。

<session-timeout>タグに設定された値で，デフォルト値を上書きします。

<mime-mapping>タグに定義した拡張子単位の設定で，デフォルト値を拡張子単位に上書きします。

なお，DD（WEB-INF/web.xml）のmime-mappingタグにデフォルトで設定されている拡張子とMIMEタイプの対応づけについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(3)　サーブレットのインスタンス作成数

Webアプリケーション単位に同じクラスのサーブレットのインスタンスを一つ作成します。SingleThreadModelを継承したサーブレットのインスタンスも，一般のサーブレットと同様にWebアプリケーション単位に一つ作成します。

ただし，同一のサーブレットおよびJSPに対して，デフォルトのマッピングとDDに記述したマッピングの両方でアクセスすると，インスタンスは次のように生成されます。

表4-4　デフォルトマッピングとDDに記述したマッピングの両方でアクセスする場合のインスタンスの生成

URL
インスタンス

*.jsp
DDに記述したマッピングでアクセスした場合とは別のインスタンスが生成されます。

*.jspx

/servlet/*

サーブレットの完全修飾クラス名を指定した場合
DDに記述したマッピングでアクセスした場合とは別のインスタンスが生成されます。

web.xmlで定義したサーブレット名を指定した場合
DDに記述したマッピングでアクセスした場合と同じインスタンスが生成されます。

また，SingleThreadModelを継承した単一のサーブレットに対して，Webアプリケーション単位にリクエストが並列に複数到着した場合，各スレッドがオーバラップしないで1スレッドずつ順に実行するように制御します。

(4)　サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

サーブレットのinitメソッドおよびserviceメソッドの実行のタイミングは，デフォルトマッピングかサーブレットマッピングかによって異なります。

デフォルトマッピングでサーブレットにアクセスした場合
サーブレットのinitメソッドおよびserviceメソッドは，該当するURLにマッピングされているフィルタの処理の延長で，実行されます。

サーブレットマッピングでサーブレットにアクセスした場合
initメソッドはフィルタの処理の前に，実行されます。serviceメソッドは，該当するURLにマッピングされたフィルタの処理の延長で，実行されます。

(5)　レスポンス送信時に使用されるサーブレットのバッファ

レスポンス送信時に使用されるサーブレットのバッファは，リクエスト処理スレッドの数だけ保持されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを使用してバッファサイズを変更する場合は，バッファサイズ×リクエスト処理スレッド数分のメモリが確保されることを考慮した上で，メモリ使用量を見積もってください。

(6)　クエリ文字列の解析について

クエリ文字列は，URLの?マーク以降に，"名前=値"の組が一つ以上組み合わさって構成されます。

Cosminexusでは，"名前=値"の部分に複数の"="がある場合，最初の"="より前の文字列が名前，後ろの文字列が値となります。例えば，URLが「http://host/examples?a=b=c」の場合は，「名前"a"の値は"b=c"」と解析されます。

4.2.3　Webアプリケーションでのアノテーション指定

Webアプリケーションにはアノテーションを指定できます。アノテーションとは，Webアプリケーションが依存しているリソースやほかのEnterprise Beanへの参照を取得するために使用する記述方式で，Servlet 2.4の場合に指定できます。なお，Servlet 2.3以前のバージョンのweb.xmlがある場合，アノテーションの指定は無効になります。

＜この項の構成＞

(1)　指定できるアノテーション

(2)　DIを使用するWebアプリケーションのリロード

(3)　Webアプリケーションのアノテーション参照抑止

(4)　インポート時の注意

(1)　指定できるアノテーション

Webアプリケーションに指定できるアノテーションは次のとおりです。

@Resource

@Resources

@EJB

@EJBs

ポイント

@Resourceアノテーションで指定できるリソースのタイプについては，「5.2.5(1)　@Resourceアノテーションで指定できるリソースのタイプ」を参照してください。

なお，@EJBおよび@Resourceアノテーションのname属性は，web.xmlのタグの要素と対応しています。このため，アノテーションでEnterprise Beanおよびリソースへの参照を定義する場合は，@EJBおよび@Resourceアノテーションのname属性と，name属性に対応するweb.xmlのタグに指定する要素は，重複しないように設定してください。name属性に対応するweb.xmlのタグを次の表に示します。

表4-5　name属性に対応するweb.xmlのタグ

アノテーションと属性 | name属性に対応するweb.xmlのタグ
@EJB　name() | <ejb-ref>タグ下の<ejb-ref-name>タグ
<ejb-local-ref>タグ下の<ejb-ref-name>タグ
@Resource　name() | <env-entry>タグ下の<env-entry-name>タグ
<resource-ref>タグ下の<res-ref-name>タグ
<resource-env-ref>タグ下の<resource-env-ref-name>タグ

参考

Webアプリケーションのアノテーション指定時の注意は，Enterprise Beanにアノテーションを指定するときの注意と同じになります。Enterprise Beanのアノテーション指定については，「5.2.4　Enterprise Beanのアノテーション指定」もあわせて参照してください。

(2)　DIを使用するWebアプリケーションのリロード

DIを使用するWebアプリケーションのリロード時には，例外が発生することがあります。例外が発生する場合を次に示します。

DIターゲット（DI機能を使用して参照を注入する対象）を定義しているクラス，または参照先クラスのロードに失敗した場合

DIターゲット名に対応したフィールド，メソッドがリロード後に削除されて，存在しない場合

例外が発生すると，メッセージログにKDJE53904-Wのメッセージが出力され，処理が続行されます。処理は続行されますが，対象となるインスタンスに対するDIが実行できない状態になり，対象のインスタンスへのリクエストが実行できなくなります。このため，このメッセージが出力された場合は，Webアプリケーションを修正して再度リロードを実施してください。

(3)　Webアプリケーションのアノテーション参照抑止

Cosminexusは，Servlet2.4仕様に基づいたWebアプリケーションでもアノテーションを使用できます。しかし，アノテーションの有無を判断するためにWebアプリケーションを解析するため，アノテーションを使用していない場合でも解析によるオーバーヘッドが大きくなります。アノテーションを使用しない場合は，アノテーション参照抑止機能を使用することで解析によるオーバーヘッドを減らすことができます。アノテーション参照抑止機能は，J2EEサーバ単位で設定できます。アノテーション参照抑止機能については，「5.2.7　アノテーションの参照抑止」を参照してください。

(4)　インポート時の注意

WARファイルからEJB-JARファイルを参照している場合，WARファイルとEJB-JARファイルの両方を含んだアプリケーションにしてからインポートしてください。ただし，参照するインタフェースをWARファイルに含めている場合は，WARファイルを個別にインポートすることもできます。

4.3　インプロセスHTTPサーバによるリクエストの受け付け

インプロセスHTTPサーバは，J2EEサーバのプロセス内で提供されるWebサーバ機能です。

Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。このため，性能を重視したシステムでは，インプロセスHTTPサーバを使用することを推奨します。

ただし，Hitachi Web ServerおよびMicrosoft IISと比べて提供機能に差異があるため，機能差異を確認した上で，インプロセスHTTPサーバを使用するかどうか検討してください。また，インプロセスHTTPサーバとWebサーバ連携機能を同時に使用することはできません。システム設計時に，あらかじめどちらの機能を使用するか選択しておく必要があります。選択の指針については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

なお，インプロセスHTTPサーバを使用する場合，次のことが前提となります。

インプロセスHTTPサーバは不正アクセスが想定される外部ネットワークからのアクセスが可能なDMZに配置しないで，ファイアウォール内の内部ネットワークに配置する必要があります。インターネットなどの外部ネットワークからアクセスされるシステムでは，DMZにプロキシサーバを配置して，内部ネットワークのインプロセスHTTPサーバに転送するようにシステムを構築する必要があります。インプロセスHTTPサーバを使用する場合のシステム構成については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

インプロセスHTTPサーバでは，HTTPだけがサポートされています。HTTPSはサポートされていません。HTTPSを使用する場合，SSLアクセラレータ，またはHitachi Web Serverのリバースプロキシを使用することが前提となります。

インプロセスHTTPサーバを使用してアクセスできるのは，J2EEサーバ上にデプロイされたWebアプリケーションだけです。なお，静的コンテンツだけをデプロイすることはできませんが，リダイレクトによるリクエストの振り分け，およびエラーページのカスタマイズを実行する場合だけ，Webアプリケーションに含まれない静的コンテンツを指定できます。

インプロセスHTTPサーバの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ポイント

インプロセスHTTPサーバは，デフォルトでは使用しない設定になっています。

＜この節の構成＞

4.3.1　インプロセスHTTPサーバで使用できる機能

4.3.2　Webクライアントからの接続数とリクエスト処理スレッド数の制御

4.3.3　Webクライアントからの同時接続数の制御

4.3.4　Persistent Connectionによる通信制御

4.3.5　インプロセスHTTPサーバで設定できる通信タイムアウト

4.3.6　アクセスを許可するホストの制限によるアクセス制御

4.3.7　リクエストデータのサイズの制限によるアクセス制御

4.3.8　有効なHTTPメソッドの制限によるアクセス制御

4.3.9　HTTPレスポンスヘッダのカスタマイズ

4.3.10　エラーページのカスタマイズ

4.3.11　リダイレクトによるリクエストの振り分け

4.3.12　ログ・トレースの出力

4.3.13　インプロセスHTTPサーバが返すエラーステータスコード

4.3.1　インプロセスHTTPサーバで使用できる機能

インプロセスHTTPサーバで使用できる機能と参照先を次の表に示します。

表4-6　インプロセスHTTPサーバで使用できる機能と参照先

機能名 | 参照先
Webクライアントからの接続数とリクエスト処理スレッド数の制御 | 4.3.2
リクエストの流量制御 | Webクライアントからの同時接続数の制御 | 4.3.3
同時実行スレッド数の制御※ | 4.17，4.18，4.19，4.20
Webクライアントとの通信制御 | Persistent Connectionによる通信制御 | 4.3.4
インプロセスHTTPサーバで設定できる通信タイムアウト | 4.3.5
インプロセスHTTPサーバで利用するIPアドレスの指定※ | 4.27
Webクライアントからのアクセス制御 | アクセスを許可するホストの制限 | 4.3.6
リクエストデータのサイズ制限 | 4.3.7
有効なHTTPメソッドの制限 | 4.3.8
Webクライアントへのレスポンスのカスタマイズ | HTTPレスポンスヘッダのカスタマイズ | 4.3.9
エラーページのカスタマイズ | 4.3.10
リダイレクトによるリクエストの振り分け | 4.3.11
Webコンテナへのゲートウェイ情報の通知※ | 4.26
ログ・トレースの出力 | 4.3.12

注※

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。

4.3.2　Webクライアントからの接続数とリクエスト処理スレッド数の制御

ここでは，Webクライアントからの接続数の制御と，リクエスト処理スレッド数の制御について説明します。

インプロセスHTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，インプロセスHTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。

このように，Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。

Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御について説明します。

＜この項の構成＞

(1)　Webクライアントからの接続数の制御

(2)　リクエスト処理スレッド数の制御

(3)　リクエスト処理スレッド数の遷移例

(1)　Webクライアントからの接続数の制御

インプロセスHTTPサーバでは，一度に接続するWebクライアントやプロキシサーバの数の最大値を設定して，リクエスト処理スレッド数を制御します。インプロセスHTTPサーバではWebクライアントからの接続数分のリクエスト処理スレッドを作成するため，Webクライアントからの接続数の最大値は，インプロセスHTTPサーバで作成するリクエスト処理スレッド数の上限となります。

なお，クライアントからの接続要求は，TCP/IPのListenキューに登録されて，リクエスト処理スレッドに渡されます。接続数の上限を超えたクライアントからの接続要求は，Listenキューに蓄えられます。Listenキューに蓄えられたクライアントからの接続要求が指定した最大値を超えた場合，クライアントはサーバへの接続に失敗します。

Webクライアントからの接続数の制御の概要を次の図に示します。

図4-1　Webクライアントからの接続数の制御の概要

(2)　リクエスト処理スレッド数の制御

インプロセスHTTPサーバでは，起動時にリクエスト処理スレッドを作成したあと，リクエスト処理スレッドの状態，およびスレッド数を定期的に監視します。インプロセスHTTPサーバにリクエストが集中している場合は，リクエスト処理スレッドを追加して十分な予備スレッドをプールしておき，リクエストが少ない場合は余分にプールしている予備スレッドを削除します。

リクエスト処理スレッド数の制御は次のように実行します。

J2EEサーバ起動時に，指定した数分のリクエスト処理スレッドを作成します。

J2EEサーバの稼働中はリクエスト処理スレッド数を監視します。

監視のタイミングで，予備スレッド数が指定した最小値より少ない場合は，リクエスト処理スレッドを追加して予備スレッドとしてプールします。また，予備スレッド数が指定した最大値より多い場合は，余分な予備スレッドを削除します。
なお，J2EEサーバ起動時に作成したスレッド数を維持することもできます。起動時に作成したスレッド数を維持する場合，リクエスト処理スレッドと予備スレッドの総数が起動時に作成したスレッド数以下の場合，予備スレッド数が最大値を超えていても予備スレッドは削除されません。例えば，起動時に作成したスレッド数が8で，予備スレッド数の最大値が5の場合，リクエスト処理スレッドが2で，予備スレッド数が6のときは，予備スレッドは削除されません。

(3)　リクエスト処理スレッド数の遷移例

リクエスト処理スレッド数の遷移について，例を使用して説明します。

遷移例1
次の内容が設定されていることとします。

Webクライアントからの最大接続数：15

Listenキューの登録数：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：10

J2EEサーバ起動時に作成したスレッド数の維持：無効

リクエスト処理スレッド数の遷移例を次の図に示します。

図4-2　リクエスト処理スレッド数の遷移例

図中の項番1～7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，Webクライアントからの最大接続数に達しているため，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，4スレッド削除します。

7リクエストを受信した時点で，予備スレッド数が最小値より少ないため，2スレッド追加します。

8リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，3スレッド削除します。

遷移例2
予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にすることによって，一度作成したリクエスト処理スレッドを削除しないで使い続けることができます。
予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例について説明します。
なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：15

J2EEサーバ起動時に作成したスレッド数の維持：無効

予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図4-3　予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例

図中の項番1～7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッドが14スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

7リクエストを受信した時点で，予備スレッドが7スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

8リクエストの処理が終了した時点で，予備スレッド数が15スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

設定例3
サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例について説明します。
なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：3

予備スレッドの最大値：5

J2EEサーバ起動時に作成したスレッド数の維持：有効

サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図4-4　J2EEサーバ起動時に作成したスレッドを維持する場合のリクエスト処理スレッド数の遷移例

図中の項番1～8について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

6リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため1スレッド追加します。

6リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値を超えていますが，サーバ起動時に作成したスレッド数を維持するため，1スレッドだけ削除します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

7リクエストの処理が終了した時点で，予備スレッドが8スレッドとなり，最大値を超えたため，3スレッド削除します。

3リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため，1スレッド追加します。

1リクエストの処理が終了した時点で，予備スレッド数が4スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

9リクエストの処理が終了した時点で，予備スレッド数が13スレッドとなり，最大値より多くなっていますが，J2EEサーバ起動時のスレッド数を維持するため，5スレッドだけ削除します。

4.3.3　Webクライアントからの同時接続数の制御

ここでは，Webクライアントからの同時接続数の制御について説明します。

インプロセスHTTPサーバでは，Webクライアントからの最大接続数の設定とあわせて，接続を拒否するリクエスト数を設定することによって，Webクライアントからの同時接続数を制御します。

Webクライアントからの接続数の増加や，J2EEアプリケーションなどの影響でJ2EEサーバの負荷が高くなった場合に，Webクライアントからのリクエストの受け付けを拒否して，即座にエラーを返すことで，Webクライアントは即座にレスポンスを受信できます。これによって，J2EEサーバの負荷を一定に抑え，リクエストに対するレスポンスタイムを維持します。

Webクライアントからの同時接続数の制御の概要を，次の図に示します。

図4-5　Webクライアントからの同時接続数の制御の概要

例えば，Webクライアントからの最大接続数を40として，接続を拒否するリクエスト数を1とする場合，インプロセスHTTPサーバに接続し同時にリクエストを処理できるWebクライアントの数は39となります。リクエスト処理中のスレッド数が39になると，残りの1スレッドは処理中のリクエスト処理スレッド数が減るまで受信したリクエストに対してエラーを返し続けます。Webクライアントからの同時接続数の制御の例を次の図に示します。

図4-6　Webクライアントからの同時接続数の制御の例

Webクライアントからの同時接続数の制御によって，接続を拒否したリクエストに対しては，ステータスコード503のエラーをWebクライアントに返します。このときクライアントに返すエラーページをカスタマイズすると，レスポンスメッセージのカスタマイズや，ほかのサーバへのリダイレクトができます。

Webクライアントへのレスポンスのカスタマイズ（インプロセスHTTPサーバの場合）の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

フレームを使用したページや，画像を挿入したページを表示する際，Webクライアントから複数のリクエストを受信する場合があります。その場合，Webクライアントからの同時接続数の制御によって表示されるページが部分的にエラーになることがあります。

4.3.4　Persistent Connectionによる通信制御

ここでは，Persistent Connectionによる通信制御について説明します。

Persistent Connectionは，WebクライアントとインプロセスHTTPサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるための機能です。Persistent Connectionを使用することによって，WebクライアントとWebサーバ間でのコネクション接続に掛かる時間を短縮し，処理時間の短縮と通信トラフィックの軽減を図れます。

インプロセスHTTPサーバでは，次に示す項目を設定することで，Persistent Connectionによる通信制御を実現します。

Persistent Connection数の上限値
Persistent Connection数の上限値を設定することで，一つのTCPコネクションで連続してリクエストを処理できるWebクライアント数を制御します。TCPコネクション数が指定した上限値を超えた場合，リクエスト処理終了後に切断します。これによって，新規リクエストを処理するスレッドが確保でき，リクエスト処理スレッドを特定のクライアントに専有されることを防げます。

Persistent Connectionのリクエスト処理回数の上限値
Persistent Connectionのリクエスト処理回数の最大値を設定することで，同じWebクライアントから連続してリクエスト要求があった場合の処理を制御します。
Persistent Connectionのリクエスト処理回数が指定した上限値を超えた場合，リクエスト処理終了後にコネクションを切断します。これによってリクエスト処理スレッドを特定のクライアントに専有し続けられることを防げます。

Persistent Connectionのタイムアウト
Persistent Connectionのリクエスト待ち時間にタイムアウトを設定することで，Persistent Connectionのリクエスト待ち時間を制御します。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションを切断します。これによって，使用されていない状態でTCPコネクションが専有され続けることを防げます。

なお，コネクションを切断されたWebクライアントは，接続のリトライを実行して，再度リクエストを送信します。

4.3.5　インプロセスHTTPサーバで設定できる通信タイムアウト

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間での，リクエスト受信およびレスポンス送信に，通信タイムアウトを設定できます。ネットワークの障害やアプリケーションの障害などが発生し応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

インプロセスHTTPサーバを使用する場合，次に示す図中の二つの矢印が示す通信に対してタイムアウトを設定します。

図4-7　タイムアウトを設定できる通信（インプロセスHTTPサーバを使用する場合）

図に示すように，通信タイムアウトはリクエスト受信とレスポンス送信に対して設定します。通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

なお，Webクライアントからのリクエスト受信，およびWebクライアントへのレスポンス送信でタイムアウトが発生した場合，Webクライアントまたはネットワークで障害が発生したと見なされて，Webクライアントとの接続が切断されるため，レスポンスは返されません。

＜この項の構成＞

(1)　リクエスト受信時の通信タイムアウト設定

(2)　レスポンス送受信時の通信タイムアウト設定

(1)　リクエスト受信時の通信タイムアウト設定

リクエスト受信時の通信タイムアウトの設定場所を次の図に示します。

図4-8　リクエスト受信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間の通信に，タイムアウトを設定します。

WebクライアントとインプロセスHTTPサーバ間の通信にタイムアウトを設定することによって，クライアント側で次に示す障害が発生したことを検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　レスポンス送受信時の通信タイムアウト設定

レスポンス送受信時の通信タイムアウトの設定場所を次の図に示します。

図4-9　レスポンス送信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，インプロセスHTTPサーバとWebクライアント間の通信に，タイムアウトを設定します。

インプロセスHTTPサーバとWebクライアント間の通信にタイムアウトを設定することによって，次に示す障害を検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

4.3.6　アクセスを許可するホストの制限によるアクセス制御

ここでは，アクセスを許可するホストの制限によるアクセス制御について説明します。

J2EEサーバへの不正アクセスを防ぐため，アクセスできるホストを制限できます。デフォルトでは，全ホストからのアクセスが可能な状態になっています。

ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名が解決されます。なお，ローカルホストは明記しなくても常にアクセスが許可されます。通常，外部ネットワークからアクセスされるシステムでは，プロキシサーバのIPアドレスを指定します。

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

注意事項

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

4.3.7　リクエストデータのサイズの制限によるアクセス制御

ここでは，リクエストデータのサイズの制限によるアクセス制御について説明します。

インプロセスHTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

インプロセスHTTPサーバでは，次に示す項目を設定することで，リクエストデータのサイズ制限によるアクセス制御を実現します。

リクエストラインの長さの制限
リクエストラインの長さの上限値を設定することで，アクセスを制御します。リクエストラインの長さには，HTTPメソッド，URI（クエリ文字列を含む），HTTPのバージョン，およびリクエストラインの終わりを示す改行文字（2バイト）が含まれます。
受信したリクエストラインの長さが上限値を超えた場合，Webクライアントに対して，ステータスコード414のエラーを返します。

HTTPヘッダ数の制限
HTTPリクエストに含まれるHTTPヘッダ数の上限値を設定することで，アクセスを制御します。
受信したHTTPリクエストに含まれるHTTPヘッダ数が上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストヘッダサイズの制限
HTTPリクエストのリクエストヘッダのサイズに上限値を設定することによって，アクセスを制御します。
受信したHTTPリクエストのHTTPヘッダのサイズが上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストボディサイズの制限
HTTPリクエストのボディサイズに上限値を設定することによって，アクセスを制御します。インプロセスHTTPサーバでは，リクエストヘッダに含まれるContent-Lengthヘッダの値で判断します。
HTTPリクエストのボディサイズが上限値を超えた場合，Webクライアントに対してステータスコード413のエラーを返します。
なお，チャンク形式でリクエストボディが送信された場合，サーブレット内部では指定された上限値までのデータを読み込みます。上限値を超えるとサーブレットで例外（IOException）が発生しますが，サーブレットの処理は続行されます。リクエストを送信したクライアントには，指定された上限値までのデータを読み込んだ結果に基づいて，アプリケーションが作成したレスポンスを返します。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，プロキシサーバを配置していて，ゲートウェイ機器やプロキシサーバにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

4.3.8　有効なHTTPメソッドの制限によるアクセス制御

ここでは，有効なHTTPメソッドの制限によるアクセス制御について説明します。

インプロセスHTTPサーバでは，HTTPリクエストで有効なHTTPメソッドを制限することによって，無効なHTTPメソッドを含むリクエストの受け付けを拒否します。これによって，サーバ上のリソースへの不正アクセスを防止できます。デフォルトでは，DELETEメソッド，HEADメソッド，GETメソッド，OPTIONSメソッド，POSTメソッド，およびPUTメソッドの使用を許可しています。

HTTPメソッドを制限するには，有効なHTTPメソッドのメソッド名を設定します。このとき，メソッド名の代わりにアスタリスク（*）を指定すると，すべてのメソッドの使用を許可する設定になります。

無効なHTTPメソッドを含むリクエストを受信した場合，Webクライアントに対してステータスコード405のエラーを返します。

なお，静的コンテンツに対してOPTIONSメソッドを含むリクエストを送信した場合，レスポンスに含まれるAllowヘッダには静的コンテンツに対してデフォルトで有効なメソッド（GETメソッド，POSTメソッド，TRACEメソッド，およびOPTIONSメソッド）から，インプロセスHTTPサーバで無効なメソッドを除いたメソッドが返されます。サーブレット/JSPの場合，Webアプリケーションの実装に依存します。

4.3.9　HTTPレスポンスヘッダのカスタマイズ

ここでは，HTTPレスポンスヘッダのカスタマイズについて説明します。

インプロセスHTTPサーバでは，HTTPレスポンスのServerヘッダに自動設定する情報をカスタマイズできます。デフォルトでは，「CosminexusComponentContainer」が自動設定されます。

Serverヘッダに自動設定する値は，RFC2616に規定されている値を使用する必要があります。サーブレット/JSPでServerヘッダを使用する設定にしている場合はその設定が優先されます。

4.3.10　エラーページのカスタマイズ

クライアントから，存在しないリソースへのアクセスなどがあると，インプロセスHTTPサーバはエラーステータスコードとエラーページを返し，クライアントにはインプロセスHTTPサーバが生成したエラーページが表示されます。インプロセスHTTPサーバでは，このエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

インプロセスHTTPサーバによるエラーページのカスタマイズを利用することで，特定のステータスコードに対応するエラーページのカスタマイズや，リクエストURLに対応するエラーページのカスタマイズをWebコンテナ単位にまとめて制御できます。また，次に示すようなWebアプリケーションによるエラーページのカスタマイズが実行できない場合でも，エラーページをカスタマイズできます。

リクエストに対応するコンテキストがない場合（ステータスコード404）

停止処理中のコンテキストでリクエスト処理を実行しようとした場合（ステータスコード503）

インプロセスHTTPサーバがエラーステータスコードを返す場合

インプロセスHTTPサーバが返すエラーステータスコード，およびエラーページのカスタマイズの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

インプロセスHTTPサーバによるエラーページのカスタマイズを実行する場合，javax.servlet.http.HttpServletResponseインタフェースのsendErrorメソッドを使用してレスポンスのステータスコードを設定する必要があります。なお，setStatusメソッドを使用した場合（JSPでsetStatusメソッドを使用した場合など），インプロセスHTTPサーバによるカスタマイズが実行されないことがあります。ただし，sendErrorメソッドを使用しても，Webアプリケーションが次に示すどちらかの条件に該当する場合，インプロセスHTTPサーバによるエラーページのカスタマイズは実行されません。

sendErrorメソッドの実行時に例外が発生した場合

Webアプリケーションでエラーページのカスタマイズの設定をしていて，エラー発生時にその設定によるエラーページの実行が正常終了した場合※

注※

エラーページの実行が正常終了した場合とは，次の条件を満たす場合のことです。

エラーページでcatchされない例外が発生していない。

ステータスコードが400～599以外で終了している。

＜この項の構成＞

(1)　インプロセスHTTPサーバによるエラーページのカスタマイズ

(2)　注意事項

(1)　インプロセスHTTPサーバによるエラーページのカスタマイズ

インプロセスHTTPサーバでは，次に示すエラーページのカスタマイズができます。

ステータスコードに対応するエラーページのカスタマイズ
ステータスコード400番台，500番台に対応するエラーページをカスタマイズできます。
ステータスコードに対応するエラーページをカスタマイズすることによって，ステータスコードに対応するファイルの送信と，ステータスコードに対応するリダイレクトを実行できます。

ステータスコードに対応するファイルの送信
カスタマイズするステータスコードに対して，レスポンスボディとして特定のファイルをクライアントに返すことができます。この場合，レスポンスのContent-Typeヘッダの値を指定します。
なお，リクエスト処理時にファイルの読み込みに失敗した場合，デフォルトのエラーページが使用されます。

ステータスコードに対応するリダイレクト
カスタマイズするステータスコードに対して，特定のURLにリダイレクトすることができます。リダイレクトする場合，レスポンスのステータスコードに302を設定して，LocationヘッダにリダイレクトURLを指定します。
ステータスコードに対応するファイルを送信する場合，リダイレクトは実行できません。

リクエストURLに対応するエラーページのカスタマイズ
リクエストURLを指定して，特定のURLのエラーページをカスタマイズできます。リクエストURLを指定した場合，指定したURLと一致するリクエスト処理でエラーが発生した場合だけ，カスタマイズしたエラーページをクライアントに返します。

(2)　注意事項

インプロセスHTTPサーバによるエラーページのカスタマイズに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，エラーページが正しく表示されない場合があります。

ブラウザの設定によっては，ステータスコードがエラーを示し，レスポンスボディのサイズが小さい場合，レスポンスボディがブラウザ固定のメッセージに置き換えられて表示されることがあるため注意してください。特にエラーページをカスタマイズしなかった場合に表示されるデフォルトのエラーページは，レスポンスボディのサイズが小さいため注意してください。

リダイレクトURLの指定値とリクエストURLの指定値が一致して，リダイレクト後に同じエラーステータスが発生すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

ステータスコードに対応するリダイレクトを実施する場合，エラー発生時にリクエストURLに付加されていたクエリ文字列はリダイレクトURLに付加されません。また，URLの書き換えによるセッション管理をしている場合，エラーの発生したページと同じWebアプリケーション内へのリダイレクトを実施してもセッションを引き継ぐことはできません。

4.3.11　リダイレクトによるリクエストの振り分け

ここでは，リダイレクトによるリクエストの振り分けについて説明します。

インプロセスHTTPサーバでは，HTTPリクエストに含まれるURLパターンによってリクエストを振り分けます。また，振り分けたリクエストに対するレスポンスをカスタマイズしてクライアントに返すこともできます。

URLパターンによるリクエストの振り分けと，レスポンスのカスタマイズの処理について説明します。また，リダイレクトによるリクエストの振り分けの設定の概要についても説明します。

＜この項の構成＞

(1)　URLパターンによるリクエストの振り分け

(2)　レスポンスのカスタマイズ

(3)　注意事項

(1)　URLパターンによるリクエストの振り分け

インプロセスHTTPサーバでは，インプロセスHTTPサーバあてのHTTPリクエストのうち，特定のURLへのリクエストを，指定したWebコンテナに振り分けて処理させることができます。これによって，システム構成の変更などの理由でWebアプリケーションを別なJ2EEサーバに移動する場合に，変更前のURLへのリクエストを，変更後のURLに転送できます。

また，インプロセスHTTPサーバでのリダイレクトによる振り分けでは，特定のWebアプリケーション，およびWebアプリケーション内の特定のサーブレット/JSPに対するリクエストを，一時的にほかのWebサーバにリダイレクトする場合にも使用できます。インプロセスHTTPサーバでは，リクエストされたサーブレット/JSPなどのリソースが実際にあるかどうかに関係なく，リダイレクトを実行します。リダイレクトは，サーブレット/JSPよりも優先されます。そのため，サーブレット/JSPへのリクエストがリダイレクトされるURLと一致した場合，サーブレット/JSPは実行されません。

(2)　レスポンスのカスタマイズ

特定のURLへのリクエストに対して，特定のファイルをレスポンスとして返すようにカスタマイズすることもできます。リダイレクトするURLへのリクエストに対するレスポンスのステータスコードが300～307の場合，レスポンスボディを自動生成してクライアントにレスポンスを返します。また，指定したファイルをレスポンスボディとして使用することもできます。ファイルを指定する場合，レスポンスのContent-Typeヘッダもあわせて指定します。

レスポンスボディが自動生成されるステータスコードの詳細，およびリダイレクトによるリクエストの振り分けの設定（インプロセスHTTPサーバの場合）については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　注意事項

リダイレクトによるリクエストの振り分けに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，正しくブラウザに表示されない場合があります。

リダイレクトURLの指定値とリクエストURLの指定値が一致すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

URLの書き換えによるセッション管理をしている場合，Webアプリケーション内へのリダイレクトを実行してもセッションを引き継ぐことはできません。

4.3.12　ログ・トレースの出力

ここでは，インプロセスHTTPサーバが出力するログ・トレースについて説明します。

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，次の表に示すログおよびトレースを出力します。

表4-7　インプロセスHTTPサーバが出力するログ・トレース

ログ・トレースの種類
説明

アクセスログ
Webクライアントからのリクエスト，およびレスポンスの処理結果を出力します。Webクライアントとの通信の解析に使用します。
アクセスログを解析することによって，Webクライアントからリクエストされたファイルや，インプロセスHTTPサーバの性能情報，およびセッショントラッキング情報などを分析できます。

性能解析トレース
インプロセスHTTPサーバでリクエストを送受信するときの性能解析情報や，障害発生時のトラブルシュートのための情報を出力します。
性能解析トレースは，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて，システム全体のボトルネックの解析などに使用できます。性能解析トレースの詳細については，「17.10　システムの処理性能の解析」を参照してください。

スレッドトレース
保守用のトレースです。

通信トレース
保守用のトレースです。

4.3.13　インプロセスHTTPサーバが返すエラーステータスコード

クライアントからのリクエストのサイズが上限値を超えたり，値が不正だったりした場合，インプロセスHTTPサーバはエラーステータスコードを返します。インプロセスHTPPサーバが返すエラーステータスコードとエラーステータスコードを返す条件を次の表に示します。

表4-8　インプロセスHTTPサーバが返すエラーステータスコードと条件

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
リクエストの状態が次のどれかの場合，エラーステータスコード400が返ります。

リクエストのHTTPのバージョンが1.1で，Hostヘッダがない場合

リクエストのHostヘッダのポート番号が不正な場合

リクエストヘッダのサイズが上限値を超えた場合

リクエストヘッダの数が上限値を超えた場合

リクエストURIが不正な場合

リクエストのContent-Lengthヘッダの値が2147483647より大きい，または0より小さい場合

リクエストのContent-Lengthヘッダの値が数値以外の場合

リクエストのContent-Lengthヘッダが複数指定されている場合

リクエストラインのHTTPのバージョンがサポートされていない場合

403　Forbidden
web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合，エラーステータスコード403が返ります。

405　Method Not Allowed
許可しないHTTPメソッドからアクセスがあった場合，エラーステータスコード405が返ります。

413　Request entity too large
リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります。

414　Request-URI too large
リクエストラインの長さが上限値を超えた場合，エラーステータスコード414が返ります。

500　Internal Server Error
リダイレクト機能によってステータスコード200でファイルを返す際にファイルの読み込みに失敗した場合，エラーステータスコード500が返ります。

501　Not implemented
リクエストのtransfer-encodingヘッダの値が，サポートされていない場合に，エラーステータスコード501が返ります。

503　Service Unavailable
流量制御の上限を超えてリクエスト処理を実行しようとした場合，エラーステータスコード503が返ります。

4.4　セッション管理

セッション管理は，リクエストとWebクライアントを対応づけるための機能です。この機能を使用すると，Webクライアントから，複数のWebページにわたって同じ情報を引き継いだ作業ができるようになります。

セッション管理機能は，次に示す場合にも利用されます。

クラスタリングによる負荷分散機能を使用するときのクライアントの識別

セキュリティ管理機能でのログイン済みクライアントの識別

セッション管理の方式として，Servlet仕様では，Cookieを使用する方法とURL書き換えを使用する方法が明記されています。CosminexusのWebコンテナでも，これらの方式によってセッションを管理します。ただし，Servlet仕様では，具体的な管理方式を明記していない部分があります。このため，この節では，Servlet仕様で明記されていないセッションの管理方式について，Cosminexusでどのように管理するかを説明します。

また，Cosminexusの独自の機能である，次の2種類のセッション管理機能についても，この節で説明します。

HTTPSessionオブジェクトの上限値の設定

セッションIDおよびCookieへのサーバIDの付加

ポイント

HTTPSessionオブジェクトの上限値の設定，およびセッションIDへのサーバIDの付加は，Cosminexusのセッションフェイルオーバ機能を使用する場合に前提になる機能です。セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

＜この節の構成＞

4.4.1　セッション情報を管理するオブジェクト

4.4.2　セッションIDの形式

4.4.3　セッションの管理方法

4.4.4　HttpSessionオブジェクト数の上限値の設定

4.4.5　セッションIDおよびCookieへのサーバIDの付加

4.4.1　セッション情報を管理するオブジェクト

ここでは，セッション情報の管理に使用するHttpSessionオブジェクトについて説明します。

＜この項の構成＞

(1)　HttpSessionオブジェクトの管理方法

(2)　HttpSessionオブジェクトの保存期間

(1)　HttpSessionオブジェクトの管理方法

セッション情報は，Servlet APIで規定されているHttpSessionオブジェクトによって管理される情報です。

セッション情報の管理が開始されるのは，次の時点です。

サーブレットの場合は，HttpSessionオブジェクトを参照した時点。

JSPの場合は，ページへの参照が発生した時点（ただし，これはデフォルトの場合です）。

セッション情報の管理が開始されたあとで，同一のWebアプリケーション内のサーブレットに対して，同じブラウザプロセスからリクエストが送信されると，管理されている内容のHttpSessionオブジェクトがサーブレットに渡されるようになります。

ただし，実際にサーブレットに渡されるHttpSessionオブジェクトのインスタンスは，リクエスト単位に異なります。つまり，同一セッションに属する一連のリクエストでは，内容が同じでインスタンスが異なるHttpSessionオブジェクトが渡される場合があります。

このため，HttpSessionオブジェクトに対する操作では，次の点に留意してください。

HttpSessionオブジェクトにアクセスする場合，リクエスト単位にインスタンスを取得する必要があります。

HttpSessionオブジェクトへの参照を，複数のリクエストにわたってキャッシングしないでください。

HttpSessionオブジェクトに対して，javaのsynchronizedキーワードでロックを掛けても意味はありませんので，ロックは掛けないでください。

(2)　HttpSessionオブジェクトの保存期間

HttpSessionオブジェクトは単一のJavaVM内にだけ保存されています。このため，サーブレットエンジンとして動作しているJavaVMプロセス（J2EEサーバ）に障害が発生した場合には，HttpSessionオブジェクトが保持しているセッション情報は失われます。

また，セッション情報は，正常・異常に関係なくJ2EEサーバが終了すると失われます。

J2EEサーバが終了したあとにもセッション情報を保持しておきたい場合は，Cosminexusの機能であるセッションフェイルオーバ機能を使用してください。セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

4.4.2　セッションIDの形式

ここでは，セッション情報の識別に使用するセッションIDの形式について説明します。HttpSessionオブジェクトは，セッションIDによって識別されます。

セッションIDの形式は，次の機能を使用しているかどうかで異なります。

リダイレクタによる負荷分散機能

セッションIDへのサーバIDの付加機能

セッションIDは，J2EEサーバ内で一意であることが保証されています。ただし，複数のJ2EEサーバにわたって一意の値にする必要がある場合には，セッションIDにワーカ名またはサーバIDを追加して，複数のJ2EEサーバにわたって一意になるように設定する必要があります。

使用している機能ごとのセッションIDの形式を，次の図に示します。

図4-10　セッションIDの形式

それぞれの場合について説明します。

リダイレクタによる負荷分散機能とサーバID付加機能のどちらも使用していない場合
セッションIDは，32文字の英数字になります。この英数字は，一つのJ2EEサーバ内で一意な値になります。

リダイレクタによる負荷分散機能を使用している場合
セッションIDは，32文字の英数字，「.」（ピリオド），およびワーカ名で構成されます。ワーカ名には，サーバごとに一意の名称を設定しておく必要があります。
リダイレクタによる負荷分散機能については，「4.23　Webサーバ（リダイレクタ）によるリクエストの振り分け」のロードバランサを使用する場合の説明を参照してください。

サーバID付加機能を使用している場合（リダイレクタによる負荷分散機能を使用していないとき）
セッションIDは，32文字の英数字およびサーバIDで構成されます。サーバIDには，サーバごとに一意の値を設定しておく必要があります。
サーバID付加機能については，「4.4.5　セッションIDおよびCookieへのサーバIDの付加」を参照してください。
なお，リダイレクタによる負荷分散機能を使用している場合，サーバIDは付加されません。

4.4.3　セッションの管理方法

ここでは，セッションの管理方法について説明します。

Webコンテナでのセッションの管理方法には，HTTP Cookieを使用する方法と，URL書き換えを使用する方法の2種類があります。

Webコンテナは，セッションがどの方法で管理されているかを，セッションIDが何から取得できたかによって判別します。HTTP CookieからセッションIDを取得した場合は，HTTP Cookieによってセッションを管理していると判別します。URLのパスパラメタから取得できた場合は，URL書き換えによってセッションを管理していると判別します。これらの判別は，リクエストごとに実行されます。

次に，セッションの管理方法ごとのセッションIDの管理のされ方について説明します。

＜この項の構成＞

(1)　セッションの管理にHTTP Cookieを使用する場合

(2)　セッションの管理にURL書き換えを使用する場合

(3)　URL書き換えをする場合に使用するAPIと注意事項

(4)　URL書き換えを使用する場合の注意事項

(1)　セッションの管理にHTTP Cookieを使用する場合

セッションIDは，HTTP Cookieとして管理されます。

セッションIDを示すHTTP Cookieの名称は，「JSESSIONID」です。この名称は，Servlet仕様で決められているため，変更できません。

(2)　セッションの管理にURL書き換えを使用する場合

セッションIDは，URLのパスパラメタとして管理されます。

セッションIDを示すURLのパスパラメタの名称は，「jsessionid」です。この名称は，Servlet仕様で決められているため，変更できません。セッションIDは，WebコンテナによってURLが書き換えられるときに，URLのパスの最後に，「;jsessionid=セッションID」の形式で付加されます。

URLのパスは，階層構造を持っている，リソースを識別するための値です。URLのパスには，クエリやフラグメントは含まれません。このため，これらの要素がURLに含まれている場合，セッションIDは，クエリまたはフラグメントの直前に付加されます。また，URLにセッションID以外のパスパラメタが含まれている場合，セッションIDを示すパスパラメタは，URLに含まれるパスパラメタの最後に付加されます。

ポイント

セッションIDをURLのパスパラメタに追加する場合，URLの文字数が増加します。

増加する文字数を次の表に示します。

表4-9　URL書き換えによって増加するURLの文字数

機能の使用状況 | 増加するURLの文字数（単位：文字数）
リダイレクタによる負荷分散機能またはサーバID付加機能を使用していない場合 | 44※
リダイレクタによる負荷分散機能を使用している場合 | 44※ + 1（ピリオドの文字数）+ワーカ名の文字数
サーバID付加機能を使用している場合（リダイレクタによる負荷分散機能を使用していないとき） | 44※ + サーバIDの文字数

注※

「;jsessionid=」の12文字とセッションIDの32文字の合計です。

(3)　URL書き換えをする場合に使用するAPIと注意事項

URL書き換えは，J2EEアプリケーション内でURL書き換えを実行するServlet APIを呼び出したときに実行されます。

URL書き換えを実行するServlet APIとは，次に示すjavax.servlet.http.HttpServletResponseインタフェースのメソッドです。

encodeURL(java.lang.String url)メソッド

encodeRedirectURL(java.lang.String url)メソッド

encodeUrl(java.lang.String url)メソッド

encodeRedirectUrl(java.lang.String url)メソッド

これらのメソッドの詳細については，Servlet仕様を参照してください。なお，encodeUrl(java.lang.String url)メソッド，およびencodeRedirectUrl(java.lang.String url)メソッドは，Servlet 2.1以降，非推奨のAPIとなっています。このため，これら以外のメソッドを使用することをお勧めします。

ここでは，Servlet仕様で明記されていないAPIの動作として，URL書き換えを実行するServlet APIの戻り値についての，Cosminexusでの動作について説明します。

HTTPセッションは，リクエスト処理中のWebアプリケーション内だけで有効です。このため，Servlet APIの引数に指定されたURLが，リクエスト処理中のWebアプリケーション内を指しているURLの場合にだけ，URL書き換えをします。引数のURLごとに，リクエスト処理中のWebアプリケーション内を指していると判定する条件を次の表に示します。

表4-10　引数のURLごとに，リクエスト処理中のWebアプリケーション内を指していると判定する条件

引数のURLの種類
判定条件

相対URL
（（例）/ex/a.html）
次の条件を満たす場合にだけ，Webアプリケーション内であると判定されます。

引数のURLの正規化したパスが，リクエスト処理中のWebアプリケーションのコンテキストルート名を含んでいる。※1

絶対URL
（（例）http://host1/ex/）
次のすべての条件を満たす場合にだけ，Webアプリケーション内であると判定されます。

引数のURLのスキームが「http」，または「https」である。※2

引数のURLとリクエストのURLが同一のスキームの場合，ポート番号が一致する。

引数のURLのホスト名が，リクエストのホスト名と一致する。※1※3

引数のURLの正規化したパスが，リクエスト処理中のWebアプリケーションのコンテキストルート名を含んでいる。※1

注※1　名称を比較する場合に，大文字，小文字を区別します。

注※2　名称を比較する場合に，大文字，小文字を区別しません。

注※3　リクエストのホスト名は，リクエストのHostヘッダのホスト名部分とし，ホスト名の名前解決しないで，文字列を比較します。なお，リクエストのホスト名には，javax.servlet.ServletRequest.getServerNameメソッドの戻り値を使用します。なお，次の場合は，同じホストであっても異なるホストと判定します。

引数のURLがホスト名の指定で，リクエストのURLがIPアドレスの場合

引数のURLがIPアドレスの指定で，リクエストのURLがホスト名の場合

また，URL書き換えを実行するServlet APIの引数に，URL以外の文字列を指定した場合の戻り値について説明します。また，URLの先頭にクエリまたはフラグメントを指定した場合についても，あわせて説明します。

URL書き換えを実行するServlet APIの引数ごとの戻り値を次の表に示します。

表4-11　URL書き換えを実行するServlet APIの引数ごとの戻り値

項番
条件
戻り値または発生する例外

HTTPセッション
引数

1
－
null
nullが返されます。

2
－
URLとして不正なフォーマット
java.lang.IllegalArgumentException例外が発生します。

3

リクエスト処理中に新規作成したHTTPセッションがある。

URL書き換えでセッションIDが通知されている。

空文字列
HTTPリクエストのURLのパスおよびクエリに対して，セッションIDを付加した値が返されます。※1

4
クエリから開始されているURL（先頭文字が「?」の場合）
HTTPリクエストのURLのパスに，セッションIDおよび引数に指定した値が付加された値が返されます。※1

5
フラグメントから開始されているURL（先頭文字が「#」の場合）
引数に指定した値が返されます。※2

6
現在のHTTPセッションのセッションIDを表すパスパラメタが含まれているURL
引数に指定した値が返されます。

7
リクエスト処理中のWebアプリケーション内と判定されるURL
引数にセッションIDを付加した値が返されます。

8
上記の条件以外
引数に指定した値が返されます。

（凡例）－：該当しない

注

この表で示す項番は，条件の優先度を示します。項番の数字が小さいほど，条件の優先度は高くなります。

注※1

引数のURLにパスが含まれないため，引数のURLにパスパラメタを直接付加できません。引数が空文字列やクエリから始まるURLは，リクエストのURLのリソースを指しているURLであるため，リクエストのURLにパスパラメタを付加した値を使用して，URL書き換えをします。

注※2

フラグメントだけのURLは，現在のリソース内の特定の個所を示すURLです。Webブラウザでは，通常このURLを，表示されているコンテンツ内の移動を示すものとして扱います。このとき，サーバにリクエストは送信しません。なお，これは，RFC3986に従った動作です。

次に，URL書き換えを使用してセッションIDを付加したURLの例について説明します。なお，ここで説明する例は，次の前提条件に従っています。

前提条件

Servlet APIは，HTTPセッションの生成後に実行されたものとします。

HTTPリクエストのURLは，「http://host1/gyoumu1/app1/index.jsp?type=1」です。

コンテキストルート名は，「/gyoumu1」です。

URL書き換えに使用するServlet APIの引数の指定値と書き換え後の戻り値（URL）の対応の例を次の表に示します。

表4-12　URL書き換えに使用するServlet APIの引数の指定値と書き換え後の戻り値（URL）の対応の例

Servlet APIの引数 | 戻り値
b.html | b.html;jsessionid=AAAAA111112222233333444445555566svr0
../b.html | ../b.html;jsessionid=AAAAA111112222233333444445555566svr0
../../b.html | ../../b.html
http://host2/ | http://host2
https://host1/gyoumu1/ | https://host1/gyoumu1/;jsessionid=AAAAA111112222233333444445555566svr0
""(空文字列) | "/gyoumu1/app1/index.jsp;jsessionid=AAAAA111112222233333444445555566svr0?type=1"
"?mode=2" | "/gyoumu1/app1/index.jsp;jsessionid=AAAAA111112222233333444445555566svr0?mode=2"
"#aaa" | "#aaa"

(4)　URL書き換えを使用する場合の注意事項

URL書き換えを使用する場合の注意事項について説明します。

●静的コンテンツからの画面遷移

静的コンテンツ（HTMLファイルなど）から遷移した場合，URL書き換えによって管理されているセッションは維持されません。

URL書き換えを使用してセッションを管理する場合は，常にサーブレットまたはJSPを使用して画面を遷移するように実装してください。また，サーブレットまたはJSP内で，Servlet APIによってURLを書き換えて，セッションIDを追加する処理を実装してください。

●Webアプリケーションで取得したリクエストURL

HTTPリクエストのURLに，URL書き換えによって追加されたセッションIDを示すパスパラメタが含まれる場合であっても，次のメソッドによって取得したURLには，セッションIDを示すパスパラメタは含まれません。

インタフェース

javax.servlet.http.HttpServletRequestインタフェース

メソッド

getRequestURI()メソッド

getRequestURL()メソッド

4.4.4　HttpSessionオブジェクト数の上限値の設定

Cosminexusでは，有効となるHttpSessionオブジェクト数に，上限値を設定できます。

HTTPSessionオブジェクトの上限値は，J2EEアプリケーションに含まれるWebアプリケーションの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，セッションフェイルオーバ機能を使用する場合は，HttpSessionオブジェクト数の上限値の指定は必須となります。セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

注意

グローバルセッション情報のサイズ見積もり機能を有効にする場合，セッションフェイルオーバ機能の前提条件であるHttpSessionオブジェクト数の上限値の指定は不要です。グローバルセッション情報のサイズ見積もり機能については，「12.2.10　グローバルセッション情報のサイズの見積もり」を参照してください。

＜この項の構成＞

(1)　上限値を設定する対象になるHttpSessionオブジェクト

(2)　上限値を超えた場合の動作

(1)　上限値を設定する対象になるHttpSessionオブジェクト

上限値を設定する対象になるのは，有効なHttpSessionオブジェクトです。

有効なHttpSessionオブジェクトとは，javax.servlet.http.HttpServletRequestクラスのgetSessionメソッドで取得したHttpSessionオブジェクトのうち，次の二つの条件を満たすオブジェクトを指します。

タイムアウトしていないオブジェクト

invalidateメソッドが呼ばれていないオブジェクト

(2)　上限値を超えた場合の動作

HttpSessionオブジェクト数の上限値を設定しているときに，HttpSessionオブジェクト数が上限値に達すると，javax.servlet.http.HttpServletRequestクラスのgetSessionメソッドで，java.lang.IllegalStateExceptionがスローされます。

WebコンテナでのHttpSessionオブジェクト生成は，次のタイミングで実行されます。

JSP実行時
pageディレクティブのsession属性に「true」を指定した場合，またはsession属性を省略している場合に，JSPを実行したときを指します。

FORM認証を必要とするURLへのアクセス時

生成されたHttpSessionオブジェクトの数が設定した上限値を超えると，次のように動作します。

JSP実行時に上限値を超えた場合
JSPのユーザコードが実行される前に，java.lang.IllegalStateExceptionがスローされます。

FORM認証を必要とするURLへのアクセス時に上限値を超えた場合
ログイン用ページにリクエストが転送される前に，java.lang.IllegalStateExceptionがスローされます。

4.4.5　セッションIDおよびCookieへのサーバIDの付加

Cosminexusでは，HttpSessionのセッションIDやCookieに，サーバIDを付けることができます。これを，サーバID付加機能といいます。サーバIDは，Webコンテナごとに異なる値を設定します。

セッションIDおよびCookieへのサーバIDの付加についての設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，セッションフェイルオーバ機能を使用する場合は，セッションIDへのサーバIDの付加は必須となります。セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

＜この項の構成＞

(1)　HttpSessionのセッションIDへのサーバID付加

(2)　CookieへのサーバID付加

(1)　HttpSessionのセッションIDへのサーバID付加

セッションIDは，通常，同一のWebコンテナ内では一意となります。しかし，負荷分散機を使用して複数のWebコンテナで構成するシステムの場合，システム全体ではセッションIDが一意にならないおそれがあります。HttpSessionのセッションIDへのサーバID付加機能を使用すると，HttpSessionのセッションIDに，Webコンテナごとに異なるサーバIDが付加されます。これによって，セッションIDをシステム内で一意にできます。

参考

Webサーバとの連携時に，リダイレクタの設定でラウンドロビンでリクエストの振り分けをする場合，HttpSessionのセッションIDを付加するかどうかの設定にかかわらず，セッションIDには，ワーカ名が付加されます。サーバIDは付加されません。

(2)　CookieへのサーバID付加

同一のセッションのリクエストを，同一のWebコンテナに転送するには，負荷分散機のCookieによってリクエスト転送先を指定する機能と，CookieへのサーバID付加機能を使用して実現します。

CookieへのサーバID付加機能では，CookieにWebコンテナごとに異なるサーバIDが付加されます。HTTPレスポンスには，サーバIDが付加されたCookieを付けることができるので，同一のセッションのリクエストを，同一のWebコンテナに転送できます。なお，サーバIDが付いたCookieは，HttpSessionを生成したリクエストのレスポンスに付加されます。

4.5　文字コード変換

HTTPは，主にWebサーバからブラウザへデータをダウンロードするために用いられるプロトコルですが，HTMLのフォームの場合などではデータのアップロードにも使われます。

ダウンロードするコンテンツの文字コードをWebサーバからブラウザに伝えるための規格は，Servlet APIでも明確に規定されています。しかし，過去のServlet API（Servlet API 2.2以前）では，HTTPクエリ文字列とHTTPリクエストボディの文字コードの扱いが明確ではなかったため，ベンダによって扱いが異なっていました。

Servlet API 2.3からは，Servlet APIを通してHTTPクエリ文字列やHTTPリクエストボディを参照するときに，文字コードを指定できるようになりました（ただし，エンコードタイプがmultipart/form-dataのHTTPリクエストボディを除きます）。これらのデータは，指定された文字コードのデータと見なされてJavaの内部表現であるUnicodeに変換されてからアプリケーションに渡されます。

アプリケーション開発時に使用する文字コードについては，「付録G　アプリケーションの開発で使用する文字コード」を参照してください。

4.6　デフォルトの文字エンコーディング設定

リクエストのデコードやレスポンスのエンコードで使用する文字エンコーディングは，Servlet仕様に準拠した設定をする場合，サーブレットやJSPファイルごとに設定を記述します。Cosminexusでは，Servlet仕様に準拠した設定のほかに，次の二つの方法でデフォルトの文字エンコーディングを設定できます。

J2EEサーバごとに使用する文字エンコーディングを設定する

Webアプリケーションごとに使用する文字エンコーディングを設定する

これによって，Webアプリケーション開発時に，サーブレットやJSPファイルに記述する文字エンコーディングの設定を省略できます。また，J2EEサーバまたはWebアプリケーションごとに，容易に文字エンコーディングを統一できます。

省略できるServlet仕様での文字エンコーディング設定を，次の図に示します。

図4-11　省略できるServlet仕様での文字エンコーディングの設定

この節では，デフォルトの文字エンコーディング設定について説明します。

＜この節の構成＞

4.6.1　デフォルトの文字エンコーディングの設定単位

4.6.2　設定できる文字エンコーディング

4.6.3　デフォルトの文字エンコーディングの適用個所と適用条件

4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用

4.6.5　デフォルトの文字エンコーディング適用時の注意事項

4.6.6　Servlet仕様での文字エンコーディング設定

4.6.1　デフォルトの文字エンコーディングの設定単位

Cosminexusでは，リクエストのデコード，レスポンスのエンコード，およびJSPファイルで使用するデフォルトの文字エンコーディングを，J2EEサーバ単位，Webアプリケーション単位で設定できます。

ここでは，デフォルトの文字エンコーディングの設定について説明します。なお，デフォルトの文字エンコーディングは，JSP事前コンパイル実行時に適用することもできます。JSP事前コンパイル実行時のデフォルトの文字エンコーディング設定については，「4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

＜この項の構成＞

(1)　J2EEサーバ単位の設定

(2)　Webアプリケーション単位の設定

(3)　複数の範囲で文字エンコーディングを設定している場合の動作

(1)　J2EEサーバ単位の設定

J2EEサーバごとにデフォルトの文字エンコーディングを設定します。J2EEサーバごとにデフォルトの文字エンコーディングを設定すると，J2EEサーバにデプロイされているすべてのJ2EEアプリケーションのサーブレットおよびJSPファイルに対して，設定した文字エンコーディングを適用します。これによって，J2EEサーバ単位で，文字エンコーディングを統一できます。

J2EEサーバ単位の場合，デフォルトの文字エンコーディングは，J2EEサーバの動作設定をカスタマイズする際に設定します。設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバの動作設定のカスタマイズに関する説明を参照してください。

(2)　Webアプリケーション単位の設定

WARファイルごとに，デフォルトの文字エンコーディングを設定します。WARファイルごとにデフォルトの文字エンコーディングを設定すると，WARファイルに含まれるサーブレットおよびJSPファイルに対して，設定した文字エンコーディングを適用します。これによって，Webアプリケーション単位で，文字エンコーディングを統一できます。

Webアプリケーション単位での設定の場合，デフォルトの文字エンコーディングは，J2EEアプリケーションのプロパティを定義する際に設定します。設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEアプリケーションのプロパティ定義で設定できることに関する説明を参照してください。

(3)　複数の範囲で文字エンコーディングを設定している場合の動作

文字エンコーディングの設定は，J2EEサーバ単位またはWebアプリケーション単位での設定のほかに，Servlet仕様での文字エンコーディングの設定もできます。Servlet仕様での文字エンコーディング設定の場合，設定範囲は，サーブレットまたはJSPファイル単位になります。

それぞれの設定範囲を次の図に示します。

図4-12　文字エンコーディングの設定範囲

デフォルトの文字エンコーディングは複数範囲で設定することもできます。複数の範囲で設定されている場合，次の順序で適用されます。

サーブレット/JSPファイル単位での設定（Servlet仕様）

Webアプリケーション単位での設定

J2EEサーバ単位での設定

例えば，図4-12で，サーブレット2とJ2EEサーバに文字エンコーディングが設定されているとします。この場合，J2EEサーバ内のアプリケーション全体に，J2EEサーバ単位で設定したデフォルトの文字エンコーディングが適用されますが，サーブレット2だけは，サーブレット内に設定した文字エンコーディングが適用されます。

次の表に，文字エンコーディング設定の組み合わせごとに，有効になる設定を示します。

表4-13　文字エンコーディング設定の組み合わせと有効になる設定

設定の組み合わせ | 有効になる設定
サーブレット/JSPファイルでの設定（Servlet仕様） | Webアプリケーション単位での設定 | J2EEサーバ単位での設定
○ | × | × | サーブレット/JSPファイルでの設定
○ | ○ | ×
○ | × | ○
○ | ○ | ○
× | ○ | × | Webアプリケーション単位での設定
× | ○ | ○
× | × | ○ | J2EEサーバ単位での設定
× | × | × | Servlet仕様で規定されている文字エンコーディング

（凡例）○：設定あり　×：設定なし

注

文字エンコーディングの設定がない場合は，Servlet仕様で規定されている文字エンコーディングが適用されます。詳細については，「4.6.6(2)　Servlet仕様で規定されている文字エンコーディング」を参照してください。

4.6.2　設定できる文字エンコーディング

デフォルトの文字エンコーディングとして設定できる文字は，JavaVMがサポートしている文字エンコーディングとなります。JavaVMがサポートしている文字エンコーディングについては，JDKのドキュメントのサポートされているエンコーディングに関する説明を参照してください。

また，指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名になります。

注意

J2EEアプリケーションの開発環境と運用環境のOSが異なる場合で，J2EEアプリケーションを，実行時情報を含むEARファイルでエクスポートおよびインポートするときは，開発環境のOSと運用環境のOSの両方でサポートしている文字エンコーディングを設定してください。開発環境で設定した文字エンコーディングが運用環境でサポートされていない場合は，アプリケーション開始時に例外が発生することがあります。

また，設定したデフォルトの文字エンコーディングは，JavaVMでサポートしている文字エンコーディングかどうか検証されます。検証のタイミングは，デフォルトの文字エンコーディングの設定方法によって異なります。文字エンコーディングの検証のタイミングについて，次の表に示します。

表4-14　文字エンコーディングの検証のタイミング

検証のタイミング | サポートされていない文字エンコーディングが設定されていた場合の動作
J2EEサーバ開始時 | 警告メッセージを出力し，J2EEサーバ開始処理を続行します。なお，設定した文字エンコーディングは無視されます。
サーバ管理コマンド（cjsetappprop）実行時 | エラーメッセージを出力し，サーバ管理コマンドの処理を中止します。
cjjspcコマンド実行時※ | エラーメッセージを出力し，コマンドの処理を終了します。

注※

cjjspcコマンドでのJSP事前コンパイル実行時に，デフォルトの文字エンコーディング設定をするときの検証のタイミングです。なお，JSP事前コンパイルでのデフォルトの文字エンコーディングの適用については，「4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

4.6.3　デフォルトの文字エンコーディングの適用個所と適用条件

ここでは，J2EEサーバ単位，またはWebアプリケーション単位で設定したデフォルトの文字エンコーディングの適用個所と，適用時の条件について説明します。

＜この項の構成＞

(1)　適用個所

(2)　適用条件

(1)　適用個所

J2EEサーバ単位またはWebアプリケーション単位に設定したデフォルトの文字エンコーディングは，次の個所に適用されます。

リクエストのデコード
リクエストボディおよびクエリのデコードに使用する，デフォルトの文字エンコーディングに適用されます。

レスポンスのエンコード
レスポンスボディおよびレスポンスのContent-Typeヘッダのエンコードに使用する，デフォルトの文字エンコーディングに適用されます。

JSPファイル
JSPファイルのデフォルトの文字エンコーディングに適用されます。

(2)　適用条件

デフォルトの文字エンコーディングは，Servlet仕様での文字エンコーディングが設定されていない場合に適用されます。Servlet仕様での文字エンコーディングの設定方法については，「4.6.6　Servlet仕様での文字エンコーディング設定」を参照してください。

また，リクエストのデコードおよびレスポンスのエンコードで使用する文字エンコーディングについては，さらに次に示す適用条件があります。

(a)　リクエストでの適用条件

リクエストのデコードで使用する文字エンコーディングの場合，次に示す適用条件があります。

クライアントから送信されたリクエストのHTTPリクエストヘッダに，charsetパラメタを含む，Content-Typeヘッダが含まれていない。

さらに，リクエストボディおよびクエリには，次に示す適用条件があります。

●リクエストボディ

サーブレットの場合

リクエストのPOSTデータを，次のどちらかの方法で読み込んでいる場合に適用されます。

javax.servlet.ServletRequestのgetReaderメソッドを使用して取得したBufferedReaderで読み込む。

リクエストのパラメタとして読み込む。

リクエストのパラメタとして読み込む場合，javax.servlet.ServletRequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用します。

JSPファイルの場合

リクエストのPOSTデータを，次のどちらかの方法で読み込んでいる場合に適用されます。

暗黙オブジェクトrequestのgetReaderメソッドを使用して取得したBufferedReaderで読み込む。

リクエストのパラメタとして読み込む。

リクエストのパラメタとして読み込む場合，暗黙オブジェクトrequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用，またはExpression Languageで暗黙オブジェクトparam，paramValuesを使用します。

●クエリ

サーブレットの場合

javax.servlet.ServletRequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用する方法で，クエリをリクエストのパラメタとして読み込んでいる場合に，適用されます。

JSPファイルの場合

次のどちらかの方法で，クエリをリクエストのパラメタとして読み込んでいる場合に適用されます。

暗黙オブジェクトrequestのgetParameterメソッド，getParameterMapメソッド，getParameterNameメソッド，getParameterValuesメソッドを使用して読み込む。

Expression Languageで暗黙オブジェクトparam，paramValuesを使用して読み込む。

(b)　レスポンスでの適用条件

レスポンスのエンコードで使用する文字エンコーディングの適用条件を，レスポンスボディとレスポンスのContent-Typeヘッダの文字エンコーディング名に分けて説明します。

●レスポンスボディ

サーブレットの場合

javax.servlet.ServletResponseのgetWriterメソッドで取得したPrintWriterでレスポンスデータを作成している場合に適用されます。

JSPファイルの場合

暗黙オブジェクトresponseのgetOutputStream()メソッドによってServletOutputStreamオブジェクトを取得しないで，レスポンスを出力している場合に適用されます。※

注※

ServletOutputStreamオブジェクトを取得した場合，JSP本文のテキストや，暗黙オブジェクトoutへの出力などのServletOutputStreamオブジェクトを使用しない出力は，すべて実行時にエラーとなります。このため，レスポンスとして出力することはできません。

●レスポンスのContent-Typeヘッダの文字エンコーディング名

サーブレットの場合

レスポンスのコンテンツ形式に「text/」で始まるMIMEタイプを設定し，charsetは設定していない場合に適用されます。

JSPファイルの場合

次のどちらかの場合に適用されます。

レスポンスのコンテンツ形式を設定していない。

「text/」で始まるMIMEタイプを設定し，charsetは設定していない。

静的コンテンツの場合

次の条件を満たした場合に適用されます。

静的コンテンツの拡張子が，デフォルトエンコーディング設定機能の対象として設定された拡張子である。

拡張子が「text/」で始まるMIMEタイプに設定されている。

静的コンテンツを出力するより前に，サーブレット，JSP，フィルタなどでレスポンスに対して文字エンコーディングを設定しない。

参考

コンテンツ形式とは，コンテンツのMIMEタイプを指します。コンテンツ形式には，文字エンコーディングを含めることができます。次に，サーブレットおよびJSPファイルでのコンテンツ形式の設定例を示します。

サーブレットの場合
javax.servlet.ServletResponseのsetContentTypeメソッドを使用します。
設定例：response.setContentType("text/html");

JSPファイルの場合
PageディレクティブのcontentType属性を設定します。
設定例：<%@ page contentType="text/plain" %>

また，デフォルトの文字エンコーディング設定が適用されるMIMEタイプの例と，適用されないMIMEタイプの例を示します。

適用されるMIMEタイプの例：「text/plain」，「text/html」

適用されないMIMEタイプの例：「image/gif」，「text/html;charset=UTF-8」

4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用

JSPファイルのデフォルトの文字エンコーディングについては，JSP事前コンパイル実行時に適用することもできます。JSP事前コンパイル時に適用させる場合，デフォルトの文字エンコーディング設定は，JSP事前コンパイルの方法によって異なります。JSP事前コンパイルの方法には，次の2種類があります。

アプリケーション開発時に実施するJSP事前コンパイル

J2EEアプリケーション開始時に実施するJSP事前コンパイル

JSP事前コンパイルの種類ごとに，デフォルトの文字エンコーディング設定について説明します。JSP事前コンパイル機能の詳細については，「4.7　JSPの事前コンパイルとコンパイル結果の保持」を参照してください。

なお，設定できる文字エンコーディングについては，「4.6.2　設定できる文字エンコーディング」を，設定したデフォルトの文字エンコーディングの適用個所および適用条件については，「4.6.3　デフォルトの文字エンコーディングの適用個所と適用条件」を参照してください。

＜この項の構成＞

(1)　アプリケーション開発時に実施するJSP事前コンパイル（cjjspcコマンド）

(2)　J2EEアプリケーション開始時に実施するJSP事前コンパイル（cjstartappコマンド）

(1)　アプリケーション開発時に実施するJSP事前コンパイル（cjjspcコマンド）

cjjspcコマンドでJSP事前コンパイルを実施する際，JSPファイルまたはタグファイルに，デフォルトの文字エンコーディングを適用できます。cjjspcコマンドの場合，デフォルトの文字エンコーディングは，cjjspcコマンドの引数に指定します。これによって，cjjspcコマンド実行時に，実行対象となるJSPファイルに対して，コマンドに指定したデフォルトの文字エンコーディングが適用されます。ただし，JSPファイルやタグファイルにServlet仕様での文字エンコーディング指定がある場合は，設定は適用されないので注意してください。

設定の詳細については，マニュアル「Cosminexus　アプリケーション開発ガイド」のcjjspcコマンドを使用したJSPの事前コンパイルに関する説明を参照してください。

注意

cjjspcコマンドの場合，リクエストのデコードおよびレスポンスのエンコードに使用するデフォルトの文字エンコーディングは，JSPファイルのコンパイル時に適用されないため，cjjspcコマンドでは設定できません。

(2)　J2EEアプリケーション開始時に実施するJSP事前コンパイル（cjstartappコマンド）

cjstartappコマンドでJ2EEアプリケーション開始とあわせてJSP事前コンパイルを実施する際，JSPファイルまたはタグファイルに，デフォルトの文字エンコーディングを適用できます。デフォルトの文字エンコーディングの設定方法は，J2EEサーバ単位，Webアプリケーション単位の場合と同様です。J2EEサーバ単位の場合は，J2EEサーバの動作設定時にJ2EEサーバごとに設定します。また，Webアプリケーション単位の場合は，Webアプリケーション開発時にWARファイルごとに設定します。cjstartappコマンドを実行すると，設定したデフォルトの文字エンコーディングが適用されます。

J2EEサーバ単位の設定およびWebアプリケーション単位での設定については，「4.6.1　デフォルトの文字エンコーディングの設定単位」を参照してください。また，設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEアプリケーションのプロパティ定義で設定できることに関する説明を参照してください。

4.6.5　デフォルトの文字エンコーディング適用時の注意事項

デフォルトの文字エンコーディングの適用については，次の点に注意してください。

＜この項の構成＞

(1)　レスポンスへのデフォルトの文字エンコーディングの設定の可否について

(2)　getCharacterEncodingメソッドに適用される文字エンコーディング

(3)　XML宣言内の文字エンコーディング

(4)　JSPファイルへの文字エンコーディングの適用

(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定

(6)　デフォルトエラーページの文字エンコーディングについて

(1)　レスポンスへのデフォルトの文字エンコーディングの設定の可否について

次の場合は，レスポンスへのデフォルトの文字エンコーディングの設定は有効になりません。

静的コンテンツの拡張子が，webserver.static_content.encoding.extensionパラメタ※1に指定した拡張子以外の場合

Servlet仕様で規定されたエラーページの静的コンテンツに対して，レスポンスへのデフォルトの文字エンコーディングを設定しない場合※2

注※1　デフォルトの文字エンコーディングを適用させる静的コンテンツの拡張子を指定するためのパラメタです。

注※2　次のどちらかの条件のあとに出力された静的コンテンツの場合は，レスポンスへのデフォルトの文字エンコーディングの設定が有効になります。

レスポンスに対して文字エンコーディングを設定しない場合で，サーブレット，JSP，フィルタなどで，javax.servlet.ServletResponseクラスのgetWriterメソッドによってjava.io.PrintWriterオブジェクトが取得されるとき。

setAttributeメソッドが実行されても，リクエストオブジェクトがラップされる場合で，そのリクエストオブジェクトが，setAttributeメソッドを呼び出さないリクエストラッパでラップされるとき。

なお，HTTPレスポンス圧縮フィルタを使用している場合は，レスポンスへのデフォルトの文字エンコーディングの設定は有効になりません。

(2)　getCharacterEncodingメソッドに適用される文字エンコーディング

Servlet仕様で文字エンコーディングを設定していない場合，次に示すServlet APIのメソッドには，J2EEサーバ単位またはWebアプリケーション単位で設定したデフォルトの文字エンコーディングが適用されます。

javax.servlet.ServletRequestのgetCharacterEncodingメソッド（リクエストの場合）

javax.servlet.ServletResponseのgetCharacterEncodingメソッド（レスポンスの場合）

ただし，setCharacterEncodingメソッドで文字エンコーディングを変更しているときは，setCharacterEncodingメソッドで変更した文字エンコーディングが取得されます。

また，レスポンスの場合，javax.servlet.ServletResponseのresetメソッドを使用してレスポンスデータを初期化したときは，getCharacterEncodingメソッドで取得できる文字エンコーディングは，Cosminexusで設定した文字エンコーディングとなります。

なお，Servlet仕様での文字エンコーディングの設定方法については，「4.6.6　Servlet仕様での文字エンコーディング設定」を参照してください。

(3)　XML宣言内の文字エンコーディング

JSPドキュメントおよびXML形式のタグファイルで，WebコンテナがXML宣言を自動生成する場合，XML宣言内の文字エンコーディングの宣言には，レスポンスボディのエンコードに適用されたデフォルトの文字エンコーディングが出力されます。

(4)　JSPファイルへの文字エンコーディングの適用

JSPファイルへの文字エンコーディング設定は，JSPファイルのコンパイル時に適用されます。このため，すでにJSPファイルがコンパイルされている状態で，文字エンコーディングの設定を追加または変更しても，追加または変更した文字エンコーディングはJSPファイルに反映されません。設定を反映させるためには，再度，コンパイルを実施してください。

(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定

07-00でJSP事前コンパイルを実行したWebアプリケーションに対して，レスポンスへのデフォルトの文字エンコーディングを設定する場合は，再度，JSP事前コンパイルを実施してください。

デフォルトの文字エンコーディングの設定単位ごとに説明します。

J2EEサーバ単位での設定の場合
J2EEサーバ上で動作するすべてのWebアプリケーションのJSPファイルに対して，JSP事前コンパイルを実施します。

Webアプリケーション単位での設定の場合
Webアプリケーションに含まれるJSPファイルに対して，JSP事前コンパイルを実施します。

なお，JSP事前コンパイル実行時でのデフォルトの文字エンコーディング設定については，「4.6.4　JSP事前コンパイル実行時の文字エンコーディングの適用」を参照してください。

(6)　デフォルトエラーページの文字エンコーディングについて

デフォルトエラーページの文字エンコーディングはUTF-8に設定されているため，デフォルトエンコーディングは適用されません。

4.6.6　Servlet仕様での文字エンコーディング設定

Servlet仕様で規定された文字エンコーディング設定がある個所については，Cosminexusで設定したデフォルトの文字エンコーディングは無効となります。

ここでは，Servlet仕様で規定された文字エンコーディング設定について説明します。なお，文字エンコーディングの設定は，Servlet仕様のバージョンによって異なります。

＜この項の構成＞

(1)　Servlet仕様での文字エンコーディングの設定方法

(2)　Servlet仕様で規定されている文字エンコーディング

(1)　Servlet仕様での文字エンコーディングの設定方法

Servlet仕様での文字エンコーディングの設定方法について，Servlet/JSPのバージョンごとに表に示します。

表4-15　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.4/JSP 2.0）

設定内容
設定場所
Servlet仕様での設定方法

リクエストの文字エンコーディング
サーブレット
ServletRequest.setCharacterEncoding(java.lang.String env)※1

JSPファイル
なし

レスポンスの文字エンコーディング
サーブレット

ServletResponse.setContentType(java.lang.String type)※1

ServletResponse.setCharacterEncoding(java.lang.String charset)※1

ServletResponse.setLocale(java.util.Locale loc)※1

JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

JSPファイルの文字エンコーディング
JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブまたはTagディレクティブのpageEncoding属性※3

web.xmlのpage-encoding要素※2

XML宣言のencoding属性※4

注※1　パッケージはjavax.servletです。

注※2　JSPページに設定する方法です。

注※3　JSPページまたは標準形式のタグファイルに設定する方法です。

注※4　JSPドキュメントまたはXML形式のタグファイルに設定する方法です。

表4-16　Servlet仕様での文字エンコーディングの設定方法（Servlet 2.3/JSP 1.2）

設定内容
設定場所
Servlet仕様での設定方法

リクエストの文字エンコーディング
サーブレット
ServletRequest.setCharacterEncoding(java.lang.String env)
※1

JSPファイル
なし

レスポンスの文字エンコーディング
サーブレット

ServletResponse.setContentType(java.lang.String type)※1

ServletResponse.setLocale(java.util.Locale loc)※1

JSPファイル
PageディレクティブのcontentType属性値（charsetを含む）

JSPファイルの文字エンコーディング
JSPファイル

PageディレクティブのcontentType属性値（charsetを含む）※2

PageディレクティブのpageEncoding属性※2

注※1　パッケージはjavax.servletです。

注※2　JSPページまたはJSPドキュメントに設定する方法です。

(2)　Servlet仕様で規定されている文字エンコーディング

Servlet仕様での文字エンコーディング設定，およびCosminexusでのデフォルトの文字エンコーディングの設定がない場合は，Servlet仕様で規定されている文字エンコーディングが適用されます。

文字エンコーディングを設定していない場合に適用される，Servlet仕様で規定された文字エンコーディングを次に示します。

リクエストの場合
ISO-8859-1が適用されます。なお，サーブレットおよびJSPファイルでは，Servlet APIを使用して設定されます。

レスポンスの場合
Servlet仕様で規定された文字エンコーディングを，Servletのバージョンごとに次の表に示します。

表4-17　Servlet仕様で規定された文字エンコーディング（レスポンス）

Servletのバージョン | 種類 | 適用される文字エンコーディング
Servlet 2.3 | サーブレット | ISO-8859-1
JSPページ
JSPドキュメント
Servlet 2.4 | サーブレット | ISO-8859-1
JSPページ
JSPドキュメント | UTF-8

JSPファイルの場合
Servlet仕様で規定された文字エンコーディングを，Servletのバージョンごとに次の表に示します。

表4-18　Servlet仕様で規定された文字エンコーディング（JSPファイル）

Servletのバージョン | 種類 | 適用される文字エンコーディング
Servlet 2.3 | JSPページ | ISO-8859-1
JSPドキュメント
Servlet 2.4 | JSPページ | ISO-8859-1
標準形式のタグファイル
JSPドキュメント | UTF-8
XML形式のタグファイル

4.7　JSPの事前コンパイルとコンパイル結果の保持

通常，Webアプリケーション内のJSPファイルは，JSPファイルへの最初のリクエスト到着時にWebコンテナ上でコンパイルされます。JSP事前コンパイル機能を使用すると，Webアプリケーションのデプロイ前にコンパイルできます。JSP事前コンパイル機能であらかじめJSPファイルをコンパイルしておくと，JSPファイルへの最初のリクエスト到着時のレスポンスタイムを短縮できます。

また，JSPコンパイル結果である，Javaソースファイルおよびクラスファイルを，J2EEサーバの再起動時に保持するかどうか設定できます。

ここでは，JSP事前コンパイル機能とコンパイル結果の保持について説明します。

＜この節の構成＞

4.7.1　JSP事前コンパイル機能とは

4.7.2　JSP事前コンパイルの方法

4.7.3　JSP事前コンパイルの適用例

4.7.4　JSP事前コンパイルの実行時の処理

4.7.5　JSPコンパイル結果のライフサイクルと出力先

4.7.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

4.7.1　JSP事前コンパイル機能とは

JSP事前コンパイル機能とは，Webアプリケーションに含まれるJSPファイルを，デプロイ前にコンパイルし，クラスファイルを生成する機能です。

JSP事前コンパイル機能を使用した場合の処理の流れを次の図に示します。

図4-13　JSP事前コンパイル機能を使用した場合の処理の流れ

通常，Webアプリケーションに含まれるJSPファイルは，JSPファイルに最初のリクエストが到着したときにコンパイルされ，JSPファイルからクラスファイルが生成されます。このため，JSPへの初回リクエスト時のレスポンスタイムは遅くなります。また，web.xmlで<load-on-startup>を指定していると，コンパイルのタイミングはWebアプリケーションの開始時となるため，JSPへの初回リクエスト到着時のレスポンスタイムは短縮できます。ただし，Webアプリケーションの開始に時間が掛かります。

JSP事前コンパイル機能を使用すると，あらかじめ，クラスファイルの生成までを実施しておけるので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。

4.7.2　JSP事前コンパイルの方法

JSP事前コンパイル方法には次の二つがあります。

cjjspcコマンドによるJSP事前コンパイル

cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

ここでは，JSP事前コンパイルを実行するコマンドの概要と，コンパイル方法について説明します。なお，コンパイル方法は，どの場面でJSPファイルを事前にコンパイルするかによって異なります。JSP事前コンパイルを適用する場面とコンパイル方法については，「4.7.3　JSP事前コンパイルの適用例」を参照してください。

＜この項の構成＞

(1)　コマンドの概要

(2)　cjjspcコマンドによるJSP事前コンパイル

(3)　cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

(1)　コマンドの概要

ここでは，JSP事前コンパイルを実施するための前提条件と，JSP事前コンパイル実行時に必要なファイル，および実行後に生成されるファイルについて説明します。

前提条件

JSP事前コンパイルを実施するための前提条件は次のとおりです。

コンパイルするJSPファイルがWebアプリケーションのルートディレクトリ以下，またはそのサブディレクトリ以下に格納されていること。

Webアプリケーションのルートディレクトリに/WEB-INFディレクトリがあること。

/WEB-INFディレクトリ直下にweb.xmlが格納されていること。

JSP事前コンパイルに必要なファイル

JSP事前コンパイルを実施するためには，次に示すファイルが必要です。

JSPファイル（JSP 1.1，JSP 1.2またはJSP 2.0）※1

JSP 2.0仕様に準拠したタグファイル※2

JSPファイルおよびタグファイルから静的にインクルードされるファイル

TLDファイル

web.xml

コンパイルに必要なクラスライブラリ

注※1　JSPファイルとは，次に示すファイルを指します。

拡張子が.jspまたは.jspxであるファイル（.jspxはJSP 2.0の場合だけ）

web.xmlの<jsp-file>タグに指定されたファイル

web.xmlの<jsp-property-group><url-pattern>タグに合致するファイル（JSP 2.0の場合だけ）

注※2　JSP事前コンパイル実行時にDTDまたはXMLスキーマに従っているかどうかが検証されます。

JSP事前コンパイル後に生成されるファイル（JSPコンパイル結果）

JSPファイルやタグファイルから生成された，JavaソースファイルおよびクラスファイルをJSPコンパイル結果といいます。JSP事前コンパイルを実施すると，JSPワークディレクトリに次に示すJSPコンパイル結果が生成されます。

JSPファイルから生成されたJavaソースファイルおよびクラスファイル

タグファイルから生成されたJavaソースファイルおよびクラスファイル

なお，JSP事前コンパイル実行時には，Javaソースファイルを保存しておくかどうかを設定できます。

(2)　cjjspcコマンドによるJSP事前コンパイル

cjjspcコマンドは，JSP事前コンパイルを実施するためのコマンドです。アプリケーションの開発時などにこのコマンドを実施すると，Webアプリケーションに含まれるJSPファイルをコンパイルできます。cjjspcコマンドによるJSP事前コンパイルには，次の二つの方法があります。

JSPファイル単位での事前コンパイル
Webアプリケーションに含まれるJSPファイルのうち，指定されたJSPファイルだけをコンパイルします。

Webアプリケーション単位での事前コンパイル
Webアプリケーションに含まれるすべてのJSPファイルをコンパイルします。

また，このコマンド実行時に次の内容を設定できます。

コンパイル不要なJSPファイルの指定
コンパイル不要なJSPファイルがある場合，あらかじめ不要なファイルを指定しておくことで，事前コンパイルの対象外にできます。指定方法には，コンパイル不要なJSPファイル名をコマンドに一つずつ指定する方法と，コンパイル不要なJSPファイル名をファイルにまとめて記載し，そのファイルをコマンドに指定する方法があります。

実行結果リストファイルを出力するかどうかの指定
実行結果リストファイルを出力するかどうかを指定できます。実行結果リストファイルとは，cjjspcコマンドの実行結果を出力したファイルです。コンパイルに成功したJSPファイル，コンパイルに失敗したJSPファイル，およびコンパイル対象外のJSPファイルのパスを一覧で出力します。

Javaソースファイルを保存するかどうかの指定
JSPから生成されたJavaソースファイルを保存しておくかどうかを指定できます。

JSPコンパイル時のJava言語仕様のバージョンの指定
JSPトランスレーションによって生成されたJavaソースファイルをコンパイルするときのJava言語仕様のバージョンを指定できます。

JSPワークディレクトリ名を変更するかどうかの指定
JSPワークディレクトリとは，JSPコンパイル結果を格納するディレクトリのことです。JSPワークディレクトリ名は変更できます。なお，JSPワークディレクトリについては，「4.7.5(2)　JSPコンパイル結果の出力先」を参照してください。

デフォルトの文字エンコーディングの指定
JSPファイルのデフォルトの文字エンコーディングを指定できます。なお，デフォルトの文字エンコーディングの概要については，「4.6　デフォルトの文字エンコーディング設定」を参照してください。また，07-00でJSP事前コンパイル機能を使用していたWebアプリケーションに対して，07-10でデフォルトの文字エンコーディングを設定する場合の注意については，「4.6.5(5)　07-00でJSP事前コンパイルを実行したWebアプリケーションへの文字エンコーディング設定」を参照してください。

なお，これらの設定は，コマンドのオプションで指定します。アプリケーション開発時での事前コンパイルのコマンドの使い方については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。

参考

cjjspcコマンドを使用したJSP事前コンパイルで，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージが出力されます。エラーメッセージはコンソールに出力されます。

(3)　cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

cjstartappコマンドは，J2EEアプリケーションを開始するためのコマンドです。cjstartappコマンドに，JSP事前コンパイルをするオプションを指定すると，JSPの事前コンパイルを実施してから，J2EEアプリケーションが開始されます。J2EEアプリケーション開始時のJSP事前コンパイルでは，J2EEアプリケーションに含まれるすべてのJSPファイルをコンパイルします。

このコマンドの実行時の動作はあらかじめ設定できます。設定できる内容を次に示します。

Javaソースファイルを保存するかどうかの指定
JSPファイルから生成されたJavaソースファイルを保存しておくかどうかを指定できます。

JSPコンパイル時のJava言語仕様のバージョンの指定
JSPトランスレーションによって生成されたJavaソースファイルをコンパイルするときのJava言語仕様のバージョンを指定できます。

JSPワークディレクトリ名を変更するかどうかの指定
JSPワークディレクトリとは，JSPコンパイル結果を格納するディレクトリのことです。JSPワークディレクトリ名は変更できます。なお，JSPワークディレクトリについては，「4.7.5(2)　JSPコンパイル結果の出力先」を参照してください。

なお，これらの設定は，J2EEサーバの動作設定のカスタマイズで実施します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

参考

cjstartappコマンドを使用したJSP事前コンパイルで，JSPファイルまたはタグファイルのトランスレーション時にエラーが発生すると，エラーメッセージが出力されます。エラーメッセージはWebサーブレットログ，またはメッセージログに出力されます。

4.7.3　JSP事前コンパイルの適用例

JSP事前コンパイルは次に示すときに使用できます。

アプリケーション開発時

システム運用時

JSP事前コンパイルの適用場面と使用するコマンドの対応表を次に示します。

表4-19　JSP事前コンパイルの適用場面と使用するコマンドの対応

適用する場面 | 使用するコマンド | 参照先
アプリケーション開発 | Webアプリケーションの開発時 | cjjspcコマンド | (1)　アプリケーション開発での使用
システム運用 | J2EEアプリケーション開始時 | cjstartappコマンド | (2)　システム運用での使用
J2EEアプリケーション入れ替え時 | 通常の入れ替え | cjstartappコマンド
リロードによる入れ替え | cjjspcコマンド
リデプロイによる入れ替え | cjjspcコマンド

JSP事前コンパイルを使用する場面について次に説明します。なお，使用するコマンドの概要については，「4.7.2　JSP事前コンパイルの方法」を参照してください。

＜この項の構成＞

(1)　アプリケーション開発での使用

(2)　システム運用での使用

(1)　アプリケーション開発での使用

Webアプリケーションの開発では，Webアプリケーションの開発中またはWebアプリケーション完成後に，JSP事前コンパイルを実施できます。JSP事前コンパイルを実施するには，cjjspcコマンドを使用します。Webアプリケーション開発での，JSP事前コンパイルの適用例を次の図に示します。

図4-14　Webアプリケーション開発でのJSP事前コンパイルの適用例

JSP事前コンパイル機能は，図中の1.または2.の場面で使用できます。図中の1.および2.について説明します。

JSPファイルの作成後または修正後
JSPファイルの作成および修正のあと，JSPファイル単位で動作確認を実施するときに，JSPファイルのコンパイルが正常に完了するかどうかを確認します。また，JSPファイル単位で事前コンパイルを実施しておくことで，動作確認時のJSP初回リクエストのレスポンスタイムを向上できます。
作成・修正したJSPファイルだけを事前にコンパイルするには，cjjspcコマンドの，JSPファイル単位でのJSP事前コンパイルを実施します。

Webアプリケーション完成時
完成したWebアプリケーションに含まれるすべてのJSPファイルを，一括してコンパイルします。Webアプリケーション実行時のJSP初回リクエストのレスポンスタイムを向上できます。
Webアプリケーション内のすべてのJSPファイルを一括でコンパイルするには，cjjspcコマンドの，Webアプリケーション単位でのJSP事前コンパイルを実施します。

なお，アプリケーション開発時にJSP事前コンパイルを使用するときのコンパイルの実施方法については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。

(2)　システム運用での使用

システム運用時では，JSP初回リクエストのレスポンスタイムを向上させるために，運用の開始前に，JSP事前コンパイルを実施します。システム運用時のJSP事前コンパイルは，J2EEアプリケーションを開始するときや，J2EEアプリケーションの入れ替えをするときに実施します。システム運用での，JSP事前コンパイルの適用例を次の図に示します。

図4-15　システム運用でのJSP事前コンパイルの適用

JSP事前コンパイル機能を適用する場面ごとに概要を説明します。なお，システム運用時にJSP事前コンパイルを使用するときのコンパイルの実施方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

(a)　J2EEアプリケーション開始時

J2EEアプリケーション開始時に，インポート済みのJ2EEアプリケーションに対してJSP事前コンパイルを使用できます。J2EEアプリケーション開始時に実施するJSP事前コンパイルは，cjstartappコマンドにJSP事前コンパイルを実施するためのオプションを指定して実行します。このコマンドを実行すると，J2EEアプリケーションの開始前に，J2EEアプリケーションに含まれるJSPファイルを一括してコンパイルします。

(b)　J2EEアプリケーション入れ替え時

J2EEアプリケーションを入れ替える場合，入れ替えを実施する前にJSP事前コンパイルを使用できます。なお，JSP事前コンパイルの方法は，J2EEアプリケーション入れ替えの方法によって異なります。

通常のJ2EEアプリケーションの入れ替えの場合
通常のJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションをいったん停止してから，新しいアプリケーションと入れ替える方法です。
通常のJ2EEアプリケーションの入れ替えの場合，入れ替え後のJ2EEアプリケーションをインポートしたあとに，cjstartappコマンドにJSP事前コンパイルを実施するためのオプションを指定して，JSP事前コンパイルを実行します。このコマンドを実行すると，入れ替え後のJ2EEアプリケーションが開始される前に，J2EEアプリケーションに含まれるJSPファイルが一括でコンパイルされます。

リロードによるJ2EEアプリケーションの入れ替えの場合
リロードによるJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションを停止しないで，新しいJ2EEアプリケーション（展開形式のアプリケーション）と入れ替える方法です。
JSPコンパイル結果を含むJ2EEアプリケーションをリロード機能を使用して運用している場合で，JSPファイルの修正が発生したときに，cjjspcコマンドによって修正したJSPファイルのコンパイルができます。

リデプロイによるJ2EEアプリケーションの入れ替えの場合
リデプロイによるJ2EEアプリケーションの入れ替えとは，J2EEアプリケーションを停止しないで，新しいJ2EEアプリケーション（アーカイブ形式のアプリケーション）と入れ替える方法です。
リデプロイによるJ2EEアプリケーションの入れ替えの流れを次に示します。

cjjspcコマンドでJSP事前コンパイルを実施し，J2EEアプリケーションに含まれるすべてのJSPファイルを一括してコンパイルします。

1.で生成したJSPコンパイル結果を含んだEARファイルを作成します。

2.のEARファイルをリデプロイします。

なお，J2EEアプリケーションの入れ替えの概要については，「19.6　J2EEアプリケーションの入れ替え」を参照してください。なお，リロードについては，「7.5　J2EEアプリケーションの更新検知とリロード」もあわせて参照してください。

4.7.4　JSP事前コンパイルの実行時の処理

ここでは，JSP事前コンパイル実行時に実施されるチェックやJSP事前コンパイル機能を実行したJ2EEアプリケーションの動作について説明します。

＜この項の構成＞

(1)　JSP事前コンパイルで実施されるチェック

(2)　JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

(3)　JSP事前コンパイル機能の注意

(1)　JSP事前コンパイルで実施されるチェック

JSP事前コンパイルの実行時には，web.xmlの妥当性チェック，およびJSPコンパイル結果のバージョンチェックが実施されます。

(a)　web.xmlの妥当性チェック

JSP事前コンパイル機能では，コンパイル処理を実行する前に，web.xmlがDTDまたはXMLスキーマに従っているかどうかの検証が実施されます。また，JSP事前コンパイル時に参照する要素については，JSP事前コンパイルに必要な範囲で，設定値が妥当であるかどうかについても検証されます。スキーマに従っていない場合は，JSPファイルからJavaファイルを生成するJSPのトランスレーション時に，エラーが発生します。

JSP事前コンパイル実行時に検証されるweb.xmlの要素を次の表に示します。

表4-20　JSP事前コンパイル時に検証されるweb.xmlの要素

タグ名 | タグの説明 | Servletのバージョン
2.2 | 2.3 | 2.4
<!DOCTYPE> | DOCTYPE宣言 | ○ | ○ | ×
<web-app> | ルートタグ | ○ | ○ | ○
| <servlet> | サーブレットについての定義 | ○ | ○ | ○
|  | <jsp-file> | JSPファイル名 | ○ | ○ | ○
| <taglib> | タグライブラリについての定義 | ○ | ○ | －
|  | <taglib-uri> | タグライブラリのURI | ○ | ○ | －
|  | <taglib-location> | タグライブラリ記述ファイル（TLD）の場所 | ○ | ○ | －
| <jsp-config> | JSPについての定義 | － | － | ○
|  | <taglib> | タグライブラリについての定義 | － | － | ○
|  |  | <taglib-uri> | タグライブラリのURI | － | － | ○
|  |  | <taglib-location> | タグライブラリ記述ファイル（TLD）の場所 | － | － | ○
|  | <jsp-property-group> | 指定したURLパターンに合致するJSPの設定 | － | － | ○
|  |  | <url-pattern> | 設置を適用するJSPのURLパターン | － | － | ○
|  |  | <el-ignored> | EL（式言語）を無視するかの設定 | － | － | ○
|  |  | <scripting-invalid> | スクリプティング要素を無効にするかの設定 | － | － | ○
|  |  | <page-encoding> | ページエンコーディング名 | － | － | ○
|  |  | <include-prelude> | JSPのヘッダとしてインクルードするファイル | － | － | ○
|  |  | <include-coda> | JSPのフッタとしてインクルードするファイル | － | － | ○
|  |  | <is-xml> | XML形式で記述されているかの設定 | － | － | ○

（凡例）○：検証される　　×：検証されない　　－：サポートしていない要素

参考

WebアプリケーションのServletのバージョンが2.4のときは，妥当性の検証がデフォルトで実施されます。Webアプリケーションのバージョンが2.3以前の場合，妥当性の検証を行うかどうかはあらかじめ設定しておく必要があります。検証をするかどうかの設定については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのカスタマイズに関する記述を参照してください。

(b)　JSPコンパイル結果のバージョンチェック

JSP事前コンパイル機能使用時，J2EEサーバはweb.xmlで指定されたWebアプリケーションのバージョンと，JSPコンパイル時のJSPのバージョンが合致するかチェックします。バージョンのチェックは次のタイミングで実施されます。

アプリケーション開始時に，JSP事前コンパイルを実施する指定をしていないとき（-jspcオプションを指定しないで，cjstartappコマンドでアプリケーションを開始したとき）

cjjspcコマンドを使用して，コンパイル対象外ファイルを指定してWebアプリケーション単位のJSP事前コンパイルを実行したとき

cjjspcコマンドを使用して，JSPファイル単位にJSP事前コンパイルを実行したとき

JSPから生成されるクラスファイルは，web.xmlで指定されたWebアプリケーションのバージョンに依存します。JSP事前コンパイル実行時のWebアプリケーションとバージョンが異なるWebアプリケーションで使用することはできません。このため，Webアプリケーションのバージョンを変更した際には，すべてのJSPファイルをコンパイルする必要があります。

なお，次の場合は，Webアプリケーションに含まれるすべてのJSPをコンパイルするため，JSPコンパイル結果のチェックは実施されません。

コンパイル対象外ファイルを指定しないでWebアプリケーション単位のJSP事前コンパイルを実行したとき

アプリケーション開始時のJSP事前コンパイルを実行したとき

参考

JSPコンパイル結果のバージョンチェックが実施されると，コンパイル対象のWebアプリケーションのJSPワークディレクトリに，JSPファイルのバージョン情報が記述されたバージョン情報ファイルが生成されます。バージョン情報ファイルは次の場所に生成されます。

<Webアプリケーションのディレクトリ>/WEB-INF/<JSPワークディレクトリ名>/WEB-INF/<JSPワークディレクトリ名>/jsp_compile_info

(c)　TLDファイルのチェック

TLDファイルは，JSP事前コンパイル実行時にDTDまたはXMLスキーマに従っているかどうか検証されます。WebアプリケーションのバージョンごとにTLDファイルのチェックについて説明します。

Webアプリケーションのバージョンが2.4の場合
デフォルトで検証が実施されます。なお，スキーマに従っていない場合，JSPファイルのトランスレーション時にエラーとなります。

Webアプリケーションのバージョンが2.3以前の場合
あらかじめ，検証をするかどうか設定しておく必要があります。TLDファイルを検証する設定をしている場合に，JSP事前コンパイル実行時に検証されます。
なお，TLDファイルの検証については，マニュアル「Cosminexus　システム構築ガイド」のJSPファイルのコンパイル結果の保持の設定に関する説明を参照してください。また，設定ファイルについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(2)　JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

JSP事前コンパイル機能を実行したJ2EEアプリケーションの動作について説明します。

(a)　リクエスト実行時およびJ2EEアプリケーション開始時の動作

JSP事前コンパイルを実施していると，リクエスト実行時にはJSPコンパイルは実施されません。事前コンパイル時に作成したJSPのクラスファイルがロードされ，実行されます。

このとき，JSPファイルからコンパイルされたクラスファイルがない場合などには，エラーになります。JSP事前コンパイルを実施していて，ファイルがない場合のJ2EEサーバの挙動を次の表に示します。

表4-21　ファイルがない場合のJ2EEサーバの挙動（JSP事前コンパイルを実行しているとき）

存在しないファイル | J2EEサーバの挙動
JSPファイル | JSPファイル | JSPファイルを参照しない
クラスファイル | 404エラーを返す
タグファイル | タグファイル | タグファイルを参照しない
クラスファイル | 500エラーを返す（java.lang.NoClassDefFoundErrorが発生する）
静的インクルードされたファイル | 静的インクルードされたファイルを参照しない
TLDファイル | TLDファイルを参照しない

事前コンパイルを実施してない場合でファイルがないときは，J2EEサーバは次のように動作します。

表4-22　ファイルがない場合のJ2EEサーバの挙動（JSP事前コンパイルを実行していないとき）

存在しないファイル | J2EEサーバの挙動
JSPファイル | JSPファイル | 404エラーを返す
クラスファイル | JSPファイルをコンパイルする
タグファイル | タグファイル | 500エラーを返す（コンパイルエラー）
クラスファイル | タグファイルをコンパイルする
静的インクルードされたファイル | 500エラーを返す（コンパイルエラー）
TLDファイル

(b)　J2EEアプリケーション開始時の動作

web.xmlでJSPファイルに<load-on-startup>を指定したWebアプリケーションのJSPファイルを事前コンパイルした場合，J2EEアプリケーション開始時には，JSPコンパイルは実施されません。JSP事前コンパイル時に生成されたクラスファイルがロードされ，jspInitメソッドが実行されます。このとき，JSPのクラスファイルまたはJSPが依存するクラスファイルがない場合は，JSPファイルのロードに失敗します。

なお，サーブレットとJSPのエラー通知の設定が有効になっている場合は，Webアプリケーション開始時に失敗します。サーブレットとJSPのエラー通知の設定については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

(3)　JSP事前コンパイル機能の注意

ここでは，JSP事前コンパイル機能での注意事項を説明します。

「jsp_precompile=true」を付加したリクエストの送信
JSP事前コンパイルを実行したアプリケーションに，クエリ文字列「jsp_precompile=true」を付加したリクエストを送信しても，JSPコンパイルは実行されません。

JSP事前コンパイルのコマンドの複数起動による同じWebアプリケーションの操作
cjjspcコマンドの複数起動によって同じWebアプリケーションに対するJSP事前コンパイルを実行することはできません。また，アプリケーション開始時のJSP事前コンパイル実行時にcjjspcコマンドによって同じWebアプリケーションに対するコンパイル処理を実行することはできません。
なお，コマンドの排他処理のため，JSP事前コンパイル実行中には，JSPワークディレクトリにロックファイルが生成されます。ロックファイルは次の場所に生成されます。
<Webアプリケーションのディレクトリ>/WEB-INF/<JSPワークディレクトリ名>/WEB-INF/<JSPワークディレクトリ名>/ExecutingJspPrecompilation.lock

JSPコンパイル結果を使用するアプリケーションに移行する場合
アーカイブ形式のJ2EEアプリケーションの場合，アプリケーション開始時のJSP事前コンパイルで生成したコンパイル結果は，アプリケーションの停止時に削除されます。
アプリケーション開始時のJSP事前コンパイルで生成したJSPコンパイル結果を，アプリケーションの停止後も利用する場合の手順を，J2EEアプリケーションの形式ごとに説明します。
アーカイブ形式のJ2EEアプリケーションの場合

アプリケーション開始時のJSP事前コンパイルを実行する

アプリケーションを実行時情報を含めてJ2EEアプリケーションをエクスポートする

リデプロイ機能等を使用して，JSPコンパイル結果を含むアプリケーションに入れ替える

展開ディレクトリ形式のJ2EEアプリケーションの場合

cjjspcコマンドまたはアプリケーション開始時にJSP事前コンパイルを実行する

JSPコンパイル結果を使用しないアプリケーションに移行する場合
JSP事前コンパイルで生成されたJSPコンパイル結果を使用しない場合は，JSPワークディレクトリを，ディレクトリごと削除する必要があります。
JSPコンパイル結果を使用しない場合の手順を，J2EEアプリケーションの形式ごとに説明します。
アーカイブ形式のJ2EEアプリケーションの場合

J2EEアプリケーションをエクスポートする

EARファイルを展開する

<Webアプリケーションのルートディレクトリ>/WEB-INFの下にある，JSPワークディレクトリをディレクトリごと削除する

EARファイルを作成する

リデプロイ機能などを使用して，J2EEアプリケーションを入れ替える

展開ディレクトリ形式のJ2EEアプリケーションの場合

J2EEアプリケーションを停止する

<Webアプリケーションのルートディレクトリ>/WEB-INFの下にある，JSPワークディレクトリをディレクトリごと削除する

J2EEアプリケーションを開始する

JSPファイルが依存するファイルを修正した場合
タグファイル，静的にインクルードされたファイル，またはTLDファイルを更新した場合は，更新したファイルを参照するすべてのJSPファイルをコンパイルする必要があります。

JSP事前コンパイル機能を使用する展開ディレクトリ形式のJ2EEアプリケーションを更新する場合
JSP事前コンパイル機能を使用する展開ディレクトリ形式のJ2EEアプリケーションを更新する場合，次の点に注意してください。

JSPファイルまたはタグファイルをJ2EEアプリケーションに追加した場合
追加したJSPファイルまたはタグファイルを参照するJSPファイルを，すべてコンパイルしてください。なお，JSPファイルのコンパイルには，JSP事前コンパイル機能を使用してください。

開発環境で更新したJSPコンパイル結果を実行環境に反映する場合
開発環境のJ2EEアプリケーションのJSPワークディレクトリ下にあるクラスファイルを，実行環境のJ2EEアプリケーションのJSPワークディレクトリにコピーしてください。この場合，開発環境でJSP事前コンパイル実行時に更新された，すべてのクラスファイルがコピー対象となります。

4.7.5　JSPコンパイル結果のライフサイクルと出力先

JSP事前コンパイル機能を使用している場合の，JSPコンパイル結果のライフサイクルと，JSPコンパイル結果の出力先について説明します。

＜この項の構成＞

(1)　JSPコンパイル結果のライフサイクル

(2)　JSPコンパイル結果の出力先

(1)　JSPコンパイル結果のライフサイクル

JSP事前コンパイルを使用している場合のJSPのコンパイル結果のライフサイクルについて説明します。

コンパイル結果の生成

JSP事前コンパイル機能を使用する場合は，次のどちらかのタイミングでコンパイル結果が生成されます。

cjjspcコマンドを実行するとき

cjstartappコマンドに-jspcオプションを指定してWebアプリケーションを開始するとき

コンパイル結果の削除

アーカイブ形式のJ2EEアプリケーションの場合，アプリケーション開始時のJSP事前コンパイルを実行して生成されたコンパイル結果は，アプリケーションの停止時に削除されます。

(2)　JSPコンパイル結果の出力先

JSP事前コンパイルを実施すると，JSPワークディレクトリが作成され，JSPコンパイル結果はJSPワークディレクトリに出力されます。ただし，コンパイル対象となるJSPファイルが存在しない場合は，JSPワークディレクトリは作成されません。出力されるファイルは次のとおりです。

JSPファイルから生成されたJavaソースファイル※

1.のJavaソースファイルをコンパイルしたクラスファイル

タグファイルから生成されたJavaソースファイル※

3.のJavaソースファイルをコンパイルしたクラスファイル

注※　JSP事前コンパイルを実施する場合は，これらのファイルを保存するかどうかを設定できます。

ここでは，デフォルトの出力先と，出力先のディレクトリ構成について説明します。

(a)　デフォルトの出力先

JSP事前コンパイルを実行する場合，コンパイル結果はJSPワークディレクトリに出力されます。デフォルトのJSPワークディレクトリは次の場所になります。

Windowsの場合

<WebアプリケーションのWEB-INFディレクトリ>¥cosminexus_jsp_work

UNIXの場合

<WebアプリケーションのWEB-INFディレクトリ>/cosminexus_jsp_work

なお，JSPワークディレクトリ名はデフォルト値が設定されていますが，必要に応じて変更できます。JSPワークディレクトリ名の変更については，cjjspcコマンドでJSP事前コンパイルを実施する場合は，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。cjstartappコマンドでJ2EEアプリケーションの開始時にJSP事前コンパイルを実施する場合は，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのカスタマイズに関する説明を参照してください。

(b)　出力先のディレクトリ構成

JSPコンパイル結果は，JSPワークディレクトリに出力されます。JSPコンパイル結果の出力先ディレクトリ構成を次の図に示します。なお，この図ではJSPワークディレクトリはデフォルトのディレクトリ名となっています。

図4-16　JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行している場合）

ディレクトリ構成について説明します。

タグファイルから生成されたクラスのパッケージ名は次の形式となります。

WEB-INF/tags下のタグファイルの場合

org.apache.jsp.tag.web.</WEB-INF/tagsディレクトリ下のパス>

WEB-INF/lib下のjarファイルに含まれるタグファイルの場合

org.apache.jsp.tag.meta.<jarファイル名をエンコードした文字列>.<jarファイル内のMETA-INF/tagsディレクトリ下のパス>

JSPファイルおよびタグファイルから生成されるクラスファイルの出力先ディレクトリのパス長は，OSの上限によって制限があります。OSの上限を超えるパス長になる場合は，JSPワークディレクトリ名を変更してください。

4.7.6　JSP事前コンパイルを使用しない場合のJSPコンパイル結果

JSP事前コンパイルを使用しない場合，JSPファイルのコンパイルは，JSPファイルへの初回アクセス時に実施されます。ここでは，JSP事前コンパイル機能を使用しない場合の，JSPコンパイル結果について説明します。

＜この項の構成＞

(1)　JSPコンパイル結果のライフサイクル

(2)　JSPファイルのコンパイル結果の保持

(3)　JSPコンパイル結果の出力先

(1)　JSPコンパイル結果のライフサイクル

JSP事前コンパイルを使用しない場合のJSPのコンパイル結果のライフサイクルについて説明します。

コンパイル結果の生成

JSP事前コンパイル機能で事前にJSPファイルのコンパイルを実施していない場合は，JSPコンパイル結果は次のどちらかのタイミングで生成されます。

JSPに最初にアクセスするとき

DD（web.xml）でJSPに対し<load-on-startup>が指定されている，Webアプリケーションを開始するとき

コンパイル結果の削除

JSPのコンパイル結果は，次のタイミングで削除されます。

J2EEアプリケーションのアンデプロイ時

J2EEサーバの起動時※

J2EEサーバの終了時※

注※

JSPコンパイル結果を保持しない設定にしている場合，削除されます。なお，J2EEサーバ起動時については，コンパイル結果の削除は，サーバが強制終了された場合に備えて実施されます。

(2)　JSPファイルのコンパイル結果の保持

JSP事前コンパイルをしない場合，JSPコンパイル結果はJ2EEサーバを停止または再起動するときに削除されます。Webコンテナでは，JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを，J2EEサーバの再起動時に保持するかどうか設定できます。

JSPファイルのコンパイル結果を保持するための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

Webアプリケーションアンデプロイ時の注意

デフォルトでは，JSPのコンパイル結果を保持する設定になっています。また，JSPコンパイル結果を保持する設定をしていても，Webアプリケーションをアンデプロイすると，JSPのコンパイル結果は削除されます。このため，ユーザは，サーバの再起動時にJSPのコンパイル結果を削除する必要はありません。JSPコンパイル結果を保持する設定でWebコンテナを稼働したあと，JSPコンパイル結果が不要となった場合は，J2EEアプリケーションをアンデプロイしてください。

JSPのコンパイル結果は保持する設定にしておくことをお勧めします。

(3)　JSPコンパイル結果の出力先

JSP事前コンパイルを実施していない場合，JSPコンパイル結果はJSP用テンポラリディレクトリに出力されます。

出力されるファイルは次のとおりです。

JSPファイルから生成されたJavaソースファイル

1.のJavaソースファイルをコンパイルしたクラスファイル

タグファイルから生成されたJavaソースファイル

3.のJavaソースファイルをコンパイルしたクラスファイル

ここでは，デフォルトの出力先と，出力先のディレクトリ構成について説明します。

(a)　デフォルトの出力先

JSP事前コンパイルを実行していない場合，JSPコンパイル結果は，JSP用テンポラリディレクトリ下に作成される，Webアプリケーション単位のディレクトリに出力されます。デフォルトのJSP用テンポラリディレクトリは次の場所になります。

Windowsの場合

<Cosminexusのインストールディレクトリ>¥CC¥server¥repository¥<サーバ名称>¥web

UNIXの場合

/opt/Cosminexus/CC/server/repository/<サーバ名称>/web

なお，JSP用テンポラリディレクトリは，デフォルト値が設定されていますが，必要に応じて変更できます。JSP用テンポラリディレクトリの変更については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのカスタマイズに関する説明を参照してください。

(b)　出力先のディレクトリ構成

JSPコンパイル結果の出力先ディレクトリ構成を次の図に示します。

図4-17　JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行していない場合）

ディレクトリ構成について説明します。

タグファイルから生成されたクラスのパッケージ名は次の形式となります。

WEB-INF/tags下のタグファイルの場合

org.apache.jsp.tag.web.</WEB-INF/tagsディレクトリ下のパス>

WEB-INF/lib下のjarファイルに含まれるタグファイルの場合

org.apache.jsp.tag.meta.<jarファイル名をエンコードした文字列>.<jarファイル内のMETA-INF/tagsディレクトリ下のパス>

JSPファイルおよびタグファイルから生成されるクラスファイルの出力先ディレクトリのパス長は，OSの上限によって制限があります。OSの上限を超えるパス長になる場合は，JSPワークディレクトリ名を変更してください。

4.8　アプリケーションのイベントリスナ

Webアプリケーション単位でのイベントリスナ機能があります。アプリケーションイベントリスナは，Webアプリケーションのデプロイ時にインスタンス化されます。インスタンス化されたアプリケーションイベントリスナは，サーブレットコンテキストオブジェクトまたはセッションオブジェクトのどちらか一方，または両方の状態変化イベントを受け取ります。リスナオブジェクトが受け取るイベントを次に示します。

セッションオブジェクトの新規生成

セッションオブジェクトのシリアライズ前※1

セッションオブジェクトのデシリアライズ後※1

セッションオブジェクトの抹消

セッションオブジェクトの属性の追加，削除，変更

サーブレットコンテキストオブジェクトの生成

サーブレットコンテキストオブジェクトの抹消

サーブレットコンテキストオブジェクトの属性の追加，削除，変更

Webアプリケーションへのリクエストの到着※2

Webアプリケーションでのリクエスト処理の完了※2

リクエストオブジェクトの属性の追加，削除，変更※2

注※1

サーブレットエンジンのベンダ独自処理の都合で，セッションオブジェクトをシリアライズして格納，通信し，別の時点でデシリアライズして処理を再開することが，Servlet APIでは想定されています。

セッションオブジェクトに，これらのイベント通知が設けられている意図は，セッションオブジェクトにデータだけでなく，データベースコネクションやオブジェクトリファレンスなどの資源を持たせられるようにするためです。セッションオブジェクトに資源を持たせるような設計のアプリケーションでは，シリアライズの前にいったん資源を解放し，デシリアライズ後に再び獲得するようにしなければなりません。

セッションオブジェクトに資源を持たせるという構成は，注意深く利用しないとサーバ全体の必要資源量を大幅に増大させてしまい，資源が不足するおそれがあります。このため，イベントリスナ機能は，資源を確保できる場合に利用してください。

注※2

Servlet 2.4の場合だけ使用できます。

4.9　タグファイルの実行

Application Serverでは，JSP 2.0で規定されているJSPの構文に従って作成されたタグファイルを実行できます。タグファイルの実行では，次の内容が実施されます。

タグファイルをjavaクラスに変換する

変換したjavaクラスファイルをコンパイルする

コンパイルしたファイルをJavaVM内にロードして実行する

タグファイルを使用すると，従来，カスタムタグライブラリで実現していたタグの拡張をJSPの構文だけで記述できます。

4.10　JSP ELの実行

Application Serverでは，JSP 2.0で規定されているELの構文に従って作成されたEL式を実行できます。JSP ELを使用すると，JSPファイルやタグファイル内でJavaBeans属性へのアクセスなどを記述できます。

4.11　リクエストおよびレスポンスのフィルタリング

Cosminexusで使用できるフィルタリングの機能には，Servlet仕様で規定されている機能と，Cosminexusで提供する機能があります。どちらの機能も，サーブレット/JSPのリクエストやレスポンスに対してフィルタリングをする機能です。

Servlet仕様で規定されているフィルタリング機能では，サーブレット/JSPを実行する前のリクエスト，またはサーブレット/JSPを実行したあとのレスポンスをラップします。これによって，データの変更，リソースに対するトレースの取得などができます。

また，Cosminexusが提供するフィルタリング機能では，セッション情報を引き継いだり，HTTPレスポンスを圧縮したりできます。Cosminexusでは，これらのフィルタリング機能を使用するためにサーブレットフィルタを提供しています。Cosminexusが提供するサーブレットフィルタをbuilt-inフィルタといいます。次項でCosminexusが提供するbuilt-inフィルタについて説明します。

＜この節の構成＞

4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）

4.11.2　フィルタ連鎖の推奨例

4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）

Cosminexusでは，次に示す機能を使用するためのサーブレットフィルタ（built-inフィルタ）を提供しています。

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）
J2EEサーバ間のセッション情報を引き継ぐために，Cosminexusはbuilt-inフィルタとしてセッションフェイルオーバ用フィルタを提供しています。

HTTPレスポンスの圧縮
HTTPリクエストに対するHTTPレスポンスを圧縮するために，Cosminexusはbuilt-inフィルタとしてHTTPレスポンス圧縮フィルタを提供しています。

built-inフィルタの種類を次の表に示します。また，Webアプリケーションにbuilt-inフィルタを組み込むことによって使用できる機能の参照先をあわせて示します。

表4-23　built-inフィルタの種類

built-inフィルタの種類 | 機能の説明 | 参照先
セッションフェイルオーバ用フィルタ | J2EEアプリケーションで実行中のセッション情報を管理します。J2EEサーバで障害が発生したときに，管理しているセッション情報をほかのJ2EEサーバに引き継ぎます。 | 12章
HTTPレスポンス圧縮フィルタ | サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスをgzip形式に圧縮します。 | 4.12

以降で，built-inフィルタのHTTPリクエスト・HTTPレスポンスへの作用，built-inフィルタの動作条件に関する制約について説明します。

＜この項の構成＞

(1)　HTTPリクエストおよびHTTPレスポンスへの作用

(2)　動作条件に関する制約

(1)　HTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタは，クライアント側から送信されるHTTPリクエストのリクエストヘッダ，およびリクエストボディに対して作用して，情報の削除，追加，変更などを実施する場合があります。また，サーバから送信されるHTTPレスポンスのレスポンスヘッダ，およびレスポンスボディに対して同様に作用する場合もあります。built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用を次の表に示します。

表4-24　built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタの種類 | HTTPリクエストへの作用 | HTTPレスポンスへの作用
セッションフェイルオーバ用フィルタ | － | －
HTTPレスポンス圧縮フィルタ | － | レスポンスボディが圧縮される場合，Content-Encodingヘッダに「gzip」を指定します。また，レスポンスボディをgzip形式で圧縮します。

（凡例）　－：該当なし

(2)　動作条件に関する制約

ユーザのフィルタと，built-inフィルタを同時に使用する場合，フィルタ連鎖の中でbuilt-inフィルタが呼び出される順序に制約があります。

built-inフィルタごとに次に示す制約について説明します。

位置に関する制約
フィルタ連鎖中のbuilt-inフィルタの位置（呼び出される順序）に関する制約です。

動作条件に関する制約
built-inフィルタが動作する上での前提条件などの動作条件に関する制約です。

前後に配置するほかのサーブレットフィルタに対する制約
built-inフィルタの前後に配置するサーブレットフィルタに対する制約です。

(a)　セッションフェイルオーバ用フィルタに対する制約

セッションフェイルオーバ用フィルタに対する制約を次の表に示します。

表4-25　セッションフェイルオーバ用フィルタに対する制約

制約の種類 | 説明
位置に関する制約 | フィルタ連鎖の中で，最初に呼び出される必要があります。すべてのユーザのフィルタおよびbuilt-inフィルタよりも前に配置する必要があります。
動作条件に関する制約 | －
前後に配置するほかのサーブレットフィルタに対する制約 | －

（凡例）　－：該当なし

(b)　HTTPレスポンス圧縮フィルタに対する制約

HTTPレスポンス圧縮フィルタに対する制約を次の表に示します。

表4-26　HTTPレスポンス圧縮フィルタに対する制約

制約の種類 | 説明
位置に関する制約 | －
動作条件に関する制約 | －
前後に配置するほかのサーブレットフィルタに対する制約 | javax.servlet.http.HttpServletResponseクラスのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，またはaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，またはContent-Encodingヘッダの設定を変更するサーブレットフィルタと同時に使用する場合，そのサーブレットフィルタはHTTPレスポンス圧縮フィルタよりあとに配置する必要があります。

（凡例）　－：該当なし

4.11.2　フィルタ連鎖の推奨例

フィルタ連鎖の推奨例を次に示します。次に示す順序で連鎖するように配置してください。

なお，例で説明するユーザのフィルタは，リクエストボディおよびレスポンスボディに作用する一般的なフィルタを想定しています。

セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮フィルタを使用する場合

セッションフェイルオーバ用フィルタ

HTTPレスポンス圧縮フィルタ

セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮フィルタ，およびユーザのフィルタ（FilterA）を使用する場合

セッションフェイルオーバ用フィルタ

HTTPレスポンス圧縮フィルタ

ユーザのフィルタ（FilterA）

セッションフェイルオーバ用フィルタ，およびユーザのフィルタ（FilterC）を使用する場合

セッションフェイルオーバ用フィルタ

ユーザのフィルタ（FilterC）

HTTPレスポンス圧縮フィルタ，およびユーザのフィルタ（FilterD）を使用する場合

HTTPレスポンス圧縮フィルタ

ユーザのフィルタ（FilterD）

4.12　フィルタリングによるHTTPレスポンスの圧縮

ここでは，サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスを圧縮する機能について説明します。この機能を，HTTPレスポンス圧縮機能といいます。この機能は，Webアプリケーションに組み込んで動作させるサーブレットフィルタとして提供されています。これを，HTTPレスポンス圧縮フィルタといいます。

この機能を使用することによって，WebコンテナとWebクライアント（ブラウザなど）との間のHTTPレスポンス通信に掛かる時間を削減できます。

HTTPレスポンス圧縮機能を使用するための設定は，J2EEアプリケーションに含まれるフィルタおよびWebアプリケーションの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

4.12.1　HTTPレスポンス圧縮フィルタの概要

4.12.2　HTTPレスポンス圧縮フィルタを使用するための条件

4.12.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

4.12.4　HTTPレスポンス圧縮機能を使用する場合のDDの定義内容

4.12.5　HTTPレスポンス圧縮機能を使用するDDの定義例

4.12.1　HTTPレスポンス圧縮フィルタの概要

HTTPレスポンス圧縮機能を有効にすると，HTTPレスポンスのレスポンスボディをgzip形式に圧縮します。HTTPレスポンス圧縮機能の概要を次の図に示します。

図4-18　HTTPレスポンス圧縮機能の概要

HTTPレスポンス圧縮機能を有効にするためには，Cosminexusが提供するHTTPレスポンス圧縮フィルタをWebアプリケーションに組み込む必要があります。HTTPレスポンス圧縮機能を適用する場合，WebアプリケーションのDD（web.xml）にHTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。J2EEサーバにデプロイ済みのWebアプリケーションに適用する場合は，サーバ管理コマンドを使用して，HTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。

4.12.2　HTTPレスポンス圧縮フィルタを使用するための条件

ここでは，HTTPレスポンス圧縮フィルタを使用する場合の条件や注意事項について説明します。

＜この項の構成＞

(1)　前提条件

(2)　必要なメモリ量

(3)　HTTPレスポンス圧縮機能を有効にする場合の条件

(4)　注意事項

(1)　前提条件

HTTPレスポンス圧縮機能を使用にするには，次の前提条件を満たしている必要があります。

Webクライアントのgzip形式の対応
HTTPレスポンス圧縮機能を有効にした場合，gzip形式で圧縮されたHTTPレスポンスをWebクライアントで解凍する必要があります。そのため，Webクライアントがgzip形式に対応していることが前提となります。Webクライアントがgzip形式に対応していない場合は，HTTPレスポンス圧縮機能を有効にしていても，HTTPレスポンスは圧縮されません。

WebクライアントのHTTP/1.1の対応
HTTPレスポンス圧縮機能では，Webクライアントがgzip形式に対応しているかどうかをHTTPリクエストのAccept-Encodingヘッダに指定された値によって判定しています。そのため，WebクライアントはAccept-Encodingヘッダの仕様が規定されているHTTP/1.1に対応している必要があります。

(2)　必要なメモリ量

HTTPレスポンス圧縮機能に必要なメモリ量は次の計算式で求められます。

HTTPレスポンス圧縮機能に必要なメモリ量（バイト）=HTTPレスポンス圧縮機能が有効となるHTTPリクエストの同時実行数×レスポンスの圧縮しきい値（バイト）

圧縮しきい値とは，HTTPレスポンスボディのサイズによって，HTTPレスポンスを圧縮するかどうかを判定するためのしきい値です。HTTPレスポンスボディのサイズが圧縮しきい値に定義したサイズを超える場合にだけ，HTTPレスポンスを圧縮します。なお，圧縮しきい値は，HTTPリクエストに対して設定します。

圧縮しきい値は，DD（web.xml）に定義します。圧縮しきい値を定義することで，HTTPレスポンスのサイズが小さい場合に，HTTPレスポンスの圧縮に掛かる時間が，通信に掛かる時間よりも大きくならないようにします。

圧縮しきい値は，圧縮するリソースの種別と通信回線の速度によって適切なサイズが決まります。圧縮しきい値に定義するサイズは実測で求め，適切なサイズを定義することを推奨します。

(3)　HTTPレスポンス圧縮機能を有効にする場合の条件

HTTPレスポンス圧縮機能が有効になる条件を指定できます。指定できる条件を次に示します。

HTTPリクエストのURLパターン
HTTPレスポンス圧縮フィルタを実装しているWebアプリケーションに対するリクエストのURLが，指定したURLパターンと一致する場合，そのリクエストに対するレスポンスを圧縮します。
HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例を次の図に示します。

図4-19　HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例

HTTPレスポンスのMedia-Type
HTTPレスポンスのContent-Typeヘッダに含まれるMedia-Typeの値が，指定した値と一致する場合，HTTPレスポンスを圧縮します。
HTTPレスポンスのMedia-Typeは，サーブレット/JSPの場合はJ2EEアプリケーションがsetContentTypeメソッドによって設定した値です。静的コンテンツの場合は拡張子に対応づけられたMIMEタイプとなります。
HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例を次の図に示します。

図4-20　HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例

HTTPレスポンスのボディサイズ
HTTPレスポンスの圧縮を実行するためしきい値を設定して，ボディサイズがこのしきい値を超える場合，HTTPレスポンスを圧縮します。
HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定してHTTPレスポンス圧縮機能を有効にした場合の例を次の図に示します。

図4-21　HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定した場合の例

(4)　注意事項

HTTPレスポンス圧縮フィルタの定義に関する注意事項

HTTPレスポンス圧縮フィルタを使用する場合，built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用やフィルタ連鎖の順序制約を考慮して，WebアプリケーションにHTTPレスポンス圧縮フィルタを組み込む必要があります。built-inフィルタの詳細については，「4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

エラーページに関する注意事項

HTTPレスポンス圧縮機能を使用するWebアプリケーションでは，次の機能を使用してエラーページをカスタマイズできます。

Webサーバの機能を使用したエラーページのカスタマイズ

インプロセスHTTPサーバによるエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページを使用する場合は，エラーページに静的コンテンツ，またはレスポンスからjavax.servlet.SevletOutputStreamを取得して使用するサーブレットを指定してください。

HTTPレスポンス圧縮機能では圧縮後のデータの出力にレスポンスオブジェクトから取得したjavax.servlet.ServletOutputStreamを使用します。そのため，エラーページを生成するサーブレット，またはJSPでレスポンスオブジェクトからは，java.io.PrintWriterを取得することができません。

4.12.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

ここでは，HTTPレスポンス圧縮フィルタを使用するアプリケーションを開発するときの注意事項について説明します。

＜この項の構成＞

(1)　ほかのフィルタと併用する場合の呼び出し順序

(2)　HTTPレスポンスのバッファに関する注意事項

(3)　HTTPレスポンスのレスポンスヘッダに関する注意事項

(4)　HTTPレスポンスのデータ出力に関する注意事項

(5)　アプリケーションでHTTPレスポンスを圧縮する場合の注意事項

(1)　ほかのフィルタと併用する場合の呼び出し順序

HTTPレスポンス圧縮フィルタは，HTTPレスポンスのヘッダに設定するほかのフィルタよりも前に呼び出される必要があります。javax.servlet.http.HttpServletResponseのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，およびaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，Content-Encodingヘッダを設定するほかのフィルタを使用する場合は，HTTPレスポンス圧縮フィルタよりも後ろに配置してください。

(2)　HTTPレスポンスのバッファに関する注意事項

HTTPレスポンス圧縮機能を有効にした場合，HTTPレスポンスのバッファよりも前に圧縮しきい値に指定したサイズのバッファが設けられます。HTTPレスポンスのバッファには，出力したデータが圧縮しきい値を超えたときに書き込まれます。

圧縮後のデータサイズがHTTPレスポンスのバッファサイズを超えなければ，WebクライアントにHTTPレスポンスが書き出されることはありません。出力したデータのサイズが圧縮しきい値を超える前に，HTTPレスポンスをWebクライアントに書き出す必要がある場合は，明示的にレスポンス出力用ストリーム※のflushメソッドを呼び出す必要があります。ただし，出力したデータのサイズが圧縮しきい値を超える前にflushメソッド，またはjavax.servlet.ServletResponseクラスのflushBufferメソッドを呼び出した場合は，出力したデータは圧縮されないでWebクライアントに書き出されます。

注※

レスポンス出力用ストリームとは，次に示すオブジェクトを指します。

javax.servlet. ServletResponseクラスのgetOutputStreamメソッドによって取得したjavax.servlet.ServletOutputStream

javax.servlet. ServletResponseクラスのgetWriterメソッドによって取得したjava.io.PrintWriter

JSPで暗黙的に利用できるjavax.servlet.jsp.JspWriter

(3)　HTTPレスポンスのレスポンスヘッダに関する注意事項

HTTPレスポンス圧縮機能によってHTTPレスポンスのレスポンスボディが圧縮される場合，このHTTPレスポンスのContent-Encodingヘッダにはgzip，VaryヘッダにはAccept-Encodingが指定されます。Content-Lengthヘッダには何も指定されません。

したがって，javax.servlet.ServletResponseクラスのsetContentLengthメソッドを使用する場合とjavax.servlet.http.HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用する場合は，次の点に注意してください。

次のどちらかのAPIを使用してContent-Lengthヘッダ，Content-Encodingヘッダを設定するフィルタを追加している場合は，レスポンス圧縮用フィルタよりもあとに実行されるようにDD（web.xml）で定義してください。

ServletResponseクラスのsetContentLengthメソッド

HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※

HTTPレスポンスのレスポンスボディが圧縮される場合，ServletResponseクラスのsetContentLengthメソッド，およびHttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用しても，HTTPレスポンスのContent-Lengthヘッダは付加されません。Content-Lengthヘッダが付加されていないHTTPレスポンスはWebコンテナによってchunk形式でクライアントに送信されます。

HTTPレスポンスのレスポンスボディが圧縮される場合，HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用してもContent-Encodingヘッダには値が設定されません。レスポンスボディが圧縮される場合は，WebコンテナによってContent-Encodingヘッダにgzipが指定されます。

注※

レスポンスヘッダを追加・変更するAPIとは，javax.servlet.http.HttpServletResponseクラスの次のメソッドを指します。

setHeaderメソッド

addHeaderメソッド

setIntHeaderメソッド

addIntHeaderメソッド

(4)　HTTPレスポンスのデータ出力に関する注意事項

javax.servlet.ServletResponseクラスのgetOutputStreamメソッド，またはgetWriterメソッドによってServletOutputStreamまたはPrintWriterを取得し，HTTPレスポンスを出力する場合は，次の点に注意してください。

ServletOutputStreamまたはPrintWriterを使用して，HTTPレスポンスのバッファにデータを書き出している状態で，ServletResponseのsetContentTypeメソッドを呼び出した場合，圧縮するように指定されたMedia-Typeを持つHTTPレスポンスであっても圧縮されません。
ただし，圧縮するMedia-Typeにアスタリスク（*）が指定されているときは圧縮されます。

Media-Typeを指定してJSPの出力を圧縮するためには，pageディレクティブのcontentType属性を指定するか，またはJSPのバッファを超える前にServletResponseクラスのsetContentTypeメソッドを呼び出す必要があります。

(5)　アプリケーションでHTTPレスポンスを圧縮する場合の注意事項

アプリケーションで圧縮したHTTPレスポンスには，HTTPレスポンス圧縮機能が有効にならないように設定してください。アプリケーションで圧縮したHTTPレスポンスに対して，HTTPレスポンス圧縮機能を有効にした場合の動作は保証できません。

4.12.4　HTTPレスポンス圧縮機能を使用する場合のDDの定義内容

ここでは，HTTPレスポンス圧縮機能を使用する場合に必要なDDの定義について説明します。

HTTPレスポンス圧縮機能を有効にするためには，WebアプリケーションのDDに，フィルタ定義およびフィルタマッピング定義を追加する必要があります。HTTPレスポンス圧縮機能は，フィルタマッピング定義によってマッピングされたURLパターンを持つリソースに対してリクエストがあった場合にだけ有効となります。

次に示すDDの定義例を基に，DDの定義内容を説明します。

    ：
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!－The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>タグで囲まれた部分がフィルタ定義，<filter-mapping>タグで囲まれた部分がフィルタマッピング定義となります。フィルタ定義の<filter-name>タグおよび<filter-class>タグに指定する値は，次のパッケージ名で固定です。

com.hitachi.software.was.web.ResponseCompressionFilter

次に，DDの<init-param>タグ内に定義する内容を示します。

表4-27　HTTPレスポンス圧縮機能使用時のDDの定義内容

定義する項目
<param-name>に指定する要素
<param-value>に指定する内容
デフォルト値

URLパターンとHTTPレスポンス圧縮規則のマッピング
url-mapping
URLパターンとHTTPレスポンス圧縮規則名とのマッピングを指定します。
指定を省略した場合は，デフォルト値が適用されます。
/*

HTTPレスポンス圧縮規則
HTTPレスポンス圧縮規則名
圧縮するHTTPレスポンスのMedia-Typeと圧縮しきい値（バイト単位）を指定します。圧縮しきい値は，100～2147483647の整数値で指定します。
指定を省略した場合は，すべてのMedia-Typeに圧縮しきい値100が適用されます。
100

＜この項の構成＞

(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）

(2)　HTTPレスポンス圧縮規則

(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）

HTTPレスポンス圧縮機能が有効となるURLパターンと，指定したURLパターンに適用するHTTPレスポンス圧縮規則名のマッピングを指定します。

パラメタ指定時の規則およびURLパターンのマッピング規則を示します。

(a)　パラメタ指定時の規則

URLパターンは，大文字と小文字が区別されます。

HTTPレスポンス圧縮規則名は，大文字と小文字が区別されます。

URLパターンとHTTPレスポンス圧縮規則名は，半角のイコール（=）で区切ります。

複数指定する場合は，半角のセミコロン（;）で区切ります。

複数のURLパターンに該当する場合は，先に指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

(b)　URLパターンのマッピング規則

url-mappingパラメタに定義するURLパターンには，パス一致，拡張子一致，および完全一致のマッピング規則が適用されます。それぞれのマッピング規則を次に示します。

パス一致
URLパターンとして「/」で始まり「/*」で終わる文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがURLパターンの「*」を除く文字列で始まっているときに，一致したとみなされます。また，URLパターンとして「/*」を指定した場合は，すべてのリクエストURLが一致したとみなされます。

（例）

URLパターンが「/jsp/*」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

拡張子一致
URLパターンとして「*.」で始まる文字列を指定した場合は，リクエストURLの拡張子とURLパターンの「*.」に続く文字列と同じであるときに，一致したとみなされます。

（例）

URLパターンが「*.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

完全一致
URLパターンとして「/」で始まる上記以外の文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがこのURLパターンと完全に同じであるときに，一致したとみなされます。

（例）

URLパターンが「/jsp/index.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/ jsp/index.jsp」の場合に一致したとみなされます。

(2)　HTTPレスポンス圧縮規則

圧縮するHTTPレスポンスのMedia-Typeと圧縮しきい値を指定します。圧縮しきい値（バイト単位）は，100から2147483647までの整数値で指定します。

パラメタ指定時の規則を示します。

Media-Typeにアスタリスク（*）を指定した場合は，すべてのMedia-Typeを表します。ただし，Media-Typeごとの指定がある場合は，Media-Typeごとの指定が優先されます。

Media-Typeは，大文字と小文字が区別されません。

Media-Typeと圧縮しきい値は，半角のコロン（:）で区切ります。

複数指定する場合は半角のセミコロン（;）で区切ります。

同じMedia-Typeを複数指定した場合はあとに指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

4.12.5　HTTPレスポンス圧縮機能を使用するDDの定義例

ここでは，次に示すそれぞれの場合を例に，HTTPレスポンス圧縮機能を使用するDDの定義例を示します。

HTTPレスポンスのボディサイズで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

圧縮条件を組み合わせて指定する場合

＜この項の構成＞

(1)　HTTPレスポンスのボディサイズで圧縮条件を指定する場合

(2)　URLパターンで圧縮条件を指定する場合

(3)　HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

(4)　圧縮条件を組み合わせて指定する場合

(1)　HTTPレスポンスのボディサイズで圧縮条件を指定する場合

HTTPレスポンスのボディサイズで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!－ The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!－The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/*のアクセスに対するHTTPレスポンスで，ボディサイズが1,000バイトを超えるものを圧縮します。

(2)　URLパターンで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!－ The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /app/dir/*=rule1;
      *.html=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:100;
    </param-value>
  </init-param>
</filter>
    ：
<!－The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/app/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir/*で，ボディサイズが100バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlで，ボディサイズが100バイトを超えるHTTPレスポンス

(3)　HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合の定義例を示します。

<web-app>
    ：
<!－ The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /*=rule1;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      text/html:500;
      application/pdf:1000;
    </param-value>
  </init-param>
</filter>
    ：
<!－The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例はURLパターンが/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

Media-Typeがtext/htmlでボディサイズが500バイトを超えるHTTPレスポンス

Media-Typeがapplication/pdfでボディサイズが1,000バイトを超えるHTTPレスポンス

(4)　圧縮条件を組み合わせて指定する場合

次に示す例のように，圧縮条件を組み合わせて定義することもできます。

<web-app>
    ：
<!－ The filter for Response Compression Filter -->
<filter>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
  <init-param>
    <param-name>url-mapping</param-name>
    <param-value>
      /app/dir1/*=rule1;
      /app/dir2/*=rule2;
      *.html=rule3;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule1</param-name>
    <param-value>
      *:500;
      application/pdf:1000;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule2</param-name>
    <param-value>
      application/pdf:2000;
    </param-value>
  </init-param>
  <init-param>
    <param-name>rule3</param-name>
    <param-value>
      *:100;
    </param-value>
  </init-param>
</filter>
    ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
  <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
  <url-pattern>/app/*</url-pattern>
</filter-mapping>
    ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf以外，ボディサイズが500バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf，ボディサイズが1,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir2/*でMedia-Typeがapplication/pdf，ボディサイズが2,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlでボディサイズが100バイトを超えるHTTPレスポンス

4.13　Webコンテナのセキュリティ管理

Webコンテナではセキュリティの機能として，SSLによる暗号化，ロールに基づくユーザ認証，およびWebコンテナの実行時の保護機能が提供されています。

＜この節の構成＞

4.13.1　SSL使用による認証情報とデータの暗号化

4.13.2　ロールに基づくWebコンテナのユーザ認証

4.13.3　SecurityManagerによるWebコンテナの実行時の保護

4.13.1　SSL使用による認証情報とデータの暗号化

SSLをサポートするWebサーバとの連携では，WebサーバとWebクライアント間のSSLによる暗号化が有効になります。

＜この項の構成＞

(1)　Webサーバの認証機能

(2)　通信路のセキュリティレベルの要請

(3)　SSLで使用された証明書情報の取得

(1)　Webサーバの認証機能

Webサーバの機能には，サーバ認証の機能とクライアント認証の機能があります。

サーバ認証

サーバ認証では，サーバにインストールされた鍵交換用の証書を用いて，ブラウザからサーバあてに共通鍵の基となる乱数情報を暗号化して送ります。

この暗号を解くための秘密鍵は，鍵交換用の証書の持ち主であるサーバだけが知っているので，クライアントから見て正当なサーバの場合だけ，ハンドシェイクが成立します。この過程では，サーバは電子署名をしませんが，ハンドシェイクの成立後にサーバが正当であるかどうかの見直しができます。

クライアント認証

クライアント認証では，サーバからブラウザに乱数データを送ってクライアントで電子署名を付与させて，ブラウザにインストールされた電子署名用の証書とともにサーバに送り返させます。

乱数データにブラウザが電子署名を付けて見せることで，ブラウザ自身が秘密鍵を保有していることをサーバに証明します。これによって，サーバ側では，クライアントが証明書に対応した秘密鍵を所有していることを確認できます。

なお，ここで説明するSSL関連の機能を使用する場合，あらかじめWebサーバであるHitachi Web ServerまたはMicrosoft IISにSSLの設定をしておく必要があります。Hitachi Web ServerまたはMicrosoft IISのSSLの設定方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　通信路のセキュリティレベルの要請

WebアプリケーションからWebコンテナに対して，通信路の暗号化レベルの要請をします。通信路の暗号化レベルの要請は，Webサーバと連携する場合に使用できます。

暗号化レベルには，保護なし（NONE），改ざん防止（INTEGRAL），または秘匿（CONFIDENTIAL）の3段階を指定できます。暗号化レベルに，改ざん防止または秘匿が指定された場合に，SSLが使用されます。

この機能を使用すると，保護が要求されたページに対してアクセスできるのは，SSLを使用したアクセスだけに限定できます。保護が要請されたページに対してブラウザがHTTPでリクエストを送った場合，Webコンテナはブラウザに対してHTTPSで同じページに再度アクセスを要求するHTTPレスポンスを返します。その結果，ブラウザはHTTPSで同じページにアクセスし直します。なお，セキュリティレベルの設定は，Webアプリケーション全体だけではなく，Webアプリケーション内の一部のページに対しても指定できます。これによって，HTTPS以外での該当ページへのアクセスを防止します。

通信路の暗号化レベルの要請は，J2EEアプリケーションに含まれるWebアプリケーションのDD（WEB-INF/web.xml）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

Webサーバと連携している場合で，転送先のHTTPSのポート番号を設定していない場合，保護が要請されたページに対してアクセスすると403エラーになります。

なお，インプロセスHTTPサーバまたは簡易Webサーバを使用している場合は転送先のHTTPSのポート番号の設定内容にかかわらず，保護が要請されたページにはアクセスできません。403エラーになります。

転送先のHTTPサーバのポート番号の設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　SSLで使用された証明書情報の取得

サーブレットのAPIによって，ハンドシェイクで用いられた証書についての情報，およびハンドシェイクの結果選択された暗号化アルゴリズムについての情報を取得できます。

クライアント認証を用いた場合，クライアントが提示したX.509証書に記載された事項がjava.security.cert.X509Certificateクラスのオブジェクトとして取得できます。

なお，クライアント証明書情報をサーブレット内で取得できるのは，SSLのクライアント認証をした場合だけです。SSLのクライアント認証をする場合，Webサーバで設定する必要があります。

また，WebサーバにMicrosoft IISを使用してWebコンテナと連携している場合，Servlet v2.3仕様で定められている「javax.servlet.request.cipher_suite」によるSSL通信時の暗号化アルゴリズムの取得はできません。

4.13.2　ロールに基づくWebコンテナのユーザ認証

Webコンテナはロールという仕組みに基づいて認証処理をします。ロールは，ユーザを管理するための単位です。各ユーザに一つ以上設定されます。一方，Webアプリケーションではコンテキスト内の特定のURLごとに，そのURLへアクセスするのに必要なロールを定義できます。認証処理は，Webクライアントが制限されたURLへリクエストをする場合に，次に示す二つの段階を踏みます。

認証によるリクエストが正当なユーザによるものであるかの判定

ユーザに設定されたロールと，アクセスするのに必要なロールが一致するかの判定

両方の判定で正当と認められたユーザだけが，制限されたURLへアクセスできます。

アクセスするのに必要なロールは，J2EEアプリケーションに含まれるDD（WEB-INF/web.xml）内の<security-constraint>タグに指定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　ユーザ情報の管理

(2)　コンテナセキュリティとアクセス権管理

(3)　プログラムセキュリティ

(4)　認証機能を併用するときの注意

(1)　ユーザ情報の管理

Webコンテナでは，各ユーザのユーザ名，パスワード，および所属するロールを，J2EEサーバ付属のユーザ管理機能によって定義し，保持・管理します。

(2)　コンテナセキュリティとアクセス権管理

Webコンテナでは，Webクライアントから特定のURLへのアクセスを制限できます。

特定のURLへのアクセスを制限するには，DD（WEB-INF/web.xml）に次に示す情報を記述します。

アクセスの制限対象となるURLパターン

アクセスするのに必要なロールなどのセキュリティ定義情報

ユーザに定義されたロールを取得するための認証方式

Webクライアントが認証に失敗した場合，またはユーザがアクセスするのに必要なロールを持たない場合には，アクセス制限対象となっているURLパターンへのアクセスはエラーになります。なお，認証に成功したクライアントは，セッションの有効期間内には再度認証の対象になることはありません。

セキュリティ定義情報，および認証方式を定義する方法は，Servlet API 2.3で規定されているDD（WEB-INF/web.xml）の仕様に従います。

なお，Webコンテナでの認証方式は，Basic認証とForm認証とがあります。これらは，J2EEアプリケーションに含まれるDD（WEB-INF/web.xml）に<login-config>タグを追加することで定義できます。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

WebサーバにHitachi Web ServerまたはMicrosoft IISを使用する場合，WebコンテナによるBasic認証を正しく動作させるには，Webサーバ認証機能を解除しておく必要があります。

手順の詳細については，マニュアル「Cosminexus　システム構築ガイド」のWebサーバ（Hitachi Web ServerまたはMicrosoft IIS）に関する項目を参照してください。

(3)　プログラムセキュリティ

DD（WEB-INF/web.xml）によってBasic，またはForm認証によるアクセス制限が設定されたサーブレット，JSPでは，HttpServletRequestの次に示すAPIを使用することで，ログインしたユーザのユーザ名やロール名などに応じて処理を切り替えるなど，プログラムレベルでのより細かいセキュリティ処理を行えます。

getRemoteUser()

isUserInRole()

getUserPrincipal()

これらのAPIの詳細については，Java Servlet Specification v2.3を参照してください。

(4)　認証機能を併用するときの注意

ここでは，Webコンテナの認証機能と，Webサーバの認証機能を併用するときの注意について説明します。

(a)　認証の順序

Webコンテナが提供する認証機能とWebサーバの認証機能※を併用した場合，次の順序で認証が実施されます。

Webサーバでの認証

Webコンテナでの認証

注※

Webサーバの認証機能とは，Webサーバの基本認証，SSLのサーバ認証，SSLのクライアント認証を指します。Web認証機能の併用とは，Webコンテナが提供する認証機能を使用している場合に，Webサーバの基本認証，SSLのサーバ認証，SSLのクライアント認証のどれか一つ以上を使用していることを指します。

(b)　Webサーバの基本認証とWebコンテナのBasic認証を併用するときの注意

Webサーバの基本認証とWebコンテナのBasic認証を併用した場合は，Webサーバで認証されたユーザ名とパスワードがWebコンテナに引き継がれます。このため，WebサーバとWebコンテナには，共通のユーザ情報を定義する必要があります。

なお，Webサーバの認証後，Webコンテナでの認証の状況によっては，Webコンテナの動作が異なります。Webコンテナでの動作について次に示します。

Webサーバで認証されたユーザが，Webコンテナで認証されない場合
Webコンテナにユーザ名・パスワード入力のダイアログが表示されるので，そこにWebサーバとWebコンテナ共通のユーザ名・パスワードを入力します。

Webサーバで認証されたユーザが，Webコンテナにアクセスするのに必要なロールを持っていない場合
アクセス制御対象となっているURLパターンへのアクセスはエラーとなります。

Webサーバで認証されたユーザが，Webコンテナにアクセスするのに必要なロールを持っている場合
ユーザ名・パスワードの入力ダイアログが表示されることなく，アクセス制限対象となっているURLパターンへアクセスできます。

(c)　WebサーバにMicrosoft IISを使用している場合の注意

Webコンテナの認証を使用する場合，Microsoft IISで提供する次の認証機能には制限があります。

ダイジェスト認証
Webコンテナでの認証機能の使用の有無にかかわらず，ダイジェスト認証は使用できません。Microsoft IISで，必ずダイジェスト認証の設定を解除してください。

統合Windows認証
WebコンテナのBasic認証を使用する場合は，統合Windows認証は使用できません。Microsoft IISで，統合Windows認証の設定を解除してください。

4.13.3　SecurityManagerによるWebコンテナの実行時の保護

Java2のSecurityManagerに基づいたWebコンテナの実行時保護を実現します。これによって，次に示すような現象を防ぐことができます。

内部でSystem.exit()などを発行するような，不正なサーブレット，JSPによってWebコンテナ全体が勝手に終了する。

システムプロパティなどを勝手に書き換えるような不正なサーブレット，JSPによって，Webコンテナの実行に不具合が生じる。

なお，Webコンテナの保護はデフォルトで有効になっています。使用しない場合は，J2EEサーバを開始するcjstartsvコマンドに-nosecurityオプションを指定します。

4.14　EJBコンテナとの連携

WebコンテナはEJBコンテナと連携して，J2EEサーバとして動作します。ここでは，Enterprise Beanの呼び出しについて説明します。なお，Enterprise Beanを呼び出すには，ビジネスインタフェースを使用することもできます。

＜この節の構成＞

4.14.1　Enterprise Beanの呼び出し方法

4.14.2　Enterprise Bean呼び出しの準備

4.14.1　Enterprise Beanの呼び出し方法

Enterprise Beanの呼び出しは，ルックアップを使用する方法とDIを使用する方法があります。ルックアップを使用する場合，呼び出し方法はCORBAネーミングサービスの切り替え機能を利用するかどうかで異なります。

CORBAネーミングサービスの切り替え機能を利用する場合，または同じEARに含まれるEnterprise Beanを呼び出す場合

呼び出し対象のEnterprise Beanが同一のEARに含まれている場合，次の例に示すようにEnterprise Beanを呼び出します。

呼び出し対象のEnterprise Beanが同一のEARに含まれていない場合でも，CORBAネーミングサービスの切り替え機能を使用して，次に示すようにEnterprise Beanを呼び出すことができます。CORBAネーミングサービスの切り替え機能については，「8.6　CORBAネーミングサービスの切り替え」を参照してください。

例：

Context ctx = new InitialContext();
Object o = ctx.lookup("java:comp/env/ejb/cart");
CartHome h = (CartHome)PortableRemoteObject.narrow(o, CartHome.class);
Cart c = h.create();
c.call();

CORBAネーミングサービスの切り替え機能を利用しないで別EARに含まれるEnterprise Beanを呼び出す場合

CORBAネーミングサービスの切り替え機能を利用しない場合で，呼び出し対象のEnterprise Beanが別のEARに含まれているとき，次の例に示すようにEnterprise Beanを呼び出します。例を次に示します。

例：

Context ctx = new InitialContext();
Object o =
ctx.lookup("HITACHI_EJB/SERVERS/MyServer/EJB/APName/Cart");
CartHome h = (CartHome)PortableRemoteObject.narrow(o, CartHome.class);
Cart c = h.create();
c.call();

4.14.2　Enterprise Bean呼び出しの準備

Enterprise Beanの呼び出しを利用する場合，該当Webアプリケーションをデプロイする前に，J2EEサーバからRMI-IIOPのスタブ（stubs.jar），およびRMI-IIOPインタフェースを取得し，WebアプリケーションのWEB-INF/libディレクトリに格納します。

また，複数のRMI-IIOPのスタブ（stubs.jar）を格納する場合，名前の重複を避けるためにWEB-INF/libディレクトリに格納する前に適当な名前に変更してください。

なお，RMI-IIOPのスタブについては，J2EEサーバのダイナミッククラスローディングを利用できます。ダイナミッククラスローディングの詳細については，「6.6.2　ダイナミッククラスローディング」を参照してください。

WARからEJBを呼び出す場合は，WARのDDにejb-refを定義する必要があります。ただし，アノテーションを使用して参照を定義している場合は，web.xmlに参照を定義する必要はありません。WARからEJBを呼び出すときの留意点を次に示します。

WARから同一アプリケーション内のEJBを呼び出す場合は，WARに，スタブおよびリモートインタフェースを含める必要はありません。

WARから別アプリケーションで動作するEJBを呼び出す場合，または別J2EEサーバで動作するEJBを呼び出す場合には，リモートインタフェースとスタブが必要になります。WARにリモートインタフェースを含めて，usrconf.propertiesにejbserver.deploy.stub.generation.scope=appを指定すると，J2EEアプリケーションの開始時にスタブが自動生成されます。

4.15　データベースとの接続

Webコンテナを利用している場合，J2EEサービスのリソースアダプタを使用して，データベースにアクセスできます。なお，リソースアダプタを通じてデータベースにアクセスする場合は，DB Connectorを使用します。データベースへのアクセス時には，次に示す機能を利用できます。

JDBCコネクションプーリング

JDBCコネクションシェアリング

分散トランザクション

データベースとの接続の詳細については，「9.　リソース接続とトランザクション管理」を参照してください。また，データベース接続するためのリソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

4.16　Webコンテナによるスレッドの作成

Webコンテナでは，Webサーバ連携のためのスレッド，Webアプリケーションのためのスレッドなどを作成します。これらのスレッドに対して，システムのリソースが十分であるか検討してください。

なお，Cosminexusでは，サーブレットおよびJSPからスレッド（ユーザスレッド）を作成して使用することもできます。ユーザスレッドで使用できるApplication Serverの機能の詳細については，「4.21　ユーザスレッドで使用できるApplication Serverの機能」を参照してください。

ここでは，Webコンテナが作成するスレッドについて説明します。

＜この節の構成＞

4.16.1　作成するスレッドの種類と数

4.16.2　作成するスレッドの総数

4.16.1　作成するスレッドの種類と数

Webコンテナが作成するスレッドを次の表に示します。

表4-28　Webコンテナが作成するスレッド

スレッドの分類 | 参照先
Webコンテナの簡易Webサーバ用のスレッド | (1)
Webサーバ連携機能を使用するためのスレッド※1 | (2)
インプロセスHTTPサーバを使用するためのスレッド※2 | (3)
Webアプリケーションのためのスレッド | (4)
管理用コンテキストのためのスレッド | (5)
レスポンス送信時のタイムアウトを監視するためのスレッド | (6)

注※1

Webサーバ連携機能を使用する場合に作成されるスレッドです。

注※2

インプロセスHTTPサーバを使用する場合に作成されるスレッドです。

＜この項の構成＞

(1)　Webコンテナの簡易Webサーバ用のスレッド（必須）

(2)　Webサーバ連携機能を使用するためのスレッド

(3)　インプロセスHTTPサーバを使用するためのスレッド

(4)　Webアプリケーションのためのスレッド

(5)　管理用コンテキストのためのスレッド

(6)　レスポンス送信時のタイムアウトを監視するためのスレッド

(1)　Webコンテナの簡易Webサーバ用のスレッド（必須）

簡易Webサーバ用のスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

TCPのコネクション接続要求を受信するスレッド，および受信したリクエストの処理用スレッドを作成します。

スレッドの数

TCPのコネクション接続要求を受信するスレッドは，1スレッドです。簡易Webサーバが受信したリクエストの処理用スレッドは，最小5スレッド，最大100スレッドです。

リクエスト処理用スレッドは，起動時に5スレッド作成し，同時実行スレッド数が起動済みスレッド数を超えた場合，100スレッドまで作成されます。

なお，Webコンテナの簡易Webサーバは，必ず使用します。

(2)　Webサーバ連携機能を使用するためのスレッド

Webサーバとの連携に使用するスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

リダイレクタからのコネクション接続要求を受信するスレッド，およびリダイレクタから受信したリクエストの処理用スレッドを作成します。

スレッドの数

リダイレクタからのコネクション接続要求を受信するスレッドは，1スレッドです。リダイレクタから受信したリクエストの処理用スレッドは，WebサーバとWebコンテナとのコネクション数分スレッドを作成します。

リダイレクタから受信したリクエスト処理用スレッドは，起動時に，usrconf.propertiesのwebserver.connector.ajp13.max_threadsキーに指定した数分作成します（webserver.connector.ajp13.max_threadsキーのデフォルトは10）。

(3)　インプロセスHTTPサーバを使用するためのスレッド

インプロセスHTTPサーバ用のスレッドとして，Webコンテナが作成するスレッドとスレッド数を次に示します。

作成するスレッド

リクエスト処理スレッド，およびリクエスト処理スレッド数の監視用スレッドを作成します。

スレッドの数

Webクライアントまたはプロキシサーバからの接続数と同じ数のリクエスト処理スレッドを作成します。リクエスト処理スレッドは，J2EEサーバ起動時に，usrconf.propertiesのwebserver.connector.inprocess_http.init_threadsキーに指定した数分作成します（webserver.connector.inprocess_http.init_threadsキーのデフォルトは10）。同時実行スレッド数がJ2EEサーバ起動時に作成したスレッド数を超えた場合，Webクライアントからの接続数の最大値を上限として，リクエスト処理スレッドを作成します（webserver.connector.inprocess_http.max_connectionsキーのデフォルトは100）。

また，リクエスト処理スレッド数の監視用スレッドを1スレッド作成します。

(4)　Webアプリケーションのためのスレッド

Webアプリケーション単位に，セッションの有効期限監視スレッドを作成します。最小1スレッド，最大3スレッドです。

(5)　管理用コンテキストのためのスレッド

管理用コンテキストを二つ生成するため，2スレッド作成します。

(6)　レスポンス送信時のタイムアウトを監視するためのスレッド

レスポンス送信時のタイムアウトを有効にすると，送信タイムアウトを監視するためのスレッドを1スレッド作成します。

4.16.2　作成するスレッドの総数

Webコンテナがデフォルトの設定でプロセス起動時に作成するスレッドの総数を，Webサーバと連携する場合と，インプロセスHTTPサーバを使用する場合に分けて示します。ただし，この数値にはWebコンテナ以外のスレッド，およびJavaVMが作成するスレッドは含まれていません。

＜この項の構成＞

(1)　Webサーバと連携する場合

(2)　インプロセスHTTPサーバを使用する場合

(1)　Webサーバと連携する場合

Webサーバと連携する場合の作成するスレッドの総数について説明します。また，Webサーバ連携に使用するスレッド数についても説明します。

(a)　作成するスレッドの総数

作成するスレッドの総数は，レスポンス送信時のタイムアウトを設定しているかどうかによって異なります。

レスポンス送信時のタイムアウトを設定しているとき

スレッド総数=A＋B＋C＋D＋E

レスポンス送信時のタイムアウトを設定していないとき

スレッド総数=A＋B＋C＋D

（凡例）

A：Webコンテナの簡易Webサーバ用のスレッド数

B：Webサーバとの連携に使用するスレッド数

C：Webアプリケーション単位のスレッド数

D：管理用コンテキストのスレッド数

E：レスポンス送信時のタイムアウトを監視するためのスレッド数

このため，Webサーバ連携の場合のプロセス起動時のスレッド総数は次のようになります。

レスポンス送信時のタイムアウトを設定しているときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2＋1

=20＋Webアプリケーション数

レスポンス送信時のタイムアウトを設定していないときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2

=19＋Webアプリケーション数

プロセス起動後，Webサーバとのコネクション数，簡易Webサーバの同時実行数によってスレッド数が増加します。

(b)　Webサーバとの連携に使用するスレッド数

Webサーバ連携機能を使用する場合のリクエスト処理スレッドは，Webコンテナ起動時にusrconf.propertiesのwebserver.connector.ajp13.max_threadsキーに指定した数分作成し，以降はリダイレクタからのコネクション数分作成します。そのため，リクエスト処理スレッド数の最大数はWebサーバの最大接続数に依存します。

なお，リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断された場合は，Webサーバの最大接続数以上にリクエスト処理スレッドが作成されます。リクエスト処理用スレッド数の最大値を算出する式を次に示します。

Hitachi Web Serverを使用している場合
リクエスト処理スレッド数の最大値＝A＋B

（凡例）

A：日立WebサーバのThreadsPerChildディレクティブの設定値

B：リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断されたときの，実行中のリクエスト数（最大値はwebserver.connector.ajp13.max_threadsの設定値）

Microsoft IISを使用している場合
リクエスト処理スレッド数の最大値＝A×B＋C

（凡例）

A：Microsoft IISのスレッド数

B：Microsoft IISのプロセス数

C：リダイレクタ－Webコンテナ間のコネクションがタイムアウトによって切断されたときの，実行中のリクエスト数（最大値はwebserver.connector.ajp13.max_threadsの設定値）

(2)　インプロセスHTTPサーバを使用する場合

作成するスレッドの総数は，レスポンス送信時のタイムアウトを設定しているかどうかによって異なります。

レスポンス送信時のタイムアウトを設定しているとき

スレッド総数=A＋B＋C＋D＋E

レスポンス送信時のタイムアウトを設定していないとき

スレッド総数=A＋B＋C＋D

（凡例）

A：Webコンテナの簡易Webサーバを使用する場合のスレッド数

B：インプロセスHTTPサーバを使用する場合のスレッド数

C：Webアプリケーション単位のスレッド数

D：管理用コンテキストのスレッド数

E：レスポンス送信時のタイムアウトを監視するためのスレッド数

このため，インプロセスHTTPサーバを使用する場合のプロセス起動時のスレッド総数は次のようになります。

レスポンス送信時のタイムアウトを設定しているときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2＋1

=20＋Webアプリケーション数

レスポンス送信時のタイムアウトを設定していないときのスレッド総数

=6＋11＋（1×Webアプリケーション数）＋2

=19＋Webアプリケーション数

J2EEサーバ起動後，Webクライアントとのコネクション数，簡易Webサーバの同時実行数によってスレッド数が増加します。

4.17　同時実行スレッド数の制御

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定できます。これによって，スラッシングなどによるパフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスのチューニングができます。

ここでは，同時実行スレッド数の制御の単位と設定パラメタについて説明します。

＜この節の構成＞

4.17.1　スレッド数を制御する単位

4.17.2　同時実行スレッド数制御のパラメタ

4.17.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

4.17.1　スレッド数を制御する単位

同時に実行するスレッド数を制御するには，Webコンテナ単位で制御する方法，Webアプリケーション単位で制御する方法，およびURLグループ単位で制御する方法の3種類あります。

Webコンテナ単位での同時実行スレッド数制御
Webコンテナ上のWebアプリケーション全体で，同時にリクエストを処理するスレッド数を設定します。

Webアプリケーション単位での同時実行スレッド数制御
Webコンテナ上のWebアプリケーションごとに，同時にリクエストを処理するスレッド数を設定します。Webコンテナ単位での同時実行スレッド数制御より細かい単位でスレッド数を制御できます。

URLグループ単位での同時実行スレッド数制御
Webアプリケーション内のサーブレットやJavaBeansなどの業務ロジックに対応するURLごとに，同時にリクエストを処理するスレッド数を設定します。特定のURLへのリクエストを処理する業務ロジックをURLグループといいます。URLグループ単位で，同時実行スレッド数を制御するので，Webアプリケーション単位の制御より細かい単位でスレッド数を制御できます。

それぞれの制御単位の関係について次の図に示します。

図4-22　同時実行スレッド数制御の単位の関係

図に示すように，同時実行スレッド数制御のいちばん大きな単位は，Webコンテナ単位となります。Webコンテナ内のWebアプリケーションごとにスレッド数を制御する場合はWebアプリケーション単位で設定します。さらに，Webアプリケーション内のURLグループごとにスレッド数を制御する場合はURLグループ単位で設定します。スレッド数制御の最小単位はURLグループ単位となります。

スレッド数の制御には包含関係があるので，Webアプリケーション単位でスレッド数を制御する場合はWebコンテナ単位での設定も必要になります。また，URLグループ単位でスレッド数を制御する場合は，Webコンテナ単位およびWebアプリケーション単位での設定も必要になります。

4.17.2　同時実行スレッド数制御のパラメタ

同時実行スレッド数制御をする場合，最大同時実行スレッド数，占有スレッド数，実行待ちキューサイズなどのパラメタでスレッド数を制御します。

ここでは，スレッド数を制御するための主なパラメタについて説明します。

＜この項の構成＞

(1)　最大同時実行スレッド数

(2)　占有スレッド数

(3)　実行待ちキューサイズ

(4)　共有スレッド数

(5)　共有スレッド数の算出のしかた

(1)　最大同時実行スレッド数

最大同時実行スレッド数とは，利用できる全体のスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを最大で同時に実行できるスレッド数です。

最大同時実行スレッド数は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位で設定します。

(2)　占有スレッド数

占有スレッド数とは，利用できる全体のスレッドのうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webアプリケーション単位，およびURLグループ単位で設定することで，Webアプリケーションごと，またはURLグループごとにスレッド数を最低限確保できます。

(3)　実行待ちキューサイズ

同時実行スレッド数制御の対象となるリクエストが，同時実行スレッド数の上限に達した場合に，リクエストが入るキューサイズを指定できます。キューサイズには，キューに格納するリクエストの個数を指定します。

実行待ちキューにリクエストが格納される条件を次に示します。

同時実行スレッド数＜最大同時実行スレッド数で，かつ同時実行スレッド数≧占有スレッド数の場合に，使用できる共有スレッド数がないとき

同時実行スレッド数≧最大同時実行スレッド数の場合

なお，実行待ちキューに空きがない場合は，リクエストは処理されないで，クライアントにはエラーが返ります。

実行待ちキューサイズは，Webアプリケーション単位，およびURLグループ単位で設定できます。

(4)　共有スレッド数

共有スレッド数とは，利用できるスレッドのうち，占有されないスレッド数です。共有スレッド数には，Webコンテナの共有スレッド数と，Webアプリケーションの共有スレッド数があります。

Webコンテナの共有スレッド数
Webコンテナの共有スレッド数とは，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有するスレッド数です。

Webアプリケーションの共有スレッド数
Webアプリケーションの共有スレッド数とは，Webアプリケーションに含まれるすべての処理で共有するスレッド数です。

なお，共有スレッド数は，最大同時実行スレッド数と占有スレッド数から導き出します。

共有スレッド数の算出のしかたについては，「(5)　共有スレッド数の算出のしかた」を参照してください。

(5)　共有スレッド数の算出のしかた

ここでは，Webコンテナの共有スレッド数と，Webアプリケーションの共有スレッド数の算出のしかたについて説明します。なお，Webアプリケーション単位での同時実行スレッド数制御の設定をしている場合の，Webアプリケーションの共有スレッド数は，URLグループ単位の同時実行スレッド数制御を設定しているかどうかで異なります。

また，URLグループには共有スレッド数はありません。Webアプリケーション内にURLグループ単位の同時実行スレッド数制御を設定している場合は，Webアプリケーション単位の共有スレッド数を使用します。

Webコンテナの共有スレッド数
Webコンテナ上に，占有スレッド数を設定したWebアプリケーションがある場合の共有スレッド数は，次のとおりです。

Webコンテナの共有スレッドの総数＝

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※　WebコンテナにデプロイされているすべてのWebアプリケーションに設定されている，占有スレッド数の合計となります。

各Webアプリケーションに設定した占有スレッド数は，Webアプリケーションで最低限確保するためのスレッド数です。このスレッド数は，ほかのWebアプリケーションのリクエスト処理には使用されません。

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定している場合）

Webアプリケーションの共有スレッド数＝

Webアプリケーション単位の最大同時実行スレッド数－URLグループ単位の占有スレッド数の合計※

注※　Webアプリケーション内に設定されているすべてのURLグループの占有スレッド数の合計です。

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定していない場合）

Webアプリケーションの共有スレッド数＝Webアプリケーション単位の最大同時実行スレッド数

同時実行スレッド数が，次の図に示すとおり設定されている場合の，WebコンテナおよびWebアプリケーションの共有スレッド数の算出例を説明します。

図4-23　共有スレッド数の算出例

Webコンテナの共有スレッド数＝A－（Bの合計）
この図の場合，Webコンテナの共有スレッド数は7－（2＋0）で，5になります。

Webアプリケーション1の共有スレッド数＝C－（Dの合計）
Webアプリケーション1には，URLグループ単位の占有スレッド数が指定されています。この図では，共有スレッド数は3－（2＋0）で，1になります。

Webアプリケーション2の共有スレッド数＝Webコンテナの共有スレッド数
Webアプリケーション2には，同時実行スレッド数制御の設定はありません。このため，Webアプリケーション2の共有スレッド数は，Webコンテナの共有スレッド数が適用されます。この図では，共有スレッド数は5になります。

Webアプリケーション3の共有スレッド数＝最大同時実行スレッド数
Webアプリケーション3には，URLグループ単位の占有スレッド数が指定されていません。このため，Webアプリケーション3の共有スレッド数はWebアプリケーション3の最大同時実行スレッド数が適用されます。この図では，共有スレッド数は2になります。

4.17.3　静的コンテンツやリクエストのエラー処理に使用されるスレッド数

Webサーバの最大同時接続数は，Webコンテナでのリクエスト処理のほかに，Webサーバ上に配置された静的コンテンツの処理，およびWebコンテナのリクエストを送信し，同時実行スレッド数と実行待ちキューを超えたリクエストのエラー処理に使用されます。静的コンテンツの処理および実行待ちキューを超えたリクエストのエラー処理に使用されるスレッド数は，次のとおりです。

静的コンテンツやリクエストのエラー処理に使用されるスレッド数＝

Webサーバの最大同時接続数－（Webコンテナ単位の最大同時実行スレッド数＋実行待ちキューサイズの合計）

なお，デフォルトの設定では静的コンテンツに使用されるスレッド数は割り当てられていません。静的コンテンツの処理に使用するスレッド数を確保する場合は，上記の式を満たすように実行待ちキューサイズに適切な値を設定してください。

4.18　Webコンテナ単位での同時実行スレッド数の制御

同時に実行するスレッドの数を，Webコンテナ単位で制御する方法です。通常，Webコンテナには複数のWebアプリケーションがデプロイされています。Webコンテナ単位で同時に実行できるスレッド数を制御する場合，Webコンテナに対して次のパラメタを設定します。

最大同時実行スレッド数
Webコンテナ全体で同時に実行できる最大スレッド数を設定します。ここで設定したスレッド数は，WebコンテナにデプロイされているすべてのWebアプリケーションで共有するスレッド数となります。

Webコンテナ単位での同時実行スレッド数の制御は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

Webコンテナ単位での同時実行スレッド数の制御の仕組みについて，次の図で説明します。

図4-24　Webコンテナ単位での同時実行スレッド数制御

例えば，Webコンテナに二つのWebアプリケーションがデプロイされていて，同時実行スレッド数に「5」を設定している場合，二つのWebアプリケーションで同時に実行できるスレッド数は5となります。

Webコンテナ単位に同時実行スレッド数を設定することで，Webコンテナにデプロイされた複数のWebアプリケーションのうち，一つのWebアプリケーションにアクセスが集中した場合でも，アクセスが集中しているWebアプリケーションにスレッドを割り当てることができます。この仕組みについて次の図で説明します。

図4-25　アクセスが集中したときのスレッドの扱い（Webコンテナ単位の場合）

図のように，WebコンテナにWebアプリケーションが二つデプロイされていて，同時実行スレッド数に「5」が設定されている場合に，Webアプリケーション1にリクエストが集中すると，5スレッドすべてがWebアプリケーション1に割り当てられます。

一方，Webアプリケーション2に対するリクエストは，Webアプリケーション1のリクエスト処理が完了するまで，実行待ちのキューにためられます。なお，実行待ちのキューにためられたリクエストは，リクエスト処理の完了後，順次実行されます。

4.19　Webアプリケーション単位での同時実行スレッド数の制御

同時に実行するスレッドの数を，Webアプリケーション単位で制御する方法です。なお，Webアプリケーション単位でスレッド数を制御するときには，Webコンテナ単位でのスレッド数制御も同時に設定する必要があります。「4.18　Webコンテナ単位での同時実行スレッド数の制御」もあわせて参照してください。

Webアプリケーション単位での同時実行スレッド数の制御の設定は，J2EEアプリケーションに含まれるWebアプリケーションの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

4.19.1　同時実行スレッド数の制御の概要（Webアプリケーション単位）

4.19.2　Webアプリケーション単位の設定パラメタ

4.19.3　同時実行スレッド数および実行待ちキューサイズの設定例

4.19.4　同時実行スレッド数の動的変更

4.19.5　同時実行スレッド数制御の注意事項

4.19.1　同時実行スレッド数の制御の概要（Webアプリケーション単位）

Webコンテナ単位より細かい粒度で同時実行スレッド数を制御したい場合，Webアプリケーション単位で同時実行スレッド数を制御します。

Webアプリケーション単位で同時実行スレッド数を設定することで，Webアプリケーションごとの同時実行スレッド数に上限が設けられます。これによって，特定のWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有するのを防ぎ，また，ほかの業務も滞りなく実行できるようになります。

なお，Webアプリケーション単位での同時実行スレッド数の設定の指針については，マニュアル「Cosminexus　システム設計ガイド」のWebアプリケーションの同時実行数の制御を，パラメタの設定方法については，マニュアル「Cosminexus　システム構築ガイド」の同時実行スレッド数の制御の設定を参照してください。

4.19.2　Webアプリケーション単位の設定パラメタ

ここでは，Webアプリケーション単位でスレッド数を制御する場合の設定について説明します。Webアプリケーション単位でスレッド数を制御する場合は，次の設定が必要になります。

Webコンテナ単位の同時実行スレッド数制御の設定
Webコンテナ単位の最大同時実行スレッド数を設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。
Webコンテナ単位での最大同時実行スレッドについては，「4.18　Webコンテナ単位での同時実行スレッド数の制御」を参照してください

Webアプリケーション単位の同時実行スレッド数制御の設定
同時実行スレッド数を制御したいWebアプリケーションに対して，次に示すパラメタを設定します。

最大同時実行スレッド数
Webアプリケーションで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数
Webアプリケーションの占有スレッド数を設定します。

実行待ちキューサイズ
Webアプリケーションの実行待ちキューサイズを設定します。

デフォルトの実行待ちキューサイズ
Webアプリケーション単位の同時実行スレッド数制御を設定していないWebアプリケーションのための，実行待ちキューサイズを設定します。

以降で，Webアプリケーション単位での同時実行スレッド数制御の設定項目の詳細を説明します。

＜この項の構成＞

(1)　Webアプリケーションの最大同時実行スレッド数

(2)　Webアプリケーションの占有スレッド数

(3)　Webアプリケーションの実行待ちキューサイズ

(1)　Webアプリケーションの最大同時実行スレッド数

Webアプリケーション単位の最大同時実行スレッド数は，値を設定している場合は，その数が適用されます。ここでは，同時実行スレッド数を設定していないWebアプリケーションの最大同時実行スレッド数，および占有スレッド数を設定していないWebアプリケーションでの最大同時実行スレッド数の考え方について説明します。

(a)　同時実行スレッド数制御を設定していないWebアプリケーションの場合

最大同時実行スレッド数を設定していないWebアプリケーションの，最大同時実行スレッド数は次のとおりです。

最大同時実行スレッド数＝

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※

WebコンテナにデプロイされているすべてのWebアプリケーションに設定されている，占有スレッド数の合計となります。

(b)　占有スレッド数を設定していないWebアプリケーションの場合

Webアプリケーション単位の同時実行スレッド数制御の設定では，占有スレッド数の設定は任意となります。占有スレッド数を設定していないWebアプリケーションの最大同時実行スレッド数は，次のどちらかの値のうち，小さい方の値が適用されます。

最大同時実行スレッド数＝

Webアプリケーションに設定した最大同時実行スレッド数

　または

Webコンテナの最大同時実行スレッド数－Webアプリケーション単位の占有スレッド数の合計※

注※

WebコンテナにデプロイされているすべてのWebアプリケーション設定されている，占有スレッド数の合計となります。

(2)　Webアプリケーションの占有スレッド数

Webコンテナ単位での同時実行スレッド数だけを設定している場合，Webコンテナ内のほかのWebアプリケーションへのアクセスが集中すると，スレッドはアクセスが集中しているアプリケーションに使用されます。占有スレッド数を設定することで，Webアプリケーション内での実行に必要なスレッド数を最低限確保できるので，Webコンテナ内のほかのWebアプリケーションへのアクセスが集中した場合でも，リクエストが待ち状態になることなく，実行できます。

(a)　占有スレッド数の設定の有無によるWebアプリケーションの動作

Webアプリケーションの占有スレッド数について次の図に示します。この図を使用して，占有スレッド数を設定したWebアプリケーションと占有スレッド数を設定していないWebアプリケーションの動作を説明します。

図4-26　Webアプリケーションの占有スレッド数

図の内容について説明します。Webコンテナでは，Webアプリケーション1とWebアプリケーション2が動作しています。Webアプリケーション2では，Webアプリケーションでの同時実行スレッド数制御を設定していませんが，Webアプリケーション1では，Webアプリケーションでの同時実行スレッド制御を設定しています。Webアプリケーション1の最大同時実行スレッド数は3で，占有スレッド数は1に設定されています。

例えば，Webアプリケーション2にアクセスが集中した場合，Webアプリケーション1に占有スレッド数を設定していないと，すべてのスレッドがWebアプリケーション2に使用されます。図のようにWebアプリケーション1に占有スレッド数を設定することで，Webアプリケーション2へのアクセスが集中したときでも，Webアプリケーション1では1スレッドは最低限確保できます。これによって，占有スレッド数を設定しているWebアプリケーション1の処理を確実に実行できます。

このように，占有スレッド数を設定しておくと，ほかの業務へのアクセスが集中した場合でも確実に実行できます。このため，管理用アプリケーションなどの重要度の高いWebアプリケーションに対して占有スレッド数を設定しておくことをお勧めします。

なお，占有スレッド数に指定した数のスレッドは，ほかのWebアプリケーションのリクエスト処理には使用されません。また，Webアプリケーション単位の同時実行スレッド制御の設定では，占有スレッド数の設定は任意となります。

(b)　占有スレッド数と最大同時接続数

Webサーバの最大同時接続数（Webサーバ連携機能を使用する場合）またはWebクライアントからの最大同時接続数（インプロセスHTTPサーバを使用する場合）が少ないときに，占有スレッド数を設定していないWebアプリケーションへのリクエストによって最大同時接続数が占有されると，占有スレッド数を設定したWebアプリケーションにアクセスしても，Webサーバ上またはインプロセスHTTPサーバ上で実行待ちになったり，エラーになったりします。

占有スレッド数を設定したWebアプリケーションを，ほかのWebアプリケーションへのアクセス流量に依存しないで確実に実行させるためには，最大同時接続数に適切な値を設定する必要があります。最大同時接続数の設定方法を次に示します。

Webサーバの最大同時接続数の設定方法（Webサーバ連携機能を使用する場合）
Webサーバ連携機能を使用する場合，Webサーバの最大同時接続数を，次に示す値よりも大きい値にする必要があります。

Webサーバの最大同時接続数＞実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

占有スレッド数を設定する場合は，上記の式を満たすように適切な値を設定してください。
なお，Webサーバの最大同時接続数は，次の個所に設定されています。

Hitachi Web Serverを使用している場合

httpsd.confのThreadsPerChildディレクティブ（Windowsのとき）またはhttpsd.confのMaxClientsディレクティブ（UNIXのとき）

Microsoft IISを使用している場合

［インターネット サービス マネージャ］で設定したクライアントとの接続数

Hitachi Web ServerまたはMicrosoft IISを使用している場合の設定の詳細については，マニュアル「Hitachi Web Server」またはMicrosoft IISのヘルプを参照してください。

Webクライアントからの最大同時接続数の設定方法（インプロセスHTTPサーバを使用する場合）
インプロセスHTTPサーバを使用する場合，Webクライアントからの最大同時接続数を次に示す値よりも大きい値にする必要があります。

Webクライアントからの最大同時接続数＞実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数

なお，Webクライアントからの同時接続数とは，Webクライアントからの最大接続数から，接続を拒否するリクエスト数を引いた値です。詳細については，「4.3.3　Webクライアントからの同時接続数の制御」を参照してください。

(3)　Webアプリケーションの実行待ちキューサイズ

Webアプリケーションの実行待ちキューサイズを設定します。

Webアプリケーションに最大同時実行スレッド数を設定している場合，実行スレッド数が最大数に達してしまうと，リクエストはキューにためられます。このときの，実行待ちのキューのサイズを，Webアプリケーション単位で指定できます。

実行待ちキューサイズの設定は，Webアプリケーション単位での同時実行スレッド数を設定しているかどうかで異なります。

Webアプリケーション単位で同時実行スレッド数を設定している場合
Webアプリケーションごとに実行待ちキューサイズを設定できます。

Webアプリケーション単位で同時実行スレッド数を設定していない場合
Webアプリケーションで共通となる実行待ちキューサイズが使用されます。共通の実行待ちキューサイズのことを，デフォルトの実行待ちキューサイズといいます。

実行待ちキューでの動作

実行待ちキューの設定が，Webアプリケーションの実行待ちキューサイズとデフォルトの実行待ちキューサイズを含め，複数ある場合，共有スレッド数を使用して実行されるリクエストの順序は，キューのリクエストのうち，先に到着したリクエストから処理されます。

Webサーバの最大同時接続数と実行待ちキュー（Webサーバ連携機能を使用する場合）

WebサーバからWebコンテナに転送されるリクエストの多重度は，Webサーバの最大同時接続数が上限となります。このため，占有スレッド数を設定する場合には，実行待ちキューサイズはWebサーバの最大同時接続数より少ない数にしてください。

Webクライアントからの最大同時接続数と実行待ちキュー（インプロセスHTTPサーバを使用する場合）

Webクライアントからの接続数の多重度の上限は次に示す値となります。

Webクライアントからの最大同時接続数－接続を拒否するリクエスト数

このため，占有スレッド数を設定する場合には，実行待ちキューサイズはWebクライアントからの最大同時接続数より少ない値にする必要があります。

なお，Webクライアントからの最大同時接続数が「実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数」よりも大きい場合，インプロセスHTTPサーバによるWebクライアントからの同時実行数の制御は不要です。また，Webクライアントからの最大同時接続数が「実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数」よりも小さい場合，インプロセスHTTPサーバによるWebクライアントからの同時実行数の制御を実行することによって，クライアントに対して接続待ちを発生させないで即座にエラーを返すことができます。

ポイント

同時実行スレッド数が最大数に達したときのリクエストの動作

Webアプリケーション単位の同時実行スレッド数が最大数に達した場合で，キューに空きがあるときは，リクエストはキューにたまります。そして，処理中のリクエスト処理が完了したあとに，順次キューからリクエストが取り出され，実行されます。なお，キューに空きがないときは，リクエストはエラーとなり，クライアントには，HTTP 503エラーが返ります。

4.19.3　同時実行スレッド数および実行待ちキューサイズの設定例

同時実行スレッド数および実行待ちキューサイズの設定例について説明します。ここでは，Webサーバ連携機能を使用する場合の例について説明します。

＜この項の構成＞

(1)　説明で使用するWebアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

(1)　説明で使用するWebアプリケーションの設定例

この例では，Webコンテナに四つのWebアプリケーションがデプロイされていて，そのうちの二つのWebアプリケーションにWebアプリケーション単位での同時実行スレッド数制御がされているものとします。設定内容を次に示します。

Webサーバの最大同時接続数：50

Webコンテナ単位の最大同時実行スレッド数：10

デフォルトの実行待ちキューサイズ：10

Webアプリケーション単位の同時実行スレッド数制御の設定
WebアプリケーションAおよびBに，それぞれ次の設定がされているものとします。
なお，WebアプリケーションCおよびDには，Webアプリケーション単位の同時実行スレッド数制御の設定はありません。

Webアプリケーション名 | 最大同時実行スレッド数 | 占有スレッド数 | 実行待ちキューサイズ
WebアプリケーションA | 3 | 1 | 5
WebアプリケーションB | 3 | 2 | 10

Webコンテナ上に，Webアプリケーションごとの同時実行スレッド数制御の設定があるWebアプリケーションと，設定のないWebアプリケーションが混在している場合の例を，次の図に示します。

図4-27　Webアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

図4-27の設定の場合に使用できる最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズについて，Webアプリケーションごとに説明します。なお，説明の項番は，図中の項番と対応しています。

WebアプリケーションA

最大同時実行スレッド数および占有スレッド数
WebアプリケーションAでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションAの同時に実行できるスレッド数は最大で3スレッドです。そのうち，1スレッドは，WebアプリケーションAで最低限確保できる占有スレッド数となります。

実行待ちキューサイズ
WebアプリケーションAでは実行待ちキューサイズを指定しています。WebアプリケーションAで同時に3スレッド使用している場合，WebアプリケーションAへのリクエストは，最大で5個，キューにたまります。

WebアプリケーションB

最大同時実行スレッド数および占有スレッド数
WebアプリケーションBでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションBの同時に実行できるスレッド数は最大で3スレッドです。そのうち，2スレッドは，WebアプリケーションBで最低限確保できる占有スレッド数となります。

実行待ちキューサイズ
WebアプリケーションBでは実行待ちキューサイズを指定しています。WebアプリケーションBで同時に3スレッド使用している場合，WebアプリケーションBへのリクエストは，最大で10個，キューにたまります。

WebアプリケーションCおよびWebアプリケーションD
WebアプリケーションCおよびWebアプリケーションDでは，Webアプリケーション単位の同時実行スレッド制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
WebアプリケーションCおよびWebアプリケーションDでは，Webコンテナの共有スレッド数を使用します。この場合，Webコンテナの共有スレッド数は7であるため，WebアプリケーションCおよびWebアプリケーションDで，合わせて最大で7スレッド使用できます。
なお，スレッド数は，WebアプリケーションCおよびWebアプリケーションDで共有することになります。
また，同時実行スレッド数制御を設定していないため，占有スレッド数はありません。WebアプリケーションAおよびWebアプリケーションBへのアクセスが集中し，使用できるスレッドがなくなると，WebアプリケーションCおよびWebアプリケーションDの処理は実行待ちになります。

実行待ちキューサイズ
WebアプリケーションCまたはWebアプリケーションDで実行待ちが発生した場合，これらのWebアプリケーションへのリクエストは，キューにたまります。WebアプリケーションCおよびWebアプリケーションDでは実行待ちキューサイズを指定していないため，キューはデフォルトの実行待ちキューにためられます。最大で10個のリクエストがキューにたまります。

参考

Webコンテナでは，スレッドは静的コンテンツやリクエストのエラー処理にも使用されます。これらの目的で使用されるスレッド数は，次の式から求められます。

Webサーバの処理スレッド数－（Webコンテナ単位の最大同時実行スレッド数＋実行待ちキューサイズの総和※）

注※　実行待ちキューサイズの総和とは，この図の場合，Webコンテナ，WebアプリケーションA，WebアプリケーションBの実行待ちキューサイズを足した値となります。

このため，この図の例の場合，50－（10＋（10＋5＋10））となり，静的コンテンツやリクエストのエラー処理に使用されるスレッド数は，15スレッドとなります。

4.19.4　同時実行スレッド数の動的変更

Webアプリケーション単位の同時実行スレッド数の設定（最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズ）は動的に変更することもできます。これによって，稼働中のWebアプリケーションのサービスを停止することなく，同時実行スレッド数の設定を変更できます。

同時実行スレッド数の動的変更によって，次のようなことができます。

Webアプリケーション単位の同時実行スレッド数に関する性能チューニング

アクセス状況に応じた，同時実行スレッド数の設定の変更

時間帯に応じた，計画的な同時実行スレッド数の設定の変更

Webアプリケーションの同時実行スレッド数の動的変更については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

＜この項の構成＞

(1)　設定変更の例

(2)　設定変更後の動作

(3)　URLグループ単位の同時実行スレッド数制御への影響

(4)　動的変更の注意

(1)　設定変更の例

ここでは，特定のWebアプリケーションに対して，スループットを向上し，エラーとなるリクエストを減らしたい場合の，設定変更例を紹介します。この例では，Webアプリケーションの，最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズを増やしています。なお，同時実行スレッド数の動的変更では，Webコンテナ単位の最大同時実行スレッド数およびURLグループ単位の最大同時実行スレッド数は変更できません。

表4-29　同時実行スレッド数の動的変更の例

パラメタ | 変更前の設定値 | 変更後の設定値
Webコンテナ単位の最大同時実行スレッド数 | 10 | －
Webアプリケーションの設定 | 最大同時実行スレッド数 | 7 | 8
占有スレッド数 | 4 | 5
実行待ちキューサイズ | 8 | 10

（凡例）　－：設定を変更できない

(2)　設定変更後の動作

同時実行スレッド数の変更はすぐに反映されます。変更した直後に注意が必要な動作を次に示します。

最大同時実行スレッド数を変更した場合

最大同時実行スレッド数を増加させたとき
実行待ち状態のリクエストで，実行できる状態になったリクエストはすぐに実行されます。

最大同時実行スレッド数に指定しているスレッド数をすべて使用している状態で，最大同時実行スレッド数を減少させたとき
一時的に変更後の最大同時実行スレッド数を上回るリクエストが同時に実行されます。

占有スレッド数を変更した場合

Webコンテナ単位の最大同時実行スレッド数に設定した数のスレッドをすべて使用している状態で，占有スレッド数を増加させたとき
占有スレッド数を増加させたWebアプリケーションに実行待ちのリクエストがあるときは，占有スレッド数分のリクエストはすぐ実行されます。ただし，このとき，一時的にWebコンテナ単位の最大同時実行スレッド数を超えたリクエストが同時に実行されます。

占有スレッド数を減少させたとき
占有スレッド数を減少させると，すべてのWebアプリケーション単位で共有するスレッド数が増加します。このときに，実行待ち状態で，すべてのWebアプリケーション単位で共有するスレッド数の増加によって実行できる状態になったリクエストがあれば，すぐに実行されます。

実行待ちキューサイズを変更した場合

Webアプリケーション単位の実行待ちキューで，キューの上限までリクエストの待ちがある状態で，実行待ちキューサイズを減少したとき
実行待ちキューサイズを超えたリクエストはHTTP 503エラーが返ります。

(3)　URLグループ単位の同時実行スレッド数制御への影響

URLグループ単位の同時実行スレッド数制御を設定しているWebアプリケーションの同時実行スレッド数を動的に変更した場合，URLグループ単位の同時実行スレッド数の設定に影響が出ることがあります。影響が出る変更を次に示します。

Webアプリケーション単位の最大同時実行スレッド数を減らした場合

Webアプリケーション単位の最大同時実行スレッド数の減少によって，次の条件を満たしたとき，URLグループ単位の最大同時実行スレッド数は，一時的にWebアプリケーション単位の同時実行スレッド数になります。

URLグループ単位の最大同時実行スレッド数が変更される条件

URLグループ単位の最大同時実行スレッド数＞Webアプリケーション単位の最大同時実行スレッド数

ただし，URLグループ単位の最大同時実行スレッド数の設定値が変更になるわけではありません。動的変更時に設定したスレッド数までWebアプリケーション単位の最大同時実行スレッド数が減少し，URLグループ単位の最大同時実行スレッド数がWebアプリケーション単位の最大同時実行スレッド数を下回ると，URLグループ単位の最大同時実行スレッド数は設定した値で動作します。

なお，この変更によって，実行中のリクエスト処理を継続させるために，一時的に変更後のWebアプリケーション単位の最大同時実行スレッド数を上回るリクエストが同時に実行されることがあります。

Webアプリケーション単位の占有スレッド数を減らした場合

Webアプリケーション単位の占有スレッド数の減少によって，Webアプリケーション内のすべてのURLグループ単位に設定されている占有スレッド数が使用できなくなります。使用できなくなる条件を次に示します。なお，条件は，Webアプリケーション単位の最大同時実行スレッド数と占有スレッド数の関係によって異なります。

Webアプリケーション単位の最大同時実行スレッド数＝Webアプリケーション単位の占有スレッド数の場合

次に示す式を満たしたとき，URLグループ単位に設定されている占有スレッド数は使用できなくなります。

Webアプリケーション単位の占有スレッド数≦URLグループ単位の占有スレッド数の総和

Webアプリケーション単位の最大同時実行スレッド数≠Webアプリケーション単位の占有スレッド数の場合

次に示す式を満たしたとき，URLグループ単位に設定されている占有スレッド数は使用できなくなります。

Webアプリケーション単位の占有スレッド数＜URLグループ単位の占有スレッド数の総和

(4)　動的変更の注意

動的に変更できるのは，Webアプリケーション単位の同時実行スレッド数の設定です。Webコンテナ単位の同時実行スレッド数およびURLグループ単位の同時実行スレッド数は，動的に変更できません。

動的に変更された同時実行スレッド数の情報はJ2EEサーバには保存されません。このため，サービスを停止すると変更した値は無効になるので注意してください。

Webアプリケーション単位の同時実行スレッド数の動的変更によって，Webアプリケーション単位の共有スレッド数が0以下になると，Webアプリケーション内のすべてのURLグループ単位で設定している占有スレッド数が使用できなくなります。

4.19.5　同時実行スレッド数制御の注意事項

Webアプリケーション単位での同時実行スレッド数を制御する場合，次のことに注意してください。

スレッド数が，Webコンテナ単位の最大同時実行スレッド数を上回る場合
次の条件すべてを満たすときは，Webアプリケーションで最低限確保されているスレッド数だけリクエストが実施されるため，スレッド数が，一時的にWebコンテナ単位の最大同時実行スレッド数を上回るおそれがあります。

アクセスが集中したときなど，Webコンテナ単位の同時実行スレッド数に設定した数すべてを使用しているとき

占有スレッド数を設定したWebアプリケーションをデプロイしているとき

実行中のリクエスト処理スレッドが完了する前に，デプロイしたWebアプリケーションにリクエストがあったとき

制御の対象となるアクセス
サーブレット，JSPのほかに，静的コンテンツへのアクセスも，同時実行スレッド数の制御の対象となります。

カスタムエラー使用時の注意
web.xmlに<error-page>タグを使用した，カスタムエラー機能を使用している場合，エラー発生時に転送されたリクエスト処理は，同時実行スレッド数制御の対象外となります。同時実行スレッド数の制御による制限はありません。

スレッドについて
占有スレッド数は，Webアプリケーション専用のスレッドとして生成されるものではありません。ここで設定するスレッド数は，Webアプリケーションを実行するに当たり，最低限確保されるスレッド数です。
なお，リクエスト処理用のスレッドは，Webコンテナ全体で再利用されます。

Webアプリケーション単位の最大同時実行スレッド数について
Webアプリケーション単位の最大同時実行スレッド数が，Webコンテナ単位の最大同時実行スレッド数より大きな値が設定されていても，WebアプリケーションをJ2EEサーバにデプロイできます。ただし，デプロイされたWebアプリケーションの最大同時実行スレッド数は，Webコンテナ単位の最大同時実行スレッド数になるので，注意してください。

Webアプリケーション単位の共有スレッド数が0以下になる場合について
次のようなWebアプリケーションをデプロイすることで，Webアプリケーション単位の共有スレッド数が0以下になることがあります。Webアプリケーション単位の共有スレッド数が0以下になると，Webアプリケーションのデプロイに失敗するので注意してください。次のような場合で共有スレッド数が0以下になることが考えられます。

すでにURLグループ単位の同時実行スレッド数制御を設定しているWebアプリケーションがデプロイされていて，さらに占有スレッド数を設定したWebアプリケーションをデプロイしようとしている場合

デプロイするWebアプリケーションで，占有スレッド数，およびURLグループ単位の同時実行スレッド数制御を設定していて，設定段階ですでにWebアプリケーション単位の共有スレッド数が0以下となっている場合

4.20　URLグループ単位での同時実行スレッド数の制御

同時に実行するスレッドの数を，URLグループ単位で制御する方法です。なお，URLグループ単位でスレッド数を制御するときには，Webコンテナ単位，およびWebアプリケーション単位でのスレッド数制御も同時に設定する必要があります。「4.18　Webコンテナ単位での同時実行スレッド数の制御」および「4.19　Webアプリケーション単位での同時実行スレッド数の制御」もあわせて参照してください。

＜この節の構成＞

4.20.1　同時実行スレッド数の制御の概要（URLグループ単位）

4.20.2　URLグループ単位の設定パラメタ

4.20.3　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

4.20.4　URLパターンのマッピング処理

4.20.1　同時実行スレッド数の制御の概要（URLグループ単位）

Webアプリケーション単位より細かい粒度で同時実行スレッド数制御をしたい場合，URLグループ単位で同時実行スレッド数を制御します。

一つのWebアプリケーション内に処理に時間が掛かる業務ロジック（サーブレットやJavaBeans）がある場合，Webアプリケーション内の同時実行スレッド数のほとんどが使用されてしまい，ほかの業務ロジックの処理が待ち状態になるおそれがあります。このような場合にURLグループ単位の同時実行スレッド数制御を設定することで，Webアプリケーション内の業務ロジックがほかの処理に影響を与えることなく実行できます。

なお，同時実行スレッド数で制御できるURLは，RFC 2616で定義されているリクエストURIを指します。また，URLグループ単位での同時実行スレッド数の制御ができるURLは，リクエストURIのクエリ文字は含みません。例を次に示します。

制御できるHTTPリクエスト：/webapp/index.html

制御できないHTTPリクエスト：http://localhost/webapp/index.html?id=0001

なお，URLグループ単位の同時実行スレッド数の設定の指針については，マニュアル「Cosminexus　システム設計ガイド」のWebアプリケーションの同時実行数の制御を，パラメタの設定方法については，マニュアル「Cosminexus　システム構築ガイド」の同時実行スレッド数の制御の設定を参照してください。

4.20.2　URLグループ単位の設定パラメタ

ここでは，URLグループ単位でスレッド数を制御する場合の設定について説明します。URLグループ単位でスレッド数を制御する場合は，次の設定が必要になります。

Webコンテナ単位の同時実行スレッド数制御の設定
Webコンテナ単位の最大同時実行スレッド数などを設定します。なお，ここで設定した最大同時実行スレッド数は，Webコンテナ上にデプロイされているすべてのWebアプリケーションで共有します。
Webコンテナ単位での同時実行スレッド数制御の設定については，「4.18　Webコンテナ単位での同時実行スレッド数の制御」を参照してください

Webアプリケーション単位の同時実行スレッド数制御の設定
Webアプリケーション単位の同時実行スレッド数や，占有スレッド数などを設定します。なお，URLグループ単位での同時実行スレッド数を設定する場合，Webアプリケーション単位での占有スレッド数の設定は必須になります。
Webアプリケーション単位での同時実行スレッド数制御の設定については，「4.19　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

URLグループ単位の同時実行スレッド数制御の設定
URLグループ単位の同時実行スレッド数制御は，Webアプリケーション単位での同時実行スレッド数制御を設定しているWebアプリケーション内のURLグループに対して，次に示すパラメタを設定します。

URLグループ単位の同時実行スレッド数制御の定義名
同時実行スレッド数制御の単位となるURLグループの名称を設定します。

最大同時実行スレッド数
URLグループで最大で幾つのスレッドを同時に実行できるかを設定します。

占有スレッド数
URLグループの占有スレッド数を設定します。

実行待ちキューサイズ
URLグループの実行待ちキューサイズを設定します。

URLパターン
スレッド数制御の対象となるリクエストURLに振り分けるための，URLパターンを設定します。

以降で，URLグループ単位での同時実行スレッド数制御の設定項目の詳細を説明します。

＜この項の構成＞

(1)　URLグループ単位の最大同時実行スレッド数

(2)　URLグループ単位の占有スレッド数

(3)　URLグループ単位の実行待ちキュー

(4)　URLパターンの設定

(1)　URLグループ単位の最大同時実行スレッド数

URLグループ単位で使用するスレッド数は，URLグループが属するWebアプリケーションのスレッド数です。このため，URLグループ単位でスレッドを一つ使用している場合，そのURLグループを含むWebアプリケーションでもスレッドが一つ実行されていることになります。

なお，URLグループ単位の最大同時実行スレッド数を設定していないリクエストURLについては，Webアプリケーション単位の共有スレッド数が使用されます。Webアプリケーション単位の共有スレッド数は，次のようになります。

Webアプリケーション単位の共有スレッド数＝

Webアプリケーション単位の最大同時実行スレッド数※－URLグループ単位の占有スレッド数の合計

注※　ここでの最大同時実行スレッド数の値には，次の1.と2.のうち，小さい方の値が適用されます。

Webコンテナ単位の共有スレッド数

Webアプリケーション単位の最大同時実行スレッド数に設定した値

このとき，Webアプリケーション単位の共有スレッド数は1以上である必要があります。共有スレッド数が0以下になる場合は，エラーが発生します。詳細は，「4.19.5　同時実行スレッド数制御の注意事項」を参照してください。

(2)　URLグループ単位の占有スレッド数

URLグループ単位の占有スレッド数は，特定の業務ロジックをWebアプリケーション内のほかの業務ロジックの影響を受けないで実行させるために設定します。

URLグループ単位の占有スレッド数は，Webアプリケーションで設定されている占有スレッド数の範囲で指定します。このため，URLグループが含まれるWebアプリケーションで占有スレッド数を設定していない場合は，URLグループ単位でも占有スレッド数を設定できないので注意してください。

また，URLグループ単位の同時実行スレッド数制御を設定しているリクエストURLに対するリクエスト数が，URLグループ単位の占有スレッド数を超える場合で，かつURLグループ単位の最大同時実行スレッド数に満たない場合は，Webアプリケーション単位の共有スレッド数を使用してリクエストを処理します。このため，Webアプリケーション単位の共有スレッド数が少ないと，URLグループ単位の最大同時実行スレッド数は，設定値よりも少なくなることがあるので注意してください。

(3)　URLグループ単位の実行待ちキュー

URLグループ単位の実行待ちキューは，URLグループ単位の同時実行スレッド数が上限に達したときにリクエストが入るキューです。URLグループ単位の実行待ちキューは，URLグループ単位の同時実行スレッド数の制御を設定した場合に，URLグループごとに作成されます。この実行待ちキューのサイズを設定します。

リクエストは，URLグループ単位の同時実行スレッド数が上限に達していて，実行待ちキューに空きがある場合，実行待ちキューに入ります。実行待ちキューの中のリクエストは，処理中のリクエストが完了したあとに，順次実行待ちキューから取り出され，実行されます。URLグループ単位の同時実行スレッド数が上限に達していて，実行待ちキューサイズに空きがない場合はエラーとなり，クライアントにHTTPステータスコード503が返ります。

なお，URLグループ単位の実行待ちキューに入るリクエストは，デフォルトの実行待ちキューやWebアプリケーションの実行待ちキューに入ることはありません。また，URLグループ単位の同時実行スレッド数の制御で設定したリクエストURLに該当しないリクエストについては，Webアプリケーションの実行待ちキューが使用されます。

(4)　URLパターンの設定

リクエストURLを振り分けるためのURLパターンを設定します。URLパターンには，Servlet仕様のサーブレットマッピングのURLパターンが指定できます。指定できるURLパターンを次に示します。

"/"で始まる文字列
例：/index.jsp

"/"で始まり，"/*"で終わる文字列
例：/test/*

"*."始まる文字列
例：*.do

なお，リクエストURLのURLパターンとのマッピング順序については，「4.20.4　URLパターンのマッピング処理」を参照してください。

4.20.3　同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

同時実行スレッド数および実行待ちキューサイズの設定例について説明します。ここでは，Webサーバ連携機能を使用する場合の例について説明します。

＜この項の構成＞

(1)　説明で使用するWebアプリケーションの設定例

(2)　各Webアプリケーションで使用できるスレッド数

(1)　説明で使用するWebアプリケーションの設定例

この例では，Webコンテナに二つのWebアプリケーションがデプロイされていて，そのうちの一つのWebアプリケーションにWebアプリケーション単位での同時実行スレッド数制御およびURLグループ単位の同時実行スレッド数制御がされているものとします。設定内容を次に示します。

Webサーバの最大同時接続数：40

Webコンテナ単位の最大同時実行スレッド数：8

デフォルトの実行待ちキューサイズ：5

Webアプリケーション単位の同時実行スレッド数制御の設定
WebアプリケーションAに次の内容が設定されているものとします。なお，WebアプリケーションBでは，Webアプリケーション単位の同時実行スレッド数制御の設定はありません。

Webアプリケーション名 | 最大同時実行スレッド数 | 占有スレッド数 | 実行待ちキューサイズ
WebアプリケーションA | 7 | 3 | 5

URLグループ単位の同時実行スレッド数制御の設定
WebアプリケーションAでは，次に示すURLグループの設定がされているものとします。なお，Control Cには，URLグループ単位の同時実行スレッド数制御の設定はありません。

URLグループ名 | URLパターン | 最大同時実行スレッド数 | 占有スレッド数 | 実行待ちキューサイズ
Control A | /health_check.jsp | 1 | 1 | 1
Control B | /create_pdf | 3 | 2 | 5

URLグループ単位でスレッド数を制御する場合の例を，次の図に示します。

図4-28　URLグループ単位の設定例

(2)　各Webアプリケーションで使用できるスレッド数

図4-28の設定の場合に使用できる最大同時実行スレッド数，占有スレッド数，および実行待ちキューサイズについて，WebアプリケーションまたはURLグループごとに説明します。なお，説明の項番は，図中の項番と対応しています。

WebアプリケーションA
WebアプリケーションAでは同時実行スレッド数制御を設定しています。また，WebアプリケーションA内の業務ロジック（Control AおよびControl B）にはURLグループ単位の同時実行スレッド数制御を設定しています。
ここでは，WebアプリケーションAのスレッド数について説明します。

最大同時実行スレッド数および占有スレッド数
最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
WebアプリケーションAの同時に実行できるスレッド数は最大で7スレッドです。そのうち，3スレッドは，WebアプリケーションAで最低限確保できる占有スレッド数となります。

共有スレッド数
WebアプリケーションA全体で使用できる共有スレッド数は，WebアプリケーションAの最大同時実行スレッド数－占有スレッド数の合計となります。この場合7－3となるので，共有スレッド数は4となります。

実行待ちキューサイズ
WebアプリケーションAでは実行待ちキューサイズを指定しています。WebアプリケーションA全体で同時に7スレッド使用している場合，リクエストは最大で5個，実行待ちキューにたまります。なお，このキューは，Webアプリケーション内の業務ロジックのうち，URLグループ単位の同時実行スレッド数制御を設定していない，Control Cの業務ロジックへのリクエストに使用されます。

Control A（/health_check.jspへのリクエスト）

最大同時実行スレッド数および占有スレッド数
Control Aでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
Control Aでは，同時に実行できるスレッド数は最大で1スレッドです。この1スレッドはControl Aで最低限確保できる占有スレッドでもあります。なお，Control Aの占有スレッド数はWebアプリケーションAの占有スレッドのうちの一つとなります。

実行待ちキューサイズ
Control Aでは実行待ちキューサイズを指定しています。Control Aで1スレッド使用している場合，リクエストは最大で1個，実行待ちキューにたまります。

Control B（/create_pdfへのリクエスト）

最大同時実行スレッド数および占有スレッド数
Control Bでは，最大同時実行スレッド数および占有スレッド数が設定されているので，それぞれ設定された値までスレッド数を使用できます。
Control Bでは，同時に実行できるスレッド数は最大で3スレッドです。そのうち2スレッドは，Control Bで最低限確保できる占有スレッドです。なお，Control Bの占有スレッド数はWebアプリケーションAの占有スレッドのうちの二つとなります。

実行待ちキューサイズ
Control Bでは実行待ちキューサイズを指定しています。Control Bで3スレッド使用している場合，リクエストは最大で5個，実行待ちキューにたまります。

Control Cの処理
WebアプリケーションA内の，Control Cへのリクエストに対しては，同時実行スレッド数制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
WebアプリケーションAの共有スレッド数が最大同時実行スレッド数になります。WebアプリケーションAの共有スレッド数は4スレッドであるため，Control Cの処理の最大同時実行スレッド数は4になります。
また，同時実行スレッド数制御を設定してないため，占有スレッド数はありません。このため，Control AまたはBへのアクセスが集中し，WebアプリケーションA内で使用できるスレッドがなくなると，Control Cの業務ロジックの処理は実行待ちになります。

実行待ちキューサイズ
Control Cの業務ロジックの処理で実行待ちが発生した場合，これらの処理へのリクエストは，キューにたまります。Control Cの業務ロジックでは実行待ちキューサイズを指定していないため，キューはWebアプリケーションAの実行待ちキューにためられます。リクエストは，最大で5個，キューにたまります。

WebアプリケーションB
WebアプリケーションBでは，Webアプリケーション単位の同時実行スレッド制御を設定していません。
このため，次のように動作します。

最大同時実行スレッド数
Webコンテナの共有スレッド数が最大同時実行スレッド数になります。Webコンテナの共有スレッド数は，次の式で求められます。
　Webコンテナの最大同時実行スレッド数－WebアプリケーションAの占有スレッド数
この例の場合，8－3となるため，WebアプリケーションBの最大同時実行スレッド数は5になります。

実行待ちキューサイズ
WebアプリケーションBで実行待ちが発生した場合，WebアプリケーションBへのリクエストは，キューにたまります。WebアプリケーションBでは実行待ちキューサイズを指定していないため，キューはデフォルトの実行待ちキューにためられます。リクエストは，最大で5個，キューにたまります。

参考

Webコンテナでは，スレッドは静的コンテンツやリクエストのエラー処理にも使用されます。これらの目的で使用されるスレッド数は，次の式から求められます。

Webサーバの処理スレッド数－（Webコンテナ単位の最大同時実行スレッド数＋実行待ちキューサイズの総和※）

注※　実行待ちキューサイズの総和とは，この図の場合，Webコンテナ，WebアプリケーションA，Control A，およびControl Bの実行待ちキューサイズを足した値となります。

このため，この図の例の場合，40－（8＋（5＋5＋1＋5））となり，静的コンテンツやリクエストのエラー処理に使用されるスレッド数は，16スレッドとなります。

4.20.4　URLパターンのマッピング処理

URLパターンに指定したURLとリクエストURLとのマッピングの順序について説明します。また，welcomeファイルに対してURLパターンを設定している場合についても説明します。

＜この項の構成＞

(1)　マッピングの順序

(2)　welcomeファイルにURLパターンを設定しているときの処理の流れ

(1)　マッピングの順序

リクエストURLは，次の1.～3.の順序でマッピングされます。なお，マッピングの順序は，Servlet仕様のサーブレットマッピングの適用順序と同じです。

完全一致
リクエストURLとURLパターンが完全に一致する場合，一致したURLパターンが適用されます。

プリフィックス一致
リクエストURLとプリフィックスが一致し，さらに，リクエストURLとできるだけ長く文字列が一致するURLパターンが適用されます。

拡張子一致
リクエストURLと拡張子が一致しする場合，一致したURLパターンが適用されます。

なお，上記の1.～3.に一致しない場合は，URLグループ単位の同時実行スレッド数制御の対象にはなりません。このようなリクエストURLは，Webアプリケーション単位の同時実行スレッド数制御の対象になります。

次に示すURLパターンを使用して，URLのマッピングの例を説明します。

表4-30　URLパターンの例

URLパターン | URLパターンに対応するURLグループ
/foo/bar | Control1
/foo/* | Control2
/foo/bar/* | Control3
*.do | Control4

マッピング例1：リクエストURLが「/foo/bar」の場合

Control1のURLパターンと完全一致するため，Control1に振り分けられます。

マッピング例2：リクエストURLが「/foo/bb」の場合

完全一致するURLパターンがないため，プリフィックスが一致するControl2に振り分けられます。

マッピング例3：リクエストURLが「/foo/aa.do」の場合

この場合，Control2とControl4で次の個所が一致します。

プリフィックス「/foo」がControl2と一致します。

拡張子「.do」がControl4と一致します。

マッピング順序では，拡張子一致よりプリフィックス一致が優先されるため，Control2に振り分けられます。

マッピング例4：リクエストURLが「/foo/bar/」の場合

この場合，Control2とControl3でそれぞれプリフィックスが一致します。

プリフィックス「/foo」がControl2と一致します。

プリフィックス「/foo/bar」がControl3と一致します。

より長い文字列で一致するControl3に振り分けられます。

マッピング例5：リクエストURLが「/foo/bar/action.do」の場合

この場合，Control2，Control3，Control4で次の個所が一致します。

プリフィックス「/foo」がControl2と一致します。

プリフィックス「/foo/bar」がControl3と一致します。

拡張子「.do」がControl4と一致します。

マッピング順序では拡張子一致よりプリフィックス一致が優先され，さらにより長い文字列が一致するURLパターンが優先されるので，Control3に振り分けられます。

マッピング例6：リクエストURLが「/context/fo」の場合

該当するURLパターンがないため，Webアプリケーション単位での同時実行スレッド制御として扱われます。

マッピング例7：リクエストURLが「/action.do」の場合

Control4と拡張子が一致するため，Control4に振り分けられます。

マッピング例8：リクエストURLが「/boo/action.do」の場合

Control4と拡張子が一致するため，Control4に振り分けられます。

(2)　welcomeファイルにURLパターンを設定しているときの処理の流れ

welcomeファイルにURLパターンを設定しているときの処理の流れについて，次の図で説明します。この図の例では，Webアプリケーションのコンテキストルートはcontextとし，welcomeファイルはweb.xmlで/index.htmlが設定されているものとします。また，URLパターンとURLグループ単位での同時実行スレッド数制御の定義名は次のとおりとします。

URLパターン：/index.html

URLグループ単位での同時実行スレッド数制御の定義名：Control1

図4-29　welcomeファイルにURLパターンを設定する場合の例

図の流れについて次に説明します。

クライアントはhttp://localhost/context/にリクエストを送信する。

J2EEサーバでは，web.xmlに設定されたwelcomeファイルに対して再度クライアントにアクセスしてもらうため，HTTPステータスコード302を返す。また，Locationヘッダにhttp://localhost/context/index.htmlを含める。

HTTPレスポンスを受信したクライアントは，Locationヘッダの値（http://localhost/context/index.html）にリクエストを送信する。

該当するWebアプリケーションのリクエストが/index.htmlなので，Control1のURLグループ単位の同時実行スレッド数制御の制御対象となる。リクエスト処理終了後，クライアントに対してレスポンスとしてindex.htmlを送信する。

4.21　ユーザスレッドで使用できるApplication Serverの機能

Cosminexusでは，サーブレットおよびJSPからスレッドを作成して使用できます。ユーザがプログラムの中で明示して作成するスレッドのことを，ユーザスレッドといいます。

ここでは，ユーザスレッドで使用できるApplication Serverの機能について説明します。ユーザスレッドの使用方法については，「4.32.1(14)　ユーザスレッドの使用方法」を参照してください。

Application Serverで提供される各機能について，ユーザスレッドで使用できるかどうかを次の表に示します。

表4-31　ユーザスレッドでの機能の使用可否

機能名 | 使用可否 | 参照先
サーブレットAPIの利用 | △ | （1）
Enterprise Beanの呼び出し | × | －
ネーミングサービス | ○ | （2）
リソース接続 | △ | （3）
トランザクションサービス | △
統合ユーザ管理 | × | －
ログ運用および障害検知 | ○ | （4）
J2EEアプリケーション運用 | △ | （5）
コンテナ拡張ライブラリの利用 | ○ | （6）

（凡例）○：使用できる　△：一部の機能が使用できない　×：使用できない　－：該当なし

ユーザスレッドで使用できる機能をさらに詳細機能に分類し，各機能についてサーブレット/JSP，およびユーザスレッドで使用できるかどうかを示します。また，ユーザスレッドで使用する場合の注意事項についても示します。

＜この節の構成＞

(1)　サーブレットAPI

(2)　ネーミングサービス

(3)　リソース接続およびトランザクションサービス

(4)　ログ運用および障害検知

(5)　J2EEアプリケーション運用

(6)　コンテナ拡張ライブラリ

(1)　サーブレットAPI

サーブレットAPIをユーザスレッドで使用する場合，リクエストオブジェクトおよびレスポンスオブジェクトは使用できません。リクエスト処理スレッドでだけ使用してください。詳細は，サーブレット仕様書のThread Safetyの項を参照してください。

(2)　ネーミングサービス

ネーミングサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表4-32　ネーミングサービスの機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
JNDIのルックアップ | リソースアダプタ | DB Connector | ○ | ○
DB Connector for Cosminexus RMとCosminexus RM | ○ | ○
TP1/Message Queue-Access | ○ | ○
uCosminexus TP1 Connector | ○ | ○
Java Mail | ○ | ○
JavaBeansリソース | ○ | ○
ユーザトランザクション | ○ | ○

（凡例）○：使用できる

ネーミングサービスを使用する場合，ユーザスレッドの実行中にアプリケーションを停止しないでください。

(3)　リソース接続およびトランザクションサービス

リソース接続およびトランザクションサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表4-33　リソース接続およびトランザクション管理の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
コネクションプーリング | DB Connectorによるコネクションプーリング | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによるコネクションプーリング | ○ | ○
uCosminexus TP1 Connectorとのコネクションプーリング | ○ | ○
TP1/Message Queue - Accessとのコネクションプーリング | ○ | ○
SMTPサーバとのコネクションプーリング | × | ×
コネクションプールのウォーミングアップ | ○ | ○
コネクション数調節 | ○ | ○
コネクションシェアリング | ○ | ○
コネクションアソシエーション | ○ | ○
ステートメントプーリング（DB Connector） | ○ | ○
ライトトランザクション | ○ | ○
インプロセストランザクションサービス | ○ | ○
DataSourceオブジェクトのキャッシング | ○ | ○
DB Connectorのコンテナ管理でのサインオンの最適化 | ○ | ○
受信バッファのプーリング | ○ | ○
コネクションの障害検知 | DB Connectorによる障害検知 | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによる障害検知 | ○ | ○
uCosminexus TP1 Connectorとのコネクション障害検知 | × | ×
TP1/Message Queue - Accessとのコネクション障害検知 | × | ×
SMTPサーバとのコネクション障害検知 | × | ×
コネクション枯渇時のコネクション取得待ち | ○ | ○
コネクションの取得リトライ | DB Connectorによるコネクション取得リトライ | ○ | ○
DB Connector for Cosminexus RMとCosminexus RMによるコネクション取得リトライ | ○ | ○
uCosminexus TP1 Connectorとのコネクション取得リトライ | ○ | ○
TP1/Message Queue - Accessとのコネクション取得リトライ | ○ | ○
SMTPサーバとのコネクション取得リトライ | × | ×
コネクションプールクリア | ○ | ○
コネクションのクローズ・解放 | コネクション強制クローズ | × | ×
コネクション自動クローズ（Webコンテナ） | ○ | ×
コネクションスイーパ | ○ | ○
トランザクションタイムアウト | ○ | ○
トランザクションリカバリ | ○ | ○
トランザクションの自動決着※ | ○ | ×
障害調査用SQLの出力 | ○ | ○
コネクションプールのクラスタ化 | ○ | ○

（凡例）○：使用できる　×：使用できない

注※

サーブレットのメソッドからリターンするとき，未決着のトランザクションをロールバックする機能です。

ユーザスレッドでリソース接続およびトランザクションサービスを使用する場合の注意事項を示します。

SingleThreadModelインタフェースを実装したサーブレットで生成したスレッド上で，トランザクションの開始と決着，およびコネクションの取得と解放はできません。

スレッド生成時にトランザクションを引き継ぐことはできません。

トランザクションは，同じスレッド上で開始または決着してください。

スレッド間でコネクションを渡すことはできません。コネクションを使用すると，動作不正となります。

ユーザスレッドでコネクションを取得した場合，コネクションを取得したスレッド上で確実にコネクションをクローズしてください。

(4)　ログ運用および障害検知

ログ運用および障害検知として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表4-34　ログ運用および障害検知の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
Managementイベントによる処理の自動実行 | ○ | ○
JP1イベントによるシステムの監視 | ○ | ○
ユーザログ出力 | ○ | ○
性能解析トレース | ○ | ○
CTMの稼働情報の監視 | ○ | ○

（凡例）○：使用できる

(5)　J2EEアプリケーション運用

J2EEアプリケーション運用機能として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表4-35　J2EEアプリケーション運用機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
Webコンテナでの同時実行スレッド数の制御 | ○ | ×
スケジュールキュー単位の同時実行数の動的変更 | ○ | ○
J2EEアプリケーションの実行時間監視 | メソッドタイムアウト機能 | ○ | ×
メソッドキャンセル機能 | ○ | ×
J2EEアプリケーションの停止 | 通常停止 | ○ | ○※1
強制停止 | ○ | ○※1
J2EEアプリケーションの入れ替え | リデプロイ機能による入れ替え | ○ | ○※2
リロード機能による入れ替え | ○ | ○
テストモードでのJ2EEアプリケーションの実行 | ○ | ×

（凡例）○：使用できる　×：使用できない

注※1

コンテナでは，ユーザスレッドを停止しません。

注※2

開始状態のJ2EEアプリケーションを入れ替えた場合，コンテナではユーザスレッドを停止しません。

(6)　コンテナ拡張ライブラリ

コンテナ拡張ライブラリは，サーブレット/JSPおよびユーザスレッドのどちらでも使用できます。

4.22　通信タイムアウトの設定

Webサーバ連携機能を使用する場合，クライアント－Webサーバ間，およびWebサーバ－Webコンテナ間での，リクエスト受信およびレスポンス送信に，通信のタイムアウトを設定できます。ネットワークの障害やアプリケーションの障害発生などで応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

Webサーバ連携機能を使用する場合，通信タイムアウトは，次に示す図中の四つの矢印が示す通信に対して設定します。さらに，リダイレクタ－Webコンテナ間の通信では，リダイレクタ側，Webコンテナ側の両方で通信タイムアウトを設定できます。リクエスト送信の場合は，リダイレクタ側でのリクエスト送信時およびWebコンテナ側でのリクエスト受信時に設定できます。また，レスポンス送信の場合は，Webコンテナ側でのレスポンス送信時およびリダイレクタ側でのレスポンス受信時に設定できます。タイムアウトを設定できる通信について次の図に示します。

図4-30　タイムアウトを設定できる通信

通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

＜この節の構成＞

4.22.1　リクエスト送受信時の通信タイムアウト

4.22.2　レスポンス送受信時の通信タイムアウト設定

4.22.1　リクエスト送受信時の通信タイムアウト

ここでは，Webサーバ連携機能を使用する場合のリクエスト送受信時の通信タイムアウト設定について説明します。リクエスト送受信時の，通信タイムアウトの設定場所を次の図に示します。

図4-31　リクエスト送受信時の通信タイムアウトの設定場所

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webサーバでのリクエスト受信時（クライアント－Webサーバ）
クライアントからのリクエストを，Webサーバで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。
Webサーバでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「(1)　Webサーバでのリクエスト受信時」を参照してください。

リダイレクタでのリクエスト送信時（リダイレクタ－Webコンテナ）
リダイレクタからWebコンテナにリクエストを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。
リダイレクタでのリクエスト送信時に通信タイムアウトを設定することによって検知できる障害については，「(2)　リダイレクタでのリクエスト送信時」を参照してください。

Webコンテナでのリクエスト受信時（リダイレクタ－Webコンテナ）
リダイレクタからのリクエストを，Webコンテナで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。
Webコンテナでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「(3)　Webコンテナでのリクエスト受信時」を参照してください。

＜この項の構成＞

(1)　Webサーバでのリクエスト受信時

(2)　リダイレクタでのリクエスト送信時

(3)　Webコンテナでのリクエスト受信時

(1)　Webサーバでのリクエスト受信時

Webサーバでは，クライアントから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント－Webサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

Webサーバでのリクエスト受信時のタイムアウトは，Webサーバで指定します。Webサーバ連携時のリクエスト送受信時の通信タイムアウト設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　リダイレクタでのリクエスト送信時

リダイレクタでは，Webコンテナへのリクエスト送信処理にタイムアウト時間を設定できます。

(a)　設定できる通信タイムアウトと検知できる障害

リダイレクタでのリクエスト送信処理では，次に示す二つの時間にタイムアウトが設定できます。

Webコンテナにリクエストを送信するための，コネクションを確立する時間

Webコンテナにリクエストを送信する時間

設定した通信タイムアウトによって，Webコンテナ側またはネットワーク上で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

リダイレクタ－Webコンテナ間でネットワーク障害が発生した

リダイレクタでのリクエスト送信時のタイムアウトは，リダイレクタで設定します。Webサーバ連携時のリクエスト送受信時の通信タイムアウト設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(b)　リクエスト送信処理のリトライ

リダイレクタからのリクエスト送信処理が一時的にできなくなった場合，リクエスト送信処理のリトライができます。一時的にリクエスト送信ができない場合とは次のような場合です。

ネットワークの一時的な障害が発生した場合

コネクション確立時に，Webコンテナにリクエストが集中している状態で，確立要求が一時的にリスンキューからあふれた場合

Webコンテナの起動完了を待っている場合

リトライできる処理は，コネクションの確立処理，およびリクエストヘッダの送信処理となります。なお，リトライ回数は，リダイレクタで設定します。Webサーバ連携時のリクエスト送受信時の通信タイムアウト設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。リトライ処理の流れを次の図に示します。

図4-32　Webコンテナへのリクエスト送信時のリトライ処理の流れ

リトライは，図中のAまたはBでタイムアウトが発生した場合に実施されます。図中CまたはDの部分で処理に失敗し，タイムアウトが発生した場合，リトライは実施されません。コネクションはクローズされ，クライアントにエラーが返ります。なお，図中CまたはDの部分で処理の失敗とは，Webサーバからのリクエストボディの受信に失敗した場合，またはWebコンテナへのリクエストボディの送信に失敗した場合を指します。

ポイント

図中のCまたはDの処理では，Webコンテナ側ですでにリクエストに対する処理が開始されている可能性があります。Webサーバからのリクエストボディの受信に失敗した場合，およびWebコンテナへのリクエストボディの送信に失敗した場合は，リトライを実施すると二重送信となるおそれがあるため，リトライはされません。

次に，図中Aおよび図中Bで処理に失敗した場合のリトライについて説明します。

●図中Aの部分で処理に失敗した場合のリトライ

リダイレクタからWebコンテナにコネクションの確立要求を出したあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，コネクション確立でタイムアウトが発生したことを示すメッセージが出力されます。

指定した回数だけコネクションの確立をリトライします。

なお，リトライ回数分実施してもコネクションの確立ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにエラー（ステータスコード500）が返されます。

●図中Bの部分で処理に失敗した場合のリトライ

コネクションの確立が成功したあと，またはWebコンテナにリクエストヘッダの送信をしたあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，リクエスト送信でタイムアウトが発生したことを示すメッセージが出力されます。

リクエストヘッダの送信処理に使用されたコネクションをクローズします。

指定した回数だけリクエストヘッダの送信をリトライします。
なお，このとき，コネクションキャッシュにコネクションがあるかどうかで動作が異なります。

コネクションキャッシュにコネクションがある場合
コネクションキャッシュ中のコネクションを使用して，リクエストヘッダの送信処理からリトライします。

コネクションキャッシュにコネクションがない場合
再度，コネクションの確立を実施してから，リクエストヘッダの送信処理をリトライします。

なお，リトライ回数分実施してもリクエストヘッダの送信ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにステータスコード500が返されます。

●ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

ロードバランサを使用したリクエストの振り分けをしている場合のリトライ動作について，次の図で説明します。

なお，この図では，リクエストは，Webコンテナ1，Webコンテナ2の順で振り分けられ，リトライ回数は3回が設定されていることとします。

図4-33　ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

図のリトライ動作について説明します。

Webコンテナ1へのリクエスト送信
リクエストはWebコンテナ1に送信されます。Webコンテナ1へのコネクションの確立またはリクエストヘッダの送信処理に失敗すると，リトライをします。リトライは3回まで実施されます。

Webコンテナ2へのリクエスト送信
Webコンテナ1でのリトライに3回失敗すると，リクエストはWebコンテナ2に転送されます。リクエストが転送されると，リトライは再度1からカウントされるため，Webコンテナ2に対しても，最大で3回リトライが実行されます。

クライアントへのエラー通知
Webコンテナ2に対しても，コネクションの確立またはリクエストヘッダの送信処理が3回失敗すると，クライアントにエラー（ステータスコード500）が返ります。

参考

リクエストの転送は，設定されているWebコンテナの数だけ実施されます。

(3)　Webコンテナでのリクエスト受信時

Webコンテナでは，リダイレクタから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webサーバが稼働するホストがダウンした

Webサーバ－Webコンテナ間のネットワーク障害が発生した

クライアント－Webサーバ間での処理が終わる前に，Webコンテナ側でタイムアウトが発生した
これは，Webコンテナが要求したデータサイズ分の読み込みを，クライアント－Webサーバ間で行っているときに，クライアント－Webサーバ間の通信速度が十分ではないなどの理由によって，データの読み込みが終了する前に，Webコンテナで設定した通信タイムアウトが発生したことを意味します。

通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表4-36　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生する条件
発生後の動作

リクエスト受信時に次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

リクエスト処理は実行されない。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でのAPI※使用時に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

java.lang.IllegalStateExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でjavax.servlet.ServletInputStreamクラスまたはjavax.servlet.ServletRequestクラスのgetReaderメソッドによって得られたjava.io.BufferedReaderクラスを使用してPOSTデータを読み込んだ際に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ－Webコンテナ間のネットワークに障害が発生した。

java.net.SocketTimeoutExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

注※

javax.servlet.ServletRequestの，getParameterメソッド，getParameterMapメソッド，getParameterNamesメソッド，getParameterValuesメソッドを使用している場合を指します。

Webコンテナでのリクエスト受信時のタイムアウトの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

4.22.2　レスポンス送受信時の通信タイムアウト設定

ここでは，Webサーバ連携機能を使用する場合のレスポンス送受信時の通信タイムアウト設定について説明します。レスポンス送受信時の，通信タイムアウトの設定場所を次の図に示します。

図4-34　レスポンス送信時の通信タイムアウトの設定場所（Webサーバ連携機能を使用する場合）

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webコンテナでのレスポンス送信時（Webコンテナ－リダイレクタ）
Webコンテナからリダイレクタにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。
Webコンテナでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「(1)　Webコンテナでのレスポンス送信時」を参照してください。

リダイレクタでのレスポンス受信時（Webコンテナ－リダイレクタ）
Webコンテナからのレスポンスを，リダイレクタで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。
リダイレクタでのレスポンス受信時に通信タイムアウトを設定することによって検知できる障害については，「(2)　リダイレクタでのレスポンス受信時」を参照してください。

Webサーバでのレスポンス送信時（Webサーバ－クライアント）
Webサーバからクライアントにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。
Webサーバでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「(3)　Webサーバでのレスポンス送信時」を参照してください。

＜この項の構成＞

(1)　Webコンテナでのレスポンス送信時

(2)　リダイレクタでのレスポンス受信時

(3)　Webサーバでのレスポンス送信時

(1)　Webコンテナでのレスポンス送信時

Webコンテナでは，リダイレクタへのレスポンス送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

リダイレクタが稼働するホストがダウンした

Webコンテナ－リダイレクタ間でネットワーク障害が発生した

Webコンテナでのレスポンス送信時のタイムアウトの設定は，Webコンテナで設定します。Webサーバとの連携時のレスポンス送受信時の通信タイムアウト設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

また，通信タイムアウトが発生すると，KDJE39507-E（レスポンス送信処理でタイムアウト発生）がメッセージログに出力されます。通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表4-37　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生するタイミング
通信タイムアウト発生後のメソッドの動作
通信タイムアウト発生後のサーブレットまたはJSPの動作

サーブレット内で，javax.servlet.ServletResponseクラスのgetOutputStreamメソッドによって得られたjavax.servlet.ServletOutputStreamクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき
java.net.SocketTimeoutExceptionの例外が発生する。
リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

サーブレット内で，javax.servlet.ServletResponseクラスのgetWriterメソッドによって得られたjava.io.PrintWriterクラスのメソッドを使用して，レスポンスデータをクライアントに送信したとき
送信処理が中断されて，リターンする。

java.io.PrintWriterクラスのcheckErrorメソッドがtrueを返す。

リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

JSP内で，javax.servlet.jsp.JspWriterクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき
java.net.SocketTimeoutExceptionの例外が発生する。
リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

静的コンテンツのレスポンスデータをクライアントに送信したとき
－
－

（凡例）－：該当しない

(2)　リダイレクタでのレスポンス受信時

リダイレクタは，Webコンテナにリクエストを送信すると，Webコンテナからのレスポンスを待ちます。このレスポンスの待ち時間に，タイムアウトを設定できます。設定した通信タイムアウトによって，Webコンテナ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

Webコンテナ－リダイレクタ間でネットワーク障害が発生した

Webコンテナ内のWebアプリケーションで障害が発生した

Webアプリケーションで発生する障害には次のようなものがあります。

Webアプリケーションで発生する障害

サーブレット/JSP処理内の無限ループによって，レスポンスが返されない

サーブレット/JSPの延長でEnterprise Bean，データベースなどが呼び出され，それによる応答待ちをしている

Webアプリケーションでデッドロックが発生している

アクセスピーク時にサーバの処理が追いつかないで滞っている

リダイレクタでの通信タイムアウト後の動作

通信タイムアウトが発生すると，リダイレクタは，Webコンテナとのコネクションを切断し，クライアントにステータスコード500のエラーを返します。

ポイント

アプリケーション処理中にタイムアウトが発生したときの動作

Webコンテナでの処理中にリダイレクタがタイムアウトしていても，Webコンテナでは，リダイレクタがタイムアウトしていることを検知できません。

リダイレクタでのタイムアウトを検知できるのは，Webコンテナの処理が完了し，リダイレクタへレスポンスを転送するときとなります。しかし，この時点では，すでにリダイレクタがWebコンテナとのコネクションを切断しているため，レスポンス送信はエラーとなります。アプリケーション処理中にタイムアウトが発生したときの動作について次の図に示します。

図4-35　アプリケーション処理中にタイムアウトが発生したときの動作

図について説明します。

リダイレクタでタイムアウトが発生すると，Webコンテナとのコネクションを切断する要求を出します。

リダイレクタはWebサーバに対して，エラーコードを送信します。

Webコンテナでのアプリケーションの処理が完了すると，リダイレクタに対して，レスポンスを送信しますが，1.で，すでにリダイレクタとWebコンテナのコネクションは切断されているため，通信エラーが発生します。

リダイレクタでのレスポンス受信時のタイムアウトの設定は，Webサーバ連携時に使用するworkers.properties（ワーカ定義ファイル）で指定します。Webサーバとの連携の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　Webサーバでのレスポンス送信時

Webサーバでは，クライアントへのデータ送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント－Webサーバ間のネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

Webサーバでのレスポンス送信時のタイムアウトは，Webサーバで指定します。Webサーバとの連携の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

4.23　Webサーバ（リダイレクタ）によるリクエストの振り分け

この節では，リダイレクタを使用したリクエストの振り分けについて説明します。この機能は，Webサーバ連携機能を使用する場合に使用できます。リクエストの振り分けをするには，次に示す定義を，Webサーバ/リダイレクタが動作しているホストに対して実施する必要があります。

なお，使用するWebサーバの種類によって定義が異なります。また，Webサーバの種類がHitachi Web Serverの場合は，使用するシステムの構築支援機能の種類によっても定義が異なります。使用するWebサーバの種類と定義を次の表に示します。

表4-38　使用するWebサーバの種類と定義

Webサーバの種類
システムの構築支援機能の種類
定義

Hitachi Web Server
Smart Composer機能

簡易構築定義ファイルの定義

workers.propertiesの定義

mod_jk.confの定義

Smart Composer機能以外

workers.propertiesの定義

mod_jk.confの定義

Microsoft IIS
－

workers.propertiesの定義

uriworkermap.propertiesの定義

isapi_redirect.confの定義

（凡例）－：該当しない

リダイレクタを使用したリクエストの振り分けの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

インプロセスHTTPサーバを使用する場合のリダイレクトによるリクエストの振り分けについては，「4.3.11　リダイレクトによるリクエストの振り分け」を参照してください。

＜この節の構成＞

4.23.1　リダイレクタを使用したリクエスト振り分けの仕組み

4.23.2　URLパターンでのリクエストの振り分け

4.23.3　ラウンドロビン方式でのリクエストの振り分け

4.23.4　POSTデータサイズでのリクエストの振り分け

4.23.5　リダイレクタが返すエラーステータスコード

4.23.6　Webサーバ連携時の留意事項

4.23.1　リダイレクタを使用したリクエスト振り分けの仕組み

リダイレクタを使用すると，WebサーバあてのHTTPリクエストのうち，特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできます。

リダイレクタを使用してリクエストを振り分ける場合，ワーカプロセス※というWebサーバの背後で動作するWebコンテナの実行プロセスを使用します。ワーカプロセスは，リダイレクタを経由して，サーブレット，JSPを含むリクエストを処理するプロセスです。Webサーバとワーカプロセスとの間のデータ交換は，TCP/IPに基づき，ユーザが設定する特定のポート番号を通じて実行されます。リダイレクタの設定は，ワーカというWebコンテナを抽象化した設定単位を使用して行います。ワーカには，単体のJ2EEサーバを表すワーカと，クラスタ構成のJ2EEサーバを表すワーカがあります。J2EEサーバへリクエストを転送するワーカを転送先ワーカと呼びます。転送先ワーカはワーカタイプがajp13のワーカです。

注※

ワーカプロセスは，実際には，J2EEサーバとなります。

＜この項の構成＞

(1)　リクエストの転送パターン

(2)　リクエストの振り分け方法

(1)　リクエストの転送パターン

リダイレクタからワーカプロセスへのリクエストの転送には，次に示すパターンがあります。

一つのWebサーバから一つのワーカプロセスへの転送

一つのWebサーバから複数のワーカプロセスへの転送

なお，Webサーバとワーカプロセスは，同一のマシン上にあっても，異なるマシン上にあってもかまいません。

リダイレクタからワーカプロセスへのリクエスト転送パターンを次の図に示します。

図4-36　一つのWebサーバから一つのワーカプロセスへの転送

図4-37　一つのWebサーバから複数のワーカプロセスへの転送

複数のWebコンテナへリクエストを振り分けるには，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカプロセスを振り分け先として定義します。

(2)　リクエストの振り分け方法

リダイレクタを使用してリクエストを振り分ける方法には，次の3種類があります。

URLパターンによって振り分ける方法
一つのWebコンテナに特定の処理をさせたい場合，および複数のWebコンテナに処理を振り分けたい場合に使用します。
ワーカプロセスが一つの場合と複数の場合に使用できます。

ロードバランサを使用してラウンドロビン方式で振り分ける方法
複数のWebコンテナに処理を振り分けたい場合に使用します。

POSTデータサイズによって振り分ける方法
複数のWebコンテナに処理を振り分けたい場合に使用します。この振り分け方法は，WebサーバにHitachi Web Serverを使用している場合にだけ設定できます。
なお，次の機能を使用している場合，この振り分け方法は適用できません。

セッションフェイルオーバ機能

ラウンドロビン方式でのリクエストの振り分け

ワーカプロセスを作成するには，ワーカ定義ファイルと呼ばれるファイル（workers.properties）に，次の属性を定義します。

ワーカ名

ワーカのタイプ

ワーカが動作しているホスト名，またはIPアドレス

ワーカが受け付けるポート番号

標準で提供されるworkers.propertiesには，あらかじめ次に示すワーカが定義されています。WebサーバとWebコンテナを同一のホスト上で動作させる場合には，これらパラメタを変更する必要はありません。

ワーカの属性 | パラメタ
ワーカ名 | worker1
ワーカのタイプ | ajp13
ホスト名 | localhost
ポート番号 | 8007

ワーカプロセスの定義方法の詳細については，マニュアル「Cosminexus　システム構築ガイド」およびマニュアル「Cosminexus　リファレンス　定義編」を参照してください。

4.23.2　URLパターンでのリクエストの振り分け

HTTPリクエストに含まれるURLパターンによって，リクエストを振り分けます。これによって，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて処理を振り分けたりできます。例えば，「『/examples/』というURLを含むHTTPリクエストをWebコンテナで処理する」という定義や，「『/examples1/』というURLを含むHTTPリクエストはWebコンテナAで，『/examples2/』というURLを含むHTTPリクエストはWebコンテナBで処理する」といった定義ができます。

Webコンテナに転送するリクエストは，URLパターンとワーカプロセスのマッピングによって定義します。リダイレクタは設定されたURLパターンに従って，リクエストを転送するWebコンテナを切り替えます。なお，URLパターンによる振り分けは，原則としてWebアプリケーション単位で振り分けます。

URLパターンは，リダイレクタの動作として定義します。URLパターンでのリクエスト振り分けの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　リダイレクタによるリクエスト振り分けの例

(2)　URLパターンの種類と適用されるパターンの優先順位

(1)　リダイレクタによるリクエスト振り分けの例

リダイレクタによるリクエストの振り分けの例を，次の図に示します。

図4-38　リダイレクタによるリクエストの振り分け（特定のリクエストをWebコンテナに転送する場合）

図4-39　リダイレクタによるリクエストの振り分け（リクエストを複数のWebコンテナに振り分けて転送する場合）

(2)　URLパターンの種類と適用されるパターンの優先順位

リダイレクタのURLマッピングには次の４種類のURLパターンを指定できます。

完全パス指定
完全に一致するパターンです。

例：

URLパターンが"/examples/jsp/index.jsp"で，URLが"/examples/jsp/index.jsp"の場合，一致となります。

パス指定
パスが一致するパターンです。

例：

URLパターンが"/examples/*"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

拡張子指定
拡張子が一致するパターンです。指定されたパス以下のすべての階層に適用されます。

例：

URLパターンが"/examples/*.jsp"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

サフィックス指定
サフィックスが一致するパターンです。指定されたパス以下のすべての階層に適用されます。

例：

URLパターンが"/examples/servlet/*Servlet"で，URLが"/examples/servlet/HelloServlet"などの場合，一致となります。

これらの四つのURLパターンへのマッピングのうち，最優先されるURLパターンは，「完全パス指定」です。「完全パス指定」に一致しない場合，次に示す順序でパスの一致が判定され，適用されるURLパターンが決定します。

「完全パス指定」に一致しない場合
「パス指定」「拡張子指定」「サフィックス指定」のうち，最長一致のものが適用されます。最長一致とは，先頭("/")から"*"の上位パスまでができるだけ長いものに一致することを示します。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/* worker1

/examples/jsp/* worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/test/index.jsp"の場合にはworker1のマッピングが適用されます。

1.の条件に加えて，最長一致する「パス指定」「拡張子指定」「サフィックス指定」が複数存在する場合
「パス指定」より，「拡張子指定」または「サフィックス指定」が優先されます。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/jsp/* worker1

/examples/jsp/*.jsp worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/jsp/test.html"の場合にはworker1のマッピングが適用されます。

1.および2.の条件に加えて，最長一致する「拡張子指定」「サフィックス指定」が複数存在する場合
あとに指定したURLパターンが優先されます。
次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/*.jsp worker1

/examples/*jsp worker2

この順番に指定されていた場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用されます。

注意

URLパターンでの注意事項を次に示します。

URLパターンの先頭に"/"以外を指定した場合，そのマッピングは無視されます。

指定できる"*"は一つだけです。

"*"の前は"/"である必要があります。

同じURLパターンのマッピングを複数記述しないでください。複数記述したときの動作は保証できません。

4.23.3　ラウンドロビン方式でのリクエストの振り分け

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，ラウンドロビン方式でそれぞれのWebコンテナにリクエストを振り分けられます。リダイレクタは，各リクエストに付けられたセッションIDを参照することで，同一のWebクライアントから来たリクエストが常に同一のWebコンテナへ転送されるように，リクエストを振り分けます。

また，振り分け先のWebコンテナの処理性能が異なる場合などには，負荷パラメタを定義することで，ホストごとの負荷の割合を調整することもできます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれ同じWebアプリケーションがデプロイされていることが前提になります。

クラスタ構成でのラウンドロビン方式によるリクエスト振り分けには，ロードバランサというワーカ定義を使用します。ロードバランサには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するラウンドロビン方式の振り分けが実行されます。

振り分けはHTTPリクエスト単位で実行されます。ただし，同じセッションに属するHTTPリクエストは，前回の振り分け先と同じワーカに振り分けられます。

参考

Webサーバ連携時に，リダイレクタの設定でラウンドロビン方式によるリクエストの振り分けを指定すると，HttpSessionのセッションIDにワーカ名が付加されます。また，サーバIDを付加するかどうかの設定に関係なく，HttpSessionのセッションIDにサーバIDは付加されません。

＜この項の構成＞

(1)　ラウンドロビン方式によるリクエストの振り分けの例

(2)　ラウンドロビン方式によるリクエストの振り分けの定義

(3)　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

(1)　ラウンドロビン方式によるリクエストの振り分けの例

ロードバランサを使用したリクエストの振り分けの例を次の図に示します。

図4-40　ロードバランサを使用したリクエストの振り分けの例

(2)　ラウンドロビン方式によるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すロードバランサが定義されています。

#worker.list=loadbalancer1

#worker.loadbalancer1.type=lb
#worker.loadbalancer1.balanced_workers=worker1,worker2

worker.loadbalancer1.typeでは，ワーカのタイプを設定します。worker.loadbalancer1.balanced_workersでは，振り分け対象となるワーカプロセス名を設定します。workers.propertiesには，loadbalancer1として，それぞれ「lb」と「worker1，worker2」が定義されています。

ただし，この定義はコメントとして記述されています。このため，上記のロードバランサを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエスト振り分けの比率は，振り分け対象となる各ワーカ定義のlbfactorパラメタに定義できます。lbfactorが大きければ大きいほどそのワーカプロセスに転送されるリクエストの割合は大きくなります。

例えば，worker1とworker2という二つのワーカプロセスでリクエストを振り分ける場合，ワーカ定義のlbfactorパラメタに次に示すように定義されているとします。

worker1のlbfactorパラメタ：2.0

worker2のlbfactorパラメタ：1.0

この場合，worker1はworker2の2倍の数のWebクライアントを担当することになります。

ラウンドロビン方式でのリクエストの振り分けは，ワーカに設定します。ラウンドロビン方式でのリクエスト振り分けの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

リダイレクタのラウンドロビン方式によるリクエストの振り分けに関する注意事項を次に示します。

J2EEアプリケーション停止中のWebコンテナへのリクエストの送信
ラウンドロビン方式でリクエストを振り分ける場合，J2EEアプリケーションが停止中であってもWebコンテナへリクエストが送信されます。このため，J2EEアプリケーションの変更は，すべてのWebコンテナをシステムから隔離した状態で実施する必要があります。

負荷分散機によるヘルスチェックの無効
負荷分散機と，ラウンドロビン方式によるリクエストの振り分けを併用した場合，J2EEサーバに障害が発生したときも，リダイレクタで正常なWebコンテナへ転送されます。このため，負荷分散機でJ2EEサーバの障害が検知できなくなり，Webコンテナの監視が行えません。

4.23.4　POSTデータサイズでのリクエストの振り分け

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，POSTデータサイズごとにそれぞれのWebコンテナにリクエストを振り分けられます。この機能を使用すると，処理に時間が掛かる長大なPOSTデータのリクエストを，特定のWebコンテナに転送できます。これによって，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれWebアプリケーションがデプロイされていることが前提になります。ただし，各J2EEサーバにデプロイするWebアプリケーションが同一である必要はありません。

クラスタ構成でのPOSTデータサイズによるリクエストの振り分けには，POSTリクエスト振り分けワーカというワーカ定義を使用します。POSTリクエスト振り分けワーカには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するPOSTデータサイズの振り分けが実行されます。POSTリクエスト振り分けワーカの振り分け先となるワーカプロセスをPOSTリクエスト転送先ワーカといいます。

POSTリクエスト転送先ワーカへの振り分けは，HTTPリクエスト単位で実行されます。

注意

HTTP CookieまたはURL書き換えによる制御でセッションが管理されている場合でも，POSTデータサイズによる振り分けを設定しているときは，POSTデータサイズによって，リクエストの振り分け先が決定されます。このため，同一クライアントからのリクエストの場合でも，HttpSessionのセッションIDは引き継がれません。

例えば，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送された場合，J2EEサーバ2で新たにHttpSessionのセッションIDが生成されます。この場合，再度J2EEサーバ1にアクセスすると，クライアントではJ2EEサーバ2で生成されたHttpSessionのセッションIDを使用しているため，J2EEサーバ1で新たにHttpSessionのセッションIDが生成されます。このため，HttpSessionのセッションは引き継がれません。

なお，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送されても，J2EEサーバ2でHttpSessionのセッションIDが生成されない場合，再度J2EEサーバ1にアクセスすると，J2EEサーバ1で生成済みのHttpSessionのセッションIDがそのまま使用されます。

＜この項の構成＞

(1)　POSTデータサイズによるリクエストの振り分けの例

(2)　リクエストの振り分け条件

(3)　POSTデータサイズによるリクエストの振り分けの定義

(1)　POSTデータサイズによるリクエストの振り分けの例

POSTデータサイズでリクエストを振り分ける場合，POSTリクエスト振り分けワーカに転送されるリクエストが限定できるかどうかによって，POSTデータサイズの上限値に設定する値が異なります。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できる場合
ここでは，次の条件を満たすリクエストが，POSTリクエスト振り分けワーカに転送されるものとして説明します。

POSTデータのリクエストである。

リクエストのPOSTデータサイズが200メガバイト未満である。

リクエストが限定できる場合，処理したい長大なPOSTデータの範囲も限定できます。長大なPOSTデータのリクエストを処理するワーカに，特定のPOSTデータサイズのリクエストが転送されるように，それぞれのリクエスト転送先ワーカで上限値を設定します。
リクエストが限定できる場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図4-41　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できる場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストがワーカプロセスBに転送されるように，それぞれにPOSTデータサイズの上限値を設定しています。リクエストのPOSTデータサイズが上限値未満の場合に，それぞれのPOSTリクエスト転送先ワーカに振り分けられます。リクエストのPOSTデータサイズが，複数のPOSTリクエスト転送先ワーカに当てはまる場合，POSTデータサイズの上限値が最も小さいPOSTリクエスト転送先ワーカに，リクエストは振り分けられます。例えば，POSTデータサイズが80メガバイトのリクエストの場合は，どちらのワーカにも該当しますが，ワーカプロセスAに振り分けられます。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できない場合
リクエストを限定できない場合，長大なPOSTデータを処理するワーカのPOSTデータサイズの上限値には，最大値を設定します。
リクエストが限定できない場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図4-42　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できない場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，それぞれにPOSTデータサイズの上限値を設定しています。長大なPOSTデータのリクエストすべてをワーカプロセスBで処理するように，ワーカプロセスBのPOSTデータサイズの上限値には最大値を設定しています。ワーカプロセスAの上限値以上（100メガバイト以上）のPOSTデータのリクエストは，すべてワーカプロセスBに転送されます。なお，この場合，POSTデータ以外のリクエストや，POSTデータサイズが参照できないリクエストなどが転送されると，リクエスト振り分けワーカで振り分けられないため，リダイレクタによってエラーステータスコード400が返されてエラーとなります。

POSTデータサイズでリクエストを振り分ける場合，リクエストの振り分け条件に満たないリクエストがPOSTリクエスト振り分けワーカに転送されると，リダイレクタによってエラーステータスコード400が返されてエラーとなります。リクエストの振り分け条件については，「(2)　リクエストの振り分け条件」を参照してください。

リクエストの振り分け条件に満たないリクエストも処理したい場合は，そのリクエストを転送するワーカプロセスを設定する必要があります。リクエストの振り分け条件に満たないリクエストを転送するワーカプロセスをデフォルトワーカといいます。なお，デフォルトワーカの設定は任意です。

リクエストが限定できない場合に，リクエストの振り分け条件に満たないリクエストをデフォルトワーカに転送する例を次の図に示します。

図4-43　POSTデータサイズによるリクエストの振り分けの例（デフォルトワーカを設定した場合）

この図では，リクエストの振り分け条件に満たないリクエストを，デフォルトワーカのワーカプロセスAに転送するように設定しています。

(2)　リクエストの振り分け条件

POSTリクエスト転送先ワーカに振り分けられるリクエストは，次の条件を満たしている必要があります。

POSTリクエスト転送先ワーカに振り分けられるリクエストの条件

リクエストのメソッドがPOSTであること。

リクエストにContent-Lengthヘッダがある（ボディデータがチャンク形式でない）こと。

リクエストのContent-Lengthヘッダの値が，ワーカに設定しているPOSTデータサイズ未満であること。

どれか一つでも条件を満たさないリクエストは，デフォルトワーカに振り分けられます。デフォルトワーカが設定されていない場合は，エラーとなり，エラーステータスコード400のエラーが返されます。

(3)　POSTデータサイズによるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すPOSTリクエスト割り分けワーカが定義されています。

#worker.list=postsizelb1
#worker.postsizelb1.type=post_size_lb
#worker.postsizelb1.post_size_workers=worker1,worker2
#worker.postsizelb1.default_worker=worker1

worker.postsizelb1.typeでは，ワーカのタイプを設定します。worker.postsizelb1.post_size_workersでは，振り分け対象となるPOSTリクエスト転送先ワーカのワーカプロセス名を設定します。worker.postsizelb1.default_workerでは，デフォルトワーカを設定します。workers.propertiesには，postsizelb1として，ワーカのタイプに「post_size_lb」，POSTリクエスト転送先ワーカに「worker1，worker2」，デフォルトワーカに「worker1」が定義されています。

ただし，この定義はコメントとして記述されています。このため，この定義のPOSTリクエスト割り分けワーカを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエストを振り分けるPOSTデータサイズは，workers.propertiesのワーカ定義のpost_dataパラメタで設定します。

例えば，標準提供のpostsizelb1の定義を利用して，worker1とworker2という二つのPOSTリクエスト転送先ワーカに，それぞれ次のようにPOSTデータサイズを定義しているとします。

worker1のpost_dataパラメタ：100m

worker2のpost_dataパラメタ：200m

この場合，worker1には100メガバイト未満のリクエストが，worker2には100メガバイト以上200メガバイト未満のリクエストが振り分けられます。リクエスト振り分けワーカが，200メガバイト以上のリクエストを振り分けた場合，そのリクエストはデフォルトワーカに設定されているworker1に転送されます。

POSTデータサイズでのリクエスト振り分けの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

4.23.5　リダイレクタが返すエラーステータスコード

Webコンテナとのデータ送受信時にタイムアウトが発生したり，定義ファイルに記載誤りがあったりすると，リダイレクタはエラーステータスコードを返します。リダイレクタが返すエラーステータスコードと，エラーステータスコードを返す条件を，Webサーバの種類ごとに表に示します。

表4-39　リダイレクタが返すエラーステータスコードと発生条件（Hitachi Web Serverの場合）

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかに該当する場合，エラーステータスコード400が返ります。

リクエストのHostヘッダのポート番号が不正な場合

リクエストのメソッドがPOSTではない場合※1

リクエストにContent-Lengthヘッダがない（POSTリクエストである場合，ボディがチャンク形式である）場合※1

リクエストのContent-Lengthヘッダの値が，POSTリクエスト転送先ワーカに設定されたPOSTデータサイズの上限を超えた値である場合※1

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

mod_jk.confの内容に記述誤りがある場合※2

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合※1

リクエストヘッダが16KBを超えている場合※3

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

注※1　POSTデータサイズによる振り分けで，デフォルトワーカを指定していない場合が該当します。

注※2　Windowsの場合だけ該当します。UNIXの場合は起動に失敗します。

注※3　Hitachi Web Serverの設定で16KB以上のリクエストヘッダを許可している場合が該当します。

表4-40　リダイレクタが返すエラーステータスコードと発生条件（Microsoft IISの場合）

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかの場合，エラーステータスコード400が返ります。

リクエストURLに"%"を含み，さらに"%"のあとに続く2文字が16進数を表さない文字（A～F，a～f，または0～9以外の文字）の場合

リクエストのHostヘッダのポート番号が不正の場合

403　Forbidden
次のどちらかの場合，エラーステータスコード403が返ります。

リクエストURLが"hitachi_ccfj"から始まる場合※1

リクエストURLに"%2F"が含まれる場合※1

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

isapi_redirect.confの内容に記述誤りがある場合

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合

リクエストヘッダが16KBを超えている場合※2

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

注※1　大文字・小文字の区別はありません。

注※2　Microsoft IISの設定で16KB以上のリクエストヘッダを許可している場合が該当します。

4.23.6　Webサーバ連携時の留意事項

Webサーバと連携するときの留意事項について説明します。

＜この項の構成＞

(1)　Webコンテナが送受信できるリクエストヘッダおよびレスポンスヘッダの上限値

(2)　Hitachi Web Serverを使用するときの留意事項

(3)　Microsoft IISを使用するときの留意事項

(1)　Webコンテナが送受信できるリクエストヘッダおよびレスポンスヘッダの上限値

Webサーバと連携する場合，Webコンテナで送受信できるリクエストヘッダおよびレスポンスヘッダには上限があります。上限はそれぞれ16KBです。16KBを超えるヘッダの送受信はできないので注意してください。

(2)　Hitachi Web Serverを使用するときの留意事項

Application Serverで構築したシステムでは，Hitachi Web Serverの仮想ホスト機能を使用できません。同一ホスト上で，複数のHitachi Web Serverを起動したい場合は，Management Serverを使用してください。

(3)　Microsoft IISを使用するときの留意事項

Microsoft IISを使用するときの留意事項を説明します。

Microsoft IISで複数のWebサイトを構築している場合，これらのWebサイトと同時に連携することはできません。複数のWebサイトを構築している場合は，Webサイトごとにリダイレクタの設定をしてください。

Microsoft IIS用リダイレクタでは，Webコンテナに転送するリクエストについては，リクエストURL情報を変更します。変更したリクエストURLはISAPIフィルタ内で使用します。
このため，Microsoft IIS用リダイレクタ以降に実行されるISAPIフィルタでは，Microsoft IISが最初に受信したリクエストURLを取得できません。Microsoft IISが受信したリクエストURLをISAPIフィルタで取得したい場合は，ISAPIフィルタの優先順位をMicrosoft IIS用リダイレクタよりも高く設定する必要があります。なお，優先順位を調整するために，Microsoft IIS用リダイレクタの優先順位を「中」または「低」に変更する必要がある場合は，Microsoft IIS用リダイレクタ動作定義ファイルのfilter_priorityキーで指定します。filter_priorityキーについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

Microsoft IISと連携する場合，次のHTTPリクエストヘッダはWebクライアントで指定していても，Webアプリケーションでは受信できません。

tomcaturl

tomcatquery

tomcatworker

tomcattranslate

これらのHTTPリクエストヘッダはリダイレクタで使用されます。

Microsoft IISと連携する場合，POSTデータサイズによるリクエストの振り分けは設定できません。

4.24　エラーページのカスタマイズ

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。クライアント側では，Webコンテナから返されたエラーステータスコードに対応するエラーページが表示されます。

Cosminexusでは，クライアントで表示されるエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

エラーページをカスタマイズするには，Servlet仕様で規定されているweb.xmlの<error-page>タグを使用する方法と，Webサーバの機能を使用する方法があります。ただし，リダイレクタがWebコンテナとの通信に失敗した場合など，リダイレクタがエラーを返す場合のエラーページは，web.xmlの<error-page>タグを使用する方法ではカスタマイズできません。リダイレクタがエラーを返す場合のエラーページのカスタマイズは，Webサーバの機能を使用する方法で行ってください。エラー発生場所とエラーページのカスタマイズ方法の対応を表に示します。

表4-41　エラー発生場所とエラーページのカスタマイズ方法の対応

エラー発生場所 | カスタマイズ方法
Webサーバの機能を使用する方法 | web.xmlの<error-page>タグを使用する方法
Webコンテナ | ○ | ○
リダイレクタ | ○ | ×

（凡例）　○：カスタマイズできる　×：カスタマイズできない

ここでは，Webサーバの機能を使用したエラーページのカスタマイズ方法について説明します。

なお，Webコンテナでエラーが発生する条件と，対応するエラーステータスコードについては，「4.30　Webコンテナが返すエラーステータスコード」を参照してください。また，エラーページのカスタマイズは，ワーカで定義します。エラーページのカスタマイズの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，Webサーバの機能を使用したエラーページのカスタマイズは，Webサーバ連携機能を使用する場合に使用できる機能です。WebサーバがHitachi Web Serverの場合だけ使用できます。Microsoft IISの場合は使用できません。

＜この節の構成＞

4.24.1　エラーページのカスタマイズの仕組み

4.24.2　エラーページカスタマイズの注意事項

4.24.1　エラーページのカスタマイズの仕組み

エラーページのカスタマイズの処理の仕組みを，Webコンテナでエラーが発生した場合，およびリダイレクタでエラーが発生した場合のそれぞれについて説明します。

Webコンテナでエラーが発生した場合

Webコンテナからのエラーステータスコードは，リダイレクタが受信します。リダイレクタは，エラーページの作成をWebサーバに委任し，Webサーバでエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

エラーページのカスタマイズの処理の流れを次の図に示します。

図4-44　ユーザ作成のエラーページ表示の流れ（Webサーバの機能を使用する場合）

図中の1.～3.について説明します。

クライアントから存在しないリソースへのアクセスがあると，Webコンテナでは，404エラーをWebサーバに返します。

リダイレクタは404エラーを受け取ると，設定情報※を基にして，404エラーに対応するエラーページの生成をWebサーバに依頼します。

Webサーバでは，設定情報※を基に404エラーに対応するエラーページ「missing.html」を，クライアントに返します。

リダイレクタでエラーが発生した場合

リダイレクタでエラーが発生すると，リダイレクタは設定情報を基にして，発生したエラーに対応するエラーページの生成をWebサーバに依頼します。Webサーバでは，設定情報※を基にエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

注※

エラーページをカスタマイズするためには，あらかじめ，エラーステータスコードとエラーページの対応づけをしておく必要があります。

対応づけの概要を次の図に示します。

図4-45　エラーステータスコードとエラーページの対応づけ（Webサーバの機能を使用する場合）

4.24.2　エラーページカスタマイズの注意事項

Webサーバ連携機能を使用する場合に，Webサーバの機能を使用してエラーページをカスタマイズするときの注意事項を次に示します。

対象となるエラーステータスコードは決まっています。指定できるエラーステータスコードについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

エラーページのカスタマイズは，WebサーバがHitachi Web Serverの場合だけ使用できます。このため，Microsoft IISと連携している場合に，workers.propertiesにエラーページのカスタマイズを設定しても，無効となります。

Servlet 2.3仕様に対応したWebアプリケーションで，Servlet仕様で規定されている，web.xmlの<error-page>タグによるカスタムエラー機能を使用している場合，Webコンテナは<error-page>タグに記述されているページへのアクセス結果をステータスコードとして返します。このため，<error-page>タグによるカスタムエラー機能を使用している場合は，<error-page>タグに記述されているページへのアクセスでエラーが発生したときに，エラーページのカスタマイズ機能が動作します。

エラーページのカスタマイズをするための設定が，workers.propertiesまたはhttpsd.confのどちらか一方にしかない場合，設定されているエラーがWebコンテナで発生しても，ユーザが設定したファイルは表示されません。

4.25　ドメイン名指定でのトップページの表示

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。この機能は，Webサーバ連携機能を使用する場合に使用できます。ここでは，index.htmlやindex.jspなどのファイルを，welcomeファイルと呼びます。

ドメイン名だけでトップページを表示させるには，welcomeファイルをルートコンテキストに配置する必要があります。ルートコンテキストとは，コンテキストルート※が空文字（コンテキストルートに名称が指定されていない）のコンテキストです。

注※

Webアプリケーションをまとめた管理単位を，コンテキストといいます。このコンテキストのルートパスをコンテキストルートといいます。Webアプリケーションにアクセスするときは，コンテキストルートをURL上に指定します。

コンテキストとコンテキストルートについて，次の図に示します。

図4-46　コンテキストとコンテキストルート

ドメイン名だけでトップページを表示させるには，次の設定が必要になります。

リダイレクタの設定
ルートコンテキストには，Webサーバ経由でアクセスします。このため，リダイレクタのURLマッピング定義で，該当するURLがリダイレクトされるように設定する必要があります。mod_jk.conf（Hitachi Web Serverの場合）またはuriworkermap.properties（Microsoft IISの場合）に設定します。

アプリケーションの設定
インポートしたJ2EEアプリケーションのコンテキストルートに空文字を指定します。

ドメイン名指定でトップページを表示するための設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

●注意事項

ドメイン名指定でのトップページの表示機能を使用する上での注意事項を次に示します。

コンテキストルートとルートコンテキストが同じ階層を持つ場合にアクセスされる階層
コンテキストルートとルートコンテキストが同じ階層を持つ場合，コンテキストルートの階層にアクセスされます。例を次に示します。

例

WebアプリケーションAがコンテキストルートexampleを持ち，WebアプリケーションBのコンテキストルートが空文字で，両方のWebアプリケーション内に「example」という階層を持つ場合の例を説明します。

この場合，「http://<ホスト名>/example」にアクセスすると，コンテキストルートを持つ，WebアプリケーションAのexample/index.jspが実行されます。

ただし，ディレクトリ内に，forwardやincludeがある場合で，例えばディレクトリ内のforwardにアクセスすると，ルートコンテキストのindex.jspにforwardされます。

Webアプリケーション内の構成
URLの先頭に「ejb」や「web」を使用することはできません。

使用できない例

http://<ホスト名>:<ポート番号>/ejb/

http://<ホスト名>:<ポート番号>/web/

このため，ルートコンテキストとしてデプロイするWebアプリケーションでは，「ejb」または「web」が先頭になるような構成にしないでください。

メッセージ本文での表示方法
コンソールやログファイルに出力されるメッセージでは，コンテキストルートは空文字で表示されます。

4.26　Webコンテナへのゲートウェイ情報の通知

クライアントと，WebサーバまたはインプロセスHTTPサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合で，welcomeファイルやForm認証画面への遷移時などにWebコンテナが自動的にリダイレクトするとき，Webコンテナではゲートウェイの情報を得ることができず，転送先のURLを正しく作成できないことがあります。

これを解決するために，ゲートウェイ指定機能を使用します。ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

ゲートウェイ指定機能は次のような場合に使用できます。

クライアントと，WebサーバまたはインプロセスHTTPサーバとの間にSSLアクセラレータを配置する場合
クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，welcomeファイルやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。
この場合，ゲートウェイ指定機能を使用して，スキームを常にhttpsとみなすように指定することで，正しくリダイレクトできるようになります。

Hostヘッダのないリクエストに対して，リクエストを受けたWebサーバまたはインプロセスHTTPサーバ以外へリダイレクトする必要がある場合
Hostヘッダのないリクエストをリダイレクトする場合，リダイレクト先URLのホスト名・ポート番号は，リクエストを受けたWebサーバのホスト名・ポート番号となります。
ゲートウェイ指定機能は，WebサーバまたはインプロセスHTTPサーバの前に負荷分散機を配置している場合などで，クライアントがアクセスするURLのホスト名・ポート番号が，リクエストを受けたWebサーバまたはインプロセスHTTPサーバと異なるときに使用します。これによって，クライアントからアクセスするホスト名・ポート番号が指定されるので，正しくリダイレクトできるようになります。

なお，インプロセスHTTPサーバを使用する場合，一つのWebコンテナに複数の異なる経路でアクセスする場合（複数のゲートウェイからWebコンテナにHTTPリクエストが転送される場合など），ゲートウェイ指定機能を使用できません。インプロセスHTTPサーバを使用する場合，ゲートウェイ指定機能を使用するには，Webコンテナへのアクセス経路は一つになる構成にする必要があります。

なお，Webコンテナにゲートウェイ情報を通知するための設定は，リダイレクタに指定します。Webコンテナにゲートウェイ情報を通知するための設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

●注意事項

ゲートウェイ指定機能を使用する上での注意事項を次に示します。

リダイレクト先URLのホスト名，およびポート番号の指定について
通常，ブラウザはHostヘッダを付けてリクエストを送信するため，リダイレクト先URLのホスト名やポート番号を指定する必要はありません。
なお，リクエストにHostヘッダがあるかどうかは，javax.servlet.http.HttpServletRequestクラスのgetHeaderメソッドに，引数「Host」を指定して呼び出すことで確認できます。

サーブレットAPIの動作について
ゲートウェイ指定機能の利用によって，一部のサーブレットAPIの動作が変わります。WebアプリケーションでAPIを利用するときには注意が必要です。
なお，動作が変わるサーブレットAPIについては，「12.7.1　実装時の留意事項」を参照してください。

web.xmlの<transport-guarantee>タグについて
ゲートウェイ指定機能でスキームをHTTPSとみなすように設定した場合，WebサーバへのリクエストがHTTPであってもHTTPSであると見なされます。このため，web.xmlの<transport-guarantee>タグでINTEGRALやCONFIDENTIALを指定してもHTTPSのURLへリダイレクトされないので注意してください。

CookieのSecure属性について
ゲートウェイ指定機能でスキームをHTTPSとみなすように設定している場合に，Webコンテナが生成したセッションIDを，Cookieによってクライアントに返すとき，そのCookieにはSecure属性が付与されます。

4.27　Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレス指定

Webコンテナでは，Webサーバ連携，インプロセスHTTPサーバ，および簡易Webサーバで利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するよう設定できます。

バインドするIPアドレスは，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

●注意事項

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。なお，ワイルドカードアドレスを使用する場合は，次のことに注意してください。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

簡易Webサーバで利用するIPアドレスには，ループバックアドレスを指定することはできません。簡易Webサーバで利用するIPアドレスにループバックアドレスを指定した場合は，ワイルドカードアドレスを使用してサーバが起動されます。

4.28　静的コンテンツのキャッシュ

一度アクセスした静的コンテンツは，メモリ上にキャッシュできます。

一度アクセスした静的コンテンツをメモリ上にキャッシュし，2回目以降のアクセスではキャッシュからブラウザにレスポンスを返すことで，静的コンテンツのレスポンスタイムを短縮できます。

Webコンテナでは，Webアプリケーション単位でキャッシュに使用するメモリサイズの上限と，キャッシュの対象とする静的コンテンツのファイルサイズの上限を設定して，静的コンテンツのキャッシュを制御できます。

静的コンテンツのキャッシュの制御には次の2種類の方法があります。

Webコンテナ単位の静的コンテンツのキャッシュの制御
静的コンテンツのキャッシュをWebコンテナ単位で制御する方法です。Webコンテナ単位に，Webアプリケーション単位でキャッシュするメモリサイズの上限値と，キャッシュを許可する静的コンテンツのファイルサイズの上限値を設定します。設定したWebアプリケーション単位のキャッシュに使用するメモリサイズの上限値，および静的コンテンツのファイルサイズの上限値は，WebコンテナにデプロイされているすべてのWebアプリケーションに適用されます。

Webアプリケーション単位の静的コンテンツのキャッシュの制御
静的コンテンツのキャッシュをWebアプリケーション単位で制御する方法です。Webアプリケーション単位に，キャッシュするメモリサイズの上限値，およびキャッシュを許可するファイルサイズの上限値を設定します。
Webアプリケーション単位での制御と，Webコンテナ単位での制御の両方を設定した場合，Webアプリケーション単位での制御の設定が優先されます。

なお，Webアプリケーション単位のキャッシュするメモリサイズが上限値を超えた場合，または静的コンテンツのファイルサイズが上限値を超えた場合は，メモリ上にはキャッシュしないで，毎回ファイルシステムからブラウザにレスポンスを返します。

静的コンテンツのキャッシュの設定は，設定する範囲ごとに，次の個所に設定します。

Webコンテナ単位の静的コンテンツのキャッシュの制御
J2EEサーバのプロパティとして指定します。

Webアプリケーション単位の静的コンテンツのキャッシュの制御
Webアプリケーションの属性（プロパティ）として設定します。

静的コンテンツのキャッシュの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

J2EEアプリケーションのリロード機能が有効な場合は，静的コンテンツのキャッシュ機能は無効になるので注意してください。

4.29　簡易Webサーバ機能

WebコンテナをHTTPサーバとして，スタブなどのダウンロードに利用します。この機能は，常に利用するように設定されています。

注意

簡易Webサーバは，本番運用時のWebサーバとしては利用できませんので注意してください。

また，この機能にアクセスできるホストを制限できます。簡易Webサーバへのアクセスを許可されていないホストからのアクセスがあった場合，J2EEサーバはそのアクセスを拒否※します。デフォルトでは，ローカルホストからのアクセスだけを許可します。ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。

なお，ホスト名またはIPアドレスは，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注※

J2EEサーバがアクセスを拒否すると，Webブラウザが自動で再接続をリトライすることがあります。再接続のリトライ回数は，Webブラウザによって異なるため，1度のアクセスで，アクセスが拒否されたことを示すメッセージが複数出力されることがあります。

アクセスを許可するホストをホスト名で指定した場合の注意

アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名の名前が解決されます。

ホスト名で指定した場合の注意事項を次に示します。

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

4.30　Webコンテナが返すエラーステータスコード

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。Webコンテナが返すエラーステータスコードと，エラーステータスコードを返す条件を次の表に示します。

表4-42　Webコンテナが返すエラーステータスコードと条件

エラーステータスコード
エラーステータスコードを返す条件

400　Bad Request
次のどちらかに該当する場合，エラーステータスコード400が返ります。

FORM認証で使用するログインページとして指定されたリソースに対して，クライアントから直接リクエストを送信し，その結果表示されたログインページからユーザ認証に成功した場合

次の三つの条件をすべて満たしているアクセスの場合

HTTPのバージョンが"HTTP/1.0"のとき

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承しているとき

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていないとき

Content-Lengthヘッダの値が2147483647より大きい，または0より小さいリクエストヘッダでアクセスされた場合

Content-Lengthヘッダの値が数値以外のリクエストヘッダでアクセスされた場合

Content-Lengthヘッダを複数含むリクエストヘッダでアクセスされた場合

401　Unauthorized
BASIC認証を必要とするリソースに対して，次のようなアクセスがあった場合，エラーステータスコード401が返ります。

不正なユーザ名，またはパスワードでアクセスされた場合

認証情報を含まないでアクセスされた場合（Authorizationヘッダがないアクセス）。

403　Forbidden
次のどれかに該当する場合，エラーステータスコード403が返ります。

BASIC認証，またはFORM認証を必要とするリソースに対して，認可できないユーザ名でアクセスされた場合

web.xmlで，auth-constraint要素にrole-name要素を指定しないで，すべてのアクセスを許可しないとするリソースにアクセスされた場合※1

静的コンテンツに対して，PUTまたはDELETEメソッドでアクセスされた場合

web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合※2

404　Not Found
次のどちらかのアクセスがあった場合，エラーステータスコード404が返ります。

存在しないリソースにアクセスされた場合

javax.servlet.UnavailableExceptionが発生しているサーブレット，またはJSPファイルにアクセスされた場合※3

405　Method Not Allowed
次の三つの条件をすべて満たしているアクセスの場合，エラーステータスコード405が返ります。

HTTPのバージョンが"HTTP/1.1"の場合

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承している場合

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていない場合

412　Precondition Failed
If-Matchヘッダ，またはIf-Unmodified-Sinceヘッダで指定した条件に一致しない静的コンテンツへのアクセスの場合，エラーステータスコード412が返ります。

416　Requested Range Not Satisfiable
次のどれかに当てはまる不正なRangeヘッダの値を使用した静的コンテンツへのアクセスの場合，エラーステータスコード416が返ります。

Rangeヘッダの値が"byte"から始まっていない

範囲定義に数字や"-"を使用していない

指定範囲が妥当ではない

500　Internal Server Error
次のどれかに該当する場合，エラーステータスコード500が返ります。

例外が発生するサーブレットまたはJSPファイルにアクセスされた場合※4

コンパイルに失敗したJSPファイルにアクセスされた場合

削除された静的コンテンツにアクセスされた場合※5

静的コンテンツへのアクセスでI/Oエラーが発生した場合

web.xmlの定義が不正な状態で，<auth-constraint>要素で保護されたリソースにアクセスされた場合※6

501　Not Implemented
静的コンテンツまたはjavax.servlet.http.HttpServletを継承したサーブレットに対して，GET，HEAD，POST，PUT，DELETE，OPTIONS，TRACEメソッド以外のHTTPメソッドでアクセスされた場合，エラーステータスコード501が返ります。

503　Service Unavailable
次のどれかに該当する場合，エラーステータスコード503が返ります。

リクエストの実行待ちキューに空きがない場合※7

javax.servlet.UnavailableExceptionが発生しているサーブレットまたはJSPファイルにアクセスされた場合※8

終了処理中のWebコンテナに対してアクセスされた場合

予期しないエラーまたは例外によって，異常な状態になったWebアプリケーションにアクセスされた場合

注※1　Webアプリケーションのバージョンが2.4の場合に該当します。

注※2　usrconf.propertiesのwebserver.connector.redirect_https.portキーに転送先のhttpsのポート番号を設定していない場合が該当します。

注※3　Webアプリケーションのバージョンが2.4の場合で，永久的に利用できないことを示すjavax.servlet.UnavailableExceptionが発生し，サーブレットおよびJSPファイルで例外をcatchしていないときが該当します。

注※4　次のような場合が該当します。

Webアプリケーションのバージョンが2.4の場合
サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合
web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

注※5　Webアプリケーションのリロード機能，JSPファイルの再コンパイル機能，またはJ2EEアプリケーションのリロード機能を使用しない場合が該当します。

注※6　web.xmlで<auth-constraint>要素に<role-name>要素が定義され，<login-config>要素が定義されていない場合に該当します。この状態でアプリケーションを開始すると，KDJE39150-Wの警告メッセージがコンソール画面，およびメッセージログに出力されます。

注※7　Webアプリケーション単位の同時実行スレッド数制御，またはURLグループ単位の同時実行スレッド数制御を設定している場合が該当します。

注※8　次のような場合が該当します。

Webアプリケーションのバージョンが2.4の場合
一時的に利用できないことを示す，javax.servlet.UnavailableExceptionが発生し，サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合
web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

4.31　前バージョンからのJSPの移行

07-00より前のバージョンと07-00以降のバージョンでは，JSPのコンパイルの動作が異なります。Cosminexusでは，JSPトランスレーション時に，JSP仕様に従ってJSPの内容がチェックされるため，JSPトランスレーション時にエラーになって移行できないことがあります。その場合，JSPトランスレーション下位互換機能を使用すると，07-00より前のバージョンと07-00以降のバージョンでJSPのコンパイルの動作を同じように設定できて，エラーが発生しないようにすることができます。

JSPトランスレーション下位互換機能を使用するには，簡易構築定義ファイルで設定する方法と，cjjspcコマンドを実行するときにオプションに指定する方法の二つがあります。簡易構築定義ファイルで設定する方法については，マニュアル「Cosminexus　簡易構築・運用ガイド」の論理J2EEサーバで指定できるパラメタについての説明を参照してください。cjjspcコマンドを実行するときにオプションに指定する方法については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

07-00以降のバージョンで，JSPトランスレーション下位互換機能を使用するとき（07-00より前のバージョンと同じコンパイルの動作をするとき）とJSPトランスレーション下位互換機能を使用しないときの，コンパイルの動作の差異を次に示します。

JSPのカスタムタグに，javax.servlet.jsp.tagext.TagExtraInfoクラスのサブクラスで指定するスコープや，TLDファイルのvariable要素内のscope要素で指定するスコープの指定が重複した，同一名称のスクリプト変数を定義する場合

JSPトランスレーション下位互換機能を使用する

2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数の変数宣言をする。

JSPトランスレーション下位互換機能を使用しない

2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数の変数宣言をしない。

インスタンス化できないクラス名をclass属性に指定した場合

JSPトランスレーション下位互換機能を使用する

2回目以降の<jsp:useBean>タグで指定したid属性値がエラーにならないで，Beanが取得できる。

JSPトランスレーション下位互換機能を使用しない

JSPのトランスレーション時にエラーになる。

Expressionの指定が許されていないタグの属性値に，Expressionを指定した場合

JSPトランスレーション下位互換機能を使用する

Expressionの指定が許されていないタグの属性値に指定したExpressionは，文字列として扱われる。

JSPトランスレーション下位互換機能を使用しない

JSPのトランスレーション時にエラーになる。

タグの属性値が「"<%=」（または「'<%=」）で開始していて，「%>"」（または「%>'」）で終了していない場合

JSPトランスレーション下位互換機能を使用する

「"」（または，「'」）で囲まれた属性値を，文字列として処理する。

JSPトランスレーション下位互換機能を使用しない

「"」（または，「'」）で囲まれた属性値を，Expressionとして処理する。

taglibディレクティブの前に，taglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合

JSPトランスレーション下位互換機能を使用する

カスタムタグではなく文字列として扱う。

JSPトランスレーション下位互換機能を使用しない

JSPのトランスレーション時にエラーになる。

JSPを移行するときの注意事項については，次の個所を参照してください。

4.32.8　カスタムタグのスクリプト変数の定義に関する注意事項

4.32.9　<jsp:useBean>タグのclass属性に関する注意事項

4.32.10　TLDファイルのバージョンに関する注意事項

4.32.11　タグの属性値のExpressionチェックに関する注意事項

4.32.12　タグの属性値に指定するExpressionに関する注意事項

4.32.13　taglibディレクティブのprefix属性に関する注意事項

4.32　サーブレット，JSPの実装

この節では，サーブレットおよびJSPを実装するときの注意事項について説明します。

＜この節の構成＞

4.32.1　サーブレット，JSP実装時共通の注意事項

4.32.2　サーブレット実装時の注意事項

4.32.3　Servlet 2.4仕様で追加，変更された仕様についての注意事項

4.32.4　JSP実装時の注意事項

4.32.5　JSP 2.0仕様で追加，変更された仕様についての注意事項

4.32.6　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

4.32.7　サーブレットでのアノテーションの使用

4.32.8　カスタムタグのスクリプト変数の定義に関する注意事項

4.32.9　<jsp:useBean>タグのclass属性に関する注意事項

4.32.10　TLDファイルのバージョンに関する注意事項

4.32.11　タグの属性値のExpressionチェックに関する注意事項

4.32.12　タグの属性値に指定するExpressionに関する注意事項

4.32.13　taglibディレクティブのprefix属性に関する注意事項

4.32.1　サーブレット，JSP実装時共通の注意事項

Cosminexus上で動作するアプリケーションのプログラムとして，サーブレット，JSPを実装するときの共通の注意事項を示します。

＜この項の構成＞

(1)　Webアプリケーションのサポート範囲

(2)　トランザクションとJDBCコネクション利用時の注意

(3)　パッケージ名の指定に関する注意

(4)　Cookie利用時の注意

(5)　特別な意味を持つ入力値の表示に関する注意

(6)　コミット後のエラーページの表示に関する注意

(7)　PrintWriter，JSPWriterクラス利用時の性能向上について

(8)　javax.servlet.error.XXXXXによるエラー情報参照時の注意

(9)　ファイルアクセス時の注意

(10)　例外発生時のエラーページの設定について

(11)　クラスローダの取得に関する注意

(12)　URLConnectionクラス使用時の注意

(13)　ネイティブライブラリのロードに関する注意

(14)　ユーザスレッドの使用方法

(15)　セッション情報の永続化について

(16)　initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ

(17)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について

(18)　バイナリデータを含むWebアプリケーションの操作について

(19)　レスポンスの文字エンコーディングに関する注意

(20)　javax.serlvet.ServletRequestクラスのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について

(1)　Webアプリケーションのサポート範囲

Webアプリケーションのバージョンは，web.xmlに記述するServlet仕様のバージョン情報で識別されます。上位のバージョンのWebアプリケーションは下位のバージョンの機能を使用できます。下位のバージョンのWebアプリケーションは上位のバージョンの機能を使用できません。

Webアプリケーションのバージョンごとに，使用できる機能範囲を次の表に示します。

表4-43　Webアプリケーションのサポート範囲

Webアプリケーションのバージョン | サーブレット | JSP | タグライブラリ※
2.2 | 2.3 | 2.4 | 1.1 | 1.2 | 2.0 | 1.1 | 1.2 | 2.0
2.2 | ○ | × | × | ○ | × | × | ○ | × | ×
2.3 | ○ | ○ | × | ○ | ○ | × | ○ | ○ | ×
2.4 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○

（凡例）○：使用できる　×：使用できない

注※

タグライブラリのバージョンとは，タブライブラリ･ディスクリプタ（TLDファイル）のバージョンを表します。

なお，Servlet 2.2仕様およびServlet 2.3仕様に対応したWebアプリケーションで，Servlet 2.4仕様およびJSP 2.0仕様の機能を使用した場合にエラーとなる場合があります。エラーとなる機能および処理を次の表に示します。

表4-44　Servlet 2.2／2.3仕様に対応するWebアプリケーションからServlet 2.4仕様の機能を使用した場合のエラー

仕様
使用する機能
エラー時の処理

Servlet 2.4
新規API呼び出し
Servlet 2.4仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規リスナ登録
Webアプリケーションの開始時にメッセージKDJE39297-Wがメッセージログに出力され，そのリスナ定義は無視されます。

JSP 2.0
新規ディレクティブ新規スタンダード・アクション
サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され，JSPコンパイルエラーとなります。

タグファイル

TLDを使用しない場合

taglibディレクティブで新規属性となるtagdir属性が不正として，サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され，JSPコンパイルエラーとなります。

TLDを使用する場合

TLD 2.0を使用したエラーになります。

TLD 2.0
次に示すTLDファイルは，Webアプリケーション開始時にチェックされます。該当する場合，メッセージログにKDJE39293-Wが出力され，無視されます。

web.xmlの<taglib><tablib-location>に指定されたTLDファイル

/WEB-INF/lib下のJarファイル内の/META-INF以下に配置されたTLDファイル

上記以外のTLDファイルは，JSPコンパイル時にチェックされます。初回アクセス時など，JSPファイルのコンパイル時は，サーブレットログにKDJE 39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され，JSPコンパイルエラーとなります。

シンプル・タグ・ハンドラ
サーブレットログにKDJE39145-Eのメッセージを，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され，JSPコンパイルエラーとなります。

Servlet 2.2仕様およびServlet 2.3仕様から，Servlet 2.4仕様にWebアプリケーションのバージョンアップする場合の作業，および注意事項については，「4.32.6　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点」を参照してください。

(2)　トランザクションとJDBCコネクション利用時の注意

サーブレット，JSPでトランザクションを利用する場合，該当するサービスメソッドでJDBCコネクションを取得し，該当するサービスメソッドが終了する前に解放してください。トランザクションが開始しているサーブレットおよびJSPでは，次に示すJDBCコネクションの使用はサポートされません。

サーブレット，JSPのサービスメソッドが生成したスレッド上のJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドから呼び出した別のサーブレット，JSPのサービスメソッドでJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドのinitメソッドで取得したJDBCコネクションを使用する。

インスタンス変数に格納されたJDBCコネクションを使用する。※

注※

SingleThreadModelのサーブレットおよびJSPを使用した場合は，インスタンス変数にJDBCコネクションを格納できます。

(3)　パッケージ名の指定に関する注意

不正なパッケージ名が指定されたクラスをサーブレットおよびJSPで使用した場合，ブラウザからアクセスしたときにステータスコード500のエラーになります。例えば，作成したクラスファイルを正しく配置して，ブラウザからアクセスしても，パッケージ名の宣言に不正があった場合は，該当クラスが見つかりません。この場合，ステータスコード500のエラーが返されます。

(4)　Cookie利用時の注意

日本語などの2バイトコードを含むCookieは使用しないでください。使用した場合，サーブレットおよびJSPで利用しているHTTPセッションが失われる場合があります。

Cookieでセッション管理をする場合，ホスト名によるURLでアクセスしたサーブレットまたはJSPで生成されたセッションは，ホスト名の代わりにIPアドレスを指定したURLでアクセスしたサーブレットまたはJSPに引き継がれません（逆も同様です）。

(5)　特別な意味を持つ入力値の表示に関する注意

フォームなどで「<」や「>」などの特別な意味を持つ文字の入力値をそのまま表示した場合，悪意のあるユーザが<SCRIPT>，<OBJECT>，<APPLET>，<EMBED>のスクリプトなどを実行できるタグを使用して，重大なセキュリティ上の問題を引き起こすおそれがあります。アプリケーション開発者は，ユーザから入力されたデータに対して必ず検査をする処理を追加して，特別な意味を持つ文字を排除する必要があります。

(6)　コミット後のエラーページの表示に関する注意

サーブレットまたはJSPでレスポンスがコミットされたあとは，例外などのエラーが発生したとしても，次に示すエラーページはブラウザに表示されません。

web.xmlで指定したエラーページ

JSPのpageディレクティブのerrorPage属性で指定したエラーページ

Webコンテナサーバが出力するデフォルトのエラーページ

レスポンスのコミットは，ユーザがServletResponseクラスのflushBufferメソッドなどを明示的に呼び出してコミットする場合以外にも，レスポンスのバッファが満杯になって自動的にWebコンテナがコミットすることがあります。

サーブレットまたはJSPでコミットされているかどうかを調べるには，ServletResponseクラスのisCommittedメソッドを使用します。また，バッファサイズの変更は，サーブレットの場合はServletResponseクラスのsetBufferSizeメソッドで，JSPの場合はpageディレクティブのbuffer属性の指定で行うことができます。

(7)　PrintWriter，JSPWriterクラス利用時の性能向上について

PrintWriterクラスおよびJSPWriterクラスのprintメソッドとprintlnメソッドの呼び出し回数を少なくすることで，アクセス回数を減らし，性能を向上できます。例えば，StringBufferクラスを使用し，最後にprintlnメソッドを呼び出すようにして，printおよびprintlnメソッドの呼び出し回数を削減します。

(8)　javax.servlet.error.XXXXXによるエラー情報参照時の注意

Servlet 2.3仕様で定義されているjavax.servlet.error.XXXXX属性は，web.xmlの<error-page>タグに指定されたサーブレットまたはJSP内でそのエラーページを実行する要因となったエラー情報を参照するためのものです。web.xmlの<error-page>タグに指定されたサーブレットまたはJSP以外からは，これらの属性を参照しないでください。

(9)　ファイルアクセス時の注意

ファイルにアクセスする場合は，必ず絶対パスを指定してください。相対パスを指定すると，J2EEサーバはWebコンテナサーバの実行ディレクトリからの相対パスによって目的のパスを検索しようとします。ServletContextクラスのgetRealPathメソッドで相対パスを指定すると，WARファイルを展開したディレクトリでの相対パスが取得されます。

また，ファイルにアクセスする場合は，必ずファイルをクローズしてください。WARファイル展開ディレクトリでファイルにアクセスしてクローズしないと，J2EEサーバで正常にアンデプロイできなくなります。WARファイルの展開ディレクトリ下のパスを指定していない場合でもファイルをクローズしていないと，J2EEサーバの起動中にファイルを削除できないなどの現象が発生します。

(10)　例外発生時のエラーページの設定について

JSP，サーブレットへのアクセスで例外が発生した場合，Webコンテナのデフォルトの処理では例外のステータスコードをブラウザに返します。このデフォルトの処理を変える場合はJSPのerrorPageの指定やweb.xmlでエラーページを設定してください。

(11)　クラスローダの取得に関する注意

J2EEアプリケーション内のコードからCosminexus Component Containerのクラスローダを取得して，次に示すメソッドを使用する場合に，java.net.JarURLConnectionクラスが使用されます。

getResource(String).openConnection().getInputStream()

getResource(String).openStream()

上記メソッドが呼び出される過程でjava.net.JarURLConnectionクラスのopenConnectionメソッドが呼び出され，該当するURLに指定されたJARファイルがオープンされます。このJARファイルはcloseメソッドを明示的に呼ばないかぎり，オープンされたままになり削除できません。上記メソッドはJ2EEアプリケーション内で使用しないでください。また，JARファイルに対する操作が必要でjava.net.JarURLConnectionクラスのopenConnectionメソッドを使用する場合には，該当するJARファイルに対してcloseメソッドを必ず呼び出すようにしてください。

(12)　URLConnectionクラス使用時の注意

java.net.URLConnectionクラスはsetUseCaches(boolean)メソッドを使用して，指定されたURLに対してコネクションを取得するときにキャッシュの情報を利用するかどうかを指定できます。URLConnectionクラスに対してsetUseCaches(false)メソッドを指定した場合に，コネクションごとに対象のオブジェクトが生成されます。J2EEアプリケーション内のコードから使用する場合には，J2EEサーバのJavaVMがメモリ不足となるおそれがあります。

(13)　ネイティブライブラリのロードに関する注意

System.loadLibraryメソッドを使用して，サーブレットおよびJSPからネイティブライブラリをロードしないでください。サーブレットおよびJSPでネイティブライブラリをロードすると，JNI仕様の制約によって，java.lang.UnsatisfiedLinkErrorが発生することがあります。ネイティブライブラリのロードが必要な場合は，System.loadLibraryメソッドを呼び出すコンテナ拡張ライブラリを作成し，サーブレットおよびJSPからコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については，「10.　コンテナ拡張ライブラリ」を参照してください。

(14)　ユーザスレッドの使用方法

アプリケーションを構成するサーブレットおよびJSPからスレッドを生成して，使用できます。ユーザがプログラムの中で明示して生成するスレッドのことを，ユーザスレッドといいます。

ユーザスレッドは，生成後の動作のしかた（ライフサイクル）によって，次の二つに分けられます。

サービスメソッドやinitメソッドの範囲内で動作させる。

サービスメソッドやinitメソッドのバックグラウンドで動作させる。

ユーザスレッドの使用条件

ユーザスレッドは，Enterprise Beanでは使用できません（EJB仕様で，Enterprise Beanからのスレッドの生成が禁止されているため）。

ユーザスレッドが使用できるApplication Serverのサーバモードを次に示します。

表4-45　ユーザスレッドの前提条件（サーバモード）

サーバモード | 使用可否
J2EEサーバモード | 1.4モード | ○
ベーシックモード | ×
サーブレットエンジンモード | ○※

（凡例）○：使用できる　×：使用できない

注※

サーブレットエンジンモードでサポートされている範囲で機能を使用できます。ただし，コネクションプールは使用できません。

ユーザスレッドを使用する場合のライフサイクルについて説明します。

(a)　サービスメソッドやinitメソッドの範囲内で動作させる場合

サービスメソッドやinitメソッドでユーザスレッドの処理を完了させるモデルです。このモデルの処理の流れを次の図に示します。

図4-47　サービスメソッドやinitメソッドの範囲内で動作させる場合の処理

サービスメソッドやinitメソッドの呼び出しの範囲内で，ユーザスレッドを生成します。サービスメソッドやinitメソッドでは，joinメソッドによってユーザスレッドの処理が完了するのを待ってから，リターンします。

(b)　サービスメソッドやinitメソッドのバックグラウンドで動作させる場合

サービスメソッドやinitメソッドでユーザスレッドを生成し，その後ユーザスレッドをバックグラウンドで動作させるモデルです。このモデルの処理の流れを次の図に示します。

図4-48　サービスメソッドやinitメソッドのバックグラウンドで動作させる場合の処理

ユーザスレッドを生成したサービスメソッドやinitメソッドは，ユーザスレッドを生成したあと，処理の完了を待たないでリターンします。ただし，アプリケーションを停止したあとは，ユーザスレッドからJ2EEサービスを利用できなくなります。したがって，アプリケーションの停止によってサーブレットやJSPのdestroyメソッドが呼ばれる前に，ユーザスレッドの処理を完了しておく必要があります。

(15)　セッション情報の永続化について

Webコンテナではセッション情報の永続化はサポートされません。Webコンテナではセッション情報は，正常，異常に関係なくWebコンテナが終了すると失われます。セッション情報を保持したい場合は，セッションフェイルオーバ機能を使用してください。

また，web.xmlで<distributable>タグを指定した場合，およびSerializableでないオブジェクトをセッション情報として登録した場合もIllegalArgumentExceptionは発生しません。

(16)　initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ

initメソッドおよびdestroyメソッドをオーバーライドしていないサーブレットを初期化または終了すると，次の形式のログがサーブレットログに出力されます。

メッセージID：KDJE39037-I

メッセージ本文：path="aa....aa" :bb....bb: init※

aa....aa

「/」から始まるコンテキストパスを表します。

bb....bb

web.xmlの<servlet-name>タグで指定したサーブレット名を表します。デフォルトマッピングのサーブレットの場合は，「org.apache.catalina.INVOKER.<クラス名>」となります。

注※

initメソッドの場合は「init」，destroyメソッドの場合は「destroy」となります。出力されるメッセージは，それぞれjavax.servlet.GenericServletクラスのinitメソッドおよびdestroyメソッドで出力されるログです。したがって，initメソッドまたはdestroyメソッドをオーバーライドしたサーブレットではこれらのメッセージは出力されません。

また，JSPの場合は，pageディレクティブのextends属性で指定するJSPの基底クラスでinitメソッドおよびdestroyメソッドをオーバーライドしなかった場合，同様のメッセージが出力されます。その場合，サーブレット名は"com.hitachi.software.web.servlet-name.jsp"となります。JSPでpageディレクティブのextends属性を指定しなかった場合は，initメソッドのログだけが出力され，destroyメソッドのログは出力されません。

(17)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について，Servletで例外をスローした場合とJSPファイルで例外をスローした場合の二つに分けて説明します。

(a)　Servletで例外をスローした場合

Servletでスローした例外クラスがjava.lang.Error，またはその派生クラスの場合

javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。Servletでスローした例外は，javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。

Servletでスローした例外クラスがjava.lang.Error，またはその派生クラス以外のクラスの場合

Servletでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

(b)　JSPファイルで例外をスローした場合

●エラーページがJSPファイルの場合

web.xmlの<error-page>タグでエラーページを指定した場合

web.xmlの<error-page>タグでエラーページを指定した場合について，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

JSP 1.2

JSPファイルでスローした例外クラスが次のクラスのどれかであれば，JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

java.io.IOException，またはその派生クラス

java.lang.RuntimeException，またはその派生クラス

javax.servlet.ServletException，またはその派生クラス

JSPファイルでスローした例外クラスが上記以外の場合，javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。JSPファイルでスローした例外は，javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。

pageディレクティブのerrorPage属性でエラーページを指定した場合

pageディレクティブのerrorPage属性でエラーページを指定した場合について，エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合とfalseを指定した場合に分けて示します。

エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合

JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

エラーページでpageディレクティブのisErrorPage属性にfalseを指定した場合

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。

●エラーページがServletの場合

web.xmlの<error-page>タグでエラーページを指定した場合

エラーページがJSPファイルの場合の，web.xmlの<error-page>タグでエラーページを指定した場合と同様です。

pageディレクティブのerrorPage属性でエラーページを指定した場合

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。

(18)　バイナリデータを含むWebアプリケーションの操作について

バイナリデータを含むWebアプリケーションでは，次のことに注意してください。

クライアントから送信されたバイナリデータへのリクエストを実行する場合
バイナリデータへのリクエストで適用されるフィルタ内で，レスポンスオブジェクトからのPrintWriterを取得しないでください。

クライアントから送信されたリクエストを処理するサーブレットまたはJSPがディスパッチする場合
次の場所では，レスポンスオブジェクトからのPrintWriterを取得しないでください。

バイナリデータへのリクエストで適用されるフィルタ内

バイナリデータにディスパッチするサーブレットまたはJSP内

参考

バイナリデータとは，拡張子にマッピングされたMIMEタイプが"text/"から始まっていない静的コンテンツ，またはマッピングが存在しない静的コンテンツです。

(19)　レスポンスの文字エンコーディングに関する注意

JSPまたはサーブレットのレスポンスボディの文字エンコードディングが，UTF-16（16ビットUCS変換形式）の場合，ブラウザによって正しく表示できない場合があります。その場合は，JSPまたはサーブレットの文字エンコードディングに，UTF-16BE（16ビットUCS変換形式のビッグエンディアンバイト順），またはUTF-16LE（16ビットUCS変換形式のリトルエンディアンバイト順）を使用してください。

(20)　javax.serlvet.ServletRequestクラスのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について

getServerNameメソッド，およびgetServerPortメソッドの戻り値について説明します。

Servlet2.4仕様では，Hostヘッダの有無によって，getServerNameメソッド，およびgetServerPortメソッドの戻り値が異なります。Servlet2.4仕様でのgetServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。

表4-46　getServerNameメソッド，およびgetServerPortメソッドの戻り値（Servlet2.4仕様の場合）

Hostヘッダの有無 | getServerNameメソッドの戻り値 | getServerPortメソッドの戻り値
有り | Hostヘッダの「:」より前の部分 | Hostヘッダの「:」よりあとの部分
無し | 解決されたサーバ名またはIPアドレス | クライアントとの接続を受け付けたサーバのポート番号

Cosminexusでは，getServerNameメソッド，およびgetServerPortメソッドの戻り値は，HTTPリクエストと，使用する機能の組み合わせによって得られます。なお，HTTP 1.1のリクエストにHostヘッダが含まれない場合，HTTP 1.1仕様に従って，400エラーとなります。また，HTTP 1.1仕様では，リクエストラインのリクエストURIが絶対URIの場合，ホストにはリクエストURIのホストを使用して，Hostヘッダの内容は無視するように定義されています。なお，Servlet仕様では明記されていませんが，HTTP仕様に従って，リクエストラインのURIに含まれるホスト名を優先するようになっています。

HTTPリクエストと，使用する機能の組み合わせによって得られる，getServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。なお，ゲートウェイ指定機能を使用している場合の，getServerNameメソッド，およびgetServerPortメソッドの戻り値については，表4-48を参照してください。

表4-47　getServerNameメソッド，およびgetServerPortメソッドの戻り値（Cosminexusの場合）

HTTPリクエスト | 使用する機能 | getServerNameメソッドの戻り値 | getServerPortメソッドの戻り値
Hostヘッダの有無 | リクエストラインのURIの種類
有り | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
簡易Webサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
相対URI | Webサーバ連携 | Hostヘッダのホスト名 | Hostヘッダのポート番号
インプロセスHTTPサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
簡易Webサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
無し | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
簡易Webサーバ | J2EEサーバのホスト名またはIPアドレス※1 | 簡易Webサーバのポート番号
相対URI | Webサーバ連携 | Webサーバのホスト名またはIPアドレス※2 | Webサーバのポート番号
インプロセスHTTPサーバ | J2EEサーバのホスト名またはIPアドレス※1 | インプロセスHTTPサーバのポート番号
簡易Webサーバ | J2EEサーバのホスト名またはIPアドレス※1 | 簡易Webサーバのポート番号

注※1　java.net.InetAddress.getLocalHostメソッド，またはgetHostNameメソッドの戻り値となります。

注※2　Hitachi Web Serverを使用する場合，ServerNameディレクティブに指定した値となります。ServerNameディレクティブについては，マニュアル「Hitachi Web Server」を参照してください。

ゲートウェイ指定機能使用時のgetServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。

表4-48　ゲートウェイ指定機能使用時のgetServerNameメソッド，およびgetServerPortメソッドの戻り値（Cosminexusの場合）

HTTPリクエスト | 使用する機能 | getServerNameメソッドの戻り値 | getServerPortメソッドの戻り値
Hostヘッダの有無 | リクエストラインのURIの種類
有り | 絶対URI | Webサーバ連携 | リクエストラインのホスト名 | リクエストラインのポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
相対URI | Webサーバ連携 | Hostヘッダのホスト名 | Hostヘッダのポート番号
インプロセスHTTPサーバ | Hostヘッダのホスト名 | Hostヘッダのポート番号
無し | 絶対URI | Webサーバ連携 | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバ | リクエストラインのホスト名 | リクエストラインのポート番号
相対URI | Webサーバ連携 | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号
インプロセスHTTPサーバ | ゲートウェイ指定機能で指定したホスト名 | ゲートウェイ指定機能で指定したポート番号

4.32.2　サーブレット実装時の注意事項

サーブレットを実装するときの注意事項を示します。

＜この項の構成＞

(1)　入出力ストリーム利用時の注意

(2)　ロケール設定時の注意

(3)　URI取得時の注意

(4)　POSTデータの読み込み失敗時の動作について

(5)　属性の変更に対するイベント通知時の注意

(6)　ServletContextインタフェース利用時の注意

(7)　Webアプリケーションに含まれるディレクトリにアクセスするときの注意

(8)　ServletRequestインタフェース利用時の注意

(9)　プロセス内で複数回実行してはならない処理を実装する場合の注意

(10)　ゲートウェイ指定機能を使用する場合の注意

(11)　ゲートウェイ使用時の注意

(12)　ServletContextオブジェクトに登録する日立独自の属性

(13)　ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

(14)　javax.servlet.ServletResponseクラスのresetメソッドについての注意

(15)　setMaxInactiveIntervalメソッドの引数に0を指定した場合の動作

(16)　java.io.BufferedReaderのmark操作について

(17)　setVersionメソッドの引数に1を指定した場合の動作

(18)　getRequestDispatcherメソッドでのパスの指定について

(19)　setBufferSizeメソッドを使用してバッファサイズを変更する場合の注意

(20)　HTTPレスポンスのContent-Typeヘッダについての注意

(1)　入出力ストリーム利用時の注意

ServletInputStreamのavailableメソッドは，常に0を返します。

ServletOutputStreamクラスのprint(char c)メソッドの引数には，0x00～0xFFの範囲で指定してください。範囲外の値を指定するとjava.io.CharConversionExceptionが発生します。

ServletInputStreamクラスでは，markメソッドおよびresetメソッドをサポートしていません。また，markSupportedメソッドは常にfalseを返します。

ServletInputStreamクラスからデータを読み出したあとに転送（forward）した場合，転送先のServletInputStreamクラスから読み出されるデータは，転送する前に読み出された位置からのものとなります。また，転送する前にServletInputStreamクラスからすべてのデータを読み出した場合，転送先のリクエストパラメタは空となります。

(2)　ロケール設定時の注意

ServletResponseクラスのsetLocaleメソッドにLocale.JAPANESEを指定した場合，Content-TypeヘッダのcharsetはShift_JIS（シフトJIS）になります。

(3)　URI取得時の注意

HttpServletRequestクラスのgetRequestURIメソッドでは，最適化されたURIが返されます。例えば，「xxx//yyy/zzz」は「xxx/yyy/zzz」に，「xxx/yyy/../zzz」は「xxx/zzz」のように変換されます。

(4)　POSTデータの読み込み失敗時の動作について

WebサーバでPOSTデータの読み込みに失敗した場合，Webコンテナで動作するサーブレットでは，ServletRequestクラスの次に示すメソッドの呼び出し時にIllegalStateException例外が発生します。

getParameterメソッド

getParameterNamesメソッド

getParameterValuesメソッド

getParameterMapメソッド

(5)　属性の変更に対するイベント通知時の注意

ServletContextAttributeListenerインタフェース，HttpSessionAttributeListenerインタフェース，およびServletRequestAttributeListenerでは，Webコンテナが内部で使用している属性の追加，削除，更新があった場合にもイベントが通知される場合があります。通知されたイベントの属性名を参照して，Webアプリケーションで使用している属性名以外の場合には無視するようにしてください。

(6)　ServletContextインタフェース利用時の注意

ServletContextインタフェースのgetResourcePathsメソッドによって得られるjava.util.Setは参照用です。このjava.util.Setに対し，要素の追加，削除の操作をしないでください。add，addAll，clear，remove，およびremoveAllメソッドを使用するとIllegalStateException例外が発生する場合があります。

ServletContextインタフェースのgetContextメソッドの引数には，存在するコンテキストルート名を使用したURLを指定してください。存在しないコンテキストルート名を使用したURLを指定した場合の動作は保証されません。

ServletContextインタフェースのgetResourceメソッドおよびgetResourceAsStreamメソッドには，該当Webアプリケーションに含まれるリソースを指定してください。該当Webアプリケーション外のリソースを指定した場合の動作は保証されません。

(7)　Webアプリケーションに含まれるディレクトリにアクセスするときの注意

Webアプリケーションに含まれるディレクトリにアクセスするときは，クエリ文字列およびPOSTデータがリダイレクト先リソースで取得できないことがあるため，クエリ文字列およびPOSTデータは付けないようにしてください。

(8)　ServletRequestインタフェース利用時の注意

ServletRequestインタフェースのgetParameterメソッドの引数に指定するパラメタ名，および戻り値として得られるパラメタ値に「=」を含む文字列を利用する場合は，クエリ文字列またはPOSTデータに指定するときに「=」をエンコードして指定してください。具体的には，次のような形式です。

"a=b%3Dc"

また，getParameterNamesメソッド，getParameterValuesメソッド，およびgetParameterMapメソッドについても「=」をエンコードして指定してください。

ServletRequestインタフェースのgetRemoteHostメソッドは，リクエストを送信したクライアントのホスト名を返しますが，Webサーバがホスト名を解決できないか，解決しないように設定されている場合はIPアドレスを返します。
既定の設定ではWebサーバの設定がされていないため，IPアドレスを返します。ホスト名を取得する場合は，Webサーバの設定を変更する必要があります。ただし，設定を変更すると，ホスト名の解決のため，レスポンスが遅くなる場合があります。Webサーバの設定の変更方法については，マニュアル「Hitachi Web Server」を参照してください。

(9)　プロセス内で複数回実行してはならない処理を実装する場合の注意

1プロセス内で複数回実行してはならない処理をサーブレット中に記述する場合，サーブレットの実行とその処理が同期することがないようにしてください。特に，OTMとの通信を開始するための初期化処理の中には，インスタンスを削除しても終了しない常駐スレッドを生成するものがあります。例えば，Cosminexus TPBrokerの初期化関数であるORB.initメソッドは，呼び出されるたびにガーベージコレクション実行のための監視用常駐スレッドを生成し，このスレッドはプロセス終了まで消えません。そのため，１プロセス内でORB.initメソッドを必要以上に実行すると，不要なガーベージコレクション処理が増え，システム全体の性能が著しく低下するなどの悪影響があります。

このような事態を避けるため，プロセス中で1回だけ実行させたい処理をサーブレットに記述する場合には，その処理がプロセス中で実行済みかどうかをあらかじめ判定する必要があります。具体的には，ある処理が実行済みかどうかの状態を格納する条件フラグとしてstatic変数を任意のクラス中で用意します。static変数の値が「未実行」を意味するものである場合にだけ処理を実行し，値を「実行済み」を意味するものに変更することで，その処理の実行回数をプロセス中で1回だけに限定できます。ただし，次の2点に注意してください。

任意のクラスでstatic変数を使用する場合は，usrconf.propertiesまたはhitachi_web.propertiesに次の設定をしないでください。
・webserver.context.reloadable=true
・webserver.jsp.recompilable=true
設定した場合，そのクラスのインスタンスが自動的に破棄されて，再生成されることがあるため，それに伴ってstatic変数の値も初期化されてしまうことがあります。usrconf.propertiesとhitachi_web.propertiesの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

あるスレッドが条件フラグであるstatic変数の値を参照してから値を変更するまでの間に，ほかのスレッドが同様の処理を実行することがないよう，この処理を実行するメソッドにsynchronizedキーワードを指定してください。この方法を用いてCosminexus TPBrokerの初期化関数ORB.initメソッドが1回だけ呼び出されるようにするためのコーディング例を次に示します。

static org.omg.CORBA.ORB _orb=null;
public static synchronized org.omg.CORBA.ORB getORB(String[] args, Properties props){
 if(_orb==null){
   _orb=org.omg.CORBA.ORB.init(args,props);
 }
return _orb;
}

(10)　ゲートウェイ指定機能を使用する場合の注意

Webコンテナにゲートウェイ情報を通知し，welcomeファイルやFORM認証画面に正しくリダイレクトするゲートウェイ指定機能を使用できます。ゲートウェイ指定機能については，「4.26　Webコンテナへのゲートウェイ情報の通知」を参照してください。

ゲートウェイ指定機能を使用する場合，一部のサーブレットAPIの動作が変わります。ゲートウェイ指定機能使用時のサーブレットAPIの注意事項を，使用するメソッドごとに示します。

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッド
引数に相対URLを指定し，Hostヘッダのないリクエストの場合，リダイレクト先URLのホスト名とポート番号は，ゲートウェイ指定機能で指定した値となります。引数に相対URLを指定し，ゲートウェイ指定機能でスキームをhttpsとみなすように設定した場合，リダイレクト先URLのスキームは常に「https」となります。

javax.servlet.ServletRequestクラスのgetServerNameメソッド
ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。

javax.servlet.ServletRequestクラスのgetServerPortメソッド
ゲートウェイ指定機能でリダイレクト先URLのポート番号を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，ポート番号を省略した場合，戻り値はリクエストのスキームがhttpであれば「80」，httpsであれば「443」となります。

javax.servlet.ServletRequestクラスのgetSchemeメソッド
ゲートウェイ指定機能でスキームをhttpsとみなすように設定した場合，戻り値は常に「https」となります。

javax.servlet.ServletRequestクラスのisSecureメソッド
ゲートウェイ指定機能でスキームをhttpsとみなすように設定した場合，戻り値は常に「true」となります。

javax.servlet.ServletRequestクラスのgetAttributeメソッド
ゲートウェイ指定機能でスキームをhttpsとみなすように設定した場合でも，次の属性は取得できません。

javax.servlet.request.cipher_suite（WebサーバにMicrosoft IISを使用している場合は，ゲートウェイ指定機能の使用に関係なく取得できません）

javax.servlet.request.key_size

javax.servlet.request.X509Certificate

(11)　ゲートウェイ使用時の注意

SSLアクセラレータや負荷分散器などのゲートウェイを使用した場合，次のサーブレットAPIの戻り値はクライアントのIPアドレスやホスト名ではなく，ゲートウェイのIPアドレスやホスト名になります。

javax.servlet.ServletRequestクラスのgetRemoteAddrメソッド

javax.servlet.ServletRequestクラスのgetRemoteHostメソッド

(12)　ServletContextオブジェクトに登録する日立独自の属性

Webコンテナは，Webアプリケーションの制御に必要な情報をjavax.servlet.ServletContextオブジェクトの属性に登録しています。WebアプリケーションでServletContextインタフェースのgetAttributeNamesメソッドによって取得する属性名には，Webコンテナによって登録された属性の名称も含まれます。

Webアプリケーション内でServletContextオブジェクトに属性を登録する時，次の文字列で開始するキー名称を使用しないでください。

org.apache.catalina

com.hitachi.software.web

また，ServletContextにはJ2EEの仕様で定められた属性も追加されるため，これらと同じキー名称の属性を登録しないでください。

Webコンテナが登録する属性の名称と意味を次の表に示します。

表4-49　ServletContextに登録する日立独自の属性

項番 | キー名称 | 値の説明 | コンテナのモード
1 | org.apache.catalina.WELCOME_FILES | web.xmlまたはデフォルトweb.xmlに<welcome-file-list>タグで設定された値です。 | J2EE，サーブレット
2 | org.apache.catalina.resources | コンテキストと結び付けられるJNDIディレクトリコンテキストです。 | J2EE，サーブレット
3 | org.apache.catalina.jsp_classpath | コンテキストに含まれるJSPのコンパイル時に使用するクラスパスです。 | J2EE，サーブレット
4 | com.hitachi.software.web.application-dd.J2eeApplicationName | J2EEアプリケーション名です。 | J2EE
5 | com.hitachi.software.web.application-dd.contextRoot | コンテキストルート名です。 | J2EE
6 | com.hitachi.software.web.dd.session-max-inactive-interval | web.xmlに設定されたHTTPセッションの有効期間※1です。 | J2EE
7 | com.hitachi.software.web.hitachi-runtime-dd.http-session-max-number | HTTPセッション数の上限値設定機能で設定されたHTTPセッション数の上限値です。 | J2EE
8 | com.hitachi.software.web.dd.filter-class | web.xmlの最上部に定義されたフィルタマッピングのクラス名です。 | J2EE
9 | com.hitachi.software.web.dd.url-pattern | web.xmlの最上部に定義されたフィルタマッピングのURLパターン※2※3です。 | J2EE
10 | com.hitachi.software.web.server-id-cookie-name | サーバID付加機能によって作成されるサーバIDのHTTP Cookie名称です。 | J2EE
11 | com.hitachi.software.was.sfo.GIDCookieName※4 | セッションフェイルオーバ機能用フィルタの初期化パラメタに設定されたグローバルセッションIDに使用するHTTP Cookie名称です。 | J2EE

（凡例）

J2EE：J2EEサーバモードを表す

サーブレット：サーブレットエンジンモードを表す

注※1

web.xmlにHTTPセッションの有効期間を設定しなかった場合はデフォルトの値が登録されます。

注※2

<url-pattern>タグでなく，<servlet-name>タグが設定された場合は追加されません。

注※3

web.xml内にセッションフェイルオーバ機能用フィルタを使用するフィルタマッピングが複数定義されていた場合，URLパターンの代わりに”<multi mapped>”の文字列が登録されます。

注※４

この属性が登録されるのは，セッションフェイルオーバ機能を使用する場合だけです。

(13)　ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

次に示すjavax.servlet.ServletRequestクラスのメソッドは，リクエストを送信したクライアント，または最後に通ったプロキシの情報を取得するためのメソッドですが，リバースプロキシを使用した環境では，取得する情報がリバースプロキシの情報となります。

getRemoteAddrメソッド

getRemoteHostメソッド

getRemotePortメソッド

(14)　javax.servlet.ServletResponseクラスのresetメソッドについての注意

javax.servlet.ServletResponseクラスのgetWriterメソッドを実行したあとに，resetメソッドを実行した場合，HTTPレスポンスのContent-Typeで指定する文字エンコーディングは，次に示すAPIのどれか（すべてjavax.servlet.ServletResponseクラス）を使用して，再度同じ文字エンコーディングを指定してください。

setContentTypeメソッド

setLocaleメソッド

setCharacterEncodingメソッド※

注※

Servlet 2.4仕様で追加されたメソッドです。

Servlet 2.4仕様では，上記のAPIを使用して文字エンコーディングを設定する場合は，getWriterメソッドを実行する前に呼び出す必要があります。ただし，getWriterメソッドを実行したあとにresetメソッドを実行した場合にかぎり，再度getWriterメソッドを呼び出すまでは上記のAPIで文字エンコーディングを設定できます。

(15)　setMaxInactiveIntervalメソッドの引数に0を指定した場合の動作

javax.servlet.http.HttpSessionのsetMaxInactiveIntervalメソッドの引数に0を指定した場合，セッションがタイムアウトになることはありません。

(16)　java.io.BufferedReaderのmark操作について

インプロセスHTTPサーバ機能を使用している場合に，javax.servlet.ServletRequestのgetReaderメソッドで得られるjava.io.BufferedReaderは，mark操作をサポートしていません。markSupportedメソッドではfalseが返されます。

(17)　setVersionメソッドの引数に1を指定した場合の動作

javax.servlet.http.CookieのsetVersionメソッドの引数に1を指定した場合，Webサーバ連携機能使用時には，レスポンスにSet-Cookie2ヘッダが付加されますが，インプロセスHTTPサーバ機能使用時にはSet-Cookieヘッダが付加されます。

(18)　getRequestDispatcherメソッドでのパスの指定について

javax.servlet.ServletRequestのgetRequestDispatcherメソッドの引数に「/」ではじまらない相対パスを指定した場合，このサーブレットのサーブレットマッピングに指定したURLパターンからの相対パスになります。URLパターンが「/」で終わっている場合は，親のディレクトリからの相対パスになります。

例えば，サーブレットマッピングを"/a/b/"に指定したサーブレットから，"hello.html"を指定してgetRequestDispatcherメソッドを実行すると，"/a/hello.html"が得られます。

(19)　setBufferSizeメソッドを使用してバッファサイズを変更する場合の注意

レスポンス送信時に使用されるサーブレットのバッファは，リクエスト処理スレッドごとに保持されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを実行してバッファサイズを変更した場合，変更したバッファサイズは，同一J2EEサーバ上のほかのWebアプリケーションを含め，該当するスレッドが処理するすべてのリクエストに適用されます。javax.servlet.ServletResponseのsetBufferSizeメソッドを使用してバッファサイズを変更する場合は，（バッファサイズ）×（リクエスト処理スレッド数）分のメモリが確保されることを考慮した上で，メモリ使用量を見積もってください。

(20)　HTTPレスポンスのContent-Typeヘッダについての注意

サーブレットでは，javax.servlet.ServletResponseクラスのsetContentTypeメソッドで明示的にContent-Typeを設定していない場合，Content-Typeヘッダを作成しません。そのため，HTTPレスポンスの文字エンコーディングをContent-Typeヘッダの”charset=”フィールドから確認することはできません。

4.32.3　Servlet 2.4仕様で追加，変更された仕様についての注意事項

Servlet 2.4仕様で追加，変更された仕様を，Cosminexus上で使用するときの注意事項を示します。Servlet 2.4仕様およびServlet 2.3仕様については，それぞれの仕様書（Servlet 2.4仕様書，Servlet 2.3仕様書）を参照してください。

＜この項の構成＞

(1)　X-Powered-Byヘッダの利用

(2)　java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

(3)　javax.servlet.SingleThreadModelインタフェースの非推奨化について

(4)　javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

(5)　javax.servlet.UnavailableExceptionについて

(6)　javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

(7)　javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

(8)　HTTPステータスコード302のステータスメッセージについて

(9)　サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

(10)　リスナで例外が発生した場合の制御について

(11)　共通で使用する外部のライブラリ（Extension）について

(12)　サーブレットのバージョンが異なるWebアプリケーション間のクロスコンテキストの使用について

(1)　X-Powered-Byヘッダの利用

Servlet 2.4仕様で追加されたX-Powered-Byヘッダはレスポンスに追加されません。

(2)　java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

javax.servlet.ServletRequestクラス，およびjavax.servlet.ServletContextクラスのgetRequestDispatcherメソッドで取得したjavax.servlet.RequestDispatcherクラスのforwardメソッドを実行すると，リクエストオブジェクトには次のキーの属性が追加されます。ただし，javax.servlet.ServletContextクラスのgetNamedDispatcherメソッドで取得したRequestDispatcherオブジェクトのforwardメソッドでは追加されません。

javax.servlet.forward.request_uri

javax.servlet.forward.context_path

javax.servlet.forward.servlet_path

javax.servlet.forward.path_info※1

javax.servlet.forward.query_string※2

注※1

Webコンテナが受信したHTTPリクエストが追加のパス情報を含まない場合，この属性は追加されません。

注※2

Webコンテナが受信したHTTPリクストのリクエストURIがクエリ文字列を含まない場合，この属性は追加されません。

これらの属性は，Webコンテナによって追加されます。javax.servlet.ServletRequestAttributeListenerに属性追加のイベントは通知されません。追加される属性の値については，Servlet 2.4仕様書を参照してください。

(3)　javax.servlet.SingleThreadModelインタフェースの非推奨化について

javax.servlet.SingleThreadModelインタフェースは，Servlet 2.4仕様から非推奨となっています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，javax.servlet.SingleThreadModelインタフェースを使用できます。ただし，Servlet 2.4仕様を参照し，非推奨となった理由に注意して使用してください。

(4)　javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

javax.servlet.ServletResponseクラスのsetLocaleメソッドによって，HTTPレスポンスのContent-Typeヘッダに文字エンコーディングが設定されます。Servlet 2.4仕様では，設定される文字エンコーディングが有効となる条件が変更されています。

Cosminexusで有効となる条件を，Servlet 2.4とServlet 2.3に分けて示します。

Servlet 2.4

次のすべての条件を満たす必要があります。

HTTPレスポンスがコミットされる前であること。

getWriterメソッドの呼び出し前であること。

setCharacterEncodingメソッドの呼び出し前であること。

setContentTypeメソッドによって文字エンコーディングが設定されていないこと。

条件に反する場合，setLocalメソッドは，ServletResponseクラスにロケールを設定するだけで，レスポンスの文字エンコーディングは設定しません。

Servlet 2.3

次の条件を満たす必要があります。

HTTPレスポンスがコミットされる前であること※。

注※

レスポンスがコミットされる前の場合，getWriterメソッドの呼び出し前後に関係なく，文字エンコーディングが設定されます。

レスポンスがコミットされる前の場合，setContentTypeメソッドで文字エンコーディングが設定されているかどうかに関係なく，文字エンコーディングが設定されます。

(5)　javax.servlet.UnavailableExceptionについて

javax.servlet.UnavailableException例外は永久的に利用できないことを示します。javax.servlet.UnavailableException例外をthrowしたサーブレット，JSPにアクセスした場合のHTTPレスポンスコードの仕様が，Servlet 2.4仕様で追記されています。

Cosminexusでこの例外をthrowしたサーブレット，JSPにアクセスした場合のHTTPレスポンスコードを，Servlet 2.4とServlet 2.3に分けて示します。

Servlet 2.4

404エラーとなります。

Servlet 2.3

503エラーとなります。

(6)　javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドを呼び出すタイミングが，Servlet 2.4仕様で変更されています。

Cosminexusでこのメソッドを呼び出す場合のタイミングを，Servlet 2.4とServlet 2.3に分けて示します。

Servlet 2.4

セッションが破棄される前に実行されます。

Servlet 2.3

セッションが破棄されたあとに実行されます。

なお，セッションタイムアウトが無効のとき，次の順序でセッションに関するリスナが通知されます。Webアプリケーションのバージョンごとに，順序を示します。

Servlet2.4の場合

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyed()メソッド

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド

Servlet2.3の場合

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyed()メソッド

(7)　javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドを使用する条件が，Servlet 2.4仕様で変更されています。

Cosminexusでこのメソッドを正常に実行するには，次の条件をすべて満たす必要があります。

実行するタイミングが，レスポンスがコミットされる前であること。

引数に適切なURLを指定すること。

この条件を満たさない場合のエラー制御を，Servlet 2.4とServlet 2.3に分けて示します。

Servlet 2.4

条件を満たさない場合は，java.lang.IllegalStateException例外がthrowされます。

Servlet 2.3

レスポンスがすでにコミットされている場合
java.lang.IllegalStateException例外がthrowされます。

引数に不正なURLが指定された場合
レスポンスコードが404になります。

(8)　HTTPステータスコード302のステータスメッセージについて

Servlet 2.4仕様では，HTTPステータスコードの302を示す定数として，javax.servlet.http.HttpServletResponseクラスに「SC_FOUND」が追加されています。また，下位互換性のため，Servlet 2.3仕様で定義されていた「SC_MOVED_TEMPORARILY」はそのまま使用できます。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，「SC_FOUND」および「SC_MOVED_TEMPORARILY」を使用できます。

なお，ステータスメッセージの「Found」がWebコンテナで使用されるのは，次の場合です。

Webアプリケーションで302を返す場合

デフォルトエラーページが出力された場合（HTML本文中）

(9)　サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

Servlet 2.4仕様では，サービスメソッド実行中のjavax.servlet.http.HttpSessionクラスでのタイムアウトについて仕様が追記されています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，Webアプリケーションでのリクエスト処理を実行している間は，HttpSessionはタイムアウトされません。

また，Webアプリケーション単位またはURLグループ単位の同時実行スレッド数制御によって，リクエストが実行待ち状態の場合も，HttpSessionはタイムアウトされません。ただし，Webコンテナ単位での同時実行スレッド数制御による実行待ち状態の場合は，HttpSessionはタイムアウトされるので注意してください。

(10)　リスナで例外が発生した場合の制御について

Servlet 2.4仕様では，リスナで例外が発生した場合についての記述が追加されています。

Cosminexusを使用している場合で，リスナで例外が発生した場合の制御を，Servlet 2.4とServlet 2.3に分けて示します。

Servlet 2.4

該当するイベントを処理するリスナが複数あっても，例外を発生したリスナ以降のリスナは，実行されません。

Servlet 2.3

発生した例外はWebコンテナによってcatchされます。複数のリスナが登録されている場合，例外がcatchされたあとに，正常時と同様に登録されているリスナが順次実行されます。

(11)　共通で使用する外部のライブラリ（Extension）について

Webアプリケーションで外部のライブラリを使用する場合に記載するMANIFESTファイルの扱いについて，Servlet 2.4仕様では記述が変更されています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，MANIFESTファイルの存在，およびMANIFESTファイルの内容は確認されません。

(12)　サーブレットのバージョンが異なるWebアプリケーション間のクロスコンテキストの使用について

サーブレットのバージョンが異なるWebアプリケーション間で，クロスコンテキストを使用したリクエストをforwardしたあとの動作，およびincludeしたあとの動作を，次の表に示します。

表4-50　forward後およびinclude後の動作

項番
Servlet 2.4仕様の追加機能／Webアプリケーションのバージョンで違いのある機能
リクエストのforward先／include先の動作

2.4から2.3にforward／include※1
2.3から2.4にforward／include※2

1
forward時またはinclude時のフィルタ適用
forward後／include後のサーブレット，またはJSPから，さらにforwardまたはincludeする場合，Servlet 2.4仕様が適用され，フィルタは使用できます。
forward後／include後のサーブレット，またはJSPからさらにforwardまたはincludeする場合，Servlet 2.3仕様が適用され，フィルタは使用できません。

2
javax.servlet.ServletRequestAttributeListenerの呼び出し
Servlet 2.4仕様が適用され，リクエストへの属性追加時にリスナが使用できます。
Servlet 2.3仕様が適用され，リクエストへの属性追加時にリスナは使用できません。

3
JSPのコンパイル
Servlet 2.3に対応したアプリケーションとしてJSPコンパイルを実行します。
Servlet 2.4に対応したアプリケーションとしてJSPコンパイルを実行します。

4
javax.servlet.ServletResponseクラスのsetLocaleメソッド
Servlet 2.4仕様が適用され，次に示す条件をすべて満たす場合，文字エンコーディングの設定が有効となります。

レスポンスがコミットされる前であること。

getWriterメソッドの呼び出し前であること。

setCharacterEncodingメソッドの呼び出し前であること。

serContentTypeメソッドで文字エンコーディングが設定されていないこと。

Servlet 2.3仕様が適用され，レスポンスがコミットされる前である場合，文字エンコーディングの設定が有効となります。

5
永久的に利用できないことを示すjavax.servlet.UnavailableException例外をthrowしたサーブレット，JSPへのディスパッチ
Servlet 2.3仕様が適用され，ステータス503を設定したレスポンスが返されます。
Servlet 2.4仕様が適用され，ステータス404を設定したレスポンスが返されます。

6
javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッド
Servlet 2.4仕様が適用され，HTTPセッションが破棄される前に実行されます。
Servlet 2.3仕様が適用され，HTTPセッションが破棄されたあとに実行されます。

7
javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドに不正なURLを指定
Servlet 2.4仕様の仕様が適用され，java.lang.IllegalStateException例外がthrowされます。
Servlet 2.3の仕様が適用され，ステータス404がレスポンスに設定されます。

8
使用するリスナ定義
次に示すリスナの場合，forward先またはinclude先のアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，forwardまたはincludeを呼び出したアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletRequestAttributeListener

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

次に示すリスナの場合，forward先またはinclude先のアプリケーションで定義されたリスナが動作します。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，forwardまたはincludeを呼び出したアプリケーションで定義されたリスナが動作します。

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

9
該当するイベントを処理するリスナがweb.xmlで複数定義されていた場合に，forwardもしくはinclude先のアプリケーション内でリスナが例外を発生したときの動作
次に示すリスナの場合，Servlet 2.4仕様が適用され，例外を発生したリスナ以降のリスナは実行されません。

javax.servlet.ServletRequestAttributeListener

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

次に示すリスナの場合，Servlet 2.3仕様が適用され，発生した例外をキャッチし，その後正常時と同様に登録されている次のリスナへ処理が移ります。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，Servlet 2.4仕様が適用され，例外を発生したリスナ以降のリスナは実行されません。

javax.servlet.ServletContextAttributeListener

次に示すリスナの場合，Servlet 2.3仕様が適用され，発生した例外をキャッチし，その後正常時と同様に登録されている次のリスナへ処理が移ります。

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionAttributeListener

10
web.xmlで指定されたエラーページを表示したレスポンスのステータスコード
Servlet 2.4仕様が適用され，エラー発生時のステータスコードのレスポンスが返されます。
Servlet 2.3仕様が適用され，ステータス200のレスポンスが返されます。

注※1

Servlet 2.4に対応したアプリケーションからServlet 2.3に対応したアプリケーションにforwardまたはincludeした場合を表します。

注※2

Servlet 2.3に対応したアプリケーションからServlet 2.4に対応したアプリケーションにforwardまたはincludeした場合を表します。

4.32.4　JSP実装時の注意事項

JSPを実装するときの注意事項を示します。

＜この項の構成＞

(1)　includeディレクティブ利用時の注意

(2)　タグライブラリ利用時の注意

(3)　<%=%>タグ記述時の注意

(4)　URL指定とマッピング定義によるアクセスについて

(5)　<jsp:plugin>タグ利用時の注意

(6)　JSPから生成されるJavaソースのコンパイルについて

(7)　JSPドキュメント内のversion属性について

(8)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて

(9)　JSPで動的なページをインクルードする場合の注意

(10)　TLDファイルでのDOCTYPE宣言への内部サブセットの記述について

(11)　JSPドキュメントおよびXML形式のタグファイルでの外部サブセットURIの指定について

(12)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性の値について

(13)　JSPでサポートしている文字エンコーディングについて

(1)　includeディレクティブ利用時の注意

JSPファイルのincludeディレクティブでファイルをインクルードする場合，インクルード元となるJSPファイルでエンコーディングを指定してください。

JSPでHTMLなどの静的ファイルをインクルードする場合は，includeアクションを使用しないで，includeディレクティブを使用してください。includeアクションはJSPやサーブレットなど動的なページをインクルードする場合に使用してください。

(2)　タグライブラリ利用時の注意

タグライブラリを作成する場合には，タグライブラリを記述したクラスファイルの先頭にpackage文で必ずパッケージ名を付けるようにしてください。パッケージ名が付いていない場合，そのタグライブラリは正常に動作しません。

タグライブラリ・ディスクリプタ（TLDファイル）で，<variable>タグ内の<scope>タグ要素には，NESTED，AT_BEGIN，AT_ENDのどれかを指定してください。これら以外の値を指定した場合には，デフォルトのNESTEDが仮定されて実行されます。

タグライブラリのタグハンドラを実装する場合には，doStartTagメソッド，doAfterBodyメソッド，およびdoEndTagメソッドが仕様で規定されている戻り値を返すようにしてください。仕様で規定されている戻り値以外の値を返した場合，デフォルトの戻り値を仮定して動作します。デフォルトの戻り値とは，javax.servlet.jsp.tagext.TagSupportまたはjavax.servlet.jsp.tagext.BodyTagSupportクラスの各メソッドがオーバーライドしない場合に返す戻り値です。例えば，BodyTagインタフェースを実装したクラス（またはBodyTagSupportクラスを継承したクラス）で，doStartTagメソッドがEVAL_PAGEを戻り値として返した場合，デフォルトの戻り値であるEVAL_BODY_BUFFEREDが返されたと仮定して動作します。

Webアプリケーションのバージョンが2.3の場合で，かつタグライブラリのタグハンドラで属性の指定を持つカスタムタグを実装した場合，JSPのカスタムタグで同じ属性を複数指定すると，該当するタグハンドラのsetterメソッドが指定された回数呼び出されます。通常指定された値を上書きするようなsetterメソッドを実装している場合には，後ろに記述された属性の値が有効になります。

(3)　<%=%>タグ記述時の注意

JSPで<%= %>タグを使用する場合は，その中に「;（セミコロン）」が入らないようにしてください。セミコロンが入っている場合，JSPコンパイルでエラーとなります。

(4)　URL指定とマッピング定義によるアクセスについて

直接JSPファイルのパスをURL指定してアクセスする場合とマッピング定義されたURLでアクセスする場合には，それぞれ別々のインスタンスが生成されます。したがって，jspInitメソッドがそれぞれのインスタンスで実行されることに注意してください。なお，<load-on-startup>タグで起動時にロードされるように指定した場合，起動時にロードされるインスタンスは，マッピング定義されたURLでアクセスするものと同じになります。

(5)　<jsp:plugin>タグ利用時の注意

JSPページで，pluginアクションまたはJSPドキュメントでの<jsp:plugin>タグのcode属性は必ず指定してください。省略した場合はコンパイルエラーとなります。

(6)　JSPから生成されるJavaソースのコンパイルについて

JSPから生成されるJavaソースをコンパイルするときのコンパイルオプションは指定できません。

(7)　JSPドキュメント内のversion属性について

JSPドキュメントでは，<jsp:root>タグの属性として，使用するバージョン情報を記述できます。しかし，JSPで使用できる機能範囲は，該当するJSPを含むWebアプリケーションのweb.xmlのバージョン情報に従います。

例えば，<jsp:root version="1.2">と記述しているJSPドキュメントであっても，JSP 2.0仕様で追加されたJSP ELを使用できます。

(8)　taglibディレクティブのuri属性で指定するURIとTLDファイルのマッピングについて

taglibディレクティブのuri属性で指定するURIは，JSP仕様によって次のどちらかの方法でマッピングします。同じURIを異なるTLDファイルにマッピングすることはできません。URIが重複した場合は，次に示す番号順を優先順位とし，優先順位の高いマッピングが有効になります。

web.xmlの<taglib>要素の<taglib-uri>要素で指定したURIと，<taglib-location>要素で指定したTLDファイルをマッピング

TLDファイルの<uri>要素で指定したURIと，そのTLDファイル自身をマッピング

URIの重複が検出された場合，次のメッセージが出力され，該当するマッピングは無視されます。

表4-51　URI重複時に出力されるメッセージと出力条件

メッセージID
出力条件

KDJE39314-W

J2EEサーバモード，サーブレットエンジンモード，またはcjjspcコマンドの場合

TLDファイルで記述した<uri>要素の内容が，web.xmlの<taglib-uri>要素の内容，またはほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

cjjsp2javaコマンドの場合

TLDファイルで記述した<uri>要素の内容が，コマンド引数-taglibに指定したuriの内容，またはほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

KDJE39315-W
TLDファイルで記述した<uri>要素の内容が，ほかのTLDファイルで記述した<uri>要素の内容と重複したときに出力されます。

KDJE39316-W
web.xmlに指定した<taglib>要素の内容と重複する<taglib-uri>要素を持つほかの<taglib>要素が指定されている場合に出力されます。

(9)　JSPで動的なページをインクルードする場合の注意

JSPで，JSPやサーブレットなどの動的なページをインクルードする場合は，javax.servlet.RequestDispatcherのincludeメソッドを使用しないで，includeアクションを使用してください。

(10)　TLDファイルでのDOCTYPE宣言への内部サブセットの記述について

TLDファイル（タグライブラリ・ディスクリプタ）で，DOCTYPE宣言に内部サブセットを記述しないでください。

タグの要素拡張またはタグライブラリの要素拡張でxsi:schemaLocation属性に指定するURIは絶対URIだけ指定できます。タグの要素拡張またはタグライブラリの要素拡張以外の目的で，J2EE仕様で定められたDTD／XMLスキーマ以外を参照しないでください。

(11)　JSPドキュメントおよびXML形式のタグファイルでの外部サブセットURIの指定について

DOCTYPE宣言を指定する場合，外部サブセットURIには絶対URIだけ指定できます。また，XML1.0仕様で定義された外部エンティティ参照をする場合，外部エンティティ宣言に指定するURIには絶対URIだけ指定できます。相対URIを指定した外部サブセットおよび外部エンティティは参照できません。

(12)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性の値について

JSPファイルで例外をスローした場合，pageディレクティブのerrorPage属性でエラーページを指定しているとき，例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.jsp.jspException属性に設定されるとJSP仕様に記述されていますが，pageディレクティブのerrorPage属性でエラーページを指定しない場合も設定されます。

(13)　JSPでサポートしている文字エンコーディングについて

Servlet仕様が規定したJSPの文法に従って作成されたJSPは，サーブレットに変換され，Javaプログラムとしてコンパイルされたあと，Java VM内にロードして実行できます。

Webコンテナでは，JSPの解析に使用するCosminexus XML Processor，およびJavaVMのサポートしている文字エンコーディングの制限によって，サーブレットに変換できるJSPファイルの文字エンコーディングに制限があります。

ここでは，JSPファイルで使用できる文字エンコーディングと，文字エンコーディングの指定について，JSPファイルの種類ごとに説明します。

なお，JSPドキュメントの場合，Servlet2.4/JSP2.0仕様に準拠したWebアプリケーションのときは，ファイルの拡張子に関係なく，web.xmlの指定によって，使用できる文字エンコーディングが異なります。Servlet2.4/JSP2.0仕様に準拠したWebアプリケーションの場合に，web.xmlの指定に対応するJSPドキュメントを次の表に示します。

表4-52　web.xmlの指定に対応するJSPドキュメント（Servlet2.4/JSP2.0仕様に準拠したWebアプリケーションの場合）

ファイルの拡張子 | web.xmlの指定 | 対応するJSPドキュメント
jspx | page-encoding要素で文字エンコーディングの指定あり | ファイルの拡張子がjspx以外のJSPドキュメント
上記以外 | ファイルの拡張子がjspxのJSPドキュメント
jspx以外 | jsp-property-group要素内のis-xml要素でtrueを指定し，かつpage-encoding要素に指定なし | ファイルの拡張子がjspxのJSPドキュメント
上記以外 | ファイルの拡張子がjspx以外のJSPドキュメント

●使用できる文字エンコーディング

JSPファイルの種類ごとに，使用できる文字エンコーディングについて説明します。

JSPページの場合
JSPファイルの文字エンディングには，JavaVMがサポートしている文字エンコーディングが使用できます。JavaVMがサポートしている文字エンコーディングについては，JDKのドキュメントのサポートされているエンコーディングに関する説明を参照してください。ただし，英数字を複数バイトで表現する文字エンコーディング（UTF-16など）を使用する場合は，次の条件を満たしている必要があります。

Servlet2.4/JSP2.0仕様に準拠したWebアプリケーションである。

JSPファイルの先頭にバイトオーダーマークを付加している。

JSPドキュメント（ファイルの拡張子がjspx）の場合
JSPファイルの文字エンディングには，Cosminexus XML Processorがサポートしている文字エンコーディングが使用できます。Cosminexus XML Processorがサポートしている文字エンコーディングについては，マニュアル「Cosminexus XML Processor　ユーザーズガイド」を参照してください。

JSPドキュメント（ファイルの拡張子がjspx以外）の場合
JSPファイルの文字エンディングには，Cosminexus XML Processorがサポートしている文字エンコーディングのうちISO-10646-UCS-4以外が使用できます。Cosminexus XML Processorがサポートしている文字エンコーディングについては，マニュアル「Cosminexus XML Processor　ユーザーズガイド」を参照してください。ただし，英数字を複数バイトで表現する文字エンコーディング（UTF-16など）を使用する場合は，次の条件を満たしている必要があります。

Servlet2.4/JSP2.0仕様に準拠したWebアプリケーションである。

JSPファイルの先頭にはバイトオーダーマークを付加している。

ISO-10646-UCS-2を使用している場合は，ビッグエンディアンのISO-10646-UCS-2を使用している。

●文字エンコーディングの指定

JSPファイルの種類ごとに，文字エンコーディングの指定方法と，指定値について説明します。

文字エンコーディングの指定方法
JSPファイルの種類ごとの，文字エンコーディングの指定方法を次の表に示します。なお，指定方法が複数ある場合は，どれか一つの方法で使用してください。

表4-53　JSPファイルの種類ごとの，文字エンコーディングの指定方法

指定方法
JSPファイルの種類

JSPページ
JSPドキュメント

ファイルの拡張子がjspxの場合
ファイルの拡張子がjspx以外の場合

web.xmlのjsp-property-group要素内のpage-encoding要素
（Servlet2.4/JSP2.0仕様のWebアプリケーションの場合）
○
－
○

tagディレクティブのpageEncoding属性
（Servlet2.4/JSP2.0仕様のWebアプリケーションの場合）
○
－
－

pageディレクティブのpageEncoding属性
（Servlet2.3/JSP1.2仕様およびServlet2.4/JSP2.0仕様のWebアプリケーションの場合）
○
－
－

pageディレクティブのcontentType属性
○
－
－

XML宣言のencoding属性
－
○
○

（凡例）○：指定できる　－：該当しない

文字エンコーディングの指定値
JSPファイルの種類ごとに，文字エンコーディングに指定できる文字列を次に示します。なお，指定値に指定する文字エンコーディングと，JSPファイルで使用する文字エンコーディングは，必ず一致するようにしてください。

JSPページ，およびJSPドキュメント（ファイルの拡張子がjspx以外）の場合
文字エンコーディングに指定できる文字列は，java.nio API用の正準名とjava.lang API用の正準名に記載されている文字エンコーディング，およびそれらの別名です。詳細については，JDKのドキュメントのサポートされているエンコーディングに関する説明を参照してください。

JSPドキュメント（ファイルの拡張子がjspx以外）の場合
文字エンコーディングに指定できる文字列は，Cosminexus XML Processorがサポートしている文字エンコーディングです。詳細については，マニュアル「Cosminexus XML Processor　ユーザーズガイド」を参照してください。

●デフォルトの文字エンコーディング

文字エンコーディングを明示的に指定しない場合，デフォルトの文字エンコーディングでJSPを処理します。この場合も，明示的に文字エンコーディングを指定しないJSPファイルの文字エンコーディングと，デフォルトの文字エンコーディングは，必ず一致するようにしてください。デフォルトの文字エンコーディングをServletのバージョンごとに次の表に示します。

表4-54　デフォルトの文字エンコーディング

Servlet/JSPのバージョン | 種類 | デフォルトの文字エンコーディング設定の有無※ | デフォルトの文字エンコーディング
Servlet2.2/JSP1.1 | JSPページ | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | ISO-8859-1
JSPドキュメント | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | UTF-8
Servlet2.3/JSP1.2 | JSPページ | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | ISO-8859-1
JSPドキュメント | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | UTF-8
Servlet2.4/JSP2.0 | JSPページ | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | ISO-8859-1
JSPドキュメント | 設定有り | デフォルトの文字エンコーディング設定の指定値
設定無し | ISO-8859-1

注※　デフォルトの文字エンコーディングの設定については，「4.6　デフォルトの文字エンコーディング設定」を参照してください。

4.32.5　JSP 2.0仕様で追加，変更された仕様についての注意事項

JSP 2.0仕様で追加，変更された仕様を，Cosminexus上で利用するときの注意事項を示します。JSP 2.0仕様およびJSP 1.2仕様については，それぞれの仕様書（JSP 2.0仕様書，JSP 1.2仕様書）を参照してください。

＜この項の構成＞

(1)　JSPドキュメントのデフォルト拡張子

(2)　タグファイルのJavaソースファイルとクラスファイルの出力先

(3)　JSP EL式の評価APIの複数指定

(4)　XMLシンタックスで記述されたJSPファイルとタグファイル

(5)　pageディレクティブのisThreadSafe属性の非推奨化について

(6)　JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

(7)　タグライブラリ・ディスクリプタ（TLDファイル）の配置について

(8)　javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

(9)　includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

(10)　JSPドキュメント内の矛盾する文字コードについて

(11)　JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

(12)　pageディレクティブのpageEncoding属性の複数回指定について

(13)　JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

(14)　JSPドキュメントの文字コードについて

(15)　EL（Expression Language）のエスケープシーケンスについて

(1)　JSPドキュメントのデフォルト拡張子

JSP 2.0仕様では，JSPドキュメントの標準的な拡張子を「jspx」としています。Cosminexusで利用するWebコンテナでは，「jspx」を拡張子としたファイルは，デフォルトマッピングによってweb.xmlにURLマッピング定義しなくてもJSPドキュメントとして扱われます。

(2)　タグファイルのJavaソースファイルとクラスファイルの出力先

タグファイルは，JSPファイルと同様に，JSPのコンパイルによってJavaソースファイルとクラスファイルが生成されます。Javaソースファイルおよびクラスファイルは，JSPコンパイル結果の出力先ディレクトリに出力されます。

JSPコンパイル結果の出力先ディレクトリは変更できます。なお，生成されるJavaソースファイル，およびクラスファイルのパスがOSの上限を超える場合は，出力先ディレクトリを変更する必要があります。

JSPコンパイル結果の出力先ディレクトリについては，JSP事前コンパイル機能を使用している場合，「4.7.5(2)　JSPコンパイル結果の出力先」，JSP事前コンパイル機能を使用してない場合，「4.7.6(3)　JSPコンパイル結果の出力先」を参照してください。

(3)　JSP EL式の評価APIの複数指定

JSP 2.0仕様では，EL式の構文解析と評価をするAPIとして次のAPIが提供されます。

javax.servlet.jsp.el.ExpressionEvaluatorクラスのevaluateメソッド

javax.servlet.jsp.el.Expressionクラスのevaluateメソッド

JSP 2.0仕様では，これらのAPIから複数のEL式を指定することはできませんが，Cosminexusでは，複数のEL式を指定できます。

(4)　XMLシンタックスで記述されたJSPファイルとタグファイル

文字エンコードについて
Webアプリケーションのバージョン2.4で，JSPドキュメントの文字エンコードを指定する場合は，XML宣言で文字エンコードを指定してください。
JSP 1.2仕様の場合は，ファイルの文字エンコードは，pageディレクティブのpageEncoding属性，またはcontentType属性のcharset値で指定していましたが，JSP2.0仕様からはXML宣言で文字エンコードを指定するように変更されています。

標準アクションの接頭辞ついて
JSPの標準アクションは，XML名前空間の「http://java.sun.com/JSP/Page」で識別されます。したがって，XML名前空間の接頭辞で標準アクションを指定する必要があります。接頭辞をjspとした場合の記述例を示します。

<?xml version="1.0" ?>
<jsp:root
   xmlns:jsp=http://java.sun.com/JSP/Page
   version="2.0">
   <jsp:directive.page import="java.util.*"/>
   <jsp:useBean id="name" class="test.Bean"/>

</jsp:root>

<jsp:root>要素の扱いについて
JSP 2.0仕様から<jsp:root>要素をルート要素に指定していなくても，XMLシンタックスのJSPファイル，またはタグファイルとして扱われます。
JSP 1.2仕様では，JSPドキュメントの条件として<jsp:root>がルート要素に指定されている必要がありましたが，JSP2.0仕様からは，<jsp:root>が指定されていなくても，web.xmlに定義した<jsp-config><jsp-property-group><is-xml>の値がtrue，または拡張子がjspx，tagxであれば，XMLシンタックス形式のJSPと扱うように変更されています。

(5)　pageディレクティブのisThreadSafe属性の非推奨化について

pageディレクティブのisThreadSafe属性は，javax.servlet.SingleThreadModelインタフェースが非推奨となったことによって，JSP 2.0仕様では非推奨とされています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，pageディレクティブのisThreadSafe属性を使用できます。ただし，Servlet 2.4仕様で，javax.servlet.SingleThreadModelインタフェースが非推奨となった理由に注意して使用してください。

(6)　JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

JSP 2.0仕様では，JSPドキュメントを使用した場合に，デフォルトのContentTypeの値が「text/xml」になると追記されています。

Cosminexusでは，JSP 2.0の場合は「text/xml」，JSP 1.2の場合は「text/html」をデフォルトとして動作します。

(7)　タグライブラリ・ディスクリプタ（TLDファイル）の配置について

JSP 2.0仕様では，タグライブラリ・ディスクリプタの配置場所についての規定が追加されています。

Cosminexusでは，配置するディレクトリによって，Webアプリケーションの開始時およびJSPのコンパイル時にKDJE39289-Wのメッセージが出力されることがあります。ただし，エラーとはならないでWebアプリケーションが実行されます。

メッセージが出力される条件を次に示します。

配置するディレクトリ

/WEB-INFディレクトリ以下以外

/WEB-INF/classesディレクトリ以下

/WEB-INF/libディレクトリ以下

メッセージが出力されるタイミング

該当するタグライブラリ・ディスクリプタを，web.xmlの<taglib><taglib-location>タグに指定して，Webアプリケーション開始するとき

該当するタグライブラリ・ディスクリプタを，タグライブラリの宣言で直接指定して使用するJSPをコンパイルするとき

(8)　javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

javax.servlet.jsp.tagext.PageDataオブジェクトのgetInputStreamメソッドで取得できるXMLビュー情報の仕様が，JSP 2.0仕様で変更されています。getInputStreamメソッドは，javax.servlet.jsp.tagext.TagLibraryValidatorクラスのvalidateメソッドの第三引数に指定して使用されます。

Cosminexusでの変更点を，JSP 2.0とJSP 1.2に分けて示します。

(a)　jsp:id属性

JSP 2.0

jsp:id属性を付加します。

JSP 1.2

jsp:id属性を付加しません。

(b)　XMLビューの文字エンコード

JSP 2.0

XMLビューの文字エンコードを常にUTF-8とし，文字コードをUTF-8としてXML宣言を出力します。

JSP 1.2

XMLビューの文字エンコードを常にUTF-8とし，文字コードをUTF-8としてXML宣言を出力しません。

(c)　pageディレクティブのpageEncoding属性

JSP 2.0

pageEncoding属性の値をUTF-8に設定します。pageEncoding属性がない場合は，pageEncoding属性を追加します。

JSP 1.2

pageEncoding属性の値は変更しません。

(d)　pageディレクティブのcontentType属性

JSP 2.0

contentType属性の値にServletResponseクラスのsetContentTypeメソッドで設定された値を設定します。contentType属性がない場合は，contentType属性を追加します。

JSP 1.2

contentType属性の値は変更しません。

(9)　includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

JSP 2.0仕様では，pageディレクティブのpageEncoding属性は，pageEncoding属性を記述したファイルにだけ適用されることが追記されています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，includeディレクティブでファイルをインクルードするときに，インクルード先のファイルに文字コードの指定がないと，インクルード元の文字コードがインクルード先のファイルに適用されます。

(10)　JSPドキュメント内の矛盾する文字コードについて

JSPドキュメントでのXML宣言に指定する文字コードと，JSPドキュメントでのpageディレクティブのpageEncoding属性に指定する文字コードが異なる場合の仕様がJSP 2.0仕様では追記されています。JSP 1.2仕様には記述がありません。

Cosminexusで文字コードが異なる場合の制御を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

JSPコンパイルエラーとなります。

JSP 1.2

pageディレクティブのpageEncoding属性が使用されます。

(11)　JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

JSPドキュメントでpageディレクティブのcontentType属性がない場合や，属性にCHARSET値がない場合に使用されるHTTPレスポンスのデフォルトの文字コードがJSP 2.0仕様では追記されています。

Cosminexusでのデフォルト値を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

UTF-8が使用されます。

JSP 1.2

ISO-8859-1が使用されます。

(12)　pageディレクティブのpageEncoding属性の複数回指定について

pageディレクティブのpageEncoding属性の複数回指定について，JSP 2.0仕様では仕様が変更されています。

JSP 2.0仕様では，トランスレーション単位（JSPとincludeディレクティブでインクルードされるファイル）でpageEncoding属性の複数回指定ができるようになっています。また，同じJSPファイル内でpageEncoding属性の複数回指定をするとコンパイルエラーとなることが追記されています。

Cosminexusでは，Webアプリケーションのバージョンに関係なく，トランスレーション単位でpageEncoding属性の複数回指定ができます。このとき，ファイル単位に指定した値が該当するファイルに適用されます。また，同じJSPファイル内でのpageEncoding属性の複数回指定については，JSP 2.0とJSP 1.2で仕様が異なります。Cosminexusでの仕様を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

一つのファイルに1回だけ指定できます。複数回指定した場合は，JSPコンパイルエラーとなります。

JSP 1.2

一つのファイルに複数回指定できます。最初に記述した値が適用されます。

(13)　JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

JSPドキュメントでnamespaceを使ってタグライブラリを宣言し，指定したuriがtaglibマップ（uriとタグライブラリ・ディスクリプタのマッピング）で見つからない場合の動作について，JSP 2.0仕様では追記されています。

Cosminexusでの動作を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

指定したuriがtaglibマップに登録されていない場合，uriのnamespaceで定義されたアクションは，解析しないで扱われます（テキストとして出力されます）。

JSP 1.2

uriが絶対URIの場合
トランスレーションエラーとなります。

uriが絶対URI以外の場合
Webアプリケーション内のパスとしてTLDファイル（タグライブラリ・ディスクリプタ）を検索して使用されます。TLDファイルがない場合は，トランスレーションエラーとなります。

(14)　JSPドキュメントの文字コードについて

JSPドキュメントでのファイルの文字コードの決定方法について，JSP 2.0仕様で仕様が変更されています。

Cosminexusでの文字コードの決定方法を，JSP 2.0とJSP 1.2に分けて示します。

JSP 2.0

XML 1.0の仕様に従い，XML宣言に従います。XML宣言がない場合はデフォルト値のUTF-8となります。

JSP 1.2

pageディレクティブのpageEncoding属性に従います。pageEncoding属性がない場合はcontentType属性のcharset=で指定した文字コードに従います。どちらもない場合はデフォルト値のISO-8859-1になります。

(15)　EL（Expression Language）のエスケープシーケンスについて

JSP2.0仕様であるELの開始を示す"${"に含まれる"$"を文字列として表すエスケープシーケンスについて，JSP仕様と，Cosminexusで利用するWebコンテナの仕様を次に示します。

Cosminexusで利用するWebコンテナでは，"¥$"はエスケープシーケンスによって，"$"と出力されます。"¥$"と出力したい場合は，"¥¥$"と記述します。

"¥$"と記述した場合の動作を，JSP2.0とJSP1.2に分けて示します。

JSP2.0

JSP2.0仕様では，ELの設定を無効に設定している場合，"$"はELの開始文字とする必要がなく，"¥"は制御コードとしては扱われません。JSP2.0で動作する場合は，ELの設定を有効にしているかどうかによって，"¥$"の出力結果が異なります。JSP2.0で動作する場合の"¥$"の出力結果を次の表に示します。

表4-55　JSP2.0で動作する場合の"¥$"の出力結果

ELの設定の有効/無効 | 仕様 | 出力結果
有効 | JSP2.0仕様 | "$"
Cosminexusで利用するWebコンテナ | "$"
無効 | JSP2.0仕様 | "¥$"
Cosminexusで利用するWebコンテナ | "$"

ELの設定を無効にする場合は，次に示すどれかの方法で設定します。

pageディレクティブのisELIgnored属性にtrueを指定する。

tagディレクティブのisELIgnored属性にtrueを指定する。

web.xmlの<el-ignored>タグにtrueを指定する。

JSP1.2

JSP1.2仕様では"$"は予約語ではありません。"¥"は制御コードとしては扱われないため，"¥$"と出力されます。

JSP1.2で動作する場合の"¥$"の出力結果を次の表に示します。

表4-56　JSP1.2で動作する場合の"¥$"の出力結果

仕様 | 出力結果
JSP1.2仕様 | "¥$"
Cosminexusで利用するWebコンテナ | "$"

4.32.6　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点

Servlet 2.2仕様またはServlet 2.3仕様に対応したWebアプリケーションをServlet 2.4仕様にバージョンアップする場合に必要な作業，および注意事項を示します。なお，Servlet 2.4仕様の詳細については，Servlet 2.4仕様書を参照してください。

＜この項の構成＞

(1)　web.xmlの移行

(2)　Servlet 2.4仕様に対応したコードへの修正

(3)　サーブレットエンジンモードからJ2EEサーバモードへの移行

(4)　JSPのシンタックスチェックについて

(1)　web.xmlの移行

Servlet 2.2仕様またはServlet 2.3仕様に従って作成したweb.xmlは，Servlet 2.4仕様に従った定義に修正します。Servlet 2.4仕様で変更された点については，マニュアル「Cosminexus　アプリケーション開発ガイド」のServlet 2.4仕様で追加，変更された仕様についての注意事項（web.xml）を参照してください。

(2)　Servlet 2.4仕様に対応したコードへの修正

Servlet 2.4仕様では，Servlet 2.2仕様およびServlet 2.3仕様から仕様が追加，変更されています。追加，変更された点を確認し，Servlet 2.4仕様に対応したコードに修正してください。Servlet 2.4仕様で追加，変更された点については，「4.32.3　Servlet 2.4仕様で追加，変更された仕様についての注意事項」を参照してください。

また，JSP 2.0仕様でもJSP 1.2仕様から仕様が追加，変更されています。追加，変更された点を確認し，JSP 2.0仕様に対応したコードに修正してください。JSP 2.0仕様で追加，変更された点については，「4.32.5　JSP 2.0仕様で追加，変更された仕様についての注意事項」を参照してください。

(3)　サーブレットエンジンモードからJ2EEサーバモードへの移行

Servlet 2.4仕様に対応したWebアプリケーションは，サーブレットエンジンモードでは実行できません。したがって，サーブレットエンジンモードを使用していた場合は，J2EEサーバモードに移行する必要があります。

サーブレットエンジンモードからJ2EEサーバモードへの移行方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(4)　JSPのシンタックスチェックについて

Servlet 2.4仕様に対応したWebアプリケーションに含まれるJSPファイルは，JSP 2.0仕様に準拠します。JSP 2.0仕様では，JSP 1.2仕様よりも厳密にシンタックスチェックされます。したがって，Servlet 2.3仕様のWebアプリケーションでは通知されなかったエラーが通知されることがあります。

Servlet 2.2仕様またはServlet 2.3仕様に対応したWebアプリケーションをServlet 2.4仕様にバージョンアップする場合は，cjjspcコマンドでJSPをコンパイルして，エラーが発生しないことを確認してください。コンパイルエラーが通知された場合は，エラー通知内容に従って修正してください。

cjjspcコマンドについては，「4.7.2　JSP事前コンパイルの方法」を参照してください。

4.32.7　サーブレットでのアノテーションの使用

Cosminexusでは，サーブレットでアノテーションを使用できます。Cosminexusが対応しているアノテーションについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

4.32.8　カスタムタグのスクリプト変数の定義に関する注意事項

ここでは，JSPのカスタムタグで，スクリプト変数を定義する場合の注意事項について説明します。

●スコープ指定時の注意

複数のカスタムタグで，スクリプト変数名とスクリプト変数のスコープが重複した場合，Cosminexusのバージョンによって，JSPのコンパイル結果が異なります。スクリプト変数のスコープは，次のどちらかで指定します。

javax.servlet.jsp.tagext.TagExtraInfoクラスのサブクラス

TLDファイルのvariable要素内のscope要素

JSPのカスタムタグで同じ名称のスクリプト変数を指定した場合に，Cosminexusのバージョンごとの動作の違いを次に示します。

07-00より前のバーションの場合
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数の変数宣言を行います。

07-00以降のバージョンの場合
2回目以降のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数の変数宣言を行いません。

スコープが「AT_BEGIN」で，属性idに指定された変数名（var）のスクリプト変数を定義するカスタムタグ<my:foo>を例に説明します。

定義例

<my:foo id="var" type="String">
 <%=var%>
</my:foo>

<my:foo id="var" type="String">
 <%=var%>
</my:foo>

07-00より前のバーションの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数varで変数宣言をします。この場合，各カスタムタグでのスコープ「AT_BEGIN」の範囲は次のようになります。

このため，JSPから生成されたJavaソースのコンパイル時にコンパイルエラーとなります。

07-00以降のバージョンの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでは，スクリプト変数varで変数宣言をしません。この場合，各カスタムタグでのスコープ「AT_BEGIN」の範囲は次のようになります。

このため，同一スコープ内で同一の名称のスクリプト変数を定義しても，JSPから生成されたJavaソースのコンパイルは正常に実行されます。

●スクリプトレット記述時の注意

JSPからJavaソースを生成する際，スクリプトレットで記述されたJavaコードは解析しません。このため，カスタムタグの前後，またはボディのスクリプトレットで，スクリプト変数のスコープが変更される処理を定義していると，Cosminexusのバージョンによっては，JSPコンパイルの結果がエラーとなることがあります。

スコープが「AT_BEGIN」の場合にコンパイルエラーとなる例
この例では，カスタムタグ<my:foo>で，スコープに「AT_BEGIN」，属性idに指定された変数名（var）のスクリプト変数を定義しています。

<% if(flag) { %>

 <my:foo id="var" type="String">
   <%=var%>
 </my:foo>

<% } else { %>

 <my:foo id="var" type="String">
   <%=var%>
 </my:foo>

<% } %>

この定義例での，Cosminexusのバージョンごとの動作を次に示します。

07-00より前のバーションの場合
2回目のカスタムタグに対応するJSPから生成されたJavaコードでも，スクリプト変数varで変数宣言をします。このため，2回目のスクリプト変数varの参照でもエラーとなりません。JSPコンパイルは正常に実行されます。

07-00以降のバージョンの場合
2回目のカスタムタグでは，スクリプト変数varが宣言済みと解析します。この場合，カスタムタグに対応するJSPから生成されたJavaコードでは，変数varで変数宣言をしません。このため，2回目のスクリプト変数varの参照でエラーとなります。

4.32.9　<jsp:useBean>タグのclass属性に関する注意事項

<jsp:useBean>タグでは，class属性はオブジェクトの実装クラス名であることがJSPの仕様で定義されています。07-00以降では，この仕様に準拠して，JSPトランスレーション時に，class属性に指定されたクラスについて次のチェックを実施しています。

クラスの修飾子がpublicである。

クラスの修飾子がinterfaceではない。

クラスの修飾子がabstractではない。

メソッドの修飾子がpublicで引数がないコンストラクタが存在する。

このため，class属性にこれらのチェック項目に該当しないクラスを指定したとき，07-00より前と07-00以降ではJSPコンパイルの結果が異なります。

次のようにinclude元で実装クラスを指定して，include先でインタフェースを指定したJSPを例にして説明します。

test1.jsp（インクルード元）

<jsp:useBean id="bean" scope="request" class="test.TestBean"/>
<jsp:include page="test1_included.jsp"/>

test1_included.jsp（インクルード先）

<jsp:useBean id="bean" scope="request" class="test.TestBeanIF"/>

注　class属性に指定したtest.TestBeanはJSP仕様に準拠した実装クラス，test.TestBeanIFはtest.TestBeanのインタフェースになります。

この定義例での，Cosminexusのバージョンごとの動作を次に示します。

07-00より前のバーションの場合
JSPトランスレーション時にチェックを実施しないため，JSPファイルから生成されたサーブレットが実行されます。
JSPファイルから生成されたサーブレットでは，id属性に指定された"bean"で既存のスクリプト変数を検索します。上記ではインクルード元（test1.jsp）ですでに同一スクリプト変数が定義済みのため，class属性で指定されたクラス（test.TestBeanIFインタフェース）からのインスタンス化はしないで，既存のオブジェクト（test.TestBeanクラスのインスタンス）を使用します。そのため，正常に実行されます。

07-00以降のバージョンの場合
test1_included.jspは，JSPトランスレーション時にclass属性に指定されたクラスのチェックを実施するため，JSPトランスレーションでエラーとなります。

4.32.10　TLDファイルのバージョンに関する注意事項

07-00以降のバージョンでは，JSPトランスレーション時にTLDファイルのバージョン（TLDファイルが対応するJSPのバージョン）をチェックします。そのため，TLDファイルのバージョンが，Webアプリケーションのバージョンに対応しているJSPおよびTLDファイルのバージョンより上位のJSPの場合，JSPトランスレーションでエラーになります。また，JSP1.2，およびJSP2.0仕様では，TLDファイルにスキーマ言語を定義する必要があります。

TLDファイルのバージョンは，TLDファイルに記述されたスキーマ言語から判定します。ただし，スキーマ言語が定義されていない場合は，Webアプリケーションのバージョンから判定します。

TLDファイルにスキーマ言語を定義していない場合のTLDファイルのバージョンを次の表に示します。

表4-57　スキーマ言語未定義時のTLDファイルのバージョン

Webアプリケーションのバージョン | TLDファイルのバージョン
2.2 | 1.1
2.3 | 1.2
2.4 | 2.0

4.32.11　タグの属性値のExpressionチェックに関する注意事項

JSP仕様では，Expressionを指定できるタグの属性が制限されています。07-00以降のバージョンでは，JSPトランスレーション下位互換機能を使用しないでExpressionが指定できる属性以外でExpressionを指定した場合，JSPトランスレーション時にエラーになります。しかし，07-00より前のバージョンでは，JSPトランスレーション時にExpressionが指定できるかどうかをチェックしないため，Expressionを表す「<%=」や「%>」は文字列として認識されてエラーになりません。そのため，Expressionが指定できる属性以外でExpressionを指定した場合，07-00より前のバージョンと07-00以降のバージョンではJSPコンパイルの結果が異なります。

Expressionが指定できる属性以外でExpressionを指定しているJSPを使用する場合は，必ずJSPトランスレーション下位互換機能を設定してください。

4.32.12　タグの属性値に指定するExpressionに関する注意事項

タグの属性値にExpressionを指定する場合，「"<%= scriptlet_expr %>"」または，「'<%= scriptlet_expr %>'」と指定します。

タグの属性値が，「"<%=」（または「'<%=」）で開始していて「%>"」（または「%>'」）で終了していない場合，07-00より前のバージョンでは，「"」（または「'」）で囲まれた値を文字列として扱います。例えば，「%>」と「"」の間に，任意の文字列がある場合は，「"」で囲まれた値を文字列として扱います。しかし，07-00以降のバージョンでは，「%>"」（または「%>'」）を属性値の末尾として扱うため，JSPトランスレーション時にエラーになります。

タグの属性値が，「"<%=」（または「'<%=」）で開始していて「%>"」（または「%>'」）で終了していない場合は，必ずJSPトランスレーション下位互換機能を設定してください。

4.32.13　taglibディレクティブのprefix属性に関する注意事項

JSP仕様では，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを指定できません。07-00以降のバージョンでは，JSP仕様に従って，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述しているかをチェックします。taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合，トランスレーション時にエラーになります。しかし，07-00より前のバージョンでは，このチェックをしないため，記述されたカスタムタグは，文字列として扱われます。

そのため，taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用してカスタムタグを記述している場合は，07-00より前と07-00以降のバージョンではJSPコンパイルの結果が異なります。

taglibディレクティブの前にtaglibディレクティブで指定したprefixを使用したカスタムタグを記述している場合は，必ずJSPトランスレーション下位互換機能を設定してください。

5.　EJBコンテナ

この章では，Enterprise Beanの実行基盤である，EJBコンテナで利用できる機能について説明します。EJBコンテナの機能は，Enterprise Beanを使用したJ2EEアプリケーションを実行する場合に使用します。

なお，EJBコンテナの機能のうち，JNDI名前空間機能，Enterprise Beanでのトランザクション設定やアクセス制御では，J2EEサービスの機能も利用します。「9.　リソース接続とトランザクション管理」もあわせて参照してください。

＜この章の構成＞

5.1　EJBコンテナで使用できる機能

5.2　Enterprise Beanの実行

5.3　EJBコンテナのJNDI名前空間へのリファレンス登録

5.4　外部リソースとの接続

5.5　Enterprise Beanでのトランザクション設定

5.6　Entity Beanのコミットオプション指定

5.7　Enterprise Beanのプールの管理

5.8　Enterprise Beanへのアクセス制御

5.9　EJBコンテナでのタイムアウトの設定

5.10　Timer Serviceの機能

5.11　EJBのリモートインタフェースの呼び出し

5.12　セキュリティ管理

5.13　Enterprise Beanの実装

5.1　EJBコンテナで使用できる機能

EJBコンテナでは，Enterprise Beanを実行するコンテナとしての機能を提供しています。

EJBコンテナで使用できる機能を次の表に示します。なお，EJBクライアントで使用できる機能については，「6.1　EJBクライアントで使用できる機能」を参照してください。

表5-1　EJBコンテナで使用できる機能

機能 | 参照先
Enterprie Beanの実行 | 5.2
EJBコンテナのJNDI名前空間へのリファレンス登録※1 | 5.3
外部リソースとの接続 | 5.4
Enterprise Beanでのトランザクション設定※2 | 5.5
Entity Beanのコミットオプション指定 | 5.6
Stateless Session Beanのプーリング | 5.7.1
Entity Beanのプーリング | 5.7.2
Enterprise Beanへのアクセス制御 | 5.8
Stateful Session Beanのタイムアウト | 5.9.2
Entity BeanのEJBオブジェクトのタイムアウト | 5.9.3
RMI-IIOP通信のタイムアウト | 5.9.4
Timer Serviceの機能 | 5.10
EJBのリモートインタフェースの呼び出し | 5.11
セキュリティ管理 | 5.12

注※1

J2EEサービスのネーミング管理機能の利用によって実現します。管理機能の概要については，「8.　ネーミング管理」を参照してください。

注※2

J2EEサービスのトランザクション管理機能の利用によって実現します。J2EEサービスのトランザクション管理の概要については，「9.　リソース接続とトランザクション管理」を参照してください。

なお，Cosminexusで提供するEJBコンテナの機能には，J2EEで規定された機能にCosminexus独自の機能を拡張したものと，Cosminexus独自の機能として提供しているものがあります。Cosminexus独自の機能かどうかについては，「2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）」を参照してください。

5.2　Enterprise Beanの実行

EJBコンテナは，Enterprise Beanの実行を制御し，Enterprise Beanに各種のサービスを提供する実行環境です。

この節では，EJBコンテナで実行できるEnterprise Beanについて説明します。

＜この節の構成＞

5.2.1　Enterprise Beanの種類

5.2.2　Enterprise Beanのインタフェース

5.2.3　Enterprise Beanのライフサイクル

5.2.4　Enterprise Beanのアノテーション指定

5.2.5　DIの使用

5.2.6　デフォルトインターセプタの使用

5.2.7　アノテーションの参照抑止

5.2.8　EJBのチェック

5.2.9　CMPフィールドとデータ型のマッピング

5.2.1　Enterprise Beanの種類

Enterprise Beanは大きく分けて3種類あります。

Enterprise Beanの分類を次の表に示します。Cosminexusで提供しているEJBコンテナでは，これらのEnterprise Beanをサポートしています。

表5-2　EJBコンテナでサポートしているEnterprise Beanの分類

大分類 | 小分類
Session Bean | Stateless Session Bean
Stateful Session Bean
Entity Bean | BMP（Bean Managed Persistence）
CMP（Container Managed Persistence）
Message-driven Bean | なし

Session Bean，Entity Bean，およびMessage-driven Beanについて説明します。

＜この項の構成＞

(1)　Session Bean

(2)　Entity Bean

(3)　Message-driven Bean

(1)　Session Bean

Session Beanは，クライアントからのセッション単位に生成され，クライアントが終了すると消滅するEnterprise Beanです。Session Beanのライフサイクルは，ユーザがシステムの利用を開始してから終了するまでの範囲を超えることはありません。Session Beanは状態管理をするかどうかによって，Stateless Session BeanとStateful Session Beanに分類されます。

(a)　Stateless Session Bean

セッションの状態を管理しないモデルです。クライアントからの1セッションはBeanのビジネスメソッドの1回の呼び出しで完結させる必要があります。

(b)　Stateful Session Bean

セッションの状態を管理するモデルです。EJBコンテナが状態管理をします。クライアントからの1セッションがEJBの複数のビジネスメソッドを呼び出す場合でも，ビジネスメソッドの呼び出し間で状態が保存されます。

(2)　Entity Bean

Entity Beanは，エンティティを表現し，データベースに保存（永続化）されることを前提としています。そのため，クライアントが終了してもEntity Beanの状態はデータベースに存在し続けます。Session Beanと比較してライフサイクルが長いEnterprise Beanです。EJB仕様では，次の二つの管理モデルを規定しています。

(a)　BMP（Bean Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化の管理をするモデルです。データベースへの接続，SQLの組み立てや実行などの処理は，Enterprise Beanの開発者が実装しなければなりません。

(b)　CMP（Container Managed Persistence）

EJBコンテナがデータの永続化の管理をするモデルです。データベースへの接続とデータの保存はEJBコンテナによって実行されるので，Enterprise Beanのビジネスメソッドで実行する必要はありません。Enterprise Bean内のデータと格納先データベースのテーブルおよびカラムの対応をEJBコンテナが提供する方法で定義します。一方，接続先データベースのホスト名やポート番号などの接続情報をリソースアダプタまたはデータソースに定義します。EJBコンテナは，これらの定義情報を参照してSQL文を組み立て，接続先データベースのテーブルにデータの参照および格納をします。

なお，EJB 2.0で追加されたCMP 2.0ではEJB QLが導入されたため，使用するデータベースに依存することなく，データベースの検索処理をSQLのような構文でDDに記述できるようになりました。また，Entity Bean同士に関連を持たせるCMR（Container-managed relationship）が導入されたため，Entity Bean間の関連をDDで設定し，EJBコンテナで管理できるようになりました。

Cosminexusで提供するEJBコンテナのCMP機能でのEntity BeanのJavaデータ型とデータベースのSQLデータ型の対応については，「5.2.9　CMPフィールドとデータ型のマッピング」を参照してください。

(3)　Message-driven Bean

Message-driven Beanは，JMSと連携するメッセージ駆動タイプのBeanです。EJBコンテナはJMSのDestinationからのJMSメッセージ受信を契機にBeanを起動します。Session BeanまたはEntity Beanと異なり，ホームインタフェース，コンポーネントインタフェースを持たないため，クライアントから直接呼び出されません。

Message-driven Beanは，EJB 2.0の場合とEJB 2.1の場合で実装するインタフェースが異なります。

EJB 2.0の場合は，次のインタフェースを実装します。

javax.ejb.MessageDrivenBeanインタフェース

javax.jms.MessageListenerインタフェース

EJB 2.1の場合は，次のインタフェースを実装します。

javax.ejb.MessageDrivenBeanインタフェース

EISが提供する任意のメッセージリスナのインタフェース

EJB 2.0とEJB 2.1では，それぞれ対応するConnectorのバージョンが異なります。EJBとConnectorのバージョンの対応を次の表に示します。

表5-3　EJBとConnectorのバージョンの対応

EJBのバージョン | Connectorのバージョン
Connector 1.0 | Connector 1.5
EJB 2.0 | ○ | ×
EJB 2.1 | ○ | ◎

（凡例）

○：uCosminexus Reliable MessagingまたはTP1/Message Queue - Accessから送信されたメッセージを受信できます。

◎：任意の形式のリスナインタフェースを使用して送信されたメッセージを受信できます。

×：該当するリソースアダプタから送信されたメッセージを受信できません。

また，EJB 2.0とEJB 2.1では，次の表に示す機能差があります。

表5-4　EJB 2.0とEJB 2.1の機能差

機能
EJB 2.0
EJB 2.1

Connector 1.0の機能を使用する場合
Connector 1.5の機能を使用する場合

接続できるリソースアダプタ
Connector1.0仕様に準拠したリソースアダプタ。
Connector1.0仕様に準拠したリソースアダプタ。
Connector 1.5仕様に準拠し，Inboundが定義されているリソースアダプタ。

使用できるEIS

uCosminexus Reliable Messaging

TP1/Message Queue - Access

uCosminexus Reliable Messaging

TP1/Message Queue - Access

Connector 1.5をサポートする任意のEIS（JMSを含みます）。※

キューの定義方法
キュー定義ファイルに定義します。
キュー定義ファイルに定義します。
リソースアダプタのDD（ra.xml）内の管理対象オブジェクトに定義します。

JMSのバージョン
JMS1.0.2b
JMS1.0.2b
JMS1.1

メッセージリスナでのコネクションの管理方法
アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。
アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。
使用するリソースアダプタによって異なります。

注※

uCosminexus Reliable MessagingまたはTP1/Message Queue - AccessはConnector 1.5仕様に対応していないため，Connector 1.5の機能は使用できません。

5.2.2　Enterprise Beanのインタフェース

Enterprise Beanの実装に必要なインタフェースについて説明します。利用できるインタフェースの一覧を次の表に示します。

表5-5　利用できるインタフェースの一覧

インタフェース名 | 説明
リモートホームインタフェース※1 | EJB仕様1.1以降で規定されている，javax.ejb.EJBHomeを継承した，リモートクライアント用のインタフェースです。主に，Enterprise Beanインスタンスの取得のために使用します。
リモートコンポーネントインタフェース※2 | EJB仕様1.1以降で規定されている，javax.ejb.EJBObjectを継承した，リモートクライアント用のインタフェースです。主に，ビジネスメソッドを定義します。
リモートビジネスインタフェース | リモートクライアントからEnterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。規定されたインタフェースを継承する必要はありません。
ローカルホームインタフェース | EJB仕様2.0以降で規定されている，javax.ejb.EJBLocalHomeを継承した，ローカルクライアント用のインタフェースです。主に，Enterprise Beanインスタンスの取得のために使用します。
ローカルコンポーネントインタフェース | EJB仕様2.0以降で規定されている，javax.ejb.EJBLocalObjectを継承した，ローカルクライアント用のインタフェースです。主に，ビジネスメソッドを定義します。
ローカルビジネスインタフェース | ローカルクライアントからEnterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。規定されたインタフェースを継承する必要はありません。

注※1　EJB仕様1.1ではホームインタフェースと呼ばれるインタフェースです。

注※2　EJB仕様1.1ではリモートインタフェースと呼ばれるインタフェースです。

利用できるインタフェースの総称を次に示します。

表5-6　インタフェースの総称一覧

インタフェースの総称
説明

ホームインタフェース
次のインタフェースの総称です。

リモートホームインタフェース

ローカルホームインタフェース

コンポーネントインタフェース
次のインタフェースの総称です。

リモートコンポーネントインタフェース

ローカルコンポーネントインタフェース

ビジネスインタフェース
次のインタフェースの総称です。

リモートビジネスインタフェース

ローカルビジネスインタフェース

リモートインタフェース
次のインタフェースの総称です。

リモートホームインタフェース

リモートコンポーネントインタフェース

リモートビジネスインタフェース

ただし，リモートコンポーネントインタフェース，リモートビジネスインタフェースだけを指すこともあります。

ローカルインタフェース
次のインタフェースの総称です。

ローカルホームインタフェース

ローカルコンポーネントインタフェース

ローカルビジネスインタフェース

ただし，ローカルコンポーネントインタフェース，ローカルビジネスインタフェースだけを指すこともあります。

Enterprise Beanは少なくても一つのインタフェースを持ちます。ただし，Message-driven Beanは上記のインタフェースを持ちません。

＜この項の構成＞

(1)　リモートインタフェース

(2)　ローカルインタフェース

(3)　ビジネスインタフェースに対応する機能

(4)　ビジネスインタフェースのEnterprise Bean呼び出し

(1)　リモートインタフェース

リモートインタフェースではJava RMIのインタフェースの規定に従い，RMI-IIOP通信によってEnterprise Beanの呼び出しをします。クライアントが異なるJavaVMに存在するEnterprise Beanを呼び出すことができますが，実行時に通信上のオーバーヘッドが発生します。メソッド実行時の引数および戻り値は値渡し（pass by value）になります。

(2)　ローカルインタフェース

ローカルインタフェースの場合，Enterprise Beanの呼び出しはJavaのメソッド呼び出しで実行され，通信が発生しません。クライアントは同一J2EEアプリケーションに存在する場合にだけ，このインタフェースを利用できます。また，ローカルインタフェースを利用する場合には，リモートインタフェースと異なり，メソッド実行時の引数および戻り値は参照渡し（pass by reference）になります。

(3)　ビジネスインタフェースに対応する機能

ビジネスインタフェースを使用した場合でも，次の機能を使用できます。

ローカル呼び出し最適化機能
機能の詳細については，「5.11.1　EJBのリモートインタフェースでのローカル呼び出しの最適化」を参照してください。

リモートインタフェースの値の参照渡し機能
機能の詳細については，「5.11.2　EJBのリモートインタフェースの値の参照渡し」を参照してください。

RMI-IIOP通信でのタイムアウト
機能の詳細については，「5.9.4　RMI-IIOP通信のタイムアウト」を参照してください。
通信タイムアウトの設定は，定義ファイルまたはAPIで設定します。ビジネスインタフェースを使用した場合のタイムアウトの設定についての注意事項を次に示します。

定義ファイルで設定する場合
DI機能を使用するときに，EJBコンテナ内でJNDIを使用するため，JNDIの通信タイムアウトのプロパティも有効になります。

APIで設定する場合
スレッドには設定できますが，オブジェクトには設定できません。

また，タイムアウトの発生時には，ビジネスインタフェースがjava.rmi.Remoteを継承している場合はjava.rmi.RemoteException(org.omg.CORBA.TIMEOUT)，java.rmi.Remoteを継承していない場合はjavax.ejb.EJBException(RemoteException(org.omg.CORBA.TIMEOUT))が送出されます。

EJBのチェック機能
機能の詳細については，「5.2.8　EJBのチェック」を参照してください。

J2EEアプリケーションの実行時間監視のメソッドタイムアウト機能
機能の詳細については，「19.3.1　J2EEアプリケーション実行時間の監視の概要」を参照してください。
アノテーションを指定したEJBのメソッド呼び出し処理では，次の表に示すメソッド単位にタイムアウト値を設定できます。

表5-7　タイムアウトの適用範囲

インタフェース | メソッド | StatelessSession Bean | StatefulSessionBean | MessageDrivenBean | PersistenceAPI
ビジネスインタフェース | ビジネスメソッド※1 | ○ | ○ | － | －
ホームまたはコンポーネントインタフェース※2 | create | × | ○ | － | －
ビジネスメソッド | ○ | ○ | － | －
remove | × | ○ | － | －
javax.ejb.TimedObject | ejbTimeout | ○ | － | － | －

（凡例）　○：適用される　×：適用されない　－：該当なし

注※1　@Timeoutアノテーション，@Removeアノテーションが付いたメソッドを含みます。

注※2　@RemoteHomeまたは@LocalHomeを使用したインタフェースを指します。

(4)　ビジネスインタフェースのEnterprise Bean呼び出し

ここでは，同一J2EEサーバ内のほかのJ2EEアプリケーションで動作するビジネスインタフェースを呼び出す場合と，ほかのJ2EEサーバで動作するビジネスインタフェースを呼び出す場合について説明します。

どちらの場合も，呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先のEnterprise Beanのビジネスインタフェース，およびインタフェースで使用するユーザ作成クラスを含めます。また，JNDI名前空間に自動的にバインドされる名称またはユーザ指定名前空間機能で設定した別名を使用してルックアップします。ルックアップで使用する名称については，「8.2.2　EJBのリファレンスが自動的にバインドされる名称」を参照してください。

同一J2EEサーバ内のほかのJ2EEアプリケーションで動作するビジネスインタフェースのEnterprise Beanを呼び出す場合
呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先のEnterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めてください。
また，usrconf.propertiesのejbserver.rmi.localinvocation.scopeキーに「all」または「none」を指定してください。ただし，「none」を指定する場合は，呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドを使用してスタブを取得し，呼び出し元のEARファイルに含めてください。※

ほかのJ2EEサーバで動作するビジネスインタフェースのEnterprise Beanを呼び出す場合
呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドを使用してスタブを取得し，呼び出し元のEARファイルに含めてください。※

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用する場合は，スタブを含める必要はありません。ただし，ダイナミッククラスローディング機能は，性能上，推奨しません。

5.2.3　Enterprise Beanのライフサイクル

Enterprise Beanのライフサイクルについて，Enterprise Beanの種類ごとに説明します。

＜この項の構成＞

(1)　Session Beanのライフサイクル

(2)　Entity Beanのライフサイクル

(3)　Message-driven Beanのライフサイクル

(1)　Session Beanのライフサイクル

Session Beanのライフサイクルは，Stateless Session Beanの場合とStateful Session Beanの場合とで異なります。

(a)　Stateless Session Beanの場合

Stateless Session Beanのライフサイクルを次の図に示します。

図5-1　Stateless Session Beanのライフサイクル

does not exist：

Stateless Session Beanが存在しない状態

method-ready pool：

Stateless Session Beanが実行可能状態としてmethod-readyプール内に存在する状態

(b)　Stateful Session Beanの場合

Stateful Session Beanのライフサイクルを次の図に示します。

図5-2　Stateful Session Beanのライフサイクル

does not exist：

Stateful Session Beanが存在しない状態

method-ready：

Stateful Session Beanがアクティベイトされ，実行可能状態としてmethod-readyプール内に存在する状態（トランザクションなし）

method-ready in TX：

Stateful Session Beanがアクティベイトされ，実行可能状態としてmethod-readyプール内に存在する状態（トランザクションあり）

(2)　Entity Beanのライフサイクル

Entity Beanのライフサイクルを次の図に示します。

図5-3　Entity Beanのライフサイクル

does not exist：

Entity Beanが存在しない状態

pool：

Entity Beanがパッシベイトされ，passiveプール内に存在する状態

ready：

Entity Beanがアクティベイトされ，readyプール内に存在する状態

(3)　Message-driven Beanのライフサイクル

Message-driven Beanのライフサイクルを次の図に示します。

図5-4　Message-driven Beanのライフサイクル

does not exist：

Message-driven Beanが存在しない状態

method-ready pool：

Message-driven Beanがmethod-ready状態で，ServerSessionプール内に存在する状態

5.2.4　Enterprise Beanのアノテーション指定

EJBコンテナでは，Enterprise BeanがDDを持たない場合，またはDD（ejb-jar.xmlバージョン2.1）を持つ場合に，Enterprise Beanにアノテーションを指定できます。

アノテーションとは，ソースコードにクラスやメソッドの付加情報などを埋め込むための記述方式です。アノテーションを使用することで，従来，DD（ejb-jar.xml）で指定していた情報を，Enterprise Beanのソースコード上に指定できます。アノテーションを使用する場合のメリットを次に示します。

ソースコードとDDに分散していた情報を，ソースコード上に集約できます。

Enterprise BeanのDDを作成する必要がありません。

DIによって，ほかのEnterprise Beanやリソースへの参照を取得できます。

DIについては，「5.2.5　DIの使用」を参照してください。

ここでは，指定できるアノテーションや，アノテーションを指定した場合のEnterprise Beanの実装について説明します。

＜この項の構成＞

(1)　指定できるアノテーション

(2)　Enterprise Beanの実装

(3)　注意事項

(1)　指定できるアノテーション

指定できるアノテーションは，DD（ejb-jar.xmlバージョン2.1）がある場合と，DDがない場合とで異なります。

アプリケーションまたはリソースの属性取得（cjgetappprop，cjgetrespropコマンド），または属性設定（cjsetappprop，cjsetrespropコマンド）を実行した場合，アノテーションの要素は表示できますが，更新はできません。DDの要素は表示，更新できます。展開ディレクトリ形式のアプリケーションでは，アノテーションの更新ができます。更新したアノテーションは，次のタイミングで反映されます。

アプリケーションを開始したとき。

リロード機能を使用したとき。
リロード機能については，「7.5　J2EEアプリケーションの更新検知とリロード」を参照してください。

ただし，これらの方法で更新できるアノテーションと更新できないアノテーションがあります。DDがある場合，またはDDがない場合に指定できるアノテーションと，更新できるアノテーションの一覧を次の表に示します。

表5-8　指定できるアノテーション一覧

アノテーション名 | 指定できるアノテーション | 更新できるアノテーション
DDがある場合 | DDがない場合
@PostConstruct | × | ◎ | ○
@PreDestroy | × | ◎ | ○
@Resource | ◎ | ◎ | －
@Resources | ◎ | ◎ | －
@RunAs | × | ◎ | －
@DeclareRoles | × | ◎ | ○
@RolesAllowed | × | ◎ | －
@PermitAll | × | ◎ | ○
@DenyAll | × | ◎ | ○
@Stateless | × | ◎ | －
@Stateful | × | ◎ | －
@Init | × | ◎ | ○
@Remove | × | ◎ | ○
@Remote | × | ◎ | －
@Local | × | ◎ | －
@RemoteHome※ | × | ◎ | －
@LocalHome※ | × | ◎ | －
@TransactionManagement | × | ◎ | ○
@TransactionAttribute | × | ◎ | ○
@PostActivate | × | ◎ | ○
@PrePassivate | × | ◎ | ○
@Interceptors | × | ◎ | ○
@AroundInvoke | × | ◎ | ○
@ExcludeDefautInterceptors | × | ◎ | ○
@ExcludeClassInterceptors | × | ◎ | ○
@Timeout | × | ◎ | －
@ApplicationException | × | ◎ | ○
@EJB | ◎ | ◎ | －
@EJBs | ◎ | ◎ | －

（凡例）　◎：指定できる　×：指定できない　○：更新できる　－：更新できない

注※　@RemoteHomeまたは@LocalHomeアノテーションを使用してホームインタフェースを指定する場合，指定されたホームインタフェースのcreateメソッドの戻り値がコンポーネントインタフェースとみなされます。

(2)　Enterprise Beanの実装

アノテーションは，Session Beanで指定できます。アノテーションを指定して，Stateless Session Bean，またはStateful Session Beanを実装する場合について説明します。

(a)　Stateless Session Bean

Enterprise Beanの種類（Stateless Session Bean）は，@Statelessアノテーションで指定するか，またはDD（ejb-jar.xml）に指定します。

ビジネスインタフェースを使用してSession Beanを実装できます。

javax.ejb.SessionBeanインタフェースをインプリメントすることは，必須ではありません。

インターセプタクラスは，必要に応じて実装します。

Stateless Session Beanには，次のコールバックを定義できます。

@PostConstruct

@PreDestroy

コールバック，またはメソッドが呼び出されるタイミングについては，「5.2.3　Enterprise Beanのライフサイクル」を参照してください。

(b)　Stateful Session Bean

Enterprise Beanの種類（Stateful Session Bean）は，@Statefulアノテーションで指定するか，またはDD（ejb-jar.xml）に指定します。

ビジネスインタフェースを使用してSession Beanを実装できます。

javax.ejb.SessionBeanインタフェース，およびjava.io.Serializableインタフェースをインプリメントすることは，必須ではありません。

インターセプタクラスは，必要に応じて実装します。

次のコールバックを定義できます。

@PostConstruct

@PreDestroy

実装クラスのメソッドに@Initアノテーションおよび@Removeアノテーションを指定できます。

コールバック，またはメソッドが呼び出されるタイミングについては，「5.2.3　Enterprise Beanのライフサイクル」を参照してください。

(3)　注意事項

アノテーションを指定した場合の注意事項を説明します。

アノテーションで指定した値は，DD（ejb-jar.xml）や属性ファイルで変更できません。

一つのEJB-JAR内に，DDを持つEnterprise Beanと，DDを持たないEnterprise Beanを混在させることはできません。

アノテーションを使用する場合，インポート単位の外部への参照を含めることはできません。

ライブラリJARを使用する場合，該当するJARを含んだ形のアプリケーションとしてインポートしてください。

ほかのEJB-JARを参照するEJB-JARが存在する場合，両方のEJB-JARを含んだ形のアプリケーションとしてインポートしてください。ただし，参照する側のEJB-JARに，参照される側のインタフェースを含めている場合は，EJB-JARごとにインポートすることもできます。

EJB 2.0以前，またはServlet 2.3以前のバージョンのDDがある場合，アノテーションの指定は無効になります。

指定できるアノテーション以外のアノテーションを指定した場合は無効になります。

次の場合，インポート時に例外が発生します。

DDがなく，@Stateful Session Beanアノテーションまたは@Stateless Session Beanアノテーションの指定がないEnterprise Beanの場合。

DDのスキーマ定義の出現回数を超える数のアノテーションを指定した場合。

アノテーションが有効となるアプリケーション（DDを持たないEnterprise Beanを含む場合，バージョン2.1のDDを持つEnterprise Beanを含む場合，またはServlet 2.4の場合）に，package宣言と異なる場所に配置されているなどの不正なクラスファイルが含まれていると，アノテーションを指定しているかどうかに関係なく，インポート時に例外が発生します。

ローカルインタフェースおよびリモートインタフェースの両方を持つビジネスインタフェースに対して，@EJBアノテーションでリンク解決を行う場合，ローカルインタフェースへのリファレンスとして解釈されます。

5.2.5　DIの使用

Dependency Injection（DI）とは，EJBやインターセプタクラスのフィールドやsetterメソッドに，@EJBや@Resourceアノテーションを指定することで，Enterprise Beanやリソースへの参照をEJBコンテナが自動的にセットする機能です。DIを使用すると，Enterprise Beanやリソースへの参照を，JNDIを使用してルックアップする必要がなくなります。

ここでは，@Resourceアノテーションで指定できるリソースのタイプ，およびDIに関する注意事項について説明します。

＜この項の構成＞

(1)　@Resourceアノテーションで指定できるリソースのタイプ

(2)　注意事項

(1)　@Resourceアノテーションで指定できるリソースのタイプ

@Resourceアノテーションを使用して，リファレンスを定義できます。@Resourceアノテーションで指定できるリソースのタイプを次の表に示します。

表5-9　@Resourceアノテーションで指定できるリソースのタイプ

リソースのタイプ | 指定可否
javax.sql.DataSource※1 | ○
javax.mail.Session | ○
java.net.URL | ×
javax.jms.ConnectionFactory | ○
javax.jms.QueueConnectionFactory※2 | ○
javax.jms.TopicConnectionFactory | ○
javax.jms.Queue※2 | ○
javax.jms.Topic | ○
javax.resource.cci.ConnectionFactory※3 | ○
javax.resource.cci.InteractionSpec | ×
javax.transaction.UserTransaction | ○※4
org.omg.CORBA_ 2_3.ORB | ○※5
javax.xml.rpc.Service | ×
javax.xml.ws.Service | ×
javax.jws.WebService | ×
javax.ejb.EJBContext | ○※6
javax.ejb.SessionContext | ○※6
javax.ejb.TimerService | ○※6※7
JavaBeansリソース独自 | ○
java.lang.String | ○※8
java.lang.Character | ○※8
java.lang.Integer | ○※8
java.lang.Boolean | ○※8
java.lang.Double | ○※8
java.lang.Byte | ○※8
java.lang.Short | ○※8
java.lang.Long | ○※8
java.lang.Float | ○※8

（凡例）　○：指定できる　×：指定できない

注※1　DB Connectorが該当します。

注※2　TP1/Message Queue - Access，Cosminexus RMが該当します。

注※3　uCosminexus TP1 Connectorが該当します。

注※4　CMTで動作するEnterprise Beanまたはインターセプタでは使用できません。

注※5　ORBのshareable属性はtrueが指定されているものとして動作します。なお，注入されるORBオブジェクトは，ほかのコンポーネントでも使用される共有のインスタンスです。

注※6　Webコンテナ上で動作するクラスでは使用できません。

注※7　Stateful SessionBeanやStateful SessionBeanに適用されたインターセプタでは使用できません。

注※8　<env-entry-value>タグに，DIまたはルックアップで取得できる値を設定できません。

(2)　注意事項

DIを使用した場合の，Stateful Session Beanのリファレンス取得時の注意事項を次に示します。

J2EEアプリケーションがサーブレットからStateful Session Beanを呼び出す構成の場合，サーブレットでStateful Session Beanのリファレンスを取得するときは，DIを使用しないで，JNDI経由で行ってください。

J2EEアプリケーションがStateless Session BeanからStateful Session Beanを呼び出す構成の場合に，DIを使用してStateful Session BeanのビジネスインタフェースをStateless Session Beanに注入するとき，Stateless Session Beanのビジネスメソッド呼び出し，またはタイムアウトメソッド呼び出しのたびにDIが実行されます。

@Resourceアノテーションで指定できないリソースのタイプを指定した場合，インポート時に例外が発生します。

@EJBおよび@Resourceアノテーションのname属性は，次の表に示すejb-jar.xmlのタグの要素と対応しています。このため，アノテーションでEnterprise Beanおよびリソースへの参照を定義する場合は，@EJBおよび@Resourceアノテーションのname属性と，name属性に対応するejb-jar.xmlのタグに指定する要素は，重複しないように設定してください。name属性に対応するejb-jar.xmlのタグを次の表に示します。

表5-10　name属性に対応するejb-jar.xmlのタグ

アノテーションと属性 | name属性に対応するejb-jar.xmlのタグ
@EJB　name() | <ejb-ref>タグ下の<ejb-ref-name>タグ
<ejb-local-ref>タグ下の<ejb-ref-name>タグ
@Resource　name() | <env-entry>タグ下の<env-entry-name>タグ
<resource-ref>タグ下の<res-ref-name>タグ
<resource-env-ref>タグ下の<resource-env-ref-name>タグ

5.2.6　デフォルトインターセプタの使用

デフォルトインターセプタは，EJB-JAR属性ファイルを使用して，EJB-JARの属性として設定します。ここでは，EJB-JAR属性ファイルを使用したデフォルトインターセプタの使用方法について説明します。

注意

Cosminexusでは，EJB 3.0のDDをサポートしていません。このため，DDを使用してデフォルトインターセプタを設定することはできません。

EJB-JAR属性ファイルを使用してデフォルトインターセプタを使用する場合，<interceptor-order>タグによって実行順序を指定することはできません。

＜この項の構成＞

(1)　EJB-JAR属性ファイルでのデフォルトインターセプタの指定方法

(2)　インターセプタクラスの指定規則

(3)　注意事項

(1)　EJB-JAR属性ファイルでのデフォルトインターセプタの指定方法

EJB-JAR属性ファイルで，<hitachi-ejb-jar-property>タグ下の<interceptor-binding>タグを記述することで，デフォルトインターセプタの情報を指定できます。<interceptor-binding>タグ下に指定する要素を次の表に示します。

表5-11　デフォルトインターセプタを使用する場合に<interceptor-binding>タグ下に指定する要素

タグ名 | 必須／任意 | 指定内容
<description> | 任意 | 任意の情報を指定します。
<ejb-name> | 必須 | "*"（ワイルドカード）を指定します。
<interceptor-class> | 必須 | 要素にインターセプタクラスのクラス名を指定します。

これ以外のタグで指定した要素の値は，反映されません。

デフォルトインターセプタを使用する場合のEJB-JAR属性ファイルの記述例を次に示します。

<hitachi-ejb-jar-property>
　…(略)…
 <interceptor-binding>
   <description xml:lang="en">Default Interceptor</description>
   <ejb-name>*</ejb-name>
   <interceptor-class>test.ejb30.MyDefaultIC</interceptor-class>
   <interceptor-class>test.ejb30.MyDefaultIC2</interceptor-class>
 </interceptor-binding>
　…(略)…
</hitachi-ejb-jar-property>

この記述例では，デフォルトインターセプタクラスとして，「test.ejb30.MyDefaultIC」と「test.ejb30.MyDefaultIC2」の二つのクラスを指定しています。

EJB-JAR属性ファイルは，サーバ管理コマンド（cjsetapppropコマンド）を使用してJ2EEアプリケーションに設定します。なお，J2EEアプリケーションに含まれないEJB-JARファイルに対して，サーバ管理コマンド（cjsetresprop -type ejbコマンド）を使用して設定することはできません。サーバ管理コマンドについての詳細は，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。属性ファイルについての詳細は，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(2)　インターセプタクラスの指定規則

<interceptor-class>タグでのクラス名の指定方法は，EJB 3.0仕様に準じます。次の規則に従って指定してください。

一つの<interceptor-class>タグに指定できるインターセプタクラスのクラス名は一つです。

<interceptor-class>タグは複数記述できます。<interceptor-class>タグを複数記述した場合は，記述した順序でインターセプタが呼び出されます。

<interceptor-class>タグで指定したインターセプタクラスには，次に示すアノテーションを使用してインターセプタメソッドを指定できます。

@AroundInvoke

@PostConstruct

@PreDestroy

アノテーションについての詳細は，マニュアル「Cosminexus　リファレンス　API編」のCosminexusが対応しているアノテーションの説明を参照してください。

(3)　注意事項

<ejb-name>タグに"*"(ワイルドカード)を指定した<interceptor-binding>タグが複数ある場合は，1番上に記述された<interceptor-binding>タグの内容が有効になります。2番目以降の内容は設定されません。設定されない<interceptor-binding>タグの指定があった場合は，警告メッセージが出力されます。

Interceptorを使用した機能のうち，デフォルトインターセプタ以外の機能については，アノテーションを使用して設定してください。属性ファイルでは設定できません。
アノテーションで指定したInterceptorに関する設定値は，属性ファイルでは変更できません。また，<interceptor-order>タグなど，アノテーションで設定できない項目を属性ファイルに指定しても，値は反映されないで無視されます。

デフォルトインターセプタとして指定したクラス内で，次のアノテーションは使用できません。

@EJB

@EJBs

@Resource

@Resources

5.2.7　アノテーションの参照抑止

Cosminexusでは，EJB 2.1およびServlet 2.4仕様に基づいたアプリケーションでもアノテーションを使用できます。しかし，アノテーションの有無を判断するためにアプリケーションを解析するため，アノテーションを使用していない場合でも解析によるオーバーヘッドが大きくなります。また，リソースやほかのアプリケーションを参照するアプリケーションの場合，アノテーション解析時にクラスファイルの参照エラーが発生して，デプロイに失敗することがあります。アノテーションを使用しない場合は，アノテーション参照抑止機能を使用することで，J2EEサーバによるアノテーションの参照処理を抑止することができます。

アノテーション参照抑止機能は，J2EEサーバ単位で設定します。アノテーション参照抑止機能が有効になるのは，EJB 2.1およびServlet 2.4を使用したJ2EEアプリケーションです。アノテーション参照抑止機能を有効にした場合，アノテーションを記述したEJB 2.1またはServlet 2.4のモジュールを含むJ2EEアプリケーションは使用できなくなりますので，ご注意ください。アノテーション参照抑止機能の設定方法については，マニュアル「Cosminexus　システム構築ガイド」のアノテーションの参照を抑止する設定についての説明を参照してください。

アノテーション抑止機能が有効になる範囲を次の表に示します。

表5-12　アノテーション抑止機能が有効になる範囲

J2EEアプリケーションに含まれるモジュール | バージョン | 有効／無効
EJB | 1.1，2.0 | －
2.1 | ○
Servlet | 2.2，2.3 | －
2.4 | ○

（凡例）○：有効になる　－：無効になる

アノテーションを参照するタイミングを，アプリケーション参照抑止機能を使用する場合としない場合に分けて次の表に示します。

表5-13　アノテーションを参照するタイミング

タイミング
（実行したコマンド）
J2EEサーバの設定
アーカイブ形式のJ2EEアプリケーション
展開ディレクトリ形式のJ2EEアプリケーション

インポート時（cjimportapp）
使用する
×
×

使用しない
○
○

インポート時（cjimportres※1）
使用する
×
－

使用しない
○
－

開始時（cjstartapp※2）
使用する
×
×

使用しない
○※3
○

リプレース時（cjreplaceapp）
使用する
×
－

使用しない
△
－

リロード時（cjreloadapp）
使用する
－
×

使用しない
－
○

（凡例）

使用しない：アプリケーション参照抑止機能を使用しない設定のJ2EEサーバ

使用する：アプリケーション参照抑止機能を使用する設定のJ2EEサーバ

○：アノテーションを参照する

×：アノテーションを参照しない

△：アノテーションを参照するが変更は反映されない

－：該当しない

注※1　cjimportresコマンドに引数「-type ejb」または「-type war」を指定して実行した場合です。

注※2　J2EEサーバの再起動時も含みます。

注※3　その前にJ2EEサーバを起動したときと設定が異なる場合だけアノテーションをロードします。

アノテーション参照抑止機能が有効になっているかどうかは，簡易構築定義ファイルの<configuration>タグ内のパラメタ「ejbserver.deploy.applications.metadata_complete」に設定された値を参照してください。パラメタの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」およびマニュアル「Cosminexus　リファレンス　定義編」を参照してください。

5.2.8　EJBのチェック

EJBコンテナでは，J2EEアプリケーションの開始時に，各Enterprise Beanに対して，EJBの仕様に準拠しているかどうかをチェックします。このチェックの結果，仕様に準拠しないEnterprise Beanがあった場合は，Enterprise Beanを含むJ2EEアプリケーションの開始に失敗します。このとき，エラーメッセージが出力されます。

EJBのチェック処理は，次のタイミングで動作します。

J2EEアプリケーションをJ2EEサーバに最初にインポートして開始する時。

J2EEアプリケーションの構成を変更して（リデプロイ機能による変更を含む）開始する時。

J2EEサーバをベーシックモードから1.4モードに変更したあと，最初にJ2EEサーバを起動する時。

アップグレードインストールをしたあと，最初にJ2EEサーバを起動する時。

これらのタイミングで開始に成功すると，以降のJ2EEアプリケーションの開始と停止では，EJBチェック処理は動作しません。

5.2.9　CMPフィールドとデータ型のマッピング

Cosminexusで提供するEJBコンテナのCMP機能でのEntity BeanのJavaデータ型とデータベースのSQLデータ型の対応について説明します。

＜この項の構成＞

(1)　CMPでサポートするJavaデータ型の範囲

(2)　注意事項

(3)　HiRDBの場合のマッピング一覧

(4)　Oracleの場合のマッピング一覧

(1)　CMPでサポートするJavaデータ型の範囲

EJBコンテナのEntity BeanのCMPでサポートするJavaデータ型の範囲と，プライマリキーへの指定の可否を次の表に示します。

表5-14　CMPでサポートするJavaデータ型の範囲

Javaデータ型 | 値の範囲 | プライマリキーへの指定
boolean | true，false | ×
java.lang.Boolean | ○
byte | -128～127 | ×
java.lang.Byte | ○
char | '¥u0000'～'¥uffff'(0～65535) | ×
java.lang.Character | ○
short | -32768～32767 | ×
java.lang.Short | ○
int | -2147483648～2147483647 | ×
java.lang.Integer | ○
long | -9223372036854775808～9223372036854775807 | ×
java.lang.Long | ○
float※ | ±1.40239846e-45～±3.40282347e+38 | ×
java.lang.Float※ | ○
double※ | ±4.94065645841246544e-324～±1.79769313486231570e+308 | ×
java.lang.Double※ | ○
byte[] | 1Byte～2147483647Byte | ×
java.lang.String | － | ○
java.math.BigDecimal | － | ×
java.sql.Date | － | ×
java.sql.Time | 00:00:00～23:59:59 | ×
java.sql.TimeStamp | － | ×
Serializableな型 | － | ×

（凡例）

○：プライマリキーに指定できる。

×：プライマリキーに指定できない。

－：該当しない。

注※　浮動小数点を扱う場合，丸めが発生する可能性があります。

(2)　注意事項

固定長文字列のSQL型をCMPフィールドに用いる場合
固定長文字列のSQL型（Oracle，HiRDBのCHAR型）を用いる場合，データベース格納時にけた数に満たない文字数を空白で埋めるため，作成時のデータの後ろに空白が挿入される可能性があります。したがって，使用するときは十分に注意してください。

固定長文字列のSQL型をプライマリキーに用いる場合
固定長文字列のSQL型（Oracle，HiRDBのCHAR型）をキーに用いる場合，データベース格納時にけた数に満たない文字数を空白で埋めるため，作成時のデータと値が異なり，対象Entity Beanを取得できない可能性があります。したがって，使用するときは十分に注意してください。

(3)　HiRDBの場合のマッピング一覧

EJBコンテナのEntity BeanのCMPでのフィールドとデータベースのマッピングを次の表に示します。

なお，表中の「Javaデータ型」はCMPがサポートするJavaのデータ型，「JDBCデータ型」はJavaのデータ型に対応するJDBCのjava.sql.Types.のデータ型，「SQLデータ型」はJavaデータ型とのマッピングで推奨するDBカラムの型となります。

表5-15　CMPでのフィールドとデータベースのマッピング（HiRDB使用時）

Javaデータ型
JDBCデータ型
SQLデータ型

boolean
SMALLINT
SMALLINT

java.lang.Boolean

byte
SMALLINT
SMALLINT

java.lang.Byte

char※1
CHAR
CHAR(4)

java.lang.Character※1

short
SMALLINT
SMALLINT

java.lang.Short

int
INTEGER
INTEGER

java.lang.Integer

long
DECIMAL
DECIMAL(22)

java.lang.Long

float
REAL
REAL，SMALLFLT

java.lang.Float

double
FLOAT
DOUBLE PRECISION

java.lang.Double

byte[]※2
LONGVARBINARY
BLOB

java.lang.String※1
VARCHAR
VARCHAR(m)
CHAR(n)
MVARCHAR(m)
MCHAR(n)
NVARCHAR(x)
NCHAR(y)※3

java.math.BigDecimal
DECIMAL
DECIMAL(m,n)※4

java.sql.Date
DATE
DATE※5

java.sql.Time
TIME
TIME

java.sql.TimeStamp※6
CHAR
CHAR(29)

Serializableな型※2
LONGVARBINARY
BLOB

注※1　固定長文字列のSQL型を使用する場合の注意については，「(2)　注意事項」を参照してください。

注※2　[HiRDB BLOB最大値] 2147483647バイト

注※3　m，n，x，yの範囲はそれぞれ次のとおりです。

m：1～30000，n：1～32000，x：1～15000，y：1～16000

注※4　m，nの範囲はそれぞれ次のとおりです。

m：1～29，n：1～29

注※5　DATEの範囲は，0001/01/01～9999/12/31です。

注※6　「yyyy-mm-dd hh:mm:ss.fffffffff」（JDBC日付エスケープ）形式の文字列として格納します。

(4)　Oracleの場合のマッピング一覧

EJBコンテナのEntity BeanのCMPでのフィールドとデータベースのマッピングを次の表に示します。

なお，表中の「Javaデータ型」はCMPがサポートするJavaのデータ型，「JDBCデータ型」はJavaのデータ型に対応するJDBCのjava.sql.Types.のデータ型，「SQLデータ型」はJavaデータ型とのマッピングで推奨するDBカラムの型となります。

表5-16　CMPでのフィールドとデータベースのマッピング（Oracle使用時）

Javaデータ型
JDBCデータ型
SQLデータ型

boolean
NUMERIC
NUMBER(38)

java.lang.Boolean

byte
NUMERIC
NUMBER(38)

java.lang.Byte

char※1
CHAR
CHAR(4)

java.lang.Character※1

short
NUMERIC
NUMBER(38)

java.lang.Short

int
NUMERIC
NUMBER(38)

java.lang.Integer

long
NUMERIC
NUMBER(22)

java.lang.Long

float
NUMERIC
NUMBER

java.lang.Float

double※2
FLOAT
FLOAT(126)

java.lang.Double※2

byte[]※3
LONGVARBINARY
LONG RAW

java.lang.String※1
VARCHAR
VARCHAR(m)
CHAR(n)
LONG※4

java.math.BigDecimal
NUMERIC
NUMBER(m,n)※5

java.sql.Date
DATE
DATE※6 ※7

java.sql.Time
CHAR
CHAR(8)※8

java.sql.TimeStamp
TimeStamp
DATE※7 ※9

Serializableな型※3
LONGVARBINARY
LONG RAW

注　java.sql.Types.BLOBにマッピングされるBLOB，およびjava.spl.Types.CLOBにマッピングされるCLOBは扱えません。

注※1　固定長文字列のSQL型を使用する場合の注意については，「(2)　注意事項」を参照してください。

注※2　[Oracle FLOAT(126)の範囲] 1E-125～9.9・・・9E125

ただし，「丸め」が発生するおそれがあります。

注※3　[Oracle LONG RAW最大値] 2ギガバイト。

注※4　m，nの範囲はそれぞれ次のとおりです。

m=1～4000，n=1～2000

また，""（長さゼロの空文字）をOracleに格納するとNULLに変換されます。

注※5　m，nの範囲はそれぞれ次のとおりです。

m=1～38，n=-84～127

注※6　DATEの範囲は，-4712/01/01～9999/12/31です。

注※7　紀元前データはJava-JDBCドライバ間でマイナス値が正しく扱えないため，値は保証されません。

注※8　「hh:mm:ss」（JDBC日付エスケープ）形式の文字列として格納します。

注※9　DATEの範囲は，-4712/01/01 00:00:00～9999/12/31 23:59:59です。なお，Oracle8iでは小数点以下の秒数は扱えません。

5.3　EJBコンテナのJNDI名前空間へのリファレンス登録

EJBコンテナでは，java:comp/env名前空間へのリファレンスの登録をサポートしています。なお，該当するリファレンスは，（）内に示す名前空間に登録することを推奨しています。

環境エントリ（java:comp/env）

EJBホームオブジェクトリファレンス（java:comp/env/ejb）

ビジネスインタフェースのリファレンス（java:comp/env/ejb）

JMS（java:comp/env/jms）

JDBCデータソース（java:comp/env/jdbc）

JavaMailセッション（java:comp/env/mail）

uCosminexus TP1 Connector（java:comp/env/eis）

JavaBeansリソース（java:comp/env/bean）

これによって，java:comp/envのJNDI名前空間を使用して，間接的なルックアップができます。

なお，ネーミング管理機能については，「8.　ネーミング管理」を参照してください。

5.4　外部リソースとの接続

EJBコンテナで使用できるリソース，およびJ2EEリソースの詳細については，「9.　リソース接続とトランザクション管理」を参照してください。

5.5　Enterprise Beanでのトランザクション設定

EJBコンテナがサポートしているEnterprise Beanのトランザクション管理方法には，次の2種類があります。

BMT（Bean-Managed Transaction）

CMT（Container-Managed Transaction）

これらの機能は，J2EEサービスのトランザクション管理機能によって実現されます。

なお，トランザクション管理方法は，J2EEアプリケーションに含まれるSession BeanまたはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

トランザクション管理の概要については，「9.　リソース接続とトランザクション管理」を参照してください。

＜この節の構成＞

5.5.1　BMT

5.5.2　CMT

5.5.1　BMT

Enterprise Beanでトランザクション管理をするモデルです。BMTは，Session Bean，およびMessage-driven Beanが対象です（Entity Beanは対象外で，常にCMTになります）。

BMTでは，Enterprise Beanのビジネスメソッドでjavax.transaction.UserTransactionを利用し，次の操作をします。

トランザクションを開始

リソースマネジャを更新

トランザクションをコミットまたはロールバック

Stateless Session Beanでは，1ビジネスメソッド内で1トランザクションを決着（コミットまたはロールバック）させる必要があります。また，Message-driven Beanでは，次のどちらかのメソッド内で，トランザクションを決着（コミットまたはロールバック）させる必要があります。

onMessageメソッド（EJB 2.0の場合）

任意のメッセージリスナのメソッド（EJB 2.1の場合）

一方，Stateful Session Beanでは，複数のビジネスメソッドを一つのトランザクションスコープに含めることができます。このとき，EJBコンテナは，Beanインスタンスとトランザクションの関係を保持します。BMTでのStateful Session Beanを次の図に示します。

図5-5　BMTでのStateful Session Bean

表5-17　BMTのトランザクション制御

クライアント側トランザクション | Beanインスタンスのトランザクション | メソッドに結び付くトランザクション
なし | なし | なし
T1 | なし | なし
なし | T2 | T2
T1 | T2 | T2

（凡例）

なし：トランザクションを開始しない，またはトランザクションが関連づかない

T1：クライアント側で開始するトランザクション

T2：Bean側で開始するトランザクション

注意

トランザクションが決着していないときに，UserTransaction.beginメソッドを使って新しいトランザクションを開始した場合，EJBコンテナはjavax.transaction.NotSupportedExceptionを送出します。

5.5.2　CMT

EJBコンテナでトランザクション管理をするモデルです。CMTは，Session Bean，Entity Bean，Message-driven Beanが対象です。CMTでは，Beanのメソッド単位でトランザクションの属性を指定します。なお，トランザクション属性は，J2EEアプリケーションに含まれるSession Bean，Entity Bean，またはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

トランザクションがコミットできない場合，EJBコンテナは次の処理をします。

アプリケーションエラーのロギング

トランザクションのロールバック

Beanインスタンスの破棄

リモートコンポーネントインタフェースで呼び出すクライアントにはjava.rmi.RemoteException，ローカルコンポーネントインタフェースまたはビジネスインタフェースで呼び出すクライアントにはjavax.ejb.EJBExceptionを送出。ただし，リモートビジネスインタフェースがjava.rmi.Remoteを継承している場合には，java.rmi.RemoteExceptionを送出

＜この項の構成＞

(1)　トランザクション属性の種類と振る舞い

(2)　Enterprise Beanの種別ごとに指定できるトランザクション属性

(1)　トランザクション属性の種類と振る舞い

トランザクション属性の振る舞いについて，トランザクション属性の種類ごとに図に示して説明します。

●NotSupported属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Bean側には伝播しません。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Beanには伝播しません。

NotSupported属性の振る舞いを次の図に示します。

図5-6　NotSupported属性

●Required属性

クライアントがトランザクション内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，Enterprise Bean側で新しいトランザクションが開始されます。

Required属性の振る舞いを次の図に示します。

図5-7　Required属性

●Supports属性

クライアントがトランザクション内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Beanに伝播しません。

Supports属性の振る舞いを次の図に示します。

図5-8　Supports属性

●RequiresNew属性

クライアントがトランザクション内でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナは新しいトランザクションを開始します。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したときも，同様に新しいトランザクションがEJBコンテナによって開始されます。

RequiresNew属性の振る舞いを次の図に示します。

図5-9　RequiresNew属性

●Mandatory属性

クライアントがトランザクション内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナはクライアントに次の例外を送出します。

ビジネスインタフェースを使用している場合，javax.ejb.EJBTransactionRequiredExceptionを送出します。ただし，java.rmi.Remoteを継承しているリモートビジネスインタフェースの場合は，javax.transaction.TransactionRequiredExceptionを送出します。

リモートコンポーネントインタフェースを使用している場合，javax.transaction.TransactionRequiredExceptionを送出します。

ローカルコンポーネントインタフェースを使用している場合，javax.ejb.TransactionRequiredLocalExceptionを送出します。

Mandatory属性の振る舞いを次の図に示します。

図5-10　Mandatory属性

●Never属性

クライアントがトランザクション内でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナはクライアントに次の例外を送出します。

ビジネスインタフェースを使用している場合，javax.ejb.EJBExceptionを送出します。ただし，java.rmi.Remoteを継承しているリモートビジネスインタフェースの場合は，java.rmi.RemoteExceptionを送出します。

リモートコンポーネントインタフェースを使用している場合，java.rmi.RemoteExceptionを送出します。

ローカルコンポーネントインタフェースを使用している場合，javax.ejb.EJBExceptionを送出します。

また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Beanに伝播しません。

Never属性の振る舞いを次の図に示します。

図5-11　Never属性

(2)　Enterprise Beanの種別ごとに指定できるトランザクション属性

Enterprise Beanの種別ごとに指定できるトランザクション属性およびデフォルト値を次の表に示します。EJB仕様ではBean種別ごとに指定できるトランザクション属性が規定されています。CMP 2.0については，EJB仕様でオプションとされている，ほかのトランザクション属性は指定できません。デフォルト値についてはEJB仕様では規定されていません。Cosminexusの場合，EJBのDDでCMTの指定があり，トランザクション属性の指定がない場合のデフォルト設定は，次の表のようになります。

表5-18　Enterprise Beanの種別ごとに指定できるトランザクション属性およびデフォルト値

種別
指定できるトランザクション属性
デフォルト値

Stateless Session Bean
Stateful Session Bean
（SessionSynchronization以外）
Entity Bean（BMP，CMP 1.1）

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Supports

Stateful Session Bean
（SessionSynchronization）

Required

RequiresNew

Mandatory

Required

Entity Bean（CMP 2.0）

Required

RequiresNew

Mandatory

Required

Message-driven Bean（Connector 1.0に準拠したリソースアダプタを使用する場合）

Required

NotSupported

Required

Message-driven Bean（Connector 1.5に準拠したリソースアダプタを使用する場合）

Required※

NotSupported

Required※

アノテーションを使用した，DDを持たないSession Bean

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Required

注　ただし，DDを持たないEnterprise Beanの場合，デフォルト値（Required）が規定されています。

注※　EJBの仕様では指定可能ですが，CosminexusではConnector 1.5トランザクションに参加するメッセージ配信ができないため，Requiredを指定できません。指定できるのはNotSupportedだけです。

5.6　Entity Beanのコミットオプション指定

Entity Beanでは，次に示す３種類のCMPフィールドのキャッシュ方法，およびEntity Beanの状態遷移をサポートしています。

Full caching（commit option A）

Caching（commit option B）

No caching（commit option C）

なお，コミットオプションは，J2EEアプリケーションに含まれるSession BeanまたはEntity Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

(1)　Full caching（commit option A）

(2)　Caching（commit option B）

(3)　No caching（commit option C）

(1)　Full caching（commit option A）

Full cachingは，参照系のEntity Bean用のキャッシュモデルです。トランザクション開始時にデータベースからEntity Beanインスタンスにデータが読み込まれません。このため，Entity Beanが前回のトランザクションコミット時と同じ状態のままでトランザクションが開始されます。

例えば，前回のトランザクションコミット時からトランザクション開始時の間にほかのJ2EEサーバがEntity Beanを更新した場合，Entity Beanの状態の一貫性が保たれません。

(2)　Caching（commit option B）

Cachingは，更新系のEntity Beanのキャッシュモデルです。トランザクション開始時にデータベースからEntity Beanインスタンスにデータが読み込まれます。このため，Entity Beanがデータベースの最新状態と同じ状態でトランザクションが開始されます。

(3)　No caching（commit option C）

No cachingは，更新系のEntity Beanのキャッシュモデルです。トランザクションコミット時にEntity Beanが非活性化されます。トランザクション開始時には，一度活性化され，データベースからEntity Beanインスタンスにデータが読み込まれます。このため，Entity Beanがデータベースの最新状態と同じ状態でトランザクションが開始されます。このため，多数のEntity Beanを利用する場合に適用するキャッシュモデルです。

5.7　Enterprise Beanのプールの管理

EJBコンテナでは，Enterprise Beanの種類ごとに，プールを作成して管理します。

なお，プーリングの管理方法は，J2EEアプリケーションに含まれるEnteprise Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

5.7.1　Stateless Session Beanのプーリング

5.7.2　Entity Beanのプーリング

5.7.3　Message-driven Beanのプーリング

5.7.1　Stateless Session Beanのプーリング

Stateless Session Beanのプーリングは，クライアント側からのアクセス量に応じてStateless Session Beanをプーリングする機能です。EJBコンテナではStateless Session Beanごとにプールを作成して管理します。最大値※，最小値を指定することで，プーリングの動作をカスタマイズできます。

J2EEアプリケーション開始時には，最小値分のStateless Session Beanが生成され，プーリングされます。プーリングされたStateless Session Beanはmethod-ready状態で，クライアントからアクセスされるとすぐに実行されます。プーリングされるStateless Session Beanの数は，クライアントからのアクセス量に応じて，最大値と最小値の間になります。

このStateless Session Beanに対するクライアント要求数が最大数を超えると，インスタンスが使用できるようになるまで実行が待たされます。

注※

Stateless Session Beanでのプーリングの最大値は，クライアントが同時に確立できる最大セッション数となります。

5.7.2　Entity Beanのプーリング

Entity Beanのプーリングは，クライアント側からのアクセス量に応じてEntity Beanをプーリングする機能です。EJBコンテナでは，Entity Beanごとにプールを作成して管理します。最大値，最小値を指定することで，プーリングの動作をカスタマイズできます。

J2EEアプリケーション開始時には，最小値分のEntity Beanが生成され，プーリングされます。プーリングされるEntity Beanの数は，クライアントからのアクセス量に応じて，最大値と最小値の間になります。

さらに，プーリングされたEntity Beanの状態には，ready状態とpool状態の二つがあります。

ready状態のEntity Bean

データがデータベース上からインスタンス中に読み込まれた状態のもので，Entity Beanとしてのアイデンティティを持っています。ready状態のものは，クライアントからアクセスされた時点ですでに実行可能状態になっています。

pool状態のEntity Bean

データがデータベース上からインスタンス中に読み込まれていない状態のもので，Entity Beanとしてのアイデンティティを持っていません。pool状態のものは，一度活性化され，ready状態になってから実行可能状態になります。

ready状態のEntity Beanが多くなると，幾つかが非活性化され，pool状態になります。ただし，このとき，ready状態のEntity Beanの中でトランザクション中のものについては，非活性化の対象になりません。

5.7.3　Message-driven Beanのプーリング

Message-driven Beanのプーリングは，メッセージの数に応じてMessage-driven Beanをプーリングする機能です。最大値を指定することで，プーリングの動作をカスタマイズできます。

JMSからの要求に従って，プール内のインスタンスの最大数に指定した値分のインスタンスが，デプロイ時に生成されます。

インスタンスは，JMSからの要求に従って破棄されます。

5.8　Enterprise Beanへのアクセス制御

EJBコンテナでは，J2EEサービスのセキュリティ管理機能によって，クライアントからEnterprise Beanへのアクセスを制御できます。

なお，Enterprise Beanへのアクセス制御以外のセキュリティ管理の機能については，「5.12　セキュリティ管理」を参照してください。

＜この節の構成＞

5.8.1　Enterprise Beanへのアクセス制御の抑止

5.8.1　Enterprise Beanへのアクセス制御の抑止

EJBコンテナでは，J2EEサービスのセキュリティ管理機能によって，Enterprise Beanへのアクセスを制御できます。また，J2EEサーバのデフォルトの動作で，アプリケーションがアクセス制御の機能を利用していない場合でも，アクセス制御のための基本処理が動作します。

これに対して，Enterprise Beanへのアクセス制御を抑止するオプション（Enterprise Beanへのアクセス制御の抑止オプション）を使用すると，ビジネスメソッド呼び出し時に呼び出し元の実行権限のチェックを抑止できます。チェックを抑止すると，EJBコンテナではアクセス制御のための処理がまったく実施されないため，Enterprise Beanのビジネスメソッドの呼び出し処理が軽くなります。このため，アクセス制御の機能を利用しない場合は，抑止オプションを使用することをお勧めします。

ただし，アクセス制御の抑止オプションを利用したJ2EEサーバから，異なるJ2EEサーバ上のアクセス制御機能を利用したEnterprise Beanを呼び出す場合は，エラーが発生するので注意してください。

Enterprise Beanへのアクセス制御の抑止の設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

5.9　EJBコンテナでのタイムアウトの設定

EJBコンテナでは，次に示すタイムアウトを設定できます。

Stateful Session Beanのタイムアウト

Entity BeanのEJBオブジェクトのタイムアウト

RMI-IIOP通信のタイムアウト

インスタンス取得待ちのタイムアウト

これらのタイムアウトについて説明します。

＜この節の構成＞

5.9.1　タイムアウトの種類

5.9.2　Stateful Session Beanのタイムアウト

5.9.3　Entity BeanのEJBオブジェクトのタイムアウト

5.9.4　RMI-IIOP通信のタイムアウト

5.9.5　インスタンス取得待ちのタイムアウト

5.9.1　タイムアウトの種類

EJBコンテナで設定できるタイムアウトの種類，タイムアウト機能の概要，および参照先を次の表に示します。

表5-19　タイムアウトの種類

タイムアウトの種類 | タイムアウトの概要 | 参照先
Stateful Session Beanのタイムアウト | Stateful Session Beanが最後にアクセスされた時点からのタイムアウト時間を設定します。指定された時間が経過したものを削除します。 | 5.9.2
Entity BeanのEJBオブジェクトのタイムアウト | 非活性化されたEntity Beanに結び付くEJBオブジェクトにタイムアウト時間を設定します。指定された時間が経過したものを削除します。 | 5.9.3
RMI-IIOP通信のタイムアウト | EJBクライアント－CORBAネーミングサービス間，およびEJBクライアント－Enterprise Bean間の通信にタイムアウト時間を設定します。 | 5.9.4
インスタンス取得待ちのタイムアウト | Stateless Session Bean，Entity Beanに，リクエスト受信時のインスタンス取得の待ち時間にタイムアウト時間を設定します。 | 5.9.5

5.9.2　Stateful Session Beanのタイムアウト

Stateful Session Beanが最後にアクセスされた時点からの経過時間を監視し，指定された時間が経過してもクライアントからアクセスされない場合，タイマによってStateful Session Beanを削除する機能です。EJBコンテナでは，タイムアウト時間を指定できます。ただし，トランザクション中のStateful Session Beanについては，削除の対象になりません。

なお，タイムアウトによって削除されたStateful Session Beanを呼び出すと，インタフェースの種類によって，次の例外が送出されます。

リモートコンポーネントインタフェースの場合
java.rmi.NoSuchObjectExceptionが送出されます。

ローカルコンポーネントインタフェースの場合
java.ejb.NoSuchObjectLocalExceptionが送出されます。

ビジネスインタフェースの場合
javax.ejb.NoSuchEJBExceptionが送出されます。ただし，ビジネスインタフェースがjava.rmi.Remoteを継承している場合は，java.rmi.NoSuchObjectExceptionが送出されます。

Stateful Session Beanのタイムアウトの設定は，J2EEアプリケーションに含まれるSession Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

5.9.3　Entity BeanのEJBオブジェクトのタイムアウト

非活性化されたEntity Beanに結び付くEJBオブジェクトのうち，指定された時間が経過したものを削除する機能です。EJBコンテナでは，タイムアウト時間を指定できます。なお，タイムアウトによってEJBオブジェクトを削除されたEntity Beanを呼び出した場合，例外（java.rmi.NoSuchObjectException）が発生します。

ローカルインタフェースのEJBローカルオブジェクトも同様にタイムアウトによる削除対象になります。Entity BeanがEJBオブジェクト，EJBローカルオブジェクトの両方を持つ場合，非活性化されたEntity Beanに対するアクセスが，指定された時間内にどちらのインタフェースからもないときは，EJBオブジェクト，EJBローカルオブジェクトを削除します。削除されたEJBローカルオブジェクトを呼び出した場合，例外（javax.ejb.NoSuchObjectLocalException）が発生します。

Entity BeanのEJBオブジェクトのタイムアウトの設定は，J2EEアプリケーションに含まれるEntity Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

5.9.4　RMI-IIOP通信のタイムアウト

EJBクライアント－CORBAネーミングサービス間，EJBクライアント－Enterprise Bean間の通信に対して，タイムアウトを設定できます。また，EJBクライアントとJ2EEサーバの間にCTMを配置している場合，通信タイムアウトは，EJBクライアント－CTM間，およびCTM－J2EEサーバ間に設定できます。

RMI-IIOPの通信のタイムアウトには，EJBコンテナがRMI-IIOPの通信基盤として利用するCosminexus TPBrokerのリクエストタイムアウト機能を利用します。

＜この項の構成＞

(1)　タイムアウトを設定できるRMI-IIOP通信

(2)　通信タイムアウトの設定範囲とタイミング

(3)　通信タイムアウト発生時のクライアントの処理

(4)　通信タイムアウトの設定方法

(5)　通信タイムアウト設定時の注意事項

(1)　タイムアウトを設定できるRMI-IIOP通信

タイムアウトを設定できるRMI-IIOP通信を，CTM連携ありの場合となしの場合について図に示し，タイムアウトの設定範囲について説明します。

図5-12　タイムアウトを設定できる通信（CTM連携ありの場合）

図5-13　タイムアウトを設定できる通信（CTM連携なしの場合）

RMI-IIOP通信のタイムアウトは，図のA，B，Cの3か所に設定できます。

Aの場合
図5-12または図5-13の，項番1.～6.のRMI-IIOP通信すべてにタイムアウトが有効になります。タイムアウトの設定は，定義ファイルで行います。定義ファイルでの設定方法については，「(4)(a)　プロパティで設定する方法」を参照してください。

Bの場合
図5-12または図5-13の，項番1.，2.のCORBAネーミングサービスとの通信にタイムアウトが有効になります。タイムアウトの設定は，定義ファイルで行います。定義ファイルでの設定方法については，「(4)(a)　プロパティで設定する方法」を参照してください。

Cの場合
図5-12または図5-13の，項番4.～6.のAPIの通信にタイムアウトが有効になります。
EJBクライアントアプリケーションでのcreate～ビジネスメソッド～removeまでのAPIの通信のタイムアウト時間の設定は，アプリケーション開発時にAPI（RequestTimeoutConfigFactoryクラスおよびRequestTimeoutConfigクラスのメソッド）によって設定します。APIでの設定方法については，「(4)(b)　APIで設定する方法」を参照してください。

(2)　通信タイムアウトの設定範囲とタイミング

この機能による通信タイムアウトは，ORBに対して設定します。つまり，ORB配下のすべてのRMI-IIOP通信に対して設定されます。

設定のタイミングは，クライアント起動後の最初のnew javax.naming.InitialContext()実行時です。

CORBAネーミングサービスを利用しない場合でも，この機能を利用するときは，new javax.naming.InitialContext()をクライアントの処理の最初で実行してください。

(3)　通信タイムアウト発生時のクライアントの処理

クライアントからのリクエストに対してプロパティ指定値以内にレスポンスが返らない場合，該当リクエストはタイムアウトとしてキャンセルされます。この機能によって通信タイムアウトが発生した場合，java.rmi.RemoteException（org.omg.CORBA.TIMEOUT）の例外が発生します。この機能を利用するクライアントでは，Enterprise Beanのビジネスメソッド呼び出しなどで，この例外が発生することを考慮する必要があります。

(4)　通信タイムアウトの設定方法

タイムアウトの設定は，設定する範囲によって，定義ファイルのプロパティ，またはCosminexusが提供するAPIのどちらかで行います。プロパティで設定する方法とAPIで設定する方法の概要を説明します。

(a)　プロパティで設定する方法

図5-12，図5-13のAまたはBを設定する方法です。プロパティで設定する場合，タイムアウトの設定方法はEnterprise Beanがどこから呼び出されるかによって異なります。設定は，呼び出し元（EJBクライアント側）のJ2EEサーバ，WebコンテナサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。

次に，Enterprise Beanを呼び出すEJBクライアントの形態ごとの設定方法を示します。

●Enterprise Beanの場合

クライアント側のEnterprise Beanが動作するJ2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

●JSP，サーブレットの場合

クライアント側のJSP，サーブレットが動作するJ2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

●EJBクライアントアプリケーションの場合

EJBクライアントアプリケーションの実行時に有効なプロパティとして設定します。EJBクライアントアプリケーションのプロパティの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(b)　APIで設定する方法

図5-12，図5-13のCを設定する方法です。APIで設定する場合，com.hitachi.software.ejb.ejbclientパッケージのAPIを利用します。APIの機能と文法については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

RMI-IIOPの通信タイムアウトは，クライアントのプロセス起動後の，最初のInitialContext生成時にプロパティに指定した値が設定されます。ネーミングサービスを利用しない場合でも，RMI-IIOPの通信タイムアウトを設定する場合は，InitialContextを生成する必要があります。

ネーミングサービスの通信タイムアウトを設定する場合は，InitialContext生成やlookupなどの，JNDIのAPI呼び出し時にプロパティに指定した値が設定されます。

(5)　通信タイムアウト設定時の注意事項

通信タイムアウト設定時の注意事項について説明します。

通信タイムアウトの定義が重複している場合の注意事項
図5-12および図5-13のAの範囲とBの範囲の両方に通信タイムアウトを設定している場合，およびAの範囲とCの範囲に通信タイムアウトを設定している場合は次のように動作します。

Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合の動作
Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合，通信タイムアウトは次の図のようになります。

図5-14　Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合の動作

Aの範囲とCの範囲の両方に通信タイムアウトを設定している場合の動作
Aの範囲とCの範囲の両方に通信タイムアウトを設定している場合，Cの範囲の通信タイムアウト設定が有効となります。

クライアント実装時の注意事項
RMI-IIOPの通信タイムアウト，ネーミングサービスの通信タイムアウトと同時に，クライアントからのリクエストに対して指定値以内にレスポンスが返らない場合，該当するリクエストはタイムアウトとしてキャンセルされます。このとき，例外java.rmi.RemoteException（org.omg.CORBA.TIMEOUTなど）やjavax.naming.NamingExceptionが送出されます。通信タイムアウトを利用するクライアントを実装する場合，Enterprise Beanのメソッド呼び出しやJNDIのAPIなどでこれらの例外が発生することを考慮してください。

タイムアウト発生後のサーバ側の動作についての注意事項
クライアントからのリクエストがサーバ（ネーミングサービスやEnterprise Bean）に到着したあとに，サーバ側の処理中にタイムアウトが発生すると，クライアントに例外が返されます。ただし，タイムアウト発生後もサーバ側では正常に処理が継続されるため，Enterprise Beanのインスタンスの破棄や，リソースコネクションなどの資源の解放はされません。

5.9.5　インスタンス取得待ちのタイムアウト

EJBコンテナは，リクエストを受け付けるとインスタンスの割り当てをします。割り当て時に，インスタンスプール（Stateless Session Beanのmethod-readyプールおよびEntity Beanのpoolプール）に最大値が指定されている場合で，すべてのインスタンスでほかのリクエストを処理しているときには，インスタンスの取得待ちが発生します。この待ち時間に，タイムアウトを設定できます。

タイムアウトを設定していると，設定した時間内にインスタンスが取得できない場合は，クライアントに例外が返ります。

インスタンス取得待ちのタイムアウトの設定は，J2EEアプリケーションに含まれるSession BeanまたはEntity Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

5.10　Timer Serviceの機能

Timer Serviceとは，指定した時刻，経過時間，または間隔でEnterprise Beanを呼び出す機能です。この機能はEJBコンテナが提供します。Timer Serviceを使用すると，マシン負荷が低い時間を指定したバッチ処理や，一定間隔での日次処理など，時刻を指定した処理を容易に実行できます。

ここでは，Timer Serviceで設定できるタイムアウトの内容や，タイムアウトを設定するEJBタイマの動作，Timer Serviceの運用などについて説明します。

＜この節の構成＞

5.10.1　Timer Serviceの概要

5.10.2　EJBタイマの生成と削除

5.10.3　Timer Serviceの運用

5.10.4　EJBタイマとコールバックの動作についての注意事項

5.10.5　Timer Serviceを使用するアプリケーションの実装

5.10.1　Timer Serviceの概要

Timer Serviceで設定できるタイムアウトやTimer Serviceのサポート範囲，Timer Serviceでのトランザクション管理について説明します。

＜この項の構成＞

(1)　Timer ServiceとEJBタイマ

(2)　EJBタイマの種別

(3)　Timer Serviceのサポート範囲

(4)　Timer Serviceでのトランザクション管理

(1)　Timer ServiceとEJBタイマ

Timer Serviceは，J2EEに規定されたAPIを使用して，Enterprise Beanから操作します。時刻を指定した処理を行うには，EJBタイマを生成します。EJBタイマにはタイムアウト時刻を指定します。生成されたEJBタイマは，EJBコンテナに管理され，タイムアウト時刻になると，EJBコンテナによってEnterprise Beanのメソッドがコールバックされます。この際にコールバックされるメソッドを，タイムアウトメソッドと呼びます。

Timer Serviceの処理の概要を次の図に示します。

図5-15　Timer Serviceの処理の概要

(2)　EJBタイマの種別

EJBタイマに設定できるタイマ種別には次の2種類があります。

single-eventタイマ
タイムアウトメソッドを1回だけ実行するためのEJBタイマです。
タイムアウトの設定には，タイムアウトメソッドを実行する時刻を指定する方法と，EJBタイマ生成メソッドを呼び出してからタイムアウトメソッドを実行するまでの時間を指定する方法があります。

intervalタイマ
一定間隔で，繰り返しタイムアウトメソッドを実行するためのEJBタイマです。
タイムアウトの設定には，1回目のタイムアウトメソッドを実行する時刻を指定する方法と，EJBタイマ生成メソッドを呼び出してから1回目のタイムアウトメソッドを実行するまでの時間を指定する方法があります。また，この設定のほかに，2回目以降のタイムアウトメソッドを実行するためのタイムアウトの間隔を指定します。この間隔は，タイムアウトから次のタイムアウトまでの間隔です。

EJBタイマに設定できるタイマ種別と設定例を次の表に示します。

表5-20　EJBタイマに設定できるタイマ種別と設定例

タイマ種別 | 設定例 | 説明
single-event | 2006/4/15　12：00 | 2006/4/15　12：00にタイムアウトメソッドを1回だけ実行します。
24時間後 | EJBタイマが生成されてから24時間後に，タイムアウトメソッドを1回だけ実行します。
interval | 2006/4/1　12：00から24時間間隔 | 2006/4/1　12：00に1回目のタイムアウトメソッドを実行します。そのあと，24時間間隔でタイムアウトメソッドを繰り返し実行します。
24時間後から10時間間隔 | EJBタイマが生成されてから24時間後に，1回目のタイムアウトメソッドを実行します。そのあと，10時間間隔でタイムアウトメソッドを繰り返し実行します。

single-eventタイマとintervalタイマの動作を次の図に示します。この図では，2：00にタイムアウトメソッドを1回だけコールバックするsingle-eventタイマと，2：00から2時間間隔でタイムアウトメソッドをコールバックするintervalタイマの動作を示しています。

図5-16　single-eventタイマとintervalタイマの動作

(3)　Timer Serviceのサポート範囲

J2EEの仕様で規定されている，Timer Serviceの機能のサポート状況を次の表に示します。

表5-21　J2EEの仕様で規定されているTimer Serviceの機能のサポート状況

J2EEの仕様で規定されているTimer Serviceの機能 | サポート状況
トランザクション | ○
EJBタイマ永続性 | ×※
TimerServiceオブジェクトの取得（DI，JNDIルックアップ，EJBContext） | ○
タイムアウトメソッドの指定(アノテーション，TimedObject実装) | ○
タイムアウトメソッドの指定（DDによる指定） | ×

（凡例）　○：利用できる　×：利用できない

注※　障害などでJ2EEサーバを再起動したときは，再起動前に使用していたEJBタイマは引き継がれません。J2EEサーバ起動時にEJBタイマを自動で生成する場合は，「付録E　J2EEサーバ起動時のEJBタイマの自動生成」を参照してください。

Enterprise Beanの種別ごとに，Timer Serviceの機能のサポート状況を次の表に示します。

表5-22　Enterprise Beanの種別ごとの，Timer Serviceの機能のサポート状況

Timer Serviceの機能 | Message-driven Bean | Session Bean | Entity Bean
Stateful Session Bean | Stateless Session Bean
TimerServiceオブジェクトの取得 | × | － | ○ | ×
Timer Serviceに関するオブジェクト（TimerService，Timer，TimerHandle）の操作 | × | ○ | ○ | ×

（凡例）　○：利用できる　×：利用できない　－：利用できない（J2EE仕様）

(4)　Timer Serviceでのトランザクション管理

Timer Serviceは，トランザクションをサポートしています。具体的には，EJBタイマの生成，EJBタイマの削除，およびタイムアウトメソッドがトランザクションに対応しています。ここでは，タイムアウトメソッドのトランザクション管理について説明します。

EJBタイマの生成とEJBタイマの削除については，「5.10.2　EJBタイマの生成と削除」を参照してください。

(a)　タイムアウトメソッドに設定できるトランザクション属性

タイムアウトメソッドには，トランザクション管理にBMTまたはCMTを選択できます。

CMTの場合に，タイムアウトメソッドに指定できるトランザクション属性を次に示します。

Required属性

RequiresNew属性

NotSupported属性

これ以外の属性が指定された場合，J2EEアプリケーションの開始に失敗します。

(b)　タイムアウトメソッドのコールバックに対するトランザクション管理

タイムアウトメソッドに，CMTでRequired属性またはRequiresNew属性を指定した場合，タイムアウトメソッドのコールバック中にトランザクションがロールバックすると，コールバックをリトライします。コールバックのリトライについては「5.10.3(1)(b)　タイムアウトメソッドのコールバックリトライ」を参照してください。

5.10.2　EJBタイマの生成と削除

Timer Serviceによって指定した時刻に処理を実行するには，EJBタイマを生成します。また，EJBタイマによる処理の実行を停止するには，EJBタイマを削除します。EJBタイマの生成，削除のタイミングは，EJBタイマの種別や，トランザクションの管理下で処理が実行されるかどうかによって異なります。ここでは，EJBタイマの生成と削除のタイミング，およびEJBタイマの生成時と削除時のタイムアウトメソッドのコールバックの動作について説明します。

＜この項の構成＞

(1)　EJBタイマの生成

(2)　EJBタイマの削除

(1)　EJBタイマの生成

EJBタイマ生成では，EJBタイマ生成メソッド（javax.ejb.TimerServiceオブジェクトのcreateTimerメソッド）によって，EJBタイマが一つ生成されます。EJBタイマが生成されると，指定した時刻にタイムアウトが発生してタイムアウトメソッドがコールバックされます。

(a)　タイムアウト時刻のカウント

EJBタイマ生成時に，EJBタイマを呼び出してから1回目のタイムアウトメソッドを実行するまでの時間を指定しているEJBタイマの場合，時間のカウントは，EJBタイマ生成メソッドが呼ばれた時刻を基点に開始されます。EJBタイマの生成とカウントの開始について次の図に示します。

図5-17　EJBタイマの生成とカウントの開始

(b)　EJBタイマ生成とタイムアウトメソッドのコールバック実行のタイミング

EJBタイマが生成されるタイミングおよびタイムアウトメソッドがコールバックされるタイミングは，EJBタイマ生成がトランザクションの管理下で行われるかどうかによって異なります。

EJBタイマ生成がトランザクションの管理下で行われる場合

EJBタイマは，トランザクションがコミットした時に生成されます。

タイムアウトメソッドのコールバックが実行されるタイミングは，トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合と，トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合とで異なります。なお，トランザクションがロールバックされた場合は，EJBタイマの生成は取り消されます。

トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合
指定した時刻どおりにタイムアウトメソッドがコールバックされます。EJBタイマ生成とコールバックの実行について次の図に示します。

図5-18　EJBタイマ生成とコールバックの実行（トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合）

この図では，EJBタイマ生成メソッドが呼ばれた時点から，タイムアウト時刻までのカウントが開始され，指定した時刻どおりにタイムアウトメソッドがコールバックされます。EJBタイマが生成されるのは，トランザクションコミット時です。

トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合
トランザクションがコミットした直後にタイムアウトメソッドがコールバックされます。EJBタイマ生成とコールバックの実行について次の図に示します。

図5-19　EJBタイマ生成とコールバックの実行（トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合）

この図では，EJBタイマ生成メソッドが呼ばれた時点から，タイムアウト時刻までのカウントが開始され，トランザクションコミットの前にタイムアウト時刻になります。トランザクションコミット時までEJBタイマは生成されないため，タイムアウト時刻になってもタイムアウトメソッドはコールバックされません。トランザクションがコミットした直後にコールバックされます。

EJBタイマ生成がトランザクションの管理下で行われない場合

EJBタイマはEJBタイマ生成メソッドが呼ばれた直後に生成されます。

トランザクションの管理下でない場合のEJBタイマ生成について次の図に示します。

図5-20　EJBタイマ生成とコールバックの実行（トランザクションの管理下でない場合）

この図では，EJBタイマ生成メソッドが呼ばれた直後にEJBタイマが生成されます。そのあと，指定した時刻どおりにタイムアウトメソッドがコールバックされます。

(2)　EJBタイマの削除

EJBタイマを削除するには，EJBタイマキャンセルを行います。

なお，single-eventタイマの場合は，タイムアウトメソッドのコールバック完了時にEJBタイマが削除されます。intervalタイマの場合，EJBタイマキャンセルが行われるまでEJBタイマは削除されません。

EJBタイマキャンセルでは，EJBタイマキャンセルメソッド（javax.ejb.Timerオブジェクトのcancelメソッド）によって，EJBタイマが一つ削除されます。EJBタイマが削除されると，それ以降のコールバックは実行されません。EJBタイマキャンセルによってEJBタイマが削除されるタイミングは，EJBタイマキャンセルがトランザクションの管理下で行われるかどうかによって異なります。

EJBタイマキャンセルがトランザクションの管理下で行われる場合

EJBタイマは，トランザクションのコミット時に削除されます。そのため，EJBタイマキャンセルメソッドが呼ばれてから，トランザクションがコミットするまでの間にタイムアウト時刻になることがあります。

トランザクションがロールバックされた場合は，EJBタイマキャンセルは取り消されます。

EJBタイマキャンセルがトランザクションの管理下で行われない場合

EJBタイマは，EJBタイマキャンセルメソッドが呼ばれた直後に削除されます。

参考

J2EEアプリケーションの停止時には，停止対象のJ2EEアプリケーションのEJBタイマはすべて削除されます。J2EEサーバの停止または異常終了時には，J2EEサーバ上のEJBタイマはすべて削除されます。

5.10.3　Timer Serviceの運用

Timer Serviceの運用で使用する機能，および注意事項について説明します。

＜この項の構成＞

(1)　Timer Serviceの運用機能

(2)　Timer Serviceの運用に関する注意事項

(1)　Timer Serviceの運用機能

Timer Serviceの運用で使用する機能について説明します。運用機能には次の二つがあります。

タイムアウトメソッドのコールバックスレッド数制御機能

タイムアウトメソッドのコールバックリトライ機能

これらの機能は，J2EEサーバのプロパティをカスタマイズして設定します。設定するプロパティについては，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバの動作設定のカスタマイズに関する説明を参照してください。

(a)　タイムアウトメソッドのコールバックスレッド数制御機能

タイムアウトメソッドのコールバックを処理するスレッドを，J2EEサーバ全体で同時に幾つ実行するかを設定します。これをコールバック最大スレッド数といいます。

複数のEJBタイマが同時にタイムアウトした場合，タイムアウトメソッドのコールバックの最大スレッド数の設定によって，次のような動作になります。

コールバック最大スレッド数：1（デフォルト）の場合
コールバック処理は順次行われます。そのため，EJBタイマに設定した時刻よりも遅れてコールバック処理が開始されることがあります。

コールバック最大スレッド数：2以上の場合
設定した数だけ並行してコールバック処理が実行されます。最大スレッド数を増加させた場合，その分だけリソースを消費するため，並行に実行させたいスレッド数を適切に設定してください。

コールバック最大スレッド数の設定とコールバック処理の関係について次の図に示します。

図5-21　コールバック最大スレッド数の設定とコールバック処理の関係

この図の場合，EJBタイマ1のタイムアウトの1分後に，EJBタイマ2のタイムアウトになる設定にしています。コールバック最大スレッド数を1に設定した場合は，EJBタイマ1のコールバック処理が終了したあと，EJBタイマ2のコールバック処理が開始されます。コールバック最大スレッド数を2に設定した場合は，二つのコールバックを並行して処理できるため，設定どおりにEJBタイマ1の1分後にEJBタイマ2のコールバック処理が開始されます。

注意

コールバックのスレッド数に余裕がある場合でもEnterprise Beanのインスタンスが不足していると，インスタンスが解放されるのを待ってコールバック処理が行われます。そのため，コールバックするインスタンス数を考慮してEnterprise Beanインスタンスプールを設定してください。

(b)　タイムアウトメソッドのコールバックリトライ

タイムアウトメソッドのコールバックに失敗した場合は，コールバックをリトライします。

コールバックが失敗する要因として次のケースが考えられます。

タイムアウトによるコールバック時に，非検査例外（java.lang.RuntimeException，java.lang.Errorおよびそれらのサブクラス）がスローされた場合

タイムアウトメソッドがCMTのRequired属性またはRequiresNew属性で，そのトランザクションがロールバックした場合

コールバックのリトライを行うには，次の二つを設定します。

リトライ回数

リトライする回数を設定します。0を設定した場合は，リトライしません。また，リトライ実行回数が設定したリトライ回数に達すると，そのタイムアウトでのリトライは行いません。

リトライの実行間隔

コールバックが失敗してから，リトライのコールバックを行うまでの時間を設定します。

(2)　Timer Serviceの運用に関する注意事項

Timer Serviceを利用する場合の注意事項について説明します。

Timer Serviceを利用した場合，EJBタイマに指定した時刻と，実際にタイムアウトメソッドがコールバックされる時刻に差が生じることがあります。この場合，次の要因が考えられます。

ガーベージコレクションの実行
EJBタイマで指定した時刻に，JavaVMでガーベージコレクションが実行された場合，ガーベージコレクションの処理が優先されます。ガーベージコレクションが終了してからタイムアウトメソッドがコールバックされるため，指定した時刻との差異が生じることがあります。

プラットフォームやハードウェア環境
Timer Serviceでは，JavaVMの時間を使用します。JavaVMの時間は，プラットフォームやハードウェア環境に依存します。コールバックもJavaVMの時間に従って実行されるため，指定した時刻との差異が生じることがあります。

J2EEサーバが稼働するマシンで，NTPクライアントソフトウェアなどによってシステム時刻が修正された場合，登録済みのEJBタイマのタイムアウト時刻は次のような動作になります。

single-eventタイマの場合
修正前のシステム時刻が継続されているものとして，タイムアウトが発生します。

intervalタイマの場合
修正後，修正前のシステム時刻が継続されているものとして1回目のタイムアウトが発生します。2回目以降は，修正後のシステム時刻に従ってタイムアウトが発生します。

5.10.4　EJBタイマとコールバックの動作についての注意事項

次の場合のEJBタイマの動作およびコールバックの動作について説明します。

EJBタイマに過去の時刻が指定された場合

一つのEnterprise Beanのクラスで複数のEJBタイマを設定している場合

タイムアウト時に，前回のコールバックが終了していない場合

複数スレッドからEJBタイマキャンセルが呼ばれた場合

コールバック実行中にEJBタイマキャンセルが呼ばれた場合

コールバック時に，EJBタイマキャンセルを行った未決着トランザクションがある場合

＜この項の構成＞

(1)　EJBタイマに過去の時刻が指定された場合

(2)　一つのEnterprise Beanのクラスで複数のEJBタイマを設定している場合

(3)　タイムアウト時に，前回のコールバックが終了していない場合

(4)　複数スレッドからEJBタイマキャンセルが呼ばれた場合

(5)　コールバック実行中にEJBタイマキャンセルが呼ばれた場合

(6)　コールバック時に，EJBタイマキャンセルを行った未決着トランザクションがある場合

(1)　EJBタイマに過去の時刻が指定された場合

EJBタイマに過去の時刻が指定された場合，single-eventタイマのときはEJBタイマの生成直後に1回タイムアウトメソッドをコールバックします。intervalタイマの場合は，EJBタイマ生成後の時刻に発生するタイムアウト時にタイムアウトメソッドをコールバックします。EJBタイマに過去の時刻が指定された場合の動作を次の図に示します。

図5-22　EJBタイマに過去の時刻が指定された場合の動作

single-eventタイマの場合

2：00にタイムアウトが発生するsingle-eventタイマが，すでにタイムアウトの時刻を過ぎた4：15に生成された場合，生成直後に1回タイムアウトメソッドをコールバックします。

intervalタイマの場合

2：00から2時間間隔でタイムアウトが発生するintervalタイマが，すでにタイムアウトの時刻を過ぎた4：15に生成された場合，それ以降の時刻に発生するタイムアウト時（1回目は6：00）にタイムアウトメソッドをコールバックします。

(2)　一つのEnterprise Beanのクラスで複数のEJBタイマを設定している場合

一つのEnterprise Beanクラスに対して，複数のEJBタイマがある場合に，それらの複数のEJBタイマのコールバックが重なったときは，コールバック処理が並列に行われます。ただし，並列に処理できるコールバックスレッドやEnterprise Beanインスタンスがある場合に限ります。このようなコールバックスレッドやインスタンスがない場合は，スレッドやインスタンスが解放されるまで待ちます。

(3)　タイムアウト時に，前回のコールバックが終了していない場合

一つのEJBタイマで同時に実行できるコールバックは一つだけです。タイムアウトメソッドの処理は，処理内容によっては時間が長く掛かることがあります。そのため，intervalタイマの場合，コールバック処理の実行中に次のタイムアウトの時刻を過ぎてしまい，一つのコールバックが完了するまでに複数のタイムアウト時刻を経過することがあります。この場合，タイムアウトの時刻どおりに実行されなかったコールバック処理は行わないで，前回のコールバックが終了した時刻よりあとに発生するタイムアウトのコールバック処理を行います。

コールバック時に，前回のコールバックが終了していない場合の動作を次の図に示します。

図5-23　コールバック時に前回のコールバックが終了していない場合の動作

この図の場合，1分間隔でタイムアウトが発生してコールバック処理を実行する設定にしています。1回目のコールバックの処理中に，2回目と3回目のタイムアウトの時刻を過ぎてしまった場合，1回目のコールバック処理が終了したあとの，次のタイムアウト時刻（予定では4回目のタイムアウトの時刻）に2回目のコールバック処理を行います。タイムアウト時刻を過ぎてしまった2回分のコールバック処理は行われません。

(4)　複数スレッドからEJBタイマキャンセルが呼ばれた場合

同時に複数のスレッドから，同一EJBタイマのEJBタイマキャンセルメソッドが呼ばれた場合，キャンセルの処理は順次行われます。

ただし，トランザクション管理下でEJBタイマキャンセルが行われた場合，トランザクションが決着するまでは，EJBタイマが削除されるかどうかを確定できません。そのため，そのほかのスレッドが同じEJBタイマのキャンセルを行うと，排他待ちとなります。

同時に複数のスレッドから，同一のEJBタイマのキャンセルが呼ばれた場合の動作を次の図に示します。

図5-24　複数スレッドからのEJBタイマのキャンセル

(5)　コールバック実行中にEJBタイマキャンセルが呼ばれた場合

EJBタイマのキャンセル時に，タイムアウトメソッドのコールバックが実行中の場合，次のような動作になります。

EJBタイマキャンセルメソッドの呼び出しは正常終了します。

タイムアウトメソッドのコールバック処理は継続して実行されますが，コールバック完了後に次の動作をします。

タイムアウトメソッドがCMTのトランザクションを使用している場合，そのトランザクションはロールバックされます。

タイムアウトメソッドがCMTのトランザクションを使用していない場合，コールバック中に行われたトランザクションの決着には関与しません。

通常ではコールバックをリトライする次のケースで終了した場合でも，リトライしません。

CMTのトランザクションがロールバックされた場合

非検査例外がスローされた場合

コールバック完了時に，メッセージログにメッセージが出力されます。

タイムアウトメソッドがCMTのトランザクションを使用している場合，KDJE43161-Wが出力されます。

タイムアウトメソッドがCMTのトランザクションを使用していない場合は，KDJE43160-Wが出力されます。

CMTのトランザクションを使用するタイムアウトメソッドのコールバック実行中に，別のトランザクションからEJBタイマキャンセルが行われた場合と，CMTのトランザクションを使用するタイムアウトメソッドの中でEJBタイマキャンセルが行われた場合では動作が異なります。

CMTのトランザクションを使用するタイムアウトメソッドのコールバック実行中に，別のトランザクションからEJBタイマキャンセルが行われた場合の動作を次の図に示します。

図5-25　コールバック実行中のキャンセル

CMTトランザクションを使用するタイムアウトメソッドの中でEJBタイマキャンセルが行われた場合の動作を次の図に示します。

図5-26　タイムアウトメソッドでのEJBタイマキャンセル

この図の場合，実際にEJBタイマがキャンセルされるのは，タイムアウトメソッド完了後です。このため，トランザクションがコミットした場合，EJBタイマはキャンセルされます。トランザクションがロールバックした場合，EJBタイマは存続します。

(6)　コールバック時に，EJBタイマキャンセルを行った未決着トランザクションがある場合

EJBタイマキャンセルを行った未決着のトランザクションAが存在する場合，タイムアウトメソッドのコールバックの処理は，コールバック完了時からトランザクションAが決着するまで排他待ちとなります。したがって，タイムアウトメソッドがCMTのトランザクションの管理下にある場合，そのトランザクションの決着は，トランザクションAが決着するまで待ちます。この場合の流れを次の図に示します。

図5-27　キャンセルを行った未決着トランザクションがある場合のコールバックの動作

5.10.5　Timer Serviceを使用するアプリケーションの実装

Timer Serviceを使用する場合のアプリケーションの実装内容を示します。

タイムアウトメソッドの指定
次に示すどちらかの方法で，コールバックするタイムアウトメソッドを指定します。

タイムアウトメソッドとして利用するメソッドに，Timeoutアノテーションを指定します

Enterprise BeanにTimedObjectインタフェースを実装します。この場合，TimedObjectインタフェースで定義されているejbTimeoutメソッドがタイムアウトメソッドとなります。

javax.ejb.TimerServiceオブジェクトの取得
DIやEJBContextインタフェースのgetTimerServiceメソッドや，JNDIのlookupメソッドなどを使用して，TimerServiceオブジェクトを取得します。

EJBタイマ（Timer）の生成
TimerServiceオブジェクトのcreateTimerメソッドを呼び出し，Timerを生成するコードを実装します。

EJBタイマ（Timer）のキャンセル
キャンセルする処理が必要な場合は，Timerをキャンセルするコードを実装します。Timerは，javax.ejb.TimerServiceやjavax.ejb.TimerHandleから取得します。

これらの処理を実装した例と，実装時の注意事項を示します。

＜この項の構成＞

(1)　DIを使用した場合の実装例（タイムアウトメソッドをTimeoutアノテーションで指定）

(2)　EJBContextを利用した場合の実装例（TimedObjectインタフェースを実装）

(3)　lookupを利用した場合の実装例（TimedObjectインタフェースを実装）

(4)　Timer Service実装時の注意事項

(1)　DIを使用した場合の実装例（タイムアウトメソッドをTimeoutアノテーションで指定）

アノテーションを使用した場合の実装例を示します。この例では，Timeoutアノテーション（@Timeout）でタイムアウトメソッド（myTimeout）を指定しています。

@Stateless public class TimerSessionBean{
 @Resource TimerService timerService;

 public void createMyTimer(long intervalDuration){
   Timer timer = timerService.createTimer
                          (intervalDuration, "MyTimer");
 }

 @Timeout public void myTimeout(Timer timer) {
   System.out.println("TimerSessionBean: myTimeout ");
 }

 public void cancelTimers(){
   Collection<Timer> timers = timerService.getTimers();
   for(Timer timer: timers) {
     timer.cancel();
   }
 }
}

(2)　EJBContextを利用した場合の実装例（TimedObjectインタフェースを実装）

EJBContextのサブクラスであるSessionContextを利用して，TimerServiceオブジェクトを取得する例を示します。この例では，TimedObjectインタフェースをインプリメントして実装しています。

public class TimerSessionBean implements SessionBean, TimedObject{
 private SessionContext context;

 public void createMyTimer(long intervalDuration) {
   System.out.println("TimerSessionBean: start createTimer ");
   TimerService timerService = context.getTimerService();
   Timer timer = timerService.createTimer
                            (intervalDuration, "MyTimer");
 }

 public void ejbTimeout(Timer timer) {
   System.out.println("TimerSessionBean: ejbTimeout ");
 }

 public void setSessionContext(SessionContext sc) {
   context = sc;
 }
}

(3)　lookupを利用した場合の実装例（TimedObjectインタフェースを実装）

JNDIを使用して，TimerServiceオブジェクトを取得する例を示します。この例では，TimedObjectインタフェースをインプリメントして実装しています。

public class TimerSessionBean implements SessionBean, TimedObject{
 private SessionContext context;

 public void createMyTimer(long intervalDuration) {
   System.out.println("TimerSessionBean: start createTimer ");
   InitialContext context = new InitialContext();
   TimerService timerService =
     (TimerService)context.lookup("java:comp/TimerService");
   Timer timer = timerService.createTimer
                            (intervalDuration, "MyTimer");
 }

 public void ejbTimeout(Timer timer){
   System.out.println("TimerSessionBean: ejbTimeout ");
 }
}

(4)　Timer Service実装時の注意事項

Timer Serviceを実装するときの注意事項を示します。

(a)　createTimerメソッドの引数infoの指定

TimerオブジェクトのgetInfoメソッドは，TimerServiceオブジェクトのcreateTimerメソッドで引数infoに指定されたオブジェクト自体を戻り値とします。そのため，getInfoメソッドの戻り値がcreateTimerメソッド実行時のオブジェクトと異なる状態である場合があり，トラブルが生じやすくなっています。

これを防ぐために，createTimerメソッドで引数infoに指定するオブジェクトはStringやIntegerなどの不変オブジェクトにする，または引数infoに指定したオブジェクトの状態を変更しないことを推奨します。変更した場合には，getInfoメソッドの戻り値は変更後のオブジェクトになります。

(b)　DDおよび属性ファイルでのタイムアウトメソッド指定

DDや属性ファイルで<method>タグにタイムアウトメソッドを指定する場合は，次のどちらかとしてください。

<method>タグ直下に<method-intf>タグの定義を追加しない。

<method-intf>タグの要素を空にする。

(c)　Timer Serviceオブジェクトをサポートしていない種別のBeanからTimer Serviceオブジェクトを取得しようとした場合の動作

Timer Serviceをサポートしない取得手段を次の表に示します。Timer Serviceをサポートしない種別のBeanやサーブレットからTimerServiceオブジェクトを取得しようとした場合，手段によって次のような動作をします。

表5-23　Timer Serviceオブジェクトをサポートしていない種別のBeanからTimer Serviceオブジェクトを取得しようとした場合の動作

TimerServiceオブジェクトの取得手段 | 動作
EJBContext#getTimerService | IllegalStateException例外をスローします。
JNDIのルックアップ | NamingException例外をスローします。
DI | デプロイに失敗します。

Timer Serviceをサポートしている種別のBeanは，タイムアウトメソッドを実装しているかどうかに関係なく，TimerServiceオブジェクトを取得できます。

(d)　TimerServiceが提供するAPIの動作仕様

TimerServiceが提供するAPIを呼び出したときの動作のうち，EJB仕様書で明確に示されていない動作仕様があります。ここでは，javax.ejb.TimerServiceおよびjavax.ejb.TimerのCosminexusでの動作仕様を示します。

javax.ejb.TimerService
javax.ejb.TimerServiceのメソッドを呼び出したBeanがタイムアウトメソッドを実装している場合，およびタイムアウトメソッドを実装していないときの動作を，次の表に示します。

表5-24　Beanからjavax.ejb.TimerServiceのAPIを利用したときの動作

タイムアウトメソッドの実装 | javax.ejb.TimerServiceのメソッドの種類
createTimer | getTimers
実装している場合※ | EJBタイマ生成処理を実行します。 | EJBタイマのコレクションを返します。
実装していない場合 | IllegalStateException例外をスローします。 | 空のコレクションを返します。

注※

タイムアウトメソッドを実装している場合は，EJBの仕様どおりに動作します。

javax.ejb.TimerのAPI
タイムアウトメソッドが実行している場合，および実行していない場合に，javax.ejb.Timerに対してメソッドを呼び出したときの動作を，次の表に示します。

表5-25　javax.ejb.TimerのAPIを利用したときの動作

タイムアウトメソッドの実行 | javax.ejb.Timerのメソッドの種類
cancel | getHandle, getInfo | getNextTimeout | getTimeRemaining
実行していない場合※ | 「5.10.4　EJBタイマとコールバックの動作についての注意事項」を参照してください。 | 仕様どおりに動作します。 | 次のタイムアウトが起こる時刻を返します。 | 次のタイムアウトまでの時間を返します。
実行している場合 | 実行中のタイムアウトの開始予定時刻として登録されていた時刻を返します。 | 0を返します。

注※

タイムアウトメソッドを実行していない場合は，EJBの仕様どおりに動作します。

参考

Cosminexusでは，Timer Serviceのサンプルプログラムを提供しています。サンプルプログラムの概要および実行方法については，マニュアル「Cosminexus　システム構築ガイド」のEnterprise Bean（Timer Service）のサンプルプログラムについての説明を参照してください。

5.11　EJBのリモートインタフェースの呼び出し

ここでは，EJBのリモートインタフェースの呼び出しで使用できる機能について説明します。

＜この節の構成＞

5.11.1　EJBのリモートインタフェースでのローカル呼び出しの最適化

5.11.2　EJBのリモートインタフェースの値の参照渡し

5.11.3　EJBのリモートインタフェースの通信障害発生時の動作

5.11.1　EJBのリモートインタフェースでのローカル呼び出しの最適化

ここでは，EJBのリモートインタフェースでのローカル呼び出しの最適化について説明します。

＜この項の構成＞

(1)　ローカル呼び出しを最適化する範囲と動作

(2)　注意事項

(1)　ローカル呼び出しを最適化する範囲と動作

EJBのリモートインタフェースに定義されるメソッドの呼び出しは，RMI-IIOPで行われますが，この呼び出しについてローカル呼び出し最適化を適用できます。

なお，EJBのローカルインタフェースに定義されるメソッドの呼び出しについては，RMI-IIOPを利用しない，通常のJavaのメソッド呼び出しとなるため，この機能は適用外となります。

リモートインタフェースでのローカル呼び出しの最適化では，ローカル呼び出しを最適化する範囲を選択できます。最適化する範囲は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

次に，ローカル呼び出し最適化機能の範囲および動作と，J2EEサーバのプロパティ（usrconf.properties）のキーの指定値の対応を次の表に示します。

表5-26　ローカル呼び出し最適化機能の範囲と動作

項目 | ejbserver.rmi.localinvocation.scopeキー※の値
all | app | none
ローカル呼び出し最適化の範囲 | 同一J2EEサーバ内となります。 | 同一アプリケーション内となります。 | 範囲はありません。
スレッド構成 | CallerとCalleeは常に同一スレッドとなります。 | 同一アプリケーション内でだけCallerとCalleeは同一スレッドとなります。 | CallerとCalleeは常に別スレッドとなります。
クラスローダ構成 | EJBはコンテナクラスローダ（J2EEサーバ単位）でロードされます。 | EJBはアプリケーションクラスローダ（アプリケーション単位）でロードされます。
ローカルトランザクション | J2EEサーバ内で利用できます。 | 同一アプリケーション内で利用できます。 | 同一J2EEコンポーネント内で利用できます。

注※　usrconf.propertiesに指定するキーです。

(2)　注意事項

同一アプリケーション内での処理で，EJBのリモートインタフェースのローカル呼び出し最適化を適用する場合（usrconf.propertiesに「ejbserver.rmi.localinvocation.scope=app」を指定する場合），次のプロバイダURLには同じホストを指定してください。

J2EEサーバで使用するプロバイダURLのホスト

J2EEアプリケーションから使用するプロバイダURLホスト

ホストの指定が異なると，ローカル呼び出しの最適化が行われません。
また，同じホストを指定している場合でも，ホスト名に指定した文字列が異なると，ローカル呼び出しの最適化は行われません。例えば，大文字と小文字の違いや，IPアドレス指定とホスト名指定の違いなどがあると，ローカル呼び出しの最適化は行われません。

J2EEサーバが使用するプロバイダURLは次の優先順位で決定されます。

ejbserver.naming.startupMode=inprocessの場合

vbroker.se.iiop_tp.hostプロパティの値

InetAddress.getLocalHost().getHostName()の値

ejbserver.naming.startupMode=automaticの場合

InetAddress.getLocalHost().getHostName()の値

ejbserver.naming.startupMode=manualの場合

ejbserver.naming.hostプロパティの値

InetAddress.getLocalHost().getHostName()の値

J2EEアプリケーションから使用するプロバイダURLは次の優先順位で決定されます。

ネーミング切り替え機能使用時にlookupに渡す引数部分

InitialContext生成時に指定するjava.naming.provider.urlプロパティ

J2EEサーバが使用するプロバイダURL

5.11.2　EJBのリモートインタフェースの値の参照渡し

通常，リモートインタフェースを持つEJBメソッドを呼び出すとき，引数や戻り値をコピーして値を渡しますが（pass by value），引数や戻り値を参照で返すこともできます（pass by reference）。値を参照で渡す場合は，値をコピーして渡す場合より，負荷の軽減が図れます。

ただし，値を参照で渡す場合は，引数や戻り値を直接参照するため，引数および戻り値の変更や，参照渡しをするクライアントとアプリケーションの配置には注意が必要です。

java.io.Serializableインタフェースを実装したオブジェクトを，メソッドの引数や戻り値に定義している場合，EJBのリモートインタフェースの値の参照渡しを適用することで，負荷の軽減を期待できます。オブジェクトの数やサイズが大きければより効果を期待できます。

設定方法には次の二つがあります。どちらか一つの方法で設定していれば，値の参照渡しが有効になります。

EJB単位で設定する方法
EJB単位で機能の有効/無効を，Session BeanまたはEntity Beanの属性として定義します。

J2EEサーバ単位で設定する方法
J2EEサーバ単位で機能の有効/無効を，J2EEサーバのプロパティとして，一括して定義します。

5.11.3　EJBのリモートインタフェースの通信障害発生時の動作

EJBクライアントからリモートインタフェースとして定義されたEJBメソッドが呼び出しを実施している際に通信障害が発生したときのクライアント側の動作を次のどちらかから選択できます。

コネクションを再接続して，リクエストを再送信する

コネクションの再接続も，リクエストの再送信もしない

なお，この機能を使用するための設定は，J2EEサーバ，WebコンテナサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の次の説明を参照してください。

J2EEサーバの動作設定のカスタマイズ

Webコンテナサーバの動作設定のカスタマイズ

EJBクライアントアプリケーションのプロパティの設定

なお，EJBクライアントアプリケーションの場合は，API（java.lang.SystemクラスのsetPropertyメソッドなど）で設定することもできます。java.lang.System.setPropertyメソッドで定義する場合は，EJBクライアントアプリケーションのプロセス起動後，最初にEnterprise Beanのメソッドを呼び出す前に定義してください。

＜この項の構成＞

(1)　設定が有効になる通信

(2)　推奨する設定

(3)　注意事項

(1)　設定が有効になる通信

通信障害発生時の動作は，リモートインタフェースとして定義されたEJBメソッドの呼び出しで通信障害が起きた場合に有効になります。EJBメソッドの呼び出しとは，次の呼び出しを指します。

WebアプリケーションからのEJBの呼び出し

EJBクライアントからのEJBの呼び出し

EJBからのEJBの呼び出し

設定が有効となる通信を次の図に示します。

図5-28　設定が有効になる通信

なお，次の場合は無効になるので注意してください。

ローカルインタフェースとして定義されたEJBメソッドの呼び出し

ローカル呼び出し最適化が有効となる範囲での，リモートインタフェースとして定義されたEJBメソッドの呼び出し

ネーミングサービスの呼び出し

(2)　推奨する設定

システムの形態によって，次のように設定することをお勧めします。

検索および参照系のシステムの場合

コネクションを再接続して，リクエストを再送信する設定にすることをお勧めします。これによって，リクエストを失敗させることなく，結果を取得できるようになります。

更新系のシステムの場合

コネクションの再接続も，リクエストの再送信もしない設定にすることをお勧めします。更新系のシステムの場合，コネクションの再接続およびリクエストの再送信ありの設定をすると，リクエストの二重送信をするおそれがあります。

(3)　注意事項

システムプロパティのejbserver.container.rebindpolicyキーで"NO_RECONNECT"（再接続なし／再送なし）を選択した場合，通信障害によってコネクションが切断されると，再接続が抑止されているため該当するオブジェクトリファレンスは再利用できなくなります。このため，EJBクライアントでは，次回Enterprise Beanのメソッド呼び出しをする場合には，EJBホームオブジェクトのときはlookupメソッド，EJBオブジェクトのときはcreateメソッドを再実行したあと，メソッド呼び出しを実行してください。なお，Enterprise Beanのメソッド呼び出し中にコネクションが切断された場合，メソッドは次のどちらかの例外を送出します。

java.rmi.RemoteException
detailフィールドがorg.omg.CORBA.REBINDのインスタンス

java.rmi.MarshalException
detailフィールドがorg.omg.CORBA.COMM_FAILUREのインスタンス

これらの例外をキャッチするクライアントのコーディング例を次に示します。

try {
    //JNDI.lookup()
    //EJBHome.create()
    //EJBObject.invoke()
   } catch (java.rmi.MarshalException e) {
     if (e.detail instanceof org.omg.CORBA.COMM_FAILURE) {
       //通信障害に対応する処理
     }
   } catch (java.rmi.RemoteException e) {
     if (e.detail instanceof org.omg.CORBA.REBIND) {
       //通信障害に対応する処理
     }
   }

5.12　セキュリティ管理

J2EEサービスは，EJBコンテナとWebコンテナで構成されるJ2EEコンテナの部品機能として利用されます。J2EEサービスでは，基本機能として，セキュリティ管理の機能を提供しています。

セキュリティ管理では，次の機能を使用できます。

セキュリティアイデンティティを使用した認証

EJBコンテナの通信ポートとIPアドレスの固定

＜この節の構成＞

5.12.1　セキュリティアイデンティティを使用した認証

5.12.2　EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション）

5.12.1　セキュリティアイデンティティを使用した認証

セキュリティ管理機能を使用して，WebコンテナやEJBコンテナへのアクセス時のユーザ認証を実現できます。認証には，ユーザおよびパスワードを使用します。

セキュリティ管理機能での認証に成功した場合は，セキュリティアイデンティティという認証情報が作成され，WebコンテナやEJBコンテナに伝達されます。なお，認証に失敗した場合は例外が発生します。

認証処理でのセキュリティアイデンティティの流れを次の図に示します。

図5-29　認証処理でのセキュリティアイデンティティの流れ

また，セキュリティ管理では，中間コンポーネントで指定したセキュリティアイデンティティを伝達するRun as機能も使用できます。

Run as機能とは，Enterprise Beanを呼び出す中間コンポーネントで，クライアントでログインしたセキュリティアイデンティティと異なるセキュリティアイデンティティを指定すると，指定したセキュリティアイデンティティでEnterprise Beanの呼び出しができる機能です。Run as機能について次の図に示します。

図5-30　Run as機能

なお，Cosminexusのセキュリティ管理機能では，コンポーネントへアクセスするときのメッセージを暗号化する機能，メッセージに署名を付ける機能，証明書による認証機能はサポートしていません。

5.12.2　EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション）

J2EEサーバ経由でCosminexus TPBrokerのオプションを定義することで，EJBコンテナの通信ポート，およびIPアドレスを固定して運用できます。使用するポートを最小限にしてシステムのセキュリティを高める場合は，ポート固定の設定を強く推奨します。Cosminexus TPBrokerのオプションの詳細については，マニュアル「TPBroker　ユーザーズガイド」を参照してください。また，EJBコンテナの通信ポートおよびIPアドレスを固定するためのCosminexus TPBrokerのオプションは，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　通信ポートの固定

(2)　IPアドレスの固定

(1)　通信ポートの固定

EJBコンテナの通信ポートは，デフォルトではCosminexus TPBrokerによってランダムな値が割り当てられています。

これに対して，Cosminexus TPBrokerのオプションとして任意の値を指定して，J2EEサーバ単位で通信ポートを固定できます。ポート番号については，ほかのプログラムなどと重複しないようにしてください。

(2)　IPアドレスの固定

EJBコンテナのIPアドレスは，デフォルトではCosminexus TPBrokerによって実行環境のマシンのシステムから取得して割り当てられています。

これに対して，Cosminexus TPBrokerのオプションとして任意の値を指定して，J2EEサーバ単位でIPアドレスを固定できます。

5.13　Enterprise Beanの実装

この節ではEnterprise Beanを実装するときの注意事項について説明します。

＜この節の構成＞

5.13.1　Enterprise Bean共通の注意事項

5.13.2　Stateless Session Bean実装時の注意事項

5.13.3　Stateful Session Bean実装時の注意事項

5.13.4　Entity Bean（BMP）実装時の注意事項

5.13.5　Entity Bean（CMP）実装時の注意事項

5.13.6　Message-driven Bean実装時の注意事項

5.13.7　アノテーション使用時の注意事項（Enterprise Bean）

5.13.1　Enterprise Bean共通の注意事項

Cosminexus上で動作するアプリケーションのプログラムとして，Enterprise Beanを実装するときの共通の注意事項を示します。

＜この項の構成＞

(1)　Enterprise Beanおよび関連するクラスの命名規則

(2)　リソースのコネクションの取得と解放

(3)　ローカルインタフェースとリモートインタフェースの使い分け

(4)　ローカル呼び出し最適化機能の利用について

(5)　ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法

(6)　ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法

(7)　クラスローダの取得に関する注意

(8)　URLConnectionクラス使用時の注意

(9)　ネイティブライブラリのロードに関する注意

(10)　Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて

(11)　Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について

(12)　javax.ejb.EJBContextインタフェースメソッドについての注意事項

(13)　Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて

(14)　EJBの仕様に関する注意

(15)　Unicodeの補助文字の送受信に関する注意

(1)　Enterprise Beanおよび関連するクラスの命名規則

Enterprise Beanクラス，ホームインタフェース，コンポーネントインタフェース，ビジネスインタフェース，インターセプタクラス，およびそれらで使用するクラスを実装する場合は，次に示す命名規則に従ってください。

Enterprise Beanおよび関連するクラスのクラス名と同じ名前で始まるパッケージに，それらのクラスを配置しないでください。

「Wrappers.」で始まるパッケージ名は使用できません。

Enterprise Beanクラス，ホームインタフェース，コンポーネントインタフェース，およびビジネスインタフェースの名称では，英数字および記号を使用します。アンダースコア（_）で始まるメソッド名，およびメンバ変数名は使用できません。

Entity BeanのCMPではアンダースコア（_）で始まるCMPフィールド名，およびCMRフィールド名は指定できません。

大文字，小文字の違いだけのパッケージ名称，およびクラス名称は利用できません。RMI-IIOPでは大文字，小文字が区別されないため，Enterprise Beanに正常にアクセスできなくなるおそれがあります。

JARファイル中にあるホームインタフェースなど，java.rmi.Remoteを実装したクラスがあると，スタブは作業ディレクトリ内に生成されます。作業ディレクトリのパス長がプラットフォームの上限に達しないようにjava.rmi.Remoteを実装したクラスのパッケージ名やクラス名を指定してください。作業ディレクトリのパス長の見積もりについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

EJB-JARファイルが別の場合でも，同じアプリケーション内では，クラスが重複しないようにしてください。

Enterprise Beanのリモートインタフェース，リモートコンポーネントインタフェースのクラス名は，VisiBrokerの予約名を使用しないでください。なお，VisiBrokerの予約名には，「Helper」,「Holder」,「Package」,「Operations」,「POA」,および「POATie」があります。VisiBrokerの予約名については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス」を参照してください。

デフォルトパッケージにEnterprise Beanクラスを作成する場合，次に示す文字列で終わるクラスをデフォルトパッケージに作成しないでください。

_LocalHomeImpl

_LocalComponentImpl

_RemoteHomeImpl

_RemoteComponentImpl

_LocalBIProxyImpl

_LocalBIClientSideProxyImpl

_RemoteBIProxyInterface

_RemoteBIProxyImpl

_RemoteBIClientSideProxyImpl

_CallbackWrapperImpl

_InvocationContextImpl

(2)　リソースのコネクションの取得と解放

Enterprise BeanでJDBC，JMSなどのJ2EEリソースのコネクションを使用する場合，Connectionクラスのcloseメソッドでコネクションを解放してください。コネクションを解放しないと，予期しないうちにリソースを消費し尽くしてしまいます。このような状況を避けるため，次のような点を考慮して実装してください。

コネクションをEnterprise Beanクラスのメンバ変数に保持しないようにします。
コネクションをメンバ変数に保持していると，Beanの実行に関係なくコネクションが使用状態のままになり，パフォーマンスが低下します。そのため，SQL実行時にコネクションの取得と解放をするようにしてください。

コネクションプールを設定します。
コネクションプールを設定すると，物理的コネクションを再利用するためコネクション取得のオーバーヘッドを削減できます。また，JTAのトランザクション配下で実行する場合はコネクションプールの設定をする必要があります。

(3)　ローカルインタフェースとリモートインタフェースの使い分け

EJB 2.0仕様で追加されたローカルインタフェースを利用すると，RMI-IIOP通信処理のオーバーヘッドを削減できますが，ローカルインタフェースだけを持つEnterprise Beanはリモート呼び出しができません。また，ローカルインタフェースを使用する場合，メソッドの引数，戻り値がpass by referenceで動作できる必要があります。次に示すローカルインタフェースの使用条件を参考に，ローカルインタフェースとリモートインタフェースを使い分けてください。

ローカルインタフェースの使用が推奨される場合

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）が同じJ2EEアプリケーションに含まれている場合，ローカルインタフェースの使用が推奨されます。

ローカルインタフェースの使用が必須の場合

CMP2.xのCMRは，ローカルインタフェースの使用が前提のため，ローカルインタフェースを使用してください。

ローカルインタフェースが使用できない場合

次の場合は，ローカルインタフェースが使用できません。

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）が別のJ2EEアプリケーションに含まれている場合。

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）がほかのJ2EEサーバ（別のJavaVM）で実行される場合。

EJB 1.1ですでに実装されている場合。

(4)　ローカル呼び出し最適化機能の利用について

リモートインタフェース使用時にローカル呼び出し最適化機能を利用すると，RMI-IIOP通信処理のオーバーヘッドを削減できます。ローカル呼び出しは，メソッド呼び出しとほぼ同等の呼び出し形式になりますが，メソッドの引数，戻り値はpass by valueで処理されます。

(5)　ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法

同一J2EEサーバ内にある場合と，ほかのJ2EEサーバ内にある場合に分けて，ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースで呼び出す方法を示します。

(a)　同一J2EEサーバ内のほかのアプリケーションで動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのリモートホームインタフェース，リモートインタフェースおよび各インタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルに次に示すプロパティを指定します。
usrconf.propertiesのejbserver.deploy.stub.generation.scopeキーに「app」を指定します。
usrconf.propertiesについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

J2EEサーバ用ユーザ定義ファイルに次に示すプロパティを指定します。
usrconf.propertiesのejbserver.rmi.localinvocation.scopeキーに「all」または「none」を指定します。
usrconf.propertiesについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

ネーミングの切り替え機能を使用してcorbanameで始まる，ほかのJ2EEアプリケーション内のEnterprise Beanのルックアップ名を指定します。
指定方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」の，ほかのEnterprise Beanのリファレンス定義の内容を参照してください。指定例を次に示します。

corbaname::NamingHost:900#HITACHI_EJB/SERVERS/MyServer/EJB/MyApplication/MyBean

(b)　ほかのJ2EEサーバ上で動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのリモートホームインタフェース，リモートインタフェースおよび各インタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルに次に示すプロパティを指定します。
usrconf.propertiesのejbserver.deploy.stub.generation.scopeキーに「app」を指定します。

ネーミングの切り替え機能を使用してcorbanameで始まるほかのJ2EEアプリケーション内のEnterprise Beanのルックアップ名を指定します。
指定方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」の，ほかのEnterprise Beanのリファレンス定義の内容を参照してください。指定例を次に示します。

corbaname::NamingHost:900#HITACHI_EJB/SERVERS/MyServer/EJB/MyApplication/MyBean

(6)　ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法

同一J2EEサーバ内にある場合と，ほかのJ2EEサーバ内にある場合に分けて，ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースで呼び出す方法を示します。

(a)　同一J2EEサーバ内のほかのアプリケーションで動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルのejbserver.rmi.localinvocation.scopeキーに「all」または，「none」を指定します。

「none」の場合は，呼び出し先のEnterprise Beanに対して，cjgetstubsjarコマンドでスタブを取得し，呼び出し元のEARファイルに含めます。※
Enterprise BeanはEJB参照を使用しないでルックアップします。ルックアップ名を指定する形式を示します。
「HITACHI_EJB/SERVERS/<サーバ名> /EJBBI/<J2EE APP名>/<Enterprise Bean名>」
<サーバ名>：J2EEサーバのサーバ名称
<J2EE APP名>：J2EEアプリケーションのルックアップ名称
<Enterprise Bean名>：Enterprise Beanのルックアップ名称

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用すればスタブを含める必要はありませんが，ダイナミッククラスローディング機能は性能上推奨しません。

(b)　ほかのJ2EEサーバ上で動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めます。

呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドでスタブを取得し，呼び出し元のEARファイルに含めます。※
Enterprise BeanはEJB参照を使用しないでルックアップします。ルックアップ名を指定する形式を示します。
「HITACHI_EJB/SERVERS/<サーバ名> /EJBBI/<J2EE APP名>/<Enterprise Bean名>」
<サーバ名>：J2EEサーバのサーバ名称
<J2EE APP名>：J2EEアプリケーションのルックアップ名称
<Enterprise Bean名>：Enterprise Beanのルックアップ名称

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用すればスタブを含める必要はありませんが，ダイナミッククラスローディング機能は性能上推奨しません。

(7)　クラスローダの取得に関する注意

J2EEアプリケーション内のコードからCosminexus Component Containerのクラスローダを取得して，次に示すAPIを使用する場合に，java.net.JarURLConnectionクラスが使用されます。

getResource(String).openConnection().getInputStream();

getResource(String).openStream()

上記メソッドの延長でjava.net.JarURLConnectionクラスのopenConnectionメソッドが呼び出され，該当するURLに指定されたJARファイルがオープンされます。JARファイルに対する操作が必要でjava.net.JarURLConnectionクラスのopenConnectionメソッドを使用する場合には，該当するJARファイルに対してcloseメソッドを必ず呼び出すようにしてください。明示的にcloseメソッドを呼ばないかぎり，オープンされたままになり削除できません。また，上記メソッドはJ2EEアプリケーション内で使用しないでください。

(8)　URLConnectionクラス使用時の注意

java.net.URLConnectionクラスはsetUseCaches(boolean)メソッドを使用して，指定されたURLに対してコネクションを取得するときにキャッシュの情報を利用するかどうかを指定できます。URLConnectionクラスに対してsetUseCaches(false)メソッドを指定した場合に，コネクションごとに対象のオブジェクトが生成されます。J2EEアプリケーション内のコードから使用する場合には，J2EEサーバのJavaVMがメモリリークするおそれがあります。

(9)　ネイティブライブラリのロードに関する注意

System.loadLibraryメソッドを使用して，Enterprise Beanからネイティブライブラリをロードしないでください。Enterprise Beanでネイティブライブラリをロードすると，JNI仕様の制約によって，java.lang.UnsatisfiedLinkErrorが発生することがあります。ネイティブライブラリのロードが必要な場合は，System.loadLibraryメソッドを呼び出すコンテナ拡張ライブラリを作成し，Enterprise Beanからコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については，「10.1　コンテナ拡張ライブラリの利用」を参照してください。

(10)　Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて

Entity Bean（CMP，BMP）を使用する場合，同一プライマリキーのEntity Beanに対するアクセスには排他が掛かります。同時に同一のプライマリキーのEntity Beanに対してアクセスし，処理時間が掛かる場合は，排他待ちが行われます。排他待ちの結果，排他を取得できなかった場合は，タイムアウト（デフォルト45秒）で例外IllegalStateExceptionが発生します。この場合，J2EEサーバ用ユーザ定義ファイル（/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties）のejbserver.server.mutex.invocation.timeoutキーにタイムアウト時間を指定してタイムアウトを発生させないようにすることができます。ejbserver.server.mutex.invocation.timeoutキーについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(11)　Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について

Application Serverでは，Entity Beanのトランザクション処理にデータベースのトランザクション機能を使用しています。データベースへのアクセスの順番，データの排他にかかわるテーブルの設定，データベースのシステムの設定，および呼び出すSQL文によっては，デッドロックが発生する場合があります。詳細は使用しているデータベースのマニュアルを参照してください。

(12)　javax.ejb.EJBContextインタフェースメソッドについての注意事項

javax.ejb.EJBContextインタフェースのgetUserTransactionメソッド，getRollbackOnlyメソッド，setRollbackOnlyメソッドについては，Enterprise Beanのトランザクション管理モデルによっては発行できません。また，Enterprise Beanのメソッドのうち，EJB仕様で"Unspecified transaction"で動作するとされるものでは，発行できません。発行できない場合，EJBコンテナはjava.lang.IllegalStateExceptionを送出します。各メソッドの発行可否についてそれぞれの表に示します。

表5-27　トランザクション管理モデル別の発行可否

javax.ejb.EJBContextメソッド | 発行可否
BMT | CMT
getUserTransaction | ○ | ×
getRollbackOnly | × | ○
setRollbackOnly | × | ○

（凡例）○：発行できる　×：発行できない

表5-28　EJBのメソッド別の発行可否

Bean種別 | メソッド | 発行可否
SessionBean | コンストラクタ | ×
setSessionContext | ×
ejbCreate | ×
ejbRemove | ×
ejbPassivate | ×
ejbActivate | ×
ビジネスメソッド | ○
afterBegin | ○
beforeCompletion | ○
afterCompletion | ×
EntityBean | コンストラクタ | ○
setEntityContext | ×
unsetEntityContext | ×
ejbCreate | ○
ejbPostCreate | ○
ejbRemove | ○
ejbHome | ○
ejbPassivate | ×
ejbActivate | ×
ejbLoad | ○
ejbStore | ○
ビジネスメソッド | ○
Message-driven Bean | コンストラクタ | ×
ejbCreate | ×
onMessage | ○
メッセージリスナのメソッド | ○
ejbRemove | ×

（凡例）○：発行できる　×：発行できない

(13)　Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて

Entity Bean属性ファイルの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，次のように動作します。

Entity Bean（CMP）の場合
デプロイ時にエラーメッセージKDJE42039-Eが出力され，デプロイ処理はエラーで終了します。

Entity Bean（BMP）の場合
クラスを指定したときと同様，デプロイおよび実行できます。

(14)　EJBの仕様に関する注意

EJB仕様に従っていない記述をした場合，エラー（例外）が発生することがあります。以前のバージョンでエラーが発生しなくても，バージョンアップをしたときにエラーになることがあります。エラーが発生した場合は，エラーの内容を確認し，EJB仕様に従って変更してください。

(15)　Unicodeの補助文字の送受信に関する注意

構成ソフトウェアにCosminexus TPBrokerを含むApplication Serverでは，RMI-IIOP通信によるEnterprise Beanのメソッド呼び出しで，Unicodeの補助文字を送受信できます。この場合，送信側と受信側のApplication Serverのバージョンによって，Unicodeの補助文字の送受信時の動作が異なります。Application Serverのバージョンの組み合わせと，Unicodeの補助文字送受信時の動作を次の表に示します。

表5-29　Application Serverのバージョンの組み合わせと，Unicodeの補助文字送受信時の動作

送信側のApplication Serverのバージョン | 受信側のApplication Serverのバージョン
07-50以降 | 07-50より前
07-50以降 | ○ | ×
07-50より前 | × | ×

（凡例）

○：Unicodeの補助文字を送受信できる

×：Unicodeの補助文字を送受信できない

Unicodeの補助文字送受信ができないバージョンの場合，RMI-IIOP通信によるUnicodeの補助文字送受信時に，java.rmi.RemoteExceptionの例外またはjava.rmi.MarshalExceptionの例外がスローされます。

なお，Unicodeの補助文字を送受信した場合の動作を，07-50より前と同じ動作に設定できます。07-50より前と同じ動作を設定したい場合は，usrconf.properties（J2EEサーバ用ユーザプロパティファイル，およびJavaアプリケーション用ユーザプロパティファイル）で，vbroker.orb.htc.surrogateCheckOffキーに「false」を設定してください。キーの詳細については，マニュアル「TPBroker　ユーザーズガイド」を参照してください。

5.13.2　Stateless Session Bean実装時の注意事項

Stateless Session Beanを実装するときの注意事項を示します。

＜この項の構成＞

(1)　removeメソッドによるリファレンスの解放

(2)　ejbCreateメソッドおよび@PostConstructアノテーションを指定したメソッドでのリソースマネジャへのアクセスについて

(3)　Beanクラスの共有についての注意

(4)　ejbRemoveメソッドまたは@PreDestroyアノテーションを指定したメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

(1)　removeメソッドによるリファレンスの解放

ホームインタフェースを使用してStateless Session Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Session Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出してリファレンスを解放してください。リファレンスを解放しない場合，J2EEサーバ上のメモリを消費したままの状態になります。

また，removeメソッド呼び出しを不要にするオプションを指定することで，Stateless Session BeanのEJBオブジェクトに対する，removeメソッドの呼び出しが不要になります。このオプションを有効にすると，removeメソッド呼び出しのあとに，ビジネスメソッドの呼び出しができます。

このオプションを無効にしている場合は，removeメソッドを呼び出す必要があります。また，removeメソッド呼び出しのあとにビジネスメソッドを呼び出した場合，java.rmi.NoSuchObjectException例外が呼び出し元に返ります。

removeメソッド呼び出しを不要にするオプションは，usrconf.propertiesのejbserver.rmi.stateless.unique_id.enabledキーに指定し，J2EEサーバ単位に定義します。キーの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。また，構成ソフトウェアにCosminexus TPBrokerを含まないuCosminexus Developer Standardでは，プロパティの設定に関係なく常にこのオプションは有効になります。

(2)　ejbCreateメソッドおよび@PostConstructアノテーションを指定したメソッドでのリソースマネジャへのアクセスについて

EJB仕様では，ejbCreateメソッドまたは@PostConstructアノテーションを指定したメソッドで，リソースマネジャへアクセスすることは許されていません。

(3)　Beanクラスの共有についての注意

同じSession Beanを同じJ2EEアプリケーション内でStateful Session Bean，およびStateless Session Beanとして同時に利用しないでください。

(4)　ejbRemoveメソッドまたは@PreDestroyアノテーションを指定したメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

Stateless Session BeanのejbRemoveメソッドまたは@PreDestroyアノテーションを指定したメソッドでは，javax.transaction.UserTransactionのbeginメソッドを呼び出せる場合がありますが，EJBの仕様上，呼び出して使用することはできません。呼び出さないようにしてください。

5.13.3　Stateful Session Bean実装時の注意事項

Stateful Session Beanを実装するときの注意事項を示します。

＜この項の構成＞

(1)　removeメソッドまたは@Removeアノテーションを指定したメソッドによるEJBインスタンスの削除とリファレンスの解放

(2)　Beanクラスの共有についての注意

(3)　SessionSynchronizationのインスタンスの破棄についての注意

(4)　ベーシックモードでのSessionSynchronizationのメソッド呼び出しについての注意

(5)　setSessionContextメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

(6)　beforeCompletionメソッドからのEnterprise Beanの呼び出しについて

(7)　afterCompletionメソッドからのEnterprise Beanの呼び出しについて

(1)　removeメソッドまたは@Removeアノテーションを指定したメソッドによるEJBインスタンスの削除とリファレンスの解放

ホームインタフェースを使用してStateful Session Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Session Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出して，EJBインスタンスの削除とリファレンスを解放してください。

ビジネスインタフェースを使用してStateful Session Beanを呼び出す場合，ビジネスメソッドの呼び出しが完了したあとに，必ず@Removeアノテーションを指定したメソッドを呼び出して，EJBインスタンスを削除し，リファレンスを解放してください。

EJBインスタンスの削除およびリファレンスの解放をしない場合，J2EEサーバ上のメモリを消費したままの状態になります。

(2)　Beanクラスの共有についての注意

同じSession Beanを同じJ2EEアプリケーション内でStateful Session Bean，およびStateless Session Beanとして同時に利用しないでください。

(3)　SessionSynchronizationのインスタンスの破棄についての注意

SessionSynchronizationのbeforeCompletionメソッドおよびafterCompletionメソッドでシステム例外が発生した場合，EJBコンテナでは該当するSession Beanのインスタンスを破棄しません。

(4)　ベーシックモードでのSessionSynchronizationのメソッド呼び出しについての注意

ベーシックモードで，クライアントでトランザクション開始後にSessionSynchronizationのStateful Session Bean（トランザクション属性はRequiredまたはMandatory）を呼び出して，afterBeginメソッドまたはsetRollbackOnlyメソッドを呼び出すと，クライアントでのコミット時にbeforeCompletionメソッドが呼び出されません。1.4モードのときは，beforeCompletionメソッドが呼び出されます。

(5)　setSessionContextメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

Stateful Session BeanのsetSessionContextメソッドでは，javax.transaction.UserTransactionのbeginメソッドを呼び出せる場合がありますが，EJBの仕様上，呼び出して使用することはできません。呼び出さないようにしてください。

(6)　beforeCompletionメソッドからのEnterprise Beanの呼び出しについて

J2EEサーバモードの動作モードとしてベーシックモードを使用している場合，Stateful Session BeanのbeforeCompletionメソッドからほかのEnterprise Beanは呼び出せません。ほかのEnterprise Beanを呼び出した場合，java.rmi.RemoteException例外が発生します。

(7)　afterCompletionメソッドからのEnterprise Beanの呼び出しについて

Stateful Session BeanのafterCompletionメソッドからほかのEnterprise Beanを呼び出した場合，J2EEサーバモードの動作モードによって次の動作をします。

ベーシックモード：java.rmi.RemoteException例外が発生します。

1.4モード：Enterprise Beanを呼び出せます。

EJBの仕様上，Stateful Session BeanのafterCompletionメソッドからほかのEnterprise Beanを呼び出せないので，呼び出さないようにしてください。

5.13.4　Entity Bean（BMP）実装時の注意事項

Entity Bean（BMP）を実装するときの注意事項を示します。

＜この項の構成＞

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

(2)　プライマリキークラスへのインタフェース指定について

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

EJB 1.1仕様およびEJB 2.0仕様では，setEntityContextメソッドでのリソースマネジャへのアクセスは許されていません。

(2)　プライマリキークラスへのインタフェース指定について

BMP Entity BeanのDDの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，クラスを指定したときと同様に，デプロイおよび実行ができます。

5.13.5　Entity Bean（CMP）実装時の注意事項

Entity Bean（CMP）を実装するときの注意事項を示します。

＜この項の構成＞

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

(2)　ユーザ定義型のCMPフィールドの使用についての注意

(3)　CMRフィールド使用時のトランザクションに関する注意

(4)　CMRのcascade-deleteの使用についての注意

(5)　プライマリキークラスへのインタフェース指定について

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

EJB 1.1仕様およびEJB 2.0仕様では，setEntityContextメソッドでのリソースマネジャへのアクセスは許されていません。

(2)　ユーザ定義型のCMPフィールドの使用についての注意

プライマリキーとして複合プライマリキーを使用する以外で，ユーザ定義型のCMPフィールドを使用できません。

(3)　CMRフィールド使用時のトランザクションに関する注意

Collection型のCMRフィールドやCollection型のCMRフィールドのIteratorを使用する場合，CMRフィールドを取得したときのトランザクションの範囲内で，CMRフィールドやIteratorへアクセスできます。次のコーディング例のcallTeamメソッドでは，CMRフィールドのgetterメソッドであるgetPlayersメソッドと，それに続くIteratorを使用した操作をすべて同一トランザクション内で実行する必要があります（［a］から［b］の間）。

  public void callTeam() {
            ：
    //[a]
    Collection playersInTeam = team.getPlayers();
    Iterator i = playersInTeam.iterator();
    while (i.hasNext()) {
      LocalPlayer p = (LocalPlayer) i.next();
            ：
    }
    //[b]
  }

このコーディング例をトランザクション外で実行した場合は，IllegalStateException例外が発生します。これを避けるために，トランザクション内で実行されるようにCMTなどで設定してください。

(4)　CMRのcascade-deleteの使用についての注意

CMRのcascade-deleteを使用する場合，次の制限があります。

cascade-deleteでEntity Beanをremoveする場合，呼び出し元となるクライアントプログラムは，最初にremoveされるBeanのremoveメソッドのメソッドパーミッションだけでなく，cascade-deleteの対象となるすべてのBeanでの，コンポーネントインタフェースのremoveメソッドのメソッドパーミッションを持つように設定されている必要があります。

cascade-deleteの対象となるすべてのBeanでの，コンポーネントインタフェースのremoveメソッドのトランザクション属性は，Requiredに設定してください。

cascade-deleteを指定している関係が複数のBeanを循環するように設定されている場合，循環した関係にあるすべてのBeanでremoveメソッドの実行は保証されません。

(5)　プライマリキークラスへのインタフェース指定について

CMP Entity BeanのDDの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，デプロイ時にエラーメッセージKDJE42039-Eが出力され，デプロイ処理はエラー終了されます。

5.13.6　Message-driven Bean実装時の注意事項

Message-driven Beanを実装するときの注意事項を示します。

＜この項の構成＞

(1)　Message-driven Beanのトランザクション設定時の注意（Connector 1.0に準拠したリソースアダプタを使用する場合）

(2)　Message-driven Beanのトランザクション設定時の注意（Connector 1.5に準拠したリソースアダプタを使用する場合）

(1)　Message-driven Beanのトランザクション設定時の注意（Connector 1.0に準拠したリソースアダプタを使用する場合）

Message-driven Beanへのメッセージ配信とMessage-driven Bean内のデータベースアクセス処理をトランザクションで同期を取る場合，Message-driven Beanのトランザクション設定はCMTでRequiredに設定します。これによって，トランザクションがロールバックした場合にMessage-driven Beanへメッセージが再配信されます。しかし，トランザクションのロールバックが繰り返されると再配信も繰り返されるため，Message-driven Bean側でjavax.jms.MessageクラスのgetJMSRedeliveredメソッドを使用して再配信を確認するなどの対処が必要になります。CMTのNotSupported設定，またはBMTではいったんMessage-driven Beanでメッセージを受信すると，トランザクションがロールバックしても再配信されなくなります。

(2)　Message-driven Beanのトランザクション設定時の注意（Connector 1.5に準拠したリソースアダプタを使用する場合）

グローバルトランザクションを使用している場合，次の処理の同期は取れません。

Message-driven Beanへのメッセージ配信

Message-driven Bean内でのデータベースアクセス処理

また，Connector 1.5仕様のリソースアダプタからメッセージを受信するJ2EEアプリケーションで，トランザクション管理方法をCMTにしてトランザクション属性をRequiredに設定すると，J2EEアプリケーションの開始に失敗します。

5.13.7　アノテーション使用時の注意事項（Enterprise Bean）

Enterprise Beanでアノテーションを使用する場合の注意事項を示します。

＜この項の構成＞

(1)　アノテーションのサポート範囲

(2)　@RemoteHomeまたは@LocalHomeで指定したホームインタフェースについて

(1)　アノテーションのサポート範囲

Cosminexusでは，Enterprise Beanでアノテーションを使用できます。Cosminexusが対応しているアノテーションについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

(2)　@RemoteHomeまたは@LocalHomeで指定したホームインタフェースについて

Cosminexusでは，@RemoteHomeまたは@LocalHomeで指定したホームインタフェースの，createメソッドの戻り値の型となるインタフェースは，コンポーネントインタフェースと見なされます。ホームインタフェースとビジネスインタフェースの組み合わせでは使用できません。

6.　EJBクライアント

EJBコンテナで動作するEnterprise Beanを呼び出すクライアントを，EJBクライアントといいます。この章では，EJBクライアントで使用できる機能について説明します。

＜この章の構成＞

6.1　EJBクライアントで使用できる機能

6.2　Enterprise Beanの呼び出し

6.3　JNDIによるEJBホームオブジェクトおよびビジネスインタフェースのリファレンスのルックアップ

6.4　EJBクライアントアプリケーションでのトランザクションの実装

6.5　EJBクライアントアプリケーションでのセキュリティの実装

6.6　RMI-IIOPスタブ，インタフェースの取得

6.1　EJBクライアントで使用できる機能

この節では，EJBクライアントで使用できる機能について説明します。

EJBクライアントとは，J2EEサーバ上のEJBコンテナで実行されているEnterprise Beanを呼び出すクライアントプログラムです。

EJBクライアントには，次の種類があります。

EJBクライアントアプリケーション

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーションとは，J2EEサーバ上で実行されるEnterprise Beanを呼び出すクライアントアプリケーションのことです。

EJBクライアントで使用できる機能について，次の表に示します。なお，それぞれの機能の詳細については，参照先の説明を参照してください。

表6-1　EJBクライアントで使用できる機能

分類 | 機能概要 | 機能についての参照先
JNDI | 基本機能 | EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスの検索，取得ができます。 | 6.3※，8.2
拡張機能 | 複数のネーミングサービスとJ2EEサーバで構成されるシステムで，EJBクライアントからのルックアップをラウンドロビンで実行できます。これによって，負荷分散を実現できます。 | 8.4
ネーミングサービスからルックアップしたオブジェクトをメモリ上に保持（キャッシュ）できます。キャッシュの利用によって，ネーミングサービスへのアクセスの性能上のコストを削減できます。 | 8.5
EJB | EJBコンテナで実行されているEnterprise Beanを呼び出せます。 | 5.2，6.2※，6.6※
EJB呼び出し実行時に通信障害が発生した場合に，送信動作を選択できます。 | 5.11.3
トランザクション | EJBクライアントでトランザクションを開始・決着できます。 | 9.3
Security | J2EEサーバで定義されたユーザとパスワードを使用してユーザ認証ができます。EJBクライアントからログインして，セキュリティロールが設定されたEJBのビジネスメソッドを呼び出せます。 | 5.12.1，6.5※
そのほか | EJBクライアントとネーミングサービス間，およびEJBクライアントとJ2EEサーバ間の通信で，通信タイムアウトを設定できます。 | 5.9.4
EJBクライアントの性能解析トレースを出力できます。 | 17.10

注※　アプリケーションの実装方法について説明しています。

EJBクライアントアプリケーションで使用できる拡張機能について，次の表に示します。なお，それぞれの機能の詳細については，参照先の説明を参照してください。なお，EJBクライアントアプリケーションでは，データソース（JDBC）およびコネクタ（Connector）は使用できません。

表6-2　EJBクライアントアプリケーションで使用できる拡張機能

分類
機能概要
機能についての参照先

トランザクション
EJBクライアントアプリケーションでUserTransactionを取得し,トランザクションを開始・決着できます。UserTransactionの取得方法には次の2種類の方法があります。

UserTransactionFactoryクラスを使用する方法

ルックアップを使用する方法

なお，Cosminexusでは，1.の方法を推奨しています。
6.4

そのほか
EJBクライアントのログを出力できます。
マニュアル「Cosminexus　システム運用ガイド」

EJBクライアントアプリケーションをコマンド（cjclstartapコマンド）で起動できます。
マニュアル「Cosminexus　システム構築ガイド」

次の節以降では，EJBクライアントアプリケーションについて説明しています。

6.2　Enterprise Beanの呼び出し

EJBクライアントアプリケーションからEnterprise Beanを呼び出す方法，およびメソッドの呼び出しで通信障害が発生したときの，クライアント側の動作設定について説明します。

＜この節の構成＞

6.2.1　Enterprise Beanを呼び出す方法

6.2.2　EJBクライアントアプリケーションからのEnterprise Bean呼び出しの流れ

6.2.1　Enterprise Beanを呼び出す方法

EJBクライアントアプリケーションからEnterprise Beanを呼び出すには，JNDIを利用します。ここでは，EJBホームオブジェクトのリファレンスをルックアップする場合，およびビジネスインタフェースのリファレンスをルックアップする場合に分けて，Enterprise Beanを呼び出す方法を説明します。

＜この項の構成＞

(1)　EJBホームオブジェクトのリファレンスを検索してEnterprise Beanを呼び出す方法

(2)　ビジネスインタフェースのリファレンスを検索してEnterprise Beanを呼び出す方法

(1)　EJBホームオブジェクトのリファレンスを検索してEnterprise Beanを呼び出す方法

EJBホームオブジェクトのリファレンスをルックアップしてEnterprise Beanを呼び出す方法を，実装例を基に説明します。

(a)　JNDIネーミングコンテキストの生成

EJBホームオブジェクトのリファレンスのルックアップに利用するJNDIネーミングコンテキストを生成します。

javax.naming.Context ctx = new javax.naming.InitialContext();

(b)　EJBホームオブジェクトのリファレンスの検索と取得

生成したJNDIネーミングコンテキストを利用して，EJBホームオブジェクトのリファレンスを取得します。EJBホームオブジェクトのリファレンスを取得するには，自動的にバインドされる名称またはユーザ指定名前空間機能を利用して付与した名称でルックアップします。次の例では，ユーザ指定名前空間を利用してルックアップ，取得しています。ルックアップの方法については，「6.3　JNDIによるEJBホームオブジェクトおよびビジネスインタフェースのリファレンスのルックアップ」を参照してください。

String ejbName = "MySample";
java.lang.Object obj = ctx.lookup(ejbName);
SampleHome sampleHome =
(SampleHome)javax.rmi.PortableRemoteObject.narrow(obj, SampleHome.class);

(c)　Enterprise Beanの生成とメソッドの呼び出し

EJBホームオブジェクトのcreateメソッドによって，Enterprise Beanのインスタンスを生成します。これによって，アプリケーションに必要となるEnterprise Beanのメソッドを呼び出せるようになります。

Sample remoteSample = sampleHome.create(); //Enterprise Beanインスタンスの生成
String result = remoteSample.getData("data"); //ビジネスメソッドの呼び出し

なお，Entity BeanでCollection型が返されるfindメソッドを利用する場合は，コレクションから取り出したオブジェクトに対して，Enterprise Beanのクラスでナロウする必要があります。

Collection c = home.findByXXX(keyValue);
Iterator i=c.iterator();
while (i.hasNext()) {
 Sample remoteSample=(Sample)javax.rmi.PortableRemoteObject.narrow(i.next(), Sample.class);
               //RemoteSampleに対してビジネスメソッドを呼び出します。
}

(2)　ビジネスインタフェースのリファレンスを検索してEnterprise Beanを呼び出す方法

ビジネスインタフェースのリファレンスをルックアップしてEnterprise Beanを呼び出す方法を，実装例を基に説明します。

(a)　InitialContextの生成

ビジネスインタフェースを使用してEnterprise Beanを呼び出すには，最初にInitialContextを生成します。

// InitialContextを生成
InitialContext ctx = new InitialContext();

(b)　ビジネスインタフェースのリファレンスの検索と取得

生成したInitialContextを利用して，ビジネスインタフェースのリファレンスを取得します。ビジネスインタフェースのリファレンスを取得するには，自動的にバインドされる名称またはユーザ指定名前空間機能を利用して付与した名称でルックアップします。自動的にバインドされる名称を使用したビジネスインタフェースのルックアップの方法については，「6.3.1(2)　ビジネスインタフェースの場合」を参照してください。

// ビジネスインタフェースのリファレンスを取得
Sample sample = (Sample)ctx.lookup("HITACHI_EJB/SERVERS/MyServer/EJBBI/SampleApp/Sample");

(c)　メソッドの呼び出し

ビジネスインタフェースのリファレンスを取得したことで，ビジネスメソッドを呼び出せるようになります。

// ビジネスメソッドの呼び出し
String result = sample.getData("data");

6.2.2　EJBクライアントアプリケーションからのEnterprise Bean呼び出しの流れ

EJBホームオブジェクトのリファレンスを検索，取得する場合を例に，Enterprise Beanを呼び出す流れを示します。

図6-1　EJBクライアントアプリケーションからホームインタフェースを利用してEnterprise Beanを呼び出す流れ

EJBクライアントアプリケーションからホームインタフェースを利用してEnterprise Beanを呼び出すには，JNDIを利用してEJBホームオブジェクトのリファレンスを取得することで実現します。したがって，EJBクライアントアプリケーションでJNDIネーミングコンテキストを生成し，EJBホームオブジェクトのリファレンスを検索できるように実装する必要があります。Enterprise Beanの呼び出しの詳細については，「6.2.1　Enterprise Beanを呼び出す方法」を参照してください。また，EJBクライアントアプリケーションは通信手段にRMI-IIOPを利用するため，RMI-IIOPのスタブやインタフェースを参照できるようにしておく必要があります。RMI-IIOPのスタブやインタフェースの取得については，「6.6　RMI-IIOPスタブ，インタフェースの取得」を参照してください。

6.3　JNDIによるEJBホームオブジェクトおよびビジネスインタフェースのリファレンスのルックアップ

EJBホームオブジェクトまたはビジネスインタフェースのリファレンスをネーミングサービスから検索（ルックアップ）して取得するには，次のどちらかの名称を利用します。

自動的にバインドされる名称

ユーザ指定名前空間機能を利用して付与した名称

この節では，それぞれの場合に分けてルックアップ，取得の流れについて説明します。

また，EJBホームオブジェクトへの再接続を設定することで，J2EEサーバが障害などで再起動した場合，再ルックアップしないで，再起動前に取得したEJBホームオブジェクトのリファレンスをそのまま使用できます。再接続を設定する場合の注意事項についても説明します。

＜この節の構成＞

6.3.1　自動的にバインドされる名前でのルックアップ

6.3.2　ユーザ指定名前空間で付与した名前でのルックアップ

6.3.3　EJBホームオブジェクトリファレンスの再利用（EJBホームオブジェクトへの再接続機能）

6.3.1　自動的にバインドされる名前でのルックアップ

自動的にバインドされる名前を利用してルックアップする方法を，EJBホームオブジェクトをルックアップする場合と，ビジネスインタフェースのリファレンスをルックアップする場合に分けて示します。

＜この項の構成＞

(1)　EJBホームオブジェクトの場合

(2)　ビジネスインタフェースの場合

(3)　テストモードで実行する場合の注意

(1)　EJBホームオブジェクトの場合

自動的にバインドされる名称を利用してEJBホームオブジェクトのリファレンスをルックアップする場合，次の規則に従ってEJBオブジェクトリファレンスの名前を指定してルックアップします。

HITACHI_EJB/SERVERS/<サーバ名称>/EJB/<J2EE APP名称>/<Enterprise Bean名称>

＜サーバ名称＞

J2EEサーバ名を指定します。

<J2EE APP名称>

J2EEアプリケーションをルックアップするときの名称（ルックアップ名称）を指定します。

<Enterprise Bean名称>

Enterprise Beanをルックアップするときの名称（ルックアップ名称）を指定します。

次に，自動的にバインドされる名称を利用した場合のルックアップ，取得の流れを示します。

図6-2　自動的にバインドされる名称を利用したルックアップ，取得の流れ

(2)　ビジネスインタフェースの場合

自動的にバインドされる名称を利用してビジネスインタフェースのリファレンスをルックアップする場合，次の規則に従ってEJBオブジェクトリファレンスの名前を指定してルックアップします。

HITACHI_EJB/SERVERS/<サーバ名称>/EJBBI/<J2EE APP名称>/<Enterprise Bean名称>

＜サーバ名称＞

J2EEサーバ名を指定します。

<J2EE APP名称>

J2EEアプリケーションをルックアップするときの名称（ルックアップ名称）を指定します。

<Enterprise Bean名称>

Enterprise Beanをルックアップするときの名称（ルックアップ名称）を指定します。

(3)　テストモードで実行する場合の注意

ルックアップするEnterprise Beanがテストモードで実行されている場合，テストモード用の名前空間を意識してルックアップする必要があります。通常モードで実行されるEnterprise Beanを「HITACHI_EJB/」で始まる文字列でルックアップするのに対して，同じEnterprise Beanがテストモードで実行される場合は「$HITACHI_TEST/HITACHI_EJB/」で始まる文字列でルックアップします。

テストモードでのアプリケーションの動作については，「19.7　J2EEアプリケーションのテスト機能」を参照してください。

6.3.2　ユーザ指定名前空間で付与した名前でのルックアップ

ユーザ指定名前空間とは，EJBホームオブジェクトをネーミングサービスに登録するときの名前を，任意に付けた場合の名前空間です。EJBクライアントでは，付けられた任意の名前でEJBホームオブジェクトのリファレンスをルックアップ，取得できます。例えば，Enterprise Beanに対して「MyCart」という名前を付けた場合は，そのまま「MyCart」という名前を指定してルックアップします。

次に，ユーザ指定名前空間を利用した場合のルックアップ，取得の流れを示します。

図6-3　ユーザ指定名前空間を利用したルックアップ，取得の流れ

なお，ルックアップするEnterprise Beanがテストモードで実行されている場合，テストモード用の名前空間を意識してルックアップする必要があります。この図の例では，通常モードで実行されるEnterprise Beanを「MyCart」でルックアップするのに対して，同じEnterprise Beanがテストモードで実行される場合は，「$HITACHI_TEST/MyCart」でルックアップします。

テストモードでのアプリケーションの動作については，「19.7　J2EEアプリケーションのテスト機能」を参照してください。

6.3.3　EJBホームオブジェクトリファレンスの再利用（EJBホームオブジェクトへの再接続機能）

EJBホームオブジェクトへの再接続機能とは，J2EEサーバの障害などのあとで，J2EEサーバを再起動した場合やJ2EEアプリケーションを再開始した場合に，取得したEJBホームオブジェクトを再利用できる機能です。J2EEサーバの再起動後やJ2EEアプリケーションの再開始後に，EJBクライアントアプリケーションが取得したEJBホームオブジェクトを，再ルックアップしないでそのまま利用できます。

Session Bean（Stateless Session BeanまたはStateful Session Bean）のEJBホームオブジェクトのリファレンスに利用できます。

EJBホームオブジェクトへの再接続機能を使用する場合，J2EEサーバ単位にユーザプロパティファイルで定義します。定義方法については，マニュアル「Cosminexus　システム構築ガイド」のEJBコンテナの機能を使用するための設定の説明を参照してください。

EJBホームオブジェクトへの再接続機能を使用する場合の注意事項を次に示します。

J2EEサーバの再起動やJ2EEアプリケーションの再開始の際に，J2EEアプリケーションを変更しないでください。J2EEアプリケーションを変更すると，EJBホームオブジェクトのリファレンスは再利用できません。

J2EEサーバの通信ポートを固定してください。また，J2EEサーバを再起動するときに，固定した値を変更しないでください。
定義方法については，マニュアル「Cosminexus　システム構築ガイド」のEJBコンテナの通信ポートとIPアドレスの固定（EJBコンテナの機能を使用するための設定）の説明を参照してください。

Javaアプリケーション用ユーザプロパティファイルのリモートインタフェースでの通信障害発生時のEJBクライアントの動作（ejbserver.container.rebindpolicyキー）の値に，「VB_TRANSPARENT」を指定してください。
定義方法については，マニュアル「Cosminexus　システム構築ガイド」のリモートインタフェースでの通信障害発生時のEJBクライアントの動作（EJBコンテナの機能を使用するための設定）の説明を参照してください。

EJB呼び出しで通信障害が発生した場合，通信障害発生時のEJBクライアントの動作（ejbserver.container.rebindpolicyキー）の値に「VB_TRANSPARENT」を指定していると，コネクションが再接続され，リクエストが再送されます。
そのため，EJBホームオブジェクトへの再接続機能は参照系のシステムでの使用を推奨します。

6.4　EJBクライアントアプリケーションでのトランザクションの実装

EJBクライアントでトランザクションを使用するには，クラスパスの追加とシステムプロパティの設定が必要になります。また，EJBクライアントアプリケーションで，UserTransaction（javax.transaction.UserTransaction）を取得する必要があります。

注意

uCosminexus Clientを使用してEJBクライアント環境を構築する場合は，EJBクライアントアプリケーションのトランザクションは使用できません。

＜この節の構成＞

6.4.1　EJBクライアントでトランザクションを使用する手順

6.4.2　ルックアップを使用したUserTransactionの取得方法

6.4.3　EJBクライアントアプリケーションでのトランザクション実装時の注意事項

6.4.1　EJBクライアントでトランザクションを使用する手順

ここでは，EJBクライアントでトランザクションを使用する場合の手順を説明します。

EJBクライアントアプリケーション起動時のクラスパスに，次のJARファイルを追加します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥TPB¥lib¥tpotsinproc.jar
<Cosminexusのインストールディレクトリ>¥CC¥lib¥ejbserver.jar※

UNIXの場合
/opt/Cosminexus/TPB/lib/tpotsinproc.jar
/opt/Cosminexus/CC/lib/ejbserver.jar※

注※

ejbserver.jarはHiEJBClientStatic.jarよりも後ろに追加してください。

EJBクライアントアプリケーション起動時に必要なシステムプロパティを追加します。
システムプロパティの追加方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

EJBクライアントアプリケーションのプロセスの起動直後に，EJBクライアントアプリケーションに実装したユーザコードから，サービスの初期化処理を実行します。
サービスの初期化処理を実行するには，EJBClientInitializerクラス（com.hitachi.software.ejb.ejbclient.EJBClientInitializer）を呼び出します。
なお，EJBClientInitializerクラスのinitializeメソッドを呼び出す前に，javax.naming.InitialContextを生成した場合や，UserTransactionFactoryクラスのgetUserTransactionメソッドを呼び出した場合は，その時点で初期化処理が行われます。このため，EJBClientInitializerクラスによる初期化処理は不要です。
EJBClientInitializerクラスの文法や機能については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

UserTransactionオブジェクトを取得します。
UserTransactionの取得方法には，次の2種類があります。

UserTransactionFactoryクラスを使用する
com.hitachi.software.ejb.ejbclient.UserTransactionFactoryクラスのgetUserTransactionメソッドを使用して取得します。UserTransactionFactoryクラスの文法や機能については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

ルックアップを使用する
ネーミングサービスからルックアップして取得します。ルックアップを使用したUserTransactionの取得方法については，「6.4.2　ルックアップを使用したUserTransactionの取得方法」を参照してください。

EJBクライアントでは，UserTransactionFactoryクラスを使用する方法を推奨しています。ただし，他社のアプリケーションサーバからの移行などによって，EJBクライアントアプリケーションのソースコードを変更できない場合は，ルックアップを使用します。

Enterprise Beanを呼び出すスレッドから，UserTransactionインタフェースのbeginメソッドを呼び出し，トランザクションを開始します。

サーバ上のEnterprise Beanを呼び出します。

Enterprise Beanを呼び出したスレッドから，UserTransactionインタフェースのcommitメソッドまたはrollbackメソッドを呼び出して，トランザクションを決着します。

6.4.2　ルックアップを使用したUserTransactionの取得方法

EJBクライアントアプリケーションからUserTransactionをルックアップする場合に指定する検索文字列を示します。

通常モードのアプリケーションを呼び出す場合
HITACHI_EJB/SERVERS/<サーバ名称>/SERVICES/UserTransaction

テストモードのアプリケーションを呼び出す場合
$HITACHI_TEST/HITACHI_EJB/SERVERS/<サーバ名称>/SERVICES/UserTransaction

ルックアップの結果によって得られるオブジェクトは，java.lang.Object型であるため，javax.transaction.UserTransaction型にキャストして使用します。

また，ルックアップに失敗した場合，javax.naming.NamingException例外が発生します。

UserTransaction型へのキャストや例外については，J2EEサーバ上のWebアプリケーションやEnterprise BeanからUserTransactionをルックアップする場合と同様の仕様となります。

注意

次に示す環境でのUserTransactionのルックアップはサポートされません。

CTM連携時に使用するグローバルネーミングサービスに対するUserTransactionのルックアップ

ラウンドロビン検索機能などで使用されるユーザ指定名前空間管理機能を使用したUserTransactionのルックアップ

この環境でUserTransactionを使用する場合は，UserTransactionFactoryクラスを使用してUserTransactionを取得してください。

6.4.3　EJBクライアントアプリケーションでのトランザクション実装時の注意事項

EJBクライアントでトランザクションを実装する場合の注意事項を示します。

サービスの初期化処理で例外が発生した場合は，システムプロパティが正しく設定されていない可能性があります。例外のメッセージに従って対処してください。

呼び出されるEnterprise Beanを，コンテナ管理のトランザクション（CMT）でmandatory，required，supportsなどの属性にすれば，EJBクライアントアプリケーションで開始したトランザクションの範囲内で実行されます。

EJBクライアントアプリケーションが，トランザクション処理中に障害などの理由でダウンした場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を行う必要があります。EJBクライアントアプリケーションの再起動後に，EJBClientInitializerクラスのinitializeメソッドを呼び出し，グローバルトランザクションのリカバリ処理が開始するように設計してください。なお，リカバリ処理はバックグラウンドで実行されるため，initializeメソッドはリカバリ処理の完了を待たないでリターンします。

EJBクライアントアプリケーションでトランザクションを開始している場合は，必ずすべてのトランザクションを決着してから，EJBクライアントアプリケーションのプロセスが停止するように設計してください。トランザクションの決着処理を待たないでEJBクライアントアプリケーションのプロセスを停止すると，プリペア状態のトランザクションが決着されないまま残るおそれがあります。この状態になると，アプリケーションサーバの正常停止やリソースアダプタの停止ができなくなります。また，リソースのロックが解放されない場合があります。
万一，プリペア状態のトランザクションが残ってしまった場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を行う必要があります。

EJBクライアントアプリケーションでは，JTAやOTSが出力する性能解析トレースに，ルートアプリケーション情報やクライアントアプリケーション情報が含まれていません。リクエストをトレースする場合は，スレッドのハッシュコードやXIDの情報を使用してください。なお，トランザクションタイムアウトが発生した時に出力されるメッセージには，ルートアプリケーション情報の代わりに，トランザクションを開始したスレッドのハッシュコードが含まれています。

6.5　EJBクライアントアプリケーションでのセキュリティの実装

EJBクライアントアプリケーションでは，J2EEサーバで定義されたユーザとパスワードを使用してユーザを認証できます。EJBクライアントアプリケーションからユーザを認証してログインすると，セキュリティロールが設定されたEnterprise Beanのメソッドを呼び出せます。

EJBクライアントアプリケーションでのセキュリティは，Cosminexusが提供するAPIを使用して実装します。ここでは，セキュリティを実装する場合の前提条件，実装方法，およびサンプルプログラムを示します。APIの機能と文法については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この節の構成＞

6.5.1　セキュリティを実装する場合の前提条件

6.5.2　セキュリティを実装した場合のサンプルプログラム

6.5.1　セキュリティを実装する場合の前提条件

セキュリティを実装する前に，次の前提条件を満たしているか確認してください。

J2EEサーバ側にユーザが登録されている必要があります。

登録されているユーザにセキュリティロールが設定されている必要があります。

＜この項の構成＞

(1)　セキュリティの実装方法

(1)　セキュリティの実装方法

EJBクライアントアプリケーションでセキュリティを実装する場合，次の手順で処理を実装します。

セキュリティAPIのパッケージをインポートします。
セキュリティAPIを利用するために，次に示すパッケージをインポートします。

import com.hitachi.software.ejb.security.base.authentication.*

LoginInfoManagerのオブジェクトを取得します。
Enterprise Beanのメソッドを呼び出すプログラム上でLoginInfoManagerオブジェクトを取得します。取得にはLoginInfoManagerオブジェクトに用意されているスタティックメソッドのgetLoginInfoManagerメソッドを使用します。

LoginInfoManager lm = LoginInfoManager.getLoginInfoManager();

ユーザ名とパスワードでログインします。
LoginInfoManagerオブジェクト取得後，loginメソッドを呼び出します。

lm.login(username, password);

Enterprise Beanのメソッドを呼び出します。
loginメソッド成功後，Enterprise Beanのメソッドを呼び出します。

ログアウトします。
Enterprise Beanのメソッド呼び出しが終了したあと，logoutメソッドでJ2EEサーバからログアウトします。

lm.logout();

注意

EJBクライアントアプリケーションでセキュリティを実装する場合，HiEJBClientStatic.jarをクラスパスに追加してコンパイルする必要があります。

6.5.2　セキュリティを実装した場合のサンプルプログラム

Enterprise Bean名がaccountの場合に，getAccountIDメソッドを呼び出すサンプルプログラムを次に示します。

import com.hitachi.software.ejb.security.base.authentication.*;
   :
 try {
   LoginInfoManager lm = LoginInfoManager.getLoginInfoManager();
   String userName = System.getProperty("username");
   String password = System.getProperty("password");
   if(lm.login(userName , password)) {
     try {
       System.out.println("user:" + userName + "login success");
       Context ctx = new InitialContext();
       java.lang.Object obj = ctx.lookup(appUnitPath + "Account");
       AccountHome aHome =
          (AccountHome)PortableRemoteObject.narrow(obj,AccountHome.class);
       Account account  = aHome.create();
       account.getAccountID();
     } finally {
       lm.logout();
     }
   }
 } catch(NotFoundServerException e) {
   System.out.println("not found server");
 } catch(InvalidUserNameException e) {
   System.out.println("invalid user name");
 } catch(InvalidPasswordException e) {
   System.out.println("invalid password");
 } catch(Exception e) {
   e.printStackTrace();
 }

6.6　RMI-IIOPスタブ，インタフェースの取得

EJBクライアントアプリケーションは，Cosminexus TPBrokerのRMI-IIOPの機能を利用してアプリケーションを呼び出します。

EJBホームオブジェクトのリファレンスを検索，取得する場合，EJBクライアントアプリケーションは次に示すスタブおよびクラスを参照できるようにする必要があります。

Enterprise BeanのEJBオブジェクトのスタブ

Enterprise BeanのEJBホームオブジェクトのスタブ

スタブが利用する各種クラス

また，EJBクライアントアプリケーションからは，次に示すインタフェース，および各種クラスを参照できるようにする必要があります。

リモートインタフェース

ホームインタフェース

インタフェースが参照する各種クラス

ビジネスインタフェースを使用してEnterprise Beanを呼び出す場合は，ビジネスインタフェース，およびビジネスインタフェースを呼び出すためのクラスを参照できるようにする必要があります。

これらのクラス（RMI-IIOPスタブ，RMI-IIOPインタフェース）は，サーバ管理コマンドまたはダイナミッククラスローディングを使用してダウンロードします。

ポイント

サーバ管理コマンドとダイナミッククラスローディングの使い分け

ダイナミッククラスローディングを使用するよりも，サーバ管理コマンドを使用して呼び出しに必要なクラスをダウンロードした方が性能上優れています。したがって，実運用ではサーバ管理コマンドの使用を推奨します。一方，開発，テスト時にはスタブの取得と更新に手間の掛からない，ダイナミッククラスローディングの使用を推奨します。

＜この節の構成＞

6.6.1　サーバ管理コマンドによる手動ダウンロード

6.6.2　ダイナミッククラスローディング

6.6.3　uCosminexus Client使用時の注意

6.6.1　サーバ管理コマンドによる手動ダウンロード

サーバ管理コマンドのcjgetstubsjarコマンドでRMI-IIOPスタブおよびRMI-IIOPインタフェースをダウンロードできます。cjgetstubsjarコマンドの使用方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

6.6.2　ダイナミッククラスローディング

RMI-IIOPスタブをクラスパスに指定しないで，EJBクライアントアプリケーションを開始します。EJBクライアントアプリケーションがEnterprise Beanを呼び出したときにRMI-IIOPスタブおよびRMI-IIOPインタフェースが自動的に読み込まれます。

RMI-IIOPスタブのダイナミッククラスローディングを利用する場合の手順を示します。

簡易構築定義ファイルを編集します。
簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.DynamicStubLoading.Enabledパラメタで「true」を指定します。

該当するJ2EEサーバを再開始します。
J2EEサーバを開始します。J2EEアプリケーションが開始済みの場合は，一度停止してから再開始してください。

注意

ダイナミッククラスローディング使用上の注意事項を次に示します。

ダイナミッククラスローディングを使用する場合，同じJ2EEサーバ内で，同じパッケージ名称，インタフェース名称のEnterprise Beanを持つJ2EEアプリケーションを複数開始できません。なお，インタフェースの継承元となる親クラス名称が同じ場合もJ2EEアプリケーションを複数開始できません。ここでの継承元となる親クラスとは，ユーザが作成するクラスであり，J2SEやJ2EEが提供するクラスではありません。

クライアントプログラムのクラスパスにスタブを指定していない場合，シリアライズされたEnterprise BeanオブジェクトのHandle（javax.ejb.Handle）を復元できません。

CTMのグローバルCORBAネーミングサービスをルックアップする場合には，ダイナミッククラスローディング機能は使用できません。

6.6.3　uCosminexus Client使用時の注意

uCosminexus Clientにはcjgetstubsjarコマンドは含まれていないため，サーバ管理コマンドで取得できません。uCosminexus ClientでRMI-IIOPのスタブを手動で取得する場合の手順を次に示します。

Application Serverが稼働するマシンでcjgetstubsjarコマンドを実行し，RMI-IIOPのスタブとインタフェースのファイルを任意のディレクトリに置きます。

uCosminexus Clientが稼働するマシンからApplication Serverが稼働するマシンにアクセスし，ファイル転送などの方法でRMI-IIOPのスタブとインタフェースのファイルをダウンロードします。

7.　J2EEアプリケーションの実行

この章では，J2EEサーバで実行できるJ2EEアプリケーションの形態と，J2EEアプリケーションを実行するための機能について説明します。

＜この章の構成＞

7.1　実行できるJ2EEアプリケーションの形態

7.2　アーカイブ形式によるJ2EEアプリケーションのデプロイ

7.3　展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ

7.4　J2EEアプリケーションのリデプロイ

7.5　J2EEアプリケーションの更新検知とリロード

7.1　実行できるJ2EEアプリケーションの形態

J2EEサーバ上で実行できるアプリケーションを，J2EEアプリケーションといいます。WAR形式のWebアプリケーション，またはEJB-JAR形式のEJBアプリケーションをJ2EEサーバで実行するためには，J2EEアプリケーションとしてデプロイする必要があります。J2EEサーバ上で実行できるJ2EEアプリケーションは，次に示す2種類です。

アーカイブ形式のJ2EEアプリケーション
EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションです。

展開ディレクトリ形式のJ2EEアプリケーション
EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションです。

7.2以降で，それぞれの形式のJ2EEアプリケーションのデプロイについて説明します。また，J2EEアプリケーションの実行機能として，J2EEアプリケーションのリデプロイ，J2EEアプリケーションの更新検知とリロードについても説明します。

なお，システムの運用を開始したあとでJ2EEアプリケーションの運用中に使用する機能については，「19.　J2EEアプリケーションの運用」を参照してください。

7.2　アーカイブ形式によるJ2EEアプリケーションのデプロイ

この節では，アーカイブ形式によるJ2EEアプリケーションのデプロイについて説明します。

＜この節の構成＞

(1)　アーカイブ形式のJ2EEアプリケーションとは

(2)　J2EEアプリケーションのデプロイ

(3)　J2EEアプリケーションのアンデプロイ

(1)　アーカイブ形式のJ2EEアプリケーションとは

J2EEサーバ上で実行できるアプリケーションの形式の一つに，アーカイブ形式のJ2EEアプリケーションがあります。アーカイブ形式のJ2EEアプリケーションは，EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つアプリケーションです。アーカイブ形式のJ2EEアプリケーションを次の図に示します。

図7-1　アーカイブ形式のJ2EEアプリケーション

アーカイブ形式のJ2EEアプリケーションでは，アプリケーションの実体はJ2EEサーバ上にあり，J2EEサーバの作業ディレクトリ下にアプリケーションの構成要素を保持します。

通常，アーカイブ形式のJ2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションの停止，新しいJ2EEアプリケーションのインポート，デプロイなどの作業が発生します。このとき，リデプロイ機能を使用すると，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。

リデプロイ機能を使用したJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションの属性情報を引き継ぐことができ，J2EEサーバ上で動作しているJ2EEアプリケーションの停止，新しいJ2EEアプリケーションのインポート，デプロイなどの作業が不要になります。リデプロイ機能については，「7.4　J2EEアプリケーションのリデプロイ」を参照してください。リデプロイ機能を使用したJ2EEアプリケーションの入れ替えについては，「19.6.1　J2EEアプリケーション入れ替えの概要」を参照してください。

(2)　J2EEアプリケーションのデプロイ

Webアプリケーション，またはEJBアプリケーションをJ2EEサーバで実行するためには，J2EEアプリケーションとしてデプロイする必要があります。J2EEアプリケーションを実行するJ2EEサーバにEARファイルをインポートしてください。

(3)　J2EEアプリケーションのアンデプロイ

アーカイブ形式のJ2EEアプリケーションを削除する場合は，J2EEアプリケーションに対してアンデプロイを実行します。アンデプロイの処理完了後に，J2EEサーバからJ2EEアプリケーションが削除されます。

7.3　展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ

この節では，展開ディレクトリ形式によるJ2EEアプリケーションのデプロイについて説明します。

＜この節の構成＞

7.3.1　展開ディレクトリ形式の概要

7.3.2　アプリケーションディレクトリの構成

7.3.3　EARファイル／ZIPファイルの展開ディレクトリ形式でのデプロイ

7.3.4　展開ディレクトリ形式を使用する場合の注意事項

7.3.1　展開ディレクトリ形式の概要

ここでは，展開ディレクトリ形式の概要，デプロイおよびアンデプロイの方法について説明します。

＜この項の構成＞

(1)　展開ディレクトリ形式のJ2EEアプリケーションとは

(2)　J2EEアプリケーションのデプロイ

(3)　J2EEアプリケーションのアンデプロイ

(1)　展開ディレクトリ形式のJ2EEアプリケーションとは

J2EEサーバ上で実行できるアプリケーションの形式の一つに，展開ディレクトリ形式のJ2EEアプリケーションがあります。展開ディレクトリ形式のJ2EEアプリケーションは，EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つアプリケーションです。アプリケーションディレクトリというルートディレクトリを作成し，アプリケーションディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素が格納されていれば，J2EEアプリケーションとして動作できます。アプリケーションディレクトリについては，「7.3.2　アプリケーションディレクトリの構成」を参照してください。

展開ディレクトリ形式のJ2EEアプリケーションを次の図に示します。

図7-2　展開ディレクトリ形式のJ2EEアプリケーション

展開ディレクトリ形式のJ2EEアプリケーションが保持するのは，DDとアプリケーションディレクトリへのパス情報です。J2EEサーバの作業ディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素を保持しません。

展開ディレクトリ形式のJ2EEアプリケーションの特長について説明します。

(a)　J2EEアプリケーションの入れ替えの容易化

展開ディレクトリ形式のJ2EEアプリケーションでは，構成要素をEAR形式にアーカイブする必要はありません。このため，アーカイブ形式のJ2EEアプリケーションと比べて，少ない手順でJ2EEアプリケーションの入れ替えができます。

また，リロード機能を使用することで，さらに少ない手順でJ2EEアプリケーションを動的に入れ替えられます。リロード機能では，J2EEアプリケーションを構成するファイルの更新を検知し，更新したJ2EEアプリケーションをリロードします。リロード機能を使用することで，J2EEサーバを再起動することなく，デプロイ済みのサーブレット，JSPやEJB-JARを動的に入れ替えられるようになります。リロード機能については，「7.5　J2EEアプリケーションの更新検知とリロード」を参照してください。

(b)　複数のJ2EEサーバでのアプリケーションディレクトリの共有

展開ディレクトリ形式のJ2EEアプリケーションでは，複数のJ2EEサーバでアプリケーションディレクトリを共有できます。

例えば，アーカイブ形式のJ2EEアプリケーションを使用している場合に，同じ内容のJ2EEアプリケーションを複数のJ2EEサーバで実行させるときは，複数のJ2EEサーバ上に，EARファイル／ZIPファイルをそれぞれ配置する必要があります。また，インポートしたJ2EEアプリケーションを入れ替える場合には，J2EEサーバの数だけ，再インポートや再デプロイが必要になります。

しかし，展開ディレクトリ形式のJ2EEアプリケーションでは，DDとアプリケーションディレクトリへのパス情報だけを保持するため，アプリケーションディレクトリ以下にあるEJB-JAR，Webアプリケーションなどの構成要素を，複数のJ2EEサーバで共有できます。

例えば，J2EEサーバをクラスタ構成で配置している場合にそれぞれのJ2EEサーバで同じJ2EEアプリケーションを使用するときは，同一のディレクトリをアプリケーションディレクトリとして指定できます。同一のアプリケーションディレクトリを参照しているため，J2EEアプリケーションに変更が発生した場合には，そのアプリケーションディレクトリでクラスファイルなどを更新するだけで，すべてのJ2EEアプリケーションの入れ替えができるようになります。アプリケーションディレクトリの共有の例を次の図に示します。

図7-3　アプリケーションディレクトリの共有の例

なお，J2EEアプリケーションを共有する場合には，それぞれのJ2EEサーバから参照できる環境（共有ディスク装置など）にアプリケーションディレクトリを配置してください。

(2)　J2EEアプリケーションのデプロイ

展開ディレクトリ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，デプロイが必要です。J2EEアプリケーションを実行するJ2EEサーバに，展開ディレクトリ形式のJ2EEアプリケーションをインポートしてください。アプリケーション開始時に生成される各クラスローダは，クラスパスとしてアプリケーションディレクトリを保持して動作します。

(3)　J2EEアプリケーションのアンデプロイ

展開ディレクトリ形式のJ2EEアプリケーションを削除する場合は，展開ディレクトリ形式のJ2EEアプリケーションに対してアンデプロイを実行します。アンデプロイの処理完了後に，J2EEサーバへのJ2EEアプリケーションの登録が解除されます。なお，アプリケーションディレクトリは削除されません。

7.3.2　アプリケーションディレクトリの構成

アプリケーションディレクトリは，展開ディレクトリ形式のJ2EEアプリケーションのルートディレクトリです。展開ディレクトリ形式のJ2EEアプリケーションを作成する場合には，アプリケーションディレクトリを作成し，アプリケーションディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素を格納します。アプリケーションディレクトリの構成を次の表に示します。

表7-1　アプリケーションディレクトリの構成

ディレクトリ
ディレクトリの説明

<アプリケーションディレクトリ>
展開ディレクトリ形式のJ2EEアプリケーションのルートディレクトリです。アプリケーションディレクトリの名称は任意です。

META-INF
J2EEアプリケーションのDDの格納ディレクトリです。このディレクトリの直下に，application.xmlが格納されます。

<EJB-JARディレクトリ>
EJBアプリケーションのルートディレクトリです。

META-INF
EJB-JARのDDの格納ディレクトリです。このディレクトリの直下に，ejb-jar.xmlが格納されます。

<パッケージ名>
EJB-JARのクラスファイルやプロパティファイルを格納するディレクトリです。

（例）

MyEJB.class

MyEJBHome.class

MyEJBRemote.class

MyResource.properties

<WARディレクトリ>
Webアプリケーションのルートディレクトリです。
なお，このディレクトリの直下に，JSPファイルが格納されます。

（例）

index.jsp

WEB-INF
WebアプリケーションのDDの格納ディレクトリです。このディレクトリの直下に，web.xmlが格納されます。

classes
サーブレットクラスファイルやプロパティファイルを格納するディレクトリです。

（例）

MyServlet.class

lib
タグライブラリなどのJARファイルを格納するディレクトリです。

（例）

MyTagLibrary.jar

RARファイル※
J2EEアプリケーションで使用するリソースアダプタです。

注※　リソースアダプタ（RARファイル）をJ2EEアプリケーションに含めて使用する場合に配置します。RARファイルは，アーカイブファイルのまま格納します。リソースアダプタをJ2EEリソースアダプタとしてデプロイする場合は，アプリケーションディレクトリにリソースアダプタを格納する必要はありません。

アプリケーションディレクトリの留意事項を次に示します。

<EJB-JARディレクトリ>，<WARディレクトリ>，およびRARファイルを配置する場所は，application.xmlの<module>タグ以下に記述した相対パスに従って作成してください。また，EJB-JARディレクトリとWARディレクトリの名称もapplication.xmlの記述と合わせてください。application.xmlの<module>タグ以下に記述したEAR上の相対パス（EJB-JARファイル名，またはWARファイル名）から拡張子（「.jar」または「.war」）を除いたものが，EJB-JARディレクトリとWARディレクトリの名称になります。

application.xmlの<module>タグ以下で，EJB-JARとWARのモジュールが，「.jar」または「.war」以外の拡張子で宣言されていた場合，アプリケーションのインポートに失敗します。

アプリケーションディレクトリ以下のJARファイルのうち，application.xmlの<module>タグ以下で定義していない，拡張子が小文字（.jar）のJARファイルは，ライブラリJARとして扱われます。

アプリケーションディレクトリにないJARを指定する場合は，参照ライブラリを使用します。

アプリケーションディレクトリを変更する場合には，「(2)　アプリケーションディレクトリの変更」に示す規則に従ってください。

＜この項の構成＞

(1)　アプリケーションディレクトリの作成例

(2)　アプリケーションディレクトリの変更

(1)　アプリケーションディレクトリの作成例

アプリケーションディレクトリの作成例を次に示します。

ここでは，EJB-JARディレクトリが「subdir/converter」，WARディレクトリが「MyWebApp」，RARファイルが「rardir/DBConnector_DABJ_CP.rar」の場合のアプリケーションディレクトリの構成例，application.xmlの記述例を示します。

アプリケーションディレクトリの構成例
この例でのアプリケーションディレクトリの構成を次に示します。

application.xmlの記述例
この例でのapplication.xmlを次に示します。

<?xml version="1.0" encoding="Shift_JIS" ?>
<application xmlns="http://java.sun.com/xml/ns/j2ee"
            version="1.4"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                       http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
 <display-name>converter</display-name>
 <module>
   <ejb>subdir/converter.jar</ejb>
 </module>
 <module>
   <web>
     <web-uri>MyWebApp.war</web-uri>
     <context-root>/</context-root>
   </web>
 </module>
 <module>
   <connector>rardir/DBConnector_DABJ_CP.rar</connector>
 </module>
</application>

(2)　アプリケーションディレクトリの変更

アプリケーションディレクトリを変更する場合，変更の対象となるディレクトリやファイルの種類と操作の内容によって，変更できなかったり，変更後にアプリケーションの再インポートが必要になったりします。

（例）

ディレクトリの削除／名称変更
アプリケーションディレクトリ，EJB-JARディレクトリ，およびWARディレクトリは削除できません。また，ディレクトリ名は変更できません。削除した場合や名称を変更した場合には，アプリケーションを再インポートする必要があります。

JARファイルの追加／変更／削除
ライブラリJARの追加，削除，およびファイル名の変更はできません。ライブラリJAR（application.xmlで宣言していないJARファイル）を追加しても，そのJARファイルは読み込まれません。アプリケーションのインポート時に存在したライブラリJARのファイル名を変更した場合や，ライブラリJARを削除した場合には，アプリケーションを再インポートする必要があります。
なお，WARディレクトリ/WEB-INF/libディレクトリでは，JARファイルの追加／変更／削除はできます。

DDの変更
ユーザがアプリケーションディレクトリに存在するDDを変更しても，J2EEサーバは更新を検知しません。DDに記述された定義の更新にはサーバ管理コマンドを使用してください。ただし，クラスファイルに記述されたアノテーションは，次回J2EEアプリケーションを開始したときのクラスファイルの再読み込みで，更新を反映させることができます。
なお，サーバ管理コマンド実行時にアプリケーションディレクトリの構成がチェックされます。

アプリケーションディレクトリの変更可否を次の表に示します。

表7-2　アプリケーションディレクトリの変更可否

対象
ディレクトリおよびファイル
ディレクトリおよびファイルへの操作
アプリケーションの状態
説明

停止
開始

J2EEアプリケーション
アプリケーションディレクトリ
追加
－
－
－

内容変更
－
－
－

名称変更
△
×
アプリケーションの構成変更はできない。

削除
△
×
アプリケーションの構成変更はできない。

application.xml
追加
－
－
－

内容変更
○
×
DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更
－
－
－※1

削除
△
×
－※1

EJBアプリケーション
EJB-JARディレクトリ
追加
△
－
－

内容変更
－
－
－

名称変更
△
×
アプリケーションの構成変更はできない。

削除
△
×
アプリケーションの構成変更はできない。

EJBを構成するクラスファイル
追加
◎
×
クラスを追加したあとで，サーバ管理コマンド（またはServer Plug-in）で属性を編集する必要がある。

内容変更
◎
×
DDにメソッド情報（container-transactionやmethod-permission）が記述されている場合には，DDの情報と同期を取って修正する必要がある。

名称変更
△
×
クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除
◎
×
クラスを削除したあとで，サーバ管理コマンド（またはServer Plug-in）で属性を編集する必要がある。

ほかのクラスファイル
追加
◎
×
－

内容変更
◎
×
－

名称変更
△
×
クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除
◎
×
－

ejb-jar.xml
追加
－
－
－

内容変更
○
×
DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更
－
－
－※1

削除
△
×
－※1

Webアプリケーション
WARディレクトリ
追加
△
－
－

内容変更
－
－
－

名称変更
△
×
アプリケーションの構成変更はできない。

削除
△
×
アプリケーションの構成変更はできない。

WEB-INF/classes下のクラスファイルやプロパティファイル
追加
◎
×
－

内容変更
◎
×
－

名称変更
－
－
クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除
◎
×
－

WEB-INF/lib下のJARファイル
追加
◎
×
－

内容変更
◎
×
－

名称変更
◎
×
－

削除
◎
×
－

web.xml
追加
－
－
－

内容変更
○
×
DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更
－
－
－※1

削除
△
×
－※1

JSPファイル，
タグファイル，
静的コンテンツ（HTMLやJavaScriptなど），
JSPファイルまたはタグファイルが依存するファイル※2，
JSPコンパイル結果
追加
◎
×
－

内容変更
◎
×
－

名称変更
－
－
－

削除
◎
×
－

ライブラリ
ライブラリJAR
追加
△
×
アプリケーションの構成変更はできない。
ライブラリJARを追加しても無視される。

内容変更
◎
×
－

名称変更
△
×
アプリケーションの構成変更はできない。

削除
△
×
アプリケーションの構成変更はできない。

参照ライブラリ
追加
◎
×
サーバ管理コマンド（cjsetappprop）で定義を変更する。

内容変更
◎
×
－

名称変更
－
－
サーバ管理コマンド（cjsetappprop）で定義を変更する。開始状態では変更できない。

削除
○
×
サーバ管理コマンド（cjsetappprop）で定義を変更する。開始状態では削除できない。

参照ライブラリのディレクトリ
追加
◎
×
－

内容変更
◎
×
－

名称変更
◎
×
－

削除
◎
×
－

リソースアダプタ
RARファイル
追加
△
×
－

内容変更
○
×
RARファイルを直接変更できない。サーバ管理コマンドを使用してプロパティを変更する。

名称変更
△
×
－

削除
△
×
－

（凡例）

「アプリケーションの状態」が「停止」の場合

アプリケーションが停止状態の場合，ディレクトリおよびファイルの種類や操作の内容によって，アプリケーションの再インポートの要否が異なります。

◎：再インポートは不要（次回アプリケーション開始時に操作が反映される）。

○：条件を満たす場合には，再インポートは不要。条件は「説明」を参照。

△：再インポートが必要。

－：該当しない。

「アプリケーションの状態」が「開始」の場合

アプリケーションが開始状態でリロード機能が無効の場合，ディレクトリおよびファイルの種類や操作の内容によって，操作を許可するかどうかが異なります。

×：操作できない。

－：該当しない。

注※1

DDを変更してもJ2EEサーバは更新を検知しないで，操作は無視されます。

次に示すコマンドを次回，実行したときに上書きされます。

cjsetappprop

cjaddapp（-type filterオプション指定時）

cjdeleteapp（-type filterオプション指定時）

cjrenameapp

cjstartapp

注※2

依存するファイルは，JSPファイルまたはタグファイルのincludeディレクティブでインクルードされるファイルや，web.xmlの<include-prelude>または<include-coda>でインクルードされるファイルのことです。

7.3.3　EARファイル／ZIPファイルの展開ディレクトリ形式でのデプロイ

EARファイルや，J2EEサーバからエクスポートしたZIPファイルを，展開ディレクトリ形式でJ2EEサーバにインポートできます。この機能を使用することで，作成済みのEARファイル／ZIPファイルを，展開ディレクトリ形式のJ2EEアプリケーションとして動作させることが容易になります。

＜この項の構成＞

(1)　EARファイル／ZIPファイルの展開

(2)　ディレクトリ名の生成規則

(1)　EARファイル／ZIPファイルの展開

EARファイル／ZIPファイルの内容を任意のディレクトリに展開して，展開ディレクトリ形式のJ2EEアプリケーションとしてJ2EEサーバにインポートします。EARファイル／ZIPファイルの展開を次の図に示します。

図7-4　EARファイル／ZIPファイルの展開

インポートするときに，コマンドの引数として，EARファイル／ZIPファイルと，アプリケーションディレクトリとなる展開先のディレクトリを指定します。J2EEサーバは，展開先のディレクトリのパス情報をコマンドから受け取り，そのパス情報を基にアプリケーションディレクトリを生成して，アプリケーションディレクトリ下にEARファイル／ZIPファイルの内容を展開します。

(2)　ディレクトリ名の生成規則

EARファイル／ZIPファイルを展開ディレクトリ形式としてインポートする場合，ディレクトリ名の衝突が発生することがあります。EARファイル／ZIPファイルを展開する場合の，EJB-JARディレクトリとWARディレクトリのディレクトリ名の生成規則を次に示します。

EARファイル内のディレクトリと衝突しない場合
EJB-JARファイルとWARファイルから拡張子（「.jar」または「.war」）を除いたものが，EJB-JARディレクトリとWARディレクトリの名称になります。
EJB-JARファイルとWARファイルに拡張子がない場合は，ファイル名がそのままディレクトリ名になります。

EJB-JARファイルとWARファイルで衝突する場合，またはEARファイル内のディレクトリと衝突する場合
EJB-JARファイルとWARファイルの拡張子（「.jar」または「.war」）をそれぞれ「_jar」または「_war」に置き換えたものが，EJB-JARディレクトリとWARディレクトリの名称になります。

「_jar」または「_war」に置き換えても衝突する場合
「_jar」または「_war」の後ろに通し番号（1～2147483647）が付加されます。

ディレクトリ名の衝突が発生する場合のEARファイルの構成と，生成されるアプリケーションディレクトリの構成を次の図に示します。

図7-5　ディレクトリ名の衝突の例

注意

cjimportappコマンドの-dオプションを使用してEARファイル／ZIPファイルを展開して作成されたアプリケーションディレクトリが，次に示す条件のどれかに合致する場合，そのアプリケーションディレクトリをcjimportappコマンドの-aオプションに指定していると，インポートに失敗します。

EJB-JARのモジュール名が「.jar」で終わっていない。

WARのモジュール名が「.war」で終わっていない。

モジュールの拡張子を除いた名称が，ほかのモジュールの拡張子を除いた名称と重複する。

モジュールの拡張子を除いた名称が，EARファイル内のディレクトリと重複する。

7.3.4　展開ディレクトリ形式を使用する場合の注意事項

展開ディレクトリ形式を使用する場合の注意事項を次に示します。

展開ディレクトリ形式のJ2EEアプリケーションでは，アーカイブ形式のJ2EEアプリケーションと比べて，次の作業ができません。

EJB-JAR／WAR／RARの追加

EJB-JAR／WAR／RARの削除

ライブラリJARの追加

ライブラリJARの削除

展開ディレクトリ形式のJ2EEアプリケーションでこれらの作業を実施したい場合には，次の手順で実施してください。

J2EEサーバから展開ディレクトリ形式のJ2EEアプリケーションを削除します。

アプリケーションディレクトリを修正します。

修正した展開ディレクトリ形式のJ2EEアプリケーションをインポートします。

展開ディレクトリ形式のJ2EEアプリケーションを使用する場合には，J2EEアプリケーションが任意のリソースへアクセスできるように，セキュリティの設定を変更することをお勧めします。セキュリティの設定の変更については，マニュアル「Cosminexus　システム構築ガイド」の展開ディレクトリ形式のJ2EEアプリケーションの設定に関する説明を参照してください。

展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合に，アプリケーションディレクトリのパスとしてUNC名を含むパスは指定できません。UNC名を含むパスを指定した場合には，コマンドの実行エラーになります。

J2EEサーバの起動処理中やサーバ管理コマンドの実行中にアプリケーションディレクトリ以下のファイルおよびディレクトリを追加／削除／上書きしないでください。

application.xmlに<alt-dd>タグが指定されているJ2EEアプリケーションは，展開ディレクトリ形式で使用できません。展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合，またはEARファイルや，J2EEサーバからエクスポートしたZIPファイルを展開ディレクトリ形式でインポートする場合に，J2EEアプリケーションのapplication.xmlに<alt-dd>タグが指定されているときは，コマンドの実行エラーになります。

J2EEサーバ内で，複数のJ2EEアプリケーションが同一のディレクトリをアプリケーションディレクトリとして指定することはできません。展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合，またはEARファイルや，J2EEサーバからエクスポートしたZIPファイルを展開ディレクトリ形式でインポートする場合に，指定したディレクトリがすでにほかのJ2EEアプリケーションのアプリケーションディレクトリであるときは，コマンドの実行エラーになります。

アプリケーションディレクトリ以下にJavaソースファイルを置くような構成は推奨しません。同じディレクトリに置かれているクラスファイルとJavaソースファイルの同期が取れていない場合，アプリケーションの開始やリロードに失敗する場合があります。

次の半角記号はエスケープ文字として扱われるため，アプリケーションディレクトリ名およびモジュール名には指定しないでください。
!　#　%　+

アプリケーションディレクトリ以下に置かれているJARファイルはライブラリJARとして扱われます。このため，アプリケーションディレクトリ以下には，cjgetstubsjarコマンドで取得したスタブおよびインタフェースを置かないでください。

7.4　J2EEアプリケーションのリデプロイ

リデプロイとは，少ない手順で高速にJ2EEアプリケーションを入れ替えられるデプロイ方法です。この節では，リデプロイ機能を使用したJ2EEアプリケーションの入れ替えについて説明します。

リデプロイ機能を使用したJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションのすべての属性の情報を引き継ぐことができます。リデプロイ機能でのJ2EEアプリケーションの入れ替えは，次のような場合に利用できます。

J2EEアプリケーションのテスト時のロジックの修正による入れ替え

テスト実施中，J2EEアプリケーション内のロジックに問題を発見してJ2EEアプリケーション内のEJB-JARファイルやWARファイルなどを修正した場合に，テスト中のアプリケーションを修正後のJ2EEアプリケーションと入れ替えるときに使用できます。

運用中のJ2EEアプリケーションと開発環境でテストしたJ2EEアプリケーションとの入れ替え

開発環境にあるJ2EEアプリケーションを，すでに運用中のJ2EEアプリケーションと入れ替えるときに使用できます。

ただし，運用環境と開発環境のアプリケーションの構成は同じで，ロジックだけが異なるJ2EEアプリケーションの場合に入れ替えできます。

リデプロイ機能を使用する場合には，通常のJ2EEアプリケーションの入れ替えを実施するときに必要となる，入れ替え前のJ2EEアプリケーションの停止と削除，入れ替えるJ2EEアプリケーションのインポートとデプロイなどの手順が不要になります。このため，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。J2EEアプリケーションの入れ替えについては，「19.6.1　J2EEアプリケーション入れ替えの概要」を参照してください。

なお，リデプロイ機能を使用したJ2EEアプリケーションの入れ替えができるのは，アーカイブ形式のJ2EEアプリケーションです。展開ディレクトリ形式のJ2EEアプリケーションでは，リデプロイ機能は使用できません。

参考

リデプロイを実行する前に，JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は，Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし，クラスファイルを生成する機能です。あらかじめ，クラスファイルの生成までを実施しておくので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については，「4.7　JSPの事前コンパイルとコンパイル結果の保持」を参照してください。

＜この節の構成＞

7.4.1　J2EEアプリケーションの状態と入れ替え

7.4.2　注意事項

7.4.1　J2EEアプリケーションの状態と入れ替え

リデプロイ機能では，J2EEアプリケーションが開始・停止の状態に関係なく入れ替えできます。

開始状態のアプリケーションを入れ替えた場合，および停止状態のアプリケーションを入れ替えた場合について説明します。

＜この項の構成＞

(1)　開始状態のJ2EEアプリケーションを入れ替えた場合

(2)　停止状態のJ2EEアプリケーションを入れ替えた場合

(1)　開始状態のJ2EEアプリケーションを入れ替えた場合

開始状態のJ2EEアプリケーションを入れ替えた場合，入れ替え後のJ2EEアプリケーションも開始状態になります。

開始状態のJ2EEアプリケーションをリデプロイすると，次のような流れで入れ替え処理が実施されます。

J2EEアプリケーションを停止する

J2EEアプリケーションを入れ替える

J2EEアプリケーションを開始する

それぞれの処理については，タイムアウトがあります。

停止時のタイムアウト

J2EEアプリケーションの停止処理の実行時間が，サーバ管理コマンドでタイムアウトとして設定した時間を超えた場合，J2EEアプリケーションは強制停止されます。強制停止を実施後，強制停止で設定したタイムアウト値の時間を超えてもJ2EEアプリケーションが停止しない場合は，サーバ管理コマンドは異常終了します。

タイムアウトの設定については，マニュアル「Cosminexus　システム運用ガイド」，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，タイムアウトの時間には，次に示す順序で，最初に取得できた値が適用されます。

サーバ管理コマンドに設定されたタイムアウト値

デフォルト値（60秒）

入れ替え時および開始時のタイムアウト

入れ替え処理，および開始処理の実行時間でタイムアウト値として設定した時間を超えた場合，サーバ管理コマンドは異常終了します。なお，タイムアウト値は，RMI-IIOP通信のタイムアウトに設定した時間が適用されます。RMI-IIOP通信のタイムアウトについては，「5.9.4　RMI-IIOP通信のタイムアウト」を参照してください。

(2)　停止状態のJ2EEアプリケーションを入れ替えた場合

停止状態のJ2EEアプリケーションを入れ替えた場合，入れ替え後のJ2EEアプリケーションも停止状態になります。停止状態のJ2EEアプリケーションのリデプロイでは，アプリケーションの入れ替え処理だけが実施されます。

7.4.2　注意事項

リデプロイによるJ2EEアプリケーションの入れ替えの注意事項について説明します。

入れ替え処理実行時に，J2EEサーバ上に同じ名称のJ2EEアプリケーションがない場合は，エラーになります。入れ替えはできません。

リデプロイによるJ2EEアプリケーションの入れ替えでは，入れ替え前のJ2EEアプリケーションの実行時情報を，入れ替え後のJ2EEアプリケーション（新しいJ2EEアプリケーション）に引き継ぐため，入れ替え後のJ2EEアプリケーションに実行時情報が含まれていると入れ替えができません。入れ替えをしようとすると，エラー終了します。

デフォルトの設定の場合，入れ替え後のJ2EEアプリケーションには，入れ替え前のJ2EEアプリケーションのすべての属性が引き継がれます。06-70よりも前のバージョンと同じように，ランタイム属性※だけを引き継ぐ場合は，オプションを指定してcjreplaceappコマンドを実行する必要があります。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

J2EEアプリケーションについて，入れ替え前と入れ替え後で次に示す内容に差異があると，入れ替え処理でエラー終了します。

J2EEアプリケーション内のEJB-JARファイルの数，リソースアダプタの数，およびWARの数が異なる。

J2EEアプリケーション内のEJB-JARファイル名，RARファイル名，およびWARファイル名が，入れ替え前と入れ替え後とで異なる。

EJB-JARファイル内のホームインタフェース（ローカル／リモート），コンポーネントインタフェース（ローカル／リモート），およびビジネスインタフェース（ローカル／リモート）のメソッド定義が異なる。

ランタイム属性※だけを引き継ぐ設定をしている場合に，DD（application.xml，ejb-jar.xml，ra.xml，web.xml）の定義が異なる。

設定しているアノテーションの値を変更した。

開始状態のJ2EEアプリケーションを入れ替えした場合，プールやキャッシュに格納されたJ2EEアプリケーション関連のオブジェクトは破棄されます。

注※

属性ファイルには，DD（application.xml，ejb-jar.xml，ra.xml，web.xml）の定義と属性ファイル独自の定義が設定できます。属性ファイル独自の定義のことをランタイム属性といいます。

7.5　J2EEアプリケーションの更新検知とリロード

J2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。この節では，J2EEアプリケーションの更新検知とリロードについて説明します。

J2EEアプリケーションの更新検知とリロードの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。また，コマンドやファイルのキーについては，マニュアル「Cosminexus　リファレンス　コマンド編」，およびマニュアル「Cosminexus　リファレンス　定義編」を参照してください。

＜この節の構成＞

7.5.1　更新検知とリロードの概要

7.5.2　更新検知の対象となるファイル

7.5.3　J2EEアプリケーションの更新検知インターバル

7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル

7.5.5　Webアプリケーションのリロード

7.5.6　JSPのリロード

7.5.7　ほかの機能との関係

7.5.1　更新検知とリロードの概要

リロード機能は，展開ディレクトリ形式のJ2EEアプリケーションを使用している場合に使用できます。リロード機能を使用することで，J2EEサーバを再起動することなく，デプロイ済みのサーブレット，JSPやEJB-JARを動的に入れ替えられるようになります。

また，リロード機能を使用する場合には，通常のJ2EEアプリケーションの入れ替えで必要となる，入れ替え前のJ2EEアプリケーションの停止と削除，入れ替えるJ2EEアプリケーションのインポートとデプロイなどの手順が不要になります。このため，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。J2EEアプリケーションの入れ替えについては，「19.6.1　J2EEアプリケーション入れ替えの概要」を参照してください。

＜この項の構成＞

(1)　J2EEアプリケーションのリロード方法

(2)　リロードの適用範囲

(3)　リロード時のクラスローダの構成

(4)　エラー発生時の動作

(5)　リロードの注意事項および制限事項

(1)　J2EEアプリケーションのリロード方法

J2EEアプリケーションのリロードには，更新検知によるリロードと，コマンドによるリロードの2種類の方法があります。

(a)　更新検知によるリロード

更新検知によるリロードは，J2EEアプリケーション開発時のテストを支援する機能として利用できます。更新検知によるリロードを次の図に示します。

図7-6　更新検知によるリロード

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）が更新された場合に，J2EEサーバがJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視し，構成ファイルの更新を検知すると，J2EEアプリケーションのリロードを実行します。J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図7-7　更新検知によるリロードの処理の流れ

図中の1.～10.について説明します。

J2EEアプリケーションの構成ファイルを更新します。
展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。

J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視していて，構成ファイルが更新されると更新を検知します。J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔は，更新検知インターバルとして設定します。更新検知インターバルについては，「7.5.3　J2EEアプリケーションの更新検知インターバル」を参照してください。

更新を検知したあと，更新するファイルをロードします。このとき，ファイルのコピー中にロードが開始されてしまい，ロードに失敗することがあります。これを回避するため，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間を構成ファイル更新用インターバルとして設定しておくことができます。構成ファイル更新用インターバルについては，「7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル」を参照してください。

JSPを更新した場合には，JSPの再コンパイル，またはクラスファイルの監視によって更新が検知されます。JSPのリロードについては，「7.5.6　JSPのリロード」を参照してください。

リクエスト処理を閉塞します。
構成ファイルの更新を検知し，構成ファイル更新用インターバルで指定した時間を経過すると，J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。

EJBアプリケーション（EJB-JAR）の場合
新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。

Webアプリケーション（WAR）の場合
新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。このとき，リロード遅延実行機能を使用すると，リロードの開始処理を遅らせることができます。リロード遅延実行については，「7.5.5(1)　Webアプリケーションのリロード遅延実行」を参照してください。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

J2EEアプリケーションの終了処理をします。
リロードを実行するために，J2EEアプリケーションを終了します。終了処理では，次の処理が実施されます。

リロード前のクラスローダにローディングされたサーブレットのインスタンスが破棄されます。サーブレットがdestroyメソッドを実装している場合，destroyメソッドが実行されます。また，JSPファイルから生成されたサーブレットのインスタンスも破棄されます。このとき，JSPファイルがjspDestroyメソッドを実装していると，jspDestroyメソッドが実行されます。

javax.servlet.ServletContextに登録されたオブジェクトは破棄されます。

リロード前のクラスローダにローディングされたEJBのインスタンスが破棄されます。このとき，次のEJBのコールバックメソッドが実行されます。

分類
実行されるメソッド

Stateless Session Beanの場合
ejbRemove
PreDestroy

Stateful Session Beanの場合
ejbRemove
PreDestroy

Entity Beanの場合
unsetEntityContext

Message-driven Beanの場合
ejbRemove

セッション情報をシリアライズし，セッション情報ファイルに出力します。
Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を，リロード後も継続して利用できます。セッション情報の引き継ぎについては，「7.5.5(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ」を参照してください。

J2EEアプリケーション単位のクラスローダを新規に作成します。
J2EEアプリケーションのリロード処理が実行されると，J2EEアプリケーション単位のクラスローダが新たに作成され，リロード後のリクエスト処理で使用されます。

セッション情報ファイルからセッション情報を読み込み，デシリアライズします。
Webアプリケーションをリロードする場合は，セッション情報ファイルに出力されたセッション情報を新しいクラスローダに読み込みます。

セッション情報ファイルを削除します。

J2EEアプリケーションの開始処理をします。

リロード後は，初回アクセス時に更新後のサーブレットのインスタンスが作成され，initメソッドが実行されます。

開始処理では，プールの最小値分のEJBを生成してプーリングします。このとき，次のEJBのコールバックメソッドが実行されます。

分類
実行されるメソッド

Stateless Session Beanの場合
setSessionContext
ejbCreate
PostConstruct

Entity Beanの場合
setEntityContext

Message-driven Beanの場合
setMessageDrivenContext
ejbCreate

リクエストの閉塞を解除し，リクエストの処理を再開します。
3.で実行待ちにしていたリクエストの処理を再開します。

(b)　コマンドによるリロード

コマンドによるリロードは，J2EEアプリケーション開発時のテストを支援する機能，またはシステムの運用時にJ2EEアプリケーションの入れ替えを支援する機能として利用できます。コマンドによるリロードを次の図に示します。

図7-8　コマンドによるリロード

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）を更新した場合に，ユーザがcjreloadappコマンドを実行します。J2EEサーバは，cjreloadappコマンドを契機にJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図7-9　コマンドによるリロードの処理の流れ

図中の1.～4.について説明します。5.以降の手順については，更新検知によるリロードの場合と同じです。5.以降の手順については，「(a)　更新検知によるリロード」を参照してください。

J2EEアプリケーションの構成ファイルを更新します。
展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。

cjreloadappコマンドを実行します。

cjreloadappコマンドを契機に，J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。

リクエスト処理を閉塞します。
J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。

EJBアプリケーション（EJB-JAR）の場合
新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。

Webアプリケーション（WAR）の場合
新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(2)　リロードの適用範囲

リロードの対象として指定できるアプリケーションの種類を次の表に示します。

表7-3　リロードの対象として指定できるアプリケーションの種類

アプリケーションの種類 | 適用の有無 | 制限事項
EJBアプリケーション（EJB-JAR） | Stateless Session Bean | △ | リロード中の新規リクエストはエラーになります。なお，CTMを利用している場合は，リロード中の新規リクエストは実行待ちになります。
Stateful Session Bean | △ | リロード中の新規リクエストはエラーになります。また，リロードするとアプリケーションの状態が破棄されるため，アプリケーション開始前の状態になります。
Entity Bean | △ | リロード中の新規リクエストはエラーになります。
Message-driven Bean | △
Webアプリケーション（WAR） | サーブレット | ○ | －
JSP | ○ | －
ライブラリJAR | － | ○ | －

（凡例）

○：リロードの対象として指定できる

△：リロードの対象として指定できるが，制限事項がある

－：該当しない

リロードの適用範囲は，次の範囲で指定できます。

app：EJBアプリケーション（EJB-JAR）とWebアプリケーション（WAR）をリロードの対象とする。

web：Webアプリケーション（WAR）だけをリロードの対象とする。

jsp：JSPだけをリロードの対象とする。

注　app，web，jspは，usrconf.propertiesのejbserver.deploy.context.reload_scopeキーの指定値です。なお，noneを指定した場合は，リロード機能は無効になります。

appを指定した場合

EJBアプリケーションを更新すると，EJBアプリケーション，サーブレット，およびJSPがリロードされます。

サーブレットを更新するとサーブレットとJSPがリロードされます。

JSPを更新するとJSPがリロードされます。

webを指定した場合

サーブレットを更新するとサーブレットとJSPがリロードされ，JSPを更新するとJSPがリロードされます。

サーブレットがあってJSPがない場合は，サーブレットだけがリロードされます。JSPがあってサーブレットがない場合は，JSPだけがリロードされます。

EJBアプリケーションを更新してもリロードは動作しません。

jspを指定した場合

JSPを更新するとJSPがリロードされます。

EJBアプリケーションまたはサーブレットを更新しても，リロードは動作しません。

なお，リロード機能の有効／無効は，usrconf.propertiesのejbserver.rmi.localinvocation.scopeキーで指定するローカル呼び出し最適化機能の適用範囲と，リロード機能の適用範囲の組み合わせによって決まります。ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応を次の表に示します。

表7-4　ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応

項目 | ejbserver.rmi.localinvocation.scopeキーの値
all | app | none
ローカル呼び出し最適化の範囲 | 同一J2EEサーバ内となります。 | 同一アプリケーション内となります。 | 範囲はありません。
ejbserver.deploy.context.reload_scopeキーの値 | app | 　×※ | ○ | ○
web | ○ | ○ | ○
jsp | ○ | ○ | ○
none | × | × | ×

（凡例）○：リロード機能を使用できる　×：リロード機能を使用できない

注※　設定に誤りがあります。ejbserver.rmi.localinvocation.scope=allの場合にejbserver.deploy.context.reload_scope=appを指定すると，J2EEサーバを起動するときにメッセージが出力されて起動に失敗します。

(3)　リロード時のクラスローダの構成

リロード時のクラスローダの構成は，ローカル呼び出し最適化の範囲によって異なります。ローカル呼び出し最適化の範囲とクラスローダの構成の対応を次の表に示します。なお，クラスローダの構成については，「付録H　クラスローダの構成」を参照してください。

表7-5　ローカル呼び出し最適化の範囲とクラスローダの構成の対応

項目 | ejbserver.rmi.localinvocation.scopeキー※の値
all | app | none
ローカル呼び出し最適化の範囲 | 同一J2EEサーバ内となります。 | 同一アプリケーション内となります。 | 範囲はありません。
クラスローダ構成 | ローカル呼び出し最適化時のクラスローダ構成になります。 | デフォルトのクラスローダ構成になります。 | デフォルトのクラスローダ構成になります。

注※　usrconf.propertiesに指定するキーです。

リロード機能では，ApplicationClassLoader以下，またはWebappClassLoader以下のクラスローダを入れ替えます。EJB-JARをリロードする場合，デフォルトのクラスローダ構成で，次のファイルをロードします。

ApplicationClassLoaderでは，J2EEアプリケーションに含まれるEJB-JAR，ライブラリJAR，および参照ライブラリをロードします。

WebappClassLoaderでは，J2EEアプリケーションに含まれるWARをロードします。

JasperLoaderでは，J2EEアプリケーションに含まれるJSPをロードします。

EJB-JARをリロードするためにApplicationClassLoaderを入れ替える場合は，下位にあるWebappClassLoader，およびJasperLoaderも入れ替える必要があります。したがって，EJB-JAR，ライブラリJAR，参照ライブラリをリロードする場合は，WARを含めたリロードになります。

(4)　エラー発生時の動作

リロード機能の使用中にエラーが発生した場合の動作を次の表に示します。

表7-6　リロード機能でのエラー発生時の動作

エラーの内容
結果

リロード中（アプリケーション内で処理しているリクエストがない状態）にリクエストがサーバに来た場合
EJB-JARの場合はクライアントにエラーが返ります。WARの場合，新規リクエストはリロードが完了するまで実行待ちとなります。

リロード中に例外が発生した場合（クラスファイルのロードの失敗を含む）
更新検知は停止しないで，アプリケーションを停止します。更新を検知した場合，停止したJ2EEアプリケーションは再び開始されます。

リロード以外の処理（更新チェック中，構成ファイル更新用インターバル中，リロード遅延実行中）で例外が発生した場合
更新検知は停止しないで，J2EEアプリケーションは開始状態のまま監視を続けます。

J2EEアプリケーションのメソッドがハングアップなどで終了しない場合
J2EEアプリケーション実行時間の監視でメソッドをキャンセルしないとリロードできません。また，cjreloadappコマンドを使用しないとリロードできません。
J2EEアプリケーション実行時間の監視については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(5)　リロードの注意事項および制限事項

リロードに関する注意事項および制限事項を次に示します。

(a)　リロード機能の使用に関する注意事項

J2EEアプリケーションの削除について
リロードに失敗しているJ2EEアプリケーションを削除する場合は，次のどちらかの方法で削除してください。

更新検知によるリロード，またはcjreloadappコマンドによるリロードを再度実行してください。リロードが成功したら，J2EEアプリケーションを停止して削除してください。

J2EEサーバを再起動したあとで，J2EEアプリケーションを削除してください。

削除後，J2EEアプリケーションを再インポートしてください。

メモリ不足の発生について
リロード処理では，クラスローダを再作成してクラスをロードし直すため，メモリを多く消費します（消費するメモリ使用量は，J2EEアプリケーションの実装に依存します）。このため，例えば，複数のWebアプリケーションで同時にリロード処理を繰り返すとメモリ不足が発生する可能性があります。また，リロード処理によって不要となったリソースがJavaVMから解放されるタイミングは，JavaVMのガーベージコレクションの実行タイミングに依存します。リクエストのピーク時など，負荷が高いときにリロードを繰り返すと，ガーベージコレクションを実行するタイミングがなく，メモリ不足が発生する可能性が高くなります。
このため，リクエストのピーク時など負荷が高い場合には，リソースの更新は避けてください。

メソッドキャンセルの実行について
処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。メソッドキャンセルを実行しても，処理をキャンセルできない場合には，J2EEサーバを再起動してください。

実行待ちとなっているリクエスト処理の再開について
J2EEアプリケーションのリロードでEJBアプリケーションの開始，または停止に失敗した場合，Webアプリケーションのリロード処理開始以降の新規リクエストは実行待ちとなります。実行待ちとなっているリクエスト処理を再開するためには，EJBアプリケーションを更新してリロードを実行し，リロード処理を成功させてください。Webアプリケーションを更新しても，リロードは実行されません。

J2EEアプリケーションに含まれるRARファイルについて
アプリケーションディレクトリにRARファイルを含めている場合，RARファイルはリロード機能の対象にはなりません。RARファイルを更新した場合は，更新したRARファイルを含むJ2EEアプリケーションを，サーバ管理コマンドを使用して入れ替えてください。サーバ管理コマンドを使用してJ2EEアプリケーションを入れ替える手順については，マニュアル「Cosminexus　システム運用ガイド」のJ2EEアプリケーションの入れ替えについての説明を参照してください。

(b)　EJBアプリケーション（EJB-JAR）の注意事項

リロード後にEJBを呼び出す場合には，クライアント側のソースコードでEJBHomeやビジネスインタフェースを取得し直す必要があります。リロード前に取得したインタフェース経由でEJBにアクセスした場合は例外が返ります。また，リロード実行中にEJBにアクセスした場合も例外が返ります。

リモートインタフェースまたはリモートビジネスインタフェースを入れ替えた場合，クライアント側ではスタブを取得し直す必要があります。

リロードを実行すると，Stateful Session Beanのクライアントとのセッションの状態は失われます。

(c)　EJBアプリケーション（EJB-JAR）の制限事項

これまでjavax.ejb.TimedObjectインタフェースを実装していなかったEJBで，javax.ejb.TimedObjectインタフェースを実装するように変更して，リロードすることはできません。リロードした場合には，次のようになります。

更新検知スレッドは停止させないで，J2EEアプリケーションを停止します。

更新を検知した場合，停止したJ2EEアプリケーションは再び開始されます。

CMRを使用したアプリケーションはリロードできません。

(d)　Webアプリケーション（WAR）の注意事項

タグライブラリ記述子ファイルのlistenerタグの変更内容は，リロード後に反映されません。

リロード時に利用できるサーブレットとJSPは，リロード後も状態を継続して利用できます。永久的に利用できないとされている場合は，リロード後も永久的に利用できません。一時的に利用できない場合は，リロードの実行とは関係なく，指定した期間後に利用できるようになります。

Webアプリケーションでリロード監視対象になっているファイルを削除した場合，そのファイルは監視対象外となります。このため，再度ファイルを追加しても更新検知によるリロードは実行されません。ただし，/WEB-INF/lib下にJARファイルを追加した場合は，そのJARファイルが削除後に再度追加されたかどうかに関係なく，コマンドによるリロードまたは更新検知によるリロードを実行できます。

JSPのリロード処理中にJ2EEアプリケーションを停止した場合，またはWebアプリケーションをリロードした場合，JSPのリロード処理は中止されます。

JSPのリロード処理開始時，ログの出力レベルがErrorの場合は，メッセージKDJE39310-Iに，更新されたファイル名とリロードを実行するJSPファイルのファイル数が出力されます。ログの出力レベルがWarningの場合は，メッセージKDJE39312-Iに，リロードを実行するすべてのJSPファイル名が出力されます。

リスナクラスのロード，インスタンス生成時に例外が発生した場合，Webコンテナは例外が発生したリスナを無効としてリロード処理を続行します。例外が発生したリスナを有効にするには，該当のリスナを修正して再度リロードを実行してください。

フィルタクラスのロード，インスタンス生成，initメソッド実行で例外が発生した場合，Webコンテナは例外が発生したフィルタを無効としてリロード処理を続行します。例外が発生したフィルタを有効にするには，該当のフィルタを修正して再度リロードを実行してください。

Webアプリケーションのリロード処理を実行すると，次の表に示すリスナインタフェースのメソッドが実行されます。

表7-7　Webアプリケーションのリロード処理で実行されるリスナのメソッド

インタフェース名 | メソッド名
javax.servlet.ServletContextListener | contextDestroyed()
contextInitialized()
javax.servlet.ServletContextAttributeListener | attributeRemoved()
attributeAdded()
javax.servlet.http.HttpSessionActivationListener※ | sessionWillPassivate()
sessionDidActivate()

注※　javax.servlet.http.HttpSessionオブジェクトが存在しないときは実行しません。

リロード処理時間は，Webアプリケーションの実装に大きく依存します。このため，次の点に注意が必要です。

セッション情報の容量は，シリアライズ処理時間，デシリアライズ処理時間に大きく影響します。シリアライズ対象となるセッション情報は，必要十分な容量にしてください。

リロード処理では，Webアプリケーションの終了処理，初期化処理が実行されます。終了処理，初期化処理が長い場合，リロードの処理時間も長くなり，Webアプリケーションのサービス停止期間にも影響があるため注意してください。ただし，リロード処理で初期化処理が実行されるのは，web.xmlの<load-on-startup>タグを設定したサーブレットやJSPだけです。<load-on-startup>タグを設定していないサーブレットやJSPの初期化処理は，リロード完了後の初回アクセス時に実行されます。

Webアプリケーションのリロード機能は，Webアプリケーション単位のクラスローダを入れ替えることによって，サーバ起動中のWebアプリケーションの入れ替えを実現しています。そのため，リロード後にリロード前のWebアプリケーション単位のクラスローダ，またはWebアプリケーション単位のクラスローダでロードされたクラスが参照されるとメモリリークが発生します。
次に，該当する場合を示します。リロード機能を使用する場合は，Webアプリケーション内でこれらのことをしないでください。

スレッドの生成
スレッドはコンテキストクラスローダを保持しますが，デフォルトでは親スレッドのコンテキストクラスローダを保持します。Webアプリケーション実行時のスレッドは，Webアプリケーション単位のクラスローダをコンテキストクラスローダとしているため，生成されたスレッドはWebアプリケーション単位のクラスローダをコンテキストクラスローダとします。そのため，リロード後も該当スレッドが存在すると，リロード前のWebアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

java.lang.Threadクラスまたはその派生クラスのインスタンス生成
java.lang.Threadクラスまたはその派生クラス（以降，スレッドクラス）のインスタンスを作成すると，所属するスレッドグループから該当スレッドクラスのインスタンスが参照されます。スレッドグループからの参照は，スレッドの実行を終了（runメソッドの完了）すると解放されます。そのため，Webアプリケーション内でスレッドクラスのインスタンスを生成し，runメソッドを実行しなかった場合は，該当スレッドクラスのインスタンスが解放されません。また，スレッドはコンテキストクラスローダとしてWebアプリケーション単位のクラスローダを保持しているため，Webアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

スレッドローカル変数の使用
Webコンテナではリクエストを処理するスレッドはプールされていて，Webコンテナ終了時まで終了しません。そのため，スレッドローカル変数にWebアプリケーションに含まれるクラスのインスタンスを格納すると，メモリリークが発生します。

JSP事前コンパイル機能を使用している場合，JSPファイルまたはタグファイルが依存するファイルは更新検知対象となったあと，次のどれかの条件を満たすときに更新検知対象から除外されます。

JSPファイルまたはタグファイルを，依存するファイルを使用しないように変更したクラスファイルに更新し，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

JSPファイルまたはJSPファイルが依存するファイルから生成されたクラスファイルを更新し，JSPファイルから生成されたクラスのロードでエラーが発生した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

該当するファイルが更新検知対象から除外された場合，メッセージログにKDJE39319-Iが出力されます。
なお，cjjspcコマンドを実行すると依存するファイルを使用しているJSPファイルまたはタグファイルも再度コンパイルされます。クラスファイルを展開ディレクトリ以外で作成したあとに更新する場合は，cjjspcコマンドで生成されたクラスファイルをすべて更新してください。

JSP事前コンパイル機能を使用していない場合，JSPファイルまたはタグファイルが依存するファイルは更新検知対象となったあと，次のどれかの条件を満たすときに更新検知対象から除外されます。

JSPファイルまたはタグファイルを，依存するファイルを使用しないように修正し，コンパイルが正常に完了した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

JSPファイル，またはJSPファイルが依存するファイルを更新し，JSPファイルのコンパイルエラーが発生した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

該当するファイルが更新検知対象から除外された場合，メッセージログにKDJE39318-Iが出力されます。また，JSPファイルのコンパイルエラーが発生し，かつ次の条件を満たすときは，更新検知対象から除外されたファイルだけを修正することで，コンパイルエラーとなったJSPファイルを修正しないで，JSPのリロードを実行できます。

依存するファイルがタグファイルの場合
タグファイルの記述内容とタグファイルを使用するファイルの記述内容が矛盾している。タグファイルの次の属性のどれかが不正である。
tagディレクティブに定義した属性：body-content，またはdynamic-attributes
attributeディレクティブに定義した属性：name，required，fragment，rtexprvalue，またはtype
variableディレクティブに定義した属性：name-given，variable-class，declare，またはscope

依存するファイルがweb.xmlの<include-prelude>，または<include-coda>に指定した暗黙的にincludeされるファイルの場合
暗黙的にincludeされたファイルの記述内容が，includeするJSPファイルの記述内容と矛盾している。

依存するファイルがincludeディレクティブに指定したファイルの場合
includeディレクティブに指定されたファイルの記述内容が，includeディレクティブを指定したJSPファイルまたはタグファイルの内容と矛盾している。

依存するファイルがタグライブラリ・ディスクリプタ（TLD）ファイルの場合
TLDファイルの記述内容とJSPファイルの記述内容が矛盾している。

この場合，該当するファイルは更新検知の対象外となっているため，依存するファイルを更新したあと，次のどれかを実行しJSPのリロードを実行する必要があります。

依存するファイルを使用するJSPファイルにブラウザなどからアクセスする。

依存するファイルを使用するJSPファイルまたはタグファイルの更新日時を更新する。

7.5.2　更新検知の対象となるファイル

クラスローダによってロードされるファイルのうち，監視対象のファイルが更新されたときに，J2EEサーバが更新を検知してリロードが実行されます。更新検知の対象となるタイミングは，J2EEアプリケーションの開始時です。

ただし，クラスローダでロードされていないファイルは，更新検知の対象になりません。アプリケーションディレクトリ以下にあってもロードされていないファイルや，アプリケーションディレクトリを使用していないJ2EEアプリケーションのファイルは，更新検知の対象になりません。また，DD（ejb-jar.xml，web.xml）は，更新検知の対象になりません。

＜この項の構成＞

(1)　更新検知の対象ファイル

(2)　更新検知の対象ファイルの例

(3)　リロードの対象となる操作

(1)　更新検知の対象ファイル

更新検知の対象ファイルを次の表に示します。

表7-8　更新検知の対象ファイル

種別
更新検知の対象ファイル
リロードの適用範囲※1

app
web
jsp

アプリケーションディレクトリ以下のファイル

ライブラリJAR

○
－
－

EJB-JARディレクトリ以下のEJBアプリケーション（EJB-JAR）のファイル

クラスファイル

java.util.ResourceBundleによってロードされたプロパティファイル

○
－
－

WARディレクトリ以下のWebアプリケーション（WAR）のファイル
サーブレット

クラスファイル

JARファイル

java.util.ResourceBundleによってロードされたプロパティファイル

○
○
－

JSP

JSPファイル

○※2
○※2
○※2

タグファイル

タグライブラリ記述子

○※3
○※3
○※3

JSPコンパイル結果

タグファイルコンパイル結果

○※4
○※4
○※4

静的コンテンツ

○※5
○※5
○※5

アプリケーションディレクトリ以外のファイル

参照ライブラリ

○
－
－

（凡例）○：更新検知の対象になる　－：更新検知の対象にならない

注※1

リロードの適用範囲のapp，web，jspは，usrconf.propertiesのejbserver.deploy.context.reload_scopeキーの指定値です。

注※2

JSPの事前コンパイルがされていない状態で，ロード済みの場合に，更新検知の対象になります。

注※3

JSPの事前コンパイルがされていない状態で，ロード済みのJSPファイルまたはタグファイルで使用されている場合に，更新検知の対象になります。

注※4

JSPの事前コンパイルがされている場合に，更新検知の対象になります。

注※5

JSPファイルまたはタグファイルが依存するファイルの場合に，更新検知の対象になります。依存するファイルは，JSPファイルまたはタグファイルのincludeディレクティブでインクルードされるファイルや，web.xmlの<include-prelude>または<include-coda>でインクルードされるファイルのことです。

(2)　更新検知の対象ファイルの例

アプリケーションディレクトリ以下のファルのうち，更新検知の対象となるファイルの例を次の表に示します。

表7-9　更新検知の対象ファイルの例

ディレクトリ
ディレクトリ下のファイル
更新検知の対象

<アプリケーションディレクトリ>
ライブラリJAR
例：MyLibrary.jar
○

META-INF
J2EEアプリケーションのDD（application.xml）
－

<EJB-JARディレクトリ>
－
－

META-INF
EJB-JARのDD（ejb-jar.xml）
－

<パッケージ名>
Enterprise Beanクラス
例：MyEJB.class
○

ホームインタフェースクラス
例：MyEJBHome.class
○

コンポーネントインタフェースクラス
例：MyEJBRemote.class
○

ビジネスインタフェースクラス
例：MyBusiness.class
○

EJBから利用されるクラス
例：MyClass.class
○

java.util.ResourceBundleによってロードされたプロパティファイル
例：MyResource.properties
○

<WARディレクトリ>
JSPファイル
例：MyJsp.jsp
○

静的コンテンツ
例：MyStatic.jspf
○

HTMLファイル
例：MyIndex.html
－

META-INF
－
－

WEB-INF
WebアプリケーションのDD（web.xml）
－

タグライブラリ記述子ファイル
例：MyTaglib.tld
○

Webアプリケーションプロパティファイル（hitachi_web.properties）
－

classes
－
－

<パッケージ名>
java.util.ResourceBundleによってロードされたプロパティファイル
例：MyResource.properties
○

サーブレットクラス
例：MyServlet.class
○

lib
JARファイル
例：MyLibrary.jar
○

tags
タグファイル
例：MyTag.tag
○

<JSPワークディレクトリ>
JSPコンパイル結果
例：MyJsp$jsp.class
○

WEB-INF
tags
タグファイルコンパイル結果
例：MyTag$tag.class
○

<アプリケーションディレクトリ以外のディレクトリ>
参照ライブラリ
例：MyRef.jar
○

（凡例）　○：更新検知の対象になる　－：更新検知の対象にならない

(3)　リロードの対象となる操作

監視対象のファイルを変更した場合に，更新が検知されてリロードが実行されるかどうかは，ファイルへの操作によって異なります。リロードの対象となる操作を次の表に示します。

表7-10　リロードの対象となる操作

更新検知の対象ファイル
ファイルへの操作
注意点

追加
削除
更新

アプリケーションディレクトリ以下のファイル
ライブラリJAR
×
×
○

ライブラリJARの名称は変更できません。

ライブラリJARの構成は変更できます。

EJB-JARディレクトリ以下のEJBアプリケーション（EJB-JAR）のファイル
EJBを構成するクラスファイル
×
×
○

アノテーションも読み込まれます。※1

クラス名の変更はできません。

これまで参照していなかったクラスを参照するように更新した場合，参照先のクラスファイルもリロードの対象となります。

ほかのクラスファイル
×
×
○

アノテーションも読み込まれます。※1

これまで参照していなかったクラスを参照するように更新した場合，参照先のクラスファイルもリロードの対象となります。

WARディレクトリ以下のWebアプリケーション（WAR）のファイル
クラスファイル
△
○
○
－

JARファイル
○
○
○
－

プロパティファイル
△
○
○
－

JSPファイル
△
○※2
○※2
－

タグファイル
△
○※2
○※2

JARファイル内にあるタグファイルは除きます。

JSPファイルまたはタグファイルが依存するファイル
△
○※2
○※2
－

静的コンテンツ
△
×
×

リロード機能を使用した場合には，キャッシュが無効になります。

JSPコンパイル結果（JSP，タグファイルをコンパイルして生成されたクラスファイル）
△
○
○

JSPの事前コンパイル機能が有効である必要があります。

アプリケーションディレクトリ以外のファイル
参照ライブラリ
×
×
○

参照ライブラリの名称は変更できません。

参照ライブラリが指すJARファイルの構成およびクラスパス内のファイルの更新はできます。

スタブおよびコンテナ生成クラスの再生成が必要な場合には，再生成されます。

（凡例）

○：リロードが実行される

△：操作はできるが，リロードは実行されない

×：リロードが実行されない

注※1

更新できるアノテーションと更新できないアノテーションがあります。アノテーションについては，「5.2.4　Enterprise Beanのアノテーション指定」を参照してください。

注※2

JSPの事前コンパイル機能が有効な場合は，△になります。

7.5.3　J2EEアプリケーションの更新検知インターバル

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視していて，構成ファイルが更新されると更新を検知します。J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔は，更新検知インターバルとして設定します。更新検知インターバルを次の図に示します。

図7-10　更新検知インターバル

更新検知インターバルの値を大きくすると，構成ファイルを監視する間隔が長くなり，ファイル更新後のリロードの反映が遅くなります。また，値を小さくすると，リロードの反映が早くなります。

ポイント

更新検知の対象となるファイル数が増えると，更新検知処理のオーバーヘッドが大きくなり，CPU使用率が高くなります。このような場合は，更新検知インターバルを変更することによって，性能への影響が小さくなります。更新検知インターバルの値は大きくすることをお勧めします。

更新検知インターバルは，J2EEアプリケーション，Webアプリケーション，およびJSPでそれぞれ設定できます。設定値の関係を次に示します。

EJBアプリケーションの場合

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）が使用されます。なお，J2EEアプリケーションの更新検知インターバルに0を指定している場合，EJBアプリケーションは更新検知されません。

サーブレットの場合

WebアプリケーションまたはJ2EEアプリケーションの更新検知インターバルが使用されます。優先順位を次に示します。

Webアプリケーションの更新検知インターバル（webserver.context.check_interval）

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）

なお，Webアプリケーションの更新検知インターバルを指定していない場合には，J2EEアプリケーションの更新検知インターバルが使用されます。

また，Webアプリケーションの更新検知インターバルに0を指定している場合，サーブレットは更新検知されません。

JSPの場合

JSPまたはJ2EEアプリケーションの更新検知インターバルが使用されます。優先順位を次に示します。

JSPの更新検知インターバル（webserver.jsp.check_interval）

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）

なお，JSPの更新検知インターバルを指定していない場合には，J2EEアプリケーションの更新検知インターバルが使用されます。

また，JSPの更新検知インターバルに0を指定している場合，JSPは更新検知されません。

7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル

J2EEサーバは，構成ファイルの更新を検知すると処理中のリクエスト数の監視を開始し，処理中のリクエストの処理が完了するとファイルをロードします。ファイルの容量が大きい場合，ネットワークを経由した場合や，ファイルが複数ある場合には，ファイルコピーなどの処理時間が長くなることがあります。このとき，ファイルコピーが完了する前に処理中のリクエストがなくなると，ファイルコピー中にロードが開始されて，ロードに失敗するおそれがあります。これを回避するため，ファイルコピーに掛かる時間を考慮し，コピーが完了してからロードが開始されるように，構成ファイル更新用インターバルを設定しておくことができます。構成ファイル更新用インターバルでは，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間を設定します。構成ファイル更新用インターバルを次の図に示します。

図7-11　構成ファイル更新用インターバル

ポイント

構成ファイル更新用インターバルには，実際に掛かるコピー時間にゆとりを持たせた時間を設定することをお勧めします。

複数のファイルを同時に更新する場合は，複数のファイルの更新に掛かる時間を算出して，構成ファイル更新用インターバルを設定してください。

構成ファイル更新用インターバルは，J2EEアプリケーション，Webアプリケーション，およびJSPでそれぞれ設定できます。設定値の関係を次に示します。

EJBアプリケーションの場合

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）が使用されます。

サーブレットの場合

WebアプリケーションまたはJ2EEアプリケーションの構成ファイル更新用インターバルが使用されます。優先順位を次に示します。

Webアプリケーションの構成ファイル更新用インターバル（webserver.context.update.interval）

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）

Webアプリケーションの構成ファイル更新用インターバルを指定していない場合には，J2EEアプリケーションの構成ファイル更新用インターバルが使用されます。

JSPの場合

JSPまたはJ2EEアプリケーションの構成ファイル更新用インターバルが使用されます。優先順位を次に示します。

JSPの構成ファイル更新用インターバル（webserver.jsp.update.interval）

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）

JSPの構成ファイル更新用インターバルを指定していない場合には，J2EEアプリケーションの構成ファイル更新用インターバルが使用されます。

7.5.5　Webアプリケーションのリロード

Webアプリケーションをリロードする場合には，リロード遅延実行機能を使用することで，J2EEアプリケーションのサービス停止期間を最小限に抑えることができます。また，Webアプリケーションのリロードでは，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用することができます。ここでは，Webアプリケーションのリロード遅延実行とセッション情報の引き継ぎについて説明します。

＜この項の構成＞

(1)　Webアプリケーションのリロード遅延実行

(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ

(1)　Webアプリケーションのリロード遅延実行

デフォルトでは，構成ファイルの更新を検知すると，次のような手順でリロード処理を実行します。

Webアプリケーションのリクエスト処理を閉塞します。
構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，次のようにリクエストを処理します。

新規リクエスト：実行待ちにします。

処理中のリクエスト：処理を続行します。

処理中のリクエストの処理が完了すると，リロードを実行します。

この場合，処理中のリクエストの処理時間が長くなるほど，新規リクエストの処理開始時間が遅くなり，新規リクエストに対するアプリケーションのサービス停止期間が長くなります。これを回避するために，リロード遅延実行を設定しておくことをお勧めします。リロード遅延実行機能を使用すると，処理中のリクエストの実行待ち時間を減らして，アプリケーションのサービス停止期間を最小限に抑えられます。

リロード遅延実行機能では，この機能を使用するかどうか，およびリロード処理を開始するまでの時間（最大遅延時間）を設定します。リロード遅延実行機能を使用すると，処理中のリクエストの処理が終わるまで，新規リクエストを受け付けることができます。処理中のリクエスト数が0になると，リロード処理を開始して新規リクエストを実行待ちにします。ただし，処理中のリクエスト数が0になるかどうかは，アクセス状況に依存します。リクエストが途切れない場合には，リロード処理を開始できません。このような場合には，構成ファイルの更新を検知してから，新規リクエストを実行待ちにするまでの最大遅延時間を設定します。最大遅延時間を経過すると，それ以降の新規リクエストは実行待ちとなり，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。

リロード遅延実行を設定した場合と設定しない場合の，アプリケーションのサービス停止期間の違いを，次の図に示します。

図7-12　アプリケーションのサービス停止期間の違い

リロード遅延実行の最大遅延時間を設定している場合には，構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，リロード遅延実行の最大遅延時間のカウントを開始します。例えば，最大遅延時間を5分と設定していた場合，アクセス状況によってリロード処理の開始時間が次のように異なります。

最大遅延時間を経過する前に処理中のリクエストが0になった場合
最大遅延時間のカウントを開始してから3分後に，処理中のリクエストが0になった場合には，その時点でリロード処理を開始します。また，新規リクエストを実行待ちにします。

最大遅延時間を経過した場合
リクエストが途切れないため処理中のリクエストが0にならない場合には，最大遅延時間のカウントを開始してから5分後に，新規リクエストを実行待ちにします。処理中のリクエストの処理が完了したら，リロード処理を開始します。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。J2EEアプリケーション実行時間の監視については，「7.5.7(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ

Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用します。

(a)　セッション情報ファイル

Webアプリケーションをリロードする場合，セッション情報（javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクト）をシリアライズし，セッション情報ファイルに出力します。セッション情報ファイルからセッション情報を読み込み，リロード後のクラスローダ上でデシリアライズします。なお，シリアライズ処理，およびデシリアライズ処理の時間は，リロードを実行しているWebアプリケーション上で生成されたセッション数，javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクトの容量などに依存します。

注意

シリアライズ対象となるセッションに登録したオブジェクトのクラス，およびそこから参照されるオブジェクトのクラスを，デシリアライズできない構成に更新してリロードを実行した場合，セッションのデシリアライズに失敗します。デシリアライズに失敗すると，Webアプリケーション上のすべてのセッション情報が破棄されます。

セッション情報ファイルは，リロード処理開始時に作成され，リロード処理完了時に削除されます。リロード実行時にセッションが存在しない場合でもセッション情報ファイルは作成されます。

セッション情報ファイルには，Webコンテナが自動生成する情報（2キロバイト）とセッション情報が出力されます。セッション情報は，セッション数とセッションに登録したセッション情報（オブジェクト）に依存します。

セッション情報ファイルのファイル容量は，リロード時に出力されるシリアライズ処理完了のメッセージからファイル容量を確認し，セッション数に応じて算出してください。シリアライズ処理完了時のメッセージの出力例を次に示します。

KDJE39168-I The serialization of session objects has finished. (J2EE application = app1, context root = /examples, number of sessions = 10, session information file size(byte) = 12345)

この出力例では，コンテキストルート名が「examples」のWebアプリケーション「app1」上に10個のセッションがあり，セッション情報ファイルのサイズは，12,345バイトです。

(b)　セッション情報を引き継ぐ場合の注意事項

リロード時のセッション引き継ぎ機能を使用する場合，javax.servlet.http.HttpSessionに登録するセッション情報は，シリアライズできるオブジェクトである必要があります。

HttpSessionオブジェクトに登録したオブジェクトから参照するオブジェクトは，transientで宣言されているか，またはシリアライズできるオブジェクトである必要があります。以降，参照するオブジェクトも同様です。シリアライズできるオブジェクトについての詳細は，J2SEの仕様書を参照してください。

セッション情報としてシリアライズできないオブジェクトを登録した場合は，エラーが発生します。エラーの内容はオブジェクトによって異なります。

javax.servlet.http.HttpSessionに登録したオブジェクトの場合
HttpSessionオブジェクトに登録したオブジェクトが，シリアライズできないオブジェクトである場合，該当するオブジェクトだけを破棄します。破棄されたオブジェクトは，リロードが完了したあとに使用することはできません。また，該当するオブジェクトが，javax.servlet.http. HttpSessionBindingListenerインタフェースを実装していても，Webコンテナからアンバインドされたイベントは通知されません。

javax.servlet.http.HttpSessionに登録したオブジェクトから参照されるオブジェクトの場合
HttpSessionに登録したオブジェクトから参照されるオブジェクトがシリアライズできないオブジェクトの場合，すべてのセッション情報が破棄されます。HttpSessionに登録したオブジェクトから参照されるオブジェクトが，HttpSessionに登録したオブジェクトの場合も同様に，すべてのセッション情報が破棄されます。

7.5.6　JSPのリロード

JSPを更新した場合には，JSPの再コンパイル，またはクラスファイルの監視によって更新が検知され，JSPがリロードされます。JSPのリロード方法を次に示します。

JSPの再コンパイルによるリロード
Webコンテナは，ロードされたJSPファイル，タグファイル，JSPファイルまたはタグファイルが依存するファイルが更新されているかどうかをチェックし，更新日時がロード時と異なる場合には，再コンパイルしてJSPをリロードします。
更新を検知してJSPの構成ファイル更新用インターバルを経過したあとに，ファイルを再コンパイルします。コンパイルが完了し，処理中のリクエストがなくなったことを検知したら，リロード処理を開始します。

クラスファイルの監視によるリロード
Webコンテナは，WebコンテナにロードされたJSPファイルから生成されたクラスファイルが更新されているかどうかをチェックし，更新日時がロード時と異なる場合に，JSPをリロードします。
更新を検知してJSPの構成ファイル更新用インターバルを経過したあとに，処理中のリクエストがなくなったことを検知したら，リロード処理を開始します。
クラスファイルの更新のタイミングは次のどちらかです。

JSP事前コンパイルのコマンドを実行し，JSPファイルをコンパイルしてクラスファイルを生成したとき

JSP事前コンパイルでコンパイルされたクラスファイルを，JSPワークディレクトリにコピーして上書きしたとき

JSPの事前コンパイルについては，「4.7　JSPの事前コンパイルとコンパイル結果の保持」を参照してください。

JSPのリロード方法の差異を次の表に示します。

表7-11　JSPのリロード方法の差異

項目
JSPの再コンパイルによるリロードの場合
クラスファイルの監視によるリロードの場合

JSPの事前コンパイル機能使用の有無
JSP事前コンパイル機能は無効となります。
JSP事前コンパイル機能は有効となります。

更新検知の対象ファイル※

JSPファイル

タグファイル

JSPファイルまたはタグファイルが依存するファイル

JSP事前コンパイルで生成されたクラスファイル

更新検知後の処理
ファイルをコンパイルし，リロードします。
クラスファイルをリロードします。

注※

Webコンテナにロードされていないファイル，または更新検知の対象ではないファイルを更新しても検知されません。

どちらのリロード方法の場合でも，ファイルの更新を検知するために，JSPの更新検知インターバルとJSPの構成ファイル更新用インターバルを指定できます。更新検知インターバルについては，「7.5.3　J2EEアプリケーションの更新検知インターバル」を参照してください。構成ファイル更新用インターバルについては，「7.5.4　J2EEアプリケーションの構成ファイル更新用インターバル」を参照してください。

7.5.7　ほかの機能との関係

リロード機能と次の機能との関係について説明します。

同時実行スレッド数制御

J2EEアプリケーション実行時間の監視

＜この項の構成＞

(1)　リロードと同時実行スレッド数制御との関係

(2)　リロードとJ2EEアプリケーション実行時間の監視との関係

(1)　リロードと同時実行スレッド数制御との関係

Webアプリケーションのリロード機能での新規リクエストの実行待ちと，同時実行スレッド数制御との関係について説明します。なお，同時実行スレッド数の制御については，「4.17　同時実行スレッド数の制御」を参照してください。

(a)　Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御を使用する場合

リロード機能での新規リクエストの実行待ちは，Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御の実行待ちキューとは，別に制御されます。

Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されている場合
Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されているWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。

リロード機能で実行待ちとなった新規リクエストは，Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されません。実行待ちキューのサイズの上限に関係なく，実行待ちとなります。

Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されたリクエストがある場合は，実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。

リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，実行待ちキューに登録されます。実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。

Webアプリケーション単位の同時実行スレッド数制御が設定されていない場合
Webアプリケーション単位の同時実行スレッド数制御が設定されていないWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。

リロード機能で実行待ちとなった新規リクエストは，デフォルトの実行待ちキューに登録されません。デフォルトの実行待ちキューサイズの上限に関係なく，実行待ちとなります。

デフォルトの実行待ちキューに登録されたリクエストがある場合は，実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。

リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，デフォルトの実行待ちキューに登録されます。デフォルトの実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。

(b)　Webコンテナ単位の同時実行スレッド数制御を設定する場合

Webコンテナ単位の同時実行スレッド数制御を設定している場合，リロード処理開始後に，Webコンテナ単位の同時実行スレッド数制御で実行できることになった，新規リクエストの処理スレッドが実行待ちとなります。

このため，リロード機能で実行待ちとなった新規リクエスト数がWebコンテナ単位の最大同時実行スレッド数まで達した場合，リロード処理を開始したWebアプリケーション以外のWebアプリケーションへのリクエストも，Webコンテナ単位の同時実行スレッド数制御機能によって実行待ちとなります。

(2)　リロードとJ2EEアプリケーション実行時間の監視との関係

処理中のリクエストの処理が完了しない場合には，cjreloadappコマンドで-tオプションを指定することで，処理中のリクエストを強制的に終了させて，リロード処理を開始できます。ただし，処理中のリクエストを強制的に終了できるのは，J2EEアプリケーション実行時間の監視機能のメソッドタイムアウトの適用対象メソッドだけです。また，メソッドタイムアウトの発生後にメソッドキャンセルが動作するように設定している場合は，タイムアウトの発生によって処理中のリクエストがキャンセルされて，リロードを開始できます。

J2EEアプリケーション実行時間の監視の詳細については，「19.3　J2EEアプリケーション実行時間の監視とキャンセル」を参照してください。J2EEアプリケーション実行時間の監視の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(a)　EJBアプリケーションの場合

EJBアプリケーションをリロードする場合について説明します。

構成ファイル更新用インターバルを経過すると，J2EEサーバは，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図7-13　メソッドキャンセル機能によるリロード（EJBアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋処理中のリクエストの実行待ち時間（秒）

(b)　Webアプリケーションの場合

Webアプリケーションをリロードする場合について説明します。

リロード遅延実行を設定している場合，指定した最大遅延時間を経過すると，J2EEサーバは，新規リクエストを実行待ちにし，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図7-14　メソッドキャンセル機能によるリロード（Webアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋リロード遅延実行の最大遅延時間（秒）＋処理中のリクエストの実行待ち時間（秒）

8.　ネーミング管理

この章では，ネーミング管理の機能について説明します。ネーミング管理は，J2EEサービスで提供されている機能の一つです。ネーミング管理機能を使用して，Enterprise Bean参照またはリソース参照のための名前解決を実現します。

＜この章の構成＞

8.1　ネーミング管理の概要

8.2　JNDI名前空間へのオブジェクトのバインドとルックアップ

8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）

8.4　ラウンドロビンポリシーによるCORBAネーミングサービスの検索

8.5　ネーミング管理機能でのキャッシング

8.6　CORBAネーミングサービスの切り替え

8.1　ネーミング管理の概要

この節では，ネーミング管理の機能，およびネーミング管理で使用するネーミングサービスについて説明します。

＜この節の構成＞

8.1.1　ネーミング管理の機能

8.1.2　ネーミングサービス

8.1.1　ネーミング管理の機能

ネーミング管理は，J2EEサービスで提供されている機能の一つです。J2EEサービスは，J2EEコンテナの部品機能として利用される機能です。ネーミング管理では，オブジェクト（Enterprise Beanに対応するEJBホームオブジェクト，ビジネスインタフェースのリファレンスおよびJ2EEリソース）の名前と格納場所を管理しています。ネーミング管理の機能を使用することで，EJBクライアントは，呼び出すEnterprise Beanまたはリソースの格納場所を知らなくても，名前から必要なオブジェクトを利用できるようになります。

また，Connector 1.5仕様に準拠したリソースアダプタを使用する場合，管理対象オブジェクトもネーミング管理で管理されています。管理対象オブジェクトは，J2EEアプリケーションの中からメッセージの送信および同期受信をするときに使用するオブジェクトです。管理対象オブジェクトについては，「9.13.4　管理対象オブジェクトのルックアップ」を参照してください。

Cosminexusで提供するネーミング管理の機能を次の表に示します。

表8-1　Cosminexusで提供するネーミング管理の機能

機能 | 参照先
JNDI名前空間へのオブジェクトのバインドとルックアップ※ | 8.2
Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能） | 8.3
ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | 8.4
ネーミング管理機能でのキャッシング | 8.5
CORBAネーミングサービスの切り替え | 8.6

注※　ルックアップには何種類かの方法があります。ルックアップ名称および方法については，「8.2.1　ルックアップで使用する名称の種類」を参照してください。

ネーミング管理機能のJNDIでは，CORBAオブジェクトリファレンス以外のオブジェクト（RMI-IIOPのリモートオブジェクトやJDBCデータソースなどのオブジェクト）を次のように扱います。

CORBAオブジェクトリファレンス以外の登録は，対象のオブジェクトをCORBAオブジェクトに変換し，CORBAオブジェクトリファレンスをCORBAネーミングサービスへ登録することで実現しています。

CORBAオブジェクト以外のオブジェクトの検索は，CORBAオブジェクトリファレンスを検索し，CORBAオブジェクトから逆変換して元のオブジェクトを取得することで実現しています。

なお，Cosminexusで提供するネーミング管理の機能には，J2EEで規定された機能にCosminexus独自の機能を拡張したものと，Cosminexus独自の機能として提供しているものがあります。Cosminexus独自の機能かどうかについては，「2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）」を参照してください。

Cosminexusが提供するネーミング管理の機能と対象になるオブジェクトの関係を次の表に示します。

表8-2　Cosminexusが提供するネーミング管理の機能と対象になるオブジェクトの関係

機能 | Enterprise Bean | J2EEリソース
EJBホームオブジェクト | ビジネスインタフェース
JNDI名前空間へのオブジェクトのバインドとルックアップ | ○ | ○ | 　○※
Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能） | ○ | ○ | ○
ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | ○ | ○ | ×
ネーミング管理機能でのオブジェクトのキャッシング | ○ | × | ×
CORBAネーミングサービスの切り替え | ○ | × | ×

（凡例）

○：使用できる　×：使用できない

注※

自動的にバインドされる名称でのルックアップはできません。

注意

Webアプリケーションでカスタムエラーページを設定している場合，設定されたエラーページからJNDIを利用できません。

8.1.2　ネーミングサービス

ネーミング管理機能を使用する場合，オブジェクトの名前と格納場所は，ネーミングサービスによって管理されます。

Cosminexusでは，ネーミング管理の機能として，CORBAネーミングサービスを利用したJNDIをサポートしています。オブジェクトの登録，削除，または検索などのJNDIのインタフェースが呼び出されたときに，対応するCORBAネーミングサービスのインタフェースを呼び出します。したがって，ネーミング管理機能を利用するためには，CORBAネーミングサービスへの接続情報としてプロトコル，ホスト名，およびポート番号を設定する必要があります。

参考

CORBAネーミングサービスはJ2EEサーバのインプロセスで起動できます。インプロセスで起動することで，個別の起動・終了が不要になり，運用性が向上します。

8.2　JNDI名前空間へのオブジェクトのバインドとルックアップ

ルックアップの対象になるオブジェクトは，JNDI名前空間の名前と関連づけて管理されます。

J2EEサーバ内で実行するアプリケーションでは，利用したいリソースマネジャや呼び出したいEnterprise Beanなどのオブジェクトを参照するために，JNDIの名前空間で検索（ルックアップ）を実行します。

この節では，ルックアップに使用する名称の種類，バインドされる名称の規則，およびルックアップの仕組みについて説明します。また，JNDI名前空間の確認方法についても説明します。

＜この節の構成＞

8.2.1　ルックアップで使用する名称の種類

8.2.2　EJBのリファレンスが自動的にバインドされる名称

8.2.3　JNDI名前空間のマッピングとルックアップ

8.2.4　JNDI名前空間の確認方法

8.2.1　ルックアップで使用する名称の種類

Cosminexusでは，次に示す3種類の名称を使用したルックアップができます。

自動的にバインドされる名称でのルックアップ
Enterprise Beanをルックアップするときに使用できます。

java:comp/envでのルックアップ
Enterprise BeanまたはJ2EEリソースをルックアップするときに使用できます。

ユーザ指定名前空間機能を利用して付与した名称でのルックアップ
Enterprise BeanまたはJ2EEリソースをルックアップするときに使用できます。

EJBクライアントの形態ごとに，利用できるルックアップ方法，および推奨するルックアップ方法を次の表に示します。

表8-3　ルックアップ方法の種類

EJBクライアントの形態 | ルックアップの方法
自動的にバインドされる名称でのルックアップ | java:comp/envを使用した名称でのルックアップ | ユーザ指定名前空間機能を利用して付与した別名でのルックアップ
EJBクライアントアプリケーション | ◎ | × | ○
JSP，サーブレット | ○ | ◎ | ○
EJB | ○ | ◎ | ○

（凡例）　◎：利用を推奨する　○：利用できる　×：利用できない

それぞれのルックアップ名称とその名称を使用したルックアップ方法について説明します。

＜この項の構成＞

(1)　自動的にバインドされる名称でのルックアップ

(2)　java:comp/envを使用した名称でのルックアップ

(3)　ユーザ指定名前空間機能を利用して付与した別名でのルックアップ

(1)　自動的にバインドされる名称でのルックアップ

CosminexusでのJ2EEアプリケーションのデプロイ時に，オブジェクトリファレンスに自動的に付与される名称を指定してルックアップする方法です。

J2EEアプリケーションのデプロイ時に，Enterprise Beanに対応するEJBホームオブジェクトリファレンス，およびビジネスインタフェースのリファレンスは，自動的にJNDIの名前にバインドされます。バインドされる名称には，J2EEアプリケーションのサーバ名やアプリケーション名が付与されるので，名前空間の衝突を回避できます。

自動的にバインドされる名称については，「8.2.2　EJBのリファレンスが自動的にバインドされる名称」を参照してください。

(2)　java:comp/envを使用した名称でのルックアップ

J2EEで定義されているjava:comp/envを使用して，ルックアップで指定した名称の名前解決をする方法です。java:comp/envは，J2EEで定義されている，名前空間のコンテキストルートです。なお，java:comp/envで指定する参照名と，実際の名称間のリンクの対応は，DDによって定義します。これによって，デプロイ時に参照名と実際の名称間のリンクを解決します。

(3)　ユーザ指定名前空間機能を利用して付与した別名でのルックアップ

Cosminexusの機能で，Enterprise BeanまたはJ2EEリソースに別名を定義する方法です。ユーザ指定名前空間機能といいます。

Enterprise Beanの場合，JNDIの名前へのバインドと合わせて，EJBホームオブジェクトリファレンスまたはビジネスインタフェースのリファレンスの別名を登録できます。また，J2EEリソース（リソースアダプタ，メールコンフィグレーション，JavaBeansリソース）に対しても，別名を登録できます。

別名を登録することで，ユーザが指定した任意の名称でEnterprise BeanおよびJ2EEリソースをルックアップできるようになります。

参考

J2EEの仕様では，java:comp/envを使用した名称でのルックアップが推奨されています。

Enterprise BeanまたはJ2EEリソースへの別名付与の詳細については，「8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

8.2.2　EJBのリファレンスが自動的にバインドされる名称

J2EEアプリケーションをデプロイすると，EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスは，決められた名称で自動的にJNDIの名前にバインドされます。ルックアップ時には，バインドされた名前を使用します。

ここでは，EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスが自動的にバインドされる名称について説明します。

なお，JNDI名前空間のマッピングの仕組みと使い方については，「8.2.3　JNDI名前空間のマッピングとルックアップ」で説明します。

＜この項の構成＞

(1)　EJBホームオブジェクトリファレンスが自動的にバインドされる名称

(2)　ビジネスインタフェースのリファレンスが自動的にバインドされる名称

(3)　テストモードで実行されているEnterprise Beanのルックアップをする場合の名称の指定方法

(1)　EJBホームオブジェクトリファレンスが自動的にバインドされる名称

J2EEアプリケーションを開始（デプロイ）したとき，Enterprise BeanのEJBホームオブジェクトリファレンスは，次に示す名称で，JNDIの名前にバインドされます。

HITACHI_EJB/SERVERS/<サーバ名称>/EJB/<J2EE APP名称>/<Enterprise Bean名称>

<サーバ名称>

J2EEサーバのサーバ名称

<J2EE APP名称>

J2EEアプリケーションのルックアップ名称

<Enterprise Bean名称>

Enterprise Beanのルックアップ名称

J2EEアプリケーション間のEnterprise Beanの呼び出しや，EJBクライアントアプリケーションからのEnterprise Beanの呼び出しのとき，クライアントはバインドされたJNDIの名前でEJBホームオブジェクトリファレンスをルックアップします。

次に示す図では，下記の条件でJ2EEアプリケーションを開始したとき，"CartHome"インタフェースを実装したEJBホームオブジェクトが生成され，そのリファレンスがJNDIの名前"HITACHI_EJB/SERVERS/MyServer/EJB/CartApp/CartEB"にバインドされることを示しています。

条件

Enterprise Bean："CartBean"

リモートインタフェースの名称："Cart"

ホームインタフェース："CartHome"

サーバ名称："MyServer"

J2EEアプリケーションのルックアップ名称："CartApp"

Enterprise Beanのルックアップ名称："CartEB"

図8-1　EJBホームオブジェクトリファレンスのJNDI名前空間へのバインド

次に，自動的にバインドされる名称を利用してEJBホームオブジェクトのリファレンスをルックアップする場合のルックアップとオブジェクトの取得の流れを示します。

図8-2　自動的にバインドされる名称を利用したルックアップとオブジェクトの取得の流れ

(2)　ビジネスインタフェースのリファレンスが自動的にバインドされる名称

J2EEアプリケーションを開始（デプロイ）したとき，ビジネスインタフェースのリファレンスは，次に示す名称で，JNDIの名前にバインドされます。

HITACHI_EJB/SERVERS/<サーバ名称>/EJBBI/<J2EE APP名称>/<Enterprise Bean名称>

<サーバ名称>

J2EEサーバのサーバ名称

<J2EE APP名称>

J2EEアプリケーションのルックアップ名称

<Enterprise Bean名称>

Enterprise Beanのルックアップ名称

J2EEアプリケーション間のEnterprise Beanの呼び出しや，EJBクライアントアプリケーションからのEnterprise Beanの呼び出しのとき，クライアントはバインドされたJNDIの名前でビジネスインタフェースのリファレンスをルックアップします。

(3)　テストモードで実行されているEnterprise Beanのルックアップをする場合の名称の指定方法

J2EEアプリケーション外からテストモードで実行されているEnterprise Beanをルックアップする場合，テストモード用の名前空間を意識してルックアップする必要があります。通常モードで実行されるEnterprise Beanを「HITACHI_EJB/」で始まる文字列でルックアップするのに対して，同じEnterprise Beanがテストモードで実行される場合は「$HITACHI_TEST/HITACHI_EJB/」で始まる文字列でルックアップします。

テストモードでのアプリケーションの動作については，「19.7　J2EEアプリケーションのテスト機能」を参照してください。

8.2.3　JNDI名前空間のマッピングとルックアップ

ここでは，JNDI名前空間のマッピングの仕組みと，ルックアップでの指定する名称とJNDI名前空間およびDDの関係について説明します。

＜この項の構成＞

(1)　Enterprise Beanを参照する仕組みと使い方（ejb-ref）

(2)　リソースを参照する仕組みと使い方（resource-ref）

(1)　Enterprise Beanを参照する仕組みと使い方（ejb-ref）

J2EEサーバ内で実行するアプリケーションでは，Enterprise Beanを呼び出すために，Enterprise Bean参照の名前解決が必要です。正確には，Enterprise Beanに対応するEJBホームインタフェース，EJBローカルホームインタフェース，ビジネスインタフェースなどの名前解決をします。

EJBホームインタフェース，またはビジネスインタフェースの名前解決をするためには，次の2種類の作業が必要です。

参照側アプリケーションの作成時の作業
アプリケーションの作成時に参照用の名称を決め，Enterprise Beanやサーブレットなどのプログラム内でのlookupの引数に，その参照用の名称を指定します。また，java:comp/envを使用する場合は，DDの<ejb-ref>に，決めた参照用の名称を記載します。

参照側アプリケーションのデプロイ時の作業
作成したアプリケーションをJ2EEサーバ上にデプロイするときに，Enterprise Beanをカスタマイズして，参照用の名称と実際の名称をlinked-toで結び付けます。
この操作は，サーバ管理コマンドを使用して実行できます。

マッピングの仕組みは，参照側のアプリケーションと参照先のアプリケーションが同じJ2EEアプリケーションか，別のJ2EEアプリケーションかによって異なります。次に，EJBホームインタフェースの名前解決の例として，別のJ2EEアプリケーションのEnterprise Beanを参照する場合と，同じJ2EEアプリケーション内のEnterprise Beanを参照する場合の例を示します。

(a)　別のJ2EEアプリケーションのEnterprise Beanを参照する場合

J2EEアプリケーションから別のJ2EEアプリケーションに含まれるEnterprise Beanを参照する例を，次の図に示します。

図8-3　J2EEアプリケーションから別のJ2EEアプリケーションに含まれるEnterprise Beanを参照する例

java:comp/envを使用する場合，参照側のプログラムのlookupに指定するjava:comp/env下の参照名と実際にJNDI名前空間に登録されているlookup名は，デフォルトで対応づけられます（linked-to）。なお，lookup名をJNDI名前空間に登録されている名称と異なる名称にする場合は，サーバ管理コマンドでカスタマイズする必要があります。図の場合は，PetShopEBをejb/PetShopBeanとして呼び出すようにカスタマイズします。

ユーザ指定名前空間機能を使用する場合，参照側のプログラムのlookupに別名を指定できます。<ejb-ref>の定義は不要です。

(b)　同じJ2EEアプリケーション内のEnterprise Beanを参照する場合

J2EEアプリケーションから同じJ2EEアプリケーションに含まれるEnterprise Beanを参照する例を，次の図に示します。

図8-4　同じJ2EEアプリケーションに含まれるEnterprise Beanを参照する例

同じアプリケーション内のEnterprise Beanを呼び出す場合は，lookup名による参照の解決ではなく，<ejb-ref-name>とejb-nameを結び付けて解決します（linked-to）。なお，同一J2EEアプリケーションの場合，参照に必要な情報はアプリケーション開発時に判明しているので，DDの<ejb-link>タグに直接ejb-nameを書き込んでおくこともできます。

(2)　リソースを参照する仕組みと使い方（resource-ref）

J2EEサーバ内で実行するアプリケーションでリソースアダプタを利用する場合，lookupによるリソース参照の名前解決が必要です。正確には，リソースマネジャへのコネクションを作成するファクトリの名前解決をします。

リソースマネジャへのコネクションを作成するファクトリの名前解決をするためには，次の2種類の作業が必要です。

参照側アプリケーションの作成時の作業
アプリケーションの作成時に参照用の名称を決め，Enterprise Beanやサーブレットなどのプログラム内でのlookupの引数に，その参照用の名称を指定します。また，DDの<resource-ref>に，決めた参照用の名称を記載します。

参照側アプリケーションのデプロイ時の作業
作成したアプリケーションをJ2EEサーバ上にデプロイするときに，リソースをカスタマイズして，参照用の名称とJ2EEサーバ上に登録済みのリソースをlinked-toで結び付けます。
この操作は，サーバ管理コマンドを使用して実行できます。

次にDB Connector経由でデータベースにアクセスする場合の例を示します。

図8-5　DB Connector経由でデータベースにアクセスする場合の例

この例では，リソースの参照名称とリソースの表示名称を結び付けています。

8.2.4　JNDI名前空間の確認方法

コマンドを使用して，CORBAネーミングサービスで認識されている名称を表示して確認できます。なお，J2EEリソースの別名やEJBローカルホームオブジェクトリファレンスの登録情報は確認できません。使用するコマンドは，nsutilコマンドです。nsutilコマンドの使用方法，使用条件などについては，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

JNDI名前空間の「HITACHI_EJB/SERVERS/MyServer/EJB」の下位の一覧を表示する場合の表示例を次に示します。

# nsutil -VBJprop ORBInitRef=NameService=corbaname::localhost:900 list HITACHI_EJB/SERVERS/MyServer/EJB
Bindings in HITACHI_EJB/SERVERS/MyServer/EJB
Context: App1
Context: App2
Context: App3

8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）

Enterprise BeanまたはJ2EEリソースに対して，ユーザが別の名称を付けてJNDI名前空間に登録する機能を，ユーザ指定名前空間機能といいます。この機能によって，Enterprise BeanまたはJ2EEリソースを，設定した任意の名称でルックアップできるようになります。

Enterprise Beanに付与する別名は，Session BeanまたはEntity Beanの属性（プロパティ）として設定します。J2EEリソースに付与する別名は，DB Connector，メールコンフィグレーション，またはJavaBeansリソースの属性として設定します。

なお，別名を付与するためには，サーバ管理コマンドの動作設定のカスタマイズが必要です。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の次の説明を参照してください。

J2EEアプリケーションの設定

サーバ管理コマンドの動作設定のカスタマイズ

注意

J2EEの仕様では，java:comp/envを利用した名称でのルックアップが推奨されています。

＜この節の構成＞

8.3.1　別名を付けられる対象

8.3.2　別名の付与規則

8.3.3　別名の設定方法

8.3.4　別名が登録または削除されるタイミング

8.3.5　クライアントからの検索

8.3.6　ユーザ指定名前空間機能を使用する場合の注意事項

8.3.1　別名を付けられる対象

ここでは，別名を付けられる対象について説明します。

別名は，Enterprise BeanまたはJ2EEリソースに付けられます。

＜この項の構成＞

(1)　Enterprise Beanに対する別名

(2)　J2EEリソースに対する別名

(1)　Enterprise Beanに対する別名

別名を付けられるのは，次のインタフェースを持つEnterprise Beanです。

リモートホームインタフェース

ローカルホームインタフェース

リモートビジネスインタフェース

ローカルビジネスインタフェース

なお，以降，リモートホームインタフェースとリモートビジネスインタフェースをあわせて，リモートインタフェースといいます。また，ローカルホームインタフェースとローカルビジネスインタフェースをあわせてローカルインタフェースといいます。

参考

リモートインタフェースとローカルインタフェースの別名は，異なる属性として設定します。詳細は，「8.3.3　別名の設定方法」を参照してください。

(2)　J2EEリソースに対する別名

別名を付与できるのは，次の表に示すJ2EEリソースです。

表8-4　別名を付与できるJ2EEリソース

J2EEリソースの種別 | 別名付与の可否
リソースアダプタ | DB Connector | ○※1
DB Connector for Cosminexus RM | ○
Cosminexus RM | ○※2
uCosminexus TP1 Connector | ○
TP1/Message Queue - Access | ○※2
そのほかのリソースアダプタ | ○※3
メールコンフィグレーション | ○
JavaBeansリソース | ○

（凡例）　○：別名を付けられる

注※1　コネクションプールのクラスタ化機能を使用する場合，メンバリソースアダプタには別名を付けられません。

注※2　属性ファイルの<resource-env-ref>に指定するjavax.jms.ConnectionFactoryオブジェクトに別名を付けられます。<resource-env-ref>に指定するjavax.jms.Destinationオブジェクトには別名を付けられません。

注※3　Connector 1.5仕様に準拠するリソースアダプタの場合，管理対象オブジェクトに別名は付与できません。

8.3.2　別名の付与規則

ここでは，Enterprise BeanおよびJ2EEリソースに別名を設定する場合の付与規則について説明します。

＜この項の構成＞

(1)　指定できる名称

(2)　別名の重複

(1)　指定できる名称

別名に指定できる文字，および指定する場合の制約について説明します。

(a)　別名に指定できる文字

別名には，次の文字を使用した名称を指定できます。

英数字（A～Z，a～z，0～9）

アンダースコア（_）

スラッシュ（/）

ピリオド（.）

ただし，スラッシュは，区切り文字として使用する場合だけ，名前に使用できます。

(b)　別名を指定するときの制約

次に示す名前は，別名として指定できません。指定した場合，J2EEアプリケーションまたはJ2EEリソースを開始できません。

名前の先頭または名前の末尾に，スラッシュ（/）またはピリオド（.）を指定した名前。

スラッシュ（/）だけ，またはピリオド（.）だけの名前。

スラッシュ（/）が連続している名前。

スラッシュ（/）とピリオド（.）が連続している名前。

「HITACHI_EJB」で始まる名前（大文字・小文字を区別する）。

文字列長が255バイトよりも長い名前。

このほか，J2EEリソースの場合，同じ名称が指定されたときには，あとから指定されている定義が有効になります。

(2)　別名の重複

Enterprise BeanおよびJ2EEリソースに別名を付ける場合の別名の重複可否を次の表に示します。

表8-5　Enterprise BeanおよびJ2EEリソースの別名の重複可否

別名を付ける対象 | リモートインタフェースを持つEnterprise Bean | ローカルインタフェースを持つEnterprise Bean | J2EEアプリケーションに含まれるリソースアダプタ | J2EEリソース※1
リモートインタフェースを持つEnterprise Bean | × | ○※2 | × | ×
ローカルインタフェースを持つEnterprise Bean | ○※2 | △ | △ | ×
J2EEアプリケーションに含まれるリソースアダプタ | × | △ | △ | ×
J2EEリソース※1 | × | × | × | ×

（凡例）

○：重複できる

△：J2EEアプリケーションが異なる場合は重複できる

×：重複できない

注※1

J2EEアプリケーションに含まれるリソースアダプタを除きます。

注※2

ローカル呼び出し最適化機能を使用するかどうかに関係なく重複できます。

なお，重複できない組み合わせの場合，名称が完全に一致していなくても指定できないことがあります。

例を使用して説明します。

例

ネーミング管理機能では，CORBAネーミングサービスに登録されるオブジェクトを名前で管理しています。オブジェクトに付与された名前は「/」を階層構造の区切りとして解析し，ツリー構造で管理されます。ツリーのなかで，子ノードを持つノードでは，そのノードの下に新しくオブジェクトを登録できます。

下の図の，ノードA，B，C，Fは子ノードを持つノードです。このため，これらのノードの下には新しくオブジェクトを登録できます。

この状態で，別名「A/B/D」がすでに使用されている場合は，別名「A/B/I」を指定できます。

しかし，D，E，G，Hのようなノードには，新しくオブジェクトを登録することはできません。このため，別名「A/B/D/I」を指定することはできません。

重複できない別名を指定した場合，別名を指定した対象ごとに，次にタイミングでエラーが発生します。

Enterprise Beanの場合は，J2EEアプリケーションの開始に失敗します。

メールコンフィグレーション以外のJ2EEリソースの場合は，リソースの開始に失敗します。

メールコンフィグレーションの場合は，属性設定時にエラーが発生します。

8.3.3　別名の設定方法

ここでは，Enterprise BeanまたはJ2EEリソースに別名を設定する方法について説明します。

＜この項の構成＞

(1)　Enterprise Beanに別名を設定する方法

(2)　J2EEリソースに別名を設定する方法

(1)　Enterprise Beanに別名を設定する方法

Enterprise Beanの別名は，次の2種類の方法で設定できます。

サーバ管理コマンドで設定する方法

アノテーションで指定する方法

それぞれの方法について説明します。

(a)　サーバ管理コマンドで設定する方法

サーバ管理コマンド（cjsetapppropコマンド）で設定します。別名は，属性ファイルの次のタグに指定します。

リモートインタフェースの別名は，<optional-name>タグに指定します。

ローカルインタフェースの別名は，<local-optional-name>タグに指定します。

設定方法の詳細は，マニュアル「Cosminexus　システム構築ガイド」の，J2EEアプリケーションに含まれるEnterprise Beanの別名の設定についての説明を参照してください。

(b)　アノテーションで指定する方法

@Statelessまたは@StatefulのmappedName属性で指定します。

アノテーションで別名を指定する場合のコーディング例を次に示します。この例は，@StatelessのmappedName属性にStateless Session Beanの別名「MyFoo」を設定する場合の例です。

@Stateless(mappedName="MyFoo")
public class FooEB implements FooIF {
   ...
}

public interface FooIF {
...
}

@Stateless，@StatefulのmappedName属性に指定した別名は，Session Bean属性ファイルの<hitachi-session-bean-property><mapped-name>タグに設定されます。

(c)　サーバ管理コマンドとアノテーションの両方で別名を設定した場合

@Stateless，@StatefulのmappedName属性を指定して別名を指定している場合に，Session Bean属性ファイルで<optional-name>タグまたは<local-optional-name>タグに別名を設定したときには，<optional-name>タグおよび<local-optional-name>タグの指定が有効になります。

サーバ管理コマンドとアノテーションの両方で別名を指定した場合に有効になるタグについて，次の表に示します。

表8-6　サーバ管理コマンドとアノテーションの両方で別名を指定した場合に有効になるタグ

別名の設定対象 | @Stateless，@StatefulのmappedName属性だけを指定 | <optional-name>タグ，<local-optional-name>タグだけを指定 | @Stateless，@StatefulのmappedName属性および<optional-name>タグ，<local-optional-name>タグの両方を指定した場合
リモートインタフェース | <mapped-name>タグ※ | <optional-name>タグ | <optional-name>タグ
ローカルインタフェース | <mapped-name>タグ※ | <local-optional-name>タグ | <local-optional-name>タグ

注※　@Stateless，@StatefulのmappedName属性に指定した値が設定されるタグです。

(2)　J2EEリソースに別名を設定する方法

J2EEリソースの別名は，サーバ管理コマンド（cjsetrespropコマンドまたはcjsetrarpropコマンド）を使用して設定できます。別名は，属性ファイルの次のタグに指定します。

表8-7　サーバ管理コマンドとアノテーションの両方で別名を指定した場合に有効になるタグ

リソースの種別 | 属性ファイル | 指定するタグ
リソースアダプタ | Connector属性ファイル | <resource-external-property>下の<optional-name>タグ
メールコンフィグレーション | メール属性ファイル
JavaBeansリソース | JavaBeansリソース属性ファイル | <resource-env-external-property>下の<optional-name>タグ

設定方法の詳細は，マニュアル「Cosminexus　システム構築ガイド」のリソースの別名の設定についての説明を参照してください。

8.3.4　別名が登録または削除されるタイミング

ここでは，Enterprise BeanまたはJ2EEリソースに対する別名の設定方法，別名が登録されるタイミング，および別名が削除されるタイミングについて説明します。

＜この項の構成＞

(1)　Enterprise Beanの別名が登録または削除されるタイミング

(2)　J2EEリソースの別名が登録または削除されるタイミング

(1)　Enterprise Beanの別名が登録または削除されるタイミング

Enterprise Beanのオブジェクトに指定した別名が名前空間に登録されるのは，J2EEアプリケーションを開始した時，またはJ2EEサーバを起動した時です。

Enterprise Beanのオブジェクトに指定した別名が名前空間から削除されるのは，J2EEアプリケーションを停止した時，またはJ2EEサーバを停止した時です。

参考

ログレベルを「Warning」にしている場合，別名が登録または削除されたことをメッセージログで確認できます。

別名登録時：KDJE47605-Iが出力されます。

別名削除時：KDJE47606-Iが出力されます。

ただし，デフォルトのログレベルの設定では，これらのメッセージは出力されません。ログレベルの設定については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのログ取得の設定についての説明を参照してください。

(2)　J2EEリソースの別名が登録または削除されるタイミング

J2EEリソースの別名が名前空間に登録されるのは，J2EEリソースを開始した時です。

J2EEリソースの別名が名前空間から削除されるのは，J2EEリソースを停止した時です。

参考

別名が登録または削除されたことは，メッセージログで確認できます。

別名登録時：KDJE47602-Iが出力されます。

別名削除時：KDJE47603-Iが出力されます。

8.3.5　クライアントからの検索

ここでは，別名を付けたEnterprise BeanまたはJ2EEリソースをクライアントから検索する方法について説明します。

＜この項の構成＞

(1)　クライアントのソースと検索先オブジェクトの設定の関係

(2)　Enterprise Beanの検索

(3)　J2EEリソースの検索

(1)　クライアントのソースと検索先オブジェクトの設定の関係

別名を付けたEnterprise BeanまたはJ2EEリソースを検索する場合のクライアントのソースでの指定方法と，検索先オブジェクトでの設定方法について説明します。

クライアントのソースには，ルックアップする名称として，検索先のオブジェクトの別名を指定します。検索先のオブジェクトには，アノテーションまたは属性ファイルを使用して，対応する別名を設定します。

検索元のソースの記述と，検索先オブジェクトの設定の関係を次の図に示します。

図8-6　クライアントのソースと検索先オブジェクトの設定の関係

(2)　Enterprise Beanの検索

別名を使用してEnterprise Beanを検索する場合の，クライアントのコーディング例を次に示します。この例では，「MyCart」という別名を設定したEJBホームオブジェクトを検索します。

 ：
javax.naming.Context ctx = new javax.naming.InitialContext();
Object obj = ctx.lookup("MyCart");
SampleHome home =
(SampleHome)javax.rmi.PortableRemoteObject.narrow(obj, SampleHome.class);
Sample mybean = home.create();   //リモートオブジェクトの生成
String name = mybean.ping();     //ビジネスメソッドの実行
 ：

EJBホームオブジェクト取得後の操作は，別名を使用しないで取得したEJBホームオブジェクトに対する操作と同じです。

EJBホームオブジェクトのリファレンスをルックアップする場合の，ルックアップおよびオブジェクト取得の流れを次の図に示します。

図8-7　EJBホームオブジェクトのリファレンスのルックアップとオブジェクト取得の流れ

ポイント

J2EEアプリケーション外からテストモードで実行されているEnterprise Beanをルックアップする場合，テストモード用の名前空間を意識してルックアップする必要があります。この図の例では，通常モードで実行されるEnterprise Beanを「MyCart」でルックアップするのに対して，同じEnterprise Beanがテストモードで実行される場合は，「$HITACHI_TEST/MyCart」でルックアップします。

テストモードでのアプリケーションの動作については，「19.7　J2EEアプリケーションのテスト機能」を参照してください。

(3)　J2EEリソースの検索

別名を使用してJ2EEリソースを検索する場合の，クライアントのコーディング例を次に示します。この例では，「jdbc/DBOpt」という別名を設定したJ2EEリソースを検索します。

Context initCtx = new InitialContext();
DataSource ds = (DataSource) initCtx.lookup("jdbc/DBOpt");

なお，J2EEリソースのオブジェクト取得後の操作は，別名を使用しないで取得したオブジェクトに対する操作と同じです。

注意

EJBクライアントアプリケーションからは，J2EEリソースを検索できません。検索した場合は，javax.naming.NameNotFoundException例外が発生します。

8.3.6　ユーザ指定名前空間機能を使用する場合の注意事項

ここでは，ユーザ指定名前空間機能を使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　別名を使用した検索を実行する場合の注意

(2)　ネーミングサービスについての注意

(3)　J2EEリソースの別名を指定する場合の注意

(4)　テストモードを使用する場合の注意

(1)　別名を使用した検索を実行する場合の注意

ローカルインタフェースを持つEnterprise Beanは，J2EEアプリケーション外から検索できません。

ローカルインタフェースを持つEnterprise Beanの別名に対して，ネーミングコンテキスト単位の検索はできません。

リモートインタフェースを持つEnterprise Beanとローカルインタフェースを持つEnterprise Beanには，同じ別名を設定できます。ただし，この場合に重複している別名をルックアップすると，必ずローカルインタフェースを持つEnterprise Beanがルックアップされます。

(2)　ネーミングサービスについての注意

複数のJ2EEサーバで，一つのCORBAネーミングサービスを共用している場合，ユーザ指定名前空間機能は使用できません。

J2EEサーバとCORBAネーミングサービスは同じタイミングで起動・停止するようにしてください。
J2EEサーバまたはCORBAネーミングサービスのどちらか一方がダウンした場合は，J2EEサーバとCORBAネーミングサービスを共に再起動してください。

CORBAネーミングサービスを共有する場合，ユーザ指定名前空間機能で指定する別名として「Cosminexus」は使用できません。

(3)　J2EEリソースの別名を指定する場合の注意

別名を登録したJ2EEリソースを停止，削除，または属性変更（JavaMailセッションの場合）する場合は，J2EEサーバ上で開始されているすべてのJ2EEアプリケーションを先に停止してください。

J2EEリソースのユーザ指定名前空間機能を使用する場合，J2EEアプリケーションで生成するInitialContextで指定しているプロバイダURL（java.naming.provider.url）のホスト名と，J2EEサーバ側のサーバ定義に指定するejbserver.naming.hostキーの値は同じ文字列にしてください。なお，次の条件に当てはまる場合は，J2EEアプリケーションで生成しているInitialContextに対して，プロバイダURLを指定する必要はありません。

J2EEサーバ用ユーザプロパティファイルのejbserver.naming.hostキーに「localhost」（デフォルト値）を指定する。

同一J2EEサーバ上のネーミングサービスへ接続する。

ejbserver.naming.hostキーに「localhost」を指定していて，J2EEアプリケーションで生成しているInitialContextのプロバイダURLを指定する場合は，プロバイダURLのホスト名に次のAPIで取得できる値を指定してください。java.net.InetAddress.getLocalHost().getHostName();

J2EEリソースのユーザ指定名前空間機能では，別名の中に"/"文字を含めた場合も，ネーミングコンテキスト単位で検索できません。ルックアップ名称として使用できる文字列は，指定した別名だけです。
別名として "jdbc/TestDB"を付与してデプロイおよび開始しているJ2EEリソース（DB Connector）の場合に，使用できるJNDIのルックアップ名称と使用できないルックアップ名の例を次に示します。

使用できるルックアップ名の例

DataSource ds = (DataSource) initCtx.lookup("jdbc/TestDB");

使用できないルックアップ名の例

Context ctx = (Context) initCtx.lookup("jdbc");

(4)　テストモードを使用する場合の注意

テストモードを使用している場合，1.と2.で示すオブジェクの別名に，同じ名前を付けることができます。

テストモードで動作しているJ2EEアプリケーションに含まれる，リモートインタフェースを持つEnterprise Bean

通常モードで動作しているJ2EEアプリケーションに含まれる，リモートインタフェースを持つEnterprise Bean，またはJ2EEリソース

ただし，これらのオブジェクトに重複した別名を付けている場合に，どちらかのJ2EEアプリケーションの動作モードを変更して開始しようとすると，エラーが発生します。

エラーが発生する例を次の図に示します。

図8-8　J2EEアプリケーションの動作モードを変更した場合にエラーが発生する例

動作モードを変更した場合にJ2EEアプリケーションを起動できなかったときは，重複しない別名に変更してください。

8.4　ラウンドロビンポリシーによるCORBAネーミングサービスの検索

この節では，ラウンドロビンポリシーによってCORBAネーミングサービスを検索する機能について説明します。この機能を使用すると，複数のCORBAネーミングサービスに登録されている同一名称（別名）のEJBホームオブジェクトまたはビジネスインタフェースのリファレンスを，ラウンドロビンポリシーに従ってルックアップできます。これを，ラウンドロビン検索といいます。

JNDIの名前空間から該当する名前でEJBホームオブジェクトまたはビジネスインタフェースのリファレンスをラウンドロビン検索した場合，クライアントアプリケーションは複数のCORBAネーミングサービス上に存在するEJBホームオブジェクトまたはビジネスインタフェースのリファレンスから，ラウンドロビンのポリシーで選択されたEJBホームオブジェクトまたはビジネスインタフェースのリファレンスを取得できます。これによって，J2EEサーバをクラスタ構成で開始して，負荷を分散できます。また，EJBクライアントからは，クラスタ構成を意識しないで，J2EEサーバのEnterprise Beanを呼び出すことができます。

ポイント

ラウンドロビン検索をする場合，検索対象となるEJBホームオブジェクトまたはビジネスインタフェースのリファレンスは同じ名称でCORBAネーミングサービスに登録されている必要があります。このため，ユーザ指定名前空間機能を使用して，それぞれのEJBホームオブジェクトまたはビジネスインタフェースのリファレンスに同じ名称を指定してください。

＜この節の構成＞

8.4.1　ラウンドロビン検索の範囲

8.4.2　ラウンドロビン検索の動作

8.4.3　ラウンドロビン検索をするために必要な設定

8.4.4　ラウンドロビン検索をする場合の注意事項

8.4.1　ラウンドロビン検索の範囲

JNDIによるラウンドロビン検索の対象範囲は，論理ネーミングサービス内のグループとなります。

論理ネーミングサービスは一つ以上のグループで構成されます。1グループにつき一つ以上のCORBAネーミングサービスを含みます。論理ネーミングサービスの構成を次の図に示します。

図8-9　論理ネーミングサービスの構成

複数のグループで，グループのメンバに同一のCORBAネーミングサービスを指定できます。

8.4.2　ラウンドロビン検索の動作

クライアントプログラムからのラウンドロビン検索時の動作について次に示す図で説明します。

なお，図中の各CORBAネーミングサービスには，ラウンドロビン検索の対象となるEJBホームオブジェクトが「MyBean」という名前で登録されていると仮定します。検索対象となる複数のEJBホームオブジェクトには，ユーザ指定名前空間機能によって，同一の名称が設定されています。

図8-10　ラウンドロビン検索時の動作

クライアントアプリケーションは，検索対象の論理ネーミングサービスのグループ名を引数にして，ラウンドロビン用のInitialContextインスタンスを生成します。

クライアントアプリケーションは，生成したラウンドロビン用のInitialContextインスタンスに，「MyBean」という名前を指定して検索を要求します。

ラウンドロビン検索機能は，ラウンドロビンポリシーで検索対象のグループに属するCORBAネーミングサービスの検索先を決定します。

検索に成功すると，クライアントアプリケーションに結果を返します。
なお，検索に失敗した場合は，グループに属する別のCORBAネーミングサービスを検索します。

クライアントアプリケーションは，検索されたEJBホームオブジェクトにアクセスします。

8.4.3　ラウンドロビン検索をするために必要な設定

ラウンドロビン検索をするために必要な設定とグループ名の命名規則などについて説明します。

ラウンドロビン検索をする場合，次の設定が必要です。

ラウンドロビン検索の対象になる論理ネーミングサービスのグループ

各グループに属するCORBAネーミングサービスのルート位置

InitialContextFactoryの実装を委譲しているクラス

ラウンドロビン検索機能を使用するためには，システムプロパティに設定します。なお，InitialContextFactoryの実装を委譲しているクラスについては，システムプロパティの設定に加えて，各アプリケーションのInitialContext生成時に引数で指定することもできます。また，InitialContext生成時の引数では，システムプロパティに指定した論理ネーミングサービスのグループのうち，特定のネーミングサービスを選択して指定することもできます。

なお，システムプロパティだけで設定している場合は，特定のグループを指定したラウンドロビン検索はできません。論理ネーミングサービス上にある全グループのネーミングサービスが検索の対象となります。

ここでは，それぞれの設定方法の概要について説明します。

＜この項の構成＞

(1)　システムプロパティの設定によるグループとグループに属するCORBAネーミングサービスのルート位置の特定

(2)　InitialContext生成時の引数指定による検索対象グループの選択

(3)　グループ名の命名規則

(4)　推奨する設定

(1)　システムプロパティの設定によるグループとグループに属するCORBAネーミングサービスのルート位置の特定

ラウンドロビン検索を実行する場合，システムプロパティに，ラウンドロビン検索の対象になる論理ネーミングサービスのグループと，グループに属するネーミングサービスのルート位置を指定します。また，InitialContextFactoryの実装を委譲しているクラスとして，java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactoryを指定する必要があります。

システムプロパティは，ラウンドロビン検索機能を利用するアプリケーションの種類ごとに，次の個所に設定します。

J2EEサーバで動作するJ2EEアプリケーション（Enterprise Beanまたはサーブレット），またはWebコンテナサーバで動作するWebアプリケーション（サーブレット）の場合
J2EEサーバまたはWebコンテナサーバのプロパティをカスタマイズして設定します。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の次の説明を参照してください。

J2EEサーバの動作設定のカスタマイズ

Webコンテナサーバの動作設定のカスタマイズ

J2EEサーバ，Webコンテナサーバ以外で動作するEJBクライアントアプリケーションの場合
次のどちらかの方法で設定します。

EJBクライアントアプリケーション起動時にプロパティとして設定します。EJBクライアントアプリケーションのプロパティの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

System.setPropertyメソッドを使用してアプリケーション内で設定します。

指定例を次に示します。この例は，プロパティをusrconf.propertiesで指定する場合の指定例です。なお，それぞれのキーの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

# 論理ネーミングサービスの構成を定義
ejbserver.jndi.namingservice.group.list=g1;g2;g3
ejbserver.jndi.namingservice.group.g1.providerurls=corbaname::hostA:900;corbaname::hostB:900
ejbserver.jndi.namingservice.group.g2.providerurls=corbaname::hostD:700;corbaname::hostE:700
ejbserver.jndi.namingservice.group.g3.providerurls=corbaname::hostF:800;corbaname::hostG:800
# InitialContextFactoryの実装を委譲するクラスを指定
java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactory
　　：

指定例の中のejbserver.jndi.namingservice.group.listキー，ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキー，およびjava.naming.factory.initialキーには，それぞれ次の内容を指定します。

ejbserver.jndi.namingservice.group.listキー

ラウンドロビン検索をする場合に，検索対象になる論理ネーミングサービスのグループを定義します。指定する各グループ名は，論理ネーミング内で一意に識別できる名称にします。

ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキー

各グループに属するネーミングサービスのルート位置をプロバイダURLで指定します。<Specify group name>には，ejbserver.jndi.namingservice.group.list内に指定したグループ名を指定します。

java.naming.factory.initialキー

InitialContextFactoryの実装を委譲しているクラスを指定します。

java.naming.factory.initialキーに，"com.hitachi.software.ejb.jndi.GroupContextFactory"を指定した場合，ラウンドロビン検索が実施されます。指定しなかった場合，J2EEサーバがネーミングサービスとして利用するCORBAネーミングサービスが検索の対象になります。

なお，「(2)　InitialContext生成時の引数指定による検索対象グループの選択」に示す方法でInitialContext生成時の引数にjava.naming.factory.initialキーを設定する場合，システムプロパティでこのキーに値を指定する必要はありません。

(2)　InitialContext生成時の引数指定による検索対象グループの選択

ラウンドロビン検索を実行する設定になっている場合に，クライアントアプリケーション内でInitialContext生成時の引数に特定のグループを指定することによって，ラウンドロビン対象でのルックアップ対象になるグループを選択できます。なお，InitialContext生成時の引数の指定は任意です。

指定例を次に示します。

　　　　　：
Hashtable env = new Hashtable();
env.put("ejbserver.jndi.namingservice.groupname", "g1");
env.put("java.naming.factory.initial",
                "com.hitachi.software.ejb.jndi.GroupContextFactory");
InitialContext ic = new InitialContext(env);
　　　　　：

指定例の中のejbserver.jndi.namingservice.groupnameキーおよびjava.naming.factory.initialキーには，それぞれ次の内容を指定します。

ejbserver.jndi.namingservice.groupnameキー

検索対象となるグループ名を「gl」部分に指定します。グループ名は，システムプロパティ（usrconf.propertiesのejbserver.jndi.namingservice.group.listキー）で，すでに定義されているものを指定してください。なお，ejbserver.jndi.namingservice.groupnameキーにデフォルト値はありません。指定しなかった場合，システムプロパティで設定した，すべてのグループを検索の対象とします。

java.naming.factory.initialキー

InitialContextFactoryの実装を委譲しているクラスを指定します。java.naming.factory.initialキーに，"com.hitachi.software.ejb.jndi.GroupContextFactory"を指定した場合，ラウンドロビン検索が実施されます。システムプロパティのjava.naming.factory.initialキーの指定を省略した場合に，引数でこのキーの指定を省略すると，ejbserver.jndi.namingservice.groupnameキーで指定したグループの検索は実施されないで，J2EEサーバがネーミングサービスとして利用するCORBAネーミングサービスが検索の対象になります。

(3)　グループ名の命名規則

グループ名に使用できる文字を次に示します。

英数字（A～Z，a～z，0～9）

アンダースコア（_）

なお，グループ名は，論理ネーミングサービス内で一意となる名称にしてください。

(4)　推奨する設定

ラウンドロビン検索機能を使用するときには，CORBAネーミングサービスの監視機能が持つ，無効なキャッシュ領域を定期的にクリアする機能を利用することを推奨します。クライアントのシステムプロパティ設定例を次に示します。

クライアントのシステムプロパティ設定例

 ：
# キャッシュの設定
ejbserver.jndi.cache=on
ejbserver.jndi.cache.interval=60
ejbserver.jndi.cache.interval.clear.option=check

# 論理ネーミングサービスの構成を定義
ejbserver.jndi.namingservice.group.list=g1;g2;g3
ejbserver.jndi.namingservice.group.g1.providerurls= corbaname::hostA:900;corbaname::hostB:900;corbaname::hostC:900
ejbserver.jndi.namingservice.group.g2.providerurls=
　　　　　　　　　　　　　corbaname::hostD:700;corbaname::hostE:700
ejbserver.jndi.namingservice.group.g3.providerurls=
 corbaname::hostF:800;corbaname::hostG:800;corbaname::hostH:800
 ：

8.4.4　ラウンドロビン検索をする場合の注意事項

ラウンドロビン検索用に取得したコンテキストでは，lookupメソッドだけをサポートしています。javax.naming.Contextで定義されているほかのAPIは使用できません。

別名を使用したラウンドロビン検索を実行すると，次の順序でEnterprise Beanが検索されます。

検索を実行したJ2EEサーバの名前空間から，ローカルインタフェースを持つEnterprise Beanが検索されます。

1.で見つからなかった場合は，ラウンドロビン検索によってリモートインタフェースを持つEnterprise Beanが検索されます。

InitialContextFactoryの処理を委譲しているクラスごとの検索可否を次の表に示します。

表8-8　InitialContextFactoryの処理を委譲しているクラスごとの検索可否

検索対象
GroupContextFactory
InsContextFactory

リモートインタフェースを持つEnterprise Bean
○※
○

リモートインタフェースを持つEnterprise Bean
（別名による検索）
○
○

ローカルインタフェースを持つEnterprise Bean
○※
○

ローカルインタフェースを持つEnterprise Bean
（別名による検索）
○
○

J2EEリソース
○※
○

J2EEリソース
（別名による検索）
×
○

（凡例）　○：検索できる　×：検索できない

注※　java:comp/envでのルックアップの場合，ラウンドロビン検索はしません。ルックアップを実行した自身のJ2EEサーバだけから検索されます。

InitialContextFactoryの実装を委譲しているクラスは，次の方法で指定します。両方指定した場合は引数で指定した方が有効になります。

usrconf.propertiesのjava.naming.factory.initialキーに指定する。

InitialContextを生成するときの引数(Hashtable)で，java.naming.factory.initialキーに指定する。

8.5　ネーミング管理機能でのキャッシング

J2EEサービスのネーミング管理機能には，キャッシング機能があります。キャッシング機能とは，JNDIを介してEJBホームオブジェクトリファレンスを検索した場合に，該当オブジェクトをキャッシュに一時的に保存し，以降，同一のオブジェクトを検索するときには，キャッシュに保存されたオブジェクトを返す機能です。

この節では，キャッシングの流れ，およびキャッシュ領域のクリアについて説明します。

なお，ネーミング管理機能でのキャッシングをするための設定は，J2EEサーバ，WebコンテナサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の次の説明を参照してください。

J2EEサーバの動作設定のカスタマイズ

Webコンテナサーバの動作設定のカスタマイズ

EJBクライアントアプリケーションのプロパティの設定

＜この節の構成＞

8.5.1　キャッシングの流れ

8.5.2　ネーミングで使用したキャッシュのクリア

8.5.3　ネーミングでのキャッシングの注意事項

8.5.1　キャッシングの流れ

次の図に示すような流れで，ネーミングはキャッシングされます。

図8-11　ネーミングのキャッシングの流れ

キャッシングの流れを説明します。この流れでは，同じJ2EEサーバ上の二つのJ2EEアプリケーションから，同じ名前「Count」でEJBホームオブジェクトのリファレンスをルックアップします。1.～5.がJ2EEアプリケーション1から実行される処理，6.～9.がJ2EEアプリケーション2から実行される処理です。

J2EEアプリケーション1が，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーション1が，javax.naming.InitialContextクラスのインスタンスに対して，EJBホームオブジェクトリファレンスの検索（ルックアップ）を要求します。このとき，名前に「Count」を指定します。

要求を受けたネーミング管理機能が，CORBAネーミングサービスの名前空間からEJBホームオブジェクトリファレンスを検索します。

ネーミング管理機能は，検索結果として，EJBホームオブジェクトのリファレンスを取得します。

ネーミング管理機能が，取得したEJBホームオブジェクトのリファレンスをキャッシュに保存します。

同じプロセス上にあるJ2EEアプリケーション2が，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーション2が，javax.naming.InitialContextクラスのインスタンスに対して，EJBホームオブジェクトリファレンスの検索（ルックアップ）を要求します。このとき，名前に，2.で指定した名前と同じ名前「Count」を指定します。

要求を受けたネーミング管理機能が，キャッシュから，EJBホームオブジェクトリファレンスを検索します。

ネーミング管理機能が，検索結果として，キャッシュからEJBホームオブジェクトのリファレンスを取得します。

8.5.2　ネーミングで使用したキャッシュのクリア

ネーミングで使用しているキャッシュは，クリアできます。ただし，クリアするキャッシュサイズは設定できません。ここでは，キャッシュクリアが行われるタイミングと，クリアされる範囲について説明します。

＜この項の構成＞

(1)　キャッシュクリアのタイミング

(2)　キャッシュクリアの範囲

(1)　キャッシュクリアのタイミング

キャッシュの内容は次のどちらかのタイミングでクリアされます。

JNDIおよびRMI-IIOPのAPIで例外が発生した場合，キャッシュのクリアを強制的に実施します。

システムプロパティに指定した値の間隔でキャッシュをクリアします（デフォルト値は0秒で，キャッシュはクリアされません）。

(2)　キャッシュクリアの範囲

キャッシュクリアの範囲は2とおりあります。

キャッシュ領域をすべてクリアします。

無効なキャッシュ領域だけをクリアします。

1.の場合，キャッシュの全領域をクリアします。一方，2.の場合は，定期的に，キャッシュに保存されたオブジェクトが有効かどうかを確認し，無効なオブジェクトだけをキャッシュからクリアします。また，2.の場合，キャッシュクリアと同じタイミングで，一度検索を行ったCORBAネーミングサービスの状態を監視します。これによって，一度検索されたCORBAネーミングサービスの場合，CORBAネーミングサービスがダウンしたあとは，該当するCORBAネーミングサービスの検索を実施しません。また，CORBAネーミングサービスが再起動すると，該当するCORBAネーミングサービスの検索を自動的に開始します。

参考

EJBホームオブジェクトの再接続機能を使用している場合，J2EEサーバを再起動したあとでも，キャッシュは無効になりません。

このため，無効なキャッシュ領域だけをクリアする指定をしているときでも，CORBAネーミングサービスのEJBホームオブジェクトのオブジェクトリファレンスは，キャッシュ領域から削除されません。

EJBホームオブジェクトのリファレンスの検索（ルックアップ）で，削除されなかったキャッシュ上のオブジェクトリファレンスがそのまま使用できます。

8.5.3　ネーミングでのキャッシングの注意事項

ネーミングのキャッシングに関する注意事項について説明します。

アプリケーションでEJBホームオブジェクトリファレンスやJDBCデータソースをキャッシングしている場合，ネーミングでのキャッシングを無効にすることを推奨します。

キャッシュを定期的にクリアするには，簡易構築定義ファイルで設定します。論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタで設定します。

ejbserver.jndi.cache.interval.clear.option

キャッシュをクリアする範囲を指定します。

ejbserver.jndi.cache

キャッシュを実行するかどうかを指定します。ここでは「ON」を設定してください。

ejbserver.jndi.cache.interval

キャッシュのクリア間隔を指定します。

論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，プロパティ「ejbserver.jndi.cache.interval.clear.option」に「check」を設定している場合，CORBAネーミングサービスの監視は，プロパティ「ejbserver.jndi.cache.interval」に指定したキャッシュクリアのタイミングだけで行われます。CORBAネーミングサービスの再起動後，CORBAネーミングサービスの回復を検知するためには，最大で，プロパティ「ejbserver.jndi.cache.interval」に設定した時間が必要です。

キャッシング機能を使用している場合，キャッシュにEJBホームオブジェクトのオブジェクトリファレンスが保存された状態で，EJBホームオブジェクトが保存されているJ2EEサーバがダウンするか，またはJ2EEアプリケーションの再デプロイが実行されると，キャッシュに保存されているEJBホームオブジェクトのオブジェクトリファレンスは無効な情報となります。この状態でEJBホームオブジェクトの検索要求（lookup）を受けると，キャッシュ上の無効なオブジェクトリファレンスが検索要求元に返却されます。このオブジェクトリファレンスに対して，javax.rmi.PortableRemoteObject.narrow()メソッド，またはcreateメソッドなどのメソッドを実行すると，CORBA例外（org.omg.CORBA.OBJECT_NOT_EXISTなど）が発生する場合があります。なお，CORBA例外が発生した場合，キャッシュ情報はすべて削除されます。次回の検索要求（lookup）ではCORBAネーミングサービスへ接続して有効な情報が取得されます。

CTMを使用している場合に，指定した値の間隔で無効なキャッシュ領域だけをクリアするとき，J2EEサーバやJ2EEアプリケーションが停止していても，グローバルCORBAネーミングサービスのEJBホームオブジェクトのオブジェクトリファレンスはキャッシュ領域からクリアされません。EJBホームオブジェクトの検索要求（lookup）を受けると，クリアされなかったキャッシュ上のオブジェクトリファレンスが検索要求元に返却されます。J2EEアプリケーションが再度開始されていた場合は，キャッシュしたオブジェクトリファレンスはそのまま使用できます。J2EEアプリケーションが再度開始されていない場合は，返却されたオブジェクトリファレンスに対して，createメソッドなどのメソッドを実行すると，CORBA例外（org.omg.CORBA.NO_IMPLEMENT）などが発生します。
なお，CORBA例外が発生した場合，キャッシュ情報はすべて削除されます。J2EEアプリケーションが再開始している場合は，次回の検索要求（lookup）でグローバルCORBAネーミングサービスに接続して有効な情報が取得されます。

8.6　CORBAネーミングサービスの切り替え

ネーミング管理機能では，JNDIを介して分散オブジェクトを検索するときに，JNDIが接続するCORBAネーミングサービスの切り替えができます。切り替えは，InitialContextクラスのインスタンスに対して，プリフィックス「corbaname:」を付与した名前をlookupメソッドの引数に渡すことで実現できます。

CORBAネーミングサービスの切り替えの流れを次の図に示します。

図8-12　CORBAネーミングサービスの切り替えの流れ

ネーミングサービスの切り替えの流れを説明します。この流れでは，J2EEアプリケーションから，プリフィックス「corbaname:」を付与したルックアップを2回実行します。プリフィックスの後ろに指定したホスト名に応じて，接続するCORBAネーミングサービスが切り替えられます。

J2EEアプリケーションが，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーションが，javax.naming.InitialContextクラスのインスタンスに対して，オブジェクトの検索（ルックアップ）を要求します。このとき，プリフィックス「corbaname:」を付与した名前「corbaname::MyHost:900#Count1」を指定します。

要求を受けたネーミング管理機能から「MyHost:900」のCORBAネーミングサービスへの接続が実行されます。接続後，ルックアップで指定した名前のEJBホームのオブジェクトリファレンス「Count1」が検索されます。

J2EEアプリケーションから，InitialContextクラスのインスタンスに対して，オブジェクトの検索（ルックアップ）を要求します。このとき，プリフィックス「corbaname:」を付与した名前「corbaname::MyHost:901#Count2」を指定します。

要求を受けたネーミング管理機能から「MyHost:901」のCORBAネーミングサービスへの接続が実行されます。接続後，ルックアップで指定した名前のEJBホームのオブジェクトリファレンス「Count2」が検索されます。

CORBAネーミングサービスの切り替えは，サーバ管理コマンドを使用した，Enterprise Beanリファレンスの解決で行います。操作については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のJ2EEアプリケーションのプロパティ設定に関する内容を参照してください。

なお，CORBAネーミングサービスがローカルホスト上で動作する場合，ネーミングサービスのホスト名に関する設定では，"localhost"の文字列ではなく，マシン名またはIPアドレスを指定してください。

ネーミングサービスのホスト名の設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

9.　リソース接続とトランザクション管理

この章では，Application Serverが接続できるリソースと，リソースへの接続について説明します。また，リソース接続でのトランザクション管理についても説明します。

＜この章の構成＞

9.1　リソース接続とトランザクション管理の概要

9.2　リソースへの接続の概要

9.3　トランザクション管理の概要

9.4　データベースへの接続

9.5　データベース上のキューとの接続

9.6　OpenTP1との接続（SSPまたはTP1/Message Queue）

9.7　SMTPサーバとの接続

9.8　JavaBeansリソースの利用

9.9　そのほかのリソースとの接続

9.10　パフォーマンスチューニングのための機能

9.11　フォールトトレランスのための機能

9.12　コネクションプールのクラスタ化

9.13　そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合）

9.14　リソースへの接続テスト

9.15　ファイアウォール環境での運用のための機能

9.16　リソースに接続するための実装

9.17　トランザクション管理機能の実装

9.18　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項

9.1　リソース接続とトランザクション管理の概要

J2EEサーバ上のJ2EEアプリケーションに含まれるEJB，サーブレット，JSPなどのJ2EEコンポーネントからは，データベースやOpenTP1などのリソースに接続できます。データベースやOpenTP1などのリソースに接続する場合は，リソースアダプタを使用します。Application Serverでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用できます。SMTPサーバやJavaBeansリソースなどのリソースに，リソースアダプタを使用しないで接続する機能も提供しています。

また，Application Serverでは，リソースに効率的かつ信頼性の高い方法でアクセスするために，コネクションプーリングやトランザクション管理の機能を提供しています。コネクションプーリングを使用すると，リソースに対するコネクションをプーリングして，効率的にコネクションを使用できます。また，障害が発生したコネクションを適切にコネクションプールから取り除きます。また，トランザクション管理の機能を使用すると，トランザクションマネジャが，EJBのメソッドごとに指定するトランザクション属性やJTAインタフェース（UserTransaction）による指示に基づいて，リソースアクセスのトランザクションを適切に制御します。複数のリソースに対してトランザクション管理をする場合には，グローバルトランザクションを使用します。グローバルトランザクションを使用すると，2フェーズコミットプロトコルによってトランザクションが管理されるため，リソース間で更新の整合性が確保されます。

コネクションプーリング，およびトランザクション管理の機能を使用したリソースへの接続の例を次の図に示します。

図9-1　コネクションプーリングおよびトランザクション管理の機能を使用したリソースへの接続の例

9.2　リソースへの接続の概要

この節では，リソースの種類ごとの接続方法と，接続に使用するリソースアダプタの種類について説明します。

また，リソースアダプタを使用する場合の説明として，リソースアダプタの使用方法，機能および注意事項についても説明します。

＜この節の構成＞

9.2.1　リソースへの接続方法

9.2.2　リソースアダプタの種類

9.2.3　リソースアダプタの使用方法

9.2.4　リソースアダプタの機能

9.2.5　リソースアダプタについての注意事項

9.2.6　リソースアダプタ以外の機能

9.2.1　リソースへの接続方法

Application Serverでは，リソースの種類によって，接続にリソースアダプタを使用するものと，リソースアダプタを使用しないものがあります。それぞれのリソースへの接続方法の概要を，リソースの種類ごとに説明します。

＜この項の構成＞

(1)　接続にリソースアダプタを使用するリソース

(2)　接続にリソースアダプタを使用しないリソース

(1)　接続にリソースアダプタを使用するリソース

接続にリソースアダプタを使用するリソースを次に示します。

データベース

データベースと接続できます。データベースと接続するためには，リソースアダプタとしてDB Connectorを使用します。

DB Connectorで接続できるのは，次のデータベースです。

HiRDB

Oracle

SQL Server※

XDM/RD E2

注※　SQL Serverと接続できるのはWindowsの場合だけです。

データベースとの接続については，「9.4.1　DB Connectorによる接続の概要」を参照してください。

データベース上のキュー

Cosminexus RMで使用するデータベース上のキューと接続できます。データベース上のキューと接続するためには，リソースアダプタとしてDB Connector for Cosminexus RMおよびCosminexus RMを使用します。

DB Connector for Cosminexus RMおよびCosminexus RMで接続できるのは，次のデータベースです。

HiRDB

Oracle

データベース上のキューとの接続については，「9.5.1　DB Connector for Cosminexus RMとCosminexus RMによる接続の概要」を参照してください。

OpenTP1

OpenTP1のSPP，TP1/Message Queueと接続できます。OpenTP1のSPPと接続するには，リソースアダプタとしてuCosminexus TP1 Connectorを使用します。また，TP1/Message Queueと接続するには，リソースアダプタとしてTP1/Message Queue - Accessを使用します。

OpenTP1との接続の詳細については，接続に使用するリソースアダプタごとに説明しています。参照先を次の表に示します。

表9-1　OpenTP1接続の詳細説明の参照先

接続方法 | 参照先
uCosminexus TP1 Connectorを利用した接続 | 「9.6.1　uCosminexus TP1 Connectorによる接続」
TP1/Message Queue - Accessを利用した接続 | 「9.6.2　TP1/Message Queue - Accessによる接続」

そのほかのリソース

リソースの種類に関係なく，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタで接続できるリソースに接続できます。

使用できるリソースアダプタについては，「9.9　そのほかのリソースとの接続」を参照してください。また，Connector 1.5仕様に準拠したリソースアダプタを使用する場合に，Application Serverで使用できる機能については，「9.13　そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合）」を参照してください。

(2)　接続にリソースアダプタを使用しないリソース

接続にリソースアダプタを使用しないリソースについて次に示します。

SMTPサーバ

SMTPサーバと接続できます。SMTPサーバとの接続については，「9.7　SMTPサーバとの接続」を参照してください。

JavaBeans

リソースとしてJavaBeansリソースを利用できます。JavaBeansリソースの利用については，「9.8　JavaBeansリソースの利用」を参照してください。

9.2.2　リソースアダプタの種類

Application Serverでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用できます。

ここでは，それぞれの仕様に準拠したリソースアダプタについて説明します。また，リソースアダプタのDDのスキーマの違いについても説明します。

＜この項の構成＞

(1)　Connector 1.0仕様に準拠したリソースアダプタ

(2)　Connector 1.5仕様に準拠したリソースアダプタ

(3)　Connector 1.0仕様とConnector 1.5仕様のリソースアダプタのスキーマの違い

(1)　Connector 1.0仕様に準拠したリソースアダプタ

Cosminexusを含む日立の製品では，Connector 1.0仕様に準拠したリソースアダプタを提供しています。

Application Serverでは，次のリソースアダプタを使用できます。

DB Connector

DB Connector for Cosminexus RMおよびCosminexus RM

uCosminexus TP1 Connector

TP1/Message Queue - Access

これらのリソースアダプタでは，Connector 1.0仕様に対応する機能が使用できます。

なお，DB ConnectorおよびDB Connector for Cosminexus RMでは，Connector 1.0仕様に対応する機能に加えて，Cosminexusで追加された機能を使用できます。使用できる機能については，「9.2.4　リソースアダプタの機能」を参照してください。

ポイント

Application Serverでは，これらのリソースアダプタ以外にも，標準仕様のConnector 1.0仕様に準拠したリソースアダプタを使用できます。ただし，標準仕様のConnector 1.0仕様に準拠したリソースアダプタを使用する場合，DD（ra.xml）の次のタグの設定内容は無視されます。

<security-permission>
セキュリティの設定にはserver.policyファイルを使用してください。

<authentication-mechanism>
設定内容に関係なく，BasicPasswordが適用されます。

(2)　Connector 1.5仕様に準拠したリソースアダプタ

Application Serverでは，Connector 1.5仕様に準拠したリソースアダプタを使用できます。Application Serverで使用できるのは，Connector 1.5仕様の規約のうち，次の規約に対応した機能です。

Lifecycle Management

Work Management

メッセージインフロー

Connector 1.5仕様に準拠したリソースアダプタについては，「9.9.1　そのほかのリソースとの接続に使用するリソースアダプタ」を参照してください。

(3)　Connector 1.0仕様とConnector 1.5仕様のリソースアダプタのスキーマの違い

Connector 1.0仕様に準拠したリソースアダプタと，Connector 1.5仕様に準拠したリソースアダプタの，DDのスキーマの違いについて説明します。リソースアダプタのDDは，ra.xmlです。

Connector 1.0仕様のスキーマからConnector 1.5仕様のスキーマに対する主な変更点を次の表に示します。ここで示す以外の変更点については，Connector 1.5仕様を参照してください。

表9-2　Connector 1.0仕様のスキーマからConnector 1.5仕様のスキーマに対する主な変更点

Connector 1.5仕様で変更になった内容
Connector 1.5仕様のDDの内容

javax.resource.spi.ResourceAdapterインタフェースの実装クラスの指定
<connector>-<resourceadapter>-<resourceadapter-class>
<connector>-<resourceadapter>-<config-property>

Outboundリソースアダプタの指定
<connector>-<resourceadapter>-<outbound-resourceadapter>

Inboundリソースアダプタの指定
<connector>-<resourceadapter>-<inbound-resourceadapter>

adminobjectの指定
<connector>-<resourceadapter>-<adminobject>

Connector 1.5仕様で変更になった内容の概要を説明します。

javax.resource.spi.ResourceAdapterインタフェースの実装クラスの指定

javax.resource.spi.ResourceAdapterインタフェースの実装クラスと，そのコンフィグレーションプロパティを指定する要素が追加されました。javax.resource.spi.ResourceAdapterインタフェースの追加に伴って実現できる機能については，「9.13.1　リソースアダプタのライフサイクル管理」および「9.13.2　リソースアダプタのワーク管理」を参照してください。

Outboundリソースアダプタの指定

Outboundのリソースアダプタを明示的に定義するための要素が追加されました。

なお，Outboundリソースアダプタでは，一つのDD内にコネクション定義を複数指定できます。コネクション定義の複数指定については，「9.13.5　コネクション定義の複数指定」を参照してください。

Inboundリソースアダプタの指定

Inboundのリソースアダプタを明示的に定義するための要素が追加されました。

adminobjectの指定

管理対象オブジェクトについての情報を指定する要素が追加されました。

9.2.3　リソースアダプタの使用方法

ここでは，リソースアダプタの使用方法について説明します。リソースアダプタを使用してリソースと接続する方法には，次の2種類があります。

J2EEリソースアダプタとしてデプロイして使用する方法

J2EEアプリケーションに含めて使用する方法

ここでは，それぞれの方法について説明します。

＜この項の構成＞

(1)　J2EEリソースアダプタとしてデプロイして使用する

(2)　J2EEアプリケーションに含めて使用する

(3)　使用方法ごとに使用できるリソースアダプタ

(1)　J2EEリソースアダプタとしてデプロイして使用する

J2EEサーバにインポートしたリソースアダプタを，共有スタンドアロンモジュールとしてデプロイします。そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションで使用できるようになります。J2EEサーバ上に配置されたリソースアダプタをJ2EEリソースアダプタといいます。

(2)　J2EEアプリケーションに含めて使用する

リソースアダプタをJ2EEアプリケーションに含めて使用します。同じJ2EEアプリケーションに含まれるEJBやWARから，リソースアダプタを使用できます。リソースアダプタをJ2EEアプリケーションに含めて使用する手順については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定の流れ（アプリケーションに含めて使用する場合）についての説明を参照してください。

なお，J2EEアプリケーションに含めることができるリソースアダプタには，制限があります。J2EEアプリケーションに含めることができるリソースアダプタについては，「(3)　使用方法ごとに使用できるリソースアダプタ」を参照してください。

(3)　使用方法ごとに使用できるリソースアダプタ

リソースアダプタは，Cosminexusのバージョンに適したリソースアダプタに統一する必要があります。また，Cosminexusでは，Connector 1.0仕様，およびConnector 1.5仕様に準拠したリソースアダプタをデプロイして使用できます。ただし，J2EEアプリケーションに含めて使用する場合，次のリソースアダプタは使用できません。

XATransactionに設定したリソースアダプタ

ネイティブライブラリを含むリソースアダプタ

起動順序の制御が必要なリソースアダプタ

Cosminexus独自の機能を使用しているリソースアダプタ

Cosminexusが提供するリソースアダプタの使用方法を次の表に示します。

表9-3　Cosminexusが提供するリソースアダプタの使用方法

リソースアダプタ | 使用方法
リソースアダプタをJ2EEリソースアダプタとしてデプロイして使用する | リソースアダプタをJ2EEアプリケーションに含めて使用する
DB Connector | NoTransactionまたはLocalTransactionに設定 | ○ | ○
XATransactionに設定 | ○ | －
クラスタ構成 | ルートリソースアダプタ | ○ | －
メンバリソースアダプタ | ○ | －
uCosminexus TP1 Connector | NoTransactionまたはLocalTransactionに設定 | ○ | ○
XATransactionに設定 | ○ | －
TP1/Message Queue - Access | ○ | －
Cosminexus RM | Cosminexus RM（データベースなし） | ○ | －
Cosminexus RM（データベースあり） | ○ | －
DB Connector for Cosminexus RM | ○ | －

（凡例）　○：使用できる　－：使用できない

使用できないリソースアダプタに対して次の操作をすると，エラーメッセージが出力されて，操作に失敗します。

J2EEアプリケーションに含めてインポートする

J2EEアプリケーションに含めて接続テストまたは開始する

9.2.4　リソースアダプタの機能

ここでは，次のリソースアダプタの機能について説明します。

DB Connector

コネクションプールのクラスタ化で使用するDB Connector（ルートリソースアダプタおよびメンバリソースアダプタ）

DB Connector for Cosminexus RM

Connector 1.5仕様に準拠したリソースアダプタ

なお，これ以外のリソースアダプタの機能については，使用するリソースアダプタのドキュメントを参照してください。

データベース接続で使用できる機能を，リソースアダプタの種類ごとに次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表9-4　リソースアダプタの種類ごとの使用できる機能

機能
リソースアダプタの種類

参照先

DB Connector
ルートリソースアダプタ
メンバリソースアダプタ
DB Connector for Cosminexus RM
Connector 1.5に準拠したリソースアダプタ※

コネクションプーリング
○
×
◎
○
○
9.10.1

コネクションプールのウォーミングアップ
○
×
○
○
○

コネクションプール数調節機能
○
×
○
○
○

コネクションシェアリング・アソシエーション
○
×
○
○
○
9.10.2

ステートメントプーリング
○
×
○
○
○
9.10.3

DataSourceオブジェクトのキャッシング
○
○
×
○
×
9.10.6

DB Connectorのコンテナ管理でのサインオンの最適化
○
×
○
○
×
9.10.7

コネクション障害検知
○
×
◎
○
○
9.11.1

コネクション枯渇時のコネクション取得待ち
○
×
◎
○
○
9.11.2

コネクション取得リトライ
○
×
×
○
○
9.11.3

コネクションプールの情報表示
○
×
○
○
×
9.11.4

コネクションプールのクリア
○
×
○
○
○
9.11.5

コネクションの自動クローズ
○
×
○
○
○
9.11.6

コネクションスイーパ
○
×
○
○
○
9.11.7

ステートメントキャンセル
○
×
○
○
○
9.11.8

障害調査用SQLの出力
◎
×
◎
◎
×
9.11.10

オブジェクトの自動クローズ
○
×
○
○
×
9.11.11

コネクションプールの一時停止
×
×
○
×
×
9.12

コネクションプールの再開
×
×
○
×
×

コネクションプールの状態表示
○
×
○
○
○

リソースアダプタのライフサイクル管理
×
×
×
×
○
9.13.1

リソースアダプタのワーク管理
×
×
×
×
○
9.13.2

メッセージインフロー
×
×
×
×
○
9.13.3

管理対象オブジェクトのルックアップ
×
×
×
×
○
9.13.4

コネクション定義の複数指定
×
×
×
×
○
9.13.5

リソースへの接続テスト
○
○
○
○
○
9.14

J2EEリソースへの別名付与
○
○
×
○
○
8.3

コネクションIDのPRFトレース
○
○
○
○
－
17.10

クライアントAPIで発生した例外の通知
○
○
○
○
－
－

（凡例）　◎：必ず有効になる　○：使用できる　×：使用できない　－：該当しない

注※　この表で示しているのはApplication Serverが提供する機能が使用できるかどうかです。リソースアダプタが提供する機能については，使用するリソースアダプタのドキュメントを参照してください。

9.2.5　リソースアダプタについての注意事項

ここでは，リソースアダプタについての注意事項を説明します。

デプロイ方法によって使用できない機能

リソースアダプタをJ2EEアプリケーションに含めて使用する場合，J2EEアプリケーションに含めたリソースが更新されても，次の機能は有効になりません。

J2EEアプリケーションの更新検知

J2EEアプリケーションのリロード

詳細は，「7.5.1(5)　リロードの注意事項および制限事項」を参照してください。

リソースアダプタの表示名についての注意事項

J2EEアプリケーション内のEJBやWARは，J2EEリソースアダプタとしてデプロイするリソースアダプタ，およびJ2EEアプリケーションに含めて使用するリソースアダプタを同時に使用できます。ただし，一つのJ2EEサーバで同じ表示名のリソースアダプタを二つ以上使用することはできません。一つのJ2EEサーバに同じ表示名のリソースアダプタを二つ以上使用しようとすると，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。リソースアダプタの開始に失敗する手順の例を次に示します。

例1.

「Rar1」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

「Rar1」という表示名のリソースアダプタを含めたJ2EEアプリケーションをインポートする。

例2.

「Rar2」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

「Rar2」という表示名のリソースアダプタを，インポート済みのJ2EEアプリケーションに追加する。

例3.

「Rar3」という表示名のリソースアダプタを含めたJ2EEアプリケーションをインポートする。

「Rar3」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

リソースアダプタのオプショナル名についての注意事項

同じオプショナル名で複数のリソースアダプタをデプロイしている場合，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。

9.2.6　リソースアダプタ以外の機能

ここでは，リソースアダプタ以外で実現される機能について説明します。ここで説明する機能は，リソースアダプタの種類に関係なく使用できます。

リソースアダプタ以外で実現される機能を，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表9-5　リソースアダプタ以外の機能

機能 | 参照先
ライトトランザクション | 9.10.4
インプロセストランザクションサービス | 9.10.5
受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合） | 9.10.8
トランザクションタイムアウト | 9.11.8
トランザクションリカバリ | 9.11.9

9.3　トランザクション管理の概要

この節では，トランザクション管理の概要について説明します。

リソース接続時のトランザクションを管理する方法には，Application Serverで管理する方法と，ユーザが直接管理する方法があります。

Application Serverでトランザクションを管理する場合，Application Serverのトランザクションマネジャを使用してトランザクションを管理できます。

ポイント

リソースのうち，SMTPサーバおよびJavaBeansリソースについては，トランザクション管理の対象外です。

参考

EJBクライアントアプリケーションでもトランザクションを開始できます。EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項については，「9.18　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」を参照してください。

＜この節の構成＞

9.3.1　リソース接続でのトランザクション管理の方法

9.3.2　ローカルトランザクションとグローバルトランザクション

9.3.3　リソースごとに使用できるトランザクションの種類

9.3.4　トランザクションサービスで提供する機能

9.3.5　システム例外発生時のトランザクションの動作

9.3.6　トランザクションマネジャの取得

9.3.1　リソース接続でのトランザクション管理の方法

リソース接続でのトランザクションの管理方法には，Application Serverが管理する方法と，Application Serverが管理しない方法（ユーザが直接管理する方法）があります。ここでは，それぞれのトランザクションの管理方法について説明します。

＜この項の構成＞

(1)　Application Serverが管理するトランザクション

(2)　ユーザが直接管理するトランザクション（Application Serverが管理しないトランザクション）

(1)　Application Serverが管理するトランザクション

Application Serverのトランザクションマネジャ経由でトランザクションを管理する方法です。ユーザは，javax.transaction.UserTransactionインタフェースのAPIを操作するか，EJBメソッドのCMT属性を設定することで，トランザクションを管理します。

UserTransactionインタフェースによる管理
サーブレット，JSP，またはEJB（BMT）から，javax.transaction.UserTransactionインタフェースのAPIを発行することで，トランザクションを管理できます。BMTの詳細については，「5.5.1　BMT」を参照してください。

EJBのCMT属性による管理
EJB（CMT）のメソッド単位で指定するトランザクション属性によって，トランザクションを管理できます。CMTの詳細については，「5.5.2　CMT」を参照してください。

Application Serverがトランザクションを管理する場合，トランザクションの種類としてローカルトランザクションまたはグローバルトランザクションを選択できます。Application Serverが管理するトランザクションの種類については，「9.3.2　ローカルトランザクションとグローバルトランザクション」を参照してください。

(2)　ユーザが直接管理するトランザクション（Application Serverが管理しないトランザクション）

リソース固有のAPIによって，ユーザが直接トランザクションを管理する方法です。例えば，データベースにJDBCインタフェースで接続する場合，java.sql.ConnectionインタフェースのsetAutoCommit()，commit()，rollback()などのAPIをユーザが直接操作します。

9.3.2　ローカルトランザクションとグローバルトランザクション

Application Serverが管理するトランザクションを使用する場合，Application Serverのトランザクションマネジャと，リソースを管理するリソースマネジャ（DBMSなど）が連携して，トランザクションを管理します。この場合，トランザクションの種類として，ローカルトランザクションとグローバルトランザクションのどちらかを選択します。

ローカルトランザクションと，グローバルトランザクションについて説明します。

＜この項の構成＞

(1)　ローカルトランザクション

(2)　グローバルトランザクション

(3)　ライトトランザクション機能とトランザクションの管理方法の関係

(1)　ローカルトランザクション

トランザクション管理を行うリソースが一つだけの場合に，ローカルトランザクションを使用します。ローカルトランザクションを使用する場合，トランザクションの決着はリソースマネジャが行います。

(2)　グローバルトランザクション

トランザクション管理を行うリソースが複数ある場合に，グローバルトランザクションを使用します。グローバルトランザクションを使用する場合，トランザクションマネジャが複数のリソースのトランザクションを調整し，整合性が崩れないように決着します。トランザクションの決着には，2フェーズコミットプロトコルが使用されます。なお，グローバルトランザクション使用時には，インプロセストランザクションサービスを使用します。インプロセストランザクションサービスについては，「9.10.5　インプロセストランザクションサービス」を参照してください。

グローバルトランザクションには比較的高い処理コストが掛かりますので，トランザクション管理を行うリソースが一つだけの場合には，ローカルトランザクションを使用することをお勧めします。

なお，デフォルトではライトトランザクション機能※が有効になっているため，グローバルトランザクションを使用することはできません。グローバルトランザクションを使用するには，ライトトランザクション機能を無効にする必要があります。

注※

ライトトランザクションの詳細については，「9.10.4　ライトトランザクション」を参照してください。

(3)　ライトトランザクション機能とトランザクションの管理方法の関係

ライトトランザクション機能とは，ローカルトランザクションに，最適化された環境を提供する機能です。

トランザクションの管理方法とライトトランザクションの対応を次の表に示します。

表9-6　トランザクションの管理方法とライトトランザクションの対応

トランザクションの管理方法 | ライトトランザクション有効 | ライトトランザクション無効
Application Serverが管理するトランザクション | ローカルトランザクション | ○ | ○
グローバルトランザクション | × | ○
Application Serverが管理しないトランザクション | ○ | ○

（凡例）　○：使用できる　　×：使用できない

ライトトランザクション機能については，「9.10.4　ライトトランザクション」を参照してください。

9.3.3　リソースごとに使用できるトランザクションの種類

ここでは，次に示すリソースごとに使用できるトランザクションの種類について説明します。

データベース（接続方法：DB Connector）

データベース上のキュー（接続方法：DB Connector for Cosminexus RMとCosminexus RM）

OpenTP1（接続方法：uCosminexus TP1 ConnectorまたはTP1/Message Queue - Access）

そのほかのリソース（接続方法：Connector 1.5仕様に準拠したリソースアダプタ）

それぞれのリソースで使用できるトランザクションの種類は，次の項目の設定内容によって決まります。

リソースアダプタ単位で設定するトランザクションサポートレベル

次に示す3種類のトランザクションサポートレベルごとに，使用できるトランザクションの種類が異なります。

NoTransaction
リソースをトランザクション管理しません。

LocalTransaction
リソースをローカルトランザクションでトランザクション管理します。

XATransaction
リソースをグローバルトランザクションでトランザクション管理します。

なお，トランザクションサポートレベルの設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ライトトランザクション機能の有効／無効

ライトトランザクション機能を有効にしているか無効にしているかによって，使用できるトランザクションの種類が異なります。

＜この項の構成＞

(1)　データベース接続の場合

(2)　データベース上のキューとの接続の場合

(3)　OpenTP1接続の場合

(4)　そのほかのリソースの場合

(1)　データベース接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表9-7　使用できるトランザクションの種類（データベース接続の場合）

接続方法
トランザクションサポートレベル
ライトトランザクション機能

有効
無効

DB Connector（DBConnector_HiRDB_Type4_CP.rar）
（DBConnector_DABJ_CP.rar）
（DBConnector_Oracle_CP.rar）
（DBConnector_SQLServer_CP.rar）
（DBConnector_SQLServer2005_CP.rar）
（DBConnector_CP_ClusterPool_Root.rar）
（DBConnector_Oracle_CP_ClusterPool_Member.rar）
NoTransaction
なし
なし

LocalTransaction
ローカル
ローカル

DB Connector（DBConnector_HiRDB_Type4_XA.rar）
（DBConnector_DABJ_XA.rar）
（DBConnector_Oracle_XA.rar）
XATransaction
－
グローバル

（凡例）

グローバル：グローバルトランザクション

ローカル：ローカルトランザクション

なし：トランザクション管理なし

－：指定できない

(2)　データベース上のキューとの接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表9-8　使用できるトランザクションの種類（データベース上のキューとの接続の場合）

接続方法
トランザクションサポートレベル
ライトトランザクション機能

有効
無効

DB Connector for Cosminexus RMとCosminexus RM
（DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar）
（DBConnector_DABJ_CP_Cosminexus_RM.rar）
（DBConnector_Oracle_CP_Cosminexus_RM.rar）
NoTransaction
なし
なし

LocalTransaction
ローカル
ローカル

DB Connector for Cosminexus RMとCosminexus RM
（DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar）
（DBConnector_DABJ_XA_Cosminexus_RM.rar）
（DBConnector_Oracle_XA_Cosminexus_RM.rar）
XATransaction
－
グローバル

（凡例）

グローバル：グローバルトランザクション

ローカル：ローカルトランザクション

なし：トランザクション管理なし

－：指定できない

(3)　OpenTP1接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表9-9　使用できるトランザクションの種類（OpenTP1接続の場合）

接続方法 | トランザクションサポートレベル | ライトトランザクション機能
有効 | 無効
uCosminexus TP1 Connector | NoTransaction | なし | なし
LocalTransaction | ローカル | ローカル
XATransaction | － | グローバル
TP1/Message Queue - Access | NoTransaction | なし | なし
LocalTransaction | ローカル | ローカル
XATransaction | － | グローバル

（凡例）

グローバル：グローバルトランザクション

ローカル：ローカルトランザクション

なし：トランザクション管理なし

－：指定できない

(4)　そのほかのリソースの場合

Connector 1.5仕様に準拠したリソースアダプタで使用できるトランザクションの種類については，「9.9.2　そのほかのリソースとの接続で使用できる機能」を参照してください。

9.3.4　トランザクションサービスで提供する機能

トランザクションサービスでは，次に示す機能を提供します。なお，Application Serverでは，トランザクションサービスはJ2EEサーバのインプロセスで起動します。

グローバルトランザクションの開始，コミット決着，ロールバック決着の制御
2フェーズコミットプロトコルによってトランザクション処理を制御します。2フェーズコミットプロトコルとは，同期点での処理をプリペア処理（資源のアップデート準備）とコミット処理（資源のアップデート処理）という2段階に分ける方法です。2フェーズコミットプロトコルでは，DBMSなどの複数のリソースオブジェクトに対して同期を取り，コミットまたはロールバックができます。また，2フェーズコミットプロトコルではトランザクション処理中に障害が発生した場合でも，すべてのリソースオブジェクトを矛盾なく自動的にロールバックできます。

トランザクションコンテキストの伝播（RMI-IIOPによるEnterprise Bean呼び出し）
グローバルトランザクションの状態を表すトランザクションコンテキストを管理します。例えば，サーブレット/JSPなどのクライアントがリモートのEnterprise Beanのメソッドを呼び出したとき，クライアント側のトランザクションコンテキストをサーバ側のEnterprise Beanに伝達します。

ステータスファイルを使用したトランザクション情報の管理と障害発生後のJ2EEサーバの再起動によるシステム回復
システム障害でJ2EEサーバが停止したときに実行中だったアプリケーションプログラムのトランザクション処理を回復して，ロールバックまたはコミットします。トランザクションをロールバックするか，コミットするかは，トランザクション処理がどこまで進んでいたかで決まります。トランザクション処理が，2フェーズコミットのうちの1フェーズ目の完了前まで進んでいる場合には，グローバルトランザクションをロールバックします。2フェーズコミットのうちの1フェーズ目が完了している場合には，ルートトランザクションブランチでの決定に従って，グローバルトランザクションをロールバック，またはコミットします。

ステータスファイルの二重化
ステータスファイルの二重化の機能を使用した場合，一方のステータスファイルが配置されているディスクで障害が発生すると，他方のステータスファイルでトランザクション回復処理が実行されます※。ただし，この機能を利用すると，二重にディスクアクセスするため，オンライン処理の応答時間は遅くなります。

注※

オンライン処理は継続できません。

リソースマネジャでのヒューリスティック決着時のエラー通知
データベースなどのリソースマネジャでのヒューリスティック決着を検知したとき，メッセージによってエラーを通知します。

9.3.5　システム例外発生時のトランザクションの動作

EJB呼び出し時に，呼び出し先でシステム例外が発生したときの呼び出し元のトランザクションの挙動は，J2EEサーバの起動モードやシステム定義によって次のように変わります。

＜この項の構成＞

(1)　呼び出し元のトランザクションを呼び出し先が引き継ぐ場合（呼び出し先のトランザクション属性がCMTのRequired，Supports，Mandatoryの場合）

(2)　呼び出し元のトランザクションを呼び出し先が引き継がない場合（呼び出し先のトランザクション属性がBMT，またはCMTのNotSupported，RequiresNew，Supportsの場合）

(1)　呼び出し元のトランザクションを呼び出し先が引き継ぐ場合（呼び出し先のトランザクション属性がCMTのRequired，Supports，Mandatoryの場合）

呼び出し先でシステム例外が戻ってきた場合，トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

(2)　呼び出し元のトランザクションを呼び出し先が引き継がない場合（呼び出し先のトランザクション属性がBMT，またはCMTのNotSupported，RequiresNew，Supportsの場合）

呼び出し元，呼び出し先のトランザクションは，それぞれ次のように動作します。

呼び出し元のトランザクション

EJBのリモートインタフェースでのリモート呼び出し時
ライトトランザクションが無効の場合：
トランザクションはOTSによってロールバックにマークされます。
ライトトランザクションが有効の場合：
トランザクションはロールバックにマークされません。

EJBのリモートインタフェースでのローカル呼び出しの最適化時
usrconf.propertiesのejbserver.distributedtx.rollbackClientTxOnSystemExceptionキーの値によって動作が異なります。
trueの場合：
トランザクションはロールバックにマークされます。
falseの場合：
トランザクションはロールバックにマークされません。

EJBのローカルインタフェース呼び出し時
トランザクションはロールバックにマークされます。

呼び出し先のトランザクション

トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

なお，ローカル呼び出しの最適化については，「5.11.1　EJBのリモートインタフェースでのローカル呼び出しの最適化」を参照してください。

9.3.6　トランザクションマネジャの取得

トランザクションマネジャ（javax.transaction.TransactionManagerまたはjavax.transaction.Transaction）は，トランザクションを管理するためのAPIを提供します。トランザクションマネジャのAPIを使用するフレームワークを使用する場合は，JNDIを使用してトランザクションマネジャを取得できます。トランザクションマネジャを取得するには，「java:comp/TransactionManager」の名前でルックアップします。

CosminexusがサポートするトランザクションマネジャのAPI，およびSynchronizationを使用する場合の注意について説明します。

＜この項の構成＞

(1)　サポートするAPI

(2)　トランザクションマネジャを使用する場合の注意事項

(3)　Synchronizationを使用する場合の注意事項

(1)　サポートするAPI

CosminexusがサポートするトランザクションマネジャのAPIを次の表に示します。

表9-10　CosminexusがサポートするトランザクションマネジャのAPI

インタフェース | メソッド | 使用可否
javax.transaction.TransactionManger | begin | ○
commit | ○
getStatus | ○
getTransaction | ○
resume | ○
rollback | ○
setRollbackOnly | ○
setTransactionTimeout | ○
suspend | ○
javax.transaction.Transaction | commit | ○
delistResource | －
enlistResource | －
getStatus | ○
registerSychronization | ○
rollback | ○
setRollbackOnly | ○

（凡例）　○：使用できる　－：使用できない

注　使用できないメソッドを使用しようとすると，javax.transaction.SystemExceptionがスローされます。

(2)　トランザクションマネジャを使用する場合の注意事項

ルックアップで取得したトランザクションマネジャを使用する場合，トランザクション管理に含める処理（データベースのコネクションの取得，使用，解放など）は，トランザクションの開始後から決着前，または開始後から中断前および再開後から決着前の範囲内で実装してください。トランザクションの開始前や決着後，中断中に実装された処理はトランザクション管理に含まれません。

(3)　Synchronizationを使用する場合の注意事項

トランザクション（javax.transaction.Transaction）のregisterSynchronizationメソッドで登録するSynchronization（javax.transaction.Synchronization）のbeforeCompletionメソッド，およびafterCompletionメソッドでは，J2EEサーバが提供するサービスを使用できません。使用できないサービスの例を次に示します。

リソースアクセス

UserTransactionまたはCMTによるトランザクション操作

EJBアクセス

JNDIアクセス

これらのサービスのうちリソースアクセスを行った場合，リソースアクセスがトランザクションマネジャが管理するトランザクションの一部として管理されないで，不整合が発生することがあります。リソースアクセスをする場合は，フレームワークの責任で，フレームワークがリソースに対して直接トランザクションを制御するようにしてください。

上記のような注意事項があるため，ユーザプログラムでSynchronizationを利用することは推奨しません。ユーザプログラムからトランザクション決着のタイミングを利用したい場合には，EJBのjavax.ejb.SessionSynchronizationを使用してください。

9.4　データベースへの接続

この節では，DB Connectorを使用したデータベースへの接続について説明します。

DB Connectorを使用して接続できるデータベースには，HiRDB，Oracle，SQL Server，XDM/RD E2があります。データベースと接続する場合，接続先のデータベースの種類によって，データベースの接続方法，使用できるJDBCドライバなどが異なります。ここでは，データベース接続の前提条件と，使用できる機能について説明します。

＜この節の構成＞

9.4.1　DB Connectorによる接続の概要

9.4.2　使用できるJ2EEコンポーネントおよび機能

9.4.3　接続できるデータベース

9.4.4　DB Connector（RARファイル）の種類

9.4.5　HiRDBと接続する場合の前提条件と注意事項

9.4.6　Oracleと接続する場合の前提条件と注意事項

9.4.7　SQL Serverと接続する場合の前提条件と注意事項

9.4.8　XDM/RD E2と接続する場合の前提条件と注意事項

9.4.1　DB Connectorによる接続の概要

データベースと接続する場合，リソースアダプタとしてDB Connectorを使用できます。DB Connectorは，JDBCを利用したデータベースアクセスをするためのリソースアダプタです。DB Connectorは，J2EEアプリケーションからコネクションファクトリ（javax.sql.DataSourceクラス）をルックアップして使用します。

DB Connectorによる接続の概要を次の図に示します。

図9-2　DB Connectorによる接続の概要

DB Connectorでのデータベース接続では，JDBCドライバに，HiRDB Type4 JDBC Driver，Cosminexus DABroker Library，Oracle JDBC Thin Driver，またはSQL ServerのJDBCドライバを使用します。

DB Connectorの設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定の説明，および「Cosminexus　アプリケーション設定操作ガイド」のデータベースと接続するための設定の説明を参照してください。

また，データベース上のキューと接続する場合の接続方法については，「9.5　データベース上のキューとの接続」を参照してください。

注意

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

9.4.2　使用できるJ2EEコンポーネントおよび機能

ここでは，データベース接続で使用できる機能について説明します。

データベース接続で使用できるJ2EEコンポーネントおよび機能を，データベースごとに次の表に示します。

表9-11　使用できるJ2EEコンポーネントおよび機能

項目 | HiRDB | Oracle | SQL Server | XDM/RD E2
Oracle9i | Oracle10g
J2EEコンポーネント | Servlet/JSP | ○ | ○ | ○ | ○ | ○
Stateless Session Bean | ○ | ○ | ○ | ○ | ○
Stateful Session Bean | ○ | ○ | ○ | ○ | ○
Entity Bean（BMP） | ○ | ○ | ○ | ○ | ×
Entity Bean（CMP1.1） | ○ | ○※1 | × | × | ×
Entity Bean（CMP2.0） | ○※2 | ○※1 | × | × | ×
Message-driven Bean（onMessageメソッドからのデータベースアクセス） | ○ | ○ | ○ | ○ | ○
使用できる機能 | コネクションプーリング | ○ | ○ | ○ | ○ | ○
コネクションプールのウォーミングアップ | ○ | ○ | ○ | ○ | ○
コネクションプールの情報表示（cjlistpoolコマンド） | ○ | ○ | ○ | ○ | ○
コネクションプールのクリア（cjclearpoolコマンド） | ○ | ○ | ○ | ○ | ○
リソースへの接続テスト | ○ | ○ | ○ | ○ | ○
コネクションの障害検知 | ○※3 | ○ | ○ | △※4 | ○
ステートメントプーリング | ○※5 | ○ | ○ | ○ | ○※5※6
ステートメントキャンセル | ○※7 | △※8※9 | △※8※9 | ○ | ○※10
ステートメントsetQueryTimeoutメソッド | ○※11 | △※12 | △※12 | ○※13 | ×※14
コネクションIDのPRFトレース出力 | ○ | ○ | ○ | × | ○※10
障害調査用SQLの出力 | ○ | ○ | ○ | ○ | ○
コネクションプールのクラスタ化 | × | × | ○※15 | × | ×

（凡例）　○：使用できる　　×：使用できない　　△：一部制限あり

注※1

Oracle9iでCMP1.1およびCMP2.0が使用できるのは，Cosminexus DABroker Libraryを使用して接続する場合だけです。Oracle JDBC Thin Driverを使用して接続する場合は，CMP1.1およびCMP2.0は使用できません。

注※2

CMP2.0の機能である，CMR機能は利用できません。

注※3

Cosminexus DABroker Libraryを使用して接続する場合，HiRDBのバージョンが07-01以前でグローバルトランザクション（XATransaction）のときは使用できません。

注※4

DB ConnectorのselectMethodプロパティをdirectに設定した場合は使用できません。

注※5

HiRDB自動再接続機能とステートメントプーリング機能の併用はできません。

注※6

Cosminexus DABroker Libraryを使用する場合，XDM/RD E2 11-02以降のバージョンとCosminexus DABroker Library 03-13以降を使用する場合にだけステートメントプーリングを使用できます。

注※7

Cosminexus DABroker Libraryを使用して接続する場合，グローバルトランザクション（XATransaction）のときは使用できません。

注※8

Cosminexus DABroker Libraryを使用して接続する場合，データベースのサーバまたはクライアントがWindowsで，接続形式が専用接続であるときは，使用できません。

注※9

Oracle9i，Oracle10gでOracle JDBC Thin Driverを使用して接続する場合は，接続形式がMTS接続のときに使用できます。専用接続では使用できません。

注※10

ステートメントキャンセル，およびコネクションIDのPRFトレース出力は，DABroker経由の場合，XDM/RD E2 11-02以降で使用できます。

注※11

HiRDB Type4 JDBC Driverを使用して接続する場合に使用できます。Cosminexus DABroker Libraryを使用して接続する場合は使用できません。

注※12

Cosminexus DABroker Libraryを使用して接続する場合は使用できません。Oracle JDBC Thin Driverを使用する場合，MTS接続は有効に働きますが，専用接続には制限があります。詳細はオラクルのサポートサービスにお問い合わせください。

注※13

ステートメントsetQueryTimeoutメソッドは，SQL Server 2005の場合だけ使用できます。SQL Server 2000の場合は使用できません。

注※14

ステートメントsetQueryTimeoutメソッドは，DABroker経由の場合は使用できません。

注※15

RAC機能を使用している場合で，Oracle JDBC Thin Driverを使用して接続するときに使用できます。

9.4.3　接続できるデータベース

ここでは，DB Connectorを使用して接続できるデータベースについて説明します。

＜この項の構成＞

(1)　接続できるデータベースの種類

(2)　データベースとJDBCドライバの対応

(3)　DB ConnectorがサポートするJDBC仕様

(1)　接続できるデータベースの種類

DB Connectorを利用して接続できるデータベースには，HiRDB，Oracle，SQL Server，XDM/RD E2があります。なお，SQL ServerおよびXDM/RD E2ではグローバルトランザクションは使用できません。

(2)　データベースとJDBCドライバの対応

DB Connectorを使用してデータベースに接続するためには，データベースに対応するJDBCドライバが必要です。接続先のデータベースと使用できるJDBCドライバの対応について次の表に示します。

表9-12　接続先のデータベースと使用できるJDBCドライバ（データベース接続の場合）

データベース | JDBCドライバ
HiRDB Type4 JDBC Driver | Cosminexus DABroker Library | Oracle JDBC Thin Driver | SQL ServerのJDBCドライバ
HiRDB Version 7 | × | ○ | × | ×
HiRDB Version 8 | ◎ | ○ | × | ×
Oracle | × | ○ | ◎ | ×
SQL Server | × | × | × | ○
XDM/RD E2 | ○ | ○ | × | ×

（凡例）

◎：使用できる。かつ使用を推奨する。

○：使用できる。

×：使用できない。

参考

Cosminexus DABroker Libraryの文字コード設定

Cosminexus DABroker Libraryを使用してデータベースに接続する場合，文字コードを設定できます。文字コードは，リソースアダプタであるDB Connectorのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　DB ConnectorがサポートするJDBC仕様

接続に使用するJDBCドライバとDB ConnectorがサポートするJDBC仕様を次の表に示します。ただし，接続に使用するJDBCドライバが，JDBC仕様で規定された機能をサポートしていない場合は，DB Connectorでその機能を使用できません。

表9-13　接続に使用するJDBCドライバとDB ConnectorがサポートするJDBC仕様

接続に使用するJDBCドライバ | DB ConnectorがサポートするJDBC仕様
HiRDB Type4 JDBC Driver | JDBC 2.0
Cosminexus DABroker Library | JDBC 2.0
Oracle JDBC Thin Driver | JDBC 3.0
SQL ServerのJDBCドライバ | JDBC 2.0

ポイント

Oracle JDBC Thin Driverは，JDBC3.0の仕様で規定された範囲の機能をサポートしています。Oracleパッケージのクラスおよびインタフェースを使用したOracle拡張機能は使用できません。

また，CosminexusでOracle JDBC Thin Driverを使用してデータベースと接続する場合，Oracle JDBC Thin Driverの拡張機能である，文キャッシュおよび接続キャッシュ機能を利用することはできません。Cosminexusで提供するステートメントプーリング，またはコネクションプーリングを使用してください。ステートメントプーリングまたはコネクションプーリングについては，「9.10　パフォーマンスチューニングのための機能」を参照してください。

9.4.4　DB Connector（RARファイル）の種類

DB Connectorを使用してデータベースに接続する場合，使用するJDBCドライバに対応したRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

JDBCドライバの種類と対応するRARファイルについて次の表に示します。

表9-14　JDBCドライバとRARファイルの対応

JDBCドライバ | RARファイル | 説明
HiRDB Type4 JDBC Driver | DBConnector_HiRDB_Type4_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_HiRDB_Type4_XA.rar※ | グローバルトランザクションを使用する場合に使用します。
Cosminexus DABroker Library | DBConnector_DABJ_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_DABJ_XA.rar※ | グローバルトランザクションを使用する場合に使用します。
Oracle JDBC Thin Driver | DBConnector_Oracle_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_Oracle_XA.rar※ | グローバルトランザクションを使用する場合に使用します。
DBConnector_CP_ClusterPool_Root.rar | コネクションプールのクラスタ化機能でルートリソースアダプタを使用する場合に使用します。
DBConnector_Oracle_CP_ClusterPool_Member.rar | コネクションプールのクラスタ化機能でメンバリソースアダプタを使用する場合に使用します。
SQL ServerのJDBCドライバ | DBConnector_SQLServer_CP.rar | SQL Server 2000への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_SQLServer2005_CP.rar | SQL Server 2005への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

注※

ライトトランザクション機能は有効にできません。

9.4.5　HiRDBと接続する場合の前提条件と注意事項

ここでは，HiRDBと接続する場合の前提条件と注意事項について説明します。HiRDBのバージョンによって，使用できるJDBCドライバが異なります。

＜この項の構成＞

(1)　HiRDB Version 7の場合の前提条件

(2)　HiRDB Version 8の場合の前提条件

(3)　HiRDBと接続するときの注意事項

(1)　HiRDB Version 7の場合の前提条件

HiRDB Version 7の場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
DBConnector_DABJ_CP.rarまたはDBConnector_DABJ_XA.rarを使用します。
RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-15　RARファイルごとに使用できるトランザクションサポートレベル（HiRDB Version 7）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_DABJ_CP.rar
NoTransaction
LocalTransaction
○
○

DBConnector_DABJ_XA.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

(2)　HiRDB Version 8の場合の前提条件

HiRDB Version 8の場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはHiRDB Type4 JDBC DriverまたはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
次のどれかのRARファイルを使用します。

DBConnector_HiRDB_Type4_CP.rar

DBConnector_DABJ_CP.rar

DBConnector_HiRDB_Type4_XA.rar

DBConnector_DABJ_XA.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-16　RARファイルごとに使用できるトランザクションサポートレベル（HiRDB Version 8）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_HiRDB_Type4_CP.rar
DBConnector_DABJ_CP.rar
NoTransaction
LocalTransaction
○
○

DBConnector_HiRDB_Type4_XA.rar
DBConnector_DABJ_XA.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

(3)　HiRDBと接続するときの注意事項

HiRDBと接続する場合の注意を次に示します。

HiRDBの自動再接続機能を使用すると，データベースネットワーク障害などでHiRDBサーバとの接続が切断された場合に，コネクションが自動的に再接続されます。ただし，トランザクション中に接続が切断されると，SQLException例外が発生します。J2EEアプリケーションでSQLException例外を受け取ったときには，処理を続行しないでください。続けてDBMSにアクセスするとデータの不整合などの問題が発生するおそれがあります。

コネクションプール機能とステートメントプーリング機能を有効にして，Statement.cancel()を使用すると，SQLException例外が発生することがあります。この場合，コネクションプール機能，またはステートメントプーリング機能のどちらかを無効にすることをお勧めします。

HiRDBのバージョンが07-01以前で，トランザクションサポートレベルにXATrasactionを使用する場合，トランザクション外でコネクションを使用してデータベースにアクセスすると，コネクションが二つ使用されます。
HiRDBのバージョンが07-02以降で，J2EEアプリケーションが次の条件をすべて満たす場合は，コネクションが二つ使用され，HiRDBへの接続が同時に利用しているユーザ数の2倍になります。HiRDBのシステム共通定義のpd_max_usersオペランドに，同時に利用しているユーザ数の2倍の値を指定してください。pd_max_usersオペランドについては，マニュアル「HiRDB システム定義」を参照してください。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

Application Serverが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。
注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

HiRDBのバージョンが07-01以前で，ステートメントプーリング機能を有効にした場合，Application Serverが管理するトランザクションで使用するときだけ，ステートメントプーリング機能が使用できます。これ以外の場合はエラーが発生します。
HiRDBのバージョンが07-02以降で，J2EEアプリケーションが次の条件をすべて満たす場合は，エラーが発生します。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

Application Serverが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。
注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

HiRDBのバージョンが07-01以前で，コネクションの障害検知機能を有効にした場合，障害検知が誤動作するおそれがあるため，無効にしてください。
HiRDBのバージョンが07-02以降の場合は，コネクションの障害検知機能を使用できます。

次の条件をすべて満たす場合，同一コネクションを複数の異なるグローバルトランザクションに同時に参加させることはできません。トランザクションごとに使用するコネクションを分けてください。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

Application Serverが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。
注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

9.4.6　Oracleと接続する場合の前提条件と注意事項

ここでは，Oracleと接続する場合の前提条件と注意事項について説明します。

＜この項の構成＞

(1)　Oracle9iの場合の前提条件

(2)　Oracle10gの場合の前提条件

(3)　Oracleと接続する場合の注意事項

(1)　Oracle9iの場合の前提条件

Oracle9iの場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker LibraryまたはOracle JDBC Thin Driverとなります。
JDBCドライバとしてCosminexus DABroker Libraryを使用する場合，Oracleクライアントをインストールする必要があります。

接続方法
次のどれかのRARファイルを使用します。

DBConnector_DABJ_CP.rar

DBConnector_Oracle_CP.rar

DBConnector_DABJ_XA.rar

DBConnector_Oracle_XA.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-17　RARファイルごとに使用できるトランザクションサポートレベル（Oracle9i）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_DABJ_CP.rar
DBConnector_Oracle_CP.rar
NoTransaction
LocalTransaction
○
○

DBConnector_DABJ_XA.rar
DBConnector_Oracle_XA.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

(2)　Oracle10gの場合の前提条件

Oracle10gの場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker LibraryまたはOracle JDBC Thin Driverとなります。
JDBCドライバとしてCosminexus DABroker Libraryを使用する場合，Oracleクライアントをインストールする必要があります。

接続方法
次のどれかのRARファイルを使用します。

DBConnector_DABJ_CP.rar

DBConnector_Oracle_CP.rar

DBConnector_DABJ_XA.rar

DBConnector_Oracle_XA.rar

DBConnector_CP_ClusterPool_Root.rar

DBConnector_Oracle_CP_ClusterPool_Member.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-18　RARファイルごとに使用できるトランザクションサポートレベル（Oracle10g）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_DABJ_CP.rar
DBConnector_Oracle_CP.rar
NoTransaction
LocalTransaction
○
○

DBConnector_DABJ_XA.rar
DBConnector_Oracle_XA.rar
XATransaction
－
○

DBConnector_CP_ClusterPool_Root.rar
DBConnector_Oracle_CP_ClusterPool_Member.rar
NoTransaction
LocalTransaction
○
○

（凡例）　○：使用できる　　－：該当しない

(3)　Oracleと接続する場合の注意事項

Oracleと接続する場合，使用するJDBCドライバによって，機能差があります。

ここでは，Oracleに接続する場合の，Cosminexus DABroker LibraryとOracle JDBC Thin Driverの機能の差異と，使用時の注意について説明します。

(a)　使用できるJ2EEコンポーネントの違い

Oracle接続で使用できるJ2EEコンポーネントを，JDBCドライバごとに次の表に示します。

表9-19　J2EEコンポーネントと使用できるJDBCドライバ

J2EEコンポーネント | Cosminexus DABroker Library | Oracle JDBC Thin Driver
サーブレット/JSP | ○ | ○
Stateless Session Bean | ○ | ○
Stateful Session Bean | ○ | ○
Entity Bean（BMP） | ○ | ○
Entity Bean（CMP2.0） | ○ | ×
Message-driven Bean | ○ | ○

（凡例）　○：使用できる　　×：使用できない

(b)　型マッピングの相違点

Cosminexus DABroker LibraryおよびOracle JDBC Thin Driverでは，Javaの型とOracleのSQL型の間で，マッピングが一部異なります。Javaの型とOracleのSQL型のマッピングを，JDBCドライバごとに表に示します。

表9-20　Javaの型とOracleのSQL型のマッピング（Cosminexus DABroker Library）

メソッド | OracleのSQL型
CHAR | VARCHAR2 | NUMBER | DATE | TIMESTAMP | CLOB | LONG | BLOB | RAW | LONGRAW
set/getByte | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getShort | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getInt | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getLong | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getFloat | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getDouble | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getBigDecimal | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getBoolean | － | － | － | － | － | － | － | － | － | －
set/getString | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getBytes | － | － | － | － | － | － | － | － | ○ | ○
set/getDate | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getTime | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getTimestamp | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getClob | － | － | － | － | － | ○ | － | － | － | －
set/getBlob | － | － | － | － | － | － | － | ○ | － | －
set/getObject | ○ | ○ | ○ | ○ | － | ○ | ○ | ○ | ○ | ○

（凡例）

○：java.sql.PreparedStatement#setXXXおよびjava.sql.ResultSet#getXXXなどでマッピングできる

－：マッピングできない

表9-21　Javaの型とOracleのSQL型のマッピング（Oracle JDBC Thin Driver）

メソッド | OracleのSQL型
CHAR | VARCHAR2 | NUMBER | DATE | TIMESTAMP | CLOB | LONG | BLOB | RAW | LONGRAW
set/getByte | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getShort | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getInt | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getLong | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getFloat | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getDouble | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getBigDecimal | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getBoolean | ○ | ○ | ○ | － | － | － | ○ | － | － | －
set/getString | ○ | ○ | ○ | ○ | － | － | ○ | － | ○ | ○
set/getBytes | － | － | － | － | － | － | － | － | ○ | ○
set/getDate | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getTime | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getTimestamp | ○ | ○ | － | ○ | － | － | ○ | － | － | －
set/getClob | － | － | － | － | － | ○ | － | － | － | －
set/getBlob | － | － | － | － | － | － | － | ○ | － | －
set/getObject | ○ | ○ | ○ | ○ | － | ○ | ○ | ○ | ○ | ○

（凡例）

○：java.sql.PreparedStatement#setXXXおよびjava.sql.ResultSet#getXXXなどでマッピングできる

－：マッピングできない

注

この表は，Oracle9iのマッピングです。詳細やOracle10gについては，Oracleのマニュアルを参照してください。

(c)　日本語文字コード変換の相違点とOracle JDBC Thin Driverでの文字化けを回避するための設定

JDBCドライバでは，データをデータベースに格納するとき，およびデータベースからデータを取り出すときに，Unicodeとデータベース格納コードとの間で適宜，文字コードを変換します。文字コード変換をする場所は，JDBCドライバによって異なります。JDBCドライバごとに文字コード変換が実施される場所について説明します。

●Cosminexus DABroker Libraryを使用する場合

Cosminexus DABroker Libraryを使用する場合に文字コード変換が実施される場所を次の図に示します。

図9-3　Cosminexus DABroker Libraryを使用する場合に文字コード変換が実施される場所

J2EEサーバ上のJDBCドライバ部分では，JavaVMのコンバータによって，Unicodeからデータベース格納コード，およびデータベース格納コードからUnicodeへの変換が実施されます。

Cosminexus DABroker LibraryのエンコーディングセットとOracleサーバのデータベースキャラクタセットを同じにしておく必要があります。

●Oracle JDBC Thin Driverを使用する場合

Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所を次の図に示します。

図9-4　Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所

図中の場所ごとに実行される文字コード変換について，次の表に示します。

表9-22　Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所

場所 | 実施される内容
1 | ネットワーク，ファイルなどの外部データをJ2EEサーバで読み込む時に，外部データコードからUnicodeに変換されます。
2 | J2EEサーバで読み込んだデータをOracleサーバに格納する時に，UnicodeからUTF-8に変換されます。J2EEサーバ上のJDBCドライバ部分で実施されるコード変換です。
3 | Oracleサーバのコンバータによって，UTF-8からデータベース格納コードへの変換が実施されます。Oracleサーバ上で実施されるコード変換です。
4 | Oracleサーバのコンバータによって，データベース格納コードからUTF-8への変換が実施されます。
5 | OracleサーバからJ2EEサーバが格納したデータを取得する時に，UTF-8からUnicodeに変換されます。
6 | J2EEサーバで取得したデータをネットワークやファイルなどに書き出す時に，Unicodeから外部データコードに変換されます。

Oracle JDBC Thin Driverを使用する場合，JavaVMとOracleサーバのコンバータがサポートしているマッピング規則の相違から，文字化けが発生することがあります。文字化けは，外部データの文字コードとデータベース格納コードの組み合わせや，文字コード変換を行うコンバータの組み合わせによって発生します。

文字化けを回避するためには，外部データの文字コードと，データベース格納コードを，次に示す組み合わせで使用してください。

外部データの文字コードがシフトJIS（CP932）の場合
データベース格納コードに「AL32UTF8」または「JA16SJISTILDE」を指定してください。なお，データベース格納コードに「JA16SJIS」を指定した場合，「～」の文字で文字化けが発生しますのでご注意ください。

外部データの文字コードがSJISの場合
データベース格納コードに「AL32UTF8」を指定してください。なお，データベース格納コードに「JA16SJIS」を指定した場合，「￠」「￡」「￢」「∥」「－」で文字化けが発生しますのでご注意ください。

外部データの文字コードがEUCの場合
データベース格納コードに「AL32UTF8」を指定してください。なお，データベース格納コードに「JA16EUC」を指定した場合，「￠」「￡」「￢」で文字化けが発生しますのでご注意ください。

9.4.7　SQL Serverと接続する場合の前提条件と注意事項

ここでは，SQL Serverと接続する場合の前提条件と注意事項について説明します。

＜この項の構成＞

(1)　SQL Serverの場合の前提条件

(2)　SQL Serverと接続する場合の注意事項

(1)　SQL Serverの場合の前提条件

SQL Serverの場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはSQL ServerのJDBCドライバとなります。

接続方法
DBConnector_SQLServer_CP.rarまたはDBConnector_SQLServer2005_CP.rarを使用します。使用するRARファイルは，接続するSQL Serverによって異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-23　RARファイルごとに使用できるトランザクションサポートレベル（SQL Server）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_SQLServer_CP.rar
DBConnector_SQLServer2005_CP.rar
NoTransaction
LocalTransaction
○
○

（凡例）　○：使用できる

なお，SQL Serverと接続できるのはWindowsの場合だけです。

(2)　SQL Serverと接続する場合の注意事項

SQL Server接続時，データベースに日本語文字コードを含むデータを格納する場合，システムでの文字コード変換について考慮する必要があります。ここでは，システムでの文字コード変換の概要と，文字化けを回避するために設定時に注意することについて説明します。

Javaでは日本語文字コードはUnicodeで表現されます。SQL Serverを使用する場合，Webクライアントとアプリケーションサーバ間，およびアプリケーションサーバとSQL Server間の処理で文字コード変換が実施されます。

SQL Serverを使用する場合の文字コード変換の概要を次の図に示します。

図9-5　SQL Serverを使用する場合の文字コード変換の概要

図中の1.～4.について説明します。

アプリケーションサーバがWebクライアントからデータを受信する時に，外部文字コードからUnicodeに変換されます。

アプリケーションサーバがデータをSQL Serverに格納する時に，Unicodeからデータベース格納文字コードに変換されます。

SQL Serverに格納されたデータをアプリケーションサーバが取得する時に，データベース格納文字コードからUnicodeに変換されます。

アプリケーションサーバがデータをWebクライアントに送信する時に，Unicodeから外部文字コードに変換されます。

SQL Serverを使用する場合，外部文字コードとデータベース格納文字コードの組み合わせや，文字コード変換を実施する場合に使用されるコンバータの種類によっては，文字化けなどの問題が発生することがあります。このような文字化けを回避するためには，文字コードの設定に注意する必要があります。

SQL Serverでは次の表に示す文字データ型をサポートしています。SQL Serverを使用する場合，Unicodeデータ型を使用することによって，文字コード変換時に発生する文字化けを防ぐことができます。

表9-24　SQL Serverでサポートする文字データ型

カテゴリ | 文字データ型
Unicodeデータ型 | nchar，nvarchar，ntext
非Unicode文字データ型 | char，varchar，text

次に，SQL Serverでのデータベース格納文字コードとして，Unicodeデータ型を使用する場合と，非Unicodeデータ型を使用する場合の文字コード変換について説明します。

Unicodeデータ型を使用する場合

DB ConnectorのプロパティのsendStringParametersAsUnicodeキーにtrue（デフォルト値）を設定している場合，文字化けは発生しません。falseを設定した場合，外部文字コードにShift_JIS，EUC-JP，ISO-2022-JP，またはUTF-8を使用すると文字化けが発生することがあります。

非Unicode文字データ型を使用する場合

外部文字コードの設定によって，文字化けが発生することがあります。

外部文字コードにWindows-31Jを使用する場合
文字化けは発生しません。

外部文字コードにShift_JIS，EUC-JP，またはISO-2022-JPを使用する場合
次に示す文字などで文字化けが発生します。

外部文字コードにUTF-8を使用する場合
次に示す文字などで文字化けが発生します。

9.4.8　XDM/RD E2と接続する場合の前提条件と注意事項

ここでは，XDM/RD E2と接続する場合の前提条件と注意事項について説明します。

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker LibraryまたはHiRDB Type4 JDBC Driverとなります。
JDBCドライバとしてCosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
DBConnector_DABJ_CP.rarまたはDBConnector_HiRDB_Type4_CP.rarを使用します。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-25　RARファイルごとに使用できるトランザクションサポートレベル（XDM/RD E2）

使用するDB Connector
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_DABJ_CP.rar
NoTransaction
LocalTransaction
○
○

DBConnector_HiRDB_Type4_CP.rar
NoTransaction
LocalTransaction
○
○

（凡例）　○：使用できる

9.5　データベース上のキューとの接続

ここでは，データベース上のキューとの接続について説明します。

データベース上のキューと接続するためには，リソースアダプタとしてDB Connector for Cosminexus RMとCosminexus RMを使用します。

Cosminexus RMの詳細については，マニュアル「Cosminexus Reliable Messaging」を参照してください。また，接続できるデータベースについては，「9.4　データベースへの接続」を参照してください。

＜この節の構成＞

9.5.1　DB Connector for Cosminexus RMとCosminexus RMによる接続の概要

9.5.2　DB Connector for Cosminexus RMとCosminexus RMによる接続の特徴

9.5.3　使用できる機能

9.5.4　接続できるデータベース

9.5.5　DB Connector for Cosminexus RM（RARファイル）の種類

9.5.6　HiRDBのキューに接続する場合の前提条件

9.5.7　Oracleのキューに接続する場合の前提条件

9.5.1　DB Connector for Cosminexus RMとCosminexus RMによる接続の概要

DB Connector for Cosminexus RMは，Cosminexus RMと連携して，JMSインタフェースを使用してデータベースと接続するためのリソースアダプタです。

Cosminexus RMと連携することによって，サーブレット，JSP，Enterprise Bean（Session Bean，Entity Bean，Message-driven Bean）から，JMSインタフェースを使用してデータベース上のキューにアクセスできます。また，JDBCインタフェースを使用して，データベース上のテーブルにもアクセスできます。

JMSインタフェースとJDBCインタフェースを使用して同じデータベースにアクセスするとき，グローバルトランザクションを1フェーズコミットで処理できます。これによって，処理性能が向上します。また，JMSインタフェースとJDBCインタフェースによるデータベース接続に使用する物理コネクションを共通できるため，リソースを有効活用できるようになります。

DB Connector for Cosminexus RMとCosminexus RMによる接続の概要を次の図に示します。

図9-6　DB Connector for Cosminexus RMとCosminexus RMによる接続の概要

DB Connector for Cosminexus RMとCosminexus RMによるデータベース接続では，JDBCドライバに，HiRDB Type4 JDBC Driver，Cosminexus DABroker Library，またはOracle JDBC Thin Driverを使用します。

DB Connector for Cosminexus RMの設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定の説明，および「Cosminexus　アプリケーション設定操作ガイド」のデータベース上のキューと接続するための設定の説明を参照してください。

9.5.2　DB Connector for Cosminexus RMとCosminexus RMによる接続の特徴

ここでは，DB Connector for Cosminexus RMとCosminexus RMによる接続の特徴について説明します。

＜この項の構成＞

(1)　DB Connector for Cosminexus RMおよびCosminexus RMによる処理の概要

(2)　DB Connector for Cosminexus RMとCosminexus RMによるデータベース接続の構成

(1)　DB Connector for Cosminexus RMおよびCosminexus RMによる処理の概要

DB Connector for Cosminexus RMを使用してCosminexus RMと連携することによって，データベース上のキューに対するJMSインタフェースによるメッセージの送受信や，メッセージによって起動されるMessage-driven Beanの呼び出しなどができます。

DB Connector for Cosminexus RMとCosminexus RMによってデータベースに接続する場合，JMSインタフェースとJDBCインタフェースによるアクセスで使用する物理コネクションを共有することによって次のことが実現できるため，処理性能が向上します。

ローカルトランザクションの適用

グローバルトランザクションの1フェーズコミット

サーブレット，JSP，または，Enterprise Beanから，JMSインタフェースとJDBCインタフェースを使用して，データベースにアクセスするときのDB Connector for Cosminexus RMおよびCosminexus RMの処理の概要を次の図に示します。

図9-7　DB Connector for Cosminexus RMおよびCosminexus RMの処理の概要

JMSインタフェースによるアクセスはCosminexus RMを経由して，JDBCインタフェースによるアクセスはDB Connector for Cosminexus RMを経由して，データベースにアクセスします。なお，Cosminexus RMでは，キューをデータベース上に構築するため，内部的にJDBCインタフェースによるデータベースへのアクセスを使用します。そのため，JDBCドライバを経由してデータベースにアクセスします。

また，DB Connector for Cosminexus RMでは，Cosminexus RMを経由して，Cosminexus RMと物理コネクションを共有してデータベースにアクセスします。これらのリソースアダプタでは，Cosminexus RM用のコネクションプールを利用してコネクションを取得します。これによって，物理コネクションの共有を実現しています。

(2)　DB Connector for Cosminexus RMとCosminexus RMによるデータベース接続の構成

DB Connector for Cosminexus RMとCosminexus RMを使用して接続する場合のリソースの構成パターンについて説明します。ここでは，次に示す場合のリソースの構成について説明します。

JMSインタフェースだけを使用する場合

JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合

JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合

Message-driven Beanを使用する場合

なお，JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合と，Message-driven Beanを使用する場合は，コネクションの共有ができます。ただし，コネクションを共有するためには，次に示す前提条件を満たしている必要があります。

コネクション共有の前提条件

ユーザプログラムで，同一トランザクション内でJMSインタフェースによるデータベース上のキューへのアクセスと，JDBCインタフェースによるテーブルへのアクセスを実施する。

Cosminexus RMによってキューを構築するデータベースと，テーブルにアクセスするデータベースが同じである。

JMSインタフェースよるデータベース上のキューへのアクセスと，JDBCインタフェースによるデータベース上のテーブルへのアクセスで使用するセキュリティ情報（ユーザ名，パスワード）と，サインオンの方式が同じである。

DB Connector for Cosminexus RMとCosminexus RMへのリファレンスを設定しているJ2EEアプリケーションで，DDの<res-sharing-scope>タグの値に「Shareable」が設定されている。

注意

JDBCインタフェースだけを使用してデータベースにアクセスする場合，リソースアダプタとしてDB Connectorを使用してください。

コネクション共有の前提条件を満たさない場合，DB Connector for Cosminexus RMとCosminexus RMによってJMSインタフェースとJDBCインタフェースの両方を使用したデータベースへのアクセスはしないでください。この場合，「(c)　JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合」に示す構成にして，テーブルへのアクセスにはDB Connectorを使用してください。

(a)　JMSインタフェースだけを使用する場合

ユーザプログラムでデータベース上のキューに対してだけアクセスする場合，次の図に示す構成で使用します。

図9-8　JMSインタフェースだけを使用する場合の構成

(b)　JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合

ユーザプログラムでJMSインタフェースとJDBCインタフェースを使用してデータベースにアクセスする場合，コネクション共有の前提条件を満たしているときは，2種類のインタフェースで同一のデータベースにアクセスできます。このとき，次の図に示す構成で使用します。

この構成にすることによって，コネクションの共有によるトランザクション処理性能の向上とリソースの有効利用を実現できます。

図9-9　JMSインタフェースとJDBCインタフェースでアクセスするデータベースが同じ場合の構成

(c)　JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合

ユーザプログラムでJMSインタフェースとJDBCインタフェースを使用してデータベースにアクセスする場合，コネクション共有の前提条件を満たしていないときは，インタフェースごとに，異なるデータベースにアクセスする構成にする必要があります。このとき，次の図に示す構成で使用します。

図9-10　JMSインタフェースとJDBCインタフェースでアクセスするデータベースが異なる場合の構成

データベース上のキューへのアクセスには，DB Connector for Cosminexus RMとCosminexus RMを使用します。また，データベース上のテーブルへのアクセスには，DB Connectorを別途用意して使用する必要があります。

(d)　Message-driven Beanを使用する場合

Message-driven Beanを使用する場合，次の図に示す構成で使用します。コネクションの共有条件を満たす場合には，DB Connector for Cosminexus RMのJDBCインタフェースを使用して，Message-driven BeanとJDBCインタフェースでコネクションを共有することができます。

なお，Message-driven Beanを使用する場合，関連づけるリソースアダプタがCosminexus RM 01-01以降のときは，グローバルトランザクションおよびローカルトランザクションを使用できます。Cosminexus RM 01-00のリソースアダプタを使用する場合は，グローバルトランザクションを使用する必要があります。このとき，ローカルトランザクションを使用することはできませんが，コネクション共有の前提条件を満たしていれば，グローバルトランザクションは1フェーズで決着されます。

図9-11　Message-driven Beanを使用する場合の構成

9.5.3　使用できる機能

DB Connector for Cosminexus RMとCosminexus RMによる接続で使用できる機能の詳細については，マニュアル「Cosminexus Reliable Messaging」を参照してください。

なお，JDBCインタフェースを使用してデータベースに接続する場合，DB Connectorを使用して接続する場合と同じ機能を利用できます。利用できる機能の詳細については，「9.2.4　リソースアダプタの機能」を参照してください。

9.5.4　接続できるデータベース

ここでは，DB Connector for Cosminexus RMとCosminexus RMを使用して接続できるデータベースについて説明します。

＜この項の構成＞

(1)　接続できるデータベースの種類

(2)　データベースとJDBCドライバの対応

(3)　注意事項

(1)　接続できるデータベースの種類

DB Connector for Cosminexus RMとCosminexus RMを使用して接続できるデータベースには，HiRDB，およびOracleがあります。なお，SQL Server，およびXDM/RD E2には接続できません。

(2)　データベースとJDBCドライバの対応

DB Connector for Cosminexus RMとCosminexus RMを使用してデータベースに接続するためには，データベースに対応するJDBCドライバが必要です。

接続先のデータベースと使用できるJDBCドライバについて次の表に示します。

表9-26　接続先のデータベースと使用できるJDBCドライバ（データベース上のキューとの接続の場合）

データベース | JDBCドライバ
HiRDB Type4 JDBC Driver | Cosminexus DABroker Library | Oracle JDBC Thin Driver
HiRDB Version 7 | × | ○ | ×
HiRDB Version 8 | ○ | ○ | ×
Oracle | × | × | ○

（凡例）　○：使用できる　　×：使用できない

(3)　注意事項

DB Connector for Cosminexus RMとCosminexus RMを使用してデータベースに接続する場合の注意事項を次に示します。

DB Connector for Cosminexus RMが提供するJDBCコネクション（java.sql.Connection. Connection）では，JDBC固有のトランザクション制御はできません。JDBC固有のトランザクション制御を行った場合，setAutoCommit(boolean)メソッドの引数falseでの呼び出しのときと，releaseSavepoint(SavePoint)メソッド，rollback(Savepoint)メソッド，setSavepoint()メソッド，およびsetSavepoint(String)メソッドの呼び出しのときに例外が発生します。JDBC固有のトランザクション制御を行う場合は，DB Connectorを使用してください。

DB Connector for Cosminexus RMの場合，性能解析トレースの取得ポイントおよびイベントIDがDB Connectorの場合と一部異なります。
JDBCコネクション（java.sql.Connection. Connection）に関しては，1回のアクセスでDB Connector for Cosminexus RMのJDBCコネクションと，DB ConnectorでのJDBCコネクションの二つのトレース取得ポイントで性能解析トレースが出力されます。
また，JDBCコネクションの生成物（java.sql.Statementなど）は，DB Connectorと同様のトレース取得ポイントで性能解析トレースが出力されます。java.sql.DataSourceは，DB Connector for Cosminexus RM用のトレース取得ポイントでだけ性能解析トレースが出力されます。

DB Connector for Cosminexus RMでは，稼働情報監視をした場合，DB Connector for Cosminexus RMのリソースアダプタの次の項目について，正しい値が出力されません。DB Connector for Cosminexus RM はコネクションをCosminexus RM経由で取得するため，連携するリソースアダプタの監視稼働情報はCosminexus RM側に累積され出力されます。

トランザクションサポートレベル

プール現在値（総数）

使用中のコネクション数

未使用のコネクション数

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行回数

ManagedConnectionのgetConnection()メソッドの実行回数

ManagedConnectionのcleanup()メソッドの実行回数

ManagedConnectionのdestroy()メソッドの実行回数

ConnectionManagerのallocateConnection()メソッドの実行時間

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行時間

ConnectionManagerのallocateConnection()メソッドの失敗回数

ManagedConnectionでFATALエラーが発生した回数

DB Connector for Cosminexus RMは，連携するCosminexus RM側のコネクションプールを共有します。そのため，DB Connector for Cosminexus RMには，コネクションプールの各機能の設定をする必要はありません。

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

9.5.5　DB Connector for Cosminexus RM（RARファイル）の種類

DB Connector for Cosminexus RMを使用してデータベースに接続する場合，使用するJDBCドライバに応じたRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

JDBCドライバの種類と対応するRARファイルについて次の表に示します。

表9-27　JDBCドライバとRARファイルの対応

JDBCドライバ | RARファイル | 説明
HiRDB Type4 JDBC Driver | DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar※ | グローバルトランザクションを使用する場合に使用します。
Cosminexus DABroker Library | DBConnector_DABJ_CP_Cosminexus_RM.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_DABJ_XA_Cosminexus_RM.rar※ | グローバルトランザクションを使用する場合に使用します。
Oracle JDBC Thin Driver | DBConnector_Oracle_CP_Cosminexus_RM.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_Oracle_XA_Cosminexus_RM.rar※ | グローバルトランザクションを使用する場合に使用します。

注※

ライトトランザクション機能は有効にできません。

9.5.6　HiRDBのキューに接続する場合の前提条件

ここでは，HiRDBのキューに接続する場合の前提条件について説明します。

＜この項の構成＞

(1)　HiRDB Version 7の場合の前提条件

(2)　HiRDB Version 8の場合の前提条件

(1)　HiRDB Version 7の場合の前提条件

HiRDB Version 7の場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
DBConnector_DABJ_CP_Cosminexus_RM.rarまたはDBConnector_DABJ_XA_Cosminexus_RM.rarを使用します。
RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-28　RARファイルごとに使用できるトランザクションサポートレベル（HiRDB Version 7）

使用するDB Connector for Cosminexus RM
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_DABJ_CP_Cosminexus_RM.rar
NoTransaction
LocalTransaction
○
○

DBConnector_DABJ_XA_Cosminexus_RM.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

(2)　HiRDB Version 8の場合の前提条件

HiRDB Version 8の場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはHiRDB Type4 JDBC DriverまたはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
次のどれかのRARファイルを使用します。

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

DBConnector_DABJ_CP_Cosminexus_RM.rar

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

DBConnector_DABJ_XA_Cosminexus_RM.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-29　RARファイルごとに使用できるトランザクションサポートレベル（HiRDB Version 8）

使用するDB Connector for Cosminexus RM
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar
DBConnector_DABJ_CP_Cosminexus_RM.rar
NoTransaction
LocalTransaction
○
○

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar
DBConnector_DABJ_XA_Cosminexus_RM.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

9.5.7　Oracleのキューに接続する場合の前提条件

ここでは，Oracleのキューに接続する場合の前提条件について説明します。

＜この項の構成＞

(1)　Oracle9iの場合の前提条件

(2)　Oracle10gの場合の前提条件

(1)　Oracle9iの場合の前提条件

Oracle9iの場合の前提条件について示します。

使用できるJDBCドライバ
使用できるJDBCドライバはOracle JDBC Thin Driverとなります。

接続方法
DBConnector_Oracle_CP_Cosminexus_RM.rarまたはDBConnector_Oracle_XA_Cosminexus_RM.rarを使用します。
RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。
RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表9-30　RARファイルごとに使用できるトランザクションサポートレベル（Oracle9i）

使用するDB Connector for Cosminexus RM
（RARファイル）
トランザクションサポートレベル
ライトトランザクション

有効
無効

DBConnector_Oracle_CP_Cosminexus_RM.rar
NoTransaction
LocalTransaction
○
○

DBConnector_Oracle_XA_Cosminexus_RM.rar
XATransaction
－
○

（凡例）　○：使用できる　　－：該当しない

(2)　Oracle10gの場合の前提条件

Oracle10gで使用できるJDBCドライバおよび接続方法は，Oracle9iの場合と同じです。「(1)　Oracle9iの場合の前提条件」を参照してください。

9.6　OpenTP1との接続（SSPまたはTP1/Message Queue）

Cosminexusでは，OpenTP1 SPPまたはTP1/Message Queueと接続できます。OpenTP1との接続には，次のリソースアダプタを使用します。

OpenTP1 SPPとの接続の場合，uCosminexus TP1 Connectorを使用します。

TP1/Message Queueとの接続の場合，TP1/Message Queue - Accessを使用します。

ここでは，OpenTP1との接続について説明します。

＜この節の構成＞

9.6.1　uCosminexus TP1 Connectorによる接続

9.6.2　TP1/Message Queue - Accessによる接続

9.6.1　uCosminexus TP1 Connectorによる接続

J2EEサーバとOpenTP1 SPPの接続には，リソースアダプタとしてuCosminexus TP1 ConnectorとTP1/Client/Jを組み合わせて利用します。

OpenTP1との連携について次の図に示します。

図9-12　uCosminexus TP1 Connectorを利用したOpenTP1との連携

uCosminexus TP1 Connectorは，TP1/Client/JのRPCを使用してOpenTP1と接続し，OpenTP1のSPPにアクセスします。これによって，J2EEサーバでは，OpenTP1のSPPと連携することができます。

注意

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

uCosminexus TP1 Connectorの設定項目の詳細については，uCosminexus TP1 Connectorのドキュメントを参照してください。TP1/Client/Jの設定項目の詳細については，マニュアル「OpenTP1　クライアント使用の手引　TP1/Client/J編」を参照してください。

また，サーバ管理コマンドを使用したリソースアダプタの設定方法については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定の説明，およびマニュアル「Cosminexus　アプリケーション設定操作ガイド」のそのほかのリソースと接続するための設定の説明を参照してください。

9.6.2　TP1/Message Queue - Accessによる接続

CosminexusとTP1/Message Queueの接続には，リソースアダプタとしてTP1/Message Queue - Accessを利用します。

TP1/Message Queue - Accessを利用したTP1/Message Queueとの連携について次の図に示します。

図9-13　TP1/Message Queue - Accessを利用したTP1/Message Queueとの連携

TP1/Message Queue - Accessでは，JMSインタフェースを提供しています。このJMSインタフェースを利用して，J2EEサーバはTP1/Message Queueと接続します。

注意

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

TP1/Message Queue - Accessの設定項目の詳細については，マニュアル「OpenTP1 Version 6 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」を参照してください。

また，サーバ管理コマンドを使用したリソースアダプタの設定方法については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定の説明，およびマニュアル「Cosminexus　アプリケーション設定操作ガイド」のそのほかのリソースと接続するための設定の説明を参照してください。

9.7　SMTPサーバとの接続

J2EEアプリケーションは，JavaMailを使用して，SMTPサーバにメールを送信できます。なお，POP/IMAPによるメール受信はできません。

SMTPサーバとの接続の設定については，マニュアル「Cosminexus　システム構築ガイド」のリソースの設定の概要，および「Cosminexus　アプリケーション設定操作ガイド」のメールコンフィグレーションの設定の説明を参照してください。

9.8　JavaBeansリソースの利用

JavaBeansリソースでは，J2EEアプリケーションを稼働させるための設定値などを一括して保持，管理できます。J2EEアプリケーションからJNDIを使用してJavaBeansリソースをルックアップすることで，設定値を取得できます。

ここでは，JavaBeansリソースの開始処理の流れ，およびJavaBeansリソースの実装について説明します。

＜この節の構成＞

9.8.1　JavaBeansリソースの開始処理の流れ

9.8.2　JavaBeansリソースの実装

9.8.1　JavaBeansリソースの開始処理の流れ

J2EEサーバで，複数のJavaBeansリソースを開始状態にできます。サーバ管理コマンドを使用した場合の，JavaBeansリソースの開始処理の流れを次の図に示します。

図9-14　JavaBeansリソースの開始処理の流れ

JavaBeansリソースをインポートして，開始する。
サーバ管理コマンドを使用して，J2EEサーバにJavaBeansリソースをインポートして開始します。

ネーミングサービスにJavaBeansリソースのリファレンスを登録する。
JavaBeansリソースの開始時に，ネーミングサービスのJ2EEリソース用の名前空間にJavaBeansリソースのリファレンスを登録します。

J2EEアプリケーションからネーミングサービスにルックアップする。
JavaBeansリソースを利用するJ2EEアプリケーションから，ネーミングサービスにルックアップを行います。ルックアップ処理の延長でJavaBeansリソースのsetメソッドが呼ばれて，JavaBeansリソース属性ファイルに指定したプロパティ値が設定されます。

取得したリファレンスを使用して，JavaBeansリソースのgetメソッドの呼び出しを行います。
ルックアップして取得したリファレンスを使用して，JavaBeansリソースのgetメソッドの呼び出しを行い，setメソッドで設定した値をgetメソッドで取得します。

JavaBeansリソースの実装クラスは，単独のクラスで構成される場合はクラスファイルの形式で，JavaBeansリソースのクラスと関連クラスのように複数のクラスで構成される場合はJARファイルの形式で利用できます。

JavaBeansリソースの設定方法については，マニュアル「Cosminexus　システム構築ガイド」および「Cosminexus　アプリケーション設定操作ガイド」のJavaBeansリソースの設定の説明を参照してください。

9.8.2　JavaBeansリソースの実装

JavaBeansリソースの実装手順を，例を用いて説明します。

＜この項の構成＞

(1)　インポート時の設定

(2)　JavaBeansリソースの実装クラスの作成

(3)　アプリケーションの設定

(4)　アプリケーションの開始と終了

(1)　インポート時の設定

サーバ管理コマンド（cjimportjbコマンド）でJavaBeansリソースをインポートするときに必要な設定と注意事項を示します。

(a)　JavaBeansリソース属性ファイルの設定

JavaBeansリソース属性ファイルは，次に示す点に留意して作成してください。

<res-type>タグおよび<class-name>タグには，JavaBeansリソースのクラス名，実装クラス名を指定します。<res-type>タグおよび<class-name>タグで同じ値を設定する場合は<res-type>タグは省略できます。

<property-name>タグには，setメソッドおよびgetメソッドのメソッド名称を指定します。

<property-type>タグには，setメソッドの引数の型を指定します。
<property-type>タグの値と実際の該当setメソッドの引数型と合わない場合はlookup時にエラーになります。

<property-value>タグには，setメソッドの引数に渡す値を指定します。

JavaBeansリソース属性ファイルの設定例を示します。

<!DOCTYPE hitachi-javabeans-resource-property PUBLIC '-//Hitachi, Ltd.//DTD JavaBeans Resource Property 7.0//EN'
'http://localhost/hitachi-javabeans-resource-property_7_0.dtd'>

<hitachi-javabeans-resource-property>
 <description></description>
 <display-name>JavaBean_resource</display-name>
   <class-name>com.mycompany.mypackage.MyJavaBean</class-name>
   <runtime>
     <property>
       <property-name>UserName</property-name>
       <property-type>java.lang.String</property-type>
       <property-value>Hitachi</property-value>
     </property>
     <property>
       <property-name>UserID</property-name>
       <property-type>java.lang.String</property-type>
       <property-value>01234567</property-value>
     </property>
   </runtime>
</hitachi-javabeans-resource-property>

JavaBeansリソース属性ファイルのテンプレートファイル（jb_template.xml）は，次のディレクトリに格納されています。

<Cosminexusのインストールディレクトリ>¥CC¥admin¥templates

(b)　-dオプションの使い方

インポート時に-dオプションを使用することで，アーカイブを作成しないで，ディレクトリ構成のままインポートできます。-dで指定するディレクトリは，インポートするディレクトリの最上位を指定します。

インポートするときの-dオプションの指定例を次に示します。この指定例では，パッケージ名がcom.mycompany.mypackageのMyJavaBeanクラスをインポートします。

-dで指定するディレクトリ¥
 └ com¥
    └ mycompany
       └ mypackage
            └ MyJavaBean.class

-dオプションは指定されたディレクトリ下に存在するものをすべてインポートするので，不要なファイルはディレクトリ内に含めないでください。

複数のJavaBeansリソースをインポートする場合の注意

インポート済みのJavaBeansリソースと同じ実装クラス名のJavaBeansリソースはインポートできません。先にインポートしたJavaBeansリソースを削除してからインポートするか，実装クラス名を変更し，作成し直してからインポートしてください。

(2)　JavaBeansリソースの実装クラスの作成

JavaBeansで管理するデータ（プロパティ）を操作するメソッドを宣言します。データを登録する場合，setメソッド（set＋プロパティ名）を設定します。データを参照する場合，getメソッド（get＋プロパティ名）を設定します。

次に，JavaBeansリソースを登録，参照するクラスの実装例を示します。

package com.mycompany.mypackage;
public class MyJavaBean {
   private String username;
   private String userid;

   public void setUserName(String user_name) {
       this.username = user_name;
   }
   public void setUserID(String user_id) {
       this.userid = user_id;
   }
   public String getUserName() {
       return this.username;
   }
   public int getUserID() {
       return this.userid;
   }
}

(3)　アプリケーションの設定

JavaBeansリソースを利用するときに，アプリケーション側で必要な実装および定義について説明します。

(a)　lookupの実装（JavaBeansリソース）

JavaBeansリソースを，ルックアップまたはDIを使用して取得します。ここでは，"java:comp/env"形式でルックアップする方法を示します。

Context initCtx = new InitialContext();
MyJavaBean jb = (MyJavaBean) initCtx.lookup("java:comp/env/bean/myJB");

JavaBeansリソースをルックアップできる範囲は，ほかのリソース同様に，同じJ2EEサーバプロセス内のアプリケーションです。

(b)　DDの定義内容（JavaBeansリソース）

ルックアップを使用してJavaBeansリソースを取得する場合，ルックアップする名前や実装クラス名の情報をDD（ejb-jar.xmlまたはweb.xml）に定義します。設定するタグを次に示します。

<resource-env-ref-name>タグに，ルックアップで"java:comp/env"形式に指定する値を指定します。

<resource-env-ref-type>タグに，JavaBeansリソースの実装クラス名を指定します。

また，作成したアプリケーションをJ2EEサーバ上にデプロイするときに，ルックアップでの参照用の名称と実際の名称をlinked-toで結び付けます。この操作をするには，サーバ管理コマンド（cjsetapppropコマンド）を使用します。

cjgetapppropで該当アプリケーションの属性ファイルを取得します。

<resource-env-ref>タグに<linked-to>タグを追加して，利用するJavaBeansリソースの表示名を指定します。

cjsetapppropで該当アプリケーションの属性ファイルを設定します。

次に，cjsetapppropで渡す属性ファイルの<resource-env-ref>タグの例を示します。

<resource-env-ref>
 <resource-env-ref-name>bean/myJB</resource-env-ref-name>
 <resource-env-ref-type>com.mycompany.mypackage.MyJavaBean</resource-env-ref-type>
 <linked-to>JavaBean_resource</linked-to>
</resource-env-ref>

(4)　アプリケーションの開始と終了

JavaBeansリソースを利用するアプリケーションの開始，終了は，サーバ管理コマンドまたはManagement Serverで操作します。アプリケーションの開始，終了方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

Cosminexusでは，JavaBeansリソースのサンプルプログラムを提供します。サンプルプログラムの概要および実行方法については，マニュアル「Cosminexus　システム構築ガイド」のJavaBeansリソースのサンプルプログラムについての説明を参照してください。

9.9　そのほかのリソースとの接続

ここでは，9.4から9.8までで説明したリソース以外のリソースとの接続について説明します。

＜この節の構成＞

9.9.1　そのほかのリソースとの接続に使用するリソースアダプタ

9.9.2　そのほかのリソースとの接続で使用できる機能

9.9.1　そのほかのリソースとの接続に使用するリソースアダプタ

Application Serverでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用して，任意のリソースに接続できます。

Connector 1.5仕様では，J2EEサーバとリソースアダプタ間の通信モデルとして，次の2種類のモデルが決められています。Application Serverでは，これらの通信モデルに対応したリソースアダプタを使用できます。

Outbound
J2EEサーバからリソースアダプタにアクセスする通信モデルです。

Inbound
リソースアダプタからJ2EEサーバにアクセスする通信モデルです。

Application Serverでは，Connector 1.5仕様の次の規約に対応しています。

Lifecycle Management
リソースアダプタの開始処理または終了処理を管理するための規約です。

Work Management
リソースアダプタがスレッドを扱うための規約です。

メッセージインフロー
EISからのメッセージを受信して，リソースアダプタからMessage-driven Beanを使用するための規約です。

これらの規約に基づいたApplication Serverの機能については，「9.13.1　リソースアダプタのライフサイクル管理」，「9.13.2　リソースアダプタのワーク管理」および「9.13.3　メッセージインフロー」を参照してください。

また，既存の次の規約に対してConnector1.5仕様で追加された機能についても，Application Serverで対応しています。

Connection Management
不正コネクションを検知できます。
不正コネクションを検知する機能については，「9.11.1　コネクションの障害検知」を参照してください。

Common Client Interface
メッセージインフローに関連したAPIを使用できます。このAPIに対してApplication Serverで独自に規定した仕様については，「9.13.6　Application Server独自のConnector 1.5 API仕様」を参照してください。

9.9.2　そのほかのリソースとの接続で使用できる機能

Connector 1.5で規定された機能のうち，Application Serverで使用できる機能について説明します。使用できる機能は，Outboundの場合とInboundの場合で異なります。なお，Connector 1.5仕様に準拠したリソースアダプタで使用できるApplication Serverの機能については，「9.2.4　リソースアダプタの機能」を参照してください。

＜この項の構成＞

(1)　Outboundで使用できる機能

(2)　Inboundで使用できる機能

(3)　リソースアダプタの利用方法とトランザクションレベルの対応

(1)　Outboundで使用できる機能

Outboundでは，次の機能が使用できます。

ローカルトランザクションおよびグローバルトランザクションによるトランザクション管理

メッセージキューの使用

(2)　Inboundで使用できる機能

Inboundでは，Non-Transacted Delivery（Message-driven Beanの呼び出しがトランザクションに参加しないメッセージ配信）を使用できます。

次のメッセージ配信には対応していません。

対応していないメッセージ配信

Transacted Delivery（Message-driven Beanの呼び出しがグローバルトランザクションに参加するメッセージ配信）

Transaction Inflow（Message-driven Beanの呼び出しがEISのトランザクションに参加するメッセージ配信）

(3)　リソースアダプタの利用方法とトランザクションレベルの対応

リソースアダプタをOutboundまたはInboundで使用する場合に指定できるトランザクションレベルを次の表に示します。

表9-31　OutboundまたはInboundで使用する場合に指定できるトランザクションレベル

利用する通信モデル
トランザクションの管理方法
トランザクション属性
トランザクションサポートレベル

NoTransaction
LocalTransaction
XATransaction※1

Outbound
CMT
Required
RequiresNew
Supports
NotSupported
Mandatory
Never
○
○
○

BMT
－
○
○
○

Inbound
CMT
Required
－
－
×※2

NotSupported
○※３
○※３
○※３

BMT※3
－
○
○
○

（凡例）

○：使用できる　×：使用できない

－：該当しない，または仕様上設定できない

注※1

リソースアダプタをJ2EEアプリケーションに含める場合は，XATransactionは使用できません。

注※2

Message-driven Beanの開始に失敗します。KDJE43052-Eメッセージが出力されます。

注※3

Message-driven Beanへのメッセージ配信がトランザクションに参加しないため，リソースアダプタのトランザクション属性は無視されます。

9.10　パフォーマンスチューニングのための機能

この節では，パフォーマンスチューニングのための機能として，次の機能を紹介しています。

コネクションプーリング

コネクションシェアリング・アソシエーション

ステートメントプーリング

ライトトランザクション

インプロセストランザクションサービス

DataSourceオブジェクトのキャッシング

DB Connectorのコンテナ管理でのサインオンの最適化

受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）

これらの機能について，以降の項で説明します。

＜この節の構成＞

9.10.1　コネクションプーリング

9.10.2　コネクションシェアリング・アソシエーション

9.10.3　ステートメントプーリング

9.10.4　ライトトランザクション

9.10.5　インプロセストランザクションサービス

9.10.6　DataSourceオブジェクトのキャッシング

9.10.7　DB Connectorのコンテナ管理でのサインオンの最適化

9.10.8　受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）

9.10.1　コネクションプーリング

サーブレット，JSP，EJBなどのJ2EEコンポーネントからのリソースアクセス量に応じて，リソースコネクション（JDBCコネクション，およびリソースアダプタのコネクション）をプーリングする機能です。コネクションをプーリングすることによって，ユーザアプリケーションからのリソース接続要求を高速に処理します。

＜この項の構成＞

(1)　前提条件

(2)　コネクションプールのウォーミングアップ

(3)　コネクションプールの生成および初期化

(4)　コネクションプールの終了処理

(5)　例外が発生したコネクションの破棄

(6)　コネクションプール利用上の注意事項

(7)　コネクション数調節機能

(1)　前提条件

コネクションプーリング機能は，リソースの種類，接続方法の組み合わせによって，使用できる場合とできない場合があります。コネクションプーリング機能の使用について次の表に示します。

表9-32　コネクションプーリング機能の利用可否

リソースの種類 | 接続方法 | 利用可否
データベース | DB Connector | ○
データベース上のキュー | DB Connector for Cosminexus RMとCosminexus RM | ○
OpenTP1 | uCosminexus TP1 Connector | ○
TP1/Message Queue - Access | ○
SMTPサーバ | メールコンフィグレーション | ×
JavaBeansリソース | － | ×
そのほかのリソース | Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ | ○

（凡例）　○：使用できる　×：使用できない　－：該当しない

(2)　コネクションプールのウォーミングアップ

コネクションプールのウォーミングアップとは，サーバ起動時またはリソースアダプタのスタート時に実行されるリソースのスタート処理で，あらかじめ，コネクションを，コネクションプールの設定で定義した最小値までプーリングする機能です。これによって，コネクションプールの使用を開始した直後の，コネクション要求のレスポンスを向上できます。

コネクションプールのウォーミングアップは，リソースアダプタの属性（プロパティ）として設定します。リソースアダプタのプロパティ定義で設定できることについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　コネクションプールの生成および初期化

コネクションプールが生成・初期化されるタイミングは，リソースのスタート処理時です。コネクションプールのウォーミングアップ機能を有効にした場合，この時点でコネクションを生成します。コネクションプールのウォーミングアップ機能を無効にした場合，リソースのスタート時にコネクションは生成されず，最初のコネクション取得要求の発生時にコネクションを生成します。

コネクションプールの生成単位は次のとおりです。

Connector 1.0仕様に対応したリソースアダプタを使用する場合，リソース単位に一つのコネクションプールが生成されます。

Connector 1.5仕様に対応したリソースアダプタを使用する場合，コネクション定義ごとに一つのコネクションプールが生成されます。

(4)　コネクションプールの終了処理

リソースのアンデプロイ時やJ2EEサーバの終了時は，コネクションプール内のすべてのコネクションを削除し，コネクションプール自体も削除します。なお，コネクションプールの終了処理では，コネクションに関するトランザクションなどがすべて決着済みのものとして処理します。

(5)　例外が発生したコネクションの破棄

データベース障害などが発生すると，コネクションプールに格納しているコネクションは使えなくなるため，コネクションプールから速やかに破棄する必要があります。

Application Serverは，コネクション，またはStatementのようなコネクションからの生成物に対する処理で例外が発生すると，コネクションクローズ時に該当コネクションをコネクションプールから破棄します。ただし，ローカルトランザクションの決着処理が正常終了した場合には，コネクションが正常であると判断するため破棄しません。

コネクションが正常に維持している状態で，コネクションやコネクションからの生成物で例外が発生すると，グローバルトランザクションを使用している場合には，トランザクションの決着処理が正常終了してもApplication Serverはコネクションをコネクションプールに戻さないで破棄します。そのため余分なコネクション生成が発生して性能に影響を与えることがあります。

(6)　コネクションプール利用上の注意事項

コネクションプールを利用する場合の注意事項について説明します。

データベースサーバ側から強制的に切断する機能（タイムアウトなど）を利用しないでください。

コネクションプールで管理するコネクションは，取得時に使用した認証情報（ユーザ名，パスワードなど）を保持するため，サインオンの形態によっては注意が必要です。

コンテナ管理でのサインオンの場合

一つのコネクションプールに対して，コネクション取得要求時に使用する認証情報は常に一つとなるため，特に注意は必要ありません。

コンポーネント管理でのサインオンの場合

複数のユーザ名とパスワードの組み合わせを利用する場合に注意が必要です。コネクションプールはリソースごとに一つであるため，一つのリソースに対して複数のユーザが利用する場合，複数のユーザで一つのコネクションプールを共有することになります。この場合，一人のユーザが，コネクションプールの最大値に設定した数までコネクションを利用できないことがあります。

また，コネクションプール内の未使用コネクションの中に，認証情報が一致するコネクションがない場合，プール内のコネクション総数によって，次のように動作します。

コネクション総数が，指定したコネクションプールの最大値に達している場合，未使用状態のコネクションを破棄して，新規にコネクションを生成します。

コネクション総数が，指定したコネクションプールの最大値に達していない場合，新規にコネクションを生成します。

(7)　コネクション数調節機能

コネクション数調節機能とは，コネクションプール内の不要なコネクションを指定したコネクションプールの最小値から最大値の範囲で段階的に減少させる機能です。この機能を有効にすると，実際の稼働実績に適した数までプール内のコネクション数を徐々に減らせるため，指定したコネクションプールの最小値を超えた場合のコネクション生成コストの削減やリソース資源の節約ができます。

また，コネクション数の調節時のコネクション削除処理に対して，応答時間にタイムアウトを設定できます。サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション削除処理に対しても応答が返らなくなることがあります。このように，リソースから応答が返らない場合でも，タイムアウトを設定することでコネクション削除処理を終了し，処理を継続できます。

コネクション数調節機能の動作

コネクション数調節機能を使用すると，プール内のコネクション数は，前回コネクション数を調節したときから今回コネクション数を調節するまでの間に同時に使用されたコネクションの最大数で調節されます。コネクション数の調節時に，プール内コネクション数が同時に使用されたコネクションの最大数より多い場合は，コネクションの削除処理が動作します。例えば，現在，プール内にあるコネクション数が8の場合で，前回のコネクション数調整から今回のコネクション数調節までの間に同時に使用されたコネクションの最大数が5のときは，プール内のコネクション数が3多いため，コネクションプールから3コネクションが削除され，調節後のコネクション数は5となります。

なお，コネクション数調節機能は一定間隔で動作します。

コネクション数調節機能の設定については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタのプロパティ定義に関する説明を参照してください。

コネクション削除処理のタイムアウト

コネクション数調節機能のコネクション削除処理に対して，その応答時間にタイムアウトを設定できます。なお，コネクション削除処理のタイムアウト時間は5秒（固定）です。

ただし，コネクションプールの最大数が無制限の場合，コネクション削除処理のタイムアウトは無効になります。

また，コネクション削除処理のタイムアウトにはコネクション管理スレッドを使用するため，コネクション削除処理のタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費します。設定する場合は，必要なメモリ使用量を適切に見積もってください。

コネクション管理スレッドについては，「9.11.1　コネクションの障害検知」を参照してください。

9.10.2　コネクションシェアリング・アソシエーション

コネクションシェアリングとコネクションアソシエーションは，コネクション共有機能です。コネクション共有機能を利用することで，リソースを効率的に使用し，パフォーマンスを向上できます。必要に応じて，コネクションアソシエーション機能を有効にしてください。

ローカルトランザクションでトランザクション管理を行っている場合，一つのリソースコネクションだけでデータベースなどのリソースにアクセスする必要があります。コネクション共有機能を使用するとユーザアプリケーションで意識することなく，一つのリソースコネクションだけでリソースアクセスができます。

グローバルトランザクションの場合も同様に，一つのリソースコネクションしかトランザクションに参加しない場合は，1フェーズコミットに最適化されるため，トランザクションの決着コストを下げることができます。

＜この項の構成＞

(1)　物理コネクションと論理コネクション

(2)　コネクションシェアリング

(3)　コネクションアソシエーション

(1)　物理コネクションと論理コネクション

物理コネクションとは，接続先リソースのコネクションを指します。通常，サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作することはなく，コンテナが操作します。例えば，リソースアダプタの場合はManagedConnection（javax.resource.spi.ManagedConnection）です。

論理コネクションとは，サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作するコネクションを指します。例えば，リソースアダプタの場合はjavax.resource.cci.Connectionやリソースアダプタが独自に提供するコネクションです。

物理コネクションと論理コネクションの関係は，一般的に，物理コネクションから論理コネクションを生成するという関係になります。物理コネクションはコネクションプールで管理され，コネクションプールが物理コネクションの取得およびクローズを行います。

サーブレットやEnterprise BeanなどのJ2EEコンポーネントからのコネクション取得要求に対しては，コネクションプールが物理コネクションから論理コネクションを生成して返却します。コネクション解放要求に対しては，論理コネクションだけをクローズし，物理コネクションはクローズしないでプール管理します。

(2)　コネクションシェアリング

コネクションアソシエーション機能が有効でない場合，Application Serverが管理するトランザクション内でコネクションシェアリングが行われます。トランザクション内コネクションシェアリングは，リソースコネクションを最も効率的に使用します。トランザクション内のコネクションシェアリングについて次の図に示します。

図9-15　論理コネクションと物理コネクションの関係（トランザクション内コネクションシェアリング）

コネクションアソシエーション機能が有効な場合，およびApplication Serverが管理するトランザクションの外でのコネクションシェアリングは，サーブレットやEnterprise BeanなどのJ2EEコンポーネントインスタンス内でコネクションシェアリングが行われます。コンポーネント内のコネクションシェアリングについて，次の図に示します。

図9-16　論理コネクションと物理コネクションの関係（コンポーネント内コネクションシェアリング）

(a)　コネクションシェアリングの条件

コネクションシェアリングをするためには，次の条件をすべて満たす必要があります。

同一のJ2EEサーバ内であること

同一のリソースであること

サインオンの方法とセキュリティ情報（ユーザ名とパスワード）が同じであること

標準DDの<res-sharing-scope>にShareableが指定されていること

同一のApplication Serverが管理するトランザクション内であること※

注※

Application Serverが管理するトランザクションの外でもコネクションシェアリングを行うことができます。

Application Serverが管理するトランザクションの外でコネクションシェアリングを有効にする場合は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，リソースアダプタのトランザクションサポートレベルにNoTransactionを指定した場合は，コネクションシェアリングは行われません。

(b)　コネクションシェアリングの定義

コネクションを共有するかどうかは，サーブレットやEnterprise Beanの標準DDの<res-sharing-scope>タグで指定します。リソース参照ごとに指定できます。コネクションの共有はデフォルトで有効になっています。無効にする場合は，<res-sharing-scope>にUnshareableを指定します。

コネクションシェアリングの設定は，J2EEアプリケーションに含まれるSession Bean.，Entity Bean，Message-driven BeanまたはWARの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(c)　注意事項

java.sql.Connectionを，複数のトランザクション間で再利用することはできません。

java.sql.Connectionをトランザクション内で利用する場合には，トランザクションごとに，javax.sql.DataSourceからgetConnection()メソッドを使用してコネクションを取得してください。

なお，java.sql.Connectionは，トランザクション内とトランザクション外との間でも再利用することはできません。

(3)　コネクションアソシエーション

トランザクション範囲を超えた永続性を持つコネクションを使用する場合，トランザクション内コネクションシェアリングを使用できません。その場合は，コネクションアソシエーション機能を有効にしてください。

コネクションアソシエーションは，論理コネクションと物理コネクションの関係を切り替えて，一つのリソースコネクションによるリソースアクセスを実現します。

図9-17　論理コネクションと物理コネクションの関係（コネクションアソシエーション）

図9-18　論理コネクションと物理コネクションの関係（コネクションアソシエーションとコネクションシェアリングの併用時）

(a)　コネクションアソシエーションの条件

コネクションアソシエーションをするためには，次の条件のすべてを満たす必要があります。

コネクションアソシエーション機能が有効であること

同一のJ2EEサーバ内であること

同一のリソースであること

サインオンの方法とセキュリティ情報（ユーザ名とパスワード）が同じであること

標準DDの<res-sharing-scope>にShareableが指定されていること※

同一のApplication Serverが管理するトランザクション内であること

注※

usrconf.propertiesのejbserver.connectionpool.association.enabledDespiteUnshareableSettingキーに「true」を設定すると標準DDの<res-sharing-scope>にUnshareableが指定されていてもコネクションアソシエーションを行います。

このプロパティは下位互換性のためだけに提供されています。

(b)　コネクションアソシエーションの定義

コネクションアソシエーションはデフォルトで無効になっています。

コネクションアソシエーションを有効にするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

また，コネクションを共有するかどうかは，サーブレットやEnterprise Beanの標準DDの<res-sharing-scope>タグで指定します。リソース参照ごとに指定できます。コネクションの共有はデフォルトで有効になっています。無効にする場合は，<res-sharing-scope>にUnshareableを指定します。

コネクションシェアリングの設定は，J2EEアプリケーションに含まれるSession Bean.，Entity Bean，Message-driven BeanまたはWARの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(c)　注意事項

java.sql.Connectionからの生成物（例：java.sql.Statement）をトランザクションの範囲を超えて使用することはできません。

9.10.3　ステートメントプーリング

DB Connectorを使用した場合，JDBCのAPIであるjava.sql.PreparedStatementとjava.sql.CallableStatementの再利用を行うプーリング機能を使用できます。ステートメントプーリング機能によって，PreparedStatementとCallableStatementを使用した場合のパフォーマンス向上が図れます。なお，PreparedStatementとCallableStatementのプールサイズは，DB Connectorの設定で指定します。ステートメントプーリングを使用する際のプールサイズ設定の指針については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。また，DB Connectorのプロパティ定義については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

ステートメントプーリング機能を利用するには，コネクションプーリング機能を使用する必要があります。また，トランザクションサポートレベルにグローバルトランザクションを指定した場合，HiRDBのバージョンによっては利用できないことがあります。

注意

HiRDB Type4 JDBC DriverまたはCosminexus DABroker Libraryを使用する場合，PreparedStatement，CallableStatementのプールサイズに制限があります。指定できるプールサイズについては，「Cosminexus　リファレンス　定義編」を参照してください。

＜この項の構成＞

(1)　前提条件

(1)　前提条件

トランザクションサポートレベル，コネクションプーリング使用の有無，使用するデータベースの種類との対応による，ステートメントプーリング利用について次の表に示します。

表9-33　ステートメントプーリングの利用

トランザクションサポートレベル
コネクションプーリングを使用する
コネクションプーリングを使用しない

HiRDB※1
Oracle
SQL Server
XDM/RD E2
HiRDB／Oracle／
SQL Server

トランザクションなし（NoTransaction）
○
○
○
○
×

ローカルトランザクション（LocalTransaction）
○
○
○
○
×

グローバルトランザクション（XATransaction）
○※2
○
×
×
×

（凡例）　○：利用できる　　×：利用できない

注※1

ステートメントプーリング機能を使用した状態で，定義SQLを実行しないでください。定義SQLを実行する場合，ステートメントプーリング機能は使用できません。また，定義SQLを実行する場合は，HiRDBのクライアント環境変数として「PDDDLDEAPRP=YES」を設定する必要があります。

注※2

JDBCのDatabaseMetaData#supportsStatementPooling()の戻り値がtrueの場合に，利用できます。

なお，XDM/RD E2を使用する場合は，XDM/RD E2 11-02以降のバージョンとCosminexus DABroker Library 03-13以降，またはXDM/RD E2 11-03以降のバージョンとHiRDB Type4 JDBC Driver 08-02以降を使用する場合にだけステートメントプーリング機能を使用できます。XDM/RD E2と接続する場合の設定については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタのプロパティ定義に関する説明を参照してください。

9.10.4　ライトトランザクション

ライトトランザクションとは，ローカルトランザクションに最適化された環境を提供する機能です。これによって，良好なローカルトランザクション処理性能を得られます。ライトトランザクションは，ローカルトランザクションだけを使用する場合に適用できます。ライトトランザクション機能を有効にした場合，呼び出し先がBMTのときだけ，トランザクション中のEJBリモート呼び出しができます。

ライトトランザクション機能は，デフォルトでは有効となっています。ライトトランザクション機能を有効にした状態で，グローバルトランザクションを使用するとエラーになります。このため，グローバルトランザクションを使用する場合には，ライトトランザクション機能を無効にする必要があります。

ライトトランザクション機能を有効にするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

9.10.5　インプロセストランザクションサービス

Application Serverでは，トランザクションサービスをJ2EEサーバのインプロセスで起動できます。インプロセスでトランザクションサービスを起動すると，トランザクション処理をJ2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムを実現できます。

インプロセストランザクションサービスは，CORBAで規定されたOTS1.3の仕様をサポートしています。

9.10.6　DataSourceオブジェクトのキャッシング

J2EEアプリケーションからデータベースにアクセスする場合，JNDIインタフェースを使用してjavax.sql.DataSource型のオブジェクト（以降，DataSourceオブジェクト）の検索を要求します。J2EEサーバのデフォルトの動作では，該当するDataSourceが登録されている場合に，DataSourceオブジェクトのインスタンスを生成してアプリケーションに返します。

このとき，DataSourceオブジェクトのキャッシングを使用すると，J2EEサーバは，登録されているDataSourceオブジェクトのインスタンスをキャッシングして，検索の要求に対して同じインスタンスを返します。DataSourceオブジェクトのキャッシングを使用すると，DataSourceオブジェクトの検索時間が短くなります。

DataSourceオブジェクトのキャッシングをするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　前提条件

(2)　注意事項

(1)　前提条件

DataSourceオブジェクトのキャッシング機能は，Enterprise Beanのビジネスメソッド，およびサーブレット/JSPのサービスメソッド内でDataSourceをルックアップし，該当するインスタンスをメンバ変数などに保持しない場合に有効です。

ビジネスメソッドやサービスメソッド内でルックアップしたDataSourceオブジェクトをメンバ変数に保持し，ほかのメソッドでも利用する場合は有効ではありません。また，Enterprise BeanのejbCreateメソッドやサーブレット/JSPのinitメソッドなどの初期化メソッド内でルックアップしたDataSourceオブジェクトをメンバ変数に保持し，ビジネスメソッドやサービスメソッドで使用する場合も有効ではありません。

(2)　注意事項

DataSourceオブジェクトのキャッシング機能を使用する場合に，次に示すようなリソースアダプタを使用すると，動作時に属性ファイルの<resource-ref>の定義が有効にならないことがあります。

同一J2EEコンポーネントから同一リソースに対して複数の<resource-ref>タグを定義し，それぞれの<resource-ref>タグにある<res-sharing-scope>タグや<res-auth>タグに異なる値を指定した，リソースアダプタを使用する。

同一J2EEコンポーネントで複数の<resource-ref>タグを定義する場合は，別のリソース（デプロイ単位が別になるリソースアダプタ）を使用するようにしてください。

9.10.7　DB Connectorのコンテナ管理でのサインオンの最適化

DB Connectorでは，コンテナ管理のサインオンとコンポーネント管理のサインオンをサポートしています。

それぞれの方法の特徴を次に示します。

コンテナ管理でのサインオンの場合

コンテナ管理のサインオンを使用する場合，DB Connectorで設定するユーザ名とパスワードを使用して，データベースにアクセスします。

コンポーネント管理でのサインオンの場合

コンポーネント管理でのサインオンを使用する場合，コネクションファクトリのgetConnectionメソッドに渡されたユーザ名とパスワードを使用してデータベースにアクセスします。

なお，DBConnector_DABJ_XA.rarを使用する場合（グローバルトランザクションを使用する場合），XAOpen文字列に指定されたユーザ名とパスワードだけが有効となります。このため，getConnectionメソッドでユーザ名とパスワードを指定して利用する，コンポーネント管理でのサインオンはできません。

コンテナ管理のサインオンをするときに，サインオンの最適化機能を使用すると，コンテナ管理でのサインオン動作が最適化され，データベースとのコネクション取得のパフォーマンスが向上します。

DB Connectorのコンテナ管理でのサインオンの最適化をするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

コンテナ管理でのサインオンの最適化は，コンポーネント管理のサインオンをしない場合に使用してください。コンテナ管理でのサインオンの最適化をすると，コンポーネント管理でのサインオンは利用できなくなります。

コネクションプールのクラスタ化機能を利用する場合，一つのクラスタコネクションプール内で，コンテナ管理でのサインオンとコンポーネント管理でのサインオンを混在して使用できません。

9.10.8　受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合）

Cosminexus DABroker Libraryを使用する場合，実行したSQLに対して返却される実行結果を格納する領域をプールして再利用できます。この領域を受信バッファといいます。また，受信バッファをプールするための領域を受信バッファプールといいます。受信バッファをプールすることによって，SQL実行時に受信バッファが頻繁に作成，破棄されることで発生する負荷を削減できます。

また，プールする受信バッファの数を指定できるため，ステートメントプーリング使用時のメモリ占有量を抑制できます。

ここでは，受信バッファの管理と，受信バッファプール数の指定について説明します。

＜この項の構成＞

(1)　受信バッファの管理

(2)　受信バッファプール数の指定

(1)　受信バッファの管理

受信バッファの管理では，プールする受信バッファ数を指定する場合と指定しない場合とで，受信バッファの再利用のしかたが異なります。ここでは，プールする受信バッファ数を指定しない，デフォルトの場合について説明します。受信バッファ数を指定する場合については，「(2)　受信バッファプール数の指定」を参照してください。

受信バッファは，Statementごとに受信バッファプールに生成されます。生成された受信バッファはセクションIDで管理され，同一のStatementで再利用されます。なお，ここでは，Statement，PreparedStatement，およびCallableStatementをStatementと総称します。

受信バッファプールの管理の概要を次の図に示します。

図9-19　受信バッファプールの管理の概要（受信バッファプール数を指定しない場合）

受信バッファが生成されるタイミング

Statementの受信バッファはデータベースとの接続時に一つ生成され，そのセクションIDは「1」になります。これ以降はSQL実行時に受信バッファが生成されます。受信バッファが生成されると，受信バッファプールに登録されます。

受信バッファの保持期間

受信バッファプールに登録された受信バッファは，コネクションがクローズされるまで保持されます。ステートメントをクローズしても，受信バッファは破棄されません。

プールする受信バッファの数

プールできる受信バッファの数は，最大1,024個です。

SQLを実行するメソッド

次のメソッドを実行するとSQLが実行され，受信バッファが生成されます。

表9-34　SQLを実行するメソッド

クラス | メソッド
Connection | prepareCall(String sql)
prepareCall(String sql, int resultSetType, int resultSetConcurrency)
prepareStatement(String sql)
prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
DatabaseMetaData | getProcedures(String catalog, String schemaPattern, String procedureNamePattern)
getProcedureColumns(String catalog, String schemaPattern, String procedureNamePattern, String columnNamePattern)
getTables(String catalog, String schemaPattern, String tableNamePattern, String[] types)
getSchemas()
getTableTypes()
getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
getColumnPrivileges(String catalog, String schema, String table, String columnNamePattern)
getTablePrivileges(String catalog, String schemaPattern, String tableNamePattern)
getPrimaryKeys(String catalog, String schema, String table)
getIndexInfo(String catalog, String schema, String table, boolean unique, boolean approximate)
Statement | executeBatch()
execute(String sql)
executeQuery(String sql)
executeUpdate(String sql)
PreparedStatement | execute()
executeQuery()
executeUpdate()

(2)　受信バッファプール数の指定

受信バッファプールに登録してプールする受信バッファの数を指定できます。この数のことを受信バッファプール数といいます。受信バッファプール数を指定することによってSQL実行時の性能を向上でき，メモリ占有量を軽減できます。

受信バッファプール数は，1～1,024個の範囲で指定できます。受信バッファプール数を指定すると，同一コネクション内で受信バッファが再利用されます。そのため，セッションIDが異なるStatementでも，同一コネクションであれば受信バッファを再利用できます。受信バッファが，指定した受信バッファプール数よりも多く必要になった場合は，一時的に受信バッファを生成し，Cosminexus DABroker Libraryから実行結果のデータを受信したあとに破棄します。このような一時的に生成した受信バッファは，受信バッファプールには登録されません。

受信バッファプール数を指定した場合の，受信バッファプールの管理の概要を次の図に示します。

図9-20　受信バッファプールの管理の概要（受信バッファプール数を指定した場合）

受信バッファが生成されるタイミング

受信バッファが生成されるタイミングは，受信バッファプール数を指定しない場合と同じです。詳細については，「(1)　受信バッファの管理」を参照してください。

受信バッファを取得または返却するタイミング

受信バッファプールから受信バッファを取得するタイミング，および受信バッファを受信バッファプールに返却するタイミングは，SQLを実行するメソッドによって異なります。

各メソッドの動作は次の三つに分類されます。

表9-35　メソッドの動作の分類

動作 | 説明
1 | メソッド実行時に受信バッファを受信バッファプールから取得する。メソッド終了後，受信バッファを受信バッファプールに戻す。
2 | 動作2に分類されるメソッドのうち，最初に実行するメソッドで受信バッファを受信バッファプールから取得する。メソッドが終了しても，受信バッファは受信バッファプールに戻さない。
3 | 動作2に分類されるメソッドで取得した受信バッファを受信バッファプールに戻す。新たな受信バッファは取得しない。

受信バッファを再利用する際に受信バッファを取得または返却するメソッド，およびメソッドの動作を次の表に示します。動作の列の数字は，上記の表と対応しています。

表9-36　SQLを実行するメソッド，およびメソッドの動作

クラス | メソッド | 動作
Connection | prepareCall(String sql) | 1
prepareCall(String sql, int resultSetType, int resultSetConcurrency) | 1
prepareStatement(String sql) | 1
prepareStatement(String sql, int resultSetType, int resultSetConcurrency) | 1
DatabaseMetaData | getProcedures(String catalog, String schemaPattern, String procedureNamePattern) | 1
getProcedureColumns(String catalog, String schemaPattern, String procedureNamePattern, String columnNamePattern) | 1
getTables(String catalog, String schemaPattern, String tableNamePattern, String[] types) | 1
getSchemas() | 1
getTableTypes() | 1
getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern) | 1
getColumnPrivileges(String catalog, String schema, String table, String columnNamePattern) | 1
getTablePrivileges(String catalog, String schemaPattern, String tableNamePattern) | 1
getPrimaryKeys(String catalog, String schema, String table) | 1
getIndexInfo(String catalog, String schema, String table, boolean unique, boolean approximate) | 1
Statement | executeBatch() | 1
execute(String sql) | 1
executeQuery(String sql) | 1
executeUpdate(String sql) | 1
close()※ | 3
PreparedStatement | execute() | 1
executeQuery() | 1
executeUpdate() | 1
ResultSet | absolute(int row) | 2
afterLast() | 2
first() | 2
next() | 2
close() | 3

注※　ResultSet#close()メソッドを実行していない場合だけ使用できます。

(a)　受信バッファプール数の指定方法

受信バッファプール数は，次のどれかの方法で指定します。また，これらを同時に指定した場合，1，2，3の優先度順に決定されます。

DataSource#setBufferPoolSize()メソッドで指定する。

接続するデータベースの設定で，getConnectionメソッドおよびconnectメソッドの引数Properties infoに，キーワード「BUF_POOL_SIZE」を指定する。

データベースの各種情報の設定で，引数URLに「BUF_POOL_SIZE」を指定する。

指定方法の詳細については，「付録I.4　データベース接続の設定」を参照してください。

(b)　受信バッファプール数の目安

受信バッファプール数は，次の式で求められる数以上の数を目安に設定します。

検索処理に必要な受信バッファ数+更新処理に必要な受信バッファ数

検索処理に必要な受信バッファ数

アプリケーションの中で同時に使用するResultSetの数です。

実行するStatementが4個のアプリケーションの場合の，ResultSetの数の例を次の図に示します。

図9-21　アプリケーション中で同時に使用するResultSetの数

この図の場合，アプリケーションの開始から終了までの間に同時に使用するResultSetの数は3のため，検索処理に必要な受信バッファ数は3となります。

更新処理に必要な受信バッファ数

次のどちらかで求めます。

更新処理を単一スレッドで逐次実行する場合は，1

更新処理をマルチスレッドで同時実行する場合は，アプリケーションの中で同時実行する更新SQLの数

実際に必要な受信バッファ数が，この式を基に設定した受信バッファ数を超えた場合，受信バッファを新たに生成し，使用後に破棄します。このとき，生成した受信バッファは受信バッファプールに登録されません。この場合，オブジェクトの作成，破棄が頻発するため，性能が劣化することがあります。ただし，設定した受信バッファ数を超えた分の受信バッファは使用後に破棄するため，式を基に設定した場合よりメモリ占有量は軽減します。

9.11　フォールトトレランスのための機能

この節では，フォールトトレランスのための機能として，次の機能を紹介しています。

コネクションの障害検知

コネクション枯渇時のコネクション取得待ち

コネクションの取得リトライ

コネクションプールの情報表示

コネクションプールのクリア

コネクションの自動クローズ

コネクションスイーパ

トランザクションタイムアウト

トランザクションリカバリ

障害調査用SQLの出力

オブジェクトの自動クローズ

これらの機能について，以降の項で説明します。

＜この節の構成＞

9.11.1　コネクションの障害検知

9.11.2　コネクション枯渇時のコネクション取得待ち

9.11.3　コネクションの取得リトライ

9.11.4　コネクションプールの情報表示

9.11.5　コネクションプールのクリア

9.11.6　コネクションの自動クローズ

9.11.7　コネクションスイーパ

9.11.8　トランザクションタイムアウトとステートメントキャンセル

9.11.9　トランザクションリカバリ

9.11.10　障害調査用SQLの出力

9.11.11　オブジェクトの自動クローズ

9.11.1　コネクションの障害検知

コネクションプーリングを使用している場合，リソースダウン・ネットワーク障害などが発生すると，ユーザプログラムのコネクション取得要求に対し，障害が発生したコネクションを返すおそれがあります。コネクションの障害検知機能を使用すると，プーリングされているコネクションに障害が発生していないかをチェックし，障害が発生したコネクションをなるべく返さないようにできます。

コネクション障害検知機能は，コネクション取得リトライ機能と併用できます。この場合，ユーザプログラムのコネクション取得要求時にコネクション障害を検知すると，新しいコネクション取得のリトライを実施し※，障害が復旧した時点でコネクションをユーザプログラムに返すことができます。

注※

新しいコネクションを作成して返すことは，コネクションの障害検知のタイミングを「コネクション取得要求時」に設定している場合だけ有効になります。

コネクションの障害検知のタイミングについては，「(1)　障害検知を実施するタイミング」を参照してください。

＜この項の構成＞

(1)　障害検知を実施するタイミング

(2)　障害検知のタイムアウト

(3)　チェック時の動作

(4)　前提条件

(5)　注意事項

(1)　障害検知を実施するタイミング

コネクションの障害を検知するタイミングは，表に示したタイミングのどちらかを選択できます。

表9-37　コネクションの障害検知のタイミング

障害検知のタイミング | 内容
コネクション取得要求時 | コネクション取得時に，毎回，障害検知を実施します。この場合，コネクション取得要求のレスポンス性能が劣化しますが，障害が発生したコネクションを取得する確率は低くなります。コネクション取得要求の頻度が少ない場合や，障害が発生したコネクションの取得がほとんど許容されない場合に有用です。
一定間隔 | 一定時間の間隔で，障害検知を実施します。障害検知の間隔をある程度長くすることで，障害検知処理による性能劣化を少なくできます。ただし，障害が発生したコネクションを取得する確率は高くなります。コネクション取得要求の頻度が多い場合や，障害が発生したコネクションの取得がある程度許容される場合に有用です。

なお，デフォルトでは，コネクション取得要求時に障害検知を実施する設定となっています。コネクションの障害検知を実施しない設定もできます。

コネクション障害検知の有効・無効の切り替えや，検知するタイミングの設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　障害検知のタイムアウト

コネクション障害検知に対する応答時間にタイムアウトを設定できます。

サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション障害検知の実行に対しても応答が返らなくなることがあります。タイムアウトを設定することで，リソースからの応答が返らない場合も，コネクションのチェックを終了して，処理を継続できます。なお，障害検知のタイムアウト時間は5秒（固定）です。

コネクション障害検知のタイムアウトは，コネクション管理スレッドを使用して動作します。コネクション管理スレッドは，コネクションプールのコネクション数に応じてシステム内で作成されます。コネクション管理スレッドの数と，コネクションプールのコネクション数の最大値の関係を次に示します。

コネクション管理スレッド数 = コネクションプールのコネクション数の最大値×2

このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費します。必要なメモリ使用量を適切に見積もってください。

また，コネクションプールのコネクション数の最大値の設定が無制限の場合，メッセージが出力されて，コネクション障害検知のタイムアウトが無効になります。

なお，コネクション障害検知のタイムアウトを有効にする場合の注意事項の詳細については，「(5)　注意事項」を参照してください。

コネクション障害検知のタイムアウトの有効・無効は，リソースアダプタのプロパティをカスタマイズして設定します。リソースアダプタのプロパティの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(3)　チェック時の動作

コネクション障害検知をコネクション取得要求時に実施する場合と，一定間隔で実施する場合の動作について説明します。

コネクション障害検知をコネクション取得要求時に実施する場合
コネクション障害検知をコネクション取得要求時に実施する場合の動作を次に示します。

コネクションプールから未使用コネクションが取得されます。

コネクションチェックメソッドによって，コネクションに障害が発生していないかどうかチェックされます。
コネクション障害検知のタイムアウトが無効な場合，このチェックはコネクション取得要求の延長で実施されます。
コネクション障害検知のタイムアウトが有効な場合，このチェックはコネクション管理スレッドで実施されます。サーバ障害やネットワーク障害などでチェックメソッドの応答が5秒以内に返らないときは，コネクションに障害が発生していると判断されます。このとき，メッセージが出力されます。
なお，リソースアダプタにコネクションチェックメソッドが実装されていない場合，コネクションの状態はチェックされません。

コネクションに障害が発生している場合，チェックに使用したコネクションが破棄されて，新たに作成されたコネクションがユーザプログラムに返されます。
コネクションに障害が発生していない場合，チェックに使用したコネクションがユーザプログラムに返されます。

コネクション障害検知を一定間隔で実施する場合
コネクション障害検知を一定間隔で実施する場合の動作を次に示します。

コネクションプールから未使用コネクションが一つ取得されて，そのコネクションが有効であるかどうかがチェックされます。
ただし，未使用コネクションがプーリングされていない場合は，チェックされません。

コネクション障害検知のタイムアウトが無効な場合，コネクションチェックメソッドによって，コネクションに障害が発生していないかどうかのチェックが一定間隔で実施されます。
コネクション障害検知のタイムアウトが有効な場合，コネクション管理スレッドで，チェックが一定間隔で実施されます。サーバ障害やネットワーク障害などでチェックメソッドの応答が5秒以内に返らないときは，コネクションに障害が発生していると判断されます。このとき，メッセージが出力されます。
なお，リソースアダプタにコネクションチェックメソッドが実装されていない場合，コネクションの状態はチェックされません。

コネクションに障害が発生している場合に，コネクション障害検知のタイムアウトが無効のときは，コネクションチェックに使用されたコネクションが破棄されて，コネクションプール内の使用中コネクションが再利用不可にマークされます。また，未使用コネクションが破棄されます。
コネクション障害検知のタイムアウトが有効のときは，コネクションチェックに使用したコネクションが破棄されて，コネクション管理スレッドによってコネクションプール内の使用中コネクションが再利用不可にマークされます。また，未使用コネクションが，コネクションプールから取り除かれて，破棄されます。
コネクションに障害が発生していない場合は，コネクションチェックに使用されたコネクションがコネクションプールに返却されます。

(4)　前提条件

コネクションの障害検知機能の利用可否を次の表に示します。

表9-38　コネクションの障害検知機能の利用可否

リソース | 接続方法 | 利用可否
データベース | DB Connector | ○
データベース上のキュー | DB Connector for Cosminexus RMとCosminexus RM | ○
OpenTP1 | uCosminexus TP1 Connector | 　 ×※1
TP1/Message Queue - Access | 　 ×※1
SMTPサーバ | メールコンフィグレーション | ×
JavaBeansリソース | － | ×
そのほかのリソース | Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ | 　 △※2

（凡例）

○：使用できる　　×：使用できない　　△：条件によって異なる　－該当なし

注※1

Application Serverが提供するコネクションの障害検知機能は使用できませんが，uCosminexus TP1 ConnectorまたはTP1/Message Queue - Accessでは，コネクションの障害検知機能と同様の機能が提供されています。

注※2

Connector 1.5仕様に準拠したリソースアダプタを使用している場合に，リソースアダプタがValidatingManagedConnectionFactoryインタフェースのgetInvalidConnectionsメソッドを実装しているときに使用できます。

(5)　注意事項

パラレルサーバ構成のリソースを使用する場合の注意事項と，コネクション障害検知のタイムアウトを有効にした場合の注意事項について説明します。

(a)　パラレルサーバ構成のリソースを使用する場合の注意事項

コネクション障害検知を一定間隔で実施する場合，コネクションプール内のコネクションをサンプリングチェックするため，一部のサーバに障害が発生しても検知できないことがあります。

(b)　コネクション障害検知のタイムアウトを有効にした場合の注意事項

コネクション障害検知のタイムアウトを有効にした場合の注意事項を次に示します。

コネクション障害検知にタイムアウトを設定した場合，システム内で，コネクションプールのコネクション数に応じた障害検知用のスレッドが生成されます。このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費するので注意が必要です。
障害検知用のスレッドは，コネクションプールの最大コネクション数の2倍の数だけ作成されます。必要なメモリ使用量を適切に見積もってください。

サーバ障害やネットワーク障害などが繰り返し発生する場合にシステムの運用を続けると，コネクションチェックメソッドを実行中のコネクション管理スレッドが増え続け，システム側が用意したすべてのコネクション管理スレッドを使い切るおそれがあります。使用できるコネクション管理スレッドがない場合，メッセージが出力されて，コネクション取得要求がエラーとなります。

コネクション障害検知を一定間隔で実施する場合，コネクションプールから取り除いた未使用コネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールのコネクション数の最大値を超える場合があります。

9.11.2　コネクション枯渇時のコネクション取得待ち

コネクションがコネクションプールに指定した最大コネクション数までプールされていて，利用できるコネクションがプール中にない状態を，コネクション枯渇といいます。

コネクション枯渇状態のときには，コネクション取得要求を待ち状態にできます。待ち状態になっているコネクション取得要求は，コネクションが解放されるとすぐにコネクションを取得できます。これによって，コネクション枯渇時に，効率良くコネクションを取得できます。コネクション枯渇時の取得待ちについて，次の図で説明します。

図9-22　コネクション枯渇時のコネクション取得待ち

この図では，コネクションプールの最大数は2となっています。このため，四つのgetConnectionからコネクション取得要求があっても，二つまでしか処理できません。最初の二つのコネクションの取得要求については，コネクションプールにコネクションがあるため，コネクションの取得ができます。残りの二つについては，コネクション枯渇の状態になるため，コネクション取得待ちのキューに入り，コネクションが解放されるのを待ちます。

なお，コネクション取得待ちは，コネクションプールを利用している場合に設定できます。

コネクション取得待ちをする場合には，リソースアダプタのプロパティとして，次の二つの内容を設定する必要があります。

コネクション枯渇時にコネクションの取得待ちをするかどうか

コネクション取得待ちの最大時間

リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　コネクション枯渇時の動作

(1)　コネクション枯渇時の動作

コネクション取得待ちを設定している場合，コネクション枯渇時のコネクション取得要求は待ち状態になります。

また，コネクション取得要求を再開するタイミングは，次のどちらかになります。

コネクションが解放されて，未使用コネクションができたとき

コネクションが破棄されて，コネクション数が最大数未満になったとき

なお，コネクション取得要求の再開後にエラーが発生した場合，コネクション取得のリトライ機能が有効になっているときは，リトライ処理が実施されます。

9.11.3　コネクションの取得リトライ

コネクション取得リトライは，使用できるコネクションがコネクションプールにない場合や，物理コネクションの確立に失敗した場合に，自動的にコネクションの取得をリトライする機能です。コネクション取得リトライ機能を使用することで，コネクション取得に失敗した場合に，ユーザプログラムでリトライをする必要がなくなります。

コネクション取得をリトライできる条件は次のとおりです。

コネクションの取得要求時に，コネクションプールに未使用状態のコネクションがない場合で，コネクションプールのコネクション総数がプーリングするコネクションの最大数に達しているとき

物理コネクションの確立に失敗した場合

なお，リトライしてもコネクションが取得できない場合は，アプリケーションプログラムに例外が通知され，コネクションの取得は失敗します。

コネクションプールが枯渇したときの動作は，「9.11.2　コネクション枯渇時のコネクション取得待ち」に従います。

コネクション取得リトライを実施する場合には，リソースアダプタのプロパティとして，次の二つの内容を設定する必要があります。

リトライの回数
リトライする回数を設定します。

リトライまでの間隔
次のリトライまでの間隔を秒単位で設定します。

なお，リトライの回数，およびリトライまでの間隔を大きくすると，コネクション取得処理が重なった場合に，待ちが発生するおそれがあります。

リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　前提条件

(1)　前提条件

コネクション取得のリトライ機能を使用するための前提条件を次の表に示します。

表9-39　コネクション取得のリトライ機能の利用

リソース | 接続方法 | 利用可否
データベース | DB Connector | ○
データベース上のキュー | DB Connector for Cosminexus RMとCosminexus RM | ○
OpenTP1 | uCosminexus TP1 Connector | ○
TP1/Message Queue - Access | ○
SMTPサーバ | メールコンフィグレーション | ×
JavaBeansリソース | － | ×
そのほかのリソース | Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ | ○

（凡例）　○：使用できる　　×：使用できない　　－：該当なし

9.11.4　コネクションプールの情報表示

コネクションプール内のコネクションの情報は，cjlistpoolコマンドを使用して表示できます。cjlistpoolコマンドは，コネクションプールのクラスタ化機能を使用した場合のメンバリソースアダプタに対しても実行できます。

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。また，コネクションプールのクラスタ化機能については，「9.12　コネクションプールのクラスタ化」を参照してください。

メンバリソースアダプタのコネクション情報の表示例を次に示します。なお，コネクションプールが無効な場合は，コネクション情報は表示されません。

図9-23　メンバリソースアダプタのコネクション情報の表示例

9.11.5　コネクションプールのクリア

データベースサーバのダウンなどによって，コネクションが切断された場合，プールされているコネクションはコネクションプール内に残ってしまいます。これらのコネクションは，cjclearpoolコマンドによって削除できます。

なお，コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

9.11.6　コネクションの自動クローズ

ユーザプログラムがオープンしたリソースのコネクションは，ユーザプログラムでクローズする必要があります。例外発生などの理由で，ユーザプログラムがコネクションをクローズすることができない場合，WebコンテナやEJBコンテナが自動的にコネクションをクローズする機能があります。

コネクション自動クローズ機能は，機能によって有効と無効を切り替えることができます。コネクションの自動クローズの方法と切り替えについて次の表に示します。

表9-40　コネクション自動クローズの方法と機能の切り替え

自動クローズの方法 | 有効と無効の切り替え | 備考
Webコンテナによるコネクション自動クローズ | ○※1※2 | －
EJBコンテナによるコネクション自動クローズ | ×※1 | 常に有効になります。

（凡例）　○：切り替えできる　×：切り替えできない

注※1

対象リソースは，リソースアダプタのコネクションとなります。

注※2

Webコンテナによるコネクションの自動クローズ機能は，デフォルトでは有効となっています。無効にする場合は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　Webコンテナによるコネクション自動クローズ

(2)　EJBコンテナによるコネクション自動クローズ

(3)　コネクション自動クローズが実行されたことを確認する方法

(4)　注意事項

(1)　Webコンテナによるコネクション自動クローズ

サーブレットやJSPのサービスメソッド内で，取得・オープンされたJDBCコネクションのうち，メソッドの実行完了時にクローズが実行されていないコネクションに対して，J2EEコンテナ側で自動的にコネクションをクローズします。これによって，オープンされたまま蓄積しているコネクションを，自動でクローズできます。

なお，コネクションの自動クローズ機能は，サーブレット内部の別のメソッド，または外部のクラスでコネクションを取得・利用した場合にも有効です。

Webコンテナによるコネクション自動クローズは，サーブレットやJSPのserviceメソッドが完了したときに実行されます。

(2)　EJBコンテナによるコネクション自動クローズ

例外発生などの理由で，EJB内で取得したリソースのコネクションをユーザがクローズできない場合に，EJBコンテナが自動的にコネクションをクローズして解放する機能です。

EJBコンテナによるコネクションの自動クローズは，次のタイミングで実施されます。

EJBが破棄されるとき

Stateless Session Beanで，ビジネスメソッドがリターンするとき

Stateful Session Beanがパッシベイトされるとき

(3)　コネクション自動クローズが実行されたことを確認する方法

コネクション自動クローズが実行されたことは，メッセージログまたはPRFトレースで確認できます。

テスト実行時や障害調査時など，性能を考慮しなくてよい場合は，メッセージログによって確認することをお勧めします。実運用時に確認したい場合は，PRFトレースによって確認することをお勧めします。

(a)　メッセージログで確認する方法

ログレベルを「Warning」に設定してください。

コネクション自動クローズが実行された場合は，J2EEサーバのメッセージログにKDJE31010-Wが出力されます。

ログレベルの設定方法については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのログ取得の設定の説明を参照してください。

(b)　PRFトレースでの確認方法

JCAコンテナの機能レイヤのPRFトレース取得レベルを「詳細」に設定してください。

コネクション自動クローズが実行された場合は，PRFトレースファイルに次のイベントIDが出力されます。

0x8B84

0x8B85

PRFトレースの取得レベルの設定方法については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのログ取得の設定の説明を参照してください。また，機能レイヤごとのPRFトレース取得レベルの設定方法については，マニュアル「Cosminexus　リファレンス　コマンド編」のcprflevelコマンドまたはcprfstartコマンドの説明を参照してください。

(4)　注意事項

Servlet/JSPでユーザが生成したスレッド（ユーザスレッド）で取得したコネクションは，自動クローズされません。

9.11.7　コネクションスイーパ

コネクションスイーパは，一定間隔でコネクションプールを監視し，一定時間使用していない未使用コネクションを破棄する機能です。該当コネクションを最後に利用した時点からの経過時間が，指定された時間以上の場合に，コネクションを破棄します。

コネクションスイーパ機能は，デフォルトでは無効になっています。なお，コネクションスイーパ機能の設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

9.11.8　トランザクションタイムアウトとステートメントキャンセル

トランザクションの開始時点からの経過時間を監視し，指定された時間が経過した時点でトランザクションをロールバックする機能です。監視期間は，トランザクションの開始時点から，トランザクションの決着時点までです。トランザクションタイムアウトが発生したあと，該当するトランザクションでのJTA，およびJDBCインタフェースへのアクセスは例外が通知されます。

トランザクションタイムアウト機能は，Application Serverが管理するトランザクションの場合に有効です。

なお，BMT，サーブレット，またはJSPの場合，トランザクションタイムアウトが発生したあと，該当するトランザクションに対してUserTransaction.commit/rollbackを発行すると，JTA，およびJDBCインタフェースにアクセスできるようになります。

＜この項の構成＞

(1)　トランザクションタイムアウトの設定単位

(2)　トランザクションタイムアウト発生時のステートメントキャンセル

(1)　トランザクションタイムアウトの設定単位

トランザクションタイムアウトの設定は，J2EEサーバ単位またはBean単位で設定できます。

(a)　J2EEサーバ単位での設定

J2EEサーバ単位の設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(b)　Bean単位での設定

Bean単位で設定するには，BMTの場合とCMTの場合で異なります。

BMTの場合
UserTransactionインタフェースを使用してトランザクションを管理する場合は，UserTransactionインタフェースのsetTransactionTimeoutメソッドを使用して，デフォルト値から変更できます。

CMTの場合
サーバ管理コマンドを使用して設定します。設定単位は，Bean単位，インタフェース単位，およびメソッド単位の三つから選択できます。
設定が有効になるメソッドは，次のどちらかです。

トランザクション属性が「Required」に設定され，EJBコンテナがトランザクションを開始するメソッド

トランザクション属性が「RequiresNew」に設定されたメソッド

クライアントから伝播するトランザクションで動作するSupports属性およびMandatory属性の場合，トランザクションを使用しないNotSupported属性およびNever属性の場合は，タイムアウトの設定は無効になります。なお，トランザクション属性については，「5.5.2　CMT」を参照してください。
なお，設定の優先順位は，次のとおりです。

メソッド単位での設定

インタフェース単位での設定

Bean単位での設定

J2EEサーバ単位での設定

Bean単位のトランザクションタイムアウトの設定は，J2EEアプリケーションに含まれるSession Bean，Entity BeanまたはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　トランザクションタイムアウト発生時のステートメントキャンセル

実行中のSQL処理が返ってこない状態でトランザクションタイムアウトが発生すると，ステートメントがキャンセルされます。

ステートメントのキャンセルを有効にする場合，DB ConnectorのCancelStatementプロパティにtrueを設定する必要があります。リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

9.11.9　トランザクションリカバリ

J2EEサーバやリソースマネジャの障害で，プリペア状態またはヒューリスティック完了状態となった2フェーズトランザクションを決着させる機能です。グローバルトランザクションを使用する場合に有効になります。

J2EEサーバを開始すると，インポートされているリソースに対して，無条件にトランザクションの全面回復処理を実行します。また，トランザクション実行中にリソースマネジャがダウンした場合にも，部分回復処理をします。

なお，トランザクションの状態は，インプロセストランザクションサービスを使用している場合，サーバ管理コマンドのcjlisttrnコマンドで表示できます。また，停止中のJ2EEサーバのステータスファイルに残っている，未決着トランザクション情報はcjlisttrnfileコマンドで表示できます。

ライトトランザクションが有効なときには，トランザクションリカバリ機能は使用できません。

注意

J2EEサーバ再起動によるトランザクションリカバリをしない場合，トランザクションの回復は各リソースの回復手順に従い，ユーザ責任で手動回復してください。

＜この項の構成＞

(1)　J2EEサーバ終了時の未決着トランザクションの確認とタイムアウトの設定

(2)　注意事項

(1)　J2EEサーバ終了時の未決着トランザクションの確認とタイムアウトの設定

J2EEサーバを正常停止する時，J2EEサーバは未決着のトランザクションがないことを確認してから停止します。未決着のトランザクションがあるときは，それらが完了するまで無限に待ちます。また，そのトランザクションが決着するまでリソースを削除できません。

これに対して，システム開発時など，トランザクションを早急に解決する必要がない場合は，未決着トランザクションの確認時間にタイムアウトを設定できます。タイムアウトが発生した場合は，未決着のトランザクションの確認処理が完了していなくても，J2EEサーバの停止処理がされます。ただし，タイムアウトは，J2EEアプリケーション開発時などに設定してください。J2EEアプリケーション運用時には，トランザクションの信頼性を保証するために，タイムアウトを設定しないことをお勧めします。

タイムアウトの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　注意事項

トランザクションリカバリについての注意事項を説明します。

(a)　J2EEサーバ起動時にリソースアダプタの開始に失敗した場合の注意

J2EEサーバ起動時にXATransactionを利用するリソースアダプタの開始に失敗した場合，J2EEサーバはトランザクションリカバリを実行しないで，メッセージKDJE48605-Eを出力して強制停止します。この場合は，リソースアダプタの開始処理が失敗する原因を取り除いてから，J2EEサーバを再起動してください。これによって，プリペア状態またはヒューリスティック状態のトランザクションは決着されます。

(b)　J2EEサーバを再起動する時の注意

J2EEサーバが強制終了または異常終了したあと，リソースを削除するとリカバリできなくなります。このため，再起動時にリソースの構成を変更しないでください。

強制終了または異常終了前の受信ポートと同じポートで再起動する必要があります。このため，簡易構築定義ファイル内の<configuration>タグ内のパラメタ「ejbserver.distributedtx.recovery.port」の値を変更しないでください。なお，Management Serverを利用しないでシステムを構築する場合は，usrconf.propertiesのejbserver.distributedtx.recovery.portキーを変更しないでください。

(c)　トランザクションリカバリを実行するための権限

リカバリはリソース（XADataSourceなど）に設定したデフォルトユーザで実行します。リソースマネジャによっては，未決着トランザクションの走査に特別な権限や設定が必要になります。また，複数のユーザでサインオンする場合，デフォルトユーザにそのほかのユーザのトランザクションを決着できるリソースマネジャでの適正な権限を付与する必要があります。なお，詳細については，各リソースのマニュアルを参照してください。

Oracleでリカバリをする場合で，JDBCドライバにCosminexus DABroker Libraryを使用するときは，ユーザに次の権限が必要です。

SYS.DBA_PENDING_TRANSACTIONSへのSELECT権限

FORCE_ANY_TRANSACTION権限

Oracleでリカバリをする場合で，JDBCドライバにOracle JDBC Thin Driverを使用するときは，ユーザに次の権限が必要です。

SYS.DBA_PENDING_TRANSACTIONSへのSELECT権限

FORCE_ANY_TRANSACTION権限

SYS.DBMS_SYSTEMをEXECUTEする権限

Oracleを使用する場合の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(d)　使用するコネクション数

トランザクションリカバリをする場合に使用するコネクション数に注意してください。

J2EEサーバでは，トランザクションサポートレベルがXATransactionの一つのリソースアダプタに対して，次のコネクションを確立します。

プーリング管理をするコネクション

リカバリ用のコネクション（一つ）

同一のリソースマネジャで必要となる最大コネクション数は，次の式で示す値になります。リソースマネジャにコネクション数の上限がある場合は，注意してください。

同一のリソースマネジャで必要となる最大コネクション数＝IR(1) + … + IR(N) + N

IR(i)

i番目のリソースアダプタのプール設定値の最大コネクション数。

1≦i≦Nです。

N

Connector 1.0仕様に準拠したリソースアダプタの場合は，同一のリソースマネジャに接続するリソースアダプタ数。

Connector 1.5仕様に準拠したリソースアダプタの場合は，同一のリソースマネジャに接続するリソースアダプタ内のコネクション定義数の総数。

対象になるのは，開始状態で，かつトランザクションサポートレベルがXATransactionのリソースアダプタです。

9.11.10　障害調査用SQLの出力

デッドロックやスローダウンなどの障害が発生した場合,発行したSQLが障害の要因となった可能性があります。そこで，発行したSQLをログに出力することによって，障害要因の解析が容易になります。ログに出力されるSQLの情報を障害調査用SQLと呼びます。

＜この項の構成＞

(1)　出力されるタイミング

(2)　出力先

(3)　出力内容

(4)　注意事項

(1)　出力されるタイミング

障害調査用SQLは，次のタイミングで出力されます。

トランザクションタイムアウト発生時

J2EEアプリケーションの強制停止実行時

メソッドキャンセルコマンド実行時

メソッドタイムアウト発生後のメソッドキャンセル実行時

(2)　出力先

障害調査用SQLは，リソースアダプタの稼働ログ，および性能解析トレースに出力されます。

リソースアダプタの稼働ログでは，KDJE50080-Wのメッセージに出力されます。詳細については，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

性能解析トレースでは，0x8C41のイベントIDに出力されます。詳細については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

(3)　出力内容

出力対象のコネクションでSQLを発行している場合，物理コネクションがSQLを保持しています。この物理コネクションが保持しているSQLが，障害調査用SQLとして出力されます。

SQLを保持する物理コネクション

障害調査用SQLが出力されるタイミングごとに，SQLを保持している物理コネクションを示します。

トランザクションタイムアウト発生時
トランザクションに参加しているコネクションに対応する物理コネクション。

J2EEアプリケーションを強制停止した時，メソッドキャンセルコマンド実行時，またはメソッドタイムアウト発生後のメソッドキャンセル実行時
トランザクション処理中の場合，トランザクションに参加しているコネクションに対応する物理コネクション。
トランザクションを使用していない場合，アプリケーション強制停止またはメソッドキャンセルを実行するインスタンスで使用中のコネクションに対応する物理コネクション。なお，クローズしたコネクションは，障害調査用SQL出力の対象外になります。

SQLを保持するAPI

ユーザアプリケーションで次のAPIが呼び出されたとき，引数で渡されたSQLを物理コネクションに保持します。保持するSQLは物理コネクションごとに一つです。APIが呼び出されるたびに，最新のSQLが上書きされます。SQLを保持するAPIを次の表に示します。

表9-41　SQLを保持するAPIの一覧

クラス | メソッド
java.sql.Connection | prepareCall(String sql)
prepareCall(String sql, int resultSetType, int resultSetConcurrency)
prepareCall(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)
prepareStatement(String sql)
prepareStatement(String sql, int autoGeneratedKeys)
prepareStatement(String sql, int[] columnIndexes)
prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
prepareStatement(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)
prepareStatement(String sql, String[] columnNames)
java.sql.Statement | addBatch(String sql)
execute(String sql)
execute(String sql, int autoGeneratedKeys)
execute(String sql, int[] columnIndexes)
execute(String sql, String[] columnNames)
executeBatch()※1
executeQuery(String sql)
executeUpdate(String sql)
executeUpdate(String sql, int autoGeneratedKeys)
executeUpdate(String sql, int[] columnIndexes)
executeUpdate(String sql, String[] columnNames)
java.sql.PreparedStatement | java.sql.Statementから継承した表示対象メソッド
addBatch()※2
execute()※2
executeQuery()※2
executeUpdate()※2
java.sql.CallableStatement | java.sql.PreparedStatementから継承した表示対象メソッド

注※1　executeBatch()メソッドを実行した場合は，最後にaddBatch(String sql)メソッド， addBatch()メソッドで加えられたSQLを物理コネクションに保持します。

注※2　addBatch()メソッド，execute()メソッド，executeQuery()メソッド，executeUpdate()メソッドを実行した場合，java.sql.ConnectionのprepareStatementメソッド，prepareCallメソッドの引数で与えられたSQLを物理コネクションに保持します。ただし，SQLのINパラメタプレースホルダー（"？"）は，置換しないで"？"のまま出力します。

(4)　注意事項

障害調査用SQLの出力機能についての注意事項を説明します。

DB Connectorを使用している場合，この機能は常に有効になります。DB Connector以外を使用している場合は無効になります。

リソースアダプタの稼働ログの障害調査用SQLログに出力されるメッセージが4キロバイトを超えた場合，4キロバイトまでのメッセージだけが出力されます。

コネクションシェアリング，コネクションアソシエーションによって共有されたコネクションは，物理コネクションが一つのため，障害調査用SQLログは一つだけ出力されます。

9.11.11　オブジェクトの自動クローズ

ユーザプログラムでオープンしたStatementオブジェクトなどは，ユーザプログラムでクローズする必要があります。ただし，クローズできなかった場合，DB Connectorは，ユーザハンドル（java.sql.Connection）から生成された，次のオブジェクトを自動的にクローズできます。

Statementオブジェクト

PreparedStatementオブジェクト

CallableStatementオブジェクト

各種ステートメントやDatabaseMetaDataから生成されたResultSetオブジェクト

9.12　コネクションプールのクラスタ化

コネクションプールのクラスタ化機能は，データベースをクラスタ構成にしているシステムの場合に，最適な動作をするための機能です。コネクションプールのクラスタ化機能を使用することで，障害発生時やメンテナンス時の可用性の低下を防ぐことができます。コネクションプールのクラスタ化機能の使用時に，データベースノードに障害が発生した場合，およびデータベースノードのメンテナンスを行う場合の動作について説明します。

データベースノードに障害が発生した場合
OS，ハード，ソフト障害など，コネクションが取得できない状況になった場合，障害が発生しているデータベースノードに接続しているコネクションプールを自動で一時停止できます（自動一時停止機能）。J2EEアプリケーションからリソースアダプタにコネクションの取得要求が出された場合でも，一時停止されたコネクションプールにはコネクションの取得要求が出されないため，TCP/IPのタイムアウトまで処理が中断することはありません。これによって，J2EEアプリケーションは，ほかの正常なデータベースノードに接続しているコネクションプールからコネクションを取得し，業務を継続できます。
また，データベースノードの障害が回復した時に，自動でコネクションプールを再開できます（自動再開機能）。コネクションプールが再開されると，自動的に回復したデータベースノードから再びアクセスされるため，データベースノード回復時にcjclearpoolコマンドを実行して，コネクションプールを削除する必要はありません。

データベースノードのメンテナンスを行う場合
データベースノードのメンテナンスを行う場合，コマンドを使用して任意のタイミングでメンバコネクションプールを一時停止できます（手動一時停止機能）。これによって，そのデータベースノードを切り離して，メンテナンスを行えます。
また，メンテナンスが終了して再開する時に，コマンドを使用して任意のタイミングでコネクションプールを再開できます（手動再開機能）。

コネクションプールをクラスタ化する場合のコネクションプール（クラスタコネクションプール）の特徴，および機能について説明します。なお，Oracle RAC機能を使用してクラスタ化したOracleとの接続方法については，「付録F　Oracle RACを使用したOracleへの接続」を参照してください。

＜この節の構成＞

9.12.1　クラスタコネクションプールの概要

9.12.2　クラスタコネクションプールの動作

9.12.3　使用するリソースアダプタ

9.12.1　クラスタコネクションプールの概要

クラスタ化されたコネクションプールのことをクラスタコネクションプールといいます。ここでは，クラスタコネクションプールの構成，およびクラスタコネクションプールで使用できる機能について説明します。

＜この項の構成＞

(1)　クラスタコネクションプールの構成

(2)　前提条件

(3)　データベース接続で使用できるJ2EEコンポーネントおよび機能

(4)　使用できるリソース接続とトランザクション管理の機能

(1)　クラスタコネクションプールの構成

クラスタコネクションプールは，各データベースノードと接続するメンバリソースアダプタと，それら複数のメンバリソースアダプタを束ねるルートリソースアダプタで構成されています。ルートリソースアダプタとメンバリソースアダプタについて説明します。

ルートリソースアダプタ
クラスタ化したコネクションプール（クラスタコネクションプール）を使用するときに，J2EEアプリケーションからアクセスされるリソースアダプタです。ルートリソースアダプタは，メンバリソースアダプタを束ねる役割を持ちます。ルートリソースアダプタでは，ルートリソースアダプタに対する処理要求をメンバリソースアダプタに振り分けます。なお，ルートリソースアダプタは，コネクションプールを持ちません。

メンバリソースアダプタ
クラスタ化されている個々のデータベースノードに接続するリソースアダプタです。メンバリソースアダプタは，必ずルートリソースアダプタを経由してアクセスされます。メンバリソースアダプタのコネクションプールのことを，メンバコネクションプールといいます。

コネクションプールをクラスタ化しているときのコネクション取得時の処理の流れを次の図に示します。

図9-24　コネクション取得時の処理の流れ

J2EEアプリケーションは，ルートリソースアダプタに対しコネクション取得要求をする。

ルートリソースアダプタは，メンバコネクションプールを一つ選択し，コネクション取得要求を出す。

メンバコネクションプールからコネクションが選択され，J2EEアプリケーションに返す。

(2)　前提条件

コネクションプールのクラスタ化機能を利用できるデータベースは，Oracle10gでRAC機能を使用している場合だけです。使用できるJDBCドライバは，Oracle JDBC Thin Driverです。

(3)　データベース接続で使用できるJ2EEコンポーネントおよび機能

コネクションプールのクラスタ化機能を使用している場合に，データベース接続で使用できるJ2EEコンポーネントおよび機能を次の表に示します。

表9-42　データベース接続で使用できるJ2EEコンポーネントおよび機能（コネクションプールのクラスタ化機能）

項目 | Oracle10g（コネクションプールのクラスタ化機能を使用した場合）
J2EEコンポーネント | Servlet/JSP | ○
Stateless Session Bean | ○
Stateful Session Bean | ○
Entity Bean（BMP） | ○
Entity Bean（CMP1.1） | ×
Entity Bean（CMP2.0） | ×
Message-driven Bean | ×
使用できる機能 | コネクションプーリング | ○
コネクションプールのウォーミングアップ | ○
コネクションプールの情報表示（cjlistpoolコマンド） | ○
コネクションプールのクリア | ○
リソースへの接続テスト | ○
コネクションの障害検知 | ○
ステートメントプーリング | ○
ステートメントキャンセル | 　△※1
ステートメントsetQueryTimeoutメソッド | 　△※2
コネクションIDのPRFトレース出力 | ○
障害調査用SQLの出力 | ○

（凡例）　○：使用できる　　×：使用できない　　△：一部制限あり

注※1

接続形式がMTS接続のときに使用できます。専用接続では使用できません。

注※2

MTS接続は有効に働きますが，専用接続には制限があります。詳細はオラクルのサポートサービスにお問い合わせください。

注意

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

(4)　使用できるリソース接続とトランザクション管理の機能

ルートリソースアダプタ，およびメンバリソースアダプタで使用できる機能については，「9.2.4　リソースアダプタの機能」を参照してください。

9.12.2　クラスタコネクションプールの動作

コネクションプールをクラスタ化した場合に使用できる機能と動作について説明します。クラスタコネクションプールでは次の機能を実行できます。

コネクションプールの一時停止

コネクションプールの再開

また，コネクションプールの状態，およびコネクションの取得要求を受けたときの，コネクションプールの選択方式についても説明します。

＜この項の構成＞

(1)　コネクションプールの一時停止

(2)　コネクションプールの再開

(3)　コネクションプールの状態

(4)　コネクションプールの選択方式

(1)　コネクションプールの一時停止

メンバコネクションプールを閉塞および一時停止できます。一時停止を実行すると，メンバコネクションプールが閉塞し一時停止します。

J2EEアプリケーションがルートリソースアダプタにコネクション取得要求をした場合，閉塞または一時停止したメンバコネクションプールにはコネクション取得要求は出されません。

次の場合にメンバコネクションプールを一時停止してください。

データベースノードに障害が発生した場合

データベースノードのメンテナンスをする場合

なお，一時停止の方法には次の2とおりがあります。

自動一時停止

手動一時停止

参考

一時停止処理では，J2EEアプリケーションで使用し終わったコネクションを破棄し，コネクションプール内のすべてのコネクションを破棄してから，コネクションプールを一時停止します。ネットワーク障害やデータベースノード障害が発生した場合，ネットワークのタイムアウトまで待ってからコネクションを破棄するため，閉塞してから一時停止するまでに時間が掛かることがあります。

(a)　自動一時停止

データベースノードの障害時にメンバコネクションプールを自動で一時停止できます。障害を検知すると，メンバコネクションプールは自動的に閉塞状態になり，そのあと一時停止します。

コネクションの取得時に次の現象が発生した場合，データベースノードに障害が発生したと判断し，メンバコネクションプールが自動的に一時停止します。

コネクション取得時のコネクションの障害検知がタイムアウトした場合

物理コネクションの取得に失敗した場合

物理コネクションの取得がタイムアウトした場合

コネクション管理スレッドが枯渇した場合

この機能は，デフォルトで有効となっています。有効/無効の設定は，ルートリソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のリソースアダプタのプロパティ定義についての説明を参照してください。

(b)　手動一時停止

データベースノードのメンテナンスをする場合などに，cjsuspendpoolコマンドを実行することで，コネクションプールを手動で一時停止できます。手動一時停止は，メンバコネクションプールが開始状態，開始予約状態，自動一時停止状態，および自動一時停止予約状態の場合に実行できます。メンバコネクションプールが自動一時停止状態の場合にcjsuspendpoolコマンドを実行すると，手動一時停止状態になります。これによって，自動一時停止後に自動再開させない運用ができます。

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

注意

cjsuspendpoolコマンドで手動一時停止したコネクションプールは，自動で再開されません。手動で再開してください。

(2)　コネクションプールの再開

一時停止したメンバコネクションプールを再開できます。J2EEアプリケーションからルートリソースアダプタにコネクション取得要求をした時に，再開したメンバコネクションプールには再びコネクションの取得要求が出されるようになります。

なお，コネクションプールを再開するには，未使用のコネクション管理スレッドの個数が，コネクションプールのコネクション数の最大数以上必要です。

次の場合にコネクションプールを再開してください。

データベースノードの障害が回復した場合

データベースノードのメンテナンスが終了した場合

再開の方法には次の2とおりがあります。

自動再開

手動再開

参考

コネクションプールが停止されている場合に，未使用のコネクション管理スレッドの個数がコネクションプールのコネクション数の最大数になると，メッセージが出力されます。cjresumepoolコマンドの実行に失敗した場合は，出力されたメッセージを確認してから再度コマンドを実行してください。

コネクションプールのウォーミングアップ機能が有効な場合には，コネクションプールの設定で定義した最小値までコネクションをプールしてから，メンバコネクションプールを開始します。コネクションをプーリングしているときにコネクションの生成に失敗した場合は，メンバコネクションプールは一時停止状態に戻ります。また，コネクションプールのウォーミングアップ機能が無効な場合は，すぐに開始状態になります。

(a)　自動再開

自動一時停止したメンバコネクションプールを自動で再開できます。

自動一時停止したメンバコネクションプールでは，データベースノードの状態をチェックするために，一定間隔で物理コネクションの取得要求を出します。このとき，コネクションの取得に成功すると，データベースノードが回復したと判断し，自動的に再開処理が行われます。また，自動一時停止したメンバコネクションプールを自動再開させない運用にするには，自動一時停止後に手動一時停止してください。再開時には，手動再開してください。

なお，ルートリソースアダプタが停止状態の場合，自動再開処理は行われません。ただし，メンバコネクションプールが自動再開中状態の場合にルートリソースアダプタを停止したときは，実行中の自動再開処理が継続されます。

この機能は，デフォルトで有効となっています。有効/無効の切り替えや，データベースノードの状態をチェックする間隔の設定は，ルートリソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のリソースアダプタのプロパティ定義についての説明を参照してください。

(b)　手動再開

自動一時停止または手動一時停止したコネクションプールを手動で再開できます。手動再開するには，cjresumepoolコマンドを使用します。手動再開は，コネクションプールが次の状態の場合に実行できます。

自動一時停止状態

手動一時停止状態

自動一時停止予約状態

手動一時停止予約状態

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

(3)　コネクションプールの状態

コネクションプールの状態は，メンバコネクションプールの場合だけ存在するものです。なお，コネクションプールの状態は，J2EEサーバやリソースアダプタの再起動後も維持されます。

メンバコネクションプールの状態には，次の種類があります。メンバコネクションプールの状態の詳細，およびコネクションプールの一時停止や再開をした場合の状態遷移については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

開始状態

開始予約状態

自動再開中状態

手動再開中状態

自動閉塞状態

手動閉塞状態

自動一時停止状態

自動一時停止予約状態

手動一時停止状態

手動一時停止予約状態

メンバコネクションプールの状態は次の方法で確認できます。手動一時停止または手動再開をする場合は，コマンドを実行する前にコネクションプールの状態を確認してください。

cjlistrarコマンド
cjlistrarコマンドは，デプロイされているすべてのリソースアダプタについて，リソースアダプタ名とリソースアダプタの状態を標準出力に出力します。-clusterpoolを指定した場合には，メンバコネクションプールの状態も表示できます。

cjlistpoolコマンド
cjlistpoolコマンドは，コネクションプールの情報を表示するコマンドです。メンバリソースアダプタの場合は，メンバコネクションプールの状態も表示できます。メンバリソースアダプタのコネクション情報の表示例については，「9.11.4　コネクションプールの情報表示」を参照してください。

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

(4)　コネクションプールの選択方式

J2EEアプリケーションがルートリソースアダプタにコネクションの取得要求を出した時に，メンバコネクションプールが一つ選択されます。このときメンバコネクションプールが選択される方式は，ラウンドロビン方式です。

選択対象のコネクションプールは，開始状態のメンバコネクションプールです。コネクションに空きがあるメンバコネクションプールが優先的に選択されます。

ただし，コネクション枯渇状態のメンバコネクションプールしかない場合は，コネクション取得要求が待ち状態になります。さらに，コネクション取得待ちのタイムアウトが発生すると，コネクションの取得に失敗します。また，コネクション取得要求が待ち状態の場合にコネクションプールが閉塞されたときは，コネクション取得要求が再開され，次の優先度のメンバコネクションプールからコネクションの取得を試みます。すべてのメンバコネクションプールからコネクションが取得できない場合には，コネクションの取得に失敗します。

なお，各メンバコネクションプールの最大サイズを設定する場合，次の指針に従って設定します。

メンバコネクションプールの最大サイズ（数）＝システムで許容される最大同時接続数÷データベースノードの数

9.12.3　使用するリソースアダプタ

ルートリソースアダプタおよびメンバリソースアダプタで実行できるコマンド，設定の概要，および注意事項について説明します。

＜この項の構成＞

(1)　実行できるコマンド

(2)　DB Connectorの設定

(3)　ルートリソースアダプタについての注意事項

(4)　メンバリソースアダプタについての注意事項

(1)　実行できるコマンド

ルートリソースアダプタおよびメンバリソースアダプタごとの，コマンドの実行可否を次の表に示します。なお，これ以外のコマンドについてはどちらのリソースアダプタでも実行できます。

表9-43　ルートリソースアダプタおよびメンバリソースアダプタのコマンドの実行可否

コマンド | リソースアダプタの種類
ルートリソースアダプタ | メンバリソースアダプタ
cjstartrar | ○ | ○
cjstoprar | ○ | ○
cjtestres | ○ | ○
cjlistrar | ○ | ○
cjclearpool | × | ○
cjlistpool | × | ○
cjsuspendpool | × | ○
cjresumepool | × | ○

（凡例）　○：実行できる　　×：実行できない

(2)　DB Connectorの設定

ルートリソースアダプタおよびメンバリソースアダプタのDB Connectorで設定する項目を次の表に示します。

表9-44　ルートリソースアダプタおよびメンバリソースアダプタのDB Connectorで設定する項目

設定項目 | リソースアダプタの種類
ルートリソースアダプタ | メンバリソースアダプタ
トランザクションサポートレベル | × | 　○※1
ログ取得の可否 | ○ | ○
データベース接続情報 | － | ○
DB Connector固有の設定（ステートメントプールなど） | － | ○
セキュリティ情報（ユーザ名，パスワード） | × | 　○※2
コネクションプールサイズ | × | ○
クラスタコネクションプール固有の設定 | ○ | －

（凡例）○：設定が必要　×：設定は不要　－：設定項目がない

注※1　一つのクラスタコネクションプールを構成するメンバリソースアダプタのトランザクションサポートレベルは，すべて同じにする必要があります。

注※2　一つのクラスタコネクションプールを構成するメンバリソースアダプタのユーザ名は，すべて同じにする必要があります。

DB Connectorの設定の詳細については，マニュアル「Cosminexus　リファレンス　定義編」，またはマニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

(3)　ルートリソースアダプタについての注意事項

cjclearpoolコマンドは実行できません。実行した場合は，メッセージが出力され，コマンドが異常終了します。クラスタコネクションプール内のコネクションをcjclearpoolコマンドでクリアする場合は，メンバリソースアダプタに対してコマンドを実行してください。

cjlistpoolコマンドは実行できません。実行した場合は，メッセージが出力され，コマンドが異常終了します。クラスタコネクションプール内のコネクションプールの情報を表示する場合は，cjlistpoolコマンドの-resnameにメンバリソースアダプタの表示名を指定するか，-resallを指定して実行してください。

一つのクラスタコネクションプール内で，コンテナ管理でのサインオンとコンポーネント管理でのサインオンを混在して使用できません。コンポーネント管理でのサインオンを使用する場合は，ルートリソースアダプタに属するすべてのメンバリソースアダプタのユーザ名を空白にしてください。

ルートリソースアダプタは，ルートリソースアダプタに属するすべてのメンバリソースアダプタが開始状態の場合に開始できます。これ以外の場合に，ルートリソースアダプタを開始すると，コンソールまたは画面にエラーメッセージが出力され，リソースアダプタの開始に失敗します。

(4)　メンバリソースアダプタについての注意事項

メンバリソースアダプタでは，次の機能が前提となります。これらの機能は，デフォルトで有効となり，無効にすることはできません。

コネクションプーリング
コネクションプールの最大値に0より大きい値を設定してください。0以下の値を設定した場合，コネクションプールの最大値と最小値にデフォルト値が指定されたものとして動作します。

コネクション取得時のコネクションの障害検知
コネクション取得時のコネクションの障害検知およびコネクション障害検知のタイムアウトは，設定値に関係なく有効となります。

コネクション枯渇時のコネクション取得待ち
コネクション枯渇時のコネクション取得待ちは，設定値に関係なく有効となります。

loginTimeout
loginTimeoutのプロパティに0よりも大きい値を設定してください。0以下の値を設定した場合はデフォルト値が指定されたものとして動作します。

メンバリソースアダプタでは，次の機能を使用できません。これらの機能は，デフォルトで無効となり，有効にすることはできません。

コネクションの取得リトライ

J2EEリソースのユーザ指定名前空間

メンバコネクションプール内のコネクションは，すべて同じデータベースノードに接続している必要があるため，データベースで接続先を変更する機能は使用しないでください。次にその機能の例を挙げます。なお，各機能を無効にする設定については，オラクルのマニュアルを参照してください。

クライアント・ロード・バランシング機能

接続時フェイルオーバー機能

データベースサービス

リスナによる負荷分散機能

メンバリソースアダプタにアクセスするときは，必ずルートリソースアダプタを経由します。そのため，次の個所には設定できません。

J2EEアプリケーションのリソースリファレンス

CMP Entity Beanのマッピング定義

メンバリソースアダプタは，所属するルートリソースアダプタが停止状態の場合に停止できます。開始状態のときに，メンバリソースアダプタを停止すると，コンソールまたは画面にエラーメッセージが出力され，リソースアダプタの停止に失敗します。

9.13　そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合）

この節では，「9.10　パフォーマンスチューニングのための機能」，「9.11　フォールトトレランスのための機能」，および「9.12　コネクションプールのクラスタ化」で説明した機能以外のリソースアダプタの機能について説明します。

次の機能を使用できます。

リソースアダプタのライフサイクル管理

リソースアダプタのワーク管理

メッセージインフロー

管理対象オブジェクトのルックアップ

コネクション定義の複数指定

これらの機能は，Connector 1.5仕様に準拠したリソースアダプタで使用できます。Application Serverで使用できるConnector 1.5仕様に準拠したリソースアダプタについては，「9.2.2(2)　Connector 1.5仕様に準拠したリソースアダプタ」を参照してください。

参考

Connector 1.5仕様に準拠したリソースアダプタなど，「9.2.2(1)　Connector 1.0仕様に準拠したリソースアダプタ」で示したリソースアダプタ以外のリソースアダプタを使用する場合には，リソースアダプタの処理の入り口と出口で，トレースを出力することをお勧めします。出力したトレースは，障害が発生したときの要因を切り分けるために使用します。

＜この節の構成＞

9.13.1　リソースアダプタのライフサイクル管理

9.13.2　リソースアダプタのワーク管理

9.13.3　メッセージインフロー

9.13.4　管理対象オブジェクトのルックアップ

9.13.5　コネクション定義の複数指定

9.13.6　Application Server独自のConnector 1.5 API仕様

9.13.7　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の注意事項

9.13.1　リソースアダプタのライフサイクル管理

Connector 1.5仕様に準拠したリソースアダプタを利用する場合，J2EEサーバによってリソースアダプタのライフサイクルを管理できます。

リソースアダプタのライフサイクル管理とは，リソースアダプタの開始処理と停止処理を，J2EEサーバで管理する機能です。

＜この項の構成＞

(1)　前提条件

(2)　ライフサイクル管理に使用するクラス

(3)　ライフサイクル管理の制御

(4)　ライフサイクル管理機能を使用するときの注意

(1)　前提条件

リソースアダプタのライフサイクル管理は，リソースアダプタが次の条件を満たす場合に有効になります。

リソースアダプタに，「(2)　ライフサイクル管理に使用するクラス」で示すクラスが実装されている。

DD（ra.xml）の<connector>-<resourceadapter>-<resourceadapter-class>に，javax.resource.spi.ResourceAdapterインタフェースを実装したJavaBeansのクラス名を指定している。

なお，DDの<connector>-<resourceadapter>-<resourceadapter-class>の指定が省略されている場合，リソースアダプタのライフサイクル管理は実行されません。

(2)　ライフサイクル管理に使用するクラス

リソースアダプタのライフサイクル管理に使用するクラスについて説明します。使用するクラスには，リソースアダプタでの実装が必要なクラスと，J2EEサーバが提供するクラスがあります。

●リソースアダプタで実装が必要なクラス

リソースアダプタでは，次のクラスの実装が必要です。なお，これらのクラスはJavaBeanとして実装することが，Connector 1.5仕様で規定されています。

javax.resource.spi.ResourceAdapterインタフェースの実装クラス

javax.resource.spi.ManagedConnectionFactoryインタフェースの実装クラス

AdminObject（管理対象オブジェクト）の実装クラス

詳細な実装については，Connector 1.5仕様を参照してください。

●J2EEサーバが提供するクラス

J2EEサーバは，次のクラスを提供します。

javax.resource.spi.work.WorkManagerインタフェースの実装クラス
このクラスには，doWork(Work)メソッド，scheduleWork(Work)メソッド，startWork(Work)メソッドなどが実装されています。

javax.resource.spi.BootstrapContextインタフェースの実装クラス
このクラスには，createTimer()メソッド，getWorkManager()メソッド，およびgetXATerminator()メソッドが実装されています。
なお，Application Serverでは，BootstrapContextインタフェースのgetXATerminatorメソッドを呼び出した場合，nullが返却されるように実装されています。

(3)　ライフサイクル管理の制御

ここでは，ライフサイクル管理の対象になる，リソースアダプタの開始処理と停止処理の制御について説明します。

リソースアダプタの開始処理および停止処理は，次にタイミングで実行されます。

J2EEリソースアダプタを開始または停止したとき（cjstartrarコマンドまたはcjstoprarコマンドを実行したとき）

J2EEサーバを起動または停止したとき（cjstartsvコマンドまたはcjstopsvコマンドを実行したとき）

リソースアダプタを含むアプリケーションを開始または停止したとき（cjstartappコマンドまたはcjstopappコマンドを実行したとき）

●リソースアダプタの開始処理を実行した場合の制御

リソースアダプタの開始処理を実行した場合の制御の流れを次の図に示します。

図9-25　リソースアダプタの開始処理を実行した場合の制御の流れ

リソースアダプタの開始処理によって実行される制御について説明します。なお，項番は図中の数字と対応しています。

WorkManager（javax.resource.spi.work.WorkManagerインタフェースの実装クラス）が生成されます。

BootstrapContext（javax.resource.spi.BootstrapContextインタフェースの実装クラス）が生成されます。

ResourceAdapterJavaBean（javax.resource.spi.ResourceAdapterインタフェースの実装クラス）が生成されます。
ResourceAdapterJavaBeanとして生成される実装クラスは，リソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<resourceadapter-class>に指定したクラスです。
このタグで指定したクラスのインスタンス化に失敗した場合，リソースアダプタの開始が失敗します※。このとき，KDJE48589-Eのメッセージが出力されます。

ResourceAdapterJavaBeanにプロパティが設定されます。
DD（ra.xml）の<connector>-<resourceadapter>-<config-property>に指定した値は，3.で生成されたResourceAdapterJavaBeanに設定されます。設定は，JavaBeanの仕様に従い，setterメソッドで実行されます。setterメソッドの呼び出しで例外が発生した場合は，KDJE48594-Wのメッセージが出力されます。ただし，処理は継続されます。

javax.resource.spi.ResourceAdapterインタフェースのstartメソッドが呼び出され，リソースアダプタが開始されます。
このメソッドの呼び出しによって例外がスローされた場合は，リソースアダプタの開始が失敗します※。このとき，KDJE48590-Eのメッセージが出力されます。

ResourceAdapterJavaBeanとManagedConnectionFactoryJavaBeanが関連づけられます（Outboundの場合）。
ライフサイクル管理機能を使用する場合，javax.resource.spi.ManagedConnectionFactoryインタフェースの実装クラスはjavax.resource.spi.ResourceAdapterAssociationインタフェースを実装しています。ResourceAdapterJavaBeanとManagedConnectionFactoryの関連づけは，javax.resource.spi.ResourceAdapterAssociationインタフェースのsetResourceAdapter(ResourceAdapter)メソッドで実行されます。
また，次の場合には，リソースアダプタの開始が失敗します※。このとき，KDJE48591-Eが出力されます。

ManagedConnectionFactoryJavaBeanがjavax.resource.spi.ResourceAdapterAssociationインタフェースを実装していなかった場合

setResourceAdapterメソッドの呼び出しに対して例外がスローされた場合

AdminObjectJavaBean（管理対象オブジェクト）が生成され，プロパティが設定されます。
AdminObjectJavaBeanとして生成される実装クラスは，リソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<adminobject>-<adminobject-class>に指定したクラスです。このタグで指定したクラスのインスタンス化に失敗した場合，リソースアダプタの開始が失敗します※。このとき，KDJE48597-Eのメッセージが出力されます。
また，DD（ra.xml）の<connector>-<resourceadapter>-<adminobject>-<config-property>で指定した値が，AdminObjectJavaBeanに設定されます。設定は，JavaBeanの仕様に従い，setterメソッドで実行されます。AdminObjectJavaBeanのsetterメソッドの呼び出しで例外が発生した場合は，KDJE48598-Wのメッセージが出力されます。ただし，処理は継続されます。

注※

アプリケーションに含まれるリソースアダプタの場合，リソースアダプタの開始が失敗したときには，そのリソースアダプタを含むアプリケーションの開始処理も失敗します。

●リソースアダプタの停止処理を実行した場合の制御

リソースアダプタの停止処理を実行した場合の制御を次の図に示します。

図9-26　リソースアダプタの停止処理を実行した場合の制御

リソースアダプタの停止処理によって実行される制御について説明します。なお，項番は図中の数字と対応しています。

停止するリソースアダプタを参照しているEJB，サーブレット，Message-driven Beanがすべて停止していることが確認されます。
次の要素が使用されていないことが確認されます。

Inboundリソースアダプタ

コネクションファクトリ

管理対象オブジェクト

これらが使用されていた場合は，リソースアダプタの停止処理が中止されます。

AdminObjectJavaBean（管理対象オブジェクト）が破棄されます。

javax.resource.spi.ResourceAdapterインタフェースのstopメソッドが呼び出され，リソースアダプタが停止します。
このメソッドの呼び出しによって例外がスローされた場合は，KDJE48590-Eのメッセージが出力されて，リソースアダプタの停止処理が失敗します。

ResourceAdapterJavaBeanが破棄されます。

●リソースアダプタの状態遷移

リソースアダプタは，リソースアダプタの開始処理または停止処理が実行されたタイミングで，「開始状態」または「停止状態」に遷移します。

リソースアダプタの状態遷移を次の図に示します。

図9-27　リソースアダプタの状態遷移

(4)　ライフサイクル管理機能を使用するときの注意

ライフサイクル管理機能を使用する場合は，次の点に注意してください。

J2EEサーバにデプロイされているリソースアダプタが複数ある場合，開始および停止処理が実行される順序は不定です。また，アプリケーションに含まれるリソースアダプタが複数ある場合，開始および停止処理が実行される順序は不定です。実行順序に依存する処理がある場合，動作は保証されません。

アプリケーションに含まれるリソースアダプタの場合，アプリケーション内に含まれるEJBやServletの開始処理よりも前に，リソースアダプタの開始処理が実行されます。また，アプリケーション内に含まれるEJBやServletの停止処理よりもあとで，リソースアダプタの停止処理が実行されます。

ResourceAdapter.stopの処理では，次に示す処理を適切に実行してください。

BootstrapContext.createTimerで生成したTimerの破棄(Timer#cancel)

WorkManagerに登録したWorkオブジェクトへの終了指示(Work#release)

9.13.2　リソースアダプタのワーク管理

Connector 1.5仕様に準拠したリソースアダプタを使用する場合，リソースアダプタが使用するスレッドをJ2EEサーバによって管理できます。

リソースアダプタのワーク管理とは，リソースアダプタがマルチスレッドで動作する場合に，スレッドを適切に使用するための機能です。J2EEサーバは，スレッドをプールに管理しておき，必要なリソースアダプタに割り当てます。

注意

ワーク管理の対象になるWorkを実行するスレッドは，J2EEアプリケーションの実行時間監視の対象にはなりません。

J2EEアプリケーションの実行時間監視については，「19.3　J2EEアプリケーション実行時間の監視とキャンセル」を参照してください。

＜この項の構成＞

(1)　前提条件

(2)　ワーク管理に使用するクラス

(3)　ワーク管理の流れ

(4)　スレッドプーリング

(5)　ワーク管理の開始処理と終了処理

(6)　ワーク管理機能を使用するときの注意

(1)　前提条件

リソースアダプタのワーク管理機能は，リソースアダプタのライフサイクルが管理されている場合に使用できます。リソースアダプタのライフサイクル管理については，「9.13.1　リソースアダプタのライフサイクル管理」を参照してください。

(2)　ワーク管理に使用するクラス

リソースアダプタのワークを管理する場合に使用するクラスについて説明します。使用するクラスには，リソースアダプタでの実装が必要なクラスと，J2EEサーバが提供するクラスがあります。なお，J2EEサーバが提供するクラスは，ライフサイクル管理で使用するクラスと同じです。「9.13.1(2)　ライフサイクル管理に使用するクラス」を参照してください。

●リソースアダプタで実装が必要なクラス

リソースアダプタでは，次のクラスの実装が必要です。

javax.resource.spi.work.Workインタフェースの実装クラス
このクラスのrunメソッドには，実行する処理を実装しておく必要があります。

なお，ワークの登録，ワークのスレッドへの割り当て，およびワークの終了のタイミングをリソースアダプタで管理したい場合は，javax.resource.spi.work.WorkListenerインタフェースの実装クラスも実装してください。

(3)　ワーク管理の流れ

ここでは，ワーク管理の処理の流れについて説明します。

ワーク管理の概要を次の図に示します。

図9-28　ワーク管理の概要

図で示した流れについて説明します。

Workの登録
リソースアダプタは，Work（javax.resource.spi.work.Workインタフェースの実装クラス）を生成して，WorkManagerに登録します。
このとき，WorkManagerのインスタンスは，BootstarpContext経由でリソースアダプタに渡されます。WorkManagerについては，「9.13.1　リソースアダプタのライフサイクル管理」を参照してください。
また，Workの登録と同時に，WorkManagerにWorkListener（javax.resource.spi.work.WorkListener）も登録すると，以降，Workの登録が完了したとき（1.が実行されたとき），Workにスレッドが割り当てられたとき（2.が実行されたとき），およびWorkの処理が完了したとき（3.が実行されたとき）に，それぞれイベント(javax.resource.spi.work.WorkEventインタフェースの実装クラス)を取得できます。

空きスレッドへのワークの割り当て
J2EEサーバは，WorkManagerに登録されたWorkに対して，空きスレッドを割り当てて，Workで実装されているrunメソッドを実行します。

Workの終了とスレッドの回収
J2EEサーバは，処理が完了したWorkに割り当てたスレッドを，スレッドプールに回収します。
回収されたスレッドは，スレッドプーリングでの設定に従って，プールに戻って待機状態になるか，解放されます。

なお，この流れの中で，javax.resource.spi.work.Workインタフェースまたはjavax.resource.spi.work.WorkListenerインタフェースのメソッドで例外が発生した場合は，それぞれKDJE48592-EまたはKDJE48593-Eのメッセージが出力されます。

WorkManagerに登録されたWorkの状態遷移を，次の図に示します。

図9-29　Workの状態遷移

なお，WorkManagerにWorkを登録する時に使用するメソッドによって，メソッドがリターンするタイミングが異なります。それぞれのメソッドがリターンするタイミングを次の表および図に示します。なお，リターンするタイミング以外，これらのメソッドの処理に違いはありません。

表9-45　メソッドがリターンするタイミング

メソッド | リターンするタイミング
scheduleWork | Workを登録して，すぐにリターンします。
startWork | Workにスレッドが割り当てられたタイミングでリターンします。
doWork | Workの処理が完了したタイミングでリターンします。

図9-30　scheduleWorkメソッドがリターンするタイミング

図9-31　startWorkメソッドがリターンするタイミング

図9-32　doWorkメソッドがリターンするタイミング

(4)　スレッドプーリング

スレッドプーリングは，ワークに割り当てるスレッドを，スレッドプールで管理する機能です。

●スレッドプーリングの設定

スレッドプーリングの設定は，リソースアダプタをJ2EEサーバにインポートしたあとで，Connector属性ファイルの<hitachi-connector-property>-<resourceadapter-runtime>-<property>タグに指定して，リソースアダプタごとのプロパティとして設定します。設定手順については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のリソースアダプタのプロパティ定義の説明を参照してください。

スレッドプールに設定できる値を次の表に示します。

表9-46　スレッドプールに設定できる値

設定できる値（プロパティ名）
説明

同時に実行される最大のスレッド数（MaxTPoolSize）
WorkManagerで同時に実行される最大のスレッド数を設定します。
Workが登録されたときに空きスレッドがない場合，WorkManagerで実行中のスレッドの数がこの値未満であれば，新規にスレッドが生成されて，Workに割り当てられます。
実行中のスレッドの数がこの値以上のときには，Workの受け付けは拒否されて，javax.resource.spi.work.WorkRejectedExceptionがスローされます。

スレッドプールの最小スレッド数（MinTPoolSize）
スレッドプールにプールする最小スレッド数を設定します。
WorkManagerにWorkがまったく登録されていない場合でも，この値分のスレッドは常にプールされます。
また，この値に0を指定した場合は，Workが登録されるまで，スレッドは生成されません。

Workが割り当たっていないスレッドが解放されるまでの最大生存期間［単位：秒］（TPoolKeepalive）
Workが割り当てられていないスレッドが，スレッドプールから解放されるまでの期間を秒単位で設定します。
空きスレッドになってからTpoolKeepalive秒経過してもWorkが割り当てられなかった場合，そのスレッドは解放されます。
ただし，スレッドプールに存在するスレッド数がMinTPoolSizeの値分しかない場合は，解放されません。

指定方法および指定できる値の詳細については，マニュアル「Cosminexus　リファレンス　定義編」のConnector属性ファイルの説明を参照してください。

なお，ライフサイクル管理機能が有効でない場合（リソースアダプタのDD（ra.xml）に<resourceadapter-class>が指定されていない場合），スレッドプーリングを設定するプロパティの値は無視されます。

●ワーク管理で使用するスレッドのライフサイクル

ワーク管理機能で使用するスレッドのライフサイクルを次に図に示します。

スレッドのライフサイクルは，スレッドプールと実行中スレッドの状態によって異なります。

図9-33　スレッドのライフサイクル（スレッドプールに空きスレッドがなく，実行中のスレッド数がMaxTPoolSize未満の場合）

図9-34　スレッドのライフサイクル（スレッドプールに空きスレッドがある場合）

図9-35　スレッドのライフサイクル（スレッドプールに空きスレッドがなく，実行中のスレッド数がMaxTPoolSizeに達している場合）

スレッドが生成されるのは，リソースアダプタによってscheduleWorkメソッド，startWorkメソッドまたはdoWorkメソッドが呼び出された場合に，次の状態の両方に当てはまるときです。

スレッドプールに空きスレッドがない。

WorkManagerで実行中のスレッド数がMaxTPoolSize未満である。

スレッドは，Workの処理が完了するとスレッドプールで実行待ち状態になります。次のWorkが登録されると，再度実行状態になります。

スレッドプール内で，TPoolKeepaliveで指定した秒数が経過してもWorkが割り当てられなかった場合，スレッドは解放されます。ただし，そのスレッドを解放することでスレッドプール内のスレッド数がMinTPoolSize未満になる場合は，解放されません。

●Message-driven Beanのインスタンスプールとスレッドプーリングとの関係

リソースアダプタがWorkを使用してMessage-driven Beanを呼び出す場合の動作は，Message-driven Beanのインスタンスプールの最大数と，リソースアダプタのMaxTPoolSizeの関係によって異なります。

Message-driven Beanのインスタンスプールの最大数とリソースアダプタのMaxTPoolSizeの関係ごとの動作を次の表に示します。これは，一つのリソースアダプタから一つのMessage-driven Beanを呼び出す場合の動作です。

表9-47　リソースアダプタがWorkによってMessage-driven Beanを呼び出すときの動作

Message-driven Beanのインスタンスプールの最大数とリソースアダプタのMaxTPoolSizeの関係
動作

MaxTPoolSize>Message-driven Beanのインスタンスプールの最大数
Message-driven Beanのインスタンスプールの最大数に達するまで，WorkからMessage-driven Beanを実行できます。
Message-driven Beanのインスタンスプールの最大数を超える数のWorkは，Message-driven Beanのインスタンスの取得待ちの状態になります。

MaxTPoolSize=Message-driven Beanのインスタンスプールの最大数
Message-driven Beanのインスタンスプールの最大数に達するまで，WorkからMessage-driven Beanを実行できます。
Message-driven Beanのインスタンスプールの最大数を超える数のWorkに対しては，javax.resource.spi.work.WorkRejectedException例外がスローされます。インスタンスの取得待ちにはなりません。

MaxTPoolSize<Message-driven Beanのインスタンスプールの最大数
同時に使用できるMessage-driven Beanのインスタンス数は，MaxTPoolSizeの数になります。実行中のWorkの数がMaxTPoolSizeに達するまで，WorkからMessage-driven Beanを実行できます。
MaxTPoolSizeを超える数のWorkに対しては，javax.resource.spi.work.WorkRejectedException例外がスローされます。実行待ちにはなりません。

ポイント

ワーク管理機能のスレッドプーリングはリソースアダプタ単位に設定します。一方，Message-driven BeanのインスタンスプールはMessage-driven Bean単位に設定します。

リソースアダプタが複数のMessage-driven Beanを呼び出す場合，リソースアダプタのMaxTPoolSizeには，それぞれのMessage-driven Beanで必要なスレッド数を考慮して，合計した値を設定してください。

(5)　ワーク管理の開始処理と終了処理

ワーク管理の開始処理および終了処理は，ライフサイクル管理機能の開始処理および終了処理のタイミングで実行されます。

それぞれの処理で実行されることを次に示します。

●開始処理

ワーク管理の開始処理では，スレッドプーリングの設定に応じて，スレッドの生成が実行されます。MinTPoolSizeが1以上に設定されている場合は，MinTPoolSize分のスレッドが生成されて，空きスレッドとしてスレッドプールに格納されます。

●終了処理

終了処理で実行される内容は，正常終了の場合と，異常終了または強制終了の場合とで一部異なります。なお，異常終了とは，ResourceAdapterインタフェースのstopメソッド実行時に例外がスローされる場合のことです。また，強制終了とは，cjstopapp -forceコマンドまたはcjstopapp -cancelコマンド実行の延長で実行される終了処理のことです。

参考

cjstopsv -fコマンドを実行した場合は，リソースアダプタの終了処理が実行されないでJ2EEサーバが停止されます。このため，ここで説明する処理は実行されません。

J2EEサーバからResourceAdapterインタフェースのstopメソッドが呼び出され，リソースアダプタに対して，停止処理が指示されます。
また，この処理の延長でWorkのreleaseメソッドが呼び出されて，Workが解放されます。

リソースアダプタによって，新規のWorkの受け付けが停止されます。
1.の処理を実行したあとなので，通常，Workの登録要求はありません。Workの登録要求があった場合，例外として，javax.resource.spi.work.WorkRejectedExceptionがスローされます。

Workの処理完了が待機されます。
実行中のWorkのrunメソッドの実行がすべて完了するまで待機されます。

ポイント

Workから呼び出しているMessage-driven Beanに対してメソッドキャンセルが実行されると，Message-driven Beanは強制終了します。ただし，その場合，実行中のWorkの処理は停止されません。

WorkからMessage-driven Beanを呼び出している場合，リソースアダプタよりも先にMessage-driven Beanが終了します。Message-driven Bean停止後にWorkからMessage-driven Beanを呼び出したり，javax.resource.spi.endpoint.MessageEndpointFactoryのcreateEndpointメソッドを呼び出したりすると，例外がスローされます。
詳細は，「9.13.3　メッセージインフロー」を参照してください。

(6)　ワーク管理機能を使用するときの注意

WorkおよびWorkListenerのメソッド内では，J2EEサーバの機能として，メッセージインフロー規約に基づくMessage-driven Beanの呼び出しだけが使用できます。

WorkおよびWorkListenerのメソッドは，スレッドセーフにしてください。

WorkListenerのメソッドには，実行スレッドに依存した処理を実装しないでください。実行スレッドに依存した処理がある場合，動作は保証されません。

9.13.3　メッセージインフロー

メッセージインフローは，リソースアダプタとMessage-driven Bean間の規約です。Connector 1.5仕様のリソースアダプタは，EISなどのメッセージプロバイダからのメッセージを受け付けて，アプリケーションサーバ上のメッセージエンドポイント（Message-driven Bean）を動作させることができます。メッセージエンドポイントでは，メッセージプロバイダから送信されたメッセージを，非同期に処理します。

＜この項の構成＞

(1)　前提条件

(2)　メッセージインフローの制御の流れ

(3)　メッセージエンドポイントのデプロイとアンデプロイ

(1)　前提条件

メッセージインフローは，リソースアダプタおよびMessage-driven Beanが次の条件を満たす場合に有効になります。

メッセージインフローで呼び出されるMessage-driven Beanは，EJB 2.1に準拠している必要があります。
EJB 2.1では，Message-driven Beanはjavax.jms.MessageListenerだけではなく，任意のメッセージリスナを実装できます。メッセージリスナは，リソースアダプタとMessage-driven Bean間のメッセージ配送に使用するリスナです。リソースアダプタがサポートしているメッセージリスナをMessage-driven Beanに実装することで，汎用的なメッセージ受信を実現できます。
EJB 2.0のMessage-driven Beanでメッセージインフローを実行しようとした場合，アプリケーション開始時にエラーになり，開始に失敗します。この場合は，KDJE42088-Eのメッセージが出力されます。

メッセージインフローを実行する場合，リソースアダプタおよびMessage-driven Beanの属性として，次の設定が必要です。

管理対象オブジェクトに設定する情報（リソースアダプタ）

Message-driven Beanとリソースアダプタの対応づけ（Message-driven Beanおよびリソースアダプタ）

ActivationSpecに設定する情報（Message-driven Bean）

Message-driven Beanが使用するインタフェース（Message-driven Beanおよびリソースアダプタ）

メッセージインフローの処理を実行する場合のリソースアダプタとJ2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　メッセージインフローの制御の流れ

メッセージインフローを使用する場合の制御の流れを次の図に示します。

図9-36　メッセージインフローを使用する場合の制御の流れ

メッセージインフローを使用した場合に実行される制御について説明します。なお，項番は図中の数字と対応しています。

アプリケーションの開始処理によって，リソースアダプタのActivationSpecJavaBeanにプロパティが設定されます。
Message-driven Beanの属性の<activation-config>に指定した内容が設定されます。

J2EEサーバからendpointActivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの開始が通知されます。

EISからメッセージが送信されます。

リソースアダプタからMessageEndpointFactoryに対して，createEndpointメッセージが呼び出されます。

MessageEndpointFactoryがエンドポイントのプロキシを生成します。

リソースアダプタからエンドポイントのプロキシに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

エンドポイントのプロキシからMessage-driven Beanに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

処理が完了したら，J2EEサーバからendpointDeactivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの停止が通知されます。

(3)　メッセージエンドポイントのデプロイとアンデプロイ

ここでは，メッセージエンドポイントのデプロイとアンデプロイで実行される処理について説明します。

●メッセージエンドポイントのデプロイ

メッセージエンドポイントのデプロイ時に実行される処理について説明します。メッセージエンドポイントのデプロイは，リソースアダプタが開始済みの状態で，Message-driven Beanを含むアプリケーションを開始したときに実行されます。

メッセージエンドポイントのデプロイ時の処理を次の図に示します。

図9-37　メッセージエンドポイントのデプロイ時の処理

メッセージエンドポイントのデプロイで実行される処理について説明します。項番は図中の番号に対応しています。

リソースアダプタが開始済みの状態で，Message-driven Beanを含むJ2EEアプリケーションを開始します。

J2EEサーバが，MessageEndpointFactoryを生成します。
MessageEndpointFactoryは，J2EEサーバが提供するjavax.resource.spi.endpoint.MessageEndpointFactoryのインスタンスです。javax.resource.spi.endpoint.MessageEndpointFactoryはリソースアダプタにエンドポイントのインスタンスを提供するファクトリクラスです。

J2EEサーバが，ActivationSpecを生成します。
ActivationSpecは，Message-driven Bean（エンドポイント）の開始に必要な情報を設定するJavaBeanです。

J2EEサーバが，ActivationSpecのプロパティを設定します。
ActivationSpecのプロパティに設定する情報は，Message-driven Beanを含むアプリケーションの属性として設定した情報です。

J2EEサーバが，javax.resource.spi.ResourceAdapter#endpointActivation(MessageEndpointFactory, ActivationSpec)メソッドを呼び出します。
このとき，引数として，生成・設定したMessageEndpointFactoryとActivationSpecのインスタンスが指定されます。なお，endpointActivationメソッドの呼び出しで例外が発生した場合は，KDJE43174-Eのメッセージが出力され，アプリケーションの開始が中止されます。

リソースアダプタは，5.のメソッドが呼び出されると，メッセージプロバイダからのメッセージ受信に対する準備をします。

●メッセージエンドポイントのアンデプロイ

メッセージエンドポイントのアンデプロイ時に実行される処理について説明します。メッセージエンドポイントのアンデプロイは，Message-driven Beanを含むアプリケーションを停止したときに実行されます。

メッセージエンドポイントのアンデプロイ時の処理を次の図に示します。

図9-38　メッセージエンドポイントのアンデプロイ時の処理

メッセージエンドポイントのアンデプロイで実行される処理について説明します。項番は図中の番号に対応しています。

Message-driven Beanを含むJ2EEアプリケーションを停止します。

J2EEサーバが，javax.resource.spi.ResourceAdapter#endpointDeactivation(MessageEndpointFactory, ActivationSpec)を呼び出します。
このとき，引数として，デプロイ時に指定したMessageEndpointFactoryとActivationSpecと同じインスタンスが指定されます。なお，このメソッドの呼び出しで例外が発生した場合，メッセージKDJE43175-Wが出力されます。ただし，例外が発生した場合も，アプリケーションの停止処理は続行されます。

リソースアダプタは，2.のメソッドが呼び出されると，メッセージプロバイダからのメッセージ受信終了の処理をします。

●メッセージ配送をするときのリソースアダプタの処理

ここでは，メッセージ配送をするときのリソースアダプタの処理について説明します。

リソースアダプタからのメッセージエンドポイント（Message-driven Bean）の呼び出しは，メッセージエンドポイントのプロキシを使用して実行されます。このプロキシは，リソースアダプタからjavax.resource.spi.endpoint.MessageEndpointFactoryのcreateEndpointメソッドを呼び出すことで得られます。

注意

アプリケーションの停止後にMessageEndpointFactoryのメソッドを呼び出すと，javax.resource.spi.UnavailableException例外がスローされます。このとき，メッセージKDJE43177-Eが出力されます。また，メッセージエンドポイントのメソッドを呼び出した場合は，java.lang.IllegalStateException例外がスローされます。このとき，メッセージKDJE43177-Eが出力されます。

9.13.4　管理対象オブジェクトのルックアップ

管理対象オブジェクト（AdminObject）をルックアップによって取得できます。管理対象オブジェクトは，J2EEアプリケーションの中からメッセージを送信したり，同期受信したりする場合に，メッセージの送信先の情報を得るために必要です。管理対象オブジェクトをルックアップするためには，リソースアダプタとJ2EEアプリケーションの設定が必要です。ここでは，設定の概要について説明します。

参考

管理対象オブジェクトの仕様は，リソースアダプタの仕様に依存します。詳細は，使用するリソースアダプタの仕様に従ってください。

＜この項の構成＞

(1)　ルックアップの対象にする管理対象オブジェクトの設定

(2)　J2EEアプリケーションの設定

(1)　ルックアップの対象にする管理対象オブジェクトの設定

ルックアップの対象にする管理対象オブジェクトの情報は，リソースアダプタのプロパティとして設定します。リソースアダプタのプロパティは，Connector属性ファイルで設定します。

管理対象オブジェクトをルックアップの対象にする場合は，<adminobject-name>タグに管理対象オブジェクト名を必ず指定してください。管理対象オブジェクト名は，管理対象オブジェクトがリソースアダプタごとに複数定義された場合に，管理対象オブジェクトを一意に識別するために使用されます。

設定項目については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタのプロパティ定義でできることの説明を参照してください。

(2)　J2EEアプリケーションの設定

管理対象オブジェクトをルックアップするJ2EEアプリケーションの設定は，属性ファイルまたはアノテーションで設定できます。

(a)　属性ファイルを使用する場合

<resource-env-ref>タグ下の次の要素を設定します。

<resource-env-ref-name>タグ下にルックアップで使用する名称を指定します。<resource-env-ref-type>タグ下に参照する管理対象オブジェクトの型を指定します。<linked-adminobject>タグ下にリソースアダプタの管理対象オブジェクトの名前，リソースアダプタの表示名を指定します。

注意

EJB 2.1で管理対象オブジェクトを参照するための要素として規定されている<message-destination-ref>タグは，Application Serverでは使用できません。

設定については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEアプリケーションのプロパティ定義で設定できることの説明を参照してください。

(b)　アノテーションを使用する場合

@ResourceのmappedName属性に，ルックアップする管理対象オブジェクト名を指定します。次の形式で指定します。リソースアダプタの表示名と管理対象オブジェクト名を区切る区切り文字には「!#」を使用します。

@Resource(mappedName="リソースアダプタの表示名!#管理対象オブジェクト名")

9.13.5　コネクション定義の複数指定

Connector 1.5仕様に準拠したリソースアダプタを使用する場合，一つのリソースアダプタに対して複数のコネクション定義を指定できます。コネクションプールやログ出力などについての設定は，コネクション定義ごとに設定できます。

リソースアダプタ内のコネクション定義の識別には，コネクション定義識別子を使用します。コネクション識別子は，DD内の<connectionfactory-interface>の指定値です。<connectionfactory-interface>の値は，リソースアダプタ内のコネクション定義ごとに一意の値を持っています。

なお，リソースアダプタに含まれるコネクション定義ごとのコネクション定義識別子については，次のサーバ管理コマンドに-outboundオプションを指定して実行すると確認できます。

cjlistappコマンド（アプリケーションに含まれるRARファイルの場合）

cjlistresコマンド

cjlistrarコマンド

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

ここでは，コネクション定義に指定できる要素と指定個所について説明します。また，コネクション定義を複数指定する場合に留意することについて説明します。

＜この項の構成＞

(1)　コネクション定義に指定できる要素と指定個所

(2)　コネクションプールを使用する場合の留意事項

(3)　トランザクションリカバリをする場合の留意事項

(4)　リソースへの接続テストをする場合の留意事項

(5)　稼働情報およびリソース枯渇監視情報を出力する場合の留意事項

(6)　リソースアダプタの稼働ログを出力する場合の留意事項

(7)　移行コマンドでの対応についての留意事項

(1)　コネクション定義に指定できる要素と指定個所

ここでは，コネクション定義に指定できる要素と指定個所について説明します。

●DDでの指定個所とコネクション定義に指定できる要素

コネクション定義は，Connector 1.5仕様に対応したDDの，<connection-definition>下に指定します。<connection-definition>の下に指定する要素を次に示します。

<managedconnectionfactory-class>

<config-property>

<connectionfactory-interface>

<connectionfactory-impl-class>

<connection-interface>

<connection-impl-class>

●Connector属性ファイルの階層構造とコネクション定義の対応

DD（ra.xml）の階層構造の変更に合わせて，属性ファイルにもコネクション定義に対応する階層が追加されます。

J2EEサーバにインポート済みのリソースアダプタの場合，リソースアダプタのプロパティの変更には，Connector属性ファイルを使用します。Connector属性ファイルに定義した値は，サーバ管理コマンドを使用してJ2EEサーバ上のリソースアダプタに反映します。属性ファイルによるプロパティの設定手順については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

なお，リソースアダプタの動作に関連するプロパティには，コネクション定義ごとに定義する項目と，リソースアダプタ全体に定義する項目があります。コネクション定義ごとに指定する項目については，Connector属性ファイルの<outbound-resourceadapter>-<connection-definition>下に指定します。リソースアダプタ全体に対して指定する項目については，<resourceadapter-runtime>-<property>下に指定します。

それぞれの項目の指定方法の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

●J2EEアプリケーションでのリンク解決の定義方法（<resource-ref>-<linked-to>，<cmp-map>-<datasource-name>またはmappedNameでの指定方法）

Connector 1.5仕様に準拠したリソースアダプタを参照するJ2EEアプリケーションでは，リンク解決のために，J2EEアプリケーションがどのコネクション定義を参照するかを定義する必要があります。

定義は，次のどれかの方法で指定します。

J2EEアプリケーションの属性ファイル（WAR属性ファイル，Session Bean属性ファイル，Entity Bean属性ファイルまたはMessageDrivenBean属性ファイル）の<resource-ref>-<linked-to>

J2EEアプリケーションの属性ファイル（Entity Bean属性ファイル）の<cmp-map>-<datasource-name>

アノテーション@ResourceのmappedName属性

注意

参照先のリソースがConnector 1.5仕様に準拠したリソースアダプタの場合は，必ずコネクション定義識別子を指定してください。指定を省略した場合，リンク解決に失敗します。また，参照先のリソースがConnector 1.0仕様に準拠したリソースアダプタの場合は，コネクション定義識別子を指定しないでください。指定した場合，リンク解決に失敗します。

コネクション定義識別子を含む参照先のリソースは，次の形式で指定します。

<リソースアダプタの表示名>!<コネクション定義識別子>

指定内容について説明します。

<リソースアダプタの表示名>

参照先のリソースアダプタのDD（ra.xml）の<connector>-<display-name>要素の値です。

<コネクション定義識別子>

参照先のリソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<outbound-resourceadapter>-<connection-definition>-<connectionfactory-interface>要素の値です。

なお，リソースアダプタの表示名およびコネクション定義識別子は，次のサーバ管理コマンドでも確認できます。

cjlistappコマンド（アプリケーションに含まれるRARファイルの場合）

cjlistresコマンド

cjlistrarコマンド

(2)　コネクションプールを使用する場合の留意事項

複数のコネクション定義が指定されているリソースアダプタでは，コネクションプールをコネクション定義単位で管理できます。コネクションプールについての定義は，Connector属性ファイルの<outbound-resourceadapter>-<connection-definition>-<connector-runtime>-<property>下の要素で指定して設定してください。

次に，コネクションプールが複数になる場合の留意事項について説明します。

●コネクションプールを対象にしたコマンドの実行

コネクションプールを対象にしたサーバ管理コマンドを実行するときには，どのコネクションプールを対象にするかを指定する必要があります。

次のコマンドを実行する場合には，コネクション定義識別子の指定が必要です。コネクション定義識別子は，これらのコマンドのオプションで指定します。

cjclearpoolコマンド

cjlistpoolコマンド

コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

参考

コネクションプールのクラスタ化で使用するコマンドについては，対象になりません。コネクションプールのクラスタ化で使用するコマンドは，Cosminexusが提供しているリソースアダプタだけで実行できます。

●コネクションプールのウォーミングアップ処理

コネクションプールのウォーミングアップ処理は，コネクション定義ごとに実行されます。

コネクションプールのウォーミングアップ処理が実行される場合に，特定のコネクション定義に対応するコネクションプールのウォーミングアップに失敗しても，それ以外のコネクションプールに対するウォーミングアップ処理は継続されます。

(3)　トランザクションリカバリをする場合の留意事項

トランザクションリカバリは，コネクション定義ごとに実行されます。このため，コネクション定義を複数指定した場合，OTSにはコネクション定義ごとにリソースが登録されます。

(4)　リソースへの接続テストをする場合の留意事項

リソースアダプタの接続テストを実行する場合，特定のコネクション定義に対する接続テストでエラーが発生した場合も，処理は中止されません。すべてのコネクション定義に対して接続テストが実行されます。ただし，どれかのコネクション定義でエラーが発生した場合，コマンドの戻り値は異常終了を示す戻り値になります。

(5)　稼働情報およびリソース枯渇監視情報を出力する場合の留意事項

コネクション定義が複数指定されている場合，稼働情報およびリソース枯渇監視情報は次のように出力されます。

稼働情報（稼働情報ファイルに出力される情報）

一つ目のコネクション定義についての情報だけが出力されます。一つ目のコネクション定義とは，DD（ra.xml）で最初に定義されているコネクション定義です。

稼働情報（運用管理コマンドを使用して出力する情報）

出力できません。Connector 1.5仕様に準拠したリソースアダプタについての稼働情報を出力しようとした場合，出力内容は保証されません。

リソース枯渇監視情報

リソースアダプタに指定されているすべてのコネクション定義の情報が出力されます。

(6)　リソースアダプタの稼働ログを出力する場合の留意事項

Connector 1.5仕様に準拠したリソースアダプタの稼働ログを出力する場合，出力ファイルのファイル名は，次の形式になります。

<リソースアダプタの表示名>_<コネクション定義の並び順>_<ログファイルの通番>.log

<コネクション定義の並び順>は，DD（ra.xml）内で，対応する<connection-definition>が出現した順番（1，2，...）に対応します。

(7)　移行コマンドでの対応についての留意事項

cjrarupdate（リソースアダプタのバージョンアップ）を実行しても，Connector 1.0仕様のリソースアダプタのDDは，Connector 1.5仕様のリソースアダプタのDDには書き換えられません。

9.13.6　Application Server独自のConnector 1.5 API仕様

ここでは，Connector 1.5で仕様のインタフェースに対して，Application Server独自で規定した仕様について説明します。

＜この項の構成＞

(1)　javax.resource.spi.endpoint.MessageEndpointFactoryインタフェース

(2)　javax.resource.spi.endpoint.MessageEndpointインタフェース

(3)　メッセージリスナのメソッド

(1)　javax.resource.spi.endpoint.MessageEndpointFactoryインタフェース

Cosminexusでは，二つのメソッドの仕様を規定しています。

(a)　createEndpointメソッド

形式

public MessageEndpoint createEndpoint(XAResource xaResource) throws UnavailableException

Application Server独自の仕様

引数xaResourceにXAResourceインスタンスを指定しても，無視されます。

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでこのメソッドが呼び出された場合は，javax.resource.spi.UnavailableExceptionがスローされます。

このメソッドの中でMessage-driven Beanのインタスタンス取得処理が実行されます。Message-driven Beanのインスタンスプールの上限に達していた場合は，Message-driven Beanのインスタンスを取得できるか，J2EEアプリケーションが停止するまで，メソッドがリターンされません。

例外

Application Serverで規定した例外の動作について示します。

例外
例外が発生するタイミング

javax.resource.spi.UnavailableException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでこのメソッドが呼び出した場合

Message-driven Beanのインスタンスの取得に失敗した場合

(b)　isDeliveryTransactedメソッド

形式

public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException

Application Server独自の仕様

Application ServerではConnector 1.5仕様のリソースアダプタに対してCMTをサポートしていません。このため，常にfalseが返却されます。

(2)　javax.resource.spi.endpoint.MessageEndpointインタフェース

Application Serverでは，三つのメソッドの仕様を規定しています。

(a)　beforeDeliveryメソッド

形式

public void beforeDelivery(Method method) throws NoSuchMethodException, ResourceException

Application Server独自の仕様

例外について規定しています。

例外

Application Serverで規定した例外の動作について示します。

例外
例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

javax.resource.spi.IllegalStateException

不正な順序で呼び出した場合（beforeDeliveryメソッド呼び出し後に再度beforeDeliveryメソッドを呼び出した場合。またはメッセージリスナのメソッドの呼び出し後にbeforeDeliveryメソッドを呼び出した場合）

javax.resource.spi.UnavailableException

予期しない例外が発生した場合

(b)　afterDeliveryメソッド

形式

public void afterDelivery() throws ResourceException

Application Server独自の仕様

例外について規定しています。

例外

Application Serverで規定した例外の動作について示します。

例外
例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

javax.resource.spi.IllegalStateException

不正な順序で呼び出した場合（Option B※のメッセージリスナのメソッド呼び出し後以外のタイミングでafterDelivery()を呼び出した場合）

javax.resource.spi.UnavailableException

予期しない例外が発生した場合

注※

Connector 1.5仕様に記述されているメッセージ配送オプションです。

(c)　releaseメソッド

形式

public void release()

Application Server独自の仕様

このメソッドを呼び出すと，エンドポイントに対応づけられたMessage-driven Beanのインスタンスが解放され，インスタンスプールに戻ります。

エンドポイントを使用し終わったら，必ずこのメソッドを呼び出して，Message-driven Beanをインスタンスプールに戻すように実装してください。

例外

Application Serverで規定した例外の動作について示します。

例外
例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

(3)　メッセージリスナのメソッド

インタフェースはメッセージリスナのインタフェースで定義されます。ここでは，Application Serverで規定した例外の動作について示します。

例外
例外が発生するタイミング

メッセージリスナのインタフェースに指定された例外

Message-driven Beanの実行時（システム例外が発生した時以外）

javax.ejb.EJBException

Message-driven Beanの実行時（システム例外が発生した時）

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

不正な順序で呼び出した場合（Option B※のメッセージ配送で，メッセージリスナのメソッドを呼び出したあと，続けてメッセージリスナのメソッドを呼び出した場合）

注※

Connector 1.5仕様に記述されているメッセージ配送オプションです。

9.13.7　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の注意事項

Connector 1.5仕様に準拠したリソースアダプタを使用する場合の注意事項について説明します。注意事項はリソースアダプタの使用方法によって異なります。

＜この項の構成＞

(1)　J2EEリソースアダプタとしてデプロイして使用する場合（J2EEアプリケーションに含めないで使用する場合）

(2)　J2EEアプリケーションに含めて使用する場合

(1)　J2EEリソースアダプタとしてデプロイして使用する場合（J2EEアプリケーションに含めないで使用する場合）

管理対象オブジェクトをアノテーションで指定する場合は，コンテナ拡張ライブラリに管理対象オブジェクトのインタフェースを追加する必要があります。

コンテナ拡張ライブラリについては，「10.　コンテナ拡張ライブラリ」を参照してください。

(2)　J2EEアプリケーションに含めて使用する場合

リロード機能を使用する場合は，次のクラス（インタフェース）をコンテナ拡張ライブラリに追加する必要があります。

javax.resource.spi.ActivationSpecインタフェースの実装クラス

リソースアダプタがサポートするメッセージリスナのインタフェース

管理対象オブジェクトをアノテーションで指定する場合は，コンテナ拡張ライブラリに管理対象オブジェクトのインタフェースを追加する必要があります。

コンテナ拡張ライブラリについては，「10.　コンテナ拡張ライブラリ」を参照してください。

9.14　リソースへの接続テスト

リソースアダプタのプロパティ設定後，設定した内容が正しいかどうか，検証することができます。これを接続テスト機能といいます。接続テストで検証される内容は，接続するリソースごとに異なります。リソースごとの接続テストでの検証内容を，次の表に示します。

なお，接続テストの実行手順や，リソースアダプタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

表9-48　接続テストでの検証内容

リソースの種類
接続方法
接続テストでの検証内容

データベース
DB Connector

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1※2

DB Connectorの設定が正しいこと

使用するJDBCドライバの設定が正しいこと

データベースとの接続を確立できること

SQL発行が成功すること

DB Connector（コネクションプールのクラスタ化機能を使用した場合のルートリソースアダプタ）

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1

DB Connectorの設定が正しいこと

ルートリソースアダプタの開始に必要な設定がされていること※3

DB Connector（コネクションプールのクラスタ化機能を使用した場合のメンバリソースアダプタ）

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1

DB Connectorの設定が正しいこと

Oracle JDBC Thin Driverの設定が正しいこと

データベースとの接続を確立できること

SQL発行が成功すること

メンバリソースアダプタの前提となる機能を使用していること※4

メンバリソースアダプタで使用できない機能を使用していないこと※4

データベース上のキュー
Cosminexus RM

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1

Cosminexus RMの設定が正しいこと

連携するDB Connector for Cosminexus RMが開始していること

連携するDB Connector for Cosminexus RMの設定が正しいこと

使用するデータベースとの接続を確立できること

DB Connector for Cosminexus RM

DB Connector for Cosminexus RMの設定が正しいこと

DB Connector for Cosminexus RMが開始していること

連携するCosminexus RMの設定が正しいこと

連携するCosminexus RMが開始していること

使用するJDBCドライバの設定が正しいこと

使用するデータベースとの接続を確立できること

SQL発行が成功すること

OpenTP1
TP1/Message Queue - Access

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1

TP1/Message Queue - Accessの設定が正しいこと

TP1/Message Queue - Accessが，TP1/Message Queueとの接続を確立できること

uCosminexus TP1 Connector

1.4モードであること

指定されたトランザクションサポートレベルが使用できること※1

uCosminexus TP1 Connectorの設定が正しいこと

SMTPサーバ
メールコンフィグレーション

SMTPサーバへの接続を確立できること

そのほか
日立製以外のリソースアダプタ

1.4モードであること

リソースへの接続を確立できること※5（javax.resource.spi.ManagedConnectionFactoryの実装クラスのcreateManagedConnectionメソッド呼び出しが成功することによって，リソースとの接続が確立できたものとします）。

Connector1.5に準拠したリソースアダプタの場合は，リソースアダプタを開始していないときに，開始と停止ができること（javax.resource.spi.ResourceAdapterの実装クラスのstartメソッドおよびstopメソッド呼出しが成功することによって，リソースアダプタを開始・停止できたものとします）。

注※1

リソースアダプタのトランザクションサポートレベルにグローバルトランザクション（XATransaction）が指定されている場合は，usrconf.propertiesのejbserver.distributedtx.XATransaction.enabledキーがtrueになっていれば使用できます。なお，トランザクションサポートレベルについては，「9.3.3　リソースごとに使用できるトランザクションの種類」を参照してください。

注※2

接続先のデータベースがXDM/RD E2のときは，グローバルトランザクション（XATransaction）は使用できません。トランザクションリカバリ用の物理コネクションの取得に失敗するため，DB Connectorの開始ができません。

注※3

ルートリソースアダプタの開始に必要な設定については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

注※4

メンバリソースアダプタの前提となる機能，および使用できない機能については，「9.12.3　使用するリソースアダプタ」を参照してください。

注※5

Outboundの通信をする場合にリソースとの接続に必要なコネクション定義がないときは，メッセージKDJE48606-Eが出力されてテストに失敗します。

9.15　ファイアウォール環境での運用のための機能

ファイアウォールをシステムに組み込んで運用する場合，通信に使用するポートを固定し，固定したポートを使用した通信だけを許可する必要があります。

参考

コネクションスイーパによる通信性能低下の回避

ファイアウォールには，一定時間以上無通信のセッションを強制切断する機能を持つものがあります。ファイアウォールがアプリケーションサーバとデータベースサーバの間に配置されていて，コネクションプールが有効の場合には，しばらくの間使用されなかったコネクションがファイアウォールによって切断されることがあります。その後の切断されたコネクションの使用は，長時間の待ちが発生します。この現象は，ファイアウォールの無通信切断時間よりも早い時間で未使用コネクションを破棄するようにコネクションスイーパ機能を設定することで回避できます。

＜この節の構成＞

9.15.1　トランザクションリカバリ用通信ポート

9.15.2　スマートエージェントが使用する通信ポート

9.15.1　トランザクションリカバリ用通信ポート

グローバルトランザクションを使用する場合，トランザクションリカバリ処理用の通信ポートを使用します。ファイアウォールをシステムに組み込んで運用する場合，ファイアウォールの構成によっては，このポートの通信を許可する必要があります。デフォルトではポート番号として20302が使用されますが，変更することもできます。

トランザクションリカバリ用通信ポートの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

9.15.2　スマートエージェントが使用する通信ポート

TPBrokerのスマートエージェント（OSAgent）は通信ポートを使用します。ファイアウォールをシステムに組み込んで運用する場合，ファイアウォールの構成によっては，このポートを使用する通信を許可する必要があります。

スマートエージェントが使用する通信ポートの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，J2EEサーバのプロパティに設定した通信ポートは，環境変数OSAGENT_PORTにも指定する必要があります。J2EEサーバのプロパティと，環境変数OSAGENT_PORTには，必ず，同じ値を設定してください。

9.16　リソースに接続するための実装

アプリケーションからリソースに接続するには，Enterprise Beanやサーブレットでリソースへの参照を取得する必要があります。リソースへの参照を取得する方法として，ルックアップを使用する方法とDI（Dependency Injection）を使用する方法があります。

ここでは，アプリケーションからリソースに接続する手順と，リソースへのサインオン方式について説明します。

＜この節の構成＞

9.16.1　アプリケーションからリソースに接続する手順

9.16.2　リソースへのサインオン方式

9.16.1　アプリケーションからリソースに接続する手順

ルックアップを使用する場合，次の手順でアプリケーションからリソースに接続します。

リソースに接続するコネクションを取得するためのファクトリクラスを，JNDIを使用してルックアップします。
ルックアップする名前は，Enterprise BeanやサーブレットのDDで指定します。該当するタグは<resource-ref>タグ中の<res-ref-name>タグです。

コネクションのファクトリクラスを使用して，コネクションを取得します。

取得したコネクションを使用して，リソースに接続します。

使用済みのコネクションをクローズします。

コネクションプーリングを使用している場合は，手順2.でプーリングされているコネクションが取得され，手順4.でコネクションがプールに返却されます。ユーザプログラムでコネクションプーリングを意識したコーディングは必要ありません。

DIを使用してリソースへの参照を取得する場合，DDの定義は不要となります。DIの概要およびDI使用時の注意事項については，「5.2.5　DIの使用」を参照してください。

注意

ユーザプログラムでリソースへのコネクションを取得した場合，使用後には必ずクローズしてください。具体的には，例外などが発生した場合にも必ずクローズするように，finally節でコネクションをクローズしてください。

なお，finalizeメソッドが呼ばれるタイミングはJavaVMのガーベージコレクションのタイミングに依存するので，finalizeメソッドでコネクションをクローズする設計にはしないでください。ユーザプログラムでコネクションが正しくクローズされない場合，取得できるコネクションの最大数に達してしまい，それ以上のコネクションが取得できなくなるおそれがあります。

9.16.2　リソースへのサインオン方式

リソースにサインオンするには，次のどちらかの方式を選択します。

コンテナ管理サインオン
アプリケーションサーバで自動的にサインオンする方式です。この方式を使用する場合，リソースアダプタごとにユーザ名とパスワードを設定しておけば，コネクション取得時に，アプリケーションサーバによって自動的にユーザ名とパスワードがリソースに伝達されます。
コンテナ管理サインオンを使用するには，Enterprise BeanやサーブレットのDDの，<resource-ref>タグ中の<res-auth>タグに，Containerを指定してください。

コンポーネント管理サインオン
ユーザプログラムでリソースにサインオンする方式です。この方式を使用する場合，コネクションを取得するときのユーザ名とパスワードをユーザプログラムで指定します。

（例）DB Connectorの場合

DataSourceクラスのgetConnectionを呼び出すときに，引数でユーザ名とパスワードを指定します。

コンポーネント管理サインオンを使用するには，Enterprise BeanやサーブレットのDDの<resource-ref>タグ中の<res-auth>タグに，Applicationを指定してください。

コネクションプーリングを使用する場合は，コネクションを効率良く再利用できるコンテナ管理サインオンの使用をお勧めします。

9.17　トランザクション管理機能の実装

トランザクション管理機能として，次に示す場合の処理概要と実装時の留意点を説明します。

コンテナ管理のトランザクション（CMT）を使用する場合

UserTransactionインタフェースを使用する場合

リソースアダプタ固有のトランザクション管理インタフェースを使用する場合

EJBクライアントでのトランザクションの実装方法については，「6.4　EJBクライアントアプリケーションでのトランザクションの実装」を参照してください。

＜この節の構成＞

9.17.1　コンテナ管理のトランザクション（CMT）を使用する場合の処理概要と留意点

9.17.2　UserTransactionインタフェースを使用する場合の処理概要と留意点

9.17.3　リソースアダプタ固有のトランザクション管理インタフェースを使用する場合の処理概要と留意点

9.17.4　トランザクションを使用しない場合の処理概要と留意点

9.17.5　JTAによるトランザクション実装時の注意事項

9.17.1　コンテナ管理のトランザクション（CMT）を使用する場合の処理概要と留意点

コンテナ管理のトランザクションを使用すれば，Enterprise Beanのビジネスメソッドが呼ばれる直前に自動的にトランザクションを開始し，ビジネスメソッドの処理が終了した直後に自動的にトランザクションをコミットできます。ユーザプログラムのコーディングとしてトランザクション管理処理をまったく記述する必要がなく，容易にリソースへのアクセスのトランザクションを管理できます。

コンテナ管理のトランザクションを使用する場合のシーケンスを示します。

図9-39　コンテナ管理のトランザクション使用時のシーケンス

コンテナ管理のトランザクションを使用する場合，次の点に留意して実装してください。

コンテナ管理のトランザクションを使用する場合，Enterprise Beanのメソッドごとにトランザクション属性を指定できます。指定できるのは，Required，RequiresNew，Mandatory，Supports，NotSupported，Neverのどれかです。トランザクションを使用する場合，DDの<transaction-type>タグにContainerを指定し，メソッドごとのトランザクション属性は<trans-attribute>タグに指定します。また，DDを使用しないで，アノテーションで定義することもできます。トランザクション属性の詳細については，「5.5.2　CMT」を参照してください。アノテーションについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

トランザクションを開始したあとのビジネスメソッドの中でリソースにアクセスした場合には，そのリソースアクセスは自動的にトランザクション管理がされます。

トランザクション開始後に複数のリソースへアクセスする場合は，グローバルトランザクションに対応したリソースアダプタを使用し，リソースアダプタのトランザクションサポートレベルをXATransactionに設定する必要があります。

コンテナ管理のトランザクションを使用する場合，ユーザプログラムのコーディングとしてトランザクション管理のための処理を記述する必要はありません。

コンテナ管理のトランザクションはEnterprise Beanで使用できます。サーブレットおよびJSPでは使用できません。

9.17.2　UserTransactionインタフェースを使用する場合の処理概要と留意点

UserTransactionインタフェースを使用すれば，ユーザプログラムからトランザクションマネージャに対して，トランザクションの開始，決着の指示を出すことができます。ユーザプログラムで，トランザクションの細かい制御をしたい場合には，この方法を使用します。

ユーザプログラムからトランザクションマネージャに対して，トランザクションの開始，決着を指示する手順を示します。

UserTransactionオブジェクトを取得します。
UserTransactionオブジェクトを取得するには，次の方法があります。

ネーミングサービスからJNDIを使用して"java:comp/UserTransaction"をルックアップする方法

EJBContextインタフェースのgetUserTransactionメソッドを呼び出して取得する方法

DIを使用して取得する方法

UserTransactionオブジェクトのbeginメソッドを呼び出して，トランザクションを開始します。

リソースにアクセスします。

UserTransactionオブジェクトのcommitメソッドまたはrollbackメソッドを呼び出して，トランザクションを決着します。

UserTransactionインタフェースを使用する場合のシーケンスを示します。

図9-40　UserTransactionインタフェース使用時のシーケンス

UserTransactionインタフェースを使用する場合，次の点に留意して実装してください。

UserTransactionインタフェースを使用する場合，DDの<transaction-type>タグにBeanを指定します。また，DDを使用しないで，アノテーションで定義することもできます。アノテーションについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

トランザクションを開始後にリソースにアクセスした場合には，そのリソースアクセスは自動的にトランザクション管理されます。

トランザクション開始後に複数のリソースへアクセスする場合は，グローバルトランザクションに対応したリソースアダプタを使用し，リソースアダプタのトランザクションサポートレベルをXATransactionに設定する必要があります。

Enterprise Bean，サーブレット，およびJSPで使用できます。

UserTransactionインタフェースを使用して，ユーザプログラムで開始したトランザクションは，例外などが発生した場合にも，ユーザプログラムでcommitまたはrollbackを発行して決着させる必要があります。決着させなかった場合，リソースのロックが解放されない，または次のトランザクションが開始できないなどの問題が発生するおそれがあります。

9.17.3　リソースアダプタ固有のトランザクション管理インタフェースを使用する場合の処理概要と留意点

リソースアダプタ固有のインタフェースを使用して，ユーザプログラムが直接リソースのトランザクションを制御することもできます。例えば，DB Connectorであれば，ConnectionインタフェースのsetAutoCommitメソッド，commitメソッド，およびrollbackメソッドを使用して，ユーザプログラムが直接リソースのトランザクションを制御できます。

リソースアダプタ固有のトランザクション管理インタフェースを使用する場合のシーケンスを示します。

図9-41　リソースアダプタ固有のトランザクション管理インタフェース使用時のシーケンス

リソースアダプタ固有のトランザクション管理インタフェースを使用する場合，次の点に留意して実装してください。

トランザクションマネージャが提供するトランザクションタイムアウトなどの機能は使用できません。

複数のリソースへのアクセスをトランザクション管理することはできません。

9.17.4　トランザクションを使用しない場合の処理概要と留意点

リソースへのアクセスをトランザクション管理しないこともできます。リソースに対して参照しかしない場合などには，トランザクション管理のコストを削減するために，この方法を使用できます。

トランザクションを使用しない場合のシーケンスを示します。

図9-42　トランザクション未使用時のシーケンス

トランザクションを使用しない場合，次の点に留意して実装してください。

Enterprise BeanのDDの<transaction-type>タグにContainerを指定して，<trans-attribute>タグにNotSupported，Neverのどちらかを指定すれば，トランザクションは使用されません。また，DDを使用しないで，アノテーションで定義することもできます。トランザクション属性の詳細については，「5.5.2　CMT」を参照してください。アノテーションについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

Enterprise BeanのDDの<transaction-type>タグにBeanを指定して，UserTransactionオブジェクトのbeginメソッドを呼び出さなければ，トランザクションは使用されません。また，DDを使用しないで，アノテーションで定義することもできます。アノテーションについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

サーブレットおよびJSPでUserTransactionオブジェクトのbeginメソッドを呼び出さなければ，トランザクションは使用されません。

特定のリソースアダプタへのアクセスだけをトランザクションで管理しないこともできます。これを実現するには，トランザクションで管理しないリソースアダプタのトランザクションサポートレベルをNoTransactionに設定します。トランザクションサポートレベルをNoTransactionに設定したリソースアダプタでは，トランザクション開始後にリソースにアクセスしてもトランザクション管理の対象とはなりません。

9.17.5　JTAによるトランザクション実装時の注意事項

JTAを使用してトランザクションを実装したプログラムの処理の内容，および動作を次の表に示します。

表9-49　JTAの動作

処理の内容
動作

EJB呼び出しで，java.rmi.RemoteExceptionまたはjava.rmi.RemoteExceptionを継承した例外が発生した場合

CORBAのシステム例外が発生した場合

クライアント側のトランザクションをロールバックにマークするかしないかは，プロパティ（ejbserver.distributedtx.rollbackClientTxOnSystemException）の設定で変わります。プロパティの設定値とその動作については，「9.3.5　システム例外発生時のトランザクションの動作」を参照してください。

トランザクションタイムアウト発生後に，javax.transaction.UserTransaction.commitメソッドを呼び出した場合
javax.transaction.RollbackException例外が発生します。ただし，トランザクションタイムアウトが発生したあと，2回以上UserTransaction.commitメソッドを呼び出すと，2回目以降はjava.lang.IllegalStateException例外が発生します。

トランザクションタイムアウト発生後にjavax.transaction.UserTransaction.rollbackメソッドを呼び出した場合
例外は発生しません。

トランザクションタイムアウト後のjavax.transaction.UserTransaction.getStatusメソッドの戻り値
javax.transaction.Status.STATUS_ROLLEDBACKが返されます。ただし，UserTransaction.commitメソッド，またはUserTransaction.rollbackメソッドを呼び出したあとは，javax.transaction.Status.STATUS_NO_TRANSACTIONが返されます。

javax.ejb.SessionSynchronizationを実装したEJBのbeforeCompletionメソッド，またはafterCompletionメソッドからのEJB呼び出し
例外が発生することなく，呼び出すことができます。

9.18　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項

この節では，EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項について説明します。

ポイント

EJBクライアントアプリケーションでトランザクションを開始できるのは，EJBクライアントマシンにApplication Serverをインストールしている場合です。uCosminexus ClientをインストールしたEJBクライアントマシンでは，EJBクライアントアプリケーションでトランザクションを開始することはできません。

EJBクライアントアプリケーションでトランザクションを開始した場合，グローバルトランザクションを使用してアプリケーションサーバ側のEJBを呼び出せます。このとき，トランザクションマネジャとトランザクションサービスは，EJBクライアントとアプリケーションサーバ間でトランザクションを伝播し，最終的に2フェーズコミットを実行します。

EJBクライアントアプリケーションで開始したトランザクション内では，アプリケーションサーバ上の複数のEJBを呼び出せます。アプリケーションサーバ側では，複数のリソースにアクセスできます。なお，EJBクライアントアプリケーションからリソースに直接アクセスすることはできません。

ここでは，EJBクライアントアプリケーションでトランザクションを開始する場合に注意することについて説明します。

＜この節の構成＞

9.18.1　アプリケーション開発時の注意事項

9.18.2　システム構築時の注意事項

9.18.3　システム運用時の注意事項

9.18.1　アプリケーション開発時の注意事項

EJBクライアントアプリケーションでトランザクションを開始する場合に，アプリケーション開発時に注意することを次に示します。EJBクライアントアプリケーションでのトランザクションの実装については，「6.4　EJBクライアントアプリケーションでのトランザクションの実装」を参照してください。

EJBクライアントアプリケーションでグローバルトランザクションを使用するには，EJBクライアントアプリケーション起動直後に，EJBクライアントアプリケーションで使用するサービスを初期化するための処理をユーザプログラムから呼び出す必要があります。この初期化処理を呼び出すことで，トランザクションマネジャとトランザクションサービスが初期化されます。初期化処理としては，EJBClientInitializerクラスのinitialize()メソッドを呼び出してください。

トランザクション処理中にEJBクライアントアプリケーションが異常終了した場合も，サービスを初期化するための処理をユーザプログラムで呼び出すことによって，トランザクションのリカバリ処理が開始できるようになります。なお，リカバリ処理はバックグラウンドで実行されるため，initialize()メソッドはリカバリ処理の完了を待たないでリターンします。EJBクライアントアプリケーションの再起動によってグローバルトランザクションのリカバリ処理が開始するように，EJBクライアントアプリケーションを設計してください。

EJBクライアントアプリケーションでトランザクションを開始している場合，必ずすべてのトランザクションを決着させてから，EJBクライアントアプリケーションが停止するように設計してください。トランザクションの決着処理を待たないでEJBクライアントアプリケーションが停止すると，未決着トランザクションがトランザクション内に残留するおそれがあります。この状態になると，アプリケーションサーバの正常停止やリソースアダプタの停止ができなくなったり，リソースのロックが解除されなくなったりする場合があります。

9.18.2　システム構築時の注意事項

EJBクライアントアプリケーションでトランザクションを開始する場合に，システム構築時に注意することを次に示します。EJBクライアントアプリケーションのトランザクションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

EJBクライアントアプリケーションでトランザクションを開始する場合，グローバルトランザクションを使用するために，アプリケーションサーバ側でライトトランザクション機能を無効に設定する必要があります（デフォルトでは有効になっています）。

呼び出されるEJBを，EJBコンテナで管理するトランザクション（CMT）でMandatory属性，Required属性，Supports属性などに指定すると，EJBクライアントアプリケーション側で開始したトランザクションの範囲内で実行されます。

9.18.3　システム運用時の注意事項

EJBクライアントアプリケーションでトランザクションを開始した場合に，運用時に注意することを次に示します。

EJBクライアントアプリケーションの停止後に，アプリケーションサーバやリソースアダプタを停止できない場合は，未決着トランザクションがトランザクション内に残留しているおそれがあります。この場合，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を実施してください。
なお，リカバリ処理は，EJBクライアントアプリケーション内で，再起動後にサービスの初期化処理を呼び出されることで実行されます。

トランザクション処理中に障害などの理由でEJBクライアントマシンがダウンした場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を実施する必要があります。

EJBクライアントアプリケーションで開始したトランザクションは，メソッドキャンセル機能を使用して強制決着させることはできません。

サービスの初期化処理で例外が発生した場合，EJBクライアントアプリケーションの実行時のシステムプロパティなどが正しく設定されていないおそれがあります。例外メッセージに従って対処してください。

EJBクライアントアプリケーションでトランザクションを開始した場合，JTAやOTSが出力する性能解析トレースにルートアプリケーション情報やクライアントアプリケーション情報が含まれません。リクエストをトレースする場合には，スレッドのハッシュコードやXIDの情報を使用してください。
また，トランザクションタイムアウトが発生した時に出力されるメッセージには，ルートアプリケーション情報の代わりに，トランザクションを開始したスレッドのハッシュコードが含まれています。この情報を使用してトレースすることもできます。

10.　コンテナ拡張ライブラリ

この章では，コンテナ拡張ライブラリの機能について説明します。

Cosminexusでは，Enterprise Beanやサーブレットから共通して使用するライブラリを，コンテナ拡張ライブラリとして利用できます。

＜この章の構成＞

10.1　コンテナ拡張ライブラリの利用

10.2　コンテナ拡張ライブラリの利用の指針

10.3　コンテナ拡張ライブラリ利用の流れ

10.4　サーバ起動・停止フック機能の実装

10.5　スマートエージェント経由でのCORBAオブジェクトの呼び出し

10.1　コンテナ拡張ライブラリの利用

Cosminexusでは，EJB-JARとWAR間で共通に利用したい処理がある場合や，異なるEAR間で共通に利用したい処理がある場合に，ユーザ作成のライブラリを利用できます。ユーザ作成のライブラリを利用することで，サーブレット，JSP，およびEnterprise Beanの機能を拡張できます。

サーブレット，JSP，およびEnterprise Beanが共通に利用できるライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することで，Enterprise Bean，サーブレット，JSPから共通して，ユーザ作成のライブラリを呼び出せるようになります。

また，サーバ起動・停止フック機能を利用することで，サーバの起動，終了時にコンテナ拡張ライブラリが呼び出されるようにできます。また，コンテナ拡張ライブラリで使用するJNI機能の初期化などを行うことができます。

コンテナ拡張ライブラリを使用するためには，ライブラリを一つのJARファイルにまとめ，コンテナ拡張ライブラリを使用するための設定をusrconf.cfgで定義します。また，コンテナ拡張ライブラリがJNIを利用する場合は，サーバ起動・停止フック機能を使用するための設定も必要です。

コンテナ拡張ライブラリの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

10.2　コンテナ拡張ライブラリの利用の指針

コンテナ拡張ライブラリを利用するかどうかの検討方法，およびコンテナ拡張ライブラリ機能利用時の制限事項について説明します。

＜この節の構成＞

10.2.1　コンテナ拡張ライブラリ利用の検討

10.2.2　コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項

10.2.1　コンテナ拡張ライブラリ利用の検討

処理の種類に応じて検討する方法と，処理の内容に応じて検討する方法について説明します。

＜この項の構成＞

(1)　処理の種類による検討

(2)　処理の内容による検討

(1)　処理の種類による検討

まず，処理を次の3種類に分類し，コンテナ拡張ライブラリを利用するかどうかを検討します。コンテナ拡張ライブラリを利用しない場合は，EJB-JARファイル，WARファイル，またはライブラリJARに共通のライブラリを含めます。

業務処理
業務ごとに処理が異なるため，EJB-JARファイル，またはWARファイルに含めます。コンテナ拡張ライブラリを利用する必要はありません。

EJB-JARファイルおよびWARファイル間の共通処理
複数のEJB-JARファイルやWARファイルに含まれる，Enterprise Bean，サーブレット，JSP，業務処理が共通に利用できる処理がある場合，ライブラリJARを利用します。ライブラリJARを利用できない場合は，共通処理のクラスを作成して，コンテナ拡張ライブラリを利用します。

EAR間の共通処理
複数のEARに含まれる，EJB-JAR，WARが共通に利用できる処理がある場合，ライブラリJARを利用します。ライブラリJARを利用できない場合は，共通処理のクラスを作成して，コンテナ拡張ライブラリを利用します。

(2)　処理の内容による検討

Enterprise Bean，サーブレット，JSPでの操作内容を次のように分類し，それぞれコンテナ拡張ライブラリを使用するかどうかを検討します。コンテナ拡張ライブラリを利用するかどうかの指針を次の表に示します。

表10-1　操作内容ごとのコンテナ拡張ライブラリの利用の指針

操作内容 | コンテナ拡張ライブラリ | EJB-JARファイルまたはWARファイル | ライブラリJAR
ファイルやディレクトリへのアクセス操作 | ○ | × | ×
JNIの利用による操作※ | ○ | × | ×
スマートエージェント経由のCORBAオブジェクトの呼び出し | ○ | × | ×
J2EEコンテナ機能の操作 | × | ○ | ×
EJB-JARファイルおよびWARファイル内のクラス参照 | × | － | ×

（凡例）　○：含める　　×：含めない　　－：該当しない

注※

J2EEアプリケーションまたはWebアプリケーションで同一のネイティブライブラリをロードしようとした場合，JNIの仕様によってUnsatisfiedLinkErrorがスローされます。これは，アプリケーションで共通に使用するネイティブライブラリをコンテナ拡張ライブラリとして登録することで，回避できます。

注意

コンテナ拡張ライブラリには，次のアクセス権が付与されます。アクセス権は変更できません。

java.security.AllPermission

ただし，java.lang.RuntimePermissionのsetSecurityManagerアクセス権は付与されません。

10.2.2　コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能を利用する場合の制限事項を示します。

アプリケーションのポータビリティについて
コンテナ拡張ライブラリはJ2EEの仕様外の機能です。したがって，コンテナ拡張ライブラリを使用した場合は，アプリケーションとしての移行性は低下します。

コンテナ拡張ライブラリの呼び出しについて
コンテナ拡張ライブラリは，サーブレット，JSP，およびEnterprise Beanから呼び出されることを前提としています。次に示す利用形態は適用できないので，注意してください。

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，EJB-JARファイル，WARファイルを参照する（EJB-JARファイル，WARファイルのクラスが，コンテナ拡張ライブラリのクラスを継承することも含む）。

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，J2EEコンテナの機能を利用する（Enterprise Bean，JNDI，JDBCなどのAPIを呼び出す）。

EJB-JARファイルおよびWARファイルのクラスから，直接サーバ起動・停止フック機能を参照する（コンテナ拡張ライブラリのクラスが，EJB-JARファイル，WARファイルのクラスを継承することも含む）。

ファイル，ディレクトリのアクセスについて
コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，次に示すファイルやディレクトリを操作しないでください。

Cosminexusのインストールディレクトリ以下のファイルやディレクトリ

J2EEサーバおよびWebコンテナサーバの作業ディレクトリ以下のファイルやディレクトリ

JNI機能の利用について
コンテナ拡張ライブラリおよびサーバ起動・停止フック機能からJNI機能を利用する場合，J2EEサーバおよびWebコンテナサーバでは，ネイティブメソッドでの処理を管理できません。例えば，ネイティブメソッドでメモリアクセス違反があった場合，J2EEサーバおよびWebコンテナサーバは，JavaVMのプロセスごと異常終了します。

Cosminexus TPBrokerの利用について

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能では，Cosminexus TPBrokerのサーバ機能を利用できません。これは，J2EEサーバおよびWebコンテナサーバ上にCosminexus TPBrokerのCORBAオブジェクトを活性化できないためです。

Cosminexus TPBrokerのDII機能は利用できません。

インストール型オプションパッケージの使用について
コンテナ拡張ライブラリおよびサーバ起動・停止フック機能は，インストール型オプションパッケージとして使用してはいけません。インストール型オプションパッケージとは，次のディレクトリに置かれたファイルです。

<Cosminexusのインストールディレクトリ>¥jdk¥jre¥lib¥extに置かれたJARファイル

<Cosminexusのインストールディレクトリ>¥jdk¥jre¥binに置かれたネイティブコードバイナリ

シャットダウンフックの登録について
コンテナ拡張ライブラリおよびサーバ起動・停止フック機能では，シャットダウンフックを登録しないでください。

10.3　コンテナ拡張ライブラリ利用の流れ

コンテナ拡張ライブラリの作成と利用の流れを次に示します。

ユーザ作成のクラスを実装，コンパイルします。
サーバ起動・停止フック機能を使用する場合は，<Cosminexusのインストールディレクトリ>¥CC¥lib¥ejbserver.jarをクラスパスに指定してコンパイルします。なお，サーバ起動・停止フック機能を使用する場合は，IDEを使用しない方法で実装，コンパイルしてください。IDEを使用しないアプリケーションの開発方法については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。
また，サーバ起動・停止フック機能では，Cosminexus TPBrokerが提供するスマートエージェント経由のCORBAオブジェクトを呼び出す処理を実装することもできます。

作成したクラスを，JARファイルにアーカイブします。
ユーザが作成したクラスを，コンテナ拡張ライブラリ用のJARファイルにアーカイブします。EJB-JARファイルやWARファイルには含めないでください。

アーカイブしたJARファイルを，J2EEサーバまたはWebコンテナサーバのシステムクラスパスに指定します。

コンテナ拡張ライブラリを利用する場合，この手順のほかにJ2EEサーバまたはWebコンテナサーバでの設定（定義ファイルの指定など）が必要になります。J2EEサーバまたはWebコンテナサーバでの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

10.4　サーバ起動・停止フック機能の実装

サーバ起動・停止フック機能を利用する場合の実装方法と，サーバ起動・停止フック機能を複数登録した場合のクラスの呼び出し順序について説明します。また，サーバ起動・停止フック機能を使用する場合に必要となるクラスパスの指定について説明します。

＜この節の構成＞

10.4.1　サーバ起動・停止フック機能の実装方法

10.4.2　サーバ起動・停止フック処理の呼び出し順序

10.4.3　サーバ起動・停止フック機能利用時のクラスパスの指定

10.4.1　サーバ起動・停止フック機能の実装方法

サーバ起動・停止フック機能は，com.hitachi.software.ejb.application.InitTermProcessインタフェースを実装することで利用できます。サーバ起動フック処理はserverInitializingメソッド，停止フック処理はserverTerminatingメソッドに実装します。次に，InitTermProcessインタフェースの実装例を示します。

package sample;

import com.hitachi.software.ejb.application.InitTermProcess;
import com.hitachi.software.ejb.application.InitTermException;

public class AppInitTerm implements InitTermProcess {
   public void serverInitializing() throws InitTermException {
       try {
           // サーバ起動フック処理
       } catch (Exception e) {
           throw new InitTermException("詳細メッセージ");
       }
   }
   public void serverTerminating() throws InitTermException {
       try {
           // サーバ停止フック処理
       } catch (Exception e) {
           throw new InitTermException("詳細メッセージ");
       }
   }
}

J2EEサーバ，Webコンテナサーバは，起動時にデフォルトコンストラクタを使用してサーバ起動・停止フック機能のインスタンスを生成します。このため，クラスおよびデフォルトコンストラクタのアクセス指定子には，publicを指定してください。

サーバ停止フック処理が呼び出されるタイミングは，アプリケーションの停止処理後になります。J2EEサーバおよびWebコンテナサーバでは，スレッドの停止処理を行っていないため，処理スレッドは残りますが，サーバ停止フック処理後に，新たにアプリケーションは実行されません。

ユーザ定義ファイル（usrconf.properties）のサーバ起動・停止フック機能用のプロパティキー（ejbserver.application.InitTermProcessClasses）に，サーバ起動・停止フックのクラス名を指定します。また，サーバ起動・停止フックのクラス名は複数指定できます。ユーザ定義ファイル（usrconf.properties）については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

10.4.2　サーバ起動・停止フック処理の呼び出し順序

サーバ起動・停止フック機能を複数登録した場合の，サーバ起動・停止フック処理の呼び出し順序について説明します。

＜この項の構成＞

(1)　正常に起動，停止した場合

(2)　サーバ起動フック処理中に例外が発生した場合

(3)　サーバ起動フック処理後に例外が発生した場合

(1)　正常に起動，停止した場合

J2EEサーバ，およびWebコンテナサーバ起動時には，登録されたクラス順にサーバ起動フック処理を行うserverInitializingメソッドが呼び出されます。また，J2EEサーバ，およびWebコンテナサーバ停止時には，登録された逆順にサーバ停止フック処理を行うserverTerminatingメソッドが呼び出されます。

J2EEサーバが正常起動した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。なお，Webコンテナサーバの場合も，次の図と同様の順序で呼び出されます。

図10-1　サーバ起動・停止フック処理の呼び出し順序（正常起動時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。サーバ起動フック処理では，正常に呼び出されると，クラスA，クラスB，クラスCの順でクラスが呼び出されます。サーバ停止フック処理では，クラスC，クラスB，クラスAの順でクラスが呼び出されます。

(2)　サーバ起動フック処理中に例外が発生した場合

サーバ起動フック処理の実行中に例外が発生した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。なお，Webコンテナサーバの場合も，次の図と同様の順序で呼び出されます。

図10-2　サーバ起動・停止フック処理の呼び出し順序（起動フック処理中の例外発生時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。クラスBのサーバ起動フック処理（serverInitializingメソッド）の実行中に例外が発生した場合は，クラスCのサーバ起動フック処理は呼び出されません。また，クラスCのサーバ停止フック処理（serverTerminatingメソッド）は呼び出されないで，クラスB，クラスAの順序でサーバ停止フック処理が呼び出されます。

(3)　サーバ起動フック処理後に例外が発生した場合

サーバ起動フック処理の実行後に例外が発生した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。なお，Webコンテナサーバの場合も，次の図と同様の順序で呼び出されます。

図10-3　サーバ起動・停止フック処理の呼び出し順序（起動フック処理後の例外発生時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。クラスBのサーバ起動フック処理（serverInitializingメソッド）の実行後に例外が発生した場合は，クラスCのサーバ起動フック処理は呼び出されません。また，サーバ停止フック処理は呼び出されません。

10.4.3　サーバ起動・停止フック機能利用時のクラスパスの指定

サーバ起動・停止フック機能を利用する場合，JARファイルのパスを，J2EEサーバおよびWebコンテナサーバのシステムクラスパスに追加する必要があります。システムクラスパスの追加は，ユーザ定義ファイル（usrconf.cfg）に指定します。

システムクラスパスの追加の方法については，マニュアル「Cosminexus　システム構築ガイド」に記載されているコンテナ拡張ライブラリの設定の説明を参照してください。また，ユーザ定義ファイル（usrconf.cfg）については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

10.5　スマートエージェント経由でのCORBAオブジェクトの呼び出し

コンテナ拡張ライブラリを利用することで，J2EEアプリケーションまたはWebアプリケーションがCosminexus TPBrokerを使用して，スマートエージェント経由でCORBAオブジェクトを呼び出すことができます。スマートエージェントを利用してCORBAオブジェクトのオブジェクトリファレンスを取得し，メソッドを呼び出すときには，スマートエージェントが起動済みとなっており，スマートエージェントに，該当するCORBAオブジェクトのオブジェクトリファレンスが登録されている必要があります。また，コンテナ拡張ライブラリには，J2EEアプリケーションまたはWebアプリケーションからCORBAオブジェクトを呼び出す処理を含めます。

次に，CORBAオブジェクト呼び出し処理の実装時の注意事項，およびCORBAオブジェクト呼び出し処理のパッケージ化の注意事項を示します。

＜この節の構成＞

(1)　CORBAオブジェクト呼び出し処理の実装時の注意事項

(2)　CORBAオブジェクト呼び出し処理のパッケージ化の注意事項

(1)　CORBAオブジェクト呼び出し処理の実装時の注意事項

CORBAオブジェクトの呼び出し処理を実装するときには，次の点に注意してください。

プロパティを使用して，org.omg.ORBをカスタマイズするには，org ORB init(String[] args, Properties props)メソッドのpropsパラメタにプロパティを指定してください。
なお，J2EEサーバおよびWebコンテナサーバのシステムプロパティに指定できるのキーは，vbroker.agent.port，vbroker.agent.enableLocator，およびvbroker.agent.addrキーだけです。

Cosminexus TPBrokerのサーバ機能は利用できません。また，J2EEサーバおよびWebコンテナサーバ上で，CORBAオブジェクトを活性化することはできません。

Cosminexus TPBrokerのインターセプタは利用できません。

Cosminexus TPBrokerのDII機能は利用できません。

(2)　CORBAオブジェクト呼び出し処理のパッケージ化の注意事項

CORBAオブジェクトの呼び出し処理をパッケージ化するときには，次の点に注意してください。

org.omg.CORBA配下のパッケージにあるインタフェース，クラスを利用するクラスは，EJB-JARファイルまたはWARファイルには含めないでください。これらのクラスは，コンテナ拡張ライブラリ用のJARファイルに含めます。

IDL定義から生成されたインタフェース，クラス，およびそれらを利用するクラスは，EJB-JARファイルまたはWARファイルには含めないでください。これらのクラスは，コンテナ拡張ライブラリ用のJARファイルに含めます。

11.　CTMによるリクエストのスケジューリングと負荷分散

この章では，リクエストのスケジューリングと負荷分散について説明します。

業務システムには，局所的な障害発生時にシステムを止めることなく安定稼働できる信頼性と，随時変わっていく業務の処理要求に柔軟に対応できる可用性が求められます。Cosminexusシステムは，これらの要求に対して，OLTP技術に対応したリクエストのスケジューリングや，サーバのクラスタリングによる負荷分散などによって対応します。

なお，この章で説明する機能は，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できる機能です。また，サーバの動作モードには依存しないで使用できます。利用できる製品については，マニュアル「Cosminexus　概説」を参照してください。

＜この章の構成＞

11.1　CTMを使用したリクエストのスケジューリングの概要

11.2　CTMのプロセス構成

11.3　CTMによるリクエストのスケジューリングの仕組み

11.4　CTMによるリクエストの流量制御と優先制御

11.5　CTMによるリクエストの閉塞制御

11.6　CTMによるリクエストの負荷分散

11.7　CTMによるリクエストのキューの滞留監視

11.8　CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続

11.1　CTMを使用したリクエストのスケジューリングの概要

この節では，CTMを使用したリクエストのスケジューリングの概要について説明します。

Cosminexusシステムでは，リクエストのスケジューリングに，CTM（Cosminexus Component Transaction Monitor）という構成ソフトウェアを使用します。CTMは，それぞれのリクエストをキューを使用して制御します。このキューを，スケジュールキューといいます。

＜この節の構成＞

11.1.1　リクエストをスケジューリングする目的

11.1.2　CTMが制御できるリクエストの種類

11.1.3　リクエストを送信するクライアントアプリケーション

11.1.1　リクエストをスケジューリングする目的

規模の大きい業務システムでは，特定のJ2EEアプリケーションを実行しているJ2EEサーバに大量のリクエストが集中することがあります。それぞれのサーバの負荷を抑え，可用性を確保して業務を滞りなく進めるためには，リクエストの送り先を分散したり，一定時間内のリクエストの流量を制御したりすることが必要です。また，複数のJ2EEサーバで処理を分散する場合に，リクエストが送信された時点で負荷が最も掛かっていないJ2EEサーバに処理させることができれば，システム全体の処理性能を向上させられます。

これらを実現するのが，リクエストのスケジューリングです。これによって，それぞれのJ2EEサーバが持つ性能を十分に活用しながら，安定して稼働するシステムを構築できます。また，リクエストをスケジューリングすることで，特定のJ2EEサーバ，J2EEアプリケーションまたは業務処理プログラム（Enterprise Bean）にトラブルが発生した場合にも，該当する範囲だけを閉塞して縮退運転できるので，システム全体の可用性を高められます。

Cosminexusシステムでは，リクエストをスケジューリングすることで，次の3種類の機能を実現できます。

流量制御
J2EEサーバで一度に実行される処理数の最大値を制限することで，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現できます。

閉塞制御
特定のJ2EEアプリケーションに対するリクエストの受け付けを停止したり，リクエストを滞留したりすることで，システム全体を稼働させたままのメンテナンスを可能にします。これによって，システムの可用性が高められます。

負荷分散
J2EEサーバ間で負荷が均等になるように処理を分散して割り当て，システム全体の処理性能と可用性が高められます。

11.1.2　CTMが制御できるリクエストの種類

CTMでスケジューリングできるリクエストは，RMI-IIOP通信を使用する，Stateless Session Beanに対するリモートインタフェース呼び出しだけです。

次のリクエストは，CTMでのスケジューリングができません。

CTMでスケジューリングできないリクエスト

Stateful Session BeanおよびEntity Beanに対する呼び出し。

ローカルインタフェースによる呼び出しおよびMessage-driven Beanに対する呼び出し（RMI-IIOP通信を使用しないため，対象になりません）。

なお，同一のJ2EEアプリケーション内の業務処理を呼び出す場合には，リクエストのスケジューリングをしたいときだけ，リモートインタフェースを使用してください。リクエストのスケジューリングをしないときは，処理性能を考慮して，ローカルインタフェースを使用して呼び出すことをお勧めします。

また，リクエストをCTMによる制御の対象にするかどうかは，J2EEアプリケーション単位，またはJ2EEアプリケーションに含まれる業務処理プログラム単位（Bean単位）で選択できます。例えば，リモートインタフェースを持つ業務処理プログラムをCTMによる制御の対象から外したい場合は，J2EEアプリケーションのプロパティを定義して設定を変更してください。CTMによるリクエストのスケジューリングの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

11.1.3　リクエストを送信するクライアントアプリケーション

CTMを使用できるクライアントは，EJBクライアントである，次のクライアントです。

EJBクライアントアプリケーション

JSP／サーブレット

ほかのEnterprise Bean

これらを開発する時に，特別なインタフェースを使用する必要はありません。CTMデーモンと連携するグローバルCORBAネーミングサービス（ctmstartの-CTMINSRefオプションに指定したCORBAネーミングサービス）に対してルックアップするように設定してください。

ただし，システム内の特定のアプリケーションサーバに障害が発生した場合にルックアップ対象のCORBAネーミングサービスを切り替えられるように，lookup，create，invoke，removeのどの処理で例外が発生してもJNDIのlookupから処理をし直すようにコーディングしてください。

11.2　CTMのプロセス構成

CTMを使用してリクエストをスケジューリングする環境のプロセス構成と配置の指針について説明します。また，各プロセスの機能についても説明します。

＜この節の構成＞

11.2.1　CTMのプロセス構成と配置

11.2.2　プロセス配置の指針

11.2.3　CTMデーモン

11.2.4　CTMレギュレータ

11.2.5　CTMドメインとCTMドメインマネジャ

11.2.6　グローバルCORBAネーミングサービス

11.2.1　CTMのプロセス構成と配置

CTMを使用する場合のプロセスの配置例を次の図に示します。

図11-1　CTMを構成するプロセスの配置例

各プロセスの主な機能について，次の表で説明します。

表11-1　CTMで使用するプロセス

プロセス
説明

CTMデーモン
クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。

CTMレギュレータ
CTMデーモンに集中するリクエストを，分散集約するためのプロセスです。

CTMドメインマネジャ
CTMドメインを管理するプロセスです。CTMドメインは，複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。

グローバルCORBAネーミングサービス
同じCTMドメイン内に含まれるホスト上の業務処理プログラムの情報を共有管理しているネーミングサービスです。

PRFデーモン
（パフォーマンストレーサ）
CTMデーモンが出力した性能解析情報をファイルに出力する，I／Oプロセスです。
詳細は，「17.10　システムの処理性能の解析」を参照してください。

スマートエージェント
Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。CTMによるリクエストのスケジューリングをする場合，スマートエージェントが必要です。
詳細は，マニュアル「Borland(R) Enterprise Server VisiBroker(R)　デベロッパーズガイド」を参照してください。

11.2.2　プロセス配置の指針

プロセスを配置する場合の指針を示します。

CTMデーモンは，ホストに一つ配置します。

J2EEサーバまたはCTMレギュレータを配置するホストには，CTMデーモンが必要です。

一つのCTMデーモンで，複数のJ2EEサーバを制御できます。なお，J2EEサーバは，一つのホストに二つ配置することをお勧めします。

一つのCTMデーモンに対して，複数のCTMレギュレータを配置できます。一つのCTMレギュレータに送信される同時リクエスト数が256を超えるような場合は，性能が劣化するおそれがあります。この場合は，CTMレギュレータの配置数を増やしてください。

EJBクライアントが動作するクライアントホストにCTMデーモンは必要ありません。

CTMデーモンを配置したホストに，CTMドメインマネジャを一つ配置します。複数のCTMデーモンを同じCTMドメインに参加させたい場合，各ホストのCTMドメインマネジャの名称には，同じ名称を指定します。

統合ネーミングスケジューラサーバにするホスト（J2EEサーバを配置しないホスト）にも，CTMデーモンを配置します。CTMレギュレータは不要です。なお，統合ネーミングスケジューラサーバについては，「(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）」で説明します。

各プロセスの起動方法については，マニュアル「Cosminexus　システム運用ガイド」の，システムの起動と停止の説明を参照してください。

CTMで使用するプロセスの配置パターンについて説明します。

＜この項の構成＞

(1)　多数のEJBクライアントからJ2EEサーバを呼び出す構成

(2)　WebブラウザからJ2EEサーバを呼び出す構成（小規模）

(3)　WebブラウザからJ2EEサーバを呼び出す構成（大規模）

(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）

(1)　多数のEJBクライアントからJ2EEサーバを呼び出す構成

多数のEJBクライアントから，並列に配列したアプリケーションサーバ上のJ2EEサーバを呼び出す構成の例を次の図に示します。

図11-2　複数のEJBクライアントからJ2EEサーバを呼び出す構成の例

(2)　WebブラウザからJ2EEサーバを呼び出す構成（小規模）

Webブラウザから，並列に配置したWebサーバ／アプリケーションサーバ上のWebコンテナを経由して，J2EEサーバを呼び出す構成の例を次の図に示します。なお，Webサーバとアプリケーションサーバは同じホスト上に配置しています。

図11-3　WebブラウザからJ2EEサーバを呼び出す構成（小規模）の例

(3)　WebブラウザからJ2EEサーバを呼び出す構成（大規模）

WebブラウザからWebサーバ上のWebコンテナを経由して，アプリケーションサーバ上のJ2EEサーバを呼び出す構成の例を次の図に示します。Webサーバとアプリケーションサーバのホストを分けることで，それらを容易に多対多の関係で構成できます。

図11-4　WebブラウザからJ2EEサーバを呼び出す構成（大規模）の例

(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）

グローバルCORBAネーミングサービスを独立したホストに配置してレプリカを作成することで，ネーミングサービスの可用性を向上させることができます。このホストを，統合ネーミングスケジューラサーバといいます。統合ネーミングスケジューラサーバにJ2EEサーバを配置する必要はありません。

ただし，ほかのホスト上の業務処理プログラム情報を統合ネーミングスケジューラサーバのグローバルCORBAネーミングサービスに登録するためには，CTMデーモンは統合ネーミングスケジューラサーバにも配置しておく必要があります。

独立した統合ネーミングスケジューラサーバを構築する構成を次の図に示します。

図11-5　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）の例

なお，この構成の場合，統合ネーミングスケジューラサーバのCTMデーモンにはcreate要求以外が送信されないため，統合ネーミングスケジューラサーバではCTMレギュレータを起動しなくてもかまいません。

11.2.3　CTMデーモン

CTMデーモンは，クライアントからのリクエストを処理してリクエストのスケジューリングを実現する，スケジューラの機能を持つプロセスです。

クライアントから送信されたリクエストは，CTMレギュレータというプロセスを経由して，CTMデーモンが受信します。CTMレギュレータについては「11.2.4　CTMレギュレータ」を参照してください。

なお，CTMデーモンの機能を使用するための設定は，CTMデーモンを起動するときにctmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMであらかじめ設定しておくことができます。

CTMデーモンは，次の手順でリクエストを処理します。

リクエストの振り分け

スケジュールキューへのリクエストの登録

業務処理プログラムの呼び出し

処理結果の返却

それぞれの処理内容について説明します。

＜この項の構成＞

(1)　リクエストの振り分け

(2)　スケジュールキューへのリクエストの登録

(3)　業務処理プログラムの呼び出し

(4)　処理結果の返却

(1)　リクエストの振り分け

CTMデーモンの負荷に応じて，リクエストを受け付けたCTMデーモンがそのままリクエストを処理するか，またはほかのCTMデーモンに転送するかを決定して振り分けます。

CTMデーモンは，リクエストを受け付けると，負荷情報をほかのCTMデーモンと連絡し合ってリクエストの振り分け先を決定します。

CTMデーモンは，特定の範囲（CTMドメイン）内のCTMデーモン間で，それぞれが処理対象としているJ2EEアプリケーションに含まれる業務処理プログラムの情報を共有しています。共有した情報は，CTMデーモンと同じホストに配置されているグローバルCORBAネーミングサービスに登録されています。これによって，リクエストを受け付けたCTMデーモンの処理対象に該当する業務処理プログラムがない場合でも，CTMデーモンが持つ情報を基に，適切なCTMにリクエストを振り分けられます。

グローバルCORBAネーミングサービスについては，「11.2.6　グローバルCORBAネーミングサービス」を参照してください。CTMドメインについては，「11.2.5　CTMドメインとCTMドメインマネジャ」を参照してください。

リクエストは，create時の選択ポリシー，およびスケジュールポリシーに従って振り分けられます。

create時の選択ポリシーおよびスケジュールポリシーは，CTMデーモンを起動するときに，次のどちらかを選択できます。

それぞれのCTMデーモンの負荷状況に応じて，負荷が軽いCTMデーモンにリクエストを振り分けるポリシー

リクエストを受け付けたCTMデーモンが優先的に処理をするポリシー
ただし，この場合でも，リクエストを受け付けたCTMデーモンの負荷が高い状態の場合，または閉塞状態の場合は，ほかのCTMデーモンに処理を振り分けます。負荷の高さは，それぞれのキューでのリクエストの滞留率から計算されます。

なお，create時の選択ポリシーおよびスケジュールポリシーのタイミングについては，「11.6　CTMによるリクエストの負荷分散」を参照してください。

スケジュールポリシーは，ctmstartコマンドの引数-CTMDispatchPolicyに指定します。create時の選択ポリシーは，ctmstartコマンドの引数-CTMCreatePolicyに指定します。

リクエスト転送時のタイムアウトについて

CTMデーモン間で，リクエスト転送処理が完了するまでの待ち時間にタイムアウトを設定できます。タイムアウトの設定は，ctmstartコマンドの-CTMDCSendTimeOutオプションに指定します。

(2)　スケジュールキューへのリクエストの登録

スケジュールポリシーに従って振り分けられたリクエストは，スケジュールキューに登録されます。スケジュールキューに登録できるリクエストの数は，CTMデーモンを起動する時に，設定されています。この値を超えてリクエストを転送された場合には，クライアントにエラーが返却されます。また，指定を省略した場合は，50が設定されます。

登録できるリクエストキューの長さは，CTMデーモンを起動するときにctmstartコマンドの引数-CTMMaxRequestCountに指定します。また，運用管理ポータルで構築したシステムを運用する場合は，あらかじめ論理CTMの設定で設定しておくことができます。ctmstartコマンドまたは運用管理ポータルの設定の詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」，または「Cosminexus　運用管理操作ガイド」を参照してください。

(3)　業務処理プログラムの呼び出し

スケジュールキューに登録されたリクエストは，CTMデーモンの処理対象であるJ2EEサーバ上の業務処理プログラムを呼び出します。なお，異常終了したJ2EEサーバや，ハングアップした業務処理プログラムを呼び出すことはありません。

(4)　処理結果の返却

処理の実行後，業務処理プログラム（Enterprise Bean）から返却された応答は，CTMデーモンを経由してクライアントに返却されます。なお，リクエストがスケジュールキューに登録されてから取り出されるまでの時間がリクエストのタイムアウト値を超えている場合は，リクエストが破棄されます。

11.2.4　CTMレギュレータ

CTMレギュレータは，CTMデーモンに対するリクエストの集中による問題を，コネクションやリクエストのレギュレート（集約）によって解決するプロセスです。CTMデーモンのフロントに配置され，EJBクライアントからのコネクションやリクエスト（invokeまたはremove）の集中を，分散集約します。

例えば，大規模なシステムでクライアントの数が増え，リクエスト数が増大した場合，システムの動作状態が不安定になったり，システムで管理する資源が不足して正常な処理ができなくなったりします。これは，リクエストのスケジューリングをするCTMデーモンに対するリクエストの集中によって，コネクション数が増大し，ファイルやソケットのオープン数などのプロセス使用資源が増大するためです。

CTMレギュレータは，このようなリクエスト集中による問題を解決するための専用のプロセスです。CTMレギュレータは，クライアントからの幾つかのコネクションを集約し，CTMデーモン当たりのコネクション数の上限を管理します。これを，コネクションのレギュレートといいます。CTMレギュレータが大量のコネクションをレギュレートすることによって，使用資源を複数プロセスに分散し，大規模なシステムをより安定して動作させることができます。

コネクションのレギュレートの仕組みを，次の図に示します。

図11-6　コネクションのレギュレートの仕組み

CTMレギュレータは，EJBクライアントからのリクエストを受け付けると，対応するCTMデーモンにリクエスト転送して，リクエストの応答を待ちます。応答が返ってくると，その応答をEJBクライアントに返却します。

CTMでは，一つのCTMデーモンに対して，必要に応じて複数のCTMレギュレータを配置できます。一つのCTMレギュレータに対する同時リクエスト数が256を超えるような場合は，性能が劣化するおそれがあります。この場合は，クライアントプロセス数に関係なく，CTMレギュレータを増やしてください。なお，CTMレギュレータは，対応するCTMデーモンと同じホスト上に配置する必要があります。

また，ネーミングサービスをJ2EEサーバとは別なホストに配置している統合ネーミングスケジューラサーバモデルの場合，統合ネーミングスケジューラサーバでは，create以外のリクエストを受け付けません。このため，CTMレギュレータを起動する必要はありません。

11.2.5　CTMドメインとCTMドメインマネジャ

CTMドメインとは，複数のCTMデーモン間で，それぞれに登録された業務処理プログラムの情報やスケジュールキューの負荷情報を交換して，情報共有と負荷分散をする範囲のことです。ドメイン名称で識別されます。CTMデーモンは，同じCTMドメイン内に存在するCTMデーモン間で，リクエストの振り分けやスケジューリングをします。CTMドメインの範囲と，CTMドメイン内の各CTMデーモンの情報は，CTMドメインマネジャによって管理されます。

ポイント

CTMドメインは，Management Serverが管理する運用管理ドメイン内に含まれます。

CTMドメインマネジャは，同じCTMドメイン内のCTMデーモンの情報を管理するデーモンプロセスです。CTMデーモンを配置したホスト上に一つずつ配置します。

なお，対象となるCTMドメインマネジャが同じネットワークセグメント内にあるか，異なるネットワークセグメントにあるかによって，CTMドメインマネジャによる情報の配布方法が異なります。

なお，CTMドメインマネジャの機能を使用するための設定は，CTMドメインマネジャを起動するときにctmdmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMドメインマネジャにあらかじめ設定しておくことができます。コマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。運用管理ポータルについては，マニュアル「Cosminexus　運用管理操作ガイド」を参照してください。

＜この項の構成＞

(1)　対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有

(2)　対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有

(3)　CTMドメインマネジャの部分再開始

(4)　CTMドメインマネジャの稼働状態の確認

(1)　対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有

CTMドメインマネジャは，ホスト内のCTMデーモンの情報を，ほかのホスト上のCTMドメインマネジャにブロードキャストで配布します。対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有について，次の図に示します。

図11-7　同じネットワークセグメント内でのCTMドメインマネジャによる情報共有

既存のCTMドメインに新しくCTMデーモンを登録したい場合は，CTMドメイン内のホスト上で，ほかのCTMドメインマネジャと同じドメイン名称とポート番号を持つCTMドメインマネジャを開始するだけで参加できます。既存のCTMドメインで環境の定義などを更新する必要がないので，システム環境をコピーするだけで，容易にシステムのスケールアウトができます。

(2)　対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有

ブロードキャストされた情報はルータを越えられないため，異なるネットワークセグメントにあるCTMドメインマネジャには届きません。この場合には，スマートエージェントを使用して情報を配布する必要があります。

対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有について，次の図に示します。

図11-8　異なるネットワークセグメントでのCTMドメインマネジャによる情報共有

複数のネットワークセグメントでCTMドメインを構成する場合に必要な設定は次のとおりです。

CTMドメインマネジャを開始するときに，情報共有の対象になるCTMドメインマネジャのホスト名またはIPアドレスを指定します。
登録できるリクエストキューは，CTMドメインマネジャを起動するときにctmdmstartコマンドの引数-CTMSendHostに指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMドメインマネジャにあらかじめ設定しておくことができます。

スマートエージェントを，異なるネットワークセグメント上のスマートエージェントと接続するように設定します。
スマートエージェントの設定については，マニュアル「Borland(R) Enterprise Server VisiBroker(R)　デベロッパーズガイド」を参照してください。

(3)　CTMドメインマネジャの部分再開始

CTMドメインマネジャが異常終了した場合，CTMドメインマネジャだけを部分再開始できるときがあります。再開始できる障害かどうかは，CTMドメインマネジャが再開始する時に，自動的に判断されます。部分再開始ができない場合は，システム全体が異常終了します。この場合は，システムを全面的に再開始してください。

(4)　CTMドメインマネジャの稼働状態の確認

CTMドメインマネジャは，ほかのホストのCTMドメインマネジャが稼働しているかどうかを確認しています。このとき，稼働状態を確認する間隔に，任意の時間を指定できます。稼働状態の確認間隔の指定は，ctmdmstartコマンドの-CTMAliveCheckCountオプションで指定します。

なお，稼働状況の確認間隔で，CTMノード情報が送信されなかった場合は，送信元のCTMドメインマネジャが停止したと判断され，送信元に対するCTMの情報が削除されます。CTMノード情報を削除した場合，そのCTMデーモンへのリクエストの振り分けは実施されません。CTMドメインマネジャの稼働状況確認について，次の図に示します。

図11-9　CTMドメインマネジャの稼働状況確認

ホストBのCTMドメインマネジャは，ホストAのCTMドメインマネジャからホストAのCTMデーモンの情報を受信します。「CTMデーモンの情報の送信間隔に指定した値×生存判定監視係数」の間にCTMデーモンの情報が受信されない場合，ホストAのCTMデーモンの情報を削除し，そのことをホストBのCTMデーモンに通知します。これによって，ホストBのCTMデーモンは，ホストAのCTMデーモンにリクエストを振り分けなくなります。

11.2.6　グローバルCORBAネーミングサービス

CTMを使用したリクエストのスケジューリングでは，ネーミングサービスとしてグローバルCORBAネーミングサービスを使用します。

グローバルCORBAネーミングサービスとは，同じCTMドメイン内に含まれるホスト上の業務処理プログラム（Stateless Session Bean）の情報を共有管理しているネーミングサービスのことです。グローバルCORBAネーミングサービスでは，それぞれのホスト上に登録されているEJBホームオブジェクトリファレンスの情報を，CTMドメイン内で共有しています。これによって，リクエストを受け付けたCTMデーモンが処理対象としているJ2EEサーバに目的の業務処理プログラムが登録されていない場合でも，CTMドメイン内のほかのホスト上に存在するCTMデーモンから，目的の業務処理プログラムが登録されているJ2EEサーバを探せるようになり，適切なCTMデーモンにリクエストを振り分けられるようになります。

グローバルCORBAネーミングサービスは，CTMデーモン一つに対して一つ配置します。CTMデーモンは，ほかのCTMデーモンと情報を交換した時に得たほかのホスト上にある業務処理プログラムの情報を，自ホスト内のグローバルCORBAネーミングサービスに登録します。これによって，CTMドメイン内で，グローバルCORBAネーミングサービスの情報が共有，同期されます。このため，J2EEサーバを配置しないでグローバルCORBAネーミングサービスだけを配置するホスト（統合ネーミングスケジューラサーバ）の場合も，ほかのホスト上で動作しているJ2EEサーバの情報を得るために，CTMデーモンを配置する必要があります。

グローバルCORBAネーミングサービスの特徴を次に示します。

障害の影響範囲を局所化することで，可用性を高められます。
CTMデーモンごとに一つずつ配置して，ドメイン内で情報を共有するので，どれかのホストのグローバルCORBAネーミングサービスにトラブルが発生した場合には，ほかのホスト上のグローバルCORBAネーミングサービスで対応できます。これによって，グローバルCORBAネーミングサービスの障害の影響範囲を局所化して，システムの可用性を高められます。

lookupの対象にするネーミングサービスを，業務処理プログラムごとに選択する必要がありません。
クラスタ構成による負荷分散を実現する場合，CTMドメイン内のすべてのグローバルCORBAネーミングサービスに同じ業務処理プログラムの情報（EJBホームオブジェクトリファレンスの情報）が登録されているので，実行する業務処理プログラムごとにルックアップするネーミングサービスを選択する必要がなくなります。これによって，特定のネーミングサービスに負荷を集中させることなく，適切な負荷分散が実現できます。

グローバルCORBAネーミングサービスを使用した処理の流れの例を次の図に示します。

この例ではホストAとホストBのCTMデーモンが同じCTMドメインに登録されています。ホストAのJ2EEサーバには業務処理プログラムAとBが，ホストBのJ2EEサーバには業務処理プログラムCが登録されています。ただし，ホストAでは障害が発生しています。また，EJBクライアントアプリケーションは，システムプロパティ（java.naming.factory.initialキー）にラウンドロビン検索を実行する指定をして開始しています。

図11-10　グローバルCORBAネーミングサービスを使用した処理の流れの例

図について説明します。

EJBクライアントアプリケーションから業務処理プログラムCを実行するためには，まず，グローバルCORBAネーミングサービスからEJBホームオブジェクトリファレンスをルックアップする必要があります。この図では，ホストAのグローバルCORBAネーミングサービスを対象にlookupを実行しましたが，ホストAでは，障害が発生していたため，lookupに対して例外が発生します。

特定のグローバルCORBAネーミングサービスで障害が発生した場合に，EJBクライアントアプリケーションのシステムプロパティでラウンドロビン検索の実行が指定されていると，自動的にCTMドメイン内のほかのグローバルCORBAネーミングサービスにlookupの対象が切り替えられます。そこで，EJBクライアントアプリケーションから再度lookupを実行すると，ホストBのグローバルCORBAネーミングサービスから業務処理プログラムCのEJBホームオブジェクトリファレンスが取得できます。業務処理プログラムCはアプリケーションサーバB上にあるので，アプリケーションサーバAの障害とは関係なく，処理を実行できます。

なお，アプリケーションサーバAに障害が発生していなかった場合は，1.のlookupの結果，ホストAのグローバルCORBAネーミングサービスに登録されていたリファレンスが返却されます。そのリファレンスを使用してcreateを実行すると，ホストAのCTMデーモンとホストBのCTMデーモン間でリクエストの振り分けが実行され，ホストBにある業務処理プログラムCのEJBホームオブジェクトリファレンスが返却されます。

注意

グローバルCORBAネーミングサービスが登録されているホストでトラブルが発生した場合は，そのホスト上のアプリケーションサーバ全体を再起動して，CTMデーモンからスケジュールキューのリファレンスを再度グローバルCORBAネーミングサービスに登録し直す必要があります。

11.3　CTMによるリクエストのスケジューリングの仕組み

リクエストのスケジューリングの仕組みについて説明します。

＜この節の構成＞

11.3.1　CTMを使用する場合の処理の流れ

11.3.2　スケジュールキューの構成とキューの共有

11.3.3　スケジュールキューの長さ

11.3.1　CTMを使用する場合の処理の流れ

ここでは，CTMを使用する場合の処理の流れについて説明します。

＜この項の構成＞

(1)　J2EEサーバの起動処理

(2)　J2EEアプリケーションのデプロイ・スタート処理

(3)　J2EEアプリケーションのストップ・アンデプロイ処理

(4)　J2EEサーバ停止処理

(1)　J2EEサーバの起動処理

CTMを使用するようにカスタマイズされているJ2EEアプリケーションをデプロイするためには，J2EEサーバの起動時に，CTMデーモンとのコネクションを確立して初期化処理を実行する必要があります。コネクションの確立と初期化は，次の手順で実行します。

CTMを使用するための設定をします。

CTMデーモンを起動します。

J2EEサーバを起動します。

J2EEサーバが起動する時に，J2EEサーバによってコネクションの確立と初期化処理が実行されます。J2EEサーバの起動前に必ずCTMデーモンを起動してください。

なお，J2EEサーバの起動時にコネクションの確立と初期化に失敗した場合は，サーバの起動が失敗します。この場合は，失敗した要因に対策してから，サーバを再起動してください。

(2)　J2EEアプリケーションのデプロイ・スタート処理

J2EEアプリケーションのデプロイ・スタートを実行すると，J2EEサーバからCTMデーモンに対して，指定されたキュー名称でスケジュールキューを活性化する要求が発行されます。CTMデーモンでは，キューを活性化してから，CTMデーモンの処理対象になる業務処理プログラムのcreateを，J2EEサーバに対して実行します。createは，CTMデーモンから直接呼び出される業務処理プログラムごとに，同時実行スレッド数（Parallel Count）分実行されます。

業務処理プログラムに対応するEJBオブジェクトリファレンスが作成されると，業務処理プログラムに対応するEJBオブジェクトリファレンスがCTMデーモンに返却されます。CTMデーモンでは，それをプールしておき，スケジュールキューにリクエストが登録された時に，それぞれのリクエストに割り当てます。これによって，リクエストが振り分けられます。

(3)　J2EEアプリケーションのストップ・アンデプロイ処理

J2EEアプリケーションをアンデプロイする時には，まず，CTMデーモンから新たにリクエストが振り分けられないように，CTMデーモンが管理しているスケジュールキューを閉塞（非活性化要求）します。CTMデーモンでは，キューを非活性化してから，CTMデーモンの処理対象になる業務処理プログラムのremoveを，J2EEサーバに対して実行します。removeは，CTMデーモンから直接呼び出される業務処理プログラムごとに，同時実行スレッド数（Parallel Count）分実行されます。

そのあとで，CTMを使用しない場合と同じように，アンデプロイ処理が実行されます。

(4)　J2EEサーバ停止処理

J2EEサーバを停止する時に，J2EEサーバとCTMデーモンとのコネクションが切断されます。

11.3.2　スケジュールキューの構成とキューの共有

キューは，J2EEアプリケーション単位，またはBean単位で作成できます。ここでは，スケジュールキューの構成と，キューの共有について説明します。また，キューを共有する場合としない場合の利点についても説明します。

＜この項の構成＞

(1)　スケジュールキューの構成

(2)　スケジュールキューを共有する場合

(3)　スケジュールキューを共有しない場合

(1)　スケジュールキューの構成

クライアントからのリクエストは，CTMデーモンによって管理されるスケジュールキューによってスケジューリングされます。スケジュールキューは，J2EEアプリケーション（EAR）単位またはBean単位で作成されます。デフォルトのキュー名称は，J2EEアプリケーション単位の場合はJ2EEアプリケーションの名称，Bean単位の場合はBean名となります。J2EEアプリケーション単位またはBean単位でスケジュールキューを持つことで，異なるインタフェースを持つ業務処理プログラム間，またはJ2EEアプリケーションのBean間でキューを共有できます。なお，スケジュールキューで制御されるリクエストは，「EJBホームリファレンスのグローバルCORBAネーミングサービス登録名称」と「業務処理プログラムのリモートインタフェース名称」の組み合わせで管理されます。

スケジュールキューは，同じCTMデーモンに対応づけられている，次のJ2EEアプリケーション間またはBean間で共有できます。

J2EEアプリケーション間で共有する場合

キュー名称が同じである

業務処理プログラムの構成が同じである（J2EEアプリケーションに含まれるEnterprise Beanが，CTMが認識する範囲で完全に一致する）

Bean間で共有する場合

キュー名称が同じである

Beanが同じである

同じ業務処理プログラム構成でもキュー名称が異なる場合や，同じキュー名称でも異なる業務処理プログラム構成を持つJ2EEアプリケーション間では，スケジュールキューは共有できません。

複数のJ2EEサーバ間でスケジュールキューを共有することもできます。ただし，その場合は，ユーザ指定名前空間機能を使用して，それぞれの業務処理プログラムであるEnterprise Beanに別名（Optional Name）を付与する必要があります。ユーザ指定名前空間機能については，「8.2　JNDI名前空間へのオブジェクトのバインドとルックアップ」を参照してください。別名の付与は，J2EEアプリケーションのプロパティとして設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

参考

デフォルトの設定でJ2EEアプリケーションをインポートすると，業務処理プログラムをルックアップするための名称が「/HITACHI_EJB/SERVERS/＜J2EEサーバ名称＞/EJB/＜J2EEアプリケーション名称＞/＜業務処理プログラムの名称＞」になります。この場合，ルックアップ名称にJ2EEサーバ名称が含まれてしまうため，J2EEサーバ間でスケジュールキューを共有できません。

一つのJ2EEサーバ内で複数のJ2EEアプリケーションを同一名称でインポートして，スケジュールキューを共有することはできません。

(2)　スケジュールキューを共有する場合

スケジュールキューを共有する場合について，J2EEアプリケーション単位での共有と，Bean単位での共有に分けて説明します。

(a)　J2EEアプリケーション単位の場合

スケジュールキューを共有すると，複数のJ2EEサーバ上のJ2EEアプリケーションで，リクエストを分散処理できます。

スケジュールキューの共有には，次のような効果があります。

キューを共有するJ2EEアプリケーション間で同時実行スレッド数を制御できるので，特定のJ2EEアプリケーションに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。

キューを共有しているどちらかのJ2EEサーバで障害が発生した場合に，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバのJ2EEアプリケーションで処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図11-11　スケジュールキューを共有する例（J2EEアプリケーション単位）

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2に処理が振り分けられます。

(b)　Bean単位の場合

スケジュールキューを共有すると，複数のJ2EEサーバ上のBeanでリクエストを分散処理できます。

スケジュールキューの共有には，次のような効果があります。

同一のJ2EEアプリケーション内にあるほかのBeanの影響を受けることなく，J2EEアプリケーション内のBean種別ごとにキューを分けることができます。

キューを共有するBean間で同時実行スレッド数を制御できるので，特定のBeanに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。

キューを共有しているどちらかのJ2EEサーバで障害が発生した場合，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバ上のBeanで処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図11-12　スケジュールキューを共有する例（Bean単位）

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2上のBean Aに処理が振り分けられます。

(3)　スケジュールキューを共有しない場合

スケジュールキューを共有しない場合，異なるJ2EEサーバに同じJ2EEアプリケーションがインポートされていたり，J2EEサーバ上に同じBeanがあったりしても，リクエストはそれぞれのキューで制御され，実行されます。

スケジュールキューを共有しないと，負荷分散や縮退運転はできなくなりますが，異なるスケジュールキューでリクエストが滞留してもその影響を受けなくなるため，優先的に業務処理を進められます。

スケジュールキューを共有しない場合は，それぞれのJ2EEアプリケーションに含まれる業務処理プログラムに別名を指定しないで，それぞれ異なるルックアップ名称にします。

スケジュールキューを共有しない例を次の図に示します。

図11-13　スケジュールキューを共有しない例

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有していない場合，指定したJ2EEアプリケーションを制御するキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXが制御しているJ2EEサーバ1に処理が振り分けられます。

11.3.3　スケジュールキューの長さ

スケジュールキューの長さは，次の単位で設定できます。

CTMデーモン単位

J2EEアプリケーション単位

Session Bean単位

CTMデーモン単位の設定については，「11.2.3(2)　スケジュールキューへのリクエストの登録」を参照してください。

J2EEアプリケーション単位またはSession Bean単位の設定は，アプリケーション属性ファイルまたはSession Bean属性ファイルの<queue-length>タグで設定します。CTMによるリクエストのスケジューリングの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ただし，スケジュールキューを共有する場合は，スケジュールキューはすでに作成されているため，指定したスケジュールキューの長さは無効になります。

11.4　CTMによるリクエストの流量制御と優先制御

ここでは，CTMによるリクエストの流量制御と，リクエストの優先制御について説明します。

＜この節の構成＞

11.4.1　リクエストの流量制御

11.4.2　リクエストの優先制御

11.4.3　リクエストの同時実行数の動的変更

11.4.1　リクエストの流量制御

CTMを使用した流量制御について説明します。

流量制御は，J2EEサーバで一度に実行される処理数の最大値を設定して，リクエストの同時実行数を制限する機能です。これによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現します。CPUや排他資源の競合も抑止できます。

CTMによる流量制御は，CTMデーモンおよびCTMデーモンが管理しているスケジュールキューを使用して実現します。

CTMによる流量制御の概要を，次の図に示します。この図は，J2EEアプリケーション単位でスケジュールキューを共有している場合の例です。

図11-14　CTMによる流量制御の概要

CTMデーモンでは，クライアントから受け付けたリクエストをスケジュールキューに登録して，J2EEアプリケーション単位に設定された同時実行スレッド数分ずつ実行します。クライアントからのリクエストが瞬間的に増加した場合でも，CTMデーモンによって流量が制御されるため，J2EEサーバで実行されるリクエストは同時実行スレッド数以上には増加しません。また，複数のJ2EEサーバのJ2EEアプリケーションで同じスケジュールキューを共有している場合は，そのJ2EEアプリケーション数および各J2EEアプリケーションの同時実行スレッド数の設定で，一度に処理できる業務処理プログラムを多重化できます。リクエストは，スケジュールキューの最大リクエスト登録数分まで受け付けられます。最大リクエスト登録数は，スケジュールキュー単位で設定できます。なお，スケジュールキュー単位での設定がない場合は，CTMデーモン単位の設定がデフォルトとなります。これを超えると，エラーが返却されます。

なお，J2EEアプリケーションの同時実行数の制御は，EJBコンテナでも実行できます。EJBコンテナの同時実行数制御とCTMの流量制御の組み合わせによる効果は次のとおりです。

あるJ2EEサーバ上のEJBコンテナで同時実行数が上限に達した場合に，ほかのJ2EE サーバにリクエストを転送できます。また，同時実行数が上限に達していなくても，該当するEJBコンテナの負荷が高い場合はほかのJ2EEサーバにリクエストを転送できます。

CTMのキューによって実行待ちのリクエスト数を一定に保てるので，それ以上のリクエストがEJBコンテナに送信された場合は，エラーを通知できます。

EJBコンテナのインスタンスのプーリングと併用できます。

CTMが制御するスレッドの最大値およびキューごとのリクエストの登録数は，CTMデーモンを起動するときに，ctmstartコマンドの引数-CTMDispatchParallelCountおよび-CTMMaxRequestCountに指定します。また，運用管理ポータルで構築したシステムを運用している場合は，あらかじめ論理CTMに設定しておくことができます。ctmstartコマンドまたは運用管理ポータルの設定の詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」，またはマニュアル「Cosminexus　運用管理操作ガイド」を参照してください。

注意

CTMによる流量制御では，スケジュールキューごとに同時実行スレッド数（Parallel Count）を設定します。また，CTMに呼び出されるStateless Session Bean単位に，プールしておくインスタンス数の最大値（Pooled InstancesのMaximum）を指定できます。プールしておくインスタンス数の最大値がスケジュールキューの同時実行スレッド数よりも少ないと，CTMから呼び出された時にインスタンスが不足するおそれがあるのでご注意ください。

CTMを使用する場合，グローバルCORBAネーミングサービスのほかにそれぞれのホストのCORBAネーミングサービス（ローカルCORBAネーミングサービス）にもEJBオブジェクトリファレンスが登録されます。このため，アプリケーションの構成によっては，CTMを使用しないで直接ローカルCORBAネーミングサービスに対してlookupを実行してEnterprise Beanを呼び出すことも可能です。ただし，この場合，CTMからの同時実行スレッド数指定が保証されなくなります。このような使用方法はしないでください。

11.4.2　リクエストの優先制御

CTMを経由するリクエストには優先順位を付けることができます。EJBクライアントに優先順位を付けておくと，優先順位の高いEJBクライアントからのリクエストは，優先順位の低いEJBクライアントからのリクエストより先にキューから取り出され，処理されます。

リクエストの優先順位は，EJBクライアントとして動作するJ2EEサーバ，WebコンテナサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。CTMでは，優先順位に小さな値が設定されているEJBクライアントから送信されてきたリクエストを，優先的に処理します。

11.4.3　リクエストの同時実行数の動的変更

CTMを使用して流量制御をしている場合に，CTMデーモンを停止しないでスケジュールキュー単位のリクエストの同時実行数を動的に変更できます。これによって，スケジュールキューが対応するサービスの内容に応じて，同時実行数を一時的に増加させたり，減少させたりできます。

CTMの同時実行数の動的変更は，ctmchparaコマンドで実行します。CTMのスケジュールキューの同時実行数の変更については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。ctmchparaコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

ポイント

ctmchparaコマンドで変更したスケジュールキュー単位の同時実行数は，CTMデーモンを停止するまで有効です。個別のJ2EEアプリケーションに設定したparallel countの値として保存はされません。一度CTMデーモンを再起動してJ2EEアプリケーションを再開始する場合には，個別のJ2EEアプリケーションに設定したparallel countの値が有効になります。

＜この項の構成＞

(1)　動的変更の処理の仕組み

(2)　同時実行数に指定できる値

(1)　動的変更の処理の仕組み

CTMによる同時実行スレッド数の動的変更の概要を，次の図に示します。

図11-15　CTMによる同時実行数の動的変更の概要

図11-15について，(a)～(c)で説明します。

(a)　同時実行数を動的変更する前の状態（スケジュールキューとしての同時実行数は5）

同時実行数を動的変更する前の，J2EEサーバ起動時の状態です。CTMデーモンのスケジュールキューは，J2EEサーバ1のアプリケーションとJ2EEサーバ2のJ2EEアプリケーションで共有されています。

J2EEサーバ1のJ2EEアプリケーションでは，Stateless Session Beanの属性として，同時実行数（parallel count）が3に設定されています。J2EEサーバ2のJ2EEアプリケーションでは，Stateless Session Beanの属性として，同時実行数（parallel count）が2に設定されています。この場合，スケジュールキュー単位の同時実行数は，それぞれのJ2EEアプリケーションの同時実行数を足した5になります。

それぞれのJ2EEサーバでは，リクエスト処理要求を受けると，必要に応じてリクエスト処理用のスレッドを生成します。最大でJ2EEアプリケーションのparallel countに設定した数分のスレッドが生成されます。生成されたスレッドは，削除されないでそのまま常駐スレッドになります。

なお，parallel countは，サーバ管理コマンドで設定，変更できます。

(b)　同時実行数を動的変更したあとの状態（同時実行数を8に増やした場合）

スケジュールキュー単位の同時実行数を動的に8に増やした場合について説明します。

スケジュールキュー単位の同時実行数を動的に増やすと，変更後の同時実行数に合わせて，それぞれのJ2EEアプリケーションのリクエスト処理用の常駐スレッド数も変更されます。

なお，常駐スレッド数が変更されるときには，スケジュールキューを共有しているJ2EEアプリケーションで，常駐スレッド数の平均化が実施されます。例えば，三つのJ2EEサーバ上のJ2EEアプリケーションのparallel countがそれぞれ40，30，60で，それぞれ常駐スレッドが最大数作成されている場合に，スケジュールキュー単位の同時実行数を120に変更しようとすると，それぞれのJ2EEサーバ上の常駐スレッド数は，「120（同時実行数）÷3（スケジュール共有数）」で平均化されて，40になります。

図11-15の場合は，同時実行数8を二つのJ2EEサーバで処理するので，常駐スレッド数がそれぞれ4ずつに変更されます。

(c)　同時実行数を動的に変更したあとの状態（同時実行数を1に減らした場合）

スケジュールキュー単位の同時実行数を1に減らした場合について説明します。

同時実行数を減らす場合も，変更後の同時実行数に合わせて，それぞれのJ2EEアプリケーションのリクエスト処理用の常駐スレッド数が変更されます。この場合も，常駐スレッド数は平均化されます。

ただし，スケジュールキュー単位の同時実行数を，スケジュールキューを共有しているJ2EEアプリケーションの数よりも小さくした場合，単純に常駐スレッド数を平均化すると，リクエストを受け付けないJ2EEサーバが出てしまいます。これを防ぐため，常駐スレッドは最低で1個は確保されます。

図11-15の場合，同時実行数1を二つのJ2EEサーバで処理するので，それぞれのJ2EEサーバの常駐処理スレッドは，最低保障常駐スレッド数である1になります。ただし，この場合も，同時に処理されるリクエストの数は，同時実行数分だけになります。つまり，J2EEサーバ2での処理が完了するまで，J2EEサーバ1のスレッドでは処理が実行されません。

(2)　同時実行数に指定できる値

同時実行数を動的変更するときに，指定できる値について説明します。

同時実行数は，1～「スケジュールキューを共有しているJ2EEアプリケーションの数×127」までの整数で指定できます。127は，一つのJ2EEアプリケーションで処理できる同時実行数（parallel count）の最大数です。

ただし，CTMデーモンを起動するときに-CTMDispatchParallelCountに指定した値を超える値は指定できません。

次の値を指定した場合は，エラーが出力されて，同時実行数は変更されません。

0

「スケジュールキューを共有しているJ2EEアプリケーションの数×127」を超える値

ctmstartコマンドの-CTMDispatchParallelCountの指定値を超える値

11.5　CTMによるリクエストの閉塞制御

CTMを使用した閉塞制御（サービス閉塞）について説明します。

閉塞制御は，特定のJ2EEアプリケーションに対するリクエストの受け付けを停止したり，リクエストを滞留させたりすることで，システム全体を停止させないでJ2EEアプリケーションの入れ替えや再起動を可能にして，システムの可用性を高めるための機能です。

CTMによる閉塞制御でできることは，次のとおりです。

オンライン状態でのJ2EEアプリケーションの入れ替え
スケジュールキューにリクエストを保持した状態でJ2EEアプリケーションを入れ替えられます。

J2EEアプリケーションの閉塞制御
リクエストの完了を待ってから，J2EEアプリケーションを閉塞させます。

スケジュールキューの閉塞制御
スケジュールキューをすぐに閉塞させます。キューに登録済みのリクエストを破棄するかどうかを選択できます。

J2EEサーバ異常終了時のリクエスト保持
J2EEサーバ異常終了時にスケジュールキューのリクエストを一定時間保持します。

リクエストの閉塞制御は，運用管理コマンド（mngsvrutil）で実行します。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

＜この節の構成＞

11.5.1　オンライン状態でのJ2EEアプリケーションの入れ替え

11.5.2　J2EEアプリケーションの閉塞制御

11.5.3　スケジュールキューの閉塞制御

11.5.4　J2EEサーバ異常終了時のリクエスト保持

11.5.1　オンライン状態でのJ2EEアプリケーションの入れ替え

J2EEアプリケーションを入れ替える場合に，オンライン状態でJ2EEアプリケーションを入れ替えられます。

J2EEアプリケーションを入れ替える場合には，CTMデーモンによって，スケジュールキューの出口を閉じてから，入れ替えを実行します。出口を閉じている間もクライアントからのリクエストはスケジュールキューに登録し続けることができます。このため，該当アプリケーションに対するリクエストもエラーにしないでシステムを運用し続けられます。ただし，スケジュールキューの最大リクエスト登録数を超えた場合は，クライアントにエラーが返却されます。

オンライン状態でのJ2EEアプリケーションの入れ替えの概要を，次の図に示します。

図11-16　オンライン状態でのJ2EEアプリケーションの入れ替えの概要

11.5.2　J2EEアプリケーションの閉塞制御

J2EEアプリケーションを停止およびアンデプロイするときに，スケジュールキューに登録されたリクエストの処理が完了するのを待ってから，J2EEアプリケーションを停止できます。これによって，停止するJ2EEアプリケーションがそのキューを共有する最後のアプリケーションであった場合に，すでに受け付けられたリクエストをエラーにしないで処理できます。

キューを共有する最後のJ2EEアプリケーションが停止する場合，CTMデーモンは，スケジュールキューの入り口を閉じてサービスを停止して，それ以上リクエストを受け付けないようにします。そのあと，スケジュールキューに登録されていたリクエストの処理がすべて完了するのを待ってから，J2EEアプリケーションを停止します。

J2EEアプリケーションの閉塞制御の概要を次の図に示します。

図11-17　J2EEアプリケーションの閉塞制御の概要

11.5.3　スケジュールキューの閉塞制御

スケジュールキューに対して，直接閉塞を実行することもできます。これによって，複数のJ2EEアプリケーションでスケジュールキューが共有されている場合に，一度にJ2EEアプリケーションを停止できます。スケジュールキューに登録されている仕掛かり中のリクエストについては，破棄するか一定の時間処理を続けるかを選択できます。処理を続ける場合は，一定の時間内に処理ができなければ強制的に破棄するように，タイムアウト時間が指定できます。また，仕掛かり中のリクエストについては，処理が続行されます。

スケジュールキューの閉塞が指示されると，CTMデーモンは，スケジュールキューの入り口を閉じてサービスを停止して，それ以降のリクエストを受け付けないようにします。また，すでにスケジュールキューに登録されたリクエストは，設定に従って，破棄するか，または処理を実行してからスケジュールキューの閉塞を完了します。リクエストを破棄する場合は，キューに登録されていたリクエストの処理はすべてエラーとしてクライアントに返却されます。処理を実行してから閉塞する場合は，一定時間処理を継続して，時間内に終了しなかった処理がエラーで返却されます。

スケジュールキューの閉塞制御の概要を，次の図に示します。

図11-18　スケジュールキューの閉塞制御の概要

スケジュールキューの閉塞制御を利用した運用については，マニュアル「Cosminexus　システム運用ガイド」のサービスの閉塞の説明を参照してください。

＜この項の構成＞

(1)　スケジュールキューの強制閉塞

(2)　スケジュールキューのタイムアウト閉塞

(1)　スケジュールキューの強制閉塞

スケジュールキューは，CTMデーモンとの通信をしないで閉塞することもできます。これを，スケジュールキューの強制閉塞といいます。強制閉塞をする場合は，運用管理コマンド（mngsvrutil）のサブコマンド「hold」の引数に，「queue force」を指定してください。

なお，スケジュールキューの強制閉塞をすると，滞留しているリクエストは一定時間後に破棄されます。滞留するリクエストを破棄したくない場合は，ctmholdqueコマンドで-CTMRequestLeaveオプションも指定してください。

(2)　スケジュールキューのタイムアウト閉塞

スケジュールキューでは，EJBクライアントのタイムアウトを一定間隔で監視し，タイムアウトの発生回数が，設定した回数を超えると，スケジュールキューを閉塞します。これを，スケジュールキューのタイムアウト閉塞といいます。

タイムアウト発生について次の図で説明します。

図11-19　スケジュールキューのタイムアウト閉塞の発生

図では，10秒間隔でタイムアウト発生回数を監視しています。タイムアウト回数のカウントは，監視時間内だけとなります。次の監視時間ではタイムアウトの回数はリセットしてカウントされます。

このとき，例えば，タイムアウト発生回数として10回が設定されている場合，10秒の監視時間内で10回以上タイムアウトが発生すると，キューが閉塞されます。なお，キューが閉塞されるタイミングは，タイムアウト回数を10回以上検知したあとの，次の監視時間で閉塞されます。この図の場合，監視を始めてから30秒後に11回のタイムアウトを検知したので，タイムアウトを検知した30秒後にキューが閉塞されます。

なお，スケジュールキューのタイムアウト閉塞は，ctmstartコマンドの-CTMWatchRequestオプションで設定します。

11.5.4　J2EEサーバ異常終了時のリクエスト保持

J2EEサーバ異常終了時に，スケジュールキューのリクエストを一定時間保持します。

これによって，J2EEサーバが異常終了した場合でも，すぐにユーザにエラーは返却されません。さらに，J2EEサーバが再起動するまでの間，クライアントからのリクエストは受け付け続けます。リクエストは，スケジュールキューの最大リクエスト登録数分まで受け付けられます。このため，J2EEサーバに障害が発生した場合でも，すぐに再起動すれば，クライアントに障害を気づかせないで運用を続けられます。ただし，スケジュールキューに登録できるリクエストの最大値を超えた場合は，クライアントにエラーが返却されます。

J2EEサーバ異常終了時のリクエスト保持の概要を，次の図に示します。

図11-20　J2EEサーバ異常終了時のリクエスト保持の概要

11.6　CTMによるリクエストの負荷分散

CTMを使用した負荷分散について説明します。

負荷分散は，クラスタ構成などで並列に運用しているJ2EEサーバ間で，負荷が均等になるように処理を分散して割り当て，システム全体の可用性を高める機能です。クライアントからのcreateおよびinvokeの要求をサーバ間，プロセス間およびスレッド間で負荷分散できます。

負荷分散は，スケジュールキューを共有しているJ2EEアプリケーション間で実行できるほか，複数のCTMデーモン間で負荷情報を交換することで，異なるスケジュールキューで制御されているJ2EEアプリケーションに含まれる業務処理プログラムに対しても実行できます。

＜この節の構成＞

(1)　負荷分散のタイミング

(2)　負荷状況の監視

(1)　負荷分散のタイミング

CTMでは，次の2回のタイミングで負荷分散を実行します。

createの実行によって，EJBオブジェクトリファレンスを取得するタイミング
このタイミングでは，負荷が軽いCTMデーモンに処理を振り分けるか，createを受け付けたホストのCTMデーモンに優先的に処理を振り分けるかが，create時の選択ポリシーに従って決まります。

invokeの実行によって，リモートインタフェースのビジネスメソッドを実行するタイミング
このタイミングでは，負荷が軽いCTMデーモンに処理を振り分けるか，リクエストを受け付けたホストのCTMデーモンに優先的に処理を振り分けるかが，スケジュールポリシーに従って決まります。

クライアントから業務処理プログラムを呼び出す流れと負荷分散のタイミングを，次の図に示します。

図11-21　EJBクライアントから業務処理プログラムを呼び出す流れと負荷分散のタイミング

図について説明します。

EJBクライアントは，各ホストに配置されているグローバルCORBAネーミングサービスに対して，lookupを実行します。
図の場合は，ホストAに対してlookupを実行しています。
グローバルCORBAネーミングサービスには，スケジュールキューのリファレンスが登録されています。図の場合は，ホストAから，登録されていたスケジュールキューのリファレンスが返却されます。

取得したリファレンスを使用してcreateを実行します。
図の場合は，ホストAのCTMデーモンに対して，createを実行しています。
このタイミングで，1回目の負荷分散が実行されます。
このとき，create時の選択ポリシーに従って負荷分散が実行されます。
createを受け付けたCTMデーモンは，create時の選択ポリシーに従って，次のどちらかのリファレンスをEJBクライアントに返却します。

createを受け付けたホストのCTMデーモンに対応するCTMレギュレータのリファレンス

CTMドメイン内の負荷が軽いCTMデーモンに対応するCTMレギュレータのリファレンス

図の場合は，ホストBのCTMレギュレータのリファレンスが返却されます。

取得したリファレンスを使用して，リモートインタフェースに定義したinvokeまたはremoveを実行します。
図の場合は，ホストBのCTMレギュレータに対して，invokeを実行しています。リクエストは，CTMレギュレータによってCTMデーモンに送信されます。
このタイミングで，2回目の負荷分散が実行されます。
invoke実行時に，スケジュールポリシーに従って負荷分散が実行されます。※
図の場合は，リクエストを受け付けたホストAのCTMデーモンに振り分けられました。振り分けられたリクエストはスケジュールキューに登録されます。実行時には，あらかじめプールされていたEJBオブジェクトのリファレンスと結び付けられて，J2EEサーバの業務処理プログラムを呼び出します。このとき，異常終了したJ2EEサーバやハングアップしてタイムアウトした業務処理プログラムを呼び出すことはありません。

注※

remove実行時にはスケジュールポリシーは適用されません。

業務処理プログラムからの応答は，リクエストを受け付けたCTMデーモンを経由して，EJBクライアントに返却されます。

(2)　負荷状況の監視

CTMでは，スケジュールキューの負荷状況を監視できます。負荷状況の監視は，J2EEサーバ単位で指定した監視時間の間隔で実施されます。監視間隔の設定は，CTMデーモンを起動するときにctmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMであらかじめ設定しておくことができます。ctmstartコマンドまたは運用管理ポータルの設定の詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」，またはマニュアル「Cosminexus　運用管理操作ガイド」を参照してください。

11.7　CTMによるリクエストのキューの滞留監視

J2EEサーバで，CTMデーモンのスケジュールキュー取り出しが遅れると，リクエストがスケジュールキューの中で滞留することがあります。これを監視する機能として，スケジュールキュー監視機能があります。

スケジュールキュー監視機能では，スケジュールキュー内に滞留しているリクエストの数を監視します。スケジュールキューにリクエストが滞留し，その数が一定の割合を超えると，メッセージを出力し，CTMデーモンは異常終了します。

スケジュールキュー監視は次のように動作します。

スケジュールキューの監視は，設定したキューの滞留率を超えた時点から開始します。

監視状態になると，指定した監視時間間隔でスケジュールキューを監視します。

監視のタイミングで，次に示すスケジュールキュー滞留監視式が成立すると，CTMデーモンが異常終了します。

スケジュールキュー滞留監視式

（P／Cn-1） ＜ （M1／100）

P：前回監視時点から現在までのリクエスト処理数

Cn-1：前回の監視時点でのキュー滞留数

M1：システム停止のしきい値（しきい値はシステムの処理率）

なお，スケジュールキュー監視は，ctmstartコマンドの-CTMWatchQueueオプションで設定します。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

＜この節の構成＞

(1)　スケジュールキュー監視の例

(2)　注意事項

(1)　スケジュールキュー監視の例

例を使用してスケジュールキュー監視について説明します。

次の内容が設定されていることとします。

スケジュールキュー監視を行うキューの滞留率：60%

システム停止のしきい値：70%

スケジュールキューの監視間隔：1秒

図11-22　スケジュールキュー監視

この例の場合，システムの処理率が70%を下回るとシステムが停止します。このため，スケジュールキュー滞留監視式「（P／Cn-1） ＜ （M1／100）」の右辺「M1／100」は，70／100＝0.7となるため，この例でのスケジュールキュー滞留監視式は次のとおりとなります。

この例のスケジュール滞留監視式

（P／Cn-1） ＜ 0.7

左辺「（P／Cn-1）」の値が0.7未満になると，CTMデーモンが異常終了します。

また，この例では，スケジュールキューの滞留数の最大が50の場合について説明します。このため，スケジュールキューの滞留率60%は，スケジュールキューの滞留数にすると30となります。滞留数が30を超えるとスケジュールキュー監視が開始されます。

図中の監視時点ごとにスケジュールキュー監視について説明します。

C₁

C₁でのスケジュールキューの滞留数は31で，スケジュールキューの滞留率が60%（滞留数は30）を超えているので，スケジュールキューの滞留監視を開始します。

C₂

P（C₁からC₂までのリクエスト処理数）＝22のため，スケジュールキュー滞留監視式の左辺「（P／Cn-1）」の値は次のようになります。

　（P／C₁）＝22／31＝0.7

システムが停止する0.7と同じ値であるため，CTMデーモンは停止しません。

また，C₂でのスケジュールキューの滞留数は45で，スケジュールキューの滞留率が60%（滞留数は30）を超えているので，引き続きスケジュールキューの滞留監視を実施します。

C₃

P（C₂からC₃までのリクエスト処理数）＝32のため，スケジュールキュー滞留監視式の左辺「（P／Cn-1）」の値は次のようになります。

　（P／C₂）＝32／45＝0.71

システムが停止する0.7を超えているので，CTMデーモンは停止しません。

また，C₃でのスケジュールキューの滞留数は35で，スケジュールキューの滞留率が60%（滞留数は30）を超えているので，引き続きスケジュールキューの滞留監視を実施します。

C₄

P（C₃からC₄までのリクエスト処理数）＝35のため，スケジュールキュー滞留監視式の左辺「（P／Cn-1）」の値は次のようになります。

　（P／C₃）＝35／35＝1

システムが停止する0.7を超えているので，CTMデーモンは停止しません。

また，C₄でのスケジュールキューの滞留数は30で，スケジュールキューの滞留率が60%（滞留数は30）と同じであるため，スケジュールキューの滞留監視は終了します。

C₅

P（C₄からC₅までのリクエスト処理数）＝5のため，スケジュールキュー滞留監視式の左辺「（P／Cn-1）」の値は次のようになります。

　（P／C₄）＝5／30＝0.16

システムが停止する0.7未満になっていますが，C₅ではスケジュールキューの滞留監視をしていないため，CTMデーモンは停止しません。

C₆

C₆でのスケジュールキューの滞留数は31で，スケジュールキューの滞留率が60%（滞留数は30）を超えているので，スケジュールキューの滞留監視を開始します。

C₇

P（C₆からC₇までのリクエスト処理数）＝2のため，スケジュールキュー滞留監視式の左辺「（P／Cn-1）」の値は次のようになります。

　（P／C₆）＝2／31＝0.06

システムが停止する0.7未満になっているので，CTMデーモンは異常停止します。

(2)　注意事項

監視状態のリクエストキューに対して，閉塞コマンド（ctmholdqueコマンド）を使用してリクエストキューに滞留しているリクエストを破棄した場合，破棄したリクエストは処理されたものとして判別されます。

リクエストキューを監視している状態で，閉塞コマンド（ctmholdqueコマンド）を使用した場合，監視状態は次のようになります。

通常閉塞の場合（ctmholdqueコマンドのオプション指定なし）
リクエストが破棄されるため，キューの滞留数が減少します。このため，自動的に監視状態が解除されます。

入口閉塞の場合（ctmholdqueコマンドに-CTMRequestLeaveオプションを指定）
滞留しているリクエストはサーバで処理されるため，監視状態のままとなります。

出口閉塞の場合（ctmholdqueコマンドに-CTMChangeServerオプションを指定）
滞留しているリクエストは処理されず，処理率が0になるため，システムは停止します。このため，監視状態は解除されます。

11.8　CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続

CTMでは，次に示すクライアントからアプリケーションサーバ上で動作するJ2EEアプリケーションを呼び出せるゲートウェイ機能を提供します。

TPBrokerクライアント
TPBroker Version 5以降で開発されたクライアントアプリケーションです。

TPBroker OTMクライアント
TPBroker Object Transaction Monitorで開発されたクライアントアプリケーションです。

また，CTMではゲートウェイでリクエストを送受信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。性能解析トレース出力については，「17.10　システムの処理性能の解析」を参照してください。

CTMのゲートウェイ機能を使用した，TPBrokerクライアントまたはTPBroker OTMクライアントからのJ2EEアプリケーションの呼び出しの概要を次の図に示します。

図11-23　TPBrokerクライアントまたはTPBroker OTMクライアントからのJ2EEアプリケーションの呼び出しの概要

TPBrokerクライアントはORBゲートウェイ経由，TPBroker OTMクライアントはOTMゲートウェイ経由で，J2EEサーバ上のJ2EEアプリケーションにリクエストを送信します。ORBゲートウェイおよびOTMゲートウェイは，CTMが提供するプロセス群で，ORBゲートウェイおよびOTMゲートウェイは，CTMデーモンを起動するときに，同時に起動されます。

TPBrokerクライアントおよびTPBroker OTMクライアントからJ2EEアプリケーションへのリクエスト方法と，リファレンスの解決方法を次に示します。

TPBrokerクライアントの場合
ctmregltdコマンドの-CTMAgentオプションに1を指定する，または-CTMIDLConnectオプションに1を指定すると，CTMレギュレータでORBゲートウェイ機能が有効になります。-CTMAgentオプションに1を指定した場合，EJBのルックアップ名称をオブジェクト名称として，スマートエージェントにCORBAリファレンスを登録します。そのため，TPBrokerクライアントでは，EJBのルックアップ名称を_bind()の引数に指定してリファレンスの参照を解決します。-CTMIDLConnectオプションに1を指定した場合，ctmgetiorコマンドでIOR文字列を取得することでリファレンスの参照を解決します。

TPBroker OTMクライアントの場合
ctmstartコマンドの-CTMTSCGwStartオプションに1以上を指定すると，OTMゲートウェイが開始されます。TPBroker OTMクライアントでは，TSCユーザプロキシを生成するコンストラクタの引数に，EJBのルックアップ（登録）名称をTSCアクセプタ名称として指定します。なお，TSCアクセプタ名称は省略できませんので注意してください。また，接続形態は，TSCレギュレータを選択してください。

なお，TPBrokerクライアントおよびTPBroker OTMクライアントからJ2EEサーバ上のアプリケーションを呼び出すためのクライアントアプリケーションの開発方法については，TPBrokerまたはTPBroker Object Transaction Monitorのドキュメントを参照してください。

12.　J2EEサーバ間のセッション情報の引き継ぎ

J2EEサーバ間のセッション情報を引き継ぐには，セッションフェイルオーバ機能を使用します。この章では，セッションフェイルオーバ機能について説明します。この機能を使用すると，アプリケーションで実行中のセッション情報が管理され，J2EEサーバで障害が発生したときにそのセッション情報がほかのJ2EEサーバに引き渡されます。これによって，リクエストがほかのJ2EEサーバに転送された場合でも，障害発生前の状態で業務を続行できるようになります。

＜この章の構成＞

12.1　セッションフェイルオーバ機能とは

12.2　グローバルセッションを利用したセッション管理

12.3　HTTP Cookieによるグローバルセッションの制御

12.4　URL書き換えによるグローバルセッションの制御

12.5　グローバルセッションの制御方法が混在する場合のシステム構成

12.6　セッションフェイルオーバ機能で実施される処理

12.7　セッションフェイルオーバ機能を使用するアプリケーションの実装

12.8　障害検知の方法

12.1　セッションフェイルオーバ機能とは

セッションフェイルオーバ機能とは，J2EEサーバやWebサーバでの，ソフトウェア障害，ハードウェア障害，およびネットワーク障害の発生時に，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトを引き継ぐ機能です。

セッションフェイルオーバ機能を使用すると，システム内の特定のJ2EEサーバに障害が発生した場合に，障害発生前のセッション情報を引き継いで，ほかのJ2EEサーバで業務を続行できます。これによって，システムの可用性を高めることができます。

ここでは，セッションフェイルオーバ機能の利点と，前提条件について説明します。

なお，セッションフェイルオーバ機能を使用するための，J2EEサーバ間のセッション情報の引き継ぎの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

12.1.1　セッションフェイルオーバの利点

12.1.2　前提条件

12.1.1　セッションフェイルオーバの利点

HttpSessionオブジェクトは，J2EEサーバのメモリ上で保持されています。J2EEサーバで障害が発生すると，HttpSessionオブジェクトは失われます。複数のJ2EEサーバで構成されているシステムの場合に，一つのJ2EEサーバで障害が発生すると，リクエストはほかのJ2EEサーバに転送されます。しかし，HttpSessionオブジェクトが失われるため，HttpSessionオブジェクトに登録された情報（セッション情報）は引き継がれません。このため，リクエストが転送されたJ2EEサーバ上のJ2EEアプリケーションでは，新規のセッションとして扱うことになります。例えば，ユーザ認証処理後の画面で障害が発生すると，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報を管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡せます。このため，J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

また，統合ユーザ管理を使用している場合でも，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継ぐことができます。

セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れを次の図に示します。

図12-1　セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れ

セッションフェイルオーバ機能を使用していないときにサーバに障害が発生すると，セッション情報が失われるため，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報がサーバ間で引き継がれるため，ブラウザでのユーザの操作では，サーバの障害発生に気づくことなく，処理を続行できます。

12.1.2　前提条件

セッションフェイルオーバ機能を利用するための前提条件について説明します。

＜この項の構成＞

(1)　前提となる構成

(2)　前提となる機能

(3)　必要な設定

(1)　前提となる構成

セッションフェイルオーバ機能を使用するには，負荷分散機の使用が前提となります。セッションフェイルオーバ機能は負荷分散機を使用した，複数のJ2EEサーバにリクエストを振り分けるシステム構成の場合に使用できます。

セッションフェイルオーバ機能を使用するためのシステム構成については，マニュアル「Cosminexus　システム設計ガイド」のSFOサーバを使用したセッション情報の引き継ぎについての説明を参照してください。

なお，リダイレクタの負荷分散機能を使用している場合，セッションフェイルオーバ機能は使用はできません。セッションフェイルオーバ機能とリダイレクタの負荷分散機能を同時に使用すると，次のような問題が発生します。

負荷分散機による，J2EEサーバ自体の負荷分散ができなくなります。

負荷分散機のヘルスチェックを任意のJ2EEサーバに送信できません。また，J2EEサーバに障害が発生した場合も，リダイレクタで正常なJ2EEサーバにリクエストが転送されるので，負荷分散機でJ2EEサーバの障害を検知できなくなります。

参考

負荷分散機によるリクエストの振り分けとは

負荷分散機では，リクエストの振り分けが実行されます。これによって，負荷が分散されるので，システムの安定稼働と処理性能の向上が図れます。

負荷分散機を使用した負荷分散には，WebサーバやJ2EEサーバに負荷分散処理に関する負荷が掛からないという利点があります。なお，負荷分散機によるリクエストの振り分け方式は，それぞれの負荷分散機に依存します。

負荷分散機によるリクエスト振り分けの例を次の図に示します。

図12-2　負荷分散機によるリクエストの振り分けの例

(2)　前提となる機能

セッションフェイルオーバ機能を使用するためには，次の機能の利用が前提となります。

HttpSessionオブジェクト数の上限値の指定機能
有効となるHttpSessionオブジェクトの数に上限値を設定する機能です。なお，セッションフェイルオーバ機能を使用する場合は，上限値に，1以上の有効な値を設定する必要があります。HttpSessionオブジェクト数の上限値の設定については，「4.4.4　HttpSessionオブジェクト数の上限値の設定」を参照してください。
なお，開発環境でグローバルセッション情報のサイズ見積もり機能を有効にする場合，HttpSessionオブジェクト数の上限値の指定は不要です。グローバルセッション情報のサイズ見積もり機能については，「12.2.10　グローバルセッション情報のサイズの見積もり」を参照してください。

セッションIDへのサーバIDの付加機能
HttpSessionのセッションIDに，Webコンテナごとに異なるサーバIDを付加する機能です。セッションIDへのサーバIDの付加については，「4.4.5　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

(3)　必要な設定

セッションフェイルオーバ機能を使用するために必要な設定について説明します。

●セッションフェイルオーバ機能を使用するためのDDの定義

セッションフェイルオーバ機能を使用するには，WebアプリケーションのDD（web.xml）にセッションフェイルオーバ用フィルタのフィルタ定義，およびフィルタマッピング定義を追加する必要があります。セッションフェイルオーバ機能を使用するためのDDの定義については，「12.7.4　DDの定義」を参照してください。セッションフェイルオーバ用フィルタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

なお，J2EEアプリケーションをJ2EEサーバにインポートしたあとで，セッションフェイルオーバ機能を使用するための設定を変更する場合は，サーバ管理コマンドによって変更できます。マニュアル「Cosminexus　システム構築ガイド」の，セッション情報の引き継ぎを行うWebアプリケーションの設定変更の説明を参照してください。

このほか，セッションフェイルオーバ機能を使用した場合，ServletAPIの動作について注意する必要があります。セッションフェイルオーバ機能を使用するアプリケーションの開発については，「12.7　セッションフェイルオーバ機能を使用するアプリケーションの実装」を参照してください。

●HTTPセッションのスティッキー（Sticky）の設定

セッションフェイルオーバ機能を使用するには，負荷分散機に対するHTTPセッションのスティッキーを設定する必要があります。

12.2　グローバルセッションを利用したセッション管理

この節では，グローバルセッションを利用したセッション管理について説明します。

＜この節の構成＞

12.2.1　グローバルセッションを利用したセッション管理の概要

12.2.2　グローバルセッションID

12.2.3　グローバルセッション情報

12.2.4　グローバルセッションを利用するためのシステム構成要素

12.2.5　グローバルセッション情報が引き継がれるセッションの条件

12.2.6　サーバの状態とグローバルセッション情報の引き継ぎ

12.2.7　グローバルセッションの制御方法

12.2.8　グローバルセッション情報の排他制御

12.2.9　グローバルセッション情報の最大数

12.2.10　グローバルセッション情報のサイズの見積もり

12.2.1　グローバルセッションを利用したセッション管理の概要

セッションフェイルオーバ機能では，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトの情報を，ほかのJ2EEサーバに引き継ぎます。

複数のJ2EEサーバ間で引き継いで使用できるセッションを，グローバルセッションといいます。HTTPセッションは，そのセッションを扱っているJ2EEサーバに障害が発生すると消失します。一方，グローバルセッションは，J2EEサーバとは別のサーバ（SFOサーバ）で管理されているため，J2EEサーバに障害が発生した場合も消失しません。このため，一つのJ2EEサーバで障害が発生した場合に，別のJ2EEサーバにHTTPセッションを作成して，グローバルセッションの情報を引き継ぐことができます。

グローバルセッションを使用している場合に，ほかのJ2EEサーバに引き継がれるHttpSessionオブジェクトの情報を，グローバルセッション情報といいます。

HTTPセッションとグローバルセッションの範囲について，次の図に示します。

図12-3　HTTPセッションとグローバルセッションの範囲

セッションフェイルオーバ機能では，J2EEサーバでの障害発生時にグローバルセッション情報を引き継ぐことで，ユーザにエラーを通知することなく，障害発生前の状態で業務を続行できます。グローバルセッション情報は，SFOサーバで管理されます。SFOサーバとは，システム内のグローバルセッション情報を管理するためのJ2EEサーバです。

セッション情報の引き継ぎの流れについて次の図で説明します。

図12-4　セッション情報引き継ぎの流れ

J2EEサーバ1でHTTPセッションの生成後，グローバルセッション情報はSFOサーバに格納されます。

J2EEサーバ1に障害が発生すると，処理を引き継いだJ2EEサーバ2では，SFOサーバに対して，グローバルセッションIDを基にグローバルセッション情報の取得を要求します。
グローバルセッションIDとは，グローバルセッション情報を一意に識別するためのIDです。

J2EEサーバ2では，セッションに対するリクエスト処理を開始する際に，グローバルセッション情報の同期をとるため，グローバルセッション情報に対してロックを掛けます。

SFOサーバは，J2EEサーバ2にグローバルセッション情報を渡します。

J2EEサーバ2でのリクエスト処理が完了すると，リクエスト処理で更新されたグローバルセッション情報は，SFOサーバに送信されます。

SFOサーバ側で，グローバルセッション情報が更新されます。

ロックが解除されます。

流れの中で出てきた項目について，以降の項で説明します。

12.2.2　グローバルセッションID

グローバルセッションIDとは，グローバルセッションを管理するためのIDです。グローバルセッションIDによって，システム内でグローバルセッション情報を一意に識別できます。グローバルセッションIDは，HttpSessionオブジェクトが作成されるごとに，HTTPセッションIDに関連づけて発行されます。J2EEサーバに障害が発生し，セッション情報が引き継がれるときにも，グローバルセッションIDが変わることはありません。

グローバルセッションIDは，グローバルセッションIDの発行時刻，およびHTTPセッションIDで構成されています。

グローバルセッションIDの形式を次の図に示します。

図12-5　グローバルセッションIDの形式

グローバルセッションIDの発行時刻は，GMT（グリニッジ標準時）の1970年1月1日0時からの通算ミリ秒数（8バイトのデータを16進数で表現したもの）です。J2EEサーバで障害が発生したときに，障害発生前と障害発生後に作成されたグローバルセッションIDを必ず一意にするために付加されています。

HTTPセッションIDは，J2EEサーバ内で一意な文字列と，サーバIDで構成されています。サーバIDとは，セッションIDへのサーバID付加機能で設定されるIDです。セッションIDへのサーバID付加機能については，「4.4.5　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

12.2.3　グローバルセッション情報

グローバルセッション情報とは，セッションフェイルオーバ機能で引き継がれるHTTPセッションの情報です。SFOサーバで管理されます。

SFOサーバでグローバルセッション情報として保持するセッション情報には，次の設定ができます。

グローバルセッション情報として引き継ぐセッション情報の範囲

グローバルセッション情報として指定できるセッション情報のデータ型

グローバルセッション情報の種別（書き換え可能にするかまたは読み込み専用にするか）

これらの設定は，セッションフェイルオーバ用フィルタに設定します。セッションフェイルオーバ用フィルタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

次に，各設定内容について説明します。

＜この項の構成＞

(1)　グローバルセッション情報として引き継ぐセッション情報の範囲

(2)　グローバルセッション情報として指定できるセッション情報のデータ型

(3)　引き継ぎ対象外のオブジェクトの扱い

(4)　グローバルセッション情報の種別

(5)　SFOサーバでのグローバルセッション情報の管理方法

(1)　グローバルセッション情報として引き継ぐセッション情報の範囲

SFOサーバでは，引き継ぎ対象として選択したセッション情報だけがグローバルセッション情報として保持されます。グローバルセッション情報として選択できるセッション情報は，HTTPセッションに登録された一部，またはすべてです。引き継ぎ対象として選択するセッション情報は，グローバルセッション情報の種別ごとに指定できます。グローバルセッション情報の種別については，「(4)　グローバルセッション情報の種別」を参照してください。

グローバルセッション情報選択時の注意事項

パフォーマンス向上のために，グローバルセッション情報には，必要最低限のHTTPセッション情報を指定してください。

(a)　HTTPセッションに登録された一部のセッション情報を引き継ぐ場合

HTTPセッションに登録されたセッション情報のうち，一部のセッション情報をグローバルセッション情報として引き継ぐ場合には，あらかじめ，DD（web.xml）で引き継ぎ対象とするセッション情報のキー名称を指定する必要があります。この場合，Webアプリケーション内で動的にキー名称を作成するセッション情報をグローバルセッションとして指定することはできません。

HTTPセッションに登録された一部のセッション情報を引き継ぐ例を次の図に示します。

図12-6　HTTPセッションに登録された一部のセッション情報を引き継ぐ例

(b)　HTTPセッションに登録されたすべてのセッション情報を引き継ぐ場合

HTTPセッションに登録されたセッション情報を，グローバルセッション情報としてすべて引き継ぐ場合には，あらかじめ，DD（web.xml）で引き継ぎ対象とするセッション情報のキー名称を設定する必要はありません。ただし，すべてのセッション情報を引き継ぐ設定をする必要があります。

注意

HTTPセッションに登録されたすべてのセッション情報をグローバルセッション情報として引き継ぐと，引き継ぐ必要がない情報がHTTPセッションに登録されている場合に，リクエスト処理のパフォーマンスが低下することがあります。このため，グローバルセッション情報には，必要なHTTPセッション情報だけ指定して引き継ぐことをお勧めします。

(2)　グローバルセッション情報として指定できるセッション情報のデータ型

(a)　データ型の種類

グローバルセッション情報として指定できるセッション情報には，次のデータ型のオブジェクトが指定できます。

java.lang.Stringクラスのオブジェクト

byte型配列

直列化可能クラスのオブジェクト

java.lang.Stringクラス以外のデータ型のオブジェクトを引き継ぎ対象とする場合は，あらかじめ，DD（web.xml）でデータ型の引き継ぎを許可する設定が必要です。DD（web.xml）でデータ型の設定を省略した場合は，java.lang.Stringクラスのオブジェクトだけが引き継ぎ可能なセッション情報となります。

参考

既存のJ2EEアプリケーションにセッションフェイルオーバ機能を適用するときは，引き継ぎをしたいセッション情報のデータ型を確認してください。指定したデータ型以外のオブジェクトの扱いについては，「(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(b)　直列化可能クラスのオブジェクトを引き継ぎ対象にする場合の注意事項

直列化可能クラスは，java.io.Serializableインタフェースを実装したクラスです。java.io.ObjectOutputStreamクラスのwriteObject()メソッドによってシリアライズできます。直列化可能クラスのオブジェクトを引き継ぎ対象にすると，グローバルセッション情報は，セッション情報をjava.io.ObjectOutputStreamクラスでシリアライズして作成されます。この場合，引き継ぐセッション情報のデータ型が，java.lang.Stringクラスのオブジェクト，またはbyte型配列であっても，データ型に関係なく，直列化可能クラスのオブジェクトとしてシリアライズされます。
セッション情報のシリアライズ処理では，属性ごとにシリアライズしたあとに，作成したグローバルセッション情報のサイズをチェックします。シリアライズ後の一時的なデータは，GSInfosLengthMaxに指定したグローバルセッション情報の最大サイズに関係なく作成されます。このため，見積もった値を超える巨大なオブジェクトがHTTPセッションに登録されることがあります。この場合，グローバルセッション情報の作成中にメモリ不足（OutOfMemoryErrorエラー）が発生するおそれがあるので，注意してください。

セッションフェイルオーバ機能では，次に示す直列化可能クラスのオブジェクトを引き継ぎ対象としてサポートしています。

J2EEアプリケーションで提供されるクラスのオブジェクト

J2SEで提供されるクラスのオブジェクト

ただし，引き継ぎ処理では，HTTPセッションに登録された直列化可能クラスのオブジェクトが，セッションフェイルオーバ機能でサポートされているかオブジェクトかどうかはチェックされません。このため，セッションフェイルオーバ機能でサポートしていないオブジェクトをHTTPセッションに登録している場合には，次のどちらかを実施して，このオブジェクトが引き継がれないようにしてください。

DD（web.xml）で引き継ぎ対象とするオブジェクトのキー名称を設定する。

オブジェクトが引き継がれないようにJ2EEアプリケーションを変更する。

(c)　データ型選択時の注意事項

セッション情報が直列化可能クラスのオブジェクトである場合，グローバルセッション情報の更新，および引き継ぎ処理で，オブジェクトのシリアライズまたはデシリアライズ処理が必要になります。シリアライズ処理は，引き継ぎ対象のオブジェクトだけでなく，このオブジェクトから参照されるオブジェクトすべてを対象とします。このため，引き継ぐ必要がない情報を含むクラスの場合，性能が低下することがあります。

シリアライズ処理の対象範囲の例を次の図に示します。

図12-7　シリアライズ処理の対象範囲の例

この図では，HTTPセッションに登録されたオブジェクト（1～3）にフィールドとして含まれているオブジェクト（a～e）も，シリアライズ処理の対象に含まれます。

パフォーマンス向上のためには，グローバルセッション情報をjava.lang.Stringクラスまたはbyte型配列のオブジェクトに限定することをお勧めします。

(3)　引き継ぎ対象外のオブジェクトの扱い

グローバルセッション情報として引き継ぎ対象外となるオブジェクトがHTTPセッションに登録された場合の扱いについて説明します。引き継ぎ対象とするセッション情報のデータ型および範囲の設定によって，オブジェクトの扱いが異なります。

また，直列化可能クラスのオブジェクトの場合，セッション情報の引き継ぎ時にシリアライズ処理またはデシリアライズ処理を実施します。これらの処理に成功するかどうかによってもオブジェクトの扱いが異なります。

(a)　java.lang.Stringクラスまたはbyte型配列のオブジェクトが引き継ぎ対象である場合

リクエスト処理完了時点で，HTTPセッションにjava.lang.Stringクラスまたはbyte型配列以外のオブジェクトが登録されている場合，引き継ぎ対象とするセッション情報の範囲の設定によって，セッション情報を引き継ぐかどうかが異なります。HTTPセッションに引き継ぎ対象外のオブジェクトが登録されている場合のセッション情報の引き継ぎ可否を次の表に示します。

表12-1　HTTPセッションに引き継ぎ対象以外のオブジェクトが登録されている場合のセッション情報の引き継ぎ可否

引き継ぎ対象とするセッション情報の範囲
リクエスト処理完了時点の動作
セッション情報の引き継ぎ可否

引き継ぎ対象外のオブジェクト
引き継ぎ対象のオブジェクト

一部のセッション情報※を引き継ぐ場合
KDJE34226-Eのメッセージが出力され，エラーが通知されます。
HTTPセッションに登録されたすべての書き換え可能グローバルセッション情報は削除され，リクエストが処理されます。この場合，KDJE34219-WのメッセージがWarningレベルで出力されます。
セッション情報は引き継がれません。
エラーが通知される原因となったHTTPセッションに登録された，すべてのセッション情報が引き継がれません。

すべてのセッション情報を引き継ぐ場合
KDJE34255-WのメッセージがWarningレベルで出力されます。
セッション情報は引き継がれません。
セッション情報はSFOサーバに冗長化されて，引き継がれます。

注※　DD（web.xml）で指定したキーで登録されたセッション情報です。

(b)　直列化可能クラスのオブジェクトが引き継ぎ対象である場合

リクエスト処理完了時点で，HTTPセッションに引き継ぎ対象外のオブジェクト登録されている場合，引き継ぎ対象とするセッション情報の設定範囲によって，セッション情報を引き継ぐかどうかが異なります。

また，直列化可能クラスのオブジェクトの場合，セッション情報の引き継ぎ時にシリアライズ処理またはデシリアライズ処理を実施します。これらの処理に成功するかどうかによってもオブジェクトの扱いが異なります。

HTTPセッションに登録された一部のセッション情報を引き継ぐ場合
DD（web.xml）で指定したキーで登録されたセッション情報は，java.io.Serializableインタフェースを実装した直列化可能クラスでなければなりません。リクエスト処理完了時点で，java.io.Serializableインタフェースを実装していないクラスのオブジェクトや，直列化可能クラス以外のオブジェクトが登録されていた場合にはエラーとなります。この場合，HTTPセッションに登録されたすべてのセッション情報が引き継がれません。
HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否を次の表に示します。

表12-2　HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否（一部のセッション情報を引き継ぐ場合）

項番
HTTPセッションに登録されたオブジェクトの内容
リクエスト処理完了時点の動作
セッション情報の引き継ぎ可否

java.io.Serializableインタフェースの実装の有無
シリアライズの成功/失敗
引き継ぎ対象外のオブジェクト
引き継ぎ対象のオブジェクト

1
java.io.Serializableインタフェースの実装有り
シリアライズの成功
リクエストは処理されます。
－（該当しません）
セッション情報はSFOサーバに冗長化されて，引き継がれます。

2
シリアライズの失敗
KDJE34256-Eのメッセージが出力され，エラーが通知されます。
HttpSessionオブジェクトに登録されたすべての書き換え可能グローバルセッション情報は削除され，リクエストが処理されます。この場合，KDJE34219-WのメッセージがWarningレベルで出力されます。
セッション情報は引き継がれません。
エラーが通知される原因となったHTTPセッションに登録された，すべてのセッション情報は引き継がれません。

3
java.io.Serializableインタフェースの実装無し
－（シリアライズできません）
KDJE34226-Eのメッセージが出力され，エラーが通知されます。
HTTPセッションに登録されたすべての書き換え可能グローバルセッション情報は削除され，リクエストが処理されます。この場合，KDJE34219-WのメッセージがWarningレベルで出力されます。
セッション情報は引き継がれません。
エラーが通知される原因となったHTTPセッションに登録された，すべてのセッション情報は引き継がれません。

HTTPセッションに登録されたすべてのセッション情報を引き継ぐ場合
リクエスト処理完了時点で，HTTPセッションにjava.io.Serializableインタフェースを実装していないクラスのオブジェクトや，直列化可能クラス以外のオブジェクトが登録されていた場合，これらのオブジェクトは無視されて引き継がれません。
HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否を次の表に示します。

表12-3　HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否（すべてのセッション情報を引き継ぐ場合）

項番
HTTPセッションに登録されたオブジェクトの内容
リクエスト処理完了時点の動作
セッション情報の引き継ぎ可否

java.io.Serializableインタフェースの実装の有無
シリアライズの成功/失敗
引き継ぎ対象外のオブジェクト
引き継ぎ対象のオブジェクト

1
java.io.Serializableインタフェースの実装有り
シリアライズの成功
リクエストは処理されます。
－（該当しません）
セッション情報はSFOサーバに冗長化されて，引き継がれます。

2
シリアライズの失敗
KDJE34256-Eのメッセージ出力され，エラーが通知されます。
HttpSessionオブジェクトに登録されたすべての書き換え可能グローバルセッション情報は削除され，リクエストが処理されます。この場合，KDJE34219-WのメッセージがWarningレベルで出力されます。
セッション情報は引き継がれません。
エラーが通知される原因となったHTTPセッションに登録された，すべてのセッション情報は引き継がれません。

3
java.io.Serializableインタフェースの実装無し
－（シリアライズできません）
KDJE34255-Wのメッセージが出力されます。
セッション情報は無視され，引き継がれません。
セッション情報はSFOサーバに冗長化されて，引き継がれます。

SFOサーバからJ2EEサーバへグローバルセッション情報を引き継ぐ場合
J2EEサーバ間でセッション情報を引き継ぐ場合，J2EEサーバは，SFOサーバからグローバルセッション情報を取得します。この時，グローバルセッション情報のデシリアライズ処理を実施します。デシリアライズ処理によるグローバルセッション情報の引き継ぎ可否を次の表に示します。

表12-4　デシリアライズ処理によるグローバルセッション情報の引き継ぎ可否

項番
デシリアライズの成功/失敗
引き継ぎ先のJ2EEサーバの処理
セッション情報の引き継ぎ可否

1
デシリアライズの成功
SFOサーバから引き継いだグローバルセッション情報を使用してリクエストは処理されます。
SFOサーバからJ2EEサーバへグローバルセッション情報が引き継がれます。

2
デシリアライズの失敗
グローバルセッション情報およびセッション情報を削除され，KDJE34258-EおよびKDJE34214-Eのメッセージが出力されます。
J2EEサーバ間のセッション情報の引き継ぎに失敗するため，リクエストはHTTPセッションがない状態で処理されます。
SFOサーバからJ2EEサーバへグローバルセッション情報は引き継がれません。

シリアライズおよぴデシリアライズに失敗する原因

シリアライズおよぴデシリアライズに失敗する原因について，次に示します。

シリアライズに失敗する原因

java.io.Serializableインタフェースを実装したクラスのオブジェクトがシリアライズに失敗する原因として，次の2点が考えられます。

HTTPセッションに登録された直列化可能クラスのオブジェクトから参照されたオブジェクトが，直列化可能クラス以外のクラスであった。

writeObject（java.io.ObjectOutputStream out）メソッドが実装されていて，かつwriteObject（java.io.ObjectOutputStream out）メソッドでシリアライズ時に例外が発生した。

デシリアライズに失敗する原因

java.io.Serializableインタフェースを実装したクラスのオブジェクトがデシリアライズに失敗する原因として，次の2点が考えられます。

アプリケーションが，シリアライズ処理時とデシリアライズ処理時で異なっていて，デシリアライズ処理が失敗する原因となる変更がアプリケーションに加えられている。

readObject（java.io.ObjectOutputStream in）メソッドが実装されていて，かつreadObject（java.io.ObjectOutputStream in）メソッドでデシリアライズ時に例外が発生した。

(4)　グローバルセッション情報の種別

保持するセッション情報には，グローバルセッション情報の種別を設定します。グローバルセッション情報の種別には，次の2種類があります。

書き換え可能グローバルセッション情報
書き換え可能グローバルセッション情報とは，HttpSessionオブジェクトに登録されたあと，変更が必要となるセッション情報です。書き換え可能グローバルセッション情報は，SFOサーバに障害が発生した場合，破棄されます。
HttpSessionオブジェクトへの登録後，更新や削除をする必要があり，リクエスト処理の推移とともに，更新される可能性のあるセッション情報は，書き換え可能グローバルセッション情報に設定してください。

読み込み専用グローバルセッション情報
読み込み専用グローバルセッション情報とは，HttpSessionオブジェクトに登録されたあと，変更されないセッション情報です。読み込み専用グローバルセッション情報は，SFOサーバに障害が発生しても，そのまま使用できます。
HttpSessionオブジェクトに登録した情報に対して，更新や削除をする必要のないセッション情報は，読み込み専用グローバルセッション情報に設定してください。例えば，ログイン情報など，一度登録すると更新する必要のない情報を読み込み専用グローバルセッション情報に設定すると，SFOサーバに障害が発生した場合でも，ユーザに対して再ログインを要求する必要がなくなるので，ユーザへの影響を軽減できます。

(5)　SFOサーバでのグローバルセッション情報の管理方法

SFOサーバでは，HttpSessionオブジェクトに含まれるグローバルセッション情報は連結されて管理されます。直列化可能クラスのオブジェクトが引き継ぎ対象でない場合，セッション情報の連結には，区切り文字として半角セミコロン（;）が使用されます。直列化可能クラスのオブジェクトが引き継ぎ対象である場合は，連結するセッション情報がシリアライズ後の情報であるため，セッション情報の連結に区切り文字は使用されません。

なお，連結されたグローバルセッション情報のサイズには上限があります。上限を超えると，エラーになります。また，上限を超えたサイズのグローバルセッション情報は，SFOサーバでは管理されないので注意してください。グローバルセッション情報の最大サイズは，WebアプリケーションのDD（web.xml）で指定します。セッションフェイルオーバ機能を使用する場合に必要な定義については，「12.7.4　DDの定義」を参照してください。また，開発環境でグローバルセッション情報のサイズを見積もる場合には，グローバルセッション情報のサイズ見積もり機能が使用できます。グローバルセッション情報のサイズ見積もり機能については，「12.2.10　グローバルセッション情報のサイズの見積もり」を参照してください。

また，デプロイ後のWebアプリケーションの場合，Webアプリケーションを含むJ2EEアプリケーションの属性（プロパティ）として設定できます。デプロイ後のWebアプリケーションのセッションフェイルオーバ用フィルタの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

12.2.4　グローバルセッションを利用するためのシステム構成要素

ここでは，グローバルセッションを利用するためのシステム構成要素である，次のサーバプロセス，アプリケーションおよびフィルタについて説明します。

SFOサーバ

SFOサーバアプリケーション

セッションフェイルオーバ用フィルタ

SFOサーバアプリケーションは，SFOサーバ上で動作するアプリケーションです。セッションフェイルオーバ用フィルタは，J2EEサーバで動作するJ2EEアプリケーションに設定するサーブレットフィルタです。

＜この項の構成＞

(1)　SFOサーバ

(2)　SFOサーバアプリケーション

(3)　セッションフェイルオーバ用フィルタ

(1)　SFOサーバ

SFOサーバとは，グローバルセッション情報を管理するサーバプロセスです。セッションフェイルオーバ機能を使用するためには，システム内にSFOサーバを配置する必要があります。

●SFOサーバの役割

SFOサーバは，J2EEサーバのJ2EEアプリケーション内で生成されたグローバルセッション情報を管理する機能を持つサーバプロセスです。実体はJ2EEサーバです。

J2EEアプリケーションが稼働しているJ2EEサーバに障害が発生して，J2EEサーバ間でグローバルセッション情報の引き継ぎが必要になると，引き継がれる側のJ2EEサーバは，SFOサーバに対してグローバルセッション情報の取得要求をします。

SFOサーバは，SFOサーバアプリケーションだけを実行するためのJ2EEサーバです。SFOサーバアプリケーション以外のアプリケーションを実行しないでください。

また，SFOサーバでは，SFOサーバアプリケーションを登録するために，CORBAネーミングサービスを使用します。CORBAネーミングサービスはSFOサーバのインプロセスで動作させてください。

●SFOサーバの複数配置

SFOサーバに障害が発生すると，SFOサーバ上で管理されているグローバルセッション情報はすべて削除されます※。SFOサーバの障害発生に備えて，システム内にSFOサーバを複数配置することもできます。

注※

削除されるのは，書き換え可能グローバルセッション情報です。読み込み専用のグローバルセッション情報は削除されません。書き換え可能，および読み込み専用のグローバルセッション情報については，「12.2.3　グローバルセッション情報」を参照してください。

SFOサーバを複数配置するときの推奨構成

SFOサーバを複数配置する構成では，J2EEサーバごとにSFOサーバを配置するのではなく，J2EEサーバ内のWebアプリケーションごとにSFOサーバを割り当てることをお勧めします。これによって，SFOサーバに障害が発生した場合の影響範囲を，障害が発生したSFOサーバを使用していたWebアプリケーションだけにとどめることができます。配置例を次の図に示します。

図12-8　複数のSFOサーバの配置例

図のように，アプリケーション1のグローバルセッション情報をSFOサーバ1で，アプリケーション2のグローバルセッション情報をSFOサーバ2で管理している場合，SFOサーバ1に障害が発生しても，影響範囲はアプリケーション1だけで済みます。また，ほかのWebアプリケーションに影響を与えることなく，SFOサーバの再起動を伴うWebアプリケーションの設定変更をすることもできます。

●SFOサーバでのJ2EEサーバの切断検知

SFOサーバでは，SFOサーバと一度接続したJ2EEサーバについて，切断検知ができます。J2EEサーバの切断は，Stateful Session Beanのタイムアウトで検知できます。J2EEサーバとの接続が切断された場合，デフォルトで最大6分後にJ2EEサーバの切断を検知できます。なお，SFOサーバがJ2EEサーバの切断を検知する前に，一度切断されたJ2EEサーバが，切断前にSFOサーバに格納したセッション情報を取得するためにSFOサーバに再接続することがあります。この場合，SFOサーバでは，J2EEサーバがいったん切断されたことを検知し，再接続をします。

(2)　SFOサーバアプリケーション

SFOサーバ上では，SFOサーバで使用するJ2EEアプリケーションが稼働しています。このJ2EEアプリケーションを，SFOサーバアプリケーションといいます。

SFOサーバアプリケーションは，グローバルセッション情報を管理する機能が実装されたアプリケーションです。EJBで実装されています。

SFOサーバアプリケーションはCosminexusで提供しています。SFOサーバをセットアップするときに，SFOサーバアプリケーションをJ2EEサーバにインポートしてください。

ポイント

Smart Composer機能を使用してシステムを構築する場合は，sfo-tierを使用してシステムを構築すると，SFOサーバアプリケーションがSFOサーバに自動的にインポートされます。

(3)　セッションフェイルオーバ用フィルタ

セッションフェイルオーバ用フィルタは，J2EE仕様で規定されたjavax.servlet.Filterインタフェースを持つクラスです。J2EEアプリケーションの実行前後に，セッションフェイルオーバ機能で必要な処理を実行します。

セッションフェイルオーバ用フィルタは，セッションフェイルオーバ機能の対象にするJ2EEアプリケーションに追加して使用します。

12.2.5　グローバルセッション情報が引き継がれるセッションの条件

ここでは，セッションフェイルオーバ機能を使用できるセッションの条件と，サーバ障害が発生したときのグローバルセッション情報の引き継ぎについて説明します。

セッションフェイルオーバ機能では，次の二つの条件を満たしているセッションの場合に，グローバルセッション情報が引き継がれます。

SFOサーバが正常に稼働している状態で作成されたセッションであること。

障害が発生した場所がクライアントから送信されるリクエストの間で，どのJ2EEサーバからも使用されていないセッションであること。

これらの条件を満たしていない場合は，グローバルセッション情報は引き継がれず，破棄されます。

また，障害発生時にJ2EEサーバで使用しているセッションについても，グローバルセッション情報は引き継がれません。障害が発生したJ2EEサーバで処理されていたリクエストは，エラーとしてクライアントに返され，セッションが切断されます。

次に，Webサーバ，J2EEサーバ，SFOサーバで障害が発生したときの，リクエストの処理位置による，グローバルセッション情報の引き継ぎの有無について説明します。

＜この項の構成＞

(1)　Webサーバで障害が発生した場合

(2)　J2EEサーバで障害が発生した場合

(3)　SFOサーバで障害が発生した場合

(1)　Webサーバで障害が発生した場合

Webサーバで障害が発生した場合，障害発生時のリクエストの処理の位置にかかわらず，リクエスト自体は正常に処理され，グローバルセッション情報が引き継がれます。障害発生時のリクエストの処理位置と，グローバルセッション情報の引き継ぎについて次の図に示します。

図12-9　障害発生時のリクエストの処理位置とグローバルセッション情報の引き継ぎ（Webサーバでの障害発生の場合）

クライアントへのレスポンスについて

図中の項番1.，2.，4.，5.，6.，7.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスはエラーとなります。

図中の項番3.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスは正常に返ります。

(2)　J2EEサーバで障害が発生した場合

J2EEサーバで障害が発生した場合，障害発生時のリクエストの処理の位置がJ2EEサーバ上にあるときは，グローバルセッション情報が破棄され，引き継ぎできません。障害発生時のリクエストの処理位置と，グローバルセッション情報の引き継ぎについて次の図に示します。

図12-10　障害発生時のリクエストの処理位置とグローバルセッション情報の引き継ぎ（J2EEサーバでの障害発生の場合）

クライアントへのレスポンスについて

図中の項番1.，4.，5.，6.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスはエラーとなります。

図中の項番2.，3.，7.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスは正常に返ります。

(3)　SFOサーバで障害が発生した場合

SFOサーバで障害が発生した場合，グローバルセッションはすべて切断されます。また，SFOサーバでの障害発生後のリクエストは，書き換え可能グローバルセッション情報は破棄されて，処理されます。

12.2.6　サーバの状態とグローバルセッション情報の引き継ぎ

サーバの停止時，およびサーバの障害発生時のセッション情報の引き継ぎについて説明します。

ここでは，次の状態の場合のセッション情報の引き継ぎについて説明します。

J2EEサーバまたはSFOサーバ停止時のセッション情報の引き継ぎ

Webサーバ，J2EEサーバまたはSFOサーバでの障害発生時のセッション情報の引き継ぎ

＜この項の構成＞

(1)　J2EEサーバ停止時のセッション情報の引き継ぎ

(2)　SFOサーバ停止時のセッション情報の引き継ぎ

(3)　WebサーバまたはJ2EEサーバの障害発生時のセッション情報の引き継ぎ

(4)　SFOサーバの障害発生時のセッション情報の引き継ぎ

(1)　J2EEサーバ停止時のセッション情報の引き継ぎ

J2EEサーバを停止すると，J2EEサーバ内のHTTPセッションは破棄されますが，SFOサーバ上にあるグローバルセッション情報は破棄されません。このため，別のJ2EEサーバにグローバルセッション情報を引き継いだり，停止したJ2EEサーバの再起動後にグローバルセッション情報を引き継いだりすることができます。

なお，SFOサーバ上のグローバルセッション情報は，SFOサーバを再起動したときに破棄されます。

(2)　SFOサーバ停止時のセッション情報の引き継ぎ

SFOサーバを停止すると，SFOサーバ上のグローバルセッション情報はすべて破棄されます。SFOサーバの停止も，SFOサーバで障害が発生したときと同様に，J2EEサーバ上のHttpSessionオブジェクトに含まれる書き換え可能グローバルセッション情報も削除されるので注意してください。

(3)　WebサーバまたはJ2EEサーバの障害発生時のセッション情報の引き継ぎ

WebサーバまたはJ2EEサーバで障害が発生したとき，リクエストは，別のJ2EEサーバに転送されます。このとき，グローバルセッション情報の引き継ぎ処理が発生します。WebサーバまたはJ2EEサーバで障害が発生したときの，セッション情報の引き継ぎについて次の図に示します。なお，この図は，HTTPリクエストヘッダのCookieヘッダにグローバルセッションIDがあるが，Cookieヘッダに含まれるJSESSIONIDに対応するHttpSessionオブジェクトがJ2EEサーバにない場合の例です。

図12-11　WebサーバまたはJ2EEサーバの障害発生時のセッション情報の引き継ぎ

SFOサーバにグローバルセッションIDに対応するグローバルセッション情報の引き継ぎ要求をします。

グローバルセッション情報を検索し，ロックします。

グローバルセッション情報をJ2EEサーバに転送します。

新規HttpSessionオブジェクトを作成します。

3.で取得したグローバルセッション情報を，4.で作成した新規HttpSessionオブジェクトに格納します。

J2EEアプリケーション内の処理で，引き継がれたグローバルセッション情報を使用します。

J2EEアプリケーション処理の終了後，セッションフェイルオーバ用フィルタでグローバルセッション情報をSFOサーバに送信します。

SFOサーバ上のグローバルセッション情報を更新します。

SFOサーバ上のグローバルセッション情報のロックを解除します。

(4)　SFOサーバの障害発生時のセッション情報の引き継ぎ

SFOサーバに障害が発生している間は，セッションフェイルオーバ機能が無効になり，HTTPセッションによるセッション管理で業務を続けます。このため，SFOサーバに障害が発生している間は，グローバルセッションは生成されません。

SFOサーバの障害発生中に作成されたHttpSessionオブジェクトは，SFOサーバが復旧すると，最初にリクエストが送信された時点で，対応するグローバルセッションが生成され，SFOサーバに格納されます。

SFOサーバに障害が発生すると，J2EEサーバ上にあるHttpSessionオブジェクト内の書き換え可能グローバルセッション情報を削除します。SFOサーバ障害発生時のグローバルセッション情報の削除処理の動作を次の図で説明します。

図12-12　SFOサーバ障害発生時のグローバルセッション情報の削除処理

グローバルセッションIDのHTTP Cookie情報を削除するよう，HTTPレスポンスヘッダのSet-Cookieヘッダに，有効期限切れを示す情報をセットします。

HttpSessionオブジェクトに含まれる書き換え可能グローバルセッション情報を削除します。

J2EEアプリケーション内の処理では，書き換え可能グローバルセッション情報だけが削除されたHttpSessionオブジェクトが使用されます。

参考

書き換え可能グローバルセッション情報の削除は，SFOサーバの障害時以外にも，ロック待ちタイムアウトが発生した場合，および無効となったグローバルセッションIDを使用するリクエストが送信された場合も実施されます。

SFOサーバに障害が発生したときの，グローバルセッションIDの発行，HttpSessionオブジェクトの最大数，およびグローバルセッション情報は次のようになります。

●SFOサーバの障害発生時のグローバルセッションIDの発行について

SFOサーバに障害が発生した場合，セッションフェイルオーバ機能は無効になります。このため，HttpSessionオブジェクトが生成されても，グローバルセッションIDは発行されません。なお，SFOサーバが回復すると，最初に実施されるロック処理でグローバルセッションIDが発行されます。ロックが解除されたときにSFOサーバにグローバルセッション情報が格納されます。

●SFOサーバに障害が発生した場合のHttpSessionオブジェクトの最大数について

SFOサーバに障害が発生した場合，セッションフェイルオーバ機能は無効になります。SFOサーバが停止していると，J2EEサーバでは，SFOサーバで管理できるグローバルセッション情報の最大数を超えて，HTTPセッション数の上限までHttpSessionオブジェクトが生成されます。

SFOサーバが回復すると，リクエスト処理で使用されたセッション情報から順にSFOサーバに格納されます。このとき，SFOサーバに格納できない分のHttpSessionオブジェクトについては，リクエストを受信した時点で破棄され，新規リクエストとして再度生成されて，J2EEアプリケーションに送られます。

●SFOサーバに障害が発生した場合のグローバルセッション情報について

SFOサーバに障害が発生したあとのグローバルセッション情報について，種類ごとに説明します。なお，グローバルセッションの種類の概要については，「12.2.3　グローバルセッション情報」を参照してください。

書き換え可能グローバルセッション情報の場合

SFOサーバに障害が発生した場合，SFOサーバによる管理ができなくなるため，書き換え可能グローバルセッション情報は使用できなくなります。

読み込み専用グローバルセッション情報の場合

継続して使用できます。

SFOサーバで障害が発生したあとのリクエストは，書き換え可能グローバルセッション情報を削除したHttpSessionオブジェクトで処理を続行します。クライアントへのレスポンスも正常に返ります。

また，セッションフェイルオーバ用フィルタがSFOサーバに対してロック要求をした延長でSFOサーバに障害が発生した場合は，次のように処理されます。

書き換え可能グローバルセッション情報の削除をしたあとのHttpSessionオブジェクトに対して新しいグローバルセッションIDが作成されます。

SFOサーバに対するロック処理が実行されます。

J2EEアプリケーションが処理されます。

この処理が発生した場合，HttpSessionオブジェクトの属性に次に示すキー名称と値が登録されます。

キー名称：com.hitachi.software.was.sfo.gsession.status

値：unavailable

なお，この属性は，SFOサーバの復旧後，グローバルセッション情報がSFOサーバに格納されると削除されます。また，この属性は，SFOサーバに冗長化されないため，引き継ぎの対象になりません。

●SFOサーバに障害が発生した場合のHTTPセッション

SFOサーバに障害が発生したあとでも，Webアプリケーションで作成された新しいHTTPセッションは使用できます。ただし，セッションフェイルオーバ機能は無効になっているため，SFOサーバには格納されません。

なお，SFOサーバ復旧後，SFOサーバに障害が発生しているときに作成されたHTTPセッションは，リクエスト処理で使用されたHTTPセッションから順に，SFOサーバに格納され，セッションフェイルオーバ機能が有効になります。このとき，SFOサーバの障害発生中に登録された書き換え可能グローバルセッション情報や読み込み専用グローバルセッション情報は，そのままSFOサーバに格納されます。

12.2.7　グローバルセッションの制御方法

ここでは，グローバルセッションの制御方法について説明します。

＜この項の構成＞

(1)　グローバルセッションの制御方法の種類

(2)　グローバルセッション情報の制御方法の選択指針

(3)　注意事項

(1)　グローバルセッションの制御方法の種類

グローバルセッションは，次のどちらかの方法で制御できます。

HTTP Cookieによる制御
グローバルセッションIDをHTTP Cookieによって管理する制御方法です。J2EEサーバからWebクライアントにレスポンスを返すときに，グローバルセッションIDを含むHTTP Cookieを設定します。次にWebクライアントがJ2EEサーバにリクエストを送るときには，そのHTTP Cookieを送信します。これによって，グローバルセッションの制御を実現します。

URL書き換えによる制御
グローバルセッションIDをURLのパスパラメタに含めて管理する制御方法です。
J2EEサーバがWebクライアントに返すページ遷移用のURLを書き換えるときに，グローバルセッションIDを含めてエンコードします。次にWebクライアントがJ2EEサーバにリクエストを送るときには，このエンコードされたURLを使用します。これによって，グローバルセッションの制御を実現します。

使用するクライアントの種類などに応じて，適切な制御方法を選択してください。それぞれの制御方法の詳細については，「12.3　HTTP Cookieによるグローバルセッションの制御」および「12.4　URL書き換えによるグローバルセッションの制御」を参照してください。

制御方法は，セッションフェイルオーバ用フィルタに設定します。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，セッションフェイルオーバ用フィルタの設定についての説明を参照してください。

参考

両方の制御方法を使用する設定をしている場合に，HTTP CookieおよびURLのパスパラメタの両方にグローバルセッションIDが含まれているときの動作

セッションフェイルオーバ用フィルタでの制御方法の設定では，次の設定ができます。

HTTP Cookieを使用することを示す設定（cookie）

URL書き換えを使用することを示す設定（url-rewriting）

両方の制御方法を使用することを示す設定（both）

「both」を設定している場合に，HTTP CookieおよびURLのパスパラメタの両方にグローバルセッションIDが含まれているときには，HTTP Cookieに含まれるグローバルセッションIDが有効になります。このとき，URLのパスパラメタに含まれているグローバルセッションIDは無効になります。

なお，URL書き換えによるグローバルセッション制御は，J2EEサーバおよびSFOサーバのバージョンが07-50以降の場合に使用できます。

(2)　グローバルセッション情報の制御方法の選択指針

HTTP Cookieによって制御できる場合は，HTTP Cookieによる制御を選択してください。

URL書き換えによる制御をする場合，リクエストおよびレスポンスの両方に，HTTPセッションのセッションIDとグローバルセッションIDが含まれることになります。この方法は，一般的にセッションハイジャックなどの危険性が高まるといわれています。

HTTP Cookieを使用できないクライアントを使用するシステムなど，特定のシステム以外では，URL書き換えによる制御は使用しないことをお勧めします。

(3)　注意事項

Webクライアントから受信したリクエストが，次の条件をすべて満たす場合，グローバルセッションが作成されません。

HTTPセッションが存在する。

WebアプリケーションのDDに，グローバルセッションの制御方法として，HTTP Cookie，またはURL書き換えのどちらかを使用すると設定している（「both」を設定していない）。

すでに存在するHTTPセッションの制御方法が，Webアプリケーションに設定したグローバルセッションの制御方法と異なる。

これらの条件に当てはまるリクエストに関連づけられたHTTPセッションは，セッションフェイルオーバ機能の対象にはなりません。この場合，リクエストの受信時にKDJE34524-Wのメッセージが出力されます。

ただし，グローバルセッションが作成されない場合も，HTTPセッションは継続されます。

12.2.8　グローバルセッション情報の排他制御

ここでは，SFOサーバで管理しているグローバルセッション情報の排他制御について説明します。

セッションフェイルオーバ機能では，複数のJ2EEサーバから同じグローバルセッション情報を同時に更新されることを抑止するために，ロックを使用して排他制御を実現します。

J2EEサーバは，セッションに対するリクエスト処理を開始するときに，SFOサーバ上のグローバルセッション情報にロックを設定します。また，リクエスト処理が完了した時点でロックを解除します。

別のJ2EEサーバによってすでにロックが設定されているグローバルセッション情報をロックしようとした場合は，設定されているロックが解除されるまで，処理が待たされます。これを，ロック待ちといいます。

なお，ロック待ちには，タイムアウト時間を設定できます。タイムアウトが発生した場合，J2EEサーバは，該当するグローバルセッション情報が使用できないものと判断します。この場合，J2EEサーバは，SFOサーバ上の書き換え可能グローバルセッション情報を破棄して，J2EEアプリケーションを呼び出し，リクエスト処理を実行します。

ロック待ちのタイムアウト時間は，Webアプリケーション単位で設定できます。設定方法については，「12.7.4　DDの定義」を参照してください。

参考

異なるJ2EEサーバに振り分けられた場合，グローバルセッション情報のロック機能を使用して，更新業務を実行するJ2EEアプリケーションの排他制御も実現できます。

更新業務を実行するJ2EEアプリケーションでは，ダブルクリックなどによってリクエストが二重に送信されると，正常に処理が実行できなくなる場合があります。このため，J2EEアプリケーションでは，セッションなどを利用して，このような場合に二重に処理するのを抑止する必要があります。

セッションフェイルオーバ機能を使用している場合，ダブルクリックなどによって二重送信されたリクエストが異なるJ2EEサーバに送信されたときには，グローバルセッション情報のロック設定時にロック待ちが発生します。これによって，処理が二重に実施されるのを防げます。

12.2.9　グローバルセッション情報の最大数

SFOサーバで管理できるグローバルセッション情報の最大数は，SFOサーバと接続しているWebアプリケーションのHttpSessionオブジェクト数の上限値となります。

WebアプリケーションのHttpSessionオブジェクト数の上限値と，SFOサーバで管理できるグローバルセッション情報の最大数の関係を次の図に示します。

図12-13　SFOサーバで管理できるグローバルセッション情報の最大数

図のように，各Webアプリケーションの，HttpSessionオブジェクト数の上限値に1,000が設定されている場合，SFOサーバで管理できるグローバルセッション情報の最大数も1,000となります。

しかし，実際にはSFOサーバは，複数のJ2EEサーバで生成されたHTTPセッションを一括して管理するため，WebアプリケーションのHttpSessionオブジェクト数の上限値に達する前に，SFOサーバ内のグローバルセッション情報の数が最大数に達することがあります。次の図で説明します。

図12-14　HttpSessionオブジェクト数の上限とSFOサーバのグローバルセッション情報の最大数との関係

SFOサーバで管理するグローバルセッション情報の数は，各WebアプリケーションのHttpSessionオブジェクト数の合計となるため，図のように，WebアプリケーションのHttpSessionオブジェクト数が上限値に達していなくても，SFOサーバのグローバルセッション情報の数が最大数に達する場合があります。このとき，J2EEサーバ上のJ2EEアプリケーション内で，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドを呼び出すと，IllegalStateExceptionが送出されます。

なお，HttpSessionオブジェクト数の上限値設定については，「4.4.4　HttpSessionオブジェクト数の上限値の設定」を参照してください。

12.2.10　グローバルセッション情報のサイズの見積もり

ここでは，グローバルセッション情報を見積もるための機能について説明します。

グローバルセッション情報のサイズは，あらかじめ最大サイズを見積もって，DD（web.xml）に定義する必要があります。しかし，次の場合，セッション情報のサイズを見積もることは困難です。

直列化可能クラスのオブジェクトの場合，HTTPセッションに登録されたオブジェクトをシリアライズして作成される。

java.lang.Stringクラスのオブジェクトの場合，データの内容が非ASCII文字を含むときは，文字種によって文字列長が変わる。

グローバルセッション情報のサイズ見積もり機能は，開発環境でグローバルセッション情報のサイズを見積もるための機能です。グローバルセッション情報を作成してそのサイズをWebサーブレットログに出力します。この機能は開発環境で使用してください。このとき，SFOサーバのセットアップや設定，およびJ2EEサーバでのセッション情報の引き継ぎを行うための設定は不要です。

注意

グローバルセッション情報のサイズ見積もり機能は，運用環境では使用しないでください。この機能を使用すると，セッション情報の引き継ぎは無効となり，セッションフェイルオーバ機能が有効になりません。グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理については，「(2)　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理」を参照してください。

＜この項の構成＞

(1)　グローバルセッション情報のサイズ見積もり機能を使用したサイズの見積もり

(2)　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理

(3)　グローバルセッション情報のサイズ見積もり機能を有効にするための設定

(4)　グローバルセッション情報のサイズ見積もり機能使用時の注意事項

(1)　グローバルセッション情報のサイズ見積もり機能を使用したサイズの見積もり

この機能を使用すると，セッションフェイルオーバ機能が有効なWebアプリケーションに対してリクエストを送信するたびに，グローバルセッション情報のサイズを示すメッセージがWebサーブレットログに出力されます。グローバルセッション情報のサイズを出力するメッセージを次の表に示します。

表12-5　グローバルセッション情報のサイズを出力するメッセージ

メッセージID | 出力レベル | 出力するタイミング | 出力する内容
KDJE34260-I | Error | リクエストごと | リクエスト一つ分に対応するグローバルセッション情報のサイズ
KDJE34261-I | Error | HTTPセッションに登録されるセッション情報ごと | キー名称，区切り文字などを含むセッション情報一つ分に対応するデータのサイズ

各メッセージの出力例を次に示します。この例では，キー名称がAttribute1とAttribute2の二つのセッション情報からグローバルセッション情報を作成します。

KDJE34261-I　 The session information was serialized. （J2EE application = App01， context root = /test， request URL = http://host01/test/TestServlet， attribute name = Attribute1， class name = app.MyObject1※， size（byte） = 36， HTTP session ID = 01234567aaaabbbbccccddddeeeeffffserver1， global session ID = 0123456789abcdef01234567aaaabbbbccccddddeeeeffffserver1）
KDJE34261-I　 The session information was serialized. （J2EE application = App01， context root = /test， request URL = http://host01/test/TestServlet， attribute name = Attribute2， class name = app.MyObject2※， size（byte） = 25， HTTP session ID = 01234567aaaabbbbccccddddeeeeffffserver1， global session ID = 0123456789abcdef01234567aaaabbbbccccddddeeeeffffserver1）
KDJE34260-I　 The global session information was created. （J2EE application = App01， context root = /test， request URL = http://host01/test/TestServlet， size（byte） = 65， HTTP session ID = 01234567aaaabbbbccccddddeeeeffffserver1， global session ID = 0123456789abcdef01234567aaaabbbbccccddddeeeeffffserver1）

注　太字の部分に，グローバルセッション情報のサイズを見積もるための値が出力されます。各メッセージのsize（byte）に出力される内容の詳細については，表12-6を参照してください。また，各メッセージの詳細については，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

注※　クラス名に出力される内容は，属性値に対してjava.lang.ClassクラスのgetName()メソッドで得られた文字列です。なお，KDJE34261-Iのメッセージは，引き継ぎの対象であるセッション情報がHTTPセッションにない場合は出力されません。また，KDJE34260-Iのメッセージは，引き継ぎの対象であるセッション情報がHTTPセッションにあるかどうかに関係なく，HTTPセッションがあれば出力されます。

これらのメッセージに出力されるサイズ（size（byte））の値を基に，グローバルセッション情報のサイズを見積もります。見積もった値が，SFOサーバで冗長化できるグローバルセッション情報のサイズのデフォルト値（1,024バイト）を超えている場合は，DD（web.xml）でグローバルセッション情報の最大サイズの設定を変更する必要があります。グローバルセッション情報の最大サイズの設定方法については，「12.7.4(3)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）」を参照してください。

なお，KDJE34260-IおよびKDJE34261-Iのメッセージに出力されるサイズの値は，直列化可能クラスのオブジェクトを引き継ぎ対象としているかどうかによって異なります。KDJE34260-IおよびKDJE34261-Iのメッセージに出力されるサイズ（size（byte））の詳細を次の表に示します。

表12-6　KDJE34260-IおよびKDJE34261-Iのメッセージに出力されるサイズ（size（byte））の詳細

メッセージIDの種類
直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可（GSInfoTypeSerializableEnable）の設定

true
（直列化可能クラスのオブジェクトが引き継ぎ対象の場合）
false
（直列化可能クラスのオブジェクトが引き継ぎ対象外の場合）

KDJE34260-I
次の値を合計したサイズが出力されます。

HTTPセッションの有効期間情報の長さ

各属性のサイズ（KDJE34261-Iのメッセージで出力したサイズ）の合計

次の値を合計したサイズが出力されます。

HTTPセッションの有効期間情報の長さ

各属性を連結する区切り文字分のサイズ（各1バイト）

各属性のサイズ（KDJE34261-Iのメッセージで出力したサイズ）の合計

KDJE34261-I
次の値を合計したサイズが出力されます。

属性名をシリアライズしたデータのサイズ

属性値をシリアライズしたデータのサイズ

java.io.ObjectOutputStreamクラスが書き込むマジックナンバー，およびバージョン情報のデータ分のサイズ※1

次の値を合計したサイズが出力されます。

属性名のデータのサイズ

属性値のデータのサイズ

属性名と属性値の区切り文字のサイズ（1バイト）

byte型配列の管理情報の長さ※2

注※1　HTTPセッションに登録された属性のうち，最初にシリアライズされる属性のサイズにだけ含まれます。

注※2　byte型配列であるセッション情報が引き継ぎ対象の場合にだけ含まれます。

(2)　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理

グローバルセッション情報のサイズ見積もり機能を使用すると，グローバルセッション情報は作成しますが，セッション情報の引き継ぎ処理は無効となります。この場合，SFOサーバにセッション情報が冗長化されません。このほかにも，セッションフェイルオーバ機能で実行する処理で無効となるものがあります。グローバルセッション情報のサイズ見積もり機能使用時に，無効となる処理を次に示します。

J2EEサーバとSFOサーバとのネゴシエーション処理

SFOサーバへのグローバルセッション情報の冗長化

グローバルセッション情報の引き継ぎ処理

(3)　グローバルセッション情報のサイズ見積もり機能を有効にするための設定

グローバルセッション情報のサイズ見積もり機能を有効にする場合は，簡易構築定義ファイルと，DD（web.xml）で設定が必要になります。

簡易構築定義ファイルでのグローバルセッション情報のサイズ見積もり機能を有効にする設定
論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，webserver.sfo.check_size.modeパラメタに「on」を設定します。グローバルセッション情報のサイズ見積もり機能を無効にする場合は，このパラメタに「off」を設定してください。簡易構築ファイルについては，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。
webserver.sfo.check_size.modeパラメタに「on」を設定した場合，次に示すJ2EEサーバの設定は無効になります。

グローバルセッション情報を格納するSFOサーバの設定（webserver.sfo.sfo_serversパラメタ，およびwebserver.sfo.sfo_servers.<SFOフィルタのサーバ定義名>.namingパラメタ）

SFOサーバとの通信タイムアウトの設定（webserver.sfo.sfo_servers.<SFOフィルタのサーバ定義名>.connectionTimeoutパラメタ）

詳細については，マニュアル「Cosminexus　システム構築ガイド」のセッション情報の引き継ぎを行うJ2EEサーバの設定に関する説明を参照してください。

参考

Smart Composer機能を使用しない場合に，グローバルセッション情報のサイズ見積もり機能を有効にするときは，J2EEサーバ用ユーザプロパティファイル（usrconf.properties）でwebserver.sfo.check_size.modeキーに「on」を設定します。webserver.sfo.check_size.modeキーについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

DD（web.xml）でのセッションフェイルオーバ用フィルタの定義
セッションフェイルオーバ機能の設定をします。DD（web.xml）でのセッションフェイルオーバ用フィルタの定義については，「12.7.4　DDの定義」を参照してください。グローバルセッション情報のサイズ見積もり機能では，DD（web.xml）に定義したセッションフェイルオーバ機能の設定を基にグローバルセッション情報が作成されます。

(4)　グローバルセッション情報のサイズ見積もり機能使用時の注意事項

グローバルセッション情報のサイズ見積もり機能使用時の注意事項を次に示します。

セッションフェイルオーバ機能で引き継ぎ可能なサイズの上限は，HTTPセッションの有効期間情報などのサイズを含めて，1,048,576（1M）バイトです。グローバルセッション情報のサイズ見積もり機能使用時に，この上限値を超えた場合は，KDJE34262-Eのメッセージが出力されます。それ以降のグローバルセッション情報の作成処理は中断されます。この場合，KDJE34260-Iのメッセージは出力されません。メッセージについては，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

グローバルセッション情報のサイズ見積もり機能を有効にしている場合は，DD（web.xml）のGSInfosLengthMaxパラメタで，グローバルセッション情報の最大サイズを指定しても無視されます。このため，この機能を無効にして運用を開始する前に，KDJE34260-Iのメッセージに出力されたグローバルセッション情報のサイズが，GSInfosLengthMaxパラメタで指定したサイズを超えていないことを確認する必要があります。GSInfosLengthMaxパラメタについては，「12.7.4(3)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）」を参照してください。メッセージについては，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

グローバルセッション情報のサイズ見積もり機能を使用すると，Webアプリケーション開始時にJ2EEサーバとSFOサーバとのネゴシエーション処理は実行されません。このため，KDJE34216-Iのメッセージ（SFOサーバとの接続開始），およびKDJE34205-Iのメッセージ（SFOサーバとの接続完了）は出力されません。これらのメッセージの代わりに，KDJE34263-Iのメッセージ（グローバルセッション情報の冗長化無効）がエラーレベルで出力されます。各メッセージについては，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

同じHTTPセッションを使用する複数のリクエストを同時に送信した場合，処理中のリクエスト処理スレッドがあるときはグローバルセッション情報が作成されません。このため，グローバルセッション情報のサイズは見積もりません。この場合，最後のリクエスト処理スレッドが処理を終えた時にグローバルセッション情報のサイズを見積って，メッセージを出力します。

グローバルセッション情報のサイズ見積もり機能を有効にする場合，HttpSessionオブジェクト数の上限値の指定は不要です。HttpSessionオブジェクト数の上限値の設定については，「4.4.4　HttpSessionオブジェクト数の上限値の設定」を参照してください。

グローバルセッション情報のサイズ見積もり機能を有効にする場合，J2EEサーバが使用するメモリ量が増加します。J2EEサーバが使用するメモリ増加量を求める式を次に示します。

J2EEサーバが使用するメモリ増加量（メガバイト）
　＝10×1.5＋1.5※

注※　Webコンテナ単位の最大同時実行スレッド数が10以上の場合は，「Webコンテナ単位の最大同時実行スレッド数×1.5＋1.5」となります。Webコンテナ単位の最大同時実行スレッド数については，「4.18　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

12.3　HTTP Cookieによるグローバルセッションの制御

この節では，HTTP Cookieによるグローバルセッションの制御について説明します。

＜この節の構成＞

12.3.1　HTTP Cookieによる制御の概要

12.3.2　HTTP Cookieによる制御の前提条件

12.3.3　グローバルセッションIDを送信するHTTP Cookieの名称

12.3.4　サーブレットコンテキストへの属性追加

12.3.5　HTTP Cookieの有効期限

12.3.6　グローバルセッション破棄に伴うHTTP Cookie情報の破棄

12.3.1　HTTP Cookieによる制御の概要

HTTP Cookieによる制御では，WebクライアントからJ2EEサーバにリクエストを送信するときに，グローバルセッションIDを示すHTTP Cookieを送信します。

グローバルセッションIDは，HTTPレスポンスヘッダのSet-Cookieヘッダに設定され，Webクライアントに送信されます。この情報は，Webクライアントで，Cookie情報として管理されます。

J2EEサーバでは，グローバルセッションIDを含むHTTP Cookieを送信してきたWebクライアントに対して，グローバルセッションを継続します。

HTTP Cookieによるグローバルセッションの制御の概要を次の図に示します。

図12-15　HTTP Cookieによるグローバルセッションの制御の概要

Webクライアントからのリクエストを受信すると，J2EEサーバのJ2EEアプリケーション（Servlet／JSP）内で，HTTPセッションオブジェクトの作成とともに，グローバルセッションIDが発行されます。発行されたグローバルセッションIDは，Webクライアントに送信されるHTTPレスポンスヘッダに設定されます。同時に，SFOサーバに，グローバルセッション情報とともに格納されます。

12.3.2　HTTP Cookieによる制御の前提条件

HTTP Cookieによってグローバルセッションを制御する場合，Webクライアントとして，HTTP Cookieを使用できるクライアントが必要です。また，Webクライアントのブラウザでは，HTTP Cookieセッションを有効にする必要があります。

12.3.3　グローバルセッションIDを送信するHTTP Cookieの名称

グローバルセッションIDは，HTTPレスポンスヘッダのSet-Cookieヘッダに設定されます。使用されるHTTP Cookieの名称は，Webアプリケーション単位に設定できます。デフォルトの設定の場合，「GSESSIONID」になります。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，セッション情報の引き継ぎを行うJ2EEサーバの設定についての説明を参照してください。

注意

グローバルセッションIDを送信するHTTP Cookieの名称には，次の名称は指定できません。なお，大文字と小文字は区別されません。

HTTPセッションのセッションIDで使用するHTTP Cookieの名称である「JSESSIONID」

J2EEサーバのサーバID付加機能によってサーバIDを付加したHTTP Cookieの名称と同じ名称
サーバID付加機能については，「4.4.5　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

これらと同じ名称を使用すると，セッションフェイルオーバ用フィルタの初期化処理でエラーとなり，アプリケーションが開始できなくなります。なお，セッションフェイルオーバ用フィルタの初期化処理については，「12.6.3　J2EEアプリケーション開始時の処理」を参照してください。

12.3.4　サーブレットコンテキストへの属性追加

グローバルセッションIDが使用するHTTP Cookieの名称は，Webアプリケーション開始時に，サーブレットコンテキストの属性として，「com.cosminexus.software.was.sfo.GIDCookieName」の名称で登録されます。このとき，Webアプリケーションに，javax.servlet.ServletContextAttributeListenerインタフェースを実装したクラスが登録されていた場合，attributeAddedメソッドが呼び出されます。

12.3.5　HTTP Cookieの有効期限

グローバルセッションIDの送信に使用するHTTP Cookieの有効期限には，デフォルト値である-1が設定されています。このため，HTTP Cookieの情報は，ブラウザのプロセスの終了と同時に消失します。

12.3.6　グローバルセッション破棄に伴うHTTP Cookie情報の破棄

ブラウザ内のHTTP Cookie情報は，デフォルトの設定ではブラウザのプロセス終了とともに消失します。また，J2EEアプリケーション内で明示的にセッションを破棄することでグローバルセッション情報が破棄されると，ブラウザ内にあるHTTP Cookie情報も破棄されます。ブラウザ内のHTTP Cookie情報は，HTTPレスポンスヘッダに対して有効期限の切れたHTTP Cookieを設定することで破棄されます。

なお，タイムアウトによるグローバルセッション情報の破棄の場合は，ブラウザ内のHTTP Cookie情報は明示的に破棄されません。クライアントから無効になったグローバルセッションIDがHTTP Cookieとして送られてきたときに，クライアント内のHTTP Cookie情報が削除されます。

12.4　URL書き換えによるグローバルセッションの制御

この節では，URL書き換えによるグローバルセッションの制御について説明します。

＜この節の構成＞

12.4.1　URL書き換えによる制御の概要

12.4.2　URL書き換えによる制御の前提条件

12.4.3　グローバルセッションIDの送信に使用するURLのパスパラメタ

12.4.4　URL書き換えによって制御する場合の負荷分散

12.4.5　URL書き換えによって制御する場合の注意事項

12.4.1　URL書き換えによる制御の概要

URL書き換えによるグローバルセッションの制御方法は，HTTPセッションをURL書き換えによって制御する場合の方法と同じです。J2EEサーバがWebアプリケーション内のサーブレットやJSPでリンクURLをエンコードするときに，グローバルセッションIDを含めてエンコードします。

Webクライアントからの2回目以降のリクエスト送信時には，グローバルセッションIDを含めてエンコードされたURLが使用されます。J2EEサーバはリクエストヘッダに含まれるURLの情報を基に，グローバルセッションの制御を実行します。

URL書き換えによるグローバルセッションの制御の概要を次の図に示します。

図12-16　URL書き換えによるグローバルセッションの制御の概要

Webクライアントからのリクエストを受信すると，J2EEサーバのJ2EEアプリケーション（Servlet／JSP）内で，HTTPセッションオブジェクトの作成とともに，グローバルセッションIDが発行されます。発行されたグローバルセッションIDは，Webクライアントに送信されるHTTPレスポンスボディに設定されます。同時に，SFOサーバに，グローバルセッション情報とともに格納されます。

12.4.2　URL書き換えによる制御の前提条件

URL書き換えによる制御の前提条件について説明します。

URL書き換えによってグローバルセッションを制御するためには，WebアプリケーションがURL書き換えに対応している必要があります。WebアプリケーションがURL書き換えに対応していない場合，この制御方法ではグローバルセッションを制御できません。

URL書き換えに対応したWebアプリケーションの実装方法については，「12.7.2　URL書き換えによる制御をする場合のアプリケーションの実装」を参照してください。

なお，Smart Composer機能で構築する，セッションフェイルオーバ機能を使用したシステムでは，HTTP Cookieによるグローバルセッション情報の制御に対応していますが，URL書き換えによるグローバルセッション情報の制御には対応していません。グローバルセッション情報の制御にURL書き換えを使用するシステムは，運用管理ポータル，またはファイル編集とコマンド実行で構築してください。

12.4.3　グローバルセッションIDの送信に使用するURLのパスパラメタ

ここでは，グローバルセッションIDの送信に使用するURLのパスパラメタについて説明します。

グローバルセッションIDは，URLのパスパラメタ名として設定されます。使用されるパスパラメタ名は，Webアプリケーション単位に設定できます。デフォルトの設定の場合，「gsessionid」になります。パスパラメタ名は，大文字と小文字を区別されます。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，セッション情報の引き継ぎを行うJ2EEサーバの設定についての説明を参照してください。

注意

「jsessionid」は，大文字，小文字に関係なく，パスパラメタ名に指定できません。「jsessionid」は，HTTPセッションのセッションIDが，URL書き換えで使用するパスパラメタ名です。

これと同じ名称を使用すると，セッションフェイルオーバ用フィルタの初期化処理でエラーとなり，アプリケーションが開始できなくなります。

セッションフェイルオーバ用フィルタの初期化処理については，「12.6.3　J2EEアプリケーション開始時の処理」を参照してください。

Webコンテナは，リクエストのURLにグローバルセッションIDを示すパスパラメタが含まれる場合，そのIDをグローバルセッションIDとして扱い，グローバルセッションを引き継ぎます。

ただし，次の条件のどれかに該当する場合は，URLのパスパラメタに含まれるグローバルセッションIDが無効になります。

URLのパスパラメタに含まれるグローバルセッションIDが無効になる場合

リクエストのHTTP CookieにグローバルセッションIDが含まれている場合

リクエストのHTTP CookieにHTTPセッションのセッションIDが含まれている場合

リクエストのURLがHTTPセッションのセッションIDを表すパスパラメタを含んでいない場合

なお，Webアプリケーション内でURLを取得するServletAPIを使用した場合，取得できるURLにはグローバルセッションIDを示すパスパラメタは含まれません。URLに含まれるパスパラメタがグローバルセッションIDとして無効な場合も同様です。

リクエストURLを取得するServletAPIについては，「4.4.3(3)　URL書き換えをする場合に使用するAPIと注意事項」を参照してください。

12.4.4　URL書き換えによって制御する場合の負荷分散

ここでは，URL書き換えによってグローバルセッションを制御する場合に，負荷分散機で負荷分散を実現する方法について説明します。

HTTP Cookieを使用できないWebクライアントを使用する場合，負荷分散をするときにセッションを継続するための方法として，次のような方法があります。

サーバが埋め込む識別情報によってセッションを継続する方法

HTTPリクエストに含まれるクライアント個別の識別情報によってセッションを継続する方法

それぞれの方法について説明します。

＜この項の構成＞

(1)　サーバが埋め込む識別情報によるセッションの継続

(2)　HTTPリクエストに含まれるクライアント個別の識別情報によるセッションの継続

(1)　サーバが埋め込む識別情報によるセッションの継続

Webサーバまたはアプリケーションサーバがコンテンツに埋め込む識別情報を使用して，振り分け先を決め，セッションを継続する方法です。負荷分散機には，この識別情報を基にリクエストの振り分け先のサーバを決めるように設定します。

サーバが埋め込む識別情報は，一般的に次のフィールドに設定されます。

URLのパスの一部

URLのパスパラメタ

URLのクエリストリング

サーバから送信するHTMLのフォームのhiddenフィールド

セッションフェイルオーバ機能を使用している場合，識別情報として，サーバIDを使用できます。サーバIDを識別情報として使用する場合，アプリケーションの実装を変更しなくても，負荷分散時のセッションの継続が実現できます。サーバIDは，セッションIDの構成要素です。URLのパスパラメタに含まれています。サーバIDについては，「4.4.5　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

なお，サーバID以外を識別情報として使用する場合は，識別情報をコンテンツに埋め込む処理をアプリケーションで作りこむ必要があります。

サーバが埋め込む識別情報を使用して負荷分散を実行する処理の概要を次の図に示します。

図12-17　サーバが埋め込む識別情報を使用した負荷分散の概要

クライアント1は，リクエストを送信するときに，サーバ1から送信された識別情報をリクエストヘッダに含めて送信します。負荷分散機は，この識別情報を基に，振り分け先のサーバを選択します。これによって，セッションを継続できます。

(2)　HTTPリクエストに含まれるクライアント個別の識別情報によるセッションの継続

Webクライアントが送信するクライアント個別の識別情報に基づいて，振り分け先を決め，セッションを継続する方法です。負荷分散機には，この識別情報を基にリクエストの振り分け先のサーバを決めるように設定します。

クライアント個別の識別情報は，一般的に次のフィールドに設定されます。

HTTPリクエストのUser-Agentヘッダ

クライアントが独自に定義したHTTPリクエストヘッダ

なお，この方法を使用する場合，クライアント側の設定で，クライアント個別の識別情報をリクエストと同時に送信するように設定しておく必要があります。

クライアントの個別識別情報を使用して負荷分散を実行する処理の概要を次の図に示します。

図12-18　クライアントの個別識別情報を使用した負荷分散の概要

クライアント1は，リクエストを送信するときに，クライアント固有の識別情報をUser-Agentヘッダに含めて送信します。負荷分散機は，この識別情報を基に，振り分け先のサーバを選択します。これによって，セッションを継続できます。

12.4.5　URL書き換えによって制御する場合の注意事項

ここでは，URL書き換えによってグローバルセッションを制御する場合の注意事項について説明します。

＜この項の構成＞

(1)　リクエストラインの文字列長の算出と最大サイズの設定

(2)　URL書き換えのタイミング

(1)　リクエストラインの文字列長の算出と最大サイズの設定

URL書き換えによってグローバルセッションを制御する場合の，リクエストラインの最大サイズの設定について説明します。

URL書き換えによってグローバルセッションを制御する場合，URLのパスパラメタには，HTTPセッションのセッションIDとグローバルセッションIDが含まれます。HTTPリクエストのリクエストラインのサイズは，サーバ側およびクライアント側でそれぞれ上限があります。

URL書き換えによってグローバルセッションを制御する場合には，あらかじめリクエストラインの最大サイズを算出して，それを基にサーバおよびクライアントでのリクエストラインの最大サイズを設定しておく必要があります。

URL書き換えを使用する場合のリクエストラインの文字列長の算出方法，およびリクエストラインの最大サイズの設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，リクエストラインの最大サイズの設定についての説明を参照してください。

(2)　URL書き換えのタイミング

URL書き換えを実行するServlet APIを呼び出すと，URLのパスパラメタにはその時点で存在するグローバルセッションのグローバルセッションIDが付加されます。

このため，次の場合には，セッションを正しく継続できません。

セッションを作成する前にURL書き換えを実行するServlet APIを呼び出した場合

URL書き換えを実行するServlet APIを呼び出したあとでセッションを再作成した場合

12.5　グローバルセッションの制御方法が混在する場合のシステム構成

この節では，グローバルセッションの制御方法が混在する場合のシステム構成について説明します。なお，グローバルセッションの制御方法が混在しない場合のシステム構成については，マニュアル「Cosminexus　システム設計ガイド」の次の説明を参照してください。

SFOサーバを使用したセッション情報の引き継ぎを検討する場合のシステム構成

グローバルセッションの制御方法が混在するシステムでは，Webアプリケーションを制御方法ごとに分けるかどうかによって，システム構成および設定内容が異なります。

注意

URL書き換えによってセッションを制御する方法には，セッションハイジャックなどの脆弱性があるといわれています。URL書き換えを使用する場合，脆弱性への対策は，それぞれのシステムで確実に実施するようにしてください。

対策としては，次のようなものが考えられます。

HTTP Cookieを使用するWebアプリケーションでは，URL書き換えを抑止して，セッションIDをURLに付加しないようにする。

URL書き換えを実行するWebアプリケーションでは，HTTP CookieをサポートしているWebクライアントからのリクエストは処理しない。

なお，この節の説明は，URL書き換えでセッションを制御する場合の脆弱性について理解し，適切な対応をしていることを前提にした上で，次のシステム構成について説明しています。

HTTP Cookieを使用するWebアプリケーションと，URL書き換えを使用するWebアプリケーションを，それぞれ専用のWebアプリケーションとして使用する場合のシステム構成

HTTP Cookieを使用するWebアプリケーションと，URL書き換えを使用するWebアプリケーションを，専用のWebアプリケーションにはしないで，両方の制御方法で使用する場合のシステム構成

＜この節の構成＞

12.5.1　制御方法ごとにWebアプリケーションを分ける場合

12.5.2　制御方法ごとにWebアプリケーションを分けない場合

12.5.1　制御方法ごとにWebアプリケーションを分ける場合

ここでは，グローバルセッションの制御方法ごとにWebアプリケーションを分ける場合のシステム構成について説明します。

次の2種類のシステム構成について説明します。

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

＜この項の構成＞

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

(2)　リクエストの受信ポートをHTTP Cookieの使用可否によって分けない場合

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合のシステム構成の例を次に示します。

図12-19　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合（制御方法をWebアプリケーションごとに分けるとき）

この例の場合は，HTTP Cookieを使用できないWebクライアントからのリクエストを受信するJ2EEサーバと，HTTP Cookieを使用できるWebクライアントからのリクエストを受信するJ2EEサーバを分けて配置しています。

J2EEサーバ1およびJ2EEサーバ2は，HTTP Cookieを使用できないWebクライアントからのリクエストを受信するJ2EEサーバです。これらのJ2EEサーバには，URL書き換えによってセッションを制御するWebアプリケーションを配置します。

また，J2EEサーバ3およびJ2EEサーバ4は，HTTP Cookieを使用できるWebクライアントからのリクエストを受信するJ2EEサーバです。これらのJ2EEサーバには，HTTP Cookieを使用してセッションを制御するWebアプリケーションを配置します。

なお，グローバルセッションの制御方法に関係なく，J2EEサーバ1からJ2EEサーバ4までで作成したすべてのグローバルセッション情報は，SFOサーバ1（SFOServer01）で冗長化して管理します。

(2)　リクエストの受信ポートをHTTP Cookieの使用可否によって分けない場合

リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合のシステム構成の例を次に示します。

図12-20　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合（制御方法をWebアプリケーションごとに分けるとき）

この例の場合は，HTTP Cookieを使用できないWebクライアントからのリクエストを受信するJ2EEサーバと，HTTP Cookieを使用できるWebクライアントからのリクエストを受信するJ2EEサーバを分けないで配置しています。

この場合は，URL書き換えによってセッションを制御するWebアプリケーションとHTTP Cookieによってセッションを制御するWebアプリケーションの両方を，それぞれのJ2EEサーバに配置する必要があります。これは，HTTP CookieをサポートしていないWebクライアントと，HTTP CookieをサポートしているWebクライアントの両方からのリクエストが，それぞれのJ2EEサーバに対して送信されるためです。

なお，この場合，グローバルセッションの制御方法が異なるWebアプリケーションを一つのJ2EEアプリケーションにまとめて配置しても，異なるJ2EEアプリケーションとして配置してもかまいません。この例の場合は，同一のJ2EEアプリケーション内に異なる制御方法のWebアプリケーションを配置しています。

グローバルセッションの制御方法は，Webアプリケーションそれぞれに対して，設定してください。

なお，グローバルセッションの制御方法に関係なく，J2EEサーバ1およびJ2EEサーバ2で作成したすべてのグローバルセッション情報は，SFOサーバ1（SFOServer01）で冗長化して管理します。

12.5.2　制御方法ごとにWebアプリケーションを分けない場合

ここでは，グローバルセッションの制御方法ごとにWebアプリケーションを分けない場合のシステム構成として，次の2種類の構成について説明します。

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

＜この項の構成＞

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

(2)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

グローバルセッションの制御方法に関係なく同一のWebアプリケーションを使用する場合に，リクエストがWebクライアントのHTTP Cookieサポート有無によって分かれているときの，システムの構成例を次に示します。

図12-21　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合（制御方法をWebアプリケーションごとに分けないとき）

それぞれのJ2EEサーバに配置されたWebアプリケーションは，HTTP Cookieによるセッション制御，およびURL書き換えによるセッション制御の両方に対応しています。ただし，グローバルセッションの制御方法ごとにリクエストの受信ポートを分けているため，実際にはWebアプリケーションごとにWebクライアントの種類が決まります。このため，それぞれのWebアプリケーションには，リクエストを送信するWebクライアントがHTTP Cookieを使用できるかどうかに応じて，グローバルセッションの制御方法を設定します。

図12-21の場合は，J2EEサーバ1およびJ2EEサーバ2がHTTP Cookieを使用できないWebクライアントからのリクエストを受け付けます。また，J2EEサーバ3とJ2EEサーバ4がHTTP Cookieを使用できるWebクライアントからのリクエストを受け付けます。

ポイント

冗長化した同じWebアプリケーションに対して，異なるグローバルセッションの制御方法を設定した場合，同一のSFOサーバ上でのネゴシエーションは失敗します。このため，この例では，SFOサーバを，グローバルセッションの制御方法ごとに二つのプロセスとしています。

どのSFOサーバを使用するかは，それぞれのJ2EEサーバで設定します。接続先のSFOサーバの設定方法については，マニュアル「Cosminexus　システム構築ガイド」のセッション情報の引き継ぎを行うJ2EEサーバの設定の説明を参照してください。

また，同じWebアプリケーションに対して異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用したいときには，制御方法ごとに，J2EEアプリケーションの名称を変更する方法があります。セッションフェイルオーバ機能では，J2EEアプリケーションのアプリケーションが一致するかどうかによって，Webアプリケーションを同じアプリケーションであると判断します。このため，J2EEアプリケーションの名称を変更することで，異なるWebアプリケーションだと判断され，ネゴシエーションが失敗しなくなります。

異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用する場合のシステム構成例を次の図に示します。

図12-22　異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用する場合のシステム構成例

この例では，グローバルセッションの制御方法ごとに，J2EEアプリケーションの名称を変更しています。

(2)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

グローバルセッションの制御方法に関係なく同一のWebアプリケーションを使用する場合に，リクエストがWebクライアントのHTTP Cookieサポート有無によって分かれていないときの，システムの構成例を次に示します。

図12-23　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合（制御方法をWebアプリケーションごとに分けないとき）

この例の場合は，リクエストの受信ポートがグローバルセッションの制御方法によって分かれていないため，それぞれのWebアプリケーションには，HTTP Cookieを使用したリクエストとURL書き換えを利用したリクエストの両方が送信されます。これに対応するため，それぞれのWebアプリケーションでは，セッションの制御方法として「both」を設定します。

なお，グローバルセッションの制御方法に関係なく，J2EEサーバ1およびJ2EEサーバ2で作成したすべてのグローバルセッション情報は，SFOサーバ1（SFOServer01）で冗長化して管理します。

12.6　セッションフェイルオーバ機能で実施される処理

この節では，セッションフェイルオーバ機能で実施される処理について説明します。

参考

この節の12.6.1から12.6.6までの説明は，グローバルセッションの制御方法として，HTTP Cookieを使用した場合の処理について説明しています。

それぞれの処理でのグローバルセッションの制御処理については，URL書き換えを使用した場合も同様です。ただし，グローバルセッションの制御にURL書き換えを使用する場合，HTTP Cookieを使用する場合と比べて，次の処理が異なります。

グローバルセッションの制御に使用するグローバルセッションIDは，URLのパスパラメタから取得されます。

グローバルセッションの制御にHTTP Cookieを使用しないため，グローバルセッションを削除した場合，およびグローバルセッションが無効な場合に，グローバルセッションのHTTP Cookie情報の削除処理が実行されません。

HTTPセッションのURL書き換え処理が実行されるときに，HTTPセッションのセッションIDに加えて，グローバルセッションIDが付加されます。なお，HTTPセッションのURL書き換え処理は，WebアプリケーションでのURLエンコード用のServlet APIの呼び出しを実行した場合に実行されます。

これらの相違点を含めた処理の流れについては，「12.6.7　URL書き換えを使用する場合の処理の違い」を参照してください。

＜この節の構成＞

12.6.1　セッションフェイルオーバ機能で処理が実施されるタイミング

12.6.2　J2EEサーバ起動時の処理

12.6.3　J2EEアプリケーション開始時の処理

12.6.4　リクエスト実行時の処理

12.6.5　HttpSessionオブジェクトの有効期限が切れた場合の処理

12.6.6　無効なグローバルセッションIDが送られた場合の処理

12.6.7　URL書き換えを使用する場合の処理の違い

12.6.1　セッションフェイルオーバ機能で処理が実施されるタイミング

セッションフェイルオーバ機能では，次に示す時点でそれぞれ処理が実施されます。

J2EEサーバ起動時の処理
J2EEサーバ起動時には，SFOサーバの状態を監視するためのスレッドが作成されます。

J2EEアプリケーション開始時の処理
J2EEアプリケーション開始時には，セッションフェイルオーバ用フィルタの初期化処理が実施されます。

リクエスト実行時の処理
リクエスト処理実施時には，セッションフェイルオーバ情報の格納，更新，削除がされます。

セッションフェイルオーバ機能で実施される処理について，以降の項で説明します。

また，HttpSessionオブジェクトの有効期限が切れた場合の処理，無効なグローバルセッションIDが送られた場合の処理についても説明します。

12.6.2　J2EEサーバ起動時の処理

J2EEサーバでは，SFOサーバの状態を監視するためのスレッドを作成します。これを，SFOサーバ監視スレッドといいます。SFOサーバ監視スレッドは，Webアプリケーションごとに一つ作成され，各Webアプリケーションで使用するSFOサーバのヘルスチェックを実施します。ヘルスチェックは，SFOサーバアプリケーションで用意している，コネクションの状態監視用のビジネスメソッドを呼び出して実施します。コネクションの状態監視のインターバルは3秒です。また，コネクションの状態監視用のビジネスメソッドの呼び出しのタイムアウトには，SFOサーバとの通信タイムアウト時間に設定した時間が適用されます。タイムアウトが発生した場合，SFOサーバはダウンしていると判断され，リトライはされません。

なお，SFOサーバアプリケーションは，Cosminexusで提供しています。SFOサーバアプリケーションの概要については，「12.2.4(1)　SFOサーバ」を参照してください。また，SFOサーバ監視スレッドの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

12.6.3　J2EEアプリケーション開始時の処理

ここでは，J2EEアプリケーション開始時の処理の流れについて説明します。また，J2EEアプリケーション開始時に実行されるJ2EEサーバとSFOサーバのネゴシエーション処理についても説明します。

＜この項の構成＞

(1)　J2EEアプリケーション開始時の処理の流れ

(2)　J2EEサーバとSFOサーバのネゴシエーションで使用される情報

(3)　ネゴシエーションが失敗した場合の対処

(1)　J2EEアプリケーション開始時の処理の流れ

J2EEアプリケーション実行前に，セッションフェイルオーバ用フィルタの初期化処理が実施されます。初期化処理では，次の内容が実施されます。

web.xmlのセッションフェイルオーバ機能に関する設定の妥当性がチェックされます。
設定内容に問題がある場合は，フィルタの初期化処理でエラーとなり，Webアプリケーションは開始されません。

web.xmlの設定に問題がない場合，J2EEサーバからSFOサーバへの接続が実施されます。
接続先のSFOサーバは，J2EEサーバごとに設定されています。設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，セッション情報の引き継ぎを行うJ2EEサーバの設定についての説明を参照してください。
なお，接続に失敗した場合は，次の点を確認してください。

SFOサーバが起動しているか

SFOサーバとの通信路に障害が発生していないか

J2EEサーバに設定されている，SFOサーバが登録されているCORBAネーミングサービスのIPアドレスまたはポート番号に誤りがないか

SFOサーバとして使用するJ2EEサーバの起動コマンドである"cjstartsv"コマンドの実行時に"-nosecurity"オプションが指定されているか

SFOサーバとの接続に成功すると，SFOサーバとのネゴシエーションが実施されます。
web.xmlで設定した内容に問題がない場合，SFOサーバとのネゴシエーションが実施されます。ネゴシエーション処理に使用される情報については，「(2)　J2EEサーバとSFOサーバのネゴシエーションで使用される情報」を参照してください。
ネゴシエーションに失敗した場合の対処については，「(3)　ネゴシエーションが失敗した場合の対処」を参照してください。

セッションフェイルオーバ用フィルタの初期化処理完了後，Webアプリケーションの開始時にセッションフェイルオーバ機能の設定内容を示すKDJE34265-Iのメッセージが出力されます。

ポイント

グローバルセッションの制御にHTTP Cookieを使用するWebアプリケーションの場合，ネゴシエーションが成功すると，web.xmlで設定したグローバルセッションIDが使用するHTTP Cookie名称が，サーブレットコンテキストに属性として登録されます。属性の名称は，「com.hitachi.software.was.sfo.GIDCookieName」です。

このとき，Servlet仕様で提供されるリスナ，およびjavax.servlet.ServletContextAttributeListenerインタフェースを実装したリスナをWebアプリケーションに定義していた場合，attributeAddedメソッドの呼び出しがされます。

グローバルセッションの制御方法の設定，およびHTTP Cookieの名称の設定方法については，マニュアル「Cosminexus　システム構築ガイド」の，セッションフェイルオーバ用フィルタの設定についての説明を参照してください。

●注意事項

SFOサーバの稼働状態に異常があったり，SFOサーバが稼働するマシンのメモリ使用量に異常があったりして，60秒以内にネゴシエーション処理が完了しなかった場合，J2EEサーバはSFOサーバとのネゴシエーションに失敗したと判断して，SFOサーバとの接続を切断します。
なお，SFOサーバ側でネゴシエーションが成功していても，J2EEサーバとの接続が切断されていることを検知した時点で，グローバルセッション情報の保持を終了します。
なお，J2EEサーバの接続検知については，「12.2.4(1)　SFOサーバ」を参照してください。

SFOサーバとJ2EEサーバとのネゴシエーションが成功すると，SFOサーバには，Webアプリケーションの設定情報が登録されます。Webアプリケーションの情報を変更して，SFOサーバに接続すると，SFOサーバには変更前のWebアプリケーションの情報があるため，ネゴシエーションに失敗します。そのため，SFOサーバに登録されたWebアプリケーションの設定情報を削除してからWebアプリケーションを開始する必要があります。なお，Webアプリケーションの設定情報の削除については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

SFOサーバが起動していない状態でJ2EEアプリケーションを開始していた場合，またはJ2EEサーバとの接続中にSFOサーバを再起動した場合，J2EEサーバは，起動または再起動後のSFOサーバに接続します。SFOサーバとの接続完了後，アプリケーション開始と同様のネゴシエーションが実行されます。
なお，このときにネゴシエーションに失敗したWebアプリケーションは，以降，SFOサーバへの接続はしません。この場合，セッションフェイルオーバ機能が無効なまま処理が続行されます。
セッションフェイルオーバ機能を有効にするためには，J2EEアプリケーションを一度停止してください。該当するWebアプリケーションのセッションフェイルオーバ機能に関する設定を正しくした上で，J2EEアプリケーションを再度開始してください。

(2)　J2EEサーバとSFOサーバのネゴシエーションで使用される情報

J2EEアプリケーションの開始処理の中で実施される，ネゴシエーションで使用される情報について説明します。

セッションフェイルオーバ用フィルタは，ネゴシエーション処理を実行するときに，Webアプリケーションの情報をSFOサーバに送信します。SFOサーバでは，送信された情報のうちネゴシエーションで使用する情報について，冗長化されているほかのJ2EEサーバのWebアプリケーションの情報と比較します。これらの情報が，ほかのJ2EEサーバのWebアプリケーションの情報と異なる場合，フィルタの初期化処理でエラーとなり，Webアプリケーションは開始されません。

ネゴシエーション処理で使用される情報として，セッションフェイルオーバ用フィルタによってSFOサーバに送信される情報を次の表に示します。また，その中でほかのJ2EEサーバと同じ設定である必要がある情報も示します。

表12-7　ネゴシエーション処理で使用される情報

セッションフェイルオーバ用フィルタによってSFOサーバに送信される情報 | ほかのJ2EEサーバと同じ設定である必要がある情報
J2EEアプリケーション名 | ○
Webアプリケーションのコンテキストルート名 | －
HttpSession数の上限値 | ○
セッション情報の最大サイズ | ○
DDに定義されたHTTPセッションの有効期間 | ○
グローバルセッションの制御方法 | ○
グローバルセッションIDの送信に使用するHTTP Cookieの名称 | 　 ○※1
グローバルセッションIDの送信に使用するURLのパスパラメタ名 | 　 ○※2
SFOサーバ内のロック待ちでのタイムアウト時間 | ○
書き換え可能グローバルセッション情報のキー名称 | ○
読み込み専用グローバルセッション情報のキー名称 | ○
J2EEサーバに設定されたHttpセッションのセッションIDへ付加するサーバID | －
byte型配列であるセッション情報の引き継ぎ許可 | 　○※3
直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可 | ○

（凡例）

○：ほかのJ2EEサーバと同じ設定である必要がある。

－：ほかのJ2EEサーバと同じ設定でなくてもかまわない。

注※1

グローバルセッションの制御方法がHTTP Cookieを使用する方法の場合に同じ設定である必要があります。URL書き換えを使用する場合，同じ設定でなくてもかまいません。

注※2

グローバルセッションの制御方法がURL書き換えを使用する方法の場合に同じ設定である必要があります。HTTP Cookieを使用する場合，同じ設定でなくてもかまいません。

注※3

直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とする場合は，同じ設定でなくてもかまいません。

また，セッションフェイルオーバ用フィルタによってSFOサーバに送信される情報のうち，HttpSessionのセッションIDに付けられるサーバIDは，J2EEサーバに対してそれぞれ一意となる値が設定されている必要があります。このため，すでに接続されているJ2EEサーバに設定されたサーバIDと同じ値である場合は，ネゴシエーションが失敗し，Webアプリケーションは開始されません。

(3)　ネゴシエーションが失敗した場合の対処

ネゴシエーションで使用する情報の不一致によってネゴシエーションに失敗した場合，J2EEサーバのメッセージログ，およびSFOサーバのメッセージログにエラーメッセージが出力されます。エラーの原因となった個所の設定を見直し，再度Webアプリケーションをデプロイしてください。

なお，ネゴシエーション中に，次に示す要因でエラーが発生した場合，ネゴシエーションは失敗しますが，セッションフェイルオーバ機能が無効な状態でWebアプリケーションの処理は続行されます。

SFOサーバのメモリが不足している

ネゴシエーション処理のタイムアウトが発生した

ネゴシエーション中にSFOサーバまたは通信路に障害が発生した

必要な機能をSFOサーバがサポートしていない（SFOサーバのバージョンがJ2EEサーバのバージョンと合っていない）

エラーが発生した場合は，J2EEサーバおよびSFOサーバで出力されたメッセージログとSFOサーバの状態を確認して，エラーの原因を取り除いてください。

なお，エラー発生後，J2EEサーバはWebアプリケーションの処理を続行しながら，定期的にSFOサーバへの接続を試みます。J2EEサーバがSFOサーバに接続ができた場合，再度ネゴシエーション処理が実行されます。

ネゴシエーションが成功すると，セッションフェイルオーバ機能が有効になります。

12.6.4　リクエスト実行時の処理

ここでは，リクエスト実行時のグローバルセッションフェイルオーバ用フィルタの処理と，グローバルセッション情報の格納，更新，削除処理について説明します。

＜この項の構成＞

(1)　リクエスト実行時のセッションフェイルオーバ用フィルタの処理

(2)　グローバルセッション情報の格納処理

(3)　グローバルセッション情報の更新処理

(4)　グローバルセッション情報の削除処理

(1)　リクエスト実行時のセッションフェイルオーバ用フィルタの処理

セッションフェイルオーバ用フィルタでは，リクエスト実行前には，グローバルセッション情報をロックし，必要に応じて引き継ぎ処理をします。また，リクエスト処理後には，グローバルセッション情報を格納または更新して，ロックを解除します。

(a)　グローバルセッション情報のロックについて

異なるJ2EEサーバから同じグローバルセッション情報を同時に更新されることを抑止するため，セッションフェイルオーバ用フィルタでは，SFOサーバ上のグローバルセッション情報のロックをします。

J2EEアプリケーションでのリクエスト処理で，SFOサーバのグローバルセッション情報を使用すると，SFOサーバ上のグローバルセッション情報はロックされます。
このとき，別のJ2EEサーバがグローバルセッション情報を使用しようとすると，ロックの解除待ちとなります。

グローバルセッション情報を使用しているJ2EEアプリケーションでリクエスト処理が完了すると，SFOサーバでのロックが解除されます。
ロック解除時に，ロックの解除待ちとなっているJ2EEアプリケーションがある場合は，ロックが解除されたグローバルセッション情報を使用してリクエスト処理をします。

グローバルセッション情報にロックを設定することによって，J2EEアプリケーションでのダブルクリックなどによって二重送信されたリクエストが別のJ2EEサーバに送信された場合の誤動作も防止できます。

なお，ロックの解除待ちには，タイムアウトを設定できます。解除待ちでタイムアウトした場合，該当するグローバルセッション情報は使用できなくなります。このとき，セッションは破棄され，新規リクエストとしてJ2EEアプリケーションを呼び出します。

(b)　セッション情報の引き継ぎ処理について

セッション情報の引き継ぎ処理では，新規にHttpSessionオブジェクトを生成し，セッション情報を登録します。Servlet仕様で提供されているセッションに関する次の三つのリスナをJ2EEアプリケーションで定義している場合，リスナへの通知が実施されます。

呼び出されるリスナの種類について，システム内で発生するイベントごとに次の表に示します。

表12-8　呼び出されるリスナの種類

システム内で発生するイベント
呼び出されるリスナ
HttpSessionオブジェクト，およびグローバルセッションへの操作

ログイン
HttpSessionListener

HttpSessionオブジェクトの作成

グローバルセッションの作成

J2EEアプリケーション内でのセッションの使用
HttpSessionAttributeListener
HttpSessionBindingListener

HttpSessionオブジェクトへのセッション情報の格納

HttpSessionオブジェクトからのセッション情報の削除

ログアウト
HttpSessionListener
HttpSessionAttributeListener
HttpSessionBindingListener

HttpSessionオブジェクトの破棄

グローバルセッションの破棄

障害発生によるグローバルセッション情報の引き継ぎ

HttpSessionオブジェクトの作成

HttpSessionオブジェクトへのグローバルセッション情報の格納

ほかのサーバに引き継がれたHttpSessionオブジェクトの有効期限切れ

HttpSessionオブジェクトの削除

(2)　グローバルセッション情報の格納処理

グローバルセッションは，HTTPセッションと同時に生成されます。グローバルセッションが生成されると，グローバルセッション情報も生成されます。このとき，HttpSessionオブジェクトに対してセッション情報が未登録である場合も，グローバルセッション情報は生成されます。ただし，セッション情報が未登録であるという情報が生成されます。

J2EEアプリケーションでHttpSessionオブジェクトの作成後，グローバルセッション情報がSFOサーバに格納されるまでの処理について，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「12.6.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図12-24　グローバルセッション情報の格納処理

J2EEアプリケーション内の処理で，HttpSessionオブジェクトが作成されます。
javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドが呼び出され，HttpSessionオブジェクトが作成されます。

作成されたHttpSessionオブジェクトに対応する，グローバルセッションIDが発行されます。

SFOサーバに新しいグローバルセッション情報を追加します。追加されたグローバルセッション情報はロックされます。

HTTPレスポンスのヘッダのSet-Cookieヘッダに，グローバルセッションIDが追加されます。

SFOサーバにグローバルセッション情報を送信し，格納します。

(3)　グローバルセッション情報の更新処理

J2EEアプリケーションでセッションを使用し，グローバルセッション情報が更新されると，SFOサーバ内のグローバルセッション情報も更新する必要があります。

なお，グローバルセッション情報の更新中は，グローバルセッション情報にロックが掛かります。ロックが掛かると，ほかのJ2EEサーバからのグローバルセッション情報の操作ができなくなります。

グローバルセッション情報の更新処理について，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「12.6.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図12-25　グローバルセッション情報の更新処理

SFOサーバ上のグローバルセッション情報にロックが掛かります。
J2EEアプリケーションの処理の前に，グローバルセッション情報にロックが掛かります。

J2EEアプリケーション内の処理でHttpSessionオブジェクトを使用すると，HttpSessionオブジェクトに登録されたグローバルセッション情報が更新されます。

J2EEアプリケーション処理の終了後，SFOサーバにセッション情報を送信します。

SFOサーバ上のグローバルセッション情報を最新に更新します。

SFOサーバ上のグローバルセッション情報のロックを解除します。

(4)　グローバルセッション情報の削除処理

J2EEアプリケーション内で，javax.servlet.http.HttpSessionインタフェースのinvalidateメソッドが呼び出される場合の，明示的なグローバルセッション情報の削除の処理について，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「12.6.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図12-26　グローバルセッション情報の明示的な削除

SFOサーバ上のグローバルセッション情報にロックが掛かります。
J2EEアプリケーションの処理の前に，グローバルセッション情報にロックが掛かります。

J2EEアプリケーション内の処理で，明示的にHttpSessionオブジェクトを破棄します。
javax.servlet.http.HttpSessionインタフェースのinvalidateメソッドを呼び出して，オブジェクトを破棄します。

J2EEアプリケーション処理の終了後，SFOサーバにグローバルセッション情報の削除要求を送信します。

SFOサーバ上のグローバルセッション情報が削除されます。

クライアント上にあるグローバルセッションIDのHTTP Cookie情報を削除するように設定されます。
HTTPレスポンスヘッダに，HTTP Cookieを期限切れでセットします。ただし，J2EEアプリケーションでHTTPレスポンスがすでにコミットされていた場合は，期限切れでのセットは実施されません。

クライアント上のグローバルセッションIDのHTTP Cookie情報が削除されるのは，レスポンスがコミットされていなかった場合だけです。J2EEアプリケーションからセッションフェイルオーバ用フィルタに処理が戻った時点で，すでにレスポンスがコミットしている場合は，クライアント上のグローバルセッションIDのHTTP Cookie情報は削除されません。この場合，次に送信するリクエストにグローバルセッション情報がCookieとして付けられた時点で，HTTP Cookie情報の削除処理が実施されます。

12.6.5　HttpSessionオブジェクトの有効期限が切れた場合の処理

HttpSessionオブジェクトに設定されている有効期限が切れるまでの間に，HttpSessionオブジェクトを使用するリクエストが発生しなかった場合は，HttpSessionオブジェクトはJ2EEサーバによって削除されます。また，このとき，HttpSessionオブジェクトに対応づけられたSFOサーバ上のグローバルセッション情報も削除されます。

有効期限が切れているときには，グローバルセッション情報がロックされているかどうかにかかわらず，HttpSessionオブジェクトは削除されます。このため，J2EEサーバでグローバルセッション情報を使用中の場合や，J2EEサーバのダウンによってロックされたままのグローバルセッション情報も，有効期限が切れると削除されます。

HttpSessionオブジェクトの有効期限が切れた場合の処理の流れについて，次の図に示します。

図12-27　HttpSessionオブジェクトの有効期限が切れた場合の処理

有効期限が切れると，HttpSessionオブジェクトは削除されます。
J2EEサーバ内では，HttpSessionオブジェクトの有効期限が監視されています。有効期限が切れると，HttpSessionオブジェクトが削除されます。

有効期限の切れたSFOサーバ上のグローバルセッション情報も削除されます。
SFOサーバ内では，グローバルセッション情報の有効期限が監視されています。有効期限が切れると，SFOサーバ上のグローバルセッション情報が削除されます。

12.6.6　無効なグローバルセッションIDが送られた場合の処理

SFOサーバにない，グローバルセッションIDがリクエストとして送られてきた場合の処理の流れについて，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「12.6.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図12-28　無効なグローバルセッションIDが送られた場合の処理

グローバルセッション情報のロックが失敗します。
SFOサーバに対して，グローバルセッション情報のロック要求がありますが，SFOサーバ内にない，無効なグローバルセッションIDが送信されてきたため，ロックが失敗します。

HTTPレスポンスヘッダに，Set-Cookieヘッダを期限切れでセットします。
クライアントにあるグローバルセッションIDのHTTP Cookie情報を削除するよう，Set-Cookieヘッダを期限切れでセットします。

HttpSessionオブジェクトがある場合は，書き換え可能グローバルセッション情報が削除されます。

なお，3.の処理以降，J2EEアプリケーション内の処理で，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドが呼び出されると，グローバルセッションが新規に作成されます。

12.6.7　URL書き換えを使用する場合の処理の違い

ここでは，URL書き換えを使用する場合の処理と，HTTP Cookieを使用する場合の処理との違いについて説明します。

グローバルセッションの制御方法としてURL書き換えを使用している場合，HTTP Cookieを使用して制御している場合の処理に加えて，URL書き換えのための処理として，次の処理が追加されます。

URLのパスパラメタの解析

WebアプリケーションでのServlet APIの呼び出しによる，グローバルセッションIDを含むURLのエンコード

また，グローバルセッションを削除した場合，およびグローバルセッションが無効な場合に，グローバルセッションのHTTP Cookie情報の削除処理は実行されません。

URL書き換えする場合に追加される処理について，次の図に示します。

図12-29　URL書き換えする場合に追加される処理

各ポイントでの処理内容について説明します。説明の番号は図中の番号と対応しています。なお，1.，3.，4.の処理が，URL書き換えの場合だけに実行される処理です。

J2EEサーバによって，Webクライアントから送信されたリクエストURLのパスパラメタが解析されます。

セッションフェイルオーバ用フィルタによって，SFOサーバ上のグローバルセッション情報がロックされます。
なお，この処理は，グローバルセッションの制御方法に関係なく実行されます。

J2EEアプリケーション内のWebアプリケーションで，URL書き換えのためのエンコードを実行するServlet APIが呼び出されます。
この処理は，URL書き換えの場合だけ実行されます。

J2EEサーバによって，グローバルセッションIDがURLにエンコードされます。なお，エンコードはHTTPセッションのセッションIDとともに実行されます。

セッションフェイルオーバ用フィルタによって，SFOサーバ上のグローバルセッション情報が更新され，グローバルセッション情報のロックが解除されます。
なお，この処理は，グローバルセッションの制御方法に関係なく実行されます。

12.7　セッションフェイルオーバ機能を使用するアプリケーションの実装

この節では，セッションフェイルオーバ機能を使用するアプリケーションを開発するときに留意することについて説明します。また，セッションフェイルオーバ機能を使用する場合，アプリケーションでは，DD（web.xml）を編集して，セッションフェイルオーバ機能に必要な設定をする必要があります。この設定方法についても説明します。

＜この節の構成＞

12.7.1　実装時の留意事項

12.7.2　URL書き換えによる制御をする場合のアプリケーションの実装

12.7.3　アプリケーションを実行するときに追加される属性

12.7.4　DDの定義

12.7.1　実装時の留意事項

セッションフェイルオーバ機能を使用するアプリケーションを開発する場合に，留意する点について説明します。

＜この項の構成＞

(1)　セッションフェイルオーバ用フィルタの呼び出し順序

(2)　JSPで暗黙的に作成されるHTTPセッションの扱い

(3)　セッション管理に使用する情報の選択

(4)　障害発生時の動作を考慮した処理の実装

(5)　HTTPセッションの破棄に伴う動作

(6)　セッション情報の引き継ぎが発生した場合の認証情報の扱い

(7)　セッションフェイルオーバ機能使用によるサーブレットAPIの動作

(8)　JSPでの<jsp:useBean>タグの使用

(1)　セッションフェイルオーバ用フィルタの呼び出し順序

セッションフェイルオーバ用フィルタは，サーブレットフィルタとして提供されます。セッションフェイルオーバ用フィルタは，ほかのサーブレットフィルタよりも前に呼び出される必要があります。HTTPレスポンス圧縮フィルタ，およびユーザ作成のフィルタよりも前に配置してください。

(2)　JSPで暗黙的に作成されるHTTPセッションの扱い

セッションフェイルオーバ機能を有効にしたアプリケーションでは，セッションを作成すると必ずグローバルセッションIDが発行され，グローバルセッション情報を使用しないサーブレットまたはJSPであっても，「グローバルセッション情報が存在しない」という情報がSFOサーバに冗長化されます。

JSPでは，デフォルトでHttpSessionオブジェクトが作成されます。メモリの使用量や，SFOサーバとの通信による負荷を考慮し，セッションを必要としないJSPでは明示的にHttpSessionオブジェクトを作成しない設定にしてください。HttpSessionオブジェクトを作成しない設定には，pageディレクティブのsession属性を使用してください。

(3)　セッション管理に使用する情報の選択

HTTPセッションのセッション管理には，グローバルセッション情報を使用するようにしてください。

セッションフェイルオーバ機能では，障害発生時にグローバルセッション情報は引き継げますが，HTTPセッションは新しく作成されます。このため，HTTPセッションのセッションIDはグローバルセッション情報の引き継ぎの前後で異なります。したがって，HTTPセッションのセッションIDを基に制御を実行するアプリケーションは，グローバルセッション情報を基に制御を実行するように変更する必要があります。

(4)　障害発生時の動作を考慮した処理の実装

セッションフェイルオーバ機能を使用するアプリケーションでは，障害発生時にグローバルセッション情報の引き継ぎ処理や，書き換え可能グローバルセッション情報の削除処理が発生します。

アプリケーションでは，これらを想定した処理を実装する必要があります。

(a)　セッション情報の引き継ぎを考慮した処理

J2EEサーバやWebサーバに障害が発生すると，リクエストが別のJ2EEサーバに転送されて，セッション情報が引き継がれます。アプリケーションが引き継ぎ先のJ2EEサーバで問題なく業務を続けるためには，必要な情報をすべてグローバルセッション情報として設定しておく必要があります。

グローバルセッション情報として設定できる情報については，「12.2.3　グローバルセッション情報」を参照してください。また，グローバルセッション情報の引き継ぎについては，「12.2.6　サーバの状態とグローバルセッション情報の引き継ぎ」を参照してください。

(b)　HTTPセッションに同一のオブジェクトが複数回登録されている場合を考慮した処理

HttpSessionオブジェクトに同じオブジェクトが複数登録されていた場合に，引き継ぎ後のHttpSessionオブジェクトに登録されるオブジェクトが異なるので，注意が必要です。

一つのHttpSessionオブジェクトに同じオブジェクトが複数登録されている場合
一つのHttpSessionオブジェクトに，同じjava.lang.Stringクラスのオブジェクトが複数登録されている場合に，グローバルセッション情報の引き継ぎが発生すると，複数登録していたオブジェクトは別々のオブジェクトとして生成されます。
一つのHttpSessionオブジェクトに同じオブジェクトが複数登録されている場合の引き継ぎの例を次の図に示します。

図12-30　一つのHttpSessionオブジェクトに同じオブジェクトが複数登録されている場合の引き継ぎの例

この図では，J2EEサーバ1上のHttpSessionオブジェクトに，java.lang.Stringクラスのオブジェクトであるセッション情報Bが複数登録されています。J2EEサーバ1で障害が発生して，J2EEサーバ2へセッション情報が引き継がれた場合，J2EEサーバ2上のHttpSessionオブジェクトには，複数登録されていたセッション情報Bが，それぞれ別のセッション情報B-1とセッション情報B-2として生成されます。セッション情報B-1およびセッション情報B-2は，インスタンスは異なりますが，内容は同じです。

異なるHTTPセッションに同一のオブジェクトが登録されている場合
グローバルセッション情報はHTTPセッション単位に作成されます。直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象に設定している場合も，HTTPセッションごとに引き継ぎます。
異なるHttpSessionオブジェクトで同一のオブジェクトをセッション情報として共有している場合に，グローバルセッション情報の引き継ぎが発生したときは，オブジェクトが共有されません。別々のオブジェクトとして生成されます。
異なるHttpSessionオブジェクトに同一のオブジェクトが登録されている場合の引き継ぎの例を次の図に示します。

図12-31　異なるHttpSessionオブジェクトに同一のオブジェクトが登録されている場合の引き継ぎの例

この図では，J2EEサーバ1上のHttpSessionオブジェクト1およびHttpSessionオブジェクト2で，同一のオブジェクトのセッション情報Cを共有しています。J2EEサーバ1で障害が発生して，J2EEサーバ2へセッション情報が引き継がれた場合，J2EEサーバ2上のHttpSessionオブジェクト1およびHttpSessionオブジェクト2には，共有されていたセッション情報Cが，それぞれ別のセッション情報C-1とセッション情報C-2として生成されます。セッション情報C-1およびセッション情報C-2は，インスタンスは異なりますが，内容は同じです。

(c)　書き換え可能グローバルセッション情報の削除を考慮した処理

SFOサーバに障害が発生した場合など，書き換え可能グローバルセッション情報の削除が発生したとき，HttpSessionオブジェクトには読み込み専用グローバルセッション情報とグローバルセッション情報でないセッション情報が残ります。

リクエスト処理を実行する前に，書き換えグローバルセッション情報が削除されていないかどうかを確認する処理を実行して，削除されている場合には適切な処理を実行してください。

例えば，グローバルセッション情報が次のように設定されている場合があります。

読み込み専用グローバルセッション情報にログイン情報が設定されている。

書き換え可能グローバルセッション情報に作業中の情報が設定されている。

この場合，書き換え可能グローバルセッション情報が削除されると，HttpSessionオブジェクトに登録されたセッション情報の内容はログイン直後の状態に戻ります。この状態から業務をやり直すためには，オブジェクトを再作成する処理や，javax.servlet.http.HttpServletResponseインタフェースのsendRedirectメソッドを使用してログイン直後のページに戻す処理などが必要になります。

J2EEアプリケーション内での書き換え可能グローバルセッション情報が削除されているかどうかは，HttpSessionオブジェクトに登録した書き換え可能グローバルセッション情報があるかどうかで確認できます。確認した結果，あるはずの書き換え可能グローバルセッション情報がなくなっていた場合，書き換え可能グローバルセッション情報が削除されたと判断できます。

(5)　HTTPセッションの破棄に伴う動作

HTTPセッションを破棄するアプリケーション内でレスポンスのコミットを実行しても，クライアント上のグローバルセッションIDのHTTP Cookie情報は削除されません。この場合，コミット後にリクエストを送信するとき，グローバルセッションIDがリクエストヘッダのCookieとして付加されて，J2EEサーバ，SFOサーバのメッセージログに次のログメッセージが出力されます。

J2EEサーバで出力されるメッセージ
KDJE34234-Ｗ（出力レベル：Warning）

SFOサーバで出力されるメッセージ
KDJE34017-Ｗ（出力レベル：Warning）

ただし，これらのメッセージが出力された場合も，J2EEサーバ，SFOサーバでの実際のリクエスト処理，およびセッションフェイルオーバ機能への影響はありません。なお，クライアント上のグローバルセッションIDのHTTP Cookie情報を削除する処理は，この時点で実行されます。以降のリクエスト処理ではこのHTTP Cookieは付加されません。

また，javax.servlet.http.HttpServletResponseインタフェースのsendRedirectメソッドを使用した場合も，レスポンスがコミットされて，リダイレクト先アドレスへのアクセス時にKDJE34234-Wのメッセージが出力されます。このとき，リダイレクト先アドレスがFORM認証を使用しているページへのアドレスであった場合，J2EEサーバのメッセージログにはKDJE34234-Wのメッセージではなく，KDJE34229-Wのメッセージ（出力レベル：Warning）が出力されます。ただし，この場合も，認証機能およびセッションフェイルオーバ機能への影響はありません。

(6)　セッション情報の引き継ぎが発生した場合の認証情報の扱い

Webコンテナで使用できるログイン認証には，サーブレットAPIで定義されているフォーム認証による認証と，HTTPが定義しているBasic認証による認証があります。

セッションフェイルオーバ機能を使用するシステムで認証機能を使用している場合，J2EEサーバまたはWebサーバの障害発生時には次のように動作します。

サーブレットAPIで定義されているフォーム認証によって認証処理をしている場合
障害発生時に，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合は，再度認証が必要です。

Basic認証によって認証処理をしている場合
障害発生時に，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合でも，再度認証する必要はありません。グローバルセッション情報は正常に引き継がれ，業務を続けられます。

(7)　セッションフェイルオーバ機能使用によるサーブレットAPIの動作

セッションフェイルオーバ機能を使用する場合と，使用しない場合とで動作が変わるサーブレットAPIがあります。次に，セッションフェイルオーバ機能によって動作に変更があるAPIおよび注意点を示します。

表12-9　セッションフェイルオーバ機能と関係するサーブレットAPI

項番 | クラス名またはインタフェース名※1 | API名 | 注意点
1 | ServletContext | getAttributeNames | HTTP Cookieによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションIDに使用するHTTP Cookie名称をサーブレットコンテキストに属性として登録します。グローバルセッションIDは，セッションフェイルオーバ用フィルタ開始時に初期化パラメタに設定されたIDです。getAttributeNamesで取得できる属性名にこの属性の名称が含まれます。セッションフェイルオーバ用フィルタが登録する属性については，「12.7.3　アプリケーションを実行するときに追加される属性」を参照してください。
2 | ServletContextAttributeListener | attributeAdded | HTTP Cookieによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションIDに使用するHTTP Cookie名称をサーブレットコンテキストに属性として登録するために，javax.servlet.ServletContextAttributeListenerクラスのattributeAddedメソッドが呼び出されます。グローバルセッションIDは，セッションフェイルオーバ用フィルタ開始時に初期化パラメタに設定されたIDです。サーブレットコンテキストに登録する属性については，マニュアル「12.7.3　アプリケーションを実行するときに追加される属性」を参照してください。
3 | HttpServletRequest | getCookies | HTTP Cookieによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションが発行されると，グローバルセッションIDがCookieヘッダにセットされます。HTTP Cookieの名称は，GIDCookieNameパラメタに指定した値です。
4 | getHeader
5 | getHeaderNames
6 | getHeaders
7 | getSession | HTTPセッション作成時に，J2EEサーバのHTTPセッション数に余裕がある場合でも，SFOサーバでグローバルセッション数が上限に達すると，IllegalStateException例外が発生します。
8 | HttpServletResponse | encodeRedirectURL | URL書き換えによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションIDをURLに含めてエンコードします。グローバルセッションIDは，HTTPセッションIDとともにエンコードされます。この処理は必要に応じて実行されます。
9 | encodeURL
10 | encodeRedirectUrl※2
11 | encodeUrl※2
12 | HttpSession | getAttribute | 書き換え可能グローバルセッション情報の削除処理が発生すると，Webコンテナによって属性が追加されます。Webコンテナが追加する属性については，「12.7.3　アプリケーションを実行するときに追加される属性」を参照してください。
13 | getAttributeNames
14 | getCreationTime | 引き継ぎが発生すると，引き継ぎ処理によってHttpSessionオブジェクトが作成されるため，引き継ぎ発生前と異なる値が返されます。
15 | getId※3
16 | getLastAccessedTime | 引き継ぎ発生後，初回のリクエスト時には前回アクセスの時刻を返すことができません。
17 | isNew※4 | 引き継ぎによって，HttpSessionオブジェクトが作成されると，戻り値が「true」となります。
18 | HttpSessionAttributeListener | リスナについては，「12.6.4　リクエスト実行時の処理」を参照してください。
19 | HttpSessionBindingListener
20 | HttpSessionListener
21 | HttpServletRequestWrapper | 動作については，javax.servlet.http.HttpServletRequestインタフェースの動作を参考にしてください。

注※1

クラス名およびインタフェース名は，「javax.servlet.http.」を省略しています。

注※2

Servlet 2.1仕様で非推奨とされているAPIです。

注※3

HTTPセッションのセッションIDを基に制御が行われるWebアプリケーションは，グローバルセッション情報を基に制御が行われるように変更する必要があります。

注※4

isNewメソッドの戻り値によって制御が行われるWebアプリケーションでは，HttpSessionオブジェクトを新規に作成した場合，必ず登録するセッション情報を設けてください。そのセッション情報を読み込み専用グローバルセッション情報とし，isNewメソッドを使用する代わりにそのセッションがHttpSessionオブジェクトに登録されているかどうかで新規セッションかどうかを判断するようにしてください。

(8)　JSPでの<jsp:useBean>タグの使用

JSPで<jsp:useBean>タグを使用する時，scope属性を"session"とすることで，JavaBeansがHttpSessionオブジェクトの属性として登録されます。

<jsp:useBean>タグのscope属性を"session"とする場合には，次の設定が必要になります。

引き継ぎ対象とするセッション情報のデータ型に，直列化可能クラスのオブジェクトを設定する。

<jsp:useBean>タグのidタグに設定した名称が引き継ぎ対象となるように，idタグに設定した名称をグローバルセッション情報として使用する情報（キー）に設定する。

12.7.2　URL書き換えによる制御をする場合のアプリケーションの実装

URL書き換えによってグローバルセッションを制御する場合の，Webアプリケーションの実装方法について説明します。

＜この項の構成＞

(1)　使用するServlet API

(2)　JSPの記述例

(1)　使用するServlet API

Webアプリケーションを実装する際には，次に示すServlet APIを使用して実装してください。

なお，グローバルセッションIDのエンコードは，グローバルセッションが存在している場合に，Webアプリケーション内でこれらのServlet APIが呼び出され，HTTPセッションのセッションIDのエンコードが必要と判断されたときにだけ実行されます。

サーブレットやJSP内で同一アプリケーションへのリンク先URLをレスポンスに出力する場合，次のAPIを使用してリンク先URLを出力してください。

javax.servlet.http.HttpServletResponseインタフェースのencodeURL(java.lang.String url)メソッド

javax.servlet.http.HttpServletResponseインタフェースのencodeUrl(java.lang.String url)メソッド

ただし，encodeUrl(java.lang.String url)メソッドは非推奨のAPIです。

サーブレットやJSP内でjavax.servlet.http.HttpServletResponseインタフェースのsendRedirect()メソッドによって同一アプリケーションへのリダイレクトを行う場合は，リダイレクト先のURLを次のAPIを使用して取得してください。

javax.servlet.http.HttpServletResponseインタフェースのencodeRedirectURL(java.lang.String url)メソッド

javax.servlet.http.HttpServletResponseインタフェースのencodeRedirectUrl(java.lang.String url)メソッド

ただし，encodeRedirectUrl(java.lang.String url)メソッドは非推奨のAPIです。

これらのServletAPIを使用しないでWebアプリケーションを実装している場合，グローバルセッションIDのURL書き換えは実行されません。この場合，HTTPセッションおよびグローバルセッションは継続されません。

(2)　JSPの記述例

URL書き換えによってグローバルセッションを制御する場合のJSPの記述例，および出力されるレスポンスの内容を示します。

JSPの記述内容

<a href="<%= response.encodeURL("nextPage.jsp") %>">link</a>

なお，この例は，次の前提に従っています。

HTTPセッションのセッションIDは"xxxxx"である。

グローバルセッションIDは"yyyyy"である。

グローバルセッションIDの送信に使用するURLのパスパラメタ名は"gsessionid"である。

出力されるレスポンスの内容

<a href="nextPage.jsp;jsessionid=xxxxx;gsessionid=yyyyy">link</a>

注意

次に示すように，URL書き換えを使用しないでパスパラメタを設定するアプリケーションの場合，グローバルセッションのURL書き換えが実行されません。この場合，セッションフェイルオーバ機能が有効になりません。

URL書き換えによるグローバルセッションの制御が有効にならない例（JSPの場合）

<a href="nextPage.jsp;jsessionid=<%=session.getId()%>">link</a>

12.7.3　アプリケーションを実行するときに追加される属性

セッションフェイルオーバ機能を使用するアプリケーションでは，動作するために必要な情報をWebコンテナから取得するために，javax.servlet.ServletContextオブジェクトの属性を使用します。

アプリケーションの起動時には，次の表に示す属性が，Webコンテナによってjavax.servlet.ServletContextオブジェクトの属性に追加されます。

表12-10　WebコンテナによってServletContextの属性に追加される属性

キー名称 | 値の説明
com.hitachi.software.web.application-dd.J2eeApplicationName | J2EEアプリケーション名
com.hitachi.software.web.application-dd.contextRoot | コンテキストルート名
com.hitachi.software.web.dd.session-max-inactive-interval | DD（web.xml）に設定されたHTTPセッションの有効期間※1
com.hitachi.software.web.hitachi-runtime-dd.http-session-max-number | HTTPセッション数の上限値設定機能で設定されたHTTPセッション数の上限値
com.hitachi.software.web.dd.filter-class | DD（web.xml）の最上部に定義されたフィルタマッピングのクラス名
com.hitachi.software.web.dd.url-pattern | DD（web.xml）の最上部に定義されたフィルタマッピングのURLパターン※2※3

注※1

DD（web.xml）にHTTPセッションの有効期間を設定しなかった場合は，デフォルトの値が登録されます。

注※2

<url-pattern>タグでなく，<servlet-name>タグが設定された場合は追加されません。

注※3

DD（web.xml）内にセッションフェイルオーバ用フィルタを使用するフィルタマッピングの定義が複数あった場合，URLパターンの代わりに「<multi mapped>」の文字列が登録されます。

これらの属性の追加はセッションフェイルオーバ機能の有効，無効に関係なく，J2EEサーバモードでWebアプリケーションを開始する時には必ず実行されます。

なお，javax.servlet.ServletContextAttributeListenerインタフェースを実装したクラスを使用した場合は，上記属性の追加，削除するためのattributeAddedメソッド，attributeRemovedメソッド，およびattributeReplacedメソッドの呼び出しは実行されません。

12.7.4　DDの定義

次に示すディレクトリに，セッションフェイルオーバ機能で使用するフィルタ定義およびフィルタマッピングの定義が記述されたテンプレートのDD（web.xml）が用意してあります。

テンプレート格納ディレクトリ

<Cosminexusのインストールディレクトリ>¥CC¥sfo¥sfo_war

このファイルをコピーしてWebアプリケーションのDDを作成します。すでに存在するWebアプリケーションにセッションフェイルオーバ機能を適用する場合，テンプレートからDDにセッションフェイルオーバ用フィルタのフィルタ定義およびフィルタマッピングの定義をコピーし，必要な定義を記述します。

テンプレートの内容を次に示します。

図12-32　テンプレートの内容（セッションフェイルオーバ機能のDD）（1/2）

図12-33　テンプレートの内容（セッションフェイルオーバ機能のDD）（2/2）

次の定義の値は固定となります。テンプレートの値をそのまま使用してください。

フィルタ定義の<filter-name>タグと<filter-class>タグ

フィルタマッピング定義の<filter-name>タグと<url-pattern>タグ

注意

フィルタマッピング（<filter-mapping>タグ）を定義する場合，次の点に注意してください。

フィルタマッピング定義を複数定義する場合，セッションフェイルオーバ用のフィルタマッピング定義を最初に記述してください。最初に記述しない場合はアプリケーションを開始できません。

セッションフェイルオーバ用のフィルタマッピング定義は複数定義しないでください。複数定義した場合はアプリケーションを開始できません。

WebアプリケーションのバージョンがServlet 2.4の場合，<filter-mapping>タグの要素の<dispatcher>タグを指定しないでください。<dispatcher>タグで「FORWARD」，「INCLUDE」，および「ERROR」を指定した場合，Webアプリケーションの開始時にセッションフェイルオーバ用フィルタの初期化段階でエラーが発生し，アプリケーションは開始できません。

＜この項の構成＞

(1)　DDに定義する項目

(2)　グローバルセッション情報として使用する情報（GSInfoKey-RW，GSInfoKey-R）

(3)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）

(4)　グローバルセッション情報を格納するSFOサーバ（SFOServerName）

(5)　グローバルセッションの制御方法（GSessionControl）

(6)　グローバルセッションIDの送信に使用するHTTP Cookieの名称（GIDCookieName）

(7)　グローバルセッションIDの送信に使用するURLのパスパラメタ名（GIDURLParamName）

(8)　グローバルセッション情報のロック待ちタイムアウト時間（LockTimeout）

(9)　引き継ぎ可能なセッション情報のデータ型（GSInfoTypeByteArrayEnable，GSInfoTypeSerializableEnable）

(10)　DDの定義例（HTTP Cookieによる制御の場合）

(11)　DDの定義例（URL書き換えによる制御の場合）

(12)　DDの定義例（制御方法にbothを指定する場合）

(1)　DDに定義する項目

グローバルセッション情報として登録する情報や，使用するSFOサーバの情報などは，<filter>タグ内の初期化パラメタである，<init-param>タグ内を編集して定義します。

参考

<init-param>タグ内の情報は，アプリケーションをJ2EEサーバにインポートしたあとで，サーバ管理コマンドを使用して設定することもできます。

DDの<init-param>タグ内に定義する内容を次の表に示します。なお，<param-value>に指定する値の詳細については，(2)以降で説明します。

表12-11　DDの<init-param>タグ内に定義する内容

定義する項目
<param-name>タグに指定する要素
<param-value>に指定する内容

グローバルセッション情報として使用する情報
書き換え可能な情報
GSInfoKey-RW
HTTPセッションに登録する情報の中から，グローバルセッション情報として登録する情報を選択して定義します。
文字列を指定します。※1
「;」（半角セミコロン）を含んだキーは指定できません。
複数指定する場合は，「;」（半角セミコロン）で区切って指定します。
なお，同じ名称のキーは複数回指定できません。GSInfoKey-RWとGSInfoKey-Rに同じ名称を指定することもできません。※2
また，「*」（半角アスタリスク）だけを指定すると，HTTPセッションに登録されたすべての情報がグローバルセッション情報として登録されます。ただし，複数指定の中に「*」を指定している場合，「*」はキーとして扱われます。「*」は，GSInfoKey-RWとGSInfoKey-Rの両方に指定できません。
GSInfoKey-RWとGSInfoKey-Rに指定する値と引き継ぎ対象となるセッション情報の関係については，「(2)　グローバルセッション情報として使用する情報（GSInfoKey-RW，GSInfoKey-R）」を参照してください。

読み込み専用の情報
GSInfoKey-R

グローバルセッション情報の最大サイズ
GSInfosLengthMax
グローバルセッション情報の最大サイズ（文字）を指定します。
DDには，3～1048576の整数値で指定します。

グローバルセッション情報を格納するSFOサーバ
SFOServerName
使用するSFOサーバ名を指定します。
DDには，J2EEサーバ用のusrconf.propertiesのwebserver.sfo.sfo_serversキーで指定されているSFOサーバの中から選択して指定します。

グローバルセッションの制御方法
GSessionControl
グローバルセッション情報の制御方法を指定します。
指定できる値は，「cookie」，「url-rewriting」または「both」です。
このパラメタに指定した値については，大文字と小文字が区別して扱われます。

グローバルセッションIDの送信に使用するHTTP Cookieの名称
GIDCookieName
グローバルセッションIDを送信するHTTP Cookieの名称を指定します。
DDには，16文字までの文字列で指定します。
使用できる文字は，A～Z，a～zおよび0～9の英数字です。ただし，HTTP Cookieの名称の識別では，大文字と小文字は区別されません。
また，HTTPセッションのセッションIDが使用する「JSESSIONID」やJ2EEサーバが使用するサーバIDと同じ値は指定できません。

グローバルセッションIDの送信に使用するURLのパスパラメタ名
GIDURLParamName
グローバルセッションIDの送信に使用するURLのパスパラメタ名を指定します。
DDには，16文字までの文字列で指定します。
使用できる文字は，A～Z，a～zおよび0～9の英数字です。URLのパスパラメタの識別では，大文字と小文字は区別されます。
また，URLのパスパラメタ名には，「jsessionid」を指定できません。「jsessionid」は，HTTPセッションのセッションIDの送信に使用する文字列です。なお，「jsessionid」の識別では，大文字と小文字は区別されません。
また，Webアプリケーションで独自のURLのパスパラメタを使用している場合は，Webアプリケーションで使用しているURLのパスパラメタと異なる名称をこのパラメタに，指定してください。

グローバルセッション情報のロック待ちタイムアウト時間
LockTimeout
SFOサーバでのロック待ちタイムアウト時間を秒単位で指定します。
DDには，1～3600の整数値を指定します。

引き継ぎ可能なセッション情報のデータ型
byte型配列であるセッション情報の引き継ぎ許可
GSInfoTypeByteArrayEnable
byte型配列のセッション情報を引き継ぎ対象とするかどうかを指定します。

true

byte型配列のセッション情報を引き継ぎ対象とします。

false

byte型配列のセッション情報を引き継ぎ対象としません。byte型配列を使用した場合は，グローバルセッション情報の更新時にエラーとなります。

trueおよびfalse以外の文字列を指定した場合は，デフォルト値のfalseが適用されます。
このパラメタに指定した値について，大文字，小文字は区別されません。また，このパラメタに指定した値は，GSInfoTypeSerializableEnableパラメタに「true」を指定している場合は無視されます。

直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可
GSInfoTypeSerializableEnable
直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とするかどうかを指定します。

true

直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とします。

false

直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象としません。

このパラメタに指定した値について，大文字，小文字は区別されません。

注※1　キー名称の先頭と最後の空白は省略されます。省略された結果，""（文字列）になったキー名称は無視されます。

注※2　同じキー名称を指定した場合，Webアプリケーションを開始できません。

これらの定義項目は，使用する機能によって設定するかどうかが異なります。使用する機能ごとのDDの<init-param>タグ内に定義する要素のデフォルト値と設定要否を次の表に示します。

表12-12　使用する機能ごとのDDの<init-param>タグ内に定義する要素のデフォルト値と設定要否

<param-name>タグに指定する要素 | デフォルト値 | 使用する機能
セッションフェイルオーバ機能の設定要否 | グローバルセッション情報のサイズ見積もり機能の設定要否
GSInfoKey-RW | なし | 任意※1 | 任意※1
GSInfoKey-R | なし | 任意※1 | 任意※1
GSInfosLengthMax | 1024 | 任意 | 無効※2
SFOServerName | webserver.sfo.sfo_serversキーに指定されているSFOサーバ数によって異なります。※3 | 任意 | 無効※4
GSessionControl | cookie | 任意 | 任意
GIDCookieName | GSESSIONID | 任意 | 任意
GIDURLParamName | gsessionid | 任意 | 任意
LockTimeout | 60 | 任意 | 無効※2
GSInfoTypeByteArrayEnable | false | 任意 | 任意
GSInfoTypeSerializableEnable | false | 任意 | 任意

（凡例）

任意：省略できることを示します。省略した場合はデフォルトの値が設定されます。

無効：指定しても無効になることを示します。設定した値は使用されません。

注※1　GSInfoKey-RWとGSInfoKey-Rの両方を省略することはできません。

注※2　パラメタに不正な値を指定した場合はエラーとなり，Webアプリケーションは開始できません。

注※3　SFOフィルタのサーバ定義名に指定されているSFOサーバ名が一つの場合は，そのSFOサーバ名がデフォルトになります。複数指定されている場合は，先頭に指定されているSFOサーバ名がデフォルトになります。SFOフィルタのサーバ定義名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.sfo.sfo_serversパラメタで指定します。

注※4　指定したSFOサーバ名が，簡易構築定義ファイルで指定されているSFOフィルタのサーバ定義名にない場合もエラーになりません。SFOフィルタのサーバ定義名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.sfo.sfo_serversパラメタで指定します。

なお，グローバルセッションの制御方法によって，指定する必要があるパラメタが異なります。

グローバルセッションの制御方法と指定が必要なパラメタの対応を次の表に示します。

表12-13　グローバルセッションの制御方法と指定が必要なパラメタの対応

<param-name>タグに指定する要（パラメタ） | HTTP Cookieによって制御する場合 | URL書き換えによって制御する場合
GSInfoKey-RW | ○ | ○
GSInfoKey-R | ○ | ○
GSInfosLengthMax | ○ | ○
SFOServerName | ○ | ○
GSessionControl | ○※ | ◎
GIDCookieName | ○ | －
GIDURLParamName | － | ○
LockTimeout | ○ | ○
GSInfoTypeByteArrayEnable | ○ | ○
GSInfoTypeSerializableEnable | ○ | ○

（凡例）

◎：指定が必要です。省略できません。

○：指定が必要です。省略した場合は，デフォルト値が有効になります。

－：指定は不要です。

注※

デフォルト値は「cookie」です。このため，省略した場合もHTTP Cookieによってグローバルセッションが制御されます。

注意

グローバルセッション情報として使用する情報は，一つ以上指定する必要があります。それ以外の値の定義は任意です。デフォルト値がある項目については，省略するとデフォルト値が使用されます。

パラメタ値を省略する場合，<init-param>タグごと省略してください。次のようにタグを残して値だけを省略した場合，空文字列を指定したと判断されて，エラーになります。
間違った省略方法の例
　　　　：
<init-param>
<param-name>GSInfosLengthMax</param-name>
<param-value></param-value>
</init-param>
　　　　：

セッションフェイルオーバ機能を使用するためのDDの定義内容は，冗長化したJ2EEサーバにデプロイした同一アプリケーションで同じ必要があります。定義内容が不正な場合，アプリケーション開始処理がエラーになります。メッセージは，KDJE34202-Eのメッセージが出力されます。

(2)　グローバルセッション情報として使用する情報（GSInfoKey-RW，GSInfoKey-R）

HTTPセッションに登録する情報の中から，グローバルセッション情報として登録する情報を選択して定義します。HTTPセッションに登録する情報すべてをグローバルセッション情報として引き継ぐ場合は，「*」を指定します。

グローバルセッション情報は，書き換え可能グローバルセッション情報または読み込み専用グローバルセッション情報として指定します。HTTPセッションに登録後，変更が必要なセッション情報は，書き換え可能グローバルセッション情報に指定します。HTTPセッションに登録後，変更が不要なセッション情報は，読み込み専用グローバルセッションに指定します。グローバルセッション情報については，「12.2.3　グローバルセッション情報」を参照してください。

書き換え可能グローバルセッション情報の場合は，パラメタのGSInfoKey-RWで指定します。読み込み専用グローバルセッション情報の場合は，GSInfoKey-Rで指定します。

GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定した文字列は，「;」（半角セミコロン）で分割したあと，それぞれの値の先頭と最後の連続した空白文字※を削除した結果がキー名称として使用されます。空白文字※を削除した結果が「""」（空文字列）になったキー名称は無視されます。GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定した文字列に有効となるキー名称がない場合は，KDJE34202-Eのメッセージが出力され，エラーとなります。

注※　空白文字とは，半角スペース，タブ，LF（ラインフィード（0x0a）），CR（キャリッジリターン（0x0d））またはFF（フォームフィード（0x0c））のことを指します。

GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定する値と引き継ぎ対象となるセッション情報の関係を次の表に示します。

表12-14　GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定する値と引き継ぎ対象となるセッション情報の関係

項番 | パラメタに指定する値 | 指定例 | 指定例で引き継ぎ対象となるセッション情報
1 | 「;」（半角セミコロン）で区切った複数の文字列 | "user;roll" | "user"および"roll"のキーで登録されたセッション情報
2 | キーの前，またはあとに空白を含んだ文字列 | "user△;△roll△△; password" | "user"，"roll"，および"password"のキーで登録されたセッション情報（空白文字を削除した結果，キー名称となります）
3 | キーの途中に空白を含んだ文字列 | "user;user△id" | "user"および"user△id"のキーで登録されたセッション情報
4 | 「*」（半角アスタリスク）だけ | "*" | HTTPセッションに登録されたすべてのセッション情報※
5 | 前，またはあとに空白を含んだ「*」（半角アスタリスク） | "△△*△△" | HTTPセッションに登録されたすべてのセッション情報※（空白文字を削除した結果，「*」となります）
6 | 「*」（半角アスタリスク）を含んだ複数の文字列 | "user;*" | "user"および"*"のキーで登録されたセッション情報
7 | 「*」（半角アスタリスク）以外のキーが空文字列 | "*;" | "*"のキーで登録されたセッション情報
8 | 空文字列 | "" | エラーとなり，KDJE34202-Eのメッセージが出力されます。
9 | 「△」だけ | "△△" | エラーとなり，KDJE34202-Eのメッセージが出力されます（空白文字を削除した結果，空文字列となります）。
10 | 「;」（半角セミコロン）だけ | ";;" | エラーとなり，KDJE34202-Eのメッセージが出力されます（有効となるキー名称がありません）。
11 | 「△」を「;」（半角セミコロン）で区切った文字列 | ";△;" | エラーとなり，KDJE34202-Eのメッセージが出力されます（空白文字を削除した結果，有効となるキー名称がありません）。

（凡例）△：空白文字を示します。

注※　GSInfoKey-RWパラメタで「*」を指定している場合に，GSInfoKey-Rパラメタでキーを指定しているときは，GSInfoKey-Rパラメタに指定したキーで登録されたセッション情報は含まれません。また，GSInfoKey-Rパラメタで「*」を指定している場合に，GSInfoKey-RWパラメタでキーを指定しているときは，GSInfoKey-RWパラメタに指定したキーで登録されたセッション情報は含まれません。

(3)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）

SFOサーバに格納するグローバルセッション情報の一つ当たりの最大サイズを指定します。SFOサーバで冗長化できるグローバルセッション情報のサイズは，デフォルトでは1,024バイトまでです。冗長化するグローバルセッション情報の文字数がこの値を超える場合は，定義した内容を変更する必要があります。

また，グローバルセッション情報の最大サイズを小さくすると，SFOサーバで使用するメモリサイズを少なくできます。実際に格納するグローバルセッション情報の最大サイズを考慮して，適切なサイズを指定してください。

注意

グローバルセッション情報のサイズ見積もり機能を有効にしている場合，GSInfosLengthMaxパラメタの指定は無視されます。このため，グローバルセッション情報のサイズ見積もり機能を無効にして運用を開始する前に，KDJE34260-Iのメッセージで出力されたグローバルセッション情報のサイズが，GSInfosLengthMaxパラメタで指定したサイズを超えていないことを確認してください。

グローバルセッション情報のサイズは，次の式で算出できます。直列化可能クラスのオブジェクトであるセッション情報の引き継ぎを許可しているかどうか（GSInfoTypeSerializableEnableパラメタの指定）によって，見積もり式が異なります。

(a)　直列化可能クラスのオブジェクトであるセッション情報の引き継ぎを許可していない場合

グローバルセッション情報のサイズ＝
　（各グローバルセッション情報のキーの文字列長合計）
　＋（各HTTPセッションに登録されたオブジェクトのサイズの最大長合計）
　＋（区切り文字数）※1
　＋（HTTPセッションの有効期間情報の長さ）※2

注※1

区切り文字数は，2×（設定したグローバルセッション情報の数）－1で算出できます。これは，区切り文字には，グローバルセッション情報間の区切り文字と，各グローバルセッション情報のキーと値の区切り文字が含まれるためです。

注※2

HTTPセッションの有効期間情報の長さは4バイトです。

ただし，グローバルセッション情報がjava.lang.Stringクラスの場合，文字列をUTF-8の文字エンコーディングでURLエンコードして冗長化します（URLエンコードにはjava.net.URLEncoderクラスを使用します）。そのため，グローバルセッション情報の文字列長は，セッション情報の文字列長と異なることがあります。文字種ごとのURLエンコード後の文字列長を次の表に示します。

表12-15　文字種ごとのURLエンコード後の文字列長

項番
文字種
文字列長（バイト）

1
ASCII文字
英数字（0～9およびa～Z）および次に示す特殊文字

ピリオド（.）

ハイフン（-）

アスタリスク（*）

アンダースコア（_）

1

上記以外のASCII文字
3

2
JIS X 0201のすべての非ASCII文字
6または9

3
JIS X 0208のすべての非ASCII文字
6または9

4
JIS X 0212のすべての非ASCII文字
6または9

5
Windows-31Jの拡張文字
9

6
Unicodeの補助文字（基本多言語面以外の文字）
12

7
JIS X 0213の第3，第4水準漢字
9または12

このため，グローバルセッション情報のサイズは，セッション情報の文字列を文字種ごとにURLエンコード後の文字列長に変換してから，それらを合計して見積もる必要があります。

例えば，n種類のグローバルセッション情報を指定した場合は，グローバルセッション情報の最大サイズは次の式で算出できます。

グローバルセッション情報のサイズ＝
　（グローバルセッション情報1のキーの文字列長）
　＋（HTTPセッションに登録されたオブジェクト1の最大サイズ）
　＋（グローバルセッション情報2のキーの文字列長）
　＋（HTTPセッションに登録されたオブジェクト2の最大サイズ）
　　：
　＋（グローバルセッション情報nのキーの文字列長）
　＋（HTTPセッションに登録されたオブジェクトnの最大サイズ）
　＋（2×n-1）
　＋4

参考

グローバルセッション情報のサイズ見積もり機能を使用すると，HTTPセッションに含まれるセッション情報ごとのバイト数が出力できます。出力されたサイズ情報を参考にして，グローバルセッション情報の最大サイズに適切な値を設定してください。グローバルセッション情報のサイズ見積もり機能については，「12.2.10　グローバルセッション情報のサイズの見積もり」を参照してください。

(b)　直列化可能クラスのオブジェクトであるセッション情報の引き継ぎを許可している場合

グローバルセッション情報のサイズ＝
　（各グローバルセッション情報のキーのシリアライズ後のバイト数合計）
　＋（各HTTPセッションに登録されたオブジェクトのシリアライズ後のバイト数合計）
　＋（HTTPセッションの有効期間情報の長さ）※

注

シリアライズは，一つのHTTPセッションに対して，一つのjava.io.ObjectOutputStreamのオブジェクトを使用して実施します。

注※

HTTPセッションの有効期間情報の長さは4バイトです。

例えば，n種類のグローバルセッション情報を設定した場合は，グローバルセッション情報の最大サイズは次の式で算出できます。

グローバルセッション情報のサイズ＝
　（グローバルセッション情報1のキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクト1のシリアライズ後のバイト数）
　＋（グローバルセッション情報2のキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクト2のシリアライズ後のバイト数）
　：
　＋（グローバルセッション情報nのキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクトnのシリアライズ後のバイト数）
　＋4

注

シリアライズは，一つのHTTPセッションに対して，一つのjava.io.ObjectOutputStreamのオブジェクトを使用して実施します。

参考

グローバルセッション情報のサイズ見積もり機能を使用すると，各情報のシリアライズ後のバイト数が出力できます。出力されたサイズ情報を参考にして，グローバルセッション情報の最大サイズに適切な値を設定してください。グローバルセッション情報のサイズ見積もり機能については，「12.2.10　グローバルセッション情報のサイズの見積もり」を参照してください。

(4)　グローバルセッション情報を格納するSFOサーバ（SFOServerName）

グローバルセッション情報を格納するSFOサーバのサーバ名を指定します。サーバ名は，J2EEサーバのusrconf.propertiesのwebserver.sfo.sfo_serversキーに指定したSFOサーバ名から選択します。

usrconf.propertiesについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(5)　グローバルセッションの制御方法（GSessionControl）

グローバルセッションの制御方法を指定します。指定した値に応じて，Webクライアントに対するグローバルセッションIDの送信方法，およびWebクライアントからのグローバルセッションIDの受信方法が決まります。

指定できる値と意味を次の表に示します。

表12-16　GSessionControlの指定値の意味

指定値
意味

cookie
グローバルセッションの制御にHTTP Cookieを使用します。

url-rewriting
グローバルセッションの制御にURL書き換えを使用します。

both
グローバルセッションの制御にHTTP CookieおよびURL書き換えの両方を使用します。
WebクライアントがHTTP Cookieをサポートしているかどうかを判別して，必要に応じてHTTP Cookieによる制御とURL書き換えによる制御を切り替えます。

また，GSessionControlに指定した値によって，次の制御が変わります。

WebクライアントからJ2EEサーバに送信されるグローバルセッションIDの扱われ方

J2EEサーバからWebクライアントへのレスポンスの設定内容

GSessionControlに指定する値とグローバルセッションの制御方法の関係を，次の表に示します。

表12-17　GSessionControlに指定する値とグローバルセッションの制御方法の関係

GSessionControlに指定する値 | WebクライアントからJ2EEサーバに送信されるリクエストに含まれるグローバルセッションID | J2EEサーバからWebクライアントに送信されるレスポンスの内容
HTTP Cookieに含まれるグローバルセッションID | URLのパスパラメタに含まれるグローバルセッションID | グローバルセッション生成時にHTTP Cookieを付加するかどうか | ServletAPIによるURL書き換えが有効になるかどうか
cookie | 有効 | 無効 | 付加する | 無効
url-rewriting | 無効 | 有効 | 付加しない | 有効
both | 有効※¹ | 有効※¹ | 付加する | 有効※²

注※1

クライアントから送信されたリクエストが，HTTP CookieおよびURLのパスパラメタの両方にグローバルセッションIDを含んでいる場合は，HTTP Cookieで送信されたグローバルセッションIDが有効になります。

注※2

WebクライアントがHTTP Cookieをサポートしている場合は，URL書き換えは実行しません。

HTTP CookieまたはURL書き換えを使用したグローバルセッションの制御については，「12.3　HTTP Cookieによるグローバルセッションの制御」および「12.4　URL書き換えによるグローバルセッションの制御」を参照してください。

(6)　グローバルセッションIDの送信に使用するHTTP Cookieの名称（GIDCookieName）

グローバルセッションIDをWebブラウザなどのクライアントに通知するときに使用するHTTP Cookieの名称を指定します。なお，グローバルセッションIDとは，グローバルセッション情報の識別に使用される情報です。

(7)　グローバルセッションIDの送信に使用するURLのパスパラメタ名（GIDURLParamName）

グローバルセッションIDをWebブラウザなどのクライアントに通知するときに使用するURLのパスパラメタ名を指定します。

GSessionControlパラメタに「cookie」を指定した場合，このパラメタに設定した値は無効になります。なお，GSessionControlパラメタに「cookie」を指定した場合，GIDURLParamNameパラメタに設定した値はチェックされません。このため，このパラメタに不正な値を設定した場合も，検出はされません。

注意

Webアプリケーション内で使用するURLのパスパラメタと同じ名称を，このパラメタで指定しないでください。指定した場合，セッションフェイルオーバ機能が正しく動作しません。

URL書き換えを使用したグローバルセッションの制御については，「12.4　URL書き換えによるグローバルセッションの制御」を参照してください。

(8)　グローバルセッション情報のロック待ちタイムアウト時間（LockTimeout）

すでにロックされた状態のセッションに対して，別のJ2EEサーバからロック要求があった場合に，ロック待ちがタイムアウトになるまでの時間を指定します。

J2EEサーバからSFOサーバに対してグローバルセッション情報のロック取得要求をしたあとに，J2EEサーバに障害が発生して停止した場合，SFOサーバ上のグローバルセッション情報がロックされたままの状態になってしまうおそれがあります。グローバルセッション情報のロック待ちタイムアウト時間は，このような場合に，J2EEサーバに障害が発生したと判断するために使用されます。

また，次のような場合にロックされたままの状態になったときにも，このタイムアウト時間が有効になります。これらの状態は，負荷分散機を使用している環境で発生することがあります。

ページにフレームを使用している場合など，同じセッションを使用するリクエストが同時に送信され，それぞれのリクエストが負荷分散機のスケジュール機能によって異なるJ2EEサーバに分散されて転送されたとき

ユーザの操作によってリクエストが二重に送信された場合など，リクエストを送信して応答が返されるよりも前に次のリクエストを送信したときに，それぞれのリクエストが負荷分散機のスケジュール機能によって異なるJ2EEサーバに分散されて転送されたとき

フレームを使用するアプリケーションの場合は，リクエスト処理が終わるまでのロック待ち時間も考慮して，タイムアウト時間を定義してください。

(9)　引き継ぎ可能なセッション情報のデータ型（GSInfoTypeByteArrayEnable，GSInfoTypeSerializableEnable）

引き継ぎ可能なセッション情報のデータ型には，java.lang.Stringクラスのオブジェクト，byte型配列，および直列化可能クラスのオブジェクトがあります。

データ型がbyte型配列，または直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とする場合には，次の設定を有効にします。

byte型配列であるセッション情報の引き継ぎ許可

直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可

これらの設定を無効にした場合は，java.lang.Stringクラスのオブジェクトだけが引き継ぎ可能なセッション情報となります。

(a)　byte型配列であるセッション情報の引き継ぎ許可

byte型配列のセッション情報を引き継ぎ対象とするかどうかをGSInfoTypeByteArrayEnableパラメタに指定します。「true」を指定した場合は，java.lang.Stringクラスのオブジェクトに加え，byte型配列のセッション情報も引き継ぎ対象となります。

「false」を指定した場合は，byte型配列のセッション情報は引き継ぎ対象外となります。引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「12.2.3(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(b)　直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可

直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とするかどうかをGSInfoTypeSerializableEnableパラメタに指定します。「true」を指定した場合は，直列化可能クラスのオブジェクトであるセッション情報が引き継ぎ対象となります。この場合，java.lang.Stringクラスのオブジェクト，およびbyte型配列のセッション情報も区別なく，直列化可能クラスのオブジェクトであるセッション情報としてシリアライズして，グローバルセッション情報を作成します。

「false」を指定した場合は，直列化可能クラスのオブジェクトであるセッション情報は引き継ぎ対象外となります。引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「12.2.3(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(c)　引き継ぎ可能なセッション情報のデータ型を指定する場合の注意事項

GSInfoTypeByteArrayEnableパラメタとGSInfoTypeSerializableEnableパラメタの指定値によって，引き継ぎ対象となるデータ型が異なります。各パラメタに指定する値と引き継ぎ対象となるデータ型の関係を次の表に示します。

表12-18　GSInfoTypeByteArrayEnableおよびGSInfoTypeSerializableEnableパラメタに指定する値と引き継ぎ対象となるデータ型の関係

GSInfoTypeByteArrayEnableパラメタ※1に指定する値 | GSInfoTypeSerializableEnableパラメタ※2に「true」を指定 | GSInfoTypeSerializableEnableパラメタ※2に「false」を指定
true | 直列化可能クラスのオブジェクト | java.lang.Stringクラスのオブジェクトまたはbyte型配列
false | 直列化可能クラスのオブジェクト | java.lang.Stringクラスのオブジェクト

注※1　byte型配列のセッション情報を引き継ぎ対象とするかどうかを指定するパラメタです。

注※2　直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とするかどうかを指定するパラメタです。

なお，引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「12.2.3(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(10)　DDの定義例（HTTP Cookieによる制御の場合）

セッションフェイルオーバ機能を使用する場合のDDの定義例を示します。この例は，HTTP Cookieによってグローバルセッションを制御し，byte型配列のセッション情報を引き継ぐ場合の例です。

    ：
<!--The filter for Session Fail Over -->
<filter>
  <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
  <filter-class>com.hitachi.software.was.sfo.web.SFOFilter</filter-class>
  <init-param>
    <param-name>GSInfoKey-RW</param-name>
    <param-value>page</param-value>
  </init-param>

  <init-param>
    <param-name>GSInfoKey-R</param-name>
    <param-value>userId;roll</param-value>
  </init-param>

  <init-param>
    <param-name>GSInfosLengthMax</param-name>
    <param-value>44</param-value>
  </init-param>

  <init-param>
    <param-name>SFOServerName</param-name>
    <param-value>sfo_server1</param-value>
  </init-param>

  <init-param>
    <param-name>GSessionControl</param-name>
    <param-value>cookie</param-value>
  </init-param>

  <init-param>
    <param-name>GIDCookieName</param-name>
    <param-value>SFOSESSIONID</param-value>
  </init-param>

  <init-param>
    <param-name>LockTimeout</param-name>
    <param-value>180</param-value>
  </init-param>

  <init-param>
    <param-name>GSInfoTypeByteArrayEnable</param-name>
    <param-value>true</param-value>
  </init-param>
</filter>

<!-- Specify the filter tags here. -->
<filter>
  <filter-name>UserFilter</filter-name>
  <filter-class>filter.UserFilter</filter-class>
</filter>

<!-- The filter mappings for the Session Fail Over-->
<filter-mapping>
  <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

<!-- Specify the filter-mapping tags here. -->
<filter-mapping>
  <filter-name>UserFilter</filter-name>
  <url-pattern>/servlet/*</url-pattern>
</filter-mapping>
    ：
</web-app>

この例で定義される内容は，次のとおりです。

書き換え可能グローバルセッション情報として，「page」の値を格納します。

読み込み専用グローバルセッション情報として，「userId」および「roll」の2種類の値を格納します。

グローバルセッション情報の最大サイズとして，49を設定します。
最大サイズは，次の式で算出します。ここでは，page（4文字）の値は1～2文字のASCII文字列，userId（6文字）の値は1～12バイトのbyte型配列，roll（4文字）の値は1～7文字のASCII文字列とします。
（4＋6＋4）+（2＋7＋（12＋5））＋（2×3-1）＋4＝49

使用するSFOサーバの名称は，sfo_server1とします。

グローバルセッションIDのキー名称は，SFOSESSIONIDとします。

SFOサーバでのロック待ちタイムアウト時間は，180秒とします。

byte型配列のセッション情報を引き継ぎます。

(11)　DDの定義例（URL書き換えによる制御の場合）

セッションフェイルオーバ機能を使用する場合のDDの定義例を示します。この例は，URL書き換えによってグローバルセッションを制御する場合の例です。

なお，ここでは，URL書き換えによる制御の場合にHTTP Cookieによる制御と異なる設定だけについて示します。これ以外の項目については，「(10)　DDの定義例（HTTP Cookieによる制御の場合）」を参照してください。

    ：
<!--The filter for Session Fail Over -->
<filter>
  <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
  <filter-class>com.hitachi.software.was.sfo.web.SFOFilter</filter-class>
    ：
  <init-param>
    <param-name>GSessionControl</param-name>
    <param-value>url-rewriting</param-value>
  </init-param>

  <init-param>
    <param-name>GIDURLParamName</param-name>
    <param-value>sfogid</param-value>
  </init-param>
    ：
</filter>

この例では，グローバルセッションIDの送信に使用するURLのパスパラメタ名は，「sfogid」としています。

(12)　DDの定義例（制御方法にbothを指定する場合）

セッションフェイルオーバ機能を使用する場合のDDの定義例を示します。この例は，制御方法としてGSessionControlに「both」を指定する場合の例です。bothは，WebクライアントがHTTP Cookieをサポートしているかどうかを判別して，必要に応じてHTTP Cookieによる制御とURL書き換えによる制御を切り替える方法です。

なお，ここでは，bothを指定する場合にHTTP Cookieによる制御と異なる設定だけについて示します。これ以外の項目については，「(10)　DDの定義例（HTTP Cookieによる制御の場合）」を参照してください。

    ：
<filter>
  <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
  <filter-class>com.hitachi.software.was.sfo.web.SFOFilter</filter-class>
    ：
  <init-param>
    <param-name>GSessionControl</param-name>
    <param-value>both</param-value>
  </init-param>

  <init-param>
    <param-name>GIDCookieName</param-name>
    <param-value>SFOSESSIONID</param-value>
  </init-param>

  <init-param>
    <param-name>GIDURLParamName</param-name>
    <param-value>sfogid</param-value>
  </init-param>
    ：
</filter>

この例では，グローバルセッションIDの送信に使用するHTTP Cookieの名称は「SFOSESSIONID」としています。また，グローバルセッションIDの送信に使用するURLのパスパラメタ名は，「sfogid」としています。

12.8　障害検知の方法

セッションフェイルオーバ機能を使用している場合に，Webサーバ，J2EEサーバ，およびSFOサーバで発生した障害は，次に示す二つの方法で検知できます。

Management Serverの稼働状況監視による障害検知
Management Serverの稼働状況監視を使用して，Webサーバ，J2EEサーバ，およびSFOサーバの稼働状況を監視できます。稼働状況の監視については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

負荷分散機のヘルスチェック機能による障害検知
負荷分散機の機能を使用して，システム内のJ2EEサーバに対してヘルスチェックを実施できます。ヘルスチェックで，J2EEサーバに問題を検知した場合，該当するJ2EEサーバにリクエストを転送しているWebサーバへの負荷分散を中止します。
また，J2EEサーバへのチェックの際にWebサーバを経由するため，Webサーバでの障害検知もできます。
SFOサーバで発生した障害については，SFOサーバおよびJ2EEサーバが出力したメッセージログを基に，障害検知を実施します。

13.　統合ユーザ管理

この章では，Cosminexusシステムのユーザを統合管理するための統合ユーザ管理フレームワークについて説明します。統合ユーザ管理フレームワークとは，Javaの標準ユーザ認証（JAAS）によるアプリケーションユーザ管理および複数のアプリケーションへのシングルサインオンを実現するフレームワークです。

なお，この章で説明する機能は，J2EEサーバの動作モードには依存しないで使用できます。

＜この章の構成＞

13.1　統合ユーザ管理の概要

13.2　Cosminexus標準ログインモジュールによるユーザ認証の仕組み

13.3　統合ユーザ管理のセッション管理

13.4　シングルサインオンの利用方法

13.5　カスタムログインモジュールの利用

13.6　統合ユーザ管理フレームワークが提供するAPIの概要

13.7　統合ユーザ管理フレームワークによるユーザ認証の実装の概要

13.8　APIを使用したユーザ認証の実装

13.9　タグライブラリを使用したユーザ認証の実装

13.10　セッションフェイルオーバ機能使用時のユーザ認証の実装

13.11　カスタムログインモジュールの実装

13.12　統合ユーザ管理の運用

13.1　統合ユーザ管理の概要

統合ユーザ管理は，Cosminexusシステムにログインするユーザについての情報を統合管理する機能です。

統合ユーザ管理を実現するために，Cosminexusでは次の機能を提供しています。

統合ユーザ管理フレームワーク
統合ユーザ管理でのユーザ認証を実現するフレームワークです。Java標準仕様（JAAS）に従ったアプリケーションプログラムインタフェースを提供します。

＜この節の構成＞

13.1.1　統合ユーザ管理の目的

13.1.2　レルムを使用したユーザ管理とユーザマッピング

13.1.3　Java標準仕様（JAAS）に準拠したユーザ認証の概要

13.1.4　統合ユーザ管理で使用するユーザ情報の管理方法

13.1.5　ユーザ認証の有効期間と認証状態の引き継ぎ

13.1.6　統合ユーザ管理の処理の流れ

13.1.1　統合ユーザ管理の目的

従来，企業内にある各種の業務システムでは，業務の要件によってそれぞれ独自の方法でそのシステムのユーザを管理しています。例えば，勤休管理のシステムでは，社員データベースに登録された社員個人をシステムのユーザとして区別します。また，資材の発注システムでは，原価管理のための各部署をシステムのユーザとして区別します。最近はイントラネット技術の発展によって，システムごとのクライアントプログラムをインストールしなくても，Webブラウザを使ってこれらの業務サービスを受けられるようになってきています。しかし，社内メールサービスを利用するにはメールのIDで，勤休管理サービスでは社員番号で，また資材発注サービスは部署コードでログインをするといったように，それぞれのシステムのユーザ管理に従ったユーザ認証のための操作が必要で，簡単にそれらのシステムのサービスを統合した新たなサービスを提供することは困難でした。

統合ユーザ管理フレームワークは，J2EE技術でこれらのサービスを統合するためのユーザ管理のフレームワークです。統合ユーザ管理フレームワークの例を次の図に示します。

図13-1　統合ユーザ管理フレームワークの例

13.1.2　レルムを使用したユーザ管理とユーザマッピング

ここでは，統合ユーザ管理で使用する概念である，レルムとユーザマッピングについて説明します。

＜この項の構成＞

(1)　レルム（Realm）

(2)　レルム間のユーザマッピング

(1)　レルム（Realm）

レルムとは，同一の認証ポリシーを適用する範囲のことです。業務サービスを提供するアプリケーションは，提供するサービスの要件に従って，そのサービスを利用するユーザを区別します。ユーザを区別するための処理は，一般に認証処理と呼ばれます。認証処理は，サービスを利用するユーザを区別するための認証メカニズムと，そのためのユーザ認証データベース（ユーザ認証リポジトリ）によって分類できます。どのような認証メカニズム（群）を利用し，どのようなユーザをユーザ認証データベースに登録するかといった認証ポリシーを決定するのは，システムを管理するシステム管理者の仕事です。

単一のサービスを提供するシステムを構築する場合にはあまり問題になりませんが，多数のサービスを提供するシステムを構築する場合，どの範囲でどのような認証ポリシーを適用してシステムを運用するかという検討が必要です。Webシステムでは，同一の認証ポリシーを適用する範囲をレルムと呼び，それぞれのレルムを識別する名称のことをレルム名と呼びます。あるレルムで認証されたユーザは，該当レルム内でそのユーザを一意に識別する識別子（ユーザID）を持っています。

同じユーザ管理要件を持つ複数のアプリケーションは，一つのレルムで運用できます。新たにすべてのサービスを構築する場合，すべてのサービスを一つのレルムにして，認証されたユーザの持つセキュリティ属性によって各種のサービスに対してコントロールするようにできれば管理しやすいのですが，現実にはなかなかそのようなシステムの構築はされません。社内メールではメールのID，人事システムでは従業員番号，資材システムには部署コードでログインするといったように，企業システムにはすでに多くのレルムがあり，これらは別々に管理運用されています。

管理者は，Cosminexusを使用してこれらのサービスの統合をする場合，何のためにそのレルムが必要なのか分析し，運用管理を簡単にするためにできるだけ少ないレルムで運用できるように，レルムの統廃合を検討してください。レルムの運用例を次の図に示します。

図13-2　レルムの運用例

(2)　レルム間のユーザマッピング

業務サービスを提供するアプリケーションは，ユーザの情報が必要になると，まずエンドユーザにユーザIDとパスワードの入力を求め，それを基にユーザを認証します。一度受けた認証の結果は，ログアウトするまで保持されます。ただし，ユーザIDおよびパスワードが異なるアプリケーションに続けてログインしようとすると，そのたびにアプリケーションからユーザIDとパスワードの入力を求められます。つまり，一度一つのアプリケーションで認証を受けたユーザであっても，異なるレルムで管理されているアプリケーションにアクセスするためには，そのつど認証を受ける必要があります。

これに対して，あるレルムでログインしたユーザが，ほかのレルムでどのユーザとして扱われるのかが分かれば，レルムが異なるJ2EEアプリケーションにログインするたびにユーザIDとパスワードを入力する必要はなくなります。統合ユーザ管理フレームワークでは，この問題を解決するために，あるレルムでログインしたユーザをほかのレルムのユーザにマッピングするユーザマッピングを実現します。

ユーザマッピングとは，元のレルムでの認証が成功したという認証状態が引き継がれていれば，自動的にほかのレルムにマッピングしてユーザ認証をするものです。ユーザマッピングをする場合，Cosminexusのシステム管理者が，あるレルムのユーザとほかのレルムのユーザとのマッピング情報をあらかじめシステムに定義しておきます。

次の図に示すようなユーザマッピングの例では，勤休管理サービスで認証されたユーザ「USER3」に対して，資材発注サービスのユーザ「dev_3」のマッピングを定義しておきます。これによって，勤休管理サービスに「USER3」として認証されたユーザは，資材発注サービスへのログイン操作をしなくても自動的に該当サービスに対して「dev_3」として認証されます。

図13-3　ユーザマッピングの例

13.1.3　Java標準仕様（JAAS）に準拠したユーザ認証の概要

今までの業務システムのWeb化では，従来の業務システムが持っていたユーザ認証機構をWebのサービスから独自のインタフェースで呼び出していました。また，最初からJ2EE技術で構築されるWeb業務サービスも，各社のアプリケーションサーバが提供する独自のユーザ認証機構を使って構築されてきました。これらのインタフェースの違いは，サービスを統合する場合の大きな障害になっていました。しかし，Javaの標準ユーザ認証の仕様としてJAAS（Java Authentication and Authorization Service） 1.0が決まり，現在ではJ2EE技術で構築されるWeb業務サービスのユーザ認証の標準となっています。

＜この項の構成＞

(1)　統合ユーザ管理フレームワークと個別のユーザ管理の関連

(2)　Cosminexus標準ログインモジュールの概要

(1)　統合ユーザ管理フレームワークと個別のユーザ管理の関連

JAASでは，アプリケーションが認証を要求する側のインタフェース（API：アプリケーションプログラミングインタフェース）と，その要求を受け認証処理をする側のインタフェース（SPI：サービスプロバイダインタフェース）を規定しています。認証処理をする側のモジュールをログインモジュールといいます。APIとSPIの関係を次の図に示します。

図13-4　APIとSPIの関係

Cosminexusでは，標準でパスワード認証の機能を持つCosminexus標準ログインモジュールを提供しています。このCosminexus標準ログインモジュールを利用して，JAASのAPIを使用するJSP/サーブレットで作成されたJ2EEアプリケーションのユーザ管理ができます。

Cosminexus標準ログインモジュールを使用すれば，アプリケーション開発者は，独自に認証モジュールを開発する必要はありません。また，モジュールはスタック可能なので，Cosminexus標準ログインモジュールと連携する拡張認証モジュールを容易に追加できます。さらに，完全に独自認証機能を必要とするアプリケーションでは，容易にCosminexus標準ログインモジュールを独自認証モジュールに置き換えて使用できます。これによって，JAASを使用してユーザ認証をしているアプリケーションプログラムを簡単にCosminexusで統合できるようになります。

これを，JAAS対応ユーザ管理と呼びます。JAAS対応ユーザ管理の概要を次の図に示します。なお，図中のユーザ情報リポジトリとは，認証処理に必要なユーザ情報が格納されているリポジトリです。

図13-5　JAAS対応ユーザ管理の概要

統合ユーザ管理フレームワークに従って，JAAS対応ユーザ管理を使用すると，ある業務サービスで認証されたユーザを，別の業務サービスのユーザにマッピングして認証要求する，ユーザマッピングの機能を利用できます。また，独自のユーザ情報リポジトリを利用する場合でも，カスタムログインモジュールを作成すれば，その業務サービスも含めたシングルサインオンが実現できます。ユーザマッピングによるシングルサインオンの概要を次の図に示します。なお，図中のシングルサインオン情報リポジトリとは，シングルサインオンに必要なマッピング情報が格納されているリポジトリです。

図13-6　ユーザマッピング機能の概要

(2)　Cosminexus標準ログインモジュールの概要

Cosminexus標準ログインモジュールは，パッケージjavax.security.auth.spiに含まれるLoginModuleインタフェースの実装クラスです。実現する認証方法に応じて使い分けられます。

Cosminexus標準ログインモジュールの特徴を次に示します。

既存のユーザ情報（LDAP情報またはデータベース情報）を利用したユーザ認証ができます。

Cosminexus標準ログインモジュールでは，ユーザ認証に使用するユーザ情報を格納するリポジトリとしてLDAPディレクトリサーバまたはデータベース（RDB）を使用できます。

LDAPディレクトリサーバを使用する場合，標準のユーザ管理リポジトリのDIT（Directory Information Tree）の構造をCosminexusが規定しています。また，すでにLDAPを導入しているときには，その情報を利用できるように簡単にカスタマイズできます。なお，DITとは，ユーザや組織の情報をツリー構造で管理するためのLDAPの仕組みです。詳細については，「13.1.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。

認証方式としては，証明書を使用した認証やパスワード認証ができます。認証方式は，Cosminexus標準ログインモジュールの種類によって異なります。

ユーザ情報を参照できます。

ユーザ認証が成功した場合に，ログインユーザについての情報を参照できます。

JAASでは，認証が成功すると認証したユーザの情報をCredentialとしてSubjectに設定することが規定されています。また，これを要求元のアプリケーションからjava.util.setインタフェースで参照するための一般的なメソッド（getPublicCredentialsメソッドおよびgetPrivateCredentialsメソッド）が規定されています。

Cosminexus標準ログインモジュールでは，ユーザ情報を参照するためのインタフェースを提供しています。このインタフェースでは，コンフィグレーションに従って，ユーザの情報をCosminexusが提供するUserAttributesインタフェースで扱うオブジェクトとして，Credentialに設定します。アプリケーションでは標準のインタフェースでこのオブジェクトを取り出し，該当オブジェクトのgetAttributeメソッドに属性名を指定して呼び出すことで，必要なユーザ情報を取得できます。また，属性名の別名（エイリアス）を指定して，情報を取得することもできます。

シングルサインオンを実現できます。

Cosminexus標準ログインモジュールは，シングルサインオンに対応できます。

なお，シングルサインオンを実現する場合，ユーザ情報を管理しているリポジトリの種類と関係なく，LDAPディレクトリサーバが必要です。

13.1.4　統合ユーザ管理で使用するユーザ情報の管理方法

ここでは，統合ユーザ管理で使用するユーザ情報の管理方法について説明します。

統合ユーザ管理では，ユーザ情報を格納するリポジトリとして，LDAP，またはデータベースを使用します。LDAPディレクトリサーバでは，ユーザや組織の情報は，DITで管理されます。統合ユーザ管理フレームワークで使用するLDAPディレクトリサーバでは，ユーザおよびレルムをDITのエントリとして管理します。エントリは，DITを構成する情報で，DITの各節に該当する情報です。個々のエントリは，DN（識別名）で区別されます。

Cosminexusでは，統合ユーザ管理フレームワークで使用するLDAPディレクトリサーバに格納する標準のユーザ管理リポジトリのDIT構造を規定しています。統合ユーザ管理フレームワークで使用するリポジトリは，2種類あります。

ユーザ情報リポジトリ
ユーザ情報を格納します。

シングルサインオン情報リポジトリ
統合ユーザ管理フレームワークのユーザマッピングを実行して，シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報を格納します。

これらのリポジトリは，次の図に示すようなディレクトリ構造を持ちます。

図13-7　統合ユーザ管理フレームワークのリポジトリのDIT構造

各リポジトリについて説明します。

＜この項の構成＞

(1)　ユーザ情報リポジトリ（LDAPディレクトリサーバの場合）

(2)　ユーザ情報リポジトリ（データベースの場合）

(3)　シングルサインオン情報リポジトリ

(1)　ユーザ情報リポジトリ（LDAPディレクトリサーバの場合）

ユーザ認証で使用するユーザ情報は，ユーザ情報リポジトリに格納します。統合ユーザ管理フレームワークは，LDAPディレクトリサーバのユーザ情報リポジトリに格納されたユーザ情報を基にユーザを認証して，認証したユーザの情報をアプリケーションに渡します。ユーザ情報リポジトリのユーザ情報の参照には，ユーザ認証ライブラリを使用します。ユーザ情報リポジトリのDIT構造を次の図に示します。

図13-8　ユーザ情報リポジトリのDIT構造

管理するレルムごとにユーザ情報リポジトリを設定してください。

(a)　レルム

JAAS対応ユーザ管理のレルム名を指定します。レルム名は次の表に示す基準に従って指定してください。

表13-1　レルム名の基準

情報の種類
意味
文法

レルム名
ユーザ管理の範囲を示す識別子。
英数字列。
大文字と小文字を区別しません。
DN名で使用できる名前を付けてください。

注　英数字列は，英字（A～Z，a～z）と数字（0～9）の文字の並びを意味します。ASCII文字列で指定してください（文法については，プログラムではチェックしていません）。

(b)　アプリケーション固有情報

該当レルムを使用する各アプリケーション固有の情報を格納する場合に使用してください。統合ユーザ管理フレームワークを使用する場合に必須な情報はありません。

(c)　ユーザ認証ライブラリのベースDN

レルムに属するユーザエントリの上位エントリです。レルムに属する各ユーザのエントリは，このエントリの下階層にある必要があります。なお，ユーザエントリがこのエントリの直下にない場合は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）のcom.cosminexus.admin.auth.ldap.search.scopeオプションを変更する必要があります。また，このエントリで指定した情報はjaas.conf（JAASのコンフィグレーションファイル）に指定する必要があります。各コンフィグレーションファイルについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(d)　ユーザエントリ

ユーザ情報を定義します。ユーザ認証ライブラリでは，ユーザ情報として次の表に示す属性が必要です。

表13-2　ユーザ情報に必要な属性

属性名 | 説明 | 必須
ユーザID | ユーザIDを格納します。属性は，文字列（cisなど）である必要があります。デフォルトでは，「uid」属性名を使用します。 | 必須
パスワード | パスワードを格納します。属性はバイナリです。平文または暗号化した値を格納します。この属性に値が指定されていない場合は，アカウントが無効になります。デフォルトでは，「userPassword」属性名を使用します。 | オプション
そのほかの属性 | 各アプリケーションが定義している属性です。 | 各アプリケーションの仕様に従ってください。

ユーザIDおよびパスワードの属性名は，jaas.conf（JAASのコンフィグレーションファイル）で変更できます。

(e)　注意事項

ユーザ情報リポジトリのディレクトリ構成は，JAAS対応ユーザ管理で推奨するDIT構成です。別の構成で管理する場合は「ユーザ認証ライブラリのベースDN」以下の次の条件を満たすユーザのエントリが必要です。

ユーザIDとパスワードは，同一オブジェクトクラス内にある必要があります。

パスワードの属性はバイナリである必要があります。また，暗号化した値が格納されていることを推奨します。平文で格納されている場合は，一度ldif形式のファイルに出力してからconvpwコマンドで暗号化して，再登録してください。convpwコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

ユーザIDおよびパスワードは，同じ属性名を使用してマルチバリューで指定できますが，Cosminexusシステムの運用上，一つのオブジェクトクラス内に一つだけ指定してください。もし，複数指定した場合は，最初に見つかったものを使用します。

ユーザIDとして使用する属性のユーザIDは，レルム内（ユーザ情報リポジトリのベースDN下）で一意な値にしてください。

なお，ユーザ情報リポジトリのベースDN，使用するユーザIDおよびパスワードの属性名については，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定します。ua.confについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(2)　ユーザ情報リポジトリ（データベースの場合）

統合ユーザ管理フレームワークは，データベースに格納されたユーザ情報を基にユーザを認証できます。データベースでは，ユーザIDからパスワードを取得できるようにしてください。

(3)　シングルサインオン情報リポジトリ

シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報は，シングルサインオン情報リポジトリに格納します。統合ユーザ管理フレームワークは，LDAPディレクトリサーバのシングルサインオン情報リポジトリに格納されたユーザ情報を基にユーザマッピングをして，シングルサインオンを実現します。シングルサインオン情報リポジトリのユーザ情報は，シングルサインオンライブラリを使用して参照します。シングルサインオン情報リポジトリのDIT構造を次の図に示します。

図13-9　シングルサインオン情報リポジトリのDIT構造

(a)　シングルサインオン情報リポジトリのベースDN

シングルサインオンを使用するために必要な情報を管理するDITの，最上位のエントリです。このエントリは，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定します。ua.confについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。なお，ここで指定する名称は，大文字と小文字が区別されません。この値は，標準のオブジェクトクラスである「organizationalUnit」のou属性に設定されます。

(b)　レルム

ユーザ情報はレルムごとに管理されます。シングルサインオン情報リポジトリのレルム名では，大文字と小文字は区別されません。この値は，標準のオブジェクトクラスである「organizationalUnit」のou属性に設定されます。

(c)　ユーザエントリ

シングルサインオンで接続したいアプリケーションで，ユーザ管理に使用しているユーザの認証情報および接続先を格納するためのエントリです。ユーザエントリの構造を次の図に示します。

図13-10　ユーザエントリの構造

管理用識別子

シングルサインオンライブラリで登録した際に自動的に設定される識別子です。

ユーザID

各レルムで一意なユーザIDを文字列で指定します。ユーザIDでは，大文字と小文字は区別されます。

暗号化したデータ

登録する際に暗号化が必要なデータを格納します。例えば，パスワードは，この属性に格納することで，暗号化されて保存されます。

暗号化しないデータ

登録する際に暗号化する必要がない，ユーザIDおよび暗号化データ以外に認証に必要な情報を格納します。例えば，ユーザに付くグループIDを保存します。

ユーザ管理を持つアプリケーションのユーザエントリのDN名

ここには，ユーザが接続する，ユーザ管理を持つアプリケーションのユーザ認証情報の格納先（DN名）が格納されます。この値は，複数指定できます。

13.1.5　ユーザ認証の有効期間と認証状態の引き継ぎ

JAASでのユーザ認証の有効期限は，loginメソッドの成功からlogoutメソッドを呼び出すまでです。

J2EEのWebアプリケーションでは，ユーザとの仮想的なセッションをHttpSessionオブジェクトでコントロールします。複数のHTTPプロトコルの通信を一連のセッションとして扱う場合は，WebアプリケーションでCookieまたはURL書き換えなどでHttpSessionオブジェクトと要求ユーザの結び付けをするようにコーディングします。

統合ユーザ管理フレームワークでは，ユーザ認証に成功した状態をHttpSessionオブジェクトで記憶しています。同一HttpSessionオブジェクトを利用した要求で，かつ同一レルムの場合に限り，2回目以降のログインでは，自動的に最初のログインで指定されたユーザの認証情報（ユーザID／パスワード）を使用して認証状態の引き継ぎをするため，エンドユーザからの認証情報の入力を省略できます。

ただし，次の表に示す順序でログインモジュールが使用された場合，エンドユーザから認証情報の入力を省略する機能は働きません。それぞれのログインモジュールの機能については，「13.2　Cosminexus標準ログインモジュールによるユーザ認証の仕組み」を参照してください。

表13-3　エンドユーザから認証情報の入力を省略する機能が働かない使用順序

使用順序
使用するログインモジュール

1回目のログイン

DelegationLoginModule（カスタムログインモジュールやWebCertificateLoginModuleを呼び出す場合）

WebCertificateLoginModule

WebSSOLoginModule（カスタムログインモジュールやWebCertificateLoginModuleを呼び出す場合）

2回目以降のログイン

WebPasswordLDAPLoginModule

また，次の表に示す順序でログインモジュールを使用する場合，WebPasswordLDAPLoginModuleによる2回目以降のログインで認証情報の入力を省略するためには，最初のログインで使用するログインモジュールでパスワードを統合ユーザ管理のセッションに保持する必要があります。さらに，WebPasswordLDAPLoginModuleでの2回目以降のログインに使用するパスワードが最初のログインで保持したパスワードと同じでなければなりません。パスワードを保持するかどうか，および保持する場合に暗号化をするかどうかは，jaas.conf（JAASのコンフィグレーションファイル）およびua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定できます。指定方法については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

表13-4　2回目以降のログインで認証情報の入力を省略するために条件がある使用順序

使用順序
使用するログインモジュール

1回目のログイン

WebPasswordLoginModule

WebPasswordJDBCLoginModule

WebPasswordLDAPLoginModule

2回目以降のログイン

WebPasswordLDAPLoginModule

保持するパスワードを暗号化しない場合，J2EEサーバが使用するメモリの内容を何らかの方法で参照されるとパスワードが漏洩する可能性があります。また，セッションフェイルオーバ機能を使用する場合，パスワードを含むセッション情報がネットワークを流れるため，パスワードが盗聴されるおそれがあります。暗号化をすることで，パスワードが漏洩するおそれは少なくなりますが，性能は劣化します。暗号化をするかどうかは，必要とするセキュリティや性能に応じて決定してください。なお，暗号化する場合，暗号アルゴリズムにはトリプルDESが使用されます。

13.1.6　統合ユーザ管理の処理の流れ

統合ユーザ管理を使用する場合の処理の流れを次の図に示します。

図13-11　統合ユーザ管理を使用する場合の処理の流れ

図の流れについて説明します。

Webブラウザからログインを要求するリクエストを送信します。

Webアプリケーションから，認証処理をするためのログインモジュールの呼び出し処理が実行されます。

Cosminexus標準ログインモジュールを使用して，ユーザ認証処理が実行されます。使用するログインモジュールおよびそのコンフィグレーションは，jaas.conf（JAASのコンフィグレーションファイル）またはua.conf（統合ユーザ管理のコンフィグレーションファイル）に定義されています。また，認証に必要な情報は，ユーザ情報リポジトリであるLDAPディレクトリサーバまたはデータベースから取得します。

認証結果がWebアプリケーションに返却されます。

この処理を実現するためには，システムを構築するユーザとアプリケーション開発者によるシステムの設定およびアプリケーションの開発が必要です。

システムを構築するユーザの作業の概要

jaas.conf（JAASのコンフィグレーションファイル）およびua.conf（統合ユーザ管理のコンフィグレーションファイル）に，使用するログインモジュール，使用するリポジトリ，およびそれらのコンフィグレーション情報を定義します。シングルサインオンを使用する場合には，ua.conf（統合ユーザ管理のコンフィグレーションファイル）にシングルサインオン用のパラメタも定義します。

シングルサインオンを使用する場合には，暗号鍵ファイルを作成します。

ユーザ情報リポジトリにユーザ情報を登録しておきます。

なお，jaas.confおよびua.confはテキストエディタなどで編集してください。

統合ユーザ管理機能の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

アプリケーション開発者の作業の概要

JAASのAPIおよびCosminexusが提供している統合ユーザ管理API，JSPタグライブラリを使用して，ログインモジュールを呼び出す認証処理プログラムを作成します。

それぞれのアプリケーションで独自の認証処理をする場合は，カスタムログインモジュールを作成します。

パスワード認証時のパスワード拡張をする場合は，実装クラスを作成します。

統合ユーザ管理フレームワークを使用したユーザ認証の実装については，「13.7　統合ユーザ管理フレームワークによるユーザ認証の実装の概要」を参照してください。

13.2　Cosminexus標準ログインモジュールによるユーザ認証の仕組み

統合ユーザ管理フレームワークでは，JAASに準拠したCosminexus標準ログインモジュールを提供します。Cosminexus標準ログインモジュールを使用することで，独自に認証モジュールを作成しなくても，Cosminexusシステムのユーザの統合管理が実現できます。

＜この節の構成＞

13.2.1　Cosminexus標準ログインモジュールの種類と機能

13.2.2　WebPasswordLoginModule

13.2.3　WebCertificateLoginModule

13.2.4　WebPasswordLDAPLoginModule

13.2.5　WebPasswordJDBCLoginModule

13.2.6　DelegationLoginModule

13.2.7　WebSSOLoginModule

13.2.8　Cosminexus標準ログインモジュールによるリポジトリへのアクセス

13.2.9　パスワード認証時の暗号拡張

13.2.10　ログインモジュールが使用するコンフィグレーションファイルのパラメタ

13.2.1　Cosminexus標準ログインモジュールの種類と機能

統合ユーザ管理フレームワークが提供するCosminexus標準ログインモジュールは，次の2種類に分類できます。

ユーザを認証するために使用するログインモジュール
次の四つのログインモジュールが該当します。

WebPasswordLoginModule
パスワードを使用してユーザ認証するログインモジュールです。

WebCertificateLoginModule
クライアント証明書を使用してユーザ認証するログインモジュールです。

WebPasswordLDAPLoginModule
LDAPディレクトリサーバの認証機能を使用してユーザ認証するログインモジュールです。

WebPasswordJDBCLoginModule
ユーザ情報リポジトリとして，すでにデータベースを使用している場合に使用するログインモジュールです。

各アプリケーションのカスタムログインモジュールを呼び出すためのログインモジュール
次の二つのログインモジュールが該当します。

DelegationLoginModule
カスタムログインモジュールを呼び出す場合に使用するログインモジュールです。シングルサインオンには対応しません。

WebSSOLoginModule
シングルサインオンで使用するログインモジュールです。Cosminexus標準ログインモジュールやカスタムログインモジュールなど，ほかのログインモジュールを呼び出します。

DelegationLoginModuleは，シングルサインオンの機能を使用しない場合にカスタムログインモジュールを呼び出すときに使用します。WebSSOLoginModuleは，シングルサインオンの機能を利用する場合に，ほかのCosminexus標準ログインモジュールまたはカスタムログインモジュールを呼び出すときに使用します。例えば，パスワードを使用してユーザ認証をしたいアプリケーションを，シングルサインオンの対象にしたい場合は，WebSSOLoginModuleからWebPasswordLoginModuleを呼び出して使用します。

それぞれのログインモジュールの機能一覧を次の表に示します。

表13-5　ログインモジュールの機能一覧

機能 | 種類
P | C | L | J | D | S
使用するリポジトリ | LDAPディレクトリサーバ | ○ | ○ | ○ | － | － | ○
データベース（JDBCでのアクセス） | － | － | － | ○ | － | －
認証方式 | X509証明書 | － | ○ | － | － | － | －
パスワード認証 | ○ | － | ○※1 | ○ | － | －
| 格納できる型 | バイナリ（byte[]） | ○ | － | － | ○※2 | － | －
文字列（String） | － | － | － | ○※3 | － | －
比較／格納するときに利用できる暗号アルゴリズム | 平文 | ○ | － | － | ○ | － | －
SHA-1形式 | ○ | － | － | ○ | － | －
MD5形式 | ○ | － | － | ○ | － | －
暗号化形式の拡張 | ○ | － | － | ○ | － | －
トリプルDES形式 | － | － | － | － | － | ○
そのほか | Principalオブジェクトの設定 | ○ | ○ | ○ | ○ | － | －
ユーザ属性の取得 | ○ | ○ | ○ | － | － | －
ログイン時，統合ユーザ管理のセッションにログインしたユーザのユーザID／レルム名の登録（ログアウト時に削除） | ○ | ○ | ○ | ○ | ○※4 | ○※4
カスタムログインモジュールの呼び出し | － | － | － | － | ○ | ○

（凡例）

P：WebPasswordLoginModule

C：WebCertificateLoginModule

L：WebPasswordLDAPLoginModule

J：WebPasswordJDBCLoginModule

D：DelegationLoginModule

S：WebSSOLoginModule

○：その機能を持ちます。

－：その機能を持ちません。

注※1　パスワードを格納できる型および暗号アルゴリズムの種類は，使用するLDAPディレクトリサーバに依存します。

注※2　byte[]型にマッピングできるSQLのデータ型を指定できます（VARBINARY/LONGVARBINARY）。

注※3　String[]型にマッピングできるSQLのデータ型を指定できます（CHAR/VARCHAR/LONGVARCHAR）。

注※4　条件を満たしている場合に登録されます。

13.2.2　WebPasswordLoginModule

WebPasswordLoginModuleは，LDAPディレクトリサーバにユーザ情報リポジトリがある場合に，パスワード認証をするログインモジュールです。

入力されたユーザID/パスワードを使って，LDAPディレクトリサーバに格納されているユーザ情報からパスワードを取得して認証します。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）には，LDAPディレクトリサーバに接続するための定義やエントリを検索する際に使用する属性名（uidおよびuserPassword）を指定しておきます。

WebPasswordLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得してLDAPディレクトリサーバを検索し，パスワードを取得してパスワード認証をします。認証に問題がなければユーザ属性を返却します。WebPasswordLoginModuleの概要を次の図に示します。

図13-12　WebPasswordLoginModuleの概要

13.2.3　WebCertificateLoginModule

WebCertificateLoginModuleは，Webサーバで認証されたクライアント証明書を使用して認証をするログインモジュールです。

WebサーバがSSL認証した際にブラウザに要求したクライアント証明書の被認証者識別名と，ユーザ情報リポジトリとでマッピングします。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）には，クライアント証明書の被認証者の識別名内からユーザIDに該当する属性名（cn）とLDAPディレクトリサーバを検索する際に使用する属性名（uid）を指定しておきます。

WebCertificateLoginModuleではその内容を読み取り，クライアント証明書を使用して認証処理をします。クライアント証明書からユーザIDに該当するIDを取得してLDAPディレクトリサーバにアクセスした結果，認証に問題がなく，該当エントリがあればユーザ属性を返却します。なお，証明書内のユーザIDに対応したエントリがない場合は，FailedLoginException例外が発生します。

WebCertificateLoginModuleの概要を次の図に示します。

図13-13　WebCertificateLoginModuleの概要

13.2.4　WebPasswordLDAPLoginModule

WebPasswordLDAPLoginModuleは，LDAPディレクトリサーバの認証機能を利用したログインモジュールです。

入力されたユーザID，パスワードを使ってLDAPディレクトリサーバにバインドし，バインドが成功すると認証が成功します。WebPasswordLDAPLoginModuleの概要を次の図に示します。

図13-14　WebPasswordLDAPLoginModuleの概要

ua.conf（統合ユーザ管理のコンフィグレーションファイル）では，LDAPディレクトリサーバに接続するための定義と，エントリを検索するときに使用する属性名を指定します。

WebPasswordLDAPLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得して，ユーザIDからユーザエントリのDNを求めます。次に，このDNとHttpServletRequestから取得したパスワードでLDAPディレクトリサーバにバインドし，成功するとユーザ属性を返却します。

ユーザエントリ検索とユーザ属性の取得に使用するユーザID／パスワードについて

認証時にユーザエントリの検索をする場合，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定されたバインドDNとバインドDNのパスワードを使用します。一方，ユーザ属性の取得に使用するバインドDNとパスワードには，ユーザエントリのDNとそのパスワードを使用します。ユーザエントリの検索については，「13.2.8(1)　ユーザエントリの検索」を参照してください。

LDAP接続プールを利用する場合の注意

LDAP接続プールはユーザエントリの検索処理だけに使用されます。認証時およびユーザ属性取得時にLDAP接続プールは使用されません。したがって，検索をしない設定の場合はLDAP接続プールを使用しない設定にしてください。LDAP接続プールについては，「13.2.8(2)　接続プール」を参照してください。

13.2.5　WebPasswordJDBCLoginModule

WebPasswordJDBCLoginModuleは，すでにデータベースを用いてユーザ管理をしている場合に使用するログインモジュールです。

入力されたユーザIDとパスワードを使って，データベース内に格納されているユーザ情報からパスワードを取得して認証します。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）では，データベースに接続するための情報定義やエントリを検索する際に使用するSQL（SELECT文）を指定します。

WebPasswordJDBCLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得してJDBCを使ってデータベースにアクセスし，パスワードを取得してパスワード認証をします。WebPasswordJDBCLoginModuleの概要を次の図に示します。

図13-15　WebPasswordJDBCLoginModuleの概要

JDBCドライバの指定

WebPasswordJDBCLoginModuleを使用する場合，JDBCドライバのクラスをログインモジュール内で参照します。使用できるJDBCドライバは，Cosminexus DABroker LibraryのJdbcDbpsv.jarです。このJARファイルは，次に示すディレクトリに格納されている必要があります。

Windowsの場合

<Cosminexusインストールディレクトリ>¥DABJ

UNIXの場合

/opt/Cosminexus/DABJ

13.2.6　DelegationLoginModule

カスタムログインモジュールを呼び出す場合に使用するログインモジュールです。

指定されたカスタムログインモジュールに認証処理を委譲します。DelegationLoginModuleの概要を次の図に示します。

図13-16　DelegationLoginModuleの概要

jaas.conf（JAASのコンフィグレーションファイル）では，使用するカスタムログインモジュールのクラス名を指定します。DelegationLoginModuleはその内容を読み取り，カスタムログインモジュールをインスタンス化します。このとき，DelegationLoginModuleのinitializeメソッドに与えられた引数はそのままカスタムログインモジュールに渡されます。

認証処理はカスタムログインモジュールに委譲されます。

13.2.7　WebSSOLoginModule

シングルサインオンをする場合に使用するログインモジュールです。Cosminexus標準ログインモジュールまたはカスタムログインモジュールを呼び出します。

一つのセッションですでにログインしているユーザが存在する場合，別のレルムで認証するための情報（ユーザID，SecretData，PublicData）をカスタムログインモジュールに渡します。WebSSOLoginModuleの概要を次の図に示します。

図13-17　WebSSOLoginModuleの概要

WebSSOLoginModuleは，jaas.conf（JAASのコンフィグレーションファイル）で指定されたログインモジュールの識別子に対応するカスタムログインモジュールのクラス名をua.conf（統合ユーザ管理のコンフィグレーションファイル）から読み込み，カスタムログインモジュールをインスタンス化します。このとき，WebSSOLoginModuleのinitializeメソッドに与えられた引数はそのままカスタムログインモジュールに渡されます。

該当するセッションでログインしているユーザが存在する場合，ua.confで指定されたLDAPディレクトリサーバからログインしているユーザのシングルサインオン情報が取得されます。このシングルサインオン情報に，これからログインしようとしているレルムのユーザへのマッピング情報が存在する場合，マッピング先ユーザのシングルサインオン情報が取得されます。シングルサインオン情報のうち，SecretDataはua.confで指定された方法で複合化されます。WebSSOLoginModuleは，マッピング先ユーザのユーザID，復号化したSecretData，およびPublicDataをsharedState（カスタムログインモジュールにinitializeメソッドによって渡されるMapオブジェクト）に設定します。設定に使用するパラメタ名は，ua.confに指定します。

該当するセッションでログインしているユーザが存在しない場合，WebSSOLoginModuleはsharedStateを変更しません。

認証処理はカスタムログインモジュールに委譲されます。

13.2.8　Cosminexus標準ログインモジュールによるリポジトリへのアクセス

ここでは，Cosminexus標準ログインモジュールによるユーザ情報リポジトリへのアクセス方法について説明します。

＜この項の構成＞

(1)　ユーザエントリの検索

(2)　接続プール

(1)　ユーザエントリの検索

LDAPディレクトリサーバをユーザ情報リポジトリとして使用する次のログインモジュールは，認証時にユーザエントリの検索ができます。

WebPasswordLoginModule

WebCertificateLoginModule

WebPasswordLDAPLoginModule

検索するかどうか，および検索範囲は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定します。なお，検索する必要があるかどうかは，LDAPディレクトリサーバのDITの構成によって決まります。

検索する必要がない場合

ユーザの認証およびユーザ属性を取得するためには，ユーザから入力されたユーザIDを基に，LDAPディレクトリサーバ上のユーザエントリを特定する必要があります。

次の図に示すように，ユーザエントリがベースDNの直下に存在し，かつユーザIDがユーザエントリのRDN（相対識別名）に含まれていれば，ユーザエントリのDNは，ベースDN，ユーザIDを表す属性名，およびユーザIDから組み立てられるため，検索は不要です。統合ユーザ管理では，このように検索が不要となるDIT構造にすることを推奨します。

図13-18　ユーザエントリがベースDNの直下に存在する場合

検索する必要がある場合

ユーザエントリのRDNにユーザIDが含まれない場合，またはユーザエントリがベースDNの直下よりも下の階層に存在する場合は，検索しないとユーザエントリを特定できません。次の図に示すようにユーザエントリがベースDNの2階層以上下層に存在する場合，検索範囲はsubtree（ベースDN以下すべての下層の検索）にする必要があります。

図13-19　ユーザエントリがベースDNの2階層以上下層に存在する場合

(2)　接続プール

Cosminexus標準ログインモジュールでは，ユーザ情報リポジトリへのアクセスを高速化するために接続プールを使用できます。

接続プールについては，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定します。

LDAP接続プールを使用できるログインモジュールを次に示します。

WebPasswordLoginModule

WebCertificateLoginModule

WebPasswordLDAPLoginModule

WebSSOLoginModule

JDBC接続プールを使用できるログインモジュールを次に示します。

WebPasswordJDBCLoginModule

13.2.9　パスワード認証時の暗号拡張

リポジトリに格納されているパスワードの暗号の形式が標準で用意されているもの（SHA-1/MD5/平文）以外の場合でも，暗号拡張ができます。この機能が利用できるのは，WebPasswordLoginModuleとWebPasswordJDBCLoginModuleです。

パスワード認証の暗号拡張をすると，リポジトリに格納されているパスワードの暗号の形式が標準で用意されている形式以外の場合でもパスワード認証をできるようにします。この機能を使うためには，あらかじめアプリケーション開発者が実装クラスを作成する必要があります。

ログインモジュールでは，データベースから取得したパスワードと比較するためにHttpServletRequestから入力したパスワードを変換します。com.cosminexus.admin.auth.jdbc.password.encrypt.exがua.conf（統合ユーザ管理のコンフィグレーションファイル）に指定されていた場合，そのクラスの実装をインスタンス化して，HttpServletRequestから入力したパスワードを変換します。

変換したものとデータベースのパスワードを単純にbyte[]で比較し，すべての文字が一致することで認証が成功します。パスワード認証時の暗号拡張の概要を次の図に示します。

図13-20　パスワード認証時の暗号拡張の概要

実装クラスの作成方法については，「13.8　APIを使用したユーザ認証の実装」を参照してください。

13.2.10　ログインモジュールが使用するコンフィグレーションファイルのパラメタ

使用するCosminexus標準ログインモジュールの種類によって，ua.conf（統合ユーザ管理のコンフィグレーションファイル）に指定する必要があるパラメタが異なります。

＜この項の構成＞

(1)　LDAPディレクトリサーバを使用するログインモジュール

(2)　データベースを使用するログインモジュール

(1)　LDAPディレクトリサーバを使用するログインモジュール

LDAPディレクトリサーバを使用する各ログインモジュールが使用するパラメタの一覧を次の表に示します。各パラメタの意味については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

表13-6　LDAPディレクトリサーバを使用する各ログインモジュールが使用するパラメタの一覧

パラメタ | 種類
P | C | S | L
java.naming.provider.url | ○ | ○ | ○ | ○
java.naming.security.principal | ○ | ○ | ○ | ○※1
java.naming.security.credentials | ○ | ○ | ○ | ○※1
com.cosminexus.admin.auth.ldap.basedn | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.attr.userid | ○ | ○ | × | ○
com.cosminexus.admin.auth.ldap.search.userrdn | ○ | ○ | × | ○※2
com.cosminexus.admin.auth.ldap.search.scope | ○ | ○ | × | ○※3
com.cosminexus.admin.auth.ldap.attr.password | ○ | × | × | ○※4
com.cosminexus.admin.auth.ldap.pool.enable | ○ | ○ | ○ | ○※5
com.cosminexus.admin.auth.ldap.pool.max | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.pool.max_spare | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.pool.min_spare | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.pool.gc_interval | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.conn.retry.count | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.conn.retry.wait | ○ | ○ | ○ | ○
com.cosminexus.admin.auth.ldap.certificate.attr.userid | × | ○ | × | ×
com.cosminexus.admin.auth.ldap.password.encrypt | ○ | × | × | ×
com.cosminexus.admin.auth.ldap.password.encrypt.ex | ○ | × | × | ×
com.cosminexus.admin.auth.ldap.directory.kind | × | × | × | ○

（凡例）

P：WebPasswordLoginModule

C：WebCertificateLoginModule

S：WebSSOLoginModule

L：WebPasswordLDAPLoginModule

○：使用できる　×：使用できない

注※1　ユーザエントリを検索する場合だけ必要です。このバインドDNとパスワードを使用して検索します。

注※2　ユーザエントリを検索する場合（ユーザエントリがベースDNの直下にない場合），trueを設定してください。

注※3　ユーザエントリを検索する場合，subtreeを指定してください。

注※4　ユーザのパスワードを変更する場合だけ必要です。使用するLDAPディレクトリサーバがActive Directoryの場合，unicodePwdを指定してください。Active Directory以外の場合はuserPasswordを指定してください。

注※5　LDAP接続プールはユーザエントリを検索する場合だけ使用されます。検索しない場合はfalseを指定してください。なお，どちらの場合も，ユーザの認証をするためにバインドするとき，LDAP接続プールは使用されません。

(2)　データベースを使用するログインモジュール

データベースを使用する各ログインモジュールが使用するパラメタの一覧を次の表に示します。各パラメタの意味については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

表13-7　データベースを使用する各ログインモジュールが使用するパラメタの一覧

パラメタ | 種類
J
com.cosminexus.admin.auth.jdbc.driver | ○
com.cosminexus.admin.auth.jdbc.conn.url | ○
com.cosminexus.admin.auth.jdbc.conn.user | ○
com.cosminexus.admin.auth.jdbc.conn.password | ○
com.cosminexus.admin.auth.jdbc.pool.enable | ○
com.cosminexus.admin.auth.jdbc.pool.max | ○
com.cosminexus.admin.auth.jdbc.pool.max_spare | ○
com.cosminexus.admin.auth.jdbc.pool.min_spare | ○
com.cosminexus.admin.auth.jdbc.pool.gc_interval | ○
com.cosminexus.admin.auth.jdbc.conn.retry.count | ○
com.cosminexus.admin.auth.jdbc.conn.retry.wait | ○
com.cosminexus.admin.auth.jdbc.sql | ○
com.cosminexus.admin.auth.jdbc.password.type | ○
com.cosminexus.admin.auth.jdbc.password.encrypt | ○
com.cosminexus.admin.auth.jdbc.password.encrypt.ex | ○

（凡例）

J：WebPasswordJDBCLoginModule

○：使用できる

13.3　統合ユーザ管理のセッション管理

この節では，統合ユーザ管理で管理するセッションについて説明します。

＜この節の構成＞

13.3.1　セッションの種類

13.3.2　ログインしたユーザIDの登録

13.3.3　統合ユーザ管理のセッションに登録したユーザIDの削除

13.3.4　JAASのコンフィグレーションファイルの定義例

13.3.5　セッションフェイルオーバ機能を使用したログイン状態の引き継ぎ

13.3.1　セッションの種類

統合ユーザ管理の機能を使う上で存在するセッションとして考えられるものには次の種類があります。

Webコンテナが管理するセッション（HttpSession）
HttpSessionオブジェクトのことを示します。

統合ユーザ管理のセッション
Cosminexus標準ログインモジュールを使用してログインしてからログアウトするまでの期間を示します。
一つのセッション内には複数のユーザがログインできるため，ログインしているすべてのユーザがログアウトしないとセッションは無効になりません。また，このセッションはWebコンテナが管理しているセッションであるHttpSessionと同期しています。そのため，HttpSessionが無効になった場合は，ログインの有無に関係なくセッションは無効になります。
統合ユーザ管理のセッションを制御する機能としては，次の2種類の機能があります。

Cosminexus標準ログインモジュールでは，ログインしたユーザIDとレルム名をセッションに自動で登録および削除できます。

統合ユーザ管理はセッションフェイルオーバ機能に対応しています。統合ユーザ管理のセッションフェイルオーバ機能を有効にすることで，ログイン状態をセッションフェイルオーバ先に引き継げます。なお，セッションフェイルオーバ機能を使用しているときに，ログイン状態を引き継ぐかどうかは選択できます。

カスタムログインモジュールのセッション
各アプリケーションが個々に持つログインしているユーザのセッションを示します。このセッションの概念は，カスタムログインモジュールの仕様に依存します（通常はログインしてからログアウトまでの期間を示します）。
なお，カスタムログインモジュールでは，ログインしたユーザIDとレルム名をセッションに自動で登録および削除できます。

13.3.2　ログインしたユーザIDの登録

ここでは，統合ユーザ管理のセッションにログインしたユーザIDの登録について説明します。

＜この項の構成＞

(1)　ログインしているユーザIDを登録する目的

(2)　ログインしているユーザIDの登録条件

(3)　統合ユーザ管理のセッションに登録される内容

(1)　ログインしているユーザIDを登録する目的

統合ユーザ管理のセッションにログインしているユーザIDを登録することで，次のようなことができます。

JSPタグライブラリの<ua:notLogin>タグで，統合ユーザ管理のセッションでユーザがログインしているかどうかを判断できます。この指定は，任意のレルム名を指定することで，そのレルム内でのログインの有無も判断できます。

(2)　ログインしているユーザIDの登録条件

認証手段を持つCosminexus標準ログインモジュールでは，自動的に統合ユーザ管理のセッションにログインしたユーザIDを登録します。

カスタムログインモジュールの場合，次の条件を満たしたログインモジュールでログインしたユーザIDが，統合ユーザ管理のセッションに登録されます。

カスタムログインモジュールの実装で，commitメソッドによってPrincipalオブジェクトがSubjectに関連づけられていること

統合ユーザ管理フレームワークによって提供されているWebSSOHandlerが，LoginContextクラスのコンストラクタの引数に指定されていること

もし，1回の呼び出しで複数のログインモジュールを呼び出していた場合，認証手段を持つCosminexus標準ログインモジュールまたは上記の条件を満たしたログインモジュールでログインされるまでユーザIDは登録されません。最後まで見つからなかった場合は，統合ユーザ管理のセッションにはログインしたユーザIDは登録されません。

(3)　統合ユーザ管理のセッションに登録される内容

統合ユーザ管理のセッションに登録される内容は，レルム名，ユーザIDおよびログイン時刻の3種類です。

レルム名
jaas.conf（JAASコンフィグレーションファイル）のcom.cosminexus.admin.auth.realmで指定した値が設定されます。このオプションが省略されていた場合は空文字が仮定されます。なお，DelegationLoginModule以外の場合，com.cosminexus.admin.auth.realmの指定は省略できません。

ユーザID
各ログインモジュールのcommitメソッドを呼び出したあと，Subjectから最初に求められたPrincipalオブジェクトのユーザID（getNameメソッドの結果）が設定されます。

ログイン時刻
統合ユーザ管理のセッションにユーザIDを登録時，最初にログインした時刻がユーザ単位に設定されます。

13.3.3　統合ユーザ管理のセッションに登録したユーザIDの削除

認証したSubjectを持つLoginContextクラスのlogoutメソッドが呼ばれたとき，自動的に統合ユーザ管理のセッションに登録されたユーザIDとレルム名が削除されます。

13.3.4　JAASのコンフィグレーションファイルの定義例

jaas.conf（JAASのコンフィグレーションファイル）の定義例を示します。

＜この項の構成＞

(1)　Cosminexusの標準ログインモジュールを使った定義例

(2)　カスタムログインモジュールだけを使用した場合の定義例

(1)　Cosminexusの標準ログインモジュールを使った定義例

JAASのコンフィグレーションファイルで次のように定義されていた場合は，最初に実行したWebPasswordLoginModuleが認証した際のユーザIDおよびレルム名「RealmA」で統合ユーザ管理のセッションに登録します。

Example03 {
 com.cosminexus.admin.auth.login.WebPasswordLoginModule required
                                              //セッションに参加します
   com.cosminexus.admin.auth.realm="RealmA"
   com.cosminexus.admin.auth.ldap.r="0"
   com.cosminexus.admin.auth.ldap.w="1"
   ;
 com.cosminexus.admin.auth.login.DelegationLoginModule required
   com.cosminexus.admin.auth.custom.lm="my.login.MyLoginModule"
   my.login.useracctterm="acctTerm"
   ;
};

(2)　カスタムログインモジュールだけを使用した場合の定義例

JAASのコンフィグレーションファイルで次のように定義されていた場合，最初に実行したMyLoginModule1のcommitメソッドで設定したPrincipalオブジェクトのユーザID（getNameメソッドの値）を使って統合ユーザ管理のセッションにユーザIDを登録します（DelegationLoginModuleがユーザIDを登録します）。

なお，「com.cosminexus.admin.auth.realm」については指定がないため，レルム名として空文字（””）を仮定します。

Example99 {
 com.cosminexus.admin.auth.login.DelegationLoginModule required
                                             //セッションに参加します
   com.cosminexus.admin.auth.custom.lm="my.login.MyLoginModule1"
   ;
 com.cosminexus.admin.auth.login.DelegationLoginModule required
   com.cosminexus.admin.auth.custom.lm="my.login.MyLoginModule2"
   ;
};

ただし，MyLoginModule1がPrincipalオブジェクトをSubjectに設定していない場合は，MyLoginModule2が統合ユーザ管理のセッションにユーザIDを登録する対象になります。もし，MyLoginModule2もPrincipalオブジェクトを設定しない場合は，統合ユーザ管理のセッションにユーザIDを登録しません。

jaas.confの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

13.3.5　セッションフェイルオーバ機能を使用したログイン状態の引き継ぎ

統合ユーザ管理では，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継ぐことができます。

セッションフェイルオーバで引き継がれる情報の一覧を次の表に示します。なお，表中の「API」はJAASのAPIのことです。「カスタムタグ」は統合ユーザ管理で提供されるJSPカスタムタグのことです。

表13-8　セッションフェイルオーバ機能で引き継がれる情報一覧

情報
Cosminexus標準ログインモジュール
カスタムログインモジュール

API
カスタムタグ
API
カスタムタグ

統合ユーザ管理のセッション情報
ログイン状態
（ユーザがログインしているかどうかの状態）
◎
◎
◎
◎

登録されているユーザID/レルム名
◎
◎
◎
◎

パスワード
○
○
－
－

認証情報
Subject
×
×
×
×

Principal
×
×
×
×

ユーザ属性（UserAttributes）
△
△
－
－

ユーザ属性（UserAttributes）以外のCredential（Public/Private）
×
×
×
×

（凡例）

◎：引き継げる

○：オプションによって選択できる

△：手動で対応する必要がある

×：引き継げない

－：該当しない

なお，07-00よりも前のバージョンで作成したユーザアプリケーションをセッションフェイルオーバに対応させる場合，ユーザアプリケーションの処理の一部を見直す必要があります。セッションフェイルオーバに対応した統合ユーザ管理のアプリケーションの開発方法については，「13.10　セッションフェイルオーバ機能使用時のユーザ認証の実装」を参照してください。また，セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

13.4　シングルサインオンの利用方法

この節では，シングルサインオンの利用方法について説明します。シングルサインオンとは，一度のログイン処理で，ユーザIDが異なる複数のシステムをシームレスに使用できるようにするための機能です。

＜この節の構成＞

13.4.1　シングルサインオンをするために必要な手順

13.4.2　既存アプリケーションで行っているユーザ管理の適用

13.4.1　シングルサインオンをするために必要な手順

シングルサインオンを利用するためには，シングルサインオンを使用するすべてのカスタムログインモジュールおよびCosminexus標準ログインモジュール（ユーザ認証をするログインモジュール）をWebSSOLoginModuleで呼び出す必要があります。

シングルサインオンへの切り替えはjaas.conf（JAASのコンフィグレーションファイル）で定義します。

例えば，シングルサインオンを適用する前は次のようにWebPasswordLoginModuleを使ってユーザ認証をしていたとします。

AP1 {
 com.cosminexus.admin.auth.login.WebPasswordLoginModule Requisite
   com.cosminexus.admin.auth.ldap.r="3"
   com.cosminexus.admin.auth.ldap.w="2"
   com.cosminexus.admin.auth.realm=XXXcompany;
};

シングルサインオンを適用するには次の太字に示す修正をします。

AP1 {
 com.cosminexus.admin.auth.sso.login.WebSSOLoginModule Requisite
   com.cosminexus.admin.auth.ldap.r="3"
   com.cosminexus.admin.auth.ldap.w="2"
   com.cosminexus.admin.auth.realm=XXXcompany;
};

シングルサインオンをするすべてのログインモジュールの定義は，この例で示すような修正で変更したあとにJ2EEサーバを起動することで利用できます。

13.4.2　既存アプリケーションで行っているユーザ管理の適用

利用しているアプリケーションがすでにユーザ管理を行っている場合に，統合ユーザ管理のシングルサインオンを適用するには，次の表に示す条件を満たしている必要があります。

表13-9　統合ユーザ管理のシングルサインオンの適用に必要な条件

LoginModuleの有無 | 条件１ | 条件２ | 適用 | 適用方法
ある | 改造できる。 | － | ○ | sharedStateで認証情報が渡せるようにして呼び出します。
改造できない。 | sharedStateで認証情報が渡せる。 | ○ | jaas.conf（JAASのコンフィグレーションファイル）をシングルサインオンライブラリ用に変更します。
sharedStateで認証情報が渡せない。 | × | －
ない | login用APIが公開されている。 | － | ○ | ログインモジュールを作成します。
login用APIが公開されていない。 | － | × | －

（凡例）　○：適用できる　　×：適用できない　　－：該当しない

なお，Cosminexus標準ログインモジュールのWebPasswordLoginModule，WebCertificateLoginModule，WebPasswordLDAPLoginModuleおよびWebPasswordJDBCLoginModule（ユーザ認証を行うログインモジュール）は，すべてシングルサインオンを適用できます。

13.5　カスタムログインモジュールの利用

Cosminexus標準ログインモジュール以外を使用して各アプリケーションのユーザ認証をする場合，カスタムログインモジュールを作成して，Cosminexus標準モジュールと組み合わせて使用できます。

カスタムログインモジュールは，アプリケーション開発者が実装します。

＜この節の構成＞

13.5.1　カスタムログインモジュールとは

13.5.2　カスタムログインモジュールの呼び出し

13.5.1　カスタムログインモジュールとは

カスタムログインモジュールは，Cosminexus標準ログインモジュール以外を使用してアプリケーションのユーザ認証をしたい場合に作成するクラスです。このクラスは，JAASのSPIであるLoginModuleインタフェースを継承して作成します。

カスタムログインモジュールは，次に示すディレクトリに格納します。

Windowsの場合
<Cosminexusインストールディレクトリ>¥manager¥modules

UNIXの場合
/opt/Cosminexus/manager/modules

なお，カスタムログインモジュールの格納先ディレクトリは，ua.conf（統合ユーザ管理のコンフィグレーションファイル）の，com.cosminexus.admin.auth.custom.modulesで変更できます。

13.5.2　カスタムログインモジュールの呼び出し

カスタムログインモジュールは，Cosminexus標準ログインモジュールであるDelegationLoginModuleまたはWebSSOLoginModuleのどちらかで呼び出します。

DelegationLoginModule
シングルサインオンの機能を利用しない場合に使用します。

WebSSOLoginModule
シングルサインオンの機能を利用する場合に使用します。

また，カスタムログインモジュールをCosminexus標準ログインモジュールから呼び出すことで，統合ユーザ管理が管理しているログインセッション管理に参加できます。このセッションはWebコンテナのセッション管理とは別です。統合ユーザ管理のセッションについては，「13.3　統合ユーザ管理のセッション管理」を参照してください。

カスタムログインモジュールは，DelegationLoginModuleまたはWebSSOLoginModuleのどちらかのログインモジュールから呼びされます。これらのログインモジュールは，呼び出したカスタムログインモジュールで認証が成功すると自動的に統合ユーザ管理のセッションに参加します。統合ユーザ管理のセッション登録時に必要なユーザIDは，Subjectに関連づけられているPrincipalオブジェクトから取得します。

シングルサインオン機能を使用する場合は，WebSSOLoginModuleを使用します。この場合，2回目のカスタムログインモジュールの呼び出しでは，最初に統合ユーザ管理のセッションに参加したユーザIDをキーにシングルサインオン情報リポジトリから必要な認証情報が取得されてから，カスタムログインモジュールに渡されます。リポジトリで暗号化して保存していたものは，復号化してから渡されます。

カスタムログインモジュールの実装方法については，「13.11　カスタムログインモジュールの実装」を参照してください。

13.6　統合ユーザ管理フレームワークが提供するAPIの概要

統合ユーザ管理フレームワークでは，認証処理の呼び出し処理をするアプリケーションを開発するために，JSPのタグライブラリおよび統合ユーザ管理フレームワークのライブラリが提供されています。必要に応じて使用してください。

統合ユーザ管理フレームワークで使用するAPIの詳細については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この節の構成＞

13.6.1　JSPタグライブラリ

13.6.2　統合ユーザ管理フレームワークのライブラリ

13.6.1　JSPタグライブラリ

統合ユーザ管理フレームワークでは，JSPで統合ユーザ管理フレームワークの機能を容易に利用するためのJSPタグライブラリを提供します。アプリケーション開発者（またはWebデザイナ）は，Javaプログラムによる認証処理の詳細を気にすることなく，容易にJSPを開発できます。

統合ユーザ管理フレームワークのログインモジュールとしてCosminexus標準ログインモジュールを使用する場合，JSPタグライブラリを使用して，ユーザ情報を参照できます。

13.6.2　統合ユーザ管理フレームワークのライブラリ

統合ユーザ管理フレームワークは，次の2種類で構成されています。

ユーザ認証ライブラリ
LDAPディレクトリサーバで構築されたユーザ情報リポジトリの情報を基にユーザ認証をして，認証したユーザの情報をアプリケーションに提供するJAAS対応ユーザ管理用ライブラリです。

シングルサインオンライブラリ
ユーザマッピング情報の入ったシングルサインオン情報リポジトリの情報を基にユーザマッピングをして，シングルサインオンを実現するライブラリです。

ユーザ認証ライブラリおよびシングルサインオンライブラリの位置づけを次に示します。

次の図に示すように，ユーザ認証ライブラリは単体でアプリケーションの認証に使用できます。また，シングルサインオンライブラリと協調動作し，マッピングされたユーザの認証をすることもあります。

図13-21　ユーザ認証ライブラリおよびシングルサインオンライブラリの位置づけ

13.7　統合ユーザ管理フレームワークによるユーザ認証の実装の概要

統合ユーザ管理フレームワークとは，統合ユーザ管理でのユーザ認証を実現するフレームワークです。JAASに準拠したユーザ認証を，Cosminexus標準のログインモジュールとして提供します。統合ユーザ管理フレームワークを使用することで，独自に認証モジュールを開発しなくても，ユーザ認証を容易に実装できます。

統合ユーザ管理フレームワークによるユーザ認証は，APIを使用して実装します。また，ユーザ認証を容易に実装するためのタグライブラリを使用することもできます。APIまたはタグライブラリを使用してユーザ認証を実装する場合，最初に，サーブレットやJSPでユーザ認証を行うログインモジュールを呼び出します。呼び出したログインモジュールによって認証を行い，処理が終わったところでログアウトします。

Cosminexus標準のログインモジュール以外の認証モジュールを使用する場合は，カスタムログインモジュールとして作成します。ログインモジュールの種類およびログイン処理の流れについては，「13.1.3　Java標準仕様（JAAS）に準拠したユーザ認証の概要」，および「13.1.6　統合ユーザ管理の処理の流れ」を参照してください。

ここでは，APIとタグライブラリを使用したユーザ認証の実装方法，およびカスタムログインモジュールの作成方法について説明します。

参考

Cosminexusでは，統合ユーザ管理フレームワークの動作確認用のサンプルプログラムを提供します。次に示すファイルに実行手順が記述されていますので，その手順に従って実行してください。

<Cosminexusのインストールディレクトリ>¥manager¥examples¥ua¥index.html

13.8　APIを使用したユーザ認証の実装

APIを使用した場合のログインからログアウトまでの実装方法について説明します。また，次の内容についても説明します。

HttpSessionにjava.io.Serializableを継承したSubjectを格納する場合の実装

パスワード認証時の暗号拡張の実装

なお，統合ユーザ管理フレームワークで提供するAPIの機能や文法については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この節の構成＞

13.8.1　ログイン（APIを使用する場合）

13.8.2　ユーザIDの取得（APIを使用する場合）

13.8.3　ユーザ属性の取得（APIを使用する場合）

13.8.4　ログアウト（APIを使用する場合）

13.8.5　HttpSessionにjava.io.Serializableを継承したSubjectを格納する場合の実装

13.8.6　パスワード認証時の暗号拡張の実装

13.8.1　ログイン（APIを使用する場合）

統合ユーザ管理フレームワークを使用してユーザ認証をする場合，ログイン時にサーブレットやJSPなどでログインモジュールを呼び出す処理を実装します。ログインモジュールを使用するには，JAASのコンフィグレーションファイルの設定が必要です。JAASのコンフィグレーションファイルの設定内容については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

次に，APIを使用した場合の，ログインの実装例を示します。

<%@ page import="com.cosminexus.admin.auth.callback.WebPasswordHandler" %>
<%@ page import="javax.security.auth.login.LoginContext" %>
...
<%LoginContext lc = new LoginContext("Portal",
   new WebPasswordHandler(request, response, null, "login.html", true));
 try { lc.login(); } catch (LoginException e) { ... }
%>
...

例では，LoginContextクラスからインスタンスを生成し，その引数として，JAASのコンフィグレーションファイルのPortalエントリに記述された認証モジュールを使用するように指定しています。requestにcom.cosminexus.admin.auth.nameパラメタおよびcom.cosminexus.admin.auth.passwordパラメタが設定されている場合には，これらのパラメタを使用して認証します。そうでない場合は，login.htmlを呼び出し，ユーザから認証情報（ユーザIDとパスワード）を取得します。

13.8.2　ユーザIDの取得（APIを使用する場合）

認証が完了したあと，認証したユーザIDは，Principalオブジェクト（java.security.Principal）としてSubjectに格納されています。ユーザIDを取得する場合の実装例を次に示します。

<%@ page import="javax.security.auth.Subject" %>
<%@ page import="java.security.Principal" %>
...
<%
 ...
 Subject subject = lc.getSubject();
 Principal principal = (Principal)subject.getPrincipals().iterator().next();
 String userid = principal.getName();
%>
...

SubjectからPrincipalが格納されているiteratorを取り出し，その1番目に格納されている値をPrincipalオブジェクトに型変換してから，PrincipalオブジェクトのgetNameメソッドでユーザIDを取得しています。

13.8.3　ユーザ属性の取得（APIを使用する場合）

ユーザ属性を取得するには，ログイン時に取得したい属性の一覧を指定する必要があります。次に，ユーザ属性の一覧を指定する場合のログイン処理の実装例を示します。

<%@ page import="com.cosminexus.admin.auth.callback.WebPasswordHandler" %>
<%@ page import="com.cosminexus.admin.auth.AttributeEntry" %>
<%@ page import="javax.security.auth.login.LoginContext" %>
...
<%
 AttributeEntry[] attributes = new AttributeEntry[2];
 attributes[0] = new AttributeEntry("cn", "full name", null);
 attributes[1] = new AttributeEntry("employeeNumber", "employee ID", null);
 LoginContext lc = new LoginContext("Portal",
   new WebPasswordHandler(request, response, attributes, "login.html", true));
 try { lc.login(); } catch (LoginException e) { ... }
%>
...

属性の一覧に従って属性をリポジトリから取得し，UserAttributesオブジェクトに設定します。取得した属性は，java.lang.Object型として管理されています。使用するには，UserAttributesオブジェクトのメソッドを使用して，目的の属性を取得するところから始めます。

LoginContext lc = new ...              // LoginContextクラスのインスタンス化
...
Subject subject  = lc.getSubject();
Iterator it = subject.getPublicCredentials().iterator();
UserAttributes ua= (UserAttributes)it.next();   // uaにUserAttributesの
...                                             // リファレンスが格納される。

属性の値を参照するには，UserAttributesオブジェクトに対して，次に示すgetAttributeメソッドを使用します（String型の場合）。

String role = (String)ua.getAttribute("Portal Role");

getAttributeメソッドでユーザ属性を取得する場合の実装例を次に示します。

<%@ page import="com.cosminexus.admin.auth.UserAttributes" %>
<%@ page import="javax.security.auth.Subject" %>
...
<%
 ...
 Subject subject = lc.getSubject();
 UserAttributes attrs = (UserAttributes)subject.getPublicCredentials().iterator().next();
 String fullname = (String)attrs.getAttribute("full name");
 String eid = (String)attrs.getAttribute("employee ID");
%>
...

ユーザ情報参照，取得時の注意事項

UserAttributesの値は参照専用です。内容を変更してもリポジトリには反映されません。また，ユーザ認証ライブラリでは，取得した属性について何も加工しません。

登録されている属性は，String型だけです。

属性の一覧で指定された属性がない場合は，nullが設定されます。

13.8.4　ログアウト（APIを使用する場合）

ログアウトの実装例を次に示します。

...
<%
 try { lc.logout(); } catch (LoginException e) { ... }
%>
...

セッションタイムアウト時にログアウトするには，HttpSessionBindingListenerインタフェースを継承したオブジェクトをセッションに設定します。

...
<%
 session.setAttribute("loginContext", lc);
%>
...

<%@ page import="javax.security.auth.login.LoginContext" %>
...
<%  session.setAttribute("logoutObject",
                new HttpSessionBindingListener() {
                  public void valueBound(HttpSessionBindingEvent event) {}
                  public void valueUnbound(HttpSessionBindingEvent event) {
                    LoginContext lc =
 (LoginContext)event.getSession().getAttribute("loginContext");
                    try { lc.logout(); } catch (LoginException e) { ... };
                  }
                };);
%>
...

13.8.5　HttpSessionにjava.io.Serializableを継承したSubjectを格納する場合の実装

HttpSessionに設定するオブジェクトは，java.io.Serializableインタフェースを継承したオブジェクトであることが推奨されます。また，HttpSessionには，java.io.Serializableインタフェースを継承したSubjectを格納して，ログアウトする方法が推奨されます。

なお，ログイン後にSubjectに関連づけられるユーザ属性（UserAttributes）をセッションフェイルオーバで引き継がせるには，HttpSessionにSubjectを格納する必要があります。ここでは，HttpSessionにjava.io.Serializableインタフェースを継承したSubjectを格納する場合のログインとログアウトの実装例を示します。

＜この項の構成＞

(1)　ログイン

(2)　ログアウト

(1)　ログイン

ログインでは，ログインが成功したSubjectをHttpSessionに登録します。次に，HttpSessionにSubjectを格納する場合のログインの実装例を示します。

<%
 LoginContext lc = new LoginContext("Portal",
   new WebPasswordHandler(request, response, null, "login.html", true));
 try {
   lc.login();
    session.setAttribute("ExampleSubject", lc.getSubject());
    session.setAttribute("ExampleCredential", lc.getSubject().getPublicCredentials().iterator().next());
 } catch (LoginException e) { ... }%
>
...

(2)　ログアウト

ログアウトは，HttpSessionに登録されているSubjectを使用して行います。次に，ユーザ属性がある場合のログアウトの実装例を示します。

<%
 try {
   Subject subject = (Subject)session.getAttribute("ExampleSubject");
   LoginContext lc = new LoginContext("Example", subject);
   session.removeAttribute("ExampleCredential");
   session.removeAttribute("ExampleSubject");
   lc.logout();
 } catch (LoginException e) { ... }
%>
...

セッションタイムアウト時にログアウトするためには，HttpSessionBindingListenerインタフェースを実装したオブジェクトを，HttpSessionオブジェクトに設定します。次に，セッションタイムアウト時のログアウトの実装例を示します。

<%
 LoginContext lc = new LoginContext("Portal",
   new WebPasswordHandler(request, response, null, "login.html", true));
 try {
   lc.login();
    session.setAttribute("logoutObject",
       new MyListener("Portal", "ExampleSubject", "ExampleCredential"));
   session.setAttribute("ExampleSubject", lc.getSubject());
   session.setAttribute("ExampleCredential",
   lc.getSubject().getPublicCredentials().iterator().next());

 } catch (LoginException e) { ... }
%>
<%!
 class MyListener implements
         HttpSessionBindingListener, java.io.Serializable {
     String name;
     String subjectName;
     String attrsName;
     public MyListener(String name, String subjectName, String attrsName) {
         this.name = name;
         this.subjectName = subjectName;
         this.attrsName = attrsName;
     }
     public void valueBound(HttpSessionBindingEvent ev) {}
     public void valueUnbound(HttpSessionBindingEvent ev) {
         Subject subject =
          (Subject)ev.getSession().getAttribute(subjectName);
         ev.getSession().removeAttribute(attrsName);
         ev.getSession().removeAttribute(subjectName);
         try {
             LoginContext ctx = new LoginContext(name, subject);
             ctx.logout();
         } catch (LoginException e) {}
     }
 }
%>

13.8.6　パスワード認証時の暗号拡張の実装

統合ユーザ管理フレームワークで標準提供されている，パスワードの暗号の形式（SHA-1/MD5/平文）以外でも，パスワード認証ができます。この暗号拡張の機能を利用するには，あらかじめ実装クラスを作成する必要があります。

ここでは，暗号拡張できるログインモジュールと，暗号拡張で使用するクラスの実装方法について説明します。暗号拡張の概要については，「13.2.9　パスワード認証時の暗号拡張」を参照してください。

＜この項の構成＞

(1)　暗号拡張を利用できるログインモジュール

(2)　暗号拡張で使用するクラスの実装方法

(1)　暗号拡張を利用できるログインモジュール

WebPasswordLoginModuleまたはWebPasswordJDBCLoginModuleを使用する場合に，暗号拡張を利用できます。

(2)　暗号拡張で使用するクラスの実装方法

暗号拡張を実装する場合，com.cosminexus.admin.auth.security.PasswordCryptographyクラスを継承して処理を実装します。作成したクラスは，次に示すディレクトリの下にクラスファイルで格納します。

<Cosminexusのインストールディレクトリ>¥manager¥modules

なお，格納先ディレクトリは，統合ユーザ管理フレームワークのコンフィグレーションファイル（ua.conf）の，com.cosminexus.admin.auth.custom.modulesで変更できます。

SHA-1形式でbyte型の配列で比較する場合の実装例を次に示します。

package my;

import com.cosminexus.admin.auth.security.PasswordCryptography;
import java.security.*;

public class CustomCryptography implements PasswordCryptography
{
 public byte[]encrypt (byte[] plain) {
   byte[] encryptedPassword = null;
   try{
     MessageDigest md = MessageDigest.getInstance("SHA");
     md.update(plain);
     encryptedPassword = md.digest();
   } catch (NoSuchAlgorithmException e) {
     encryptedPassword = plain;
   }
   return encryptedPassword;
 }
}

13.9　タグライブラリを使用したユーザ認証の実装

タグライブラリを使用した場合のログインからログアウトまでの実装方法について説明します。タグライブラリのタグの説明と，タグ属性については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

なお，タグライブラリを使用する場合は，プログラムの実装のほかに，DD（web.xml）の編集が必要になります。タグライブラリ使用時のDDの編集については，マニュアル「Cosminexus　システム構築ガイド」に記載されている，JSPタグライブラリを使用している場合の設定についての説明を参照してください。

＜この節の構成＞

13.9.1　ログイン（タグライブラリを使用する場合）

13.9.2　ユーザIDの取得（タグライブラリを使用する場合）

13.9.3　ユーザ属性の取得（タグライブラリを使用する場合）

13.9.4　ログアウト（タグライブラリを使用する場合）

13.9.1　ログイン（タグライブラリを使用する場合）

統合ユーザ管理フレームワークを使用したユーザ認証を行う場合，ログイン時にサーブレットやJSPなどでログインモジュールを呼び出す処理を実装します。ログインモジュールを使用するには，JAASのコンフィグレーションファイルの設定が必要です。JAASのコンフィグレーションファイルの設定については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

JSPの<ua:login/>タグを使用してログインするには，HTTPリクエストオブジェクトに，com.cosminexus.admin.auth.nameパラメタ，およびcom.cosminexus.admin.auth.passwordパラメタが設定されている必要があります。したがって，まず，次に示すようなログイン用のフォームを準備して，パラメタを設定できるようにします。

<html>
<body>
<form action="auth.jsp" method="post">
<table>
<tr>
<td>username</td>
<td><input type="text" name="com.cosminexus.admin.auth.name" /></td>
</tr>
<tr>
<td>password</td>
<td><input type="password" name="com.cosminexus.admin.auth.password" />
</td>
</tr>
</table>
<br />
<input type="submit" value="Login" />
<input type="reset" value="Reset" />
</form>
</body>
</html>

次に，<ua:login/>タグを使用して，JAASコンフィグレーションファイルのPortalエントリに記述された認証モジュールを使用してログインします。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>
<%@ page errorPage="error.jsp" %>

<ua:login id="lc" entry="Portal" />
...

タグライブラリの仕様によって，タグの処理中に発生した例外は，すべてJspExceptionとなります。<ua:login/>タグの処理中に発生した例外をより細かく検出する場合は，<ua:exception>Body </ua:exception>タグを使用します。次の例では，発生した例外を，検出するJSP（loginError.jsp）に転送しています。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>
<ua:login id="lc" entry="Portal" excepId="ex" excepScope="session" />
<ua:exception name="ex" ><jsp:forward page="loginError.jsp" /></ua:exception>
...

例外を検出するJSP（loginError.jsp）では，例外の内容に応じて返すメッセージを選択しています。

<%@ page contentType=”text/html; charset=Shift_JIS” %>
<%@ taglib uri=”http://cosminexus.com/admin/auth/uatags” prefix=”ua” %>

<html>
<body>
<ua:exception name="ex" type="javax.security.auth.login.FailedLoginException">
ユーザIDかパスワードが間違っています。<br />
</ua:exception>
<ua:exception name="ex" type="javax.security.auth.login.AccountExpiredException">
アカウントの有効期限が切れています。<br />
</ua:exception>
<ua:exception name="ex" type="javax.security.auth.login.CredentialExpiredException">
パスワードの有効期限が切れています。<br />
</ua:exception>
<ua:exception name="ex" >
例外が発生しました。<br />
<%= e.toString() %><br />
</ua:exception>
</body>
</html>

ポイント

ログインしているかどうかを確認する方法

各JSPページの先頭に<ua:notLogin>Body</ua:notLogin>タグを記述することで，そのJSPページを処理する前にログインしているかどうかを確認できます。

<%@ page contentType=”text/html; charset=Shift_JIS” %>
<%@ taglib uri=”http://cosminexus.com/admin/auth/uatags” prefix=”ua” %>
...
<ua:notLogin>
<a href=”login.html”>ログインしてください。</a>
</ua:notLogin>
...

13.9.2　ユーザIDの取得（タグライブラリを使用する場合）

認証が完了したあと，認証したユーザIDは<ua:getPrincipalName>タグを使用して，表示したり，取得したりできます。次に，ユーザIDを表示する例を示します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>
...
User ID: <ua:getPrincipalName name="lc" />
...

<ua:getPrincipalName>タグのname属性に，ログイン時に指定したLoginContextの識別子（lc）を指定します。

次に，ユーザIDを取得する例を示します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>
...
<ua:getPrincipalName name="lc" id="userid" />User ID: <%= userid %>
...

<ua:getPrincipalName>タグのname属性に加え，id属性を指定します。id属性では，ユーザIDを参照するインスタンスを識別する識別子を指定します。

13.9.3　ユーザ属性の取得（タグライブラリを使用する場合）

ユーザ属性を取得するには，<ua:attributeEntries>タグを使用して取得したい属性の一覧を指定する必要があります。次に，ユーザ属性の一覧を指定する場合の実装例を示します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>

<ua:attributeEntries id="ae">
 <ua:attributeEntry attrName="cn" alias="full name" />
 ...
</ua:attributeEntries>
<ua:login id="lc" entry="Portal" attrEntName="ae" />
...
Full Name: <ua:getAttribute name="lc" attrName="full name" />
...

ユーザ属性の一覧を指定したあとに，<ua:getAttribute>タグを使用して，ユーザ属性を取得します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>

<ua:login id="lc" entry="Portal" attrFile="MyAttrs.csv" />
...
<ua:getAttribute name="lc" attrName="full name" id="fullname" />
Full Name: <%= fullname %>
...

ユーザ情報参照，取得時の注意事項

UserAttributesの値は参照専用です。内容を変更してもリポジトリには反映されません。また，ユーザ認証ライブラリでは，取得した属性について何も加工しません。

登録されている属性は，String型だけです。

属性の一覧で指定された属性がない場合は，nullが設定されます。

13.9.4　ログアウト（タグライブラリを使用する場合）

ログアウトの実装例を次に示します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>

<ua:logout name="lc" />
...

<ua:login/>タグに対応する<ua:logout/>タグを明示的に記述しなかった場合は，セッション切断時に暗黙的にログアウトされます。

13.10　セッションフェイルオーバ機能使用時のユーザ認証の実装

統合ユーザ管理では，セッションフェイルオーバ機能を使用して，障害発生時のログイン状態を別のJ2EEサーバに引き継ぐことができます。

ここでは，セッションフェイルオーバ機能で引き継げる情報，ユーザ認証の実装方法，およびDDの定義方法について説明します。

＜この節の構成＞

13.10.1　セッションフェイルオーバ機能で引き継げるセッション情報と認証情報

13.10.2　セッションフェイルオーバ機能使用時のユーザ認証の実装

13.10.3　セッションフェイルオーバ機能使用時のDDの定義

13.10.1　セッションフェイルオーバ機能で引き継げるセッション情報と認証情報

セッションフェイルオーバ機能で引き継ぐことができる情報の一覧を次の表に示します。なお，表中のAPIはJAASのAPIを，カスタムタグは統合ユーザ管理が提供するJSPカスタムタグを示します。

表13-10　セッションフェイルオーバ機能で引き継げる情報

情報
Cosminexus標準ログインモジュール
カスタムログインモジュール

API
カスタムタグ
API
カスタムタグ

統合ユーザ管理のセッション情報
ログインの状態
（ユーザがログインしているかどうか）
◎
◎
◎
◎

登録されているユーザIDおよびレルム名
◎
◎
◎
◎

パスワード
○
○
－
－

認証情報
Subject
×
×
×
×

Principal
×
×
×
×

ユーザ属性（UserAttributes）
△
△
－
－

ユーザ属性（UserAttributes）以外のCredential（Public／Private）
×
×
×
×

（凡例）

◎：引き継げます。

○：オプションによって，引き継ぐかどうかを選択できます。

△：手動で対応する必要があります。

×：引き継げません。

－：対象外となります。

13.10.2　セッションフェイルオーバ機能使用時のユーザ認証の実装

セッションフェイルオーバ機能使用時のログインとログアウトの実装方法，および実装時の注意点について説明します。

＜この項の構成＞

(1)　APIを使用する場合

(2)　タグライブラリを使用する場合

(3)　シングルサインオンを使用する場合の注意

(1)　APIを使用する場合

セッションフェイルオーバ機能では，String型以外のオブジェクトは引き継げません。したがって，ユーザ属性（UserAttributes）を引き継ぐには，必要な文字情報を取り出して，グローバルセッション情報に格納する必要があります。

ここでは，セッションフェイルオーバ機能使用時のユーザ認証の実装例を示します。

(a)　ログイン（セッションフェイルオーバ機能使用時）

ログインでは，ログインが成功したときのユーザIDと必要なユーザ情報をグローバルセッションに登録しておきます。

<%
 LoginContext lc = new LoginContext("Example",
   new WebPasswordHandler(request, response, null, "login.html", true));
 try {
   lc.login();
   Subject subject = lc.getSubject();
   session.setAttribute("ExampleSubject", subject);   // SubjectをHttpSessionに格納
   String uid = ((Principal)subject.getPrincipals().iterator().next()).getName();
   session.setAttribute("ExampleUserID", uid);   //ユーザIDをグローバルセッションに格納します。
   UserAttributes attr = (UserAttributes)lc.getSubject().getPublicCredentials().iterator().next();
   session.setAttribute("telephoneNumber", attr.getAttribute("tel"));
                                                      //電話番号をグローバルセッションに格納します。
 } catch (LoginException e) { ... }
%>

ユーザIDはSFOサーバの障害発生時に備えて，読み取り専用で登録することを推奨します。

(b)　ログアウト（セッションフェイルオーバ機能使用時）

ログアウトは，ログイン時に取得したSubjectとグローバルセッションに登録されているユーザIDとHttpSessionを使って行います。ただし，フェイルオーバが発生したあとは，Subjectオブジェクトがnullになっているので，新たにSubjectを生成して指定してください。

<%
 try {
   String uid = (String)session.getAttribute("ExampleUserID");//グローバルセッションからユーザIDを取得
   Subject subject = (Subject)session.getAttribute("ExampleSubject");
   LoginContext lc = new LoginContext("Example",
     (subject != null) ? subject : new Subject(), //Subjectがnullの場合は，新規にSubjectを生成します。
     new WebLogoutHandler(session, uid));         //WebLogoutHandlerをLoginContextに設定します。
   session.removeAttribute("ExampleUserID");
   lc.logout();
 } catch (LoginException e) { ... }
%>

(c)　セッションタイムアウト時のログアウト（セッションフェイルオーバ機能使用時）

セッションタイムアウト時にログアウトするためには，HttpSessionBindingListenerインタフェースを実装したオブジェクトをHttpSessionオブジェクトに設定します。ただし，フェイルオーバ発生後は，HttpSessionが新しく生成されるので登録したオブジェクトはなくなります。画面遷移などのタイミングでオブジェクトがなくなっていないか確認し，なくなっていれば再登録する必要があります。

<%
 LoginContext lc = new LoginContext("Portal",
   new WebPasswordHandler(request, response, null, "login.html", true));
 try {
   lc.login();
   Subject subject = lc.getSubject();
   String uid = ((Principal)subject.getPrincipals().iterator().next()).getName();
   session.setAttribute("PortalSubject", subject);   // SubjectをHttpSessionに格納
   session.setAttribute("PortalUserID", uid);   // ユーザIDをグローバルセッションに格納します。
   session.setAttribute("myLogoutObject",       // セッションタイムアウト時にログアウト処理を
     new MyListener("Portal", "PortalUserID", "PortalSubject")); //行うオブジェクトをHttpSessionに設定。
 } catch (LoginException e) { ... }
%>
<%!
 class MyListener implements                              // セッションタイムアウト時に
     HttpSessionBindingListener, java.io.Serializable {   // ログアウト処理を行うクラス。
   String name;
   String userName;
   String subjectName;
   public MyListener(String name, String userName, String subjectName) {
     this.name = name;
     this.userName = userName;
     this. subjectName = subjectName;
   }
   public void valueBound(HttpSessionBindingEvent ev) {}
   public void valueUnbound(HttpSessionBindingEvent ev) {
     String uid = (String)ev.getSession().getAttribute(userName);
     Subject subject = (Subject)ev.getSession().getAttribute(subjectName);
     try {
       LoginContext ctx = new LoginContext(name,
         (subject != null) ? subject : new Subject(),
         new WebLogoutHandler(ev.getSession(), uid));
       ctx.logout();
     } catch (LoginException e) { ... }
   }
 }
%>

(d)　ログイン状態のチェック（セッションフェイルオーバ機能使用時）

フェイルオーバが発生した場合，ログアウトするために登録したHttpSessionBindingListenerインタフェースの実装したオブジェクトがなくなっています。したがって，オブジェクトがないか確認し，なくなっていれば再登録する必要があります。

<%!
 if (LoginUtil.check(request, response)) {
   HttpSession session = request.getSession();
   if (session.getAttribute("myLogoutObject") == null) {
     session.setAttribute("myLogoutObject",
         new MyListener("Portal", session.getAttribute("userid"), "PortalSubject");
   }
 } else {
   //ログインしていない場合の処理
 }
%>

(2)　タグライブラリを使用する場合

セッションフェイルオーバ機能使用時は，ユーザ属性（UserAttributes）が引き継げないため，次のタグの使用が制限されます。

<ua:getAttributes/>

id属性を指定した場合は，スクリプト変数にnullを代入します。id属性を指定していない場合は，何もしません。

<ua:getAttribute/>

id属性を指定した場合は，スクリプト変数にnullを代入します。id属性を指定していない場合は，何もしません。

<ua:getAttributeNames/>

id属性を指定した場合は，スクリプト変数にnullを代入します。id属性を指定していない場合は，何もしません。

ユーザ属性（UserAttributes）を引き継ぐには，必要な文字情報を取り出して，グローバルセッション情報に格納する必要があります。

(3)　シングルサインオンを使用する場合の注意

同一レルムおよび同一ユーザで多重ログインするような処理にしないでください。多重ログインが発生した場合，シングルサインオンが正しく機能しない場合があります。

13.10.3　セッションフェイルオーバ機能使用時のDDの定義

統合ユーザ管理でのセッションフェイルオーバ機能は，DD（web.xml）にフィルタ定義を追加することで有効になります。

ここでは，セッションフェイルオーバ機能を使用する場合に定義が必要な，GSInfoKey-RW（グローバルセッション情報として使用する情報（読み込み専用））とGSInfosLengthMax（グローバルセッション情報の最大サイズ）について示します。「12.7.4　DDの定義」の内容とあわせて参照してください。

＜この項の構成＞

(1)　GSInfoKey-RWの定義（統合ユーザ管理・セッションフェイルオーバ機能）

(2)　GSInfosLengthMaxの定義（統合ユーザ管理・セッションフェイルオーバ機能）

(3)　DDの定義例（統合ユーザ管理・セッションフェイルオーバ機能）

(1)　GSInfoKey-RWの定義（統合ユーザ管理・セッションフェイルオーバ機能）

次のパッケージを定義します。

com.cosminexus.admin.auth.user_data

(2)　GSInfosLengthMaxの定義（統合ユーザ管理・セッションフェイルオーバ機能）

次の計算式で求めた統合ユーザ管理で使用する値に，アプリケーションで使用する値を足した値を定義します。なお，式中の1,500と1,200という固定値は，統合ユーザ管理の管理情報を保存するために必要な値です。

APIを使用する場合

パスワード保存機能を使用しない場合

｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋1,200）×レルム数｝×2

パスワード保存機能を使う場合

｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋パスワードの最大長＋1,200）×レルム数｝×2

タグライブラリを使用する場合

パスワード保存機能を使用しない場合

｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋loginタグのid属性値の長さ＋loginタグのentry属性値の長さ＋1,200）×レルム数｝×2

パスワード保存機能を使う場合

｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋loginタグのid属性値の長さ＋loginタグのentry属性値の長さ＋パスワードの最大長＋1,200）×レルム数｝×2

統合ユーザ管理で使用するGSInfosLengthMaxの計算例

条件

APIを使用する。

パスワード保存機能は使用しない。

レルム名の長さが10文字。

ユーザ名の最大長が20文字。

シングルサインオンを行うシステムの数が3（レルム数）。

計算式

｛1,500＋（10＋20＋1,200）×3｝×2＝10,380

設定に誤りがある場合は，セッションフェイルオーバが正しく行われません。

セッションフェイルオーバ機能を使用する場合で，統合ユーザ管理のセッションフェイルオーバ機能を無効にする場合は，統合ユーザ管理のコンフィグレーションファイル（ua.conf）の設定で変更します。統合ユーザ管理のコンフィグレーションファイルについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(3)　DDの定義例（統合ユーザ管理・セッションフェイルオーバ機能）

統合ユーザ管理でセッションフェイルオーバ機能を使用する場合のDDの定義例を示します。

  ：
<filter>
   <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
   <filter-class>com.hitachi.software.was.sfo.web.SFOFilter</filter-class>
   <init-param>
       <param-name>GSInfoKey-RW</param-name>
       <param-value>com.cosminexus.admin.auth.user_data</param-value>
   </init-param>
   <init-param>
       <param-name>GSInfoKey-R</param-name>
       <param-value></param-value>
   </init-param>
   <init-param>
       <param-name>GSInfosLengthMax</param-name>
       <param-value>10380</param-value>
   </init-param>
   <init-param>
       <param-name>SFOServerName</param-name>
       <param-value>sfo_server1</param-value>
   </init-param>
   <init-param>
       <param-name>GIDCookieName</param-name>
       <param-value>GSESSIONID</param-value>
   </init-param>
   <init-param>
       <param-name>LockTimeout</param-name>
       <param-value>30</param-value>
   </init-param>
</filter>
  ：

13.11　カスタムログインモジュールの実装

Cosminexus標準のログインモジュール以外の手段でユーザ認証する場合は，カスタムログインモジュールとして作成して，Cosminexus標準のログインモジュールと連携して使用します。

＜この節の構成＞

13.11.1　Cosminexus標準のログインモジュールと連携するための情報

13.11.2　カスタムログインモジュールの実装時の留意点

13.11.3　カスタムログインモジュールの実装例

13.11.1　Cosminexus標準のログインモジュールと連携するための情報

JAASでは，一度の認証で複数の認証モジュールを順次呼び出せます。これらの認証モジュールでは，LoginModuleインタフェースのinitializeメソッドの第3パラメタに渡されるMapオブジェクト（sharedState）を利用して情報を渡します。ここでは，Cosminexus標準のログインモジュール別に，追加する情報を示します。なお，DelegationLoginModuleおよびWebPasswordJDBCLoginModuleでは，情報は追加しません。

＜この項の構成＞

(1)　WebPasswordLoginModule，WebCertificateLoginModule，およびWebPasswordLDAPLoginModule

(2)　WebSSOLoginModule

(1)　WebPasswordLoginModule，WebCertificateLoginModule，およびWebPasswordLDAPLoginModule

WebPasswordLoginModule，WebCertificateLoginModule，およびWebPasswordLDAPLoginModuleでは，次のLoginModuleを呼び出す前にsharedStateに次に示す情報を追加します。

キー：com.cosminexus.admin.auth.userattributes

値の型：UserAttributes

説明：Subjectに関連づけたユーザ属性を格納したUserAttributesオブジェクトを参照します。

設定されるタイミング：commitメソッド終了直前

(2)　WebSSOLoginModule

同一セッション内で認証済みであれば，そのユーザに対応するユーザマッピングから該当レルムのユーザの認証情報を取得して，カスタムログインモジュールを呼び出す前に次に示す情報をsharedStateに追加します。該当セッションで初めて認証する場合や，ユーザマッピング上に認証情報がない場合は，情報を追加しません。

キー：com.cosminexus.admin.auth.sso.userid

値の型：String

説明：ユーザマッピングのUSERIDで定義した値です。

設定されるタイミング：カスタムログインモジュールのloginメソッドを呼び出す直前

キー：com.cosminexus.admin.auth.sso.secdat

値の型：String

説明：ユーザマッピングのSECRETDATAで定義した値です。sharedStateに格納される場合は，復号化されて格納されます。

設定されるタイミング：カスタムログインモジュールのloginメソッドを呼び出す直前

キー：com.cosminexus.admin.auth.sso.pubdat

値の型：String

説明：ユーザマッピングのPUBLICDATAで定義した値です。

設定されるタイミング：カスタムログインモジュールのloginメソッドを呼び出す直前

また，各キーについては，統合ユーザ管理フレームワークのコンフィグレーションファイルで変更できます。すでにカスタムログインモジュールがあり，sharedStateから認証情報を取得できる場合，そのカスタムログインモジュールの仕様に合わせたキーにできます。コンフィグレーションファイルの設定内容については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

13.11.2　カスタムログインモジュールの実装時の留意点

カスタムログインモジュールを作成するには，JAASのSPIであるLoginModuleインタフェースを継承して必要な処理を実装します。カスタムログインモジュールを実装する場合の，LoginModuleインタフェースの実装時の留意点を示します。また，ユーザIDを管理するPrincipalオブジェクトの実装時の留意点を示します。

＜この項の構成＞

(1)　LoginModuleインタフェースの実装時の留意点

(2)　Principalオブジェクトの実装時の留意点

(1)　LoginModuleインタフェースの実装時の留意点

loginメソッド
シングルサインオンに対応するには，最初にsharedState内にユーザIDとパスワードが指定されていないか判断してください。なお，sharedStateからユーザIDとパスワードを取得するための名前については，統合ユーザ管理フレームワークのコンフィグレーションファイルで指定できます。

commitメソッド
PrincipalオブジェクトをSubjectに設定してください。Principalオブジェクトが複数ある場合，WebSSOLoginModuleおよびDelegationLoginModuleでは最初に見つかったPrincipalオブジェクトを使用して統合ユーザ管理のセッションへユーザIDの登録をします。シングルサインオンの場合は，最初にログインしたユーザIDを認識するために使用します。

logoutメソッド
logoutメソッドは，commitメソッドでSubjectに関連づけたPrincipalオブジェクトやCredential（ユーザ属性など）を削除しますが，logoutメソッド使用時に次の現象が発生することがあります。

logoutメソッドが呼ばれたとき，SubjectにCredentialが設定されない

ログアウト時にカスタムログインモジュールのcommitメソッドまたはloginメソッドで設定したメンバ属性の値が参照できない

Credentialが設定されない現象は，シリアライズ化できるSubjectオブジェクトのシリアライズ対象に，Credentialが含まれていないために発生することがあります。
ログアウト時にメンバ属性の値が参照できない現象は，JAASのLoginContext（LoginModuleを含む）がシリアライズ化されたオブジェクトではないために発生します。LoginContextはHttpSessionにSubjectオブジェクトを格納し，ログアウトするためにSubjectオブジェクトから新たなログインモジュールのインスタンスを生成するため，commitメソッドやloginメソッドで設定したメンバ属性の値が参照できなくなります。

(2)　Principalオブジェクトの実装時の留意点

Principalオブジェクトは，java.security.Principalとjava.io.Serializableのインタフェースを継承して実装してください。

13.11.3　カスタムログインモジュールの実装例

カスタムログインモジュールおよびPrincipalオブジェクトの実装例を示します。

カスタムログインモジュールの実装例では，最初にセッションフェイルオーバ機能を使用しない場合の例を示します。セッションフェイルオーバ機能を使用する場合の例は，セッションフェイルオーバ機能を使用しない場合と異なる部分だけ示します。

＜この項の構成＞

(1)　セッションフェイルオーバ機能を使用しない場合の実装例

(2)　セッションフェイルオーバ機能を使用する場合の実装例

(3)　Principalオブジェクトの実装例

(1)　セッションフェイルオーバ機能を使用しない場合の実装例

セッションフェイルオーバ機能を使用しない場合のカスタムログインモジュールの実装例を示します。

/**
* LoginModuleの実装クラスは，LoginModuleインタフェースを継承して作成します。
*
*/
public class ExampleLoginModule implements LoginModule
{
   // initialize()メソッドに渡ってきたパラメタの値を各メソッドで参照するために使用されます。
   private Subject subject;
   private CallbackHandler callbackHandler;
   private Map sharedState;
   private Map options;

   // sharedStateからユーザIDおよびパスワードの値を取り出すときの名称を定義します。
   // “simple.login.username”， "simple.login.password";は，統合ユーザ管理のコンフィグレーションファイルで
   // 指定できます。
   private static final String USERNAME = "simple.login.username";
   private static final String PASSWORD = "simple.login.password";

   // 認証の判定をするユーザIDを格納します。この値は，login()で設定され，commit()で参照されます。
   private String username;

   // login()の正否を格納します。trueなら，login()が成功しており，falseならlogin()が失敗しています。
   // この値は，login()で設定されcommit()で参照されます。

private boolean succeeded;

   // commit()の正否を格納します。trueなら，commit()が成功しており，falseならcommit()が失敗しています。
   // この値は，commit ()で設定されabort ()で参照されます。

private boolean commitSucceeded;

   /**
   * initialize()メソッドでは，引数に渡ってきたパラメタをメンバ変数に覚えます。
   * また，これ以外に初期化が必要な処理があればそれを行います。
   * (本クラスインスタンス時に1回だけ呼ばれる)
   *
   */
   public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)
   {
       this.subject = subject;
       this.callbackHandler = callbackHandler;
       this.sharedState = sharedState;
       this.options = options;
   }

   /**
   * login ()メソッドでは，認証に必要なユーザIDの取得と認証処理を行います。
   * 本例では，認証に成功した場合succeededにtrueを設定します。また，usernameに認証したユーザID
   * を格納します。
   *
   */
   public boolean login()
       throws LoginException
   {
       // SSOに対応するには，最初にsharedState内にユーザID･パスワードを取り出します。
       this.username = (String)this.sharedState.get(USERNAME);
       String password = (String)this.sharedState.get(PASSWORD);

       // sharedState内にユーザIDがない場合，CallbackHandlerを使ってユーザID/パスワードの
       // 取り出しを行います。(この例では，WebPasswordCallbackに値を設定してくれる，WebPasswordHandlerが
       // が前提になります)
       if (this.username == null || this.username.length() == 0) {
           WebPasswordCallback webpc = new WebPasswordCallback();
           webpc.setOption(WebPasswordCallback.GETPW);
           Callback callbacks[] = new Callback[] { webpc };
           try {
               this.callbackHandler.handle(callbacks);
           }
           catch (Exception ex) {
               // 例外処理を行います。
           }
           // CallbackからユーザIDとパスワードを取り出します。
           this.username = webpc.getName();
           password = webpc.getPassword();
       }

       // 認証で使用するユーザIDの有無を調べます。もし，ユーザIDがない場合は，例外を上げます。
       if (this.username == null || this.username.length() == 0) {
           throw new FailedLoginException();
       }

       // 各アプリケーションの認証処理を行います。
       // 認証した結果，問題がなければsucceededにtrueを設定します。

       /* ここに認証処理を入れる。 */

       if (!succeeded) {
           throw new FailedLoginException();
       }
       return succeeded;
   }

   /**
   * commit ()メソッドでは，認証したことを示すために，PrincipalオブジェクトをSubjectに関連づけます。
   * (SimplePrincipalは，PrincipalとSerializableのインタフェースを継承して作成されたクラスです。
   *
   */
   public boolean commit()
       throws LoginException
   {
       // PrincipalオブジェクトをSubjectに関連づけます。これにより，統合ユーザ管理で管理している
       // ログインセッション管理に参加したり，SSOの機能に対応することができます。
       this.subject.getPrincipals().add( new SimplePrincipal(this.username) );

       /* ユーザ属性があるなら，それもSubjectに関連づける処理を入れる。 */

       return this.commitSucceeded = true;
   }

   /**
   * abort ()メソッドでは，login()メソッドcommit()メソッドで障害があった場合にリカバリするために
   * 呼び出されます。
   *
   */
   public boolean abort()
       throws LoginException
   {
       if (this.commitSucceeded) {
           // Subjectに関連づけているPrincipalやユーザ属性を解放します。
           // この例ではlogout()メソッドを呼び出して解放します。
           logout();
       }
       return true;
   }

   /**
   * logout ()メソッドでは，ログアウトする場合に呼び出されます。
   * このメソッドでは，Subjectに関連づけられているPrincipalやユーザ属性を解放するために使用されます。
   *
   *
   */
   public boolean logout()
       throws LoginException
   {
// SubjectからPrincipalやユーザ属性を削除する処理を入れます。

       return true;
   }
}

(2)　セッションフェイルオーバ機能を使用する場合の実装例

loginメソッドとcommitメソッドについては，セッションフェイルオーバ機能を使用しない場合と同じです。ここでは，違いのあるlogoutメソッドの実装方法を示します。

/**
* LoginModuleの実装クラスは，LoginModuleインタフェースを継承して作成します。
*/
public class ExampleLoginModule implements LoginModule
{
  ：
 /**
  * logout ()メソッドでは，ログアウトする場合に呼び出されます。
  * このメソッドでは，ログイン時に取得したリソースを解放するために使用されます。
  */
 public boolean logout() throws LoginException
 {
   if (callbackHandler != null) {
       WebLogoutCallback callback = new WebLogoutCallback();
       try {
           callbackHandler.handle(new Callback[]{callback});
       } catch (Exception e) { ... }
       String uid = callback.getUserID();
       HttpSession session = callback.getSession();
       //リソースを解放する処理を入れます。
       //例えば，グローバルセッションに登録した情報を削除するなど。
   }
   return true;
 }
}

logoutメソッドでは，ログイン時に取得したリソースを解放します。セッションフェイルオーバ機能を使用する場合，SubjectやPrincipalはフェイルオーバされないことに注意してください。

(3)　Principalオブジェクトの実装例

Principalオブジェクトは，java.security.Principalとjava.io.Serializableのインタフェースを継承して作成してください。Principalオブジェクトの実装例を示します。

import java.security.Principal;
import java.io.Serializable;

/**
* Principalの実装クラスは，PrincipalとSerializableインタフェースを継承して作成します。
*
*/
public class SimplePrincipal implements Principal, Serializable
{
 private String name;

 public SimplePrincipal(String name) {
   if (name == null) throw new NullPointerException();
   this.name = name;
 }
 public String getName() { return name; }
 public String toString() { return getName(); }
 public boolean equals(Object o) {
   if (o == null) return false;
   if (this == o) return true;
   if (!(o instanceof SimplePrincipal)) return false;
   SimplePrincipal rhs = (SimplePrincipal)o;
   if (getName().equals(rhs.getName())) return true;
   return false;
 }
 public int hashCode() { return getName().hashCode(); }
}

13.12　統合ユーザ管理の運用

この節では，統合ユーザ管理の運用方法について説明します。

＜この節の構成＞

13.12.1　リポジトリ管理

13.12.2　リポジトリ（LDAPディレクトリサーバ）の接続フェイルオーバ

13.12.1　リポジトリ管理

統合ユーザ管理では，ユーザ情報を管理するリポジトリとして，LDAPディレクトリサーバまたはデータベースを使用できます。

LDAPディレクトリサーバを使用する場合，ユーザ情報は次に示す方法で登録できます。

LDAPディレクトリサーバが提供するコマンドによって登録する
ご使用のLDAPディレクトリサーバで提供されているコマンドを使用してください。コマンドによって，ldifファイルで定義した内容に基づいた一括登録などができます。

統合ユーザ管理APIを使用して開発したアプリケーションから登録する
ユーザ認証ライブラリおよびシングルサインオンライブラリを使用してユーザ認証を実行するアプリケーションを開発してください。統合ユーザ管理フレームワークを使用したユーザ認証の実装については，「13.7　統合ユーザ管理フレームワークによるユーザ認証の実装の概要」を参照してください。

13.12.2　リポジトリ（LDAPディレクトリサーバ）の接続フェイルオーバ

LDAPディレクトリサーバをレプリケーションによって多重化することで，一つのLDAPディレクトリサーバへのアクセスに失敗した場合，統合ユーザ管理が提供する標準ログインモジュールはあらかじめ設定した別のLDAPディレクトリサーバにユーザ情報，シングルサインオン情報の参照先の切り替えを自動的にできます。

例えば，次の図に示す構成では，J2EEサーバ1が使用しているLDAPディレクトリサーバslave1がダウンした場合，使用するLDAPディレクトリサーバを自動的にslave2に切り替えて認証処理ができます（slave2もダウンしている場合はslave3へ切り替えます）。

図13-22　LDAPディレクトリサーバの多重化の構成例

設定されているLDAPディレクトリサーバに順番にアクセスし，すべてのサーバでアクセスが失敗した場合，認証が失敗します。

LDAPディレクトリサーバがダウンしているかどうかの判断方法を次に示します。

javax.naming.CommunicationException例外が発生します。
この例外の原因としては，接続先ホストから接続を拒否された場合などが考えられます。詳細については，JDKのドキュメントを参照してください。

リトライを実行します。
リトライは，あらかじめ設定した回数分実行されます。

リトライしてもLDAPディレクトリサーバにアクセスできない場合，ダウンしていると見なされます。

設定されているすべてのLDAPディレクトリサーバがダウンしている場合，認証は失敗し，LoginContextクラスのloginメソッドの呼び出し元にLoginException例外が発生します。

各LDAPディレクトリサーバへの接続情報は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定して，JAASアプリケーションごとにjaas.conf（JAASのコンフィグレーションファイル）で使用するLDAPの設定を一つ以上指定します。ua.confおよびコンフィグレーションファイルの内容の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

また，PasswordUtilクラスによるパスワードの変更も接続フェイルオーバに対応しています。マスタサーバに対してパスワードの変更をします。次の図に示すようなマルチマスタ構成の場合に使用できます。

図13-23　LDAPディレクトリサーバの多重化の構成例（マルチマスタ構成）

なお，接続フェイルオーバをする場合，LDAPディレクトリサーバのエントリのツリー構造およびエントリの内容を同一にしてください。

14.　バッチサーバ

この章では，バッチアプリケーション実行環境の概要と，バッチサーバで提供している機能について説明します。

＜この章の構成＞

14.1　バッチアプリケーション実行環境の概要

14.2　バッチアプリケーション実行機能

14.3　EJBアクセスで使用できる機能

14.4　ネーミング管理が提供する機能

14.5　リソース接続とトランザクション管理が提供する機能

14.6　ガーベージコレクション制御機能

14.7　コンテナ拡張ライブラリ

14.1　バッチアプリケーション実行環境の概要

バッチサーバとは，バッチアプリケーションを実行するためのサーバです。バッチ実行コマンドを使用して，バッチサーバ上のバッチアプリケーションを実行します。

バッチアプリケーションの実行環境は，JP1/AJS2と連携できます。バッチ実行コマンドをあらかじめJP1/AJS2のジョブとして定義しておくことで，JP1/AJS2からバッチアプリケーションを実行できます。また，実行中のバッチアプリケーションを強制停止することもできます。バッチアプリケーションの強制停止には，バッチ強制停止コマンドを使用します。バッチ強制停止コマンドも，JP1/AJS2のジョブとして定義できます。

バッチアプリケーション実行の流れを次の図に示します。

図14-1　バッチアプリケーション実行の流れ

ここでは，バッチアプリケーション実行の流れ，およびシステムの構築・運用の概要を説明します。

＜この節の構成＞

14.1.1　バッチアプリケーションを実行するシステム

14.1.2　バッチサーバで提供する機能

14.1.3　バッチアプリケーションの実行環境の構築

14.1.4　バッチアプリケーションの実行環境の運用

14.1.5　マルチバイト文字の使用について

14.1.1　バッチアプリケーションを実行するシステム

バッチアプリケーションを実行するシステムは，JP1/AJS2と連携して運用します。また，JP1/AJS2に加えて，BJEXを使用して運用することもできます。JP1/AJS2やBJEXを使用すると，バッチサーバの起動・停止や，バッチアプリケーションの開始をジョブとして定義できるので，バッチアプリケーションを自動実行できます。また，BJEXを使用すると，バッチアプリケーションの実行コマンドの戻り値を使用したジョブステップの条件付き実行機能を使用できます。ただし，BJEXとの連携はAIXの場合だけできます。

ここでは，JP1/AJS2と連携するシステムと，JP1/AJS2およびBJEXと連携するシステムに分けて説明します。

なお，システム構成については，「21.4.2　ジョブによるシステムの自動運転に必要なプログラム」を参照してください。

＜この項の構成＞

(1)　JP1/AJS2と連携するシステム

(2)　JP1/AJS2およびBJEXと連携するシステム

(1)　JP1/AJS2と連携するシステム

バッチサーバを起動したり，バッチアプリケーションを実行したりする場合は，JP1/AJS2から操作します。JP1/AJS2では，あらかじめバッチサーバやバッチアプリケーションの操作をジョブとして定義します。バッチサーバおよびバッチアプリケーション操作の流れを次の図に示します。

図14-2　バッチサーバおよびバッチアプリケーション操作の流れ（JP1/AJS2連携）

バッチサーバは，JP1/AJS2からアプリケーションサーバのManagement Serverを経由して起動します。一方，バッチアプリケーションの実行や強制停止は，JP1/AJS2から直接バッチアプリケーションに対して実行します。JP1/AJS2ではこれらの操作をUNIXジョブまたはPCジョブとしてあらかじめ定義しておきます。

JP1/AJS2でのジョブ定義については，「15.1　バッチアプリケーションの実行方法」を参照してください。

参考

Management Serverを配置しない構成もできます。ただし，バッチアプリケーションの強制停止に失敗したときには，バッチサーバの再起動が必要になります。Management Serverを使用してバッチサーバを監視すると，トラブル発生時にバッチサーバを自動再起動できるため，Management Serverを使用する運用をお勧めします。

(2)　JP1/AJS2およびBJEXと連携するシステム

サーバを起動したり，バッチアプリケーションを実行したりするには，JP1/AJS2やBJEXから操作します。JP1/AJS2およびBJEXでは，あらかじめバッチサーバやバッチアプリケーションの操作をジョブとして定義します。バッチサーバおよびバッチアプリケーション操作の流れを次の図に示します。

図14-3　バッチサーバおよびバッチアプリケーション操作の流れ（JP1/AJS2およびBJEX連携）

バッチサーバは，JP1/AJS2からアプリケーションサーバのManagement Serverを経由して起動します。バッチアプリケーションの実行は，JP1/AJS2からBJEXを経由してバッチアプリケーションに対して実行します。また，バッチアプリケーションの強制停止はJP1/AJS2から直接バッチアプリケーションに対して実行します。このため，JP1/AJS2およびBJEXで，次に示す操作をあらかじめジョブに定義します。

バッチサーバの起動
JP1/AJS2のUNIXジョブまたはPCジョブとして定義します。

バッチアプリケーションの実行
JP1/AJS2のUNIXジョブまたはPCジョブとしてBJEXのジョブステップを定義し，BJEXのジョブステップにバッチアプリケーションの実行を定義します。

バッチアプリケーションの強制停止
JP1/AJS2のリカバリージョブとして定義します。

JP1/AJS2やBJEXでのジョブ定義については，「15.1　バッチアプリケーションの実行方法」を参照してください。

参考

Management Serverを配置しない構成もできます。ただし，バッチアプリケーションの強制停止に失敗したときには，バッチサーバの再起動が必要になります。Management Serverを使用してバッチサーバを監視すると，トラブル発生時にバッチサーバを自動再起動できるため，Management Serverを使用する運用をお勧めします。

バッチサーバではBJEXのジョブログ出力機能を使用できます。ただし，ジョブログ出力機能で出力されるログには，cjexecjobコマンドのCPU使用時間およびメモリ使用量が出力されます。BJEXのジョブステップのCPU使用時間およびメモリ使用量は出力できません。

14.1.2　バッチサーバで提供する機能

バッチサーバではバッチアプリケーションを実行する機能として，バッチサービスを提供しています。cjexecjobコマンドを実行すると，バッチサービスはバッチアプリケーションの情報を基に，バッチアプリケーションの実行を開始します。また，バッチアプリケーションを強制停止するcjkilljobコマンドを実行すると，実行中のバッチアプリケーションに対して強制停止を実行します。バッチサービスには，次に示す機能があります。

バッチアプリケーション実行機能

EJBアクセス機能

ネーミング管理が提供する機能

リソース接続とトランザクション管理が提供する機能

ガーベージコレクション制御機能

コンテナ拡張ライブラリの機能

それぞれの機能については，14.2以降を参照してください。

14.1.3　バッチアプリケーションの実行環境の構築

バッチアプリケーションの実行環境は，Cosminexusで提供するSmart Composer機能，サーバ管理コマンド，およびServer Plug-inを使用して構築します。バッチアプリケーションの実行環境の構築手順を次に示します。

Smart Composer機能を使用してシステムを構築します。
簡易構築定義ファイルでシステム構成を定義し，Smart Composer機能で提供するコマンドを使用して，システムを一括構築します。

サーバ管理コマンドまたはServer Plug-inを使用して，リソースアダプタを設定します。
バッチアプリケーションからデータベースに接続する場合だけ実施します。

Smart Composer機能，サーバ管理コマンド，およびServer Plug-inについては，「16.　システムの構築」を参照してください。また，Smart Composer機能を使用したシステム構築については，マニュアル「Cosminexus　簡易構築・運用ガイド」のバッチアプリケーションを実行するシステムの構築に関する説明を参照してください。

注意

バッチサーバを複数構築する場合，サーバで使用するTCP/IPのポート番号を重複しないよう変更する必要があります。また，バッチサーバはJ2EEサーバで使用しているTCP/IPのポート番号を使用します。複数のバッチサーバを同時に起動する場合，およびバッチサーバとJ2EEサーバを同時に起動する場合は，使用するポート番号が重複しないように設定してください。ポート番号については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

参考

バッチアプリケーションの実行環境は運用管理ポータルを使用して構築することもできます。運用管理ポータルを使用したバッチアプリケーションの実行環境の構築については，マニュアル「Cosminexus　運用管理操作ガイド」のバッチアプリケーションを実行するシステムの構築と削除に関する説明を参照してください。

14.1.4　バッチアプリケーションの実行環境の運用

バッチアプリケーションの実行環境は次の順序で運用します。

システムの起動
Smart Composer機能で提供するコマンドを使用して，バッチサーバを含むシステム全体を起動します。バッチアプリケーションからリソースに接続する場合は，DB Connectorも開始します。

バッチアプリケーションの実行
cjexecjobコマンドを使用してバッチアプリケーションを開始します。

バッチサーバの停止
Smart Composer機能で提供するコマンドを使用して，バッチサーバを含むシステム全体を停止します。

JP1/AJS2と連携する場合は，JP1/AJS2からバッチサーバおよびバッチアプリケーションを開始できます。また，JP1/AJS2およびBJEXと連携する場合はJP1/AJS2からバッチサーバを，BJEXからバッチアプリケーションを開始できます。

システムの起動および停止の詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」のシステムの開始に関する説明を参照してください。バッチアプリケーションの開始方法については，「15.1　バッチアプリケーションの実行方法」を参照してください。

また，バッチアプリケーションを実行するシステムでは次の運用機能を使用できます。

システムの日常運用を支援する機能
バッチサーバの稼働状況や，バッチサーバのリソースの使用状況を監視できます。システムの日常運用を支援する機能については，「17.　システムの日常運用」を参照してください。

システムの保守を支援する機能
バッチサーバの障害を検知したときに，トラブルシューティングの資料を取得できます。システムの保守を支援する機能については，「18.　システムの保守」を参照してください。

システムの監査を支援する機能
システムの構築者や運用者がCosminexusのプログラムに対して実行した操作や履歴を出力できます。また，バッチアプリケーションがデータベースにアクセスした際に使用したアカウントを記録できます。システムの監査を支援する機能については，「20.　システムの監査」を参照してください。

14.1.5　マルチバイト文字の使用について

次に示す個所でマルチバイト文字を使用する場合は，これらの個所すべてでマルチバイト文字のエンコードを同じにしてください。

バッチアプリケーション用オプション定義ファイル（usrconf.cfg）内にマルチバイト文字を使用する場合

バッチサーバ用オプション定義ファイル（usrconf.cfg）内にマルチバイト文字を使用する場合

cjexecjobコマンドの引数にマルチバイト文字を指定する場合

バッチアプリケーションのソースコードで，java.lang.System.outまたはjava.lang.System.errにマルチバイト文字を出力する場合

また，バッチサーバとcjexecjobコマンドを実行するコンソールの環境変数LANGには，対応する文字エンコードを表示できるようにしてください。

14.2　バッチアプリケーション実行機能

バッチアプリケーション実行機能は，バッチサーバで提供する機能の一つです。バッチアプリケーション実行機能は，バッチアプリケーションを実行したり，バッチアプリケーションが出力したデータをログ出力機能に出力したりします。

ここでは，バッチアプリケーション実行機能について説明します。

＜この節の構成＞

14.2.1　バッチアプリケーション実行機能の概要

14.2.2　バッチアプリケーションの実行

14.2.3　バッチアプリケーションの強制停止

14.2.4　バッチアプリケーションのログ出力

14.2.1　バッチアプリケーション実行機能の概要

バッチアプリケーション実行機能とは，バッチアプリケーションを実行するための機能です。バッチアプリケーションは，バッチアプリケーション実行機能で提供されているバッチクラスローダ上で実行されます。また，実行中のバッチアプリケーションが出力した内容は，ログ出力機能に出力されます。

バッチアプリケーション実行機能について次の図に示します。

図14-4　バッチアプリケーション実行機能の概要

また，バッチアプリケーション実行機能は，EJBアクセス機能やリソース接続機能と連携できます。

EJBアクセス機能と連携すると，バッチアプリケーションからほかのJ2EEサーバのEJBにアクセスできます。

リソース接続機能と連携すると，バッチアプリケーションからデータベースに接続できます。

EJBアクセス機能については「14.3　EJBアクセスで使用できる機能」を，リソース接続機能については「14.5　リソース接続とトランザクション管理が提供する機能」を参照してください。

次に，バッチアプリケーションのライフサイクルとバッチアプリケーションを実行するクラスローダについて説明します。

＜この項の構成＞

(1)　バッチアプリケーションのライフサイクル

(2)　バッチアプリケーションを実行するクラスローダ

(1)　バッチアプリケーションのライフサイクル

バッチアプリケーションは，cjexecjobコマンドを使用して開始します。次の図を使用して，バッチアプリケーションのライフサイクルについて説明します。

図14-5　バッチアプリケーションのライフサイクル

cjexecjobコマンドを実行すると，バッチアプリケーションはバッチクラスローダによってロードされます。

バッチアプリケーションがバッチサーバ上で実行されます。

バッチアプリケーションの処理が終了します。
バッチアプリケーションの処理終了後に，バッチアプリケーションをロードしたバッチクラスローダがガーベージコレクションされます。

バッチアプリケーションのクラスがアンロードされます。

(2)　バッチアプリケーションを実行するクラスローダ

バッチアプリケーション実行時には，バッチサーバ上でバッチアプリケーション用のクラスローダが生成されます。バッチアプリケーションはクラスローダ上で実行されます。バッチアプリケーション用のクラスローダの構成を次の図に示します。

図14-6　バッチアプリケーションを実行するクラスローダの構成

図のそれぞれのクラスローダについて説明します。

システムクラスローダ
Cosminexusの構成ソフトウェアが提供するクラスをロードします。

コネクタクラスローダ
リソースアダプタに含まれるクラスをロードします。バッチサーバ内に一つだけ存在します。

バッチクラスローダ
バッチアプリケーションに含まれるクラスをロードします。cjexecjobコマンド実行ごとに作成され，バッチアプリケーション終了時に破棄されます。バッチアプリケーションを実行するスレッドのコンテキストクラスローダは，バッチクラスローダです。

なお，バッチクラスローダ生成時には，バッチクラスローダが生成されたことを示すメッセージが出力されます（メッセージKDJE55013-I）。また，バッチクラスローダがガーベージコレクションされたことを示すメッセージも出力されます（メッセージKDJE55014-I）。

14.2.2　バッチアプリケーションの実行

バッチアプリケーションは，cjexecjobコマンドで開始します。バッチアプリケーションのmainメソッドの実行が終わると，バッチサーバはフルガーベージコレクションを実行します。ここでは，バッチアプリケーションの開始と終了について説明します。

＜この項の構成＞

(1)　バッチアプリケーションの開始

(2)　バッチアプリケーションの終了

(1)　バッチアプリケーションの開始

cjexecjobコマンドにバッチアプリケーションのクラス名とクラスパスを指定すると，cjexecjobコマンドに指定したバッチアプリケーションが開始します。バッチアプリケーション開始時の処理を次に示します。

バッチアプリケーションの開始処理を開始することを示すメッセージ（KDJE55000-I）を出力します。

バッチアプリケーションのmainメソッドを開始することを示すメッセージ（KDJE55001-I）を出力します。

public static void main(String[])メソッドまたはpublic static int main(String[])メソッドを実行します。

バッチアプリケーションの開始時には，cjexecjobコマンドに指定した実行クラスのpublic static void main(String[])メソッドまたはpublic static int main(String[])メソッドが呼び出されます。メソッドの引数には，cjexecjobコマンドのクラス名のあとに指定した引数を設定します。

バッチアプリケーションの開始に失敗する場合

バッチアプリケーションにmainメソッドが定義されていない場合などには，バッチアプリケーションの開始は失敗します。なお，バッチアプリケーションの開始に失敗すると，バッチサーバとcjexecjobコマンドは次のように動作します。

バッチサーバの動作
メッセージを出力し，バッチアプリケーション開始に失敗した情報とメッセージ文字列をcjexecjobコマンドに返します。

cjexecjobコマンドの動作
バッチサーバから受け取ったメッセージ文字列を出力し，異常終了します。なお，コマンドの戻り値は1です。

次の表に，バッチアプリケーションの開始に失敗する条件，およびバッチサーバが出力するメッセージを示します。

表14-1　バッチアプリケーションの開始に失敗する条件

バッチアプリケーションの開始に失敗する条件 | バッチサーバが出力するメッセージ
usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）の読み込みに失敗した。 | KDJE55035-E
cjexecjobコマンドに指定したクラスが存在しない。 | KDJE55006-E
public static void main(String[])メソッドまたはpublic static int main(String[])メソッドが定義されていない。
public static void main(String[])メソッドまたはpublic static int main(String[])メソッドのどちらともシグニチャが異なる。
cjexecjobコマンドに指定したクラスのロード時に，java.lang.NoClassDefFoundErrorが発生した。 | KDJE55007-E
public static void main(String[])メソッドまたはpublic static int main(String[])メソッド呼び出し時に必要なクラスが見つからない。
static{}ブロック内でエラーが発生した。
上記以外の問題でmainメソッドが実行できない。 | KDJE55008-E

なお，バッチアプリケーションの作成については，「15.2　バッチアプリケーションの作成」を参照してください。

バッチアプリケーション実行時の注意

バッチアプリケーションの開始時には，使用するEJBおよびDB Connectorが存在するかどうかの確認は実施しません。バッチアプリケーションから参照しているEJBまたはDB Connectorがない場合は，バッチアプリケーション実行中に実行時エラーになります。バッチアプリケーションを開始する前に，参照先のEJBがあるかどうかを確認してください。また，DB Connectorを使用してバッチアプリケーションからデータベースに接続する場合は，バッチサーバでDB Connectorを開始しておいてください。

(2)　バッチアプリケーションの終了

バッチアプリケーションのmainメソッドの実行が終わると処理が終了します。バッチアプリケーション終了時の処理を次に示します。

バッチアプリケーション終了処理を開始することを示すメッセージ（KDJE55002-I）を出力します。

バッチアプリケーションの終了処理が完了したことを示すメッセージ（KDJE55003-I）を出力します。

フルガーベージコレクションを実行します。

cjexecjobコマンドにバッチアプリケーションの終了コードを送信します。

なお，バッチアプリケーション実行中に［Ctrl］＋［C］やシグナルなどによってcjexecjobコマンドを終了しても，バッチアプリケーションの実行は終了しません。バッチアプリケーションの実行を強制停止したい場合，cjkilljobコマンドを実行してください。ただし，cjkilljobコマンドで強制終了した場合，cjexecjobコマンドの終了コードは不定となります。

バッチ強制停止コマンドについては，「14.2.3　バッチアプリケーションの強制停止」を参照してください。

バッチアプリケーションの終了条件

次の表に，バッチアプリケーションの終了条件と，そのときのバッチサーバやcjexecjobコマンドの動作を示します。

表14-2　バッチアプリケーションの終了条件

バッチアプリケーションの終了条件
バッチサーバの動作
cjexecjobコマンドの動作

mainメソッドを最後まで実行した。
KDJE55002-I出力して，バッチアプリケーションの実行を終了する。終了後にKDJE55003-Iを出力する。
正常終了する。
戻り値：0

public static void main(String[])メソッドでreturn文を実行した。

public static int main(String[])メソッドでreturn <終了コード>を実行した。
正常終了する。
戻り値：returnに指定した終了コード

mainメソッドの外に，java.lang.Throwableまたはjava.lang.Throwableを継承したクラスがスローされた。
KDJE55009-Eを出力する。例外のスタックトレースを例外ログに出力する。バッチアプリケーションの実行を終了する。
例外のスタックトレースを標準エラー出力に出力する。バッチアプリケーションの実行を異常終了する。
戻り値：1

バッチサーバが終了した（バッチサーバの強制終了または予期しないJavaVMのダウン）。
なし。
KDJE55021-Eを出力して，バッチアプリケーションの実行を異常終了する。
戻り値：1

14.2.3　バッチアプリケーションの強制停止

実行中のバッチアプリケーションを必要に応じて停止させることができます。これを，バッチアプリケーションの強制停止といいます。ここでは，バッチアプリケーションの強制停止について説明します。

＜この項の構成＞

(1)　強制停止で実行される処理

(2)　バッチアプリケーションの強制停止に失敗した場合に備えて

(1)　強制停止で実行される処理

実行中のバッチアプリケーションを強制停止するには，cjkilljobコマンドを使用します。cjkilljobコマンドを使用すると，バッチアプリケーションを実行しているスレッドに対してメソッドキャンセルを実行してバッチアプリケーションを強制停止します。

メソッドキャンセルとは，実行中のメソッドをキャンセルする機能です。ただし，メソッドを実行している領域によって，キャンセルできるメソッドとできないメソッドがあります。メソッドをキャンセルできる領域のことを非保護区，メソッドをキャンセルできない領域を保護区といいます。実行中のメソッドが非保護区の場合に，メソッドキャンセルが実行されます。バッチアプリケーションの強制停止で実行されるメソッドキャンセルは，J2EEアプリケーション実行時間の監視機能で実行されるメソッドキャンセルと同じです。メソッドキャンセルの処理については，「19.3.3　メソッドキャンセルとは」を参照してください。

バッチアプリケーション強制停止時の処理を次に示します。

バッチアプリケーションの強制停止処理を開始することを示すメッセージ（KDJE55004-I）を出力します。

public static void main(String[])メソッドまたはpublic static int main(String[])メソッドのメソッドキャンセルを実行します。
なお，メソッドキャンセルに失敗した場合，KDJE55017-Eを出力して強制停止に失敗し，バッチサーバが強制停止します。強制停止に失敗した場合は，バッチサーバを再起動してください。

バッチアプリケーションの強制停止処理が完了したことを示すメッセージ（KDJE55005-I）を出力します。

フルガーベージコレクションを実行します。

cjexecjobコマンドにバッチアプリケーションの終了コードを送信します。

次の表に，バッチアプリケーションの強制停止条件を示します。

表14-3　バッチアプリケーションの強制停止の条件

バッチアプリケーションの強制停止の条件
バッチサーバの動作
cjexecjobコマンドの動作

バッチアプリケーション実行中にバッチ強制停止コマンドを実行した。
KDJE55004-I出力して，バッチアプリケーションの実行を強制停止を開始する。強制停止の完了時にはKDJE55005-Iを出力する。強制停止に失敗したときはKDJE55017-Eを出力する。
バッチ強制終了時の正常パス
戻り値：1

(2)　バッチアプリケーションの強制停止に失敗した場合に備えて

バッチアプリケーションの強制停止に失敗すると，バッチサーバが強制停止されます。複数のバッチアプリケーションを連続して実行する場合，バッチサーバの強制停止後に実行するバッチアプリケーションを開始する前に，バッチサーバを再起動する必要があります。このため，Management Serverを利用して，バッチサーバが自動的に再起動するように設定してください。

14.2.4　バッチアプリケーションのログ出力

バッチサーバでは，バッチアプリケーションの実行ログを出力します。実行ログには，実行中のバッチアプリケーションが標準出力や標準エラー出力に出力する内容を，バッチ実行コマンド単位で出力します。これらの情報は障害発生時の調査情報として利用できます。

バッチアプリケーションがjava.lang.System.outおよびjava.lang.System.errに書き出したデータは，バッチサーバによってそれぞれ次の場所に出力されます。

バッチアプリケーションがjava.lang.System.outに書き出したデータ
バッチサーバの標準出力転送機能で，次の場所に出力されます。

バッチサーバのユーザ出力ログ

バッチサーバの標準出力

cjexecjobコマンドの標準出力

バッチアプリケーションがjava.lang.System.errに書き出したデータ
バッチサーバの標準エラー出力転送機能で，次の場所に出力されます。

バッチサーバのユーザエラーログ

バッチサーバの標準エラー出力

cjexecjobコマンドの標準エラー出力

また，cjexecjobコマンド，およびcjkilljobコマンドで出力するメッセージは，メッセージのレベルによってそれぞれ次の場所に出力されます。

I（Information）

標準出力に出力します。ただし，コマンドの使用方法を示すメッセージ（KDJE55029-I，KDJE55030-I）の出力先は標準エラー出力になります。

E（Error）およびW（Warning）

標準エラー出力に出力されます。

バッチアプリケーションを実行するためのコマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」のバッチアプリケーションで使用するコマンドに関する説明を参照してください。また，メッセージのレベルについては，マニュアル「Cosminexus　メッセージ1　KAWS／KDAL／KDJE編」のメッセージの記述形式に関する説明を参照してください。

14.3　EJBアクセスで使用できる機能

バッチアプリケーションからほかのJ2EEアプリケーションにあるEJBにアクセスできます。バッチアプリケーションからのEJBアクセスで使用できる機能について，次の表に示します。なお，それぞれの機能の詳細については，参照先の説明を参照してください。

表14-4　EJBアクセスで使用できる機能

分類
機能概要
機能についての参照先

JNDI
基本機能
EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスの検索，取得ができます。
6.3※，8.2

拡張機能
複数のネーミングサービスとJ2EEサーバで構成されるシステムに対して，バッチアプリケーションからのルックアップをラウンドロビンで実行できます。これによって，負荷分散を実現できます。
8.4

ネーミングサービスからルックアップしたオブジェクトをメモリ上に保持（キャッシュ）できます。キャッシュの利用によって，ネーミングサービスへのアクセスの性能上のコストを削減できます。
8.5

EJB
EJBコンテナで実行されているEnterprise Beanをバッチアプリケーションから呼び出せます。ただし，呼び出し方法はリモート呼び出しだけ使用できます。ローカル呼び出しはできません。
5.2，6.2※，6.6※

バッチアプリケーションからのEJB呼び出し実行時に通信障害が発生した場合に，送信動作を選択できます。
5.11.3

トランザクション
バッチアプリケーションでトランザクションを開始・決着できます。ただし，バッチアプリケーションの場合，グローバルトランザクションは使用できません。
9.3

バッチアプリケーションでUserTransactionを取得し,トランザクションを開始・決着できます。UserTransactionの取得方法には次の2種類の方法があります。

UserTransactionFactoryクラスを使用する方法

ルックアップを使用する方法

6.4

そのほか
バッチサーバとネーミングサービス間，およびバッチサーバとJ2EEサーバ間の通信で，通信タイムアウトを設定できます。
5.9.4

バッチアプリケーションの性能解析トレースを出力できます。
17.10

バッチアプリケーションのログを出力できます。
マニュアル「Cosminexus　システム運用ガイド」

注※　アプリケーションの実装方法について説明しています。

14.4　ネーミング管理が提供する機能

ネーミング管理は，J2EEサービスで提供されている機能の一つです。J2EEサービスは，J2EEコンテナの部品機能として利用される機能です。ネーミング管理では，オブジェクト（Enterprise Beanに対応するEJBホームオブジェクト，ビジネスインタフェースのリファレンスおよびJ2EEリソース）の名前と格納場所を管理しています。ネーミング管理の機能を使用することで，バッチアプリケーションは，呼び出すEnterprise Beanまたはリソースの格納場所を知らなくても，名前から必要なオブジェクトを利用できるようになります。

Cosminexusで提供するネーミング管理の機能を次の表に示します。

表14-5　Cosminexusで提供するネーミング管理の機能

機能 | 参照先
JNDI名前空間へのオブジェクトのバインドとルックアップ※1 | 8.2
J2EEリソースへの別名付与（ユーザ指定名前空間機能） | 8.3※2
ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | 8.4
ネーミング管理機能でのキャッシング | 8.5
CORBAネーミングサービスの切り替え | 8.6

注※1　ルックアップには何種類かの方法があります。ルックアップ名称および方法については，「8.2.1　ルックアップで使用する名称の種類」を参照してください。ただし，バッチアプリケーションの場合，java:comp/envでのルックアップは使用できません。

注※2　参照先の記述のうち，J2EEリソースに関する説明を参照してください。バッチアプリケーションの場合，Enterprise Beanの説明は該当しません。

ネーミング管理機能のJNDIでは，CORBAオブジェクトリファレンス以外のオブジェクト（RMI-IIOPのリモートオブジェクトやJDBCデータソースなどのオブジェクト）を次のように扱います。

CORBAオブジェクトリファレンス以外の登録は，対象のオブジェクトをCORBAオブジェクトに変換し，CORBAオブジェクトリファレンスをCORBAネーミングサービスへ登録することで実現しています。

CORBAオブジェクト以外のオブジェクトの検索は，CORBAオブジェクトリファレンスを検索し，CORBAオブジェクトから逆変換して元のオブジェクトを取得することで実現しています。

なお，Cosminexusで提供するネーミング管理の機能には，J2EEで規定された機能にCosminexus独自の機能を拡張したものと，Cosminexus独自の機能として提供しているものがあります。Cosminexus独自の機能かどうかについては，「3.　アプリケーションサーバの機能（バッチアプリケーションを実行する場合）」を参照してください。

14.5　リソース接続とトランザクション管理が提供する機能

バッチアプリケーションからリソースに接続することもできます。ここでは，バッチアプリケーションからリソースに接続するための機能と，リソース接続でのトランザクション管理について説明します。

なお，リソースに接続するバッチアプリケーションの作成方法については，「15.3　リソースに接続するバッチアプリケーションの作成」を参照してください。

＜この節の構成＞

14.5.1　リソース接続とトランザクション管理の概要

14.5.2　リソース接続への接続方法

14.5.3　トランザクションの管理方法

14.5.1　リソース接続とトランザクション管理の概要

ここでは，Application Serverが接続できるリソースと，リソースをトランザクションで管理するための方法について，概要を紹介します。

バッチアプリケーションでは，処理の延長でデータベースに接続できます。バッチアプリケーションからデータベースに接続するには，接続するリソースに対応したリソースアダプタをデプロイして使用します。Cosminexusシステムでは，データベースに接続するためのリソースアダプタであるDB Connectorを提供しています。

また，Cosminexusでは，これらのリソースに効率的かつ信頼性の高い方法でアクセスするために，コネクションプーリングやトランザクション管理の機能を提供しています。コネクションプーリングを使用すると，リソースに対するコネクションをプーリングして，効率的にコネクションを使用できます。また，障害が発生したコネクションを適切にコネクションプールから取り除きます。また，トランザクション管理の機能を使用すると，トランザクションマネジャが，メソッドごとに指定するトランザクション属性やJTAインタフェース（UserTransaction）による指示に基づいて，リソースアクセスのトランザクションを適切に制御します。

なお，バッチアプリケーションではグローバルトランザクションは使用できません。

コネクションプーリング，およびトランザクション管理の機能を使用したリソースへの接続の例を次の図に示します。

図14-7　コネクションプーリングおよびトランザクション管理の機能を使用したリソースへの接続の例

14.5.2　リソース接続への接続方法

バッチアプリケーションではリソースとしてデータベースを使用できます。ここでは，バッチアプリケーションからのデータベースへの接続について説明します。

＜この項の構成＞

(1)　接続できるデータベース

(2)　リソースへの接続方法

(3)　DB Connector（RARファイル）の種類

(4)　リソースアダプタの使用方法

(5)　リソースアダプタの機能

(6)　リソースアダプタ以外の機能

(7)　リソースアダプタのオプショナル名についての注意事項

(1)　接続できるデータベース

バッチサーバからは次のデータベースに接続できます。

HiRDB

Oracle

SQL Server※

XDM/RD E2
注※　SQL Serverと接続できるのはWindowsの場合だけです。

ただし，バッチサーバではグローバルトランザクションは使用できません。

データベースとの接続については次の個所を参照してください。

DB Connectorを使用したデータベース接続の概要
「9.4.1　DB Connectorによる接続の概要」

データベースとJDBCドライバの対応や，DB ConnectorがサポートするJDBCの仕様
「9.4.3　接続できるデータベース」

データベースの前提条件と注意事項
接続するデータベースの種類に応じて，次の個所を参照してください。

HiRDBに接続する場合
「9.4.5　HiRDBと接続する場合の前提条件と注意事項」

Oracleに接続する場合
「9.4.6　Oracleと接続する場合の前提条件と注意事項」

SQL Serverに接続する場合
「9.4.7　SQL Serverと接続する場合の前提条件と注意事項」

XDM/RD E2に接続する場合
「9.4.8　XDM/RD E2と接続する場合の前提条件と注意事項」

(2)　リソースへの接続方法

バッチアプリケーションからデータベースに接続するには，JDBCドライバを直接使用するか，またはCosminexusで提供しているリソースアダプタを使用します。リソースアダプタを使用する場合は，DB Connectorを使用します。バッチアプリケーションからデータベースに接続するときに使用できる機能を，接続方法ごとに次の表に示します。なお，DB Connectorを使用すると次の表の機能に加えて，DB Connectorが提供している機能も使用できます。DB Connectorが提供している機能については，(5)を参照してください。

表14-6　データベースに接続するときに使用できる機能

使用できる機能 | 接続方法
DB Connector | JDBCドライバ
SQLの実行 | ○ | ○
トランザクションの利用 | Connection APIによるトランザクション | ○ | ○
JTA | ローカルトランザクション | ○ | ×
グローバルトランザクション | × | ×
ガーベージコレクション制御機能 | ○ | ×

（凡例）○：使用できる　×：使用できない

(3)　DB Connector（RARファイル）の種類

DB Connectorを使用してデータベースに接続する場合，使用するJDBCドライバに応じたRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

JDBCドライバの種類とバッチサーバの場合に使用できるRARファイルについて次の表に示します。

表14-7　JDBCドライバとRARファイルの対応

JDBCドライバ | RARファイル | 説明
HiRDB Type4 JDBC Driver | DBConnector_HiRDB_Type4_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
Cosminexus DABroker Library | DBConnector_DABJ_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
Oracle JDBC Thin Driver | DBConnector_Oracle_CP.rar | トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_CP_ClusterPool_Root.rar | コネクションプールのクラスタ化機能でルートリソースアダプタを使用する場合に使用します。
DBConnector_Oracle_CP_ClusterPool_Member.rar | コネクションプールのクラスタ化機能でメンバリソースアダプタを使用する場合に使用します。
SQL ServerのJDBCドライバ | DBConnector_SQLServer_CP.rar | SQL Server 2000への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。
DBConnector_SQLServer2005_CP.rar | SQL Server 2005への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

(4)　リソースアダプタの使用方法

リソースアダプタを使用してリソースと接続する場合，リソースアダプタをJ2EEリソースアダプタとしてデプロイしてください。J2EEリソースアダプタとは，J2EEサーバ上に配置されたリソースアダプタです。デプロイ方法については，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定に関する説明を参照してください。

(5)　リソースアダプタの機能

バッチサーバの場合にデータベース接続で使用できる機能を，リソースアダプタの種類ごとに次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表14-8　リソースアダプタの種類ごとの使用できる機能

機能 | リソースアダプタの種類 | 参照先
DB Connector | ルートリソースアダプタ | メンバリソースアダプタ
コネクションプーリング | ○ | × | ◎ | 9.10.1
コネクションプールのウォーミングアップ | ○ | × | ○
コネクションプール数調節機能 | ○ | × | ○
コネクションシェアリング・アソシエーション | ○ | × | ○ | 9.10.2
ステートメントプーリング | ○ | × | ○ | 9.10.3
DataSourceオブジェクトのキャッシング | ○ | ○ | × | 9.10.6
DB Connectorのコンテナ管理でのサインオンの最適化 | ○ | × | ○ | 9.10.7
コネクション障害検知 | ○ | × | ◎ | 9.11.1
コネクション枯渇時のコネクション取得待ち | ○ | × | ◎ | 9.11.2
コネクション取得リトライ | ○ | × | × | 9.11.3
コネクションプールの情報表示 | ○ | × | ○ | 9.11.4
コネクションプールのクリア | ○ | × | ○ | 9.11.5
ステートメントキャンセル | ○ | × | ○ | 9.11.8
障害調査用SQLの出力 | ◎ | × | ◎ | 9.11.10
オブジェクトの自動クローズ | ○ | × | ○ | 9.11.11
コネクションプールの一時停止 | × | × | ○ | 9.12
コネクションプールの再開 | × | × | ○
コネクションプールの状態表示 | ○ | × | ○
リソースへの接続テスト | ○ | ○ | ○ | 9.14
J2EEリソースへの別名付与※ | ○ | ○ | × | 8.3
コネクションIDのPRFトレース | ○ | ○ | ○ | 17.10
クライアントAPIで発生した例外の通知機能 | ○ | ○ | ○ | －

（凡例）　◎：必ず有効になる　○：使用できる　×：使用できない　－：該当しない

注※　バッチサーバの場合，リソースアダプタのオプショナル名機能は必ず使用します。

(6)　リソースアダプタ以外の機能

ここでは，リソースアダプタ以外で実現される機能について説明します。ここで説明する機能は，リソースアダプタの種類に関係なく使用できます。

リソースアダプタ以外で実現される機能を，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表14-9　リソースアダプタ以外の機能

機能 | 参照先
ライトトランザクション※ | 9.10.4
受信バッファのプーリング（Cosminexus DABroker Libraryを使用する場合） | 9.10.8
トランザクションタイムアウト | 9.11.8

注※　バッチサーバの場合，ライトトランザクション機能は必ず有効にします。

注意

トランザクション管理の機能では，トランザクションを自動決着する機能がありますが，バッチサーバの場合，トランザクションの自動決着機能は使用できません。

(7)　リソースアダプタのオプショナル名についての注意事項

同じオプショナル名で複数のリソースアダプタをデプロイしている場合，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。

14.5.3　トランザクションの管理方法

リソース接続時のトランザクションを管理する方法には，Application Serverで管理する方法と，Application Serverが管理しないでユーザが直接管理する方法があります。データベースへの接続では，Application Serverのトランザクションマネジャを使用してトランザクションを管理できます。トランザクション管理については，「9.3.1　リソース接続でのトランザクション管理の方法」を参照してください。

バッチサーバで使用できるトランザクションは，ローカルトランザクションです。グローバルトランザクションは使用できません。また，バッチサーバでは，必ずライトトランザクション機能を有効にしてください。ライトトランザクション機能とは，ローカルトランザクションに最適化された環境を提供する機能です。ローカルトランザクションおよびライトトランザクション機能については，「9.3.2　ローカルトランザクションとグローバルトランザクション」を参照してください。

また，EJB呼び出し時に，呼び出し先でシステム例外が発生したときの，呼び出し元，呼び出し先のトランザクションは，それぞれ次のように動作します。

呼び出し元のトランザクション

トランザクションはロールバックにマークされません。

呼び出し先のトランザクション

トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

14.6　ガーベージコレクション制御機能

バッチサーバでは，ガーベージコレクション制御機能を使用できます。ここではガーベージコレクション制御機能の概要と，ガーベージコレクション制御機能の処理の流れについて説明します。

ガーベージコレクション制御機能を使用するための設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

14.6.1　ガーベージコレクション制御機能とは

14.6.2　ガーベージコレクション制御の処理の流れ

14.6.1　ガーベージコレクション制御機能とは

ガーベージコレクションとは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。ガーベージコレクションはJavaVMが実行します。

ガーベージコレクションには処理時間が掛かります。また，ガーベージコレクション実行中は，JavaVM上のすべてのプログラム処理が中断するため，ガーベージコレクションを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

バッチサーバでは，バッチアプリケーションが長時間リソースを排他するのを回避するため，ガーベージコレクション制御機能を提供しています。ガーベージコレクション制御機能とは，リソースが排他されていないときに明示的にフルガーベージコレクションを実行するための機能です。ガーベージコレクション制御機能の利用によって，リソースの排他中にフルガーベージコレクションが発生するのを回避できます。

ガーベージコレクション制御機能について，例を使用して説明します。

ガーベージコレクション制御機能を使用していない場合，バッチ処理と並行してオンライン処理を実行する環境では，次の図に示す問題があります。

図14-8　ガーベージコレクション制御機能を使用していない場合

この図では，バッチアプリケーションでのリソース排他中に，フルガーベージコレクションが発生しています。これによって，バッチアプリケーションはリソースを排他したまま処理が中断します。また，この間にオンライン処理から排他中のレコードが参照されると，オンライン処理もバッチサーバのフルガーベージコレクションが終了するまで中断します。

ガーベージコレクション制御機能を使用すると次の図のようになります。

図14-9　ガーベージコレクション制御機能を使用している場合

図のように，フルガーベージコレクションの実行要求が出たときに，バッチアプリケーションでリソースを排他していると，フルガーベージコレクションの実行は待ち状態になります。

レコードの排他が解除されると，バッチサーバでフルガーベージコレクションが実行されます。また，オンライン処理もリソースへのアクセスができるようになります。これによって，バッチアプリケーションでの長時間のリソース排他を回避できます。

14.6.2　ガーベージコレクション制御の処理の流れ

ガーベージコレクション制御は次の流れで処理されます。

図14-10　ガーベージコレクション制御の処理の流れ

メモリ監視
監視タイマスレッドは，JavaVMのメモリを監視します。(1)に示す条件を満たすと，ガーベージコレクション制御機能にガーベージコレクション実行要求が出されます。

リソース排他のチェック
ガーベージコレクション実行要求が出されると，ガーベージコレクション制御機能はリソース排他中かどうかを調査します。

フルガーベージコレクションの実行待ち
リソース排他中の場合，フルガーベージコレクションの実行は待ち状態になります。

フルガーベージコレクションの実行
リソースの排他が解除されると，フルガーベージコレクションが実行されます。

それぞれの処理について説明します。

＜この項の構成＞

(1)　メモリ監視

(2)　リソース排他のチェック

(3)　フルガーベージコレクションの実行待ち

(4)　ガーベージコレクションの実行

(5)　注意事項

(1)　メモリ監視

監視タイマスレッドはJavaVMのメモリを監視し，次のどれかの条件を満たす場合，ガーベージコレクション制御機能にガーベージコレクションの実行要求を出します。

Tenured領域消費サイズ/Tenured領域合計サイズ×100≧ガーベージコレクション制御のしきい値

New領域合計サイズ/Tenured領域最大空きサイズ×100≧ガーベージコレクション制御のしきい値

Permanent領域消費サイズ/Permanent領域合計サイズ×100≧ガーベージコレクション制御のしきい値

(2)　リソース排他のチェック

ガーベージコレクション実行が要求されると，ガーベージコレクション制御機能は，バッチアプリケーションが使用しているコネクションを調査します。コネクションの調査では，バッチアプリケーションがリソース排他中かどうかを確認します。

次の表にリソースの排他中とみなす状態を示します。

表14-10　リソースの排他中とみなす状態

トランザクション
状態
DB Connector
JDBC

トランザクション外
SQL文を実行中※1

java.sql.Statement#executeの実行中

java.sql.Statement#executeUpdateの実行中

java.sql.Statement#executeQueryの実行中

java.sql.Statement#executeBatchの実行中

○
×

ResultSetに対する操作中

java.sql.ResultSet#deleteRowの実行中

java.sql.ResultSet#insertRowの実行中

java.sql.ResultSet#updateRowの実行中

○
×

オブジェクト取得などの操作中※1

java.sql.Statement#addBatchの実行中

java.sql.Connection#prepareCallの実行中

java.sql.Connection#prepareStatementの実行中

○
×

トランザクション中

Connection APIによるトランザクション実行中※2

ローカルトランザクション（JTA）実行中※2

○
×

グローバルトランザクション（JTA）実行中
－
－

（凡例）○：リソース排他中として扱う　×：リソース排他がないものとして扱う

　　　　－：該当しない

注※1　表中のjava.sql.Statementは継承クラスであるjava.sql.PreparedStatement，java.sql.CallableStatementを含みます。

注※2　トランザクションの開始後（setAutoCommit(false)やUserTransaction.beginの実行後），SQL文の実行またはResultSetに対する操作を1回以上実行していて，トランザクションの決着処理が完了していない状態を指します。

JDBCを使用したリソース操作については，リソース排他がないものとして扱われます。例えば，JDBCのSQL文の実行と，DB Connectorでのトランザクション処理が混在するプログラムを実行した場合，DB Connectorのトランザクション処理だけがガーベージコレクション制御の対象となります。

(3)　フルガーベージコレクションの実行待ち

リソース排他中と判断されると，メッセージKDJE55025-Iを出力して，フルガーベージコレクションの実行待ち状態になります。リソース排他が一つでもあると，フルガーベージコレクションは待機し続けます。フルガーベージコレクション実行待ちの例を次の図に示します。

図14-11　フルガーベージコレクション実行待ちの例

この図では，一つのジョブプログラム中で二つのリソースにアクセスしています。リソース排他中にフルガーベージコレクションの実行が要求されると，ガーベージコレクション制御機能はフルガーベージコレクションの実行を待機状態にします。二つのリソースアクセスが終了するcon2.commit()が実行されると，排他が解除されます。

(4)　ガーベージコレクションの実行

リソース排他がなくなると，フルガーベージコレクションが実行されます。

(5)　注意事項

同時に実行できるバッチアプリケーションは一つだけです。

一つのバッチアプリケーションから複数のリソースへの処理ができます。ただし，グローバルトランザクションは使用できません。

フルガーベージコレクションの実行待ち状態でも，空きメモリが不足すると，JavaVMによってフルガーベージコレクションが実行されることがあります。これは，ガーベージコレクション実行時のメモリ使用量のしきい値が大きい場合や，リソースの排他区間が長い場合などに発生します。マニュアル「Cosminexus　システム設計ガイド」のガーベージコレクション制御で使用するしきい値の設定に関する説明を参照して，メモリ使用量のしきい値をチューニングしてください。

14.7　コンテナ拡張ライブラリ

バッチサーバでは，アプリケーション間で共通に利用したい処理がある場合に，ユーザ作成のライブラリを利用できます。ユーザ作成のライブラリを利用することで，アプリケーションの機能を拡張できます。

アプリケーションが共通に利用できるライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することで，アプリケーション間で共通して，ユーザ作成のライブラリを呼び出せるようになります。

バッチサーバではコンテナ拡張ライブラリを利用できますが，バッチアプリケーション自体をコンテナ拡張ライブラリに設定して使用することはできません。

また，サーバ起動・停止フック機能を利用することで，サーバの起動，終了時にコンテナ拡張ライブラリが呼び出されるようにできます。また，コンテナ拡張ライブラリで使用するJNI機能の初期化などを行うことができます。

コンテナ拡張ライブラリを使用するためには，ライブラリを一つのJARファイルにまとめ，コンテナ拡張ライブラリを使用するための設定をusrconf.cfgで定義します。また，コンテナ拡張ライブラリがJNIを利用する場合は，サーバ起動・停止フック機能を使用するための設定も必要です。

なお，コンテナ拡張ライブラリの利用の概要とサーバ起動・停止フック機能の実装方法については，「10.　コンテナ拡張ライブラリ」を参照してください。

また，バッチサーバ側のコンテナ拡張ライブラリの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

注意

コンテナ拡張ライブラリには，次のアクセス権が付与されます。アクセス権は変更できません。

java.security.AllPermission

ただし，java.lang.RuntimePermissionのsetSecurityManagerアクセス権は付与されません。

15.　バッチアプリケーション

バッチアプリケーションとは，バッチ処理を実装したJavaアプリケーションです。この章では，バッチアプリケーションの実行方法，およびバッチアプリケーションの作成方法について説明します。

＜この章の構成＞

15.1　バッチアプリケーションの実行方法

15.2　バッチアプリケーションの作成

15.3　リソースに接続するバッチアプリケーションの作成

15.4　EJBにアクセスするバッチアプリケーションの作成

15.5　Javaアプリケーションからの移行

15.1　バッチアプリケーションの実行方法

ここでは，バッチアプリケーションの開始方法について説明します。また，バッチアプリケーションの強制停止の方法についても説明します。

＜この節の構成＞

15.1.1　バッチアプリケーションの開始方法

15.1.2　バッチアプリケーションの強制停止の方法

15.1.3　バッチアプリケーションで使用するコマンドの実行について

15.1.1　バッチアプリケーションの開始方法

バッチアプリケーションを開始するにはcjexecjobコマンドを使用します。cjexecjobコマンドを実行するには，次の三つの方法があります。

cjexecjobコマンドを直接実行する方法
JP1/AJS2およびBJEXを使用しない場合はこの方法で開始します。

cjexecjobコマンドをJP1/AJS2のジョブとして定義しておき，JP1/AJS2から実行する方法
JP1/AJS2だけを使用する場合はこの方法で開始します。

cjexecjobコマンドをBJEXのジョブステップとして定義しておき，JP1/AJS2からBJEXのジョブを実行する方法
JP1/AJS2およびBJEXを使用する場合はこの方法で開始します。

ここでは，2.および3.の方法でバッチアプリケーションを開始するときの，JP1/AJS2およびBJEXのジョブの定義について説明します。

なお，JP1/AJS2やBJEXからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

＜この項の構成＞

(1)　JP1/AJS2だけを使用する場合

(2)　JP1/AJS2およびBJEXを使用する場合

(1)　JP1/AJS2だけを使用する場合

JP1/AJS2と連携する場合，cjexecjobコマンドをJP1/AJS2のUNIXジョブまたはPCジョブとして定義しておきます。JP1/AJS2のジョブの属性を定義する画面の「スクリプトファイル名」「パラメーター」および「実行時のユーザー」の項目には，次に示す内容を設定してください。

スクリプトファイル名
cjexecjobコマンドを指定します。cjexecjobコマンドのパスについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

パラメーター
実行するバッチアプリケーションのクラス名と引数を指定します。

実行時のユーザー
バッチサーバを実行するユーザを指定します。

なお，JP1/AJS2での設定の詳細については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

(2)　JP1/AJS2およびBJEXを使用する場合

JP1/AJS2およびBJEXと連携する場合，JP1/AJS2およびBJEXにはそれぞれ次の内容を設定してください。

BJEXの設定
BJEXのバッチジョブにcjexecjobコマンドの実行を定義します。このとき，cjexecjobコマンドを，バッチジョブのジョブステップとして定義してください。
また，BJEXのジョブ定義XMLには次の内容を定義します。

EXEC要素
cjexecjobコマンドを実行するための定義をします。

PGM属性
cjexecjobコマンドを定義します。

PARM属性
cjexecjobコマンドの引数を定義します。ただし，引数の長さの上限は，BJEXの仕様に準拠します。

BJEXでの設定の詳細については，マニュアル「uCosminexus Batch Job Execution Server 使用の手引」を参照してください。

JP1/AJS2の設定
BJEXのバッチジョブの実行コマンドをジョブとして定義します。
JP1/AJS2での設定の詳細については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

15.1.2　バッチアプリケーションの強制停止の方法

バッチアプリケーションを強制停止するには次のどちらかの方法があります。

cjkilljobコマンドを直接実行する方法
JP1/AJS2を使用しない場合はこの方法で開始します。

cjkilljobコマンドをJP1/AJS2のリカバリージョブとして定義しておき，ジョブやジョブネットの強制停止の延長で実行する方法
BJEXの使用の有無に関係なく，JP1/AJS2を使用する場合はこの方法で開始します。

ここでは，JP1/AJS2のリカバリージョブとしてバッチアプリケーションを強制停止するときの定義方法を説明します。

なお，バッチアプリケーションの強制停止に失敗した場合，バッチサーバの強制停止が実行されます。このため，複数のアプリケーションを続けて実行する場合は，バッチサーバの再起動が必要になります。バッチアプリケーションの強制停止失敗に備えて，あらかじめバッチサーバを自動再起動するよう設定しておくことをお勧めします。バッチサーバの自動再起動は，Management Serverの運用監視を使用して実現します。

＜この項の構成＞

(1)　JP1/AJS2だけを使用する場合

(2)　JP1/AJS2およびBJEXを使用する場合

(1)　JP1/AJS2だけを使用する場合

JP1/AJS2と連携する場合，ジョブネットまたはジョブの強制終了をする際に，cjkilljobコマンドをJP1/AJS2のリカバリージョブとして定義しておきます。ただし，ルートジョブネットを強制停止する場合は，リカバリージョブは実行されません。このため，バッチアプリケーションがバッチサーバ上で実行されたままになります。その場合は，cjkilljobコマンドを直接実行して，バッチアプリケーションを強制停止してください。

JP1/AJS2での設定の詳細については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

(2)　JP1/AJS2およびBJEXを使用する場合

バッチアプリケーションの強制停止は，JP1/AJS2のリカバリージョブとして定義します。リカバリージョブの定義については，(1)を参照してください。

15.1.3　バッチアプリケーションで使用するコマンドの実行について

バッチアプリケーションで使用するコマンドには次の2種類があります。

cjexecjobコマンド（バッチ実行コマンド）
バッチアプリケーションを実行するためのコマンドです。

cjkilljobコマンド（バッチ強制停止コマンド）
実行中のバッチアプリケーションを強制停止するためのコマンドです。

これらのコマンドは，バッチサーバの状態によって実行できないことがあります。バッチサーバの状態とコマンドの実行について説明します。なお，コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」のバッチアプリケーションで使用するコマンドに関する説明を参照してください。

＜この項の構成＞

(1)　バッチサーバの状態とコマンドの実行

(2)　コマンド処理中にバッチサーバが異常終了した場合

(1)　バッチサーバの状態とコマンドの実行

cjexecjobコマンドおよびcjkilljobコマンドは，バッチサーバの状態によって実行できないことがあります。コマンドを実行できるバッチサーバの状態を次の図に示します。

図15-1　コマンドを実行できるバッチサーバの状態

cjexecjobコマンドおよびcjkilljobコマンドはバッチサーバ稼働中に実行できます。

バッチサーバ起動中，バッチサーバ停止中はcjexecjobコマンドおよびcjkilljobコマンドは実行できません。メッセージKDJE55012-Eが出力されます。また，バッチサーバの停止完了後も，cjexecjobコマンドおよびcjkilljobコマンドは実行できません。

また，バッチサーバでほかのコマンドを処理している場合，コマンドの種類によっては実行できない場合があります。バッチサーバでコマンドを処理しているときの，コマンドの実行可否を次の表に示します。

表15-1　バッチサーバでコマンドを処理しているときのコマンドの実行可否

実行するコマンド | 処理中のコマンド
cjexecjob | cjkilljob | サーバ管理コマンド
cjexecjob | × | × | ○
cjkilljob | ○ | × | ○
サーバ管理コマンド | cjstoprar | × | × | △※1
cjstoprar以外のコマンド | ○ | ○ | △※1
cjstopsvまたはcmx_stop_target | ○※2 | ○※2 | △※1
cjdumpsv | ○ | ○ | ○

（凡例）○：実行できる　×：実行できない　△：コマンドの種類によって異なる

注※1　サーバ管理コマンドの種類によって動作が異なります。詳細については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のサーバ管理コマンドの排他制御に関する説明を参照してください。

注※2　実行中のバッチアプリケーションがある場合は，メッセージKDJE55033-Iを出力し，バッチアプリケーションの終了を待機します。

(2)　コマンド処理中にバッチサーバが異常終了した場合

バッチサーバでcjexecjobコマンドおよびcjkilljobコマンドを処理しているときに，バッチサーバが異常終了した場合，メッセージKDJE55021-Eが出力されます。バッチサーバの状態を確認してから再度コマンドを実行してください。

15.2　バッチアプリケーションの作成

バッチアプリケーションとは，バッチ処理の内容を実装したJavaアプリケーションです。ここでは，バッチアプリケーションの規則と注意事項を説明します。

＜この節の構成＞

15.2.1　バッチアプリケーションの作成規則

15.2.2　バッチアプリケーション作成時の注意

15.2.1　バッチアプリケーションの作成規則

バッチアプリケーションの作成規則について説明します。

＜この項の構成＞

(1)　バッチアプリケーションのファイル形式

(2)　バッチアプリケーションに実装できる処理

(3)　バッチ処理の開始と終了

(1)　バッチアプリケーションのファイル形式

バッチアプリケーションは，JavaVMで規定しているクラスファイル形式にします。なお，複数のクラスを使用する場合は次のこともできます。

クラスファイルを配置したディレクトリをクラスパスに含める。

クラスファイルをアーカイブしたJARファイルをクラスパスに含める。

(2)　バッチアプリケーションに実装できる処理

バッチアプリケーションには，Javaで記述できる処理を実装できます。ただし，ファイルの操作やバッチアプリケーション内で使用するスレッドなどについて，使用時の注意事項があります。アプリケーション作成時の注意については，「15.2.2　バッチアプリケーション作成時の注意」を参照してください。

(3)　バッチ処理の開始と終了

バッチ処理の開始および終了は，バッチアプリケーションに次のように定義してください。

●バッチ処理の開始

バッチ処理の開始メソッドとして，次のどちらかのメソッドをバッチアプリケーションに定義してください。

public static void main(String[])

public static int main(String[])

mainメソッドの戻り値の型と修飾子が異なる場合，バッチアプリケーションは実行できません。なお，mainメソッドにはthrowsを指定できます。mainメソッドの引数には，cjexecjobコマンドに指定した引数が文字列配列で渡されます。

●バッチ処理の終了

バッチアプリケーションが次のどちらかの状態になると処理が終了します。

cjexecjobコマンドの引数に指定したクラスのmainメソッドの実行が終了する。

例外やエラーがmainメソッドの外にスローされる。

15.2.2　バッチアプリケーション作成時の注意

ここでは，バッチアプリケーション作成時に注意が必要となる処理や，バッチアプリケーションでは使用できない機能について説明します。これらの内容を確認の上，バッチアプリケーションを作成してください。

＜この項の構成＞

(1)　注意が必要な処理

(2)　バッチアプリケーションで実装できない機能

(1)　注意が必要な処理

次に示す処理は，バッチアプリケーションを作成する際に注意が必要です。

●ファイルやディレクトリの操作

バッチアプリケーションでは，次に示すファイルやディレクトリは操作しないでください。

Cosminexusのインストールディレクトリ以下のファイルやディレクトリ
Cosminexusのインストールディレクトリ以下のファイルやディレクトリについては，マニュアル「Cosminexus　システム構築ガイド」のインストール後のディレクトリ構成に関する説明を参照してください。

バッチサーバの作業ディレクトリ以下のファイルやディレクトリ
バッチサーバの作業ディレクトリについては，マニュアル「Cosminexus　システム構築ガイド」のバッチサーバの作業ディレクトリに関する説明を参照してください。

また，バッチアプリケーションでファイルやディレクトリを扱う場合，ファイルやディレクトリのパスに相対パスを使用できません。cjexecjobコマンドを実行したディレクトリからの相対パスを取得したい場合は，ejbserver.batch.currentdirの値を使用してください。ejbserver.batch.currentdirについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

次に，バッチアプリケーションの修正例を示します。

修正前

File f = new File("DataFile.txt");

修正後

File f = new File(System.getProperty("ejbserver.batch.currentdir") + System.getProperty("file.separator") + "DataFile.txt");

●スレッドの使用

バッチサーバは，バッチアプリケーションが作成および開始したスレッドの終了を待ちません。バッチアプリケーション内でスレッドを使用する場合は，バッチアプリケーションを終了する前に，開始したすべてのユーザスレッドを完了するように実装してください。また，ユーザスレッドはメソッドキャンセルの対象外です。

バッチアプリケーションが作成したスレッドが残っていると，バッチアプリケーションのクラスや使用したリソースは解放されません。このため，次にバッチアプリケーションを開始しようとすると，バッチアプリケーションの開始に失敗するおそれがあります。また，ユーザスレッド内では，「3.2　バッチアプリケーション実行基盤の機能の概要」で説明しているバッチサーバの機能を呼び出すことはできません。

●JavaVM終了時のリソースの自動クローズ

バッチサーバではサーバのJavaVM上でバッチアプリケーションを実行します。このため，JavaVM終了による自動的なリソースのクローズ処理を期待した実装をしている場合は，メモリやファイルディスクリプタのリークが発生します。例えば，次の場合にリークが発生します。

ZIPファイルまたはJARファイルをオープンしている場合，明示的にクローズしないとCヒープ領域がリークします。

java.io.File.deleteOnExit()を使用しても，バッチサーバが停止するまでファイルは削除されません。バッチサーバが停止するまでCヒープ領域がリークします。

この問題を回避するためには，リソースが正しくクローズされるようにバッチアプリケーションを実装してください。

また，ファイルやソケットなども明示的にクローズしていないと，リソース解放のタイミングが不定になります。これによって，次回以降のバッチアプリケーションの実行に影響を及ぼすおそれがあります。ファイルやソケットは明示的にクローズするようにしてください。

なお，バッチサーバの場合，コネクションの自動クローズは使用できません。バッチアプリケーション内で必ずコネクションをクローズしてください。

(2)　バッチアプリケーションで実装できない機能

次に示す機能はバッチアプリケーションでは使用できません。「対処方法」に示す手段で対応してください。

●標準入力からの入力

java.lang.System.inなどを使用した標準入力からの入力処理はできません。

対処方法

入力処理が必要な場合はファイルを使用してください。

●シャットダウンフックの使用

シャットダウンフックは使用できません。

対処方法

バッチアプリケーション終了時に実施したい処理がある場合は，mainメソッドのfinallyブロック内に処理を記述してください。

●JNIの使用

JNI経由でのネイティブライブラリの実行機能は使用できません。

対処方法

JNIを使用する場合は，コンテナ拡張ライブラリ経由で使用してください。このとき，ネイティブライブラリのロードはコンテナ拡張ライブラリ内で実施します。

●JavaVM終了メソッドの使用

次に示すメソッドは使用できません。

java.lang.System.exit(int);

java.lang.Runtime.exit(int);

java.lang.Runtime.halt(int);

これらのメソッドを使用した場合は，バッチサーバごとJavaVMが終了します。

対処方法

public static int main(String[])メソッドにバッチ処理の内容を記述します。終了コードを返す場合は，return <終了コード>を使用します。ただし，returnを使用する場合は，finallyブロックが実行されます。

●システムプロパティのセットの置き換え

次に示すメソッドは使用できません。

java.lang.System.setProperties(java.util.Properties)

対処方法

java.lang.System.setProperty(String, String)を使用します。

●標準出力ストリームおよび標準エラー出力ストリームの割り当てのし直し

次に示すメソッドは使用できません。

java.lang.System.setOut(java.io.PrintStream)java.lang.System.setErr(java.io.PrintStream)

対処方法

java.lang.System.outおよびjava.lang.System.errを使用しないで，出力したいPrintStreamオブジェクトを直接使用します。

15.3　リソースに接続するバッチアプリケーションの作成

ここでは，リソースに接続するバッチアプリケーションの作成方法について説明します。新規にバッチアプリケーションを作成する場合と，既存のバッチアプリケーションから移行する場合について説明します。

＜この節の構成＞

15.3.1　新規にバッチアプリケーションを作成する場合

15.3.2　既存のバッチアプリケーションから移行する場合

15.3.3　リソースに接続するバッチアプリケーションの注意

15.3.1　新規にバッチアプリケーションを作成する場合

新規にバッチアプリケーションを作成する場合，リソースへの接続にはDB Connectorを使用することをお勧めします。DB Connectorとは，Cosminexusで提供するデータベースに接続するためのリソースアダプタです。DB Connectorを使用したリソースに接続する方法を次に示します。

バッチサーバでDB Connectorを設定します。
ユーザ指定名前空間機能を使用して，DB Connectorのオブジェクトに別名を付けてJNDI名前空間に登録します。バッチアプリケーションからデータベースに接続するときには，必ずユーザ指定名前空間機能を使用してください。
別名は，DB Connectorをバッチサーバにデプロイしたあと，Connector属性ファイルで設定します。次の設定例のように，Connector属性ファイルの<resource-external-property>タグに<optional-name>タグを追加して別名を設定します。
設定例

<connector-runtime>
    ：
  <resource-external-property>
      <optional-name>DB Connectorの別名</optional-name>
  </resource-external-property>
</connector-runtime>

DB Connectorの別名の付け方については，「8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。
また，DB Connectorの設定の流れについては，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定に関する説明を参照してください。

1.で設定した別名でDB Connectorをルックアップし，コネクションファクトリ（javax.sql.DataSourceクラス）を取得します。
取得したコネクションファクトリからjava.sql.Connectionを取得します。コーディング例を次に示します。

String dbName = <DB Connectorの別名>;
InitialContext ic = new InitialContext();
DataSource ds = (DataSource) ic.lookup(dbName);
Connection con = ds.getConnection();

取得したjava.sql.Connectionを使用して，リソースに接続します。
JDBCドライバの提供するjava.sql.ConnectionとAPIは同じです。

注意

DB Connectorを使用する場合，バッチサーバでDB Connectorを開始してからバッチアプリケーションを開始してください。

15.3.2　既存のバッチアプリケーションから移行する場合

既存のバッチアプリケーション（Javaアプリケーション）から移行する場合，リソースに接続する方法は次の2種類があります。

Cosminexusで提供するDB Connectorを使用したリソース接続に変更する。

JDBCドライバを使用してリソースに接続する（接続方法を変更しない）。

DB Connectorを使用しない場合，バッチアプリケーションのコードを修正する必要はありません。ただし，DB Connectorが提供する機能およびガーベージコレクション制御機能は利用できません。ここでは，リソースの接続方法をDB Connectorに変更する場合の移行方法と，JDBCドライバを使用する場合（接続方法を変更しない場合）の移行方法を説明します。

＜この項の構成＞

(1)　DB Connectorを使用したリソース接続に変更する

(2)　JDBCドライバを使用してリソースに接続する

(1)　DB Connectorを使用したリソース接続に変更する

DB Connectorを使用する場合，DB Connectorからjava.sql.Connectionを取得するようバッチアプリケーションを変更してください。変更方法を次に示します。

バッチサーバでDB Connectorを設定します。
ユーザ指定名前空間機能を使用して，DB Connectorのオブジェクトに別名を付けてJNDI名前空間に登録します。バッチアプリケーションからデータベースに接続するときには，必ずユーザ指定名前空間機能を使用してください。
別名は，DB Connectorをバッチサーバにデプロイしたあと，Connector属性ファイルで設定します。次の設定例のように，Connector属性ファイルの<resource-external-property>タグに<optional-name>タグを追加して別名を設定します。
設定例

<connector-runtime>
    ：
  <resource-external-property>
      <optional-name>DB Connectorの別名</optional-name>
  </resource-external-property>
</connector-runtime>

DB Connectorの別名の付け方については，「8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。
また，DB Connectorの設定の流れについては，マニュアル「Cosminexus　システム構築ガイド」のリソースアダプタの設定に関する説明を参照してください。

バッチアプリケーション内のリソース接続処理のコードをDB Connectorを使用するよう変更します。
変更前のバッチアプリケーションを次に示します。下線部分はConnection取得処理です。この処理を「変更後のバッチアプリケーション」の下線部分の処理に変更してください。「変更後のバッチアプリケーション」の下線部分は，DB ConnectorのConnection取得処理です。

変更前のバッチアプリケーション

Class.forName("oracle.jdbc.driver.OracleDriver");
Connection con = DriverManager.getConnection(uri,"user","pass");
con.setAutoCommit(false);
Statement stmt = con.createStatement();
stmt.executeBatch();
con.commit();

変更後のバッチアプリケーション

String dbName = <DB Connectorの別名>
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)ic.lookup(dbName);
Connection con = ds.getConnection();
con.setAutoCommit(false);
Statement stmt = con.createStatement();
stmt.executeBatch();
con.commit();

DB Connectorから取得したjava.sql.Connectionは，JDBCドライバのjava.sql.Connectionと同様に使用できます。このため，java.sql.Connectionの取得方法だけを変更すれば，ほかのバッチアプリケーションのコードを変更する必要はありません。

注意

DB Connectorを使用する場合，バッチサーバでDB Connectorを開始してからバッチアプリケーションを実行してください。

(2)　JDBCドライバを使用してリソースに接続する

JDBCドライバを使用する場合，バッチアプリケーションのコードを修正する必要はありません。ただし，使用するJDBCドライバのライブラリをバッチサーバのクラスパスに追加する必要があります。詳細は，使用するJDBCドライバの設定に従ってください。次に，JDBCドライバのライブラリをバッチサーバのクラスパスに追加する方法を示します。バッチサーバのクラスパスに追加するには，usrconf.cfg（バッチサーバ用オプション定義ファイル）に次の記述を追加します。

add.class.path=<JDBCドライバのライブラリのフルパス>

なお，usrconf.cfg（バッチサーバ用オプション定義ファイル）については，マニュアル「Cosminexus　リファレンス　定義編」のusrconf.cfg（バッチサーバ用オプション定義ファイル）に関する説明を参照してください。

15.3.3　リソースに接続するバッチアプリケーションの注意

リソースに接続するバッチアプリケーションを作成するときには，次のことに注意してください。

●バッチアプリケーション実行時の注意

バッチアプリケーション実行中には，DB Connectorの停止や設定変更をしないでください。DB Connectorの停止や設定変更は，バッチアプリケーションが終了してから実施します。

●コネクションのクローズ

バッチサーバでは，コネクションの自動クローズは実行されません。このため，使用したコネクションは必ずクローズするよう，アプリケーションに実装してください。

●JTAのローカルトランザクションの使用

バッチアプリケーションの中で，JTAのローカルトランザクションを使用できます。JTAのローカルトランザクションは，次に示す方法で使用します。

次のどちらかの方法でUserTransactionオブジェクトを取得します。

ネーミングサービスからルックアップして取得する。
ルックアップ名：HITACHI_EJB/SERVERS/<サーバ名称>/SERVICES/UserTransaction

com.hitachi.software.ejb.ejbclient.UserTransactionFactoryクラスのgetUserTransactionメソッドを使用して取得する。

UserTransactionオブジェクトのbegin()メソッドを呼び出して，トランザクションを開始します。

リソースに接続します。

UserTransactionオブジェクトのcommit()またはrollback()を呼び出して，トランザクションを決着します。

UserTransactionインタフェースの使用方法の詳細については，「9.17.2　UserTransactionインタフェースを使用する場合の処理概要と留意点」を参照してください。

●トランザクションの決着

バッチサーバではトランザクションの自動決着機能をサポートしていません。開始したトランザクション（javax.transaction.UserTransaction）は，バッチアプリケーション内で必ず決着処理を実施してください。

トランザクションの決着をしないでバッチアプリケーションを終了すると，次のバッチアプリケーションの実行でトランザクションを開始するときに（javax.transaction.UserTransaction#begin()），次のエラーが発生します。

javax.transaction.NotSupportedException: KDJE31009-E No nested transaction is supported.

トランザクションの決着処理をしないでバッチアプリケーションを終了した場合，バッチサーバを再起動してトランザクションが使用できない状態を回復してください。

15.4　EJBにアクセスするバッチアプリケーションの作成

バッチアプリケーションからJ2EEアプリケーションのEJBにアクセスできます。EJBにアクセスするバッチアプリケーションを作成する場合，アクセスするEJBを次に示す名称でルックアップして使用することができます。

自動的にバインドされる名称(HITACHI_EJBで始まる名称)

ユーザ指定名前空間機能を使用した別名

EJBにアクセスする場合，次に示す手順でバッチアプリケーションを準備します。

バッチアプリケーションからアクセスするEJBの準備
バッチアプリケーションからアクセスするEJBを含むJ2EEアプリケーションを開始状態にします。

バッチアプリケーションの実装
バッチアプリケーション内に，EJBを使用するためのコードを実装します。

バッチアプリケーションの実行
2.で作成したバッチアプリケーションを実行します。

それぞれの手順の詳細を次に説明します。

＜この節の構成＞

(1)　EJBの準備

(2)　バッチアプリケーションの実装

(3)　バッチアプリケーションの実行

(1)　EJBの準備

バッチアプリケーションからアクセスするEJBを持つJ2EEアプリケーションを用意します。また，J2EEアプリケーションを実行するためのJ2EEサーバも用意します。J2EEサーバの構築については，マニュアル「Cosminexus　簡易構築・運用ガイド」のJ2EEアプリケーションを実行するシステム構築に関する説明を参照してください。

構築したJ2EEサーバ上で，J2EEアプリケーションを開始します。cjgetstubsjarコマンドを使用して，開始したJ2EEアプリケーションのRMI-IIOPスタブおよびインタフェースを取得しておきます。

なお，バッチアプリケーションからEJBにアクセスする場合，別名によるルックアップをするときは，事前にユーザ指定名前空間機能を使用してEJBの別名を設定しておいてください。EJBの別名の設定については，「8.3　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

(2)　バッチアプリケーションの実装

「(1)　EJBの準備」で設定したEJBを取得するためのコードを，バッチアプリケーションに実装します。コードの例を次に示します。

String EjbName = <EJBのルックアップ名>;
InitialContext ic = new InitialContext();
Object objref = ic.lookup(EjbName);
<ホームインタフェースクラス名> home =
  (<ホームインタフェースクラス名>) PortableRemoteObject.narrow(objref,
                            <ホームインタフェースクラス名>.class);
<EJBオブジェクトクラス名> ejbobj = home.create();

ホームインタフェースおよびEJBオブジェクトファイルはあらかじめ準備しておいてください。バッチアプリケーションのコンパイル時および実行時にクラスパスに含める必要があります。

(3)　バッチアプリケーションの実行

バッチアプリケーションを実行する場合，クラスパスに「(1)　EJBの準備」で取得したスタブや「(2)　バッチアプリケーションの実装」で使用したインタフェースファイルをフルパスで指定します。

EJBを検索するネーミングサービスのURLは，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）のjava.naming.provider.urlの値として指定します。

ただし，リソース接続機能とEJBアクセス機能を同時に使用する場合は，ネーミングサービス切り替え機能を使用して，EJBをルックアップするネーミングサービスを指定してください。ネーミングサービス切り替え機能については，「8.6　CORBAネーミングサービスの切り替え」を参照してください。

15.5　Javaアプリケーションからの移行

Cosminexusで提供するcjclstartapコマンドで実行していたJavaアプリケーションは，バッチサーバでバッチアプリケーションとして実行できます。Javaアプリケーションを，バッチサーバ上でバッチアプリケーションとして実行する場合，アプリケーションや実行環境の移行が必要となる場合があります。ここでは，アプリケーションおよび実行環境の移行について，移行が必要な場合と移行方法を説明します。

＜この節の構成＞

15.5.1　アプリケーションの移行が必要な場合

15.5.2　実行環境の移行が必要な場合

15.5.1　アプリケーションの移行が必要な場合

次の場合，Javaアプリケーションの移行が必要になります。

バッチアプリケーションの使用上の注意事項に該当する処理を実装している場合
ファイルやディレクトリの操作などは，バッチアプリケーションに実装する際に注意が必要となります。

移行方法

バッチアプリケーションで注意が必要な処理は，「15.2.2(1)　注意が必要な処理」に記載しています。これらの内容を参照して，Javaアプリケーションを修正してください。

バッチアプリケーションで使用できない機能を実装している場合
バッチアプリケーションでは使用できない機能が幾つかあります。例えば，標準入力からの入力やシャットダウンフックの使用はできません。

移行方法

バッチアプリケーションで使用できない機能および機能を使用するための代替方法は，「15.2.2(2)　バッチアプリケーションで実装できない機能」に記載しています。これらの内容を参照して，Javaアプリケーションを修正してください。

usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティを定義している場合
移行元のJavaアプリケーションで使用していたusrconf.properties（Javaアプリケーション用ユーザプロパティファイル）は引き続きバッチアプリケーションでも使用できます。
ただし，usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）の中に，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティ※を定義して，バッチアプリケーションから値を参照している場合はアプリケーションの修正が必要です。

移行方法

usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートしていないプロパティの値を参照しないように，バッチアプリケーションを修正してください。

注※

ユーザが定義したプロパティを除きます。なお，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされているプロパティについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

15.5.2　実行環境の移行が必要な場合

これまでJavaアプリケーションの実行環境で使用していた次の二つのファイルは，バッチサーバの実行環境でもそのまま使用できます。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）

usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）

ただし，次に示す条件に該当する場合は，ファイルの移行が必要になります。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）およびusrconf.properties（Javaアプリケーション用ユーザプロパティファイル）の格納場所を環境変数CJCLUSRCONFDIRに設定している場合

移行方法

usrconf.cfg（バッチアプリケーション用オプション定義ファイル）およびusrconf.properties（バッチアプリケーション用ユーザプロパティファイル）の格納場所を環境変数CJBATCHUSRCONFDIRにフルパスで設定してください。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）のadd.jvm.argに，-cp，-classpath，-D以外のオプションを設定している場合

移行方法

オプションの設定をusrconf.cfg（バッチサーバ用オプション定義ファイル）に記載してください。複数のバッチアプリケーションを一つのバッチサーバ上で順次実行する場合は，定義の設定値を調整する必要があります。次に例を示します。この例では，より大きい値を設定しているアプリケーション2の値をバッチサーバに設定しています。

例：アプリケーション1でadd.jvm.arg=-Xmx512m，アプリケーション2でadd.jvm.arg=-Xmx768mを設定していた場合

バッチサーバではadd.jvm.arg=-Xmx768mを設定してください。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）にejb.client.log.directoryを設定して，ログの出力先をデフォルトから変更している場合

移行方法

usrconf.cfg（バッチアプリケーション用オプション定義ファイル）にbatch.log.directoryを設定して，ログの出力先をデフォルトから変更してください。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）に，ejb.client.ejb.logまたはejb.client.log.appidを設定して，ログの出力先をデフォルトから変更している場合

移行方法

ありません。ejb.client.ejb.log，およびejb.client.log.appidを使用して指定していたログの出力先は，バッチサーバの場合は指定できません。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）にejb.client.directory.shareable=trueを設定して，アプリケーションを複数同時に実行している場合

移行方法

一つのバッチサーバ上で，複数のバッチアプリケーションを同時に実行することはできません。このため，バッチアプリケーションの最大同時実行数のバッチサーバを用意してください。それぞれのバッチサーバ上でバッチアプリケーションが動作するように，cjexecjobコマンドに指定するサーバ名を変更してください。

usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティを定義している場合
usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）の中に，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティ※を定義している場合は，usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）の修正が必要です。

移行方法

usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）から，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートしていないプロパティの定義を削除してください。

注※

ユーザが定義したプロパティを除きます。なお，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされているプロパティについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

16.　システムの構築

この章では，システムの構築支援機能について説明します。

システムの構築には，Smart Composer機能またはセットアップウィザードというシステム構築支援機能を使用します。リソースアダプタやJ2EEアプリケーションの設定には，サーバ管理コマンドまたはServer Plug-inという機能を使用します。これらの機能は，構築するシステムの構成や，リソースアダプタやアプリケーションに設定する内容，システム構築時のインタフェースなどを考慮して，どれを使用するかを選択できます。

また，この章では，構築済みの実行環境を切り替える機能についても説明します。

＜この章の構成＞

16.1　Cosminexusで提供するシステムの構築支援機能

16.2　Management Serverで構築したシステムの概要

16.3　Smart Composer機能を使用したシステム構築の特長

16.4　Smart Composer機能を使用したシステム構築の流れ

16.5　セットアップウィザードを使用したシステム構築の特長

16.6　セットアップウィザードを使用したシステム構築の流れ

16.7　リソースアダプタやJ2EEアプリケーションの設定

16.8　複数の構築済み実行環境の切り替え

16.1　Cosminexusで提供するシステムの構築支援機能

Cosminexusでは，システム構築支援機能として，次の2種類の機能を使用できます。

Smart Composer機能

セットアップウィザード

Smart Composer機能は，コマンドおよび定義ファイルを使用してシステムを構築するための機能です。事前に作成した定義ファイルの内容に従って，複数台のマシンで構成されるシステムを容易に構築できます。Smart Composer機能を使用すると，さまざまな構成のシステムを構築できます。

また，Smart Composer機能で構築したシステムは，一括した管理・運用ができます。Smart Composer機能で実施できるシステムの一括管理・一括運用については，「16.2　Management Serverで構築したシステムの概要」を参照してください。

セットアップウィザードは，対話形式のウィザードプログラムを使用してシステムを構築するための機能です。1台のマシンに，アプリケーションサーバとして必要なサーバプロセスをセットアップできます。構築作業は，画面に表示される項目を確認しながら進められます。事前に定義ファイルを準備したり，複数のコマンドを実行したりする必要がありません。できるだけ少ない手順で実行環境を構築したい場合にお勧めの機能です。

ただし，セットアップウィザードで構築できるシステムの構成には制限があります。

参考

システムを構築する方法には，Smart Composer機能またはセットアップウィザードを使用する方法以外に，次の方法があります。

運用管理ポータルでのシステム構築
運用管理ポータルを使用すると，Application Serverをインストールした複数のマシンに対して，Webブラウザからリモート操作でシステム構築を実行できます。運用管理ポータルの操作方法については，マニュアル「Cosminexus　運用管理操作ガイド」を参照してください。

ファイル編集とコマンド実行でのシステム構築
Application Serverをインストールしたマシンで，WebサーバやJ2EEサーバの定義ファイル類を編集したり，プロセスごとに提供されているコマンドを実行したりして，システムを構築します。Cosminexusが提供する定義ファイル類の詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。プロセスごとに提供されているコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

16.2　Management Serverで構築したシステムの概要

Smart Composer機能またはセットアップウィザードを使用してシステムを構築する場合，Management Serverというサーバプロセスを使用します。

Smart Composer機能では，構築したシステムを一括管理，および一括運用できます。システムの一括管理・一括運用は，Management Serverという運用管理プロセスによって実現します。Management Serverは，複数のホスト上に構築されているCosminexusシステム全体を一括管理，および一括運用します。Management Serverを使用することで，各ホスト上のサーバの環境設定をまとめて実施したり，サーバを一括起動したりできます。また，システム全体の状態を把握できるので，サーバの運用管理が容易になります。

セットアップウィザードを使用して構築したシステムも，Management Serverで管理・運用できます。Management Serverを使用して，1台のアプリケーションサーバマシンにセットアップされた複数のサーバプロセスを，適切な順序で起動したり，停止したりできます。

ここでは，Management Serverが管理する範囲と，Management Serverでのサーバ管理の概要について説明します。

＜この節の構成＞

16.2.1　Management Serverが管理する範囲

16.2.2　Management Serverでのサーバ管理

16.2.1　Management Serverが管理する範囲

Management Serverが管理する範囲のことを，運用管理ドメインといいます。運用管理ドメインでは，運用管理のプロセスとして，Management Server，および運用管理エージェントを使用します。

運用管理ドメインを次の図に示します。

図16-1　運用管理ドメイン

図中の項番について説明します。なお，説明の項番は，図中の項番と対応しています。

Management Server
運用管理ドメインを構成するサーバプログラムです。運用管理ドメイン単位に一つ配置します。Management Serverは，各ホストに配置した運用管理エージェントに指示を出して，それぞれのホストの運用管理を実行します。なお，Management Serverを配置したホストのことを，運用管理サーバといいます。

運用管理エージェント
運用管理者の代わりにそれぞれのホスト上のサーバを起動したり，定義ファイルを更新したりする，エージェントプログラムです。Management Serverからの指示を受けて操作を実行します。Management Serverで管理するホストに一つずつ配置します。

図16-1のように，Management Serverをアプリケーションサーバとは別のホストに配置するシステム構成モデルのことを，運用管理サーバモデルといいます。また，Management Serverをアプリケーションサーバと同じホストに配置して，そのホスト内のサーバを管理することもできます。同じホストに配置するシステム構成モデルのことを，ホスト単位管理モデルといいます。

次に示す場合，すべてのプロセスは1台のマシン内に構築されます。

セットアップウィザードを使用してシステムを構築する場合

Smart Composer機能を使用してバッチアプリケーションの実行環境を構築する場合

これらの場合，Management Serverは，同じマシン内に配置された運用管理エージェント経由で，各サーバプロセスの運用管理を実行します。

参考

Management Serverの機能を使用して，J2EEサーバ，SFOサーバ，またはバッチサーバの稼働情報を監視・収集する場合，運用監視エージェントというエージェントプログラムを使用します。監視対象にするホスト上で，監視対象にするJ2EEサーバ，SFOサーバ，またはバッチサーバに一つずつ含まれます。また，クラスタ構成の場合は，クラスタに含まれるJ2EEサーバに一つずつ含まれます。

業務用のサーバを配置したLANと管理用のサーバを配置したLANに分けている場合，運用管理サーバを管理用のサーバを配置したLANに置くこともできます。LANを分け，一つのマシンを複数のネットワークセグメントに接続する場合，環境設定に注意が必要です。詳細については，マニュアル「Cosminexus　運用管理操作ガイド」を参照してください。

16.2.2　Management Serverでのサーバ管理

Management Serverでは，Cosminexusが提供するサーバの実体を，論理サーバとして管理します。WebサーバやJ2EEサーバなどは，論理Webサーバ，論理J2EEサーバとして管理されます。また，バッチサーバは論理J2EEサーバとして管理されます。

さらに，共通の機能を提供する論理サーバの集合をクラスタとして扱います。クラスタに対しては，単体の論理サーバと同様の操作ができます。J2EEサーバクラスタ，Webサーバクラスタなどがあります。

論理サーバは，運用管理ドメイン内で一意な名称（論理サーバ名）で管理します。

Management Serverでは，運用管理ドメイン内の論理サーバを対象にして，運用管理操作を実行します。

Management Serverによる論理サーバの管理の概要を次の図に示します。

図16-2　Management Serverによる論理サーバの管理の概要

各ホスト上での操作は，Management Serverからの指示に従って，運用管理エージェントが実行します。運用管理エージェントを利用することで，複数のホストに分散して配置された論理サーバをManagement Serverで一元管理できます。なお，運用管理エージェントは，論理サーバのある各ホストで動作させる必要があります。運用管理ドメインは，互いに排他の関係になります。一つの論理サーバが複数の運用管理ドメインに包含されることはありません。

なお，Smart Composer機能でシステムを構築すると，Smart Composer機能のコマンドを使用して次の操作が実施できます。

サービスユニット単位での起動と停止

サービスユニット単位での運用監視

運用操作については，「17.　システムの日常運用」，および「18.　システムの保守」を参照してください。

16.3　Smart Composer機能を使用したシステム構築の特長

ここでは，Smart Composer機能を使用したシステム構築の特長について説明します。Smart Composer機能を使用したシステム構築では，論理サーバを稼働させるために必要な設定を一括で設定できます。

なお，Smart Composer機能でのシステム構築の詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

＜この節の構成＞

(1)　システム構成のパターン化による一括構築

(2)　JP1と連携したシステム構築・運用

(1)　システム構成のパターン化による一括構築

Smart Composer機能では，システム構成をパターン化することによってサーバを一括構築できるので，迅速にシステムを構築できます。

Smart Composer機能で構築できるシステム構成は，同じ機能構成やプロセス構成でパターン化された構成を対象としています。Smart Compser機能でシステムを構築する場合，J2EEサーバやWebサーバで構成される業務サービスを提供する閉じた部分系を，サービスユニットといいます。複数のホストでサービスユニットを持つことで，システム構成がパターン化するので，一括構築ができます。

Smart Composer機能では，最初に必要最小限の定義を記述しておくだけで，複数のサービスユニットに対して，一度に初期構築できます。また，すべてのサービスユニットの環境を一括で設定できます。

Smart Composer機能での一括構築の例を次の図に示します。

図16-3　Smart Composer機能での一括構築の例

Smart Composer機能を使用すると，設定情報を一括で各サーバ内のサービスユニットに設定します。この図の場合，アプリケーションサーバ1と2のサービスユニット内にある，Webサーバ，PRFデーモン，およびJ2EEサーバの設定が一括でできます。

(2)　JP1と連携したシステム構築・運用

Smart Composer機能を使用してシステムを構築・運用する際に，JP1と連携することもできます。システム構築時には，JP1/IM - CMと連携することで，システム構成の定義をビジュアルに定義できます。また，システム運用時には，JP1/AJS2 - SOと連携することで，シナリオによるシステムの自動運転が実現します。JP1との連携の詳細については，「21.　JP1と連携したシステムの運用」を参照してください。

16.4　Smart Composer機能を使用したシステム構築の流れ

Smart Composer機能を使用してシステムを構築する場合，システムを構築するユーザは，サーバの情報を設定した定義ファイルを作成します。その定義内容を，コマンドを使用してシステム内のすべてのサーバに対して一括で設定します。これによって，最小限の操作でシステムを構築できます。また，Smart Composer機能では，一つの設定情報を基に，複数のサーバを一括で設定します。このため，同じ機能構成・プロセス構成でパターン化されたシステムの構築に適しています。なお，Smart Composer機能で構築したシステムは，一括管理，および一括運用できます。

Smart Composer機能で構築したシステムで使用するリソースアダプタやJ2EEアプリケーションの設定には，サーバ管理コマンドを使用します。

Smart Composer機能でのシステム構築については，「16.2　Management Serverで構築したシステムの概要」を参照してください。サーバ管理コマンドおよびServer Plug-inでのJ2EEアプリケーションやリソースアダプタの設定の概要については，「16.7　リソースアダプタやJ2EEアプリケーションの設定」を参照してください。

Smart Composer機能による設定の流れを次の図に示します。

図16-4　Smart Composer機能による設定の流れ

Smart Composer機能による設定の流れは，次のとおりです。Smart Comopser機能のコマンドで操作します。なお，設定の流れは，バッチアプリケーションの実行環境を構築する場合も同じです。

サービスユニットの設定情報をまとめた定義ファイルを作成します。
サービスユニット内の，WebサーバやJ2EEサーバなどの設定情報を定義した，簡易構築定義ファイルを作成します。

Smart Composer機能のコマンドを使用して，Webシステムを構築します。
Smart Composer機能のコマンドを使用して，1.で作成した定義ファイルの内容からManagement Server上にWebシステムの情報モデルを生成します。また，生成した情報モデルを基にして，各サービスユニットに対して一括して情報を設定します。

参考

Management Serverの動作の環境設定には，Management Serverのコマンド（mngsvrctl）を使用します。mngsvrctlコマンドを使用して，Management Serverの管理ユーザアカウントを設定，およびManagement Serverをセットアップします。

16.5　セットアップウィザードを使用したシステム構築の特長

セットアップウィザードを使用すると，画面の表示を確認しながら，対話形式でシステムを構築できます。

セットアップウィザードを使用したシステム構築の特長は，次のとおりです。

対話形式のプログラムによる構築手順の簡略化
画面に表示される内容を確認しながら，必要な項目を入力して構築作業を進められます。事前に詳細なパラメタ設計をしたり，定義ファイルを作成したりする必要がありません。

デフォルト値の使用によるシステム構築作業時間の短縮
セットアップウィザードを使用すると，ほとんどの項目がデフォルト値を使用してセットアップされます。構築時には必要最小限の項目だけを設定すればよいため，細かな設定で迷うことなくシステムを構築できます。
これによって，システム構築作業に掛かる時間も短縮できます。

ただし，セットアップウィザードで実行できるのは，1台のマシンを対象にしたシステム構築だけです。セットアップウィザードでのシステム構築の詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

16.6　セットアップウィザードを使用したシステム構築の流れ

セットアップウィザードは，CUI画面を使用してシステム構築を実行します。定義ファイルなどを事前に準備する必要はありません。

セットアップウィザードによるシステム構築の流れを次の図に示します。

図16-5　セットアップウィザードによるシステム構築の流れ

セットアップウィザードでは，システムに必要なサーバプロセスの構築と，リソースアダプタの設定までを一括で実行できます。

ただし，J2EEアプリケーションのインポート，設定，開始については，セットアップウィザード実行後にサーバ管理コマンドを使用して実行します。サーバ管理コマンドについては，「16.7　リソースアダプタやJ2EEアプリケーションの設定」を参照してください。

16.7　リソースアダプタやJ2EEアプリケーションの設定

Cosminexusでは，リソースアダプタやJ2EEアプリケーションを設定するための機能として，サーバ管理コマンドおよびServer Plug-inを提供しています。ここでは，サーバ管理コマンド，Server Plug-inの概要，およびリソースアダプタやJ2EEアプリケーションの設定の流れを紹介します。

＜この節の構成＞

16.7.1　リソースアダプタやJ2EEアプリケーションの設定で使用する構築支援機能

16.7.2　リソースアダプタの設定の流れ

16.7.3　J2EEアプリケーションの設定の流れ

16.7.1　リソースアダプタやJ2EEアプリケーションの設定で使用する構築支援機能

リソースアダプタやJ2EEアプリケーションの設定をするには，サーバ管理コマンドまたはServer Plug-inを使用します。

＜この項の構成＞

(1)　サーバ管理コマンドでの設定

(2)　Server Plug-inでの設定

(1)　サーバ管理コマンドでの設定

サーバ管理コマンドとは，リソースやJ2EEアプリケーションを設定するためのCUIです。リソースアダプタやJ2EEアプリケーションの設定を，コマンドを使用して実行します。GUIでの対話処理が不要な場合などの運用環境の操作に適しています。なお，サーバ管理コマンドとServer Plug-inでは設定できる内容に差異があります。機能差異については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

(2)　Server Plug-inでの設定

Server Plug-inとは，リソースアダプタやJ2EEアプリケーションを設定するためのGUIです。Eclipseのプラグインとして提供しているので，リソースアダプタやJ2EEアプリケーションの設定を，Eclipseのビュー上で操作して実施できます。また，Server Plug-inでは，論理サーバの起動や停止もできるため，アプリケーション開発でEclipseを使用している場合は，アプリケーション開発から，J2EEアプリケーションやリソースアダプタの設定，テストまでを一貫してEclipse上で実施できる利点があります。

なお，Server Plug-inの使用は，構築したシステムでプロセスとしてManagement Serverを使用していることが前提となります。このため，Smart Composer機能，または運用管理ポータルで構築したシステムの場合に使用できます。

また，Server Plug-inはUNIX環境では使用できません。実行環境がUNIXの場合で，Server Plug-inを使用した操作を実施したい場合は，別途，uCosminexus Operatorをインストールしたマシンを用意し，Server Plug-inを使用するための設定をしてください。

Server Plug-inでは一部，設定できない項目があります。それらの設定項目については，サーバ管理コマンドを使用して設定します。サーバ管理コマンドおよびServer Plug-inで設定できる項目の一覧については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

16.7.2　リソースアダプタの設定の流れ

リソースアダプタの設定には，サーバ管理コマンドまたはServer Plug-inが使用できます。サーバ管理コマンドまたはServer Plug-inを使用してリソースアダプタの設定をして，サーバ管理コマンドを使用してリソースアダプタをデプロイします。リソースアダプタの設定について，次の図に示します。

図16-6　リソースアダプタの設定

サーバ管理コマンドまたはServer Plug-inで，リソースアダプタのインポートやプロパティ設定などをします。
リソースアダプタのプロパティ設定は，開発環境で実施しておきます。なお，プロパティの設定は，サーバ管理コマンドとServer Plug-inとで方法が異なります。サーバ管理コマンドを使用する場合は，コマンドを実行して属性ファイルを取得し，取得した属性ファイルにリソースアダプタのプロパティを設定します。Server Plug-inを使用する場合は，画面上でプロパティを設定します。

リソースアダプタのデプロイなどをします。
サーバ管理コマンドを使用して，1.でプロパティを設定した属性ファイルとリソースアダプタを，Smart Composer機能で構築した運用環境のサーバにデプロイします。

リソースアダプタの設定手順については，マニュアル「Cosminexus　簡易構築・運用ガイド」のリソースアダプタのデプロイの説明を参照してください。

16.7.3　J2EEアプリケーションの設定の流れ

J2EEアプリケーションの設定には，サーバ管理コマンドまたはServer Plug-inが使用できます。サーバ管理コマンドまたはServer Plug-inでJ2EEアプリケーションの設定をして，サーバ管理コマンドを使用してJ2EEアプリケーションをデプロイします。J2EEアプリケーションの設定について，次の図に示します。

図16-7　J2EEアプリケーションの設定

サーバ管理コマンドまたはServer Plug-inで，J2EEアプリケーションのインポートやプロパティ設定などをします。
開発環境で，サーバ管理コマンドまたはServer Plug-inでJ2EEアプリケーションをインポートしてプロパティを設定します。プロパティ設定後はエクスポートします。

J2EEアプリケーションのデプロイなどをします。
サーバ管理コマンドを使用して，J2EEアプリケーションを，Smart Composer機能で構築した運用環境のJ2EEサーバにデプロイします。

なお，J2EEアプリケーションの設定は，J2EEアプリケーションのデプロイのしかた（アーカイブ形式でデプロイするか，展開ディレクトリ形式でデプロイするか）によって手順が異なります。J2EEアプリケーションのプロパティ設定の手順については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を，J2EEアプリケーションのデプロイについては，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

16.8　複数の構築済み実行環境の切り替え

Cosminexusでは，1台のマシンに複数の構築済み実行環境を共存させ，それぞれの実行環境を切り替える機能を提供しています。構築済み実行環境の切り替えによって，同一製品のバージョンやパッチの違い，設定内容の違いなどによるシステムの動作を，1台のマシンで検証できます。

この節では，構築済み実行環境の切り替えの概要や，実行環境を切り替える場合の注意事項などについて説明します。なお，1台のマシンで同時に動作できる実行環境は一つです。

注意

構築済み実行環境の切り替えは，UNIX環境の場合に使用できます。退避機能と回復機能は，同じOSの同じバージョンのマシン環境上で実行してください。切り替え対象となる実行環境を構築する製品は，Application Server Standard，およびApplication Server Enterpriseです。

＜この節の構成＞

16.8.1　構築済み実行環境の切り替えの概要

16.8.2　構築済み実行環境の切り替えの流れ

16.8.3　構築済み実行環境を切り替える場合の注意

16.8.1　構築済み実行環境の切り替えの概要

ここでは，構築済み実行環境の切り替えの概要について説明します。

構築済み実行環境を切り替える場合，構築済みの実行環境ごとに退避環境を作成します。退避環境は，実行環境を圧縮して，稼働可能状態から退避状態（稼働できない状態）に遷移した環境です。複数の退避環境のうち，使用したい退避環境を稼働可能状態に回復して，実行環境を切り替えます。

複数の構築済み実行環境の切り替えの概要を次の図に示します。

図16-8　複数の構築済み実行環境の切り替えの概要

この図では，実行環境Aに対する退避環境Aと，実行環境Bに対する退避環境Bをそれぞれ作成して，実行環境を切り替えています。作成済みの退避環境は，一覧で出力したり，不要となった場合に削除したりできます。

次に，構築済み実行環境を切り替える場合の前提条件，切り替え時に使用する機能，および取得するログファイルについて説明します。

＜この項の構成＞

(1)　前提条件

(2)　構築済み実行環境の切り替えで使用する機能

(3)　構築済み実行環境の切り替え実行時に障害が発生した場合の対処

(1)　前提条件

切り替え対象となる実行環境を構築する製品は，Application Server Standard，およびApplication Server Enterpriseです。構築済み実行環境の切り替えは，UNIX環境の場合に使用できます。退避対象となる実行環境は，システムの構築が完了済みで，各サーバやサービスを起動していない状態（稼働可能状態）であることが前提です。

また，構築済み実行環境から退避環境を作成する場合に，実行環境はTAR形式またはCPIO形式に圧縮されます。このため，実行環境の切り替えは，TAR形式またはCPIO形式に対応している環境で実行する必要があります。

(2)　構築済み実行環境の切り替えで使用する機能

構築済み実行環境を切り替える場合，次の四つの機能を使用します。

退避機能
構築済み実行環境をTAR形式またはCPIO形式のファイルに圧縮して，退避環境を作成します。退避機能を実行しても，構築済み実行環境はそのまま残ります。退避環境は，複数作成でき，退避機能実行時に指定する識別子で管理できます。

回復機能
現在の構築済み実行環境をアンインストールして，退避環境を回復します。回復機能を実行しても，回復元の退避環境はそのまま残ります。実行環境の回復完了後に，回復元の退避環境を削除したい場合は，削除機能を実行してください。

削除機能
退避環境を削除します。退避環境が不要となった場合に実施します。

退避環境一覧出力機能
現在退避している退避環境の一覧を出力します。
退避環境一覧出力機能では，次の項目を出力します。

退避環境の識別子

退避環境の格納先パス

退避環境を作成した日付と時刻

退避環境に退避した製品の形名，バージョン情報および製品名

退避環境一覧の出力形式については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

これらの機能は，cosmienvコマンドに，機能に対応する引数を指定して実行します。cosmienvコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

(3)　構築済み実行環境の切り替え実行時に障害が発生した場合の対処

構築済み実行環境を切り替える場合は，cosmienvコマンドを実行します。cosmienvコマンド実行時に障害が発生した場合は，メッセージと，ログファイルの内容を基に障害を解析してください。ログファイルは機能ごとに取得され，次の場所に格納されます。

構築済み実行環境の切り替えで取得するログファイルの格納場所

/opt/Cosminexus/env/log

機能ごとに出力されるログファイルを次の表に示します。

表16-1　機能ごとに出力されるログファイル

機能の種類 | ログファイル名
退避機能 | cosmienv_s[n].log
回復機能 | cosmienv_d[n].log
削除機能 | cosmienv_r[n].log

なお，退避環境一覧出力機能の場合，ログファイルは出力されません。

ログファイルの内容については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。また，メッセージについては，マニュアル「Cosminexus　メッセージ2　KEOS／KEUC／KFCB編」を参照してください。

16.8.2　構築済み実行環境の切り替えの流れ

ここでは，構築済み実行環境を切り替える場合の流れについて説明します。構築済み実行環境の切り替えの流れを次の図に示します。

図16-9　構築済み実行環境の切り替えの流れ

この図では，1台のマシンで，実行環境のバージョンアップを実施し，バージョンアップ後の実行環境で動作確認をしたあと，バージョンアップ前の実行環境に戻しています。この場合，退避機能を使用して，各バージョンの実行環境を退避しているので，動作確認中に障害や不具合が発生しても，再インストールや環境設定などの作業を実施しないで，退避した実行環境に回復できます。

退避機能を使用すると，次に示す実行環境を1台のマシンに共存できます。

製品のバージョンが異なる実行環境

製品のバージョンが同じで，設定が異なる実行環境

製品のバージョンが同じで，適用しているパッチが異なる実行環境

16.8.3　構築済み実行環境を切り替える場合の注意

ここでは，構築済み実行環境を切り替える場合の注意事項について説明します。

退避機能および回復機能を実行する場合，次に示すファイルは，退避および回復されません

ユーザ任意の定義ファイル

ログファイル

プロパティの設定によって作成されるファイル

これらのファイルのうち，退避機能実行前に退避したり，回復機能実行後に回復したりする作業が必要なファイルがあります。手動で退避・回復が必要なファイルについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

CTMドメインマネジャが異常終了したあとに，構築済み実行環境の切り替えを実施すると，CTMドメインマネジャの起動時にKFCT70604-Eメッセージを出力して，起動に失敗する場合があります。CTMドメインマネジャの起動に失敗した場合は，次のどちらかを実施してください。

ctmdmstartコマンドに，-CTMAutoForceオプションまたは-CTMForceStart を指定して，CTMドメインマネージャを起動してください。

CTMSPOOL環境変数で指定したディレクトリ以下を削除してから，CTMドメインマネージャを起動してください。

17.　システムの日常運用

この章では，Cosminexusシステムで提供する，システムの日常運用を支援する機能について説明します。

システムの日常運用を支援する機能には，システムの起動・停止，運用監視，障害検知，性能解析など，システム運用に必要な機能およびサポート機能があります。

＜この章の構成＞

17.1　システムの日常運用の概要

17.2　J2EEサーバまたはバッチサーバの運用とシステムの運用管理者（UNIXの場合）

17.3　システムの起動と停止

17.4　ステータスの監視

17.5　稼働情報の監視（稼働情報収集機能）

17.6　稼働情報の監視（運用管理コマンド）

17.7　リソースの枯渇監視

17.8　Managementイベントによる処理の自動実行

17.9　CTMの稼働統計情報の収集

17.10　システムの処理性能の解析

17.11　サービスユニットの構成監視

17.1　システムの日常運用の概要

Cosminexusでは，システムを日常的に運用するための機能を提供しています。

Cosminexusシステムの運用管理には，Management Serverを利用します。Management Serverを利用すると，複数のホストで構成されるサーバに対する一括操作など，運用管理機能が利用できます。Management Serverを使用したシステムの運用管理機能の仕組みについては「16.2　Management Serverで構築したシステムの概要」を参照してください。

なお，システムの日常運用を支援する機能は，アプリケーションの実行環境によって異なります。ここでは，J2EEアプリケーションの実行環境の場合とバッチアプリケーションの実行環境の場合に分けて，システムの日常運用を支援する機能を説明します。

注意

J2EEサーバとバッチサーバの識別

Management Serverでは，バッチサーバは論理J2EEサーバとして管理されます。このため，システムの日常運用をする際に，バッチサーバも「J2EEサーバ」として出力または表示されます。システム運用時に，ファイル，コマンドの実行結果，またはServer Plug-inの画面に表示される「J2EEサーバ」がバッチサーバかJ2EEサーバかは，usrconf.cfgのオプションを参照して判断してください。

batch.service.enabled=trueになっている場合
バッチサーバとして構築されたサーバです。

batch.service.enabled=falseになっている場合
J2EEサーバとして構築されたサーバです。

なお，usrconf.cfgのbatch.service.enabledキーの値は変更しないでください。

＜この節の構成＞

17.1.1　J2EEアプリケーションの実行環境の日常運用

17.1.2　バッチアプリケーションの実行環境の日常運用

17.1.1　J2EEアプリケーションの実行環境の日常運用

J2EEアプリケーションの実行環境の日常運用を支援する機能について説明します。また，Management Serverで利用できる運用管理機能，およびManagement Serverの運用管理ドメインで管理できる論理サーバについても説明します。

＜この項の構成＞

(1)　日常運用を支援する機能

(2)　利用できる運用管理機能

(3)　運用管理ドメインで管理できる論理サーバ

(1)　日常運用を支援する機能

Cosminexusで提供している日常運用を支援する機能の概要を表に示します。

表17-1　日常運用を支援する機能の一覧（J2EEアプリケーションの実行環境の場合）

機能 | 概要 | 参照個所
システムの起動・停止 | システムを起動・停止します。 | 17.3.1
障害発生時の自動再起動 | 障害が発生して停止した論理サーバを自動再起動します。 | 17.3.3
ステータスの監視 | Webシステム内のサービスユニットのステータスを監視します。 | 17.4.1
J2EEアプリケーションや論理サーバのステータスを監視します。 | 17.4.2
稼働情報の監視（稼働情報の収集機能） | J2EEサーバの稼働状態を監視し，稼働情報を出力します。 | 17.5
稼働情報の監視（運用管理コマンド） | 論理サーバの稼働状態を監視し，稼働情報を出力します。 | 17.6
リソースの枯渇監視 | J2EEサーバおよびSFOサーバのリソースの使用状況を監視します。 | 17.7
Managementイベントによる処理の自動実行 | Managementイベントによって，障害やリソース枯渇などの事象をManagement Serverに通知します。また，Managementイベント発生時に自動的にManagementアクションを実行できます。 | 17.8
CTMの稼働統計情報の収集 | リクエストを処理する過程で出力される稼働統計情報を取得し，CTMの処理性能の解析に利用できます。 | 17.9
システムの性能解析 | リクエストを処理する過程で出力される性能解析トレースを取得し，Cosminexusシステムの処理性能の解析に利用できます。 | 17.10
構成監視 | Webシステム内のサービスユニットの構成を確認できます。 | 17.11

(2)　利用できる運用管理機能

システムの運用時にはSmart Composer機能のコマンドに加えて，Management Serverの運用管理コマンド（mngsvrutil）も使用します。

利用できる運用管理機能と実行方法を次の表に示します。

表17-2　利用できる運用管理機能と実行方法（J2EEアプリケーションの実行環境の場合）

運用管理機能
実行方法
備考

Smart Composer機能のコマンド
運用管理コマンド

サービスユニットの起動と停止
○
×
－

ステータス監視
○
○

Smart Composer機能のコマンドは，Webシステム内のサービスユニットのステータスを監視するときに使用します。

運用管理コマンドは，それぞれのJ2EEアプリケーションや論理サーバのステータスを監視するときに使用します。

性能解析トレースファイルの収集
×
○
－

CTMの稼働統計情報の収集
×
○
－

稼働情報のファイルへの出力（CSV形式またはSNMP連携用形式ファイル）
×
○
－

運用管理エージェントの稼働状況の確認
×
○
－

Management Serverの稼働状況の確認
×
○
－

（凡例）　○：実行できる　×：実行できない　－：該当なし

(3)　運用管理ドメインで管理できる論理サーバ

J2EEアプリケーション実行環境の場合に，運用管理ドメインで管理できる論理サーバの種類を説明します。

論理J2EEサーバ
J2EEサーバの機能を提供する論理サーバです。

論理パフォーマンストレーサ
パフォーマンストレーサを使用する場合に必要な論理サーバです。パフォーマンストレーサは，Cosminexusシステムの各機能レイヤが出力するトレース情報を取得して，ファイルに出力するエンジンになるプログラムです。各機能レイヤとトレース情報収集の概要については，「17.10　システムの処理性能の解析」を参照してください。

論理スマートエージェント
CTMを使用する場合に必要な論理サーバです。Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスを提供します。

論理CTMドメインマネジャ
CTMを使用する場合に必要な論理サーバです。CTMドメインを管理するプログラムを提供します。なお，CTMドメインとは，複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲のことです。

論理CTM
CTMを使用する場合に必要な論理サーバです。クライアントからのリクエストを処理してリクエストをスケジューリングするプロセスとして，CTMデーモンとグローバルCORBAネーミングサービスを提供します。

論理SFOサーバ
セッションフェイルオーバ機能を使用する場合に必要な論理サーバです。J2EEサーバ間のセッション情報を管理します。

論理Webサーバ
Webサーバと連携する場合に必要な論理サーバです。Management Serverでは，WebサーバとしてHitachi Web Serverを使用します。

論理ユーザサーバ
ユーザが任意で定義したサービスやプロセスをManagement Serverで管理する場合に必要な論理サーバです。ユーザ定義のサービスやプロセスを論理ユーザサーバとして定義することで，サービスやプロセスがManagement Serverの管理対象となります。これによって，起動，停止，およびステータス監視ができるようになります。

また，Smart Composer機能では，複数の論理サーバを，サービスユニットという単位で扱います。サービスユニットについては，「16.3　Smart Composer機能を使用したシステム構築の特長」を参照してください。

17.1.2　バッチアプリケーションの実行環境の日常運用

バッチアプリケーションの実行環境の日常運用を支援する機能について説明します。また，Management Serverで利用できる運用管理機能，およびManagement Serverの運用管理ドメインで管理できる論理サーバについても説明します。

＜この項の構成＞

(1)　日常運用を支援する機能

(2)　利用できる運用管理機能

(3)　運用管理ドメインで管理できる論理サーバ

(1)　日常運用を支援する機能

Cosminexusで提供している日常運用を支援する機能の概要を表に示します。

表17-3　日常運用を支援する機能の一覧（バッチアプリケーションの実行環境の場合）

機能 | 概要 | 参照個所
システムの起動・停止 | システムを起動・停止します。 | 17.3.1
障害発生時の自動再起動 | 障害が発生して停止した論理サーバを自動再起動します。 | 17.3.3
ステータスの監視 | Webシステム内のサービスユニットのステータスを監視します。 | 17.4.1
論理サーバのステータスを監視します。 | 17.4.2
稼働情報の監視（稼働情報の収集機能） | バッチサーバの稼働状態を監視し，稼働情報を出力します。 | 17.5
稼働情報の監視（運用管理コマンド） | 論理サーバの稼働状態を監視し，稼働情報を出力します。 | 17.6
リソースの枯渇監視 | バッチサーバのリソースの使用状況を監視します。 | 17.7
Managementイベントによる処理の自動実行 | Managementイベントによって，障害やリソース枯渇などの事象をManagement Serverに通知します。また，Managementイベント発生時に自動的にManagementアクションを実行できます。 | 17.8
システムの性能解析 | リクエストを処理する過程で出力される性能解析トレースを取得し，Cosminexusシステムの処理性能の解析に利用できます。 | 17.10
構成監視 | Webシステム内のサービスユニットの構成を確認できます。 | 17.11

(2)　利用できる運用管理機能

システムの運用時にはSmart Composer機能のコマンドに加えて，Management Serverの運用管理コマンド（mngsvrutil）も使用します。

利用できる運用管理機能と実行方法を次の表に示します。

表17-4　利用できる運用管理機能と実行方法（バッチアプリケーションの実行環境の場合）

運用管理機能
実行方法
備考

Smart Composer機能のコマンド
運用管理コマンド

サービスユニットの起動と停止
○
×
－

ステータス監視
○
○

Smart Composer機能のコマンドは，Webシステム内のサービスユニットのステータスを監視するときに使用します。

運用管理コマンドは，それぞれの論理サーバのステータスを監視するときに使用します。

性能解析トレースファイルの収集
×
○
－

稼働情報のファイルへの出力（CSV形式またはSNMP連携用形式ファイル）
×
○
－

運用管理エージェントの稼働状況の確認
×
○
－

Management Serverの稼働状況の確認
×
○
－

（凡例）　○：実行できる　×：実行できない　－：該当なし

(3)　運用管理ドメインで管理できる論理サーバ

バッチアプリケーション実行環境の場合に，運用管理ドメインで管理できる論理サーバの種類を説明します。

論理J2EEサーバ
バッチサーバの機能を提供する論理サーバです。

論理パフォーマンストレーサ
パフォーマンストレーサを使用する場合に必要な論理サーバです。パフォーマンストレーサは，Cosminexusシステムの各機能レイヤが出力するトレース情報を取得して，ファイルに出力するエンジンになるプログラムです。各機能レイヤとトレース情報収集の概要については，「17.10　システムの処理性能の解析」を参照してください。

また，Smart Composer機能では，複数の論理サーバを，サービスユニットという単位で扱います。サービスユニットについては，「16.3　Smart Composer機能を使用したシステム構築の特長」を参照してください。

17.2　J2EEサーバまたはバッチサーバの運用とシステムの運用管理者（UNIXの場合）

UNIXの場合，J2EEサーバやバッチサーバのセットアップ，起動・停止などはスーパーユーザで実施しますが，スーパーユーザ以外の一般ユーザでも権限を与えることでこれらの操作ができるようになります。このユーザをComponent Container管理者といいます。Component Container管理者を設定することで，スーパーユーザ以外のユーザを運用管理者にできます。

Component Container管理者の設定は，Cosminexusの構成ソフトウェアであるCosminexus Component Containerをインストールしたあとに実施します。なお，Component Container管理者の設定後，Component Container管理者ができる操作は，一部の操作を除き，スーパーユーザでは操作できなくなるので注意してください。

Component Container管理者を設定した場合に，スーパーユーザおよびComponent Container管理者が実施できる操作について，次の表に示します。

表17-5　スーパーユーザおよびComponent Container管理者が実施できる操作

操作
スーパーユーザ
Component Container管理者

Cosminexus Component Containerのインストール
○
×

Component Container管理者のセットアップ（cjenvsetupコマンド）
○
×

作業ディレクトリおよびユーザ定義ファイルの移行（cjenvupdateコマンド）
×
○

J2EEサーバまたはバッチサーバのセットアップ／アンセットアップ（cjsetupコマンド）
×
○

リダイレクタの設定
×
○

J2EEサーバまたはバッチサーバの起動／停止
（cjstartsvコマンド，cjstopsvコマンド）
×
○

サーバ管理コマンドの実行
○
○

スレッドダンプの取得（cjdumpsvコマンド）
○
○

OS状態情報の取得（cjgetsysinfoコマンド）
○
○

バッチ実行コマンド（cjexecjobコマンド）※
○
○

バッチ強制停止コマンド（cjkilljobコマンド）※
○
○

（凡例）　○：できる　　×：できない

注※　バッチアプリケーションの場合に使用できるコマンドです。

参考

Component Container管理者を設定しない場合は，スーパーユーザが運用管理者となるため，表中のComponent Container管理者の操作はスーパーユーザが実施します。

17.3　システムの起動と停止

ここでは，日常運用で行うシステムの起動・停止，および障害発生時の自動再起動について説明します。

＜この節の構成＞

17.3.1　日常運用での起動と停止

17.3.2　論理サーバの起動・停止と稼働確認

17.3.3　障害発生時の自動再起動

17.3.1　日常運用での起動と停止

Smart Composer機能のコマンドを使用すると，論理サーバをサービスユニット単位で，またはすべてのサービスユニットを一括で起動・停止できます。また，Webシステム内のすべてのサービスユニットを一括で起動・停止することもできます。

参考

アプリケーションの開発環境で，テスト・デバッグを実施する場合などには，Server Plug-inでJ2EEサーバの起動・停止ができます。

Smart Composer機能では，運用管理にManagement Serverを使用するため，次の流れでシステムを起動します。停止の場合は，起動と逆の流れになります。論理サーバの起動と停止の仕組みについては，「17.3.2　論理サーバの起動・停止と稼働確認」を参照してください。

運用管理エージェントの起動

Management Serverの起動

サービスユニットの準備状態での起動（Smart Composer機能のコマンド）

リソースアダプタの開始（サーバ管理コマンド）

J2EEアプリケーションの開始（サーバ管理コマンド）

サービスユニットの稼働状態での起動（Smart Composer機能のコマンド）

システムの起動と停止の詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

17.3.2　論理サーバの起動・停止と稼働確認

Management Serverを利用して論理サーバを起動・停止，および稼働確認を行います。

＜この項の構成＞

(1)　論理サーバの起動と稼働確認

(2)　論理サーバの停止

(1)　論理サーバの起動と稼働確認

論理サーバの起動と稼働確認について次の図に示します。

図17-1　論理サーバの起動と稼働確認

Management Serverは運用管理エージェントに論理サーバの起動要求を出します。

運用管理エージェントは，論理サーバの起動コマンドを実行して，要求された論理サーバを起動します。

運用管理エージェントで論理サーバプロセスのプロセスIDを取得します。

運用管理エージェントは，Management Serverに論理サーバの起動完了を通知します。

運用管理エージェントは，論理サーバのプロセス監視および動作確認を実施します。
論理サーバプロセスのプロセスIDを使用してプロセスがあるかどうかを確認し，プロセスの存在が確認できると，論理サーバの動作確認を実施します。

運用管理エージェントは，論理サーバのステータスをManagement Serverに通知します。

論理サーバの種類ごとのプロセス確認および動作確認の内容を，次の表に示します。なお，表中の動作確認の項目がない論理サーバについては，プロセスの存在確認だけが実施されます。

表17-6　論理サーバの稼働確認方法

論理サーバの種類
プロセスの起動方法※
論理サーバの稼働確認方法

プロセス存在確認
動作確認

論理パフォーマンストレーサ
間接起動
パフォーマンストレーサの提供コマンドで取得したプロセスIDの存在を確認する。
－

論理スマートエージェント
直接起動
起動コマンドのプロセスIDの存在を確認する。
－

論理ネーミングサービス
直接起動
起動コマンドのプロセスIDの存在を確認する。
ルートコンテキストを取得できることを確認する。

論理CTMドメインマネジャ
間接起動
CTMドメインマネジャの提供コマンドで取得したプロセスIDの存在を確認する。
－

論理CTM
ネーミングサービス
直接起動
起動コマンドのプロセスIDの存在を確認する。
－

CTMデーモン
間接起動
CTMデーモンの提供コマンドで取得したプロセスIDの存在を確認する。
－

論理SFOサーバ
直接起動
起動コマンドのプロセスIDの存在を確認する。

メトリックが取得できることを確認する。

SFOアプリケーションが開始されていることを確認する。

論理J2EEサーバ
直接起動
起動コマンドのプロセスIDの存在を確認する。
IIOPでの呼び出しに応答することを確認する。

論理Webサーバ
間接起動
Webサーバが生成するhttpd.pidファイルから取得した制御プロセスとWebサーバのサーバプロセスのプロセスIDの存在を確認する。
Webサーバ動作確認用URLに対してHTTPアクセスで正しいレスポンスが受信できるかどうかを確認する。応答はWebサーバのサーバプロセスが行う。

論理ユーザサーバ
直接起動
論理ユーザサーバ定義ファイルにgetProcessIDコマンドが定義されている場合は，getProcessIDコマンドで取得したプロセスIDの存在を確認する。定義されていない場合は，起動コマンドのプロセスIDの存在を確認する。
論理ユーザサーバ定義ファイルにisAliveコマンドが定義されている場合は，isAliveコマンドを使用してプロセスが稼働しているかを確認する。定義されていない場合は，動作確認は成功したものとみなす。

間接起動
getProcessIDコマンドで取得したプロセスIDの存在を確認する。
論理ユーザサーバ定義ファイルにisAliveコマンドが定義されている場合は，isAliveコマンドを使用する。定義されていない場合は，動作確認は成功したものとみなす。

（凡例）　－：なし

注※　直接起動では，実行したコマンドそのものが監視対象となります。間接起動では，コマンドが起動したサービスやプロセスが監視対象となります。コマンドを実行して監視対象のサービスやプロセスが起動されると，コマンドは終了します。

(2)　論理サーバの停止

論理サーバの停止について次の図に示します。

図17-2　論理サーバの停止

Management Serverは運用管理エージェントに論理サーバの停止要求を出します。

運用管理エージェントは，論理サーバの停止コマンドを実行して，要求された論理サーバを停止します。

運用管理エージェントは，Management Serverに論理サーバの停止完了を通知します。

17.3.3　障害発生時の自動再起動

Management Serverを使用して，障害が発生して停止した論理サーバを自動再起動できます。

自動再起動は，Management Serverによって正しく起動された論理サーバから，起動後の状態として「障害」が検出された場合に実行されます。「障害」とは，停止要求を受け付けていないのに論理サーバが停止したことが検出された状態です。

運用管理エージェントでは，論理サーバに対してプロセス監視および動作確認をしています。プロセスのダウン，およびハングアップといった論理サーバの障害を検出すると，運用管理エージェントは異常を検知し，Management Serverに通知します。Management Serverは，障害検知時コマンドおよびsnapshotログ収集を実行してトラブルシューティング用の資料を収集したあとで，論理サーバを自動再起動します。

ユーザからの起動要求に対する起動処理の途中で障害が発生した場合は，自動再起動をしないでユーザに起動の失敗が通知されます。

自動再起動は，システムの構築時に設定した，自動再起動回数および自動再起動リトライ間隔に従って実行されます。

なお，自動再起動回数として「0回」を設定している場合，自動再起動は実行されません。

障害発生時の自動再起動の流れと論理サーバのステータスについて次の図に示します。

図17-3　障害発生時の自動再起動

なお，前提となる論理サーバで自動再起動をした場合には，前提となる論理サーバの自動再起動の完了後に，該当する論理サーバを前提として設定している論理サーバも再起動されます。

ポイント

障害検出について

論理サーバの稼働状態の確認は，運用管理エージェントでの論理サーバのプロセス監視および動作確認で実施しています。例えば，プロセス監視では，論理サーバプロセスのプロセスIDが存在するかどうかを確認します。プロセスIDが存在しない場合は，運用管理エージェントはプロセスダウンを検知し，Management Serverに異常を通知します。

なお，プロセス監視および動作確認の内容は，論理サーバの種類によって異なります。詳細については，「17.3.2　論理サーバの起動・停止と稼働確認」を参照してください。

17.4　ステータスの監視

Cosminexusでは，ステータス監視によって，システムが正常に稼働しているかどうかを監視できます。ステータス監視には次の2種類があります。

サービスユニットのステータス監視
サービスユニットのステータスを監視できます。

論理サーバのステータス監視
論理サーバのステータスを監視できます。

参考

サーバ管理コマンドを使用して，サーバ上で動作するアプリケーションのステータス監視，および稼働中のJ2EEサーバやバッチサーバのトランザクション情報の表示などができます。

＜この節の構成＞

17.4.1　サービスユニットのステータス監視

17.4.2　論理サーバのステータス監視

17.4.1　サービスユニットのステータス監視

Smart Composer機能のコマンドを使用してサービスユニットの稼働状態（ステータス）を監視できます。サービスユニットのステータス監視では，特定のユニット，またはWebシステム中のすべてのユニットの稼働状態をCSV形式にファイル出力できます。

なお，Smart Composer機能のコマンドの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

17.4.2　論理サーバのステータス監視

論理サーバのステータス監視では，運用管理コマンド（mngsvrutil）を使用して論理サーバの稼働状態（ステータス）を監視できます。ステータス情報は標準出力に出力したり，CSV形式またはSNMP連携様式にファイル出力したりできます。

17.5　稼働情報の監視（稼働情報収集機能）

稼働情報の収集機能では，J2EEサーバやバッチサーバの稼働状態を定期的に監視して，サーバ性能やリソースの情報などの稼働情報を取得できます。稼働情報は，J2EEサーバやバッチサーバの稼働状態を確認したり，稼働実績を統計情報として参照したり，J2EEサーバやバッチサーバの設定パラメタをチューニングしたりするのに利用できます。

稼働情報を監視することで，次の機能を使用できます。

稼働情報ファイルの出力
取得した稼働情報を稼働情報ファイルとして出力できます。

イベントの発行
監視対象にしきい値を設定し，監視対象がしきい値を超えた時にイベントを発行できます。

稼働情報ファイルの取得とイベント発行の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ポイント

稼働情報を監視する方法には，運用管理コマンドを使用した方法もあります。稼働情報の監視を行う場合，通常の運用では，ここで説明している稼働情報ファイルを使用して稼働情報を監視してください。稼働情報ファイルで取得できる情報よりも，詳細な情報を取得したい場合には，運用管理コマンドを使用して稼働情報を監視してください。運用管理コマンドを使用した稼働情報の監視については，「17.6　稼働情報の監視（運用管理コマンド）」を参照してください。

＜この節の構成＞

17.5.1　稼働情報ファイルの出力

17.5.2　イベントの発行

17.5.1　稼働情報ファイルの出力

稼働情報ファイルの出力機能では，J2EEサーバやバッチサーバの各機能単位で出力される稼働情報を指定された稼働情報収集間隔ごとに収集し，テキストファイルに出力します。

稼働情報を出力する機能を次の図に示します。

図17-4　稼働情報の種類と稼働情報を出力するJ2EEサーバの機能

稼働情報を出力する機能を次に示します。なお，各機能の番号は，図中の数字と対応しています。

JavaVM

プロセスリソース

Stateful Session Bean※

Stateless Session Bean※

Message-driven Bean※

DB Connector

JCAリソース

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

Webアプリケーション※

Webコンテナ※

URLグループ※
注※　バッチサーバの場合は該当しません。

出力される稼働情報を次の表に示します。

表17-7　出力される稼働情報

稼働情報 | 稼働情報を出力する機能単位
分類 | 種別 | 情報
サーバ性能 | 実行結果情報 | 受け付けリクエスト数※ | Webアプリケーション
URLグループ
応答済みリクエスト数※ | Webアプリケーション
URLグループ
セッション数※ | Webアプリケーション
実行待ちリクエスト数の上限からあふれたリクエスト数※ | Webコンテナ
Webアプリケーション
URLグループ
受け付けメッセージ数※ | Message-driven Bean
決着済みトランザクション数 | トランザクションサービス
トランザクションロールバック数 | トランザクションサービス
コネクション取得失敗数 | JCAリソース
プールされたPreparedStatement数 | DBConnector
プールされたCallableStatement数 | DBConnector
PrepareStatementメソッドが呼び出された回数 | DBConnector
PrepareCallメソッドが呼び出された回数 | DBConnector
プール内PreparedStatementヒット回数 | DBConnector
プール内CallableStatementヒット回数 | DBConnector
サーバリソース | 流量制御リソース情報 | 同時実行スレッド数※ | Webコンテナ
Webアプリケーション
URLグループ
実行待ちリクエスト数※ | Webコンテナ
Webアプリケーション
URLグループ
プールされたインスタンス数※ | Stateless Session Bean
プール内の使用中インスタンス数※ | Stateless Session Bean
実行待ちリクエスト数※ | Stateless Session Bean
接続セッション数※ | Stateful Session Bean
プールされたインスタンス数※ | Message-driven Bean
プール内の使用中インスタンス数※ | Message-driven Bean
プールされたコネクション数 | JCAリソース
プール内の使用中コネクション数 | JCAリソース
コネクション取得待ちスレッド数 | JCAリソース
OSリソース情報 | JavaVMヒープサイズ | JavaVM
コピーガーベージコレクション回数 | JavaVM
フルガーベージコレクション回数 | JavaVM
ロードされているクラス数 | JavaVM
JavaVMの稼働中のスレッド数 | JavaVM
モニタロックのためにブロック状態であるスレッド数 | JavaVM
スレッド数 | プロセスリソース
ファイルディスクリプタ数 | プロセスリソース

注※　バッチサーバの場合は該当しません。

17.5.2　イベントの発行

イベントの発行機能は，稼働情報の監視対象が，設定したしきい値を超えた時に，イベントを発行する機能です。イベントが発行されることで，稼働状態の異常を検知できます。

なお，イベント発行時にはメッセージが出力されます。このメッセージを利用してManagementイベントを発行できます。Managementイベントの詳細については，「17.8　Managementイベントによる処理の自動実行」を参照してください。

＜この項の構成＞

(1)　しきい値を設定できる監視対象

(2)　イベントの発行方法

(1)　しきい値を設定できる監視対象

しきい値を設定できる稼働情報の監視対象は次の二つです。

フルガーベージコレクション回数
フルガーベージコレクションの回数を監視します。フルガーベージコレクションが頻発する異常状態を検知できます。しきい値には，フルガーベージコレクションの回数を設定します。
J2EEアプリケーションの実行環境およびバッチアプリケーションの実行環境で監視できます。

URLグループ単位の実行待ちリクエスト数
URLグループ単位の実行待ちリクエストキューにあるリクエスト数を監視します。実行待ちリクエスト数がリクエストキューサイズを超える前に，リクエストキューの空きが少なくなったことを検知できます。しきい値には，実行待ちリクエストキューサイズに対する実行待ちリクエスト数の割合を設定します。
J2EEアプリケーションの実行環境で監視できます。

(2)　イベントの発行方法

イベントの発行方法は，しきい値を設定する監視対象によって，回数型と増減型の2種類があります。フルガーベージコレクション回数の監視は回数型，URLグループ単位の実行待ちリクエスト数の監視は増減型です。

(a)　フルガーベージコレクション回数の場合（回数型）

設定した監視時間（しきい値監視間隔）単位で発生したフルガーベージコレクション回数をカウントし，しきい値に達した場合にイベントを発行します。

フルガーベージコレクション回数の場合の，しきい値のイベント発行について次の図に示します。

図17-5　しきい値のイベント発行（フルガーベージコレクション回数の場合）

この図の場合，フルガーベージコレクション回数のしきい値が10，しきい値監視間隔が5分です。稼働情報の監視を開始した時点からしきい値監視間隔ごとにフルガーベージコレクションの回数をカウントし，一回のしきい値監視間隔でフルガーベージコレクションが10回を超えるとイベントを発行します。

(b)　URLグループ単位の実行待ちリクエスト数の場合（増減型）

上限しきい値および下限しきい値を設定し，URLグループ単位の実行待ちリクエスト数が，それぞれのしきい値に達した時にイベントを発行します。上限しきい値のイベント，および下限しきい値のイベントは次のタイミングで発行されます。なお，上限しきい値は下限しきい値より大きく設定する必要があります。

URLグループ単位の実行待ちリクエスト数が上限しきい値（警告域）に達した時に，上限しきい値のイベントが発行されます。

上限しきい値のイベントが発行されたあと，URLグループ単位の実行待ちリクエスト数が下限しきい値以下になった時に，正常域に戻ったことを示す下限しきい値のイベントが発行されます。

上限しきい値のイベントが発行されてから，URLグループ単位の実行待ちリクエスト数がいったん下限しきい値以下になってから再度上限しきい値に達した時に，上限しきい値のイベントが発行されます。上限しきい値のイベントが発行されたあと，下限しきい値に達しないで，再度上限しきい値に達した場合は，上限しきい値のイベントは発行されません。

下限しきい値のイベントが発行されてから，URLグループ単位の実行待ちリクエスト数がいったん上限しきい値以上になってから再度下限しきい値に達した時に，下限しきい値のイベントが発行されます。下限しきい値のイベントが発行されたあと，上限しきい値に達しないで，再度下限しきい値に達した場合は，下限しきい値のイベントは発行されません。

URLグループ単位の実行待ちリクエスト数の場合の，しきい値のイベント発行について次の図に示します。

図17-6　しきい値のイベント発行（URLグループ単位の実行待ちリクエスト数の場合）

この図の場合，正常域から上限しきい値に達した時に，上限しきい値のイベントが発行されます。その後，上限しきい値以下になってから，再度上限しきい値に達しますが，この時には上限しきい値のイベントは発行されません。これ以降，下限しきい値に達した時に下限しきい値のイベントが，上限しきい値に達した時に上限しきい値のイベントが発行されます。

17.6　稼働情報の監視（運用管理コマンド）

Management Serverの運用管理コマンド（mngsvrutil）を使用して稼働情報を監視できます。運用管理コマンドによる稼働情報の監視では，Management Serverを使用して運用管理ドメイン内の論理サーバを監視します。稼働情報は，運用管理ドメイン単位で，ファイルに出力して確認できます。ファイルの形式は，CSV形式またはSNMP連携用形式です。

SNMP連携用形式のファイルは，SNMP Manager製品と連携する場合に使用できます。これらの製品で使用する場合は，SNMP連携用形式のファイルを，JP1/Cm2/ESA for Extension Mib Runtime※などを使用してMIBオブジェクトに変換して使用します。

注※

JP1/Cm2/ESA for Extension Mib Runtimeは，Windowsの場合に使用します。

UNIXの場合，JP1/Cm2/ESAとなります。

稼働情報のファイルへの出力の流れを次の図に示します。なお，稼働情報をMIBオブジェクトに変換する場合は，Cosminexusで提供する拡張MIBオブジェクト定義ファイルを使用します。

図17-7　稼働情報のファイルへの出力の流れ

参考

なお，運用管理エージェントおよびManagement Serverの稼働状況については，運用管理コマンドまたはadminagentcheckコマンドを使用して確認できます。

17.7　リソースの枯渇監視

Cosminexusでは，リソースの使用状態を監視できます。これを，リソース枯渇監視機能といいます。この機能は，Managementイベントと組み合わせて利用することもできます。

＜この節の構成＞

17.7.1　リソース枯渇監視機能の概要

17.7.2　監視できるリソースの種類

17.7.1　リソース枯渇監視機能の概要

リソース枯渇監視機能で監視できるリソースは全部で7種類あります。すべてのリソースを監視することもできますが，監視するリソースを選択することもできます。リソース枯渇監視機能では，監視するリソースや，各リソースのしきい値などを設定します。なお，リソース枯渇監視で対象となるのは，J2EEサーバ，SFOサーバ，またはバッチサーバのリソースです。

J2EEサーバ，SFOサーバ，またはバッチサーバのリソース枯渇を監視する設定にしている場合，監視対象のリソースについての情報が，一定間隔でファイルに出力されます。この情報をリソース枯渇監視情報といいます。リソース枯渇監視情報は，監視するリソースの種類ごとに出力するかどうかを選択できます。なお，リソース枯渇監視情報を出力したファイルを，リソース枯渇監視ログファイルといいます。

リソース枯渇監視情報を利用すると，リソースの使用率または使用数の変化のしかたを確認できます。また，この情報は，リソースの使用率または使用数がしきい値を超えた場合に，その原因を調査するためにも使用できます。

リソースの使用率または使用数が設定したしきい値を超えた場合，アラートが発生します。Management Serverを使用している場合，アラートが発生すると，メッセージを出力し，Management Serverに対してイベントを通知できます。このイベントを，Managementイベントといいます。また，Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。このアクションを，Managementアクションといいます。リソース枯渇監視機能とManagementイベントを組み合わせて使用することによって，リソースを効率良く確実に監視できます。ManagementイベントとManagementアクションの詳細については，「17.8　Managementイベントによる処理の自動実行」を参照してください。

Managementイベントによる処理の自動実行の設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

17.7.2　監視できるリソースの種類

リソース枯渇監視機能では，7種類のリソースを監視できます。7種類すべてのリソースを監視することも，必要なリソースだけ監視することもできます。ただし，使用しているOSによっては，監視できないリソースがあります。また，バッチサーバの場合，HTTPリクエスト実行待ちキュー監視およびセッション数監視はできません。

各リソースの詳細について次に説明します。

メモリ監視
メモリ監視では，JavaVMでのヒープ・メモリ領域を監視します。メモリの使用状況を監視することで，フルガーベージコレクションの予兆を検知できるので，監視結果をヒープサイズおよびメモリサイズのチューニングに利用できます。

ポイント

この機能で監視しているメモリ使用率が100%に近づいた場合に必ずフルガーベージコレクションが発生するわけではありません。監視した値は，フルガーベージコレクションが発生する可能性が高いという予兆を検知するために使用されます。

ファイルディスクリプタ監視
ファイルディスクリプタ監視では，サーバのプロセス内で開いているファイルディスクリプタを監視します。ファイルディスクリプタの数を監視することで，システムに割り当てられている，サーバのプロセスで使用できるファイルディスクリプタの枯渇を検知したり，見積もりで求めたファイルディスクリプタの数に到達する前に検知したりできます。
なお，ファイルディスクリプタ監視は，Windowsの場合，およびAIXの場合は使用できません。

スレッド監視
スレッド監視では，サーバのプロセス内で生成するスレッド数を監視します。生成されたスレッド数を監視することで，システムに割り当てられている，サーバのプロセス内で生成できるスレッド数を超えたり，見積もりで求めたスレッド数に到達する前に検知したりできます。
なお，スレッド監視は，Linuxの場合は使用できません。

スレッドダンプ監視
スレッドダンプ監視では，cjdumpsvコマンドやJ2EEアプリケーション実行時間の監視で出力されたスレッドダンプのファイル数を，サーバ単位で監視します。スレッドダンプのファイル数を監視することで，ファイル数が上限に達する前に検知できます。
J2EEアプリケーション実行時間の監視については，「19.3　J2EEアプリケーション実行時間の監視とキャンセル」を参照してください。

HTTPリクエスト実行待ちキュー監視
HTTPリクエスト実行待ちキュー監視では，Webアプリケーション単位の同時実行スレッド数の制御で実行待ちキューにあるリクエストの数を監視します。監視する実行待ちキューは，Webアプリケーションごとの実行待ちキューと，デフォルトの実行待ちキューです。監視は，J2EEサーバ単位，またはWebアプリケーション単位でできます。HTTPリクエストの実行待ちキューを監視することで，リクエストが実行待ちキューからあふれる前の状態を検知できます。
ただし，実行待ちキューサイズに「0」が指定されている場合は監視しません。
なお，実行待ちキューサイズが動的に変更された場合でも，しきい値は最初に設定した値から変更されることはありません。
同時実行スレッド数については，「4.17　同時実行スレッド数の制御」を参照してください。

セッション数監視
セッション数監視では，Webアプリケーション上で生成されるセッション数を監視します。セッション数を監視することで，セッション数の増加を検知できます。
ただし，セッション数の設定で作成できるセッション数に「0」が指定されている場合は，監視しません。

コネクションプール監視
コネクションプール監視では，コネクションプールの使用状態を監視します。コネクションプールの使用状態を監視することで，コネクションの枯渇を事前に検知できるので，コネクションプールのチューニングに利用できます。
ただし，コネクションプールが無効となっている場合は，監視できません。また，コネクションプールの最大値が無制限の場合は，監視はしますが，Managementイベントは通知されません。
コネクションプールについては，「9.10.1　コネクションプーリング」を参照してください。

17.8　Managementイベントによる処理の自動実行

この節では，Managementイベントによる処理の自動実行について説明します。

＜この節の構成＞

17.8.1　Managementイベントの通知とManagementアクション

17.8.2　Managementアクションの実行制御

17.8.1　Managementイベントの通知とManagementアクション

Managementイベントとは，運用管理ドメイン内のJ2EEサーバ，SFOサーバ，またはバッチサーバで発生する障害やリソース枯渇などの事象をManagement Serverに通知するためのイベントです。J2EEサーバ，SFOサーバ，またはバッチサーバが稼働中に出力するメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。このアクションをManagementアクションといいます。

注意

J2EEサーバおよびSFOサーバが出力するメッセージのうち，次に示すメッセージはManagementイベントの発行対象外となります。

KDJE90001-E

KDJE90002-E

KDJE90003-E

KDJE90005-W

KDJE90006-W

KDJE90009-W

メッセージの詳細については，マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」を参照してください。

Managementイベントが発行されてから，Management ServerでManagementアクションが実行されるまでの流れを次の図に示します。

図17-8　ManagementイベントとManagementアクション

この例では，リソース枯渇監視機能で設定したしきい値を超えた場合に出力されるメッセージを契機に，Managementイベントを実行しています。図中の処理の流れについて説明します。

監視しているリソースで設定しているしきい値を超えると，Managementイベントが発行されます。

Mnagementイベントは，Management Serverに通知されます。

Management Server内で定義されたManagementアクションの定義に従って，処理が自動的に実行されます。
Managementアクションの定義では，J2EEサーバから挙がるManagementイベントに対応したアクションを定義します。Managementアクションはあらかじめ定義しておく必要があります。

なお，リソース枯渇監視機能を使用してメモリ監視をしている場合，フルガーベージコレクションの予兆検知ができます。メモリ監視中に，フルガーベージコレクションの予兆を検知すると，その情報はManagementイベントとしてManagement Serverに通知されます。このとき，Managementイベントでフルガーベージコレクションが通知されたときの動作として，J2EEサーバでサービスを閉塞して再起動するアクションが定義されていると，J2EEサーバに対してこのアクションが自動的に実行されます。これによって，リクエスト処理の停止を回避できるようになります。

17.8.2　Managementアクションの実行制御

ここでは，Managementアクションの実行制御について説明します。

同一のManagementアクションの実行を一定時間抑止したり，同時実行数の上限を設定したりすることによって，Managementアクションの実行を制御できます。これによって，同一のManagementアクションが重複して実行されたり，Managementアクションの実行が集中したりすることを防ぎます。

なお，Managementアクションの実行とは，Managementアクションとして指定されたコマンドを実行してから，コマンドが終了またはタイムアウトするまでのことを指します。

Managementアクションの実行制御方式を次の表に示します。

表17-8　Managementアクションの実行制御方式

制御方式 | 説明
抑止時間制御 | Managementアクションの実行後に，同一のManagementアクションが実行されるのを一定時間抑止します。これによって，一定時間内に発生するManagementイベントに対して実行される，Managementアクションが集約されます。
同時実行数制御 | 同一のManagementアクションの同時実行数を制限します。これによって，Managementアクション実行中に，同一のManagementアクションが過度に重複して実行されることを防ぎます。同時実行数はManagementアクションIDごとに適用されます。

なお，上記二つの方式を同時に指定した場合，同時実行数の上限値に達していないときでも，抑止時間内のManagementアクションの実行は抑止されます。

Managementアクションの制御方式について例を使って説明します。

設定例1
次の内容が設定されていることとします。

Managementアクションの実行時間：5秒

抑止時間：10秒

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図17-9　Managementアクションの制御例1

この図の例では，アクション1のあと，10秒間は同一アクションの実行を抑止するため，アクション2およびアクション3の実行は抑止されます。抑止時間が過ぎたあと，アクション4が実行できるようになります。

設定例2
次の内容が設定されていることとします。

Managementアクションの実行時間：5秒

抑止時間：0秒（抑止しない）

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図17-10　Managementアクションの制御例2

この図の例では，抑止時間の制限がないため，アクション1の実行後に，アクション2が実行されます。ただし，この時点で同一Managementアクションの同時実行数の上限値に達しているため，アクション3の実行は抑止されます。アクション1の実行が終了したあと，アクション4を実行できるようになります。アクション5，6については，アクション2，3と同様になります。

設定例3
次の内容が設定されていることとします。

Managementアクションの実行時間：12秒

抑止時間：3秒

同時実行数の上限値：2

Managementアクションの制御例を次の図に示します。

図17-11　Managementアクションの制御例3

この図の例では，アクション1の実行後，3秒間は同一のManagementアクションの実行が抑止されるため，アクション2の実行は抑止されます。アクション3の実行後，同一Managementアクションの同時実行数の上限値に達したため，アクション4の実行が抑止されます。アクション1の実行終了後，アクション5を実行できようになります。

17.9　CTMの稼働統計情報の収集

CTMが提供するCTMデーモンやCTMレギュレータなどのプロセス群では，リクエストを処理する過程で稼働統計情報をバッファに出力します。

このバッファの情報は，CTM単位にホスト上のファイル（稼働統計情報ファイル）に一定間隔で出力されます。バイナリ形式の稼働統計情報ファイルから，CSV形式などのテキストファイル（稼働統計出力ファイル）に変換したファイルを使用して，CTMの処理性能を解析します。

この節では，CTMが提供するプロセス群（CTMデーモンやCTMレギュレータなど）が出力する稼働統計情報を使用した，CTMの処理性能の監視について説明します。

＜この節の構成＞

17.9.1　CTMの稼働統計情報の概要

17.9.2　稼働統計情報ファイルの利用方法

17.9.1　CTMの稼働統計情報の概要

CTMでは，CTMでリクエストを受け付けてからJ2EEサーバにリクエストを送信するまで，およびその処理結果がCTMに返却されるまでの一連の処理の過程で稼働統計情報を出力します。稼働統計情報を基に，CTMが提供するプロセス群の性能処理性能を解析したり，稼働状態を確認したりしてシステムの安定化を図ることができます。

CTMの稼働統計情報の収集の概要を次の図に示します。

図17-12　CTMの稼働統計情報の収集の概要

性能に関する処理のCTMの稼働統計情報は，CTMが提供するプロセス群によって，CTM単位に，ホスト上のファイル（稼働統計情報ファイル）に出力されます。

Management Serverを利用して運用している場合，各ホストに出力された稼働統計情報ファイルの内容は，Management Serverのコマンドによって，管理サーバに一括収集できます。なお，CTMが出力した稼働統計情報ファイルは，バイナリ形式のファイルです。Management Serverでは，運用管理エージェントに指示を出し，稼働統計情報ファイルをテキスト（CSV）形式のファイルに編集して，それを圧縮したものを収集します。なお，テキスト形式に編集した稼働統計情報ファイルを稼働統計出力ファイルといいます。

運用管理者は，収集した稼働統計出力ファイルを基に，運用管理ドメイン内のCTMに関する性能解析およびボトルネックの分析ができるようになります。

なお，Management Serverで収集できるのは，運用管理ドメイン内のホストで出力された稼働統計情報ファイルです。

17.9.2　稼働統計情報ファイルの利用方法

CTMの稼働統計情報ファイルの利用方法について説明します。

CTMの稼働統計情報ファイルには，CTMが提供する次に示すプロセス群の処理の状態，処理の開始・終了時間や，処理の回数などの情報がバイナリ形式で自動的に出力されます。

CTMデーモン

CTMレギュレータ

OTMゲートウェイ

バイナリ形式で出力された稼働統計情報ファイルは，Management Serverの運用管理コマンド（mngsvrutil）を実行して編集します。編集した情報は，CSV形式のファイル，または標準出力に出力されます。

稼働統計出力ファイルの取得方法，および稼働統計出力ファイルの出力形式については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。また，稼働統計出力ファイルの取得に使用するコマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

17.10　システムの処理性能の解析

Cosminexusシステムの各機能は，リクエストを処理する過程で，性能解析情報をバッファに出力します。このバッファの情報は，一定間隔ごとにPRFデーモンというパフォーマンストレーサのデーモンによってそれぞれのホスト上のファイル（PRFトレースファイル）に出力されます。

この節では，Cosminexusシステムの各機能が出力する性能解析情報を使用して，Cosminexusシステムの処理性能を解析する機能について説明します。この機能を，性能解析トレースといいます。

＜この節の構成＞

17.10.1　性能解析トレースの概要

17.10.2　性能解析トレースの仕組み

17.10.3　性能解析トレースの構成

17.10.4　トレース情報の利用方法

17.10.5　トレース取得ポイントとPRFトレース取得レベル

17.10.6　トレース情報の取得によるトラブルシュート

17.10.7　性能解析トレースのルートアプリケーション情報の取得のための実装

17.10.1　性能解析トレースの概要

性能解析トレースは，クライアントからデータベースなどのEISに至るまで，およびその処理結果がクライアントに返却されるまでのリクエストの一連の処理で出力されるトレース情報を基に，システムの性能を検証する機能です。システムのボトルネックを解析したり，障害が発生した場合にリクエストの処理がどこまで到達したかを調べてトラブルシュートの効率向上を図ったり，セッションやグローバルセッション情報のライフサイクルを把握したりできます。

Cosminexusシステムでは，処理性能の解析に，Cosminexus Performance Tracerという構成ソフトウェアを使用します。

性能解析トレースのトレース情報収集の概要を，次の図に示します。

図17-13　性能解析トレースのトレース情報収集の概要

WebクライアントまたはEJBクライアントからリクエストが送信された場合に，Webサーバ，J2EEサーバおよびCTMでは決まった処理のポイントでトレース情報を出力します。出力した情報は，PRFデーモンによって，トレースファイル（PRFトレースファイル）に出力されます。トレースが出力されるポイントを，トレース取得ポイントといいます。

Management Serverを利用して運用している場合，各ホストに出力されたトレースファイルの内容は，Management Serverの運用管理コマンド（mngsvrutil）で，管理サーバに一括収集できます。なお，PRFデーモンが出力したPRFトレースファイルは，バイナリ形式のファイルです。Management Serverでは，運用管理エージェントに指示を出し，PRFトレースファイルをテキスト（CSV）形式のファイルに編集して，それを圧縮したものを収集します。Management Serverで収集できるのは，運用管理ドメイン内のホストで出力されたPRFトレースです。

なお，テキスト形式に編集したトレースファイルを性能解析トレースファイルといいます。

運用管理者は，収集した性能解析トレースファイルを基に，運用管理ドメイン内全体の性能解析およびボトルネックの分析ができるようになります。

運用管理コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。また，性能解析トレースの運用については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

17.10.2　性能解析トレースの仕組み

性能解析トレースでは，システム内部のイベント単位で，複数のノードおよびプロセス間にわたるトレース情報を取得できます。これによって，一連の処理の中で，どの処理がボトルネックになっているかをトレースできます。

イベント単位でトレースを取得するために，性能解析トレースでは，イベント単位の一連の処理に一貫したキーを設定して管理します。イベント内のトレース取得ポイントで出力するトレースには，キーの情報が付加されます。これによって，一連の処理がトレースできます。

図17-14　性能解析トレースによるトレース出力の概要

なお，トレースを出力するリダイレクタ，Webコンテナなどを，機能レイヤといいます。性能解析トレースでは，次の機能レイヤで性能解析情報を出力します。アプリケーションの実行環境と該当する機能レイヤを次の表に示します。

表17-9　アプリケーションの実行環境と該当する機能レイヤ

機能レイヤ | アプリケーションの実行環境
J2EEアプリケーションの実行環境 | バッチアプリケーションの実行環境
CTM | ○ | －
リダイレクタ | ○ | －
Webコンテナ | ○ | －
EJBコンテナ | ○ | －
Timer Service | ○ | －
JNDI | ○ | ○
JTA | ○ | ○
JCAコンテナ | ○ | ○
DB Connector | ○ | ○
RMI（通信処理） | ○ | ○
OTS | ○ | ○
標準出力/標準エラー出力/ユーザログ | ○ | ○
DI | ○ | －
バッチアプリケーション実行機能 | － | ○※

（凡例）○：該当する　－：該当しない

注※　トレース情報は，バッチアプリケーションの実行直前（mainメソッドを呼ぶ直前），およびバッチアプリケーション終了直後に出力されます。cjexecjobコマンドおよびcjkilljobコマンドの実行では出力されません。

また，性能解析トレースでは，これらの機能レイヤのほかに，J2EEサーバの開始処理，終了処理，トランザクションタイムアウト発生時，およびセッションの生成／破棄でもトレースを出力します。

参考

これらの機能レイヤのほか，Application Serverの構成ソフトウェアおよび関連プログラムでも，次の機能レイヤでPRFトレースが取得できます。

Cosminexus Web Services - Base

uCosminexus TP1 Connector

TP1/Client/J

TP1/MQ Access

Cosminexus RM

HCSCサーバ

uCosminexus Service Adapter for Object Access

uCosminexus Service Coordinator Interactive Workflow

uCosminexus Service Adapter for Flat Files

トレース情報のキー情報は，次の要素で構成されています。

キー情報の構成

キー情報を取得したプロセスID

キー情報を取得したプロセスが起動しているホストのIPアドレス

PRFトレースのI／Oプロセス（PRFデーモン）単位で割り当てられる通信番号
なお，PRFデーモンが起動していない場合は，通信番号として時刻が返却されます。ただし，この場合，通信番号の一意性を保てないおそれがあるので，PRFデーモンは必ず起動してください。

PRFトレースには，次の2種類のキー情報が付与されます。

ルートアプリケーション情報
各イベントで一連の処理の先頭になるプロセスで取得した情報です。

J2EEアプリケーションの場合
リダイレクタまたはEJBクライアントで取得した情報になります。

バッチアプリケーションの場合
バッチアプリケーションの実行直前に取得した情報になります。

クライアントアプリケーション情報
J2EEアプリケーションの場合，次に示すEnterprise Beanを呼び出す処理単位で設定される情報です。

WebコンテナからEJBコンテナの呼び出し

EJBクライアントからEJBコンテナの呼び出し

EJBコンテナからEJBコンテナの呼び出し

なお，バッチアプリケーションの場合は，バッチアプリケーションの実行直前に設定される情報になります。

17.10.3　性能解析トレースの構成

性能解析トレースは，次のプログラムで構成されています。

PRFトレース出力ライブラリ
Cosminexusシステムの各機能レイヤに組み込まれています。各機能レイヤが出力したPRFトレースを，共用メモリに作成されたバッファに出力します。

PRFデーモン
バッファに出力されたPRFトレースを，一定量たまったらファイルに出力する，I／Oプロセスです。PRFトレースを取得するホストごとに，一つ以上起動します。一つのホストに一つ配置することをお勧めします。
PRFトレース出力ライブラリとPRFデーモンの関係を次の図に示します。

図17-15　PRFトレース出力ライブラリとPRFデーモンの関係

PRFトレース出力ライブラリによってトレースが出力されるバッファ領域は，PRFデーモン起動時に作成されます。バッファ領域は，共用メモリに作成されます。ただし，前回PRFデーモンを起動した時に作成したバッファ領域が残っている場合は，その領域を再利用します。バッファ領域が削除されないで残っているのは，前回起動したPRFデーモンが異常終了した場合です。

PRFデーモンが正常終了した場合，バッファ領域内のバッファデータはPRFトレースファイルに出力され，バッファ領域は削除されます。

バッファ領域が不足すると，KFCT26999-Wのメッセージが出力されて，PRFトレースが完全に出力されない場合があります。そのため，このメッセージが出力される場合は，バッファサイズのチューニングをしてください。

17.10.4　トレース情報の利用方法

性能解析トレースを使用して出力したトレース情報の利用方法について説明します。

性能解析トレースでは，次に示す各機能レイヤの入り口と出口でトレース情報が出力されます。また，必要に応じて，各機能レイヤ内の処理のうち，性能に影響を与える処理ごとに，トレース情報を出力します。

性能解析トレースによってPRFトレースファイルにバイナリ形式で出力された情報は，Management Serverの運用管理コマンド（mngsvrutil）を実行してダンプ形式またはCSV形式に編集して使用します。

例えば，CSV形式で出力すると，Excelなどのアプリケーションプログラムで「イベントごと」「プロセスごと」などによって出力項目をフィルタリングして，注目する個所を絞り込んで，目的に合わせた分析ができます。

なお，トレース情報の内容には，トレース情報を取得したプロセスID，取得ポイントを示すイベントID，トレース取得年月日やトレース情報を取得したクライアントアプリケーションのIPアドレスなどの情報が含まれます。

トレース情報の内容，および具体的な使用方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

17.10.5　トレース取得ポイントとPRFトレース取得レベル

性能解析トレースでは，次の図に示す機能レイヤのトレース取得ポイントでPRFトレースを出力します。PRFトレースを出力する機能レイヤとトレース取得ポイントについて，システムの構成ごとに図に示します。

図17-16　PRFトレースを出力する機能レイヤとトレース取得ポイント（Webクライアント構成の場合）

図17-17　PRFトレースを出力する機能レイヤとトレース取得ポイント（EJBクライアント/TPBrokerクライアント/TPBroker OTMクライアント構成（CTM使用）の場合）

図17-18　PRFトレースを出力する機能レイヤとトレース取得ポイント（バッチサーバ構成の場合）

詳細な取得ポイントおよびそれぞれの取得ポイントで出力されるトレースの内容については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

性能解析トレースでは，次の3種類のPRFトレース取得レベルを設定してトレースを出力できます。レベルによって，トレース取得ポイントの数が異なります。

標準レベル
各機能レイヤの境界（入り口と出口）を識別できるトレース情報を出力します。

詳細レベル
標準レベルの出力内容に加えて，各機能レイヤ内処理のトレース情報も出力します。

保守レベル
障害発生時などの保守情報を取得するためのレベルです。

抑止レベル
トレース情報の出力を抑止するためのレベルです。RMIの機能レイヤにだけ設定できます。

Management Serverを利用して運用している場合は，簡易構築定義ファイルで，すべての機能レイヤに対して共通のレベルを設定して，トレース情報を出力します。

17.10.6　トレース情報の取得によるトラブルシュート

トレース情報を利用したトラブルシュートについて説明します。

性能解析トレースに出力される情報を取得することで，トラブルシュートとして次のように使用できます。

J2EEアプリケーションのトランザクションがタイムアウトした場合やリダイレクタでのレスポンス受信時にタイムアウトが発生した場合，性能解析トレースに出力されるルートアプリケーション情報を使用して，タイムアウトしたトランザクションやリクエストを特定できます。

データベースとの接続中にトラブルが発生した場合，性能解析トレースに出力されるコネクションIDを利用して，トラブルが発生したコネクションを特定できます。

17.10.7　性能解析トレースのルートアプリケーション情報の取得のための実装

性能解析トレースのルートアプリケーション情報を取得する機能の概要および実装方法を説明します。

ルートアプリケーション情報とは，性能解析トレース機能で取得した情報のうち，リダイレクタまたはEJBクライアントで取得した情報をいいます。APIを使用して，ルートアプリケーション情報の文字列表現を取得する機能をJ2EEアプリケーションおよびバッチアプリケーションに実装できます。実装すると，取得した文字列表現をログファイルなどに記録することで，任意のタイミングで性能解析トレースファイルとの突き合わせができるため，トラブル発生時のトラブルシュートに役立ちます。

性能解析トレースのルートアプリケーション情報の取得機能を実装するには，CprfTraceクラスを使用します。CprfTraceクラスを使用するには，次のパスをクラスパスに指定してコンパイルします。

<Cosminexusのインストールディレクトリ>¥CC¥lib¥ejbserver.jar

CprfTraceクラスの詳細については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

17.11　サービスユニットの構成監視

Cosminexusでは，サービスユニットの構成監視ができます。

サービスユニットの構成監視では，コマンドを使用してWebシステムのモデル情報を表示することで，Webシステム内のサービスユニットの構成を確認できます。

なお，コマンドの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」のcmx_list_modeコマンドの説明を参照してください。

18.　システムの保守

この章では，Cosminexusシステムで提供する，システムの保守を支援する機能について説明します。

システムの保守を支援する機能として，システム保守に利用できるさまざまな資料を出力する機能があります。

＜この章の構成＞

18.1　システムの保守の概要

18.2　トラブルシューティングの資料の取得

18.3　アプリケーションのユーザログ出力

18.4　コンソールログの出力

18.1　システムの保守の概要

この節では，システムの保守を支援する機能について説明します。

Cosminexusシステムで障害が発生した場合，発生したトラブルの種別に応じて資料を収集する必要があります。Cosminexusでは，システムの保守に利用できる資料として，ログを出力する機能を提供しています。収集する資料の種類と資料の詳細については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

Cosminexusで提供しているシステムの保守を支援する機能の概要を次の表に示します。なお，システムの保守を支援する機能は，J2EEアプリケーションの実行環境，およびバッチアプリケーションの実行環境で使用できます。

表18-1　システムの保守を支援する機能の一覧

機能 | 概要 | 参照個所
トラブルシューティングの資料の取得 | トラブル発生時に，トラブルシューティングの資料を取得します。snapshotログを収集できます。 | 18.2
アプリケーションのユーザログ出力 | J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するユーザログを，システムが出力するログと同じ形式で出力して，扱うことができます。 | 18.3
コンソールログの出力 | 運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などを，コンソール出力情報として取得できます。 | 18.4

18.2　トラブルシューティングの資料の取得

この節では，障害発生時の資料取得の流れと取得できる資料について説明します。また，資料を取得するときに実行する障害検知時コマンドと，資料を一括収集するsnapshotログについて説明します。

＜この節の構成＞

18.2.1　障害発生時の資料取得の流れ

18.2.2　取得できる資料

18.2.3　障害検知時コマンドによる資料取得

18.2.4　snapshotログの収集

18.2.1　障害発生時の資料取得の流れ

Cosminexusシステムでは，自動でトラブルシューティングの資料を取得できます。論理サーバを起動すると，運用管理エージェントは論理サーバの監視を開始します。論理サーバに異常が発生すると，運用管理エージェントは異常を検知し，Management Serverに通知します。Management Serverは資料を取得および収集し，論理サーバを停止して再起動します。

自動で資料を取得する場合の流れを次の図に示します。

図18-1　自動で資料を取得する場合の流れ

参考

2.の障害検知時コマンドで必要な資料を取得し，3.のsnapshotログで資料を収集します。なお，障害検知時コマンドを使用しないで，4.の論理サーバの停止後にsnapshotログを取得することもできますが，このとき取得できる情報はJ2EEサーバだけとなります。このため，障害検知時コマンドを使用して，3.でsnapshotログを収集することをお勧めします。

なお，Management Serverの運用管理コマンド（mngsvrutil）を使用して，snapshotログを任意のタイミングで収集することもできます。snapshotログについては，「18.2.4　snapshotログの収集」を参照してください。Management Serverの運用管理コマンドでの資料の取得については，マニュアル「Cosminexus　システム運用ガイド」のトラブルシューティングに関する説明を参照してください。

論理サーバのプロセスがダウンしたとき，および論理サーバのプロセスがハングアップしたときの処理の流れについて説明します。

＜この項の構成＞

(1)　論理サーバのプロセスがダウンしたときの処理の流れ

(2)　論理サーバのプロセスがハングアップしたときの処理の流れ

(1)　論理サーバのプロセスがダウンしたときの処理の流れ

論理サーバの起動後，運用管理エージェントのプロセス監視では，論理サーバプロセスのプロセスIDを使用して定期的にプロセスを監視します。論理サーバプロセスがダウンしたときの処理の流れを次の図に示します。

図18-2　論理サーバのプロセスダウン時の処理の流れ

論理サーバプロセスのプロセスIDで，定期的にプロセスを監視します。

論理サーバプロセスが異常終了すると，運用管理エージェントはプロセスダウンを検知して，Management Serverに通知します。
プロセス監視では，プロセスIDの存在確認をします。確認内容は，論理サーバの種類によって異なります。詳細については，「17.3.2　論理サーバの起動・停止と稼働確認」を参照してください。

Management Serverではプロセスダウンを検知すると，障害検知時コマンドを実行し，snapshotログを収集します。

障害検知時コマンドとsnapshotログ収集後，論理サーバを自動再起動します。

(2)　論理サーバのプロセスがハングアップしたときの処理の流れ

論理サーバの起動後，運用管理エージェントのプロセス監視では，論理サーバプロセスに対して定期的に，論理サーバが動作しているかを確認します。動作確認中に論理サーバプロセスがハングアップしたときの処理の流れを次の図に示します。

図18-3　論理サーバのプロセスハングアップ時の処理の流れ

定期的に論理サーバプロセスの動作確認をします。
動作確認は，プロセス監視でプロセスIDが存在することが確認されてから，実施されます。確認内容は，論理サーバの種類によって異なります。詳細については，「17.3.2　論理サーバの起動・停止と稼働確認」を参照してください。

連続して動作確認に2回失敗すると（デフォルト値），運用管理エージェントはハングアップと判断して，Management Serverに通知します。なお，ハングアップと判断する，動作確認の失敗回数は変更できます。

Management Serverではハングアップを検知すると，障害検知時コマンドを実行し，snapshotログを収集します。

ハングアップの場合，プロセスは稼働中であるため，自動停止処理を実行します。

運用管理エージェントでは論理サーバの停止コマンドを実行します。
なお，一定時間経っても停止しない場合は，強制停止コマンドが実行されます。

障害検知時コマンドとsnapshotログ収集後，論理サーバを自動再起動します。

18.2.2　取得できる資料

ここでは，トラブルシュートのために取得できる資料の概要を説明します。資料の詳細や資料の取得方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

＜この項の構成＞

(1)　トラブルシューティングに必要な資料

(2)　資料の取得方法

(1)　トラブルシューティングに必要な資料

トラブルシューティングに必要な資料は，発生したトラブルの種別によって異なります。例えば，エラーメッセージが出力されたのか，Cosminexusのサーバプロセスが異常終了したのかによって，必要な資料は異なります。また，トラブルの内容によっては保守員に連絡する必要があります。保守員とは，ご購入契約に基づくお問い合わせ窓口のことです。トラブルシューティングに必要な資料は，資料を保守員へ送付するときのタイミングによって，一次送付資料と二次送付資料に分類されます。

一次送付資料
メールの添付資料として送付できるファイルサイズの資料が該当します。メールなどで早急に保守員に送付できます。
例えば，次の資料が一次送付資料として取得できます。

メッセージログ
J2EEサーバなどの稼働状態およびエラー情報が出力されます。

ユーザログ
アプリケーション中で出力される標準出力および標準エラー出力の情報が出力されます。

例外ログ
システムでトラブルが発生したときの例外情報が出力されます。

保守用ログ
システムでトラブルが発生したときの障害保守情報が出力されます。保守員が障害解析用に使用します。

二次送付資料
一次送付資料に加えて，ファイルサイズが比較的大きい資料が該当します。ファイルサイズが比較的大きい資料は資料の送付に時間が掛かるため，別途，保守員に送付する必要があります。
例えば，次の資料が二次送付資料として取得できます。

性能解析トレース
リクエストの一連の処理で出力されるトレース情報が出力されます。

メモリダンプ
プロセスのメモリイメージがダンプ出力されます。

取得できる資料の詳細，およびほかに取得できる資料については，マニュアル「Cosminexus　システム運用ガイド」の取得が必要な資料の種類に関する説明を参照してください。

(2)　資料の取得方法

トラブルシューティングに必要な資料は，個別に取得したり，snapshotログとして一括して取得したりできます。トラブルシューティングに必要な資料の取得については，マニュアル「Cosminexus　システム運用ガイド」の資料の取得に関する説明を参照してください。

なお，資料によっては，事前に取得のための設定をしておく必要があります。例えば，OSの統計情報，ユーザダンプなどは，システム構築時に取得のための設定をしておかないと，取得できません。これらの資料はトラブルシューティングで必要となるため，取得することをお勧めします。

デフォルトの設定で取得できる資料についても，ログファイルの出力先，ログファイルの面数や1ファイル当たりの最大サイズなどを変更できます。必要に応じて，資料取得の設定を変更してください。

また，デフォルトの設定ではsnapshotログとして収集できない資料でも，その資料の取得先をsnapshotログの収集対象として定義することで，snapshotログとして一括収集できるようになります。

トラブルシューティングに必要な資料取得の設定については，マニュアル「Cosminexus　システム構築ガイド」のトラブルシューティングの資料取得の設定に関する説明を参照してください。

18.2.3　障害検知時コマンドによる資料取得

障害検知時コマンドは，Management Serverが論理サーバの障害を検知したときに，システムによって実行されるコマンドです。障害検知時コマンドを利用して，トラブル発生時のスレッドダンプやユーザダンプの取得などの取得処理を実行することで，トラブル発生時のタイムリーな資料を取得できるようになります。また，障害検知時コマンドを利用すると，次のどちらかのタイミングでsnapshotログを自動収集することもできます。収集するタイミングは設定によって決められます。

論理サーバにトラブルが発生した場合，障害検知時コマンドが実行されて，論理サーバの停止前にsnapshotログが収集されます。

J2EEサーバにトラブルが発生した場合，障害検知時コマンドが実行されて，J2EEサーバの再起動前にsnapshotログが収集されます。

障害検知時コマンドには，システム提供の障害検知時コマンドとユーザ作成の障害検知時コマンドの2種類があります。

システム提供の障害検知時コマンド

あらかじめCosminexusで定義されているコマンドです。システム提供の障害検知時コマンドでは，論理サーバにトラブルが発生した場合に，トラブルが発生した論理サーバのJavaVMのスレッドダンプや性能解析トレースなどを取得します。システム提供の障害検知時コマンドで取得した資料は，snapshotログとして収集できます。

デフォルトの設定では，論理サーバにトラブルが発生した場合にシステム提供の障害検知時コマンドが実行されて，トラブルが発生した論理サーバの停止前にsnapshotログが収集されます。

ユーザ作成の障害検知時コマンド

障害検知時コマンドはユーザが作成することもできます。資料取得に必要な任意の処理を記述したバッチファイルやシェルスクリプトを，障害検知時コマンドとして実行できます。

なお，ユーザ作成の障害検知時コマンドで取得した資料をsnapshotログとして収集するためには，その資料の取得先をsnapshotログの収集先として定義しておく必要があります。

システム提供の障害検知時コマンドの動作設定を変更する場合，またはユーザ作成の障害検知時コマンドを利用する場合に必要な設定については，マニュアル「Cosminexus　システム構築ガイド」の障害検知時コマンドによる資料取得の設定に関する説明を参照してください。

18.2.4　snapshotログの収集

システムの構成ソフトウェアがトラブル発生時にそのときの状態を出力したログを，snapshotログといいます。snapshotログには，各種構成ソフトウェアのログのほかに，スレッドダンプ，性能解析トレースなど，システム保守に必要な情報とアプリケーション保守に必要な情報が含まれます。Cosminexusで構築したシステムでは，これらの情報をsnapshotログとして一括収集し，ZIP形式のログファイルとして取得できます。運用管理者は，snapshotログを収集・分析することで，トラブルに対処できます。

snapshotログは，自動または任意のタイミングで収集できます。snapshotログの収集のタイミングを次の表に示します。

表18-2　snapshotログの収集のタイミング

分類 | 収集のタイミング
自動的に収集する※1 | 論理サーバが障害時に自動停止される直前※2
J2EEサーバが障害時に自動再起動される直前※2
J2EEサーバを手動で一括再起動する直前
任意のタイミングで収集する | Management Serverの運用管理コマンド（mngsvrutil）でsnapshotログの収集を実行したとき

注※1

論理サーバの停止前，またはJ2EEサーバの再起動前のどちらのタイミングでsnapshotログを収集するかは，システム構築時に設定を変更できます。デフォルトの設定では，論理サーバの停止前にsnapshotログが収集されます。

注※2

このタイミングでsnapshotログを収集する場合には，Management Serverによって障害検知時コマンドが実行されます。

なお，収集できるのは，論理サーバが稼働しているホスト内のsnapshotログです。

障害検知時コマンドの実行とsnapshotログの収集によって，トラブルシューティングに必要な資料は自動収集するように設定されています。デフォルトの設定で収集されない情報をsnapshotログとして収集したい場合には，その資料の取得先をsnapshotログの収集対象として定義してください。snapshotログの収集対象，出力先ディレクトリや面数などは，システム構築時に設定を変更できます。

デフォルトの設定でsnapshotログとして収集できる資料とsnapshotログ収集の設定については，マニュアル「Cosminexus　システム構築ガイド」のsnapshotログ収集の設定に関する説明を参照してください。取得できる資料の詳細については，マニュアル「Cosminexus　システム運用ガイド」の取得が必要な資料の種類に関する説明を参照してください。

18.3　アプリケーションのユーザログ出力

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションのログ出力の概要と出力方法について説明します。なお，ユーザログ出力の参照先はアプリケーションの種類によって異なります。参照先について次の表に示します。

表18-3　ユーザログ出力に関する参照先

参照先 | アプリケーションの種類
J2EEアプリケーション | バッチアプリケーション | EJBクライアントアプリケーション
18.3.1　ユーザログ出力の概要 | ○ | ○ | ○
18.3.2　ログのフォーマット | ○ | ○ | ○
18.3.3　ユーザログ出力で使用するメソッド | ○ | ○ | ○
18.3.4　ロガーとハンドラの作成と設定 | ○ | ○ | ×
18.3.5　ログの出力方法 | ○ | ○ | ×
18.3.6　セキュリティポリシーの設定 | ○ | × | ×
18.3.7　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法 | ○ | ○ | ×
18.3.8　ユーザログ機能を使用する場合の注意事項 | ○ | ○ | ○
18.3.9　EJBクライアントアプリケーションのユーザログ出力 | × | × | ○
18.3.10　EJBクライアントアプリケーションでのユーザログ出力の実装 | × | × | ○

（凡例）○：参照する　　×：参照しない

＜この節の構成＞

18.3.1　ユーザログ出力の概要

18.3.2　ログのフォーマット

18.3.3　ユーザログ出力で使用するメソッド

18.3.4　ロガーとハンドラの作成と設定

18.3.5　ログの出力方法

18.3.6　セキュリティポリシーの設定

18.3.7　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法

18.3.8　ユーザログ機能を使用する場合の注意事項

18.3.9　EJBクライアントアプリケーションのユーザログ出力

18.3.10　EJBクライアントアプリケーションでのユーザログ出力の実装

18.3.1　ユーザログ出力の概要

ここでは，ユーザログ出力の概要について説明します。

＜この項の構成＞

(1)　ユーザログ出力とは

(2)　ユーザログ出力の仕組み

(1)　ユーザログ出力とは

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するログを，ユーザログといいます。Cosminexusでは，ユーザログを，日立トレース共通ライブラリ形式で出力できます（ユーザログ機能）。これによって，システムのログとアプリケーションのログを同じ形式で扱うことができるようになり，システム全体のログ運用の信頼性を高められます。

次に，ユーザログ機能を使用したログ出力の流れを示します。

図18-4　ユーザログ機能の処理の流れ

ユーザログ出力の実装にはJ2SEの標準のログ出力機能（JavaロギングAPI）を使用します。この機能を使用する場合は，ユーザログ出力をJavaロギングAPIで実装してください。

参考

リソースアダプタからユーザログを出力することはできません。なお，リソースアダプタから呼び出されるMessage-driven Beanからは，ユーザログを出力できます。

(2)　ユーザログ出力の仕組み

ユーザログを出力するJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションの実装には，J2SEのJavaロギングAPIを使用できます。JavaロギングAPIは，メモリ，コンソール，ファイルなどのさまざまな出力ができる汎用性の高いAPIです。ただし，ロジックが単純なため，ミッション・クリティカルなシステムに適用する場合は，信頼性と耐久性を備えたログ出力用クラスをアプリケーション開発者が実装する必要があります。

ユーザログ機能を使用すると，アプリケーション開発者によってログ出力用クラスを実装しなくても，信頼性が高いユーザログを出力できます。

JavaロギングAPIを使用して開発したJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションから出力されたログは，日立トレース共通ライブラリを使用して，ほかのCosminexusシステムの構成ソフトウェアが出力する形式（日立トレース共通ライブラリ形式）で出力することができます。このライブラリを使用することで，ユーザログをほかのシステムのログと同じ形式で扱うことができ，高い信頼性を持つ統一的なログ運用ができます。

ユーザログ出力は，J2SEのJavaロギングの仕組みに従って出力します。Javaロギングでは，ロガーとハンドラという2種類の要素を使用します。なお，ロガーおよびハンドラは，それぞれ，LoggerクラスおよびHandlerクラスのオブジェクトです。

Javaロギングの仕組みを次の図に示します。

図18-5　Javaロギングの仕組み

図について説明します。

アプリケーションから，ロガーを使用して，ユーザログを出力します。
ユーザログは，アプリケーションの処理の中で，Loggerクラスのメソッドを使用して出力されます。

ロガーは，アプリケーションから出力されたログにレベルやメッセージ文字列などの付加情報を追加してLogRecordにしたものを，ハンドラに渡します。
なお，このとき，ロガーに接続されたフィルタ（Filterクラスのオブジェクト）を使用して，ログレベルとして指定する制御以上のきめ細やかな制御をすることもできます。

ハンドラは，受け取ったLogRecordを基に，ログをファイル，コンソールまたはソケットに出力します。
出力先や出力形式は，あらかじめハンドラのプロパティとして設定しておきます。ハンドラでは，ハンドラに接続されたフィルタを使用してきめ細やかな制御ができます。また，フォーマッタ（Formatterクラスのオブジェクト）を使用して任意の形式にフォーマットしたメッセージを出力できます。

Cosminexusでは，日立トレース共通ライブラリ形式でログをファイルに出力するためのファイルハンドラを提供しています。提供しているファイルハンドラについて，アプリケーションの種類ごとに説明します。

●J2EEアプリケーションまたはバッチアプリケーションの場合

ファイルハンドラとして，CJMessageFileHandlerを提供しています。CJMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどは，システム構築時に設定できます。J2EEアプリケーションまたはバッチアプリケーションのユーザログ出力の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

また，ユーザログに，ログを出力したアプリケーションの名称やメッセージの内容と対応したメッセージIDを出力したい場合は，J2EEアプリケーションまたはバッチアプリケーション内で実装する必要があります。この場合は，Application Serverが提供する拡張LogRecord作成用のクラス（CJLogRecordクラス）を使用して実装してください。CJLogRecordクラスの使用方法については，「18.3.3　ユーザログ出力で使用するメソッド」を参照してください。また，CJLogRecordクラスのAPIについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

注意

ハンドラやロガーの設定をJ2EEアプリケーション内に直接実装する場合は，実行するアプリケーションにLoggingPermission("control")のセキュリティ権限が必要になります。LoggingPermission("control")のセキュリティ権限の設定方法については，「18.3.6　セキュリティポリシーの設定」を参照してください。

●EJBクライアントアプリケーションの場合

ファイルハンドラとして，CJMPMessageFileHandlerを提供しています。なお，EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。EJBクライアントアプリケーションのユーザログ出力については，「18.3.9　EJBクライアントアプリケーションのユーザログ出力」を参照してください。

18.3.2　ログのフォーマット

ユーザログ機能を使用した場合，次に示すフォーマットでログが出力されます。

番号　日付　時刻
AppName
pid　tid
MsgID
メッセージテキスト
CRLF

フォーマットの項目の出力内容を次に示します。

表18-4　ログフォーマット

項目
出力内容

番号
トレースコードの通番（4けた）が出力されます。0000から始まり，9999まで行くと，0000に戻ります。

日付
出力時の日付（yyyy/mm/dd形式）が出力されます。

時刻
出力時の時刻（hh:mm:ss.nnn形式）が出力されます。

AppName
アプリケーション識別名が出力されます。アプリケーション識別名は，16バイト以内で指定します。長さの制限を超えた場合は，切り捨てられます。

pid
プロセス識別子（16進表示）が出力されます。OSの管理する値とは異なります。
CJMessageFileHandlerを使用して出力したログの場合，JavaVMがRuntimeのインスタンスに付けたハッシュ値が出力されます。
CJMPMessageFileHandlerを使用して出力したログの場合，JavaVMが日立トレース共通ライブラリをロードした時刻（ミリ秒単位の時間）の下位32ビットが出力されます。

tid
スレッド識別子（16進表示）が出力されます。JavaVMがThreadのインスタンスに付けたハッシュ値です。OSの管理する値とは異なります。

MsgID
メッセージIDが出力されます。メッセージIDは，21バイト以内で指定します。長さの制限を超えた場合は，切り捨てられます。

メッセージテキスト
メッセージの本体です。CR（0x0D），LF（0x0A），NULL（0x00），EOF（0x1A）などの制御文字を含まない任意の文字列です。長さは0～4,095文字で指定します。長さの制限を超えた場合は，切り捨てられます。なお，制御文字を含んでいた場合の出力内容は保障されません。

CRLF
レコード終端記号（0x0D，0x0A）が出力されます。

18.3.3　ユーザログ出力で使用するメソッド

ユーザログ出力で使用するLoggerクラスのメソッドと，CJLogRecordクラスが属するパッケージを示します。CJLogRecordクラスのメソッドの一覧，および機能と文法については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この項の構成＞

(1)　ユーザログ出力で使用するLoggerクラスのメソッド

(2)　CJLogRecordクラスが属するパッケージ

(1)　ユーザログ出力で使用するLoggerクラスのメソッド

CJLogRecordメソッドを使用して，AppNameとMsgIDの受け渡しをする場合，次に示すlogメソッドを使用します。

void log(LogRecord record)

(2)　CJLogRecordクラスが属するパッケージ

CJLogRecordクラスをソースプログラム上で使用するには，次に示すパッケージをインポートする必要があります。

com.hitachi.software.ejb.application.userlog

このパッケージの格納先を，次に示します。

<Cosminexusのインストールディレクトリ>¥CC¥client¥lib¥HiEJBClientStatic.jar

ユーザログ機能を使用する場合のプログラムの実装例，プロパティの設定例，およびユーザログの出力例については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

18.3.4　ロガーとハンドラの作成と設定

JavaロギングAPIを使用してユーザログ出力をするためには，ロガーとハンドラを作成して，必要な設定をします。ログ出力に必要なアプリケーション識別名（AppName）やメッセージID（MsgID）などのパラメタは，Cosminexusが提供するCJLogRecordクラスのcreateメソッドの引数に指定します。また，独自のクラスを作成することで，ログのフィルタリングや出力内容のフォーマットをカスタマイズすることもできます。

なお，ユーザログ出力をするには，ログの出力先や構成面数などのプロパティを，実行環境に設定する必要があります。実行環境でのユーザログの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

J2EEアプリケーションまたはバッチアプリケーションのユーザログを出力する場合のロガーとハンドラの作成および設定の概要について説明します。

なお，EJBクライアントアプリケーションのユーザログ出力については，「18.3.9　EJBクライアントアプリケーションのユーザログ出力」を参照してください。

＜この項の構成＞

(1)　ロガーの作成と設定

(2)　ハンドラの作成と設定

(3)　ロガーおよびハンドラを作成・設定する場合の指針

(1)　ロガーの作成と設定

ロガーは，ロガー名称を指定して作成します。作成時には，システム構築時に設定した内容が使用されます。

各アプリケーション内では，ロガー名称を指定して作成されたロガーを取得し，取得したロガーを使用してログを出力します。Loggerクラスのメソッドでは，ロガーの作成およびログ出力の指定ができます。指定したログは，LogRecordに変換され，ハンドラに渡されて，ログファイルまたはコンソールに出力されます。

このほか，ロガーでログを取捨選択するためのフィルタ，ログのレベル，ロガーで使用するハンドラについても，必要に応じて設定できます。

(2)　ハンドラの作成と設定

ハンドラは，システム構築時に設定した内容に従って作成，設定されます。

CJMessageFileHandlerを使用する場合は，ハンドラ名称を変えることで，複数のファイルハンドラを作成できます。

CJMessageFileHandlerで作成したファイルハンドラには，次の項目が設定できます。

ユーザログの出力先ファイル，面数，サイズなどのログファイルの設定

ログ取得レベル

使用するフィルタ，フォーマッタ

なお，一つのハンドラが出力するログのアプリケーション名およびメッセージIDが同じでかまわない場合には，CJMessageFileHandlerのプロパティとして設定できます。メッセージごとに出力するログのアプリケーション名とメッセージIDを変更したい場合は，アプリケーション内のログ出力処理ごとに，アプリケーション名およびメッセージIDを出力するようにCJLogRecordクラスを使用して実装してください。

(3)　ロガーおよびハンドラを作成・設定する場合の指針

ロガーおよびハンドラを作成，設定する場合の指針を次に示します。

一つのロガーに対して複数のファイルハンドラを接続できますが，複数のロガーから出力先が同じファイルハンドラに接続して利用することはできません。

アプリケーションごとにログの出力先を変えたい場合は，アプリケーションごとのロガーを作成します。

ロガーは，階層関係を持たせることができます。階層関係を持たせた場合，下位のロガーが取得したログメッセージは，上位のロガーに伝播します。必要に応じて，ロガーの伝播を止めてください。特に，ロガーの最上位にはルートロガーがデフォルトで存在し，J2SEデフォルトの設定の場合，ルートロガーにはConsoleHandlerが接続されています。上位ロガーへの伝播を止めていない場合，ルートロガーのConsoleHandlerからコンソールにすべてのメッセージが出力されます。

ハンドラはインスタンスごとにメッセージを出力するため，一つの出力メッセージが複数のハンドラに送信された場合，一つの出力メッセージが複数回出力されます。例えば，2か所のConsoleHandlerのメッセージは，コンソールに2回出力されます。

一つのアプリケーションで複数のログファイルを利用する場合は，出力先ごとにハンドラを作成してください。

ロガーとハンドラの作成例を次の図に示します。

図18-6　ロガーとハンドラの作成例

この例では，J2EEアプリケーション1と2に対して，com.example.userlogger1とcom.example.userlogger2という2種類のロガーを作成しています。com.example.userlogger1からは，ログの出力レベルおよび出力内容に応じて2種類のログファイルを出力するために，conf1とconf2という2種類のCJMessageFileHandlerハンドラを作成しています。このような構成にすると，ログファイル1にはSEVEREレベル以上の重要なユーザログを，ログファイル2にはINFOレベル以上のすべてのユーザログを出力するという運用ができます。一方，com.example.userlogger2からは1種類のログファイルだけを出力します。この場合は，J2EEアプリケーションから指定されたログのうち，com.example.userlogger2のロガーとハンドラconf3に指定したレベル以下のユーザログは，すべてログファイル3に出力されます。なお，コンソールにログを出力したい場合は，J2SEの標準のハンドラであるConsoleHandlerを使用してください。

それぞれのログファイルのサイズおよび面数は，アプリケーションが出力するユーザログの量や指定した出力レベルに応じて，適切に設定してください。

18.3.5　ログの出力方法

J2EEアプリケーションまたはバッチアプリケーションでのログの出力は，JavaロギングAPIを使用してコーディングします。ユーザログにJ2EEアプリケーションまたはバッチアプリケーションの名称やメッセージIDを出力したい場合には，Cosminexusが提供している，CJLogRecordクラスを使用します。

CJLogRecordクラスは，JavaロギングAPIのLogRecordクラスを継承したクラスです。メッセージIDとアプリケーション名を設定したCJLogRecordオブジェクトを作成できます。このクラスで作成したオブジェクトをLoggerクラスのlogメソッドの引数に指定することによって，ユーザログに任意のメッセージIDとアプリケーション名が出力できるようになります。

アプリケーション名「UserApp」，メッセージID「USER10000-E」のユーザログを出力する例

try{
  //エラー出力する処理の実行
}
catch(Error ex){
  logger.log(CJLogRecord.create(Level.SEVERE, "Catch an exception", "UserApp", "USER10000-E"));
}

APIについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

18.3.6　セキュリティポリシーの設定

ここでは，J2SE標準のロギング機能をユーザのアプリケーションで直接実装して利用するために必要なセキュリティポリシーの設定について説明します。セキュリティポリシーは，server.policy（J2EEサーバ用セキュリティポリシーファイル）またはweb.policy（SecurityManager定義ファイル）に定義します。

簡易構築定義ファイルのパラメタを基に構築されたロガーに対して出力指定をする場合，セキュリティポリシーを設定する必要はありません。セキュリティポリシーの設定が必要なのは，次のような場合です。

ユーザのアプリケーションのソースコード上でJ2SE標準のファイルハンドラを作成する場合

LoggerクラスのaddHandlerメソッドを呼び出してロガーの構成を変更する場合

この場合には，JavaロギングAPI操作用のセキュリティポリシーが必要になります。必要に応じて次のセキュリティパーミッションを指定してください。

フィルタやフォーマッタをリフレクションで作成する場合

permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

それぞれのHandlerクラスは，LogManagerからプロパティを取得して，実行時にReflection機能を使ってFormatterクラスまたはFilterクラスを生成します。このため，Reflectionに関する権限が必要です。

LogManagerのプロパティを設定する場合

permission java.util.PropertyPermission "*", "read, write";

LogManagerがログ出力用の設定を読み書き（Propertyのset**）するための権限が必要です。

J2SE標準のファイルハンドラを使用する場合

permission java.io.FilePermission "<<ALL FILES>>", "read, write";

ログを実際にファイルに出力するための権限が必要です。ログのファイルへの出力には，読み取り権限だけではなく，書き込み権限も必要です。

JavaロギングAPIのLogger.addHandlerメソッドなどを使用してログ体系を変更する場合

permission java.util.logging.LoggingPermission "control";

JavaロギングAPIを使用するためのセキュリティパーミッションの指定が必要です。

J2EEアプリケーションのサーブレットから，JavaロギングAPIのLogger.addHandlerメソッドなどを使用してログ体系を変更する場合のserver.policy（J2EEサーバ用セキュリティポリシーファイル）の設定例を次に示します。

設定例

//
// Grant permissions to JSP/Servlet
//
grant codeBase "file:${ejbserver.http.root}/web/${ejbserver.serverName}/-" {
  permission java.lang.RuntimePermission "loadLibrary.*";
  permission java.lang.RuntimePermission "queuePrintJob";
  permission java.net.SocketPermission "*", "connect";
  permission java.io.FilePermission "<<ALL FILES>>", "read, write";
  permission java.util.PropertyPermission "*", "read";

  //For J2SE Logging Source
  permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
  permission java.util.PropertyPermission "*", "read, write";
  permission java.util.logging.LoggingPermission "control";

};

server.policy（J2EEサーバ用セキュリティポリシーファイル）の定義方法については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

18.3.7　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法

ここでは，ユーザが作成した独自のFilterクラス，FormatterクラスまたはHandlerクラスをユーザログ機能で利用するための使用方法について説明します。なお，ここでは，ユーザが作成したクラスをユーザ作成クラスといいます。

ユーザ作成クラスを作成することで，ログのフィルタリングや出力内容をフォーマットできます。ユーザ作成クラスとして，Filterクラス，FormatterクラスまたはHandlerクラスを作成し，ライブラリJARまたはコンテナ拡張ライブラリに含めて使用します。

ユーザ作成クラスをユーザログ機能で使用する方法には，次の2種類の方法があります。

ライブラリJARを利用する
J2EEアプリケーションの場合に使用できる方法です。バッチアプリケーションの場合は使用できません。

コンテナ拡張ライブラリを利用する
J2EEアプリケーションまたはバッチアプリケーションで使用できる方法です。

それぞれの方法について説明します。

＜この項の構成＞

(1)　ライブラリJARを利用する

(2)　コンテナ拡張ライブラリを利用する

(1)　ライブラリJARを利用する

ユーザ作成クラスであるFilterクラス，FormatterクラスまたはHandlerクラスを，アプリケーション上で作成してロガーに追加して利用する方法です。この場合は，次の処理が実行されます。

まず，アプリケーションの中でHandlerクラスをインスタンス化します。

次に，FilterクラスやFormatterクラスをインスタンス化したものをHandlerクラスのインスタンスに接続します。

最後に，接続したHandlerクラスのインスタンスを，ロガーに追加します。

この場合のユーザ作成クラスは，J2SEのjava.util.loggingの仕様に従って作成してください。作成したクラスは，通常のユーザクラスと同じように，WAR，EJB-JARまたはインポート用ライブラリJARに含めて利用できます。

次に，ライブラリJARに含めて利用する場合のユーザ作成クラスの作成手順を示します。

セキュリティポリシーファイル（server.policy）にセキュリティポリシーを設定します。
セキュリティポリシーの設定については，「18.3.6　セキュリティポリシーの設定」，またはマニュアル「Cosminexus　システム構築ガイド」を参照してください。

独自のHandlerクラス，Filterクラス，およびFormatterクラスを含めたインポート用のライブラリJARを作成します。

サーバ管理コマンドを使用して，作成したライブラリJARのクラスをインポートするように指定します。

アプリケーションのソースプログラム上で，独自クラスのインスタンスを生成します。

Loggerクラス，Handlerクラスへ接続する処理を実装します。
J2SE1.4仕様のログマネジャ（LogManager）を利用して実装する場合は，次の点に注意してください。

プロパティ（java.util.logging.classやjava.util.logging.fileなど）を使用して，ログマネジャをカスタマイズすることはできません。カスタマイズした場合，ユーザログの構築に失敗するおそれがあります。

ソースプログラム上でログマネジャのreadConfiguration(InputStream ins)メソッドなどを呼び出すことはできません。readConfiguration(InputStream ins)メソッドを呼び出して，Loggerクラスの構成を初期化した場合，ユーザログ機能によって構築されたログ体系が失われます。

なお，コーディング上の注意事項については，「18.3.8　ユーザログ機能を使用する場合の注意事項」を参照してください。

(2)　コンテナ拡張ライブラリを利用する

ユーザ作成クラスであるFilterクラス，FormatterクラスまたはHandlerクラスのクラス名称をユーザログ機能のプロパティキーに指定しておき，J2EEサーバ起動時にユーザ作成クラスを含むログ構成を構築して利用する方法です。J2EE標準の方法とは異なります。

ユーザ作成クラスを含めたJARファイルをコンテナ拡張ライブラリとして指定して，作成したライブラリへのクラスパスを指定します。これによって，J2EEサーバ起動時に，プロパティキーで指定しているCJMessageFileHandlerクラスとフォーマッタ，フィルタの作成，接続などが実行されて，ログ構成を構築できます。

手順を示します。

ユーザ作成クラスのFormatterクラス，FilterクラスおよびHandlerクラスを含めたJARファイル（コンテナ拡張ライブラリJAR）を作成します。
ここでは，myloglib.jarとします。

myloglib.jarを任意の場所に配置します。
ここでは，次の場所に配置することを前提に説明しています。

Windowsの場合
c:¥mylib

UNIXの場合
/usr/mylib

配置したライブラリへのクラスパスを指定します。
例えば，J2EEサーバの場合は，usrconf.cfg（オプション定義ファイル）内に，次のように指定します。

Windowsの場合
add.class.path=C:¥mylib¥myloglib.jar

UNIXの場合
add.class.path=/usr/mylib/myloglib.jar

usrconf.properties（ユーザプロパティファイル）のユーザログ機能用のプロパティキーに，パッケージ名称を含むフルクラス名を指定します。

18.3.8　ユーザログ機能を使用する場合の注意事項

ここでは，ユーザログ機能を使用する場合の注意事項について説明します。

＜この項の構成＞

(1)　LogManagerのカスタマイズについて

(2)　ユーザが作成したフィルタ・フォーマッタを使用する場合の注意

(3)　ロガーとハンドラとの接続

(1)　LogManagerのカスタマイズについて

J2SE標準のLogManagerは，java.util.logging.config.classなどのプロパティを使用してカスタマイズできます。ただし，Application Serverが提供するユーザログ機能を使用する場合，カスタマイズはしないでください。ユーザログ機能で使用するプロパティを使用したログ体系の構築では，J2EEサーバの起動時に，ユーザログ機能がLogManagerを使用してプロパティからログ構成を取得します。このため，LogManagerをユーザがカスタマイズすると，ログ構成の構築に失敗するおそれがあります。

また，アプリケーションのソースコード上でLogManagerのreadConfiguration(InputStream ins)メソッドなどを実行して，ロガーの構成を初期化した場合も，ユーザログ機能が構築したログ構成が失われます。このため，このメソッドは実行しないでください。

ただし，カスタマイズしたLogManagerが，すでに構築されているログの構成（LogManagerの内容）を完全に引き継いで，さらに独自の処理を追加した構造になっている場合は，カスタマイズ後もユーザログ機能を使用できます。

(2)　ユーザが作成したフィルタ・フォーマッタを使用する場合の注意

ログメッセージの出力時に，ハンドラに接続している，ユーザ作成のフィルタが例外をスローした場合，ハンドラのisLoggableメソッド※1は，true※2を返します。

ハンドラに接続している，ユーザ作成のフォーマッタが例外をスローした場合，ハンドラはフォーマッタで整形したメッセージを出力できません。ユーザが指定したメッセージは，フォーマッタで整形しないで出力されます。

ユーザ作成のフィルタ，フォーマッタがスローした例外の内容については，cjexception.logを参照してください。

注※1

isLoggableメソッドは，ログメッセージの取捨選択を判定するメソッドです。

注※2

trueは，メッセージを出力対象とすることを意味します。

(3)　ロガーとハンドラとの接続

ロガーには複数のハンドラを接続できますが，複数のロガーに同一の設定を持つハンドラ（CJMessageFileHandlerまたはCJMPMessageFileHandler）を接続することはできません。

18.3.9　EJBクライアントアプリケーションのユーザログ出力

ここでは，EJBクライアントアプリケーションのユーザログ出力について説明します。

＜この項の構成＞

(1)　ユーザログ出力の設定

(2)　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法

(1)　ユーザログ出力の設定

EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。

(a)　cjclstartapコマンドを使用する場合

EJBクライアントアプリケーションのプロパティファイルでユーザログの設定をします。EJBクライアントアプリケーションのログ出力の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(b)　vbjコマンドを使用する場合

ユーザログ機能を実装する際，EJBクライアントアプリケーションのユーザログ用の設定ファイルに，CJMPMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタとフォーマッタなどを設定します。ユーザアプリケーションプログラムでは，ユーザログ用の設定ファイルを読み込むように記述する必要があります。

EJBクライアントアプリケーションの開始コマンド実行時に，設定ファイルがユーザアプリケーションプログラムから読み込まれて，EJBクライアントアプリケーションのシステムプロパティに設定されます。

EJBクライアントアプリケーションでのユーザログ機能の実装については，「18.3.10　EJBクライアントアプリケーションでのユーザログ出力の実装」を参照してください。

(c)　ログの出力方法

EJBクライアントアプリケーションのログの出力方法には，2種類のモードがあります。プロセスごとにログ出力先のサブディレクトリを作成する動作モードのことをサブディレクトリ専有モード，複数のプロセスでログ出力先のサブディレクトリを共有する動作モードのことをサブディレクトリ共有モードといいます。

サブディレクトリ専有モードは06-50よりも前のバージョンとの互換用に使用するモードであるため，EJBクライアントアプリケーションを新たに作成する場合は，サブディレクトリ共有モードの使用をお勧めします。

EJBクライアントアプリケーションのユーザログ機能を使用する場合，またはcjclstartapコマンドでEJBクライアントアプリケーションを実行する場合は，サブディレクトリ共有モードを使用してください。

EJBアプリケーションのログの出力方法については，マニュアル「Cosminexus　システム構築ガイド」のEJBクライアントアプリケーションのログの種類に関する説明を参照してください。また，EJBアプリケーションのログを出力するサブディレクトリについては，マニュアル「Cosminexus　システム運用ガイド」のEJBクライアントアプリケーションのシステムログの取得に関する説明を参照してください。

(2)　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法

ユーザが作成した独自のFilterクラス，Formatterクラス，またはHandlerクラスを，EJBクライアントアプリケーションのユーザログ機能で使用する場合は，EJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに，ユーザ作成のクラスを指定してください。

18.3.10　EJBクライアントアプリケーションでのユーザログ出力の実装

ユーザログ機能は，EJBクライアントアプリケーションでも使用できます。ユーザログ機能を実装すると，EJBクライアントアプリケーションのユーザログを出力できるようになります。

ここでは，EJBクライアントアプリケーションでユーザログ機能を利用するための準備と，ユーザログが出力されるまでの処理の流れについて説明します。

＜この項の構成＞

(1)　利用の準備

(2)　ユーザログ出力処理の流れ

(3)　EJBクライアントアプリケーションでのユーザログ出力の拡張

(1)　利用の準備

EJBクライアントアプリケーションでユーザログ機能を利用する場合には，次の準備が必要です。

なお，EJBクライアントアプリケーションでユーザログ機能を利用する前提として，Application Server側での設定が必要になります。ユーザログの具体的な設定内容については，マニュアル「Cosminexus　システム構築ガイド」のアプリケーションのユーザログ出力の設定に関する説明を参照してください。

ユーザログ機能用の設定ファイルの準備
システムプロパティを設定するための，ユーザログ機能用の設定ファイルを準備します。設定ファイルは，J2SEのプロパティファイル形式で記述します。ファイル名称および格納ディレクトリは任意です。
設定ファイルには，J2EEサーバ用のusrconf.propertiesに指定できるキーのうち，「ejbserver.application.userlog」で始まるキーを指定できます。指定できるキーについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

システムプロパティの設定処理の実装
設定ファイルを読み込んでシステムプロパティに設定するための処理を，EJBクライアントアプリケーションのソースコードに追加する必要があります。この処理は，EJBクライアント機能の初期化が実行される処理よりも前に実行されるようにする必要があります。

JARファイルのクラスパスの追加
EJBクライアントアプリケーションを開始するときのクラスパスに，使用するハンドラに対応するJARファイルのクラスパスを追加してください。クラスパスの指定については，マニュアル「Cosminexus　システム構築ガイド」のEJBクライアントアプリケーションのクラスパスへのJARファイルの設定に関する説明を参照してください。

参考

EJBクライアントアプリケーションでユーザログ機能を利用する場合，セキュリティポリシーを設定する必要はありません。

(2)　ユーザログ出力処理の流れ

EJBクライアントアプリケーションでのユーザログの出力は，次の流れで行われます。

システムプロパティの設定
設定ファイルを利用してシステムプロパティが設定されます。

EJBクライアントの初期化
EJBクライアント機能を初期化するメソッドが呼び出されて，ログ体系が構築されます。

JavaロギングAPIの実行
JavaロギングAPIの実行によって，ユーザログが出力されます。

流れに沿って，それぞれの処理内容について説明します。

(a)　システムプロパティの設定

EJBクライアントアプリケーションのユーザログ機能用のシステムプロパティは，設定ファイルを利用して設定されます。

システムプロパティで設定できるプロパティは，J2EEサーバ用のusrconf.propertiesに指定できるプロパティのうち，「ejbserver.application.userlog」で始まるキーです。設定例を次に示します。

# user-log handler function
ejbserver.application.userlog.CJLogHandler.conf1.appname=my_app1
ejbserver.application.userlog.CJLogHandler.conf1.path=application1/logfileA
ejbserver.application.userlog.CJLogHandler.conf1.limit=10485760
ejbserver.application.userlog.CJLogHandler.conf1.count=2
ejbserver.application.userlog.CJLogHandler.conf1.level=SEVERE

# user-log logger function
ejbserver.application.userlog.Logger.com.example.userlogger1.handlers=com.hitachi.software.ejb.application.userlog.CJMPMessageFileHandler;conf1
ejbserver.application.userlog.Logger.com.example.userlogger1.useParentHandlers=true
ejbserver.application.userlog.Logger.com.example.userlogger1.level=INFO
ejbserver.application.userlog.loggers=com.example.userlogger1

EJBクライアントアプリケーションでは，ユーザログを出力するためのハンドラとして，CJMPMessageFileHandlerまたはCJMessageFileHandlerを指定できます。使用するハンドラは，ejbserver.application.userlog.Logger.<ロガー名>.handlersキーに指定します。例の場合は，userlogger1というロガーに，CJMPMessageFileHandlerクラスを指定しています。

CJMPMessageFileHandlerは，複数のプロセスから同時に同じファイルにログ出力できる機能を持つハンドラです。このため，EJBクライアントアプリケーションの複数のプロセスが出力するユーザログをまとめて出力できます。このハンドラは，EJBクライアントアプリケーションの場合だけ使用できるハンドラです。

なお，複数のプロセスから同時に同じファイルにログ出力しない場合は，J2EEアプリケーションのユーザログを出力する場合と同様に，CJMessageFileHandlerも使用できます。CJMessageFileHandlerを使用すると，CJMPMessageFileHandlerを使用する場合に比べて，ログ出力性能が高くなります。

注意

CJMPMessageFileHandlerクラスを使用すると，日立トレース共通ライブラリがログ管理に使用するファイルを「<ユーザログ出力ディレクトリ>/mmap/<ログファイル名のプレフィックス>.mm」に作成します。このユーザログ出力ディレクトリを使用している間は，このファイルを変更または削除しないでください。

(b)　EJBクライアント機能の初期化

EJBクライアント機能を初期化するメソッドが呼び出されて，ログ体系が構築されます。EJBクライアント機能は，次のどれかのタイミングで初期化されます。

JNDIの初期コンテキスト生成（new InitialContextメソッド）

セキュリティ機能APIでのログイン（LoginInfoManagerクラスのloginメソッド）

通信タイムアウト機能APIでの通信タイムアウト設定用オブジェクトの取得（RequestTimeoutConfigFactoryクラスのgetRequestTimeoutConfigメソッド）

注意

初期化処理が失敗した場合，EJBクライアントアプリケーションのユーザログを出力する機能は使用できません。ただし，ユーザアプリケーションのソースコード上で，J2SE標準のHandlerクラスやLoggerクラス，またはユーザが独自に作成したHandlerクラスやLoggerクラスの設定および構築をして，ログを出力することはできます。

(c)　JavaロギングAPIの実行

アプリケーション内の処理で，JavaロギングAPIが実行されて，ユーザログが出力されます。CJMPMessageFileHandlerを使用するときは，次の点に注意してください。

CJMPMessageFileHandler使用時の注意

CJMPMessageFileHandlerを使用する場合，メモリマップトファイルを使用しているため，実際にファイルへ反映されるまで遅延が発生することがあります。プロセスが終了するときにはファイルに反映されますが，長時間動作し続ける場合やファイルへの反映が遅延すると問題がある場合などは，flushを実行することをお勧めします。

flushを実行する方法には，次の二つの方法があります。

Logger.getHandlersメソッドが返すすべてのHandlerに対して，flushメソッドを呼び出す。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名>.autoFlush.enabledプロパティを指定する。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名>.autoFlush.enabledプロパティを指定する場合，flushは自動的に実行されます。このため，flushメソッドは使用しないでください。

(3)　EJBクライアントアプリケーションでのユーザログ出力の拡張

ユーザが作成した独自のクラス（Formatter，Filter，Handler）をEJBクライアントアプリケーションのユーザログ機能で利用するには，ユーザが作成した独自のクラスをEJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに指定します。

18.4　コンソールログの出力

この節では，コンソールログの出力機能について説明します。

Management Serverを利用して運用する場合，運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などを，コンソール出力情報として取得できます。コンソール出力情報の取得を次の図に示します。

図18-7　コンソール出力情報の取得

運用管理エージェントが各プロセスから取得したコンソール出力情報は，ログファイル（コンソールログ）に出力されます。

また，Server Plug-inを使用している場合，コンソール出力情報は，Management Serverを経由してEclipseのコンソールにも表示されます。コンソール出力情報は，イベントとしてManagement Serverに通知されます。イベントはイベントキューに滞留され，順次イベントキューからイベントが取り出されてManagement Serverに通知されます。Management Serverが起動していないなどの理由でイベントを通知できない場合には，通知できるまでイベントが再送されます。イベントキュー内に滞留しているイベントがキューのサイズを超えた場合には，古いイベントから破棄されます。

＜この節の構成＞

(1)　コンソールログの出力対象となる操作

(2)　コンソールログの出力対象となるプロセス

(1)　コンソールログの出力対象となる操作

次の方法で論理サーバ，J2EEアプリケーション，リソースを操作する場合には，運用管理エージェントがプロセスを起動および停止するため，コンソールログを取得できます。

Smart Composer機能のコマンドを使用する場合

Management Serverの運用管理コマンド（mngsvrutil）を使用する場合

Server Plug-inを使用する場合

(2)　コンソールログの出力対象となるプロセス

コンソールログの出力対象となるのは，次のプロセスです。

論理サーバを構成するプロセス

J2EEアプリケーションやリソースを操作するプロセス

ただし，Windowsの場合には，間接起動のプロセスからはコンソールログを取得できません。間接起動される論理サーバについては，「17.3.2　論理サーバの起動・停止と稼働確認」を参照してください。

注意

運用管理エージェントが起動したプロセスが一度に大量の文字列を出力する場合，運用管理エージェントのガーベージコレクションなどのタイミングによっては，対象となるプロセスが一時停止することがあります。

19.　J2EEアプリケーションの運用

この章では，J2EEアプリケーションの運用について説明します。

J2EEアプリケーションの運用では，同時実行数の変更，実行時間の監視，サービスの閉塞，停止，入れ替え，およびテストモードでのJ2EEアプリケーションの実行ができます。

＜この章の構成＞

19.1　J2EEアプリケーションの運用の概要

19.2　同時実行数の動的変更

19.3　J2EEアプリケーション実行時間の監視とキャンセル

19.4　J2EEアプリケーションのサービスの閉塞

19.5　J2EEアプリケーションの停止

19.6　J2EEアプリケーションの入れ替え

19.7　J2EEアプリケーションのテスト機能

19.1　J2EEアプリケーションの運用の概要

J2EEアプリケーションの運用とは，J2EEサーバにデプロイしたJ2EEアプリケーションに対して，日常業務の中で定型的な運用を実施したり，業務状況の変化に応じて適切に設定を変更してチューニングを実施したりすることです。

Cosminexusでは，J2EEアプリケーションに対して次の運用操作を実行する機能を提供しています。

同時実行スレッド数の動的変更

J2EEアプリケーション実行時間の監視とキャンセル

J2EEアプリケーションの閉塞と停止

J2EEアプリケーションの入れ替えと保守

J2EEアプリケーションのテストモードでの運用

なお，バッチサーバの場合，J2EEアプリケーションの運用機能は使用できません。

19.2　同時実行数の動的変更

J2EEアプリケーションの運用では，J2EEアプリケーションのリクエストの同時実行数を動的に変更できます。

リクエストの同時実行数は，J2EEサーバを起動する前に，Webサーバ，Webアプリケーション，Enterprise Bean，CTMなどで設定できます。このうち，Webアプリケーション単位の同時実行数と，CTMの同時実行数は，J2EEサーバ起動後，J2EEアプリケーションの運用中に動的に変更できます。

同時実行数を動的に変更することによって，アクセス状況に応じて同時に実行できる処理を一時的に増加させたり，減少させたりできます。また，稼働状態でパフォーマンスをチューニングしたり，時間帯に応じた計画的な同時実行数の変更をしたりすることもできるようになります。

同時実行数が変更できるのは，次のJ2EEアプリケーションです。

Webアプリケーションを含むJ2EEアプリケーション
Webアプリケーションでは，Webアプリケーション単位の同時実行数が動的に変更できます。詳細については，「4.19.4　同時実行スレッド数の動的変更」を参照してください。

CTMによる制御の対象になっているJ2EEアプリケーション
CTMでは，スケジュールキュー単位の同時実行数が動的に変更できます。詳細については，「11.4.3　リクエストの同時実行数の動的変更」を参照してください。

19.3　J2EEアプリケーション実行時間の監視とキャンセル

J2EEアプリケーション実行時間の監視機能の概要と，J2EEアプリケーション実行時間の監視機能で提供するメソッドタイムアウト機能，およびメソッドキャンセル機能について説明します。

なお，J2EEアプリケーションの実行時間の監視とキャンセルをするためには，J2EEアプリケーションでの設定が必要です。J2EEアプリケーションの実行時間監視については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この節の構成＞

19.3.1　J2EEアプリケーション実行時間の監視の概要

19.3.2　メソッドタイムアウトとは

19.3.3　メソッドキャンセルとは

19.3.4　タイムアウト値の設定例と設定値の有効範囲

19.3.5　J2EEアプリケーション実行時間の監視機能の実装

19.3.6　使用するスレッド数

19.3.1　J2EEアプリケーション実行時間の監視の概要

J2EEアプリケーション実行時間の監視とは，EJBおよびWebアプリケーションのリクエスト実行時間を監視する機能です。J2EEアプリケーション実行時間の監視機能によって，J2EEアプリケーションで無限ループなどの障害発生を検知すると，一定時間内に終了しなかったメソッド処理をタイムアウトしてユーザに通知し，さらにメソッドキャンセル機能によって使用中のトランザクションの強制決着とメソッドのキャンセルを実施できます。

J2EEアプリケーション実行時間の監視機能には，メソッドタイムアウト機能と，メソッドキャンセル機能があります。

メソッドタイムアウト機能

監視基盤にあるリクエストのうち，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知する機能です。監視基盤とは，J2EEアプリケーション実行時間の監視機能を実現するために必要なインタフェースを提供し，監視情報を管理する領域です。

メソッドキャンセル機能

メソッドタイムアウト機能でタイムアウトが通知されたあと，メソッドのキャンセルを実施する機能です。キャンセル時にデータベースにアクセスしている場合は，トランザクションの強制決着もします。

なお，メソッドタイムアウト機能およびメソッドキャンセル機能では，ログ情報としてスレッドダンプを出力します。出力されたスレッドダンプのファイル数は，リソース枯渇監視機能で監視できます。リソース枯渇監視機能については，「17.7　リソースの枯渇監視」を参照してください。

J2EEアプリケーション実行時間の監視機能について次の図に示します。

図19-1　J2EEアプリケーション実行時間の監視機能の概要

図中のコマンドについて説明します。

一覧表示コマンド
メソッドキャンセルコマンドを実施する前に，メソッドキャンセルコマンドを実行できるかどうかを確認するときに使用します。

メソッドキャンセルコマンド
タイムアウトが検知された場合，またはスレッドの状態が不正な場合に使用します。

アプリケーション強制停止コマンド
アプリケーションを強制停止するときに使用します。アプリケーションの強制停止については，「19.5　J2EEアプリケーションの停止」を参照してください。

なお，これらのコマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

19.3.2　メソッドタイムアウトとは

メソッドタイムアウトとは，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知する機能です。

＜この項の構成＞

(1)　タイムアウトの判定とタイムアウト後の動作

(2)　メソッドタイムアウト機能の対象となる処理

(3)　タイムアウト検知間隔とメソッドタイムアウト時間

(1)　タイムアウトの判定とタイムアウト後の動作

タイムアウトは，監視基盤で監視されるメソッドの呼び出しが，次の式を満たす場合に発生します。

タイムアウト判定時点の時刻－メソッド開始時刻 ＞ タイムアウトの時間

また，タイムアウト発生後は，次のどちらかの動作（メソッドキャンセルのモード）を選択できます。

KDJE52703-Wのメッセージを出力する

KDJE52703-Wのメッセージを出力して，メソッドキャンセル機能を実行する

どちらの動作を選択した場合も，タイムアウトした呼び出しが終了したときに，KDJE52716-Iのメッセージが出力されます。

(2)　メソッドタイムアウト機能の対象となる処理

メソッドタイムアウトの対象となる処理に，タイムアウトを設定します。設定する個所は次のとおりです。

Webアプリケーションのリクエスト処理

EJBのメソッド呼び出し処理

なお，メソッドタイムアウトの適用対象として，次の処理は含まれません。

J2EEアプリケーションのデプロイ時やアンデプロイ時に動作する処理

EJBコンテナの状態管理機能，およびアクティブセッションのタイムアウト機能で動作するEnterprise Beanの処理
Enterprise Beanのメソッド呼び出し処理とは別に，EJBコンテナが設定によって自動的に行う処理は，メソッドタイムアウトの適用対象に含まれません。

また，J2EEアプリケーションのデータ構造によっては，メソッドタイムアウトができない場合があります。詳細については，「19.3.5　J2EEアプリケーション実行時間の監視機能の実装」を参照してください。

(3)　タイムアウト検知間隔とメソッドタイムアウト時間

メソッドタイムアウト機能を使用する場合，次の設定が必要です。

タイムアウトを検知する時間の間隔
タイムアウトを検知するための時間間隔を設定します。
メソッドタイムアウトが発生しているかどうかの判定が，指定した間隔ごとにJ2EEサーバによって判定されます。これは，J2EEサーバ単位に設定します。
また，タイムアウトの検知は一定間隔で行われるため，検知までに最大で次の時間が掛かります。

タイムアウトの検知に掛かる時間の算出式

タイムアウトの検知に掛かる時間＝タイムアウトの時間+タイムアウトを検知する時間の間隔

J2EEアプリケーションごとのメソッドタイムアウト時間
メソッドタイムアウトにする時間を，J2EEアプリケーションに設定します。
設定は，J2EEアプリケーション内のEnterprise Bean単位，またはWebアプリケーション単位に設定します。

J2EEアプリケーションの実行時間監視の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

19.3.3　メソッドキャンセルとは

メソッドキャンセルとは，タイムアウトの原因となっている実行中の処理をキャンセルする処理です。メソッドキャンセル時には，現在実行されている処理がキャンセルできるかどうかを判断します。

ポイント

Connector 1.5仕様に準拠したリソースアダプタを使用している場合，次の処理はメソッドキャンセルの対象にできません。

リソースアダプタ独自のメソッド

ワーク管理で実行されているWork

ただし，Workによって呼び出されたMessage-driven Bean内の処理については，メソッドキャンセルの対象にできます。

＜この項の構成＞

(1)　保護区と非保護区

(2)　メソッドキャンセルの処理

(3)　WebコンテナおよびEJBコンテナでのメソッドキャンセル時の動作

(4)　メソッドキャンセル実行のタイミング

(1)　保護区と非保護区

メソッドをキャンセルできる領域のことを非保護区，メソッドをキャンセルできない領域を保護区といいます。

保護区とは，メソッドキャンセルのできない領域です。保護区では，J2EEサーバの動作で共有されるデータや領域を保持したり，JavaVM内で行われる処理を保証したりするため，メソッドキャンセルができません。J2EEサービス，Webコンテナ，EJBコンテナが保護区に該当します。これらの保護区に該当するクラス以外で，保護区として扱いたいクラスがある場合は，保護区リストファイルに記述します。

一方，非保護区は，メソッドキャンセルができる領域です。J2EEアプリケーションが非保護区になります。

保護区，非保護区の判定は，クラス単位で行われます。ただし，非保護区の場合は実行時の条件によって保護区として扱われることがあります。J2EEアプリケーションでも，ネイティブメソッドを呼び出している場合や，スタティックイニシャライザを実行している場合は，保護区と判定されます。

(2)　メソッドキャンセルの処理

メソッドキャンセルは，現在実行中の処理が非保護区の場合だけ実行されます。メソッドキャンセルができるかどうかを確認するため，保護区の判定では，キャンセル対象となるメソッドが非保護区で実行中かどうかを判定します。実行している処理が非保護区の場合は，メソッドキャンセルが行われます。保護区の場合は，一定間隔で保護区の判定をリトライします。一定時間内に非保護区に制御が移らない場合は，メソッドキャンセルが失敗したと見なされ，メソッドキャンセルの処理が終了します。保護区の判定処理の流れを次の図に示します。

図19-2　保護区の判定処理の流れ

なお，メソッドキャンセル時にデータベースにアクセスしている場合，トランザクションは強制的にタイムアウトします。トランザクションがタイムアウトすると，実行中のSQLをキャンセルし，トランザクションはロールバックにマークされます。また，保護区を実行中のためにメソッドキャンセルが行われなくても，トランザクションは強制的にタイムアウトします。このとき，トランザクションはロールバックにマークされます。トランザクションタイムアウトの詳細については，「9.11.8(2)　トランザクションタイムアウト発生時のステートメントキャンセル」を参照してください。

(3)　WebコンテナおよびEJBコンテナでのメソッドキャンセル時の動作

メソッドキャンセルを実行すると，キャンセル対象となるメソッドを実行中のスレッドで，ThreadDeathが発生します。WebコンテナおよびEJBコンテナでは，このThreadDeathをキャッチして必要な処理を実施します。

WebコンテナおよびEJBコンテナでのメソッドキャンセル時の動作について説明します。

(a)　Webコンテナでの動作

ThreadDeathがスローされるタイミングによって動作が異なります。

Webアプリケーションのフィルタ/サーブレット/JSPでのリクエスト処理中にThreadDeathがスローされた場合

呼び出し元となるフィルタ/サーブレット/JSPにjavax.servlet.ServletExceptionがスローされます。

例えば，フィルタからjavax.servlet.FilterChainのdoFilterメソッド呼び出しの延長でサーブレットが実行され，そのサーブレットの実行中にThreadDeathが発生した場合，doFilterメソッドの呼び出しで，javax.servlet.ServletExceptionがスローされます。

同様に，javax.servlet.RequestDispatcherのforwardメソッド，またはincludeメソッドを呼び出して，リクエストをサーブレット/JSPに転送した場合，javax.servlet.ServletExceptionのgetRootCauseメソッドでは，ThreadDeathオブジェクトを返します。

Webアプリケーションのリスナの処理中にThreadDeathがスローされた場合

WebコンテナはThreadDeathをキャッチしますが，リスナが呼び出される契機となったイベントの発生元となるユーザプログラム処理に対しては，例外はスローされません。

例えば，javax.servlet.http.HttpServletRequestのgetSessionメソッドの呼び出しによってHttpSessionを作成した場合，javax.servlet.http.HttpSessionListenerのsessionCreatedメソッドが呼び出されます。このsessionCreatedメソッドの実行中にThreadDeathがスローされた場合，WebコンテナはスローされたThreadDeathをキャッチしますが，HttpSession生成のイベントを発生させたgetSessionメソッド呼び出しには例外をスローしません。

(b)　EJBコンテナでの動作

EJBのメソッド呼び出し中にThreadDeathがスローされた場合は，EJB仕様で定められたシステム例外が発生した場合と同等の動作をします。呼び出し元に返る例外のgetCauseメソッドでは，ThreadDeathオブジェクトを返します。

(4)　メソッドキャンセル実行のタイミング

メソッドキャンセル実行のタイミング，およびメソッドキャンセル実行までに掛かる最大の時間について説明します。

タイムアウト発生時
メソッドタイムアウト時のメソッドキャンセルのモードとして，スレッドを停止することが設定されている場合，タイムアウト発生時にメソッドキャンセルが実行されます。メッセージを出力するだけの設定の場合は，タイムアウト時でもメソッドキャンセルは実行されません。
タイムアウトが発生したメソッドのキャンセル処理は，一定の間隔で実行されます。また，メソッドキャンセルの処理は，動作中のリクエスト処理がタイムアウトしていないかを調査する（タイムアウトを監視する）スレッドとは別のスレッドで，非同期で実行されます。そのため，タイムアウトの検知後にメソッドキャンセルが実行されるまでには，最大で，メソッドキャンセル処理の時間間隔分掛かります。
メソッドキャンセル処理の時間間隔は，タイムアウトを監視する時間間隔と同じです。メソッドキャンセル処理の時間間隔の設定については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEアプリケーション実行時間の監視の設定に関する説明を参照してください。

メソッドキャンセルコマンドの実行時
運用中にメソッドキャンセルコマンドを実行すると，メソッドキャンセルが実行されます。
メソッドキャンセルコマンドは，タイムアウトが発生したメソッドを実行中のスレッドの状態を確認して，メソッドキャンセルが実行できることを確認してから，必要に応じて実行します。
メソッドキャンセルを実行するための手順については，マニュアル「Cosminexus　システム運用ガイド」の，J2EEアプリケーションの実行時間の監視とキャンセルの説明を参照してください。
メソッドキャンセル処理は，コマンド実行後に非同期に実行されます。また，メソッドキャンセル処理は，メソッドキャンセル処理の時間間隔には影響されません。

J2EEアプリケーション強制停止の実行時
J2EEアプリケーションを強制停止した場合に，停止対象となるJ2EEアプリケーションで実行中のスレッドがあるときは，メソッドキャンセルが実施されます。
アプリケーションの強制停止については，「19.5　J2EEアプリケーションの停止」を参照してください。
メソッドキャンセル処理は，コマンド実行後に非同期で実行されます。また，メソッドキャンセル処理は，メソッドキャンセル処理の時間間隔には影響されません。

19.3.4　タイムアウト値の設定例と設定値の有効範囲

J2EEアプリケーション実行時間の監視機能を使用するときの，タイムアウト値の設定例と設定値の有効範囲について，Webアプリケーションの場合とEJBの場合に分けて説明します。

＜この項の構成＞

(1)　Webアプリケーションの場合

(2)　EJBの場合

(1)　Webアプリケーションの場合

Webアプリケーションの場合のタイムアウト値の設定について説明します。

(a)　フィルタ/サーブレット/JSPへの呼び出し

フィルタ/サーブレット/JSP呼び出しのタイムアウト設定について，次の図に示します。

図19-3　フィルタ/サーブレット/JSP呼び出しのタイムアウト設定

各場所のタイムアウト値は，呼び出しの順序を考慮して適切に設定する必要があります。例えば，図中Aの範囲のdoFilterメソッドのタイムアウト値は，メソッドの開始から終了までの処理時間の監視に適用されます。このため，BまたはCの処理時間がAのタイムアウト値に設定した時間に達してしまうと，その時点でタイムアウトされてしまいます。例を次に示します。

処理中にタイムアウトが発生する例

図中のA，B，Cのそれぞれのタイムアウト値として次の表に示す時間が設定されていることとします。

表19-1　タイムアウト値の設定例1

場所 | 設定したタイムアウト値
図中A（フィルタのdoFilterメソッド） | 240秒
図中B（サーブレット） | 180秒
図中C（JSP） | 120秒

このような設定の場合に，AからBへの処理，およびBからCの処理で次の時間が掛かったとします。

AからBへの処理：120秒

BからCへの処理：60秒

このとき，Cでの処理が60秒以上掛かると，図中Aのタイムアウト値の240秒に達してしまうため，処理が完了する前にタイムアウトが発生します。

●設定時の注意事項

アップロード，ダウンロードを実施するサーブレット/JSP内の処理の延長では，クライアントとの通信が発生する場合があります。この場合，アップロード中，ダウンロード中はサーブレット/JSPの処理中として扱われるため，メソッドの実行時間が監視されます。

このため，アップロード，ダウンロードを実施するサーブレット/JSPは，クライアントとの通信遅延などを考慮してタイムアウトを設定する必要があります。特に，ダウンロードについては，ブラウザでダウンロード確認用のダイアログを表示して，クライアントに，ダウンロードの確認を求める場合があります。この場合，ダウンロードするデータ量によっては，クライアント上でユーザがダウンロード確認用のダイアログで操作をするまで，ダウンロードが完了しない（サーブレット/JSPの処理が完了しない）ことがあるので注意してください。

なお，フィルタを経由する場合は，該当するフィルタに関しても同様の注意が必要です。

(b)　サーブレットへの初回リクエスト

サーブレットへの初回アクセス時には，サーブレットのserviceメソッドに設定したタイムアウト値が有効になります。

ただし，DD（web.xml）の<load-on-startup>タグを設定していないサーブレット/JSPの場合，初回リクエスト時には，initメソッドが実行されます。このとき，initメソッドには，該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が有効になります。

また，サーブレット/JSPがserviceメソッドの処理で利用できないことを示す，javax.servlet.UnavailableExceptionをスローした場合に実行されるdestroyメソッドにも，該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が適用されます。

サーブレットへの初回リクエストのタイムアウト設定について，次の図に示します。

図19-4　サーブレットへの初回リクエストのタイムアウト設定

(c)　フィルタを経由したサーブレット/JSPの初回リクエスト

フィルタを経由したサーブレットおよびJSPの初回リクエストのタイムアウト設定について，次の図に示します。

図19-5　フィルタを経由したサーブレットの初回リクエストのタイムアウト設定

図19-6　フィルタを経由したJSPの初回リクエストのタイムアウト設定

フィルタの処理の延長で，サーブレット/JSPが呼び出される場合のフィルタのタイムアウト値は，フィルタの延長で呼び出されるサーブレット/JSPのタイムアウト値を考慮して設定する必要があります。

例えば，図19-6の場合，図中Aの範囲のフィルタのタイムアウト値は，フィルタの処理時間に適用されます。このため，BまたはCの処理時間がAのタイムアウト値に設定した時間に達してしまうと，その時点でタイムアウトされてしまいます。図19-6の場合の例を次に示します。

処理中にタイムアウトが発生する例

図中のA，B，Cのそれぞれのタイムアウト値として次の表に示す時間が設定されていることとします。

表19-2　タイムアウト値の設定例2

場所 | 設定したタイムアウト値
図中A（フィルタ） | 240秒
図中BおよびC（サーブレット） | 180秒

このような設定の場合に，フィルタでの処理，およびサーブレットでの処理で次の時間が掛かったとします。

フィルタでの処理：60秒

サーブレットのinitメソッドで処理：120秒

このとき，サーブレットのserviceメソッドでの処理が60秒以上掛かると，図中Aのタイムアウト値の240秒に達してしまうため，サーブレットのserviceメソッドの処理が完了する前にタイムアウトが発生します。

また，DD（web.xml）の<servlet>タグを定義していて，<load-on-startup>タグを設定していないサーブレット/JSPの場合で，初回リクエストをフィルタのdoFilterメソッドの延長で実行するとき，サーブレット/JSPのinitメソッドが実行されます。initメソッドが実行されるタイミングを次の表に示します。

表19-3　initメソッドが実行されるタイミング

対象 | <servlet>タグの定義 | <load-on-startup>タグの定義 | initメソッドの実行されるタイミング
サーブレット | あり | なし | doFilterメソッドが呼び出される前
なし | なし | doFilterメソッドの延長
JSP | あり | なし | doFilterメソッドの延長
なし | なし | doFilterメソッドの延長

このとき，initメソッドのタイムアウト値には，次のどちらかの値が適用されます。

フィルタのタイムアウト値≧Webアプリケーションのタイムアウト値の場合
該当するサーブレット/JSPのserviceメソッドに設定したタイムアウト値が有効になります。

フィルタのタイムアウト値＜Webアプリケーションのタイムアウト値の場合
フィルタに設定したタイムアウト値が有効になります。

(2)　EJBの場合

Stateless Session Beanのビジネスメソッド呼び出しのタイムアウト設定について，次の図に説明します。なお，ほかのBeanの種類（Stateful Session Bean，Entity Bean,，Message-driven Bean）についても同様に設定できます。

図19-7　Stateless Session Beanのビジネスメソッド呼び出しのタイムアウト設定

ビジネスメソッドのタイムアウト値に設定した時間を超えると，タイムアウトが発生します。

なお，EJBのメソッド呼び出しの延長で呼び出されるコールバックは，業務処理の一部であるため，タイムアウト値を設定するときには，コールバックメソッドの実行時間を考慮してください。各メソッドで呼び出されるコールバックについては，「19.3.5(2)　Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法」を参照してください。

19.3.5　J2EEアプリケーション実行時間の監視機能の実装

ここでは，メソッドタイムアウト機能，およびメソッドキャンセル機能を実装する場合の設定や注意事項について説明します。

＜この項の構成＞

(1)　Webアプリケーションのリクエスト処理でのタイムアウト値の設定方法

(2)　Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法

(3)　メソッドタイムアウト発生時のオプションメッセージの設定

(4)　メソッドキャンセルを利用するアプリケーション開発時の注意事項

(1)　Webアプリケーションのリクエスト処理でのタイムアウト値の設定方法

Webアプリケーションのリクエスト処理では，次の表に示すメソッドにタイムアウト値を設定できます。各メソッドのタイムアウト値の有効範囲については，「19.3.4　タイムアウト値の設定例と設定値の有効範囲」を参照してください。

なお，タイムアウトを利用するサーブレットおよびJSPは，DD（web.xml）の<servlet>タグで定義しておく必要があります。

表19-4　メソッドタイムアウトの適用対象（Webアプリケーションのリクエスト処理）

ケース | メソッド | 条件
サーブレット，JSP | service | 条件はありません。
init | DD（web.xml）に<load-on-startup>タグを定義していないサーブレット（JSP利用時は，JSP）に対して，初回リクエストで実行される場合だけ，メソッドタイムアウトの適用対象となります。
destroy | serviceメソッドを呼び出した時に，永久に利用できないことを示すjavax.servlet.UnavailableException例外をスローしたことで実行される場合だけ，メソッドタイムアウトの適用対象となります。
フィルタ | doFilter | 条件はありません。

javax.servlet.http.HttpServletクラスのサブクラスとしてサーブレットを実装し，javax.servlet.http.HttpServletクラスのserviceメソッドから呼び出されるdoXXXメソッド（doGetメソッド,doPostメソッドなど）をオーバーライドする場合，オーバーライドしたdoXXXメソッドがタイムアウトの適用対象となります。

JSPのserviceメソッドとは，JSPから生成されたjavax.servlet.jsp.JspPageインタフェースを実装したクラスのserviceメソッドを指します。

JSP内に定義する_jspServiceメソッドは，JspPageインタフェースの実装クラスから，JspPageのserviceメソッドの延長で実行されます。JSPでJspPageを指定しない場合，Webコンテナが提供するJspPageインタフェースの実装クラスが使用されます。

(2)　Enterprise Beanのメソッド呼び出し処理でのタイムアウト値の設定方法

Enterprise Beanのメソッド呼び出し処理では，メソッド単位にタイムアウト値を設定できます。Enterprise Bean単位にタイムアウト値を設定できません。

J2EEアプリケーションのメソッドを呼び出す側でのメソッドタイムアウト適用対象メソッドを表19-5に，J2EEアプリケーションに実装されるコールバックメソッド側でのメソッドタイムアウトの適用対象メソッドを表19-6にそれぞれ示します。

CMP2.0のfindメソッド／selectメソッド，およびCMP1.0のfindメソッドのように，Javaプログラムに実装されていないメソッドは，メソッドタイムアウトの適用対象外となります。また，メソッドが呼び出しされたときの状態によって，呼び出されるかどうかが決定するコールバックメソッド（ejbActivate，ejbLoadなど）についても，適用対象外となります。

表19-5　メソッドタイムアウトの適用対象（Enterprise Bean呼び出し側）

インタフェース
メソッド
Stateless
Session
Bean
Stateful
Session
Bean
Entity
Bean
(BMP)
Entity
Bean
(CMP2.0)
Entity
Bean
(CMP1.1)
Message
-driven
Bean

ホームインタフェース
create
×
○
○
○
○
×

finder
－
－
○
×
×
－

select
－
－
－
×
－
－

home
－
－
○
○
－
－

コンポーネントインタフェース
remove
×
○
○
○
○
×

ビジネスメソッド
○
○
○
○
○
－

javax.jms.MessageListener
onMessage
－
－
－
－
－
○

（凡例）○：適用されます。　×：適用されません。　－：該当しません。

表19-6　メソッドタイムアウトの適用対象（コールバックメソッド側）

メソッド
Stateless
Session
Bean
Stateful
Session
Bean
Entity
Bean
(BMP)
Entity
Bean
(CMP2.0)
Entity
Bean
(CMP1.1)
Message
-driven
Bean

コンストラクタ
×
×
×
×
×
×

setSessionContext／setEntityContext／setMessageDrivenContext
×
×
×
×
×
×

unsetSessionContext／unsetEntityContext
×
×
×
×
×
－

ejbCreate<Method>
×
○
○
○
○
×

ejbPostCreate<Method>
－
－
×
×
×
－

ejbRemove※
×
○
○
○
○
×

ejbActivate
×
×
×
×
×
－

ejbPassivate
×
×
×
×
×
－

ejbLoad
－
－
×
×
×
－

ejbStore
－
－
×
×
×
－

ejbfind<Method>
－
－
○
－
－
－

ejbSelect<Method>
－
－
－
－
－
－

homeメソッド
－
－
○
○
－
－

ビジネスメソッド
○
○
○
○
○
－

onMessage
－
－
－
－
－
○

（凡例）○：適用されます。　×：適用されません。　－：該当しません。

注※

タイムアウト機能などのコンテナの処理で呼び出された場合は対象外です。

(3)　メソッドタイムアウト発生時のオプションメッセージの設定

メソッドタイムアウトが発生した場合，オプションを設定しておくことによって，タイムアウトを通知するメッセージの詳細部分に任意の文字列を追加することができます。実装例を次に示します。

   // ユーザの処理
....
   // メッセージの追加
RequestMonitorMessage.setMessage("メッセージを追加します。");
....
// ユーザの処理

次のような監視対象ではないアプリケーションでは，このメソッドは使用できません。

EJBクライアントアプリケーション

J2EEアプリケーションが生成，起動したスレッドで動作するアプリケーション

(4)　メソッドキャンセルを利用するアプリケーション開発時の注意事項

メソッドキャンセルを使用する場合，アプリケーションを開発するときに，アプリケーションのデータ構造について注意する必要があります。

メソッドキャンセルを実行すると，スレッドの実行が予期しない場所で中断されます。そのため，メソッドキャンセルの対象スレッドとほかのスレッドで，更新または削除を実行する共有データがある場合，メソッドキャンセルを使用しないでください。共有データが破壊され，ほかのリクエストの処理に影響を及ぼすことがあります。

例えば，あるEnterprise Beanに共有の領域（変数A=1，B=2）を設けて，複数スレッド（スレッド1とスレッド2）でアクセスした場合に，スレッド1が共有の領域を更新中（A=10，B=20）にThreadDeath例外が発生すると，更新が中途半端のまま（A=10，B=2）スレッド1が終了します。このとき，スレッド1が更新途中のデータをスレッド2で参照して，A*Bを計算すると，演算結果が不正になります（正：200，誤：20）。そのため，このような例では，メソッドキャンセルは使用できません。

また，ローカル呼び出し最適化機能を使用している場合は，アプリケーション内で，またはアプリケーションをわたって，複数スレッドで更新や削除を実行するようなデータ構造がないか確認する必要もあります。

19.3.6　使用するスレッド数

J2EEアプリケーション実行時間の監視機能を使用する場合に，生成されるスレッドとスレッド数を次の表に示します。

表19-7　生成されるスレッドとスレッド数

スレッド | スレッド数
メソッドタイムアウトの監視用スレッド※ | 1
タイムアウトによるメソッドキャンセル実行用スレッド | 4
コマンドによるメソッドキャンセル実行用スレッド | 4
現在時刻の取得用スレッド | 1

注※　動作中のリクエスト処理がタイムアウトしていないかを調査するためのスレッドです。

なお，コマンドによるメソッドキャンセル実行用スレッドは，メソッドキャンセルコマンド，およびアプリケーション強制停止コマンドを実行した時に生成され，コマンドを終了した時に削除されます。そのほかのスレッドは，J2EEサーバを起動した時に生成され，J2EEサーバが終了するまで動作します。

19.4　J2EEアプリケーションのサービスの閉塞

サービスとは，J2EEアプリケーションで提供される業務を指します。新しいリクエストについてはエラーを返したり，実行中のリクエストについては処理を続行してエラーを返さないようにしたりして，サービスを閉塞できます。

ここでは，Webアプリケーションのサービスの閉塞と，CTMのスケジュールキューの閉塞について説明します。

＜この節の構成＞

19.4.1　Webアプリケーションのサービスの閉塞と閉塞解除

19.4.2　CTMのスケジュールキューの閉塞と閉塞解除

19.4.1　Webアプリケーションのサービスの閉塞と閉塞解除

Webアプリケーションのサービスの閉塞とは，WebアプリケーションをフロントとするJ2EEアプリケーションのサービスを閉塞することを指します。Webアプリケーションのサービスの閉塞は，例えば，業務時間外やシステムのメンテナンス時に，サービスを停止するときに実施します。

＜この項の構成＞

(1)　サービス閉塞の方法

(2)　負荷分散機を使用したシステム構成でのサービス閉塞

(3)　エラーページの表示

(4)　サービス閉塞の解除

(1)　サービス閉塞の方法

Webアプリケーションのサービスを閉塞する方法には，次の五つがあります。

負荷分散機でリクエストの振り分け先を変更する方法※1

負荷分散機を停止する方法※2

Webサーバを停止する方法※3

J2EEサーバを停止する方法

アプリケーションを停止する方法

注※1

負荷分散機でリクエストの振り分け先を変更する方法の場合，実行中のリクエストの処理を，エラーを返さずに続行させるため，負荷分散機の次の機能を使用します。

リクエスト振り分け先の変更時に，変更前の負荷分散機とWebサーバ間の接続を，リクエスト処理が完了するまで保持する機能

注※2

負荷分散機を停止する方法の場合，負荷分散機の停止中に，実行中のリクエストの処理を，エラーを返さずに続行させるため，負荷分散機の次の機能を使用します。

負荷分散機の停止時に，負荷分散機とWebサーバ間の接続を，リクエスト処理が完了するまで保持する機能

注※3

Webサーバを停止する方法は，WebサーバにHitachi Web Serverを使用している場合だけできます。Microsoft IISを使用している場合は，実行中のリクエストにエラーを返すため，使用できません。

(2)　負荷分散機を使用したシステム構成でのサービス閉塞

サービス閉塞の方法には，負荷分散機を使用する場合と使用しない場合で手順が異なります。ここでは，負荷分散機でリクエストの振り分け先を変更することによって，サービスを閉塞する場合を例に，サービスの閉塞について説明します。

負荷分散機を使用してリクエストの振り分け先を変更する場合，サービス閉塞用のWebサーバを配置する必要があります。稼働中のWebアプリケーションの閉塞後は，サービス閉塞用のWebサーバにリクエストを転送するよう，負荷分散機を設定します。

サービス閉塞前とサービス閉塞後のリクエストの振り分けについて，次の図に示します。

図19-8　サービス閉塞前とサービス閉塞後のリクエストの振り分け

なお，サービス閉塞用のWebサーバでは，Webアプリケーションのサービス閉塞後，リクエストがきたときには，エラーページを返すようにします。

表示させるエラーページはカスタマイズすることもできます。表示されるエラーページについては，「(3)　エラーページの表示」を参照してください。

(3)　エラーページの表示

閉塞したWebアプリケーションのサービスにアクセスした場合，クライアントにはエラーページが表示されます。表示されるエラーページは，次のどれかとなります。

Webサーバのデフォルトのエラーページ，またはユーザが作成したエラーページ

接続エラーのページ※

エラーステータスコードの表示されたエラーページ

注※

接続先のHTTPポートが閉じられている場合に表示されます。

(a)　サービス閉塞の方法と表示されるエラーページ

表示されるエラーページは，Webアプリケーションのサービス閉塞の方法によって異なります。サービス閉塞の方法と，表示されるエラーページを次の表に示します。

表19-8　サービス閉塞の方法と表示されるエラーページ

サービス閉塞の方法
表示されるエラーページ

負荷分散機でリクエストの振り分け先を変更する方法
サービス閉塞用のWebサーバで設定したエラーページ

負荷分散機を停止する方法
接続エラーのページ

Webサーバを停止する方法
接続エラーのページ※1

J2EEサーバを停止する方法
次のエラーステータスコードが表示されたページ

404エラー※2

500エラー※3

503エラー※4

アプリケーションを停止する方法
次のエラーステータスコードが表示されたページ

404エラー※5

503エラー※4

注※1

ただし，負荷分散機を使用している場合は，使用している負荷分散機の仕様に依存します。

注※2

J2EEサーバを停止したときの404エラーは，アプリケーションの停止時に，J2EEサーバにはリクエストが到達していて，Webアプリケーションへの実行待ちキューには到達していないリクエストに対して返されます。

注※3

500エラーは，アプリケーションの停止時に，J2EEサーバには到達していないリクエストに対して返されます。

注※4

503エラーは，アプリケーションの停止時に，Webアプリケーションの実行待ちキューにあるリクエストに対して返されます。

注※5

アプリケーションを停止したときの404エラーは，アプリケーションの停止時に，Webアプリケーションへの実行待ちキューに到達していないリクエストに対して返されます。

(b)　ユーザ作成のエラーページの使用

表示されるエラーページは，ユーザ作成のエラーページにカスタマイズできます。ただし，カスタマイズはサービス閉塞の方法によって，できる場合とできない場合があります。サービス閉塞の方法と，エラーページのカスタマイズについて次の表に示します。

表19-9　サービス閉塞の方法とエラーページのカスタマイズ

サービス閉塞の方法 | エラーページのカスタマイズ
負荷分散機でリクエストの振り分け先を変更する方法 | ○
負荷分散機を停止する方法 | ×
Webサーバを停止する方法 | ×
J2EEサーバを停止する方法 | 　○※
アプリケーションを停止する方法 | 　○※

（凡例）　○：できる　　×：できない

注※

エラーページのカスタマイズをするときのWebサーバの設定で，httpsd.confファイルのErrorDocumentディレクティブでフルURL（http://で始まるURLを記述し，他サイトのコンテンツを指定したURL）を指定しているときには，302エラーが返ります。

エラーページのカスタマイズの設定については，マニュアル「Cosminexus　システム構築ガイド」，およびマニュアル「Hitachi Web Server」を参照してください。

なお，エラーページのカスタマイズの概要については，「4.24　エラーページのカスタマイズ」を参照してください。エラーページのカスタマイズは，WebサーバにHitachi Web Serverを使用している場合だけできます。

(4)　サービス閉塞の解除

Webアプリケーションのサービス閉塞の解除は，サービス閉塞の方法によって異なります。サービス閉塞の方法ごとに，サービス閉塞の解除の方法を示します。

負荷分散機でリクエストの振り分け先を変更する方法の場合
J2EEサーバへリクエストが転送されるように，負荷分散機のリクエスト振り分け先を変更します。

負荷分散機を停止する方法の場合
負荷分散機を起動します。

Webサーバを停止する方法の場合
Webサーバを起動します。

J2EEサーバを停止する方法の場合
J2EEサーバを起動します。

アプリケーションを停止する方法の場合
アプリケーションを開始します。

19.4.2　CTMのスケジュールキューの閉塞と閉塞解除

CTMを使用してリクエストをスケジューリングしている場合，特定のスケジュールキューの閉塞制御ができます。スケジュールキューを閉塞制御することによって，特定のJ2EEアプリケーションをオンライン状態で入れ替えるサービス閉塞などができるようになります。

スケジュールキューの閉塞および閉塞の解除は，運用管理コマンド（mngsvrutil）を使用します。CTMを使用したサービス閉塞については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。CTMのスケジュールキューの閉塞機能についての詳細は，「11.5.3　スケジュールキューの閉塞制御」を参照してください。

19.5　J2EEアプリケーションの停止

J2EEアプリケーションを停止させるには，通常停止と強制停止があります。通常停止と強制停止の概要や，処理の流れについて説明します。

＜この節の構成＞

19.5.1　J2EEアプリケーション停止の概要

19.5.2　閉塞処理

19.5.3　停止処理

19.5.4　強制停止処理

19.5.1　J2EEアプリケーション停止の概要

ここでは，J2EEアプリケーション停止の種類，停止のしかたについて説明します。

＜この項の構成＞

(1)　J2EEアプリケーション停止の種類

(2)　停止のしかた

(3)　J2EEアプリケーション停止処理の流れ

(1)　J2EEアプリケーション停止の種類

J2EEアプリケーション停止の種類には，次の二つがあります。

通常停止

通常停止とは，WebアプリケーションやEJBの停止処理を順番に実施して，J2EEアプリケーションを安全に停止させる方法です。このとき，J2EEアプリケーションで処理中のリクエストがあったときには，リクエストが終了してから，J2EEアプリケーションを停止します。通常停止には，タイムアウトを設定できます。通常停止でタイムアウトが発生した場合は，J2EEアプリケーションの状態を確認し，強制停止を実施するか，またはJ2EEサーバを再起動します。

強制停止

強制停止とは，J2EEアプリケーションで処理中のリクエストがある場合でも，強制的に処理を中止する方法です。通常停止を実行後，処理中のリクエストが終了しないなどの原因によって通常停止が継続できない場合に強制停止を実行すると，処理中のリクエストが終了し，通常停止が継続できるようになります。

強制停止は，J2EEアプリケーションで障害が発生した場合に迅速にサービスを閉塞したり，リクエスト処理中のJ2EEアプリケーションを強制停止して，J2EEアプリケーションの入れ替えをしたりするときに使用できます。

(2)　停止のしかた

通常停止，および強制停止は，サーバ管理コマンドで実行します。J2EEアプリケーションの停止については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

(3)　J2EEアプリケーション停止処理の流れ

ここでは，J2EEアプリケーション停止処理の流れについて説明します。通常停止と強制停止の処理の流れを次の図に示します。

図19-9　J2EEアプリケーション停止処理の流れ

通常停止処理では，閉塞処理と停止処理が実施されます。

閉塞処理，停止処理，および強制停止処理について，次項以降で説明します。

19.5.2　閉塞処理

閉塞処理では，閉塞対象のJ2EEアプリケーションを構成する要素のうち，リクエストの受け口となるフロント部分を閉塞し，新規リクエストの受け付けを終了します。

なお，処理中のリクエストは，引き続き処理されます。

＜この項の構成＞

(1)　閉塞順序と処理内容

(2)　J2EEアプリケーションの構成パターンと閉塞方法

(3)　閉塞処理を実行する場合の注意事項

(1)　閉塞順序と処理内容

閉塞順序を次に示します。

Webアプリケーションの閉塞処理

CTMのスケジュールキューの閉塞処理※

フロントEJBの閉塞処理

注※

CTM連携なしの場合は，CTMのスケジュールキューの閉塞処理はありません。

それぞれの閉塞処理での処理内容について説明します。

(a)　Webアプリケーションの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

処理中のリクエストは引き続き処理します。

Webアプリケーションの同時実行数制御のキューにあるリクエストのうち，Webコンテナで処理を開始していないリクエストについては，処理しません。すべて503エラーをクライアントに返します。

(b)　CTMのスケジュールキューの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

CTMのスケジュールキューに投入されたリクエストのうち，J2EEサーバに振り分けられていないリクエストについては，処理しません。java.rmi.RemoteExceptionをクライアントに返します。

CTMのスケジュールキューに投入されたリクエストのうち，すでにJ2EEサーバで処理が開始しているリクエストについては，引き続き処理します。

(c)　フロントEJBの閉塞処理

次の処理が実行されます。

新規リクエストの受け付けを終了します。

処理中のリクエストは，引き続き処理します。

(2)　J2EEアプリケーションの構成パターンと閉塞方法

J2EEアプリケーションの構成パターン別の閉塞方法について，J2EEアプリケーションの形態を図に示し，それぞれの閉塞方法を説明します。

図19-10　J2EEアプリケーションの構成パターン

J2EEアプリケーション1の閉塞方法
J2EEアプリケーション1は，Webアプリケーションを含みます。
この場合，フロントは通常，Webアプリケーションとなります。J2EEアプリケーション1では，Webアプリケーションを閉塞します。

J2EEアプリケーション2の閉塞方法
J2EEアプリケーション2は，EJBをCTM連携で呼び出します。
この場合，クライアントからの呼び出しが必ずCTMになるので，CTMがフロントとなります。J2EEアプリケーション2では，CTMを閉塞します。

J2EEアプリケーション3の閉塞方法
J2EEアプリケーション3は，CTMを使用しないでEJBを呼び出します。
この場合，どのEJBがフロントとなるのかJ2EEアプリケーション構成からは判断できません。フロントとなるEJB（フロントEJB）は，ユーザが指定します。J2EEアプリケーション3では，ユーザが指定したフロントEJBを閉塞します。

J2EEアプリケーション4の閉塞方法
J2EEアプリケーション4は，Webアプリケーションが単独であるJ2EEアプリケーションです。
この場合，Webアプリケーションがフロントとなります。J2EEアプリケーション4では，Webアプリケーションを閉塞します。

J2EEアプリケーション5の閉塞方法
J2EEアプリケーション5は，EJBが単独であるJ2EEアプリケーションです。
この場合，EJBがフロントとなります。フロントとなるEJB（フロントEJB）は，ユーザが指定します。J2EEアプリケーション5では，ユーザが指定したフロントEJBを閉塞します。

なお，フロントEJBの指定については，マニュアル「Cosminexus　システム構築ガイド」のJ2EEサーバのカスタマイズで設定できる主な項目に関する説明を参照してください。

(3)　閉塞処理を実行する場合の注意事項

閉塞処理を実行する場合は，次の点に注意する必要があります。

(a)　CTM使用時の注意

CTM使用時に閉塞処理を実行する場合の注意事項を次に示します。

WebアプリケーションまたはEJBが，CTMを使用して同一J2EEアプリケーション内にあるEJBにアクセスする場合
閉塞処理が終了した時点で，処理中のリクエストもクライアントに例外を返します。このような形態の場合，該当するWebアプリケーションまたはEJBを呼び出すクライアントの処理を停止したあとに，J2EEアプリケーションを停止してください。

CTMから呼び出されているEJBに対して，閉塞処理後にCTMを使用しないでリクエストが投入された場合
EJBの閉塞処理が実施されていないため，新規リクエストが受け付けられます。このような形態の場合，該当するEJBを呼び出すクライアントの処理を停止したあとに，J2EEアプリケーションを停止してください。

usrconf.propertiesのejbserver.ctm.DeactivateTimeOutキーに0を指定している場合
usrconf.propertiesでは，ejbserver.ctm.DeactivateTimeOutキーには0を指定しないでください。
0を指定している場合，CTM経由で仕掛り中のリクエストがある状態でアプリケーションを停止しようとすると，リクエストが終了するまで閉塞が完了しません。このため，リクエストが障害などの理由で終了しない場合，強制停止ができなくなります。

(b)　J2EEアプリケーションをわたったWebアプリケーション呼び出しの注意

Webアプリケーションでは，javax.servlet.ServletContextのgetContextを使用して，同じWebコンテナ上のWebアプリケーションに対してアクセスできます。アクセスするWebアプリケーションが，別のJ2EEアプリケーションに配置されている場合，呼び出し元になるフロントのWebアプリケーションを含むJ2EEアプリケーションを最初に停止してください。

19.5.3　停止処理

停止処理では，J2EEアプリケーションのストップ処理，アンデプロイ処理の順に実施されます。それぞれの処理について説明します。

＜この項の構成＞

(1)　ストップ処理

(2)　アンデプロイ処理

(1)　ストップ処理

ストップ処理は，次の順で実施されます。なお，処理完了後は，J2EEアプリケーションは実行できなくなります。

Webアプリケーションのストップ処理

EJBのストップ処理

J2EEアプリケーションのストップ処理

それぞれの処理について説明します。

(a)　Webアプリケーションのストップ処理

Webアプリケーションのストップ処理は，次の順序で実施されます。

サーブレット/JSPの終了処理
サーブレットのdestroy，JSPのjspDestroyが実施されます。

HTTPセッションの破棄
HTTPセッションの属性の削除および無効化が実施されます。

フィルタの終了処理
フィルタのdestroyが実施されます。

サーブレットコンテキストの破棄
サーブレットコンテキストの属性の破棄および無効化が実施されます。

名前空間からWebアプリケーションの実行環境の削除
名前空間から，ejb-ref，ejb-local-ref，resource-ref，env-entityなどが削除されます。

(b)　EJBのストップ処理

EJBのストップ処理は，次の順序で実施されます。

名前空間からEJBの実行環境の削除
名前空間から，ejb-ref，ejb-local-ref，resource-ref，env-entityなどが削除されます。

名前空間からのEJBホームオブジェクトまたはEJBローカルホームオブジェクトの削除
名前空間から，EJBホームオブジェクトまたはEJBローカルホームオブジェクトが削除されます。

プールの削除
Session Bean，およびMessage-driven Beanの場合は，method-readyプールが削除されます。
Entity Beanの場合は，poolプールとreadyプールが削除されます。

(c)　J2EEアプリケーションのストップ処理

J2EEアプリケーションのストップ処理では，名前空間からJ2EEアプリケーションのエントリが削除されます。

(2)　アンデプロイ処理

アンデプロイ処理は，次の順で実施されます。なお，処理完了後は，J2EEアプリケーションはJ2EEサーバから削除されます。

Webアプリケーションのアンデプロイ処理

EJBのアンデプロイ処理

J2EEアプリケーションのアンデプロイ処理

それぞれの処理について説明します。

(a)　Webアプリケーションのアンデプロイ処理

JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを削除します。なお，JSPのコンパイル結果については，「4.7.6(2)　JSPファイルのコンパイル結果の保持」を参照してください。

(b)　EJBのアンデプロイ処理

EJBのアンデプロイ処理は，次の順序で実施されます。

リモートアダプタの削除（リモートインタフェースサポート時だけ）

CMR使用時に作成したテーブルの削除

(c)　J2EEアプリケーションのアンデプロイ処理

J2EEアプリケーションのアンデプロイ処理では，ユーザが手動でダウンロードしたファイルを削除します。

19.5.4　強制停止処理

強制停止処理では，通常停止のときの閉塞処理や停止処理は実行されません。J2EEアプリケーションで処理中のリクエストがある場合でも，強制的に処理が中止されます。なお，実行中のメソッドについてはメソッドキャンセルが実行されます。

J2EEアプリケーションを強制停止したときのトランザクションの扱い

J2EEアプリケーションの強制停止を実行すると，仕掛かり中のトランザクションは強制的にタイムアウトされます。このため，J2EEアプリケーションを強制停止したあとにトランザクションを開始しようとすると，例外が発生してトランザクションを開始できません。

ただし，インプロセスOTSが複数のJavaVMにわたって動作しているときには，J2EEアプリケーションを強制停止しても，トランザクションは強制的にタイムアウトされません。

また，J2EEアプリケーションの強制停止時に，Statement，CallableStatement，またはPreparedStatementでSQLが実行されている場合，実行は取り消され，制御をJ2EEアプリケーションに戻そうとします。J2EEアプリケーションで使用していたコネクションは破棄され，プールには戻りません。

トランザクションタイムアウトの詳細については，「9.11.8(2)　トランザクションタイムアウト発生時のステートメントキャンセル」を参照してください。

19.6　J2EEアプリケーションの入れ替え

J2EEアプリケーションの入れ替えについて，入れ替えの概要や入れ替え方法について説明します。

＜この節の構成＞

19.6.1　J2EEアプリケーション入れ替えの概要

19.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え

19.6.1　J2EEアプリケーション入れ替えの概要

システムの運用を開始したあとで，J2EEアプリケーションのバージョンアップやメンテナンスを実施するために，J2EEアプリケーションを入れ替えることがあります。

通常，J2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し，新しいJ2EEアプリケーションをインポート，デプロイする必要があります。通常のJ2EEアプリケーションの入れ替えの手順を次の図に示します。

図19-11　通常のJ2EEアプリケーションの入れ替えの手順

通常のJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションを入れ替える間，サービスを停止する必要がありますが，サービスの部分閉塞を使用すると，サービスを停止することなくJ2EEアプリケーションを入れ替えることができます。また，リデプロイ機能やリロード機能を使用すると，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。

J2EEアプリケーションの入れ替え方法を次の表に示します。

表19-10　J2EEアプリケーションの入れ替え方法

入れ替え方法 | 対象のJ2EEアプリケーション
アーカイブ形式 | 展開ディレクトリ形式
サービスの部分閉塞による入れ替え | ○ | ○
リデプロイ機能による入れ替え | ○ | －
リロード機能による入れ替え | － | ○

（凡例）　○：入れ替えできる　－：入れ替えできない

それぞれの入れ替え方法について説明します。なお，入れ替え方法の詳細については，マニュアル「Cosminexus　システム運用ガイド」のJ2EEアプリケーションの入れ替えと保守に関する説明を参照してください。

＜この項の構成＞

(1)　サービスの部分閉塞による入れ替え

(2)　リデプロイ機能による入れ替え

(3)　リロード機能による入れ替え

(1)　サービスの部分閉塞による入れ替え

部分的なサービスの閉塞です。サービスを停止することなく，システムをメンテナンスしたいときに使用します。24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合などには，サービスの部分閉塞によって，サービスを停止することなく，システムをメンテナンスできるようになります。

サービス部分閉塞の実行方法は，J2EEアプリケーションの形態によって異なります。例えば，Webアプリケーションの場合には，入れ替え対象のJ2EEアプリケーションが動作するJ2EEサーバに対して負荷分散機からのリクエストの振り分けを停止し，J2EEアプリケーションを入れ替えます。入れ替えている間は，ほかのJ2EEサーバでリクエストを処理することで，サービスを停止することなくJ2EEアプリケーションを入れ替えられます。

J2EEアプリケーションがWebアプリケーションの場合に，サービス部分閉塞を使用してJ2EEアプリケーションを入れ替える方法については，「19.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え」を参照してください。

参考

サービス部分閉塞は，CTMを利用して実行することもできます。CTMのスケジュールキューの閉塞を利用してJ2EEアプリケーションを入れ替える方法については，「11.5　CTMによるリクエストの閉塞制御」を参照してください。

(2)　リデプロイ機能による入れ替え

アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リデプロイ機能を使用した入れ替えができます。リデプロイとは，少ない手順で高速にJ2EEアプリケーションを入れ替えられるデプロイ方法です。ロジックだけを変更したJ2EEアプリケーションを入れ替えたい場合などに利用できます。ただし，リデプロイ機能を実行できる条件に合わない場合は，通常の手順で入れ替える必要があります。リデプロイ機能を実行できる条件については，「7.4　J2EEアプリケーションのリデプロイ」を参照してください。

リデプロイ機能は，アーカイブ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リデプロイ機能による入れ替え手順を次に示します。

図19-12　リデプロイ機能による入れ替え手順

リデプロイ機能を使用する場合には，通常のアーカイブ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。

参考

リデプロイを実行する前に，JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は，Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし，クラスファイルを生成する機能です。あらかじめ，クラスファイルの生成までを実施しておくので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については，「4.7　JSPの事前コンパイルとコンパイル結果の保持」を参照してください。

リデプロイ機能については，「7.4　J2EEアプリケーションのリデプロイ」を参照してください。

(3)　リロード機能による入れ替え

アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。

リロード機能による入れ替えは，展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リロード機能による入れ替え手順を次に示します。

図19-13　リロード機能による入れ替え手順

リロード機能を使用する場合には，通常の展開ディレクトリ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。

リロード機能については，「7.5　J2EEアプリケーションの更新検知とリロード」を参照してください。

19.6.2　Webアプリケーションのサービスの部分閉塞による入れ替え

Webアプリケーションのサービス閉塞では，部分的にサービスを閉塞することもできます。Webアプリケーションのサービスの部分閉塞によって，サービスを停止することなく，J2EEアプリケーションの入れ替えができ，システムをメンテナンスできます。

＜この項の構成＞

(1)　サービスの部分閉塞ができるシステム構成

(2)　サービスの部分閉塞の方法

(1)　サービスの部分閉塞ができるシステム構成

サービスの部分閉塞ができるシステム構成を次に示します。

負荷分散機を使用して，複数のWebサーバにリクエストを振り分けていること

WebサーバとJ2EEサーバは，1:1または1:nの構成になっていること

なお，セッションを使用するアプリケーションの場合，同一セッションのリクエストは同一のJ2EEサーバで処理する必要がありますが，Webアプリケーションのサービスの部分閉塞をすると，リクエストは，閉塞されたWebアプリケーションがあるJ2EEサーバとは別のJ2EEサーバで処理されます。セッション情報を引き継ぐためには，セッションフェイルオーバ機能を使用してください。セッションフェイルオーバ機能については，「12.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

(2)　サービスの部分閉塞の方法

Webアプリケーションのサービスの部分閉塞をするには，負荷分散機のリクエスト振り分け先を変更して，閉塞したいWebアプリケーションにリクエストが転送されないようにします。

このとき，リクエストにエラーが返されないようにするため，J2EEサーバで実行されるリクエストがないことを確認します。使用しているWebサーバによって，次のことを実施してください。

WebサーバにHitachi Web Serverを使用している場合
Hitachi Web Serverを停止してください。Hitachi Web Serverを停止すると，J2EEサーバにリクエストは転送されません。

WebサーバにMicrosoft IISを使用している場合
該当するJ2EEサーバで実行中のリクエストがないことを確認してください。J2EEサーバで実行中のリクエスト数を確認するには，Management Serverを使用します。Management Serverについては，「16.2　Management Serverで構築したシステムの概要」を参照してください。

なお，負荷分散機には，リクエストの振り分け先を変更したときに，変更前にあった負荷分散機とWebサーバの接続を，リクエスト処理が完了するまで保持する機能が必要です。この機能のない負荷分散機を使用すると，実行中のリクエストにエラーを返すので注意してください。

19.7　J2EEアプリケーションのテスト機能

J2EEアプリケーションのテスト機能には，J2EEアプリケーションの動作モードとして，本番稼働できるJ2EEアプリケーションの動作モードである通常モードと，テスト専用の動作モードであるテストモードの二つがあります。

ここでは，テストモードについて説明します。

＜この節の構成＞

19.7.1　テストモードの概要

19.7.2　テストモードで動作しているJ2EEアプリケーションに対する処理

19.7.3　テストモードで動作しているJ2EEアプリケーション情報の取得

19.7.4　テストモードでのJ2EEアプリケーション呼び出し時の注意事項

19.7.1　テストモードの概要

テストモードとは，J2EEアプリケーションをテスト用に動作させるための，専用の動作モードです。J2EEアプリケーションの新規開発時や，J2EEアプリケーションの入れ替え時など，J2EEアプリケーションを本番環境でテストするときに利用します。なお，テストモードの動作の対象となるのは，WebアプリケーションとEJBです。

テストモードには次のような特徴があります。

稼働中のJ2EEサーバ上にテスト用のJ2EEアプリケーションを配置して，テストを実施できます。
テストモードでJ2EEアプリケーションを動作させても，稼働中のJ2EEアプリケーションに影響を与えることはありません。このため，本番環境でJ2EEアプリケーションのテストを実施できます。

J2EEアプリケーションを容易に本番環境に移行できます。
テストモードで動作しているJ2EEアプリケーションは，テスト終了後，容易に本番運用に移行できます。移行のときには，DDなどの設定を変更する必要はありません。

＜この項の構成＞

(1)　テストモード使用の前提条件

(2)　J2EEアプリケーションの動作モードの変更

(3)　テストモードを使用するための設定

(4)　テストモードで動作中のアプリケーションに対してできる操作

(1)　テストモード使用の前提条件

テストモードでJ2EEアプリケーションを動作させるときの前提条件を次に示します。

同一J2EEサーバでは，同じ名称のJ2EEアプリケーション（表示名が同じJ2EEアプリケーション）は，通常モードとテストモードでそれぞれ一つだけ開始できます。

テストモードのJ2EEアプリケーションと，通常モードのJ2EEアプリケーション間で，相互呼び出しはできません。

Connector 1.5仕様に準拠したInboundリソースアダプタは，テストモードで使用できません。

(2)　J2EEアプリケーションの動作モードの変更

テストモードから通常モードへの変更，および通常モードからテストモードへの変更時には，J2EEアプリケーションをいったん停止する必要があります。モードの変更後，J2EEアプリケーションを開始してください。なお，モードを変更するとき，標準DDなどの設定変更は不要です。

(3)　テストモードを使用するための設定

テストモードにするかどうかは，J2EEアプリケーション単位で設定します。テストモードでのJ2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(4)　テストモードで動作中のアプリケーションに対してできる操作

テストモードで動作するJ2EEアプリケーションのカスタマイズおよび運用操作は，サーバ管理コマンドで実行します。テストモードでのJ2EEアプリケーションの運用については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

19.7.2　テストモードで動作しているJ2EEアプリケーションに対する処理

ここでは，テストモードで実行しているJ2EEアプリケーションに対するクライアントからの処理について説明します。

＜この項の構成＞

(1)　処理の流れ

(2)　テストモードで動作しているWebアプリケーションの呼び出し

(3)　テストモードで動作しているEJBの呼び出し

(4)　CTMを使用する場合の注意事項

(1)　処理の流れ

テストモードおよび通常モードで実行しているJ2EEアプリケーションがあるときのアプリケーションサーバの動作について，CTMを使用する場合と使用しない場合に分けて，図に示します。

図19-14　処理の流れ（CTMを使用する場合）

図19-15　処理の流れ（CTMを使用しない場合）

図について説明します。

クライアント

クライアントは，本番用とテスト用とで別に用意します。

J2EEアプリケーション

通常モードで動作中のJ2EEアプリケーションのほかに，テストモードでJ2EEアプリケーションをデプロイします。

名前空間

CTMを使用する場合，グローバルネーミングサービス，およびローカルネーミングサービスの名前空間は，本番用とテスト用で別に用意します。CTMを使用しない場合のネーミングサービスも同様に，本番用とテスト用を別に用意します。

クライアントから検索する名前空間を本番用とテスト用とで切り分けることで，EJBの呼び出しの切り替えをします。

CTMのスケジュールキュー（CTMを使用する場合だけ）

CTMのスケジュールキューは，本番用のJ2EEアプリケーションとテスト用のJ2EEアプリケーションで別に生成します。

DB Connectorおよびデータベース

J2EEアプリケーションがデータベースを使用する場合は，本番用に定義したDB Connectorを使用します。テスト用のクライアントやJ2EEアプリケーションから，テスト用のデータを生成することで，データベースでの確認をします。

参考

なお，テストモードのJ2EEアプリケーションに含まれるWebアプリケーションからWebサーバ上の静的コンテンツを利用する場合には，次のどちらかの方法で静的コンテンツにアクセスしてください。

WebアプリケーションからWebサーバ上の静的コンテンツに相対パスでアクセスする場合，あらかじめWebサーバ上のディレクトリ構成をテストモードのコンテキストルート名を含むディレクトリ構成として静的コンテンツを配置し，アクセスするようにしてください。

WebアプリケーションからWebサーバ上の静的コンテンツに絶対パスでアクセスする場合，あらかじめWebサーバ上で本番用のディレクトリ構成下に配置された静的コンテンツにアクセスするようにしてください。

(2)　テストモードで動作しているWebアプリケーションの呼び出し

テストモードで動作している場合，テスト用のクライアントからは，テスト用のURLでWebアプリケーションに接続します。

J2EEアプリケーションをテストモードで開始すると，コンテキストルートに「_test_」のプリフィックスが付いた，テスト用のコンテキストルートが生成されます。このコンテキストルートを含むURLが，テスト用のURLになります。例えば，コンテキストルートが「example」で，本番用のURLが「http://www.hitachi.co.jp/example/index.jsp」である場合，テスト用のURLは「http://www.hitachi.co.jp/_test_/example/index.jsp」となります。

注意

通常モードで，コンテキストルート名が「/_test_」で始まるWebアプリケーションを使用している場合，コンテキストルート名が「/_test_」で始まらないWebアプリケーションをテストモードで実行すると，コンテキストルート名が重複したり，またはコンテキストルート名のパスの構成要素が包含関係となったりする場合があります。

例えば，通常モードでコンテキストルート名が「/_test_/example」のWebアプリケーション1を使用している場合に，コンテキストルート名が「/example」のWebアプリケーション2は，テストモードではコンテキストルート名に「/_test_」が付加されるためコンテキストルート名がWebアプリケーション1と重複することになり実行できません。

また，コンテキストルート名が「/example/app」のWebアプリケーション3を，テストモードで実行すると，コンテキストルート名は「/_test_/example/app」となり，Webアプリケーション1とはコンテキストルート名のパスの構成要素が包含関係となります。この場合，テストモードで実行することはできますが，包含されるコンテキストルート名を持つWebアプリケーション1にアクセスできない場合があります。詳細については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」のJ2EEアプリケーションのコンテキストルート定義に関する説明を参照してください。

(3)　テストモードで動作しているEJBの呼び出し

EJBでは，EJBホームオブジェクトおよびEJBローカルホームオブジェクトの取得には，JNDIを利用します。テストモードの場合，通常モード用とは別に名前空間を設けることでJNDIでモードの切り替えをして，EJBを呼び出します。

J2EEアプリケーションをテストモードで開始すると，EJB ホームオブジェクトおよびEJBローカルホームオブジェクトなどは，JNDIで自動変換してから，テストモード用の名前空間に登録および検索されます。クライアント側では，テスト用の名前空間を検索して，EJBホームオブジェクトやEJBローカルホームオブジェクトなどを取得します。JNDIがlookup呼び出し元クライアントのJ2EEアプリケーションのモードを判別して，検索名の変換を自動で実施するので，クライアント側では，テスト用の検索名を意識する必要はありません。

また，テストモードを通常モードに変更しても，lookupの呼び出し元のソースや，WAR，EARなどのDDの変更は必要ありません。

注意

EJBクライアントアプリケーションの場合は，通常モードとテストモードの区別がありません。このため，JNDIでは検索名の自動変換はされませんので，クライアント側ではテストモードの検索名を意識してJ2EEアプリケーションを作成する必要があります。

また，J2EEアプリケーションにEntity Bean（CMP2.0）を含む場合，J2EEアプリケーションのテスト機能を利用できません。

(4)　CTMを使用する場合の注意事項

CTMを使用する場合は，次の内容に注意してください。

(a)　スケジュールキューの名称

スケジュールキューの名称は，通常モードの場合，デフォルトでは，J2EEアプリケーションの名称になります。通常モードのキュー名称との衝突を回避するため，テストモードでは，スケジュールキューの名称を，通常モードのキュー名称の先頭に，プリフィックス「_test_」が付けられます。CTMで提供するコマンドを使用してテスト用のキューを操作する場合は，キュー名称を意識する必要があります。

なお，通常モードとテストモードのJ2EEアプリケーションの間では，CTMのスケジュールキューを共有することはできません。

(b)　EJBホームオブジェクトのJNDI登録名

J2EEアプリケーションをテストモードで開始するとき，ローカルネーミングサービスと同様にCTMが利用するグローバルネーミングサービスにもテスト用の名前空間を形成し，EJBホームオブジェクトを登録します。

19.7.3　テストモードで動作しているJ2EEアプリケーション情報の取得

テストモードで動作しているJ2EEアプリケーションについて，Management Serverを使用すると統計情報の取得ができます。また，性能解析トレースを使用することで，J2EEアプリケーションのモードを確認できます。

＜この項の構成＞

(1)　統計情報の取得

(2)　性能解析トレースの利用によるJ2EEアプリケーションの動作モードの確認

(1)　統計情報の取得

通常モードのJ2EEアプリケーションと同様に，テストモードのJ2EEアプリケーションでも，統計情報を取得できます。統計情報の取得には，Management Serverを使用します。

注意

テストモードで動作しているJ2EEアプリケーションの場合，Management Serverは統計情報の取得にだけ利用できます。Management Serverを使用して，テストモードで動作するJ2EEアプリケーションに対して操作することはできません。

(2)　性能解析トレースの利用によるJ2EEアプリケーションの動作モードの確認

テストモードのJ2EEアプリケーションの呼び出しと，通常モードのJ2EEアプリケーションの相互呼び出しはできません。性能解析トレースを使用すると，クライアントからのリクエストがテストモードのJ2EEアプリケーションの呼び出しか，通常モードのJ2EEアプリケーションの呼び出しかを判断できるので，テストモードと通常モードのJ2EEアプリケーションを呼び出していないかどうか，確認できます。

Webアプリケーション呼び出し時とEJB呼び出し時のモードの判別方法について説明します。なお，トレース取得ポイントの詳細と取得情報については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

(a)　Webアプリケーション呼び出し時のモードの判別

Webアプリケーション呼び出しでモードの判別をするときの，トレース取得ポイントとモードの判別方法について次に示します。

トレース取得ポイント

Webコンテナでのリクエスト取得・リクエストヘッダ解析完了時点

リクエスト処理完了時点

モードの判別方法

上記のトレース取得ポイントで取得された出力情報で，オペレーション名に出力されるURLのコンテキストルートに「_test_」が含まれる場合は，テストモードとなります。

(b)　EJB呼び出し時のモードの判別

EJB呼び出しでモードの判別をするときの，トレース取得ポイントとモードの判別方法について次に示します。

トレース取得ポイント

JNDIでの検索処理開始時点
EJB呼び出しの切り替えはJNDIで実施しているため，JNDIでの検索処理開始時の情報を取得します。

モードの判別方法

上記のトレース取得ポイントで取得された出力情報で，オペレーション名に出力される検索文字列に「$HITACHI_TEST」が含まれる場合は，テストモードとなります。

19.7.4　テストモードでのJ2EEアプリケーション呼び出し時の注意事項

アプリケーションの動作モードには，本番稼働できる通常モードと，テスト専用のテストモードの二つがあります。

テストモードは，アプリケーションの新規開発や，アプリケーションの入れ替えなど，アプリケーションをテストするときに利用します。なお，テストの対象となるのは，WebアプリケーションとEnterprise Beanです。

＜この項の構成＞

(1)　テストモードでのWebアプリケーション呼び出しについての注意事項

(2)　テストモードでのEnterprise Bean呼び出しについての注意事項

(1)　テストモードでのWebアプリケーション呼び出しについての注意事項

アプリケーションの作りによっては，テストモードでのWebアプリケーション呼び出し機能が利用できないことがあります。注意事項を次に説明します。

(a)　ほかのWebアプリケーションとのリンクを作成する場合

テストモードで起動するJ2EEアプリケーションに複数のWebアプリケーションが含まれている場合，そのWebアプリケーションから，同じくテストモードで起動されたWebアプリケーションへのリンク（URLまたはURI）を作成する処理が含まれることがあります。この場合，サーブレットAPIでほかのWebアプリケーションのコンテキストルートは取得できないため，Webアプリケーションで固定またはユーザプログラム内の定義で指定していると考えられます。

この場合，テストモードのWebアプリケーションにアクセスし，作成されたページのリンクにアクセスすると，テストモードのWebアプリケーションではなく，通常モードのWebアプリケーションにアクセスするので注意してください。

(b)　静的コンテンツ内のリンクがコンテキストルートからのパスで記述されている場合

静的コンテンツ内で記述しているリンクが，相対パスではなくコンテキストルートからのパスで記述してある場合，通常モードのWebアプリケーションにアクセスしてしまいます。

(c)　サーブレットAPIを利用する場合

サーブレットAPIで使用するメソッドによっては，次に示す注意が必要になる場合があります。

注意事項A：

引数にコンテキストルート名をハードコーディングしたり，戻り値として特定のコンテキストルート名が返されることを期待したりしないでください。

注意事項B：

戻り値としてファイルシステム上の実際のパスが返されます。特定のファイルパスが返されることを期待しないでください。

注意事項Aおよび注意事項Bに該当するメソッドを，次の表に示します。

表19-11　注意が必要なサーブレットAPI

パッケージ | クラス | メソッド | 注意事項
A | B
javax.servlet | ServletContext | getContext(java.lang.String uripath) | ○ |
getResource(java.lang.String path) | ○ |
getRealPath(java.lang.String path) |  | ○
javax.servlet.http | HttpServletRequest | getContextPath() | ○ |
getPathTranslated() | ○ |
getRequestURI() | ○ |
getRequestURL() | ○ |
getPathTranslated() |  | ○
HttpServletResponse | encodeRedirectUrl(java.lang.String url) | ○ |
encodeRedirectURL(java.lang.String url) | ○ |
encodeUrl(java.lang.String url) | ○ |
encodeURL(java.lang.String url) | ○ |
sendRedirect(java.lang.String location) | ○ |
Cookie | getPath() | ○ |
setPath(java.lang.String uri) | ○ |
HttpServletRequestWrapper | getContextPath() | ○ |
getPathTranslated() | ○ |
getRequestURI() | ○ |
getRequestURL() | ○ |
getPathTranslated() |  | ○
HttpServletResponseWrapper | encodeRedirectUrl(java.lang.String url) | ○ |
encodeRedirectURL(java.lang.String url) | ○ |
encodeUrl(java.lang.String url) | ○ |
encodeURL(java.lang.String url) | ○ |
sendRedirect(java.lang.String location) | ○ |
HttpUtils | getRequestURL(HttpServletRequest req) | ○ |

（凡例）○：注意事項に該当することを示します。

(2)　テストモードでのEnterprise Bean呼び出しについての注意事項

Enterprise Beanの場合，一般にEJBホームオブジェクトおよびEJBローカルホームオブジェクトの取得にJNDIを利用します。したがって，通常モード用とは別にテストモード用の名前空間を設け，JNDIで通常／テストのモード切り替えを実施することで，テストモードでのEnterprise Beanの呼び出しを実現します。テストモードでのEnterprise Beanの呼び出しについての注意事項を次に示します。

(a)　Enterprise Beanを開始する場合

Enterprise Beanを含むJ2EEアプリケーションをテストモードで開始するとき，テストモードで開始されたEnterprise BeanのEJBホームオブジェクト，およびEJBローカルホームオブジェクトなどをテストモード用の名前空間に登録します。テストモード用名前空間への登録／検索については，JNDIで自動変換して実行するため，J2EEアプリケーションに本番／テストのモード変更が発生しても，lookupメソッド呼び出し元のソースや，WAR，Enterprise BeanなどのDD定義の変更は不要です。

(b)　クライアントから接続する場合

クライアントでは，テストモード用の名前空間を検索してEJBホームオブジェクト，およびEJBローカルホームオブジェクトなどを取得します。

J2EEアプリケーション形態のEnterprise Beanのクライアント（例：JSP／サーブレットやEnterprise Bean）では，JNDIがlookupメソッド呼び出し元（クライアント）のJ2EEアプリケーションのモードを判別して自動的に検索名を変換するため，クライアント側ではテストモードの検索名を意識しなくて済みます。

一方，J2EEアプリケーション形態以外のEnterprise Beanのクライアント（例：EJBクライアントアプリケーション）では，JNDIでは自動的に検索名を変換しません。そのため，クライアント側では，テストモードの検索名を意識し，テスト用のクライアントを作成してください（J2EEアプリケーション形態以外のEnterprise Beanのクライアントには，通常モード／テストモードの区別がありません。このため，JNDIでは，検索名の自動変換は実行されません）。

(c)　ダイナミッククラスローディング機能を使用する場合

ダイナミッククラスローディング機能を使用する場合，一つのJ2EEサーバ上で通常モードとテストモードのJ2EEアプリケーションを，同じ名称で同時に開始できません。例えば，すでに通常モードでJ2EEアプリケーションが動作しているときにテストモードのJ2EEアプリケーションを開始しようとすると，開始に失敗します。

テストモードでJ2EEアプリケーションを動作させる場合は，ダイナミッククラスローディング機能を使用しないことをお勧めします。

20.　システムの監査

この章では，Cosminexusが提供する機能を使用したシステムの監査について説明します。

＜この章の構成＞

20.1　システムの監査の概要

20.2　監査ログを使用したシステムの監査

20.3　データベース監査証跡との連携

20.1　システムの監査の概要

近年，組織の健全な運営の保障や，複雑化・多様化するITシステムの安全な構築・運用の観点から，組織の内部統制の重要性が高まっています。内部統制の目的は，いつ，だれが，どんな業務を実行したかを把握することで，業務が各種法規制に準拠して遂行されているかを検証することです。そのために，インフラの面では，システムに対して正当な権限を持つ者が正当な操作を行ったことを監査するための仕組みが必要です。

Cosminexusでは，システムの監査を支援する機能として，システムやアプリケーションに対する操作履歴など，監査の観点で必要な情報を記録する機能を提供しています。

Cosminexusが提供している，システムの監査を支援する機能の概要を次の表に示します。なお，システムの監査を支援する機能は，J2EEアプリケーションの実行環境，およびバッチアプリケーションの実行環境で使用できます。

表20-1　システムの監査を支援する機能の一覧

機能
概要
参照先

監査ログ出力機能
システムの構築者や運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴を監査ログとして出力します。
また，Cosminexusが提供している監査ログ出力用のAPIを使用して，システムで動作するJ2EEアプリケーションやバッチアプリケーションの監査ログを出力する機能を実装できます。
20.2

データベース監査証跡連携機能
データベースが提供するデータベース監査証跡の機能と連携する機能です。Cosminexus上のアプリケーション※1またはサーバ内※2からデータベースにアクセスした際に，Cosminexusシステムが持つ情報をデータベース監査証跡に出力できます。
20.3

注※1　J2EEアプリケーションまたはバッチアプリケーションが対象となります。

注※2　J2EEサーバ内またはバッチサーバ内が対象となります。

20.2　監査ログを使用したシステムの監査

この節では，監査ログを使用したシステムの監査について説明します。

＜この節の構成＞

20.2.1　監査ログを使用したシステムの監査の概要

20.2.2　監査ログ出力の前提条件

20.2.3　アプリケーションの監査ログを出力するための実装

20.2.4　監査ログの出力方式

20.2.1　監査ログを使用したシステムの監査の概要

監査ログとは，システム構築者やシステム運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」「だれが」「何をしたか」を知ることができて，システムの運用が法規制，セキュリティ評価基準，または業界ごとの各種の基準に準拠していることを証明できます。

監査ログには，コマンドなどによる操作を実行したユーザに関する情報や，その操作に伴う処理が成功したか失敗したかなどの監査事象に関する情報，操作や処理の対象に関する情報などが出力されます。これらの情報をシステムの監査に役立てることができます。監査ログに出力される情報の詳細については，マニュアル「Cosminexus　システム運用ガイド」の監査ログの収集と調査に関する情報を参照してください。なお，JP1/NETM/Auditと連携すると，監査ログを自動で収集したり，一括で管理したりすることができるようになります。JP1/NETM/Auditと連携して，監査ログを自動で収集したり一括管理したりする機能については，「21.6　監査ログの収集および一元管理（JP1/NETM/Auditとの連携）」を参照してください。

監査ログが出力される流れと主な出力情報を次の図に示します。

図20-1　監査ログが出力される流れと主な出力情報

監査ログが出力される契機になるのは，コマンドの実行など，Cosminexusのプログラムに対する操作です。この操作は，システム管理者，システム運用者など，その作業に応じたユーザが実行します。また，監査ログは，Cosminexusの各プロセスで監査事象が発生したタイミングで出力されます。監査事象とは，Cosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの処理のうち，システムの構築や運用の正当性を証明するために記録する必要がある事象のことです。Cosminexusでは，監査事象を次のとおり分類して定義しています。

表20-2　監査事象の定義

監査事象
説明

StartStop
ソフトウェアの起動と終了を示す事象です。次の操作が該当します。

各プロセスの起動・停止

J2EEアプリケーションの開始・停止

J2EEリソースの開始・停止

Authentication
システム管理者やシステム運用者が実行した，Management Serverの管理者IDと管理者パスワードによる認証を伴う操作が，成功または失敗したことを示す事象です。

ConfigurationAccess
システム管理者が実行した操作が正常終了または失敗したことを示す事象です。次の操作が該当します。

設定変更

構成変更

構成情報の参照

Cosminexusで定義している監査事象の例を次に示します。

Smart Composer機能のコマンドの実行，およびSmart Composer機能のコマンドの実行に伴う処理

サーバ管理コマンドの実行，およびサーバ管理コマンドの実行に伴う処理

Management Serverを仲介した，管理者IDやパスワードの作成・変更

運用管理エージェントを仲介した，定義ファイルの編集

監査事象は，コマンドごとに定義されています。監査事象となるコマンドの一覧については，マニュアル「Cosminexus　システム運用ガイド」の監査ログが出力されるコマンド一覧を参照してください。コマンドごとの監査ログの出力ポイントについては，マニュアル「Cosminexus　システム運用ガイド」の監査ログの出力ポイントについての説明を参照してください。

また，Cosminexusでは，J2EEアプリケーションまたはバッチアプリケーションに使用する監査ログ出力用のAPIを提供します。監査ログ出力用のAPIを使用すると，監査事象のタイミング以外にも，アプリケーションへの操作の実行や，アプリケーションによる処理のタイミングで監査ログを出力することもできます。監査ログ出力用のAPIを使用したJ2EEアプリケーションまたはバッチアプリケーションの実装については，「20.2.3　アプリケーションの監査ログを出力するための実装」を参照してください。

監査ログを使用したシステムの監査で必要な作業と参照先を次の表に示します。

表20-3　システムの監査で必要な作業と参照先

作業
参照先
記載内容

監査ログ出力の前提条件を知る
「20.2.2　監査ログ出力の前提条件」

監査ログ出力の前提条件

監査を実施するセキュアなシステムの構成を検討する
マニュアル「Cosminexus　システム設計ガイド」

監査ログを使用してセキュアなシステムを構成するための考え方

監査ログを取得するための設定をする
マニュアル「Cosminexus　システム構築ガイド」

監査ログ取得の設定方法

監査ログを収集する
マニュアル「Cosminexus　システム運用ガイド」

監査ログの出力方式

監査ログの収集方法

JP1/NETM/Auditと連携して監査ログを一括収集･管理する
マニュアル「Cosminexus　システム構築ガイド」

JP1/NETM/Auditとの連携方法

監査ログを調査する
マニュアル「Cosminexus　システム運用ガイド」

監査ログの調査方法

監査ログが出力されるコマンド一覧

監査ログの出力ポイント

マニュアル「Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編」

マニュアル「Cosminexus　メッセージ 2　KEOS／KEUC／KFCB編」

マニュアル「Cosminexus　メッセージ 3　KFCT／KFDB／KFDJ編」

監査ログに出力されるメッセージの見方

アプリケーションに監査ログ出力用のAPIを実装する
「20.2.3　アプリケーションの監査ログを出力するための実装」

監査ログ出力用のAPIの実装例

監査ログ出力用のAPIを実装するときの注意事項

マニュアル「Cosminexus　リファレンス　API編」

監査ログ出力用のAPIの詳細

20.2.2　監査ログ出力の前提条件

Cosminexus Version 7の製品ごとに，監査ログ出力機能を使用できるかどうかが異なります。監査ログ出力機能を使用できる製品は，次のとおりです。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

20.2.3　アプリケーションの監査ログを出力するための実装

Cosminexusでは，J2EEアプリケーションまたはバッチアプリケーションに実装できる監査ログ出力用のAPIを提供しています。監査ログ出力用のAPIを使用することで，アプリケーションに対する操作，およびアプリケーションによる処理が実行されたタイミングで，操作および処理の履歴を監査ログに出力させることができます。ここでは，監査ログ出力用のAPIの実装例と実装時の注意事項について説明します。

なお，監査ログ出力用のAPIの詳細についてはマニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この項の構成＞

(1)　監査ログ出力用のAPIの実装例

(2)　監査ログ出力用のAPI実装時の注意事項

(1)　監査ログ出力用のAPIの実装例

監査ログ出力用のAPIの実装例を次に示します。

if (UserAuditLogger.isEnabled())
{
   try
   {
       UserAuditLogger logger = UserAuditLogger.getLogger("UserComponent");
       if (logger.isLoggable("Message1"))
       {
           AuditLogRecord record = new AuditLogRecord();
           record.setMessageId("Message1");
           record.setCategory(AuditLogRecord.CATEGORY_CONFIGURATION_ACCESS);
           record.setResult(AuditLogRecord.RESULT_SUCCESS);
           record.setObjectInfo("Object");
           record.setOperation(AuditLogRecord.OPERATION_REFER);
           record.setMessage("Message");
           logger.log(record);
       }
   }
   catch (AuditLogException e)
   {
       // 監査ログの出力に失敗したときの処理
   }
}

このように実装した場合の監査ログの出力例を次に示します。なお，この例はWindowsの場合です。

CALFHM 1.0, seqnum=2, msgid=Message1, date=2007-05-31T19:12:53.788+09:00, progid=Cosminexus, compid=UAP_UserComponent, pid=3984, ocp:host=hostname, ctgry=ConfigurationAccess, result=Success, subj:euid=username, obj="Object", op="Refer", loc="10.209.15.130/1234/0x0000000000000001", msg="Message"

(2)　監査ログ出力用のAPI実装時の注意事項

監査ログ出力用のAPIを実装するときの注意事項について説明します。

システムの管理・運用に関する情報について

システム管理や運用に関する情報のうち，監査を実行するユーザなどに参照させてはいけない情報を監査ログに出力しないようにしてください。監査ログに出力してはいけない情報の例を次に示します。

データベースにアクセスするユーザのユーザ名，およびパスワード

監査ログファイルや監査ログの設定ファイルに対して書き込み権限を所有するユーザのユーザ名，およびパスワード

複数マシン間での時刻の設定について

複数のマシンにわたって監査ログを出力する場合は，それぞれのマシンに同じ時刻を設定しておいてください。

監査ログに出力する項目について

J2EEアプリケーションまたはバッチアプリケーションが出力する監査ログには，次の項目が必ず出力されるように実装してください。

メッセージID

発生コンポーネント名

監査事象の種別

監査事象の結果

20.2.4　監査ログの出力方式

ここでは，監査ログの出力方式について説明します。

監査ログは，監査ログを出力したサーバのローカルファイルに，ラップアラウンド方式で出力されます。監査ログが出力されるファイルの面数が切り替わるタイミングで，面数が切り替わったことを通知するメッセージが出力されます。また，障害が発生して，監査ログの出力に失敗すると，監査ログの出力でエラーが発生したことを通知するメッセージが出力されます。

監査ログを使用して監査を実施するシステムでは，監査ログをすべて保存しておくことが求められるため，監査ログの出力に失敗した場合は，システムを停止する必要があります。また，ラップアラウンドによって削除される監査ログを，アーカイブする必要があります。これらの処理は，JP1などの運用管理プログラムを使用して，自動実行することをお勧めします。JP1などの運用管理プログラムを使用して，監査ログの出力に失敗した場合にシステムを自動で停止する例と，監査ログを自動でアーカイブする例について説明します。

JP1などの運用管理プログラムを使用して監査ログの出力に失敗した場合にシステムを自動で停止する

監査ログの出力に失敗すると，監査ログの出力に失敗したことを通知するメッセージが，メッセージログに出力されます。JP1などの運用管理プログラムを使用すると，監査ログの出力に失敗したことを通知するメッセージログを監視して，システムを自動で停止することができます。

JP1などの運用管理プログラムを使用して，監査ログの出力に失敗した場合にシステムを自動で停止する流れを次に示します。

図20-2　JP1などの運用管理プログラムを使用して監査ログの出力に失敗した場合にシステムを自動で停止する流れ

障害によってCosminexusが監査ログの出力に失敗します。

Cosminexusが，監査ログの出力に失敗したことを通知するメッセージログを出力します。

JP1などの運用管理プログラムが，メッセージログが出力されたことを検知します。

JP1などの運用管理プログラムがCosminexusを停止します。

JP1などの運用管理プログラムを使用して監査ログを自動でアーカイブする

監査ログの面数が切り替わると，面数が切り替わったことを通知するメッセージが，メッセージログに出力されます。JP1などの運用管理プログラムを使用すると，面数が切り替わったことを通知するメッセージログを監視して，自動でアーカイブすることができます。アーカイブする必要があるファイルを次に示します。

表20-4　アーカイブする必要があるファイル

アーカイブに含める必要があるファイル | パス
監査ログ | <監査ログの出力ディレクトリ>audit[n].log
監査ログのメッセージログ | <監査ログの出力ディレクトリ>¥rasmessage[n].log

JP1などの運用管理プログラムを使用して，監査ログを自動でアーカイブする流れを次に示します。

図20-3　JP1などの運用管理プログラムを使用して監査ログを自動でアーカイブする流れ

監査ログを出力するファイルの面数が切り替わります。

ファイルの面数が切り替わったことを通知するメッセージログを，Cosminexusが出力します。

JP1などの運用管理プログラムが，メッセージログが出力されたことを検知します。

JP1などの運用管理プログラムが，古い監査ログファイルを取得します。

20.3　データベース監査証跡との連携

この節では，データベースが提供するデータベース監査証跡の機能と連携する機能，およびCosminexusシステムでできることについて説明します。

＜この節の構成＞

20.3.1　データベース監査証跡との連携の概要

20.3.2　データベース監査証跡に出力する情報

20.3.1　データベース監査証跡との連携の概要

データベース監査証跡とは，データベースに対する操作を記録したものです。監査者がデータベース監査証跡を調査することによって，監査対象のテーブルに決められた操作権限どおりに運用が行われているか，不正なアクセスがないかをチェックできます。データベース監査証跡の出力，取得，参照などをするための機能は，データベースが提供しています。データベース監査証跡の詳細については，データベースのマニュアルを参照してください。

Cosminexusシステムでは，データベースが提供するデータベース監査証跡の機能と連携できます。この機能をデータベース監査証跡連携機能といいます。この機能によって，次に示すアプリケーションまたはサーバ内からデータベースにアクセスした際に，Cosminexusシステムが持つ情報をデータベース監査証跡の情報の一部として出力させることができます。

J2EEアプリケーションまたはJ2EEサーバ内からデータベースにアクセスした際

バッチアプリケーションまたはバッチサーバ内からデータベースにアクセスした際

データベース監査証跡に出力できるCosminexusシステムの情報は，クライアントからのリクエストごとに割り振られるルートアプリケーション情報です。

データベース監査証跡，アプリケーションのユーザログ，および性能解析トレースを組み合わせて，データベースの監査対象のテーブルにアクセスしたリクエストのセッションID，ログイン名を特定できます。データベース監査証跡と連携した運用方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

＜この項の構成＞

(1)　データベース監査証跡への出力の流れ

(2)　前提条件

(3)　データベース監査証跡連携機能の設定

(1)　データベース監査証跡への出力の流れ

データベース監査証跡連携機能を使用して，データベース監査証跡にCosminexusシステムの情報を出力する処理の流れを次の図に示します。この図では，J2EEアプリケーションからデータベースにアクセスした場合について示します。

図20-4　データベース監査証跡への情報の出力の流れ

J2EEアプリケーションからDBConnectorを経由してデータベースにアクセスする処理を実行します。

データベース監査証跡連携機能がルートアプリケーション情報をパフォーマンストレーサから取得します。

取得したルートアプリケーション情報を，コネクションを通じてデータベースに渡します。

データベースで情報を処理し，データベース監査証跡の情報としてルートアプリケーション情報を出力します。

(2)　前提条件

データベース監査証跡連携機能を使用してデータベース監査証跡にCosminexusシステムの情報を出力するには，次の表に示すデータベース，およびDBConnectorを使用している必要があります。

表20-5　データベース監査証跡連携機能を使用できるデータベースとDBConnector

データベース
使用するDBConnector

HiRDB（バージョン08-02以降）
HiRDB Type4 JDBCドライバに対応した次のDB Connector

DBConnector_HiRDB_Type4_CP.rar

DBConnector_HiRDB_Type4_XA.rar

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

J2EEアプリケーションで，DBConnectorからデータベースへのアクセスを実装している場合に，そのアクセスがJ2EEおよびCosminexusの仕様でDBConnectorからのアクセスが許可されているメソッドまたはその延長の処理内であれば，データベース監査証跡連携機能が動作します。データベース監査証跡連携機能が動作することで，Cosminexusシステムの情報をデータベース監査証跡に出力できます。

次の場合はデータベース監査証跡連携機能が動作しないため，データベース監査証跡にCosminexusシステムの情報は出力されません。

表20-5以外のDBConnectorを使用した場合

データベースが提供しているJDBCドライバから直接コネクションを取得してデータベースにアクセスした場合

データベースが提供しているデータベース監査証跡機能のAPIを使用した場合

(3)　データベース監査証跡連携機能の設定

データベース監査証跡連携機能を使用するには，次の設定が必要です。

データベースサーバのデータベース監査証跡機能の有効化

データベース監査証跡機能に対応したJDBCドライバのJARファイルのパスの設定

J2EEサーバ単位の設定

設定の詳細については，マニュアル「Cosminexus　システム構築ガイド」のデータベース監査証跡との連携の設定についての説明を参照してください。

20.3.2　データベース監査証跡に出力する情報

ここでは，データベース監査証跡に出力できるCosminexusシステムの情報について説明します。

＜この項の構成＞

(1)　出力する情報

(2)　出力個所

(1)　出力する情報

データベース監査証跡連携機能を使用して，データベース監査証跡に出力できるCosminexusシステムの情報は，ルートアプリケーション情報です。ルートアプリケーション情報以外にデータベース監査証跡に出力されている情報は，データベースが出力した情報です。

データベース監査証跡に出力されるルートアプリケーション情報は，データベースにアクセスしたリクエストのルートアプリケーション情報です。

また，リクエストの延長でJ2EEサーバがデータベースにアクセスする次のような場合には，リクエストのルートアプリケーション情報が出力されます。

Entity BeanのCMPを使用し，EJBコンテナ内からデータベースにアクセスした場合

コネクションの自動クローズが実行された場合

ただし，リクエストと異なるルートアプリケーション情報が出力される場合，およびルートアプリケーション情報が出力されない場合もあります。それぞれの場合について説明します。

リクエストとは異なるルートアプリケーション情報が出力される場合

リクエストの延長ではないところでデータベースにアクセスした次のような場合，リクエストとは異なるルートアプリケーション情報が出力されます。

Message-driven Beanのメッセージ受信側でデータベースにアクセスした場合
ただし，Cosminexus RMの場合，メッセージ送信元のルートアプリケーション情報と関連づけることもできます。詳細については，マニュアル「Cosminexus　Reliable Messaging」を参照してください。

Timer Serviceのコールバックメソッド内でデータベースにアクセスした場合

ルートアプリケーション情報が出力されない場合

次の場合，ルートアプリケーション情報は出力されません。

コネクション取得前にデータベースにアクセスした場合

コネクションプールのウォーミングアップのコネクションを取得した場合

リソースの接続テストをした場合

(2)　出力個所

HiRDBのデータベース監査証跡表の次の列に情報が出力されます。

出力する列名称

PRODUCT_INFO_1

列の型

VARCHAR(255)

出力される情報

ルートアプリケーション情報

21.　JP1と連携したシステムの運用

この章では，JP1と連携したシステムの運用について説明します。

JP1と連携してCosminexusシステムを運用することで，Cosminexusシステムを含んだ業務システム全体の監視から問題の検知，調査対策までの一連の運用を，一貫した操作で効率良くできるようになります。また，サーバやアプリケーションの起動・停止を自動化することで，システムの日常運用の効率化を図れるほか，システムリソースの有効活用もできるようになります。

なお，この章で説明するJP1との連携機能は，Management Serverを利用して運用することが前提になります。

＜この章の構成＞

21.1　JP1と連携して実現できる運用

21.2　システムの集中監視（JP1/IMとの連携）

21.3　システムの構成定義および管理（JP1/IM - CMとの連携）

21.4　ジョブによるシステムの自動運転（JP1/AJS2との連携）

21.5　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）

21.6　監査ログの収集および一元管理（JP1/NETM/Auditとの連携）

21.1　JP1と連携して実現できる運用

業務システムは，Cosminexusによって構築されるアプリケーションサーバ以外にも，サーバ，ネットワーク，ストレージなどのハードウェアや，Webサーバ，メールサーバ，データベースなどのソフトウェアなど，さまざまなリソースによって構成されます。業務システムの運用管理では，これら全体をできるだけ効率良く確実に運用する方法が求められます。

JP1は，このような複合的な業務システムの統合運用管理を実現する，日立のミドルウェアです。JP1と連携して実現できる運用を次に示します。これらは，業務システムの運用形態に応じて，組み合わせて運用できます。なお，JP1との連携は，J2EEアプリケーションの実行環境，およびバッチアプリケーションの実行環境で使用できます。

システム全体を対象に，稼働性能を監視したり，障害を調査して対策したりできます（システムの集中監視）。

Smart Composer機能でのシステム構築時にシステムの構成情報を定義したり，定義したシステムの構成情報を収集したりできます（システムの構成定義および管理）※。

Cosminexusで管理しているサーバやプロセスの起動／停止を，ジョブを使用して自動化できます（ジョブによるシステムの自動運転）。

Smart Composer機能で構築したシステムを，シナリオを使用して自動運転できます（シナリオによるシステムの自動運転）※。

システムの監査ログを自動で収集して一元管理できます（監査ログの収集／一元管理）。

注※

システムの構成定義・管理，およびシナリオを使用した自動運転は，Smart Composer機能を使用して構築したシステムが前提となります。Smart Composer機能については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

また，Cosminexusでは，Management Serverの機能として，JP1と連携する環境の構築を支援したり，JP1と運用管理ポータルを一連の流れの中でスムーズに運用したりするための，次の機能を提供しています。

JP1/IMの統合スコープに表示する監視ツリーの自動生成

JP1/IMの統合コンソールまたは統合スコープからのManagement Serverの運用管理ポータルの直接起動（Windowsの場合）

JP1/AJS2でジョブを定義するときに使用するカスタムジョブ（Windowsの場合）

それぞれの運用管理をするための環境の構築方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

21.2　システムの集中監視（JP1/IMとの連携）

システムの集中監視は，業務システム全体のリソースの状態を監視することで，稼働性能を把握，調査したり，障害の発生を検知して原因を究明，対策したりできる運用方法です。JP1/IMと連携することで実現できます。JP1/IMは，企業情報システム全体を統合管理する基盤になるプログラム群です。JP1/IMでシステムの集中監視をする場合は，次の3種類のプログラムを利用します。

JP1/IM - Central Console※（統合コンソール）
システムで発生した事象をJP1イベントによって集中管理することで，システムの統合管理を実現するプログラムです。JP1イベントとは，システムで発生した事象に，JP1で管理するための属性を付与された情報です。
JP1/IM - Central Consoleでは，発生した事象に関連するエラーメッセージなどが表示されるので，事象の詳細を確認できます。

JP1/IM - Central Scope※（統合スコープ）
システムを監視するための画面を，管理者の目的に合わせて表示できるようにすることで，目的指向型のシステム監視を実現するプログラムです。
発生した事象の影響範囲が業務単位またはサーバ単位のツリー形式で確認できるので，影響範囲の切り分けや特定ができます。

JP1/IM - View（ビューアー）
JP1/IMでシステム運用管理をするときに使用する，監視・操作画面を提供するプログラムです。
統合コンソールおよび統合スコープの操作画面を表示するホストに必要です。

注※　JP1/IM - Central ConsoleとJP1/IM - Central ScopeはJP1 Version 7iの製品です。JP1 Version 8の場合，この二つの製品はJP1/IM - Managerに統合され，内部コンポーネントとして提供されています。JP1 Version 8を使用する場合は，「JP1/IM - Central Console」と「JP1/IM - Central Scope」を「JP1/IM - Manager」に置き換えてお読みください。

JP1/IMのシステムの集中監視の詳細については，マニュアル「JP1 Version 8 JP1/Integrated Management - Manager システム構築・運用ガイド」，またはマニュアル「JP1 Version 7i JP1/Integrated Manager - Console　システム構築・運用ガイド」を参照してください。

また，JP1/IM - CMでシステムの構成定義および管理をする場合については，「21.3　システムの構成定義および管理（JP1/IM - CMとの連携）」を参照してください。

＜この節の構成＞

21.2.1　システムの集中監視の概要

21.2.2　システムの集中監視に必要なプログラム

21.2.3　監視ツリーの自動生成

21.2.4　統合機能メニューからの運用管理ポータルの表示（Windowsの場合）

21.2.5　障害の監視の仕組み

21.2.1　システムの集中監視の概要

JP1/IMと連携してシステムを集中監視すると，Cosminexusシステムの次の事象を統合コンソールと統合スコープのビューアーで監視できるようになります。

J2EEアプリケーションが開始，停止または実行されたことの通知や，J2EEアプリケーション内で発生した障害を監視できます。

論理サーバが開始，停止されたことの通知や，論理サーバで発生した障害を監視できます。

J2EEアプリケーションやバッチアプリケーション内で出力されたユーザログの情報を監視できます。

JP1/IMを使用したシステムの集中監視の概要を次に示します。

図21-1　JP1/IMを使用したシステムの集中監視の概要

J2EEサーバ／Webサーバで障害が発生した場合，その事象が，JP1統合運用管理サーバに通知されます。

JP1統合運用管理サーバから，業務システムの運用管理者に事象が通知されます。
通知方法としては，事象を選別して携帯電話に自動的に通知する設定などができます。このような設定をしておくと，運用管理者自身が常にコンソールを監視している必要がなくなります。

通知を受けた運用管理者が，JP1/IMの統合スコープのビューアーを参照して，事象を確認します。
統合スコープのビューアーでは，監視ツリーを使用して障害などの影響範囲を確認できます。例えば，特定のJ2EEサーバで障害が発生している場合，監視ツリーでは，ツリーのルートノードから該当するJ2EEサーバまでのノードが，障害を表す色で表示されます。このツリーをルートノードからたどれば，障害が発生しているJ2EEサーバとその影響範囲をすぐに確認できます。また，その障害によって業務が完全に停止してしまうのか，またはクラスタ構成によってシステムの停止にはなっていないのかなどを確認して，緊急性の有無を判断できます。
なお，Cosminexusでは，業務指向ツリーとサーバ指向ツリーの2種類の監視ツリーを作成する機能を提供しています。詳細については，「21.2.3　監視ツリーの自動生成」を参照してください。

障害が発生した個所を特定したら，該当するノードから統合コンソールを表示して，エラー情報などを確認します。

障害の原因がCosminexusシステムの設定にあった場合は，統合コンソールからCosminexusの運用管理ポータルを表示して，障害の原因に対処します※。
運用管理ポータルが表示される場合は，統合コンソールで選択したイベントに応じて，その事象に対処するための画面が直接表示されます。

注※

運用管理ポータルの表示は，Windowsの場合だけできます。

Cosminexusでは，このような運用を実現するために，次の機能を提供しています。

JP1/IMで使用するCosminexus用の監視ツリーを自動生成する機能（アダプタコマンド）

Cosminexusシステムで発生したトラブルをJP1/IMに通知するためのJP1イベントを発行する機能

JP1/IMからManagement Serverの運用管理ポータルを表示する機能（モニタ起動コマンド）※

注※

モニタ起動コマンドはWindowsの場合だけ使用できます。

21.2.2　システムの集中監視に必要なプログラム

システムの集中監視は，JP1/IMを中心としたJP1のプログラム群と，Cosminexusの運用管理機能を組み合わせて実現します。

JP1/IMと連携してシステムの集中監視をする場合のシステム構成例を次の図に示します。この図では，JP1 Version 7iの場合のシステム構成例を示します。

図21-2　JP1/IMと連携してシステムの集中監視をする場合のシステム構成例

JP1の各プログラムの主な機能を次に示します。なお，Cosminexusの運用管理機能については，「17.　システムの日常運用」を参照してください。

表21-1　システムの集中監視をするために使用するJP1プログラムの機能

JP1プログラム
機能
配置するサーバ／
クライアント

JP1/Base
JP1/IMの基盤機能を提供します。JP1イベントの送受信などをするほか，JP1/IMシステムのエージェントとして機能します。

J2EEサーバ

Cosminexusの運用管理サーバ

JP1統合運用管理サーバ

JP1/Cm2/ESA for Extension Mib Runtime
TCP/IPネットワークを管理するためのSNMPエージェントです。
CosminexusをインストールしたサーバのOSがWindowsの場合に使用します。

J2EEサーバ

JP1/Cm2/ESA
TCP/IPネットワークを管理するためのSNMPエージェントです。
CosminexusをインストールしたサーバのOSがUNIXの場合に使用します。

J2EEサーバ

JP1/IM - Central Console※
統合コンソールです。

JP1統合運用管理サーバ

JP1/IM - Central Scope※
統合スコープです。

JP1統合運用管理サーバ

JP1/IM - View
ビューアーです。

運用管理クライアント

注※　JP1 Version 8の場合，JP1/IM - Managerの内部コンポーネントとして提供されています。

21.2.3　監視ツリーの自動生成

JP1/IMの統合スコープでは，監視ツリーを使用してシステムを監視します。監視ツリーは，JP1/IMの機能を使用して，自動生成できます。

Cosminexusシステムを集中監視する場合，次の2種類の監視ツリーが自動生成できます。これによって，JP1/IMと連携したCosminexusシステムを含んだシステム全体の障害監視，稼働性能監視が容易に実現できるようになります。

業務指向ツリー

サーバ指向ツリー

なお，監視ツリーは，運用開始前にあらかじめ自動生成しておきます。

監視ツリーの自動生成の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　業務指向ツリー

(2)　サーバ指向ツリー

(3)　監視ツリー自動生成の処理の流れ

(1)　業務指向ツリー

業務指向ツリーとは，Cosminexusシステム上で稼働しているJ2EEアプリケーションを主体に構成されている監視ツリーです。どの業務で問題が発生しているのか，業務の視点で障害が監視できるようになります。

業務指向ツリーの構成を次に示します。初期表示は，「Cosminexus運用管理グループ」ノードまでが展開された状態になります。

図21-3　業務指向ツリーの構成

業務指向ツリーの各ノードについて説明します。

表21-2　業務指向ツリーのノード

ノード名※1 ※2
説明

業務
業務指向ツリーのルートノードです。

AJS2マネージャグループ
JP1/AJS2用のルートノードです。

Cosminexus運用管理グループ
Cosminexus用のルートノードです。

Cosminexus運用管理ホスト<運用管理ホスト名>
Cosminexus運用管理ホストの監視グループです。運用管理ホストの名称が表示されます。

<Cosminexus運用管理ドメイン名>
Cosminexus運用管理ドメインの監視グループです。運用管理ドメインの名称が表示されます。

<業務J2EEアプリケーション名>※3
業務に対応する監視グループです。J2EEアプリケーション（EAR）のプロパティであるDisplay Nameプロパティの値が表示されます。統合スコープから，わかりやすい業務名に必要に応じて変更できます。

<Cosminexus運用管理エージェントホスト名>
論理サーバが稼働するホストの監視グループです。Cosminexusの運用管理エージェントが配置されているホストのホスト名が表示されます。

業務サービス
（JP1/IMで管理しているほかの業務指向ツリーと階層を合わせるためのノードです）。

Cosminexus業務サービス
（サーバ指向ツリーを使用する場合にJP1/AJS2の監視ノードと区別するためのノードです）。

論理サーバ監視
論理サーバに対応する監視グループです。論理サーバを監視するWebサーバ，およびAPサーバの監視グループは，このノードの下に配置されます。

Webサーバ※3
Webサーバに対応する監視グループです。Webサーバを監視するオブジェクトは，このノード下に配置されます。

<Webサーバ名>監視※3
Webサーバの障害監視オブジェクトです。
該当するWebサーバに障害が発生すると，この監視オブジェクトの状態が変わります。

APサーバ
アプリケーションサーバの監視グループです。Webサーバ以外を監視するオブジェクトは，このノード下に配置されます。

J2EEサーバ<論理サーバ名>監視
J2EEサーバまたはバッチサーバの障害監視オブジェクトです（バッチサーバの場合も「J2EEサーバ」と表示されます）。
J2EEアプリケーションが稼働しているJ2EEサーバの表示名，またはバッチサーバの表示名が表示されます。
該当するJ2EEサーバまたはバッチサーバで障害が発生すると，この監視オブジェクトの状態が変わります。なお，J2EEサーバの場合，該当するJ2EEアプリケーションが1ホスト内の複数のJ2EEサーバに配置されている場合，この監視オブジェクトは複数生成されます。

ネーミングサービス<論理サーバ名>監視※3
ネーミングサービスの障害監視オブジェクトです。J2EEサーバに関連するネーミングサービスの表示名が表示されます。
該当するネーミングサービスに障害が発生すると，この監視オブジェクトの状態が変わります。

スマートエージェント<論理サーバ名>監視※3
スマートエージェントの障害監視オブジェクトです。同じ監視グループ内のOTSやCTMに関連するスマートエージェントの表示名が表示されます。
該当するスマートエージェントに障害が発生すると，この監視オブジェクトの状態が変わります。

CTMドメインマネジャ名<論理サーバ名>監視※3
CTMドメインマネジャの障害監視オブジェクトです。J2EEサーバに関連するCTMドメインマネジャの表示名が表示されます。
該当するCTMドメインマネジャに障害が発生すると，この監視オブジェクトの状態が変わります。

CTM<論理サーバ名>監視※3
CTMの障害監視オブジェクトです。J2EEサーバに関連するCTMの表示名が表示されます。
該当するCTMに障害が発生すると，この監視オブジェクトの状態が変わります。

パフォーマンストレーサ<論理サーバ名>監視
パフォーマンストレーサの障害監視オブジェクトです。J2EEサーバに関連するパフォーマンストレーサの表示名が表示されます。
該当するパフォーマンストレーサに障害が発生すると，この監視オブジェクトの状態が変わります。

SFOサーバ<論理サーバ名>監視※3
SFOサーバの障害監視オブジェクトです。SFOサーバの表示名が表示されます。
該当するSFOサーバで障害が発生すると，この監視オブジェクトの状態が変わります。

J2EEアプリケーション監視※3
J2EEアプリケーションの監視グループです。J2EEアプリケーションを監視するオブジェクトはこのノードの下に配置されます。

<論理サーバ名><J2EEアプリケーション名>監視※3
J2EEサーバ内のJ2EEアプリケーション監視オブジェクトです。J2EEサーバのサーバ名とJ2EEアプリケーション名が表示されます。
該当するJ2EEサーバ内のJ2EEアプリケーションで障害が発生すると，この監視オブジェクトの状態が変わります。なお，この監視オブジェクトは，各J2EEサーバ内のJ2EEアプリケーションの数だけ生成されます。

ミドル
ミドル製品用の監視グループです。ミドル製品のリソースを監視するオブジェクトです。

注※1　<　>で囲まれている名称は，環境に応じて設定される名称です。

注※2　各ノードの名称は，統合スコープ上で任意の名称に変更できます。

注※3　バッチサーバの場合，該当しません。

(2)　サーバ指向ツリー

サーバ指向ツリーとは，サーバマシン（ホスト）を主体に構成されている監視ツリーです。どのホストで問題が発生しているのか，ホストの視点で障害が監視できるようになります。

サーバ指向ツリーの構成を次に示します。初期表示は，「管理ホスト<IMマネージャ>」ノードまでが展開された状態になります。なお，IM構成ホストとは，JP1/IMマネジャホストまたはエージェントホストのことです。

図21-4　サーバ指向ツリーの構成

(3)　監視ツリー自動生成の処理の流れ

監視ツリーの自動生成処理の流れについて説明します。

JP1/IM - Viewで表示した統合スコープのビューアーから監視ツリーの自動生成を実行すると，JP1/IMからJP1/Baseを介してアダプタコマンドが実行されます。アダプタコマンドとは，監視ツリーの自動生成に使用する定義情報を収集するために，JP1/Baseによって実行されるコマンドです。あらかじめJP1/Baseに登録しておく必要があります。

Cosminexusシステムに対してアダプタコマンドが実行されると，Cosminexus運用管理コマンド（mngsvrutil）が実行されます。J2EEアプリケーションを実行しているシステムでは，J2EEアプリケーションやJ2EEサーバ，Webサーバなどの構成情報が取得されます。バッチアプリケーションを実行しているシステムでは，バッチサーバ，パフォーマンストレーサなどの構成情報が取得されます。

JP1/IMでは，それぞれのアダプタコマンドによって取得された情報を基に，監視ツリーの自動生成が実行されます。

21.2.4　統合機能メニューからの運用管理ポータルの表示（Windowsの場合）

この機能はWindowsの場合だけ使用できます。

JP1/IMでは「統合機能メニュー」画面を提供しています。この画面には，JP1/IMと連携するプログラムの一覧が表示されます。それぞれのプログラムは，「統合機能メニュー」から起動できます。

JP1/IMと連携すると，Cosminexusの運用管理ポータル画面が「統合機能メニュー」画面から表示できるようになります。運用管理ポータル画面は，自動ログインを設定しているかによって，次のどちらかの画面が表示されます。

運用管理ポータルへのログイン画面
自動ログインを設定していない場合に表示されます。

運用管理ポータル
自動ログインを設定している場合に表示されます。

自動ログインの設定は，JP1/IM連携用モニタ起動設定ファイル（.mngsvrmonitorrc）で設定します。Cosminexusモニタ起動コマンドのセットアップについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。また，統合機能メニューの詳細については，マニュアル「JP1 Version 8 JP1/Integrated Management - Manager システム構築・運用ガイド」，またはマニュアル「JP1 Version 7i JP1/Integrated Manager - Console　システム構築・運用ガイド」を参照してください。

21.2.5　障害の監視の仕組み

JP1/IMの統合コンソールと統合スコープを使用して，Cosminexusシステムで発生した障害を監視します。

＜この項の構成＞

(1)　障害の監視の仕組み

(2)　運用管理ポータルの表示のされ方（Windowsの場合）

(1)　障害の監視の仕組み

統合コンソールおよび統合スコープを使用することで，Cosminexusシステム以外の要因で発生した障害も同じ画面で確認できるようになり，障害の影響範囲も特定しやすくなります。さらに，Windowsの場合は，Cosminexusシステムで発生した障害の，調査および対処をするとき，障害の内容に応じたCosminexusの運用管理ポータル画面を，統合コンソールまたは統合スコープから直接表示できます。

JP1/IMと連携して障害を監視する場合は，次の準備が必要です。

JP1/IMと連携して障害監視をするために必要な準備

Cosminexusシステムで発生する，どのようなエラーやインフォメーション情報をJP1/IMで監視したいのかを決めて，Cosminexusの運用管理ポータル（「JP1連携の設定」画面）から定義しておきます（JP1イベントのフィルタリング設定）。

Cosminexusシステムが出力するメッセージごとの重要度や，どのメッセージをJP1イベント発行対象にするかを運用方法に合わせて決定して，運用管理ポータル（論理サーバの環境設定）またはメッセージマッピング定義ファイルで設定，編集します。設定，編集は任意です。運用管理ポータル（論理サーバの環境設定）については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。メッセージマッピング定義ファイルの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

統合スコープを使用した障害監視をする場合は，監視ツリーを生成しておきます。JP1/IMの統合スコープに表示する監視ツリーは，各ホストのJP1/Baseによって収集されてJP1統合運用管理サーバに集められた情報を基に自動生成されます。
なお，統合コンソールだけを使用する場合は，監視ツリーの生成は不要です。

JP1/IMと連携した障害監視処理の流れを次の図に示します。

図21-5　JP1/IMと連携した障害監視処理の流れ

Cosminexusシステムで発生したトラブルに関する障害情報は，JP1/Baseを経由して，JP1イベントとしてJP1統合運用管理サーバのJP1/IMに通知されます。

J2EEサーバで発生したトラブルに関する障害情報は，J2EEサーバホスト内のJP1/Baseを経由してJP1統合運用管理サーバに発行されます。

J2EEサーバ以外の論理サーバ（Webサーバやネーミングサービスなど）で発生したトラブルに関する障害情報は，運用管理エージェントによってCosminexusの運用管理サーバに収集されます。その後，運用管理サーバのJP1/Baseを経由して，JP1統合運用管理サーバに発行されます。

なお，障害情報には，通知メッセージやJ2EEアプリケーションで出力されたユーザログのメッセージなども含まれます。

J2EEサーバ，バッチサーバ，またはCosminexusの運用管理サーバからJP1イベントを受け取ったJP1統合運用管理サーバのJP1/IMによって，次のような処理が実行されます。

JP1/IMの自動アクション機能を使って運用管理者への通知を設定している場合は，トラブルが発生したことが運用管理者に通知されます。

統合スコープの監視ツリーの状態が変化します。例えば，WebサーバやJ2EEサーバなど，業務に依存しない論理サーバレベルの障害の場合はすべての業務を対象にする該当論理サーバオブジェクトの状態が変化します。また，業務レベルの障害の場合は，該当するJ2EEアプリケーションの監視オブジェクトの状態が変化します。

通知を受け取った運用管理者は，統合コンソールや統合スコープから障害に対処します。
障害の影響範囲を特定したい場合は，統合スコープを確認します。統合スコープには，障害の影響範囲が明示された監視ツリーが表示されます。また，詳細な障害の内容を知りたい場合は，統合コンソールを確認します。統合コンソールには，エラーメッセージなどが表示されます。さらに，Windowsの場合，Cosminexusシステムで障害の原因究明や対策が必要なときは，Management Serverの運用管理ポータルの該当画面を表示して，調査や対策を実施します。

JP1イベントとして発行されるCosminexusシステムの障害情報を次に示します。

表21-3　JP1イベントとして発行されるCosminexusシステムの障害情報

イベントの種類
説明

Cosminexus運用管理システム JP1イベント
Management Serverが出力した通知・障害メッセージをJP1イベントに変換したものです。変換は，メッセージマッピングファイルで指定したルールに従って実行されます。
主な内容は，J2EEサーバ，バッチサーバ，Webサーバ，ネーミングサービス，CTMなどの論理サーバでプロセス停止レベルの障害が発生した時や，各サーバが起動または停止した時の通知メッセージです。
発行されるJP1イベントのIDは，00012000～0001207F（未割当てのIDあり）です。詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。
なお，Management Serverの起動中に出力されるメッセージについては，JP1イベントが発行されない場合があります。

J2EEサーバシステム JP1イベント
J2EEサーバまたはバッチサーバが出力した通知・障害メッセージをJP1イベントに変換したものです。変換は，メッセージマッピングファイルで指定したルールに従って実行されます。
発行されるJP1イベントのIDは，00012080～000120CF（未割当てのIDあり）です。詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。
なお，Management Serverの起動中に出力されるメッセージについては，JP1イベントが発行されない場合があります。

J2EEサーバユーザ JP1イベント
J2EEアプリケーションが，ユーザログ出力機能※によって出力した通知・障害メッセージをJP1イベントに変換したものです。

注※　ユーザログ出力機能については，「18.3　アプリケーションのユーザログ出力」を参照してください。

(2)　運用管理ポータルの表示のされ方（Windowsの場合）

統合コンソールまたは統合スコープからは，次のようにして運用管理ポータルの画面が表示されます。なお，統合コンソールまたは統合スコープからの，運用管理ポータル画面の表示はWindowsの場合だけできます。

ログイン方法の設定
統合コンソールまたは統合スコープから運用管理ポータルを表示する場合，自動ログインするか，ログイン画面を表示して手動ログインするかを選択できます。自動ログインをするためには，あらかじめ設定ファイル（.mngsvrmonitorrc）に管理ユーザのユーザIDとパスワードを指定しておく必要があります。ファイルの指定方法については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

論理サーバに障害が発生した場合に表示される画面
J2EEサーバ，バッチサーバ，Webサーバなどの論理サーバレベルの障害が発生した場合は，次に示す状態の「論理サーバの稼働状況」画面が表示されます。

ツリーペインには，サーバビューが表示されます。ツリーは，障害が発生した論理サーバまで展開された状態で表示されます。ただし，論理サーバを特定できない障害（一括起動操作に関する障害など）が発生している場合は，ツリーは展開されません。

ボディペインには，ツリーペインのドメインを選択した場合に表示される「論理サーバの稼働状況」画面が表示されます。

J2EEアプリケーションに障害が発生した場合に表示される画面
J2EEアプリケーションで障害が発生した場合は，次に示す状態の「論理サーバのアプリケーション管理」画面が表示されます。

ツリーペインのツリーは，障害が発生したJ2EEアプリケーションが稼働しているJ2EEサーバまで展開された状態で表示されます。

ボディペインには，J2EEサーバ下のアプリケーションを選択した場合に表示される「J2EEアプリケーションの開始／停止」画面が表示されます。

そのほかの障害が発生した場合に表示される画面
Management Serverの障害など，サーバやJ2EEアプリケーション以外の障害が発生した場合は，「運用管理ポータル」画面が表示されます。

21.3　システムの構成定義および管理（JP1/IM - CMとの連携）

システムの構成定義および管理では，システム構築時にシステム構成を定義したり，定義したシステムについて，リソースやシステム構成に関する情報を集約して管理したりします。JP1/IMと連携することで実現します。

JP1/IMでシステムの構成定義および管理をするには，JP1/IM - CMを利用します。JP1/IM - CMは，業務システムをユーザの視点で運用管理することを目的として，システム構成を定義したり，定義した構成情報を管理したりするためのプログラムです。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。

JP1/IM - CMと連携できるのは，Cosminexusで提供するSmart Composer機能を使用してシステムを構築する場合だけです。Smart Composer機能については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

また，JP1/IM - CMは，JP1/IM - Manager（JP1 Version 8の場合）またはJP1/IM - Central Console（JP1 Version 7iの場合），およびJP1/IM - Viewの使用が前提となります。JP1/IM - ManagerまたはJP1/IM - Central Console，およびJP1/IM - Viewについては，「21.2　システムの集中監視（JP1/IMとの連携）」を参照してください。

JP1/IM - CMの詳細については，マニュアル「JP1 Version 8 JP1/Integrated Management - Central Information Master システム構築・運用ガイド」，またはマニュアル「JP1 Version 7i JP1/Integrated Manager - Central Information Master　システム構築・運用ガイド」を参照してください。

＜この節の構成＞

21.3.1　システムの構成定義および管理の概要

21.3.2　システムの構成定義および管理に必要なプログラム

21.3.3　Smart Composer機能でのWebシステム構築

21.3.4　Webシステムの構成情報の収集

21.3.1　システムの構成定義および管理の概要

Smart Composer機能を使用してシステムを構築する場合，JP1/IM - CMと連携できます。JP1/IM - CMを使用すると，システム構成を，GUIを使用してビジュアルに定義できます。JP1/IM - CMで定義したシステムの構成情報は，JP1/IM - CMのエクスポート機能を使用することで，Smart Composer機能で使用するXMLファイルとして出力できます。

JP1/IM - CMを使用したシステムの構成定義および管理の概要を次に示します。

図21-6　JP1/IM - CMを使用したシステムの構成定義および管理の概要

JP1統合運用管理サーバにインストールされたJP1/IM - CMを使用して，構築するシステムの構成を定義します。定義したシステム構成情報は，JP1/IM - CMで管理されます。Smart Composer機能でWebシステムを構築するときには，JP1/IM - CMで定義した構成情報をファイルに出力して利用します。

21.3.2　システムの構成定義および管理に必要なプログラム

システムの構成定義および管理は，JP1/IMを中心としたJP1のプログラム群と，Cosminexusの運用管理機能を組み合わせて実現します。

JP1/IM - CMと連携してシステムの構成定義および管理をする場合のシステム構成例を次の図に示します。

図21-7　JP1/IM - CMと連携してシステムの構成定義および管理をする場合のシステム構成例

JP1の各プログラムの主な機能を次に示します。なお，Cosminexusの運用管理機能については，「17.　システムの日常運用」を参照してください。

表21-4　システムの構成定義および管理をするために使用するJP1プログラムの機能

JP1プログラム
機能
配置するサーバ／
クライアント

JP1/Base
JP1/IMの基盤機能を提供します。JP1イベントの送受信などをするほか，JP1/IMシステムのエージェントとして機能します。

Cosminexusの運用管理サーバ

JP1統合運用管理サーバ

JP1/IM - Central Console※
統合コンソールです。

JP1統合運用管理サーバ

JP1/IM - CM
システム構成に関する情報を定義したり，管理したりする機能を提供します。

JP1統合運用管理サーバ

JP1/Cm2/NC - Manager
負荷分散機から構成情報を取得して，取得した構成情報を一元管理します。

Cosminexusの運用管理サーバ

JP1/Cm2/NC - Manager for Cosminexus
JP1とCosminexusが連携して，Cosminexusから負荷分散機を制御する機能を提供します。

Cosminexusの運用管理サーバ

JP1/IM - View
ビューアーです。

運用管理クライアント

注※　JP1 Version 8の場合，JP1/IM - Managerの内部コンポーネントとして提供されています。

21.3.3　Smart Composer機能でのWebシステム構築

JP1/IM - CMと連携すると，Smart Composer機能でのシステム構築時に，GUIを使用してビジュアルにシステム構成を定義できます。また，JP1/IM - CMでは，定義した構成情報をXML形式のファイルでエクスポートできます。出力したXMLファイルは，Smart Composer機能で使用する簡易構築定義ファイルとして利用できます。簡易構築定義ファイルとは，Webシステムの構成について定義したファイルです。JP1/IM - CMとの連携で，Smart Composer機能を使用したシステム構築がより簡単になります。

JP1/IM - CMとSmart Composer機能を使用したシステム構築の流れを次の図に示します。

図21-8　JP1/IM - CMとSmart Composer機能を使用したシステム構築の流れ

JP1/IM - CMでシステムの構成を定義します。
Cosminexus用のシステム構成を定義する方法については，マニュアル「JP1 Version 8 JP1/Integrated Management - Central Information Master システム構築・運用ガイド」，またはマニュアル「JP1 Version 7i JP1/Integrated Manager - Central Information Master　システム構築・運用ガイド」を参照してください。

JP1/IM - CMのエクスポート機能を使用して，Cosminexus Smart Composer用ファイルを出力します。
JP1/IM - CMのコマンドを使用して，定義情報をXML形式のファイルでエクスポートします。出力したCosminexus Smart Composer用ファイルは，Smart Composer機能の簡易構築定義ファイルとしてそのまま利用できます。

Smart Composer機能で提供するコマンドを使用して，システムを構築します。
Smart Composer機能で提供するコマンドを使用して，次の操作を実施します。

JP1/IM - CMで出力したCosminexus Smart Composer用ファイル（以降，簡易構築定義ファイル）に，抽象パラメタを展開します。

抽象パラメタ展開済みの簡易構築定義ファイルの情報から，Cosminexusの運用管理サーバ上のManagement ServerにWebシステムの情報モデルを生成します。

Management Server上の情報モデルを基にWebシステムを構築します。

WebシステムにJ2EEアプリケーションおよびDB Connectorをデプロイします。

Smart Composer機能で提供するコマンドやSmart Composer機能を使用したシステムの構築方法については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

21.3.4　Webシステムの構成情報の収集

JP1/IM - CMでは，定義したシステムの構成情報を管理します。Smart Composer機能を使用してシステム構成を変更すると，Management Serverでは，JP1/IM - CMで管理する構成情報との整合性を保つため，システムの構成変更を自動通知するJP1イベントを発行します。これによって，JP1/IM - CMでは常に最新のシステム構成を管理できるようになります。

Webシステムの構成変更時の情報収集について，次の図に示します。この図では，サービスユニット2をスケールアウトしたときの構成変更情報の収集を例にしています。

図21-9　Webシステムの構成変更時の情報収集

Smart Composer機能のコマンドを使用して，サービスユニット2を追加して，Webシステムをスケールアウトします。

1.のコマンド実行によって，JP1統合運用管理サーバにJP1イベントが発行されます。
Smart Composer機能のサービスユニット追加コマンドの実行が契機になって，Management ServerからJP1統合運用管理サーバに対して，Webシステムの構成変更が自動通知されます。

ユーザは2.のJP1イベントの発行を受けて，JP1/IM - CMで管理しているWebシステムの構成情報を収集します。

Management Serverは，Smart Composer機能で構築したWebシステムの最新の構成情報を返します。

21.4　ジョブによるシステムの自動運転（JP1/AJS2との連携）

システムの自動運転は，サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図る運用方法です。JP1/AJS2と連携することでジョブによるシステムの自動運転が実現できます。

JP1/AJS2は，日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するためのプログラム群です。JP1/AJS2では，システム運用の各作業を，ジョブとして扱います。ジョブは，コマンド，シェルスクリプト，バッチファイルなどの集まりに対応します。また，ジョブの実行順序を関連づけたものを，ジョブネットといいます。

JP1/AJS2は，次の3種類のプログラムで構成されています。

JP1/AJS2 - Manager
ジョブネットやスケジュールの定義を保存して，ジョブネットの実行を管理するプログラムです。ジョブの実行時には，実行するジョブをJP1/AJS2 - Agentに転送し，実行状況，実行結果の情報を受け取ります。エージェントとしてジョブの実行もできます。

JP1/AJS2 - Agent
ジョブを実行するためのプログラムです。JP1/AJS2 - Managerから転送されたジョブを実行します。

JP1/AJS2 - View
GUIを使ってJP1/AJS2を操作するためのプログラムです。JP1/AJS2 - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

JP1/AJS2の詳細については，マニュアル「JP1/Automatic Job Management System 2 解説」を参照してください。

また，シナリオによるJP1/AJS2 - SOと連携したシステムの自動運転については，「21.5　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）」を参照してください。

＜この節の構成＞

21.4.1　ジョブによるシステムの自動運転の概要

21.4.2　ジョブによるシステムの自動運転に必要なプログラム

21.4.3　カスタムジョブによるジョブの定義（Windowsの場合）

21.4.4　論理サーバおよびJ2EEアプリケーションの起動と停止の自動化の仕組み

21.4.1　ジョブによるシステムの自動運転の概要

JP1/AJS2と連携してシステムを自動運転すると，Cosminexusシステム内の論理サーバおよびJ2EEアプリケーションの計画的な一括開始や一括停止ができるようになります。夜間に実行するバッチ処理，曜日によって異なる業務の切り替え，月末だけに実行する業務などをあらかじめスケジュール定義しておくことで，システムリソースを計画的に確保して，有効活用できるようになります。

＜この項の構成＞

(1)　JP1/AJS2を使用したシステムの自動運転

(2)　JP1/AJS2を使用したバッチアプリケーションの自動実行

(1)　JP1/AJS2を使用したシステムの自動運転

JP1/AJS2を使用したシステムの自動運転を次に示します。

図21-10　JP1/AJS2を使用したシステムの自動運転の概要

Cosminexusシステムの運用を自動化するためには，まず，J2EEアプリケーションの開始や停止などの処理の一つ一つをジョブとして定義して，それらの実行順序をジョブネットとして定義します。Cosminexusシステムの場合，ジョブとして，Management Serverのコマンドであるmngsvrutilコマンドを1実行単位で定義します。次に，運用計画に従って，ジョブネットごとに開始曜日や時刻などのスケジュールを設定して，JP1ジョブ運用管理サーバのJP1/AJS2に登録します。例えば，WebサーバとJ2EEアプリケーション「AP1」「AP2」の起動と停止を，それぞれAM8:00とPM5:00に定義します。設定した時刻になると，JP1/AJS2によって，ジョブとして定義したmngsvrutilコマンドが実行されます。

また，JP1/IMと連携しておけば，JP1/AJS2によって自動実行されたジョブに異常が発生した場合に，運用管理者の携帯電話などに通知する運用もできます。

なお，Windowsの場合，Cosminexusでは，このような運用を実現するために，カスタムジョブの提供による，ジョブ定義支援機能を提供しています。

(2)　JP1/AJS2を使用したバッチアプリケーションの自動実行

バッチアプリケーションは，Cosminexusで構築するバッチサーバ上でも実行できます。バッチサーバで動作するバッチアプリケーションは，Cosminexusで提供するバッチ実行コマンドで開始します。バッチ実行コマンドをJP1/AJS2のジョブとして定義することで，バッチアプリケーションの自動実行が実現します。

JP1/AJS2を使用したバッチアプリケーションの自動実行を次の図に示します。

図21-11　JP1/AJS2を使用したバッチアプリケーションの自動実行の概要

また，JP1/AJS2では，BJEXと連携することもできます。BJEXと連携する場合は，JP1/AJS2のジョブとして，BJEXのバッチジョブの実行コマンドを定義する必要があります。ジョブの定義については，「15.1　バッチアプリケーションの実行方法」を参照してください。

21.4.2　ジョブによるシステムの自動運転に必要なプログラム

システムの自動運転は，JP1/AJS2を中心としたJP1のプログラム群と，Cosminexusの運用管理機能を組み合わせて実現します。

JP1/AJS2と連携してシステムの自動運転をする場合のシステム構築例を，J2EEサーバの場合とバッチサーバの場合に分けて説明します。

＜この項の構成＞

(1)　J2EEサーバの場合

(2)　バッチサーバの場合

(1)　J2EEサーバの場合

J2EEアプリケーション実行環境で，システムを自動運転する場合のシステムの構成例を次の図に示します。

図21-12　JP1/AJS2と連携してシステムの自動運転をする場合のシステム構築例（J2EEサーバの場合）

それぞれの図中のJP1の各プログラムの主な機能を次に示します。なお，Cosminexusの管理機能については，「17.　システムの日常運用」を参照してください。

表21-5　システムの自動運転をするために使用するJP1プログラムの機能（J2EEサーバの場合）

JP1プログラム
機能
配置するサーバ／
クライアント

JP1/Base
JP1/AJS2の基盤機能を提供します。ユーザ権限の管理やJP1イベントの送受信をします。

Cosminexusの運用管理サーバ

JP1ジョブ運用管理サーバ

JP1/AJS2 - Agent
JP1/AJS2のエージェントです。JP1/AJS2 - Managerから転送されたジョブを実行します。

Cosminexusの運用管理サーバ

JP1/AJS2 - Manager
JP1/AJS2のマネジャです。

JP1ジョブ運用管理サーバ

JP1/AJS2 - View
GUIを使ってJP1/AJS2を操作するための画面を提供します。JP1/AJS2 - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

運用管理クライアント

(2)　バッチサーバの場合

バッチアプリケーション実行環境で，システムを自動運転する場合のシステムの構成例を次の図に示します。

図21-13　JP1/AJS2と連携してシステムの自動運転をする場合のシステム構築例（バッチサーバの場合）

それぞれの図中のJP1の各プログラムの主な機能を次に示します。なお，Cosminexusの管理機能については，「17.　システムの日常運用」を参照してください。

表21-6　システムの自動運転をするために使用するJP1プログラムの機能（バッチサーバの場合）

JP1プログラム
機能
配置するサーバ／
クライアント

JP1/Base
JP1/AJS2の基盤機能を提供します。ユーザ権限の管理やJP1イベントの送受信をします。

バッチサーバ

JP1ジョブ運用管理サーバ

JP1/AJS2 - Agent
JP1/AJS2のエージェントです。JP1/AJS2 - Managerから転送されたジョブを実行します。

バッチサーバ

JP1/AJS2 - Manager
JP1/AJS2のマネジャです。

JP1ジョブ運用管理サーバ

JP1/AJS2 - View
GUIを使ってJP1/AJS2を操作するための画面を提供します。JP1/AJS2 - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

運用管理クライアント

BJEXと連携する場合は，BJEXをバッチサーバに配置してください。なお，BJEXはAIXの場合だけ使用できます。

21.4.3　カスタムジョブによるジョブの定義（Windowsの場合）

JP1/AJS2では，運用に使用するコマンド，バッチファイルなどをジョブとして定義して，それぞれのジョブの実行順序を関連づけることで，システム運用を自動化します。

Windowsの場合，ジョブを定義する際にカスタムジョブを使用すると，直接コマンドやバッチファイルをジョブに指定するのに比べて，容易，かつ間違いなく定義できます。

カスタムジョブとは，JP1/AJS2以外のプログラムとJP1/AJS2が連携するジョブを定義する場合に，目的のジョブを容易に作成するために使用できるジョブのテンプレートです。

Cosminexusでは，次の2種類のカスタムジョブを提供しています。

論理サーバ制御用カスタムジョブ

アプリケーション制御用カスタムジョブ

これらのカスタムジョブを使用すると，GUI操作でCosminexus用のジョブが定義できます。

Cosminexusが提供するカスタムジョブによるシステムの自動運転の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。また，カスタムジョブを定義する場合のJP1/AJS2 - Viewの操作方法については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

なお，カスタムジョブはWindowsの場合だけ使用できます。このため，UNIXの場合は，JP1/AJS2 - Viewで，運用に使用するコマンドやバッチファイルなどを，ジョブとして定義する必要があります。ジョブの定義方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　論理サーバ制御用カスタムジョブ

(2)　アプリケーション制御用カスタムジョブ

(1)　論理サーバ制御用カスタムジョブ

論理サーバの起動，停止を制御するジョブを定義するためのカスタムジョブです。監視時間の設定もできます。起動できる論理サーバは，次のとおりです。

パフォーマンストレーサ

スマートエージェント

ネーミングサービス

CTMドメインマネジャ

CTM

J2EEサーバ

バッチサーバ

Webサーバ

(2)　アプリケーション制御用カスタムジョブ

J2EEアプリケーション，バッチアプリケーション，およびJ2EEリソースアダプタの起動，停止を制御するジョブを定義するためのカスタムジョブです。監視時間の設定もできます。

21.4.4　論理サーバおよびJ2EEアプリケーションの起動と停止の自動化の仕組み

JP1/AJS2で定義したジョブおよびジョブネットを使用して，論理サーバとJ2EEアプリケーションの起動と停止の運用を自動化します。

自動化した場合の処理の流れを次の図に示します。

図21-14　論理サーバおよびJ2EEアプリケーションの起動と停止を自動化した場合の処理の流れ

ジョブネットで設定した時間になると，ジョブに定義した論理サーバやJ2EEアプリケーションの起動または停止を実行するためのコマンドとパラメタが，JP1/AJS2 - Managerから各ホストのJP1/AJS2 - Agentに送信されます。

ジョブの実行指示を受け取ったJP1/AJS2 - Agentは，ジョブに定義されていたCosminexusの運用管理コマンド（mngsvrutil）を実行して，Management Serverに処理を要求します。なお，JP1/AJS2 - Agentの処理は，要求が完了したところで終了します。

Management Serverは，各ホストの運用管理エージェントに対して，処理の実行を要求します。

運用管理エージェントによって，要求された処理が実行されます。

Cosminexus運用管理コマンド（mngsvrutil）の機能については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

21.5　シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）

システムの自動運転は，サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図る運用方法です。JP1/AJS2 - SOと連携することで，シナリオによるシステムの自動運転が実現できます。

JP1/AJS2 - SOは，運用環境に合わせたジョブを展開するためのシナリオテンプレートを作成するためのプログラムです。シナリオテンプレートは，JP1/AJS2のカスタムジョブをより汎用化したものです。

シナリオによるシステムの自動運転をする場合は，Smart Composer機能を使用して構築したシステムが前提となります。Cosminexusでは，Smart Composer機能で使用するためのシナリオテンプレートを提供しています。シナリオテンプレートを組み合わせることで，Smart Composer機能を使用して構築したシステムの自動運転を定義できます。

なお，ジョブによるJP1/AJS2と連携したシステムの自動運転については，「21.4　ジョブによるシステムの自動運転（JP1/AJS2との連携）」を参照してください。

＜この節の構成＞

21.5.1　シナリオによるシステムの自動運転の概要

21.5.2　シナリオによるシステムの自動運転に必要なプログラム

21.5.3　シナリオテンプレートによるシナリオの定義

21.5.1　シナリオによるシステムの自動運転の概要

Cosminexusでは，Smart Composer機能のコマンドを定義したシナリオテンプレートを提供しています。JP1/AJS2 - SOでは，シナリオテンプレートを組み合わせて，システムを自動運転するためのシナリオを作成します。

Cosminexusで提供するシナリオテンプレートでは，例えば，次のような運用ができます。

Webシステムの計画的な一括起動および一括停止
Webシステムを決まった時間に一括起動したり，一括停止したりする，日常運用ができます。

サービスユニット内のJ2EEアプリケーションやリソースアダプタの更新
Webシステムのメンテナンスなどの場合に，J2EEアプリケーションやリソースアダプタを更新できます。

Webシステムのスケールアウトおよびスケールイン
Webシステムのスケールアウトとは，システム全体の処理性能を向上させるためにサーバの台数を増やすことをいいます。また，Webシステムのスケールインとは，システムの規模を縮小するためにサーバの台数を減らすことをいいます。スケールアウトによってWebシステムにサービスユニットを追加したり，スケールインによってWebシステムからサービスユニットを削除したりできます。

21.5.2　シナリオによるシステムの自動運転に必要なプログラム

シナリオによるシステムの自動運転は，JP1/AJS2およびJP1/AJS2 - SOを中心としたJP1のプログラム群と，Cosminexusの運用管理機能を組み合わせて実現します。

JP1/AJS2およびJP1/AJS2 - SOと連携してシステムの自動運転をする場合のシステム構築例を次の図に示します。

図21-15　JP1/AJS2およびJP1/AJS2 - SOと連携してシステムの自動運転をする場合のシステム構築例

JP1の各プログラムの主な機能を次に示します。なお，Cosminexusの管理機能については，「17.　システムの日常運用」を参照してください。

表21-7　シナリオによるシステムの自動運転をするために使用するJP1プログラムの機能

JP1プログラム
機能
配置するサーバ／
クライアント

JP1/Base
JP1/AJS2の基盤機能を提供します。ユーザ権限の管理やJP1イベントの送受信をします。

アプリケーションサーバ

Cosminexusの運用管理サーバ

JP1ジョブ運用管理サーバ

JP1/AJS2 - Agent
JP1/AJS2のエージェントです。JP1/AJS2 - Managerから転送されたジョブを実行します。

Cosminexusの運用管理サーバ

JP1/AJS2 - Manager
JP1/AJS2のマネジャです。

JP1ジョブ運用管理サーバ

JP1/AJS2 - View
GUIを使ってJP1/AJS2を操作するための画面を提供します。JP1/AJS2 - Managerに接続して，ジョブネットの定義や操作，実行状況や結果の表示などをします。

運用管理クライアント

JP1/AJS2 - SO Manager
シナリオテンプレートやシナリオの定義を保存します。JP1/AJS2 - Managerと接続してシナリオをJP1/AJS2のジョブネットとして登録します。

JP1ジョブ運用管理サーバ

JP1/AJS2 - SO View
GUIを使ってJP1/AJS2 - SOを操作するための画面を提供します。JP1/AJS2 - SO Managerに接続して，シナリオテンプレートやシナリオの定義・操作，シナリオの監視などをします。

運用管理クライアント

21.5.3　シナリオテンプレートによるシナリオの定義

JP1/AJS2 - SOでは，運用手順をコマンドなどの機能的な概念で定型化したシナリオテンプレートを作成します。Cosminexusでは，Webシステムの自動運転を実現するために，Smart Composer機能のコマンドを定義したシナリオテンプレートを提供しています。シナリオテンプレートを利用して，JP1/AJS2 - SOでシナリオを作成することで，Webシステム全体の運用を自動化します。

シナリオは，シナリオテンプレートを組み合わせて作成します。シナリオの作成方法については，マニュアル「JP1/Automatic Job Management System 2 - Scenario Operation」を参照してください。

なお，Cosminexusのシナリオテンプレートを使用するには，シナリオテンプレート定義ファイルをJP1/AJS2 - SOに組み込む必要があります。組み込みについては，マニュアル「JP1/Automatic Job Management System 2 - Scenario Operation」を参照してください。Cosminexus用のシナリオテンプレート定義ファイルについては，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

21.6　監査ログの収集および一元管理（JP1/NETM/Auditとの連携）

JP1/NETM/Auditを使用して，Cosminexusのアプリケーションサーバ，運用管理サーバ，連携する日立オープンミドルウェア製品などが出力した監査ログを自動で収集できます。また，JP1/NETM/Auditに組み込まれているデータベースを使用して，収集した監査ログを一元管理できます。

＜この節の構成＞

21.6.1　監査ログの収集および一元管理の概要

21.6.2　監査ログの収集および一元管理に必要なプログラム

21.6.1　監査ログの収集および一元管理の概要

ここでは，JP1/NETM/Auditを使用した監査ログの収集，および一元管理の概要を説明します。JP1/NETM/Auditを使用した監査ログの収集，および一元管理の例を次の図に示します。

図21-16　JP1/NETM/Auditを使用した監査ログの収集・一元管理の例

この例では，複数のアプリケーションサーバと運用管理サーバがそれぞれのローカルディスクに出力した監査ログを，監査ログ管理サーバで自動収集しています。また，監査ログ管理サーバに収集された監査ログを，監査ログ管理サーバが提供するデータベースで一元管理しています。監査ログの収集，および一元管理の概要を次に示します。

監査ログの収集

監査ログを収集するサーバを，監査ログ管理サーバといいます。JP1/NETM/Auditを使用すると，それぞれのアプリケーションサーバで出力された監査ログを，監査ログ管理サーバで自動収集できます。収集された監査ログは，監査ログ管理サーバのデータベースで一元管理されます。

監査ログは，次のタイミングで自動収集されます。

指定した日時に定期的に収集

イベントデータベースの切り替え時に自動収集

それぞれの収集方法の詳細については，マニュアル「JP1/NETM/Audit」を参照してください。

監査ログの一元管理

JP1/NETM/Auditは，監査ログを一元管理するデータベースを提供します。このデータベースを，監査ログ管理データベースといいます。監査ログ管理データベースを使用して収集した監査ログを一元管理すると，収集した監査ログの検索，集計，結果の出力などができるようになります。

JP1/NETM/Auditを使用した監査ログの一元管理の詳細は，マニュアル「JP1/NETM/Audit」を参照してください。

21.6.2　監査ログの収集および一元管理に必要なプログラム

監査ログの収集および一元管理は，JP1/NETM/Auditを中心としたJP1のプログラム群とCosminexusで実現します。JP1/NETM/Auditと連携して監査ログの収集および一元管理をする場合のシステム構成例を次に示します。

図21-17　JP1/NETM/Auditと連携して監査ログの収集および一元管理をする場合のシステム構成例

JP1の各プログラムの主な機能を次に示します。

表21-8　監査ログの収集および一元管理をするために使用するJP1プログラムの機能

JP1プログラム
機能
配置するサーバ

JP1/NETM/Audit
JP1/Baseと連携して，アプリケーションサーバが出力する監査ログを収集します。また，収集した監査ログを監査ログ管理サーバのデータベースで一元管理します。

監査ログ管理サーバ

JP1/Base
出力された監査ログを，JP1イベントとして送受信します。

監査ログ管理サーバ

アプリケーションサーバ

運用管理サーバ

22.　クラスタソフトウェアと連携したシステムの運用

この章では，クラスタソフトウェアと連携したシステムの運用について説明します。

Cosminexusでは，Microsoft Cluster ServiceまたはHAモニタと連携したシステムの運用をサポートしています。

なお，クラスタソフトウェアについては，Microsoft Cluster Serviceのマニュアル，またはマニュアル「高信頼化システム監視機能　HAモニタ」もあわせて参照してください。

＜この章の構成＞

22.1　クラスタソフトウェアと連携して実現できる運用

22.2　クラスタソフトウェアと連携するための前提条件

22.3　実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）

22.4　相互スタンバイで運用するシステム（相互系切り替えシステム）

22.5　待機系をリカバリ専用サーバとして運用するシステム（N:1リカバリシステム）

22.1　クラスタソフトウェアと連携して実現できる運用

クラスタソフトウェアとは，システムの信頼性および稼働率の向上を目的とした，サーバプログラムを含めたシステムの切り替えを実現するプログラムです。Cosminexusでは，次に示すクラスタソフトウェアと連携できます。

Microsoft Cluster Service
Windowsの場合に使用するクラスタソフトウェアです。使用できるOSは次のとおりです。

Windows Server 2003 Enterprise Edition

Windows Server 2003 R2 Enterprise Edition

Windows Server 2003 Enterprise x64 Edition

Windows Server 2003 R2 Enterprise x64 Edition

HAモニタ
AIX・HP-UX・Linuxの場合に使用するクラスタソフトウェアです。

なお，Solarisの場合，クラスタソフトウェアと連携したシステム運用はできません。

クラスタソフトウェアと連携してCosminexusシステムを運用することで，アプリケーションサーバに障害が発生した場合に，直ちに自動でアプリケーションサーバを切り替えたり，待機しているリカバリサーバで，障害が発生したアプリケーションサーバのリカバリ処理をしたりできます。また，運用管理サーバに障害が発生した場合にも，待機させておいた運用管理サーバに切り替えることができます。これによって，システムの不稼働時間を短縮でき，信頼性や稼働率を高めることができます。

Cosminexusではクラスタソフトウェアと連携することによって，次に示す系切り替え構成でシステムを運用できます。

J2EEアプリケーションの実行環境の場合

実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）

相互スタンバイで運用するシステム（相互系切り替えシステム）

待機系をリカバリ専用サーバとして運用するシステム（N:1リカバリシステム）

バッチアプリケーションの実行環境の場合

実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）※

相互スタンバイで運用するシステム（相互系切り替えシステム）

注※　アプリケーションサーバの系切り替えだけ使用できます。

それぞれのシステムの概要について以降の項で説明します。

ポイント

クラスタソフトウェアでは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器を含めたシステム全体の総称を系といいます。システム動作中の系を区別する呼び方に，実行系・待機系があります。

実行系
現在実行中のサーバがある系のことです。系切り替えが発生すると，待機系になります。

待機系
現在待機中のサーバがある系のことです。系切り替えが発生すると，実行系になります。

また，システムの設定などで，システムが動作していないときの系を区別する呼び方に，現用系・予備系があります。

現用系
起動したときに，最初に実行系として起動される系のことです。

予備系
起動したときに，最初に待機系として起動される系のことです。

＜この節の構成＞

22.1.1　実行系と待機系を1:1で運用するシステムとは（1:1系切り替えシステム）

22.1.2　相互スタンバイで運用するシステムとは（相互系切り替えシステム）

22.1.3　待機系をリカバリ専用サーバとして運用するシステムとは（N:1リカバリシステム）

22.1.1　実行系と待機系を1:1で運用するシステムとは（1:1系切り替えシステム）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。Cosminexusでは，アプリケーションサーバの1:1系切り替えシステムでの運用と，運用管理サーバの1:1系切り替えシステムでの運用をサポートしています。ただし，バッチアプリケーションの実行環境では，運用管理サーバを配置しないため，運用管理サーバの1:1系切り替えシステムの運用はできません。

1:1系切り替えシステムでは，実行系に何らかの障害が発生すると，クラスタソフトウェアがこれを検知して，自動的に待機している系に切り替えて業務を続行します。また，障害が発生しなくても実行中のシステムに予防保守，その他必要があるときには，オペレータの操作によって待機している系に計画的に切り替えることができます。

1:1系切り替えシステムの詳細については，「22.3　実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）」を参照してください。

22.1.2　相互スタンバイで運用するシステムとは（相互系切り替えシステム）

相互系切り替えシステムとは，1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。Cosminexusでは，アプリケーションサーバの相互切り替えシステムでの運用をサポートしています。

相互系切り替えシステムでは，各サーバでそれぞれJ2EEアプリケーションまたはバッチアプリケーションを動作させて，障害が発生した場合は自動的に相互の待機している系に切り替えて業務を続行します。また，1:1系切り替えシステムの場合と同様に，障害が発生しなくても実行中のシステムに予防保守，その他必要があるときには，オペレータの操作によって待機している系に計画的に切り替えることができます。

相互系切り替えシステムの詳細については，「22.4　相互スタンバイで運用するシステム（相互系切り替えシステム）」を参照してください。

22.1.3　待機系をリカバリ専用サーバとして運用するシステムとは（N:1リカバリシステム）

N:1リカバリシステムとは，クラスタ構成になっている実行系の複数（N台）のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。

業務は，実行系のアプリケーションサーバで実行します。業務実行中のアプリケーションサーバに障害が発生すると，リカバリ専用サーバで，障害が発生したアプリケーションサーバの仕掛かり中のトランザクションを決着します。

なお，バッチサーバの場合，N:1リカバリシステムは使用できません。

N:1リカバリシステムの詳細については，「22.5　待機系をリカバリ専用サーバとして運用するシステム（N:1リカバリシステム）」を参照してください。

22.2　クラスタソフトウェアと連携するための前提条件

クラスタソフトウェアと連携してシステムを運用するための前提条件について説明します。

＜この節の構成＞

22.2.1　系切り替えの管理対象となるサーバ

22.2.2　ライトトランザクション機能の利用

22.2.3　システムの運用方法

22.2.4　実行系の前提条件

22.2.5　待機系の前提条件

22.2.1　系切り替えの管理対象となるサーバ

クラスタソフトウェアと連携してCosminexusシステムを運用する場合に，系切り替えの管理対象となるサーバを次の表に示します。

表22-1　系切り替えの管理対象となるサーバ

系切り替えの種類 | 系切り替えの管理対象となるサーバ
1:1系切り替えシステム | アプリケーションサーバ，運用管理サーバ
相互系切り替えシステム | アプリケーションサーバ
N:1系切り替えシステム | アプリケーションサーバ

なお，クラスタソフトウェアと連携してシステムを運用する場合のシステム構成については，「22.3.1　1:1系切り替えシステムのシステム構成例」，「22.4.1　相互系切り替えシステムのシステム構成例」または「22.5.1　N:1リカバリシステムのシステム構成例」を参照してください。

22.2.2　ライトトランザクション機能の利用

クラスタソフトウェアと連携する場合，ライトトランザクション機能を有効にしているかどうかによって，使用できる系切り替えの種類が異なります。系切り替えの種類とライトトランザクション機能の利用について次の表に示します。なお，実行系と待機系は，同じ動作モードにすることが前提となります。

表22-2　系切り替えの種類とライトトランザクション機能の利用

系切り替えの種類 | ライトトランザクション
有効 | 無効
1:1系切り替えシステム | ○ | ○
相互系切り替えシステム | ○ | ○
N:1系切り替えシステム | × | ○

（凡例）　○：使用できる　　×：使用できない

なお，バッチアプリケーション実行環境の場合，ライトトランザクション機能を有効にするため，N:1系切り替えシステムは使用できません。

22.2.3　システムの運用方法

クラスタソフトウェアと連携する場合，系切り替えの種類にかかわらず，Management Serverを利用してCosminexusシステムを運用することが前提となります。

クラスタソフトウェアと連携する場合の設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

参考

アプリケーションサーバの1:1系切り替えシステムの場合，クラスタソフトウェアは，運用管理エージェント（Cosminexusシステムを管理するプロセス）を監視します。

運用管理サーバの1:1系切り替えシステムの場合，クラスタソフトウェアは，Management Serverを監視します。

22.2.4　実行系の前提条件

N:1系切り替えシステムの場合，実行系アプリケーションサーバは次に示す前提条件を満たしている必要があります。なお，1:1系切り替えシステム，および相互系切り替えシステムの場合，実行系に前提条件はありません。

グローバルトランザクションを使用します。

CORBAネーミングサービスおよびトランザクションサービスは，インプロセスで使用します。

トランザクションサービスのステータスファイルは共用ディスク装置のディレクトリに格納します。

22.2.5　待機系の前提条件

待機系の前提条件を次に示します。

なお，クラスタソフトウェアと連携してCosminexusシステムを運用する場合，待機系はコールドスタンバイで系切り替えを待ちます。コールドスタンバイとは，系切り替えが発生したあとに待機系のサーバが起動する方法です。

＜この項の構成＞

(1)　1:1系切り替えシステム・相互系切り替えシステムの場合

(2)　N:1系切り替えシステムの場合

(1)　1:1系切り替えシステム・相互系切り替えシステムの場合

1:1系切り替えシステム，および相互系切り替えシステムの場合，待機系のアプリケーションサーバではCosminexus関連のプロセスは起動できません。このため，次の操作ができないので注意してください。

J2EEサーバへのアプリケーションのデプロイおよびアンデプロイ
J2EEアプリケーションの入れ替えも含みます。

Management Serverおよび運用管理エージェントによる管理操作

また，待機系のアプリケーションサーバからは共用ディスク装置へのアクセスはできません。J2EEサーバを使用している場合でグローバルトランザクションのとき，共用ディスク装置にはトランザクションサービスなどの定義情報が保持されます。ただし，待機系のアプリケーションサーバからこの定義情報を変更することはできません。

(2)　N:1系切り替えシステムの場合

N:1リカバリシステムの場合，待機系はリカバリ専用サーバとなります。待機系のリカバリ専用サーバの前提条件を次に示します。

グローバルトランザクションを使用します。

CORBAネーミングサービスおよびトランザクションサービスはインプロセスで動作させます。

実行系のアプリケーションサーバ上のJ2EEサーバと同じ名称のJ2EEサーバが，待機系のリカバリ専用サーバ上で動作している必要があります。

実行系のアプリケーションサーバで使用しているリソースアダプタと同じ設定のリソースアダプタをインポートし，デプロイ，開始しておきます。なお，リカバリ専用サーバには実行系で使用しているリソースアダプタをすべてインポートする必要があります。

リカバリ専用サーバは，障害が発生したアプリケーションサーバのトランザクションを決着するために使用するサーバであるため，J2EEアプリケーションをデプロイする必要はありません。

バッチアプリケーションの実行環境では使用できません。

なお，待機系であるリカバリ専用サーバマシンには，リカバリ処理をするリソースアダプタを，あらかじめ設定しておく必要があります。また，N:1リカバリが有効に動作するためには，次の二つの条件を満たしている必要があります。

実行系のアプリケーションサーバで起動しているJ2EEサーバと同じ名称のJ2EEサーバが，待機系のリカバリ専用サーバにあること。

実行系のJ2EEサーバでスタート状態にあるリソースアダプタの設定とまったく同じ設定のリソースアダプタが，待機系のJ2EEサーバに常に存在すること。

22.3　実行系と待機系を1:1で運用するシステム（1:1系切り替えシステム）

1:1系切り替えシステムとは，実行系と待機系が1:1で対応しているシステムです。Cosminexusでは，アプリケーションサーバの1:1系切り替えシステムと，運用管理サーバの1:1系切り替えシステムをサポートしています。ただし，バッチアプリケーションの実行環境では，運用管理サーバの1:1系切り替えシステムは使用できません。

アプリケーションサーバの1:1系切り替えシステム
実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成です。実行系のアプリケーションサーバマシンにトラブルが発生してマシンが終了した場合，または運用管理エージェントが終了した場合に，クラスタソフトウェアによって待機系のアプリケーションサーバマシンを起動して処理を切り替えます。

運用管理サーバの1:1系切り替えシステム
実行系の運用管理サーバマシン1台に対して待機系の運用管理サーバマシンを1台用意しておく構成です。実行系の運用管理サーバマシンにトラブルが発生してマシンが終了した場合，またはManagement Serverのプロセスが終了した場合に，クラスタソフトウェアによって待機系の運用管理サーバマシンを起動して処理を切り替えます。

以降では，1:1系切り替えシステムのシステムの構成例，系切り替え処理の流れなどについて説明します。

＜この節の構成＞

22.3.1　1:1系切り替えシステムのシステム構成例

22.3.2　系切り替えのタイミング

22.3.3　1:1系切り替えシステムでの系切り替え処理の流れ

22.3.4　系切り替え時のシステムの動作

22.3.5　系切り替え時の情報の引き継ぎ

22.3.1　1:1系切り替えシステムのシステム構成例

クラスタソフトウェアと連携して，アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例と，運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例について説明します。

アプリケーションサーバを1:1系切り替えシステムで運用する場合
アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例を次の図に示します。系切り替え時，Webサーバや運用管理サーバからは，同じ論理アドレスでアプリケーションサーバが再起動したようにみえます。

図22-1　アプリケーションサーバを1:1系切り替えシステムで運用する場合のシステム構成例

運用管理サーバを1:1系切り替えシステムで運用する場合
運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例を次の図に示します。系切り替え時，Webサーバやアプリケーションサーバからは，同じ論理アドレスで運用管理サーバが再起動したようにみえます。

図22-2　運用管理サーバを1:1系切り替えシステムで運用する場合のシステム構成例

参考

Management Serverでは，運用管理ドメインの構成情報などのManagement Serverに関する設定情報をファイル中に保持しています。運用管理サーバの1:1系切り替えシステムでは，運用管理ドメインの構成に変更がある場合，実行系の情報を待機系に引き継ぐために，システムの起動前に実行系で定義した情報（Management Serverの各種定義ファイル，Management Serverに登録したJ2EEアプリケーションやリソースアダプタなど）を待機系にコピーする必要があります。Management Serverに関する設定情報のコピーの手順については，マニュアル「Cosminexus　システム構築ガイド」または「Cosminexus　システム運用ガイド」を参照してください。

なお，1:1系切り替えシステムでは次のような運用ができます。

共用ディスク装置の使用

アプリケーションサーバを1:1系切り替えシステムで運用する場合，共用ディスク装置の使用については，ローカルトランザクションの場合とグローバルトランザクションの場合とで異なります。

ローカルトランザクションの場合
共用ディスク装置は不要です。ローカルトランザクションでは，実行系と待機系との間で引き継ぐセッション情報がないため，共用ディスク装置を使用しません。

グローバルトランザクションの場合
共用ディスク装置が必要になります。共用ディスク装置は，系切り替え時に，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。

JP1連携をする場合

クラスタソフトウェアを使用した構成では，JP1とも連携できます。

JP1と連携する場合，アプリケーションサーバには，JP1/Baseなども必要になります。クラスタソフトウェアでのJP1の管理は，Cosminexusとは別に行う必要があります。

データベースサーバでのクラスタソフトウェアとの連携

データベースサーバでもクラスタソフトウェアを使用した構成にすることもできます。この場合，アプリケーションサーバ側では，仮想アドレス（論理アドレス）だけを認識していれば，特にデータベースサーバがクラスタソフトウェアを使用していることを意識する必要はありません。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

なお，1:1系切り替えシステムのシステム構成の詳細については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

22.3.2　系切り替えのタイミング

系切り替えは次のタイミングで実施されます。

クラスタソフトウェアがハード障害などの系障害※を検知したとき

監視対象プロセス（運用管理エージェントまたはManagement Server）がダウンしたとき

クラスタソフトウェアの系切り替えコマンドを使用したとき

そのほかの，クラスタソフトウェアが系を切り替える事象が発生したとき

注※

サーバを除いた系に発生する障害を指します。系のハードウェア障害やクラスタソフトウェアの障害などがあります。

22.3.3　1:1系切り替えシステムでの系切り替え処理の流れ

1:1系切り替えシステムでの系切り替え時の動作と，処理の流れについて説明します。

＜この項の構成＞

(1)　系切り替えの動作

(2)　系切り替えの処理の流れ

(1)　系切り替えの動作

1:1系切り替えシステムでの系切り替えは次の図のようにして行われます。この図では，系Aに障害が発生し，系Bに切り替える場合の例を示します。

図22-3　1:1系切り替えシステムでの系切り替えの動作

(2)　系切り替えの処理の流れ

1:1系切り替えシステムで適用できる系切り替えには，自動系切り替えと計画系切り替えの二つがあります。自動系切り替えとは，クラスタソフトウェアが自動的に系を切り替える方法です。実行系に障害が発生したときは，自動系切り替えになります。一方，計画系切り替えとは，オペレータが系を保守する際に，計画的に系を切り替える方法です。実行系からクラスタソフトウェアのコマンドを使用して切り替えます。

ここでは，系切り替え処理の流れについて，自動系切り替えの場合と計画系切り替えの場合に分けて説明します。

(a)　自動系切り替えの処理の流れ

1:1系切り替えシステムでの自動系切り替えの処理の流れについて説明します。ここでは，実行系である系Aに障害が発生し，待機系である系Bに切り替えるときの流れについて説明します。

アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。

図22-4　アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。

図22-5　運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

(b)　計画系切り替えの処理の流れ

1:1系切り替えシステムでの計画系切り替えの処理の流れについて説明します。ここでは，クラスタソフトウェアのコマンドを使用して，実行系である系Aを待機系に，待機系である系Bを実行系に切り替えるときの流れについて説明します。

アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。

図22-6　アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。

図22-7　運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

22.3.4　系切り替え時のシステムの動作

系切り替え時のシステムの動作について説明します。

＜この項の構成＞

(1)　HTTPのセッション情報の引き継ぎ

(2)　EJBのセッション情報の引き継ぎ

(3)　トランザクション情報の引き継ぎ

(4)　運用管理エージェントの動作

(5)　性能解析トレースで出力するキー情報

(1)　HTTPのセッション情報の引き継ぎ

セッションフェイルオーバ機能を使用しない場合，Webコンテナが管理しているHTTPのセッション情報※1およびServletContextに設定したアトリビュート情報※2は，J2EEサーバのメモリ中にしかなく，これらの情報は，実行系と待機系との間で共有されません。系の切り替え実施後，HTTPのセッション情報は失われます。このため，すでにセッションを開始していたWebアプリケーションおよびWebクライアントでは，不正な動作をするおそれがあります。これを防止するため，アプリケーションで，セッション情報に矛盾が発生した場合に適切に対処できるようにしておく必要があります。

セッションフェイルオーバ機能を使用する場合，系切り替え後もHTTPセッション情報を維持できます。ただし，維持できるのはセッションフェイルオーバ機能で引き継ぎの対象としたセッション情報だけです。

なお，系切り替え後もセッションを維持するためには，セッションをDBMSなどで管理するようにアプリケーション側で独自に設定し，実行系および待機系の両方から参照できるようにする必要があります。

注※1

javax.servlet.http.HttpServletRequest#getSessionメソッドで取得した，javax.servlet.http.HttpSessionオブジェクトに格納している情報を指します。

注※2

javax.servlet.ServletContext#getServletContextメソッドで取得した，javax.servlet.ServletContextオブジェクトに格納している情報を指します。

(2)　EJBのセッション情報の引き継ぎ

EJBコンテナが管理しているセッション情報※は，J2EEサーバのメモリ中にしかないため，系の切り替え実施後はセッション情報が失われます（実行系と待機系の間で，セッション情報は共有されません）。このため，すでにセッションを開始していたEJBクライアントでは，正常に動作を継続できないおそれがあります。セッション情報が失われた場合は，Homeのlookupからやり直すように，EJBクライアントを設計する必要があります。

なお，CTM環境でも同様の問題が起こります。

注※

ホームインタフェース，およびコンポーネントインタフェースのオブジェクト情報を指します。

(3)　トランザクション情報の引き継ぎ

トランザクション情報の引き継ぎはトランザクションの種類によって異なります。トランザクション情報の引き継ぎについて，ローカルトランザクションの場合とグローバルトランザクションの場合を説明します。

(a)　ローカルトランザクションの場合

ローカルトランザクションの場合，系の切り替え時にはトランザクション情報は引き継がれません。

システムの障害によってダウンした場合や，J2EEサーバのプロセスダウンによって系の切り替えが発生した場合は，開始中のトランザクションは，コミットおよびロールバックのどちらも実施されません。

なお，計画系切り替えのように，J2EEサーバが正常に終了する場合は，トランザクションが開始中の状態で残ることはありません。

(b)　グローバルトランザクションの場合

グローバルトランザクションの場合，系切り替え後に引き継いだトランザクションを使用して，J2EEサーバの起動時に，トランザクションの回復処理をします。これによって，コミットまたはロールバックのどちらかの適切な処理が実施されます。

(4)　運用管理エージェントの動作

運用管理エージェントでは，実行系と待機系の間で直接情報を引き継ぐことはありません。系切り替え後には，運用管理エージェントの起動スクリプト中に記述した論理サーバが起動されます。なお，運用管理エージェントの起動スクリプトについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(5)　性能解析トレースで出力するキー情報

性能解析トレースの出力する情報には，一連の処理を識別するためのキー情報が付与されています。このキー情報には，作成時のIPアドレスが含まれます。IPアドレスを複数持つホストの場合，キー情報には，そのホストの持つIPアドレスのどれか一つが含まれます。このため，実行系のホストで出力された性能解析トレースには，キー情報として，ステーショナリIPアドレス（系切り替えによって他系へ移動しないIPアドレス）が含まれたり，エイリアスIPアドレス（クラスタソフトウェアによって動的に割り当てられるIPアドレス）が含まれたりする場合があります。これによって，系の切り替え前と切り替え後とで，キー情報に含まれるIPアドレスが変わる可能性があることに留意してください。

なお，性能解析トレースで出力するキー情報については，「17.10.2　性能解析トレースの仕組み」を参照してください。

22.3.5　系切り替え時の情報の引き継ぎ

系切り替え時に，待機系に引き継がれる情報と，引き継がれない情報について説明します。

引き継がれる情報

OTSトランザクション情報（グローバルトランザクションの場合）
実行系から待機系のへの系切り替え後，OTSトランザクション情報を引き継ぎ，トランザクションの回復処理をします。

引き継げない情報
系切り替えが発生したとき，次に示す情報は切り替え後の系に引き継がれないので注意してください。

Webコンテナが管理するアプリケーションのHTTPセッション情報※

WebコンテナのServletContextに設定したアトリビュート情報

ホームインタフェースとコンポーネントインタフェースのBeanのセッション情報

アプリケーションの稼働状態，JNDIのキャッシュ，コネクションプール，CTMのキューなどの状態に関する情報

注※

セッションフェイルオーバ機能を使用する場合，引き継ぎの対象としたセッション情報だけ引き継げます。

22.4　相互スタンバイで運用するシステム（相互系切り替えシステム）

相互系切り替えシステムとは，1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。

この節では，相互スタンバイシステムのシステムの構成例と系切り替え処理の流れについて説明します。系切り替えのタイミングや系切り替え時のシステムの動作などは1:1系切り替え構成の場合と同じです。参照先を次の表に示します。

表22-3　系切り替え時の動作と参照先

系切り替え時の動作 | 参照先
系切り替えのタイミング | 22.3.2
系切り替え時のシステムの動作 | 22.3.4
系切り替え時の情報の引き継ぎ | 22.3.5

＜この節の構成＞

22.4.1　相互系切り替えシステムのシステム構成例

22.4.2　相互系切り替えシステムでの系切り替え処理の流れ

22.4.1　相互系切り替えシステムのシステム構成例

クラスタソフトウェアと連携した相互系切り替えシステムの構成例を次の図に示します。系切り替え時，クライアントやデータベースなどサーバの外からは，同じ論理アドレスでアプリケーションサーバが再起動したようにみえます。

図22-8　相互系切り替えシステムの構成例

図に示す，相互系切り替えシステムについて説明します。

実行系1（待機系2）および待機系1（実行系2）の各アプリケーションサーバは，異なる運用管理ドメインで管理されています。

それぞれの運用管理ドメイン内に，現用系および予備系の二つの仮想ホストを定義しています。現用系および予備系の仮想ホストは，それぞれ実行系アプリケーションサーバ，待機系アプリケーションサーバとして使用します。

障害発生時は，相互の運用管理ドメイン内の仮想ホストが切り替えられます。例えば，図中のサーバ1の現用系仮想ホストで障害が発生した場合，サーバ2の予備系仮想ホストに系が切り替えられます。

各サーバの運用に使用するIPアドレスは，クラスタソフトウェアによって動的に割り当てられるIPアドレス（エイリアスIPアドレス）を使用します。図中の相互系切り替えシステムの場合，「xxx.xxx.1.111」および「xxx.xxx.2.222」がエイリアスIPアドレスとなります。なお，クラスタソフトウェアはIPアドレス単位にLANを切り替えるため，サーバ1およびサーバ2のクラスタIPアドレスには一意となる値が割り当てられます。系切り替え時は，現用系仮想ホストでエイリアスIPアドレスが削除され，予備系仮想ホストでエイリアスIPアドレスが追加されることで処理が引き継がれます。

Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系へ移動しないIPアドレス（ステーショナリIPアドレス）を使用します。図中の相互系切り替えシステムの場合，現用系1の「xxx.xxx.0.11」，および予備系1の「xxx.xxx.0.22」がステーショナリIPアドレスとなります。

参考

仮想ホストとは，一つのマシンに複数の異なるIPアドレスを割り当てて，複数の物理ホストとして使用できる構成です。同一運用管理ドメイン内の仮想ホストは，一つの運用管理エージェントによってアプリケーションサーバの起動や停止などの運用操作を制御できますが，運用に使用するIPアドレスは異なるため，見かけ上は異なる物理ホストとして扱われます。

なお，相互系切り替えシステムでは次のような運用ができます。

共用ディスク装置の使用

共用ディスク装置の使用については，ローカルトランザクションの場合とグローバルトランザクションの場合とで異なります。

ローカルトランザクションの場合
共用ディスク装置は不要です。ローカルトランザクションでは，実行系と待機系との間で引き継ぐセッション情報がないため，共用ディスク装置を使用しません。

グローバルトランザクションの場合
共用ディスク装置が必要になります。共用ディスク装置は，系切り替え時に，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。

JP1との連携

クラスタソフトウェアを使用した構成では，JP1とも連携できます。

JP1と連携する場合，アプリケーションサーバには，JP1/Baseなども必要になります。クラスタソフトウェアでのJP1の管理は，Cosminexusとは別に行う必要があります。

データベースサーバでのクラスタソフトウェアとの連携

データベースサーバでもクラスタソフトウェアを使用した構成にすることもできます。この場合，アプリケーションサーバ側では，仮想アドレス（論理アドレス）だけを認識していれば，特にデータベースサーバがクラスタソフトウェアを使用していることを意識する必要はありません。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

相互系切り替えシステムのシステム構成の詳細については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

22.4.2　相互系切り替えシステムでの系切り替え処理の流れ

相互系切り替えシステムでの系切り替え時の動作と，処理の流れについて説明します。

＜この項の構成＞

(1)　系切り替えの動作

(2)　系切り替えの処理の流れ

(1)　系切り替えの動作

相互系切り替えシステムでの系切り替えは次の図のようにして行われます。この図では，実行系1（待機系2）の現用系仮想ホストに障害が発生し，待機系1（実行系2）の予備系仮想ホストに系を切り替える場合の例を示します。

図22-9　相互系切り替えシステムでの系切り替えの動作

(2)　系切り替えの処理の流れ

相互系切り替えシステムに適用できる系切り替えには，自動系切り替えと計画系切り替えの二つがあります。自動系切り替えとは，クラスタソフトウェアが自動的に系を切り替える方法です。実行系に障害が発生したときは，自動系切り替えになります。一方，計画系切り替えとは，オペレータが系を保守する際に，計画的に系を切り替える方法です。実行系からクラスタソフトウェアのコマンドを使用して切り替えます。

ここでは，系切り替え処理の流れについて，自動系切り替えの場合と計画系切り替えの場合に分けて説明します。

(a)　自動系切り替えの処理の流れ

相互系切り替えシステムでの自動系切り替えの処理の流れを次の図に示します。この図では，実行系1（待機系2）の現用系仮想ホストに障害が発生して，待機系1（実行系2）の予備系仮想ホストに系を切り替えるときの処理の流れを示します。

図22-10　相互系切り替えシステムでの自動系切り替えの処理の流れ

(b)　計画系切り替えの処理の流れ

相互系切り替えシステムでの計画系切り替えの処理の流れを次の図に示します。この図では，クラスタソフトウェアのコマンドを使用して，実行系1（待機系2）の現用系仮想ホストを予備系仮想ホストに，待機系1（実行系2）の予備系仮想ホストを現用系仮想ホストに切り替えるときの流れについて示します。

図22-11　相互系切り替えシステムでの計画系切り替えの処理の流れ

22.5　待機系をリカバリ専用サーバとして運用するシステム（N:1リカバリシステム）

N:1リカバリシステムとは，クラスタ構成になっている実行系の複数（N台）のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。ただし，バッチアプリケーションの実行環境の場合，N:1リカバリシステムは使用できません。

ここでは，システムの構成例，リカバリ処理の流れについて説明します。

＜この節の構成＞

22.5.1　N:1リカバリシステムのシステム構成例

22.5.2　リカバリ処理の流れ

22.5.3　系切り替え時の情報の引き継ぎ

22.5.1　N:1リカバリシステムのシステム構成例

クラスタソフトウェアと連携したN:1リカバリシステムのシステム構成例を次の図に示します。クラスタ構成で実行中のアプリケーションサーバに障害が発生すると，待機系のリカバリ専用サーバが起動し，障害が発生した実行系のトランザクションを決着します。

待機系であるリカバリ専用サーバのJ2EEサーバには，実行系にインポートされているリソースアダプタをすべてインポートします。なお，リカバリ専用サーバは障害が発生した実行系のアプリケーションサーバのリカバリを実施するだけなので，アプリケーションをデプロイする必要はありません。

図22-12　N:1リカバリシステムのシステム構成例

N:1リカバリシステムでは次のような運用ができます。

共用ディスク装置の使用

共用ディスク装置が必要になります。共用ディスク装置は，OTSのステータスなどのトランザクション情報を引き継ぐために使用します。トランザクション情報は，実行系のそれぞれのアプリケーションサーバと，待機系のリカバリ専用サーバとの間で引き継ぎします。

負荷分散機の適用

このシステム構成例では示していませんが，同一構成のWebサーバを複数用意して，負荷分散機を適用することもできます。これによって，Webサーバの信頼性・稼働率を上げることができます。

なお，N:1リカバリシステムのシステム構成の詳細については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

22.5.2　リカバリ処理の流れ

クラスタ構成の実行系と，リカバリ専用サーバである1台の待機系で稼働します。実行系の複数のアプリケーションサーバのうち一つでも障害が発生すると，クラスタソフトウェアで障害を検出し，待機系であるリカバリ専用サーバに切り替えられます。待機系では，ダウンした実行系のアプリケーションサーバのトランザクションを決着します。

リカバリ処理の流れについて次の図に示します。

図22-13　リカバリ処理の流れ

リカバリ専用サーバのクラスタソフトウェアが障害を検知します。
実行系のアプリケーションサーバCで障害が発生し，ダウンすると，待機系のリカバリ専用サーバのクラスタソフトウェアはアプリケーションサーバCのダウンを検知します。

リカバリ専用サーバのクラスタソフトウェアで系切り替えを実施します。
待機系のリカバリ専用サーバに切り替えます。このとき，共用ディスク装置の切り替え，共用ディスク装置のマウント，および仮想ホストのIPアドレスの設定をします。

リカバリ専用サーバをロックします。
リカバリ専用サーバでは，順次，リカバリ処理を実施します。このため，リカバリ処理を実施する前に，リカバリ専用サーバをロックします。

リカバリ専用サーバのクラスタソフトウェアでリカバリコマンドを実行し，リカバリ専用サーバのアプリケーションサーバをリカバリモードで起動します。

ダウンしたアプリケーションサーバCで仕掛かり中だったトランザクションのリカバリ処理を，リカバリ専用サーバで実施します。
リカバリ専用サーバでは，トランザクションのリカバリ処理だけが実施されます。リカバリ処理終了後，リカバリ専用サーバのアプリケーションサーバは終了します。

リカバリ専用サーバのロックを解除します。

リカバリ専用サーバのクラスタソフトウェアでアプリケーションサーバ終了後の処理を実施します。
共用ディスク装置の切り替え，共用ディスク装置のアンマウント，および仮想ホストのIPアドレスの削除をします。

ほかの実行系のアプリケーションサーバに障害が発生している場合は，リカバリ処理をします。なお，実行系のアプリケーションサーバAおよびBについては，アプリケーションサーバCのダウンの影響を受けず，アプリケーション処理を実行します。

注意事項

複数の実行系で障害が発生し，アプリケーションサーバがダウンした場合は，リカバリ専用サーバ（待機系）では，排他で順次リカバリ処理をします。

リカバリ専用サーバでのリカバリ処理中は，リカバリ専用サーバのサービスポートが閉塞されるため，処理の受け付けはされません。

リカバリ専用サーバでは，リカバリ処理が終了しない場合に備えて，タイムアウト監視が実施されます。

データベースのダウンによってタイムアウトした場合は，手動でリカバリ処理をしてください。詳細については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

リカバリ専用サーバがダウンした場合などの二重障害については，対応していません。

22.5.3　系切り替え時の情報の引き継ぎ

系切り替え時に，待機系に引き継がれる情報と，引き継がれない情報について説明します。

引き継がれる情報

OTSトランザクション情報の引き継ぎ（グローバルトランザクションの場合）
実行系から待機系のへの系切り替え後，OTSトランザクション情報を引き継ぎ，トランザクションの回復処理をします。

引き継げない情報
系切り替えが発生したとき，次に示す情報は切り替え後の系に引き継がれないので注意してください。

Webコンテナが管理するアプリケーションのHTTPセッション情報

WebコンテナのServletContextに設定したアトリビュート情報

ホームインタフェースとコンポーネントインタフェースのBeanのセッション情報

アプリケーションの稼働状態，JNDIのキャッシュ，コネクションプール，CTMのキューなどの状態に関する情報

付録

＜この付録の構成＞

付録A　旧バージョンとの互換用機能

付録B　ベーシックモードでのリソース接続

付録C　サーブレットエンジンモードで使用できるWebコンテナの機能

付録D　サーブレットエンジンモードでのリソース接続

付録E　J2EEサーバ起動時のEJBタイマの自動生成

付録F　Oracle RACを使用したOracleへの接続

付録G　アプリケーションの開発で使用する文字コード

付録H　クラスローダの構成

付録I　Cosminexus DABroker Libraryを使用したデータベース接続の実装

付録J　用語解説

付録A　旧バージョンとの互換用機能

ここでは，旧バージョンとの互換用機能としてのサーバの動作モードについて説明します。また，互換用の動作モードで使用できる機能の一覧を示します。

＜この節の構成＞

付録A.1　互換用のサーバの動作モード

付録A.2　使用できる機能の一覧

付録A.3　サーブレットエンジンモードとJ2EEサーバモードの比較

付録A.1　互換用のサーバの動作モード

互換用のサーバの動作モードには次の二つがあります。

ベーシックモード

サーブレットエンジンモード

それぞれの動作モードについて説明します。

＜この項の構成＞

(1)　ベーシックモード

(2)　サーブレットエンジンモード

(1)　ベーシックモード

ベーシックモードは，J2EEサーバモードの一つです。単一のデータベースだけのリソースをトランザクションで使用するシステムに適用できます。旧バージョンとの互換性を重視したモードです。

なお，ベーシックモードは，1.4モード（06-71までのスタンダードモードまたはアドバンスドモード）に比べて，使用できる機能に制限があります。J2EEサーバモードを使用する場合は，1.4モードを使用することを推奨します。

参考

ベーシックモードから1.4モードへの変更

すでにベーシックモードを使用している場合も，1.4モードへの変更ができます。変更する場合は，次の点に留意してください。

データソースをインポートしている場合，データソースを削除してから，再度作成し直す必要があります。

サーバの環境をいったん削除してから，再度サーバの環境をセットアップし直す必要があります。

1.4モードを使用する場合は，トランザクション管理サーバなどが必要となるため，ベーシックモードに比べ，多量のCPU/メモリリソースが必要となります。

また，動作モードの変更によって，変更前の動作モードで使用できたプロパティが使用できなくなることがありますので注意してください。

(2)　サーブレットエンジンモード

1.4モードまたはベーシックモードではJ2EEコンテナ（EJBコンテナとWebコンテナ）を利用します。一方，サーブレットエンジンモードは，Webアプリケーションだけを動作させる（Enterprise Beanを使用しない）場合など，Webコンテナ部分だけを使用する構成のときに利用できる動作モードです。サーブレットエンジンモードでは，サーブレットエンジンだけが単独で動作します。サーブレットエンジンとは，サーブレット実行機能，JSP実行機能を持つサーバのことです。

このモードでは，WebアプリケーションからはJava Servlet Specification v2.3，JavaServer Pages Specification v1.2に示すAPIおよびCosminexus DABroker Libraryを通じ，Sun JDBC API仕様に従った方法によるデータベースアクセスが利用できます。

なお，サーブレットエンジンモードで実行したときのサーバをWebコンテナサーバと呼びます。

付録A.2　使用できる機能の一覧

ベーシックモードおよびサーブレットエンジンモードで使用できるJ2EEの機能，およびApplication Serverの機能について一覧に示します。

＜この項の構成＞

(1)　使用できるJ2EEの機能

(2)　使用できるApplication Serverの機能

(1)　使用できるJ2EEの機能

互換用の動作モードで使用できるJ2EEの機能について，次の表に示します。

表A-1　互換用の動作モードで使用できるJ2EEの機能

J2EEの機能
ベーシックモード
サーブレットエンジンモード

Servlet 2.3
○
○

Servlet 2.4
×
×

JSP 1.2
○
○

JSP 2.0
×
×

EJB 2.0
○
×

Message-driven Bean
×
×

ローカルインタフェース
×
×

CMP 1.1
○
×

CMP 2.0
×
×

EJB 2.1
×
×

ビジネスインタフェース
アノテーション
DI
×
×

JDBC 2.0コア
JDBC 2.0オプションパッケージ
○
○

JDBC 3.0
×
×

JMS 1.0.2※1
×
×

JMS 1.1※2
×
×

Connector 1.0（JCA 1.0）
×
×

Connector 1.5（JCA 1.5）
×
×

JTA 1.0.1
○
×

local
○
×

global
×
×

JavaMail 1.2
　○※3
×

JavaMail 1.3
×
×

（凡例）　○：使用できる　　×：使用できない

注※1

Cosminexus RMまたはTP1/Message Queue - Accessを使用する場合は，JMS1.0.2であることが前提です。また，Topicを含む一部の機能に制限があります。

注※2

JMS1.1を使用するためには，JMSプロバイダがJMS1.1に対応していること，

Message-driven BeanがEJB2.1に対応していること（Message-driven Beanを使用する場合），使用するリソースアダプタがConnector 1.5に対応していることが前提になります。

注※3

JavaMailで使用できるサービスプロバイダはSMTPだけです。メールの送信機能だけを使用できます（メールの受信機能は使用できません）。

(2)　使用できるApplication Serverの機能

ベーシックモードおよびサーブレットエンジンモードの場合に使用できるApplication Serverの各機能について説明します。

Webコンテナの機能
互換用の動作モードで使用できるWebコンテナの機能について次の表に示します。なお，ベーシックモードの場合のWebコンテナの機能は「4.　Webコンテナ」を，サーブレットエンジンモードの場合のWebコンテナの機能については，「付録C　サーブレットエンジンモードで使用できるWebコンテナの機能」を参照してください。

表A-2　互換用の動作モードで使用できるWebコンテナの機能

Webコンテナの機能 | ベーシックモード | サーブレットエンジンモード
Webアプリケーションの実行 | ◎ | △
インプロセスHTTPサーバによるリクエストの受け付け | ◎ | ×
セッション管理 | HttpSessionオブジェクト数の上限値の設定 | ◎ | ×
セッションIDおよびCookieへのサーバIDの付加 | ◎ | ◎
文字コード変換 | ○ | ○
デフォルトの文字エンコーディング設定 | ◎ | ×
JSPの事前コンパイル | × | ×
JSPファイルのコンパイル結果の保持 | ◎ | ◎△
アプリケーションのイベントリスナ | ○ | ○
タグファイルの実行 | × | ×
JSP ELの実行 | × | ×
リクエストおよびレスポンスのフィルタリング | ○ | ○
フィルタリングによるHTTPレスポンスの圧縮 | ○ | ○
Webコンテナのセキュリティ管理 | SSL使用による認証情報とデータの暗号化 | ◎ | ◎
ロールに基づくWebコンテナのユーザ認証 | ◎ | ◎△
Webコンテナ実行時の保護 | ◎ | ◎△
EJBコンテナとの連携 | ◎ | ◎△
データベースとの接続 | △ | ◎△
Webコンテナによるスレッドの作成 | ◎ | ◎△
同時実行スレッド数の制御 | Webコンテナ単位の同時実行スレッド数制御 | ◎ | ◎
Webアプリケーション単位の同時実行スレッド数制御 | ◎ | ×
URLグループ単位の同時実行スレッド数制御 | × | ×
ユーザスレッドの使用 | ◎ | ◎
通信タイムアウトの設定 | ◎ | ◎
Webサーバ（リダイレクタ）によるリクエストの振り分け | ◎ | ◎
エラーページのカスタマイズ | ◎ | ◎
ドメイン名指定でのトップページの表示 | ○ | ○
Webコンテナへのゲートウェイ情報の通知 | ○ | ○
Webサーバ連携・インプロセスHTTPサーバ・簡易WebサーバでのIPアドレスの指定※ | ◎ | ○
静的コンテンツのキャッシュ | ◎ | ○
簡易Webサーバ機能 | ◎ | ◎△
セッションフェイルオーバ機能 | ◎ | ×

（凡例）

○：使用できる

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

△：使用できる。ただし，1.4モードと機能差がある

×：使用できない

注　◎△は，J2EEの機能に加えてApplication Serverで拡張した機能またはApplication Server独自の機能を使用でき，かつJ2EEサーバモードとサーブレットエンジンモードで機能差があることを表します。

注※　サーブレットエンジンモードの場合は，インプロセスHTTPサーバは使用できないため，インプロセスHTTPサーバで利用するIPアドレスの指定は該当しません。

EJBコンテナの機能
互換用の動作モードで使用できるEJBコンテナの機能について次の表に示します。

表A-3　互換用の動作モードで使用できるEJBコンテナの機能

EJBコンテナの機能 | ベーシックモード | サーブレットエンジンモード
Eneterprise Beanの実行 | ○ | ×
EJBコンテナのJNDI名前空間へのリファレンス登録 | ◎ | ×
外部リソースとの接続 | ○ | ×
Enterprise Beanでのトランザクション設定 | ○ | ×
Enterprise Beanへのアクセス制御 | ○ | ×
EJBコンテナの動作の最適化 | Entity Beanのキャッシュモデル（コミットオプション指定） | ○ | ×
Stateless Session Bean，Entity Beanのプーリング | ◎ | ×
Stateful Session Beanのタイムアウト | ◎ | ×
Entity BeanのEJBオブジェクトのタイムアウト | ◎ | ×
RMI-IIOP通信のタイムアウト | ◎ | ×
インスタンス取得待ちのタイムアウト | × | ×
EJBのリモートインタフェースの呼び出し | ◎ | ×
Timer Serviceの機能 | × | ×
EJBクライアントの使用 | ◎ | ×
セキュリティ管理 | セキュリティアイデンティティの使用 | △※ | ×
通信ポートとIPアドレスの固定 | ◎ | ×
Enterprise Beanへのアクセス制御の抑止オプション | ◎ | ×

（凡例）

○：使用できる

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

△：使用できる。ただし，ほかのJ2EEサーバモードと機能差がある

×：使用できない

注※

サーブレット／JSPからEJBを呼び出す際に，web.xmlに指定した<run-as>タグの情報は使用されません。

J2EEアプリケーションの実行機能
互換用の動作モードで使用できるJ2EEアプリケーションの実行機能について次の表に示します。

表A-4　互換用の動作モードで使用できるJ2EEアプリケーションの実行機能

J2EEアプリケーションの実行機能 | ベーシックモード | サーブレットエンジンモード
アーカイブ形式によるJ2EEアプリケーションのデプロイ | ○ | ×
展開ディレクトリ形式によるJ2EEアプリケーションのデプロイ | × | ×
J2EEアプリケーションのリデプロイ | ◎ | ×
J2EEアプリケーションの更新検知とリロード | × | ×
Webアプリケーションの更新検知とリロード | × | ◎※1
リソースアダプタを含むJ2EEアプリケーションの操作 | ○※2 | ◎

（凡例）

○：使用できる

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

注※1　サーブレットエンジンモードで使用できるリロード機能は，1.4モードで使用できるリロード機能とは差異があります。サーブレットエンジンモードで使用できるリロード機能については，「付録C.2　Webアプリケーションの更新検知とリロード」を参照してください。

注※2　ベーシックモードの場合，リソースアダプタを含むJ2EEアプリケーションのインポートはできますが，J2EEアプリケーションの開始はできません。また，開始状態のJ2EEアプリケーションをインポートした場合，J2EEアプリケーションにリソースアダプタが含まれている場合は開始できません。

ネーミング管理の機能
互換用の動作モードで使用できるネーミング管理の機能について次の表に示します。

表A-5　互換用の動作モードで使用できるネーミング管理の機能

ネーミング管理の機能 | ベーシックモード | サーブレットエンジンモード
JNDI名前空間へのオブジェクトのバインドとルックアップ | ◎ | ×
Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能） | ◎※ | ×
ラウンドロビンポリシーによるCORBAネーミングサービスの検索 | ◎ | ◎
ネーミング管理機能でのキャッシング | ◎ | ◎
CORBAネーミングサービスの切り替え | ◎ | ◎

（凡例）

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

注※

リモートホームインタフェースに対する別名だけを使用できます。

ローカルホームインタフェース，リモートビジネスインタフェースまたはローカルビジネスインタフェースに対しても別名は設定できます。ただし，ベーシックモードではこれらのインタフェースがサポートされていないため，設定した別名は使用できません。

リソース接続とトランザクション管理の機能
互換用の動作モードで使用できるリソース接続とトランザクション管理の機能について次の表に示します。
なお，接続できるリソースやリソース接続で使用できる機能については，ベーシックモードの場合は，「付録B　ベーシックモードでのリソース接続」を，サーブレットエンジンモードの場合は，「付録D　サーブレットエンジンモードでのリソース接続」を参照してください。

表A-6　互換用の動作モードで使用できるリソース接続とトランザクション管理の機能

リソース接続とトランザクション管理の機能 | ベーシックモード | サーブレットエンジンモード
コネクションプーリング | DB Connectorによるコネクションプーリング | － | －
データソースによるコネクションプーリング | ◎ | －
Webコンテナコネクションプールによるコネクションプーリング | － | ◎
DB Connector for Cosminexus RMとCosminexus RMによるコネクションプーリング | － | －
uCosminexus TP1 Connectorとのコネクションプーリング | － | －
TP1/Message Queue - Accessとのコネクションプーリング | － | －
SMTPサーバとのコネクションプーリング | × | －
JavaBeansリソースとのコネクションプーリング | － | －
コネクションプールのウォーミングアップ | × | ×
コネクション数調節 | × | ×
コネクションシェアリング | ○ | －
コネクションアソシエーション | × | －
ステートメントプーリング（DB Connector） | × | ×
ライトトランザクション | × | －
インプロセストランザクションサービス | × | －
DataSourceオブジェクトのキャッシング | ◎ | ×
DB Connectorのコンテナ管理でのサインオンの最適化 | － | －
受信バッファのプーリング | × | ×
コネクションの障害検知 | DB Connectorによる障害検知 | － | －
データソースによる障害検知 | × | －
Webコンテナコネクションプールによる障害検知 | － | ×
DB Connector for Cosminexus RMとCosminexus RMによる障害検知 | － | －
uCosminexus TP1 Connectorとのコネクション障害検知 | － | －
TP1/Message Queue - Accessとのコネクション障害検知 | － | －
SMTPサーバとのコネクション障害検知 | × | －
JavaBeansリソースとのコネクション障害検知 | － | －
コネクション枯渇時のコネクション取得待ち | × | ×
コネクションの取得リトライ | DB Connectorによるコネクション取得リトライ | － | －
データソースによるコネクション取得リトライ | ◎ | －
Webコンテナコネクションプールによるコネクション取得リトライ | － | ◎
DB Connector for Cosminexus RMとCosminexus RMによるコネクション取得リトライ | － | －
uCosminexus TP1 Connectorとのコネクション取得リトライ | － | －
TP1/Message Queue - Accessとのコネクション取得リトライ | － | －
SMTPサーバとのコネクション取得リトライ | × | －
JavaBeansリソースとのコネクション取得リトライ | － | －
コネクションプールの情報表示 | ◎ | ◎※
コネクションプールのクリア | ◎ | ◎※
コネクションのクローズ・解放 | コネクション強制クローズ | ◎ | ◎※
コネクション自動クローズ（Webコンテナ） | × | ×
コネクション自動クローズ（EJBコンテナ） | ○ | ×
コネクションスイーパ | ◎ | ×
トランザクションタイムアウト | ○ | －
トランザクションリカバリ | × | －
障害調査用SQLの出力 | × | ×
コネクションプールのクラスタ化 | × | ×
リソースへの接続テスト | DB Connectorによるデータベースとの接続テスト | － | －
データソースによるデータベースとの接続テスト | ◎ | －
Webコンテナコネクションプールによるデータベースとの接続テスト | － | ×
DB Connector for Cosminexus RMとCosminexus RMによるデータベース上のキューとの接続テスト | － | －
uCosminexus TP1 ConnectorによるOpenTP1 SPPとの接続テスト | － | －
TP1/Message Queue - AccessによるTP1/Message Queueとの接続テスト | － | －
SMTPサーバとの接続テスト | ○ | －
JavaBeansリソースとの接続テスト | － | －

（凡例）

○：使用できる

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

－：該当しない

注※　J2EEサーバモードの場合と実行するコマンドが異なります。

コンテナ拡張ライブラリの機能
コンテナ拡張ライブラリは，互換用の動作モードでも利用できます。コンテナ拡張ライブラリは，Application Server独自の機能となります。

注意

ベーシックモードの場合，コンテナ拡張ライブラリには次のアクセス権が付与されます。アクセス権は変更できません。

java.security.AllPermission

ただし，java.lang.RuntimePermissionのsetSecurityManagerアクセス権は付与されません。

サーブレットエンジンモードの場合，アクセス権が付与されません。

cjstartwebコマンドに-securityオプションを指定し，Webコンテナの実行時保護機能を有効にする場合は，SecurityManager定義ファイル（web.policy）に適切なアクセス権を設定してください。

CTM機能
互換用の動作モードで使用できるCTM機能について次の表に示します。

表A-7　互換用の動作モードで使用できるCTM機能

CTM機能 | ベーシックモード | サーブレットエンジンモード
CTMによるリクエストの流量制御と優先制御 | ◎ | ×
CTMによるリクエストの閉塞制御 | ◎ | ×
CTMによるリクエストの負荷分散 | ◎ | ×
CTMによるリクエストのキューの滞留監視 | ◎ | ×
CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続 | ◎ | ×
CTMの稼働統計情報の出力／収集 | ◎ | ×

（凡例）

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

統合ユーザ管理機能
互換用の動作モードで使用できる統合ユーザ管理機能について次の表に示します。なお，サーブレットエンジンモードを使用している場合，統合ユーザ管理GUIを使用した機能は使用できません。それ以外の機能については，サーバの動作モードによる差異はありません。

表A-8　互換用の動作モードで使用できる統合ユーザ管理機能

統合ユーザ管理機能 | ベーシックモード | サーブレットエンジンモード
Cosminexus標準ログインモジュールを使用したログイン | ◎ | ◎
Cosminexus標準ログインモジュールを使用したユーザ情報リポジトリへのアクセス | ◎ | ◎
統合ユーザ管理のセッション管理 | ◎ | ◎
シングルサインオン | ◎ | ◎
カスタムログインモジュールを使用したログイン | ◎ | ◎
統合ユーザ管理をするためのアプリケーション開発 | ◎ | ◎
リポジトリ管理 | ◎ | ×
リソース監視 | ◎ | ×

（凡例）

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

ログ運用および障害検知に使用する機能
互換用の動作モードで使用できるログ運用および障害検知に使用する機能について次の表に示します。

表A-9　互換用の動作モードで使用できるログ運用および障害検知に使用する機能

ログ運用および障害検知に使用する機能 | ベーシックモード | サーブレットエンジンモード
稼働情報の監視（稼働情報の収集機能） | × | ×
稼働情報の監視（運用管理コマンド・運用管理ポータルの機能） | ◎ | ×
リソースの枯渇監視 | × | ×
Managementイベントによる処理の自動実行 | × | ×
CTMの稼働統計情報の収集 | ◎ | ×
システムの処理性能の解析 | ◎※ | ◎
ユーザログ出力 | ◎ | ◎
コンソールログ出力 | ◎ | ×
障害検知時コマンド | ◎ | ×
snapshotログ収集 | ◎ | ◎

（凡例）

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

注※　ベーシックモードの場合，次の機能レイヤでは性能解析情報を出力しません。

JTA

JCAコンテナ

DB Connector

J2EEアプリケーションの運用機能
互換用の動作モードで使用できるJ2EEアプリケーションの運用機能について次の表に示します。

表A-10　互換用の動作モードで使用できるJ2EEアプリケーションの運用機能

J2EEアプリケーションの運用機能 | ベーシックモード | サーブレットエンジンモード
J2EEアプリケーションのリクエストの同時実行数の動的変更 | ◎ | ×
J2EEアプリケーション実行時間の監視とキャンセル | メソッドタイムアウト機能 | × | ×
メソッドキャンセル機能 | × | ×
J2EEアプリケーションのサービスの閉塞 | ◎ | ◎
J2EEアプリケーションの停止 | 通常停止 | ○ | ○
強制停止 | × | ×
J2EEアプリケーションの入れ替え | Webアプリケーションのサービスの部分閉塞による入れ替え | ○ | ○※1
リデプロイ機能による入れ替え | ◎ | ×
リロードによる入れ替え※2 | × | ◎
テストモードでのJ2EEアプリケーションの実行 | × | ×

（凡例）

○：使用できる

◎：J2EEの機能に加えてApplication Serverで拡張した機能を使用できる，またはApplication Server独自の機能を使用できる

×：使用できない

注※1　WebサーバにHitachi Web Serverを使用している場合だけ使用できます。

注※2　サーブレットエンジンモードで使用できるリロード機能は，1.4モードで使用できるリロード機能とは差異があります。サーブレットエンジンモードで使用できるリロード機能については，「付録C.2　Webアプリケーションの更新検知とリロード」を参照してください。

システムの監査機能
互換用の動作モードで使用できるシステムの監査機能について次の表に示します。

表A-11　互換用の動作モードで使用できるシステムの監査機能

システムの監査機能 | ベーシックモード | サーブレットエンジンモード
監査ログ出力機能 | × | ×
データベース監査証跡連携機能 | × | ×

（凡例）

×：使用できない

クラスタソフトウェアによる系切り替え機能
互換用の動作モードで使用できるクラスタソフトウェアによる系切り替え機能について次の表に示します。

表A-12　互換用の動作モードで使用できるクラスタソフトウェアによる系切り替え機能

クラスタソフトウェアによる系切り替え機能 | ベーシックモード | サーブレットエンジンモード
1:1系切り替えシステム | ○ | ×
相互系切り替えシステム | ○ | ×
N:1系切り替えシステム | × | ×

（凡例）

○：使用できる

×：使用できない

Management Serverの管理対象となるJ2EEサーバについて
ベーシックモードで動作しているJ2EEサーバはManagement Serverの管理対象となりますが，サーブレットエンジンモードで動作しているサーバ（Webコンテナサーバ）はManagement Serverの管理の対象にはなりません。このため，サーブレットエンジンモードの場合は次の制限があります。

JP1連携は，Management Serverを利用した運用をしていることが前提となる機能です。このため，ベーシックモードで動作しているJ2EEサーバはJP1連携による管理の対象となりますが，サーブレットエンジンモードで動作しているサーバ（Webコンテナサーバ）はJP1連携による管理の対象にはなりません。なお，JP1連携による運用管理機能と動作モードは，直接関係ありません。

付録A.3　サーブレットエンジンモードとJ2EEサーバモードの比較

サーブレットエンジンモードは互換用のサーバの動作モードです。旧バージョンでサーブレットエンジンモードを使用していた場合には，推奨の動作モードであるJ2EEサーバモードの1.4モード（以降，J2EEサーバモードと呼びます）への移行をお勧めします。ここでは，移行時の留意事項として，サーブレットエンジンモードとJ2EEサーバモードを比較し，機能の差異およびシステムの構築方法の差異について説明します。

サーブレットエンジンモードからJ2EEサーバモードへ移行する場合には，次の差異に留意する必要があります。

システムの構築方法

Webアプリケーションのデプロイと設定

Webサーバの使用方法

データベースとの接続

Webアプリケーションに組み込むサーブレットフィルタ

Webアプリケーションのリロード

システムの起動および停止

使用するメモリ，スレッド数，ポート番号

＜この項の構成＞

(1)　システムの構築方法

(2)　Webアプリケーションのデプロイと設定

(3)　Webサーバの使用方法

(4)　データベースとの接続

(5)　Webアプリケーションに組み込むサーブレットフィルタ

(6)　Webアプリケーションのリロード

(7)　システムの起動および停止方法

(8)　使用するメモリ，スレッド数，ポート番号

(1)　システムの構築方法

サーブレットエンジンモードでは，Webコンテナサーバ用のusrconf.propertiesやusrconf.cfgを編集し，cjwebsetupなどのコマンドを実行してシステムを構築しますが，J2EEサーバモードでは次の3種類のシステム構築方法があります。

Smart Composer機能を使用して構築する
Smart Composer機能で提供するファイルおよびコマンドを使用し，推奨構成でシステムを構築します。システム構築の概要については，「16.　システムの構築」を参照してください。システム構築の詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

運用管理ポータルを使用して構築する
運用管理ポータルに設定内容を入力し，任意の構成でシステムを構築します。システム構築の概要については，「16.　システムの構築」を参照してください。運用管理ポータルでのシステム構築方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ファイル編集とコマンド実行によってシステムを構築する
J2EEサーバ用のusrconf.propertiesやusrconf.cfgを編集し，cjsetupなどのコマンドを実行し，任意の構成でシステムを構築します。システム構築の概要については，「16.　システムの構築」を参照してください。また，ファイル編集とコマンド実行でのシステム構築方法については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

どの方法でシステムを構築するかは，どのようなシステムを構築してどのように運用するかによって決定します。システム構築方法の検討については，マニュアル「Cosminexus　システム設計ガイド」を参照してください。

(2)　Webアプリケーションのデプロイと設定

サーブレットエンジンモードとJ2EEサーバモードでは，Webアプリケーションのデプロイおよび属性の設定方法が異なります。

(a)　Webアプリケーションのデプロイ

サーブレットエンジンモードとJ2EEサーバモードでは，Webアプリケーションのデプロイ方法が異なります。

サーブレットエンジンモードの場合
次のどちらかの方法で，WebアプリケーションをWebコンテナサーバにデプロイします。

WARファイルのコピー

ディレクトリのコピー

また，WARファイル，またはディレクトリを削除することで，アンデプロイできます。

J2EEサーバモードの場合
WebアプリケーションをJ2EEサーバにデプロイするためには，Webアプリケーションをアーカイブ形式，または展開ディレクトリ形式のJ2EEアプリケーションにしてからデプロイします。

Webアプリケーションからアーカイブ形式のJ2EEアプリケーションを作成し，J2EEサーバにインポートおよびデプロイします。

Webアプリケーションから展開ディレクトリ形式のJ2EEアプリケーションを作成し，J2EEサーバにインポートおよびデプロイします。

また，アーカイブ形式，または展開ディレクトリ形式のJ2EEアプリケーションをアンデプロイします。

サーブレットエンジンモードとJ2EEサーバモードのWebアプリケーションのデプロイおよびアンデプロイ方法の違いを次に示します。

項目 | サーブレットエンジンモードの場合 | J2EEサーバモードの場合
WARファイルのコピーの場合 | ディレクトリのコピーの場合 | アーカイブ形式の場合 | 展開ディレクトリ形式の場合
アセンブル | WAR形式にアセンブルする | アセンブルは不要 | EAR形式またはZIP形式にアセンブルする | アセンブルは不要
デプロイ／アンデプロイ単位 | WARファイル単位 | ディレクトリ単位 | EARファイルまたはZIPファイル単位 | ディレクトリ単位
入れ替えできる最小単位 | WARファイル単位 | JSPファイルやServletクラス単位 | EARファイルまたはZIPファイル単位 | JSPファイルやServletクラス単位
デプロイ／アンデプロイできるタイミング | Webコンテナサーバの起動中／停止中 | J2EEサーバの起動中
デプロイ／アンデプロイ結果の反映 | Webコンテナサーバの起動／再起動後 | デプロイ操作完了後

サーブレットエンジンモードからJ2EEサーバモードへ移行する場合には，サーブレットエンジンモードでのWebアプリケーションのデプロイ方法と操作性が近い，展開ディレクトリ形式によるデプロイ方法をお勧めします。

アーカイブ形式，または展開ディレクトリ形式のJ2EEアプリケーションについては，「7.　J2EEアプリケーションの実行」を参照してください。

(b)　Webアプリケーションの属性の設定

サーブレットエンジンモードの場合は，アプリケーション開発時にWebアプリケーションのDD（web.xml）を直接編集するか，またはhitachi_web.propertiesのキーを設定して，Webアプリケーションの属性を設定します。なお，WebアプリケーションのDD（web.xml）とhitachi_web.propertiesは，WebアプリケーションのWEB-INFディレクトリ下に置きます。

J2EEサーバモードの場合は，これらに加えて，次の方法でもWebアプリケーションの属性を設定できます。

システム構築時に，サーバ管理コマンドでJ2EEアプリケーションをJ2EEサーバにインポートし，属性ファイルを編集して属性を設定します。

システム構築時に，Server Plug-inでJ2EEアプリケーションをJ2EEサーバにインポートし，属性を設定します。

サーバ管理コマンドまたはServer Plug-inでは，J2EEアプリケーションの実行時間の監視や同時実行スレッド数の制御など，J2EEサーバの拡張機能の設定ができます。J2EEサーバモードの場合は，システム構築時にサーバ管理コマンドまたはServer Plug-inで設定する方法をお勧めします。サーバ管理コマンドまたはServer Plug-inの操作方法，および設定内容については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

なお，hitachi_web.propertiesの設定内容は，サーブレットエンジンモードとJ2EEサーバモードで異なります。

サーブレットエンジンモードとJ2EEサーバモードで同じ場合
JSPファイルのコンパイル結果の保持（webserver.jsp.keepgenerated）とTLDファイルの妥当性チェック（webserver.xml.validate）は，hitachi_web.propertiesまたはusrconf.propertiesで設定します。

サーブレットエンジンモードとJ2EEサーバモードで異なる場合
サーブレットエンジンモードの場合，Webアプリケーションのリロードの設定は，hitachi_web.propertiesまたはusrconf.propertiesで設定します。
J2EEサーバモードの場合，Webアプリケーションのリロードの設定は，usrconf.propertiesで設定します。J2EEサーバ用のhitachi_web.propertiesでは，Webアプリケーションのリロードの設定はできません。

(3)　Webサーバの使用方法

サーブレットエンジンモードとJ2EEサーバモードでは，Webサーバの使用方法が異なります。

サーブレットエンジンモードの場合 | J2EEサーバモードの場合
Webサーバと連携して使用する | Webサーバと連携して使用する
Webコンテナサーバ内の簡易Webサーバを使用する | J2EEサーバ内のインプロセスHTTPサーバを使用する

Webサーバと連携して使用する方法の場合，サーブレットエンジンモードからJ2EEサーバモードに移行するときは，設定内容には差異はありません。ただし，システムの構築方法によって設定方法が異なります。

Smart Composer機能を使用してシステムを構築する場合，Smart Composer機能で提供するファイルでWebサーバの設定をします。

運用管理ポータルを使用してシステムを構築する場合，運用管理ポータル上でWebサーバの設定をします。また，論理Webサーバとして使用できるのは，Hitachi Web Serverです。

ファイル編集とコマンド実行によってシステムを構築する場合，設定方法はサーブレットエンジンモードと同じです。設定の変更などは必要はありません。

簡易Webサーバを使用する方法の場合，J2EEサーバモードのインプロセスHTTPサーバに移行するときは，設定内容および設定方法が異なります。

Smart Composer機能を使用してシステムを構築する場合，インプロセスHTTPサーバは使用できません。

運用管理ポータルを使用してシステムを構築する場合，運用管理ポータル上でインプロセスHTTPサーバの設定をします。

ファイル編集とコマンド実行によってシステムを構築する場合，J2EEサーバ用のusrconf.propertiesにインプロセスHTTPサーバの設定をします。なお，簡易Webサーバを使用する方法でWebコンテナサーバ用のusrconf.propertiesのwebserver.connector.http.で始まるキーに設定していた内容は，インプロセスHTTPサーバではJ2EEサーバ用のusrconf.propertiesのwebserver.connector.inprocess_http.で始まるキーに設定します。

なお，インプロセスHTTPサーバでは，サーブレットエンジンモードの簡易Webサーバよりも機能が多く，同時実行スレッド数の制御などの機能も使用できます。インプロセスHTTPサーバについては，「4.3　インプロセスHTTPサーバによるリクエストの受け付け」を参照してください。

(4)　データベースとの接続

WebアプリケーションからJDBCを使用してデータベースに接続をする場合，サーブレットエンジンモードとJ2EEサーバモードではWebアプリケーションの実装方法および設定方法が異なります。

(a)　データベースとの接続に使用できるクラスとインタフェース

サーブレットエンジンモードのWebアプリケーションの場合，使用できるのはjava.sqlパッケージで定義されたクラス，インタフェースだけです。java.sql.DriverManagerクラスのgetConnectionメソッドを使ってデータベースコネクションを取得し，コネクションプール機能が使用できます。

J2EEサーバモードのWebアプリケーションの場合，java.sqlパッケージとjavax.sqlパッケージで定義されたクラス，インタフェースが使用できます。このうち，javax.sql.DataSourceクラスのgetConnectionメソッドを使ってデータベースコネクションを取得する方法をお勧めします。この場合，コネクションプール機能が使用でき，さらにローカルトランザクションやグローバルトランザクション配下でデータベースコネクションを使用できるようになります。

javax.sql.DataSourceクラスを使用してデータベースコネクションを取得する例を次に示します。

import javax.naming.InitialContext;
import javax.sql.DataSource;
import java.sql.Connection;

public void doPost(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, java.io.IOException {

・・・
 InitialContext ic = new InitialContext();              // JNDIの初期コンテキストの生成
 DataSource ds = (DataSource)ic.lookup(“java:comp/env/MyDB”);    // DataSourceをlookupにより取得
 Connection con = ds.getConnection();                   // DataSourceからコネクションを取得・・・
}

(b)　ルックアップの方法

J2EEサーバモードではjavax.sql.DataSourceクラスをJNDIのルックアップで取得します。ルックアップの実装および設定方法を次に示します。なお，ここでは，サーバ管理コマンドを使用した設定方法について説明します。

ルックアップ名称の定義
Webアプリケーションの開発時に，Webアプリケーションのlookupメソッドの引数に「java:comp/env/<<res-ref-name>タグ指定値>」と指定して実装します。

リソースの参照の定義
次のどちらかの方法でリソースの参照を定義します。

Webアプリケーションの開発時に定義します。WebアプリケーションのDD（web.xml）を編集し，<resource-ref>タグでリソースの参照を定義します。

システム構築時に定義します。サーバ管理コマンドでJ2EEアプリケーションをJ2EEサーバにインポートし，WebアプリケーションのWAR属性ファイルの<resource-ref>タグで，リソースの参照を定義します。

DB Connectorへの関連づけ
システム構築時に定義します。サーバ管理コマンドでJ2EEアプリケーションをJ2EEサーバにインポートし，WebアプリケーションのWAR属性ファイルの<resource-ref>タグ下の<linked-to>タグで，関連づけるDB Connectorの表示名を定義します。

なお，DB Connectorでは，ルックアップされるための設定は必要ありません。

(c)　コネクションプーリングの方法

J2EEサーバモードでは，WebアプリケーションはDB Connectorというリソースアダプタを経由してデータベースに接続します。DB Connectorは，Webアプリケーションに対してJDBCのインタフェースを提供します。また，DB Connectorを使用する場合，Webアプリケーションで開始したトランザクションの配下でデータベースに接続できます。

サーブレットエンジンモードで使用するjava.sql.DriverManagerでは，getConnectionメソッドの引数に与えるデータベースURLによって接続先データベースを指定しますが，J2EEサーバモードで使用するDB Connectorは，データベースとの接続方法やトランザクションの形態によって実装が分かれています。このため，用途に合わせてDB Connectorを選択し，接続先データベースやコネクションプーリングなどをDB Connectorのプロパティ（サーバ管理コマンドを使用する場合は，Connector属性ファイルに設定）に定義します。

サーブレットエンジンモードと同様にJ2EEサーバモードでもトランザクション管理なしでデータベースを使用する場合に，Cosminexus DABroker Libraryを使用するときは，次のDB Connectorを選択します。

DBConnector_DABJ_CP.rar
Cosminexus DABroker Library用のDB Connectorです。ローカルトランザクションを使用する場合，またはトランザクション管理なしで使用する場合（トランザクションのサポートレベルにLocalTransactionまたはNoTransactionを指定する場合）に選択します。Cosminexus DABroker LibraryのConnectionPoolDataSourceを使用してデータベースに接続します。接続可能なデータベースは，HiRDBとOracleです。

なお，DBConnector_DABJ_CP.rar以外のDB Connectorについては，「9.4.1　DB Connectorによる接続の概要」を参照してください。

(5)　Webアプリケーションに組み込むサーブレットフィルタ

サーブレットエンジンモードとJ2EEサーバモードでは，使用できるサーブレットフィルタ（built-inフィルタ）の種類と設定方法が異なります。

(a)　built-inフィルタの種類

サーブレットエンジンモードでは，HTTPレスポンス圧縮フィルタを使用できますが，J2EEサーバモードの場合は，これらに加えて，次のbuilt-inフィルタも使用できます。

セッションフェイルオーバ用フィルタ
セッションフェイルオーバ機能で使用するフィルタです。J2EEアプリケーションで実行中のセッション情報を管理します。

built-inフィルタについては，「4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

(b)　built-inフィルタの設定

サーブレットエンジンモードの場合は，アプリケーション開発時にWebアプリケーションのDD（web.xml）を直接編集し，built-inフィルタをWebアプリケーションに組み込みます。J2EEサーバモードの場合は，これに加えて，次の方法でもbuilt-inフィルタをWebアプリケーションに組み込むことができます。

システム構築時に，サーバ管理コマンドでJ2EEアプリケーションをJ2EEサーバにインポートし，属性ファイルを編集してフィルタを組み込みます。

システム構築時に，Server Plug-inでJ2EEアプリケーションをJ2EEサーバにインポートし，属性を設定してフィルタを組み込みます。

J2EEサーバモードの場合は，システム構築時にサーバ管理コマンドまたはServer Plug-inで設定する方法をお勧めします。

(6)　Webアプリケーションのリロード

サーブレットエンジンモードとJ2EEサーバモードでは，Webアプリケーションのリロード機能が異なります。サーブレットエンジンモードとJ2EEサーバモードでのリロード機能の違いを次に示します。

項目 | サーブレットエンジンモードの場合 | J2EEサーバモードの場合
リロード方法 | 更新検知によるリロード | 更新検知によるリロード，またはコマンド（cjreloadapp）によるリロード
リロードの対象範囲 | 更新があったファイル※1 | 更新があったファイルとそのファイルを参照するファイル
セッション情報の引き継ぎ | セッション情報を引き継ぐかどうか変更できる | 常にセッション情報を引き継ぐ
リロードの設定方法 | Webコンテナサーバのusrconf.properties，またはhitachi_web.properties | J2EEサーバのusrconf.properties※2

注※1

参照先のファイルが更新された場合，参照元のファイルは更新されません。

注※2

Smart Composer機能でシステムを構築する場合には，Smart Composer機能で提供するファイルにリロード機能の設定をします。運用管理ポータルでシステムを構築する場合には，運用管理ポータル上でリロード機能の設定をします。

リロード時のリクエストの処理や遅延実行など，このほかのWebアプリケーションのリロード機能には，違いはありません。

サーブレットエンジンモードのリロード機能については，「付録C.2　Webアプリケーションの更新検知とリロード」を参照してください。J2EEサーバモードのリロード機能については，「7.5　J2EEアプリケーションの更新検知とリロード」を参照してください。

サーブレットエンジンモードとJ2EEサーバモードのusrconf.propertiesで指定する，リロード機能のキーとそのデフォルト値の対応を次に示します。

設定項目
サーブレットエンジンモードでのusrconf.propertiesのデフォルト値※1
J2EEサーバモードでのusrconf.propertiesのデフォルト値

Webアプリケーションの更新検知
webserver.context.reloadable=false
ejbserver.deploy.context.reload_scope=none

Webアプリケーションの更新検知インターバル
webserver.context.check_interval=1
webserver.context.check_interval
デフォルト値はなし（ejbserver.deploy.context.check_intervalキーに設定した値（デフォルト値は0）を使用する）。

Webアプリケーションの構成ファイル更新用インターバル
webserver.context.update.interval=0
webserver.context.update.interval
デフォルト値はなし（ejbserver.deploy.context.update.intervalキーに設定した値（デフォルト値は0）を使用する）。

Webアプリケーションの遅延実行
webserver.context.reload_delay_timeout=0
webserver.context.reload_delay_timeout=0

JSPの更新検知インターバル
webserver.jsp.check_interval=1
webserver.jsp.check_interval
デフォルト値はなし（ejbserver.deploy.context.check_intervalキーに設定した値（デフォルト値は0）を使用する）。

JSPの構成ファイル更新用インターバル
webserver.jsp.update.interval=0
webserver.jsp.update.interval
デフォルト値はなし（ejbserver.deploy.context.update.intervalキーに設定した値（デフォルト値は0）を使用する）。

セッション情報の引き継ぎ
webserver.session.persistence.enabled=false
－※2

JSPの再コンパイルの有無
webserver.jsp.recompilable=false
－※2

注※1

hitachi_web.propertiesでもデフォルト値は同じです。ただし，webserver.context.check_intervalとwebserver.jsp.check_intervalは，hitachi_web.propertiesでは設定できません。

注※2

J2EEサーバモードのusrconf.propertiesには，対応するキーはありません。常にセッション情報が引き継がれます。JSPがリロード対象となっていて対象ファイルが更新された場合には，再コンパイルが実行されます。

サーブレットエンジンモードでの，Webアプリケーションの更新検知の有無（webserver.context.reloadable），およびJSPの再コンパイルの有無（webserver.jsp.recompilable）の組み合わせを次に示します。

リロード機能の動作 | webserver.context.reloadableキーの値 | webserver.jsp.recompilableキーの値
リロード機能を使用しない | false（デフォルト値） | false（デフォルト値）
サーブレットとJSPをリロードする | true | true
サーブレットだけをリロードする | true | false（デフォルト値）
JSPだけをリロードする | false（デフォルト値） | true

J2EEサーバモードでの，J2EEアプリケーションの適用の有無と適用範囲（ejbserver.deploy.context.reload_scope），Webアプリケーションの更新検知インターバル（webserver.context.check_interval），およびJSPの更新検知インターバル（webserver.jsp.check_interval）の組み合わせを次に示します。

リロード機能の動作 | ejbserver.deploy.context.reload_scopeキーの値 | webserver.context.check_intervalキーの値 | webserver.jsp.check_intervalキーの値
リロード機能を使用しない | none（デフォルト値） | 0 | 0
サーブレットとJSPをリロードする | web | 1以上 | 1以上
サーブレットだけをリロードする | web | 1以上 | 0
JSPだけをリロードする | web | 0 | 1以上

(7)　システムの起動および停止方法

サーブレットエンジンモードでシステムを起動および停止する場合には，cjstartwebコマンド，cjstopwebコマンド，cprfstartコマンドなどを使用します。

J2EEサーバモードの場合には，システムの構築方法によって，システムの起動および停止方法が異なります。

Smart Composer機能を使用して構築する場合
cmx_start_target，cmx_stop_targetなどのSmart Composer機能で提供するコマンドを使用して，Webシステム（サービスユニット，J2EEアプリケーション，リソースアダプタ）を一括起動，一括停止します。

運用管理ポータルを使用して構築する場合
運用管理ポータルの「論理サーバの起動／停止」と「論理サーバのアプリケーション管理」で，論理サーバ，J2EEアプリケーション，リソースアダプタを一括起動，一括停止します。

ファイル編集とコマンド実行によってシステムを構築する場合
cjstartsvコマンド，cjstopsvコマンドなどのコマンドを使用して，J2EEサーバなどの各サーバを一つずつ起動，停止します。サーバ管理コマンドを使用して，J2EEアプリケーション，リソースアダプタを起動，停止します。

注意

サーブレットエンジンモードとJ2EEサーバモードで，サーバ起動時の実行時保護機能のデフォルト値が異なるので注意してください。

サーブレットエンジンモードで，cjstartwebコマンドを使用してWebコンテナサーバを起動する場合，デフォルトでは実行時保護機能は無効（有効にする場合には-securityを指定）となっています。

J2EEサーバモードで，cjstartsvコマンドやcjstartrecoverコマンドを使用してJ2EEサーバを起動する場合，デフォルトでは実行時保護機能は有効（無効にする場合には-nosecurityを指定）となっています。

(8)　使用するメモリ，スレッド数，ポート番号

サーブレットエンジンモードとJ2EEサーバモードを比較する場合，J2EEサーバモードの方が，機能が多く，メモリやスレッド，ポートなどのリソースを多く消費します。このため，サーブレットエンジンモードからJ2EEサーバモードへ移行する場合には，注意してください。

各プロセスで使用するポートを次に示します。

WebコンテナサーバとJ2EEサーバのポートの対応

デフォルトのポート | 説明 | Webコンテナサーバプロセス | J2EEサーバプロセス※1
80（TCP） | インプロセスHTTPサーバのhttpポート | － | ○
8080（TCP） | 簡易Webサーバのhttpポート | ○ | －
管理用通信ポート | － | ○
8007（TCP） | Webサーバ（リダイレクタ）からのリクエスト受付ポート | ○ | ○
8005（TCP） | cjstopwebコマンドからのプロセス終了要求の受付ポート | ○ | －
900（TCP） | ネーミングサービスのリクエスト受付ポート | － | ○
浮動（TCP）※2 | EJBコンテナのリクエスト受付ポート | － | ○
浮動（TCP）※2 | サーバ管理コマンドのCUIとの通信ポート。 | － | ○
23152（TCP） | RMIレジストリのリクエスト受付ポート | － | ○
浮動（TCP）※2 | 運用監視エージェントの通信ポート | － | 　　○※3

（凡例）

○：使用する　－：使用しない

注※1

ここではJ2EEサーバプロセスのポートだけを説明しています。J2EEサーバモードの場合，CTMを使用する場合などで使用するポートが増えます。

注※2

デフォルトの設定です。固定に変更できます。

注※3

Management Serverと連携する場合だけ使用するポートです。

Hitachi Web Serverのポート

デフォルトのポート | 説明
80（TCP） | Hitachi Web Serverのhttpポート
443（TCP） | Hitachi Web Serverのhttpsポート

Management Serverのポート

デフォルトのポート | 説明
28080（TCP） | Management Serverのhttpポート
28005（TCP） | Management Serverの終了要求ポート（ホスト内通信に必要）
28009（TCP） | Management Serverの内部通信ポート（ホスト内通信に必要）

運用管理エージェントのポート

デフォルトのポート | 説明
20295（TCP） | Management Serverとの通信に使用するポート

付録B　ベーシックモードでのリソース接続

ここでは，ベーシックモードでのリソース接続について説明します。

＜この節の構成＞

付録B.1　接続できるリソースとトランザクションの管理方法

付録B.2　データベース接続の前提条件

付録B.3　データソースによるデータベースへの接続で使用できる機能

付録B.4　リソースへの接続テスト

付録B.5　JTAによるトランザクション実装時の注意事項

付録B.1　接続できるリソースとトランザクションの管理方法

ベーシックモードの場合に接続できるリソースの種類とトランザクションの管理方法について説明します。

＜この項の構成＞

(1)　接続できるリソース

(2)　トランザクションの管理方法

(1)　接続できるリソース

ベーシックモードで接続できるリソースについて次の表に示します。

表B-1　接続できるリソース（ベーシックモード）

リソースの種類 | ベーシックモード
データベース | HiRDB | ○
Oracle | ○
SQL Server | ×
XDM/RD E2 | ×
データベース上のキュー | HiRDB | ×
Oracle | ×
OpenTP1 | ×※
SMTPサーバ | ○
JavaBeansリソース | ○

（凡例）　○：接続できる　　×：接続できない

注※

リソースアダプタがNon-Managed環境での使用に対応している場合には，接続できる場合があります。ただし，Application Serverによるコネクションプーリングやトランザクション管理は利用できません。なお，TP1/Message Queueへの接続については，マニュアル「OpenTP1 Version 6 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」を参照してください。

(2)　トランザクションの管理方法

ベーシックモードでは，次のトランザクションを管理できます。

Application Serverが管理するトランザクションのローカルトランザクション

Application Serverが管理しないトランザクション

付録B.2　データベース接続の前提条件

ベーシックモードでデータベースに接続する場合の前提条件を，データベースの種類ごとに示します。

ベーシックモードの場合，データベース接続には，データソースを使用します。使用できるトランザクションの種類は，ローカルトランザクションだけになります。

なお，ベーシックモードでは，次のデータベースには接続できません。

Oracle10g

SQL Server

XDM/RD E2

＜この項の構成＞

(1)　HiRDBの場合

(2)　Oracle9iの場合

(3)　Cosminexus DABroker Libraryの文字コード設定

(1)　HiRDBの場合

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
データソースを使用して接続します。
なお，トランザクションの管理方法は，Application Serverが管理するトランザクション，またはApplication Serverが管理しないトランザクションのどちらかを選択できます。

(2)　Oracle9iの場合

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。Oracle JDBC Thin Driverでは接続できません。
JDBCドライバとしてCosminexus DABroker Libraryを使用する場合，Oracleクライアントをインストールする必要があります。

接続方法
データソースを使用して接続します。
なお，トランザクションの管理方法は，Application Serverが管理するトランザクション，またはApplication Serverが管理しないトランザクションのどちらかを選択できます。

(3)　Cosminexus DABroker Libraryの文字コード設定

Cosminexus DABroker Libraryを使用してデータベースに接続する場合，文字コードを設定できます。ベーシックモードの場合，usrconf.propertiesのejbserver.jdbc.propertyInfo.ENCODELANGキーに文字コードを設定します。

usrconf.propertiesの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

付録B.3　データソースによるデータベースへの接続で使用できる機能

ここでは，データソースによるデータベースへの接続機能について説明します。

なお，データソースの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

データソースを利用すると，J2EEサーバと連携して，J2EEアプリケーションから次に示す機能を利用できます。

＜この項の構成＞

(1)　サインオン

(2)　コネクション管理

(3)　トランザクション管理

(4)　オブジェクトの自動クローズ

(5)　パフォーマンスチューニングのための機能

(6)　フォールトトレランスのための機能

(7)　データソースを使用するときの注意

(1)　サインオン

データソースを利用した場合，サインオンの方式として，コンテナ管理のサインオンとコンポーネント管理のサインオンの両方を使用できます。ただし，コンポーネント管理でのサインオンの場合，トランザクションの種類によって使用が制限されます。

コンテナ管理でのサインオンの場合

コンテナ管理でのサインオンの場合には，データソースで設定したユーザ名とパスワードを使ってデータベースにアクセスします。

コンポーネント管理でのサインオンの場合

データベースへのアクセスはgetConnectionメソッドで渡されたユーザ名とパスワードを使ってデータベースにアクセスします。

(2)　コネクション管理

データベースの接続情報は，データソースを介してJ2EEサーバで管理され，コネクションプールにプーリングされます。

(3)　トランザクション管理

ローカルトランザクションでトランザクション管理されます。

トランザクションについては，「9.3.1(1)　Application Serverが管理するトランザクション」を参照してください。

(4)　オブジェクトの自動クローズ

データソースは，ユーザハンドル（java.sql.Connection）から生成された，Statementオブジェクト，PreparedStatementオブジェクト，CallableStatementオブジェクト，および各種ステートメントやDatabaseMetaDataから生成されたResultSetオブジェクトを自動クローズできます。

(5)　パフォーマンスチューニングのための機能

ベーシックモードでデータベースに接続する場合に，パフォーマンスチューニングのために使用できる機能を，次の表に示します。

表B-2　ベーシックモードでデータベースに接続する場合に使用できるパフォーマンスチューニングのための機能

機能 | 使用可否 | 機能差※1
コネクションプーリング | ○ | あり
コネクションシェアリング | ○※2 | なし
コネクションのアソシエーション | × | －
ステートメントプーリング | × | －
ライトトランザクション | × | －
インプロセストランザクションサービス | × | －
DataSourceオブジェクトのキャッシング | ○ | なし
DB Connectorのコンテナ管理でのサインオンの最適化 | × | －
受信バッファのプーリング | × | －

（凡例）○：使用できる　×：使用できない　－：該当しない

注※1　1.4モードとの機能差の有無です。

注※2　ベーシックモードでコネクションシェアリング機能を利用するには，コネクションプーリング機能を利用する必要があります。なお，標準DDの<res-sharing-scope>にUnshareableを指定してもコネクションシェアリングは有効です。

以降，ベーシックモードで使用できるパフォーマンスチューニングのための機能について説明します。なお，それぞれの機能の概要および目的については，「9.10　パフォーマンスチューニングのための機能」を参照してください。ここでは，ベーシックモードで特有の説明についてだけ説明します。

コネクションプーリング

J2EEサーバでは，JDBCデータソースごとにプールを作成して管理します。JDBCデータソースに最大値，最小値，増加，しきい値などを指定することで，プーリングの動作をカスタマイズできます。

J2EEコンポーネントがJDBCデータソースからJDBCコネクションを取得したとき，最小値分のJDBCコネクションが生成されプーリングされます。また，JDBCコネクションは最大値分までプーリングされます。プール中の未使用JDBCコネクションの数がしきい値分以下になったとき，新たに増加分のJDBCコネクションを取得してプールに補充します。プーリングされるJDBCコネクションの数は，J2EEコンポーネントからのデータベースアクセス量に応じて，最大値と最小値の間になります。

なお，JDBCコネクションプーリングは，同一JDBCデータソースに対して，引数なしのgetConnection()メソッドと引数ありのgetConnection(java.lang.String username,java.lang.String password)メソッド間では，別のプールになります。

また，引数ありのgetConnection(java.lang.String username,java.lang.String password)メソッド間でusernameが異なる場合，別のプールになります。なお，J2EEサーバ間のJDBCコネクションプーリングは，サポートしていません。

コネクションシェアリング

1.4モードとの機能差はありません。「9.10.2　コネクションシェアリング・アソシエーション」を参照してください。

DataSourceオブジェクトのキャッシング

1.4モードとの機能差はありません。「9.10.6　DataSourceオブジェクトのキャッシング」を参照してください。

(6)　フォールトトレランスのための機能

ベーシックモードでデータベースに接続する場合に，フォールトトレランスのために使用できる機能を，次の表に示します。

表B-3　ベーシックモードでデータベースに接続する場合に使用できるフォールトトレランスのための機能

機能 | 使用可否 | 機能差※
コネクションの障害検知 | × | －
コネクション枯渇時のコネクション取得待ち | × | －
コネクションの取得リトライ | ○ | なし
コネクションプールの情報表示 | ○ | あり
コネクションプールのクリア | ○ | なし
コネクションの強制クローズ | ○ | あり
コネクションの自動クローズ | ○ | あり
コネクションスイーパ | ○ | なし
トランザクションタイムアウト | × | －
トランザクションリカバリ | × | －
障害調査用SQLの出力 | × | －
コネクションプールのクラスタ化 | × | －

（凡例）○：使用できる　×：使用できない　－：該当しない

注※　1.4モードとの機能差です。

以降，ベーシックモードで使用できるフォールトトレランスのための機能について説明します。

なお，それぞれの機能の概要および目的については，「9.11　フォールトトレランスのための機能」を参照してください。ここでは，ベーシックモードで特有の説明についてだけ説明します。

コネクションの取得リトライ

1.4モードとの機能差はありません。「9.11.5　コネクションプールのクリア」を参照してください。

コネクションプールの情報表示

コネクションプール内のコネクションの情報を，コマンドを使用して表示できます。コネクションプール情報の表示には，cjclosecnコマンドを使用します。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

コネクションプールのクリア

1.4モードとの機能差はありません。「9.11.3　コネクションの取得リトライ」を参照してください。

コネクションの強制クローズ

アプリケーションのConnection.closeメソッドの記述もれによってクローズされないコネクションは，コネクションプール内で使用中状態のまま再利用されません。これらのコネクションは，cjclosecnコマンドを使用して強制クローズできます。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

コネクションの自動クローズ

EJBコンテナによるコネクション自動クローズだけが有効になります。また，対象となるリソースは，データソースだけです。

コネクションスイーパ

1.4モードとの機能差はありません。「9.11.7　コネクションスイーパ」を参照してください。

トランザクションタイムアウト

ローカル呼び出し最適化機能を使用するかどうかによって，トランザクションタイムアウト後のJTAおよびJDBCインタフェースにアクセスできない期間が異なります。
ローカル呼び出し最適化機能を使用しない場合，該当するトランザクションを含むリモートインタフェースのメソッドが終了すればアクセスできます。ローカル呼び出し最適化機能を使用する場合は，リクエスト終了するまでアクセスできません。

トランザクションタイムアウトが発生すると，トランザクションの状態がjavax.transaction.Status.STATUS_NO_TRANSACTIONになるため，Required属性，Supports属性，またはNever属性のビジネスメソッドが呼び出されます。トランザクションタイムアウト後にビジネスメソッドが呼び出されないようにするには，Mandatory属性を使用してください。ただし，ローカル呼び出し最適化機能を使用する場合は，トランザクションタイムアウト後に新しいトランザクションを開始できないので，タイムアウト後にRequired属性またはRequiresNew属性のビジネスメソッドは呼び出されません。

ローカル呼び出し最適化機能を使用して，タイムアウトの発生後にStateful Session Bean（BMT）を呼び出した場合，またはリモートインタフェースのメソッド呼び出し中（トランザクションがサスペンド中）にタイムアウトが発生した場合，J2EEアプリケーションにタイムアウトの発生を通知しません。
J2EEアプリケーションでこの内容を考慮していない場合，意図しないDBMSのアクセスによる，データの不整合などの問題が発生するおそれがあります。この問題を回避するため，ローカル呼び出し最適化機能を使用しないか，または次の対策を行ってください。
JTA，またはJDBCインタフェースのアクセスで例外が発生した場合，およびリモートインタフェースのメソッド呼び出しでRemoteException例外が発生した場合は，リクエストを終了させます。また，Stateful Session Bean（BMT）を使用する場合は，そのメソッド内で，JTA，JDBCインタフェースに対して，必ずアクセスします。

(7)　データソースを使用するときの注意

java.sql.Connectionを，複数のトランザクション間で再利用することはできません。java.sql.Connectionをトランザクション内で利用する場合には，トランザクションごとに，javax.sql.DataSourceからgetConnection()メソッドを使用してコネクションを取得してください。

java.sql.ConnectionのようなJDBCインタフェースのAPIでSQLException例外が発生すると，コネクションクローズで該当コネクションの接続が維持されていても，コネクションプールに戻さないで破棄します。その結果，余分なコネクション生成が発生して性能に影響を与えることがあります。

付録B.4　リソースへの接続テスト

データソースのプロパティ設定後，設定した内容が正しいかどうか，検証することができます。ここでは，接続テストでの検証項目と，接続テストの前提条件について説明します。

なお，接続テストの実行手順や，データソースの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

接続テストで検証される内容は，接続するリソースごとに異なります。

ベーシックモードの場合に，リソースごとの接続テストで検証できる内容を，次の表に示します。

表B-4　接続テストでの検証内容

リソースの種類
接続方法
接続テストでの検証内容

データベース
データソース

Driverを使用していること

Cosminexus DABroker Libraryの設定が正しいこと

データベースとの接続を確立できること

SMTPサーバ
メールコンフィグレーション

SMTPサーバへの接続を確立できること

付録B.5　JTAによるトランザクション実装時の注意事項

JTAを使用してトランザクションを実装したプログラムは，J2EEサーバの動作モードによって異なる動作をする場合があります。ベーシックモードの場合のプログラムの処理内容，および動作を次に示します。1.4モードの場合については，「9.17.5　JTAによるトランザクション実装時の注意事項」を参照してください。

表B-5　ベーシックモードの場合のJTAの動作

処理の内容
動作

EJB呼び出しで，java.rmi.RemoteExceptionまたはjava.rmi.RemoteExceptionを継承した例外が発生した場合

CORBAのシステム例外が発生した場合

クライアント側のトランザクションは，ロールバックにマークされません。

トランザクションタイムアウト発生後に，javax.transaction.UserTransaction.commitメソッドを呼び出した場合
java.lang.IllegalStateException例外が発生します。

トランザクションタイムアウト発生後にjavax.transaction.UserTransaction.rollbackメソッドを呼び出した場合
java.lang.IllegalStateException例外が発生します。

トランザクションタイムアウト後のjavax.transaction.UserTransaction.getStatusメソッドの戻り値
javax.transaction.Status.STATUS_NO_TRANSACTIONが返されます。

javax.ejb.SessionSynchronizationを実装したEJBのbeforeCompletionメソッド，またはafterCompletionメソッドからのEJB呼び出し
呼び出せません。呼び出すと，javax.transaction.SystemException例外が発生します。

付録C　サーブレットエンジンモードで使用できるWebコンテナの機能

Webコンテナは，J2EEサーバモードおよびサーブレットエンジンモードで使用されますが，動作モードによって使用できる機能および機能の内容が異なります。この章では，サーブレットエンジンモードで使用できるWebコンテナの機能について説明します。

Webコンテナでは，Webアプリケーションの実行機能を提供するコンテナの機能と，Webサーバと連携するためのリダイレクタの機能を提供しています。

サーブレットエンジンモードで使用できるWebコンテナの機能を次の表に示します。

表C-1　サーブレットエンジンモードで使用できるWebコンテナの機能

機能 | 参照先
Webアプリケーションの実行 | 付録C.1
アプリケーションの更新検知とリロード | 付録C.2
セッション管理機能のセッションIDおよびCookieへのサーバIDの付加※1 | 4.4.5
文字コード変換※1 | 4.5
JSPファイルのコンパイル結果の保持 | 付録C.3
アプリケーションのイベントリスナ※2 | 4.8，付録C.4
リクエストおよびレスポンスのフィルタリング※2 | 4.11，付録C.5
Webコンテナのセキュリティ管理※2 | 4.13，付録C.6
EJBコンテナとの連携※2 | 4.14，付録C.7
データベースとの接続 | 付録C.8
Webコンテナによるスレッドの作成 | 付録C.9
同時実行スレッド数の制御※2 | 4.17，付録C.10
ユーザスレッドの使用※1 | 付録C.11
通信タイムアウトの設定※1 | 4.22
Webサーバ（リダイレクタ）によるリクエストの振り分け※1 | 4.23
エラーページのカスタマイズ※1※3 | 4.24
ドメイン名指定でのトップページの表示※² | 4.25，付録C.12
Webコンテナへのゲートウェイ情報の通知※1 | 4.26
Webサーバ連携および簡易WebサーバでのIPアドレスの指定※1 | 4.27
静的コンテンツのキャッシュ※2 | 4.28，付録C.13
簡易Webサーバ機能 | 付録C.14

注※1

使用できる機能および使用方法は，J2EEサーバモードとの差異はありません。サーブレットエンジンモードの場合，J2EEサーバをWebコンテナサーバに置き換えてください。

注※2

これらの機能の概要については，動作モードの違いによる差異はありませんが，サーブレットエンジンモードの場合，使用方法や使用できる機能に差異があります。サーブレットエンジンモードの場合の差異については，「付録C　サーブレットエンジンモードで使用できるWebコンテナの機能」の各項を，機能の概要については，「4.　Webコンテナ」の各節を参照してください。

注※3

Webサーバとして，Hitachi Web Serverを使用する場合だけ使用できる機能です。Microsoft IISを使用する場合，この機能は使用できません。

Cosminexusで提供するWebコンテナの機能には，J2EEで規定された機能にCosminexus独自の機能を拡張したものと，Cosminexus独自の機能として提供しているものがあります。Cosminexus独自の機能かどうかについては，「2.　アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）」を参照してください。

以降の節で，サーブレットエンジンモードで使用できるWebコンテナの機能の詳細について説明します。

参考

アプリケーション開発時に，Cosminexusが提供するcjjsp2javaコマンドを使用することで，JSPファイルからJavaソースファイルを生成し，JSPに記述ミスがないかを確認できます。

＜この節の構成＞

付録C.1　Webアプリケーションの実行

付録C.2　Webアプリケーションの更新検知とリロード

付録C.3　JSPファイルのコンパイル結果の保持

付録C.4　アプリケーションのイベントリスナ

付録C.5　リクエストおよびレスポンスのフィルタリング

付録C.6　Webコンテナのセキュリティ管理

付録C.7　EJBコンテナとの連携

付録C.8　データベースとの接続

付録C.9　Webコンテナによるスレッドの作成

付録C.10　同時実行スレッド数の制御

付録C.11　ユーザスレッドで使用できるApplication Serverの機能

付録C.12　ドメイン名指定でのトップページの表示

付録C.13　静的コンテンツのキャッシュ

付録C.14　簡易Webサーバ機能

付録C.1　Webアプリケーションの実行

Webコンテナでは，Webアプリケーションを実行できます。ただし，サーブレットエンジンモードの場合，Java Servlet2.4仕様，およびJavaServer Pages（JSP）2.0仕様に準拠したWebアプリケーションは実行できません。また，Webコンテナを使用してWebアプリケーションを実行するには，必ずWebサーバとしてHitachi Web ServerまたはMicrosoft IISを使用する必要があります。

＜この項の構成＞

(1)　Webアプリケーションのデプロイとアンデプロイ

(2)　Webアプリケーションを実行する場合の留意事項

(1)　Webアプリケーションのデプロイとアンデプロイ

ここでは，サーブレットエンジンモードの場合のWebアプリケーションのデプロイおよびアンデプロイについて説明します。

(a)　Webアプリケーションのデプロイ

サーブレットエンジンモードの場合，WAR形式のWebアプリケーションをデプロイするには，次に示す二つの方法があります。

WARファイルのコピーによるデプロイ

ディレクトリのコピーによるデプロイ

Webアプリケーションのデプロイの手順については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

複数のWebアプリケーションのデプロイ

複数のWebアプリケーションをデプロイした場合，Webアプリケーションごとに独立のクラスローダが作成されます。このため，異なるWebアプリケーションで同一のクラス名のクラス（Loginサーブレットなど）を用いた場合でも，別々のクラスローダ上で独立に扱われます。

(b)　Webアプリケーションのアンデプロイ

サーブレットエンジンモードの場合，次に示す二つの方法があります。

WARファイルの削除によるアンデプロイ

ディレクトリの削除によるアンデプロイ

Webアプリケーションのアンデプロイの手順については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(2)　Webアプリケーションを実行する場合の留意事項

ここでは，Webアプリケーションを実行する場合の留意事項について説明します。

(a)　サーブレット/JSPのデフォルトマッピングについて

Java Servlet Specification v2.3では，クライアントがリクエストするURLに対してどのサーブレットが呼び出されるかの設定（サーブレットマッピング）をDD（WEB-INF/web.xml）内に記述するように求めていますが，Webコンテナでは，これ以外にも次に示すマッピングをデフォルトで定義しています。

URL | 取り扱い
*.jsp | JSPファイルとして取り扱われます。
/servlet/* | WEB-INF/classes以下にあるサーブレットクラス，またはWEB-INF/lib以下にあるJARファイルに含まれるサーブレットクラスが呼び出されます。

(b)　DD（WEB-INF/web.xml）内のタグが設定されていない場合のデフォルト値について

Webコンテナでは，次に示すタグがDD（WEB-INF/web.xml）に設定されていない場合，次に示すデフォルト値を使用します。

タグ名
設定されていない場合のデフォルト値

welcome-file-list

<welcome-file-list>
   <welcome-file>
       index.jsp
   </welcome-file>
   <welcome-file>
       index.html
   </welcome-file>
   <welcome-file>
       index.htm
   </welcome-file>
</welcome-file-list>

session-timeout
30

mime-mapping
拡張子とMIMEタイプとの対応付け。

DD（WEB-INF/web.xml）にこれらのタグを設定している場合には，次の設定となります。

<welcome-file-list>タグに設定された値が追加されます。

<session-timeout>タグに設定された値で，デフォルト値を上書きします。

<mime-mapping>タグに定義した拡張子単位の設定で，デフォルト値を拡張子単位に上書きします。

なお，DD（WEB-INF/web.xml）のmime-mappingタグにデフォルトで設定されている拡張子とMIMEタイプの対応づけについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(c)　サーブレットのインスタンス作成数

Webアプリケーション単位に同じクラスのサーブレットのインスタンスを一つ作成します。SingleThreadModelを継承したサーブレットのインスタンスも，一般のサーブレットと同様にWebアプリケーション単位に一つ作成します。

ただし，同一のサーブレットおよびJSPに対して，デフォルトのマッピングとDDに記述したマッピングの両方でアクセスすると，それぞれに別のインスタンスが生成されます。

また，SingleThreadModelを継承した単一のサーブレットに対して，Webアプリケーション単位にリクエストが並列に複数到着した場合，各スレッドがオーバラップしないで1スレッドずつ順に実行するように制御します。

(d)　クエリ文字列の解析について

クエリ文字列は，URLの?マーク以降に，"名前=値"の組が一つ以上組み合わさって構成されます。

Cosminexusでは，"名前=値"の部分に複数の"="がある場合，最初の"="より前の文字列が名前，後ろの文字列が値となります。例えば，URLが「http://host/examples?a=b=c」の場合は，「名前"a"の値は"b=c"」と解析されます。

付録C.2　Webアプリケーションの更新検知とリロード

サーブレットエンジンモードでは，Webコンテナ上のアプリケーションの更新を検知し，更新したアプリケーションをリロードする機能を備えています。この機能によって，Webコンテナサーバを再起動することなく，デプロイ済みのサーブレットやJSPを動的に入れ替えることができます。この機能は，Webアプリケーション開発時のテストを支援する機能として利用します。

リロード機能には，次の二つがあります。

Webアプリケーションのリロード機能
Webコンテナサーバ起動中にWebアプリケーションを更新すると，WebコンテナはWebアプリケーションが更新されたことを検知し，更新後のWebアプリケーションをリロードします。

JSPファイルの再コンパイル機能
Webコンテナサーバ起動中にJSPを更新すると，WebコンテナはJSPが更新されたことを検知し，更新後のJSPを再コンパイルします。

これらの機能によって，Webコンテナサーバにロード済み※のサーブレットまたはJSPを，Webコンテナサーバ起動中に更新後のサーブレットまたはJSPに置き換えができます。

注※

Webコンテナサーバの起動後にアクセスされたサーブレット/JSP，またはweb.xmlの<load-on-startup>タグに指定されているサーブレット/JSPを指します。

更新検知の対象となるファイル
Webアプリケーションのリロード機能およびJSPファイルの再コンパイル機能の対象は，webapps下にデプロイされたWebアプリケーションのディレクトリ下のファイルです。
webappsは，次の場所にあります。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名称>¥webapps

UNIXの場合
/opt/Cosminexus/CC/web/containers/<サーバ名称>/webapps

なお，WARファイルのコピーでのデプロイの場合，Webコンテナサーバ起動後に展開されたディレクトリ内のファイルが対象です。

Webアプリケーションのリロードと，JSPファイルの再コンパイルについて次に示します。

＜この項の構成＞

(1)　Webアプリケーションのリロード

(2)　リロードの動作に関する設定

(3)　JSPファイルの再コンパイル

(1)　Webアプリケーションのリロード

Webアプリケーションのリロードの条件について説明します。

(a)　Webアプリケーションのリロードの条件

Webコンテナサーバ起動後，更新検知対象のファイルが次に示す条件でリロードされます。

表C-2　リロードの条件

更新検知対象のファイル種別
リロードの条件

Windowsの場合

WEB-INF¥classesディレクトリ下のクラスファイルおよびリソースファイル（java.util.ResourceBundleによってロードされたファイルなど）

UNIXの場合

WEB-INF/classesディレクトリ下のクラスファイルおよびリソースファイル（java.util.ResourceBundleによってロードされたファイルなど）

ロード時の更新日時と異なる場合

ロードされたファイルが削除された場合

Windowsの場合

WEB-INF¥libディレクトリ下のJARファイル

UNIXの場合

WEB-INF/libディレクトリ下のJARファイル

ロード時の更新日時と異なる場合

JARファイルが追加された場合

JARファイルが削除された場合

(b)　リロード処理の流れ

Webアプリケーションの更新を検知して，リロードするまでの流れを次の図に示します。

図C-1　Webアプリケーションの更新検知からリロードまでの動作

Webアプリケーションを更新する

WebコンテナがWebアプリケーションの更新を検知する
Webコンテナは，設定した間隔でWebアプリケーションが更新されているかどうかチェックします。この間隔は，更新検知のインターバルで設定します。詳細については，「(2)(a)　更新検知のインターバル」を参照してください。
また，更新を検知してから，手順3.の処理を実施するまでのインターバルを設定できます。インターバルの設定については，「(2)(b)　リソース更新用インターバル」を参照してください。

新規リクエストを実行待ち状態にする
なお，処理中のリクエストはそのまま実行します。
デフォルトでは，新規リクエストを実行待ちにしますが，処理中のリクエストの処理が終わってから，新規リクエストを実行待ちにすることもできます。この場合，リロード遅延実行の設定が必要になります。リロード遅延実行については，「(2)(c)　リロード遅延実行（任意）」を参照してください。リロード遅延実行の設定は任意となります。

Webアプリケーションの終了処理をする
終了処理では次の処理が実行されます。

リロード前のクラスローダにローディングされたサーブレットのインスタンスが破棄されます。サーブレットがdestroyメソッドを実装している場合，destroyメソッドが実行されます。また，JSPファイルから生成されたサーブレットのインスタンスも破棄されます。この際，JSPファイルが，jspDestroyメソッドを実装している場合，jspDestroyメソッドが実行されます。

javax.servlet.ServletContextに登録されたオブジェクトは破棄されます。

セッション情報（javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクト）をシリアライズ※し，セッション情報ファイルに出力する
セッション情報を引き継ぐかどうかを設定できます。セッション情報を引き継ぎたい場合に指定してください。詳細については，「(2)(d)　リロード時のセッション引き継ぎ（任意）」を参照してください。

Webアプリケーション単位のクラスローダを新規に作成する
Webアプリケーションのリロード処理が実行されると，Webアプリケーション単位のクラスローダが新たに作成され，リロード後のリクエスト処理で使用されます。すでにロードされているサーブレットについては，destroyメソッドが実行され，インスタンスを破棄します。

セッション情報ファイルからセッション情報を読み込み，デシリアライズ※する
セッション情報ファイルからセッション情報を読み込み，リロード後のクラスローダ上でデシリアライズします。セッション情報の引き継ぎを設定している場合だけ実施されます。

セッション情報ファイルを削除する
セッション引き継ぎを指定している場合だけ実施されます。

Webアプリケーションの開始処理をする
リロード後は，初回アクセス時に更新後のサーブレットのインスタンスが作成され，initメソッドが実行されます。

リクエスト処理を再開する
3.で実行待ちにしていたリクエストの処理を再開します。

注※

シリアライズ処理，およびデシリアライズ処理の時間は，リロードを実行しているWebアプリケーション上で生成されたセッション数，javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクトの容量などに依存します。

(2)　リロードの動作に関する設定

アプリケーションの更新検知とリロード機能は，デフォルトの設定では実行されません。必要に応じて実行するように設定してください。

この機能では，次の動作をカスタマイズできます。

更新検知のインターバル

リソース更新用インターバル

リロード遅延実行（任意）

リロード時のセッション引き継ぎ（任意）

リロードの動作に関する設定は，Webコンテナサーバのプロパティ，またはWebコンテナ上で動作するWebアプリケーションプロパティとして設定します。アプリケーションの更新検知とリロードの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(a)　更新検知のインターバル

Webアプリケーションの更新を検知する間隔を設定できます。更新検知は，デーモンスレッドによって実行されます。デフォルトでは1秒間隔となっています。

更新検知インターバルの値を大きくすると，構成ファイルを監視する間隔が長くなり，ファイル更新後のリロードの反映が遅くなります。また，値を小さくすると，リロードの反映が早くなります。

ポイント

更新検知の対象となるファイル数が増えると，更新検知処理のオーバーヘッドが大きくなり，CPU使用率が高くなります。このような場合は，更新検知インターバルを変更することによって，性能への影響が小さくなります。更新検知インターバルの値は大きくすることをお勧めします。

(b)　リソース更新用インターバル

Webアプリケーションの更新を検知してから，処理中のリクエスト数の監視を実施するまでの時間を設定できます。

Webコンテナは，ファイル（リソース）の更新を検知すると，更新するファイルをコピーし，処理中のリクエスト数の監視を開始します。処理中のリクエストの処理が完了すると，コピーしたファイルをロードします。ファイルの容量が大きい場合，ネットワークを経由した場合や，ファイルが複数ある場合には，ファイルコピーなどの処理時間が長くなることがあります。このとき，ファイルコピーが完了する前に処理中のリクエストがなくなると，ファイルコピー中にロードが開始されて，ロードに失敗するおそれがあります。これを回避するため，ファイルコピーに掛かる時間を考慮してコピーが完了してからロードが開始されるように，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間をリソース更新用インターバルとして設定しておくことができます。

ポイント

リソース更新用インターバルには，実際に掛かるコピー時間にゆとりを持たせた時間を設定することをお勧めします。

複数のファイルを同時に更新する場合，複数のファイルの更新に掛かる時間を算出して，設定してください。

(c)　リロード遅延実行（任意）

ファイル（リソース）の更新を検知してから，リロードを開始するまでの時間を設定できます。リロード遅延実行の時間を設定している場合に，Webアプリケーションの更新を検知すると，リロードの開始を遅延実行に指定した時間まで遅らせます。指定した時間内に処理中のリクエストがなくなるか，または指定した時間がくると，アプリケーションのサービスを停止してリロードを開始します。これによって，処理中のリクエストの実行待ち時間を減らすことができるため，アプリケーションのサービス停止期間を最小限にできます。

なお，デフォルトでは，リロード遅延実行が設定されていません。デフォルトでは次のような動作となります。

Webコンテナがリソースの更新を検知すると，アプリケーションのサービスを停止する

リクエストを次のように処理する

新規のリクエスト：実行待ちにする

処理中のリクエスト：すべてのリクエストを処理する

処理中のリクエストの処理が完了すると，リロードが実施される

リロードの遅延実行が設定されていないと，アプリケーションのサービス停止の期間が長くなります。これを回避するため，リロード遅延実行を設定することをお勧めします。

リロード遅延実行を設定した場合と設定しない場合の，アプリケーションのサービス停止期間の違いを，次の図に示します。

図C-2　アプリケーションのサービスの停止期間の違い

(d)　リロード時のセッション引き継ぎ（任意）

Webアプリケーションのリロード実行前に生成したセッション情報を，リロード後も継続して利用するかどうかを設定できます。これによって，リロード前にjavax.servlet.http.HttpSessionオブジェクトに登録されているオブジェクトを，リロード後も引き続き利用できるようになります。セッションの情報は，シリアライズされてセッション情報ファイルに出力されます。セッション情報ファイルは，リロード処理開始時に作成されます。そして，リロード後にセッション情報がクラスローダ上でデシリアライズされ，セッション情報ファイルはリロード処理完了時に削除されます。

なお，セッション引き継ぎ機能を使用しない場合，リロード処理が実行されるとセッション情報はすべて失われます。

(e)　注意事項

Webアプリケーションのリロード機能を使用する際の，注意について説明します。

●リロード機能の使用に関する注意

Webアプリケーションのリロード機能を使用する場合，web.xmlに<error-page>タグを定義しないでください。

Webアプリケーションのリロード機能を使用する場合，WebアプリケーションからJNIを利用することはできません。リロード処理ではWebアプリケーション単位のクラスローダを置き換えますが，JNIの仕様では，異なるクラスローダ上で同じネイティブライブラリをロードできないという制限があるためです。

Webアプリケーションのリロード機能は，Webアプリケーション単位のクラスローダを入れ替えることによって，Webコンテナ起動中のWebアプリケーションの入れ替えを実現しています。そのため，リロード後にリロード前のWebアプリケーション単位のクラスローダ，またはWebアプリケーション単位のクラスローダでロードされたクラスが参照されるとメモリリークが発生します。
次に，該当する場合を示します。

スレッドの生成
スレッドはコンテキストクラスローダを保持しますが，デフォルトでは親スレッドのコンテキストクラスローダを保持します。Webアプリケーション実行時のスレッドは，Webアプリケーション単位のクラスローダをコンテキストクラスローダとしているため，生成されたスレッドはWebアプリケーション単位のクラスローダをコンテキストクラスローダとします。そのため，リロード後も該当スレッドが存在すると，リロード前のWebアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

java.lang.Threadクラスまたはその派生クラスのインスタンス生成
java.lang.Threadクラスまたはその派生クラス（以降，スレッドクラス）のインスタンスを作成すると，所属するスレッドグループから該当スレッドクラスのインスタンスが参照されます。スレッドグループからの参照は，スレッドの実行を終了（runメソッドの完了）すると解放されます。そのため，Webアプリケーション内でスレッドクラスのインスタンスを生成し，runメソッドを実行しなかった場合は，該当スレッドクラスのインスタンスが解放されません。また，スレッドはコンテキストクラスローダとしてWebアプリケーション単位のクラスローダを保持しているため，Webアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

スレッドローカル変数の使用
Webコンテナではリクエストを処理するスレッドはプールされていて，Webコンテナ終了時まで終了しません。そのため，スレッドローカル変数にWebアプリケーションに含まれるクラスのインスタンスを格納すると，メモリリークが発生します。

Webアプリケーション外からの参照
usrconf.cfg（Webコンテナサーバ用オプション定義ファイル）のweb.add.class.pathキーで指定したクラスパスに存在するクラスは，システムクラスローダからロードされます。リロード実行時に該当クラスはアンロードされません。
このため，該当クラスのクラス変数からWebアプリケーション単位のクラスローダ，またはWebアプリケーション単位のクラスローダでロードされたクラスを参照すると，メモリリークが発生します。

Webアプリケーションのリロード機能と，JSPの再コンパイル機能を併用する場合，次のことに注意してください。

JSPファイルだけを更新した場合，Webアプリケーションのリロードは実行されません。

JSPファイルの再コンパイルが実行されている場合には，リロード処理でのJSPの再コンパイルは停止されることがあります。この場合，JSPファイルの再コンパイルは，リロード完了後の該当するJSPに対して初めてアクセスするときに実行されます。また，web.xmlの<load-on-startup>タグに該当するJSPファイルが指定されている場合は，リロード処理内のWebアプリケーションの初期化処理で実行されます。

●リソースの更新に関する注意

次の場合にはメモリ不足が発生するおそれがあるため，リソースの更新はリクエストのピーク時など負荷の高いときを避けて実施してください。

リロードの処理は，クラスローダを再作成してクラスをロードし直すため，メモリを多く消費します（ただし，消費するメモリ使用量は，Webアプリケーションの実装に依存します）。そのため，例えば，複数のWebアプリケーションで，同時にリロード処理を繰り返すと，メモリ不足が発生するおそれがあります。

リロード処理によって不要になったリソースがJavaVMから解放されるタイミングは，JavaVMのガーベージコレクションの実行のタイミングに依存します。リクエストのピーク時など，負荷が高いときにリロードを繰り返すと，ガーベージコレクションを実行するタイミングがなく，メモリ不足が発生するおそれがあります。

複数のリソースを更新する場合，リソース更新用インターバルに，複数のリソースの更新（ファイルコピー）に掛かる時間を指定してください。なお，いったん，リソースを更新したら，リロード処理が完了する前に別のリソースを更新しないようにしてください。

ロード済みのリソース（ファイル）を削除した場合もWebアプリケーションに対する変更と判断されるため，リロードが実行されます。このため，不用意にリソースを削除しないよう，注意してください。

●リロード処理実行時の注意

Webアプリケーションのリロード処理が実行されると，Webアプリケーション単位のクラスローダを置き換えるため，リロード前に作成されたインスタンスをリロード後のサーブレットから使用できません。

更新前のサーブレットがjavax.servlet.ServletContextに登録したオブジェクトはクリア（削除）されます。更新前のサーブレットが生成したセッションは破棄され，更新後のサーブレットにアクセスすると新しいセッションが生成されます。さらに，Webアプリケーションのリロード時には，そのときロードされているJSPもリロードされます。

Webアプリケーションのリロード機能を使用すると，更新検知処理のためのオーバーヘッドが発生し，監視対象のファイル数の増加に伴ってオーバーヘッドが大きくなるため，更新検知間隔を変更して性能への影響を小さくする必要があります。

リロード処理中に，cjstopwebコマンドでWebコンテナサーバに対して終了要求を発行した場合は，次のように動作します。

リロード処理内のWebアプリケーションの初期化処理の開始前の場合
リロード処理を中断し，終了処理が実行されます。

リロード処理内のWebアプリケーションの初期化処理の開始後の場合
リロード処理完了後に，Webコンテナサーバの終了処理が実行されます。このとき，リロード処理による実行待ちのリクエストはエラーになります。

●リロードの処理時間に関する注意

リロード処理時間は，Webアプリケーションの実装に大きく依存します。このため，次の点に注意が必要です。

セッション情報の容量は，シリアライズ処理時間，デシリアライズ処理時間に大きく影響します。シリアライズ対象となるセッション情報は，必要十分な容量にしてください。

リロード処理では，Webアプリケーションの終了処理，初期化処理が実行されます。終了処理，初期化処理が長い場合，リロードの処理時間も長くなり，Webアプリケーションのサービス停止期間にも影響があるため注意してください。ただし，リロード処理で初期化処理が実行されるのは，web.xmlの<load-on-startup>タグを設定したサーブレットやJSPだけです。<load-on-startup>タグを設定していないサーブレットやJSPの初期化処理は，リロード完了後の初回アクセス時に実行されます。

●セッション引き継ぎ機能を使用する場合の注意

リロード時のセッション引き継ぎ機能を使用する場合，javax.servlet.http.HttpSessionに登録するセッション情報は，シリアライズできるオブジェクトである必要があります。

HttpSessionオブジェクトに登録したオブジェクトから参照するオブジェクトは，transientで宣言されているか，またはシリアライズできるオブジェクトである必要があります。以降，参照するオブジェクトも同様です。シリアライズできるオブジェクトについての詳細は，J2SEの仕様書を参照してください。

セッション情報としてシリアライズできないオブジェクトを登録した場合は，エラーが発生します。エラーの内容はオブジェクトによって異なります。

javax.servlet.http.HttpSessionに登録したオブジェクトの場合
HttpSessionオブジェクトに登録したオブジェクトが，シリアライズできないオブジェクトである場合，該当するオブジェクトだけを破棄します。破棄されたオブジェクトは，リロードが完了したあとに使用することはできません。また，該当するオブジェクトが，javax.servlet.http. HttpSessionBindingListenerインタフェースを実装していても，Webコンテナからアンバインドされたイベントは通知されません。

javax.servlet.http.HttpSessionに登録したオブジェクトから参照されるオブジェクトの場合
HttpSessionに登録したオブジェクトから参照されるオブジェクトがシリアライズできないオブジェクトの場合，すべてのセッション情報が破棄されます。HttpSessionに登録したオブジェクトから参照されるオブジェクトが，HttpSessionに登録したオブジェクトの場合も同様に，すべてのセッション情報が破棄されます。

シリアライズ対象となるセッションに登録したオブジェクトのクラス，およびそこから参照されるオブジェクトのクラスを，デシリアライズできない構成に更新してリロードを実行した場合，セッションのデシリアライズに失敗します。デシリアライズに失敗すると，Webアプリケーション上のすべてのセッション情報が破棄されるので注意してください。

(3)　JSPファイルの再コンパイル

WebコンテナにロードされたJSPファイルの更新日時がロード時と異なる場合，再コンパイルされるように設定できます。ただし，JSPファイルから生成されたJavaファイル，またはクラスファイルを更新しても，再コンパイルの対象にはなりません。

JSPの再コンパイル機能は，デフォルトの設定では実行されません。必要に応じて実行するように設定してください。

この機能では，次の動作をカスタマイズできます。

更新検知のインターバル

JSPファイル更新用インターバル

JSPファイルの再コンパイルに関する設定は，Webコンテナサーバのプロパティ，またはWebコンテナ上で動作するWebアプリケーションプロパティとして設定します。アプリケーションの更新検知とリロードの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

(a)　更新検知のインターバル

JSPファイルの更新を検知する間隔を指定できます。更新検知は，デーモンスレッドによって実行されます。デフォルトでは1秒間隔となっています。

ポイント

更新検知の対象となるファイル数が増えると，更新検知処理のオーバーヘッドが大きくなり，CPU使用率が高くなります。このような場合は，更新検知インターバルを変更することによって，性能への影響が小さくなります。更新検知インターバルの値は大きくすることをお勧めします。

(b)　JSPファイル更新用インターバル

JSPファイル更新用インターバルとは，JSPファイルの更新を検知してから，JSPファイルをコンパイルするまでの間隔を指します。

設定の指針

JSPファイル更新用インターバルには，実際にファイルのコピーに掛かる時間よりも長い時間を設定することをお勧めします。

複数のファイルを同時に更新する場合，複数のファイルの更新に掛かる時間を算出して，設定してください。

(c)　注意事項

JSPファイルの再コンパイル機能を使用すると，更新検知処理のためのオーバーヘッドが発生します。監視対象のJSPファイル数が増えると，オーバーヘッドも大きくなります。この場合は，更新検知間隔を長くすることで，性能への影響を少なくできます。

includeディレクティブを使用してインクルードされたJSPファイルを更新しても，インクルード元のJSPファイルは再コンパイルされません。再コンパイルを実行する場合には，インクルード元のJSPファイルを更新してください。

付録C.3　JSPファイルのコンパイル結果の保持

JSPは，Webコンテナ上でコンパイルされ，Javaソースファイルおよびクラスファイルが生成されます。Webコンテナでは，JSPのコンパイル結果である，Javaソースファイルおよびクラスファイルを，Webコンテナサーバの再起動時に保持するかどうか設定できます。

JSPのコンパイル結果の保持機能は，デフォルトの設定では実行されません。必要に応じて実行するように設定してください。

JSPのコンパイル結果の保持に関する設定は，Webコンテナサーバのプロパティをカスタマイズして設定します。Webコンテナサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

ここでは，コンパイル結果が生成，削除されるタイミングについて説明します。また，Webアプリケーションがアンデプロイされた場合，およびJSPファイルが更新された場合のJSPコンパイル結果の動作についても説明します。

＜この項の構成＞

(1)　コンパイル結果の生成

(2)　コンパイル結果の削除

(3)　Webアプリケーションアンデプロイ時の動作

(4)　JSPファイルを更新する場合の動作

(1)　コンパイル結果の生成

JSPのコンパイル結果は，次のタイミングで生成されます。

JSPへの初回アクセス時

DD（web.xml）でJSPに対し<load-on-startup>が指定されているWebアプリケーションの開始時

(2)　コンパイル結果の削除

JSPのコンパイル結果は，次のタイミングで削除されます。

Webコンテナサーバの起動時※1

Webコンテナサーバの終了時※2

注※1

次のどちらかの場合にだけ削除されます。

JSPコンパイル結果を保持しない設定にしている場合

JSP用テンポラリディレクトリにJSPコンパイル結果が保持されている場合
これは，サーバが強制終了された場合に備えて実施されます。

注※2

JSPコンパイル結果保持を無効にした場合だけ削除します。

(3)　Webアプリケーションアンデプロイ時の動作

サーブレットエンジンモードの場合，WebアプリケーションをアンデプロイしてもJSPコンパイル結果は削除されません。このため，JSPのコンパイル結果を保持する設定でWebコンテナを稼働したあとにJSPコンパイル結果が不要となった場合，またはWebアプリケーションをアンデプロイした場合は，JSPのコンパイル結果を手動で削除する必要があります。削除方法について次に示します。

削除方法

JSPコンパイル結果の削除をするには，Webコンテナサーバ終了後に，削除対象のWebアプリケーションのJSP用テンポラリディレクトリに作成されるWebアプリケーション単位のディレクトリ以下を削除します。JSP用テンポラリディレクトリは，usrconf.propertiesで設定します。

(4)　JSPファイルを更新する場合の動作

サーブレットエンジンモードでは，JSPファイルを直接編集，またはファイルの上書きで更新できます。JSPコンパイル結果を保持している状態では，JSPの初回ロード時に，保持されたクラスファイルをロードする場合と，更新されたJSPファイルのコンパイル結果であるクラスファイルをロードする場合があります。どちらのクラスファイルをロードするかについては，更新されたJSPファイルと，保持されたクラスファイルの更新日時によって次のように決まります。

更新されたJSPファイルの更新日時が，保持されたクラスファイルの更新日時より新しい場合，保持されたクラスファイルは使用されません。このため，JSPのコンパイルが実行され，コンパイル後のクラスファイルがロードされます。

更新されたJSPファイルの更新日時が，保持されたクラスファイルの更新日時よりも古い場合，保持されたクラスファイルがそのままロードされます。

付録C.4　アプリケーションのイベントリスナ

Webアプリケーション単位でのイベントリスナ機能があります。アプリケーションイベントリスナは，Webアプリケーションのデプロイ時にインスタンス化されます。インスタンス化されたアプリケーションイベントリスナは，サーブレットコンテキストオブジェクトまたはセッションオブジェクトのどちらか一方，または両方の状態変化イベントを受け取ります。リスナオブジェクトが受け取るイベントを次に示します。

セッションオブジェクトの新規生成

セッションオブジェクトのシリアライズ前※

セッションオブジェクトのデシリアライズ後※

セッションオブジェクトの抹消

セッションオブジェクトの属性の追加，削除，変更

サーブレットコンテキストオブジェクトの生成

サーブレットコンテキストオブジェクトの抹消

サーブレットコンテキストオブジェクトの属性の追加，削除，変更

注※

サーブレットエンジンのベンダ独自処理の都合で，セッションオブジェクトをシリアライズして格納，通信し，別の時点でデシリアライズして処理を再開することが，Servlet APIでは想定されています。

セッションオブジェクトに，これらのイベント通知が設けられている意図は，セッションオブジェクトにデータだけでなく，データベースコネクションやオブジェクトリファレンスなどの資源を持たせられるようにするためです。セッションオブジェクトに資源を持たせるような設計のアプリケーションでは，シリアライズの前にいったん資源を解放し，デシリアライズ後に再び獲得するようにしなければなりません。

セッションオブジェクトに資源を持たせるという構成は，注意深く利用しないとサーバ全体の必要資源量を大幅に増大させてしまい，資源が不足するおそれがあります。このため，イベントリスナ機能は，資源を確保できる場合に利用してください。

付録C.5　リクエストおよびレスポンスのフィルタリング

サーブレット/JSPの，リクエストやレスポンスに対してフィルタリングをする機能です。この機能によって，サーブレット/JSPの実行前のリクエスト，または実行後のレスポンスをラップして，データの変更，リソースに対するトレースの取得などができます。

Cosminexusでは，Cosminexus独自の機能を使用するためのサーブレットフィルタを提供しています。Cosminexusが提供するサーブレットフィルタを，built-inフィルタといいます。

Cosminexusで提供しているサーブレットフィルタ（built-inフィルタ）のうち，サーブレットエンジンモードで使用できるのは，HTTPレスポンスの圧縮機能を使用するためのbuilt-inフィルタです。

サーブレットエンジンモードで使用できるbuilt-inフィルタの種類を次の表に示します。また，Webアプリケーションにbuilt-inフィルタを組み込むことによって使用できる機能の参照先をあわせて示します。

表C-3　サーブレットエンジンモードで使用できるbuilt-inフィルタの種類

built-inフィルタの種類 | 機能 | 参照先
HTTPレスポンス圧縮フィルタ | サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスをgzip形式に圧縮します。 | 4.12

なお，built-inフィルタは，HTTPリクエストおよびHTTPレスポンスへの作用や，フィルタ連鎖の順序制約などを考慮して，Webアプリケーションに組み込む必要があります。built-inフィルタに関する制約については，「4.11.1　Cosminexusが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

付録C.6　Webコンテナのセキュリティ管理

Webコンテナのセキュリティ管理は，次の内容を除き，J2EEサーバモードの場合と同様です。このため，セキュリティ管理の概要については，「4.13　Webコンテナのセキュリティ管理」もあわせて参照してください。

ここでは，J2EEサーバモードとの差異のある機能について説明します。

＜この項の構成＞

(1)　ロールに基づくWebコンテナのユーザ認証

(2)　SecurityManagerによるWebコンテナの実行時の保護

(1)　ロールに基づくWebコンテナのユーザ認証

サーブレットエンジンモードの場合，Webコンテナのユーザ認証で使用するユーザ情報の管理方法が，J2EEサーバモードとは異なります。

Webコンテナでは，ユーザ情報として，各ユーザのユーザ名，パスワード，および所属するロールを保持，管理します。これらの情報を保持，管理するために，サーブレットエンジンモードでは，次に示す場所に各ユーザのユーザ名，パスワード，および所属するロールを記述します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥web¥containers¥<サーバ名称>¥usrconf¥web-users.xml

UNIXの場合
/opt/Cosminexus/CC/web/containers/<サーバ名称>/usrconf/web-users.xml

記述例を次に示します。

<web-users>
 <user name="user1"  password="user1" roles="regular" />
 <user name="admin" password="admin" roles="admin" />
</web-users>

なお，web-users.xmlの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

(2)　SecurityManagerによるWebコンテナの実行時の保護

Java2のSecurityManagerに基づいたWebコンテナの実行時保護を実現します。これによって，次に示すような現象を防ぐことができます。

内部でSystem.exit()などを発行するような，不正なサーブレット，JSPによってWebコンテナ全体が勝手に終了する。

システムプロパティなどを勝手に書き換えるような不正なサーブレット，JSPによって，Webコンテナの実行に不具合が生じる。

サーブレットエンジンモードの場合，-securityオプションを指定して，cjstartwebコマンドを実行することでWebコンテナの保護が有効になります。なお，Webコンテナの実行時の保護機能を使用すると，サーブレットまたはJSPファイルから，EJBを呼び出すことができないので注意してください。

付録C.7　EJBコンテナとの連携

ここでは，サーブレットエンジンモードの場合のEJBコンテナとの連携について説明します。

＜この項の構成＞

(1)　Enterprise Beanの呼び出し方法

(2)　JSPからのEnterprise Beanを呼び出すときのRMI-IIOP通信のタイムアウトを設定するときの注意

(1)　Enterprise Beanの呼び出し方法

WebコンテナはEJBコンテナと連携して，J2EEサーバとして動作します。なお，EJBコンテナとの連携については，J2EEサーバモードの場合と同じです。

ここでは，サーブレットエンジンモード固有のEnterprise Beanの呼び出し方法についてだけ説明します。これ以外のEnterprise Beanの呼び出し方法については，「4.14.1　Enterprise Beanの呼び出し方法」を参照してください。また，Enterprise Bean呼び出しの準備については，「4.14.2　Enterprise Bean呼び出しの準備」を参照してください。

Enterprise Beanを呼び出すサーブレット/JSPがWebコンテナサーバで動作している場合

Enterprise Beanを呼び出すサーブレットがWebコンテナサーバで動作しているとき，次の例に示すようにEnterprise Beanを呼び出します。例を次に示します。

例：

Context ctx = new InitialContext();
Object o =
ctx.lookup("HITACHI_EJB/SERVERS/MyServer/EJB/APName/Cart");
CartHome h = (CartHome)PortableRemoteObject.narrow(o, CartHome.class);
Cart c = h.create();
c.call();

(2)　JSPからのEnterprise Beanを呼び出すときのRMI-IIOP通信のタイムアウトを設定するときの注意

Enterprise Beanを呼び出すとき，RMI-IIOP通信にタイムアウトを設定できます。RMI-IIOP通信のタイムアウト時間の設定方法は，Enterprise Beanがどこから呼び出されるかによって異なります。

Enterprise Beanを呼び出すEJBクライアントの形態がJSPやサーブレットの場合で，サーブレットエンジンモードで動作するWebコンテナを利用するときは，クライアント側のJSP，サーブレットが動作するWebコンテナサーバのプロパティをカスタマイズして設定します。Webコンテナサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。また，RMI-IIOP通信のタイムアウトの概要については，「5.9.4　RMI-IIOP通信のタイムアウト」を参照してください。

付録C.8　データベースとの接続

サーブレットエンジンモードでWebコンテナを利用している場合，WebアプリケーションからCosminexus DABroker Libraryを通じ，Sun JDBC API仕様に従ったデータベースアクセスができます。ただし，使用時には次に示す点に注意する必要があります。

java.sqlパッケージで定義されたクラス，インタフェースだけが使用できます。

java.sql.DriverManagerクラスのgetConnectionメソッドを使ってデータベースコネクションを取得します。

コネクションシェアリング，および分散トランザクションはサポートしていません。

コネクションプール機能を使用できます。コネクションプールの詳細については，「付録D.3(2)　パフォーマンスチューニングのための機能」を参照してください。

Cosminexus DABroker Libraryを使用したデータベースアクセスの詳細については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

付録C.9　Webコンテナによるスレッドの作成

Webコンテナでは，Webサーバ連携のためのスレッド，Webアプリケーションのためのスレッドなどを作成します。これらのスレッドに対して，システムのリソースが十分であるか検討します。

ここでは，サーブレットエンジンモードの場合の，Webコンテナが作成するスレッドについて説明します。

＜この項の構成＞

(1)　作成されるスレッドの種類と数

(2)　作成されるスレッドの総数

(1)　作成されるスレッドの種類と数

Webコンテナが作成するスレッドを次に示します。

(a)　Webサーバ連携のためのスレッド

●Webコンテナの簡易Webサーバを使用する場合（任意）

作成するスレッド

TCPのコネクション接続要求を受信するスレッド，および受信したリクエスト処理用スレッドを作成します。

スレッドの数

TCPのコネクション接続要求を受信するスレッドは，1スレッドです。簡易Webサーバが受信したリクエスト処理用スレッドは，最小5スレッド，最大100スレッドです。

リクエスト処理用スレッドは，起動時に5スレッド作成し，同時実行スレッド数が起動済みスレッド数を超えた場合，100スレッドまで作成されます。

なお，サーブレットエンジンモードの場合，Webコンテナの簡易Webサーバの使用は任意となります。

●Webサーバ連携機能を使用する場合

作成するスレッド

リダイレクタからのコネクション接続要求を受信するスレッド，およびリダイレクタから受信したリクエスト処理用スレッドを作成します。

スレッドの数

リダイレクタからのコネクション接続要求を受信するスレッドは，1スレッドです。リダイレクタから受信したリクエスト処理用スレッドは，WebサーバとWebコンテナとのコネクション数分スレッドを作成します。

リダイレクタから受信したリクエスト処理用スレッドは，起動時にwebserver.connector.ajp13.max_threadsに指定された数分作成します（webserver.connector.ajp13.max_threadsのデフォルトは10）。

(b)　Webアプリケーションのためのスレッド

Webアプリケーション単位に次のスレッドを作成します。最小１スレッド，最大３スレッドです。

セッションの有効期限監視スレッド

Webアプリケーションのリロード監視スレッド
（webserver.context.reloadable=trueを設定した場合）

JSPの更新監視スレッド
（webserver.jsp.recompilable=trueを設定した場合）

(c)　メインスレッド

なお，サーブレットエンジンモードの場合，メインスレッドとして1スレッド作成します。

(2)　作成されるスレッドの総数

Webコンテナがデフォルトの設定でプロセス起動時に作成するスレッドの総数を次に示します。ただし，この数値にはWebコンテナ以外，およびJavaVMが作成するスレッドは含まれていません。

作成するスレッドの総数は，レスポンス送信時のタイムアウトを設定しているかどうかによって異なります。

レスポンス送信時のタイムアウトを設定しているとき

スレッド総数=A＋B＋C＋D＋E

レスポンス送信時のタイムアウトを設定していないとき

スレッド総数=A＋B＋C＋D

（凡例）

A：Webコンテナの簡易Webサーバを使用する場合のスレッド数

B：Webサーバ連携機能を使用する場合のスレッド数

C：Webアプリケーション単位のスレッド数

D：メインスレッド

E：レスポンス送信時のタイムアウトを監視するためのスレッド数

このため，プロセス起動時のスレッド総数は次のようになります。

レスポンス送信時のタイムアウトを設定しているときのスレッド総数

=6＋11＋（１×Webアプリケーション数）＋1＋1

=19＋Webアプリケーション数

レスポンス送信時のタイムアウトを設定していないときのスレッド総数

=6＋11＋（１×Webアプリケーション数）＋1

=18＋Webアプリケーション数

プロセス起動後，Webサーバとのコネクション数，簡易Webサーバの同時実行数によってスレッド数が増加します。

付録C.10　同時実行スレッド数の制御

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定できます。これによって，スラッシングなどによる，パフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスチューニングができます。

サーブレットエンジンモードの場合，同時に実行できるスレッド数は，Webコンテナ単位で制御されます。Webアプリケーション単位でのスレッド数の制御およびURLグループ単位でのスレッド数の制御はできません。

Webコンテナ単位での同時実行スレッド数の制御には，J2EEサーバモードとで機能差異はありません。このため，機能については，「4.18　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

付録C.11　ユーザスレッドで使用できるApplication Serverの機能

ここでは，サーブレットエンジンモードの場合，ユーザスレッドで使用できるApplication Serverの機能について説明します。ユーザスレッドの使用方法については，「4.32.1(14)　ユーザスレッドの使用方法」を参照してください。

Application Serverで提供される各機能について，ユーザスレッドで使用できるかどうかを次に示します。

＜この項の構成＞

(1)　サーブレットAPI

(2)　リソース接続およびトランザクションサービス

(3)　ログ運用および障害検知

(4)　J2EEアプリケーション運用

(5)　コンテナ拡張ライブラリ

(1)　サーブレットAPI

サーブレットAPIをユーザスレッドで使用する場合，リクエストオブジェクトおよびレスポンスオブジェクトは使用できません。リクエスト処理スレッドでだけ使用してください。詳細は，サーブレット仕様書のThread Safetyの項を参照してください。

(2)　リソース接続およびトランザクションサービス

サーブレットエンジンモードで使用できるリソース接続およびトランザクションサービスとして提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表C-4　リソース接続およびトランザクション管理の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
コネクションプーリング | Webコンテナコネクションプールによるコネクションプーリング | － | －
コネクションプールのウォーミングアップ | ○ | ○
Webコンテナコネクションプールによるコネクション取得リトライ | － | －
コネクションプールクリア | ○ | ○
コネクションのクローズ・解放 | コネクション強制クローズ | × | ×

（凡例）　○：使用できる　　×：使用できない　　－：該当しない

ユーザスレッドでリソース接続およびトランザクションサービスを使用する場合の注意事項を示します。

SingleThreadModelインタフェースを実装したサーブレットで生成したスレッド上で，トランザクションの開始と決着，およびコネクションの取得と解放はできません。

スレッド生成時にトランザクションを引き継ぐことはできません。

トランザクションは，同じスレッド上で開始または決着してください。

スレッド間でコネクションを渡すことはできません。コネクションを使用すると，動作不正となります。

ユーザスレッドでコネクションを取得した場合，コネクションを取得したスレッド上で確実にコネクションをクローズしてください。

(3)　ログ運用および障害検知

サーブレットエンジンモードで使用できるログ運用および障害検知として提供される機能が，サーブレット/JSPおよびユーザスレッドで使用できるかどうかを次の表に示します。

表C-5　ログ運用および障害検知の機能の使用可否（ユーザスレッド）

分類／機能名 | サーブレット/JSP | ユーザスレッド
ユーザログ出力 | ○ | ○
性能解析トレース | ○ | ○

（凡例）　○：使用できる

(4)　J2EEアプリケーション運用

J2EEアプリケーション運用機能として提供される機能のうち，Webアプリケーションの通常停止は，サーブレット/JSPおよびユーザスレッドで使用できます。ただし，コンテナでは，ユーザスレッドを停止しません。

(5)　コンテナ拡張ライブラリ

コンテナ拡張ライブラリは，サーブレット/JSPおよびユーザスレッドのどちらでも使用できます。

付録C.12　ドメイン名指定でのトップページの表示

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。

ドメイン名指定でのトップページの表示は，J2EEサーバモードと同じです。ドメイン名指定でのトップページの表示については，「4.25　ドメイン名指定でのトップページの表示」もあわせて参照してください。

ただし，サーブレットエンジンモードの場合は，Webアプリケーションのコンテキストルートを「ROOT」にしてデプロイする必要があります。

サーブレットエンジンモードの場合にドメイン名指定でのトップページの表示をするための設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

付録C.13　静的コンテンツのキャッシュ

一度アクセスした静的コンテンツをメモリ上にキャッシュし，2回目以降のアクセスではキャッシュからブラウザにレスポンスを返すことで，静的コンテンツのレスポンスタイムを短縮できます。

静的コンテンツのキャッシュは，J2EEサーバモードの場合と同じです。静的コンテンツのキャッシュについては，「4.28　静的コンテンツのキャッシュ」を参照してください。

なお，サーブレットエンジンモードの場合，リロード機能またはJSPファイルの再コンパイル機能が有効なときには，静的コンテンツのキャッシュは無効になります。

付録C.14　簡易Webサーバ機能

サーブレットエンジンモードの場合，簡易Webサーバは，Webアプリケーションの動作確認用に利用できます。

注意

簡易Webサーバは，本番運用時にサーブレット，JSPを実行するWebサーバとしては利用できませんので注意してください。

簡易Webサーバを利用するための設定は，Webコンテナサーバのプロパティをカスタマイズして設定します。Webコンテナサーバの動作設定のカスタマイズについては，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

付録D　サーブレットエンジンモードでのリソース接続

ここでは，サーブレットエンジンモードでのリソース接続について説明します。

＜この節の構成＞

付録D.1　接続できるリソースとトランザクションの管理方法

付録D.2　データベース接続の前提条件

付録D.3　Webコンテナコネクションプール機能によるデータベース接続

付録D.1　接続できるリソースとトランザクションの管理方法

サーブレットエンジンモードの場合に接続できるリソースの種類とトランザクションの管理方法について説明します。

＜この項の構成＞

(1)　接続できるリソース

(2)　トランザクションの管理方法

(1)　接続できるリソース

サーブレットエンジンモードで接続できるリソースについて次の表に示します。

表D-1　接続できるリソース（サーブレットエンジンモード）

リソースの種類 | サーブレットエンジンモード
データベース | HiRDB | ○
Oracle | ○
SQL Server | ×
XDM/RD E2 | ×
データベース上のキュー | HiRDB | ×
Oracle | ×
OpenTP1 | SPP | ×※
TP1/Message Queue | ×※
SMTPサーバ | ×
JavaBeansリソース | ×

（凡例）　○：接続できる　　×：接続できない

注※

リソースアダプタがNon-Managed環境での使用に対応している場合には，接続できる場合があります。ただし，Application Serverによるコネクションプーリングやトランザクション管理は利用できません。なお，TP1/Message Queueへの接続については，マニュアル「OpenTP1 Version 6 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」を参照してください。

(2)　トランザクションの管理方法

サーブレットエンジンモードの場合，トランザクションはApplication Serverで管理されません。

付録D.2　データベース接続の前提条件

サーブレットエンジンモードでデータベースに接続する場合の前提条件を，データベースの種類ごとに示します。

サーブレットエンジンモードの場合，データベース接続には，Webコンテナコネクションプール機能を使用します。

なお，サーブレットエンジンモードでは，次のデータベースには接続できません。

Oracle10g

SQL Server

XDM/RD E2

＜この項の構成＞

(1)　HiRDBの場合

(2)　Oracle9iの場合

(1)　HiRDBの場合

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。
Cosminexus DABroker Libraryを使用する場合，HiRDBクライアントをインストールする必要があります。

接続方法
Webコンテナコネクションプール機能を使用して接続します。
なお，サーブレットエンジンモードの場合，トランザクションはApplication Serverで管理されません。

(2)　Oracle9iの場合

使用できるJDBCドライバ
使用できるJDBCドライバはCosminexus DABroker Libraryとなります。Oracle JDBC Thin Driverでは接続できません。
JDBCドライバとしてCosminexus DABroker Libraryを使用する場合，Oracleクライアントをインストールする必要があります。

接続方法
Webコンテナコネクションプール機能を使用して接続します。
なお，サーブレットエンジンモードの場合，トランザクションはApplication Serverで管理されません。

付録D.3　Webコンテナコネクションプール機能によるデータベース接続

サーブレットエンジンモード上で動作するWebアプリケーションからデータベースへ接続する場合，Webコンテナコネクションプーリング機能を利用してデータベースへの接続をプールできます。これによって，コネクション生成時のパフォーマンスを向上できます。

Webコンテナコネクションプール機能での，コネクションの取得方法には次の2とおりがあります。

java.sql.DriverManager.getDriverを使ってjava.sql.Driverのインスタンスを取得し，java.sql.Driver.connectを使ってコネクションを取得する方法

java.sql.DriverManager.getConnectionを使ってコネクションを取得する方法

なお，コネクションプールの詳細については，「9.10.1　コネクションプーリング」を参照してください。

＜この項の構成＞

(1)　Webコンテナコネクションプール機能の利用方法

(2)　パフォーマンスチューニングのための機能

(3)　フォールトトレランスのための機能

(1)　Webコンテナコネクションプール機能の利用方法

Webコンテナコネクションプール機能を利用するためには，管理機能用のWebアプリケーションをデプロイし，プール管理情報を登録する必要があります。プール管理情報の登録をするためのコネクションプーリングの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

また，コネクションの取得処理はWebアプリケーションで実施するため，ユーザ作成のアプリケーションに，コネクションを操作するための記述が必要になります。

コネクションを取得するには，次の2とおりの方法があります。同時に多数のユーザが接続するようなシステムの場合は，ドライバマネージャ内で待ちが発生するため，取得方法1の記述をお勧めします。

取得方法1

String className = "com.hitachi.software.web.jdbc.WccpDriver";
String url = "jdbc:hitachi:wccp://DBID=<データベースID>";

Properties info = new Properties();
info.put("user", "<ユーザID>");
info.put("password", "<パスワード>");

Class.forName(className);
Driver drv = DriverManager.getDriver(url);
Connection con = drv.connect(url, info);
con.close();

取得方法2

String className = "com.hitachi.software.web.jdbc.WccpDriver";
String url = "jdbc:hitachi:wccp://DBID=<データベースID>";
String user = "<ユーザID>";
String password = "<パスワード>";

Class.forName(className);
Connection con = DriverManager.getConnection(url, user, password);
con.close();

(2)　パフォーマンスチューニングのための機能

サーブレットエンジンモードでデータベースに接続する場合に，パフォーマンスチューニングのために使用できる機能を，次の表に示します。

表D-2　サーブレットエンジンモードでデータベースに接続する場合に使用できるパフォーマンスチューニングのための機能

機能 | 使用可否
コネクションプーリング | ○
コネクションシェアリング | ×
コネクションのアソシエーション | ×
ステートメントプーリング | ×
ライトトランザクション | ×
インプロセストランザクションサービス | ×
DataSourceオブジェクトのキャッシング | ×
DB Connectorのコンテナ管理でのサインオンの最適化 | ×
受信バッファのプーリング | ×

（凡例）○：使用できる　×：使用できない

サーブレットエンジンモードの場合のコネクションプーリングについて次に説明します。

コネクションプーリング

サーブレットエンジンモードの場合，プーリングの基本機能として，コネクションプールの生成初期化，コネクションの取得や解放などの機能を提供しています。

コネクションプールの生成および初期化
コネクションプールが生成・初期化されるタイミングは，リソースのスタート処理時または監視・制御機能で提供するAPIのクラスのインスタンスの生成時です。ただし，この時点ではコネクションは生成されません。
コネクションが最初に生成されるのは，最初のコネクション取得要求があったときです。以降，プールの最小値までコネクションをプールします。この動作は，非同期で実施されます。

コネクションの取得と解放
コネクションの取得要求があると，プールから未使用のコネクションを選択し，コネクションの状態を使用中にしてから，クライアントに渡します。
また，コネクションの解放要求があると，使用中になっているコネクションの状態を未使用に設定して，コネクションをプールに返します。なお，コネクションの状態が，再利用できない状態に設定されている場合は，データベースとの接続を切断して，コネクションを削除します。この場合，コネクションはプールに返されません。

例外が発生したコネクションの破棄
java.sql.ConnectionのようなJDBCインタフェースのAPIでSQLException例外が発生すると，コネクションクローズで該当コネクションの接続が維持されていても，コネクションプールに戻さないで破棄します。その結果，Webコンテナコネクションプーリングを使用している場合（java.sql.Connectionインタフェースだけ該当する）に，余分なコネクション生成が発生して性能に影響を与えることがあります。

(3)　フォールトトレランスのための機能

サーブレットエンジンモードでデータベースに接続する場合に，フォールトトレランスのために使用できる機能を，次の表に示します。

表D-3　サーブレットエンジンモードでデータベースに接続する場合に使用できるフォールトトレランスのための機能

機能 | 使用可否
コネクションの障害検知 | ×
コネクション枯渇時のコネクション取得待ち | ×
コネクションの取得リトライ※ | ○
コネクションプールの情報表示 | ○
コネクションプールのクリア | ○
コネクションの強制クローズ | ○
コネクションの自動クローズ | ×
コネクションスイーパ | ×
トランザクションタイムアウト | ×
トランザクションリカバリ | ×
障害調査用SQLの出力 | ×
コネクションプールのクラスタ化 | ×

（凡例）○：使用できる　×：使用できないまたは該当しない

注※　Webコンテナコネクションプールのコネクション取得リトライができます。

以降，サーブレットエンジンモードで使用できるフォールトトレランスのための機能について説明します。

なお，それぞれの機能の概要および目的については，「9.11　フォールトトレランスのための機能」を参照してください。ここでは，サーブレットエンジンモードで特有の説明についてだけ説明します。

コネクションの取得リトライ

J2EEサーバモードとの機能差はありません。「9.11.3　コネクションの取得リトライ」を参照してください。

コネクションプールの情報表示

コネクションプール内のコネクションの情報を，コマンドを使用して表示できます。コネクションプール情報の表示には，cjweblistpoolコマンドを使用します。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

コネクションプールのクリア

データベースサーバのダウンなどによって，コネクションが切断された場合，プールされているコネクションはコネクションプール内に残ってしまいます。これらのコネクションは，cjwebclearpoolコマンドによって削除できます。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

コネクションの強制クローズ

アプリケーションのConnection.closeメソッドの記述もれによってクローズされないコネクションは，コネクションプール内で使用中状態のまま再利用されません。これらのコネクションは，cjwebclosepoolコマンドを使用して強制クローズできます。コマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

付録E　J2EEサーバ起動時のEJBタイマの自動生成

Timer Serviceを使用している場合に，J2EEサーバ起動時にEJBタイマを自動で生成する方法について説明します。EJBタイマの自動生成には次の方法があります。

サーブレット方式
サーブレット内で，EJBタイマの自動生成処理を実装する方法です。

Managementイベント方式
Managementイベントを使用してEJBタイマを自動生成する方法です。J2EEサーバの起動時に出力されるメッセージを契機に発生するManagementイベントとして，EJBタイマの自動生成を設定します。
EJBタイマを生成するEnterprise Beanを呼び出すEJBクライアントプログラムを作成している場合は，J2EEアプリケーションの修正は不要です。

Timer Serviceの機能については，「5.10　Timer Serviceの機能」を参照してください。

＜この節の構成＞

付録E.1　サーブレット方式

付録E.2　Managementイベント方式

付録E.1　サーブレット方式

EJBタイマの自動生成処理をサーブレットで実装する場合の，EJBタイマ自動生成の流れと設定について説明します。

＜この項の構成＞

(1)　EJBタイマの自動生成の流れ

(2)　EJBタイマを自動生成するための設定

(1)　EJBタイマの自動生成の流れ

サーブレット方式では，次のような流れでEJBタイマが自動生成されます。

図E-1　EJBタイマの自動生成の流れ（サーブレット方式）

J2EEサーバを再起動する。

J2EEアプリケーションが自動で開始する。
J2EEサーバ停止時に開始状態だったJ2EEアプリケーションが自動で開始されます（アプリケーションの自動起動を有効にしておく必要があります）。

initメッドが実行される。
J2EEアプリケーションが開始するとサーブレットがロードされ，initメッドが実行されます。initメソッドでは，Enterprise Beanを生成してビジネスメソッドを呼び出します。

EJBタイマが生成される。
Enterprise Beanのビジネスメソッドで，Timer ServiceオブジェクトからEJBタイマが生成されます。

(2)　EJBタイマを自動生成するための設定

サーブレットでEJBタイマを自動生成するには，次の設定をします。

Enterprise BeanにEJBタイマを生成するビジネスメソッドを作成する。

サーブレットを作成する。
initメソッドで，手順1.で作成したビジネスメソッドを呼び出すようにします。

J2EEアプリケーションの開始時に，手順2.で作成したサーブレットをロードさせる。
DD（web.xml）で，手順2.で用意したサーブレットの<load-on-startup>タグの値を0以上に設定します。

J2EEサーバ起動時に，アプリケーションの自動起動を有効にする。

付録E.2　Managementイベント方式

＜この項の構成＞

(1)　EJBタイマの自動生成の流れ

(2)　EJBタイマを自動生成するための設定

(1)　EJBタイマの自動生成の流れ

Managementイベント方式では，次のような流れでEJBタイマが自動生成されます。

図E-2　EJBタイマの自動生成の流れ（Managementイベント方式）

J2EEサーバを再起動する。

メッセージが出力される。
J2EEサーバの起動が完了するとメッセージKDJE30028-Iが出力されます。このメッセージが出力されることで，Managementイベントが発生します。

Managementアクションが実行される。
Managementイベントを受けて，Managementアクションが実行されます。Managementアクションでは，バッチファイルが実行されます。

バッチファイルが実行される。
バッチファイルで，EJBクライアントアプリケーションが実行されます。

EJBクライアントアプリケーションでビジネスメソッドが呼ばれる。
EJBクライアントアプリケーションで，Enterprise Beanを生成してビジネスメソッドを呼び出します。

EJBタイマが生成される。
Enterprise Beanのビジネスメソッドで，Timer ServiceオブジェクトからEJBタイマが生成されます。

(2)　EJBタイマを自動生成するための設定

Managementイベントを使用してEJBタイマを自動生成するには，次の設定をします。

Enterprise BeanにEJBタイマを生成するビジネスメソッドを作成する。

EJBクライアントアプリケーションを作成する。
手順1.で作成したビジネスメソッドを呼び出すようにします。

手順2.で作成したEJBクライアントアプリケーションを実行する環境，およびバッチファイルを作成します。

Managementイベントの自動実行を設定する。
Managementイベントを有効にします。J2EEサーバ開始完了時に出力されるKDJE30028-IをManagementイベントに設定し，このManagementイベントに対するManagementアクションとして，手順3.で準備したバッチファイルを設定します。
Managementイベントの詳細については，「17.8　Managementイベントによる処理の自動実行」を参照してください。

付録F　Oracle RACを使用したOracleへの接続

Oracle RACを使用したOracleへの接続方法は，Oracleのバージョン，または負荷分散に使用する機能によって異なります。なお，接続できるトランザクションの種類はローカルトランザクションです。

Oracleのバージョン，負荷分散に使用する機能および使用するRARファイルの対応を次の表に示します。

表F-1　Oracleのバージョン，使用する機能および使用するRARファイルの対応

Oracleのバージョン
負荷分散に使用する機能
DB ConnectorのRARファイル名

Oarcle 10g

Oracle 10g R2

Cosminexusの機能（コネクションプールのクラスタ化機能）
DBConnector_CP_ClusterPool_Root.rar
DBConnector_Oracle_CP_ClusterPool_Member.rar

Oracle9i

Oarcle 10g

Oracle 10g R2

Oracleの機能
DBConnector_DABJ_CP.rar
DBConnector_Oracle_CP.rar
DBConnector_Oracle_CP_Cosminexus_RM.rar

負荷分散に使用する機能ごとに，Oracleへの接続方法について説明します。

＜この節の構成＞

付録F.1　Cosminexusの機能を使用した接続

付録F.2　Oracleの機能を使用した接続

付録F.1　Cosminexusの機能を使用した接続

Cosminexusのコネクションプールのクラスタ化機能を使用して，Oracle RACに接続します。Cosminexusがデータベースアクセスの負荷を分散します。コネクションプールのクラスタ化機能については，「9.12　コネクションプールのクラスタ化」を参照してください。

＜この項の構成＞

(1)　負荷分散処理の流れと設定

(2)　データベース障害発生時と回復時の動作

(1)　負荷分散処理の流れと設定

コネクションプールのクラスタ化機能を使用した場合の負荷分散処理の流れと設定を次の図に示します。

図F-1　コネクションプールのクラスタ化機能を使用した接続

この図では，3台構成のOracle RACシステムで，データベースノード1にはインスタンス1，データベースノード2にはインスタンス2，データベースノード3にはインスタンス3があります。データベースに接続するための設定を次に示します。

インスタンス1，2，3に対応したメンバリソースアダプタ用DB Connector M1，M2，M3を生成します。また，メンバリソースアダプタに振り分ける機能を持つルートリソースアダプタ用DB Connector Rも生成します。

J2EEアプリケーションはルートリソースアダプタ用DB Connector Rに関連づけます。

この設定によって，J2EEアプリケーション1，2からのデータベースアクセスはデータベースノード1，2，3に分散されます。

(2)　データベース障害発生時と回復時の動作

データベース障害が発生した場合，Cosminexusが障害を検知します。障害が発生したデータベースに対応するメンバリソースアダプタが閉塞され，残っているインスタンスで処理が続行されます。

データベース障害が回復するとCosminexusは自動で閉塞を解除します。また，手動でも閉塞を解除できます。

付録F.2　Oracleの機能を使用した接続

DB ConnectorからOracle RACに接続し，Oracle RACの機能でデータベースアクセスの負荷を分散します。

＜この項の構成＞

(1)　負荷分散処理の流れと設定

(2)　データベース障害発生時と回復時の動作

(1)　負荷分散処理の流れと設定

Oracle RACの機能を使用した場合の負荷分散処理の流れと設定を次の図に示します。

図F-2　Oracle RACの機能を使用した接続

この図では，3台構成のOracle RACシステムで，データベースノード1にはインスタンス1，データベースノード2にはインスタンス2，データベースノード3にはインスタンス3があります。データベースに接続するための設定を次に示します。

OracleにサービスXを作成します。サービスとは，Oracle 10gから導入された機能です。

サービスXでは，インスタンス1，2，3への接続を「優先」に設定します。なお，グローバルトランザクションは使用しないため，DTPは無効にします。

サービスXに対応したDB Connector Aを生成します。

DB Connector Aは，サービスXを使用するように設定します。

J2EEアプリケーション1，および2をDB Connector Aに関連づけます。

この設定によって，J2EEアプリケーション1，および2からのデータベースアクセスはデータベースノード1，2，3に分散されます。

(2)　データベース障害発生時と回復時の動作

データベース障害が発生した場合，Oracle RAC機能によって障害が発生したインスタンスが切り離され，残っているインスタンスで処理が続行されます。

Cosminexusのコネクションプールを使用している場合，データベース回復時には次の操作を実行してください。コネクションプールがクリアされ，これ以降のアクセスが正常に分散されます。

cjclearpoolコマンドを実行する。

J2EEサーバを再起動する。

付録G　アプリケーションの開発で使用する文字コード

アプリケーション開発時には，実行プロセスやリソースの文字コードを考慮する必要があります。Javaで扱う文字コードはUnicodeであるため，リソースの文字コードやUnicodeへの文字コード変換が間違っていると，「文字化け」を引き起こす原因になります。

ここでは，アプリケーションで使用する文字コードと注意事項を示します。また，ブラウザおよびデータベースとデータをやり取りする場合の，文字コード変換の注意事項についても示します。

＜この節の構成＞

付録G.1　アプリケーションで扱う文字コード

付録G.2　ブラウザとアプリケーション間の文字コード変換

付録G.3　データベースとアプリケーション間の文字コード変換

付録G.1　アプリケーションで扱う文字コード

アプリケーションの構成を基に，文字コード変換の流れを示します。

図G-1　アプリケーションの文字コード変換の流れ

図中の番号（（1）～（5））は，文字コードを考慮する必要のあるプログラムやリソースを表します。また，図中の英字（A～E）は文字コード変換時のデータの流れを示します。プログラム，リソースで扱う文字コードと注意事項，および文字コード変換の動作と注意事項を，それぞれ表に示します。

表G-1　プログラム，リソースで扱う文字コードと注意事項

プログラム，リソース名
項目
扱う文字コードおよび注意事項

（1）入力ページ
URLのパス
URLのパスの文字コードは，ISO-8859-1である必要があります。シフトJISなどの非ASCII文字は記述できません。

クエリ文字列
HTMLの<FORM>タグを使用して送信される文字は，フォームを表示しているHTMLページと同じ文字コードでURLエンコードされて送出されます。

POSTデータ

（2）JSP
JSP
任意の文字コードで作成できます。
Webアプリケーションのバージョン2.4（JSP 2.0仕様）で，JSPドキュメントの文字エンコードを指定する場合は，XML宣言で文字エンコードを指定してください。
JSP 1.2仕様では，JSPの文字コードは，pageディレクティブのpageEncoding属性に記述する必要があります。

（3）HTML
HTML
任意の文字コードで作成できます。

（4）データベース
データベース
データベースに格納するデータの文字コードは，ブラウザに表示する文字コードを考慮して決定してください。

（5）出力ページ
レスポンスヘッダ
ISO-8859-1である必要があります。非ASCII文字を使用する場合は，URLエンコードする必要があります。

レスポンスボディ
ユーザプログラムで任意の文字コードを使用できます。

注意

Webコンテナでは英数字を2バイトで表現する文字コードは使用できません。英数字に2バイト使用する文字コードを次に示します。

UCS-2（ISO/IEC 10646）

UCS-4（ISO/IEC 10646-1）

UTF-16

表G-2　文字コード変換の動作と注意事項

変換個所
対象
文字コード変換時の動作および注意事項

A　ブラウザ～J2EEサーバ
URLのパス
Webコンテナでは，URLのパスの文字コードはISO-8859-1として処理されます。

クエリ文字列
クエリ文字列またはPOSTデータの文字コードは，アプリケーションで任意に決められます。サーブレット，JSPではUnicodeで扱われるので，アプリケーション内で矛盾のないように文字コードを変換してください。

POSTデータ

B　J2EEサーバ内
JSPファイル
pageディレクティブのpageEncoding属性に記述されたエンコーディングでファイルが読み込まれます。pageEncoding属性が省略されている場合は,
contentType属性が使用されます。

HTMLファイル
HTMLファイルの文字コードのままブラウザに送信されます。

C　J2EEサーバ～データベース
データベース
JDBCドライバによって，Unicodeがデータベース格納文字コードに変換されます。

D　データベース～J2EEサーバ
データベース
JDBCドライバによって，データベース格納文字コードがUnicodeに変換されます。

E　J2EEサーバ～ブラウザ
レスポンスヘッダ
Webコンテナによって，レスポンスヘッダの文字コードがISO-8859-1に変換されます。

レスポンスボディ

サーブレットの場合

ServletResponseクラスのsetContentTypeメソッドによって文字コードを指定します。

JSPの場合

pageディレクティブのcontentType属性で文字コードを指定します。

参考

「文字化け」について

アプリケーションの実行環境では，文字コードはUnicodeとして扱われます。このため，ブラウザから送信された文字列は一度Unicodeに変換されます。また，データベースへのアクセス時にはUnicodeとデータベース格納文字コード間の文字コード変換，レスポンス時にはUnicodeからレスポンスの文字コードへの変換をする必要があります。これらの文字コード変換時に適切な変換をしないと，文字化けする原因になります。

これはシフトJISと呼ばれる文字コードに機種依存文字が含まれることや，同じ文字でもUnicodeへの変換結果がほかの文字コードと異なっているもの※があるために発生します。例えば，ブラウザから機種依存文字を含んだ文字データが送信され，これをUnicodeに変換した場合，レスポンス時にこの文字列をシフトJISに変換すると，文字化けする結果となります。

クライアントのOSをWindowsに限定できる場合は，文字コードをシフトJISではなくMS932またはWindows-31Jと指定することで，文字化けを避けられます。

注※

－，～，∥，￠，￡，￢などの文字が該当します。

付録G.2　ブラウザとアプリケーション間の文字コード変換

ブラウザとアプリケーション間で文字コード変換をするときに使用するメソッド，およびJSPとJavaScriptの実装時の注意事項について説明します。

＜この項の構成＞

(1)　ブラウザとアプリケーション間の文字コード変換で使用するメソッド

(2)　JSPのファイルインクルード時の注意事項

(3)　JavaScriptを使用してクエリ文字列を作成する場合の注意事項

(1)　ブラウザとアプリケーション間の文字コード変換で使用するメソッド

ブラウザを使用して送信されたクエリ文字列，POSTデータは，HttpServletRequestクラスのメソッドを使用して取得します。HttpServletRequestクラスのうち，文字コード変換に関係のあるメソッドと使用時の注意事項を示します。

(a)　setCharacterEncodingメソッド

リクエストのメッセージボディで使われている文字コードを設定します。このメソッドは，getParameterメソッドや，getReaderメソッドを使って入力ストリームから読み込む前に実行されなければなりません。

(b)　getParameterメソッド

パラメタの名称を指定して，リクエストに含まれるパラメタの値を取得します。取得した値はURLデコードされ，Unicodeに変換されます。パラメタの名称やパラメタの値を取得する前に，setCharacterEncodingメソッドを用いて文字コードを指定する必要があります。指定しなかった場合，ISO-8859-1としてUnicodeに変換されます。HttpServletRequestクラスのgetParameterNamesメソッド，getParameterValuesメソッド，getParameterMapメソッドも同様です。

(c)　getInputStreamメソッド

リクエストのメッセージボディに含まれているバイナリデータを読み込むためのストリームを取得します。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります

(d)　getReaderメソッド

リクエストのメッセージボディにBufferedReaderクラスを使い，文字データとして取り出します。文字データはメッセージボディと同じ文字コードに変換されます。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります。

(e)　getQueryStringメソッド

リクエストされたURLのパスの後ろに含まれているクエリ文字列を返します。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります。

(2)　JSPのファイルインクルード時の注意事項

JSPファイルのincludeディレクティブでファイルをインクルードする場合には，インクルード元となるJSPファイルでcontentType属性を使用してエンコードを指定してください。また，JSPファイルの文字コードはpageEncoding属性に指定してください。指定しない場合はインクルード先の文字が正常に表示されない場合があります。

(3)　JavaScriptを使用してクエリ文字列を作成する場合の注意事項

JavaScriptのencodeURI関数およびencodeURIComponent関数※を使用すると，UTF-8でURLエンコードできます。この関数を用いて変換した文字列をクエリ文字列として使用してください。この場合，J2EEサーバ側でUTF-8としてUnicodeに変換すると，日本語の文字列データを取得できます。

注※

encodeURI関数とencodeURIComponent関数の相違は，「,/?:@&=+$,#」などの特殊文字を変換するかどうかです。encodeURI関数は「,/?:@&=+$,#」などの特殊文字を変換しません。

JavaScriptのescape関数はブラウザの種類やバージョンによって動作が異なります。escape関数で変換された文字列は，サーバ側で正常に扱えないため，escape関数を使用しないで，encodeURI関数またはencodeURIComponent関数を使用するようにしてください。

付録G.3　データベースとアプリケーション間の文字コード変換

アプリケーションからデータベースに文字データを格納するときには，Unicodeからデータベースに設定されている文字コードに変換して格納する必要があります。文字コード変換はJDBCドライバによって行われますが，次に示す内容に従って，あらかじめJDBCドライバに使用する文字コードを設定しておく必要があります。

J2EEサーバモードの場合

1.4モードでは，Connector属性ファイルのencodLangプロパティで指定します。Server Plug-inを使用する場合，Connector属性ファイルのフォームページから指定できます。

ベーシックモードでは，ejbserver.jdbc.propertyInfo.ENCODELANGプロパティに使用する文字コードを指定してください。このプロパティに値が指定されている場合，J2EEサーバがJDBCコネクションを取得するときに，ENCODELANGキーに該当値を設定したプロパティを作成し，Cosminexus DABroker Libraryのjava.sql.Driver.connectの引数に渡します。

サーブレットエンジンモードの場合

JDBCコネクションを取得するとき，ENCODELANGキーに該当値を設定したプロパティを作成し，Cosminexus DABroker Libraryのjava.sql.Driver.connectメソッドまたはjava.sql.DriverManager.getConnectionメソッドの引数に渡してください。

付録H　クラスローダの構成

Cosminexusのクラスローダ構成には，デフォルトのクラスローダ構成，ローカル呼び出し最適化機能を使用したときのクラスローダ構成，および下位互換用のクラスローダ構成の3種類があります。それぞれのクラスローダ構成およびクラスローダに設定されるクラスパスについて説明します。

＜この節の構成＞

付録H.1　デフォルトのクラスローダ構成

付録H.2　ローカル呼び出し最適化時のクラスローダ構成

付録H.3　下位互換用のクラスローダ構成

付録H.4　クラスローダに設定されるクラスパス

付録H.1　デフォルトのクラスローダ構成

新規インストール後のデフォルトのクラスローダ構成を次に示します。

図H-1　デフォルトのクラスローダ構成

各クラスローダの内容を次に示します。

システムクラスローダ
Cosminexusのコンポーネントが提供するクラスをロードします。

コネクタクラスローダ
単体デプロイされたリソースアダプタに含まれるクラスをロードします。J2EEサーバ内に一つだけ存在します。

JavaBeansクラスローダ
JavaBeansリソースのクラスをロードします。

アプリケーションクラスローダ
アプリケーション内のEJB-JAR，ライブラリJAR，リソースアダプタに含まれるクラスをロードします。アプリケーションごとに存在します。

Webアプリケーションクラスローダ
J2EEアプリケーション内のWARファイルに含まれるクラスをロードします。WARファイルごとに存在します。

JSPクラスローダ
JSPファイルおよびタグファイルをコンパイルしたときに生成されたクラスをロードします。JSPごとに存在します。

ポイント

リソースアダプタのロードについて

J2EEリソースアダプタとしてデプロイしたリソースアダプタは，コネクタクラスローダでロードされます。J2EEアプリケーションに含めて使用するリソースアダプタは，アプリケーションクラスローダでロードされます。

付録H.2　ローカル呼び出し最適化時のクラスローダ構成

ローカル呼び出し最適化機能を利用する場合，デフォルトのクラスローダとはクラスローダ構成が異なります。ローカル呼び出し最適化機能は，別のアプリケーションのEnterprise Beanを高速で呼び出すことができる機能です。

ローカル呼び出し最適化機能を使用するには，J2EEサーバ用ユーザ定義ファイル（<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties）に次の設定をします。

ejbserver.rmi.localinvocation.scope=all

ローカル呼び出し最適化時のクラスローダ構成を次に示します。

図H-2　ローカル呼び出し最適化時のクラスローダ構成

各クラスローダの内容を次に示します。

システムクラスローダ
Cosminexusのコンポーネントが提供するクラスをロードします。

コネクタクラスローダ
単体デプロイされたリソースアダプタに含まれるクラスをロードします。J2EEサーバ内に一つだけ存在します。

JavaBeansクラスローダ
JavaBeansリソースのクラスをロードします。

J2EEコンテナクラスローダ
すべてのアプリケーションクラスローダの親クラスローダとなり，すべてのアプリケーションクラスローダが持つクラスパスが設定されます。J2EEコンテナクラスローダは，J2EEサーバ内に一つだけ存在します。

アプリケーションクラスローダ
アプリケーション内のEJB-JAR，ライブラリJAR，およびリソースアダプタに含まれるクラスをクラスパスに持ちます。アプリケーションごとに存在します。ローカル呼び出し最適化時には親クラスローダであるJ2EEコンテナクラスローダにも，アプリケーションクラスローダが持つクラスパスが設定されているため，このクラスローダでは何もロードされません。

Webアプリケーションクラスローダ
J2EEアプリケーション内のWARファイルに含まれるクラスをロードします。WARファイルごとに存在します。

JSPクラスローダ
JSPファイルおよびタグファイルをコンパイルしたときに生成されたクラスをロードします。JSPごとに存在します。

ポイント

リソースアダプタのロードについて

J2EEリソースアダプタとしてデプロイしたリソースアダプタは，コネクタクラスローダでロードされます。J2EEアプリケーションに含めて使用するリソースアダプタは，アプリケーションクラスローダでロードされます。

注意

プロパティにejbserver.rmi.localinvocation.scope=allを設定して実行するときには，次の点に注意してください。

J2EEアプリケーションが持つEJB-JARやライブラリJARは同一のクラスローダでロードされるため，同名のクラスはJ2EEアプリケーション間で共有されます。内容の異なる同名クラスが存在する場合は，Javaの仕様上，先にロードされたクラスだけが有効となります。なお，WAR内のクラスはWAR単位に存在するクラスローダによってロードされますので共有の対象外となります。

J2EEアプリケーションのEJB-JARやライブラリJARを入れ替える場合は，J2EEアプリケーションを停止したあとにJ2EEサーバを再起動してください。再起動後に有効となります。

付録H.3　下位互換用のクラスローダ構成

デフォルトのクラスローダ構成と，Cosminexus Version 5（05-01）以前のクラスローダ構成では内容が異なります。このため，下位互換用にクラスローダ構成を変更するためのオプションがあります。Cosminexus Version 5（05-01）以前のバージョンからアップグレードインストールした場合は，自動的に下位互換用のクラスローダ構成になります。

下位互換用のクラスローダ構成に変更するには，J2EEサーバ用ユーザ定義ファイル（<Cosminexusのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties）に次の設定をします。

動作モードをベーシックモードに設定

ejbserver.server.j2ee.feature=1.3basic

ローカル呼び出し最適化機能の適用範囲をなしに設定

ejbserver.rmi.localinvocation.scope=none

下位互換用のクラスローダ構成を次に示します。

図H-3　下位互換用のクラスローダ構成

各クラスローダの内容を次に示します。

システムクラスローダ
Cosminexusのコンポーネントが提供するクラスをロードします。

コネクタクラスローダ
下位互換用クラスローダ構成のときには，リソースアダプタを使用することはできないため，このクラスローダでは何もロードされません。

JavaBeansクラスローダ
JavaBeansリソースのクラスをロードします。

アプリケーションクラスローダ
アプリケーション内のEJB-JARおよびライブラリJARに含まれるクラスをロードします。アプリケーションごとに存在します。

Webアプリケーションクラスローダ
J2EEアプリケーション内のWARに含まれるクラスをロードします。WARごとに存在します。WARからJ2EEアプリケーション内のEJB呼び出しができるように，スタブ関連のクラスもロードします。

JSPクラスローダ
JSPファイルおよびタグファイルをコンパイルしたときに生成されたクラスをロードします。JSPごとに存在します。

付録H.4　クラスローダに設定されるクラスパス

クラスローダに設定されるクラスパス，およびクラスローダがクラスをロードするときのクラスの検索順序を示します。

コネクタクラスローダ
コネクタクラスローダは単体RARのクラスをロードするクラスローダです。単体デプロイ済みRARファイルに含まれているJARファイルを，クラスパスに設定します。

J2EEコンテナクラスローダ
J2EEコンテナクラスローダは，ejbserver.rmi.localinvocation.scope=all（ローカル呼び出し最適化機能を使用する）を指定したときに有効になるクラスローダです。すべてのアプリケーションクラスローダの親クラスローダとなり，開始状態にあるすべてのアプリケーションクラスローダのクラスパスを自分のクラスパスに持ちます。

アプリケーションクラスローダ
アプリケーションクラスローダは，J2EEアプリケーション内のEJB-JAR，ライブラリJAR，およびコンテナ生成クラスをロードします。設定されるクラスパスの順序を次に示します。

J2EEアプリケーションに含まれるRARに含まれているJARファイル

J2EEアプリケーションに含まれるEJB-JAR

参照方式のライブラリ

J2EEアプリケーションに含まれるライブラリJAR

Naming切り替え機能によって参照している別アプリケーションのEJB-JARファイル（参照先のアプリケーションが同一J2EEサーバに存在する場合）

付録I　Cosminexus DABroker Libraryを使用したデータベース接続の実装

ここでは，Cosminexus DABroker Libraryが提供する機能を使用してデータベース接続をする場合の実装方法や注意事項について説明します。

なお，ここではCosminexus DABroker Libraryを単独で使用（J2EEアプリケーション以外から使用）する場合について説明しています。

＜この節の構成＞

付録I.1　Cosminexus DABroker Libraryで開発するアプリケーション

付録I.2　JDBC2.0の概要

付録I.3　JDBC2.0拡張機能の概要

付録I.4　データベース接続の設定

付録I.5　JDBC2.0拡張機能を使用したデータベース接続の設定

付録I.6　エラー時のJDBCドライバの処理

付録I.7　データ型の対応

付録I.1　Cosminexus DABroker Libraryで開発するアプリケーション

Cosminexus DABroker Libraryは，JDBCドライバとDABrokerのデータベース接続部品から構成されたデータベースに接続するミドルウェアです。

Cosminexus DABroker Libraryを利用して開発したアプリケーションは，JDKが対応するWWWブラウザで動作します。開発したアプリケーションを組み込むマシンには，Cosminexus DABroker Libraryが提供するJDBCドライバが必要です。Cosminexus DABroker Libraryはサーバで動作するアプリケーションだけサポートしています。

Application Serverを利用したデータベース接続の流れを次の図に示します。

図I-1　Application Serverを利用したデータベース接続

Cosminexus DABroker Libraryで開発したアプリケーションは，Application Serverに組み込んで使用します。アプリケーションからの要求は，Application Server上にあるJDBCドライバを経由し，Cosminexus DABroker Libraryで処理されます。

Application Serverのアプリケーションの動作時には，Cosminexus DABroker Libraryで提供するネイティブライブラリがApplication Server上に動的にロードされます。ネイティブライブラリがロードされると，Java標準のネイティブライブラリインタフェースである，JNIを使用してアプリケーションとCosminexus DABroker Libraryを接続します。ネイティブライブラリを使用することで，アプリケーションとCosminexus DABroker Libraryとの接続処理を高速化し，高性能なデータベース接続を実現します。また，同一マシン上にアプリケーション，JDBCドライバ，Cosminexus DABroker Libraryがあるため，通信処理のオーバーヘッドがなく，Javaアプレットやクライアントで動作するアプリケーションに比べて高性能な処理を実現します。

注意

ここでは，Cosminexus DABroker LibraryをJ2EEアプリケーション以外から使用する場合について説明しています。したがって，J2EEアプリケーションから使用する場合には該当しません。

付録I.2　JDBC2.0の概要

ここでは，Cosminexus DABroker Libraryで提供する，JDBC2.0基本規格に沿った機能の概要と注意事項について説明します。JDBC1.0が提供するクラスとメソッドの機能，およびJDBC2.0で規格化されていないDBPドライバだけの機能については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この項の構成＞

(1)　ResultSetの拡張

(2)　バッチ更新

(3)　JDBC SQLタイプの扱い

(1)　ResultSetの拡張

JDBC2.0基本規格では，ResultSet（ResultSetクラス）の拡張機能として，「スクロール」と「並行処理」が追加されています。

(a)　スクロールタイプ

ResultSetのスクロールタイプには，次の3種類があります。

順方向専用型
JDBC1.0からの標準のスクロールタイプです。ResultSet内を，順方向（上から下）にだけスクロールできます。

スクロール非反映型
JDBC2.0で導入されたスクロールタイプです。ResultSet内を，順方向，逆方向にスクロールできます。また，現在の位置からの相対位置指定の移動，絶対位置への移動もできます。
「非反映型」とは，ResultSetが開かれている間に加えられた変更が，そのResultSetに反映されないことを意味します。つまり，基盤となるデータの静的なビューを提供するだけで，ResultSetに含まれる行，その順序，および列の値は，ResultSetの作成時に固定されます。

スクロール反映型
JDBC2.0で導入されたスクロールタイプです。Cosminexus DABroker Libraryではサポートしていません。ResultSetが開かれている間に加えられた変更が，そのResultSetに反映される点がスクロール非反映型とは異なります。
「変更の反映」という点では，「そのResultSet自身による変更の反映」，「同一トランザクション内での，ほかのResultSetでの変更の反映」，「ほかのトランザクションによる変更の反映」などがありますが，どこまで保証するかはドライバの実装レベル，およびDBMSのトランザクション遮断レベルに依存します。

(b)　並行処理タイプ

ResultSetの並行処理タイプには，次の種類があります。

読み取り専用型
JDBC1.0からの標準の並行処理タイプです。ResultSetからの更新はできません。

更新可能型
JDBC2.0で導入された並行処理タイプです。ResultSetからの更新（UPDATE，INSERT，DELETE）ができます。Cosminexus DABroker Libraryではサポートしていません。

(c)　ResultSetタイプ

スクロールタイプと並行処理タイプを組み合わせることで，ResultSetには6種類のタイプがあります。Cosminexus DABroker Libraryでは，このうち2種類をサポートしています。ResultSetタイプは，ConnectionクラスのcreateStatementメソッド，prepareStatementメソッド，またはprepareCallメソッドで，Statementクラス（またはそのサブクラス）のインスタンスを取得する時に指定します。

６種類のResultSetタイプとCosminexus DABroker Libraryでのサポートを，次の表に示します。

表I-1　ResultSetのタイプ

ResultSetタイプ | Cosminexus DABroker Libraryでのサポート
スクロールタイプ | 並行処理タイプ
順方向専用型 | 読み取り専用型 | ○
更新可能型 | ×
スクロール非反映型 | 読み取り専用型 | ○
更新可能型 | ×
スクロール反映型 | 読み取り専用型 | ×
更新可能型 | ×

（凡例）

○：サポートしています。

×：サポートしていません。

サポートしていないResultSetタイプが指定された場合，エラーにはしないで，指定されたResultSetタイプにいちばん近いResultSetタイプを使用してStatementクラス（またはそのサブクラス）のインスタンスを生成します。また，警告メッセージをConnectionクラスのSQLWarningに格納します。

更新可能型の並行処理タイプはサポートしていないため，ResultSetクラスに使用できないメソッドがあります。これらの使用できないメソッドが呼び出された場合は，無条件にSQLExceptionをthrowします。どのメソッドが使用できないかについては，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

(d)　スクロール型ResultSet使用時の注意点

スクロール型ResultSetでは，Cosminexus DABroker Library内ですべての検索データをキャッシングします。データ量が大量な場合は，メモリ不足や性能劣化が発生する可能性が大きくなります。このため，スクロール型ResultSetを使用する場合は，「SQLに条件を付加する」，「StatementクラスのsetMaxRowsメソッドを呼び出す」など，検索データ量をあらかじめ抑制してください。

(2)　バッチ更新

JDBC2.0基本規格では，Statementクラス，PreparedStatementクラス，およびCallableStatementクラスにバッチ更新機能が追加されています。バッチ更新機能を使うと，複数のSQL，または複数のパラメタ値を登録し，一括で実行できます。

注意

バッチ更新機能を使用する場合，ConnectionクラスのAUTOコミットモードをOFFにしてください。これは，バッチ更新の途中でエラーが発生した場合，そのトランザクションの有効・無効をアプリケーション側で制御する必要があるためです。AUTOコミットモードがON（初期状態）の場合，バッチ更新の途中でエラーが発生しても，エラーが発生する一つ前までのSQL実行は有効となるため，注意が必要です。CosminexusでJTAトランザクションを使用している場合，AUTOコミットモードはOFFになります。

(a)　Statementクラスでのバッチ更新

概要

複数の更新系SQLをaddBatchメソッドで登録します。

登録した更新系SQLを，executeBatchメソッドを使用して一括で実行します。

一括実行の結果として，それぞれの更新系SQLによって更新された行数の配列を返します。

一括実行の途中でエラーが発生した場合，BatchUpdateExceptionをthrowします。

登録したSQL中に検索系SQLがある場合，executeBatchメソッド呼び出し時にBatchUpdateExceptionをthrowします。

注意事項

DABrokerとのインタフェース上，複数のSQLを一括実行できないため，Cosminexus DABroker Libraryでは，登録されたSQLを逐次実行することでバッチ更新を実現しています。

(b)　PreparedStatementクラスでのバッチ更新

概要

PreparedStatementインスタンス生成時に指定した，更新系SQLに対する？パラメタを，通常の手順（setXXXメソッド）で設定します。

addBatchメソッドで，？パラメタのセットを登録します。

登録した複数セットの？パラメタを，executeBatchメソッドで一括実行します。

一括実行の結果として，それぞれの？パラメタのセットで更新された行数の配列を返します。

一括実行の途中でエラーが発生した場合，BatchUpdateExceptionをthrowします。

PreparedStatementインスタンス生成時に指定したSQLが検索系SQLである場合，executeBatchメソッド呼び出し時にBatchUpdateExceptionをthrowします。

注意事項

定義系および制御系SQLについては，addBatchメソッドを実行しないでください。

(c)　CallableStatementクラスでのバッチ更新

概要

CallableStatementインスタンス生成時に指定した，SQLに対する？パラメタを，通常の手順（setXXXメソッド）で設定します。

addBatchメソッドで，入力パラメタのセットを登録します。

登録した複数セットの入力パラメタを，executeBatchメソッドで一括実行します。

一括実行の結果として，それぞれの入力パラメタのセットで実行された，SQLの返却値（更新行数）の配列を返します。

一括実行の途中でエラーが発生した場合，BatchUpdateExceptionをthrowします。

CallableStatementインスタンス生成時に指定したSQLが更新行数を返さない場合，および出力パラメタか入出力パラメタを持つ場合，executeBatchメソッド呼び出し時にBatchUpdateExceptionをthrowします。

注意事項

定義系および制御系SQLについては，addBatchメソッドを実行しないでください。

(d)　HiRDBの場合のバッチ更新

HiRDBの場合のバッチ更新処理は，次の2種類に分けられます。

逐次実行
複数のSQLに分けて実行する更新処理です。

一括実行
HiRDBの配列更新機能を使用して実行する更新処理です。

HiRDBの配列更新機能とは，データベースにより提供される次の機能を指します。

HiRDBの配列を使用したINSERT機能

HiRDBの配列を使用したUPDATE機能

HiRDBの配列を使用したDELETE機能

HiRDBクライアント経由XDM／RD E2で使用するXDM／RD E2の配列を使用したINSERT機能

HiRDBクライアント経由XDM／RD E2で使用するXDM／RD E2の配列を使用したUPDATE機能

HiRDBクライアント経由XDM／RD E2で使用するXDM／RD E2の配列を使用したDELETE機能

HiRDBの配列更新機能では，複数の?パラメタセットを配列形式で扱い，一度に処理することができます。そのため，データベースとの通信回数が減り，大量のデータを高速に更新できます。

HiRDBの配列更新機能を使用するには，BlockUpdate設定をtrueにします。ただし，接続するHiRDBのバージョンによって使用できない場合があります。HiRDBの配列更新機能の詳細については，マニュアル「HiRDB　UAP開発ガイド」およびマニュアル「HiRDB　SQLリファレンス」を参照してください。

●addBatchメソッド－executeBatchメソッド使用時の仕様

次に，バッチ更新時に使用するaddBatchメソッド－executeBatchメソッド使用時の仕様を，BlockUpdate設定がtrueの場合とfalseの場合に分けて示します。

表I-2　addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がtrue，HiRDBの場合）

実行するSQL文
DABrokerの仕様（処理方法）

HiRDB Version 6
HiRDB Version 7 07-00以降かつ07-00-/K以前
HiRDB Version 7 07-00-/L以降かつHiRDB Version 7 07-01未満
HiRDB Version 7 07-01以降

INSERT文
（VALUES句指定）
逐次実行
一括実行
一括実行
一括実行

INSERT文
（SELECT句指定）
逐次実行
KFPA19408-E
逐次実行
一括実行

UPDATE文
逐次実行
KFPA19408-E
逐次実行
一括実行

DELETE文
逐次実行
KFPA19408-E
逐次実行
一括実行

CALL文（OUTまたはINOUTパラメタあり）
KFDJ00010-E
KFDJ00010-E
KFDJ00010-E
KFDJ00010-E

CALL文（INパラメタだけ）
逐次実行
逐次実行
逐次実行
逐次実行

（凡例）

一括実行：HiRDBの配列更新機能を使用してSQLを一括実行します。

逐次実行：HiRDBの配列更新機能を使用しないでSQLを分けて実行します。

KFPA19408-E：エラー（KFPA19408-E）が発生します。HiRDBの配列更新機能は使用できません。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれていた場合，例外となります。

表I-3　 addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がfalseまたは指定なし，HiRDBの場合）

実行するSQL文 | DABrokerの仕様（処理方法）
INSERT文（VALUES句指定） | 逐次実行
INSERT文（SELECT句指定） | 逐次実行
UPDATE文 | 逐次実行
DELETE文 | 逐次実行
SELECT文 | KFDJ00010-E
CALL文（OUTまたはINOUTパラメタあり） | KFDJ00010-E
CALL文（INパラメタだけ） | 逐次実行

（凡例）

逐次実行：HiRDBの配列更新機能を使用しないでSQLを分けて実行します。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれていた場合，例外となります。

表I-4　addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がtrue，HiRDBクライアント経由XDM/RD E2の場合）

実行するSQL | DABrokerの仕様（処理方式）
HiRDBクライアント08-02未満 | HiRDBクライアント08-02以降
XDM／RD E2（11-03未満） | XDM／RD E2（11-03以降）
INSERT文（VALUES句指定） | 逐次実行 | 逐次実行 | 一括実行
INSERT文（SELECT句指定） | 逐次実行 | 逐次実行 | 一括実行
UPDATE文 | 逐次実行 | 逐次実行 | 一括実行
DELETE文 | 逐次実行 | 逐次実行 | 一括実行
SELECT文 | KFDJ00010-E | KFDJ00010-E | KFDJ00010-E
CALL文（OUT，またはINOUTパラメタ有） | KFDJ00010-E | KFDJ00010-E | KFDJ00010-E
CALL文（INパラメタだけ） | 逐次実行 | 逐次実行 | 逐次実行

（凡例）

一括実行：HiRDBの配列更新機能を使用してSQLを一括実行します。

逐次実行：HiRDBの配列更新機能を使用しないでSQLを分けて実行します。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれている場合，例外となります。

表I-5　addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がfalseまたは指定なし，HiRDBクライアント経由XDM/RD E2の場合）

実行するSQL文 | DABrokerの仕様
INSERT文（VALUES句指定） | 逐次実行
INSERT文（SELECT句指定） | 逐次実行
UPDATE文 | 逐次実行
DELETE文 | 逐次実行
SELECT文 | KFDJ00010-E
CALL文（OUT，またはINOUTパラメタあり） | KFDJ00010-E
CALL文（INパラメタだけ） | 逐次実行

（凡例）

逐次実行：HiRDBの配列更新機能を使用しないでSQLを分けて実行します。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれている場合，例外となります。

●HiRDBの配列更新機能の使用方法

HiRDBの配列更新機能の使用方法を次に示します。

BlockUpdate設定をtrueにします。
Connect時に，プロパティとしてBLOCK_UPDATE=TRUEを指定するか（DataSourceを使用する場合はsetBlockUpdate(true)），JdbcDbpsvPreparedStatementのsetBlockUpdate(true)を指定します。

パラメタが一つ以上あるSQLを前処理します。

PreparedStatementクラス，またはCallableStatementクラスのsetメソッドで，?パラメタに対する値を設定します。

addBatchメソッドで，?パラメタセットを追加します。

executeBatchメソッドで，バッチ更新を実行します。

●HiRDBの配列更新機能使用時の注意事項

共通項目
サポートするHiRDB全バージョン共通の注意事項を次に示します。

HiRDBの配列更新機能を使用するには，接続時のプロパティ情報，またはデータソースのBlockUpdateをtrueで設定するか，PreparedStatementのsetBlockUpdateメソッドをtrueに設定する必要があります。

HiRDBの配列更新機能は，?パラメタを持つSQL文に対して有効です。プロシジャやStatementクラスのaddBatch(String sql)を使用した場合は有効となりません。

パラメタセットを登録する場合，PreparedStatement，またはCallableStatementのaddBatchメソッドを使用してください。StatementのaddBatch(String sql)を使用するとエラーになります。

HiRDBの配列更新機能は，addBatchメソッドで登録したパラメタセットが2件以上ある場合に有効です。1件の場合はHiRDBの配列更新機能を使用しないで実行されます。

実行するSQLには，?パラメタが一つ以上必要です。?パラメタがない場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

XA環境下のHiRDBに接続してバッチ更新を実行する場合，setAutoCommit(false)を設定する必要があります。setAutoCommit(false)を設定しないで実行するとHiRDBでエラーになります。

DECIMAL型データをパラメタセットに設定する場合，配列に指定するDECIMAL型データの精度，および位取りはHiRDBの表定義属性に合わせられます。整数部のけた数がHiRDBの表定義の整数部のけた数より大きいと，けたあふれが発生してエラーになります。

SMALLINT型，INTEGER型，またはDECIMAL型の列に，setInt，またはsetStringを使用して範囲外のデータを設定するとエラーになります。

配列更新の途中でエラーが発生した場合，エラーが発生する直前までの実行もすべて無効になります。

?パラメタにHiRDBの繰り返し列（複数要素を格納できる列）を指定している場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

setNullメソッドで，HiRDBの表定義の列属性がCHAR，NCHAR，MCHAR，DATE，TIME，またはTIMESTAMPの場合，列属性と同じjava.sql.Typesを指定していると，HiRDBの配列更新機能は使用されないで，逐次実行されます。

setNullメソッドで，HiRDBの表定義の列属性と異なるjava.sql.Typesを指定している場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。ただし，次の場合は，HiRDBの配列更新機能が実行されます。
・HiRDBの表定義の列属性がCHAR，NCHAR，またはMCHARで，java.sql.Typesにjava.sqlTypes.VARCHARを指定した場合
・HiRDBの表定義の列属性がDATE，TIME，またはTIMESTAMPで，java.sql.Typesにjava.sql.Types.CHARを指定した場合

HiRDBのバージョンが07-00の場合の注意事項
HiRDBのバージョンが07-00の場合，次に示すバージョン固有の注意事項がありま
す。共通項目と合わせて注意してください。

HiRDBのバージョンが07-00の場合，使用できるHiRDBの配列更新機能は，「配列を使用したINSERT機能（INSERT VALUE句だけ）」です。「配列を使用したINSERT機能（INSERT VALUE句以外）」，「配列を使用したUPDATE機能」，および「配列を使用したDELETE機能」は使用できません。

?パラメタにHiRDBのBLOB型の列，または定義長32,001バイト以上のBINARY型の列を指定している場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

WITH DEFAULT指定のBLOB型の列，またはWITH DEFAULT指定で定義長32,001バイト以上のBINARY型の列の場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

HiRDBの行単位トリガを定義した表に対して更新する場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

HiRDBのバージョンが07-01以降の場合の注意事項
HiRDBのバージョンが07-01以降の場合，次に示すバージョン固有の注意事項があります。共通項目と合わせて注意してください。

「配列を使用したINSERT機能」，「配列を使用したUPDATE機能」，および「配列を使用したDELETE機能」が使用できます。

?パラメタにデータ長が32,001バイト以上のBINARYデータを指定している場合，HiRDBの配列更新機能は使用されないで，逐次実行されます。

HiRDBのBLOB型列に対して32,001バイト以上のデータを指定している場合，HiRDBの配列更新機能は使用され，逐次実行されます。

(e)　Oracleの場合のバッチ更新

ここでは，Oracleの場合のバッチ更新について説明します。

●addBatchメソッド－executeBatchメソッド使用時の仕様

次に，PreparedStatementおよびCallableStatementでのaddBatchメソッド－executeBatchメソッド使用時の仕様を，BlockUpdate設定がtrueの場合，falseの場合に分けて示します。

表I-6　 addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がtrue，Oracleの場合）

実行するSQL文 | DABrokerの仕様（処理方法）
INSERT文（VALUES句指定） | 逐次実行
INSERT文（SELECT句指定） | 逐次実行
UPDATE文 | 逐次実行
DELETE文 | 逐次実行
SELECT文 | KFDJ00010-E
BEGIN文（OUTまたはINOUTパラメタあり） | KFDJ00010-E
BEGIN文（INパラメタだけ） | 逐次実行

（凡例）

逐次実行：SQLを分けて実行します。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれていた場合，例外となります。

表I-7　 addBatchメソッド－executeBatchメソッド使用時の仕様（BlockUpdate設定がfalseまたは指定なし，Oracleの場合）

実行するSQL文 | DABrokerの仕様（処理方法）
INSERT文（VALUES句指定） | 逐次実行
INSERT文（SELECT句指定） | 逐次実行
UPDATE文 | 逐次実行
DELETE文 | 逐次実行
SELECT文 | KFDJ00010-E
BEGIN文（OUTまたはINOUTパラメタあり） | KFDJ00010-E
BEGIN文（INパラメタだけ） | 逐次実行

（凡例）

逐次実行：SQLを分けて実行します。

KFDJ00010-E：エラー（KFDJ00010-E）が発生します。JDBC2.0規格では，executeBatchメソッドで更新行数を返さないもの（SELECTなど）が含まれていた場合，例外となります。

●addBatchメソッド使用時の注意事項

実行するSQLに?パラメタを一つ以上含めてください。

配列に指定するデータ型が異なる場合にはエラーとなります。

Cosminexusから使用する場合は，PreparedStatementクラスのsetBlockUpdateメソッドは使用できません。

(3)　JDBC SQLタイプの扱い

JDBC2.0基本規格では，幾つかの新しいJDBC SQLタイプが追加されています。追加されたJDBC SQLタイプとCosminexus DABroker Libraryでのサポートを，次の表に示します。

表I-8　 追加されたJDBC SQLタイプとCosminexus DABroker Libraryでのサポート

追加されたJDBC SQLタイプ | Cosminexus DABroker Libraryでのサポート
BLOB | ○
CLOB | △
ARRAY | ×
REF | ×
DISTINCT | ×
STRUCT | ×
JAVA OBJECT | ×

（凡例）

○：Oracle9i，Oracle10g，およびHiRDBでサポートしています。

△：Oracle9i，およびOracle10gでだけサポートしています。

×：サポートしていません。

(a)　検索データ取得時のデータ変換

追加されたJDBC SQLタイプと，ResultSetクラスのgetXXXメソッドとのデータ変換について，次の表に示します。変換できないJDBC SQLタイプに対してgetXXXメソッドが呼び出された場合は，SQLExceptionをthrowします。接続データベースがどのJDBC SQLタイプをサポートしているかは，「付録I.7　データ型の対応」を参照してください。

なお，JDBC2.0規格ではgetUnicodeStreamメソッドが推奨されないメソッドとなったため，代わりにgetCharacterStreamが追加されています。

表I-9　 ResultSetクラスのgetXXXメソッドとJDBC SQLタイプとのデータ変換 （1）

getXXXメソッド
JDBC SQLタイプ

B
I
T
T
I
N
Y
I
N
T
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
F
L
O
A
T
R
E
A
L
D
O
U
B
L
E
N
U
M
E
R
I
C
D
E
C
I
M
A
L
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R

getByte
○
◎
○
○
○
○
○
○
○
○
○
○
○

getShort
○
○
◎
○
○
○
○
○
○
○
○
○
○

getInt
○
○
○
◎
○
○
○
○
○
○
○
○
○

getLong
○
○
○
○
◎
○
○
○
○
○
○
○
○

getFloat
○
○
○
○
○
○
◎
○
○
○
○
○
○

getDouble
○
○
○
○
○
◎
○
◎
○
○
○
○
○

getBigDecimal
○
○
○
○
○
○
○
○
◎
◎
■
○
○

getBoolean
◎
○
○
○
○
○
○
○
○
○
○
○
○

getString
○
○
○
○
○
○
○
○
○
○
◎
◎
○

getBytes
－
－
－
－
－
－
－
－
－
－
－
－
－

getDate※1
－
－
－
－
－
－
－
－
－
－
○
○
○

getTime※1
－
－
－
－
－
－
－
－
－
－
○
○
○

getTimestamp※1
－
－
－
－
－
－
－
－
－
－
○
○
○

getAsciiStream
－
－
－
－
－
－
－
－
－
－
○
○
◎

getUnicodeStream
－
－
－
－
－
－
－
－
－
－
○
○
◎

getBinaryStream
－
－
－
－
－
－
－
－
－
－
－
－
－

getObject
○
○
○
○
○
○
○
○
○
○
○
○
○

getCharacter
Stream
－
－
－
－
－
－
－
－
－
－
○
○
◎

getArray
（未サポート）
－
－
－
－
－
－
－
－
－
－
－
－
－

getBlob※2
－
－
－
－
－
－
－
－
－
－
－
－
－

getClob※3
－
－
－
－
－
－
－
－
－
－
－
－
－

getRef
（未サポート）
－
－
－
－
－
－
－
－
－
－
－
－
－

（凡例）

◎：完全に変換できます。

○：変換できます。ただし，変換元のデータの内容によってはデータの欠落や変換エラーとなることがあります。

■：設定値が定義長に満たない場合，エラーが発生します。

－：変換できません。

注※1

引数にjava.util.Calendarオブジェクトを指定するgetDate，getTimeおよびgetTimestampメソッドを実行すると，データベースに格納されたデータが指定したjava.util.Calendarオブジェクトのタイムゾーンであるとして，実行しているアプリケーションのデフォルトのタイムゾーンに変換して取得します。

注※2

Oracle9i，Oracle10g，およびHiRDBでサポートしています。

注※3

Oracle9i，およびOracle10gでサポートしています。

表I-10　 ResultSetクラスのgetXXXメソッドとJDBC SQLタイプとのデータ変換 （2）

getXXXメソッド
JDBC SQLタイプ

D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
B
I
N
A
R
Y
V
A
R
B
I
N
A
R
Y
L
O
N
G
V
A
R
B
I
N
A
R
Y
J
A
V
A
O
B
J
E
C
T
S
T
R
U
C
T
A
R
R
A
Y
B
L
O
B
C
L
O
B
R
E
F

getByte
－
－
－
－
－
－
－
－
－
－
－
－

getShort
－
－
－
－
－
－
－
－
－
－
－
－

getInt
－
－
－
－
－
－
－
－
－
－
－
－

getLong
－
－
－
－
－
－
－
－
－
－
－
－

getFloat
－
－
－
－
－
－
－
－
－
－
－
－

getDouble
－
－
－
－
－
－
－
－
－
－
－
－

getBigDecimal
－
－
－
－
－
－
－
－
－
－
－
－

getBoolean
－
－
－
－
－
－
－
－
－
－
－
－

getString
○
○
○
○
○
○
－
－
－
－
－
－

getBytes
－
－
－
◎
◎
○
－
－
－
－
－
－

getDate※1
◎
－
○
－
－
－
－
－
－
－
－
－

getTime※1
－
◎
○
－
－
－
－
－
－
－
－
－

getTimestamp※1
○
－
◎
－
－
－
－
－
－
－
－
－

getAsciiStream
－
－
－
○
○
○
－
－
－
－
－
－

getUnicodeStream
－
－
－
○
○
○
－
－
－
－
－
－

getBinaryStream
－
－
－
○
○
◎
－
－
－
－
－
－

getObject
○
○
○
○
○
○
▲
▲
△
▼
▼
△

getCharacter
Stream
－
－
－
○
○
○
－
－
－
－
－
－

getArray
（未サポート）
－
－
－
－
－
－
－
－
▲
－
－
－

getBlob※2
－
－
－
－
－
○※4
－
－
－
●
－
－

getClob※3
－
－
－
－
－
－
－
－
－
－
●
－

getRef
（未サポート）
－
－
－
－
－
－
－
－
－
－
－
▲

（凡例）

◎：完全に変換できます。

○：変換できます。ただし，変換元のデータの内容によってはデータの欠落や変換エラーとなることがあります。

●：完全に変換できる組み合わせです。ただし，接続するデータベースがOracle9iまたはOracle10gの場合以外は，JDBC SQLタイプが未サポートのため使えません。

▼：変換できる組み合わせです。ただし，接続するデータベースがOracle9iまたはOracle10gの場合以外は，JDBC SQLタイプが未サポートのため使えません。

▲：完全に変換できる組み合わせです。ただし，JDBC SQLタイプが未サポートのため使えません。

△：変換できる組み合わせです。ただし，JDBC SQLタイプが未サポートのため使えません。

－：変換できません。

注※1

引数にjava.util.Calendarオブジェクトを指定するgetDate，getTimeおよびgetTimestampメソッドを実行すると，データベースに格納されたデータが指定したjava.util.Calendarオブジェクトのタイムゾーンであるとして，実行しているアプリケーションのデフォルトのタイムゾーンに変換して取得します。

注※2

Oracle9i，Oracle10g，およびHiRDBでサポートしています。

注※3

Oracle9i，およびOracle10gでサポートしています。

注※4

HiRDBでだけサポートしています。

(b)　？パラメタ設定時のデータ変換

追加されたJDBC SQLタイプと，PreparedStatementクラスのsetXXXメソッドとのデータ変換について，次の表に示します。JDBC SQLタイプをサポートしていない場合，setXXXメソッドはSQLExceptionをthrowします。接続データベースがどのJDBC SQLタイプをサポートしているかは，「付録I.7　データ型の対応」を参照してください。

なお，JDBC2.0規格では，setUnicodeStreamメソッドが推奨されないメソッドとなったため，代わりにsetCharacterStreamが追加されています。

表I-11　 追加されたJDBC SQLタイプとsetXXXメソッド

setXXXメソッド | データ変換されるJDBC SQLタイプ
setCharacterStream | CHAR，VARCHAR，またはLONGVARCHAR
setRef（未サポート） | REF
setBlob※1 | BLOB，LONGVARBINARY
setClob※2 | CLOB
setArray（未サポート） | ARRAY

注※1

Oracle9i，Oracle10g，およびHiRDBでサポートしています。

注※2

Oracle9i，およびOracle10gでサポートしています。

表I-12　 setXXXメソッドとJDBC SQLタイプとのデータ変換 （1）

setXXXメソッド
JDBC SQLタイプ

B
I
T
T
I
N
Y
I
N
T
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
F
L
O
A
T
R
E
A
L
D
O
U
B
L
E
N
U
M
E
R
I
C
D
E
C
I
M
A
L
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R

setByte
○
◎
○
○
○
○
○
○
○
○
○
○
○

setShort
○
○
◎
○
○
○
○
○
○
○
○
○
○

setInt
○
○
○
◎
○
○
○
○
○
○
○
○
○

setLong
○
○
○
○
◎
○
○
○
○
○
○
○
○

setFloat
○
○
○
○
○
○
◎
○
○
○
○
○
○

setDouble
○
○
○
○
○
◎
○
◎
○
○
○
○
○

setBigDecimal
○
○
○
○
○
○
○
○
◎
◎
○
○
○

setBoolean
◎
○
○
○
○
○
○
○
○
○
○
○
○

setString
○
○
○
○
○
○
○
○
○
○
◎
◎
○

setBytes
－
－
－
－
－
－
－
－
－
－
－
－
－

setDate
－
－
－
－
－
－
－
－
－
－
○
○
○

setTime
－
－
－
－
－
－
－
－
－
－
○
○
○

setTimestamp
－
－
－
－
－
－
－
－
－
－
○
○
○

setAsciiStream
－
－
－
－
－
－
－
－
－
－
○※4
○※4
○※4

setUnicodeStream※1
－
－
－
－
－
－
－
－
－
－
○
○
○

setBinaryStream
－
－
－
－
－
－
－
－
－
－
－
－
－

setObject
○
○
○
○
○
○
○
○
○
○
○
○
○

setCharacterStream
－
－
－
－
－
－
－
－
－
－
○※5
○※5
○※5

setArray
（未サポート）
－
－
－
－
－
－
－
－
－
－
－
－
－

setBlob※2
－
－
－
－
－
－
－
－
－
－
－
－
－

setClob※3
－
－
－
－
－
－
－
－
－
－
－
－
－

setRef
（未サポート）
－
－
－
－
－
－
－
－
－
－
－
－
－

（凡例）

◎：完全に変換できます。

○：変換できます。ただし，変換元のデータの内容によってはデータの欠落や変換エラーとなることがあります。

－：変換できません。

注※1

Oracle9i，Oracle10g，およびHiRDBでサポートしています。

注※2

Oracle9i，およびOracle10gでサポートしています。

注※3

長さが0のデータを設定するとエラーになります。

注※4

接続データベースがOracleの場合，長さが0のデータを設定すると，NULL値に変換します。

注※5

java.io.Readerオブジェクトから取得できるデータの長さが引数で指定した長さより短い場合，次のように引数で指定した長さまで0を補完します。

表I-13　 setXXXメソッドとJDBC SQLタイプとのデータ変換（2）

setXXXメソッド
JDBC SQLタイプ

D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
B
I
N
A
R
Y
V
A
R
B
I
N
A
R
Y
L
O
N
G
V
A
R
B
I
N
A
R
Y
J
A
V
A
O
B
J
E
C
T
S
T
R
U
C
T
A
R
R
A
Y
B
L
O
B
C
L
O
B
R
E
F

setByte
－
－
－
－
－
－
－
－
－
－
－
－

setShort
－
－
－
－
－
－
－
－
－
－
－
－

setInt
－
－
－
－
－
－
－
－
－
－
－
－

setLong
－
－
－
－
－
－
－
－
－
－
－
－

setFloat
－
－
－
－
－
－
－
－
－
－
－
－

setDouble
－
－
－
－
－
－
－
－
－
－
－
－

setBigDecimal
－
－
－
－
－
－
－
－
－
－
－
－

setBoolean
－
－
－
－
－
－
－
－
－
－
－
－

setString
○
○
○
○
○
○
－
－
－
－
－
－

setBytes
－
－
－
◎
◎
○
－
－
－
－
－
－

setDate
◎
－
○
－
－
－
－
－
－
－
－
－

setTime
－
◎
○
－
－
－
－
－
－
－
－
－

setTimestamp
○
－
◎
－
－
－
－
－
－
－
－
－

setAsciiStream
－
－
－
○
○※4
○※4
－
－
－
－
－
－

setUnicodeStream※3
－
－
－
○
○
○
－
－
－
－
－
－

setBinaryStream
－
－
－
○
○※4
○※4
－
－
－
－
－
－

setObject
○
○
○
○
○
○
▲
▲
△
▼
▼
△

setCharacterStream
－
－
－
○※5
○※5
○※5
－
－
－
－
－
－

setArray（未サポート）
－
－
－
－
－
－
－
－
▲
－
－
－

setBlob※1
－
－
－
－
－
○※1
－
－
－
●※2※4
－
－

setClob※2
－
－
－
－
－
－
－
－
－
－
●※4
－

setRef（未サポート）
－
－
－
－
－
－
－
－
－
－
－
▲

（凡例）

◎：完全に変換できます。

○：変換できます。ただし，変換元のデータの内容によってはデータの欠落や変換エラーとなることがあります。

●：完全に変換できる組み合わせは，接続するデータベースがOracle9iまたはOracle10gの場合以外は，JDBC SQLタイプが未サポートのため使えません。

▼：変換できる組み合わせは，接続するデータベースがOracle9iまたはOracle10gの場合以外は，JDBC SQLタイプが未サポートのため使えません。

▲：完全に変換できる組み合わせは，JDBC SQLタイプが未サポートのため使えません。

△：変換できる組み合わせは，JDBC SQLタイプが未サポートのため使えません。

－：変換できません。

注※1

Oracle9i，Oracle10g，およびHiRDBでサポートしています。

注※2

Oracle9i，およびOracle10gでサポートしています。

注※3

長さが0のデータを設定するとエラーになります。

注※4

接続データベースがOracleである場合，長さが0であるデータを設定するとNULL値に変換します。

注※5

java.io.Readerオブジェクトから取得できるデータの長さが引数で指定した長さより短い場合，次のように引数で指定した長さまで0を補完します。

付録I.3　JDBC2.0拡張機能の概要

ここでは，Cosminexus DABroker Libraryで提供するJDBC2.0拡張機能の概要を説明します。各メソッドでの制限事項については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

＜この項の構成＞

(1)　JNDI連携

(2)　接続プール

(3)　注意事項

(4)　分散トランザクション機能

(1)　JNDI連携

JNDI連携とは，DBMSとの接続情報をJNDIに登録し，登録した接続情報を使用してDBMSと接続する機能です。一度接続情報を登録すれば，DBMSとの接続時に接続情報を設定する必要がなくなります。JNDI連携の操作については，「付録I.5　JDBC2.0拡張機能を使用したデータベース接続の設定」を参照してください。

(2)　接続プール

接続プール機能は，DataSourceオブジェクトとJNDIを使用してデータベースと接続した場合だけ使用できます。

データベースとの接続をためる（プール）機能の概要について説明します。

(a)　概要

DBMSとの接続をプールします。この機能は，DBMSとの接続および解放によるオーバーヘッドを縮小し，サーバアプリケーションの性能向上に役立ちます。

アプリケーションに影響を与えないため，接続プールの有無を意識する必要がない。

システム構築時に，接続プール機能を任意に選択できる（ユーザが作成する，アプリケーションサーバのベンダが提供するものを使用する，またはJDBCのベンダが提供するものを使用する）。

接続プール機能では，アプリケーションとのインタフェースとして，DataSourceクラスを提供する。

JDBC2.0拡張機能では，接続プール機能とのインタフェースとして，ConnectionPoolDataSourceクラスとPooledConnectionクラスを提供する。

ConnectionPoolDataSourceクラスは，JDBC2.0拡張機能が提供するDataSourceクラスと同様に，接続情報の設定および取得用のメソッドを提供する。

(b)　関連するクラス

接続プール機能に関連するクラスを次の表に示します。

表I-14　 接続プールに関連するクラス

クラス
概要

javax.sql.
ConnectionEventListener

接続プール機能が提供

接続プール機能で，接続の切断，SQLエラーなどをこのクラスのオブジェクトから検知※1

javax.sql.DataSource

接続プール機能が提供

データベース接続時のアプリケーションとのインタフェース

接続プールを制御

JNDIに登録して使用

javax.sql.
ConnectionPoolDataSource

JDBC2.0拡張機能が提供※2

データベース接続に必要な接続情報の設定および取得用のメソッドを提供

接続プール機能が使用

JNDIに登録して使用

このクラスのオブジェクトからPooledConnectionオブジェクトを取得

javax.sql.PooledConnection

JDBC2.0拡張機能が提供※2

接続プール機能が使用

このクラスのオブジェクトがプール対象

このクラスのオブジェクトからConnectionオブジェクトを取得

注※1

connectionErrorOccurredが返されるのは次のエラーコードの場合です。

接続データベースがHiRDB：-720，-722，-723，-728，-732，-932，-1700

接続データベースがOracle：28，1012，3113，3114，12571

注※2

JDBC2.0拡張機能が提供するパッケージ名称とクラス名称を次に示します。

種類 | 名称
パッケージ | JP.co.Hitachi.soft.DBPSV_Driver
ConnectionPoolDataSourceクラス | JdbcDbpsvConnectionPoolDataSource
PooledConnectionクラス | JdbcDbpsvPooledConnection

(3)　注意事項

接続プール機能に関連するクラスのインタフェース定義は，JDKでは標準で提供していません。接続プール機能を使用するときは，JavaSoftのホームページから入手しておいてください。

(4)　分散トランザクション機能

分散トランザクション機能とは，Sun Microsystemsの提唱するJava Transaction API（JTA）規格を基に，トランザクションマネージャと連携する，接続プール機能の拡張機能です。

分散トランザクション機能は，XADataSourceクラスとJNDIを使用してデータベースと接続した場合だけ使用できます。

分散トランザクション機能の概要について説明します。

(a)　概要

JTSおよびJTAとの連携によって，Sun Microsystemsの提唱するJava Transaction API（JTA）規格に沿った，分散トランザクションを構築できます。

システム構築時に，トランザクション連携機能を任意に選択できます（ユーザが作成する，APServerベンダ提供のものを使用する，またはJDBCベンダが提供するものを使用する）。

トランザクション連携機能は，接続プールの拡張機能として，トランザクションマネージャが提供する，JTAやJTSを使用します。

トランザクション連携機能では，アプリケーションとのインタフェースとして，DataSourceクラスを提供します。

JDBC2.0拡張機能では，トランザクション連携機能とのインタフェースとして，XADataSourceクラスとXAConnectionクラスを提供します。また，トランザクションマネージャとのインタフェースとして，XAResourceクラスを提供します。

XADataSourceクラスは，JDBC2.0拡張機能が提供するDataSourceクラスと同様に，接続情報の設定および取得用のメソッドを提供します。

接続プールの場合と同様に，アプリケーションが使用するConnectionオブジェクトはXAConnectionクラスが生成しますが，PooledConnectionクラスやJDBC2.0拡張機能が提供するDataSourceクラスが生成するConnectionオブジェクトと比べて，次の点が異なります。

接続情報にXALocalCommitMode(true)を設定していない場合には，XADataSourceクラス使用時，AutoCommitのモードはOFFになります。また，AutoCommitのモードをONにしたり（ConnectionクラスのsetAutoCommit(true)メソッドの発行），Connectionクラスのcommitメソッド，またはrollbackメソッドを実行したりすると，SQLExceptionとなります。ただし，XALocalCommitMode(true)をプロパティに設定している場合だけAutoCommitのモードはONとなります。

一つのXAResourceに対して複数のConnectionクラスを生成してもトランザクションは一つになります。XAResource，Connectionは一対一で使用するようにしてください。トランザクションがローカルトランザクション※1の場合，ConnectionクラスのsetAutoCommit(true)メソッド，commitメソッド，およびrollbackメソッドを呼び出せます。同じXAResourceを使用するトランザクションがグローバルトランザクション※2を開始すると，自動的にAutoCommitのモードはOFFになります。再び，トランザクションがローカルトランザクションに移行すると，開始前のAutoCommitのモードに変更されます。複数のConnectionを使用して，トランザクションがローカルトランザクションのときにsetAutoCommitメソッドでAutoCommitのモードを変更する場合は，すべてのConnectionクラスのオブジェクトに対してそれぞれsetAutoCommitメソッドを呼び出してAutoCommitのモードを統一させる必要があります。現在のトランザクションがローカルトランザクションで，AutoCommitのモードがOFFの状態で新たにConnectionを生成した場合，新しいConnectionクラスのオブジェクトに対してsetAutoCommit(false)を実行してください。

注※1

ローカルトランザクションとは，XAResourceクラスのstart実行前，またはXAResourceクラスのend実行後の状態にあるトランザクションのことです。

注※2

グローバルトランザクションとは，XAResourceクラスのstart実行後，またはXAResourceクラスのendを実行するまでの状態にあるトランザクションのことで，トランザクションマネージャがトランザクション制御を行っている状態を指します。

次の状態のとき，Connectionクラスのcloseメソッドを実行しても，接続しているデータベースによってトランザクションが決着されないことがあります。

接続情報にXALocalCommitMode(true)を設定している。

AutoCommitのモードをOFFにしている。

ローカルトランザクション内でSQLを実行し，Connectionクラスのcommitメソッド，またはrollbackメソッドを実行しない。

トランザクションを決着させるには，Connectionクラスのcloseメソッドを実行する前に，明示的にConnectionクラスのcommitメソッド，またはrollbackメソッドを実行する必要があります。

HiRDBの配列更新機能を使用するには，setXALocalCommitMode(true)，およびsetBlockUpdate(true)に設定してHiRDBに接続後，AutoCommit(false)を指定する必要があります。HiRDBにsetXALocalCommitMode(true)を設定して接続し，HiRDBの配列更新機能を使用する例を次に示します。
なお，HiRDBの配列更新機能については，「付録I.2(2)　バッチ更新」を参照してください。

XADataSource xads = new XADataSource();
xads.setDatabaseName("HIRDB");
xads.setXALocalCommitMode(true);
               ・
               ・
Connection con = xaconnection.getConnection();
String sql = "INSERT INTO SAMPLE VALUES(?)";
PreparedStatement pst = con.prepareStatement(sql);
con.setAutoCommit(false);
pst.setInt(1,10);
pst.addBatch();
pst.setInt(1,20);
pst.addBatch();
pst.executeBatch();
con.commit();

Cosminexus DABroker Libraryは，SQLの前処理を複数のCommit，Rollbackにわたって保持します。
この機能をXA環境下で使用できるデータベースは，HiRDBのバージョンが07-01以降です。また，SQLの前処理の保持機能が使用できるのは，グローバルトランザクション，およびローカルトランザクションを混在せずに使用している場合だけです。
ローカルトランザクションとグローバルトランザクションを混在させて使用すると，ローカルトランザクションSQLの前処理の保持機能は使用できません。
XA環境下でローカルトランザクションとグローバルトランザクションが混在したJavaUPの場合の前処理保持状態を次に示します。

図I-2　XA環境下でローカルトランザクションとグローバルトランザクションが混在したJavaUPの場合の前処理保持状態

(b)　関連するクラス

分散トランザクション機能に関連するクラスを次の表に示します。

表I-15　 分散トランザクションに関連するクラス

クラス
概要

javax.sql.
ConnectionEventListener

トランザクション連携機能が提供

トランザクション連携機能で，接続の切断，SQLエラーなどをこのクラスのオブジェクトから検知※1

javax.sql.DataSource

トランザクション連携機能が提供

データベース接続時のアプリケーションとのインタフェース

トランザクションマネージャとの連携および接続プールを制御

JNDIに登録して使用

javax.sql.XADataSource

JDBC2.0拡張機能が提供※2

データベース接続に必要な接続情報の設定および取得用のメソッドを提供

トランザクション連携機能が使用

JNDIに登録して使用

このクラスのオブジェクトからXAConnectionオブジェクトを取得

javax.sql.XAConnection

JDBC2.0拡張機能が提供※2

PooledConnectionクラスのサブクラス

トランザクション連携機能が使用

このクラスのオブジェクトがプール対象

このクラスのオブジェクトからConnectionオブジェクトを取得

javax.transaction.xa.
XAResource

JDBC2.0拡張機能が提供※2

トランザクションマネージャが使用するXA関連メソッドを提供

javax.transaction.xa.Xid

JDBC2.0拡張機能※2およびトランザクションマネージャが提供

XAResourceクラスの引数および戻り値として使用

注※1

connectionErrorOccurredが返されるのは次のエラーコードの場合です。

接続データベースがHiRDB：-720，-722，-723，-728，-732，-932，-1700

接続データベースがOracle：28，1012，3113，3114，12571

注※2

JDBC2.0拡張機能が提供するパッケージ名称とクラス名称を次に示します。

種類 | 名称
パッケージ | JP.co.Hitachi.soft.DBPSV_Driver
XADataSourceクラス | JdbcDbpsvXADataSource
XAConnectionクラス | JdbcDbpsvXAConnection
XAResourceクラス | JdbcDbpsvXAResource
Xidクラス | JdbcDbpsvXid

(c)　注意事項

トランザクション連携機能に関連するクラスのインタフェース定義は，JDKでは標準で提供していません。トランザクション連携機能を使用するときは，JavaSoftのホームページから入手しておいてください。

付録I.4　データベース接続の設定

Cosminexus DABroker Libraryで開発するアプリケーションでは，次の項目を設定します。ただし，トレースを取得するための情報の設定は任意です。

使用するJDBCドライバの設定

接続するデータベースの設定

データベースに接続するための各種情報の設定

トレースを取得するための情報の設定（任意）

ここでは，それぞれの設定内容について説明します。

なお，アプリケーション運用時に必要となる，アプリケーションの組み込みやインタフェースの定義については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

＜この項の構成＞

(1)　使用するJDBCドライバの設定

(2)　接続するデータベースの設定

(3)　データベースに接続するための各種情報の設定

(4)　トレースを取得するための情報の設定

(1)　使用するJDBCドライバの設定

JDBCドライバのロードに，次のドライバ名称およびパッケージ名称を設定します。

設定項目 | 設定値
ドライバ名称 | JdbcDbpsvDriver
パッケージ名称 | JP.co.Hitachi.soft.DBPSV_Driver

ドライバ名称およびパッケージ名称は，次のどちらかの方法で設定してください。

Class.forNameメソッドでの設定
Class.forNameメソッドでアプリケーションからJDBCドライバを登録します。
アプリケーション内に次のように記述してください。

Class.forName("JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDriver")

システム（java.lang.System）プロパティのjdbc.driversでの指定
システムプロパティにJDBCドライバを登録します。
システムプロパティでの指定方法は，Javaの各処理系の仕様に依存します。
次に，システムプロパティへの登録方法を示します。

Appletviewerでの指定－Javaアプレットの場合
[JAVA_HOME]/.hotjava/propertiesファイルに次の記述を追加してください。複数のドライバを使用する場合は，「:（コロン）」で区切って記述してください。なお，［JAVA_HOME］とは，環境変数PATHに設定した値のことです。［JAVA_HOME］は，Java実行環境によって異なります。

jdbc.drivers="JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDriver"

Javaのメソッドでの設定
System.setPropertyメソッドを使用してシステムプロパティに登録してください。次のように記述してください。

System.setProperty("jdbc.drivers", "JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDriver") ;

JDBCドライバの使用方法の詳細については，JavaSoft提供のJDBC関連ドキュメントを参照してください。

(2)　接続するデータベースの設定

Cosminexus DABroker Libraryで開発するアプリケーションは，DABrokerに接続してデータベースに接続します。DABrokerおよびデータベースは，次のどちらかの方法で設定してください。

Driver.connectメソッドの直接呼び出し

DriverManager.getConnectionメソッドの使用

同時に多数のユーザが接続するシステムの場合，ドライバマネージャを使用する接続方法では，ドライバマネージャ内で待ちが発生することがあります。多数のユーザが同時に接続することが想定されるシステムでは，Driver.connectメソッドの直接呼び出しの接続方法でアプリケーションを開発することをお勧めします。

Driver.connectメソッドの直接呼び出しによる接続方法
次のように，Driverクラスのconnectメソッドを直接呼び出すことができます。

Driver drv = new JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDriver();
Connection con = drv.connect(String url,Properties info);

DriverManager.getConnectionメソッドの使用による接続方法
DABrokerとの接続は，DriverManager.getConnectionメソッドを使用します。引数のパターンは，次のどちらかです。

DriverManager.getConnection(String url,String user,String password);
DriverManager.getConnection(String url,Properties info);

次の表に，DriverManager.getConnectionメソッド，およびDriver.connectメソッドの引数の内容を示します。

表I-16　 getConnectionメソッドおよびconnectメソッドの引数の内容

引数
設定内容
指定

String url
データベースに接続するための各種情報の設定用URL構文（「付録I.4(3)　データベースに接続するための各種情報の設定」参照）
必須

String user
データベース接続のユーザID※¹
必須

String password
データベース接続のパスワード※¹
任意

Properties info
データベース接続のユーザID※¹
（キーワード："user"）
必須

データベース接続のパスワード※¹
（キーワード："password"）
任意

アプリケーションの名称※²
（キーワード："UAPNAME"）
任意

DABrokerからの受信データのバッファ長※³
（キーワード："BUF_SIZE"）
任意

トレース取得の有無
（キーワード："JDBC_IF，SV_EVENT，TRC_NO"，
「付録I.4(4)　トレースを取得するための情報の設定」参照）
任意

エンコード文字形態※⁴
（キーワード："ENCODELANG"）
任意

JDBCで取り扱うバッファ長※⁵
（キーワード："ROW_SIZE"）
任意

OS認証機能使用の有無※6
（キーワード："DAB_OSAUTH"）
任意

警告の保持※7
（キーワード："SQLWARNING_IGNORE"）
任意

HiRDBのカーソルの保持※8
（キーワード："HIRDB_CURSOR"）
任意

複数のパラメタセットの処理方法※9
（キーワード："BLOCK_UPDATE"）
任意

Execute Direct機能使用の有無※10
（キーワード："EXECUTE_DIRECT_MODE"）
任意

LONGVARBINARY型データアクセスモード※11
（キーワード："LONGVARBINARY_ACCESS"）
任意

DABrokerからの受信データのバッファプール数※12
（キーワード："BUF_POOL_SIZE"）
任意

注※1

データベースに接続するためのユーザID，およびパスワードは，あらかじめデータベースに登録しておいてください。

なお，ユーザIDだけを指定し，パスワードの指定を省略した場合でも，データベースに接続できます。ただし，ユーザIDの指定を省略し，パスワードだけを指定した場合は，データベースに接続できません（データベースの仕様に従っています）。

注※2

開発するアプリケーションを一意に識別するための名称です。DABrokerで取得する，アプリケーションとの通信トレースのPAPNAMEに使用されます。指定を省略した場合は，「DABroker for Java Version 2」が使用されます。

アプリケーションの名称は，30バイト以内の文字列で指定してください。31バイト以上の文字列を指定した場合，31バイト以降は切り捨てられます。

注※3

DABrokerからの受信データを格納するためのバッファ長を，キロバイト単位の数字文字列で指定します。BLOBデータなどの長大データを使用する場合，想定されるデータ長以上の値をこの項目に指定します。

指定値

1～16000

指定を省略した場合，数字以外を指定した場合，または1より小さい値を指定した場合は64が仮定されます。16000より大きい値を指定した場合は16000が仮定されます。

値が仮定されたときは，Exceptionトレースログに値が仮定されたことを表すメッセージ（KFDJ01009-W）が出力されます。出力される契機はDriverManager.getConnectionメソッドなどでConnectionオブジェクトを取得するときです。メッセージについては，マニュアル「Cosminexus　メッセージ3　KFCT／KFDB／KFDJ編」を参照してください。

ただし，BUF_SIZEの上限が16,000キロバイトのため，BLOBデータなどの16,000キロバイトを超えるデータに一度にアクセスすることはできません。データベース種別がHiRDBの場合は，指定したバイト数を取り出すSTRING のインタフェース（BLOBデータの部分抽出機能）があるため，ここで指定したサイズ以下のサイズに分割して取り出してください。BLOBデータの部分抽出機能の詳細については，マニュアル「HiRDB　UAP開発ガイド」，およびマニュアル「HiRDB　SQLリファレンス」を参照してください。

注※4

Stringクラスで文字変換に使用するエンコード文字形態を指定します。

指定値

Javaがサポートしている文字エンコーディング：

MS932など，指定したエンコード文字形態を使用します。

OFF：

JavaVMがサポートしている標準エンコードを使用します。

次にDABrokerの漢字コードセットの値とJDBC内のエンコーディングの対応を示します。

DABroker（UNIX）のDAB_LANGの値，またはDABroker（Windows）のDABLANGMODEの漢字コードセットの値 | JDBC内の文字エンコーディング
SJIS（シフトJIS）モード | VMの標準エンコードを使用します。
EUCモード | EUCJIS
ASCIIモード | 8859_1
UTF-8モード | UTF-8

指定を省略した場合，OFFが仮定されます。

注※5

JDBCで取り扱うバッファ長を指定します。指定はメガバイト単位の数字文字列で指定します。利用するデータベースの1レコードの長さより大きい値を指定してください。

指定値

16～512

指定を省略した場合，数字以外を指定した場合，または16より小さい値を指定した場合は16が仮定されます。

512より大きい値を指定した場合は512が仮定されます。

注※6

OS認証機能を使用したデータベース接続をするかどうか指定します。

指定値

TRUE ：使用します。

FALSE：使用しません。

指定を省略した場合は，FALSEが仮定されます。この指定は，Oracle9i 9.2.0に接続する場合だけ有効です。それ以外のバージョンのOracleに対して指定した場合は動作を保証しません。接続するデータベースがOracle以外の場合は，指定値に関係なく，OS認証機能を使用しません。

注※7

データベースから返される警告を，Connectionクラスで保持するかどうかを指定します。

指定値

TRUE ：保持しません。

FALSE：保持します。

指定を省略した場合は，FALSEが仮定されます。

注※8

HiRDBでの検索時，カーソルが複数のCommitにわたって有効かどうかを指定します。

指定値

TRUE：カーソルは保持されます。アプリケーションは，続けてFetchできます（LOCK TABLE UNTIL DISCONNECTが前提です）。

FALSE：カーソルはクローズされます。

指定を省略した場合は，FALSEが仮定されます。Oracleでは，カーソルは常に複数のCommit，またはRollbackにわたって有効です。通常，Fetch時，DABrokerにFetchデータをバッファリングするため，Commit直後のFetchでエラーが発生するとは限りません。

MetaDataを取得する場合，「TRUE」を指定してLOCK TABLE UNTIL DISCONNECTをしないで，複数のCommitにわたってFetchを行うとエラーが発生します。MetaDataを取得する場合は，「TRUE」を設定しないでください。

MetaDataを取得する場合，「FALSE」，またはデフォルトの状態でResultSetのFetch実行中にCommitを実行するとエラーが発生します。

この機能については，マニュアル「HiRDB　SQLリファレンス」を参照してください。

注※9

接続データベースがHiRDBの場合，?パラメタを使用したデータベースの更新で，複数のパラメタセットを一度に処理するかどうかを指定します。

指定値

TRUE ：一度に処理します。

FALSE：パラメタセットを一つずつ分割して処理します。

指定を省略した場合は，FALSEが仮定されます。この指定は，接続データベースがHiRDBのときだけ有効です。HiRDB以外のデータベースの場合は，常にパラメタセットを一つずつ分割して処理します。また，実際にパラメタセットが一度に処理されるかどうかは，DABrokerおよびHiRDBの仕様に従います。

注※10

接続データベースがHiRDBの場合，INSERT，UPDATE，DELETEなど，Statementクラスを使用したデータベースの更新でHiRDBのEXECUTE DIRECT機能を使用するかどうかを指定します。

指定値

TRUE ：EXECUTE DIRECT機能を使用します。

FALSE：EXECUTE DIRECT機能を使用しません。

指定を省略した場合は，FALSEが仮定されます。この指定は，接続データベースがHiRDBのときだけ有効であり，HiRDB以外のデータベースの場合は，常にEXECUTE DIRECT機能を使用しません。

注※11

LONGVARBINARY（列属性BLOB，列属性BINARY）のデータベースのアクセス方法を指定します。

指定値

REAL：実データでアクセスします（デフォルト）。

LOCATOR：HiRDBの位置づけ子（locator）機能を使用してアクセスします。

上記以外：「REAL」を指定したものとします。なお，次のどれかの場合，「LOCATOR」を指定しても「REAL」が指定されたとみなします。

接続先DBがHiRDB 以外

接続先DBであるHiRDBのHiRDBサーバ，またはHiRDBクライアントライブラリのバージョンが07-00以前

LONGVARBINARY_ACCESSを指定した場合の注意事項を次に示します。

BUF_SIZEとLONGVARBINARY_ACCESSを指定した場合
BUF_SIZEおよびLONGVARBINARY_ACCESSの指定によって，BLOB／BINARYデータの取得方法が変化します。BLOB／BINARYデータの取得方法については，「付録I.4(3)(b)　URLに指定する各種情報」の「BLOB／BINARYデータの取得方法」を参照してください。

実行性能
LONGVARBINARY_ACCESSに「REAL」を指定すると，データベースへのアクセスは，ResultSet.nextまたはCallableStatement.execute実行時に1回行われるのに対し，「LOCATOR」を指定すると，ResultSet.nextまたはCallableStatement.execute実行時と，getBytesなどのデータを取得するメソッド実行時の2回行われます。そのため，「LOCATOR」を指定すると「REAL」を指定した場合に比べて性能が低下する場合があります。

AUTOコミット
LONGVARBINARY_ACCESSが「LOCATOR」でかつ，AUTOコミットが有効の場合，ストアドプロシジャのBLOB／BINARY型出力パラメタを受け取れません（getBytesなどでデータを取得できません）。ストアドプロシジャの出力パラメタを受け取るにはAUTOコミットを無効にしてください。

トランザクション終了後のデータ操作
LONGVARBINARY_ACCESSが「LOCATOR」の場合，SQLの実行結果取得（ResultSet.next，CallableStatement.execute）からデータ操作（Blob.getBytes，InputStream.readなど）までにトランザクションが終了すると，データ操作ができません。また，HIRDB_CURSORが「TRUE」であってもトランザクション終了後のデータ操作は実行できません。
そのため，データ操作はトランザクション終了前に行ってください。

注※12

DABrokerからの受信データを格納するためのバッファプール数を設定します。指定しない場合は，0（デフォルト）が仮定されます。受信バッファプール数指定機能については，「9.10.8(2)　受信バッファプール数の指定」を参照してください。

指定値

0（デフォルト）
受信バッファプール数指定機能を使用しません。受信バッファをすべてプールします。

1～1024
引数に指定された値を受信バッファプール数に設定します。ただし，接続するデータベースがHiRDBまたはORACLE以外の場合は，受信バッファプール数は1～64になります。この場合，64より大きい値を指定しても64個までしかプールできません。

上記以外
0より小さい値を指定した場合，または数字以外を指定した場合は0が仮定されます。1024より大きい値を設定した場合は1024が仮定されます。
値が仮定されたときは，Exceptionトレースログにメッセージ（KFDJ01011-W）が出力されます。このメッセージが出力される契機はDriverManager.getConnectionメソッドなどでConnectionオブジェクトを取得するときです。メッセージについては，マニュアル「Cosminexus　メッセージ3　KFCT／KFDB／KFDJ編」を参照してください。
ただし，SQLWarnningは作成されません。

(3)　データベースに接続するための各種情報の設定

ここでは，DABrokerおよびデータベースの各種情報の設定について説明します。

(a)　URLの指定形式

引数URLは，次の形式で指定します。

なお，任意に指定する項目については，［］（角括弧）で示しています。

jdbc:hitachi:dbplib://DB =データベース種別[,DBID = データベースの接続情報][,DBENV = 接続先データベース定義情報][,DBHOST = データベース(HiRDB)のホスト名][,BUF_SIZE = 受信バッファ長][,ENCODELANG = 変換文字指定]
[,HIRDB_CURSOR = HiRDBカーソル動作モード]

必須の指定を省略した場合は，エラー（SQLExceptionをthrowする）となります。

URLで指定する項目の中または項目の間でスペースを指定すると，指定値が無効となります。

(b)　URLに指定する各種情報

各種情報に指定する内容を，次に示します。

●URLでの指定項目

表I-17　URLでの指定項目

各種情報
指定内容

データベース種別
（DB=）
DABrokerから接続するデータベースの種別を指定します。
指定値：表I-18参照
指定は必須です。

データベースの
接続情報
（DBID=）
接続するデータベース情報を指定します。
指定値：表I-19参照

接続先データベース定義情報
（DBENV=）
DABrokerの接続先データベース定義情報を次の形式で指定します。
データベース種別名：データベース名
データベース種別がDABroker－Database Connection Serverの場合は，必ずこの項目を指定します。それ以外のデータベース種別の場合は，ここでの指定値は無視されます。

データベースのホスト名
（DBHOST=）
データベースの種別にHiRDBを指定する場合，HiRDBのホスト名を指定します。なお，HiRDB以外のデータベースを指定する場合，ここでの指定値は無視されます。
指定値：ホスト名
指定は任意です。

受信バッファ長
（BUF_SIZE=）
DABrokerからの受信データを格納するためのバッファ長を，キロバイト単位の数字文字列で指定します。BLOBデータなどの長大データを使用する場合，想定されるデータ長以上の値をこの項目に指定します。
指定値：1～16000
指定を省略した場合，数字以外を指定した場合，または1より小さい値を指定した場合は64が仮定されます。16000より大きい値を指定した場合は16000が仮定されます。
値が仮定されたときは，Exceptionトレースログに値が仮定されたことを表すメッセージ（KFDJ01009-W）が出力されます。出力される契機はDriverManager.getConnectionメソッドなどでConnectionオブジェクトを取得するときです。メッセージについては，マニュアル「Cosminexus　メッセージ3　KFCT／KFDB／KFDJ編」を参照してください。
ただし，BUF_SIZEの上限が16,000キロバイトのため，BLOBデータなどの16,000キロバイトを超えるデータに一度にアクセスすることはできません。データベース種別がHiRDBの場合は，指定したバイト数を取り出すSTRING のインタフェース（BLOBデータの部分抽出機能）があるため，ここで指定したサイズ以下のサイズに分割して取り出してください。BLOBデータの部分抽出機能の詳細については，マニュアル「HiRDB　UAP開発ガイド」，およびマニュアル「HiRDB　SQLリファレンス」を参照してください。

受信バッファプール数（BUF_POOL_SIZE）
DABrokerからの受信データを格納するためのバッファプール数を設定します。指定しない場合は，0（デフォルト）が仮定されます。受信バッファプール数指定機能については，「9.10.8(2)　受信バッファプール数の指定」を参照してください。
指定値：

0（デフォルト）

受信バッファプール数指定機能を使用しません。受信バッファをすべてプールします。

1～1024

引数に指定された値を受信バッファプール数に設定します。ただし，接続するデータベースがHiRDBまたはORACLE以外の場合は，受信バッファプール数は1～64になります。この場合，64より大きい値を指定しても64個までしかプールできません。

上記以外

0より小さい値を指定した場合，または数字以外を指定した場合は0が仮定されます。1024より大きい値を設定した場合は1024が仮定されます。

値が仮定されたときは，Exceptionトレースログにメッセージ（KFDJ01011-W）が出力されます。このメッセージが出力される契機はDriverManager.getConnectionメソッドなどでConnectionオブジェクトを取得するときです。メッセージについては，マニュアル「Cosminexus　メッセージ3　KFCT／KFDB／KFDJ編」を参照してください。
ただし，SQLWarnningは作成されません。

変換文字指定
（ENCODELANG=）
Stringクラスで文字変換に使用するエンコード文字形態を指定します。
指定値：Javaがサポートしている文字エンコーディング（MS932など），またはOFF（JavaVMがサポートしている標準エンコードを使用します）
指定は任意です。指定を省略した場合，OFFが仮定されます。

HiRDBカーソル動作モード
（HIRDB_CURSOR=）
HiRDBでの検索時，カーソルが複数のCommitにわたって有効かどうかを指定します。
指定値：

TRUE

カーソルは保持されます。アプリケーションは，続けてFetchできます（LOCK TABLE UNTIL DISCONNECTが前提です）。

FALSE

カーソルはクローズされます。

指定を省略した場合は，FALSEが仮定されます。Oracleでは，カーソルは常に複数のCommit，またはRollbackにわたって有効です。通常，Fetch時，DABrokerにFetchデータをバッファリングするため，Commit直後のFetchでエラーが発生するとは限りません。
MetaDataを取得する場合，「TRUE」を指定してLOCK TABLE UNTIL DISCONNECTをしないで，複数のCommitにわたってFetchを行うとエラーが発生します。MetaDataを取得する場合は，「TRUE」を設定しないでください。
MetaDataを取得する場合，「FALSE」またはデフォルトの状態で，ResultSetのFetch実行中にCommitを実行するとエラーが発生します。
接続データベースがHiRDBで検索SQL（SELECT文）に「UNTIL DISCONNECT」を記述した場合は，「TRUE」を指定するか，DataSourceクラスのsetHiRDBCursorModeメソッドで「true」を設定してください。設定しない場合，Commitをわたった検索中のResultSetクラスオブジェクトに対してcloseメソッドを実行してもカーソルをクローズしません。
この機能を使用する場合，マニュアル「HiRDB　SQLリファレンス」を参照してください。

●データベースの指定値

表I-18　データベース種別の指定値

データベース種別 | データベース種別の指定値
Oracle | oracleまたはORACLE
Oracle8i※ | oracle8iまたはORACLE8I
HiRDB | hirdbまたはHIRDB

注

指定値の文字列は，大文字，小文字のどちらでもかまいません。

「=」の前後に，空白またはタブ文字を指定した場合は，エラー（SQLExceptionをthrowする）となります。

注※

データベース種別にOracle8iの指定値を指定して，DABroker環境設定の「使用するOracleのバージョン」にOracle9iを指定した場合はOracle9iに，Oracle10gを指定した場合はOracle10gに接続できます。

表I-19　データベースの接続情報の指定値

データベース種別 | データベースの接続情報の指定内容 | 指定の省略可否
Oracle | SQL*Netの接続文字列※¹ | 任意※¹
Oracle8i
HiRDB | HiRDBのシステムポート番号※¹※² | 任意※¹

注

「=」の前後に，空白またはタブ文字を指定した場合は，エラー（SQLExceptionをthrowする）となります。

「DB=データベース種別」との区切りに「,（コンマ）」を使用します。

「,（コンマ）」を2回以上指定した場合は，最後の「,（コンマ）」以降がデータベースの接続情報の指定となります。

データの区切りに「,（コンマ）」以外のキーを使用した場合は，データベース接続情報の指定は無効となります。

注※1

指定を省略する場合は，DABrokerの動作環境定義ファイルでの指定が有効になります。

注※2

HiRDBクライアントの環境変数グループ名を指定する場合は，グループ名の先頭に@を付加します。

（例1）

Windowsの場合

HiRDBクライアントの環境変数グループ名がHiRDB_ENV_GROUPのときは，次のように指定します。

DBID=@DABENVGRP=HiRDB_ENV_GROUP

（例2）

UNIXの場合

HiRDBクライアントの環境変数グループ名のパスが/HiRDB_P/Client/HiRDB.iniのときは，次のように指定します。

DBID=@DABENVGRP=/HiRDB_P/Client/HiRDB.ini

DBID=@DABENVGRP=＜環境変数グループ名＞を指定する場合は，指定内容に半角の空白を含めないでください。指定内容が次に示す例のどれかに該当する場合，DBIDは正しく設定されません。

（例）

DBID=@DABENVGRP=＜環境変数グループ名＞の指定内容に半角スペースを含みます。OSはWindowsで，環境変数グループ名はHiRDB_ENV_GROUPとします。

半角の空白を△で示します。

DBID△=@DABENVGRP=HiRDB_ENV_GROUP

DBID=△@DABENVGRP=HiRDB_ENV_GROUP

DBID=@△DABENVGRP=HiRDB_ENV_GROUP

DBID=@DABENVGRP△=HiRDB_ENV_GROUP

DBID=@DABENVGRP=△HiRDB_ENV_GROUP

DBID=@DABENVGRP=HiRDB_ENV_GROUP△

●BLOB／BINARYデータの取得方法

LONGVARBINARY_ACCESSを指定した場合の各メソッド実行時の動作を次に示します。

接続先データベースにHiRDBを指定した場合

表I-20　BLOB／BINARYデータの取得方法（1）

指定値
CallableStatement.execute
および
ResultSet.next
CallableStatement.getBytes
および
ResultSet.getBytes
Blob.getBytes

REAL
BLOB／BINARYデータの全体を接続先データベースから取得します。
ResultSet.nextで取得したBLOB／BINARYデータを使用します。
ResultSet.nextで取得したBLOB／BINARYデータから，引数で指定された範囲を切り出して取得します。

LOCATOR
BLOB／BINARYデータの全体ではなく，接続先データベース内のBLOB／BINARYデータを示すロケータを取得します。
BLOB／BINARYデータの全体を接続先データベースからBUF_SIZE×1,024バイト単位に分割して取得します。
引数で指定された範囲のBLOB／BINARYデータを接続先データベースからBUF_SIZE×1,024バイト単位に分割して取得します。

表I-21　BLOB／BINARYデータの取得方法（2）

指定値
CallableStatement.getBinaryStream
および
ResultSet.getBinaryStreamBlob.getBinaryStream
Blob.length
Blob.position

REAL
getBinaryStreamによって取得したInputStreamのreadメソッドを実行した場合，ResultSet.nextで取得したBLOB／BINARYデータから抽出して取得します。
ResultSet.nextメソッドで取得したBLOB／BINARYデータから，データ長を取得します。
ResultSet.nextで取得したBLOB／BINARYデータから，検索パターンに一致する位置を取得します。

LOCATOR
getBinaryStreamによって取得したInputStreamのreadメソッドを実行した場合，接続先データベースからデータを取得します。
接続先データベースからデータ長を取得します。
接続先データベースから，検索パターンに一致する位置を取得します。

表I-22　BLOB／BINARYデータの取得方法（3）

指定値 | InputStream.available※ | InputStream.skip※
REAL | ロケータの示す実データの長さ以下の値を返します。 | ロケータの示す実データの長さ以下の値を返します。
LOCATOR | BUF_SIZE×1,024バイト以下の値を返します。 | BUF_SIZE×1,024バイト以下の値を返します。

注※

CallableStatement.getBinaryStream，ResultSet.getBinaryStream，またはBlob.getBinaryStreamで取得したInputStreamです。

接続先データベースにOracleを指定した場合

表I-23　BLOB／BINARYデータの取得方法（4）

指定値
CallableStatement.execute
および
ResultSet.next
CallableStatement.getBytes
および
ResultSet.getBytes
Blob.getBytes

REAL
BLOB／BINARYデータの全体を接続先データベースからBUF_SIZE ×1,024バイト単位に分割して取得します。
ResultSet.nextで取得したBLOB／BINARYデータを使用します。
ResultSet.nextで取得したBLOB／BINARYデータから，引数で指定された範囲を切り出して取得します。

LOCATOR

表I-24　BLOB／BINARYデータの取得方法（5）

指定値
CallableStatement.getBinaryStream
および
ResultSet.getBinaryStreamBlob.getBinaryStream
Blob.length
Blob.position

REAL
ResultSet.nextで取得したBLOB／BINARYデータを使用します。
ResultSet.nextで取得したBLOB／BINARYデータから，データ長を取得します。
ResultSet.nextで取得したBLOB／BINARYデータから，検索パターンに一致する位置を取得します。

LOCATOR

表I-25　BLOB／BINARYデータの取得方法（6）

指定値 | InputStream.available※ | InputStream.skip※
REAL | ロケータの示す実データの長さ以下の値を返します。 | ロケータの示す実データの長さ以下の値を返します。
LOCATOR

注※

CallableStatement.getBinaryStream，ResultSet.getBinaryStream，またはBlob.getBinaryStreamで取得したInputStreamです。

(4)　トレースを取得するための情報の設定

JDBCドライバでは，次のトレースを取得できます。トレースの出力内容については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

JDBCインタフェースメソッドトレース

DABrokerとのイベントトレース

(a)　トレースの取得および出力ストリームの設定方法

次の項目を指定して，トレースの取得を設定してください。次の項目が指定されていない場合は，トレースを取得できません。

DriverManager.getConnectionメソッドまたはDriver.connectメソッドの引数Properties infoでのトレース取得有無の指定

DriverManager.setLogWriterメソッドでの，トレースの出力ストリームの指定

1.のProperties infoで指定する値を次の表に示します。1.のメソッドと引数については，「付録I.4(3)　データベースに接続するための各種情報の設定」を参照してください。

表I-26　 トレースを取得するための指定値

トレースの種類
およびトレース関連項目
Properties infoの
キーワード
Properties infoの値

JDBCインタフェースメソッド
トレース※¹
JDBC_IF
指定値
ON：トレースを取得する
OFF：トレースを取得しない

DABrokerとのイベント
トレース※¹
SV_EVENT
指定値
ON：トレースを取得する
OFF：トレースを取得しない

各トレースのエントリ数※²
TRC_NO
デフォルト値
500（エントリ）
指定範囲
10～1000（エントリ）

注※1

ONまたはOFF以外の値を指定した場合は「トレースを取得しない」設定となります。

注※2

数字以外の値を指定した場合は「トレースを取得しない」設定となります。

(b)　指定したストリームへの出力タイミング

トレースは，各トレースのエントリ数分，JDBCドライバで保持されます。

保持されたトレースは，次のタイミングでDriverManager.setLogWriterメソッドで指定した出力ストリームに出力されます。

Connection.Closeメソッドの呼び出し（正常終了時）

エラー発生時（SQLExceptionのthrow時）

(c)　JDBCドライバでのトレース取得時の注意事項

JDBCドライバは，JDBCドライバ内でトレース情報の数がエントリ数を超えた場合は，トレースの古い順にトレース情報を上書きします。

JDBCインタフェースメソッドトレース（キーワード：JDBC_IF）は，EntryおよびReturnでそれぞれ1エントリのトレース領域を使用します。

DABrokerとのイベントトレース（キーワード：SV_EVENT）は，送信または受信イベントでそれぞれ1エントリのトレース領域を使用します。

付録I.5　JDBC2.0拡張機能を使用したデータベース接続の設定

JDBC2.0拡張機能で提供するJNDI連携機能を使用した，データベースへ接続する操作について説明します。なお，DataSourceクラスのインタフェース定義およびJNDIを，JDKでは標準で提供していません。JNDI連携機能を使用するときは，JavaSoftのホームページから入手しておいてください。この機能はCosminexusのJ2EEサーバモード，DB Connectorを使用する場合は，アプリケーションで設定する必要はありません。

＜この項の構成＞

(1)　DataSourceオブジェクトの生成

(2)　データベースに接続するための各種情報の設定

(3)　JNDIへの情報の登録

(4)　JNDIからの情報の取得

(5)　データベースへの接続

(6)　JDBC2.0拡張機能で提供する機能のトレースを取得するための情報の指定

(1)　DataSourceオブジェクトの生成

接続情報の設定は，DataSourceオブジェクトで実行します。

DataSourceオブジェクトの生成で必要な，ドライバ拡張機能のパッケージ名称およびDataSourceクラス名称を次に示します。

指定項目 | 指定値
パッケージ名称 | JP.co.Hitachi.soft.DBPSV_Driver
DataSourceクラス名称 | JdbcDbpsvDataSource

DataSourceオブジェクトの生成例を次に示します。

JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource  ds = null ;
ds = new JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource() ;

(2)　データベースに接続するための各種情報の設定

データベースに接続するための各種情報は，JDBC2.0拡張機能で提供するメソッドで設定します。提供するメソッドを次の表に示します。

表I-27　 各種情報を設定するメソッド

メソッド | 機能
setNetworkProtocol | DABrokerとの接続種別を設定します。
setServerName | 接続するDABrokerのホスト名を設定します。
setPortNumber | 接続するDABrokerのポート番号を設定します。
setDatabaseName | 接続するデータベースの種別を設定します。
setDescription | 接続するデータベースに必要な接続付加情報を設定します。
setDBHostName | 接続するHiRDBのホスト名を設定します。
setDBEnv | DABrokerの接続先データベース定義情報を設定します。
setEncodLang | エンコード文字形態を設定します。
setJDBC_IF_TRC | JDBCインタフェースメソッドトレースの取得の有無を設定します。
setSV_EVENT_TRC | DABrokerとのイベントトレースの取得の有無を設定します。
setTRC_NO | トレースのエントリ数を設定します。
setUapName | アプリケーション名称を設定します。
setBufSize | DABrokerからの受信データのバッファ長を設定します。
setUser | データベース接続のユーザIDを設定します。
setPassword | データベース接続のパスワードを設定します。
setXAOpenString※ | XA_OPEN文字列を設定します。
setXACloseString※ | XA_CLOSE文字列を設定します。
setRMID※ | リソースマネージャの識別子を設定します。
setXAThreadMode※ | XA使用時のスレッドモードを設定します。
setXALocalCommitMode※ | XA使用時，データベースのオートコミットを有効にするかどうかを設定します。
setRowSize | JDBCで取り扱うバッファ長を指定します。
setOSAuthorize | OS認証機能を使用してデータベースに接続するかどうかを設定します。
setSQLWarningIgnore | データベースから返される警告をConnectionクラスで保持するかどうかの情報を設定します。
setHiRDBCursorMode | 接続データベースがHiRDBの場合，検索時にカーソルが複数のCommitにわたって有効かどうかを設定します。
setNotErrorOccurred | connectionErrorOccurredが呼ばれるかどうかを設定します。
setBlockUpdate | 接続データベースがHiRDBの場合，?パラメタを使用したデータベースの更新で，複数のパラメタセットを一度に処理するかどうかを設定します。
setExecuteDirectMode | 接続データベースがHiRDBの場合，Statementクラスを使用したデータベースの更新でHiRDBのExecute Direct機能を使用するかどうかを設定します。
setLONGVARBINARY_Access | HiRDBでLONVARBINARY（列属性BLOB，列属性BINARY）へのアクセス方法を設定します。
setBufferPoolSize | DABrokerからの受信データのバッファプール数を設定します。

注※

JdbcDbpsvXADataSourceクラスでだけ提供するメソッドです。

JDBC2.0拡張機能では，接続情報を取得するためのメソッドも提供しています。接続情報を取得するためのメソッドを次の表に示します。

表I-28　 各種情報を取得するメソッド

メソッド | 機能
getNetworkProtocol | DABrokerとの接続種別を取得します。
getServerName | 接続するDABrokerのホスト名を取得します。
getPortNumber | 接続するDABrokerのポート番号を取得します。
getDatabaseName | 接続するデータベースの種別を取得します。
getDescription | 接続するデータベースに必要な接続付加情報を取得します。
getDBHostName | 接続するHiRDBのホスト名を取得します。
getDBEnv | DABrokerの接続先データベース定義情報を取得します。
getEncodLang | エンコード文字形態を取得します。
getJDBC_IF_TRC | JDBCインタフェースメソッドトレースの取得の有無を取得します。
getSV_EVENT_TRC | DABrokerとのイベントトレースの取得の有無を取得します。
getTRC_NO | トレースのエントリ数を取得します。
getUapName | アプリケーション名称を取得します。
getBufSize | DABrokerからの受信データのバッファ長を取得します。
getUser | データベース接続のユーザIDを取得します。
getPassword | データベース接続のパスワードを取得します。
getXAOpenString※ | XA_OPEN文字列を取得します。
getXACloseString※ | XA_CLOSE文字列を取得します。
getRMID※ | リソースマネージャの識別子を取得します。
getXAThreadMode※ | XA使用時のスレッドモードを取得します。
getXALocalCommitMode※ | XA使用時，データベースのオートコミットを有効にしているかどうかの設定を取得します。
getRowSize | JDBCで取り扱うバッファ長を取得します。
getOSAuthorize | OS認証機能を使用してデータベースに接続するかどうかの設定を取得します。
getSQLWarningIgnore | データベースから返される警告をConnectionクラスで保持するかどうかの情報を取得します。
getHiRDBCursorMode | 接続データベースがHiRDBの場合，検索時にカーソルが複数のCommit，またはRollbackにわたって有効かどうかの設定を取得します。
getNotErrorOccurred | connectionErrorOccurredが呼ばれるかどうかの設定を取得します。
getBlockUpdate | 接続データベースがHiRDBの場合，?パラメタを使用したデータベースの更新で，複数のパラメタセットを一度に処理するかどうかの設定を取得します。
getExecuteDirectMode | 接続データベースがHiRDBの場合，Statementクラスを使用したデータベースの更新でHiRDBのExecute Direct機能を使用するかどうかの設定を取得します。
getLONGVARBINARY_Access | HiRDBでLONVARBINARY（列属性BLOB，列属性BINARY）へのアクセス方法を取得します。
getBufferPoolSize | DABrokerからの受信データのバッファプール数を取得します。

注※

JdbcDbpsvXADataSourceクラスでだけ提供するメソッドです。

各メソッドの機能および文法については，マニュアル「Cosminexus　リファレンス　API編」を参照してください。

(3)　JNDIへの情報の登録

接続情報を設定したDataSourceオブジェクトを，JNDIに登録します。JNDIは実行環境によって，幾つかのサービスプロバイダを選択できます。

File Systemサービスプロバイダを使用するJNDIへの登録例を次に示します。ほかのサービスプロバイダへの登録については，JNDIのドキュメントを参照してください。なお，JNDIに登録するときの論理名称は，"jdbc"というサブコンテキスト（登録例ではjdbc/TestDataSource）の下に登録するようにしてください。

// JDBC2.0拡張機能が提供するDataSourceオブジェクトを生成する
JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource  ds;
ds = new JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource();

// 接続情報を設定する
  ：
// システムプロパティを取得する
Properties sys_prop = System.getProperties();

// File Systemサービスプロバイダのプロパティを設定する
sys_prop.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.fscontext.RefFSContextFactory");

// File Systemサービスプロバイダで使用するディレクトリを設定する
// (この場合，c:¥JNDI_DIRの下に登録される)
sys_prop.put(Context.PROVIDER_URL, "file:c:"+File.separator + "JNDI_DIR");

//システムプロパティを更新する
System.setProperties(sys_prop);

// JNDIを初期化する
Context ctx = new InitialContext();

// JDBC2.0拡張機能が提供するDataSourceオブジェクトを，
// jdbc/TestDataSourceという論理名称でJNDIに登録する
ctx.bind("jdbc" + File.separator + "TestDataSource", ds);
  ：

(4)　JNDIからの情報の取得

データベースに接続するときに，JNDIに登録したDataSourceオブジェクトを取得します。

File Systemサービスプロバイダを使用するJNDIから，DataSourceオブジェクトを取得する例を次に示します。ほかのサービスプロバイダから取得する方法については，JNDIのドキュメントを参照してください。

// システムプロパティを取得する
Properties sys_prop = System.getProperties();

// File Systemサービスプロバイダのプロパティを設定する
sys_prop.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.fscontext.RefFSContextFactory");

// File Systemサービスプロバイダで使用するディレクトリを設定する
// (この場合，c:¥JNDI_DIRの下に登録されている)
sys_prop.put(Context.PROVIDER_URL, "file:c:"+File.separator + "JNDI_DIR");

// システムプロパティを更新する
System.setProperties(sys_prop);

// JNDIを初期化する
Context ctx = new InitialContext();

//jdbc/TestDataSourceという論理名称のオブジェクトをJNDIから取得する
Object obj = ctx.lookup("jdbc" + File.separator + "TestDataSource");

// 取り出したオブジェクトを，DataSourceクラスの型にキャストする
DataSource ds = (DataSource)obj;
  ：

(5)　データベースへの接続

JNDIに登録したDataSourceオブジェクトを取得後，DataSourceオブジェクトに対し，getConnectionメソッドを呼び出して，データベースへ接続します。

getConnectionメソッドの呼び出し例を次に示します。

DataSource ds

// JNDIからDataSourceオブジェクトを取得する
  ：
// getConnectionメソッドを呼び出す
Connection con = ds.getConnection("USERID","PASSWORD")※

注※

getConnectionメソッドの引数（ユーザID，パスワード）は省略できます。引数を指定した場合は，DataSourceオブジェクトに設定した接続情報よりも優先されます。

必要な接続情報がDataSourceオブジェクトに設定されていない場合，接続情報の内容が不正な場合，データベースとの接続に失敗した場合は，getConnectionメソッドはSQLExceptionをthrowします。

JNDIからDataSourceオブジェクトを取得したあと，接続情報を設定し直すことができます。設定し直す場合は，DataSourceオブジェクトをJDBC2.0拡張機能が提供するDataSourceクラスの型にキャストします。キャストする例を次に示します。

DataSource ds
JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource  dbp_ds;

// JNDIからDataSourceオブジェクトを取得する
  ：
// DataSourceオブジェクトを，JDBC拡張機能が提供する
// DataSourceクラスの型にキャストする
dbp_ds = (JP.co.Hitachi.soft.DBPSV_Driver.JdbcDbpsvDataSource)ds;

// 接続情報を再設定する
  ：

(6)　JDBC2.0拡張機能で提供する機能のトレースを取得するための情報の指定

JDBC2.0拡張機能では，次のトレースを取得できます。トレースの出力内容については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

JDBCインタフェースメソッドトレース

DABrokerとのイベントトレース

(a)　トレースの取得

トレースを取得する場合は，次の項目を設定してください。次の項目が設定されていない場合は，トレースを取得できません。

JdbcDbpsvDataSource，JdbcDbpsvConnectionPoolDataSourceまたはJdbcDbpsvXADataSourceクラスのsetLogWriterメソッドでの有効なログストリームの指定

setJDBC_IF_TRC，setSV_EVENT_TRCおよびsetTRC_NOメソッドで，トレース取得の指定

(b)　トレース取得時の注意事項

setLogWriterメソッドで指定したログストリームは，JNDIには登録されません。トレースの取得は，JNDIからDataSourceオブジェクトを取得するたびに，setLogWriterメソッドで指定してください。

付録I.6　エラー時のJDBCドライバの処理

データベース接続，DABroker，またはJDBCドライバでエラーが発生した場合は，SQLExceptionをthrowします。SQLExceptionオブジェクトのreasonには，次の項目が設定されます。

JDBCドライバのメッセージ

エラーを検知したクラス名称.メソッド名称

DABrokerからのメッセージ※

注※

DABrokerからのメッセージは，存在する場合だけ設定されます。

なお，次のようなエラーの場合は，SQLExceptionをthrowしないで，JDBCインタフェースの仕様で決まっている処理を続行します。

Driver.connectionメソッドでデータベースに接続できない場合

URL指定でnullが返される場合（Cosminexus DABroker Libraryで対象としていないURLが指定された場合など）

付録I.7　データ型の対応

ここでは，JDBCドライバのデータ型について説明します。

JDBCドライバでは，JDBCのデータ型とDABrokerでサポートするデータベースのデータ型をマッピングして処理を実行しています。JDBCのデータ型とDABrokerでサポートするデータ型は完全に一致していません。

なお，Cosminexus DABroker Libraryでサポートする文字型データのコード体系は，ASCII，シフトJIS，EUCJIS，UTF-8，およびChinese Simpleです。

＜この項の構成＞

(1)　JDBCのデータ型とDABrokerでサポートするデータ型の対応

(2)　データ型の注意事項

(1)　JDBCのデータ型とDABrokerでサポートするデータ型の対応

次に，JDBCのデータ型とDABrokerでサポートするデータ型の対応をデータベースごとに示します。

(a)　HiRDBの場合

表I-29　 HiRDBの場合のデータ型の対応

DABrokerでサポートするデータ型 | JDBCのデータ型
INTEGER | INTEGER
SMALLINT | SMALLINT
DECIMAL | DECIMAL
FLOAT, DOUBLE PRECISION | FLOAT
SMALLFLT, REAL | REAL
CHAR | CHAR
VARCHAR | VARCHAR
NCHAR | CHAR
NVARCHAR | VARCHAR
MCHAR | CHAR
MVARCHAR | VARCHAR
DATE | DATE
TIME | TIME
TIMESTAMP | TIMESTAMP
BLOB，BINARY LARGE OBJECT | LONGVARBINARY

(b)　Oracleの場合

表I-30　 Oracleの場合のデータ型の対応

DABrokerでサポートするデータ型 | JDBCのデータ型
VARCHAR2 | VARCHAR
NUMBER | NUMERIC，DECIMAL，BIT，TINYINT，SMALLINT，INTEGER，BIGINT
FLOAT | FLOAT
LONG | LONGVARCHAR
ROWID | CHAR
DATE | DATE，TIME，TIMESTAMP
RAW | VARBINARY
LONG RAW | LONGVARBINARY
CHAR | CHAR
NCHAR※ | CHAR
NVARCHAR2※ | VARCHAR
CLOB※ | CLOB
NCLOB※ | CLOB
BLOB※ | BLOB
BFILE※ | BLOB

注※

接続データベースがOracle9i，またはOracle10gの場合だけ使用できます。

(2)　データ型の注意事項

ここでは，データ型についての注意事項を示します。

データ型のマッピングは，次のメソッドでデータベースに接続する場合は，データ型の変換をJDBCドライバで実行します。次に示すメソッド実行時のデータ型の扱いについては，JDBCの仕様に依存します。

ResultSetクラスのgetXXXメソッド

PreparedStatementクラスのsetXXXメソッド

CallableStatementクラスのsetXXXメソッド

なお，setXXXメソッド実行時は，JDBCドライバでデータを保持し，execute実行時にデータをDABrokerに転送して，通信回数を削減しています。したがって，setXXXで発生するようなエラーがexecuteの実行時に発生する場合もあります。

DABrokerがサポートしていないデータ型に対して接続を要求した場合（Statement.execute発行時など）は，DABrokerからエラーが返ります。その後，Cosminexus DABroker Libraryは，SQLExceptionをthrowします。

付録J　用語解説

Application Server，uCosminexus Client，Web Redirector，およびuCosminexus Operatorで使用する用語について説明します。

（数字）

1.4モード

サーバの動作モードです。J2EE 1.4の機能を使用できます。データベースを含む複数のリソースのトランザクション管理ができます。

1:1系切り替えシステム

実行系のアプリケーションサーバと待機系のアプリケーションサーバが1:1で対応しているシステムです。実行系のアプリケーションサーバに障害が発生すると，待機系のアプリケーションサーバで処理を引き継ぎます。

（英字）

Application Server

Cosminexusの実行環境を構築する基盤製品です。Application Server Standardと，Application Server Enterpriseの総称です。

BJEX

uCosminexus Batch Job Execution Serverのことです。

BMP（Bean-Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化を管理するモデルです。

BMT（Bean-Managed Transaction）

Enterprise Beanでトランザクションを管理するモデルです。Session BeanおよびMessage-driven Beanが対象になります。Entity Beanは対象外です。

CMP（Container-Managed Persistence）

EJBコンテナがデータの永続化を管理するモデルです。

CMT（Container-Managed Transaction）

EJBコンテナがトランザクションを管理するモデルです。Session Bean，Entity BeanおよびMessage-driven Beanが対象になります。

Component Container管理者

スーパーユーザ以外の，J2EEサーバやバッチサーバのセットアップ，J2EEサーバやバッチサーバの起動・停止などを実施できるユーザを指します。Component Container管理者はUNIXの場合に設定できます。

Cookieスイッチング機能

負荷分散機で提供しているサーバスイッチング機能の一つです。Cookieスイッチング機能を使用すると，クライアントからのリクエストパケット内のCookie情報に基づいて，同じサーバにセッションをリダイレクトします。

CORBAネーミングサービス

CORBAの仕様に準拠した，リモートオブジェクトの格納場所を管理するためのネーミングサービスです。Application Serverの構成ソフトウェアであるCosminexus TPBrokerによって提供される機能です。

Cosminexus

アプリケーションサーバを中核とした，性能および信頼性の高いアプリケーションを実行および開発するためのシステム構築基盤製品です。

Cosminexus Component Container

サーバ・サイドの業務処理プログラム（ビジネスロジック）をコンポーネントとして実行するための構成ソフトウェアです。また，Cosminexusシステムの運用管理をするためのManagement Server，統合ユーザ管理，snapshotログ収集などの機能も提供しています。

Cosminexus Component Transaction Monitor

クライアントからのリクエストのスケジューリングを実現するための構成ソフトウェアです。

Cosminexus Operator Plug-in

実行環境を運用管理操作するための構成ソフトウェアです。Server Plug-inとHCSC-Managerを提供しています。HCSC-Managerとは，Cosminexusサービスプラットフォームの運用環境で利用する運用管理機能です。なお，HCSC-Managerについては，マニュアル「Cosminexus　サービスプラットフォーム　システム構築・運用ガイド」を参照してください。

Cosminexus Performance Tracer

リクエストが処理されるときに，決められたポイントごとに各機能が出力する性能解析情報をファイルに出力するための構成ソフトウェアです。

Cosminexus Reliable Messaging

Cosminexus システム上のJ2EEアプリケーションがメッセージを使用して非同期に通信するためのミドルウェアです。JMSインタフェースでのメッセージ通信機能をJ2EEアプリケーションに提供します。

Cosminexusシステム

Application Serverを実行基盤として構築されているシステムのことです。

Cosminexus標準ログインモジュール

統合ユーザ管理のユーザ認証処理で使用するログインモジュールです。javax.security.auth.spiに含まれるLoginModuleインタフェースの実装クラスです。

次のログインモジュールがあります。

WebPasswordLoginModule
パスワードを使用してユーザを認証します。

WebCertificateLoginModule
クライアント証明書を使用してユーザを認証します。

WebPasswordLDAPLoginModule
LDAPディレクトリサーバの認証機能を使用してユーザを認証します。

WebPasswordJDBCLoginModule
RDBに格納された情報を使用してユーザを認証します。

DelegationLoginModule
カスタムログインモジュールを呼び出します。

WebSSOLoginModule
シングルサインオンをするときに，ほかのログインモジュールを呼び出します。

CTM

Cosminexus Component Transaction Monitorのことです。リクエストのスケジューリングをするための構成ソフトウェアです。

CTMデーモン

クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。リクエストのスケジューリングを実現する，スケジューラとして機能します。

Management Serverを利用している場合，CTMデーモンは論理サーバとして扱えます。

CTMドメイン

複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。CTMデーモンはCTMドメイン内で，それぞれに登録された業務処理プログラムの情報やスケジュールキューの負荷情報を交換してリクエストを振り分けます。

CTMドメインマネジャ

CTMドメインを管理するプロセスです。ホスト内のCTMデーモンの情報を，CTMドメイン内のほかのCTMドメインマネジャに配布します。

Management Serverを利用している場合，CTMドメインマネジャは論理サーバとして扱えます。

CTMレギュレータ

EJBクライアントからCTMデーモンに集中するリクエストを，分散集約するためのプロセスです。TPBrokerクライアント（CORBAクライアント）からJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能も提供します。

DB Connector

データベースに接続するためのリソースアダプタです。

DD

アプリケーションを運用環境に配置するときの定義情報を記述したものです。EJB用，Webアプリケーション用，Enterpriseアプリケーション用などがSun Microsystems, Inc.からの仕様で規定されています。

Dependency Injection

EJBやインターセプタクラスのフィールドやsetterメソッドに，@EJBや@Resourceアノテーションを指定することで，EJBやリソースへの参照をEJBコンテナが自動的にセットする機能です。Dependency Injectionを使用すると，EJBやリソースへの参照をJNDIを使用してルックアップする必要がなくなります。

DIターゲット

Dependency Injection機能を使用して参照を注入する対象のことです。DIターゲット名と名前が一致するフィールド，またはDIターゲット名をプロパティとして持つsetterメソッドに対して，Dependency Injectionが実行されます。

DTD

XMLで使用するタグの属性や階層構造や出現順序などを定義したものです。

EARファイル

J2EEアプリケーションを構成する複数のEJB-JARファイル，WARファイル，およびDDをEARファイル形式でパッケージ化したものです。

EIS

データベースやトランザクションサーバなど，企業内に構築されているバックエンドシステムです。

EJB（Enterprise JavaBeans）

業務ロジックをプログラムとして記述したビジネスロジック，および永続的データを格納するオブジェクトであるエンティティをJavaコンポーネント化したものです。Sun Microsystems, Inc.からEJB仕様が公開されています。

EJB-JARファイル

Enterprise Bean，DDなどをJARファイル形式に圧縮したものです。

EJBクライアント

J2EEサーバ上で開始されているEnterprise Beanを呼び出すクライアントプログラムです。次の3種類があります。

EJBクライアントアプリケーション

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーション

Enterprise Beanを呼び出すJavaアプリケーションです。

EJBコンテナ

Enterprise Beanを制御すると同時に，通信，トランザクション管理などのシステムレベルのサービスを提供する実行環境です。Enterprise Beanの実体は，EJBコンテナの中で実行されます。

EJBタイマ

EJBコンテナのTimer Serviceの機能を利用して，タイムアウト時間を管理するタイマです。指定された時刻または間隔で，タイムアウトメソッドをコールバックし，イベントを実行します。

Enterprise Bean

ビジネスロジックをEJBアーキテクチャに従って作成したものです。業務処理プログラムに該当します。

Entity Bean

永続化されたデータそのものを表すBeanです。Entity Beanは，さらにCMP Entity BeanとBMP Entity Beanに分類されます。

HAモニタ

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。HAモニタと連携することで，Cosminexusシステムの信頼性や稼働率を向上できます。AIX，HP-UXまたはLinuxを使用しているときに連携できます。

HAモニタと連携することで，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステムが実現できます。

Inbound

Connector 1.5仕様で定められたJ2EEサーバとリソースアダプタ間の通信モデルの一つです。リソースアダプタからJ2EEサーバにアクセスする通信モデルです。

J2EE

JavaTM 2 Platform, Enterprise Editionの略です。Sun Microsystems, Inc.からJ2EE仕様が公開されています。

J2EEアプリケーション

JSP，サーブレット，EnterpriseBeanなどで構成されるアプリケーションです。Cosminexusで扱うJ2EEアプリケーションの形式には，EARファイル形式でパッケージ化されたアーカイブ形式のアプリケーションと，アーカイブ化しない展開ディレクトリ形式のアプリケーションがあります。EARファイル形式でパッケージ化されたアプリケーションの場合，複数のEJB-JARファイル，複数のWARファイル，および一つのDDから構成されます。

J2EEアプリケーション実行時間の監視機能

EJBおよびWebアプリケーションのリクエスト実行時間を監視する機能です。実行時間監視中に障害を検知すると，メソッドタイムアウト機能およびメソッドキャンセル機能が動作します。

J2EEアプリケーションの強制停止

J2EEアプリケーションの停止での強制停止とは，J2EEアプリケーションで処理中のリクエストがある場合でも，強制的に処理を中止する方法です。

J2EEアプリケーションの通常停止

J2EEアプリケーションの停止での通常停止とは，WebアプリケーションやEJBの停止処理を順番に実施して，J2EEアプリケーションを安全に停止させる方法です。

J2EEコンテナ

J2EEアプリケーションを実行するためのサーバ基盤です。

J2EEコンポーネントへ各種APIを提供する，Webコンテナ，EJBコンテナから構成されます。

J2EEコンポーネント

サーブレット，JSP，Enterprise Beanなどのユーザアプリケーションプログラムのことです。

J2EEサーバ

J2EEコンテナを生成，実行する環境です。

J2EEサーバモード

J2EEサーバの動作モードの一つです。このモードの場合，J2EEコンテナ上で動作するアプリケーションから，J2EE関連のAPIを利用できます。なお，J2EEサーバモードには，1.4モードと，互換用の動作モードであるベーシックモードがあります。

J2EEサービス

J2EEコンテナの部品機能として利用されます。J2EEコンポーネントにJNDI，JDBC，JTA，RMI-IIOPおよびJavaMailのAPIを提供します。

J2EEリソース

サーバから利用できるリソースです。J2EEサーバの場合，データベース，OpenTP1，SMTPサーバなどを利用できます。また，バッチサーバの場合，データベースを利用できます。

J2EEリソースアダプタ

J2EEサーバに共有スタンドアロンモジュールとして配備したリソースアダプタのことです。

jaas.conf（JAASのコンフィグレーションファイル）

ユーザ認証ライブラリおよびシングルサインオンライブラリの機能を使用するために必要なJAAS認証用の設定ファイルです。

Java

1991年にSun Microsystems, Inc.内の研究グループが開発したインタプリタ言語を基に，C++をより移植性と信頼性が高くなるように改良した言語です。Webの普及によってブラウザに応用されています。

JavaロギングAPI

J2SEで提供されているコアロギング機能のクラスおよびインタフェースです。Application Serverでは，JavaロギングAPIを使用してユーザログを日立トレース共通ライブラリ形式で出力する機能を提供しています。

JCAコンテナ

J2EEサーバやバッチサーバと，EISを接続するためのシステムレベルのプラグイン機能を提供するコンテナです。

JDBC（Java Database Connectivity）

Javaのプログラムでデータベースを利用するためのAPIです。

JavaSoftが1996年前半に仕様を公開しました。Javaプログラムから，JDBC APIを経由して「JDBCドライバ」を呼び出し，ドライバがデータベース・サーバへの接続機能を提供します。

JNDI（Java Naming and Directory Interface）

Javaプラットフォーム用の標準拡張機能で，Java テクノロジに対応したアプリケーションに，企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供します。

Application Serverでは，Cosminexus TPBrokerのCORBAネーミングサービスを利用して，JNDIの機能を実現しています。

JNDI名前空間

JNDIによってアクセスする名前情報が管理されている名前空間です。Application Serverでは，J2EEアプリケーションをデプロイした時に，EJBオブジェクトリファレンスがJNDI名前空間の名前にバインドされます。

Application Serverで使用するJNDI名前空間の名前には，別名を付けることができます。これによって，Enterprise BeanやJ2EEリソースを別名でルックアップできるようになります。

JP1

日立の統合システム運用管理ソフトウェアです。

JP1/AJS2

日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するめたのプログラム群です。JP1/AJS2 - Manager，JP1/AJS2 - Agent，JP1/AJS2 - Viewの製品で構成されます。

JP1/AJS2 - SO

一つ一つの運用手順を蓄積し，ライブラリとして統合する運用管理の基盤機能を提供するプログラムです。立案したシナリオに合う運用手順をライブラリから選択し，運用環境に合わせてカスタマイズすることで，業務運用の設計を容易に，かつ高品質で実現することができます。

JP1/Cm2/NC - Manager

負荷分散機の設定をしたり，負荷分散機の制御をしたりするためのプログラムプロダクトです。

JP1/Cm2/NC - Manager for Cosminexus

Cosminexusと連携して，負荷分散機を制御するためのプログラムプロダクトです。Management Serverから負荷分散機を動的に制御できます。

JP1/IM

企業情報システム全体を統合管理する基盤になるプログラム群です。JP1 Version 8の場合は，JP1/IM - Manager，JP1/IM - View，およびJP1/IM - CMの三つの製品で構成されます。JP1 Version 7iの場合は，JP1/IM - Central ConsoleおよびJP1/IM - Central Scope，JP1/IM - View，およびJP1/IM - CMの四つの製品で構成されます。

JP1/IM - CM

業務システムを構成する各種のリソース（サーバ，ストレージなど）やシステム構成に関する情報を集約して管理するためのプログラムです。管理対象のリソースを任意にグルーピングできるため，システムの監視（性能，障害）や運用（設定配布，構成変更）の際に，グループ単位で管理したり操作したりできます。

JP1/NETM/Audit

システム内の製品が出力した監査ログを自動収集して，一括管理するためのプログラムプロダクトです。JP1/Baseと連携して，Cosminexusのアプリケーションサーバ，運用管理サーバ，連携する日立オープンミドルウェア製品などが出力した監査ログを監査ログ管理サーバで自動収集できます。また，収集した監査ログを，監査ログ管理サーバのデータベースで一元管理できます。

JP1/SC/DPM

デプロイメント操作を実行するためのソフトウェアです。ディスクイメージをバックアップしたり，OSやアプリケーションのインストールを一括して実施したりできます。

JP1イベント

システム内で何らかの事象が発生した際に，その事象に関してJP1/Baseに通知される情報です。

JP1ジョブ運用管理サーバ

JP1/AJS2と連携してシステムの自動運転をする場合に，JP1/AJS2 - Managerを配置するホストのことです。

JP1統合運用管理サーバ

JP1/IMと連携してシステムの集中監視をする場合に，JP1/IM - Manager（JP1 Version 8の場合）を配置するホストのことです。JP1 Version 7iの場合は，JP1/IM - Central ConsoleおよびJP1/IM - Central Scopeを配置するホストのことです。

JSP（JavaServer Pages）

Webページを作成するHTMLの中にJSP固有のタグを埋め込んでEnterprise Beanを呼び出すことや，サーブレットから値を受け取ることができます。また，簡単なJava言語を直接記述することもできます。

JSP EL

JSP 2.0で定義された式言語です。JSPファイルやタグファイル内に

JavaBeansの属性へのアクセスなどを記述できます。また，APIも提供されています。

JSPコンパイル結果

JSPファイルおよびタグファイルのコンパイルで生成されるJavaソースファイルやクラスファイルです。

JSP事前コンパイル

Webアプリケーションに含まれるJSPファイルおよびタグファイルをデプロイ前にコンパイルし，Javaソースファイルやクラスファイルを生成する機能です。JSP事前コンパイル機能を使用してあらかじめJavaソースファイルやクラスファイルを生成しておくと，Webアプリケーション実行時の初回リクエストでのレスポンスタイムを短縮できます。

JSPタグライブラリ

JSPタグを作成するためのもので，JSP仕様で規定されています。Cosminexusでは，統合ユーザ管理をする場合に，Cosminexus標準ログインモジュールを使用してユーザ認証をするためのJSPタグライブラリを提供しています。

Management Server

運用管理ドメインを構成するサーバプログラムです。運用管理ドメイン単位に一つ配置します。

Management Serverは運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行します。

Managementアクション

Managementイベント発生時に自動的に実行される処理です。Managementアクションとしてどのような処理をするかは，Management Server側であらかじめ定義しておきます。

Managementイベント

Management Serverを利用して運用している場合に，運用管理ドメイン内の論理サーバで発生した事象に応じてManagement Serverで発行するイベントです。論理サーバでメッセージが出力されたタイミングで発行できます。例えば，リソース監視中に設定したしきい値を超えた場合などに発行できます。

Managementイベントに対してManagementアクションを定義しておくと，発生した事象に応じたアクションを自動的に実行できます。

Message-driven Bean

JMSと連携するメッセージ駆動タイプのBeanです。EJBコンテナはJMSのDestinationからのJMSメッセージ受信を契機にBeanを起動します。

MIBオブジェクト

SNMPプロトコルで使用するオブジェクトです。

MIBファイル

SNMPプロトコルで使うオブジェクトの構造体を記述したテキストファイルです。すべてのオブジェクト（情報）は，オブジェクトIDで一意に決まります。

Microsoft Cluster Service

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。Microsoft Cluster Serviceと連携することで，Cosminexusシステムの信頼性や稼働率を向上できます。Windows Server 2003で使用できます。

Microsoft Cluster Serviceと連携したシステムでは，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステムが実現できます。

N:1リカバリシステム

クラスタ構成の実行系のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。リカバリ専用サーバでは，障害が発生した実行系のアプリケーションサーバのトランザクションの決着をします。

Oracle RAC

Oracleデータベースのクラスタ機能です。Cosminexusでは，Oracle RAC機能を使用してクラスタ化されたOracleデータベースに接続できます。

ORBゲートウェイ

CORBAクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。CTMレギュレータプロセスによって提供されます。

OTMゲートウェイ

TPBroker OTMのクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。OTMゲートウェイプロセスによって提供されます。

OTS（Object Transaction Service）

1.4モードで，TPBroker OTSによる分散トランザクションを使用するために必要なサービスです。

Outbound

Connector 1.5仕様で定められたJ2EEサーバとリソースアダプタ間の通信モデルの一つです。J2EEサーバからリソースアダプタにアクセスする通信モデルです。

PRFデーモン

バッファに出力されたPRFトレースをPRFトレースファイルに出力するIOプロセスです。

Management Serverでは，論理サーバとして扱えます。Management Serverで扱う場合は，パフォーマンストレーサといいます。

PRFトレース

リクエストを処理する時にCosminexusシステムの各機能で出力されたトレース情報です。バッファに出力されて，一定量たまったらPRFトレースファイルに出力されます。

PRFトレース出力ライブラリ

Cosminexusシステムの各機能に組み込まれているライブラリです。機能レイヤごとのPRFトレースをバッファに出力する機能を提供しています。

PRFトレース取得レベル

PRFトレースを取得するレベルです。「標準レベル」，「詳細レベル」，「保守レベル」があります。「詳細レベル」または「保守レベル」を指定した場合，「標準レベル」に比べてトレース取得ポイントが多くなります。

PRFトレースファイル

PRFトレースを出力したバイナリ形式のファイルです。性能解析トレースファイル（CSV形式）に変換する基になるファイルです。

RMI-IIOP

JavaRMI とJavaIDLを統合したAPIです。

SecurityManager

セキュリティポリシーに基づいたWebコンテナの実行時保護をするJ2EEサーバの機能です。

Server Plug-in

Eclipseのプラグインです。Server Plug-inを使用すると次の操作ができます。

リソースアダプタのプロパティを設定したり，設定したリソースアダプタをJ2EEサーバやバッチサーバにデプロイしたりする。

J2EEアプリケーションのプロパティを設定したり，設定したJ2EEアプリケーションをJ2EEサーバにインポートしたりする。

論理サーバを起動・停止する。

Session Bean

主に業務処理を実行するためのBeanです。Session Beanは，クライアントを一つだけ持つことができます。クライアントが終了すると，対応するSession Bean も終了します。クライアントとのセッションの間だけ動作するため，一時的であり，非永続的なBeanです。Session Beanは，Stateful Session Beanと，Stateless Session Beanに分類されます。

SFOサーバ

システム内のJ2EEサーバのJ2EEアプリケーション内で生成されたグローバルセッション情報を管理するJ2EEサーバです。セッションフェイルオーバ機能を使用するときにシステム構成に含めます。

SFOサーバアプリケーション

SFOサーバ上で稼働するJ2EEアプリケーションを，SFOサーバアプリケーションといいます。SFOサーバアプリケーションはEJBで実装されています。なお，SFOサーバアプリケーションはCosminexusで提供しています。

Smart Composer機能

Cosminexusを使用してアプリケーションサーバを構築する場合に，一般的な3階層モデルのアプリケーションサーバのシステムを，簡単に構築および運用できるよう支援する機能です。システム全体に対して，システムの設定，およびJ2EEアプリケーションやリソースアダプタのデプロイを一括で実行できるので，簡単，迅速にシステム構築ができます。

構築したシステムを一括で起動したり，一括でシステムの設定を変更したりなど，運用機能についてもサポートしています。

snapshotログ

ある時点でのJ2EEサーバやバッチサーバの状態が出力されたログファイルです。

トラブルシューティングに必要な情報が自動的に出力されます。

Management Serverを利用している場合は，次のタイミングで出力されます。

論理サーバに異常が発生した時

運用管理ポータルまたは運用管理コマンドによってsnapshotログの収集を要求した時

Management Serverを利用していない場合は，コマンド（snapshotlog）を実行した時に出力されます。このコマンドで出力できるのは，そのコマンドを実行したホストの情報だけです。

SNMP連携用形式ファイル

SNMP Manager製品と連携するためのファイルです。MIBファイルに変換する基になる形式のファイルです。Management Serverの運用管理コマンド（mngsvrutil）で出力できます。

Stateful Session Bean

内部的な状態を保持できるBeanです。Stateless Session Beanとは異なり，ホームインタフェースからの生成によってインスタンス化されたあとは，メソッドの呼び出しごとに生成，消滅することはありません。セッション単位で連続した処理をする場合に適したBeanです。

Stateless Session Bean

状態を保持しないBeanです。Beanのインスタンスの生成・消滅は，すべてEJBコンテナが独自に管理しています。同じBeanのメソッドを続けて呼び出した場合にも，それらが同じインスタンスである保証はありません。そのため，Stateless Session Beanでは，内部状態を保持して，複数メソッドで連続した処理をすることはできません。1メソッドで完結するような処理を記述する場合に適しています。

Timer Service

EJBコンテナで提供される機能です。指定した時刻，経過時間，または間隔で，EJBコンテナがタイムアウトメソッドをコールバックします。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

JAAS対応ユーザ管理，およびシングルサインオンの機能を使用するための設定ファイルです。

uCosminexus Batch Job Execution Server

オープン環境で基幹系のバッチ業務を実行・運用するためのバッチジョブ実行基盤を提供する製品です。JP1/AJS2とあわせて使用します。

uCosminexus Client

EJBクライアント環境を構築するための製品です。

uCosminexus Operator

Application Serverをインストールしたマシンとは別のマシンから，GUI（Eclipseプラグイン）画面を使用して運用操作を実行するための製品です。例えば，実行環境がUNIXの場合に，別のWindowsのマシンでEclipseプラグインのGUIによる運用管理操作を実行したいときに，この製品を使用します。

usrconf.properties（ユーザプロパティファイル）

J2EEサーバ，バッチサーバ，Webコンテナサーバ，またはサーバ管理コマンドで使用するJavaVMのシステムプロパティを定義するファイルです。

WARファイル

Webアプリケーションの構成要素をJARファイル形式に圧縮したファイルです。

Webアプリケーション実行に必要なHTMLファイル，JSPページ，Javaクラスファイル，JARファイル，およびWebアプリケーション配置記述子が含まれます。

Webアプリケーション

Webブラウザを備えたクライアントを対象に作成されたアプリケーションです。具体的には，サーブレットプログラム，JSPページ，HTML/XMLドキュメントなどの集合体です。

Webコンテナ

J2EEアーキテクチャのWebコンポーネント規約を実装するコンテナです。セキュリティ，トランザクションなどの各種サービスを提供する実行環境です。Webアプリケーションは，Webコンテナ上で動作します。

Java Servlet2.4仕様，およびJavaServer Pages Specification v2.0仕様に準拠したWebアプリケーションを実行できます。

Webコンテナサーバ

サーブレットエンジンモードで動作するサーバを指します。

Webサーバ

Webブラウザからのリクエスト受信およびWebブラウザへのデータ送信に関連する処理を実行するプログラムです。Cosminexusでは，Hitachi Web Server，Microsoft IIS，またはインプロセスHTTPサーバを使用できます。インプロセスHTTPサーバは，J2EEサーバプロセス内で動作するWebサーバです。

なお，Management Serverを利用する場合，Hitachi Web Serverは論理サーバとして扱えます。

Webサーバ連携

アプリケーションサーバで使用するWebサーバとして，Hitachi Web ServerまたはMicrosoft IISを使用する方法です。

Hitachi Web ServerまたはMicrosoft IISにCosminexus Component Containerが提供するリダイレクタモジュールを組み込んで使用します。

Webシステム

1台の負荷分散機（ロードバランサ）と複数のWebサーバおよびアプリケーションサーバで構築されるWebクラスタシステムで，単一の業務サービスを提供します。

（ア行）

アーカイブ形式

EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションの形式です。

アウトプロセス

プロセスの起動のしかたです。アウトプロセスで起動させると，J2EEサーバのプロセス外で実行します。アウトプロセスでネーミングサービスを使用する場合，CORBAネーミングサービスはユーザが起動する必要があります。

アセンブル

単体では動作しないEJB-JARをアプリケーションの1構成要素として位置づけるための組み立て作業のことです。

アノテーション

ソースコードにクラスやメソッドの付加情報などを埋め込むための記述方式です。

アプリケーションサーバ

情報システムの中間に位置し，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。

日立のアプリケーションサーバCosminexusは，業務の開発から運用まで一貫した環境を提供します。

アプレット

Web経由で読み手のマシンのブラウザ上にダウンロードされるJavaプログラムです。

イベントリスナ

イベントを受け取って処理するオブジェクトです。Application Serverでは，Webアプリケーション単位でサーブレットコンテキストオブジェクトまたはセッションオブジェクトの状態変化イベントを受け取ります。

インプロセス

プロセスの起動のしかたです。インプロセスで起動させると，J2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムが実現できます。ネーミングサービス，トランザクションサービスおよびHTTPサーバ機能をインプロセスで起動できます。このとき，CORBAネーミングサービス，インプロセスOTSおよびインプロセスHTTPサーバは，J2EEサーバ起動時に自動で起動されます。

インプロセスHTTPサーバ

J2EEサーバのインプロセスで動作するWebサーバ機能です。Webコンテナの機能の一部として提供されます。

運用監視エージェント

ホスト上で動作する論理サーバの稼働状況を監視して，稼働情報を収集するエージェントプログラムです。

運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェントプログラムです。

運用管理コマンド（mngsvrutil）

Management Serverを操作するためのCUIです。

運用管理サーバ

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverを配置したホストです。運用管理ドメイン内の各ホストに配置されている運用管理エージェントに対して，管理操作を指示します。

運用管理サーバモデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，アプリケーションサーバとは別の運用管理用のホストにManagement Serverを配置するシステム構成モデルです。

運用管理ドメイン

Management Serverが管理する論理サーバの集合です。同じ運用管理ポリシーが適用されます。

運用管理ポータル

Management Serverを操作するためのGUIです。Webブラウザで表示します。

運用管理ポリシー

運用，監視，セキュリティなど，運用管理に関するポリシーです。

エラーページのカスタマイズ

Webクライアントから存在しないリソースへのアクセスなどがあった場合に，Webコンテナから返却されるエラーページをユーザが作成した任意のページに変更して表示させる機能です。

（カ行）

ガーベージコレクション制御機能

リソースの排他中にガーベージコレクションの実行を待ち状態にする機能です。リソースの排他中にフルガーベージコレクションが発生し，処理が長時間中断されるのを回避できます。ガーベージコレクション制御機能は，バッチサーバの場合に使用できます。

カスタムジョブ

JP1/AJS2以外のプログラムとJP1/AJS2が連携するジョブを定義する場合に，目的のジョブを容易に作成するために使用できるジョブのテンプレートです。Windowsの場合，Cosminexusでは，「論理サーバ制御用カスタムジョブ」と「アプリケーション制御用カスタムジョブ」の2種類を提供しています。

カスタムログインモジュール

Cosminexus標準ログインモジュール以外を使用して，各アプリケーションのユーザ認証をしたい場合に作成する実装クラスです。

仮想サーバ

負荷分散機で複数の実サーバを管理するための仮想的なサーバです。負荷分散機では，クライアントから仮想サーバにアクセスされたトラフィックを，実サーバに自動分配します。

稼働情報収集機能

J2EEサーバやバッチサーバ内の各機能の稼働情報を定期的に収集し，ファイルに出力する機能です。出力されたファイルを稼働情報ファイルといいます。

簡易Webサーバ

WebコンテナをHTTPサーバとして使用して，スタブなどのダウンロードに利用する機能です。インプロセスHTTPサーバとは異なり，実運用時にはスタブのダウンロード以外の目的では使用できません。

Management Serverを利用する場合は，「管理用サーバ」という名称で扱います。

監査証跡

データベースの機能で出力する，データベースに対する操作記録のことです。データベースに対する権限の運用が適切に行われているかどうかをチェックするために使用します。Cosminexusでは，監査証跡にCosminexusシステムの情報を出力するためのデータベース監査証跡連携機能を提供しています。

監査ログ

システム構築者やシステム運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」「だれが」「何をしたか」を知ることができて，システムの運用が法規制，セキュリティ評価基準，または業界ごとの各種の基準に準拠していることを証明できます。

監視ツリー

JP1/IM連携をしている場合に，統合スコープに表示するツリーのことです。Cosminexusシステムでは，監視ツリーとして，Cosminexus業務指向ツリーとサーバ指向ツリーの2種類を作成する機能を提供しています。

管理対象オブジェクト（AdminObject）

Connector 1.5仕様で定義された，キューやトピックなどを使用したメッセージの送受信で使用するオブジェクトです。メッセージ送信や，同期または非同期でのメッセージ受信でのメッセージ変換で使用します。

管理対象オブジェクトは，メッセージプロバイダごとに特有のオブジェクトです。リソースアダプタが使用する管理対象オブジェクトは，リソースアダプタのDD（ra.xml）の<adminobject>タグで指定します。

機能レイヤ

性能解析トレース収集をする場合に，PRFトレースを出力する機能の層です。EJBクライアント，リダイレクタ，Webコンテナ，CTM，EJBコンテナ，JNDI，JTA，JCA/JDBCなどがあります。

業務指向ツリー

JP1/IMと連携している場合に統合スコープに表示する監視ツリーの一つです。Cosminexusシステム上で稼働しているJ2EEアプリケーションを主体に構成されている監視ツリーです。どの業務で問題が発生しているか，業務の視点でトラブルを監視できます。

業務処理プログラム

ビジネスロジックを実装したEnterprise Beanのことです。

共有スレッド数

Webコンテナ上にデプロイされているWebアプリケーションで共有されるスレッド数です。

クライアントアプリケーション情報

性能解析トレースに出力される情報です。次に示すEnterprise Beanを呼び出す単位で設定される情報です。

WebコンテナからEJBコンテナの呼び出し

EJBクライアントからEJBコンテナの呼び出し

EJBコンテナからEJBコンテナの呼び出し

クラスタ

ある共通の機能を提供するサーバの集合です。

Management Serverでは，J2EEサーバクラスタまたはWebサーバクラスタを論理サーバとして扱えます。

クラスタソフトウェア

システムの信頼性向上，稼働率向上を目的として，システムの切り替えを実現するプログラムです。

実行中のサーバシステムに障害が発生した場合，事前に待機しているサーバシステムに，直ちに自動で切り替えることができます。そのため，オペレータが特に意識することなく，システムの信頼性や稼働率を高められます。

Cosminexusでは，クラスタソフトウェアを使用して，1:1系切り替えシステム，N:1リカバリシステム，および相互系切り替えシステムを実現できます。

AIX，HP-UXまたはLinuxを使用している場合は，クラスタソフトウェアとしてHAモニタが使用できます。Windowsの場合は，クラスタソフトウェアとしてMicrosoft Cluster Serviceが使用できます。

グローバルCORBAネーミングサービス

CTMによってリクエストをスケジューリングする場合に，CTMドメイン内に含まれる複数のJ2EEサーバに登録されている業務処理プログラム（Stateless Session Bean）の情報を共有管理するネーミングサービスです。

グローバルセッション

セッションフェイルオーバ機能では，障害発生前のHTTPセッションと，障害発生後に引き継がれたHTTPセッションを一つのセッションとして扱います。これをグローバルセッションといいます。

グローバルセッションID

グローバルセッションを管理するIDです。システム内でグローバルセッション情報を一意に識別するために，グローバルセッションに付けられます。

グローバルセッション情報

グローバルセッションが持つ情報をグローバルセッション情報といいます。グローバルセッション情報はSFOサーバで管理されます。

グローバルトランザクション

J2EEサーバが提供するトランザクションマネジャによって管理されるトランザクションです。2フェーズコミットプロトコルを使用できるので，トランザクションに複数のリソースを参加させることができます。

系

系とは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器を含めたシステム全体の総称です。系の種類には，実行系と待機系があります。

計画系切り替え

系切り替えの方法の一つで，オペレータが系を保守する際に，計画的に系を切り替える方法です。

系切り替え

システムに障害が発生した場合やシステムの保守のために，システムを切り替えることをいいます。系切り替えが行われると，待機系は業務処理を引き継いで実行系となります。一方，実行系は，さらに障害が発生した場合に備えて待機系となります。以降，系切り替えのたびに，実行と待機を交代して，どちらかの系で常に業務処理を実行するようにします。

系障害

サーバを除いた系に発生する障害を指します。系のハードウェア障害やHAモニタの障害などがあります。なお，サーバに発生する障害はサーバ障害といいます。

ゲートウェイ指定機能

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようにするための機能です。

現用系

最初に実行系として動作させる系を現用系といいます。系切り替えによって，実行系が待機系になった場合でも，呼び方は変わりません。

コネクションスイーパ

一定の間隔でコネクションプール内の未使用コネクションを破棄する機能です。

コネクションプーリング

サーブレット，JSP，Enterprise BeanなどのJ2EEコンポーネントや，バッチアプリケーションからリソースへのアクセス量に応じて，リソースコネクションをメモリ上にプーリングする機能です。リソースコネクションには，JDBCコネクション，リソースアダプタのコネクションなどがあります。コネクションをプーリングしておくことで，アプリケーションからのリソース接続要求を高速に処理できます。

コミットオプション

CMPフィールドのキャッシュ方法とEntity Beanの状態遷移のキャッシュモデルを指定するオプションです。

Full cachingの場合，Entity Beanは前回のトランザクションコミット時と同じ状態で開始されます。

Cachingの場合，Entity Beanはデータベースの最新状態と同じ状態で開始されます。

No cachingの場合，Entity Beanはデータベースの最新状態と同じ状態で開始され，かつ，トランザクションコミット時にEntity Beanは非活性になります。

コンテキスト

Webアプリケーションをまとめた管理単位です。

コンテキストルート

コンテキストのルートパスです。コンテキスト内のWebアプリケーションにアクセスするときにURL上に指定します。コンテキストパスとも呼びます。

コンテナ拡張ライブラリ

ユーザ作成ライブラリのインタフェースおよび機能を，J2EEコンテナ，Webコンテナ，またはバッチサーバから利用できるように拡張したライブラリです。Enterprise Bean，サーブレットおよびJSPから共通して利用できます。

（サ行）

サーバ管理コマンド

サーバで管理しているアプリケーションおよびリソースの設定をするためのコマンド群です。

サーバ起動・停止フック機能

J2EEサーバ，バッチサーバまたはWebサーバの起動・停止時に，コンテナ拡張ライブラリを使用するための初期化処理および停止処理を自動的に呼び出す機能です。J2EEサーバまたはWebサーバが異常終了した場合には機能しません。

サーバ指向ツリー

JP1/IMと連携している場合に統合スコープに表示する監視ツリーの一つです。サーバマシン（ホスト）を主体に構成されている監視ツリーです。

サービス閉塞

J2EEアプリケーションの運用中に特定の業務処理プログラムを入れ替えたい場合などに，システム全体は稼働させたまま，該当サービスだけを安全に閉塞させる機能です。

サービスユニット

J2EEサーバやWebサーバで構成される業務サービスを提供する閉じた部分系を，サービスユニットといいます。Smart Composer機能では，サービスユニット単位でシステムを構築したり，一括起動や一括停止をしたりできます。

Smart Composer機能を利用してシステムを構築するときの概念です。

サーブレット

サーバ側でJavaを実行させる方法の一つです。

サーブレットは，Webサーバに対して，単にHTML文書や画像ファイルを送るだけではなく，Webサーバと連携して，アプリケーションを実行し，その結果をHTML文書として送り返す機能を提供します。

サーブレットエンジンモード

サーバの動作モードの一つです。Webコンテナ部分だけを使用して，サーブレットエンジンを単独で動作させます。Enterprise Beanは動作しません。

サーブレットエンジンとは，サーブレット実行機能およびJSP実行機能を持つサーバのことです。

なお，サーブレットエンジンモードは互換用の動作モードとなります。

サーブレットフィルタ

サーブレット/JSPへのリクエストや，サーブレット/JSPからのレスポンスを，フィルタリングする機能です。サーブレットフィルタによって，サーブレット/JSPの実行前のリクエスト，または実行後のレスポンスをラップして，データの変更，リソースに対するトレースの取得などができます。

Cosminexusの機能を実現するためのサーブレットフィルタとしては，セッションフェイルオーバ用フィルタ，およびHTTPレスポンス圧縮用フィルタが提供されています。

実行系

業務処理を実行させる系（実行中のサーバ）を指します。

実行待ちキュー

同時実行スレッドの最大値を設定している場合に，実行スレッド数が最大に達したときに，リクエストをためておくキューのことです。

実パラメタ

Cosminexusの定義ファイルに設定するパラメタです。Smart Composer機能では，抽象パラメタを一つ設定することで，互いに関連のある複数の実パラメタに，一括で値を設定できます。

自動系切り替え

系切り替えの方法の一つで，クラスタソフトウェアが自動的に系を切り替える方法です。

シナリオ

JP1/AJS2 - SOで扱う，シナリオジョブに実行順序を付けてネットワーク化したオブジェクトです。シナリオジョブとは，シナリオ中に定義されたコマンド，シェルスクリプト，Windows実行ファイルなどを定義したオブジェクトです。

シナリオはJP1/AJS2に登録して実行できます。

ジョブ

JP1/AJS2で扱うシステム運用の各作業のことです。

ジョブネット

JP1/AJS2で扱うジョブの実行順序を関連づけたものです。

シングルサインオン

一度のログイン処理で，ユーザIDが異なる複数のシステムをシームレスに利用できるようにする機能です。

シングルサインオン情報リポジトリ

統合ユーザ管理フレームワークのユーザマッピングを実行して，シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報を格納するリポジトリです。

シングルサインオンライブラリ

ユーザマッピング情報の格納されたシングルサインオン情報リポジトリの情報を基にユーザマッピングをして，シングルサインオンを実現するライブラリです。

スケールアウト

システム全体の処理性能を向上させることを目的として，サーバの台数を増やすことをいいます。

スケールイン

システムの規模を縮小する場合などに，サーバの台数を減らすことをいいます。

スケジュールキュー

CTMによってリクエストをスケジューリングする場合に，リクエストをためておくキューです。J2EEアプリケーション単位で作成され，CTMデーモンによって管理されます。

スケジュールポリシー

CTMによってリクエストをスケジューリングする場合に，振り分ける基準を決めるポリシーです。負荷が軽いCTMデーモンに振り分ける方法と，リクエストを受け付けたCTMデーモンに優先的に処理させる方法のどちらかを選択できます。

スマートエージェント

1.4モードでグローバルトランザクションを使用する場合，またはCTMを使用する場合に，動的な分散ディレクトリサービスを提供するプロセスです。

Management Serverを利用する場合，スマートエージェントは論理サーバとして扱えます。CTMはスマートエージェントによって管理されます。

なお，グローバルトランザクションの場合でも，インプロセストランザクションサービスを利用するときは，スマートエージェントは不要です。

静的コンテンツ

HTMLファイルや画像ファイルなど，クライアントからの要求に対する応答に使用するファイルのうち，リクエスト内容に影響されないで常に同じ内容になるコンテンツのことです。

性能解析トレース

Cosminexusシステムの性能解析をするためのトレース情報です。

性能解析トレースファイル

Cosminexusシステムの性能解析をするためのトレース情報をCSV形式で編集出力したテキストファイルです。

セキュリティアイデンティティ

J2EEサーバによるユーザ認証が成功した時にWebコンテナやEJBコンテナに伝達される認証情報です。

セッション

Webアプリケーションに対する一連の作業を示す単位です。セッションは通常，WebクライアントからWebサーバへの複数のリクエストの集合から構成されます。

セッションフェイルオーバ機能

J2EEアプリケーション実行中のHttpSessionオブジェクトに登録されたオブジェクトをセッション情報として管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡す機能です。J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

セッションフェイルオーバサーバ

セッションフェイルオーバ機能を使用する場合に，J2EEサーバを配置しないで，SFOサーバを配置して使用するホストです。

セットアップウィザード

対話形式のウィザードプログラムを使用してシステムを構築するための機能です。必要最低限の項目を設定するだけで，J2EEアプリケーションを実行するためのシステムを構築できます。できるだけ少ない手順で実行環境を構築したい場合にお勧めの機能です。ただし，セットアップウィザードで実行できるのは，1台のマシンを対象にしたシステム構築だけです。

占有スレッド数

利用できるスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webコンテナ上にデプロイされているWebアプリケーションごと，またはWebアプリケーション内の業務処理ロジックごとに指定できます。

相互系切り替えシステム

クラスタソフトウェアを使用して実現できるシステムの一つです。アプリケーションサーバの実行系と待機系を1：1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にするシステムです。

相互スタンバイ

クラスタソフトウェアを使用した運用をする場合に，アプリケーションサーバの実行系と待機系を1:1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にすることです。

（タ行）

待機系

障害に備えて待機させている系（待機中のサーバ）を指します。

抽象パラメタ

互いに関連のあるパラメタを一つのパラメタとしてまとめたものです。Smart Composer機能で使用します。Smart Composer機能のコマンドを使用してパラメタを展開すると，一度に複数の実パラメタに値が展開されます。

通常モード

J2EEアプリケーションの動作モードです。通常モードは，本番稼働するJ2EEアプリケーションを動作させるためのモードです。

データソース

JDBCを使用してデータベースに接続する機能です。

テストモード

J2EEアプリケーションの動作モードです。テストモードは，テスト用のJ2EEアプリケーションを本番環境と同じように動作させるためのモードです。

デプロイ

J2EEアプリケーションの場合，J2EEサーバ内にインポートしたJ2EEアプリケーションを，クライアントから実行可能な状態にすることです。

J2EEリソースアダプタの場合，J2EEサーバ内にインポートしたJ2EEリソースアダプタを，そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションから使用可能な状態にすることです。

展開ディレクトリ形式

EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションの形式です。

統合コンソール

JP1/IMと連携している場合に，システムで発生した事象に関するエラーメッセージなどを表示する画面です。

統合スコープ

JP1/IMと連携している場合に，システムの監視画面として管理者の目的に合った監視ツリーを表示する画面です。

統合ネーミングスケジューラサーバ

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないで，グローバルCORBAネーミングサービスを配置して使用するホストです。統合ネーミングスケジューラサーバのレプリカを作成することで，可用性を向上できます。なお，統合ネーミングスケジューラサーバにもCTMデーモンは必要です。

統合ネーミングスケジューラサーバモデル

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないでグローバルCORBAネーミングサービスを配置するホストを作成するシステム構成モデルです。

統合ユーザ管理

Cosminexusシステムにログインするユーザを統合管理するための仕組みです。ユーザ認証を実現する統合ユーザ管理フレームワークと，リポジトリ管理およびリソース監視を実現する統合ユーザ管理GUIが使用できます。

統合ユーザ管理GUI

Management Serverの運用管理ポータルから，統合ユーザ管理の対象になるユーザ情報を格納したリポジトリを管理したり，統合ユーザ管理に関連するリソースを監視したりするためのGUIです。

統合ユーザ管理フレームワーク

統合ユーザ管理でのユーザ認証を実現するフレームワークです。Java標準仕様（JAAS）に従ったAPIが提供されています。

動作モード

サーバの動作モードです。J2EEサーバモードとサーブレットエンジンモードがあります。J2EEサーバモードには，さらに，1.4モード，ベーシックモードがあります。

ただし，ベーシックモードおよびサーブレットエンジンモードは旧バージョンとの互換用の動作モードとなります。

動的コンテンツ

サーブレットやJSPのように，クライアントからの要求に応じて動的に生成されるコンテンツのことです。

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

グローバルトランザクションを使用する場合に，トランザクションを管理するサービスです。TPBroker OTSによって提供されるサービス全体を表します。トランザクションサービスは，J2EEサーバのインプロセスで起動されます。

トランザクションマネジャ

トランザクションを管理する機能です。Application Serverが提供しています。グローバルトランザクションの場合は，トランザクションマネジャのバックエンドでTPBroker OTSが使用されています。

トレース取得ポイント

Cosminexusシステムの各機能レイヤでPRFトレースを出力するポイントのことです。PRFトレース取得レベルの指定によって，トレース取得ポイントの数は異なります。

（ナ行）

ネーミング切り替え

JNDIを介してEJBホームオブジェクトの登録，削除，検索をする時に，JNDIが接続するCORBAネーミングサービスを切り替えることです。

ネーミングサービス

オブジェクトに名前を付けて格納場所を管理しておくことで，格納先を知らなくても名前からそのオブジェクトを利用できるようにするサービスです。Application ServerではCORBAネーミングサービスを利用します。

Management Serverでは，ネーミングサービスを論理サーバとして扱えます。

（ハ行）

バインド先アドレス設定機能

Webサーバ連携および簡易Webサーバで利用するIPアドレスを，Webコンテナで明示的に指定する機能をバインド先アドレス設定機能といいます。複数の物理ネットワークインタフェースを持つホストまたは一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，この機能を使用することで，任意のIPアドレスを設定できます。

バッチアプリケーション

バッチ処理を実装したJavaアプリケーションです。バッチ実行コマンドを使用して，バッチサーバ上で実行します。バッチ実行コマンドをJP1/AJS2のジョブとして定義しておくと，JP1/AJS2からバッチアプリケーションを実行できます。

バッチサーバ

バッチアプリケーションを実行するためのサーバです。バッチアプリケーションの実行機能のほかに，バッチアプリケーションからデータベースに接続したり，EJBにアクセスしたりする機能も提供しています。

パフォーマンストレーサ

PRFデーモンのことです。

Management Serverでは，パフォーマンストレーサを論理サーバとして扱えます。

ハンドラ

ロガーから受け取ったアプリケーションのログをファイルやコンソールに出力する，JavaロギングAPIのHandlerオブジェクトです。J2EEアプリケーション，バッチアプリケーション，EJBクライアントアプリケーションで使用できます。

Application Serverでは，日立トレース共通ライブラリ形式のログをファイルに出力するためのファイルハンドラである，CJMessageFileHandlerを提供しています。

ビジネスインタフェース

Enterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。

日立トレース共通ライブラリ

日立が提供するトレース採取用のライブラリです。複数の製品で共通のライブラリを利用するので，各製品のトレース形式が統一できます。

非保護区

メソッドキャンセルができる領域を指します。ユーザプログラムのコードが非保護区に該当します。メソッドキャンセルとは，J2EEアプリケーション実行時間の監視で提供される機能の一つです。また，バッチ強制停止コマンドでも使用されます。

負荷分散機

Webブラウザなどからのリクエストを一元的に受け付けて，同等の機能を持つ複数のサーバに転送して各サーバの負荷を分散させるための装置です。

物理コネクション

接続先リソースのコネクションです。通常はJ2EEコンテナが操作します。リソースアダプタの場合は，javax.resource.spi.ManagedConnection，JDBCの場合はjavax.sql.XAConnectionに該当します。

物理ティア

同一のデプロイメント（プロセスの配置，J2EEアプリケーションやリソースアダプタのデプロイ，定義）を適用するサーバマシンの集合を物理ティアといいます。

Smart Composer機能を利用してシステムを構築するときの概念です。

フロントEJB

リクエストの受け口となるEnterprise BeanをフロントEJBといいます。

ベーシックモード

旧バージョンとの互換性を確保するためのサーバの動作モードの一つです。

単一リソースとのトランザクション管理ができます。

別名

JNDI名前空間に登録するEJBホームオブジェクトリファレンスや，J2EEリソースに付けられる任意の名前です。ユーザ指定名前空間機能を使用している場合，別名を付けられます。Optional Nameともいいます。

保護区

メソッドキャンセルができない領域を指します。J2EEサービスのソースなどが保護区に該当します。メソッドキャンセルとは，J2EEアプリケーション実行時間の監視で提供される機能の一つです。また，バッチ強制停止コマンドでも使用されます。

ホスト単位管理モデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverをアプリケーションサーバと同じホストに配置するシステム構成モデルです。

（マ行）

未決着トランザクション

決着していない，仕掛かり中のトランザクションです。

メソッドキャンセル機能

J2EEアプリケーション実行時間の監視機能の機能の一つです。メソッドタイムアウト機能でタイムアウトが通知されたあと，メソッドのキャンセルを実施する機能です。キャンセル時にデータベースにアクセスしている場合は，トランザクションの強制決着もします。

また，メソッドキャンセル機能は，バッチ強制停止コマンド実行時にも使用されます。

メソッドタイムアウト機能

J2EEアプリケーション実行時間の監視機能の機能の一つです。監視基盤にあるリクエストのうち，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知します。

メッセージインフロー

メッセージプロバイダがアプリケーションサーバ上のメッセージエンドポイントにメッセージを配送する場合の規約です。Connector 1.5のInboundの通信モデルを使用する場合に使用できる機能です。

メッセージプロバイダにはEISなどが該当します。アプリケーションサーバ上のメッセージエンドポイントにはMessage-driven Beanが該当します。

面数

ログファイルを保持する数です。ログファイルは面数分作成され，循環して使用されます。

メンバリソースアダプタ

コネクションプールをクラスタ構成にしている場合に，データベースノードに接続するリソースアダプタです。メンバリソースアダプタは，必ずルートリソースアダプタを経由してアクセスされます。

（ヤ行）

ユーザ指定名前空間機能

JNDI名前空間に登録するEJBホームオブジェクトリファレンスやJ2EEリソースの名前に，ユーザが任意の別名を付けられる機能です。別名を付与することによって，CTMによってリクエストを振り分けたり，負荷分散機やロードバランサによって負荷分散したりする場合に，サーバ名やアプリケーション名に依存しない名前でルックアップできるようになります。

ユーザ情報

Cosminexusシステムにユーザがログインするための情報です。

ユーザ情報リポジトリ

統合ユーザ管理をする場合に，ログイン時のユーザ認証に使用する情報を格納するリポジトリです。LDAPディレクトリサーバまたはデータベース（RDB）が使用できます。

ユーザスレッド

ユーザがプログラムの中で明示して生成するスレッドのことです。

ユーザ認証ライブラリ

LDAPディレクトリサーバで構築されたユーザ情報リポジトリの情報を基にユーザ認証をして，認証したユーザの情報をアプリケーションに提供する，JAAS対応ユーザ管理用ライブラリです。

ユーザプロパティファイル

usrconf.propertiesのことです。J2EEサーバ，Webコンテナサーバまたはサーバ管理コマンドを実行するJavaVMのシステムプロパティを指定します。なお，J2EEサーバ，Webコンテナサーバおよびサーバ管理コマンドで使用するユーザプロパティファイルは，それぞれ格納先および指定できるキーが異なります。

ユーザマッピング

異なるユーザ情報リポジトリに格納した同じユーザについての情報を対応づけることです。

ユーザログ

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションが出力するログのことです。

予備系

最初に待機系として起動する系を予備系といいます。系切り替えによって，待機系が実行系になった場合でも，呼び方は変わりません。

（ラ行）

ライトトランザクション

ローカルトランザクションを最適化した状態で使用できる機能です。

ライブラリJAR

JARファイル形式でパッケージされた，共通ライブラリです。J2EEアプリケーション内のJ2EEコンポーネントから共通に使用できます。

ラウンドロビン検索

複数のCORBAネーミングサービス上にある同一名称のEJBホームオブジェクトを，ラウンドロビンポリシーに従ってルックアップする検索機能のことです。

ラウンドロビンポリシー

複数のCORBAネーミングサービス上にある同一名称のEJBホームオブジェクトをルックアップする場合に適用されるポリシーです。

EJBホームオブジェクトリファレンスをラウンドロビン検索によって取得できるので，EJBクライアントでは意識しないでJ2EEサーバに送信するリクエストの負荷分散を実現できます。

リカバリ専用サーバ

クラスタソフトウェアを使用してN:1リカバリシステムを構築している場合に待機系として機能するアプリケーションサーバです。

障害が発生した実行系のアプリケーションサーバに未決着のトランザクションがあった場合に，系が切り替えられ，該当するトランザクションを解決してリソースを解放します。

リクエスト処理スレッド

Webブラウザなどのクライアントからのリクエストを受け付けて処理するためにWebサーバで生成されるスレッドです。インプロセスHTTPサーバの場合は，Webコンテナで生成されます。

リクエストのスケジューリング

クライアントからのリクエストを実行するサーバを負荷に応じて的確に振り分けたり，サーバに送信するリクエストの数を制限したりする機能です。

リソースアダプタ

J2EE Connector Architectureによって，J2EEサーバまたはバッチサーバと，EISを接続するための接続機能です。

Cosminexusシステムでは，データベースに接続するためのリソースアダプタであるDB ConnectorおよびDB Connector for Cosminexus RMを提供しています。また，OpenTP1のSPPと接続するためのリソースアダプタであるuCosminexus TP1 Connector，TP1/Message Queueと接続するためのリソースアダプタであるTP1/Message Queue - Access，データベース上に実現したキューに接続するためのリソースアダプタであるCosminexus RMも使用できます。

リソースマネジャ

リソースを管理する機能です。DBMSなどが該当します。

リダイレクタ

Webサーバに登録しWebコンテナへの接続を可能にするプラグインコンポーネント（ライブラリ）です。Webサーバに登録したリダイレクタによって，リクエストをURLパターンまたはラウンドロビン方式で複数のWebコンテナに振り分けて処理できます。

リデプロイ機能

J2EEアプリケーションを入れ替えるときに使用する機能です。リデプロイ機能による入れ替えは，J2EEアプリケーションのテスト時などに，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたいときに使用します。

リバースプロキシサーバ

インターネットなどの外部ネットワークとアプリケーションサーバが配置されている内部ネットワークの間のDMZに配置され，外部ネットワークからのリクエストを内部ネットワークに中継するための機能を持つWebサーバです。

Cosminexusでは，Hitachi Web Serverをリバースプロキシサーバとして使用できます。リバースプロキシサーバには，リバースプロキシモジュールが組み込まれて動作します。

リモートインタフェース

Java RMIのインタフェース規定に従い，RMI-IIOP通信によってEnterprise Beanの呼び出しをするインタフェースです。

リモートホームインタフェースとリモートビジネスインタフェースが含まれます。

リロード機能

開始状態にあるアプリケーションを停止させないで，アプリケーションを構成するクラスやJSPを，少ない手順で動的に入れ替える機能です。

ルートアプリケーション情報

性能解析トレースに出力される情報です。イベントで一連の処理の先頭になるプロセスで取得した情報です。

ルートコンテキスト

コンテキストルートが空文字（コンテキストルートに名称が指定されていない）の，WARファイル内のルートパスです。

ルートリソースアダプタ

コネクションプールをクラスタ構成にしている場合に，メンバリソースアダプタを束ね，ユーザプログラムからのリクエストを受け付けるアダプタのことです。

レルム

統合ユーザ管理をしているシステムで，同一の認証ポリシーを適用する範囲のことです。

ローカルインタフェース

Enterprise Beanの呼び出しをJavaのメソッド呼び出しで実行するインタフェースです。通信は発生しません。

ローカルホームインタフェースとローカルビジネスインタフェースが含まれます。

ローカルトランザクション

接続先のリソースマネジャによって管理されるトランザクションです。単一のリソースだけがトランザクションに参加できます。

ロードバランサ

リダイレクタを使用してリクエストを振り分ける場合に使用するワーカ定義のうち，クラスタ構成の場合に使用する特殊なワーカ定義です。振り分け先のWebコンテナのリストが定義されています。リダイレクタでは，この定義を基に，ラウンドロビン方式でリクエストの振り分け処理をします。

ロール

コンテキストに対し，アクセス制御するときに使用される単位です。ロールはグループごとに定義されます。また，アクセス制御するコンテキストについては，そのコンテキストにアクセスするのに必要なロールが定義されます。アクセスしたユーザの持つロールがコンテキストに定義されたロールと一致した場合，そのコンテキストへのアクセスは成功します。

ロガー

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションのログを取得する，JavaロギングAPIのLoggerオブジェクトです。

ログインモジュール

JAASに準拠した統合ユーザ管理のユーザ認証に使用する，JAAS APIのLoginModuleインタフェースの実装クラスです。

論理コネクション

サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作するコネクションです。

リソースアダプタの場合はjavax.resource.cci.Connection，JDBCの場合はjava.sql.Connectionに該当します。

論理サーバ

Management Serverの運用管理の対象になる，サーバまたはクラスタです。サーバには，Webサーバ，J2EEサーバなどがあります。クラスタとは，ある共通の機能を提供するサーバの集合です。

論理ネーミングサービス

JNDIがラウンドロビン検索の対象にする複数のCORBAネーミングサービスのことです。

論理ユーザサーバ

任意のサービスやプロセスをManagement Serverの管理対象として定義した論理サーバです。Management Serverで起動・停止したり，ステータス監視したりできるようになります。

（ワ行）

ワーカプロセス

Webサーバの背後で動作するWebコンテナのプロセスです。リダイレクタから見た場合のWebコンテナ実行プロセスになります。具体的には，J2EEサーバまたはWebコンテナサーバに当たります。

索引

[記号]
[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｆ][Ｇ][Ｈ][Ｉ][Ｊ][Ｌ][Ｍ][Ｎ][Ｏ][Ｐ][Ｒ][Ｓ][Ｔ][Ｕ][Ｗ][Ｘ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行][ワ行]

(記号)

<%=%>タグ記述時の注意

<jsp:plugin>タグ利用時の注意

@RemoteHomeまたは@LocalHomeで指定したホームインタフェースについて

(数字)

1.4モード

1:1系切り替えシステム

1:1系切り替えシステム

1:1系切り替えシステム

1:1系切り替えシステム

1:1系切り替えシステムでの系切り替え処理の流れ

1:1系切り替えシステムでの系切り替えの動作

1:1系切り替えシステムのシステム構成例

(英字)

(Ａ)

afterCompletionメソッドからのEnterprise Beanの呼び出しについて

APIを使用したユーザ認証の実装

Application Server

Application Serverが管理するトランザクション

Application Serverで提供する機能の目的

Application Serverで提供する機能の目的

Application Serverとは

(Ｂ)

Bean-Managed Persistence

Bean-Managed Transaction

Beanクラスの共有についての注意

Beanクラスの共有についての注意

beforeCompletionメソッドからのEnterprise Beanの呼び出しについて

BJEX

BMP

BMP

BMT

BMT

built-inフィルタ

built-inフィルタ

built-inフィルタ

(Ｃ)

Caching（commit option B）

CallableStatementクラスでのバッチ更新

cjjspcコマンドによるJSP事前コンパイル

CJLogRecordクラス

CJLogRecordクラスが属するパッケージ

cjstartappコマンドによるJ2EEアプリケーション開始時のJSP事前コンパイル

CMP

CMP

CMRのcascade-deleteの使用についての注意

CMRフィールド使用時のトランザクションに関する注意

CMT

CMT

Component Container管理者

Component Container管理者

Container-Managed Persistence

Container-Managed Transaction

Cookieスイッチング機能

CookieへのサーバID付加

Cookie利用時の注意

CORBAネーミングサービス

CORBAネーミングサービス

CORBAネーミングサービスの切り替え

Cosminexus

Cosminexus Component Container

Cosminexus Component Transaction Monitor

Cosminexus DABroker Libraryで開発するアプリケーション

Cosminexus DABroker Libraryの文字コード設定

Cosminexus Operator Plug-in

Cosminexus Performance Tracer

Cosminexus Reliable Messaging

Cosminexusがサポートするクラスタソフトウェア

Cosminexusが提供するサーブレットフィルタ

Cosminexusシステム

Cosminexusシステムのユーザを統合管理する機能の概要

Cosminexusで提供するシステムの構築支援機能

Cosminexus標準のログインモジュールと連携するための情報

Cosminexus標準ログインモジュール

Cosminexus標準ログインモジュール

Cosminexus標準ログインモジュール

create時の選択ポリシー

CTM

CTM

CTM

CTMが提供する機能の概要

CTMデーモン

CTMデーモン

CTMでスケジューリングできないリクエスト

CTMドメイン

CTMドメイン

CTMドメインマネジャ

CTMドメインマネジャ

CTMドメインマネジャの稼働状態の確認

CTMのスケジュールキューの閉塞処理

CTMのプロセス構成

CTMレギュレータ

CTMレギュレータ

(Ｄ)

DataSourceオブジェクトのキャッシング

DataSourceオブジェクトの生成

DB Connector

DB Connector（RARファイル）の種類

DB Connector for Cosminexus RMとCosminexus RMによる接続

DB Connectorによる接続

DB Connectorのコンテナ管理でのサインオンの最適化

DD

DD

DDの定義

DDの定義内容（JavaBeansリソース）

DDの定義例（統合ユーザ管理・セッションフェイルオーバ機能）

DelegationLoginModule

Dependency Injection

DI

DIターゲット

DTD

(Ｅ)

EARファイル

EARファイル／ZIPファイルの展開ディレクトリ形式でのデプロイ

EIS

EJB

EJB-JAR

EJB-JARファイル

EJBアクセス機能の概要

EJBクライアント

EJBクライアント

EJBクライアントアプリケーション

EJBクライアントアプリケーション

EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項

EJBクライアントアプリケーションでのセキュリティの実装

EJBクライアントアプリケーションでのトランザクションの実装

EJBクライアントアプリケーションでのユーザログ出力の拡張

EJBクライアントアプリケーションでのユーザログ出力の実装

EJBクライアントの実行機能の概要

EJBコンテナ

EJBコンテナ

EJBコンテナ

EJBコンテナが提供する機能の概要

EJBコンテナで使用できる機能

EJBコンテナでのタイムアウトの設定

EJBコンテナとの連携

EJBコンテナとの連携

EJBコンテナによるコネクション自動クローズ

EJBタイマ

EJBタイマキャンセル

EJBタイマ生成

EJBにアクセスするバッチアプリケーションの作成

EJBの仕様に関する注意

EJBのチェック

EJBのリモートインタフェースでのローカル呼び出しの最適化

EJBのリモートインタフェースの値の参照渡し

EJBのリモートインタフェースの通信障害発生時の動作

EJBのリモートインタフェースの呼び出し

EJBホームオブジェクトのリファレンスの検索と取得

EJBホームオブジェクトのリファレンスを検索してEnterprise Beanを呼び出す方法

EJB呼び出し時のモードの判別

EL（Expression Language）のエスケープシーケンスについて

Enterprise Bean

Enterprise Bean

Enterprise Beanおよび関連するクラスの命名規則

Enterprise Bean共通の注意事項

Enterprise Beanでのトランザクション設定

Enterprise Beanのアノテーション指定

Enterprise Beanのインタフェース

Enterprise Beanの実行

Enterprise Beanの種別ごとに指定できるトランザクション属性

Enterprise Beanの種類

Enterprise Beanの生成とメソッドの呼び出し

Enterprise Beanのプールの管理

Enterprise Beanの呼び出し方法

Enterprise Beanのライフサイクル

Enterprise Beanへのアクセス制御

Enterprise Beanへのアクセス制御の抑止

Enterprise Beanへのアクセス制御の抑止オプション

Enterprise Bean呼び出しの準備

Enterprise JavaBeans

Entity Bean

Entity Bean

Entity Bean（BMP）実装時の注意事項

Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について

Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて

Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて

Entity Bean（CMP）実装時の注意事項

Entity BeanのEJBオブジェクトのタイムアウト

Entity Beanのコミットオプション指定

Entity Beanのプーリング

Entity Beanのライフサイクル

(Ｆ)

Full caching（commit option A）

(Ｇ)

GSInfoKey-RWの定義（統合ユーザ管理・セッションフェイルオーバ機能）

GSInfosLengthMaxの定義（統合ユーザ管理・セッションフェイルオーバ機能）

(Ｈ)

HAモニタ

HAモニタ

HiRDBの場合のバッチ更新

HTTP Cookie情報の破棄

HTTP Cookieによるグローバルセッションの制御

HTTP Cookieによる制御

HTTP Cookieによる制御

HttpSessionオブジェクト

HttpSessionオブジェクト数の上限値の設定

HttpSessionオブジェクトの有効期限が切れた場合の処理

HttpSessionにjava.io.Serializableを継承したSubjectを格納する場合の実装

HttpSessionのセッションIDへのサーバID付加

HTTPステータスコード302のステータスメッセージについて

HTTPリクエスト実行待ちキュー監視

HTTPレスポンス圧縮機能

HTTPレスポンス圧縮機能を使用するDDの定義例

HTTPレスポンス圧縮機能を使用する場合のDDの定義内容

HTTPレスポンス圧縮機能を有効にする場合の条件

HTTPレスポンス圧縮フィルタ

HTTPレスポンス圧縮フィルタに対する制約

HTTPレスポンス圧縮フィルタの概要

HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

HTTPレスポンス圧縮フィルタを使用するための条件

HTTPレスポンスヘッダのカスタマイズ

(Ｉ)

Inbound

Inbound

includeディレクティブでインクルードされるファイルのデフォルトの文字コードについて

includeディレクティブ利用時の注意

IPアドレスの固定

(Ｊ)

J2EE

J2EEアプリケーション

J2EEアプリケーション

J2EEアプリケーション

J2EEアプリケーション開始時の処理

J2EEアプリケーション実行時間の監視

J2EEアプリケーション実行時間の監視機能

J2EEアプリケーション実行時間の監視機能の実装

J2EEアプリケーション情報の取得

J2EEアプリケーション停止処理の流れ

J2EEアプリケーション停止の種類

J2EEアプリケーションとJ2EEコンポーネントの関係

J2EEアプリケーションの入れ替え

J2EEアプリケーションの入れ替え機能

J2EEアプリケーションの運用

J2EEアプリケーションの運用機能の概要

J2EEアプリケーションの強制停止

J2EEアプリケーションの更新検知インターバル

J2EEアプリケーションの更新検知とリロード

J2EEアプリケーションの構成パターンと閉塞方法

J2EEアプリケーションの構成ファイル更新用インターバル

J2EEアプリケーションの構造

J2EEアプリケーションのサービスの閉塞

J2EEアプリケーションの実行機能の概要

J2EEアプリケーションの実行時間を監視する機能

J2EEアプリケーションの状態と入れ替え

J2EEアプリケーションの設定

J2EEアプリケーションの設定の流れ

J2EEアプリケーションの通常停止

J2EEアプリケーションの停止

J2EEアプリケーションのテスト機能

J2EEアプリケーションのテスト機能

J2EEアプリケーションの動作モードの変更

J2EEアプリケーションのリデプロイ

J2EEアプリケーションやリソースアダプタの設定を支援する機能

J2EEアプリケーションを実行する場合のプロセス構成

J2EEコンテナ

J2EEコンテナ

J2EEコンポーネント

J2EEコンポーネント

J2EEサーバ

J2EEサーバ

J2EEサーバ

J2EEサーバ起動時の処理〔セッションフェイルオーバ〕

J2EEサーバ単位の設定

J2EEサーバ停止時のセッション情報の引き継ぎ

J2EEサーバの構成

J2EEサーバの構造

J2EEサーバモード

J2EEサーバモード

J2EEサービス

J2EEサービス

J2EEサービス

J2EEリソース

J2EEリソース

J2EEリソース

J2EEリソースアダプタ

J2EEリソースアダプタ

JAAS

jaas.conf

JAAS対応ユーザ管理

JAASでのユーザ認証の有効期限

JAASのコンフィグレーションファイル

Java

java.servlet.RequestDispatcherクラスのforwardメソッド利用時の注意

JavaBeansリソース属性ファイルの設定

JavaBeansリソースの実装

JavaBeansリソースの実装クラスの作成

Java Database Connectivity

Java Naming and Directory Interface

JavaServer Pages

javax.ejb.EJBContextインタフェースメソッドについての注意事項

javax.servlet.error.XXXXXによるエラー情報参照時の注意

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッドについて

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyedメソッドについて

javax.servlet.jsp.tagext.PageDataクラスのgetInputStreamメソッドで取得できるXMLビュー情報について

javax.servlet.ServletResponseクラスのresetメソッドについての注意

javax.servlet.ServletResponseクラスのsetLocaleメソッドについて

javax.servlet.SingleThreadModelインタフェースの非推奨化について

javax.servlet.UnavailableExceptionについて

Javaアプリケーションからの移行

JavaロギングAPI

JavaロギングAPI

JCAコンテナ

JDBC

JDBC SQLタイプの扱い

JDBC2.0拡張機能で提供する機能のトレースを取得するための情報の指定

JDBC2.0拡張機能の概要

JDBC2.0拡張機能を使用したデータベース接続の設定

JDBC2.0の概要

JDBCドライバの指定

JNDI

JNDI

JNDI

JNDIからの情報の取得

JNDI名前空間

JNDI名前空間の確認方法

JNDIによるEJBホームオブジェクトおよびビジネスインタフェースのリファレンスのルックアップ

JNDIネーミングコンテキストの生成

JNDIへの情報の登録

JNDI連携

JP1

JP1

JP1

JP1/AJS2

JP1/AJS2 - Agent

JP1/AJS2 - Manager

JP1/AJS2 - SO

JP1/AJS2 - SO

JP1/AJS2 - SOとの連携

JP1/AJS2 - View

JP1/AJS2およびBJEXと連携するシステム

JP1/AJS2との連携

JP1/AJS2と連携するシステム

JP1/Cm2/NC - Manager

JP1/Cm2/NC - Manager for Cosminexus

JP1/IM

JP1/IM

JP1/IM - Central Console

JP1/IM - Central Scope

JP1/IM - CM

JP1/IM - CM

JP1/IM - CMとの連携

JP1/IM - View

JP1/IMとの連携

JP1/NETM/Audit

JP1/NETM/Auditとの連携

JP1/SC/DPM

JP1イベント

JP1イベント

JP1イベントとして発行されるCosminexusシステムの障害情報

JP1イベントのフィルタリング設定

JP1ジョブ運用管理サーバ

JP1統合運用管理サーバ

JP1との連携

JP1と連携したシステム構築・運用

JP1連携による運用管理機能の概要

JP1連携による運用管理機能の概要

JSP

JSP 2.0仕様で追加，変更された仕様についての注意事項

JSP EL

JSP EL式の評価APIの複数指定

JSP ELの実行

JSPから生成されるJavaソースのコンパイルについて

JSPコンパイル結果

JSPコンパイル結果

JSPコンパイル結果の出力先

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行していない場合）

JSPコンパイル結果の出力先ディレクトリ構成（JSP事前コンパイルを実行している場合）

JSPコンパイル結果のバージョンチェック

JSPコンパイル結果のライフサイクル

JSPコンパイル結果のライフサイクル

JSP事前コンパイル

JSP事前コンパイル機能とは

JSP事前コンパイル機能の注意

JSP事前コンパイル機能を実施したアプリケーションでのJSPファイルの扱い

JSP事前コンパイル実行時の文字エンコーディングの適用

JSP事前コンパイル時に検証されるweb.xmlの要素

JSP事前コンパイルで実施されるチェック

JSP事前コンパイルの実行時の処理

JSP事前コンパイルの適用場面と使用するコマンドの対応

JSP事前コンパイルの適用例

JSP事前コンパイルの方法

JSP実装時の注意事項

JSPタグライブラリ

JSPタグライブラリ

JSPドキュメントでのHTTPレスポンスの文字コードのデフォルト値について

JSPドキュメント内のversion属性について

JSPドキュメント内の矛盾する文字コードについて

JSPドキュメントのHTTPレスポンスのContentTypeのデフォルト値について

JSPドキュメントのタグライブラリの宣言でtaglibマップに登録されていないuriを記述した場合について

JSPドキュメントのデフォルト拡張子

JSPドキュメントの文字コードについて

JSPトランスレーション下位互換機能

JSPの事前コンパイル

JSPのリロード

JSPファイル更新用インターバル

JSPファイルのコンパイル結果の保持

JSPファイルのコンパイル結果の保持

JSPファイルの再コンパイル

JTAによるトランザクション実装時の注意事項

JTAによるトランザクション実装時の注意事項

(Ｌ)

LoginModuleインタフェースの実装時の留意点

lookupの実装（JavaBeansリソース）

(Ｍ)

Management Server

Management Server

Management Server

Management Server

Management Serverによる運用管理機能

Management Serverによる運用管理機能の概要

Management Serverによる運用管理機能の概要

Managementアクション

Managementアクション

Managementアクションの実行制御

Managementイベント

Managementイベント

Managementイベントによる処理の自動実行

Mandatory属性

Message-driven Bean

Message-driven Bean

Message-driven Bean実装時の注意事項

Message-driven Beanのトランザクション設定時の注意（Connector 1.0に準拠したリソースアダプタを使用する場合）

Message-driven Beanのトランザクション設定時の注意（Connector 1.5に準拠したリソースアダプタを使用する場合）

Message-driven Beanのプーリング

Message-driven Beanのライフサイクル

Message-driven Beanのライフサイクル

MIBオブジェクト

MIBファイル

Microsoft Cluster Service

Microsoft Cluster Service

mngsvrutil

(Ｎ)

N:1リカバリシステム

N:1リカバリシステム

N:1リカバリシステム

N:1リカバリシステム

N:1リカバリシステムのシステム構成例

Never属性

No caching（commit option C）

NotSupported属性

(Ｏ)

Object Transaction Service

Oracle RAC

Oracle RACを使用したOracleへの接続

Oracleの場合のバッチ更新

ORBゲートウェイ

OTMゲートウェイ

OTS

Outbound

Outbound

(Ｐ)

pageディレクティブのisThreadSafe属性の非推奨化について

pageディレクティブのpageEncoding属性の複数回指定について

Persistent Connection

Persistent Connectionによる通信制御

pool状態のEntity Bean

POSTデータサイズでのリクエストの振り分け

POSTデータの読み込み失敗時の動作について

POSTリクエスト転送先ワーカ

POSTリクエスト振り分けワーカ

PreparedStatementクラスでのバッチ更新

PRFデーモン

PRFデーモン

PRFデーモン

PRFデーモン

PRFトレース

PRFトレース出力ライブラリ

PRFトレース出力ライブラリ

PRFトレース取得レベル

PRFトレース取得レベル

PRFトレースファイル

PRFトレースファイル

Principalオブジェクトの実装時の留意点

PrintWriter，JSPWriterクラス利用時の性能向上について

(Ｒ)

ready状態のEntity Bean

Realm

removeメソッドによるリファレンスの解放

Required属性

RequiresNew属性

ResultSetタイプ

ResultSetの拡張

RMI-IIOP

RMI-IIOP通信のタイムアウト

Run as機能

(Ｓ)

SecurityManager

SecurityManagerによるWebコンテナの実行時の保護

SecurityManagerによるWebコンテナの実行時の保護

Server Plug-in

Server Plug-inでの設定

Servlet 2.4仕様で追加，変更された仕様についての注意事項

ServletContextインタフェース利用時の注意

ServletContextオブジェクトに登録する日立独自の属性

ServletRequestインタフェース利用時の注意

ServletRequestクラスのプロキシ取得用メソッドを使用する場合の注意

Servlet仕様で規定された文字エンコーディング（JSPファイル）

Servlet仕様で規定された文字エンコーディング（レスポンス）

Servlet仕様で規定されている文字エンコーディング

Servlet仕様での文字エンコーディング設定

Servlet仕様での文字エンコーディングの設定方法

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.3/JSP 1.2）

Servlet仕様での文字エンコーディングの設定方法（Servlet 2.4/JSP 2.0）

Session Bean

Session Bean

Session Beanのライフサイクル

SessionSynchronizationのインスタンスの破棄についての注意

setEntityContextメソッドでのリソースマネジャへのアクセスについて

setEntityContextメソッドでのリソースマネジャへのアクセスについて

setSessionContextメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

SFOサーバ

SFOサーバ

SFOサーバ

SFOサーバアプリケーション

SFOサーバアプリケーション

SFOサーバ停止時のセッション情報の引き継ぎ

SFOサーバでのJ2EEサーバの切断検知

SFOサーバでのグローバルセッション情報の管理

SFOサーバに障害が発生した場合のHttpSessionオブジェクトの最大数

SFOサーバに障害が発生した場合のグローバルセッション情報

SFOサーバの障害発生時のグローバルセッションIDの発行

SFOサーバの障害発生時のセッション情報の引き継ぎ

SFOサーバの複数配置

SFOサーバを複数配置するときの推奨構成

Smart Composer機能

Smart Composer機能

Smart Composer機能でのWebシステム構築

Smart Composer機能による設定の流れ

Smart Composer機能を使用したシステム構築の特長

SMTPサーバとの接続

snapshotログ

snapshotログ

snapshotログの収集

SNMP連携用形式ファイル

SSL使用による認証情報とデータの暗号化

SSLで使用された証明書情報の取得

Stateful Session Bean

Stateful Session Bean

Stateful Session Bean実装時の注意事項

Stateful Session Beanのタイムアウト

Stateful Session Beanのライフサイクル

Stateless Session Bean

Stateless Session Bean

Stateless Session Bean実装時の注意事項

Stateless Session Beanに対するリモートインタフェース呼び出し

Stateless Session Beanのプーリング

Stateless Session Beanのライフサイクル

Statementクラスでのバッチ更新

Supports属性

(Ｔ)

Timer Service

Timer Service

Timer Serviceを使用するアプリケーションの実装

TP1/Message Queue - Accessによる接続

(Ｕ)

ua.conf

uCosminexus Batch Job Execution Server

uCosminexus Client

uCosminexus Clientの機能概要

uCosminexus Operator

uCosminexus Operatorの機能概要

uCosminexus TP1 Connectorによる接続

Unicodeの補助文字の送受信に関する注意

URI取得時の注意

URLConnectionクラス使用時の注意

URLConnectionクラス使用時の注意

URL書き換えによる制御

URL書き換えによる制御の前提条件

URL書き換えによる制御をする場合のアプリケーションの実装

URL書き換えを実行するServlet APIの引数ごとの戻り値

URLグループ単位での同時実行スレッド数の制御

URLグループ単位の最大同時実行スレッド数

URLグループ単位の実行待ちキュー

URLグループ単位の設定パラメタ

URLグループ単位の占有スレッド数

URL指定とマッピング定義によるアクセスについて

URLパターンでのリクエストの振り分け

URLパターンによるリクエストの振り分け

URLパターンの種類と適用されるパターンの優先順位

URLパターンの設定

URLパターンのマッピング処理

UserTransactionインタフェースを使用する場合の処理概要と留意点

usrconf.properties

(Ｗ)

WARファイル

Web Redirectorの機能概要

WebCertificateLoginModule

WebPasswordJDBCLoginModule

WebPasswordLDAPLoginModule

WebPasswordLoginModule

WebSSOLoginModule

Webアプリケーション

Webアプリケーション

Webアプリケーション

Webアプリケーションアンデプロイ時の注意

Webアプリケーション開発でのJSP事前コンパイルの適用例

Webアプリケーション単位での同時実行スレッド数の制御

Webアプリケーション単位の設定

Webアプリケーション単位の設定パラメタ

Webアプリケーションでのアノテーション指定

Webアプリケーションに含まれるディレクトリにアクセスするときの注意

Webアプリケーションのアノテーション参照抑止

Webアプリケーションのアンデプロイ〔サーブレットエンジンモード〕

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定していない場合）

Webアプリケーションの共有スレッド数（URLグループ単位の同時実行スレッド数制御を設定している場合）

Webアプリケーションの更新検知とリロード

Webアプリケーションのサービスの部分閉塞による入れ替え

Webアプリケーションのサービスの閉塞と閉塞解除

Webアプリケーションの最大同時実行スレッド数

Webアプリケーションの実行

Webアプリケーションの実行

Webアプリケーションの実行待ちキューサイズ

Webアプリケーションの占有スレッド数

Webアプリケーションのデプロイ

Webアプリケーションのデプロイとアンデプロイ

Webアプリケーションの閉塞処理

Webアプリケーションのリロード

Webアプリケーションのリロード

Webアプリケーションのリロード時のセッション情報の引き継ぎ

Webアプリケーションのリロード遅延実行

Webアプリケーションのリロードの条件

Webアプリケーション呼び出し時のモードの判別

Webアプリケーションを実行する場合の留意事項

Webクライアントからの接続数とリクエスト処理スレッド数の制御

Webクライアントからの接続数の制御

Webクライアントからの同時接続数の制御

Webコンテナ

Webコンテナ

Webコンテナ

Webコンテナが返すエラーステータスコード

Webコンテナが提供する機能の概要

Webコンテナコネクションプール機能の利用方法

Webコンテナサーバ

Webコンテナサーバ

Webコンテナ単位での同時実行スレッド数の制御

Webコンテナでのリクエスト受信時

Webコンテナでのレスポンス送信時

Webコンテナによるコネクション自動クローズ

Webコンテナによるスレッドの作成

Webコンテナの機能

Webコンテナの共有スレッド数

Webコンテナのセキュリティ管理

Webコンテナのセキュリティ管理

Webコンテナへのゲートウェイ情報の通知

Webサーバ

Webサーバ

Webサーバ（リダイレクタ）によるリクエストの振り分け

Webサーバでのリクエスト受信時

Webサーバでのレスポンス送信時

Webサーバの認証機能

WebサーバまたはJ2EEサーバの障害発生時のセッション情報の引き継ぎ

Webサーバ連携

Webサーバ連携時の留意事項

Webシステム

Webシステムの構成情報の収集

(Ｘ)

X-Powered-Byヘッダの利用

(ア行)

(あ)

アーカイブ形式

アーカイブ形式のJ2EEアプリケーション

アーカイブ形式のJ2EEアプリケーション

アウトプロセス

アクセスを許可するホストの制限によるアクセス制御

アセンブル

アセンブル

アダプタコマンド

アノテーション

アノテーション

アノテーション参照抑止機能

アノテーション使用時の注意事項（Enterprise Bean）

アノテーションのサポート範囲

アプリケーションからリソースに接続する手順

アプリケーション強制停止コマンド

アプリケーションサーバ

アプリケーションサーバ

アプリケーションサーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

アプリケーションサーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

アプリケーションサーバの機能（J2EEアプリケーションを実行する場合）

アプリケーションサーバの機能（バッチアプリケーションを実行する場合）

アプリケーション実行基盤としての機能

アプリケーション制御用カスタムジョブ

アプリケーションで扱う文字コード

アプリケーションディレクトリ

アプリケーションディレクトリの構成

アプリケーションディレクトリの変更

アプリケーションの移行が必要な場合

アプリケーションのイベントリスナ

アプリケーションのイベントリスナ

アプリケーションの開発で使用する文字コード

アプレット

暗号拡張

アンデプロイ処理

(い)

一次送付資料

一覧表示コマンド

イベントの発行

イベントリスナ

インスタンス取得待ちのタイムアウト

インプロセス

インプロセスHTTPサーバ

インプロセスHTTPサーバ

インプロセスHTTPサーバが返すエラーステータスコード

インプロセスHTTPサーバで使用できる機能

インプロセスHTTPサーバで設定できる通信タイムアウト

インプロセスHTTPサーバによるエラーページのカスタマイズ

インプロセスHTTPサーバによるリクエストの受け付け

インプロセストランザクションサービス

(う)

運用監視エージェント

運用管理エージェント

運用管理エージェント

運用管理エージェント

運用管理コマンド

運用管理サーバ

運用管理サーバ

運用管理サーバの1:1系切り替えシステムでの計画系切り替えの処理の流れ

運用管理サーバの1:1系切り替えシステムでの自動系切り替えの処理の流れ

運用管理サーバモデル

運用管理サーバモデル

運用管理ドメイン

運用管理ドメイン

運用管理ドメインで管理できる論理サーバ

運用管理ドメインで管理できる論理サーバ

運用管理ポータル

運用管理ポリシー

(え)

エイリアスIPアドレス

エラー時のJDBCドライバの処理

エラーページカスタマイズの注意事項

エラーページのカスタマイズ

エラーページのカスタマイズ

エラーページのカスタマイズ

エラーページのカスタマイズ

エラーページのカスタマイズの仕組み

(お)

オプション製品の機能

(カ行)

(か)

ガーベージコレクション制御機能

ガーベージコレクション制御機能とは

ガーベージコレクション制御機能の概要

ガーベージコレクション制御の処理の流れ

下位互換用のクラスローダ構成

回復機能

外部リソースとの接続

書き換え可能グローバルセッション情報

カスタムジョブ

カスタムジョブ

カスタムジョブによるジョブの定義〔JP1/AJS2連携〕

カスタムログインモジュール

カスタムログインモジュール

カスタムログインモジュール

カスタムログインモジュールの実装

カスタムログインモジュールの実装時の留意点

カスタムログインモジュールの実装例

カスタムログインモジュールのセッション

カスタムログインモジュールの呼び出し

仮想サーバ

稼働情報収集機能

稼働情報の監視（稼働情報収集機能）

稼働情報の監視機能

稼働情報ファイルの出力

簡易Webサーバ

簡易Webサーバ機能

簡易Webサーバ機能

簡易構築定義ファイル

環境構築支援のための機能

監査証跡

監査に必要な，操作や処理の履歴を記録する機能

監査ログ

監査ログ

監査ログの一元管理

監査ログの収集

監査ログの収集および一元管理

監査ログを使用したシステムの監査

監視基盤

監視ツリー

監視ツリーの自動生成〔JP1/IM連携〕

管理対象オブジェクト（AdminObject）

(き)

既存のバッチアプリケーションから移行する場合

機能レイヤ

機能レイヤ

キャッシュクリアのタイミング

キャッシュのクリア

キャッシングの流れ

キュー

旧バージョンとの互換用の機能

キュー名称

強制停止

強制停止で実行される処理

共通で使用する外部のライブラリ（Extension）について

業務指向ツリー

業務指向ツリー

業務処理プログラム

共有スレッド数

共有スレッド数

共有スレッド数の算出のしかた

(く)

クエリ文字列の解析について

クライアントアプリケーション情報

クライアントアプリケーション情報

クライアント認証〔Webサーバの機能〕

クラスタ

クラスタ

クラスタソフトウェア

クラスタソフトウェアとの連携

クラスタソフトウェアとの連携による系切り替え機能の概要

クラスタソフトウェアとの連携による系切り替え機能の概要

クラスタソフトウェアと連携してできる運用

クラスローダに設定されるクラスパス

クラスローダの構成

クラスローダの取得に関する注意

クラスローダの取得に関する注意

グローバルCORBAネーミングサービス

グローバルCORBAネーミングサービス

グローバルCORBAネーミングサービス

グローバルCORBAネーミングサービス

グローバルセッション

グローバルセッション

グローバルセッションID

グローバルセッションID

グローバルセッションIDの形式

グローバルセッションIDを送信するHTTP Cookieの名称

グローバルセッション情報

グローバルセッション情報

グローバルセッション情報

グローバルセッション情報の格納

グローバルセッション情報の更新

グローバルセッション情報のサイズ見積もり機能

グローバルセッション情報の削除

グローバルセッション情報の種別

グローバルセッション情報のロック

グローバルセッションの制御方法

グローバルトランザクション

グローバルトランザクション

(け)

系

系

計画系切り替え

計画系切り替え

計画系切り替え

計画系切り替えの処理の流れ

計画系切り替えの処理の流れ

系切り替え

系切り替え時のシステムの動作

系切り替え時の情報の引き継ぎ

系切り替えの処理の流れ

系切り替えのタイミング

系切り替えの動作

系障害

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能

ゲートウェイ指定機能を使用する場合の注意

ゲートウェイ使用時の注意

検索データ取得時のデータ変換

現用系

現用系

(こ)

更新検知によるリロード

更新検知のインターバル

更新検知のインターバル

更新検知の対象となるファイル

構築済み実行環境の切り替えの概要

構築済み実行環境の切り替えの流れ

構築済み実行環境を切り替える場合の注意

コネクションアソシエーション

コネクション枯渇時のコネクション取得待ち

コネクションシェアリング

コネクションシェアリング・アソシエーション

コネクションスイーパ

コネクションスイーパ

コネクション数調節機能

コネクション定義識別子

コネクションの自動クローズ

コネクションの取得リトライ

コネクションの障害検知

コネクションのレギュレート

コネクションプーリング

コネクションプーリング

コネクションプール監視

コネクションプールのウォーミングアップ

コネクションプールのクリア

コネクションプールの情報表示

コマンドによるリロード

コミットオプション

コミット後のエラーページの表示に関する注意

コンテキスト

コンテキストルート

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項

コンテナ拡張ライブラリが提供する機能の概要

コンテナ拡張ライブラリが提供する機能の概要

コンテナ拡張ライブラリの利用

コンテナ拡張ライブラリの利用の指針

コンテナ管理サインオン

コンテナ管理でのサインオン

コンテナ管理のトランザクション（CMT）を使用する場合の処理概要と留意点

コンテナセキュリティとアクセス権管理

コンパイル結果の削除

コンパイル結果の削除

コンパイル結果の生成

コンパイル結果の生成

コンパイル結果の保持

コンポーネント管理サインオン

コンポーネント管理でのサインオン

(サ行)

(さ)

サーバID付加機能

サーバ管理コマンド

サーバ管理コマンドでの設定

サーバ起動・停止フック機能

サーバ起動・停止フック機能

サーバ起動・停止フック機能

サーバ起動・停止フック機能の実装

サーバ起動・停止フック機能の実装方法

サーバ起動・停止フック機能利用時のクラスパスの指定

サーバ起動・停止フック処理の呼び出し順序

サーバ指向ツリー

サーバ指向ツリー

サーバ認証〔Webサーバの機能〕

サーバの動作モード

サービスの部分閉塞ができるシステム構成

サービスの部分閉塞の方法

サービス閉塞

サービス閉塞

サービス閉塞の解除

サービス閉塞の方法

サービス閉塞の方法と表示されるエラーページ

サービスユニット

サービスユニット

サービスユニットのステータス監視

サーブレット

サーブレットエンジンモード

サーブレットエンジンモード

サーブレットエンジンモードでのリソース接続

サーブレット実装時の注意事項

サーブレットのinitメソッドおよびserviceメソッドの実行のタイミング

サーブレットのサービスメソッド実行中のHttpSessionのタイムアウト

サーブレットフィルタ

サーブレットマッピング

最大同時実行スレッド数

削除機能

作成されるスレッドの種類と数

作成されるスレッドの総数

作成するスレッドの種類と数

作成するスレッドの総数

(し)

システム運用時に使用する機能の概要

システム運用時に使用する機能の概要

システム運用でのJSP事前コンパイルの適用

システム構築時に使用する機能の概要

システム構築時に使用する機能の概要

システム提供の障害検知時コマンド

システムの運用を支援する機能

システムの監査

システムの監査を支援する機能の概要

システムの監査を支援する機能の概要

システムの起動・停止機能

システムの構成定義および管理

システムの構成定義および管理に必要なプログラム〔JP1/IM - CM連携〕

システムの構成定義および管理の概要〔JP1/IM - CM連携〕

システムの構築を支援する機能

システムの集中監視

システムの集中監視に必要なプログラム〔JP1/IM連携〕

システムの日常運用を支援する機能の概要

システムの日常運用を支援する機能の概要

システムの保守を支援する機能の概要

システムの保守を支援する機能の概要

システム例外発生時のトランザクションの動作

実行環境の移行が必要な場合

実行系

実行系

実行待ちキュー

実行待ちキューサイズ

実パラメタ

指定できるアノテーション

自動系切り替え

自動系切り替え

自動系切り替え

自動系切り替えの処理の流れ

自動系切り替えの処理の流れ

シナリオ

シナリオテンプレート

シナリオテンプレートによるシナリオの定義〔JP1/AJS2 - SO連携〕

シナリオによるシステムの自動運転

シナリオによるシステムの自動運転に必要なプログラム〔JP1/AJS2 - SO連携〕

シナリオによるシステムの自動運転の概要〔JP1/AJS2 - SO連携〕

受信バッファのプーリング

障害検知時コマンドによる資料取得

障害検知の方法

障害検知を実施するタイミング

障害調査用SQL

障害調査用SQLの出力

障害の監視〔JP1/IM連携〕

詳細レベル

使用するJDBCドライバの設定

常駐スレッド数の平均化

ジョブ

ジョブ

ジョブによるシステムの自動運転

ジョブによるシステムの自動運転に必要なプログラム〔JP1/AJS2連携〕

ジョブによるシステムの自動運転の概要〔JP1/AJS2連携〕

ジョブネット

ジョブネット

新規にバッチアプリケーションを作成する場合

シングルサインオン

シングルサインオン

シングルサインオン情報リポジトリ

シングルサインオン情報リポジトリ

シングルサインオンライブラリ

シングルサインオンライブラリ

(す)

スクロール型ResultSet使用時の注意点

スクロールタイプ

スケールアウト

スケールイン

スケジュールキュー

スケジュールキュー

スケジュールキュー

スケジュールキュー監視機能

スケジュールキュー滞留監視式

スケジュールキューで制御されるリクエスト

スケジュールキューの強制閉塞

スケジュールキューの構成

スケジュールキューの構成とキューの共有

スケジュールキューのタイムアウト閉塞

スケジュールキューの長さ

スケジュールポリシー

スケジュールポリシー

ステーショナリIPアドレス

ステータスの監視

ステートメントキャンセル

ステートメントキャンセル

ステートメントプーリング

スマートエージェント

スマートエージェントが使用する通信ポート

スマートエージェント経由でのCORBAオブジェクトの呼び出し

スレッド監視

スレッド数を制御する単位

スレッドダンプ監視

スレッドの使用

スレッドプーリング

スレッドプール

(せ)

静的コンテンツ

静的コンテンツのキャッシュ

静的コンテンツやリクエストのエラー処理に使用されるスレッド数

性能解析トレース

性能解析トレース

性能解析トレースの利用によるJ2EEアプリケーションの動作モードの確認

性能解析トレースのルートアプリケーション情報の取得のための実装

性能解析トレースファイル

性能解析トレースファイル

セキュリティアイデンティティ

セキュリティアイデンティティ

セキュリティアイデンティティを使用した認証

セキュリティ管理

セッション

セッションID

セッションIDおよびCookieへのサーバIDの付加

セッション管理

セッション情報

セッション情報の引き継ぎ処理

セッション情報ファイル

セッション情報を管理するオブジェクト

セッション数監視

セッションタイムアウト時のログアウト（セッションフェイルオーバ機能使用時）

セッションの種類

セッションフェイルオーバ機能

セッションフェイルオーバ機能

セッションフェイルオーバ機能使用時のユーザ認証の実装

セッションフェイルオーバ機能で引き継げるセッション情報と認証情報

セッションフェイルオーバサーバ

セッションフェイルオーバ用フィルタに対する制約

セッションフェイルオーバ用フィルタの処理

接続するデータベースの設定

接続できるデータベース

接続できるリソース

接続できるリソース

接続できるリソースとトランザクションの管理方法

接続テスト機能

接続プール

設定できる文字エンコーディング

セットアップウィザード

セットアップウィザード

前提条件

前バージョンからのJSPの移行

占有スレッド数

占有スレッド数

占有スレッド数と最大同時接続数

(そ)

相互系切り替えシステム

相互系切り替えシステム

相互系切り替えシステム

相互系切り替えシステムでの計画系切り替えの処理の流れ

相互系切り替えシステムでの系切り替えの動作

相互系切り替えシステムでの自動系切り替えの処理の流れ

相互スタンバイ

属性の変更に対するイベント通知時の注意

(タ行)

(た)

待機系

待機系

退避環境

退避環境一覧出力機能

退避機能

タイムアウトメソッド

タイムアウトを設定できるRMI-IIOP通信

タグファイルのJavaソースファイルとクラスファイルの出力先

タグファイルの実行

タグライブラリ・ディスクリプタ（TLDファイル）の配置について

タグライブラリ利用時の注意

タグライブラリを使用したユーザ認証の実装

(ち)

抽象パラメタ

(つ)

通常停止

通常モード

通信タイムアウト設定時の注意事項

通信タイムアウトの設定

通信タイムアウトの設定方法

通信ポートの固定

通信路のセキュリティレベルの要請

(て)

停止処理

データ型の対応

データソース

データソースによるデータベースへの接続で使用できる機能

データベース監査証跡

データベース監査証跡連携機能

データベース接続の前提条件

データベース接続の前提条件

データベースとアプリケーション間の文字コード変換

データベースとの接続

データベースとの接続

データベースとの連携

データベースへの接続

データベースへの接続

適用個所

適用条件

テストモード

テストモード

テストモードでのEnterprise Bean呼び出しについての注意事項

テストモードでのJ2EEアプリケーション呼び出し時の注意事項

テストモードでのWebアプリケーション呼び出しについての注意事項

デフォルトインターセプタ

デフォルトのクラスローダ構成

デフォルトの文字エンコーディング設定

デフォルトの文字エンコーディング適用時の注意事項

デフォルトの文字エンコーディングの設定単位

デフォルトの文字エンコーディングの適用個所と適用条件

デフォルトマッピング

デフォルトワーカ

デプロイ

デプロイ

展開ディレクトリ形式

展開ディレクトリ形式のJ2EEアプリケーション

展開ディレクトリ形式のJ2EEアプリケーション

(と)

統計情報の取得

統合機能メニュー

統合機能メニューからの運用管理ポータルの表示〔JP1/IM連携〕

統合コンソール

統合コンソール

統合コンソール

統合コンソール

統合スコープ

統合スコープ

統合スコープ

統合ネーミングスケジューラサーバ

統合ネーミングスケジューラサーバモデル

統合ユーザ管理

統合ユーザ管理

統合ユーザ管理GUI

統合ユーザ管理のコンフィグレーションファイル

統合ユーザ管理のセッション

統合ユーザ管理フレームワーク

統合ユーザ管理フレームワーク

統合ユーザ管理フレームワーク

統合ユーザ管理フレームワークと個別のユーザ管理の関連

統合ユーザ管理フレームワークによるユーザ認証の実装の概要

統合ユーザ管理フレームワークのライブラリ

動作モード

同時実行スレッド数および実行待ちキューサイズの設定例

同時実行スレッド数および実行待ちキューサイズの設定例（URLグループ単位）

同時実行スレッド数制御の注意事項

同時実行スレッド数制御のパラメタ

同時実行スレッド数の制御

同時実行スレッド数の制御

同時実行スレッド数の制御の概要（URLグループ単位）

同時実行スレッド数の制御の概要（Webアプリケーション単位）

同時実行スレッド数の動的変更

動的コンテンツ

動的変更の注意

特別な意味を持つ入力値の表示に関する注意

ドメイン名指定でのトップページの表示

ドメイン名指定でのトップページの表示

トランザクション管理機能の実装

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

トランザクションサービスで提供する機能

トランザクションサポートレベル

トランザクション属性の種類

トランザクションタイムアウト

トランザクションタイムアウトの設定単位

トランザクションとJDBCコネクション利用時の注意

トランザクションの管理方法

トランザクションの管理方法

トランザクションの種類

トランザクションマネジャ

トランザクションリカバリ

トランザクションリカバリ用通信ポート

トランザクションを使用しない場合の処理概要と留意点

トレース取得ポイント

トレース取得ポイント

トレース取得ポイント

トレース情報のキー情報

トレース情報の取得・収集機能

トレース情報の取得によるトラブルシュート

トレース情報の利用方法

トレースを取得するための情報の設定

(ナ行)

(に)

二次送付資料

入出力ストリーム利用時の注意

認証機能を併用するときの注意

認証処理

(ね)

ネイティブライブラリのロードに関する注意

ネイティブライブラリのロードに関する注意

ネーミング管理

ネーミング管理

ネーミング管理

ネーミング管理が提供する機能

ネーミング管理が提供する機能の概要

ネーミング管理が提供する機能の概要

ネーミング管理機能でのキャッシング

ネーミング切り替え

ネーミングサービス

ネーミングサービス

ネーミングでのキャッシングの注意事項

(ハ行)

(は)

バインド先アドレス設定機能

バインド先アドレス設定機能

パスワード認証時の暗号拡張の実装

パッケージ名の指定に関する注意

バッチアプリケーション

バッチアプリケーション

バッチアプリケーション作成時の注意

バッチアプリケーション実行環境の概要

バッチアプリケーション実行機能

バッチアプリケーション実行機能の概要

バッチアプリケーション実行機能の概要

バッチアプリケーション実行の流れ

バッチアプリケーションで実装できない機能

バッチアプリケーションで使用するコマンドの実行について

バッチアプリケーションに実装できる処理

バッチアプリケーションの開始

バッチアプリケーションの開始方法

バッチアプリケーションの強制停止

バッチアプリケーションの強制停止に失敗した場合に備えて

バッチアプリケーションの強制停止の方法

バッチアプリケーションの作成規則

バッチアプリケーションの実行

バッチアプリケーションの実行環境の運用

バッチアプリケーションの実行環境の構築

バッチアプリケーションの実行方法

バッチアプリケーションの終了

バッチアプリケーションのファイル形式

バッチアプリケーションのライフサイクル

バッチアプリケーションのログ出力

バッチアプリケーションを実行するクラスローダ

バッチアプリケーションを実行するシステム

バッチアプリケーションを実行する場合のプロセス構成

バッチ更新

バッチサーバ

バッチサーバ

バッチサーバ

バッチサーバで提供する機能

バッチサーバの構成

バッチサーバの構造

バッチサービス

バッチ処理の開始と終了

パフォーマンスチューニングのための機能

パフォーマンストレーサ

パフォーマンストレーサ

パフォーマンストレーサ

ハンドラ

ハンドラ

(ひ)

ビジネスインタフェース

ビジネスインタフェースに対応する機能

ビジネスインタフェースのEnterprise Bean呼び出し

ビジネスインタフェースのリファレンスを検索してEnterprise Beanを呼び出す方法

日立トレース共通ライブラリ

日立トレース共通ライブラリ

日立トレース共通ライブラリ形式

非保護区

非保護区

ビューアー

ビューアー

ビューアー

標準レベル

(ふ)

ファイアウォール環境での運用のための機能

ファイルアクセス時の注意

ファイルディスクリプタ監視

ファイルやディレクトリの操作

フィルタリングによるHTTPレスポンスの圧縮

フィルタ連鎖の推奨例

フォールトトレランスのための機能

負荷状況の監視

負荷分散

負荷分散機

負荷分散機

負荷分散機を使用したシステム構成でのサービス閉塞

負荷分散のタイミング

複数のWebアプリケーションのデプロイ

複数の構築済み実行環境の切り替え

複数の範囲で文字エンコーディングを設定している場合の動作

物理コネクション

物理コネクション

物理ティア

プライマリキークラスへのインタフェース指定について

プライマリキークラスへのインタフェース指定について

ブラウザとアプリケーション間の文字コード変換

プログラムセキュリティ

プロセス内で複数回実行してはならない処理を実装する場合の注意

フロントEJB

フロントEJBの閉塞処理

分散トランザクション機能

(へ)

並行処理タイプ

閉塞処理

閉塞制御

ベーシックモード

ベーシックモード

ベーシックモードでのSessionSynchronizationのメソッド呼び出しについての注意

ベーシックモードでのリソース接続

別名

(ほ)

ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法

ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法

ほかのプログラムと連携する機能

ほかのプログラムと連携する機能の概要

ほかのプログラムと連携する機能の概要

保護区

保護区

保守員

保守レベル

ホスト単位管理モデル

ホスト単位管理モデル

(マ行)

(ま)

マッピングの順序

マルチバイト文字の使用について

(み)

未決着トランザクション

(む)

無効なグローバルセッションIDが送られた場合の処理

(め)

メソッドキャンセル機能

メソッドキャンセル機能

メソッドキャンセルコマンド

メソッドキャンセル実行のタイミング

メソッドキャンセル時の動作

メソッドキャンセルとは

メソッドキャンセルの処理

メソッドキャンセルを利用するアプリケーション開発時の注意事項

メソッドタイムアウト機能

メソッドタイムアウト機能

メソッドタイムアウトとは

メソッドタイムアウト発生時のオプションメッセージの設定

メッセージインフロー

メッセージインフロー

メモリ監視

面数

メンバリソースアダプタ

(も)

文字エンコーディング設定の組み合わせと有効になる設定

文字エンコーディングの検証のタイミング

文字エンコーディングの設定範囲

文字コード変換

(ヤ行)

(ゆ)

有効なHTTPメソッドの制限によるアクセス制御

ユーザIDの取得（APIを使用する場合）

ユーザIDの取得（タグライブラリを使用する場合）

ユーザサーバ

ユーザサーバ

ユーザ作成クラス

ユーザ作成の障害検知時コマンド

ユーザ指定名前空間機能

ユーザ指定名前空間機能

ユーザ指定名前空間機能

ユーザ指定名前空間で付与した名前でのルックアップ

ユーザ情報

ユーザ情報の管理（Webコンテナ）

ユーザ情報リポジトリ

ユーザ情報リポジトリ

ユーザスレッド

ユーザスレッド

ユーザスレッドで使用できるApplication Serverの機能

ユーザスレッドの使用方法

ユーザ属性の取得（APIを使用する場合）

ユーザ属性の取得（タグライブラリを使用する場合）

ユーザ定義型のCMPフィールドの使用についての注意

ユーザ認証ライブラリ

ユーザ認証ライブラリ

ユーザ認証リポジトリ

ユーザプロパティファイル

ユーザプロパティファイル

ユーザマッピング

ユーザマッピング

ユーザマッピング

ユーザログ

ユーザログ

ユーザログ機能

ユーザログ出力処理の流れ

ユーザログ出力で使用するLoggerクラスのメソッド

ユーザログ出力で使用するメソッド

(よ)

抑止レベル

予備系

予備系

読み込み専用グローバルセッション情報

(ラ行)

(ら)

ライトトランザクション

ライトトランザクション

ライトトランザクション機能

ライブラリJAR

ライブラリJAR

ラウンドロビン検索

ラウンドロビン検索

ラウンドロビン検索の動作

ラウンドロビン検索の範囲

ラウンドロビン方式でのリクエストの振り分け

ラウンドロビンポリシー

ラウンドロビンポリシーによるCORBAネーミングサービスの検索

(り)

リカバリ専用サーバ

リクエストおよびレスポンスのフィルタリング

リクエスト実行時の処理

リクエスト受信時の通信タイムアウト設定

リクエスト処理スレッド

リクエスト処理スレッド数の制御

リクエスト処理スレッド数の遷移例

リクエスト送受信時の通信タイムアウト

リクエスト送信処理のリトライ

リクエストデータのサイズの制限によるアクセス制御

リクエスト転送時のタイムアウト

リクエストのスケジューリング

リクエストの転送パターン

リクエストの振り分け方法

リクエストの優先制御

リクエストの流量制御

リスナで例外が発生した場合の制御について

リソースアダプタ

リソースアダプタ固有のトランザクション管理インタフェースを使用する場合の処理概要と留意点

リソースアダプタの使用方法

リソースアダプタの設定

リソースアダプタの設定の流れ

リソースアダプタのライフサイクル管理

リソースアダプタのワーク管理

リソースアダプタやJ2EEアプリケーションの設定

リソースアダプタやJ2EEアプリケーションの設定で使用する構築支援機能

リソース更新用インターバル

リソース接続でのトランザクション管理の方法

リソース接続とトランザクション管理が提供する機能の概要

リソース接続とトランザクション管理が提供する機能の概要

リソース接続とトランザクション管理の概要

リソース接続とトランザクション管理の概要

リソース接続への接続方法

リソースに接続するための実装

リソースに接続するバッチアプリケーションの作成

リソースに接続するバッチアプリケーションの注意

リソースの枯渇監視

リソースのコネクションの取得と解放

リソースへのサインオン方式

リソースへの接続テスト

リソースへの接続テスト

リソースへの接続方法

リソースへの接続方法

リソースマネジャ

リダイレクタ

リダイレクタ

リダイレクタが返すエラーステータスコード

リダイレクタでのリクエスト送信時

リダイレクタでのレスポンス受信時

リダイレクタによるリクエスト振り分けの例

リダイレクタを使用したリクエスト振り分けの仕組み

リダイレクトによるリクエストの振り分け

リデプロイ機能

リバースプロキシサーバ

リポジトリ（LDAPディレクトリサーバ）の接続フェイルオーバ

リポジトリ管理

リモートインタフェース

リモートインタフェース

リモートインタフェース

流量制御

利用できる運用管理機能

利用できる運用管理機能

リロード機能

リロード時のクラスローダの構成

リロード時のセッション引き継ぎ

リロード処理の流れ

リロード遅延実行

リロードの適用範囲

(る)

ルートアプリケーション情報

ルートアプリケーション情報

ルートコンテキスト

ルートリソースアダプタ

ルックアップを使用したUserTransactionの取得方法

(れ)

例外発生時のエラーページの設定について

レギュレート

レスポンス送受信時の通信タイムアウト設定

レスポンス送受信時の通信タイムアウト設定

レスポンス送信時に使用されるサーブレットのバッファ

レスポンスのカスタマイズ

レルム

レルム

レルム

レルム名

(ろ)

ローカルインタフェース

ローカルインタフェース

ローカルインタフェース

ローカルインタフェースとリモートインタフェースの使い分け

ローカルトランザクション

ローカルトランザクション

ローカル呼び出し最適化機能の利用について

ローカル呼び出し最適化時のクラスローダ構成

ロードバランサ

ロードバランサ

ロール

ロールに基づくWebコンテナのユーザ認証

ロガー

ロガー

ログ・トレースの出力

ログアウト（APIを使用する場合）

ログアウト（セッションフェイルオーバ機能使用時）

ログアウト（タグライブラリを使用する場合）

ログイン（APIを使用する場合）

ログイン（セッションフェイルオーバ機能使用時）

ログイン（タグライブラリを使用する場合）

ログインしているかどうかを確認する方法

ログイン状態のチェック（セッションフェイルオーバ機能使用時）

ログイン方法の設定 〔JP1/IM連携〕

ログインモジュール

ログ運用および障害検知に使用する機能

ログのフォーマット

ロケール設定時の注意

ロック待ち

論理CTM

論理CTMドメインマネジャ

論理J2EEサーバ

論理J2EEサーバ

論理SFOサーバ

論理Webサーバ

論理コネクション

論理コネクション

論理サーバ

論理サーバ

論理サーバおよびJ2EEアプリケーションの起動と停止の自動化〔JP1/AJS2連携〕

論理サーバ制御用カスタムジョブ

論理サーバのステータス監視

論理スマートエージェント

論理ネーミングサービス

論理ネーミングサービス

論理パフォーマンストレーサ

論理パフォーマンストレーサ

論理ユーザサーバ

論理ユーザサーバ

(ワ行)

(わ)

ワーカ定義ファイル

ワーカプロセス

ワーカプロセス

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国における米国International Business Machines Corp.の登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
BIG-IP，3-DNS，iControl Services Manager，FirePass　および F5 は F5 Networks Inc の商標，または登録商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
gzipは，米国FSF(Free Software Foundation)が配布しているソフトウェアです。
HP-UXは，米国Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Intelは，Intel Corporationの会社名です。
Internet Explorerは，米国Microsoft Corporationの米国及びその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国および他の国におけるインテル コーポレーションまたはその子会社の登録商標です。
Java 及びすべてのJava関連の商標及びロゴは，米国及びその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JavaScriptは，米国およびその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JDKは，米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Linuxは，Linus Torvaldsの米国およびその他の国における登録商標あるいは商標です。
Microsoftは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corp.の商品名称です。
Microsoft Office Excelは，米国 Microsoft Corporation の商品名称です。
Microsoft SQL Serverは，米国Microsoft Corp.の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，米国Oracle Corporationの登録商標です。
Oracleは，米国Oracle Corporation及びその子会社，関連会社の登録商標です。
Oracle8iは，米国Oracle Corporationの商標です。
Oracle9iは，米国Oracle Corporationの商標です。
Oracle 10gは，米国Oracle Corporationの商標です。
PA-RISCは，米国Hewlett-Packard Companyの商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
SQL Serverは，米国法人Sybase，Inc.の商標です。
Sun，Sun Microsystems，Javaは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Sun Microsystemsは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
UNIXは，X/Open Company Limited が独占的にライセンスしている米国ならびに他の国における登録商標です。
Windowsは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Windows Serverは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
Windows Vistaは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
X/Openは，X/Open Company Limited の英国ならびに他の国における登録商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，米国Sun Microsystems,Inc.が著作権を有している部分が含まれています。
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，UNIX System Laboratories,Inc.が著作権を有している部分が含まれています。