Cosminexus V11 アプリケーションサーバ 機能解説 拡張編

解説書

3021-3-J08-50

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DABroker，HAモニタ，HiRDB，JP1，OpenTP1，TPBroker，uCosminexus，XDMは，株式会社 日立製作所の商標または登録商標です。

AIXは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

EclipseおよびJakartaは，Eclipse Foundation, Inc.の商標です。

Linuxは，Linus Torvalds氏の米国およびその他の国における登録商標です。

Microsoft，Active Directory，Azure，SQL Server，Windows，Windows Server は，マイクロソフト 企業グループの商標です。

Oracle(R)，Java ，MySQL及びNetSuite は，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat, and Red Hat Enterprise Linux are registered trademarks of Red Hat, Inc. in the United States and other countries. Linux(R) is the registered trademark of Linus Torvalds in the U.S. and other countries.

Red Hat，およびRed Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。Linux(R)は，米国およびその他の国におけるLinus Torvalds氏の登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

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

マイクロソフトの許可を得て使用しています。

発行

2024年 2月 3021-3-J08-50

著作権

All Rights Reserved. Copyright (C) 2020, 2024, Hitachi, Ltd.

変更内容

変更内容(3021-3-J08-50) uCosminexus Application Server 11-40，uCosminexus Client 11-40，uCosminexus Developer 11-40，uCosminexus Service Architect 11-40，uCosminexus Service Platform 11-40

追加・変更内容

変更個所

アプリケーションサーバ11-40での主な機能変更についての説明を追加した。

1.4

JDK17サポートに伴い，JDK11でだけ使用できるパラメタに注意事項を追加した。

2.3.10

ZGCが有効な場合のメモリ監視について説明を追加した。

2.9.2(1)

JDK17以降を使用する場合は，明示管理ヒープ機能を使用できないことを追加した。また，G1GCのチューニングおよびZGCのチューニングについて説明を追加した。

7

ejbserver.server.eheap.httpsession.enabledについて，パラメタが無効になる条件を追加した。

7.13.4(1)

次の適用OSを削除した。

Windows Server 2019 Standard

Windows Server 2019 Datacenter

これに伴い，関連する記載を削除または変更した。

-

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

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

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

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

1.1　機能の分類

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

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

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

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

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

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

図1‒1　アプリケーションサーバの機能の分類と対応するマニュアル

注※1

マニュアル名称の「アプリケーションサーバ」を省略しています。

注※2

アプリケーションサーバでは，SOAP WebサービスとRESTful Webサービスを実行できます。目的によっては，マニュアル「アプリケーションサーバ Webサービス開発ガイド」以外の次のマニュアルも参照してください。

SOAPアプリケーションを開発・実行する場合

アプリケーションサーバ SOAPアプリケーション開発の手引

SOAP WebサービスやSOAPアプリケーションのセキュリティを確保する場合

XML Security - Core ユーザーズガイド

アプリケーションサーバ Webサービスセキュリティ構築ガイド

XMLの処理について詳細を知りたい場合

XML Processor ユーザーズガイド

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

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

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

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

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

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

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

アプリケーションサーバでは，Java EE 8に対応した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)　Webサービスを開発するための機能

Webサービスの実行環境および開発環境としての機能が該当します。

アプリケーションサーバでは，次のエンジンを提供しています。

JAX-WS仕様に従ったSOAPメッセージのバインディングを実現するJAX-WSエンジン

JAX-RS仕様に従ったRESTful HTTPメッセージのバインディングを実現するJAX-RSエンジン

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

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

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

(4)　システムのセキュリティを確保するための機能（セキュリティ管理機能）

アプリケーションサーバを中心としたシステムのセキュリティを確保するための機能が該当します。不正なユーザからのアクセスを防止するための認証機能や，通信路での情報漏えいを防止するための暗号化機能などがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1‒1　機能の分類と機能解説のマニュアルの対応

分類

機能

マニュアル※1

基本・開発機能

Webコンテナ

基本・開発編(Webコンテナ)

JSFおよびJSTLの利用

JAX-RS 2.1の利用

WebSocket

NIO HTTPサーバ

サーブレットおよびJSPの実装

セッションマネージャの指定機能

EJBコンテナ

基本・開発編(EJBコンテナ)

EJBクライアント

Enterprise Bean実装時の注意事項

ネーミング管理

基本・開発編(コンテナ共通機能)

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

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

JPA 2.2の利用

CJMSプロバイダ

JavaMailの利用

アプリケーションサーバでのCDIの利用

アプリケーションサーバでのBean Validationの利用

Java Batch

JSON-P

JSON-B

Concurrency Utilities

アプリケーションの属性管理

アノテーションの使用

J2EEアプリケーションの形式とデプロイ

コンテナ拡張ライブラリ

ライブラリ競合回避機能

パッケージ名変換機能

拡張機能

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

拡張編※2

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

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

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）

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

明示管理ヒープ機能を使用したFullGCの抑止

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

セキュリティ管理機能

統合ユーザ管理による認証

セキュリティ管理機能編

アプリケーションの設定による認証

SSL/TLS通信でのTLSv1.2の使用

APIによる直接接続を使用する負荷分散機の運用管理機能からの制御

運用機能

システムの起動と停止

運用／監視／連携編

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

監視機能

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

リソースの枯渇監視

監査ログ出力機能

データベース監査証跡連携機能

運用管理コマンドによる稼働情報の出力

Managementイベントの通知とManagementアクションによる処理の自動実行

CTMの稼働統計情報の収集

コンソールログの出力

連携機能

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

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

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

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

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

1:1系切り替えシステム（クラスタソフトウェアとの連携）

相互系切り替えシステム（クラスタソフトウェアとの連携）

N:1リカバリシステム（クラスタソフトウェアとの連携）

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

保守機能

トラブルシューティング関連機能

保守／移行編

性能解析トレースを使用した性能解析

製品のJavaVM（以降，JavaVMと略す場合があります）の機能

移行機能

旧バージョンのアプリケーションサーバからの移行

推奨機能への移行

互換機能

基本・開発機能の互換機能

互換編

拡張機能の互換機能

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

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

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

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

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

信頼性

高い信頼が求められるシステムの場合に使用するとよい機能です。

アベイラビリティ（安定稼働性）およびフォールトトレランス（耐障害性）を高める機能や，ユーザ認証などのセキュリティを高めるための機能が該当します。

性能

性能を重視したシステムの場合に使用するとよい機能です。

システムのパフォーマンスチューニングで使用する機能などが該当します。

運用・保守

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

拡張性

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

そのほか

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

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

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の出力

−

−

○

−

−

−

○

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

○

−

−

−

−

○

−

リソースへの接続テスト

−

−

○

−

−

−

○

GC制御機能

−

○

−

−

−

−

○

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章

明示管理ヒープ機能を使用したFullGCの抑止

○

−

−

−

−

−

○

7章

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

−

−

○

−

−

−

○

8章

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

注

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

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

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

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

ポイント

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

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

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

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

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

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

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

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

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

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

1.4.1　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

Java SE 17への対応

Java SE 17の機能が使用できるようになりました。

システム設計ガイド

2.1

機能解説 保守／移行編

9章

メモリ管理方式にZGCを追加

メモリ管理方式にZGCを追加しました。

システム設計ガイド

7.17

接続できるデータベースにAzure SQL Databaseを追加

DB Connectorを使用して接続できるデータベースにAzure SQL Databaseを追加しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6.17

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

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

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

2.1　この章の構成

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

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

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

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

機能名

参照先

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

2.3

EJBアクセス機能

2.4

ネーミング管理機能

2.5

リソース接続機能

2.7

トランザクション管理

2.8

GC制御機能

2.9

コンテナ拡張ライブラリ

2.10

JavaVMの機能

2.11

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

2.12

JP1/AJSとの連携

2.13

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

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

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

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

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

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

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

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

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

バッチアプリケーションを実行するシステムには，バッチサーバが必要です。また，バッチアプリケーションを実行するシステムは，次の製品と連携する運用もできます。

JP1/AJS

BJEXまたはJP1/Advanced Shell

これらの製品と連携すると，バッチサーバの起動・停止や，バッチアプリケーションの開始をジョブとして定義して，バッチアプリケーションを自動実行できます。また，BJEX，またはJP1/Advanced Shellと連携すると，バッチアプリケーションの実行コマンドの戻り値を使用したジョブステップの条件付き実行機能を使用したり，ジョブを強制終了したときにバッチアプリケーションを自動的に停止させたりできます。

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

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

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

この図の場合，バッチアプリケーションを実行するシステムは，次の製品と連携しています。

JP1/AJS

BJEXまたはJP1/Advanced Shell

これらの製品と連携しない場合は，図中の運用管理クライアント，JP1ジョブ運用管理サーバ，ならびにバッチサーバのBJEX，JP1/Advanced Shell，JP1/AJS - AgentおよびJP1/Baseは必要ありません。

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

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

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

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

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

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

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

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

参考

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

(2)　JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するシステム

次の製品と連携するシステムでは，バッチサーバの起動や，バッチアプリケーションの実行および強制停止は，JP1/AJS，BJEX，またはJP1/Advanced Shellから操作します。

JP1/AJS

BJEXまたはJP1/Advanced Shell

JP1/AJS，BJEX，およびJP1/Advanced Shellでは，あらかじめバッチサーバやバッチアプリケーションの操作をジョブとして定義します。

注意事項

BJEXと連携する場合は，JP1/AJSとも連携する必要があります。JP1/Advanced Shellと連携する場合，JP1/AJSと連携する必要はありません。

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

図2‒4　バッチサーバおよびバッチアプリケーション操作の流れ（JP1/AJS，BJEX，およびJP1/Advanced Shell連携）

バッチサーバは，JP1/AJSからアプリケーションサーバのManagement Serverを経由して起動します。バッチアプリケーションの実行，およびバッチアプリケーションの強制停止は，JP1/AJSからBJEXまたはJP1/Advanced Shellを経由してバッチアプリケーションに対して実行します。このため，JP1/AJS，BJEX，およびJP1/Advanced Shellで，次に示す操作をあらかじめジョブに定義します。

バッチサーバの起動

JP1/AJSのUNIXジョブまたはPCジョブとして定義します。

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

JP1/AJSのUNIXジョブまたはPCジョブとして，BJEXのジョブ定義XMLファイルまたはJP1/Advanced Shellのジョブ定義スクリプトファイルを指定します。また，BJEXのジョブ定義XMLファイルまたはJP1/Advanced Shellのジョブ定義スクリプトファイルにバッチアプリケーションの実行を定義します。

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

実行中のUNIXジョブまたはPCジョブをJP1/AJSから強制終了した場合，その命令を受けたBJEXまたはJP1/Advanced Shellは，バッチアプリケーションを自動的に停止させます。

JP1/AJS，BJEX，およびJP1/Advanced Shellでのジョブ定義については，「2.13.2　JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するための設定」を参照してください。

参考

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

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

(3)　JP1/AJS，BJEX，およびJP1/Advanced Shellと連携しないシステム

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

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

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

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

参考

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

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

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

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

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

Smart Composer機能を使用してシステムを構築します。

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

サーバ管理コマンドを使用して，リソースアダプタを設定します。

バッチアプリケーションからデータベースに接続する場合だけ実施します。

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

注意事項

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

参考

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

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

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

システムの起動

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

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

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

バッチサーバの停止

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

参考

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

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

システムの起動および停止の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.6　システムの起動と停止の設定」を参照してください。バッチアプリケーションの開始方法については，「2.3.2　バッチアプリケーションの実行」を参照してください。

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

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

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

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

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

運用管理コマンドによる稼働情報の出力

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

リソースの枯渇監視

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

Managementイベントの通知とManagementアクションによる処理の自動実行

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

CTMの稼働統計情報の収集

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

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

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

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

コンソールログ出力

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

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

ユーザログ出力

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

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

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

監査ログの出力

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

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

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

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

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

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

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

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

トラブルシューティング

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

例えば，システムにトラブルが発生した場合には，トラブルシューティング情報としてsnapshotログを自動的に収集できます。

性能解析トレースを使用したシステムの性能解析

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

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

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

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

JP1との連携

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

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

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

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

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

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

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

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

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

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

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

クラスタソフトウェアとの連携による系切り替え機能の概要について説明します。連携できるクラスタソフトウェアは，Windows Server Failover Cluster※（Windowsの場合），およびHAモニタ（AIX・Linuxの場合）です。

注※

使用できるOSは，Windows Server 2022 Standard/Datacenterとなります。

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‒6　バッチアプリケーション実行機能の概要

また，バッチアプリケーション実行機能は，EJBアクセス機能やリソース接続機能と連携できます。

EJBアクセス機能と連携すると，バッチアプリケーションからほかのJ2EEサーバのEJBにアクセスできます。

リソース接続機能と連携すると，バッチアプリケーションからデータベースに接続できます。

EJBアクセス機能については「2.4.1　EJBアクセスで使用できる機能」を，リソース接続機能については「2.7　リソース接続機能」を参照してください。

次に，バッチアプリケーションのライフサイクルとバッチアプリケーションを実行するクラスローダについて説明します。

(1)　バッチアプリケーションのライフサイクル

バッチアプリケーションは，cjexecjobコマンドを使用して開始します。次の図を使用して，バッチアプリケーションのライフサイクルについて説明します。

図2‒7　バッチアプリケーションのライフサイクル

cjexecjobコマンドを実行すると，バッチアプリケーションはバッチクラスローダによってロードされます。

バッチアプリケーションがバッチサーバ上で実行されます。

バッチアプリケーションの処理が終了します。

バッチアプリケーションの処理終了後に，バッチアプリケーションをロードしたバッチクラスローダがGCされます。

バッチアプリケーションのクラスがアンロードされます。

注意事項

バッチアプリケーションはcjexecjobコマンドが実行されるたびにバッチクラスローダにロードされ，処理が完了するとクラスがアンロードされます。常駐形式のバッチアプリケーションをバッチサーバ上で動作させることは推奨しません。

(2)　バッチアプリケーションの状態遷移

バッチアプリケーションの状態遷移を次の図に示します。

図2‒8　バッチアプリケーションの状態遷移（スケジューリング機能を使用しない場合）

「RUNNING」は，バッチアプリケーションがバッチサーバ上にあって実行中の状態です。

バッチアプリケーションの状態は，バッチアプリケーション情報から確認できます。バッチアプリケーション情報の表示方法については，「2.3.4　バッチアプリケーション情報の一覧表示」を参照してください。

(3)　バッチアプリケーションを実行するクラスローダ

バッチアプリケーション実行時には，バッチサーバ上でバッチアプリケーション用のクラスローダが生成されます。バッチアプリケーションはクラスローダ上で実行されます。バッチアプリケーション用のクラスローダの構成を次の図に示します。

図2‒9　バッチアプリケーションを実行するクラスローダの構成

図のそれぞれのクラスローダについて説明します。

システムクラスローダ

アプリケーションサーバの構成ソフトウェアが提供するクラスやコンテナ拡張ライブラリのクラスをロードします。

生成タイミング：J2EEサーバ起動時

破棄タイミング：J2EEサーバ停止時

コネクタクラスローダ

リソースアダプタに含まれるクラスをロードします。バッチサーバ内に一つだけ存在します。

生成タイミング：J2EEサーバ起動時

破棄タイミング：J2EEサーバ停止時

バッチクラスローダ

バッチアプリケーションに含まれるクラスをロードします。バッチアプリケーションを実行するスレッドのコンテキストクラスローダは，バッチクラスローダです。

生成タイミング：バッチアプリケーション実行時

破棄タイミング：バッチアプリケーション終了時

なお，バッチクラスローダ生成時には，バッチクラスローダが生成されたことを示すメッセージが出力されます（メッセージKDJE55013-I）。また，バッチクラスローダのファイナライズ処理が実行されたことを示すメッセージも出力されます（メッセージKDJE55014-I）。

クラスローダの破棄についての注意事項は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「付録B.1　デフォルトのクラスローダ構成」を参照してください。なお，クラスローダの破棄のタイミング，クラスローダの破棄時に出力されるメッセージについては適宜読み替えてください。

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

バッチアプリケーションは，cjexecjobコマンドで開始します。バッチアプリケーションのmainメソッドの実行が終わると，バッチサーバはFullGCを実行します。ここでは，バッチアプリケーションの開始方法と，バッチアプリケーションの開始および終了時の処理について説明します。

なお，実行中のバッチアプリケーションを停止する場合には，強制停止をします。バッチアプリケーションの強制停止の方法については，「2.3.3　バッチアプリケーションの強制停止」を参照してください。

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

ここでは，バッチアプリケーションの開始方法について説明します。

バッチアプリケーションを開始するにはcjexecjobコマンドを使用します。cjexecjobコマンドを実行するには，次の四つの方法があります。

cjexecjobコマンドを直接実行する方法

JP1/AJS，BJEX，およびJP1/Advanced Shellを使用しない場合はこの方法で開始します。

cjexecjobコマンドをJP1/AJSのジョブとして定義しておき，JP1/AJSから実行する方法

JP1/AJSだけを使用する場合はこの方法で開始します。

cjexecjobコマンドをBJEXのジョブステップとして定義しておき，JP1/AJSからBJEXのジョブを実行する方法

JP1/AJSおよびBJEXを使用する場合はこの方法で開始します。

JP1/Advanced Shellのジョブ定義スクリプトファイルから，JP1/Advanced Shellが提供するadshjavaコマンドを使用して実行する方法

JP1/Advanced Shellを使用する場合はこの方法で開始します。なお，この方法では，JP1/Advanced Shellを直接実行することも，JP1/AJS経由でJP1/Advanced Shellを実行することもできます。

2.，3.，および4.の方法で，バッチアプリケーションを開始するときの，JP1/AJS，BJEX，およびJP1/Advanced Shellのジョブの定義については，「2.13　JP1/AJSとの連携」を参照してください。

なお，JP1/AJS，BJEX，およびJP1/Advanced Shellからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

(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）を出力します。

FullGCを実行します。

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)　バッチアプリケーションの強制停止方法

バッチアプリケーションを強制停止するにはcjkilljobコマンドを使用します。cjkilljobコマンドを実行するには，次の三つの方法があります。

cjkilljobコマンドを直接実行する方法

JP1/AJSを使用しない場合はこの方法で開始します。

cjkilljobコマンドをJP1/AJSのリカバリージョブとして定義しておき，ジョブやジョブネットの強制停止の延長で実行する方法

BJEXまたはJP1/Advanced Shellの使用の有無に関係なく，JP1/AJSを使用する場合はこの方法で開始します。

2.の方法で，JP1/AJSのリカバリージョブとしてバッチアプリケーションを強制停止するときのJP1/AJSのジョブの定義については，「2.13　JP1/AJSとの連携」を参照してください。

BJEXまたはJP1/Advanced Shellの強制停止の延長で，バッチアプリケーションを強制停止する方法

BJEXまたはJP1/Advanced Shellを使用してバッチアプリケーションを実行している場合，BJEXまたはJP1/Advanced Shellを強制終了することで，これらの製品を経由して実行されたバッチアプリケーションも自動的に停止されます。この方法では，JP1/AJSのリカバリージョブを定義する必要はありません。

なお，バッチアプリケーションの強制停止に失敗した場合，バッチサーバの強制停止が実行されます。このため，複数のアプリケーションを続けて実行する場合は，バッチサーバの再起動が必要になります。バッチアプリケーションの強制停止失敗に備えて，あらかじめバッチサーバを自動再起動するよう設定しておくことをお勧めします。バッチサーバの自動再起動は，Management Serverの運用監視を使用して実現できます。詳細は，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.4　障害発生時の自動再起動」を参照してください。

(2)　バッチアプリケーションの強制停止処理

実行中のバッチアプリケーションを強制停止するには，cjkilljobコマンドを使用します。cjkilljobコマンドを使用すると，バッチアプリケーションを実行しているスレッドに対してメソッドキャンセルを実行してバッチアプリケーションを強制停止します。

メソッドキャンセルとは，実行中のメソッドをキャンセルする機能です。ただし，メソッドを実行している領域によって，キャンセルできるメソッドとできないメソッドがあります。メソッドをキャンセルできる領域のことを非保護区，メソッドをキャンセルできない領域を保護区といいます。実行中のメソッドが非保護区の場合に，メソッドキャンセルが実行されます。バッチアプリケーションの強制停止で実行されるメソッドキャンセルは，J2EEアプリケーション実行時間の監視機能で実行されるメソッドキャンセルと同じです。メソッドキャンセルの処理については，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「5.3.4　メソッドキャンセルとは」を参照してください。

バッチアプリケーション強制停止時に実行される処理を次に示します。

バッチアプリケーションの強制停止処理を開始することを示すメッセージ（KDJE55004-I）を出力します。

public static void main(String[])メソッドまたはpublic static int main(String[])メソッドのメソッドキャンセルを実行します。

なお，メソッドキャンセルに失敗した場合，KDJE55017-Eを出力して強制停止が失敗し，バッチサーバが強制停止します。強制停止が失敗した場合は，バッチサーバを再起動してください。

バッチアプリケーションの強制停止処理が完了したことを示すメッセージ（KDJE55005-I）を出力します。

FullGCを実行します。

cjexecjobコマンドにバッチアプリケーションの終了コードを送信します。

次の表に，バッチアプリケーションの強制停止条件を示します。

表2‒5　バッチアプリケーションの強制停止の条件

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

バッチサーバの動作

cjexecjobコマンドの動作

バッチアプリケーション実行中にバッチ強制停止コマンドを実行した。

KDJE55004-I出力して，バッチアプリケーションの実行を強制停止を開始する。強制停止の完了時にはKDJE55005-Iを出力する。強制停止に失敗したときはKDJE55017-Eを出力する。

バッチ強制終了時の正常パス

戻り値：1

なお，JP1/Advanced Shellのadshjavaコマンドによってバッチアプリケーションを実行した場合は，JP1/Advancel Shellのジョブを強制終了することで，JP1/Advanced Shellが自動的にcjkilljobコマンドを実行してバッチアプリケーションを強制停止します。

(3)　バッチアプリケーションの強制停止実行時の注意事項

バッチアプリケーションの強制停止に失敗すると，バッチサーバが強制停止されます。複数のバッチアプリケーションを連続して実行する場合，バッチサーバの強制停止後に実行するバッチアプリケーションを開始する前に，バッチサーバを再起動する必要があります。このため，Management Serverを利用して，バッチサーバが自動的に再起動するように設定してください。詳細は，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.4　メソッドキャンセルとは」を参照してください。

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

実行中のバッチアプリケーションの状態や，バッチ実行コマンドの開始時刻などをバッチアプリケーション情報として一覧表示できます。ここでは，バッチアプリケーション情報の一覧表示について説明します。

(1)　バッチアプリケーション情報の一覧表示の方法

バッチアプリケーション情報の一覧を表示するには，JP1/AJSを使用しているかどうかに関係なく，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.xxx.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）

標準エラー出力に出力されます。

バッチアプリケーションを実行するためのコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「3.3　バッチアプリケーションで使用するコマンド」を参照してください。また，メッセージのレベルについては，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「7.1　メッセージの記述形式」を参照してください。

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

ここでは，バッチアプリケーションで使用するコマンドの実行について説明します。

バッチアプリケーションで使用するコマンドには次の3種類があります。

cjexecjobコマンド（バッチ実行コマンド）

バッチアプリケーションを実行するためのコマンドです。

cjkilljobコマンド（バッチ強制停止コマンド）

実行中のバッチアプリケーションを強制停止するためのコマンドです。

cjlistjobコマンド（バッチ一覧表示コマンド）

バッチアプリケーション情報を一覧表示するためのコマンドです。

これらのコマンドは，バッチサーバの状態によって実行できないことがあります。バッチサーバの状態とコマンドの実行について説明します。なお，コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「3.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　サーバ管理コマンドの種類によって動作が異なります。詳細については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「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)　バッチアプリケーションのファイル形式

バッチアプリケーションは，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)　新規にバッチアプリケーションを作成する場合

新規にバッチアプリケーションを作成する場合，リソースへの接続にはDB Connectorを使用することをお勧めします。DB Connectorとは，アプリケーションサーバで提供するデータベースに接続するためのリソースアダプタです。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の別名の付け方については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

また，DB Connectorの設定の流れについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「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種類があります。

Application Serverで提供するDB Connectorを使用したリソース接続に変更する。

JDBCドライバを使用してリソースに接続する（接続方法を変更しない）。

DB Connectorを使用しない場合，バッチアプリケーションのコードを修正する必要はありません。ただし，DB Connectorが提供する機能およびGC制御機能は利用できません。ここでは，リソースの接続方法を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の別名の付け方については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

また，DB Connectorの設定の流れについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「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（バッチサーバ用オプション定義ファイル）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2.1　usrconf.cfg（バッチサーバ用オプション定義ファイル）」を参照してください。

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

リソースに接続するバッチアプリケーションを作成するときには，次のことに注意してください。

(a)　バッチアプリケーション実行時の注意

バッチアプリケーション実行中には，DB Connectorの停止や設定変更をしないでください。DB Connectorの停止や設定変更は，バッチアプリケーションが終了してから実施します。

(b)　コネクションのクローズ

バッチサーバでは，コネクションの自動クローズは実行されません。このため，使用したコネクションは必ずクローズするよう，アプリケーションに実装してください。

(c)　JTAのローカルトランザクションの使用

バッチアプリケーションの中で，JTAのローカルトランザクションを使用できます。JTAのローカルトランザクションは，次に示す方法で使用します。

次のどちらかの方法でUserTransactionオブジェクトを取得します。

ネーミングサービスからルックアップして取得する。

ルックアップ名：HITACHI_EJB/SERVERS/<サーバ名称>/SERVICES/UserTransaction

com.hitachi.software.ejb.ejbclient.UserTransactionFactoryクラスのgetUserTransactionメソッドを使用して取得する。

UserTransactionオブジェクトのbegin()メソッドを呼び出して，トランザクションを開始します。

リソースに接続します。

UserTransactionオブジェクトのcommit()またはrollback()を呼び出して，トランザクションを決着します。

UserTransactionインタフェースの使用方法の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4.8　UserTransactionインタフェースを使用する場合の処理概要と留意点」を参照してください。

UserTransaction使用時の注意事項を次に示します。

UserTransactionはmainスレッドだけ使用できます。ユーザスレッドでは使用できません。

mainスレッドでトランザクションの開始および決着を実施してください。

スレッド生成時にトランザクションは引き継がれません。

スレッド間でコネクションやコネクションから得られたインスタンス（ステートメントなど）を渡せません。このインスタンスを使用した場合は動作が不正になります。

(d)　トランザクションの決着

バッチアプリケーション内でトランザクションを開始した場合は，バッチアプリケーション内で必ず決着処理を実施してください。トランザクションの決着処理を実施しないでバッチアプリケーションを終了すると，タイムアウト時間が経過したあとにトランザクションがロールバックされます。

この場合，簡易構築定義ファイルの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を次に示す名称でルックアップして使用できます。

自動的にバインドされる名称（Portable Global JNDI名またはHITACHI_EJBから始まる名称）

ユーザ指定名前空間機能を使用した別名

EJBにアクセスする場合，次に示す手順でバッチアプリケーションを準備します。

バッチアプリケーションからアクセスするEJBの準備

バッチアプリケーションからアクセスするEJBを含むJ2EEアプリケーションを開始状態にします。

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

バッチアプリケーション内に，EJBを使用するためのコードを実装します。

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

2.で作成したバッチアプリケーションを実行します。

それぞれの手順の詳細を次に説明します。

(1)　EJBの準備

バッチアプリケーションからアクセスするEJBを持つJ2EEアプリケーションを用意します。また，J2EEアプリケーションを実行するためのJ2EEサーバも用意します。J2EEサーバの構築については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1　Webサーバを別ホストに配置してマシン性能を向上するシステムの構築」を参照してください。

構築したJ2EEサーバ上で，J2EEアプリケーションを開始します。cjgetstubsjarコマンドを使用して，開始したJ2EEアプリケーションのRMI-IIOPスタブおよびインタフェースを取得しておきます。

なお，バッチアプリケーションからEJBにアクセスする場合，別名によるルックアップをするときは，事前にユーザ指定名前空間機能を使用してEJBの別名を設定しておいてください。EJBの別名の設定については，マニュアル「アプリケーションサーバ 機能解説基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

(2)　バッチアプリケーションの実装

「2.3.9(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)　バッチアプリケーションの実行

バッチアプリケーションを実行する場合，クラスパスに「2.3.9(1)　EJBの準備」で取得したスタブや「2.3.9(2)　バッチアプリケーションの実装」で使用したインタフェースファイルをフルパスで指定します。

EJBを検索するネーミングサービスのURLは，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）のjava.naming.provider.urlの値として指定します。

ただし，リソース接続機能とEJBアクセス機能を同時に使用する場合は，ネーミングサービス切り替え機能を使用して，EJBをルックアップするネーミングサービスを指定してください。この場合，usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）のjava.naming.provider.urlは指定しないでください。ネーミングサービス切り替え機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.10　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

このパラメタはJDK11を使用する場合だけ指定できます。

バッチアプリケーションで明示管理ヒープ機能を実装していない場合は，明示管理ヒープ機能を無効にすることをお勧めします。明示管理ヒープ機能を無効にするには，パラメタの値に-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

任意

（凡例）必須：必ず指定する　任意：必要に応じて指定する

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

注※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)　注意が必要な処理

次に示す処理は，バッチアプリケーションを作成する際に注意が必要です。

(a)　ファイルやディレクトリの操作

バッチアプリケーションでは，次に示すファイルやディレクトリは操作しないでください。

Application Serverのインストールディレクトリ以下のファイルやディレクトリ

Application Serverのインストールディレクトリ以下のファイルやディレクトリについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録B　インストール後のディレクトリ構成」を参照してください。

バッチサーバの作業ディレクトリ以下のファイルやディレクトリ

バッチサーバの作業ディレクトリについては，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録C.2　バッチサーバの作業ディレクトリ」を参照してください。

また，バッチアプリケーションでファイルやディレクトリを扱う場合，ファイルやディレクトリのパスに相対パスを使用できません。cjexecjobコマンドを実行したディレクトリからの相対パスを取得したい場合は，ejbserver.batch.currentdirの値を使用してください。ejbserver.batch.currentdirについては，マニュアル「アプリケーションサーバリファレンス 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");

(b)　スレッドの使用

バッチサーバは，バッチアプリケーションが作成および開始したスレッドの終了を待ちません。バッチアプリケーション内でスレッドを使用する場合は，バッチアプリケーションを終了する前に，開始したすべてのユーザスレッドを完了するように実装してください。また，ユーザスレッドはメソッドキャンセルの対象外です。

なお，簡易構築定義ファイルでejbserver.batch.application.exit.enabledパラメタで「true」を指定した場合には，次の点に注意してください。

スレッドグループ（ThreadGroup）を作成できません。

バッチアプリケーションにjava.lang.ThreadクラスのインタフェースであるUncaughtExceptionHandlerを継承したハンドラを登録していると，JavaVM終了メソッド呼び出し時に登録したハンドラの処理が実行されます。このとき，uncaughtExceptionメソッドの引数にJP.co.Hitachi.soft.jvm.SpecialThrowableの例外が渡されることがあります。

バッチアプリケーションが作成したスレッドが残っていると，バッチアプリケーションのクラスや使用したリソースは解放されません。このため，次にバッチアプリケーションを開始しようとすると，バッチアプリケーションの開始に失敗するおそれがあります。また，ユーザスレッド内では，次のバッチサーバの機能を呼び出すことはできません。

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

EJBアクセス機能

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

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

GC制御機能

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

(c)　JavaVM終了時のリソースの自動クローズ

バッチサーバではサーバのJavaVM上でバッチアプリケーションを実行します。このため，JavaVM終了による自動的なリソースのクローズ処理を期待した実装をしている場合は，メモリやファイルディスクリプタのリークが発生します。例えば，次の場合にリークが発生します。

ZIPファイルまたはJARファイルをオープンしている場合，明示的にクローズしないとCヒープ領域がリークします。

バッチサーバのusrconf.propertiesにejbserver.batch.application.exit.enabled=falseを指定した場合，java.io.File.deleteOnExit()を使用しても，バッチサーバが停止するまでファイルは削除されません。バッチサーバが停止するまでCヒープ領域がリークします。

この問題を回避するためには，リソースが正しくクローズされるようにバッチアプリケーションを実装してください。

また，ファイルやソケットなども明示的にクローズしていないと，リソース解放のタイミングが不定になります。これによって，次回以降のバッチアプリケーションの実行に影響を及ぼすおそれがあります。ファイルやソケットは明示的にクローズするようにしてください。

なお，バッチサーバの場合，コネクションの自動クローズは使用できません。バッチアプリケーション内で必ずコネクションをクローズしてください。

(d)　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終了メソッドを使用する場合の注意事項については，「2.3.11(3)　JavaVM終了メソッド使用時の注意」を参照してください。

(e)　シャットダウンフックの使用

簡易構築定義ファイルで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終了メソッドを使用するときの注意事項について説明します。

(a)　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が終了します。

(b)　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アクセスで使用できる機能

EJBアクセスで使用できる機能について，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2‒13　EJBアクセスで使用できる機能

分類

機能

説明

参照先マニュアル※

参照個所

JNDI

基本機能

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

自動的にバインドされる名称（Portable Global JNDI名またはHITACHI_EJBから始まる名称），またはユーザ指定名前空間を利用して，EJBホームオブジェクトおよびビジネスインタフェースのリファレンスをネーミングサービスからルックアップできます。

基本・開発編(コンテナ共通機能)

2.3

拡張機能

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

複数のネーミングサービスとJ2EEサーバで構成されるシステムに対して，バッチアプリケーションからのルックアップをラウンドロビンで実行できます。これによって，負荷分散を実現できます。

2.7

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

ネーミングサービスからルックアップしたオブジェクトをメモリ上に保持（キャッシュ）できます。キャッシュの利用によって，ネーミングサービスへのアクセスの性能上のコストを削減できます。

2.8

EJB

Enterprise Beanの実行

EJBコンテナで実行されているEnterprise Beanをバッチアプリケーションから呼び出せます。ただし，呼び出し方法はリモート呼び出しだけ使用できます。ローカル呼び出しはできません。

基本・開発編(EJBコンテナ)

2.2

Enterprise Beanの呼び出し

3.4

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

バッチアプリケーションから，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

性能解析トレースを使用したシステムの性能解析

バッチアプリケーションの性能解析トレースを出力できます。

保守／移行編

7章

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

バッチアプリケーションのログを出力できます。

このマニュアル

8章

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

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アドレスまたはホスト名を固定するかどうかを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

2.5　ネーミング管理機能

ネーミング管理は，J2EEサービスで提供されている機能の一つです。J2EEサービスは，J2EEコンテナの部品機能として利用される機能です。ネーミング管理では，オブジェクト（Enterprise Beanに対応するEJBホームオブジェクト，ビジネスインタフェースのリファレンスおよびJ2EEリソース）の名前と格納場所を管理しています。ネーミング管理の機能を使用することで，バッチアプリケーションは，呼び出すEnterprise Beanまたはリソースの格納場所を知らなくても，名前から必要なオブジェクトを利用できるようになります。この節では，バッチサーバで使用できるネーミング管理機能および設定方法について説明します。

この節の構成を次の表に示します。

表2‒15　この節の構成（ネーミング管理機能）

分類

タイトル

参照先

解説

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

2.5.1

設定

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

2.5.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

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

バッチサーバで使用できるネーミング管理機能を次の表に示します。ネーミング管理機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.　ネーミング管理」を参照してください。

表2‒16　ネーミング管理機能

機能

説明

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

オブジェクトをJNDI名前空間の名前とバインドして管理します。バッチアプリケーションからは，バインドされた名前を使用してルックアップできます。バッチアプリケーションの場合，java:comp/envでのルックアップは使用できません。

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

J2EEリソースに別名を付与できます。バッチアプリケーションからは，別名として設定した任意の名称でルックアップできます。なお，バッチアプリケーションからデータベースに接続する場合，J2EEリソースには必ず別名を設定してください。

J2EEリソースについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6　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

ネーミングサービスとの通信タイムアウト時間を指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

注※1　デフォルトの設定では，バッチサーバは，ホスト名「localhost」，ポート番号「900」のCORBAネーミングサービスをインプロセスで自動起動して使用します。

注※2　ラウンドロビン検索は，ユーザ指定名前空間機能を使用していることが前提になります。ユーザ指定名前空間機能を使用する場合，サーバ管理コマンドの動作設定のカスタマイズが必要です。設定方法については，マニュアル「アプリケーションサーバ 機能解説基本・開発編(コンテナ共通機能)」の「2.6.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　接続できるデータベース

バッチサーバからは次のデータベースに接続できます。ただし，バッチサーバではグローバルトランザクションは使用できません。

HiRDB

Oracle

SQL Server※

XDM/RD E2

注※　

SQL Serverと接続できるのはWindowsの場合だけです。

これらのデータベースを利用するためにはリソースアダプタを使用します。リソースアダプタを利用するには，サーバ管理コマンドを使用して，リソースアダプタのプロパティ設定やインポートなどの作業が必要です。リソースアダプタの設定については，「2.7.7(2)　リソースアダプタの設定」を参照してください。

なお，リソースの設定をする前に，リソースの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。リソース設定時の注意事項や，サーバ管理コマンドを使用するための動作設定については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「3.3　サーバ管理コマンドの動作設定のカスタマイズ」を参照してください。

また，次に示すデータベースとの接続に関する説明については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「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

ローカルトランザクション

○

×

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

×

×

GC制御機能

○

×

（凡例）○：使用できる　×：使用できない

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

DB Connectorを使用してデータベースに接続する場合，使用するJDBCドライバに応じたRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「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ファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

SQL ServerのJDBCドライバ

DBConnector_SQLServer_CP.rar

SQL Server（Windowsの場合だけ）への接続に使用するRARファイルです。トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

注　新規に，DB ConnectorのRARファイルを使用する場合，アプリケーションサーバで提供するConnector属性ファイルのテンプレートファイルを使用して，プロパティを定義できます。Connector属性ファイルのテンプレートファイルは，すべてのDB ConnectorのRARファイルに対して提供しています。提供しているテンプレートファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.13　Connector属性ファイルのテンプレートファイル」を参照してください。

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

リソースアダプタを使用してリソースと接続する場合，リソースアダプタをJ2EEリソースアダプタとしてデプロイしてください。J2EEリソースアダプタとは，J2EEサーバ上に配置されたリソースアダプタです。デプロイ方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.3.7　リソースアダプタの設定方法」を参照してください。

(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

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

J2EEリソースへの別名付与※2

J2EEリソースに別名を付与できます。バッチアプリケーションからは，別名として設定した任意の名称でルックアップできます。

2.6

性能解析トレースを使用したシステムの性能解析

コネクションIDのPRFトレース

各機能が出力する性能解析情報を収集します。この情報を基に，システム性能およびボトルネックを分析できます。

保守／移行編

8章

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

注※2　バッチサーバの場合，リソースアダプタの別名は必ず使用します。

リソースアダプタの種類ごとに使用できる機能を次の表に示します。

表2‒22　リソースアダプタの種類ごとに使用できる機能

機能

項目

リソースアダプタの種類

DB Connector

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

コネクションプーリング

○

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

○

コネクション数調節機能

○

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

○

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

○

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

○

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

○

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

コネクション障害検知

○

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

○

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

○

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

○

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

○

ステートメントキャンセル

○

障害調査用SQLの出力

◎

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

○

リソースへの接続テスト

リソースへの接続テスト

○

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

J2EEリソースへの別名付与※

○

性能解析トレースを使用したシステムの性能解析

コネクションIDのPRFトレース

○

（凡例）

◎：必ず有効になる

○：使用できる

注※　バッチアプリケーションの場合，コネクションアソシエーションは使用できません。

(2)　リソースアダプタ以外の機能

ここでは，リソースアダプタ以外で実現される機能について説明します。ここで説明する機能は，リソースアダプタの種類に関係なく使用できます。

リソースアダプタ以外で実現される機能を，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2‒23　リソースアダプタ以外の機能

機能

項目

説明

参照先マニュアル※

参照個所

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

ライトトランザクション

ローカルトランザクションに最適化された環境を提供します。ライトトランザクション機能は必ず有効にします。

基本・開発編(コンテナ共通機能)

3.14

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

トランザクションタイムアウト

トランザクション開始時間から一定時間経過した時点で呼び出し先のトランザクションをロールバックします。

基本・開発編(コンテナ共通機能)

3.15

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

注意事項

J2EEサーバのトランザクション管理の機能では，トランザクションを自動決着する機能がありますが，バッチサーバの場合，トランザクションの自動決着機能は使用できません。

(3)　リソースアダプタのオプショナル名についての注意事項

同じオプショナル名で複数のリソースアダプタをデプロイしている場合，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。

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

バッチアプリケーションからデータベースに接続するには，DB Connectorというリソースアダプタを使用します。ここでは，バッチサーバで使用するリソースアダプタの設定について説明します。バッチサーバの場合，リソースアダプタは，J2EEリソースアダプタとしてデプロイして使用します。

参考

リソースアダプタがDB Connectorの場合，アプリケーションサーバが提供するConnector属性ファイルのテンプレートファイルが使用できます。Connector属性ファイルのテンプレートファイルを使用すると，DB Connectorをインポートする前に，Connector属性ファイルを編集しておくことができます。このため，編集対象のConnector属性ファイルをサーバ管理コマンド（cjgetrarpropコマンドまたはcjgetrespropコマンド）で取得する操作が不要になります。Connector属性ファイルのテンプレートは，次の場所に格納されています。テンプレートファイルはコピーして使用してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥templates¥

UNIXの場合

/opt/Cosminexus/CC/admin/templates/

なお，Connector属性ファイルのテンプレートファイル，およびテンプレートファイル使用時の注意事項については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.13　Connector属性ファイルのテンプレートファイル」を参照してください。

注意事項

旧バージョンのアプリケーションサーバで使用していたリソースアダプタを使用する場合，リソースアダプタの移行処理が必要です。リソースの移行方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.8　リソースアダプタの移行」を参照してください。

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

リソースアダプタの設定には，サーバ管理コマンドを使用します。バッチサーバの場合，リソースアダプタは，J2EEリソースアダプタとしてデプロイして使用します。

バッチサーバで使用するリソースアダプタの新規設定の流れを次の図に示します。

図2‒12　バッチサーバで使用するリソースアダプタの新規設定の流れ

図中の1.〜4.について説明します。

サーバ管理コマンドを使用してリソースアダプタをインポートします。

cjimportresコマンドを使用して，リソースアダプタをインポートします。

インポートするリソースアダプタについては，「2.7.3　DB Connector（RARファイル）の種類」を参照してください。

サーバ管理コマンドを使用してリソースアダプタをデプロイします。

cjdeployrarコマンドを使用して，リソースアダプタをデプロイします。

リソースアダプタは，デプロイするとJ2EEリソースアダプタとして使用できます。J2EEリソースアダプタとは，バッチサーバに共有スタンドアロンモジュールとして配備したリソースアダプタのことです。サーバ管理コマンドでインポートしたリソースアダプタをデプロイすると，バッチサーバ上で使用できるようになります。

サーバ管理コマンドを使用してリソースアダプタのプロパティを定義します。

cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。

バッチサーバの場合，ユーザ指定名前空間機能を使用してリソースアダプタに別名を設定してください。ユーザ指定名前空間機能を使用した別名の設定は，リソースアダプタのプロパティで定義します。ユーザ指定名前空間機能の設定については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

リソースアダプタのプロパティ定義で設定できる内容については，「2.7.7(2)　リソースアダプタの設定」を参照してください。

サーバ管理コマンドを使用してリソースアダプタの接続テストを実施します。

cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。リソースごとの接続テストでの検証内容については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.17　リソースへの接続テスト」を参照してください。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，cjimportresコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjimportres（リソースのインポート）」を参照してください。cjdeployrarコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjdeployrar（リソースアダプタのデプロイ）」を参照してください。cjgetrarpropコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjgetrarprop（RARファイルの属性の取得）」を参照してください。cjtestresコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjtestres（リソースの接続テスト）」を参照してください。属性については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

なお，次の手順については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.8　リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）」を参照してください。その際，「J2EEサーバ」を「バッチサーバ」に，「J2EEアプリケーション」を「バッチアプリケーション」に置き換えてお読みください。

リソースアダプタの設定を変更する場合の流れ

リソースアダプタを入れ替える場合の流れ

参考

次のような場合，リソースアダプタをエクスポート・インポートすることで，効率良くリソースアダプタを設定できます。

開発環境で設定したリソースアダプタをエクスポートして，運用環境にインポートして使用する場合

運用環境ですでに動いているリソースアダプタをエクスポートして，増設したバッチサーバにインポートして使用する場合

エクスポートとインポートはcjexportrarとcjimportresで実行します。

なお，アプリケーションサーバのバージョンやプラットフォームが異なるホスト間では，リソースアダプタをエクスポート・インポートして使用することはできません。リソースアダプタをエクスポートするホストと，アプリケーションサーバのバージョンやプラットフォームが異なるホストでリソースアダプタを設定する場合は，リソースアダプタを新規に設定してください。

2.7.7　実行環境での設定

リソース接続機能を使用する場合，バッチサーバおよびリソースアダプタの設定が必要です。

ここでは，リソース接続機能を使用するための設定について説明します。

(1)　バッチサーバの設定

バッチサーバの設定は，簡易構築定義ファイルで実施します。バッチアプリケーション実行機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリソース接続機能の定義を次の表に示します。

表2‒24　簡易構築定義ファイルでのリソース接続機能の定義

項目

指定するパラメタ

設定内容

アプリケーションサーバが管理するトランザクションの外でのコネクションシェアリングの有効化

ejbserver.connectionpool.sharingOutsideTransactionScope.enabled

アプリケーションサーバが管理するトランザクションの外で複数回コネクションの取得を行ったときの，コネクションシェアリングの動作を指定します。

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

ejbserver.jndi.cache.reference

DataSourceオブジェクトのキャッシングを有効にするかどうかを指定します。

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

ejbserver.connectionpool.applicationAuthentication.disabled

コンテナ管理のサインオンの最適化機能を有効にするかどうかを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　リソースアダプタの設定

リソースに接続するバッチアプリケーションの場合，ユーザ指定名前空間機能を使用してリソースアダプタに別名を設定します。バッチアプリケーションからリソースアダプタをルックアップするには，ユーザ指定名前空間機能で設定した別名を使用します。ユーザ指定名前空間機能の設定については，「2.3.8　バッチアプリケーションの実装（リソースに接続する場合）」を参照してください。

参考

リソースの設定をする前に，リソースの設定に関する注意事項を理解しておいてください。また，サーバ管理コマンドを使用する場合には，必要に応じて，サーバ管理コマンドの動作設定をカスタマイズしてください。リソース設定時の注意事項や，サーバ管理コマンドを使用するための動作設定については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「3.3　サーバ管理コマンドの動作設定のカスタマイズ」を参照してください。

リソースアダプタの設定は，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属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

注※1　XDM/RD E2 11-01以前のバージョンの場合，ステートメントプーリング機能を利用できないため，これらのプロパティには0を指定してください。

注※2　同じキーで設定します。このため，コネクションの障害検知機能でタイムアウトを使用する場合は，コネクション数調節機能でもタイムアウトを使用する設定となります。なお，タイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキー（ejbserver.connectionpool.validation.timeout）に，任意の時間を指定してください（デフォルト値は5秒）。

なお，DB Connectorを使用してデータベースに接続する場合に設定する，DB Connectorのプロパティ定義については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.1.2　設定する項目と操作の概要」を参照してください。

2.8　トランザクション管理

この節では，リソース接続時のトランザクション管理について説明します。

この節の構成を次の表に示します。

表2‒26　この節の構成（トランザクション管理）

分類

タイトル

参照先

解説

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

2.8.1

設定

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

2.8.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

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

リソース接続時のトランザクションを管理する方法には，アプリケーションサーバで管理する方法と，アプリケーションサーバが管理しないでユーザが直接管理する方法があります。データベースへの接続では，アプリケーションサーバのトランザクションマネジャを使用してトランザクションを管理できます。トランザクション管理については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.4.1　リソース接続でのトランザクション管理の方法」を参照してください。

バッチサーバで使用できるトランザクションは，ローカルトランザクションです。グローバルトランザクションは使用できません。また，バッチサーバでは，必ずライトトランザクション機能を有効にしてください。ライトトランザクション機能とは，ローカルトランザクションに最適化された環境を提供する機能です。ローカルトランザクションおよびライトトランザクション機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.4.2　ローカルトランザクションとグローバルトランザクション」を参照してください。

また，EJB呼び出し時に，呼び出し先でシステム例外が発生したときの，呼び出し元，呼び出し先のトランザクションは，それぞれ次のように動作します。

呼び出し元のトランザクション

トランザクションはロールバックにマークされません。

呼び出し先のトランザクション

トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

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

トランザクション管理の機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。トランザクション管理の機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

ejbserver.jta.TransactionManager.defaultTimeOut

バッチサーバ上で開始されるトランザクションのタイムアウトのデフォルト値を指定します。

なお，トランザクションタイムアウトについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15　フォールトトレランスのための機能」を参照してください。簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

2.9　GC制御機能

バッチサーバでは，GC制御機能を使用できます。この節ではGC制御機能の概要，処理の流れおよび設定方法について説明します。

この節の構成を次の表に示します。

表2‒27　この節の構成（GC制御機能）

分類

タイトル

参照先

解説

GC制御機能の概要

2.9.1

GC制御の処理の流れ

2.9.2

設定

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

2.9.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

2.9.1　GC制御機能の概要

GCとは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。GCはJavaVMが実行します。

GCには処理時間が掛かります。また，GC実行中は，JavaVM上のすべてのプログラム処理が中断するため，GCを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

バッチサーバでは，バッチアプリケーションが長時間リソースを排他するのを回避するため，GC制御機能を提供しています。GC制御機能とは，リソースが排他されていないときに明示的にFullGCを実行するための機能です。GC制御機能の利用によって，リソースの排他中にFullGCが発生するのを回避できます。

GC制御機能について，例を使用して説明します。

GC制御機能を使用していない場合，バッチ処理と並行してオンライン処理を実行する環境では，次の図に示す問題があります。

図2‒13　GC制御機能を使用していない場合

この図では，バッチアプリケーションでのリソース排他中に，FullGCが発生しています。これによって，バッチアプリケーションはリソースを排他したまま処理が中断します。また，この間にオンライン処理から排他中のレコードが参照されると，オンライン処理もバッチサーバのFullGCが終了するまで中断します。

GC制御機能を使用すると次の図のようになります。

図2‒14　GC制御機能を使用している場合

図のように，FullGCの実行要求が出たときに，バッチアプリケーションでリソースを排他していると，FullGCの実行は待ち状態になります。

レコードの排他が解除されると，バッチサーバでFullGCが実行されます。また，オンライン処理もリソースへのアクセスができるようになります。これによって，バッチアプリケーションでの長時間のリソース排他を回避できます。

2.9.2　GC制御の処理の流れ

GC制御は次の流れで処理されます。

図2‒15　GC制御の処理の流れ

メモリ監視

監視タイマスレッドは，JavaVMのメモリを監視します。(1)に示す条件を満たすと，GC制御機能にGC実行要求が出されます。

リソース排他のチェック

GC実行要求が出されると，GC制御機能はリソース排他中かどうかを調査します。

FullGCの実行待ち

リソース排他中の場合，FullGCの実行は待ち状態になります。

FullGCの実行

リソースの排他が解除されると，FullGCが実行されます。

それぞれの処理について説明します。

(1)　メモリ監視

監視タイマスレッドはJavaVMのメモリを監視し，次のどれかの条件を満たす場合，GC制御機能にGCの実行要求を出します。

SerialGCが有効な場合

Tenured領域消費サイズ/Tenured領域合計サイズ×100≧GC制御のしきい値

New領域合計サイズ/Tenured領域最大空きサイズ×100≧GC制御のしきい値

Metaspace領域消費サイズ/Metaspace領域最大サイズ×100≧GC制御のしきい値

G1GCが有効な場合

Javaヒープ領域消費サイズ/Javaヒープ領域合計サイズ×100≧GC制御のしきい値

Metaspace領域消費サイズ/Metaspace領域最大サイズ×100≧GC制御のしきい値

ZGCが有効な場合

Metaspace領域消費サイズ/Metaspace領域最大サイズ×100≧GC制御のしきい値

(2)　リソース排他のチェック

GC実行が要求されると，GC制御機能は，バッチアプリケーションが使用しているコネクションを調査します。コネクションの調査では，バッチアプリケーションがリソース排他中かどうかを確認します。

次の表にリソースの排他中と見なす状態を示します。

表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のトランザクション処理だけがGC制御の対象となります。

(3)　FullGCの実行待ち

リソース排他中と判断されると，メッセージKDJE55024-Iを出力して，FullGCの実行待ち状態になります。リソース排他が一つでもあると，FullGCは待機し続けます。FullGC実行待ちの例を次の図に示します。

図2‒16　FullGC実行待ちの例

この図では，一つのジョブプログラム中で二つのリソースにアクセスしています。リソース排他中にFullGCの実行が要求されると，GC制御機能はFullGCの実行を待機状態にします。二つのリソースアクセスが終了するcon2.commit()が実行されると，排他が解除されます。

(4)　GCの実行

リソース排他がなくなると，FullGCが実行されます。

(5)　注意事項

同時に実行できるバッチアプリケーションは一つだけです。

一つのバッチアプリケーションから複数のリソースへの処理ができます。ただし，グローバルトランザクションは使用できません。

FullGCの実行待ち状態でも，空きメモリが不足すると，JavaVMによってFullGCが実行されることがあります。これは，GC実行時のメモリ使用量のしきい値が大きい場合や，リソースの排他区間が長い場合などに発生します。マニュアル「アプリケーションサーバシステム設計ガイド」の「9.4　GC制御で使用するしきい値を設定する」を参照して，メモリ使用量のしきい値をチューニングしてください。

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

GC制御機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。GC制御機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

ejbserver.batch.gc.watch.threshold

GCを実行する条件となるメモリ使用量のしきい値を指定します。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

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

バッチサーバでは，アプリケーション間で共通に利用したい処理がある場合に，ユーザ作成のライブラリを利用できます。ユーザ作成のライブラリを利用することで，アプリケーションの機能を拡張できます。この節では，コンテナ拡張ライブラリの概要および設定方法について説明します。

この節の構成を次の表に示します。

表2‒29　この節の構成（コンテナ拡張ライブラリ）

分類

タイトル

参照先

解説

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

2.10.1

設定

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

2.10.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

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

アプリケーションが共通に利用できるライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することで，アプリケーション間で共通して，ユーザ作成のライブラリを呼び出せるようになります。コンテナ拡張ライブラリに設定したライブラリはシステムクラスローダでローディングされます。詳細については，「2.3.1　バッチアプリケーション実行機能の概要」を参照してください。

バッチサーバではコンテナ拡張ライブラリを利用できますが，バッチアプリケーション自体をコンテナ拡張ライブラリに設定して使用することはできません。

また，サーバ起動・停止フック機能を利用することで，サーバの起動，終了時にコンテナ拡張ライブラリが呼び出されるようにできます。また，コンテナ拡張ライブラリで使用するJNI機能の初期化などを行うことができます。

コンテナ拡張ライブラリを使用するためには，ライブラリを一つのJARファイルにまとめ，コンテナ拡張ライブラリを使用するための設定をusrconf.cfgで定義します。また，コンテナ拡張ライブラリがJNIを利用する場合は，サーバ起動・停止フック機能を使用するための設定も必要です。

なお，コンテナ拡張ライブラリの利用の概要については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.2　コンテナ拡張ライブラリの利用」を参照してください。サーバ起動・停止フック機能の実装方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.4.2　サーバ起動・停止フック機能の実装方法」を参照してください。

注意事項

コンテナ拡張ライブラリには，次のアクセス権が付与されます。アクセス権は変更できません。

java.security.AllPermission

ただし，java.lang.RuntimePermissionのsetSecurityManagerアクセス権は付与されません。

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

コンテナ拡張ライブラリの機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。コンテナ拡張ライブラリの機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。指定するパラメタを次に示します。

add.class.path

コンテナ拡張ライブラリのJARファイルのパスを指定します。

add.library.path

JNI用ライブラリの検索パスを指定します。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

コンテナ拡張ライブラリの機能を使用するための設定方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.3.3　コンテナ拡張ライブラリの機能を使用するための設定」を参照してください。

2.11　JavaVMの機能

この節では，JavaVMの機能について説明します。

この節の構成を次の表に示します。

表2‒30　この節の構成（JavaVMの機能）

分類

タイトル

参照先

解説

JavaVMの機能の概要

2.11.1

設定

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

2.11.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

2.11.1　JavaVMの機能の概要

アプリケーションサーバで動作するバッチサーバのプロセスは，JavaVM上で実行されます。

JavaVMは，構成ソフトウェアであるDeveloper's Kit for Javaによって提供される，独自のJavaVMです。JavaVMの機能を次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

表2‒31　JavaVMの機能

機能

説明

参照先マニュアル※

参照個所

明示管理ヒープ機能

FullGC発生の要因になるJavaオブジェクトをExplicitヒープ領域に配置できます。アプリケーションで使用するJavaオブジェクトによる，FullGCの発生を抑止できます。

このマニュアル

7章

クラス別統計機能

各クラスのインスタンスが持つメンバの配下にあるすべてインスタンスのサイズを，クラス別統計情報として拡張スレッドダンプに出力できます。クラス別統計情報を複数回出力すると，GCによるJavaオブジェクトの変化や，寿命が短いJavaオブジェクトの状態などを調査できます。クラス別統計情報を出力する機能としては，インスタンス統計機能，STATICメンバ統計機能，参照関係情報出力機能，統計前のGC選択機能，Tenured領域内不要オブジェクト統計機能，およびTenured増加要因の基点オブジェクトリスト出力機能があります。

保守／移行編

9.3

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

拡張スレッドダンプに出力したクラス別統計情報を基に，クラスごとのインスタンスの合計サイズ，およびクラスごとのインスタンス数を2種類のCSVファイルとして出力できます。

9.10

Survivor領域の年齢分布情報出力機能

CopyGC実行時に，JavaVMログファイルにSurvivor領域のJavaオブジェクトの年齢分布を出力できます。Survivor領域の使用状況が調査でき，メモリサイズのチューニングに使用できます。

9.11

hndlwrap機能

ログオフ時のJavaVMのログオフイベントの発生を抑止できます。

9.12

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

また，JavaVMでは，障害発生時の要因分析やシステムの状態確認に利用できるよう，ログの出力内容が拡張されています。このログは，JavaVMログファイルに出力され，標準のJavaVMよりも，多くのトラブルシュート情報が取得できます。さらに，このログ（拡張verbosegc情報）を利用して適切なチューニングを実施することで，システムの可用性向上が図れます。JavaVMログファイルについては，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「4.10　JavaVMログ（JavaVMログファイル）」を参照してください。JavaVMのチューニングについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

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

JavaVMの機能を使用する場合，バッチサーバの設定が必要です。

バッチサーバの設定は，簡易構築定義ファイルで実施します。JavaVMの機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのJavaVMの機能の定義を次の表に示します。

表2‒32　簡易構築定義ファイルでのJavaVMの機能の定義

項目

指定するパラメタ

設定内容

パラメタ名

パラメタ値

明示管理ヒープ機能の利用

add.jvm.arg

-XX:+HitachiUseExplicitMemory

バッチアプリケーションで明示管理ヒープ機能を実装している場合に，明示管理ヒープ機能の使用を指定します。

明示管理ヒープ機能使用時に設定できるJavaVMオプションについては，「7.13.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」を参照してください。

Suvivor領域の年齢分布情報の出力

add.jvm.arg

-XX:+HitachiVerboseGCPrintTenuringDistribution

CopyGC発生時に，Suvivor領域のオブジェクトの年齢分布情報をJavaVMログファイルに出力することを指定します。

JavaVMのログの取得（JavaVMログファイル）

add.jvm.arg

-XX:+HitachiOutOfMemoryStackTrace※

例外情報とスタックトレースをJavaVMログファイルに出力することを指定します。

-XX:+HitachiVerboseGC※

GCが発生した場合に，拡張verbosegc情報をJavaVMログファイルに出力することを指定します。

-XX:+HitachiJavaClassLibTrace※

クラスライブラリのスタックトレースをJavaVMログファイルに出力することを指定します。

注　簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

注※　どれか一つでも指定すると，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アプリケーションからの移行）

ここでは，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（バッチアプリケーション用ユーザプロパティファイル）でサポートされているプロパティについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2.6　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（バッチアプリケーション用ユーザプロパティファイル）でサポートされているプロパティについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2.6　usrconf.properties（バッチアプリケーション用ユーザプロパティファイル）」を参照してください。

2.13　JP1/AJSとの連携

バッチアプリケーションを実行するシステムは，JP1/AJSと連携して運用できます。また，JP1/AJSに加えて，BJEXまたはJP1/Advanced Shellを使用して運用することもできます。この節では，JP1/AJS，BJEX，およびJP1/Advanced Shellと連携する場合の設定について説明します。

この節の構成を次の表に示します。

表2‒34　この節の構成（JP1/AJSとの連携）

分類

タイトル

参照先

設定

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

2.13.1

JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するための設定

2.13.2

注　「解説」，「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

参考

JP1/AJSと連携するシステム，ならびにJP1/AJSとBJEX，およびJP1/Advanced Shellと連携するシステムの概要については，「2.2.1　バッチアプリケーションを実行するシステム」および「2.2.2　バッチサーバおよびバッチアプリケーションの操作の流れ」を参照してください。

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

ここでは，JP1/AJSと連携する場合の，JP1/AJSのジョブの定義について説明します。

なお，JP1/AJSからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

(1)　バッチアプリケーションの開始

JP1/AJSと連携する場合，cjexecjobコマンドをJP1/AJSのUNIXジョブまたはPCジョブとして定義しておきます。JP1/AJSジョブの属性を定義する画面の「スクリプトファイル名」「パラメーター」および「実行時のユーザー」の項目には，次に示す内容を設定してください。

スクリプトファイル名

cjexecjobコマンドを指定します。cjexecjobコマンドのパスについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjexecjob（バッチアプリケーションの実行）」を参照してください。

パラメーター

実行するバッチアプリケーションのクラス名と引数を指定します。

実行時のユーザー

バッチサーバを実行するユーザを指定します。

なお，JP1/AJSでの設定の詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」を参照してください。

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

JP1/AJSと連携する場合，ジョブネットまたはジョブの強制終了をする際に，cjkilljobコマンドをJP1/AJSのリカバリージョブとして定義しておきます。ただし，ルートジョブネットを強制停止する場合は，リカバリージョブは実行されません。このため，バッチアプリケーションがバッチサーバ上で実行されたままになります。その場合は，cjkilljobコマンドを直接実行して，バッチアプリケーションを強制停止してください。

JP1/AJSでの設定の詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」を参照してください。

2.13.2　JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するための設定

ここでは，JP1/AJS，BJEX，およびJP1/Advanced Shellと連携する場合の，JP1/AJS，BJEX，およびJP1/Advanced Shellのジョブの定義について説明します。

なお，BJEXまたはJP1/Advanced ShellのバッチジョブアプリケーションをJP1/AJSから実行する際には，あらかじめバッチサーバを起動しておいてください。

(1)　バッチアプリケーションの開始

JP1/AJS，BJEX，およびJP1/Advanced Shellと連携する場合，JP1/AJS，BJEX，およびJP1/Advanced Shellにはそれぞれ次の内容を設定してください。

BJEXと連携する場合の設定

BJEXのバッチジョブにcjexecjobコマンドの実行を定義します。このとき，cjexecjobコマンドを，バッチジョブのジョブステップとして定義してください。

また，BJEXのジョブ定義XMLには次の内容を定義します。

EXEC要素

cjexecjobコマンドを実行するための定義をします。

PGM属性

cjexecjobコマンドを定義します。

PARM属性

cjexecjobコマンドの引数を定義します。ただし，引数の長さの上限は，BJEXの仕様に準拠します。

BJEXでの設定の詳細については，マニュアル「Batch Job Execution Server 使用の手引」を参照してください。

JP1/Advanced Shellと連携する場合の設定

JP1/Advanced Shellではadshjavaコマンドを使用します。adshjavaコマンドをJP1/Advanced Shellのジョブ定義スクリプト上で実行することで，adshjavaコマンドの処理の中でcjexecjobコマンドが呼び出され，バッチアプリケーションが実行されます。adshjavaコマンドには，バッチアプリケーションのクラス名に加えてバッチサーバ名称やスケジュールグループ名称を指定できるので，特定のバッチサーバ上でバッチアプリケーションを実行できます。

adshjavaコマンドの詳細については，マニュアル「JP1/Advanced Shell」を参照してください。

JP1/AJSの設定

BJEXまたはJP1/Advanced Shellのバッチジョブの実行コマンドをジョブとして定義します。

JP1/AJSでの設定の詳細については，マニュアル「JP1/Automatic Job Management System 操作ガイド」を参照してください。

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

BJEXまたはJP1/Advanced Shellと連携する場合は，BJEXまたはJP1/Advanced Shellのバッチジョブの実行コマンドを強制停止するだけで，実行中のバッチアプリケーションも自動的に強制停止されます。そのため，リカバリージョブを定義する必要はありません。

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

この章では，リクエストのスケジューリングと負荷分散について説明します。

業務システムには，局所的な障害発生時にシステムを止めることなく安定稼働できる信頼性と，随時変わっていく業務の処理要求に柔軟に対応できる可用性が求められます。アプリケーションサーバでは，これらの要求に対して，OLTP技術を用いたリクエストのスケジューリングや，サーバのクラスタリングによる負荷分散などによって対応します。

なお，この章で説明する機能は，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できる機能です。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2.1　製品と構成ソフトウェアの対応」を参照してください。

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の稼働統計情報の収集については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「10.　CTMの稼働統計情報の収集」を参照してください。

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

この節では，CTMを使用したリクエストのスケジューリングの概要について説明します。

アプリケーションサーバでは，リクエストのスケジューリングに，CTM（Component Transaction Monitor）という構成ソフトウェアを使用します。CTMは，それぞれのリクエストをキューを使用して制御します。このキューを，スケジュールキューといいます。

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通信を使用しないため，対象になりません）。

EJB3.0以降のEnterprise Beanに対する呼び出し。

なお，同一の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サーバの起動処理

CTMを使用するようにカスタマイズされているJ2EEアプリケーションを開始するためには，J2EEサーバの起動時に，CTMデーモンとのコネクションを確立して初期化処理を実行する必要があります。コネクションの確立と初期化は，次の操作によって実行されます。

CTMを使用するための設定をします。

CTMデーモンを起動します。

J2EEサーバを起動します。

J2EEサーバが起動する時に，J2EEサーバによってCTMデーモンとのコネクション確立と初期化処理が実行されます。J2EEサーバの起動前に必ずCTMデーモンを起動してください。

CTMデーモンを使用するための設定については，「3.4.2　実行環境での設定」を参照してください。CTMデーモンおよびJ2EEサーバの起動については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.24　システムを起動する（CUI利用時）」を参照してください。Smart Composer機能を使用してシステムを起動すると，CTMデーモン，J2EEサーバの順序で起動処理が実行されます。

なお，J2EEサーバの起動時にCTMデーモンとのコネクション確立と初期化に失敗した場合は，J2EEサーバの起動が失敗します。この場合は，失敗した要因に対処してから，J2EEサーバを再起動してください。

(2)　J2EEアプリケーションの開始処理

J2EEアプリケーションを開始すると，J2EEサーバからCTMデーモンに対して，指定されたキュー名称でスケジュールキューを活性化する要求が発行されます。CTMデーモンでは，キューを活性化してから，CTMデーモンの処理対象になる業務処理プログラムのcreateを，J2EEサーバに対して実行します。createは，CTMデーモンから直接呼び出される業務処理プログラムごとに，同時実行スレッド数（Parallel Count）分実行されます。

業務処理プログラムに対応する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)　スケジュールキューの作成単位

クライアントからのリクエストは，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）を付与する必要があります。ユーザ指定名前空間機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「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のプロセス構成と配置

CTMを使用する場合のプロセスの配置例を次の図に示します。

図3‒4　CTMを構成するプロセスの配置例

各プロセスの主な機能について，次の表で説明します。

表3‒2　CTMで使用するプロセス

プロセス

説明

CTMデーモン

クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。

CTMレギュレータ

CTMデーモンに集中するリクエストを，分散集約するためのプロセスです。

CTMドメインマネジャ

CTMドメインを管理するプロセスです。CTMドメインは，複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。

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

同じCTMドメイン内に含まれるホスト上の業務処理プログラムの情報を共有管理しているネーミングサービスです。

PRFデーモン

（パフォーマンストレーサ）

CTMデーモンが出力した性能解析情報をファイルに出力する，I／Oプロセスです。

詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.5　実行環境での設定」を参照してください。

スマートエージェント

TPBrokerで提供されている，動的な分散ディレクトリサービスです。CTMによってリクエストのスケジューリングをする場合，スマートエージェントが必要です。また，異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合などにも使用されます。

詳細は，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

3.3.2　プロセス配置の指針

プロセスを配置する場合の指針を示します。

CTMデーモンは，ホストに一つ配置します。

J2EEサーバまたはCTMレギュレータを配置するホストには，CTMデーモンが必要です。

一つのCTMデーモンで，複数のJ2EEサーバを制御できます。

一つのCTMデーモンに対して，複数のCTMレギュレータを配置できます。一つのCTMレギュレータに送信される同時リクエスト数が256を超えるような場合は，性能が劣化するおそれがあります。この場合は，CTMレギュレータの配置数を増やしてください。

EJBクライアントが動作するクライアントホストにCTMデーモンは必要ありません。

CTMデーモンを配置したホストに，CTMドメインマネジャを一つ配置します。複数のCTMデーモンを同じCTMドメインに参加させたい場合，各ホストのCTMドメインマネジャの名称には，同じ名称を指定します。

統合ネーミングスケジューラサーバにするホスト（J2EEサーバを配置しないホスト）にも，CTMデーモンを配置します。CTMレギュレータは不要です。なお，統合ネーミングスケジューラサーバについては，「(4)　独立した統合ネーミングスケジューラサーバを構築する構成（統合ネーミングスケジューラサーバモデル）」で説明します。

各プロセスの起動方法については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「2.　システムの起動と停止」を参照してください。

CTMで使用するプロセスの配置パターンについて説明します。

(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デーモンは，クライアントからのリクエストを処理してリクエストのスケジューリングを実現する，スケジューラの機能を持つプロセスです。

注意事項

Windowsのサービスから起動する場合は，開始コマンドのオプションに，「-Dvbroker.orb.isNTService=true」を指定してください。

クライアントから送信されたリクエストは，CTMレギュレータというプロセスを経由して，CTMデーモンが受信します。CTMレギュレータについては「3.3.4　CTMレギュレータ」を参照してください。

なお，CTMデーモンの機能を使用するための設定は，CTMデーモンを起動するときにctmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMであらかじめ設定しておくことができます。

CTMデーモンは，次の手順でリクエストを処理します。

リクエストの振り分け

スケジュールキューへのリクエストの登録

業務処理プログラムの呼び出し

処理結果の返却

それぞれの処理内容について説明します。

(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コマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「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ドメインマネジャによって管理されます。

ポイント

CTMドメインは，Management Serverが管理する運用管理ドメイン内に含まれます。

注意事項

CTMドメインを新しく増やすと，ファイルシステム中に情報が増えます。使用しなくなったCTMドメインに対するCTMドメイン情報は，ctmdminfoコマンドを使用して適宜削除してください。

CTMドメインマネジャは，同じCTMドメイン内のCTMデーモンの情報を管理するデーモンプロセスです。CTMデーモンを配置したホスト上に一つずつ配置します。

対象となるCTMドメインマネジャが同じネットワークセグメント内にあるか，異なるネットワークセグメントにあるかによって，CTMドメインマネジャによる情報の配布方法が異なります。

なお，CTMドメインマネジャの機能を使用するための設定は，CTMドメインマネジャを起動するときにctmdmstartコマンドの引数として指定します。また，運用管理ポータルで構築したシステムを運用している場合は，論理CTMドメインマネジャにあらかじめ設定しておくことができます。コマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「ctmdmstart（CTMドメインマネジャの開始）」を参照してください。運用管理ポータルについては，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.6.2　CTMドメインマネジャのネットワーク設定」を参照してください。

注意事項

Windowsのサービスから起動する場合は，開始コマンドのオプションに，「-Dvbroker.orb.isNTService=true」を指定してください。

WindowsでCTMデーモンが異常終了した場合，CTMドメインマネジャはCTMデーモンの子プロセスを強制停止します。

CTMドメインマネジャが異常終了した場合，CTMドメインマネジャの正常起動コマンド（ctmdmstartコマンド）に，-CTMForceStartオプション，または-CTMAutoForceオプションを指定してください。

(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ネーミングサービスに登録し直す必要があります。

リクエスト処理中に「CORBA::XXXX」という例外を標準出力，または標準エラー出力に表示することがあります。そのままの状態で動作し続ける場合には問題ありません。

3.4　リクエストの流量制御

流量制御では，J2EEサーバで一度に実行されるリクエスト処理数の最大値を制限することで，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現します。

この節の構成を次の表に示します。

表3‒3　この節の構成（リクエストの流量制御）

分類

タイトル

参照先

解説

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

3.4.1

設定

実行環境での設定

3.4.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

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

CTMを使用した流量制御について説明します。

流量制御は，J2EEサーバで一度に実行される処理数の最大値を設定して，リクエストの同時実行数を制限する機能です。これによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを実現します。CPUや排他資源の競合も抑止できます。

CTMによる流量制御は，CTMデーモンおよびCTMデーモンが管理しているスケジュールキューを使用して実現します。

CTMによる流量制御の概要を，次の図に示します。この図は，J2EEアプリケーション単位でスケジュールキューを共有している場合の例です。

図3‒14　CTMによる流量制御の概要

CTMデーモンでは，クライアントから受け付けたリクエストをスケジュールキューに登録して，スケジュールキュー単位に設定された同時実行スレッド数分ずつ実行します。クライアントからのリクエストが瞬間的に増加した場合でも，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コマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「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を使用するシステムの構成や構築手順については，マニュアル「アプリケーションサーバ システム設計ガイド」，およびマニュアル「アプリケーションサーバ システム構築・運用ガイド」を参照してください。

CTMの機能を使用して，リクエストをスケジューリングするための設定は，簡易構築定義ファイルでejbserver.ctmから始まるパラメタに，CTMデーモンのCTM識別子，CTMキューの長さなどを指定します。

CTMによるリクエストのスケジューリングをするためには，次の設定が必要です。

実行環境ディレクトリの作成と環境変数の設定

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

サーバ管理コマンドでの設定

(1)　実行環境ディレクトリの作成と環境変数の設定

Management Serverを使用しないでシステムを構築する場合，CTMを使用するためには，CTMとパフォーマンストレーサの実行環境ディレクトリを作成して，環境変数に指定する必要があります。

実行環境ディレクトリの作成および環境変数については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録H　システムの環境変数」を参照してください。

なお，Management Serverを使用してシステムを構築する場合は，CTMを使用するために必要な環境変数の設定はありません。

注意事項

AIXの場合は，環境変数の設定には次の点に注意してください。

Component Transaction Monitorの実行環境では，環境変数PSALLOCに「early」を設定してください。設定しない場合にメモリ不足が発生すると，正しい動作が保証できません。

AIXの早期ページングスペース割り当てを指定する，環境変数PSALLOCに「early」を指定しています。早期ページングスペース割り当てでは，ページングスペース見積もり上の考慮事項があります。詳細は，AIXのマニュアルの「システム・マネージメント・コンセプト：オペレーティング・システムおよびデバイス」を参照してください。

Component Transaction Monitorの実行環境では，環境変数NODISCLAIMに「true」を設定してください。環境変数PSALLOCに「early」を設定した場合，環境変数NODISCLAIMに「true」を設定しないと，レスポンス，スループットおよびCPU利用率が極端に低下することがあります。

Component Transaction Monitorで使用するユーザデータ領域と共用メモリ領域を拡張するため，環境変数LDR_CNTRLに「MAXDATA=0x40000000」を設定してください。割り当てるメモリの値を1ギガバイトにしてください。

Component Transaction Monitorの実行環境では，環境変数EXTSHMに「ON」を設定してください。設定しない場合，共有メモリが参照できなくなることがあります。

(2)　簡易構築定義ファイルでの設定

CTMを使用してリクエストをスケジューリングする場合には，簡易構築定義ファイルで論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタを設定してください。簡易構築定義ファイルについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

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)　サーバ管理コマンドでの設定

サーバ管理コマンドで設定できる内容を次に示します。サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「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コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「ctmchpara（スケジュールキューの同時実行数の変更）」を参照してください。

ポイント

ctmchparaコマンドで変更したスケジュールキュー単位の同時実行数は，CTMデーモンを停止するまで有効です。個別のJ2EEアプリケーションに設定したparallel countの値として保存はされません。一度CTMデーモンを再起動してJ2EEアプリケーションを再開始する場合には，個別のJ2EEアプリケーションに設定したparallel countの値が有効になります。

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

CTMによる同時実行スレッド数の動的変更の概要を，次の図に示します。

図3‒15　CTMによる同時実行数の動的変更の概要

図3-15について，(1)〜(3)で説明します。

(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コマンド，そのサブコマンド，および取得できる情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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のスケジュールキューの稼働状況の確認

CTMのスケジュールキューの稼働状況を確認するには，ctmlsqueコマンドの引数に「-CTMAppInfo」を指定して実行します。このコマンドを実行すると，スケジュールキューを共有しているJ2EEアプリケーションの情報を確認できます。実行形式と実行例を次に示します。

実行形式

ctmlsque -CTMDomain <CTMドメイン名称> -CTMID <CTM識別子> -CTMAppInfo

実行例

ctmlsque -CTMDomain domain01 -CTMID CTM01 -CTMAppInfo

ctmlsqueコマンドの詳細，および出力される情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「ctmlsque（スケジュールキュー情報の出力）」を参照してください。

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

CTMのスケジュールキューの同時実行数を変更するには，ctmchparaコマンドを実行します。実行形式と実行例を次に示します。

実行形式

ctmchpara -CTMDomain <CTMドメイン名称> -CTMID <CTM識別子> -CTMQueue <スケジュールキュー登録名称> -CTMChangeCount <同時実行数>

実行例

ctmchpara -CTMDomain domain01 -CTMID CTM01-CTMQueue que01 -CTMChangeCount 10

実行後，変更が反映されていることを確認してください。スケジュールキューの状態を確認する方法については，「(1)　CTMのスケジュールキューの稼働状況の確認」を参照してください。

ctmchparaコマンドの詳細，および出力される情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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　リクエストの閉塞制御の概要

CTMを使用してリクエストをスケジューリングしている場合，特定のスケジュールキューの閉塞制御ができます。スケジュールキューを閉塞制御することによって，特定のJ2EEアプリケーションをオンライン状態で入れ替えるサービス閉塞などができるようになります。

CTMによる閉塞制御でできることは，次のとおりです。

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

スケジュールキューにリクエストを保持した状態でJ2EEアプリケーションを入れ替えられます。

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

リクエストの完了を待ってから，J2EEアプリケーションを閉塞させます。

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

スケジュールキューをすぐに閉塞させます。キューに登録済みのリクエストを破棄するかどうかを選択できます。

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

J2EEサーバ異常終了時にスケジュールキューのリクエストを一定時間保持します。

リクエストの閉塞制御は，運用管理コマンド（mngsvrutil）で実行します。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

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

J2EEアプリケーションを入れ替える場合に，オンライン状態でJ2EEアプリケーションを入れ替えられます。

ここでは，入れ替えの概要と入れ替え手順について説明します。

(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アプリケーションの入れ替え方法については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「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コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「mngsvrutil（Management Serverの運用管理コマンド）」を参照してください。

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

J2EEアプリケーションを停止するときに，スケジュールキューに登録されたリクエストの処理が完了するのを待ってから，J2EEアプリケーションを停止できます。これによって，停止するJ2EEアプリケーションがそのキューを共有する最後のアプリケーションであった場合に，すでに受け付けられたリクエストをエラーにしないで処理できます。

ここでは，閉塞制御の概要と閉塞の手順について説明します。

(1)　閉塞制御の概要

キューを共有する最後のJ2EEアプリケーションが停止する場合，CTMデーモンは，スケジュールキューの入り口を閉じてサービスを停止して，それ以上リクエストを受け付けないようにします。そのあと，スケジュールキューに登録されていたリクエストの処理がすべて完了するのを待ってから，J2EEアプリケーションを停止します。

J2EEアプリケーションの閉塞制御の概要を次の図に示します。

図3‒17　J2EEアプリケーションの閉塞制御の概要

CTMの閉塞処理では，次の作業が実行されます。

新規リクエストの受け付けが終了されます。

スケジュールキューに格納されているリクエストのうち，すでにJ2EEサーバに振り分けられて処理中のリクエストは引き続き処理されます。

スケジュールキューに格納されているリクエストのうち，J2EEサーバへの振り分けがされていないリクエストに対しては，java.rmi.RemoteExceptionエラーが返却されます。

(2)　閉塞の手順

閉塞は，運用管理コマンドで実行します。

特定のホスト内のJ2EEアプリケーションを一括停止する場合の運用管理コマンドの実行形式と実行例を次に示します。なお，運用管理コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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)　スケジュールキューの閉塞制御の概要

スケジュールキューに対して，直接閉塞を実行することもできます。これによって，複数の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オプションも指定してください。

なお，閉塞の解除方法については，通常の閉塞をした場合と同じです。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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オプションで設定します。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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サーバへのリクエストの送信でタイムアウトが発生したときにキューを閉塞するかどうかを指定します。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

3.8　リクエストの負荷分散

負荷分散は，クラスタ構成などで並列に運用しているJ2EEサーバ間で，負荷が均等になるように処理を分散して割り当て，システム全体の可用性を高める機能です。クライアントからのcreateおよびinvokeの要求をサーバ間，プロセス間およびスレッド間で負荷分散できます。

この節の構成を次の表に示します。

表3‒7　この節の構成（リクエストの負荷分散）

分類

タイトル

参照先

解説

負荷分散のタイミング

3.8.1

負荷状況の監視

3.8.2

設定

実行環境での設定

3.8.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

負荷分散は，スケジュールキューを共有しているJ2EEアプリケーション間で実行できるほか，複数のCTMデーモン間で負荷情報を交換することで，異なるスケジュールキューで制御されているJ2EEアプリケーションに含まれる業務処理プログラムに対しても実行できます。

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コマンドについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「ctmstart（CTMデーモンの開始）」を参照してください。運用管理ポータルの設定の詳細については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「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

スケジュールキューの負荷状況を監視する時間間隔を指定します。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

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

この節の構成を次の表に示します。

表3‒9　この節の構成（リクエストのキューの滞留監視）

分類

タイトル

参照先

解説

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

3.9.1

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

3.9.2

設定

実行環境での設定

3.9.3

注意事項

注意事項

3.9.4

注　「実装」および「運用」について，この機能固有の説明はありません。

J2EEサーバで，CTMデーモンのスケジュールキュー取り出しが遅れると，リクエストがスケジュールキューの中で滞留することがあります。これを監視する機能として，スケジュールキュー監視機能があります。ここでは，スケジュールキュー監視機能について説明します。

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

スケジュールキューの滞留監視機能では，スケジュールキュー内に滞留しているリクエストの数を監視します。スケジュールキューにリクエストが滞留し，その数が一定の割合を超えると，メッセージを出力し，CTMデーモンは異常終了します。

スケジュールキュー監視は次のように動作します。

スケジュールキューの監視は，設定したキューの滞留率を超えた時点から開始します。

監視状態になると，指定した監視時間間隔でスケジュールキューを監視します。

監視のタイミングで，次に示すスケジュールキュー滞留監視式が成立すると，CTMデーモンが異常終了します。

スケジュールキュー滞留監視式

（P／Cn-1） ＜ （M1／100）

P：前回監視時点から現在までのリクエスト処理数

Cn-1：前回の監視時点でのキュー滞留数

M1：システム停止のしきい値（しきい値はシステムの処理率）

なお，スケジュールキュー監視は，ctmstartコマンドの-CTMWatchQueueオプションで設定します。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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パラメタに指定してください。

簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

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サーバの各機能が出力する性能解析情報とあわせて分析できます。性能解析トレース出力については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」の性能解析トレースに関する説明を参照してください。

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　バッチアプリケーションのスケジューリング

バッチアプリケーションのスケジューリング機能を使用すると，バッチアプリケーションの実行リクエストを制御できるようになります。これによって，バッチサーバの数を変更することなく，複数のバッチアプリケーションの実行リクエストを受け付けられるようになります。この章では，バッチアプリケーションのスケジューリングの概要，スケジューリング機能を使用したバッチアプリケーションの実行，スケジューリング機能を使用するための設定などについて説明します。

なお，スケジューリング機能は，構成ソフトウェアにComponent Transaction Monitorを含む製品だけで利用できる機能です。利用できる製品については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の「2.2.1　製品と構成ソフトウェアの対応」を参照してください。

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　バッチアプリケーションをスケジューリングする利点

ここでは，スケジューリング機能を使用する利点について説明します。

バッチサーバでは，同時に実行できるバッチアプリケーションの数は一つです。バッチアプリケーションを開始するには，アプリケーションサーバで提供しているバッチ実行コマンドを使用します。バッチサーバでは，バッチ実行コマンドによるバッチアプリケーションの実行リクエストを受けて，バッチアプリケーションを開始します。

スケジューリング機能を使用しない場合，バッチサーバの数を超えたバッチアプリケーションの実行リクエストは受け付けられません。この場合，受け付けられないリクエストはエラーとなります。また，バッチ実行コマンドにどのバッチサーバで実行するかを定義する必要があります。

スケジューリング機能を使用する場合，バッチサーバの数を超えたバッチアプリケーションの実行リクエストは，CTMによってスケジュールキューに滞留され，エラーになりません。滞留されたリクエストは，CTMによってバッチサーバに振り分けられます。このため，バッチサーバの数に関係なく，バッチ実行コマンドを実行できます。また，バッチアプリケーションの実行リクエストを実行するバッチサーバは，CTMによって振り分けられるため，バッチ実行コマンドにどのバッチサーバで実行するかを定義する必要がありません。

スケジューリング機能の使用の有無によるバッチアプリケーションの実行の流れを次の図に示します。

図4‒1　スケジューリング機能の使用の有無によるバッチアプリケーションの実行の流れ

この図は，バッチサーバが2台のシステムに対して，JP1/AJSのジョブまたは直接マシンからバッチ実行コマンドを同時に実行する例です。

スケジューリング機能を使用しない場合は，図中の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/AJSと連携できます。

スケジューリング機能を使用したバッチアプリケーション実行の流れを次の図に示します。

図4‒2　スケジューリング機能を使用したバッチアプリケーション実行の流れ

この図では，CTMによって，同じスケジュールグループに属するバッチサーバ1からバッチサーバ3に，バッチアプリケーションの実行リクエストを振り分けています。なお，スケジュールキューからあふれたバッチアプリケーションの実行リクエストはエラーになります。

複数のスケジュールグループを使用したバッチアプリケーション実行の流れを次の図に示します。

図4‒3　複数のスケジュールグループを使用したバッチアプリケーション実行の流れ

この図は，GroupAとGroupBの二つのスケジュールグループを指定した例で，スケジュールキューは二つ作成されます。使用するスケジュールグループは，コマンドで定義します。バッチアプリケーションは，コマンドのスケジュールグループの設定に従って，スケジュールキューに振り分けられます。なお，この図の場合，各スケジュールグループのバッチサーバでバッチアプリケーションを実行中のため，CTMに受け付けられたバッチアプリケーションは，スケジュールキュー内で待機しています。

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

この節では，スケジューリング機能を使用したシステムの構成と，必要なプロセスについて説明します。

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

ここでは，スケジューリング機能を使用したシステムの構成について説明します。

スケジューリング機能を使用したシステムの構成例を次の図に示します。

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

この図の場合，バッチアプリケーションを実行するシステムは，JP1/AJSと連携しています。JP1/AJSと連携しない場合は，図中の運用管理クライアント，JP1ジョブ運用管理サーバ，ならびにアプリケーションサーバのJP1/AJS - AgentおよびJP1/Baseは必要ありません。バッチサーバおよびバッチアプリケーションの操作の流れについては，「2.2.2(1)　JP1/AJSと連携するシステム」および「2.2.2(3)　JP1/AJS，BJEX，およびJP1/Advanced Shellと連携しないシステム」を参照してください。

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

ここでは，スケジューリング機能で必要なプロセスについて説明します。

スケジューリング機能を使用する場合，CTMを使用します。スケジューリング機能を使用するアプリケーションサーバのプロセス構成例を次の図に示します。

図4‒5　アプリケーションサーバのプロセス構成例（スケジューリング機能を使用する場合）

CTMで使用するプロセスの概要を次の表に示します。

表4‒2　CTMで使用するプロセスの概要（スケジューリング機能の場合）

プロセス

説明

CTMデーモン

バッチアプリケーションの実行リクエストを制御するスケジュールキューを管理するプロセスです。

CTMレギュレータ

CTMデーモンに集中するバッチアプリケーションの実行リクエストを，分散集約するためのプロセスです。

CTMドメインマネジャ

同じCTMドメイン内のCTMデーモンの情報を管理するプロセスです。

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

同じCTMドメイン内に含まれるホスト上のバッチアプリケーションの情報を共有管理しているネーミングサービスです。

スマートエージェント

TPBrokerで提供されている，動的な分散ディレクトリサービスを提供するプロセスです。異なるネットワークセグメントにあるCTMデーモンに情報を配布する場合に使用されます。詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

各プロセスを配置する指針，各プロセスについては，「3.　CTMによるリクエストのスケジューリングと負荷分散」を参照してください。

なお，PRFデーモン（パフォーマンストレーサ）は，CTMデーモンが出力した性能解析情報をファイルに出力するI／Oプロセスとして，CTMでも使用されます。詳細は，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.2.1　アプリケーションサーバの性能解析トレースの概要」を参照してください。

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

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

バッチアプリケーションの実行環境は，スケジューリング機能を使用する場合も，Smart Composer機能と，サーバ管理コマンドを使用して構築します。バッチアプリケーションの実行環境の運用手順や，使用できる運用機能は，スケジューリング機能を使用しない場合と同じです。

バッチアプリケーションの実行環境の構築手順については，「2.2.3(1)　バッチアプリケーションの実行環境の構築」を参照してください。ただし，スケジューリング機能を使用する場合は，バッチサーバの定義や構築に加えて，CTM，スマートエージェントなどの環境設定や構築が必要になります。CTM，スマートエージェントなどの構築にもSmart Composer機能を使用します。詳細は，マニュアル「アプリケーションサーバシステム構築・運用ガイド」の「4.6　バッチアプリケーションを実行するシステムの構築」を参照してください。バッチアプリケーションの実行環境でできる運用や，運用手順については，「2.2.3(2)　バッチアプリケーションの実行環境の運用」を参照してください。

また，スケジューリング機能を使用したシステムでも，JP1やクラスタソフトウェアと連携できます。詳細は，「2.2.3(3)　ほかのプログラムとの連携」を参照してください。

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

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

なお，バッチサーバで出力するバッチアプリケーションの実行ログは，スケジューリング機能を使用しない場合と同じです。バッチアプリケーションの実行ログについては，「2.3.5　バッチアプリケーションのログ出力」を参照してください。

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

ここでは，スケジューリング機能を使用したバッチアプリケーションの状態遷移について説明します。

バッチアプリケーションの状態遷移を次の図に示します。

図4‒6　バッチアプリケーションの状態遷移（スケジューリング機能を使用する場合）

バッチアプリケーションの各状態の説明を次の表に示します。

表4‒3　バッチアプリケーションの各状態の説明

バッチアプリケーションの状態

説明

WAITING

バッチサーバでほかのバッチアプリケーションが実行中のため，スケジュールキュー内で待機している状態です。

RUNNING

バッチアプリケーションがバッチサーバ上にある状態です。

FORCESTOPPING

バッチ強制停止コマンドによって，スケジュールキュー内のバッチアプリケーションが削除を予約された状態です。

バッチアプリケーションの状態は，バッチアプリケーション情報から確認できます。バッチアプリケーション情報の表示方法については，「4.5.4　バッチアプリケーション情報の一覧表示」を参照してください。

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

バッチアプリケーションを開始するには，cjexecjobコマンドを使用します。cjexecjobコマンドを実行するには，次の二つの方法があります。

cjexecjobコマンドを直接実行する方法

JP1/AJSを使用しない場合はこの方法で開始します。

cjexecjobコマンドをJP1/AJSのジョブとして定義しておき，JP1/AJSから実行する方法

JP1/AJSを使用する場合はこの方法で開始します。

2.の方法でバッチアプリケーションを開始するときのJP1/AJSのジョブの定義については，「2.13　JP1/AJSとの連携」を参照してください。なお，JP1/AJSからバッチアプリケーションを実行する際には，あらかじめバッチサーバを起動しておいてください。

バッチアプリケーションの開始処理，終了処理および実行時の注意事項については，スケジューリング機能を使用しない場合と同じです。詳細は，「2.3.2　バッチアプリケーションの実行」を参照してください。

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

バッチアプリケーションを強制停止するには，cjkilljobコマンドを使用します。スケジューリング機能を使用する場合，cjkilljobコマンドには，ジョブIDを指定します。

ジョブIDで指定されたバッチアプリケーションの実行リクエストがスケジュールキュー内で待機中の場合は，削除が予約されます。削除が予約されたバッチアプリケーションの実行リクエストは，CTMによってスケジュールキューから取り出された時に削除されます。

ジョブIDで指定されたバッチアプリケーションの実行リクエストがバッチサーバで実行中の場合は，強制停止されます。

バッチアプリケーションの強制停止方法，強制停止処理および実行時の注意事項については，スケジューリング機能を使用しない場合と同じです。詳細は，「2.3.3　バッチアプリケーションの強制停止」を参照してください。

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

実行中または待機中のバッチアプリケーションの状態や，バッチ実行コマンドの開始時刻などをバッチアプリケーション情報として一覧表示できます。ここでは，バッチアプリケーション情報の一覧表示について説明します。

(1)　バッチアプリケーション情報の一覧表示の方法

バッチアプリケーション情報の一覧を表示するには，JP1/AJSを使用しているかどうかに関係なく，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.xxx.mypackage.batchApp1 0x0000000000123456 2008/04/14 17:27:35.689012 2008/04/14 17:27:37.182777 HOGE MybatchServer1
JOBGROUP running com.xxx.mypackage.batchApp2 0x00000000002345678 2008/04/14 17:45:20.123456 2008/04/14 19:21:56.271354 102 MybatchServer2
JOBGROUP running com.xxx.mypackage.batchApp3 0x000000000034567890 2008/04/14 18:15:54.397890 2008/04/14 19:00:00.123447 #5HL390_G3CV7 MybatchServer3
JOBGROUP waitting com.xxx.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)　コマンド処理中にバッチサーバが異常終了した場合

バッチサーバで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」を指定している場合

メッセージKDJE55010-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（バッチサーバ用ユーザプロパティファイル）のファイルおよびキーについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「3.2.2　usrconf.properties（バッチサーバ用ユーザプロパティファイル）」を参照してください。

usrconf.cfg（バッチアプリケーション用オプション定義ファイル）のファイルおよびキーについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2.5　usrconf.cfg（バッチアプリケーション用オプション定義ファイル）」を参照してください。

注※　デフォルトではfalseが設定されていますが，CTMとの連携時には自動的にtrueが設定されます。

各ファイルで編集するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

4.7　実行環境での設定

スケジューリング機能を使用する場合，次の設定が必要です。

バッチサーバ

CTM

バッチアプリケーションで使用するコマンド

この節では，それぞれの設定項目について説明します。なお，スケジューリング機能を使用する場合は，バッチアプリケーション実行機能の定義も設定する必要があります。バッチアプリケーション実行機能の定義については，「2.3.10　実行環境での設定（バッチサーバの設定）」を参照してください。

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

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

4.7.2　CTMの設定

CTMの設定は，簡易構築定義ファイルで実施します。スケジューリング機能の定義は，簡易構築定義ファイルの論理CTM（componenttransaction-monitor）の<configuration>タグ内に指定します。指定するパラメタを次に示します。このパラメタは必ず指定してください。

ctm.Agent

スケジューリング機能を使用する場合には，CTMレギュレータのORBゲートウェイ機能を使用します。パラメタの値は必ず1を指定してください。

簡易構築定義ファイルおよびパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

4.7.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（バッチアプリケーション用オプション定義ファイル）およびキーについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「3.2.5　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　この章の構成

J2EEサーバ間のセッション情報を引き継ぐには，セッションフェイルオーバ機能を使用します。ここでは，セッションフェイルオーバ機能の概要およびセッションフェイルオーバ機能の種類について説明します。

この章の構成を次の表に示します。

表5‒1　この章の構成（セッションフェイルオーバ機能）

分類

タイトル

参照先

解説

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

5.2

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

5.3

前提条件

5.4

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

5.5

セッションフェイルオーバ機能使用時に設定できる機能

5.6

セッションフェイルオーバ機能使用時に実行される機能

5.7

メモリの見積もり

5.8

注意事項

注意事項

5.9

注　「実装」，「設定」，および「運用」について，この機能固有の説明はありません。

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

セッションフェイルオーバ機能とは，J2EEサーバやWebサーバでの，ソフトウェア障害，ハードウェア障害，およびネットワーク障害の発生時に，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトを引き継ぐ機能です。

セッションフェイルオーバ機能を使用すると，システム内の特定のJ2EEサーバに障害が発生した場合に，障害発生前のセッション情報を引き継いで，ほかのJ2EEサーバで業務を続行できます。これによって，システムの可用性を高めることができます。

ここでは，セッションフェイルオーバ機能を利用する利点と，セッションフェイルオーバ機能の種類について説明します。

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

HttpSessionオブジェクトは，J2EEサーバのメモリ上で保持されています。J2EEサーバで障害が発生すると，HttpSessionオブジェクトは失われます。複数のJ2EEサーバで構成されているシステムの場合に，一つのJ2EEサーバで障害が発生すると，リクエストはほかのJ2EEサーバに転送されます。しかし，HttpSessionオブジェクトが失われるため，HttpSessionオブジェクトに登録された情報（セッション情報）は引き継がれません。このため，リクエストが転送されたJ2EEサーバ上のJ2EEアプリケーションでは，新規のセッションとして扱うことになります。例えば，ユーザ認証処理後の画面で障害が発生すると，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報を管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡せます。このため，J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

また，統合ユーザ管理を使用している場合でも，セッションフェイルオーバ機能を使用してログイン状態を別のJ2EEサーバに引き継げます。

セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れを次の図に示します。

図5‒1　セッションフェイルオーバ機能を使用しない場合と使用した場合の処理の流れ

セッションフェイルオーバ機能を使用していないときにサーバに障害が発生すると，セッション情報が失われるため，再ログインが必要になります。

セッションフェイルオーバ機能を使用すると，セッション情報がサーバ間で引き継がれるため，ブラウザでのユーザの操作では，サーバの障害発生に気づくことなく，処理を続行できます。

5.2.2　セッションフェイルオーバ機能の種類

セッションフェイルオーバ機能の種類にはセッション情報の格納先によって次の種類があります。

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

セッション情報をデータベースに格納して管理します。

データベースセッションフェイルオーバ機能の概要については，「5.5.1　データベースセッションフェイルオーバ機能の概要」を参照してください。

適用手順，処理の流れや設定については，「6.　データベースセッションフェイルオーバ機能」を参照してください。

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

ここでは，セッションフェイルオーバ機能で管理するグローバルセッション情報について説明します。また，グローバルセッション情報として引き継げるHTTPセッションの属性に関する条件や注意事項についても説明します。

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

セッションフェイルオーバ機能では，J2EEサーバ上のHttpSessionオブジェクトに登録されたオブジェクトの情報を，ほかのJ2EEサーバに引き継ぎます。

複数のJ2EEサーバ間で引き継いで使用できるセッションを，グローバルセッションといいます。HTTPセッションは，そのセッションを扱っているJ2EEサーバに障害が発生すると消失します。一方，グローバルセッションは，J2EEサーバとは別のプロセスで管理されているため，J2EEサーバに障害が発生した場合も消失しません。このため，一つのJ2EEサーバで障害が発生した場合に，別のJ2EEサーバにHTTPセッションを作成して，グローバルセッションの情報を引き継げます。

グローバルセッションを使用している場合に，ほかのJ2EEサーバに引き継がれるHttpSessionオブジェクトの情報を，グローバルセッション情報といいます。

HTTPセッションとグローバルセッションの範囲について，次の図に示します。

図5‒2　HTTPセッションとグローバルセッションの範囲

セッションフェイルオーバ機能では，J2EEサーバでの障害発生時にグローバルセッション情報を引き継ぐことで，ユーザにエラーを通知することなく，障害発生前の状態で業務を続行できます。

5.3.2　グローバルセッション情報に含まれる情報

データベースセッションフェイルオーバ機能を使用する場合，グローバルセッション情報は，データベースに作成するセッション情報格納テーブルのレコードに格納されます。グローバルセッション情報が格納される際，HTTPセッションごとに一つのレコードが割り当てられます。

グローバルセッション情報には，次の表に示す情報が含まれます。

表5‒2　グローバルセッション情報に含まれる情報

項番

冗長化の対象

説明

1

セッションID

グローバルセッション情報を管理するセッションIDです。

2

HTTPセッションの属性情報

HTTPセッションに登録された属性および関連づけられたすべての属性について，属性名および属性値のオブジェクトをシリアライズしたバイト配列に変換した情報です。

3

HTTPセッションの作成時刻

HTTPセッションが作成された時刻です。グローバルセッションの引き継ぎが発生した場合，引き継ぎ前のHTTPセッションの作成時刻をそのまま使用します。

4

HTTPセッションの有効期限

HTTPセッションに設定された有効期限です。

5

最終アクセス時刻

HTTPセッションを使用するリクエストが最後に送信された時刻です。

6

HTTPセッションの所有J2EEサーバ識別子

HTTPセッションを作成，または引き継ぎをしたJ2EEサーバのサーバIDです。

参考

データベースセッションフェイルオーバ機能で使用するデータベースのテーブルには，Webアプリケーションの設定情報を格納するアプリケーション情報テーブル，グローバルセッション情報を格納するセッション情報格納テーブル，およびセッション情報格納テーブルの未使用レコードを管理する空きレコード情報テーブルがあります。

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

ここでは，障害発生時に引き継げるHTTPセッションの属性に関する次の項目について説明します。

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

引き継ぎ対象としてサポートされるオブジェクト

オブジェクトの内容によるセッション情報の引き継ぎ可否

HTTPセッションの属性引き継ぎ時のシリアライズ処理についての注意事項

HTTPセッションの属性引き継ぎ時のデシリアライズ処理についての注意事項

HTTPセッションの属性引き継ぎ時の注意事項

(1)　引き継げるHTTPセッションの属性の条件

セッションフェイルオーバ機能では，グローバルセッション情報の更新処理でオブジェクトのシリアライズ，引き継ぎ処理でオブジェクトのデシリアライズ処理が発生します。そのため，HTTPセッションに登録する属性は，次の条件を満たす必要があります。

java.io.Serializableインタフェースを実装した直列化可能クラスのオブジェクトである。

(2)　引き継ぎ対象としてサポートされるオブジェクト

セッションフェイルオーバ機能では，次に示す直列化可能クラスのオブジェクトを引き継ぎ対象としてサポートしています。

J2EEアプリケーションで提供されるクラスのオブジェクト。

J2SEで提供されるクラスのオブジェクト。

ただし，引き継ぎ処理では，HTTPセッションに登録された直列化可能クラスのオブジェクトが，セッションフェイルオーバ機能でサポートされているオブジェクトかどうかはチェックされません。

(3)　オブジェクトの内容によるセッション情報の引き継ぎ可否

HTTPセッションに登録されたオブジェクトの内容によるセッション情報の引き継ぎ可否を次の表に示します。

表5‒3　HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ可否

項番

HTTPセッションに登録されたオブジェクトの内容

セッション情報の引き継ぎ可否

グローバルセッション情報の格納

java.io.Serializableインタフェースの実装の有無

シリアライズの成功/失敗

1

java.io.Serializableインタフェースの実装あり

シリアライズの成功

引き継ぎできます。

シリアライズ後の情報がデータベースに格納されます。

2

シリアライズの失敗

シリアライズに失敗した属性を含むHTTPセッションは，グローバルセッションの引き継ぎの対象とならないため，引き継ぎできません。

KDJE34318-EまたはKDJE34411-Eのメッセージが出力され，データベースにグローバルセッション情報は格納されません。

次回以降のリクエスト処理完了後に，HTTPセッションに登録されたオブジェクトがシリアライズ可能となった時点で，データベース上にグローバルセッション情報が格納されます。

3

java.io.Serializableインタフェースの実装なし

（シリアライズできません）

シリアライズできない属性はグローバルセッションの引き継ぎの対象とならないため，引き継ぎできません。

シリアライズできないオブジェクトが存在したときは，KDJE34317-WまたはKDJE34410-Wのメッセージが出力され，シリアライズできない属性を除いた属性で作成したグローバルセッション情報がデータベースに格納されます。

(4)　HTTPセッションの属性引き継ぎ時のシリアライズ処理についての注意事項

シリアライズ処理についての注意事項を次に示します。

(a)　シリアライズ処理が性能に与える影響

引き継ぎ対象のオブジェクトだけでなく，引き継ぎ対象のオブジェクトから参照されるオブジェクトすべてを対象としてシリアライズ処理が実行されます。このため，引き継ぐ必要がない情報を含むクラスなどをHTTPセッションに登録した場合，性能が低下するおそれがあります。

(b)　java.lang.OutOfMemoryErrorエラーが発生する場合

シリアライズ処理では，一時的に，アプリケーションで設定したHttpSessionオブジェクト数を超えてシリアライズ後のデータが作成されます。そのため，巨大なオブジェクトがHTTPセッションに登録された場合，グローバルセッション情報の作成中にjava.lang.OutOfMemoryErrorエラーが発生することがあります。

(c)　シリアライズに失敗する場合とその対処

次のような場合は，KDJE34317-W，KDJE34318-E，KDJE34410-W，またはKDJE34411-Eのメッセージが出力され，シリアライズに失敗します。

HTTPセッションに登録したオブジェクト（直列化可能クラスのオブジェクト）から参照するオブジェクトに，直列化可能クラス以外のクラスを実装したオブジェクトが含まれる場合。

オブジェクトにwriteObject(java.io.OutputStream out)メソッドが実装されており，シリアライズ時に例外が発生する場合。

失敗した場合，グローバルセッション情報の更新，および引き継ぎ処理が実行されません。処理を実行するためには，次のどちらかの対処が必要です。

シリアライズに失敗したオブジェクトのHTTPセッションへの登録を解除する。

シリアライズに失敗したオブジェクトを変更して，シリアライズに失敗した原因を取り除く。

(5)　HTTPセッションの属性引き継ぎ時のデシリアライズ処理についての注意事項

次のような場合は，デシリアライズに失敗します。

デシリアライズに失敗する原因となる変更がWebアプリケーションに加えられ，シリアライズ時とWebアプリケーションが異なっている場合。

オブジェクトにreadObject(java.io.OutputStream out)メソッドが実装されており，デシリアライズ時に例外が発生する場合。

リクエストの受信時，またはWebアプリケーション開始時のグローバルセッション情報の引き継ぎ処理でセッション情報のデシリアライズに失敗した場合，グローバルセッション情報およびセッション情報が削除され，KDJE34326-E，またはKDJE34413-Eが出力されます。セッションの引き継ぎに失敗するため，HTTPセッションがない状態でリクエストが処理されます。

(6)　HTTPセッションの属性引き継ぎ時の注意事項

完全性保障モードを使わない，かつ同じセッションに対して同時にリクエストが実行される構成である場合，セッションにはスレッドアンセーフなオブジェクトを格納してはなりません（ユーザプログラム内でsynchronized句などを利用したスレッドセーフな実装をしていても，Cosminexus側の処理との競合は防げません）。

5.4　前提条件

セッションフェイルオーバ機能を使用するための前提条件について説明します。

5.4.1　前提となる構成

セッションフェイルオーバ機能を使用する場合，負荷分散機を使用した，複数のJ2EEサーバにリクエストを振り分けるシステム構成が前提となります。また，各J2EEサーバで作成されたHTTPセッションの情報を格納するためのデータベースの配置が必要です。

なお，データベースセッションフェイルオーバ機能ではOracle RACを使用したOracleへの接続はサポートしません。

データベースセッションフェイルオーバ機能を使用する場合の前提となる構成を次の図に示します。

図5‒3　セッションフェイルオーバ機能の前提となる構成

負荷分散機

セッションフェイルオーバ機能を使用するには，負荷分散機の使用が前提となります。

参考

負荷分散機によるリクエストの振り分けとは

負荷分散機では，リクエストの振り分けが実行されます。これによって，負荷が分散されるので，システムの安定稼働と処理性能の向上が図れます。

負荷分散機を使用した負荷分散には，WebサーバやJ2EEサーバに負荷分散処理に関する負荷が掛からないという利点があります。なお，負荷分散機によるリクエストの振り分け方式は，それぞれの負荷分散機に依存します。

負荷分散機によるリクエスト振り分けの例を次の図に示します。

図5‒4　負荷分散機によるリクエストの振り分けの例

J2EEサーバ/Webサーバ

セッションフェイルオーバ機能を使用する場合，一つのシステムで一つ以上のJ2EEサーバおよびWebサーバを配置します。J2EEサーバ障害に備え，二つ以上配置することを推奨します。

データベース

データベースセッションフェイルオーバ機能を使用する場合に，セッション情報の格納先としてデータベースが必要です。セッション情報の格納先として使用できるデータベース，JDBCドライバ，およびリソースアダプタの対応について次の表に示します。

表5‒4　使用できるデータベース，JDBCドライバおよびリソースアダプタの対応

データベース

JDBCドライバ

リソースアダプタ※

HiRDB

HiRDB Type4 JDBC Driver

DBConnector_HiRDB_Type4_CP.rar

Oracle

Oracle JDBC Thin Driver

DBConnector_Oracle_CP.rar

注※　データベースセッションフェイルオーバ機能で使用するリソースアダプタはDB Connectorです。データベースセッションフェイルオーバ機能で使用するDB Connectorに必要な設定については，「6.6.4　DB Connectorの設定」を参照してください。

なお，データベースセッションフェイルオーバ機能を使用するための詳細なシステム構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.10.1　データベースを使用する構成（データベースセッションフェイルオーバ機能）」を参照してください。

データベースセッションフェイルオーバ機能を使用する構成は，ここで示した条件を満たしている場合，構成から設計し直す必要がありません。機能の設定とパラメタチューニングを実施すればデータベースセッションフェイルオーバ機能を使用できます。

5.4.2　前提となる設定

セッションフェイルオーバ機能を使用するための前提となる設定について説明します。

(1)　セッションフェイルオーバ機能共通の前提となる設定

データベースセッションフェイルオーバ機能を使用する場合，次の設定が必要です。

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

HTTPセッションのセッションIDにサーバIDを付加する機能です。データベースセッションフェイルオーバ機能（完全性保障モード無効）を使用する場合は，この機能を有効にする必要があります。また，冗長化したJ2EEサーバごとに，異なるサーバID※を設定します。

HttpSessionのサーバID付加機能を無効にした場合，Webアプリケーションの開始時にKDJE34371-EまたはKDJE34404-Eのエラーメッセージがメッセージログに出力され，Webアプリケーションの開始に失敗します。冗長化したJ2EEサーバごとに異なるサーバID※を設定しなかった場合は，意図しないJ2EEサーバにグローバルセッション情報が引き継がれ，グローバルセッション情報の完全性が失われることがあります。

HttpSessionのセッションIDへのサーバIDの付加機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.6　セッションIDおよびCookieへのサーバIDの付加」を参照してください。

注※　実行系と待機系による系切り替えシステムの場合，実行系と待機系の値は同じにしてください。

HTTPセッションのスティッキー（Sticky）の設定

負荷分散機を使用する環境でセッションフェイルオーバ機能を使用するには，HTTPセッションのスティッキーを設定する必要があります。

HTTPセッションのスティッキーを設定しない場合，HTTPセッションを保持したリクエストの振り分け先が固定されません。そのため，HTTPセッションを保持したリクエストを受け付けるたびにHTTPセッションの引き継ぎ処理が実施され，性能が劣化するおそれがあります。

ホストの時刻の設定

セッションフェイルオーバ機能を使用するには，システム内のJ2EEサーバが稼働するそれぞれのホストに同じ時刻を設定してください。

データベースに格納するセッション情報には，HTTPセッションの作成時刻や，最終アクセス時刻などの情報が含まれます。各ホストでの設定時刻が異なっている場合，セッション情報に自ホストの設定時刻と異なる情報が含まれます。そのため，セッションの引き継ぎが発生した場合にHTTPセッションの制御に問題が発生するおそれがあります。

(2)　データベースセッションフェイルオーバ機能の前提となる設定

データベースセッションフェイルオーバ機能を使用する場合，次の設定が必要です。

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

有効となるHttpSessionオブジェクト数の上限値を設定する機能です。この機能は，完全性保障モードを有効にする場合に設定します。

アプリケーション開始時に実施されるネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を中止する設定にしているときは，上限値に1以上の有効な値を設定する必要があります。HttpSessionオブジェクト数の上限値を設定していない場合，アプリケーション開始時にKDJE34303-Eのエラーメッセージがメッセージログに出力され，アプリケーションの開始に失敗します。

ただし，ネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を続行する設定にしているときは，HttpSessionオブジェクト数の上限値の設定は任意です。また，上限値に-1（無制限）を設定することもできます。HTTPSessionオブジェクト数の上限値に-1（無制限），またはデータベースのセッション情報格納テーブルのレコード数よりも大きな値を設定した場合，HttpSessionオブジェクト数がセッション情報格納テーブルのレコード数を超過したときの動作は，次のようになります。

完全性保障モードが無効の場合（任意）

該当するHTTPセッションは縮退して，リクエスト処理が続行されます。

完全性保障モードが有効の場合

KDJE34380-Eのエラーメッセージがメッセージログに出力され，該当するHTTPセッションは作成されません。

HttpSessionオブジェクト数の上限値の設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.7.5　HttpSessionオブジェクト数の上限値の設定」を参照してください。

ネゴシエーション処理については，「6.4.1　アプリケーション開始時の処理」を参照してください。

完全性保障モードについては，「5.5.1(4)　データベースセッションフェイルオーバ機能の運用モード」を参照してください。

完全性保障モードが無効の場合のHTTPセッションの縮退については，「5.7.3　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例外がスローされます。

ユーザ指定名前空間機能

データベースセッションフェイルオーバ機能を使用する場合，ユーザ指定名前空間機能を利用して付与した別名でのJ2EEリソースのルックアップが前提となります。

このため，J2EEサーバのプロパティに次のパラメタを指定してラウンドロビン検索機能を使用している場合，データベースセッションフェイルオーバ機能は使用できません。

java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactory

このパラメタを指定している場合，Webアプリケーション開始時にKDJE34305-Eのエラーメッセージがメッセージログに出力され，Webアプリケーションの開始に失敗します。

J2EEサーバで動作するJ2EEアプリケーションでラウンドロビン検索が必要な場合は，InitialContextFactoryの実装を委譲しているクラスをJ2EEサーバのプロパティで指定しないで，各アプリケーションのInitialContext生成時に引数で指定する必要があります。ラウンドロビン検索機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.7　ラウンドロビンポリシーによるCORBAネーミングサービスの検索」を参照してください。

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

J2EEサーバ間のセッション情報の引き継ぎを実現するための機能として，データベースセッションフェイルオーバ機能があります。ここでは，データベースセッションフェイルオーバ機能の概要について説明します。

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

データベースセッションフェイルオーバ機能は，セッション情報をデータベースで管理することで，障害が発生した場合にJ2EEサーバ間のセッション情報の引き継ぎを実現するための機能です。障害が発生した場合，データベースに格納されているセッション情報を基にセッションを再作成し，正常に業務を続行できます。

データベースセッションフェイルオーバ機能の処理の概要，運用モードについて説明します。

(1)　セッション情報の格納の流れ

データベースセッションフェイルオーバ機能を使用すると，リクエストによるセッションの作成処理が発生したときに，処理の延長上でセッション情報がデータベースに格納されます。

セッション情報の格納の流れを次の図に示します。

図5‒5　セッション情報の格納の流れ（データベースセッションフェイルオーバ機能）

項番は図中の番号と対応しています。

Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます。

作成されたセッションについて，セッション情報が作成されます。

セッション情報がデータベースに格納されます。

Webサーバ1またはJ2EEサーバ1で障害が発生すると，データベースに格納されたセッション情報がWebサーバ2またはJ2EEサーバ2へ引き継がれ，障害発生前の状態で業務を続行できます。

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れ

WebサーバまたはJ2EEサーバで障害が発生した場合，データベースに格納されているセッション情報を基に，ほかのJ2EEサーバでセッションを再作成し，正常に業務を続行できます。

WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れについて，次の図に示します。

図5‒6　WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れ（データベースセッションフェイルオーバ機能）

Webサーバ1で障害が発生すると，負荷分散機によってWebサーバ2へリクエストが転送されます。

転送先のJ2EEサーバ2でリクエストを処理するとき，リクエストに関連づけられたセッションが存在しないため，データベースからセッション情報を引き継ぎます。

セッションが再作成されます。

セッションが正常に引き継がれ，障害発生前の状態で業務を続行できます。

また，J2EEサーバ1を再起動しWebサーバ1が障害から回復すると，再びリクエストはWebサーバ1に送信されます。

(3)　データベースで障害が発生した場合の処理の流れ

データベースで障害が発生すると，J2EEサーバ上のセッション情報だけを操作して業務を続行できます。データベースが障害から回復し，それ以降のセッションの操作でデータベースにアクセスできたとき，J2EEサーバ上で操作したセッション情報でデータベースを更新します。

これによって，クライアントはデータベースに障害が発生したことを意識しないで業務を続行できます。

(4)　データベースセッションフェイルオーバ機能の運用モード

データベースに格納済みのグローバルセッション情報に対して同じセッションIDを持つリクエストが複数同時に送信された場合，デフォルトの設定では，リクエストは複数同時に処理できます。これによって，データベースセッションフェイルオーバ機能を使用することによる処理性能の低下は抑えられています。

ただし，この運用は，冗長化された複数のJ2EEサーバから同じセッションIDのグローバルセッション情報を同時に更新するような処理が発生しないことを前提とした運用です。複数のJ2EEサーバから同じセッションIDのグローバルセッション情報が同時に更新された場合は，グローバルセッション情報の整合性が失われるおそれがあります。このようなケースを許容できないシステムでは，グローバルセッション情報の整合性を確保するためのモードを有効にする必要があります。

グローバルセッション情報の整合性を保障するモードを完全性保障モードといいます。このモードを有効にした場合，グローバルセッションを更新するたびにデータベースにロックが設定されます。同じセッションIDの複数のリクエストが同時に送信された場合は，リクエストがシリアルに処理されるため，グローバルセッション情報が不整合な状態になることはありません。ただし，複数同時に実行できないこと，およびグローバルセッション情報の格納のたびにロックの設定・解除処理が発生することから，リクエスト処理性能に影響を及ぼす場合があります。

このため，データベースセッションフェイルオーバ機能を使用する場合は，システムの目的や特性に応じて，どちらのモードで運用するかを検討する必要があります。

完全性保障モードの有効・無効による主な違いを次の表に示します。

表5‒5　完全性保障モードの有効・無効による主な違い

比較項目

完全性保障モード

無効

有効

適したシステムの特性

性能を重視するシステムに適しています。

性能が低下したとしても，確実なセッション情報の引き継ぎが必要なシステムに適しています。

リクエストの処理性能

同じセッションIDの複数のリクエストを同時に処理できるので，優れています。

リクエストをシリアルに処理する必要があるため，性能が低下します。

グローバルセッション情報の完全性

同じセッションIDのグローバルセッション情報を同時に更新した場合は，保障されません。

保障されます。

データベースに障害が発生した場合の挙動

J2EEサーバ上のセッション情報を使用して処理を継続します（データベースセッションフェイルオーバ機能の縮退運用）。

エラーメッセージを出力して処理を停止します。

それぞれのモードでのリクエスト処理の流れを次の図に示します。

図5‒7　完全性保障モードを無効にした場合のリクエスト処理の流れ（デフォルトの設定）

完全性保障モードが無効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際にデータベースのロックが取得・解除されますが，一度コミットしたあとのセッション取得処理ではロックが取得されません。また，以降のグローバルセッション情報の更新処理では，データベースのロックの取得処理および解除処理は実施されません。

図5‒8　完全性保障モードを有効にした場合のリクエスト処理の流れ

完全性保障モードが有効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際に，データベースのロックが取得・解除されます。さらに，一度コミットしたあとのセッション取得処理で，再度ロックが取得されます。これによって，HTTPセッション作成後，Webアプリケーション実行中にJ2EEサーバまたはデータベースで障害が発生した場合にも，データベースに不整合が発生しないことが保障されます。また，以降のグローバルセッション情報の更新処理では，更新するたびにデータベースのロックを取得し，更新したあとで解除する処理が実施されます。

グローバルセッション情報のロック時の動作については，「6.4.5(1)　ロック取得時のロック取得処理の呼び出し結果」を参照してください。

また，完全性保障モードの有効・無効の設定によって，使用できる機能が異なります。

5.6　セッションフェイルオーバ機能使用時に設定できる機能

ここではセッションフェイルオーバ機能を使用している場合に設定できる次の機能について説明します。この機能は必要に応じて使用できます。

セッションフェイルオーバの抑止

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

注※　HTTPセッションの参照専用リクエストの定義機能は，データベースセッションフェイルオーバ機能の完全性保障モード有効時には使用できません。

5.6.1　セッションフェイルオーバ機能の抑止

セッションフェイルオーバ機能を有効にした場合，HTTPセッションを取得済みのリクエストを受け付けたときに，データベースへのアクセスや，HTTPセッションのシリアライズなどの処理が実施されます。静的コンテンツやHTTPセッションを必要としないコンテンツに対するリクエストであっても，HTTPセッションを取得済みのリクエストと同一のセッションIDが送信された場合には，セッションフェイルオーバ機能が動作してこれらの不要な処理が発生します。

これに対して，セッションフェイルオーバ機能を抑止するURLパターンをURIまたは拡張子で設定すると，設定したURLパターンのリクエストに対するセッションフェイルオーバ機能の処理が抑止されるため，不要な処理が発生しなくなり，処理性能が向上します。このように，セッションフェイルオーバ機能を設定している場合に，特定のURLパターンに対してだけセッションフェイルオーバを抑止する機能をセッションフェイルオーバ抑止機能といいます。

セッションフェイルオーバ抑止機能の有効・無効と実施される処理の違いを，データベースセッションフェイルオーバ機能を例に次の図に示します。

図5‒9　セッションフェイルオーバ抑止機能の有効・無効と実施される処理の違い（データベースセッションフェイルオーバ機能）

性能向上以外では，次のような目的でセッションフェイルオーバ抑止機能が使用できます。

完全性保障モードが有効の場合のデータベースセッションフェイルオーバ機能では，同一セッションIDのリクエストに対して，排他的に処理を実行します。例えば，PUSH配信をするために常駐するようなサーブレット/JSPなど，長時間処理が終了しないサーブレット/JSPをHTMLのフレームなどの一つから呼び出した場合，そのサーブレット/JSPの処理が終わるまで，同じフレームから送信されるすべてのリクエストは実行されません。これは，一つのフレームから送信されるリクエストはすべて同一のセッションIDを送信するリクエストになるためです。

このような状態を防ぐためには，HTTPセッションを使用していない特定のリクエストに対して，セッションフェイルオーバ機能を抑止する必要があります。

完全性保障モードを有効にしてデータベースセッションフェイルオーバ機能を使用している場合に，セッションフェイルオーバ抑止機能を有効または無効に設定したときに実施される処理の違いを次の図に示します。なお，図中のリクエスト1およびリクエスト2は，同一のセッションIDを送信するリクエストです。

図5‒10　セッションフェイルオーバ抑止機能の有効・無効と実施される処理の違い（データベースセッションフェイルオーバ機能）

セッションフェイルオーバ抑止機能の有効・無効は，J2EEサーバ単位またはWebアプリケーション単位に設定できます。

注意事項

セッションフェイルオーバ抑止機能について，注意事項を示します。

セッションフェイルオーバ抑止機能によってセッションフェイルオーバ機能が無効となったリクエスト処理内で，javax.servlet.http.HttpServletRequestインタフェースのgetSession()メソッドまたはgetSession(boolean create)メソッドを呼び出すと，com.hitachi.software.web.dbsfo.SessionOperationException例外がスローされます。このため，このメソッドを呼び出すリクエストに対しては，セッションフェイルオーバ抑止機能は適用できません。

com.hitachi.software.web.dbsfo.SessionOperationException例外についての詳細は，マニュアル「アプリケーションサーバ リファレンス API編」の「3.1　例外クラス」を参照してください。

セッションフェイルオーバ抑止機能によってセッションフェイルオーバ機能が無効となったリクエストは，HTTPセッションを使用するリクエストではないため，HTTPセッションのアクセス時刻が更新されません。これによって，次の影響があります。

・javax.servlet.http.HttpSessionインタフェースのgetLastAccessedTime()メソッドは，前回HTTPセッションを使用するリクエストが実行された時刻を返します。

・現在の時刻とHTTPセッションのアクセス時刻の差がタイムアウト時間を超えた場合，HTTPセッションはタイムアウトします。このため，HTTPセッション作成後に，セッションフェイルオーバ機能が無効になったリクエストだけを送信し続けると，HTTPセッションのタイムアウトが発生する場合があります。

JSPでは，デフォルトで暗黙的にHTTPセッションが作成されます。このため，HTTPセッションを必要としないJSPに対してセッションフェイルオーバ抑止機能を適用する場合は，明示的にpageディレクティブのsession属性を使用してHTTPセッションを作成しない設定にする必要があります。

Webコンテナが提供するログイン認証機能としてFORM認証を使用する場合，暗黙的にHTTPセッションが作成されます。セッションフェイルオーバの抑止機能によってセッションフェイルオーバ機能が無効となったリクエストでFORM認証を使用すると，HTTPセッションを作成できないため，com.hitachi.software.web.dbsfo.SessionOperationException例外が発生し，認証は行われません。ただし，すでにセッションが作成されている場合は，セッションフェイルオーバ抑止機能によってセッションフェイルオーバ機能が無効となったリクエストでも例外は発生しないで，認証は行われます。

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

HTTPセッションの参照専用リクエストの定義機能とは，HTTPセッションを更新しないで参照だけするリクエスト（参照専用リクエスト）のURLパターンを設定することで，そのURLパターンのリクエストに対してHTTPセッションのシリアライズや，データベースへのアクセスの処理を抑止する機能です。

この機能は，データベースセッションフェイルオーバ機能の完全性保障モードが無効の場合に使用できます。

なお，HTTPセッションを更新だけでなく参照もしないリクエストの場合は，セッションフェイルオーバ抑止機能を使用できます。参照専用リクエストとセッションフェイルオーバ抑止機能の対象リクエストの両方に該当するリクエストの場合，セッションフェイルオーバ抑止機能の対象リクエストとして処理されます。セッションフェイルオーバ抑止機能については，「5.6.1　セッションフェイルオーバ機能の抑止」を参照してください。

HTTPセッションの参照専用リクエストの定義機能は，J2EEサーバ単位またはWebアプリケーション単位に設定できます。

データベースセッションフェイルオーバ機能のJ2EEサーバ単位の設定については，「6.6.1　J2EEサーバの設定」を参照してください。

注意事項

HTTPセッションの参照専用リクエストの定義について，注意事項を示します。

参照専用リクエストでは，HTTPセッションを無効化できません。参照専用リクエストで，HTTPセッションを無効化するjavax.servlet.http.HttpSessionインタフェースのinvalidate()メソッドをWebアプリケーション内で呼び出した場合，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オブジェクトにセッションの属性情報として登録済みとします。

5.7　セッションフェイルオーバ機能使用時に実行される機能

ここでは，セッションフェイルオーバ機能を使用している場合に，自動で実行される機能について説明します。ここで説明する機能は，データベースセッションフェイルオーバ機能の完全性保障モードが無効の場合に適用される機能です。データベースセッションフェイルオーバ機能の完全性保障モードが有効の場合には適用されません。

5.7.1　同一セッションIDの同時実行

同一セッション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アプリケーションを実装してください。

5.7.2　Webアプリケーション開始時のグローバルセッション情報の引き継ぎ

WebアプリケーションやJ2EEサーバを停止した場合，またはJ2EEサーバが障害でプロセスダウンした場合，J2EEサーバ上のHTTPセッションは破棄されます。Webアプリケーションを再開始する際に，グローバルセッション情報を引き継ぐ機能をWebアプリケーション開始時のグローバルセッション情報の引き継ぎといいます。

J2EEサーバが障害でダウンしたあと，Webアプリケーションを再開始する際の，グローバルセッション情報の引き継ぎ処理の流れを次に示します。

データベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得する。

Webアプリケーションの開始時，データベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得します。

グローバルセッション情報の引き継ぎ処理を実行する。

セッションIDのリストを取得できた場合，KDJE34344-IまたはKDJE34429-Iのメッセージをメッセージログに出力し，グローバルセッション情報の引き継ぎ処理を開始します。

グローバルセッション情報の引き継ぎ処理では，リストに含まれているセッションIDのグローバルセッション情報を一つずつデータベースからJ2EEサーバ上に引き継ぎます。

グローバルセッション情報の引き継ぎができなかった場合，障害の原因に対応したメッセージが出力されます。

引き継ぎ処理を終了する。

セッションIDのリストにあるすべてのグローバルセッション情報の引き継ぎが完了した時点で，KDJE34349-IまたはKDJE34430-Iのメッセージがメッセージログに出力されます。

なお，次の表に示す条件の場合，グローバルセッション情報は引き継がれません。

表5‒6　グローバルセッション情報が引き継がれない場合の条件と動作

項番

条件

動作

1

ネットワーク障害などの理由でデータベースから引き継ぐグローバルセッション情報のセッションIDのリストを取得できなかった場合。

KDJE34345-WまたはKDJE34431-Wのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理が終了します。

2

引き継ぐグローバルセッション情報が，すでにJ2EEサーバ上に存在する場合（リクエストの受信でJ2EEサーバ上にすでに引き継がれている）。

KDJE34347-IまたはKDJE34432-Iのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理がスキップされます。

3

引き継ぐグローバルセッション情報が，データベースセッションフェイルオーバ機能で，すでに冗長化された別のJ2EEサーバに引き継がれている場合。

KDJE34348-Iのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理はスキップされます。

4

ネットワーク障害などの理由でデータベースからグローバルセッション情報を取得できなかった場合。

KDJE34346-Wのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理がスキップされます。

5

J2EEサーバ上のHTTPセッション数が，HttpSessionオブジェクト数の上限値の指定機能で設定した上限値に達したために引き継げなかった場合。

KDJE34370-Wのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理がスキップされます。

6

グローバルセッション情報のデシリアライズに失敗した場合。

KDJE34328-EまたはKDJE34436-Eのメッセージがメッセージログに出力され，グローバルセッション情報を引き継がないで，データベースから削除されます。

7

データベースセッションフェイルオーバ機能を使用していて，HttpSessionのサーバID付加機能で設定したサーバIDを変更した場合。

KDJE34348-Iのメッセージがメッセージログに出力され，グローバルセッション情報の引き継ぎ処理がスキップされます。

5.7.3　HTTPセッションの縮退

HTTPセッションの縮退とは，データベースで次の表に示す障害が発生した場合に，処理を中断しないで，J2EEサーバ上のHTTPセッションを使用してリクエスト処理を続行する機能です。

表5‒7　HTTPセッションの縮退が機能する障害の内容

障害の発生個所

使用する機能

障害の内容

データベース

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

グローバルセッション情報の作成時にデータベースに空きレコードが存在しない

グローバルセッション情報の操作時にデータベース障害が発生

発生した障害によってHTTPセッションが縮退するときの動作を次の表に示します。

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

表5‒8　HTTPセッションの縮退時の動作（データベースセッションフェイルオーバ機能の場合）

発生した障害

縮退の動作

縮退時に出力されるメッセージ※

縮退が解除されるタイミング

縮退したHTTPセッションの引き継ぎ

グローバルセッション情報の作成時にデータベースに空きレコードがない。

J2EEサーバ上のHTTPセッションだけを作成する。

KDJE34367-W

以降のHTTPセッションの操作時にデータベースに空きレコードがあり，グローバルセッション情報を作成できた場合。

データベースにグローバルセッション情報が存在しないため，引き継がれない。

グローバルセッション情報の操作時にデータベース障害が発生した。

J2EEサーバ上のHTTPセッションだけを操作する。

KDJE34368-W

以降のHTTPセッションの操作時にデータベースアクセスに成功した場合。

データベースにグローバルセッション情報が存在しない場合：引き継がれない。

データベースにグローバルセッション情報が存在する場合：古いグローバルセッション情報が引き継がれるときがある。

注※　発生した障害ごとに，初めて縮退したときに出力されるメッセージです。それ以降は，縮退したHTTPセッションがすべてなくなってから，再び縮退するまで出力されません。なお，縮退したHTTPセッションがすべてなくなった場合は，メッセージKDJE34369-Iが出力されます。

5.8　メモリの見積もり

セッションフェイルオーバ機能を使用する場合，環境構築の準備として次のメモリサイズの見積もりをします。

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

シリアライズ処理で使用するメモリ

HTTPセッションの属性情報のサイズ

データベースのテーブル容量

ここでは，見積もり方法について説明します。

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

セッションフェイルオーバ機能では，リクエスト処理完了時に，HTTPセッションの属性情報のシリアライズのために一時的にメモリが確保されます。このメモリ確保によって必要となるメモリ領域のサイズについて，JavaVMのチューニング時に考慮する必要があります。

チューニングでは，複数スレッドでメモリを確保する処理が重なった場合のメモリの増加量（最大増加量）を見積もります。リクエストの処理時に使用するメモリの最大増加量について，Webアプリケーション単位，およびJ2EEサーバ単位に求める式をそれぞれ次に示します。

Webアプリケーション単位の使用メモリ最大増加量（バイト）＝
最大同時実行スレッド数※1 × HTTPセッションの属性情報の最大サイズ※2

J2EEサーバ単位の使用メモリ最大増加量（バイト）＝
Webアプリケーション単位の使用メモリ最大増加量の合計 ＝
　　Webアプリケーション1の使用メモリ最大増加量
　＋Webアプリケーション2の使用メモリ最大増加量
　　　：
　＋Webアプリケーションｎの使用メモリ最大増加量

注※1

Webアプリケーション単位の同時実行スレッド数を設定している場合はWebアプリケーション単位の最大同時実行スレッド数の値を指します。Webアプリケーション単位の同時実行スレッド数を設定していない場合はWebコンテナ単位の最大同時実行スレッド数の値を指します。

注※2

HTTPセッションの属性情報のサイズ見積もり機能で見積もった値を指します。

上記の式で求めた値を基に，JavaVMのチューニングを実施してください。

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

セッションフェイルオーバ機能が使用するデータベースのディスク容量を確保する際，HTTPセッションの属性情報の最大サイズが必要になります。

HTTPセッションの属性情報のサイズをWebアプリケーションの内容から計算して求めることは困難です。そのため，アプリケーションサーバではHTTPセッションの属性情報のサイズ見積もり機能を提供しています。HTTPセッションの属性情報のサイズ見積もり機能を使用すると，実際にアプリケーションを実行し，HTTPセッションに登録した属性のシリアライズ後のサイズ情報をメッセージとして出力できます。

ここでは，HTTPセッションの属性情報のサイズ見積もり機能およびHTTPセッションの属性情報のサイズを求める計算式について説明します。

また，FullGCの抑止をする場合のメモリの確保についても説明します。

(1)　HTTPセッションの属性情報のサイズの見積もり機能

HTTPセッションの属性情報のサイズ見積もり機能を使用すると，出力されたサイズ情報を参考にして，HTTPセッションの属性情報の最大サイズに適切な値を見積もることができます。

なお，この機能は見積もり時に使用する機能です。データベースへのグローバルセッションの格納は実施されないため，データベースへの接続は発生しません。

注意事項

HTTPセッションの属性情報のサイズの見積もり機能は，運用環境で使用しないでください。この機能を使用した場合，データベースセッションフェイルオーバ機能は無効となり，グローバルセッション情報がデータベースに冗長化されません。

(a)　HTTPセッションの属性情報のサイズの見積もり機能を有効にするための設定

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，次のパラメタに「on」を指定してください。

webserver.dbsfo.check_size.modeパラメタ

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

HTTPセッションの属性情報のサイズの見積もり機能を有効にすると，データベースセッションフェイルオーバ機能に関するほかの設定はすべて無効になります。

なお，HTTPセッションの属性情報のサイズの見積もり機能を使用する場合，「5.4.2　前提となる設定」で示しているHttpSessionオブジェクト数の上限値の指定機能を有効にしなくても動作します。

(b)　HTTPセッションの属性情報のサイズを通知するメッセージ

HTTPセッションの属性情報のサイズ見積もり機能が有効の場合，Webアプリケーションのリクエスト処理完了時にHTTPセッションの属性情報のサイズを通知する次のメッセージがErrorレベルで出力されます。

表5‒9　HTTPセッションの属性情報のサイズを通知するメッセージ

メッセージID

内容

サイズの情報に含まれる内容

KDJE34330-IまたはKDJE34416-I

リクエストごとに作成したHTTPセッションの属性情報のサイズ

HTTPセッションに登録されている属性をシリアライズした結果の合計サイズ（KDJE34331-IまたはKDJE34417-Iで出力するサイズの合計）※1

KDJE34331-IまたはKDJE34417-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個のオブジェクトを属性として登録して，登録した属性をそれぞれ属性1〜属性nとする場合，HTTPセッションの属性情報の最大サイズは次の式で求めることができます。

HTTPセッションの属性情報の最大サイズ（バイト）＝
　　　　属性1の属性名をシリアライズしたバイト配列のバイト数
　　　＋属性1の属性値をシリアライズしたバイト配列のバイト数
　　　＋属性2の属性名をシリアライズしたバイト配列のバイト数
　　　＋属性2の属性値をシリアライズしたバイト配列のバイト数
　　　　　：（中略）
　　　＋属性ｎの属性名をシリアライズしたバイト配列のバイト数
　　　＋属性ｎの属性値をシリアライズしたバイト配列のバイト数

属性名をシリアライズしたバイト配列のバイト数，および属性値をシリアライズしたバイト配列のバイト数は次の式で求めることができます。

属性名をシリアライズしたバイト配列のバイト数

属性名をシリアライズしたバイト配列のバイト数＝
　属性名の文字数×3×1.2

属性値をシリアライズしたバイト配列のバイト数

属性値をシリアライズしたバイト配列のバイト数＝
　属性値のオブジェクトが持つすべてのフィールドの値のバイト数の合計×1.2

なお，フィールドの値のバイト数は次の式で求めることができます。

Stringオブジェクトの場合：文字数×3

その他のオブジェクトの場合：そのオブジェクトが持つすべてのフィールドの値のバイト数の合計

プリミティブ型の場合：それぞれのプリミティブ型を格納するために必要なバイト数

注意事項

HTTPセッションの属性情報のサイズを求める計算式で算出できる値は概算です。最終的にHTTPセッションの属性情報の最大値を求める際には，HTTPセッションの属性情報のサイズの見積もり機能を使用してください。

(3)　FullGCの抑止をする場合のメモリの確保

HTTPセッションの属性情報のサイズはシリアライズ後のサイズであるため，HTTPセッションに登録した属性オブジェクトのメモリ上でのサイズとは異なります。そのため，FullGCの抑止で必要となる外部ヒープ領域のメモリサイズの見積もりは別途実施して，適切な値を設定する必要があります。

FullGCの抑止についての詳細は「7.　明示管理ヒープ機能を使用したFullGCの抑止」を参照してください。

5.8.3　データベースのディスク容量の見積もり

データベースセッションフェイルオーバ機能では，3種類のテーブル（アプリケーション情報テーブル，セッション情報テーブル，空きレコード情報テーブル）を作成します。確保するディスク容量のサイズは，テーブルとインデクスの情報を基に各データベースのマニュアルを参照して見積もります。なお，これらの情報はComponent Containerのバージョンアップや修正パッチで変更になる場合があります。

(1)　テーブルの情報

テーブルごとの列の要素，および行数について説明します。

アプリケーション情報テーブル

列の要素を次の表に示します。

表5‒10　アプリケーション情報テーブルの列の要素

項番

列名

HiRDB型

ORACLE型

インデクスの有無

1

APP_INFO_KEY

CHAR(128) PRIMARY KEY

VARCHAR2(128) PRIMARY KEY

なし

2

APP_INFO_VALUE

CHAR(512)

VARCHAR2(512)

なし

行数は次のとおりです。

13＋参照専用リクエストの定義数

セッション情報格納テーブル

列の要素を次の表に示します。

表5‒11　セッション情報格納テーブルの列の要素

項番

列名

HiRDB型

ORACLE型

インデクスの有無

1

RECORD_NO

INTEGER PRIMARY KEY

NUMBER(10,0) PRIMARY KEY

なし

2

SESSIONID

CHAR(112)

VARCHAR2(112)

あり

3

CREATION_TIME

DECIMAL(23,0)

NUMBER(23,0)

なし

4

MAX_INACTIVE_INTERVAL

INTEGER

NUMBER(10,0)

なし

5

THIS_ACCESSED_TIME

DECIMAL(23,0)

NUMBER(23,0)

なし

6

ATTRIBUTES_DATA

BINARY(HTTPセッションの属性情報の最大サイズ)※1

BLOB※2

なし

7

STATUS

CHAR(16)

VARCHAR2(16)

なし

8

OWNER_SERVER

CHAR(512)

VARCHAR2(512)

なし

9

NEXT_FREE_RECORD_NO

INTEGER

NUMBER(10,0)

なし

注※1　HTTPセッションの属性情報のサイズの見積もりについては，「5.8.2　HTTPセッションの属性情報のサイズの見積もり」を参照してください。

注※2　BLOBの列に格納する値の最大サイズは，HTTPセッションの属性情報の最大サイズです。HTTPセッションの属性情報のサイズの見積もりについては，「5.8.2　HTTPセッションの属性情報のサイズの見積もり」を参照してください。

行数は次のとおりです。

ネゴシエーション処理に失敗した場合にWebアプリケーションの開始処理を続行する設定のとき

データベースに格納するグローバルセッション情報の数

ネゴシエーション処理に失敗した場合にWebアプリケーションの開始処理を中止する設定のとき

HttpSessionオブジェクト数の最大値

空きレコード情報テーブル

列の要素を次の表に示します。

表5‒12　空きレコード情報テーブルの列の要素

項番

列名

HiRDB型

ORACLE型

インデクスの有無

1

BLOCK_NO

INTEGER PRIMARY KEY

NUMBER(10,0) PRIMARY KEY

なし

2

FREE_RECORD_NO

INTEGER

NUMBER(10,0)

なし

行数は10固定です。

(2)　インデクスの情報

セッション情報格納テーブルのインデクスを次の表に示します。

項番

インデクス名

UNIQUE属性

カラム名

1

<アプリケーション識別子>_SESSIONS_IDX

なし

SESSIONID

参考

HiRDBを使用する場合，次の条件を満たすことで性能が向上することがあります。

データベースセッションフェイルオーバ機能で使用するテーブルおよびインデクスをRDエリアに配置している※。

RDエリアに配置したテーブルおよびインデクスにそれぞれグローバルバッファを設定している。

RDエリア，およびグローバルバッファの設計については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。

注※

RDエリアにテーブルおよびインデクスを配置する場合，SQLファイルの編集が必要です。

5.9　注意事項

ここでは，セッションフェイルオーバ機能使用時の注意事項，およびアプリケーション実装時の注意事項について説明します。

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

セッションの引き継ぎを必要としない処理では明示的にHttpSessionオブジェクトを作成しないように設定してください。

セッションフェイルオーバ機能を有効にしたアプリケーションでは，属性が登録されないHTTPセッションの作成時にも，グローバルセッション情報が作成され，さらにグローバルセッション情報の更新処理も発生します。

JSP仕様では，デフォルトでHttpSessionオブジェクトが作成されます。そのため，不要な処理によって，メモリの使用量が増加したり，データベースとの通信による負荷が発生したりするおそれがあります。

HttpSessionオブジェクトの作成に関する設定には，pageディレクティブのsession属性を使用します。

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

グローバルセッション情報はHTTPセッション単位に作成されます。

異なるHttpSessionオブジェクトで同一のオブジェクトをセッション情報として共有している場合に，グローバルセッション情報の引き継ぎが発生したときは，オブジェクトが共有されません。別々のオブジェクトとして作成されます。

異なるHttpSessionオブジェクトに同一のオブジェクトが登録されている場合の引き継ぎの例を次の図に示します。

図5‒11　異なる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は，インスタンスは異なりますが，内容は同じです。

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

アプリケーションサーバではログイン認証機能として，Form認証，Basic認証，およびHttpServletRequestのメソッドauthenticate/login/logoutがあります。セッションフェイルオーバ機能を使用したアプリケーションでこれらのログイン認証機能を使用した場合，次の動作となります。

Form認証を使用した場合

J2EEサーバの障害でセッションの引き継ぎが発生したとき，セッションの引き継ぎに成功した場合でも，再度Form認証による認証が必要です。

Basic認証を使用した場合

J2EEサーバの障害でセッションの引き継ぎが発生したかどうかに関係なく，再度Basic認証を行う必要はなく，続けてアクセスできます。

HttpServletRequestのメソッドauthenticate/login/logoutを使用した場合

J2EEサーバの障害でセッションの引き継ぎが発生したとき，セッションの引き継ぎに成功した場合でも，再度メソッドによる認証が必要です。

Basic認証およびForm認証については，マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「6.2　DDの設定によるWebコンテナのユーザ認証」を参照してください。

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

セッションフェイルオーバ機能を使用した場合のサーブレットAPIへの影響として，次の項目について説明します。

引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの動作

サーブレットAPIの呼び出しによるデータベースとの通信の発生

(1)　引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの動作

引き継ぎ後のHttpSessionオブジェクトに関連するサーブレットAPIの注意点について次の表に示します。

表5‒13　HttpSessionオブジェクトに関連するサーブレットAPIの注意点

項番

API名

注意点

1

getCreationTime()

引き継ぎによって，HttpSessionオブジェクトが作成された場合，引き継ぎ前のHttpSessionオブジェクトの情報が引き継がれます。

2

getLastAccessedTime()

3

getId()

引き継ぎによって，HttpSessionオブジェクトが作成された場合，引き継ぎ前のHttpSessionオブジェクトと同一のIDが取得できます。

4

isNew()

引き継ぎによって，HttpSessionオブジェクトが作成されても，戻り値「true」は返されません。

この表に示していないサーブレットAPIについては，セッションフェイルオーバ機能を使用した場合の影響はありません。

(2)　サーブレットAPIの呼び出しによるデータベースとの通信の発生

次の表に示すサーブレットAPIを実装した場合，API呼び出しの延長でデータベースとの通信が発生します。そのため，性能への影響があります。

表5‒14　データベースとの通信

項番

クラス

メソッド

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　データベースセッションフェイルオーバ機能

この章では，データベースセッションフェイルオーバ機能について説明します。

6.1　この章の構成

ここでは，データベースセッションフェイルオーバ機能について説明します。

この機能を使用すると，アプリケーションで実行中のセッション情報がデータベースに格納されます。格納されたセッション情報は，WebサーバやJ2EEサーバで障害が発生したときに，ほかのJ2EEサーバに引き渡されます。これによって，障害発生時にリクエストがほかのJ2EEサーバに転送された場合でも，障害発生前の状態で業務を続行できるようになります。

なお，セッションフェイルオーバ機能の種類や機能差異，前提条件，メモリの見積もり，注意事項については，「5.　J2EEサーバ間のセッション情報の引き継ぎ」を参照してください。

この章の構成を次の表に示します。

表6‒1　この章の構成（データベースセッションフェイルオーバ機能）

分類

タイトル

参照先

解説

適用手順

6.2.1

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

6.3

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

6.4

実装

cosminexus.xmlでの定義

6.5

設定

J2EEサーバの設定

6.6.1

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

6.6.2

データベースの設定

6.6.3

DB Connectorの設定

6.6.4

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

6.7

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

6.8

注意事項

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

6.9

注　「運用」について，この機能固有の説明はありません。

6.2　データベースセッションフェイルオーバ機能を使用するための準備

6.2.1　適用手順

データベースセッションフェイルオーバ機能を使用する場合に必要な，環境構築の準備と各種設定について説明します。データベースセッションフェイルオーバ機能の適用手順を次の図に示します。

図6‒1　適用手順（データベースセッションフェイルオーバ機能）

ここで示す適用手順に従って環境構築の準備や各種設定を実施したあと，J2EEアプリケーションを開始します。

(1)　環境構築の準備

データベースセッションフェイルオーバ機能を使用する場合に環境構築の準備として実施する項目について，実施内容および参照先を次の表に示します。

表6‒2　データベースセッションフェイルオーバ機能を使用する環境構築の準備として実施する項目の実施内容および参照先

実施順序

実施項目

実施内容

参照先

1

前提条件の確認

前提となる構成および設定を確認します。

5.4

2

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

HTTPセッションの属性情報のサイズを見積もります。見積もった値はデータベースの環境設定で必要になります。

5.8.2

(2)　データベースセッションフェイルオーバ機能の設定

データベースセッションフェイルオーバ機能の設定について，設定内容および参照先を次の表に示します。

表6‒3　データベースセッションフェイルオーバ機能の設定内容および参照先

設定順序

設定項目

設定内容

参照先

1

J2EEサーバの設定

次の設定をします。

データベースセッションフェイルオーバ機能の設定（J2EEサーバ単位）

DB Connectorの別名の設定

完全性保障モードの設定

シリアライズ処理で使用するメモリ量の設定

セッションフェイルオーバ抑止機能の設定（拡張子，またはURI単位）

参照専用リクエストの設定

HttpSessionのサーバID付加機能の設定

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

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

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

6.6.1

2

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

次の設定をします。

データベースセッションフェイルオーバ機能の設定（Webアプリケーション単位）

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

アプリケーション識別子の設定

HTTPセッションの属性情報の最大サイズ

拡張子によるセッションフェイルオーバ機能の抑止の設定

6.6.2

注※　Webアプリケーションの設定は開発環境で実施します。サーバ管理コマンドを使用して実行環境でWebアプリケーションの設定をしたい場合は「6.6.2　Webアプリケーションの設定」を参照してください。

(3)　データベースの準備

データベースセッションフェイルオーバ機能を使用する場合にデータベースの準備として実施する項目について，実施内容および参照先を次の表に示します。

表6‒4　データベースの準備として実施する項目の実施内容および参照先

実施順序

実施項目

実施内容

参照先

1

テーブルの作成

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

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

セッション情報格納テーブルの作成

空きレコード情報テーブルの作成

5.8.3，6.6.3(2)，6.6.3(3)，6.6.3(4)

2

データベースの環境設定

次の設定をします。

データベースのタイムアウトの設定

6.6.3(5)

(4)　DB Connectorの設定

データベースセッションフェイルオーバ機能を使用する場合に必要なDB Connectorの設定について，設定内容および参照先を次の表に示します。

表6‒5　DB Connectorの設定内容および参照先

設定順序

設定項目

設定内容

参照先

1

DB Connectorの設定

次の設定をします。

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

DB Connectorの環境設定

DB Connectorの別名の設定

6.6.4

(5)　注意事項

データベースとしてHiRDBを使用する場合，自動コミットを有効にしてください。自動コミットを無効にした場合，データベースセッションフェイルオーバ機能のSQL実行のタイミングでエラーが発生します。

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

ここでは，性能を重視したモードを選択した場合の動作，使用できる機能（グローバルセッション情報の削除），および注意事項について説明します。

性能を重視したモードを選択するには，完全性保障モードの設定を無効にします（デフォルト）。完全性保障モードを無効にすると，同一セッションIDを持つリクエスト処理を同時に実行できるようになります（同一セッションIDの同時実行）。

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

完全性保障モードが無効の場合の動作については，「5.7　セッションフェイルオーバ機能使用時に実行される機能」を参照してください。

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

グローバルセッション情報の有効期限監視は，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コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「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に接続する場合の注意事項は，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.6.7　Oracleと接続する場合の前提条件と注意事項」を参照してください。

6.3.3　注意事項

ここでは，完全性保障モード無効時の注意事項について説明します。

完全性保障モードの切り替え

完全性保障モードを無効から有効に切り替える場合は，次の手順に従って，データベースのセッション情報格納テーブルとアプリケーション情報テーブルを初期化してください。

冗長化したJ2EEサーバをすべて停止する。

HTTPセッションを破棄する。

HTTPセッションの破棄の手順については，「6.7.3　グローバルセッション情報の削除（HTTPセッションの破棄）」を参照してください。

データベースに保存した設定情報を初期化する。

データベースに保存した設定情報を初期化する手順については，「6.7.2　データベーステーブルの初期化」を参照してください。

J2EEサーバ停止時のグローバルセッション情報の有効期限監視

WebアプリケーションまたはJ2EEサーバを停止したときや，J2EEサーバに障害が発生してプロセスダウンしたとき，グローバルセッション情報の有効期限は監視されません。Webアプリケーションの開始，またはリクエストの受信でグローバルセッション情報がJ2EEサーバに引き継がれた時点から，有効期限の監視が開始されます。

なお，完全性保障モードが有効の場合，J2EEサーバが停止したときは別のJ2EEサーバによって有効期限が監視されます。有効期限監視の処理の詳細については，「6.4.3　グローバルセッション情報の有効期限が切れた場合の処理」を参照してください。

グローバルセッション情報の数が上限に達した場合の動作

グローバルセッション情報作成時に，データベース上のグローバルセッション情報の数が上限に達していた場合，HTTPセッションを縮退します。HTTPセッションの縮退については，「5.7.3　HTTPセッションの縮退」を参照してください。

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

データベースセッションフェイルオーバ機能では，次に示す時点でそれぞれ処理が実施されます。

アプリケーション開始時

アプリケーションのネゴシエーション処理が実施されます。

リクエスト実行時

グローバルセッション情報の格納，更新，削除が実施されます。

この節では，データベースセッションフェイルオーバ機能で実施される処理について説明します。

また，グローバルセッション情報の有効期限が切れた場合の処理，データベースセッションフェイルオーバ機能で発生するイベントに関連して動作するリスナ，完全性保障モードの場合にだけ実施されるグローバルセッション情報のロック処理，およびグローバルセッション情報操作中の障害発生時の動作についても説明します。

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

ここでは，アプリケーション開始時に実施されるアプリケーションのネゴシエーション処理，およびアプリケーションのネゴシエーション処理で使用するアプリケーション識別子について説明します。

(1)　アプリケーションのネゴシエーション処理

データベースセッションフェイルオーバ機能を使用するWebアプリケーションでは，アプリケーション開始時にネゴシエーション処理が実行されます。

ネゴシエーション処理では，次の内容が確認されます。

Webアプリケーションが一致していること

各Webアプリケーションの設定が一致していること

J2EEサーバの設定が一致していること

データベースの設定が正しいこと

ネゴシエーション処理の結果によってWebアプリケーションが開始されるかどうかが決まります。

ネゴシエーション処理の結果とWebアプリケーションの状態の関係を次の表に示します。

表6‒6　ネゴシエーション処理の結果と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‒7　Webアプリケーションの一致の確認のために使用される項目

項番

確認項目

1

アプリケーション識別子※

2

J2EEアプリケーション名

3

Webアプリケーション名（コンテキストルート名）

注※　アプリケーション識別子については，「6.4.1(2)　アプリケーション識別子」を参照してください。

各Webアプリケーションの設定が一致していること

次の表に示す確認項目について，冗長化した各Webアプリケーションの設定が一致しているか確認されます。

表6‒8　各Webアプリケーションの設定の一致を確認するための項目

項番

確認項目

1

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

2

グローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズ

3

DD（web.xml）に定義されたHTTPセッションの有効期間

4

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

J2EEサーバの設定が一致していること

次の表に示す確認項目について，冗長化した各J2EEサーバの設定が一致しているか確認されます。

表6‒9　各J2EEサーバの設定の一致を確認するための項目

項番

確認項目

1

完全性保障モードの設定

2

参照専用リクエストの設定

3

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

4

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

データベースの設定が正しいこと

次の表に示す条件を満たしているかが確認されます。

表6‒10　データベースの設定が正しいことを確認するための条件

項番

条件

1

必要なテーブルがデータベースに存在すること。

2

存在するテーブルの内容がデータベースセッションフェイルオーバ機能用のテーブルの内容であること。

3

存在するテーブルがほかのアプリケーションで使用中でないこと。

(b)　ネゴシエーションで確認されるWebアプリケーションの設定内容

最初にネゴシエーション処理に成功したWebアプリケーションの設定内容は，データベースのアプリケーション情報テーブルに保存されます。保存された設定内容はネゴシエーションの確認で使用される，正しい設定情報として扱われます。

このため，Webアプリケーションの設定内容を変更する場合は，すでにデータベースに保存されている，変更対象のWebアプリケーションに関連する設定情報を削除する必要があります。設定の変更手順については，「6.7　データベースセッションフェイルオーバ機能に関する設定の変更」を参照してください。

(2)　アプリケーション識別子

アプリケーション識別子とは，データベースセッションフェイルオーバ機能使用時にクラスタリングされたWebアプリケーションを認識するための名称です。デフォルトの設定では，システムによって自動的に生成されます。

アプリケーション識別子は，ネゴシエーションでWebアプリケーションが一致しているかどうかの確認に使用されます。そのため，次の条件を満たしている必要があります。

冗長化したJ2EEサーバで動作する同一のWebアプリケーションで一致している。

システム内で一意の値である。

システムによって自動的に生成されるアプリケーション識別子が条件を満たさない場合，条件を満たす値を定義する必要があります。定義方法については「6.5　cosminexus.xmlでの定義」を参照してください。

アプリケーション識別子の自動生成規則，および自動生成されるアプリケーション識別子の例について説明します。

注意事項

異なるWebアプリケーションに同じアプリケーション識別子が設定されている場合，二つ目のWebアプリケーション開始時にネゴシエーションに失敗して，Webアプリケーションが開始されません。

(a)　アプリケーション識別子の自動生成規則

デフォルトの設定では，アプリケーション識別子にはコンテキストルート名を基にした文字列が自動的に設定されます。アプリケーション識別子が自動的に生成された場合，Webアプリケーション開始時に，適用した値がKDJE34302-Iのメッセージでメッセージログに出力されます。

コンテキストルート名を基にしたアプリケーション識別子の自動生成には，次に示す規則が適用されます。

先頭のスラッシュ（/）は削除する。

先頭のスラッシュ（/）を除き，文字列長が16文字を超える場合，16文字までの文字列を使用する。

アプリケーション識別子に使用できない文字をコンテキストルート名で使用している場合，アンダースコア（_）に置換する。

アプリケーション識別子に使用できる文字は英数字（A〜Z，a〜z，0〜9），およびアンダースコア（_）だけです。また，設定した値は，大文字小文字が区別されます。

ルートコンテキストの場合，空文字列ではなく，「ROOT」とする。

自動生成規則を適用した結果，アプリケーション識別子がシステム内で一意でなくなる場合があります。この場合，同じアプリケーション識別子が設定されている二つ目のWebアプリケーション開始時にネゴシエーションに失敗して，Webアプリケーションが開始されません。そのため，Webアプリケーションに対してシステム内で一意になるアプリケーション識別子を設定する必要があります。

(b)　自動生成されるアプリケーション識別子の例

コンテキストルート名から自動生成されるデフォルトのアプリケーション識別子の例を次の表に示します。

表6‒11　自動生成されるデフォルトのアプリケーション識別子の例

項番

コンテキストルート名

アプリケーション識別子

作成時に適用されるルール

1

/examples

examples

先頭の"/"を削除する

2

/App01/test1

App01_test1

先頭の"/"を削除する

途中の"/"を"_"に置換する

3

/WebApplication_001

WebApplication_0

先頭の"/"を削除する

17文字以降を削除する

4

/examples/WebApplication

examples_WebAppl

先頭の"/"を削除する

途中の"/"を"_"に置換する

17文字以降を削除する

5

/

ROOT

ルートコンテキストのため"ROOT"とする

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

ここでは，リクエスト実行時のグローバルセッションの作成，更新，削除およびグローバルセッションの引き継ぎについて説明します。

Webアプリケーション内で処理が実行されると，処理の延長でグローバルセッション情報に対しての処理が発生します。Webアプリケーション内で実行される処理の例と，例に対応したリクエスト実行時のグローバルセッション情報に対して実行される処理，および参照先を次の表に示します。

表6‒12　Webアプリケーション内での処理の例とグローバルセッション情報に対して実行される処理の対応

項番

Webアプリケーション内で実行される処理の例

グローバルセッション情報に対して実行される処理

参照先

1

ログイン

グローバルセッション情報の作成

(1)

2

業務の実行（ページ遷移/更新）

グローバルセッション情報の更新

(2)

3

ログアウト

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

(3)

4

タイムアウトによるログアウト

有効期限切れによるグローバルセッション情報の削除

6.4.3

5

別のJ2EEサーバにグローバルセッションを引き継いでの業務の実行

（J2EEサーバでの障害発生時）

グローバルセッション情報を使用したセッション情報の引き継ぎ

(4)

グローバルセッション情報操作中に障害が発生した場合の処理結果については，「6.4.6　グローバルセッション情報操作中の障害発生時の動作」を参照してください。

(1)　グローバルセッション情報の作成

J2EEサーバ上で新規にHTTPセッションが作成されると，データベース上にグローバルセッション情報が作成されます。

グローバルセッション情報の作成で実行される処理の流れを次の図に示します。

図6‒2　グローバルセッション情報の作成（データベースセッションフェイルオーバ機能）

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セッションの縮退については，「5.7.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については，マニュアル「アプリケーションサーバリファレンス API編」の「3.1　例外クラス」を参照してください。

(2)　グローバルセッション情報の更新

Webアプリケーション実行中にセッションが更新されると，J2EEサーバでHTTPセッションが更新されます。それに伴って，データベース上のグローバルセッション情報も更新されます。

グローバルセッション情報の更新で実行される処理の流れを次の図に示します。

図6‒3　グローバルセッション情報の更新（データベースセッションフェイルオーバ機能）

HTTPセッションが存在するリクエストを受信します。

完全性保障モードが有効の場合，Webアプリケーション実行前にデータベース上のグローバルセッション情報がロックされます。

Webアプリケーションでのセッションの更新に伴って，HTTPセッションが更新されます。

HTTPセッションの更新によって，データベース上のグローバルセッション情報が最新の情報に更新されます。

完全性保障モードが有効の場合，ロックが解除されます。

グローバルセッション情報のロック時の動作については，「6.4.5(1)　ロック取得時のロック取得処理の呼び出し結果」を参照してください。

(3)　グローバルセッション情報の削除

Webアプリケーション内でのセッションの削除処理で，javax.servlet.http.HttpSessionインタフェースのinvalidate()メソッドを実装して明示的にHTTPセッションを削除すると，その処理の延長でデータベース上のグローバルセッション情報が削除されます。

グローバルセッション情報の削除で実行される処理の流れを次の図に示します。

図6‒4　グローバルセッション情報の削除（データベースセッションフェイルオーバ機能）

HTTPセッションの削除が必要なリクエストを受信します。

完全性保障モードが有効の場合，Webアプリケーション実行前にデータベース上のグローバルセッション情報がロックされます。

Webアプリケーションでのセッションの削除に伴って，HTTPセッションが削除されます。

HTTPセッションの削除によって，データベース上のグローバルセッション情報および空きレコード情報が削除されます。

完全性保障モードが有効の場合，ロックが解除されます。

(4)　グローバルセッション情報を使用したセッション情報の引き継ぎ

受信したリクエストに関連づけられたHTTPセッションがJ2EEサーバ上に存在しない場合，データベース上のグローバルセッション情報を使用してHTTPセッションが再作成されます。これによってセッションが引き継げます。

グローバルセッション情報を使用したセッション情報の引き継ぎで実行される処理の流れを次の図に示します。

図6‒5　グローバルセッション情報を使用したセッション情報の引き継ぎ（データベースセッションフェイルオーバ機能）

受信したリクエストに関連づけられたHTTPセッションがJ2EEサーバ上に存在しない場合，データベース上のグローバルセッション情報を呼び出して，J2EEサーバ上にHTTPセッションが再作成されます。

再作成されたHTTPセッションによってセッションが引き継がれ，Webアプリケーションでセッションの更新処理が実行されます。セッションの更新処理の延長上で，HTTPセッションが更新されます。

HTTPセッションの更新に伴って，グローバルセッション情報が更新されます。

なお，グローバルセッション情報の引き継ぎができた場合，KDJE34321-Iのメッセージがメッセージログに出力されます。クライアントから受信したセッションIDに対応するグローバルセッション情報がデータベース上に存在しないためにグローバルセッション情報の引き継ぎができなかった場合，KDJE34325-Wのメッセージがメッセージログに出力されます。

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

HTTPセッションにはそれぞれ有効期限が設定されています。最終アクセス時刻の情報を基にした有効期限確認の結果，有効期限を超過しているHTTPセッションは削除されます。HTTPセッションが有効期限の超過によって削除されると，その処理の延長で，対応するグローバルセッション情報も削除されます。

HTTPセッションの有効期限は，Webコンテナに存在する有効期限監視スレッドによって定期的に監視されています。有効期限監視スレッドはWebアプリケーションごとに存在しています。

有効期限切れによるグローバルセッション情報の削除で実行される処理の流れを次の図に示します。

図6‒6　グローバルセッション情報の有効期限が切れた場合の処理（データベースセッションフェイルオーバ機能）

完全性保障モードが有効の場合，有効期限監視スレッドによって有効期限切れであると判断されたセッションについて，対応するグローバルセッション情報がロックされます。

セッションの削除処理の延長で，HTTPセッションが削除されます。また，HTTPセッションの削除によって，データベース上のグローバルセッション情報および空きレコード情報が削除されます。

完全性保障モードが有効の場合，ロックが解除されます。

6.4.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‒13　データベースセッションフェイルオーバ機能で発生するイベントと動作するリスナ

項番

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.4.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はありません。データベースセッションフェイルオーバ機能の抑止については，「5.6.1　セッションフェイルオーバ機能の抑止」を参照してください。

データベースセッションフェイルオーバ機能では，異なるJ2EEサーバではなく，一つのJ2EEサーバに対して送信されるスレッド間でもグローバルセッションのロックは有効です。セッションIDが同一である複数のリクエストが一つのJ2EEサーバに送信された場合，受信したリクエストから順に一つずつ処理されます。あとで受信したリクエストは，先に受信したリクエストの処理が終わるのを待ってから，処理を開始します。

注意事項

フレームなどを使用した，HTTPセッションを使用する複数の動的ページを組み合わせたコンテンツの更新などによって，WebクライアントからセッションIDが同一である複数のリクエストが送信される場合があります。この場合，受信したリクエストから順に一つずつ処理されます。その結果，データベースセッションフェイルオーバ機能を使用しない場合に比べ，処理性能が低下するおそれがあります。

(1)　ロック取得時のロック取得処理の呼び出し結果

データベース上のグローバルセッション情報の状態によってロック取得処理の呼び出し結果が異なります。グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係を次の表に示します。

表6‒14　グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番

データベース上のグローバルセッション情報の状態

ロック取得処理の呼び出し結果

出力されるメッセージ

1

存在し，ロック中ではない（正常時）。

データベース上のグローバルセッション情報がロックされます（正常終了）。

出力されない

2

存在しない。

タイムアウトで無効化したセッション，または無効なセッションIDのセッションを対象にしていると判断されます。そのため，J2EEサーバ内のHTTPセッションが削除されます。

その結果，Webアプリケーションは，HTTPセッションが存在しない状態で実行されます。

KDJE34315-W

3

存在するが，ほかのJ2EEサーバで更新され，J2EEサーバ内のHTTPセッションの情報よりも新しい。

ほかのJ2EEサーバで使用されたグローバルセッション情報であると判断されます。そのため，データベース上のグローバルセッション情報の内容が引き継がれます（セッションの引き継ぎ※1発生）。

KDJE34322-I※2

4

存在し，使用されているためロック中である。

ロック待ち※3が発生します。HTTPセッション使用中のリクエストの処理が終了したあとでロックが取得され，Webアプリケーションが開始されます。

出力されない

注※1

セッションの引き継ぎについては「6.4.2(4)　グローバルセッション情報を使用したセッション情報の引き継ぎ」を参照してください。

注※2

Warningレベルで出力されます。

注※3

ロック待ちについては「6.4.5(2)　ロック待ち」を参照してください。

(2)　ロック待ち

ロック対象となっているグローバルセッション中のHTTPセッションを使用するリクエストを受信すると，ロックの取得を待つ必要があります。ロックの取得を待っている状態を，グローバルセッション情報のロック待ちといいます。また，ロック待ちが原因で発生するタイムアウトのことを，ロックタイムアウトといいます。

ロック待ち発生後のグローバルセッション情報の状態と，ロック取得処理の呼び出し結果の関係を次の表に示します。

表6‒15　ロック待ち発生後のグローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番

ロック待ち発生後のグローバルセッション情報の状態

ロック待ち発生後のロック取得処理の呼び出し結果

出力されるメッセージ

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クラスの詳細については，マニュアル「アプリケーションサーバリファレンス API編」の「3.1　例外クラス」を参照してください。

(3)　J2EEサーバでの障害発生時のグローバルセッション情報のロック

Webアプリケーション実行中のJ2EEサーバで，OSのハングアップやネットワークの障害などが発生すると，データベース上でロック中のグローバルセッション情報が一時的にロックされたままの状態となる場合があります。

ロックされたままの状態から回復するには，次のどちらかの対処が必要です。

データベースに，クライアントからの接続を監視する設定，および接続の切断を検知して回復する設定をする。

この設定をすると，データベースの機能によって一定時間後にJ2EEサーバからの接続の切断が検知され，自動的にロックが解除されます。さらに，切断が検知されたタイミングで，ロック取得前の状態に戻ります。HiRDBを使用する場合，UAP処理時間監視機能を設定してください。UAP処理時間監視機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

データベースの定期的なメンテナンスをする。

データベースの設定，運用については使用するデータベースのマニュアルを参照してください。

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

グローバルセッション情報の操作中の障害発生時の動作について説明します。ここでは，グローバルセッション情報の操作ごとに，障害が発生したポイント，セッションの状態，ほかのリクエストへの影響，および出力されるメッセージについて説明します。

(1)　グローバルセッション情報の作成時に障害が発生した場合の動作

グローバルセッション情報の作成時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報の作成処理の流れと障害発生のポイントを次の図に示します。

図6‒8　グローバルセッション情報の作成処理の流れと障害発生のポイント

以降の説明では，図中の数字（J2EEサーバの障害発生ポイント）またはアルファベット（データベースの障害発生ポイント）と，表中の障害発生ポイントの数字またはアルファベットが対応しています。

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報の作成時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作を次の表に示します。

表6‒16　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

J2EEサーバのHTTPセッション

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

1

作成されない

作成されない

なし

2

作成されない

作成されない（ロールバック）※1

データベースがクライアント接続を検知するまでの間，すべてのHTTPセッションの新規作成はできない

3

作成されない

作成される※2

なし

4

プロセスダウンによって消滅

作成される※2

なし

注※1　SQLExceptionが発生し，リクエスト受信前の状態にロールバックします。

注※2　この状態のグローバルセッション情報の引き継ぎはできません。有効期限が切れると，有効期限監視によって削除されます。

(b)　データベース障害発生時の動作（SQLExceptionが発生した場合）

グローバルセッション情報の作成時にデータベース障害が発生し，SQLExceptionが発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6‒17　データベース障害でSQLExceptionが発生した場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

縮退して作成される※1

作成されない

なし

正常終了

KDJE34368-W

B〜F

縮退して作成される※1

作成されない（ロールバック）※2

なし

正常終了

KDJE34368-W

G

−

−

−

−

−

H

−

−

−

−

−

（凡例）−：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　SQLExceptionが発生し，リクエスト受信前の状態にロールバックします。

表6‒18　データベース障害で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‒19　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

縮退して作成される※1

作成されない

なし

正常終了

KDJE34368-W

B〜F

縮退して作成される※1

作成されない（ロールバック）※2

ロック解放待ちでタイムアウトするまでの間，すべてのHTTPセッションの新規作成はできない

正常終了

KDJE34368-W

G

−

−

−

−

−

H

−

−

−

−

−

（凡例）−：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

表6‒20　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

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‒21　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

J2EEサーバのHTTPセッション

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

1

プロセスダウンによって消滅

更新されない

なし

2

プロセスダウンによって消滅

更新されない（ロールバック）※

データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

3

プロセスダウンによって消滅

更新されない（ロールバック）※

データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

4

プロセスダウンによって消滅

更新されない（ロールバック）※

データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

注※　SQLExceptionが発生し，リクエスト受信前の状態にロールバックします。

(b)　データベース障害発生時の動作（SQLExceptionが発生した場合）

グローバルセッション情報の更新時にデータベース障害が発生し，SQLExceptionが発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6‒22　データベース障害でSQLExceptionが発生した場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

縮退して更新される※

更新されない

なし

正常終了

KDJE34368-W

B

−

−

−

−

−

C

縮退して更新される※

更新されない

なし

−

KDJE34368-W

D

−

−

−

−

−

（凡例）−：該当なし

注※　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

表6‒23　データベース障害で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‒24　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

縮退して更新される※1

更新されない

なし

正常終了

KDJE34368-W

B

−

−

−

−

−

C

縮退して更新される※1

更新されない（ロールバック）※2

ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない

−

KDJE34368-W

D

−

−

−

−

−

（凡例）−：該当なし

注※1　縮退したHTTPセッションは，次回リクエスト受信時のグローバルセッション情報の更新処理でデータベースに更新されます。

注※2　データベースのロック解放待ちのタイムアウトが発生し，リクエスト受信前の状態にロールバックします。

表6‒25　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

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‒26　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

J2EEサーバのHTTPセッション

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

1

プロセスダウンによって消滅

削除されない

なし

2

プロセスダウンによって消滅

削除されない（ロールバック）※

データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

3

プロセスダウンによって消滅

削除されない（ロールバック）※

データベースがクライアント接続を検知するまでの間，該当するHTTPセッションの操作はできない

4

プロセスダウンによって消滅

削除されている

なし

注※　SQLExceptionが発生し，リクエスト受信前の状態にロールバックします。

(b)　データベース障害発生時の動作（SQLExceptionが発生した場合）

グローバルセッション情報の削除時にデータベース障害が発生し，SQLExceptionが発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6‒27　データベース障害で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‒28　データベース障害で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‒29　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

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‒30　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

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‒31　J2EEサーバ障害発生時の動作（プロセスダウン）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

J2EEサーバのHTTPセッション

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

1

プロセスダウンによって消滅

削除されない

なし

2，3

プロセスダウンによって消滅

削除されない（ロールバック）

データベースがクライアントの切断を検知するまでの間，該当するHTTPセッションの操作はできない

(b)　データベース障害発生時の動作（SQLExceptionが発生した場合）

有効期限切れによるグローバルセッション情報の削除時にデータベース障害が発生し，SQLExceptionが発生した場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6‒32　データベース障害でSQLExceptionが発生した場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

−

−

−

−

−

B〜E

削除される

削除されない（ロールバック）

なし

−

KDJE34377-E※

（凡例）−：該当なし

注※　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

表6‒33　データベース障害でSQLExceptionが発生した場合の動作（完全性保障モード有効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

削除される

削除されない（ロールバック）

なし

−

KDJE34336-W

B〜E

削除される

削除されない（ロールバック）

なし

−

KDJE34312-W

（凡例）−：該当なし

(c)　データベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）

有効期限切れによるグローバルセッション情報の削除時にデータベース障害が発生し，データベースが無応答またはスローダウンした場合の動作を次の表に示します。なお，完全性保障モード無効時と有効時とでは動作が異なります。

表6‒34　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード無効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

−

−

−

−

−

B〜E

削除される

削除されない（ロールバック）

ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない

−

KDJE34377-E※

（凡例）−：該当なし

注※　初めての障害発生時にだけメッセージが出力されます。それ以降はWebアプリケーションを再開始するまで同じ障害ではメッセージは出力されません。

表6‒35　データベース障害で無応答またはスローダウンしている場合の動作（完全性保障モード有効時）

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

A

削除される

削除されない（ロールバック）

ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない

−

KDJE34336-W

B〜E

削除される

削除されない（ロールバック）

ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない

−

KDJE34312-W

（凡例）−：該当なし

(5)　グローバルセッション情報を使用したグローバルセッション引き継ぎ時に障害が発生した場合の動作

グローバルセッション情報を使用したグローバルセッション引き継ぎ時に，J2EEサーバ障害またはデータベース障害が発生した場合の動作について説明します。

グローバルセッション情報を使用したグローバルセッション引き継ぎ処理の流れと障害発生のポイントを次の図に示します。

図6‒12　グローバルセッション情報を使用したグローバルセッション引き継ぎ処理の流れと障害発生のポイント

(a)　J2EEサーバ障害発生時の動作（プロセスダウン）

グローバルセッション情報を使用したグローバルセッション引き継ぎ時にJ2EEサーバ障害が発生し，プロセスダウンした場合の動作は，グローバルセッション情報の更新時にJ2EEサーバ障害が発生した場合と同じ動作になります。

グローバルセッション情報の更新時にJ2EEサーバ障害が発生した場合の動作については，「6.4.6(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のJ2EEサーバ障害発生時の動作を参照してください。

(b)　データベース障害発生時の動作（SQLExceptionが発生した場合）

グローバルセッション情報を使用したグローバルセッション引き継ぎ時の，図中Cの処理中にデータベース障害が発生し，SQLExceptionが発生した場合の動作を次の表に示します。図中A，B，D，Eの処理中に障害が発生した場合の動作は，グローバルセッション情報の更新時にデータベースでSQLExceptionが発生した場合と同じ動作になります。

グローバルセッション情報の更新時にデータベース障害でSQLExceptionが発生した場合の動作については，「6.4.6(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のデータベース障害発生時の動作（SQLExceptionが発生した場合）を参照してください。

表6‒36　データベース障害で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の処理中に障害が発生した場合の動作は，グローバルセッション情報の更新時にデータベースが無応答またはスローダウンした発生した場合と同じ動作になります。

グローバルセッション情報の更新時にデータベース障害で無応答またはスローダウンした場合の動作については，「6.4.6(2)　グローバルセッション情報更新時に障害が発生した場合の動作」のデータベース障害発生時の動作（データベースが無応答またはスローダウンしている場合）を参照してください。

表6‒37　データベース障害で無応答またはスローダウンしている場合の動作

障害発生ポイント

セッションの状態

ほかのリクエストへの影響

Webアプリケーションの動作

メッセージ

J2EEサーバのHTTPセッション

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

C

引き継がれない

引き継がれない

ロック解放待ちでタイムアウトするまでの間，該当するHTTPセッションの操作はできない

HTTPセッションの取得時に例外が発生※

KDJE34314-W

注※　Servletの場合はjavax.servlet.http.HttpServletRequestインタフェースのgetSessionメソッドの呼び出しで，JSPの場合はユーザコードが実行される前に，com.hitachi.software.web.dbsfo.DatabaseAccessExceptionが発生します。

6.5　cosminexus.xmlでの定義

データベースセッションフェイルオーバ機能を使用するための定義は，cosminexus.xmlの<war>タグ内に指定します。

cosminexus.xmlでのデータベースセッションフェイルオーバ機能の定義について次の表に示します。

表6‒38　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アプリケーション単位で有効にする場合に，データベースセッションフェイルオーバ機能を抑止する拡張子を設定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.6　War属性の詳細」を参照してください。

6.6　実行環境での設定

6.6.1　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。データベースセッションフェイルオーバ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのデータベースセッションフェイルオーバ機能の定義について次の表に示します。

表6‒39　簡易構築定義ファイルでのデータベースセッションフェイルオーバ機能の定義

項目

指定するパラメタ

設定内容

参照先

データベースセッションフェイルオーバ機能の設定

webserver.dbsfo.enabled

J2EEサーバ単位でデータベースセッションフェイルオーバ機能を使用するかどうかを設定します。

−

DB Connectorの別名の設定

webserver.dbsfo.connector.name

DB Connectorで設定する，DB Connectorの別名を指定します。

DB Connectorの別名の設定については「6.6.4(2)　DB Connectorの別名の設定」を参照してください。

−

グローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズの設定

webserver.dbsfo.attribute_data_size.max

グローバルセッション情報に含めることができるHTTPセッションの属性情報の最大サイズを設定します。

−

HTTPセッションの属性情報のサイズ見積もり機能の設定

webserver.dbsfo.check_size.mode

HTTPセッションの属性情報のサイズ見積もり機能を使用するかどうかを設定します。

−

完全性保障モードの設定

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サーバごとに異なる値を設定します※3。

−

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

webserver.dbsfo.thread_control_queue.enabled

Webアプリケーション単位の同時実行スレッド数制御機能が有効の場合に，実行待ちキューの空きが不足したときの動作を設定します。

−

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

webserver.dbsfo.negotiation.high_level

ネゴシエーションが失敗した場合にWebアプリケーションの開始処理を続行するか中止するかを設定します。

−

データベースセッションフェイルオーバ機能の抑止対象リクエスト内でHTTPセッションを使用した場合にスローされる例外の設定

webserver.dbsfo.exception_type_backcompat

データベースセッションフェイルオーバ機能の抑止対象リクエスト内でHTTPセッションを使用した場合に発生する例外を設定します。

−

（凡例）−：該当なし。

注※1　完全性保障モードの設定でwebserver.dbsfo.integrity_mode.enabledパラメタにfalseを指定した場合，HttpSessionのサーバID付加機能の設定でwebserver.session.server_id.enabledパラメタ，およびwebserver.session.server_id.valueパラメタを指定する必要があります。

注※2　シリアライズ処理で使用するメモリ量の見積もり方法については，「5.8.1　シリアライズ処理で使用するメモリの見積もり」を参照してください。JavaVMのチューニングについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

注※3　実行系と待機系による系切り替えシステムの場合，実行系と待機系の値は同じにしてください。

簡易構築定義ファイル，および指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(1)　データベースセッションフェイルオーバ機能の抑止の設定

ここでは，URI単位のデータベースセッションフェイルオーバ機能の抑止をする場合の，URIの指定方法について説明します。

(a)　URIの指定方法

コンテキストパスを含む「/」(スラッシュ)で始まるURIを指定します。パスパラメタ，クエリ，およびフラグメントは含みません。なお，設定値のURI中に「;」（セミコロン）を使用することはできません。

また，複数のURIを指定する場合は，「;」（セミコロン）で区切って指定してください。

(b)　完全一致指定とプリフィックス一致指定

次のどちらかで指定できます。

完全一致指定

指定した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*

(c)　URIの正規化

データベースセッションフェイルオーバ機能の抑止対象とするURIは，正規化して指定する必要があります。正規化していないURIを指定した場合，KDJE34341-Wのメッセージが出力されて，該当するURIは抑止の対象外になります。

正規化したURIの例を次に示します。

/examples/test/servlet/TestServlet

正規化していないURIの例を次に示します。これらのURIは抑止の対象外になります。

/examples/test/jsp/../servlet/TestServlet

/examples/test/./servlet/TestServlet

(d)　URLエンコードとの対応

URLエンコードをしたURIを抑止対象として指定した場合は，指定したURIと一致する，URLエンコードされたURLのリクエストがデータベースセッションフェイルオーバ機能の抑止対象になります。同様に，URLエンコードをしないURIを指定した場合は，URLエンコードされていないURLのリクエストがデータベースセッションフェイルオーバ機能の抑止対象になります。

ただし，URIのデコード機能を使用する場合，対象のURLは，デコードが実施されたあとでURIによるデータベースフェイルオーバ機能の抑止の対象かどうかが判定されます。このため，URLエンコードされたURLが抑止対象として指定したURIと一致する場合に，URI単位のデータベースセッションフェイルオーバ機能の抑止対象になります。

URIのデコード機能の有効・無効によって抑止の対象となるURLについて，次の表に示します。

表6‒40　URIのデコード機能の有効・無効によって抑止の対象となるURL

プロパティ

設定値

リクエストURL

URIのデコード機能 有効

URIのデコード機能 無効

エンコードあり

エンコードなし

エンコードあり

エンコードなし

エンコードあり

抑止しない

抑止しない

抑止する

抑止しない

エンコードなし

抑止する

抑止する

抑止しない

抑止する

（凡例）

抑止する：データベースセッションフェイルオーバ機能を抑止する（データベースセッションフェイルオーバ機能が無効になる）。

抑止しない：データベースセッションフェイルオーバ機能を抑止しない（データベースセッションフェイルオーバ機能が有効になる）。

エンコードあり：URLエンコードされた文字列を含むURI。

（例：/examples/%61/Servlet）

エンコードなし：URLエンコードされた文字列を含まないURI。

（例：/examples/a/Servlet）

(e)　URI指定時の注意事項

URIによるデータベースセッションフェイルオーバ機能の抑止で設定するURIは，ネゴシエーション時に確認される項目ではありません。このため，それぞれのJ2EEサーバで設定するURIが同じことを確認してください。

(2)　参照専用リクエストの設定

ここでは，参照専用リクエストを設定する場合の，URIの指定方法について説明します。

(a)　URIの指定方法

コンテキストパスを含む「/」(スラッシュ)で始まるURIを指定します。パスパラメタ，クエリ，およびフラグメントは含みません。指定できる文字数は512文字までです。なお，設定値のURI中に「;」（セミコロン）を使用することはできません。

また，複数のURIを指定する場合は，「;」（セミコロン）で区切って指定してください。

(b)　完全一致指定とプリフィックス一致指定

次のどちらかで指定できます。

完全一致指定

指定した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*

(c)　URIの正規化

参照専用リクエストとするURIは，正規化して指定する必要があります。正規化していないURIを指定した場合，KDJE34357-Wのメッセージが出力されて，該当するURIは参照専用リクエストになりません。

正規化したURIの例を次に示します。

/examples/test/servlet/TestServlet

正規化していないURIの例を次に示します。これらのURIは参照専用リクエストになりません。

/examples/test/jsp/../servlet/TestServlet

/examples/test/./servlet/TestServlet

(d)　URLエンコードとの対応

URLエンコードをしたURIを参照専用リクエストとして指定した場合は，指定したURIと一致する，URLエンコードされたURLのリクエストが参照専用リクエストになります。同様に，URLエンコードをしないURIを指定した場合は，URLエンコードされていないURLのリクエストが参照専用リクエストになります。

ただし，URIのデコード機能を使用する場合，対象のURLは，デコードが実施されたあとでURIによる参照専用リクエストかどうかが判定されます。このため，URLエンコードされたURLが参照専用リクエストとして指定したURIと一致する場合に，URI単位の参照専用リクエストになります。

URIのデコード機能の有効・無効によって参照専用リクエストになるURLについて，次の表に示します。

表6‒41　URIのデコード機能の有効・無効によって参照専用リクエストになるURL

プロパティ

設定値

リクエストURL

URIのデコード機能 有効

URIのデコード機能 無効

エンコードあり

エンコードなし

エンコードあり

エンコードなし

エンコードあり

参照専用リクエストにならない

参照専用リクエストにならない

参照専用リクエストになる

参照専用リクエストにならない

エンコードなし

参照専用リクエストになる

参照専用リクエストになる

参照専用リクエストにならない

参照専用リクエストになる

（凡例）

参照専用リクエストになる：リクエストURLが参照専用リクエストになる。

参照専用リクエストにならない：リクエストURLが参照専用リクエストにならない。

エンコードあり：URLエンコードされた文字列を含むURI。

（例：/examples/%61/Servlet）

エンコードなし：URLエンコードされた文字列を含まないURI。

（例：/examples/a/Servlet）

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

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。データベースセッションフェイルオーバ機能の定義には，WAR属性ファイルを使用します。

WAR属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「6.5　cosminexus.xmlでの定義」を参照してください。

6.6.3　データベースの設定

この節では，データベースセッションフェイルオーバ機能を使用する場合に必要となる，テーブルの作成，および環境設定について説明します。

注意事項

テーブルを作成する際，テンプレートファイルについてここで説明しない変更をした場合，データベースセッションフェイルオーバ機能の動作は保障されません。

(1)　データベース接続に必要な権限

データベースのテーブルを操作するには権限が必要です。また，条件を満たす必要があります。データベースごとのテーブルの操作に必要な権限および条件について説明します。ここでは，データベースに接続するユーザのことをデータベース接続ユーザといいます。

HiRDBの場合

ここでは，データベース接続ユーザが，データベースセッションフェイルオーバ機能で使用するテーブルに関するすべての操作を実施することを想定しています。データベース接続ユーザは，次の権限および条件を満たす必要があります。

スキーマを所有すること。

CONNECT権限を持つこと。

データベース接続ユーザのスキーマに，データベースセッションフェイルオーバ機能が使用するテーブル，インデックスおよびストアドプロシジャを作成すること。

データベースのテーブルの作成の詳細については，「6.6.3(2)　データベースのテーブルの作成」を参照してください。データベースのテーブルの削除の詳細については，「6.8　データベースのテーブルの削除」を参照してください。

Oracleの場合

ここでは，データベースセッションフェイルオーバ機能が使用するデータベースのテーブルの作成または削除の操作はデータベース管理者が実施し，そのほかの通常の運用で必要となるデータベースの操作は，データベースセッションフェイルオーバ機能のデータベース接続ユーザが実施することを想定しています。データベース接続ユーザは，次の権限および条件を満たす必要があります。

CREATE SESSIONシステム権限を持つこと。

データベース接続ユーザのスキーマに，データベースセッションフェイルオーバ機能が使用するテーブル，インデックスおよびストアドプロシジャを作成すること。

データベースのテーブルの作成の詳細については，「6.6.3(2)　データベースのテーブルの作成」を参照してください。データベースのテーブルの削除の詳細については，「6.8　データベースのテーブルの削除」を参照してください。

(2)　データベースのテーブルの作成

データベースセッションフェイルオーバ機能では，データベース上に3種類のテーブルを作成する必要があります。作成するテーブルと，作成手順の参照先について次の表に示します。

表6‒42　作成するテーブルと，作成手順の参照先

テーブル名

データベース上の物理名称

作成手順の参照先

アプリケーション情報テーブル

SFO_<APPLICATION_ID>_APP_INFO

6.6.3(3)

セッション情報格納テーブル

SFO_<APPLICATION_ID>_SESSIONS

6.6.3(4)

空きレコード情報テーブル

SFO_<APPLICATION_ID>_REC_INFO

データベースセッションフェイルオーバ機能で使用するデータベースのテーブル作成用のテンプレートファイルは次の場所に格納されています。

Windowsの場合：

<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥

UNIXの場合：

/opt/Cosminexus/CC/sfo/sql/

テーブル作成用のテンプレートファイルは使用するデータベースごとに2種類ずつあります。使用するデータベース，ファイル，および作成するテーブルの種類の対応を次の表に示します。

表6‒43　テーブル作成用テンプレートファイルと作成するテーブル

使用するデータベース

テンプレートファイル

作成するテーブルの種類

アプリケーション情報テーブル

セッション情報格納テーブル

空きレコード情報テーブル

HiRDB

hirdb_create_apptbl.sql

○

−

hirdb_create_sessiontbl.sql

−

○

Oracle

oracle_create_apptbl.sql

○

−

oracle_create_sessiontbl.sql

−

○

（凡例）○：作成できる　−：作成できない

以降で，使用するデータベースごとにテンプレートファイルの詳細について示します。

また，DB Connectorに設定するユーザには，テーブルの作成者を登録してください。

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

アプリケーション情報テーブルは，Webアプリケーションに設定したデータベースセッションフェイルオーバ機能に関する設定を格納するテーブルです。

アプリケーション情報テーブルの作成手順を次に示します。

テンプレートファイルを任意の場所にコピーします。

テーブル作成用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_create_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_create_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_create_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_create_apptbl.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル作成用SQLファイルを作成します。

テンプレートファイル内の変更個所と変更内容を次の表に示します。

表6‒44　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

HiRDB

Oracle

1行目

5行目

1行目

5行目

<APPLICATION_ID>

使用するアプリケーションのアプリケーション識別子に変更してください。

なし

1行目

5行目

<SCHEMA_NAME>

データベース接続ユーザのスキーマ名に変更してください。

6行目

6行目

<HTTP_SESSION_NO>

データベースに格納するグローバルセッション情報の数に変更してください。

作成したテーブル作成用SQLファイルを実行します。

SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

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

セッション情報格納テーブルは，グローバルセッション情報を格納するテーブルです。空きレコード情報テーブルは，セッション情報格納テーブルの未使用レコードを管理するテーブルです。セッション情報格納テーブルおよび空きレコード情報テーブルは，一つのテーブル作成用のSQLファイルを実行することで同時に作成されます。

セッション情報格納テーブルおよび空きレコード情報テーブルの作成手順を次に示します。

テンプレートファイルを任意の場所にコピーします。

テーブル作成用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_create_sessiontbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_create_sessiontbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_create_sessiontbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_create_sessiontbl.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル作成用SQLファイルを作成します。

テンプレートファイル内の，使用するデータベースごとの変更個所と変更内容について次の表に示します。

表6‒45　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

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>

データベースに格納するグローバルセッション情報の数に変更してください。

作成したテーブル作成用SQLファイルを実行します。

SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

(5)　データベースの環境設定

データベースセッションフェイルオーバ機能を使用する場合，データベースにはタイムアウト（HiRDBの場合UAP処理時間監視機能）の設定をしてください。

データベースセッションフェイルオーバ機能が有効の場合，機能の処理の中で操作対象となるデータベースのテーブルのレコードが排他制御されます。そのため，J2EEサーバのホストでの障害発生時などに，操作対象となっていたレコードが排他されたままになる場合があります。このとき，HTTPセッションの新規作成や，J2EEサーバとデータベースとの接続に失敗するおそれがあります。

タイムアウトの設定をしておくと，このような状況を検知してタイムアウト時にトランザクションがロールバックされ，レコードが排他制御される前の状態に戻るため，システムへの影響はなくなります。

なお，誤動作を防ぐために，データベースのタイムアウトの値にはDB Connectorに設定するタイムアウトの値よりも大きな値を設定してください。データベースの設定内容，手順については，HiRDBを使用する場合はマニュアル「HiRDB UAP開発ガイド」を，Oracleを使用する場合はOracleのマニュアルを参照してください。

レコードが排他制御される処理，処理中に操作対象となるテーブル，処理中にJ2EEサーバで障害が発生した場合のシステムへの影響，および出力されるメッセージを次の表に示します。

表6‒46　レコードが排他制御される処理と処理中に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.6.4　DB Connectorの設定

データベースセッションフェイルオーバ機能を使用する場合，アプリケーションで使用するものとは別に，DB Connectorを新規に作成します。DB Connectorは，J2EEサーバごとに一つ必要です。データベースセッションフェイルオーバ機能を使用するアプリケーションは，すべて同一のDB Connectorを使用します。

DB Connectorのインポートから開始までの手順については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。

この節では，データベースセッションフェイルオーバ機能で使用するDB Connectorに必要な次の設定について説明します。

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

DB Connectorの別名の設定

DB Connectorの環境設定

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

データベースセッションフェイルオーバ機能ではトランザクションサポートのレベルを設定する必要があります。Connector属性ファイルの<hitachi-connector-property>-<resourceadapter>-<outbound-resourceadapter>タグ以下の<transaction-support>タグにNoTransactionを指定します。

(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の別名の設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

また，J2EEサーバに定義するDB Connectorの別名も同じ値に変更する必要があります。J2EEサーバのDB Connectorの別名の設定については「6.6.1　J2EEサーバの設定」を参照してください。

(3)　DB Connectorの環境設定

データベースセッションフェイルオーバ機能は24時間連続稼働を実現するための機能です。連続稼働を実現するには，データベースに障害が発生した場合もシステムに影響を与えないために，コネクションの障害検知などの設定が必要です。障害回復に必要な時間を考慮して，値を設定してください。

コネクションの障害検知については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.1　コネクションの障害検知」を参照してください。

DB Connectorに設定するプロパティおよび設定方法の詳細については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。

DB Connectorに設定が必要なプロパティについて説明します。

(a)　<config-property>タグで設定するプロパティ

<config-property>タグで設定するプロパティについて使用するデータベースごとに示します。なお，ここで示していないプロパティについては，データベースセッションフェイルオーバ機能に関する設定は不要です。

注意事項

データベースセッションフェイルオーバ機能を使用する場合，ステートメントプーリングを設定する必要があります。ステートメントプーリングは，J2EEサーバのメモリ使用量に大きく影響を与えます。そのため，コネクションプーリングの設定も考慮して，PreparedStatementPoolSizeプロパティの指定値を決定してください。

ステートメントプーリングについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.4　ステートメントプーリング」を参照してください。コネクションプーリングについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.1　コネクションプーリング」を参照してください。PreparedStatementPoolSizeプロパティに指定できる値については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.10　DB Connectorに設定する<config-property>タグに指定できるプロパティ」を参照してください。なお，ステートメント一つ当たりの使用するメモリサイズについては，JDBC関連ドキュメントを参照してください。

●HiRDBを使用する場合に設定するプロパティ

HiRDBを使用する場合に設定するプロパティについて次の表に示します。

表6‒47　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

PDDBLOG

ALL

●Oracleを使用する場合に設定するプロパティ

Oracleを使用する場合に設定するプロパティについて次の表に示します。

表6‒48　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の値を指定してください。

(b)　<property>タグに指定するプロパティ

<property>タグで設定するプロパティについて次の表に示します。なお，ここで示していないプロパティについては，データベースセッションフェイルオーバ機能に関する設定は不要です。

表6‒49　<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コンテナからのデータ受信のタイムアウトとは，ProxyPassディレクティブのtimeoutキーまたはTimeoutディレクティブに指定した値です。

Webサーバを経由しないでJ2EEサーバに直接リクエストを送受信する場合

1 < RequestQueueTimeout

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

この節では，データベースセッションフェイルオーバ機能に関する設定の変更について説明します。データベースセッションフェイルオーバ機能では，データベースのテーブルにアプリケーション情報やグローバルセッション情報などの設定情報を格納します。Webアプリケーション開始時のネゴシエーション処理で設定に誤りがないことを確認するため，一度開始したWebアプリケーションの設定を変更する場合は，データベースに保存したWebアプリケーションの設定情報の初期化が必要となります。ネゴシエーション処理については，「6.4.1　アプリケーション開始時の処理」を参照してください。

データベースセッションフェイルオーバ機能に関する設定の変更の流れを次の図に示します。

図6‒13　データベースセッションフェイルオーバ機能に関する設定の変更の流れ

データベースセッションフェイルオーバ機能に関する設定を変更する場合の注意事項を次に示します。

設定変更時に停止する範囲に関する注意事項

次の設定を変更する場合は，冗長化したほかのJ2EEサーバまたはアプリケーションをすべて停止してください。

完全性保障モードの設定

データベース上のグローバルセッション情報数の設定

HTTPセッションの属性情報の最大サイズの変更に関する注意事項

HTTPセッションの属性情報の最大サイズを小さく変更した場合，変更前に作成したグローバルセッション情報を引き継いだ時に，変更後の最大サイズを超えることがあります。最大サイズを超えた場合，属性情報のシリアライズ時にKDJE34320-Eのメッセージが出力され，グローバルセッション情報はデータベースに保存されません。このため，HTTPセッションの属性情報の最大サイズを小さく変更する場合は，HTTPセッションを破棄してください。HTTPセッションの破棄については，「6.7.3　グローバルセッション情報の削除（HTTPセッションの破棄）」を参照してください。

この節では，J2EEサーバおよびアプリケーションの設定変更，およびデータベーステーブルの初期化について説明します。

参考

アプリケーションの停止および開始には，サーバ管理コマンドまたは運用管理ポータルを使用します。アプリケーションの開始については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstartapp（J2EEアプリケーションの開始）」を参照してください。アプリケーションの停止については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstopapp（J2EEアプリケーションの停止）」を参照してください。運用管理ポータルの操作については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「12.3　J2EEアプリケーション管理」を参照してください。

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

ここでは，J2EEサーバの設定，およびWebアプリケーションの設定変更の手順について説明します。設定を変更した場合，データベースに保存した情報の初期化が必要です。データベースに保存した情報の初期化については，「6.7.2　データベーステーブルの初期化」を参照してください。

(1)　アプリケーションの停止および設定変更

アプリケーションの設定を変更するには，J2EEアプリケーションを停止して，Webアプリケーションの設定を変更します。

一つのJ2EEサーバのWebアプリケーションの設定変更終了後に，冗長化した別のJ2EEサーバのWebアプリケーションの設定を変更します。冗長化したJ2EEサーバに対して，一つずつ同じWebアプリケーションの設定変更をしていくことで，システム全体を停止することなく全体の設定を変更できます。

設定項目については，「6.5　cosminexus.xmlでの定義」，Webアプリケーションの設定変更の詳細については「6.6.2　Webアプリケーションの設定」を参照してください。

(2)　J2EEサーバの停止および設定変更

J2EEサーバの設定を変更するには，次の手順を実施してください。

J2EEアプリケーションを停止します。

J2EEサーバ内のすべてのJ2EEアプリケーションを停止します。

J2EEサーバを停止します。

J2EEサーバを停止します。

簡易構築定義ファイルでJ2EEサーバの設定を変更します。

簡易構築定義ファイルで設定を変更します。J2EEサーバでの設定項目については「6.6.1　J2EEサーバの設定」を参照してください。

冗長化した別のJ2EEサーバの設定を変更します。

冗長化した別のJ2EEサーバに対して順番に手順1.〜3.を実施し，冗長化したJ2EEサーバすべてに同じ設定変更をします。

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

Webアプリケーションで使用する情報，またはWebアプリケーションに関する情報を変更した場合，データベース上に保存されたWebアプリケーションの設定情報を初期化する必要があります。ここでは，データベース上に保存された設定情報の初期化の手順について説明します。また，データベース上のグローバルセッション情報数の変更，およびデータベース上のHTTPセッションの属性情報の最大サイズの変更の手順について説明します。

(1)　データベースに保存された設定情報の初期化

一度開始したWebアプリケーションの設定を変更した場合は，データベースに保存された設定情報を初期化する必要があります。

データベースに保存された設定情報を初期化する手順について説明します。

テンプレートファイルを任意の場所にコピーします。

データベースに保存された設定情報の初期化用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_reset_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_reset_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_reset_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_reset_apptbl.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベースに保存された設定情報の初期化用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6‒50　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

1行目

<APPLICATION_ID>

使用するアプリケーションのアプリケーション識別子に変更してください。

作成したデータベースに保存された設定情報の初期化用SQLファイルを実行します。

SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

(2)　データベース上のグローバルセッション情報数の変更

データベース上のグローバルセッション情報数は，HTTPSessionオブジェクト数の上限値に合わせて変更します。ただし，アプリケーション開始時に実施されるネゴシエーション処理に失敗した場合に，Webアプリケーションの開始処理を続行する設定にしているときは，データベース上のグローバルセッション情報数とHTTPSessionオブジェクト数の上限値の設定は異なっていてもかまいません。

データベース上のグローバルセッション情報数を変更する手順について説明します。なお，データベース上のグローバルセッション情報数を変更すると，データベース上のセッション情報はすべて削除されます。

J2EEアプリケーション，およびJ2EEサーバを停止します。

J2EEサーバ内のすべてのJ2EEアプリケーション，および冗長化したすべてのJ2EEサーバを停止します。

テンプレートファイルを任意の場所にコピーします。

データベース上のグローバルセッション情報数の変更用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_change_session_num.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_change_session_num.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_change_session_num.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_change_session_num.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベース上のグローバルセッション情報数の変更用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6‒51　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

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.5　cosminexus.xmlでの定義」を参照してください。

データベース上のHTTPセッションの属性情報の最大サイズを変更する手順について説明します。この手順は，HiRDBを使用する場合だけ必要です。

J2EEアプリケーション，およびJ2EEサーバを停止します。

J2EEサーバ内のすべてのJ2EEアプリケーション，および冗長化したすべてのJ2EEサーバを停止します。

テンプレートファイルを任意の場所にコピーします。

データベース上のHTTPセッションの属性情報の最大サイズの変更用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を次に示します。

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_change_attributes_size.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_change_attributes_size.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，データベース上のHTTPセッションの属性情報の最大サイズの変更用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6‒52　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

1行目

<APPLICATION_ID>

使用するアプリケーションのアプリケーション識別子に変更してください。

2行目

<ATTRIBUTE_DATA_SIZE_MAX>

HTTPセッションの属性情報を格納するカラムのサイズ（単位：バイト）を変更してください。

作成したデータベース上のグローバルセッション情報数の変更用SQLファイルを実行します。

SQLファイルの実行には，SQL Executerを使用してください。

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

システムの運用中，アプリケーションのバージョンアップをする場合などに，システム内に存在するHTTPセッションの破棄が必要となる場合があります。

データベースセッションフェイルオーバ機能では，データベースにグローバルセッション情報を格納するため，J2EEアプリケーションやJ2EEサーバの停止ではHTTPセッションが破棄できません。グローバルセッション情報をデータベースから削除することで，HTTPセッションを破棄します。

グローバルセッション情報を削除するには，次の手順を実施してください。

J2EEアプリケーションを停止します。

J2EEサーバ内のすべてのJ2EEアプリケーションを停止します。

データベース上のグローバルセッション情報を削除します。

データベース上のグローバルセッション情報数を変更する手順でグローバルセッション情報を削除します。この時，グローバルセッション情報数を変更しないで，変更手順だけを実施します。変更手順については，「6.7.2(2)　データベース上のグローバルセッション情報数の変更」を参照してください。

J2EEアプリケーションを開始します。

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

データベースセッションフェイルオーバ機能を使用するアプリケーションの設定を変更する際に，データベースのテーブルの削除が必要な場合があります。ここでは，データベースのテーブルの削除について説明します。

削除するテーブルと，削除手順の参照先について次の表に示します。

表6‒53　削除するテーブルと，削除手順の参照先

テーブル名

データベース上の物理名称

削除手順の参照先

アプリケーション情報テーブル

SFO_<APPLICATION_ID>_APP_INFO

6.8.1

セッション情報格納テーブル

SFO_<APPLICATION_ID>_SESSIONS

6.8.2

空きレコード情報テーブル

SFO_<APPLICATION_ID>_REC_INFO

データベースセッションフェイルオーバ機能で使用するデータベースのテーブル削除用のテンプレートファイルは次の場所に格納されています。

Windowsの場合：

<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥

UNIXの場合：

/opt/Cosminexus/CC/sfo/sql/

テーブル削除用のテンプレートファイルは使用するデータベースごとに2種類ずつあります。使用するデータベース，ファイル，および削除するテーブルの種類の対応を次の表に示します。

表6‒54　テーブル削除用テンプレートファイルと削除するテーブル

使用するデータベース

テンプレートファイル

削除するテーブルの種類

アプリケーション情報テーブル

セッション情報格納テーブル

空きレコード情報テーブル

HiRDB

hirdb_delete_apptbl.sql

○

−

−

hirdb_delete_sessiontbl.sql

−

○

○

Oracle

oracle_delete_apptbl.sql

○

−

−

oracle_delete_sessiontbl.sql

−

○

○

（凡例）○：削除できる　−：削除できない

以降で，使用するデータベースごとにテンプレートファイルの詳細について示します。

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

アプリケーション情報テーブルは，Webアプリケーションに設定したデータベースセッションフェイルオーバ機能に関する設定を格納するテーブルです。

アプリケーション情報テーブルの削除手順を次に示します。

テンプレートファイルを任意の場所にコピーします。

テーブル削除用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_delete_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_delete_apptbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_delete_apptbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_delete_apptbl.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル削除用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6‒55　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

HiRDB

Oracle

1行目

1行目

<APPLICATION_ID>

使用するアプリケーションのアプリケーション識別子に変更してください。

なし

1行目

<SCHEMA_NAME>

データベース接続ユーザのスキーマ名に変更してください。

作成したテーブル削除用SQLファイルを実行します。

SQLファイルの実行には，HiRDBを使用する場合はSQL Executer，Oracleを使用する場合はSQL*Plusなどを使用してください。

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

セッション情報格納テーブルは，グローバルセッション情報を格納するテーブルです。空きレコード情報テーブルは，セッション情報格納テーブルの未使用レコードを管理するテーブルです。

セッション情報格納テーブルおよび空きレコード情報テーブルの削除手順について説明します。

テンプレートファイルを任意の場所にコピーします。

テーブル削除用のSQLファイルとして，テンプレートファイルが用意されています。テンプレートファイルの格納場所を，使用するデータベースごとに次に示します。

HiRDBを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥hirdb_delete_sessiontbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/hirdb_delete_sessiontbl.sql

Oracleを使用する場合のテンプレートファイルの格納場所

Windowsの場合：<Application Serverのインストールディレクトリ>¥CC¥sfo¥sql¥oracle_delete_sessiontbl.sql

UNIXの場合：/opt/Cosminexus/CC/sfo/sql/oracle_delete_sessiontbl.sql

テンプレートファイルを編集します。

Webアプリケーションの設定情報に合わせて，テンプレートファイルを編集して，テーブル削除用SQLファイルを作成します。テンプレートファイル内の変更個所と変更内容について次の表に示します。

表6‒56　テンプレートファイル内の変更個所と変更内容

変更個所

変更対象

変更内容

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.9　データベースセッションフェイルオーバ機能使用時の注意事項

データベースセッションフェイルオーバ機能を使用する際の注意事項について説明します。

データベースセッションフェイルオーバ機能で使用するテーブルの内容を操作した場合，システムの情報を正しく保つことができないため，正常な運用を続けることができなくなります。

データベース上のデータベースセッションフェイルオーバ機能で使用するテーブルの変更を伴う操作として実行できるのは，次の操作だけです。なお，次の操作を実施する場合も，参照先の手順に従って操作してください。

データベースセッションフェイルオーバ機能の設定変更（6.7参照）

テーブルの初期化（6.7.2参照）

HTTPセッションの破棄（6.7.3参照）

これらの操作以外については，実行しないでください。

HTTPセッションの属性情報のサイズが最大値を超えた場合，HTTPセッションの情報はデータベースに冗長化されません。

7　明示管理ヒープ機能を使用したFullGCの抑止

アプリケーションサーバでは，Javaアプリケーション実行時に，Javaオブジェクトの配置先としてJavaヒープとは別のメモリ空間を使用できます。この機能を明示管理ヒープ機能といいます。明示管理ヒープ機能を効果的に使用することで，FullGCの発生を抑止できます。

この章では，明示管理ヒープ機能を使用したFullGCの抑止について説明します。ただし，JDK17以降を使用する場合は，明示管理ヒープ機能を使用できません。また，JDK11以前でG1GCを使用した場合にも，明示管理ヒープ機能を使用できません。G1GCまたはZGC使用時に-XX:+HitachiUseExplicitMemoryを指定した場合，メッセージ（Using -XX:+UseG1GC and -XX:+HitachiUseExplicitMemory at the same time is not supported.またはUsing -XX:+UseZGC and -XX:+HitachiUseExplicitMemory at the same time is not supported.）を標準出力に出力してJavaVMを終了します。

JDK11以前のアプリケーションサーバでは，明示管理ヒープ機能がデフォルトで有効になります。そのため，JDK11以前のアプリケーションサーバでG1GCを使用する場合は，-XX:-HitachiUseExplicitMemoryを指定してください。

G1GCでのFull GCの発生を抑止するチューニングは，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.16　G1GCのチューニング」を参照してください。ZGCでは，Full GCの概念がなくFull GCの発生によるシステムの停止がないため，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.18　ZGCのチューニング（JDK17以降の場合）」を参照して，Javaヒープサイズを適切にチューニングしてください。

7.1　この章の構成

明示管理ヒープ機能は，Javaオブジェクトの配置先としてJavaヒープ外の領域（Explicitヒープ）を使用することで，FullGCの発生を抑止する機能です。

この章の構成を次の表に示します。

表7‒1　この章の構成（明示管理ヒープ機能を使用したFullGCの抑止）

分類

タイトル

参照先

解説

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

7.2

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

7.3

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

7.4

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

7.5

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

7.6

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

7.7

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

7.8

javagcコマンドによるExplicitメモリブロックの解放

7.9

Explicitメモリブロックの自動解放処理に掛かる時間の短縮

7.10

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

7.11

実装

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

7.12

設定

実行環境での設定

7.13

注意事項

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

7.14

注　「運用」について，この機能固有の説明はありません。

なお，GCの仕組みについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

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

この節では，明示管理ヒープ機能の概要について説明します。

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

明示管理ヒープ機能は，FullGCの発生を抑止する機能です。この機能を使用することで，システムが停止する回数を低減し，安定したスループットを実現します。

システムで扱う論理アドレス空間の増加やシステム規模の拡大などによって，アプリケーションサーバで扱うJavaヒープのサイズは増加しています。Javaヒープのサイズの増加に伴って問題になるのは，GCの実行に掛かる時間の増加です。GCが実行されている間，システムは停止します。特に，FullGCの実行時間は，使用済みのJavaヒープのサイズに応じて増加します。使用できるJavaヒープのサイズの増加に従って，FullGCに掛かる時間も増えるおそれがあります。

参考

GCのアルゴリズムとシステム停止時間の関係

JavaVMでは，CopyGCのアルゴリズムとしてCopyアルゴリズム，FullGCのアルゴリズムとしてMark Sweep Compactアルゴリズムを採用しています。これらのアルゴリズムは，Stop The World型のアルゴリズムです。Stop The World型では，GCの実行に掛かる時間は，そのJavaVMを利用したシステムが停止する時間と等しくなります。

7.2.2　明示管理ヒープ機能の利用によるFullGCの抑止の仕組み

明示管理ヒープ機能では，Javaオブジェクトの配置先として，Explicitヒープという独自の領域を使用します。Explicitヒープは，Javaヒープ外にある，GCの対象にならない領域です。明示管理ヒープ機能を使用していない場合にJavaヒープに配置していたJavaオブジェクトをExplicitヒープに配置することで，FullGCが発生することを抑止できます。

ここでは，明示管理ヒープ機能を利用してFullGCを抑止する仕組みについて説明します。また，明示管理ヒープ機能の位置づけについてもあわせて説明します。

(1)　FullGC発生を抑止する仕組み

Javaアプリケーション実行中にEden領域に空き領域がなくなると，GCが発生します。このとき，次の式が成り立つ場合は，JavaVMによってFullGCが実行されます。

New領域で使用されているメモリのサイズ＞Tenured領域の空き領域のサイズ

注

Eden領域に空き領域がなくなっているため，New領域で使用されているメモリのサイズはNew領域の最大サイズにほぼ等しくなります。

式が示すとおり，Tenured領域の空き領域のサイズが小さくなるとFullGCが発生します。Tenured領域の空き領域は，CopyGCが発生したときにSurvivor領域から移動（昇格）するJavaオブジェクトによって使用されます。つまり，昇格するJavaオブジェクトを削減できれば，FullGCの発生を抑えられます。なお，何回かのCopyGCの実行で削除されないで，昇格の対象になるオブジェクトを長寿命オブジェクトといいます。

長寿命オブジェクトには大きく分けて2種類あります。一つは，FullGCで回収されないオブジェクトです。例えばアプリケーションの実行中は常に生存し続けるような，本来Tenured領域に格納される必要があるオブジェクトが当てはまります。このようなオブジェクトは増加し続けることはないため，FullGCが発生する本質的な原因ではありません。このような長寿命オブジェクトの影響を排除したい場合は，Tenured領域のサイズを増加することで対処できます。

二つ目は，FullGCで回収されるオブジェクトです。FullGCで回収される長寿命オブジェクトとは，Tenured領域に昇格する程度に長寿命であるが，一定期間で不要となるオブジェクトを指します。このような長寿命オブジェクトはFullGCの発生までは増加し続けるため，FullGC発生の原因となります。

FullGCで回収されるオブジェクト，およびFullGCで回収されないオブジェクトについて，次の図で説明します。

図7‒1　FullGCで回収されるオブジェクト，およびFullGCで回収されないオブジェクト

一定期間で不要となるオブジェクトの増加を防ぐ対策として，Tenured領域のサイズを増加しただけでは，効果がありません。Tenured領域のサイズを2倍にしても，FullGCの発生間隔が2倍になるだけで，期待するほどの効果は得られません。

つまり，FullGCの発生を抑止するためには，一定期間で不要となるオブジェクトのTenured領域への昇格を減らすことがポイントとなります。

アプリケーションサーバでは，一部のJavaオブジェクトについて，CopyGC発生時の昇格先がExplicitヒープになるように設定されています。明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違いを次の図に示します。

図7‒2　明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違い

図の1.のタイミングでは，どちらの場合も同じ状態です。2.のオブジェクトが昇格するタイミングで，明示管理ヒープ機能を使用していない場合の昇格では，すべての長寿命オブジェクトがTenured領域に移動します。一方，明示管理ヒープ機能を使用している場合，長寿命オブジェクトのうち，一定期間後に破棄されることがわかっているオブジェクトについてはExplicitヒープに移動します。これによって，Tenured領域に移動するのは，破棄される予定がない長寿命オブジェクトに限定され，Tenured領域の使用済みサイズの増加が緩やかになります。なお，3.で示すとおり，明示管理ヒープ機能を使用している場合のExplicitヒープのオブジェクトは，不要になったタイミングで削除されます。

対象となるJavaオブジェクトについては，「7.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。また，GCのアルゴリズムについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

なお，ユーザが開発するアプリケーションで明示管理ヒープ機能を使用する場合は，一定期間後に破棄される長寿命オブジェクトを，直接Explicitヒープに生成します。これによって，Tenured領域のメモリサイズ増加を防ぎます。Explicitヒープに生成できるJavaオブジェクトについては，「7.5　アプリケーションで任意にExplicitヒープに配置できるオブジェクト」を参照してください。

(2)　明示管理ヒープ機能の位置づけ

明示管理ヒープ機能は，JavaVMの機能です。明示管理ヒープ機能を利用する方法には，次の2種類があります。

明示管理ヒープ機能の設定ファイルを使う方法

明示管理ヒープ機能の設定ファイルには，次のものがあります。これらを使用して，明示管理ヒープ機能を利用する対象オブジェクトを設定できます。

明示管理ヒープ機能適用除外設定/適用除外無効設定ファイル

自動配置設定ファイル

明示管理ヒープ機能APIを使う方法

明示管理ヒープ機能の位置づけを次の図に示します。なお，図中のJavaVMログファイル出力機能は，JavaVMログファイル出力機能のことです。

図7‒3　明示管理ヒープ機能の位置づけ

明示管理ヒープ機能の範囲である，明示管理ヒープ機能API，自動配置設定ファイル，明示管理ヒープ機能適用除外設定／適用除外無効設定ファイル，明示管理ヒープ機能を構成する各機能，Tenured領域内不要オブジェクト統計機能，およびExplicitヒープについて説明します。

明示管理ヒープ機能API

Javaプログラムから明示管理ヒープ機能を使用する場合，明示管理ヒープ機能APIを使用します。このAPIでは，Explicitヒープに関連する操作が実行できます。また，Explicitヒープの使用状況を稼働情報として収集することもできます。

自動配置設定ファイル

Javaプログラムを変更しないで明示管理ヒープ機能を使用する場合，自動配置設定ファイルを使用します。このファイルに明示管理ヒープに配置させたいオブジェクトを指定します。

明示管理ヒープ機能適用除外設定／適用除外無効設定ファイル

自動配置機能で明示管理ヒープに配置したオブジェクトから参照されているオブジェクトは，GC発生時に，参照関係に基づいて明示管理ヒープへ自動で移動します。この参照関係に基づく移動の対象となるオブジェクトを，クラス単位に明示管理ヒープ機能の適用対象から除外する場合，明示管理ヒープ機能適用除外設定ファイルと，明示管理ヒープ機能適用除外無効設定ファイルを使用します。

明示管理ヒープ機能の適用対象から除外する場合は，明示管理ヒープ機能適用除外設定ファイルを使用します。このファイルに明示管理ヒープへ移動しないオブジェクトのクラスを指定します。

また，明示管理ヒープ機能適用除外設定ファイルで同一パッケージ内のすべてのクラスを明示管理ヒープ機能の適用対象から除外している場合などに，一部のクラスを明示管理ヒープ機能の適用対象とするときは，明示管理ヒープ機能適用除外無効設定ファイルを使用します。このファイルに明示管理ヒープ機能適用除外の設定を無効にしたいクラスを指定します。

明示管理ヒープ機能を構成する各機能

明示管理ヒープ機能を構成する各機能は，JavaVMに含まれます。APIで呼び出されます。次の処理を実行できます。

Explicitヒープおよびヒープ内のメモリブロックの管理および制御

GCと連携したアロケーション処理の変更によるExplicitヒープへのオブジェクトの配置

なお，アロケーション処理はnewキーワードの延長で実行されます。

Explicitヒープメモリブロックへのオブジェクトの移動制御

JavaVMログファイルとスレッドダンプへのExplicitヒープのイベントログおよび状態の出力

Tenured領域内不要オブジェクト統計機能

Tenured領域内でメモリ増加の原因となっている不要オブジェクトを調査します。Tenured領域内不要オブジェクト統計機能については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.8　Tenured領域内不要オブジェクト統計機能」を参照してください。

Explicitヒープ

GCの対象外にするJavaオブジェクトの配置先になる領域です。明示管理ヒープ機能が管理します。Explicitヒープは，複数のメモリブロック（Explicitメモリブロック）で構成されます。

(3)　明示管理ヒープ機能を使用する場合に必要なメモリサイズ

明示管理ヒープ機能で管理するExplicitヒープは，Javaヒープ外の領域です。Explicitヒープを使用する場合，使用しない場合に比べて，メモリの使用量が増加します。

明示管理ヒープ機能を使用する場合は，必要なメモリサイズとしてExplicitヒープの最大サイズを見積もり，適切に設定する必要があります。明示管理ヒープ機能を利用する流れ，Explicitヒープに格納するオブジェクト（Tenured領域のメモリサイズ増加の要因になるオブジェクト），およびExplicitヒープのサイズの見積もりについては，マニュアル「アプリケーションサーバシステム設計ガイド」の「7.11　Explicitヒープのチューニング」を参照してください。

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

ここでは，明示管理ヒープ機能を利用する場合の前提条件について説明します。明示管理ヒープ機能は，サーバまたはコマンドごとに，使用可否が異なります。

明示管理ヒープ機能のサポート有無を次の表に示します。デフォルトの設定については，「7.13.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」を参照してください。

表7‒2　明示管理ヒープ機能のサポート有無

サーバまたはコマンドの種類

サポート有無

J2EEサーバ

○

バッチサーバ

○

cjclstartapコマンド

○

（凡例）

○：サポートされています。

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

この節では，明示管理ヒープ機能で使用するメモリ空間であるExplicitヒープの構造について説明します。なお，JavaVMで使用するメモリ空間の構成については，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.2.6　SerialGC使用時のJavaVMで使用するメモリ空間の構成とJavaVMオプション」もあわせて参照してください。

Explicitヒープは，GCの対象にならないメモリ空間です。複数のメモリブロックで構成されます。Explicitヒープを構成するメモリブロックをExplicitメモリブロックといいます。Explicitヒープは，Explicitメモリブロック全体を表す概念です。

初期化や解放などの操作は，Explicitメモリブロック単位で実行します。

Explicitヒープの概念を次の図に示します。

図7‒4　Explicitヒープの概念

Explicitヒープの最大サイズは，JavaVM起動オプションの-XX:HitachiExplicitHeapMaxSizeオプションで設定します。-XX:HitachiExplicitHeapMaxSizeオプションの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「-XX:HitachiExplicitHeapMaxSize（Explicitメモリブロックの最大サイズ指定オプション）」を参照してください。生成（初期化）できるExplicitメモリブロックの数は，最大1,048,575個です。この数を超えて生成することはできません。

Explicitヒープ領域の確保のタイミングについて

-XX:HitachiExplicitHeapMaxSizeオプションで指定したExplicitヒープの最大サイズの実メモリ領域が，JavaVMを起動したタイミングで確保されます。領域は，JavaヒープおよびMetaspace領域からの連続領域として確保されます。

JavaオブジェクトをExplicitメモリブロックに配置するために必要なメモリが不足している場合，JavaVM起動時に確保したExplicitヒープの領域から，Explicitメモリブロック向けのメモリ領域を確保します。このため，Explicitメモリブロック内のメモリ領域は複数の領域に分かれていることがあります。

仮想メモリ空間の利用イメージを次の図に示します。

図7‒5　仮想メモリ空間の利用イメージ

Explicitヒープ用の領域は連続領域になりますが，一つのExplicitメモリブロックで使用する領域が，非連続になります。

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

この節では，J2EEサーバ利用時にExplicitヒープに配置されるオブジェクトについて説明します。

J2EEサーバでは，FullGCの発生を抑止するために，次のオブジェクトをExplicitヒープに配置します。

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

Explicitメモリブロック領域の確保やExplicitメモリブロックの解放予約は，Webコンテナが実行します。ここでは，オブジェクトに対してWebコンテナによって実行される処理について説明します。

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

HTTPセッションに格納するオブジェクトは，セッションが有効な間保持されるオブジェクトです。生存期間は，セッションの生成から破棄までの間です。

このオブジェクトは，明示管理ヒープ機能を使用していない場合，何回かのCopyGCが実行される間使用され続けることが多いオブジェクトです。このため，長寿命オブジェクトとしてTenured領域に昇格しやすくなります。Tenured領域に昇格したオブジェクトはCopyGCでは回収されないため，このオブジェクトはセッションが破棄されたあとも回収されません。このため，Tenured領域のメモリ使用量が増加していき，FullGCが発生します。

明示管理ヒープ機能を利用していない場合の例を次の図に示します。

図7‒6　明示管理ヒープ機能を利用していない場合の例

1.でセッションを生成すると，New領域にオブジェクトを格納するための領域が確保されます。2.でセッションにオブジェクトが格納されます。何回かのCopyGCのあと，1.および2.のオブジェクトはTenured領域に移動します。3.でセッションが無効化された場合も，Tenured領域のオブジェクトは回収されないため，メモリ使用量が増加していきます。

これに対して，HTTPセッションに関するオブジェクトの昇格先をTenured領域からExplicitヒープに変更することで，FullGC発生を抑止できます。

明示管理ヒープ機能を利用した例を次の図に示します。

図7‒7　明示管理ヒープ機能を利用した例

明示管理ヒープ機能を使用すると，HTTPセッションに関するオブジェクトによるTenured領域の増加がありません。このため，FullGC発生を抑止できます。なお，Explicitヒープに配置したJavaオブジェクトは，セッションが破棄されたあと，J2EEサーバによって明示的に解放されます。

HTTPセッションを配置するExplicitメモリブロック領域の確保および解放のタイミングについて説明します。

HTTPセッションを作成したとき

新しくHTTPセッションを作成すると，Explicitヒープ領域にExplicitメモリブロックが作成されます。Explicitメモリブロックは，1セッションに一つ割り当てられます。また，HTTPセッションが，Explicitメモリブロック内に確保されます。

ただし，セッション作成直後のオブジェクトの配置先はJavaヒープです。何回かのCopyGCのあと，該当するJavaオブジェクトが昇格するタイミングで，オブジェクトがExplicitヒープに移動します。

HTTPセッションにオブジェクトが格納されたとき（setAttributeメソッドを実行したとき）

javax.servlet.http.HttpSession.setAttributeメソッドでHTTPセッションに格納したオブジェクトは，セッションごとに割り当てられたExplicitメモリブロックに配置されます。

ただし，setAttributeメソッド実行時のオブジェクトの配置先はJavaヒープです。何回かのCopyGCのあと，該当するJavaオブジェクトが昇格するタイミングで，オブジェクトがExplicitヒープに移動します。このとき，移動するオブジェクトから参照されているオブジェクトは，すべてExplicitヒープに移動します。ただし，Explicitメモリブロックへのオブジェクト移動制御オプションの指定によって，Explicitヒープに移動しなくなることがあります。

HTTPセッションからオブジェクトが削除されたとき（removeAttributeメソッドを実行したとき）

Explicitヒープは，GCの対象外です。このため，javax.servlet.http.HttpSession.removeAttributeメソッドを実行してHTTPセッションからオブジェクトを削除しても，オブジェクトが使用していた領域は解放されません。

なお，setAttributeメソッドで属性を変更した場合も，変更前の属性はGCの対象にならないため，オブジェクトが使用していた領域は解放されません。

メモリの解放は，Explicitメモリブロック単位で実行されます。setAttributeメソッドを繰り返し頻繁に実行するようなWebアプリケーションの場合，removeAttributeメソッドを実行してもExplicitメモリブロック内の領域を不要に消費してしまうおそれがありますので，注意してください。

HTTPセッションが破棄されるとき

HTTPセッション作成時に作成されたExplicitメモリブロックは，HTTPセッションが破棄されるときに，Webコンテナによって解放が予約されます。

解放が予約されたExplicitメモリブロックは，そのあとでCopyGCまたはFullGCが実行されたときに，実際に解放されます。このとき，解放が予約されたすべての領域が解放されます。

なお，Explicitメモリブロックを解放したあとで，セッションに格納したオブジェクトへの参照が残っていた場合については，次の説明を参照してください。

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

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

Webアプリケーションで実行される操作または動作とJavaVMの動作の対応を次の表に示します。

表7‒3　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ヒープの省メモリ化機能を使用することで削減できます。詳細は，「7.11　HTTPセッションで利用するExplicitヒープのメモリ使用量の削減」を参照してください。また，マニュアル「アプリケーションサーバ システム設計ガイド」の「付録A　HTTPセッションで利用するExplicitヒープの効率的な利用」を参照してアプリケーションを実装すると，HTTPセッションに明示管理ヒープ機能を効率良く適用できます。

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

この節では，Explicitヒープに任意に配置できるオブジェクトについて説明します。

J2EEサーバで設定されている以外のJavaオブジェクトをExplicitヒープに配置したい場合は，自動配置設定ファイルを使用して配置したいオブジェクトを指定します。自動配置設定ファイルの詳細については「7.13.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用」を参照してください。

また，明示管理ヒープの自動解放機能については，「7.7　自動解放機能が有効な場合のExplicitメモリブロックの解放」を参照してください。

明示管理ヒープ機能APIを使って実装する場合は「7.12　明示管理ヒープ機能APIを使ったJavaプログラムの実装」を参照してください。

ポイント

JavaヒープおよびExplicitヒープをチューニングしてもTenured領域のメモリ使用量が増加し，かつFullGCが発生する要因になるJavaオブジェクトがある場合には，Explicitヒープへオブジェクトを配置することを検討してください。

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

ここでは，Explicitヒープに配置できるオブジェクトの前提と，配置すると効果があるオブジェクトについて説明します。

(1)　配置できるオブジェクトの前提

Explicitヒープ（Explicitメモリブロック）に配置するオブジェクトは，次の前提を満たす必要があります。

Tenured領域のメモリサイズ増加の要因になる長寿命なオブジェクトであること

Explicitメモリブロックに対するオブジェクトの配置および解放には，一定のオーバーヘッドが掛かります。このため，Explicitメモリブロックへのオブジェクトの配置と解放は，できるだけ少なくなるようにしてください。

明示管理ヒープ機能を使用していない場合にCopyGCで回収の対象となっていた短寿命のオブジェクトを配置した場合，FullGC抑止の目的に一致しない上，オーバーヘッドが掛かってしまいます。Explicitメモリブロックには，CopyGCで回収の対象にならない，長寿命のオブジェクトを配置するようにしてください。

Tenured領域のメモリサイズ増加の要因になる長寿命のオブジェクトを特定する方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「9.8　Tenured領域内不要オブジェクト統計機能」を参照してください。

生存期間が既知であること（明示管理ヒープ機能APIを使用する場合だけ）

明示管理ヒープ機能APIを使用して明示管理ヒープを使用する場合，ExplicitメモリブロックはGCの対象にならないため，使用済みのオブジェクトは自動的に回収されません。

Explicitメモリブロックに配置したオブジェクトは，アプリケーションで明示的に解放する必要がありますが，生存期間がわからないオブジェクトの場合，明示的に解放できません。このため，生存期間が既知であるオブジェクトを配置するようにしてください。

(2)　配置すると効果があるオブジェクト

明示管理ヒープ機能は，長寿命オブジェクトのうち，一定期間後に破棄されてFullGCで回収されるオブジェクトが，Tenured領域に昇格することを防ぐ機能です。このため，アプリケーションの停止まで使用されるオブジェクトなど，FullGCでも回収されないオブジェクトに対しては，適用する必要がありません。

Explicitヒープに配置すると効果があるオブジェクトとは，次のようなオブジェクトです。

一定のライフサイクルで生成と破棄が実行される。

ライフサイクルの期間がCopyGCによってオブジェクトが昇格する期間よりも長いために，破棄実施後に使用済みのオブジェクトが正しく回収されない。

このようなオブジェクトをExplicitヒープに配置することで，Tenured領域に不要なオブジェクトが残存することを防ぎ，FullGCを抑止できます。

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

Explicitメモリブロックに配置するオブジェクトのライフサイクルと状態遷移について説明します。

Explicitメモリブロックに配置したオブジェクトは，生存期間に基づいて，明示管理ヒープ機能APIを使用して明示的に生成，解放する必要があります。オブジェクトの生存期間および寿命は，アプリケーションの処理によって異なります。

Explicitメモリブロックに配置するオブジェクトのライフサイクルを次の図に示します。

図7‒8　Explicitメモリブロックに配置するオブジェクトのライフサイクル

オブジェクトは，直接Explicitメモリブロックに生成されます。その後，明示管理ヒープ機能APIによってExplicitメモリブロックの解放が実行されると，状態によって，破棄されるかまたはJavaヒープに移動されます。解放処理実行時の動作については，「7.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

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

この節では，Explicitメモリブロックのライフサイクルと，それぞれの段階で実行される処理について説明します。

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

ここでは，Explicitメモリブロックのライフサイクルと状態について説明します。

明示管理ヒープ機能では，Explicitメモリブロックを解放する方法として，次の2種類の解放処理があります。

Explicitメモリブロックの自動解放処理（自動解放機能が有効な場合に実行される解放処理）

Explicitメモリブロックの明示解放処理（自動解放機能が無効な場合に実行される解放処理）

Explicitメモリブロックの解放処理が異なることで，指定方法や処理が異なります。8.7以降で，解放処理ごとに詳しく説明します。

(1)　Explicitメモリブロックのライフサイクル

Explicitメモリブロックのライフサイクルを次の図に示します。

図7‒9　Explicitメモリブロックのライフサイクル

図に示したライフサイクルの各段階について説明します。

Explicitメモリブロックの初期化とExplicitメモリブロックの無効化

Explicitメモリブロックの初期化が実行され，Explicitメモリブロックが生成されます。

HTTPセッションに関するオブジェクトを格納するExplicitメモリブロックは，Webコンテナによって初期化されます。

アプリケーションで任意のオブジェクトをExplicitヒープに配置する場合は，明示管理ヒープ機能APIを使用して，明示的にExplicitメモリブロックを初期化します。

なお，初期化実行時の状態によっては，Explicitメモリブロックが無効化されることがあります。

Explicitメモリブロックの初期化で実行される処理，およびExplicitメモリブロックが無効化される条件については，「7.6.2　Explicitメモリブロックの初期化」で説明します。

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

アプリケーションで任意のオブジェクトをExplicitメモリブロックに格納する場合，明示管理ヒープ機能APIを使用して，オブジェクトをExplicitメモリブロックに生成，配置します。

Explicitメモリブロックへのオブジェクトの生成については，「7.6.3　Explicitメモリブロックへのオブジェクトの直接生成」で説明します。

Explicitメモリブロックの拡張

利用中にオブジェクトを配置する領域が不足した場合，JavaVMによってExplicitメモリブロックの拡張が実行されます。

Explicitメモリブロックの拡張については，「7.6.4　Explicitメモリブロックの拡張」で説明します。

Explicitメモリブロックの解放予約と解放処理

Explicitメモリブロックの解放予約と解放処理は，明示管理ヒープ機能の自動解放機能の有効（-XX:+HitachiExplicitMemoryAutoReclaim）・無効（-XX:-HitachiExplicitMemoryAutoReclaim）で挙動が異なります。

自動解放機能が有効な場合（-XX:+HitachiExplicitMemoryAutoReclaim）

Explicitメモリブロックの明示解放予約

明示管理ヒープ機能APIによって指定された，Explicitメモリブロックに対して，解放が予約されます。自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約については，「7.7.1　自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約」を参照してください。

Explicitメモリブロックの自動解放予約

明示管理ヒープの自動解放機能によって処理される，Explicitメモリブロックに対して解放が予約されます。自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約については，「7.7.2　自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約」を参照してください。

Explicitメモリブロックの解放処理

明示解放予約，または自動解放予約によって予約されたExplicitメモリブロックに配置されているオブジェクトを解放します。自動解放機能が有効な場合のExplicitメモリブロックの解放処理については，「7.7.3　自動解放機能が有効な場合のExplicitメモリブロックの解放処理」を参照してください。

なお，javagcコマンドを使用すると，解放されていないExplicitメモリブロックに対して，任意のタイミングで解放処理を実行できます。javagcコマンドによるExplicitメモリブロックの解放処理については，「7.9　javagcコマンドによるExplicitメモリブロックの解放」を参照してください。

自動解放機能が無効な場合（-XX:-HitachiExplicitMemoryAutoReclaim）

Explicitメモリブロックの明示解放予約

Explicitメモリブロックに配置したオブジェクトが不要になった場合は，Explicitメモリブロック単位で解放を予約します。

HTTPセッションに関するオブジェクトを格納したExplicitメモリブロックは，Webコンテナによって解放が予約されます。

アプリケーションで任意のオブジェクトをExplicitメモリブロックに格納した場合は，明示管理ヒープ機能APIを使用して，明示的にExplicitメモリブロックの解放を予約します。

自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約については，「7.8.1　自動解放機能が無効な場合のExplicitメモリブロックの明示解放予約」を参照してください。なお，明示解放予約を実行した段階では，まだExplicitメモリブロックは破棄されていません。

Explicitメモリブロックの解放処理

解放が予約されたExplicitメモリブロックは，CopyGCまたはFullGCが発生したタイミングで，JavaVMによって解放されます。同時にExplicitメモリブロックに配置したオブジェクトも破棄されます。ただし，一部のオブジェクトは破棄されないで，Javaヒープに移動します。

自動解放機能が無効な場合のExplicitメモリブロックの解放処理については，「7.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

(2)　Explicitメモリブロックの状態

Explicitメモリブロックは，ライフサイクルの各段階で，有効，解放済み，解放予約済みなどの状態に遷移します。

さらに，有効な状態のExplicitメモリブロックは，次の表に示すサブ状態を保持します。

表7‒4　Explicitメモリブロックのサブ状態

サブ状態

Explicitメモリブロックの状態

Enable

初期状態です。Explicitメモリブロックのすべての機能が使用できます。

Disable

該当するExplicitメモリブロックにJavaオブジェクトを移動できない状態です。Explicitメモリブロックを拡張したときに，この状態になることがあります。

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

ここでは，Explicitメモリブロックの初期化の実行と，初期化時に実行される処理について説明します。

(1)　実行契機

アプリケーションで任意のオブジェクトをExplicitヒープに配置する場合，次に示す明示管理ヒープ機能APIを呼び出すことでExplicitメモリブロックが初期化されます。

BasicExplicitMemory.BasicExplicitMemory()

BasicExplicitMemory.BasicExplicitMemory(String name)

また，これらのAPIのほかに，自動配置設定ファイルで指定したオブジェクトが生成されたタイミングでもExplicitメモリブロックが初期化されます。なお，J2EEサーバがオブジェクトを配置するExplicitメモリブロックでは，Webコンテナによって初期化と最初のオブジェクトの配置が実行されます。実行契機については，「7.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

Explicitメモリブロックが初期化されます。ただし，この段階ではExplicitメモリブロック用のメモリ領域の確保は実行されません。

また，次の場合は，初期化が実行されません。

最大数の制限を超えてExplicitメモリブロックを初期化しようとした場合

現存するExplicitメモリブロックの数が1,048,575個の場合が該当します。

明示管理ヒープ機能がオフになっている場合

-XX:-HitachiUseExplicitMemoryオプションが指定されている場合が該当します。

この場合，コンストラクタの実行は成功しますが，無効なExplicitメモリブロックとして扱われます。初期化したExplicitメモリブロック（ExplicitMemoryインスタンス）に対する処理は，すべて無効になります。

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

ここでは，Explicitメモリブロックにオブジェクトを直接生成する方法と実行される処理について説明します。

アプリケーションでExplicitメモリブロックにオブジェクトを生成するためには，「(1)実行契機」で示すAPIを使用します。APIを実行すると，引数で指定したクラスのオブジェクトがExplicitメモリブロックに生成されます。ただし，そのオブジェクトのコンストラクタなどによる初期化処理中に生成されたオブジェクトについては，Javaヒープに生成されます。

(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ごとに実行される内容を説明します。

表7‒5　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の詳細については，マニュアル「アプリケーションサーバ リファレンス API編」の「10.3　ExplicitMemoryクラス」を参照してください。

ただし，配置先のExplicitメモリブロックに必要な領域を確保できない場合は，生成したオブジェクトがExplicitメモリブロックに配置されません。生成したオブジェクトはJavaヒープに配置されます。

領域を確保できない要因および実行される処理については，「7.6.4　Explicitメモリブロックの拡張」の拡張処理を実行できない場合の説明を参照してください。

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

ここでは，Explicitメモリブロックの拡張処理について説明します。拡張処理が実行されると，Explicitメモリブロック内の空き領域が増加します。

(1)　実行契機

拡張は，JavaVMによって次の契機で実行されます。

Explicitメモリブロックに最初のオブジェクトが配置される時

オブジェクトを配置するためのExplicitメモリブロックの空き領域が足りない場合

明示管理ヒープ機能APIを使用したアプリケーションからExplicitメモリブロックにオブジェクトを配置しようとした場合に，オブジェクトのサイズが配置対象のExplicitメモリブロックの空き領域を超えるとき，拡張処理が実行されます。

Explicitメモリブロックの初期化後，初めてExplicitメモリブロックにオブジェクトを配置するときには，必ず拡張処理が実行されます。

なお，J2EEサーバがオブジェクトを配置するExplicitメモリブロックでは，Webコンテナによって初期化と最初のオブジェクトの配置が実行されます。実行契機については，「7.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

JavaVMによって，OSからメモリ領域が確保され，該当のExplicitメモリブロックが拡張されます。メモリ領域の確保には，OSのメモリ確保APIが使用されます。

ただし，次の場合，拡張処理が実行されません。

Explicitヒープの最大値の制限を超えて拡張しようとした場合

すべてのExplicitメモリブロックの合計サイズに，拡張しようとしたサイズを加えた値が，-XX:HitachiExplicitHeapMaxSizeオプションに指定した値を超えた場合です。

該当するExplicitメモリブロックのサブ状態が「Disable」に変化して，このExplicitメモリブロックへのオブジェクトの配置が中止されます。

「Disable」に変化したExplicitメモリブロックには，以降オブジェクトは配置されません。

-XX:HitachiExplicitHeapMaxSizeオプションについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした場合

サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした場合は，Explicitメモリブロックへのオブジェクトの配置が中止されます。

Explicitメモリブロックの拡張が失敗した場合のサブ状態の変化について，要因ごとに次の表に示します。

表7‒6　Explicitメモリブロックの拡張が失敗した場合のサブ状態の変化

拡張が失敗した要因

サブ状態の変化

OSからのメモリ領域の確保に失敗した

「Enable」→「Disable」

Explicitヒープの最大値の制限を超えて拡張しようとした

「Enable」→「Disable」

サブ状態が「Disable」になっているExplicitメモリブロックを拡張しようとした

変化しません。

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

JavaヒープからExplicitメモリブロックへのオブジェクトの移動では，Explicitメモリブロック内にあるオブジェクトから参照されているJavaヒープ内のオブジェクトが，自動でExplicitメモリブロックへ移動します。このため，移動するオブジェクトと関係を持つオブジェクトに対して，JavaヒープからExplicitメモリブロックへ移動する設定を作り込む必要はありません。ただし，-XX:+ExplicitMemoryUseExcludeClassオプションを指定した場合，明示管理ヒープ機能適用除外設定ファイルに記述されたクラスのオブジェクトは，Explicitメモリブロックへ移動しません。

なお，参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動は，自動配置機能で作成したExplicitメモリブロックが対象となります。明示管理ヒープAPIで作成したExplicitメモリブロックは対象外です。

参考

FullGCの発生時，大量のオブジェクトがExplicitヒープに移動したあとに次の現象が発生する場合は，参照関係に基づく移動の対象となるオブジェクトをExplicitメモリブロックへ移動しないようにする運用を検討してください。

Explicitメモリブロックの自動解放処理に時間が掛かる

Tenured領域の使用量が少ない

Explicitメモリブロックへオブジェクトを移動しないためには，次の機能を使用します。

Explicitメモリブロックへのオブジェクト移動制御機能

明示管理ヒープ機能適用除外クラス指定機能

1.の機能は，FullGC発生時にオブジェクトをExplicitヒープへ移動しない機能であり，Explicitメモリブロックの自動解放処理に掛かる時間を短縮できます。また，2.の機能は，CopyGC発生時に設定ファイルに指定したクラスのオブジェクトをExplicitヒープへ移動しない機能であり，指定するクラスによってはExplicitヒープへ移動するオブジェクトの量を少なくできます。なお，2.の機能を使用すると，1.の機能も有効になります。2.の機能は，1.の機能を利用しても，Explicitヒープへのオブジェクトの移動が多く，Explicitメモリブロックの自動解放処理に時間が掛かるような場合に利用します。

(1)　実行契機

CopyGC，およびFullGCが発生したタイミングで実行されます。

(2)　実行される内容

CopyGCまたはFullGCの処理が終了したあと，JavaVMによって解放予約されていないExplicitメモリブロックがあるかどうか調査されます。調査の基点となるオブジェクトから参照関係を調べ，参照先がなくなるまで調査を続けます。参照関係を調査する際，Javaヒープ外の領域は調査対象外です。また，Explicitメモリブロックから参照されているオブジェクトは移動対象のオブジェクトとなります。

CopyGCの場合

CopyGCが実行された場合には，これらに加えて次の規則に従って動作します。

参照されているExplicitメモリブロック内のオブジェクトが昇格するタイミングで移動します。

Metaspace領域，Explicitヒープ，およびTenured領域への参照についても調査対象としません。

Explicitメモリブロックが解放予約されている場合でも，移動対象として扱います。

Explicitメモリブロックの領域が確保できず，オブジェクトがJavaヒープに移動するときに，移動先のJavaヒープに空き領域がなくなり，移動できなくなった場合が該当します。この場合は，FullGCが実行され，Javaヒープに空き領域が確保されます。FullGC実行後，Javaヒープへのオブジェクトの移動が実行されます。

FullGCの場合

FullGCが実行された場合には，これらに加えて次の規則に従って動作します。

-XX:ExplicitMemoryFullGCPolicyオプションに1を指定した場合，参照関係に基づく移動の対象となるオブジェクトは，Explicitメモリブロックへ移動しません。なお，New領域にあるオブジェクトはTenured領域へ移動します。

これらの規則に従ったオブジェクトの移動の流れを図7-10および図7-11で例を使って説明します。なお，ここで説明するオブジェクトの移動の流れは，-XX:ExplicitMemoryFullGCPolicyオプションに0を指定していることを前提としています。

図7‒10　参照関係に基づいて移動するオブジェクト（例1）

図中のオブジェクトは次の順番に動作します。

オブジェクト1は，Explicitメモリブロック1内のオブジェクトから参照されています。そのため，オブジェクト1はExplicitメモリブロック1へ移動します。

オブジェクト9も，オブジェクト1から参照されているためExplicitメモリブロック1に移動します。

1.および2.の処理と同様に，オブジェクト4，オブジェクト10，およびオブジェクト11はExplicitメモリブロック2へ移動します。

オブジェクト6は，Explicitメモリブロック2内のオブジェクトから参照されています。しかし，Javaヒープ内のオブジェクトではないためこのままとなります。

4.と同様に，オブジェクト12についてもこのままとなります。

図7‒11　参照関係に基づいて移動するオブジェクト（例2）

図中のオブジェクトは次の順番に動作します。

オブジェクト13は，Javaヒープ内にあり，またExplicitメモリブロック2内のオブジェクトから到達できます。しかし，オブジェクト12の時点で調査が打ち切られているため，移動しません。

オブジェクト15は，オブジェクト13と同様にMetaspace領域からの参照があります。しかし，この参照に加え，Explicitメモリブロック2内のオブジェクトからMetaspace領域やほかの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レベルの例外が発生することがあります。詳細は，マニュアル「アプリケーションサーバリファレンス API編」の「10.7　例外クラス」を参照してください。

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

Explicitメモリブロックのライフサイクルの各段階では，イベントログが出力されます。イベントログは，出力契機になるイベントが発生したときに出力されます。

ライフサイクルの各段階と，イベントログの出力契機の対応を次の表に示します。ログ出力レベルの設定によって，ログを出力する契機になるイベントは異なります。

表7‒7　ライフサイクルの各段階と出力されるイベントログの対応

ライフサイクルの段階

イベントログの出力契機

ログ出力レベル

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

このほか，ライフサイクルの段階と対応しないイベントとして，GC発生時にイベントログが出力されます。

明示管理ヒープ機能のイベントログ取得の設定については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「3.3.17　JavaVMの資料取得の設定」を参照してください。明示管理ヒープ機能のイベントログの内容については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.19　明示管理ヒープ機能のイベントログ」を参照してください。

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

ここでは，明示管理ヒープの自動解放について説明します。

Explicitメモリブロックの自動解放は，解放予約と解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行することで，効率良く処理できます。

また，自動解放予約には自動解放の明示予約，および自動解放の自動予約の2種類があります。Explicitメモリブロックの自動解放について，図で説明します。

図7‒12　Explicitメモリブロックの自動解放

以降では，自動解放機能が有効な場合に実行される処理について説明します。

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

自動解放機能が有効な場合のExplicitメモリブロックの明示解放予約では，APIによって明示的にExplicitメモリブロックに対して解放を予約します。

(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レベルの例外が発生することがあります。詳細は，マニュアル「アプリケーションサーバ リファレンス API編」の「10.7　例外クラス」を参照してください。

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

自動解放機能が有効な場合のExplicitメモリブロックの自動解放予約では，JavaVMが自動的にExplicitメモリブロックに対して解放を予約します。自動配置機能で配置したExplicitメモリブロックが対象となります。

(1)　実行契機

GCが発生したタイミングでJavaVMによって実行されます。

(2)　実行される内容

GCが発生したタイミングで，JavaVMが自動でExplicitメモリブロック領域を予約します。

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

自動解放機能が有効な場合のExplicitメモリブロックの解放処理は，事前に自動解放予約，および明示解放予約で予約されているExplicitメモリブロックに対して実行されます。不要になったExplicitメモリブロックは，解放処理によってメモリから削除されます。

なお，外部（解放対象外のExplicitメモリブロック）から参照されているオブジェクトがある場合，オブジェクトは新規のExplicitメモリブロックに移動されます。

(1)　実行契機

自動解放予約で解放予約が実行されるのと同じGCで，JavaVMによって実行されます。

(2)　実行される内容

実行される内容は，解放対象外のExplicitメモリブロックから参照されているオブジェクトの挙動以外は，自動解放機能が無効な場合のExplicitメモリブロックの解放処理の処理内容と同じです。Explicitメモリブロックの解放処理で実行される内容については，「7.8.2　自動解放機能が無効な場合のExplicitメモリブロックの解放処理」を参照してください。

また，次の条件に該当する場合は動作が異なります。

Explicitメモリブロックの空き領域を確保できない場合

オブジェクトをExplicitメモリブロックに配置する際，配置先のExplicitメモリブロックに配置対象となるオブジェクトを配置する空き領域がない場合が該当します。この場合，Explicitメモリブロックにオブジェクトを配置できません。配置できなかったオブジェクトは，Javaヒープ領域へ配置されます。

Javaヒープへのオブジェクト移動時にJavaヒープがあふれた場合

Explicitメモリブロックの領域を確保できず，オブジェクトがJavaヒープに移動する場合に，移動先のJavaヒープに空き領域がなくなり，移動できなくなったときが該当します。この場合は，FullGCが実行され，Javaヒープに空き領域が確保されます。FullGC実行後，Javaヒープへのオブジェクトの移動が実行されます。

FullGCを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合は，ログファイルが出力され，オブジェクトが再度Explicitメモリブロックに配置されます。出力されるログファイルについては，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「4.19　明示管理ヒープ機能のイベントログ」を参照してください。

FullGCで十分な空き領域を作成できない場合

Javaヒープに空き領域がなくなり，FullGCを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合が該当します。この場合は，Cヒープ不足の場合と同様に，JavaVMがアボートします。ただし，Cヒープ不足時には「request nnn bytes」としてnnnに必要なメモリサイズが出力されますが，JavaVMのアボート時には，nnnとして常に「0」が出力されます。

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

ここでは，明示管理ヒープの明示解放について説明します。

Explicitメモリブロックの明示解放は，明示管理ヒープの自動解放と同様に，解放予約と解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行します。

以降では，明示解放機能で実行される処理について説明します。

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

Explicitメモリブロックの解放は，解放予約と実際の解放処理の2段階に分けて実行されます。複数のExplicitメモリブロックの解放をそれぞれ予約しておき，解放処理を一斉に実行することで，効率良く処理できます。

(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コンテナによって解放が予約されます。実行契機については，「7.4　J2EEサーバ利用時にExplicitヒープに配置されるオブジェクト」を参照してください。

(2)　実行される内容

(1)で示したAPIが呼び出されると，APIの引数で指定されたExplicitメモリブロック領域が解放予約された状態になります。

なお，APIの利用方法が誤っている場合，APIレベルの例外が発生することがあります。詳細は，マニュアル「アプリケーションサーバ リファレンス API編」の「10.7　例外クラス」を参照してください。

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

解放処理は，事前に解放予約されているExplicitメモリブロックに対して実行されます。不要になったExplicitメモリブロックは，解放処理によってメモリから実際に削除されます。

(1)　実行契機

解放処理は，次の契機でJavaVMによって実行されます。

CopyGC発生時

FullGC発生時

(2)　実行される内容

CopyGCまたはFullGCの処理が終了したあと，JavaVMによって解放予約されたExplicitメモリブロックがあるかどうかが調査されます。該当するExplicitメモリブロックが一つ以上ある場合は，そのExplicitメモリブロックが解放されます。解放は，OSのメモリ解放APIで実行されます。その際，解放されたExplicitメモリブロック内のオブジェクトは，破棄されます。

ただし，解放するExplicitメモリブロック内のオブジェクトのうち，どこからも参照されていないfinalizeメソッドを実装しているクラスのオブジェクトは，破棄されません。このオブジェクトは，ファイナライズキューに登録され，Javaヒープに移動されます。

また，解放対象のExplicitメモリブロックのオブジェクトが次の条件に該当する場合は動作が異なります。

(a)　外部（解放対象のExplicitメモリブロック以外）から参照されている場合

解放対象のExplicitメモリブロックのオブジェクトが，次の領域のオブジェクトから参照されている場合が該当します。

Javaヒープ

Metaspace領域

解放対象でないExplicitメモリブロック

それぞれの場合に実行される内容を次に示します。

JavaヒープまたはMetaspace領域から参照されている場合

JavaヒープまたはMetaspace領域内のオブジェクトから参照されている場合，そのオブジェクトは破棄されません。

該当するオブジェクトは，JavaヒープのTenured領域に優先的に移動されます。ただし，Tenured領域に空き容量がない場合，またはTenured領域があふれた場合は，New領域に移動されます。また，すでに使用されていないTenured領域のオブジェクトから参照されている場合も，移動の対象になります。

解放対象ではないExplicitメモリブロックから参照されている場合

解放対象ではないExplicitメモリブロック内のオブジェクトから参照されている場合，そのオブジェクトは破棄されません。また，参照元のオブジェクトが解放対象のExplicitメモリブロック内のオブジェクトである場合も，そのオブジェクトが破棄されないでJavaヒープに移動するオブジェクトである場合は，参照されているオブジェクトも削除されません。

Explicitメモリブロック解放時に外部から参照されている場合の動作を次の図に示します。

図7‒13　Explicitメモリブロック解放時に外部から参照されている場合の動作

解放対象のExplicitメモリブロックに含まれるオブジェクトである，オブジェクトXを例にして説明します。

解放対象のExplicitメモリブロックのオブジェクトから参照されている場合，オブジェクトXは削除されます。

Javaヒープ，Metaspace領域または解放対象でないExplicitメモリブロックのオブジェクトから参照されている場合，オブジェクトXは削除されません。

また，オブジェクトXが解放対象のExplicitメモリブロックのオブジェクト（オブジェクトY）から参照されている場合も，参照元であるオブジェクトYがJavaヒープ，Metaspace領域または解放対象でないExplicitメモリブロックのオブジェクトから参照されているときには，オブジェクトXは削除されません。この場合，オブジェクトXは，オブジェクトYとともにJavaヒープに移動します。

(b)　Javaヒープへのオブジェクト移動時にJavaヒープがあふれた場合

外部から参照されているオブジェクトがJavaヒープに移動するときに，移動先のJavaヒープに空き領域がなくなり，移動できなくなった場合が該当します。

この場合は，FullGCが実行され，Javaヒープに空き領域が確保されます。FullGC実行後，Javaヒープへのオブジェクトの移動が実行されます。

(c)　FullGCで十分な空き領域を作成できない場合

Javaヒープに空き領域がなくなり，FullGCを実行してもJavaオブジェクトを移動するために必要な空き領域が確保できない場合が該当します。この場合は，Cヒープ不足の場合と同様に，JavaVMがアボートします。ただし，Cヒープ不足時には「request nnn bytes」としてnnnに必要なメモリサイズが出力されますが，JavaVMのアボート時には，nnnとして常に「0」が出力されます。

7.9　javagcコマンドによるExplicitメモリブロックの解放

ここでは，javagcコマンドによる明示管理ヒープの解放について説明します。

javagcコマンドによるExplicitメモリブロックの解放は，任意のタイミングで実行できます。これによって，自動解放機能が有効な場合の解放処理で解放されなかったExplicitメモリブロックを明示的に解放できます。

7.9.1　実行契機

-ehgcオプションを指定してjavagcコマンドを実行したタイミングで，解放処理が実行されます。

注意事項

javagcコマンドによるExplicitメモリブロックの解放処理では，FullGCが実行されます。このため，動作中のアプリケーションに対する処理には適していません。アプリケーションのアンデプロイ時や夜間など，アプリケーションが動作していない時間帯に実行することをお勧めします。

7.9.2　実行される内容

javagcコマンドを実行すると，JavaVMによってFullGCが実行され，拡張verbosegc情報にGCの要因として「EMJavaGC Command」が出力されます。そのあと，次に示すExplicitメモリブロックが解放されます。

明示管理ヒープ機能の自動解放機能が有効な場合に，明示解放予約によって予約されたExplicitメモリブロック

明示管理ヒープ自動配置設定ファイル，またはJavaVMで生成されたExplicitメモリブロック

前回の解放処理で解放されなかったExplicitメモリブロック

GCの要因については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGCPrintCause（GC要因内容出力オプション）」を参照してください。

また，次の場合は，解放処理が実行されません。

最大数の制限を超えてExplicitメモリブロックを解放しようとした場合

現存するExplicitメモリブロックの数が1,048,575個の場合が該当します。

明示管理ヒープ機能がオフになっている場合

-XX:-HitachiUseExplicitMemoryオプションが指定されている場合が該当します。

この場合，コンストラクタの実行は成功しますが，無効なExplicitメモリブロック（ExplicitMemoryインスタンス）として扱われます。

7.10　Explicitメモリブロックの自動解放処理に掛かる時間の短縮

ここでは，明示管理ヒープ機能の自動配置機能使用時に，Explicitメモリブロックの自動解放処理に掛かる時間を短縮する機能について説明します。自動解放処理時間の短縮には，Explicitメモリブロックへのオブジェクト移動制御機能と，この機能に加えて明示管理ヒープ機能適用除外クラス指定機能を使用します。Explicitメモリブロックへのオブジェクト移動制御機能は，明示管理ヒープ機能適用除外クラス指定機能の前提となる機能です。

これらの機能を使用すると，GC発生時に，自動配置機能で配置したオブジェクトから参照されているオブジェクトが，JavaヒープからExplicitメモリブロックへ参照関係に基づいた移動をしなくなり，Explicitヒープ領域の使用量が少なくなります。これによって，Explicitメモリブロックの自動解放処理に掛かる時間を短縮できます。オブジェクトの参照関係に基づいた移動については，「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

7.10.1　適用効果があるかどうかの確認

Explicitメモリブロックへのオブジェクト移動制御機能は，FullGC発生時にオブジェクトがExplicitヒープへ移動しないようにする機能です。この機能を適用して効果があるかどうかは，スレッドダンプに含まれるExplicitメモリブロック情報と，明示管理ヒープ機能のイベントログを確認することで判定できます。Tenured領域の使用量が少なく，次の条件を満たすExplicitメモリブロックがある場合は適用効果がありますので，機能の利用を検討してください。

Explicitメモリブロック情報の<EM_NAME>が「NULL」である（一度自動解放処理を実施したExplicitメモリブロックである）。

Explicitメモリブロック情報の<EH_TOTAL>の値が，ほかのExplicitメモリブロックに比べると，極端に大きいExplicitメモリブロックがある。

FullGC発生時に出力される明示管理ヒープ機能のイベントログで，<EH_USED_AF>が<EH_USED_BF>に比べて大幅に増加している。

明示管理ヒープ機能適用除外クラス指定機能は，オブジェクト移動制御機能を利用してもExplicitメモリブロックの自動解放処理に時間が掛かるような場合に，要因となるオブジェクトを指定してExplicitヒープへ移動しないようにする機能です。明示管理ヒープ機能適用除外クラス指定機能を適用すると，設定ファイルに指定したクラスのオブジェクトが適用除外対象になります。この機能を適用して効果があるかどうかは，スレッドダンプに含まれるExplicitメモリブロック情報を確認することで判定できます。Tenured領域の使用量が少なく，Explicitメモリブロック内に次の条件を満たすクラスがある場合は適用効果がありますので，機能の利用を検討してください。

Explicitメモリブロック情報の<EM_NAME>が「NULL」である（一度自動解放処理を実施したExplicitメモリブロックである）。

Explicitメモリブロック情報の<EH_TOTAL>の値が，ほかのExplicitメモリブロックに比べると，極端に大きいExplicitメモリブロックがある。

Explicitメモリブロック情報にある，オブジェクト統計情報の<ISIZE>の値が大きく，オブジェクト解放率情報の<FRATIO>の値が低いオブジェクトがあり，そのクラスはJava SEが提供しているクラス以外である。

スレッドダンプに含まれるExplicitメモリブロック情報の出力内容については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.5　JavaVMのスレッドダンプ」を参照してください。また，明示管理ヒープ機能のイベントログについては，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.11　明示管理ヒープ機能のイベントログ」を参照してください。

7.10.2　自動解放処理に掛かる時間を短縮する仕組み

明示管理ヒープ機能では，長寿命オブジェクトのうち，一定期間で不要となるオブジェクトをExplicitヒープに配置して解放処理で回収することで，FullGCの発生を抑止しています。また，Explicitヒープに配置したオブジェクトと参照関係にあるオブジェクトは，生存期間が一致しやすいことから，JavaヒープからExplicitメモリブロックへ参照関係に基づいて移動し，Explicitヒープでまとめて管理する仕組みになっています。

しかし，運用によっては，Explicitメモリブロックへ移動したオブジェクトが，Explicitメモリブロックのサイズを巨大化させ，それが原因で自動解放処理が長時間化することがあります。Explicitメモリブロックの自動解放処理中はシステムが停止するため，自動解放処理の長時間化がシステム上問題となることがあります。巨大なサイズのExplicitメモリブロックのことを巨大ブロックといいます。参照関係に基づいた移動によって，寿命の異なるオブジェクトが一つのブロックに移動し，この繰り返しによってブロックは巨大化します。参照関係が複雑で，アプリケーション開発者が参照関係を把握できないような場合に，巨大ブロックが発生しやすくなります。

注意事項

Javaオブジェクトには，次の表に示す種類があります。Javaオブジェクトの種類によってその寿命は異なり，Explicitヒープに配置するのが適切なものと適切でないものがあります。

表7‒8　Javaオブジェクトの種類

項番

分類

オブジェクトの種別

解放されるタイミング

配置に適切なメモリ領域

1

短寿命オブジェクト

リクエスト処理やレスポンス処理など一時的に利用するオブジェクト

CopyGC発生時

Javaヒープ（New領域）※1

2

長寿命オブジェクト

一定期間で不要となるオブジェクト

自動解放処理時

Explicitヒープ

3

アプリケーションの動作に必要でアプリケーションの停止まで使用されるオブジェクト

アプリケーション停止時

Javaヒープ（Tenured領域）※2

注※1　Explicitヒープに配置すると，Explicitメモリブロックの生成とその自動解放処理が多発してオーバーヘッドが掛かってしまうため，適切ではありません。

注※2　Explicitヒープに配置すると，巨大ブロック生成の要因となり，自動解放処理が長時間化してしまうため，適切ではありません。

機能を利用しない場合と利用する場合の比較によって，自動解放処理に掛かる時間を短縮する仕組みを説明します。

(1)　Explicitメモリブロックへのオブジェクト移動制御機能と，明示管理ヒープ機能適用除外クラス指定機能を利用していない場合

Explicitメモリブロックへのオブジェクト移動制御機能と，明示管理ヒープ機能適用除外クラス指定機能を利用しない場合の仕組みについて説明します。オブジェクトを参照関係に基づいて移動するExplicitメモリブロックが三つある場合の例を次の図に示します。

図7‒14　Explicitメモリブロックへのオブジェクト移動制御機能と，明示管理ヒープ機能適用除外クラス指定機能を利用していない場合

Explicitメモリブロックへのオブジェクト移動制御機能と，明示管理ヒープ機能適用除外クラス指定機能を利用していない場合は，GCが発生したときに，オブジェクトは参照関係に基づいてJavaヒープからExplicitメモリブロックへ移動します。Explicitメモリブロック1の場合，移動したオブジェクトがアプリケーションの停止まで使用されるオブジェクトであり，自動解放処理で回収されないため，Explicitメモリブロックに残り続けます。この図に示す段階では，Explicitメモリブロック1のオブジェクトの総サイズは巨大でないため，問題はありません。しかし，オブジェクトの参照関係によっては，GCが発生するたびに，参照先のオブジェクトが参照関係に基づいてExplicitメモリブロックへ移動します。この参照関係に基づいた移動がアプリケーション停止時まで続くことで，Explicitメモリブロック1は巨大ブロックとなるおそれがあります。Explicitメモリブロック2の場合，移動したオブジェクトが巨大サイズであるため，巨大ブロックとなります。このようにExplicitヒープに適切でないオブジェクトが多量に配置されると，Explicitメモリブロックが巨大ブロックとなり，自動解放処理が長時間化します。

(2)　Explicitメモリブロックへのオブジェクト移動制御機能を利用している場合

Explicitメモリブロックへのオブジェクト移動制御機能を利用している場合の仕組みについて説明します。オブジェクトを参照関係に基づいて移動するExplicitメモリブロックが三つある場合の例を次の図に示します。

図7‒15　Explicitメモリブロックへのオブジェクト移動制御機能を利用している場合

Explicitメモリブロックへのオブジェクト移動制御機能を利用している場合，FullGCが発生しても，オブジェクトはJavaヒープからExplicitメモリブロックへ参照関係に基づいた移動をしません。この機能を利用すると，Javaヒープに配置するオブジェクトが増加するため，Javaヒープ領域のメモリサイズの再設定が必要となる場合もあります。

なお，この機能を利用しても，巨大ブロックが生成される場合は，明示管理ヒープ機能適用除外クラス指定機能を利用します。

(3)　Explicitメモリブロックへのオブジェクト移動制御機能に加えて明示管理ヒープ機能適用除外クラス指定機能を利用している場合

Explicitメモリブロックへのオブジェクト移動制御機能に加えて明示管理ヒープ機能適用除外クラス指定機能を利用している場合の仕組みについて説明します。オブジェクトを参照関係に基づいて移動するExplicitメモリブロックが三つある場合の例を次の図に示します。ここでは，Explicitメモリブロック1とExplicitメモリブロック2に移動するオブジェクトのクラスが，明示管理ヒープ機能適用外設定ファイルに設定されているとします。

図7‒16　Explicitメモリブロックへのオブジェクト移動制御機能に加えて明示管理ヒープ機能適用除外クラス指定機能を利用している場合

明示管理ヒープ機能適用除外クラス指定機能を利用している場合，明示管理ヒープ機能適用除外設定ファイルに指定したクラスのオブジェクトは，明示管理ヒープ機能の対象から除外され，CopyGCが発生しても，JavaヒープからExplicitメモリブロックへ移動しません。このオブジェクトは，昇格するタイミングでTenured領域へ移動します。この機能を利用すると，Javaヒープに配置するオブジェクトが増加するため，Javaヒープ領域のメモリサイズの再設定が必要となる場合もあります。

明示管理ヒープ機能適用除外クラス指定機能で利用する，明示管理ヒープ機能適用除外設定ファイルには，次の2種類があります。

システムで提供している明示管理ヒープ機能適用除外設定ファイル（sysexmemexcludeclass1100.cfg）

-XX:ExplicitMemoryExcludeClassListFileオプションにファイルパスを指定した，明示管理ヒープ機能適用除外設定ファイル（exmemexcludeclass.cfg，または任意のファイル名）

明示管理ヒープ機能適用除外クラス指定機能を利用する設定を（-XX:+ExplicitMemoryUseExcludeClassオプションを指定）すると，sysexmemexcludeclass1100.cfgに設定されているクラスは，自動的に明示管理ヒープ機能適用除外対象となり，そのクラスのオブジェクトはExplicitヒープへ移動しません。さらに適用除外対象のオブジェクトを指定したい場合は，exmemexcludeclass.cfg，または任意のファイル名の明示管理ヒープ機能適用除外設定ファイルに，適用除外対象のオブジェクトのクラスを指定します。また，sysexmemexcludeclass1100.cfgに設定されているクラスのオブジェクトに対して明示管理ヒープ機能を適用したい場合は，明示管理ヒープ機能適用除外無効設定ファイル（exmemnotexcludeclass.cfg）にそのクラスを指定します。このため，設定ファイルに指定するクラスによっては，Explicitヒープへ移動するオブジェクトを少なくできます。明示管理ヒープ機能適用除外クラスは，スレッドダンプに出力されるExplicitヒープ情報のオブジェクト解放率を参考に指定します。オブジェクト解放率については，「7.10.3　Explicitメモリブロックのオブジェクト解放率情報の利用」を参照してください。

なお，参照経路が明示管理ヒープ機能適用除外対象のオブジェクトを経由するオブジェクトのうち，明示管理ヒープ機能適用除外対象のオブジェクト以外の経路から参照されないオブジェクトも明示管理ヒープ機能適用除外対象となります。明示管理ヒープ機能適用除外対象のオブジェクトからの参照経路が複数ある場合の例を次の図に示します。

図7‒17　明示管理ヒープ機能適用除外対象のオブジェクトからの参照経路が複数ある場合の例

この図の場合，オブジェクトBは明示管理ヒープ機能適用除外対象のオブジェクトです。オブジェクトBを経由する参照経路には，次のものがあります。

A→B→C1

A→B→C2

A→B→C3

このうち，オブジェクトC1にはD→C1，オブジェクトC3にはE→C3の参照経路があるため，これらのオブジェクトは参照関係に基づいてExplicitメモリブロックへ移動します。一方，オブジェクトC2はオブジェクトBを経由する以外の参照経路がないため，明示管理ヒープ機能適用除外対象となってExplicitメモリブロックへ移動しません。

7.10.3　Explicitメモリブロックのオブジェクト解放率情報の利用

Explicitメモリブロックの自動解放処理が長時間化する要因となる巨大ブロックは，アプリケーションの停止まで使用される長寿命のオブジェクトがユーザプログラムやフレームワークの利用によって生成され，配置されることで生成されます。明示管理ヒープ機能を効果的に使用するためには，この巨大ブロックを生成する要因となるオブジェクトを特定して，Explicitヒープに配置しないようにすることが必要になります。

(1)　Explicitメモリブロックのオブジェクト解放率情報の出力

巨大ブロックを生成する要因となるオブジェクトは，オブジェクト解放率情報を利用すると特定できます。オブジェクト解放率情報は，Explicitメモリブロックの自動解放処理で解放されたオブジェクトの割合です。巨大ブロック上で解放率が低いオブジェクトは，巨大ブロックを生成する要因となるオブジェクトであることがわかります。オブジェクト解放率情報は，eheapprofコマンドに-freeratioオプションを指定して実行すると，拡張スレッドダンプのExplicitヒープ情報に出力できます。この情報を参考にして，そのオブジェクトのクラスを明示管理ヒープ機能適用除外設定ファイルに指定します。明示管理ヒープ機能適用除外設定ファイルへの指定方法については，「7.13.3　設定ファイルを使った明示管理ヒープ機能の適用対象の制御」を参照してください。

オブジェクト解放率情報の出力例を次の図に示します。

図7‒18　オブジェクト解放率情報の出力例

この図に示すように，JavaVMは，オブジェクト解放率情報を求めるために，FullGCと，Explicitメモリブロックの自動解放処理を実行します。これらの処理によって，アプリケーションの実行が数秒間止まるおそれがあるため，オブジェクト解放率情報は，システム開発時や業務停止時間中に出力することをお勧めします。

また，ここで出力されるオブジェクト解放率情報は，情報出力時に発生させた自動解放処理1回の結果を基に算出したものです。このため，オブジェクト解放率情報の精度を上げるためには，複数回取得することをお勧めします。

(2)　実行される内容

eheapprofコマンドに-freeratioオプションを指定して実行すると，JavaVMによって次の処理が実行されます。

FullGCの発生

自動配置機能で生成したExplicitメモリブロック，およびeheapprofコマンド実行前に明示解放予約されたExplicitメモリブロックに対する自動解放予約

自動解放予約の対象とならなかったExplicitメモリブロックのオブジェクト解放率には，「-」が出力されます。

2.で自動解放予約されたExplicitメモリブロックに対する自動解放処理

JavaVMは，自動解放処理の前後でExplicitメモリブロック単位にクラスごとのオブジェクト数情報を取得して保持します。

3.で取得した情報から算出したオブジェクト解放率情報の拡張スレッドダンプへの出力

オブジェクト解放率情報の算出例を次の図に示します。

図7‒19　オブジェクト解放率情報の算出例

外部（解放対象外のExplicitメモリブロック）から参照されているオブジェクトがある場合は，自動解放処理時に新規のExplicitメモリブロックへ移動します。Explicitメモリブロック6のように，自動解放前が複数のExplicitメモリブロックのときは，複数のExplicitメモリブロックのオブジェクト数の合計値と，新規のExplicitメモリブロックのオブジェクト数からオブジェクト解放率を算出します。

なお，eheapprofコマンドの指定方法，およびExplicitヒープ情報の出力内容については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「eheapprof（Explicitヒープ詳細情報付き拡張スレッドダンプの出力）」を参照してください。

7.10.4　自動解放処理に掛かる時間を短縮する場合の注意事項

ここでは，自動解放処理に掛かる時間を短縮する場合に使用する，Explicitメモリブロックへのオブジェクト移動制御機能，および明示管理ヒープ機能適用除外クラス指定機能使用時の注意事項について説明します。

Explicitメモリブロックへのオブジェクト移動制御機能は，自動配置機能で作成したExplicitメモリブロックにあるオブジェクトから参照されているJavaヒープのオブジェクトを，FullGC発生時にExplicitヒープへ移動しないようにします。この機能を有効にすると，これまでFullGCが発生していたシステムでは，FullGCの発生回数が増加することがあります。FullGCの発生回数がシステム上問題となる場合は，JavaVMで使用する領域のメモリサイズを再度チューニングしてください。メモリチューニングについては，マニュアル「アプリケーションサーバシステム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

明示管理ヒープ機能適用除外クラス指定機能は，自動配置機能で作成したExplicitメモリブロックにあるオブジェクトから参照されているJavaヒープのオブジェクトのうち，設定ファイルに指定されているクラスのオブジェクトをExplicitヒープに移動しないようにします。この機能を有効にすると，Explicitヒープへ移動していたオブジェクトがTenured領域に移動するため，Tenured領域の使用量が増加します。このため，FullGCの発生回数が増加するおそれがあります。FullGCの発生回数がシステム上問題になる場合は，JavaVMで使用する領域のメモリサイズを再度チューニングしてください。メモリチューニングについては，マニュアル「アプリケーションサーバシステム設計ガイド」の「7.　JavaVMのメモリチューニング」を参照してください。

明示管理ヒープ機能適用除外クラス指定機能は，J2EEサーバまたはバッチサーバ起動時に設定ファイルを読み込みます。そのため，多量のクラスを設定ファイルに指定すると，J2EEサーバまたはバッチサーバの起動時間が長くなるおそれがあります。J2EEサーバまたはバッチサーバの起動時間と，自動解放処理時間などを比較して，この機能の利用を検討してください。

明示管理ヒープ機能適用除外クラス指定機能は，クラスロード時に明示管理ヒープ機能適用除外対象かどうかを判定します。そのため，多量のクラスを設定ファイルに指定すると，クラスロード時間が増加するおそれがあります。

明示管理ヒープ機能適用除外クラス指定機能は，設定ファイルで指定したクラスのオブジェクトを明示管理ヒープ機能の対象から除外します。そのため，Explicitヒープに配置すると効果があるオブジェクトのクラスを設定ファイルに指定してしまうと，FullGC抑止の効果が得られないおそれがあります。

明示管理ヒープ機能適用除外クラス指定機能は，「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を実行しないことで，明示管理ヒープ機能適用対象外のオブジェクトとします。このため，アプリケーションでオブジェクトの直接生成を指定した場合，そのオブジェクトのクラスを明示管理ヒープ機能適用除外クラスに指定しても，Explicitメモリブロックに生成されます。アプリケーションでのオブジェクトの直接生成については，「7.6.3　Explicitメモリブロックへのオブジェクトの直接生成」を参照してください。

なお，HTTPセッションに格納されたオブジェクトを明示管理ヒープ機能適用除外クラスに指定した場合は，明示管理ヒープ機能適用除外対象となり，Explicitメモリブロックへ移動しません。HTTPセッションに格納されたオブジェクトについては，「7.4.1　HTTPセッションに関するオブジェクト」を参照してください。

アプリケーションのデバック時などにGCを抑止している間は，FullGCも自動解放処理も実行できません。GCを抑止している間に，-freeratioオプションを指定してeheapprofコマンドを実行してもオブジェクト解放率情報が取得できないため，スレッドダンプのExplicitヒープ詳細情報には，Explicitメモリブロック内のオブジェクト統計情報だけが出力され，オブジェクト解放率情報は出力されません。

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

ここでは，HTTPセッションで利用するExplicitヒープのメモリ使用量を削減する機能について説明します。メモリ使用量の削減には，HTTPセッションで利用するExplicitヒープの省メモリ化機能を使用します。

この機能を使用すると，アプリケーションサーバ内でのHTTPセッションとExplicitメモリブロックの関係が多対1になります。複数のHTTPセッションで一つのExplicitメモリブロックを共有できるため，Explicitメモリブロックの利用率が向上します。これによって，HTTPセッションが確保するExplicitヒープのメモリ使用量を削減できます。

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

HTTPセッションで利用するExplicitヒープの省メモリ化機能を適用して効果があるかどうかは，スレッドダンプに含まれるExplicitメモリブロック情報を確認することで判定できます。次の条件を満たすExplicitメモリブロックが多数ある場合は，適用効果がありますので，この機能の利用を検討してください。

Explicitメモリブロック情報の<EM_TYPE>が「R」である。

<EM_USED>が，次に示すサイズよりも小さいExplicitメモリブロックが多数ある。

明示管理ヒープ機能の自動配置機能を利用している場合

8KB

明示管理ヒープ機能の自動配置機能を利用していない場合

32KB

スレッドダンプでのExplicitメモリブロック情報の出力内容については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.5　JavaVMのスレッドダンプ」を参照してください。

なお，稼働情報によるExplicitヒープ領域のメモリサイズの見積もりについては, この機能を利用するかどうかによる違いはありません。見積もり方法については，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.11.4　稼働情報による見積もり」を参照してください。

ただし，稼働情報ファイルの出力内容については，一部違いがあります。違いについては，「7.11.3　HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項」を参照してください。

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

HTTPセッションが格納されるExplicitヒープ領域のExplicitメモリブロックは，アプリケーションがHTTPセッションを作成するたびに作成されます。HTTPセッションに関するオブジェクトは，作成されたExplicitメモリブロックに配置されます。

この機能を利用しない場合と利用する場合の比較によって，メモリ使用量を削減する仕組みを説明します。

(1)　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用しない場合

HTTPセッションに関するオブジェクトが格納されるExplicitメモリブロックが三つある場合の例を次の図に示します。このうち，BとCのExplicitメモリブロックは，利用率が低く，長時間利用されていないHTTPセッションに関連づけられたExplicitメモリブロックです。

図7‒20　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があります。

図7‒21　HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用している場合

HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用している場合，自動解放が発生したタイミングで，HTTPセッションで利用するExplicitヒープの省メモリ化機能が実行されます。利用率が低いExplicitメモリブロックであるBおよびCが解放され，このExplicitメモリブロックに格納されていたHTTPセッションに関するオブジェクトはDに移動します。

このように，利用率の低いExplicitメモリブロックに格納されていたオブジェクトをほかの領域に移動して集約して，利用率の低いExplicitメモリブロックを解放することで，Explicitメモリブロックの利用率が向上します。

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

ここでは，HTTPセッションで利用するExplicitヒープの省メモリ化機能利用時の注意事項について説明します。

HTTPセッションで利用するExplicitヒープの省メモリ化機能を利用しているかどうかによって，稼働情報ファイルの出力内容が一部異なります。

参考

ここで説明する違いによって，解放されるExplicitメモリブロックに格納されるHTTPセッションに関するオブジェクトのメモリサイズを計上する領域が，HTTPセッションで利用する領域からアプリケーションで利用する領域に変更になります。ただし，システム全体で使用するメモリサイズには変更ありません。このため，この機能を利用するかどうかは，稼働情報を使用したExplicitヒープ領域のメモリサイズの見積もりには影響ありません。

出力内容が異なる項目について説明します。

(1)　HTTPセッションで取得したExplicitメモリブロックの個数

次の項目に出力されるExplicitメモリブロックの個数が異なります。

HTTPSessionEMemoryBlockCount.HighWaterMark

HTTPSessionEMemoryBlockCount.LowWaterMark

HTTPSessionEMemoryBlockCount.Current

この機能を利用していない場合

システムで有効なHTTPセッション数が出力されます。

この機能を利用している場合

内部動作を反映した値が出力されるため，システムで有効なHTTPセッション数とは異なる値が出力されます。

(2)　アプリケーションで利用するExplicitヒープ領域のサイズ

次の項目に出力されるExplicitヒープ領域のサイズが異なります。

ApplicationEHeapSize.HighWaterMark

ApplicationEHeapSize.LowWaterMark

この機能を利用していない場合

自動配置機能で利用されるExplicitメモリのサイズが出力されます。

この機能を利用している場合

「この機能が自動解放対象としたExplicitメモリのサイズ＋自動配置機能で利用するExplicitメモリのサイズ」の合計サイズとなります。

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

この節では，アプリケーションで明示管理ヒープ機能を使用する場合の実装について説明します。明示管理ヒープ機能は，明示管理ヒープ機能APIを使用して実装します。

明示管理ヒープ機能は，JP.co.Hitachi.soft.jvm.MemoryAreaパッケージ内のクラスで使用できます。APIの詳細については，マニュアル「アプリケーションサーバ リファレンス API編」を参照してください。なお，明示管理ヒープ機能APIは，すべてスレッドセーフです。

明示管理ヒープ機能APIでは，次の2種類の処理を実装します。

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

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

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

ここでは，明示管理ヒープ機能APIのクラスの概要と，APIの基本的な利用方法について説明します。

(1)　ExplicitMemoryインスタンスとExplicitメモリブロックの関係

Explicitヒープ内のExplicitメモリブロックは，明示管理ヒープ機能APIで扱うExplicitMemoryクラスのインスタンスと1：1で対応します。

ExplicitMemoryインスタンスとExplicitメモリブロックの関係を次の図に示します。

図7‒22　ExplicitMemoryインスタンスとExplicitメモリブロックの関係

Explicitメモリブロックは，ExplicitMemoryクラスのコンストラクタを実行すると初期化されます。以降は，初期化されたインスタンスが，Explicitメモリブロックを操作するためのインタフェースになります。図の場合は，インスタンスem1がExplicitメモリブロック1に，インスタンスem2がExplicitメモリブロック2に対応しています。

(2)　明示管理ヒープ機能APIのクラス構成

明示管理ヒープ機能APIのクラスを次の表に示します。

表7‒9　明示管理ヒープ機能APIのクラス

クラス

説明

MemoryAreaクラス

JavaヒープまたはExplicitメモリブロックを表現する抽象クラスです。

ExplicitMemoryクラス

Explicitメモリブロックを表現する抽象クラスです。このクラスの機能は，派生クラスであるBasicExplicitMemoryクラスを介して利用します。

BasicExplicitMemoryクラス

アプリケーションで扱うExplicitメモリブロックを表現するクラスです。アプリケーションでは，このクラスのAPIを使用して明示管理ヒープ機能を実装します。

クラスの階層を次の図に示します。

図7‒23　明示管理ヒープ機能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行目になります。

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

ここでは，アプリケーションで明示管理ヒープ機能の稼働情報を取得するための実装について説明します。稼働情報を取得することで，デバッグや障害解析を実行できます。

アプリケーションで明示管理ヒープ機能を実装している場合，稼働情報として次の情報を取得できます。

Explicitヒープの利用状況

ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

Explicitメモリブロックの情報

また，稼働情報の取得に関連した処理として，次の処理も実行できます。

Explicitメモリブロックの名前の設定と取得

Explicitメモリブロックの処理可能状態の判定

Explicitメモリブロックの解放予約状態の判定

ここでは，明示管理ヒープ機能APIを使用した，それぞれの処理の実装について説明します。

(1)　Explicitヒープの利用状況の取得

Explicitヒープの情報を取得方法について説明します。Explicitヒープは，Explicitメモリブロック全体のことです。なお，各Explicitメモリブロックの情報を取得する方法については，「7.12.2(3)　Explicitメモリブロックの情報の取得」を参照してください。

使用するAPI

getMemoryUsage()

このAPIは，java.lang.management.MemoryUsageクラスのインスタンスを作成して，そのインスタンスを返却します。

返却されたインスタンスの各フィールドには，インスタンス作成時の情報として，次の表に示す情報が設定されています。

表7‒10　各フィールドの情報（MemoryUsageクラスのインスタンス）

フィールド

設定内容

init

0

used

Explicitヒープの使用されているメモリのサイズ（単位：バイト）

committed

Explicitヒープの確保済みサイズ（単位：バイト）

max

-XX:HitachiExplicitHeapMaxSizeで指定した最大Explicitヒープサイズの値（単位：バイト）

ただし，明示管理ヒープ機能がオフの場合（-XX:-HitachiUseExplicitMemoryが設定されている場合）は，0になります。

各フィールドが示す値を次の図に示します。

図7‒24　各フィールドが示す値（MemoryUsageクラスのインスタンス）

(2)　ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ

Explicitメモリブロックの利用状況として，ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズを取得します。これによって明示管理ヒープ機能でのメモリの使用状況をチェックできます。

使用するAPI

freeMemory()

usedMemory()

totalMemory()

それぞれのAPIで取得できるExplicitメモリブロックの利用状況を次の表に示します。なお，サイズは，long型の値として取得できます。

表7‒11　各APIで取得できるExplicitメモリブロックの利用状況

API

取得できるExplicitメモリブロックの利用状況

freeMemory()

メモリの利用可能なサイズ（単位：バイト）

usedMemory()

使用されているメモリのサイズ（単位：バイト）

totalMemory()

確保済み総サイズ（単位：バイト）

各APIで取得できる値を次の図に示します。

図7‒25　各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メモリブロックです。

(5)　Explicitメモリブロックの処理可能状態の判定

Explicitメモリブロックは，メモリ確保に失敗した場合などに処理不能な状態になることがあります。Explicitメモリブロックが処理可能な状態かどうかを判定できます。

使用するAPI

isActive()

APIを呼び出したときのExplicitメモリブロック（ExplicitMemoryインスタンス）の状態と，APIの戻り値の対応を次の表に示します。

表7‒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の戻り値の対応を次の表に示します。

表7‒13　isReclaimed()を呼び出したときのExplicitメモリブロックの状態とAPIの戻り値の対応

Explicitメモリブロックの状態

サブ状態

戻り値

解放済み

−

true

無効

−

true

解放予約済み

−

true

有効

Enable

false

Disable

false

（凡例）

−：該当しません。

7.13　実行環境での設定

この節では，明示管理ヒープ機能を利用するための実行環境での設定について説明します。

注意事項

J2EEサーバでは，デフォルトでHTTPセッションに関するオブジェクトをExplicitヒープ領域に配置する設定になっています。

運用を開始する前に，必要なExplicitヒープサイズを見積もり，JavaVMオプション（-XX:HitachiExplicitHeapMaxSizeオプション）を適切な値にチューニングしてください。Explicitヒープのチューニングについては，マニュアル「アプリケーションサーバシステム設計ガイド」の「7.3.2　チューニング手順」を参照してください。

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

ここでは，明示管理ヒープ機能を利用するための共通の設定について説明します。

明示管理ヒープ機能を利用する場合，次の設定が必要です。

J2EEサーバ

バッチサーバ

Javaアプリケーション

自動配置設定ファイルの設定

また，明示管理ヒープ機能の適用対象を制御する場合，次の設定が必要です。

明示管理ヒープ機能適用除外設定ファイルの設定

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。

明示管理ヒープ機能を使用するための共通の設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のJavaVM起動パラメタ（add.jvm.arg）でJavaVMのオプションを指定します。

明示管理ヒープ機能のJavaVMオプションの定義について次の表に示します。

表7‒14　明示管理ヒープ機能のJavaVMオプションの定義

JavaVMオプション

設定内容

デフォルト値

（JDK17インストール環境では指定なし）

-XX:[+|-]HitachiUseExplicitMemory

明示管理ヒープ機能を使用するかどうかを設定します。

新規インストールの場合

実行環境によって異なります※1。

バージョンアップの場合

-XX:-HitachiUseExplicitMemory

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

Explicitヒープ領域の最大サイズを設定します。（単位：バイト）

-XX:HitachiExplicitHeapMaxSize =64m

-XX:HitachiExplicitMemoryLogLevel:<文字列>

<文字列>に明示管理ヒープ機能で出力するイベントログのログレベルを設定します。

次のどれかを指定します。

none

normal

verbose

debug

-XX:HitachiExplicitMemoryLogLevel:normal

-XX:HitachiExplicitMemoryJavaLog:<文字列>

<文字列>に明示管理ヒープ機能で出力するイベントログの出力先パス名を指定します。

Windowsの場合

-XX:HitachiExplicitMemoryJavaLog:<Application Serverのインストールディレクトリ>¥CC¥server¥public¥ejb¥<サーバ名>¥logs

UNIXの場合

-XX:HitachiExplicitMemoryJavaLog:/opt/Cosminexus/CC/server/public/ejb/<サーバ名>/logs

-XX:HitachiExplicitMemoryJavaLogFileSize=<整数値>

<整数値>にイベントログのファイルサイズを指定します。（単位：バイト）

-XX:HitachiExplicitMemoryJavaLogFileSize =4m

-XX:ExplicitMemoryFullGCPolicy=<数値>

FullGC発生時に，参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動を制御するかどうかを指定します。

-XX:ExplicitMemoryFullGCPolicy=0

-XX:[+|-]ExplicitMemoryUseExcludeClass

明示管理ヒープ機能適用除外クラス指定機能を有効にするかどうかを指定します。

推奨モードの場合

-XX:+ExplicitMemoryUseExcludeClass

-XX:ExplicitMemoryExcludeClassListFile:<文字列>

明示管理ヒープ機能適用除外クラス指定機能を使用する場合に利用する，明示管理ヒープ機能適用除外設定ファイルのパスを指定します。

空文字

-XX:ExplicitMemoryNotExcludeClassListFile:<文字列>

明示管理ヒープ機能適用除外クラス指定機能を使用する場合に利用する，明示管理ヒープ機能適用除外無効設定ファイルのパスを指定します。

空文字

注※1

新規インストールの場合，実行環境によってデフォルト値は次のように異なります。

J2EEサーバの場合

　-XX:+HitachiUseExplicitMemory

バッチサーバおよびJavaアプリケーションの場合

　-XX:-HitachiUseExplicitMemory

注※2

見積もりについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.11　Explicitヒープのチューニング」を参照してください。

簡易構築定義ファイルでの定義例を次に示します。

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

参考

J2EEサーバの設定は，運用管理ポータルの［起動パラメタの設定］画面（論理J2EEサーバの定義）でも設定できます。運用管理ポータルでの設定方法については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「10.8.23　起動パラメタの設定（J2EEサーバ）」を参照してください。

指定するJavaVMオプション，および簡易構築定義ファイルで指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

(2)　バッチサーバの設定

バッチサーバの設定は，簡易構築定義ファイルで実施します。

明示管理ヒープ機能を使用するための共通の設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のJavaVM起動パラメタ（add.jvm.arg）でJavaVMのオプションを指定します。

指定するJavaVMのオプションは，「(1)　J2EEサーバの設定」を参照してください。

(3)　Javaアプリケーションの設定

cjclstartapコマンドで動作させるJavaアプリケーションの設定は，Javaアプリケーション用オプション定義ファイル（usrconf.cfg）で実施します。

明示管理ヒープ機能を使用するための共通の設定は，Javaアプリケーション用オプション定義ファイル（usrconf.cfg）のJavaVM起動パラメタ（add.jvm.arg）でJavaVMのオプションを指定します。

指定するJavaVMのオプションは，「(1)　J2EEサーバの設定」を参照してください。

Javaアプリケーション用オプション定義ファイル（usrconf.cfg）での定義例を次に示します。

add.jvm.arg=-Xms512m
add.jvm.arg=-Xmx512m

add.jvm.arg=-XX:+HitachiUseExplicitMemory
add.jvm.arg=-XX:HitachiExplicitHeapMaxSize=64m

Javaアプリケーション用オプション定義ファイル（usrconf.cfg）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.1　usrconf.cfg（Javaアプリケーション用オプション定義ファイル）」を参照してください。

(4)　自動配置設定ファイルの設定

自動配置設定ファイルを使用して明示管理ヒープ機能を利用する場合，-XX:+HitachiAutoExplicitMemoryオプションを指定し，Explicitヒープに配置したいオブジェクトの設定が必要です。

Explicitヒープに配置したいオブジェクトの設定は，簡易構築定義ファイルの論理J2EEサーバ（J2EE-Server）の<configuration>タグ内にAutoExplicitMemoryTextパラメタで指定します。

定義例を次に示します。

　：
<param>
<param-name>AutoExplicitMemoryText</param-name>
<param-value>
<![CDATA[
com.sample.*, java.util.ArrayList
com.sample.Main.main(java.lang.String[]), java.util.LinkedList
]]>
</param-value>
</param>
　：

自動配置設定ファイルの作成方法については，「7.13.2　自動配置設定ファイルを使った明示管理ヒープ機能の使用」を参照してください。

自動配置設定ファイルは，運用管理ポータルの［起動パラメタの設定］画面（論理J2EEサーバの定義）またはユーザ任意のファイル（-XX:HitachiAutoExplicitMemoryFileプロパティで指定したファイル）でも設定できます。

(5)　明示管理ヒープ機能適用除外設定ファイルの設定

明示管理ヒープ機能適用除外設定ファイルを使用し，参照関係に基づく移動の対象となるオブジェクトに対して明示管理ヒープ機能の適用を制御する場合は，次のオプションの指定と，Explicitヒープに移動しないクラスの設定が必要です。

-XX:ExplicitMemoryFullGCPolicy=0

-XX:+ExplicitMemoryUseExcludeClass

Explicitヒープに移動しないクラスの設定は，明示管理ヒープ機能適用除外設定ファイルに記述します。

記述例を次に示します。

com.sample.ClassA
com.sample.ClassB

また，明示管理ヒープ機能適用除外設定ファイルに記述しているクラスのうち，一部のクラスをExplicitヒープに移動したい場合は，明示管理ヒープ機能適用除外無効設定ファイルに，明示管理ヒープ機能適用除外の設定を無効にしたいクラスを記述します。

明示管理ヒープ機能適用除外設定ファイル，および明示管理ヒープ機能適用除外無効設定ファイルの作成方法については，「7.13.3　設定ファイルを使った明示管理ヒープ機能の適用対象の制御」を参照してください。

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

明示管理ヒープ機能の自動配置機能は，自動配置設定ファイルを使って設定します。自動配置設定ファイルを使用することで，Javaプログラムを変更することなく明示管理ヒープ機能を使用できます。

自動配置設定ファイルには，Explicitヒープに配置したいオブジェクト，およびオブジェクトを生成する場所を指定します。なお，このファイルに指定したオブジェクト（Explicitメモリブロックに生成されたオブジェクト）から参照されているオブジェクトは，JavaヒープからExplicitメモリブロックへ移動します。オブジェクトの移動については「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

-XX:+HitachiAutoExplicitMemoryオプションを指定して，自動配置設定ファイルを使用して明示管理ヒープ機能を利用する場合の，自動配置設定ファイルの記述形式および記述する際の注意事項について説明します。

自動配置設定ファイルの内容は次のどれかに記述できます。

簡易構築定義ファイル

運用管理ポータルの［起動パラメタの設定］画面（論理J2EEサーバの定義）

ユーザ任意のファイル（jvm.userprf.Fileプロパティで指定したファイル）

(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の起動時間やアプリケーションサーバでのアプリケーションのデプロイ時間が増加する場合があります。

自動配置機能を使用することで，CopyGCの処理に時間が掛かる場合があります。

自動配置機能の対象となるオブジェクトは，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"と出力されます。このような場合は，クラスやメソッドを小さくすることを検討してください。

7.13.3　設定ファイルを使った明示管理ヒープ機能の適用対象の制御

自動配置機能で作成したExplicitメモリブロックにあるオブジェクトから参照されているオブジェクトは，GC発生時にJavaヒープからExplicitヒープへ参照関係に基づいて移動します。明示管理ヒープ機能適用除外クラス指定機能は，設定ファイルを使って，この参照関係に基づく移動の対象となるオブジェクトを明示管理ヒープ機能の適用対象から除外し，Explicitヒープへ移動させないようにします。この機能を使用すると，アプリケーションの停止まで使用されるオブジェクトなど，FullGCでも回収されないオブジェクトを，明示管理ヒープ機能の適用対象から除外できます。オブジェクトの参照関係に基づいた移動については「7.6.5　参照関係に基づくオブジェクトのJavaヒープからExplicitメモリブロックへの移動」を参照してください。

(1)　設定ファイルの種類

明示管理ヒープ機能適用除外クラス指定機能で使用するファイルには，次の2種類があります。

明示管理ヒープ機能適用除外設定ファイル

Explicitヒープへ移動させたくないオブジェクトのクラスを指定します。このファイルに指定したクラスのオブジェクトは，GCが発生しても，Explicitヒープへ移動しません。昇格するタイミングでTenured領域へ移動します。

明示管理ヒープ機能適用除外設定ファイルには，システムで提供しているファイルがあります。明示管理ヒープ機能適用除外クラス指定機能を有効にすると，システムで提供している明示管理ヒープ機能適用除外設定ファイルが使用されます。システムで提供している明示管理ヒープ機能適用除外設定ファイルのファイルパスを次に示します。

Windowsの場合

<JDKインストールディレクトリ>¥lib¥explicitmemory¥sysexmemexcludeclass1100.cfg

UNIXの場合

/opt/Cosminexus/jdk/lib/explicitmemory/sysexmemexcludeclass1100.cfg

明示管理ヒープ機能の適用対象から除外するクラスを追加したい場合は，次のファイルパスにあるファイルを更新するか，または新たなファイルを作成してください。

Windowsの場合

<JDKインストールディレクトリ>¥usrconf¥exmemexcludeclass.cfg

UNIXの場合

/opt/Cosminexus/jdk/usrconf/exmemexcludeclass.cfg

なお，新たに明示管理ヒープ機能適用除外設定ファイルを作成した場合は，-XX:ExplicitMemoryExcludeClassListFileオプションにファイルパスを指定してください。

明示管理ヒープ機能適用除外無効設定ファイル

明示管理ヒープ機能適用除外設定ファイルに指定したクラスのうち，適用除外設定を無効にしたいクラスを指定します。このファイルに指定したクラスのオブジェクトは，GCが発生すると，Explicitヒープへ移動します。

明示管理ヒープ機能の適用対象から除外されているクラスを無効にしたい場合は，次のファイルパスにあるファイルを更新するか，または新たなファイルを作成してください。システムで提供している明示管理ヒープ機能適用除外設定ファイルに指定されているクラスも設定を無効にできます。

Windowsの場合

<JDKインストールディレクトリ>¥usrconf¥exmemnotexcludeclass.cfg

UNIXの場合

/opt/Cosminexus/jdk/usrconf/exmemnotexcludeclass.cfg

なお，新たに明示管理ヒープ機能適用除外無効設定ファイルを作成した場合は，-XX:ExplicitMemoryNotExcludeClassListFileオプションにファイルパスを指定してください。

(2)　設定ファイルの指定と明示管理ヒープ機能の適用範囲

明示管理ヒープ機能適用除外無効設定ファイルの指定は，明示管理ヒープ機能適用除外設定ファイルの指定よりも優先されます。

パッケージ「com.sample」を例に，設定ファイルの指定と明示管理ヒープ機能の適用範囲について説明します。パッケージ「com.sample」には，ClassAとClassBの二つのクラスがあります。各設定ファイルを次のように指定します。

明示管理ヒープ機能適用除外設定ファイルの指定例

com.sample.*

明示管理ヒープ機能適用除外無効設定ファイルの指定例

com.sample.ClassB

明示管理ヒープ機能適用除外設定ファイルの指定には，ClassAとClassBの両方が含まれています。しかし，明示管理ヒープ機能適用除外無効設定ファイルの指定が優先されるため，次の図のように，明示管理ヒープ機能の適用が除外されるのはClassAだけとなり，ClassBには明示管理ヒープ機能が適用されます。

(3)　設定ファイルの記述形式

設定ファイルの記述形式を次に示します。

配列型以外の場合

<指定したクラスの完全修飾クラス名>※#コメント
：
<指定したクラスの完全修飾クラス名>※

注※

クラス名は，「*」を使用すると省略できます。

配列型の場合

<配列の次元数分の"[">※L<指定したクラスの完全修飾クラス名>;

注※

多次元配列のときは，「[」を次元数分続けて指定します。3次元配列の場合は「[[[」となります。

（例）aaa.bbb.Myclassクラスの1次元配列の場合

[Laaa.bbb.Myclass;

ポイント

クラス名は1行に一つずつ記述します。

1行に記述できる文字数は1,024文字までです。この文字数は空文字やコメントを含みます。1行に1,025文字以上記述すると，パースに失敗してワーニングメッセージを出力し，その行を無視して読み込み処理を続けます。

クラス名は，「<パッケージ名>.*」と指定すると省略できます。Java言語のimport宣言の「*」とは異なり，サブパッケージのクラスも対象となります。

行末は，改行文字（「¥n」もしくは「0x0A」）または復帰文字（「¥r」もしくは「0x0D」）が１文字以上続いたものとなります。

空白文字は，半角スペース文字（「0x20」）またはタブ文字（「¥t」もしくは「0x09」）となります。なお，設定ファイルに空白文字を記述した場合は無視されます。

コメントは，「#」で始まり，「#」から行末までの間の文字すべてをコメントとします。

(4)　設定ファイルの記述例

明示管理ヒープ機能適用除外設定ファイル，および明示管理ヒープ機能適用除外無効設定ファイルの記述例を次に示します。

なお，ここで説明する記述例は，パッケージ名が「com.sample」で，次の図に示すクラス構造とします。

図7‒26　クラス構造の例

完全修飾クラス名で指定する場合

完全修飾クラス名で指定する場合の明示管理ヒープ機能適用除外設定ファイルの記述例を次に示します。

com.sample.aaa.ClassA
com.sample.aaa.ClassC
com.sample.ddd.ClassD

この例では，ClassAクラス，ClassCクラス，およびClassDクラスのオブジェクトがTenured領域へ移動します。

クラス名を省略して指定する場合

クラス名を省略して指定する場合の明示管理ヒープ機能適用除外設定ファイル，および明示管理ヒープ機能適用除外無効設定ファイルの記述例を次に示します。

明示管理ヒープ機能適用除外設定ファイルの記述例

com.sample.*

明示管理ヒープ機能適用除外無効設定ファイルの記述例

com.sample.aaa.ClassB
com.sample.ddd.ClassE

この例では，明示管理ヒープ機能適用除外設定ファイルの記述から，同一パッケージ内のクラスだけでなく，サブパッケージに存在するクラスも含めすべてのクラスがTenured領域への移動対象となります。しかし，明示管理ヒープ機能適用設定ファイルの記述から，ClassBクラスとClassEクラスのオブジェクトがExplicitメモリブロックへの移動対象となります。このため，ClassAクラス，ClassCクラス，およびClassDクラスのオブジェクトがTenured領域へ移動します。

ポイント

完全修飾クラス名で指定するか，またはクラス名を省略して指定するかは，設定ファイルの記述量が少ない方で指定することをお勧めします。記述例はどちらも同じ制御となります。この場合は，クラス名を省略して指定する方が望ましい記述です。

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

ここでは，J2EEサーバで明示管理ヒープ機能を利用するための設定について説明します。J2EEサーバでは，次のオブジェクトをExplicitヒープに配置する対象にするかどうかを，J2EEサーバのプロパティとして設定します。

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

デフォルトでは，Explicitヒープに配置するように設定されています。ただし，「7.13.1　明示管理ヒープ機能を利用するための共通の設定（JavaVMオプションの設定）」で説明したJavaVMオプションで，明示管理ヒープ機能を使用しない設定に変更した場合は，J2EEサーバのプロパティの設定は無効になります。

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。明示管理ヒープ機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでの明示管理ヒープ機能の定義について次の表に示します。

表7‒15　簡易構築定義ファイルでの明示管理ヒープ機能の定義

指定するパラメタ

設定内容

ejbserver.server.eheap.httpsession.enabled

HTTPセッションに関するオブジェクトをExplicitヒープに配置するかどうかを指定します。

ただし，JavaVMオプションの-XX:-HitachiUseExplicitMemoryを指定した場合，およびJDK17以降のJavaVMを使用している場合，このパラメタは無効（false指定時と同じ挙動）になります。

指定するパラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.11　論理J2EEサーバで指定できるパラメタ」を参照してください。

次に，JavaVMオプションと各プロパティの関係について説明します。

JavaVMオプションとejbserver.server.eheap.httpsession.enabledプロパティの関係

前提となるJavaVMオプションとejbserver.server.eheap.httpsession.enabledプロパティの指定値によって，HTTPセッションに関するオブジェクトの配置先が異なります。HTTPセッションに関するオブジェクトの配置先を次の表に示します。

表7‒16　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

そのほか（不正な文字列，指定なしなど）

(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>
     ：
 </configuration>

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

この節では，明示管理ヒープ機能使用時の注意事項について説明します。

7.14.1　Javaヒープの初期サイズと最大サイズの設定

Javaヒープの初期サイズ（-Xms）と最大サイズ（-Xmx）には，必ず同じ値を指定してください。同じ設定でない場合，CopyGCの回数が増加するおそれがあります。

なお，この設定は，明示管理ヒープ機能を使用しない場合にも推奨の設定です。

補足：

Javaヒープの初期サイズと最大サイズが異なる場合，各領域のサイズは，次のタイミングで変更されます。

CopyGC終了時

New領域のサイズが動的に変更されます。

FullGC終了時

Tenured領域とNew領域のサイズが動的に変更されます。

New領域のサイズは，主にTenured領域のサイズと-XX:NewRatioオプションに指定した値によって決まります。

明示管理ヒープ機能によってFullGCの発生が抑止されると，Tenured領域のサイズが変更されるタイミングがなくなります。これに伴って，New領域のサイズも，ほぼ一定になります。

このため，初期サイズよりも大きい最大サイズを定義していても，New領域が拡張されるタイミングがなくなり，初期サイズで指定したままのサイズになります。初期サイズで指定したNew領域が小さい場合，明示管理ヒープ機能を使用しない場合に比べて，CopyGCが多く発生するおそれがあります。

7.14.2　HTTPセッションに関するオブジェクトでExplicitヒープを利用する際の注意

HTTPセッション生成以降，setAttributeメソッドで設定したすべてのセッション属性（オブジェクト）は，HTTPセッションを破棄するまで解放されないで，Explicitヒープに残存します。その時点でHTTPセッションに設定されているかどうかは関係ありません。このため，HTTPセッションを破棄しないでsetAttributeメソッドを繰り返し実行した場合，Explicitヒープあふれが発生して，FullGC抑止の効果が得られないおそれがあります。Explicitヒープあふれが発生しているかどうかを確認するには，マニュアル「アプリケーションサーバシステム設計ガイド」の「7.14.3　Explicitヒープあふれが発生した場合の確認と対処」を参照してください。

自動解放機能を利用しない場合（-XX:-HitachiExplicitMemoryAutoReclaimの場合）で，HTTPセッションを削除する時に，そのセッションに格納したオブジェクトへの外部からの参照が残っているオブジェクトは，ExplicitヒープからJavaヒープのTenured領域に移動します。この場合，Tenured領域の使用済みサイズが増加することになり，FullGCの発生を抑止できません。

ExplicitヒープからJavaヒープへのオブジェクトの移動を防ぐためには，HTTPセッションを破棄する前に，セッションに格納したオブジェクトへの参照を削除する必要があります。

次のAPIを使用して取得したオブジェクトへの参照が残っている場合も同様です。

getAttribute(String)

getAttributeNames()

なお，自動解放機能を利用する場合（-XX:+HitachiExplicitMemoryAutoReclaimの場合）は，それらのオブジェクトがJavaヒープのTenured領域に移動することはありません。

次の場合，オブジェクトはExplicitヒープではなくJavaヒープに配置されます。

Explicitメモリブロックの数が最大値になっており，新たにExplicitメモリブロックを作成できない場合（同時に存在するExplicitメモリブロックが1,048,575個になっている場合）に，新しいセッションを生成した場合

Explicitヒープ領域の最大サイズを超えた場合

Explicitメモリブロックを確保できなかった場合

これらに該当する場合，オブジェクトはJavaヒープに作成されるため，FullGCの発生抑止ができないおそれがあります。

JSPでは，デフォルトで暗黙的にHttpSessionオブジェクトが作成されます。不要なHttpSessionオブジェクトの生成によるExplicitヒープあふれを防ぐため，セッションを必要としないJSPでは，明示的にHttpSessionオブジェクトを作成しない設定にしてください。設定には，pageディレクティブのsession属性を使用します。

FullGC抑止の効果を検証するテストを実行する場合，セッションを破棄しないままで連続してセッションを生成し続けるような条件では実行しないでください。Explicitメモリブロックが解放されないため，Explicitヒープがあふれる可能性が高くなります。

また，Explicitメモリブロックは，セッションが破棄されたときに解放予約され，その後，GCが発生したときに解放されます。このため，セッションを破棄していても，セッションの破棄と生成の繰り返し回数が1回のGC間隔に対して多過ぎる場合には，解放予約されたExplicitメモリブロックが残存したままの状態で別のExplicitメモリブロックが作成されてしまいます。その結果，Explicitメモリブロックの個数が増加し，Explicitヒープがあふれるおそれがあります。

FullGC抑止の効果を検証するには，セッションを適切に管理する条件でテストを実行してください。

セッションに格納したオブジェクトは，生成直後はJavaヒープに配置されます。何度かCopyGCが実行されたあと，通常はTenured領域に昇格するタイミングでExplicitヒープに移動します。このため，短時間で削除される場合や，セッションがすぐに破棄される場合は，オブジェクトはExplicitヒープには配置されません。

7.14.3　スレッドダンプへ出力するExplicitメモリブロック名称の文字数の上限

JavaVMのスレッドダンプに出力するExplicitヒープ詳細情報には，Explicitメモリブロックの名称が出力されます。Explicitメモリブロックの名称の文字数の上限は2,000文字です。JP.co.Hitachi.soft.jvm.MemoryAreaクラスのsetNameメソッドで，2,000文字を超えるExplicitメモリブロックの名称を設定した場合，2,000文字を超えた部分の名称は，スレッドダンプに出力されません。

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

この章では，J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションのログ出力の概要と出力方法について説明します。

8.1　この章の構成

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するログを，ユーザログといいます。この章では，アプリケーションのユーザログ出力について説明します。

トラブル発生時には，出力されたユーザログを収集・分析して，トラブルの発生要因を調査します。ユーザログの取得には，snapshotログとして一括して取得する方法と，個別に取得する方法があります。ユーザログを含むsnapshotログの収集については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「2.3.3　snapshotログの収集」を参照してください。

この章の構成を次の表に示します。

表8‒1　この章の構成（アプリケーションのユーザログ出力）

分類

タイトル

参照先

解説

ユーザログ出力の概要

8.2

ログのフォーマット

8.3

実装

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

8.4

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

8.5

設定

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

8.6

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

8.7

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

8.8

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

8.9

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

8.10

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

8.11

注意事項

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

8.12

注　「運用」について，この機能固有の説明はありません。

ユーザログ出力の参照先はアプリケーションの種類によって異なります。参照先について次の表に示します。

表8‒2　ユーザログ出力に関する参照先

参照先

アプリケーションの種類

J2EEアプリケーション

バッチアプリケーション

EJBクライアントアプリケーション

8.2　ユーザログ出力の概要

○

○

○

8.3　ログのフォーマット

○

○

○

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

○

○

○

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

○

○

×

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

○

○

×

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

○

○

×

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

○

×

×

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

×

○

×

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

×

×

○

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

×

×

○

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

○

○

○

（凡例）○：参照する　　×：参照しない

8.2　ユーザログ出力の概要

この節では，ユーザログ出力の概要について説明します。

8.2.1　ユーザログ出力の概要

J2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションが出力するログを，ユーザログといいます。アプリケーションサーバでは，ユーザログを，トレース共通ライブラリ形式で出力できます（ユーザログ機能）。これによって，システムのログとアプリケーションのログを同じ形式で扱えるようになり，システム全体のログ運用の信頼性を高められます。

次に，ユーザログ機能を使用したログ出力の流れを示します。

図8‒1　ユーザログ機能の処理の流れ

ユーザログ出力の実装にはJ2SEの標準のログ出力機能（JavaロギングAPI）を使用します。この機能を使用する場合は，ユーザログ出力をJavaロギングAPIで実装してください。

参考

リソースアダプタからユーザログを出力することはできません。なお，リソースアダプタから呼び出されるMessage-driven Beanからは，ユーザログを出力できます。

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

ユーザログを出力するJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションの実装には，J2SEのJavaロギングAPIを使用できます。JavaロギングAPIは，メモリ，コンソール，ファイルなどのさまざまな出力ができる汎用性の高いAPIです。ただし，ロジックが単純なため，ミッション・クリティカルなシステムに適用する場合は，信頼性と耐久性を備えたログ出力用クラスをアプリケーション開発者が実装する必要があります。

ユーザログ機能を使用すると，アプリケーション開発者によってログ出力用クラスを実装しなくても，信頼性が高いユーザログを出力できます。

JavaロギングAPIを使用して開発したJ2EEアプリケーション，バッチアプリケーション，およびEJBクライアントアプリケーションから出力されたログは，トレース共通ライブラリを使用して，ほかのアプリケーションサーバシステムの構成ソフトウェアが出力する形式（トレース共通ライブラリ形式）で出力できます。このライブラリを使用することで，ユーザログをほかのシステムのログと同じ形式で扱うことができ，高い信頼性を持つ統一的なログ運用ができます。

ユーザログ出力は，J2SEのJavaロギングの仕組みに従って出力します。Javaロギングでは，ロガーとハンドラという2種類の要素を使用します。なお，ロガーおよびハンドラは，それぞれ，LoggerクラスおよびHandlerクラスのオブジェクトです。

Javaロギングの仕組みを次の図に示します。

図8‒2　Javaロギングの仕組み

図について説明します。

アプリケーションから，ロガーを使用して，ユーザログを出力します。

ユーザログは，アプリケーションの処理の中で，Loggerクラスのメソッドを使用して出力されます。

ロガーは，アプリケーションから出力されたログにレベルやメッセージ文字列などの付加情報を追加してLogRecordにしたものを，ハンドラに渡します。

なお，このとき，ロガーに接続されたフィルタ（Filterクラスのオブジェクト）を使用して，ログレベルとして指定する制御以上のきめ細やかな制御をすることもできます。

ハンドラは，受け取ったLogRecordを基に，ログをファイル，コンソールまたはソケットに出力します。

出力先や出力形式は，あらかじめハンドラのプロパティとして設定しておきます。ハンドラでは，ハンドラに接続されたフィルタを使用してきめ細やかな制御ができます。また，フォーマッタ（Formatterクラスのオブジェクト）を使用して任意の形式にフォーマットしたメッセージを出力できます。

アプリケーションサーバでは，トレース共通ライブラリ形式でログをファイルに出力するためのファイルハンドラを提供しています。提供しているファイルハンドラについて，アプリケーションの種類ごとに説明します。

J2EEアプリケーションまたはバッチアプリケーションの場合

ファイルハンドラとして，CJMessageFileHandlerを提供しています。CJMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどは，システム構築時に設定できます。J2EEアプリケーションまたはバッチアプリケーションのユーザログ出力の設定については，「8.8　J2EEアプリケーションのユーザログ出力の設定」および「8.9　バッチアプリケーションのユーザログ出力の設定」を参照してください。

また，ユーザログに，ログを出力したアプリケーションの名称やメッセージの内容と対応したメッセージIDを出力したい場合は，J2EEアプリケーションまたはバッチアプリケーション内で実装する必要があります。この場合は，Application Serverが提供する拡張LogRecord作成用のクラス（CJLogRecordクラス）を使用して実装してください。CJLogRecordクラスの使用方法については，「8.4　ユーザログ出力で使用するメソッド」を参照してください。また，CJLogRecordクラスのAPIについては，マニュアル「アプリケーションサーバ リファレンス API編」の「7.　ユーザログ機能で使用するAPI」を参照してください。

注意事項

ハンドラやロガーの設定をJ2EEアプリケーション内に直接実装する場合は，実行するアプリケーションにLoggingPermission("control")のセキュリティ権限が必要になります。LoggingPermission("control")のセキュリティ権限の設定方法については，「8.8.2　セキュリティポリシーの設定」を参照してください。

EJBクライアントアプリケーションの場合

ファイルハンドラとして，CJMPMessageFileHandlerを提供しています。なお，EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。EJBクライアントアプリケーションのユーザログ出力の設定については，「8.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）」または「8.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）」を参照してください。

8.3　ログのフォーマット

ユーザログ機能を使用した場合，次に示すフォーマットでログが出力されます。

番号　日付　時刻

AppName

pid　tid

MsgID

メッセージテキスト

CRLF

フォーマットの項目の出力内容を次に示します。

表8‒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）などの制御文字を含まない任意の文字列です。ファイルハンドラとして，CJMPMessageFileHandlerを指定している場合は，長さは0〜4,095文字で指定します。CJMessageFileHandlerを指定している場合は，長さは制限しません。長さの制限を超えた場合は，切り捨てられます。なお，制御文字を含んでいた場合の出力内容は保証されません。

CRLF

レコード終端記号（0x0D，0x0A）が出力されます。

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

ユーザログ出力で使用するLoggerクラスのメソッドと，CJLogRecordクラスが属するパッケージを示します。CJLogRecordクラスのメソッドの一覧，および機能と文法については，マニュアル「アプリケーションサーバ リファレンス API編」の「7.　ユーザログ機能で使用するAPI」を参照してください。

8.4.1　ユーザログ出力で使用するLoggerクラスのメソッド

CJLogRecordメソッドを使用して，AppNameとMsgIDの受け渡しをする場合，次に示すlogメソッドを使用します。

void log(LogRecord record)

8.4.2　CJLogRecordクラスが属するパッケージ

CJLogRecordクラスをソースプログラム上で使用するには，次に示すパッケージをインポートする必要があります。

com.hitachi.software.ejb.application.userlog

このパッケージの格納先を，次に示します。

<Application Serverのインストールディレクトリ>¥CC¥client¥lib¥HiEJBClientStatic.jar

ユーザログ機能を使用する場合のプログラムの実装例については，「8.5　ユーザログを出力するための実装」を参照してください。

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

J2EEアプリケーションまたはバッチアプリケーションでのログの出力は，JavaロギングAPIを使用してコーディングします。ユーザログにJ2EEアプリケーションまたはバッチアプリケーションの名称やメッセージIDを出力したい場合には，アプリケーションサーバが提供している，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については，マニュアル「アプリケーションサーバ リファレンス API編」を参照してください。

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

JavaロギングAPIを使用してユーザログ出力をするためには，ロガーとハンドラを作成して，必要な設定をします。ログ出力に必要なアプリケーション識別名（AppName）やメッセージID（MsgID）などのパラメタは，アプリケーションサーバが提供するCJLogRecordクラスのcreateメソッドの引数に指定します。また，独自のクラスを作成することで，ログのフィルタリングや出力内容のフォーマットをカスタマイズすることもできます。

なお，ユーザログ出力をするには，ログの出力先や構成面数などのプロパティを，実行環境に設定する必要があります。実行環境でのユーザログの設定については，「8.8　J2EEアプリケーションのユーザログ出力の設定」または「8.9　バッチアプリケーションのユーザログ出力の設定」を参照してください。

J2EEアプリケーションまたはバッチアプリケーションのユーザログを出力する場合のロガーとハンドラの作成および設定の概要について説明します。

なお，EJBクライアントアプリケーションのユーザログ出力については，「8.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）」または「8.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）」を参照してください。

8.6.1　ロガーの作成と設定

ロガーは，ロガー名称を指定して作成します。作成時には，システム構築時に設定した内容が使用されます。

各アプリケーション内では，ロガー名称を指定して作成されたロガーを取得し，取得したロガーを使用してログを出力します。Loggerクラスのメソッドでは，ロガーの作成およびログ出力の指定ができます。指定したログは，LogRecordに変換され，ハンドラに渡されて，ログファイルまたはコンソールに出力されます。

このほか，ロガーでログを取捨選択するためのフィルタ，ログのレベル，ロガーで使用するハンドラについても，必要に応じて設定できます。

8.6.2　ハンドラの作成と設定

ハンドラは，システム構築時に設定した内容に従って作成，設定されます。

CJMessageFileHandlerを使用する場合は，ハンドラ名称を変えることで，複数のファイルハンドラを作成できます。

CJMessageFileHandlerで作成したファイルハンドラには，次の項目が設定できます。

ユーザログの出力先ファイル，面数，サイズなどのログファイルの設定

ログ取得レベル

使用するフィルタ，フォーマッタ

なお，一つのハンドラが出力するログのアプリケーション名およびメッセージIDが同じでかまわない場合には，CJMessageFileHandlerのプロパティとして設定できます。メッセージごとに出力するログのアプリケーション名とメッセージIDを変更したい場合は，アプリケーション内のログ出力処理ごとに，アプリケーション名およびメッセージIDを出力するようにCJLogRecordクラスを使用して実装してください。

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

ロガーおよびハンドラを作成，設定する場合の指針を次に示します。

一つのロガーに対して複数のファイルハンドラを接続できますが，複数のロガーから出力先が同じファイルハンドラに接続して利用することはできません。

アプリケーションごとにログの出力先を変えたい場合は，アプリケーションごとのロガーを作成します。

ロガーは，階層関係を持たせることができます。階層関係を持たせた場合，下位のロガーが取得したログメッセージは，上位のロガーに伝播します。必要に応じて，ロガーの伝播を止めてください。特に，ロガーの最上位にはルートロガーがデフォルトで存在し，J2SEデフォルトの設定の場合，ルートロガーにはConsoleHandlerが接続されています。上位ロガーへの伝播を止めていない場合，ルートロガーのConsoleHandlerからコンソールにすべてのメッセージが出力されます。

ハンドラはインスタンスごとにメッセージを出力するため，一つの出力メッセージが複数のハンドラに送信された場合，一つの出力メッセージが複数回出力されます。例えば，2か所のConsoleHandlerのメッセージは，コンソールに2回出力されます。

一つのアプリケーションで複数のログファイルを利用する場合は，出力先ごとにハンドラを作成してください。

ロガーとハンドラの作成例を次の図に示します。

図8‒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を使用してください。

それぞれのログファイルのサイズおよび面数は，アプリケーションが出力するユーザログの量や指定した出力レベルに応じて，適切に設定してください。

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

ここでは，ユーザが作成した独自のFilterクラス，FormatterクラスまたはHandlerクラスをユーザログ機能で利用するための使用方法について説明します。なお，ここでは，ユーザが作成したクラスをユーザ作成クラスといいます。

ユーザ作成クラスを作成することで，ログのフィルタリングや出力内容をフォーマットできます。ユーザ作成クラスとして，Filterクラス，FormatterクラスまたはHandlerクラスを作成し，ライブラリJARまたはコンテナ拡張ライブラリに含めて使用します。

ユーザ作成クラスをユーザログ機能で使用する方法には，次の2種類の方法があります。

ライブラリJARを利用する

J2EEアプリケーションの場合に使用できる方法です。バッチアプリケーションの場合は使用できません。

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

J2EEアプリケーションまたはバッチアプリケーションで使用できる方法です。

それぞれの方法について説明します。

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

ユーザ作成クラスであるFilterクラス，FormatterクラスまたはHandlerクラスを，アプリケーション上で作成してロガーに追加して利用する方法です。この場合は，次の処理が実行されます。

まず，アプリケーションの中でHandlerクラスをインスタンス化します。

次に，FilterクラスやFormatterクラスをインスタンス化したものをHandlerクラスのインスタンスに接続します。

最後に，接続したHandlerクラスのインスタンスを，ロガーに追加します。

この場合のユーザ作成クラスは，J2SEのjava.util.loggingの仕様に従って作成してください。作成したクラスは，通常のユーザクラスと同じように，WAR，EJB-JARまたはインポート用ライブラリJARに含めて利用できます。

次に，ライブラリJARに含めて利用する場合のユーザ作成クラスの作成手順を示します。

セキュリティポリシーファイル（server.policy）にセキュリティポリシーを設定します。

セキュリティポリシーの設定については，「8.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クラスの構成を初期化した場合，ユーザログ機能によって構築されたログ体系が失われます。

なお，コーディング上の注意事項については，「8.12　ユーザログ機能を使用する場合の注意事項」を参照してください。

8.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（ユーザプロパティファイル）のユーザログ機能用のプロパティキーに，パッケージ名称を含むフルクラス名を指定します。

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

この節では，J2EEアプリケーションが出力するログを，トレース共通ライブラリ形式で出力するための設定方法について説明します。また，アプリケーションのユーザログ出力例についても説明します。なお，J2EEアプリケーションのログを出力しない場合は，この設定は不要です。

トレース共通ライブラリ形式でログを出力するためには，次の設定が必要です。

J2EEサーバの設定

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

8.8.1　J2EEサーバの設定

簡易構築定義ファイルを編集して，ハンドラからのログの出力先，ログレベル，ログ面数，使用するフィルタ，フォーマッタなどを指定してください。

(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

簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　注意事項

ロガーには複数のハンドラを接続できます。ただし，複数のロガーに同一のPath設定を持つファイルハンドラ（CJMessageFileHandler）は接続できません。ファイルハンドラはロガーへの接続の指定（ejbserver.application.userlog.Logger.<ロガー名称>.handlersの値）を参照してインスタンス化します。この際，ログの出力先とプリフィックス（ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.pathの値）の同じハンドラがインスタンス化されている場合は，ログファイルのオープンに失敗します。

ハンドラやロガーの設定および構築については，簡易構築定義ファイルで指定できますが，ハンドラの作成やロガーの構成変更をJ2EEアプリケーション内に直接実装する場合は，実行するアプリケーションにLoggingPermission("control")のセキュリティ権限が必要になります。LoggingPermission("control")のセキュリティ権限の設定方法については，「8.8.2　セキュリティポリシーの設定」を参照してください。

8.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)　フィルタやフォーマッタをリフレクションで作成する場合

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サーバ用セキュリティポリシーファイル）の定義方法については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.4　server.policy（J2EEサーバ用セキュリティポリシーファイル）」を参照してください。

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

ここでは，具体的な例を示して，J2EEアプリケーションのユーザログを出力するための設定について説明します。

(1)　ユーザログ出力で使用する例

次に示す例を使用して，J2EEアプリケーションのユーザログ出力の設定について説明します。使用する例の概要を次の図に示します。

図8‒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!

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

バッチアプリケーションのユーザログ出力の設定は，J2EEアプリケーションのユーザログと同じです。設定方法については，「8.8　J2EEアプリケーションのユーザログ出力の設定」を参照してください。

ただし，バッチアプリケーションの場合，セキュリティポリシーの設定は不要です。

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

EJBクライアントアプリケーションのユーザログ出力の設定について説明します。

EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのユーザログの設定方法が異なります。ここでは，cjclstartapコマンドを使用して開始する場合の設定について説明します。

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）でユーザログの設定をします。ejbserver.applicationから始まるキーで，ユーザログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどを指定してください。指定できるキーについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「3.2.2　usrconf.properties（バッチサーバ用ユーザプロパティファイル）」を参照してください。

また，EJBクライアントアプリケーションのオプション定義ファイル（usrconf.cfg）で，クラスパスにJARファイルを設定します。クラスパスへのJARファイルの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

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

ここでは，EJBクライアントアプリケーションを，vbjコマンドを使用して開始する場合の設定について説明します。vbjコマンドを使用して開始する場合，ユーザログ機能を利用するための実装が必要です。

ここでは，EJBクライアントアプリケーションでユーザログ機能を利用するための準備と，ユーザログが出力されるまでの処理の流れについて説明します。

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

EJBクライアントアプリケーションのユーザログのファイルハンドラとして，CJMPMessageFileHandlerが提供されています。vbjコマンドを使用する場合は，CJMPMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタおよびフォーマッタなどは，EJBクライアントアプリケーションのユーザログ用の設定ファイルで設定します。

ユーザログ機能を実装する際，EJBクライアントアプリケーションのユーザログ用の設定ファイルに，CJMPMessageFileHandlerのログの出力先ファイル，ログレベル，ログ面数，使用するフィルタとフォーマッタなどを設定します。ユーザアプリケーションプログラムでは，ユーザログ用の設定ファイルを読み込むように記述する必要があります。

EJBクライアントアプリケーションの開始コマンド実行時に，設定ファイルがユーザアプリケーションプログラムから読み込まれて，EJBクライアントアプリケーションのシステムプロパティに設定されます。

8.11.2　利用の準備

EJBクライアントアプリケーションでユーザログ機能を利用する場合には，次の準備が必要です。

なお，EJBクライアントアプリケーションでユーザログ機能を利用する前提として，Application Server側での設定が必要になります。

ユーザログ機能用の設定ファイルの準備

システムプロパティを設定するための，ユーザログ機能用の設定ファイルを準備します。設定ファイルは，J2SEのプロパティファイル形式で記述します。ファイル名称および格納ディレクトリは任意です。

設定ファイルには，J2EEサーバ用のusrconf.propertiesに指定できるキーのうち，「ejbserver.application.userlog」で始まるキーを指定できます。指定できるキーについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

システムプロパティの設定処理の実装

設定ファイルを読み込んでシステムプロパティに設定するための処理を，EJBクライアントアプリケーションのソースコードに追加する必要があります。この処理は，EJBクライアント機能の初期化が実行される処理よりも前に実行されるようにする必要があります。

JARファイルのクラスパスの追加

EJBクライアントアプリケーションを開始するときのクラスパスに，使用するハンドラに対応するJARファイルのクラスパスを追加してください。クラスパスの指定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

参考

EJBクライアントアプリケーションでユーザログ機能を利用する場合，セキュリティポリシーを設定する必要はありません。

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

EJBクライアントアプリケーションでのユーザログの出力は，次の流れで行われます。

システムプロパティの設定

設定ファイルを利用してシステムプロパティが設定されます。

EJBクライアントの初期化

EJBクライアント機能を初期化するメソッドが呼び出されて，ログ体系が構築されます。

JavaロギングAPIの実行

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メソッドは使用しないでください。

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

ユーザが作成した独自のクラス（Formatter，Filter，Handler）をEJBクライアントアプリケーションのユーザログ機能で利用するには，ユーザが作成した独自のクラスをEJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに指定します。

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

ユーザが作成した独自のFilterクラス，Formatterクラス，またはHandlerクラスを，EJBクライアントアプリケーションのユーザログ機能で使用する場合は，EJBクライアントアプリケーションのJavaVMを開始するときのクラスパスに，ユーザ作成のクラスを指定してください。

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

ここでは，ユーザログ機能を使用する場合の注意事項について説明します。

8.12.1　LogManagerのカスタマイズについて

J2SE標準のLogManagerは，java.util.logging.config.classなどのプロパティを使用してカスタマイズできます。ただし，Application Serverが提供するユーザログ機能を使用する場合，カスタマイズはしないでください。ユーザログ機能で使用するプロパティを使用したログ体系の構築では，J2EEサーバの起動時に，ユーザログ機能がLogManagerを使用してプロパティからログ構成を取得します。このため，LogManagerをユーザがカスタマイズすると，ログ構成の構築に失敗するおそれがあります。

また，アプリケーションのソースコード上でLogManagerのreadConfiguration(InputStream ins)メソッドなどを実行して，ロガーの構成を初期化した場合も，ユーザログ機能が構築したログ構成が失われます。このため，このメソッドは実行しないでください。

ただし，カスタマイズしたLogManagerが，すでに構築されているログの構成（LogManagerの内容）を完全に引き継いで，さらに独自の処理を追加した構造になっている場合は，カスタマイズ後もユーザログ機能を使用できます。

8.12.2　ユーザが作成したフィルタ・フォーマッタを使用する場合の注意

ログメッセージの出力時に，ハンドラに接続している，ユーザ作成のフィルタが例外をスローした場合，ハンドラのisLoggableメソッド※1は，true※2を返します。

ハンドラに接続している，ユーザ作成のフォーマッタが例外をスローした場合，ハンドラはフォーマッタで整形したメッセージを出力できません。ユーザが指定したメッセージは，フォーマッタで整形しないで出力されます。

ユーザ作成のフィルタ，フォーマッタがスローした例外の内容については，cjexception.logを参照してください。

注※1

isLoggableメソッドは，ログメッセージの取捨選択を判定するメソッドです。

注※2

trueは，メッセージを出力対象とすることを意味します。

8.12.3　ロガーとハンドラとの接続

ロガーには複数のハンドラを接続できますが，複数のロガーに同一の設定を持つハンドラ（CJMessageFileHandlerまたはCJMPMessageFileHandler）を接続することはできません。

8.12.4　EJBクライアントアプリケーションのログの出力モードの設定

EJBクライアントアプリケーションのログの出力方法には，2種類のモードがあります。プロセスごとにログ出力先のサブディレクトリを作成する動作モードのことをサブディレクトリ専有モード，複数のプロセスでログ出力先のサブディレクトリを共有する動作モードのことをサブディレクトリ共有モードといいます。

サブディレクトリ専有モードは06-50よりも前のバージョンとの互換用に使用するモードであるため，EJBクライアントアプリケーションを新たに作成する場合は，サブディレクトリ共有モードの使用をお勧めします。

EJBクライアントアプリケーションのユーザログ機能を使用する場合，またはcjclstartapコマンドでEJBクライアントアプリケーションを実行する場合は，サブディレクトリ共有モードを使用してください。

EJBアプリケーションのログの出力方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.8　EJBクライアントアプリケーションのシステムログ出力」を参照してください。また，EJBアプリケーションのログを出力するサブディレクトリについては，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「7.6.1　アプリケーションのユーザログの取得」を参照してください。

8.12.5　usrconf.propertiesの接尾辞が「.level」で終わるキーについて

J2EEサーバのusrconf.propertiesで，接尾辞が「.level」で終わるキーのうち，値の範囲にSEVERE，WARNING，INFO，CONFIG，FINE，およびFINEST以外を持つキーが設定された場合は，次の現象が発生します。

サーバ起動時，java.util.logging.LogManagerクラスがキーを読み込むときに接尾辞が「.level」で終わるキーの値をチェックします。値が範囲以外の場合は，java.util.logging.LogManagerクラスが標準エラー出力へエラーメッセージを出力します。

（例）sample.level=Error と指定されていた場合

「Bad level value for property : sample.level」と出力されます。

ユーザログ機能の接尾辞が「.level」で終わるキーでは値が適切でない場合，1.と同様にエラーメッセージを出力します。

ただし，どちらの場合もメッセージが表示されるだけで，動作上は影響ありません。

9　CORBA/OTMゲートウェイ機能

この章では，CORBA/OTMゲートウェイ機能について説明します。

9.1　この章の構成

この章では，TPBroker OTMクライアント（OTMクライアント），およびORBクライアントからEJBアプリケーションを直接呼び出しできるCORBA/OTMゲートウェイ機能について説明します。

この章の構成を次の表に示します。

表9‒1　この章の構成（CORBA/OTMゲートウェイ機能）

分類

タイトル

参照先

解説

CORBA/OTMゲートウェイ機能の概要

9.2

実装

OTMアプリケーションのEJB呼び出しに関する実装手順

9.3

ORBクライアントからのEJB呼び出しに関する実装手順

9.4

解説

CORBAシステム例外発生時のトラブルシュート

9.5

9.2　CORBA/OTMゲートウェイ機能の概要

Cosminexus Component Transaction Monitorでは，OTMクライアント，およびORBクライアントからEJBアプリケーションを直接呼び出しできるゲートウェイ機能を提供します。ORBクライアントは，次の三つのクライアントの総称です。

TPBrokerクライアント

TPBroker以外のCORBA2.1準拠のCORBAクライアント

TMS-4V/SP/Object AccessのCORBAクライアント

9.2.1　クライアント

EJBアプリケーションを直接呼び出すことのできるクライアントの種類を次に示します。

表9‒2　ゲートウェイ機能でサポートするクライアント

クライアント

Java

C++

COBOL

OTM

○※1

○

×

TPBrokerV3

○

○

−

TPBrokerV5

○

○

×

CORBA2.1準拠のCORBAクライアント

○※2

○※2

○※2

TMS-4V/SP/Object Access

−

−

○

（凡例）

○：接続可能

×：接続不可

−：未サポート

注※1

OTMV3とCosminexusに含まれるTPBroker，またはTPBrokerV5を使用したJavaアプリケーションからEJBアプリケーションを呼び出せません。

注※2

CORBA2.1の仕様に準拠したクライアントであれば仕様上接続できますが，Cosminexus Component Transaction Monitorでは接続を保証していません。ご使用になる場合は事前に接続検証をしてください。

9.2.2　データ型

ゲートウェイ機能では，IDLに記述できるデータ型を送受信できます。

EJBのリモートインタフェースに記述できる引数はin属性だけで，引数やリターン値に使える構造型は，Javaの配列とSerializableインタフェースを実装したクラスだけです。また，Javaが提供するオブジェクトを通信データとして扱うことはできません。

OTMからリクエストする場合，stringとcharの扱いに注意してください。また，CTMが提供するIDL生成コマンドは，OTMで使用できるIDLを出力します。stringとcharの扱いについては「9.3.2　OTMで文字や文字列を扱う場合」を参照してください。IDLの詳細についてはマニュアル「TPBroker Object Transaction Monitor プログラマーズガイド」を参照してください。

9.2.3　プロセス構成

ORBクライアントはORBゲートウェイ経由または混合ゲートウェイ経由で，OTMクライアントはOTMゲートウェイ経由でリクエストします。また，TPBrokerクライアントおよびOTMクライアントはOSAgentを使用したリクエストも可能です。プロセス構成の概要を次の図に示します。

図9‒1　プロセス構成概要

9.2.4　ゲートウェイの開始方法

各種ゲートウェイに接続可能なクライアント，および開始コマンドとオプションの組み合わせを次の表に示します。

表9‒3　各種ゲートウェイに接続可能なクライアントおよび開始コマンドとオプションの組み合わせ

ゲートウェイ種別

クライアント

コマンド

オプション

-CTMAgent

1

-CTMIDLConnect

-CTMTSCGwStart

CTMレギュレータ

EJBレギュレータ

EJB

ctmstart

×

×

×

混合ゲートウェイ

EJB，ORB

ctmstart

△※

△※

×

ORBゲートウェイ

ORB

ctmstartgw

△

△

×

OTMゲートウェイ

OTM

ctmstart

×

×

○

（凡例）

○：指定可

△：両方もしくは，どちらか一方を指定

×：指定不可

注※

-CTMRegOptionに設定するファイルに指定してください。

EJBクライアントとORBクライアントからのリクエストを同一のゲートウェイで受信したい場合は，CTMレギュレータ（混合ゲートウェイ）を開始してください。EJBクライアントとORBクライアントからのリクエストをそれぞれ別々のゲートウェイで受信したい場合は，CTMレギュレータ（EJBレギュレータ）とORBゲートウェイを開始してください。

それぞれのコマンドとオプションの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」を参照してください。

9.2.5　リファレンス解決とLookup名称の指定方法

ここではリファレンス解決とLookup名称の指定方法について説明します。

(1)　クライアントがEJBアプリケーションを呼び出すためのリファレンス解決

クライアント種別ごとに，EJBアプリケーションを呼び出すためのリファレンス解決を次の表に示します。

表9‒4　EJBアプリケーションのリファレンス解決

クライアント

リファレンス解決

CORBA Naming Service

（INS）

OSAgent

IOR

文字列

EJB

○

×

×

OTM

×

○

×

ORB

TPBroker

×

○

○

TPBroker以外

×

×

○

（凡例）

○：サポート

×：未サポート

(2)　Lookup名称の指定方法

OTMクライアントの場合

OTMクライアントでは，TSCユーザプロキシを生成するコンストラクタの引数に，EJBのLookup（登録）名称をTSCアクセプタ名称として指定します。なお，TSCアクセプタ名称は省略できません。また，接続形態は，TSCレギュレータ経由接続を選択してください。

EJBアプリケーションのLookup名称が「AAA/a1」の例

＜C++＞

Converter_TSCprxy(TSCClient_ptr _tsc_client, "AAA/a1");

＜Java＞

Converter_TSCprxy(TSCClient _tsc_client, new String("AAA/a1"));

なお，アプリケーションの作成手順は，「9.3.1　OTMアプリケーションの作成手順」を参照ください。

TPBrokerクライアントの場合

ctmstartgwコマンド，または，ctmregltdコマンドに「-CTMAgent 1」を指定すると，EJBのLookup名称をオブジェクト名称として，OSAgentにCORBAリファレンスを登録します。

そのため，TPBrokerクライアントでは，EJBのLookup名称を_bind()の引数に指定して参照を解決します。

converterサンプルのデフォルトLookup名称の例

＜C++＞

Converter::_bind("HITACHI_EJB/SERVERS/MyServer/EJB/converter/MyConverter");

＜Java＞

ConverterHelper::_bind(org.omg.CORBA.ORB orb,
      new String("HITACHI_EJB/SERVERS/MyServer/EJB/converter/MyConverter"));

なお，アプリケーションの作成手順は，「9.4　ORBクライアントからのEJB呼び出しに関する実装手順」を参照ください。

9.3　OTMアプリケーションのEJB呼び出しに関する実装手順

アプリケーションの作成手順について，Cosminexus Component Containerのサンプルプログラム「converter」を例に説明します。

9.3.1　OTMアプリケーションの作成手順

EJBアプリケーション（サーバAP）を作成する。

EJBアプリケーション（サーバAP）の作成には，次のJavaプログラムが必要です。

Converter.java：EJBObject継承クラス

ConverterEJB.java：SessionBean実装クラス

ConverterHome.java：EJBHome継承クラス

サンプルで提供するcompileBean.batを使用して，Enterprise Beanをコンパイルすると，次のファイルが生成されます。

Converter.class

ConverterEJB.class

ConverterHome.class

converter.jar

詳細については，マニュアル「Cosminexus アプリケーション開発ガイド」を参照してください。

IDLファイルを生成する。

手順1で生成されたclassファイルから，CTMが提供するIDL生成コマンドを使用してIDLファイルを生成します。

% ctmjava2idl -g -o Converter.idl Converter.class

Converter.id

TSCjava.idl

この操作はCosminexus環境で実行してください。また，TPBrokerV5のjava2idlが必要になるため，PATH環境変数にはCosminexus TPBrokerのbinディレクトリを設定してください。

スタブを生成する。

手順2で生成されたIDLから，CTMが提供するスタブ生成コマンドでスタブを生成します。

この操作はクライアント開発環境で実行してください。また，クライアントAPを実行するOTMとその前提のTPBrokerの環境を設定してください。

＜C++アプリケーションの場合＞

% ctmidl2cpp -gen_included_files Converter.idl

これによってクライアントAPの作成に必要な次のファイルが生成されます。

・Converter_c.hh

・Converter_c.cc

・Converter_s.hh

・Converter_s.cc

・Convtrter_TSC_c.hh

・Converter_TSC_c.cc

＜Javaアプリケーションの場合＞

% ctmidl2j -gen_included_files Converter.idl

これによってクライアントAPの作成に必要な次のファイルが生成されます。

・Converter.java

・ConverterHelper.java

・ConverterOperations.java

・ConveterPOA.java（なし※）

・_Converter_Stub.java（_st_Converter.java※）

・_Converter_Tie.java（_tie_Converter.java※）

・Converter_TSCprxy.java

・その他構造型データのクラス

注※　TPBrokerV3を前提とする場合に出力されるファイルです。

コンパイルとリンケージ

OTMアプリケーション開発手順に従い，手順3で生成したスタブファイルを使用して，コンパイルとリンケージを実行してください。

9.3.2　OTMで文字や文字列を扱う場合

OTMで文字列を扱う場合のデータ型を次の表に示します。

表9‒5　OTMで扱うデータ型

項番

リモートインタフェースでの定義

クライアントで使用するデータ型

1

string

::TSC::TSCWStringValue

2

char

::TSC::TSCWChar

(1)　::TSC::TSCWStringValue

::TSC::TSCWStringValueはIDLで次のように定義しています。

module TSC {
  typedef sequence<octet> TSCWString;
  struct TSCWStringValue {
    TSCWString value;
  };
};

実際にwchar_t*の文字列として使用するために，次の機能を提供します。

(a)　C++インタフェース

インクルードファイル

#include “Converter_TSC_c.hh”（スタブヘッダ）

提供関数

void TSCsetWString( ::TSC::TSCWString&, const ::CORBA::WChar* )

【用途】

ワイド文字列を::TSC::TSCWStringに設定します。

【IO】

::TSC::TSCWString& :out ：設定する::TSC::TSCWString型の変数

const ::CORBA::WChar*:in ：設定したいワイド文字列

::CORBA::WChar* TSCgetWString( ::TSC::TSCWString )

【用途】

::TSC::TSCWStringに設定されているワイド文字列を取り出します。

【IO】

::TSC::TSCWString :in ：ワイド文字列を持つオブジェクト

【戻り値】

::TSC::TSCWStringから取り出したワイド文字列

【注意事項】

OTM V3で使用する場合，戻り値はdelete[]を使用して解放してください。

サンプルコード

CORBA::WChar* wstr_data = new CORBA::WChar[5];
wstr_data[0] = L’さ’;
wstr_data[1] = L’ん’;
wstr_data[2] = L’ぷ’;
wstr_data[3] = L’る’;
wstr_data[4] = 0;
::TSC::TSCWStringValue tsc_wstr_value_data;

// ワイド文字列の設定
TSCsetWString( tsc_wstr_value_data.value, wstr_data );
// 使い終わった領域の解放
delete[] wstr_data;

// ワイド文字列の取り出し
wstr_data = TSCgetWString( tsc_wstr_data.value );
// 取り出した領域の解放
delete[] wstr_data;

(b)　Javaインタフェース

Javaインタフェースは提供されません。

サンプルコード

String wstr_data = new String("さんぷる");
System.out.println(wstr_data);
TSC.TSCWStringValue tsc_wstr_value_data = new TSC.TSCWStringValue();

// ワイド文字列の設定
tsc_wstr_value_data.value = wstr_data.getBytes("UTF-16");

// ワイド文字列の取り出し
wstr_data = new String( tsc_wstr_value_data.value );

(2)　::TSC::TSCWChar

::TSC::TSCWCharはIDLで次のように定義しています。

module TSC {
  typedef octet TSCWChar[3];
};

実際にwchar_tの文字として使用するために，次の機能を提供します。

(a)　C++インタフェース

インクルードファイル

#include “Converter_TSC_c.hh”（スタブヘッダ）

提供関数

void TSCsetWChar( ::TSC::TSCWChar , ::CORBA::WChar )

【用途】

ワイド文字を::TSC::TSCWCharに設定します。

【IO】

::TSC::TSCWChar :out: 設定する領域

const ::CORBA::WChar :in : 設定したいワイド文字

【戻り】

なし

::CORBA::WChar TSCgetWChar( ::TSC::TSCWChar )

【用途】

::TSC::TSCWCharに設定されているワイド文字を取り出します。

【IO】

const ::TSC::TSCWChar :in :ワイド文字を持つオブジェクト

【戻り】

::TSC::TSCWCharから取り出したワイド文字

サンプルコード

::TSC::TSCWChar tsc_wchar_data;
// ワイド文字の設定
TSCsetWChar( tsc_wchar_data, L'あ' );

// ワイド文字の取り出し
CORBA::WChar wchar_data = TSCgetWChar( tsc_wchar_data );

(b)　Javaインタフェース

Javaインタフェースは提供されません。

サンプルコード

TSC.TSCWCharHolder tsc_wchar_data = new TSC.TSCWCharHolder();
tsc_wchar_data.value = new byte[3];
char wch_data = 'あ';

// ワイド文字の設定
tsc_wchar_data.value[0] = (byte)2;
tsc_wchar_data.value[1] = (byte)((wch_data >> 8) & 0xff);
tsc_wchar_data.value[2] = (byte)( wch_data & 0xff);

// ワイド文字の取り出し
wch_data = (char)(((char)tsc_wchar_data.value[1] & 0xff) << 8 |
((char)tsc_wchar_data.value[2] & 0xff));

9.3.3　OTMクライアントで例外を参照する方法

OTMクライアントは，EJBからスローされる例外クラスをそのままキャッチできないので，TSCユーザプロキシ（スタブ）で変換してからキャッチしています。

以降ではTSCユーザプロキシで変換した例外について説明します。

(1)　OTMクライアントで受け取る例外一覧

EJBで発生した例外とOTMクライアントで受け取る例外の対応一覧を，次の表に示します。

表9‒6　OTMクライアントで受け取る例外一覧

項番

EJBで発生した例外

OTMクライアントで受け取る例外

1

Javaユーザ定義例外

（java.lang.Exceptionを継承）

ユーザ定義例外（IDL定義のexceptionを参照）※

2

Javaユーザ定義例外

（java.rmi.RemoteExceptionを継承）

TSC::java::rmi::RemoteEx例外

3

Javaシステム定義例外

（java.lang.Exceptionを継承した例外）

TSCUnknown例外（該当Javaシステム定義例外）

4

Javaランタイム例外

（java.lang.RuntimeExceptionを継承した例外）

TSC::java::rmi::RemoteEx例外

5

Javaシステム定義エラー

（java.lang.Errorを継承したエラー）

TSC::java::rmi::RemoteEx例外

6

java.rmi.RemoteException

TSC::java::rmi::RemoteEx例外

7

CORBAシステム例外

（org.omg.CORBA.SystemExceptionを継承した例外）

TSCUnknown例外（該当TSCシステム例外）

8

CORBAユーザ例外

（org.omg.CORBA.UserExceptionを継承した例外）

ユーザ定義例外（IDL定義のexceptionを参照）

注※

例外名称が〜Exceptionの場合〜Exになります。そのほかの場合，末尾にExが付加されます。例外のメンバvalueの値が例外構造体。

(2)　例外構造体について

(a)　例外構造体の概要

OTMクライアントでは再帰的な構造のデータを解釈できない，valuetypeが使用できないという制限があるため，EJBからの例外は次の図のように構造体をメンバに持つ例外に変換されます。この構造体を例外構造体と呼びます。

図9‒2　例外クラスと例外構造体

例外は例外構造体に変換されますが，OTMクライアントでは，例外構造体をメンバとして持った例外をキャッチします。ユーザがMsgServerExceptionをEJBからスローすると，OTMクライアントはMsgServerEx例外としてキャッチします。MsgServerEx例外のメンバであるvalueは，例外構造体 MsgServerExceptionになります。

図9‒3　例外クラスからの例外構造体の取得

(b)　例外構造体のメンバ

例外構造体に含まれるメンバ名と内容を次の表に示します。

表9‒7　例外構造体のメンバの説明

項番

構造体のメンバ

内容

1

order

OTMアプリケーションの開発者は意識する必要はありません。

OTMクライアントが例外として受け取るために必要な情報です。

2

count

3

cause

OTMアプリケーションの開発者は意識する必要はありません。

OTMクライアントの場合は，EJBからcauseに値を設定して例外をスローしないでください。

4

detailMessage

スーパクラスに指定した詳細メッセージです。

5

stackTrace

EJB側の例外が生成されるまでのスタックトレースです。

6

メンバ変数

Javaユーザ定義例外で設定したメンバ変数です。

RemoteExceptionの場合は，メンバ変数はありません。

(c)　スタックトレースの各情報

例外構造体のメンバであるstackTraceは，StackTraceElement構造体の配列であり，StackTraceElement構造体には，スタックトレースの1スタック分の情報が入っています。

StackTraceElement構造体の各メンバに設定される情報を，次の表に示します。

表9‒8　StackTraceElement構造体のメンバ

項番

フィールド名

内容

例

1

LineNumber

ソースの行番号

29

2

declaringClass

クラス名

jp.co.Hitachi.soft.test.ejb.testMsgSyncServiceDelEJB

3

FileName

ファイル名

testMsgSyncServiceDelEJB.java

4

MethodName

メソッド名

InvokeBinary

(3)　OTMクライアントで例外情報を参照する例

OTMクライアントで，EJBからの例外を参照する方法について，サンプルコードを用いて説明します。

Javaユーザ定義例外を次に示します。

Package jp.co.Hitachi.soft.test;
public class MsgServerException extends Exception
{
    public MsgServerException()
    {
      m_case=1;
    }
    private int m_case;
}

(a)　C++で例外情報を参照する例

C++で例外情報を参照する例を次に示します。

#define ERR_FORMAT "EC=%d,DC=%d,PC=%d,CS=%d,MC1=%d,MC2=%d,MC3=%d,MC4=%d¥n"
// 指定された文字列の長さを返す関数
int my_wstringlen(CORBA::WChar* arg){
    int i;
    for(i=0;arg[i] != 0;i++);
    return i;
}
// 指定された文字列を表示する関数
void my_print_wstring(CORBA::WChar* arg){
    for(int i=0;i < my_wstringlen(arg); i++){
      printf("%c", arg[i]);
    }
}

int main(int argc, char** argv){
  try {
      // EJB呼び出し処理省略
  }catch(jp::co::Hitachi::soft::test::MsgServerEx &e){
   // EJBがJavaユーザ定義例外 MsgServerExceptionをスロー
    jp::co::Hitachi::soft::test::CSCMsgServerException& ex_val = e.value;

    // 詳細メッセージの出力
    printf("detailMessage:");
    ::TSC::TSCWStringValue& detailMessage = ex_val.detailMessage;
    CORBA::WChar* w_detail_msg = new CORBA::WChar[detailMessage.value.length()];
    w_detail_msg = TSCgetWString(detailMessage.value );
    my_print_wstring(w_detail_msg);
    printf("¥n");

    // メンバ変数 m_case の出力
    printf("m_case:%d", ex_val.m_case);
    // スタックトレースの出力
    ::TSC::java::lang::seq1_StackTraceElement& stackTrace = ex_val.stackTrace;
    CORBA::ULong len = stackTrace.value.length();
    :TSC::java::lang::StackTraceElement stackTraceElement;
    for ( int i = 0 ; i < len ; i ++ ) {
        stackTraceElement = stackTrace.value [ i ] ;
        ::TSC::TSCWStringValue& className = stackTraceElement.declaringClass;
        ::TSC::TSCWStringValue& methodName= stackTraceElement.methodName;
        ::TSC::TSCWStringValue& fileName = stackTraceElement.fileName;
        CORBA::Long lineNumber= stackTraceElement.lineNumber;

        CORBA::WChar* w_class_name = new CORBA::WChar[className.value.length()];
        w_class_name = TSCgetWString( className.value );

      CORBA::WChar* w_method_name = new CORBA::WChar[methodName.value.length()];
      w_method_name = TSCgetWString( methodName.value );

      CORBA::WChar* w_file_name = new CORBA::WChar[fileName.value.length()];
      w_file_name = TSCgetWString( fileName.value );

      printf("at ");
      my_print_wstring(w_class_name);
      printf(".");
      my_print_wstring(w_method_name);
      printf("(");
      my_print_wstring(w_file_name);
      printf(":%d)¥n",lineNumber);
    }
}catch(TSC::java::rmi::RemoteEx &e){
    // EJBからJavaランタイム例外がスロー
    // EJBからJavaシステム定義エラーがスロー
    // EJBからjava.rmi.RemoteExceptionがスロー

    TSC::java::rmi::RemoteException& ex_val = e.value;

    // 詳細メッセージの出力
    printf("detailMessage:");
    ::TSC::TSCWStringValue& detailMessage = ex_val.detailMessage;
    CORBA::WChar* w_detail_msg = new CORBA::WChar[detailMessage.value.length()];
    w_detail_msg = TSCgetWString(detailMessage.value );
    my_print_wstring(w_detail_msg);
    printf("¥n");

    // スタックトレースの出力
    ::TSC::java::lang::seq1_StackTraceElement& stackTrace = ex_val.stackTrace;
    CORBA::ULong len = stackTrace.value.length();
    :TSC::java::lang::StackTraceElement stackTraceElement;
    for ( int i = 0 ; i < len ; i ++ ) {
        stackTraceElement = stackTrace.value [ i ] ;
        ::TSC::TSCWStringValue& className = stackTraceElement.declaringClass;
        ::TSC::TSCWStringValue& methodName= stackTraceElement.methodName;
        ::TSC::TSCWStringValue& fileName = stackTraceElement.fileName;
        CORBA::Long lineNumber= stackTraceElement.lineNumber;

        CORBA::WChar* w_class_name = new CORBA::WChar[className.value.length()];
        w_class_name = TSCgetWString( className.value );
      CORBA::WChar* w_method_name = new CORBA::WChar[methodName.value.length()];
      w_method_name = TSCgetWString( methodName.value );

      CORBA::WChar* w_file_name = new CORBA::WChar[fileName.value.length()];
      w_file_name = TSCgetWString( fileName.value );

      printf("at ");
      my_print_wstring(w_class_name);
      printf(".");
      my_print_wstring(w_method_name);
      printf("(");
      my_print_wstring(w_file_name);
      printf(":%d)¥n",lineNumber);
    }
} catch(TSCSystemException& se) {
    // EJBからJavaシステム定義例外がスロー
    // EJBからCORBAシステム例外がスロー
    // EJBの呼び出しに失敗
    printf(ERR_FORMAT,
            se.getErrorCode(), se.getDetailCode(),
            se.getPlaceCode(), se.getCompletionStatus(),
            se.getMaintenanceCode1(), se.getMaintenanceCode2(),
            se.getMaintenanceCode3(), se.getMaintenanceCode4());
} catch(UserExcept& se) {
    // EJBからCORBAユーザ例外がスロー
    printf("UserExcept¥n");
}

(b)　Javaで例外情報を参照する例

Javaで例外情報を参照する例を次に示します。

// byte[]をchar[]に変換し，Stringにする関数
private static String myString(byte[] barray) {
    char[] carry = new char[barray.length/2];
    for ( int i=0;i<carry.length;i++) {
        carry[i] = (char)((( barray[i*2]& 0xff) << 8 ) | barray[(i*2)+1]& 0xff) ;
    }
    return new String(carry);
}

public static void main(String[] args) {
  try {
      // EJB呼び出し処理省略
  }catch(jp.co.Hitachi.soft.test.MsgServerEx ex) {

     // EJBがJavaユーザ定義例外 MsgServerExceptionをスロー
    jp.co.Hitachi.soft.csc.msg.message.reception.MsgServerException testException = ex.value;

    // 詳細メッセージの出力
    System.out.println ("detailMessage:"+ myString(testException.detailMessage);

    // メンバ変数 m_case の出力
    System.out.println ("m_case:%d"+ testException .m_case);

    // スタックトレースの出力
    TSC.java.lang.StackTraceElement[] stackElements= testException.stackTrace.value;
    java.lang.StringBuffer stb = new java.lang.StringBuffer();

    for (int i=0;i<stackElements.length;i++) {
        stb = stb.append("at ");
        stb = stb.append(myString(stackElements[i].declaringClass.value));
        stb = stb.append(".");
        stb = stb.append(myString(stackElements[i].methodName.value));
        stb = stb.append("(");
        stb = stb.append(myString(stackElements[i].fileName.value));
        stb = stb.append(":");
        stb = stb.append(stackElements[i].lineNumber);
        stb = stb.append(")");
        stb = stb.append("¥n");
    }
        System.out.println(stb.toString());
}catch(TSC.java.rmi.RemoteEx ex) {
    // EJBからJavaランタイム例外がスロー
    // EJBからJavaシステム定義エラーがスロー
    // EJBからjava.rmi.RemoteExceptionがスロー
    TSC.java.rmi.RemoteException testException = ex.value;

    // 詳細メッセージの出力
    System.out.println ("detailMessage:"+ myString(testException.detailMessage);
    // スタックトレースの出力
    TSC.java.lang.StackTraceElement[] stackElements= testException.stackTrace.value;
    java.lang.StringBuffer stb = new java.lang.StringBuffer();

    for (int i=0;i<stackElements.length;i++) {
        stb = stb.append("at ");
        stb = stb.append(myString(stackElements[i].declaringClass.value));
        stb = stb.append(".");
        stb = stb.append(myString(stackElements[i].methodName.value));
        stb = stb.append("(");
        stb = stb.append(myString(stackElements[i].fileName.value));
        stb = stb.append(":");
        stb = stb.append(stackElements[i].lineNumber);
        stb = stb.append(")");
        stb = stb.append("¥n");
    }
        System.out.println(stb.toString());
} catch(TSCSystemException tsc_se) {
    // EJBからJavaシステム定義例外がスロー
    // EJBからCORBAシステム例外がスロー
    // EJBの呼び出しに失敗
    System.out.println(tsc_se);
} catch(UserExcept tsc_se) {
    // EJBからCORBAユーザ例外がスロー
    System.out.println("catch" + tsc_se.value);
}

9.4　ORBクライアントからのEJB呼び出しに関する実装手順

この節ではORBクライアントからのEJB呼び出しに関する実装手順について説明します。

9.4.1　TPBrokerV5アプリケーションの作成手順

ここではTPBrokerV5を使用した場合のアプリケーションの作成手順について説明します。

TPBrokerV5を除くORBクライアントのアプリケーションの作成手順については「9.4.2　TPBrokerV5を除くORBクライアントアプリケーションの作成手順」を参照してください。

EJBアプリケーション（サーバAP）を作成する。

次のJavaプログラムが必要です。

Converter.java ：EJBObject継承クラス

ConverterEJB.java ：SessionBean実装クラス

ConverterHome.java ：EJBHome継承クラス

サンプルで提供するcompileBean.batを使用して，Enterprise Beanをコンパイルすると，次のファイルが生成されます。

Converter.class

ConverterEJB.class

ConverterHome.class

converter.jar

詳細については，マニュアル「Cosminexus アプリケーション開発ガイド」を参照してください。

IDLファイルを生成する。

C++アプリケーションを作成する場合，手順1で生成されたclassファイルから，TPBrokerが提供する次のコマンドでIDLファイルを生成します。

% java2idl Converter.class > Converter.idl

スタブを生成する。

手順2で生成されたIDLまたは，classファイルからスタブを生成します。

この操作はクライアント開発環境で実行してください。

＜C++アプリケーションの場合＞

% idl2cpp -namespace Converter.idl

これによってクライアントAPの作成に必要な次のファイルが生成されます。

・Converter_c.cc

・Converter_c.hh

・Converter_s.cc

・Converter_s.hh

＜Javaアプリケーションの場合＞

% java2iiop Converter.class

これによってクライアントAPの作成に必要な次のファイルが生成されます。

・Converter.java

・ConverterHelper.java

・ConverterHolder.java

・ConverterOperations.java

・ConveterPOA.java

・_Converter_Stub.java

・_Converter_Tie.java

・その他構造型データのクラス

コンパイルとリンケージ

TPBrokerアプリケーション開発手順に従い，手順3で生成したスタブファイルを使用して，コンパイルとリンケージを実行してください。

9.4.2　TPBrokerV5を除くORBクライアントアプリケーションの作成手順

TPBrokerV5を除くORBクライアント（CORBA2.1準拠のCORBAクライアントまたはTMS-4V/SP Object Access，TPBrokerV3）からEJBアプリケーション（Cosminexus）のEJBをCORBA通信によって呼び出す方式を次の図に示します。

図9‒4　ORBクライアントからのEJB呼び出し

この方式ではIDLとして次のデータ型/データ定義だけ使用できます。

long，unsigned long，string，sequence<octet>，struct

(1)　インタフェース設計手順

アプリケーションサーバ側の通信インタフェースはEJBのリモートインタフェースとして，ORBクライアント側の通信インタフェースはCORBAのIDLとしてそれぞれ記述する必要があります。

リモートインタフェースおよびIDLの設計手順の概略は次のようになります。

インタフェースのベースとなるIDL定義を作成

IDLに合わせてEJBのリモートインタフェースを作成

ctmjava2idlコマンドの出力によって，IDLの構造体メンバの並びを補正

string,sequence<octet>,structのIDL定義を変更

各手順の詳細について説明します。

(a)　インタフェースのベースとなるIDL定義の作成

インタフェースのベースとなるIDL定義は，次の注意事項を考慮して作成してください。

out/inout引数は使用できません（戻りデータとしてはリターン値を使用します。戻りデータが複数ある場合はstructにまとめてください）。

ユーザ例外は使用しないでください。

structのメンバはlong,unsigned long,string,sequence<octet>だけを使用してください。

#pragmaは使用しないでください。

(b)　リモートインタフェースの作成

ベースとなるIDL定義の作成後，それを基にEJBのリモートインタフェースを作成します。

このとき，対応するメンバ名は，IDLとリモートインタフェースで同じにしてください。

また，IDLのmoduleは，Javaのパッケージに対応します。

サポートするデータ型のマッピングを次の表に示します。

表9‒9　IDLからリモートインタフェースへのデータ型のマッピング

データ型

IDL

リモートインタフェース

整数

long

int

unsigned long※1

文字列

string※3

byte[]※2

バイナリ

sequence<octet>※3

byte[]

構造体

struct

class（Serializableを実装）

注※1

Javaにはunsignedに対応する型が存在しません。そのためIDLのunsigned longはlongと同じ型として扱われます。

注※2

JavaのStringはIDLのWstringに対応するため，リモートインタフェースではbyte[]を使用してください。

注※3

IDL上のstring/sequence<octet>に対して最大長を指定できます。ただしJava側ではすべて可変長データとして扱われます。

IDLの記述例

struct AAA {
  long longData;
  string<4> strData;
  unsigned long ulongData;
  sequence<octet> octseqData;
};

リモートインタフェースの記述例

public class AAA
  implements java.io.Serializable {
  public int longData;
  public byte[] strData;
  public int ulongData;
  public byte[] octSeqData;
};

(c)　ctmjava2idlコマンドの出力によって，IDLの構造体メンバの並びを補正

EJBに対するCORBA通信では，IDLのstruct内のメンバの並びをJavaのSerializableの仕様に沿った形で並べ替える必要があります。ここで，IDL上での適正なstructメンバの並びを確認するために，ctmjava2idlコマンドを使用します。

ctmjava2idlコマンドは，EJBのリモートインタフェースをIDL定義へ変換するコマンドです。

<例：表9-9の例で示した構造体AAAを使用した場合の手順>

AAAに対応するJavaソースプログラム（AAA.java）をコンパイルする。

% javac AAA.java

生成されたクラスファイル（AAA.class）をctmjava2idlコマンドに適用する。

% ctmjava2idl AAA.class

標準出力に出力されたIDL定義を基に，ベースとなるIDLを修正する。

ctmjava2idlコマンドによるIDLの構造体メンバの並びの変更例を，次の図に示します。

図9‒5　ctmjava2idlコマンドによるIDLの構造体メンバの並びの変更の例

参考

structメンバの並べ替えルール

リモートインタフェース上でのデータ型とメンバ名によって順番が決定されます。

intのメンバはbyte[]のメンバより先に並びます。

int型のメンバ同士では，メンバ名によって文字列順に並びます。

byte[]型のメンバ同士では，メンバ名によって文字列順に並びます。

int型のメンバ同士，および，byte[]のメンバ同士はctmjava2idlコマンドで出力したIDL定義のstructに定義されている順番に並べます。

(d)　string，sequence<octet>，structのIDL定義を変更

ORBクライアントからのEJB呼び出しではstring，sequence<octet>，structのデータを特定の形式の構造体に変更して扱う必要があります（long/unsigned longはそのまま）。

ORBクライアント側送信データの形式

ORBクライアント側からEJBに対し送信するデータに対しては，次のような形式に変更します。

（例：「図9-6　EJB向けのIDLへの変換例」のinvokeメソッドのin引数StringValue,OctSeqValue,AAARequest）

struct 任意の構造体名 {
  long VALUE_TAG;
  string REPOSITORY_ID;
  データ本体;
}

ただしstruct内のstring,sequence<octet>メンバに対しては，上記構造体を使用する代わりに，次の構造体を各データの直前に配置するようにしてください。

（例：「図9-6　EJB向けのIDLへの変換例」のAAARequestのメンバtag1およびtag2）

struct ValueTag {
  long VALUE_TAG;
  string REPOSITORY_ID;
}

ORBクライアント側のプログラム実装では，VALUE_TAG/REPOSITORY_IDに値を設定する必要があります。

ORBクライアント側受信データの形式

戻り値としてのstructそのものに対しては，送信データと同様の形式に変更します。

（例：「図9-6　EJB向けのIDLへの変換例」のAAAReply）

struct 任意の構造体名 {
  long VALUE_TAG;
  string REPOSITORY_ID;
  データ本体;
}

struct内のメンバの内，最初に出現したstring,sequence<octet>に対して次の構造体をデータの直前に配置してください。

（例：「図9-6　EJB向けのIDLへの変換例」のAAAReplyのメンバtag1）

struct ValueTag {
  long VALUE_TAG;
  string REPOSITORY_ID;
}

二つ目以降に出現したstring,sequence<octet>メンバに対しては，次の構造体を各データの直前に配置してください。

（例：「図9-6　EJB向けのIDLへの変換例」のAAAReplyのメンバtag2 。手前にsequence<octet>のメンバがあるため，ValueTagでなくReplyTagになる。）

struct ReplyTag {
  long VALUE_TAG;
  long INDIRECTION_TAG;
  long INDIRECTION;
}

受信データとしては，VALUE_TAG/REPOSITORY_ID/ INDIRECTION_TAG/INDIRECTIONの値は無視してください。

IDLの変更例

IDLの変更例を次の図に示します（対応するリモートインタフェースも示します）。

図9‒6　EJB向けのIDLへの変換例

(2)　通信処理に関するプログラム実装

プログラム実装として追加すべき処理について説明します。

(a)　ORBクライアント送信データでのVALUE_TAG，REPOSITORY_ID設定

string/sequence<octet>/structに関しては，ORBクライアント側からEJBに対し送信する場合には，送信前にデータ本体以外に，VALUE_TAG,REPOSITORY_IDにも値を設定してください。

VALUE_TAG

常に固定値（0x7fffff02）を設定してください。

REPOSITORY_ID

string/sequence<octet>の場合

固定値（“RMI:[B:0000000000000000”）を設定してください。

structの場合

リポジトリIDはstructの名称・構造により異なってくるため，ctmjava2idlコマンドの出力結果からリポジトリIDを取得してください。ctmjava2idlコマンド出力結果の「#pragma ID クラス名」の行，“RMI:〜”部分がリポジトリIDです。次の図の場合，"RMI:AAA:D7A0D1FA6D5A19A3:86B2BC1FA4F5362A"がAAAのリポジトリIDになります。

図9‒7　リポジトリIDの例

また，COBOLのマップファイルでREPOSITORY_ID部の長さを指定する場合，次の値を指定してください。

string/sequence<octet>の場合

23文字以上

（固定値（“RMI:[B:0000000000000000”）の文字数以上）

structの場合

ctmjava2idlコマンドの出力結果から取得したリポジトリIDの文字数以上

ORBクライアント側受信データに関しては，データ本体以外の情報（VALUE_TAGなど）は無視してください。

「図9-6　EJB向けのIDLへの変換例」のXXX::invoke()に対応したVALUE_TAG，REPOSITORY_IDの設定例を次に示します。

図9‒8　VALUE_TAG，REPOSITORY_IDの設定例（COBOL）

図9‒9　VALUE_TAG，REPOSITORY_IDの設定例（Java）

図9‒10　VALUE_TAG，REPOSITORY_IDの設定例（C++）

(b)　IDLのstringに対するEJB上での取り扱い

EJB側では文字列をbyte[]として送受信するため，必要に応じてJavaのStringとの相互変換をしてください。

受信したbyte[]をそのままJavaのStringに変換した場合，終端に’¥0’が付加された状態になるため，文字列長を取得すると，文字数が1文字分多い値が得られます。必要であれば終端の’¥0’を削除してください。

byte[]に文字列を設定する場合は，文字列の終端としてプログラムで明示的に’¥0’を付加してください。’¥0’で終了していないデータをIDLのstringとして返した場合，受信側でエラーになるおそれがあります。

IDLでstringの最大長を指定している場合，終端文字’¥0’はその最大長に含まれないため，byte[]のサイズとしては最大長+1を確保してください。

(c)　EJBでのNULL

Javaからの戻り値のclass/byte[]に，nullオブジェクトを使用しないでください。

(3)　文字列化オブジェクトリファレンスの生成

ORBクライアントからORBゲートウェイに接続するIOR文字列ファイルの取得手順について説明します。

ctmstartgwコマンドに-CTMIDLConnectオプションを指定してORBゲートウェイを開始します。

ORBクライアントから呼び出すJ2EEアプリケーションをデプロイしてから開始します。

ctmgetiorコマンドを実行し，IOR文字列ファイルを取得します。

なお，IOR文字列が記述されたファイルの再生成については，次の点に注意してください。

EJBのリモートインタフェースとCORBAネーミングサービスの登録名称，サーバのIPアドレス，または，ORBゲートウェイの受信ポート番号を変更しない場合

再生成する必要はありません。

ctmstartgwコマンドに「-CTMIDLConnect 0」を指定してORBゲートウェイを開始すると，ctmgetiorコマンドによってIOR文字列は取得できませんが，アプリケーションやORBゲートウェイの開始時間を短縮できます。

EJBのリモートインタフェース，CORBAネーミングサービスの登録名称，サーバのIPアドレス，または，ORBゲートウェイの受信ポート番号を変更する場合

文字列化オブジェクトリファレンスの生成手順1からやり直す必要があります。

9.5　CORBAシステム例外発生時のトラブルシュート

CORBAシステム例外発生時のトラブルシュートについて説明します。

9.5.1　CORBAシステム例外のマイナーコード

J2EEサーバ，CTMデーモンおよびORBゲートウェイで発生した例外は，CORBAシステム例外に変換してORBクライアントに通知されます。このとき，マイナーコードには1213473792〜1213474047（0x48542400〜0x485424FF）の値が設定されます。

CORBAシステム例外にマイナーコードが設定された場合，次の表を参照し，エラー要因を調査して適切に対処してください。

表9‒10　CTMが設定するマイナーコード

マイナーコード

エラー要因

対処

1213473792

CTMでエラーが発生しました。

トラブルシュート情報を取得し，障害情報と併せて保守員に連絡してください。

1213473793〜

1213474042

CTMでエラーが発生しました。

詳細は「9.5.2　CTMでエラーが発生した時のトラブルシュート」を参照してください。

1213474046

CTMでエラーが発生しました。

トラブルシュート情報を取得し，障害情報と併せて保守員に連絡してください。

1213474047

J2EEサーバからRemoteExceptionがthrowされました。

J2EEサーバがRemoteExceptionをthrowした要因を調査してください。

9.5.2　CTMでエラーが発生した時のトラブルシュート

CORBAシステム例外のマイナーコードに1213473793〜1213474042が設定された場合，CTMSPOOLディレクトリに出力される例外ログファイルからCTMで発生したエラー要因を調査できます。

(1)　例外ログファイルフォーマット

例外ログは16個のカンマ”,”区切りでエラー発生時に取得した情報を出力します。

けた

取得情報

説明

1

Time

エラー発生時刻

2

Process

プロセスID

3

Thread

スレッドID

4

ClientIPAddress

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

5

ClientPortNo

ORBクライアントのポート番号

6

ClientCommNo

通信番号

7

ErrorCode

エラーコード

8

DetailCode

内容コード

9

PlaceCode

場所コード

10

CompletionStatus

完了状態

11

MaintenanceCode1

保守情報

12

MaintenanceCode2

保守情報

13

MaintenanceCode3

保守情報

14

MaintenanceCode2

保守情報

15

ErrorCode

ORBクライアントに返す完了状態

16

CompletionStatus

ORBクライアントに返す完了状態

17

MinorCode

ORBクライアントに返すマイナーコード

例外ログの出力例を次の図に示します。

図9‒11　例外ログの出力例

(2)　トラブルシュートの手順

例外ログファイルに，ORBクライアントが受け取ったマイナーコードが17けた目に出力されているか確認してください。

例外ログファイルは次の場所に格納されています。

Windowsの場合：

<CTMSPOOLディレクトリ>¥ejb¥<接続先のCTMID名>¥expt¥

Unixの場合：

<CTMSPOOLディレクトリ>/ejb/<接続先のCTMID名>/expt/

マイナーコードが出力されていた場合は，該当する行のエラー発生時刻（1けた目）とIPアドレス（4けた目）とポート番号（5けた目）が，ORBクライアントのIPアドレスとポート番号と一致するかどうか確認してください。

該当する行のエラーコード（7けた目），内容コード（8けた目） ，場所コード （9けた目） ，完了状態（10けた目）を基にマニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「19.4　KFCTのメッセージの詳細情報」を参照して，適切な対処をしてください。

該当する行の通信番号（6けた目）からPRFトレースでリクエストがどこまで実行されているかを確認して問題発生個所を絞り込んでください。

付録

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

ここでは，11-40よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-40での主な機能変更については，「1.4　アプリケーションサーバ 11-40での主な機能変更」を参照してください。

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

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

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

付録A.1　11-30での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JDBC4.3への対応

JDBC4.3に対応しました。

アプリケーションサーバ & BPM/ESB基盤 概説

4.6.2

接続できるデータベースにMySQL，PostgreSQLを追加

DB Connectorを使用して接続できるデータベースに，MySQL，PostgreSQLを追加しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6

パッケージ名変換機能の追加

jakartaパッケージ名を前提とするアプリケーションをアプリケーションサーバで動作させる機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

20章

付録A.2　11-20での主な機能変更

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

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

表A‒2　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSF 2.3への対応

JSF 2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

3章

JAX-RS 2.1への対応

JAX-RS 2.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

4章

WebSocket 1.1への対応

WebSocket 1.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

5章

Servlet 4.0への対応

Servlet 4.0に対応しました。これに伴い，NIO HTTPサーバでHTTP/2に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

CDI Managed BeanでのJPA利用

CDI Managed BeanでのJPA利用に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

JPA 2.2への対応

JPA 2.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 2.0への対応

CDI 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

WEB-INF/lib内のCDIへの対応

WARファイルのWEB-INF/lib以下のJARファイルからCDIを利用できるようにしました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 2.0への対応

BV 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JSON-P 1.1への対応

JSON-P 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

JSON-B 1.0への対応

JSON-B 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

13章

付録A.3　11-10での主な機能変更

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

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

表A‒3　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

付録B.4

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

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

表A‒4　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSP2.3への対応

JSP2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

15章

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

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

表A‒5　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッションマネージャの指定機能の追加

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

機能解説 基本・開発編(Web コンテナ)

2.22

付録A.4　11-00での主な機能変更

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

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

表A‒6　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

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

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

表A‒7　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0/3.1への対応

Servlet 3.0の非同期サーブレット，およびServlet 3.1の非同期I/O系APIに対応しました。

機能解説 基本・開発編(Webコンテナ)

8.1

EL 3.0への対応

EL 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.3

JSF 2.2への対応

JSF 2.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JAX-RS 2.0への対応

JAX-RS 2.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

4章

WebSocket 1.0への対応

WebSocket 1.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

5章

NIO HTTPサーバ機能の追加

従来のリダイレクタ機能やインプロセスHTTPサーバ機能に代わり，非同期サーブレットやWebSocketなどのノンブロッキングI/O処理に対応したインプロセスのHTTPサーバとして，NIO HTTPサーバ機能を追加しました。

機能解説 基本・開発編(Webコンテナ)

7章

JPA 2.1への対応

JPA 2.1に対応し，JPA 2.1対応のJPAプロバイダを利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 1.2への対応

CDI 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 1.1への対応

Bean Validation 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

Java Batch 1.0への対応

Batch Applications for the Java Platform （Java Batch） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

11章

JSON-P 1.0への対応

Java API for JSON Processing（JSON-P） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

Concurrency Utilities 1.0への対応

Concurrency Utilities for Java EE 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

14章

WebSocket通信への対応

HTTP ServerからJ2EEサーバにWebSocket通信を中継する機能を追加しました。

HTTP Server

4.15

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

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

表A‒8　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録D

(4)　そのほかの目的

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

表A‒9　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録A.5　09-87での主な機能変更

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

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

表A‒10　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

Java SE 11の機能が使用できるようになりました。

機能解説 保守／移行編

9章

付録A.6　09-80での主な機能変更

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

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

表A‒11　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能におけるラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

Java SE 9の機能が使用できるようになりました。

機能解説 保守／移行編

9章

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

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

表A‒12　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録C

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録C

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録C

付録A.7　09-70での主な機能変更

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

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

表A‒13　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのJSPコンパイルバージョンの追加

J2EEサーバでのJSPから生成されたサーブレットのコンパイル方法に「JDK1.7の仕様に従ったコンパイル」と「JDK7の仕様に従ったコンパイル」を追加する。

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

10.8.4

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

4.11.2

JDK8でのメタスペース対応

JavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する。

システム構築・運用ガイド

付録A.2

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

10.8.7

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

5.2.1，5.2.2，8.2.3

統合ユーザ管理でのユーザ認証のSHA-2対応

統合ユーザ管理でのユーザ認証のハッシュアルゴリズムとしてSHA-224，SHA-256，SHA-384，SHA-512を追加する。

機能解説 セキュリティ管理機能編

5.3.1，5.3.9，5.10.7，11.4.3，12.4.3，12.5.3，13.2，14.2.2

Red Hat Enterprise Linux Server 7での自動起動と自動再起動および自動停止の追加

Red Hat Enterprise Linux Server 7でのManagement Serverと運用管理エージェントの自動起動と自動再起動および自動停止方法を追加する。

機能解説 運用／監視／連携編

2.6.3，2.6.4，2.6.5

リファレンス コマンド編

7.2

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

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

表A‒14　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

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

表A‒15　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録A.8　09-60での主な機能変更

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

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

表A‒16　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

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

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.18

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

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

表A‒17　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.16

(3)　そのほかの目的

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

表A‒18　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

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

14.2

付録A.9　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表A‒19　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

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

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

表A‒20　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

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

1.1.2

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

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

表A‒21　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC 4.0仕様への対応

DB ConnectorでJDBC 4.0仕様のHiRDB Type4 JDBC Driver，およびSQL ServerのJDBCドライバに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6.3

Portable Global JNDI名での命名規則の緩和

Portable Global JNDI名に使用できる文字を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

2.4.3

Servlet 3.0仕様への対応

Servlet 3.0のHTTP Cookieの名称，およびURLのパスパラメタ名の変更が，Servlet 2.5以前のバージョンでも使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7

Bean Validationと連携できるアプリケーションの適用拡大

CDIやユーザアプリケーションでもBean Validationを使って検証できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JavaMailへの対応

JavaMail 1.4に準拠したAPIを使用したメール送受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

javacoreコマンドが使用できるOSの適用拡大

javacoreコマンドを使って，Windowsのスレッドダンプを取得できるようになりました。

リファレンス コマンド編

javacore（スレッドダンプの取得／Windowsの場合）

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

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

表A‒22　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

システム設計ガイド

7.2.6

機能解説 保守／移行編

5.7.2，5.7.3

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

14.1，14.2，14.4

明示管理ヒープ機能の効率的な適用への対応

自動解放処理時間を短縮し，明示管理ヒープ機能を効率的に適用するための機能として，Explicitヒープに移動するオブジェクトを制御できる機能を追加しました。

Explicitメモリブロックへのオブジェクト移動制御機能

明示管理ヒープ機能適用除外クラス指定機能

Explicitヒープ情報へのオブジェクト解放率情報の出力

システム設計ガイド

7.14.6

このマニュアル

7.2.2， 7.6.5，7.10，7.13.1，7.13.3

機能解説 保守／移行編

5.5

クラス別統計情報の出力範囲拡大

クラス別統計情報を含んだ拡張スレッドダンプに，staticフィールドを基点とした参照関係を出力できるようになりました。

機能解説 保守／移行編

9.6

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

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

表A‒23　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

EADsセッションフェイルオーバ機能のサポート

EADsと連携してセッションフェイルオーバ機能を実現するEADsセッションフェイルオーバ機能をサポートしました。

このマニュアル

5章

WARによる運用

WARファイルだけで構成されたWARアプリケーションをJ2EEサーバにデプロイできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.2.1

機能解説 基本・開発編(コンテナ共通機能)

18.9

リファレンス コマンド編

cjimportwar（WARアプリケーションのインポート）

運用管理機能の同期実行による起動と停止

運用管理機能（Management Serverおよび運用管理エージェント）の起動および停止を，同期実行するオプションを追加しました。

機能解説 運用／監視／連携編

2.6.1，2.6.2，2.6.3，2.6.4

リファレンス コマンド編

adminagentctl（運用管理エージェントの起動と停止），mngautorun（自動起動および自動再起動の設定／設定解除），mngsvrctl（Management Serverの起動／停止／セットアップ）

明示管理ヒープ機能でのExplicitメモリブロックの強制解放

javagcコマンドで，Explicitメモリブロックの解放処理を任意のタイミングで実行できるようになりました。

このマニュアル

7.6.1，7.9

リファレンス コマンド編

javagc（GCの強制発生）

(6)　そのほかの目的

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

表A‒24　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

snapshotlog（snapshotログの収集）コマンドで定義ファイルだけを収集できるようになりました。

機能解説 保守／移行編

2.3

リファレンス コマンド編

snapshotlog（snapshotログの収集）

cjenvsetupコマンドのログ出力

Component Container管理者のセットアップ（cjenvsetupコマンド）の実行情報がメッセージログに出力されるようになりました。

システム構築・運用ガイド

4.1.4

機能解説 保守／移行編

4.20

リファレンス コマンド編

cjenvsetup（Component Container管理者のセットアップ）

BIG-IP v11のサポート

使用できる負荷分散機の種類にBIG-IP v11が追加になりました。

システム構築・運用ガイド

4.7.2

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

2.1

明示管理ヒープ機能のイベントログへのCPU時間の出力

Explicitメモリブロック解放処理に掛かったCPU時間が，明示管理ヒープ機能のイベントログに出力されるようになりました。

機能解説 保守／移行編

5.11.3

ユーザ拡張性能解析トレースの機能拡張

ユーザ拡張性能解析トレースで，次の機能を追加しました。

トレース対象の指定方法を通常のメソッド単位の指定方法に加えて，パッケージ単位またはクラス単位で指定できるようになりました。

使用できるイベントIDの範囲を拡張しました。

ユーザ拡張性能解析トレース設定ファイルに指定できる行数の制限を緩和しました。

ユーザ拡張性能解析トレース設定ファイルでトレース取得レベルを指定できるようになりました。

機能解説 保守／移行編

7.5.2，7.5.3，8.25.1

Session Beanの非同期呼び出し使用時の情報解析向上

PRFトレースのルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.17.3

付録A.10　09-00での主な機能変更

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

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

表A‒25　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

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

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

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

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

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

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

表A‒26　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0への対応

Servlet 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

8章

EJB 3.1への対応

EJB 3.1に対応しました。

機能解説 基本・開発編(EJBコンテナ)

2章

JSF 2.1への対応

JSF 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JSTL 1.2への対応

JSTL 1.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

CDI 1.0への対応

CDI 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

Portable Global JNDI名の利用

Portable Global JNDI名を利用したオブジェクトのルックアップができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.4

JAX-WS 2.2への対応

JAX-WS 2.2に対応しました。

Webサービス開発ガイド

1.1，16.1.5，16.1.7，16.2.1，16.2.6，16.2.10，16.2.12，16.2.13，16.2.14，16.2.16，16.2.17，16.2.18，16.2.20，16.2.22，19.1，19.2.3，37.2，37.6.1，37.6.2，37.6.3

JAX-RS 1.1への対応

JAX-RS 1.1に対応しました。

Webサービス開発ガイド

1.1，1.2.2，1.3.2，1.4.2，1.5.1，1.6，2.3，11章，12章，13章，17章，24章，39章

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

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

表A‒27　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

SSL/TLS通信でのTLSv1.2の使用

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

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

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

表A‒28　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webコンテナ全体の実行待ちキューの総和の監視

Webコンテナ全体の実行待ちキューの総和を稼働情報に出力して監視できるようになりました。

機能解説 運用／監視／連携編

3章

アプリケーションの性能解析トレース（ユーザ拡張トレース）の出力

ユーザが開発したアプリケーションの処理性能を解析するための性能解析トレースを，アプリケーションの変更をしないで出力できるようになりました。

機能解説 保守／移行編

7章

仮想化環境でのユーザスクリプトを使用した運用

任意のタイミングでユーザ作成のスクリプト（ユーザスクリプト）を仮想サーバ上で実行できるようになりました。

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

7.8

運用管理ポータル改善

運用管理ポータルの次の画面で，手順を示すメッセージを画面に表示するように変更しました。

［設定情報の配布］画面

Webサーバ，J2EEサーバおよびSFOサーバの起動画面

WebサーバクラスタとJ2EEサーバクラスタの一括起動，一括再起動および起動画面

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

10.10.1，11.9.2，11.10.2，11.10.4，11.10.6，11.11.2，11.12.2，11.12.4，11.12.6

運用管理機能の再起動機能の追加

運用管理機能（Management Serverおよび運用管理エージェント）で自動再起動が設定できるようになり，運用管理機能で障害が発生した場合でも運用が継続できるようになりました。また，自動起動の設定方法も変更になりました。

機能解説 運用／監視／連携編

2.4.1，2.4.2，2.6.3，2.6.4

リファレンス コマンド編

mngautorun（自動起動および自動再起動の設定／設定解除）

(5)　そのほかの目的

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

表A‒29　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

3.2.1

Webサーバの名称の変更

アプリケーションサーバに含まれるWebサーバの名称をHTTP Serverに変更しました。

HTTP Server

−

BIG-IPのAPI（SOAPアーキテクチャ）を使用した直接接続への対応

BIG-IP（負荷分散機）でAPI（SOAPアーキテクチャ）を使用した直接接続に対応しました。

また，APIを使用した直接接続を使用する場合に，負荷分散機の接続環境を設定する方法が変更になりました。

システム構築・運用ガイド

4.7.3，付録J

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

2.1，付録C

機能解説 セキュリティ管理機能編

8.2，8.4，8.5，8.6，18.2.1，18.2.2，18.2.3

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

付録A.11　08-70での主な機能変更

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

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

表A‒30　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

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

ファーストステップガイド

3.5

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

−

page/tagディレクティブのimport属性暗黙インポート機能の追加

page/tagディレクティブのimport属性暗黙インポート機能を使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応

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

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

7.7.2

統合ユーザ管理機能の改善

ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。

簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。

また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。

機能解説 セキュリティ管理機能編

5章，14.2.2

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

3.5，10.8.1

HTTP Server設定項目の拡充

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

システム構築・運用ガイド

4.1.21

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

10.9.1

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

4.10

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

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

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

表A‒31　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ejb-jar.xmlの指定項目の追加

ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.15

パラレルコピーガーベージコレクションへの対応

パラレルコピーガーベージコレクションを選択できるようになりました。

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

14.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)　信頼性の維持・向上

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

表A‒32　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

データベースセッションフェイルオーバ機能の改善

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

このマニュアル

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

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

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

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

このマニュアル

7.11

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

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

表A‒33　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

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

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

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

表A‒34　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

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

2.1

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

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

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

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

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

表A‒35　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

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

2章，3章，5章

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

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

表A‒36　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

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

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

表A‒37　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，9章

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

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

表A‒38　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

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

1.3，2.1

(5)　そのほかの目的

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

表A‒39　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

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.13　08-50での主な機能変更

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

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

表A‒40　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更

Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグおよびservlet-mappingタグの指定を必須から任意に変更しました。

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

2.2.3

論理サーバのネットワークリソース使用

J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。

機能解説 運用／監視／連携編

1.2.3，5.2，5.7

サンプルプログラムの実行手順の簡略化

一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。

ファーストステップガイド

3.5

システム構築・運用ガイド

付録L

運用管理ポータルの画面の動作の改善

画面の更新間隔のデフォルトを「更新しない」から「3秒」に変更しました。

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

7.4.1

セットアップウィザードの完了画面の改善

セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。

システム構築・運用ガイド

2.2.6

仮想化環境の構築

ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。

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

3章，5章

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

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

表A‒41　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

OpenTP1からの呼び出しへの対応

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JMSへの対応

JMS 1.1仕様に対応したCJMSプロバイダ機能を使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

7章

Java SE 6への対応

Java SE 6の機能が使用できるようになりました。

機能解説 保守／移行編

5.5，5.8.1

ジェネリクスの使用への対応

EJBでジェネリクスを使用できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

4.2.18

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

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

表A‒42　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

このマニュアル

7章

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

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

このマニュアル

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。

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

−

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

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

表A‒43　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，Management Serverのコマンド，またはSmart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。

システム構築・運用ガイド

4.1.15

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

2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録E.2

リファレンス コマンド編

1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）

仮想化環境の運用

仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。

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

4章，6章

(5)　そのほかの目的

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

表A‒44　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。

機能解説 保守／移行編

9.8

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。

9.9

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

クラス別統計情報をCSV形式で出力できるようになりました。

9.10

論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え

Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。

機能解説 運用／監視／連携編

16.2.2，16.3.3，16.3.4，18.4.3，18.5.3

ホスト単位管理モデルを対象とした系切り替えシステム

クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。

16章

ACOS（AX2000，BS320）のサポート

使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3，4.7.5，4.7.6，付録J，付録J.2

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

4.2.4，4.3.2，4.3.4，4.3.5，4.3.6，4.7.1

CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加

CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.7.3

OutOfMemoryError発生時の運用管理エージェントの強制終了

JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。

機能解説 保守／移行編

2.5.5

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

TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

このマニュアル

−

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

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表A‒45　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.3

(2)　標準機能への対応

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

表A‒46　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 2.5への対応

Servlet 2.5に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.2，2.5.4，2.6，8章

JSP 2.1への対応

JSP 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.1，2.3.3，2.5，2.6，8章

JSPデバッグ

MyEclipseを使用した開発環境でJSPデバッグができるようになりました。※

機能解説 基本・開発編(Webコンテナ)

2.4

タグライブラリのライブラリJARへの格納とTLDのマッピング

タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.4

application.xmlの省略

J2EEアプリケーションでapplication.xmlが省略できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

アノテーションとDDの併用

アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.5

アノテーションのJava EE 5標準準拠（デフォルトインターセプタ）

デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

@Resourceの参照解決

@Resourceでリソースの参照解決ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.4

JPAへの対応

JPA仕様に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

注※　09-00以降では，WTPを使用した開発環境でJSPデバッグ機能を使用できます。

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

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

表A‒47　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

このマニュアル

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，FullGC発生を抑止できるようになりました。

このマニュアル

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

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

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

表A‒48　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

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

1.1.3

(5)　そのほかの目的

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

表A‒49　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効なHTTP Cookieの削除

無効なHTTP Cookieを削除できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7.4

ネーミングサービスの障害検知

ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.9

コネクション障害検知タイムアウト

コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3.15.1

Oracle11gへの対応

データベースとしてOracle11gが使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3章

バッチ処理のスケジューリング

バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。

このマニュアル

4章

バッチ処理のログ

バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時のリトライ回数とリトライ間隔を指定できるようになりました。

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

3.2.5

snapshotログ

snapshotログの収集内容が変更されました。

機能解説 保守／移行編

付録A.1，付録A.2

メソッドキャンセルの保護区公開

メソッドキャンセルの対象外となる保護区リストの内容を公開しました。

機能解説 運用／監視／連携編

付録C

統計前のガーベージコレクション選択機能

クラス別統計情報を出力する前に，ガーベージコレクションを実行するかどうかを選択できるようになりました。

機能解説 保守／移行編

9.7

Survivor領域の年齢分布情報出力機能

Survivor領域のJavaオブジェクトの年齢分布情報をJavaVMログファイルに出力できるようになりました。

機能解説 保守／移行編

9.11

ファイナライズ滞留解消機能

JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。

−

−

サーバ管理コマンドの最大ヒープサイズの変更

サーバ管理コマンドが使用する最大ヒープサイズが変更されました。

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

5.2.1，5.2.2

推奨しない表示名を指定された場合の対応

J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。

メッセージ(構築／運用／開発用)

KDJE42374-W

（凡例）−：09-00で削除された機能です。

付録B　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

-XX:+HitachiJavaClassLibTrace[1]

-XX:+HitachiOutOfMemoryStackTrace[1]

-XX:+HitachiUseExplicitMemory[1]

-XX:+HitachiVerboseGC[1]

-XX:+HitachiVerboseGCPrintTenuringDistribution[1]

数字

09-70での主な機能変更[1]

09-80での主な機能変更[1]

09-87での主な機能変更[1]

11-00での主な機能変更[1]

11-10での主な機能変更[1]

11-20での主な機能変更[1]

11-30での主な機能変更[1]

A

add.class.path[1]

add.jvm.arg[1]

add.library.path[1]

B

batch.ctm.enabled[1]

batch.request.timeout[1]

batch.schedule.group.name[1]

batch.service.enabled[1]

batch.vbroker.agent.port[1]

C

CallableStatementのプールサイズ[1]

CCC#HttpSession[1]

CCC#HttpSessionManager[1]

CJLogRecordクラス[1]

CJLogRecordクラスが属するパッケージ[1]

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

create時の選択ポリシー[1]

CTM[1]

ctm.Agent[1]

CTMが制御できるリクエストの種類[1]

CTMデーモン[1]

CTMで使用するプロセス[1]

CTMでスケジューリングできないリクエスト[1]

CTMドメイン[1]、[2]

CTMドメインマネジャ[1]、[2]

CTMドメインマネジャの稼働状況確認[1]

CTMドメインマネジャの稼働状態の確認[1]

CTMに接続している最大時間の設定[1]

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

CTMによる同時実行数の動的変更[1]

CTMによる流量制御[1]

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

CTMのスケジュールキューの稼働状況の確認[1]

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

CTMのプロセス構成[1]、[2]

CTMレギュレータ[1]

CTMを使用する場合に実行される処理[1]

D

DataSourceオブジェクトのキャッシング[1]

DB Connector（RARファイル）の種類[1]

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

E

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.appname[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.count[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.encoding[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.filter[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.formatter[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.level[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.limit[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.msgid[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.path[1]

ejbserver.application.userlog.CJLogHandler.<ハンドラ名称>.separator[1]

ejbserver.application.userlog.Logger.<ロガー名称>.filter[1]

ejbserver.application.userlog.Logger.<ロガー名称>.handlers[1]

ejbserver.application.userlog.Logger.<ロガー名称>.level[1]

ejbserver.application.userlog.Logger.<ロガー名称>.useParentHandlers[1]

ejbserver.application.userlog.loggers[1]

ejbserver.batch.application.exit.enabled[1]

ejbserver.batch.gc.watch.threshold[1]

ejbserver.batch.queue.length[1]

ejbserver.batch.schedule.group.name[1]

ejbserver.client.ctm.RequestPriority[1]

ejbserver.connectionpool.applicationAuthentication.disabled[1]

ejbserver.connectionpool.sharingOutsideTransactionScope.enabled[1]

ejbserver.container.rebindpolicy[1]

ejbserver.ctm.ActivateTimeOut[1]

ejbserver.ctm.DeactivateTimeOut[1]

ejbserver.ctm.enabled[1]

ejbserver.ctm.QueueLength[1]

ejbserver.distributedtx.XATransaction.enabled[1]

ejbserver.jndi.cache[1]

ejbserver.jndi.cache.interval[1]

ejbserver.jndi.cache.interval.clear.option[1]

ejbserver.jndi.cache.reference[1]

ejbserver.jndi.namingservice.group.<Specify group name>.providerurls[1]

ejbserver.jndi.namingservice.group.list[1]

ejbserver.jndi.request.timeout[1]

ejbserver.jta.TransactionManager.defaultTimeOut[1]

ejbserver.naming.host[1]

ejbserver.naming.port[1]

ejbserver.rmi.request.timeout[1]

EJBアクセス機能[1]

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

EJBクライアントアプリケーションのユーザログ出力[1]、[2]

EJBクライアントから業務処理プログラムを呼び出す流れと負荷分散のタイミング[1]

ExplicitMemoryインスタンスが表すExplicitメモリブロックサイズ[1]

ExplicitMemoryインスタンスとExplicitメモリブロックの関係[1]

Explicitヒープ[1]、[2]

Explicitヒープに配置されるオブジェクト[1]

Explicitヒープに配置すると効果があるオブジェクト[1]

Explicitヒープに配置できるオブジェクト[1]

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

Explicitヒープに配置できるオブジェクトの前提[1]

Explicitメモリブロック[1]

Explicitメモリブロック解放時に外部から参照されている場合の動作[1]

Explicitメモリブロックのオブジェクト解放率情報の利用[1]

Explicitメモリブロックの拡張[1]

Explicitメモリブロックのサブ状態[1]

Explicitメモリブロックの自動解放処理に掛かる時間の短縮[1]

Explicitメモリブロックの状態[1]

Explicitメモリブロックの初期化[1]

Explicitメモリブロックのライフサイクル[1]、[2]

Explicitメモリブロックへのオブジェクト移動制御機能[1]

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

F

FullGCの抑止[1]

FullGC発生を抑止する仕組み[1]

G

GC制御機能の概要[1]

GC制御の処理の流れ[1]

GCのアルゴリズム[1]

H

HttpSessionオブジェクトに関連するサーブレットAPIの注意点[1]

HTTPセッションで利用するExplicitヒープの省メモリ化機能[1]

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

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

HTTPセッションに関するオブジェクトでExplicitヒープを利用する際の注意[1]

HTTPセッションに登録されたオブジェクトによるセッション情報の引き継ぎ[1]

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

HTTPセッションの参照専用リクエストの定義機能[1]

HTTPセッションの縮退[1]、[2]

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

J

J2EEアプリケーションの閉塞制御[1]、[2]

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

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

J2EEサーバ間のセッション情報の引き継ぎ[1]

J2EEリソースアダプタ[1]

java.naming.factory.initial[1]

javagcコマンドによるExplicitメモリブロックの解放[1]

JavaVM終了メソッド呼び出し時のJavaVMの動作設定[1]

JavaVMのログの取得（JavaVMログファイル）[1]

Javaアプリケーションからの移行[1]

Javaヒープの初期サイズと最大サイズの設定[1]

JavaロギングAPI[1]

Javaロギングの仕組み[1]

JP1/AJS，BJEX，およびJP1/Advanced Shellと連携しないシステム[1]

JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するシステム[1]

JP1/AJS，BJEX，およびJP1/Advanced Shellと連携するための設定[1]

JP1/AJSとの連携[1]

JP1/AJSと連携するシステム[1]

JP1/AJSと連携するための設定[1]

JP1連携による運用管理機能の概要[1]

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

L

LogManagerのカスタマイズ[1]

P

PreparedStatementのプールサイズ[1]

R

realservername[1]

RMI-IIOP通信のタイムアウト[1]

S

SecurityManagerを使用しない設定[1]

Stateless Session Beanに対するリモートインタフェース呼び出し[1]

Suvivor領域の年齢分布情報の出力[1]

T

TPBrokerクライアントまたはTPBroker OTMクライアントからのJ2EEアプリケーションの呼び出し[1]

U

use.security[1]

V

vbroker.agent.enableLocator[1]

vbroker.se.iiop_tp.host[1]

vbroker.se.iiop_tp.scm.iiop_tp.listener.port[1]

W

Webアプリケーション開始時のグローバルセッション情報の引き継ぎ[1]、[2]

Webアプリケーションの一致の確認のために使用される項目[1]

WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れ（データベースセッションフェイルオーバ機能）[1]

あ

空きレコード情報テーブル[1]

アプリケーションサーバ 11-40での主な機能変更[1]

アプリケーションサーバが管理するトランザクションの外でのコネクションシェアリングの有効化[1]

アプリケーション識別子（データベースセッションフェイルオーバ機能）[1]

アプリケーション情報テーブル[1]

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

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

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

アプリケーションのユーザログ出力[1]

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

お

同じネットワークセグメント内でのCTMドメインマネジャによる情報共有[1]

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

オンライン状態でのJ2EEアプリケーションの入れ替え[1]、[2]

か

各フィールドが示す値（MemoryUsageクラスのインスタンス）[1]

各フィールドの情報（MemoryUsageクラスのインスタンス）[1]

簡易構築定義ファイルでのリクエストの負荷分散の定義[1]

完全一致指定[1]、[2]

完全性保障モード[1]

き

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

機能説明の分類[1]

キュー[1]

キューの滞留監視[1]

キュー名称[1]

く

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

グローバルCORBAネーミングサービス[1]、[2]、[3]

グローバルセッション[1]

グローバルセッション情報[1]

グローバルセッション情報操作中の障害発生時の動作（データベースセッションフェイルオーバ機能）[1]

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

グローバルセッション情報に含まれる情報[1]

グローバルセッション情報の削除（HTTPセッションの破棄）（データベースセッションフェイルオーバ機能）[1]

グローバルセッション情報の削除（データベースセッションフェイルオーバ機能）[1]

グローバルセッション情報のロック[1]

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

こ

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

異なるネットワークセグメントでのCTMドメインマネジャによる情報共有[1]

コネクション管理スレッド[1]

コネクション枯渇時のコネクション取得待ち[1]

コネクションスイーパ[1]

コネクション数調節機能[1]

コネクションの最小値と最大値[1]

コネクションの取得リトライ[1]

コネクションの障害検知[1]

コネクションのレギュレート[1]

コネクションのレギュレートの仕組み[1]

コネクションプールのウォーミングアップ[1]

コンテナ拡張ライブラリ[1]、[2]

コンテナ拡張ライブラリの概要[1]

さ

サーバ起動・停止フック機能[1]

サービス閉塞[1]

サーブレットAPIへの影響[1]

参照専用リクエスト[1]

し

実サーバ名の設定[1]

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

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

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

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

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

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

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

自動配置設定ファイル[1]

常駐スレッド数の平均化[1]

ジョブID[1]

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

シリアライズに失敗する場合とその対処[1]

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

す

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

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

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

スケジューリング機能の概要[1]

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

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

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

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

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

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

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

スケジューリング機能を使用する設定〔バッチアプリケーションで使用するコマンドの設定〕[1]

スケジューリング機能を使用する設定〔バッチサーバの設定〕[1]

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

スケジュールキュー[1]、[2]、[3]

スケジュールキュー監視[1]

スケジュールキュー監視機能[1]

スケジュールキュー滞留監視式[1]

スケジュールキューで制御されるリクエスト[1]

スケジュールキューの強制閉塞[1]

スケジュールキューの共有[1]

スケジュールキューの作成単位[1]

スケジュールキューの作成単位とキューの共有[1]

スケジュールキューのタイムアウト閉塞[1]、[2]

スケジュールキューの長さ[1]

スケジュールキューの長さの設定〔簡易構築定義ファイル〕[1]

スケジュールキューの閉塞制御[1]、[2]

スケジュールキューを共有しない例[1]

スケジュールキューを共有する例（Bean単位）[1]

スケジュールキューを共有する例（J2EEアプリケーション単位）[1]

スケジュールグループ[1]

スケジュールグループ名の設定〔usrconf.cfg〕[1]

スケジュールグループ名の設定〔簡易構築定義ファイル〕[1]

スケジュールポリシー[1]

ステートメントキャンセル[1]

スマートエージェントが使用しているポート番号の設定[1]

スマートエージェントを使用する設定[1]

スレッドの使用[1]

せ

セッション情報[1]

セッション情報格納テーブル[1]

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

セッション情報の格納の流れ（データベースセッションフェイルオーバ機能）[1]

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

セッションフェイルオーバ機能[1]

セッションフェイルオーバ機能共通の前提となる設定[1]

セッションフェイルオーバ機能使用時に実行される機能[1]

セッションフェイルオーバ機能使用時に設定できる機能[1]

セッションフェイルオーバ機能の前提となる構成[1]

セッションフェイルオーバ機能の抑止[1]

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

セッションフェイルオーバ抑止機能[1]

接続できるデータベース[1]

そ

そのほかの拡張機能とシステムの目的の対応[1]

ち

長寿命オブジェクト[1]

て

データベースコネクション確立までの待ち時間[1]

データベースセッションフェイルオーバ機能[1]、[2]、[3]

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

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

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

データベースセッションフェイルオーバ機能の運用モード[1]

データベースセッションフェイルオーバ機能の前提となる設定[1]

データベースセッションフェイルオーバ機能の定義[1]

データベースセッションフェイルオーバ機能の抑止の設定[1]

データベース接続ユーザ[1]

データベーステーブルの初期化[1]

データベースで障害が発生した場合の処理の流れ[1]

データベースの環境設定[1]

データベースの設定[1]

データベースのディスク容量の見積もり[1]

データベースのテーブルの削除[1]

データベースのテーブルの作成[1]

適用手順（データベースセッションフェイルオーバ機能）[1]

と

同一セッションIDの同時実行[1]

同一セッションIDの同時実行機能[1]

同時実行数に指定できる値〔CTM〕[1]

同時実行数の動的変更〔CTM〕[1]

動的変更の処理の仕組み[1]

トランザクションサポートレベル[1]

トレース共通ライブラリ[1]

トレース共通ライブラリ形式[1]

ね

ネーミング管理[1]

ネーミング管理機能[1]

ネーミングサービスの通信タイムアウト[1]

ネーミングのキャッシング[1]

ネゴシエーション処理（データベースセッションフェイルオーバ機能）[1]

ネゴシエーション処理の結果とWebアプリケーションの状態の関係[1]

ネゴシエーションで確認される内容（データベースセッションフェイルオーバ機能）[1]

は

発生するイベントと動作するリスナ[1]

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

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

バッチアプリケーション実行機能[1]

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

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

バッチアプリケーション実行時の注意事項[1]

バッチアプリケーション実行の流れ〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーション実行の流れ〔スケジューリング機能を使用する場合〕[1]

バッチアプリケーション情報の一覧表示〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーション情報の一覧表示〔スケジューリング機能を使用する場合〕[1]

バッチアプリケーションで実装できない機能[1]

バッチアプリケーションで使用するコマンドの実行について〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションで使用するコマンドの実行について〔スケジューリング機能を使用する場合〕[1]

バッチアプリケーションに実装できる処理[1]

バッチアプリケーションの開始処理〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの開始方法〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの強制停止実行時の注意事項[1]

バッチアプリケーションの強制停止処理〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの強制停止方法〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの強制停止〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの強制停止〔スケジューリング機能を使用する場合〕[1]

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

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

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

バッチアプリケーションの実行〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの実行〔スケジューリング機能を使用する場合〕[1]

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

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

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

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

バッチアプリケーションの終了処理〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの状態遷移〔スケジューリング機能を使用しない場合〕[1]

バッチアプリケーションの状態遷移〔スケジューリング機能を使用する場合〕[1]

バッチアプリケーションのスケジューリング[1]

バッチアプリケーションのスケジューリング機能[1]

バッチアプリケーションのファイル形式[1]

バッチアプリケーションのユーザログ出力[1]

バッチアプリケーションのライフサイクル[1]

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

バッチアプリケーションを実行するクラスローダ[1]

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

バッチアプリケーションを実行するシステムの構成例〔スケジューリング機能を使用しない場合〕[1]

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

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

バッチサーバとしてサーバを構築するための設定[1]

バッチサーバによるアプリケーションの実行[1]

バッチサーバの通信ポートとIPアドレスの固定[1]

ハンドラ[1]、[2]

ハンドラの作成と設定[1]

ふ

ファイルやディレクトリの操作[1]

負荷状況の監視[1]

負荷分散[1]

負荷分散機[1]

負荷分散のタイミング[1]

負荷分散〔CTM〕[1]

プリフィックス一致指定[1]、[2]

へ

閉塞制御[1]

閉塞制御〔CTM〕[1]

ま

マルチバイト文字の使用について[1]

め

明示管理ヒープ機能[1]、[2]

明示管理ヒープ機能API[1]

明示管理ヒープ機能APIのクラス階層[1]

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

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

明示管理ヒープ機能適用除外クラス指定機能[1]

明示管理ヒープ機能適用除外設定ファイル[1]

明示管理ヒープ機能適用除外無効設定ファイル[1]

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

明示管理ヒープ機能のJavaVMオプションの定義[1]

明示管理ヒープ機能の位置づけ[1]、[2]

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

明示管理ヒープ機能の利用[1]

明示管理ヒープ機能の利用によるFullGCの抑止の仕組み[1]

明示管理ヒープ機能を使用していない場合の昇格と明示管理ヒープ機能を使用している場合の昇格の違い[1]

明示管理ヒープ機能を使用しない設定[1]

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

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

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

メモリの見積もり[1]

ゆ

ユーザ作成クラス[1]

ユーザ独自のフィルタ／フォーマッタ／ハンドラ[1]

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

ユーザログ[1]

ユーザログ機能[1]

ユーザログ出力処理の流れ[1]

ユーザログ出力で使用するLoggerクラスのメソッド[1]

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

優先制御〔CTM〕[1]

ら

ライトトランザクション機能を有効にするための設定[1]

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

ライフサイクルの各段階と出力されるイベントログの対応[1]

ラウンドロビン検索[1]

り

リクエスト転送時のタイムアウト[1]

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

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

リソースアダプタの使用方法[1]

リソースアダプタの設定の流れ[1]

リソースアダプタの設定方法[1]

リソース接続機能[1]

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

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

リソースへの接続方法[1]

リモートインタフェースでの通信障害発生時のEJBクライアントの動作[1]

流量制御[1]、[2]

流量制御〔CTM〕[1]

れ

レギュレート[1]

ろ

ロガー[1]、[2]

ロガーの作成と設定[1]

ログのフォーマット[1]

ログフォーマット[1]