Cosminexus アプリケーションサーバ V8

機能解説 拡張編

解説書

3020-3-U08-40

目　　次

前書き

変更内容

はじめに

1.　アプリケーションサーバの機能

1.1　機能の分類

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

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

1.1.3　機能とマニュアルの対応

1.2　システムの目的と機能の対応

1.2.1　バッチアプリケーション実行時に使用する機能

1.2.2　CTMによるEnterprise Beanのスケジューリング機能

1.2.3　そのほかの拡張機能

1.3　このマニュアルに記載している機能の説明

1.3.1　分類の意味

1.3.2　分類を示す表の例

1.4　アプリケーションサーバ 08-70での主な機能変更

2.　バッチサーバによるアプリケーションの実行

2.1　この章の構成

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

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

2.2.2　バッチサーバおよびバッチアプリケーションの操作の流れ

2.2.3　バッチアプリケーションの実行環境の構築と運用

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

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

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

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

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

2.3.4　バッチアプリケーション情報の一覧表示

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

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

2.3.7　バッチアプリケーションの実装（バッチアプリケーションの作成規則）

2.3.8　バッチアプリケーションの実装（リソースに接続する場合）

2.3.9　バッチアプリケーションの実装（EJBにアクセスする場合）

2.3.10　実行環境での設定（バッチサーバの設定）

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

2.4　EJBアクセス機能

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

2.4.2　実行環境での設定（バッチサーバの設定）

2.5　ネーミング管理機能

2.5.1　バッチサーバで使用できるネーミング管理機能

2.5.2　実行環境での設定（バッチサーバの設定）

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

2.7　リソース接続機能

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

2.7.2　リソースへの接続方法

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

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

2.7.5　リソースアダプタの設定方法

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

2.7.7　実行環境での設定

2.8　トランザクション管理

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

2.8.2　実行環境での設定（バッチサーバの設定）

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

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

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

2.9.3　実行環境での設定（バッチサーバの設定）

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

2.10.1　コンテナ拡張ライブラリの概要

2.10.2　実行環境での設定（バッチサーバの設定）

2.11　日立固有のJavaVMの機能

2.11.1　日立固有のJavaVMの機能の概要

2.11.2　実行環境での設定（バッチサーバの設定）

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

2.12.1　バッチアプリケーションの実装（Javaアプリケーションからの移行）

2.12.2　実行環境での設定（バッチサーバの設定）

2.13　JP1/AJS2との連携

2.13.1　JP1/AJS2と連携するための設定

2.13.2　JP1/AJS2およびBJEXと連携するための設定

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

3.1　この章の構成

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

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

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

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

3.2.4　CTMを使用する場合に実行される処理

3.2.5　スケジュールキューの作成単位とキューの共有

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

3.3　CTMのプロセス構成

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

3.3.2　プロセス配置の指針

3.3.3　CTMデーモン

3.3.4　CTMレギュレータ

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

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

3.4　リクエストの流量制御

3.4.1　リクエストの流量制御の概要

3.4.2　実行環境での設定

3.5　リクエストの優先制御

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

3.6.1　動的変更の処理の仕組み

3.6.2　同時実行数に指定できる値

3.6.3　CTMのスケジュールキューの稼働状況の確認

3.6.4　CTMのスケジュールキューの同時実行数の変更

3.7　リクエストの閉塞制御

3.7.1　リクエストの閉塞制御の概要

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

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

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

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

3.7.6　実行環境での設定

3.8　リクエストの負荷分散

3.8.1　負荷分散のタイミング

3.8.2　負荷状況の監視

3.8.3　実行環境での設定

3.9　リクエストのキューの滞留監視

3.9.1　スケジュールキューの滞留監視の概要

3.9.2　スケジュールキュー監視の例

3.9.3　実行環境での設定

3.9.4　注意事項

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

4.　バッチアプリケーションのスケジューリング

4.1　この章の構成

4.2　スケジューリング機能の概要

4.2.1　バッチアプリケーションをスケジューリングする利点

4.2.2　スケジューリング機能を使用するための前提

4.2.3　スケジューリング機能を使用したバッチアプリケーションの実行処理の流れ

4.3　スケジューリング機能を使用したシステム

4.3.1　スケジューリング機能を使用したシステムの構成

4.3.2　スケジューリング機能で必要なプロセス

4.4　スケジューリング機能使用時のバッチアプリケーション実行環境の構築と運用

4.5　スケジューリング機能を使用したバッチアプリケーションの実行

4.5.1　スケジューリング機能を使用したバッチアプリケーションの状態遷移

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

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

4.5.4　バッチアプリケーション情報の一覧表示

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

4.6　スケジューリング機能を使用する環境への移行

4.7　実行環境での設定

4.8　スケジューリング機能使用時の注意事項

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

5.1　この章の構成

5.2　セッションフェイルオーバ機能の概要

5.2.1　セッションフェイルオーバ機能を利用する利点

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

5.2.3　セッションフェイルオーバ機能の前提条件

5.3　セッションフェイルオーバ機能の種類と差異

6.　データベースセッションフェイルオーバ機能

6.1　この章の構成

6.2　データベースセッションフェイルオーバ機能の概要

6.2.1　処理の概要

6.2.2　セッションフェイルオーバ機能の運用モード

6.2.3　適用手順

6.3　前提条件

6.3.1　引き継げるHTTPセッションの属性

6.3.2　前提となる構成

6.3.3　前提となる設定

6.4　グローバルセッションを利用したセッション管理（データベースセッションフェイルオーバ機能）

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

6.4.2　グローバルセッション情報として引き継げるHTTPセッションの属性

6.5　メモリの見積もり

6.5.1　シリアライズ処理で使用するメモリの見積もり

6.5.2　HTTPセッションの属性情報のサイズの見積もり

6.6　データベースセッションフェイルオーバ機能の抑止

6.6.1　拡張子によるデータベースセッションフェイルオーバ機能の抑止

6.6.2　URIによるデータベースセッションフェイルオーバ機能の抑止

6.6.3　注意事項

6.7　性能を重視したモードの選択（完全性保障モードの無効化）

6.7.1　完全性保障モード無効時の動作

6.7.2　HTTPセッションの参照専用リクエストの定義

6.7.3　グローバルセッション情報の削除

6.7.4　注意事項

6.8　データベースセッションフェイルオーバ機能で実施される処理

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

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

6.8.3　グローバルセッション情報の有効期限が切れた場合の処理

6.8.4　データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ

6.8.5　グローバルセッション情報のロック（完全性保障モードが有効の場合）

6.8.6　グローバルセッション情報操作中の障害発生時の動作

6.9　実装時の注意事項

6.9.1　JSPで暗黙的に作成されるHTTPセッション

6.9.2　異なるHTTPセッションに同一のオブジェクトが登録されている場合を考慮した処理

6.9.3　セッション情報の引き継ぎが発生した場合の認証情報の扱い

6.9.4　サーブレットAPIへの影響

6.10　cosminexus.xmlでの定義

6.11　データベースの設定

6.11.1　データベースのディスク容量の確保

6.11.2　データベース接続に必要な権限

6.11.3　データベースのテーブルの作成

6.11.4　アプリケーション情報テーブルの作成

6.11.5　セッション情報格納テーブルおよび空きレコード情報テーブルの作成

6.11.6　データベースの環境設定

6.12　J2EEサーバの設定

6.13　DB Connectorの設定

6.13.1　トランザクションサポートのレベルの設定

6.13.2　DB Connectorの別名の設定

6.13.3　DB Connectorの環境設定

6.14　Webアプリケーションの設定

6.15　データベースセッションフェイルオーバ機能に関する設定の変更

6.15.1　J2EEサーバおよびアプリケーションの設定変更

6.15.2　データベーステーブルの初期化

6.15.3　グローバルセッション情報の削除（HTTPセッションの破棄）

6.16　データベースのテーブルの削除

6.16.1　アプリケーション情報テーブルの削除

6.16.2　セッション情報格納テーブルおよび空きレコード情報テーブルの削除

6.17　データベースセッションフェイルオーバ機能を使用時の注意事項

7.　メモリセッションフェイルオーバ機能

7.1　この章の構成

7.2　メモリセッションフェイルオーバ機能の概要

7.2.1　処理の概要

7.2.2　適用手順

7.3　前提条件

7.3.1　前提となる構成

7.3.2　前提となる設定

7.4　グローバルセッションを利用したセッション管理（メモリセッションフェイルオーバ機能）

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

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

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

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

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

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

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

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

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

7.5.1　グローバルセッション情報のサイズ見積もり機能を有効にするための設定（見積もり時に使用する設定）

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

7.5.3　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理

7.5.4　グローバルセッション情報のサイズ見積もり機能使用時の注意事項

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

7.6.1　HTTP Cookieによる制御の概要

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

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

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

7.6.5　HTTP Cookieの有効期限

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

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

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

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

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

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

7.7.5　リクエストラインの最大サイズの設定

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

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

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

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

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

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

7.9.2　J2EEサーバ起動時の処理

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

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

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

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

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

7.10　メモリセッションフェイルオーバ機能使用時の障害検知

7.11　アプリケーションの実装

7.11.1　実装時の留意事項

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

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

7.12　DDでの定義

7.12.1　DDの作成

7.12.2　DDに定義する項目

7.12.3　DDでの定義例

7.13　cosminexus.xmlでの定義

7.14　J2EEサーバの設定

7.14.1　J2EEサーバの設定内容

7.14.2　簡易構築定義ファイルでの定義

7.14.3　簡易構築定義ファイルのパラメタの設定要否

7.14.4　簡易構築定義ファイルの指定例

7.15　SFOサーバの設定

7.15.1　簡易構築定義ファイルでの定義

7.15.2　SFOサーバの起動オプションの設定

7.16　Webアプリケーションの設定

7.17　Webアプリケーションの設定情報の削除

8.　明示管理ヒープ機能を使用したフルガーベージコレクションの抑止

8.1　この章の構成

8.2　明示管理ヒープ機能の概要

8.2.1　明示管理ヒープ機能を利用する目的

8.2.2　明示管理ヒープ機能の利用によるフルガーベージコレクションの抑止の仕組み

8.2.3　明示管理ヒープ機能を利用する場合の前提条件

8.3　明示管理ヒープ機能で使用するメモリ空間の概要

8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト

8.4.1　HTTPセッションに関するオブジェクト

8.4.2　リダイレクタとの通信用オブジェクト

8.5　アプリケーションで任意にExplicitヒープに配置できるオブジェクト

8.5.1　Explicitヒープに配置できるオブジェクトの条件

8.5.2　オブジェクトのライフサイクルと状態遷移

8.6　Explicitメモリブロックのライフサイクルと実行される処理

8.6.1　Explicitメモリブロックのライフサイクルと状態

8.6.2　Explicitメモリブロックの初期化

8.6.3　Explicitメモリブロックへのオブジェクトの直接生成

8.6.4　Explicitメモリブロックの拡張

8.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動

8.6.6　ライフサイクルの各段階で出力されるイベントログ

8.7　自動解放機能が有効な場合のExplicitメモリブロックの解放

8.7.1　自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約

8.7.2　自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約

8.7.3　自動解放機能が有効な場合のExplicitメモリブロックの解放処理

8.8　自動解放機能が無効な場合のExplicitメモリブロックの解放

8.8.1　自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約

8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理

8.9　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減

8.9.1　適用効果があるかの確認

8.9.2　メモリ使用量を削減する仕組み

8.9.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項

8.10　明示管理ヒープ機能APIを使ったJavaプログラムの実装

8.10.1　オブジェクトをExplicitヒープに配置するための実装

8.10.2　明示管理ヒープ機能の稼働情報を取得するための実装

8.11　実行環境での設定

8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）

8.11.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用

8.11.3　J2EEサーバで利用するための設定

8.12　明示管理ヒープ機能使用時の注意事項

9.　クライアント性能の測定と分析

9.1　クライアント性能モニタ機能

9.1.1　クライアント性能モニタ機能の概要

9.1.2　前提条件

9.1.3　クライアント性能モニタ機能で実行される処理

9.1.4　クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間と分析方法

9.1.5　クライアント性能モニタ機能を構成する要素

9.1.6　クライアント性能モニタのディレクトリ構成

9.2　クライアント性能モニタ機能を使用するための実装

9.2.1　DDでの定義

9.2.2　クライアント性能フィルタの定義方法

9.2.3　問い合わせIDの定義方法

9.2.4　モニタページのアクセス制御の定義方法

9.2.5　DDのサンプル

9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成

9.2.7　クライアント性能測定スクリプトの挿入条件

9.3　実行環境の設定

9.3.1　サーバ側の設定

9.3.2　ブラウザ側の設定

9.4　クライアント性能モニタ機能の運用

9.4.1　モニタページの画面構成

9.4.2　モニタページを表示する

9.4.3　性能情報を表示する

9.4.4　統計情報を表示する

9.4.5　性能データを削除する

9.5　クライアント性能モニタ機能についての注意事項

9.5.1　クライアント性能モニタ機能運用時の注意事項

9.5.2　モニタページに関する注意事項

10.　統合ユーザ管理

10.1　この章の構成

10.2　統合ユーザ管理の概要

10.2.1　統合ユーザ管理の目的

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

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

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

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

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

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

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

10.3.2　WebPasswordLoginModule

10.3.3　WebCertificateLoginModule

10.3.4　WebPasswordLDAPLoginModule

10.3.5　WebPasswordJDBCLoginModule

10.3.6　DelegationLoginModule

10.3.7　WebSSOLoginModule

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

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

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

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

10.4.1　セッションの種類

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

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

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

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

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

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

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

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

10.6.1　カスタムログインモジュールの概要

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

10.7　ユーザ情報の管理

10.7.1　 LDAPディレクトリサーバへのユーザ情報の登録

10.7.2　 LDAPディレクトリサーバの多重化による接続フェイルオーバ

10.8　統合ユーザ管理フレームワークが提供するAPI

10.8.1　JSPタグライブラリ

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

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

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

10.10.1　ログインの実装（APIを使用する場合）

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

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

10.10.4　ログアウトの実装（APIを使用する場合）

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

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

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

10.11.1　ログインの実装（タグライブラリを使用する場合）

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

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

10.11.4　ログアウトの実装（タグライブラリを使用する場合）

10.11.5　uatags.jarおよびuatags.tldのコピーとDDでの定義

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

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

10.12.2　セッションフェイルオーバ機能使用時のログインとログアウトの実装方法

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

10.13　カスタムログインモジュールを使用したユーザ認証の実装

10.13.1　Cosminexus標準のログインモジュールと連携するための実装

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

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

10.14　統合ユーザ管理機能の設定手順

10.15　レルム名の決定

10.16　LDAPディレクトリサーバの設定

10.16.1　LDAPディレクトリサーバの設置

10.16.2　ユーザの登録とアクセス権の設定

10.16.3　オブジェクトクラスとユーザ定義属性の拡張

10.17　ユーザ情報の登録

10.17.1　コマンドによる登録

10.17.2　統合ユーザ管理フレームワークのライブラリによる登録

10.17.3　登録するユーザ情報の文法

10.17.4　Active Directoryを使用する場合の設定

10.18　暗号鍵ファイルの作成（シングルサインオンを使用する場合）

10.18.1　暗号鍵ファイルの作成

10.18.2　暗号鍵ファイルの変更

10.19　ユーザ情報の登録（シングルサインオンを使用する場合）

10.19.1　コマンドによる登録

10.19.2　統合ユーザ管理フレームワークのライブラリによる登録

10.19.3　登録するユーザ情報の文法

10.20　コンフィグレーションファイルの作成

10.20.1　jaas.confの作成

10.20.2　ua.confの作成

10.20.3　コンフィグレーションファイルの設定例

10.21　JavaVMのプロパティの設定

10.22　ファイルのデプロイ

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

11.1　この章の構成

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

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

11.4　構築済み実行環境を切り替えるための準備

11.4.1　退避対象外のファイルの退避

11.4.2　ディスク容量の確認

11.5　構築済み実行環境の切り替え手順

11.5.1　構築済み実行環境の切り替え手順の例

11.5.2　退避環境作成時に退避対象となるファイル

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

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

12.1　この章の構成

12.2　ユーザログ出力の概要

12.2.1　ユーザログ出力の概要

12.2.2　ユーザログ出力の仕組み

12.3　ログのフォーマット

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

12.5　ユーザログを出力するための実装

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

12.6.1　ロガーの作成と設定

12.6.2　ハンドラの作成と設定

12.6.3　ロガーおよびハンドラを作成・設定する場合の指針

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

12.7.1　ライブラリJARを利用する方法

12.7.2　コンテナ拡張ライブラリを利用する方法

12.8　J2EEアプリケーションのユーザログ出力の設定

12.8.1　J2EEサーバの設定

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

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

12.9　バッチアプリケーションのユーザログ出力の設定

12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）

12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）

12.11.1　vbjコマンドを使用する場合の処理の概要

12.11.2　利用の準備

12.11.3　ユーザログ出力処理の流れ

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

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

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

13.　スレッドの非同期並行処理

13.1　この章の構成

13.2　スレッドの非同期並行処理の概要

13.2.1　スレッドの非同期並行処理の流れ

13.2.2　スレッドの非同期並行処理で使用できるJava EEの機能

13.2.3　Timer and Work Manager for Application Serversとの対応

13.3　TimerManagerを使用した非同期タイマ処理

13.3.1　TimerManagerを使用したスレッドのスケジューリング方式

13.3.2　TimerManagerのライフサイクル

13.3.3　TimerManagerのステータス遷移

13.3.4　TimerManagerの多重スケジュール数

13.3.5　TimerManagerを使用したアプリケーションの開発

13.4　 WorkManagerを使用した非同期スレッド処理

13.4.1　デーモンWorkと非デーモンWork

13.4.2　非デーモンWorkで使用するスレッドプールとキューについて

13.4.3　WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル

13.4.4　WorkManagerを使用したアプリケーションの開発

13.4.5　実行環境の設定

付録

付録A　各バージョンでの主な機能変更

付録A.1　08-53での主な機能変更

付録A.2　08-50での主な機能変更

付録A.3　08-00での主な機能変更

付録B　このマニュアルの参考情報

付録B.1　関連マニュアル

付録B.2　マニュアル体系の変更について

付録B.3　このマニュアルでの表記

付録B.4　英略語

付録B.5　KB（キロバイト）などの単位表記について

付録C　用語解説

索引

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

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

前書き

■ 対象製品

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹

P-2443-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2443-7D84　 uCosminexus Application Server Standard　 08-70
P-2443-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2443-7M84　 uCosminexus Web Redirector　 08-70
P-2443-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7E84　 uCosminexus Developer Standard　 08-70
P-2443-7F84　 uCosminexus Developer Professional　 08-70
P-2443-7T84　 uCosminexus Service Architect　 08-70※2

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64）※¹，Windows Server 2003 R2（x64）※¹，Windows Server 2008 x86，Windows Server 2008 x64※¹，Windows Server 2008 R2※¹，Windows Vista，Windows XP，Windows 7（32bit），Windows 7（x64）※¹

P-2443-7H84　 uCosminexus Client　 08-70

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

P-2943-7B84　 uCosminexus Application Server Standard-R　 08-70
P-2943-7D84　 uCosminexus Application Server Standard　 08-70
P-2943-7K84　 uCosminexus Application Server Enterprise　 08-70
P-2943-7S84　 uCosminexus Service Platform　 08-70※2

●適用OS：AIX 5L V5.3，AIX V6.1，AIX V7.1

P-1M43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-1M43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-1M43-7S81　 uCosminexus Service Platform　 08-70※2

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

P-1J43-7D81　 uCosminexus Application Server Standard　 08-70
P-1J43-7K81　 uCosminexus Application Server Enterprise　 08-70
P-1J43-7S81　 uCosminexus Service Platform　 08-70※2

●適用OS：Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T），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），Red Hat Enterprise Linux Server 6（32-bit x86），Red Hat Enterprise Linux Server 6（64-bit x86_64）

P-9S43-7B81　 uCosminexus Application Server Standard-R　 08-70※2
P-9S43-7D81　 uCosminexus Application Server Standard　 08-70※2
P-9S43-7K81　 uCosminexus Application Server Enterprise　 08-70※2
P-9S43-7M81　 uCosminexus Web Redirector　 08-70※2
P-9S43-7S81　 uCosminexus Service Platform　 08-70※2

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

■ 輸出時の注意

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

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Internet Explorerは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JavaScriptは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle9iは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
SecureWayは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
SQL Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
SQL*Plusは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

■ マイクロソフト製品のスクリーンショットの使用について

Microsoft Corporationのガイドラインに従って画面写真を使用しています。

■ マイクロソフト製品の表記について

このマニュアルでは，マイクロソフト製品の名称を次のように表記しています。

製品名 | 表記
Microsoft(R) Active Directory(R) | Active Directory
Microsoft(R) Cluster Service | Microsoft Cluster Service
Microsoft(R) Internet Information Services 6.0 | Microsoft IIS 6.0 | Microsoft IIS
Microsoft(R) Internet Information Services 7.0 | Microsoft IIS 7.0
Microsoft(R) Internet Information Services 7.5 | Microsoft IIS 7.5
Microsoft(R) SQL Server 2000 | SQL Server 2000 | SQL Server
Microsoft(R) SQL Server 2005 | SQL Server 2005
Microsoft(R) SQL Server 2008 | SQL Server 2008
Microsoft(R) SQL Server 2000 Driver for JDBC | SQL Server 2000 Driver for JDBC | SQL ServerのJDBCドライバ
Microsoft(R) SQL Server 2005 JDBC Driver | SQL Server 2005 JDBC Driver
Microsoft(R) SQL Server JDBC Driver 2.0 | SQL Server JDBC Driver
Microsoft(R) SQL Server JDBC Driver 3.0
Microsoft(R) Windows(R) 7 Enterprise（32bit） | Windows 7（32bit） | Windows 7 | Windows
Microsoft(R) Windows(R) 7 Professional（32bit）
Microsoft(R) Windows(R) 7 Ultimate（32bit）
Microsoft(R) Windows(R) 7 Enterprise（x64） | Windows 7（x64）
Microsoft(R) Windows(R) 7 Professional（x64）
Microsoft(R) Windows(R) 7 Ultimate（x64）
Microsoft(R) Windows Server(R) 2003，Enterprise Edition 日本語版 | Windows Server 2003 Enterprise Edition | Windows Server 2003
Microsoft(R) Windows Server(R) 2003，Standard Edition 日本語版 | Windows Server 2003 Standard Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise Edition 日本語版 | Windows Server 2003 R2 Enterprise Edition | Windows Server 2003 R2
Microsoft(R) Windows Server(R) 2003 R2，Standard Edition 日本語版 | Windows Server 2003 R2 Standard Edition
Microsoft(R) Windows Server(R) 2003，Enterprise x64 Edition 日本語版 | Windows Server 2003 Enterprise x64 Edition | Windows Server 2003（x64）
Microsoft(R) Windows Server(R) 2003，Standard x64 Edition 日本語版 | Windows Server 2003 Standard x64 Edition
Microsoft(R) Windows Server(R) 2003 R2，Enterprise x64 Edition 日本語版 | Windows Server 2003 R2 Enterprise x64 Edition | Windows Server 2003 R2（x64）
Microsoft(R) Windows Server(R) 2003 R2，Standard x64 Edition 日本語版 | Windows Server 2003 R2 Standard x64 Edition
Microsoft(R) Windows Server(R) 2008 Enterprise 32-bit 日本語版 | Windows Server 2008 x86 | Windows Server 2008
Microsoft(R) Windows Server(R) 2008 Standard 32-bit 日本語版
Microsoft(R) Windows Server(R) 2008 Enterprise 日本語版 | Windows Server 2008 x64
Microsoft(R) Windows Server(R) 2008 Standard 日本語版
Microsoft(R) Windows Server(R) 2008 R2 Enterprise 日本語版 | Windows Server 2008 R2
Microsoft(R) Windows Server(R) 2008 R2 Standard 日本語版
Microsoft(R) Windows Vista(R) Business | Windows Vista Business | Windows Vista
Microsoft(R) Windows Vista(R) Enterprise | Windows Vista Enterprise
Microsoft(R) Windows Vista(R) Ultimate | Windows Vista Ultimate
Microsoft(R) Windows(R) XP Professional Operating System | Windows XP
Windows(R) Internet Explorer(R) | Internet Explorer
Windows Server(R) Failover Cluster | Windows Server Failover Cluster

■ 発行

2011年 7月3020-3-U08-40

■ 著作権

All Rights Reserved. Copyright (C) 2008, 2011, Hitachi, Ltd.

変更内容

変更内容（3020-3-U08-40）uCosminexus Application Server Enterprise 08-70，uCosminexus Application Server Standard 08-70，uCosminexus Application Server Standard-R 08-70，uCosminexus Client 08-70，uCosminexus Developer Professional 08-70，uCosminexus Developer Standard 08-70，uCosminexus Service Architect 08-70，uCosminexus Service Platform 08-70，uCosminexus Web Redirector 08-70

追加・変更内容
変更個所

アプリケーションサーバ 08-70での主な機能変更についての説明を1.4，およびアプリケーションサーバ 08-53での主な機能変更についての説明を付録A.1に追加した。
また，アプリケーションサーバ 08-50での主な機能変更についての説明を付録A.2に移動した。
1.4，付録A.1，付録A.2

データベースセッションフェイルオーバ機能を使用した場合のリクエスト処理，および障害発生時の処理について，性能を重視した処理方式に変更した。これに伴い，参照専用リクエストを定義できるようにした。また，データの完全性を保障するモードを選択できるようにした。
6.1，6.2.1，6.2.2，6.2.3，6.3.3，6.7，6.7.1，6.7.2，6.7.3，6.7.4，6.8，6.8.1，6.8.2，6.8.3，6.8.5，6.8.6，6.11.6，6.12

データベースセッションフェイルオーバ機能を使用する場合に，HTTPセッション情報の格納先として次のリソースアダプタを使用できるようにした。
DBConnector_CP_ClusterPool_Root.rar
DBConnector_Oracle_CP_ClusterPool_Member.rar
6.3.2

データベースセッションフェイルオーバ機能を使用する場合の，次の設定に関する説明を追加，または変更した。

HttpSessionのサーバID付加機能によるセッションIDへのサーバID付加の設定

HttpSessionオブジェクト数の上限値の指定機能

同時実行スレッド数制御機能使用時の実行待ちキュー不足時の設定

ネゴシエーション失敗時のWebアプリケーション開始処理の設定

データベースセッションフェイルオーバ機能の抑止対象リクエスト内での，getSessionメソッド実行時の例外の設定

6.3.3，6.12

グローバルセッション情報に含まれる情報に，HTTPセッションの所有J2EEサーバ識別子を追加した。
6.4.1

HTTPセッションの属性情報のサイズを求める計算式に関する説明を追加した。
6.5.2

データベースセッションフェイルオーバ機能の抑止に関する注意事項を追加した。
6.6.3

データベースセッションフェイルオーバ機能のアプリケーションのネゴシエーション処理で確認される内容に，J2EEサーバの設定の一致を確認するための項目を追加した。
6.8.1

データベースセッションフェイルオーバ機能でデータベース接続に必要な権限に関する説明を追加した。
6.11.2

データベーステーブルの操作で使用するSQLファイルの変更個所，および内容に関する説明を変更した。
6.11.4，6.11.5，6.15.2，6.16.1，6.16.2

データベースセッションフェイルオーバ機能を使用する場合に，DB Connectorの<config-property>で設定する次のプロパティに指定する内容を変更した。

PreparedStatementPoolSize

6.13.3

データベースセッションフェイルオーバ機能に関する設定の変更手順を変更した。
6.15，6.15.1，6.15.2，6.15.3

データベースセッションフェイルオーバ機能使用時の注意事項を追加した。
6.17

HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加した。
8.1，8.4.1，8.9

WebPasswordJDBCLoginModuleで使用するJDBCドライバをデータベースが提供するJDBCドライバに変更し，データベースの種類にSQL Serverを追加した。
10.3.5

LDAPディレクトリサーバとしてActive Directoryを使用する設定で，日本語などの2バイト文字に対応した。これに伴い，Active Directoryを使用する設定の説明を改善した。
10.17.4

簡易構築定義ファイルで，統合ユーザ管理機能に関する設定をできるようにした。
10.20.2，10.21

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

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

－

次の製品の適用OSにRed Hat Enterprise Linux Server 6（32-bit x86）およびRed Hat Enterprise Linux Server 6（64-bit x86_64）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Service Platform

uCosminexus Web Redirector

－

uCosminexus Application Server Enterprise 08-53，uCosminexus Application Server Standard 08-53，uCosminexus Application Server Standard-R 08-53，uCosminexus Client 08-53，uCosminexus Developer Professional 08-53，uCosminexus Developer Standard 08-53，uCosminexus Service Architect 08-53，uCosminexus Service Platform 08-53，uCosminexus Web Redirector 08-53

追加・変更内容
変更個所

SQL Server 2008に対応した。これに伴い，使用できるJDBCドライバにSQL Server JDBC Driver 2.0，およびSQL Server JDBC Driver 3.0を追加した。
2.7.3

HiRDB Version 9に対応した。
－

Microsoft IIS 7.0およびMicrosoft IIS 7.5に対応した。
－

対象製品としてuCosminexus Application Server Standard-Rを追加した。
－

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

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Service Platform

－

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

変更内容（3020-3-U08-20）uCosminexus Application Server Enterprise 08-50，uCosminexus Application Server Standard 08-50，uCosminexus Client 08-50，uCosminexus Developer Professional 08-50，uCosminexus Developer Standard 08-50，uCosminexus Service Architect 08-50，uCosminexus Service Platform 08-50，uCosminexus Web Redirector 08-50

追加・変更内容

機能の分類とマニュアルの対応の説明に，次の機能を追加した。

OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）

Cosminexus JMSプロバイダ

スレッドの非同期並行処理

ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）

JP1 Version 9に対応した。また，JP1 Version 7は非サポートとなったため削除した。

スレッドの非同期並行処理の機能を追加した。

アプリケーションサーバ 08-50での主な機能変更についての説明を追加した。また，アプリケーションサーバ 08-00での主な機能変更についての説明を付録A.1に移動した。

クラスタソフトウェアにWindows Server Failover Clusterを追加した。

ホスト単位管理モデルを対象にした系切り替えシステムに関する記述を追加した。

クラス別統計機能の説明を変更した。また，日立固有のJavaVMの機能の表に次の機能を追加した。

クラス別統計情報解析機能

hndlwrap機能

URIによってデータベースセッションフェイルオーバ機能を抑止する機能を追加した。

明示管理ヒープの自動解放機能，および自動配置設定ファイルに関する説明を追加した。

明示管理ヒープ機能を使用する場合に必要なメモリサイズに関する説明を追加した。

Tenured領域内不要オブジェクト統計機能に関する説明を追加した。

HTTPセッションに関するオブジェクトの説明を追加した。

メモリを確保する方法に関する説明を変更した。

Explicitメモリブロックの最大サイズを変更した。

アプリケーションで任意にExplicitヒープに配置できるオブジェクトについて説明を変更した。

Explicitメモリブロックのライフサイクルについて項目を追加した。

参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動に関する説明を追加した。

明示管理ヒープの明示解放機能として説明を追加し，実行契機，およびフルガーベージコレクションで十分な空き領域を作成できない場合の説明を追加した。

明示管理ヒープ機能APIを使ったJavaプログラムの実装に関する説明を変更した。

クライアント性能モニタの前提条件となるWebブラウザに，Internet Explorer 8を追加した。

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

uCosminexus Developer Standard

uCosminexus Developer Professional

uCosminexus Service Architect

uCosminexus Client

次の製品の適用OSにWindows Server 2008 R2を追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

uCosminexus Service Platform

uCosminexus Client

クライアント性能フィルタの定義方法，問い合わせIDの定義方法，およびモニタページのアクセス制御の定義方法を変更した。

クライアント性能測定スクリプトの挿入条件を追加した。

構築済み実行環境の切り替えで使用する機能に関する説明を変更した。

次の製品の適用OSからSolarisを削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

はじめに

このマニュアルは，Cosminexus（コズミネクサス）のアプリケーションサーバの機能について説明したものです。このマニュアルでは，アプリケーションサーバで提供する拡張機能について説明します。

アプリケーションサーバでは，次に示すプログラムプロダクトを使用してシステムを構築，運用します。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Application Server Standard-R

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

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

Cosminexus Component Container

Cosminexus Component Container - Client

Cosminexus Component Container - Redirector

Cosminexus Component Transaction Monitor

Cosminexus Developer's Kit for Java

Cosminexus Performance Tracer

Cosminexus TPBroker

なお，オペレーティングシステム（OS）の種類によって，機能が異なる場合があります。

対象読者

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

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

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

Windowsまたはご使用のUNIXのシステムの設計，構築および運用に関する知識

Java EEに関する知識

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

CORBAに関する基本的な知識

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

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

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

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

Windows Server Failover Clusterを使用する場合は，次の内容も理解されていることを前提とします。

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

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

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

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

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

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

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

ご利用の製品ごとの用語の読み替えについて

ご利用の製品によっては，マニュアルで使用している用語を，ご利用の製品名に読み替える必要があります。

次の表に従って，マニュアルで使用している用語をご利用の製品名に読み替えてください。

ご利用の製品名 | マニュアルで使用している用語
uCosminexus Application Server Standard-R | Application Server
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 アプリケーションサーバ アプリケーション開発ガイド」の「付録D　Developer Standard使用時の注意事項」を参照してください。

図中で使用している記号

このマニュアルの図中で使用している記号について次に示します。

1.　アプリケーションサーバの機能

この章では，アプリケーションサーバの機能の分類と目的，および機能とマニュアルの対応について説明します。また，このバージョンで変更した機能についても説明しています。

＜この章の構成＞

1.1　機能の分類

1.2　システムの目的と機能の対応

1.3　このマニュアルに記載している機能の説明

1.4　アプリケーションサーバ 08-70での主な機能変更

1.1　機能の分類

アプリケーションサーバは，Java EE 5に準拠したJ2EEサーバを中心としたアプリケーションの実行環境を構築したり，実行環境上で動作するアプリケーションを開発したりするための製品です。Java EEの標準仕様に準拠した機能や，アプリケーションサーバで独自に拡張された機能など，多様な機能を使用できます。目的や用途に応じた機能を選択して使用することで，信頼性の高いシステムや，処理性能に優れたシステムを構築・運用できます。

アプリケーションサーバの機能は，大きく分けて，次の二つに分類できます。

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

アプリケーションの実行基盤を運用・保守するための機能

二つの分類は，機能の位置づけや用途によって，さらに詳細に分類できます。アプリケーションサーバのマニュアルは，機能の分類に合わせて提供しています。

アプリケーションサーバの機能の分類と対応するマニュアル（機能解説）の体系について，次の図に示します。

図1-1　アプリケーションサーバの機能の分類と対応するマニュアル（機能解説）の体系

ここでは，機能の分類について，マニュアルとの対応と合わせて説明します。

＜この節の構成＞

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

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

1.1.3　機能とマニュアルの対応

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

アプリケーションとして実装されたオンライン業務やバッチ業務を実行する基盤となる機能です。システムの用途や求められる要件に応じて，使用する機能を選択します。

アプリケーションの実行基盤としての機能を使用するかどうかは，システム構築やアプリケーション開発よりも前に検討する必要があります。

アプリケーションの実行基盤としての機能について，分類ごとに説明します。

＜この項の構成＞

(1)　Java EEに準拠したアプリケーションを動作させるための基本的な機能（基本・開発機能）

(2)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

(1)　Java EEに準拠したアプリケーションを動作させるための基本的な機能（基本・開発機能）

Java EEに準拠したアプリケーション（J2EEアプリケーション）を動作させるための基本的な機能が該当します。主にJ2EEサーバの機能が該当します。

アプリケーションサーバでは，Java EE 5に準拠したJ2EEサーバを提供しています。J2EEサーバでは，標準仕様に準拠した機能のほか，アプリケーションサーバ独自の機能も提供しています。

基本・開発機能は，機能を使用するJ2EEアプリケーションの形態に応じて，さらに三つに分類できます。アプリケーションサーバの機能解説のマニュアルは，この分類に応じて分冊されています。

それぞれの分類の概要を説明します。

Webアプリケーションを実行するための機能（Webコンテナ）
Webアプリケーションの実行基盤であるWebコンテナの機能，およびWebコンテナとWebサーバが連携して実現する機能が該当します。

Enterprise Beanを実行するための機能（EJBコンテナ）
Enterprise Beanの実行基盤であるEJBコンテナの機能が該当します。また，Enterprise Beanを呼び出すEJBクライアントの機能も該当します。

WebアプリケーションとEnterprise Beanの両方で使用する機能（コンテナ共通機能）
Webコンテナ上で動作するWebアプリケーションおよびEJBコンテナ上で動作するEnterprise Beanの両方で使用できる機能が該当します。

(2)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

アプリケーションサーバで独自に拡張された機能が該当します。バッチサーバ，CTM，データベースなど，J2EEサーバ以外のプロセスを使用して実現する機能も含まれます。

アプリケーションサーバでは，システムの信頼性を高め，安定稼働を実現するための多様な機能が拡張されています。また，J2EEアプリケーション以外のアプリケーション（バッチアプリケーション）をJavaの環境で動作させる機能も拡張しています。

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

アプリケーションの実行基盤を効率良く運用したり，保守したりするための機能です。システムの運用開始後に，必要に応じて使用します。ただし，機能によっては，あらかじめ設定やアプリケーションの実装が必要なものがあります。

アプリケーションの実行基盤を運用・保守するための機能について，分類ごとに説明します。

＜この項の構成＞

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

(2)　システムの利用状況を監視するための機能（監視機能）

(3)　ほかの製品と連携して運用するための機能（連携機能）

(4)　トラブル発生時などに対処するための機能（保守機能）

(5)　旧バージョンの製品から移行するための機能（移行機能）

(6)　旧バージョンの製品との互換のための機能（互換機能）

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

システムの起動や停止，アプリケーションの開始や停止，入れ替えなどの，日常運用で使用する機能が該当します。

(2)　システムの利用状況を監視するための機能（監視機能）

システムの稼働状態や，リソースの枯渇状態などを監視するための機能が該当します。また，システムの操作履歴など，監査で使用する情報を出力する機能も該当します。

(3)　ほかの製品と連携して運用するための機能（連携機能）

JP1やクラスタソフトウェアなど，ほかの製品と連携して実現する機能が該当します。

(4)　トラブル発生時などに対処するための機能（保守機能）

トラブルシューティングのための機能が該当します。トラブルシューティング時に参照する情報を出力するための機能も含みます。

(5)　旧バージョンの製品から移行するための機能（移行機能）

旧バージョンのアプリケーションサーバから新しいバージョンのアプリケーションサーバに移行するための機能が該当します。

(6)　旧バージョンの製品との互換のための機能（互換機能）

旧バージョンのアプリケーションサーバとの互換用の機能が該当します。なお，互換機能については，「1.1.1　アプリケーションの実行基盤としての機能」に該当する機能などの推奨機能に移行することをお勧めします。

1.1.3　機能とマニュアルの対応

アプリケーションサーバの機能解説のマニュアルは，機能の分類に合わせて分冊されています。

機能の分類と，それぞれの機能について説明しているマニュアルとの対応を次の表に示します。

表1-1　機能の分類とマニュアルの対応

分類 | 機能 | マニュアル※1
基本・開発機能 | Webコンテナ | 基本・開発編(Webコンテナ)
Webサーバ連携
インプロセスHTTPサーバ
サーブレットおよびJSPの実装
EJBコンテナ | 基本・開発編(EJBコンテナ)
EJBクライアント
Enterprise Bean実装時の注意事項
ネーミング管理 | 基本・開発編(コンテナ共通機能)
リソース接続とトランザクション管理
OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）
アプリケーションサーバでのJPAの利用
Cosminexus JPAプロバイダ
Cosminexus JMSプロバイダ
JavaMailの利用
セキュリティ管理
アプリケーションの属性管理
アノテーションの使用
J2EEアプリケーションの形式とデプロイ
コンテナ拡張ライブラリ
拡張機能 | バッチサーバによるアプリケーションの実行 | 拡張編※2
CTMによるリクエストのスケジューリングと負荷分散
バッチアプリケーションのスケジューリング
J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）
明示管理ヒープ機能を使用したフルガーベージコレクションの抑止
クライアント性能の測定と分析
統合ユーザ管理
複数の構築済み実行環境の切り替え
アプリケーションのユーザログ出力
スレッドの非同期並行処理
運用機能 | システムの起動と停止 | 運用／監視／連携編
J2EEアプリケーションの運用
監視機能 | 稼働情報の監視（稼働情報収集機能）
リソースの枯渇監視
監査ログ出力機能
データベース監査証跡連携機能
運用管理コマンドによる稼働情報の出力
Managementイベントの通知とManagementアクションによる処理の自動実行
CTMの稼働統計情報の収集
コンソールログの出力
連携機能 | JP1と連携したシステムの運用
システムの構成定義および管理（JP1/IM-CMとの連携）
システムの集中監視（JP1/IMとの連携）
ジョブによるシステムの自動運転（JP1/AJSとの連携）
シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
監査ログの収集および一元管理（JP1/NETM/Auditとの連携）
クラスタソフトウェアとの連携
1:1系切り替えシステム（クラスタソフトウェアとの連携）
相互系切り替えシステム（クラスタソフトウェアとの連携）
N:1リカバリシステム（クラスタソフトウェアとの連携）
ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）
保守機能 | トラブルシューティング関連機能 | 保守／移行／互換編
性能解析トレースを使用したシステムの性能解析
日立固有のJavaVMの機能
移行機能 | 旧バージョンのアプリケーションサーバからの移行
推奨機能への移行
互換機能 | 旧バージョンとの互換用機能（ベーシックモード）
旧バージョンとの互換用機能（サーブレットエンジンモード）
Cosminexus DABroker Libraryを使用したデータベース接続

注※1　マニュアル名称の「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

注※2　このマニュアルです。

1.2　システムの目的と機能の対応

アプリケーションサーバでは，構築・運用するシステムの目的に合わせて，適用する機能を選択する必要があります。

この節では，アプリケーションサーバで拡張された各機能をどのようなシステムの場合に使用するとよいかを示します。機能ごとに，次の項目への対応を示しています。

信頼性
高い信頼が求められるシステムの場合に使用するとよい機能です。
アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が該当します。

性能
性能を重視したシステムの場合に使用するとよい機能です。
システムのパフォーマンスチューニングで使用する機能などが該当します。

運用・保守
効率の良い運用・保守をしたい場合に使用するとよい機能です。

拡張性
システム規模の拡大・縮小および構成の変更への柔軟な対応が必要な場合に使用するとよい機能です。

そのほか
そのほかの個別の目的に対応するための機能です。

また，アプリケーションサーバで拡張された機能には，Java EE標準機能とアプリケーションサーバが独自に拡張した機能があります。機能を選択するときには，必要に応じて，Java EE標準への準拠についても確認してください。

＜この節の構成＞

1.2.1　バッチアプリケーション実行時に使用する機能

1.2.2　CTMによるEnterprise Beanのスケジューリング機能

1.2.3　そのほかの拡張機能

1.2.1　バッチアプリケーション実行時に使用する機能

バッチアプリケーション実行時に使用する機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-2　バッチアプリケーション実行時に使用する機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

バッチアプリケーション実行機能
バッチアプリケーションの実行
－
－
－
－
－
－
○
2.3.1，
2.3.2

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

バッチアプリケーション情報の一覧表示
－
－
○
－
－
－
○
2.3.4

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

EJBアクセス機能
Enterprise Beanの呼び出し
－
－
－
○
－
○
○
2.4

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

トランザクションの実装
－
－
－
○
－
○
○

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

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

ネーミング管理が提供する機能
JNDI名前空間へのオブジェクトのバインドとルックアップ
－
－
－
○
－
○
○
2.5※

J2EEリソースへの別名付与（ユーザ指定名前空間機能）
－
－
－
○
－
－
○

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

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

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

リソース接続とトランザクション管理が提供する機能
コネクションプーリング
－
○
－
－
－
○
○
2.7，
2.8

コネクションプールのウォーミングアップ
－
○
－
－
－
－
○

コネクションプール数調節機能
－
○
－
－
－
－
○

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

ステートメントプーリング
－
○
－
－
－
－
○

ライトトランザクション
－
○
－
－
－
－
○

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

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

コネクションの障害検知
○
－
－
－
－
○
○

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

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

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

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

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

障害調査用SQLの出力
－
－
○
－
－
－
○

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

コネクションプールのクラスタ化（コネクションプールの一時停止・再開・状態表示）
○
－
－
－
－
－
○

リソースへの接続テスト
－
－
○
－
－
－
○

ガーベージコレクション制御機能
－
○
－
－
－
－
○
2.9

コンテナ拡張ライブラリ
－
－
－
○
－
－
○
2.10

日立固有のJavaVMの機能
－
－
○
－
－
－
○
2.11

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「標準」と「拡張」の両方に○が付いている機能は，Java EE標準の機能にアプリケーションサーバ独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

注※

バッチアプリケーションの場合，別名が付けられるのはJ2EEリソースだけです。Enterprise Beanの説明は該当しません。

1.2.2　CTMによるEnterprise Beanのスケジューリング機能

CTMによるEnterprise Beanのスケジューリング機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-3　CTMによるEnterprise Beanのスケジューリング機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

リクエストの流量制御
○
○
－
－
－
－
○
3.4

リクエストの優先制御
○
○
－
－
－
－
○
3.5

リクエストの同時実行数の動的変更
○
○
○
－
－
－
○
3.6

リクエストの閉塞制御
○
－
○
－
－
－
○
3.7

リクエストの負荷分散
○
○
－
○
－
－
○
3.8

リクエストのキューの滞留監視
○
－
○
－
－
－
○
3.9

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

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

1.2.3　そのほかの拡張機能

そのほかの拡張機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1-4　そのほかの拡張機能とシステムの目的の対応

機能
システムの目的
Java EE標準への準拠
参照先

信頼性
性能
運用・
保守
拡張性
そのほか
標準
拡張

バッチアプリケーションのスケジューリング
○
○
－
－
－
－
○
4章

セッションフェイルオーバ機能（データベースセッションフェイルオーバ機能）
○
－
○
－
－
－
○
5章，6章

セッションフェイルオーバ機能（メモリセッションフェイルオーバ機能）
○
－
○
－
－
－
○
5章，7章

明示管理ヒープ機能を使用したフルガーベージコレクションの抑止
○
－
－
－
－
－
○
8章

クライアント性能の測定と分析
－
－
－
－
○
－
○
9章

統合ユーザ管理
○
－
○
－
－
○
○
10章

複数の構築済み実行環境の切り替え
－
－
－
－
○
－
○
11章

アプリケーションのユーザログ出力
－
－
○
－
－
－
○
12章

スレッドの非同期並行処理
－
○
－
－
○
－
－
13章

（凡例）　○：対応する　　－：対応しない

注

「Java EE標準への準拠」の「標準」と「拡張」の両方に○が付いている機能は，Java EE標準の機能にアプリケーションサーバ独自の機能が拡張されていることを示します。「拡張」だけに○が付いている機能はアプリケーションサーバ独自の機能であることを示します。

1.3　このマニュアルに記載している機能の説明

ここでは，このマニュアルで機能を説明するときの分類の意味と，分類を示す表の例について説明します。

＜この節の構成＞

1.3.1　分類の意味

1.3.2　分類を示す表の例

1.3.1　分類の意味

このマニュアルでは，各機能の説明を次の五つに分類して説明しています。マニュアルを参照する目的によって，必要な個所を選択して読むことができます。

解説
機能の解説です。機能の目的，特長，仕組みなどについて説明しています。機能の概要について知りたい場合にお読みください。

実装
コーディングの方法やDDの記載方法などについて説明しています。アプリケーションを開発する場合にお読みください。

設定
システム構築時に必要となるプロパティなどの設定方法について説明しています。システムを構築する場合にお読みください。

運用
運用方法の説明です。運用時の手順や使用するコマンドの実行例などについて説明しています。システムを運用する場合にお読みください。

注意事項
機能を使用するときの全般的な注意事項について説明しています。注意事項の説明は必ずお読みください。

1.3.2　分類を示す表の例

機能説明の分類については，表で説明しています。表のタイトルは，「この章の構成」または「この節の構成」となっています。

次に，機能説明の分類を示す表の例を示します。

機能説明の分類を示す表の例

表X-1　この章の構成（○○機能）

分類 | タイトル | 参照先
解説 | ○○機能とは | X.1
実装 | アプリケーションの実装 | X.2
DDおよびcosminexus.xml※での定義 | X.3
設定 | 実行環境での設定 | X.4
運用 | ○○機能を使用した運用 | X.5
注意事項 | ○○機能使用時の注意事項 | X.6

注※

cosminexus.xmlについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.　アプリケーションの属性管理」を参照してください。

ポイント

cosminexus.xmlを含まないアプリケーションのプロパティ設定

cosminexus.xmlを含まないアプリケーションでは，実行環境へのインポート後にプロパティを設定，または変更します。設定済みのプロパティも実行環境で変更できます。

実行環境でのアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。サーバ管理コマンドおよび属性ファイルでのアプリケーションの設定については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.3.2　J2EEアプリケーションのプロパティの設定手順」を参照してください。

属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DDまたはcosminexus.xmlと属性ファイルのタグの対応については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.1　Cosminexusアプリケーション属性ファイル（cosminexus.xml）の指定内容」を参照してください。

なお，各属性ファイルで設定するプロパティは，アプリケーション統合属性ファイルでも設定できます。

1.4　アプリケーションサーバ 08-70での主な機能変更

この節では，アプリケーションサーバ 08-70での主な機能の変更について，変更目的ごとに説明します。

説明内容は次のとおりです。

アプリケーションサーバ 08-70で変更になった主な機能と，その概要を説明しています。機能の詳細については参照先の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「Cosminexus アプリケーションサーバ V8」は省略しています。

＜この節の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表1-5　導入・構築の容易性強化を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

運用管理ポータル改善
運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（Connector属性ファイルの設定内容）の設定，および接続テストができるようになりました。また，運用管理ポータルの画面で，J2EEアプリケーション（earファイルおよびzipファイル）をManagement Serverにアップロードできるようになりました。
ファーストステップガイド
3.4.1

運用管理ポータル操作ガイド
－

page/tagディレクティブのimport属性暗黙インポート機能の追加
page/tagディレクティブのimport属性暗黙インポート機能を使用できるようになりました。
機能解説 基本・開発編(Webコンテナ)
2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応
仮想サーバへのアプリケーションサーバ構築時に，仮想サーバに対するJP1製品の環境設定を，フックスクリプトで自動的に設定できるようになりました。
仮想化システム構築・運用ガイド
7.7.2

統合ユーザ管理機能の改善
ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。Cosminexus DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。
簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。
また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。
このマニュアル
10章

運用管理ポータル操作ガイド
3.5，10.9.1

リファレンス 定義編(サーバ定義)
14.3

Hitachi Web Server設定項目の拡充
簡易構築定義ファイルおよび運用管理ポータルの画面で，Hitachi Web Serverの動作環境を定義するディレクティブ（httpsd.conf（Hitachi Web Server定義ファイル）の設定内容）を直接設定できるようになりました。
システム構築・運用ガイド
8.4.3

運用管理ポータル操作ガイド
10.10.1

リファレンス 定義編(サーバ定義)
4.13

（凡例）－：マニュアル全体を参照する

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表1-6　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
ejb-jar.xmlの指定項目の追加 | ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 2.15
パラレルコピーガーベージコレクションへの対応 | パラレルコピーガーベージコレクションを選択できるようになりました。 | リファレンス 定義編(サーバ定義) | 19.5
Connector 1.5仕様に準拠したInboundリソースアダプタのグローバルトランザクションへの対応 | Connector 1.5仕様に準拠したリソースアダプタでTransacted Deliveryを使用できるようにしました。これによって，Message-driven Beanを呼び出すEISがグローバルトランザクションに参加できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3.16.3
TP1インバウンドアダプタのMHPへの対応 | TP1インバウンドアダプタを使用してアプリケーションサーバを呼び出すOpenTP1のクライアントとして，MHPを使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
cjrarupdateコマンドのFTPインバウンドアダプタへの対応 | cjrarupdateコマンドでバージョンアップできるリソースアダプタにFTPインバウンドアダプタを追加しました。 | リファレンス コマンド編 | 2.2

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表1-7　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
データベースセッションフェイルオーバ機能の改善 | 性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。 | このマニュアル | 6章
OutOfMemoryハンドリング機能の対象となる処理の拡大 | OutOfMemoryハンドリング機能の対象となる処理を追加しました。 | 機能解説 保守／移行／互換編 | 2.5.6
リファレンス 定義編(サーバ定義) | 19.2
HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加 | HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加しました。 | このマニュアル | 8.9

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表1-8　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応） | JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。 | 仮想化システム構築・運用ガイド | 1.2.2，3章，4章，5章，6章，7.8

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表1-9　そのほかの目的による変更

項目
変更の概要
参照先マニュアル
参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応
負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。
また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。
システム構築・運用ガイド
4.3.1

仮想化システム構築・運用ガイド
2.1

リファレンス 定義編(サーバ定義)
4.5

snapshotログ収集時のタイムアウトへの対応と収集対象の改善
snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。
機能解説 保守／移行／互換編
付録A

2.　バッチサーバによるアプリケーションの実行

バッチサーバは，バッチアプリケーションを実行するためのサーバです。この章では，バッチサーバで提供する機能，およびバッチアプリケーションの作成方法について説明します。

なお，バッチアプリケーションのスケジューリング機能を使用したバッチアプリケーションの実行については，「4.　バッチアプリケーションのスケジューリング」を参照してください。

＜この章の構成＞

2.1　この章の構成

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

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

2.4　EJBアクセス機能

2.5　ネーミング管理機能

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

2.7　リソース接続機能

2.8　トランザクション管理

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

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

2.11　日立固有のJavaVMの機能

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

2.13　JP1/AJS2との連携

2.1　この章の構成

Javaで開発したバッチジョブを実行するためのアプリケーションをバッチアプリケーションといいます。バッチアプリケーションは，常駐型のJavaVMプロセスであるバッチサーバで実行します。

バッチサーバによるアプリケーションの実行の概要については，「2.2　バッチアプリケーション実行環境の概要」を参照してください。また，バッチアプリケーションでのリソース接続の概要については，「2.6　リソース接続とトランザクション管理の概要」を参照してください。

アプリケーションサーバで提供するバッチサーバの機能と参照先を次の表に示します。

表2-1　アプリケーションサーバで提供するバッチサーバの機能

機能名 | 参照先
バッチアプリケーション実行機能 | 2.3
EJBアクセス機能 | 2.4
ネーミング管理機能 | 2.5
リソース接続機能 | 2.7
トランザクション管理 | 2.8
ガーベージコレクション制御機能 | 2.9
コンテナ拡張ライブラリ | 2.10
日立固有のJavaVMの機能 | 2.11
Javaアプリケーションからの移行 | 2.12
JP1/AJS2との連携 | 2.13

表2-1の機能のほかに，バッチサーバでは，バッチアプリケーションのスケジューリング機能を提供しています。以降，この機能をスケジューリング機能といいます。スケジューリング機能については，「4.　バッチアプリケーションのスケジューリング」を参照してください。

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

この節では，バッチアプリケーション実行環境の概要について説明します。

バッチアプリケーションは，バッチ処理を実装したJavaアプリケーションです。バッチアプリケーション実行環境は，バッチアプリケーションを実行するための環境です。常駐型のJavaVMプロセスであるバッチサーバで構成されます。アプリケーションサーバでは，コマンドを使用して，バッチサーバ上のバッチアプリケーションを実行します。バッチサーバで同時に実行できるバッチアプリケーションは一つだけです。

バッチサーバではバッチアプリケーションを実行する機能として，バッチサービスを提供しています。バッチ実行コマンド（cjexecjobコマンド）を実行すると，バッチサービスはバッチアプリケーションの情報を基に，バッチアプリケーションの実行を開始します。また，バッチ強制停止コマンド（cjkilljobコマンド）を実行すると，実行中のバッチアプリケーションに対して強制停止を実行します。バッチ一覧表示コマンド（cjlistjob）を実行すると，バッチアプリケーションの情報を出力します。

バッチアプリケーションの実行環境は，JP1/AJS2と連携できます。バッチ実行コマンドをあらかじめJP1/AJS2のジョブとして定義しておくことで，JP1/AJS2からバッチアプリケーションを実行できます。バッチ強制停止コマンドも，JP1/AJS2のジョブとして定義できます。

バッチアプリケーション実行の流れを次の図に示します。

図2-1　バッチアプリケーション実行の流れ

＜この節の構成＞

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

2.2.2　バッチサーバおよびバッチアプリケーションの操作の流れ

2.2.3　バッチアプリケーションの実行環境の構築と運用

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

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

バッチアプリケーションを実行するシステムには，バッチサーバが必要です。また，バッチアプリケーションを実行するシステムは，JP1/AJS2やBJEXと連携する運用もできます。JP1/AJS2やBJEXと連携すると，バッチサーバの起動・停止や，バッチアプリケーションの開始をジョブとして定義して，バッチアプリケーションを自動実行できます。また，BJEXと連携すると，バッチアプリケーションの実行コマンドの戻り値を使用したジョブステップの条件付き実行機能を使用できます。

ここでは，バッチアプリケーションを実行するシステムのシステム構成について説明します。スケジューリング機能を使用したシステムについては，「4.　バッチアプリケーションのスケジューリング」を参照してください。

バッチアプリケーションを実行するシステムの構成例を次の図に示します。

図2-2　バッチアプリケーションを実行するシステムの構成例

この図の場合，バッチアプリケーションを実行するシステムは，JP1/AJS2およびBJEXと連携しています。JP1/AJS2およびBJEXと連携しない場合は，図中の運用管理クライアント，JP1ジョブ運用管理サーバ，ならびにバッチサーバのBJEX，JP1/AJS2 - AgentおよびJP1/Baseは必要ありません。

2.2.2　バッチサーバおよびバッチアプリケーションの操作の流れ

ここでは，システム構成ごとに，バッチサーバおよびバッチアプリケーションの操作の流れについて説明します。

＜この項の構成＞

(1)　JP1/AJS2と連携するシステム

(2)　JP1/AJS2およびBJEXと連携するシステム

(3)　JP1/AJS2やBJEXと連携しないシステム

(1)　JP1/AJS2と連携するシステム

JP1/AJS2と連携するシステムでは，バッチサーバの起動や，バッチアプリケーションの実行および強制停止は，JP1/AJS2から操作します。JP1/AJS2では，あらかじめバッチサーバやバッチアプリケーションの操作をジョブとして定義します。

バッチサーバおよびバッチアプリケーション操作の流れを次の図に示します。

図2-3　バッチサーバおよびバッチアプリケーション操作の流れ（JP1/AJS2連携）

バッチサーバは，JP1/AJS2からアプリケーションサーバのManagement Serverを経由して起動します。一方，バッチアプリケーションの実行や強制停止は，JP1/AJS2から直接バッチアプリケーションに対して実行します。JP1/AJS2ではこれらの操作をUNIXジョブまたはPCジョブとしてあらかじめ定義しておきます。

JP1/AJS2でのジョブ定義については，「2.13.1　JP1/AJS2と連携するための設定」を参照してください。

参考

Management Serverを配置しない構成もできます。ただし，配置しない構成の場合，バッチアプリケーションの強制停止に失敗したときには，手動でバッチサーバの再起動が必要になります。Management Serverを使用してバッチサーバを監視すると，トラブル発生時にバッチサーバを自動再起動できるため，Management Serverを使用する運用をお勧めします。

(2)　JP1/AJS2およびBJEXと連携するシステム

JP1/AJS2およびBJEXと連携するシステムでは，バッチサーバの起動や，バッチアプリケーションの実行および強制停止は，JP1/AJS2やBJEXから操作します。JP1/AJS2およびBJEXでは，あらかじめバッチサーバやバッチアプリケーションの操作をジョブとして定義します。

注意

BJEXと連携する場合は，JP1/AJS2とも連携する必要があります。

バッチサーバおよびバッチアプリケーション操作の流れを次の図に示します。

図2-4　バッチサーバおよびバッチアプリケーション操作の流れ（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でのジョブ定義については，「2.13.2　JP1/AJS2およびBJEXと連携するための設定」を参照してください。

参考

Management Serverを配置しない構成もできます。ただし，配置しない構成の場合，バッチアプリケーションの強制停止に失敗したときには，手動でバッチサーバの再起動が必要になります。Management Serverを使用してバッチサーバを監視すると，トラブル発生時にバッチサーバを自動再起動できるため，Management Serverを使用する運用をお勧めします。

バッチサーバではBJEXのジョブログ出力機能を使用できます。ただし，ジョブログ出力機能で出力されるログには，cjexecjobコマンドのCPU使用時間およびメモリ使用量が出力されます。BJEXのジョブステップのCPU使用時間およびメモリ使用量は出力できません。

(3)　JP1/AJS2やBJEXと連携しないシステム

JP1/AJS2やBJEXと連携しないシステムでは，バッチサーバの起動や，バッチアプリケーションの実行および強制停止は，コマンドで直接実行します。

バッチサーバおよびバッチアプリケーション操作の流れを次の図に示します。

図2-5　バッチサーバおよびバッチアプリケーション操作の流れ

バッチサーバは，Smart Composer機能で提供するコマンドを使用して，アプリケーションサーバのManagement Serverを経由して起動します。一方，バッチアプリケーションの実行や強制停止は，バッチアプリケーション実行機能が提供するコマンド（バッチ実行コマンドおよびバッチ強制停止コマンド）を使用して直接バッチアプリケーションに対して実行します。

参考

Management Serverを配置しない構成もできます。ただし，配置しない構成の場合，バッチアプリケーションの強制停止に失敗したときには，手動でバッチサーバの再起動が必要になります。Management Serverを使用してバッチサーバを監視すると，トラブル発生時にバッチサーバを自動再起動できるため，Management Serverを使用する運用をお勧めします。

2.2.3　バッチアプリケーションの実行環境の構築と運用

ここでは，バッチアプリケーションの実行環境の構築方法と，運用方法について説明します。また，バッチアプリケーションの実行環境と連携できるプログラムについても説明します。

＜この項の構成＞

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

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

(3)　ほかのプログラムとの連携

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

バッチアプリケーションの実行環境は，Smart Composer機能，サーバ管理コマンドを使用して構築します。バッチアプリケーションの実行環境の構築手順を次に示します。

Smart Composer機能を使用してシステムを構築します。
簡易構築定義ファイルでシステム構成を定義し，Smart Composer機能で提供するコマンドを使用して，システムを一括構築します。

サーバ管理コマンドを使用して，リソースアダプタを設定します。
バッチアプリケーションからデータベースに接続する場合だけ実施します。

Smart Composer機能，サーバ管理コマンドについては，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「10.　バッチアプリケーションを実行するシステムの構築」を参照してください。

注意

バッチサーバを複数構築する場合，サーバで使用するTCP/IPのポート番号を重複しないよう変更する必要があります。また，バッチサーバはJ2EEサーバで使用しているTCP/IPのポート番号を使用します。複数のバッチサーバを同時に起動する場合，およびバッチサーバとJ2EEサーバを同時に起動する場合は，使用するポート番号が重複しないように設定してください。ポート番号については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.18　アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号」を参照してください。

参考

バッチアプリケーションの実行環境は運用管理ポータルを使用して構築することもできます。運用管理ポータルを使用したバッチアプリケーションの実行環境の構築については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「5.　バッチアプリケーションを実行するシステムの構築と削除」を参照してください。

また，バッチアプリケーションの実行環境では，複数の構築済み実行環境の切り替え機能を使用できます。この機能は拡張機能の一つです。この機能を使用すると，1台のマシンに，複数の構築済み実行環境を共存させて切り替えられます。これによって，同じ製品のバージョン違いや，パッチ適用の有無などによる動作確認を1台のマシンで検証できます。なお，この機能はWindows環境では使用できません。複数の構築済み実行環境の切り替え機能については，「11.　複数の構築済み実行環境の切り替え」を参照してください。

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

バッチアプリケーションの実行環境は次の順序で運用します。

システムの起動
Smart Composer機能で提供するコマンドを使用して，バッチサーバを含むシステム全体を起動します。バッチアプリケーションからリソースに接続する場合は，DB Connectorも開始します。

バッチアプリケーションの実行
cjexecjobコマンドを使用してバッチアプリケーションを開始します。

バッチサーバの停止
Smart Composer機能で提供するコマンドを使用して，バッチサーバを含むシステム全体を停止します。

参考

運用管理ポータルを使用したバッチアプリケーションの実行環境の起動および停止については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「6.1　システムの起動と停止」を参照してください。

JP1/AJS2と連携する場合は，JP1/AJS2からバッチサーバおよびバッチアプリケーションを開始できます。また，JP1/AJS2およびBJEXと連携する場合はJP1/AJS2からバッチサーバを，BJEXからバッチアプリケーションを開始できます。

システムの起動および停止の詳細については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.7　システムの起動と停止の設定」を参照してください。バッチアプリケーションの開始方法については，「2.3.2　バッチアプリケーションの実行」を参照してください。

バッチアプリケーションを実行するシステムでは，次の運用機能が使用できます。

(a)　システムの日常運用を支援する機能

システムの起動・停止のほかに，バッチサーバの稼働状況や，バッチサーバのリソースの使用状況を監視できます。システムの日常運用を支援する機能の概要について説明します。

稼働情報の監視（稼働情報収集機能）
バッチサーバの稼働状態を定期的に監視し，サーバ性能やリソースの情報などの稼働情報を取得します。

運用管理コマンドによる稼働情報の出力
運用管理コマンドを使用して，運用管理ドメイン内の論理サーバを監視し，稼働情報を取得します。

リソースの枯渇監視
バッチサーバを対象に，メモリやスレッドなどのリソースを監視します。監視対象のリソースについての情報は，一定間隔でファイルに出力されます。また，監視対象のリソースの状態が設定したしきい値を超えた場合には，アラートが発生します。アラートが発生すると，メッセージを出力し，Management Serverに対してイベントを通知します。

Managementイベントの通知とManagementアクションによる処理の自動実行
バッチサーバが稼働中に出力するすべてのメッセージを契機にしてManagementイベントを発行できます。Management Server側では，Managementイベントが通知されたときの動作を定義しておくことで，Managementイベントが発生すると自動的にアクションを実行できるようになります。

CTMの稼働統計情報の収集
バッチアプリケーションのスケジューリング機能を使用する場合に，CTMから出力された稼働統計情報を収集できます。この情報を基に，CTMの処理性能を分析できます。

システムの日常運用を支援する機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「1.2.1　システムの日常運用を支援する機能」を参照してください。

(b)　システムの保守を支援する機能

バッチサーバなど，運用管理エージェントによって起動されるプロセスの情報をコンソールログとして出力できます。コンソールログ出力の概要について説明します。

コンソールログ出力
運用管理エージェントが起動したプロセスの標準出力や標準エラー出力などのコンソール出力情報をコンソールログに出力できます。コンソールログ出力については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「11.　コンソールログの出力」を参照してください。

また，バッチアプリケーションのログをユーザログとして出力できます。ユーザログ出力は拡張機能の一つです。ユーザログ出力の概要について説明します。

ユーザログ出力
バッチアプリケーションで例外が発生した場合に，メッセージおよびログを日立トレース共通ライブラリ形式で出力できます。ユーザログについては，「12.　アプリケーションのユーザログ出力」を参照してください。

(c)　システムの監査を支援する機能

システムの構築者や運用者がアプリケーションサーバのプログラムに対して実行した操作や履歴を出力できます。また，バッチアプリケーションがデータベースにアクセスした際に使用したアカウントを記録できます。システムの監査を支援する機能の概要について説明します。

監査ログの出力
監査ログに，システムの構築者や運用者がアプリケーションサーバのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴を出力することで，システムの監査に利用できます。

データベース監査証跡機能との連携
データベースが提供するデータベース監査証跡機能と連携することで，バッチアプリケーションがデータベースにアクセスした際に使用したアカウントを記録できます。

システムの監査を支援する機能については，次の個所を参照してください。

マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「6.　監査ログ出力機能」

マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「7.　データベース監査証跡連携機能」

(d)　システムの保守のための機能

バッチサーバの障害を検知したときに，トラブルシューティングの資料を取得できます。システムの保守のための機能の概要について説明します。

トラブルシューティング
障害検知時コマンドを使用すると，Management Serverが論理サーバの障害を検知した場合に，トラブルシューティングの資料を取得できます。また，アプリケーションサーバの構成ソフトウェアのsnapshotログを出力，収集できます。
例えば，システムにトラブルが発生した場合には，トラブルシューティング情報としてsnapshotログを自動的に収集できます。

性能解析トレースを使用したシステムの性能解析
性能解析トレースは，アプリケーションサーバの各機能が出力する性能解析情報を収集する機能です。この情報を基に，システム性能およびボトルネックを分析できます。

システムの保守のための機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」を参照してください。

(3)　ほかのプログラムとの連携

バッチアプリケーションを実行するシステムでは，次に示すプログラムと連携できます。

JP1との連携

クラスタソフトウェアとの連携

JP1との連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「12.　JP1と連携したシステムの運用」を参照してください。クラスタソフトウェアとの連携については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「18.　クラスタソフトウェアとの連携」を参照してください。

(a)　JP1連携による運用管理機能の概要

JP1連携による運用管理機能の概要について説明します。

システムの構成定義および管理（JP1/IM - CMとの連携）
システム構築時にシステム構成を定義したり，定義したシステムについて，リソースやシステム構成に関する情報を集約して管理したりできます。システム全体に散在する各種リソースの情報を集中して管理することで，システム構成に関する情報を統合管理できます。この機能はJP1/IM - CMと連携して実現できます。なお，JP1/IM - CMと連携できるのは，Smart Composer機能を使用してシステムを構築する場合だけです。

システムの集中監視（JP1/IMとの連携）
業務システム全体のリソースの状態を集中監視することで，稼働性能を把握，調査したり，トラブルの発生を検知して，原因を究明して対策したりできます。この機能はJP1/IMと連携して実現できます。

ジョブによるシステムの自動運転（JP1/AJS2との連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義して自動化することで，効率的なリソースの配分や業務の効率化，省力化を図れます。JP1/AJS2と連携することで，カスタムジョブによるシステムの自動運転が実現できます。

シナリオによるシステムの自動運転（JP1/AJS2 - SOとの連携）
サーバやアプリケーションの開始や停止のスケジュールをあらかじめ定義しておくことで，効率的なリソースの配分や業務の効率化，省略化を図れます。JP1/AJS2 - SOと連携することで，シナリオによるシステムの自動運転が実現できます。なお，シナリオによるシステムの自動運転をする場合は，Smart Composer機能を使用して構築したシステムが前提となります。

監査ログの収集および一元管理（JP1/NETM/Auditとの連携）
システムの監査で使用する監査ログを，自動で収集して，一括管理できます。この機能はJP1/NETM/Auditと連携して実現できます。

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

クラスタソフトウェアとの連携による系切り替え機能の概要について説明します。連携できるクラスタソフトウェアは，Microsoft Cluster Service※1またはWindows Server Failover Cluster※2（Windowsの場合），およびHAモニタ（AIX・HP-UX・Linuxの場合）です。なお，Solarisの場合，クラスタソフトウェアと連携したシステム運用はできません。

注※1

使用できる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となります。

注※2

使用できるOSは，Windows Server 2008となります。

1:1系切り替えシステム
実行系と待機系が1対1になるシステム構成です。バッチアプリケーション実行環境の場合，アプリケーションサーバの1:1系切り替えシステムでの運用をサポートしています。実行系サーバでの障害発生時またはシステムの保守時に，あらかじめ待機させておいたサーバに自動的に切り替えて，業務処理を続行するための機能です。これによって，システムの不稼働時間を短縮し，クライアントの業務処理への影響を減らせます。
なお，バッチアプリケーション実行環境の場合，運用管理サーバを配置しないため，運用管理サーバの1:1系切り替えシステムは使用できません。

相互系切り替えシステム
1:1系切り替えシステムの構成で，2台のサーバがそれぞれ現用系として動作しながら，互いの予備系になるシステムです。アプリケーションサーバの相互系切り替えシステムでの運用をサポートしています。

ホスト単位管理モデルを対象にした系切り替えシステム
ホスト単位管理モデルの実行系N台と予備系1台を配置したシステム構成です。ホスト単位管理モデルのアプリケーションサーバの系切り替えシステムの運用をサポートしています。

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

次に示す個所でマルチバイト文字を使用する場合は，これらの個所すべてでマルチバイト文字のエンコードを同じにしてください。

バッチアプリケーション用オプション定義ファイル（usrconf.cfg）内にマルチバイト文字を使用する場合

バッチサーバ用オプション定義ファイル（usrconf.cfg）内にマルチバイト文字を使用する場合

cjexecjobコマンドの引数にマルチバイト文字を指定する場合

バッチアプリケーションのソースコードで，java.lang.System.outまたはjava.lang.System.errにマルチバイト文字を出力する場合

また，バッチサーバとcjexecjobコマンドを実行するコンソールの環境変数LANGには，対応する文字エンコードを表示できるようにしてください。

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

バッチアプリケーション実行機能は，バッチサーバで提供する機能の一つです。バッチアプリケーション実行機能は，バッチアプリケーションを実行したり，バッチアプリケーションが出力したデータをログ出力機能に出力したりします。

この節では，バッチアプリケーション実行機能について説明します。

この節の構成を次の表に示します。

表2-2　この節の構成（バッチアプリケーション実行機能）

分類 | タイトル | 参照先
解説 | バッチアプリケーション実行機能の概要 | 2.3.1
バッチアプリケーションの実行 | 2.3.2
バッチアプリケーションの強制停止 | 2.3.3
バッチアプリケーション情報の一覧表示 | 2.3.4
バッチアプリケーションのログ出力 | 2.3.5
バッチアプリケーションで使用するコマンドの実行について | 2.3.6
実装 | バッチアプリケーションの実装（バッチアプリケーションの作成規則） | 2.3.7
バッチアプリケーションの実装（リソースに接続する場合） | 2.3.8
バッチアプリケーションの実装（EJBにアクセスする場合） | 2.3.9
設定 | 実行環境での設定（バッチサーバの設定） | 2.3.10
注意事項 | バッチアプリケーション作成時の注意 | 2.3.11

注　「運用」について，この機能固有の説明はありません。

＜この節の構成＞

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

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

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

2.3.4　バッチアプリケーション情報の一覧表示

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

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

2.3.7　バッチアプリケーションの実装（バッチアプリケーションの作成規則）

2.3.8　バッチアプリケーションの実装（リソースに接続する場合）

2.3.9　バッチアプリケーションの実装（EJBにアクセスする場合）

2.3.10　実行環境での設定（バッチサーバの設定）

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

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

バッチアプリケーション実行機能とは，バッチアプリケーションを実行するための機能です。バッチアプリケーションは，バッチアプリケーション実行機能で提供されているバッチクラスローダ上で実行されます。また，実行中のバッチアプリケーションが出力した内容は，ログ出力機能に出力されます。

バッチアプリケーション実行機能について次の図に示します。

図2-6　バッチアプリケーション実行機能の概要

また，バッチアプリケーション実行機能は，EJBアクセス機能やリソース接続機能と連携できます。

EJBアクセス機能と連携すると，バッチアプリケーションからほかのJ2EEサーバのEJBにアクセスできます。

リソース接続機能と連携すると，バッチアプリケーションからデータベースに接続できます。

EJBアクセス機能については「2.4.1　EJBアクセスで使用できる機能」を，リソース接続機能については「2.7　リソース接続機能」を参照してください。

次に，バッチアプリケーションのライフサイクルとバッチアプリケーションを実行するクラスローダについて説明します。

＜この項の構成＞

(1)　バッチアプリケーションのライフサイクル

(2)　バッチアプリケーションの状態遷移

(3)　バッチアプリケーションを実行するクラスローダ

(1)　バッチアプリケーションのライフサイクル

バッチアプリケーションは，cjexecjobコマンドを使用して開始します。次の図を使用して，バッチアプリケーションのライフサイクルについて説明します。

図2-7　バッチアプリケーションのライフサイクル

cjexecjobコマンドを実行すると，バッチアプリケーションはバッチクラスローダによってロードされます。

バッチアプリケーションがバッチサーバ上で実行されます。

バッチアプリケーションの処理が終了します。
バッチアプリケーションの処理終了後に，バッチアプリケーションをロードしたバッチクラスローダがガーベージコレクションされます。

バッチアプリケーションのクラスがアンロードされます。

(2)　バッチアプリケーションの状態遷移

バッチアプリケーションの状態遷移を次の図に示します。

図2-8　バッチアプリケーションの状態遷移（スケジューリング機能を使用しない場合）

「RUNNING」は，バッチアプリケーションがバッチサーバ上にあって実行中の状態です。

バッチアプリケーションの状態は，バッチアプリケーション情報から確認できます。バッチアプリケーション情報の表示方法については，「2.3.4　バッチアプリケーション情報の一覧表示」を参照してください。

(3)　バッチアプリケーションを実行するクラスローダ

バッチアプリケーション実行時には，バッチサーバ上でバッチアプリケーション用のクラスローダが生成されます。バッチアプリケーションはクラスローダ上で実行されます。バッチアプリケーション用のクラスローダの構成を次の図に示します。

図2-9　バッチアプリケーションを実行するクラスローダの構成

図のそれぞれのクラスローダについて説明します。

システムクラスローダ
アプリケーションサーバの構成ソフトウェアが提供するクラスをロードします。

コネクタクラスローダ
リソースアダプタに含まれるクラスをロードします。バッチサーバ内に一つだけ存在します。

バッチクラスローダ
バッチアプリケーションに含まれるクラスをロードします。cjexecjobコマンド実行ごとに作成され，バッチアプリケーション終了時に破棄されます。バッチアプリケーションを実行するスレッドのコンテキストクラスローダは，バッチクラスローダです。

なお，バッチクラスローダ生成時には，バッチクラスローダが生成されたことを示すメッセージが出力されます（メッセージKDJE55013-I）。また，バッチクラスローダがガーベージコレクションされたことを示すメッセージも出力されます（メッセージKDJE55014-I）。

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

バッチアプリケーションは，cjexecjobコマンドで開始します。バッチアプリケーションのmainメソッドの実行が終わると，バッチサーバはフルガーベージコレクションを実行します。ここでは，バッチアプリケーションの開始方法と，バッチアプリケーションの開始および終了時の処理について説明します。

なお，実行中のバッチアプリケーションを停止する場合には，強制停止をします。バッチアプリケーションの強制停止の方法については，「2.3.3　バッチアプリケーションの強制停止」を参照してください。

＜この項の構成＞

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

(2)　バッチアプリケーションの開始処理

(3)　バッチアプリケーションの終了処理

(4)　バッチアプリケーション実行時の注意事項

(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のジョブの定義については，「2.13　JP1/AJS2との連携」を参照してください。

なお，JP1/AJS2やBJEXからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

(2)　バッチアプリケーションの開始処理

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です。

次の表に，バッチアプリケーションの開始に失敗する条件，およびバッチサーバが出力するメッセージを示します。

表2-3　バッチアプリケーションの開始に失敗する条件

バッチアプリケーションの開始に失敗する条件 | バッチサーバが出力するメッセージ
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

(3)　バッチアプリケーションの終了処理

バッチアプリケーションは，mainメソッドの実行が終わると処理が終了します。バッチアプリケーション終了時に実行される処理を次に示します。

バッチアプリケーション終了処理を開始することを示すメッセージ（KDJE55002-I）を出力します。

バッチアプリケーションの終了処理が完了したことを示すメッセージ（KDJE55003-I）を出力します。

フルガーベージコレクションを実行します。

cjexecjobコマンドにバッチアプリケーションの終了コードを送信します。

次の表に，バッチアプリケーションの終了条件と，そのときのバッチサーバやcjexecjobコマンドの動作を示します。

表2-4　バッチアプリケーションの終了条件

バッチアプリケーションの終了条件
バッチサーバの動作
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

なお，バッチアプリケーション実行中に［Ctrl］＋［C］やシグナルなどによってcjexecjobコマンドを終了しても，バッチアプリケーションの実行は終了しません。バッチアプリケーションの実行を強制停止したい場合は，cjkilljobコマンドを実行してください。ただし，cjkilljobコマンドで強制終了した場合，cjexecjobコマンドの終了コードは不定となります。バッチ強制停止コマンドについては，「2.3.3　バッチアプリケーションの強制停止」を参照してください。

(4)　バッチアプリケーション実行時の注意事項

バッチアプリケーションからEJBまたはDB Connectorを呼び出して使用する場合，バッチアプリケーションの開始時には，使用するEJBおよびDB Connectorがあるかどうかの確認は実施しません。バッチアプリケーションから参照しているEJBまたはDB Connectorがない場合は，バッチアプリケーション実行中に実行時エラーになります。バッチアプリケーションを開始する前に，参照先のEJBがあるかどうかを確認してください。また，DB Connectorを使用してバッチアプリケーションからデータベースに接続する場合は，バッチサーバでDB Connectorを開始しておいてください。

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

実行中のバッチアプリケーションを必要に応じて停止させることができます。これを，バッチアプリケーションの強制停止といいます。ここでは，バッチアプリケーションの強制停止について説明します。

＜この項の構成＞

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

(2)　バッチアプリケーションの強制停止処理

(3)　バッチアプリケーションの強制停止実行時の注意事項

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

バッチアプリケーションを強制停止するにはcjkilljobコマンドを使用します。cjkilljobコマンドを実行するには，次の二つの方法があります。

cjkilljobコマンドを直接実行する方法
JP1/AJS2を使用しない場合はこの方法で開始します。

cjkilljobコマンドをJP1/AJS2のリカバリージョブとして定義しておき，ジョブやジョブネットの強制停止の延長で実行する方法
BJEXの使用の有無に関係なく，JP1/AJS2を使用する場合はこの方法で開始します。

2.の方法で，JP1/AJS2のリカバリージョブとしてバッチアプリケーションを強制停止するときのJP1/AJS2のジョブの定義については，「2.13　JP1/AJS2との連携」を参照してください。

なお，バッチアプリケーションの強制停止に失敗した場合，バッチサーバの強制停止が実行されます。このため，複数のアプリケーションを続けて実行する場合は，バッチサーバの再起動が必要になります。バッチアプリケーションの強制停止失敗に備えて，あらかじめバッチサーバを自動再起動するよう設定しておくことをお勧めします。バッチサーバの自動再起動は，Management Serverの運用監視を使用して実現できます。詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.4　障害発生時の自動再起動」を参照してください。

(2)　バッチアプリケーションの強制停止処理

実行中のバッチアプリケーションを強制停止するには，cjkilljobコマンドを使用します。cjkilljobコマンドを使用すると，バッチアプリケーションを実行しているスレッドに対してメソッドキャンセルを実行してバッチアプリケーションを強制停止します。

メソッドキャンセルとは，実行中のメソッドをキャンセルする機能です。ただし，メソッドを実行している領域によって，キャンセルできるメソッドとできないメソッドがあります。メソッドをキャンセルできる領域のことを非保護区，メソッドをキャンセルできない領域を保護区といいます。実行中のメソッドが非保護区の場合に，メソッドキャンセルが実行されます。バッチアプリケーションの強制停止で実行されるメソッドキャンセルは，J2EEアプリケーション実行時間の監視機能で実行されるメソッドキャンセルと同じです。メソッドキャンセルの処理については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.4　メソッドキャンセルとは」を参照してください。

バッチアプリケーション強制停止時に実行される処理を次に示します。

バッチアプリケーションの強制停止処理を開始することを示すメッセージ（KDJE55004-I）を出力します。

public static void main(String[])メソッドまたはpublic static int main(String[])メソッドのメソッドキャンセルを実行します。
なお，メソッドキャンセルに失敗した場合，KDJE55017-Eを出力して強制停止が失敗し，バッチサーバが強制停止します。強制停止が失敗した場合は，バッチサーバを再起動してください。

バッチアプリケーションの強制停止処理が完了したことを示すメッセージ（KDJE55005-I）を出力します。

フルガーベージコレクションを実行します。

cjexecjobコマンドにバッチアプリケーションの終了コードを送信します。

次の表に，バッチアプリケーションの強制停止条件を示します。

表2-5　バッチアプリケーションの強制停止の条件

バッチアプリケーションの強制停止の条件
バッチサーバの動作
cjexecjobコマンドの動作

バッチアプリケーション実行中にバッチ強制停止コマンドを実行した。
KDJE55004-I出力して，バッチアプリケーションの実行を強制停止を開始する。強制停止の完了時にはKDJE55005-Iを出力する。強制停止に失敗したときはKDJE55017-Eを出力する。
バッチ強制終了時の正常パス
戻り値：1

(3)　バッチアプリケーションの強制停止実行時の注意事項

バッチアプリケーションの強制停止に失敗すると，バッチサーバが強制停止されます。複数のバッチアプリケーションを連続して実行する場合，バッチサーバの強制停止後に実行するバッチアプリケーションを開始する前に，バッチサーバを再起動する必要があります。このため，Management Serverを利用して，バッチサーバが自動的に再起動するように設定してください。詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.4　メソッドキャンセルとは」を参照してください。

2.3.4　バッチアプリケーション情報の一覧表示

実行中のバッチアプリケーションの状態や，バッチ実行コマンドの開始時刻などをバッチアプリケーション情報として一覧表示できます。ここでは，バッチアプリケーション情報の一覧表示について説明します。

＜この項の構成＞

(1)　バッチアプリケーション情報の一覧表示の方法

(2)　バッチアプリケーション情報の一覧表示処理

(1)　バッチアプリケーション情報の一覧表示の方法

バッチアプリケーション情報の一覧を表示するには，JP1/AJS2を使用しているかどうかに関係なく，cjlistjobコマンドを直接実行します。

バッチアプリケーション情報は，バッチサーバ単位に取得できます。cjlistjobコマンドの引数には，バッチアプリケーション情報を取得したいバッチサーバ名を指定します。

(2)　バッチアプリケーション情報の一覧表示処理

cjlistjobコマンドを実行すると，引数に指定したバッチサーバで実行中のバッチアプリケーションの情報が取得できます。バッチアプリケーション情報は，標準出力に出力されます。

取得できるバッチアプリケーション情報を次の表に示します。

表2-6　取得できるバッチアプリケーション情報

取得できるバッチアプリケーション情報の項目
内容

バッチアプリケーションの状態
「running」が出力されます。runningは，バッチアプリケーションの状態がRUNNINGであることを示します。詳細は，「2.3.1(2)　バッチアプリケーションの状態遷移」を参照してください。

バッチアプリケーション名
cjexecjobコマンドに指定したバッチアプリケーションのクラス名が出力されます。

性能解析トレースのルートアプリケーション情報
性能解析トレースのルートアプリケーションの通信番号が出力されます。
性能解析トレースファイルに出力されたルートアプリケーション情報と突き合わせて，バッチアプリケーションの状態を確認できます。

バッチ実行コマンドの実行時刻
cjexecjobコマンドを実行した時刻が次の形式で出力されます。なお，△は，半角スペースを表します。
yyyy/mm/dd△hh:mm:ss.ssssss
yyyy：西暦年，mm：月，dd：日，hh：時，mm：分，ss：秒，ssssss：マイクロ秒

なお，バッチアプリケーションがない場合，cjlistjobコマンドを実行しても何も出力されません。この場合，cjlistjobコマンドは正常終了します。

cjlistjobコマンドの出力形式と出力例を次に示します。なお，△は，半角スペースを表します。

cjlistjobコマンドの出力形式

<バッチアプリケーションの状態>△<バッチアプリケーション名>△<性能解析トレースのルートアプリケーション情報>△<バッチ実行コマンドの実行時刻>

cjlistjobコマンドの出力例

running com.hitachi.mypackage.batchApp1 0x0000000000123456 2008/04/14 17:27:35.689012

この例は，cjlistjobコマンドの引数に指定したバッチサーバでは，2008/4/14 17:27:35.689012に開始したバッチアプリケーションが実行中であることを示しています。

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

バッチサーバでは，バッチアプリケーションの実行ログを出力します。実行ログには，実行中のバッチアプリケーションが標準出力や標準エラー出力に出力する内容を，バッチ実行コマンド単位で出力します。これらの情報は障害発生時の調査情報として利用できます。

バッチアプリケーションがjava.lang.System.outおよびjava.lang.System.errに書き出したデータは，バッチサーバによってそれぞれ次の場所に出力されます。

バッチアプリケーションがjava.lang.System.outに書き出したデータ
バッチサーバの標準出力転送機能で，次の場所に出力されます。

バッチサーバのユーザ出力ログ

バッチサーバの標準出力

cjexecjobコマンドの標準出力

バッチアプリケーションがjava.lang.System.errに書き出したデータ
バッチサーバの標準エラー出力転送機能で，次の場所に出力されます。

バッチサーバのユーザエラーログ

バッチサーバの標準エラー出力

cjexecjobコマンドの標準エラー出力

また，cjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンドで出力するメッセージは，メッセージのレベルによってそれぞれ次の場所に出力されます。

I（Information）

標準出力に出力します。ただし，コマンドの使用方法を示すメッセージ（KDJE55029-I，KDJE55030-I，KDJE55052-I）の出力先は標準エラー出力になります。

E（Error）およびW（Warning）

標準エラー出力に出力されます。

バッチアプリケーションを実行するためのコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「3.3　バッチアプリケーションで使用するコマンド」を参照してください。また，メッセージのレベルについては，マニュアル「Cosminexus アプリケーションサーバ メッセージ 2」の「2.2　メッセージの記述形式」を参照してください。

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

ここでは，バッチアプリケーションで使用するコマンドの実行について説明します。

バッチアプリケーションで使用するコマンドには次の3種類があります。

cjexecjobコマンド（バッチ実行コマンド）
バッチアプリケーションを実行するためのコマンドです。

cjkilljobコマンド（バッチ強制停止コマンド）
実行中のバッチアプリケーションを強制停止するためのコマンドです。

cjlistjobコマンド（バッチ一覧表示コマンド）
バッチアプリケーション情報を一覧表示するためのコマンドです。

これらのコマンドは，バッチサーバの状態によって実行できないことがあります。バッチサーバの状態とコマンドの実行について説明します。なお，コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「3.3　バッチアプリケーションで使用するコマンド」を参照してください。

＜この項の構成＞

(1)　バッチサーバの状態とコマンドの実行

(2)　コマンド処理中にバッチサーバが異常終了した場合

(3)　コマンド実行時の注意事項

(1)　バッチサーバの状態とコマンドの実行

cjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンドは，バッチサーバの状態によって実行できないことがあります。バッチサーバの状態とコマンドの実行可否を次の図に示します。

図2-10　バッチサーバの状態とコマンドの実行可否

なお，バッチサーバの停止完了後は，cjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンドは実行できません。メッセージKDJE55010-Eが出力されます。

また，バッチサーバでほかのコマンドを処理している場合，コマンドの種類によっては実行できない場合があります。バッチサーバでコマンドを処理しているときの，コマンドの実行可否を次の表に示します。

表2-7　バッチサーバでコマンドを処理しているときのコマンドの実行可否

実行するコマンド | 処理中のコマンド
cjexecjob | cjkilljob | cjlistjob | サーバ管理コマンド
cjexecjob | × | × | ○ | ○
cjkilljob | ○ | × | ○ | ○
cjlistjob | ○ | ○ | ○ | ○
サーバ管理コマンド | cjstoprar | × | × | ○ | △※1
cjstoprar以外のコマンド | ○ | ○ | ○ | △※1
cjstopsvまたはcmx_stop_target | ○※2 | ○※2 | ○※2 | △※1
cjdumpsv | ○ | ○ | ○ | ○

（凡例）○：実行できる　×：実行できない　△：コマンドの種類によって異なる

注※1　サーバ管理コマンドの種類によって動作が異なります。詳細については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.2.2　サーバ管理コマンドの排他制御」を参照してください。

注※2　実行中のバッチアプリケーションがある場合は，メッセージKDJE55033-Iを出力し，バッチアプリケーションの終了を待機します。

(2)　コマンド処理中にバッチサーバが異常終了した場合

バッチサーバでcjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンドを処理している場合に，バッチサーバが異常終了したときは，メッセージKDJE55021-Eが出力されます。バッチサーバの状態を確認してから再度コマンドを実行してください。

(3)　コマンド実行時の注意事項

コマンド実行時の注意事項を次に示します。

cjexecjobコマンド，cjkilljobコマンドおよびcjlistjobコマンド実行時に，バッチサーバがない場合，メッセージKDJE55010-Eを出力してコマンドは異常終了します。

簡易構築定義ファイルのejbserver.ctm.enabledパラメタと，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキーの指定値が一致していない場合，次のコマンド実行時にエラーが発生することがあります。

cjexecjobコマンド実行時，メッセージKDJE55067-Eを出力してコマンドが異常終了することがあります。

cjlistjobコマンド実行時，バッチアプリケーション情報が出力されないことがあります。

2.3.7　バッチアプリケーションの実装（バッチアプリケーションの作成規則）

バッチアプリケーションとは，バッチ処理の内容を実装したJavaアプリケーションです。ここでは，バッチアプリケーションの作成規則について説明します。

＜この項の構成＞

(1)　バッチアプリケーションのファイル形式

(2)　バッチアプリケーションに実装できる処理

(3)　バッチ処理の開始

(4)　バッチ処理の終了

(1)　バッチアプリケーションのファイル形式

バッチアプリケーションは，JavaVMで規定しているクラスファイル形式にします。なお，複数のクラスを使用する場合は次のこともできます。

クラスファイルを配置したディレクトリをクラスパスに含める。

クラスファイルをアーカイブしたJARファイルをクラスパスに含める。

(2)　バッチアプリケーションに実装できる処理

バッチアプリケーションには，Javaで記述できる処理を実装できます。ただし，ファイルの操作やバッチアプリケーション内で使用するスレッドなどについて，使用時の注意事項があります。アプリケーション作成時の注意については，「2.3.11　バッチアプリケーション作成時の注意」を参照してください。

(3)　バッチ処理の開始

バッチ処理の開始メソッドとして，次のどちらかのメソッドをバッチアプリケーションに定義してください。

public static void main(String[])

public static int main(String[])

mainメソッドの戻り値の型と修飾子が異なる場合，バッチアプリケーションは実行できません。なお，mainメソッドにはthrowsを指定できます。mainメソッドの引数には，cjexecjobコマンドに指定した引数が文字列配列で渡されます。

また，JavaVM終了メソッドを使用できる設定にした場合は，バッチアプリケーションの開始時に，バッチサーバによってバッチアプリケーション実行開始スレッドが作成され，スレッドグループ（batchThreadGroup）に登録されます。JavaVM終了メソッドは，簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「true」を指定した場合に使用できます。ejbserver.batch.application.exit.enabledパラメタの設定については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

(4)　バッチ処理の終了

バッチアプリケーションが次のどちらかの状態になると処理が終了します。

cjexecjobコマンドの引数に指定したクラスのmainメソッドの実行が終了する。

例外やエラーがmainメソッドの外にスローされる。

また，次のどれかの状態になると，バッチアプリケーションのスレッド（batchThreadGroupに属するスレッド）が終了します。

JavaVM終了メソッドを呼び出す。

mainメソッドがリターンする。

mainスレッドで発生した例外がキャッチされない。

バッチアプリケーション終了時に使用できる終了処理を次の表に示します。

表2-8　バッチアプリケーション終了時に使用できる終了処理

バッチアプリケーションの終了方法 | 使用できる終了処理
java.io.deleteOnExit | シャットダウンフック
JavaVM終了メソッドの呼び出しによる終了 | java.lang.System.exit(int)の呼び出しによる終了 | ○ | ○
java.lang.Runtime.exit(int)の呼び出しによる終了 | ○ | ○
java.lang.Runtime.halt(int)の呼び出しによる終了 | ○ | ×
［Ctrl］＋［C］による終了 | × | ×
mainメソッドのリターンによる終了 | ○ | ○
mainスレッドでの例外発生による終了 | ○ | ○

（凡例）○：使用できる　×：使用できない

なお，JavaVM終了メソッドは，簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「true」を指定した場合に使用できます。ejbserver.batch.application.exit.enabledパラメタの設定については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

2.3.8　バッチアプリケーションの実装（リソースに接続する場合）

ここでは，リソースに接続するバッチアプリケーションの作成方法について説明します。新規にバッチアプリケーションを作成する場合と，既存のバッチアプリケーションから移行する場合について説明します。

＜この項の構成＞

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

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

(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の別名の付け方については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。
また，DB Connectorの設定の流れについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3　リソース接続」を参照してください。

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を開始してからバッチアプリケーションを開始してください。

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

既存のバッチアプリケーション（Javaアプリケーション）から移行する場合，リソースに接続する方法は次の2種類があります。

Cosminexusで提供するDB Connectorを使用したリソース接続に変更する。

JDBCドライバを使用してリソースに接続する（接続方法を変更しない）。

DB Connectorを使用しない場合，バッチアプリケーションのコードを修正する必要はありません。ただし，DB Connectorが提供する機能およびガーベージコレクション制御機能は利用できません。ここでは，リソースの接続方法をDB Connectorに変更する場合の移行方法と，JDBCドライバを使用する場合（接続方法を変更しない場合）の移行方法を説明します。

(a)　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の別名の付け方については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。
また，DB Connectorの設定の流れについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3　リソース接続」を参照してください。

バッチアプリケーション内のリソース接続処理のコードを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を開始してからバッチアプリケーションを実行してください。

(b)　JDBCドライバを使用してリソースに接続する

JDBCドライバを使用する場合，バッチアプリケーションのコードを修正する必要はありません。ただし，使用するJDBCドライバのライブラリをバッチサーバのクラスパスに追加する必要があります。詳細は，使用するJDBCドライバの設定に従ってください。次に，JDBCドライバのライブラリをバッチサーバのクラスパスに追加する方法を示します。バッチサーバのクラスパスに追加するには，usrconf.cfg（バッチサーバ用オプション定義ファイル）に次の記述を追加します。

add.class.path=<JDBCドライバのライブラリのフルパス>

なお，usrconf.cfg（バッチサーバ用オプション定義ファイル）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2　usrconf.cfg（バッチサーバ用オプション定義ファイル）」を参照してください。

(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インタフェースの使用方法の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4.8　UserTransactionインタフェースを使用する場合の処理概要と留意点」を参照してください。

UserTransaction使用時の注意事項を次に示します。

UserTransactionはmainスレッドだけ使用できます。ユーザスレッドでは使用できません。

mainスレッドでトランザクションの開始および決着を実施してください。

スレッド生成時にトランザクションは引き継がれません。

スレッド間でコネクションやコネクションから得られたインスタンス（ステートメントなど）を渡せません。このインスタンスを使用した場合は動作が不正になります。

●トランザクションの決着

バッチアプリケーション内でトランザクションを開始した場合は，バッチアプリケーション内で必ず決着処理を実施してください。トランザクションの決着処理を実施しないでバッチアプリケーションを終了すると，タイムアウト時間が経過したあとにトランザクションがロールバックされます。

この場合，簡易構築定義ファイルのejbserver.batch.application.exit.enabledパラメタの指定値によって，次に実行するバッチアプリケーションでトランザクションを開始する時（javax.transaction.UserTransaction#begin()）の挙動が異なります。

ejbserver.batch.application.exit.enabledパラメタで「true」を指定している場合

次に実行するバッチアプリケーションでトランザクションを開始できます（javax.transaction.UserTransaction#begin()を受け付けます）。

ejbserver.batch.application.exit.enabledパラメタで「false」を指定している場合

次に実行するバッチアプリケーションでトランザクションを開始できません。この場合，javax.transaction.NotSupportedExceptionが発生し，詳細情報として「KDJE31009-E No nested transaction is supported.」が出力されます。

トランザクションを開始できない状態から回復する場合は，バッチサーバを再起動してください。

ejbserver.batch.application.exit.enabledパラメタの設定については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

2.3.9　バッチアプリケーションの実装（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 アプリケーションサーバ システム構築・運用ガイド」の「8.　J2EEアプリケーションを実行するシステムの構築」を参照してください。

構築したJ2EEサーバ上で，J2EEアプリケーションを開始します。cjgetstubsjarコマンドを使用して，開始したJ2EEアプリケーションのRMI-IIOPスタブおよびインタフェースを取得しておきます。

なお，バッチアプリケーションからEJBにアクセスする場合，別名によるルックアップをするときは，事前にユーザ指定名前空間機能を使用してEJBの別名を設定しておいてください。EJBの別名の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　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をルックアップするネーミングサービスを指定してください。この場合，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）のjava.naming.provider.urlは指定しないでください。ネーミングサービス切り替え機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.8　CORBAネーミングサービスの切り替え」を参照してください。

2.3.10　実行環境での設定（バッチサーバの設定）

バッチアプリケーション実行機能を使用する場合，バッチサーバの設定が必要です。バッチサーバの設定は，簡易構築定義ファイルで実施します。

注意

デフォルトの設定では，スケジューリング機能を使用しない設定（false）になっています。スケジューリング機能を使用しない場合は，次のパラメタおよびキーの設定を変更しないでください。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のejbserver.ctm.enabledパラメタ

usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキー

バッチアプリケーション実行機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのバッチアプリケーション実行機能の定義を次の表に示します。

表2-9　簡易構築定義ファイルでのバッチアプリケーション実行機能の定義

項目
指定するパラメタ
指定内容
必須または任意

バッチサーバとしてサーバを構築するための設定
batch.service.enabled
バッチサーバとして構築するために，必ずtrueを指定してください。
必須

SecurityManagerを使用しない設定
use.security
SecurityManagerは使用しません。パラメタの値には必ずfalseを指定してください。
必須

ライトトランザクション機能を有効にするための設定
ejbserver.distributedtx.XATransaction.enabled
グローバルトランザクションは使用できません。ローカルトランザクションを使用します※1。パラメタの値には必ずfalseを指定してください。なお，このパラメタはデフォルトの設定がfalseのため，変更しないでください。
必須

明示管理ヒープ機能を使用しない設定
add.jvm.arg
バッチアプリケーションで明示管理ヒープ機能を実装していない場合は，明示管理ヒープ機能を無効にすることをお勧めします。明示管理ヒープ機能を無効にするには，パラメタの値に-XX:-HitachiUseExplicitMemoryを指定してください。デフォルトの設定の場合，明示管理ヒープ機能は有効（-XX:+HitachiUseExplicitMemory）です。
任意

実サーバ名の設定
realservername
バッチサーバの実サーバ名を指定します。省略した場合は，論理サーバ名が設定されます。
任意

JavaVM終了メソッド呼び出し時のJavaVMの動作設定
ejbserver.batch.application.exit.enabled
次のJavaVM終了メソッドをバッチアプリケーションで呼び出した時に，JavaVMを終了するかどうかを指定します。

java.lang.System.exit(int)

java.lang.Runtime.exit(int)

java.lang.Runtime.halt(int)

デフォルトは「true」（JavaVMを終了しないでバッチアプリケーションのスレッドを終了する）です。
「true」を指定，または設定を省略した場合には，JavaVM終了メソッドの呼び出し時に，バッチアプリケーションのスレッド（batchThreadGroupに属するスレッド）が終了され，JavaVMは終了されません。
「false」を指定した場合には，JavaVM終了メソッドの呼び出し時に，バッチサーバごとJavaVMが終了されます。このため，バッチアプリケーションでは，JavaVM終了メソッドおよびシャットダウンフックが使用できません。※2
任意

（凡例）必須：必ず指定する　任意：必要に応じて指定する

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

注※1　バッチサーバの場合，ローカルトランザクションに最適化された環境を提供する，ライトトランザクション機能を使用します。ライトトランザクション機能は，ejbserver.distributedtx.XATransaction.enabledパラメタに「false」を指定すると有効になります。

注※2　ejbserver.batch.application.exit.enabledパラメタで「false」を指定した場合には，JavaVM終了メソッドおよびシャットダウンフックが使用できません。次に示す手段で対処してください。

JavaVM終了メソッドに対する対処
public static int main(String[])メソッドにバッチ処理の内容を記述します。終了コードを返す場合は，return <終了コード>を使用します。ただし，returnを使用する場合は，finallyブロックが実行されます。

シャットダウンフックに対する対処
バッチアプリケーション終了時に実施したい処理がある場合は，mainメソッドのfinallyブロック内に処理を記述してください。

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

ここでは，バッチアプリケーション作成時に注意が必要となる処理や，バッチアプリケーションでは使用できない機能について説明します。これらの内容を確認の上，バッチアプリケーションを作成してください。

＜この項の構成＞

(1)　注意が必要な処理

(2)　バッチアプリケーションで実装できない機能

(3)　JavaVM終了メソッド使用時の注意

(1)　注意が必要な処理

次に示す処理は，バッチアプリケーションを作成する際に注意が必要です。

●ファイルやディレクトリの操作

バッチアプリケーションでは，次に示すファイルやディレクトリは操作しないでください。

Cosminexusのインストールディレクトリ以下のファイルやディレクトリ
Cosminexusのインストールディレクトリ以下のファイルやディレクトリについては，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.9　インストール後のディレクトリ構成」を参照してください。

バッチサーバの作業ディレクトリ以下のファイルやディレクトリ
バッチサーバの作業ディレクトリについては，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.11　バッチサーバの作業ディレクトリ」を参照してください。

また，バッチアプリケーションでファイルやディレクトリを扱う場合，ファイルやディレクトリのパスに相対パスを使用できません。cjexecjobコマンドを実行したディレクトリからの相対パスを取得したい場合は，ejbserver.batch.currentdirの値を使用してください。ejbserver.batch.currentdirについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「ejbserver.batch.currentdirプロパティ」を参照してください。

次に，バッチアプリケーションの修正例を示します。

修正前

File f = new File("DataFile.txt");

修正後

File f = new File(System.getProperty("ejbserver.batch.currentdir") + System.getProperty("file.separator") + "DataFile.txt");

●スレッドの使用

バッチサーバは，バッチアプリケーションが作成および開始したスレッドの終了を待ちません。バッチアプリケーション内でスレッドを使用する場合は，バッチアプリケーションを終了する前に，開始したすべてのユーザスレッドを完了するように実装してください。また，ユーザスレッドはメソッドキャンセルの対象外です。

なお，簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタで「true」を指定した場合には，次の点に注意してください。

スレッドグループ（ThreadGroup）を作成できません。

バッチアプリケーションにjava.lang.ThreadクラスのインタフェースであるUncaughtExceptionHandlerを継承したハンドラを登録していると，JavaVM終了メソッド呼び出し時に登録したハンドラの処理が実行されます。このとき，uncaughtExceptionメソッドの引数にJP.co.Hitachi.soft.jvm.SpecialThrowableの例外が渡されることがあります。

バッチアプリケーションが作成したスレッドが残っていると，バッチアプリケーションのクラスや使用したリソースは解放されません。このため，次にバッチアプリケーションを開始しようとすると，バッチアプリケーションの開始に失敗するおそれがあります。また，ユーザスレッド内では，次のバッチサーバの機能を呼び出すことはできません。

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

EJBアクセス機能

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

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

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

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

●JavaVM終了時のリソースの自動クローズ

バッチサーバではサーバのJavaVM上でバッチアプリケーションを実行します。このため，JavaVM終了による自動的なリソースのクローズ処理を期待した実装をしている場合は，メモリやファイルディスクリプタのリークが発生します。例えば，次の場合にリークが発生します。

ZIPファイルまたはJARファイルをオープンしている場合，明示的にクローズしないとCヒープ領域がリークします。

バッチサーバのusrconf.propertiesにejbserver.batch.application.exit.enabled=falseを指定した場合，java.io.File.deleteOnExit()を使用しても，バッチサーバが停止するまでファイルは削除されません。バッチサーバが停止するまでCヒープ領域がリークします。

この問題を回避するためには，リソースが正しくクローズされるようにバッチアプリケーションを実装してください。

また，ファイルやソケットなども明示的にクローズしていないと，リソース解放のタイミングが不定になります。これによって，次回以降のバッチアプリケーションの実行に影響を及ぼすおそれがあります。ファイルやソケットは明示的にクローズするようにしてください。

なお，バッチサーバの場合，コネクションの自動クローズは使用できません。バッチアプリケーション内で必ずコネクションをクローズしてください。

●JavaVM終了メソッドの使用

簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「true」を指定すると，次のJavaVM終了メソッドが使用できます。

java.lang.System.exit(int)

java.lang.Runtime.exit(int)

java.lang.Runtime.halt(int)

ejbserver.batch.application.exit.enabledパラメタの設定については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。なお，JavaVM終了メソッドを使用する場合の注意事項については，「(3)　JavaVM終了メソッド使用時の注意」を参照してください。

●シャットダウンフックの使用

簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「true」を指定すると，次の場合にシャットダウンフックが使用できます。

JavaVM終了メソッドを呼び出した場合

mainメソッドがリターンした場合

mainスレッドで発生した例外がキャッチされなかった場合

ejbserver.batch.application.exit.enabledパラメタの設定については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

(2)　バッチアプリケーションで実装できない機能

次に示す機能はバッチアプリケーションでは使用できません。「対処方法」に示す手段で対応してください。

●標準入力からの入力

java.lang.System.inなどを使用した標準入力からの入力処理はできません。

対処方法

入力処理が必要な場合はファイルを使用してください。

●JNIの使用

JNI経由でのネイティブライブラリの実行機能は使用できません。

対処方法

JNIを使用する場合は，コンテナ拡張ライブラリ経由で使用してください。このとき，ネイティブライブラリのロードはコンテナ拡張ライブラリ内で実施します。

●システムプロパティのセットの置き換え

次に示すメソッドは使用できません。

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オブジェクトを直接使用します。

(3)　JavaVM終了メソッド使用時の注意

簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「true」を指定すると，バッチアプリケーションでJavaVM終了メソッドを使用しても，JavaVMは終了されません。この場合，JavaVM終了メソッドが呼び出したスレッドだけを終了できます。

ここでは，ejbserver.batch.application.exit.enabledパラメタに「true」を指定している場合に，JavaVM終了メソッドを使用するときの注意事項について説明します。

●Java言語仕様との差異

バッチアプリケーションで使用するJavaVM終了メソッドは，Java言語仕様と仕様が異なります。Java言語仕様との差異を次の表に示します。

表2-10　Java言語仕様との差異

項目
Java言語仕様の場合
バッチアプリケーションの場合

終了対象
JavaVM
JavaVM終了メソッドを呼び出したスレッド

呼び出し以降に記述されたjavaロジック
JavaVM終了メソッドの呼び出し以降に記述されている処理は実行されません。
次の場合，JavaVM終了メソッドの呼び出し以降に記述されている処理は実行されます。

JavaVM終了メソッドがtryブロックに記述された場合は，対応するfinallyブロックが実行されます。※1

スレッドにjava.lang.Thread.UncaughtExceptionHandlerが登録されていた場合は，UncaughtExceptionHandlerが実行されます。※1

複数回呼び出し
使用できません。
次の場合に複数回呼び出されます。

JavaVM終了メソッドを呼び出したスレッドと同一のfinallyブロックから，JavaVM終了メソッドを呼び出す場合

バッチアプリケーションから起動された複数のユーザスレッド※2から，JavaVM終了メソッドを呼び出す場合

注※1　finallyブロック内およびfinallyブロック内で呼び出されたメソッド内で例外が発生し，その例外がfinallyブロックでキャッチされないでfinallyブロックの実行が途中で中断された場合は，スレッドが終了できないときがあります。

また，次の場合，スレッドの終了に時間が掛かったり，スレッドが終了できなかったりするときがあります。

finallyブロック内およびfinallyブロック内で呼び出されたメソッド内に，時間が掛かるJavaプログラム処理が記述された場合

java.lang.Thread.UncaughtExceptionHandlerに，時間が掛かるJavaプログラム処理が記述された場合

なお，時間の掛かるJavaプログラムの処理には，無限ループ，synchronized文によるモニタ待ち，java.lang.wait()による待ちなどがあります。

注※2　ユーザスレッドとは，バッチアプリケーションが作成した子スレッドを示します。ユーザスレッドを使用している場合は，次の点に注意してください。

run()メソッドの中でinterruptedExceptionがキャッチされると，ユーザスレッドは終了されないで残ります。

ユーザスレッドが残っていても，mainスレッドが終了していれば，次のアプリケーションの開始を受け付けられますが，メモリリークが発生します。

参考

JavaVM終了メソッド実行時にJavaVMを終了したい場合は，簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタに「false」を指定します。「false」を指定すると，JavaVM終了メソッド実行時に，バッチサーバごとJavaVMが終了します。

●JavaVM終了メソッドを呼び出した場合の処理

バッチアプリケーションごとに，JavaVM終了メソッドを呼び出した場合の処理を説明します。

シングルスレッドで実装されたバッチアプリケーションでJavaVM終了メソッドを呼び出した場合

mainスレッドを終了し，バッチアプリケーションの実行を終了します。

JavaVM終了メソッドが複数回呼び出された場合の動作を次の表に示します。

表2-11　JavaVM終了メソッドが複数回呼び出された場合の動作（シングルスレッドで実装されたバッチアプリケーションの場合）

項番
項目
動作

1
バッチアプリケーション実行機能への終了通知
1回目のJavaVM終了メソッド呼び出し時にだけ終了を通知します。
2回目以降のJavaVM終了メソッド呼び出し時には通知しません。

2
終了コードの返却
1回目のJavaVM終了メソッド呼び出し時に引数に指定された終了コードが有効となります。
2回目以降のJavaVM終了メソッド呼び出し時に引数に指定された終了コードは無効となります。

3
JavaVM終了メソッドを呼び出したスレッド
JavaVM終了メソッドの呼び出し回数に関係なく，スレッドが終了します。

マルチスレッドで実装されたバッチアプリケーションでJavaVM終了メソッドを呼び出した場合

JavaVM終了メソッドを呼び出したスレッドが終了します。それ以外のスレッドの処理は，JavaVM終了メソッドがどのスレッドから呼び出されたかによって，異なります。

mainスレッドでJavaVM終了メソッドを呼び出した場合，mainメソッドがリターンした場合，またはmainスレッドで発生した例外がキャッチされなかった場合
バッチアプリケーション実行機能が，すべての実行中のユーザスレッドに対して，java.lang.Threadクラスのinterruptを実行します。

ユーザスレッドでJavaVM終了メソッドを呼び出した場合
バッチアプリケーション実行機能が，次に示すスレッド以外の，すべての実行中のユーザスレッドに対して，java.lang.Threadクラスのinterruptを実行します。
・JavaVM終了メソッドを呼び出したユーザスレッド
・mainスレッド
バッチアプリケーション実行機能は，ユーザスレッドを呼び出しているmainスレッドに対して，メソッドキャンセルを実行します。メソッドキャンセルが成功した場合，mainスレッドが終了し，バッチアプリケーションが終了します。メソッドキャンセルが失敗した場合は，バッチサーバごとJavaVMが終了します。
ユーザスレッドでのJavaVM終了メソッド呼び出しは，メソッドキャンセルが失敗することがあるため，推奨しません。

どちらの場合も，mainスレッドが終了すると，ユーザスレッドが残っているかどうかに関係なく，次のバッチアプリケーションの開始を受け付けられます。

2.4　EJBアクセス機能

バッチアプリケーションからほかのJ2EEアプリケーションにあるEJBにアクセスできます。この機能をEJBアクセスといいます。この節では，EJBアクセスで使用できる機能（EJBアクセス機能）について説明します。

なお，EJBにアクセスするバッチアプリケーションの作成方法については，「2.3.9　バッチアプリケーションの実装（EJBにアクセスする場合）」を参照してください。

この節の構成を次の表に示します。

表2-12　この節の構成（EJBアクセス機能）

分類 | タイトル | 参照先
解説 | EJBアクセスで使用できる機能 | 2.4.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.4.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

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

2.4.2　実行環境での設定（バッチサーバの設定）

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

EJBアクセスで使用できる機能について，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2-13　EJBアクセスで使用できる機能

分類
機能
説明
参照先マニュアル※
参照個所

JNDI
基本機能
JNDI名前空間へのオブジェクトのバインドとルックアップ
自動的にバインドされる名称またはユーザ指定名前空間を利用して，EJBホームオブジェクトおよびビジネスインタフェースのリファレンスをネーミングサービスからルックアップできます。
基本・開発編(コンテナ共通機能)
2.3

拡張機能
ラウンドロビンポリシーによるCORBAネーミングサービスの検索
複数のネーミングサービスとJ2EEサーバで構成されるシステムに対して，バッチアプリケーションからのルックアップをラウンドロビンで実行できます。これによって，負荷分散を実現できます。
2.5

ネーミング管理機能でのキャッシング
ネーミングサービスからルックアップしたオブジェクトをメモリ上に保持（キャッシュ）できます。キャッシュの利用によって，ネーミングサービスへのアクセスの性能上のコストを削減できます。
2.6

EJB
Enterprise Beanの実行
EJBコンテナで実行されているEnterprise Beanをバッチアプリケーションから呼び出せます。ただし，呼び出し方法はリモート呼び出しだけ使用できます。ローカル呼び出しはできません。
基本・開発編(EJBコンテナ)
2.2

Enterprise Beanの呼び出し
3.4

RMI-IIOPスタブ，インタフェースの取得
バッチアプリケーションから，Cosminexus TPBrokerのRMI-IIOPの機能を利用してアプリケーションを呼び出せます。
3.7

EJBのリモートインタフェースの呼び出し
バッチアプリケーションからのEJB呼び出し実行時に通信障害が発生した場合に，送信動作を選択できます。
2.13

トランザクション
トランザクション管理
バッチアプリケーションでトランザクションを開始・決着できます。ただし，バッチアプリケーションの場合，グローバルトランザクションは使用できません。
基本・開発編(コンテナ共通機能)
3.4

EJBクライアントアプリケーションでのトランザクションの実装
バッチアプリケーションでUserTransactionを取得し，トランザクションを開始・決着できます。UserTransactionの取得方法には次の2種類の方法があります。

UserTransactionFactoryクラスを使用する方法

ルックアップを使用する方法

基本・開発編(EJBコンテナ)
3.5

そのほか
EJBコンテナでのタイムアウトの設定
バッチサーバとネーミングサービス間，およびバッチサーバとJ2EEサーバ間の通信で，RMI-IIOP通信のタイムアウトを設定できます。
バッチアプリケーションの場合，Stateful Session Beanのタイムアウト，Entity BeanのEJBオブジェクトのタイムアウト，およびインスタンス取得待ちのタイムアウトの説明は該当しません。
基本・開発編(EJBコンテナ)
2.11

性能解析トレースを使用したシステムの性能解析
バッチアプリケーションの性能解析トレースを出力できます。
保守／移行／互換編
6章

アプリケーションのユーザログ出力
バッチアプリケーションのログを出力できます。
このマニュアル
12章

注※　参照先のマニュアル名称は，「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

2.4.2　実行環境での設定（バッチサーバの設定）

EJBアクセス機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。EJBアクセス機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのEJBアクセス機能の定義を次の表に示します。

表2-14　簡易構築定義ファイルでのEJBアクセス機能の定義

項目 | 指定するパラメタ | 設定内容
RMI-IIOP通信のタイムアウト | ejbserver.rmi.request.timeout | RMI-IIOP通信のクライアントとサーバ間の通信タイムアウト時間を指定します。
リモートインタフェースでの通信障害発生時のEJBクライアントの動作 | ejbserver.container.rebindpolicy | EJBメソッドの呼び出し時に通信障害が発生した場合のバッチサーバ側でのコネクションの再接続動作とリクエストの再送動作を指定します。
バッチサーバの通信ポートとIPアドレスの固定 | vbroker.se.iiop_tp.scm.iiop_tp.listener.port | バッチサーバの通信ポートを指定します。
vbroker.se.iiop_tp.host | バッチサーバの使用するIPアドレスまたはホスト名を固定するかどうかを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

2.5　ネーミング管理機能

ネーミング管理は，J2EEサービスで提供されている機能の一つです。J2EEサービスは，J2EEコンテナの部品機能として利用される機能です。ネーミング管理では，オブジェクト（Enterprise Beanに対応するEJBホームオブジェクト，ビジネスインタフェースのリファレンスおよびJ2EEリソース）の名前と格納場所を管理しています。ネーミング管理の機能を使用することで，バッチアプリケーションは，呼び出すEnterprise Beanまたはリソースの格納場所を知らなくても，名前から必要なオブジェクトを利用できるようになります。この節では，バッチサーバで使用できるネーミング管理機能および設定方法について説明します。

この節の構成を次の表に示します。

表2-15　この節の構成（ネーミング管理機能）

分類 | タイトル | 参照先
解説 | バッチサーバで使用できるネーミング管理機能 | 2.5.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.5.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.5.1　バッチサーバで使用できるネーミング管理機能

2.5.2　実行環境での設定（バッチサーバの設定）

2.5.1　バッチサーバで使用できるネーミング管理機能

バッチサーバで使用できるネーミング管理機能を次の表に示します。ネーミング管理機能の詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.　ネーミング管理」を参照してください。

表2-16　ネーミング管理機能

機能
説明

JNDI名前空間へのオブジェクトのバインドとルックアップ
オブジェクトをJNDI名前空間の名前とバインドして管理します。バッチアプリケーションからは，バインドされた名前を使用してルックアップできます。バッチアプリケーションの場合，java:comp/envでのルックアップは使用できません。

Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）
J2EEリソースに別名を付与できます。バッチアプリケーションからは，別名として設定した任意の名称でルックアップできます。なお，バッチアプリケーションからデータベースに接続する場合，J2EEリソースには必ず別名を設定してください。
J2EEリソースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。バッチアプリケーションの場合，Enterprise Beanの説明は該当しません。

ラウンドロビンポリシーによるCORBAネーミングサービスの検索
複数のCORBAネーミングサービスに登録されている同一名称（別名）のEJBホームオブジェクトリファレンスを，ラウンドロビンポリシーに従ってルックアップできます。

ネーミング管理機能でのキャッシング
ルックアップしたEJBホームオブジェクトリファレンスをキャッシングしておき，2回目以降に同じオブジェクトをルックアップする場合の処理に掛かる時間を短くできます。

CORBAネーミングサービスの切り替え
ルックアップの対象にするJNDI名前空間を，InitialContextクラスのインスタンスのプリフィックス判定によって切り替えられます。

ネーミング管理機能のJNDIでは，CORBAオブジェクトリファレンス以外のオブジェクト（RMI-IIOPのリモートオブジェクトやJDBCデータソースなどのオブジェクト）を次のように扱います。

CORBAオブジェクトリファレンス以外の登録は，対象のオブジェクトをCORBAオブジェクトに変換し，CORBAオブジェクトリファレンスをCORBAネーミングサービスへ登録することで実現しています。

CORBAオブジェクト以外のオブジェクトの検索は，CORBAオブジェクトリファレンスを検索し，CORBAオブジェクトから逆変換して元のオブジェクトを取得することで実現しています。

2.5.2　実行環境での設定（バッチサーバの設定）

ネーミング管理機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。ネーミング管理機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのネーミング管理機能の定義を次の表に示します。

表2-17　簡易構築定義ファイルでのネーミング管理機能の定義

項目
指定するパラメタ
設定内容

基本設定
ejbserver.naming.host
CORBAネーミングサービスのホスト名を指定します。※1

ejbserver.naming.port
CORBAネーミングサービスのポート番号を指定します。※1

ラウンドロビン検索※2
ejbserver.jndi.namingservice.group.list
CORBAネーミングサービスのグループを指定します。

ejbserver.jndi.namingservice.group.<Specify group name>.providerurls
各グループに属する，CORBAネーミングサービスのルート位置を指定します。

java.naming.factory.initial
InitialContextFactoryの実装をデレゲートしているクラスを指定します。

ネーミングのキャッシング
ejbserver.jndi.cache
ネーミングでのキャッシングを有効にするかどうかを指定します。

ejbserver.jndi.cache.interval
キャッシュクリアの間隔を指定します。

ejbserver.jndi.cache.interval.clear.option
キャッシュクリアの範囲を指定します。
キャッシュを定期的にクリアするときの設定例（物理ティアの定義の場合）を次に示します。

（例）

<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
 <param>
   <param-name>ejbserver.jndi.cache</param-name>
   <param-value>on</param-value>
 </param>
 <param>
   <param-name>ejbserver.jndi.cache.interval</param-name>
   <param-value>60</param-value>
 </param>
 <param>
   <param-name>ejbserver.jndi.cache.interval.clear.option</param-name>
   <param-value>check</param-value>
 </param>
 ：
</configuration>

ネーミングサービスの通信タイムアウト
ejbserver.jndi.request.timeout
ネーミングサービスとの通信タイムアウト時間を指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注※1　デフォルトの設定では，バッチサーバは，ホスト名「localhost」，ポート番号「900」のCORBAネーミングサービスをインプロセスで自動起動して使用します。

注※2　ラウンドロビン検索は，ユーザ指定名前空間機能を使用していることが前提になります。ユーザ指定名前空間機能を使用する場合，サーバ管理コマンドの動作設定のカスタマイズが必要です。設定方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4.7　実行環境での設定」を参照してください。

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

バッチアプリケーションでは，処理の延長でデータベースに接続できます。バッチアプリケーションからデータベースに接続するには，接続するリソースに対応したリソースアダプタをデプロイして使用します。アプリケーションサーバでは，データベースに接続するためのリソースアダプタであるDB Connectorを提供しています。

また，アプリケーションサーバでは，これらのリソースに効率的かつ信頼性の高い方法でアクセスするために，コネクションプーリングやトランザクション管理の機能を提供しています。コネクションプーリングを使用すると，リソースに対するコネクションをプーリングして，効率的にコネクションを使用できます。また，障害が発生したコネクションを適切にコネクションプールから取り除きます。また，トランザクション管理の機能を使用すると，トランザクションマネジャが，メソッドごとに指定するトランザクション属性やJTAインタフェース（UserTransaction）による指示に基づいて，リソースアクセスのトランザクションを適切に制御します。

なお，バッチアプリケーションではグローバルトランザクションは使用できません。

コネクションプーリング，およびトランザクション管理の機能を使用したリソースへの接続の例を次の図に示します。

図2-11　コネクションプーリングおよびトランザクション管理の機能を使用したリソースへの接続の例

なお，リソースに接続するバッチアプリケーションの作成方法については，「2.3.8　バッチアプリケーションの実装（リソースに接続する場合）」を参照してください。

2.7　リソース接続機能

バッチアプリケーションではリソースとしてデータベースを使用できます。この節では，バッチアプリケーションからのデータベースへの接続について説明します。

この節の構成を次の表に示します。

表2-18　この節の構成（リソース接続機能）

分類 | タイトル | 参照先
解説 | 接続できるデータベース | 2.7.1
リソースへの接続方法 | 2.7.2
DB Connector（RARファイル）の種類 | 2.7.3
リソースアダプタの使用方法 | 2.7.4
リソースアダプタの設定方法 | 2.7.5
リソースアダプタの設定の流れ | 2.7.6
設定 | 実行環境での設定 | 2.7.7

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

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

2.7.2　リソースへの接続方法

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

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

2.7.5　リソースアダプタの設定方法

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

2.7.7　実行環境での設定

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

バッチサーバからは次のデータベースに接続できます。ただし，バッチサーバではグローバルトランザクションは使用できません。

HiRDB

Oracle

SQL Server※

XDM/RD E2

注※　SQL Serverと接続できるのはWindowsの場合だけです。

これらのデータベースを利用するためにはリソースアダプタを使用します。リソースアダプタを利用するには，サーバ管理コマンドを使用して，リソースアダプタのプロパティ設定やインポートなどの作業が必要です。リソースアダプタの設定については，「2.7.7(2)　リソースアダプタの設定」を参照してください。

なお，リソースの設定をする前に，リソースの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。リソース設定時の注意事項や，サーバ管理コマンドを使用するための動作設定については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「8.8.1　リソースとJ2EEアプリケーションの設定の前に」を参照してください。

また，次に示すデータベースとの接続に関する説明については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6　データベースへの接続」を参照してください。

DB Connectorによる接続の概要

データベースとJDBCドライバの対応

DB ConnectorがサポートするJDBC仕様

データベースと接続する場合の前提条件と注意事項※

注※　接続するデータベースの種類に応じて参照してください。

2.7.2　リソースへの接続方法

バッチアプリケーションからデータベースに接続するには，JDBCドライバを直接使用するか，またはアプリケーションサーバで提供しているリソースアダプタを使用します。リソースアダプタを使用する場合は，DB Connectorを使用します。バッチアプリケーションからデータベースに接続するときに使用できる機能を，接続方法ごとに次の表に示します。なお，DB Connectorを使用すると次の表の機能に加えて，DB Connectorが提供している機能も使用できます。DB Connectorが提供している機能については，「2.7.4(1)　リソースアダプタの機能」を参照してください。

表2-19　データベースに接続するときに使用できる機能

使用できる機能 | 接続方法
DB Connector | JDBCドライバ
SQLの実行 | ○ | ○
トランザクションの利用 | Connection APIによるトランザクション | ○ | ○
JTA | ローカルトランザクション | ○ | ×
グローバルトランザクション | × | ×
ガーベージコレクション制御機能 | ○ | ×

（凡例）○：使用できる　×：使用できない

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

DB Connectorを使用してデータベースに接続する場合，使用するJDBCドライバに応じたRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.　リソースアダプタの設定」を参照してください。

JDBCドライバの種類とバッチサーバの場合に使用できるRARファイルについて次の表に示します。

表2-20　JDBCドライバとRARファイルの対応

JDBCドライバ
RARファイル
説明

HiRDB Type4 JDBC Driver
DBConnector_HiRDB_Type4_CP.rar
HiRDB，XDM/RD E2への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

Oracle JDBC Thin Driver
DBConnector_Oracle_CP.rar
Oracleへの接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_CP_ClusterPool_Root.rar
Oracleへの接続に使用するRARファイルです。
次の場合に使用します。

コネクションプールのクラスタ化機能でルートリソースアダプタを使用する場合

ルートリソースアダプタに属するメンバリソースアダプタが，ローカルトランザクションまたはトランザクション管理なしの場合

DBConnector_Oracle_CP_ClusterPool_Member.rar
Oracleへの接続に使用するRARファイルです。
次の場合に使用します。

コネクションプールのクラスタ化機能でメンバリソースアダプタを使用する場合

ルートリソースアダプタに属するメンバリソースアダプタが，ローカルトランザクションまたはトランザクション管理なしの場合

なお，J2EEアプリケーションのリソースリファレンスに設定して使用できません。

SQL ServerのJDBCドライバ
DBConnector_SQLServer_CP.rar
SQL Server 2000（Windowsの場合だけ）への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_SQLServer2005_CP.rar
SQL Server 2005（Windowsの場合だけ）またはSQL Server 2008（Windowsの場合だけ）への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

注　新規に，DB ConnectorのRARファイルを使用する場合，アプリケーションサーバで提供するConnector属性ファイルのテンプレートファイルを使用して，プロパティを定義できます。Connector属性ファイルのテンプレートファイルは，すべてのDB ConnectorのRARファイルに対して提供しています。提供しているテンプレートファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.14　Connector属性ファイルのテンプレートファイル」を参照してください。

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

リソースアダプタを使用してリソースと接続する場合，リソースアダプタをJ2EEリソースアダプタとしてデプロイしてください。J2EEリソースアダプタとは，J2EEサーバ上に配置されたリソースアダプタです。デプロイ方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.7　リソースアダプタの設定方法」を参照してください。

＜この項の構成＞

(1)　リソースアダプタの機能

(2)　リソースアダプタ以外の機能

(3)　リソースアダプタのオプショナル名についての注意事項

(1)　リソースアダプタの機能

バッチサーバの場合にデータベース接続で使用できる機能を次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2-21　リソースアダプタの機能

機能
項目
説明
参照先マニュアル※1
参照個所

パフォーマンスチューニングのための機能
コネクションプーリング
コネクションをメモリ上にプールしておくことで，アプリケーションからの接続要求に対して高速に処理できます。
基本・開発編(コンテナ共通機能)
3.14.1

コネクションプールのウォーミングアップ
サーバ起動時またはリソースアダプタ起動時に，指定した数のコネクションを作成します。コネクションをプールしておくことで，コネクションプール開始直後の接続要求を高速に処理します。
3.14.2

コネクション数調節機能
一定間隔で，プール内の不要なコネクションを段階的に減少させます。
3.14.2

コネクションシェアリング・アソシエーション
コネクションを共有することで，コネクション取得処理に掛かる処理時間を短縮できます。
コネクションシェアリングでは，論理コネクションと接続先リソースのコネクションである物理コネクションを多対1で接続します。
バッチアプリケーションの場合，コネクションアソシエーションは使用できません。
3.14.3

ステートメントプーリング
PreparedStatementおよびCallableStatementを使用する処理の場合に，これらのステートメントをプーリングしておくことで，同じステートメント作成に掛かる処理時間を短縮できます。
3.14.4

DataSourceオブジェクトのキャッシング
JNDIインタフェースを使用して，DataSource型のオブジェクトの検索要求をする場合，DataSourceオブジェクトをキャッシングできます。
3.14.7

DB Connectorのコンテナ管理でのサインオンの最適化
コンテナ管理でサインオンをする場合，サインオンの動作を最適化できます。
3.14.8

フォールトトレランスのための機能
コネクション障害検知
プーリングされているコネクションにトラブルが発生していないかを検知できます。これによって，ユーザプログラムからのコネクション要求に対して，有効なコネクションだけを返却できます。
3.15.1

コネクション枯渇時のコネクション取得待ち
コネクションプールに指定した最大数までコネクションがプールされていて，利用できるコネクションがない場合は，コネクション取得要求を待ち状態にできます。
3.15.2

コネクション取得リトライ
使用できるコネクションがコネクションプールにない場合や接続先リソースの物理コネクションの確立に失敗した場合に，自動的にコネクションの取得処理を再実行できます。
3.15.3

コネクションプールの情報表示
コマンドを使用して，コネクションプール内のコネクションの情報を表示できます。
3.15.4

コネクションプールのクリア
データベースサーバにトラブルが発生してコネクションが切断された場合などに，不要なコネクションプールをコマンドで削除できます。
3.15.5

ステートメントキャンセル
実行中のSQL処理が返ってこない状態でトランザクションタイムアウトが発生した場合に，ステートメントをキャンセルできます。
3.15.8

障害調査用SQLの出力
デッドロックやスローダウンなどの障害が発生した場合に，発行したSQLをログに出力できます。ログは，障害要因の解析に利用できます。
3.15.10

オブジェクトの自動クローズ
ユーザプログラムでオープンしたStatementオブジェクトなどをクローズできなかった場合に，DB Connectorによってオブジェクトを自動的にクローズできます。
3.15.11

コネクションプールのクラスタ化
コネクションプールの一時停止
データベースをクラスタ構成にしている場合に，障害発生時やメンテナンス時にコネクションプールを停止したり再開したりできます。また，それぞれのコネクションプールの状態を表示できます。
3.17.3

コネクションプールの再開
3.17.3

コネクションプールの状態
3.17.3

リソースへの接続テスト
リソースへの接続テスト
環境構築時に，リソースアダプタが正しく設定できているかどうかを確認できます。
3.18

Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）
J2EEリソースへの別名付与※2
J2EEリソースに別名を付与できます。バッチアプリケーションからは，別名として設定した任意の名称でルックアップできます。
2.4

性能解析トレースを使用したシステムの性能解析
コネクションIDのPRFトレース
各機能が出力する性能解析情報を収集します。この情報を基に，システム性能およびボトルネックを分析できます。
保守／移行／互換編
7章

注※1　参照先のマニュアル名称は，「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

注※2　バッチサーバの場合，リソースアダプタの別名は必ず使用します。

リソースアダプタの種類ごとに使用できる機能を次の表に示します。

表2-22　リソースアダプタの種類ごとに使用できる機能

機能 | 項目 | リソースアダプタの種類
DB Connector | ルートリソースアダプタ | メンバリソースアダプタ
パフォーマンスチューニングのための機能 | コネクションプーリング | ○ | × | ◎
コネクションプールのウォーミングアップ | ○ | × | ○
コネクション数調節機能 | ○ | × | ○
コネクションシェアリング・アソシエーション※ | ○ | × | ○
ステートメントプーリング | ○ | × | ○
DataSourceオブジェクトのキャッシング | ○ | ○ | ×
DB Connectorのコンテナ管理でのサインオンの最適化 | ○ | × | ○
フォールトトレランスのための機能 | コネクション障害検知 | ○ | × | ◎
コネクション枯渇時のコネクション取得待ち | ○ | × | ◎
コネクション取得リトライ | ○ | × | ×
コネクションプールの情報表示 | ○ | × | ○
コネクションプールのクリア | ○ | × | ○
ステートメントキャンセル | ○ | × | ○
障害調査用SQLの出力 | ◎ | × | ◎
オブジェクトの自動クローズ | ○ | × | ○
コネクションプールのクラスタ化 | コネクションプールの一時停止 | × | × | ○
コネクションプールの再開 | × | × | ○
コネクションプールの状態 | ○ | × | ○
リソースへの接続テスト | リソースへの接続テスト | ○ | ○ | ○
Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能） | J2EEリソースへの別名付与※ | ○ | ○ | ×
性能解析トレースを使用したシステムの性能解析 | コネクションIDのPRFトレース | ○ | ○ | ○

（凡例）

◎：必ず有効になる

○：使用できる

×：使用できない

注※　バッチアプリケーションの場合，コネクションアソシエーションは使用できません。

(2)　リソースアダプタ以外の機能

ここでは，リソースアダプタ以外で実現される機能について説明します。ここで説明する機能は，リソースアダプタの種類に関係なく使用できます。

リソースアダプタ以外で実現される機能を，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2-23　リソースアダプタ以外の機能

機能 | 項目 | 説明 | 参照先マニュアル※ | 参照個所
パフォーマンスチューニングのための機能 | ライトトランザクション | ローカルトランザクションに最適化された環境を提供します。ライトトランザクション機能は必ず有効にします。 | 基本・開発編(コンテナ共通機能) | 3.14
フォールトトレランスのための機能 | トランザクションタイムアウト | トランザクション開始時間から一定時間経過した時点で呼び出し先のトランザクションをロールバックします。 | 基本・開発編(コンテナ共通機能) | 3.15

注※　参照先のマニュアル名称は，「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

注意

J2EEサーバのトランザクション管理の機能では，トランザクションを自動決着する機能がありますが，バッチサーバの場合，トランザクションの自動決着機能は使用できません。

(3)　リソースアダプタのオプショナル名についての注意事項

同じオプショナル名で複数のリソースアダプタをデプロイしている場合，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。

2.7.5　リソースアダプタの設定方法

バッチアプリケーションからデータベースに接続するには，DB Connectorというリソースアダプタを使用します。ここでは，バッチサーバで使用するリソースアダプタの設定について説明します。バッチサーバの場合，リソースアダプタは，J2EEリソースアダプタとしてデプロイして使用します。

参考

リソースアダプタがDB Connectorの場合，アプリケーションサーバが提供するConnector属性ファイルのテンプレートファイルが使用できます。Connector属性ファイルのテンプレートファイルを使用すると，DB Connectorをインポートする前に，Connector属性ファイルを編集しておくことができます。このため，編集対象のConnector属性ファイルをサーバ管理コマンド（cjgetrarpropコマンドまたはcjgetrespropコマンド）で取得する操作が不要になります。Connector属性ファイルのテンプレートは，次の場所に格納されています。テンプレートファイルはコピーして使用してください。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥CC¥admin¥templates¥

UNIXの場合
/opt/Cosminexus/CC/admin/templates/

なお，Connector属性ファイルのテンプレートファイル，およびテンプレートファイル使用時の注意事項については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.14　Connector属性ファイルのテンプレートファイル」を参照してください。

注意

アプリケーションサーバ 07-10よりも前のバージョンで使用していたリソースアダプタをアプリケーションサーバ 07-10以降で使用する場合には，リソースアダプタの移行作業が必要です。リソースの移行方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「12.1.8　リソースアダプタの移行コマンドの実行」を参照してください。

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

リソースアダプタの設定には，サーバ管理コマンドを使用します。バッチサーバの場合，リソースアダプタは，J2EEリソースアダプタとしてデプロイして使用します。

バッチサーバで使用するリソースアダプタの新規設定の流れを次の図に示します。

図2-12　バッチサーバで使用するリソースアダプタの新規設定の流れ

注※　Server Plug-inでも操作できます。Server Plug-inを使用した操作方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「14.　リソースアダプタの設定」を参照してください。

図中の1.～4.について説明します。

サーバ管理コマンドを使用してリソースアダプタをインポートします。
cjimportresコマンドを使用して，リソースアダプタをインポートします。
インポートするリソースアダプタについては，「2.7.3　DB Connector（RARファイル）の種類」を参照してください。

サーバ管理コマンドを使用してリソースアダプタをデプロイします。
cjdeployrarコマンドを使用して，リソースアダプタをデプロイします。
リソースアダプタは，デプロイするとJ2EEリソースアダプタとして使用できます。J2EEリソースアダプタとは，バッチサーバに共有スタンドアロンモジュールとして配備したリソースアダプタのことです。サーバ管理コマンドでインポートしたリソースアダプタをデプロイすると，バッチサーバ上で使用できるようになります。

サーバ管理コマンドを使用してリソースアダプタのプロパティを定義します。
cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。
バッチサーバの場合，ユーザ指定名前空間機能を使用してリソースアダプタに別名を設定してください。ユーザ指定名前空間機能を使用した別名の設定は，リソースアダプタのプロパティで定義します。ユーザ指定名前空間機能の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。
リソースアダプタのプロパティ定義で設定できる内容については，「2.7.7(2)　リソースアダプタの設定」を参照してください。

サーバ管理コマンドを使用してリソースアダプタの接続テストを実施します。
cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。リソースごとの接続テストでの検証内容については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.18　リソースへの接続テスト」を参照してください。

サーバ管理コマンドでの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，cjimportresコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjimportres（リソースのインポート）」を参照してください。cjdeployrarコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjdeployrar（リソースアダプタのデプロイ）」を参照してください。cjgetrarpropコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjgetrarprop（RARファイルの属性の取得）」を参照してください。cjtestresコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjtestres（リソースの接続テスト）」を参照してください。属性については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

なお，次の手順については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.8　リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）」を参照してください。その際，「J2EEサーバ」を「バッチサーバ」に，「J2EEアプリケーション」を「バッチアプリケーション」に置き換えてお読みください。

コネクションプールのクラスタ化機能を使用する場合のリソースアダプタの設定の流れ

リソースアダプタの設定を変更する場合の流れ

リソースアダプタを入れ替える場合の流れ

参考

次のような場合，リソースアダプタをエクスポート・インポートすることで，効率良くリソースアダプタを設定できます。

開発環境で設定したリソースアダプタをエクスポートして，運用環境にインポートして使用する場合

運用環境ですでに動いているリソースアダプタをエクスポートして，増設したバッチサーバにインポートして使用する場合

エクスポートとインポートはcjexportrarとcjimportresで実行します。

なお，アプリケーションサーバのバージョンやプラットフォームが異なるホスト間では，リソースアダプタをエクスポート・インポートして使用することはできません。リソースアダプタをエクスポートするホストと，アプリケーションサーバのバージョンやプラットフォームが異なるホストでリソースアダプタを設定する場合は，リソースアダプタを新規に設定してください。

2.7.7　実行環境での設定

リソース接続機能を使用する場合，バッチサーバおよびリソースアダプタの設定が必要です。

ここでは，リソース接続機能を使用するための設定について説明します。

＜この項の構成＞

(1)　バッチサーバの設定

(2)　リソースアダプタの設定

(1)　バッチサーバの設定

バッチサーバの設定は，簡易構築定義ファイルで実施します。バッチアプリケーション実行機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリソース接続機能の定義を次の表に示します。

表2-24　簡易構築定義ファイルでのリソース接続機能の定義

項目 | 指定するパラメタ | 設定内容
アプリケーションサーバが管理するトランザクションの外でのコネクションシェアリングの有効化 | ejbserver.connectionpool.sharingOutsideTransactionScope.enabled | アプリケーションサーバが管理するトランザクションの外で複数回コネクションの取得を行ったときの，コネクションシェアリングの動作を指定します。
DataSourceオブジェクトのキャッシング | ejbserver.jndi.cache.reference | DataSourceオブジェクトのキャッシングを有効にするかどうかを指定します。
DB Connectorのコンテナ管理でのサインオンの最適化 | ejbserver.connectionpool.applicationAuthentication.disabled | コンテナ管理のサインオンの最適化機能を有効にするかどうかを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　リソースアダプタの設定

リソースに接続するバッチアプリケーションの場合，ユーザ指定名前空間機能を使用してリソースアダプタに別名を設定します。バッチアプリケーションからリソースアダプタをルックアップするには，ユーザ指定名前空間機能で設定した別名を使用します。ユーザ指定名前空間機能の設定については，「2.3.8　バッチアプリケーションの実装（リソースに接続する場合）」を参照してください。

参考

リソースの設定をする前に，リソースの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。リソース設定時の注意事項や，サーバ管理コマンドを使用するための動作設定については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「10.6.1　リソースの設定の前に」を参照してください。

リソースアダプタの設定は，Connector属性ファイルで実施します。

Connector属性ファイルでのリソース接続機能の定義を次の表に示します。

表2-25　Connector属性ファイルでのリソース接続機能の定義

分類
項目
設定内容

一般情報
トランザクションサポートレベル
<transaction-support>タグで，トランザクションサポートレベルを設定します。トランザクション管理なし（NoTransaction），またはローカルトランザクション（LocalTransaction）を指定します。バッチサーバの場合，グローバルトランザクション（XATransaction）は指定できません。

コンフィグレーションプロパティ
データベースコネクション確立までの待ち時間
<config-property>タグのloginTimeoutで，データベースコネクション確立までのバッチアプリケーションの待ち時間を指定します。

ステートメントキャンセル
<config-property>タグのCancelStatementで，トランザクションタイムアウト発生時のステートメントキャンセルを有効にするかどうかを指定します。

PreparedStatementのプールサイズ※1
<config-property>タグのPreparedStatementPoolSizeで，PreparedStatementのプールサイズを指定します。

CallableStatementのプールサイズ※1
<config-property>タグのCallableStatementPoolSizeで，CallableStatementのプールサイズを指定します。

実行時プロパティ
コネクションの最小値と最大値
<property>タグのMinPoolSizeとMaxPoolSizeで，コネクションプールにプールするコネクションの最小値と最大値を指定します。

コネクションの障害検知
<property>タグのValidationTypeでコネクションの障害を検知するタイミングを指定し，ValidationIntervalで障害を検知する間隔を指定します。
なお，コネクションの障害検知にタイムアウトを設定する場合には，NetworkFailureTimeoutでコネクション管理スレッドの使用を有効にします。※2

コネクションの取得リトライ
<property>タグのRetryCountでコネクション取得に失敗した場合のリトライ回数を指定し，RetryIntervalでリトライ間隔を指定します。

コネクションスイーパ
<property>タグのSweeperIntervalでコネクションの自動破棄（コネクションスイーパ）が動作する間隔を指定し，ConnectionTimeoutでコネクションの最終利用時刻からコネクションを自動破棄するかどうかを判定するまでの時間を指定します。

コネクション枯渇時のコネクション取得待ち
<property>タグのRequestQueueEnableでコネクション枯渇時のコネクション取得待ちを有効にするかどうかを指定し，RequestQueueTimeoutで待ち時間を指定します。

コネクションプールのウォーミングアップ
コネクションプールのウォーミングアップ機能を使用する場合，<property>タグで，Warmupを指定します。

コネクション管理スレッド
コネクション管理スレッドを使用する場合，<property>タグで，NetworkFailureTimeoutを指定します。
コネクション管理スレッドを使用する場合，コネクションの障害検知機能，およびコネクション数調節機能のタイムアウトを使用する設定になります。

コネクション数調節機能
<property>タグのConnectionPoolAdjustmentIntervalで，コネクション数調節機能が動作する間隔を指定します。
なお，コネクション数調節機能にタイムアウトを設定する場合には，NetworkFailureTimeoutでコネクション管理スレッドの使用を有効にします。※2

注　Connector属性ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

注※1　XDM/RD E2 11-01以前のバージョンの場合，ステートメントプーリング機能を利用できないため，これらのプロパティには0を指定してください。

注※2　同じキーで設定します。このため，コネクションの障害検知機能でタイムアウトを使用する場合は，コネクション数調節機能でもタイムアウトを使用する設定となります。なお，タイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキー（ejbserver.connectionpool.validation.timeout）に，任意の時間を指定してください（デフォルト値は5秒）。

なお，DB Connectorを使用してデータベースに接続する場合に設定する，DB Connectorのプロパティ定義については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.1.2　設定する項目と操作の概要」を参照してください。

2.8　トランザクション管理

この節では，リソース接続時のトランザクション管理について説明します。

この節の構成を次の表に示します。

表2-26　この節の構成（トランザクション管理）

分類 | タイトル | 参照先
解説 | リソース接続時のトランザクション管理の概要 | 2.8.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.8.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

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

2.8.2　実行環境での設定（バッチサーバの設定）

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

リソース接続時のトランザクションを管理する方法には，アプリケーションサーバで管理する方法と，アプリケーションサーバが管理しないでユーザが直接管理する方法があります。データベースへの接続では，アプリケーションサーバのトランザクションマネジャを使用してトランザクションを管理できます。トランザクション管理については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4.1　リソース接続でのトランザクション管理の方法」を参照してください。

バッチサーバで使用できるトランザクションは，ローカルトランザクションです。グローバルトランザクションは使用できません。また，バッチサーバでは，必ずライトトランザクション機能を有効にしてください。ライトトランザクション機能とは，ローカルトランザクションに最適化された環境を提供する機能です。ローカルトランザクションおよびライトトランザクション機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4.2　ローカルトランザクションとグローバルトランザクション」を参照してください。

また，EJB呼び出し時に，呼び出し先でシステム例外が発生したときの，呼び出し元，呼び出し先のトランザクションは，それぞれ次のように動作します。

呼び出し元のトランザクション

トランザクションはロールバックにマークされません。

呼び出し先のトランザクション

トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

2.8.2　実行環境での設定（バッチサーバの設定）

トランザクション管理の機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。トランザクション管理の機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

ejbserver.jta.TransactionManager.defaultTimeOut
バッチサーバ上で開始されるトランザクションのタイムアウトのデフォルト値を指定します。

なお，トランザクションタイムアウトについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15　フォールトトレランスのための機能」を参照してください。簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

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

バッチサーバでは，ガーベージコレクション制御機能を使用できます。この節ではガーベージコレクション制御機能の概要，処理の流れおよび設定方法について説明します。

この節の構成を次の表に示します。

表2-27　この節の構成（ガーベージコレクション制御機能）

分類 | タイトル | 参照先
解説 | ガーベージコレクション制御機能の概要 | 2.9.1
ガーベージコレクション制御の処理の流れ | 2.9.2
設定 | 実行環境での設定（バッチサーバの設定） | 2.9.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

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

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

2.9.3　実行環境での設定（バッチサーバの設定）

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

ガーベージコレクションとは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。ガーベージコレクションはJavaVMが実行します。

ガーベージコレクションには処理時間が掛かります。また，ガーベージコレクション実行中は，JavaVM上のすべてのプログラム処理が中断するため，ガーベージコレクションを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

バッチサーバでは，バッチアプリケーションが長時間リソースを排他するのを回避するため，ガーベージコレクション制御機能を提供しています。ガーベージコレクション制御機能とは，リソースが排他されていないときに明示的にフルガーベージコレクションを実行するための機能です。ガーベージコレクション制御機能の利用によって，リソースの排他中にフルガーベージコレクションが発生するのを回避できます。

ガーベージコレクション制御機能について，例を使用して説明します。

ガーベージコレクション制御機能を使用していない場合，バッチ処理と並行してオンライン処理を実行する環境では，次の図に示す問題があります。

図2-13　ガーベージコレクション制御機能を使用していない場合

この図では，バッチアプリケーションでのリソース排他中に，フルガーベージコレクションが発生しています。これによって，バッチアプリケーションはリソースを排他したまま処理が中断します。また，この間にオンライン処理から排他中のレコードが参照されると，オンライン処理もバッチサーバのフルガーベージコレクションが終了するまで中断します。

ガーベージコレクション制御機能を使用すると次の図のようになります。

図2-14　ガーベージコレクション制御機能を使用している場合

図のように，フルガーベージコレクションの実行要求が出たときに，バッチアプリケーションでリソースを排他していると，フルガーベージコレクションの実行は待ち状態になります。

レコードの排他が解除されると，バッチサーバでフルガーベージコレクションが実行されます。また，オンライン処理もリソースへのアクセスができるようになります。これによって，バッチアプリケーションでの長時間のリソース排他を回避できます。

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

ガーベージコレクション制御は次の流れで処理されます。

図2-15　ガーベージコレクション制御の処理の流れ

メモリ監視
監視タイマスレッドは，JavaVMのメモリを監視します。(1)に示す条件を満たすと，ガーベージコレクション制御機能にガーベージコレクション実行要求が出されます。

リソース排他のチェック
ガーベージコレクション実行要求が出されると，ガーベージコレクション制御機能はリソース排他中かどうかを調査します。

フルガーベージコレクションの実行待ち
リソース排他中の場合，フルガーベージコレクションの実行は待ち状態になります。

フルガーベージコレクションの実行
リソースの排他が解除されると，フルガーベージコレクションが実行されます。

それぞれの処理について説明します。

＜この項の構成＞

(1)　メモリ監視

(2)　リソース排他のチェック

(3)　フルガーベージコレクションの実行待ち

(4)　ガーベージコレクションの実行

(5)　注意事項

(1)　メモリ監視

監視タイマスレッドはJavaVMのメモリを監視し，次のどれかの条件を満たす場合，ガーベージコレクション制御機能にガーベージコレクションの実行要求を出します。

Tenured領域消費サイズ/Tenured領域合計サイズ×100≧ガーベージコレクション制御のしきい値

New領域合計サイズ/Tenured領域最大空きサイズ×100≧ガーベージコレクション制御のしきい値

Permanent領域消費サイズ/Permanent領域合計サイズ×100≧ガーベージコレクション制御のしきい値

(2)　リソース排他のチェック

ガーベージコレクション実行が要求されると，ガーベージコレクション制御機能は，バッチアプリケーションが使用しているコネクションを調査します。コネクションの調査では，バッチアプリケーションがリソース排他中かどうかを確認します。

次の表にリソースの排他中と見なす状態を示します。

表2-28　リソースの排他中と見なす状態

トランザクション
状態
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)　フルガーベージコレクションの実行待ち

リソース排他中と判断されると，メッセージKDJE55024-Iを出力して，フルガーベージコレクションの実行待ち状態になります。リソース排他が一つでもあると，フルガーベージコレクションは待機し続けます。フルガーベージコレクション実行待ちの例を次の図に示します。

図2-16　フルガーベージコレクション実行待ちの例

この図では，一つのジョブプログラム中で二つのリソースにアクセスしています。リソース排他中にフルガーベージコレクションの実行が要求されると，ガーベージコレクション制御機能はフルガーベージコレクションの実行を待機状態にします。二つのリソースアクセスが終了するcon2.commit()が実行されると，排他が解除されます。

(4)　ガーベージコレクションの実行

リソース排他がなくなると，フルガーベージコレクションが実行されます。

(5)　注意事項

同時に実行できるバッチアプリケーションは一つだけです。

一つのバッチアプリケーションから複数のリソースへの処理ができます。ただし，グローバルトランザクションは使用できません。

フルガーベージコレクションの実行待ち状態でも，空きメモリが不足すると，JavaVMによってフルガーベージコレクションが実行されることがあります。これは，ガーベージコレクション実行時のメモリ使用量のしきい値が大きい場合や，リソースの排他区間が長い場合などに発生します。マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「9.4　ガーベージコレクション制御で使用するしきい値を設定する」を参照して，メモリ使用量のしきい値をチューニングしてください。

2.9.3　実行環境での設定（バッチサーバの設定）

ガーベージコレクション制御機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。ガーベージコレクション制御機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

ejbserver.batch.gc.watch.threshold
ガーベージコレクションを実行する条件となるメモリ使用量のしきい値を指定します。

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

バッチサーバでは，アプリケーション間で共通に利用したい処理がある場合に，ユーザ作成のライブラリを利用できます。ユーザ作成のライブラリを利用することで，アプリケーションの機能を拡張できます。この節では，コンテナ拡張ライブラリの概要および設定方法について説明します。

この節の構成を次の表に示します。

表2-29　この節の構成（コンテナ拡張ライブラリ）

分類 | タイトル | 参照先
解説 | コンテナ拡張ライブラリの概要 | 2.10.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.10.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.10.1　コンテナ拡張ライブラリの概要

2.10.2　実行環境での設定（バッチサーバの設定）

2.10.1　コンテナ拡張ライブラリの概要

アプリケーションが共通に利用できるライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することで，アプリケーション間で共通して，ユーザ作成のライブラリを呼び出せるようになります。

バッチサーバではコンテナ拡張ライブラリを利用できますが，バッチアプリケーション自体をコンテナ拡張ライブラリに設定して使用することはできません。

また，サーバ起動・停止フック機能を利用することで，サーバの起動，終了時にコンテナ拡張ライブラリが呼び出されるようにできます。また，コンテナ拡張ライブラリで使用するJNI機能の初期化などを行うことができます。

コンテナ拡張ライブラリを使用するためには，ライブラリを一つのJARファイルにまとめ，コンテナ拡張ライブラリを使用するための設定をusrconf.cfgで定義します。また，コンテナ拡張ライブラリがJNIを利用する場合は，サーバ起動・停止フック機能を使用するための設定も必要です。

なお，コンテナ拡張ライブラリの利用の概要については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13.2　コンテナ拡張ライブラリの利用」を参照してください。サーバ起動・停止フック機能の実装方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13.4.2　サーバ起動・停止フック機能の実装方法」を参照してください。

注意

コンテナ拡張ライブラリには，次のアクセス権が付与されます。アクセス権は変更できません。

java.security.AllPermission

ただし，java.lang.RuntimePermissionのsetSecurityManagerアクセス権は付与されません。

2.10.2　実行環境での設定（バッチサーバの設定）

コンテナ拡張ライブラリの機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。コンテナ拡張ライブラリの機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

add.class.path
コンテナ拡張ライブラリのJARファイルのパスを指定します。

add.library.path
JNI用ライブラリの検索パスを指定します。

コンテナ拡張ライブラリの機能を使用するための設定方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13.3.3　コンテナ拡張ライブラリの機能を使用するための設定」を参照してください。

2.11　日立固有のJavaVMの機能

この節では，日立固有のJavaVMの機能について説明します。

この節の構成を次の表に示します。

表2-30　この節の構成（日立固有のJavaVMの機能）

分類 | タイトル | 参照先
解説 | 日立固有のJavaVMの機能の概要 | 2.11.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.11.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.11.1　日立固有のJavaVMの機能の概要

2.11.2　実行環境での設定（バッチサーバの設定）

2.11.1　日立固有のJavaVMの機能の概要

アプリケーションサーバで動作するバッチサーバのプロセスは，JavaVM上で実行されます。

日立固有のJavaVMは，構成ソフトウェアであるCosminexus Developer's Kit for Javaによって提供される，独自のJavaVMです。日立固有のJavaVMの機能を次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2-31　日立固有のJavaVMの機能

機能 | 説明 | 参照先マニュアル※ | 参照個所
明示管理ヒープ機能 | フルガーベージコレクション発生の要因になるJavaオブジェクトをExplicitヒープ領域に配置できます。アプリケーションで使用するJavaオブジェクトによる，フルガーベージコレクションの発生を抑止できます。 | このマニュアル | 8章
クラス別統計機能 | 各クラスのインスタンスが持つメンバの配下にあるすべてインスタンスのサイズを，クラス別統計情報として拡張スレッドダンプに出力できます。クラス別統計情報を複数回出力すると，ガーベージコレクションによるJavaオブジェクトの変化や，寿命が短いJavaオブジェクトの状態などを調査できます。クラス別統計情報を出力する機能としては，インスタンス統計機能，STATICメンバ統計機能，参照関係情報出力機能，統計前のガーベージコレクション選択機能，Tenured領域内不要オブジェクト統計機能，およびTenured増加要因の基点オブジェクトリスト出力機能があります。 | 保守／移行／互換編 | 8.3
クラス別統計情報解析機能 | 拡張スレッドダンプに出力したクラス別統計情報を基に，クラスごとのインスタンスの合計サイズ，およびクラスごとのインスタンス数を2種類のCSVファイルとして出力できます。 | 8.10
Survivor領域の年齢分布情報出力機能 | コピーガーベージコレクション実行時に，日立JavaVMログファイルにSurvivor領域のJavaオブジェクトの年齢分布を出力できます。Survivor領域の使用状況が調査でき，メモリサイズのチューニングに使用できます。 | 8.11
ファイナライズ滞留解消機能 | ファイナライズ処理の滞留を解消することで，OS資源の解放遅れなどの発生を抑止できます。 | 8.12
hndlwrap機能 | ログオフ時のJavaVMのログオフイベントの発生を抑止できます。 | 8.13

注※　参照先のマニュアル名称は，「Cosminexus アプリケーションサーバ 機能解説」を省略しています。

また，日立固有のJavaVMでは，障害発生時の要因分析やシステムの状態確認に利用できるよう，ログの出力内容が拡張されています。このログは，日立JavaVMログファイルに出力され，標準のJavaVMよりも，多くのトラブルシュート情報が取得できます。さらに，このログ（拡張verbosegc情報）を利用して適切なチューニングを実施することで，システムの可用性向上が図れます。日立JavaVMログファイルについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「4.10　日立固有のJavaVMログ（日立JavaVMログファイル）」を参照してください。JavaVMのチューニングについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

2.11.2　実行環境での設定（バッチサーバの設定）

日立固有のJavaVMの機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。日立固有のJavaVMの機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの日立固有のJavaVMの機能の定義を次の表に示します。

表2-32　簡易構築定義ファイルでの日立固有のJavaVMの機能の定義

項目
指定するパラメタ
設定内容

パラメタ名
パラメタ値

明示管理ヒープ機能の利用
add.jvm.arg
-XX:+HitachiUseExplicitMemory
バッチアプリケーションで明示管理ヒープ機能を実装している場合に，明示管理ヒープ機能の使用を指定します。
明示管理ヒープ機能使用時に設定できるJavaVMオプションについては，「8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」を参照してください。

Suvivor領域の年齢分布情報の出力
add.jvm.arg
-XX:+HitachiVerboseGCPrintTenuringDistribution
コピーガーベージコレクション発生時に，Suvivor領域のオブジェクトの年齢分布情報を日立JavaVMログファイルに出力することを指定します。

ファイナライズ処理での滞留の解消
add.jvm.arg
-DJP.co.Hitachi.soft.jvm.autofinalizer=true
ファイナライズ処理の滞留を解消することを指定します。

日立固有のJavaVMのログの取得（日立JavaVMログファイル）
add.jvm.arg
-XX:+HitachiOutOfMemoryStackTrace※
例外情報とスタックトレースを日立JavaVMログファイルに出力することを指定します。

-XX:+HitachiVerboseGC※
ガーベージコレクションが発生した場合に，拡張verbosegc情報を日立JavaVMログファイルに出力することを指定します。

-XX:+HitachiJavaClassLibTrace※
クラスライブラリのスタックトレースを日立JavaVMログファイルに出力することを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

注※　どれか一つでも指定すると，日立JavaVMログファイルを出力します。なお，-XX:+HitachiOutOfMemoryStackTraceを指定すると，-XX:+HitachiOutOfMemorySizeおよび-XX:+HitachiOutOfMemoryCauseも同時に指定されます。

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

アプリケーションサーバで提供するcjclstartapコマンドで実行していたJavaアプリケーションは，バッチサーバでバッチアプリケーションとして実行できます。Javaアプリケーションを，バッチサーバ上でバッチアプリケーションとして実行する場合，アプリケーションや実行環境の移行が必要となる場合があります。この節では，アプリケーションおよび実行環境の移行について，移行が必要な場合と移行方法を説明します。

この節の構成を次の表に示します。

表2-33　この節の構成（Javaアプリケーションからの移行）

分類 | タイトル | 参照先
実装 | バッチアプリケーションの実装（Javaアプリケーションからの移行） | 2.12.1
設定 | 実行環境での設定（バッチサーバの設定） | 2.12.2

注　「解説」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

2.12.1　バッチアプリケーションの実装（Javaアプリケーションからの移行）

2.12.2　実行環境での設定（バッチサーバの設定）

2.12.1　バッチアプリケーションの実装（Javaアプリケーションからの移行）

ここでは，Javaアプリケーションをバッチアプリケーションに移行する場合に，Javaアプリケーションで必要な変更について説明します。

次の場合，Javaアプリケーションの移行が必要になります。

バッチアプリケーションの使用上の注意事項に該当する処理を実装している場合
ファイルやディレクトリの操作などは，バッチアプリケーションに実装する際に注意が必要となります。

移行方法

バッチアプリケーションで注意が必要な処理は，「2.3.11(1)　注意が必要な処理」に記載しています。これらの内容を参照して，Javaアプリケーションを修正してください。

バッチアプリケーションで使用できない機能を実装している場合
バッチアプリケーションでは使用できない機能が幾つかあります。例えば，標準入力からの入力やJNIの使用はできません。

移行方法

バッチアプリケーションで使用できない機能および機能を使用するための代替方法は，「2.3.11(2)　バッチアプリケーションで実装できない機能」に記載しています。これらの内容を参照して，Javaアプリケーションを修正してください。

usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティを定義している場合
移行元のJavaアプリケーションで使用していたusrconf.properties（Javaアプリケーション用ユーザプロパティファイル）は引き続きバッチアプリケーションでも使用できます。
ただし，usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）の中に，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされていないプロパティ※を定義して，バッチアプリケーションから値を参照している場合はアプリケーションの修正が必要です。

移行方法

usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートしていないプロパティの値を参照しないように，バッチアプリケーションを修正してください。

注※

ユーザが定義したプロパティを除きます。なお，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）でサポートされているプロパティについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.7　usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）」を参照してください。

2.12.2　実行環境での設定（バッチサーバの設定）

Javaアプリケーションをバッチアプリケーションに移行する場合に，バッチサーバの設定の変更が必要な場合があります。ここでは，バッチサーバの設定で変更が必要な場合について説明します。

これまで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 アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.7　usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）」を参照してください。

2.13　JP1/AJS2との連携

バッチアプリケーションを実行するシステムは，JP1/AJS2と連携して運用できます。また，JP1/AJS2に加えて，BJEXを使用して運用することもできます。この節では，JP1/AJS2およびBJEXと連携する場合の設定について説明します。

この節の構成を次の表に示します。

表2-34　この節の構成（JP1/AJS2との連携）

分類 | タイトル | 参照先
設定 | JP1/AJS2と連携するための設定 | 2.13.1
JP1/AJS2およびBJEXと連携するための設定 | 2.13.2

注　「解説」，「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

参考

JP1/AJS2と連携するシステム，ならびにJP1/AJS2およびBJEXと連携するシステムの概要については，「2.2.1　バッチアプリケーションを実行するシステム」および「2.2.2　バッチサーバおよびバッチアプリケーションの操作の流れ」を参照してください。

＜この節の構成＞

2.13.1　JP1/AJS2と連携するための設定

2.13.2　JP1/AJS2およびBJEXと連携するための設定

2.13.1　JP1/AJS2と連携するための設定

ここでは，JP1/AJS2と連携する場合の，JP1/AJS2のジョブの定義について説明します。

なお，JP1/AJS2からバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

＜この項の構成＞

(1)　バッチアプリケーションの開始

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

(1)　バッチアプリケーションの開始

JP1/AJS2と連携する場合，cjexecjobコマンドをJP1/AJS2のUNIXジョブまたはPCジョブとして定義しておきます。JP1/AJS2のジョブの属性を定義する画面の「スクリプトファイル名」「パラメーター」および「実行時のユーザー」の項目には，次に示す内容を設定してください。

スクリプトファイル名
cjexecjobコマンドを指定します。cjexecjobコマンドのパスについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjexecjob（バッチアプリケーションの実行）」を参照してください。

パラメーター
実行するバッチアプリケーションのクラス名と引数を指定します。

実行時のユーザー
バッチサーバを実行するユーザを指定します。

なお，JP1/AJS2での設定の詳細については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

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

JP1/AJS2と連携する場合，ジョブネットまたはジョブの強制終了をする際に，cjkilljobコマンドをJP1/AJS2のリカバリージョブとして定義しておきます。ただし，ルートジョブネットを強制停止する場合は，リカバリージョブは実行されません。このため，バッチアプリケーションがバッチサーバ上で実行されたままになります。その場合は，cjkilljobコマンドを直接実行して，バッチアプリケーションを強制停止してください。

JP1/AJS2での設定の詳細については，マニュアル「JP1/Automatic Job Management System 2 操作ガイド」を参照してください。

2.13.2　JP1/AJS2およびBJEXと連携するための設定

ここでは，JP1/AJS2およびBJEXと連携する場合の，JP1/AJS2およびBJEXのジョブの定義について説明します。

なお，JP1/AJS2やBJEXからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

＜この項の構成＞

(1)　バッチアプリケーションの開始

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

(1)　バッチアプリケーションの開始

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 操作ガイド」を参照してください。

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

バッチアプリケーションの強制停止は，JP1/AJS2のリカバリージョブとして定義します。リカバリージョブの定義については，「2.13.1(2)　バッチアプリケーションの強制停止」を参照してください。

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

この章では，リクエストのスケジューリングと負荷分散について説明します。

業務システムには，局所的な障害発生時にシステムを止めることなく安定稼働できる信頼性と，随時変わっていく業務の処理要求に柔軟に対応できる可用性が求められます。アプリケーションサーバでは，これらの要求に対して，OLTP技術に対応したリクエストのスケジューリングや，サーバのクラスタリングによる負荷分散などによって対応します。

なお，この章で説明する機能は，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できる機能です。利用できる製品については，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

＜この章の構成＞

3.1　この章の構成

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

3.3　CTMのプロセス構成

3.4　リクエストの流量制御

3.5　リクエストの優先制御

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

3.7　リクエストの閉塞制御

3.8　リクエストの負荷分散

3.9　リクエストのキューの滞留監視

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

3.1　この章の構成

この章では，CTMを使用したリクエストのスケジューリングと負荷分散について説明します。CTMを使用すると，クライアントから送信されたリクエストの実行を適切にスケジューリングしたり，複数のJ2EEサーバに振り分けて処理したりできます。これによって，システムの安定稼働と処理性能向上を実現できます。

CTMを使用したリクエストのスケジューリングの概要については，「3.2　CTMを使用したリクエストのスケジューリングの概要」を参照してください。また，CTMを使用する場合のプロセス構成については，「3.3　CTMのプロセス構成」を参照してください。

CTMを使用して実行できる機能と参照先を次の表に示します。

表3-1　CTMの機能

機能名 | 参照先
リクエストの流量制御 | 3.4
リクエストの優先制御 | 3.5
リクエストの同時実行数の動的変更 | 3.6
リクエストの閉塞制御 | 3.7
リクエストの負荷分散 | 3.8
リクエストのキューの滞留監視 | 3.9
CTMのゲートウェイ機能を利用したTPBroker／OTMクライアントとの接続 | 3.10

また，CTMの稼働統計情報を収集することもできます。CTMの稼働統計情報の収集については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「10.　CTMの稼働統計情報の収集」を参照してください。

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

この節では，CTMを使用したリクエストのスケジューリングの概要について説明します。

アプリケーションサーバでは，リクエストのスケジューリングに，CTM（Cosminexus Component Transaction Monitor）という構成ソフトウェアを使用します。CTMは，それぞれのリクエストをキューを使用して制御します。このキューを，スケジュールキューといいます。

＜この節の構成＞

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

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

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

3.2.4　CTMを使用する場合に実行される処理

3.2.5　スケジュールキューの作成単位とキューの共有

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

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

規模の大きい業務システムでは，特定のJ2EEアプリケーションを実行しているJ2EEサーバに大量のリクエストが集中することがあります。それぞれのサーバの負荷を抑え，可用性を確保して業務を滞りなく進めるためには，リクエストの送り先を分散したり，一定時間内のリクエストの流量を制御したりすることが必要です。また，複数のJ2EEサーバで処理を分散する場合に，リクエストが送信された時点で負荷が最も掛かっていないJ2EEサーバに処理させることができれば，システム全体の処理性能を向上させられます。

これらを実現するのが，リクエストのスケジューリングです。これによって，それぞれのJ2EEサーバが持つ性能を十分に活用しながら，安定して稼働するシステムを構築できます。また，リクエストをスケジューリングすることで，特定のJ2EEサーバ，J2EEアプリケーションまたは業務処理プログラム（Enterprise Bean）にトラブルが発生した場合にも，該当する範囲だけを閉塞して縮退運転できるので，システム全体の可用性を高められます。

アプリケーションサーバでは，リクエストをスケジューリングすることで，次の6種類の機能を実現できます。

流量制御
J2EEサーバで一度に実行される処理数の最大値を制限することで，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現できます。

優先制御
クライアントに優先順位を付けておくことで，優先順位の高いクライアントからのリクエストを優先的に処理します。

同時実行数の動的変更
リクエストの同時実行数を一時的に変更したい場合に，CTMデーモンを停止しないで同時実行数を変更できます。

閉塞制御
特定のJ2EEアプリケーションに対するリクエストの受け付けを停止したり，リクエストを滞留したりすることで，システム全体を稼働させたままのメンテナンスを可能にします。これによって，システムの可用性が高められます。

負荷分散
J2EEサーバ間で負荷が均等になるように処理を分散して割り当て，システム全体の処理性能と可用性が高められます。

キューの滞留監視
スケジュールキューで滞留しているリクエストの数を監視できます。

3.2.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によるリクエストのスケジューリングの設定については，「3.4.2　実行環境での設定」を参照してください。

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

CTMを使用できるクライアントは，EJBクライアントである，次のクライアントです。

EJBクライアントアプリケーション

JSP／サーブレット

ほかのEnterprise Bean

これらを開発する時に，特別なインタフェースを使用する必要はありません。CTMデーモンと連携するグローバルCORBAネーミングサービス（ctmstartの-CTMINSRefオプションに指定したCORBAネーミングサービス）に対してルックアップするように設定してください。

ただし，システム内の特定のアプリケーションサーバに障害が発生した場合にルックアップ対象のCORBAネーミングサービスを切り替えられるように，lookup，create，invoke，removeのどの処理で例外が発生してもJNDIのlookupから処理をし直すようにコーディングしてください。

3.2.4　CTMを使用する場合に実行される処理

CTMを使用する場合，次のタイミングで，CTMを使用するための処理が実行されます。

J2EEサーバの起動処理

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

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

J2EEサーバの停止処理

ここでは，それぞれのタイミングで実行される処理について説明します。

＜この項の構成＞

(1)　J2EEサーバの起動処理

(2)　J2EEアプリケーションの開始処理

(3)　J2EEアプリケーションの停止処理

(4)　J2EEサーバの停止処理

(1)　J2EEサーバの起動処理

CTMを使用するようにカスタマイズされているJ2EEアプリケーションを開始するためには，J2EEサーバの起動時に，CTMデーモンとのコネクションを確立して初期化処理を実行する必要があります。コネクションの確立と初期化は，次の操作によって実行されます。

CTMを使用するための設定をします。

CTMデーモンを起動します。

J2EEサーバを起動します。

J2EEサーバが起動する時に，J2EEサーバによってコネクションの確立と初期化処理が実行されます。J2EEサーバの起動前に必ずCTMデーモンを起動してください。

CTMデーモンを使用するための設定については，「3.4.2　実行環境での設定」を参照してください。CTMデーモンおよびJ2EEサーバの起動については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「8.7　システムの一括起動（READY）」を参照してください。Smart Composer機能を使用してシステムを起動すると，CTMデーモン，J2EEサーバの順序で起動処理が実行されます。

なお，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を使用しない場合と同じように，J2EEアプリケーションの停止処理が実行されます。

(4)　J2EEサーバの停止処理

J2EEサーバを停止する時に，J2EEサーバとCTMデーモンとのコネクションが切断されます。

3.2.5　スケジュールキューの作成単位とキューの共有

キューは，J2EEアプリケーション単位，またはBean単位で作成できます。ここでは，スケジュールキューの構成と，キューの共有について説明します。また，キューを共有する場合としない場合の利点についても説明します。

＜この項の構成＞

(1)　スケジュールキューの作成単位

(2)　スケジュールキューの共有

(3)　スケジュールキューを共有する効果

(4)　スケジュールキューを共有しない効果

(1)　スケジュールキューの作成単位

クライアントからのリクエストは，CTMデーモンによって管理されるスケジュールキューによってスケジューリングされます。スケジュールキューは，J2EEアプリケーション単位またはBean単位で作成されます。デフォルトのキュー名称は，J2EEアプリケーション単位の場合はJ2EEアプリケーションの名称，Bean単位の場合はBean名となります。

(2)　スケジュールキューの共有

J2EEアプリケーション単位またはBean単位でスケジュールキューを持つことで，異なるインタフェースを持つ業務処理プログラム間，またはJ2EEアプリケーションのBean間でキューを共有できます。なお，スケジュールキューで制御されるリクエストは，「EJBホームリファレンスのグローバルCORBAネーミングサービス登録名称」と「業務処理プログラムのリモートインタフェース名称」の組み合わせで管理されます。

スケジュールキューは，同じCTMデーモンに対応づけられている，次のJ2EEアプリケーション間またはBean間で共有できます。

J2EEアプリケーション間で共有する場合

キュー名称が同じである

業務処理プログラムの構成が同じである（J2EEアプリケーションに含まれるEnterprise Beanが，CTMが認識する範囲で完全に一致する）

Bean間で共有する場合

キュー名称が同じである

Beanが同じである

同じ業務処理プログラム構成でもキュー名称が異なる場合や，同じキュー名称でも異なる業務処理プログラム構成を持つJ2EEアプリケーション間では，スケジュールキューは共有できません。

複数のJ2EEサーバ間でスケジュールキューを共有することもできます。ただし，その場合は，ユーザ指定名前空間機能を使用して，それぞれの業務処理プログラムであるEnterprise Beanに別名（Optional Name）を付与する必要があります。ユーザ指定名前空間機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.3　JNDI名前空間へのオブジェクトのバインドとルックアップ」を参照してください。別名の付与は，J2EEアプリケーションのプロパティとして設定します。

参考

デフォルトの設定でJ2EEアプリケーションをインポートすると，業務処理プログラムをルックアップするための名称が「/HITACHI_EJB/SERVERS/＜J2EEサーバ名称＞/EJB/＜J2EEアプリケーション名称＞/＜業務処理プログラムの名称＞」になります。この場合，ルックアップ名称にJ2EEサーバ名称が含まれてしまうため，J2EEサーバ間でスケジュールキューを共有できません。

一つのJ2EEサーバ内で複数のJ2EEアプリケーションを同一名称でインポートして，スケジュールキューを共有することはできません。

(3)　スケジュールキューを共有する効果

スケジュールキューを共有する効果について，J2EEアプリケーション単位での共有と，Bean単位での共有に分けて説明します。

(a)　J2EEアプリケーション単位の場合

スケジュールキューを共有すると，複数のJ2EEサーバ上のJ2EEアプリケーションで，リクエストを分散処理できます。

スケジュールキューの共有には，次のような効果があります。

キューを共有するJ2EEアプリケーション間で同時実行スレッド数を制御できるので，特定のJ2EEアプリケーションに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。

キューを共有しているどちらかのJ2EEサーバで障害が発生した場合に，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバのJ2EEアプリケーションで処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図3-1　スケジュールキューを共有する例（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で処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図3-2　スケジュールキューを共有する例（Bean単位）

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2上のBean Aに処理が振り分けられます。

(4)　スケジュールキューを共有しない効果

スケジュールキューを共有しない場合，異なるJ2EEサーバに同じJ2EEアプリケーションがインポートされていたり，J2EEサーバ上に同じBeanがあったりしても，リクエストはそれぞれのキューで制御され，実行されます。

スケジュールキューを共有しないと，負荷分散や縮退運転はできなくなりますが，異なるスケジュールキューでリクエストが滞留してもその影響を受けなくなるため，優先的に業務処理を進められます。

スケジュールキューを共有しない場合は，それぞれのJ2EEアプリケーションに含まれる業務処理プログラムに別名を指定しないで，それぞれ異なるルックアップ名称にします。

スケジュールキューを共有しない例を次の図に示します。

図3-3　スケジュールキューを共有しない例

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有していない場合，指定したJ2EEアプリケーションを制御するキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXが制御しているJ2EEサーバ1に処理が振り分けられます。

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

スケジュールキューの長さは，次の単位で設定できます。

CTMデーモン単位

J2EEアプリケーション単位

Session Bean単位

CTMデーモン単位の設定については，「3.3.3(2)　スケジュールキューへのリクエストの登録」を参照してください。

J2EEアプリケーション単位またはSession Bean単位の設定は，アプリケーション属性ファイルまたはSession Bean属性ファイルの<scheduling>-<queue-length>タグで設定します。CTMによるリクエストのスケジューリングの設定については，「3.4.2(3)　サーバ管理コマンドでの設定」を参照してください。

ただし，スケジュールキューを共有する場合は，スケジュールキューはすでに作成されているため，指定したスケジュールキューの長さは無効になります。

3.3　CTMのプロセス構成

CTMを使用してリクエストをスケジューリングする環境のプロセス構成と配置の指針について説明します。また，各プロセスの機能についても説明します。

＜この節の構成＞

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

3.3.2　プロセス配置の指針

3.3.3　CTMデーモン

3.3.4　CTMレギュレータ

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

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

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

CTMを使用する場合のプロセスの配置例を次の図に示します。

図3-4　CTMを構成するプロセスの配置例

各プロセスの主な機能について，次の表で説明します。

表3-2　CTMで使用するプロセス

プロセス
説明

CTMデーモン
クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。

CTMレギュレータ
CTMデーモンに集中するリクエストを，分散集約するためのプロセスです。

CTMドメインマネジャ
CTMドメインを管理するプロセスです。CTMドメインは，複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。

グローバルCORBAネーミングサービス
同じCTMドメイン内に含まれるホスト上の業務処理プログラムの情報を共有管理しているネーミングサービスです。

PRFデーモン
（パフォーマンストレーサ）
CTMデーモンが出力した性能解析情報をファイルに出力する，I／Oプロセスです。
詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「6.5　実行環境での設定」を参照してください。

スマートエージェント
Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。CTMによるリクエストのスケジューリングをする場合，スマートエージェントが必要です。
詳細は，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

3.3.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 アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.　システムの起動と停止」を参照してください。

CTMで使用するプロセスの配置パターンについて説明します。

＜この項の構成＞

(1)　多数のEJBクライアントからJ2EEサーバを呼び出す構成

(2)　WebブラウザからJ2EEサーバを呼び出す構成（小規模）

(3)　WebブラウザからJ2EEサーバを呼び出す構成（大規模）

(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）

(1)　多数のEJBクライアントからJ2EEサーバを呼び出す構成

多数のEJBクライアントから，並列に配列したアプリケーションサーバ上のJ2EEサーバを呼び出す構成の例を次の図に示します。

図3-5　複数のEJBクライアントからJ2EEサーバを呼び出す構成の例

(2)　WebブラウザからJ2EEサーバを呼び出す構成（小規模）

Webブラウザから，並列に配置したWebサーバ／アプリケーションサーバ上のWebコンテナを経由して，J2EEサーバを呼び出す構成の例を次の図に示します。なお，Webサーバとアプリケーションサーバは同じホスト上に配置しています。

図3-6　WebブラウザからJ2EEサーバを呼び出す構成（小規模）の例

(3)　WebブラウザからJ2EEサーバを呼び出す構成（大規模）

WebブラウザからWebサーバ上のWebコンテナを経由して，アプリケーションサーバ上のJ2EEサーバを呼び出す構成の例を次の図に示します。Webサーバとアプリケーションサーバのホストを分けることで，それらを容易に多対多の関係で構成できます。

図3-7　WebブラウザからJ2EEサーバを呼び出す構成（大規模）の例

(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）

グローバルCORBAネーミングサービスを独立したホストに配置してレプリカを作成することで，ネーミングサービスの可用性を向上させることができます。このホストを，統合ネーミングスケジューラサーバといいます。統合ネーミングスケジューラサーバにJ2EEサーバを配置する必要はありません。

ただし，ほかのホスト上の業務処理プログラム情報を統合ネーミングスケジューラサーバのグローバルCORBAネーミングサービスに登録するためには，CTMデーモンは統合ネーミングスケジューラサーバにも配置しておく必要があります。

独立した統合ネーミングスケジューラサーバを構築する構成を次の図に示します。

図3-8　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）の例

なお，この構成の場合，統合ネーミングスケジューラサーバのCTMデーモンにはcreate要求以外が送信されないため，統合ネーミングスケジューラサーバではCTMレギュレータを起動しなくてもかまいません。

3.3.3　CTMデーモン

CTMデーモンは，クライアントからのリクエストを処理してリクエストのスケジューリングを実現する，スケジューラの機能を持つプロセスです。

クライアントから送信されたリクエストは，CTMレギュレータというプロセスを経由して，CTMデーモンが受信します。CTMレギュレータについては「3.3.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ネーミングサービスについては，「3.3.6　グローバルCORBAネーミングサービス」を参照してください。CTMドメインについては，「3.3.5　CTMドメインとCTMドメインマネジャ」を参照してください。

リクエストは，create時の選択ポリシー，およびスケジュールポリシーに従って振り分けられます。

create時の選択ポリシーおよびスケジュールポリシーは，CTMデーモンを起動するときに，次のどちらかを選択できます。

それぞれのCTMデーモンの負荷状況に応じて，負荷が軽いCTMデーモンにリクエストを振り分けるポリシー

リクエストを受け付けたCTMデーモンが優先的に処理をするポリシー
ただし，この場合でも，リクエストを受け付けたCTMデーモンの負荷が高い状態の場合，または閉塞状態の場合は，ほかのCTMデーモンに処理を振り分けます。負荷の高さは，それぞれのキューでのリクエストの滞留率から計算されます。

なお，create時の選択ポリシーおよびスケジュールポリシーのタイミングについては，「3.8　リクエストの負荷分散」を参照してください。

スケジュールポリシーは，ctmstartコマンドの引数-CTMDispatchPolicyに指定します。create時の選択ポリシーは，ctmstartコマンドの引数-CTMCreatePolicyに指定します。

リクエスト転送時のタイムアウトについて

CTMデーモン間で，リクエスト転送処理が完了するまでの待ち時間にタイムアウトを設定できます。タイムアウトの設定は，ctmstartコマンドの-CTMDCSendTimeOutオプションに指定します。

(2)　スケジュールキューへのリクエストの登録

スケジュールポリシーに従って振り分けられたリクエストは，スケジュールキューに登録されます。スケジュールキューに登録できるリクエストの数は，CTMデーモンを起動する時に，設定されています。この値を超えてリクエストを転送された場合には，クライアントにエラーが返却されます。また，指定を省略した場合は，50が設定されます。

登録できるリクエストキューの長さは，CTMデーモンを起動するときにctmstartコマンドの引数-CTMMaxRequestCountに指定します。また，運用管理ポータルで構築したシステムを運用する場合は，あらかじめ論理CTMの設定で設定しておくことができます。ctmstartコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.7.2　スケジューリングの設定」を参照してください。

(3)　業務処理プログラムの呼び出し

スケジュールキューに登録されたリクエストは，CTMデーモンの処理対象であるJ2EEサーバ上の業務処理プログラムを呼び出します。なお，異常終了したJ2EEサーバや，ハングアップした業務処理プログラムを呼び出すことはありません。

(4)　処理結果の返却

処理の実行後，業務処理プログラム（Enterprise Bean）から返却された応答は，CTMデーモンを経由してクライアントに返却されます。なお，リクエストがスケジュールキューに登録されてから取り出されるまでの時間がリクエストのタイムアウト値を超えている場合は，リクエストが破棄されます。

3.3.4　CTMレギュレータ

CTMレギュレータは，CTMデーモンに対するリクエストの集中による問題を，コネクションやリクエストのレギュレート（集約）によって解決するプロセスです。CTMデーモンのフロントに配置され，EJBクライアントからのコネクションやリクエスト（invokeまたはremove）の集中を，分散集約します。

例えば，大規模なシステムでクライアントの数が増え，リクエスト数が増大した場合，システムの動作状態が不安定になったり，システムで管理する資源が不足して正常な処理ができなくなったりします。これは，リクエストのスケジューリングをするCTMデーモンに対するリクエストの集中によって，コネクション数が増大し，ファイルやソケットのオープン数などのプロセス使用資源が増大するためです。

CTMレギュレータは，このようなリクエスト集中による問題を解決するための専用のプロセスです。CTMレギュレータは，クライアントからの幾つかのコネクションを集約し，CTMデーモン当たりのコネクション数の上限を管理します。これを，コネクションのレギュレートといいます。CTMレギュレータが大量のコネクションをレギュレートすることによって，使用資源を複数プロセスに分散し，大規模なシステムをより安定して動作させることができます。

コネクションのレギュレートの仕組みを，次の図に示します。

図3-9　コネクションのレギュレートの仕組み

CTMレギュレータは，EJBクライアントからのリクエストを受け付けると，対応するCTMデーモンにリクエスト転送して，リクエストの応答を待ちます。応答が返ってくると，その応答をEJBクライアントに返却します。

CTMでは，一つのCTMデーモンに対して，必要に応じて複数のCTMレギュレータを配置できます。一つのCTMレギュレータに対する同時リクエスト数が256を超えるような場合は，性能が劣化するおそれがあります。この場合は，クライアントプロセス数に関係なく，CTMレギュレータを増やしてください。なお，CTMレギュレータは，対応するCTMデーモンと同じホスト上に配置する必要があります。

また，ネーミングサービスをJ2EEサーバとは別なホストに配置している統合ネーミングスケジューラサーバモデルの場合，統合ネーミングスケジューラサーバでは，create以外のリクエストを受け付けません。このため，CTMレギュレータを起動する必要はありません。

3.3.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 アプリケーションサーバ リファレンス コマンド編」の「ctmdmstart（CTMドメインマネジャの開始）」を参照してください。運用管理ポータルについては，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.6.2　CTMドメインマネジャのネットワーク設定」を参照してください。

＜この項の構成＞

(1)　対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有

(2)　対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有

(3)　CTMドメインマネジャの部分再開始

(4)　CTMドメインマネジャの稼働状態の確認

(1)　対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有

CTMドメインマネジャは，ホスト内のCTMデーモンの情報を，ほかのホスト上のCTMドメインマネジャにブロードキャストで配布します。対象のCTMドメインマネジャが同じネットワークセグメント内にある場合の情報共有について，次の図に示します。

図3-10　同じネットワークセグメント内でのCTMドメインマネジャによる情報共有

既存のCTMドメインに新しくCTMデーモンを登録したい場合は，CTMドメイン内のホスト上で，ほかのCTMドメインマネジャと同じドメイン名称とポート番号を持つCTMドメインマネジャを開始するだけで参加できます。既存のCTMドメインで環境の定義などを更新する必要がないので，システム環境をコピーするだけで，容易にシステムのスケールアウトができます。

(2)　対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有

ブロードキャストされた情報はルータを越えられないため，異なるネットワークセグメントにあるCTMドメインマネジャには届きません。この場合には，スマートエージェントを使用して情報を配布する必要があります。

対象のCTMドメインマネジャが異なるネットワークセグメントにある場合の情報共有について，次の図に示します。

図3-11　異なるネットワークセグメントでの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ドメインマネジャの稼働状況確認について，次の図に示します。

図3-12　CTMドメインマネジャの稼働状況確認

ホストBのCTMドメインマネジャは，ホストAのCTMドメインマネジャからホストAのCTMデーモンの情報を受信します。「CTMデーモンの情報の送信間隔に指定した値×生存判定監視係数」の間にCTMデーモンの情報が受信されない場合，ホストAのCTMデーモンの情報を削除し，そのことをホストBのCTMデーモンに通知します。これによって，ホストBのCTMデーモンは，ホストAのCTMデーモンにリクエストを振り分けなくなります。

3.3.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キー）にラウンドロビン検索を実行する指定をして開始しています。

図3-13　グローバル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ネーミングサービスに登録し直す必要があります。

3.4　リクエストの流量制御

流量制御では，J2EEサーバで一度に実行されるリクエスト処理数の最大値を制限することで，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現します。

この節の構成を次の表に示します。

表3-3　この節の構成（リクエストの流量制御）

分類 | タイトル | 参照先
解説 | リクエストの流量制御の概要 | 3.4.1
設定 | 実行環境での設定 | 3.4.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

3.4.1　リクエストの流量制御の概要

3.4.2　実行環境での設定

3.4.1　リクエストの流量制御の概要

CTMを使用した流量制御について説明します。

流量制御は，J2EEサーバで一度に実行される処理数の最大値を設定して，リクエストの同時実行数を制限する機能です。これによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現します。CPUや排他資源の競合も抑止できます。

CTMによる流量制御は，CTMデーモンおよびCTMデーモンが管理しているスケジュールキューを使用して実現します。

CTMによる流量制御の概要を，次の図に示します。この図は，J2EEアプリケーション単位でスケジュールキューを共有している場合の例です。

図3-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 アプリケーションサーバ リファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.7.2　スケジューリングの設定」を参照してください。

注意

CTMによる流量制御では，スケジュールキューごとに同時実行スレッド数（Parallel Count）を設定します。また，CTMに呼び出されるStateless Session Bean単位に，プールしておくインスタンス数の最大値（Pooled InstancesのMaximum）を指定できます。プールしておくインスタンス数の最大値がスケジュールキューの同時実行スレッド数よりも少ないと，CTMから呼び出された時にインスタンスが不足するおそれがあるのでご注意ください。

CTMを使用する場合，グローバルCORBAネーミングサービスのほかにそれぞれのホストのCORBAネーミングサービス（ローカルCORBAネーミングサービス）にもEJBオブジェクトリファレンスが登録されます。このため，アプリケーションの構成によっては，CTMを使用しないで直接ローカルCORBAネーミングサービスに対してlookupを実行してEnterprise Beanを呼び出すこともできます。ただし，この場合，CTMからの同時実行スレッド数指定が保証されなくなります。このような使用方法はしないでください。

3.4.2　実行環境での設定

CTMの機能を使用する場合，CTMを使用する構成でシステムを構築する必要があります。CTMを使用するシステムの構成や構築手順については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」，およびマニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」を参照してください。

CTMの機能を使用して，リクエストをスケジューリングするための設定は，簡易構築定義ファイルでejbserver.ctmから始まるパラメタに，CTMデーモンのCTM識別子，CTMキューの長さなどを指定します。

CTMによるリクエストのスケジューリングをするためには，次の設定が必要です。

実行環境ディレクトリの作成と環境変数の設定

簡易構築定義ファイルでの設定

サーバ管理コマンドでの設定

＜この項の構成＞

(1)　実行環境ディレクトリの作成と環境変数の設定

(2)　簡易構築定義ファイルでの設定

(3)　サーバ管理コマンドでの設定

(1)　実行環境ディレクトリの作成と環境変数の設定

CTMを使用するためには，CTMとパフォーマンストレーサの実行環境ディレクトリを作成して，環境変数に指定する必要があります。

実行環境ディレクトリの作成および環境変数については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.3.2　環境変数の詳細」を参照してください。

(2)　簡易構築定義ファイルでの設定

CTMを使用してリクエストをスケジューリングする場合には，簡易構築定義ファイルで論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタを設定してください。簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

ejbserver.ctm.ActivateTimeOut
CTMを使用するJ2EEアプリケーションの開始時に，J2EEサーバがスケジュールキューを活性化するときの待ち時間を指定します。

ejbserver.ctm.DeactivateTimeOut
CTMを使用するJ2EEアプリケーションの停止時に，J2EEサーバがスケジュールキューを非活性化するときの待ち時間（実行中のリクエストの完了待ち時間）を指定します。

ejbserver.ctm.QueueLength
CTMを使用するJ2EEアプリケーションの開始時に，J2EEサーバによって生成されるCTMキューの長さを指定します。

ejbserver.client.ctm.RequestPriority
J2EEサーバからCTMに送信するリクエストの優先度を指定します。

(3)　サーバ管理コマンドでの設定

サーバ管理コマンドで設定できる内容を次に示します。サーバ管理コマンドでの操作については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。

J2EEアプリケーション単位での設定
アプリケーション属性ファイルで次の設定ができます。

<managed-by-ctm>タグで，CTMを利用するかどうかを設定できます。

<scheduling>タグで，スケジューリングをするキューの名称や長さなどを設定できます。

<scheduling-unit>タグで，スケジュールキューの配置単位として，J2EEアプリケーション単位またはBean単位のどちらかを選択できます。

Stateless Session Bean単位での設定
SessionBean属性ファイルで次の設定ができます。

<enable-scheduling>タグで，J2EEアプリケーションに含まれるどのStateless Session Beanをスケジューリングの対象にするかを設定できます。

<stateless><pooled-instance>タグ下の<maximum>タグまたは<minimum>タグで，プールしておくインスタンス数の最大値または最小値を設定できます。なお，運用時にCTMの同時実行数を動的に変更する場合は，最大値は無制限「0」に設定する必要があります。

<scheduling>タグで，スケジューリングをするキューの名称や長さなどを設定できます。

cjgetapppropコマンドで属性ファイルを取得し，属性ファイル編集後に，cjsetapppropコマンドで編集内容をJ2EEアプリケーションに反映させてください。

3.5　リクエストの優先制御

ここでは，CTMによるリクエストの優先制御について説明します。

CTMを経由するリクエストには優先順位を付けることができます。EJBクライアントに優先順位を付けておくと，優先順位の高いEJBクライアントからのリクエストは，優先順位の低いEJBクライアントからのリクエストより先にキューから取り出され，処理されます。

リクエストの優先順位は，EJBクライアントとして動作するJ2EEサーバ，WebコンテナサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。CTMでは，優先順位に小さな値が設定されているEJBクライアントから送信されてきたリクエストを，優先的に処理します。

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

リクエストの同時実行数の動的変更では，CTMを使用して流量制御をしている場合に，CTMデーモンを停止しないでスケジュールキュー単位のリクエストの同時実行数を動的に変更できます。これによって，スケジュールキューが対応するサービスの内容に応じて，同時実行数を一時的に増加させたり，減少させたりできます。

この節の構成を次の表に示します。

表3-4　この節の構成（リクエストの同時実行数の動的変更）

分類 | タイトル | 参照先
解説 | 動的変更の処理の仕組み | 3.6.1
設定 | 同時実行数に指定できる値 | 3.6.2
運用 | CTMのスケジュールキューの稼働状況の確認 | 3.6.3
CTMのスケジュールキューの同時実行数の変更 | 3.6.4

注　「実装」および「注意事項」について，この機能固有の説明はありません。

CTMの同時実行数の動的変更は，ctmchparaコマンドで実行します。スケジュールキューの同時実行数の変更については，「3.6.4　CTMのスケジュールキューの同時実行数の変更」を参照してください。ctmchparaコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmchpara（スケジュールキューの同時実行数の変更）」を参照してください。

ポイント

ctmchparaコマンドで変更したスケジュールキュー単位の同時実行数は，CTMデーモンを停止するまで有効です。個別のJ2EEアプリケーションに設定したparallel countの値として保存はされません。一度CTMデーモンを再起動してJ2EEアプリケーションを再開始する場合には，個別のJ2EEアプリケーションに設定したparallel countの値が有効になります。

＜この節の構成＞

3.6.1　動的変更の処理の仕組み

3.6.2　同時実行数に指定できる値

3.6.3　CTMのスケジュールキューの稼働状況の確認

3.6.4　CTMのスケジュールキューの同時実行数の変更

3.6.1　動的変更の処理の仕組み

CTMによる同時実行スレッド数の動的変更の概要を，次の図に示します。

図3-15　CTMによる同時実行数の動的変更の概要

図3-15について，(1)～(3)で説明します。

＜この項の構成＞

(1)　同時実行数を動的変更する前の状態（スケジュールキューとしての同時実行数は5）

(2)　同時実行数を動的変更したあとの状態（同時実行数を8に増やした場合）

(3)　同時実行数を動的に変更したあとの状態（同時実行数を1に減らした場合）

(1)　同時実行数を動的変更する前の状態（スケジュールキューとしての同時実行数は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は，サーバ管理コマンドで設定，変更できます。

(2)　同時実行数を動的変更したあとの状態（同時実行数を8に増やした場合）

スケジュールキュー単位の同時実行数を動的に8に増やした場合について説明します。

スケジュールキュー単位の同時実行数を動的に増やすと，変更後の同時実行数に合わせて，それぞれのJ2EEアプリケーションのリクエスト処理用の常駐スレッド数も変更されます。

なお，常駐スレッド数が変更されるときには，スケジュールキューを共有しているJ2EEアプリケーションで，常駐スレッド数の平均化が実施されます。例えば，三つのJ2EEサーバ上のJ2EEアプリケーションのparallel countがそれぞれ40，30，60で，それぞれ常駐スレッドが最大数作成されている場合に，スケジュールキュー単位の同時実行数を120に変更しようとすると，それぞれのJ2EEサーバ上の常駐スレッド数は，「120（同時実行数）÷3（スケジュール共有数）」で平均化されて，40になります。

図3-15の場合は，同時実行数8を二つのJ2EEサーバで処理するので，常駐スレッド数がそれぞれ4ずつに変更されます。

(3)　同時実行数を動的に変更したあとの状態（同時実行数を1に減らした場合）

スケジュールキュー単位の同時実行数を1に減らした場合について説明します。

同時実行数を減らす場合も，変更後の同時実行数に合わせて，それぞれのJ2EEアプリケーションのリクエスト処理用の常駐スレッド数が変更されます。この場合も，常駐スレッド数は平均化されます。

ただし，スケジュールキュー単位の同時実行数を，スケジュールキューを共有しているJ2EEアプリケーションの数よりも小さくした場合，単純に常駐スレッド数を平均化すると，リクエストを受け付けないJ2EEサーバが出てしまいます。これを防ぐため，常駐スレッドは最低で1個は確保されます。

図3-15の場合，同時実行数1を二つのJ2EEサーバで処理するので，それぞれのJ2EEサーバの常駐処理スレッドは，最低保障常駐スレッド数である1になります。ただし，この場合も，同時に処理されるリクエストの数は，同時実行数分だけになります。つまり，J2EEサーバ2での処理が完了するまで，J2EEサーバ1のスレッドでは処理が実行されません。

3.6.2　同時実行数に指定できる値

同時実行数を動的変更するときに，指定できる値について説明します。

同時実行数は，1～「スケジュールキューを共有しているJ2EEアプリケーションの数×127」までの整数で指定できます。127は，一つのJ2EEアプリケーションで処理できる同時実行数（parallel count）の最大数です。

ただし，CTMデーモンを起動するときに-CTMDispatchParallelCountに指定した値を超える値は指定できません。

次の値を指定した場合は，エラーが出力されて，同時実行数は変更されません。

0

「スケジュールキューを共有しているJ2EEアプリケーションの数×127」を超える値

ctmstartコマンドの-CTMDispatchParallelCountの指定値を超える値

3.6.3　CTMのスケジュールキューの稼働状況の確認

ここでは，CTMのスケジュールキューの稼働状況を確認する方法について説明します。CTMのスケジュールキューの稼働状況は運用管理コマンド（mngsvrutil）を使用して確認できます。

CTMのスケジュールキューの稼働状況を確認するには，運用管理コマンドのサブコマンド「get」の引数に，「queueApps」を指定して実行します。コマンドを実行すると，J2EEアプリケーション開始時の同時実行数，J2EEアプリケーションに対する現在の常駐スレッド数などの情報が取得できます。

次に，実行形式と実行例を示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <論理サーバ名> get queueApps

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t myServer get queueApps

mngsvrutilコマンド，そのサブコマンド，および取得できる情報の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

3.6.4　CTMのスケジュールキューの同時実行数の変更

J2EEアプリケーションの同時実行数をスケジュールキュー単位で動的に変更する方法について説明します。

J2EEアプリケーションの最大同時実行数をCTMスケジュールキュー単位で動的に変更する作業は次の流れで行います。

現在のCTMのスケジュールキューの同時実行数を確認する
CTMのコマンド（ctmlsque）を使用して実行します（「(1)　CTMのスケジュールキューの稼働状況の確認」参照）。

CTMのスケジュールキューの同時実行数を変更する
CTMのコマンド（ctmchpara）を使用して実行します（「(2)　CTMのスケジュールキューの同時実行数の変更」参照）。

変更後のCTMのスケジュールキューの同時実行数を確認する
CTMのコマンド（ctmlsque）を使用して実行します（「(1)　CTMのスケジュールキューの稼働状況の確認」参照）。

なお，CTMのスケジュールキューの同時実行数の変更は，スケジュールキューの状態が次の場合に実行できます。

A：スケジューリング可能状態

H：スケジューリング閉塞中

C：スケジューリング可能閉塞

＜この項の構成＞

(1)　CTMのスケジュールキューの稼働状況の確認

(2)　CTMのスケジュールキューの同時実行数の変更

(1)　CTMのスケジュールキューの稼働状況の確認

CTMのスケジュールキューの稼働状況を確認するには，ctmlsqueコマンドの引数に「-CTMAppInfo」を指定して実行します。このコマンドを実行すると，スケジュールキューを共有しているJ2EEアプリケーションの情報を確認できます。実行形式と実行例を次に示します。

実行形式

ctmlsque -CTMDomain <CTMドメイン名称> -CTMID <CTM識別子> -CTMAppInfo

実行例

ctmlsque -CTMDomain domain01 -CTMID CTM01 -CTMAppInfo

ctmlsqueコマンドの詳細，および出力される情報の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmlsque（スケジュールキュー情報の出力）」を参照してください。

(2)　CTMのスケジュールキューの同時実行数の変更

CTMのスケジュールキューの同時実行数を変更するには，ctmchparaコマンドを実行します。実行形式と実行例を次に示します。

実行形式

ctmchpara -CTMDomain <CTMドメイン名称> -CTMID <CTM識別子> -CTMQueue <スケジュールキュー登録名称> -CTMChangeCount <同時実行数>

実行例

ctmchpara -CTMDomain domain01 -CTMID CTM01-CTMQueue que01 -CTMChangeCount 10

実行後，変更が反映されていることを確認してください。スケジュールキューの状態を確認する方法については，「(1)　CTMのスケジュールキューの稼働状況の確認」を参照してください。

ctmchparaコマンドの詳細，および出力される情報の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmchpara（スケジュールキューの同時実行数の変更）」を参照してください。

3.7　リクエストの閉塞制御

閉塞制御（サービス閉塞）は，特定のJ2EEアプリケーションに対するリクエストの受け付けを停止したり，リクエストを滞留させたりすることで，システム全体を停止させないでJ2EEアプリケーションの入れ替えや再起動を可能にして，システムの可用性を高めるための機能です。

この節の構成を次の表に示します。

表3-5　この節の構成（リクエストの閉塞制御）

分類 | タイトル | 参照先
解説 | リクエストの閉塞制御の概要 | 3.7.1
オンライン状態でのJ2EEアプリケーションの入れ替え | 3.7.2
J2EEアプリケーションの閉塞制御 | 3.7.3
スケジュールキューの閉塞制御 | 3.7.4
J2EEサーバ異常終了時のリクエスト保持 | 3.7.5
設定 | 実行環境での設定 | 3.7.6

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

＜この節の構成＞

3.7.1　リクエストの閉塞制御の概要

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

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

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

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

3.7.6　実行環境での設定

3.7.1　リクエストの閉塞制御の概要

CTMを使用してリクエストをスケジューリングしている場合，特定のスケジュールキューの閉塞制御ができます。スケジュールキューを閉塞制御することによって，特定のJ2EEアプリケーションをオンライン状態で入れ替えるサービス閉塞などができるようになります。

CTMによる閉塞制御でできることは，次のとおりです。

オンライン状態でのJ2EEアプリケーションの入れ替え
スケジュールキューにリクエストを保持した状態でJ2EEアプリケーションを入れ替えられます。

J2EEアプリケーションの閉塞制御
リクエストの完了を待ってから，J2EEアプリケーションを閉塞させます。

スケジュールキューの閉塞制御
スケジュールキューをすぐに閉塞させます。キューに登録済みのリクエストを破棄するかどうかを選択できます。

J2EEサーバ異常終了時のリクエスト保持
J2EEサーバ異常終了時にスケジュールキューのリクエストを一定時間保持します。

リクエストの閉塞制御は，運用管理コマンド（mngsvrutil）で実行します。コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

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

J2EEアプリケーションを入れ替える場合に，オンライン状態でJ2EEアプリケーションを入れ替えられます。

ここでは，入れ替えの概要と入れ替え手順について説明します。

＜この項の構成＞

(1)　入れ替えの概要

(2)　入れ替えの手順

(1)　入れ替えの概要

J2EEアプリケーションを入れ替える場合には，CTMデーモンによって，スケジュールキューの出口を閉じてから，入れ替えを実行します。出口を閉じている間もクライアントからのリクエストはスケジュールキューに登録し続けることができます。このため，該当アプリケーションに対するリクエストもエラーにしないでシステムを運用し続けられます。ただし，スケジュールキューの最大リクエスト登録数を超えた場合は，クライアントにエラーが返却されます。

オンライン状態でのJ2EEアプリケーションの入れ替えの概要を，次の図に示します。

図3-16　オンライン状態でのJ2EEアプリケーションの入れ替えの概要

(2)　入れ替えの手順

オンライン状態でJ2EEアプリケーションを入れ替える場合，J2EEアプリケーションのスケジュールキューの出口を閉じたあと，入れ替えを実行します。この操作は，運用管理コマンド（mngsvrutil）で実行できます。

J2EEアプリケーションの入れ替えは，J2EEアプリケーション単位，ホスト単位，または運用管理ドメイン単位で実行できます。

スケジュールキューの出口を閉じるには，mngsvrutilコマンドにサブコマンド「hold」を指定して実行します。mngsvrutilコマンドを実行してスケジュールキューの出口を閉塞している間も，クライアントからのリクエストはスケジュールキューに登録し続けられます。ただし，スケジュールキューの最大リクエスト登録数を超えた場合，クライアントにエラーが返却されます。

J2EEアプリケーションの入れ替えが終了したら，スケジュールキューの閉塞を解除します。スケジュールキューの閉塞解除は，mngsvrutilコマンドにサブコマンド「release」を指定して実行します。スケジュールキューの閉塞を解除すると，J2EEアプリケーションで，スケジュールキューに保持されていたリクエストの処理を再開します。

CTMを使用したオンライン状態でのJ2EEアプリケーションの入れ替え手順を次に示します。

入れ替えるJ2EEアプリケーションに対応するCTMのスケジュールキューの出口を閉じます。
J2EEアプリケーションを入れ替える場合のmngsvrutilコマンドの実行形式と実行例を次に示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <CTMの名称> hold queue <キューの名称> out

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t ctm01 hold queue App1 out

J2EEアプリケーションを入れ替えます。
J2EEアプリケーションを停止して，新しいアプリケーションに入れ替えます。そのあとで，J2EEアプリケーションを再開始します。
J2EEアプリケーションの入れ替え方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6.3　J2EEアプリケーションの入れ替えと保守」を参照してください。

CTMのスケジュールキューの閉塞を解除するときは，mngsvrutilコマンドにサブコマンド「release」を指定して実行します。
この場合のmngsvrutilコマンドの実行形式と実行例を次に示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <CTMの名称> release queue <キューの名称>

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t ctm01 release queue App1

mngsvrutilコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

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

J2EEアプリケーションを停止するときに，スケジュールキューに登録されたリクエストの処理が完了するのを待ってから，J2EEアプリケーションを停止できます。これによって，停止するJ2EEアプリケーションがそのキューを共有する最後のアプリケーションであった場合に，すでに受け付けられたリクエストをエラーにしないで処理できます。

ここでは，閉塞制御の概要と閉塞の手順について説明します。

＜この項の構成＞

(1)　閉塞制御の概要

(2)　閉塞の手順

(1)　閉塞制御の概要

キューを共有する最後のJ2EEアプリケーションが停止する場合，CTMデーモンは，スケジュールキューの入り口を閉じてサービスを停止して，それ以上リクエストを受け付けないようにします。そのあと，スケジュールキューに登録されていたリクエストの処理がすべて完了するのを待ってから，J2EEアプリケーションを停止します。

J2EEアプリケーションの閉塞制御の概要を次の図に示します。

図3-17　J2EEアプリケーションの閉塞制御の概要

CTMの閉塞処理では，次の作業が実行されます。

新規リクエストの受け付けが終了されます。

スケジュールキューに格納されているリクエストのうち，すでにJ2EEサーバに振り分けられて処理中のリクエストは引き続き処理されます。

スケジュールキューに格納されているリクエストのうち，J2EEサーバへの振り分けがされていないリクエストに対しては，java.rmi.RemoteExceptionエラーが返却されます。

(2)　閉塞の手順

閉塞は，運用管理コマンドで実行します。

特定のホスト内のJ2EEアプリケーションを一括停止する場合の運用管理コマンドの実行形式と実行例を次に示します。なお，運用管理コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host hold queues in:<リクエスト終了待ち時間（秒）>

実行例

サービス閉塞をして，すべてのリクエスト処理の完了を待つ場合
mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host hold queues in:0

サービス閉塞をして，5分間リクエストの処理を続けて，終了しないリクエストは破棄する場合
mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host hold queues in:300

サービス閉塞をして，リクエストはすぐに破棄する場合
mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host hold queues in:-1

スケジュールキューの閉塞を解除するときは，mngsvrutilコマンドにサブコマンド「release」を指定して実行します。mngsvrutilコマンドの実行形式と実行例を次に示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host release queues

実行例

mngsvrutil -m mnghost01 -u user01 -p pw1 -t host01 -k host release queues

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

スケジュールキューの閉塞制御には，次の2種類があります。

強制閉塞

タイムアウト閉塞

ここでは，スケジュールキューの閉塞制御の概要について説明します。また，強制閉塞およびタイムアウト閉塞の実行手順についても説明します。

＜この項の構成＞

(1)　スケジュールキューの閉塞制御の概要

(2)　スケジュールキューの強制閉塞

(3)　スケジュールキューのタイムアウト閉塞

(1)　スケジュールキューの閉塞制御の概要

スケジュールキューに対して，直接閉塞を実行することもできます。これによって，複数のJ2EEアプリケーションでスケジュールキューが共有されている場合に，一度にJ2EEアプリケーションを停止できます。スケジュールキューに登録されている仕掛かり中のリクエストについては，破棄するか一定の時間処理を続けるかを選択できます。処理を続ける場合は，一定の時間内に処理ができなければ強制的に破棄するように，タイムアウト時間が指定できます。また，仕掛かり中のリクエストについては，処理が続行されます。

スケジュールキューの閉塞が指示されると，CTMデーモンは，スケジュールキューの入り口を閉じてサービスを停止して，それ以降のリクエストを受け付けないようにします。また，すでにスケジュールキューに登録されたリクエストは，設定に従って，破棄するか，または処理を実行してからスケジュールキューの閉塞を完了します。リクエストを破棄する場合は，キューに登録されていたリクエストの処理はすべてエラーとしてクライアントに返却されます。処理を実行してから閉塞する場合は，一定時間処理を継続して，時間内に終了しなかった処理がエラーで返却されます。

スケジュールキューの閉塞制御の概要を，次の図に示します。

図3-18　スケジュールキューの閉塞制御の概要

CTMを使用しているバックシステムで，ホスト内のJ2EEアプリケーションを一度に停止したり，キューを共有するJ2EEアプリケーションを一度に停止したりする場合，J2EEアプリケーションのスケジュールキューに対して直接閉塞を実行します。そのあと，J2EEアプリケーションを停止します。

運用管理コマンドを使用してJ2EEアプリケーションのスケジュールキューを直接閉塞する場合，スケジュールキューを共有するJ2EEアプリケーション単位，ホスト単位，または運用管理ドメイン単位でJ2EEアプリケーションを一度に停止できます。また，スケジュールキューに登録済みのリクエストを破棄するか，一定時間処理を続けるかどうかを選択します。スケジュールキューに登録済みのリクエストを破棄する場合，登録済みのリクエストはすべてエラーとしてクライアントに返却されます。一定時間処理を続ける場合，時間内に終了しなかった処理はエラーとしてクライアントに返却されます。

運用管理コマンドを使用した場合のCTMを使用したサービス閉塞の実行形式および実行例について説明します。ここでは，通常の手順で閉塞する方法と，強制的に閉塞する方法について説明します。強制閉塞は，CTMデーモンの負荷が高い場合などに，すぐにキューを閉塞したいときに実行する方法です。

(2)　スケジュールキューの強制閉塞

スケジュールキューは，CTMデーモンとの通信をしないで閉塞することもできます。これを，スケジュールキューの強制閉塞といいます。強制閉塞は，CTMデーモンの負荷が高いときにすぐにキューを閉塞するための方法です。通常の閉塞方法では，キューを閉塞するときに，CTMデーモンと通信して，その処理の延長で滞留しているリクエストを破棄しています。しかし，この方法では，CTMデーモンの負荷が高い場合，通信処理に時間が掛かるため，閉塞処理にも時間が掛かってしまいます。

強制閉塞を使用すると，CTMデーモンとの通信処理をしないで，即座にキューを閉塞できます。なお，強制閉塞を使用した場合，滞留しているリクエストの破棄は，CTMデーモン間で負荷情報を監視するタイミングにあわせて実行されます。

強制閉塞をする場合は，運用管理コマンド（mngsvrutil）のサブコマンド「hold」の引数に，「queue force」を指定してください。スケジュールキューの強制閉塞をすると，滞留しているリクエストは一定時間後に破棄されます。滞留するリクエストを破棄したくない場合は，ctmholdqueコマンドで-CTMRequestLeaveオプションも指定してください。

なお，閉塞の解除方法については，通常の閉塞をした場合と同じです。コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

強制閉塞を実行する場合のmngsvrutilコマンドの実行例を次に示します。

実行形式

mngsvrutil -m <Management Serverのホスト名>［:<ポート番号>］ -u <管理ユーザID> -p <管理パスワード> -t <ホスト名> -k host hold queues force

実行例

mngsvrutil -m mnghost -u user01 -p pw1 -t host01 -k host hold queues force

(3)　スケジュールキューのタイムアウト閉塞

スケジュールキューでは，EJBクライアントのタイムアウトを一定間隔で監視し，タイムアウトの発生回数が，設定した回数を超えると，スケジュールキューを閉塞します。これを，スケジュールキューのタイムアウト閉塞といいます。

タイムアウト発生について次の図で説明します。

図3-19　スケジュールキューのタイムアウト閉塞の発生

図では，10秒間隔でタイムアウト発生回数を監視しています。タイムアウト回数のカウントは，監視時間内だけとなります。次の監視時間ではタイムアウトの回数はリセットしてカウントされます。

このとき，例えば，タイムアウト発生回数として10回が設定されている場合，10秒の監視時間内で10回以上タイムアウトが発生すると，キューが閉塞されます。なお，キューが閉塞されるタイミングは，タイムアウト回数を10回以上検知したあとの，次の監視時間で閉塞されます。この図の場合，監視を始めてから30秒後に11回のタイムアウトを検知したので，タイムアウトを検知した30秒後にキューが閉塞されます。

なお，スケジュールキューのタイムアウト閉塞は，CTMデーモン起動時にオプションを指定することで実行します。ctmstartコマンドの-CTMWatchRequestオプションで設定します。

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

J2EEサーバ異常終了時に，スケジュールキューのリクエストを一定時間保持します。

これによって，J2EEサーバが異常終了した場合でも，すぐにユーザにエラーは返却されません。さらに，J2EEサーバが再起動するまでの間，クライアントからのリクエストは受け付け続けます。リクエストは，スケジュールキューの最大リクエスト登録数分まで受け付けられます。このため，J2EEサーバに障害が発生した場合でも，すぐに再起動すれば，クライアントに障害を気づかせないで運用を続けられます。ただし，スケジュールキューに登録できるリクエストの最大値を超えた場合は，クライアントにエラーが返却されます。

この機能は，ctmstartコマンドの-CTMQueueDeleteWaitオプションで設定します。コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。

J2EEサーバ異常終了時のリクエスト保持の概要を，次の図に示します。

図3-20　J2EEサーバ異常終了時のリクエスト保持の概要

3.7.6　実行環境での設定

閉塞制御のうち，スケジュールキューのタイムアウト閉塞をする場合，CTMデーモンの設定が必要です。

CTMデーモンの設定は，簡易構築定義ファイルで実施します。リクエストの負荷分散の定義は，簡易構築定義ファイルの論理CTM（component-transaction-monitor）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのスケジュールキューのタイムアウト閉塞の定義について次の表に示します。

表3-6　簡易構築定義ファイルでのスケジュールキューのタイムアウト閉塞の定義

指定するパラメタ | 設定内容
ctm.RequestCount | 何回タイムアウトが発生したら自動閉塞するか指定します。
ctm.RequestInterval | タイムアウト発生回数を求める時間間隔を指定します。
ctm.WatchRequest | J2EEサーバへのリクエストの送信でタイムアウトが発生したときにキューを閉塞するかどうかを指定します。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

3.8　リクエストの負荷分散

負荷分散は，クラスタ構成などで並列に運用しているJ2EEサーバ間で，負荷が均等になるように処理を分散して割り当て，システム全体の可用性を高める機能です。クライアントからのcreateおよびinvokeの要求をサーバ間，プロセス間およびスレッド間で負荷分散できます。

この節の構成を次の表に示します。

表3-7　この節の構成（リクエストの負荷分散）

分類 | タイトル | 参照先
解説 | 負荷分散のタイミング | 3.8.1
負荷状況の監視 | 3.8.2
設定 | 実行環境での設定 | 3.8.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

負荷分散は，スケジュールキューを共有しているJ2EEアプリケーション間で実行できるほか，複数のCTMデーモン間で負荷情報を交換することで，異なるスケジュールキューで制御されているJ2EEアプリケーションに含まれる業務処理プログラムに対しても実行できます。

＜この節の構成＞

3.8.1　負荷分散のタイミング

3.8.2　負荷状況の監視

3.8.3　実行環境での設定

3.8.1　負荷分散のタイミング

CTMでは，次の2回のタイミングで負荷分散を実行します。

createの実行によって，EJBオブジェクトリファレンスを取得するタイミング
このタイミングでは，負荷が軽いCTMデーモンに処理を振り分けるか，createを受け付けたホストのCTMデーモンに優先的に処理を振り分けるかが，create時の選択ポリシーに従って決まります。

invokeの実行によって，リモートインタフェースのビジネスメソッドを実行するタイミング
このタイミングでは，負荷が軽いCTMデーモンに処理を振り分けるか，リクエストを受け付けたホストのCTMデーモンに優先的に処理を振り分けるかが，スケジュールポリシーに従って決まります。

クライアントから業務処理プログラムを呼び出す流れと負荷分散のタイミングを，次の図に示します。

図3-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クライアントに返却されます。

3.8.2　負荷状況の監視

CTMでは，スケジュールキューの負荷状況を監視できます。負荷状況の監視は，J2EEサーバ単位で指定した監視時間の間隔で実施されます。監視間隔の設定は，CTMデーモンを起動するときにctmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMであらかじめ設定しておくことができます。ctmstartコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.7.2　スケジューリングの設定」を参照してください。

3.8.3　実行環境での設定

リクエストの負荷分散をする場合，CTMデーモンの設定が必要です。

CTMデーモンの設定は，簡易構築定義ファイルで実施します。リクエストの負荷分散の定義は，簡易構築定義ファイルの論理CTM（component-transaction-monitor）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエストの負荷分散の定義について次の表に示します。

表3-8　簡易構築定義ファイルでのリクエストの負荷分散の定義

項目 | 指定するパラメタ | 設定内容
負荷分散のタイミング設定 | ctm.CreatePolicy | create要求のCTMノード選択ポリシーを指定します。1回目の負荷分散で使用されます。
ctm.DispatchPolicy | リクエストのスケジュールポリシーを指定します。2回目の負荷分散で使用されます。
負荷状況の監視 | ctm.LoadCheckInterval | スケジュールキューの負荷状況を監視する時間間隔を指定します。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

3.9　リクエストのキューの滞留監視

この節の構成を次の表に示します。

表3-9　この節の構成（リクエストのキューの滞留監視）

分類 | タイトル | 参照先
解説 | スケジュールキューの滞留監視の概要 | 3.9.1
スケジュールキュー監視の例 | 3.9.2
設定 | 実行環境での設定 | 3.9.3
注意事項 | 注意事項 | 3.9.4

注　「実装」および「運用」について，この機能固有の説明はありません。

J2EEサーバで，CTMデーモンのスケジュールキュー取り出しが遅れると，リクエストがスケジュールキューの中で滞留することがあります。これを監視する機能として，スケジュールキュー監視機能があります。ここでは，スケジュールキュー監視機能について説明します。

＜この節の構成＞

3.9.1　スケジュールキューの滞留監視の概要

3.9.2　スケジュールキュー監視の例

3.9.3　実行環境での設定

3.9.4　注意事項

3.9.1　スケジュールキューの滞留監視の概要

スケジュールキューの滞留監視機能では，スケジュールキュー内に滞留しているリクエストの数を監視します。スケジュールキューにリクエストが滞留し，その数が一定の割合を超えると，メッセージを出力し，CTMデーモンは異常終了します。

スケジュールキュー監視は次のように動作します。

スケジュールキューの監視は，設定したキューの滞留率を超えた時点から開始します。

監視状態になると，指定した監視時間間隔でスケジュールキューを監視します。

監視のタイミングで，次に示すスケジュールキュー滞留監視式が成立すると，CTMデーモンが異常終了します。

スケジュールキュー滞留監視式

（P／Cn-1） ＜ （M1／100）

P：前回監視時点から現在までのリクエスト処理数

Cn-1：前回の監視時点でのキュー滞留数

M1：システム停止のしきい値（しきい値はシステムの処理率）

なお，スケジュールキュー監視は，ctmstartコマンドの-CTMWatchQueueオプションで設定します。コマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。

3.9.2　スケジュールキュー監視の例

例を使用してスケジュールキュー監視について説明します。

次の内容が設定されていることとします。

スケジュールキュー監視を行うキューの滞留率：60%

システム停止のしきい値：70%

スケジュールキューの監視間隔：1秒

図3-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デーモンは異常停止します。

3.9.3　実行環境での設定

スケジュールキューの滞留を監視する場合，CTMデーモンの設定が必要です。

CTMデーモンの設定は，簡易構築定義ファイルで実施します。リクエストの負荷分散の定義は，簡易構築定義ファイルの論理CTM（component-transaction-monitor）の<configuration>タグ内に指定します。キュー滞留監視状態へ移行する滞留率のしきい値をctm.QueueRateパラメタに指定してください。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

3.9.4　注意事項

監視状態のリクエストキューに対して，閉塞コマンド（ctmholdqueコマンド）を使用してリクエストキューに滞留しているリクエストを破棄した場合，破棄したリクエストは処理されたものとして判別されます。

リクエストキューを監視している状態で，閉塞コマンド（ctmholdqueコマンド）を使用した場合，監視状態は次のようになります。

通常閉塞の場合（ctmholdqueコマンドのオプション指定なし）
リクエストが破棄されるため，キューの滞留数が減少します。このため，自動的に監視状態が解除されます。

入り口閉塞の場合（ctmholdqueコマンドに-CTMRequestLeaveオプションを指定）
滞留しているリクエストはサーバで処理されるため，監視状態のままとなります。

出口閉塞の場合（ctmholdqueコマンドに-CTMChangeServerオプションを指定）
滞留しているリクエストは処理されず，処理率が0になるため，システムは停止します。このため，監視状態は解除されます。

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

CTMでは，次に示すクライアントからアプリケーションサーバ上で動作するJ2EEアプリケーションを呼び出せるゲートウェイ機能を提供します。

TPBrokerクライアント
TPBroker Version 5以降で開発されたクライアントアプリケーションです。

TPBroker OTMクライアント
TPBroker Object Transaction Monitorで開発されたクライアントアプリケーションです。

また，CTMではゲートウェイでリクエストを送受信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。性能解析トレース出力については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「6.　性能解析トレースを使用したシステムの性能解析」の性能解析トレースに関する説明を参照してください。

CTMのゲートウェイ機能を使用した，TPBrokerクライアントまたはTPBroker OTMクライアントからのJ2EEアプリケーションの呼び出しの概要を次の図に示します。

図3-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のドキュメントを参照してください。

4.　バッチアプリケーションのスケジューリング

バッチアプリケーションのスケジューリング機能を使用すると，バッチアプリケーションの実行リクエストを制御できるようになります。これによって，バッチサーバの数を変更することなく，複数のバッチアプリケーションの実行リクエストを受け付けられるようになります。この章では，バッチアプリケーションのスケジューリングの概要，スケジューリング機能を使用したバッチアプリケーションの実行，スケジューリング機能を使用するための設定などについて説明します。

なお，スケジューリング機能は，構成ソフトウェアにCosminexus Component Transaction Monitorを含む製品だけで利用できる機能です。利用できる製品については，マニュアル「Cosminexus アプリケーションサーバ 概説」の「2.3.1　製品と構成ソフトウェアの対応」を参照してください。

＜この章の構成＞

4.1　この章の構成

4.2　スケジューリング機能の概要

4.3　スケジューリング機能を使用したシステム

4.4　スケジューリング機能使用時のバッチアプリケーション実行環境の構築と運用

4.5　スケジューリング機能を使用したバッチアプリケーションの実行

4.6　スケジューリング機能を使用する環境への移行

4.7　実行環境での設定

4.8　スケジューリング機能使用時の注意事項

4.1　この章の構成

バッチアプリケーションのスケジューリング機能は，CTMを使用して，バッチサーバで実行するバッチアプリケーションの実行リクエストを制御する機能です。以降，この機能をスケジューリング機能といいます。

この章の構成を次の表に示します。

表4-1　この章の構成（バッチアプリケーションのスケジューリング）

分類 | タイトル | 参照先
解説 | スケジューリング機能の概要 | 4.2
スケジューリング機能を使用したシステム | 4.3
スケジューリング機能使用時のバッチアプリケーション実行環境の構築と運用 | 4.4
スケジューリング機能を使用したバッチアプリケーションの実行 | 4.5
スケジューリング機能を使用する環境への移行 | 4.6
設定 | 実行環境での設定 | 4.7
注意事項 | スケジューリング機能使用時の注意事項 | 4.8

注　「実装」および「運用」について，この機能固有の説明はありません。

なお，バッチサーバで提供する機能や，バッチアプリケーションの作成などについては，「2.　バッチサーバによるアプリケーションの実行」を参照してください。

4.2　スケジューリング機能の概要

この節では，スケジューリング機能の概要について説明します。

アプリケーションサーバでは，バッチアプリケーションのスケジューリングには，CTMを使用します。CTMは，キューを使用してそれぞれのバッチアプリケーションの実行を制御します。このキューを，スケジュールキューといいます。

＜この節の構成＞

4.2.1　バッチアプリケーションをスケジューリングする利点

4.2.2　スケジューリング機能を使用するための前提

4.2.3　スケジューリング機能を使用したバッチアプリケーションの実行処理の流れ

4.2.1　バッチアプリケーションをスケジューリングする利点

ここでは，スケジューリング機能を使用する利点について説明します。

バッチサーバでは，同時に実行できるバッチアプリケーションの数は一つです。バッチアプリケーションを開始するには，アプリケーションサーバで提供しているバッチ実行コマンドを使用します。バッチサーバでは，バッチ実行コマンドによるバッチアプリケーションの実行リクエストを受けて，バッチアプリケーションを開始します。

スケジューリング機能を使用しない場合，バッチサーバの数を超えたバッチアプリケーションの実行リクエストは受け付けられません。この場合，受け付けられないリクエストはエラーとなります。また，バッチ実行コマンドにどのバッチサーバで実行するかを定義する必要があります。

スケジューリング機能を使用する場合，バッチサーバの数を超えたバッチアプリケーションの実行リクエストは，CTMによってスケジュールキューに滞留され，エラーになりません。滞留されたリクエストは，CTMによってバッチサーバに振り分けられます。このため，バッチサーバの数に関係なく，バッチ実行コマンドを実行できます。また，バッチアプリケーションの実行リクエストを実行するバッチサーバは，CTMによって振り分けられるため，バッチ実行コマンドにどのバッチサーバで実行するかを定義する必要がありません。

スケジューリング機能の使用の有無によるバッチアプリケーションの実行の流れを次の図に示します。

図4-1　スケジューリング機能の使用の有無によるバッチアプリケーションの実行の流れ

この図は，バッチサーバが2台のシステムに対して，JP1/AJS2のジョブまたは直接マシンからバッチ実行コマンドを同時に実行する例です。

スケジューリング機能を使用しない場合は，図中の2と3のバッチ実行コマンドを同時に実行できません。スケジューリング機能を使用する場合は，CTMによってバッチアプリケーションの実行リクエストがバッチサーバに振り分けられるため，図中の2と3のバッチ実行コマンドを同時に実行できます。

4.2.2　スケジューリング機能を使用するための前提

ここでは，スケジューリング機能を使用するための前提条件について説明します。

スケジューリング機能を使用する場合，CTMの使用が前提となります。CTMの詳細は，「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

また，CTMを使用するためには，CTMを使用する構成でシステムを構築する必要があります。CTMを使用する構成については，「4.3　スケジューリング機能を使用したシステム」を参照してください。

4.2.3　スケジューリング機能を使用したバッチアプリケーションの実行処理の流れ

ここでは，バッチアプリケーションの実行処理の流れについて説明します。

スケジューリング機能を使用する場合，各バッチサーバで実行されるバッチアプリケーションは，ジョブIDで区別されます。ジョブIDは，実行するバッチアプリケーションの実行リクエストを区別するための文字列です。コマンド実行時に任意の値を設定できます。コマンド実行時にジョブIDを省略した場合，ジョブIDはスケジューリング機能によって自動生成されます。このジョブIDは，CTMによって管理されます。

また，CTMによってバッチアプリケーションが振り分けられるバッチサーバ群を，スケジュールグループといいます。スケジュールキューは，スケジュールグループごとに作成されます。バッチアプリケーションの業務分類ごとに同時実行数を制御したい場合などに，スケジュールグループを指定してください。スケジュールグループは，システム内で一意になるように設定してください。マシンごとにCTMが異なる場合でも，スケジュールグループは別々に設定する必要があります。なお，スケジュールグループを指定する場合は，バッチ実行コマンドとバッチサーバで設定が必要です。設定方法については，「4.7　実行環境での設定」を参照してください。

スケジューリング機能を使用する場合も，バッチアプリケーションの実行環境は，JP1/AJS2と連携できます。

スケジューリング機能を使用したバッチアプリケーション実行の流れを次の図に示します。

図4-2　スケジューリング機能を使用したバッチアプリケーション実行の流れ

この図では，CTMによって，同じスケジュールグループに属するバッチサーバ1からバッチサーバ3に，バッチアプリケーションの実行リクエストを振り分けています。なお，スケジュールキューからあふれたバッチアプリケーションの実行リクエストはエラーになります。

複数のスケジュールグループを使用したバッチアプリケーション実行の流れを次の図に示します。

図4-3　複数のスケジュールグループを使用したバッチアプリケーション実行の流れ

この図は，GroupAとGroupBの二つのスケジュールグループを指定した例で，スケジュールキューは二つ作成されます。使用するスケジュールグループは，コマンドで定義します。バッチアプリケーションは，コマンドのスケジュールグループの設定に従って，スケジュールキューに振り分けられます。なお，この図の場合，各スケジュールグループのバッチサーバでバッチアプリケーションを実行中のため，CTMに受け付けられたバッチアプリケーションは，スケジュールキュー内で待機しています。

4.3　スケジューリング機能を使用したシステム

この節では，スケジューリング機能を使用したシステムの構成と，必要なプロセスについて説明します。

＜この節の構成＞

4.3.1　スケジューリング機能を使用したシステムの構成

4.3.2　スケジューリング機能で必要なプロセス

4.3.1　スケジューリング機能を使用したシステムの構成

ここでは，スケジューリング機能を使用したシステムの構成について説明します。

スケジューリング機能を使用したシステムの構成例を次の図に示します。

図4-4　スケジューリング機能を使用したシステムの構成例

この図の場合，バッチアプリケーションを実行するシステムは，JP1/AJS2と連携しています。JP1/AJS2と連携しない場合は，図中の運用管理クライアント，JP1ジョブ運用管理サーバ，ならびにアプリケーションサーバのJP1/AJS2 - AgentおよびJP1/Baseは必要ありません。バッチサーバおよびバッチアプリケーションの操作の流れについては，「2.2.2(1)　JP1/AJS2と連携するシステム」および「2.2.2(3)　JP1/AJS2やBJEXと連携しないシステム」を参照してください。

4.3.2　スケジューリング機能で必要なプロセス

ここでは，スケジューリング機能で必要なプロセスについて説明します。

スケジューリング機能を使用する場合，CTMを使用します。スケジューリング機能を使用するアプリケーションサーバのプロセス構成例を次の図に示します。

図4-5　アプリケーションサーバのプロセス構成例（スケジューリング機能を使用する場合）

CTMで使用するプロセスの概要を次の表に示します。

表4-2　CTMで使用するプロセスの概要（スケジューリング機能の場合）

プロセス | 説明
CTMデーモン | バッチアプリケーションの実行リクエストを制御するスケジュールキューを管理するプロセスです。
CTMレギュレータ | CTMデーモンに集中するバッチアプリケーションの実行リクエストを，分散集約するためのプロセスです。
CTMドメインマネジャ | 同じCTMドメイン内のCTMデーモンの情報を管理するプロセスです。
グローバルCORBAネーミングサービス | 同じCTMドメイン内に含まれるホスト上のバッチアプリケーションの情報を共有管理しているネーミングサービスです。
スマートエージェント | Cosminexus TPBrokerで提供されている，動的な分散ディレクトリサービスを提供するプロセスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

各プロセスを配置する指針，各プロセスについては，「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

なお，PRFデーモン（パフォーマンストレーサ）は，CTMデーモンが出力した性能解析情報をファイルに出力するI／Oプロセスとして，CTMでも使用されます。詳細は，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「6.2　性能解析トレースの概要」を参照してください。

4.4　スケジューリング機能使用時のバッチアプリケーション実行環境の構築と運用

この節では，バッチアプリケーションの実行環境の構築や，運用について説明します。

バッチアプリケーションの実行環境は，スケジューリング機能を使用する場合も，Smart Composer機能と，サーバ管理コマンドを使用して構築します。バッチアプリケーションの実行環境の運用手順や，使用できる運用機能は，スケジューリング機能を使用しない場合と同じです。

バッチアプリケーションの実行環境の構築手順については，「2.2.3(1)　バッチアプリケーションの実行環境の構築」を参照してください。ただし，スケジューリング機能を使用する場合は，バッチサーバの定義や構築に加えて，CTM，スマートエージェントなどの環境設定や構築が必要になります。CTM，スマートエージェントなどの構築にもSmart Composer機能を使用します。詳細は，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「10.　バッチアプリケーションを実行するシステムの構築」を参照してください。バッチアプリケーションの実行環境でできる運用や，運用手順については，「2.2.3(2)　バッチアプリケーションの実行環境の運用」を参照してください。

また，スケジューリング機能を使用したシステムでも，JP1やクラスタソフトウェアと連携できます。詳細は，「2.2.3(3)　ほかのプログラムとの連携」を参照してください。

4.5　スケジューリング機能を使用したバッチアプリケーションの実行

この節では，スケジューリング機能を使用したバッチアプリケーションの実行について説明します。バッチアプリケーション実行機能については，「2.3.1　バッチアプリケーション実行機能の概要」を参照してください。

なお，バッチサーバで出力するバッチアプリケーションの実行ログは，スケジューリング機能を使用しない場合と同じです。バッチアプリケーションの実行ログについては，「2.3.5　バッチアプリケーションのログ出力」を参照してください。

＜この節の構成＞

4.5.1　スケジューリング機能を使用したバッチアプリケーションの状態遷移

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

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

4.5.4　バッチアプリケーション情報の一覧表示

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

4.5.1　スケジューリング機能を使用したバッチアプリケーションの状態遷移

ここでは，スケジューリング機能を使用したバッチアプリケーションの状態遷移について説明します。

バッチアプリケーションの状態遷移を次の図に示します。

図4-6　バッチアプリケーションの状態遷移（スケジューリング機能を使用する場合）

バッチアプリケーションの各状態の説明を次の表に示します。

表4-3　バッチアプリケーションの各状態の説明

バッチアプリケーションの状態 | 説明
WAITING | バッチサーバでほかのバッチアプリケーションが実行中のため，スケジュールキュー内で待機している状態です。
RUNNING | バッチアプリケーションがバッチサーバ上にある状態です。
FORCESTOPPING | バッチ強制停止コマンドによって，スケジュールキュー内のバッチアプリケーションが削除を予約された状態です。

バッチアプリケーションの状態は，バッチアプリケーション情報から確認できます。バッチアプリケーション情報の表示方法については，「4.5.4　バッチアプリケーション情報の一覧表示」を参照してください。

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

バッチアプリケーションを開始するには，cjexecjobコマンドを使用します。cjexecjobコマンドを実行するには，次の二つの方法があります。

cjexecjobコマンドを直接実行する方法
JP1/AJS2を使用しない場合はこの方法で開始します。

cjexecjobコマンドをJP1/AJS2のジョブとして定義しておき，JP1/AJS2から実行する方法
JP1/AJS2を使用する場合はこの方法で開始します。

2.の方法でバッチアプリケーションを開始するときのJP1/AJS2のジョブの定義については，「2.13　JP1/AJS2との連携」を参照してください。なお，JP1/AJS2からバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

バッチアプリケーションの開始処理，終了処理および実行時の注意事項については，スケジューリング機能を使用しない場合と同じです。詳細は，「2.3.2　バッチアプリケーションの実行」を参照してください。

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

バッチアプリケーションを強制停止するには，cjkilljobコマンドを使用します。スケジューリング機能を使用する場合，cjkilljobコマンドには，ジョブIDを指定します。

ジョブIDで指定されたバッチアプリケーションの実行リクエストがスケジュールキュー内で待機中の場合は，削除が予約されます。削除が予約されたバッチアプリケーションの実行リクエストは，CTMによってスケジュールキューから取り出された時に削除されます。

ジョブIDで指定されたバッチアプリケーションの実行リクエストがバッチサーバで実行中の場合は，強制停止されます。

バッチアプリケーションの強制停止方法，強制停止処理および実行時の注意事項については，スケジューリング機能を使用しない場合と同じです。詳細は，「2.3.3　バッチアプリケーションの強制停止」を参照してください。

4.5.4　バッチアプリケーション情報の一覧表示

実行中または待機中のバッチアプリケーションの状態や，バッチ実行コマンドの開始時刻などをバッチアプリケーション情報として一覧表示できます。ここでは，バッチアプリケーション情報の一覧表示について説明します。

＜この項の構成＞

(1)　バッチアプリケーション情報の一覧表示の方法

(2)　バッチアプリケーション情報の一覧表示処理

(1)　バッチアプリケーション情報の一覧表示の方法

バッチアプリケーション情報の一覧を表示するには，JP1/AJS2を使用しているかどうかに関係なく，cjlistjobコマンドを直接実行します。

バッチアプリケーション情報は，次の単位で取得できます。

コマンドの引数に指定されているスケジュールグループ

すべてのスケジュールグループ

cjlistjobコマンドの引数には，バッチアプリケーション情報を取得したいバッチサーバが属するスケジュールグループ名，または-allオプションを指定します。スケジュールグループ名は複数指定できます。-allオプションを指定すると，同一マシン内のバッチサーバが使用しているすべてのスケジュールグループのバッチアプリケーション情報を取得できます。

(2)　バッチアプリケーション情報の一覧表示処理

cjlistjobコマンドを実行すると，引数またはusrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.schedule.group.nameキーに指定したスケジュールグループで実行中のバッチアプリケーションの情報が取得できます。バッチアプリケーション情報は，標準出力に出力されます。

取得できるバッチアプリケーション情報を次の表に示します。

表4-4　取得できるバッチアプリケーション情報

取得できるバッチアプリケーション情報の項目
内容

スケジュールグループ名
バッチアプリケーションの実行リクエストが振り分けられるスケジュールグループの名称が出力されます。

バッチアプリケーションの状態
「running」，「waiting」または「forceStopping」が出力されます。running，waitingおよびforceStoppingは，それぞれバッチアプリケーションの状態がRUNNING，WAITINGおよびFORCESTOPPINGであることを示します。バッチアプリケーションの状態については，「4.5.1　スケジューリング機能を使用したバッチアプリケーションの状態遷移」を参照してください。

バッチアプリケーション名
cjexecjobコマンドに指定したバッチアプリケーションのクラス名が出力されます。

性能解析トレースのルートアプリケーション情報
性能解析トレースのルートアプリケーションの通信番号が出力されます。
性能解析トレースファイルに出力されたルートアプリケーション情報と突き合わせて，バッチアプリケーションの状態を確認できます。

バッチ実行コマンドの実行時刻
cjexecjobコマンドを実行した時刻が次の形式で出力されます。なお，△は，半角スペースを表します。
yyyy/mm/dd△hh:mm:ss.ssssss
yyyy：西暦年，mm：月，dd：日，hh：時，mm：分，ss：秒，ssssss：マイクロ秒

バッチアプリケーションの待機開始時刻・実行開始時刻・強制停止受付時刻
バッチアプリケーションの状態ごとに，バッチアプリケーションの状態を開始した時刻が次の形式で出力されます。なお，△は，半角スペースを表します。
yyyy/mm/dd△hh:mm:ss.ssssss
yyyy：西暦年，mm：月，dd：日，hh：時，mm：分，ss：秒，ssssss：マイクロ秒

ジョブID
バッチアプリケーションのジョブIDが出力されます。

バッチアプリケーションを実行しているバッチサーバ名
バッチアプリケーションを実行しているバッチサーバ名が出力されます。なお，バッチアプリケーションの状態が「waitting」の場合は，「-」が出力されます。

なお，バッチアプリケーションがない場合，cjlistjobコマンドを実行しても何も出力されません。この場合，cjlistjobコマンドは正常終了します。

cjlistjobコマンドの出力形式と出力例を次に示します。なお，△は，半角スペースを表します。

cjlistjobコマンドの出力形式

<スケジュールグループ名>△<バッチアプリケーションの状態>△<バッチアプリケーション名>△<性能解析トレースのルートアプリケーション情報>△<バッチ実行コマンドの実行時刻>△<バッチアプリケーションの待機開始時刻・実行開始時刻・強制停止受付時刻>△<ジョブID>△<バッチアプリケーションを実行しているバッチサーバ名>
<スケジュールグループ名>△<バッチアプリケーションの状態>△<バッチアプリケーション名>△<性能解析トレースのルートアプリケーション情報>△<バッチ実行コマンドの実行時刻>△<バッチアプリケーションの待機開始時刻・実行開始時刻・強制停止受付時刻>△<ジョブID>△<バッチアプリケーションを実行しているバッチサーバ名>
：

cjlistjobコマンドの出力例

JOBGROUP running com.hitachi.mypackage.batchApp1 0x0000000000123456 2008/04/14 17:27:35.689012 2008/04/14 17:27:37.182777 HOGE MybatchServer1
JOBGROUP running com.hitachi.mypackage.batchApp2 0x00000000002345678 2008/04/14 17:45:20.123456 2008/04/14 19:21:56.271354 102 MybatchServer2
JOBGROUP running com.hitachi.mypackage.batchApp3 0x000000000034567890 2008/04/14 18:15:54.397890 2008/04/14 19:00:00.123447 #5HL390_G3CV7 MybatchServer3
JOBGROUP waitting com.hitachi.mypackage.batchApp4 0x000000000045678901 2008/04/14 18:30:24.125444 2008/04/14 18:30:25.006220 112345 -

この例では，スケジュールグループJOBGROUPでは，MybatchServer1，MybatchServer2およびMybatchServer3でバッチアプリケーションが実行中であり，batchApp4のバッチアプリケーションの実行リクエストが待機中であることを示しています。

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

バッチアプリケーションで使用するコマンドの種類，およびバッチサーバの状態とコマンドの実行については，次の点以外はスケジューリング機能を使用しない場合と同じです。スケジューリング機能を使用しない場合との相違点を次に示します。

バッチサーバでcjexecjobコマンドを処理しているときも，cjexecjobコマンドを実行できます。

バッチサーバの状態が次のどれかのときに，cjexecjobコマンド，cjkilljobコマンドまたはcjlistjobコマンドを実行すると，メッセージKDJE55046-Eが出力されます。

バッチサーバ起動中

バッチサーバ停止中

バッチサーバの停止完了後

cjexecjobコマンドとバッチサーバの間，cjkilljobコマンドまたはcjlistjobコマンドとCTMの間でタイムアウトが発生するまでの時間を設定できます。タイムアウトは，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.request.timeoutキーで設定します。設定方法については，「4.7(3)　バッチアプリケーションで使用するコマンドの設定」を参照してください。

これらの相違点以外については，「2.3.6　バッチアプリケーションで使用するコマンドの実行について」を参照してください。

ここでは，バッチアプリケーションで使用するコマンドの処理中に異常終了した場合の対処と，コマンド実行時の注意事項について説明します。

＜この項の構成＞

(1)　コマンド処理中にバッチサーバが異常終了した場合

(2)　コマンド処理中にCTMデーモンまたはCTMレギュレータが異常終了した場合

(3)　コマンド実行時の注意事項

(1)　コマンド処理中にバッチサーバが異常終了した場合

バッチサーバでcjexecjobコマンド，cjkilljobコマンドまたはcjlistjobコマンドを処理している場合に，バッチサーバが異常終了したときは，メッセージKDJE55021-Eが出力されます。バッチサーバの状態を確認してから再度コマンドを実行してください。

(2)　コマンド処理中にCTMデーモンまたはCTMレギュレータが異常終了した場合

cjexecjobコマンド，cjkilljobコマンドまたはcjlistjobコマンドを処理している場合に，CTMデーモンまたはCTMレギュレータが異常終了したときは，メッセージKDJE55047-Eが出力されます。このメッセージは，スマートエージェントからスケジュールグループ名を取得したあと，CTMデーモンまたはCTMレギュレータと通信する際にプロセスが異常終了した場合に出力されます。CTMデーモンおよびCTMレギュレータの状態を確認してから再度コマンドを実行してください。

(3)　コマンド実行時の注意事項

コマンド実行時の注意事項を次に示します。

IPアドレスを複数持つマシンで，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）または環境変数にIPアドレスの指定がない場合は，ORBゲートウェイが接続するIPアドレスが自動的に判断されます。

スケジューリング機能を使用する場合は，CTMによって振り分けられたバッチサーバでバッチアプリケーションを実行します。そのため，cjexecjobコマンドはバッチサーバに対して直接実行できません。

待機中のバッチアプリケーションに対してcjkilljobコマンドを実行した場合，バッチアプリケーションはCTMによって削除予約されます。削除予約されたバッチアプリケーションはスケジュールキューから取り出された時に削除されます。この場合，削除予約されたバッチアプリケーションがスケジュールキュー内に残っているので，次の点に注意してください。

削除予約されたバッチアプリケーションと重複するジョブIDは使用できません。

cjexecjobコマンドの実行によって，バッチアプリケーションの実行リクエストの数がスケジュールキューに登録できる数を超えると，バッチサーバはメッセージKDJE55060-Eを出力して異常終了します。

待機中のバッチアプリケーションに対してcjkilljobコマンドを実行した場合，スケジュールキューから取り出されるまで，cjexecjobコマンドは終了しません。

cjexecjobコマンド，cjkilljobコマンドまたはcjlistjobコマンド実行時に，バッチサーバがない場合，メッセージを出力してコマンドは異常終了します。出力されるメッセージは，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキーの指定によって異なります。

「true」を指定している場合
メッセージKDJE555010-EまたはKDJE55046-Eを出力します。

「false」を指定している場合
メッセージKDJE55010-Eを出力します。

cjexecjobコマンド実行時，簡易構築定義ファイルおよびusrconf.cfg（バッチアプリケーション用オプション定義ファイル）の指定によって，コマンドが異常終了することがあります。

簡易構築定義ファイルでejbserver.ctm.enabledパラメタに「true」を指定して，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキーで「false」を指定している場合
メッセージKDJE55067-Eを出力して異常終了します。

簡易構築定義ファイルでejbserver.ctm.enabledパラメタに「false」を指定して，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキーで「true」を指定している場合
指定したスケジュールグループがないときは，メッセージKDJE55046-Eを出力して異常終了します。

cjlistjobコマンド実行時に，簡易構築定義ファイルでejbserver.ctm.enabledパラメタに「false」を指定して，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のbatch.ctm.enabledキーで「true」を指定している場合，バッチサーバではコマンドを受け付けられません。この場合，バッチアプリケーション情報は出力されません。

4.6　スケジューリング機能を使用する環境への移行

この節では，スケジューリング機能を使用していない環境からの移行について説明します。バッチアプリケーションの実行環境を，スケジューリング機能を使用していない環境から，スケジューリング機能を使用する環境に移行する場合，使用中の環境はそのまま使用できません。

使用中の環境で，定義ファイルを編集する必要があります。環境移行時に設定を編集するファイルを次の表に示します。

表4-5　環境移行時に設定を編集するファイル

ファイル | 編集する主なキー | 設定内容 | 必須または任意
usrconf.properties（バッチサーバ用ユーザプロパティファイル） | ejbserver.ctm.enabled | true | 必須
vbroker.agent.enableLocator | true※ | 任意
ejbserver.batch.schedule.group.name | スケジュールグループ名 | 任意
ejbserver.batch.queue.length | 作成されるスケジュールキューの長さ | 任意
usrconf.cfg（バッチアプリケーション用オプション定義ファイル） | batch.ctm.enabled | true | 必須
batch.schedule.group.name | スケジュールグループ名 | 任意
batch.request.timeout | バッチ実行コマンドとバッチサーバの間，バッチ強制停止コマンドまたはバッチ一覧表示コマンドとCTMの間のタイムアウト | 任意
batch.vbroker.agent.port | スマートエージェントが使用しているポート番号 | 任意

（凡例）必須：必ず指定する　任意：必要に応じて設定する

注　ここでは，スケジューリング機能を使用する環境への移行時に編集する主なキーについて説明しています。usrconf.properties（バッチサーバ用ユーザプロパティファイル）のファイルおよびキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.3　usrconf.properties（バッチサーバ用ユーザプロパティファイル）」を参照してください。

usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のファイルおよびキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.6　usrconf.cfg（バッチアプリケーション用オプション定義ファイル）」を参照してください。

注※　デフォルトではfalseが設定されていますが，CTMとの連携時には自動的にtrueが設定されます。

各ファイルで編集するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

4.7　実行環境での設定

スケジューリング機能を使用する場合，次の設定が必要です。

バッチサーバ

CTM

バッチアプリケーションで使用するコマンド

この節では，それぞれの設定項目について説明します。なお，スケジューリング機能を使用する場合は，バッチアプリケーション実行機能の定義も設定する必要があります。バッチアプリケーション実行機能の定義については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

＜この節の構成＞

(1)　バッチサーバの設定

(2)　CTMの設定

(3)　バッチアプリケーションで使用するコマンドの設定

(1)　バッチサーバの設定

バッチサーバの設定は，簡易構築定義ファイルで実施します。スケジューリング機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのスケジューリング機能の定義を次の表に示します。

表4-6　簡易構築定義ファイルでのスケジューリング機能の定義

項目
指定するパラメタ
設定内容
必須または任意

スケジューリング機能を使用する設定
ejbserver.ctm.enabled
スケジューリング機能を使用するかどうかを指定します。デフォルトではtrueが設定されます。また，<tier-type>タグにctm-tierを指定している場合，システムの構築時には自動的にtrueが設定されます。
任意

スマートエージェントを使用する設定
vbroker.agent.enableLocator
スマートエージェントを使用します。デフォルトではfalseが設定されますが，CTMとの連携時には自動的にtrueが設定されます。このため，パラメタの値をtrueに変更する必要はありません。
任意

スケジュールグループ名の設定
ejbserver.batch.schedule.group.name
CTMによって管理されるバッチサーバ群のスケジュールグループ名を指定します。デフォルトではJOBGROUPが設定されます。
CTMは，スケジュールグループごとにバッチアプリケーションの実行をスケジューリングします。
複数のスケジュールグループを使用してスケジュールキューを分ける場合には，バッチサーバごとにスケジュールグループ名を設定してください。
任意

スケジュールキューの長さの設定
ejbserver.batch.queue.length
CTMで作成されるスケジュールキューの長さを指定します。デフォルトでは50が設定されます。
任意

（凡例）任意：必要に応じて設定する

注　ここでは，スケジューリング機能使用時に指定する主なパラメタについて説明しています。スケジューリング機能使用時には，次のejbserver.ctmから始まるパラメタも任意で指定できます。

ejbserver.ctm.ActivateTimeOut

ejbserver.ctm.CTMDomain

ejbserver.ctm.CTMID

ejbserver.ctm.CTMMyHost

ejbserver.ctm.DeactivateTimeOut

簡易構築定義ファイルおよびパラメタについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　CTMの設定

CTMの設定は，簡易構築定義ファイルで実施します。スケジューリング機能の定義は，簡易構築定義ファイルの論理CTM（componenttransaction-monitor）の<configuration>タグ内に指定します。指定するパラメタを次に示します。このパラメタは必ず指定してください。

ctm.Agent
スケジューリング機能を使用する場合には，CTMレギュレータのORBゲートウェイ機能を使用します。パラメタの値は必ず1を指定してください。

簡易構築定義ファイルおよびパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(3)　バッチアプリケーションで使用するコマンドの設定

バッチアプリケーションで使用するコマンドの設定は，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）で実施します。スケジューリング機能の定義は，usrconf.cfgでコマンドのオプションを指定します。

usrconf.cfgでのスケジューリング機能の定義を次の表に示します。

表4-7　usrconf.cfgでのスケジューリング機能の定義

項目
指定するキー
設定内容
必須または任意

スケジューリング機能を使用する設定
batch.ctm.enabled
スケジューリング機能を使用するかどうかを指定します。パラメタの値は必ずtrueを指定してください。
必須

スケジュールグループ名の設定
batch.schedule.group.name
CTMによって管理されるバッチサーバ群のスケジュールグループ名を指定します。デフォルトではJOBGROUPが設定されます。
CTMは，スケジュールグループごとにバッチアプリケーションの実行をスケジューリングします。
任意

CTMに接続している最大時間の設定
batch.request.timeout
バッチ実行コマンドとバッチサーバの間，バッチ強制停止コマンドまたはバッチ一覧表示コマンドとCTMの間のタイムアウトを指定します。デフォルトでは0（タイムアウトしない）が設定されます。
任意

スマートエージェントが使用しているポート番号の設定
batch.vbroker.agent.port
スマートエージェントが使用しているポート番号を指定します。デフォルトでは14000が設定されます。
任意

（凡例）必須：必ず指定する　任意：必要に応じて設定する

注　ここでは，スケジューリング機能使用時に指定する主なキーについて説明しています。usrconf.cfg（バッチアプリケーション用オプション定義ファイル）およびキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.6　usrconf.cfg（バッチアプリケーション用オプション定義ファイル）」を参照してください。

4.8　スケジューリング機能使用時の注意事項

スケジューリング機能使用時の注意事項を次に示します。

スケジューリング機能で使用するCTMデーモンでは，J2EEサーバに対するクライアントからのリクエストを負荷分散させないでください。

複数のCTMデーモン間でバッチサーバに対するリクエストを負荷分散させないでください。複数のCTMデーモンに接続するバッチサーバでは，それぞれ異なるスケジュールグループ名を指定してください。
複数のCTMデーモン間でバッチサーバに対するリクエストを負荷分散した場合，バッチアプリケーションの実行リクエストは受け付けられますが，次のような問題が発生することがあります。

バッチアプリケーション情報の一覧が表示できない（バッチアプリケーション情報が取得できない）。

バッチアプリケーションの強制停止に失敗する。

バッチアプリケーションの実行リクエストがスケジュールキューからバッチサーバへ渡される間にバッチ強制停止コマンドを実行すると，メッセージKDJE55016-Wが出力されてバッチアプリケーションを強制停止できないことがあります。この場合，バッチ一覧表示コマンドを実行してバッチアプリケーションの状態を確認します。バッチアプリケーションの状態が「running」の場合は，再度バッチ強制停止コマンドを実行してください。

CTMとバッチサーバの間でタイムアウトが発生すると，メッセージKDJE55061-Eが出力されます。この場合，バッチアプリケーションの実行リクエストおよび実行中のバッチアプリケーションは，CTMの管理対象外となります。この場合に，実行中のバッチアプリケーションに対して一覧表示や強制停止を実行するときは，バッチサーバ名を指定して各コマンドを実行してください。なお，バッチ一覧表示コマンドは，スケジューリング機能を使用しない設定に変更してから実行してください。スケジューリング機能を使用しない設定にする場合は，usrconf.cfg（バッチアプリケーション用オプション定義ファイル）でbatch.ctm.enabledキーに「false」を指定してください。
各コマンドに指定するバッチサーバ名は，バッチ実行コマンドのメッセージ（KDJE55066-I）で特定できます。

バッチアプリケーションがバッチサーバで開始する前に，［Ctrl］＋［C］の入力やタイムアウトの発生などによってバッチ実行コマンドが終了されると，メッセージKDJE55007-Eがメッセージログに出力され，バッチアプリケーションの開始に失敗します。この場合には，メッセージKDJE40062-Eが標準エラー出力に出力されることがあります。

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

この章では，J2EEサーバ間のセッション情報を引き継ぐための機能である，セッションフェイルオーバ機能の概要について説明します。また，セッションフェイルオーバ機能の種類と差異について説明します。

＜この章の構成＞

5.1　この章の構成

5.2　セッションフェイルオーバ機能の概要

5.3　セッションフェイルオーバ機能の種類と差異

5.1　この章の構成

J2EEサーバ間のセッション情報を引き継ぐには，セッションフェイルオーバ機能を使用します。ここでは，セッションフェイルオーバ機能の概要およびセッションフェイルオーバ機能の種類と差異について説明します。

この章の構成を次の表に示します。

表5-1　この章の構成（セッションフェイルオーバ機能）

分類 | タイトル | 参照先
解説 | セッションフェイルオーバ機能の概要 | 5.2
セッションフェイルオーバ機能の種類と差異 | 5.3

注　「実装」，「設定」，「運用」および「注意事項」について，この機能固有の説明はありません。

5.2　セッションフェイルオーバ機能の概要

セッションフェイルオーバ機能とは，J2EEサーバやWebサーバでの，ソフトウェア障害，ハードウェア障害，およびネットワーク障害の発生時に，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトを引き継ぐ機能です。

セッションフェイルオーバ機能を使用すると，システム内の特定のJ2EEサーバに障害が発生した場合に，障害発生前のセッション情報を引き継いで，ほかのJ2EEサーバで業務を続行できます。これによって，システムの可用性を高めることができます。

ここでは，セッションフェイルオーバ機能を利用する利点と，グローバルセッションを利用したセッション管理について説明します。また，セッションフェイルオーバ機能の前提条件について説明します。

＜この節の構成＞

5.2.1　セッションフェイルオーバ機能を利用する利点

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

5.2.3　セッションフェイルオーバ機能の前提条件

5.2.1　セッションフェイルオーバ機能を利用する利点

HttpSessionオブジェクトは，J2EEサーバのメモリ上で保持されています。J2EEサーバで障害が発生すると，HttpSessionオブジェクトは失われます。複数のJ2EEサーバで構成されているシステムの場合に，一つのJ2EEサーバで障害が発生すると，リクエストはほかのJ2EEサーバに転送されます。しかし，HttpSessionオブジェクトが失われるため，HttpSessionオブジェクトに登録された情報（セッション情報）は引き継がれません。このため，リクエストが転送されたJ2EEサーバ上のJ2EEアプリケーションでは，新規のセッションとして扱うことになります。例えば，ユーザ認証処理後の画面で障害が発生すると，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報を管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡せます。このため，J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

また，統合ユーザ管理を使用している場合でも，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継げます。

セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れを次の図に示します。

図5-1　セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れ

セッションフェイルオーバ機能を使用していないときにサーバに障害が発生すると，セッション情報が失われるため，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報がサーバ間で引き継がれるため，ブラウザでのユーザの操作では，サーバの障害発生に気づくことなく，処理を続行できます。

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

セッションフェイルオーバ機能では，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトの情報を，ほかのJ2EEサーバに引き継ぎます。

複数のJ2EEサーバ間で引き継いで使用できるセッションを，グローバルセッションといいます。HTTPセッションは，そのセッションを扱っているJ2EEサーバに障害が発生すると消失します。一方，グローバルセッションは，J2EEサーバとは別のプロセス（データベースまたはSFOサーバ）で管理されているため，J2EEサーバに障害が発生した場合も消失しません。このため，一つのJ2EEサーバで障害が発生した場合に，別のJ2EEサーバにHTTPセッションを作成して，グローバルセッションの情報を引き継げます。

グローバルセッションを使用している場合に，ほかのJ2EEサーバに引き継がれるHttpSessionオブジェクトの情報を，グローバルセッション情報といいます。

HTTPセッションとグローバルセッションの範囲について，次の図に示します。

図5-2　HTTPセッションとグローバルセッションの範囲

セッションフェイルオーバ機能では，J2EEサーバでの障害発生時にグローバルセッション情報を引き継ぐことで，ユーザにエラーを通知することなく，障害発生前の状態で業務を続行できます。

5.2.3　セッションフェイルオーバ機能の前提条件

セッションフェイルオーバ機能を使用するには，負荷分散機の使用が前提となります。

なお，リダイレクタの負荷分散機能を使用している場合，セッションフェイルオーバ機能は使用できません。セッションフェイルオーバ機能とリダイレクタの負荷分散機能を同時に使用すると，次のような問題が発生します。

負荷分散機による，J2EEサーバ自体の負荷分散ができなくなります。

負荷分散機のヘルスチェックを任意のJ2EEサーバに送信できません。また，J2EEサーバに障害が発生した場合も，リダイレクタで正常なJ2EEサーバにリクエストが転送されます。そのため，負荷分散機でJ2EEサーバの障害を検知できなくなります。

参考

負荷分散機によるリクエストの振り分けとは

負荷分散機では，リクエストの振り分けが実行されます。これによって，負荷が分散されるので，システムの安定稼働と処理性能の向上が図れます。

負荷分散機を使用した負荷分散には，WebサーバやJ2EEサーバに負荷分散処理に関する負荷が掛からないという利点があります。なお，負荷分散機によるリクエストの振り分け方式は，それぞれの負荷分散機に依存します。

負荷分散機によるリクエスト振り分けの例を次の図に示します。

図5-3　負荷分散機によるリクエストの振り分けの例

5.3　セッションフェイルオーバ機能の種類と差異

J2EEサーバ間のセッション情報の引き継ぎを実現するための機能として，データベースセッションフェイルオーバ機能とメモリセッションフェイルオーバ機能があります。それぞれの機能の概要について説明します。また，二つの機能の機能差異についても説明します。

データベースセッションフェイルオーバ機能の概要
データベースセッションフェイルオーバ機能を使用すると，セッション情報をデータベースで管理できます。そのため，WebサーバやJ2EEサーバに障害が発生した場合でも，データベースで管理されているセッション情報をほかのサーバに引き継いでセッションを再作成できます。また，一度作成したセッション情報はデータベースで保障されます。
データベースセッションフェイルオーバ機能の概要について次の図に示します。

図5-4　データベースセッションフェイルオーバ機能の概要

データベースセッションフェイルオーバ機能の概要について説明します。項番は図中の番号と対応しています。

Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます。

作成されたセッションについて，セッション情報が作成されます。

セッション情報がデータベースに格納されます。

Webサーバ1またはJ2EEサーバ1で障害が発生すると，データベースに格納されたセッション情報がWebサーバ2またはJ2EEサーバ2へ引き継がれ，障害発生前の状態で業務を続行できます。
データベースセッションフェイルオーバ機能の詳細については「6.　データベースセッションフェイルオーバ機能」を参照してください。

メモリセッションフェイルオーバ機能の概要
メモリセッションフェイルオーバ機能を使用すると，セッション情報がSFOサーバで管理できます。そのため，WebサーバやJ2EEサーバに障害が発生した場合でも，SFOサーバで管理されているセッション情報をほかのサーバに引き継いでセッションを再作成できます。
メモリセッションフェイルオーバ機能の概要について次の図に示します。

図5-5　メモリセッションフェイルオーバ機能の概要

メモリセッションフェイルオーバ機能の概要について説明します。項番は図中の番号と対応しています。

Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます。

作成されたセッションについて，セッション情報が作成されます。

セッション情報がSFOサーバに格納されます。

メモリセッションフェイルオーバ機能の詳細については「7.　メモリセッションフェイルオーバ機能」を参照してください。

データベースセッションフェイルオーバ機能とメモリセッションフェイルオーバ機能ではHTTPセッションの情報の格納先が異なります。そのため，二つの機能には次の表に示す機能差異があります。

表5-2　データベースセッションフェイルオーバ機能とメモリセッションフェイルオーバ機能の機能差異

比較項目 | 機能差異
データベースセッションフェイルオーバ機能 | メモリセッションフェイルオーバ機能
HTTPセッションの情報の格納先 | データベース | SFOサーバ（メモリ）
J2EEサーバに障害が発生した際の動作 | 障害発生直前の状態から業務が再開できます。 | 障害発生直前の状態から業務が再開できます。
HTTPセッションの情報の格納先に障害が発生した際の動作 | J2EEサーバ上のセッション情報を操作して業務を続行できます。 | システム内のすべてのHTTPセッションが削除され，業務は再開できません。
システムの可用性 | データベースセッションフェイルオーバ機能が優れています。
リクエスト処理性能 | メモリセッションフェイルオーバ機能が優れています。

メモリセッションフェイルオーバ機能とデータベースセッションフェイルオーバ機能は同時に使用できません。機能差異を踏まえて，システムに適した機能を選択してください。なお，メモリセッションフェイルオーバ機能とデータベースセッションフェイルオーバ機能を同時に有効にする設定をした場合，アプリケーションの開始に失敗します。

6.　データベースセッションフェイルオーバ機能

この章では，データベースセッションフェイルオーバ機能について説明します。

＜この章の構成＞

6.1　この章の構成

6.2　データベースセッションフェイルオーバ機能の概要

6.3　前提条件

6.4　グローバルセッションを利用したセッション管理（データベースセッションフェイルオーバ機能）

6.5　メモリの見積もり

6.6　データベースセッションフェイルオーバ機能の抑止

6.7　性能を重視したモードの選択（完全性保障モードの無効化）

6.8　データベースセッションフェイルオーバ機能で実施される処理

6.9　実装時の注意事項

6.10　cosminexus.xmlでの定義

6.11　データベースの設定

6.12　J2EEサーバの設定

6.13　DB Connectorの設定

6.14　Webアプリケーションの設定

6.15　データベースセッションフェイルオーバ機能に関する設定の変更

6.16　データベースのテーブルの削除

6.17　データベースセッションフェイルオーバ機能を使用時の注意事項

6.1　この章の構成

ここでは，データベースセッションフェイルオーバ機能について説明します。

この機能を使用すると，アプリケーションで実行中のセッション情報がデータベースに格納されます。格納されたセッション情報は，WebサーバやJ2EEサーバで障害が発生したときに，ほかのJ2EEサーバに引き渡されます。これによって，障害発生時にリクエストがほかのJ2EEサーバに転送された場合でも，障害発生前の状態で業務を続行できるようになります。

この章の構成を次の表に示します。

表6-1　この章の構成（データベースセッションフェイルオーバ機能）

分類 | タイトル | 参照先
解説 | データベースセッションフェイルオーバ機能の概要 | 6.2
前提条件 | 6.3
グローバルセッションを利用したセッション管理（データベースセッションフェイルオーバ機能） | 6.4
メモリの見積もり | 6.5
データベースセッションフェイルオーバ機能の抑止 | 6.6
性能を重視したモードの選択（完全性保障モードの無効化） | 6.7
データベースセッションフェイルオーバ機能で実施される処理 | 6.8
実装 | 実装時の注意事項 | 6.9
cosminexus.xmlでの定義 | 6.10
設定 | データベースの設定 | 6.11
J2EEサーバの設定 | 6.12
DB Connectorの設定 | 6.13
Webアプリケーションの設定 | 6.14
データベースセッションフェイルオーバ機能に関する設定の変更 | 6.15
データベースのテーブルの削除 | 6.16
注意事項 | データベースセッションフェイルオーバ機能を使用時の注意事項 | 6.17

注　「運用」について，この機能固有の説明はありません。

6.2　データベースセッションフェイルオーバ機能の概要

データベースセッションフェイルオーバ機能は，セッション情報をデータベースに格納することで冗長化し，システムの可用性を高めるための機能です。

ここでは，データベースセッションフェイルオーバ機能の処理の概要，運用モード，および適用手順について説明します。

＜この節の構成＞

6.2.1　処理の概要

6.2.2　セッションフェイルオーバ機能の運用モード

6.2.3　適用手順

6.2.1　処理の概要

データベースセッションフェイルオーバ機能を使用すると，リクエストによるセッションの作成処理が発生したときに，処理の延長上でセッション情報がデータベースに格納されます。そのため，障害が発生した場合も，格納されているセッション情報を基にセッションを再作成し，正常に業務を続行できます。

セッション情報の格納の流れ，および障害が発生した場合の処理について説明します。

＜この項の構成＞

(1)　セッション情報の格納の流れ

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

(3)　データベースで障害が発生した場合の処理

(1)　セッション情報の格納の流れ

データベースセッションフェイルオーバ機能を使用すると，リクエストによるセッションの作成処理が発生したときに，処理の延長上でセッション情報がデータベースに格納されます。

セッション情報の格納の流れを次の図に示します。

図6-1　セッション情報の格納の流れ

Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます（1.）。セッションの作成の処理の延長上で，セッション情報が作成され（2.），セッション情報がデータベースに格納されます（3.）。

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

WebサーバまたはJ2EEサーバで障害が発生した場合，データベースに格納されているセッション情報を基に，ほかのJ2EEサーバでセッションを再作成し，正常に業務を続行できます。

WebサーバまたはJ2EEサーバで障害が発生した場合の処理について，次の図に示します。

図6-2　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

Webサーバ1で障害が発生すると，負荷分散機によってWebサーバ2へリクエストが転送されます（1.）。転送先のJ2EEサーバ2でリクエストを処理するとき，リクエストに関連づけられたセッションが存在しないため，データベースからセッション情報を取得して（2.），セッションを再作成します（3.）。

セッションが正常に引き継がれ，障害発生前の状態で業務を続行できます。

また，J2EEサーバ1を再起動しWebサーバ1が障害から回復すると，再びリクエストはWebサーバ1に送信されます。

(3)　データベースで障害が発生した場合の処理

データベースで障害が発生すると，J2EEサーバ上のセッション情報だけを操作して業務を続行できます。データベースが障害から回復し，それ以降のセッションの操作でデータベースにアクセスできたとき，J2EEサーバ上で操作したセッション情報でデータベースを更新します。

これによって，クライアントはデータベースに障害が発生したことを意識しないで業務を続行できます。

6.2.2　セッションフェイルオーバ機能の運用モード

データベースに格納済みのグローバルセッション情報に対して同じセッションIDを持つリクエストが複数同時に送信された場合，デフォルトの設定では，リクエストは複数同時に処理できます。これによって，データベースセッションフェイルオーバ機能を使用することによる処理性能の低下は抑えられています。

ただし，この運用は，冗長化された複数のJ2EEサーバから同じセッションIDのグローバルセッション情報を同時に更新するような処理が発生しないことを前提とした運用です。複数のJ2EEサーバから同じセッションIDのグローバルセッション情報が同時に更新された場合は，グローバルセッション情報の整合性が失われるおそれがあります。このようなケースを許容できないシステムでは，グローバルセッション情報の整合性を確保するためのモードを有効にする必要があります。

グローバルセッション情報の整合性を保障するモードを完全性保障モードといいます。このモードを有効にした場合，グローバルセッションを更新するたびにデータベースにロックが設定されます。同じセッションIDの複数のリクエストが同時に送信された場合は，リクエストがシリアルに処理されるため，グローバルセッション情報が不整合な状態になることはありません。ただし，複数同時に実行できないこと，およびグローバルセッション情報の格納のたびにロックの設定・解除処理が発生することから，リクエスト処理性能に影響を及ぼす場合があります。

このため，データベースセッションフェイルオーバ機能を使用する場合は，システムの目的や特性に応じて，どちらのモードで運用するかを検討する必要があります。

完全性保障モードの有効・無効による主な違いを次の表に示します。

表6-2　完全性保障モードの有効・無効による主な違い

比較項目 | 完全性保障モード
無効 | 有効
適したシステムの特性 | 性能を重視するシステムに適しています。 | 性能が低下したとしても，確実なセッション情報の引き継ぎが必要なシステムに適しています。
リクエストの処理性能 | 同じセッションIDの複数のリクエストを同時に処理できるので，優れています。 | リクエストをシリアルに処理する必要があるため，性能が低下します。
グローバルセッション情報の完全性 | 同じセッションIDのグローバルセッション情報を同時に更新した場合は，保障されません。 | 保障されます。
データベースに障害が発生した場合の挙動 | J2EEサーバ上のセッション情報を使用して処理を継続します（データベースセッションフェイルオーバ機能の縮退運用）。 | エラーメッセージを出力して処理を停止します。

それぞれのモードでのリクエスト処理の流れを次の図に示します。

図6-3　完全性保障モードを無効にした場合のリクエスト処理の流れ（デフォルトの設定）

完全性保障モードが無効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際にデータベースのロックが取得・解除されますが，一度コミットしたあとのセッション取得処理ではロックが取得されません。また，以降のグローバルセッション情報の更新処理では，データベースのロックの取得処理および解除処理は実施されません。

図6-4　完全性保障モードを有効にした場合のリクエスト処理の流れ

完全性保障モードが有効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際に，データベースのロックが取得・解除されます。さらに，一度コミットしたあとのセッション取得処理で，再度ロックが取得されます。これによって，HTTPセッション作成後，Webアプリケーション実行中にJ2EEサーバまたはデータベースで障害が発生した場合にも，データベースに不整合が発生しないことが保障されます。また，以降のグローバルセッション情報の更新処理では，更新するたびにデータベースのロックを取得し，更新したあとで解除する処理が実施されます。

グローバルセッション情報のロック時の動作については，「6.8.5(1)　ロック取得時のロック取得処理の呼び出し結果」を参照してください。

また，完全性保障モードの有効・無効の設定によって，使用できる機能が異なります。

完全性保障モードの有効・無効の設定別に，使用できるデータベースセッションフェイルオーバの機能を次の表に示します。

表6-3　使用できるデータベースセッションフェイルオーバの機能

項番 | 機能名 | 概要 | 完全性保障モードの設定別の使用可否 | 参照先
無効 | 有効 |
1 | HTTPセッションの属性情報のサイズ見積もり | HTTPセッションに登録した属性をデータベースに格納する場合のサイズを見積もるための機能 | ○ | ○ | 6.5
2 | データベースセッションフェイルオーバ機能の抑止 | URLパスの拡張子，またはURIによってデータベースセッションフェイルオーバ機能の有効／無効を切り替える機能 | ○ | ○ | 6.6
3 | 同一セッションIDの同時実行 | 同じセッションIDを持つリクエストの同時実行を実現して，リクエスト処理性能への影響を軽減する機能 | ○ | × | 6.7.1
4 | HTTPセッションの参照専用リクエスト定義 | HTTPセッションを更新しないリクエストの場合にグローバルセッション情報を更新しないようにすることで，データベースアクセスによるリクエスト処理性能の低下を防止する機能 | ○ | × | 6.7.2

（凡例）

○：使用できる。　×：使用できない。

完全性保障モードを無効にした場合の動作の詳細，使用できる機能および注意事項については，「6.7　性能を重視したモードの選択（完全性保障モードの無効化）」を参照してください。

完全性保障モードの設定については，「6.12　J2EEサーバの設定」を参照してください。

6.2.3　適用手順

データベースセッションフェイルオーバ機能を使用する場合に必要な，環境構築の準備と各種設定について説明します。

＜この項の構成＞

(1)　環境構築の準備

(2)　必要な設定

(1)　環境構築の準備

データベースセッションフェイルオーバ機能を使用する場合に環境構築の準備として実施する項目について，実施内容および参照先を次の表に示します。

表6-4　データベースセッションフェイルオーバ機能を使用する環境構築の準備として実施する項目の実施内容および参照先

実施順序 | 実施項目 | 実施内容 | 参照先
1 | 前提条件の確認 | 前提となる構成および設定を確認します。 | 6.3
2 | HTTPセッションの属性情報のサイズ見積もり | HTTPセッションの属性情報のサイズを見積もります。見積もった値はデータベースの環境設定で必要になります。 | 6.5.2

(2)　必要な設定

データベースセッションフェイルオーバ機能を使用する場合に必要な設定について，設定内容および参照先を次の表に示します。

表6-5　データベースセッションフェイルオーバ機能使用時に必要な設定項目の設定内容および参照先

設定順序
設定項目
設定内容
参照先

1
Webアプリケーションの設定※
次の設定をします。

データベースセッションフェイルオーバ機能の設定（Webアプリケーション単位）

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

アプリケーション識別子の設定

HTTPセッションの属性情報の最大サイズ

拡張子によるセッションフェイルオーバ機能の抑止の設定

6.9，6.10

2
データベースの設定
次の設定をします。

テーブルの作成

データベースの環境設定

6.11

3
J2EEサーバの設定
次の設定をします。

データベースセッションフェイルオーバ機能の設定（J2EEサーバ単位）

DB Cnnectorの別名の設定

完全性保障モードの設定

シリアライズ処理で使用するメモリ量の設定

セッションフェイルオーバ機能の抑止の設定（拡張子，またはURI単位）

参照リクエストの設定

HttpSessionのサーバID付加機能の設定

同時実行スレッド数制御機能を使用する場合の実行待ちキュー不足時の設定

ネゴシエーション失敗時のWebアプリケーション開始処理の設定

データベースセッションフェイルオーバ機能の抑止対象リクエスト内での，getSessionメソッド実行時の例外の設定

6.12

4
DB Connectorの設定
次の設定をします。

トランザクションサポートのレベルの設定

DB Connectorの環境設定

DB Cnnectorの別名の設定

6.13

注※　Webアプリケーションの設定は開発環境で実施します。サーバ管理コマンドを使用して実行環境でWebアプリケーションの設定をしたい場合は「6.14　Webアプリケーションの設定」を参照してください。

6.3　前提条件

データベースセッションフェイルオーバ機能を使用するための前提条件である次の項目について説明します。

引き継げるHTTPセッションの属性

前提となる構成

前提となる設定

＜この節の構成＞

6.3.1　引き継げるHTTPセッションの属性

6.3.2　前提となる構成

6.3.3　前提となる設定

6.3.1　引き継げるHTTPセッションの属性

データベースセッションフェイルオーバ機能使用時に引き継げるHTTPセッションの属性は，シリアライズに成功するオブジェクトです。シリアライズに失敗するオブジェクトを属性としてHTTPセッションに登録すると，HTTPセッションをデータベースに冗長化できません。引き継げるHTTPセッションの属性の詳細については，「6.4.2　グローバルセッション情報として引き継げるHTTPセッションの属性」を参照してください。

6.3.2　前提となる構成

データベースセッションフェイルオーバ機能を使用する場合，負荷分散機を使用した，複数のJ2EEサーバにリクエストを振り分けるシステム構成が前提となります。また，各J2EEサーバで作成されたHTTPセッションの情報を格納するためのデータベースの配置が必要です。

負荷分散機の使用については，「5.2.3　セッションフェイルオーバ機能の前提条件」を参照してください。

HTTPセッション情報の格納先として使用できるデータベース，JDBCドライバ，およびリソースアダプタの対応について次の表に示します。

表6-6　使用できるデータベース，JDBCドライバおよびリソースアダプタの対応

データベース | JDBCドライバ | リソースアダプタ※
HiRDB | HiRDB Type4 JDBC Driver | DBConnector_HiRDB_Type4_CP.rar
Oracle | Oracle JDBC Thin Driver | DBConnector_Oracle_CP.rar
DBConnector_CP_ClusterPool_Root.rar
DBConnector_Oracle_CP_ClusterPool_Member.rar

注※　データベースセッションフェイルオーバ機能で使用するリソースアダプタはDB Connectorです。データベースセッションフェイルオーバ機能で使用するDB Connectorに必要な設定については，「6.13　DB Connectorの設定」を参照してください。

なお，データベースセッションフェイルオーバ機能を使用するための詳細なシステム構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.10.1　データベースを使用する構成（データベースセッションフェイルオーバ機能）」を参照してください。

参考

データベースセッションフェイルオーバ機能を使用する構成は，ここで示した条件を満たしている場合，構成から設計し直す必要がありません。機能の設定とパラメタチューニングを実施すればデータベースセッションフェイルオーバ機能を使用できます。

6.3.3　前提となる設定

データベースセッションフェイルオーバ機能を使用するためには，次の設定が必要です。

Webクライアントが保持する無効なセッションIDの削除
HTTPセッション無効化時にWebクライアントに保持されているHTTP Cookieの情報を削除し，無効化済みのHTTPセッションに対するセッションIDの送信を抑止する機能です。データベースセッションフェイルオーバ機能を使用するには，この機能を有効にする必要があります。
HTTPセッションのセッションIDを示すHTTP Cookieの削除を無効にしている場合，Webアプリケーション開始時にKDJE34339-Eのエラーメッセージがメッセージログに出力され，Webアプリケーションの開始に失敗します。HTTPセッションのセッションIDを示すHTTP Cookieの削除については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.4　Webクライアントが保持する無効なセッションIDの削除」を参照してください。

HttpSessionのサーバID付加機能によるセッションIDへのサーバID付加
HTTPセッションのセッションIDにサーバIDを付加する機能です。完全性保障モードを無効にしている場合は，この機能を有効にする必要があります。また，冗長化したJ2EEサーバごとに，異なるサーバIDを設定します。
HttpSessionのサーバID付加機能を無効にした場合，Webアプリケーションの開始時にKDJE34371-Eのエラーメッセージがメッセージログに出力され，Webアプリケーションの開始に失敗します。冗長化したJ2EEサーバごとに異なるサーバIDを設定しなかった場合は，意図しないJ2EEサーバにグローバルセッション情報が引き継がれ，グローバルセッション情報の完全性が失われることがあります。
HttpSessionのセッションIDへのサーバIDの付加機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

HttpSessionオブジェクト数の上限値の指定機能
有効となるHttpSessionオブジェクト数の上限値を設定する機能です。
アプリケーション開始時に実施されるネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を中止する設定にしているときは，上限値に1以上の有効な値を設定する必要があります。HttpSessionオブジェクト数の上限値を設定していない場合，アプリケーション開始時にKDJE34303-Eのエラーメッセージがメッセージログに出力され，アプリケーションの開始に失敗します。
ただし，ネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を続行する設定にしているときは，HttpSessionオブジェクト数の上限値の設定は任意です。また，上限値に-1（無制限）を設定することもできます。HTTPSessionオブジェクト数の上限値に-1（無制限），またはデータベースのセッション情報格納テーブルのレコード数よりも大きな値を設定した場合，HttpSessionオブジェクト数がセッション情報格納テーブルのレコード数を超過したときの動作は，次のようになります。

完全性保障モードが無効の場合

該当するHTTPセッションは縮退して，リクエスト処理が続行されます。

完全性保障モードが有効の場合

KDJE34380-Eのエラーメッセージがメッセージログに出力され，該当するHTTPセッションは作成されません。

HttpSessionオブジェクト数の上限値の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。
ネゴシエーション処理については，「6.8.1　アプリケーション開始時の処理」を参照してください。
完全性保障モードが無効の場合のHTTPセッションの縮退については，「6.7.1(3)　HTTPセッションの縮退」を参照してください。

HTTPセッションのスティッキー（Sticky）の設定
負荷分散機を使用する環境でデータベースセッションフェイルオーバ機能を使用するには，HTTPセッションのスティッキーを設定する必要があります。
HTTPセッションのスティッキーを設定しない場合，HTTPセッションを保持したリクエストの振り分け先が固定されません。そのため，HTTPセッションを保持したリクエストを受け付けるたびにHTTPセッションの引き継ぎ処理が実施され，性能が劣化するおそれがあります。

ホストの時刻の設定
データベースセッションフェイルオーバ機能を使用するには，システム内のJ2EEサーバが稼働するそれぞれのホストに同じ時刻を設定してください。
データベースに格納するセッション情報には，HTTPセッションの作成時刻や，最終アクセス時刻などの情報が含まれます。各ホストでの設定時刻が異なっている場合，セッション情報に自ホストの設定時刻と異なる情報が含まれます。そのため，セッションの引き継ぎが発生した場合にHTTPセッションの制御に問題が発生するおそれがあります。

デフォルトの実行待ちキュー，Webアプリケーション単位の実行待ちキュー，URLグループ単位の実行待ちキューの設定
Webアプリケーション単位の同時実行スレッド数の制御機能が有効の場合，デフォルトの実行待ちキュー，Webアプリケーション単位の実行待ちキュー，URLグループ単位の実行待ちキューの空きが不足したときに，クライアントに503エラーを返すかどうかを簡易構築定義ファイルのwebserver.dbsfo.thread_control_queue.enabledパラメタに設定します。なお，デフォルトでは，クライアントに503エラーを返します。
クライアントに503エラーを返さない設定にした場合，その実行待ちキューサイズには十分に大きな値を設定してください。
クライアントに503エラーを返す設定にした場合，web.xmlで指定するエラーページで次に示すHTTPセッションの更新をしないでください。

HTTPセッションの作成
WebアプリケーションがHTTPセッションを作成した場合，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出し元に，com.hitachi.software.web.dbsfo.SessionOperationException例外がスローされ，HTTPセッションは作成されません。

HTTPセッションの有効期限の変更（javax.servlet.http.HttpSessionインタフェースのsetMaxInactiveIntervalメソッドの呼び出し）
WebアプリケーションがHTTPセッションの有効期限を変更した場合，データベース上のグローバルセッションの有効期限は変更されません。グローバルセッションの引き継ぎが発生すると，有効期限は変更前の状態に戻ります。

HTTPセッションの属性情報の変更
WebアプリケーションがHTTPセッションの属性情報を変更した場合，データベース上のグローバルセッション情報は変更されません。グローバルセッションの引き継ぎが発生すると，属性情報は変更前の状態に戻ります。

HTTPセッションの無効化（javax.servlet.http.HttpSessionインタフェースのinvalidateメソッドの呼び出し）
Webアプリケーションがjavax.servlet.http.HttpSessionインタフェースのinvalidateメソッドを呼び出した場合，com.hitachi.software.web.dbsfo.SessionOperationException例外がスローされます。

6.4　グローバルセッションを利用したセッション管理（データベースセッションフェイルオーバ機能）

セッションをグローバルセッションとして引き継ぐ場合，HTTPセッションの作成に必要なHTTPセッションの属性情報などを含む，グローバルセッション情報がデータベースに格納されます。

障害発生時には，グローバルセッション情報を基に，ほかのJ2EEサーバでHTTPセッションを再作成し，セッションを引き継げます。

ここでは，グローバルセッション情報およびグローバルセッション情報として引き継げるHTTPセッションの属性について説明します。

＜この節の構成＞

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

6.4.2　グローバルセッション情報として引き継げるHTTPセッションの属性

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

データベースセッションフェイルオーバ機能を使用する場合，グローバルセッション情報は，データベースに作成するセッション情報格納テーブルのレコードに格納されます。HTTPセッションごとに一つのレコードが割り当てられます。

グローバルセッション情報には，次の表に示す情報が含まれます。

表6-7　グローバルセッション情報に含まれる情報

項番 | 冗長化の対象 | 説明
1 | セッションID | グローバルセッション情報を管理するセッションIDです。
2 | HTTPセッションの属性情報 | HTTPセッションに登録された属性および関連づけられたすべての属性について，属性名および属性値のオブジェクトをシリアライズしたバイト配列に変換した情報です。
3 | HTTPセッションの作成時刻 | HTTPセッションが作成された時刻です。グローバルセッションの引き継ぎが発生した場合，引き継ぎ前のHTTPセッションの作成時刻をそのまま使用します。
4 | HTTPセッションの有効期限 | HTTPセッションに設定された有効期限です。
5 | 最終アクセス時刻 | HTTPセッションを使用するリクエストが最後に送信された時刻です。
6 | HTTPセッションの所有J2EEサーバ識別子 | HTTPセッションを作成，または引き継ぎをしたJ2EEサーバのサーバIDです。

6.4.2　グローバルセッション情報として引き継げるHTTPセッションの属性

ここでは，引き継げるHTTPセッションの属性に関する次の項目について説明します。

引き継げるHTTPセッションの属性の条件

引き継ぎ対象としてサポートされるオブジェクト

オブジェクトの内容によるセッション情報の引き継ぎ可否

HTTPセッションの属性引き継ぎ時のシリアライズ処理についての注意事項

HTTPセッションの属性引き継ぎ時のデシリアライズ処理についての注意事項

＜この項の構成＞

(1)　引き継げるHTTPセッションの属性の条件

(2)　引き継ぎ対象としてサポートされるオブジェクト

(3)　オブジェクトの内容によるセッション情報の引き継ぎ可否

(4)　HTTPセッションの属性引き継ぎ時のシリアライズ処理についての注意事項

(5)　HTTPセッションの属性引き継ぎ時のデシリアライズ処理についての注意事項

(1)　引き継げるHTTPセッションの属性の条件

データベースセッションフェイルオーバ機能では，グローバルセッション情報の更新および引き継ぎ処理で，オブジェクトのシリアライズまたはデシリアライズ処理が発生します。そのため，HTTPセッションに登録する属性は，次の条件を満たす必要があります。

java.io.Serializableインタフェースを実装した直列化可能クラスのオブジェクトである。

(2)　引き継ぎ対象としてサポートされるオブジェクト

データベースセッションフェイルオーバ機能では，次に示す直列化可能クラスのオブジェクトを引き継ぎ対象としてサポートしています。

J2EEアプリケーションで提供されるクラスのオブジェクト。

J2SEで提供されるクラスのオブジェクト。

ただし，引き継ぎ処理では，HTTPセッションに登録された直列化可能クラスのオブジェクトが，データベースセッションフェイルオーバ機能でサポートされているオブジェクトかどうかはチェックされません。

(3)　オブジェクトの内容によるセッション情報の引き継ぎ可否

HTTPセッションに登録されたオブジェクトの内容によるセッション情報の引き継ぎ可否を次の表に示します。

表6-8　HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否

項番
HTTPセッションに登録されたオブジェクトの内容
リクエスト処理完了時点の動作
セッション情報の引き継ぎ可否

java.io.Serializableインタフェースの実装の有無
シリアライズの成功/失敗

1
java.io.Serializableインタフェースの実装あり
シリアライズの成功
リクエストが正常に処理されます。
シリアライズ後の情報がデータベースに冗長化されて引き継がれます。

2
シリアライズの失敗
J2EEサーバで，エラーを通知するKDJE34318-Eのメッセージが出力されます。
HTTPセッションに対応するデータベース上のグローバルセッション情報は削除されます。
次回以降のリクエスト処理完了後に，HTTPセッションに登録されたオブジェクトがシリアライズ可能となった時点で，データベース上にグローバルセッション情報が作成されます。
HTTPセッションに格納した場合，シリアライズに失敗した属性を含むHTTPセッションは，グローバルセッション引き継ぎの対象となりません。
エラーが通知される原因となったHTTPセッションに登録されたセッション情報は引き継がれません。

3
java.io.Serializableインタフェースの実装なし
（シリアライズできません）
J2EEサーバでKDJE34317-Wのメッセージが出力されます。
シリアライズできない属性を除いた属性についてグローバルセッション情報が作成されます。
エラーが通知される原因となったHTTPセッションに登録されたセッション情報は引き継がれません。

(4)　HTTPセッションの属性引き継ぎ時のシリアライズ処理についての注意事項

シリアライズ処理についての注意事項を次に示します。

(a)　シリアライズ処理が性能に与える影響

引き継ぎ対象のオブジェクトだけでなく，引き継ぎ対象のオブジェクトから参照されるオブジェクトすべてを対象としてシリアライズ処理が実行されます。このため，引き継ぐ必要がない情報を含むクラスなどをHTTPセッションに登録した場合，性能が低下するおそれがあります。

(b)　java.lang.OutOfMemoryErrorエラーが発生する場合

シリアライズ処理では，一時的に，アプリケーションで設定したHttpSessionオブジェクト数を超えてシリアライズ後のデータが作成されます。そのため，設定したサイズを超える巨大なオブジェクトがHTTPセッションに登録された場合，グローバルセッション情報の作成中にjava.lang.OutOfMemoryErrorエラーが発生することがあります。

(c)　シリアライズに失敗する場合とその対処

次のような場合は，KDJE34337-W，またはKDJE34338-Eのメッセージを出力してシリアライズに失敗します。

HTTPセッションに登録したオブジェクト（直列化可能クラスのオブジェクト）から参照するオブジェクトに，直列化可能クラス以外のクラスを実装したオブジェクトが含まれる場合。

オブジェクトにwriteObject(java.io.OutputStream out)メソッドが実装されており，シリアライズ時に例外が発生する場合。

失敗した場合，グローバルセッション情報の更新，および引き継ぎ処理が実行されません。処理を実行するためには，次のどちらかの対処が必要です。

シリアライズに失敗したオブジェクトのHTTPセッションへの登録を解除する。

シリアライズに失敗したオブジェクトを変更して，シリアライズに失敗した原因を取り除く。

(5)　HTTPセッションの属性引き継ぎ時のデシリアライズ処理についての注意事項

次のような場合は，デシリアライズに失敗します。

デシリアライズに失敗する原因となる変更がWebアプリケーションに加えられ，シリアライズ時とWebアプリケーションが異なっている場合。

オブジェクトにreadObject(java.io.OutputStream out)メソッドが実装されており，デシリアライズ時に例外が発生する場合。

デシリアライズに失敗した場合，グローバルセッション情報およびセッション情報が削除され，KDJE34326-Eが出力されます。セッションの引き継ぎに失敗するため，HTTPセッションがない状態でリクエストが処理されます。

6.5　メモリの見積もり

データベースセッションフェイルオーバ機能を使用する場合，シリアライズ処理で使用するメモリをJavaVMのメモリサイズとして確保する必要があります。また，HTTPセッションの属性情報のサイズをデータベースのディスク容量として確保する必要があります。

ここでは，それぞれの見積もり方法について説明します。

＜この節の構成＞

6.5.1　シリアライズ処理で使用するメモリの見積もり

6.5.2　HTTPセッションの属性情報のサイズの見積もり

6.5.1　シリアライズ処理で使用するメモリの見積もり

データベースセッションフェイルオーバ機能では，リクエスト処理完了時に，HTTPセッションの属性情報のシリアライズのために一時的にメモリが確保されます。このメモリ確保によって必要となるメモリ領域のサイズについて，JavaVMのチューニング時に考慮する必要があります。

チューニングでは，複数スレッドでメモリを確保する処理が重なった場合のメモリの増加量（最大増加量）を見積もります。リクエストの処理時に使用するメモリの最大増加量について，Webアプリケーション単位，およびJ2EEサーバ単位に求める式をそれぞれ次に示します。

Webアプリケーション単位の使用メモリ最大増加量（バイト）＝

最大同時実行スレッド数※1 × HTTPセッションの属性情報の最大サイズ※2

J2EEサーバ単位の使用メモリ最大増加量（バイト）＝

Webアプリケーション単位の使用メモリ最大増加量の合計 ＝

　　Webアプリケーション1の使用メモリ最大増加量

　＋Webアプリケーション2の使用メモリ最大増加量

　　　：

　＋Webアプリケーションｎの使用メモリ最大増加量

注※1

Webアプリケーション単位の同時実行スレッド数を設定している場合はWebアプリケーション単位の最大同時実行スレッド数の値を指します。Webアプリケーション単位の同時実行スレッド数を設定していない場合はWebコンテナ単位の最大同時実行スレッド数の値を指します。

注※2

HTTPセッションの属性情報のサイズ見積もり機能で見積もった値を指します。

上記の式で求めた値を基に，JavaVMのチューニングを実施してください。

6.5.2　HTTPセッションの属性情報のサイズの見積もり

データベースセッションフェイルオーバ機能が使用するデータベースのディスク容量を確保する際，HTTPセッションの属性情報の最大サイズが必要になります。

HTTPセッションの属性情報のサイズをWebアプリケーションの内容から計算して求めることは困難です。そのため，アプリケーションサーバではHTTPセッションの属性情報のサイズ見積もり機能を提供しています。HTTPセッションの属性情報のサイズ見積もり機能を使用すると，実際にアプリケーションを実行し，HTTPセッションに登録した属性のシリアライズ後のサイズ情報をメッセージとして出力できます。

ここでは，HTTPセッションの属性情報のサイズ見積もり機能およびHTTPセッションの属性情報のサイズを求める計算式について説明します。

また，フルガーベージコレクションの抑止をする場合のメモリの確保についても説明します。

＜この項の構成＞

(1)　HTTPセッションの属性情報のサイズの見積もり機能

(2)　HTTPセッションの属性情報のサイズを求める計算式

(3)　フルガーベージコレクションの抑止をする場合のメモリの確保

(1)　HTTPセッションの属性情報のサイズの見積もり機能

HTTPセッションの属性情報のサイズ見積もり機能を使用すると，出力されたサイズ情報を参考にして，HTTPセッションの属性情報の最大サイズに適切な値を見積もることができます。

なお，この機能は見積もり時に使用する機能です。データベースへのグローバルセッションの格納は実施されないため，データベースへの接続は発生しません。

注意

HTTPセッションの属性情報のサイズの見積もり機能は，運用環境で使用しないでください。この機能を使用した場合，データベースセッションフェイルオーバ機能は無効となり，グローバルセッション情報がデータベースに冗長化されません。

(a)　HTTPセッションの属性情報のサイズの見積もり機能を有効にするための設定

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，webserver.dbsfo.check_size.modeパラメタに「on」を指定してください。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

HTTPセッションの属性情報のサイズの見積もり機能を有効にすると，データベースセッションフェイルオーバ機能に関するほかの設定はすべて無効になります。

なお，HTTPセッションの属性情報のサイズの見積もり機能を使用する場合，「6.3.3　前提となる設定」で示しているHttpSessionオブジェクト数の上限値の指定機能およびHTTPセッションのセッションIDを示すHTTP Cookieの削除機能を有効にしなくても動作します。

(b)　HTTPセッションの属性情報のサイズを通知するメッセージ

HTTPセッションの属性情報のサイズ見積もり機能が有効の場合，Webアプリケーションのリクエスト処理完了時にHTTPセッションの属性情報のサイズを通知する次のメッセージがErrorレベルで出力されます。

表6-9　HTTPセッションの属性情報のサイズを通知するメッセージ

メッセージID
内容
サイズの情報に含まれる内容

KDJE34330-I
リクエストごとに作成したHTTPセッションの属性情報のサイズ
HTTPセッションに登録されている属性をシリアライズした結果の合計サイズ（KDJE34331-Iで出力するサイズの合計）※1

KDJE34331-I
シリアライズが完了した属性1個分のサイズ

属性名をシリアライズした結果（バイト配列）のサイズ

属性値をシリアライズした結果（バイト配列）のサイズ

java.io.ObjectOutputStreamクラスが書き込むマジックナンバー※2

java.io.ObjectOutputStreamクラスが書き込むバージョン情報のデータ分のサイズ※2

注※1　HTTPセッションに属性が登録されていない場合，java.io.ObjectOutputStreamクラスが書き込むマジックナンバーおよびjava.io.ObjectOutputStreamクラスが書き込むバージョン情報のデータ分のサイズです。

注※2　最初にシリアライズされた属性のサイズにだけ含まれます。

登録されている属性が「Attribute1」，および「Attribute2」であるHTTPセッションから，HTTPセッションの属性情報を作成した場合のメッセージの出力例を次に示します。

KDJE34331-I An attribute was serialized. (J2EE application = App01, context root = /test, request URL = http://host01/test/TestServlet, attribute name = Attribute1, class name = app.MyObject1, size(bytes) = 36, HTTP session ID = 01234567aaaabbbbccccddddeeeeffff)
KDJE34331-I An attribute was serialized. (J2EE application = App01, context root = /test, request URL = http://host01/test/TestServlet, attribute name = Attribute2, class name = app.MyObject2, size(bytes) = 25, HTTP session ID = 01234567aaaabbbbccccddddeeeeffff)
KDJE34330-I The attribute information was created. (J2EE application = App01, context root = /test, request URL = http://host01/test/TestServlet, size(byte) = 61, HTTP session ID = 01234567aaaabbbbccccddddeeeeffff)

(2)　HTTPセッションの属性情報のサイズを求める計算式

HTTPセッションの属性情報の最大サイズは次の式で求めることができます。

ここでは，一つのHTTPセッションに対し，一つのjava.io.ObjectOutputStreamのオブジェクトを使用してシリアライズしているものとします。

HTTPセッションの属性情報の最大サイズ（バイト）＝

　HTTPセッションに登録されたすべての属性の属性名をシリアライズしたバイト配列のバイト数の合計

＋HTTPセッションに登録されたすべての属性の属性値をシリアライズしたバイト配列のバイト数の合計

また，HTTPセッションにn個のオブジェクトを属性として登録して，登録した属性をそれぞれ属性１～属性nとする場合，HTTPセッションの属性情報の最大サイズは次の式で求めることができます。

HTTPセッションの属性情報の最大サイズ（バイト）＝

　属性1の属性名をシリアライズしたバイト配列のバイト数

＋属性1の属性値をシリアライズしたバイト配列のバイト数

＋属性2の属性名をシリアライズしたバイト配列のバイト数

＋属性2の属性値をシリアライズしたバイト配列のバイト数

　　：（中略）

＋属性ｎの属性名をシリアライズしたバイト配列のバイト数

＋属性ｎの属性値をシリアライズしたバイト配列のバイト数

属性名をシリアライズしたバイト配列のバイト数，および属性値をシリアライズしたバイト配列のバイト数は次の式で求めることができます。

属性名をシリアライズしたバイト配列のバイト数

属性名をシリアライズしたバイト配列のバイト数＝

　属性名の文字数×3×1.2

属性値をシリアライズしたバイト配列のバイト数

属性値をシリアライズしたバイト配列のバイト数＝

　属性値のオブジェクトが持つすべてのフィールドの値のバイト数の合計×1.2

なお，フィールドの値のバイト数は次の式で求めることができます。

Stringオブジェクトの場合：文字数×3

その他のオブジェクトの場合：そのオブジェクトが持つすべてのフィールドの値のバイト数の合計

プリミティブ型の場合：それぞれのプリミティブ型を格納するために必要なバイト数

注意

HTTPセッションの属性情報のサイズを求める計算式で算出できる値は概算です。最終的にHTTPセッションの属性情報の最大値を求める際には，HTTPセッションの属性情報のサイズの見積もり機能を使用してください。

(3)　フルガーベージコレクションの抑止をする場合のメモリの確保

HTTPセッションの属性情報のサイズはシリアライズ後のサイズであるため，HTTPセッションに登録した属性オブジェクトのメモリ上でのサイズとは異なります。そのため，フルガーベージコレクションの抑止で必要となる外部ヒープ領域のメモリサイズの見積もりは別途実施して，適切な値を設定する必要があります。

フルガーベージコレクションの抑止についての詳細は「8.　明示管理ヒープ機能を使用したフルガーベージコレクションの抑止」を参照してください。

6.6　データベースセッションフェイルオーバ機能の抑止

データベースセッションフェイルオーバ機能を抑止する拡張子またはURIを設定すると，指定した拡張子またはURIのリクエストに対してデータベースセッションフェイルオーバ機能の処理が抑止されます。

データベースセッションフェイルオーバ機能を有効にすると，HTTPセッションを取得済みのリクエストを受け付けたときに，データベースのアクセスや，HTTPセッションのシリアライズなどの処理が実施されます。静的コンテンツやHTTPセッションを必要としないコンテンツに対するリクエストであっても，HTTPセッションを取得済みのリクエストと同一のセッションIDが送信された場合には，データベースセッションフェイルオーバ機能が動作してこれらの不要な処理が発生します。

これに対して，データベースセッションフェイルオーバ機能を抑止する拡張子またはURIを設定すると，その拡張子またはURIのリクエストに対してはデータベースセッションフェイルオーバ機能の処理が抑止されるため，不要な処理が発生しません。

データベースセッションフェイルオーバ機能の抑止の有効・無効と実施される処理の違いを次の図に示します。

図6-5　データベースセッションフェイルオーバ機能の抑止の有効・無効と実施される処理の違い

データベースセッションフェイルオーバ機能を抑止しない場合，取得済みのセッションIDが送信されると，静的コンテンツやHTTPセッションを使用しないサーブレット/JSPのときでもグローバルセッション情報を格納するための不要な処理が実施されます。これに対して，データベースセッションフェイルオーバ機能を抑止すると，HTTPセッションを使用しないリクエストの場合にグローバル情報を格納する処理を実施しなくなるため，処理性能が向上します。

なお，性能向上以外の目的でも，データベースセッションフェイルオーバ機能の抑止が必要な場合があります。詳細は，「6.6.2　URIによるデータベースセッションフェイルオーバ機能の抑止」を参照してください。

＜この節の構成＞

6.6.1　拡張子によるデータベースセッションフェイルオーバ機能の抑止

6.6.2　URIによるデータベースセッションフェイルオーバ機能の抑止

6.6.3　注意事項

6.6.1　拡張子によるデータベースセッションフェイルオーバ機能の抑止

ここでは，拡張子によるデータベースセッションフェイルオーバ機能の抑止について説明します。拡張子の指定によって，静的コンテンツへのリクエストに対してセッションフェイルオーバ機能を抑止できます。

デフォルトの設定では，「txt」，「htm」，「html」，「jpg」，「gif」，および「js」が抑止対象の拡張子です。

拡張子によるデータベースセッションフェイルオーバ機能の抑止の有効・無効はJ2EEサーバ単位またはWebアプリケーション単位に設定できます。J2EEサーバ単位の設定については，「6.12　J2EEサーバの設定」，Webアプリケーション単位の設定については「6.10 cosminexus.xmlでの定義」を参照してください。

6.6.2　URIによるデータベースセッションフェイルオーバ機能の抑止

ここでは，URIによるデータベースセッションフェイルオーバ機能の抑止について説明します。データベースセッションフェイルオーバ機能の抑止は，静的コンテンツやHTTPセッションを使用しないコンテンツに対するリクエストの場合に，データベースセッションフェイルオーバ機能を抑止してリクエスト処理性能を向上する目的で使用します。

完全性保障モードが有効の場合のデータベースセッションフェイルオーバ機能では，同一セッションIDのリクエストに対して，排他的に処理を実行します。例えば，PUSH配信をするために常駐するようなサーブレット/JSPなど，長時間処理が終了しないサーブレット/JSPをHTMLのフレームなどの一つから呼び出した場合，そのサーブレット/JSPの処理が終わるまで，同じフレームから送信されるすべてのリクエストは実行されません。これは，一つのフレームから送信されるリクエストはすべて同一のセッションIDを送信するリクエストになるためです。

このような状態を防ぐためには，HTTPセッションを使用していない特定のリクエストに対して，URIによってデータベースセッションフェイルオーバ機能を抑止する必要があります。

URIによるデータベースセッションフェイルオーバ機能の抑止の有効・無効と実施される処理の違いを次の図に示します。なお，図中のリクエスト1およびリクエスト2は，同一のセッションIDを送信するリクエストです。

図6-6　URIによるデータベースセッションフェイルオーバ機能の抑止の有効・無効と実施される処理の違い

URIによるデータベースセッションフェイルオーバ機能の抑止の有効・無効は，J2EEサーバ単位に設定できます。J2EEサーバ単位の設定については，「6.12　J2EEサーバの設定」を参照してください。

6.6.3　注意事項

データベースセッションフェイルオーバ機能の抑止によってデータベースセッションフェイルオーバ機能が無効となったリクエスト処理内で，javax.servlet.http.HttpServletRequestインタフェースのgetSession()メソッドまたはgetSession(boolean create)メソッドを呼び出すと，com.hitachi.software.web.dbsfo.SessionOperationException例外がスローされます。このため，このメソッドを呼び出すリクエストに対しては，データベースセッションフェイルオーバ機能の抑止は適用できません。

com.hitachi.software.web.dbsfo.SessionOperationException例外についての詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「3.1　例外クラス」を参照してください。

データベースセッションフェイルオーバ機能が抑止されたリクエストは，HTTPセッションを使用するリクエストではないため，HTTPセッションのアクセス時刻が更新されません。これによって，次の影響があります。

javax.servlet.http.HttpSessionインタフェースのgetLastAccessedTimeメソッドは，前回HTTPセッションを使用するリクエストが実行された時刻を返します。

現在の時刻とHTTPセッションのアクセス時刻の差がタイムアウト時間を超えた場合，HTTPセッションはタイムアウトします。このため，HTTPセッション作成後に，データベースセッションフェイルオーバ機能が抑止されたリクエストだけを送信し続けると，HTTPセッションのタイムアウトが発生する場合があります。

なお，JSPでは，デフォルトで暗黙的にHTTPセッションが作成されます。このため，HTTPセッションを必要としないJSPに対してデータベースセッションフェイルオーバ機能の抑止を適用する場合は，明示的にpageディレクティブのsession属性を使用してHTTPセッションを作成しない設定にする必要があります。

6.7　性能を重視したモードの選択（完全性保障モードの無効化）

ここでは，性能を重視したモードを選択した場合の動作，使用できる機能，および注意事項について説明します。

性能を重視したモードを選択するには，完全性保障モードの設定を無効にします（デフォルト）。完全性保障モードを無効にすると，同一セッションIDを持つリクエスト処理を同時に実行できるようになります（同一セッションIDの同時実行）。

＜この節の構成＞

6.7.1　完全性保障モード無効時の動作

6.7.2　HTTPセッションの参照専用リクエストの定義

6.7.3　グローバルセッション情報の削除

6.7.4　注意事項

6.7.1　完全性保障モード無効時の動作

ここでは，完全性保障モードが無効の場合の動作について説明します。

＜この項の構成＞

(1)　同一セッションIDの同時実行

(2)　Webアプリケーション開始時のグローバルセッション情報の引き継ぎ

(3)　HTTPセッションの縮退

(1)　同一セッションIDの同時実行

同じセッションIDを持つ複数のリクエストが，冗長化された複数のJ2EEサーバ，または一つのJ2EEサーバに送信された場合に，複数のリクエストを同時に実行します。この機能は完全性保障モードが無効の場合に必ず有効になる機能です。

複数のリクエスト処理を同時に実行するため，グローバルセッション情報のロック，およびロックの解除は行われません。

●注意事項

同一セッションIDの同時実行で複数のリクエスト処理を同時に実行する場合，Webアプリケーションが発行するServlet APIの処理順序は不定となります。

同じHTTPセッションに対して，属性を登録するリクエスト（javax.servlet.http.HttpSessionインタフェースのsetAttributeメソッド）とセッションを無効化するリクエスト（javax.servlet.http.HttpSessionインタフェースのinvalidateメソッド）を同時に送信したり，セッションを無効化するリクエストを二重に送信したりすると，Servlet APIの処理順序によっては，すでに無効化されたHTTPセッションに対して属性の登録や無効化をしてしまう場合があります。この場合，Servlet APIはjava.lang.IllegalStateException例外をスローします。このため，Servlet APIでjava.lang.IllegalStateException例外がスローされることを考慮してWebアプリケーションを実装してください。

(2)　Webアプリケーション開始時のグローバルセッション情報の引き継ぎ

WebアプリケーションやJ2EEサーバを停止した場合，またはJ2EEサーバが障害でプロセスダウンした場合，J2EEサーバ上のHTTPセッションは破棄されます。このときのグローバルセッション情報は，Webアプリケーションを再び開始すると，J2EEサーバ上に自動的に引き継がれます。グローバルセッション情報の引き継ぎ処理の流れを次に示します。

データベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得する。
Webアプリケーションの開始時，データベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得します。

グローバルセッション情報の引き継ぎ処理を実行する。
セッションIDのリストを取得できた場合，KDJE34344-Iのメッセージをメッセージログに出力し，グローバルセッション情報の引き継ぎ処理を開始します。
ネットワーク障害などの理由でデータベースからセッションIDのリストを取得できなかった場合，KDJE34345-Wのエラーメッセージをメッセージログに出力し，Webアプリケーションの開始を中止します。
グローバルセッション情報の引き継ぎ処理では，リストに含まれているセッションIDのグローバルセッション情報を一つずつデータベースからJ2EEサーバ上に引き継ぎます。

引き継ぎ処理を終了する。
セッションIDのリストにあるすべてのグローバルセッション情報の引き継ぎが完了した時点で，KDJE34349-Iのメッセージをメッセージログに出力します。

なお，次の条件の場合，グローバルセッション情報は引き継がれません。

項番 | 条件 | 動作
1 | ネットワーク障害などの理由でデータベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得できなかった場合。 | KDJE34345-Wのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理を終了します。
2 | 引き継ぐグローバルセッション情報が，すでにJ2EEサーバ上に存在する場合（リクエストの受信でJ2EEサーバ上にすでに引き継がれている）。 | KDJE34347-Iのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理はスキップします。
3 | 引き継ぐグローバルセッション情報が，すでに冗長化された別のJ2EEサーバに引き継がれている場合。 | KDJE34348-Iのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理はスキップします。
4 | ネットワーク障害などの理由でデータベースからグローバルセッション情報を取得できなかった場合。 | KDJE34346-Wのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理はスキップします。
5 | J2EEサーバ上のHTTPセッション数が，HttpSessionオブジェクト数の上限値の指定機能で設定した上限値に達したために引き継げなかった場合。 | KDJE34370-Wのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理はスキップします。
6 | グローバルセッション情報のデシリアライズに失敗した場合。 | KDJE34328-Eのメッセージをメッセージログに出力して，グローバルセッション情報を引き継がないで，データベースから削除します。
7 | HttpSessionのサーバID付加機能で設定したサーバIDを変更した場合。 | KDJE34348-Iのメッセージをメッセージログに出力して，グローバルセッション情報の引き継ぎ処理をスキップします。

(3)　HTTPセッションの縮退

データベースで次の障害が発生した場合，処理を中断しないで，J2EEサーバ上のHTTPセッションを使用してリクエスト処理を続行します。これをHTTPセッションの縮退といいます。

グローバルセッション情報の作成時にデータベースに空きレコードがなかった場合

グローバルセッション情報の操作時にデータベース障害が発生した場合

それぞれの障害でHTTPセッションが縮退した場合の動作を次の表に示します。

発生した障害
縮退の動作
縮退時に出力されるメッセージ※
縮退が解除されるタイミング
縮退したHTTPセッションの引き継ぎ

グローバルセッション情報の作成時にデータベースに空きレコードがない。
J2EEサーバ上のHTTPセッションだけを作成する。
KDJE34367-W
以降のHTTPセッションの操作時にデータベースに空きレコードがあり，グローバルセッション情報を作成できた場合。
データベースにグローバルセッション情報が存在しないため，引き継がれない。

グローバルセッション情報の操作時にデータベース障害が発生した。
J2EEサーバ上のHTTPセッションだけを操作する。
KDJE34368-W
以降のHTTPセッションの操作時にデータベースアクセスに成功した場合。

データベースにグローバルセッション情報が存在しない場合：引き継がれない。

データベースにグローバルセッション情報が存在する場合：古いグローバルセッション情報が引き継がれるときがある。

注※　発生した障害ごとに，初めて縮退したときに出力されるメッセージです。それ以降は，縮退したHTTPセッションがすべてなくなってから，再び縮退するまで出力されません。なお，縮退したHTTPセッションがすべてなくなった場合は，メッセージKDJE34369-Iが出力されます。

6.7.2　HTTPセッションの参照専用リクエストの定義

HTTPセッションの参照専用リクエストの定義では，HTTPセッションを更新しないリクエスト（参照専用リクエスト）をURIで設定すると，そのURIのリクエストに対してはHTTPセッションのシリアライズやデータベースアクセスの処理が抑止されます。

なお，HTTPセッションを更新だけでなく参照もしないリクエストの場合は，セッションフェイルオーバ機能の抑止を使用できます。参照専用リクエストとセッションフェイルオーバ機能の抑止の対象リクエストの両方に該当するリクエストの場合，セッションフェイルオーバ機能の抑止の対象リクエストとして処理されます。セッションフェイルオーバ機能の抑止については，「6.6　データベースセッションフェイルオーバ機能の抑止」を参照してください。

HTTPセッションの参照専用リクエストの定義は，J2EEサーバ単位に設定できます。J2EEサーバ単位の設定については，「6.12　J2EEサーバの設定」を参照してください。

●注意事項

HTTPセッションの参照専用リクエストの定義について，注意事項を示します。

参照専用リクエストで，WebアプリケーションがHTTPセッションを無効化するjavax.servlet.http.HttpSessionインタフェースのinvalidateメソッドを呼び出した場合，com.hitachi.software.web.dbsfo.SessionOperationException例外がスローされます。

参照専用リクエストの場合でも，HTTPセッションが存在しない初回のリクエストのときは，HTTPセッションが作成・更新・削除されます。この際，データベース上のグローバルセッション情報も更新されます。
HTTPセッションが存在する2回目以降のリクエストでは，WebアプリケーションがHTTPセッションを更新しても，データベース上のグローバルセッション情報は更新されません。そのため，グローバルセッションの引き継ぎが発生すると，HTTPセッションの属性情報は更新前の状態に戻ります。

参照専用リクエストの処理内で，HTTPセッションの有効期限の変更（javax.servlet.http.HttpSessionインタフェースのsetMaxInactiveIntervalメソッドの呼び出し）をした場合，グローバルセッションの有効期限は変更されません。そのため，グローバルセッションの引き継ぎが発生すると，有効期限は変更前の状態に戻ります。

参照専用リクエストの処理内で，HTTPセッションの属性情報の変更をした場合，グローバルセッション情報は変更されません。そのため，グローバルセッションの引き継ぎが発生すると，HTTPセッションの属性情報は変更前の状態に戻ります。なお，属性情報の変更とは次のことを指します。

javax.servlet.http.HttpSessionインタフェースのsetAttributeメソッドまたはputValueメソッドで，HTTPセッションに新しい属性情報を登録する，または登録済みのセッション属性を置き換える。

javax.servlet.http.HttpSessionインタフェースのremoveAttributeメソッドまたはremoveValueメソッドで，HTTPセッションに登録済みの属性情報を削除する。

HTTPセッションに登録済みの属性情報の内容を変更する。
セッションの属性情報の内容を変更する場合の例を次に示します。

java.util.Hashtable table = (java.util.Hashtable)session.getAttribute("attr1");
table.put("key1", "value1");

この例では，sessionはHttpSessionオブジェクトを格納した変数です。java.util.Hashtableオブジェクトは，別のリクエストで「attr1」という名前でHttpSessionオブジェクトにセッションの属性情報として登録済みとします。

6.7.3　グローバルセッション情報の削除

グローバルセッション情報の有効期限監視は，J2EEサーバ上のHTTPセッションを監視することで実施されます。有効期限の監視下では，有効期限が切れたHTTPセッションについて，データベース上のグローバルセッション情報が削除されます。しかし，J2EEサーバに障害が発生して停止した場合，そのJ2EEサーバで使用されていたグローバルセッション情報は，ほかのJ2EEサーバに引き継がれるか，そのJ2EEサーバが再起動されるまで有効期限の監視が行われません。有効期限の監視が行われない状態が長く続くと，有効期限が過ぎても削除されないグローバルセッション情報が，セッション情報格納テーブルのレコードを使用し続けることになります。

このため，データベース上に残ったグローバルセッション情報を適宜削除する必要があります。

ここでは，グローバルセッション情報をコマンドによって削除する方法について説明します。

●グローバルセッション情報の削除方法

グローバルセッション情報を削除するには，cjclearsessionコマンドを使用します。J2EEサーバまたはWebアプリケーションが停止してから，HTTPセッションの有効期限以上の時間が経過したあとに，J2EEサーバまたはWebアプリケーションが再起動する前にコマンドを実行します。

Webアプリケーション内で，Sevlet APIを使用してHTTPセッションごとに有効期限を設定している場合は，最も長い有効期限に合わせてコマンドを実行してください。

グローバルセッション情報を削除する手順を次に示します。

環境変数CLASSPATHに，使用するJDBCドライバのパスを設定する。
cjclearsessionコマンドを初めて使用する場合，環境変数CLASSPATHに使用するJDBCドライバのパスを指定します。

cjclearsessionコマンドを実行して，グローバルセッション情報を削除する。
コマンドにアプリケーション識別子，サーバID，使用するJDBCドライバの情報，およびデータベースアクセスに必要な情報を指定して実行します。アプリケーション識別子で指定したWebアプリケーションの，サーバIDで指定したJ2EEサーバが所有するグローバルセッション情報がすべて削除されます。

必要に応じて，J2EEサーバまたはWebアプリケーションを再起動する。

なお，cjclearsessionコマンドに-countオプションを指定して実行すると，J2EEサーバが所有するグローバルセッション情報数を表示できます。

データベースへの接続試行のタイムアウト，データベースのグローバルセッション情報の取得または削除するSQLの実行タイムアウトは8秒です。

コマンド実行中にデータベースアクセスでエラーが発生した場合，エラーが発生した時点でコマンドの実行を中止します。

cjclearsessionコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjclearsession（グローバルセッション情報の削除）」を参照してください。

●注意事項

グローバルセッション情報の削除についての注意事項を示します。

削除するHTTPセッションを所有するJ2EEサーバが稼働中の場合の削除
J2EEサーバが稼働中の場合，リクエスト処理が行われてグローバルセッション情報が新たに作成されることがあります。このため，削除対象とするHTTPセッションを所有するJ2EEサーバが稼働中の場合は，グローバルセッションの有効期限が切れる前に削除される可能性があります。グローバルセッション情報を削除する場合は，削除対象とするHTTPセッションを所有するJ2EEサーバを停止してからコマンドを実行してください。

有効期限前の削除
グローバルセッションの有効期限が切れる前にcjclearsessionコマンドを実行してグローバルセッション情報の削除をした場合，次の動作になります。

項番 | 完全性保障モード | J2EEサーバ上のHTTPセッションの有無 | 動作
1 | 無効 | なし | グローバルセッションの引き継ぎができません。
2 | あり | 削除されたグローバルセッション情報は，以降，データベース上に保存されない状態となり，J2EEサーバ上のHTTPセッションだけでWebアプリケーションが動作します。

完全性保障モードが有効の場合の削除
完全性保障モードが有効の場合，動作は保障されません。

Oracle JDBC Thin Driverを使用する場合
cjclearsessionコマンドは，JDBCドライバのsetQueryTimeoutメソッドを使用してSQL実行時のタイムアウトを実現しています。Oracle JDBC Thin Driverを使用してOracleに接続する場合，setQueryTimeoutメソッドは，MTS接続では有効に働きますが，専用接続では制限があり正常にタイムアウトしないことがあります。
詳細はオラクルのサポート情報を参照してください。

6.7.4　注意事項

ここでは，完全性保障モード無効時の注意事項について説明します。

●完全性保障モードの切り替え

完全性保障モードを無効から有効に切り替える場合は，次の手順に従って，データベースのセッション情報格納テーブルとアプリケーション情報テーブルを初期化してください。

冗長化したJ2EEサーバをすべて停止する。

HTTPセッションを破棄する。
HTTPセッションの破棄の手順については，「6.15.3　グローバルセッション情報の削除（HTTPセッションの破棄）を参照してください。

データベースに保存した設定情報を初期化する。
データベースに保存した設定情報を初期化する手順については，「6.15.2　データベーステーブルの初期化」を参照してください。

●J2EEサーバ停止時のグローバルセッション情報の有効期限監視

WebアプリケーションまたはJ2EEサーバを停止したときや，J2EEサーバに障害が発生してプロセスダウンしたとき，グローバルセッション情報の有効期限は監視されません。Webアプリケーションの開始，またはリクエストの受信でグローバルセッション情報がJ2EEサーバに引き継がれた時点から，有効期限の監視が開始されます。

なお，完全性保障モードが有効の場合，J2EEサーバが停止したときは別のJ2EEサーバによって有効期限が監視されます。有効期限監視の処理の詳細については，「6.8.3　グローバルセッション情報の有効期限が切れた場合の処理」を参照してください。

●グローバルセッション情報の数が上限に達した場合の動作

グローバルセッション情報作成時に，データベース上のグローバルセッション情報の数が上限に達していた場合，HTTPセッションを縮退します。HTTPセッションの縮退については，「6.7.1(3)　HTTPセッションの縮退」を参照してください。

6.8　データベースセッションフェイルオーバ機能で実施される処理

データベースセッションフェイルオーバ機能では，次に示す時点でそれぞれ処理が実施されます。

アプリケーション開始時
アプリケーションのネゴシエーション処理が実施されます。

リクエスト実行時
グローバルセッション情報の格納，更新，削除が実施されます。

この節では，データベースセッションフェイルオーバ機能で実施される処理について説明します。

また，グローバルセッション情報の有効期限が切れた場合の処理，データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ，完全性保障モードの場合にだけ実施されるグローバルセッション情報のロック処理，およびグローバルセッション情報操作中の障害発生時の動作についても説明します。

＜この節の構成＞

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

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

6.8.3　グローバルセッション情報の有効期限が切れた場合の処理

6.8.4　データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ

6.8.5　グローバルセッション情報のロック（完全性保障モードが有効の場合）

6.8.6　グローバルセッション情報操作中の障害発生時の動作

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

ここでは，アプリケーション開始時に実施されるアプリケーションのネゴシエーション処理，およびアプリケーションのネゴシエーション処理で使用するアプリケーション識別子について説明します。

＜この項の構成＞

(1)　アプリケーションのネゴシエーション処理

(2)　アプリケーション識別子

(1)　アプリケーションのネゴシエーション処理

データベースセッションフェイルオーバ機能を使用するWebアプリケーションでは，アプリケーション開始時にネゴシエーション処理が実行されます。

ネゴシエーション処理では，次の内容が確認されます。

Webアプリケーションが一致していること

各Webアプリケーションの設定が一致していること

J2EEサーバの設定が一致していること

データベースの設定が正しいこと

ネゴシエーション処理の結果によってWebアプリケーションが開始されるかどうかが決まります。

ネゴシエーション処理の結果とWebアプリケーションの状態の関係を次の表に示します。

表6-10　ネゴシエーション処理の結果とWebアプリケーションの状態の関係

ネゴシエーション処理の結果 | Webアプリケーションの状態 | ネゴシエーションの失敗の要因 | 出力されるメッセージ
成功（確認内容に問題なし） | 開始される | － | KDJE34306-I
失敗（確認内容に問題あり） | 開始されない | Webアプリケーションが一致していない。 | KDJE34340-E
開始されない※ | Webアプリケーションの設定が一致していない。 | KDJE34307-E
開始される※ | KDJE34358-I
開始されない | J2EEサーバの設定が一致していない。 | KDJE34307-E
開始されない | 必要なテーブルがデータベースに存在していない。 | KDJE34308-W
開始されない | 存在するテーブルの内容がデータベースセッションフェイルオーバ機能用のテーブルの内容ではない。 | KDJE34309-E
開始されない | 存在するテーブルがほかのアプリケーションで使用されている。 | KDJE34340-E

（凡例）－：該当なし

注※　次の確認項目について，開始するWebアプリケーションと，その他のJ2EEサーバ上の同一Webアプリケーションとで異なる値が設定されていた場合，Webアプリケーションの開始処理を続行するか中止するかを，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグにwebserver.dbsfo.negotiation.high_levelパラメタを指定することで選択できます。

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

DD（web.xml）に定義されたHTTPセッションの有効期間

これ以外の確認項目について一致していない場合は，Webアプリケーションは開始されません。

なお，Webアプリケーションの開始処理を中止する設定にした場合，HttpSessionオブジェクト数の上限値に1以上の有効な値を必ず設定してください。

ネゴシエーションの処理中にデータベースアクセスでエラーが発生した場合，KDJE34312-Wのメッセージがメッセージログに出力されます。

(a)　ネゴシエーションで確認される内容

ネゴシエーションで確認される内容の詳細について説明します。

Webアプリケーションが一致していること
確認項目がすべて一致することで，Webアプリケーションが一致していると判断されます。確認項目を次の表に示します。

表6-11　Webアプリケーションの一致の確認のために使用される項目

項番 | 確認項目
1 | アプリケーション識別子※
2 | J2EEアプリケーション名
3 | Webアプリケーション名（コンテキストルート名）

注※　アプリケーション識別子については，「(2)　アプリケーション識別子」を参照してください。

各Webアプリケーションの設定が一致していること
次の表に示す確認項目について，冗長化した各Webアプリケーションの設定が一致しているか確認されます。

表6-12　各Webアプリケーションの設定の一致を確認するための項目

項番 | 確認項目
1 | HttpSessionオブジェクト数の上限値
2 | グローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズ
3 | DD（web.xml）に定義されたHTTPセッションの有効期間
4 | データベースセッションフェイルオーバ機能を抑止する拡張子

J2EEサーバの設定が一致していること
次の表に示す確認項目について，冗長化した各J2EEサーバの設定が一致しているか確認されます。

表6-13　各J2EEサーバの設定の一致を確認するための項目

項番 | 確認項目
1 | 完全性保障モードの設定
2 | 参照専用リクエストの設定
3 | 同時実行スレッド数制御機能を使用する場合の実行待ちキュー不足時の設定
4 | データベースセッションフェイルオーバ機能の抑止対象リクエスト内での，getSessionメソッド実行時の例外の設定

データベースの設定が正しいこと
次の表に示す条件を満たしているかが確認されます。

表6-14　データベースの設定が正しいことを確認するための条件

項番 | 条件
1 | 必要なテーブルがデータベースに存在すること。
2 | 存在するテーブルの内容がデータベースセッションフェイルオーバ機能用のテーブルの内容であること。
3 | 存在するテーブルがほかのアプリケーションで使用中でないこと。

(b)　ネゴシエーションで確認されるWebアプリケーションの設定内容

最初にネゴシエーション処理に成功したWebアプリケーションの設定内容は，データベースのアプリケーション情報テーブルに保存されます。保存された設定内容はネゴシエーションの確認で使用される，正しい設定情報として扱われます。

このため，Webアプリケーションの設定内容を変更する場合は，すでにデータベースに保存されている，変更対象のWebアプリケーションに関連する設定情報を削除する必要があります。設定の変更手順については，「6.15　データベースセッションフェイルオーバ機能に関する設定の変更」を参照してください。

(2)　アプリケーション識別子

アプリケーション識別子とは，データベースセッションフェイルオーバ機能使用時にクラスタリングされたWebアプリケーションを認識するための名称です。デフォルトの設定では，システムによって自動的に生成されます。

アプリケーション識別子は，ネゴシエーションでWebアプリケーションが一致しているかどうかの確認に使用されます。そのため，次の条件を満たしている必要があります。

冗長化したJ2EEサーバで動作する同一のWebアプリケーションで一致している。

システム内で一意の値である。

システムによって自動的に生成されるアプリケーション識別子が条件を満たさない場合，条件を満たす値を定義する必要があります。定義方法については「6.10　cosminexus.xmlでの定義」を参照してください。

アプリケーション識別子の自動生成規則，および自動生成されるアプリケーション識別子の例について説明します。

注意

異なるWebアプリケーションに同じアプリケーション識別子が設定されている場合，二つ目のWebアプリケーション開始時にネゴシエーションに失敗して，Webアプリケーションが開始されません。

(a)　アプリケーション識別子の自動生成規則

デフォルトの設定では，アプリケーション識別子にはコンテキストルート名を基にした文字列が自動的に設定されます。アプリケーション識別子が自動的に生成された場合，Webアプリケーション開始時に，適用した値がKDJE34302-Iのメッセージでメッセージログに出力されます。

コンテキストルート名を基にしたアプリケーション識別子の自動生成には，次に示す規則が適用されます。

先頭のスラッシュ（/）は削除する。

先頭のスラッシュ（/）を除き，文字列長が16文字を超える場合，16文字までの文字列を使用する。

アプリケーション識別子に使用できない文字をコンテキストルート名で使用している場合，アンダースコア（_）に置換する。
アプリケーション識別子に使用できる文字は英数字（A～Z，a～z，0～9），およびアンダースコア（_）だけです。

ルートコンテキストの場合，空文字列ではなく，「ROOT」とする。

自動生成規則を適用した結果，アプリケーション識別子がシステム内で一意でなくなる場合があります。この場合，同じアプリケーション識別子が設定されている二つ目のWebアプリケーション開始時にネゴシエーションに失敗して，Webアプリケーションが開始されません。そのため，Webアプリケーションに対してシステム内で一意になるアプリケーション識別子を設定する必要があります。

(b)　自動生成されるアプリケーション識別子の例

コンテキストルート名から自動生成されるデフォルトのアプリケーション識別子の例を次の表に示します。

表6-15　自動生成されるデフォルトのアプリケーション識別子の例

項番
コンテキストルート名
アプリケーション識別子
作成時に適用されるルール

1
/examples
examples
先頭の"/"を削除する

2
/App01/test1
App01_test1

先頭の"/"を削除する

途中の"/"を"_"に置換する

3
/WebApplication_001
WebApplication_0

先頭の"/"を削除する

17文字以降を削除する

4
/examples/WebApplication
examples_WebAppl

先頭の"/"を削除する

途中の"/"を"_"に置換する

17文字以降を削除する

5
/
ROOT
ルートコンテキストのため"ROOT"とする

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

ここでは，リクエスト実行時のグローバルセッションの作成，更新，削除およびグローバルセッションの引き継ぎについて説明します。また，グローバルセッション情報の有効期限が切れた場合の処理，およびグローバルセッション情報操作中の障害発生時の動作についても説明します。

Webアプリケーション内で処理が実行されると，処理の延長でグローバルセッション情報に対しての処理が発生します。Webアプリケーション内で実行される処理の例と，例に対応したリクエスト実行時のグローバルセッション情報に対して実行される処理，および参照先を次の表に示します。

表6-16　Webアプリケーション内での処理の例とグローバルセッション情報に対して実行される処理の対応

項番
Webアプリケーション内で実行される処理の例
グローバルセッション情報に対して実行される処理
参照先

1
ログイン
グローバルセッション情報の作成
(1)

2
業務の実行（ページ遷移/更新）
グローバルセッション情報の更新
(2)

3
ログアウト
グローバルセッション情報の削除
(3)

4
タイムアウトによるログアウト
有効期限切れによるグローバルセッション情報の削除
6.8.3

5
別のJ2EEサーバにグローバルセッションを引き継いでの業務の実行
（J2EEサーバでの障害発生時）
グローバルセッション情報を使用したセッション情報の引き継ぎ
(4)

グローバルセッション情報操作中に障害が発生した場合の処理結果については，「6.8.6　グローバルセッション情報操作中の障害発生時の動作」を参照してください。

＜この項の構成＞

(1)　グローバルセッション情報の作成

(2)　グローバルセッション情報の更新

(3)　グローバルセッション情報の削除

(4)　グローバルセッション情報を使用したセッション情報の引き継ぎ

(1)　グローバルセッション情報の作成

J2EEサーバ上で新規にHTTPセッションが作成されると，データベース上にグローバルセッション情報が作成されます。

グローバルセッション情報の作成で実行される処理について説明します。

HTTPセッションが必要なリクエストを受け付けると，新規にHTTPセッションが作成されます。HTTPセッションの作成のタイミングは，Webアプリケーション内で，javax.servlet.http.HttpServletRequestインタフェースのgetSession()メソッド，またはgetSession(true)メソッドを使用してHttpSessionオブジェクトを新規に取得したときです。
次のような場合もHttpSessionオブジェクトが作成されるため，新規にHTTPセッションが作成されます。

Form認証を使用した場合

JSPでpageディレクティブのsession属性にtrueを指定した場合

JSPでpageディレクティブのsession属性の指定を省略した場合

HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報が作成されます。作成されたグローバルセッション情報は，セッション情報格納テーブルに格納されます。
グローバルセッション情報は，作成と同時にロックされます。

グローバルセッション情報の作成に伴って，空きレコード情報が更新されます。

作成されたグローバルセッション情報は一度コミットされます。
完全性保障モードが有効の場合，改めてロックが取得されます。これは，HTTPセッション作成後に，Webアプリケーション実行中のJ2EEサーバ，またはデータベースの障害発生によって，セッション情報格納テーブルと空きレコード情報テーブルの間で不整合を発生させないためです。

Webアプリケーションでの処理が終了すると，HTTPセッションが更新されます。

HTTPセッションの更新処理の延長で，グローバルセッション情報が更新されます。完全性保障モードが有効の場合，更新が完了すると，ロックが解除されます。

注意

グローバルセッション情報の数が上限に達していた場合の動作

グローバルセッション情報作成時に，データベース上のグローバルセッション情報の数が上限に達していた場合，HTTPセッションを縮退します。HTTPセッションの縮退については，「6.7.1(3)　HTTPセッションの縮退」を参照してください。

完全性保障モードが有効の場合にデータベース上のグローバルセッション情報の数が上限に達していたときは，java.lang.IllegalStateException例外がスローされ，HTTPセッションの取得に失敗します。

また，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグでwebserver.session.max.throwHttpSessionLimitExceededExceptionパラメタにtrueが設定された場合，java.lang.IllegalStateException例外の代わりにcom.hitachi.software.web.session.HttpSessionLimitExceededException例外がスローされます。HttpSessionLimitExceededException例外については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「3.1　例外クラス」を参照してください。

(2)　グローバルセッション情報の更新

Webアプリケーション実行中にセッションが更新されると，J2EEサーバでHTTPセッションが更新されます。それに伴って，データベース上のグローバルセッション情報も更新されます。

グローバルセッション情報の更新で実行される処理について説明します。

HTTPセッションが存在するリクエストを受信します。
完全性保障モードが有効の場合，Webアプリケーション実行前にデータベース上のグローバルセッション情報がロックされます。

Webアプリケーションでのセッションの更新に伴って，HTTPセッションが更新されます。

HTTPセッションの更新によって，データベース上のグローバルセッション情報が最新の情報に更新されます。
完全性保障モードが有効の場合，ロックが解除されます。

グローバルセッション情報のロック時の動作については，「6.8.5(1)　ロック取得時のロック取得処理の呼び出し結果」を参照してください。

(3)　グローバルセッション情報の削除

Webアプリケーション内でのセッションの削除処理で，javax.servlet.http.HttpSessionインタフェースのinvalidate()メソッドを実装して明示的にHTTPセッションを削除すると，その処理の延長でデータベース上のグローバルセッション情報が削除されます。

グローバルセッション情報の削除で実行される処理について説明します。

HTTPセッションの削除が必要なリクエストを受信します。
完全性保障モードが有効の場合，Webアプリケーション実行前にデータベース上のグローバルセッション情報がロックされます。

Webアプリケーションでのセッションの削除に伴って，HTTPセッションが削除されます。

HTTPセッションの削除によって，データベース上のグローバルセッション情報および空きレコード情報が削除されます。
完全性保障モードが有効の場合，ロックが解除されます。

(4)　グローバルセッション情報を使用したセッション情報の引き継ぎ

受信したリクエストに関連づけられたHTTPセッションがJ2EEサーバ上に存在しない場合，データベース上のグローバルセッション情報を使用してHTTPセッションが再作成されます。これによってセッションが引き継げます。

グローバルセッション情報を使用したセッション情報の引き継ぎで実行される処理について説明します。

受信したリクエストに関連づけられたHTTPセッションがJ2EEサーバ上に存在しない場合，データベース上のグローバルセッション情報を呼び出して，J2EEサーバ上にHTTPセッションが再作成されます。
再作成されたHTTPセッションによってセッションが引き継がれ，Webアプリケーションでセッションの更新処理が実行されます。セッションの更新処理の延長上で，HTTPセッションが更新されます

HTTPセッションの更新に伴って，グローバルセッション情報が更新されます。

なお，グローバルセッション情報の引き継ぎができた場合，KDJE34321-Iのメッセージがメッセージログに出力されます。クライアントから受信したセッションIDに対応するグローバルセッション情報がデータベース上に存在しないためにグローバルセッション情報の引き継ぎができなかった場合，KDJE34325-Wのメッセージがメッセージログに出力されます。

6.8.3　グローバルセッション情報の有効期限が切れた場合の処理

HTTPセッションにはそれぞれ有効期限が設定されています。最終アクセス時刻の情報を基にした有効期限確認の結果，有効期限を超過しているHTTPセッションは削除されます。HTTPセッションが有効期限の超過によって削除されると，その処理の延長で，対応するグローバルセッション情報も削除されます。

HTTPセッションの有効期限は，Webコンテナに存在する有効期限監視スレッドによって定期的に監視されています。有効期限監視スレッドはWebアプリケーションごとに存在しています。

有効期限切れによるグローバルセッション情報の削除で実行される処理について説明します。

完全性保障モードが有効の場合，有効期限監視スレッドによって有効期限切れであると判断されたセッションについて，対応するグローバルセッション情報がロックされます。

セッションの削除処理の延長で，HTTPセッションが削除されます。また，HTTPセッションの削除によって，データベース上のグローバルセッション情報および空きレコード情報が削除されます。
完全性保障モードが有効の場合，ロックが解除されます。

6.8.4　データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ

データベースセッションフェイルオーバ機能を使用する場合，グローバルセッションの引き継ぎが発生したタイミングでjavax.servlet.http.HttpSessionActivationListenerインタフェースのsessionDidActivate()メソッドが呼び出されます。また，このときjavax.servlet.http.HttpSessionListenerインタフェースのsessionCreated()メソッドは呼び出されません。

HTTPセッションを使用する処理では，Java EEで規定されたイベントに対応してHTTPセッションに関連するリスナが動作します。HTTPセッションに関連するリスナとは，次のインタフェースを実装したクラスです。

javax.servlet.http.HttpSessionListener

javax.servlet.http.HttpSessionActivationListener

javax.servlet.http.HttpSessionAttributeListener

javax.servlet.http.HttpSessionBindingListener

データベースセッションフェイルオーバ機能を使用する場合，HTTPセッションに関連するリスナはデータベースセッションフェイルオーバ機能のイベントを契機として動作します。

Java EEで規定されたイベントとデータベースセッションフェイルオーバ機能で発生するイベントの対応，およびイベントを契機として動作するリスナについて次の表に示します。

表6-17　データベースセッションフェイルオーバ機能で発生するイベントと動作するリスナ

項番
Java EEで規定されたイベント
対応するイベント（データベースセッションフェイルオーバ機能使用時）
動作するリスナ

1
HTTPセッション作成
HTTPセッション作成
javax.servlet.http.HttpSessionListenerインタフェースのsessionCreated()メソッド

2
HTTPセッション無効化

HTTPセッション無効化

Webアプリケーション停止

javax.servlet.http.HttpSessionListenerインタフェースのsessionDestroyed()メソッド

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド※

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド※

3
HTTPセッションの属性追加
HTTPセッションの属性追加

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeAdded()メソッド

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueBound()メソッド

4
HTTPセッションの属性変更
HTTPセッションの属性変更
javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeReplaced()メソッド

5
HTTPセッションの属性削除

HTTPセッションの属性削除

Webアプリケーション停止

javax.servlet.http.HttpSessionAttributeListenerインタフェースのattributeRemoved()メソッド

javax.servlet.http.HttpSessionBindingListenerインタフェースのvalueUnbound()メソッド

6
セッションの活性化
グローバルセッションの引き継ぎ
javax.servlet.http.HttpSessionActivationListenerインタフェースのsessionDidActivate()メソッド

7
セッションの非活性化
（対応するイベントなし）
（動作するリスナなし）

注※　イベント発生時に属性が追加されていた場合です。

このほかのリスナの動作については，データベースセッションフェイルオーバ機能を使用しない場合と同じです。

6.8.5　グローバルセッション情報のロック（完全性保障モードが有効の場合）

ここでは，完全性保障モードが有効の場合にだけ実行されるグローバルセッション情報のロックについて説明します。完全性保障モードが無効の場合は実施されません。

J2EEサーバを冗長化したシステムでは，異なるJ2EEサーバに対して，同じセッションIDを持つリクエストが同時に送信される場合があります。例えば，フレーム構造のページや，複数の画像（imageタグ）を含むページなどへのアクセスが発生した場合，ブラウザの機能によってマルチスレッドでサーバに対してリクエストが送信されます。

異なるJ2EEサーバで同じグローバルセッションの情報が更新されると，グローバルセッション情報の完全性が失われてしまいます。そのため，データベースセッションフェイルオーバ機能では，ほかのサーバで使用できないように，更新中のグローバルセッション情報が格納されているレコードの排他を取得し，制御します。この排他の取得処理をグローバルセッション情報のロックと呼びます。また，排他を解除する処理をロックの解除と呼びます。

レコードの排他によるグローバルセッション情報のロックについて，次の図に示します。

図6-7　レコードの排他によるグローバルセッション情報のロック

レコードの排他によるグローバルセッション情報のロックで実行される処理について説明します。項番は図中の番号に対応しています。

クライアントからリクエストを受け取ると，データベース上のグローバルセッション情報がロックされます。

ロック後に，Webアプリケーションの処理が実行されます。

Webアプリケーションの処理が完了すると，グローバルセッション情報のロックが解除されます。

このように，Webアプリケーションの動作中，データベース上のグローバルセッション情報はロックされているため，システム内で同じセッションIDを持つリクエストが同時に処理されないことが保証されます。

J2EEサーバにリクエストが送信された場合，Webアプリケーション内でHTTPセッションを使用するかどうかに関係なく，グローバルセッション情報がロックされます。ただし，次のリクエストに対しては，グローバルセッション情報はロックされません。

HTTPセッションが作成されていないリクエスト

データベースセッションフェイルオーバ機能を抑止された拡張子またはURIを含むURLを持つリクエスト
デフォルトの設定では，「txt」，「htm」，「html」，「jpg」，「gif」，および「js」が抑止対象の拡張子です。デフォルトの設定で，抑止対象となるURIはありません。データベースセッションフェイルオーバ機能の抑止については，「6.6　データベースセッションフェイルオーバ機能の抑止」を参照してください。

データベースセッションフェイルオーバ機能では，異なるJ2EEサーバではなく，一つのJ2EEサーバに対して送信されるスレッド間でもグローバルセッションのロックは有効です。セッションIDが同一である複数のリクエストが一つのJ2EEサーバに送信された場合，受信したリクエストから順に一つずつ処理されます。あとで受信したリクエストは，先に受信したリクエストの処理が終わるのを待ってから，処理を開始します。

注意

フレームなどを使用した，HTTPセッションを使用する複数の動的ページを組み合わせたコンテンツの更新などによって，WebクライアントからセッションIDが同一である複数のリクエストが送信される場合があります。この場合，受信したリクエストから順に一つずつ処理されます。その結果，データベースセッションフェイルオーバ機能を使用しない場合に比べ，処理性能が低下するおそれがあります。

＜この項の構成＞

(1)　ロック取得時のロック取得処理の呼び出し結果

(2)　ロック待ち

(3)　J2EEサーバでの障害発生時のグローバルセッション情報のロック

(1)　ロック取得時のロック取得処理の呼び出し結果

データベース上のグローバルセッション情報の状態によってロック取得処理の呼び出し結果が異なります。グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係を次の表に示します。

表6-18　グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番
データベース上のグローバルセッション情報の状態
ロック取得処理の呼び出し結果
出力されるメッセージ

1
存在し，ロック中ではない（正常時）。
データベース上のグローバルセッション情報がロックされます（正常終了）。
出力されない

2
存在しない。
タイムアウトで無効化したセッション，または無効なセッションIDのセッションを対象にしていると判断されます。そのため，J2EEサーバ内のHTTPセッションが削除されます。
その結果，Webアプリケーションは，HTTPセッションが存在しない状態で実行されます。
KDJE34315-W

3
存在するが，ほかのJ2EEサーバで更新され，J2EEサーバ内のHTTPセッションの情報よりも新しい。
ほかのJ2EEサーバで使用されたグローバルセッション情報であると判断されます。そのため，データベース上のグローバルセッション情報の内容が引き継がれます（セッションの引き継ぎ※1発生）。
KDJE34322-I※2

4
存在し，使用されているためロック中である。
ロック待ち※3が発生します。HTTPセッション使用中のリクエストの処理が終了したあとでロックが取得され，Webアプリケーションが開始されます。
出力されない

注※1

セッションの引き継ぎについては「6.8.2(4)　グローバルセッション情報を使用したセッション情報の引き継ぎ」を参照してください。

注※2

Warningレベルで出力されます。

注※3

ロック待ちについては「(2)　ロック待ち」を参照してください。

(2)　ロック待ち

ロック対象となっているグローバルセッション中のHTTPセッションを使用するリクエストを受信すると，ロックの取得を待つ必要があります。ロックの取得を待っている状態を，グローバルセッション情報のロック待ちといいます。また，ロック待ちが原因で発生するタイムアウトのことを，ロックタイムアウトといいます。

ロック待ち発生後のグローバルセッション情報の状態と，ロック取得処理の呼び出し結果の関係を次の表に示します。

表6-19　ロック待ち発生後のグローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番 | ロック待ち発生後のグローバルセッション情報の状態 | ロック待ち発生後のロック取得処理の呼び出し結果 | 出力されるメッセージ
1 | 先にセッションを使用していたリクエスト処理が終了し，ロックが解除された。 | データベースのグローバルセッション情報がロックされます（正常終了）。 | 出力されない
2 | タイムアウト時間を経過したが，ロックは解除されなかった（ロックタイムアウトの発生）※1。 | Webアプリケーション内でセッション取得処理が実行されると，com.hitachi.software.web.dbsfo.DatabaseAccessException※2例外がスローされます。 | KDJE34312-W
3 | ロック待ちの間にデータベースで障害が発生し，ロックは解除されなかった（ロックタイムアウトの発生）。 | Webアプリケーション内でセッション取得処理が実行されると，com.hitachi.software.web.dbsfo.DatabaseAccessException※2例外がスローされます。 | KDJE34312-W

注※1

ロックをするためのSQLをデータベースに送信し，通信路の障害などによってタイムアウトが発生した場合もこの状態に含まれます。

注※2

DatabaseAccessExceptionクラスは，java.lang.IllegalStateExceptionクラスを継承したクラスです。DatabaseAccessExceptionクラスの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「3.1　例外クラス」を参照してください。

(3)　J2EEサーバでの障害発生時のグローバルセッション情報のロック

Webアプリケーション実行中のJ2EEサーバで，OSのハングアップやネットワークの障害などが発生すると，データベース上でロック中のグローバルセッション情報が一時的にロックされたままの状態となる場合があります。

ロックされたままの状態から回復するには，次のどちらかの対処が必要です。

データベースに，クライアントからの接続を監視する設定，および接続の切断を検知して回復する設定をする。
この設定をすると，データベースの機能によって一定時間後にJ2EEサーバからの接続の切断が検知され，自動的にロックが解除されます。さらに，切断が検知されたタイミングで，ロック取得前の状態に戻ります。HiRDBを使用する場合，UAP処理時間監視機能を設定してください。UAP処理時間監視機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

データベースの定期的なメンテナンスをする。

データベースの設定，運用については使用するデータベースのマニュアルを参照してください。

6.8.6　グローバルセッション情報操作中の障害発生時の動作

グローバルセッション情報の操作中の障害発生時の動作について説明します。ここでは，グローバルセッション情報の操作ごとに，障害が発生したポイント，セッションの状態，他のリクエストへの影響，および出力されるメッセージについて説明します。

＜この項の構成＞

(1)　グローバルセッション情報の作成時に障害が発生した場合の動作

(2)　グローバルセッション情報更新時に障害が発生した場合の動作

(3)　グローバルセッション情報の削除時に障害が発生した場合の動作

(4)　有効期限切れによるグローバルセッション情報削除時に障害が発生した場合の動作

(5)　グローバルセッション情報を使用したグローバルセッション引き継ぎ時に障害が発生した場合の動作

(1)　グローバルセッション情報の作成時に障害が発生した場合の動作

グローバルセッション情報の作成時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報の作成処理の流れと障害発生のポイントを次の図に示します。

図6-8　グローバルセッション情報の作成処理の流れと障害発生のポイント

以降の説明では，図中の数字（J2EEサーバの障害発生ポイント）またはアルファベット（データベースの障害発生ポイント）と，表中の障害発生ポイントの数字またはアルファベットが対応しています。

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報の作成時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作を次の表に示します。

表6-20　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響
J2EEサーバのHTTPセッション | グローバルセッション情報
1 | 作成されない | 作成されない | なし
2 | 作成されない | 作成されない（ロールバック）※1 | データベースがクライアント接続を検知するまでの間，すべてのHTTPセッションの新規作成はできない
3 | 作成されない | 作成される※2 | なし
4 | プロセスダウンによって消滅 | 作成される※2 | なし

注※1　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

注※2　この状態のグローバルセッション情報の引き継ぎはできません。有効期限が切れると，有効期限監視によって削除されます。

(b)　データベース障害発生時の動作（SQLException例外が発生した場合）

グローバルセッション情報の作成時にデータベース障害が発生し，SQLException例外が発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-21　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 縮退して作成される※1 | 作成されない | なし | 正常終了 | KDJE34368-W
B～F | 縮退して作成される※1 | 作成されない（ロールバック）※2 | なし | 正常終了 | KDJE34368-W
G | － | － | － | － | －
H | － | － | － | － | －

（凡例）－：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

表6-22　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 作成されない | 作成されない | なし | HTTPセッションの取得時に例外発生※1 | KDJE34314-W
B～F | 作成されない | 作成されない（ロールバック）※2 | なし | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
G | 作成されない | 作成される※3 | なし | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
H | 作成されない（削除される） | 作成される※3 | なし | － | KDJE34312-W

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

注※3　この状態のグローバルセッション情報の引き継ぎはできません。有効期限が切れると，有効期限監視によって削除されます。

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

グローバルセッション情報の作成時にデータベース障害が発生し，データベースが無応答またはスローダウンした場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-23　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 縮退して作成される※1 | 作成されない | なし | 正常終了 | KDJE34368-W
B～F | 縮退して作成される※1 | 作成されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，すべてのHTTPセッションの新規作成はできない | 正常終了 | KDJE34368-W
G | － | － | － | － | －
H | － | － | － | － | －

（凡例）－：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

表6-24　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 作成されない | 作成されない | なし | HTTPセッションの取得時に例外発生※1 | KDJE34314-W
B～F | 作成されない | 作成されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，すべてのHTTPセッションの新規作成はできない | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
G | 作成されない | 作成される※3 | なし | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
H | 作成されない（削除される） | 作成される※3 | なし | － | KDJE34312-W

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

注※3　この状態のグローバルセッション情報の引き継ぎはできません。有効期限が切れると，有効期限監視によって削除されます。

(2)　グローバルセッション情報更新時に障害が発生した場合の動作

グローバルセッション情報の更新時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報の更新処理の流れと障害発生のポイントを次の図に示します。

図6-9　グローバルセッション情報の更新処理の流れと障害発生のポイント

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報の更新時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作を次の表に示します。

表6-25　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響
J2EEサーバのHTTPセッション | グローバルセッション情報
1 | プロセスダウンによって消滅 | 更新されない | なし
2 | プロセスダウンによって消滅 | 更新されない（ロールバック）※ | データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない
3 | プロセスダウンによって消滅 | 更新されない（ロールバック）※ | データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない
4 | プロセスダウンによって消滅 | 更新されない（ロールバック）※ | データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

注※　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

(b)　データベース障害発生時の動作（SQLException例外が発生した場合）

グローバルセッション情報の更新時にデータベース障害が発生し，SQLException例外が発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-26　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 縮退して更新される※ | 更新されない | なし | 正常終了 | KDJE34368-W
B | － | － | － | － | －
C | 縮退して更新される※ | 更新されない | なし | － | KDJE34368-W
D | － | － | － | － | －

（凡例）－：該当なし

注※　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

表6-27　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 更新されない | 更新されない | なし | HTTPセッションの取得時に例外発生※1 | KDJE34314-W
B | 更新されない（削除される） | 更新されない（ロールバック）※2 | なし | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
C | 更新されない（削除される） | 更新されない（ロールバック）※2 | なし | － | KDJE34312-W
D | 更新されない（削除される） | 更新されない（ロールバック）※2 | なし | － | KDJE34312-W

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

グローバルセッション情報の更新時にデータベース障害が発生し，データベースが無応答またはスローダウンした場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-28　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 縮退して更新される※1 | 更新されない | なし | 正常終了 | KDJE34368-W
B | － | － | － | － | －
C | 縮退して更新される※1 | 更新されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34368-W
D | － | － | － | － | －

（凡例）－：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

表6-29　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 更新されない | 更新されない | なし | HTTPセッションの取得時に例外発生※1 | KDJE34314-W
B | 更新されない（削除される） | 更新されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | HTTPセッションの取得時に例外発生※1 | KDJE34312-W
C | 更新されない（削除される） | 更新されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34312-W
D | 更新されない（削除される） | 更新されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34312-W

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

(3)　グローバルセッション情報の削除時に障害が発生した場合の動作

グローバルセッション情報の削除時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報の削除処理の流れと障害発生のポイントを次の図に示します。

図6-10　グローバルセッション情報の削除処理の流れと障害発生のポイント

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報の削除時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作を次の表に示します。

表6-30　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響
J2EEサーバのHTTPセッション | グローバルセッション情報
1 | プロセスダウンによって消滅 | 削除されない | なし
2 | プロセスダウンによって消滅 | 削除されない（ロールバック）※ | データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない
3 | プロセスダウンによって消滅 | 削除されない（ロールバック）※ | データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない
4 | プロセスダウンによって消滅 | 削除されている | なし

注※　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

(b)　データベース障害発生時の動作（SQLException例外が発生した場合）

グローバルセッション情報の削除時にデータベース障害が発生し，SQLException例外が発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-31　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除される | 削除されない | なし | HTTPセッションの取得時に例外が発生※1 | KDJE34377-E※2
B | － | － | － | － | －
C～F | 削除される | 削除されない（ロールバック）※3 | なし | HTTPセッションの無効化時に例外が発生※4 | KDJE34377-E※2

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

注※3　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

注※4　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッドの呼び出しで，JSPの場合は暗黙オブジェクトsessionのinvalidateメソッドの呼び出しで，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

表6-32　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除されない | 削除されない | なし | HTTPセッションの取得時に例外が発生※1 | KDJE34314-W
B | 削除される | 削除されない（ロールバック）※2 | なし | HTTPセッションの取得時に例外が発生※1 | KDJE34312-W
C～F | 削除される | 削除されない（ロールバック）※2 | なし | HTTPセッションの無効化時に例外が発生※3 | KDJE34312-W

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　SQLException例外が発生し，リクエスト受信前の状態にロールバックします。

注※3　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッドの呼び出しで，JSPの場合は暗黙オブジェクトsessionのinvalidateメソッドの呼び出しで，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

グローバルセッション情報の削除時にデータベース障害が発生し，データベースが無応答またはスローダウンした場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-33　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除される | 削除されない | なし | HTTPセッションの取得時に例外が発生※1 | KDJE34377-E※2
B | － | － | － | － | －
C～F | 削除される | 削除されない（ロールバック）※3 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | HTTPセッションの無効化時に例外が発生※4 | KDJE34377-E※2

（凡例）－：該当なし

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

注※3　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

注※4　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッドの呼び出しで，JSPの場合は暗黙オブジェクトsessionのinvalidateメソッドの呼び出しで，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

表6-34　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除されない | 削除されない | なし | HTTPセッションの取得時に例外が発生※1 | KDJE34314-W
B | 削除される | 削除されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | HTTPセッションの取得時に例外が発生※1 | KDJE34312-W
C～F | 削除される | 削除されない（ロールバック）※2 | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | HTTPセッションの無効化時に例外が発生※3 | KDJE34312-W

注※1　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

注※3　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのinvalidateメソッドの呼び出しで，JSPの場合は暗黙オブジェクトsessionのinvalidateメソッドの呼び出しで，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

(4)　有効期限切れによるグローバルセッション情報削除時に障害が発生した場合の動作

有効期限切れによるグローバルセッション情報削除時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

有効期限切れによるグローバルセッション情報削除処理の流れと障害発生のポイントを次の図に示します。

図6-11　有効期限切れによるグローバルセッション情報削除処理の流れと障害発生のポイント

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

有効期限切れによるグローバルセッション情報の削除時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作を次の表に示します。

表6-35　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響
J2EEサーバのHTTPセッション | グローバルセッション情報
1 | プロセスダウンによって消滅 | 削除されない | なし
2，3 | プロセスダウンによって消滅 | 削除されない（ロールバック） | データベースがクライアントの切断を検知するまでの間，該当するHTTPセッションの操作はできない

(b)　データベース障害発生時の動作（SQLException例外が発生した場合）

有効期限切れによるグローバルセッション情報の削除時にデータベース障害が発生し，SQLException例外が発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-36　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | － | － | － | － | －
B～E | 削除される | 削除されない（ロールバック） | なし | － | KDJE34377-E※

（凡例）－：該当なし

注※　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

表6-37　データベース障害でSQLException例外が発生した場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除される | 削除されない（ロールバック） | なし | － | KDJE34336-W
B～E | 削除される | 削除されない（ロールバック） | なし | － | KDJE34312-W

（凡例）－：該当なし

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

有効期限切れによるグローバルセッション情報の削除時にデータベース障害が発生し，データベースが無応答またはスローダウンした場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6-38　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | － | － | － | － | －
B～E | 削除される | 削除されない（ロールバック） | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34377-E※

（凡例）－：該当なし

注※　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

表6-39　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
A | 削除される | 削除されない（ロールバック） | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34336-W
B～E | 削除される | 削除されない（ロールバック） | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | － | KDJE34312-W

（凡例）－：該当なし

(5)　グローバルセッション情報を使用したグローバルセッション引き継ぎ時に障害が発生した場合の動作

グローバルセッション情報を使用したグローバルセッション引き継ぎ時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報を使用したグローバルセッション引き継ぎ処理の流れと障害発生のポイントを次の図に示します。

図6-12　グローバルセッション情報を使用したグローバルセッション引き継ぎ処理の流れと障害発生のポイント

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報を使用したグローバルセッション引き継ぎ時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作は，グローバルセッション情報の更新時にJ2EEサーバ障害が発生した場合と同じ動作になります。

グローバルセッション情報の更新時にJ2EEサーバ障害が発生した場合の動作については，「(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のJ2EEサーバ障害発生時の動作を参照してください。

(b)　データベース障害発生時の動作（SQLException例外が発生した場合）

グローバルセッション情報を使用したグローバルセッション引き継ぎ時の，図中Cの処理中にデータベース障害が発生し，SQLException例外が発生した場合の動作を次の表に示します。図中A，B，D，Eの処理中に障害が発生した場合の動作は，グローバルセッション情報の更新時にデータベースでSQLException例外が発生した場合と同じ動作になります。

グローバルセッション情報の更新時にデータベース障害でSQLException例外が発生した場合の動作については，「(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のデータベース障害発生時の動作（SQLException例外が発生した場合）を参照してください。

表6-40　データベース障害でSQLException例外が発生した場合の動作

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
C | 引き継がれない | 引き継がれない | なし | HTTPセッションの取得時に例外が発生※ | KDJE34314-W

注※　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

グローバルセッション情報を使用したグローバルセッション引き継ぎ時の，図中Cの処理中にデータベース障害が発生し，データベースが無応答，またはスローダウンした場合の動作を次の表に示します。図中A，B，D，Eの処理中に障害が発生した場合の動作は，グローバルセッション情報の更新時にデータベースが無応答またはスローダウンした発生した場合と同じ動作になります。

グローバルセッション情報の更新時にデータベース障害で無応答またはスローダウンした場合の動作については，「(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のデータベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）を参照してください。

表6-41　データベース障害で無応答またはスローダウンしている場合の動作

障害発生ポイント | セッションの状態 | 他のリクエストへの影響 | Webアプリケーションの動作 | メッセージ
J2EEサーバのHTTPセッション | グローバルセッション情報
C | 引き継がれない | 引き継がれない | ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない | HTTPセッションの取得時に例外が発生※ | KDJE34314-W

注※　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessException例外が発生します。

6.9　実装時の注意事項

ここでは，アプリケーション実装時の注意事項について説明します。

＜この節の構成＞

6.9.1　JSPで暗黙的に作成されるHTTPセッション

6.9.2　異なるHTTPセッションに同一のオブジェクトが登録されている場合を考慮した処理

6.9.3　セッション情報の引き継ぎが発生した場合の認証情報の扱い

6.9.4　サーブレットAPIへの影響

6.9.1　JSPで暗黙的に作成されるHTTPセッション

セッションの引き継ぎを必要としない処理では明示的にHttpSessionオブジェクトを作成しないように設定してください。

データベースセッションフェイルオーバ機能を有効にしたアプリケーションでは，属性が登録されないHTTPセッションの作成時にも，グローバルセッション情報が作成され，さらにグローバルセッション情報の更新処理も発生します。

JSP仕様では，デフォルトでHttpSessionオブジェクトが作成されます。そのため，不要な処理によって，メモリの使用量が増加したり，データベースとの通信による負荷が発生したりするおそれがあります。

HttpSessionオブジェクトの作成に関する設定には，pageディレクティブのsession属性を使用します。

6.9.2　異なるHTTPセッションに同一のオブジェクトが登録されている場合を考慮した処理

グローバルセッション情報はHTTPセッション単位に作成されます。

異なるHttpSessionオブジェクトで同一のオブジェクトをセッション情報として共有している場合に，グローバルセッション情報の引き継ぎが発生したときは，オブジェクトが共有されません。別々のオブジェクトとして作成されます。

異なるHttpSessionオブジェクトに同一のオブジェクトが登録されている場合の引き継ぎの例を次の図に示します。

図6-13　異なる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は，インスタンスは異なりますが，内容は同じです。

6.9.3　セッション情報の引き継ぎが発生した場合の認証情報の扱い

障害発生時に認証情報を引き継ぐ場合は，Basic認証によって認証処理をする必要があります。Basic認証を使用すると，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合でも，再度認証する必要はありません。グローバルセッション情報は正常に引き継がれ，業務を続けられます。

サーブレットAPIで定義されているForm認証によって認証処理をしている場合，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合は，認証情報が引き継がれていても，再度認証が必要です。

Basic認証およびForm認証については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「9.3　ロールに基づくWebコンテナのユーザ認証」を参照してください。

6.9.4　サーブレットAPIへの影響

データベースセッションフェイルオーバ機能を使用した場合のサーブレットAPIへの影響として，次の項目について説明します。

引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの動作

サーブレットAPIの呼び出しによるデータベースとの通信の発生

＜この項の構成＞

(1)　引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの動作

(2)　サーブレットAPIの呼び出しによるデータベースとの通信の発生

(1)　引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの動作

引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの注意点について次の表に示します。

表6-42　HttpSessionオブジェクトに関連するサーブレットAPIの注意点

項番 | API名 | 注意点
1 | getCreationTime() | 引き継ぎによって，HttpSessionオブジェクトが作成された場合，引き継ぎ前のHttpSessionオブジェクトの情報が引き継がれます。
2 | getLastAccessedTime()
3 | getId() | 引き継ぎによって，HttpSessionオブジェクトが作成された場合，引き継ぎ前のHttpSessionオブジェクトと同一のIDが取得できます。
4 | isNew() | 引き継ぎによって，HttpSessionオブジェクトが作成されても，戻り値「true」は返されません。

この表に示していないサーブレットAPIについては，データベースセッションフェイルオーバ機能を使用した場合の影響はありません。

(2)　サーブレットAPIの呼び出しによるデータベースとの通信の発生

次の表に示すサーブレットAPIを実装した場合，API呼び出しの延長でデータベースとの通信が発生します。そのため，性能への影響があります。

表6-43　データベースとの通信が発生するサーブレットAPI

項番 | クラス | メソッド
1 | javax.servlet.http.HttpServletRequest | getSession()※1
2 | javax.servlet.http.HttpServletRequest | getSession(boolean create)※1
3 | javax.servlet.http.HttpSession | invalidate()※2

注※1

新規にHttpSessionオブジェクトを作成した場合にだけ性能に影響があります。

注※2

有効なHttpSessionオブジェクトのinvalidate()メソッドを呼び出した場合にだけ性能に影響があります。

6.10　cosminexus.xmlでの定義

データベースセッションフェイルオーバ機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのデータベースセッションフェイルオーバ機能の定義について次の表に示します。

表6-44　cosminexus.xmlでのデータベースセッションフェイルオーバ機能の定義

項目 | 指定するタグ | 設定内容
データベースセッションフェイルオーバ機能の設定 | <http-session>-<dbsfo>-<enabled> | データベースセッションフェイルオーバ機能を有効にするかどうかをWebアプリケーション単位で設定します。
HttpSessionオブジェクト数の上限値 | <http-session>-<http-session-max-number> | HttpSessionオブジェクト数の上限値を設定します。
アプリケーション識別子 | <http-session>-<dbsfo>-<application-id> | アプリケーション識別子を設定します。
HTTPセッションの属性情報の最大サイズ | <http-session>-<dbsfo>-<attribute-data-size-max> | グローバルセッション情報に含められるHTTPセッションの属性情報の最大サイズを設定します。
拡張子によるデータベースセッションフェイルオーバ機能の抑止 | <http-session>-<dbsfo>-<exclude-extensions> | データベースセッションフェイルオーバ機能をWebアプリケーション単位で有効にする場合に，データベースセッションフェイルオーバ機能を抑止する拡張子を設定します。

指定するタグの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

6.11　データベースの設定

この節では，データベースセッションフェイルオーバ機能を使用する場合に必要となる，データベースのディスク容量の確保，テーブルの作成，および環境設定について説明します。

注意

テーブルを作成する際，テンプレートファイルについてここで説明しない変更をした場合，データベースセッションフェイルオーバ機能の動作は保障されません。

＜この節の構成＞

6.11.1　データベースのディスク容量の確保

6.11.2　データベース接続に必要な権限

6.11.3　データベースのテーブルの作成

6.11.4　アプリケーション情報テーブルの作成

6.11.5　セッション情報格納テーブルおよび空きレコード情報テーブルの作成

6.11.6　データベースの環境設定

6.11.1　データベースのディスク容量の確保

確保するディスク容量のサイズは，HTTPセッションの属性情報のサイズの見積もり値を基に見積もります。HTTPセッションの属性情報のサイズの見積もりについては，「6.5.2　HTTPセッションの属性情報のサイズの見積もり」を参照してください。

参考

HiRDBを使用する場合，次の条件を満たすことで性能が向上する場合があります。

データベースセッションフェイルオーバ機能で使用するテーブルおよびインデクスをRDエリアに配置している※。

RDエリアに配置したテーブルおよびインデクスにそれぞれグローバルバッファを設定している。

RDエリア，およびグローバルバッファの設計については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。

注※

RDエリアにテーブルおよびインデクスを配置する場合，SQLファイルの編集が必要です。

6.11.2　データベース接続に必要な権限

データベースのテーブルを操作するには権限が必要です。また，条件を満たす必要があります。データベースごとのテーブルの操作に必要な権限および条件について説明します。ここでは，データベースに接続するユーザのことをデータベース接続ユーザといいます。

●HiRDBの場合

ここでは，データベース接続ユーザが，データベースセッションフェイルオーバ機能で使用するテーブルに関するすべての操作を実施することを想定しています。データベース接続ユーザは，次の権限および条件を満たす必要があります。

スキーマを所有すること。

CONNECT権限を持つこと。

データベース接続ユーザのスキーマに，データベースセッションフェイルオーバ機能が使用するテーブル，インデックスおよびストアドプロシジャを作成すること。

データベースのテーブルの作成の詳細については，「6.11.3データベースのテーブルの作成」を参照してください。データベースのテーブルの削除の詳細については，「6.16　データベースのテーブルの削除」を参照してください。

●Oracleの場合

ここでは，データベースセッションフェイルオーバ機能が使用するデータベースのテーブルの作成または削除の操作はデータベース管理者が実施し，そのほかの通常の運用で必要となるデータベースの操作は，データベースセッションフェイルオーバ機能のデータベース接続ユーザが実施することを想定しています。データベース接続ユーザは，次の権限および条件を満たす必要があります。

CREATE SESSIONシステム権限を持つこと。

データベース接続ユーザのスキーマに，データベースセッションフェイルオーバ機能が使用するテーブル，インデックスおよびストアドプロシジャを作成すること。

データベースのテーブルの作成の詳細については，「6.11.3データベースのテーブルの作成」を参照してください。データベースのテーブルの削除の詳細については，「6.16　データベースのテーブルの削除」を参照してください。

6.11.3　データベースのテーブルの作成

データベースセッションフェイルオーバ機能では，データベース上に3種類のテーブルを作成する必要があります。作成するテーブルと，作成手順の参照先について次の表に示します。

表6-45　作成するテーブルと，作成手順の参照先

テーブル名 | データベース上の物理名称 | 作成手順の参照先
アプリケーション情報テーブル | SFO_<APPLICATION_ID>_APP_INFO | 6.11.4
セッション情報格納テーブル | SFO_<APPLICATION_ID>_SESSIONS | 6.11.5
空きレコード情報テーブル | SFO_<APPLICATION_ID>_REC_INFO

データベースセッションフェイルオーバ機能で使用するデータベースのテーブル作成用のテンプレートファイルは次の場所に格納されています。

Windowsの場合：

<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥

UNIXの場合：

/opt/Cosminexus/CC/sfo/sql/

テーブル作成用のテンプレートファイルは使用するデータベースごとに2種類ずつあります。使用するデータベース，ファイル，および作成するテーブルの種類の対応を次の表に示します。

表6-46　テーブル作成用テンプレートファイルと作成するテーブル

使用するデータベース | テンプレートファイル | 作成するテーブルの種類
アプリケーション情報テーブル | セッション情報格納テーブル | 空きレコード情報テーブル
HiRDB | hirdb_create_apptbl.sql | ○ | －
hirdb_create_sessiontbl.sql | － | ○
Oracle | oracle_create_apptbl.sql | ○ | －
oracle_create_sessiontbl.sql | － | ○

（凡例）○：作成できる　－：作成できない

以降で，使用するデータベースごとにテンプレートファイルの詳細について示します。

また，DB Connectorに設定するユーザには，テーブルの作成者を登録してください。

6.11.4　アプリケーション情報テーブルの作成

アプリケーション情報テーブルは，Webアプリケーションに設定したデータベースセッションフェイルオーバ機能に関する設定を格納するテーブルです。

アプリケーション情報テーブルの作成手順を次に示します。

テンプレートファイルを任意の場所にコピーします。
テーブル作成用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_create_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_create_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_create_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_create_apptbl.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル作成用SQLファイルを作成します。
テンプレートファイル内の変更個所と変更内容を次の表に示します。

表6-47　テンプレートファイル内の変更個所と変更内容

変更個所
変更対象
変更内容

HiRDB
Oracle

1行目

5行目

1行目

5行目

<APPLICATION_ID>
使用するアプリケーションのアプリケーション識別子に変更してください。

なし

1行目

5行目

<SCHEMA_NAME>
データベース接続ユーザのスキーマ名に変更してください。

6行目
6行目
<HTTP_SESSION_NO>
HttpSessionオブジェクト数の最大値に変更してください。

作成したテーブル作成用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

6.11.5　セッション情報格納テーブルおよび空きレコード情報テーブルの作成

セッション情報格納テーブルは，グローバルセッション情報を格納するテーブルです。空きレコード情報テーブルは，セッション情報格納テーブルの未使用レコードを管理するテーブルです。セッション情報格納テーブルおよび空きレコード情報テーブルは，一つのテーブル作成用のSQLファイルを実行することで同時に作成されます。

セッション情報格納テーブルおよび空きレコード情報テーブルの作成手順を次に示します。

テンプレートファイルを任意の場所にコピーします。
テーブル作成用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_create_sessiontbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_create_sessiontbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥oracle_create_sessiontbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_create_sessiontbl.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル作成用SQLファイルを作成します。
テンプレートファイル内の，使用するデータベースごとの変更個所と変更内容について次の表に示します。

表6-48　テンプレートファイル内の変更個所と変更内容

変更個所
変更対象
変更内容

HiRDB
Oracle

1行目

13行目

18行目

19行目

23行目

48行目

50行目

57行目

60行目

74行目

1行目

13行目

18行目

19行目

23行目

49行目

51行目

58行目

61行目

74行目

<APPLICATION_ID>
使用するアプリケーションのアプリケーション識別子に変更してください。

なし

1行目

13行目

18行目

19行目

23行目

49行目

51行目

58行目

60行目

74行目

<SCHEMA_NAME>
データベース接続ユーザのスキーマ名に変更してください。

7行目
なし
<ATTRIBUTE_DATA_SIZE_MAX>
HTTPセッションの属性情報の最大サイズ（単位：バイト）に変更してください。

74行目
74行目
<HTTP_SESSION_NO>

ネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を中止する設定にしているときは，HttpSessionオブジェクト数の最大値に変更してください。

ネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を続行する設定にしているときは，データベースに格納するグローバルセッション情報の数に変更してください。

作成したテーブル作成用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

6.11.6　データベースの環境設定

データベースセッションフェイルオーバ機能を使用する場合，データベースにはタイムアウト（HiRDBの場合UAP処理時間監視機能）の設定をしてください。

データベースセッションフェイルオーバ機能が有効の場合，機能の処理の中で操作対象となるデータベースのテーブルのレコードが排他制御されます。そのため，J2EEサーバのホストでの障害発生時などに，操作対象となっていたレコードが排他されたままになる場合があります。このとき，HTTPセッションの新規作成や，J2EEサーバとデータベースとの接続に失敗するおそれがあります。

タイムアウトの設定をしておくと，このような状況を検知してタイムアウト時にトランザクションがロールバックされ，レコードが排他制御される前の状態に戻るため，システムへの影響はなくなります。

なお，誤動作を防ぐために，データベースのタイムアウトの値にはDB Connectorに設定するタイムアウトの値よりも大きな値を設定してください。データベースの設定内容，手順については，HiRDBを使用する場合はマニュアル「HiRDB　UAP開発ガイド」を，Oracleを使用する場合はOracleのマニュアルを参照してください。

レコードが排他制御される処理，処理中に操作対象となるテーブル，処理中にJ2EEサーバで障害が発生した場合のシステムへの影響，および出力されるメッセージを次の表に示します。

表6-49　レコードが排他制御される処理と処理中にJ2EEサーバで障害が発生した場合のシステムへの影響

項番
レコードが排他制御される処理
操作対象のテーブル
障害が発生した場合のシステムへの影響
出力されるメッセージ

1
Webアプリケーション開始時のネゴシエーション処理
アプリケーション情報テーブル
アプリケーションのネゴシエーションに失敗するため，データベースセッションフェイルオーバ機能を使用するWebアプリケーションの開始に失敗します。
出力されない

2
グローバルセッション情報の作成処理
空きレコード情報テーブル
システムで作成できるHTTPセッションの数が全体の90％になります。このあと，HTTPセッションの作成，または削除処理に失敗する場合があります。

完全性保障モード無効時：KDJE34368-W

完全性保障モード有効時：KDJE34312-W

3
グローバルセッション情報の削除処理
空きレコード情報テーブル
システムで作成できるHTTPセッションの数が全体の90％になります。このあと，HTTPセッションの作成，または削除処理に失敗する場合があります。

完全性保障モード無効時：KDJE34377-E

完全性保障モード有効時：KDJE34312-W

4
グローバルセッション情報の更新処理
セッション情報格納テーブル
システムで作成できるHTTPセッションの数が1個分減少します。このあと，減少したHTTPセッションを操作するリクエストを受信すると，HTTPセッションの取得に失敗します。

完全性保障モード無効時：KDJE34368-W

完全性保障モード有効時：KDJE34312-W

5
グローバルセッション情報の有効期限監視処理
アプリケーション情報テーブル
データベース上のグローバルセッション情報の有効期限が監視されなくなります。

完全性保障モード無効時：排他処理を行わない

完全性保障モード有効時：KDJE34336-W

6.12　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。データベースセッションフェイルオーバ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのデータベースセッションフェイルオーバ機能の定義について次の表に示します。

表6-50　簡易構築定義ファイルでのデータベースセッションフェイルオーバ機能の定義

項目
指定するパラメタ
設定内容
参照先

データベースセッションフェイルオーバ機能の設定
webserver.dbsfo.enabled
J2EEサーバ単位でデータベースセッションフェイルオーバ機能を使用するかどうかを設定します。
－

DB Connectorの別名の設定
webserver.dbsfo.connector.name
DB Connectorで設定する，DB Connectorの別名を指定します。
DB Connectorの別名の設定については「6.13.2　DB Connectorの別名の設定」を参照してください。
－

完全性保障モードの設定
webserver.dbsfo.integrity_mode.enabled※1
データベースセッションフェイルオーバ機能の完全性保障モードを有効にするかどうかを設定します。
－

シリアライズ処理で使用するメモリ量の設定
－
シリアライズ処理で使用するメモリを考慮して，JavaVMのチューニングをします※2。
－

拡張子によるデータベースセッションフェイルオーバ機能の抑止の設定
webserver.dbsfo.exclude.extensions
J2EEサーバ単位でデータベースセッションフェイルオーバ機能を使用する場合に，データベースセッションフェイルオーバ機能を抑止する拡張子を設定します。
－

URI単位のデータベースセッションフェイルオーバ機能の抑止の設定
webserver.dbsfo.exclude.uris
J2EEサーバ単位でデータベースセッションフェイルオーバ機能を使用する場合に，データベースセッションフェイルオーバ機能を抑止するURIを設定します。
(1)

参照専用リクエストの設定
webserver.dbsfo.session_read_only.uris
参照専用リクエストとするURIを設定します。
(2)

HttpSessionのサーバID付加機能の設定

webserver.session.server_id.enabled

webserver.session.server_id.value

HttpSessionのサーバID付加機能を設定します。また，サーバIDには冗長化したJ2EEサーバごとに異なる値を設定します。
－

同時実行スレッド数制御機能を使用する場合の実行待ちキュー不足時の設定
webserver.dbsfo.thread_control_queue.enabled
Webアプリケーション単位の同時実行スレッド数制御機能が有効の場合に，実行待ちキューの空きが不足したときの動作を設定します。
－

ネゴシエーション失敗時のWebアプリケーション開始処理の設定
webserver.dbsfo.negotiation.high_level
ネゴシエーションが失敗した場合にWebアプリケーションの開始処理を続行するか中止するかを設定します。
－

データベースセッションフェイルオーバ機能の抑止対象リクエスト内での，getSessionメソッド実行時の例外の設定
webserver.dbsfo.exception_type_backcompat
データベースセッションフェイルオーバ機能の抑止対象リクエスト内で，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドを実行した場合に発生する例外を設定します。
－

（凡例）－：該当なし。

注※1　完全性保障モードの設定でwebserver.dbsfo.integrity_mode.enabledパラメタにfalseを指定した場合，HttpSessionのサーバID付加機能の設定でwebserver.session.server_id.enabledパラメタ，およびwebserver.session.server_id.valueパラメタを指定する必要があります。

注※2　シリアライズ処理で使用するメモリ量の見積もり方法については，「6.5.1　シリアライズ処理で使用するメモリの見積もり」を参照してください。JavaVMのチューニングについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

＜この節の構成＞

(1)　データベースセッションフェイルオーバ機能の抑止の設定

(2)　参照専用リクエストの設定

(1)　データベースセッションフェイルオーバ機能の抑止の設定

ここでは，URI単位のデータベースセッションフェイルオーバ機能の抑止をする場合の，URIの指定方法について説明します。

●URIの指定方法

コンテキストパスを含む「/」(スラッシュ)で始まるURIを指定します。パスパラメタ，クエリ，およびフラグメントは含みません。なお，設定値のURI中に「;」（セミコロン）を使用することはできません。

また，複数のURIを指定する場合は，「;」（セミコロン）で区切って指定してください。

●完全一致指定とプリフィックス一致指定

次のどちらかで指定できます。

完全一致指定
指定したURIがリクエストURIに完全一致した場合だけ，データベースセッションフェイルオーバ機能の抑止の対象になります。

指定例（簡易構築定義ファイルの場合）

：
<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>webserver.dbsfo.exclude.uris</param-name>
     <param-value>/examples/test/TestServlet;/examples/test2/TestServlet2</param-value>
   </param>
</configuration>
：

この例の場合，次のリクエストURIがデータベースセッションフェイルオーバ機能の抑止対象になります。

http://host/examples/test/TestServlet

http://host/examples/test/TestServlet?name=value

http://host/examples/test/TestServlet;gsessionid=XXXXXXXXXX

プリフィックス一致指定
リクエストURIとプリフィックスが一致する場合，データベースセッションフェイルオーバ機能の抑止の対象になります。

指定例（簡易構築定義ファイルの場合）

：
<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>webserver.dbsfo.exclude.uris</param-name>
     <param-value>/examples/*</param-value>
   </param>
</configuration>
：

この例の場合，次のリクエストURIがデータベースセッションフェイルオーバ機能の抑止対象になります。

http://host/examples/test/TestServlet

http://host/examples/dbsfo/DbsfoServlet?name=value

なお，プリフィックス一致指定の場合，URIの指定は「/*」で終了する必要があります。例えば，次のようなURIを指定した場合は，プリフィックス一致指定ではなく，完全一致指定と扱われます。

/examples/test*

●URIの正規化

データベースセッションフェイルオーバ機能の抑止対象とするURIは，正規化して指定する必要があります。正規化していないURIを指定した場合，KDJE34341-Wのメッセージが出力されて，該当するURIは抑止の対象外になります。

正規化したURIの例を次に示します。

/examples/test/servlet/TestServlet

正規化していないURIの例を次に示します。これらのURIは抑止の対象外になります。

/examples/test/jsp/../servlet/TestServlet

/examples/test/./servlet/TestServlet

●URLエンコードとの対応

URLエンコードをしたURIを抑止対象として指定した場合は，指定したURIと一致する，URLエンコードされたURLのリクエストがデータベースセッションフェイルオーバ機能の抑止対象になります。同様に，URLエンコードをしないURIを指定した場合は，URLエンコードされていないURLのリクエストがデータベースセッションフェイルオーバ機能の抑止対象になります。

ただし，URIのデコード機能を使用する場合，対象のURLは，デコードが実施されたあとでURIによるデータベースフェイルオーバ機能の抑止の対象かどうかが判定されます。このため，URLエンコードされたURLが抑止対象として指定したURIと一致する場合に，URI単位のデータベースセッションフェイルオーバ機能の抑止対象になります。

URIのデコード機能の有効・無効によって抑止の対象となるURLについて，次の表に示します。

表6-51　URIのデコード機能の有効・無効によって抑止の対象となるURL

プロパティ
設定値
リクエストURL

URIのデコード機能 有効
URIのデコード機能 無効

エンコードあり
エンコードなし
エンコードあり
エンコードなし

エンコードあり
抑止しない
抑止しない
抑止する
抑止しない

エンコードなし
抑止する
抑止する
抑止しない
抑止する

（凡例）

抑止する：データベースセッションフェイルオーバ機能を抑止する（データベースセッションフェイルオーバ機能が無効になる）。

抑止しない：データベースセッションフェイルオーバ機能を抑止しない（データベースセッションフェイルオーバ機能が有効になる）。

エンコードあり：URLエンコードされた文字列を含むURI。

（例：/examples/%61/Servlet）

エンコードなし：URLエンコードされた文字列を含まないURI。

（例：/examples/a/Servlet）

URIのデコード機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.23　URIのデコード機能」を参照してください。

●URI指定時の注意事項

URIによるデータベースセッションフェイルオーバ機能の抑止で設定するURIは，ネゴシエーション時に確認される項目ではありません。このため，それぞれのJ2EEサーバで設定するURIが同じことを確認してください。

(2)　参照専用リクエストの設定

ここでは，参照専用リクエストを設定する場合の，URIの指定方法について説明します。

●URIの指定方法

コンテキストパスを含む「/」(スラッシュ)で始まるURIを指定します。パスパラメタ，クエリ，およびフラグメントは含みません。指定できる文字数は512文字までです。なお，設定値のURI中に「;」（セミコロン）を使用することはできません。

また，複数のURIを指定する場合は，「;」（セミコロン）で区切って指定してください。

●完全一致指定とプリフィックス一致指定

次のどちらかで指定できます。

完全一致指定
指定したURIがリクエストURIに完全一致した場合だけ，参照専用リクエストになります。

指定例（簡易構築定義ファイルの場合）

：
<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>webserver.dbsfo.session_read_only.uris</param-name>
     <param-value>/examples/test/TestServlet;/examples/test2/TestServlet2</param-value>
   </param>
</configuration>
：

この例の場合，次のリクエストURIが参照専用リクエストになります。

http://host/examples/test/TestServlet

http://host/examples/test/TestServlet?name=value

http://host/examples/test/TestServlet;gsessionid=XXXXXXXXXX

プリフィックス一致指定
リクエストURIとプリフィックスが一致する場合，参照専用リクエストになります。

指定例（簡易構築定義ファイルの場合）

：
<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>webserver.dbsfo.session_read_only.uris</param-name>
     <param-value>/examples/*</param-value>
   </param>
</configuration>
：

この例の場合，次のリクエストURIが参照専用リクエストになります。

http://host/examples/test/TestServlet

http://host/examples/dbsfo/DbsfoServlet?name=value

なお，プリフィックス一致指定の場合，URIの指定は「/*」で終了する必要があります。例えば，次のようなURIを指定した場合は，プリフィックス一致指定ではなく，完全一致指定と扱われます。

/examples/test*

●URIの正規化

参照専用リクエストとするURIは，正規化して指定する必要があります。正規化していないURIを指定した場合，KDJE34357-Wのメッセージが出力されて，該当するURIは参照専用リクエストになりません。

正規化したURIの例を次に示します。

/examples/test/servlet/TestServlet

正規化していないURIの例を次に示します。これらのURIは参照専用リクエストになりません。

/examples/test/jsp/../servlet/TestServlet

/examples/test/./servlet/TestServlet

●URLエンコードとの対応

URLエンコードをしたURIを参照専用リクエストとして指定した場合は，指定したURIと一致する，URLエンコードされたURLのリクエストが参照専用リクエストになります。同様に，URLエンコードをしないURIを指定した場合は，URLエンコードされていないURLのリクエストが参照専用リクエストになります。

ただし，URIのデコード機能を使用する場合，対象のURLは，デコードが実施されたあとでURIによる参照専用リクエストかどうかが判定されます。このため，URLエンコードされたURLが参照専用リクエストとして指定したURIと一致する場合に，URI単位の参照専用リクエストになります。

URIのデコード機能の有効・無効によって参照専用リクエストになるURLについて，次の表に示します。

表6-52　URIのデコード機能の有効・無効によって参照専用リクエストになるURL

プロパティ
設定値
リクエストURL

URIのデコード機能 有効
URIのデコード機能 無効

エンコードあり
エンコードなし
エンコードあり
エンコードなし

エンコードあり
参照専用リクエストにならない
参照専用リクエストにならない
参照専用リクエストになる
参照専用リクエストにならない

エンコードなし
参照専用リクエストになる
参照専用リクエストになる
参照専用リクエストにならない
参照専用リクエストになる

（凡例）

参照専用リクエストになる：リクエストURLが参照専用リクエストになる。

参照専用リクエストにならない：リクエストURLが参照専用リクエストにならない。

エンコードあり：URLエンコードされた文字列を含むURI。

（例：/examples/%61/Servlet）

エンコードなし：URLエンコードされた文字列を含まないURI。

（例：/examples/a/Servlet）

URIのデコード機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.23　URIのデコード機能」を参照してください。

6.13　DB Connectorの設定

データベースセッションフェイルオーバ機能を使用する場合，アプリケーションで使用するものとは別に，DB Connectorを新規に作成します。DB Connectorは，J2EEサーバごとに一つ必要です。データベースセッションフェイルオーバ機能を使用するアプリケーションは，すべて同一のDB Connectorを使用します。

DB Connectorのインポートから開始までの手順については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。

この節では，データベースセッションフェイルオーバ機能で使用するDB Connectorに必要な次の設定について説明します。

トランザクションサポートのレベルの設定

DB Connectorの別名の設定

DB Connectorの環境設定

＜この節の構成＞

6.13.1　トランザクションサポートのレベルの設定

6.13.2　DB Connectorの別名の設定

6.13.3　DB Connectorの環境設定

6.13.1　トランザクションサポートのレベルの設定

データベースセッションフェイルオーバ機能ではトランザクションサポートのレベルを設定する必要があります。Connector属性ファイルの<hitachi-connector-property>-<resourceadapter>-<outbound-resourceadapter>タグ以下の<transaction-support>タグにNoTransactionを指定します。

6.13.2　DB Connectorの別名の設定

データベースセッションフェイルオーバ機能ではDB Connectorに別名を設定する必要があります。デフォルトでは"COSMINEXUS_SFO_DBCONNECTOR"がDB Connectorに別名として設定されます。

設定する名称をデフォルトの名称から変更する場合，Connector属性ファイルの<hitachi-connector-property>-<resourceadapter>-<outbound-resourceadapter>-<connection-definition>-<connector-runtime>-<resource-external-property>タグ以下の<optional-name>タグに任意の名称を指定します。DB Connectorの別名の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

また，J2EEサーバに定義するDB Connectorの別名も同じ値に変更する必要があります。J2EEサーバのDB Connectorの別名の設定については「6.12　J2EEサーバの設定」を参照してください。

6.13.3　DB Connectorの環境設定

データベースセッションフェイルオーバ機能は24時間連続稼働を実現するための機能です。連続稼働を実現するには，データベースに障害が発生した場合もシステムに影響を与えないために，コネクションの障害検知などの設定が必要です。障害回復に必要な時間を考慮して，値を設定してください。

コネクションの障害検知については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.1　コネクションの障害検知」を参照してください。

DB Connectorに設定するプロパティおよび設定方法の詳細については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。

DB Connectorに設定が必要なプロパティについて説明します。

＜この項の構成＞

(1)　<config-property>タグで設定するプロパティ

(2)　<property>タグに指定するプロパティ

(1)　<config-property>タグで設定するプロパティ

<config-property>タグで設定するプロパティについて使用するデータベースごとに示します。なお，ここで示していないプロパティについては，データベースセッションフェイルオーバ機能に関する設定は不要です。

注意

データベースセッションフェイルオーバ機能を使用する場合，ステートメントプーリングを設定する必要があります。ステートメントプーリングは，J2EEサーバのメモリ使用量に大きく影響を与えます。そのため，コネクションプーリングの設定も考慮して，PreparedStatementPoolSizeプロパティの指定値を決定してください。

ステートメントプーリングについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.4　ステートメントプーリング」を参照してください。コネクションプーリングについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.1　コネクションプーリング」を参照してください。PreparedStatementPoolSizeプロパティに指定できる値については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.10　DB Connectorに設定する<config-property>タグに指定できるプロパティ」を参照してください。なお，ステートメント一つ当たりの使用するメモリサイズについては，JDBC関連ドキュメントを参照してください。

(a)　HiRDBを使用する場合に設定するプロパティ

HiRDBを使用する場合に設定するプロパティについて次の表に示します。

表6-53　HiRDBを使用する場合に設定するプロパティ

<config-property-name>タグに指定する値 | <config-property-type>タグに指定する値 | <config-property-value>タグに指定する内容または値 | 必須／任意
description | java.lang.String | データベースへの接続に必要な接続付加情報を指定します。 | ○
DBHostName | java.lang.String | 接続するHiRDBのホスト名を指定します。 | ○
loginTimeout | java.lang.Integer | getConnectionメソッドでConnectionオブジェクトを取得する際の，HiRDBサーバとの物理接続確立の最大待ち時間（秒）を指定します。 | △
LONGVARBINARY_Access | java.lang.String | 「LOCATOR」を指定します。 | ○
PreparedStatementPoolSize | java.lang.Integer | 30×<J2EEサーバ内のデータベースセッションフェイルオーバ機能を使用するWebアプリケーション数>で求められる数値を指定します。 | ○
CancelStatement | java.lang.Boolean | 「true」を指定します。 | ○
logLevel | java.lang.String | DB Connectorが出力するログトレースのレベルについて，任意のレベルを指定します。 | △

（凡例）　○：必須　△：任意

注意

データベースセッションフェイルオーバ機能を使用する場合，次に示すクライアント環境定義を設定すると，正常な運用を続けることができなくなります。デフォルト値のまま使用してください。

PDISLLVL（デフォルト値：2）

PDFORUPDATEEXLOCK（デフォルト値：NO）

クライアント環境定義の設定については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(b)　Oracleを使用する場合に設定するプロパティ

Oracleを使用する場合に設定するプロパティについて次の表に示します。

表6-54　Oracleを使用する場合に設定するプロパティ

<config-property-name>タグに指定する値 | <config-property-type>タグに指定する値 | <config-property-value>タグに指定する内容または値 | 必須／任意
databaseName | java.lang.String | Oracleサーバ上の特定のデータベース名（SID）を指定します。 | ○※
serverName | java.lang.String | Oracleサーバのホスト名またはIPアドレスを指定します。 | ○※
portNumber | java.lang.Integer | Oracleのサーバが要求をリスニングするポート番号を指定します。 | ○※
url | java.lang.String | Oracle JDBC Thin Driverがデータベースに接続するために必要なJDBC URLを指定します。 | ○※
loginTimeout | java.lang.Integer | データベースへの接続試行のタイムアウト（単位：ミリ秒）を指定します。 | △
PreparedStatementPoolSize | java.lang.Integer | 30×<J2EEサーバ内のデータベースセッションフェイルオーバ機能を使用するWebアプリケーション数>で求められる数値を指定します。 | ○
logLevel | java.lang.String | DB Connectorが出力するログトレースのレベルについて，任意のレベルを指定します。 | △

（凡例）　○：必須　△：任意

注※　databaseName，serverNameおよびportNumberのすべての値を指定するか，urlの値を指定してください。

(2)　<property>タグに指定するプロパティ

<property>タグで設定するプロパティについて次の表に示します。なお，ここで示していないプロパティについては，データベースセッションフェイルオーバ機能に関する設定は不要です。

<property-name>タグに指定する値
<property-type>タグに指定する値
<property-default-value>タグの値
<property-value>タグに指定する内容または値
必須／任意

MaxPoolSize
int
10
コネクションプールの最大値※1を指定します。
○

MinPoolSize
int
10
コネクションプールの最小値※1を指定します。
○

LogEnabled
boolean
true
「true」を指定します。
○

User※2
String
－
ユーザ名を指定します。
○

Password
String
－
パスワードを指定します。
○

ValidationType
int
1
「1」を指定します。
○

RetryCount
int
0
コネクション取得リトライ回数を指定します。
データベースの設定やネットワーク環境に合わせて，障害発生時にデータベースの回復が有効になるような値を指定してください。
△

RetryInterval
int
10
コネクション取得リトライ間隔を指定します。
データベースの設定やネットワーク環境に合わせて，障害発生時にデータベースの回復が有効になるような値を指定してください。
△

RequestQueueEnable
boolean
true
「true」を指定します。
○※3

RequestQueueTimeout
int
30
コネクション枯渇時のコネクション取得待ち行列のとどまることのできる最大値を指定します。※4
○※3

WatchEnabled
boolean
true
コネクションプール監視を有効にするかどうかを指定します。
△

WatchInterval
int
30
コネクションプール監視間隔を指定します。
△

WatchThreshold
int
80
コネクションプール使用状態を監視するしきい値を指定します。
△

WatchWriteFileEnabled
boolean
true
「true」を指定します。
△

（凡例）　○：必須　△：任意　－：なし

注※1

コネクションプールの値は，次の式で算出します。なお，コネクションプールの最大値と最小値は同じ値にしてください。

Webアプリケーション単位，またはURL単位の同時実行スレッド数を設定した場合

J2EEサーバ内のデータベースセッションフェイルオーバ機能を使用するWebアプリケーションの同時実行数の和＋2

J2EEサーバ単位の同時実行スレッド数を設定した場合

J2EEサーバの同時実行スレッド数＋2以上

コネクションプールの最大値を超えてJ2EEサーバがリクエストを受信すると，そのリクエストはコネクション枯渇時のコネクション取得待ち行列で待ち状態となります。

注※2

DB Connectorに設定するユーザには，テーブルの作成者を登録してください。

注※3

Webアプリケーション単位の同時実行スレッド数の制御機能が無効の場合，設定は不要です。

注※4

次に示す範囲で値を指定してください。

Webサーバ連携機能を使用している場合

1 < RequestQueueTimeout < リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウトとは，ワーカ定義ファイルのworker.<ワーカ名>.receive_timeoutキーに指定した値です。

インプロセスHTTPサーバ機能を使用している場合

1 < RequestQueueTimeout

6.14　Webアプリケーションの設定

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。データベースセッションフェイルオーバ機能の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DD（web.xml）およびcosminexus.xmlでの定義については，「6.10　cosminexus.xmlでの定義」を参照してください。

6.15　データベースセッションフェイルオーバ機能に関する設定の変更

この節では，データベースセッションフェイルオーバ機能に関する設定の変更について説明します。データベースセッションフェイルオーバ機能では，データベースのテーブルにアプリケーション情報やグローバルセッション情報などの設定情報を格納します。Webアプリケーション開始時のネゴシエーション処理で設定に誤りがないことを確認するため，一度開始したWebアプリケーションの設定を変更する場合は，データベースに保存したWebアプリケーションの設定情報の初期化が必要となります。ネゴシエーション処理については，「6.8.1　アプリケーション開始時の処理」を参照してください。

データベースセッションフェイルオーバ機能に関する設定の変更の流れを次の図に示します。

図6-14　データベースセッションフェイルオーバ機能に関する設定の変更の流れ

データベースセッションフェイルオーバ機能に関する設定を変更する場合の注意事項を次に示します。

設定変更時に停止する範囲に関する注意事項
次の設定を変更する場合は，冗長化した他のJ2EEサーバまたはアプリケーションをすべて停止してください。

完全性保障モードの設定

データベース上のグローバルセッション情報数の設定

HTTPセッションの属性情報の最大サイズの変更に関する注意事項
HTTPセッションの属性情報の最大サイズを小さく変更した場合，変更前に作成したグローバルセッション情報を引き継いだ時に，変更後の最大サイズを超えることがあります。最大サイズを超えた場合，属性情報のシリアライズ時にKDJE34320-Eのメッセージが出力され，グローバルセッション情報はデータベースに保存されません。このため，HTTPセッションの属性情報の最大サイズを小さく変更する場合は，HTTPセッションを破棄してください。HTTPセッションの破棄については，「6.15.3　グローバルセッション情報の削除（HTTPセッションの破棄）」を参照してください。

この節では，J2EEサーバおよびアプリケーションの設定変更，およびデータベーステーブルの初期化について説明します。

参考

アプリケーションの停止および開始には，サーバ管理コマンドまたは運用管理ポータルを使用します。アプリケーションの開始については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjstartapp（J2EEアプリケーションの開始）」を参照してください。アプリケーションの停止については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cjstopapp（J2EEアプリケーションの停止）」を参照してください。運用管理ポータルの操作については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「12.3　J2EEアプリケーション管理」を参照してください。

＜この節の構成＞

6.15.1　J2EEサーバおよびアプリケーションの設定変更

6.15.2　データベーステーブルの初期化

6.15.3　グローバルセッション情報の削除（HTTPセッションの破棄）

6.15.1　J2EEサーバおよびアプリケーションの設定変更

ここでは，J2EEサーバの設定，およびWebアプリケーションの設定変更の手順について説明します。設定を変更した場合，データベースに保存した情報の初期化が必要です。データベースに保存した情報の初期化については，「6.15.2　データベーステーブルの初期化」を参照してください。

＜この項の構成＞

(1)　アプリケーションの停止および設定変更

(2)　J2EEサーバの停止および設定変更

(1)　アプリケーションの停止および設定変更

アプリケーションの設定を変更するには，J2EEアプリケーションを停止して，Webアプリケーションの設定を変更します。

一つのJ2EEサーバのWebアプリケーションの設定変更終了後に，冗長化した別のJ2EEサーバのWebアプリケーションの設定を変更します。冗長化したJ2EEサーバに対して，一つずつ同じWebアプリケーションの設定変更をしていくことで，システム全体を停止することなく全体の設定を変更できます。

設定項目については，「6.10　cosminexus.xmlでの定義」，Webアプリケーションの設定変更の詳細については「6.14　Webアプリケーションの設定」を参照してください。

(2)　J2EEサーバの停止および設定変更

J2EEサーバの設定を変更するには，次の手順を実施してください。

J2EEアプリケーションを停止します。
J2EEサーバ内のすべてのJ2EEアプリケーションを停止します。

J2EEサーバを停止します。
J2EEサーバを停止します。

簡易構築定義ファイルでJ2EEサーバの設定を変更します。
簡易構築定義ファイルで設定を変更します。J2EEサーバでの設定項目については「6.12　J2EEサーバの設定」を参照してください。

冗長化した別のJ2EEサーバの設定を変更します。
冗長化した別のJ2EEサーバに対して順番に手順1.～3.を実施し，冗長化したJ2EEサーバすべてに同じ設定変更をします。

6.15.2　データベーステーブルの初期化

Webアプリケーションで使用する情報，またはWebアプリケーションに関する情報を変更した場合，データベース上に保存されたWebアプリケーションの設定情報を初期化する必要があります。ここでは，データベース上に保存された設定情報の初期化の手順について説明します。また，データベース上のグローバルセッション情報数の変更，およびデータベース上のHTTPセッションの属性情報の最大サイズの変更の手順について説明します。

＜この項の構成＞

(1)　データベースに保存された設定情報の初期化

(2)　データベース上のグローバルセッション情報数の変更

(3)　データベース上のHTTPセッションの属性情報の最大サイズの変更（HiRDBの場合だけ）

(1)　データベースに保存された設定情報の初期化

一度開始したWebアプリケーションの設定を変更した場合は，データベースに保存された設定情報を初期化する必要があります。

データベースに保存された設定情報を初期化する手順について説明します。

テンプレートファイルを任意の場所にコピーします。
データベースに保存された設定情報の初期化用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_reset_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_reset_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥oracle_reset_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_reset_apptbl.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベースに保存された設定情報の初期化用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6-55　テンプレートファイル内の変更個所と変更内容

変更個所 | 変更対象 | 変更内容
1行目 | <APPLICATION_ID> | 使用するアプリケーションのアプリケーション識別子に変更してください。

作成したデータベースに保存された設定情報の初期化用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

(2)　データベース上のグローバルセッション情報数の変更

データベース上のグローバルセッション情報数は，HTTPSessionオブジェクト数の上限値に合わせて変更します。ただし，アプリケーション開始時に実施されるネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を続行する設定にしているときは，データベース上のグローバルセッション情報数とHTTPSessionオブジェクト数の上限値の設定は異なっていてもかまいません。

データベース上のグローバルセッション情報数を変更する手順について説明します。なお，データベース上のグローバルセッション情報数を変更すると，データベース上のセッション情報はすべて削除されます。

J2EEアプリケーション，およびJ2EEサーバを停止します。
J2EEサーバ内のすべてのJ2EEアプリケーション，および冗長化したすべてのJ2EEサーバを停止します。

テンプレートファイルを任意の場所にコピーします。
データベース上のグローバルセッション情報数の変更用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_change_session_num.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_change_session_num.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥oracle_change_session_num.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_change_session_num.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベース上のグローバルセッション情報数の変更用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6-56　テンプレートファイル内の変更個所と変更内容

変更個所
変更対象
変更内容

HiRDB
Oracle

1行目

2行目

3行目

6行目

7行目

1行目

2行目

3行目

6行目

<APPLICATION_ID>
使用するアプリケーションのアプリケーション識別子に変更してください。

4行目

7行目

4行目

6行目

<HTTP_SESSION_NO>
データベース上のグローバルセッション情報数を変更してください。

作成したデータベース上のグローバルセッション情報数の変更用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

(3)　データベース上のHTTPセッションの属性情報の最大サイズの変更（HiRDBの場合だけ）

セッション情報格納テーブルを作成したあとに，Webアプリケーションに設定したグローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズを変更した場合，データベース上のHTTPセッションの属性情報の最大サイズを変更する必要があります。なお，データベース上のHTTPセッションの属性情報の最大サイズは，Webアプリケーションに設定したグローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズよりも大きい値にしてください。Webアプリケーションに設定したグローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズの設定については，「6.10　cosminexus.xmlでの定義」を参照してください。

データベース上のHTTPセッションの属性情報の最大サイズを変更する手順について説明します。この手順は，HiRDBを使用する場合だけ必要です。

J2EEアプリケーション，およびJ2EEサーバを停止します。
J2EEサーバ内のすべてのJ2EEアプリケーション，および冗長化したすべてのJ2EEサーバを停止します。

テンプレートファイルを任意の場所にコピーします。
データベース上のHTTPセッションの属性情報の最大サイズの変更用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を次に示します。
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_change_attributes_size.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_change_attributes_size.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベース上のHTTPセッションの属性情報の最大サイズの変更用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6-57　テンプレートファイル内の変更個所と変更内容

変更個所 | 変更対象 | 変更内容
1行目 | <APPLICATION_ID> | 使用するアプリケーションのアプリケーション識別子に変更してください。
2行目 | <ATTRIBUTE_DATA_SIZE_MAX> | HTTPセッションの属性情報を格納するカラムのサイズ（単位：バイト）を変更してください。

作成したデータベース上のグローバルセッション情報数の変更用SQLファイルを実行します。
SQLファイルの実行には，SQL Executerを使用してください。

6.15.3　グローバルセッション情報の削除（HTTPセッションの破棄）

システムの運用中，アプリケーションのバージョンアップをする場合などに，システム内に存在するHTTPセッションの破棄が必要となる場合があります。

データベースセッションフェイルオーバ機能では，データベースにグローバルセッション情報を格納するため，J2EEアプリケーションやJ2EEサーバの停止ではHTTPセッションが破棄できません。グローバルセッション情報をデータベースから削除することで，HTTPセッションを破棄します。

グローバルセッション情報を削除するには，次の手順を実施してください。

J2EEアプリケーションを停止します。
J2EEサーバ内のすべてのJ2EEアプリケーションを停止します。

データベース上のグローバルセッション情報を削除します。
データベース上のグローバルセッション情報数を変更する手順でグローバルセッション情報を削除します。この時，グローバルセッション情報数を変更しないで，変更手順だけを実施します。変更手順については，「6.15.2(2)　データベース上のグローバルセッション情報数の変更」を参照してください。

J2EEアプリケーションを開始します。

6.16　データベースのテーブルの削除

データベースセッションフェイルオーバ機能を使用するアプリケーションの設定を変更する際に，データベースのテーブルの削除が必要な場合があります。ここでは，データベースのテーブルの削除について説明します。

削除するテーブルと，削除手順の参照先について次の表に示します。

表6-58　削除するテーブルと，削除手順の参照先

テーブル名 | データベース上の物理名称 | 削除手順の参照先
アプリケーション情報テーブル | SFO_<APPLICATION_ID>_APP_INFO | 6.16.1
セッション情報格納テーブル | SFO_<APPLICATION_ID>_SESSIONS | 6.16.2
空きレコード情報テーブル | SFO_<APPLICATION_ID>_REC_INFO

データベースセッションフェイルオーバ機能で使用するデータベースのテーブル削除用のテンプレートファイルは次の場所に格納されています。

Windowsの場合：

<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥

UNIXの場合：

/opt/Cosminexus/CC/sfo/sql/

テーブル削除用のテンプレートファイルは使用するデータベースごとに2種類ずつあります。使用するデータベース，ファイル，および削除するテーブルの種類の対応を次の表に示します。

表6-59　テーブル削除用テンプレートファイルと削除するテーブル

使用するデータベース | テンプレートファイル | 削除するテーブルの種類
アプリケーション情報テーブル | セッション情報格納テーブル | 空きレコード情報テーブル
HiRDB | hirdb_delete_apptbl.sql | ○ | － | －
hirdb_delete_sessiontbl.sql | － | ○ | ○
Oracle | oracle_delete_apptbl.sql | ○ | － | －
oracle_delete_sessiontbl.sql | － | ○ | ○

（凡例）○：削除できる　－：削除できない

以降で，使用するデータベースごとにテンプレートファイルの詳細について示します。

＜この節の構成＞

6.16.1　アプリケーション情報テーブルの削除

6.16.2　セッション情報格納テーブルおよび空きレコード情報テーブルの削除

6.16.1　アプリケーション情報テーブルの削除

アプリケーション情報テーブルは，Webアプリケーションに設定したデータベースセッションフェイルオーバ機能に関する設定を格納するテーブルです。

アプリケーション情報テーブルの削除手順を次に示します。

テンプレートファイルを任意の場所にコピーします。
テーブル削除用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_delete_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_delete_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥oracle_delete_apptbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_delete_apptbl.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル削除用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6-60　テンプレートファイル内の変更個所と変更内容

変更個所 | 変更対象 | 変更内容
HiRDB | Oracle
1行目 | 1行目 | <APPLICATION_ID> | 使用するアプリケーションのアプリケーション識別子に変更してください。
なし | 1行目 | <SCHEMA_NAME> | データベース接続ユーザのスキーマ名に変更してください。

作成したテーブル削除用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

6.16.2　セッション情報格納テーブルおよび空きレコード情報テーブルの削除

セッション情報格納テーブルは，グローバルセッション情報を格納するテーブルです。空きレコード情報テーブルは，セッション情報格納テーブルの未使用レコードを管理するテーブルです。

セッション情報格納テーブルおよび空きレコード情報テーブルの削除手順について説明します。

テンプレートファイルを任意の場所にコピーします。
テーブル削除用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_delete_sessiontbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_delete_sessiontbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所
Windowsの場合：<Cosminexusインストールディレクトリ>¥CC¥sfo¥sql¥oracle_delete_sessiontbl.sql
UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_delete_sessiontbl.sql

テンプレートファイルを編集します。
Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル削除用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6-61　テンプレートファイル内の変更個所と変更内容

変更個所
変更対象
変更内容

HiRDB
Oracle

1行目

2行目

3行目

4行目

1行目

2行目

3行目

4行目

<APPLICATION_ID>
使用するアプリケーションのアプリケーション識別子に変更してください。

なし

1行目

2行目

3行目

4行目

<SCHEMA_NAME>
データベース接続ユーザのスキーマ名に変更してください。

作成したテーブル削除用SQLファイルを実行します。
SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

6.17　データベースセッションフェイルオーバ機能を使用時の注意事項

データベースセッションフェイルオーバ機能で使用するテーブルの内容を操作した場合，システムの情報を正しく保つことができないため，正常な運用を続けることができなくなります。
データベース上のデータベースセッションフェイルオーバ機能で使用するテーブルの変更を伴う操作として実行できるのは，次の操作だけです。なお，次の操作を実施する場合も，参照先の手順に従って操作してください。

データベースセッションフェイルオーバ機能の設定変更（6.15参照）

テーブルの初期化（6.15.2参照）

HTTPセッションの破棄（6.15.3参照）

これらの操作以外については，実行しないでください。

HTTPセッションの属性情報のサイズが最大値を超えた場合，HTTPセッションの情報はデータベースに冗長化されません。

7.　メモリセッションフェイルオーバ機能

この章では，メモリセッションフェイルオーバ機能について説明します。

＜この章の構成＞

7.1　この章の構成

7.2　メモリセッションフェイルオーバ機能の概要

7.3　前提条件

7.4　グローバルセッションを利用したセッション管理（メモリセッションフェイルオーバ機能）

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

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

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

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

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

7.10　メモリセッションフェイルオーバ機能使用時の障害検知

7.11　アプリケーションの実装

7.12　DDでの定義

7.13　cosminexus.xmlでの定義

7.14　J2EEサーバの設定

7.15　SFOサーバの設定

7.16　Webアプリケーションの設定

7.17　Webアプリケーションの設定情報の削除

7.1　この章の構成

ここでは，メモリセッションフェイルオーバ機能について説明します。この機能を使用すると，アプリケーションで実行中のセッション情報がJ2EEサーバとは別のプロセス（SFOサーバ）で管理され，J2EEサーバで障害が発生したときにそのセッション情報がほかのJ2EEサーバに引き渡されます。これによって，リクエストがほかのJ2EEサーバに転送された場合でも，障害発生前の状態で業務を続行できるようになります。

この章の構成を次の表に示します。

表7-1　この章の構成（メモリセッションフェイルオーバ機能）

分類 | タイトル | 参照先
解説 | メモリセッションフェイルオーバ機能の概要 | 7.2
前提条件 | 7.3
グローバルセッションを利用したセッション管理（メモリセッションフェイルオーバ機能） | 7.4
グローバルセッション情報のサイズの見積もり | 7.5
HTTP Cookieによるグローバルセッションの制御 | 7.6
URL書き換えによるグローバルセッションの制御 | 7.7
グローバルセッションの制御方法が混在する場合のシステム構成 | 7.8
メモリセッションフェイルオーバ機能で実施される処理 | 7.9
メモリセッションフェイルオーバ機能使用時の障害検知 | 7.10
実装 | アプリケーションの実装 | 7.11
DDでの定義 | 7.12
cosminexus.xmlでの定義 | 7.13
設定 | J2EEサーバの設定 | 7.14
SFOサーバの設定 | 7.15
Webアプリケーションの設定 | 7.16
Webアプリケーションの設定情報の削除 | 7.17

注　「運用」および「注意事項」について，この機能固有の説明はありません。

7.2　メモリセッションフェイルオーバ機能の概要

メモリセッションフェイルオーバ機能は，セッション情報をSFOサーバに冗長化し，システムの可用性を高めるための機能です。

ここでは，メモリセッションフェイルオーバ機能の処理の概要，および適用手順の概要を説明します。

＜この節の構成＞

7.2.1　処理の概要

7.2.2　適用手順

7.2.1　処理の概要

メモリセッションフェイルオーバ機能を使用すると，リクエストによるセッションの生成処理が発生したときに，引き継ぎ対象に指定したセッション情報をSFOサーバに冗長化できます。そのため，J2EEサーバまたはWebサーバで障害が発生した場合も，ほかのJ2EEサーバでSFOサーバに格納されているセッション情報を基にセッションを再生成し，正常に業務を続行できます。

なお，SFOサーバで障害が発生した場合は，すべてのセッション情報は削除されます。また，SFOサーバでの障害発生後にリクエストを受け付けた場合は，SFOサーバへのセッション情報の冗長化は実施されません。

セッション情報の格納の流れ，および障害が発生した場合の処理について説明します。

＜この項の構成＞

(1)　セッション情報の格納の流れ

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

(1)　セッション情報の格納の流れ

メモリセッションフェイルオーバ機能を使用すると，リクエストによるセッションの作成処理が発生したときに，処理の延長上でセッション情報がSFOサーバに格納されます。

セッション情報の格納の流れを次の図に示します。

図7-1　セッション情報の格納の流れ

Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます（1.）。セッションの作成処理の延長上で，セッション情報が作成され（2.），セッション情報がSFOサーバに格納されます（3.）。

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

WebサーバまたはJ2EEサーバで障害が発生した場合，SFOサーバに格納されているセッション情報を基に，ほかのJ2EEサーバでセッションを再作成し，正常に業務を続行できます。

WebサーバまたはJ2EEサーバで障害が発生した場合の処理について，次の図に示します。

図7-2　WebサーバまたはJ2EEサーバで障害が発生した場合の処理

Webサーバ1／J2EEサーバ1で障害が発生すると，負荷分散機によってWebサーバ2へリクエストが転送されます（1.）。転送先のJ2EEサーバ2でリクエストを処理するとき，リクエストに関連づけられたセッションが存在しないため，SFOサーバからセッション情報を取得して（2.），セッションを再作成します（3.）。

セッションが正常に引き継がれ，障害発生前の状態で業務を続行できます。

7.2.2　適用手順

メモリセッションフェイルオーバ機能を使用する場合に必要な，環境構築の準備と各種設定について説明します。

＜この項の構成＞

(1)　環境構築の準備

(2)　必要な設定

(1)　環境構築の準備

メモリセッションフェイルオーバ機能を使用する場合に環境構築の準備として実施する項目について，実施内容および参照先を次の表に示します。

表7-2　メモリセッションフェイルオーバ機能を使用する環境構築の準備として実施する項目の実施内容および参照先

実施順序 | 実施項目 | 実施内容 | 参照先
1 | 前提条件の確認 | 前提となる構成および設定を確認します。 | 7.3
2 | グローバルセッション情報のサイズの見積もり | グローバルセッション情報のサイズを見積もります。見積もった値はWebアプリケーションの設定（グローバルセッション情報の最大サイズの設定）で必要になります。 | 7.5

(2)　必要な設定

メモリセッションフェイルオーバ機能を使用したシステムを構築する場合，J2EEサーバ，SFOサーバ，およびWebアプリケーションの設定が必要です。また，Webサーバ連携を使用し，かつURL書き換えを使用する場合，Webサーバの設定が必要です。

メモリセッションフェイルオーバ機能を使用する場合に必要な設定について，設定内容および参照先を次の表に示します。

表7-3　メモリセッションフェイルオーバ機能使用時に必要な設定項目の設定内容および参照先

設定順序
設定項目
設定内容
参照先

1
Webアプリケーションの設定※
Webアプリケーションの設定は，DD（web.xml）およびcosminexus.xmlに定義します。

DDに定義する項目

フィルタマッピング定義

グローバルセッション情報に関する設定

cosminexus.xmlに定義する項目

フィルタ定義

7.12，7.13

2
J2EEサーバの設定（必須）
次の設定をします。

グローバルセッション情報を格納するSFOサーバの設定

SFOサーバとの通信タイムアウトの設定

リクエストラインの最大サイズの設定（URL書き換えを使用し，かつインプロセスHTTPサーバを使用する場合）

7.14，7.7.5

3
SFOサーバの設定（必須）
次の設定をします。

SFOサーバの基本設定

SFOサーバの起動オプションの設定

7.15

4
Webサーバの設定
リクエストラインの最大サイズの設定をします（Webサーバ連携を使用し，かつURL書き換えを使用する場合）。
7.7.5

注※　Webアプリケーションの設定は開発環境で実施します。実行環境で属性ファイルを使用したWebアプリケーションの設定をしたい場合は「7.16　Webアプリケーションの設定」を参照してください。

SFOサーバに登録したWebアプリケーションの設定情報を削除する方法については，「7.17　Webアプリケーションの設定情報の削除」を参照してください。

7.3　前提条件

メモリセッションフェイルオーバ機能を利用するための前提条件について説明します。

＜この節の構成＞

7.3.1　前提となる構成

7.3.2　前提となる設定

7.3.1　前提となる構成

メモリセッションフェイルオーバ機能を使用するには，負荷分散機の使用が前提となります。メモリセッションフェイルオーバ機能は，負荷分散機を使用した，複数のJ2EEサーバにリクエストを振り分けるシステム構成の場合に使用できます。

負荷分散機の使用については，「5.2.3　セッションフェイルオーバ機能の前提条件」を参照してください。

メモリセッションフェイルオーバ機能を使用するためのシステム構成については，次の個所を参照してください。

マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.10.2　SFOサーバがシステムに複数存在する構成（メモリセッションフェイルオーバ機能）」

マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.10.3　SFOサーバがシステムに一つだけ存在する構成（メモリセッションフェイルオーバ機能）」

7.3.2　前提となる設定

メモリセッションフェイルオーバ機能を使用するためには，次の設定が必要です。

前提機能の設定

HttpSessionオブジェクト数の上限値の指定機能
有効となるHttpSessionオブジェクトの数に上限値を設定する機能です。なお，メモリセッションフェイルオーバ機能を使用する場合は，上限値に，1以上の有効な値を設定する必要があります。HttpSessionオブジェクト数の上限値の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。
なお，開発環境でグローバルセッション情報のサイズ見積もり機能を有効にする場合，HttpSessionオブジェクト数の上限値の指定は不要です。グローバルセッション情報のサイズ見積もり機能については，「7.5　グローバルセッション情報のサイズの見積もり」を参照してください。

セッションIDへのサーバIDの付加機能
HttpSessionのセッションIDに，Webコンテナごとに異なるサーバIDを付加する機能です。セッションIDへのサーバIDの付加については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

HTTPセッションのスティッキー（Sticky）の設定
メモリセッションフェイルオーバ機能を使用するには，負荷分散機にHTTPセッションのスティッキーを設定する必要があります。
HTTPセッションのスティッキーを設定しない場合，HTTPセッションを保持したリクエストの振り分け先が固定されません。そのため，HTTPセッションを保持したリクエストを受け付けるたびにHTTPセッションの引き継ぎ処理が実施され，性能が劣化するおそれがあります。

7.4　グローバルセッションを利用したセッション管理（メモリセッションフェイルオーバ機能）

メモリセッションフェイルオーバ機能を使用する場合，グローバルセッション情報は，SFOサーバで管理されます。SFOサーバとは，システム内のグローバルセッション情報を管理するためのJ2EEサーバです。

セッション情報の引き継ぎの流れについて次の図で説明します。

図7-3　セッション情報引き継ぎの流れ（メモリセッションフェイルオーバ機能）

J2EEサーバ1でHTTPセッションの生成後，グローバルセッション情報はSFOサーバに格納されます。

J2EEサーバ1に障害が発生すると，処理を引き継いだJ2EEサーバ2では，SFOサーバに対して，グローバルセッションIDを基にグローバルセッション情報の取得を要求します。
グローバルセッションIDとは，グローバルセッション情報を一意に識別するためのIDです。

J2EEサーバ2では，セッションに対するリクエスト処理を開始する際に，グローバルセッション情報の同期をとるため，グローバルセッション情報に対してロックを掛けます。

SFOサーバは，J2EEサーバ2にグローバルセッション情報を渡します。

J2EEサーバ2でのリクエスト処理が完了すると，リクエスト処理で更新されたグローバルセッション情報は，SFOサーバに送信されます。

SFOサーバ側で，グローバルセッション情報が更新されます。

ロックが解除されます。

流れの中で出てきた項目について，以降の項で説明します。

＜この節の構成＞

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

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

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

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

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

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

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

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

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

グローバルセッションIDとは，グローバルセッションを管理するためのIDです。グローバルセッションIDによって，システム内でグローバルセッション情報を一意に識別できます。グローバルセッションIDは，HttpSessionオブジェクトが作成されるごとに，HTTPセッションIDに関連づけて発行されます。J2EEサーバに障害が発生し，セッション情報が引き継がれるときにも，グローバルセッションIDが変わることはありません。

グローバルセッションIDは，グローバルセッションIDの発行時刻，およびHTTPセッションIDで構成されています。

グローバルセッションIDの形式を次の図に示します。

図7-4　グローバルセッションIDの形式

グローバルセッションIDの発行時刻は，GMT（グリニッジ標準時）の1970年1月1日0時からの通算ミリ秒数（8バイトのデータを16進数で表現したもの）です。J2EEサーバで障害が発生したときに，障害発生前と障害発生後に作成されたグローバルセッションIDを必ず一意にするために付加されています。

HTTPセッションIDは，J2EEサーバ内で一意な文字列と，サーバIDで構成されています。サーバIDとは，セッションIDへのサーバID付加機能で設定されるIDです。セッションIDへのサーバID付加機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

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

メモリセッションフェイルオーバ機能を使用する場合，グローバルセッション情報はSFOサーバで管理されます。

SFOサーバでグローバルセッション情報として保持するセッション情報には，次の設定ができます。

グローバルセッション情報として引き継ぐセッション情報の範囲

グローバルセッション情報として指定できるセッション情報のデータ型

グローバルセッション情報の種別（書き換え可能にするかまたは読み込み専用にするか）

これらの設定は，セッションフェイルオーバ用フィルタに設定します。設定については，「7.12　DDでの定義」を参照してください。

次に，各設定内容について説明します。

＜この項の構成＞

(1)　グローバルセッション情報として引き継ぐセッション情報の範囲

(2)　グローバルセッション情報として指定できるセッション情報のデータ型

(3)　引き継ぎ対象外のオブジェクトの扱い

(4)　グローバルセッション情報の種別

(5)　SFOサーバでのグローバルセッション情報の管理方法

(1)　グローバルセッション情報として引き継ぐセッション情報の範囲

SFOサーバでは，引き継ぎ対象として選択したセッション情報だけがグローバルセッション情報として保持されます。グローバルセッション情報として選択できるセッション情報は，HTTPセッションに登録された一部，またはすべてです。引き継ぎ対象として選択するセッション情報は，グローバルセッション情報の種別ごとに指定できます。グローバルセッション情報の種別については，「(4)　グローバルセッション情報の種別」を参照してください。

グローバルセッション情報選択時の注意事項

パフォーマンス向上のために，グローバルセッション情報には，必要最低限のHTTPセッション情報を指定してください。

(a)　HTTPセッションに登録された一部のセッション情報を引き継ぐ場合

HTTPセッションに登録されたセッション情報のうち，一部のセッション情報をグローバルセッション情報として引き継ぐ場合には，あらかじめ，DD（web.xml）で引き継ぎ対象とするセッション情報のキー名称を指定する必要があります。この場合，Webアプリケーション内で動的にキー名称を作成するセッション情報をグローバルセッションとして指定することはできません。

HTTPセッションに登録された一部のセッション情報を引き継ぐ例を次の図に示します。

図7-5　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)　データ型選択時の注意事項

セッション情報が直列化可能クラスのオブジェクトである場合，グローバルセッション情報の更新，および引き継ぎ処理で，オブジェクトのシリアライズまたはデシリアライズ処理が必要になります。シリアライズ処理は，引き継ぎ対象のオブジェクトだけでなく，このオブジェクトから参照されるオブジェクトすべてを対象とします。このため，引き継ぐ必要がない情報を含むクラスの場合，性能が低下することがあります。

シリアライズ処理の対象範囲の例を次の図に示します。

図7-6　シリアライズ処理の対象範囲の例

この図では，HTTPセッションに登録されたオブジェクト（1～3）にフィールドとして含まれているオブジェクト（a～e）も，シリアライズ処理の対象に含まれます。

パフォーマンス向上のためには，グローバルセッション情報をjava.lang.Stringクラスまたはbyte型配列のオブジェクトに限定することをお勧めします。

(3)　引き継ぎ対象外のオブジェクトの扱い

グローバルセッション情報として引き継ぎ対象外となるオブジェクトがHTTPセッションに登録された場合の扱いについて説明します。引き継ぎ対象とするセッション情報のデータ型および範囲の設定によって，オブジェクトの扱いが異なります。

また，直列化可能クラスのオブジェクトの場合，セッション情報の引き継ぎ時にシリアライズ処理またはデシリアライズ処理を実施します。これらの処理に成功するかどうかによってもオブジェクトの扱いが異なります。

(a)　java.lang.Stringクラスまたはbyte型配列のオブジェクトが引き継ぎ対象である場合

リクエスト処理完了時点で，HTTPセッションにjava.lang.Stringクラスまたはbyte型配列以外のオブジェクトが登録されている場合，引き継ぎ対象とするセッション情報の範囲の設定によって，セッション情報を引き継ぐかどうかが異なります。HTTPセッションに引き継ぎ対象外のオブジェクトが登録されている場合のセッション情報の引き継ぎ可否を次の表に示します。

表7-4　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セッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否を次の表に示します。

表7-5　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セッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否を次の表に示します。

表7-6　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サーバからグローバルセッション情報を取得します。この時，グローバルセッション情報のデシリアライズ処理を実施します。デシリアライズ処理によるグローバルセッション情報の引き継ぎ可否を次の表に示します。

表7-7　デシリアライズ処理によるグローバルセッション情報の引き継ぎ可否

項番
デシリアライズの成功/失敗
引き継ぎ先の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）で指定します。メモリセッションフェイルオーバ機能を使用する場合に必要な定義については，「7.12.1　DDの作成」を参照してください。また，開発環境でグローバルセッション情報のサイズを見積もる場合には，グローバルセッション情報のサイズ見積もり機能が使用できます。グローバルセッション情報のサイズ見積もり機能については，「7.5　グローバルセッション情報のサイズの見積もり」を参照してください。

また，デプロイ後のWebアプリケーションの場合，Webアプリケーションを含むJ2EEアプリケーションの属性（プロパティ）として設定できます。デプロイ後のWebアプリケーションのセッションフェイルオーバ用フィルタの設定については，「7.12　DDでの定義」を参照してください。

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

ここでは，グローバルセッションを利用するためのシステム構成要素である，次のサーバプロセス，アプリケーションおよびフィルタについて説明します。

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サーバを複数配置することもできます。

注※

削除されるのは，書き換え可能グローバルセッション情報です。読み込み専用のグローバルセッション情報は削除されません。書き換え可能，および読み込み専用のグローバルセッション情報については，「7.4.2　グローバルセッション情報」を参照してください。

SFOサーバを複数配置するときの推奨構成

SFOサーバを複数配置する構成では，J2EEサーバごとにSFOサーバを配置するのではなく，J2EEサーバ内のWebアプリケーションごとにSFOサーバを割り当てることをお勧めします。これによって，SFOサーバに障害が発生した場合の影響範囲を，障害が発生したSFOサーバを使用していたWebアプリケーションだけにとどめることができます。配置例を次の図に示します。

図7-7　複数の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サーバで障害が発生したときに，管理しているセッション情報をほかのJ2EEサーバに引き継ぎます。セッションフェイルオーバ用フィルタでは，セッション情報を管理し，J2EEサーバ間のセッションの情報を引き継ぐために，次の内容を設定します。

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

グローバルセッション情報の最大サイズ

グローバルセッション情報を格納するSFOサーバの名称

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

グローバルセッションIDの送信に使用するCookieの名称

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

グローバルセッション情報のロック待ちタイムアウト

byte型配列であるセッション情報の引き継ぎ許可

直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可

セッションフェイルオーバ用フィルタは，メモリセッションフェイルオーバ機能の対象にするJ2EEアプリケーションに追加して使用します。

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

ここでは，メモリセッションフェイルオーバ機能を使用できるセッションの条件と，サーバ障害が発生したときのグローバルセッション情報の引き継ぎについて説明します。

メモリセッションフェイルオーバ機能では，次の二つの条件を満たしているセッションの場合に，グローバルセッション情報が引き継がれます。

SFOサーバが正常に稼働している状態で作成されたセッションであること。

障害が発生した場所がクライアントから送信されるリクエストの間で，どのJ2EEサーバからも使用されていないセッションであること。

これらの条件を満たしていない場合は，グローバルセッション情報は引き継がれず，破棄されます。

また，障害発生時にJ2EEサーバで使用しているセッションについても，グローバルセッション情報は引き継がれません。障害が発生したJ2EEサーバで処理されていたリクエストは，エラーとしてクライアントに返され，セッションが切断されます。

次に，Webサーバ，J2EEサーバ，SFOサーバで障害が発生したときの，リクエストの処理位置による，グローバルセッション情報の引き継ぎの有無について説明します。

＜この項の構成＞

(1)　Webサーバで障害が発生した場合

(2)　J2EEサーバで障害が発生した場合

(3)　SFOサーバで障害が発生した場合

(1)　Webサーバで障害が発生した場合

Webサーバで障害が発生した場合，障害発生時のリクエストの処理の位置にかかわらず，リクエスト自体は正常に処理され，グローバルセッション情報が引き継がれます。障害発生時のリクエストの処理位置と，グローバルセッション情報の引き継ぎについて次の図に示します。

図7-8　障害発生時のリクエストの処理位置とグローバルセッション情報の引き継ぎ（Webサーバでの障害発生の場合）

クライアントへのレスポンスについて

図中の項番1.，2.，4.，5.，6.，7.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスはエラーとなります。

図中の項番3.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスは正常に返ります。

(2)　J2EEサーバで障害が発生した場合

J2EEサーバで障害が発生した場合，障害発生時のリクエストの処理の位置がJ2EEサーバ上にあるときは，グローバルセッション情報が破棄され，引き継ぎできません。障害発生時のリクエストの処理位置と，グローバルセッション情報の引き継ぎについて次の図に示します。

図7-9　障害発生時のリクエストの処理位置とグローバルセッション情報の引き継ぎ（J2EEサーバでの障害発生の場合）

クライアントへのレスポンスについて

図中の項番1.，4.，5.，6.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスはエラーとなります。

図中の項番2.，3.，7.のリクエスト処理中に障害が発生した場合
クライアントへのレスポンスは正常に返ります。

(3)　SFOサーバで障害が発生した場合

SFOサーバで障害が発生した場合，グローバルセッションはすべて切断されます。また，SFOサーバでの障害発生後のリクエストは，書き換え可能グローバルセッション情報は破棄されて，処理されます。

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

サーバの停止時，およびサーバの障害発生時のセッション情報の引き継ぎについて説明します。

ここでは，次の状態の場合のセッション情報の引き継ぎについて説明します。

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サーバにない場合の例です。

図7-10　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サーバ障害発生時のグローバルセッション情報の削除処理の動作を次の図で説明します。

図7-11　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サーバに障害が発生したあとのグローバルセッション情報について，種類ごとに説明します。なお，グローバルセッションの種類の概要については，「7.4.2　グローバルセッション情報」を参照してください。

書き換え可能グローバルセッション情報の場合

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サーバに格納されます。

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

ここでは，グローバルセッションの制御方法について説明します。

＜この項の構成＞

(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を使用します。これによって，グローバルセッションの制御を実現します。

使用するクライアントの種類などに応じて，適切な制御方法を選択してください。それぞれの制御方法の詳細については，「7.6　HTTP Cookieによるグローバルセッションの制御」および「7.7　URL書き換えによるグローバルセッションの制御」を参照してください。

制御方法は，セッションフェイルオーバ用フィルタに設定します。設定方法については，「7.12　DDでの定義」を参照してください。

参考

両方の制御方法を使用する設定をしている場合に，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セッションは継続されます。

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

ここでは，SFOサーバで管理しているグローバルセッション情報の排他制御について説明します。

メモリセッションフェイルオーバ機能では，複数のJ2EEサーバから同じグローバルセッション情報を同時に更新されることを抑止するために，ロックを使用して排他制御を実現します。

J2EEサーバは，セッションに対するリクエスト処理を開始するときに，SFOサーバ上のグローバルセッション情報にロックを設定します。また，リクエスト処理が完了した時点でロックを解除します。

別のJ2EEサーバによってすでにロックが設定されているグローバルセッション情報をロックしようとした場合は，設定されているロックが解除されるまで，処理が待たされます。これを，ロック待ちといいます。

なお，ロック待ちには，タイムアウト時間を設定できます。タイムアウトが発生した場合，J2EEサーバは，該当するグローバルセッション情報が使用できないものと判断します。この場合，J2EEサーバは，SFOサーバ上の書き換え可能グローバルセッション情報を破棄して，J2EEアプリケーションを呼び出し，リクエスト処理を実行します。

ロック待ちのタイムアウト時間は，Webアプリケーション単位で設定できます。設定方法については，「7.12.1　DDの作成」を参照してください。

参考

異なるJ2EEサーバに振り分けられた場合，グローバルセッション情報のロック機能を使用して，更新業務を実行するJ2EEアプリケーションの排他制御も実現できます。

更新業務を実行するJ2EEアプリケーションでは，ダブルクリックなどによってリクエストが二重に送信されると，正常に処理が実行できなくなる場合があります。このため，J2EEアプリケーションでは，セッションなどを利用して，このような場合に二重に処理するのを抑止する必要があります。

メモリセッションフェイルオーバ機能を使用している場合，ダブルクリックなどによって二重送信されたリクエストが異なるJ2EEサーバに送信されたときには，グローバルセッション情報のロック設定時にロック待ちが発生します。これによって，処理が二重に実施されるのを防げます。

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

SFOサーバで管理できるグローバルセッション情報の最大数は，SFOサーバと接続しているWebアプリケーションのHttpSessionオブジェクト数の上限値となります。

WebアプリケーションのHttpSessionオブジェクト数の上限値と，SFOサーバで管理できるグローバルセッション情報の最大数の関係を次の図に示します。

図7-12　SFOサーバで管理できるグローバルセッション情報の最大数

図のように，各Webアプリケーションの，HttpSessionオブジェクト数の上限値に1,000が設定されている場合，SFOサーバで管理できるグローバルセッション情報の最大数も1,000となります。

しかし，実際にはSFOサーバは，複数のJ2EEサーバで生成されたHTTPセッションを一括して管理するため，WebアプリケーションのHttpSessionオブジェクト数の上限値に達する前に，SFOサーバ内のグローバルセッション情報の数が最大数に達することがあります。次の図で説明します。

図7-13　HttpSessionオブジェクト数の上限とSFOサーバのグローバルセッション情報の最大数との関係

SFOサーバで管理するグローバルセッション情報の数は，各WebアプリケーションのHttpSessionオブジェクト数の合計となるため，図のように，WebアプリケーションのHttpSessionオブジェクト数が上限値に達していなくても，SFOサーバのグローバルセッション情報の数が最大数に達する場合があります。このとき，J2EEサーバ上のJ2EEアプリケーション内で，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドを呼び出すと，IllegalStateExceptionが送出されます。

なお，HttpSessionオブジェクト数の上限値設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。

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

ここでは，グローバルセッション情報を見積もるための機能について説明します。

グローバルセッション情報のサイズは，あらかじめ最大サイズを見積もって，DD（web.xml）に定義する必要があります。しかし，次の場合，セッション情報のサイズを見積もることは困難です。

直列化可能クラスのオブジェクトの場合，HTTPセッションに登録されたオブジェクトをシリアライズして作成される。

java.lang.Stringクラスのオブジェクトの場合，データの内容が非ASCII文字を含むときは，文字種によって文字列長が変わる。

グローバルセッション情報のサイズ見積もり機能は，開発環境でグローバルセッション情報のサイズを見積もるための機能です。グローバルセッション情報を作成してそのサイズをWebサーブレットログに出力します。この機能は開発環境で使用してください。このとき，SFOサーバのセットアップや設定，およびJ2EEサーバでの設定は不要です。

注意

グローバルセッション情報のサイズ見積もり機能は，運用環境では使用しないでください。この機能を使用すると，セッション情報の引き継ぎは無効となり，メモリセッションフェイルオーバ機能が有効になりません。グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理については，「7.5.3　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理」を参照してください。

＜この節の構成＞

7.5.1　グローバルセッション情報のサイズ見積もり機能を有効にするための設定（見積もり時に使用する設定）

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

7.5.3　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理

7.5.4　グローバルセッション情報のサイズ見積もり機能使用時の注意事項

7.5.1　グローバルセッション情報のサイズ見積もり機能を有効にするための設定（見積もり時に使用する設定）

グローバルセッション情報のサイズ見積もり機能を有効にする場合は，簡易構築定義ファイルと，DD（web.xml）で設定が必要になります。

簡易構築定義ファイルでのグローバルセッション情報のサイズ見積もり機能を有効にする設定
論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，webserver.sfo.check_size.modeパラメタに「on」を設定します。グローバルセッション情報のサイズ見積もり機能を無効にする場合は，このパラメタに「off」を設定してください。簡易構築ファイルおよび指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。
グローバルセッション情報のサイズ見積もり機能を使用する場合の簡易構築定義ファイルのパラメタの設定要否を次の表に示します。

表7-8　グローバルセッション情報のサイズ見積もり機能を使用する場合の簡易構築定義ファイルのパラメタの設定要否

簡易構築定義ファイルのパラメタ | パラメタの設定要否
webserver.sfo.sfo_servers | 無効※
webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.naming | 無効※
webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.connectionTimeout | 無効※
webserver.sfo.check_size.mode | 必須
webserver.session.server_id.enabled | 任意
webserver.session.server_id.value | 任意
webserver.container.server_id.enabled | 任意
webserver.container.server_id.name | 任意
webserver.container.server_id.value | 任意
webserver.connector.inprocess_http.limit.max_request_line | 任意

（凡例）

必須：必ず指定することを示す。省略した場合はエラーとなり，SFOサーバ用アプリケーションを開始できない。

無効：指定しても無効になることを示す。設定した値は使用されない。

任意：省略できることを示す。省略した場合はデフォルトの値が設定される。

注※

パラメタに設定した値は読み込みまれません。このため，不正な値を設定した場合も検出されません。

参考

Smart Composer機能を使用しない場合に，グローバルセッション情報のサイズ見積もり機能を有効にするときは，J2EEサーバ用ユーザプロパティファイル（usrconf.properties）でwebserver.sfo.check_size.modeキーに「on」を設定します。webserver.sfo.check_size.modeキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.4　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

DD（web.xml）でのセッションフェイルオーバ用フィルタの定義
メモリセッションフェイルオーバ機能の設定をします。DD（web.xml）でのセッションフェイルオーバ用フィルタの定義については，「7.12.1　DDの作成」を参照してください。グローバルセッション情報のサイズ見積もり機能では，DD（web.xml）に定義したメモリセッションフェイルオーバ機能の設定を基にグローバルセッション情報が作成されます。

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

この機能を使用すると，メモリセッションフェイルオーバ機能が有効なWebアプリケーションに対してリクエストを送信するたびに，グローバルセッション情報のサイズを示すメッセージがWebサーブレットログに出力されます。グローバルセッション情報のサイズを出力するメッセージを次の表に示します。

表7-9　グローバルセッション情報のサイズを出力するメッセージ

メッセージ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）に出力される内容の詳細については，表7-10を参照してください。また，各メッセージの詳細については，マニュアル「Cosminexus アプリケーションサーバ メッセージ 2」を参照してください。

注※　クラス名に出力される内容は，属性値に対してjava.lang.ClassクラスのgetName()メソッドで得られた文字列です。なお，KDJE34261-Iのメッセージは，引き継ぎの対象であるセッション情報がHTTPセッションにない場合は出力されません。また，KDJE34260-Iのメッセージは，引き継ぎの対象であるセッション情報がHTTPセッションにあるかどうかに関係なく，HTTPセッションがあれば出力されます。

これらのメッセージに出力されるサイズ（size（byte））の値を基に，グローバルセッション情報のサイズを見積もります。見積もった値が，SFOサーバで冗長化できるグローバルセッション情報のサイズのデフォルト値（1,024バイト）を超えている場合は，DD（web.xml）でグローバルセッション情報の最大サイズの設定を変更する必要があります。グローバルセッション情報の最大サイズの設定方法については，「7.12.2(2)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）」を参照してください。

なお，KDJE34260-IおよびKDJE34261-Iのメッセージに出力されるサイズの値は，直列化可能クラスのオブジェクトを引き継ぎ対象としているかどうかによって異なります。KDJE34260-IおよびKDJE34261-Iのメッセージに出力されるサイズ（size（byte））の詳細を次の表に示します。

表7-10　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型配列であるセッション情報が引き継ぎ対象の場合にだけ含まれます。

7.5.3　グローバルセッション情報のサイズ見積もり機能使用時に無効となる処理

グローバルセッション情報のサイズ見積もり機能を使用すると，グローバルセッション情報は作成しますが，セッション情報の引き継ぎ処理は無効となります。この場合，SFOサーバにセッション情報が冗長化されません。このほかにも，メモリセッションフェイルオーバ機能で実行する処理で無効となるものがあります。グローバルセッション情報のサイズ見積もり機能使用時に，無効となる処理を次に示します。

J2EEサーバとSFOサーバとのネゴシエーション処理

SFOサーバへのグローバルセッション情報の冗長化

グローバルセッション情報の引き継ぎ処理

7.5.4　グローバルセッション情報のサイズ見積もり機能使用時の注意事項

グローバルセッション情報のサイズ見積もり機能使用時の注意事項を次に示します。

メモリセッションフェイルオーバ機能で引き継ぎ可能なサイズの上限は，HTTPセッションの有効期間情報などのサイズを含めて，1,048,576（1M）バイトです。グローバルセッション情報のサイズ見積もり機能使用時に，この上限値を超えた場合は，KDJE34262-Eのメッセージが出力されます。それ以降のグローバルセッション情報の作成処理は中断されます。この場合，KDJE34260-Iのメッセージは出力されません。メッセージについては，マニュアル「Cosminexus アプリケーションサーバ メッセージ 2」を参照してください。

グローバルセッション情報のサイズ見積もり機能を有効にしている場合は，DD（web.xml）のGSInfosLengthMaxパラメタで，グローバルセッション情報の最大サイズを指定しても無視されます。このため，この機能を無効にして運用を開始する前に，KDJE34260-Iのメッセージに出力されたグローバルセッション情報のサイズが，GSInfosLengthMaxパラメタで指定したサイズを超えていないことを確認する必要があります。GSInfosLengthMaxパラメタについては，「7.12.2(2)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）」を参照してください。メッセージについては，マニュアル「Cosminexus アプリケーションサーバ メッセージ 2」を参照してください。

グローバルセッション情報のサイズ見積もり機能を使用すると，Webアプリケーション開始時にJ2EEサーバとSFOサーバとのネゴシエーション処理は実行されません。このため，KDJE34216-Iのメッセージ（SFOサーバとの接続開始），およびKDJE34205-Iのメッセージ（SFOサーバとの接続完了）は出力されません。これらのメッセージの代わりに，KDJE34263-Iのメッセージ（グローバルセッション情報の冗長化無効）がエラーレベルで出力されます。各メッセージについては，マニュアル「Cosminexus アプリケーションサーバ メッセージ 2」の「3.　KDJE30000からKDJE39999までのメッセージ」を参照してください。

同じHTTPセッションを使用する複数のリクエストを同時に送信した場合，処理中のリクエスト処理スレッドがあるときはグローバルセッション情報が作成されません。このため，グローバルセッション情報のサイズは見積もりません。この場合，最後のリクエスト処理スレッドが処理を終えた時にグローバルセッション情報のサイズを見積もって，メッセージを出力します。

グローバルセッション情報のサイズ見積もり機能を有効にする場合，HttpSessionオブジェクト数の上限値の指定は不要です。HttpSessionオブジェクト数の上限値の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。

グローバルセッション情報のサイズ見積もり機能を有効にする場合，J2EEサーバが使用するメモリ量が増加します。J2EEサーバが使用するメモリ増加量を求める式を次に示します。

J2EEサーバが使用するメモリ増加量（メガバイト）
　＝10×1.5＋1.5※

注※　Webコンテナ単位の最大同時実行スレッド数が10以上の場合は，「Webコンテナ単位の最大同時実行スレッド数×1.5＋1.5」となります。Webコンテナ単位の最大同時実行スレッド数については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.16　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

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

この節では，HTTP Cookieによるグローバルセッションの制御について説明します。

＜この節の構成＞

7.6.1　HTTP Cookieによる制御の概要

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

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

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

7.6.5　HTTP Cookieの有効期限

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

7.6.1　HTTP Cookieによる制御の概要

HTTP Cookieによる制御では，WebクライアントからJ2EEサーバにリクエストを送信するときに，グローバルセッションIDを示すHTTP Cookieを送信します。

グローバルセッションIDは，HTTPレスポンスヘッダのSet-Cookieヘッダに設定され，Webクライアントに送信されます。この情報は，Webクライアントで，Cookie情報として管理されます。

J2EEサーバでは，グローバルセッションIDを含むHTTP Cookieを送信してきたWebクライアントに対して，グローバルセッションを継続します。

HTTP Cookieによるグローバルセッションの制御の概要を次の図に示します。

図7-14　HTTP Cookieによるグローバルセッションの制御の概要

Webクライアントからのリクエストを受信すると，J2EEサーバのJ2EEアプリケーション（Servlet／JSP）内で，HTTPセッションオブジェクトの作成とともに，グローバルセッションIDが発行されます。発行されたグローバルセッションIDは，Webクライアントに送信されるHTTPレスポンスヘッダに設定されます。同時に，SFOサーバに，グローバルセッション情報とともに格納されます。

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

HTTP Cookieによってグローバルセッションを制御する場合，Webクライアントとして，HTTP Cookieを使用できるクライアントが必要です。また，Webクライアントのブラウザでは，HTTP Cookieセッションを有効にする必要があります。

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

グローバルセッションIDは，HTTPレスポンスヘッダのSet-Cookieヘッダに設定されます。使用されるHTTP Cookieの名称は，Webアプリケーション単位に設定できます。デフォルトの設定の場合，「GSESSIONID」になります。設定方法については，「7.14　J2EEサーバの設定」を参照してください。

注意

グローバルセッションIDを送信するHTTP Cookieの名称には，次の名称は指定できません。なお，大文字と小文字は区別されません。

HTTPセッションのセッションIDで使用するHTTP Cookieの名称である「JSESSIONID」

J2EEサーバのサーバID付加機能によってサーバIDを付加したHTTP Cookieの名称と同じ名称
サーバID付加機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

これらと同じ名称を使用すると，セッションフェイルオーバ用フィルタの初期化処理でエラーとなり，アプリケーションが開始できなくなります。なお，セッションフェイルオーバ用フィルタの初期化処理については，「7.9.3　J2EEアプリケーション開始時の処理」を参照してください。

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

グローバルセッションIDが使用するHTTP Cookieの名称は，Webアプリケーション開始時に，サーブレットコンテキストの属性として，「com.cosminexus.software.was.sfo.GIDCookieName」の名称で登録されます。このとき，Webアプリケーションに，javax.servlet.ServletContextAttributeListenerインタフェースを実装したクラスが登録されていた場合，attributeAddedメソッドが呼び出されます。

7.6.5　HTTP Cookieの有効期限

グローバルセッションIDの送信に使用するHTTP Cookieの有効期限には，デフォルト値である-1が設定されています。このため，HTTP Cookieの情報は，ブラウザのプロセスの終了と同時に消失します。

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

ブラウザ内のHTTP Cookie情報は，デフォルトの設定ではブラウザのプロセス終了とともに消失します。また，J2EEアプリケーション内で明示的にセッションを破棄することでグローバルセッション情報が破棄されると，ブラウザ内にあるHTTP Cookie情報も破棄されます。ブラウザ内のHTTP Cookie情報は，HTTPレスポンスヘッダに対して有効期限の切れたHTTP Cookieを設定することで破棄されます。

なお，タイムアウトによるグローバルセッション情報の破棄の場合は，ブラウザ内のHTTP Cookie情報は明示的に破棄されません。クライアントから無効になったグローバルセッションIDがHTTP Cookieとして送られてきたときに，クライアント内のHTTP Cookie情報が削除されます。

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

この節では，URL書き換えによるグローバルセッションの制御について説明します。

＜この節の構成＞

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

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

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

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

7.7.5　リクエストラインの最大サイズの設定

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

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

URL書き換えによるグローバルセッションの制御方法は，HTTPセッションをURL書き換えによって制御する場合の方法と同じです。J2EEサーバがWebアプリケーション内のサーブレットやJSPでリンクURLをエンコードするときに，グローバルセッションIDを含めてエンコードします。

Webクライアントからの2回目以降のリクエスト送信時には，グローバルセッションIDを含めてエンコードされたURLが使用されます。J2EEサーバはリクエストヘッダに含まれるURLの情報を基に，グローバルセッションの制御を実行します。

URL書き換えによるグローバルセッションの制御の概要を次の図に示します。

図7-15　URL書き換えによるグローバルセッションの制御の概要

Webクライアントからのリクエストを受信すると，J2EEサーバのJ2EEアプリケーション（Servlet／JSP）内で，HTTPセッションオブジェクトの作成とともに，グローバルセッションIDが発行されます。発行されたグローバルセッションIDは，Webクライアントに送信されるHTTPレスポンスボディに設定されます。同時に，SFOサーバに，グローバルセッション情報とともに格納されます。

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

URL書き換えによる制御の前提条件について説明します。

URL書き換えによってグローバルセッションを制御するためには，WebアプリケーションがURL書き換えに対応している必要があります。WebアプリケーションがURL書き換えに対応していない場合，この制御方法ではグローバルセッションを制御できません。

URL書き換えに対応したWebアプリケーションの実装方法については，「7.11.2　URL書き換えによる制御をする場合のアプリケーションの実装」を参照してください。

注意

URL書き換えによるグローバルセッション情報の制御に対応したシステムは，Smart Composer機能では構築できません。Smart Composer機能で構築するシステムは，HTTP Cookieによるグローバルセッション情報の制御だけに対応しています。グローバルセッション情報の制御にURL書き換えを使用するシステムは，運用管理ポータル，またはファイル編集とコマンド実行で構築してください。運用管理ポータルで構築する場合は，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.　J2EEアプリケーションを実行するシステムの構築と削除」を参照してください。ファイル編集とコマンド実行の場合は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」，およびマニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「付録C　J2EEアプリケーションを実行するシステムの構築と削除」を参照してください。

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

ここでは，グローバルセッションIDの送信に使用するURLのパスパラメタについて説明します。

グローバルセッションIDは，URLのパスパラメタ名として設定されます。使用されるパスパラメタ名は，Webアプリケーション単位に設定できます。デフォルトの設定の場合，「gsessionid」になります。パスパラメタ名は，大文字と小文字を区別されます。設定方法については，「7.14　J2EEサーバの設定」を参照してください。

注意

「jsessionid」は，大文字，小文字に関係なく，パスパラメタ名に指定できません。「jsessionid」は，HTTPセッションのセッションIDが，URL書き換えで使用するパスパラメタ名です。

これと同じ名称を使用すると，セッションフェイルオーバ用フィルタの初期化処理でエラーとなり，アプリケーションが開始できなくなります。

セッションフェイルオーバ用フィルタの初期化処理については，「7.9.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については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.3　セッションの管理方法」を参照してください。

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

ここでは，URL書き換えによってグローバルセッションを制御する場合に，負荷分散機で負荷分散を実現する方法について説明します。

HTTP Cookieを使用できないWebクライアントを使用する場合，負荷分散をするときにセッションを継続するための方法として，次のような方法があります。

サーバが埋め込む識別情報によってセッションを継続する方法

HTTPリクエストに含まれるクライアント個別の識別情報によってセッションを継続する方法

それぞれの方法について説明します。

＜この項の構成＞

(1)　サーバが埋め込む識別情報によるセッションの継続

(2)　HTTPリクエストに含まれるクライアント個別の識別情報によるセッションの継続

(1)　サーバが埋め込む識別情報によるセッションの継続

Webサーバまたはアプリケーションサーバがコンテンツに埋め込む識別情報を使用して，振り分け先を決め，セッションを継続する方法です。負荷分散機には，この識別情報を基にリクエストの振り分け先のサーバを決めるように設定します。

サーバが埋め込む識別情報は，一般的に次のフィールドに設定されます。

URLのパスの一部

URLのパスパラメタ

URLのクエリストリング

サーバから送信するHTMLのフォームのhiddenフィールド

メモリセッションフェイルオーバ機能を使用している場合，識別情報として，サーバIDを使用できます。サーバIDを識別情報として使用する場合，アプリケーションの実装を変更しなくても，負荷分散時のセッションの継続が実現できます。サーバIDは，セッションIDの構成要素です。URLのパスパラメタに含まれています。サーバIDについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

なお，サーバID以外を識別情報として使用する場合は，識別情報をコンテンツに埋め込む処理をアプリケーションで作りこむ必要があります。

サーバが埋め込む識別情報を使用して負荷分散を実行する処理の概要を次の図に示します。

図7-16　サーバが埋め込む識別情報を使用した負荷分散の概要

クライアント1は，リクエストを送信するときに，サーバ1から送信された識別情報をリクエストヘッダに含めて送信します。負荷分散機は，この識別情報を基に，振り分け先のサーバを選択します。これによって，セッションを継続できます。

(2)　HTTPリクエストに含まれるクライアント個別の識別情報によるセッションの継続

Webクライアントが送信するクライアント個別の識別情報に基づいて，振り分け先を決め，セッションを継続する方法です。負荷分散機には，この識別情報を基にリクエストの振り分け先のサーバを決めるように設定します。

クライアント個別の識別情報は，一般的に次のフィールドに設定されます。

HTTPリクエストのUser-Agentヘッダ

クライアントが独自に定義したHTTPリクエストヘッダ

なお，この方法を使用する場合，クライアント側の設定で，クライアント個別の識別情報をリクエストと同時に送信するように設定しておく必要があります。

クライアントの個別識別情報を使用して負荷分散を実行する処理の概要を次の図に示します。

図7-17　クライアントの個別識別情報を使用した負荷分散の概要

クライアント1は，リクエストを送信するときに，クライアント固有の識別情報をUser-Agentヘッダに含めて送信します。負荷分散機は，この識別情報を基に，振り分け先のサーバを選択します。これによって，セッションを継続できます。

7.7.5　リクエストラインの最大サイズの設定

URL書き換えによってグローバルセッションを制御する場合の，リクエストラインの最大サイズの設定について説明します。

URL書き換えによってグローバルセッションを制御する場合，URLのパスパラメタには，HTTPセッションのセッションIDとグローバルセッションIDが含まれます。HTTPリクエストのリクエストラインのサイズは，サーバ側およびクライアント側でそれぞれ上限があります。このため，あらかじめリクエストラインの最大サイズを算出して，それを基に，必要に応じてリクエストラインの最大サイズを設定してください。

ここでは，URL書き換えによってグローバルセッションを制御する場合のリクエストラインのサイズの算出方法と，リクエストラインのサイズの上限値を設定する方法について説明します。

＜この項の構成＞

(1)　リクエストラインの文字列長の算出と最大サイズの設定

(2)　URL書き換え使用時のリクエストラインのサイズの算出

(3)　リクエストラインの最大サイズの算出と設定

(1)　リクエストラインの文字列長の算出と最大サイズの設定

URL書き換えによってグローバルセッションを制御する場合の，リクエストラインの最大サイズの設定について説明します。

URL書き換えによってグローバルセッションを制御する場合，URLのパスパラメタには，HTTPセッションのセッションIDとグローバルセッションIDが含まれます。HTTPリクエストのリクエストラインのサイズは，サーバ側およびクライアント側でそれぞれ上限があります。

URL書き換えによってグローバルセッションを制御する場合には，あらかじめリクエストラインの最大サイズを算出して，それを基にサーバおよびクライアントでのリクエストラインの最大サイズを設定しておく必要があります。

URL書き換えを使用する場合のリクエストラインの文字列長の算出方法，およびリクエストラインの最大サイズの設定方法については，「7.7.5　リクエストラインの最大サイズの設定」を参照してください。

(2)　URL書き換え使用時のリクエストラインのサイズの算出

リクエストライン全体のサイズは，リクエストラインを構成する各項目のサイズを基に算出してください。

URL書き換えをする場合のリクエストラインの構成を次の図に示します。URL書き換えで使用するパスパラメタは，(d)と(e)に挿入されます。

図7-18　URL書き換えをする場合のリクエストラインの構成

リクエストラインを構成する各項目について説明します。(a)～(h)は図中の文字と対応しています。

表7-11　URL書き換えをする場合のリクエストラインを構成する項目

図中の文字
項目
説明
例

(a)
メソッド
リクエストのメソッドです。
GET
POST

(b)
スペース
区切りを示す空白文字です。
1バイト固定です。
△

(c)
リクエストパス
宛先を示すパスです。
http://www.host1:1234/example/test.jsp/example/test.jsp

(d)
HTTPセッションのセッションIDを示すパスパラメタ
URL書き換えによってURLに付加された，HTTPセッションのセッションIDを示すパスパラメタです。
;jsessionid=01234567aaaabbbbccccddddeeeeffffserver1

(e)
グローバルセッションIDを示すパスパラメタ
URL書き換えによってURLに付加された。グローバルセッションIDを示すパスパラメタです。
;gsessionid=0123456789abcdef01234567aaaabbbbccccddddeeeeffffserver1

(f)
クエリ
リクエストに付加されたクエリ文字列です。
?a=b&x=y

(g)
スペース
区切りを示す空白文字です。
1バイト固定です。
△

(h)
HTTPバージョン
HTTPのバージョンを示す文字列です。
HTTP/1.1

（凡例）

△：空白文字

なお，リクエストラインおよびURLの構成についての詳細は，RFC 2616およびRFC 2396のドキュメントを参照してください。

表7-11の内容のうち，URL書き換えによって付加される(d)と(e)のパスパラメタのサイズの算出方法について説明します。

(d)のHTTPセッションのセッションIDを示すパスパラメタのサイズの算出方法

HTTPセッションのセッションIDを示すパスパラメタのサイズ(バイト)
= ";jsessionid=" ＋ <HTTPセッションのセッションID>
=12バイト ＋ <HTTPセッションのセッションIDのサイズ(バイト)>※

注※

HTTPセッションのセッションIDの文字列長については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7　セッション管理機能」を参照してください。

(e)のグローバルセッションIDを示すパスパラメタのサイズの算出方法

グローバルセッションIDの送信に使用するパスパラメタの文字列長(バイト)
= ";" ＋ <グローバルセッションIDの送信に使用するパスパラメタ名のサイズ>
  ＋ "=" ＋ <グローバルセッションID>
= 1バイト ＋ <GIDURLParamNameパラメタに設定した文字列のサイズ(バイト)>
  ＋ 1バイト ＋ <グローバルセッションIDのサイズ(バイト)>※

注※

グローバルセッションIDのサイズ（バイト）は，次の式で算出してください。

グローバルセッションIDのサイズ(バイト)
= <HTTPセッションのセッションIDのサイズ(バイト)> ＋ 16バイト

(3)　リクエストラインの最大サイズの算出と設定

リクエストラインの最大サイズの設定方法について説明します。「(2)　URL書き換え使用時のリクエストラインのサイズの算出」で算出した値を基に，最大サイズを設定してください。

設定方法は，使用するWebサーバによって異なります。

●Webサーバ連携でHitachi Web Serverを使用する場合

Hitachi Web Serverを使用する場合は，Hitachi Web Serverの定義ファイル（httpsd.conf）のLimitRequestLineディレクティブで設定します。デフォルトの設定では，8,190バイトです。

LimitRequestLineディレクティブの設定方法の詳細については，マニュアル「Hitachi Web Server」を参照してください。

●Webサーバ連携でMicrosoft IISを使用する場合

Microsoft IISを使用する場合のリクエストラインの最大サイズの設定方法については，Microsoft IISのドキュメントを参照してください。

●インプロセスHTTPサーバを使用する場合

インプロセスHTTPサーバを使用する場合，リクエストラインの最大サイズは，簡易構築定義ファイルで設定します。

パラメタ名は，webserver.connector.inprocess_http.limit.max_request_lineです。webserver.connector.inprocess_http.limit.max_request_lineの値には，リクエストラインの終端を示す改行文字である，(CR(0x0d)＋LF(0x0A))の2バイトを含めた値を指定してください。デフォルトの設定では，8,190バイトです。

簡易構築定義ファイルの設定方法については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「8.4　システムの構成定義」を参照してください。

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

ここでは，URL書き換えによってグローバルセッションを制御する場合の注意事項について説明します。

URL書き換えのタイミング

URL書き換えを実行するServlet APIを呼び出すと，URLのパスパラメタにはその時点で存在するグローバルセッションのグローバルセッションIDが付加されます。

このため，次の場合には，セッションを正しく継続できません。

セッションを作成する前にURL書き換えを実行するServlet APIを呼び出した場合

URL書き換えを実行するServlet APIを呼び出したあとでセッションを再作成した場合

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

この節では，グローバルセッションの制御方法が混在する場合のシステム構成について説明します。なお，グローバルセッションの制御方法が混在しない場合のシステム構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「3.10　セッション情報の引き継ぎを検討する」を参照してください。

グローバルセッションの制御方法が混在するシステムでは，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アプリケーションにはしないで，両方の制御方法で使用する場合のシステム構成

＜この節の構成＞

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

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

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

ここでは，グローバルセッションの制御方法ごとにWebアプリケーションを分ける場合のシステム構成について説明します。

次の2種類のシステム構成について説明します。

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

リクエストの受信ポートを，WebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

＜この項の構成＞

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

(2)　リクエストの受信ポートをHTTP Cookieの使用可否によって分けない場合

(1)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合

リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合のシステム構成の例を次に示します。

図7-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を使用できるかどうかによって分けない場合のシステム構成の例を次に示します。

図7-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）で冗長化して管理します。

7.8.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サポート有無によって分かれているときの，システムの構成例を次に示します。

図7-21　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分ける場合（制御方法をWebアプリケーションごとに分けないとき）

それぞれのJ2EEサーバに配置されたWebアプリケーションは，HTTP Cookieによるセッション制御，およびURL書き換えによるセッション制御の両方に対応しています。ただし，グローバルセッションの制御方法ごとにリクエストの受信ポートを分けているため，実際にはWebアプリケーションごとにWebクライアントの種類が決まります。このため，それぞれのWebアプリケーションには，リクエストを送信するWebクライアントがHTTP Cookieを使用できるかどうかに応じて，グローバルセッションの制御方法を設定します。

図7-21の場合は，J2EEサーバ1およびJ2EEサーバ2がHTTP Cookieを使用できないWebクライアントからのリクエストを受け付けます。また，J2EEサーバ3とJ2EEサーバ4がHTTP Cookieを使用できるWebクライアントからのリクエストを受け付けます。

ポイント

冗長化した同じWebアプリケーションに対して，異なるグローバルセッションの制御方法を設定した場合，同一のSFOサーバ上でのネゴシエーションは失敗します。このため，この例では，SFOサーバを，グローバルセッションの制御方法ごとに二つのプロセスとしています。

どのSFOサーバを使用するかは，それぞれのJ2EEサーバで設定します。接続先のSFOサーバの設定方法については，「7.14　J2EEサーバの設定」を参照してください。

また，同じWebアプリケーションに対して異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用したいときには，制御方法ごとに，J2EEアプリケーションの名称を変更する方法があります。メモリセッションフェイルオーバ機能では，J2EEアプリケーションのアプリケーションが一致するかどうかによって，Webアプリケーションを同じアプリケーションであると判断します。このため，J2EEアプリケーションの名称を変更することで，異なるWebアプリケーションだと判断され，ネゴシエーションが失敗しなくなります。

異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用する場合のシステム構成例を次の図に示します。

図7-22　異なるグローバルセッションの制御方法を混在させて管理する場合に，SFOサーバを1プロセスだけで運用する場合のシステム構成例

この例では，グローバルセッションの制御方法ごとに，J2EEアプリケーションの名称を変更しています。

(2)　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合

グローバルセッションの制御方法に関係なく同一のWebアプリケーションを使用する場合に，リクエストがWebクライアントのHTTP Cookieサポート有無によって分かれていないときの，システムの構成例を次に示します。

図7-23　リクエストの受信ポートをWebクライアントがHTTP Cookieを使用できるかどうかによって分けない場合（制御方法をWebアプリケーションごとに分けないとき）

この例の場合は，リクエストの受信ポートがグローバルセッションの制御方法によって分かれていないため，それぞれのWebアプリケーションには，HTTP Cookieを使用したリクエストとURL書き換えを利用したリクエストの両方が送信されます。これに対応するため，それぞれのWebアプリケーションでは，セッションの制御方法として「both」を設定します。

なお，グローバルセッションの制御方法に関係なく，J2EEサーバ1およびJ2EEサーバ2で作成したすべてのグローバルセッション情報は，SFOサーバ1（SFOServer01）で冗長化して管理します。

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

この節では，メモリセッションフェイルオーバ機能で実施される処理について説明します。

参考

この節の7.9.1から7.9.6までの説明は，グローバルセッションの制御方法として，HTTP Cookieを使用した場合の処理について説明しています。

それぞれの処理でのグローバルセッションの制御処理については，URL書き換えを使用した場合も同様です。ただし，グローバルセッションの制御にURL書き換えを使用する場合，HTTP Cookieを使用する場合と比べて，次の処理が異なります。

グローバルセッションの制御に使用するグローバルセッションIDは，URLのパスパラメタから取得されます。

グローバルセッションの制御にHTTP Cookieを使用しないため，グローバルセッションを削除した場合，およびグローバルセッションが無効な場合に，グローバルセッションのHTTP Cookie情報の削除処理が実行されません。

HTTPセッションのURL書き換え処理が実行されるときに，HTTPセッションのセッションIDに加えて，グローバルセッションIDが付加されます。なお，HTTPセッションのURL書き換え処理は，WebアプリケーションでのURLエンコード用のServlet APIの呼び出しを実行した場合に実行されます。

これらの相違点を含めた処理の流れについては，「7.9.7　URL書き換えを使用する場合の処理の違い」を参照してください。

＜この節の構成＞

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

7.9.2　J2EEサーバ起動時の処理

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

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

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

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

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

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

メモリセッションフェイルオーバ機能では，次に示す時点でそれぞれ処理が実施されます。

J2EEサーバ起動時の処理
J2EEサーバ起動時には，SFOサーバの状態を監視するためのスレッドが作成されます。

J2EEアプリケーション開始時の処理
J2EEアプリケーション開始時には，セッションフェイルオーバ用フィルタの初期化処理が実施されます。

リクエスト実行時の処理
リクエスト処理実施時には，グローバルセッション情報の格納，更新，削除がされます。

メモリセッションフェイルオーバ機能で実施される処理について，以降の項で説明します。

また，HttpSessionオブジェクトの有効期限が切れた場合の処理，無効なグローバルセッションIDが送られた場合の処理についても説明します。

7.9.2　J2EEサーバ起動時の処理

J2EEサーバでは，SFOサーバの状態を監視するためのスレッドを作成します。これを，SFOサーバ監視スレッドといいます。SFOサーバ監視スレッドは，Webアプリケーションごとに一つ作成され，各Webアプリケーションで使用するSFOサーバのヘルスチェックを実施します。ヘルスチェックは，SFOサーバアプリケーションで用意している，コネクションの状態監視用のビジネスメソッドを呼び出して実施します。コネクションの状態監視のインターバルは3秒です。また，コネクションの状態監視用のビジネスメソッドの呼び出しのタイムアウトには，SFOサーバとの通信タイムアウト時間に設定した時間が適用されます。タイムアウトが発生した場合，SFOサーバはダウンしていると判断され，リトライはされません。

なお，SFOサーバアプリケーションは，Cosminexusで提供しています。SFOサーバアプリケーションの概要については，「7.4.3(1)　SFOサーバ」を参照してください。また，SFOサーバ監視スレッドの設定については，「7.14　J2EEサーバの設定」を参照してください。

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

ここでは，J2EEアプリケーション開始時の処理の流れについて説明します。また，J2EEアプリケーション開始時に実行されるJ2EEサーバとSFOサーバのネゴシエーション処理についても説明します。

＜この項の構成＞

(1)　J2EEアプリケーション開始時の処理の流れ

(2)　J2EEサーバとSFOサーバのネゴシエーションで使用される情報

(3)　ネゴシエーションが失敗した場合の対処

(1)　J2EEアプリケーション開始時の処理の流れ

J2EEアプリケーション実行前に，セッションフェイルオーバ用フィルタの初期化処理が実施されます。初期化処理では，次の内容が実施されます。

web.xmlのメモリセッションフェイルオーバ機能に関する設定の妥当性がチェックされます。
設定内容に問題がある場合は，フィルタの初期化処理でエラーとなり，Webアプリケーションは開始されません。

web.xmlの設定に問題がない場合，J2EEサーバからSFOサーバへの接続が実施されます。
接続先のSFOサーバは，J2EEサーバごとに設定されています。設定方法については，「7.14　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の名称の設定方法については，「7.12　DDでの定義」を参照してください。

●注意事項

SFOサーバの稼働状態に異常があったり，SFOサーバが稼働するマシンのメモリ使用量に異常があったりして，60秒以内にネゴシエーション処理が完了しなかった場合，J2EEサーバはSFOサーバとのネゴシエーションに失敗したと判断して，SFOサーバとの接続を切断します。
なお，SFOサーバ側でネゴシエーションが成功していても，J2EEサーバとの接続が切断されていることを検知した時点で，グローバルセッション情報の保持を終了します。
なお，J2EEサーバの接続検知については，「7.4.3(1)　SFOサーバ」を参照してください。

SFOサーバとJ2EEサーバとのネゴシエーションが成功すると，SFOサーバには，Webアプリケーションの設定情報が登録されます。Webアプリケーションの情報を変更して，SFOサーバに接続すると，SFOサーバには変更前のWebアプリケーションの情報があるため，ネゴシエーションに失敗します。そのため，SFOサーバに登録されたWebアプリケーションの設定情報を削除してからWebアプリケーションを開始する必要があります。なお，設定情報の削除については，「7.17　Webアプリケーションの設定情報の削除」を参照してください。

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サーバと同じ設定である必要がある情報も示します。

表7-12　ネゴシエーション処理で使用される情報

セッションフェイルオーバ用フィルタによって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サーバに接続ができた場合，再度ネゴシエーション処理が実行されます。

ネゴシエーションが成功すると，メモリセッションフェイルオーバ機能が有効になります。

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

ここでは，リクエスト実行時のグローバルセッションフェイルオーバ用フィルタの処理と，グローバルセッション情報の格納，更新，削除処理について説明します。

＜この項の構成＞

(1)　リクエスト実行時のセッションフェイルオーバ用フィルタの処理

(2)　グローバルセッション情報の格納処理

(3)　グローバルセッション情報の更新処理

(4)　グローバルセッション情報の削除処理

(1)　リクエスト実行時のセッションフェイルオーバ用フィルタの処理

セッションフェイルオーバ用フィルタでは，リクエスト実行前には，グローバルセッション情報をロックし，必要に応じて引き継ぎ処理をします。また，リクエスト処理後には，グローバルセッション情報を格納または更新して，ロックを解除します。

(a)　グローバルセッション情報のロックについて

異なるJ2EEサーバから同じグローバルセッション情報を同時に更新されることを抑止するため，セッションフェイルオーバ用フィルタでは，SFOサーバ上のグローバルセッション情報のロックをします。

J2EEアプリケーションでのリクエスト処理で，SFOサーバのグローバルセッション情報を使用すると，SFOサーバ上のグローバルセッション情報はロックされます。
このとき，別のJ2EEサーバがグローバルセッション情報を使用しようとすると，ロックの解除待ちとなります。

グローバルセッション情報を使用しているJ2EEアプリケーションでリクエスト処理が完了すると，SFOサーバでのロックが解除されます。
ロック解除時に，ロックの解除待ちとなっているJ2EEアプリケーションがある場合は，ロックが解除されたグローバルセッション情報を使用してリクエスト処理をします。

グローバルセッション情報にロックを設定することによって，J2EEアプリケーションでのダブルクリックなどによって二重送信されたリクエストが別のJ2EEサーバに送信された場合の誤動作も防止できます。

なお，ロックの解除待ちには，タイムアウトを設定できます。解除待ちでタイムアウトした場合，該当するグローバルセッション情報は使用できなくなります。このとき，セッションは破棄され，新規リクエストとしてJ2EEアプリケーションを呼び出します。

(b)　セッション情報の引き継ぎ処理について

セッション情報の引き継ぎ処理では，新規にHttpSessionオブジェクトを生成し，セッション情報を登録します。Servlet仕様で提供されているセッションに関する次の三つのリスナをJ2EEアプリケーションで定義している場合，リスナへの通知が実施されます。

呼び出されるリスナの種類について，システム内で発生するイベントごとに次の表に示します。

表7-13　呼び出されるリスナの種類

システム内で発生するイベント
呼び出されるリスナ
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書き換えを使用している場合の処理の違いについては，「7.9.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図7-24　グローバルセッション情報の格納処理

J2EEアプリケーション内の処理で，HttpSessionオブジェクトが作成されます。
javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドが呼び出され，HttpSessionオブジェクトが作成されます。

作成されたHttpSessionオブジェクトに対応する，グローバルセッションIDが発行されます。

SFOサーバに新しいグローバルセッション情報を追加します。追加されたグローバルセッション情報はロックされます。

HTTPレスポンスのヘッダのSet-Cookieヘッダに，グローバルセッションIDが追加されます。

SFOサーバにグローバルセッション情報を送信し，格納します。

なお，HTTPセッションで使用するSet-Cookieヘッダのpath属性はコンテキストルートが固定となります。

(3)　グローバルセッション情報の更新処理

J2EEアプリケーションでセッションを使用し，グローバルセッション情報が更新されると，SFOサーバ内のグローバルセッション情報も更新する必要があります。

なお，グローバルセッション情報の更新中は，グローバルセッション情報にロックが掛かります。ロックが掛かると，ほかのJ2EEサーバからのグローバルセッション情報の操作ができなくなります。

グローバルセッション情報の更新処理について，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「7.9.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図7-25　グローバルセッション情報の更新処理

SFOサーバ上のグローバルセッション情報にロックが掛かります。
J2EEアプリケーションの処理の前に，グローバルセッション情報にロックが掛かります。

J2EEアプリケーション内の処理でHttpSessionオブジェクトを使用すると，HttpSessionオブジェクトに登録されたグローバルセッション情報が更新されます。

J2EEアプリケーション処理の終了後，SFOサーバにセッション情報を送信します。

SFOサーバ上のグローバルセッション情報を最新に更新します。

SFOサーバ上のグローバルセッション情報のロックを解除します。

(4)　グローバルセッション情報の削除処理

J2EEアプリケーション内で，javax.servlet.http.HttpSessionインタフェースのinvalidateメソッドが呼び出される場合の，明示的なグローバルセッション情報の削除の処理について，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「7.9.7　URL書き換えを使用する場合の処理の違い」を参照してください。

図7-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情報の削除処理が実施されます。

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

HttpSessionオブジェクトに設定されている有効期限が切れるまでの間に，HttpSessionオブジェクトを使用するリクエストが発生しなかった場合は，HttpSessionオブジェクトはJ2EEサーバによって削除されます。また，このとき，HttpSessionオブジェクトに対応づけられたSFOサーバ上のグローバルセッション情報も削除されます。

有効期限が切れているときには，グローバルセッション情報がロックされているかどうかにかかわらず，HttpSessionオブジェクトは削除されます。このため，J2EEサーバでグローバルセッション情報を使用中の場合や，J2EEサーバのダウンによってロックされたままのグローバルセッション情報も，有効期限が切れると削除されます。

HttpSessionオブジェクトの有効期限が切れた場合の処理の流れについて，次の図に示します。

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

有効期限が切れると，HttpSessionオブジェクトは削除されます。
J2EEサーバ内では，HttpSessionオブジェクトの有効期限が監視されています。有効期限が切れると，HttpSessionオブジェクトが削除されます。

有効期限の切れたSFOサーバ上のグローバルセッション情報も削除されます。
SFOサーバ内では，グローバルセッション情報の有効期限が監視されています。有効期限が切れると，SFOサーバ上のグローバルセッション情報が削除されます。

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

SFOサーバにない，グローバルセッションIDがリクエストとして送られてきた場合の処理の流れについて，次の図に示します。

参考

次の図とその説明は，グローバルセッションの制御方法として，HTTP Cookieを使用している場合の例です。URL書き換えを使用している場合の処理の違いについては，「7.9.7　URL書き換えを使用する場合の処理の違い」を参照してください。

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

グローバルセッション情報のロックが失敗します。
SFOサーバに対して，グローバルセッション情報のロック要求がありますが，SFOサーバ内にない，無効なグローバルセッションIDが送信されてきたため，ロックが失敗します。

HTTPレスポンスヘッダに，Set-Cookieヘッダを期限切れでセットします。
クライアントにあるグローバルセッションIDのHTTP Cookie情報を削除するよう，Set-Cookieヘッダを期限切れでセットします。

HttpSessionオブジェクトがある場合は，書き換え可能グローバルセッション情報が削除されます。

なお，3.の処理以降，J2EEアプリケーション内の処理で，javax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドが呼び出されると，グローバルセッションが新規に作成されます。

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

ここでは，URL書き換えを使用する場合の処理と，HTTP Cookieを使用する場合の処理との違いについて説明します。

グローバルセッションの制御方法としてURL書き換えを使用している場合，HTTP Cookieを使用して制御している場合の処理に加えて，URL書き換えのための処理として，次の処理が追加されます。

URLのパスパラメタの解析

WebアプリケーションでのServlet APIの呼び出しによる，グローバルセッションIDを含むURLのエンコード

また，グローバルセッションを削除した場合，およびグローバルセッションが無効な場合に，グローバルセッションのHTTP Cookie情報の削除処理は実行されません。

URL書き換えする場合に追加される処理について，次の図に示します。

図7-29　URL書き換えする場合に追加される処理

各ポイントでの処理内容について説明します。説明の番号は図中の番号と対応しています。なお，1.，3.，4.の処理が，URL書き換えの場合だけに実行される処理です。

J2EEサーバによって，Webクライアントから送信されたリクエストURLのパスパラメタが解析されます。

セッションフェイルオーバ用フィルタによって，SFOサーバ上のグローバルセッション情報がロックされます。
なお，この処理は，グローバルセッションの制御方法に関係なく実行されます。

J2EEアプリケーション内のWebアプリケーションで，URL書き換えのためのエンコードを実行するServlet APIが呼び出されます。
この処理は，URL書き換えの場合だけ実行されます。

J2EEサーバによって，グローバルセッションIDがURLにエンコードされます。なお，エンコードはHTTPセッションのセッションIDとともに実行されます。

セッションフェイルオーバ用フィルタによって，SFOサーバ上のグローバルセッション情報が更新され，グローバルセッション情報のロックが解除されます。
なお，この処理は，グローバルセッションの制御方法に関係なく実行されます。

7.10　メモリセッションフェイルオーバ機能使用時の障害検知

メモリセッションフェイルオーバ機能を使用している場合に，Webサーバ，J2EEサーバ，およびSFOサーバで発生した障害は，次に示す二つの方法で検知できます。

Management Serverの稼働状況監視による障害検知
Management Serverの稼働状況監視を使用して，Webサーバ，J2EEサーバ，およびSFOサーバの稼働状況を監視できます。稼働状況の監視については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「3.　稼働情報の監視（稼働情報収集機能）」を参照してください。

負荷分散機のヘルスチェック機能による障害検知
負荷分散機の機能を使用して，システム内のJ2EEサーバに対してヘルスチェックを実施できます。ヘルスチェックで，J2EEサーバに問題を検知した場合，該当するJ2EEサーバにリクエストを転送しているWebサーバへの負荷分散を中止します。
また，J2EEサーバへのチェックの際にWebサーバを経由するため，Webサーバでの障害検知もできます。
SFOサーバで発生した障害については，SFOサーバおよびJ2EEサーバが出力したメッセージログを基に，障害検知を実施します。

7.11　アプリケーションの実装

この節では，メモリセッションフェイルオーバ機能を使用するアプリケーションを開発するときに留意することについて説明します。また，URL書き換えによる制御をする場合のアプリケーションの実装方法，およびアプリケーションを実行するときに追加される属性についても説明します。

＜この節の構成＞

7.11.1　実装時の留意事項

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

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

7.11.1　実装時の留意事項

メモリセッションフェイルオーバ機能を使用するアプリケーションを開発する場合に，留意する点について説明します。

＜この項の構成＞

(1)　セッションフェイルオーバ用フィルタの呼び出し順序

(2)　JSPで暗黙的に作成されるHTTPセッションの扱い

(3)　セッション管理に使用する情報の選択

(4)　障害発生時の動作を考慮した処理の実装

(5)　HTTPセッションの破棄に伴う動作

(6)　セッション情報の引き継ぎが発生した場合の認証情報の扱い

(7)　メモリセッションフェイルオーバ機能使用によるサーブレットAPIの動作

(8)　JSPでの<jsp:useBean>タグの使用

(1)　セッションフェイルオーバ用フィルタの呼び出し順序

セッションフェイルオーバ用フィルタは，サーブレットフィルタとして提供されます。セッションフェイルオーバ用フィルタは，ほかのサーブレットフィルタよりも前に呼び出される必要があります。HTTPレスポンス圧縮フィルタ，およびユーザ作成のフィルタよりも前に配置してください。フィルタの組み込みについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.9.2　フィルタ連鎖の推奨例」を参照してください。

(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サーバで問題なく業務を続けるためには，必要な情報をすべてグローバルセッション情報として設定しておく必要があります。

グローバルセッション情報として設定できる情報については，「7.4.2　グローバルセッション情報」を参照してください。また，グローバルセッション情報の引き継ぎについては，「7.4.5　サーバの状態とグローバルセッション情報の引き継ぎ」を参照してください。

(b)　HTTPセッションに同一のオブジェクトが複数回登録されている場合を考慮した処理

HttpSessionオブジェクトに同じオブジェクトが複数登録されていた場合に，引き継ぎ後のHttpSessionオブジェクトに登録されるオブジェクトが異なるので，注意が必要です。

一つのHttpSessionオブジェクトに同じオブジェクトが複数登録されている場合
一つのHttpSessionオブジェクトに，同じjava.lang.Stringクラスのオブジェクトが複数登録されている場合に，グローバルセッション情報の引き継ぎが発生すると，複数登録していたオブジェクトは別々のオブジェクトとして生成されます。
一つのHttpSessionオブジェクトに同じオブジェクトが複数登録されている場合の引き継ぎの例を次の図に示します。

図7-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オブジェクトに同一のオブジェクトが登録されている場合の引き継ぎの例を次の図に示します。

図7-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)　セッション情報の引き継ぎが発生した場合の認証情報の扱い

障害発生時に認証情報を引き継ぐ場合は，Basic認証によって認証処理をする必要があります。Basic認証を使用すると，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合でも，再度認証する必要はありません。グローバルセッション情報は正常に引き継がれ，業務を続けられます。

サーブレットAPIで定義されているフォーム認証によって認証処理をしている場合，認証されたJ2EEサーバと異なるJ2EEサーバにリクエストが振り分けられた場合は，認証情報が引き継がれていても，再度認証が必要です。

Basic認証およびForm認証については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「9.3　ロールに基づくWebコンテナのユーザ認証」を参照してください。

(7)　メモリセッションフェイルオーバ機能使用によるサーブレットAPIの動作

メモリセッションフェイルオーバ機能を使用する場合と，使用しない場合とで動作が変わるサーブレットAPIがあります。次に，メモリセッションフェイルオーバ機能によって動作に変更があるAPIおよび注意点を示します。

表7-14　メモリセッションフェイルオーバ機能と関係するサーブレットAPI

項番 | クラス名またはインタフェース名※1 | API名 | 注意点
1 | ServletContext | getAttributeNames | HTTP Cookieによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションIDに使用するHTTP Cookie名称をサーブレットコンテキストに属性として登録します。グローバルセッションIDは，セッションフェイルオーバ用フィルタ開始時に初期化パラメタに設定されたIDです。getAttributeNamesで取得できる属性名にこの属性の名称が含まれます。セッションフェイルオーバ用フィルタが登録する属性については，「7.11.3　アプリケーションを実行するときに追加される属性」を参照してください。
2 | ServletContextAttributeListener | attributeAdded | HTTP Cookieによるグローバルセッション制御が有効な場合に動作が変わります。グローバルセッションIDに使用するHTTP Cookie名称をサーブレットコンテキストに属性として登録するために，javax.servlet.ServletContextAttributeListenerクラスのattributeAddedメソッドが呼び出されます。グローバルセッションIDは，セッションフェイルオーバ用フィルタ開始時に初期化パラメタに設定されたIDです。サーブレットコンテキストに登録する属性については，「7.11.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コンテナが追加する属性については，「7.11.3　アプリケーションを実行するときに追加される属性」を参照してください。
13 | getAttributeNames
14 | getCreationTime | 引き継ぎが発生すると，引き継ぎ処理によってHttpSessionオブジェクトが作成されるため，引き継ぎ発生前と異なる値が返されます。
15 | getId※3
16 | getLastAccessedTime | 引き継ぎ発生後，初回のリクエスト時には前回アクセスの時刻を返すことができません。
17 | isNew※4 | 引き継ぎによって，HttpSessionオブジェクトが作成されると，戻り値が「true」となります。
18 | HttpSessionAttributeListener | リスナについては，「7.9.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タグに設定した名称をグローバルセッション情報として使用する情報（キー）に設定する。

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

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

メモリセッションフェイルオーバ機能を使用するアプリケーションでは，動作するために必要な情報をWebコンテナから取得するために，javax.servlet.ServletContextオブジェクトの属性を使用します。

アプリケーションの起動時には，次の表に示す属性が，Webコンテナによってjavax.servlet.ServletContextオブジェクトの属性に追加されます。

表7-15　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メソッドの呼び出しは実行されません。

7.12　DDでの定義

ここでは，テンプレートを利用したDDの作成と，DDに定義する項目について説明します。

＜この節の構成＞

7.12.1　DDの作成

7.12.2　DDに定義する項目

7.12.3　DDでの定義例

7.12.1　DDの作成

セッション情報の引き継ぎを行うWebアプリケーションの設定では，Webアプリケーションにセッションフェイルオーバ用フィルタを追加して，セッション情報の引き継ぎに関する項目やフィルタマッピングを定義します。フィルタの設定の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）」も参照してください。

次に示すディレクトリに，メモリセッションフェイルオーバ機能で使用するフィルタ定義およびフィルタマッピングの定義が記述されたテンプレートのDD（web.xml）が用意してあります。

テンプレート格納ディレクトリ

<Cosminexusのインストールディレクトリ>¥CC¥sfo¥sfo_war

このファイルをコピーしてWebアプリケーションのDDを作成します。すでに存在するWebアプリケーションにメモリセッションフェイルオーバ機能を適用する場合，テンプレートからDDにセッションフェイルオーバ用フィルタのフィルタ定義およびフィルタマッピングの定義をコピーし，必要な定義を記述します。

注意

タグの指定を省略する場合，タグの記述も含めて省略する必要があります（<init-param>タグ～</init-param>タグの記述を省略します）。次のようにタグを記述して値だけ省略した場合，空白文字列を指定したと判断されてエラーとなります。

間違った省略方法の例

　　 （省略）
　　　　：
<init-param>
<param-name>LockTimeout</param-name>
<param-value></param-value>
</init-param>
　　　　：
　　 （省略）

テンプレートの内容を次に示します。

図7-32　テンプレートの内容（メモリセッションフェイルオーバ機能のDD）（1/2）

図7-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アプリケーションの開始時にセッションフェイルオーバ用フィルタの初期化段階でエラーが発生し，アプリケーションは開始できません。

7.12.2　DDに定義する項目

グローバルセッション情報として登録する情報や，使用するSFOサーバの情報などは，<filter>タグ内の初期化パラメタである，<init-param>タグ内を編集して定義します。

参考

<init-param>タグ内の情報は，アプリケーションをJ2EEサーバにインポートしたあとで，サーバ管理コマンドを使用して設定することもできます。

DDの<init-param>タグ内に定義する内容を次の表に示します。なお，<param-value>に指定する値の詳細については，(1)以降で説明します。

表7-16　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に指定する値と引き継ぎ対象となるセッション情報の関係については，「(1)　グローバルセッション情報として使用する情報（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>タグ内に定義する要素のデフォルト値と設定要否を次の表に示します。

表7-17　使用する機能ごとの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サーバ名がデフォルトになります。セッションフェイルオーバ用フィルタのサーバ定義名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.sfo.sfo_serversパラメタで指定します。

注※4　指定したSFOサーバ名が，簡易構築定義ファイルで指定されているセッションフェイルオーバ用フィルタのサーバ定義名にない場合もエラーになりません。セッションフェイルオーバ用フィルタのサーバ定義名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.sfo.sfo_serversパラメタで指定します。

なお，グローバルセッションの制御方法によって，指定する必要があるパラメタが異なります。

グローバルセッションの制御方法と指定が必要なパラメタの対応を次の表に示します。

表7-18　グローバルセッションの制御方法と指定が必要なパラメタの対応

<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の定義内容は，すべての冗長化したアプリケーションで同一である必要があります。定義内容が不正な場合，アプリケーション開始処理がエラーになります。メッセージは，KDJE34202-Eのメッセージが出力されます。

＜この項の構成＞

(1)　グローバルセッション情報として使用する情報（GSInfoKey-RW，GSInfoKey-R）

(2)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）

(3)　グローバルセッション情報を格納するSFOサーバ（SFOServerName）

(4)　グローバルセッションの制御方法（GSessionControl）

(5)　グローバルセッションIDの送信に使用するHTTP Cookieの名称（GIDCookieName）

(6)　グローバルセッションIDの送信に使用するURLのパスパラメタ名（GIDURLParamName）

(7)　グローバルセッション情報のロック待ちタイムアウト時間（LockTimeout）

(8)　引き継ぎ可能なセッション情報のデータ型（GSInfoTypeByteArrayEnable，GSInfoTypeSerializableEnable）

(9)　統合ユーザ管理機能を使用する場合の設定

(1)　グローバルセッション情報として使用する情報（GSInfoKey-RW，GSInfoKey-R）

HTTPセッションに登録する情報の中から，グローバルセッション情報として登録する情報を選択して定義します。HTTPセッションに登録する情報すべてをグローバルセッション情報として引き継ぐ場合は，「*」を指定します。

ただし，グローバルセッション情報として，HTTPセッションに登録されたすべてのセッション情報を指定すると，引き継ぐ必要のない情報がHTTPセッションに登録されている場合にリクエスト処理のパフォーマンスが低下することがあります。このため，必要最小限のセッション情報をグローバルセッション情報としてSFOサーバに引き継ぐように設定することをお勧めします。必要最小限のグローバルセッション情報を引き継ぐことで，SFOサーバのパフォーマンスの向上を図れます。

グローバルセッション情報は，書き換え可能グローバルセッション情報または読み込み専用グローバルセッション情報として指定します。HTTPセッションに登録後，変更が必要なセッション情報は，書き換え可能グローバルセッション情報に指定します。HTTPセッションに登録後，変更が不要なセッション情報は，読み込み専用グローバルセッションに指定します。グローバルセッション情報については，「7.4.2　グローバルセッション情報」を参照してください。

書き換え可能グローバルセッション情報の場合は，パラメタのGSInfoKey-RWで指定します。読み込み専用グローバルセッション情報の場合は，GSInfoKey-Rで指定します。

GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定した文字列は，「;」（半角セミコロン）で分割したあと，それぞれの値の先頭と最後の連続した空白文字※を削除した結果がキー名称として使用されます。空白文字※を削除した結果が「""」（空文字列）になったキー名称は無視されます。GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定した文字列に有効となるキー名称がない場合は，KDJE34202-Eのメッセージが出力され，エラーとなります。

注※　空白文字とは，半角スペース，タブ，LF（ラインフィード（0x0a）），CR（キャリッジリターン（0x0d））またはFF（フォームフィード（0x0c））のことを指します。

GSInfoKey-RWおよびGSInfoKey-Rパラメタに指定する値と引き継ぎ対象となるセッション情報の関係を次の表に示します。

表7-19　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パラメタに指定したキーで登録されたセッション情報は含まれません。

(2)　グローバルセッション情報の最大サイズ（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エンコード後の文字列長を次の表に示します。

表7-20　文字種ごとの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セッションに含まれるセッション情報ごとのバイト数が出力できます。出力されたサイズ情報を参考にして，グローバルセッション情報の最大サイズに適切な値を設定してください。グローバルセッション情報のサイズ見積もり機能については，「7.5　グローバルセッション情報のサイズの見積もり」を参照してください。

(b)　直列化可能クラスのオブジェクトであるセッション情報の引き継ぎを許可している場合

グローバルセッション情報のサイズ＝
　（各グローバルセッション情報のキーのシリアライズ後のバイト数合計）
　＋（各HTTPセッションに登録されたオブジェクトのシリアライズ後のバイト数合計）
　＋（HTTPセッションの有効期間情報の長さ）※

注

シリアライズは，一つのHTTPセッションに対して，一つのjava.io.ObjectOutputStreamのオブジェクトを使用して実施します。

注※

HTTPセッションの有効期間情報の長さは4バイトです。

例えば，n種類のグローバルセッション情報を設定した場合は，グローバルセッション情報の最大サイズは次の式で算出できます。

グローバルセッション情報のサイズ＝
　（グローバルセッション情報1のキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクト1のシリアライズ後のバイト数）
　＋（グローバルセッション情報2のキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクト2のシリアライズ後のバイト数）
　：
　＋（グローバルセッション情報nのキーのシリアライズ後のバイト数）
　＋（HTTPセッションに登録されたオブジェクトnのシリアライズ後のバイト数）
　＋4

注

シリアライズは，一つのHTTPセッションに対して，一つのjava.io.ObjectOutputStreamのオブジェクトを使用して実施します。

参考

グローバルセッション情報のサイズ見積もり機能を使用すると，各情報のシリアライズ後のバイト数が出力できます。出力されたサイズ情報を参考にして，グローバルセッション情報の最大サイズに適切な値を設定してください。グローバルセッション情報のサイズ見積もり機能については，「7.5　グローバルセッション情報のサイズの見積もり」を参照してください。

(3)　グローバルセッション情報を格納するSFOサーバ（SFOServerName）

グローバルセッション情報を格納するSFOサーバのサーバ名を指定します。サーバ名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のパラメタwebserver.sfo.sfo_serversに指定したSFOサーバ名から選択します。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

ポイント

システム内に複数のSFOサーバを配置する場合，メモリセッションフェイルオーバ機能を使用するWebアプリケーション単位に，SFOサーバを割り当てることをお勧めします。Webアプリケーション単位にSFOサーバを割り当てることによって，SFOサーバで障害が発生したときの影響範囲を特定のJ2EEアプリケーションに限定させることができます。システム内に複数のSFOサーバを配置する場合の設定例を次の図に示します。

図7-34　システム内に複数のSFOサーバを配置する場合の設定例

(4)　グローバルセッションの制御方法（GSessionControl）

グローバルセッションの制御方法を指定します。指定した値に応じて，Webクライアントに対するグローバルセッションIDの送信方法，およびWebクライアントからのグローバルセッションIDの受信方法が決まります。

指定できる値と意味を次の表に示します。

表7-21　GSessionControlの指定値の意味

指定値
意味

cookie
グローバルセッションの制御にHTTP Cookieを使用します。

url-rewriting
グローバルセッションの制御にURL書き換えを使用します。

both
グローバルセッションの制御にHTTP CookieおよびURL書き換えの両方を使用します。
WebクライアントがHTTP Cookieをサポートしているかどうかを判別して，必要に応じてHTTP Cookieによる制御とURL書き換えによる制御を切り替えます。

また，GSessionControlに指定した値によって，次の制御が変わります。

WebクライアントからJ2EEサーバに送信されるグローバルセッションIDの扱われ方

J2EEサーバからWebクライアントへのレスポンスの設定内容

GSessionControlに指定する値とグローバルセッションの制御方法の関係を，次の表に示します。

表7-22　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書き換えを使用したグローバルセッションの制御については，「7.6　HTTP Cookieによるグローバルセッションの制御」および「7.7　URL書き換えによるグローバルセッションの制御」を参照してください。

(5)　グローバルセッションIDの送信に使用するHTTP Cookieの名称（GIDCookieName）

グローバルセッションIDをWebブラウザなどのクライアントに通知するときに使用するHTTP Cookieの名称を指定します。なお，グローバルセッションIDとは，グローバルセッション情報の識別に使用される情報です。

Cookieの名称は，Webアプリケーション単位に指定できます。ただし，次に示すCookieの名称と同じ値を指定することはできません。

JSESSIONID
HTTPセッションのセッションIDの送信に使用するCookieの名称です。

HTTPセッションを生成したリクエストのレスポンスに付加されるサーバIDのCookieの名称
HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加する機能を有効にしている場合に確認が必要です。
この機能を有効にしているかどうか，および付加されるサーバIDのCookieの名称については，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，次のパラメタの値を参照してください。

webserver.container.server_id.enabled

webserver.container.server_id.name

なお，グローバルセッションIDの送信に使用するCookieの名称が，これらのCookieの名称と重複した場合，Webアプリケーションに定義したセッションフェイルオーバ用フィルタ（J2EE仕様で規定されたjavax.servlet.Filterインタフェースを実装したクラス）の開始処理でエラーとなり，Webアプリケーションを実行できません。

(6)　グローバルセッションIDの送信に使用するURLのパスパラメタ名（GIDURLParamName）

グローバルセッションIDをWebブラウザなどのクライアントに通知するときに使用するURLのパスパラメタ名を指定します。

GSessionControlパラメタに「cookie」を指定した場合，このパラメタに設定した値は無効になります。なお，GSessionControlパラメタに「cookie」を指定した場合，GIDURLParamNameパラメタに設定した値はチェックされません。このため，このパラメタに不正な値を設定した場合も，検出はされません。

注意

Webアプリケーション内で使用するURLのパスパラメタと同じ名称を，このパラメタで指定しないでください。指定した場合，メモリセッションフェイルオーバ機能が正しく動作しません。

URL書き換えを使用したグローバルセッションの制御については，「7.7　URL書き換えによるグローバルセッションの制御」を参照してください。

(7)　グローバルセッション情報のロック待ちタイムアウト時間（LockTimeout）

すでにロックされた状態のセッションに対して，別のJ2EEサーバからロック要求があった場合に，ロック待ちがタイムアウトになるまでの時間を指定します。

J2EEサーバからSFOサーバに対してグローバルセッション情報のロック取得要求をしたあとに，J2EEサーバに障害が発生して停止した場合，SFOサーバ上のグローバルセッション情報がロックされたままの状態になってしまうおそれがあります。グローバルセッション情報のロック待ちタイムアウト時間は，このような場合に，J2EEサーバに障害が発生したと判断するために使用されます。

また，次のような場合にロックされたままの状態になったときにも，このタイムアウト時間が有効になります。これらの状態は，負荷分散機を使用している環境で発生することがあります。

ページにフレームを使用している場合など，同じセッションを使用するリクエストが同時に送信され，それぞれのリクエストが負荷分散機のスケジュール機能によって異なるJ2EEサーバに分散されて転送されたとき

ユーザの操作によってリクエストが二重に送信された場合など，リクエストを送信して応答が返されるよりも前に次のリクエストを送信したときに，それぞれのリクエストが負荷分散機のスケジュール機能によって異なるJ2EEサーバに分散されて転送されたとき

フレームを使用するアプリケーションの場合は，リクエスト処理が終わるまでのロック待ち時間も考慮して，タイムアウト時間を定義してください。

(8)　引き継ぎ可能なセッション情報のデータ型（GSInfoTypeByteArrayEnable，GSInfoTypeSerializableEnable）

引き継ぎ可能なセッション情報のデータ型には，java.lang.Stringクラスのオブジェクト，byte型配列，および直列化可能クラスのオブジェクトがあります。

データ型がbyte型配列，または直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とする場合には，次の設定を有効にします。

byte型配列であるセッション情報の引き継ぎ許可

直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可

これらの設定を無効にした場合は，java.lang.Stringクラスのオブジェクトだけが引き継ぎ可能なセッション情報となります。

(a)　byte型配列であるセッション情報の引き継ぎ許可

byte型配列のセッション情報を引き継ぎ対象とするかどうかをGSInfoTypeByteArrayEnableパラメタに指定します。「true」を指定した場合は，java.lang.Stringクラスのオブジェクトに加え，byte型配列のセッション情報も引き継ぎ対象となります。

「false」を指定した場合は，byte型配列のセッション情報は引き継ぎ対象外となります。引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「7.4.2(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(b)　直列化可能クラスのオブジェクトであるセッション情報の引き継ぎ許可

直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とするかどうかをGSInfoTypeSerializableEnableパラメタに指定します。「true」を指定した場合は，直列化可能クラスのオブジェクトであるセッション情報が引き継ぎ対象となります。この場合，java.lang.Stringクラスのオブジェクト，およびbyte型配列のセッション情報も区別なく，直列化可能クラスのオブジェクトであるセッション情報としてシリアライズして，グローバルセッション情報を作成します。

「false」を指定した場合は，直列化可能クラスのオブジェクトであるセッション情報は引き継ぎ対象外となります。引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「7.4.2(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(c)　引き継ぎ可能なセッション情報のデータ型を指定する場合の注意事項

GSInfoTypeByteArrayEnableパラメタとGSInfoTypeSerializableEnableパラメタの指定値によって，引き継ぎ対象となるデータ型が異なります。各パラメタに指定する値と引き継ぎ対象となるデータ型の関係を次の表に示します。

表7-23　GSInfoTypeByteArrayEnableおよびGSInfoTypeSerializableEnableパラメタに指定する値と引き継ぎ対象となるデータ型の関係

GSInfoTypeByteArrayEnableパラメタ※1に指定する値 | GSInfoTypeSerializableEnableパラメタ※2に「true」を指定 | GSInfoTypeSerializableEnableパラメタ※2に「false」を指定
true | 直列化可能クラスのオブジェクト | java.lang.Stringクラスのオブジェクトまたはbyte型配列
false | 直列化可能クラスのオブジェクト | java.lang.Stringクラスのオブジェクト

注※1　byte型配列のセッション情報を引き継ぎ対象とするかどうかを指定するパラメタです。

注※2　直列化可能クラスのオブジェクトであるセッション情報を引き継ぎ対象とするかどうかを指定するパラメタです。

なお，引き継ぎ対象外のオブジェクトが登録された場合の扱いについては，「7.4.2(3)　引き継ぎ対象外のオブジェクトの扱い」を参照してください。

(9)　統合ユーザ管理機能を使用する場合の設定

統合ユーザ管理機能を使用する場合に必要な設定について説明します。

(a)　統合ユーザ管理機能を使用する場合のグローバルセッション情報

統合ユーザ管理機能を使用する場合のセッション情報は，HTTPセッションに登録したあとで変更が必要になります。書き換え可能なグローバルセッション情報（GSInfoKey-RWパラメタ）を選択してください。また，GSInfoKey-RWパラメタには，「com.cosminexus.admin.auth.user_data」を設定してください。

(b)　統合ユーザ管理機能を使用する場合のグローバルセッション情報の最大サイズ

統合ユーザ管理機能を使用する場合のグローバルセッション情報の最大サイズの見積もり式を次に示します。

グローバルセッション情報の最大サイズ
　　＝統合ユーザ管理で使用する値
　　＋ユーザアプリケーションで使用する値

統合ユーザ管理で使用する値は，統合ユーザ管理フレームワークのAPIを使用する場合とタグライブラリを使用する場合で異なります。また，パスワード保存機能を使用するかどうかによっても異なります。それぞれの場合の統合ユーザ管理で使用する値の計算式を次に示します。

APIを使用し，パスワード保存機能を使用する場合

統合ユーザ管理で使用する値
　　＝｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋パスワードの最大長
　　＋1,200）×レルム数｝×2

APIを使用し，パスワード保存機能を使用しない場合

統合ユーザ管理で使用する値
　　＝｛1,500＋（レルム名の長さ＋ユーザ名の最大長＋1,200）×レルム数｝×2

タグライブラリを使用し，パスワード保存機能を使用する場合

統合ユーザ管理で使用する値
　　＝｛1,500＋（レルム名の長さ＋ユーザ名の最大長
　　＋loginタグのid属性値の長さ＋loginタグのentry属性値の長さ
　　＋パスワードの最大長＋1,200）×レルム数｝×2

タグライブラリを使用し，パスワード保存機能を使用しない場合

統合ユーザ管理で使用する値
　　＝｛1,500＋（レルム名の長さ＋ユーザ名の最大長
　　＋loginタグのid属性値の長さ＋loginタグのentry属性値の長さ
　　＋1,200）×レルム数｝×2

ポイント

計算式中の1,500と1,200は固定値です。統合ユーザ管理の管理情報を保存するために必要な値です。この値はオブジェクトをシリアライズしたときのバイト数の最大値を基に算出しています。

注意

セッションフェイルオーバ用フィルタの設定に誤りがある場合，セッションフェイルオーバが正しく行われませんので注意してください。

統合ユーザ管理では，GIDCookieNameパラメタが示す値を取得できたときに，統合ユーザ管理でのメモリセッションフェイルオーバ機能を有効にします。ただし，統合ユーザ管理からはセッションフェイルオーバ用フィルタの内容が正しいかをチェックできません。このため，フィルタの設定に誤りがあった場合，実際にフェイルオーバが発生するまで誤りに気づかないおそれがあります。

7.12.3　DDでの定義例

ここでは，DDの定義例として，HTTP Cookieによる制御の場合，URL書き換えによる制御の場合，および制御方法にbothを指定する場合を紹介します。

＜この項の構成＞

(1)　HTTP Cookieによる制御の場合

(2)　URL書き換えによる制御の場合

(3)　制御方法にbothを指定する場合

(4)　統合ユーザ管理機能を使用しない場合

(5)　統合ユーザ管理機能を使用する場合

(1)　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型配列のセッション情報を引き継ぎます。

(2)　URL書き換えによる制御の場合

メモリセッションフェイルオーバ機能を使用する場合のDDの定義例を示します。この例は，URL書き換えによってグローバルセッションを制御する場合の例です。

なお，ここでは，URL書き換えによる制御の場合に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」としています。

(3)　制御方法にbothを指定する場合

メモリセッションフェイルオーバ機能を使用する場合のDDの定義例を示します。この例は，制御方法としてGSessionControlに「both」を指定する場合の例です。bothは，WebクライアントがHTTP Cookieをサポートしているかどうかを判別して，必要に応じてHTTP Cookieによる制御とURL書き換えによる制御を切り替える方法です。

なお，ここでは，bothを指定する場合に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」としています。

(4)　統合ユーザ管理機能を使用しない場合

統合ユーザ管理機能を使用しない場合のDDでのフィルタ属性の記述例を次に示します。この例は，HTTP Cookieを使用してグローバルセッションを制御し，byte型配列のセッション情報を引き継ぐ場合の例です。

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>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>
　　　　：
　　 （省略）

DDでのWAR属性の記述例

　　 （省略）
　　　　：
<filter-mapping>
   <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
　　　　：
　　 （省略）

この記述例で設定される内容は，次のとおりです。

書き換え可能なグローバルセッション情報として，「page」の値を格納します。

読み取り専用のグローバルセッション情報として，「UserID」および「Roll」の2種類の値を格納します。

グローバルセッション情報の最大サイズとして，49を設定します。
最大サイズは，次の式で算出します。なお，ここでは，page（4文字）の値は1～2文字のASCII文字列，UserID（6文字）の値は1～12バイトのbyte型配列，roll（4文字）の値は1～7文字のASCII文字列とします。
（4＋4＋6）＋（2＋7＋（12＋5））＋（2×3-1）＋4＝49

グローバルセッション情報を格納するSFOサーバの名称は，「sfo_server1」とします。

グローバルセッションの制御には，HTTP Cookieを使用します。

グローバルセッションIDの送信に使用するCookieの名称は，「SFOSESSIONID」とします。

グローバルセッション情報のロック待ちタイムアウトは，「180秒」とします。

byte型配列のセッション情報を引き継ぐため，GSInfoTypeByteArrayEnableパラメタにtrueを指定します。

(5)　統合ユーザ管理機能を使用する場合

統合ユーザ管理機能を使用する場合のDDの記述例を次に示します。この例は，HTTP Cookieを使用してグローバルセッションを制御している場合の例です。

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>GSessionControl</param-name>
       <param-value>cookie</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>

   <init-param>
       <param-name>GSInfoTypeByteArrayEnable</param-name>
       <param-value>false</param-value>
   </init-param>

</filter>
　　　　：
　　 （省略）

DDでのWAR属性の記述例

　　 （省略）
　　　　：
<filter-mapping>
   <filter-name>com.hitachi.software.was.sfo.web.SFOFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
　　　　：
　　 （省略）

この記述例で設定される内容は，次のとおりです。

書き換え可能なグローバルセッション情報として，「com.cosminexus.admin.auth.user_data」の値を格納します。

グローバルセッション情報の最大サイズとして，10,380文字を設定します。
最大サイズは，次の式で算出します。
｛1,500＋(10＋20＋1,200)×3｝×2＝10,380
なお，ここでは，次の条件で最大サイズを算出しています。

APIを使用する。

パスワード保存機能は使用しない。

レルム名の長さ：10

ユーザ名の最大長：20

レルム数（シングルサインオンを使用するシステムの数）：3

グローバルセッション情報を格納するSFOサーバの名称は，「sfo_server1」とします。

グローバルセッションの制御には，HTTP Cookieを使用します。

グローバルセッションIDの送信に使用するCookieの名称は，「GSESSIONID」とします。

グローバルセッション情報のロック待ちタイムアウトは，「30」秒とします。

グローバルセッション情報として，byte型配列を使用しないため，GSInfoTypeByteArrayEnableパラメタにfalseを指定します。

7.13　cosminexus.xmlでの定義

メモリセッションフェイルオーバ機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

Webアプリケーションにセッションフェイルオーバ用フィルタを組み込むために，追加するフィルタ名称を指定します。<filter>-<filter-name>タグに次に示す固定値を指定してください。

設定値（固定値）

com.hitachi.software.was.sfo.web.SFOFilter

指定するタグの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.7　Filter属性の詳細」を参照してください。

ポイント

セッション情報の引き継ぎを行うWebアプリケーションを含むJ2EEアプリケーションの開始後にWebアプリケーションの設定を変更する場合，J2EEアプリケーションを再開始する前に，SFOサーバに登録されたWebアプリケーションの設定情報を削除する必要があります。SFOサーバに登録されたWebアプリケーションの設定情報の削除方法については，「7.17　Webアプリケーションの設定情報の削除」を参照してください。

7.14　J2EEサーバの設定

メモリセッションフェイルオーバ機能を使用する場合，J2EEサーバの設定が必要です。

＜この節の構成＞

7.14.1　J2EEサーバの設定内容

7.14.2　簡易構築定義ファイルでの定義

7.14.3　簡易構築定義ファイルのパラメタの設定要否

7.14.4　簡易構築定義ファイルの指定例

7.14.1　J2EEサーバの設定内容

セッション情報の引き継ぎを行うJ2EEサーバの設定内容について説明します。

セッション情報の引き継ぎを行うJ2EEサーバの設定では，簡易構築定義ファイルを編集して次に示す設定をします。

グローバルセッション情報を格納するSFOサーバの設定
セッション情報の引き継ぎを行うJ2EEサーバのグローバルセッション情報を格納するSFOサーバの名称，およびSFOサーバ用のCORBAネーミングサービスのIPアドレスを設定します。

SFOサーバとの通信タイムアウトの設定
J2EEサーバとSFOサーバとの通信タイムアウトを設定します。
通信タイムアウト時間の設定では，フルガーベージコレクションなどによる応答の遅延を考慮し，SFOサーバで発生した障害以外の原因でタイムアウトが発生しないように値を設定してください。
SFOサーバとの通信タイムアウトは，J2EEサーバがSFOサーバに障害が発生したと判断するために使用される時間です。設定したタイムアウト時間を超えると，J2EEサーバでは，SFOサーバは障害のため停止していると判断し，リトライを実行しません。
次の場合に，J2EEサーバがSFOサーバとの通信タイムアウトを検知して，SFOサーバに障害が発生したと判断します。

SFOサーバに障害が発生してSFOサーバとの通信が完了しなかった場合

フルガーベージコレクションなどでJ2EEサーバが高負荷状態となり，通信タイムアウトに設定した時間内にSFOサーバとの通信が完了しなかった場合

通信タイムアウトが発生してSFOサーバとの接続が一時的に切断された場合，再接続が発生します。

注意

通信タイムアウトが発生してSFOサーバとの接続が切断された場合の注意事項

SFOサーバに障害が発生して停止した場合，ビジネスメソッドの呼び出しができなくなります。
SFOサーバアプリケーションで用意しているコネクションの状態監視用のビジネスメソッドは，SFOサーバのヘルスチェックを実施するためにSFOサーバ監視スレッドによって呼び出されます。また，リクエスト実行時には，SFOサーバ上のグローバルセッション情報を操作するためのビジネスメソッドが呼び出されます。SFOサーバ監視スレッドは，J2EEサーバで作成されます。

SFOサーバとの接続が切断された場合は，SFOサーバがダウンした場合と同じ状態となります。切断中にJ2EEサーバがリクエストを受信した場合，そのリクエストのHTTPセッションに登録された書き換え可能グローバルセッション情報は削除されます。

HTTPセッションのセッションIDへのサーバIDの付加
HTTPセッションのセッションIDにサーバIDを付加する機能を有効にして，HTTPセッションのセッションIDに付加するサーバIDを設定します。

サーバIDのCookieの付加
HTTP Cookieによってグローバルセッションを制御する場合に，HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加する機能を有効にして，付加するサーバIDのCookieの名称を設定します。

リクエストラインの最大サイズの設定
URL書き換えによってグローバルセッションを制御する場合に，リクエストラインの最大サイズを設定します。URL書き換えによってグローバルセッションを制御する場合，URLのパスパラメタには，HTTPセッションのセッションIDとグローバルセッションIDが含まれます。HTTPリクエストのリクエストラインのサイズには，上限があります。このため，あらかじめリクエストラインの最大サイズを算出して，それを基にリクエストラインの最大サイズを設定する必要があります。
なお，リクエストラインの最大サイズをJ2EEサーバに設定するのは，インプロセスHTTPサーバを使用している場合です。Hitachi Web ServerまたはMicrosoft IISを使用している場合は，それぞれのWebサーバに設定します。
設定値の考え方および各Webサーバへの設定方法については，「7.7.5　リクエストラインの最大サイズの設定」を参照してください。

注意

J2EEサーバ間でのセッション情報の引き継ぎを行うために編集した，簡易構築定義ファイルのパラメタに不正な値が指定されていたり，必要なパラメタの指定が不足していたりした場合，J2EEサーバの起動時ではなく，セッション情報の引き継ぎ時にエラーが発生し，セッション情報の引き継ぎを行うWebアプリケーションを開始できません。

7.14.2　簡易構築定義ファイルでの定義

J2EEサーバの設定は，簡易構築定義ファイルで実施します。メモリセッションフェイルオーバ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのメモリセッションフェイルオーバ機能の定義について次の表に示します。

表7-24　簡易構築定義ファイルでのメモリセッションフェイルオーバ機能の定義

項目
指定するパラメタ
設定内容

グローバルセッション情報を格納するSFOサーバの設定
webserver.sfo.sfo_servers
HTTPセッションの情報の引き継ぎを行うJ2EEサーバのグローバルセッション情報を格納するSFOサーバの名称※1（セッションフェイルオーバ用フィルタのサーバ定義名）を指定します。

複数のSFOサーバにグローバルセッション情報を格納する場合
すべてのSFOサーバの名称（セッションフェイルオーバ用フィルタのサーバ定義名）を指定します。

SFOサーバに対して複数のセッションフェイルオーバ用フィルタのサーバ定義名を指定する場合
それぞれのSFOサーバに異なるセッションフェイルオーバ用フィルタのサーバ定義名を指定してください。複数のSFOサーバに同一のセッションフェイルオーバ用フィルタのサーバ定義名を指定することはできません。

複数のSFOサーバを指定する場合
一つ目に指定されたSFOサーバが，Webアプリケーションでの指定が省略された場合にデフォルトで使用するSFOサーバとなります。

webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.naming
webserver.sfo.sfo_serversパラメタに指定したSFOサーバで起動するCORBAネーミングサービスのIPアドレス（またはホスト名）およびポート番号を指定します。
複数のSFOサーバにグローバルセッション情報を格納する場合，それぞれのSFOサーバで起動するCORBAネーミングサービスのIPアドレス（またはホスト名）およびポート番号を指定します。

SFOサーバとの通信タイムアウトの設定
webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.connectionTimeout
J2EEサーバとSFOサーバとの通信タイムアウトを指定します。
複数のSFOサーバにグローバルセッション情報を格納する場合，それぞれのSFOサーバとの通信タイムアウトを指定します。

セッションIDへのサーバIDの付加
webserver.session.server_id.enabled
HTTPセッションのセッションIDにサーバIDを付加するかどうかを指定します。J2EEサーバ間でHTTPセッションの情報の引き継ぎを行う場合，「true」を指定します。

webserver.session.server_id.value※2
HTTPセッションのセッションIDに付加するサーバIDを指定します。
指定するサーバIDは，各J2EEサーバに対して一意な値としてください。HTTPセッションのセッションIDに設定されるサーバIDが，ほかのJ2EEサーバのサーバIDと重複した場合，SFOサーバとのネゴシエーションに失敗し，セッション情報の引き継ぎを行うWebアプリケーションは開始できません。

サーバIDのCookieの付加
（HTTP Cookieを使用する場合）※3
webserver.container.server_id.enabled
HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加するかどうかを指定します。同一セッションのリクエストを，同一のWebコンテナに転送する場合，「true」を指定します。

webserver.container.server_id.name
HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加する場合に，Cookieの名称を指定します。
Cookieに設定するサーバIDは，サーブレットやJSPで設定するCookieの名称，およびWebコンテナが自動設定するCookieの名称「JSESSIONID」と重複しないように注意してください。

webserver.container.server_id.value※2
HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加する場合に，Cookieの値を指定します。

リクエストラインの最大サイズの設定
（URL書き換えを使用する場合）※1
webserver.connector.inprocess_http.limit.max_request_line
リクエストラインの最大サイズを設定します。
なお，このパラメタはインプロセスHTTPサーバを使用している場合に設定するパラメタです。設定値の算出方法と，Hitachi Web ServerまたはMicrosoft IISを使用している場合の設定個所については，「7.7.5　リクエストラインの最大サイズの設定」を参照してください。

注※1

SFOサーバの名称（セッションフェイルオーバ用フィルタのサーバ定義名）は，セッション情報の引き継ぎを行うJ2EEサーバとWebアプリケーション間でのSFOサーバの識別に使用する名称です。指定したセッションフェイルオーバ用フィルタのサーバ定義名にSFOサーバ（論理サーバ）を関連づけて利用します。ここで指定したセッションフェイルオーバ用フィルタのサーバ定義名は，セッション情報の引き継ぎを行うWebアプリケーションの設定で使用します。セッション情報の引き継ぎを行うWebアプリケーションの設定については，「7.12　DDでの定義」を参照してください。

注※2

webserver.session.server_id.valueおよびwebserver.container.server_id.valueのデフォルト値には，サーバ環境の情報が含まれます。この値はクライアントに送信されるため，サーバ環境の情報を含まない値を明示的に指定することをお勧めします。

注※3

新たに負荷分散機を導入して，Webコンテナの機能でCookieによるリクエストの振り分けをする場合，HTTPセッションを生成したリクエストのレスポンスにサーバIDのCookieを付加する機能を有効にして，付加するサーバIDのCookieの名称およびCookieの値を設定します。

既存のアプリケーションで負荷分散機用にCookieの情報を設定している場合などは設定不要です。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

7.14.3　簡易構築定義ファイルのパラメタの設定要否

メモリセッションフェイルオーバ機能を使用する場合の簡易構築定義ファイルのパラメタの設定要否を次の表に示します。

表7-25　メモリセッションフェイルオーバ機能を使用する場合の簡易構築定義ファイルのパラメタの設定要否

簡易構築定義ファイルのパラメタ | パラメタの設定要否
webserver.sfo.sfo_servers | 必須
webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.naming | 必須
webserver.sfo.sfo_server.<セッションフェイルオーバ用フィルタのサーバ定義名>.connectionTimeout | 任意
webserver.session.server_id.enabled | 任意
webserver.session.server_id.value | 任意
webserver.container.server_id.enabled | 任意
webserver.container.server_id.name | 任意
webserver.container.server_id.value | 任意
webserver.connector.inprocess_http.limit.max_request_line | 任意

（凡例）

必須：必ず指定することを示す。省略した場合はエラーとなり，SFOサーバ用アプリケーションを開始できない。

任意：省略できることを示す。省略した場合はデフォルトの値が設定される。

7.14.4　簡易構築定義ファイルの指定例

セッション情報の引き継ぎに関連する簡易構築定義ファイルの指定例を次に示します。

 :
<tier>
 <tier-type>combined-tier</tier-type>
 <configuration>
   <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>webserver.container.server_id.enabled</param-name>
     <param-value>true</param-value>
   </param>
   <param>
     <param-name>webserver.sfo.sfo_servers</param-name>
     <param-value>sfo_server1,sfo_server2</param-value>
   </param>
   <param>
     <param-name>webserver.sfo.sfo_server.sfo_server1.naming</param-name>
     <param-value>host1:910</param-value>
   </param>
   <param>
     <param-name>webserver.sfo.sfo_server.sfo_server1.connectionTimeout</param-name>
     <param-value>5</param-value>
   </param>
   <param>
     <param-name>webserver.sfo.sfo_server.sfo_server2.naming</param-name>
     <param-value>host2:911</param-value>
   </param>
   <param>
     <param-name>webserver.sfo.sfo_server.sfo_server2.connectionTimeout</param-name>
     <param-value>10</param-value>
   </param>
     :
 </configuration>
   :
</tier>
<tier>
 <tier-type>sfo-tier</tier-type>
 <configuration>
   <logical-server-type>sfo-server</logical-server-type>
   <param>
     :
 </configuration>
 <configuration>
   <logical-server-type>performance-tracer</logical-server-type>
   <param>
     :
 </configuration>
</tier>
 :

この記述例で設定される内容は，次のとおりです。

SFOサーバとして，「sfo_server1」および「sfo_server2」の二つを使用します。

Webアプリケーションにグローバルセッション情報を格納するSFOサーバを指定していない場合，デフォルトで「sfo_server1」を使用します。

「sfo_server1」の稼働ホストは「host1」であり，使用するCORBAネーミングサービスのポート番号は「910」です。

「sfo_server1」との通信タイムアウトを「5秒」に設定し，通信時間が5秒を超えた場合は「sfo_server1」で障害が発生したと判断します。

「sfo_server2」の稼働ホストは「host2」であり，使用するCORBAネーミングサービスのポート番号は「911」です。

「sfo_server2」との通信タイムアウトを「10秒」に設定し，通信時間が10秒を超えた場合は「sfo_server2」で障害が発生したと判断します。

7.15　SFOサーバの設定

SFOサーバが使用するネーミングサービス，PRFデーモン，ログ，セキュリティなどの基本設定や，SFOサーバのJavaVMの起動オプションの設定を変更する場合に，必要に応じて実施してください。

注意

CTMを使用している場合，CTMを使用したリクエストのスケジューリングを無効にする必要があります。論理SFOサーバ（sfo-server）の<configuration>タグ内に，ejbserver.ctm.enabledで「true」が指定されている場合，「false」に変更してください。

＜この節の構成＞

7.15.1　簡易構築定義ファイルでの定義

7.15.2　SFOサーバの起動オプションの設定

7.15.1　簡易構築定義ファイルでの定義

SFOサーバの設定は，簡易構築定義ファイルで実施します。メモリセッションフェイルオーバ機能の定義は，簡易構築定義ファイルの論理SFOサーバ（sfo-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのメモリセッションフェイルオーバ機能の定義について次の表に示します。なお，ここで説明していないパラメタは編集しないでください。

表7-26　簡易構築定義ファイルでのメモリセッションフェイルオーバ機能の定義

項目
指定するパラメタ
設定内容

CORBAネーミングサービス
ejbserver.naming.port
利用するCORBAネーミングサービスのポート番号を指定します。

EJBコンテナ
ejbserver.container.remove.scan.interval
Stateful Session Beanのタイムアウトやプールの状態を監視するスレッドの起動間隔を指定します。

Webサーバ

ejbserver.http.port

webserver.connector.http.permitted.hosts

webserver.connector.http.bind_host

簡易Webサーバのポート番号，簡易Webサーバへのアクセスを許可するホストや，簡易Webサーバで使用するホストを指定します。

webserver.connector.ajp13.port

webserver.connector.ajp13.bind_host

webserver.connector.ajp13.max_threads※1

Webサーバとの通信ポート番号や，Webサーバ連携で使用するホストを指定します。

PRFデーモン
ejbserver.server.prf.PRFID
利用するPRFデーモンを指定します。

リソース枯渇監視

ejbserver.watch.enabled

ejbserver.watch.memory.enabled

ejbserver.watch.memory.interval

ejbserver.watch.memory.threshold

ejbserver.watch.memory.writefile.enabled

ejbserver.watch.fileDescriptor.enabled※2

ejbserver.watch.fileDescriptor.interval※2

ejbserver.watch.fileDescriptor.threshold※2

ejbserver.watch.fileDescriptor.writefile.enabled※2

ejbserver.watch.thread.enabled

ejbserver.watch.thread.interval

ejbserver.watch.thread.threshold

ejbserver.watch.thread.writefile.enabled

ejbserver.watch.threaddump.enabled

ejbserver.watch.threaddump.interval

ejbserver.watch.threaddump.threshold

ejbserver.watch.threaddump.writefile.enabled

ejbserver.watch.defaultRequestQueue.enabled※3

ejbserver.watch.defaultRequestQueue.interval

ejbserver.watch.defaultRequestQueue.threshold

ejbserver.watch.defaultRequestQueue.writefile.enabled※3

リソース枯渇監視機能の使用の有無，リソースの監視間隔やしきい値を指定します。
リソース枯渇監視機能の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「4.3.3　実行環境での設定」を参照してください。

SFOサーバのログ

ejbserver.logger.enabled.*

ejbserver.logger.channels.define.＜チャネル名＞※4.filenum

ejbserver.logger.channels.define.＜チャネル名＞※4.filesize

ejbserver.logger.systemlog.enabled

SFOサーバのログのファイル面数，ファイルサイズや，ログレベルを指定します。また，SFOサーバのログのイベントログ（UNIXの場合，syslog）への出力の有無を指定します。

スレッドダンプ出力
ejbserver.server.threaddump.filenum
J2EEサーバが障害を検知して自発的にスレッドダンプを出力する場合の
スレッドダンプのファイル数の上限を指定します。

Cosminexus TPBrokerのトレース

vbroker.orb.htc.comt.entryCount

vbroker.orb.htc.comt.fileCount

vbroker.orb.htc.tracePath

Cosminexus TPBrokerのトレースファイルの出力先，ファイル数や，エントリ数を指定します。

Cosminexus TPBrokerのオプション

vbroker.se.iiop_tp.host

vbroker.se.iiop_tp.scm.iiop_tp.listener.port

EJBコンテナの通信ポート，およびIPアドレスを固定する場合に，任意の値を指定します。

注※1

SFOサーバではWebアプリケーションでリクエストを処理することがないため，このパラメタに指定する値を小さくすることでSFOサーバが作成するスレッド数を減らすことができます。値に最小値「1」を設定することをお勧めします。

注※2

UNIXの場合に指定できるパラメタです。

注※3

SFOサーバではWebアプリケーションを実行しないため，HTTPリクエスト実行待ちキュー監視は不要です。値に「false」を設定して監視を無効にすることをお勧めします。

注※4

チャネル名には，種別ごとのチャネル名を指定します。

MessageLogFile，MaintenanceLogFile，ExceptionLogFile，ConsoleLogFile，EJBContainerLogFile，MemoryWatchLogFile，FileDescriptorWatchLogFile，ThreadWatchLogFile，RequestQueueWatchLogFile

簡易構築定義ファイルおよび指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

7.15.2　SFOサーバの起動オプションの設定

SFOサーバでは，Webアプリケーションのグローバルセッション情報の冗長化を開始する前に，グローバルセッション情報を格納するために必要な領域を確保します。このとき確保したメモリは，Webアプリケーションのグローバルセッション情報の冗長化が終了するまで解放されないで，JavaVMのTenured領域に格納されます。

JavaVMでは，Tenured領域の使用状態や，New領域の最大値に対するTenured領域の空き容量などを基に，フルガーベージコレクションを発生させます。SFOサーバでは，フルガーベージコレクションの発生を防ぐために，Webアプリケーションのグローバルセッション情報の冗長化で使用するTenured領域メモリサイズや，SFOサーバが使用するTenured領域のメモリサイズなど，Tenured領域に格納されるオブジェクトのメモリサイズを基に，JavaVMのTenured領域，New領域のサイズをチューニングする必要があります。

JavaVMのTenured領域，New領域のサイズは，簡易構築定義ファイルの論理SFOサーバ（sfo-server）の<configuration>タグ内に，JavaVM起動パラメタで定義します。JavaVM起動パラメタの指定内容を次に示します。

<param-name>タグ

add.jvm.arg

<param-value>タグ

-Xmx（設定値）

-XX:NewRatio=（設定値）

注意

JavaVMの領域をチューニングする場合は，JavaVMのガーベージコレクションログを確認して，SFOサーバの運用でフルガーベージコレクションが発生しないことを確認してください。

Webアプリケーションのグローバルセッション情報の冗長化で使用するTenured領域のメモリサイズ，およびSFOサーバが使用するTenured領域のメモリサイズの見積もり式を次に示します。

Webアプリケーションのグローバルセッション情報の冗長化で使用するTenured領域のメモリサイズの見積もり式

A＝｛(B＋500)×C×1.2÷(1,024×1,024)｝＋D×5

（凡例）

A：Webアプリケーションのグローバルセッション情報の冗長化で使用するTenured領域のメモリサイズ（単位：メガバイト）

B：グローバルセッション情報の最大サイズ（単位：バイト）※1

C：HTTPセッション数の上限値※2

D：接続するJ2EEサーバの数

注※1

Webアプリケーションのフィルタ属性ファイルまたはDD（web.xml）のGSInfosLengthMaxパラメタに指定した値です。グローバルセッション情報の最大サイズの詳細については，「7.12.2(2)　グローバルセッション情報の最大サイズ（GSInfosLengthMax）」を参照してください。

注※2

WebアプリケーションのWAR属性ファイルの<http-session-max-number>タグに指定する値です。HTTPセッション数の上限値の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。

SFOサーバが使用するTenured領域のメモリサイズの見積もり式

SFOサーバが使用するTenured領域のメモリサイズ＝A＋50

（凡例）

A：各Webアプリケーションのグローバルセッション情報の冗長化で使用するTenured領域のメモリサイズの合計（単位：メガバイト）

7.16　Webアプリケーションの設定

メモリセッションフェイルオーバ機能を使用する場合，Webアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

ポイント

セッション情報の引き継ぎを行うWebアプリケーションを含むJ2EEアプリケーションの開始後にWebアプリケーションの設定を変更する場合，J2EEアプリケーションを再開始する前に，SFOサーバに登録されたWebアプリケーションの設定情報を削除する必要があります。SFOサーバに登録されたWebアプリケーションの設定情報の削除方法については，「7.17　Webアプリケーションの設定情報の削除」を参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。メモリセッションフェイルオーバ機能の定義には，フィルタ属性ファイルおよびWAR属性ファイルを使用します。

フィルタ属性ファイルおよびWAR属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DD（web.xml）およびcosminexus.xmlでの定義については，「7.12　DDでの定義」および「7.13　cosminexus.xmlでの定義」を参照してください。

属性ファイルを編集してフィルタを組み込む場合，フィルタ属性ファイルおよびWAR属性ファイルに，Webアプリケーションにセッションフェイルオーバ用フィルタを組み込むための設定をします。属性ファイルの取得，編集した属性ファイルの設定の手順については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

7.17　Webアプリケーションの設定情報の削除

セッション情報の引き継ぎを行うWebアプリケーションを含むJ2EEアプリケーションの開始時に，SFOサーバにWebアプリケーションの設定情報が登録されます。このため，J2EEアプリケーションの開始後にWebアプリケーションの設定を変更する場合，J2EEアプリケーションを再開始する前に，SFOサーバに登録されたWebアプリケーションの設定情報を削除する必要があります。

ここでは，Webアプリケーションの設定情報を削除するときの手順について説明します。

Webアプリケーションの設定情報の削除手順を次の図に示します。

図7-35　Webアプリケーションの設定情報の削除手順

図中の1.～5.について説明します。

設定を変更するWebアプリケーションを含むJ2EEアプリケーションをすべて停止します。
J2EEアプリケーションの停止方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.2　J2EEアプリケーションの停止」を参照してください。

SFOサーバが配置されているサービスユニットを停止します。
サービスユニット内のSFOサーバも停止されます。サービスユニットの停止には，Smart Composer機能のコマンドを使用します。サービスユニットの停止方法については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「9.3　日常運用の操作」を参照してください。

Webアプリケーションの設定を変更します。
セッション情報の引き継ぎを行うWebアプリケーションの設定については，「7.12　DDでの定義」および「7.13　cosminexus.xmlでの定義」を参照してください。

参考

サービスユニット開始後にWebアプリケーションの設定変更をしたい場合は，「7.16　Webアプリケーションの設定」を参照してください。

手順2で停止したサービスユニットを開始します。
サービスユニット内のSFOサーバも開始されます。SFOサーバの再開始によって，SFOサーバに登録されているWebアプリケーションの設定情報は，すべて削除されます。サービスユニットの開始には，Smart Composer機能のコマンドを使用します。サービスユニットの開始方法については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「9.3　日常運用の操作」を参照してください。

注意

SFOサーバを再開始すると，SFOサーバに冗長化されているグローバルセッション情報もすべて削除されるため注意が必要です。また，SFOサーバで複数のWebアプリケーションのグローバルセッション情報を冗長化している場合，すべてのWebアプリケーションの設定情報，およびグローバルセッション情報が削除されるため注意してください。

Webアプリケーションの設定変更が完了したら，J2EEアプリケーションを再開始します。
J2EEアプリケーションの開始方法については，マニュアル「Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.1　J2EEアプリケーションの開始」を参照してください。

8.　明示管理ヒープ機能を使用したフルガーベージコレクションの抑止

アプリケーションサーバでは，Javaアプリケーション実行時に，Javaオブジェクトの配置先としてJavaヒープとは別のメモリ空間を使用できます。この機能を明示管理ヒープ機能といいます。明示管理ヒープ機能を効果的に使用することで，フルガーベージコレクションの発生を抑止できます。

この章では，明示管理ヒープ機能を使用したフルガーベージコレクションの抑止について説明します。

なお，コピーガーベージコレクションの種類として-XX:+UseParNewGCオプションを指定している場合，明示管理ヒープ機能は使用できません。

＜この章の構成＞

8.1　この章の構成

8.2　明示管理ヒープ機能の概要

8.3　明示管理ヒープ機能で使用するメモリ空間の概要

8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト

8.5　アプリケーションで任意にExplicitヒープに配置できるオブジェクト

8.6　Explicitメモリブロックのライフサイクルと実行される処理

8.7　自動解放機能が有効な場合のExplicitメモリブロックの解放

8.8　自動解放機能が無効な場合のExplicitメモリブロックの解放

8.9　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減

8.10　明示管理ヒープ機能APIを使ったJavaプログラムの実装

8.11　実行環境での設定

8.12　明示管理ヒープ機能使用時の注意事項

8.1　この章の構成

明示管理ヒープ機能は，Javaオブジェクトの配置先としてJavaヒープ外の領域（Explicitヒープ）を使用することで，フルガーベージコレクションの発生を抑止する機能です。

この章の構成を次の表に示します。

表8-1　この章の構成（明示管理ヒープ機能を使用したフルガーベージコレクションの抑止）

分類 | タイトル | 参照先
解説 | 明示管理ヒープ機能の概要 | 8.2
明示管理ヒープ機能で使用するメモリ空間の概要 | 8.3
J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト | 8.4
アプリケーションで任意にExplicitヒープに配置できるオブジェクト | 8.5
Explicitメモリブロックのライフサイクルと実行される処理 | 8.6
自動解放機能が有効な場合のExplicitメモリブロックの解放 | 8.7
自動解放機能が無効な場合のExplicitメモリブロックの解放 | 8.8
HTTPセッションで利用するExplicitヒープのメモリ使用量の削減 | 8.9
実装 | 明示管理ヒープ機能APIを使ったJavaプログラムの実装 | 8.10
設定 | 実行環境での設定 | 8.11
注意事項 | 明示管理ヒープ機能使用時の注意事項 | 8.12

注　「運用」について，この機能固有の説明はありません。

なお，ガーベージコレクションの仕組みについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

8.2　明示管理ヒープ機能の概要

この節では，明示管理ヒープ機能の概要について説明します。

＜この節の構成＞

8.2.1　明示管理ヒープ機能を利用する目的

8.2.2　明示管理ヒープ機能の利用によるフルガーベージコレクションの抑止の仕組み

8.2.3　明示管理ヒープ機能を利用する場合の前提条件

8.2.1　明示管理ヒープ機能を利用する目的

明示管理ヒープ機能は，フルガーベージコレクションの発生を抑止する機能です。この機能を使用することで，システムが停止する回数を低減し，安定したスループットを実現します。

システムで扱う論理アドレス空間の増加やシステム規模の拡大などによって，アプリケーションサーバで扱うJavaヒープのサイズは増加しています。Javaヒープのサイズの増加に伴って問題になるのは，ガーベージコレクションの実行に掛かる時間の増加です。ガーベージコレクションが実行されている間，システムは停止します。特に，フルガーベージコレクションの実行時間は，使用済みのJavaヒープのサイズに応じて増加します。使用できるJavaヒープのサイズの増加に従って，フルガーベージコレクションに掛かる時間も増えるおそれがあります。

参考

ガーベージコレクションのアルゴリズムとシステム停止時間の関係

日立のJavaVMでは，コピーガーベージコレクションのアルゴリズムとしてCopyアルゴリズム，フルガーベージコレクションのアルゴリズムとしてMark Sweep Compactアルゴリズムを採用しています。これらのアルゴリズムは，Stop The World型のアルゴリズムです。Stop The World型では，ガーベージコレクションの実行に掛かる時間は，そのJavaVMを利用したシステムが停止する時間と等しくなります。

8.2.2　明示管理ヒープ機能の利用によるフルガーベージコレクションの抑止の仕組み

明示管理ヒープ機能では，Javaオブジェクトの配置先として，Explicitヒープという独自の領域を使用します。Explicitヒープは，Javaヒープ外にある，ガーベージコレクションの対象にならない領域です。明示管理ヒープ機能を使用していない場合にJavaヒープに配置していたJavaオブジェクトをExplicitヒープに配置することによって，フルガーベージコレクションが発生することを抑止できます。

ここでは，明示管理ヒープ機能を利用してフルガーベージコレクションを抑止する仕組みについて説明します。また，明示管理ヒープ機能の位置づけについてもあわせて説明します。

＜この項の構成＞

(1)　フルガーベージコレクション発生を抑止する仕組み

(2)　明示管理ヒープ機能の位置づけ

(3)　明示管理ヒープ機能を使用する場合に必要なメモリサイズ

(1)　フルガーベージコレクション発生を抑止する仕組み

Javaアプリケーション実行中にEden領域に空き領域がなくなると，ガーベージコレクションが発生します。このとき，次の式が成り立つ場合は，JavaVMによってフルガーベージコレクションが実行されます。

New領域で使用されているメモリのサイズ＞Tenured領域の空き領域のサイズ

注

Eden領域に空き領域がなくなっているため，New領域で使用されているメモリのサイズはNew領域の最大サイズにほぼ等しくなります。

式が示すとおり，Tenured領域の空き領域のサイズが小さくなるとフルガーベージコレクションが発生します。Tenured領域の空き領域は，コピーガーベージコレクションが発生したときにSurvivor領域から移動（昇格）するJavaオブジェクトによって使用されます。つまり，昇格するJavaオブジェクトを削減できれば，フルガーベージコレクションの発生を抑えられます。なお，何回かのコピーガーベージコレクションの実行で削除されないで，昇格の対象になるオブジェクトを長寿命オブジェクトといいます。

長寿命オブジェクトには大きく分けて2種類あります。一つは，フルガーベージコレクションで回収されないオブジェクトです。例えばアプリケーションの実行中は常に生存し続けるような，本来Tenured領域に格納される必要があるオブジェクトが当てはまります。このようなオブジェクトは増加し続けることはないため，フルガーベージコレクションが発生する本質的な原因ではありません。このような長寿命オブジェクトの影響を排除したい場合は，Tenured領域のサイズを増加することで対処できます。

二つ目は，フルガーベージコレクションで回収されるオブジェクトです。フルガーベージコレクションで回収される長寿命オブジェクトとは，Tenured領域に昇格する程度に長寿命であるが，一定期間で不要となるオブジェクトを指します。このような長寿命オブジェクトはフルガーベージコレクションの発生までは増加し続けるため，フルガーベージコレクション発生の原因となります。

フルガーベージコレクションで回収されるオブジェクト，およびフルガーベージコレクションで回収されないオブジェクトについて，次の図で説明します。

図8-1　フルガーベージコレクションで回収されるオブジェクト，およびフルガーベージコレクションで回収されないオブジェクト

一定期間で不要となるオブジェクトの増加を防ぐ対策として，Tenured領域のサイズを増加しただけでは，効果がありません。Tenured領域のサイズを2倍にしても，フルガーベージコレクションの発生間隔が2倍になるだけで，期待するほどの効果は得られません。

つまり，フルガーベージコレクションの発生を抑止するためには，一定期間で不要となるオブジェクトのTenured領域への昇格を減らすことがポイントとなります。

アプリケーションサーバでは，一部のJavaオブジェクトについて，コピーガーベージコレクション発生時の昇格先がExplicitヒープになるように設定されています。明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違いを次の図に示します。

図8-2　明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違い

図の1.のタイミングでは，どちらの場合も同じ状態です。2.のオブジェクトが昇格するタイミングで，明示管理ヒープ機能を使用していない場合の昇格では，すべての長寿命オブジェクトがTenured領域に移動します。一方，明示管理ヒープ機能を使用している場合，長寿命オブジェクトのうち，一定期間後に破棄されることがわかっているオブジェクトについてはExplicitヒープに移動します。これによって，Tenured領域に移動するのは，破棄される予定がない長寿命オブジェクトに限定され，Tenured領域の使用済みサイズの増加が緩やかになります。なお，3.で示すとおり，明示管理ヒープ機能を使用している場合のExplicitヒープのオブジェクトは，不要になったタイミングで削除されます。

対象となるJavaオブジェクトについては，「8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。また，ガーベージコレクションのアルゴリズムについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

なお，ユーザが開発するアプリケーションで明示管理ヒープ機能を使用する場合は，一定期間後に破棄される長寿命オブジェクトを，直接Explicitヒープに生成します。これによって，Tenured領域のメモリサイズ増加を防ぎます。Explicitヒープに生成できるJavaオブジェクトについては，「8.5　アプリケーションで任意にExplicitヒープに配置できるオブジェクト」を参照してください。

(2)　明示管理ヒープ機能の位置づけ

明示管理ヒープ機能は，日立のJavaVMの機能です。明示管理ヒープ機能を利用する方法には，次の2種類があります。

明示管理ヒープ自動配置設定ファイルを使う方法

明示管理ヒープ機能APIを使う方法

明示管理ヒープ機能の位置づけを次の図に示します。

図8-3　明示管理ヒープ機能の位置づけ

明示管理ヒープ機能の範囲である，明示管理ヒープ機能API，自動配置設定ファイル，明示管理ヒープ機能を構成する各機能，Tenured領域内不要オブジェクト統計機能，およびExplicitヒープについて説明します。

自動配置設定ファイル

Javaプログラムを変更しないで明示管理ヒープ機能を使用する場合，自動配置設定ファイルを使用します。このファイルに明示管理ヒープに配置させたいオブジェクトを指定します。

明示管理ヒープ機能API

Javaプログラムから明示管理ヒープ機能を使用する場合，明示管理ヒープ機能APIを使用します。このAPIでは，Explicitヒープに関連する操作が実行できます。また，Explicitヒープの使用状況を稼働情報として収集することもできます。

明示管理ヒープ機能を構成する各機能

明示管理ヒープ機能を構成する各機能は，JavaVMに含まれます。APIで呼び出されます。次の処理を実行できます。

Explicitヒープおよびヒープ内のメモリブロックの管理および制御

ガーベージコレクションと連携したアロケーション処理の変更によるExplicitヒープへのオブジェクトの配置
なお，アロケーション処理はnewキーワードの延長で実行されます。

日立JavaVMログファイルとスレッドダンプへのExplicitヒープのイベントログおよび状態の出力

Tenured領域内不要オブジェクト統計機能

Tenured領域内でメモリ増加の原因となっている不要オブジェクトを調査します。Tenured領域内不要オブジェクト統計機能については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「8.8　Tenured領域内不要オブジェクト統計機能」を参照してください。

Explicitヒープ

ガーベージコレクションの対象外にするJavaオブジェクトの配置先になる領域です。明示管理ヒープ機能が管理します。Explicitヒープは，複数のメモリブロック（Explicitメモリブロック）で構成されます。

(3)　明示管理ヒープ機能を使用する場合に必要なメモリサイズ

明示管理ヒープ機能で管理するExplicitヒープは，Javaヒープ外の領域です。Explicitヒープを使用する場合，使用しない場合に比べて，メモリの使用量が増加します。

明示管理ヒープ機能を使用する場合は，必要なメモリサイズとしてExplicitヒープの最大サイズを見積もり，適切に設定する必要があります。明示管理ヒープ機能を利用する流れ，Explicitヒープに格納するオブジェクト（Tenured領域のメモリサイズ増加の要因になるオブジェクト），およびExplicitヒープのサイズの見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.10　Explicitヒープのチューニング」を参照してください。

8.2.3　明示管理ヒープ機能を利用する場合の前提条件

ここでは，明示管理ヒープ機能を利用する場合の前提条件について説明します。明示管理ヒープ機能は，サーバまたはコマンドごとに，使用可否が異なります。

明示管理ヒープ機能のサポート有無を次の表に示します。デフォルトの設定については，「8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」を参照してください。

表8-2　明示管理ヒープ機能のサポート有無

サーバまたはコマンドの種類 | サポート有無
J2EEサーバ | ○
バッチサーバ | ○
SFOサーバ | ×
cjclstartapコマンド | ○

（凡例）

○：サポートされています。

×：サポートされていません。

また，HTTPセッションに関するオブジェクトおよびWebコンテナとリダイレクタ間の通信に使用するオブジェクトに対して明示管理ヒープ機能を使用できるかどうかは，使用するWebサーバの種類によって異なります。

Webサーバの種類と明示管理ヒープ機能の使用可否を次の表に示します。

表8-3　Webサーバの種類と明示管理ヒープ機能の使用可否

Webサーバの種類 | HTTPセッションに関するオブジェクト | Webコンテナとリダイレクタ間の通信に使用するオブジェクト
Hitachi Web Server | ○ | ○
Microsoft IIS | ○ | ○
インプロセスHTTPサーバ | ○ | －
簡易Webサーバ | － | －

（凡例）

○：使用できます。デフォルトで有効になります。

－：使用できません。または該当しません。

8.3　明示管理ヒープ機能で使用するメモリ空間の概要

この節では，明示管理ヒープ機能で使用するメモリ空間であるExplicitヒープの構造について説明します。なお，JavaVMで使用するメモリ空間の構成については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション」もあわせて参照してください。

Explicitヒープは，ガーベージコレクションの対象にならないメモリ空間です。複数のメモリブロックで構成されます。Explicitヒープを構成するメモリブロックをExplicitメモリブロックといいます。Explicitヒープは，Explicitメモリブロック全体を表す概念です。

初期化や解放などの操作は，Explicitメモリブロック単位で実行します。

Explicitヒープの概念を次の図に示します。

図8-4　Explicitヒープの概念

Explicitヒープの最大サイズは，JavaVM起動オプションの-XX:HitachiExplicitHeapMaxSizeオプションで設定します。-XX:HitachiExplicitHeapMaxSizeオプションの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:HitachiExplicitHeapMaxSize（Explicitメモリブロックの最大サイズ指定オプション）」を参照してください。生成（初期化）できるExplicitメモリブロックの数は，最大1,048,575個です。この数を超えて生成することはできません。

メモリを確保する方法には，JavaVM起動時に一括してメモリ領域を確保する方法，および必要になったタイミングでメモリ領域を確保する方法の2種類があります。それぞれについて説明します。

JavaVM起動時に一括してメモリ領域を確保する方法

明示管理ヒープの自動配置機能を使用している場合（-XX:+HitachiAutoExplicitMemoryオプションを指定している場合），または64ビット版のアプリケーションサーバを使用している場合が該当します。

-XX:HitachiExplicitHeapMaxSizeオプションで指定したExplicitヒープの最大サイズの実メモリ領域が，JavaVMを起動したタイミングで確保されます。領域は，JavaヒープおよびPermanent領域からの連続領域として確保されます。

JavaオブジェクトをExplicitメモリブロックに配置するために必要なメモリが不足している場合，JavaVM起動時に確保したExplicitヒープの領域から，Explicitメモリブロック向けのメモリ領域を確保します。このため，Explicitメモリブロック内のメモリ領域は複数の領域に分かれていることがあります。

仮想メモリ空間の利用イメージを次の図に示します。

図8-5　仮想メモリ空間の利用イメージ（64ビット版の場合）

Explicitヒープ用の領域は連続領域になりますが，一つのExplicitメモリブロックで使用する領域が，非連続になります。

必要になったタイミングでメモリ領域を確保する方法

明示管理ヒープの自動配置機能を使用していない場合（-XX:-HitachiAutoExplicitMemoryオプションを指定している場合），かつ32ビット版のアプリケーションサーバを使用している場合が該当します。

この場合，メモリ確保は一括で行われません。Explicitメモリブロックがメモリを必要とした時点で確保されます。このため，Explicitヒープは非連続領域になります。

オブジェクトをExplicitメモリブロックに配置するために必要なメモリが不足している場合，OSから随時メモリ領域が確保されます。このため，Explicitメモリブロック内のメモリ領域も複数の領域に分かれていることがあります。

仮想メモリ空間の利用イメージを次の図に示します。

図8-6　仮想メモリ空間の利用イメージ（32ビット版の場合）

Explicitヒープ用の領域および一つのExplicitメモリブロックで使用する領域が，非連続になります。

8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト

この節では，J2EEサーバ利用時にExplicitヒープに配置されるオブジェクトについて説明します。

J2EEサーバでは，フルガーベージコレクションの発生を抑止するために，次のオブジェクトをExplicitヒープに配置します。

HTTPセッションに関するオブジェクト

リダイレクタとの通信用オブジェクト

Explicitメモリブロック領域の確保やExplicitメモリブロックの解放予約は，Webコンテナが実行します。ここでは，それぞれのオブジェクトに対してWebコンテナによって実行される処理について説明します。

＜この節の構成＞

8.4.1　HTTPセッションに関するオブジェクト

8.4.2　リダイレクタとの通信用オブジェクト

8.4.1　HTTPセッションに関するオブジェクト

HTTPセッションに格納するオブジェクトは，セッションが有効な間保持されるオブジェクトです。生存期間は，セッションの生成から破棄までの間です。

このオブジェクトは，明示管理ヒープ機能を使用していない場合，何回かのコピーガーベージコレクションが実行される間使用され続けることが多いオブジェクトです。このため，長寿命オブジェクトとしてTenured領域に昇格しやすくなります。Tenured領域に昇格したオブジェクトはコピーガーベージコレクションでは回収されないため，このオブジェクトはセッションが破棄されたあとも回収されません。このため，Tenured領域のメモリ使用量が増加していき，フルガーベージコレクションが発生します。

明示管理ヒープ機能を利用していない場合の例を次の図に示します。

図8-7　明示管理ヒープ機能を利用していない場合の例

1.でセッションを生成すると，New領域にオブジェクトを格納するための領域が確保されます。2.でセッションにオブジェクトが格納されます。何回かのコピーガーベージコレクションのあと，1.および2.のオブジェクトはTenured領域に移動します。3.でセッションが無効化された場合も，Tenured領域のオブジェクトは回収されないため，メモリ使用量が増加していきます。

これに対して，HTTPセッションに関するオブジェクトの昇格先をTenured領域からExplicitヒープに変更することによって，フルガーベージコレクション発生を抑止できます。

明示管理ヒープ機能を利用した例を次の図に示します。

図8-8　明示管理ヒープ機能を利用した例

明示管理ヒープ機能を使用すると，HTTPセッションに関するオブジェクトによるTenured領域の増加がありません。このため，フルガーベージコレクション発生を抑止できます。なお，Explicitヒープに配置したJavaオブジェクトは，セッションが破棄されたあと，J2EEサーバによって明示的に解放されます。

HTTPセッションを配置するExplicitメモリブロック領域の確保および解放のタイミングについて説明します。

HTTPセッションを作成したとき

新しくHTTPセッションを作成すると，Explicitヒープ領域にExplicitメモリブロックが作成されます。Explicitメモリブロックは，1セッションに一つ割り当てられます。また，HTTPセッションが，Explicitメモリブロック内に確保されます。

ただし，セッション作成直後のオブジェクトの配置先はJavaヒープです。何回かのコピーガーベージコレクションのあと，該当するJavaオブジェクトが昇格するタイミングで，オブジェクトがExplicitヒープに移動します。

HTTPセッションにオブジェクトが格納されたとき（setAttributeメソッドを実行したとき）

javax.servlet.http.HttpSession.setAttributeメソッドでHTTPセッションに格納したオブジェクトは，セッションごとに割り当てられたExplicitメモリブロックに配置されます。

ただし，setAttributeメソッド実行時のオブジェクトの配置先はJavaヒープです。何回かのコピーガーベージコレクションのあと，該当するJavaオブジェクトが昇格するタイミングで，オブジェクトがExplicitヒープに移動します。このとき，移動するオブジェクトから参照されているオブジェクトは，すべてExplicitヒープに移動します。

HTTPセッションからオブジェクトが削除されたとき（removeAttributeメソッドを実行したとき）

Explicitヒープは，ガーベージコレクションの対象外です。このため，javax.servlet.http.HttpSession.removeAttributeメソッドを実行してHTTPセッションからオブジェクトを削除しても，オブジェクトが使用していた領域は解放されません。

なお，setAttributeメソッドで属性を変更した場合も，変更前の属性はガーベージコレクションの対象にならないため，オブジェクトが使用していた領域は解放されません。

メモリの解放は，Explicitメモリブロック単位で実行されます。setAttributeメソッドを繰り返し頻繁に実行するようなWebアプリケーションの場合，removeAttributeメソッドを実行してもExplicitメモリブロック内の領域を不要に消費してしまうおそれがありますので，注意してください。

HTTPセッションが破棄されるとき

HTTPセッション作成時に作成されたExplicitメモリブロックは，HTTPセッションが破棄されるときに，Webコンテナによって解放が予約されます。

解放が予約されたExplicitメモリブロックは，そのあとでコピーガーベージコレクションまたはフルガーベージコレクションが実行されたときに，実際に解放されます。このとき，解放が予約されたすべての領域が解放されます。

なお，Explicitメモリブロックを解放したあとで，セッションに格納したオブジェクトへの参照が残っていた場合，そのオブジェクトはJavaヒープに移動します。

Webアプリケーションで実行される操作または動作とJavaVMの動作の対応を次の表に示します。

表8-4　Webアプリケーションで実行される操作（API）とJavaVMの動作の対応

Webアプリケーションで実行される操作（API）または動作
Webコンテナの動作
JavaVMの動作

javax.servlet.http.HttpServletRequest.getSession()

javax.servlet.http.HttpServletRequest.getSession(boolean)

セッションの生成
Explicitメモリブロックの確保

javax.servlet.http.HttpSession.setAttribute(String, Object)

セッションへのオブジェクトの格納
Explicitメモリブロックへのオブジェクトの配置

セッションのタイムアウト

javax.servlet.http.HttpSession.invalidate()

セッションの破棄
Explicitメモリブロックの解放

HTTPセッションとは別に，HTTPセッション管理用オブジェクトのために，Webアプリケーション数＋2個※のExplicitメモリブロックがWebコンテナの内部で使用されます。

注※　Webコンテナで，内部的に2個の管理用オブジェクトを持つため，その個数を加算します。

なお，HTTPセッションで使用するExplicitヒープのメモリサイズは，HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用することで削減できます。詳細は，「8.9　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減」を参照してください。

8.4.2　リダイレクタとの通信用オブジェクト

Explicitメモリブロック領域の確保や解放は，Webコンテナによって実行されます。Webコンテナとリダイレクタ間の通信に使用する通信用オブジェクトは，通常は常設コネクションとして使い回され，Webサーバが起動している間は保持されます。

Webコンテナとリダイレクタの間で障害が発生した場合などに通信の切断・再接続が発生すると，通信用オブジェクトは破棄・再生成されます。このとき，破棄された通信用オブジェクトがTenured領域に残ります。

これを防ぐため，J2EEサーバでは，Webコンテナとリダイレクタ間の通信用オブジェクトをExplicitヒープに配置します。これによって，不要なオブジェクトがTenured領域に残ることを防ぎ，フルガーベージコレクションの発生を抑止します。

通信の確立と切断のタイミングに対応するExplicitメモリブロックの配置の流れについて説明します。

通信が確立されたとき

通信が確立されると，コネクション1個に対して1個のExplicitメモリブロックが作成されます。作成されたExplicitメモリブロックに，リダイレクタとの通信用オブジェクトが配置されます。

通信が切断されたとき

通信が切断されると，Explicitメモリブロック内に配置されたリダイレクタとの通信用オブジェクトごと，1個のExplicitメモリブロックの解放が予約されます。

通信が切断された直後は，解放が予約された状態です。解放が予約されたExplicitメモリブロックは，そのあとでコピーガーベージコレクションまたはフルガーベージコレクションが実行されたときに実際に解放されます。このとき，解放が予約されたすべての領域が解放されます。

8.5　アプリケーションで任意にExplicitヒープに配置できるオブジェクト

この節では，Explicitヒープに任意に配置できるオブジェクトについて説明します。

J2EEサーバで設定されている以外のJavaオブジェクトをExplicitヒープに配置したい場合は，自動配置設定ファイルを使用して配置したいオブジェクトを指定します。自動配置設定ファイルの詳細については「8.11.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用」を参照してください。

また，明示管理ヒープの自動解放機能については，「8.7　自動解放機能が有効な場合のExplicitメモリブロックの解放」を参照してください。

明示管理ヒープ機能APIを使って実装する場合は「8.10　明示管理ヒープ機能APIを使ったJavaプログラムの実装」を参照してください。

ポイント

JavaヒープおよびExplicitヒープをチューニングしてもTenured領域のメモリ使用量が増加し，かつフルガーベージコレクションが発生する要因になるJavaオブジェクトがある場合には，Explicitヒープへオブジェクトを配置することを検討してください。

＜この節の構成＞

8.5.1　Explicitヒープに配置できるオブジェクトの条件

8.5.2　オブジェクトのライフサイクルと状態遷移

8.5.1　Explicitヒープに配置できるオブジェクトの条件

ここでは，Explicitヒープに配置できるオブジェクトの前提と，配置すると効果があるオブジェクトについて説明します。

＜この項の構成＞

(1)　配置できるオブジェクトの前提

(2)　配置すると効果があるオブジェクト

(1)　配置できるオブジェクトの前提

Explicitヒープ（Explicitメモリブロック）に配置するオブジェクトは，次の前提を満たす必要があります。

Tenured領域のメモリサイズ増加の要因になる長寿命なオブジェクトであること
Explicitメモリブロックに対するオブジェクトの配置および解放には，一定のオーバーヘッドが掛かります。このため，Explicitメモリブロックへのオブジェクトの配置と解放は，できるだけ少なくなるようにしてください。
明示管理ヒープ機能を使用していない場合にコピーガーベージコレクションで回収の対象となっていた短寿命のオブジェクトを配置した場合，フルガーベージコレクション抑止の目的に一致しない上，オーバーヘッドが掛かってしまいます。Explicitメモリブロックには，コピーガーベージコレクションで回収の対象にならない，長寿命のオブジェクトを配置するようにしてください。
Tenured領域のメモリサイズ増加の要因になる長寿命のオブジェクトを特定する方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「8.8　Tenured領域内不要オブジェクト統計機能」を参照してください。

生存期間が既知であること（明示管理ヒープ機能APIを使用する場合だけ）
明示管理ヒープ機能APIを使用して明示管理ヒープを使用する場合，Explicitメモリブロックはガーベージコレクションの対象にならないため，使用済みのオブジェクトは自動的に回収されません。
Explicitメモリブロックに配置したオブジェクトは，アプリケーションで明示的に解放する必要がありますが，生存期間がわからないオブジェクトの場合，明示的に解放できません。このため，生存期間が既知であるオブジェクトを配置するようにしてください。

(2)　配置すると効果があるオブジェクト

明示管理ヒープ機能は，長寿命オブジェクトのうち，一定期間後に破棄されてフルガーベージコレクションで回収されるオブジェクトが，Tenured領域に昇格することを防ぐ機能です。このため，アプリケーションの停止まで使用されるオブジェクトなど，フルガーベージコレクションでも回収されないオブジェクトに対しては，適用する必要がありません。

Explicitヒープに配置すると効果があるオブジェクトとは，次のようなオブジェクトです。

一定のライフサイクルで生成と破棄が実行される。

ライフサイクルの期間がコピーガーベージコレクションによってオブジェクトが昇格する期間よりも長いために，破棄実施後に使用済みのオブジェクトが正しく回収されない。

このようなオブジェクトをExplicitヒープに配置することで，Tenured領域に不要なオブジェクトが残存することを防ぎ，フルガーベージコレクションを抑止できます。

8.5.2　オブジェクトのライフサイクルと状態遷移

Explicitメモリブロックに配置するオブジェクトのライフサイクルと状態遷移について説明します。

Explicitメモリブロックに配置したオブジェクトは，生存期間に基づいて，明示管理ヒープ機能APIを使用して明示的に生成，解放する必要があります。オブジェクトの生存期間および寿命は，アプリケーションの処理によって異なります。

Explicitメモリブロックに配置するオブジェクトのライフサイクルを次の図に示します。

図8-9　Explicitメモリブロックに配置するオブジェクトのライフサイクル

オブジェクトは，直接Explicitメモリブロックに生成されます。その後，明示管理ヒープ機能APIによってExplicitメモリブロックの解放が実行されると，状態によって，破棄されるかまたはJavaヒープに移動されます。解放処理実行時の動作については，「8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

8.6　Explicitメモリブロックのライフサイクルと実行される処理

この節では，Explicitメモリブロックのライフサイクルと，それぞれの段階で実行される処理について説明します。

＜この節の構成＞

8.6.1　Explicitメモリブロックのライフサイクルと状態

8.6.2　Explicitメモリブロックの初期化

8.6.3　Explicitメモリブロックへのオブジェクトの直接生成

8.6.4　Explicitメモリブロックの拡張

8.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動

8.6.6　ライフサイクルの各段階で出力されるイベントログ

8.6.1　Explicitメモリブロックのライフサイクルと状態

ここでは，Explicitメモリブロックのライフサイクルと状態について説明します。

明示管理ヒープ機能では，Explicitメモリブロックを解放する方法として次の2種類の解放処理があります。

Explicitメモリブロックの自動解放処理

Explicitメモリブロックの明示解放処理

Explicitメモリブロックの解放処理が異なることで，指定方法や処理が異なります。8.7以降で，解放処理ごとに詳しく説明します。

＜この項の構成＞

(1)　Explicitメモリブロックのライフサイクル

(2)　Explicitメモリブロックの状態

(1)　Explicitメモリブロックのライフサイクル

Explicitメモリブロックのライフサイクルを次の図に示します。

図8-10　Explicitメモリブロックのライフサイクル

図に示したライフサイクルの各段階について説明します。

Explicitメモリブロックの初期化とExplicitメモリブロックの無効化

Explicitメモリブロックの初期化が実行され，Explicitメモリブロックが生成されます。

HTTPセッションに関するオブジェクトまたはリダイレクタとの通信用オブジェクトを格納するExplicitメモリブロックは，Webコンテナによって初期化されます。

アプリケーションで任意のオブジェクトをExplicitヒープに配置する場合は，明示管理ヒープ機能APIを使用して，明示的にExplicitメモリブロックを初期化します。

なお，初期化実行時の状態によっては，Explicitメモリブロックが無効化されることがあります。

Explicitメモリブロックの初期化で実行される処理，およびExplicitメモリブロックが無効化される条件については，「8.6.2　Explicitメモリブロックの初期化」で説明します。

Explicitメモリブロックへのオブジェクトの生成

アプリケーションで任意のオブジェクトをExplicitメモリブロックに格納する場合，明示管理ヒープ機能APIを使用して，オブジェクトをExplicitメモリブロックに生成，配置します。

Explicitメモリブロックへのオブジェクトの生成については，「8.6.3　Explicitメモリブロックへのオブジェクトの直接生成」で説明します。

Explicitメモリブロックの拡張

利用中にオブジェクトを配置する領域が不足した場合，JavaVMによってExplicitメモリブロックの拡張が実行されます。

Explicitメモリブロックの拡張については，「8.6.4　Explicitメモリブロックの拡張」で説明します。

Explicitメモリブロックの解放予約と解放処理

Explicitメモリブロックの解放予約と解放処理は，明示管理ヒープ機能の自動解放機能の有効（-XX:+HitachiExplicitMemoryAutoReclaim）・無効（-XX:-HitachiExplicitMemoryAutoReclaim）で挙動が異なります。

自動解放機能が有効な場合（-XX:+HitachiExplicitMemoryAutoReclaim）

Explicitメモリブロックの明示解放予約
明示管理ヒープ機能APIによって指定された，Explicitメモリブロックに対して，解放が予約されます。自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約については，「8.7.1　自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約」を参照してください。

Explicitメモリブロックの自動解放予約
明示管理ヒープの自動解放機能によって処理される，Explicitメモリブロックに対して解放が予約されます。自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約については，「8.7.2　自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約」を参照してください。

Explicitメモリブロックの解放処理
明示解放予約，または自動解放予約によって予約されたExplicitメモリブロックに配置されているオブジェクトを解放します。自動解放機能が有効な場合のExplicitメモリブロックの解放処理については，「8.7.3　自動解放機能が有効な場合のExplicitメモリブロックの解放処理」を参照してください。

自動解放機能が無効な場合（-XX:-HitachiExplicitMemoryAutoReclaim）

Explicitメモリブロックの明示解放予約
Explicitメモリブロックに配置したオブジェクトが不要になった場合は，Explicitメモリブロック単位で解放を予約します。

HTTPセッションに関するオブジェクトまたはリダイレクタとの通信用オブジェクトを格納したExplicitメモリブロックは，Webコンテナによって解放が予約されます。

アプリケーションで任意のオブジェクトをExplicitメモリブロックに格納した場合は，明示管理ヒープ機能APIを使用して，明示的にExplicitメモリブロックの解放を予約します。

自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約については，「8.8.1　自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約」を参照してください。なお，明示解放予約を実行した段階では，まだExplicitメモリブロックは破棄されていません。

Explicitメモリブロックの解放処理
解放が予約されたExplicitメモリブロックは，コピーガーベージコレクションまたはフルガーベージコレクションが発生したタイミングで，JavaVMによって解放されます。同時にExplicitメモリブロックに配置したオブジェクトも破棄されます。ただし，一部のオブジェクトは破棄されないで，Javaヒープに移動します。
自動解放機能が無効な場合のExplicitメモリブロックの解放処理については，「8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

(2)　Explicitメモリブロックの状態

Explicitメモリブロックは，ライフサイクルの各段階で，有効，解放済み，解放予約済みなどの状態に遷移します。

さらに，有効な状態のExplicitメモリブロックは，次の表に示すサブ状態を保持します。

表8-5　Explicitメモリブロックのサブ状態

サブ状態 | Explicitメモリブロックの状態
Enable | 初期状態です。Explicitメモリブロックのすべての機能が使用できます。
Disable | 該当するExplicitメモリブロックにJavaオブジェクトを移動できない状態です。Explicitメモリブロックを拡張したときに，この状態になることがあります。

8.6.2　Explicitメモリブロックの初期化

ここでは，Explicitメモリブロックの初期化の実行と，初期化時に実行される処理について説明します。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

アプリケーションで任意のオブジェクトをExplicitヒープに配置する場合，次に示す明示管理ヒープ機能APIを呼び出すことでExplicitメモリブロックが初期化されます。

BasicExplicitMemory.BasicExplicitMemory()

BasicExplicitMemory.BasicExplicitMemory(String name)

また，これらのAPIのほかに，自動配置設定ファイルで指定したオブジェクトが生成されたタイミングでもExplicitメモリブロックが初期化されます。なお，J2EEサーバがオブジェクトを配置するExplicitメモリブロックでは，Webコンテナによって初期化と最初のオブジェクトの配置が実行されます。実行契機については，「8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

Explicitメモリブロックが初期化されます。ただし，この段階ではExplicitメモリブロック用のメモリ領域の確保は実行されません。

また，次の場合は，初期化が実行されません。

最大数の制限を超えてExplicitメモリブロックを初期化しようとした場合
現存するExplicitメモリブロックの数が1,048,575個の場合が該当します。

明示管理ヒープ機能がオフになっている場合
-XX:-HitachiUseExplicitMemoryオプションが指定されている場合が該当します。

この場合，コンストラクタの実行は成功しますが，無効なExplicitメモリブロックとして扱われます。初期化したExplicitメモリブロック（ExplicitMemoryインスタンス）に対する処理は，すべて無効になります。

8.6.3　Explicitメモリブロックへのオブジェクトの直接生成

ここでは，Explicitメモリブロックにオブジェクトを直接生成する方法と実行される処理について説明します。

アプリケーションでExplicitメモリブロックにオブジェクトを生成するためには，「(1)実行契機」で示すAPIを使用します。APIを実行すると，引数で指定したクラスのオブジェクトがExplicitメモリブロックに生成されます。ただし，そのオブジェクトのコンストラクタなどによる初期化処理中に生成されたオブジェクトについては，Javaヒープに生成されます。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

アプリケーションで明示管理ヒープ機能を使用する場合，Explicitメモリブロックへのオブジェクトの直接生成は，次のどれかの明示管理ヒープ機能APIを呼び出すことで実行できます。

ExplicitMemory.newInstance(Class type)

ExplicitMemory.newInstance(Class type, Object... args)

ExplicitMemory.newInstance(java.lang.reflect.Constructor cons, Object... args)

ExplicitMemory.newArray(Class type, int number)

ExplicitMemory.newArray(Class type, int[] dimensions)

また，これらのAPIのほかに，明示管理ヒープ自動配置設定ファイルで指定したオブジェクトが生成され，Explicitメモリブロックの初期化が実行されたタイミングでも，Explicitメモリブロックにオブジェクトが直接生成されます。

J2EEサーバが配置するオブジェクトについては，意識する必要はありません。

(2)　実行される内容

APIごとに実行される内容を説明します。

表8-6　APIごとに実行される内容

API | 実施される内容
ExplicitMemory.newInstance(Class type) | 引数typeで指定したクラスをインスタンス化して，レシーバが示すExplicitメモリブロックに配置します。
ExplicitMemory.newInstance(Class type, Object... args)
ExplicitMemory.newInstance(java.lang.reflect.Constructor cons, Object... args) | java.lang.reflect.Constructorが示すクラスをインスタンス化して，レシーバが示すExplicitメモリブロックに配置します。
ExplicitMemory.newArray(Class type, int number) | 引数typeで指定したクラスの配列を，引数numberで指定した長さでインスタンス化して，レシーバが示すExplicitメモリブロックに配置します。
ExplicitMemory.newArray(Class type, int[] dimensions) | 引数typeで指定したクラスの配列を，引数dimensionsで指定した次元数でインスタンス化して，レシーバが示すExplicitメモリブロックに配置します。

APIの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「13.3　ExplicitMemoryクラス」を参照してください。

ただし，配置先のExplicitメモリブロックに必要な領域を確保できない場合は，生成したオブジェクトがExplicitメモリブロックに配置されません。生成したオブジェクトはJavaヒープに配置されます。

領域を確保できない要因および実行される処理については，「8.6.4　Explicitメモリブロックの拡張」の拡張処理を実行できない場合の説明を参照してください。

8.6.4　Explicitメモリブロックの拡張

ここでは，Explicitメモリブロックの拡張処理について説明します。拡張処理が実行されると，Explicitメモリブロック内の空き領域が増加します。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

拡張は，JavaVMによって次の契機で実行されます。

Explicitメモリブロックに最初のオブジェクトが配置される時

オブジェクトを配置するためのExplicitメモリブロックの空き領域が足りない場合

明示管理ヒープ機能APIを使用したアプリケーションからExplicitメモリブロックにオブジェクトを配置しようとした場合に，オブジェクトのサイズが配置対象のExplicitメモリブロックの空き領域を超えるとき，拡張処理が実行されます。

Explicitメモリブロックの初期化後，初めてExplicitメモリブロックにオブジェクトを配置するときには，必ず拡張処理が実行されます。

なお，J2EEサーバがオブジェクトを配置するExplicitメモリブロックでは，Webコンテナによって初期化と最初のオブジェクトの配置が実行されます。実行契機については，「8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

JavaVMによって，OSからメモリ領域が確保され，該当のExplicitメモリブロックが拡張されます。メモリ領域の確保には，OSのメモリ確保APIが使用されます。

ただし，次の場合，拡張処理が実行されません。

OSからのメモリ領域の確保に失敗した場合
OSのメモリ確保APIによるメモリ領域の確保が失敗した場合です。該当するExplicitメモリブロックのサブ状態が「Disable」に変化して，このExplicitメモリブロックへのオブジェクトの配置が中止されます。
「Disable」に変化したExplicitメモリブロックには，以降オブジェクトは配置されません。
なお，自動配置設定ファイルを使用している場合，または64ビット版のアプリケーションサーバを使用している場合，JavaVM起動時に最大サイズの領域がOSから確保されているため，OSからのメモリ領域確保に失敗することはありません。

Explicitヒープの最大値の制限を超えて拡張しようとした場合
すべてのExplicitメモリブロックの合計サイズに，拡張しようとしたサイズを加えた値が，-XX:HitachiExplicitHeapMaxSizeオプションに指定した値を超えた場合です。
該当するExplicitメモリブロックのサブ状態が「Disable」に変化して，このExplicitメモリブロックへのオブジェクトの配置が中止されます。
「Disable」に変化したExplicitメモリブロックには，以降オブジェクトは配置されません。
-XX:HitachiExplicitHeapMaxSizeオプションについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」を参照してください。

サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした場合
サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした場合は，Explicitメモリブロックへのオブジェクトの配置が中止されます。

Explicitメモリブロックの拡張が失敗した場合のサブ状態の変化について，要因ごとに次の表に示します。

表8-7　Explicitメモリブロックの拡張が失敗した場合のサブ状態の変化

拡張が失敗した要因 | サブ状態の変化
OSからのメモリ領域の確保に失敗した | 「Enable」→「Disable」
Explicitヒープの最大値の制限を超えて拡張しようとした | 「Enable」→「Disable」
サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした | 変化しません。

8.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動

JavaヒープからExplicitメモリブロックへのオブジェクトの移動では，Explicitメモリブロック内にあるオブジェクトから参照されているJavaヒープ内のオブジェクトが，自動でExplicitメモリブロックへ移動します。このため，移動するオブジェクトと関係を持つオブジェクトに対して，JavaヒープからExplicitメモリブロックへ移動する設定を作り込む必要はありません。

なお，参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動は，自動配置機能で作成したExplicitメモリブロックが対象となります。明示管理ヒープAPIで作成したExplicitメモリブロックは対象外です。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

コピーガーベージコレクション，およびフルガーベージコレクションが発生したタイミングで実行されます。

(2)　実行される内容

コピーガーベージコレクションまたはフルガーベージコレクションの処理が終了したあと，JavaVMによって解放予約されていないExplicitメモリブロックがあるかどうか調査されます。調査の基点となるオブジェクトから参照関係を調べ，参照先がなくなるまで調査を続けます。参照関係を調査する際，Javaヒープ外の領域は調査対象外です。また，Explicitメモリブロックから参照されているオブジェクトは移動対象のオブジェクトとなります。

ただし，コピーガーベージコレクションが実行された場合には，これらに加えて次の規則に従って動作します。

参照されているExplicitメモリブロック内のオブジェクトが昇格するタイミングで移動します。

Permヒープ，およびExplicitヒープ，およびTenured領域への参照についても調査対象としません。

Explicitメモリブロックが解放予約されている場合でも，移動対象として扱います。
Explicitメモリブロックの領域が確保できず，オブジェクトがJavaヒープに移動するときに，移動先のJavaヒープに空き領域がなくなり，移動できなくなった場合が該当します。この場合は，フルガーベージコレクションが実行され，Javaヒープに空き領域が確保されます。フルガーベージコレクション実行後，Javaヒープへのオブジェクトの移動が実行されます。

これらの規則に従ったオブジェクトの移動の流れを図8-11および図8-12で例を使って説明します。

図8-11　参照関係に基づいて移動するオブジェクト（例1）

図中のオブジェクトは次の順番に動作します。

オブジェクト1は，Explicitメモリブロック1内のオブジェクトから参照されています。そのため，オブジェクト1はExplicitメモリブロック1へ移動します。

オブジェクト9も，オブジェクト1から参照されているためExplicitメモリブロック1に移動します。

1.および2.の処理と同様に，オブジェクト4，オブジェクト10，およびオブジェクト11はExplicitメモリブロック2へ移動します。

オブジェクト6は，Explicitメモリブロック2内のオブジェクトから参照されています。しかし，Javaヒープ内のオブジェクトではないためこのままとなります。

4.と同様に，オブジェクト12についてもこのままとなります。

図8-12　参照関係に基づいて移動するオブジェクト（例2）

図中のオブジェクトは次の順番に動作します。

オブジェクト13は，Javaヒープ内にあり，またExplicitメモリブロック2内のオブジェクトから到達できます。しかし，オブジェクト12の時点で調査が打ち切られているため，移動しません。

オブジェクト15は，オブジェクト13と同様にPerm領域内からの参照があります。しかし，この参照に加え，Explicitメモリブロック2内のオブジェクトからPerm領域やほかのExplicitメモリブロックを介さずに到達できます。そのため，Explicitメモリブロック2に移動します。

オブジェクト5はExplicitメモリブロック1，およびExplicitメモリブロック2の両方から参照されていますが，Explicitメモリブロック1に移動します。
なお，オブジェクト5はExplicitメモリブロック1，およびExplicitメモリブロック2の両方から参照されています。このような場合，Explicitメモリブロック1または2のどちらかに移動しますが，どちらのExplicitメモリブロックに移動するかは未定義です。

また，次の条件に該当する場合は，例で説明した動作と異なります。

Explicitメモリブロックの空き領域を確保できない場合
オブジェクトをExplicitメモリブロックに配置する際，配置先のExplicitメモリブロックに配置対象となるオブジェクトを配置する空き領域がない場合が該当します。この場合，Explicitメモリブロックにオブジェクトを配置できません。配置できなかったオブジェクトは，Javaヒープ領域へ配置されます。なお，APIの利用方法が誤っている場合，APIレベルの例外が発生することがあります。詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「13.7　例外クラス」を参照してください。

8.6.6　ライフサイクルの各段階で出力されるイベントログ

Explicitメモリブロックのライフサイクルの各段階では，イベントログが出力されます。イベントログは，出力契機になるイベントが発生したときに出力されます。

ライフサイクルの各段階と，イベントログの出力契機の対応を次の表に示します。ログ出力レベルの設定によって，ログを出力する契機になるイベントは異なります。

表8-8　ライフサイクルの各段階と出力されるイベントログの対応

ライフサイクルの段階 | イベントログの出力契機 | ログ出力レベル
Explicitメモリブロックの初期化 | Explicitメモリブロックの初期化 | verbose
Explicitメモリブロックの初期化（詳細出力） | debug
Explicitメモリブロックの初期化失敗 | verbose
Explicitメモリブロックの拡張 | Explicitメモリブロックのサブ状態のDisable化 | verbose
Explicitメモリブロックの明示解放予約 | ファイナライザによるExplicitメモリブロックの解放予約 | verbose
Explicitメモリブロックの自動解放自動予約 | verbose
Explicitメモリブロックの自動解放明示予約 | verbose
Explicitメモリブロックの明示解放処理 | Explicitメモリブロックの解放処理 | normal
Explicitメモリブロックの解放処理（詳細出力） | verbose
Explicitメモリブロック解放時のJavaヒープあふれ | normal
Explicitメモリブロック解放によるJavaヒープへのオブジェクトの移動 | debug
Explicitメモリブロックの自動解放処理 | Explicitメモリブロックの自動解放処理 | normal
Explicitメモリブロックの自動解放処理時のJavaヒープあふれ | normal
Explicitメモリブロックへのオブジェクト直接生成 | Explicitメモリブロックへのオブジェクト生成 | verbose

このほか，ライフサイクルの段階と対応しないイベントとして，ガーベージコレクション発生時にイベントログが出力されます。

明示管理ヒープ機能のイベントログ取得の設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「3.3.19　JavaVMの資料取得の設定」を参照してください。明示管理ヒープ機能のイベントログの内容については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「4.19　明示管理ヒープ機能のイベントログ」を参照してください。

8.7　自動解放機能が有効な場合のExplicitメモリブロックの解放

ここでは，明示管理ヒープの自動解放について説明します。

Explicitメモリブロックの自動解放は，解放予約と解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行することで，効率良く処理できます。

また，自動解放予約には自動解放の明示予約，および自動解放の自動予約の2種類があります。Explicitメモリブロックの自動解放について，図で説明します。

図8-13　Explicitメモリブロックの自動解放

以降では，自動解放機能が有効な場合に実行される処理について説明します。

＜この節の構成＞

8.7.1　自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約

8.7.2　自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約

8.7.3　自動解放機能が有効な場合のExplicitメモリブロックの解放処理

8.7.1　自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約

自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約では，APIによって明示的にExplicitメモリブロックに対して解放を予約します。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約では，次のどれかの明示管理ヒープ機能APIを呼び出すことで実行できます。

ExplicitMemory.reclaim(ExplicitMemory... areas)

ExplicitMemory.reclaim(ExplicitMemory area)

ExplicitMemory.reclaim(ExplicitMemory area0,ExplicitMemory area1)

ExplicitMemory.reclaim(Iterable<ExplicitMemory> areas)

BasicExplicitMemory.finalize()

(2)　実行される内容

(1)で示したAPIが呼び出されると，APIの引数で指定されたExplicitメモリブロック領域が解放予約された状態になります。

なお，APIの利用方法が誤っている場合，APIレベルの例外が発生することがあります。詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「13.7　例外クラス」を参照してください。

8.7.2　自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約

自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約では，JavaVMが自動的にExplicitメモリブロックに対して解放を予約します。自動配置機能で配置したExplicitメモリブロックが対象となります。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

ガーベージコレクションが発生したタイミングでJavaVMによって実行されます。

(2)　実行される内容

ガーベージコレクションが発生したタイミングで，JavaVMが自動でExplicitメモリブロック領域を予約します。

8.7.3　自動解放機能が有効な場合のExplicitメモリブロックの解放処理

自動解放機能が有効な場合のExplicitメモリブロックの解放処理は，事前に自動解放予約，および明示解放予約で予約されているExplicitメモリブロックに対して実行されます。不要になったExplicitメモリブロックは，解放処理によってメモリから削除されます。

なお，外部（解放対象外のExplicitメモリブロック）から参照されているオブジェクトがある場合，オブジェクトは新規のExplicitメモリブロックに移動されます。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

自動解放予約で解放予約が実行されるのと同じガーベージコレクションで，JavaVMによって実行されます。

(2)　実行される内容

実行される内容は，解放対象外のExplicitメモリブロックから参照されているオブジェクトの挙動以外は，自動解放機能が無効な場合のExplicitメモリブロックの解放処理の処理内容と同じです。Explicitメモリブロックの解放処理で実行される内容については，「8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

また，次の条件に該当する場合は動作が異なります。

Explicitメモリブロックの空き領域を確保できない場合
オブジェクトをExplicitメモリブロックに配置する際，配置先のExplicitメモリブロックに配置対象となるオブジェクトを配置する空き領域がない場合が該当します。この場合，Explicitメモリブロックにオブジェクトを配置できません。配置できなかったオブジェクトは，Javaヒープ領域へ配置されます。

Javaヒープへのオブジェクト移動時にJavaヒープがあふれた場合
Explicitメモリブロックの領域を確保できず，オブジェクトがJavaヒープに移動する場合に，移動先のJavaヒープに空き領域がなくなり，移動できなくなったときが該当します。この場合は，フルガーベージコレクションが実行され，Javaヒープに空き領域が確保されます。フルガーベージコレクション実行後，Javaヒープへのオブジェクトの移動が実行されます。
フルガーベージコレクションを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合は，ログファイルが出力され，オブジェクトが再度Explicitメモリブロックに配置されます。出力されるログファイルについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「4.19　明示管理ヒープ機能のイベントログ」を参照してください。

フルガーベージコレクションで十分な空き領域を作成できない場合
Javaヒープに空き領域がなくなり，フルガーベージコレクションを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合が該当します。この場合は，Cヒープ不足の場合と同様に，JavaVMがアボートします。ただし，Cヒープ不足時には「request nnn bytes」としてnnnに必要なメモリサイズが出力されますが，JavaVMのアボート時には，nnnとして常に「0」が出力されます。

8.8　自動解放機能が無効な場合のExplicitメモリブロックの解放

ここでは，明示管理ヒープの明示解放について説明します。

Explicitメモリブロックの明示解放は，明示管理ヒープの自動解放と同様に，解放予約と解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行します。

以降では，明示解放機能で実行される処理について説明します。

＜この節の構成＞

8.8.1　自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約

8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理

8.8.1　自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約

Explicitメモリブロックの解放は，解放予約と実際の解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行することで，効率良く処理できます。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

アプリケーションで任意のオブジェクトをExplicitヒープに配置した場合，Explicitメモリブロックの解放予約は，次のどれかの明示管理ヒープ機能APIを呼び出すことで実行できます。

ExplicitMemory.reclaim(ExplicitMemory... areas)

ExplicitMemory.reclaim(ExplicitMemory area)

ExplicitMemory.reclaim(ExplicitMemory area0,ExplicitMemory area1)

ExplicitMemory.reclaim(Iterable<ExplicitMemory> areas)

BasicExplicitMemory.finalize()

J2EEサーバが配置したオブジェクトについては，Webコンテナによって解放が予約されます。実行契機については，「8.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

(1)で示したAPIが呼び出されると，APIの引数で指定されたExplicitメモリブロック領域が解放予約された状態になります。

なお，APIの利用方法が誤っている場合，APIレベルの例外が発生することがあります。詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「13.7　例外クラス」を参照してください。

8.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理

解放処理は，事前に解放予約されているExplicitメモリブロックに対して実行されます。不要になったExplicitメモリブロックは，解放処理によってメモリから実際に削除されます。

＜この項の構成＞

(1)　実行契機

(2)　実行される内容

(1)　実行契機

解放処理は，次の契機でJavaVMによって実行されます。

コピーガーベージコレクション発生時

フルガーベージコレクション発生時

(2)　実行される内容

コピーガーベージコレクションまたはフルガーベージコレクションの処理が終了したあと，JavaVMによって解放予約されたExplicitメモリブロックがあるかどうかが調査されます。該当するExplicitメモリブロックが一つ以上ある場合は，そのExplicitメモリブロックが解放されます。解放は，OSのメモリ解放APIで実行されます。その際，解放されたExplicitメモリブロック内のオブジェクトは，破棄されます。

ただし，解放するExplicitメモリブロック内のオブジェクトのうち，どこからも参照されていないfinalizeメソッドを実装しているクラスのオブジェクトは，破棄されません。このオブジェクトは，ファイナライズキューに登録され，Javaヒープに移動されます。

また，解放対象のExplicitメモリブロックのオブジェクトが次の条件に該当する場合は動作が異なります。

(a)　外部（解放対象のExplicitメモリブロック以外）から参照されている場合

解放対象のExplicitメモリブロックのオブジェクトが，次の領域のオブジェクトから参照されている場合が該当します。

Javaヒープ

Permanent領域

解放対象でないExplicitメモリブロック

それぞれの場合に実行される内容を次に示します。

JavaヒープまたはPermanent領域から参照されている場合

JavaヒープまたはPermanent領域内のオブジェクトから参照されている場合，そのオブジェクトは破棄されません。

該当するオブジェクトは，JavaヒープのTenured領域に優先的に移動されます。ただし，Tenured領域に空き容量がない場合，またはTenured領域があふれた場合は，New領域に移動されます。また，すでに使用されていないTenured領域のオブジェクトから参照されている場合も，移動の対象になります。

解放対象ではないExplicitメモリブロックから参照されている場合

解放対象ではないExplicitメモリブロック内のオブジェクトから参照されている場合，そのオブジェクトは破棄されません。また，参照元のオブジェクトが解放対象のExplicitメモリブロック内のオブジェクトである場合も，そのオブジェクトが破棄されないでJavaヒープに移動するオブジェクトである場合は，参照されているオブジェクトも削除されません。

Explicitメモリブロック解放時に外部から参照されている場合の動作を次の図に示します。

図8-14　Explicitメモリブロック解放時に外部から参照されている場合の動作

解放対象のExplicitメモリブロックに含まれるオブジェクトである，オブジェクトXを例にして説明します。

解放対象のExplicitメモリブロックのオブジェクトから参照されている場合，オブジェクトXは削除されます。

Javaヒープ，Permanent領域または解放対象でないExplicitメモリブロックのオブジェクトから参照されている場合，オブジェクトXは削除されません。

また，オブジェクトXが解放対象のExplicitメモリブロックのオブジェクト（オブジェクトY）から参照されている場合も，参照元であるオブジェクトYがJavaヒープ，Permanent領域または解放対象でないExplicitメモリブロックのオブジェクトから参照されているときには，オブジェクトXは削除されません。この場合，オブジェクトXは，オブジェクトYとともにJavaヒープに移動します。

(b)　Javaヒープへのオブジェクト移動時にJavaヒープがあふれた場合

外部から参照されているオブジェクトがJavaヒープに移動するときに，移動先のJavaヒープに空き領域がなくなり，移動できなくなった場合が該当します。

この場合は，フルガーベージコレクションが実行され，Javaヒープに空き領域が確保されます。フルガーベージコレクション実行後，Javaヒープへのオブジェクトの移動が実行されます。

(c)　フルガーベージコレクションで十分な空き領域を作成できない場合

Javaヒープに空き領域がなくなり，フルガーベージコレクションを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合が該当します。この場合は，Cヒープ不足の場合と同様に，JavaVMがアボートします。ただし，Cヒープ不足時には「request nnn bytes」としてnnnに必要なメモリサイズが出力されますが，JavaVMのアボート時には，nnnとして常に「0」が出力されます。

8.9　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減

ここでは，HTTPセッションで利用するExplicitヒープのメモリ使用量を削減する機能について説明します。メモリ使用量の削減には，HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用します。

この機能を使用すると，アプリケーションサーバ内でのHTTPセッションとExplicitメモリブロックの関係が多対1になります。複数のHTTPセッションで一つのExplicitメモリブロックを共有できるため，Explicitメモリブロックの利用率が向上します。これによって，HTTPセッションが確保するExplicitヒープのメモリ使用量を削減できます。

＜この節の構成＞

8.9.1　適用効果があるかの確認

8.9.2　メモリ使用量を削減する仕組み

8.9.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項

8.9.1　適用効果があるかの確認

HTTPセッションで利用するExplicitヒープの省メモリ化機能を適用して効果があるかどうかは，スレッドダンプに含まれるExplicitメモリブロック情報を確認することで判定できます。次の条件を満たすExplicitメモリブロックが多数ある場合は，適用効果がありますので，この機能の利用を検討してください。

Explicitメモリブロック情報の<EM_TYPE>が「R」である。

<EM_USED>が，次に示すサイズよりも小さいExplicitメモリブロックが多数ある。

明示管理ヒープ機能の自動配置機能を利用している場合

8KB

明示管理ヒープ機能の自動配置機能を利用していない場合

32KB

スレッドダンプでのExplicitメモリブロック情報の出力内容については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「5.5　JavaVMのスレッドダンプの内容」を参照してください。

なお，稼働情報によるExplicitヒープ領域のメモリサイズの見積もりについては, この機能を利用するかどうかによる違いはありません。見積もり方法については，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.10.5　稼働情報による見積もり」を参照してください。

ただし，稼働情報ファイルの出力内容については，一部違いがあります。違いについては，「8.9.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項」を参照してください。

8.9.2　メモリ使用量を削減する仕組み

HTTPセッションが格納されるExplicitヒープ領域のExplicitメモリブロックは，アプリケーションがHTTPセッションを作成するたびに作成されます。HTTPセッションに関するオブジェクトは，作成されたExplicitメモリブロックに配置されます。

この機能を利用しない場合と利用する場合の比較によって，メモリ使用量を削減する仕組みを説明します。

＜この項の構成＞

(1)　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用しない場合

(2)　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用する場合

(1)　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用しない場合

HTTPセッションに関するオブジェクトが格納されるExplicitメモリブロックが三つある場合の例を次の図に示します。このうち，BとCのExplicitメモリブロックは，利用率が低く，長時間利用されていないHTTPセッションに関連づけられたExplicitメモリブロックです。

図8-15　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用していない場合

HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用していない場合，自動解放が発生したときも，ExplicitメモリブロックA～Cは解放されません。この場合，HTTPセッションに関するオブジェクトが格納されるExplicitメモリブロックの使用済みサイズは，HTTPセッションに関するオブジェクトの総バイト数に一致します。また，Explicitメモリブロックの個数は有効なセッション数に一致します。

ただし，小さいサイズのオブジェクトを格納する場合も，Explicitメモリブロックは一定サイズ以上の大きさで確保されるため，Explicitヒープ領域のメモリは，実際に必要なExplicitメモリのサイズ以上に消費されます。

(2)　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用する場合

HTTPセッションに関するオブジェクトが格納されるExplicitメモリブロックが三つある場合の例を次の図に示します。このうち，BとCのExplicitメモリブロックは，利用率が低く，長時間利用されていないHTTPセッションに関連づいたExplicitメモリブロックです。また，自動配置設定ファイルに指定したオブジェクトが格納されるExplicitメモリブロックとして，Dがあります。

図8-16　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用している場合

HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用している場合，自動解放が発生したタイミングで，HTTPセッションで利用するExplicitヒープの省メモリ化機能が実行されます。利用率が低いExplicitメモリブロックであるBおよびCが解放され，このExplicitメモリブロックに格納されていたHTTPセッションに関するオブジェクトはDに移動します。

このように，利用率の低いExplicitメモリブロックに格納されていたオブジェクトをほかの領域に移動して集約して，利用率の低いExplicitメモリブロックを解放することで，Explicitメモリブロックの利用率が向上します。

8.9.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項

ここでは，HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項について説明します。

HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用しているかどうかによって，稼働情報ファイルの出力内容が一部異なります。

参考

ここで説明する違いによって，解放されるExplicitメモリブロックに格納されるHTTPセッションに関するオブジェクトのメモリサイズを計上する領域が，HTTPセッションで利用する領域からアプリケーションで利用する領域に変更になります。ただし，システム全体で使用するメモリサイズには変更ありません。このため，この機能を利用するかどうかは，稼働情報を使用したExplicitヒープ領域のメモリサイズの見積もりには影響ありません。

出力内容が異なる項目について説明します。

＜この項の構成＞

(1)　HTTPセッションで取得したExplicitメモリブロックの個数

(2)　アプリケーションで利用するExplicitヒープ領域のサイズ

(1)　HTTPセッションで取得したExplicitメモリブロックの個数

次の項目に出力されるExplicitメモリブロックの個数が異なります。

HTTPSessionEMemoryBlockCount.HighWaterMark

HTTPSessionEMemoryBlockCount.LowWaterMark

HTTPSessionEMemoryBlockCount.Current

この機能を利用していない場合

システムで有効なHTTPセッション数が出力されます。

この機能を利用している場合

内部動作を反映した値が出力されるため，システムで有効なHTTPセッション数とは異なる値が出力されます。

(2)　アプリケーションで利用するExplicitヒープ領域のサイズ

次の項目に出力されるExplicitヒープ領域のサイズが異なります。

ApplicationEHeapSize.HighWaterMark

ApplicationEHeapSize.LowWaterMark

この機能を利用していない場合

自動配置機能で利用されるExplicitメモリのサイズが出力されます。

この機能を利用している場合

「この機能が自動解放対象としたExplicitメモリのサイズ＋自動配置機能で利用するExplicitメモリのサイズ」の合計サイズとなります。

8.10　明示管理ヒープ機能APIを使ったJavaプログラムの実装

この節では，アプリケーションで明示管理ヒープ機能を使用する場合の実装について説明します。明示管理ヒープ機能は，明示管理ヒープ機能APIを使用して実装します。

明示管理ヒープ機能は，JP.co.Hitachi.soft.jvm.MemoryAreaパッケージ内のクラスで使用できます。APIの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」を参照してください。なお，明示管理ヒープ機能APIは，すべてスレッドセーフです。

明示管理ヒープ機能APIでは，次の2種類の処理を実装します。

オブジェクトをExplicitヒープに配置するための実装

明示管理ヒープ機能の稼働情報を取得するための実装

＜この節の構成＞

8.10.1　オブジェクトをExplicitヒープに配置するための実装

8.10.2　明示管理ヒープ機能の稼働情報を取得するための実装

8.10.1　オブジェクトをExplicitヒープに配置するための実装

ここでは，明示管理ヒープ機能APIのクラスの概要と，APIの基本的な利用方法について説明します。

＜この項の構成＞

(1)　ExplicitMemoryインスタンスとExplicitメモリブロックの関係

(2)　明示管理ヒープ機能APIのクラス構成

(3)　明示管理ヒープ機能APIの利用方法

(1)　ExplicitMemoryインスタンスとExplicitメモリブロックの関係

Explicitヒープ内のExplicitメモリブロックは，明示管理ヒープ機能APIで扱うExplicitMemoryクラスのインスタンスと1：1で対応します。

ExplicitMemoryインスタンスとExplicitメモリブロックの関係を次の図に示します。

図8-17　ExplicitMemoryインスタンスとExplicitメモリブロックの関係

Explicitメモリブロックは，ExplicitMemoryクラスのコンストラクタを実行すると初期化されます。以降は，初期化されたインスタンスが，Explicitメモリブロックを操作するためのインタフェースになります。図の場合は，インスタンスem1がExplicitメモリブロック1に，インスタンスem2がExplicitメモリブロック2に対応しています。

(2)　明示管理ヒープ機能APIのクラス構成

明示管理ヒープ機能APIのクラスを次の表に示します。

表8-9　明示管理ヒープ機能APIのクラス

クラス | 説明
MemoryAreaクラス | JavaヒープまたはExplicitメモリブロックを表現する抽象クラスです。
ExplicitMemoryクラス | Explicitメモリブロックを表現する抽象クラスです。このクラスの機能は，派生クラスであるBasicExplicitMemoryクラスを介して利用します。
BasicExplicitMemoryクラス | アプリケーションで扱うExplicitメモリブロックを表現するクラスです。アプリケーションでは，このクラスのAPIを使用して明示管理ヒープ機能を実装します。

クラスの階層を次の図に示します。

図8-18　明示管理ヒープ機能APIのクラス階層

(3)　明示管理ヒープ機能APIの利用方法

基本的な操作とメソッドの対応は次のとおりです。

Explicitメモリブロックへのオブジェクトの直接生成
newArrayメソッドまたはnewInstanceメソッドを利用します。

Explicitメモリブロックの解放
reclaimメソッドを使用します。

次に，BasicExplicitMemoryクラスの利用例を示します。この例では，二つのExplicitメモリブロックを作成します。

BasicExplicitMemoryクラスの利用例

行
Javaプログラム

01
02
03
04
05
06
07
08

BasicExplicitMemory em1 = new BasicExplicitMemory();
BasicExplicitMemory em2 = new BasicExplicitMemory();

Object o1 = em1.newInstance(Object.class);

Object o2 = em2.newInstance(Object.class);

ExplicitMemory.reclaim(em1);

01行目と02行目では，BasicExplicitMemoryインスタンスを生成しています。この例では，em1がExplicitメモリブロック1，em1がExplicitメモリブロック2に対応するものとします。

04行目および06行目のnewInstanceメソッドによって，Explicitメモリブロックにオブジェクトを直接生成します。04行目では，em1インスタンスからnewInstanceメソッドを呼び出すことで，ObjectクラスのオブジェクトをExplicitメモリブロック1に配置します。06行目では，em2インスタンスからnewInstanceメソッドを呼び出すことで，ObjectクラスのオブジェクトをExplicitメモリブロック2に配置します。

Explicitメモリブロックが不要になったら，Explicitメモリブロックを破棄します。08行目のExplicitMemory.reclaim(em1)メソッドの実行は，Explicitメモリブロック1を解放するための処理です。これによって，Explicitメモリブロック1が解放され，同時に04行目で生成したオブジェクトo1も破棄されます。なお，Explicitメモリブロックの解放は，オブジェクト単位ではなく，該当のExplicitメモリブロックに対応する領域全体が対象になります。

この例の場合，Explicitメモリブロック1の生存期間は，01行目から08行目になります。

8.10.2　明示管理ヒープ機能の稼働情報を取得するための実装

ここでは，アプリケーションで明示管理ヒープ機能の稼働情報を取得するための実装について説明します。稼働情報を取得することで，デバッグや障害解析を実行できます。

アプリケーションで明示管理ヒープ機能を実装している場合，稼働情報として次の情報を取得できます。

Explicitヒープの利用状況

ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

Explicitメモリブロックの情報

また，稼働情報の取得に関連した処理として，次の処理も実行できます。

Explicitメモリブロックの名前の設定と取得

Explicitメモリブロックの処理可能状態の判定

Explicitメモリブロックの解放予約状態の判定

ここでは，明示管理ヒープ機能APIを使用した，それぞれの処理の実装について説明します。

＜この項の構成＞

(1)　Explicitヒープの利用状況の取得

(2)　ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

(3)　Explicitメモリブロックの情報の取得

(4)　Explicitメモリブロックの名称の設定と取得

(5)　Explicitメモリブロックの処理可能状態の判定

(6)　Explicitメモリブロックの解放予約状態の判定

(1)　Explicitヒープの利用状況の取得

Explicitヒープの情報を取得方法について説明します。Explicitヒープは，Explicitメモリブロック全体のことです。なお，各Explicitメモリブロックの情報を取得する方法については，「(3) Explicitメモリブロックの情報の取得」を参照してください。

使用するAPI

getMemoryUsage()

このAPIは，java.lang.management.MemoryUsageクラスのインスタンスを作成して，そのインスタンスを返却します。

返却されたインスタンスの各フィールドには，インスタンス作成時の情報として，次の表に示す情報が設定されています。

表8-10　各フィールドの情報（MemoryUsageクラスのインスタンス）

フィールド
設定内容

init
0

used
Explicitヒープの使用されているメモリのサイズ（単位：バイト）

committed
Explicitヒープの確保済みサイズ（単位：バイト）

max
-XX:HitachiExplicitHeapMaxSizeで指定した最大Explicitヒープサイズの値（単位：バイト）
ただし，明示管理ヒープ機能がオフの場合（-XX:-HitachiUseExplicitMemoryが設定されている場合）は，0になります。

各フィールドが示す値を次の図に示します。

図8-19　各フィールドが示す値（MemoryUsageクラスのインスタンス）

(2)　ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

Explicitメモリブロックの利用状況として，ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズを取得します。これによって明示管理ヒープ機能でのメモリの使用状況をチェックできます。

使用するAPI

freeMemory()

usedMemory()

totalMemory()

それぞれのAPIで取得できるExplicitメモリブロックの利用状況を次の表に示します。なお，サイズは，long型の値として取得できます。

表8-11　各APIで取得できるExplicitメモリブロックの利用状況

API | 取得できるExplicitメモリブロックの利用状況
freeMemory() | メモリの利用可能なサイズ（単位：バイト）
usedMemory() | 使用されているメモリのサイズ（単位：バイト）
totalMemory() | 確保済み総サイズ（単位：バイト）

各APIで取得できる値を次の図に示します。

図8-20　各APIで取得できる値

(3)　Explicitメモリブロックの情報の取得

Explicitヒープに実体があるExplicitメモリブロックの個数を取得します。状態が解放済みまたは無効になっているExplicitメモリブロックは対象になりません。有効なExplicitメモリブロックの個数を取得すると，各Explicitメモリブロックで使用されているメモリの平均サイズなどが算出できるようになります。

使用するAPI

countExplicitMemories()

このAPIは，Explicitヒープにあるメモリブロックの数を数えて，int型の値として返却します。数える対象になるのは，次の条件を満たしているExplicitメモリブロックです。

有効なExplicitメモリブロック
サブ状態が「Enable」または「Disable」のどちらの場合も対象になります。

解放予約済みのExplicitメモリブロック

(4)　Explicitメモリブロックの名称の設定と取得

Explicitメモリブロックに対応するインスタンスに名称を設定したり，設定されている名称を取得したりできます。Explicitメモリブロックのインスタンスは，アプリケーションで扱いやすいように，名称を持っています。任意の名称を設定することで，インスタンスを利用しやすくなります。

設定した値は，明示管理ヒープ機能のイベントログにも出力されます。

使用するAPI

setName()
名前を設定します。

getName()
名前を取得します。

なお，ユーザのアプリケーションで名前を設定しない場合，次に示すデフォルトの名前が設定されています。

BasicExplicitMemory-<ID>

<ID>は，JavaVMで管理している値です。

注意

Explicitメモリブロックの名称として，「CCC#」で始まる名前は付けないでください。「CCC#」で始まる名称は，J2EEサーバが使用します。

J2EEサーバで使用するExplicitメモリブロックの名称は次のとおりです。

CCC#HttpSession
HTTPセッションを配置するExplicitメモリブロックです。

CCC#HttpSessionManager
HTTPセッション管理用オブジェクトを配置するExplicitメモリブロックです。

CCC#Ajp13
リダイレクタとの通信用オブジェクトを配置するExplicitメモリブロックです。

(5)　Explicitメモリブロックの処理可能状態の判定

Explicitメモリブロックは，メモリ確保に失敗した場合などに処理不能な状態になることがあります。Explicitメモリブロックが処理可能な状態かどうかを判定できます。

使用するAPI

isActive()

APIを呼び出したときのExplicitメモリブロック（ExplicitMemoryインスタンス）の状態と，APIの戻り値の対応を次の表に示します。

表8-12　isActive()を呼び出したときのExplicitメモリブロックの状態とAPIの戻り値の対応

Explicitメモリブロックの状態 | サブ状態 | 戻り値
解放済み | － | false
無効 | － | false
解放予約済み | － | false
有効 | Enable | true
Disable | false

（凡例）

－：該当しません。

(6)　Explicitメモリブロックの解放予約状態の判定

Explicitメモリブロックが解放予約状態や解放済み状態になったあとでも，そのExplicitメモリブロックに対応するExplicitMemoryインスタンスは参照できます。APIを使用することで，アプリケーションから，Explicitメモリインスタンスの状態を確認できます。

使用するAPI

isReclaimed()

APIを呼び出したときのExplicitメモリブロック（ExplicitMemoryインスタンス）の状態と，APIの戻り値の対応を次の表に示します。

表8-13　isReclaimed()を呼び出したときのExplicitメモリブロックの状態とAPIの戻り値の対応

Explicitメモリブロックの状態 | サブ状態 | 戻り値
解放済み | － | true
無効 | － | true
解放予約済み | － | true
有効 | Enable | false
Disable | false

（凡例）

－：該当しません。

8.11　実行環境での設定

この節では，明示管理ヒープ機能を利用するための実行環境での設定について説明します。

注意

J2EEサーバでは，デフォルトでHTTPセッションに関するオブジェクトおよびリダイレクタとの通信用オブジェクトをExplicitヒープ領域に配置する設定になっています。

運用を開始する前に，必要なExplicitヒープサイズを見積もり，JavaVMオプション（-XX:HitachiExplicitHeapMaxSizeオプション）を適切な値にチューニングしてください。Explicitヒープのチューニングについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.2.2　チューニング手順」を参照してください。

＜この節の構成＞

8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）

8.11.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用

8.11.3　J2EEサーバで利用するための設定

8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）

ここでは，明示管理ヒープ機能を利用するための共通の設定について説明します。明示管理ヒープ機能を使用するための共通の設定は，JavaVMのオプションに設定します。

＜この項の構成＞

(1)　設定する内容

(2)　定義例

(1)　設定する内容

JavaVMのオプションは，設定対象になるサーバまたはコマンドによって設定方法が異なります。

J2EEサーバまたはバッチサーバの場合は，簡易構築定義ファイルで実施します。明示管理ヒープ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。cjclstartapコマンドで動作させるJavaアプリケーションの場合は，Javaアプリケーション用オプション定義ファイル（usrconf.cfg）で定義します。

明示管理ヒープ機能のJavaVMオプションの定義について次の表に示します。

表8-14　明示管理ヒープ機能のJavaVMオプションの定義

JavaVMオプション
設定内容
デフォルト値

-XX:[+|-]HitachiUseExplicitMemory
明示管理ヒープ機能を使用するかどうかを設定します。
サーバまたはコマンドによって異なります。表8-15を参照してください。

-XX:[+|-]HitachiAutoExplicitMemory
明示管理ヒープ機能の自動配置機能を使用するかどうかを設定します。
-XX:-HitachiAutoExplicitMemory

-XX:HitachiAutoExplicitMemoryFile: <文字列>
明示管理ヒープの自動配置機能を使用する場合に利用する，自動配置設定ファイルのパスを指定します。
空文字

-XX:[+|-]HitachiExplicitMemoryAutoReclaim
明示管理ヒープ機能の自動解放機能を使用するかどうかを指定します。
-XX:+HitachiExplicitMemoryAutoReclaim

-XX:[+|-]HitachiExplicitMemoryCompatibleToV8
Explicitメモリブロックを確保する方法を，08-00と同様にするかどうか指定します。08-50以降の新機能を利用しないで，08-00で動作するアプリケーションをそのまま08-50で動作させる場合，このオプションを有効にします。
-XX:-HitachiExplicitMemoryCompatibleToV8

-XX:HitachiExplicitHeapMaxSize※
Explicitヒープ領域の最大サイズを設定します。（単位：バイト）
-XX:HitachiExplicitHeapMaxSize =64m

-XX:HitachiExplicitMemoryLogLevel:<文字列>
<文字列>に明示管理ヒープ機能で出力するイベントログのログレベルを設定します。
次のどれかを指定します。

none

normal

verbose

debug

-XX:HitachiExplicitMemoryLogLevel:normal

-XX:HitachiExplicitMemoryJavaLog:<文字列>
<文字列>に明示管理ヒープ機能で出力するイベントログの出力先パス名を指定します。
Windowsの場合
-XX:HitachiExplicitMemoryJavaLog:<Cosminexusのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名>¥logs
UNIXの場合
-XX:HitachiExplicitMemoryJavaLog:/opt/Cosminexus/CC/server/public/ejb/<サーバ名>/logs

-XX:HitachiExplicitMemoryJavaLogFileSize=<整数値>
<整数値>にイベントログのファイルサイズを指定します。（単位：バイト）
-XX:HitachiExplicitMemoryJavaLogFileSize =4m

注※

見積もりについては，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.10　Explicitヒープのチューニング」を参照してください。

サーバまたはコマンドごとの-XX:[+|-]HitachiUseExplicitMemoryオプションのデフォルト値を次の表に示します。

表8-15　-XX:[+|-]HitachiUseExplicitMemoryオプションのデフォルト値

サーバまたはコマンドの種類 | デフォルトの設定
新規インストール時 | バージョンアップ時
J2EEサーバ | 有効 | 無効
バッチサーバ | 無効 | 無効
Webコンテナサーバ | － | －
SFOサーバ※ | － | －
cjclstartapコマンド | 無効 | 無効

（凡例）

有効：明示管理ヒープ機能がデフォルトで有効になっています。

無効：明示管理ヒープ機能がデフォルトで無効になっています。

－：明示管理ヒープ機能は使用できません。

注※

SFOサーバでは，明示管理ヒープ機能を有効にしても意味がありません。新規インストールの場合も，Smart Composer機能，セットアップウィザードまたは運用管理ポータルを使用して構築した場合は，無効になります。サーバ管理コマンドを使用して構築する場合は，無効にすることを推奨します。

指定するJavaVMオプション，および簡易構築定義ファイルで指定するタグの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　定義例

J2EEサーバまたはバッチサーバの場合，簡易構築定義ファイルまたは構成変更定義ファイルで定義します。論理J2EEサーバのJ2EEサーバ用オプション定義を設定するパラメタに設定してください。

簡易構築定義ファイルでの定義例を次に示します。

簡易構築定義ファイルでの定義例

<param-name>add.jvm.arg</param-name>
<param-value>-Xms512m</param-value>
<param-value>-Xmx512m</param-value>
<param-value>-XX:+HitachiUseExplicitMemory</param-value>
<param-value>-XX:HitachiExplicitHeapMaxSize=64m</param-value>

cjclstartapコマンドで動作させるJavaアプリケーションの場合は，Javaアプリケーション用オプション定義ファイル（usrconf.cfg）で定義します。

Javaアプリケーション用オプション定義ファイル（usrconf.cfg）での定義例を次に示します。

オプション定義ファイル（usrconf.cfg）での定義例

add.jvm.arg=-Xms512m
add.jvm.arg=-Xmx512m

add.jvm.arg=-XX:+HitachiUseExplicitMemory
add.jvm.arg=-XX:HitachiExplicitHeapMaxSize=64m

簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。Javaアプリケーション用オプション定義ファイル（usrconf.cfg）については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「15.2　usrconf.cfg（Javaアプリケーション用オプション定義ファイル）」を参照してください。

8.11.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用

明示管理ヒープ機能の自動配置機能は，自動配置設定ファイルを使って設定します。自動配置設定ファイルを使用することで，Javaプログラムを変更することなく明示管理ヒープ機能を使用できます。

自動配置設定ファイルには，Explicitヒープに配置したいオブジェクト，およびオブジェクトを生成する場所を指定します。なお，このファイルに指定したオブジェクト（Explicitメモリブロックに生成されたオブジェクト）から参照されているオブジェクトは，JavaヒープからExplicitメモリブロックへ移動します。オブジェクトの移動については「8.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

-XX:+HitachiAutoExplicitMemoryオプションを指定して，自動配置設定ファイルを使用して明示管理ヒープ機能を利用する場合の，自動配置設定ファイルの記述形式および記述する際の注意事項について説明します。

＜この項の構成＞

(1)　自動配置設定ファイルの記述形式

(2)　自動配置設定ファイルの記述例

(3)　自動配置設定ファイルの注意事項

(1)　自動配置設定ファイルの記述形式

自動配置設定ファイルの記述形式を次に示します。

<生成点>※, <指定したオブジェクトの完全修飾クラス名> # コメント
：
<生成点>※, <指定したオブジェクトの完全修飾クラス名>

注※

生成点の指定例を次に示します。

生成点の指定例
意味

*
すべてのパッケージのすべてのクラスに含まれる，すべてのメソッドでの，ユーザ指定オブジェクトの生成を生成点として指定します。

com.sample.*
com.sampleで始まるすべてのパッケージのクラスに含まれるメソッドでの，ユーザ指定オブジェクトの生成を生成点として指定します。
そのため，下位のパッケージ（com.sample.abc，またはcom.sample.abc.test）が存在する場合は，これらのパッケージも対象となります。

com.sample.Main
com.sample.Mainクラスに含まれるすべてのメソッド（コンストラクタ，および静的初期化子を含む）でのユーザ指定オブジェクトの生成を生成点として指定します。

com.sample.Main.main(java.lang.String[])
com.sample.Mainクラスで定義されたmain(java.lang.String[])メソッドでのユーザ指定オブジェクトの生成を生成点として指定します。

ポイント

構文要素を区切る空白文字は，半角スペース文字（「0x20」）またはタブ文字（「¥t」もしくは「0x09」)となります。

行末は改行文字（「¥n」もしくは「0x0A」）または復帰文字（「¥r」もしくは「0x0D」）が１文字以上続いたものとなります。

コメントは「#」で始まり，「#」から行末までの間の文字すべてをコメントとします。

生成点での文字「*」は，同一またはサブパッケージに存在するすべてのクラスを表します。サブパッケージのクラスも対象とする点で，Java言語のimport宣言の「*」と生成点の「*」は意味が異なります。

(2)　自動配置設定ファイルの記述例

自動設定ファイルの記述例を次に示します。

# comment
com.sample.*, java.util.ArrayList # comment
com.sample.Main.main(java.lang.String[]), java.util.LinkedList

記述例の内容について説明します。

１行目はすべてコメントとなります。

com.sample.* で始まるすべてのパッケージに含まれる，クラス，およびメソッドで生成されるjava.util.ArrayListオブジェクトを，Explicitメモリブロックに配置するように指定します。「#」から行末まではコメントとします。

com.sample.Main.main(java.lang.String[])メソッドで生成されるjava.util. LinkedListオブジェクトをExplicitメモリブロックに配置するように指定します。

参考

JavaVM内のクラス（例：java, javaxで始まるパッケージのクラス）をユーザ指定オブジェクトの生成点として指定したエントリを記述できます。しかし，指定したエントリが存在しないものとして扱われることがあります。存在しないものとして扱われた場合は，明示管理ヒープログへエラーメッセージは出力されません。

(3)　自動配置設定ファイルの注意事項

自動配置設定ファイルを指定する場合の注意事項を次に示します。

自動配置機能を使用することで，クラスローディング時間が増加し，その結果JavaVMの起動時間やアプリケーションサーバでのアプリケーションのデプロイ時間が増加する場合があります。

自動配置機能を使用することで，コピーガーベージコレクションの処理に時間が掛かる場合があります。

自動配置機能の対象となるオブジェクトは，newで生成しているオブジェクトだけです。JNIやリフレクションで生成しているオブジェクトは対象になりません。

クラス名，およびメソッドの引数は，java.langパッケージのクラスも含め，すべて完全修飾クラス名で記述してください。

（例）

誤：String

正：java.lang.String

ジェネリックス（総称）を用いたクラス名は記述できません。パラメタ化されていないクラス名（raw型）を記述してください。

（例）

誤：java.util.HashMap<java.lang.String, java.lang.Object>

正：java.util.HashMap

ネストしたクラスは，「.」ではなく「$」で区切った名前を記述してください。

（例）

誤：java.util.AbstractMap.SimpleEntry

正：java.util.AbstractMap$SimpleEntry

コンストラクタは，クラス名と同じメソッド名，または<init>と記述してください。MyMainクラスのコンストラクタの場合は次のように記述してください。

（例）

MyMain.MyMain() またはMyMain.<init>()

クラス名と同じ名前のメソッドが存在する場合，コンストラクタを指定しているのか，メソッドを指定しているのか判別できません。そのため，コンストラクタ，およびメソッドの両方を指定したものとして扱われます。

（例）

MyMain.MyMain(int) # MyMainクラスのint引数を持つコンストラクタと# MyMain(int)メソッドの両方を生成点とする

静的初期化子は，<clinit>と記述してください。MyMainクラスの静的初期化子の場合，次のように記述します。

（例）

MyMain.<clinit>()

フィールド宣言時の代入によるオブジェクトの生成を生成点に指定する場合，生成点にデフォルトコンストラクタを記述します。

ユーザ指定オブジェクトの完全修飾クラス名に配列を指定することはできません。

（例）

java.lang.String[]

存在しないクラス名，メソッド名，およびバイトコードを持たないメソッド（nativeメソッドおよびabstractメソッド)を含む行が存在する場合，その行は存在しないものとして扱います。

ユーザ指定オブジェクトのクラス名にJ2SEの内部クラスを指定した場合，明示管理ヒープ機能が適切なクラス名に読み替えることがあります。例えば，java.util.HashMap$Entryをjava.util.HashMapに読み替えます。

生成点としてJava言語仕様の限界に近い巨大なクラスやメソッドを指定した場合，自動配置に失敗する場合があります。この場合，明示管理ヒープ機能のイベントログの明示管理ヒープ自動配置エラーの<MESSAGE>として，"Invalid class file format"と出力されます。このような場合は，クラスやメソッドを小さくすることを検討してください。

8.11.3　J2EEサーバで利用するための設定

ここでは，J2EEサーバで明示管理ヒープ機能を利用するための設定について説明します。J2EEサーバでは，次のオブジェクトをExplicitヒープに配置する対象にするかどうかを，J2EEサーバのプロパティとして設定します。

HTTPセッションに関するオブジェクト

リダイレクタとの通信用オブジェクト

デフォルトでは，どちらのオブジェクトもExplicitヒープに配置するように設定されています。ただし，「8.11.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」で説明したJavaVMオプションで，明示管理ヒープ機能を使用しない設定に変更した場合は，J2EEサーバのプロパティの設定は無効になります。

＜この項の構成＞

(1)　設定方法

(2)　簡易構築定義ファイルの定義例

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。明示管理ヒープ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの明示管理ヒープ機能の定義について次の表に示します。

表8-16　簡易構築定義ファイルでの明示管理ヒープ機能の定義

指定するパラメタ | 設定内容
ejbserver.server.eheap.httpsession.enabled | HTTPセッションに関するオブジェクトをExplicitヒープに配置するかどうかを指定します。
ejbserver.server.eheap.ajp13.enabled | リダイレクタとの通信用オブジェクトをExplicitヒープに配置するかどうかを指定します。

指定するパラメタの詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.14　論理J2EEサーバで指定できるパラメタ」を参照してください。

次に，JavaVMオプションと各プロパティの関係について説明します。

JavaVMオプションとejbserver.server.eheap.httpsession.enabledプロパティの関係

前提となるJavaVMオプションとejbserver.server.eheap.httpsession.enabledプロパティの指定値によって，HTTPセッションに関するオブジェクトの配置先が異なります。HTTPセッションに関するオブジェクトの配置先を次の表に示します。

表8-17　JavaVMオプションとejbserver.server.eheap.httpsession.enabledプロパティの値によるHTTPセッションに関するオブジェクトの配置先

JavaVMオプション | ejbserver.server.eheap.httpsession.enabledプロパティの値 | 配置先
-XX:+HitachiUseExplicitMemory | true | Explicitヒープ領域
false | Javaヒープ領域
そのほか（不正な文字列，指定なしなど） | Explicitヒープ領域
-XX:-HitachiUseExplicitMemory | true | Javaヒープ領域
false
そのほか（不正な文字列，指定なしなど）
指定なし | true | Javaヒープ領域
false
そのほか（不正な文字列，指定なしなど）

JavaVMオプションとejbserver.server.eheap.ajp13.enabledプロパティの関係

前提となるJavaVMオプションとejbserver.server.eheap.ajp13.enabledプロパティの値によって，リダイレクタとの通信用オブジェクトの配置先が異なります。リダイレクタとの通信用オブジェクトの配置先を次の表に示します。

表8-18　JavaVMオプションとejbserver.server.eheap.ajp13.enabledプロパティの値によるリダイレクタとの通信用オブジェクトの配置先

JavaVMオプション | ejbserver.server.eheap.ajp13.enabledプロパティの値 | 配置先
-XX:+HitachiUseExplicitMemory | true | Explicitヒープ領域
false | Javaヒープ領域
そのほか（不正な文字列，指定なしなど） | Explicitヒープ領域
-XX:-HitachiUseExplicitMemory | true | Javaヒープ領域
false
そのほか（不正な文字列，指定なしなど）
指定なし | true | Javaヒープ領域
false
そのほか（不正な文字列，指定なしなど）

(2)　簡易構築定義ファイルの定義例

簡易構築定義ファイルでの定義例を次に示します。

簡易構築定義ファイルでの定義例

<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
 <param>
   <param-name>ejbserver.server.eheap.httpsession.enabled</param-name>
   <param-value>true</param-value>
 </param>
 <param>
   <param-name>ejbserver.server.eheap.ajp13.enabled</param-name>
   <param-value>true</param-value>
 </param>
    ：
</configuration>

8.12　明示管理ヒープ機能使用時の注意事項

この節では，明示管理ヒープ機能使用時の注意事項について説明します。

＜この節の構成＞

(1)　Javaヒープの初期サイズと最大サイズの設定

(2)　HTTPセッションに関するオブジェクトでExplicitヒープを利用する際の注意

(1)　Javaヒープの初期サイズと最大サイズの設定

Javaヒープの初期サイズ（-Xms）と最大サイズ（-Xmx）には，必ず同じ値を指定してください。同じ設定でない場合，コピーガーベージコレクションの回数が増加するおそれがあります。

なお，この設定は，明示管理ヒープ機能を使用しない場合にも推奨の設定です。

補足：

Javaヒープの初期サイズと最大サイズが異なる場合，各領域のサイズは，次のタイミングで変更されます。

コピーガーベージコレクション終了時
New領域のサイズが動的に変更されます。

フルガーベージコレクション終了時
Tenured領域とNew領域のサイズが動的に変更されます。

New領域のサイズは，主にTenured領域のサイズと-XX:NewRatioオプションに指定した値によって決まります。

明示管理ヒープ機能によってフルガーベージコレクションの発生が抑止されると，Tenured領域のサイズが変更されるタイミングがなくなります。これに伴って，New領域のサイズも，ほぼ一定になります。

このため，初期サイズよりも大きい最大サイズを定義していても，New領域が拡張されるタイミングがなくなり，初期サイズで指定したままのサイズになります。初期サイズで指定したNew領域が小さい場合，明示管理ヒープ機能を使用しない場合に比べて，コピーガーベージコレクションが多く発生するおそれがあります。

(2)　HTTPセッションに関するオブジェクトでExplicitヒープを利用する際の注意

HTTPセッション生成以降，setAttributeメソッドで設定したすべてのセッション属性（オブジェクト）は，HTTPセッションを破棄するまで解放されないで，Explicitヒープに残存します。その時点でHTTPセッションに設定されているかどうかは関係ありません。このため，HTTPセッションを破棄しないでsetAttributeメソッドを繰り返し実行した場合，Explicitヒープあふれが発生して，フルガーベージコレクション抑止の効果が得られないおそれがあります。Explicitヒープあふれが発生しているかどうかを確認するには，マニュアル「Cosminexus アプリケーションサーバ システム設計ガイド」の「7.11.4　アプリケーション開発・運用時の確認・調査」を参照してください。

自動解放機能を利用しない場合（-XX:-HitachiExplicitMemoryAutoReclaimの場合）において，HTTPセッションを削除する時に，そのセッションに格納したオブジェクトへの外部からの参照が残っているオブジェクトは，ExplicitヒープからJavaヒープのTenured領域に移動します。この場合，Tenured領域の使用済みサイズが増加することになり，フルガーベージコレクションの発生を抑止できません。
ExplicitヒープからJavaヒープへのオブジェクトの移動を防ぐためには，HTTPセッションを破棄する前に，セッションに格納したオブジェクトへの参照を削除する必要があります。
次のAPIを使用して取得したオブジェクトへの参照が残っている場合も同様です。

getAttribute(String)

getAttributeNames()

なお，自動解放機能を利用する場合（-XX:+HitachiExplicitMemoryAutoReclaimの場合）は，それらのオブジェクトがJavaヒープのTenured領域に移動することはありません。

次の場合，オブジェクトはExplicitヒープではなくJavaヒープに配置されます。

Explicitメモリブロックの数が最大値になっており，新たにExplicitメモリブロックを作成できない場合（同時に存在するExplicitメモリブロックが1,048,575個になっている場合）に，新しいセッションを生成した場合

Explicitヒープ領域の最大サイズを超えた場合

Explicitメモリブロックを確保できなかった場合

これらに該当する場合，オブジェクトはJavaヒープに作成されるため，フルガーベージコレクションの発生抑止ができないおそれがあります。

JSPでは，デフォルトで暗黙的にHttpSessionオブジェクトが作成されます。不要なHttpSessionオブジェクトの生成によるExplicitヒープあふれを防ぐため，セッションを必要としないJSPでは，明示的にHttpSessionオブジェクトを作成しない設定にしてください。設定には，pageディレクティブのsession属性を使用します。

フルガーベージコレクション抑止の効果を検証するテストを実行する場合，セッションを破棄しないままで連続してセッションを生成し続けるような条件では実行しないでください。Explicitメモリブロックが解放されないため，Explicitヒープがあふれる可能性が高くなります。
また，Explicitメモリブロックは，セッションが破棄されたときに解放予約され，その後，ガーベージコレクションが発生したときに解放されます。このため，セッションを破棄していても，セッションの破棄と生成の繰り返し回数が1回のガーベージコレクション間隔に対して多過ぎる場合には，解放予約されたExplicitメモリブロックが残存したままの状態で別のExplicitメモリブロックが作成されてしまいます。その結果，Explicitメモリブロックの個数が増加し，Explicitヒープがあふれるおそれがあります。
フルガーベージコレクション抑止の効果を検証するには，セッションを適切に管理する条件でテストを実行してください。

セッションに格納したオブジェクトは，生成直後はJavaヒープに配置されます。何度かコピーガーベージコレクションが実行されたあと，通常はTenured領域に昇格するタイミングでExplicitヒープに移動します。このため，短時間で削除される場合や，セッションがすぐに破棄される場合は，オブジェクトはExplicitヒープには配置されません。

9.　クライアント性能の測定と分析

この章では，アプリケーションサーバで提供するクライアント性能モニタ機能について説明します。

＜この章の構成＞

9.1　クライアント性能モニタ機能

9.2　クライアント性能モニタ機能を使用するための実装

9.3　実行環境の設定

9.4　クライアント性能モニタ機能の運用

9.5　クライアント性能モニタ機能についての注意事項

9.1　クライアント性能モニタ機能

この節では，クライアント性能モニタ機能について説明します。

クライアント性能モニタ機能を使用すると，Webアプリケーションを操作するときの処理時間をクライアントの視点で測定および分析できます。

この章の構成を次の表に示します。

表9-1　この章の構成（クライアント性能モニタ機能）

分類 | タイトル | 参照先
解説 | クライアント性能モニタ機能の概要 | 9.1.1
前提条件 | 9.1.2
クライアント性能モニタ機能で実行される処理 | 9.1.3
クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間と分析方法 | 9.1.4
クライアント性能モニタ機能を構成する要素 | 9.1.5
クライアント性能モニタのディレクトリ構成 | 9.1.6
実装 | DDでの定義 | 9.2.1
クライアント性能フィルタの定義方法 | 9.2.2
問い合わせIDの定義方法 | 9.2.3
モニタページのアクセス制御の定義方法 | 9.2.4
DDのサンプル | 9.2.5
Webブラウザから性能データを読み出すアプリケーションの作成 | 9.2.6
クライアント性能測定スクリプトの挿入条件 | 9.2.7
設定 | サーバ側の設定 | 9.3.1
ブラウザ側の設定 | 9.3.2
運用 | モニタページの画面構成 | 9.4.1
モニタページを表示する | 9.4.2
性能情報を表示する | 9.4.3
統計情報を表示する | 9.4.4
性能データを削除する | 9.4.5
注意事項 | クライアント性能モニタ機能運用時の注意事項 | 9.5.1
モニタページに関する注意事項 | 9.5.2

＜この節の構成＞

9.1.1　クライアント性能モニタ機能の概要

9.1.2　前提条件

9.1.3　クライアント性能モニタ機能で実行される処理

9.1.4　クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間と分析方法

9.1.5　クライアント性能モニタ機能を構成する要素

9.1.6　クライアント性能モニタのディレクトリ構成

9.1.1　クライアント性能モニタ機能の概要

クライアント性能モニタ機能とは，作成したWebアプリケーションを操作するときの処理時間をクライアントの視点で測定して，分析する機能です。Webアプリケーションの通信に掛かる時間，Webブラウザの描画に掛かる時間，ユーザがWebブラウザ上で操作を実行するまでに掛かる時間などの性能データを測定することで，サーバ側の性能測定ではわからなかった次のことが分析できます。

システム性能に問題がないか

サーバ側，Webブラウザ側のどちらに問題があるのか

性能データには，Webアプリケーションの一つ一つの操作に対する情報（性能情報）と性能情報を画面遷移の単位で統計した情報（統計情報）があります。

性能データの測定中，ユーザはクライアント性能モニタ機能が動作していることを意識しないで，Webアプリケーションを操作できます。ユーザがWebブラウザを使用してWebアプリケーションを操作している間に，自動的に処理時間が記録されます。

また，クライアント性能モニタ機能を導入するときに，ユーザ一人一人のマシンにプログラムをインストールする必要はありません。Webアプリケーションに対して，サーブレットフィルタが動作するように設定するだけで導入できます。

さらに，クライアント性能モニタ機能の性能データに付与される問い合わせIDをサーバ側の性能解析トレース（PRFトレース）のルートアプリケーション情報と突き合わせることができます。このことで，Webアプリケーションに発生した性能問題について，サーバ側，およびクライアント側の両面から分析できます。

クライアント性能モニタ機能の概要を次の図に示します。

図9-1　クライアント性能モニタ機能の概要図

9.1.2　前提条件

クライアント性能モニタ機能は，サーバ側で動作する機能とクライアント側で動作する機能に分かれます。ここでは，クライアント側で動作する機能の前提条件について説明します。

＜この項の構成＞

(1)　クライアント側で動作する機能の前提条件

(2)　サーバ種別

(3)　クライアント性能モニタのメモリ所要量

(4)　PRFデーモンの起動

(1)　クライアント側で動作する機能の前提条件

ハードウェア

日立FLORAシリーズ

他社PC/AT互換機

1024×768以上の解像度で表示できるディスプレイ装置

OS

Windows Server 2003※

Windows Server 2003 R2

Windows Server 2003（x64）※

Windows Server 2003 R2（x64）

Windows Server 2008 x86

Windows Server 2008 x64

Windows Server 2008 R2

Windows XP

Windows Vista

Windows 7

注※　SP1を適用する必要があります。

Webブラウザ

Internet Explorer 6

Internet Explorer 7

Internet Explorer 8

(2)　サーバ種別

クライアント性能モニタ機能がサポートするサーバ種別を次の表に示します。

表9-2　クライアント性能モニタ機能がサポートするサーバ種別

項番 | サーバ種別 | サポート状況
1 | J2EEサーバ | 1.4モード | ○
2 | ベーシックモード | ×
3 | Webコンテナサーバ（サーブレットエンジンモード） | ×
4 | バッチサーバ | ×
5 | SFOサーバ | ×

（凡例）　○：サポートする　×：サポートしない

(3)　クライアント性能モニタのメモリ所要量

クライアント性能モニタのメモリ所要量は，次に示す計算式で算出してください。

クライアント性能モニタのメモリ所要量（単位：キロバイト）

300＋A×10×（同時リクエストの処理数）

Aはクライアント性能フィルタの初期化パラメタfilterSizeに指定した値です。ただし，サーブレットからsetBufferSize()メソッドを発行してバッファサイズを変更した場合は，filterSizeまたはsetBufferSize()メソッドで指定した値のどちらか大きい方とします。

(4)　PRFデーモンの起動

クライアント性能モニタ機能を使用する場合は，必ずPRFデーモンを起動してください。PRFデーモンは，Webサーバ，J2EEサーバなど，ルートアプリケーション情報を生成するプロセスが起動する前に起動してください。

PRFデーモンはcprfstartコマンドで起動します。cprfstartコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cprfstart（PRFデーモンの開始）」を参照してください。

また，Management ServerでPRFデーモンを管理している場合，運用管理ポータルでも起動できます。運用管理ポータルでの起動についてはマニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「11.4.2　パフォーマンストレーサの起動」を参照してください。

9.1.3　クライアント性能モニタ機能で実行される処理

クライアント性能モニタ機能の処理は，性能データの取得と，取得した性能データの表示という二つのフェーズに分かれます。

フェーズごとに実行される処理について説明します。

＜この項の構成＞

(1)　性能データの取得

(2)　性能データの表示

(1)　性能データの取得

性能データの取得フェーズでは，クライアント性能モニタ機能が有効になったWebアプリケーションにWebブラウザからアクセスして，性能データを取得します。このフェーズでは，クライアント性能モニタ機能が有効であることを意識しないで，Webアプリケーション上で一連の操作ができ，Webブラウザに性能データが記録されます。

性能データの取得フェーズで実行される処理の一覧を次の表に示します。

表9-3　性能データの取得フェーズで実行される処理

項番
処理
説明

1
クライアント性能測定スクリプトの自動挿入
Webアプリケーションに対して，クライアント性能測定スクリプトを自動的に挿入します。

2
クライアント性能の記録
WebアプリケーションをWebブラウザで操作しているときに，クライアント性能データを自動的に取得します。

3
ログシーケンスの管理
性能データをログシーケンスの単位でまとめて管理します。
ログシーケンスは，Webアプリケーションの一連の操作での画面遷移の単位です。
ログシーケンスについては，「9.1.4(2)　ログシーケンス」を参照してください。

なお，サーブレットフィルタの初期化パラメタを設定することで，クライアント性能フィルタやクライアント性能測定スクリプトの挙動を調節できます。設定項目については，「9.2.1(2)　任意項目」を参照してください。

(2)　性能データの表示

性能データの表示フェーズでは，性能データの取得フェーズで記録されたデータを確認，および分析できます。性能データの確認は，次の方法で実施できます。

性能データをモニタページに表示させて確認する

性能データをサーバ側で収集して確認する

性能データを確認する流れを次に示します。

性能データをモニタページに表示させて確認する場合

モニタページの表示
モニタページを表示します。モニタページを表示することで，Webブラウザに保存されている性能データにアクセスできます。

統計情報の確認
性能データの統計値を確認します。統計情報を分析し，異常値を示しているURLがないかを確認します。

性能情報の表示と問題個所の特定
性能情報の一覧を表示し，異常値を示しているリクエストが発生した時刻，およびそのときの問い合わせIDを確認します。

前後の操作の流れを確認
クライアント性能モニタ機能では，ログシーケンスとして画面遷移の流れを保持しています。問題があったリクエストに至るまでのWebアプリケーションの画面遷移の流れを確認します。Webブラウザを閉じる前の操作情報など，過去のログシーケンスについても情報を確認できます。

性能データの削除
確認および分析作業が終了したら，不要な性能データを削除します。

性能データをサーバ側で収集して確認する場合

アプリケーションの作成
API（ClientPerformance.getAllLogメソッド）を使用して，サーバ側に性能データを収集するためのアプリケーションを作成します。アプリケーションの作成方法については，「9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成」を参照してください。

性能データの読み出しとサーバ側での収集
作成したアプリケーションにアクセスして，Webブラウザに保存されている性能データをサーバ側に収集します。

性能データの確認
サーバ側に収集したデータを解析します。異常値を示しているリクエストが発生した時刻，およびそのときの問い合わせIDを確認します。この場合，クライアント側にモニタページを表示することなく，サーバ側だけで性能データを確認できます。

性能データの表示フェーズで提供する機能の一覧を次の表に示します。

表9-4　性能データの表示フェーズで提供する機能

項番
機能
説明

1
ログシーケンスの一覧表示
Webブラウザに保存されたログシーケンスの一覧を表示します。
ログシーケンスについては，「9.1.4(2)　ログシーケンス」を参照してください。

2
性能情報の表示
リクエストごとに，次に示す性能情報の値を表示します。

通信時間

描画時間

応答時間

操作時間

性能情報には問い合わせIDが付与されるため，性能解析トレースの情報と突き合わせることができます。
性能情報の表示については，「9.4.3　性能情報を表示する」を参照してください。

3
統計情報の表示
統計情報を表示します。統計情報を確認することで，Webアプリケーションでの各画面の性能や品質を分析できます。
統計情報の表示については，「9.4.4　統計情報を表示する」を参照してください。

4
性能データの削除
保存されている性能データを削除できます。削除は次の方法で実施できます。

一括削除

部分削除

性能データの削除については，「9.4.5　性能データを削除する」を参照してください。

5
性能データの読み出し
API（ClientPerformance.getAllLogメソッド）を使用して，性能データを読み出すことができます。ユーザは，クライアント性能モニタで提供しているサンプルを使用して性能データをサーバ側で収集する仕組みを作成できます。
性能データの読み出しについては，「9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成」を参照してください。

9.1.4　クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間と分析方法

ここでは，クライアント性能モニタ機能で測定できる処理時間，画面遷移の単位となるログシーケンスの概念，処理時間の分析方法，および性能解析トレースとのマッチングについて説明します。

＜この項の構成＞

(1)　測定できる処理時間

(2)　ログシーケンス

(3)　処理時間の分析

(4)　性能解析トレースとのマッチング

(1)　測定できる処理時間

クライアントがWebブラウザを操作するときの処理のサイクルを次の図に示します。

図9-2　Webブラウザから見たWebアプリケーションの処理サイクル

クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間について説明します。なお，図中の数字は，説明の番号と対応しています。

通信時間（（1）～（2））※1※2※3※4

Webブラウザが，アプリケーションサーバに対してリクエストを送信してから，レスポンスを受けて画面の描画を開始するまでの時間です。

描画時間（（2）～（3））※2※3※4※5

Webブラウザが画面の描画を開始してから，画面の描画が完了するまでの時間です。

応答時間（（1）～（3））※3※4

ユーザがサーバに対するリクエストを送信してから，次の操作ができるようになるまでの時間です。通信時間と描画時間の合計に当たります。

操作時間（（3）～（1））※3※4

画面の描画が完了したあと，次の操作（アプリケーションサーバに次のリクエストを送信する，ブラウザを閉じるなど）を実行するまでの時間です。

注※1

最初にWebアプリケーションへリクエストした場合，クライアント性能モニタ機能を適用していない画面から適用しているWebアプリケーションへリクエストを送信した場合など，通信時間が記録されないことがあります。

注※2

Webブラウザの処理によって，サーバからすべてのレスポンスを受信する前に，Webブラウザが画面の描画を開始することがあります。この場合，画面の描画開始以降に並行して実行された通信処理の時間は，通信時間としては記録されません。この場合の例を次の図に示します。

図9-3　すべてのレスポンスを受信する前にWebブラウザが画面の描画を開始する場合の処理時間の例

注※3

WebアプリケーションがダイナミックHTMLの各種イベントで独自の処理を実行するような場合，その独自の処理時間が通信時間，描画時間，操作時間のどの情報として記録されるかは不定です。

注※4

記録される値には，クライアント性能モニタ機能自体が動作する処理時間も含まれます。

注※5

ダイナミックHTMLを利用したWebアプリケーションの場合，Webブラウザの描画完了イベントが通知されたあと，さらに表示内容を変化させることができます。この場合，Webブラウザの描画完了イベントが通知されるまでの時間を描画時間として記録します。それ以降の表示内容を変化させる処理時間は，描画時間としては記録されません。

(2)　ログシーケンス

ログシーケンスとは，Webアプリケーションを操作した場合に画面遷移の単位で測定される性能データの集まりを指します。性能データはログシーケンスの単位で管理されます。あるページの性能データについて確認する場合，ログシーケンスの内容を分析することで，クライアントがWebアプリケーションのどのような画面遷移の結果として処理を実行したのかを確認できます。ログシーケンスのイメージを次の図に示します。

図9-4　ログシーケンス

ログシーケンス1は，ブラウザ1の画面が遷移することで測定された性能データのすべてを示します。ログシーケンス2は，ブラウザ1から別の画面（ブラウザ2）が表示された場合に，ブラウザ2の画面が遷移することで測定された性能データのすべてを示します。このように，ログシーケンスはある操作を契機として分岐します。ログシーケンスの分岐について，次に示します。

ログシーケンスの分岐

ログシーケンスは次の操作を契機として分岐します。

複数のWebブラウザを起動して同じWebアプリケーションにアクセスしている場合※1

Webブラウザを閉じたあと，再びWebブラウザを開いてWebアプリケーションにアクセスした場合※2

ほかのサイト，またはほかのWebアプリケーションにアクセスした場合※2※3

ポップアップウィンドウを開いたり，リンクを新しいウィンドウで開いたりした場合

注※1

一方のWebブラウザを操作している時間は，もう一方のログシーケンスの性能データには操作時間として計上されます。

注※2

分岐の契機が認識されないで，直前に操作していた画面のログシーケンスとつながることがあります。その場合は，通信時間の値が実際の通信に掛かった時間よりも長く計上されます。

注※3

フレーム構成のWebブラウザでほかのWebページやWebアプリケーションへの遷移があると，ログシーケンスが複雑に分岐したように認識されることがあります。

(3)　処理時間の分析

測定した処理時間を分析することで，次のことを確認できます。

システム性能に問題がないか。
システム性能に問題がないかを確認したい場合は，応答時間と操作時間に注目します。応答時間の値が大きい場合は，システム性能に問題があるおそれがあります。操作時間の値が大きい場合は，必ずしもシステム性能に問題があるとは限りませんが，Webアプリケーションがユーザにとって操作しにくい画面構成になっている場合が考えられます。

サーバ側，Webブラウザ側のどちらに問題があるのか。
問題点がサーバ側の処理にあるのか，またはWebブラウザ上の処理にあるのかを分析したい場合は，通信時間と描画時間の比率に注目します。通信時間の値が大きい場合，サーバ側での処理に問題があるおそれがあります。描画時間の値が大きい場合，負荷の大きいスクリプト処理などによって，Webブラウザの画面の描画処理に時間が掛かっているおそれがあります。

(4)　性能解析トレースとのマッチング

次の二つの性能データをマッチングさせることで，サーバ側とクライアント側の処理を含めたWebアプリケーションの処理全体の性能情報を分析できます。

クライアント性能モニタ機能で測定したWebブラウザ上の性能データ

性能解析トレースで測定したサーバマシン上の性能データ

クライアント性能モニタ機能で通信時間として記録された時間内の処理は，性能解析トレースでさらに詳しく分析できます。性能解析トレースについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「6.　性能解析トレースを使用したシステムの性能解析」を参照してください。

マッチング方法

クライアント性能モニタ機能では，リクエストごとに問い合わせIDが付与されます。この問い合わせIDは性能解析トレースのルートアプリケーション情報と対になっています。問い合わせIDの定義方法については，「9.2.3　問い合わせIDの定義方法」を参照してください。

問い合わせIDにマッチしたルートアプリケーション情報を確認してください。

性能解析トレースとクライアント性能モニタ機能のマッチングについて次の図に示します。

図9-5　性能解析トレースとクライアント性能モニタ機能のマッチング

9.1.5　クライアント性能モニタ機能を構成する要素

クライアント性能モニタ機能は，次の三つの要素から構成されます。

クライアント性能フィルタ

クライアント性能測定スクリプト

モニタページ

各要素について説明します。

＜この項の構成＞

(1)　クライアント性能フィルタ

(2)　クライアント性能測定スクリプト

(3)　モニタページ

(1)　クライアント性能フィルタ

クライアント性能測定スクリプトのコードを測定したい対象に埋め込む機能を持ったサーブレットフィルタです。また，Webブラウザから，クライアント性能測定スクリプト，またはモニタページへアクセスするためのURLがリクエストされた場合，クライアント性能測定スクリプト，またはモニタページをフィルタで生成し，出力します。

(2)　クライアント性能測定スクリプト

クライアントがWebアプリケーションを操作するときに，クライアント性能測定スクリプトがWebブラウザ上で動作し，各種イベントの時刻を性能データとして記録します。性能データはクライアントマシンのuser Data領域に記録されます。

(3)　モニタページ

クライアント性能測定スクリプトが記録した性能データをクライアントマシンのブラウザ上に表示するためのWebアプリケーションです。クライアント性能フィルタで自動的に生成されます。モニタページの操作方法については，「9.4　クライアント性能モニタ機能の運用」を参照してください。

9.1.6　クライアント性能モニタのディレクトリ構成

クライアント性能モニタ機能のディレクトリ構成を次に示します。クライアント性能モニタで提供しているサンプルは次の場所に格納されています。

9.2　クライアント性能モニタ機能を使用するための実装

この節では，クライアント性能モニタ機能を使用するための実装について説明します。DDでの定義の一覧を9.2.1に示し，個々の定義方法を9.2.2～9.2.4で説明します。

＜この節の構成＞

9.2.1　DDでの定義

9.2.2　クライアント性能フィルタの定義方法

9.2.3　問い合わせIDの定義方法

9.2.4　モニタページのアクセス制御の定義方法

9.2.5　DDのサンプル

9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成

9.2.7　クライアント性能測定スクリプトの挿入条件

9.2.1　DDでの定義

クライアント性能モニタ機能の設定は，クライアント性能フィルタで実行されます。

ここでは，アプリケーションの開発環境で必要なDDでの定義について，必須項目と任意項目に分けて説明します。DDでのクライアント性能モニタ機能の定義はweb.xmlに指定します。

＜この項の構成＞

(1)　必須項目

(2)　任意項目

(1)　必須項目

DDでの定義で必ず指定しなければならない項目は次の二つです。

サーブレットフィルタの定義

フィルタマッピング

定義方法については，「9.2.2　クライアント性能フィルタの定義方法」を参照してください。

(2)　任意項目

クライアント性能フィルタに指定する項目は，サーブレットフィルタの初期化パラメタ（<init-param>タグ）として定義します。

DDでの定義で任意に指定できる項目を次の表に示します。これらの項目は，サーブレットフィルタの初期化パラメタ（<filter>タグ内の<init-param>タグ）に指定します。なお，各項目に指定範囲外の値や文字列，誤った文法などを指定した場合はエラーとなり，Webアプリケーションが開始できません。

表9-5　DDでのクライアント性能モニタ機能の定義でカスタマイズできる項目

項番
項目
<param-name>に指定する要素
<param-value>に指定する内容
デフォルト値

1
使用するリソース名の先頭文字列
resourcePrefix
クライアント性能モニタ機能で使用する次のリソース名の先頭文字列をほかの文字列に置き換えたい場合に指定します。

Cookie名

HTMLドキュメントのエレメントのid属性

user Dataビヘイビアで保存されるファイル名

先頭文字列は，半角英字（A～Z（大文字））の5文字の文字列で指定します。
この項目は，通常は指定する必要はありません。ユーザが作成したWebアプリケーションの中に「CPMON_」で始まるCookie名が含まれている場合などに，名前の重複を避けるために指定してください。
CPMON

2
Webブラウザ上の性能データの有効期限
dataExpire
Webブラウザ上に保存される性能データ全体の有効期限を分単位で指定します。値は，1～1440の整数で指定します。
ここで指定する有効期限は，すべての性能データで共有されます。クライアント性能測定スクリプトやモニタページの操作で，性能データが更新（追加，削除など）されるたびに，有効期限が再設定されます。性能データが更新されないまま有効期限を超えた場合は，すべての性能データが有効期限切れとなります。
なお，ここで指定する有効期限は，クライアント性能モニタ機能が保証する期間です。この期限を過ぎると即座に性能データが失われるわけではありません。
また，有効期限内の性能データであっても，dataMaxCountに設定した個数，またはWebブラウザのリソースの上限値を超えたデータは削除対象となります。
60

3
問い合わせIDの先頭文字列
idAddrNameMapping
問い合わせIDの先頭文字列にあるIPアドレス部分をほかの文字列に置き換えたい場合に指定します。
先頭文字列には，半角英数字（0～9，A～Z（大文字））の組み合わせで15文字以内の文字列を指定します。クライアントにホストのIPアドレスを公開しない場合に指定してください。
この項目を指定する場合の構文を次に示します。

構文

IPアドレス=置き換え文字列

複数のIPアドレスを指定する場合は，半角セミコロン「;」を区切り文字として指定してください。「;」の前後の空白文字は無視されます。最後の「;」は無視されます。

複数指定する場合の例

IPアドレス=置き換え文字列;IPアドレス=置き換え文字列;・・・

なお，問い合わせIDのIPアドレスがここで指定したどのアドレスとも一致しなかった場合は，問い合わせIDのIPアドレスがそのままクライアントに送信されます。
問い合わせIDについては，「9.2.3　問い合わせIDの定義方法」を参照してください。
－

4
クライアント性能フィルタのバッファサイズ
filterSize
クライアント性能フィルタが最低限確保するバッファサイズをバイト単位で指定します。値は，1024～2097152の整数で指定します。
WebアプリケーションのHTMLコンテンツで，<BODY>タグまたは<FRAMESET>タグが現在のバッファサイズよりもあとに設定されて，クライアント性能測定スクリプトが挿入されない場合は，この指定値を大きくしてください。ただし，値を大きくした場合，処理性能が低下します。
8192

5
性能データを保存する個数
dataMaxCount
Webブラウザ上に保存する性能データの個数を指定します。値は，10～200の整数で指定します。
この値を超える性能データが記録された場合，古い性能データから順番に削除対象として扱われます。削除対象の性能データは，任意のタイミングで削除されます。ただし，実際に削除されるまでは，通常の性能データと同様に扱うことができます。
また，性能データの個数が保存できる上限値以内であっても，dataExpireに設定した有効期限，またはWebブラウザのリソースの上限値を超えたデータは削除対象となります。
50

6
クライアント性能モニタを適用しないページの指定
ignorePages
クライアント性能モニタ機能を適用しないページのパスを指定します。性能データを読み出すアプリケーションを作成した場合，このパスを指定して測定対象から除きます。
通常は指定する必要はありません。
パスには，コンテキストルート以下を指定してください。
複数のパスを指定する場合は，半角セミコロン「;」を区切り文字として指定してください。「;」の前後の空白文字は無視されます。また，最後の「;」は無視されます。

複数指定する場合の例

/monitor/MyMonitor.html;/MyMonitor2.html

－

7
Webブラウザ側のエラー表示方法の指定
printErrorBox
Webアプリケーションに埋め込まれたクライアント性能測定スクリプトの実行中にエラーが発生した場合，エラーメッセージをWebブラウザのダイアログボックスに表示するかどうかを指定します。値は，OnまたはOffで指定します。

On

エラーメッセージを表示します。

Off

エラーメッセージを表示しません。

クライアント性能モニタ機能が動作していることをユーザに意識させたくない場合などに指定します。

この項目の指定は次のエラー発生時に有効です。

クライアント性能測定スクリプトによる性能データの取得フェーズでのエラー

API（ClientPerformance.getAllLogメソッド）実行時のエラー

なお，モニタページの操作中に発生したエラーメッセージは，この設定内容に関係なくWebブラウザのダイアログボックスに表示されます。
Off

8
モニタページの表示レベルの指定
monitorPageEnableLevel
モニタページの表示レベルを指定します。指定した表示レベル以外のモニタページへアクセスした場合は，404 Not Foundが表示されます。値は，Test，MonitorまたはAPIのどれかで指定します。

Test

クライアントからモニタページ，および性能データを読み出すためのAPI（ClientPerformance.getAllLogメソッド）のサンプル画面が表示できます。また，API（ClientPerformance.getAllLogメソッド）を実行できます。この値はテスト環境以外では指定しないでください。サンプル画面は確認用の画面です。

Monitor

クライアントからモニタページを表示できます。また，API（ClientPerformance.getAllLogメソッド）を実行できます。

API

クライアントからは，API（ClientPerformance.getAllLogメソッド）だけが実行できます。

モニタページをユーザに公開しない場合などにこの値を指定してください。APIを指定した場合は，性能データを読み出すための画面を作成する必要があります。

性能データを読み出すための画面の作成については，「9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成」を参照してください。また，モニタページの表示レベルの指定については，「9.2.4　モニタページのアクセス制御の定義方法」を参照してください。
Monitor

9
性能データの異常値を検出するのためのしきい値
warningThreshold
通信時間，描画時間，応答時間および操作時間のそれぞれの値で，異常値と判定するしきい値をミリ秒単位で指定します。しきい値は，0～86400000の整数で指定します。
しきい値を指定する場合の構文を次に示します。

構文

(通信時間のしきい値, 描画時間のしきい値, 応答時間のしきい値, 操作時間のしきい値)

指定したしきい値を超えた場合，モニタページで性能情報や統計情報を表示したときに，該当する値のセルが赤い警告色で表示されます。
また，値に0を指定した場合は，しきい値は設定されません。この場合，警告色は表示されません。
(3000, 3000, 6000, 0)

10
保存するファイル名の最大長
urlMaxLength
性能データに記録するURLのファイル名の最大長を指定します。値は，16～64の整数で指定します。通常は指定する必要はありません。
性能データのファイル名が途中で切れてしまう場合は，この指定値を大きくすることで対応できます。ただし，値を大きくした場合は，保存できる性能データの個数が減少します。
16

（凡例）　－：なし

9.2.2　クライアント性能フィルタの定義方法

ここでは，WebアプリケーションのDD（web.xml）にクライアント性能フィルタを定義する方法について説明します。クライアント性能フィルタの定義はアプリケーションサーバの属性ファイルでも同様に実行できます。使用する属性ファイルについては，「9.3　実行環境の設定」を参照してください。

サーブレットフィルタの定義

クライアント性能フィルタをサーブレットフィルタとして定義します。DDのサーブレットフィルタの定義部分に次の指定を追加してください。

<filter>
   <filter-name>ClientPerformanceFilter</filter-name>
   <filter-class>com.hitachi.software.web.ajaxlog.filters.ClientPerformanceFilter</filter-class>
   <init-param>
   (各種設定)※
   </init-param>
</filter>

注※　表9-5で示した定義を設定できます。

フィルタマッピングの設定

サーブレットフィルタを適用するには，フィルタマッピングの指定が必要です。クライアント性能フィルタを有効にするには，DDのフィルタマッピングの定義部分に次の指定を追加してください。なお，<url-pattern>の属性値は「/*」に固定してください。

<filter-mapping>
 <filter-name>ClientPerformanceFilter</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>

ほかのサーブレットフィルタ（built-inフィルタ）との組み合わせ

アプリケーションサーバでは，クライアント性能フィルタのほかに次のbuilt-inフィルタを提供しています。

セッションフェイルオーバ用フィルタ

HTTPレスポンス圧縮フィルタ

クライアント性能フィルタは，これらのbuilt-inフィルタやほかのサーブレットフィルタと同時に適用できます。ただし，それぞれのフィルタを正しく動作させるためにサーブレットフィルタ（built-inフィルタ）の設定順序に注意が必要です。サーブレットフィルタ（built-inフィルタ）の動作条件に関する制約については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.9.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。フィルタ連鎖の推奨例については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.9.2　フィルタ連鎖の推奨例」を参照してください。

また，クライアント性能フィルタとユーザのサーブレットフィルタと組み合わせる場合は，「表9-9　クライアント性能モニタ機能適用によって挙動が変更されるWebアプリケーション」を参照してください。

9.2.3　問い合わせIDの定義方法

クライアント性能モニタ機能の問い合わせIDは，PRFのルートアプリケーション情報から次の情報を取得し，「/」を区切り文字としてつないだ文字列です。

キー情報を取得したプロセス（リダイレクタまたはインプロセスHTTPサーバを有効にしたJ2EEサーバ）が起動しているホストのIPアドレス

キー情報を取得したプロセスID

PRFトレースのI／Oプロセス（PRFデーモン）単位で割り当てられる通信番号

問い合わせIDの文字列を次に示します。

IPアドレス/プロセスID/通信番号

ルートアプリケーション情報に含まれるホストのIPアドレスをシステムの外部に公開したくない場合は，クライアント性能フィルタの初期化パラメタにidAddrNameMappingを指定します。idAddrNameMappingを指定することで，IPアドレス部分を任意の文字列に置き換えることができます。

idAddrNameMappingを指定した場合の問い合わせIDの文字列を次に示します。

IPアドレスの置き換え文字列/プロセスID/通信番号

idAddrNameMappingの指定方法について，次の図のシステム例を使用して説明します。

図9-6　システム例

ルートアプリケーション情報のIPアドレスとして取得される「192.168.11.1」と「192.168.11.2」をそれぞれ「SERVER01」と「SERVER02」に置き換えるものとします。この場合，Webアプリケーションに対して次の定義を追加してください。

<filter>
 <filter-name>ClientPerformanceFilter</filter-name>
 <filter-class>com.hitachi.software.web.ajaxlog.filters.ClientPerformanceFilter</filter-class>
 <init-param>
   <param-name>idAddrNameMapping</param-name>
   <param-value>192.168.11.1=SERVER01; 192.168.11.2=SERVER02;
   </param-value>
 </init-param>
</filter>

ルートアプリケーション情報として出力される可能性のある各IPアドレスに対して，マッピングする文字列を定義してください。複数のサーバやWebアプリケーションにクライアント性能モニタ機能を適用する場合は，この文字列とIPアドレスのマッピングの組み合わせがシステムで必ず一意になるように管理してください。

idAddrNameMappingを指定した場合の性能解析トレースとのマッチング方法

問い合わせIDの文字列を置き換えた場合，性能解析トレースと問い合わせIDをマッチングさせるには，クライアント性能フィルタの初期化パラメタidAddrNameMappingで指定した値を参照する必要があります。

9.2.4　モニタページのアクセス制御の定義方法

Webアプリケーション上の一連の操作では，モニタページから性能情報および統計情報が確認できます。これらの情報を一般のシステム利用者に対して公開したくない場合は，次のどちらかの方法でモニタページへのアクセスを制御してください。

クライアント性能モニタ機能の設定による方法

Hitachi Web Serverのアクセス制御の設定による方法

それぞれの設定方法について説明します。

＜この項の構成＞

(1)　クライアント性能モニタ機能の設定による方法

(2)　Hitachi Web Serverのアクセス制御の設定による方法

(1)　クライアント性能モニタ機能の設定による方法

クライアント性能フィルタの初期化パラメタにmonitorPageEnableLevelを指定することで，クライアント性能フィルタで生成されるモニタページの種類が変わります。これによって，モニタページが非表示になるように設定できます。この場合，性能データを表示するためにはAPI（ClientPerformance.getAllLogメソッド）を利用して，Webブラウザから性能データを読み出すアプリケーションを独自に作成してください。

性能データを読み出すためのAPI（ClientPerformance.getAllLogメソッド）だけを利用可能にする場合，monitorPageEnableLevelに次のとおりAPIを指定します。なお，次の指定例では，独自に作成したログ回収画面はコンテキストルート配下の/myMonitor.htmlに配置しているものとします。

<filter>
 <filter-name>ClientPerformanceFilter</filter-name>
 <filter-class>com.hitachi.software.web.ajaxlog.filters.ClientPerformanceFilter</filter-class>
 <init-param>
   <param-name>monitorPageEnableLevel</param-name>
   <param-value>
      API
   </param-value>
 </init-param>
 <init-param>
   <param-name>ignorePages</param-name>
   <param-value>
      /myMonitor.html
   </param-value>
 </init-param>
</filter>

(2)　Hitachi Web Serverのアクセス制御の設定による方法

Hitachi Web Serverと連携している場合，Hitachi Web Serverの設定によって，詳細なアクセス制御が実現できます。

ここでは，次に示すアクセス制御の例を実現するための定義について説明します。

アクセス制御の例

システム管理者マシンのIPアドレス（192.168.11.1）からはモニタページにアクセスできるように設定する。

システム利用者マシンのIPアドレス（192.168.11.1以外）からはモニタページにアクセスできないように設定する。

システム利用者マシンのIPアドレスからモニタページにアクセスした場合，403 Forbiddenを表示する。

独自に作成したログ回収画面（コンテキストルート配下の/myMonitor.html）はシステム管理者，システム利用者とも確認できるように設定する。なお，コンテキストルートは「/webapp/」とする。

Hitachi Web Serverのコンフィグファイルの指定例

Hitachi Web Serverのコンフィグファイルに次の指定を追加します。

<LocationMatch ^/webapp/cpmonitor_m_.*  >
   Order deny,allow
   Allow from 192.168.11.1
   Deny from all
</LocationMatch>

Allow fromに指定したIPアドレス以外からのモニタページへのアクセスを禁止します。また，モニタページに対するリクエストURLは，正規表現「^/webapp/cpmonitor_m_.*」を指定することでマッチできます。

DDの指定例

WebアプリケーションのDDでは，monitorPageEnableLevelにMonitorを指定します。

<filter>
 <filter-name>ClientPerformanceFilter</filter-name>
 <filter-class>com.hitachi.software.web.ajaxlog.filters.ClientPerformanceFilter</filter-class>
 <init-param>
   <param-name>monitorPageEnableLevel</param-name>
   <param-value>
       Monitor
   </param-value>
 </init-param>
 <init-param>
   <param-name>ignorePages</param-name>
   <param-value>
      /myMonitor.html
   </param-value>
 </init-param>
</filter>

9.2.5　DDのサンプル

クライアント性能モニタ機能が提供するDD（web.xml）のサンプルを次に示します。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
 All Rights Reserved. Copyright (C) 2008, Hitachi, Ltd.
-->

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
   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/web-app_2_4.xsd"
   version="2.4">

   <!-- The filter for Clientside Logging -->
   <filter>
     <display-name xml:lang="en">ClientPerformanceFilter</display-name>
     <filter-name>ClientPerformanceFilter</filter-name>
     <filter-class>com.hitachi.software.web.ajaxlog.filters.ClientPerformanceFilter</filter-class>
     <init-param>
       <param-name>warningThreshold</param-name>
       <param-value>(3000,3000,6000,0)</param-value>
     </init-param>
     <init-param>
       <param-name>monitorPageEnableLevel</param-name>
       <param-value>Monitor</param-value>
     </init-param>
   </filter>
   <!-- Specify the filter tags here. -->

   <!-- The filter mappings for Clientside Logging -->
   <filter-mapping>
     <filter-name>ClientPerformanceFilter</filter-name>
     <url-pattern>/*</url-pattern>
   </filter-mapping>

   <!-- Specify the filter-mapping tags here. -->

</web-app>

9.2.6　Webブラウザから性能データを読み出すアプリケーションの作成

クライアント性能モニタ機能では，Webブラウザ上に保存された性能データをサーバ側で収集できます。この機能を使用するために，次のAPIおよびサンプルを提供しています。

性能データを読み出すためのAPI（ClientPerformance.getAllLogメソッド）

APIを使用して性能データを読み出すサンプルプログラム（ログ一括送信画面（サンプル））

性能データを受け取る側のサンプルサーブレット（ログ一括受信アプリケーション（サンプル））

クライアント性能モニタ機能が提供しているAPIおよびサンプルの詳細を次の表に示します。

表9-6　クライアント性能モニタ機能が提供しているAPIおよびサンプル

項番
APIおよびサンプル
機能

1
ClientPerformance.getAllLogメソッド
ClientPerformance.getAllLogメソッドはJavaScriptのAPIです。Webブラウザ上に保存されている性能データをJavaScriptの配列として参照可能にします。参照できる性能データは，モニタページで表示できるすべての性能データです。次に示す性能データはモニタページに表示されないため，参照できません。

すでに削除されている性能データ

有効期限が切れている性能データ

API（ClientPerformance.getAllLogメソッド）の詳細は，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「7.2　ClientPerformance.getAllLogメソッド」を参照してください。

2
ログ一括送信画面（サンプル）（SendAllDataSample.html）
性能データを読み出すためのサンプル画面です。
項番1のClientPerformance.getAllLogメソッドの機能を使用して，Webブラウザのuser Data領域に保存されているすべての性能データをサーバに送信します。

3
ログ一括受信アプリケーション（サンプル）
（ReceiveAllDataSampleServlet）
性能データを受け取る側のサンプルサーブレットです。
ログ一括送信画面から送信されたすべての性能データをCSV形式で表示します。ログシーケンスごとに線で区切られて表示されます。

サンプルは，クライアント性能フィルタの設定を変えることで動作させられます。アプリケーションを作成するための参考にしてください。サンプルの格納場所については，「9.1.6　クライアント性能モニタのディレクトリ構成」を参照してください。

次に，サンプル画面を使用して性能データを正しく呼び出す方法について説明します。

＜この項の構成＞

(1)　性能データを読み出すためのサンプルソース

(2)　サンプル画面を動作させる手順

(1)　性能データを読み出すためのサンプルソース

性能データを読み出すためのサンプルソースを次の図に示します。なお，サンプルソース中の数字は説明文の項番と対応しています。

図9-7　性能データを読み出すためのサンプルソース

サンプルソースの動作を次に示します。

IFRAMEタグで，APIを含むHTMLファイルcpmonitor_a_LoadAllUserData.htmlをロードします。
クライアント性能フィルタが動作しているWebアプリケーションのcpmonitor_a_LoadAllUserData.htmlに対してリクエストを送信することで，性能データを読み出すAPIを含むHTMLファイルを呼び出します。性能データを表示するモニタページを自作する場合は，IFRAMEタグを使ってcpmonitorページを呼び出します。このとき，上記のHTMLファイルの内容を表示させる必要はないので，IFRAMEのborder属性，width属性およびheight属性には0を指定します。

IFRAMEのonLoadイベントに，性能データを読み出す関数を登録します。
IFRAMEの内容を読み終えたとき，onLoadイベントが発行されます。onLoadイベントが発生されたときに，性能データを読み出す関数が呼ばれるように設定します。

性能データを読み出すAPIを実行します。
onLoadイベントが発生した場合に呼ばれる関数の内部で，性能データを読み出すAPIをIFRAME経由で実行します。

APIの戻り値を確認し，性能データを送信します。
戻り値がnullでないことを確認して，必要な変数や属性などに値を格納します。

注意

サンプルは直接編集しないでください。サンプルソースコードは参照するために提供しています。編集する場合は必ずコピーしたものを修正してください。

このサンプルでは，［SendAll］ボタンがクリックされたときに性能データの読み込みが完了しているかどうかがチェックされます。実際の送信アプリケーションでも，サンプルと同様に読み込み処理が完了するまでは送信ボタンがクリックされないように設計してください。

APIは，APIを含むHTMLファイルcpmonitor_a_LoadAllUserData.htmlをロードしているIFRAMEのonLoadイベントが発生したあとで実行してください。IFRAMEのonLoadイベントの発生が確認されたあとであれば，APIをIFRAMEのonLoadイベント内で実行する必要はありません。

IFRAMEのロードが完了し，APIを実行できる状態かどうかは，次に示すコードで確認できます。なお，コード内のloadAllUserDataには，cpmonitor_a_LoadAllUserData.htmlをロードしているIFRAMEのname属性の値を指定してください。

if(  typeof loadAllUserData != "undefined" &&
    typeof loadAllUserData.ClientPerformance != "undefined" &&
    typeof loadAllUserData.ClientPerformance.getAllLog == "function"){
 /* loadAllUserData.ClientPerformance.getAllLog()は実行可能 */
}
else{
 /* loadAllUserData.ClientPerformance.getAllLog()は実行不可能 */
}

(2)　サンプル画面を動作させる手順

サンプル画面を実際に動作させたい場合は，クライアント性能フィルタの初期化パラメタmonitorPageEnableLevelにTestを指定してください。ただし，Testはテスト環境だけで指定できます。実際に運用を開始する場合は，必ずMonitorまたはAPIを指定してください。

サンプル画面を動作させるには，WebブラウザからURL「<Webアプリケーションのコンテキストルート>/SendAllDataSample.html」にアクセスします。<Webアプリケーションのコンテキストルート>にはコンテキストルートのパスを指定してください。

次に示すログ一括送信画面（サンプル）が表示されます。

図9-8　性能データを読み出すためのログ一括送信画面（サンプル）

サンプルでは，［SendAll］ボタンをクリックすると性能データがサーバのアプリケーションに送信されるように実装されています。

送信された性能データをログ一括受信アプリケーション（サンプル）によってサーバ側で受信します。受信した結果を表示した画面を次に示します。

図9-9　サンプルによってサーバ側で性能データを受信した結果

9.2.7　クライアント性能測定スクリプトの挿入条件

クライアント性能測定スクリプトは，Webアプリケーションでの静的コンテンツ，JSP，またはサーブレットが生成したコンテンツに対して，自動的に挿入されます。

クライアント性能測定スクリプトが挿入できる条件を次の表に示します。

表9-7　クライアント性能測定スクリプトの挿入条件

項番
項目
条件

1
クライアント性能フィルタが受け取るServletRequest，ServletResponseの種類
クライアント性能フィルタのdoFilter()メソッドの引数がHttpServletRequest，またはHttpServletResponseのインスタンスである場合。

2
対象のコンテンツ

クライアント性能フィルタが動作したときのContent-Typeの値がtext/htmlである場合。

クライアント性能フィルタが動作したときのContent-Encodingヘッダの値が未設定またはidentityだけ指定されている場合。

3
ステータスコード
サーブレットやあとのフィルタから渡されたレスポンスのステータスコードが200である場合。

4
リクエストメソッド
リクエストメソッドがGET，またはPOSTである場合。

5
適用されるHTMLの制限
コンテンツの先頭からクライアント性能モニタ機能の設定filterSizeで指定したサイズ（デフォルトは8キロバイト）までの範囲で，次のどちらかの条件を満たしている場合。

<HEAD>，</HEAD>，<BODY>の順でそれぞれのHTMLタグを含む。

<HEAD>，</HEAD>，<FRAMESET>の順でそれぞれのHTMLタグを含む。
この場合，コンテンツの先頭から検索していちばん最初の<FRAMESET>タグの属性は，「cols=」または「rows=」の一方だけが指定されている必要があります。なお，この属性値は次のどれかの方法で指定してください。
・ダブルクォーテーションで囲む（"～"）
・シングルクォーテーションで囲む（'～'）
・囲まない（～）
例
<frameset rows="50%,50%"> <frameset cols=50,*>

どちらの条件も満たしていない場合は，クライアント性能測定スクリプトは挿入されないことがあります。

6
出力ストリームのflush()
出力ストリームのバッファが最初にflush()されるタイミングで，「適用されるHTMLの制限」の条件を満たすデータが出力ストリームに書き込まれている場合。
出力ストリームのバッファが最初にflush()されるタイミングで，「適用されるHTMLの制限」の条件がチェックされます。このとき，「適用されるHTMLの制限」の条件を満たすデータが，出力ストリームに書き込まれていない場合は，クライアント性能測定スクリプトは挿入されません。

7
クライアント性能モニタの適用に関する設定
リクエストURLのパスがクライアント性能フィルタの初期化パラメタignorePagesで指定したパスにマッチしない場合。
リクエストURLのパスがクライアント性能フィルタの初期化パラメタignorePagesで指定したパスにマッチする場合は，クライアント性能測定スクリプトは挿入されません。

8
ブラウザの種類
User-Agentの情報として，Internet Explorerのバージョンが6以上であることが判別できる場合。

9
クライアント性能フィルタが受け取るServletResponseの状態
クライアント性能フィルタのdoFilter()メソッドが呼ばれた時点でクライアント性能フィルタが受け取るServletResponseがコミットされていない場合。
クライアント性能フィルタのdoFilter()メソッドが呼ばれた時点で，すでにクライアント性能フィルタが受け取るServletResponseがコミットされている場合は，クライアント性能測定スクリプトは挿入されません。

10
サーブレットパス
クライアント性能フィルタが動作した際，javax.servlet.ServletResponseのgetServletPathメソッドで得られるサーブレットパスが「/」で始まる文字列の場合。
サーブレットパスが「/」で始まらない文字列（空文字列など）の場合，クライアント性能測定スクリプトは挿入されません。

9.3　実行環境の設定

この節では，実行環境の設定について説明します。

＜この節の構成＞

9.3.1　サーバ側の設定

9.3.2　ブラウザ側の設定

9.3.1　サーバ側の設定

DDで定義したクライアント性能モニタの設定は，実行環境で変更できます。

実行環境でのJ2EEアプリケーションの設定は属性ファイルで実施します。クライアント性能モニタ機能の定義には，アプリケーション統合属性ファイル，WAR属性ファイルおよびフィルタ属性ファイルを使用します。各設定ファイルについては，「9.2.2　クライアント性能フィルタの定義方法」を参照してください。

なお，各設定ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「9.2.1　DDでの定義」を参照してください。

9.3.2　ブラウザ側の設定

クライアント性能モニタ機能を動作させるためにWebブラウザに必要な設定について説明します。

＜この項の構成＞

(1)　Internet Explorerの設定

(2)　Cookieの設定

(1)　Internet Explorerの設定

クライアント性能モニタ機能を動作させるためには，Internet ExplorerのWebコンテンツゾーンに対するセキュリティレベルを「高」以外に設定する必要があります。クライアント性能モニタ機能を適用したWebアプリケーションがWebブラウザからどのゾーンに認識されるかは，Internet Explorerのドキュメントで確認してください。

注意事項

次に示すOSのデフォルト設定の場合，セキュリティゾーンが制限付きサイトのときは，クライアント性能モニタ機能は正しく動作しません。
・Windows XP
・Windows Vista
・Windows 7

次に示すOSの場合，デフォルト設定ではInternet ExplorerにWidnows Serverの機能である「セキュリティ強化の構成」が適用されています。
・Windows Server 2003
・Windows Server 2003 R2
・Windows Server 2003（x64）
・Windows Server 2003 R2（x64）
・Windows Server 2008 x86
・Windows Server 2008 x64
・Windows Server 2008 R2
この場合，インターネットゾーンのセキュリティレベルが「高」になるため，クライアント性能モニタ機能は正しく動作しません。正常に動作させるには，セキュリティ強化の構成に関する設定（セキュリティ強化の構成の無効化，信頼済みサイトゾーンへのサイトの追加など）を変更する必要があります。変更手順については，各製品のドキュメントを参照してください。

Internet Explorerのセキュリティレベルをカスタマイズしている場合は，セキュリティの設定に次の表に示す設定をしてください。

表9-8　Internet Explorerの設定

項番 | 設定項目 | 設定値
1 | アクティブスクリプト | 「有効にする」
2 | バイナリ ビヘイビアとスクリプト ビヘイビア※ | 「有効にする」
3 | User Dataの常設 | 「有効にする」

注※

Windowsのサービスパックの適用状況などによって，設定項目がない場合があります。その場合は設定する必要はありません。

(2)　Cookieの設定

対象のWebアプリケーションに対して，Cookieを受け入れるようにInternet Explorerで設定してください。Cookieの設定方法については，Internet Explorerのドキュメントを参照してください。

9.4　クライアント性能モニタ機能の運用

この節では，モニタページを表示して，保存された性能データを確認，および分析する方法について説明します。

モニタページを使用する場合は，クライアント性能フィルタの初期化パラメタmonitorPageEnableLevelでモニタページを表示できるように指定しておいてください。詳細は，「9.2.1　DDでの定義」および「9.2.4　モニタページのアクセス制御の定義方法」を参照してください。

＜この節の構成＞

9.4.1　モニタページの画面構成

9.4.2　モニタページを表示する

9.4.3　性能情報を表示する

9.4.4　統計情報を表示する

9.4.5　性能データを削除する

9.4.1　モニタページの画面構成

モニタページの画面構成を次に示します。

図9-10　モニタページの構成

モニタページを構成する要素を次に示します。

ヘッダ，フッタ
ヘッダおよびフッタは常に表示されます。

中フレーム
モニタページ表示部分（右フレーム）とログシーケンス一覧（左フレーム）を合わせて中フレームと呼びます。

モニタページ表示部分（右フレーム）
性能データが表示されます。

ログシーケンス一覧（左フレーム）
ログシーケンスの一覧が表示されます。ログシーケンス一覧は常に表示されます。

モニタページに表示される性能データの背景色が持つ意味を次に示します。

赤色
警告を示します。異常値が検出された場合は，該当する性能データの背景色が赤色で表示されます。

黄色
一覧の各行の上にカーソルを移動させると背景色が黄色で表示されます。

水色
選択されていることを示します。

9.4.2　モニタページを表示する

モニタページを表示する手順を次に示します。

WebブラウザからURL「<Webアプリケーションのコンテキストルート>/cpmonitor_m_index.html」にアクセスします。
<Webアプリケーションのコンテキストルート>には，コンテキストルートのパスを指定してください。モニタページのトップ画面が表示されます。トップ画面には，最新のログシーケンスの性能情報が表示されます。

トップ画面から次の操作が実行できます。操作手順については，それぞれの参照先を参照してください。

性能情報の表示（「9.4.3　性能情報を表示する」）

統計情報の表示（「9.4.4　統計情報を表示する」）

性能データの削除（「9.4.5　性能データを削除する」）

9.4.3　性能情報を表示する

性能情報を表示する方法を次に示します。

最新性能情報を表示する（トップ画面）

選択したログシーケンスの性能情報を表示する

それぞれの表示方法について説明します。なお，画面の項目については，「(3)　性能情報の表示で使用する画面」を参照してください。

＜この項の構成＞

(1)　最新性能情報を表示する

(2)　選択したログシーケンスの性能情報を表示する

(3)　性能情報の表示で使用する画面

(4)　フレーム構成のWebブラウザを操作した場合の性能情報を確認する

(1)　最新性能情報を表示する

最新性能情報を表示する手順を次に示します。

モニタページを表示します。
モニタページの表示については，「9.4.2　モニタページを表示する」を参照してください。最新のログシーケンスの性能情報がトップ画面に表示されます。

(2)　選択したログシーケンスの性能情報を表示する

選択したログシーケンスの性能情報を表示する手順を次に示します。

［ログシーケンス一覧］画面で，性能情報を表示させたいログシーケンスを一つクリックします。
選択したログシーケンスの性能情報がモニタページの表示部分に表示されます。なお，左フレームのログシーケンス一覧では，選択したログシーケンスの行が水色で表示されます。

(3)　性能情報の表示で使用する画面

性能情報の表示で使用する画面について説明します。

(a)　［ログシーケンス一覧］画面

［ログシーケンス一覧］画面を次に示します。

図9-11　［ログシーケンス一覧］画面

［ログシーケンス一覧］画面の項目およびメニューについて説明します。

［最新情報］

中フレームの情報を最新の状態に更新します。［最新情報］をクリックすると，ログシーケンスを選択している場合でも選択が解除され，最新性能情報が表示されます。

［一括削除］

Webブラウザのuser Data領域に記録されているログシーケンスの性能データをすべて削除します。一括削除の詳細は，「9.4.5(1)　一括ですべての性能データを削除する」を参照してください。

ログシーケンスの一覧

ログシーケンスの一覧が表示されます。ログシーケンスを選択している場合，選択しているログシーケンスの行が水色で表示されます。

#

行番号が表示されます。

更新時刻

各ログシーケンスの最新ページがロードされた時刻が表示されます。

ログシーケンス内最新URL

各ログシーケンスの最新ページのURLが表示されます。ここではファイル名だけが表示されます。ファイル名の文字数は，クライアント性能フィルタの初期化パラメタurlMaxLengthに指定した値以下で表示されます。指定値を超える文字列は表示されません。また，クエリーは表示されません。

(b)　［性能情報］画面

［性能情報］画面を次に示します。

なお，フレーム構成のWebブラウザを表示した場合，性能情報の表示形式が通常の場合と異なります。詳細は，「(4)　フレーム構成のWebブラウザを操作した場合の性能情報を確認する」を参照してください。

図9-12　［性能情報］画面

［性能情報］画面の項目およびメニューについて説明します。

最新性能情報を表示している場合
最後に更新されたログシーケンスの性能情報が表示されます。

ログシーケンスを選択している場合
該当するログシーケンスの性能情報が表示されます。

画面に表示されるメニューおよび項目について説明します。

コンテキストルート

Webアプリケーションのコンテキストルートが表示されます。ここで表示されるコンテキストルートは，Webブラウザから見た場合のパスです。

先頭問い合わせID

ログシーケンスの先頭データの問い合わせIDが表示されます。性能データがない場合，先頭問い合わせIDにはno dataと表示されます。

［性能情報］

この画面では選択できません。

［統計情報］

次に示す［統計情報］画面が表示されます。

最新性能情報を表示している場合
最新のログシーケンスの［統計情報］画面

選択したログシーケンスの性能情報を表示している場合
選択したログシーケンスの［統計情報］画面

［統計情報］画面については，「9.4.4(3)　統計情報の表示で使用する画面」を参照してください。

［データ削除］

次に示す［データ削除］画面が表示されます。

最新性能情報を表示している場合
最新のログシーケンスの［データ削除］画面

選択したログシーケンスの性能情報を表示している場合
選択したログシーケンスの［データ削除］画面

性能データの削除については，「9.4.5(2)　最新のログシーケンスの性能データを削除する」または「9.4.5(3)　選択したログシーケンスの性能データを削除する」を参照してください。

性能情報

最後に更新されたログシーケンス，または選択したログシーケンスの性能情報の一覧が表示されます。一覧は時刻の新しい順にソートされます。

#

行番号が表示されます。

時刻

ロードされた時刻がhh:mm:ss.nnn（hh：時，mm：分，ss：秒，nnn：ミリ秒）形式で表示されます。

URL

該当するページのURLが表示されます。表示対象のWebアプリケーションのコンテキストルートを「/」として，ディレクトリとファイル名が表示されます。ファイル名の文字数は，クライアント性能フィルタの初期化パラメタurlMaxLengthに指定した値以下で表示されます。指定値を超える文字列は表示されません。また，クエリーは表示されません。

応答性能

応答性能（通信時間，描画時間，および応答時間）が表示されます。

通信(ms)
通信時間が表示されます。単位はミリ秒です。

描画(ms)
描画時間が表示されます。単位はミリ秒です。

合計(ms)
応答時間（通信時間＋描画時間）が表示されます。単位はミリ秒です。

操作(ms)

操作時間が表示されます。単位はミリ秒です。

問い合わせID

問い合わせIDが表示されます。

なお，次に示す値のように表示できない性能情報がある場合は，数値が「－」と表示されます。

初回アクセス時の通信時間

操作中の操作時間

イベントデータに障害が発生した場合の性能情報

性能情報の計算結果が不正な値（負の値など）

また，クライアント性能フィルタの設定で各性能数値にしきい値を設定した場合，しきい値を超えた異常値が検出されると，該当するセルが赤く反転表示されます。

異常値が検出された画面の例を次に示します。

図9-13　異常値が検出された画面の例（性能情報）

(4)　フレーム構成のWebブラウザを操作した場合の性能情報を確認する

フレーム構成のWebブラウザを操作した場合，性能情報の表示形式が通常の場合と異なります。画面遷移の例に沿って，性能情報がどのように表示されるかを説明します。

フレーム構成のWebブラウザを表示した場合の性能情報を次に示します。

図9-14　フレーム構成のWebブラウザを表示した場合の性能情報

フレーム構成のWebブラウザを表示した場合，次の性能情報の表示が通常の場合と異なります。

#

性能情報の行番号が表示される#には，「.」で区切られた番号が表示されます。

「.」の区切りがフレームの階層を示しています。左から2番目以降の番号は，同じ階層内にある子フレームの単位で分けられます。同じ数字が並んでいる場合は，同じフレームの中で画面が遷移していることを示します。

性能情報の一覧はフレームの階層単位で表示され，新しい情報が上部に表示されます。

時刻

性能情報の表示順序はフレーム単位でまとめられています。このため，一覧の表示は時刻の新しい順ではありません。

URL

フレームの階層を表す記号として「> 」が表示されます。子フレームのURLの先頭に，フレームの階層の数だけ「> 」が並んで表示されます。

画面遷移と性能情報の表示例を次に示します。

(a)　子フレームとしてleft.htmlとright.htmlを持つWebブラウザを表示した場合

sample.htmlの子フレームとしてleft.htmlとright.htmlを持つWebブラウザを表示した場合の画面および性能情報の例を次に示します。なお，図中の数字は，説明の番号と対応しています。

図9-15　子フレームとしてleft.htmlとright.htmlを持つWebブラウザを表示した場合の例

説明

#のいちばん左の番号1は，sample.htmlのフレームの階層であることを示します。

#の1.2はsample.htmlの子フレームright.htmlの情報であることを示します。

#の1.1はsample.htmlの子フレームleft.htmlの情報であることを示します。

(b)　子フレームのleft.htmlのリンクをクリックしてleft.htmlがleft2.htmlに遷移した場合

子フレームleft.htmlの表示が同じフレーム内で遷移してleft2.htmlとなった場合の画面および性能情報の例を次に示します。なお，図中の数字は，説明の番号と対応しています。

図9-16　子フレームのleft.htmlのリンクをクリックしてleft.htmlがleft2.htmlに遷移した場合の例

説明

2行目と3行目の#の番号が同じ1.1であることから，同じフレーム内での遷移であることがわかります。

上から2行目の性能情報がleft.htmlからleft2.htmlへの遷移を示します。

(c)　子フレームのright.htmlのリンクをクリックして，right.htmlがsample2.html（sample2.htmlは，子フレームとしてleft.htmlとright.htmlを持つ）に遷移した場合

子フレームright.htmlが遷移し，さらに二つの子フレーム（left.htmlおよびright.html）を表示した場合の画面および性能情報の例を次に示します。なお，図中の数字は，説明の番号と対応しています。

図9-17　子フレームright.htmlが遷移し，さらに二つの子フレーム（left.htmlおよびright.html）を表示した場合の例

説明

上から4行目のsample2.htmlはいちばん下の行のright.htmlが遷移した画面であることを示します。これは，#の番号が同じであることからわかります。

#1.2.1のleft.htmlと#1.2.2のright.htmlは，sample2.htmlの子フレームであることを示します。

(d)　フレーム全体が更新された場合

「(c)　子フレームのright.htmlのリンクをクリックして，right.htmlがsample2.html（sample2.htmlは，子フレームとしてleft.htmlとright.htmlを持つ）に遷移した場合」の画面が更新された場合の性能情報の例を次に示します。なお，図中の数字は，説明の番号と対応しています。

図9-18　フレーム全体が更新された場合の例

説明

更新前までの画面遷移の情報は，#の番号が2として表示されます。

更新された画面の情報は，#の番号が1として表示されます。

9.4.4　統計情報を表示する

統計情報を表示する方法を次に示します。

最新統計情報を表示する

選択したログシーケンスの統計情報を表示する

それぞれの表示方法について説明します。なお，画面の項目については，「(3)　統計情報の表示で使用する画面」を参照してください。

＜この項の構成＞

(1)　最新統計情報を表示する

(2)　選択したログシーケンスの統計情報を表示する

(3)　統計情報の表示で使用する画面

(1)　最新統計情報を表示する

最新統計情報を表示する手順を次に示します。

最新性能情報を表示します。
最新性能情報の表示については，「9.4.3(1)　最新性能情報を表示する」を参照してください。

［性能情報］画面の［統計情報］をクリックします。
［統計情報］画面が表示されます。［統計情報］画面には，最新のログシーケンスの統計情報が表示されます。

(2)　選択したログシーケンスの統計情報を表示する

選択したログシーケンスの統計情報を表示する手順を次に示します。

最新性能情報を表示します。
最新性能情報の表示については，「9.4.3(1)　最新性能情報を表示する」を参照してください。

［ログシーケンス一覧］画面で，統計情報を表示したいログシーケンスを一つクリックします。
選択したログシーケンスの性能情報がモニタページの表示部分に表示されます。

［性能情報］画面の［統計情報］をクリックします。
選択したログシーケンスの統計情報が［統計情報］画面に表示されます。なお，左フレームのログシーケンス一覧では，選択したログシーケンスの行が水色で表示されます。

(3)　統計情報の表示で使用する画面

統計情報の表示で使用する画面について説明します。

(a)　［ログシーケンス一覧］画面

［ログシーケンス一覧］画面については，「9.4.3(3)(a)　［ログシーケンス一覧］画面」を参照してください。

(b)　［統計情報］画面

［統計情報］画面を次に示します。

図9-19　［統計情報］画面

［統計情報］画面の項目およびメニューについて説明します。

最新統計情報を表示している場合
最後に更新されたログシーケンスの統計情報が表示されます。

ログシーケンスを選択している場合
該当するログシーケンスの統計情報が表示されます。

画面に表示されるメニューおよび項目について説明します。

コンテキストルート

Webアプリケーションのコンテキストルートが表示されます。ここで表示されるコンテキストルートは，Webブラウザから見た場合のパスです。

先頭問い合わせID

ログシーケンスの先頭データの問い合わせIDが表示されます。性能データがない場合，先頭問い合わせIDにはno dataと表示されます。

［性能情報］

次の［性能情報］画面が表示されます。

最新統計情報を表示している場合
最新のログシーケンスの［性能情報］画面

選択したログシーケンスの統計情報を表示している場合
選択したログシーケンスの［性能情報］画面

［性能情報］画面については，「9.4.3(3)(b)　［性能情報］画面」を参照してください。

［統計情報］

この画面では選択できません。

［データ削除］

次に示す［データ削除］画面が表示されます。

最新統計情報を表示している場合
最新のログシーケンスの［データ削除］画面

選択したログシーケンスの統計情報を表示している場合
選択したログシーケンスの［データ削除］画面

性能データの削除については，「9.4.5(2)　最新のログシーケンスの性能データを削除する」または「9.4.5(3)　選択したログシーケンスの性能データを削除する」を参照してください。

統計情報

最後に更新されたログシーケンス，または選択したログシーケンスの統計情報の一覧が表示されます。一覧は回数の降順でソートされます。

#

行番号が表示されます。

URL

該当するURLが表示されます。表示対象のWebアプリケーションのコンテキストルートを「/」として，ディレクトリとファイル名が表示されます。ファイル名の文字数は，クライアント性能フィルタの初期化パラメタurlMaxLengthに指定した値以下で表示されます。指定値を超える文字列は表示されません。また，クエリーは表示されません。

回数

表示されているログシーケンス内で該当するURLにアクセスした回数が表示されます。

応答性能

応答性能（通信時間，描画時間，および応答時間）の統計情報が表示されます。

通信(ms)
通信時間の統計情報が表示されます。単位はミリ秒です。
Max：通信時間の最大値が表示されます。
Min：通信時間の最小値が表示されます。
Ave：通信時間の平均値が表示されます。

描画(ms)
描画時間の統計情報が表示されます。単位はミリ秒です。
Max：描画時間の最大値が表示されます。
Min：描画時間の最小値が表示されます。
Ave：描画時間の平均値が表示されます。

合計(ms)
応答時間（通信時間＋描画時間）の統計情報が表示されます。単位はミリ秒です。
Max：応答時間の最大値が表示されます。
Min：応答時間の最小値が表示されます。
Ave：応答時間の平均値が表示されます。

操作(ms)

操作時間の統計情報が表示されます。単位はミリ秒です。

Max：操作時間の最大値が表示されます。

Min：操作時間の最小値が表示されます。

Ave：操作時間の平均値が表示されます。

なお，次に示す値のように表示できない性能情報は統計の計算には含まれません。

初回アクセス時の通信時間

操作中の操作時間

イベントデータに障害が発生した場合

表示できない統計情報がある場合は，数値が「－」と表示されます。

また，最新URLの行は背景色が水色で表示されます。クライアント性能フィルタの設定で各性能数値にしきい値を設定した場合，しきい値を超えた異常値が検出されると，該当するセルが赤く反転表示されます。

異常値が検出された画面の例を次に示します。

図9-20　異常値が検出された画面の例（統計情報）

9.4.5　性能データを削除する

性能データの削除方法には，一括で削除する方法と部分的に削除する方法があります。

一括削除

一括ですべての性能データを削除する

部分削除

最新のログシーケンスの性能データを削除する

選択したログシーケンスの性能データを削除する

それぞれの削除方法について説明します。なお，画面の項目については，「(4)　性能データの削除で使用する画面」を参照してください。

＜この項の構成＞

(1)　一括ですべての性能データを削除する

(2)　最新のログシーケンスの性能データを削除する

(3)　選択したログシーケンスの性能データを削除する

(4)　性能データの削除で使用する画面

(1)　一括ですべての性能データを削除する

一括ですべての性能データを削除する手順を次に示します。

［ログシーケンス一覧］画面の［一括削除］をクリックします。
一括削除を確認するダイアログが表示されます。一括削除をキャンセルする場合は，［キャンセル］ボタンをクリックすると元の画面に戻ります。

［OK］ボタンをクリックします。
すべての性能データが削除されます。一括削除が完了すると，完了を示すダイアログが表示されます。

［OK］ボタンをクリックして，ダイアログを閉じます。
元の画面の中フレーム全体が更新されて表示されます。
左フレームには最新のログシーケンス一覧が表示され，右フレームには最新性能情報が表示されます。

(2)　最新のログシーケンスの性能データを削除する

最新のログシーケンスの性能データを削除する手順を次に示します。このとき，ログシーケンス内の情報のうち，選択した性能データおよびそれよりも古い情報はすべて削除されます。

最新の［性能情報］画面または［統計情報］画面を表示します。
［性能情報］画面の表示については「9.4.3(1)　最新性能情報を表示する」を，［統計情報］画面の表示については「9.4.4(1)　最新統計情報を表示する」を参照してください。

［データ削除］をクリックします。
［データ削除］画面が表示されます。［データ削除］画面には，最後に更新されたログシーケンスの性能データの情報が表示されます。

削除したい性能データの行を選択します。
マウスポインタを移動させると行が黄色に変化します。

黄色に変化した行をクリックします。
削除を確認するダイアログが表示されます。

［OK］ボタンをクリックします。
選択した性能データおよびそれより古い性能データがすべて削除されます。
削除をキャンセルする場合は，［キャンセル］ボタンをクリックすると元の画面に戻ります。
子フレームの性能データを削除した場合，子フレーム内の選択したデータにつながる一連の性能データだけが削除されます。

なお，Webブラウザで開いている最中の性能データを削除しようとした場合，性能データの削除に失敗します。その場合は，性能データの削除の失敗を示すダイアログが表示されます。

図9-21　性能データの削除の失敗を示すダイアログ

ダイアログには，削除に失敗した性能データの問い合わせIDが表示されます。

(3)　選択したログシーケンスの性能データを削除する

選択したログシーケンスの性能データを削除する手順を次に示します。このとき，ログシーケンス内の情報のうち，選択した性能データおよびそれよりも古い情報はすべて削除されます。

最新性能情報を表示します。
最新性能情報の表示については，「9.4.3(1)　最新性能情報を表示する」を参照してください。

［ログシーケンス一覧］画面で，性能データを削除したいログシーケンスを一つクリックします。
選択したログシーケンスの性能情報がモニタページの表示部分に表示されます。

［性能情報］画面の［データ削除］をクリックします。
［データ削除］画面が表示されます。［データ削除］画面には，選択したログシーケンスの性能データの情報が表示されます。

削除したい性能データの行を選択します。
マウスポインタを移動させると行が黄色に変化します。

黄色に変化した行をクリックします。
削除を確認するダイアログが表示されます。

［OK］ボタンをクリックします。
選択した性能データおよびそれより古い性能データがすべて削除されます。
削除をキャンセルする場合は，［キャンセル］ボタンをクリックすると元の画面に戻ります。
子フレームの性能データを削除した場合，子フレーム内の選択したデータにつながる一連の性能データだけが削除されます。

なお，Webブラウザで開いている最中の性能データを削除しようとした場合，性能データの削除に失敗します。その場合は，性能データの削除の失敗を示すダイアログが表示されます。

図9-22　性能データの削除の失敗を示すダイアログ

ダイアログには，削除に失敗した性能データの問い合わせIDが表示されます。

(4)　性能データの削除で使用する画面

性能データの削除で使用する画面について説明します。

(a)　［ログシーケンス一覧］画面

［ログシーケンス一覧］画面については，「9.4.3(3)(a)　［ログシーケンス一覧］画面」を参照してください。

(b)　［データ削除］画面

［データ削除］画面を次に示します。

図9-23　［データ削除］画面

［データ削除］画面の項目およびメニューについて説明します。

最新情報を表示している場合
最後に更新されたログシーケンスの性能データの情報が表示されます。

ログシーケンスを選択している場合
該当するログシーケンスの性能データの情報が表示されます。

画面に表示されるメニューおよび項目について説明します。

コンテキストルート

Webアプリケーションのコンテキストルートが表示されます。ここで表示されるコンテキストルートは，Webブラウザから見た場合のパスです。

先頭問い合わせID

ログシーケンスの先頭データの問い合わせIDが表示されます。性能データがない場合，先頭問い合わせIDにはno dataと表示されます。

［性能情報］

次の［性能情報］画面が表示されます。

最新のログシーケンスの性能データの情報を表示している場合
最新のログシーケンスの［性能情報］画面

選択したログシーケンスの性能データの情報を表示している場合
選択したログシーケンスの［性能情報］画面

［性能情報］画面については，「9.4.3(3)(b)　［性能情報］画面」を参照してください。

［統計情報］

次の［統計情報］画面が表示されます。

最新のログシーケンスの性能データの情報を表示している場合
最新のログシーケンスの［統計情報］画面

選択したログシーケンスの性能データの情報を表示している場合
選択したログシーケンスの［統計情報］画面

［統計情報］画面については，「9.4.4(3)(b)　［統計情報］画面」を参照してください。

［データ削除］

この画面では選択できません。

性能データの情報

最後に更新されたログシーケンス，または選択したログシーケンスの性能データの一覧が表示されます。一覧は時刻の新しい順でソートされます。

#

行番号が表示されます。

時刻

ロードされた時刻がhh:mm:ss.nnn（hh：時，mm：分，ss：秒，nnn：ミリ秒）形式で表示されます。

URL

該当するURLが表示されます。表示対象のWebアプリケーションのコンテキストルートを「/」として，ディレクトリとファイル名が表示されます。ファイル名の文字数は，クライアント性能フィルタの初期化パラメタurlMaxLengthに指定した値以下で表示されます。指定値を超える文字列は表示されません。また，クエリーは表示されません。

問い合わせID

問い合わせIDが表示されます。

9.5　クライアント性能モニタ機能についての注意事項

この節では，クライアント性能モニタ機能運用時の注意事項およびモニタページに関する注意事項について説明します。

＜この節の構成＞

9.5.1　クライアント性能モニタ機能運用時の注意事項

9.5.2　モニタページに関する注意事項

9.5.1　クライアント性能モニタ機能運用時の注意事項

クライアント性能モニタ機能運用時の注意事項を次に示します。

＜この項の構成＞

(1)　適用時の注意事項

(2)　複数のWebアプリケーションに対する同時適用についての注意事項

(3)　user Dataビヘイビアのデータサイズについての注意事項

(4)　問い合わせIDに含まれるIPアドレス情報についての注意事項

(5)　コンテンツ出力時の文字セットについての注意事項

(6)　Webアプリケーション中の変数についての注意事項

(7)　クライアント性能モニタ機能で予約されているファイル名に関する注意事項

(8)　Webブラウザの中止ボタンについての注意事項

(9)　Webブラウザの並行操作に関する注意事項

(10)　フレーム構成のWebブラウザの性能データに関する注意事項

(11)　測定対象のHTMLコンテンツについての注意事項

(1)　適用時の注意事項

すでに運用実績があるWebアプリケーションに対してクライアント性能モニタ機能を適用する場合，Webブラウザの設定によっては不正な値が表示されることがあります。これは，クライアント性能測定スクリプトが適用されていないWebブラウザおよびキャッシュサーバ上のキャッシュに保存されているコンテンツがそのまま表示されるためです。この場合，次の対策を実行してください。

Webブラウザおよびキャッシュサーバ上のキャッシュデータを削除してください。

Webブラウザでコンテンツを更新してください。

なお，具体的な操作方法については，Webブラウザおよびキャッシュサーバのドキュメントを参照してください。

クライアント性能モニタ機能を適用すると，次の表に示すWebアプリケーションの挙動が変更されます。機能を適用する前に，これらの挙動の変更に問題がないか確認してください。

表9-9　クライアント性能モニタ機能適用によって挙動が変更されるWebアプリケーション

項番
項目
説明

1
通信量の増加

クライアント性能測定スクリプトの挿入によって，サーバからクライアントに送信される通信量が増加します。初回のリクエストで50キロバイト程度増加します。ただし，通常，一部のデータはブラウザにキャッシュされるので，増加するデータ量は50キロバイトより小さくなります。

クライアント性能測定スクリプトを挿入した場合，スクリプトの本体を呼び出すためのリクエストなどが数回発行されます。ただし，この結果は通常ブラウザにキャッシュされるため，発行される回数は減少していきます。

「コンテンツのキャッシュ制御」の影響によって，クライアント性能測定スクリプトが挿入されたHTMLコンテンツはキャッシュされなくなります。その結果として，通信量が増加します。

2
Content-Lengthヘッダの無効

クライアント性能測定スクリプトが挿入されたコンテンツは，Content-Lengthヘッダが設定されません。なお，サーブレットまたはクライアント性能フィルタよりもあとのサーブレットフィルタが発行したsetContentLength()についても，クライアント性能測定スクリプトが挿入される場合は無効となります。

HEADメソッドによるリクエストへのレスポンスとして，Content-Lengthが設定されなくなります。

3
コンテンツのキャッシュ制御
クライアント性能測定スクリプトが挿入されたHTMLコンテンツは，Webブラウザおよびキャッシュサーバにキャッシュされません。レスポンスには次のHTTPヘッダが付与されます。
Cache-Control: no-store, no-cache
Pragma: no-cache
この結果，Webブラウザの［戻る］ボタンを押すと，事前のフォーム入力内容が消えてしまうなどの影響があります。
なお，そのほかのHTMLコンテンツ以外（画像ファイルなど）のキャッシュ制御は，クライアント性能モニタ機能を適用する前と同じです。

4
WebアプリケーションのリクエストヘッダIf-None-MatchおよびIf-Modified-Sinceの削除

リクエストヘッダに含まれるIf-None-Matchヘッダは削除されます。

クライアント性能フィルタを適用したWebアプリケーションの開始時刻よりも古いHTTPリクエストのIf-Modified-Sinceヘッダは削除されます。

遷移については，「図9-24　Webアプリケーションのリクエストヘッダおよびレスポンスヘッダの制御例」を参照してください。

5
WebアプリケーションのレスポンスヘッダLast-Modifiedの変換
HTTPレスポンスにLast-Modifiedヘッダが含まれる場合，クライアント性能フィルタを適用したアプリケーションの開始時刻に変換します。
遷移については，「図9-24　Webアプリケーションのリクエストヘッダおよびレスポンスヘッダの制御例」を参照してください。

6
フレーム構成のWebブラウザの見た目の変化
クライアント性能フィルタが適用されたフレーム構成のWebブラウザを表示した場合，ページの最上部または最左部に境界線が表示されます。

7
javax.servlet.ServletResponseのバッファサイズの変化
クライアント性能フィルタでは，javax.servlet.ServletResposeを独自に拡張したクラスのインスタンスを生成して，サーブレットフィルタ，サーブレット，JSPまたは静的コンテンツに送信します。このときgetBufferSizeメソッドで取得できるバッファサイズは，クライアント性能フィルタ適用前よりも大きくなる場合があります。この場合のバッファサイズは，クライアント性能フィルタの初期化パラメタfilterSizeに指定した値になります。

8
WebアプリケーションのリクエストヘッダRangeの変化

クライアント性能フィルタを適用した場合，HTTP/1.1の仕様で定義されている部分的GETは使用できません。

リクエストヘッダに含まれるRangeヘッダを削除します。

図9-24　Webアプリケーションのリクエストヘッダおよびレスポンスヘッダの制御例

(2)　複数のWebアプリケーションに対する同時適用についての注意事項

クライアント性能モニタ機能の性能データは，アプリケーション単位で取得されます。そのため，モニタページで確認できるのはモニタページ表示のためにアクセスしている同一アプリケーション内の情報だけです。複数のWebアプリケーションの性能データを横断的に表示および確認することはできません。

(3)　user Dataビヘイビアのデータサイズについての注意事項

クライアント性能モニタ機能では，Internet Explorerのuser Dataビヘイビアを使用して性能データを記録します。ただし，user Dataビヘイビアを使用して保存できるデータサイズには上限があります。クライアント性能モニタ機能が使用できるデータサイズは，一つのWebアプリケーション当たり最大384キロバイトです。

Webアプリケーションでuser Dataビヘイビアを使用している場合，同じドメイン内で保存するデータサイズの合計が，user Dataビヘイビアの仕様で定められている上限値を超えないようしてください。user Dataビヘイビアについては，Internet Explorerのドキュメントを参照してください。

(4)　問い合わせIDに含まれるIPアドレス情報についての注意事項

デフォルト設定の場合，クライアント性能モニタ機能が生成する問い合わせIDには，サーバが動作しているホストのIPアドレスが含まれます。負荷分散機やリバースプロキシを使用している場合など，サーバのIPアドレスをクライアント側に公開しないシステム構成のときには，問い合わせIDにIPアドレスを含まないように設定することを推奨します。詳細は，「9.2.3　問い合わせIDの定義方法」を参照してください。

(5)　コンテンツ出力時の文字セットについての注意事項

サーブレットやJSPなどからコンテンツを出力する場合にjavax.servlet.ServletResponseクラスのgetOutputStreamメソッドを使用して取得した出力ストリームに出力するときは，setContentTypeメソッドなどによってコンテンツの文字セットを適切に設定しておいてください。設定されている文字セットとサーブレットが出力するコンテンツが異なる場合，クライアント性能測定スクリプトが挿入されないことがあります。

また，クライアント性能測定スクリプトが挿入されたコンテンツでは，Webブラウザでの文字セットの自動識別の結果が挿入前と変化することがあります。この場合，文字セットが指定されていないコンテンツで表示すると，結果に文字化けが発生することがあります。クライアント性能モニタ機能を適用していない場合は正常に表示されていたコンテンツでも，文字化けが表示される場合があります。

(6)　Webアプリケーション中の変数についての注意事項

クライアント性能測定スクリプトでは，変数としてClientPerformanceを使用します。WebアプリケーションのHTMLコンテンツで同じ変数名を使用している場合，クライアント性能モニタ機能は適用できません。

(7)　クライアント性能モニタ機能で予約されているファイル名に関する注意事項

次に示すファイル名はクライアント性能モニタ機能で予約されています。Webアプリケーションでは使用しないでください。

"cpmonitor_"で始まるファイル
Webアプリケーション内のすべてのディレクトリが対象です。

/ReceiveAllDataSampleServlet

/SendAllDataSample.html

これらのファイル名に重複するものがWebアプリケーションにある場合，クライアント性能モニタ機能は適用できません。重複するファイル名がある場合は，Webアプリケーションのファイル名を変更してください。ファイル名にはサーブレットマッピングなども含みます。

(8)　Webブラウザの中止ボタンについての注意事項

クライアント性能測定スクリプトが挿入されたコンテンツを表示している最中，モニタページを操作している最中などに，Webブラウザの中止ボタンは使用しないでください。保存している性能データが壊れるおそれがあります。

(9)　Webブラウザの並行操作に関する注意事項

クライアント性能モニタ機能を適用したWebアプリケーションでは，性能取得フェーズで複数のWebブラウザを同時に並行して操作しないでください。保存している性能データが壊れるおそれがあります。この理由から，クライアント性能モニタ機能はユーザの操作なしで自動的に画面を遷移させる機能（HTMLのMETAタグによる自動更新など）を持つようなWebアプリケーションには適用できません。

(10)　フレーム構成のWebブラウザの性能データに関する注意事項

フレーム構成のWebブラウザ（<iframe>によるインラインフレームページを含む）に対してクライアント性能モニタ機能を適用する場合，親フレームを表示した時に最初に表示される子フレームのコンテンツの通信時間，描画時間および応答時間の情報は取得されないことがあります。ただし，そのあとの子フレーム内で遷移した時に表示される各コンテンツの情報は取得されます。

次の図に例を示します。

図9-25　フレーム構成のWebブラウザの性能データを取得する場合の例

子フレームBの通信時間，描画時間および応答時間は取得されない場合があります。親フレームAおよび子フレームCの情報については取得されます。

(11)　測定対象のHTMLコンテンツについての注意事項

クライアント性能フィルタは，クライアント性能測定スクリプトの挿入位置を文字列の比較で検索します。HTMLコンテンツのコメント部分など，HTMLタグが無効となる位置に，<head>，</head>，<body>，<frameset>などのHTMLタグを表す文字列がある場合，これらの位置にクライアント性能測定スクリプトを挿入するおそれがあります。このようなHTMLコンテンツを含むWebアプリケーションには，クライアント性能モニタ機能は適用できません。

9.5.2　モニタページに関する注意事項

モニタページに関する注意事項を次に示します。

＜この項の構成＞

(1)　モニタページの複数同時使用の禁止についての注意事項

(2)　サポートしない操作

(3)　モニタページに表示されるURLのディレクトリについての注意事項

(4)　性能データの削除と取得の同時実行の禁止についての注意事項

(5)　モニタページに表示されるコンテキストルートについての注意事項

(1)　モニタページの複数同時使用の禁止についての注意事項

クライアント性能モニタ機能では，複数のWebブラウザでモニタページを同時に表示することはできません。クライアント性能モニタ機能を複数のWebアプリケーションに適用している場合でも，一つのマシン上に表示できるモニタページは一つだけです。複数のWebブラウザで同時に操作した場合の動作はサポートしません。

(2)　サポートしない操作

次に示す操作はサポートしません。

マルチバイト文字を含むURL
クライアント性能モニタ機能のモニタページは，マルチバイト文字を含むURLは表示できません。

TABキーの操作
クライアント性能モニタ機能のモニタページでは，TABキーを使った操作には対応していません。モニタページはマウスで操作してください。

右クリックのページ操作
クライアント性能モニタ機能のモニタページでは，Webブラウザ上で右クリックした場合に表示される「前に戻る」，「次に進む」，「最新の情報に更新」，「新しいウィンドウで開く」などの操作は実行しないでください。動作状態が不安定になる場合があります。

(3)　モニタページに表示されるURLのディレクトリについての注意事項

モニタページに表示される性能情報で，URLのディレクトリについては，情報が記録されない場合があります。この場合，URLは「[dir]/ファイル名」という形式で表示されます。

(4)　性能データの削除と取得の同時実行の禁止についての注意事項

性能データの削除を実行しているときに性能データが更新されると，Webブラウザに保存されている性能データが破壊される場合があります。性能データを削除する場合は，操作を実行する前に性能データを取得しているWebアプリケーションの画面を閉じて，性能データが更新されないようにしてください。

(5)　モニタページに表示されるコンテキストルートについての注意事項

モニタページに表示されるコンテキストルートは，Webブラウザから見た場合のパスです。そのため，リバースプロキシのパス変換などによってサーバ側のコンテキストルートのパスが変換されている場合は，サーバ側とは異なる内容が表示されます。

10.　統合ユーザ管理

この章では，アプリケーションサーバで構築したシステムのユーザを統合管理するための統合ユーザ管理フレームワークについて説明します。

なお，この章で説明する機能は，J2EEサーバの動作モードには依存しないで使用できます。

＜この章の構成＞

10.1　この章の構成

10.2　統合ユーザ管理の概要

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

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

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

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

10.7　ユーザ情報の管理

10.8　統合ユーザ管理フレームワークが提供するAPI

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

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

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

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

10.13　カスタムログインモジュールを使用したユーザ認証の実装

10.14　統合ユーザ管理機能の設定手順

10.15　レルム名の決定

10.16　LDAPディレクトリサーバの設定

10.17　ユーザ情報の登録

10.18　暗号鍵ファイルの作成（シングルサインオンを使用する場合）

10.19　ユーザ情報の登録（シングルサインオンを使用する場合）

10.20　コンフィグレーションファイルの作成

10.21　JavaVMのプロパティの設定

10.22　ファイルのデプロイ

10.1　この章の構成

統合ユーザ管理フレームワークとは，Javaの標準ユーザ認証（JAAS）によるアプリケーションユーザ管理および複数のアプリケーションへのシングルサインオンを実現するフレームワークです。ここでは，統合ユーザ管理フレームワークを使用した統合ユーザ管理について説明します。

この章の構成を次の表に示します。

表10-1　この章の構成（統合ユーザ管理）

分類 | タイトル | 参照先
解説 | 統合ユーザ管理の概要 | 10.2
Cosminexus標準ログインモジュールによるユーザ認証の仕組み | 10.3
統合ユーザ管理のセッション管理 | 10.4
シングルサインオンの利用方法 | 10.5
カスタムログインモジュールの利用 | 10.6
ユーザ情報の管理 | 10.7
統合ユーザ管理フレームワークが提供するAPI | 10.8
実装 | 統合ユーザ管理フレームワークによるユーザ認証の実装 | 10.9
APIを使用したユーザ認証の実装 | 10.10
タグライブラリを使用したユーザ認証の実装 | 10.11
セッションフェイルオーバ機能使用時のユーザ認証の実装 | 10.12
カスタムログインモジュールを使用したユーザ認証の実装 | 10.13
設定 | 統合ユーザ管理機能の設定手順 | 10.14
レルム名の決定 | 10.15
LDAPディレクトリサーバの設定 | 10.16
ユーザ情報の登録 | 10.17
暗号鍵ファイルの作成（シングルサインオンを使用する場合） | 10.18
ユーザ情報の登録（シングルサインオンを使用する場合） | 10.19
コンフィグレーションファイルの作成 | 10.20
JavaVMのプロパティの設定 | 10.21
ファイルのデプロイ | 10.22

注　「運用」および「注意事項」について，この機能固有の説明はありません。

10.2　統合ユーザ管理の概要

統合ユーザ管理は，Cosminexusシステムにログインするユーザについての情報を統合管理する機能です。

統合ユーザ管理を実現するために，Cosminexusでは次の機能を提供しています。

統合ユーザ管理フレームワーク
統合ユーザ管理でのユーザ認証を実現するフレームワークです。Java標準仕様（JAAS）に従ったアプリケーションプログラムインタフェースを提供します。

＜この節の構成＞

10.2.1　統合ユーザ管理の目的

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

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

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

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

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

10.2.1　統合ユーザ管理の目的

従来，企業内にある各種の業務システムでは，業務の要件によってそれぞれ独自の方法でそのシステムのユーザを管理しています。例えば，勤休管理のシステムでは，社員データベースに登録された社員個人をシステムのユーザとして区別します。また，資材の発注システムでは，原価管理のための各部署をシステムのユーザとして区別します。最近はイントラネット技術の発展によって，システムごとのクライアントプログラムをインストールしなくても，Webブラウザを使ってこれらの業務サービスを受けられるようになってきています。しかし，社内メールサービスを利用するにはメールのIDで，勤休管理サービスでは社員番号で，また資材発注サービスは部署コードでログインをするといったように，それぞれのシステムのユーザ管理に従ったユーザ認証のための操作が必要で，簡単にそれらのシステムのサービスを統合した新たなサービスを提供することは困難でした。

統合ユーザ管理フレームワークは，JavaEEの技術でこれらのサービスを統合するためのユーザ管理のフレームワークです。統合ユーザ管理フレームワークの例を次の図に示します。

図10-1　統合ユーザ管理フレームワークの例

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

ここでは，統合ユーザ管理で使用する概念である，レルムとユーザマッピングについて説明します。

＜この項の構成＞

(1)　レルム（Realm）

(2)　レルム間のユーザマッピング

(1)　レルム（Realm）

レルムとは，同一の認証ポリシーを適用する範囲のことです。業務サービスを提供するアプリケーションは，提供するサービスの要件に従って，そのサービスを利用するユーザを区別します。ユーザを区別するための処理は，一般に認証処理と呼ばれます。認証処理は，サービスを利用するユーザを区別するための認証メカニズムと，そのためのユーザ認証データベース（ユーザ認証リポジトリ）によって分類できます。どのような認証メカニズム（群）を利用し，どのようなユーザをユーザ認証データベースに登録するかといった認証ポリシーを決定するのは，システムを管理するシステム管理者の仕事です。

単一のサービスを提供するシステムを構築する場合にはあまり問題になりませんが，多数のサービスを提供するシステムを構築する場合，どの範囲でどのような認証ポリシーを適用してシステムを運用するかという検討が必要です。Webシステムでは，同一の認証ポリシーを適用する範囲をレルムと呼び，それぞれのレルムを識別する名称のことをレルム名と呼びます。あるレルムで認証されたユーザは，該当レルム内でそのユーザを一意に識別する識別子（ユーザID）を持っています。

同じユーザ管理要件を持つ複数のアプリケーションは，一つのレルムで運用できます。新たにすべてのサービスを構築する場合，すべてのサービスを一つのレルムにして，認証されたユーザの持つセキュリティ属性によって各種のサービスに対してコントロールするようにできれば管理しやすいのですが，現実にはなかなかそのようなシステムの構築はされません。社内メールではメールのID，人事システムでは従業員番号，資材システムには部署コードでログインするといったように，企業システムにはすでに多くのレルムがあり，これらは別々に管理運用されています。

管理者は，Cosminexusを使用してこれらのサービスの統合をする場合，何のためにそのレルムが必要なのか分析し，運用管理を簡単にするためにできるだけ少ないレルムで運用できるように，レルムの統廃合を検討してください。レルムの運用例を次の図に示します。

図10-2　レルムの運用例

(2)　レルム間のユーザマッピング

業務サービスを提供するアプリケーションは，ユーザの情報が必要になると，まずエンドユーザにユーザIDとパスワードの入力を求め，それを基にユーザを認証します。一度受けた認証の結果は，ログアウトするまで保持されます。ただし，ユーザIDおよびパスワードが異なるアプリケーションに続けてログインしようとすると，そのたびにアプリケーションからユーザIDとパスワードの入力を求められます。つまり，一度一つのアプリケーションで認証を受けたユーザであっても，異なるレルムで管理されているアプリケーションにアクセスするためには，そのつど認証を受ける必要があります。

これに対して，あるレルムでログインしたユーザが，ほかのレルムでどのユーザとして扱われるのかが分かれば，レルムが異なるJ2EEアプリケーションにログインするたびにユーザIDとパスワードを入力する必要はなくなります。統合ユーザ管理フレームワークでは，この問題を解決するために，あるレルムでログインしたユーザをほかのレルムのユーザにマッピングするユーザマッピングを実現します。

ユーザマッピングとは，元のレルムでの認証が成功したという認証状態が引き継がれていれば，自動的にほかのレルムにマッピングしてユーザ認証をするものです。ユーザマッピングをする場合，Cosminexusのシステム管理者が，あるレルムのユーザとほかのレルムのユーザとのマッピング情報をあらかじめシステムに定義しておきます。

次の図に示すようなユーザマッピングの例では，勤休管理サービスで認証されたユーザ「USER3」に対して，資材発注サービスのユーザ「dev_3」のマッピングを定義しておきます。これによって，勤休管理サービスに「USER3」として認証されたユーザは，資材発注サービスへのログイン操作をしなくても自動的に該当サービスに対して「dev_3」として認証されます。

図10-3　ユーザマッピングの例

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

今までの業務システムのWeb化では，従来の業務システムが持っていたユーザ認証機構をWebのサービスから独自のインタフェースで呼び出していました。また，最初からJavaEEの技術技術で構築されるWeb業務サービスも，各社のアプリケーションサーバが提供する独自のユーザ認証機構を使って構築されてきました。これらのインタフェースの違いは，サービスを統合する場合の大きな障害になっていました。しかし，Javaの標準ユーザ認証の仕様としてJAAS（Java Authentication and Authorization Service） 1.0が決まり，現在ではJavaEEの技術で構築されるWeb業務サービスのユーザ認証の標準となっています。

＜この項の構成＞

(1)　統合ユーザ管理フレームワークと個別のユーザ管理の関連

(2)　Cosminexus標準ログインモジュールの概要

(1)　統合ユーザ管理フレームワークと個別のユーザ管理の関連

JAASでは，アプリケーションが認証を要求する側のインタフェース（API：アプリケーションプログラミングインタフェース）と，その要求を受け認証処理をする側のインタフェース（SPI：サービスプロバイダインタフェース）を規定しています。認証処理をする側のモジュールをログインモジュールといいます。APIとSPIの関係を次の図に示します。

図10-4　APIとSPIの関係

Cosminexusでは，標準でパスワード認証の機能を持つCosminexus標準ログインモジュールを提供しています。このCosminexus標準ログインモジュールを利用して，JAASのAPIを使用するJSP/サーブレットで作成されたJ2EEアプリケーションのユーザ管理ができます。

Cosminexus標準ログインモジュールを使用すれば，アプリケーション開発者は，独自に認証モジュールを開発する必要はありません。また，モジュールはスタック可能なので，Cosminexus標準ログインモジュールと連携する拡張認証モジュールを容易に追加できます。さらに，完全に独自認証機能を必要とするアプリケーションでは，容易にCosminexus標準ログインモジュールを独自認証モジュールに置き換えて使用できます。これによって，JAASを使用してユーザ認証をしているアプリケーションプログラムを簡単にCosminexusで統合できるようになります。

これを，JAAS対応ユーザ管理と呼びます。JAAS対応ユーザ管理の概要を次の図に示します。なお，図中のユーザ情報リポジトリとは，認証処理に必要なユーザ情報が格納されているリポジトリです。

図10-5　JAAS対応ユーザ管理の概要

統合ユーザ管理フレームワークに従って，JAAS対応ユーザ管理を使用すると，ある業務サービスで認証されたユーザを，別の業務サービスのユーザにマッピングして認証要求する，ユーザマッピングの機能を利用できます。また，独自のユーザ情報リポジトリを利用する場合でも，カスタムログインモジュールを作成すれば，その業務サービスも含めたシングルサインオンが実現できます。ユーザマッピングによるシングルサインオンの概要を次の図に示します。なお，図中のシングルサインオン情報リポジトリとは，シングルサインオンに必要なマッピング情報が格納されているリポジトリです。

図10-6　ユーザマッピング機能の概要

(2)　Cosminexus標準ログインモジュールの概要

Cosminexus標準ログインモジュールは，パッケージjavax.security.auth.spiに含まれるLoginModuleインタフェースの実装クラスです。実現する認証方法に応じて使い分けられます。

Cosminexus標準ログインモジュールの特徴を次に示します。

既存のユーザ情報（LDAP情報またはデータベース情報）を利用したユーザ認証ができます。

Cosminexus標準ログインモジュールでは，ユーザ認証に使用するユーザ情報を格納するリポジトリとしてLDAPディレクトリサーバまたはデータベース（RDB）を使用できます。

LDAPディレクトリサーバを使用する場合，標準のユーザ管理リポジトリのDIT（Directory Information Tree）の構造をCosminexusが規定しています。また，すでにLDAPを導入しているときには，その情報を利用できるように簡単にカスタマイズできます。なお，DITとは，ユーザや組織の情報をツリー構造で管理するためのLDAPの仕組みです。詳細については，「10.2.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。

認証方式としては，証明書を使用した認証やパスワード認証ができます。認証方式は，Cosminexus標準ログインモジュールの種類によって異なります。

ユーザ情報を参照できます。

ユーザ認証が成功した場合に，ログインユーザについての情報を参照できます。

JAASでは，認証が成功すると認証したユーザの情報をCredentialとしてSubjectに設定することが規定されています。また，これを要求元のアプリケーションからjava.util.setインタフェースで参照するための一般的なメソッド（getPublicCredentialsメソッドおよびgetPrivateCredentialsメソッド）が規定されています。

Cosminexus標準ログインモジュールでは，ユーザ情報を参照するためのインタフェースを提供しています。このインタフェースでは，コンフィグレーションに従って，ユーザの情報をCosminexusが提供するUserAttributesインタフェースで扱うオブジェクトとして，Credentialに設定します。アプリケーションでは標準のインタフェースでこのオブジェクトを取り出し，該当オブジェクトのgetAttributeメソッドに属性名を指定して呼び出すことで，必要なユーザ情報を取得できます。また，属性名の別名（エイリアス）を指定して，情報を取得することもできます。

シングルサインオンを実現できます。

Cosminexus標準ログインモジュールは，シングルサインオンに対応できます。

なお，シングルサインオンを実現する場合，ユーザ情報を管理しているリポジトリの種類と関係なく，LDAPディレクトリサーバが必要です。

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

ここでは，統合ユーザ管理で使用するユーザ情報の管理方法について説明します。

統合ユーザ管理では，ユーザ情報を格納するリポジトリとして，LDAP，またはデータベースを使用します。LDAPディレクトリサーバでは，ユーザや組織の情報は，DITで管理されます。統合ユーザ管理フレームワークで使用するLDAPディレクトリサーバでは，ユーザおよびレルムをDITのエントリとして管理します。エントリは，DITを構成する情報で，DITの各節に該当する情報です。個々のエントリは，DN（識別名）で区別されます。

Cosminexusでは，統合ユーザ管理フレームワークで使用するLDAPディレクトリサーバに格納する標準のユーザ管理リポジトリのDIT構造を規定しています。統合ユーザ管理フレームワークで使用するリポジトリは，2種類あります。

ユーザ情報リポジトリ
ユーザ情報を格納します。

シングルサインオン情報リポジトリ
統合ユーザ管理フレームワークのユーザマッピングを実行して，シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報を格納します。

これらのリポジトリは，次の図に示すようなディレクトリ構造を持ちます。

図10-7　統合ユーザ管理フレームワークのリポジトリのDIT構造

各リポジトリについて説明します。

＜この項の構成＞

(1)　ユーザ情報リポジトリ（LDAPディレクトリサーバの場合）

(2)　ユーザ情報リポジトリ（データベースの場合）

(3)　シングルサインオン情報リポジトリ

(1)　ユーザ情報リポジトリ（LDAPディレクトリサーバの場合）

ユーザ認証で使用するユーザ情報は，ユーザ情報リポジトリに格納します。統合ユーザ管理フレームワークは，LDAPディレクトリサーバのユーザ情報リポジトリに格納されたユーザ情報を基にユーザを認証して，認証したユーザの情報をアプリケーションに渡します。ユーザ情報リポジトリのユーザ情報の参照には，ユーザ認証ライブラリを使用します。ユーザ情報リポジトリのDIT構造を次の図に示します。

図10-8　ユーザ情報リポジトリのDIT構造

管理するレルムごとにユーザ情報リポジトリを設定してください。

(a)　レルム

JAAS対応ユーザ管理のレルム名を指定します。レルム名は次の表に示す基準に従って指定してください。

表10-2　レルム名の基準

情報の種類
意味
文法

レルム名
ユーザ管理の範囲を示す識別子。
英数字列。
大文字と小文字を区別しません。
DN名で使用できる名前を付けてください。

注　英数字列は，英字（A～Z，a～z）と数字（0～9）の文字の並びを意味します。ASCII文字列で指定してください（文法については，プログラムではチェックしていません）。

(b)　アプリケーション固有情報

該当レルムを使用する各アプリケーション固有の情報を格納する場合に使用してください。統合ユーザ管理フレームワークを使用する場合に必須な情報はありません。

(c)　ユーザ認証ライブラリのベースDN

レルムに属するユーザエントリの上位エントリです。レルムに属する各ユーザのエントリは，このエントリの下階層にある必要があります。なお，ユーザエントリがこのエントリの直下にない場合は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）のcom.cosminexus.admin.auth.ldap.search.scopeオプションを変更する必要があります。また，このエントリで指定した情報はjaas.conf（JAASのコンフィグレーションファイル）に指定する必要があります。各コンフィグレーションファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

(d)　ユーザエントリ

ユーザ情報を定義します。ユーザ認証ライブラリでは，ユーザ情報として次の表に示す属性が必要です。

表10-3　ユーザ情報に必要な属性

属性名 | 説明 | 必須
ユーザID | ユーザIDを格納します。属性は，文字列（cisなど）である必要があります。デフォルトでは，「uid」属性名を使用します。 | 必須
パスワード | パスワードを格納します。属性はバイナリです。平文または暗号化した値を格納します。この属性に値が指定されていない場合は，アカウントが無効になります。デフォルトでは，「userPassword」属性名を使用します。 | オプション
そのほかの属性 | 各アプリケーションが定義している属性です。 | 各アプリケーションの仕様に従ってください。

ユーザIDおよびパスワードの属性名は，jaas.conf（JAASのコンフィグレーションファイル）で変更できます。

(e)　注意事項

ユーザ情報リポジトリのディレクトリ構成は，JAAS対応ユーザ管理で推奨するDIT構成です。別の構成で管理する場合は「ユーザ認証ライブラリのベースDN」以下の次の条件を満たすユーザのエントリが必要です。

ユーザIDとパスワードは，同一オブジェクトクラス内にある必要があります。

パスワードの属性はバイナリである必要があります。また，暗号化した値が格納されていることを推奨します。平文で格納されている場合は，一度ldif形式のファイルに出力してからconvpwコマンドで暗号化して，再登録してください。convpwコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「convpw（パスワードの暗号化）」を参照してください。

ユーザIDおよびパスワードは，同じ属性名を使用してマルチバリューで指定できますが，Cosminexusシステムの運用上，一つのオブジェクトクラス内に一つだけ指定してください。もし，複数指定した場合は，最初に見つかったものを使用します。

ユーザIDとして使用する属性のユーザIDは，レルム内（ユーザ情報リポジトリのベースDN下）で一意な値にしてください。

なお，ユーザ情報リポジトリのベースDN，使用するユーザIDおよびパスワードの属性名については，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定します。ua.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

(2)　ユーザ情報リポジトリ（データベースの場合）

統合ユーザ管理フレームワークは，データベースに格納されたユーザ情報を基にユーザを認証できます。データベースでは，ユーザIDからパスワードを取得できるようにしてください。

(3)　シングルサインオン情報リポジトリ

シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報は，シングルサインオン情報リポジトリに格納します。統合ユーザ管理フレームワークは，LDAPディレクトリサーバのシングルサインオン情報リポジトリに格納されたユーザ情報を基にユーザマッピングをして，シングルサインオンを実現します。シングルサインオン情報リポジトリのユーザ情報は，シングルサインオンライブラリを使用して参照します。シングルサインオン情報リポジトリのDIT構造を次の図に示します。

図10-9　シングルサインオン情報リポジトリのDIT構造

(a)　シングルサインオン情報リポジトリのベースDN

シングルサインオンを使用するために必要な情報を管理するDITの，最上位のエントリです。このエントリは，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定します。ua.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。なお，ここで指定する名称は，大文字と小文字が区別されません。この値は，標準のオブジェクトクラスである「organizationalUnit」のou属性に設定されます。

(b)　レルム

ユーザ情報はレルムごとに管理されます。シングルサインオン情報リポジトリのレルム名では，大文字と小文字は区別されません。この値は，標準のオブジェクトクラスである「organizationalUnit」のou属性に設定されます。

(c)　ユーザエントリ

シングルサインオンで接続したいアプリケーションで，ユーザ管理に使用しているユーザの認証情報および接続先を格納するためのエントリです。ユーザエントリの構造を次の図に示します。

図10-10　ユーザエントリの構造

管理用識別子

シングルサインオンライブラリで登録した際に自動的に設定される識別子です。

ユーザID

各レルムで一意なユーザIDを文字列で指定します。ユーザIDでは，大文字と小文字は区別されます。

暗号化したデータ

登録する際に暗号化が必要なデータを格納します。例えば，パスワードは，この属性に格納することで，暗号化されて保存されます。

暗号化しないデータ

登録する際に暗号化する必要がない，ユーザIDおよび暗号化データ以外に認証に必要な情報を格納します。例えば，ユーザに付くグループIDを保存します。

ユーザ管理を持つアプリケーションのユーザエントリのDN名

ここには，ユーザが接続する，ユーザ管理を持つアプリケーションのユーザ認証情報の格納先（DN名）が格納されます。この値は，複数指定できます。

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

JAASでのユーザ認証の有効期限は，loginメソッドの成功からlogoutメソッドを呼び出すまでです。

J2EEのWebアプリケーションでは，ユーザとの仮想的なセッションをHttpSessionオブジェクトでコントロールします。複数のHTTPプロトコルの通信を一連のセッションとして扱う場合は，WebアプリケーションでCookieまたはURL書き換えなどでHttpSessionオブジェクトと要求ユーザの結び付けをするようにコーディングします。

統合ユーザ管理フレームワークでは，ユーザ認証に成功した状態をHttpSessionオブジェクトで記憶しています。同一HttpSessionオブジェクトを利用した要求で，かつ同一レルムの場合に限り，2回目以降のログインでは，自動的に最初のログインで指定されたユーザの認証情報（ユーザID／パスワード）を使用して認証状態の引き継ぎをするため，エンドユーザからの認証情報の入力を省略できます。

ただし，次の表に示す順序でログインモジュールが使用された場合，エンドユーザから認証情報の入力を省略する機能は働きません。それぞれのログインモジュールの機能については，「10.3　Cosminexus標準ログインモジュールによるユーザ認証の仕組み」を参照してください。

表10-4　エンドユーザから認証情報の入力を省略する機能が働かない使用順序

使用順序
使用するログインモジュール

1回目のログイン

DelegationLoginModule（カスタムログインモジュールやWebCertificateLoginModuleを呼び出す場合）

WebCertificateLoginModule

WebSSOLoginModule（カスタムログインモジュールやWebCertificateLoginModuleを呼び出す場合）

2回目以降のログイン

WebPasswordLDAPLoginModule

また，次の表に示す順序でログインモジュールを使用する場合，WebPasswordLDAPLoginModuleによる2回目以降のログインで認証情報の入力を省略するためには，最初のログインで使用するログインモジュールでパスワードを統合ユーザ管理のセッションに保持する必要があります。さらに，WebPasswordLDAPLoginModuleでの2回目以降のログインに使用するパスワードが最初のログインで保持したパスワードと同じでなければなりません。パスワードを保持するかどうか，および保持する場合に暗号化をするかどうかは，jaas.conf（JAASのコンフィグレーションファイル）およびua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定できます。jaas.conf（JAASのコンフィグレーションファイル）の指定方法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。ua.conf（統合ユーザ管理のコンフィグレーションファイル）の指定方法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

表10-5　2回目以降のログインで認証情報の入力を省略するために条件がある使用順序

使用順序
使用するログインモジュール

1回目のログイン

WebPasswordLoginModule

WebPasswordJDBCLoginModule

WebPasswordLDAPLoginModule

2回目以降のログイン

WebPasswordLDAPLoginModule

保持するパスワードを暗号化しない場合，J2EEサーバが使用するメモリの内容を何らかの方法で参照されるとパスワードが漏洩する可能性があります。また，セッションフェイルオーバ機能を使用する場合，パスワードを含むセッション情報がネットワークを流れるため，パスワードが盗聴されるおそれがあります。暗号化をすることで，パスワードが漏洩するおそれは少なくなりますが，性能は劣化します。暗号化をするかどうかは，必要とするセキュリティや性能に応じて決定してください。なお，暗号化する場合，暗号アルゴリズムにはトリプルDESが使用されます。

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

統合ユーザ管理を使用する場合の処理の流れを次の図に示します。

図10-11　統合ユーザ管理を使用する場合の処理の流れ

図の流れについて説明します。

Webブラウザからログインを要求するリクエストを送信します。

Webアプリケーションから，認証処理をするためのログインモジュールの呼び出し処理が実行されます。

Cosminexus標準ログインモジュールを使用して，ユーザ認証処理が実行されます。使用するログインモジュールおよびそのコンフィグレーションは，jaas.conf（JAASのコンフィグレーションファイル）またはua.conf（統合ユーザ管理のコンフィグレーションファイル）に定義されています。また，認証に必要な情報は，ユーザ情報リポジトリであるLDAPディレクトリサーバまたはデータベースから取得します。

認証結果がWebアプリケーションに返却されます。

この処理を実現するためには，システムを構築するユーザとアプリケーション開発者によるシステムの設定およびアプリケーションの開発が必要です。

システムを構築するユーザの作業の概要

jaas.conf（JAASのコンフィグレーションファイル）およびua.conf（統合ユーザ管理のコンフィグレーションファイル）に，使用するログインモジュール，使用するリポジトリ，およびそれらのコンフィグレーション情報を定義します。シングルサインオンを使用する場合には，ua.conf（統合ユーザ管理のコンフィグレーションファイル）にシングルサインオン用のパラメタも定義します。

シングルサインオンを使用する場合には，暗号鍵ファイルを作成します。

ユーザ情報リポジトリにユーザ情報を登録しておきます。

UNIXの場合，Component Container管理者および統合ユーザ管理グループに設定したユーザが，<Cosminexusインストールディレクトリ>/manager/config以下に格納されているjaas.conf（JAASのコンフィグレーションファイル）およびua.conf（統合ユーザ管理のコンフィグレーションファイル）を使用するときは，それぞれのコンフィグレーションファイルにあらかじめ適切なアクセス権を設定しておいてください。

なお，jaas.confおよびua.confはテキストエディタなどで編集してください。

統合ユーザ管理機能の設定については，「10.20　コンフィグレーションファイルの作成」を参照してください。

アプリケーション開発者の作業の概要

JAASのAPIおよびCosminexusが提供している統合ユーザ管理API，JSPタグライブラリを使用して，ログインモジュールを呼び出す認証処理プログラムを作成します。

それぞれのアプリケーションで独自の認証処理をする場合は，カスタムログインモジュールを作成します。

パスワード認証時のパスワード拡張をする場合は，実装クラスを作成します。

統合ユーザ管理フレームワークを使用したユーザ認証の実装については，「10.9　統合ユーザ管理フレームワークによるユーザ認証の実装」を参照してください。

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

統合ユーザ管理フレームワークでは，JAASに準拠したCosminexus標準ログインモジュールを提供します。Cosminexus標準ログインモジュールを使用することで，独自に認証モジュールを作成しなくても，Cosminexusシステムのユーザの統合管理が実現できます。

＜この節の構成＞

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

10.3.2　WebPasswordLoginModule

10.3.3　WebCertificateLoginModule

10.3.4　WebPasswordLDAPLoginModule

10.3.5　WebPasswordJDBCLoginModule

10.3.6　DelegationLoginModule

10.3.7　WebSSOLoginModule

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

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

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

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

統合ユーザ管理フレームワークが提供するCosminexus標準ログインモジュールは，次の2種類に分類できます。

ユーザを認証するために使用するログインモジュール
次の四つのログインモジュールが該当します。

WebPasswordLoginModule
パスワードを使用してユーザ認証するログインモジュールです。

WebCertificateLoginModule
クライアント証明書を使用してユーザ認証するログインモジュールです。

WebPasswordLDAPLoginModule
LDAPディレクトリサーバの認証機能を使用してユーザ認証するログインモジュールです。

WebPasswordJDBCLoginModule
ユーザ情報リポジトリとして，すでにデータベースを使用している場合に使用するログインモジュールです。

各アプリケーションのカスタムログインモジュールを呼び出すためのログインモジュール
次の二つのログインモジュールが該当します。

DelegationLoginModule
カスタムログインモジュールを呼び出す場合に使用するログインモジュールです。シングルサインオンには対応しません。

WebSSOLoginModule
シングルサインオンで使用するログインモジュールです。Cosminexus標準ログインモジュールやカスタムログインモジュールなど，ほかのログインモジュールを呼び出します。

DelegationLoginModuleは，シングルサインオンの機能を使用しない場合にカスタムログインモジュールを呼び出すときに使用します。WebSSOLoginModuleは，シングルサインオンの機能を利用する場合に，ほかのCosminexus標準ログインモジュールまたはカスタムログインモジュールを呼び出すときに使用します。例えば，パスワードを使用してユーザ認証をしたいアプリケーションを，シングルサインオンの対象にしたい場合は，WebSSOLoginModuleからWebPasswordLoginModuleを呼び出して使用します。

それぞれのログインモジュールの機能一覧を次の表に示します。

表10-6　ログインモジュールの機能一覧

機能 | 種類
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　条件を満たしている場合に登録されます。

10.3.2　WebPasswordLoginModule

WebPasswordLoginModuleは，LDAPディレクトリサーバにユーザ情報リポジトリがある場合に，パスワード認証をするログインモジュールです。

入力されたユーザID/パスワードを使って，LDAPディレクトリサーバに格納されているユーザ情報からパスワードを取得して認証します。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）には，LDAPディレクトリサーバに接続するための定義やエントリを検索する際に使用する属性名（uidおよびuserPassword）を指定しておきます。

WebPasswordLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得してLDAPディレクトリサーバを検索し，パスワードを取得してパスワード認証をします。認証に問題がなければユーザ属性を返却します。WebPasswordLoginModuleの概要を次の図に示します。

図10-12　WebPasswordLoginModuleの概要

10.3.3　WebCertificateLoginModule

WebCertificateLoginModuleは，Webサーバで認証されたクライアント証明書を使用して認証をするログインモジュールです。

WebサーバがSSL認証した際にブラウザに要求したクライアント証明書の被認証者識別名と，ユーザ情報リポジトリとでマッピングします。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）には，クライアント証明書の被認証者の識別名内からユーザIDに該当する属性名（cn）とLDAPディレクトリサーバを検索する際に使用する属性名（uid）を指定しておきます。

WebCertificateLoginModuleではその内容を読み取り，クライアント証明書を使用して認証処理をします。クライアント証明書からユーザIDに該当するIDを取得してLDAPディレクトリサーバにアクセスした結果，認証に問題がなく，該当エントリがあればユーザ属性を返却します。なお，証明書内のユーザIDに対応したエントリがない場合は，FailedLoginException例外が発生します。

WebCertificateLoginModuleの概要を次の図に示します。

図10-13　WebCertificateLoginModuleの概要

10.3.4　WebPasswordLDAPLoginModule

WebPasswordLDAPLoginModuleは，LDAPディレクトリサーバの認証機能を利用したログインモジュールです。

入力されたユーザID，パスワードを使ってLDAPディレクトリサーバにバインドし，バインドが成功すると認証が成功します。WebPasswordLDAPLoginModuleの概要を次の図に示します。

図10-14　WebPasswordLDAPLoginModuleの概要

ua.conf（統合ユーザ管理のコンフィグレーションファイル）では，LDAPディレクトリサーバに接続するための定義と，エントリを検索するときに使用する属性名を指定します。

WebPasswordLDAPLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得して，ユーザIDからユーザエントリのDNを求めます。次に，このDNとHttpServletRequestから取得したパスワードでLDAPディレクトリサーバにバインドし，成功するとユーザ属性を返却します。

ユーザエントリ検索とユーザ属性の取得に使用するユーザID／パスワードについて

認証時にユーザエントリの検索をする場合，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定されたバインドDNとバインドDNのパスワードを使用します。一方，ユーザ属性の取得に使用するバインドDNとパスワードには，ユーザエントリのDNとそのパスワードを使用します。ユーザエントリの検索については，「10.3.8(1)　ユーザエントリの検索」を参照してください。

LDAP接続プールを利用する場合の注意

LDAP接続プールはユーザエントリの検索処理だけに使用されます。認証時およびユーザ属性取得時にLDAP接続プールは使用されません。したがって，検索をしない設定の場合はLDAP接続プールを使用しない設定にしてください。LDAP接続プールについては，「10.3.8(2)　接続プール」を参照してください。

10.3.5　WebPasswordJDBCLoginModule

WebPasswordJDBCLoginModuleは，すでにデータベースを用いてユーザ管理をしている場合に使用するログインモジュールです。

入力されたユーザIDとパスワードを使って，データベース内に格納されているユーザ情報からパスワードを取得して認証します。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）では，データベースに接続するための情報定義やエントリを検索する際に使用するSQL（SELECT文）を指定します。

WebPasswordJDBCLoginModuleではその内容を読み取り，HttpServletRequestからユーザIDを取得してJDBCを使ってデータベースにアクセスし，パスワードを取得してパスワード認証をします。WebPasswordJDBCLoginModuleの概要を次の図に示します。

図10-15　WebPasswordJDBCLoginModuleの概要

また，WebPasswordJDBCLoginModuleでは，JDBCドライバのクラスをログインモジュール内で参照します。使用できるJDBCドライバとJDBCドライバの設定手順を次に示します。

●使用できるJDBCドライバ

WebPasswordJDBCLoginModuleで使用できるデータベースとJDBCドライバを次の表に示します。

表10-7　WebPasswordJDBCLoginModuleで使用できるデータベースとJDBCドライバ

データベース
JDBCドライバ
JDBCのJARファイル

HiRDB※
HiRDB Type4 JDBC Driver
pdjdbc2.jar

Oracle
Oracle 10g R2
Oracle JDBC Thin Driver
ojdbc14.jar

Oracle 11g
ojdbc5.jar（JDK 5.0の場合）
ojdbc6.jar（JDK6の場合）

SQL Server
SQL Server 2005
SQL Server 2005 JDBC Driver
sqljdbc.jar

SQL Server 2008
SQL Server JDBC Driver

注※　HiRDB Run Timeを含みます。

●JDBCドライバの設定手順

JDBCドライバのクラスをua.conf（統合ユーザ管理のコンフィグレーションファイル）に設定します。また，JDBCドライバを任意のディレクトリに格納し，その場所をJ2EEサーバのクラスパスに追加してください。設定手順を次に示します。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）に，次の内容を設定します。

使用するJDBCドライバに対応するJDBCドライバのクラス名

データベースと接続するためのURL

代理で接続するデータベースユーザとそのユーザのパスワード

データベースごとに設定例を次に示します。なお，太字部分はデータベースの環境に合わせて設定してください。

HiRDBの場合

com.cosminexus.admin.auth.jdbc.driver.0=JP.co.Hitachi.soft.HiRDB.JDBC.HiRDBDriver

com.cosminexus.admin.auth.jdbc.conn.url.0=jdbc:hitachi:hirdb://DBID=22200,DBHOST=hostA

com.cosminexus.admin.auth.jdbc.conn.user.0=system

com.cosminexus.admin.auth.jdbc.conn.password.0=userpass

Oracleの場合

com.cosminexus.admin.auth.jdbc.driver.0=oracle.jdbc.OracleDriver

com.cosminexus.admin.auth.jdbc.conn.url.0=jdbc:oracle:thin:@localhost:1521:orcl

com.cosminexus.admin.auth.jdbc.conn.user.0=system

com.cosminexus.admin.auth.jdbc.conn.password.0=userpass

SQL Serverの場合

com.cosminexus.admin.auth.jdbc.driver.0=com.microsoft.sqlserver.jdbc.SQLServerDriver

com.cosminexus.admin.auth.jdbc.conn.url.0=jdbc:sqlserver://localhost:1433;DatabaseName=sqlserver

com.cosminexus.admin.auth.jdbc.conn.user.0=system

com.cosminexus.admin.auth.jdbc.conn.password.0=userpass

J2EEサーバが稼働するマシンの任意のディレクトリにJDBCドライバのJARファイルを格納します。

J2EEサーバのusrconf.cfg（オプション定義ファイル）に，手順2.で格納したJARファイルのパスを設定します。
設定例を次に示します。
add.class.path=<手順2.で格納したディレクトリ>/<JARファイル名>
なお，JARファイル名は接続するデータベースで異なります。

●注意事項

Oracleの場合，データベース側で作成するユーザ情報用のテーブルのカラム（USERIDなど）にVARCHAR2型などの可変長文字列を指定してください。CHAR型などの固定長文字列にした場合は，パスワード認証に失敗することがあります。

SQL Serverへの認証モードのうち，Windows認証は使用できません。

10.3.6　DelegationLoginModule

カスタムログインモジュールを呼び出す場合に使用するログインモジュールです。

指定されたカスタムログインモジュールに認証処理を委譲します。DelegationLoginModuleの概要を次の図に示します。

図10-16　DelegationLoginModuleの概要

jaas.conf（JAASのコンフィグレーションファイル）では，使用するカスタムログインモジュールのクラス名を指定します。DelegationLoginModuleはその内容を読み取り，カスタムログインモジュールをインスタンス化します。このとき，DelegationLoginModuleのinitializeメソッドに与えられた引数はそのままカスタムログインモジュールに渡されます。

認証処理はカスタムログインモジュールに委譲されます。

10.3.7　WebSSOLoginModule

シングルサインオンをする場合に使用するログインモジュールです。Cosminexus標準ログインモジュールまたはカスタムログインモジュールを呼び出します。

一つのセッションですでにログインしているユーザが存在する場合，別のレルムで認証するための情報（ユーザID，SecretData，PublicData）をカスタムログインモジュールに渡します。WebSSOLoginModuleの概要を次の図に示します。

図10-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を変更しません。

認証処理はカスタムログインモジュールに委譲されます。

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

ここでは，Cosminexus標準ログインモジュールによるユーザ情報リポジトリへのアクセス方法について説明します。

＜この項の構成＞

(1)　ユーザエントリの検索

(2)　接続プール

(1)　ユーザエントリの検索

LDAPディレクトリサーバをユーザ情報リポジトリとして使用する次のログインモジュールは，認証時にユーザエントリの検索ができます。

WebPasswordLoginModule

WebCertificateLoginModule

WebPasswordLDAPLoginModule

検索するかどうか，および検索範囲は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定します。なお，検索する必要があるかどうかは，LDAPディレクトリサーバのDITの構成によって決まります。

検索する必要がない場合

ユーザの認証およびユーザ属性を取得するためには，ユーザから入力されたユーザIDを基に，LDAPディレクトリサーバ上のユーザエントリを特定する必要があります。

次の図に示すように，ユーザエントリがベースDNの直下に存在し，かつユーザIDがユーザエントリのRDN（相対識別名）に含まれていれば，ユーザエントリのDNは，ベースDN，ユーザIDを表す属性名，およびユーザIDから組み立てられるため，検索は不要です。統合ユーザ管理では，このように検索が不要となるDIT構造にすることを推奨します。

図10-18　ユーザエントリがベースDNの直下に存在する場合

検索する必要がある場合

ユーザエントリのRDNにユーザIDが含まれない場合，またはユーザエントリがベースDNの直下よりも下の階層に存在する場合は，検索しないとユーザエントリを特定できません。次の図に示すようにユーザエントリがベースDNの2階層以上下層に存在する場合，検索範囲はsubtree（ベースDN以下すべての下層の検索）にする必要があります。

図10-19　ユーザエントリがベースDNの2階層以上下層に存在する場合

(2)　接続プール

Cosminexus標準ログインモジュールでは，ユーザ情報リポジトリへのアクセスを高速化するために接続プールを使用できます。

接続プールについては，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定します。

LDAP接続プールを使用できるログインモジュールを次に示します。

WebPasswordLoginModule

WebCertificateLoginModule

WebPasswordLDAPLoginModule

WebSSOLoginModule

JDBC接続プールを使用できるログインモジュールを次に示します。

WebPasswordJDBCLoginModule

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

リポジトリに格納されているパスワードの暗号の形式が標準で用意されているもの（SHA-1/MD5/平文）以外の場合でも，暗号拡張ができます。この機能が利用できるのは，WebPasswordLoginModuleとWebPasswordJDBCLoginModuleです。

パスワード認証の暗号拡張をすると，リポジトリに格納されているパスワードの暗号の形式が標準で用意されている形式以外の場合でもパスワード認証をできるようにします。この機能を使うためには，あらかじめアプリケーション開発者が実装クラスを作成する必要があります。

ログインモジュールでは，データベースから取得したパスワードと比較するためにHttpServletRequestから入力したパスワードを変換します。com.cosminexus.admin.auth.jdbc.password.encrypt.exがua.conf（統合ユーザ管理のコンフィグレーションファイル）に指定されていた場合，そのクラスの実装をインスタンス化して，HttpServletRequestから入力したパスワードを変換します。

変換したものとデータベースのパスワードを単純にbyte[]で比較し，すべての文字が一致することで認証が成功します。パスワード認証時の暗号拡張の概要を次の図に示します。

図10-20　パスワード認証時の暗号拡張の概要

実装クラスの作成方法については，「10.10　APIを使用したユーザ認証の実装」を参照してください。

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

使用するCosminexus標準ログインモジュールの種類によって，ua.conf（統合ユーザ管理のコンフィグレーションファイル）に指定する必要があるパラメタが異なります。

＜この項の構成＞

(1)　LDAPディレクトリサーバを使用するログインモジュール

(2)　データベースを使用するログインモジュール

(1)　LDAPディレクトリサーバを使用するログインモジュール

LDAPディレクトリサーバを使用する各ログインモジュールが使用するパラメタの一覧を次の表に示します。各パラメタの意味については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

表10-8　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ディレクトリサーバに接続するとき，LDAP接続プールは使用されません。

(2)　データベースを使用するログインモジュール

データベースを使用する各ログインモジュールが使用するパラメタの一覧を次の表に示します。各パラメタの意味については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

表10-9　データベースを使用する各ログインモジュールが使用するパラメタの一覧

パラメタ | 種類
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

○：使用できる

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

この節では，統合ユーザ管理で管理するセッションについて説明します。

＜この節の構成＞

10.4.1　セッションの種類

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

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

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

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

10.4.1　セッションの種類

統合ユーザ管理の機能を使う上で存在するセッションとして考えられるものには次の種類があります。

Webコンテナが管理するセッション（HttpSession）
HttpSessionオブジェクトのことを示します。

統合ユーザ管理のセッション
Cosminexus標準ログインモジュールを使用してログインしてからログアウトするまでの期間を示します。
一つのセッション内には複数のユーザがログインできるため，ログインしているすべてのユーザがログアウトしないとセッションは無効になりません。また，このセッションはWebコンテナが管理しているセッションであるHttpSessionと同期しています。そのため，HttpSessionが無効になった場合は，ログインの有無に関係なくセッションは無効になります。
統合ユーザ管理のセッションを制御する機能としては，次の2種類の機能があります。

Cosminexus標準ログインモジュールでは，ログインしたユーザIDとレルム名をセッションに自動で登録および削除できます。

統合ユーザ管理はセッションフェイルオーバ機能に対応しています。統合ユーザ管理のセッションフェイルオーバ機能を有効にすることで，ログイン状態をセッションフェイルオーバ先に引き継げます。なお，セッションフェイルオーバ機能を使用しているときに，ログイン状態を引き継ぐかどうかは選択できます。

カスタムログインモジュールのセッション
各アプリケーションが個々に持つログインしているユーザのセッションを示します。このセッションの概念は，カスタムログインモジュールの仕様に依存します（通常はログインしてからログアウトまでの期間を示します）。
なお，カスタムログインモジュールでは，ログインしたユーザIDとレルム名をセッションに自動で登録および削除できます。

10.4.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を登録時，最初にログインした時刻がユーザ単位に設定されます。

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

認証したSubjectを持つLoginContextクラスのlogoutメソッドが呼ばれたとき，自動的に統合ユーザ管理のセッションに登録されたユーザIDとレルム名が削除されます。

10.4.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 アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

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

統合ユーザ管理では，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継ぐことができます。

セッションフェイルオーバで引き継がれる情報の一覧を次の表に示します。なお，表中の「API」はJAASのAPIのことです。「カスタムタグ」は統合ユーザ管理で提供されるJSPカスタムタグのことです。

表10-10　セッションフェイルオーバ機能で引き継がれる情報一覧

情報
Cosminexus標準ログインモジュール
カスタムログインモジュール

API
カスタムタグ
API
カスタムタグ

統合ユーザ管理のセッション情報
ログイン状態
（ユーザがログインしているかどうかの状態）
◎
◎
◎
◎

登録されているユーザID/レルム名
◎
◎
◎
◎

パスワード
○
○
－
－

認証情報
Subject
×
×
×
×

Principal
×
×
×
×

ユーザ属性（UserAttributes）
△
△
－
－

ユーザ属性（UserAttributes）以外のCredential（Public/Private）
×
×
×
×

（凡例）

◎：引き継げる

○：オプションによって選択できる

△：手動で対応する必要がある

×：引き継げない

－：該当しない

なお，07-00よりも前のバージョンで作成したユーザアプリケーションをセッションフェイルオーバに対応させる場合，ユーザアプリケーションの処理の一部を見直す必要があります。セッションフェイルオーバに対応した統合ユーザ管理のアプリケーションの開発方法については，「10.12　セッションフェイルオーバ機能使用時のユーザ認証の実装」を参照してください。また，セッションフェイルオーバ機能については，「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

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

この節では，シングルサインオンの利用方法について説明します。シングルサインオンとは，一度のログイン処理で，ユーザIDが異なる複数のシステムをシームレスに使用できるようにするための機能です。

＜この節の構成＞

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

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

10.5.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サーバを起動することで利用できます。

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

利用しているアプリケーションがすでにユーザ管理を行っている場合に，統合ユーザ管理のシングルサインオンを適用するには，次の表に示す条件を満たしている必要があります。

表10-11　統合ユーザ管理のシングルサインオンの適用に必要な条件

LoginModuleの有無 | 条件1 | 条件2 | 適用 | 適用方法
ある | 改造できる。 | － | ○ | sharedStateで認証情報が渡せるようにして呼び出します。
改造できない。 | sharedStateで認証情報が渡せる。 | ○ | jaas.conf（JAASのコンフィグレーションファイル）をシングルサインオンライブラリ用に変更します。
sharedStateで認証情報が渡せない。 | × | －
ない | login用APIが公開されている。 | － | ○ | ログインモジュールを作成します。
login用APIが公開されていない。 | － | × | －

（凡例）　○：適用できる　　×：適用できない　　－：該当しない

なお，Cosminexus標準ログインモジュールのWebPasswordLoginModule，WebCertificateLoginModule，WebPasswordLDAPLoginModuleおよびWebPasswordJDBCLoginModule（ユーザ認証を行うログインモジュール）は，すべてシングルサインオンを適用できます。

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

Cosminexus標準ログインモジュール以外を使用して各アプリケーションのユーザ認証をする場合，カスタムログインモジュールを作成して，Cosminexus標準モジュールと組み合わせて使用できます。

カスタムログインモジュールは，アプリケーション開発者が実装します。

＜この節の構成＞

10.6.1　カスタムログインモジュールの概要

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

10.6.1　カスタムログインモジュールの概要

カスタムログインモジュールは，Cosminexus標準ログインモジュール以外を使用してアプリケーションのユーザ認証をしたい場合に作成するクラスです。このクラスは，JAASのSPIであるLoginModuleインタフェースを継承して作成します。

カスタムログインモジュールは，次に示すディレクトリに格納します。

Windowsの場合
<Cosminexusインストールディレクトリ>¥manager¥modules

UNIXの場合
/opt/Cosminexus/manager/modules

なお，カスタムログインモジュールの格納先ディレクトリは，ua.conf（統合ユーザ管理のコンフィグレーションファイル）の，com.cosminexus.admin.auth.custom.modulesで変更できます。

カスタムログインモジュールを格納するときの注意事項を次に示します。

カスタムログインモジュールを格納するディレクトリ内のクラスは，カスタムログインモジュール専用のクラスローダで呼び出されます。そのため，このクラスはアプリケーションで使用できません。アプリケーションで使用する場合は，カスタムログインモジュールを格納するディレクトリをusrconf.cfg（J2EEサーバ用オプション定義ファイル）のadd.class.pathキーに指定してください

カスタムログインモジュールは必ず.classファイルのまま格納してください。JARファイル形式にまとめて格納しないでください。また，クラス階層がある場合は，クラス階層構造を保ったままで，カスタムログインモジュールの格納ディレクトリに格納してください。
例を次に示します。

（例）カスタムログインモジュールのクラスが「my.login.MyLoginModule」の場合

<Cosminexusインストールディレクトリ>
　　└manager
　　　└modules
　　　　└my
　　　　　└login
　　　　　　└MyLoginModule.class

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

カスタムログインモジュールは，Cosminexus標準ログインモジュールであるDelegationLoginModuleまたはWebSSOLoginModuleのどちらかで呼び出します。

DelegationLoginModule
シングルサインオンの機能を利用しない場合に使用します。

WebSSOLoginModule
シングルサインオンの機能を利用する場合に使用します。

また，カスタムログインモジュールをCosminexus標準ログインモジュールから呼び出すことで，統合ユーザ管理が管理しているログインセッション管理に参加できます。このセッションはWebコンテナのセッション管理とは別です。統合ユーザ管理のセッションについては，「10.4　統合ユーザ管理のセッション管理」を参照してください。

カスタムログインモジュールは，DelegationLoginModuleまたはWebSSOLoginModuleのどちらかのログインモジュールから呼びされます。これらのログインモジュールは，呼び出したカスタムログインモジュールで認証が成功すると自動的に統合ユーザ管理のセッションに参加します。統合ユーザ管理のセッション登録時に必要なユーザIDは，Subjectに関連づけられているPrincipalオブジェクトから取得します。

シングルサインオン機能を使用する場合は，WebSSOLoginModuleを使用します。この場合，2回目のカスタムログインモジュールの呼び出しでは，最初に統合ユーザ管理のセッションに参加したユーザIDをキーにシングルサインオン情報リポジトリから必要な認証情報が取得されてから，カスタムログインモジュールに渡されます。リポジトリで暗号化して保存していたものは，復号化してから渡されます。

カスタムログインモジュールの実装方法については，「10.13　カスタムログインモジュールを使用したユーザ認証の実装」を参照してください。

10.7　ユーザ情報の管理

統合ユーザ管理では，ユーザ情報を管理するリポジトリとして，LDAPディレクトリサーバまたはデータベースを使用できます。この節では，LDAPディレクトリサーバでのユーザ情報の管理について説明します。

＜この節の構成＞

10.7.1　 LDAPディレクトリサーバへのユーザ情報の登録

10.7.2　 LDAPディレクトリサーバの多重化による接続フェイルオーバ

10.7.1　 LDAPディレクトリサーバへのユーザ情報の登録

LDAPディレクトリサーバを使用する場合，ユーザ情報は次に示す方法で登録できます。

LDAPディレクトリサーバが提供するコマンドによって登録する
ご使用のLDAPディレクトリサーバで提供されているコマンドを使用してください。コマンドによって，ldifファイルで定義した内容に基づいた一括登録などができます。

統合ユーザ管理APIを使用して開発したアプリケーションから登録する
ユーザ認証ライブラリおよびシングルサインオンライブラリを使用してユーザ認証を実行するアプリケーションを開発してください。統合ユーザ管理フレームワークを使用したユーザ認証の実装については，「10.9　統合ユーザ管理フレームワークによるユーザ認証の実装」を参照してください。

10.7.2　 LDAPディレクトリサーバの多重化による接続フェイルオーバ

LDAPディレクトリサーバをレプリケーションによって多重化することで，一つのLDAPディレクトリサーバへのアクセスに失敗した場合，統合ユーザ管理が提供する標準ログインモジュールはあらかじめ設定した別のLDAPディレクトリサーバにユーザ情報，シングルサインオン情報の参照先の切り替えを自動的にできます。

例えば，次の図に示す構成では，J2EEサーバ1が使用しているLDAPディレクトリサーバslave1がダウンした場合，使用するLDAPディレクトリサーバを自動的にslave2に切り替えて認証処理ができます（slave2もダウンしている場合はslave3へ切り替えます）。

図10-21　LDAPディレクトリサーバの多重化の構成例

設定されているLDAPディレクトリサーバに順番にアクセスし，すべてのサーバでアクセスが失敗した場合，認証が失敗します。

LDAPディレクトリサーバがダウンしているかどうかの判断方法を次に示します。

javax.naming.CommunicationException例外が発生します。
この例外の原因としては，接続先ホストから接続を拒否された場合などが考えられます。詳細については，JDKのドキュメントを参照してください。

リトライを実行します。
リトライは，あらかじめ設定した回数分実行されます。

リトライしてもLDAPディレクトリサーバにアクセスできない場合，ダウンしていると見なされます。

設定されているすべてのLDAPディレクトリサーバがダウンしている場合，認証は失敗し，LoginContextクラスのloginメソッドの呼び出し元にLoginException例外が発生します。

各LDAPディレクトリサーバへの接続情報は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で設定して，JAASアプリケーションごとにjaas.conf（JAASのコンフィグレーションファイル）で使用するLDAPの設定を一つ以上指定します。ua.confおよびコンフィグレーションファイルの内容の詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

また，PasswordUtilクラスによるパスワードの変更も接続フェイルオーバに対応しています。マスタサーバに対してパスワードの変更をします。次の図に示すようなマルチマスタ構成の場合に使用できます。

図10-22　LDAPディレクトリサーバの多重化の構成例（マルチマスタ構成）

なお，接続フェイルオーバをする場合，LDAPディレクトリサーバのエントリのツリー構造およびエントリの内容を同一にしてください。

10.8　統合ユーザ管理フレームワークが提供するAPI

統合ユーザ管理フレームワークでは，認証処理の呼び出し処理をするアプリケーションを開発するために，JSPのタグライブラリおよび統合ユーザ管理フレームワークのライブラリが提供されています。必要に応じて使用してください。

統合ユーザ管理フレームワークで使用するAPIの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「8.　統合ユーザ管理フレームワークで使用するAPI」を参照してください。

＜この節の構成＞

10.8.1　JSPタグライブラリ

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

10.8.1　JSPタグライブラリ

統合ユーザ管理フレームワークでは，JSPで統合ユーザ管理フレームワークの機能を容易に利用するためのJSPタグライブラリを提供します。アプリケーション開発者（またはWebデザイナ）は，Javaプログラムによる認証処理の詳細を気にすることなく，容易にJSPを開発できます。

統合ユーザ管理フレームワークのログインモジュールとしてCosminexus標準ログインモジュールを使用する場合，JSPタグライブラリを使用して，ユーザ情報を参照できます。

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

統合ユーザ管理フレームワークは，次の2種類で構成されています。

ユーザ認証ライブラリ
LDAPディレクトリサーバで構築されたユーザ情報リポジトリの情報を基にユーザ認証をして，認証したユーザの情報をアプリケーションに提供するJAAS対応ユーザ管理用ライブラリです。

シングルサインオンライブラリ
ユーザマッピング情報の入ったシングルサインオン情報リポジトリの情報を基にユーザマッピングをして，シングルサインオンを実現するライブラリです。

ユーザ認証ライブラリおよびシングルサインオンライブラリの位置づけを次に示します。

次の図に示すように，ユーザ認証ライブラリは単体でアプリケーションの認証に使用できます。また，シングルサインオンライブラリと協調動作し，マッピングされたユーザの認証をすることもあります。

図10-23　ユーザ認証ライブラリおよびシングルサインオンライブラリの位置づけ

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

統合ユーザ管理フレームワークとは，統合ユーザ管理でのユーザ認証を実現するフレームワークです。JAASに準拠したユーザ認証を，Cosminexus標準のログインモジュールとして提供します。統合ユーザ管理フレームワークを使用することで，独自に認証モジュールを開発しなくても，ユーザ認証を容易に実装できます。

統合ユーザ管理フレームワークによるユーザ認証は，APIを使用して実装します。また，ユーザ認証を容易に実装するためのタグライブラリを使用することもできます。APIまたはタグライブラリを使用してユーザ認証を実装する場合，最初に，サーブレットやJSPでユーザ認証を行うログインモジュールを呼び出します。呼び出したログインモジュールによって認証を行い，処理が終わったところでログアウトします。

Cosminexus標準のログインモジュール以外の認証モジュールを使用する場合は，カスタムログインモジュールとして作成します。ログインモジュールの種類およびログイン処理の流れについては，「10.2.3　Java標準仕様（JAAS）に準拠したユーザ認証の概要」，および「10.2.6　統合ユーザ管理の処理の流れ」を参照してください。

ここでは，APIとタグライブラリを使用したユーザ認証の実装方法，およびカスタムログインモジュールの作成方法について説明します。

参考

Cosminexusでは，統合ユーザ管理フレームワークの動作確認用のサンプルプログラムを提供します。次に示すファイルに実行手順が記述されていますので，その手順に従って実行してください。

<Cosminexusのインストールディレクトリ>¥manager¥examples¥ua¥index.html

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

APIを使用した場合のログインからログアウトまでの実装方法について説明します。また，次の内容についても説明します。

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

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

なお，統合ユーザ管理フレームワークで提供するAPIの機能や文法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」を参照してください。

＜この節の構成＞

10.10.1　ログインの実装（APIを使用する場合）

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

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

10.10.4　ログアウトの実装（APIを使用する場合）

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

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

10.10.1　ログインの実装（APIを使用する場合）

統合ユーザ管理フレームワークを使用してユーザ認証をする場合，ログイン時にサーブレットやJSPなどでログインモジュールを呼び出す処理を実装します。ログインモジュールを使用するには，JAASのコンフィグレーションファイルの設定が必要です。JAASのコンフィグレーションファイルの設定内容については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

次に，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とパスワード）を取得します。

10.10.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を取得しています。

10.10.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が設定されます。

10.10.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) { ... };
                  }
                };);
%>
...

10.10.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) {}
     }
 }
%>

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

統合ユーザ管理フレームワークで標準提供されている，パスワードの暗号の形式（SHA-1/MD5/平文）以外でも，パスワード認証ができます。この暗号拡張の機能を利用するには，あらかじめ実装クラスを作成する必要があります。

ここでは，暗号拡張できるログインモジュールと，暗号拡張で使用するクラスの実装方法について説明します。暗号拡張の概要については，「10.3.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;
 }
}

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

タグライブラリを使用した場合のログインからログアウトまでの実装方法について説明します。また，必要なファイルのコピーおよびDDでの定義についても説明します。タグライブラリのタグの説明と，タグ属性については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「9.　統合ユーザ管理フレームワークで使用するタグライブラリ」を参照してください。

＜この節の構成＞

10.11.1　ログインの実装（タグライブラリを使用する場合）

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

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

10.11.4　ログアウトの実装（タグライブラリを使用する場合）

10.11.5　uatags.jarおよびuatags.tldのコピーとDDでの定義

10.11.1　ログインの実装（タグライブラリを使用する場合）

統合ユーザ管理フレームワークを使用したユーザ認証を行う場合，ログイン時にサーブレットやJSPなどでログインモジュールを呼び出す処理を実装します。ログインモジュールを使用するには，JAASのコンフィグレーションファイルの設定が必要です。JAASのコンフィグレーションファイルの設定については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

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

10.11.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を参照するインスタンスを識別する識別子を指定します。

10.11.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が設定されます。

10.11.4　ログアウトの実装（タグライブラリを使用する場合）

ログアウトの実装例を次に示します。

<%@ taglib uri="http://cosminexus.com/admin/auth/uatags" prefix="ua" %>

<ua:logout name="lc" />
...

<ua:login/>タグに対応する<ua:logout/>タグを明示的に記述しなかった場合は，セッション切断時に暗黙的にログアウトされます。

10.11.5　uatags.jarおよびuatags.tldのコピーとDDでの定義

JSPタグライブラリを使用する場合には，ファイルのコピーや編集が必要です。

JSPタグライブラリ用のJARファイル（uatags.jar）とタグライブラリ記述子ファイル（uatags.tld）をコピーして，WebアプリケーションのDD（web.xml）を編集してください。手順を次に示します。

uatags.jarを作成するWebアプリケーションのWEB-INF¥lib（Windowsの場合），またはWEB-INF/lib（UNIXの場合）にコピーします。

uatags.tldを作成するWebアプリケーションのWEB-INFにコピーします。

web.xmlの適切な位置に次の記述を追加します。

<taglib>
 <taglib-uri>http://cosminexus.com/admin/auth/uatags</taglib-uri>
 <taglib-location>/WEB-INF/uatags.tld</taglib-location>
</taglib>

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

統合ユーザ管理では，セッションフェイルオーバ機能を使用して，障害発生時のログイン状態を別のJ2EEサーバに引き継ぐことができます。

ここでは，セッションフェイルオーバ機能で引き継げる情報，セッションフェイルオーバ機能使用時のログインとログアウトの実装方法，DDの定義方法，および実装時の注意点について説明します。

＜この節の構成＞

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

10.12.2　セッションフェイルオーバ機能使用時のログインとログアウトの実装方法

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

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

セッションフェイルオーバ機能で引き継ぐことができる情報の一覧を次の表に示します。なお，表中のAPIはJAASのAPIを，カスタムタグは統合ユーザ管理が提供するJSPカスタムタグを示します。

表10-12　セッションフェイルオーバ機能で引き継げる情報

情報
Cosminexus標準ログインモジュール
カスタムログインモジュール

API
カスタムタグ
API
カスタムタグ

統合ユーザ管理のセッション情報
ログインの状態
（ユーザがログインしているかどうか）
◎
◎
◎
◎

登録されているユーザIDおよびレルム名
◎
◎
◎
◎

パスワード
○
○
－
－

認証情報
Subject
×
×
×
×

Principal
×
×
×
×

ユーザ属性（UserAttributes）
△
△
－
－

ユーザ属性（UserAttributes）以外のCredential（Public／Private）
×
×
×
×

（凡例）

◎：引き継げます。

○：オプションによって，引き継ぐかどうかを選択できます。

△：手動で対応する必要があります。

×：引き継げません。

－：対象外となります。

10.12.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)　シングルサインオンを使用する場合の注意

同一レルムおよび同一ユーザで多重ログインするような処理にしないでください。多重ログインが発生した場合，シングルサインオンが正しく機能しないことがあります。

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

統合ユーザ管理でのセッションフェイルオーバ機能は，DD（web.xml）にフィルタ定義を追加することで有効になります。

ここでは，セッションフェイルオーバ機能を使用する場合に定義が必要な，GSInfoKey-RW（グローバルセッション情報として使用する情報（読み込み専用））とGSInfosLengthMax（グローバルセッション情報の最大サイズ）について示します。「7.12.1　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 アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

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

10.13　カスタムログインモジュールを使用したユーザ認証の実装

Cosminexus標準のログインモジュール以外の手段でユーザ認証する場合は，カスタムログインモジュールとして作成して，Cosminexus標準のログインモジュールと連携して使用します。

＜この節の構成＞

10.13.1　Cosminexus標準のログインモジュールと連携するための実装

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

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

10.13.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 アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

10.13.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のインタフェースを継承して実装してください。

10.13.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やユーザ属性を削除する処理を入れます。
       // また，login()メソッドで確保したリソースがあれば，それを解放する処理を追加します。
       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();
       // login()メソッドで確保したリソースがあれば，それを解放する処理を追加します。
       //例えば，グローバルセッションに登録した情報を削除するなど。
   }
   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(); }
}

10.14　統合ユーザ管理機能の設定手順

この節では，統合ユーザ管理機能の設定手順について説明します。

Cosminexusでは，Cosminexusで構築したシステムにログインするユーザを統合管理できます。統合ユーザ管理では，それぞれのJ2EEアプリケーションが管理しているユーザの情報が関連づけて管理され，一度のログイン処理でさまざまなJ2EEアプリケーションにログインできるようになります。統合ユーザ管理機能を使用する場合は，ユーザ認証情報を格納するLDAPディレクトリサーバや，統合ユーザ管理のコンフィグレーションファイルを設定する必要があります。

なお，統合ユーザ管理機能を使用するためには，J2EEアプリケーションの開発時に，JAASのAPIおよびCosminexusが提供している統合ユーザ管理API，ならびにJSPタグライブラリを使用して，標準ログインモジュールを呼び出す認証処理プログラムを作成しておく必要があります。また，それぞれのアプリケーションで独自の認証処理をする場合は，カスタムログインモジュールを作成する必要があります。作成方法については，「10.13　カスタムログインモジュールを使用したユーザ認証の実装」を参照してください。

統合ユーザ管理機能の設定手順を次の図に示します。

図10-24　統合ユーザ管理機能の設定手順

図中の1.～9.について説明します。

ユーザ管理方法を検討し，同一の認証ポリシーを適用する範囲（レルム）を決定します。
ユーザを管理する単位を検討し，対応するレルム名を決定します。レルム名の決定については，「10.15　レルム名の決定」を参照してください。

LDAPディレクトリサーバを設定します。
シングルサインオンを使用する場合には，シングルサインオン用のユーザ情報をLDAPディレクトリサーバで管理しますので，LDAPディレクトリサーバが必要です。LDAPディレクトリサーバの設定については，「10.16　LDAPディレクトリサーバの設定」を参照してください。
シングルサインオンを使用しないでRDB（HiRDBやOracleなど）の提供するユーザ認証だけを使用する場合は，この手順は不要です。

ユーザ認証に使用するユーザ情報をLDAPディレクトリサーバ，またはRDBに登録します。
LDAPディレクトリサーバへのユーザ情報の登録については，「10.17　ユーザ情報の登録」を参照してください。なお，Cosminexusでは，LDAPディレクトリサーバに格納するユーザ管理リポジトリの標準的なDIT構造を規定しています。リポジトリの構造については，「10.2.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。
RDBへのユーザ情報の登録については，使用しているRDBのマニュアルを参照してください。

シングルサインオンを使用する場合で，シングルサインオン用のユーザ情報を暗号化したいときは，ユーザ情報を暗号化または復号化するための暗号鍵ファイルを作成します。
暗号鍵ファイルの作成については，「10.18　暗号鍵ファイルの作成（シングルサインオンを使用する場合）」を参照してください。
シングルサインオンを使用しない場合，またはユーザ情報を暗号化しない場合，この手順は不要です。

シングルサインオンを使用する場合は，シングルサインオン用のユーザ情報をLDAPディレクトリサーバに登録します。
LDAPディレクトリサーバへのシングルサインオン用のユーザ情報の登録については，「10.19　ユーザ情報の登録（シングルサインオンを使用する場合）」を参照してください。なお，Cosminexusでは，LDAPディレクトリサーバに格納するシングルサインオン用のユーザ管理リポジトリの標準的なDIT構造を規定しています。リポジトリの構造については，「10.2.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。
シングルサインオンを使用しない場合，この手順は不要です。

コンフィグレーションファイルを作成します。
作成するファイルは，次の2種類です。

jaas.conf（JAASのコンフィグレーションファイル）

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

コンフィグレーションファイルの作成については，「10.20　コンフィグレーションファイルの作成」を参照してください。

JavaVMのプロパティを設定します。
JavaVMのプロパティの設定については，「10.21　JavaVMのプロパティの設定」を参照してください。

統合ユーザ管理で使用するEARファイルをデプロイします。
ファイルのデプロイについては，「10.22　ファイルのデプロイ」を参照してください。

必要に応じて，統合ユーザ管理で使用する情報のバックアップを取ります。
LDAPディレクトリサーバのリポジトリのバックアップとリストアは，LDAPディレクトリサービスが提供するコマンド，またはディレクトリゲートウェイで操作します。詳細については，LDAPディレクトリサーバのマニュアルを参照してください。
jaas.conf，ua.conf，および暗号鍵ファイルのバックアップも取るようにしてください。

参考

統合ユーザ管理では，セッションフェイルオーバ機能を使用することで，ログイン状態を別のJ2EEサーバに引き継ぐことができます。セッションフェイルオーバ機能を使用するためのセッションフェイルオーバ用フィルタの設定は，統合ユーザ管理機能を使用する場合と使用しない場合で異なります。設定方法については，「7.12　DDでの定義」の統合ユーザ管理機能を使用する場合の設定を参照してください。

10.15　レルム名の決定

ユーザを管理する単位を検討し，対応するレルム名を決定してください。この名称は，JAAS対応ユーザ管理の認証時に使用します。jaas.conf（JAASのコンフィグレーションファイル）内の該当するログインモジュールのオプションとして指定します。通常は，「SoumuSystem」のような，ユーザ管理を共有しているアプリケーション群を表すわかりやすい名称を使用します。

10.16　LDAPディレクトリサーバの設定

この節では，LDAPディレクトリサーバの設定について説明します。

LDAPディレクトリサーバの設定手順を次に示します。

LDAPディレクトリサーバを設置します。
詳細については，「10.16.1　LDAPディレクトリサーバの設置」を参照してください。

LDAPディレクトリサーバにユーザを登録して，アクセス権を設定します。
詳細については，「10.16.2　ユーザの登録とアクセス権の設定」を参照してください。

シングルサインオンを使用する場合は，シングルサインオンライブラリ固有のオブジェクトクラスとユーザ定義属性をLDAPディレクトリサーバに登録して，オブジェクトクラスとユーザ属性定義を拡張します。
詳細については，「10.16.3　オブジェクトクラスとユーザ定義属性の拡張」を参照してください。

＜この節の構成＞

10.16.1　LDAPディレクトリサーバの設置

10.16.2　ユーザの登録とアクセス権の設定

10.16.3　オブジェクトクラスとユーザ定義属性の拡張

10.16.1　LDAPディレクトリサーバの設置

Cosminexusでは，ユーザ情報を管理するリポジトリとして，LDAPディレクトリサーバを使用できます。LDAPディレクトリサーバをインストールして初期設定をしてください。インストールと初期設定については，使用しているLDAPディレクトリサーバのマニュアルを参照してください。

使用できるLDAPディレクトリサーバの例を次に示します。なお，使用できるLDAPディレクトリサーバの詳細については「リリースノート」でご確認ください。

使用できるLDAPディレクトリサーバの例

Sun Java System Directory Server

IBM SecureWay Directory（またはIBM Directory Server）

Active Directory

すでにLDAPディレクトリサーバを使用している場合には，LDAPディレクトリサーバで使用中のスキーマを参照して，シングルサインオン固有のスキーマが使用されていないことを確認してください。詳細については，「10.16.3　オブジェクトクラスとユーザ定義属性の拡張」を参照してください。

10.16.2　ユーザの登録とアクセス権の設定

統合ユーザ管理でLDAPディレクトリに接続（バインド）するために，管理用および参照用のユーザを登録してアクセス権を設定してください。

管理用ユーザのDNのことを管理用のバインドDN，参照用ユーザのDNのことを参照用のバインドDNといいます。

管理用のバインドDNは，統合ユーザ管理フレームワークで使用するベースエントリ以下すべてのエントリ，およびエントリに設定されたすべての属性に対して，すべてのアクセス権（Read，Write，Add，Delete，Search，Compare，Selfwrite）を持つバインドDNです。管理用のバインドDNは，LDAPディレクトリサーバ上のユーザ管理情報を登録，参照，変更，および削除するときに使用します。

参照用のバインドDNは，統合ユーザ管理フレームワークで参照するベースエントリ以下すべてのエントリ，およびエントリに設定されたすべての属性に対して，ReadとSearchのアクセス権を持つバインドDNです。参照用のバインドDNは，LDAPディレクトリサーバからユーザ情報などを取得するときに使用します。

10.16.3　オブジェクトクラスとユーザ定義属性の拡張

シングルサインオンを使用する場合は，シングルサインオンライブラリ固有のオブジェクトクラスとユーザ定義属性をLDAPディレクトリサーバに登録して，オブジェクトクラスとユーザ定義属性を拡張してください。

なお，拡張するオブジェクトクラスとユーザ定義属性の属性はシングルサインオンライブラリ固有のスキーマで，ほかのシステムとは共有できません。すでにLDAPディレクトリサーバを使用している場合は，LDAPディレクトリサーバで使用中のスキーマを参照し，シングルサインオン固有のスキーマが使用されていないことを確認してください。

＜この項の構成＞

(1)　シングルサインオンライブラリで拡張するオブジェクトクラス

(2)　シングルサインオンライブラリで拡張するユーザ定義属性

(3)　拡張するオブジェクトクラスおよびユーザ定義属性の追加手順

(1)　シングルサインオンライブラリで拡張するオブジェクトクラス

シングルサインオンライブラリ固有のオブジェクトクラスを次の表に示します。

表10-13　シングルサインオンライブラリ固有のオブジェクトクラス

オブジェクトクラス
OID
必須属性
任意属性

CosminexusSSOEntry
1.2.392.200010.7.6.21
objectClass,
CosminexusSSOEntryID,
CosminexusSSOUID
CosminexusSSOSecretdata,
CosminexusSSOPublicdata,
CosminexusSSOMapping

(2)　シングルサインオンライブラリで拡張するユーザ定義属性

シングルサインオンライブラリ固有の属性を次の表に示します。

表10-14　シングルサインオンライブラリ固有の属性

属性 | OID | シンタックス | マルチバリュー／シングルバリュー
CosminexusSSOEntryID | 1.2.392.200010.7.4.71 | cis | シングルバリュー
CosminexusSSOUID | 1.2.392.200010.7.4.72 | ces | シングルバリュー
CosminexusSSOSecretdata | 1.2.392.200010.7.4.73 | bin | シングルバリュー
CosminexusSSOPublicdata | 1.2.392.200010.7.4.74 | ces | シングルバリュー
CosminexusSSOMapping | 1.2.392.200010.7.4.75 | dn | マルチバリュー

(3)　拡張するオブジェクトクラスおよびユーザ定義属性の追加手順

拡張するオブジェクトクラスおよびユーザ定義属性の追加手順について，LDAPディレクトリサーバの種類ごとに説明します。

Sun Java System Directory ServerまたはOracle Directory Server Enterprise Editionの場合

LDAPディレクトリサーバが起動していることを確認し，uaschema.slapd.ldifを次のコマンドでLDAPディレクトリサーバに登録してください。

ldapmodify -h <ホスト名> -p <ポート番号> -D <管理用のバインドDN> -w <パスワード> -c -f uaschema.slapd.ldif

IBM SecureWay DirectoryまたはIBM Directory Serverの場合

LDAPディレクトリサーバが起動していることを確認し，uaschema.ldifを次のコマンドでLDAPディレクトリサーバに登録してください。

ldapmodify -h <ホスト名> -p <ポート番号> -D <バインドDN> -w <パスワード> -c -f uaschema.ldif

ここで，指定するバインドDNは管理者権限を持っている必要があります。

Active Directoryの場合

Active Directoryでスキーマ修正ができるように設定を変更します。Microsoft管理コンソール（mmc.exe）を起動して，「スナップインの追加と削除」でActive Directoryスキーマを追加してください。「Active Directoryスキーマ」を右クリックして「操作マスタ」を選択し，「このドメインコントローラでスキーマの修正が可能」をチェックして［OK］ボタンをクリックしてください。

次のコマンドでuaschema.ad.ldifをActive Directoryに登録してください（ログオン先のドメインのドメインコントローラに現在ログオンしているユーザとして接続する場合です）。

　　 ldifde -i -c "dc=domain" "<ToDN>" -f uaschema.ad.ldif

ここで，ToDNにはドメインによって異なる適切なDNを指定してください。例えば，ドメインが「hitachi.co.jp」の場合，ToDNは「dc=hitachi,dc=co,dc=jp」となります。

10.17　ユーザ情報の登録

この節では，LDAPディレクトリサーバへのユーザ情報の登録方法と，登録するユーザ情報の文法について説明します。RDBへのユーザ情報の登録方法については，使用しているRDBのマニュアルを参照してください。

なお，Cosminexusでは，LDAPディレクトリサーバに格納するユーザ管理リポジトリの標準的なDIT構造を規定しています。リポジトリの構造については，「10.2.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。

ユーザ情報をユーザ情報リポジトリに登録する方法には，次の2種類があります。

コマンドによる登録

統合ユーザ管理フレームワークのライブラリによる登録

それぞれの登録方法について説明します。また，登録するユーザ情報の文法，およびActive Directoryを使用する場合の設定についても説明します。

＜この節の構成＞

10.17.1　コマンドによる登録

10.17.2　統合ユーザ管理フレームワークのライブラリによる登録

10.17.3　登録するユーザ情報の文法

10.17.4　Active Directoryを使用する場合の設定

10.17.1　コマンドによる登録

Cosminexusが提供するコマンドとLDAPディレクトリサーバが提供するコマンドを使用してユーザ情報を登録する場合の手順を次に示します。

ユーザ情報を，LDIFファイルに記述します。

convpwコマンドでLDIFファイル中のパスワードを暗号化します。
LDIFファイル中に指定されたパスワードが暗号化されます。convpwコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「convpw（パスワードの暗号化）」を参照してください。

暗号化したLDIFファイルを，LDAPディレクトリサーバが提供するldapmodifyコマンドでユーザ情報リポジトリに登録します。

また，LDAPディレクトリサーバが提供するGUIでユーザ情報を登録できる場合もあります。詳細については，使用しているLDAPディレクトリサーバのマニュアルを参照してください。

10.17.2　統合ユーザ管理フレームワークのライブラリによる登録

ユーザ認証ライブラリが提供するAPIを使用してアプリケーションを作成し，そのアプリケーションを使用してユーザ情報を登録します。

APIを利用するアプリケーションは，最初にLdapUserDataManagerオブジェクトを生成します。このクラスのコンストラクタにはLDAPディレクトリサーバの定義識別子を指定します。定義識別子は，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で指定します。定義識別子にはLDAPディレクトリサーバのURL，バインドDN，バインドDNのパスワード，ベースDNなどが関連づけられています。なお，LdapUserDataManagerオブジェクトは定義ごとに一つ生成するようにしてください。

なお，LDAPディレクトリサーバとしてActive Directoryを使用して，ユーザの登録，ユーザ情報の更新，およびリポジトリ情報のパスワードの変更をする場合の方法については，「10.17.4　Active Directoryを使用する場合の設定」を参照してください。

ユーザ認証の実装については，「10.10　APIを使用したユーザ認証の実装」を参照してください。また，統合ユーザ管理フレームワークで使用するAPIについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「8.　統合ユーザ管理フレームワークで使用するAPI」を参照してください。

10.17.3　登録するユーザ情報の文法

ユーザ情報は，次の表に示す文法に従って登録してください。

表10-15　ユーザ情報の文法

情報の種類
意味
文法

ユーザID
ユーザの識別子。
英数字列。
長さは1～512（単位：文字）。

パスワード
ユーザに対応するパスワード。
英数字列および特殊文字。
長さは0～512（単位：文字）。

注1　英数字列は，英字（A～Z，a～z）と数字（0～9）の文字の並びを意味します。

注2　特殊文字は，次の記号を意味します。

（空白）｜!｜"｜#｜$｜%｜&｜'｜(｜)｜*｜+｜,｜-｜.｜/｜:｜;｜<｜=｜>｜?｜@｜[｜¥｜]｜^｜_（アンダースコア）｜`｜{｜}｜|（垂直バー）｜~

注3　「文法」欄で明記されていない場合は，英字の大文字と小文字の区別をします。

注4　ASCII文字列で指定してください（文法については，プログラムではチェックしていません）。

注5　パスワードを平文でリポジトリに格納する場合，空文字（""）をパスワードとして使用しないでください。使用した場合，そのユーザはログインできなくなることがあります。パスワードとして空文字を使用したい場合は，SHA-1などによる暗号化をしてください。

10.17.4　Active Directoryを使用する場合の設定

LDAPディレクトリサーバとしてActive Directoryを使用する場合の設定方法について説明します。

統合ユーザ管理フレームワークのライブラリを使用して，ユーザ情報リポジトリへのユーザの登録，ユーザ情報の更新（ユーザのパスワード変更を含む）を行う場合，Active Directory固有の環境設定，およびSSLを使用して接続するための証明書の登録が必要です。

LDAPディレクトリサーバとしてActive Directoryを使用する場合の設定項目を，次の表に示します。なお，使用するユーザ認証方式によって設定する項目が異なります。

表10-16　Active Directoryを使用する場合の設定項目一覧

設定項目 | パスワード認証 | パスワード変更およびユーザの追加・変更 | クライアント認証（X509証明書）
jaas.confの設定 | 必要なログインモジュールの指定 | ○ | ○ | ○
ログインモジュールのオプションの指定 | △ | ○ | －
ua.confの設定 | ユーザ識別属性の指定 | ○ | ○ | ○
DNでユーザIDとして使用する属性名の指定 | － | － | ○
パスワード属性の指定 | ○ | ○ | －
LDAPディレクトリサーバの種類の指定 | ○ | ○ | －
日本語など2バイト文字を含むDNの変換 | △ | △ | △
URLプロトコルの変更 | △ | ○ | △
SSL接続の設定 | △ | ○ | △

（凡例）

○：必ず設定する

△：必要に応じて設定する

－：設定しない（設定しても無視される）

注※　パスワードの設定やユーザの追加・変更を実施する場合を示します。

Active Directory固有の環境設定の方法，およびSSLを使用して接続するための証明書の登録を次に示します。

ポイント

Active Directoryで管理するユーザは，ほかのLDAPディレクトリサーバで管理するユーザと，オブジェクトクラス，属性が大きく異なります。統合ユーザ管理フレームワークのライブラリを使用する場合には，オブジェクトクラスに「user」を使用します，その「user」を作成する場合には，「cn」，「unicodePwd」，「sAMAccountName」，および「userAccountControl」の属性を指定します。

「sAMAccountName」には，セキュリティアカウントマネージャ（SAM）のアカウント名を指定します。なお，通常，アカウント名はユーザIDと同じ値を指定します。

「userAccountControl」には，ユーザアカウントのプロパティフラグを指定します。一般ユーザのユーザエントリを作成する場合は「512」を指定します。ただし，Active Directoryがインストールされているサーバのセキュリティポリシーで，パスワードの長さが1文字以上に設定されている場合，「userAccountControl」に「512」を指定すると，ユーザを作成できません。この場合は，次のどちらかの対処をして，ユーザエントリを作成してください。

セキュリティポリシーのパスワードの長さを0文字以上に変更して，「userAccountControl」に「512」を指定する。

セキュリティポリシーのパスワードの長さの設定を変更しないで，「userAccountControl」に「544」を指定する。

＜この項の構成＞

(1)　jaas.confの設定

(2)　ua.confの設定

(3)　SSL接続の設定

(4)　注意事項

(1)　jaas.confの設定

jaas.confに設定する内容について説明します。

(a)　ログインモジュールの設定

認証方式にパスワード認証を使用する場合はWebPasswordLDAPLoginModule，クライアント証明を使用する場合はWebCertificateLoginModuleを設定します。

(b)　ログインモジュールのオプションの指定（パスワード認証を使用する場合）

WebPasswordLDAPLoginModuleのオプションに「ldap.w」を設定します。なお，SSOを使用する場合は「sso.ldap.w」を設定します。

(2)　ua.confの設定

ua.confに設定する内容について説明します。

(a)　ユーザ識別属性の指定

ユーザ識別属性に，「cn」（フルネームに該当）または「sAMAccountName」「（ユーザログオン名（Windows2000以前）」に該当）を設定します。

設定例を次に示します。

（例1）「cn」をユーザ識別属性に使用する場合

com.cosminexus.admin.auth.ldap.attr.userid.0=cn

（例2）「sAMAccountName」をユーザ識別属性に使用する場合

com.cosminexus.admin.auth.ldap.attr.userid.0=sAMAccountName

ユーザ識別属性を「sAMAccountName」に設定した場合リポジトリのユーザエントリ（RDN）の検索が必要となります。検索に必要なプロパティとその設定例を次に示します。

（例）

java.naming.security.principal.0=cn=Administrator,cn=Users,dc=cosminexus,dc=com
java.naming.security.credentials.0=adminpassword
com.cosminexus.admin.auth.ldap.search.userrdn.0=true
com.cosminexus.admin.auth.ldap.search.scope.0=onelevel

なお，「sAMAccountName」をユーザ識別属性に使用する場合は，LdapUserDataManagerクラスのaddUserData(String uid, UserData userData)メソッドは使用できません。ユーザを追加する場合は addUserData(String uid, UserData userData, String name, String value)メソッドを使用してください。また，属性名の引数（String name）には，「cn」を設定してください。

(b)　DNでユーザIDとして使用する属性名の指定（クライアント証明書を使用する場合）

クライアント証明書を使用する場合は，クライアント証明書に格納されているDN（クライアント証明書の被認証者識別名）を分解したあと，ユーザIDとして使用する属性名を設定します。設定例を次に示します。

（例）

com.cosminexus.admin.auth.ldap.certificate.attr.userid.0=cn

ここで指定する属性名は，「(a)　ユーザ識別属性の指定」で指定するユーザ識別属性とは異なります。

(c)　パスワード属性の指定（パスワード認証を使用する場合）

パスワード属性に「unicodePwd」を設定します。設定例を次に示します。

（例）

com.cosminexus.admin.auth.ldap.attr.password.0=unicodePwd

(d)　LDAPディレクトリサーバの種類の指定（パスワード認証を使用する場合）

接続先のLDAPディレクトリサーバの種類に「AD」を指定した行を追加します。LDAP設定番号が「0」の場合の設定例を次に示します。

（例）

com.cosminexus.admin.auth.ldap.directory.kind.0=AD

(e)　日本語など2バイト文字を含むDNの変換

ua.confの次のパラメタに，日本語など2バイト文字を含むDNを設定する場合は，native2asciiコマンドを使用してUnicodeコードに変換してください。

java.naming.security.principal

com.cosminexus.admin.auth.ldap.basedn

native2asciiコマンドの実行形式を次に示します。

実行形式

<Cosminexusインストールディレクトリ>¥jdk¥bin¥native2ascii <変換前のua.confファイル> <変換後のua.confファイル>

変換後のua.confファイルを統合ユーザ管理のコンフィグレーションファイルとして使用します。

コード変換の例を次に示します。

（例）

DNを設定したua.confファイル「ua0.conf」の変換手順を次に示します。

java.naming.security.principal.0=cn=Administrator,cn=管理者,dc=cosminexus,dc=co
com.cosminexus.admin.auth.ldap.basedn.0=cn=ユーザ,dc=cosminexus,dc=com

ua0.confに対し，次のnative2asciiコマンドを実行します。

native2ascii ua0.conf ua.conf

(f)　URLプロトコルの変更

接続先のLDAPディレクトリサーバのURLのプロトコルに「ldaps」を設定します。設定例を次に示します。なお，ポート番号は省略できます。

（例）

変更前：java.naming.provider.url.0=ldap://localhost:389

変更後：java.naming.provider.url.0=ldaps://localhost:636

(3)　SSL接続の設定

J2EEサーバとActive Directory間の通信でSSLを使用するための証明書を登録します。証明書の登録方法を次に示します。

作成したデジタル証明書を，Active Directoryがインストールされているサーバ（LDAPサーバ）に登録します。
デジタル証明書の作成，登録方法については，Active Directoryのドキュメントを参照してください。

認証局（CA）の証明書を，J2EEサーバに登録します。
認証局の証明書のJ2EEサーバへの登録は，Cosminexus Developer's Kit for Javaに付属するkeytoolを使用して実行できます。keytoolの詳細については，Java 2 SDK, Standard Editionのドキュメントを参照してください。keytoolの実行例を次に示します。なお，表記の都合上，複数行にわたっていますが，実際は一行で記述します。
Windowsの場合

keytool -import -alias cakey -file C:¥temp¥cacer.cer -trustcacerts -keystore
"<Cosminexusのインストールディレクトリ>¥jdk¥jre¥lib¥security¥cacerts"

UNIXの場合

/opt/Cosminexus/jdk/bin/keytool -import -alias cakey -file /tmp/cacer.cer
-trustcacerts -keystore /opt/Cosminexus/jdk/jre/lib/security/cacerts

なお，keytoolで証明書を登録する際にJ2EEサーバを起動していた場合は，J2EEサーバを再起動してください。

(4)　注意事項

注意事項を次に示します。

ua.confでユーザのパスワードを表す属性値として「unicodePwd」を指定した場合，パスワード形式オプション「password.encrypt」および「password.encrypt.ex」の設定は無効になります。

Active Directoryでは，既存ユーザエントリのオブジェクトクラスの変更はサポートしていません。ua.confに「com.cosminexus.admin.auth.ldap.directory.kind.0=AD」を指定した場合，LdapUserDataManagerクラスのコンストラクタで新規にオブジェクトを追加したあとで，既存のユーザエントリを更新しても，ユーザエントリ作成時のオブジェクトクラスが適用されます。

10.18　暗号鍵ファイルの作成（シングルサインオンを使用する場合）

この節では，シングルサインオン用のユーザ情報を暗号化または復号化するための暗号鍵ファイルの作成と変更について説明します。ユーザ情報を暗号化しない場合，暗号鍵ファイルの作成は不要です。

シングルサインオン用のユーザ情報を暗号化する場合は，暗号鍵ファイルで暗号化してLDAPディレクトリサーバに格納します。また，ユーザ情報を参照するためには，暗号鍵ファイルで復号化して参照します。ユーザ情報を暗号化する場合は，LDAPディレクトリサーバに登録する前に，暗号鍵ファイルを作成してください。

＜この節の構成＞

10.18.1　暗号鍵ファイルの作成

10.18.2　暗号鍵ファイルの変更

10.18.1　暗号鍵ファイルの作成

シングルサインオン用のユーザ情報を暗号化または復号化するための暗号鍵ファイルは，ssogenkeyコマンドで作成します。なお，作成した暗号鍵ファイルは，システム管理者が安全な場所に保管してください。

また，シングルサインオン用のユーザ情報を暗号化または復号化するためには，ua.conf（統合ユーザ管理のコンフィグレーションファイル）で，使用する暗号エンジンに「JCE」を指定する必要があります。

ssogenkeyコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ssogenkey（暗号鍵ファイルの作成）」を参照してください。ua.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

10.18.2　暗号鍵ファイルの変更

シングルサインオン用のユーザ情報は登録済みで，暗号鍵ファイルを変更する場合は，次の手順で変更してください。暗号鍵ファイルを変更する手順を次に示します。

ssoexportコマンドでシングルサインオン情報リポジトリの内容をすべて取り出します。

ssogenkeyコマンドを実行して，暗号鍵ファイルを作成します。

ssoimportコマンドで，1.で取り出した内容を登録します。

ssoexportコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ssoexport（シングルサインオン情報リポジトリの参照）」を参照してください。ssogenkeyコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ssogenkey（暗号鍵ファイルの作成）」を参照してください。ssoimportコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ssoimport（シングルサインオン情報リポジトリの登録）」を参照してください。

10.19　ユーザ情報の登録（シングルサインオンを使用する場合）

この節では，LDAPディレクトリサーバへのシングルサインオン用のユーザ情報の登録方法と，登録するユーザ情報の文法について説明します。

なお，Cosminexusでは，LDAPディレクトリサーバに格納するシングルサインオン用のユーザ管理リポジトリの標準的なDIT構造を規定しています。リポジトリの構造については，「10.2.4　統合ユーザ管理で使用するユーザ情報の管理方法」を参照してください。

シングルサインオン用のユーザ情報をシングルサインオン情報リポジトリに登録する方法には，次の2種類があります。

コマンドによる登録

統合ユーザ管理フレームワークのライブラリによる登録

それぞれの登録方法について説明します。また，登録するユーザ情報の文法についても説明します。

＜この節の構成＞

10.19.1　コマンドによる登録

10.19.2　統合ユーザ管理フレームワークのライブラリによる登録

10.19.3　登録するユーザ情報の文法

10.19.1　コマンドによる登録

シングルサインオン用のユーザ情報をCSV形式ファイルで作成して，Cosminexusが提供するssoimportコマンドを使用してシングルサインオン情報リポジトリに登録します。

ssoimportコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「ssoimport（シングルサインオン情報リポジトリの登録）」を参照してください。CSV形式ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.4　シングルサインオン用認証情報のCSV形式ファイル」を参照してください。

10.19.2　統合ユーザ管理フレームワークのライブラリによる登録

シングルサインオンライブラリが提供するAPIを使用してアプリケーションを作成し，そのアプリケーションを使用してユーザ情報を登録します。

APIを利用するアプリケーションは，最初にLdapSSODataManagerオブジェクトを生成します。このクラスのコンストラクタにはレルム名を指定します。なお，LdapSSODataManagerオブジェクトは定義ごとに一つ生成するようにしてください。

シングルサインオン情報リポジトリの内容をAPIで更新した場合に，それを通知するシングルサインオン用認証情報リスナクラスを実装すれば，シングルサインオン情報リポジトリの更新に同期して接続先システムのリポジトリの更新もできます。

ユーザ認証の実装については，「10.10　APIを使用したユーザ認証の実装」を参照してください。また，統合ユーザ管理フレームワークで使用するAPIについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「8.　統合ユーザ管理フレームワークで使用するAPI」を参照してください。

10.19.3　登録するユーザ情報の文法

シングルサインオン用のユーザ情報は，次の表に示す文法に従って登録してください。

表10-17　シングルサインオン用のユーザ情報の文法

情報の種類
意味
文法

レルム名
ユーザ管理の範囲を示す識別子です。
英数字列。
大文字と小文字を区別しません。
DN名で使用できる名前を付けてください。

ユーザID
ユーザ管理機能を持つアプリケーションの使用者を表すユーザの識別子です。
英数字列。
長さは1～512（単位：文字）。

SecretData
ユーザ管理機能を持つアプリケーションのユーザIDに対応したパスワードなどの暗号化が必要な認証情報のことです。ユーザを認証するために使用する値を指定します。ここに指定された値は，暗号化されて保存されます。
英数字列および特殊文字。
長さは0～512（単位：文字）。

PublicData
ユーザ管理機能を持つアプリケーションが，ユーザの認証を行う際に，ユーザIDおよびSecretData以外で必要な認証情報のことです。ここに指定された値は，暗号化されません。
英数字列および特殊文字。
長さは0～512（単位：文字）。

注１　英数字列は，英字（A～Z，a～z）と数字（0～9）の文字の並びを意味します。

注２　特殊文字は，次の記号を意味します。

（空白）｜!｜"｜#｜$｜%｜&｜'｜(｜)｜*｜+｜,｜-｜.｜/｜:｜;｜<｜=｜>｜?｜@｜[｜¥｜]｜^｜_（アンダースコア）｜`｜{｜}｜|（垂直バー）｜~

注３　「文法」欄で明記されていない場合は，英字の大文字と小文字の区別をします。

注４　ASCII文字列で指定してください。文法については，プログラムではチェックしていません。

10.20　コンフィグレーションファイルの作成

この節では，次の二つのコンフィグレーションファイルの作成，およびコンフィグレーションファイルの設定例を説明します。

jaas.conf（JAASのコンフィグレーションファイル）

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

＜この節の構成＞

10.20.1　jaas.confの作成

10.20.2　ua.confの作成

10.20.3　コンフィグレーションファイルの設定例

10.20.1　jaas.confの作成

jaas.confには，ユーザ認証ライブラリまたはシングルサインオンライブラリが使用する情報として，アプリケーション単位に，使用するログインモジュール名，ua.confで指定したリポジトリ（LDAPディレクトリサーバまたはRDB）の設定番号などを指定します。

＜この項の構成＞

(1)　格納場所

(2)　指定内容

(3)　jaas.confの再読み込み

(1)　格納場所

jaas.confの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥jaas.conf

UNIXの場合
/opt/Cosminexus/manager/config/jaas.conf

このjaas.confを上書きするか，任意の場所にコピーして使用してください。jaas.confの格納場所は，JavaVM起動時のプロパティで指定してください。JavaVM起動時のプロパティの指定については，「10.21　JavaVMのプロパティの設定」を参照してください。

また，Component Container管理者がファイルを参照できるようにjaas.confのアクセス権を変更してください。Component Container管理者の設定については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.2.3　Component Container管理者の設定（UNIXの場合）」を参照してください。

(2)　指定内容

アプリケーション単位に次の情報を指定してください。

ユーザ認証ライブラリを使用してユーザ認証する場合

定義するログインモジュールはWebPasswordLoginModuleにしてください。このWebPasswordLoginModuleのオプションには，ua.confで定義しているリポジトリで定義したLDAP設定番号とレルム名を定義します。

WebPasswordLoginModuleとカスタムログインモジュールの連携をする場合，ログインモジュールの定義はDelegationLoginModuleにしてください。このDelegationLoginModuleのオプションに呼び出すカスタムログインモジュール名を定義します。

シングルサインオンライブラリを使用してユーザ認証する場合

定義するログインモジュールはWebSSOLoginModuleにしてください。このWebSSOLoginModuleのオプションには，ua.confで定義しているカスタムログインモジュールの識別子とレルム名を定義します。

なお，LDAPディレクトリサーバとしてActive Directoryを使用する場合のjaas.confの設定については，「10.17.4　Active Directoryを使用する場合の設定」を参照してください。

jaas.confについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　jaas.conf（JAASのコンフィグレーションファイル）」を参照してください。

(3)　jaas.confの再読み込み

Management Serverの運用管理コマンドであるmngsvrutilコマンドを使用すると，J2EEサーバを再起動しないで，jaas.confの再読み込みができます。J2EEサーバを再起動しないで，ログインモジュールで使用するLDAP設定番号を変更したい場合などに利用します。

なお，mngsvrutilコマンドを使用するためには，Management Serverが起動されていて，適切に設定済みである必要があります。

jaas.confの再読み込みの流れを次の図に示します。

図10-25　jaas.confの再読み込みの流れ

mngsvrutilコマンドについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

10.20.2　ua.confの作成

ua.confには，ユーザ認証ライブラリまたはシングルサインオンライブラリが使用する情報として，リポジトリ（LDAPディレクトリサーバまたはRDB）へのアクセス情報，シングルサインオン用のユーザ情報を暗号化または復号化するための暗号鍵ファイルのパスなどを指定します。

＜この項の構成＞

(1)　格納場所

(2)　指定内容

(3)　パスワードの変更とスクランブル化

(1)　格納場所

ua.confの格納場所を次に示します。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config¥ua.conf

UNIXの場合
/opt/Cosminexus/manager/config/ua.conf

このua.confを上書きするか，任意の場所にコピーして使用してください。ua.confの格納場所は，JavaVM起動時のプロパティで指定します。JavaVM起動時のプロパティの指定については，「10.21　JavaVMのプロパティの設定」を参照してください。

また，Component Container管理者がファイルを参照できるようにua.confのアクセス権を変更してください。Component Container管理者の設定については，マニュアル「Cosminexus アプリケーションサーバ システム構築・運用ガイド」の「7.2.3　Component Container管理者の設定（UNIXの場合）」を参照してください。

(2)　指定内容

ユーザ認証ライブラリの機能を使用したユーザ認証およびシングルサインオンライブラリの機能を使用したシングルサインオンをするために，LDAPディレクトリサーバのURLやベースDN，アクセス権を設定してください。

シングルサインオンライブラリの機能を使用してシングルサインオンをする場合には，暗号化するための製品の選択，および暗号鍵ファイル名の指定をしてください。また，シングルサインオンの機能から呼び出すログインモジュールがカスタムログインモジュールの場合，カスタムログインモジュール名，およびカスタムログインモジュールと関連するクラスのクラスファイルを格納しているディレクトリを定義してください。

なお，LDAPディレクトリサーバとしてActive Directoryを使用をする場合のua.confの設定については，「10.17.4　Active Directoryを使用する場合の設定」を参照してください。

ua.confの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.3　ua.conf（統合ユーザ管理のコンフィグレーションファイル）」を参照してください。

(3)　パスワードの変更とスクランブル化

ua.confに指定したLDAPディレクトリサーバやRDBに接続するためのパスワードを変更したい場合には，ua.confを編集するほかに，uachpwコマンドを使用して変更できます。uachpwコマンドを使用してLDAPディレクトリサーバやRDBに接続するためのパスワードを変更する場合に，-scrambleオプションを指定すると，パスワードのスクランブル化もできます。

なお，uachpwコマンドでパスワードをスクランブル化する場合には，必ず簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内にcom.cosminexus.admin.auth.passwordScramble.enableキーを指定して，スクランブル化されたパスワードの復号化機能を有効にしておいてください。

参考

運用管理ポータルで構築したシステムの場合の説明については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.5　統合ユーザ管理の設定」を参照してください。

10.20.3　コンフィグレーションファイルの設定例

ここでは，次の図に示すディレクトリ構成を持つユーザ情報の設定例を示します。

図10-26　ユーザ情報のディレクトリ構成の例

＜この項の構成＞

(1)　jaas.confの設定例

(2)　属性の一覧の設定例

(3)　ua.confの設定例

(4)　シングルサインオンへの対応例（標準ログインモジュールの場合）

(5)　シングルサインオンへの対応例（カスタムログインモジュールの場合）

(1)　jaas.confの設定例

jaas.confには，ユーザを認証するための情報を設定します。使用するログインモジュール名，ua.confで指定したリポジトリ（LDAPディレクトリサーバまたはRDB）の設定番号などを指定します。jaas.confの設定例を次の図に示します。

図10-27　jaas.confの設定例

(2)　属性の一覧の設定例

属性の一覧には，そのユーザで認証が成功した際に取得するユーザの情報（属性名）と参照に使用する別名（Alias）を指定します。属性の一覧の設定例（c:¥RealmA¥config¥AliasFile.csv（Windowsの場合），または/tmp/RealmA/config/AliasFile.csv（UNIXの場合））を次の図に示します。

図10-28　属性の一覧の設定例

なお，ファイルを作成しなくても，プログラム中で直接AttributeEntryクラスを使用して指定することもできます。

(3)　ua.confの設定例

ua.confには，リポジトリ（LDAPディレクトリサーバまたはRDB）へのアクセス情報などを設定します。ua.confの設定例を次の図に示します。

図10-29　ua.confの設定例（Windowsの場合）

図10-30　ua.confの設定例（UNIXの場合）

認証用プログラムのコーディング例を次の図に示します。

図10-31　認証用プログラムのコーディング例（Windowsの場合）

図10-32　認証用プログラムのコーディング例（UNIXの場合）

(4)　シングルサインオンへの対応例（標準ログインモジュールの場合）

ユーザ認証ライブラリのログインモジュールをシングルサインオンに対応させるには，jaas.confを変更する必要があります。シングルサインオンへの対応例（標準ログインモジュールの場合）を次の図に示します。

図10-33　シングルサインオンへの対応例（標準ログインモジュールの場合）

(5)　シングルサインオンへの対応例（カスタムログインモジュールの場合）

カスタムログインモジュールをシングルサインオンに対応させるには，jaas.conf，および認証用プログラムのコーディングを変更する必要があります。また，あらかじめ，ua.confに，ログインモジュールの識別子（対応例では「Krb5」）に対応するカスタムログインモジュールの定義項目を定義しておく必要があります。シングルサインオンへの対応例（カスタムログインモジュールの場合）を次の図に示します。

図10-34　シングルサインオンへの対応例（カスタムログインモジュールの場合）

10.21　JavaVMのプロパティの設定

統合ユーザ管理機能を使用する場合は，JavaVMの起動時にJavaVMプロパティの設定が必要です。この設定には簡易構築定義ファイルまたは運用管理ポータルを使用します。この節では，SmartComposer機能を使用してWebシステムを構築する場合の簡易構築定義ファイルでの設定方法について説明します。運用管理ポータルでの設定方法については，マニュアル「Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.5　統合ユーザ管理の設定」を参照してください。

JavaVMのプロパティは簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に設定します。

JavaVMのプロパティ内容を，次の表に示します。

表10-18　簡易構築定義ファイルでのJavaVMのプロパティの設定

指定するパラメタ
設定項目

jaas.ua.enabled
JavaVMのJAASを有効に設定します。

java.security.auth.login.config
jaas.confのファイルパスを指定します。

com.cosminexus.admin.auth.config
ua.confのファイルパスをを指定します。

com.cosminexus.admin.auth.passwordScramble.enable
uachpwコマンドでスクランブル化したパスワードの復号化機能の有効または無効を指定します。
詳細については，「10.20.2(3)　パスワードの変更とスクランブル化」を参照してください。

jaas.config.load_exclusively
java.security.auth.login.configパラメタで指定したjaas.conf以外のログイン構成は無視するかどうかを指定します。

簡易構築定義ファイルについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

JavaVMのプロパティ設定例を次に示します。

この例では，パスワードのスクランブル化を有効にし，jaas.conf以外のログイン構成を無視するように設定をしています。

簡易構築定義ファイルの設定例

：
<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
   <param>
     <param-name>jaas.ua.enabled</param-name>
     <param-value>true</param-value>
   </param>
   <param>
     <param-name>java.security.auth.login.config</param-name>
     <param-value><Cosminexusインストールディレクトリ>/manager/config/jaas.conf</param-value>
   </param>
   <param>
     <param-name>com.cosminexus.admin.auth.config</param-name>
     <param-value><Cosminexusインストールディレクトリ>/manager/config/ua.conf</param-value>
   </param>
   <param>
     <param-name>com.cosminexus.admin.auth.passwordScramble.enable</param-name>
     <param-value>true</param-value>
   </param>
   <param>
     <param-name>jaas.config.load_exclusively</param-name>
     <param-value>true</param-value>
   </param>
：
</configuration>

参考

WebアプリケーションでLoginContextクラスを操作するためのアクセス権を変更したい場合は，server.policyの設定を変更してください。

server.policyについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.5　server.policy（J2EEサーバ用セキュリティポリシーファイル）」を参照してください。

10.22　ファイルのデプロイ

この節では，統合ユーザ管理で使用するEARファイルをデプロイ方法について説明します。使用するJ2EEサーバに統合ユーザ管理用のuastartup.earをインポートし，uastartup.earを起動しておいてください。uastartup.earは，次に示すディレクトリにインストールされています。

Windowsの場合
<Cosminexusのインストールディレクトリ>¥manager¥config

UNIXの場合
/opt/Cosminexus/manager/config

uastartup.earは，Management Serverに登録して，J2EEサーバにインポートしてください。J2EEアプリケーションのインポートについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.5　J2EEアプリケーションのデプロイとアンデプロイ」を参照してください。

統合ユーザ管理フレームワークの機能を使用する場合は，uastartup.earを必ず稼働させてください。稼働していない場合，統合ユーザ管理フレームワークの提供するAPIで，例外が発生することがあります。また，Management Serverのリソース監視機能，およびmngsvrutilコマンドのサブコマンドreload userAdminも使用できません。

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

アプリケーションサーバでは，1台のマシンに複数の構築済み実行環境を共存させ，それぞれの実行環境を切り替える機能を提供しています。ここでは，複数の構築済み実行環境の切り替えについて説明します。

＜この章の構成＞

11.1　この章の構成

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

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

11.4　構築済み実行環境を切り替えるための準備

11.5　構築済み実行環境の切り替え手順

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

11.1　この章の構成

アプリケーションサーバでは，1台のマシンに複数の構築済み実行環境を共存させ，それぞれの実行環境を切り替える機能を提供しています。構築済み実行環境の切り替えで使用できる機能には，退避機能，回復機能，削除機能，および退避環境一覧出力機能があります。構築済み実行環境の切り替えによって，同一製品のバージョンやパッチの違い，設定内容の違いなどによるシステムの動作を，1台のマシンで検証できます。なお，1台のマシンで同時に動作できる実行環境は一つです。

この章の構成を次の表に示します。

表11-1　この章の構成（複数の構築済み実行環境の切り替え）

分類 | タイトル | 参照先
解説 | 構築済み実行環境の切り替えの概要 | 11.2
構築済み実行環境の切り替えの流れ | 11.3
設定 | 構築済み実行環境を切り替えるための準備 | 11.4
構築済み実行環境の切り替え手順 | 11.5
注意事項 | 構築済み実行環境を切り替える場合の注意事項 | 11.6

注　「実装」および「運用」について，この機能固有の説明はありません。

注意

構築済み実行環境の切り替えは，UNIX環境の場合に使用できます。退避機能と回復機能は，同じOSの同じバージョンのマシン環境上で実行してください。切り替え対象となる実行環境を構築する製品は，Application Server Standard，およびApplication Server Enterpriseです。ただし，構成ソフトウェアのうち，Cosminexus Component Container - Redirectorは構築済み実行環境の切り替え対象外です。

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

ここでは，構築済み実行環境の切り替えの概要について説明します。

構築済み実行環境を切り替える場合，構築済みの実行環境ごとに退避環境を作成します。退避環境は，実行環境を圧縮して，稼働可能状態から退避状態（稼働できない状態）に遷移した環境です。複数の退避環境のうち，使用したい退避環境を稼働可能状態に回復して，実行環境を切り替えます。

複数の構築済み実行環境の切り替えの概要を次の図に示します。

図11-1　複数の構築済み実行環境の切り替えの概要

この図では，実行環境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 アプリケーションサーバ リファレンス コマンド編」の「cosmienv（構築済み実行環境の退避，回復，削除，一覧出力）」を参照してください。

(3)　構築済み実行環境の切り替え実行時に障害が発生した場合の対処

構築済み実行環境を切り替える場合は，cosmienvコマンドを実行します。cosmienvコマンド実行時に障害が発生した場合は，メッセージと，ログファイルの内容を基に障害を解析してください。ログファイルは機能ごとに取得され，次の場所に格納されます。

構築済み実行環境の切り替えで取得するログファイルの格納場所

/opt/Cosminexus/env/log

機能ごとに出力されるログファイルを次の表に示します。

表11-2　機能ごとに出力されるログファイル

機能の種類 | ログファイル名
退避機能 | cosmienv_s[n].log
回復機能 | cosmienv_r[n].log
削除機能 | cosmienv_d[n].log

なお，退避環境一覧出力機能の場合，ログファイルは出力されません。

ログファイルの内容については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「5.2.6　構築済み実行環境の切り替えで出力するログの出力形式と出力項目（UNIXの場合）」を参照してください。また，メッセージについては，マニュアル「Cosminexus アプリケーションサーバ メッセージ 3」を参照してください。

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

ここでは，構築済み実行環境を切り替える場合の流れについて説明します。構築済み実行環境の切り替えの流れを次の図に示します。

図11-2　構築済み実行環境の切り替えの流れ

この図では，1台のマシンで，実行環境のバージョンアップを実施し，バージョンアップ後の実行環境で動作確認をしたあと，バージョンアップ前の実行環境に戻しています。この場合，退避機能を使用して，各バージョンの実行環境を退避しているので，動作確認中に障害や不具合が発生しても，再インストールや環境設定などの作業を実施しないで，退避した実行環境に回復できます。

退避機能を使用すると，次に示す実行環境を1台のマシンに共存できます。

製品のバージョンが異なる実行環境

製品のバージョンが同じで，設定が異なる実行環境

製品のバージョンが同じで，適用しているパッチが異なる実行環境

11.4　構築済み実行環境を切り替えるための準備

ここでは，構築済み実行環境を切り替えるために必要な準備について説明します。

準備として次の作業が必要です。

退避対象外のファイルの退避

ディスク容量の確認

＜この節の構成＞

11.4.1　退避対象外のファイルの退避

11.4.2　ディスク容量の確認

11.4.1　退避対象外のファイルの退避

構築済み実行環境を切り替える場合，cosmienvコマンドを使用して，構築済み実行環境から退避環境を作成します。cosmienvコマンドによって作成される退避環境には，ユーザ任意の定義ファイルや，ログファイル，プロパティの設定によって作成されたファイルなどは含まれません。このため，cosmienvコマンドを実行する前に，退避対象外のファイルのうち，アプリケーションサーバの動作に必要なファイルは，あらかじめ退避しておく必要があります。

なお，実行環境の回復時には，退避したファイルを回復した実行環境に戻す作業が必要になります。

＜この項の構成＞

(1)　退避作業が必要なファイル

(2)　退避作業が不要なファイル

(1)　退避作業が必要なファイル

退避対象外のファイルのうち，退避作業が必要なファイルと作業方法を次の表に示します。これらのファイルは，アプリケーションサーバの動作に影響があるため，必ず退避作業を実施してください。なお，実行環境の回復時には，退避したファイルを回復した実行環境の退避元フォルダに戻す作業が必要になります。

表11-3　退避作業が必要なファイルと作業方法

項番 | ファイルまたはディレクトリ名 | 作業方法 | 備考 | 構成ソフトウェア
1 | 簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のwebserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.fileパラメタに指定しているファイル | 退避してください。 | エラーステータスコードに対応するファイルを送信する場合に，レスポンスボディとしてクライアントに返すファイル | Cosminexus Component Container
2 | 簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のwebserver.connector.inprocess_http.redirect.<リダイレクト定義名>.fileで指定しているファイル | 退避してください。 | 特定のファイルをレスポンスとしてクライアントに返す場合にレスポンスボディとして使用するファイル | Cosminexus Component Container
3 | 展開ディレクトリ形式のアプリケーション | 退避してください。 | － | Cosminexus Component Container
4 | コンテナ拡張ライブラリ | 退避してください。 | － | Cosminexus Component Container
5 | アプリケーションサーバの構築・運用・アプリケーション開発で使用するファイルの形式や定義で，パスにデフォルト以外を設定しているディレクトリおよびファイル | 退避してください。 | － | Cosminexus Component Container
6 | Cosminexus RMの管理情報テーブル | 退避してください。 | DBMS上に作成したCosminexus RMの管理情報テーブル | Cosminexus Reliable Messaging
7 | Cosminexus RMのQueueConfigFileNameプロパティに指定しているファイル | プロパティを指定している場合は，退避してください。 | Cosminexus RMのキュー定義ファイル | Cosminexus Reliable Messaging
8 | Cosminexus RMのRMTRTransferControlDirプロパティに指定しているディレクトリ | プロパティを指定している場合は，退避してください。 | Cosminexus RMで使用するクライアント定義ファイルを格納したディレクトリ | Cosminexus Reliable Messaging
9 | Cosminexus RMのQueueMakeFileNameプロパティに指定しているファイル | プロパティを指定している場合は，退避してください。 | Cosminexus RMのキュー作成ファイル | Cosminexus Reliable Messaging
10 | Webサービスセキュリティの環境設定ファイル（cwsscfg.properties）のcwss.binding.KeyLocator.KeystoreDirプロパティに指定しているディレクトリ以下すべて | プロパティを指定している場合は，退避してください。 | 署名付与/検証で使用するキーストアファイルを格納するディレクトリ | Cosminexus Web Services - Security
11 | Webサービスセキュリティの環境設定ファイル（cwsscfg.properties）のcwss.binding.KeyLocator.CertificateDirプロパティに指定しているディレクトリ以下すべて | プロパティを指定している場合は，退避してください。 | 証明書検証で使用する証明書ファイルを格納するディレクトリ | Cosminexus Web Services - Security
12 | Webサービスセキュリティの環境設定ファイル（cwsscfg.properties）のcwss.binding.KeyLocator.SecretKeyDirプロパティに指定しているディレクトリ以下すべて | プロパティを指定している場合は，退避してください。 | 暗号化/復号化で使用する共通鍵ファイルを格納するディレクトリ | Cosminexus Web Services - Security
13 | 環境変数「VBROKER_ADM」またはCosminexus TPBrokerのvbroker.orb.admDirプロパティに/opt/Cosminexus/TPB/adm以外を設定している場合に，環境変数「VBROKER_ADM」またはvbroker.orb.admDirプロパティに設定しているディレクトリ以下にあるagentaddr，localaddr，HVMGTEE_DEF，htc.props，htc.clienthandleraddr，およびHVIORB_DEF | 環境変数またはプロパティを指定している場合は，退避してください。 | ユーザ作成の定義ファイル | Cosminexus TPBroker
14 | 環境変数「OSAGENT_ADDR_FILE」またはvbroker.agent.addrFileプロパティに指定しているファイル | 環境変数またはプロパティを指定している場合は，退避してください。 | ユーザ作成の定義ファイル | Cosminexus TPBroker
15 | 環境変数「OSAGENT_LOCAL_FILE」，またはvbroker.agent.localFileプロパティに指定しているファイル | 環境変数またはプロパティを指定している場合は，退避してください。 | ユーザ作成の定義ファイル | Cosminexus TPBroker
16 | -ORBpropStorageオプション，またはvbroker.orb.propStorageプロパティで指定しているファイル | オプションまたはプロパティを指定している場合は，退避してください。 | ユーザ作成の定義ファイル | Cosminexus TPBroker
17 | httpsd.confで指定した各種設定ファイル（Includeディレクティブ，TypeConfigディレクティブ，SSLによる暗号化，認証の定義など）のうち，opt/hitachi/httpsd以外にあるファイルすべて | opt/hitachi/httpsd以外を指定している場合は，退避してください。 | － | Hitachi Web Server
18 | httpsd.confで指定したコンテンツディレクトリのうち，opt/hitachi/httpsd以外にあるディレクトリすべて | opt/hitachi/httpsd以外を指定している場合は，退避してください。 | － | Hitachi Web Server

(2)　退避作業が不要なファイル

退避対象外のファイルのうち，退避作業が不要なファイルを次の表に示します。これらのファイルは，アプリケーションサーバの動作に影響はありません。必要に応じて退避してください。なお，退避作業が不要なファイルの場合，実行環境の回復時に退避したファイルを戻す作業は不要です。

表11-4　退避作業が不要なファイル

項番
ファイルまたはディレクトリ名
説明
構成ソフトウェア

1
/opt/Cosminexus/XMLSEC/logs/*
Cosminexus Web Services - Securityに含まれるXML Security - Coreのログ
Cosminexus Web Services - Security

2
/opt/Cosminexus/env以下すべて
構築済み実行環境の切り替え機能のコマンド（cosmienvコマンド）の格納先ディレクトリ
－

3
<Cosminexus作業ディレクトリ>/ejb/<サーバ名称>/logs以下すべて
/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/logs以下すべて
/opt/Cosminexus/CC/server/public/public_old/ejb/<サーバ名称>/logs以下すべて
J2EEサーバのログ出力先ディレクトリ※
Cosminexus Component Container

4
<Cosminexus作業ディレクトリ>/ejb/<サーバ名称>/以下のcore*，およびjavacore*
/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/以下のcore*，およびjavacore*
/opt/Cosminexus/CC/server/public/public_old/ejb/<サーバ名称>/以下のcore*，およびjavacore*
J2EEサーバのcoreファイル，およびJavaCoreファイル※
Cosminexus Component Container

5
<Cosminexus作業ディレクトリ>/ejb/<サーバ名称>/stats以下すべて
/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/stats以下すべて
/opt/Cosminexus/CC/server/public/public_old/ejb/<サーバ名称>/stats以下すべて
J2EEサーバとSFOサーバの稼働情報ファイルの格納先ディレクトリ※
Cosminexus Component Container

6
/opt/Cosminexus/CC/logs以下すべて
Cosminexus Component Containerのログ格納用ディレクトリ
Cosminexus Component Container

7
/opt/Cosminexus/CC/admin/logs以下すべて
サーバ管理コマンドのログ格納用ディレクトリ
Cosminexus Component Container

8
/opt/Cosminexus/CC/client/logs以下すべて
EJBクライアントアプリケーションのログ出力用ディレクトリ
Cosminexus Component Container

9
/opt/Cosminexus/CC/web/containers/<サーバ名称>/以下のcore*，およびjavacore*
Webコンテナサーバのcoreファイル，およびJavaCoreファイル
Cosminexus Component Container

10
/opt/Cosminexus/CC/web/containers/<サーバ名称>/logs以下すべて
Webコンテナサーバのログ出力先ディレクトリ
Cosminexus Component Container

11
/opt/Cosminexus/manager/log以下すべて
Cosminexus Component Containerの運用管理機能のログ出力先ディレクトリ
Cosminexus Component Container

12
/opt/Cosminexus/manager/tmp
Cosminexus Component Containerの運用管理機能の一時的なワークディレクトリ
Cosminexus Component Container

13
/opt/Cosminexus/manager/bin/以下のcore*，およびjavacore*
Cosminexus Component Containerの運用管理機能のcoreファイル，およびJavaCoreファイル
Cosminexus Component Container

14
/opt/Cosminexus/sinagent/log
サーバ通信エージェントのログ出力先ディレクトリ
Cosminexus Component Container

15
/opt/Cosminexus/CC/web/redirector/logsおよび/opt/Cosminexus/CC/web/redirector/servers/<論理Webサーバ名>/logs以下すべて
リダイレクタのメッセージログ出力先ディレクトリおよび保守用トレースログ出力先ディレクトリ
Cosminexus Component Container

16
<Cosminexus作業ディレクトリ>/ejb/<サーバ名称>/otsstatus以下すべて
/opt/Cosminexus/CC/server/public/ejb/<サーバ名称>/otsstatus以下すべて
/opt/Cosminexus/CC/server/public/public_old/ejb/<サーバ名称>/otsstatus以下すべて
インプロセストランザクションサービスのステータスファイルの格納ディレクトリ※
Cosminexus Component Container

17
/var/spool/TPBrokerOTM以下すべて
ドメイン情報ファイル格納ディレクトリ
Cosminexus Component Transaction Monitor

18
CTMSPOOL環境変数で指定したディレクトリ以下すべて
CTMSPOOLディレクトリ
Cosminexus Component Transaction Monitor

19
PRFSPOOL環境変数で指定したディレクトリ以下すべて
PRFSPOOLディレクトリ
Cosminexus Performance Tracer

20
/opt/Cosminexus/RM/logs以下すべて
Cosminexus RMコマンドのログ出力先ディレクトリ
Cosminexus Reliable Messaging

21
/opt/Cosminexus/c4web/logs以下すべて
Cosminexus Component ContainerのSOAPアプリケーション開発支援機能のログ出力先ディレクトリ
Cosminexus Web Services - Security

22
/opt/Cosminexus/TPB/adm/hgtfifo/以下すべて
バーボースログ出力用一時ディレクトリ
Cosminexus TPBroker

23
/opt/Cosminexus/TPB/adm/impl_dir/以下すべて
インプリメンテーションリポジトリデータ作成ディレクトリ
Cosminexus TPBroker

24
/opt/Cosminexus/TPB/log/以下すべて
C++ORB機能トレース出力ディレクトリ
Cosminexus TPBroker

25
/opt/Cosminexus/TPB/logj/以下すべて
JavaORB機能トレース出力ディレクトリ
Cosminexus TPBroker

26
/opt/hitachi/httpsd/logs以下すべて
Hitachi Web Serverのログ出力先ディレクトリ
Hitachi Web Server

27
/opt/hitachi/httpsd/servers/<サーバ名称>/logs以下すべて
Hitachi Web Serverのログ出力先ディレクトリ
Hitachi Web Server

28
/opt/Cosminexus/wss/logs以下すべて
Cosminexus Web Services - Securityのログ出力先ディレクトリ
Cosminexus Web Services - Security

（凡例）－：Cosminexusの製品が該当します。

注　表内のディレクトリの意味を次に示します。

<Cosminexus作業ディレクトリ>
<Cosminexusの作業ディレクトリ>は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のejb.public.directoryパラメタに設定されているディレクトリです。デフォルト値は，「/opt/Cosminexus/CC/server/public」です。

注※　次のディレクトリも含まれます。

<Cosminexus作業ディレクトリ>を変更する前に使用したデフォルトの作業ディレクトリ

アップグレードインストール後に移行した際に作成されるデフォルトのバックアップディレクトリ

11.4.2　ディスク容量の確認

構築済み実行環境から退避環境を作成する場合，退避対象ファイルをすべてアーカイブしたファイルが，退避環境として作成されます。このため，実行するマシンに十分なディスク容量があるかを確認してください。退避環境に必要なディスク容量は，構築済みの実行環境の状態によって変わります。製品の新規インストール直後の状態では，それぞれ次に示すディスク占有量が必要になります。

Application Server Standardの場合
750メガバイト

Application Server Enterpriseの場合
850メガバイト

注意

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のejbserver.distributedtx.ots.status.directory1パラメタ，またはejbserver.distributedtx.ots.status.directory2パラメタで指定したディレクトリは，相対パスで指定している場合は退避されます。この場合，ディスク容量は，ejbserver.distributedtx.ots.status.directory1パラメタ，またはejbserver.distributedtx.ots.status.directory2パラメタで指定しているディレクトリが使用するディスク容量を加えた値で見積もる必要があります。

11.5　構築済み実行環境の切り替え手順

ここでは，構築済み実行環境を切り替える場合の手順と，退避環境作成時に退避されるファイルについて説明します。

＜この節の構成＞

11.5.1　構築済み実行環境の切り替え手順の例

11.5.2　退避環境作成時に退避対象となるファイル

11.5.1　構築済み実行環境の切り替え手順の例

ここでは，1台のマシンに実行環境Aを構築し，実行環境Bにバージョンアップして動作検証したあと，実行環境Aに戻す手順を例に説明します。

各実行環境の設定内容の例を次の表に示します。

表11-5　各実行環境の設定内容の例

設定内容 | 実行環境A | 実行環境B
退避環境の格納先 | /home/CosmiBackup
退避対象外のファイルの格納先 | /home/CosmiBackup/apsvAfiles | /home/CosmiBackup/apsvBfiles
退避環境の識別子 | apsvA | apsvB

実行環境の切り替え手順を次に示します。

実行環境Aを構築します。
Application Serverをインストールして，環境設定を実施し，システムを構築します。
実行環境Aが稼働可能状態となります。

実行環境Aの退避対象外のファイルを任意の場所に格納します。
ここでは，「/home/CosmiBackup/apsvAfiles」に格納します。退避対象外のファイルについては，「11.4.1　退避対象外のファイルの退避」を参照してください。

実行環境Aを退避するために必要なディスク容量を確認します。
製品ごとに必要なディスク容量については，「11.4.2　ディスク容量の確認」を参照してください。

cosmienvコマンドに引数-sを指定して，実行環境Aの退避環境を作成します。
コマンドの入力例を次に示します。
cosmienv -s -I apsvA -P /home/CosmiBackup
退避環境作成時に退避されるファイルについては，「11.5.2　退避環境作成時に退避対象となるファイル」を参照してください。
cosmienvコマンドを実行しても，実行環境Aは稼働可能状態のまま残ります。

実行環境Bを構築します。
実行環境Aにアップグレードインストールと環境設定を実施します。
実行環境Bが稼働可能状態となり，実行環境Aは退避環境だけとなります。

実行環境Bの退避対象外のファイルを任意の場所に格納します。
ここでは，「/home/CosmiBackup/apsvBfiles」に格納します。退避対象外のファイルについては，「11.4.1　退避対象外のファイルの退避」を参照してください。

実行環境Bを退避するために必要なディスク容量を確認します。
製品ごとに必要なディスク容量については，「11.4.2　ディスク容量の確認」を参照してください。

cosmienvコマンドに引数-sを指定して，実行環境Bの退避環境を作成します。
コマンドの入力例を次に示します。
cosmienv -s -I apsvB -P /home/CosmiBackup
退避環境作成時に退避されるファイルについては，「11.5.2　退避環境作成時に退避対象となるファイル」を参照してください。
cosmienvコマンドを実行しても，実行環境Bは稼働可能状態のまま残ります。

実行環境Bで動作検証をします。

実行環境B（Application Server）をアンインストールします。

cosmienvコマンドに引数-rを指定して，実行環境Aに戻します。
コマンドの入力例を次に示します。
cosmienv -r -I apsvA
実行環境Aが稼働可能状態となり，実行環境Bは退避環境だけとなります。回復元の退避環境Aはそのまま残ります。

手順2.で退避したファイルを該当個所（退避元ディレクトリ）に格納します。
退避対象外のファイルを実行環境Aの退避元ディレクトリにそれぞれ格納します。

cosmienvコマンドの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス コマンド編」の「cosmienv（構築済み実行環境の退避，回復，削除，一覧出力）」を参照してください。

11.5.2　退避環境作成時に退避対象となるファイル

退避環境作成時に退避対象となるファイルを次の表に示します。

表11-6　退避環境作成時に退避対象となるファイル

項番 | ファイルまたはディレクトリ名 | 説明 | 構成ソフトウェア
1 | /opt/Cosminexus/XMLSEC | Cosminexus Web Services - Securityに含まれるXML Security - Coreの製品，設定ファイルなど | Cosminexus Web Services - Security
2 | /opt/Cosminexus/.HTC_xxxx.inf | Cosminexus製品情報ファイル | －
3 | /opt/Cosminexus/common以下すべて | Cosminexus共通モジュール群 | －
4 | /opt/Cosminexus/CC | Cosminexus Component Containerのインストールディレクトリ | Cosminexus Component Container
5 | /opt/Cosminexus/CWC | Cosminexus Component ContainerのWebアプリケーション開発に利用する機能のインストールディレクトリ | Cosminexus Component Container
6 | /opt/Cosminexus/c4web | Cosminexus Component ContainerのSOAPアプリケーション開発支援機能，SOAP通信基盤のファイルがインストールされているディレクトリ | Cosminexus Component Container
7 | /opt/Cosminexus/manager | Cosminexus Component Containerの運用管理機能のインストールディレクトリ | Cosminexus Component Container
8 | /sbin/init.d/MngSvr | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（HP-UXの場合） | Cosminexus Component Container
9 | /sbin/init.d/AdminAgent | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（HP-UXの場合） | Cosminexus Component Container
10 | /etc/rc.d/init.d/MngSvr | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（Linuxの場合） | Cosminexus Component Container
11 | /etc/rc.d/init.d/AdminAgent | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（Linuxの場合） | Cosminexus Component Container
12 | /etc/init.d/MngSvr | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（Solarisの場合） | Cosminexus Component Container
13 | /etc/init.d/AdminAgent | インストール時に作成されるCosminexus Component Containerの運用管理機能のrcスクリプトファイル（Solarisの場合） | Cosminexus Component Container
14 | /opt/Cosminexus/CTM/bin以下すべて | Cosminexus Component Transaction Monitorのロードモジュール | Cosminexus Component Transaction Monitor
15 | /opt/Cosminexus/CTM/lib以下すべて | Cosminexus Component Transaction Monitorのライブラリ | Cosminexus Component Transaction Monitor
16 | /opt/Cosminexus/CTM/.HTC_xxxx.inf | Cosminexus Component Transaction Monitorの製品情報ファイル | Cosminexus Component Transaction Monitor
17 | /opt/Cosminexus/PRF/bin以下すべて | Cosminexus Performance Tracerのロードモジュール | Cosminexus Performance Tracer
18 | /opt/Cosminexus/PRF/lib以下すべて | Cosminexus Performance Tracerのライブラリ | Cosminexus Performance Tracer
19 | /opt/Cosminexus/PRF/.HTC_xxxx.inf | Cosminexus Performance Tracerの製品情報ファイル | Cosminexus Performance Tracer
20 | /opt/Cosminexus/jaxp | Cosminexus XML Processorのインストールディレクトリ | Cosminexus XML Processor
21 | /opt/Cosminexus/jdk | Cosminexus Developer's Kit for Javaのインストールディレクトリ | Cosminexus Developer's Kit for Java
22 | /opt/Cosminexus/RM | Cosminexus RMのインストールディレクトリ | Cosminexus Reliable Messaging
23 | /opt/Cosminexus/TPB以下すべて | Cosminexus TPBroker インストールディレクトリ | Cosminexus TPBroker
24 | /opt/hitachi/httpsd | Hitachi Web Serverのインストールディレクトリ | Hitachi Web Server
25 | 簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）のejb.public.directoryパラメタで指定するディレクトリパス | J2EEサーバの作業ディレクトリ | Cosminexus Component Container
26 | /opt/Cosminexus/wss | Cosminexus Web Services Securityのインストールディレクトリ | Cosminexus Web Services - Security
27 | /opt/Cosminexus/sinagent | サーバ通信エージェントのインストールディレクトリ | Cosminexus Component Container
28 | /etc/rc.d/init.d/SINaviAgent | インストール時に作成されるサーバ通信エージェントのrcスクリプトファイル（Linuxの場合） | Cosminexus Component Container

（凡例）－：Cosminexusの製品が該当します。

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

ここでは，構築済み実行環境を切り替える場合の注意事項について説明します。

退避機能および回復機能を実行する場合，次に示すファイルは，退避および回復されません。

ユーザ任意の定義ファイル

ログファイル

プロパティの設定によって作成されるファイル

これらのファイルのうち，退避機能実行前に退避したり，回復機能実行後に回復したりする作業が必要なファイルがあります。手動で退避・回復が必要なファイルについては，「11.4.1(1)　退避作業が必要なファイル」を参照してください。

CTMドメインマネジャが異常終了したあとに，構築済み実行環境の切り替えを実施すると，CTMドメインマネジャの起動時にKFCT70604-Eメッセージを出力して，起動に失敗する場合があります。CTMドメインマネジャの起動に失敗した場合は，次のどちらかを実施してください。

ctmdmstartコマンドに，-CTMAutoForceオプションまたは-CTMForceStart を指定して，CTMドメインマネジャを起動してください。

CTMSPOOL環境変数で指定したディレクトリ以下を削除してから，CTMドメインマネジャを起動してください。

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

この章では，J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションのログ出力の概要と出力方法について説明します。

＜この章の構成＞

12.1　この章の構成

12.2　ユーザログ出力の概要

12.3　ログのフォーマット

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

12.5　ユーザログを出力するための実装

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

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

12.8　J2EEアプリケーションのユーザログ出力の設定

12.9　バッチアプリケーションのユーザログ出力の設定

12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）

12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）

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

12.1　この章の構成

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するログを，ユーザログといいます。この章では，アプリケーションのユーザログ出力について説明します。

トラブル発生時には，出力されたユーザログを収集・分析して，トラブルの発生要因を調査します。ユーザログの取得には，snapshotログとして一括して取得する方法と，個別に取得する方法があります。ユーザログを含むsnapshotログの収集については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「2.3.3　snapshotログの収集」を参照してください。

この章の構成を次の表に示します。

表12-1　この章の構成（アプリケーションのユーザログ出力）

分類 | タイトル | 参照先
解説 | ユーザログ出力の概要 | 12.2
ログのフォーマット | 12.3
実装 | ユーザログ出力で使用するメソッド | 12.4
ユーザログを出力するための実装 | 12.5
設定 | ロガーとハンドラの作成と設定 | 12.6
ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法 | 12.7
J2EEアプリケーションのユーザログ出力の設定 | 12.8
バッチアプリケーションのユーザログ出力の設定 | 12.9
EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合） | 12.10
EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合） | 12.11
注意事項 | ユーザログ機能を使用する場合の注意事項 | 12.12

注　「運用」について，この機能固有の説明はありません。

ユーザログ出力の参照先はアプリケーションの種類によって異なります。参照先について次の表に示します。

表12-2　ユーザログ出力に関する参照先

参照先 | アプリケーションの種類
J2EEアプリケーション | バッチアプリケーション | EJBクライアントアプリケーション
12.2　ユーザログ出力の概要 | ○ | ○ | ○
12.3　ログのフォーマット | ○ | ○ | ○
12.4　ユーザログ出力で使用するメソッド | ○ | ○ | ○
12.5　ユーザログを出力するための実装 | ○ | ○ | ×
12.6　ロガーとハンドラの作成と設定 | ○ | ○ | ×
12.7　ユーザ独自のフィルタ／フォーマッタ／ハンドラの使用方法 | ○ | ○ | ×
12.8　J2EEアプリケーションのユーザログ出力の設定 | ○ | × | ×
12.9　バッチアプリケーションのユーザログ出力の設定 | × | ○ | ×
12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合） | × | × | ○
12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合） | × | × | ○
12.12　ユーザログ機能を使用する場合の注意事項 | ○ | ○ | ○

（凡例）○：参照する　　×：参照しない

12.2　ユーザログ出力の概要

この節では，ユーザログ出力の概要について説明します。

＜この節の構成＞

12.2.1　ユーザログ出力の概要

12.2.2　ユーザログ出力の仕組み

12.2.1　ユーザログ出力の概要

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するログを，ユーザログといいます。Cosminexusでは，ユーザログを，日立トレース共通ライブラリ形式で出力できます（ユーザログ機能）。これによって，システムのログとアプリケーションのログを同じ形式で扱うことができるようになり，システム全体のログ運用の信頼性を高められます。

次に，ユーザログ機能を使用したログ出力の流れを示します。

図12-1　ユーザログ機能の処理の流れ

ユーザログ出力の実装にはJ2SEの標準のログ出力機能（JavaロギングAPI）を使用します。この機能を使用する場合は，ユーザログ出力をJavaロギングAPIで実装してください。

参考

リソースアダプタからユーザログを出力することはできません。なお，リソースアダプタから呼び出されるMessage-driven Beanからは，ユーザログを出力できます。

12.2.2　ユーザログ出力の仕組み

ユーザログを出力するJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションの実装には，J2SEのJavaロギングAPIを使用できます。JavaロギングAPIは，メモリ，コンソール，ファイルなどのさまざまな出力ができる汎用性の高いAPIです。ただし，ロジックが単純なため，ミッション・クリティカルなシステムに適用する場合は，信頼性と耐久性を備えたログ出力用クラスをアプリケーション開発者が実装する必要があります。

ユーザログ機能を使用すると，アプリケーション開発者によってログ出力用クラスを実装しなくても，信頼性が高いユーザログを出力できます。

JavaロギングAPIを使用して開発したJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションから出力されたログは，日立トレース共通ライブラリを使用して，ほかのCosminexusシステムの構成ソフトウェアが出力する形式（日立トレース共通ライブラリ形式）で出力することができます。このライブラリを使用することで，ユーザログをほかのシステムのログと同じ形式で扱うことができ，高い信頼性を持つ統一的なログ運用ができます。

ユーザログ出力は，J2SEのJavaロギングの仕組みに従って出力します。Javaロギングでは，ロガーとハンドラという2種類の要素を使用します。なお，ロガーおよびハンドラは，それぞれ，LoggerクラスおよびHandlerクラスのオブジェクトです。

Javaロギングの仕組みを次の図に示します。

図12-2　Javaロギングの仕組み

図について説明します。

アプリケーションから，ロガーを使用して，ユーザログを出力します。
ユーザログは，アプリケーションの処理の中で，Loggerクラスのメソッドを使用して出力されます。

ロガーは，アプリケーションから出力されたログにレベルやメッセージ文字列などの付加情報を追加してLogRecordにしたものを，ハンドラに渡します。
なお，このとき，ロガーに接続されたフィルタ（Filterクラスのオブジェクト）を使用して，ログレベルとして指定する制御以上のきめ細やかな制御をすることもできます。

ハンドラは，受け取ったLogRecordを基に，ログをファイル，コンソールまたはソケットに出力します。
出力先や出力形式は，あらかじめハンドラのプロパティとして設定しておきます。ハンドラでは，ハンドラに接続されたフィルタを使用してきめ細やかな制御ができます。また，フォーマッタ（Formatterクラスのオブジェクト）を使用して任意の形式にフォーマットしたメッセージを出力できます。

アプリケーションサーバでは，日立トレース共通ライブラリ形式でログをファイルに出力するためのファイルハンドラを提供しています。提供しているファイルハンドラについて，アプリケーションの種類ごとに説明します。

●J2EEアプリケーションまたはバッチアプリケーションの場合

ファイルハンドラとして，CJMessageFileHandlerを提供しています。CJMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどは，システム構築時に設定できます。J2EEアプリケーションまたはバッチアプリケーションのユーザログ出力の設定については，「12.8　J2EEアプリケーションのユーザログ出力の設定」および「12.9　バッチアプリケーションのユーザログ出力の設定」を参照してください。

また，ユーザログに，ログを出力したアプリケーションの名称やメッセージの内容と対応したメッセージIDを出力したい場合は，J2EEアプリケーションまたはバッチアプリケーション内で実装する必要があります。この場合は，Application Serverが提供する拡張LogRecord作成用のクラス（CJLogRecordクラス）を使用して実装してください。CJLogRecordクラスの使用方法については，「12.4　ユーザログ出力で使用するメソッド」を参照してください。また，CJLogRecordクラスのAPIについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「10.　ユーザログ機能で使用するAPI」を参照してください。

注意

ハンドラやロガーの設定をJ2EEアプリケーション内に直接実装する場合は，実行するアプリケーションにLoggingPermission("control")のセキュリティ権限が必要になります。LoggingPermission("control")のセキュリティ権限の設定方法については，「12.8.2　セキュリティポリシーの設定」を参照してください。

●EJBクライアントアプリケーションの場合

ファイルハンドラとして，CJMPMessageFileHandlerを提供しています。なお，EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。EJBクライアントアプリケーションのユーザログ出力の設定については，「12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）」または「12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）」を参照してください。

12.3　ログのフォーマット

ユーザログ機能を使用した場合，次に示すフォーマットでログが出力されます。

番号　日付　時刻
AppName
pid　tid
MsgID
メッセージテキスト
CRLF

フォーマットの項目の出力内容を次に示します。

表12-3　ログフォーマット

項目
出力内容

番号
トレースコードの通番（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）が出力されます。

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

ユーザログ出力で使用するLoggerクラスのメソッドと，CJLogRecordクラスが属するパッケージを示します。CJLogRecordクラスのメソッドの一覧，および機能と文法については，マニュアル「Cosminexus アプリケーションサーバ リファレンス API編」の「10.　ユーザログ機能で使用する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

ユーザログ機能を使用する場合のプログラムの実装例については，「12.5　ユーザログを出力するための実装」を参照してください。

12.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編」を参照してください。

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

JavaロギングAPIを使用してユーザログ出力をするためには，ロガーとハンドラを作成して，必要な設定をします。ログ出力に必要なアプリケーション識別名（AppName）やメッセージID（MsgID）などのパラメタは，Cosminexusが提供するCJLogRecordクラスのcreateメソッドの引数に指定します。また，独自のクラスを作成することで，ログのフィルタリングや出力内容のフォーマットをカスタマイズすることもできます。

なお，ユーザログ出力をするには，ログの出力先や構成面数などのプロパティを，実行環境に設定する必要があります。実行環境でのユーザログの設定については，「12.8　J2EEアプリケーションのユーザログ出力の設定」または「12.9　バッチアプリケーションのユーザログ出力の設定」を参照してください。

J2EEアプリケーションまたはバッチアプリケーションのユーザログを出力する場合のロガーとハンドラの作成および設定の概要について説明します。

なお，EJBクライアントアプリケーションのユーザログ出力については，「12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）」または「12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）」を参照してください。

＜この節の構成＞

12.6.1　ロガーの作成と設定

12.6.2　ハンドラの作成と設定

12.6.3　ロガーおよびハンドラを作成・設定する場合の指針

12.6.1　ロガーの作成と設定

ロガーは，ロガー名称を指定して作成します。作成時には，システム構築時に設定した内容が使用されます。

各アプリケーション内では，ロガー名称を指定して作成されたロガーを取得し，取得したロガーを使用してログを出力します。Loggerクラスのメソッドでは，ロガーの作成およびログ出力の指定ができます。指定したログは，LogRecordに変換され，ハンドラに渡されて，ログファイルまたはコンソールに出力されます。

このほか，ロガーでログを取捨選択するためのフィルタ，ログのレベル，ロガーで使用するハンドラについても，必要に応じて設定できます。

12.6.2　ハンドラの作成と設定

ハンドラは，システム構築時に設定した内容に従って作成，設定されます。

CJMessageFileHandlerを使用する場合は，ハンドラ名称を変えることで，複数のファイルハンドラを作成できます。

CJMessageFileHandlerで作成したファイルハンドラには，次の項目が設定できます。

ユーザログの出力先ファイル，面数，サイズなどのログファイルの設定

ログ取得レベル

使用するフィルタ，フォーマッタ

なお，一つのハンドラが出力するログのアプリケーション名およびメッセージIDが同じでかまわない場合には，CJMessageFileHandlerのプロパティとして設定できます。メッセージごとに出力するログのアプリケーション名とメッセージIDを変更したい場合は，アプリケーション内のログ出力処理ごとに，アプリケーション名およびメッセージIDを出力するようにCJLogRecordクラスを使用して実装してください。

12.6.3　ロガーおよびハンドラを作成・設定する場合の指針

ロガーおよびハンドラを作成，設定する場合の指針を次に示します。

一つのロガーに対して複数のファイルハンドラを接続できますが，複数のロガーから出力先が同じファイルハンドラに接続して利用することはできません。

アプリケーションごとにログの出力先を変えたい場合は，アプリケーションごとのロガーを作成します。

ロガーは，階層関係を持たせることができます。階層関係を持たせた場合，下位のロガーが取得したログメッセージは，上位のロガーに伝播します。必要に応じて，ロガーの伝播を止めてください。特に，ロガーの最上位にはルートロガーがデフォルトで存在し，J2SEデフォルトの設定の場合，ルートロガーにはConsoleHandlerが接続されています。上位ロガーへの伝播を止めていない場合，ルートロガーのConsoleHandlerからコンソールにすべてのメッセージが出力されます。

ハンドラはインスタンスごとにメッセージを出力するため，一つの出力メッセージが複数のハンドラに送信された場合，一つの出力メッセージが複数回出力されます。例えば，2か所のConsoleHandlerのメッセージは，コンソールに2回出力されます。

一つのアプリケーションで複数のログファイルを利用する場合は，出力先ごとにハンドラを作成してください。

ロガーとハンドラの作成例を次の図に示します。

図12-3　ロガーとハンドラの作成例

この例では，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を使用してください。

それぞれのログファイルのサイズおよび面数は，アプリケーションが出力するユーザログの量や指定した出力レベルに応じて，適切に設定してください。

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

ここでは，ユーザが作成した独自のFilterクラス，FormatterクラスまたはHandlerクラスをユーザログ機能で利用するための使用方法について説明します。なお，ここでは，ユーザが作成したクラスをユーザ作成クラスといいます。

ユーザ作成クラスを作成することで，ログのフィルタリングや出力内容をフォーマットできます。ユーザ作成クラスとして，Filterクラス，FormatterクラスまたはHandlerクラスを作成し，ライブラリJARまたはコンテナ拡張ライブラリに含めて使用します。

ユーザ作成クラスをユーザログ機能で使用する方法には，次の2種類の方法があります。

ライブラリJARを利用する
J2EEアプリケーションの場合に使用できる方法です。バッチアプリケーションの場合は使用できません。

コンテナ拡張ライブラリを利用する
J2EEアプリケーションまたはバッチアプリケーションで使用できる方法です。

それぞれの方法について説明します。

＜この節の構成＞

12.7.1　ライブラリJARを利用する方法

12.7.2　コンテナ拡張ライブラリを利用する方法

12.7.1　ライブラリJARを利用する方法

ユーザ作成クラスであるFilterクラス，FormatterクラスまたはHandlerクラスを，アプリケーション上で作成してロガーに追加して利用する方法です。この場合は，次の処理が実行されます。

まず，アプリケーションの中でHandlerクラスをインスタンス化します。

次に，FilterクラスやFormatterクラスをインスタンス化したものをHandlerクラスのインスタンスに接続します。

最後に，接続したHandlerクラスのインスタンスを，ロガーに追加します。

この場合のユーザ作成クラスは，J2SEのjava.util.loggingの仕様に従って作成してください。作成したクラスは，通常のユーザクラスと同じように，WAR，EJB-JARまたはインポート用ライブラリJARに含めて利用できます。

次に，ライブラリJARに含めて利用する場合のユーザ作成クラスの作成手順を示します。

セキュリティポリシーファイル（server.policy）にセキュリティポリシーを設定します。
セキュリティポリシーの設定については，「12.8.2　セキュリティポリシーの設定」を参照してください。

独自の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クラスの構成を初期化した場合，ユーザログ機能によって構築されたログ体系が失われます。

なお，コーディング上の注意事項については，「12.12　ユーザログ機能を使用する場合の注意事項」を参照してください。

12.7.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（ユーザプロパティファイル）のユーザログ機能用のプロパティキーに，パッケージ名称を含むフルクラス名を指定します。

12.8　J2EEアプリケーションのユーザログ出力の設定

この節では，J2EEアプリケーションが出力するログを，日立トレース共通ライブラリ形式で出力するための設定方法について説明します。また，アプリケーションのユーザログ出力例についても説明します。なお，J2EEアプリケーションのログを出力しない場合は，この設定は不要です。

日立トレース共通ライブラリ形式でログを出力するためには，次の設定が必要です。

J2EEサーバの設定

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

＜この節の構成＞

12.8.1　J2EEサーバの設定

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

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

12.8.1　J2EEサーバの設定

簡易構築定義ファイルを編集して，ハンドラからのログの出力先，ログレベル，ログ面数，使用するフィルタ，フォーマッタなどを指定してください。

＜この項の構成＞

(1)　設定内容

(2)　注意事項

(1)　設定内容

簡易構築定義ファイルで論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.applicationから始まるパラメタで，J2EEアプリケーションのユーザログを出力するための設定をします。ejbserver.applicationから始まるパラメタを次に示します。なお，<ハンドラ名称>には，キーの値を区別するためのハンドラ名称を指定してください。また，<ロガー名称>には，Loggerのインスタンスを取得するときに指定するロガー名称を指定してください。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.appname
ハンドラごとに，ログファイルに出力するメッセージのJ2EEアプリケーション名（AppNameフィールドの値）のデフォルト値を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.count
ハンドラごとに，ログファイルの面数を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.encoding
ハンドラごとに，ログファイルに出力する文字列のエンコーディングを指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.filter
ハンドラごとに，使用するフィルタ名を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.formatter
ハンドラごとに，使用するフォーマッタ名を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.level
ハンドラごとに，ログ取得レベルの上限を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.limit
ハンドラごとに，ログファイルのサイズを指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.msgid
ハンドラごとに，ログファイルに出力するメッセージのメッセージID（MsgIDフィールドの値）のデフォルト値を指定します。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.path
ハンドラごとに，ログファイルの出力先とプリフィックスを指定します。出力されるログファイル名は，「<プリフィックス><1～16の番号>.log」になります。このキーは必ず指定してください。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.separator
ハンドラごとに，ログファイルに出力するメッセージを1文で出力するための，要素区切り文字のデフォルト値を指定します。

ejbserver.application.userlog.loggers
使用するロガー名称を宣言します。このキーは必ず指定してください。

ejbserver.application.userlog.Logger.<ロガー名称>.handlers
ロガーごとに，使用するハンドラ名称を指定します。このキーは必ず指定してください。

ejbserver.application.userlog.Logger.<ロガー名称>.level
ロガーごとに，ロガーのログ取得レベルを指定します。

ejbserver.application.userlog.Logger.<ロガー名称>.useParentHandlers
ロガーごとに，ロガーを通過するレベルのログレコードを，親のロガーが使用しているハンドラに伝播させるかどうかを指定します。

ejbserver.application.userlog.Logger.<ロガー名称>.filter
ロガーごとに，ロガーでメッセージの取捨選択に使用するフィルタを指定します。

J2EEアプリケーションのユーザログを出力するためには，少なくとも，次の三つのパラメタを指定する必要があります。

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.path

ejbserver.application.userlog.loggers

ejbserver.application.userlog.Logger.<ロガー名称>.handlers

簡易構築定義ファイルの詳細については，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.6　簡易構築定義ファイル」を参照してください。

(2)　注意事項

ロガーには複数のハンドラを接続できます。ただし，複数のロガーに同一のPath設定を持つファイルハンドラ（CJMessageFileHandler）は接続できません。ファイルハンドラはロガーへの接続の指定（ejbserver.application.userlog.Logger.<ロガー名称>.handlersの値）を参照してインスタンス化します。この際，ログの出力先とプリフィックス（ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.pathの値）の同じハンドラがインスタンス化されている場合は，ログファイルのオープンに失敗します。

ハンドラやロガーの設定および構築については，簡易構築定義ファイルで指定できますが，ハンドラの作成やロガーの構成変更をJ2EEアプリケーション内に直接実装する場合は，実行するアプリケーションにLoggingPermission("control")のセキュリティ権限が必要になります。LoggingPermission("control")のセキュリティ権限の設定方法については，「12.8.2　セキュリティポリシーの設定」を参照してください。

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

ここでは，セキュリティポリシーの設定について説明します。

アプリケーションのソースプログラム上で，J2SE1.4仕様のLoggerクラスの構成を変更したり，FileHandlerクラスを作成したりして，J2SE標準のロギング機能を直接実装する場合，セキュリティポリシーを設定する必要があります。セキュリティポリシーは，server.policy（J2EEサーバ用セキュリティポリシーファイル）またはweb.policy（SecurityManager定義ファイル）に定義します。

なお，server.policyにセキュリティポリシーを定義する場合は，Smart Composer機能のコマンドでシステムを構築したあとに設定してください。

簡易構築定義ファイルのパラメタを基に構築されたロガーに対して出力指定をする場合，セキュリティポリシーを設定する必要はありません。セキュリティポリシーの設定が必要なのは，次のような場合です。

ユーザのアプリケーションのソースコード上でJ2SE標準のファイルハンドラを作成する場合

LoggerクラスのaddHandlerメソッドを呼び出してロガーの構成を変更する場合

この場合には，JavaロギングAPI操作用のセキュリティポリシーが必要になります。必要に応じて次のセキュリティパーミッションを指定してください。

server.policyの設定内容を次に示します。

＜この項の構成＞

(1)　フィルタやフォーマッタをリフレクションで作成する場合

(2)　ログマネジャ（LogManager）のプロパティを設定する場合

(3)　J2SE標準のファイルハンドラを使用する場合（File出力を行うクラス（FileHandler，CJMessageFileHandler）を使用する場合）

(4)　JavaロギングAPIのLogger.addHandlerメソッドなどを使用してログ体系を変更する場合

(5)　設定例

(1)　フィルタやフォーマッタをリフレクションで作成する場合

FilterクラスやFormatterクラスなどをリフレクションで作成する場合は，次に示す行を追加します。

permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

それぞれのHandlerクラスは，ログマネジャ（LogManager）からプロパティを取得して，実行時にReflection機能を使ってFormatterクラスまたはFilterクラスを生成します。このため，Reflectionに関する権限が必要です。

(2)　ログマネジャ（LogManager）のプロパティを設定する場合

ログマネジャのプロパティを設定する場合は，次に示す行を追加します。

permission java.util.PropertyPermission "*", "read, write";

ログマネジャがログ出力用のプロパティの値を読み込んだり，書き込んだりするための権限（Propertyのset**）が必要となります。

(3)　J2SE標準のファイルハンドラを使用する場合（File出力を行うクラス（FileHandler，CJMessageFileHandler）を使用する場合）

File出力を行うクラス（FileHandler，CJMessageFileHandler）を使用する場合は，次に示す行を追加します。

permission java.io.FilePermission "<<ALL FILES>>", "read, write";

ログを実際にファイルに出力するための権限が必要です。ログのファイルへの出力には，読み取り権限だけではなく，書き込み権限も必要です。

(4)　JavaロギングAPIのLogger.addHandlerメソッドなどを使用してログ体系を変更する場合

J2SE1.4仕様のロギングAPIを使用する場合は，次に示す行を追加します。

permission java.util.logging.LoggingPermission "control";

JavaロギングAPIを使用するためのセキュリティパーミッションの指定が必要です。この値を指定しないと，ロギングAPIが使用できません。

(5)　設定例

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";
  permission javax.security.auth.AuthPermission "getSubject";
  permission javax.security.auth.AuthPermission "createLoginContext.*";

  //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 アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.5　server.policy（J2EEサーバ用セキュリティポリシーファイル）」を参照してください。

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

ここでは，具体的な例を示して，J2EEアプリケーションのユーザログを出力するための設定について説明します。

＜この項の構成＞

(1)　ユーザログ出力で使用する例

(2)　ユーザログ出力の設定例

(1)　ユーザログ出力で使用する例

次に示す例を使用して，J2EEアプリケーションのユーザログ出力の設定について説明します。使用する例の概要を次の図に示します。

図12-4　J2EEアプリケーションのユーザログ出力例

A社では，ロガーの機能を使用して，業務履歴としてJ2EEアプリケーションの動作履歴をログファイルに出力します。A社のJ2EEアプリケーションのうち，動作履歴を出力したいJ2EEアプリケーションは「Application1」と「Application2」の2種類です。J2EEアプリケーションごとに，別々のファイルに異なるメッセージレベルのログを出力します。また，J2EEアプリケーション名のディレクトリを作成して，それぞれのログファイルを格納します。

(a)　「Application1」の特徴

「Application1」のロガー名称は「com.example.userlogger1」とします。

「Application1」は，複雑で規模の大きいJ2EEアプリケーションです。「SEVERE」レベルの重大なエラーが起こったときに，原因の切り分けを素早く行うために，JavaのExceptionのトレース情報を含むメッセージを「logfileA」に残しておきます。また，動作のトレースログとして「INFO」レベル以下のメッセージを「logfileB」に出力します。「com.example.userlogger1」からは，ログの出力レベルおよび出力内容に応じて2種類のログファイルを出力するために，「conf1」と「conf2」という2種類のCJMessageFileHandlerハンドラを作成しています。

「logfileA」の詳細

トレース情報を取得するため，「logfileA」への出力フォーマッタとして，「CJSimpleFormatter」を使用します。

「logfileA」は，「SEVERE」レベルのメッセージだけが出力されるため，それほど多くのファイル容量を必要としません。しかし，トレース情報を出力するので，1メッセージ当たりのレコードは大きく（最大約4,096バイト），10,000レコードを蓄積できるようにするためには約40メガバイトの容量が必要となります。このため，サイズは10メガバイト，面数は4とします。

「Application1」が出力したメッセージであることを判別するために，J2EEアプリケーション名を「my_app1」とします。

「logfileB」の詳細

「logfileB」は，「INFO」レベル以下のすべてのメッセージが出力されるため，多くのファイル容量を必要とします。1日当たりのメッセージ量と保存期間から算出したログディスク容量は約256メガバイトです。また，ファイルの最大面数は16であるため，サイズは16メガバイト，面数は16とします。

「Application1」が出力したメッセージであることを判別するために，J2EEアプリケーション名を「my_app1」とします。

(b)　「Application2」の特徴

「Application2」のロガー名称は「com.example.userlogger2」とします。

「Application2」は，ログメッセージの作りこみ品質が高く，規模が小さいJ2EEアプリケーションです。必要最小限のメッセージだけをログに出力するため，「WARNING」レベル以上のメッセージを「logfileC」に残します。「com.example.userlogger2」からは1種類のログファイルを出力するため，「conf3」というCJMessageFileHandlerハンドラを作成しています。

「logfileC」の詳細

「WARNING」レベルのメッセージだけが出力されます。また，1メッセージ当たりの最大長が約200バイトであるので，10,000レコードを蓄積するためには約2メガバイトの容量が必要となります。このため，サイズは1メガバイト，面数は2とします。

「Application2」が出力したメッセージであることを判別するために，J2EEアプリケーション名を「my_app2」とします。

(c)　デバッグ用の設定

開発中のデバッグ用の設定もしておきます。「com.example.userlogger1」と「com.example.userlogger2」へ送信されてきたすべてのメッセージの内容を表示するために，ロガー名称「com.example」のロガーへ，java.util.loggingの「ConsoleHandler」を接続しておきます。このロガーでは，子のロガーから伝播されるすべてのメッセージの内容を表示したいので，ロガーおよびハンドラのログ取得レベルは「ALL」とします。

(2)　ユーザログ出力の設定例

「(1)　ユーザログ出力で使用する例」で示した例でユーザログを出力する場合の設定例を次に示します。

(a)　簡易構築定義ファイルの設定例

簡易構築定義ファイルの設定例（物理ティアの定義の場合）を次に示します。

<configuration>
 <logical-server-type>j2ee-server</logical-server-type>
<!-- ロガーに渡されたログレコードを，親ロガーが使用しているハンドラに -->
<!-- 伝播させないようにします（ルートロガーがデフォルトで存在するため）。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.useParentHandlers</param-name>
   <param-value>false</param-value>
 </param>
<!-- 「logfileA」のJ2EEアプリケーション名，出力先，サイズ，面数，ログ取得レベル， -->
<!-- 使用するフォーマッタ名を指定します。 -->
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.appname</param-name>
   <param-value>my_app1</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.path</param-name>
   <param-value>application1/logfileA</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.limit</param-name>
   <param-value>10485760</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.count</param-name>
   <param-value>4</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.level</param-name>
   <param-value>SEVERE</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf1.formatter</param-name>
   <param-value>com.hitachi.software.ejb.application.userlog.CJSimpleFormatter</param-value>
 </param>

<!-- 「logfileB」のJ2EEアプリケーション名，出力先，サイズ，面数，ログ取得レベルを指定します。 -->
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf2.appname</param-name>
   <param-value>my_app1</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf2.path</param-name>
   <param-value>application1/logfileB</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf2.limit</param-name>
   <param-value>16777216</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf2.count</param-name>
   <param-value>16</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf2.level</param-name>
   <param-value>INFO</param-value>
 </param>

<!-- 「com.example.userlogger1」の使用するハンドラ名称「conf1」「conf2」の設定を使用して，-->
<!-- ファイルハンドラ（CJMessageFileHandler）を初期化して接続します。-->
<!-- ここで，ロガーとハンドラが作成されます。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger1.handlers</param-name>
   <param-value>com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf1,com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf2</param-value>
 </param>

<!-- 「com.example.userlogger1」のログ取得レベルを指定します。-->
<!-- 「conf1」「conf2」のレベルの高い方に合わせて，「INFO」とします。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger1.level</param-name>
   <param-value>INFO</param-value>
 </param>

<!-- 「logfileC」の出力先，ログ取得レベルを指定します。-->
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf3.appname</param-name>
   <param-value>my_app2</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf3.path</param-name>
   <param-value>application2/logfileC</param-value>
 </param>
 <param>
   <param-name>ejbserver.application.userlog.CJLogHandler.conf3.level</param-name>
   <param-value>WARNING</param-value>
 </param>

<!-- 「com.example.userlogger2」の使用するハンドラ名称「conf3」の設定を使用して，-->
<!-- ファイルハンドラ（CJMessageFileHandler）を初期化して接続します。-->
<!-- ここで，ロガーとハンドラが作成されます。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger2.handlers</param-name>
   <param-value>com.hitachi.software.ejb.application.userlog.CJMessageFileHandler;conf3</param-value>
 </param>

<!-- 「com.example.userlogger2」のログ取得レベルを指定します。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger2.level</param-name>
   <param-value>WARNING</param-value>
 </param>

<!-- デバッグ用の設定をします************************************************-->
<!-- 「ConsoleHandler」のログ取得レベルを指定します。-->
 <param>
   <param-name>java.util.logging.ConsoleHandler.level</param-name>
   <param-value>INFO</param-value>
 </param>

<!-- 「com.example」のロガーで使用するハンドラ名称「ConsoleHandler」を指定して，-->
<!-- ハンドラに接続します。ここで，ロガーとハンドラが作成されます。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.handlers</param-name>
   <param-value>java.util.logging.ConsoleHandler</param-value>
 </param>

<!-- 「com.example」のロガーのログ取得レベルを指定します。-->
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.level</param-name>
   <param-value>ALL</param-value>
 </param>

<!-- デバッグが不要になった場合は，親のロガーへの伝播の設定を解除します。-->
<!--
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger1.useParentHandlers</param-name>
   <param-value>false</param-value>
 </param>
-->
<!--
 <param>
   <param-name>ejbserver.application.userlog.Logger.com.example.userlogger2.useParentHandlers</param-name>
   <param-value>false</param-value>
 </param>
-->
<!-- デバッグが不要になった場合は，「com.example」の作成を解除します。-->
<!--
 <param>
   <param-name>ejbserver.application.userlog.loggers</param-name>
   <param-value>com.example.userlogger1, com.example.userlogger2</param-value>
 </param>
-->
<!-- *************************************************************************-->

<!-- ロガーの使用を宣言します。-->
 <param>
   <param-name>ejbserver.application.userlog.loggers</param-name>
   <param-value>com.example,com.example.userlogger1,com.example.userlogger2</param-value>
 </param>
</configuration>

(b)　「Application1」の設定例

「Application1」のソースコード例を次に示します。

import java.util.logging.*;
import com.hitachi.software.ejb.application.userlog.*;

public class application1{

   static Logger logger = Logger.getLogger("com.example.userlogger1");

   public static void exec(){

       logger.log(
                  CJLogRecord.create(Level.INFO,
                  "application1 start.","AP1_10000-I"));

       try{

           throw new Exception("Exception1!");

       }
       catch(Exception ex){

           logger.log(
                      CJLogRecord.create(Level.SEVERE,
                      "Catch an exception!", ex, "AP1_10100-E"));

       }

       logger.log(
                  CJLogRecord.create(Level.INFO,
                  "application1 end.","AP1_10001-I"));

   }

}

application1/logfileA1.logの出力例を次に示します。

    yyyy/mm/dd hh:mm:ss.sss            pid      tid      message-id  message(LANG=ja)
0047 2003/12/06 19:51:32.265  my_app1   00EB7859 012A54F9 AP1_10100-E 2003/12/06
19:51:32|application1|exec|致命的|Catch an exception!|java.lang.Exception:
Exception1!|application1.exec(application1.java.18)|application1.main(application1.java.64)

application1/logfileB1.logの出力例を次に示します。

    yyyy/mm/dd hh:mm:ss.sss           pid      tid      message-id   message(LANG=ja)
0046 2003/12/06 19:51:32.250  my_app1  00EB7859 012A54F9 AP1_10000-I  application1 start.
0048 2003/12/06 19:51:32.265  my_app1  00EB7859 012A54F9 AP1_10100-E  Catch an exception!
0049 2003/12/06 19:51:32.265  my_app1  00EB7859 012A54F9 AP1_10001-I  application1 end.

コンソール画面の出力例を次に示します。

情報: application1 start.
2003/12/06 19:51:32 application1 exec
致命的: Catch an exception!
java.lang.Exception: Exception1!
       at application1.exec(application1.java:18)
       at application1.main(application1.java:64)
2003/12/06 19:51:32 application1 exec
情報: application1 end.

(c)　「Application2」の設定例

「Application2」のソースコード例を次に示します。

import java.util.logging.*;
import com.hitachi.software.ejb.application.userlog.*;

public class application2{

   static Logger logger = Logger.getLogger("com.example.userlogger2");

   public static void exec(){

       logger.log(
                  CJLogRecord.create(Level.INFO,
                  "application2 start.","AP2_20000-I"));

       try{

           throw new Exception("Exception2!");

       }
       catch(Exception ex){

           logger.log(
                       CJLogRecord.create(Level.SEVERE,
                      "Catch an exception!", ex, "AP2_20100-E"));

       }

       logger.log(
                  CJLogRecord.create(Level.INFO,
                  "application2 end.","AP2_20001-I"));

   }

}

application2/logfileC1.logの出力例を次に示します。

    yyyy/mm/dd hh:mm:ss.sss           pid      tid      message-id   message(LANG=ja)
0048 2003/12/06 19:51:32.265  my_app2  00EB7859 012A54F9 AP2_20100-E  Catch an exception!

(d)　「Application3」の設定例

さらに，「Application3」というJ2EEアプリケーションのログを「Application1」と同じログファイルに出力する場合の例を説明します。この場合，「Application3」は「Application1」と同じプロセス内（スレッドは異なっていてもよい）で同じロガー名称を使用してロガーを取得する必要があります。

「Application3」のソースコード例を次に示します。

import java.util.logging.*;
import com.hitachi.software.ejb.application.userlog.*;

public class application1{

   static Logger logger = Logger.getLogger("com.example.userlogger1");

   public static void exec(){

       logger.log(,
                  CJLogRecord.create(Level.INFO,
                  "application3 start.","my_app3","AP3_30000-I"));

       try{

           throw new Exception("Exception3!");

       }
       catch(Exception ex){

           logger.log(,
                      CJLogRecord.create(Level.SEVERE,
                      "Catch an exception!", ex, "my_app3","AP3_30100-E"));

       }

       logger.log(
                  CJLogRecord.create(Level.INFO,
                  "application3 end.","my_app3","AP3_30001-I"));

   }

}

application1/logfileB1.logの出力例を次に示します。

    yyyy/mm/dd hh:mm:ss.sss           pid      tid      message-id   message(LANG=ja)
0046 2003/12/06 19:51:32.250  my_app1  00EB7859 012A54F9 AP1_10000-I  application1 start.
0093 2003/12/06 19:51:32.265  my_app3  00EB7859 010CB027 AP3_30000-I  application3 start.
0095 2003/12/06 19:51:32.265  my_app1  00EB7859 012A54F9 AP1_10100-E  Catch an exception!

12.9　バッチアプリケーションのユーザログ出力の設定

バッチアプリケーションのユーザログ出力の設定は，J2EEアプリケーションのユーザログと同じです。設定方法については，「12.8　J2EEアプリケーションのユーザログ出力の設定」を参照してください。

ただし，バッチアプリケーションの場合，セキュリティポリシーの設定は不要です。

12.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）

EJBクライアントアプリケーションのユーザログ出力の設定について説明します。

EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。ここでは，cjclstartapコマンドを使用して開始する場合の設定について説明します。

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）でユーザログの設定をします。ejbserver.applicationから始まるキーで，ユーザログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどを指定してください。指定できるキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.3　usrconf.properties（バッチサーバ用ユーザプロパティファイル）」を参照してください。

また，EJBクライアントアプリケーションのオプション定義ファイル（usrconf.cfg）で，クラスパスにJARファイルを設定します。クラスパスへのJARファイルの設定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

12.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）

ここでは，EJBクライアントアプリケーションを，vbjコマンドを使用して開始する場合の設定について説明します。vbjコマンドを使用して開始する場合，ユーザログ機能を利用するための実装が必要です。

ここでは，EJBクライアントアプリケーションでユーザログ機能を利用するための準備と，ユーザログが出力されるまでの処理の流れについて説明します。

＜この節の構成＞

12.11.1　vbjコマンドを使用する場合の処理の概要

12.11.2　利用の準備

12.11.3　ユーザログ出力処理の流れ

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

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

12.11.1　vbjコマンドを使用する場合の処理の概要

EJBクライアントアプリケーションのユーザログのファイルハンドラとして，CJMPMessageFileHandlerが提供されています。vbjコマンドを使用する場合は，CJMPMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどは，EJBクライアントアプリケーションのユーザログ用の設定ファイルで設定します。

ユーザログ機能を実装する際，EJBクライアントアプリケーションのユーザログ用の設定ファイルに，CJMPMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタとフォーマッタなどを設定します。ユーザアプリケーションプログラムでは，ユーザログ用の設定ファイルを読み込むように記述する必要があります。

EJBクライアントアプリケーションの開始コマンド実行時に，設定ファイルがユーザアプリケーションプログラムから読み込まれて，EJBクライアントアプリケーションのシステムプロパティに設定されます。

12.11.2　利用の準備

EJBクライアントアプリケーションでユーザログ機能を利用する場合には，次の準備が必要です。

なお，EJBクライアントアプリケーションでユーザログ機能を利用する前提として，Application Server側での設定が必要になります。

ユーザログ機能用の設定ファイルの準備
システムプロパティを設定するための，ユーザログ機能用の設定ファイルを準備します。設定ファイルは，J2SEのプロパティファイル形式で記述します。ファイル名称および格納ディレクトリは任意です。
設定ファイルには，J2EEサーバ用のusrconf.propertiesに指定できるキーのうち，「ejbserver.application.userlog」で始まるキーを指定できます。指定できるキーについては，マニュアル「Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.4　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

システムプロパティの設定処理の実装
設定ファイルを読み込んでシステムプロパティに設定するための処理を，EJBクライアントアプリケーションのソースコードに追加する必要があります。この処理は，EJBクライアント機能の初期化が実行される処理よりも前に実行されるようにする必要があります。

JARファイルのクラスパスの追加
EJBクライアントアプリケーションを開始するときのクラスパスに，使用するハンドラに対応するJARファイルのクラスパスを追加してください。クラスパスの指定については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

参考

EJBクライアントアプリケーションでユーザログ機能を利用する場合，セキュリティポリシーを設定する必要はありません。

12.11.3　ユーザログ出力処理の流れ

EJBクライアントアプリケーションでのユーザログの出力は，次の流れで行われます。

システムプロパティの設定
設定ファイルを利用してシステムプロパティが設定されます。

EJBクライアントの初期化
EJBクライアント機能を初期化するメソッドが呼び出されて，ログ体系が構築されます。

JavaロギングAPIの実行
JavaロギングAPIの実行によって，ユーザログが出力されます。

流れに沿って，それぞれの処理内容について説明します。

＜この項の構成＞

(1)　システムプロパティの設定

(2)　EJBクライアント機能の初期化

(3)　JavaロギングAPIの実行

(1)　システムプロパティの設定

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」に作成します。このユーザログ出力ディレクトリを使用している間は，このファイルを変更または削除しないでください。

(2)　EJBクライアント機能の初期化

EJBクライアント機能を初期化するメソッドが呼び出されて，ログ体系が構築されます。EJBクライアント機能は，次のどれかのタイミングで初期化されます。

JNDIの初期コンテキスト生成（new InitialContextメソッド）

セキュリティ機能APIでのログイン（LoginInfoManagerクラスのloginメソッド）

通信タイムアウト機能APIでの通信タイムアウト設定用オブジェクトの取得（RequestTimeoutConfigFactoryクラスのgetRequestTimeoutConfigメソッド）

注意

初期化処理が失敗した場合，EJBクライアントアプリケーションのユーザログを出力する機能は使用できません。ただし，ユーザアプリケーションのソースコード上で，J2SE標準のHandlerクラスやLoggerクラス，またはユーザが独自に作成したHandlerクラスやLoggerクラスの設定および構築をして，ログを出力することはできます。

(3)　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メソッドは使用しないでください。

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

ユーザが作成した独自のクラス（Formatter，Filter，Handler）をEJBクライアントアプリケーションのユーザログ機能で利用するには，ユーザが作成した独自のクラスをEJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに指定します。

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

ユーザが作成した独自のFilterクラス，Formatterクラス，またはHandlerクラスを，EJBクライアントアプリケーションのユーザログ機能で使用する場合は，EJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに，ユーザ作成のクラスを指定してください。

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

ここでは，ユーザログ機能を使用する場合の注意事項について説明します。

＜この節の構成＞

(1)　LogManagerのカスタマイズについて

(2)　ユーザが作成したフィルタ・フォーマッタを使用する場合の注意

(3)　ロガーとハンドラとの接続

(4)　EJBクライアントアプリケーションのログの出力モードの設定

(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）を接続することはできません。

(4)　EJBクライアントアプリケーションのログの出力モードの設定

EJBクライアントアプリケーションのログの出力方法には，2種類のモードがあります。プロセスごとにログ出力先のサブディレクトリを作成する動作モードのことをサブディレクトリ専有モード，複数のプロセスでログ出力先のサブディレクトリを共有する動作モードのことをサブディレクトリ共有モードといいます。

サブディレクトリ専有モードは06-50よりも前のバージョンとの互換用に使用するモードであるため，EJBクライアントアプリケーションを新たに作成する場合は，サブディレクトリ共有モードの使用をお勧めします。

EJBクライアントアプリケーションのユーザログ機能を使用する場合，またはcjclstartapコマンドでEJBクライアントアプリケーションを実行する場合は，サブディレクトリ共有モードを使用してください。

EJBアプリケーションのログの出力方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.8　EJBクライアントアプリケーションのシステムログ出力」を参照してください。また，EJBアプリケーションのログを出力するサブディレクトリについては，マニュアル「Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編」の「7.6.1　アプリケーションのユーザログの取得」を参照してください。

13.　スレッドの非同期並行処理

この章では，Timer and Work Manager for Application Serversに準拠したTimerManagerおよびWorkManagerによるスレッドの非同期並行処理について説明します。

＜この章の構成＞

13.1　この章の構成

13.2　スレッドの非同期並行処理の概要

13.3　TimerManagerを使用した非同期タイマ処理

13.4　 WorkManagerを使用した非同期スレッド処理

13.1　この章の構成

スレッドの非同期並行処理の機能と参照先を次の表に示します。

表13-1　スレッドの非同期並行処理の機能

機能名 | 参照先
スレッドの非同期並行処理の概要 | 13.2
TimerManagerを使用した非同期タイマ処理 | 13.3
WorkManagerを使用した非同期スレッド処理 | 13.4

13.2　スレッドの非同期並行処理の概要

アプリケーションサーバでは，Java EE環境で非同期タイマ処理や非同期スレッド処理などのスレッドの非同期並行処理を実行できます。

Java EEの標準仕様では，サーブレットから新しいスレッドを生成したりEJBがスレッドを管理したりすることができません。また，スレッドの非同期並行処理は原則的に推奨されていません。そのため，アプリケーションサーバでは，Java EE環境でスレッドの非同期並行処理を実現するために，CommonJが定めたTimer and Work Manager for Application Serversの仕様に基づいたAPIを提供します。

スレッドの非同期並行処理を実現するためのAPIの概要を次に示します。

TimerManager
Timer for Application Serversの仕様に準拠したAPIです。このAPIを使用すると，実行間隔を指定してスレッドの非同期処理をスケジューリングできます。この機能を非同期タイマ処理と呼びます。

WorkManager
Work Manager for Application Serversの仕様に準拠したAPIです。このAPIを使用すると，スレッドの非同期処理ができます。この機能を非同期スレッド処理と呼びます。

TimerManagerおよびWorkManagerは，EJBまたはサーブレットから使用できます。

アプリケーションサーバの，Timer and Work Manager for Application Serversへの対応状況については，「13.2.3　Timer and Work Manager for Application Serversとの対応」を参照してください。

＜この節の構成＞

13.2.1　スレッドの非同期並行処理の流れ

13.2.2　スレッドの非同期並行処理で使用できるJava EEの機能

13.2.3　Timer and Work Manager for Application Serversとの対応

13.2.1　スレッドの非同期並行処理の流れ

スレッドの非同期並行処理を実行するには，EJBおよびサーブレットからTimerManagerまたはWorkManagerをルックアップします。ここでは，TimerManagerを使用した非同期タイマ処理，およびWorkManagerを使用した非同期スレッド処理の流れについて説明します。

TimerManagerを使用した非同期タイマ処理の流れ

TimerManagerを使用した非同期タイマ処理の流れを次の図に示します。

図13-1　TimerManagerを使用した非同期タイマ処理の流れ

EJBおよびサーブレットは，実行する非同期並行処理を呼び出す，スケジュール元となります。

TimerManagerは，JNDIによるルックアップ時に作成されます。実行する処理の実体は，TimerManagerが提供するリスナであるTimerListenerに実装します。TimerListenerは，必要に応じてJNDIやJCAにアクセスして処理を実行します。

WorkManagerを使用した非同期スレッド処理の流れ

WorkManagerを使用した非同期スレッド処理の流れを次の図に示します。

図13-2　WorkManagerを使用した非同期スレッド処理の流れ

EJBおよびサーブレットは，実行する非同期並行処理を呼び出す，スケジュール元となります。

WorkManagerは，アプリケーション開始時に作成されます。JNDIによってルックアップされた場合は，アプリケーション開始時に作成されたWorkManagerを返します。実行する処理の実体は，WorkManagerが提供するWorkまたはWorkListenerに実装します。WorkまたはWorkListenerは，必要に応じてJNDIやJCAにアクセスして処理を実行します。

13.2.2　スレッドの非同期並行処理で使用できるJava EEの機能

非同期並行処理として実行する処理の中では，Java EEの機能を使用できます。Java EEの機能を使用できるTimerManagerおよびWorkManagerのAPIを次に示します。

TimerManager

TimerListener.timerExpired
設定した時間に達したときに実行されるメソッドです。

StopTimerListener.timerStop
TimerManager.stopメソッドが実行されたとき，またはアプリケーションが停止したときに実行されるメソッドです。

CancelTimerListener.timerCancel
TimerManager.cancelメソッドが実行されたときに実行されるメソッドです。

WorkManager

Work.run
WorkManagerで非同期に実行される処理メソッドです。

WorkListener.workAccepted
スケジュールしたWorkをWorkManagerが受け付けるときに実行されるメソッドです。

WorkListener.workCompleted
スケジュールされたWorkのrunメソッドが終了した直後に実行されるメソッドです。

WorkListener.workRejected
スケジュールしたWorkをWorkManagerが受け付けたあとに，スケジュール処理を継続できなくなった場合に実行されるメソッドです。

WorkListener.workStarted
スケジュールされたWorkのrunメソッドが実行される直前に実行されるメソッドです。

それぞれのAPIの詳細については，Timer and Work Manager for Application ServersのAPI仕様を参照してください。

TimerManagerおよびWorkManagerで使用できるJava EE機能を次の表に示します。

表13-2　TimerManagerおよびWorkManagerで使用できるJava EEの機能

機能名 | 使用可否 | 参照先
Enterprise Beanの呼び出し | × | －
ネーミングサービス | ○※ | (1)
トランザクションサービスとリソース接続 | ○※ | (2)
ログとトレースの出力 | ○ | (3)
コンテナ拡張ライブラリの利用 | ○ | (4)
メソッドキャンセル | × | －

（凡例）

○：使用できる

×：使用できない

－：該当なし

注※　ただし，一部の機能については使用できません。使用できる機能については，「参照先」の列に示す情報を参照してください。

次に，TimerManagerおよびWorkManagerで使用できる機能を詳細に分類して説明します。また，それぞれの機能を使用する場合の注意事項についても説明します。

＜この項の構成＞

(1)　ネーミングサービス

(2)　トランザクションサービスとリソース接続

(3)　ログとトレースの出力

(4)　コンテナ拡張ライブラリの利用

(1)　ネーミングサービス

ネーミングサービスとして提供する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表13-3　ネーミングサービスの機能の使用可否

機能名 | 使用可否
JNDIを使用したDB Connectorのルックアップ | ○
JNDIを使用したJava Mailのルックアップ | ×
JNDIを使用したJavaBeansリソースのルックアップ | ×
JNDIを使用したEntityManagerのルックアップ | ×
JNDIを使用したEntityManagerFactoryのルックアップ | ×
JNDIを使用したTimerManagerのルックアップ | ×※1
JNDIを使用したWorkManagerのルックアップ | ×※1
JNDIを使用したユーザトランザクションのルックアップ | ○※2

（凡例）

○：使用できる

×：使用できない

注※1　TimerManagerやWorkManagerのスケジュールの延長で，さらにTimerManagerやWorkManagerを呼び出すことはできません。

注※2　スケジュール元が，CMTでトランザクションを管理するEJBの場合は，java:comp/UserTransactionでルックアップできません。必ずHITACHI_EJB/SERVERS/<J2EEサーバ名>/SERVICES/ UserTransactionを使用してルックアップしてください。

注意

スケジュール元で取得したDB ConnectorやユーザトランザクションをWorkManagerまたはTimerManager中で使用しないでください。必ず実行した処理を実装したTimer ListenerまたはWork内で取得してください。

(2)　トランザクションサービスとリソース接続

リソースアダプタには，DB Connectorだけを使用できます。TimerManagerおよびWorkManagerで使用できるDB Connectorを次の表に示します。

表13-4　DB Connectorの使用可否

DB Connector名 | 使用可否
DBConnector_DABJ_CP.rar | ×
DBConnector_DABJ_XA.rar | ×
DBConnector_HiRDB_Type4_CP.rar | ○
DBConnector_HiRDB_Type4_XA.rar | ○
DBConnector_Oracle_CP.rar | ○
DBConnector_Oracle_XA.rar | ○
DBConnector_DABJ_CP_Cosminexus_RM.rar | ×
DBConnector_DABJ_XA_Cosminexus_RM.rar | ×
DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar | ×
DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar | ×
DBConnector_Oracle_CP_Cosminexus_RM.rar | ×
DBConnector_Oracle_XA_Cosminexus_RM.rar | ×
DBConnector_CP_ClusterPool_Root.rar | ×
DBConnector_Oracle_CP_ClusterPool_Member.rar | ×

（凡例）

○：使用できる

×：使用できない

DB Connectorを使用する場合，トランザクションサポートレベルには，NoTransaction，LocalTransaction，またはXATransactionを指定してください。DB Connectorのコネクションを取得するには，DB Connectorの別名を設定する必要があります。JNDIによるルックアップでは，設定した別名を使用して，DB Connectorのコネクションを取得してください。DB Connectorの別名を使用したコネクションの取得方法については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.4　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

リソース接続およびトランザクションサービスとして提供する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表13-5　トランザクションサービスの機能の使用可否

機能名
使用可否

トランザクション
（ユーザトランザクション）
ローカルトランザクション
○

グローバルトランザクション
○

トランザクションの自動決着※1
△

トランザクションタイムアウト
○

コネクションプーリング
DB Connectorによるコネクションプーリング
○

コネクションプールのウォーミングアップ
○

コネクション数調節
○

コネクションシェアリング※2
△

コネクションアソシエーション
×

DB Connectorのステートメントプーリング
○

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

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

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

コネクション自動クローズ
×

コネクションスイーパ
○

障害調査用SQLの出力
○

（凡例）

○：使用できる

△：一部の機能が使用できない

×：使用できない

注※1　ユーザトランザクションは，リスナの処理メソッドからリターンする前に決着する必要があります。トランザクションが決着していない場合，例外が発生しなくてもトランザクションはロールバックされて，メッセージ（KDJE43179-W）が出力されます。

注※2　シェアリングできるコネクションの範囲は，デフォルトで設定される「同一トランザクション」だけです。

注意

取得したDB Connectorのコネクションは自動でクローズされないため，必ずメソッド内でコネクションをクローズするように設定してください。

(3)　ログとトレースの出力

ログとトレースを出力する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表13-6　ログとトレースの機能の使用可否

機能名 | 使用可否
ユーザログ | ○
性能解析トレース | ○

（凡例）

○：使用できる

参考

性能解析トレースのオペレーション名について

TimerManagerおよびWorkManagerの性能解析トレースでは，スケジュールごとに一意の番号を取得できます。この情報は，トレース情報のオペレーション名に出力されます。取得できるトレース情報の詳細については，マニュアル「Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編」の「7.　性能解析トレースのトレース取得ポイントとPRFトレース取得レベル」を参照してください。

(4)　コンテナ拡張ライブラリの利用

コンテナ拡張ライブラリの機能は，TimerManagerおよびWorkManagerを使用しない場合と同様に使用できます。

13.2.3　Timer and Work Manager for Application Serversとの対応

Timer and Work Manager for Application Serversの仕様で，ベンダ依存と規定されている仕様には，アプリケーションサーバでは対応していません。また，CommonJが提供するAPIとアプリケーションサーバが提供するAPIには，仕様差があります。ここでは，アプリケーションサーバが対応していないTimer for Application Serversの仕様，アプリケーションサーバが対応していないWork Manager for Application Serversの仕様，およびCommonJとアプリケーションサーバで動作が異なるAPIについて説明します。

＜この項の構成＞

(1)　アプリケーションサーバが対応していないTimer for Application Serversの仕様

(2)　アプリケーションサーバが対応していないWork Manager for Application Serversの仕様

(3)　CommonJとアプリケーションサーバで動作が異なるAPI

(1)　アプリケーションサーバが対応していないTimer for Application Serversの仕様

アプリケーションサーバが対応していないTimer for Application Serversの仕様について次の表に示します。

表13-7　アプリケーションサーバが対応していないTimer for Application Serversの仕様（ベンダ依存機能）

アプリケーションサーバが対応していない仕様
備考

最大スケジューリング数のカスタマイズ
最大スケジューリング数は50です。変更できません。

TimerManagerのリスナを実装するクラス

Java EEのコンポーネントを継承しない一般のJavaオブジェクト以外のオブジェクト（EJBやサーブレットなど）

javax.ejb.EnterpriseBeanを継承するクラスをスケジュールした場合，エラーになります。それ以外の場合はエラーチェックをしません。

実行スレッドへのトランザクションコンテキストの継承項目
スケジュール元のトランザクション状態に関係なく，トランザクションなしとなります。CMTのNOT_SUPPORTEDに相当します。

実行スレッドへのJ2EEコンテキストの継承項目のカスタマイズ
継承される項目は一定です。

実行スレッドで使用できるJava EEの機能
使用できる機能については「13.2.2　スレッドの非同期並行処理で使用できるJava EEの機能」を参照してください。

なお，Timer for Application Serversでは，J2EEアプリケーション中で使用できるコンポーネントについて規定されていません。アプリケーションサーバの場合にTimerManagerで使用できるコンポーネントについては，「13.3.5　TimerManagerを使用したアプリケーションの開発」を参照してください。

(2)　アプリケーションサーバが対応していないWork Manager for Application Serversの仕様

アプリケーションサーバが対応していないWork Manager for Application Serversの仕様について次の表に示します。

表13-8　アプリケーションサーバが対応していないWork Manager for Application Serversの仕様（ベンダ依存機能）

アプリケーションサーバが対応していない仕様
備考

WorkManagerを使用した非同期スレッド処理のリモートでの実行
WorkItemをリモートで実行した場合，ローカルで実行されるダミーのRemoteWorkItemを返します。

最大スケジューリング数のカスタマイズ
最大スケジューリング数には制限がありません。

TimerManagerのリスナを実装するクラス

Java EEのコンポーネントを継承しない一般のJavaオブジェクト以外のオブジェクト（EJBやサーブレットなど）

javax.ejb.EnterpriseBeanを継承するクラスをスケジュールした場合，エラーになります。それ以外の場合，エラーチェックはしません。

アプリケーションの開始以外のタイミングでのWorkManagerの作成
WorkManagerはアプリケーションの開始時にだけ作成されます。

実行スレッドへのトランザクションコンテキストの継承項目
スケジュール元のトランザクション状態に関係なく，トランザクションなしとなります。CMTのNOT_SUPPORTEDに相当します。

実行スレッドへのJ2EEコンテキストの継承項目のカスタマイズ
継承される項目は一定です。

実行スレッドで使用できるJava EEの機能
使用できる機能については「13.2.2　スレッドの非同期並行処理で使用できるJava EEの機能」を参照してください。

なお，Work Manager for Application Serversでは，J2EEアプリケーション中で使用できるコンポーネントについて規定されていません。アプリケーションサーバの場合にWorkManagerで使用できるコンポーネントについては，「13.4.4　WorkManagerを使用したアプリケーションの開発」を参照してください。

(3)　CommonJとアプリケーションサーバで動作が異なるAPI

CommonJとアプリケーションサーバで動作が異なるAPIを次の表に示します。

表13-9　CommonJとアプリケーションサーバで動作が異なるAPI

クラス
メソッド
アプリケーションサーバでの動作

commonj.timers.TimerManager
schedule(TimerListener listener,Date time)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,long delay)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,Date firstTime,long period)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,long delay,long period)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

scheduleAtFixedRate(TimerListener listener,Date firstTime,long period)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

scheduleAtFixedRate (TimerListener listener,long delay,long period)
listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

commonj.work.WorkManager
schedule(Work work)
workがnullの場合，WorkExceptionを返します。

schedule(Work work,WorkListener wl)
workがnullの場合，WorkExceptionを返します
WorkListenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

13.3　TimerManagerを使用した非同期タイマ処理

この節では，TimerManagerを使用した非同期タイマ処理について説明します。

この節の構成を次に示します。

表13-10　この節の構成（TimerManagerを使用した非同期タイマ処理）

分類 | タイトル | 参照先
解説 | TimerManagerを使用したスレッドのスケジューリング方式 | 13.3.1
TimerManagerのライフサイクル | 13.3.2
TimerManagerのステータス遷移 | 13.3.3
TimerManagerの多重スケジュール数 | 13.3.4
実装 | TimerManagerを使用したアプリケーションの開発 | 13.3.5

注　「設定」「運用」および「注意事項」について，この機能固有の説明はありません。

TimerManagerを使用した非同期タイマ処理では，Java EE環境で，実行間隔を指定してスレッドの非同期処理をスケジューリングできます。バックグラウンドでは，コンテナで管理されたスレッドを使用するため，安全にタスクを実行できます。

スケジューリングする処理は，TimerListenerで実装します。スケジュール元となるEJBやサーブレットでTimerManagerのメソッドを実行することで，TimerListenerに実装した処理がスケジューリングされます。また，TimerManagerのscheduleメソッドから返されたTimerを使用することで，スケジュールの応答やキャンセルができます。

TimerManagerを使用するには，EJB属性やサーブレット属性の<resource-ref>タグに，TimerManagerに関する情報を定義します。EJBやサーブレットは，デプロイ時に<res-ref-name>タグに定義した名前でルックアップしてTimerManagerを使用します。

＜この節の構成＞

13.3.1　TimerManagerを使用したスレッドのスケジューリング方式

13.3.2　TimerManagerのライフサイクル

13.3.3　TimerManagerのステータス遷移

13.3.4　TimerManagerの多重スケジュール数

13.3.5　TimerManagerを使用したアプリケーションの開発

13.3.1　TimerManagerを使用したスレッドのスケジューリング方式

TimerManagerを使用したスレッドのスケジューリングには，次の二つの方式があります。

1回だけ処理を実行する

一定の間隔で処理を繰り返し実行する

それぞれのスケジューリング方式の概要を次に示します。

＜この項の構成＞

(1)　1回だけ処理を実行する

(2)　一定の間隔で処理を繰り返し実行する

(1)　1回だけ処理を実行する

指定した時間に，1回だけ処理を実行する方式です。処理が実行されると，TimerManagerは破棄されます。

(2)　一定の間隔で処理を繰り返し実行する

一定の間隔で処理を繰り返し実行するには，次の二つの方法があります。

fixed-rate（処理を開始する間隔を指定して繰り返し実行する）

fixed-delay（処理の終了から次の処理の開始までの間隔を指定して繰り返し実行する）

スケジューリングされた処理は，TimerManagerを停止するか，対応するTimerのcancelメソッドが実行されるまで，処理を実行し続けます。

それぞれの方法の概要を次に示します。

fixed-rate（処理を開始する間隔を指定して繰り返し実行する）

一定の間隔で処理を繰り返し開始していく方式です。fixed-rateでは，次の内容を指定します。

最初の処理を開始するタイミング

次のどちらかの方法で指定します。

開始時刻を指定する場合
scheduleAtFixedRateメソッドの引数であるfirstTimeをDate型で指定します。

アプリケーションを開始してから処理を実行するまでの経過時間を指定する場合
scheduleAtFixedRateメソッドの引数であるdelayをlong型で指定します。単位はミリ秒です。

前の処理を開始してから次の処理を開始するまでの間隔

scheduleAtFixedRateメソッドの引数であるperiodをlong型で指定します。単位はミリ秒です。

fixed-rateの処理のイメージを次の図に示します。この図では，アプリケーションの開始から最初の処理を開始するまでの時間を2秒，前の処理を開始してから次の処理を開始するまでの時間を3秒としています。

図13-3　fixed-rateの処理のイメージ

fixed-rateの処理では，前に実行された処理時間がperiodに指定した時間より長かった場合，前に実行された処理が終わった直後に次の処理が開始されます。この図では，3回目の処理時間がperiodで指定した時間である3秒より長かったため，3回目の処理が終わった直後に4回目の処理が開始されています。

fixed-delay（処理の終了から次の処理の開始までの間隔を指定して繰り返し実行する）

前の処理が終了してから，一定の間隔を置いて処理を繰り返し開始していく方式です。fixed-delayでは，次の内容を指定します。

最初の処理を開始するタイミング

次のどちらかの方法で指定します。

開始時刻を指定する場合
scheduleメソッドの引数であるfirstTimeをDate型で指定します。

アプリケーションを開始してから処理を実行するまでの経過時間を指定する場合
scheduleメソッドの引数であるdelayをlong型で指定します。単位はミリ秒です。

前の処理が終了してから次の処理を開始するまでの間隔

scheduleメソッドの引数であるperiodをlong型で指定します。単位はミリ秒です。

fixed-delayの処理のイメージを次の図に示します。この図では，アプリケーションの開始から最初の処理を開始するまでの時間，および前の処理が終了してから次の処理を開始するまでの時間を2秒としています。

図13-4　fixed-delayの処理のイメージ

13.3.2　TimerManagerのライフサイクル

ここでは，TimerManagerのライフサイクルについて説明します。

TimerManagerは，アプリケーション中でJNDIによってルックアップされた時に作成されます。ルックアップされるたびに，新しいTimerManagerが作成されます。作成されたTimerManagerは，アプリケーション中でstopメソッドを実行して，明示的に停止することをお勧めします。stopメソッドを実行しないで自動でTimerManagerを停止することもできますが，その場合，TimerManagerが停止するまでアプリケーションも停止しません。そのため，TimerManagerの停止処理に伴って，アプリケーションの停止にも時間が掛かることがあります。

また，TimerManagerは永続化されません。そのため，JavaVMが終了した場合，作成されたTimerManagerおよびスケジュールされたタイマは破棄されます。

TimerManagerのライフサイクルを次の図に示します。

図13-5　TimerManagerのライフサイクル

13.3.3　TimerManagerのステータス遷移

TimerManagerは，サスペンド（一時停止），リジューム（再開）などによる閉塞や，停止の処理に伴って，ステータスが遷移します。そのときのTimerManagerのステータスは，isStoppedメソッド，isStoppingメソッド，isSuspendedメソッドなどを使用して確認できます。TimerManagerのステータス遷移を次の図に示します。

図13-6　TimerManagerのステータス遷移

それぞれのステータスの詳細について次の表に示します。

表13-11　TimerManagerのステータス

図中の番号※ | ステータス | 説明
1 | running | TimerManagerが実行中の状態です。新規スケジュールの受付と実行ができます。
2 | suspending | サスペンド実行中の状態です。サスペンドが実行されたときに，実行中のタスクが残っていることを示します。実行中のタスクがなくなるとステータスがsuspendedに遷移します。
3 | suspended | すべてのタスクがサスペンドされている状態です。ステータスがsuspendedのときは，スケジューリングされたすべてのタスクは実行されません。ステータスがsuspendedのタスクは，リジュームされた時に実行されます。
4 | stopping | TimerManagerの停止処理が実行中の状態です。停止処理が実行されたときに，実行中のタスクが残っていることを示します。実行中のタスクがなくなるとステータスがstoppedに遷移します。
5 | stopped | TimerManagerが停止した状態です。すべてのタスクが停止されて，それ以降実行されないことを示しています。一度停止したTimerManagerは再開できません。

注※　番号は，図13-6の番号を示します。

13.3.4　TimerManagerの多重スケジュール数

TimerManagerでスケジュールされたタイマ処理では，スレッドプールで管理されたスレッドを使用します。タイマ処理がスケジュールされると，スレッドプールで管理されたスレッドが一つ割り当てられます。スレッドプールに空きスレッドがある場合は，空きスレッドが使用されます。スレッドプールに空きスレッドがない場合は，新しいスレッドが生成されて使用されます。スレッドプールに生成されたスレッドは，TimerManagerが停止するまでプールされます。

同時に使用できるスレッドのインスタンスごとの最大数は，50です。なお，スケジュールしたタイマ処理が待機中の場合も，スレッドは割り当てられます。そのため，同時にスケジュールできる処理の最大数は，タイマ処理の状態に関係なく50です。

すでに生成されたスレッドが最大数に達している場合，スケジュールされたタイマ処理はキューに格納されて，スレッドに空きができるまで待機します。空きスレッドができ次第，キューに格納されたタイマ処理が実行されます。

51以上のスレッドを同時にスケジュールする場合は，複数のTimerManagerを使用してください。

13.3.5　TimerManagerを使用したアプリケーションの開発

ここでは，TimerManagerを使用したアプリケーションの開発について説明します。

TimerManagerを使用する場合の，アプリケーションを構成するコンポーネントの使用可否を次の表に示します。

表13-12　TimerManagerを使用する場合のアプリケーションを構成するコンポーネントの使用可否

コンポーネント | 使用可否
EJBクライアント | ×
リソースアダプタ | ×
JavaBeansリソース | ×
サーブレット／JSP※ | ○
EJB | Stateless Session Bean | EJB2.1以前 | CMT | ○
BMT | ○
EJB3.0 | ×
Stateful Session Bean | ×
Entity Bean | ×
Message-driven Bean | ×

（凡例）

○：使用できる

×：使用できない

注※　サーブレットリスナやフィルタでも使用できます。

TimerManagerを使用するアプリケーションの開発の流れは次のとおりです。

スケジュール元となるEJBまたはサーブレットの属性を定義する

TimerManagerのリスナに実行する処理を実装する

スケジュール元となるEJBまたはサーブレットを作成する

TimerManagerを使用するJ2EEアプリケーションをコンパイルする

それぞれの作業の詳細を次に示します。

＜この項の構成＞

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

(2)　TimerManagerのリスナに実行する処理を実装する

(3)　スケジュール元となるEJBまたはサーブレットを作成する

(4)　TimerManagerを使用するJ2EEアプリケーションをコンパイルする

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

TimerManagerを使用するEJBまたはサーブレットの属性をDDに定義します。TimerManagerを使用するための定義は，アノテーションでは実施できません。

TimerManagerを使用するために定義する必要がある属性を次の表に示します。

表13-13　TimerManagerを使用するために定義する必要がある属性

タグ名
説明

＜ルートタグ＞
－

┣
┃
┃
<description>
任意で設定してください。

┣
┃
┃
┃
<res-ref-name>
JNDI ENC名（JNDIルックアップに使用する名前）を指定してください。

┣
┃
┃
┃
<res-type>
次の内容を設定してください。
「commonj.timers.TimerManager」

┣
┃
┃
<res-auth>
設定した値は無視されます。

┣
┃
┃
┃
┃┃
<res-sharing-scope>
「Unshareable」を設定してください。ただし，「Shareable」を設定しても，「Unshareable」設定時と同様に動作します（ルックアップされるたびに新しいTimerManagerが作成されます）。

┣
┃
┃
<mapped-name>
設定した値は無視されます。

┣
┃
┃
<injection-target>
設定した値は無視されます。

┗
<linked-to>
設定した値は無視されます。

サーブレットでTimerManagerを使用する場合のweb.xmlの定義例を次に示します。

<web-app>
 <display-name>TimerManagerSample</display-name>
 <servlet>
   <servlet-name>SampleServlet</servlet-name>
   <display-name>SampleServlet</display-name>
   <servlet-class>SampleServlet</servlet-class>
 </servlet>
 ・・・
 <resource-ref>
   <res-ref-name>timer/MyTimer</res-ref-name>
   <res-type>commonj.timers.TimerManager</res-type>
   <res-auth>Container</res-auth>
   <res-sharing-scope>Unshareable</res-sharing-scope>
 </resource-ref>
</web-app>

TimerManagerは，アプリケーション中でJNDIによるルックアップが実行されるたびに作成されます。作成されたTimerManagerは，stopメソッドの実行時，またはアプリケーション終了時に破棄されます。なお，TimerManagerは必要に応じて複数定義することもできます。

(2)　TimerManagerのリスナに実行する処理を実装する

TimerManagerを使用するには，実行する処理を実装したリスナを作成する必要があります。リスナのインタフェースには，必ず実装するものと，必要に応じて実装するものがあります。必ず実装するインタフェースと必要に応じて実装するインタフェースを次に示します。

必ず実装するインタフェース

TimerListener

必要に応じて実装するインタフェース

StopTimerListener

CancelTimerListener

APIの詳細については，Timer and Work Manager for Application ServersのAPIの仕様を参照してください。

TimerListener，StopTimerListenerおよびCancelTimerListenerを実装したクラスの例を次に示します。

public class MyTimerListener
       implements TimerListener,StopTimerListener, CancelTimerListener {
   private int count = 0;

       public MyTimerListener() {
       }
       public void timerStop(Timer timer) {
               System.out.println("Timer stopped: " + timer);
       }

       public void timerCancel(Timer timer) {
               System.out.println("Timer cancelled: " + timer);
       }

       public void timerExpired(Timer timer) {
               System.out.println("Timer expired !");
                   if(count++ > 10) {
               //規定回数に到達したためキャンセル
               timer.cancel();
           } else {
            System.out.println("The next timer will fire at : " +
                                  timer.getScheduledExecutionTime());
           }
       }
}

(3)　スケジュール元となるEJBまたはサーブレットを作成する

TimerManagerを使用するには，スケジュール元となるEJBまたはサーブレットに，属性に定義したTimerManagerのJNDI名のルックアップ，およびTimerManagerの処理のスケジューリングを実装します。

属性に定義したTimerManagerのJNDIを使用したルックアップ

属性に定義したTimerManagerのJNDI名をルックアップしてTimerManagerを取得します。ルックアップにはjava:comp/envを使用します。TimerManagerを取得する例を次に示します。

InitialContext ic = new InitialContext();
TimerManager tm = (TimerManager)ic.lookup
                    ("java:comp/env/timer/MyTimer");

TimerManagerの処理のスケジューリング

TimerManagerの処理のスケジューリングは，TimerManagerのscheduleメソッドを呼び出して実行します。TimerManager処理のスケジューリングの例を次に示します。

InitialContext ctx = new InitialContext();
TimerManager mgr = (TimerManager)
             ctx.lookup("java:comp/env/timer/MyTimer");
TimerListener listener = new MyTimerListener();
mgr.schedule(listener, 1000*60,1000*10);
mgr.stop();

(4)　TimerManagerを使用するJ2EEアプリケーションをコンパイルする

TimerManagerを使用するJ2EEアプリケーションをコンパイルする場合は，次のJARファイルを含めてください。

＜Cosminexusのインストールディレクトリ＞¥CC¥lib¥ejbserver.jar

13.4　 WorkManagerを使用した非同期スレッド処理

この節では，WorkManagerを使用した非同期スレッド処理について説明します。

この節の構成を次に示します。

表13-14　この節の構成（WorkManagerを使用した非同期スレッド処理）

分類 | タイトル | 参照先
解説 | デーモンWorkと非デーモンWork | 13.4.1
非デーモンWorkで使用するスレッドプールとキューについて | 13.4.2
WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル | 13.4.3
実装 | WorkManagerを使用したアプリケーションの開発 | 13.4.4
設定 | 実行環境での設定 | 13.4.5

注　「運用」および「注意事項」について，この機能固有の説明はありません。

WorkManagerを使用した非同期スレッド処理では，Java EE環境で，スレッドの非同期処理を実行できます。バックグラウンドでは，コンテナで管理されたスレッドを使用するため，安全にタスクを実行できます。

非同期で実行する処理は，Workで実装します。スケジュール元となるEJBやサーブレットでWorkManagerのscheduleメソッドを実行することで，Workに実装した処理がスケジューリングされます。また，WorkManagerのscheduleメソッドから返されたWorkItemを使用することで，スケジュールの状態を確認できます。

WorkManagerを使用するには，EJB属性やサーブレット属性の<resource-ref>タグに，WorkManagerに関する情報を定義します。EJBやサーブレットは，デプロイ時に<res-ref-name>タグに定義した名前でルックアップしてWorkManagerを使用します。

＜この節の構成＞

13.4.1　デーモンWorkと非デーモンWork

13.4.2　非デーモンWorkで使用するスレッドプールとキューについて

13.4.3　WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル

13.4.4　WorkManagerを使用したアプリケーションの開発

13.4.5　実行環境の設定

13.4.1　デーモンWorkと非デーモンWork

WorkManagerでは，デーモンWork（長寿命Work）と非デーモンWork（短寿命Work）の2種類のWorkを作成できます。それぞれのWorkの概要を次に示します。

デーモンWork（長寿命Work）
デーモンWorkは，scheduleメソッドの実行時に作成されて，サーブレットやEJBのリクエスト処理が終了しても実行され続けます。また，WorkManagerの終了時に破棄されます。デーモンWorkは，スレッドプールのスレッドではなく，常に新しく作成されたスレッドで実行されます。

非デーモンWork（短寿命Work）
非デーモンWorkは，scheduleメソッドの実行時に作成されて，runメソッドの処理の終了時に破棄されます。非デーモンWorkは，スレッドプールで管理されたスレッドおよびキューを使用します。

13.4.2　非デーモンWorkで使用するスレッドプールとキューについて

非デーモンWorkは，スレッドプールとキューを使用して処理されます。処理で使用されるスレッドプールおよびキューは，DDで定義したWorkManager単位で作成されます。なお，スレッドプールにプールできるスレッドの最大サイズを設定します。次に，非デーモンWorkがスケジュールされたとき，プールできるスレッドの最大サイズと，プール内のスレッド数の関係と動作について説明します。

プール内のスレッドが，スレッドプールの最大スレッド数より少ない場合
新しいスレッドを作成して，非デーモンWorkを実行します。なお，スレッドは，スレッドプールの中に空きスレッドがあるかどうかに関係なく，生成されます。

プール内に，スレッドプールの最大スレッド数で設定した数だけスレッドがある場合
スレッドプールの中の空きスレッドを使用して非デーモンWorkを実行します。空きスレッドがないときには，スケジュールされた非デーモンWorkはキューに格納されます。キューに格納された非デーモンWorkは，空きスレッドができると実行されます。

スレッドプールの最大スレッド数は，デフォルトで10となっています。最大スレッド数を変更したい場合は，「13.4.5　実行環境の設定」を参照してください。なお，キューサイズには制限はありません。

ポイント

WorkManagerを停止しようとするときには，実行中のWorkManagerおよびキューに格納されたWorkManagerの処理がすべて終了されてから停止処理が開始されます。また，キュー格納時にWorkManagerが停止された場合でも，キューに格納されたWorkManagerは実行されます。

13.4.3　WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル

ここでは，WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクルについて説明します。

＜この項の構成＞

(1)　WorkManagerのライフサイクル

(2)　デーモンWorkのライフサイクル

(3)　非デーモンWorkのライフサイクル

(1)　WorkManagerのライフサイクル

WorkManagerは，アプリケーション開始時に作成されます。アプリケーション中でルックアップされると，アプリケーション開始時に作成されたWorkManagerが返されます。複数回ルックアップされても，アプリケーション開始時に作成された同じWorkManagerが呼び出されます。WorkManagerは，アプリケーションの停止時に破棄されます。

また，WorkManagerは永続化されません。そのため，JavaVMが終了した場合，作成されたWorkManagerおよびスケジュールされた非同期処理は破棄されます。

WorkManagerのライフサイクルを次の図に示します。

図13-7　WorkManagerのライフサイクル

(2)　デーモンWorkのライフサイクル

デーモンWorkは，scheduleメソッドの実行時に作成されます。また，WorkManagerの停止時（WorkManagerに対応するアプリケーションの停止時）に破棄されます。WorkManagerの停止時には，WorkManagerはデーモンWorkのreleaseメソッドを実行したあと，すべてのデーモンWorkが終了するまで待機します。

デーモンWorkのライフサイクルを次の図に示します。

図13-8　デーモンWorkのライフサイクル

(3)　非デーモンWorkのライフサイクル

非デーモンWorkは，scheduleメソッドの実行時に作成されます。また，runメソッドの処理が完了すると終了します。非デーモンWorkの実行中の場合またはキューで実行待ちの場合にWorkManagerを停止したとき（対応するアプリケーションを停止したとき），非デーモンWorkが停止するまで待機してから終了します。

非デーモンWorkのライフサイクルを次の図に示します。

図13-9　非デーモンWorkのライフサイクル

13.4.4　WorkManagerを使用したアプリケーションの開発

ここでは，WorkManagerを使用したアプリケーションの開発について説明します。

WorkManagerを使用する場合の，アプリケーションを構成するコンポーネントの使用可否を次の表に示します。

表13-15　WorkManagerを使用する場合のアプリケーションを構成するコンポーネントの使用可否

コンポーネント | 使用可否
EJBクライアント | ×
リソースアダプタ | ×
JavaBeansリソース | ×
サーブレット／JSP※ | ○
EJB | Stateless Session Bean | EJB2.1以前 | CMT | ○
BMT | ○
EJB3.0 | ×
Stateful Session Bean | ×
Entity Bean | ×
Message-driven Bean | ×

（凡例）

○：使用できる

×：使用できない

注※　サーブレットリスナやフィルタでも使用できます。

WorkManagerを使用するアプリケーションの開発の流れは次のとおりです。

スケジュール元となるEJBまたはサーブレットの属性を定義する

Workおよびリスナに実行する処理を実装する

スケジュール元となるEJBまたはサーブレットを作成する

WorkManagerを使用するJ2EEアプリケーションをコンパイルする

それぞれの作業の詳細を次に示します。

＜この項の構成＞

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

(2)　Workおよびリスナに実行する処理を実装する

(3)　スケジュール元となるEJBまたはサーブレットを作成する

(4)　WorkManagerを使用するJ2EEアプリケーションをコンパイルする

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

WorkManagerを使用するEJBまたはサーブレットの属性をDDに定義します。属性は，EJBまたはサーブレットの属性定義ファイルで定義します。アノテーションで定義することはできません。

WorkManagerを使用するために定義する必要がある属性を次の表に示します。

表13-16　WorkManagerを使用するために定義する必要がある属性

タグ名
説明

＜ルートタグ＞
－

┣
┃
┃
<description>
任意で設定してください。

┣
┃
┃
┃
<res-ref-name>
JNDI ENC名（JNDIルックアップに使用する名前）を指定してください。

┣
┃
┃
<res-type>
次の内容を設定してください。
「commonj.work.WorkManager」

┣
┃
┃
<res-auth>
設定した値は無視されます。

┣
┃
┃
┃
┃┃
┃
┃
<res-sharing-scope>
「Shareable」を設定してください。ただし，「Unshareable」を設定しても，「Shareable」設定時と同様に動作します（WorkManagerはアプリケーション開始時に作成されて，ルックアップ時には同じWorkManagerが返ります）。

┣
┃
┃
<mapped-name>
設定した値は無視されます。

┣
┃
┃
<injection-target>
設定した値は無視されます。

┗
<linked-to>
設定した値は無視されます。

サーブレットでWorkManagerを使用する場合のweb.xmlの定義例を次に示します。

<web-app>
 <display-name>WorkManagerSample</display-name>
 <servlet>
   <servlet-name>SampleServlet</servlet-name>
   <display-name>SampleServlet</display-name>
   <servlet-class>SampleServlet</servlet-class>
 </servlet>
 <resource-ref>
   <res-ref-name>wm/MyWorkManager</res-ref-name>
   <res-type>commonj.work.WorkManager</res-type>
   <res-auth>Container</res-auth>
   <res-sharing-scope>Shareable</res-sharing-scope>
 </resource-ref>
</web-app>

WorkManagerは，アプリケーションの開始時に，属性の定義に従って自動で作成されます。属性で定義した数のWorkManagerが作成されます。

(2)　Workおよびリスナに実行する処理を実装する

WorkManagerを使用するには，実行する処理を実装したWorkおよびリスナを作成する必要があります。インタフェースには，処理の実体であるrunメソッドを持ったWorkインタフェースと，処理の受付，開始，終了などのタイミングで処理を実行するためのWorkListenerインタフェースがあります。このうち，Workは必ず実装してください。APIの詳細については，Timer and Work Manager for Application ServersのAPIの仕様を参照してください。

WorkListenerインタフェースのAPIが呼び出される流れとステータスの遷移を次に示します。

図13-10　WorkListenerインタフェースのAPIが呼び出される流れとステータスの遷移

WorkListenerのメソッドおよびWork.runメソッドは，同一スレッド内で呼び出されます。そのため，それぞれのメソッドは，共通のJava EEコンテキストを使用できます。

デーモンWorkと非デーモンWorkに実装する処理の流れと実装例，およびWorkListenerの実装例を次に示します。

デーモンWorkに実装する処理の流れと実装例

デーモンWorkを使用するには，isDaemonメソッドがtrueを返すようにWorkを実装します。

WorkManagerが終了すると，コンテナはデーモンWorkを停止するために，releaseメソッドを実行します。そのため，releaseメソッドが実行されたらrunメソッドの処理が終了するように実装してください。releaseメソッドが適切に実装されていない場合，WorkManager停止時にデーモンWorkが停止しないで，無限待ちになることがあるので注意してください。

デーモンWorkの実装例を次に示します。

public class MyWork implements Work {
 private String name;
 private boolean isLoopContinue = true;
 public MyWork() {}

 public void release() {
   isLoopContinue = false;
 }

 public boolean isDaemon() {
   return true;
 }

 public void run() {
   while (isLoopContinue) {
     System.out.println("DaemonWork is executed");
  try {
    Thread.sleep(10000);
  } catch(InterruptedException e) {}
}
 }
 public String toString() {
   return name;
 }
}

非デーモンWorkに実装する処理の流れと実装例

非デーモンWorkを使用するには，isDaemonメソッドがfalseを返すようにWorkを実装します。

非デーモンWorkの処理は，スケジューリングしたEJBやサーブレットの処理中に終了する必要があります。そのため，スケジュールしたWorkが終了するのを待って，EJBまたはサーブレットの処理を終了するように実装してください。スケジュールしたWorkの終了を待つには，waitForAllメソッドまたはwaitForAnyメソッドを使用します。スケジュールしたWorkが終了しないうちにEJBやサーブレットの処理を終了した場合，スケジュールしたEJBやサーブレットのライフサイクルを超えてWorkの処理が実行されてしまいます。非デーモンWorkがスケジュールしたリクエストのライフサイクルを超えて実行されないように，必ずwaitForAllメソッドなどを使用してユーザプログラム中で処理を終了してください。

非デーモンWorkの実装例を次に示します。

public class MyWork implements Work {
        private String name;
        private String data;
        public MyWork(String name) {
                 this.name = name;
}

        public void release() {}

        public boolean isDaemon() {
                 return false;
        }

        public void run() {
                 data = "Hello, World. name=" + name;
        }

        public String getData() {
                 return data;
        }

        public String toString() {
                 return name;
        }
}

WorkListenerの実装例

WorkListenerの実装例を次に示します。

public class ExampleListener implements WorkListener {
   public void workAccepted(WorkEvent we) {
       System.out.println("Work Accepted");
   }

   public void workRejected(WorkEvent we) {
       System.out.println("Work Rejected");
   }

   public void workStarted(WorkEvent we) {
       System.out.println("Work Started");
   }

   public void workCompleted(WorkEvent we) {
       System.out.println("Work Completed");
   }
}

(3)　スケジュール元となるEJBまたはサーブレットを作成する

WorkManagerを使用するには，スケジュール元となるEJBまたはサーブレットに，属性に定義したWorkManagerのJNDI名のルックアップ，およびWorkManagerの処理のスケジューリングを実装します。

属性に定義したWorkManagerのJNDI名

属性に定義したWorkManagerのJNDI名をルックアップしてWorkManagerを取得します。ルックアップにはjava:comp/envを使用します。WorkManagerを取得する例を次に示します。

  InitialContext ic = new InitialContext();
  WorkManager tm = (WorkManager)ic.lookup
                       ("java:comp/env/wm/MyWorkManager");

WorkManagerの処理のスケジューリング

WorkManagerの処理のスケジューリングは，WorkManagerのscheduleメソッドを呼び出して実行します。

複数の非デーモンWorkをスケジューリングしたあと，すべてのWorkの終了を待つプログラムの例を次に示します。

MyWork work1 = new MyWork();
MyWork work2 = new MyWork();
InitialContext ctx = new InitialContext();
WorkManager mgr = (WorkManager) ctx.lookup("java:comp/env/wm/MyWorkManager");
WorkItem wi1 = mgr.schedule(work1, new ExampleListener());
WorkItem wi2 = mgr.schedule(work2);
Collection coll = new ArrayList();
coll.add(wi1);
coll.add(wi2);
mgr.waitForAll(coll, WorkManager.INDEFINITE);

System.out.println("work1 data: " + work1.getData());
System.out.println("work2 data: " + work2.getData());

(4)　WorkManagerを使用するJ2EEアプリケーションをコンパイルする

WorkManagerを使用するJ2EEアプリケーションをコンパイルする場合は，次のJARファイルを含めてください。

＜Cosminexusのインストールディレクトリ＞¥CC¥lib¥ejbserver.jar

13.4.5　実行環境の設定

非デーモンWorkで使用するスレッドプールの最大スレッド数をデフォルト値の「10」から変更したい場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。スレッドプールの最大スレッド数の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの設定を次の表に示します。

表13-17　簡易構築定義ファイルでのスレッドプールの最大スレッド数を変更するための定義

指定するパラメタ
設定内容

ejbserver.commonj.WorkManager.non_daemon_work_threads
非デーモンWorkで使用するスレッドプールの最大スレッド数を設定します。1～65535の範囲※で設定してください。
デフォルト値は10です。

注※　範囲以外の数値が指定された場合は，メッセージKDJE34510-Wが表示され，デフォルト値が適用されます。

付録

＜この付録の構成＞

付録A　各バージョンでの主な機能変更

付録B　このマニュアルの参考情報

付録C　用語解説

付録A　各バージョンでの主な機能変更

ここでは，08-70よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。08-70での主な機能変更については，「1.4　アプリケーションサーバ 08-70での主な機能変更」を参照してください。

説明内容は次のとおりです。

アプリケーションサーバの各バージョンで変更になった主な機能と，その概要を説明しています。機能の詳細については，「参照先マニュアル」の「参照個所」の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「Cosminexus アプリケーションサーバ」または「Cosminexus アプリケーションサーバ V8」は省略しています。

＜この節の構成＞

付録A.1　08-53での主な機能変更

付録A.2　08-50での主な機能変更

付録A.3　08-00での主な機能変更

付録A.1　08-53での主な機能変更

＜この項の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表A-1　導入・構築の容易性強化を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築
さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。
また，複数のハイパーバイザが混在する環境にも対応しました。
仮想化システム構築・運用ガイド
2章，3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表A-2　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
トランザクション連携に対応したOpenTP1からの呼び出し | OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
JavaMail | POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 8章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表A-3　信頼性の維持・向上を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

JavaVMのトラブルシュート機能強化
JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行／互換編
4章，5章，8章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表A-4　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
JP1/ITRMへの対応 | ITリソースを一元管理する製品であるJP1/ITRMに対応しました。 | 仮想化システム構築・運用ガイド | 1.3，2.1

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表A-5　そのほかの目的による変更

項目
変更の概要
参照先マニュアル
参照個所

Microsoft IIS 7.0およびMicrosoft IIS 7.5への対応
WebサーバとしてMicrosoft IIS 7.0およびMicrosoft IIS 7.5に対応しました。
－
－

HiRDB Version 9およびSQL Server 2008への対応
データベースとして次の製品に対応しました。

HiRDB Server Version 9

HiRDB/Developer's Kit Version 9

HiRDB/Run Time Version 9

SQL Server 2008

また，SQL Server 2008に対応するJDBCドライバとして，SQL Server JDBC Driverに対応しました。
機能解説 基本・開発編(コンテナ共通機能)
3章

（凡例）－：該当なし。

付録A.2　08-50での主な機能変更

＜この項の構成＞

(1)　導入・構築の容易性強化

(2)　標準機能・既存機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表A-6　導入・構築の容易性強化を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更 | Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグおよびservlet-mappingタグの指定を必須から任意に変更しました。 | リファレンス 定義編(サーバ定義) | 2.4
論理サーバのネットワークリソース使用 | J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。 | 機能解説 運用／監視／連携編 | 1.2.3，5.2，5.8
サンプルプログラムの実行手順の簡略化 | 一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。 | ファーストステップガイド | 3.4.1
システム構築・運用ガイド | 付録F
運用管理ポータルの画面の動作の改善 | 画面の更新間隔のデフォルトを「更新しない」から「3秒」に変更しました。 | 運用管理ポータル操作ガイド | 7.4.1
セットアップウィザードの完了画面の改善 | セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。 | システム構築・運用ガイド | 2.2.12，3.3
仮想化環境の構築 | ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。※ | 仮想化システム構築・運用ガイド | 3章，5章

注※

08-50モードで構築する場合は，マニュアル「Cosminexus アプリケーションサーバ 仮想化システム構築・運用ガイド」の「付録D　08-50モードの仮想サーバマネージャを利用する場合の設定」を参照してください。

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表A-7　標準機能・既存機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
OpenTP1からの呼び出しへの対応 | OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 4章
JMSへの対応 | JMS1.1仕様に対応したCosminexus JMSプロバイダ機能を使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 7章
Java SE 6への対応 | Java SE 6の機能が使用できるようになりました。 | 機能解説 保守／移行／互換編 | 5.5，5.8.1
ジェネリクスの使用への対応 | EJBでジェネリクスを使用できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 4.2.17

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表A-8　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
明示管理ヒープ機能の使用性向上 | 自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。 | システム設計ガイド | 7.1.1，7.6.3，7.10.5，7.11.1
このマニュアル | 8章
データベースセッションフェイルオーバ機能のURI単位での抑止 | データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。 | このマニュアル | 6.6
仮想化環境での障害監視 | 仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。 | 仮想化システム構築・運用ガイド | 付録D

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表A-9　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
管理ユーザアカウントの省略 | 運用管理ポータル，Management Serverのコマンド，またはSmart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。 | システム構築・運用ガイド | 7.6.1，7.6.2，7.6.5
運用管理ポータル操作ガイド | 2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録G.2
リファレンス コマンド編 | 1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）
仮想化環境の運用 | 仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。 | 仮想化システム構築・運用ガイド | 4章，6章

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表A-10　そのほかの目的による変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
Tenured領域内不要オブジェクト統計機能 | Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。 | 機能解説 保守／移行／互換編 | 8.8
Tenured増加要因の基点オブジェクトリスト出力機能 | Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。 | 8.9
クラス別統計情報解析機能 | クラス別統計情報をCSV形式で出力できるようになりました。 | 8.10
論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え | Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。 | 機能解説 運用／監視／連携編 | 20.4.3，20.5.3，22.2.2，22.3.3，22.3.4
ホスト単位管理モデルを対象とした系切り替えシステム | クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。 | 22章
ACOS（AX2000，BS320）のサポート | 使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。 | システム構築・運用ガイド | 4.3.1，8.2，8.3，8.11.6，付録A，付録A.2
リファレンス 定義編(サーバ定義) | 4.5，4.6.2，4.6.4，4.6.5，4.6.6，4.10.1
CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加 | CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。 | 機能解説 基本・開発編(EJBコンテナ) | 2.7.3
OutOfMemoryError発生時の運用管理エージェントの強制終了 | JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。 | 機能解説 保守／移行／互換編 | 2.5.7
スレッドの非同期並行処理 | TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。 | このマニュアル | 13章

付録A.3　08-00での主な機能変更

＜この項の構成＞

(1)　開発生産性の向上

(2)　標準機能への対応

(3)　信頼性の維持・向上

(4)　運用性の維持・向上

(5)　そのほかの目的

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表A-11　開発生産性の向上を目的とした変更

項目
変更の概要
参照先マニュアル
参照個所

ほかのアプリケーションサーバ製品からの移行容易化
ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

機能解説 基本・開発編(Webコンテナ)
2.3，2.7.5

cosminexus.xmlの提供
Cosminexus アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。
機能解説 基本・開発編(コンテナ共通機能)
10.3

(2)　標準機能への対応

標準機能への対応を目的として変更した項目を次の表に示します。

表A-12　標準機能への対応を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
Servlet 2.5への対応 | Servlet 2.5に対応しました。 | 機能解説 基本・開発編(Webコンテナ) | 2.2，2.5.4，2.6，5章
JSP 2.1への対応 | JSP 2.1に対応しました。 | 機能解説 基本・開発編(Webコンテナ) | 2.3.1，2.3.3，2.5，2.6，5章
JSPデバッグ | MyEclipseを使用した開発環境でJSPデバッグができるようになりました。 | 機能解説 基本・開発編(Webコンテナ) | 2.4
タグライブラリのライブラリJARへの格納とTLDのマッピング | タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。 | 機能解説 基本・開発編(Webコンテナ) | 2.3.4
application.xmlの省略 | J2EEアプリケーションでapplication.xmlが省略できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 10.4
アノテーションとDDの併用 | アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 11.5
アノテーションのJava EE 5標準準拠（デフォルトインターセプタ） | デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 10.4
@Resourceの参照解決 | @Resourceでリソースの参照解決ができるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 11.4
JPAへの対応 | JPA仕様に対応しました。 | 機能解説 基本・開発編(コンテナ共通機能) | 5章，6章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表A-13　信頼性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
セッション情報の永続化 | HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。 | このマニュアル | 5章，6章
フルガーベージコレクションの抑止 | フルガーベージコレクションの要因となるオブジェクトをJavaヒープ外に配置することで，フルガーベージコレクション発生を抑止できるようになりました。 | このマニュアル | 8章
クライアント性能モニタ | クライアント処理に掛かった時間を調査・分析できるようになりました。 | このマニュアル | 9章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表A-14　運用性の維持・向上を目的とした変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
運用管理ポータルでのアプリケーション操作性向上 | アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。 | 運用管理ポータル操作ガイド | 1.1.4

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表A-15　そのほかの目的による変更

項目 | 変更の概要 | 参照先マニュアル | 参照個所
無効なHTTP Cookieの削除 | 無効なHTTP Cookieを削除できるようになりました。 | 機能解説 基本・開発編(Webコンテナ) | 2.7.4
ネーミングサービスの障害検知 | ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 2.7
コネクション障害検知タイムアウト | コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3.15.1
Oracle11gへの対応 | データベースとしてOracle11gが使用できるようになりました。 | 機能解説 基本・開発編(コンテナ共通機能) | 3章
バッチ処理のスケジューリング | バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。 | このマニュアル | 4章
バッチ処理のログ | バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時におけるリトライ回数とリトライ間隔を指定できるようになりました。 | リファレンス 定義編(サーバ定義) | 3.6
snapshotログ | snapshotログの収集内容が変更されました。 | 機能解説 保守／移行／互換編 | 付録A.1，付録A.2
メソッドキャンセルの保護区公開 | メソッドキャンセルの対象外となる保護区リストの内容を公開しました。 | 機能解説 運用／監視／連携編 | 付録C
統計前のガーベージコレクション選択機能 | クラス別統計情報を出力する前に，ガーベージコレクションを実行するかどうかを選択できるようになりました。 | 機能解説 保守／移行／互換編 | 8.7
Survivor領域の年齢分布情報出力機能 | Survivor領域のJavaオブジェクトの年齢分布情報を日立JavaVMログファイルに出力できるようになりました。 | 機能解説 保守／移行／互換編 | 8.11
ファイナライズ滞留解消機能 | JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。 | 機能解説 保守／移行／互換編 | 8.12
サーバ管理コマンドの最大ヒープサイズの変更 | サーバ管理コマンドが使用する最大ヒープサイズが変更されました。 | リファレンス 定義編(サーバ定義) | 5.2，5.3
推奨しない表示名を指定された場合の対応 | J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。 | メッセージ 2 | KDJE42374-W

付録B　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

＜この節の構成＞

付録B.1　関連マニュアル

付録B.2　マニュアル体系の変更について

付録B.3　このマニュアルでの表記

付録B.4　英略語

付録B.5　KB（キロバイト）などの単位表記について

付録B.1　関連マニュアル

アプリケーションサーバのマニュアルについて次に示します。

Cosminexus アプリケーションサーバ V8 概説（3020-3-U01）
アプリケーションサーバの概要について説明しています。

Cosminexus アプリケーションサーバ V8 ファーストステップガイド（3020-3-U02）
Application ServerまたはDeveloperを使用して，サンプルプログラムを動かすためのシステムを構築する手順について説明しています。

Cosminexus アプリケーションサーバ V8 システム設計ガイド（3020-3-U03）
システム設計時に，システムの目的に応じたシステム構成や運用方法を検討するための指針について説明しています。また，チューニングの方法についても説明しています。

Cosminexus アプリケーションサーバ V8 システム構築・運用ガイド（3020-3-U04）
セットアップウィザードおよびSmart Composer機能を使用したシステムの構築・運用の手順について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(Webコンテナ)（3020-3-U05）
アプリケーションサーバで提供するWebコンテナの機能，およびWebコンテナに関連する機能（Webサーバ，サーブレット／JSPなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ)（3020-3-U06）
アプリケーションサーバで提供するEJBコンテナの機能，およびEJBコンテナに関連する機能（EJB，EJBクライアントなど）について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能)（3020-3-U07）
WebコンテナおよびEJBコンテナで共通して利用する機能について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編（3020-3-U09）
アプリケーションサーバで提供する運用・監視機能，およびほかのプログラムとの連携について説明しています。

Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編（3020-3-U10）
アプリケーションサーバで構築したシステムの保守に関する機能，移行情報，および互換用機能について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド（3020-3-U12）
アプリケーションサーバで動作するアプリケーションの操作方法について説明しています。

Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド（3020-3-U13）
運用管理ポータルの使用方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス コマンド編（3020-3-U14）
アプリケーションサーバを構築・運用するときに使用するコマンドについて説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義)（3020-3-U15）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに使用するファイルのうち，J2EEサーバやManagement Serverなどのサーバの定義に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義)（3020-3-U16）
アプリケーションサーバを構築・運用するとき，またはアプリケーションを開発するときに使用するファイルのうち，アプリケーションやリソースの属性設定に使用するファイルの形式について説明しています。

Cosminexus アプリケーションサーバ V8 仮想化システム構築・運用ガイド（3020-3-U18）
アプリケーションサーバを仮想化したサーバ上に構築する場合の設計，構築，運用の手順について説明しています。

Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド（3020-3-U25）
アプリケーションサーバで動作させるアプリケーションの開発方法について説明しています。

Cosminexus アプリケーションサーバ V8 リファレンス API編（3020-3-U26）
アプリケーションを開発するときに使用するAPIの形式について説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 1 KDAL-KDCGおよびHitachi Web Server編（3020-3-U41）
アプリケーションサーバで出力されるKDALからKDCGまでのメッセージ，およびHitachi Web Serverのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 2 KDJE-KDJW編（3020-3-U42）
アプリケーションサーバで出力されるKDJEからKDJWまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 3 KECX-KEDT／KEOS02000-29999／KEUC-KFRM編（3020-3-U43）
アプリケーションサーバで出力されるKECXからKEDTまでのメッセージ，KEOS02000からKEOS29999までのメッセージ，およびKEUCからKFRMまでのメッセージについて説明しています。

Cosminexus アプリケーションサーバ V8 メッセージ 4 監査ログ編（3020-3-U44）
アプリケーションサーバで出力される監査ログメッセージについて説明しています。

また，このマニュアルと関連するこのほかのマニュアルを次に示します。必要に応じてお読みください。

Hitachi Web Server（3020-3-U17）

VisiBroker Version 5 Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド（3020-3-U28）

uCosminexus Batch Job Execution Server 使用の手引（3000-3-E02）

スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（UNIX(R)用）（3000-6-352）

スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（UNIX(R)用）（3000-6-354）

スケーラブルデータベースサーバ HiRDB Version 8 コマンドリファレンス（UNIX(R)用）（3000-6-355）

スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（Windows(R)用）（3020-6-352）

スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（Windows(R)用）（3020-6-354）

スケーラブルデータベースサーバ HiRDB Version 8 コマンドリファレンス（Windows(R)用）（3020-6-355）

スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド（3020-6-356）

HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）（3000-6-452）

HiRDB Version 9 システム運用ガイド（UNIX(R)用）（3000-6-454）

HiRDB Version 9 コマンドリファレンス（UNIX(R)用）（3000-6-455）

HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）（3020-6-452）

HiRDB Version 9 システム運用ガイド（Windows(R)用）（3020-6-454）

HiRDB Version 9 コマンドリファレンス（Windows(R)用）（3020-6-455）

HiRDB Version 9 UAP開発ガイド（3020-6-456）

JP1 Version 8 JP1/Automatic Job Management System 2 操作ガイド（3020-3-K24）

JP1 Version 9 JP1/Automatic Job Management System 3 操作ガイド（3020-3-S09）

なお，このマニュアルでは，次のマニュアルについて，対象OSおよびバージョン番号を省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

正式名称 | このマニュアルでの表記
Cosminexus アプリケーションサーバ V8 概説 | Cosminexus アプリケーションサーバ 概説
Cosminexus アプリケーションサーバ V8 ファーストステップガイド | Cosminexus アプリケーションサーバ ファーストステップガイド
Cosminexus アプリケーションサーバ V8 システム設計ガイド | Cosminexus アプリケーションサーバ システム設計ガイド
Cosminexus アプリケーションサーバ V8 システム構築・運用ガイド | Cosminexus アプリケーションサーバ システム構築・運用ガイド
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(Webコンテナ) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(EJBコンテナ) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)
Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能) | Cosminexus アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)
Cosminexus アプリケーションサーバ V8 機能解説 運用／監視／連携編 | Cosminexus アプリケーションサーバ 機能解説 運用／監視／連携編
Cosminexus アプリケーションサーバ V8 機能解説 保守／移行／互換編 | Cosminexus アプリケーションサーバ 機能解説 保守／移行／互換編
Cosminexus アプリケーションサーバ V8 アプリケーション設定操作ガイド | Cosminexus アプリケーションサーバ アプリケーション設定操作ガイド
Cosminexus アプリケーションサーバ V8 運用管理ポータル操作ガイド | Cosminexus アプリケーションサーバ 運用管理ポータル操作ガイド
Cosminexus アプリケーションサーバ V8 リファレンス コマンド編 | Cosminexus アプリケーションサーバ リファレンス コマンド編
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(サーバ定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(サーバ定義)
Cosminexus アプリケーションサーバ V8 リファレンス 定義編(アプリケーション／リソース定義) | Cosminexus アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)
Cosminexus アプリケーションサーバ V8 仮想化システム構築・運用ガイド | Cosminexus アプリケーションサーバ 仮想化システム構築・運用ガイド
Cosminexus アプリケーションサーバ V8 アプリケーション開発ガイド | Cosminexus アプリケーションサーバ アプリケーション開発ガイド
Cosminexus アプリケーションサーバ V8 リファレンス API編 | Cosminexus アプリケーションサーバ リファレンス API編
Cosminexus アプリケーションサーバ V8 メッセージ 1 KDAL-KDCGおよびHitachi Web Server編 | Cosminexus アプリケーションサーバ メッセージ 1
Cosminexus アプリケーションサーバ V8 メッセージ 2 KDJE-KDJW編 | Cosminexus アプリケーションサーバ メッセージ 2
Cosminexus アプリケーションサーバ V8 メッセージ 3 KECX-KEDT／KEOS02000-29999／KEUC-KFRM編 | Cosminexus アプリケーションサーバ メッセージ 3
Cosminexus アプリケーションサーバ V8 メッセージ 4 監査ログ編 | Cosminexus アプリケーションサーバ メッセージ 4
VisiBroker Version 5 Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド | Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド
JP1 Version 8 JP1/Automatic Job Management System 2 操作ガイド | JP1/Automatic Job Management System 操作ガイド
JP1 Version 9 JP1/Automatic Job Management System 3 操作ガイド
スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド | HiRDB UAP開発ガイド
HiRDB Version 9 UAP開発ガイド
スケーラブルデータベースサーバ HiRDB Version 8 コマンドリファレンス（UNIX(R)用） | HiRDB コマンドリファレンス
スケーラブルデータベースサーバ HiRDB Version 8 コマンドリファレンス（Windows(R)用）
HiRDB Version 9 コマンドリファレンス（UNIX(R)用）
HiRDB Version 9 コマンドリファレンス（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（UNIX(R)用） | HiRDB システム運用ガイド
スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（Windows(R)用）
HiRDB Version 9 システム運用ガイド（UNIX(R用）
HiRDB Version 9 システム運用ガイド（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（UNIX(R)用） | HiRDB システム導入・設計ガイド
スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（Windows(R)用）
HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）
HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）

付録B.2　マニュアル体系の変更について

08-00では，07-60のマニュアル「Cosminexus　機能解説」，マニュアル「Cosminexus　システム構築ガイド」およびマニュアル「Cosminexus　システム運用ガイド」の内容を6分冊して，マニュアル体系を変更しました。変更後のマニュアル体系については，「1.1　機能の分類」を参照してください。

付録B.3　このマニュアルでの表記

このマニュアルで使用している表記と，対応する製品名を次に示します。

表記 | 製品名
ACOS | AX2000 | AX2000
AX2500 | AX2500
BS320 | BS320ロードバランサブレード
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.6.1
HiRDBまたはHiRDBサーバ | HiRDB Server | HiRDB Server Version 9
HiRDB/Parallel Server | HiRDB/Parallel Server Version 8
HiRDB/Single Server | HiRDB/Single Server Version 8
HiRDB Run TimeまたはHiRDBクライアント | HiRDB/Run Time Version 8
HiRDB/Run Time Version 9
IPF | Itanium(R) Processor Family
JP1/AJS | JP1/AJS - Agent | JP1/Automatic Job Management System 2 - Agent※
JP1/Automatic Job Management System 3 - Agent
JP1/AJS - Manager | JP1/Automatic Job Management System 2 - Manager※
JP1/Automatic Job Management System 3 - Manager
JP1/AJS - View | JP1/Automatic Job Management System 2 - View※
JP1/Automatic Job Management System 3 - 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/IM | JP1/IM - CM | JP1/Integrated Management - Central Information Master
JP1/IM - Manager | JP1/Integrated Management - Manager
JP1/IM - View | JP1/Integrated Management - View
JP1/NETM/Audit | JP1/NETM/Audit - Manager
JP1/SC/DPM | JP1/ServerConductor/Deployment Manager Standard Edition
Oracle | Oracle10g | Oracle 10g
Oracle 10g R2
Oracle Database 10g
Oracle11g | Oracle Database 11g
Oracle Database 11g R2
Oracle9i | Oracle9i
Oracle9i R2
UNIX | AIX | AIX 5L V5.3
AIX V6.1
AIX V7.1
HP-UXまたはHP-UX（IPF） | HP-UX 11i V2（IPF）
HP-UX 11i V3（IPF）
Linux | Linux（IPF） | Red Hat Enterprise Linux(R) AS 4（IPF）
Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）
Red Hat Enterprise Linux(R) 5（Intel Itanium）
Linux（x86/AMD64 & Intel EM64T） | Red Hat Enterprise Linux(R) AS 4（x86）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）
Red Hat Enterprise Linux(R) 5（x86）
Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux(R) 5（AMD/Intel 64）
Red Hat Enterprise Linux(R) Server 6（32-bit x86）
Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）
Solaris | Solaris 10（SPARC）
Solaris 10（x64）
Solaris 9（SPARC）
Web Redirector | uCosminexus Web Redirector
XDM/RD E2 | VOS3 XDM/RD E2

注※　総称して，JP1/AJS2と表記することがあります。

なお，Application ServerおよびDeveloperを総称して，アプリケーションサーバと表記します。

また，Linuxに関しては，バージョンごとに次のように表記することがあります。

表記 | OS名
Red Hat Enterprise Linux 4 | Red Hat Enterprise Linux(R) AS 4（IPF）
Red Hat Enterprise Linux(R) AS 4（x86）
Red Hat Enterprise Linux(R) ES 4（x86）
Red Hat Enterprise Linux(R) AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux(R) ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5 | Red Hat Enterprise Linux(R) 5 Advanced Platform（Intel Itanium）
Red Hat Enterprise Linux(R) 5（Intel Itanium）
Red Hat Enterprise Linux(R) 5 Advanced Platform（x86）
Red Hat Enterprise Linux(R) 5（x86）
Red Hat Enterprise Linux(R) 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux(R) 5（AMD/Intel 64）
Red Hat Enterprise Linux Server 6 | Red Hat Enterprise Linux(R) Server 6（32-bit x86）
Red Hat Enterprise Linux(R) Server 6（64-bit x86_64）

このマニュアルで使用している表記と，対応するアプリケーションサーバの機能名を次に示します。

表記 | アプリケーションサーバの機能名
Cosminexus Developer's Kit for Java | Cosminexus Developer's Kit for JavaTM
Cosminexus RM | Cosminexus Reliable Messaging
CTM | Cosminexus Component Transaction Monitor
Management Server | Cosminexus Management Server
MyEclipse | MyEclipse for Cosminexus
PRF | Cosminexus Performance Tracer
Smart Composer | Cosminexus Smart Composer

このマニュアルで使用している表記と，対応するJava関連用語を次に示します。

表記 | Java関連用語
BMP | Bean-Managed Persistence
BMT | Bean-Managed Transaction
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 | J2EETM
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
Java EEまたはJava Platform, Enterprise Edition | JavaTM Platform, Enterprise Edition
JavaMail | JavaMailTM
Java SE | JavaTM Platform, Standard Edition
JavaVM | JavaTM Virtual Machine
JAXP | JavaTM API for XML Processing
JCA | J2EETM Connector Architecture
JCE | JavaTM Cryptography Extension
JDBC | JDBCTM
JavaTM Database Connectivity
JDK | JDKTM
JavaTM Development Kit
JMS | JavaTM Message Service
JNDI | Java Naming and Directory InterfaceTM
JNI | JavaTM Native Interface
JPA | Java Persistence API
JSP | JSPTM
JavaServer PagesTM
JTA | JavaTM Transaction API
JTS | JavaTM Transaction Service
Servletまたはサーブレット | JavaTM Servlet
WAR | Web ARchive

付録B.4　英略語

このマニュアルで使用している英略語を次に示します。

英略語 | 英字での表記
ACOS | Advanced Core Operating System
API | Application Programming Interface
ASCII | American Standard Code for Information Interchange
CMP | Container-Managed Persistence
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
DMZ | Demilitarized Zone
DN | Distinguished Name
DTD | Document Type Definition
EIS | Enterprise Information System
EL | Expression Language
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
MHP | Message Handling Program
MIB | Management Information Base
OS | Operating System
OTM | Object Transaction Monitor
OTS | Object Transaction Service
RAC | Real Application Clusters
RDB | Relational Database
RMI | Remote Method Invocation
SFO | Session Fail Over
SNMP | Simple Network Management Protocol
SPP | Service Providing Program
ssh | Secure Shell
SSL | Secure Sockets Layer
TLD | Tag Library Descriptor
URL | Uniform Resource Locator
VM | Virtual Machine
XML | Extensible Markup Language

付録B.5　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

付録C　用語解説

アプリケーションサーバで使用する用語について説明します。

（数字）

1.4モード

サーバの動作モードです。J2EE 1.4以降の機能を使用できます。データベースを含む複数のリソースのトランザクション管理ができます。

（英字）

Application Server

アプリケーションサーバの実行環境を構築する基盤製品です。Application Server Standardと，Application Server Enterpriseの総称です。

BJEX

uCosminexus Batch Job Execution Serverのことです。

CORBAネーミングサービス

CORBAの仕様に準拠した，リモートオブジェクトの格納場所を管理するためのネーミングサービスです。アプリケーションサーバの構成ソフトウェアであるCosminexus TPBrokerによって提供される機能です。

cosminexus.xml

Cosminexus アプリケーションサーバ独自の情報を定義するための属性ファイルです。

Cosminexus Component Transaction Monitor

クライアントからのリクエストのスケジューリングを実現するための構成ソフトウェアです。

Cosminexus Performance Tracer

リクエストが処理されるときに，決められたポイントごとに各機能が出力する性能解析情報をファイルに出力するための構成ソフトウェアです。

Cosminexus アプリケーションサーバ

アプリケーションサーバを中核とした，性能および信頼性の高いアプリケーションを実行および開発するためのシステム構築基盤製品です。

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アプリケーションを直接呼び出しできるゲートウェイ機能も提供します。

DD

アプリケーションを運用環境に配置するときの定義情報を記述したものです。

EJBクライアント

J2EEサーバ上で開始されているEnterprise Beanを呼び出すクライアントプログラムです。次の3種類があります。

EJBクライアントアプリケーション

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーション

Enterprise Beanを呼び出すJavaアプリケーションです。

EJBコンテナ

Enterprise Beanを制御する実行環境です。また，通信，トランザクション管理などのシステムレベルのサービスも提供します。Enterprise Beanの実体は，EJBコンテナの中で実行されます。

Explicitヒープ

明示管理ヒープ機能で使用するメモリ空間です。Javaヒープ外にあるため，フルガーベージコレクションの対象になりません。

HTTPセッション

javax.servlet.http.HttpServletRequestクラスのgetSessionメソッドで取得されるHttpSessionオブジェクトです。「HTTPセッションに格納するオブジェクト」に加え，その他にHTTPセッションがメンバとして参照するオブジェクトを含む，HTTPセッション全体を指します。

HTTPセッション管理用オブジェクト

Webコンテナの内部で使用され，HTTPセッションを管理するオブジェクトです。

HTTPセッションに格納するオブジェクト

javax.servlet.http.HttpSessionクラスのsetAttributeメソッドでHTTPセッションへ格納されるユーザオブジェクトです。

HTTPセッションの属性ともいいます。

HTTPセッションに関するオブジェクト

「HTTPセッション管理用オブジェクト」と「HTTPセッション」をまとめて表現した用語です。

J2EEサーバ

J2EEコンテナを生成，実行する環境です。

jaas.conf（JAASのコンフィグレーションファイル）

ユーザ認証ライブラリおよびシングルサインオンライブラリの機能を使用するために必要なJAAS認証用の設定ファイルです。

JavaロギングAPI

J2SEで提供されているコアロギング機能のクラスおよびインタフェースです。アプリケーションサーバでは，JavaロギングAPIを使用してユーザログを日立トレース共通ライブラリ形式で出力する機能を提供しています。

JNDI（Java Naming and Directory Interface）

Javaプラットフォーム用の標準拡張機能で，Java テクノロジに対応したアプリケーションに，企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供します。

アプリケーションサーバでは，Cosminexus TPBrokerのCORBAネーミングサービスを利用して，JNDIの機能を実現しています。

JNDI名前空間

JNDIによってアクセスする名前情報が管理されている名前空間です。Application Serverでは，J2EEアプリケーションをデプロイした時に，EJBオブジェクトリファレンスがJNDI名前空間の名前にバインドされます。

アプリケーションサーバで使用するJNDI名前空間の名前には，別名を付けることができます。これによって，Enterprise BeanやJ2EEリソースを別名でルックアップできるようになります。

JP1

日立の統合システム運用管理ソフトウェアです。

JP1/AJS

日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するためのプログラム群です。JP1/AJS - Manager，JP1/AJS - Agent，JP1/AJS - Viewの製品で構成されます。

JP1/AJS2 - SO

一つ一つの運用手順を蓄積し，ライブラリとして統合する運用管理の基盤機能を提供するプログラムです。立案したシナリオに合う運用手順をライブラリから選択し，運用環境に合わせてカスタマイズすることで，業務運用の設計を容易に，かつ高品質で実現することができます。

JP1ジョブ運用管理サーバ

JP1/AJS2と連携してシステムの自動運転をする場合に，JP1/AJS2 - Managerを配置するホストのことです。

JSPタグライブラリ

JSPタグを作成するためのもので，JSP仕様で規定されています。アプリケーションサーバでは，統合ユーザ管理をする場合に，Cosminexus標準ログインモジュールを使用してユーザ認証をするためのJSPタグライブラリを提供しています。

ORBゲートウェイ

CORBAクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。CTMレギュレータプロセスによって提供されます。

OTMゲートウェイ

TPBroker OTMのクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。OTMゲートウェイプロセスによって提供されます。

SecurityManager

セキュリティポリシーに基づいたWebコンテナの実行時保護をするJ2EEサーバの機能です。

SFOサーバ

システム内のJ2EEサーバのJ2EEアプリケーション内で生成されたグローバルセッション情報を管理するJ2EEサーバです。セッションフェイルオーバ機能を使用するときにシステム構成に含めます。

SFOサーバアプリケーション

SFOサーバ上で稼働するJ2EEアプリケーションを，SFOサーバアプリケーションといいます。SFOサーバアプリケーションはEJBで実装されています。なお，SFOサーバアプリケーションはアプリケーションサーバで提供しています。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

JAAS対応ユーザ管理，およびシングルサインオンの機能を使用するための設定ファイルです。

uCosminexus Batch Job Execution Server

オープン環境で基幹系のバッチ業務を実行・運用するためのバッチジョブ実行基盤を提供する製品です。JP1/AJS2とあわせて使用します。

Webアプリケーション

Webブラウザを備えたクライアントを対象に作成されたアプリケーションです。具体的には，サーブレットプログラム，JSPファイル，HTML/XMLドキュメントなどの集合体です。

Webコンテナ

Webアプリケーションを制御する実行環境です。また，セキュリティ，トランザクションなどの各種サービスも提供します。Webアプリケーションは，Webコンテナ上で動作します。

Java Servlet2.5仕様，およびJavaServer Pages Specification v2.1仕様に準拠したWebアプリケーションを実行できます。

Webサーバ

Webブラウザからのリクエスト受信およびWebブラウザへのデータ送信に関連する処理を実行するプログラムです。アプリケーションサーバでは，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が提供するリダイレクタモジュールを組み込んで使用します。

（ア行）

アプリケーションサーバ

情報システムの中間に位置し，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。

（カ行）

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

リソースの排他中にガーベージコレクションの実行を待ち状態にする機能です。リソースの排他中にフルガーベージコレクションが発生し，処理が長時間中断されるのを回避できます。ガーベージコレクション制御機能は，バッチサーバの場合に使用できます。

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

Cosminexus標準ログインモジュール以外を使用して，各アプリケーションのユーザ認証をしたい場合に作成する実装クラスです。

業務処理プログラム

ビジネスロジックを実装したEnterprise Beanのことです。

クラスタ

ある共通の機能を提供するサーバの集合です。

Management Serverでは，J2EEサーバクラスタまたはWebサーバクラスタを論理サーバとして扱えます。

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

CTMによってリクエストをスケジューリングする場合に，CTMドメイン内に含まれる複数のJ2EEサーバに登録されている業務処理プログラム（Stateless Session Bean）の情報を共有管理するネーミングサービスです。

グローバルセッション

セッションフェイルオーバ機能では，障害発生前のHTTPセッションと，障害発生後に引き継がれたHTTPセッションを一つのセッションとして扱います。これをグローバルセッションといいます。

グローバルセッションID

グローバルセッションを管理するIDです。システム内でグローバルセッション情報を一意に識別するために，グローバルセッションに付けられます。

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

グローバルセッションが持つ情報をグローバルセッション情報といいます。グローバルセッション情報は，メモリセッションフェイルオーバ機能を使用する場合，SFOサーバで管理されます。また，データベースセッションフェイルオーバ機能を使用する場合，データベースで管理されます。

（サ行）

サーバ管理コマンド

サーバで管理しているアプリケーションおよびリソースの設定をするためのコマンド群です。

サーブレットフィルタ

サーブレット/JSPへのリクエストや，サーブレット/JSPからのレスポンスを，フィルタリングする機能です。サーブレットフィルタによって，サーブレット/JSPの実行前のリクエスト，または実行後のレスポンスをラップして，データの変更，リソースに対するトレースの取得などができます。

アプリケーションサーバの機能を実現するためのサーブレットフィルタとしては，セッションフェイルオーバ用フィルタ，HTTPレスポンス圧縮用フィルタ，およびクライアント性能フィルタが提供されています。

ジョブ

JP1/AJS2で扱うシステム運用の各作業のことです。

シングルサインオン

一度のログイン処理で，ユーザIDが異なる複数のシステムをシームレスに利用できるようにする機能です。

シングルサインオン情報リポジトリ

統合ユーザ管理フレームワークのユーザマッピングを実行して，シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報を格納するリポジトリです。

シングルサインオンライブラリ

ユーザマッピング情報の格納されたシングルサインオン情報リポジトリの情報を基にユーザマッピングをして，シングルサインオンを実現するライブラリです。

スケジュールキュー

CTMによってリクエストをスケジューリングする場合に，リクエストをためておくキューです。J2EEアプリケーション単位で作成され，CTMデーモンによって管理されます。

スケジュールポリシー

CTMによってリクエストをスケジューリングする場合に，振り分ける基準を決めるポリシーです。負荷が軽いCTMデーモンに振り分ける方法と，リクエストを受け付けたCTMデーモンに優先的に処理させる方法のどちらかを選択できます。

スマートエージェント

1.4モードでグローバルトランザクションを使用する場合，またはCTMを使用する場合に，動的な分散ディレクトリサービスを提供するプロセスです。

Management Serverを利用する場合，スマートエージェントは論理サーバとして扱えます。CTMはスマートエージェントによって管理されます。

なお，グローバルトランザクションの場合でも，インプロセストランザクションサービスを利用するときは，スマートエージェントは不要です。

スレッドの非同期並行処理

Java EE環境で非同期タイマ処理や非同期スレッド処理などのスレッドの非同期並行処理を実現する機能です。Cosminexusのアプリケーションサーバでは，CommonJが定めたTimer and Work Manager for Application Serversの仕様に基づいたAPIを提供しています。これによって，TimerManagerを使用した非同期タイマ処理およびWorkManagerを使用した非同期スレッド処理ができます。

セキュリティアイデンティティ

J2EEサーバによるユーザ認証が成功した時にWebコンテナやEJBコンテナに伝達される認証情報です。

セッション

Webアプリケーションに対する一連の作業を示す単位です。セッションは通常，WebクライアントからWebサーバへの複数のリクエストの集合から構成されます。

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

J2EEアプリケーション実行中のHttpSessionオブジェクトに登録されたオブジェクトをセッション情報として管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡す機能です。J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

セッションフェイルオーバ機能には，メモリセッションフェイルオーバ機能とデータベースセッションフェイルオーバ機能の2種類があります。メモリセッションフェイルオーバ機能の場合，セッション情報をSFOサーバで管理します。データベースセッションフェイルオーバ機能の場合，セッション情報をデータベースで管理します。

セッションフェイルオーバサーバ

メモリセッションフェイルオーバ機能を使用する場合に，J2EEサーバを配置しないで，SFOサーバを配置して使用するホストです。

（タ行）

統合ネーミングスケジューラサーバ

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないで，グローバルCORBAネーミングサービスを配置して使用するホストです。統合ネーミングスケジューラサーバのレプリカを作成することで，可用性を向上できます。なお，統合ネーミングスケジューラサーバにもCTMデーモンは必要です。

統合ネーミングスケジューラサーバモデル

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないでグローバルCORBAネーミングサービスを配置するホストを作成するシステム構成モデルです。

統合ユーザ管理

アプリケーションサーバで構築したシステムにログインするユーザを統合管理するための仕組みです。ユーザ認証を実現する統合ユーザ管理フレームワークが使用できます。また，運用管理ポータルを使用して，リポジトリ管理およびリソース監視を実現できます。

統合ユーザ管理フレームワーク

統合ユーザ管理でのユーザ認証を実現するフレームワークです。Java標準仕様（JAAS）に従ったAPIが提供されています。

（ナ行）

ネーミングサービス

オブジェクトに名前を付けて格納場所を管理しておくことで，格納先を知らなくても名前からそのオブジェクトを利用できるようにするサービスです。アプリケーションサーバではCORBAネーミングサービスを利用します。

Management Serverでは，ネーミングサービスを論理サーバとして扱えます。

（ハ行）

バッチアプリケーション

バッチ処理を実装したJavaアプリケーションです。バッチ実行コマンドを使用して，バッチサーバ上で実行します。バッチ実行コマンドをJP1/AJS2のジョブとして定義しておくと，JP1/AJS2からバッチアプリケーションを実行できます。

バッチサーバ

バッチアプリケーションを実行するためのサーバです。バッチアプリケーションの実行機能のほかに，バッチアプリケーションからデータベースに接続したり，EJBにアクセスしたりする機能も提供しています。

ハンドラ

ロガーから受け取ったアプリケーションのログをファイルやコンソールに出力する，JavaロギングAPIのHandlerオブジェクトです。J2EEアプリケーション，バッチアプリケーション，EJBクライアントアプリケーションで使用できます。

アプリケーションサーバでは，日立トレース共通ライブラリ形式のログをファイルに出力するためのファイルハンドラである，CJMessageFileHandlerを提供しています。

日立トレース共通ライブラリ

日立が提供するトレース採取用のライブラリです。複数の製品で共通のライブラリを利用するので，各製品のトレース形式が統一できます。

負荷分散機

Webブラウザなどからのリクエストを一元的に受け付けて，同等の機能を持つ複数のサーバに転送して各サーバの負荷を分散させるための装置です。

（マ行）

明示管理ヒープ機能

Javaオブジェクトの配置先として，Explicitヒープを使用する機能です。ExplicitヒープはJavaヒープ外にある，フルガーベージコレクションの対象にならない領域です。明示管理ヒープ機能を使用することによって，フルガーベージコレクションの発生を抑止できます。

面数

ログファイルを保持する数です。ログファイルは面数分作成され，循環して使用されます。

（ヤ行）

ユーザ情報

アプリケーションサーバで構築したシステムにユーザがログインするための情報です。

ユーザ情報リポジトリ

統合ユーザ管理をする場合に，ログイン時のユーザ認証に使用する情報を格納するリポジトリです。LDAPディレクトリサーバまたはデータベース（RDB）が使用できます。

ユーザ認証ライブラリ

LDAPディレクトリサーバで構築されたユーザ情報リポジトリの情報を基にユーザ認証をして，認証したユーザの情報をアプリケーションに提供する，JAAS対応ユーザ管理用ライブラリです。

ユーザマッピング

異なるユーザ情報リポジトリに格納した同じユーザについての情報を対応づけることです。

ユーザログ

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションが出力するログのことです。

（ラ行）

リクエストのスケジューリング

クライアントからのリクエストを実行するサーバを負荷に応じて的確に振り分けたり，サーバに送信するリクエストの数を制限したりする機能です。

レルム

統合ユーザ管理をしているシステムで，同一の認証ポリシーを適用する範囲のことです。

ロガー

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションのログを取得する，JavaロギングAPIのLoggerオブジェクトです。

ログインモジュール

JAASに準拠した統合ユーザ管理のユーザ認証に使用する，JAAS APIのLoginModuleインタフェースの実装クラスです。

索引

[記号]
[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｇ][Ｈ][Ｊ][Ｌ][Ｏ][Ｐ][Ｒ][Ｓ][Ｔ][Ｕ][Ｖ][Ｗ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行]

(記号)

-XX:+HitachiJavaClassLibTrace

-XX:+HitachiOutOfMemoryStackTrace

-XX:+HitachiUseExplicitMemory

-XX:+HitachiVerboseGC

-XX:+HitachiVerboseGCPrintTenuringDistribution

(数字)

08-00での主な機能変更

1.4モード

(英字)

(Ａ)

Active Directoryを使用する場合の設定

add.class.path

add.jvm.arg

add.library.path

APIとSPIの関係

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

Application Server

(Ｂ)

batch.ctm.enabled

batch.request.timeout

batch.schedule.group.name

batch.service.enabled

batch.vbroker.agent.port

BJEX

(Ｃ)

CallableStatementのプールサイズ

CCC#Ajp13

CCC#HttpSession

CCC#HttpSessionManager

CJLogRecordクラス

CJLogRecordクラスが属するパッケージ

CORBAネーミングサービス

cosminexus.xml

cosminexus.xmlを含まないアプリケーションのプロパティ設定

Cosminexus Component Transaction Monitor

Cosminexus Performance Tracer

Cosminexus アプリケーションサーバ

Cosminexus標準ログインモジュール

Cosminexus標準ログインモジュール

Cosminexus標準ログインモジュール

Cosminexus標準ログインモジュール

create時の選択ポリシー

CTM

CTM

ctm.Agent

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

CTMデーモン

CTMデーモン

CTMで使用するプロセス

CTMでスケジューリングできないリクエスト

CTMドメイン

CTMドメイン

CTMドメイン

CTMドメインマネジャ

CTMドメインマネジャ

CTMドメインマネジャ

CTMドメインマネジャの稼働状況確認

CTMドメインマネジャの稼働状態の確認

CTMに接続している最大時間の設定

CTMによるEnterprise Beanのスケジューリング機能とシステムの目的の対応

CTMによる同時実行数の動的変更

CTMによる流量制御

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

CTMのスケジュールキューの稼働状況の確認

CTMのスケジュールキューの同時実行数の変更

CTMのプロセス構成

CTMのプロセス構成

CTMレギュレータ

CTMレギュレータ

CTMを使用する場合に実行される処理

(Ｄ)

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

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

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

DD

DDでのクライアント性能モニタ機能の定義でカスタマイズできる項目

DDの定義例（統合ユーザ管理・セッションフェイルオーバ機能）

DelegationLoginModule

(Ｅ)

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.appname

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.count

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.encoding

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.filter

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.formatter

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.level

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.limit

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.msgid

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.path

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.separator

ejbserver.application.userlog.Logger.<ロガー名称>.filter

ejbserver.application.userlog.Logger.<ロガー名称>.handlers

ejbserver.application.userlog.Logger.<ロガー名称>.level

ejbserver.application.userlog.Logger.<ロガー名称>.useParentHandlers

ejbserver.application.userlog.loggers

ejbserver.batch.application.exit.enabled

ejbserver.batch.gc.watch.threshold

ejbserver.batch.queue.length

ejbserver.batch.schedule.group.name

ejbserver.client.ctm.RequestPriority

ejbserver.connectionpool.applicationAuthentication.disabled

ejbserver.connectionpool.sharingOutsideTransactionScope.enabled

ejbserver.container.rebindpolicy

ejbserver.ctm.ActivateTimeOut

ejbserver.ctm.DeactivateTimeOut

ejbserver.ctm.enabled

ejbserver.ctm.QueueLength

ejbserver.distributedtx.XATransaction.enabled

ejbserver.jndi.cache

ejbserver.jndi.cache.interval

ejbserver.jndi.cache.interval.clear.option

ejbserver.jndi.cache.reference

ejbserver.jndi.namingservice.group.<Specify group name>.providerurls

ejbserver.jndi.namingservice.group.list

ejbserver.jndi.request.timeout

ejbserver.jta.TransactionManager.defaultTimeOut

ejbserver.naming.host

ejbserver.naming.port

ejbserver.rmi.request.timeout

EJBアクセス機能

EJBクライアント

EJBクライアントアプリケーション

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

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

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

EJBクライアントから業務処理プログラムを呼び出す流れと負荷分散のタイミング

EJBコンテナ

ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

ExplicitMemoryインスタンスとExplicitメモリブロックの関係

Explicitヒープ

Explicitヒープ

Explicitヒープ

Explicitヒープに配置されるオブジェクト

Explicitヒープに配置すると効果があるオブジェクト

Explicitヒープに配置できるオブジェクト

Explicitヒープに配置できるオブジェクトの条件

Explicitヒープに配置できるオブジェクトの前提

Explicitメモリブロック

Explicitメモリブロック解放時に外部から参照されている場合の動作

Explicitメモリブロックの拡張

Explicitメモリブロックのサブ状態

Explicitメモリブロックの状態

Explicitメモリブロックの初期化

Explicitメモリブロックのライフサイクル

Explicitメモリブロックのライフサイクル

Explicitメモリブロックへのオブジェクトの直接生成

(Ｇ)

GSInfoKey-RWの定義（統合ユーザ管理・セッションフェイルオーバ機能）

GSInfosLengthMaxの定義（統合ユーザ管理・セッションフェイルオーバ機能）

(Ｈ)

HTTP Cookie情報の破棄

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

HTTP Cookieによる制御

HTTP Cookieによる制御

HTTP Cookieの有効期限

HttpSessionオブジェクトに関連するサーブレットAPIの注意点

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

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

HTTPセッション

HTTPセッション管理用オブジェクト

HTTPセッションで利用するExplicitヒープの省メモリ化機能

HTTPセッションで利用するExplicitヒープのメモリ使用量の削減

HTTPセッションに格納するオブジェクト

HTTPセッションに関するオブジェクト

HTTPセッションに関するオブジェクト

HTTPセッションに関するオブジェクトでExplicitヒープを利用する際の注意

HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ

HTTPセッションの縮退

HTTPセッションの属性情報のサイズの見積もり

(Ｊ)

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

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

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

J2EEアプリケーションのユーザログ出力の設定

J2EEサーバ

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

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

J2EEサーバ起動時の処理〔セッションフェイルオーバ〕

J2EEサーバ停止時のセッション情報の引き継ぎ

J2EEサーバの設定

J2EEリソースアダプタ

JAAS

jaas.conf（JAASのコンフィグレーションファイル）

jaas.confの再読み込み

jaas.confの作成

jaas.confの設定例

JAAS対応ユーザ管理

JAAS対応ユーザ管理

JAASでのユーザ認証の有効期限

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

java.naming.factory.initial

JavaVM終了メソッド呼び出し時のJavaVMの動作設定

JavaVMのプロパティの設定

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

Javaヒープの初期サイズと最大サイズの設定

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

JavaロギングAPI

JavaロギングAPI

Javaロギングの仕組み

JNDI（Java Naming and Directory Interface）

JNDI名前空間

JP.co.Hitachi.soft.jvm.autofinalize

JP1

JP1/AJS

JP1/AJS2 - SO

JP1/AJS2およびBJEXと連携するシステム

JP1/AJS2およびBJEXと連携するための設定

JP1/AJS2との連携

JP1/AJS2と連携するシステム

JP1/AJS2と連携するための設定

JP1/AJS2やBJEXと連携しないシステム

JP1ジョブ運用管理サーバ

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

JSPタグライブラリ

JSPタグライブラリ

JSPで暗黙的に作成されるHTTPセッション

(Ｌ)

LDAPディレクトリサーバの設置

LDAPディレクトリサーバの設定

LDAPディレクトリサーバの多重化による接続フェイルオーバ

LDAPディレクトリサーバの多重化の構成例

LDAPディレクトリサーバの多重化の構成例（マルチマスタ構成）

LDAPディレクトリサーバへのユーザ情報の登録

LimitRequestLineディレクティブ

LoginModuleインタフェースの実装時の留意点

LogManagerのカスタマイズ

(Ｏ)

ORBゲートウェイ

OTMゲートウェイ

(Ｐ)

PreparedStatementのプールサイズ

Principalオブジェクトの実装時の留意点

(Ｒ)

Realm

realservername

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

(Ｓ)

SecurityManager

SecurityManagerを使用しない設定

SFOサーバ

SFOサーバ

SFOサーバアプリケーション

SFOサーバアプリケーション

SFOサーバ停止時のセッション情報の引き継ぎ

SFOサーバでのJ2EEサーバの切断検知

SFOサーバでのグローバルセッション情報の管理

SFOサーバに障害が発生した場合のHttpSessionオブジェクトの最大数

SFOサーバに障害が発生した場合のグローバルセッション情報

SFOサーバの障害発生時のグローバルセッションIDの発行

SFOサーバの障害発生時のセッション情報の引き継ぎ

SFOサーバの設定

SFOサーバの複数配置

SFOサーバを複数配置するときの推奨構成

Stateless Session Beanに対するリモートインタフェース呼び出し

Suvivor領域の年齢分布情報の出力

(Ｔ)

Timer and Work Manager for Application Serversとの対応

TimerManager

TimerManagerのステータス遷移

TimerManagerの多重スケジュール数

TimerManagerのライフサイクル

TimerManagerを使用したスレッドのスケジューリング方式

TimerManagerを使用した非同期タイマ処理

TPBrokerクライアントまたはTPBroker OTMクライアントからのJ2EEアプリケーションの呼び出し

(Ｕ)

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

ua.confの作成

ua.confの設定例

ua.confの設定例（UNIXの場合）

uachpwコマンド

uCosminexus Batch Job Execution Server

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

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

URL書き換えによる制御

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

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

use.security

(Ｖ)

vbroker.agent.enableLocator

vbroker.se.iiop_tp.host

vbroker.se.iiop_tp.scm.iiop_tp.listener.port

(Ｗ)

WebCertificateLoginModule

WebPasswordJDBCLoginModule

WebPasswordLDAPLoginModule

WebPasswordLoginModule

WebSSOLoginModule

Webアプリケーション

Webアプリケーションの一致の確認のために使用される項目

Webアプリケーションの設定情報の削除

Webコンテナ

Webサーバ

WebサーバまたはJ2EEサーバで障害が発生した場合の処理

WebサーバまたはJ2EEサーバの障害発生時のセッション情報の引き継ぎ

Webサーバ連携

WorkManager

WorkManagerのライフサイクル

WorkManagerを使用したアプリケーションの開発

WorkManagerを使用した非同期スレッド処理

(ア行)

(あ)

空きレコード情報テーブル

アプリケーションサーバ

アプリケーションサーバ 08-70での主な機能変更

アプリケーションサーバが管理するトランザクションの外でのコネクションシェアリングの有効化

アプリケーションサーバの機能の分類

アプリケーション識別子

アプリケーション情報テーブル

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

アプリケーションの実行基盤を運用・保守するための機能

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

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

暗号鍵ファイルの作成

暗号鍵ファイルの作成（シングルサインオンを使用する場合）

暗号鍵ファイルの変更

暗号拡張

(い)

一括ですべての性能データを削除する

(お)

応答時間

同じネットワークセグメント内でのCTMドメインマネジャによる情報共有

オブジェクトクラスとユーザ定義属性の拡張

オブジェクトをExplicitヒープに配置するための実装

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

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

(カ行)

(か)

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

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

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

ガーベージコレクションのアルゴリズム

回復機能

書き換え可能グローバルセッション情報

各実行環境の設定内容の例

各フィールドが示す値（MemoryUsageクラスのインスタンス）

各フィールドの情報（MemoryUsageクラスのインスタンス）

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

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

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

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

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

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

カスタムログインモジュールのセッション

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

カスタムログインモジュールを使用したユーザ認証の実装

簡易構築定義ファイルでのリクエストの負荷分散の定義

完全一致指定

完全一致指定

完全性保障モード

(き)

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

機能説明の分類

キュー

キューの滞留監視

キュー名称

業務処理プログラム

(く)

クライアント性能測定スクリプト

クライアント性能測定スクリプトの挿入条件

クライアント性能測定スクリプトの挿入条件

クライアント性能フィルタ

クライアント性能フィルタの定義方法

クライアント性能モニタ機能

クライアント性能モニタ機能運用時の注意事項

クライアント性能モニタ機能がサポートするサーバ種別

クライアント性能モニタ機能が提供しているAPIおよびサンプル

クライアント性能モニタ機能で実行される処理

クライアント性能モニタ機能で測定できるWebアプリケーションの処理時間と分析方法

クライアント性能モニタ機能で予約されているファイル名

クライアント性能モニタ機能の運用

クライアント性能モニタ機能を構成する要素

クライアント性能モニタ機能を使用するための実装

クライアント性能モニタのディレクトリ構成

クライアント性能モニタのメモリ所要量

クラスタ

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

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

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

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

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

グローバルセッション

グローバルセッション

グローバルセッションID

グローバルセッションID

グローバルセッションIDの形式

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

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

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

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

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

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

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

グローバルセッション情報操作中の障害発生時の動作

グローバルセッション情報として引き継げるHTTPセッションの属性

グローバルセッション情報に含まれる情報

グローバルセッション情報の格納

グローバルセッション情報の更新

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

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

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

グローバルセッション情報の削除

グローバルセッション情報の種別

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

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

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

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

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

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

グローバルセッションを利用したセッション管理（データベースセッションフェイルオーバ機能）

グローバルセッションを利用したセッション管理（メモリセッションフェイルオーバ機能）

(こ)

構築済み実行環境の切り替え手順

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

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

構築済み実行環境を切り替えるための準備

異なるHTTPセッションに同一のオブジェクトが登録されている場合を考慮した処理

異なるネットワークセグメントでのCTMドメインマネジャによる情報共有

コネクション管理スレッド

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

コネクションスイーパ

コネクション数調節機能

コネクションの最小値と最大値

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

コネクションの障害検知

コネクションのレギュレート

コネクションのレギュレートの仕組み

コネクションプールのウォーミングアップ

コマンドによる登録

コマンドによる登録

コンテナ拡張ライブラリ

コンテナ拡張ライブラリ

コンテナ拡張ライブラリの概要

コンフィグレーションファイルの作成

コンフィグレーションファイルの設定例

(サ行)

(さ)

サーバ管理コマンド

サーバ起動・停止フック機能

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

サービス閉塞

サーブレットAPIへの影響

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

サーブレットフィルタ

最新性能情報を表示する

最新統計情報を表示する

最新のログシーケンスの性能データを削除する

削除機能

参照専用リクエスト

(し)

システム内に複数のSFOサーバを配置する場合の設定例

実サーバ名の設定

自動解放機能が無効な場合のExplicitメモリブロックの解放

自動解放機能が無効な場合のExplicitメモリブロックの解放処理

自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約

自動解放機能が有効な場合のExplicitメモリブロックの解放

自動解放機能が有効な場合のExplicitメモリブロックの解放処理

自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約

自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約

常駐スレッド数の平均化

ジョブ

ジョブID

処理時間の分析

シリアライズおよびデシリアライズに失敗する原因

シリアライズ処理で使用するメモリの見積もり

シリアライズに失敗する場合とその対処

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

シングルサインオン

シングルサインオン

シングルサインオン

シングルサインオン情報リポジトリ

シングルサインオン情報リポジトリ

シングルサインオン情報リポジトリのDIT構造

シングルサインオンへの対応例（カスタムログインモジュールの場合）

シングルサインオンへの対応例（標準ログインモジュールの場合）

シングルサインオンライブラリ

シングルサインオンライブラリ

(す)

スケジューリング機能使用時の注意事項

スケジューリング機能使用時のバッチアプリケーション実行環境の構築と運用

スケジューリング機能で必要なプロセス

スケジューリング機能の概要

スケジューリング機能を使用したシステム

スケジューリング機能を使用したシステムの構成

スケジューリング機能を使用したシステムの構成例

スケジューリング機能を使用したバッチアプリケーションの実行

スケジューリング機能を使用したバッチアプリケーションの実行処理の流れ

スケジューリング機能を使用したバッチアプリケーションの状態遷移

スケジューリング機能を使用する環境への移行

スケジューリング機能を使用する設定〔バッチアプリケーションで使用するコマンドの設定〕

スケジューリング機能を使用する設定〔バッチサーバの設定〕

スケジューリング機能を使用するための前提

スケジュールキュー

スケジュールキュー

スケジュールキュー

スケジュールキュー

スケジュールキュー監視

スケジュールキュー監視機能

スケジュールキュー滞留監視式

スケジュールキューで制御されるリクエスト

スケジュールキューの強制閉塞

スケジュールキューの共有

スケジュールキューの作成単位

スケジュールキューの作成単位とキューの共有

スケジュールキューのタイムアウト閉塞

スケジュールキューのタイムアウト閉塞

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

スケジュールキューの長さの設定〔簡易構築定義ファイル〕

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

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

スケジュールキューを共有しない例

スケジュールキューを共有する例（Bean単位）

スケジュールキューを共有する例（J2EEアプリケーション単位）

スケジュールグループ

スケジュールグループ名の設定〔usrconf.cfg〕

スケジュールグループ名の設定〔簡易構築定義ファイル〕

スケジュールポリシー

スケジュールポリシー

ステートメントキャンセル

スマートエージェント

スマートエージェントが使用しているポート番号の設定

スマートエージェントを使用する設定

スレッドの使用

スレッドの非同期並行処理

スレッドの非同期並行処理で使用できるJava EEの機能

スレッドの非同期並行処理の概要

スレッドの非同期並行処理の流れ

(せ)

性能解析トレースとのマッチング

性能情報

［性能情報］画面

性能情報を表示する

性能データ

性能データの取得

性能データの取得フェーズで実行される処理

性能データの表示

性能データの表示フェーズで提供する機能

性能データをサーバ側で収集して確認する

性能データを削除する

性能データをモニタページに表示させて確認する

性能データを読み出すアプリケーションの作成

性能データを読み出すためのサンプルソース

セキュリティアイデンティティ

セッション

セッション情報

セッション情報格納テーブル

セッション情報の格納の流れ

セッション情報の引き継ぎが発生した場合の認証情報の扱い

セッション情報の引き継ぎ処理

セッションタイムアウト時のログアウト（セッションフェイルオーバ機能使用時）

セッションの種類

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

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

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

セッションフェイルオーバ機能使用時のログインとログアウトの実装

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

セッションフェイルオーバ機能の種類と差異

セッションフェイルオーバ機能の前提条件

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

セッションフェイルオーバ機能を利用する利点

セッションフェイルオーバサーバ

セッションフェイルオーバ用フィルタ

セッションフェイルオーバ用フィルタの処理

接続できるデータベース

選択したログシーケンスの性能情報を表示する

選択したログシーケンスの性能データを削除する

選択したログシーケンスの統計情報を表示する

(そ)

操作時間

属性の一覧の設定例

そのほかの拡張機能とシステムの目的の対応

(タ行)

(た)

退避環境

退避環境一覧出力機能

退避環境作成時に退避対象となるファイル

退避環境作成時に退避対象となるファイル

退避機能

退避作業が必要なファイル

退避作業が必要なファイルと作業方法

退避作業が不要なファイル

退避作業が不要なファイル

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

短寿命Work

(ち)

長寿命Work

長寿命オブジェクト

(つ)

通信時間

(て)

ディスク容量の確認

［データ削除］画面

データベースコネクション確立までの待ち時間

データベースセッションフェイルオーバ機能

データベースセッションフェイルオーバ機能

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

データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ

データベースセッションフェイルオーバ機能の定義

データベースセッションフェイルオーバ機能の抑止

データベース接続ユーザ

データベースで障害が発生した場合の処理

データベースとの通信が発生するサーブレットAPI

データベースの環境設定

データベースの設定

データベースのディスク容量の確保

データベースのテーブルの作成

デーモンWork

デーモンWorkと非デーモンWork

デーモンWorkのライフサイクル

(と)

問い合わせIDの定義方法

統計情報

［統計情報］画面

統計情報を表示する

統合ネーミングスケジューラサーバ

統合ネーミングスケジューラサーバモデル

統合ユーザ管理

統合ユーザ管理

統合ユーザ管理機能の設定手順

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

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

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

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

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

統合ユーザ管理フレームワーク

統合ユーザ管理フレームワーク

統合ユーザ管理フレームワーク

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

統合ユーザ管理フレームワークと個別のユーザ管理の関連

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

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

統合ユーザ管理フレームワークのライブラリによる登録

統合ユーザ管理フレームワークのライブラリによる登録

統合ユーザ管理フレームワークのリポジトリのDIT構造

統合ユーザ管理を使用する場合の処理の流れ

同時実行数に指定できる値〔CTM〕

同時実行数の動的変更〔CTM〕

動的変更の処理の仕組み

登録するユーザ情報の文法

登録するユーザ情報の文法

トランザクションサポートレベル

(ナ行)

(に)

認証状態の引き継ぎ

認証処理

認証用プログラムのコーディング例（Windowsの場合）

(ね)

ネーミング管理

ネーミング管理機能

ネーミングサービス

ネーミングサービスの通信タイムアウト

ネーミングのキャッシング

ネゴシエーションが失敗した場合の対処

ネゴシエーション処理の結果とWebアプリケーションの状態の関係

ネゴシエーションで確認される内容

(ハ行)

(は)

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

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

発生するイベントと動作するリスナ

バッチアプリケーション

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

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

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

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

バッチアプリケーション実行時に使用する機能とシステムの目的の対応

バッチアプリケーション実行時の注意事項

バッチアプリケーション実行の流れ〔スケジューリング機能を使用しない場合〕

バッチアプリケーション実行の流れ〔スケジューリング機能を使用する場合〕

バッチアプリケーション情報の一覧表示〔スケジューリング機能を使用しない場合〕

バッチアプリケーション情報の一覧表示〔スケジューリング機能を使用する場合〕

バッチアプリケーションで実装できない機能

バッチアプリケーションで使用するコマンドの実行について〔スケジューリング機能を使用しない場合〕

バッチアプリケーションで使用するコマンドの実行について〔スケジューリング機能を使用する場合〕

バッチアプリケーションに実装できる処理

バッチアプリケーションの開始処理〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの開始方法〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの強制停止〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの強制停止〔スケジューリング機能を使用する場合〕

バッチアプリケーションの強制停止実行時の注意事項

バッチアプリケーションの強制停止処理〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの強制停止方法〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの実行〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの実行〔スケジューリング機能を使用する場合〕

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

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

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

バッチアプリケーションの実装（EJBにアクセスする場合）

バッチアプリケーションの実装（Javaアプリケーションからの移行）

バッチアプリケーションの実装（バッチアプリケーションの作成規則）

バッチアプリケーションの実装（リソースに接続する場合）

バッチアプリケーションの終了処理〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの状態遷移〔スケジューリング機能を使用しない場合〕

バッチアプリケーションの状態遷移〔スケジューリング機能を使用する場合〕

バッチアプリケーションのスケジューリング

バッチアプリケーションのスケジューリング機能

バッチアプリケーションのファイル形式

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

バッチアプリケーションのライフサイクル

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

バッチアプリケーションを実行するクラスローダ

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

バッチアプリケーションを実行するシステムの構成例〔スケジューリング機能を使用しない場合〕

バッチアプリケーションをスケジューリングする利点

バッチサーバ

バッチサーバおよびバッチアプリケーションの操作の流れ

バッチサーバとしてサーバを構築するための設定

バッチサーバによるアプリケーションの実行

バッチサーバの通信ポートとIPアドレスの固定

ハンドラ

ハンドラ

ハンドラ

ハンドラの作成と設定

(ひ)

引き継げるHTTPセッションの属性

日立固有のJavaVMのログの取得（日立JavaVMログファイル）

日立トレース共通ライブラリ

日立トレース共通ライブラリ

日立トレース共通ライブラリ形式

非デーモンWork

非デーモンWorkで使用するスレッドプールとキューについて

非デーモンWorkのライフサイクル

非同期スレッド処理

非同期タイマ処理

描画時間

(ふ)

ファイナライズ処理での滞留の解消

ファイルのデプロイ

ファイルやディレクトリの操作

負荷状況の監視

負荷分散

負荷分散〔CTM〕

負荷分散機

負荷分散機

負荷分散のタイミング

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

プリフィックス一致指定

プリフィックス一致指定

フルガーベージコレクションの抑止

フルガーベージコレクション発生を抑止する仕組み

フレーム構成のWebブラウザを操作した場合の性能情報を確認する

(へ)

閉塞制御

閉塞制御〔CTM〕

(マ行)

(ま)

マニュアル（機能解説）の体系

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

(む)

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

(め)

明示管理ヒープ機能

明示管理ヒープ機能

明示管理ヒープ機能

明示管理ヒープ機能API

明示管理ヒープ機能APIのクラス階層

明示管理ヒープ機能APIを使ったJavaプログラムの実装

明示管理ヒープ機能使用時の注意事項

明示管理ヒープ機能で使用するメモリ空間の概要

明示管理ヒープ機能のJavaVMオプションの定義

明示管理ヒープ機能の位置づけ

明示管理ヒープ機能の位置づけ

明示管理ヒープ機能の稼働情報を取得するための実装

明示管理ヒープ機能の利用

明示管理ヒープ機能の利用によるフルガーベージコレクションの抑止の仕組み

明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違い

明示管理ヒープ機能を使用しない設定

明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）

明示管理ヒープ機能を利用する場合の前提条件

明示管理ヒープ機能を利用する目的

メモリセッションフェイルオーバ機能

メモリセッションフェイルオーバ機能

メモリセッションフェイルオーバ機能使用時の障害検知

面数

(も)

モニタページに関する注意事項

モニタページのアクセス制御の定義方法

モニタページの画面構成

モニタページを表示する

(ヤ行)

(ゆ)

ユーザエントリの構造

ユーザ作成クラス

ユーザ情報

ユーザ情報の管理

ユーザ情報の登録

ユーザ情報の登録（シングルサインオンを使用する場合）

ユーザ情報リポジトリ

ユーザ情報リポジトリ

ユーザ情報リポジトリのDIT構造

ユーザ独自のフィルタ／フォーマッタ／ハンドラ

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

ユーザ認証の有効期間

ユーザ認証ライブラリ

ユーザ認証ライブラリ

ユーザ認証ライブラリおよびシングルサインオンライブラリの位置づけ

ユーザ認証リポジトリ

ユーザの登録とアクセス権の設定

ユーザマッピング

ユーザマッピング

ユーザマッピング

ユーザマッピング機能

ユーザログ

ユーザログ

ユーザログ機能

ユーザログ出力処理の流れ

ユーザログ出力で使用するLoggerクラスのメソッド

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

優先制御〔CTM〕

(よ)

読み込み専用グローバルセッション情報

(ラ行)

(ら)

ライトトランザクション機能を有効にするための設定

ライフサイクルの各段階で出力されるイベントログ

ライフサイクルの各段階と出力されるイベントログの対応

ラウンドロビン検索

(り)

リクエスト実行時の処理

リクエスト転送時のタイムアウト

リクエストのスケジューリング

リクエストラインの最大サイズの設定

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

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

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

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

リソースアダプタの設定方法

リソース接続機能

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

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

リソースへの接続方法

リダイレクタとの通信用オブジェクト

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

流量制御

流量制御

流量制御〔CTM〕

(れ)

レギュレート

レルム

レルム

レルム

レルム名

レルム名の決定

(ろ)

ロガー

ロガー

ロガー

ロガーの作成と設定

ログアウト（セッションフェイルオーバ機能使用時）

ログイン（セッションフェイルオーバ機能使用時）

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

ログインしているかどうかを確認する方法

ログイン状態のチェック（セッションフェイルオーバ機能使用時）

ログインモジュール

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

ログシーケンス

［ログシーケンス一覧］画面

ログシーケンスの分岐

ログのフォーマット

ログフォーマット

ロック待ち

■ 商標類

Active Directoryは，米国Microsoft Corporationの，米国およびその他の国における登録商標または商標です。
AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
AX2000は，A10 Networks, Inc.の商品名称です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Internet Explorerは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
J2EEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Javaは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JavaScriptは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDBCは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JDKは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
JSPは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corporationの商品名称です。
MyEclipseは，米国Genuitec社の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle9iは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 10gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Oracle及びOracle Database 11gは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
SecureWayは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
SOAP（Simple Object Access Protocol）は，分散ネットワーク環境においてXMLベースの情報を交換するための通信プロトコルの名称です。
Solarisは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
すべてのSPARC商標は，米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は，米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。
SQL Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
SQL*Plusは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sunは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
Sun Microsystemsは，Oracle Corporation 及びその子会社，関連会社の米国 及びその他の国における登録商標または商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Serverは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Windows Vistaは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).