Cosminexus V11 アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)

解説書

3021-3-J07-30

前書き

対象製品

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

輸出時の注意

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

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

商標類

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

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

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

Amazon Web Services，『Powered by Amazon Web Services』ロゴ，Amazon RDSは，米国および/またはその他の諸国における，Amazon.com, Inc.またはその関連会社の商標です。

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

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

Microsoftは，マイクロソフト 企業グループの商標です。

OracleおよびJavaは，オラクルおよびその関連会社の登録商標です。

Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.

Red Hatは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。

Red Hat Enterprise Linux is a registered trademark of Red Hat, Inc. in the United States and other countries.

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

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

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

Windowsは，マイクロソフト 企業グループの商標です。

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

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

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

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

発行

2022年 3月 3021-3-J07-30

著作権

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

変更内容

変更内容(3021-3-J07-30) uCosminexus Application Server 11-20，uCosminexus Client 11-20，uCosminexus Developer 11-20，uCosminexus Service Architect 11-20，uCosminexus Service Platform 11-20

追加・変更内容

変更個所

Java EE 8に対応した。

1.1，16.4.1

アプリケーションサーバが対応している標準仕様に，JAX-RS 2.1を追加した。

1.1.3

アプリケーションサーバが対応している標準仕様に，JPA 2.2を追加した。

1.1.3，6.

アプリケーションサーバが対応している標準仕様に，JSON-B 1.0を追加した。

1.1.3，13.，19.6，20.4

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

1.4

マネージドデータベースサービスに関する説明を追加した。

3.6.9，3.6.10，3.6.11

CDI Managed BeanでのJPA利用に対応した。

5.3.2，5.3.3，9.4，15.4

JPA 2.2利用時の時間を扱う際の注意事項を追加した。

6.5.3

アプリケーションサーバが対応している標準仕様に，CDI 2.0を追加した。また，CDIを利用する場合の注意事項を追加した。

9.1，9.3.1，9.4，17.5.1，17.5.3

次のファイルをCDIの管理対象に追加できるようにした。

WARファイル内のWEB-INF/lib以下のJARファイル

9.3.1，9.3.2，9.4

アプリケーションサーバが対応している標準仕様に，Bean Validation 2.0を追加した。

10.4，10.8

アプリケーションサーバが対応している標準仕様に，JSON-P 1.1を追加した。

12.2，19.6，20.4

インターセプタを有効にできない条件を変更した。

15.4

アプリケーションサーバが対応している標準仕様に，Servlet 4.0を追加した。

16.4.1

persistence.xmlファイルの検証方法を変更した。

付録C.2(1)

O/Rマッピングファイルの検証方法を変更した。

付録C.2(2)

マニュアル訂正の内容を反映した。

−

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

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & 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実装時の注意事項

ネーミング管理

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

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

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

JPA 2.2の利用

CJMSプロバイダ

JavaMailの利用

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

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

Java Batch

JSON-P

JSON-B

Concurrency Utilities

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

アノテーションの使用

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

コンテナ拡張ライブラリ

ライブラリ競合回避機能

拡張機能

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

拡張編

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　システムの目的と機能の対応

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

この節では，WebコンテナおよびEJBコンテナが共通で使用できる機能について，どのようなシステムの場合に使用するとよいかを示します。機能ごとに，次の項目への対応を示しています。

信頼性

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

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

性能

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

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

運用・保守

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

拡張性

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

そのほか

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

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

1.2.1　ネーミング管理の機能

ネーミング管理の機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒2　ネーミング管理の機能とシステムの目的の対応

機能

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

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

−

−

−

○

−

○

○

2.3

Portable Global JNDI名でのルックアップ

−

−

−

○

−

○

○

2.4

HITACHI_EJBから始まる名称でのルックアップ

−

−

−

○

−

○

○

2.5

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

−

−

−

○

−

−

○

2.6

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

−

−

−

○

−

−

○

2.7

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

−

○

−

−

−

−

○

2.8

ネーミングサービスの障害検知

○

−

−

−

−

−

○

2.9

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

−

−

−

○

−

−

○

2.10

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

−

−

−

○

−

○

○

2.11

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

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

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

リソース接続とトランザクション管理の機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒3　リソース接続とトランザクション管理の機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

コネクションプーリング

−

○

−

−

−

○

○

3.14.1

コネクションプーリングで使用できる機能

−

○

−

−

−

−

○

3.14.2

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

−

○

−

−

−

○

−

3.14.3

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

−

○

−

−

−

−

○

3.14.4

ライトトランザクション

−

○

−

−

−

−

○

3.14.5

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

−

○

−

−

−

○

−

3.14.6

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

−

○

−

−

−

−

○

3.14.7

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

−

○

−

−

−

−

○

3.14.8

コネクションの障害検知

○

−

−

−

−

○※1

○※1

3.15.1

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

○

−

−

−

−

−

○

3.15.2

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

○

−

−

−

−

−

○

3.15.3

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

○

−

−

−

−

−

○

3.15.4

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

○

−

−

−

−

−

○

3.15.5

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

○

−

−

−

−

○

−

3.15.6

コネクションスイーパ

○

−

−

−

−

−

○

3.15.7

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

○

−

−

−

−

○

−

3.15.8

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

○

−

−

−

−

○

−

3.15.9

障害調査用SQLの出力

−

−

○

−

−

−

○

3.15.10

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

○

−

−

−

−

○

−

3.15.11

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

−

−

−

−

−

○

−

3.16.1

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

−

−

−

−

−

○

−

3.16.2

メッセージインフロー※2

−

−

−

−

−

○

−

3.16.3

トランザクションインフロー※3

−

−

−

−

−

○

−

3.16.4

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

−

−

−

−

−

○

−

3.16.5

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

−

−

−

−

−

○

−

3.16.6

リソースへの接続テスト

−

−

○

−

−

−

○

3.17

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

−

−

○

−

−

−

○

3.18

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

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

注※1　Connector 1.0の場合は「拡張」です。Connector 1.5の場合は「Java EE標準」です。

注※2　Connector 1.5仕様に準拠したリソースアダプタを使用する場合だけ使用できる機能です。

注※3　Connector 1.5仕様に準拠したリソースアダプタのうち，TP1インバウンドアダプタを使用する場合だけ使用できる機能です。

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

OpenTP1からアプリケーションサーバを呼び出す際のTP1インバウンド連携機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒4　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

コネクション管理機能

−

−

○

−

○

−

○

4.6

RPC通信機能

−

−

○

−

○

−

○

4.7

スケジュール機能

−

−

○

−

○

−

○

4.8

トランザクション連携機能

−

−

○

−

○

−

○

4.9

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

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

1.2.4　アプリケーションサーバで使用するJPAの機能

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

表1‒5　アプリケーションサーバで使用するJPAの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

JPA

○

−

○

−

−

○

○

6章

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

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

1.2.5　CJMSプロバイダの機能

CJMSプロバイダの機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒6　CJMSプロバイダの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

JMS仕様に準拠したメッセージの送受信

−

−

−

−

○

○

−

7.4

7.5

7.6

メッセージ配信の高信頼性確保の仕組み

○

−

−

−

−

○

−

7.7

CJMSPブローカーの機能

−

−

○

−

−

○

−

7.8

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

−

−

−

−

○

○

−

7.9

Message-driven Beanの呼び出し

−

−

−

−

○

○

−

7.10

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

1.2.6　JavaMailの機能

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

表1‒7　JavaMailの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

JavaMail

−

−

−

−

○

○

−

8章

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

1.2.7　アプリケーションサーバで使用するCDIの機能

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

表1‒8　CDIの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

CDI

−

−

−

−

○

○

−

9章

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

1.2.8　アプリケーションサーバで使用するBean Validationの機能

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

表1‒9　 Bean Validationの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

Bean Validation

−

−

−

−

○

○

−

10章

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

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

アプリケーションの属性管理の機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒10　アプリケーションの属性管理の機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

cosminexus.xmlを含むアプリケーション

−

−

−

○

−

−

○

16.3

DDの省略

−

−

−

○

−

○

○

16.4

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

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

1.2.10　アノテーションの機能

アノテーションの機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒11　アノテーションの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

アノテーション

−

−

−

○

−

○

○

17章

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

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

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

J2EEアプリケーションの形式とデプロイの機能を次の表に示します。システムの目的に合った機能を選択してください。機能の詳細については，参照先を確認してください。

表1‒12　J2EEアプリケーションの形式とデプロイの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

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

−

−

−

−

−

○

○

18.5

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

−

−

−

−

−

○

−

18.6

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

−

−

○

−

−

−

○

18.7

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

−

−

○

−

−

−

○

18.8

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

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

1.2.12　コンテナ拡張ライブラリの機能

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

表1‒13　コンテナ拡張ライブラリの機能とシステムの目的の対応

機能名

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

コンテナ拡張ライブラリ機能

−

−

−

○

−

−

○

19.3

サーバ起動・停止フック機能

−

−

−

○

−

−

○

19.4

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

−

−

−

○

−

−

○

19.5

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

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

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.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

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

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

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

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

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

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

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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章

2　ネーミング管理

この章では，ネーミング管理の機能について説明します。ネーミング管理は，J2EEサービスで提供されている機能の一つです。ネーミング管理機能を使用して，Enterprise Bean参照またはリソース参照のための名前解決を実現します。

2.1　この章の構成

ネーミング管理は，J2EEサービスで提供されている機能の一つです。J2EEサービスは，J2EEコンテナの部品機能として利用される機能です。

ネーミング管理の機能と参照先を次の表に示します。

表2‒1　ネーミング管理の機能と参照先

機能

参照先

ネーミング管理の概要

2.2

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

2.3

Portable Global JNDI名でのルックアップ

2.4

HITACHI_EJBから始まる名称でのルックアップ

2.5

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

2.6

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

2.7

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

2.8

ネーミングサービスの障害検知

2.9

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

2.10

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

2.11

注※　ルックアップには何種類かの方法があります。ルックアップ名称および方法については，「2.3.1　ルックアップで使用する名称の種類」を参照してください。

2.2　ネーミング管理の概要

この節では，ネーミング管理の機能，およびネーミング管理で使用するネーミングサービスについて説明します。

2.2.1　ネーミング管理の機能

ネーミング管理では，オブジェクト（Enterprise Beanに対応するEJBホームオブジェクト，ビジネスインタフェースのリファレンスおよびJ2EEリソース）の名前と格納場所を管理しています。ネーミング管理の機能を使用することで，EJBクライアントは，呼び出すEnterprise Beanまたはリソースの格納場所を知らなくても，名前から必要なオブジェクトを利用できるようになります。

また，Connector 1.5仕様に準拠したリソースアダプタを使用する場合，管理対象オブジェクトもネーミング管理で管理されています。管理対象オブジェクトは，J2EEアプリケーションの中からメッセージの送信および同期受信をするときに使用するオブジェクトです。管理対象オブジェクトについては，「3.16.5　管理対象オブジェクトのルックアップ」を参照してください。

ネーミング管理機能のJNDIでは，CORBAオブジェクトリファレンス以外のオブジェクト（RMI-IIOPのリモートオブジェクトやJDBCデータソースなどのオブジェクト）を次のように扱います。

CORBAオブジェクトリファレンス以外の登録は，対象のオブジェクトをCORBAオブジェクトに変換し，CORBAオブジェクトリファレンスをCORBAネーミングサービスへ登録することで実現しています。

CORBAオブジェクト以外のオブジェクトの検索は，CORBAオブジェクトリファレンスを検索し，CORBAオブジェクトから逆変換して元のオブジェクトを取得することで実現しています。

なお，アプリケーションサーバで提供するネーミング管理の機能には，J2EEで規定された機能にアプリケーションサーバ独自の機能を拡張したものと，アプリケーションサーバ独自の機能として提供しているものがあります。アプリケーションサーバ独自の機能かどうかについては，「1.　アプリケーションサーバの機能」を参照してください。

アプリケーションサーバが提供するネーミング管理の機能と対象になるオブジェクトの関係を次の表に示します。

表2‒2　アプリケーションサーバが提供するネーミング管理の機能と対象になるオブジェクトの関係

機能

Enterprise Bean

J2EEリソース

EJBホームオブジェクト

ビジネスインタフェース

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

○

○

○※1

Portable Global JNDI名でのルックアップ

○

○

○

HITACHI_EJBから始まる名称でのルックアップ

○

○

×

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

○

○

○

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

○

○

×

ネーミング管理機能でのオブジェクトのキャッシング

○

×※2

×

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

○

×

×

（凡例）

○：使用できる　×：使用できない

注※1

HITACHI_EJBから始まる名称でのルックアップはできません。

注※2

ビジネスインタフェース使用時に，プロパティ「ejbserver.jndi.cache」に「on」を設定している状態でJ2EEサーバを再起動した場合，ビジネスメソッド実行時にjavax.ejb.EJBExceptionが発生する場合があります。

注意事項

Webアプリケーションでカスタムエラーページを設定している場合，設定されたエラーページからJNDIを利用できません。

2.2.2　ネーミングサービス

ネーミング管理機能を使用する場合，オブジェクトの名前と格納場所は，ネーミングサービスによって管理されます。

アプリケーションサーバでは，ネーミング管理の機能として，CORBAネーミングサービスを利用したJNDIをサポートしています。オブジェクトの登録，削除，または検索などのJNDIのインタフェースが呼び出されたときに，対応するCORBAネーミングサービスのインタフェースを呼び出します。したがって，ネーミング管理機能を利用するためには，CORBAネーミングサービスへの接続情報としてプロトコル，ホスト名，およびポート番号を設定する必要があります。

参考

CORBAネーミングサービスはJ2EEサーバのインプロセスで起動できます。インプロセスで起動することで，個別の起動・終了が不要になり，運用性が向上します。

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

ルックアップの対象になるオブジェクトは，JNDI名前空間の名前と関連づけて管理されます。

J2EEサーバ内で実行するアプリケーションでは，利用したいリソースマネジャや呼び出したいEnterprise Beanなどのオブジェクトを参照するために，JNDIの名前空間で検索（ルックアップ）を実行します。

この節では，ルックアップに使用する名称の種類，バインドされる名称の規則，およびルックアップの仕組みについて説明します。また，JNDI名前空間の確認方法についても説明します。

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

表2‒3　この節の構成（JNDI名前空間へのオブジェクトのバインドとルックアップ）

分類

タイトル

参照先

解説

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

2.3.1

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

2.3.2

JNDI名前空間の確認方法

2.3.3

実装

cosminexus.xmlでの定義

2.3.4

設定

実行環境での設定

2.3.5

注　「運用」について，この機能固有の説明はありません。

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

アプリケーションサーバでは，次に示す4種類の名称を使用したルックアップができます。

Portable Global JNDI名でのルックアップ

Java EEで規定されたjava:global，java:app，またはjava:moduleから始まる名称（Portable Global JNDI名）を指定してルックアップする方法です。Enterprise BeanまたはJ2EEリソースをルックアップするときに使用できます。

java:comp/envを使用した名称でのルックアップ

Java EEで規定されたjava:comp/envを使用した名称を指定してルックアップする方法です。Enterprise BeanまたはJ2EEリソースをルックアップするときに使用できます。

HITACHI_EJBから始まる名称でのルックアップ

アプリケーションサーバ独自の命名規則で自動的にバインドされる名称を指定してルックアップする方法です。Enterprise Beanをルックアップするときに使用できます。

ユーザ指定名前空間機能を利用して付与した別名でのルックアップ

アプリケーションサーバ独自の機能（ユーザ指定名前空間機能）を利用して登録した任意の名称を指定してルックアップする方法です。Enterprise BeanまたはJ2EEリソースをルックアップするときに使用できます。

EJBクライアントの形態ごとに，利用できるルックアップ方法，および推奨するルックアップ方法を次の表に示します。

表2‒4　ルックアップ方法の種類

EJBクライアントの形態

ルックアップの方法

Portable Global JNDI名でのルックアップ

java:comp/envを使用した名称でのルックアップ

HITACHI_EJBから始まる名称でのルックアップ

ユーザ指定名前空間機能を利用して付与した別名でのルックアップ

EJBクライアントアプリケーション

◎

×

○

○

JSP，サーブレット

○

◎

○

○

EJB

○

◎

○

○

（凡例）　◎：利用を推奨する　○：利用できる　×：利用できない

それぞれのルックアップ名称とその名称を使用したルックアップ方法について説明します。

(1)　Portable Global JNDI名でのルックアップ

Portable Global JNDI名でのルックアップについて，名称の定義方法，ルックアップできる範囲や特徴について説明します。

定義方法

Portable Global JNDI名を使用したルックアップには，自動的にバインドされる名称でのルックアップとリソース参照の定義に指定した名称でのルックアップがあります。

自動的にバインドされる名称のルックアップの場合

アプリケーションサーバでのJ2EEアプリケーションのデプロイ時に，オブジェクトリファレンスに自動的に付与されます。この名称は，Java EEで規定されている命名規則で定義され，java:global，java:app，またはjava:moduleから始まります。この名称をPortable Global JNDI名といいます。

リソース参照の定義に指定した名称のルックアップの場合

Portable Global JNDI名をDDのリソース参照の定義に指定します。

ルックアップできる範囲

同じCORBAネーミングサービスを利用するすべてのJ2EEサーバまたはEJBクライアントアプリケーション内で，Enterprise BeanまたはJ2EEリソースをルックアップできます。

特徴

J2EEアプリケーションのデプロイ時に，Enterprise Beanに対応するEJBホームオブジェクトリファレンス，およびビジネスインタフェースのリファレンスが，自動的にjava:global，java:app，またはjava:moduleから始まる名称にバインドされます。バインドされる名称には，標準アプリケーション名や標準モジュール名が付与されるので，名前空間の衝突を回避できます。また，Portable Global JNDI名は，他社製のアプリケーションサーバ間に共通のJNDI名のため，アプリケーションサーバ間のJ2EEアプリケーションの移行の際に，ソースコードやDDの修正が不要です。

Portable Global JNDI名でのルックアップについては，「2.4　Portable Global JNDI名でのルックアップ」を参照してください。また，標準アプリケーション名および標準モジュール名については，「2.4.2　自動的にバインドされるオブジェクト」を参照してください。

(2)　java:comp/envを使用した名称でのルックアップ

java:comp/envを使用した名称のルックアップについて，名称の定義方法，ルックアップできる範囲や特徴について説明します。

定義方法

Java EEで定義されているjava:comp/envを使用した参照名と，実際の名称間のリンクの対応をDDのリソース参照に定義します。これによって，デプロイ時に参照名と実際の名称間のリンクを解決します。

ルックアップできる範囲

一つのコンポーネント内でルックアップできます。ただし，Webアプリケーションの場合は，一つのWebアプリケーション内でルックアップできます。

特徴

java:comp/envは，Java EEで定義されている，名前空間のコンテキストルートです。java:comp/envを使用して，J2EEアプリケーション内の異なるEJB-JARおよびWebアプリケーション間でのルックアップや，J2EEリソースのルックアップができます。

java:comp/envを使用した名称のルックアップについては，Java EEの規定どおりの仕様です。

(3)　HITACHI_EJBから始まる名称でのルックアップ

HITACHI_EJBから始まる名称のルックアップについて，名称の定義方法，ルックアップできる範囲や特徴について説明します。

定義方法

アプリケーションサーバでのJ2EEアプリケーションのデプロイ時に，オブジェクトリファレンスに自動的に付与されます。この名称は，アプリケーションサーバ独自の命名規則で定義されます。

ルックアップできる範囲

同じCORBAネーミングサービスを利用するすべてのJ2EEサーバまたはEJBアプリケーション内でEnterprise Beanをルックアップできます。

特徴

J2EEアプリケーションのデプロイ時に，Enterprise Beanに対応するEJBホームオブジェクトリファレンス，およびビジネスインタフェースのリファレンスが，自動的にHITACHI_EJBから始まる名称にバインドされます。バインドされる名称には，J2EEアプリケーションのサーバ名やアプリケーション名が付与されるので，名前空間の衝突を回避できます。

HITACHI_EJBから始まる名称でのルックアップについては，「2.5　HITACHI_EJBから始まる名称でのルックアップ」を参照してください。

(4)　ユーザ指定名前空間機能を利用して付与した別名でのルックアップ

ユーザ指定名前空間機能を利用して付与した別名でのルックアップについて，名称の定義方法，ルックアップできる範囲や特徴について説明します。

定義方法

アプリケーションサーバのユーザ指定名前空間機能を利用して，Enterprise BeanまたはJ2EEリソースに別名を定義します。

ルックアップできる範囲

同じCORBAネーミングサービスを利用するすべてのJ2EEサーバ内でEnterprise BeanまたはJ2EEリソースをルックアップできます。

特徴

ユーザ指定名前空間機能を利用すると，Enterprise Beanの場合はJNDIの名前へのバインドと合わせて，EJBホームオブジェクトリファレンスまたはビジネスインタフェースのリファレンスの別名を登録できます。また，J2EEリソース（リソースアダプタ，メールコンフィグレーション，JavaBeansリソース）に対しても，別名を登録できます。

別名を登録することで，ユーザが指定した任意の名称でEnterprise BeanおよびJ2EEリソースをルックアップできるようになります。

Enterprise BeanまたはJ2EEリソースへの別名付与の詳細については，「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

参考

Java EEの仕様では，java:comp/envを使用した名称でのルックアップが推奨されています。

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

ここでは，JNDI名前空間のマッピングの仕組みと，ルックアップでの指定する名称とJNDI名前空間およびDDの関係について説明します。

(1)　Enterprise Beanを参照する仕組みと使い方（ejb-ref）

J2EEサーバ内で実行するアプリケーションでは，Enterprise Beanを呼び出すために，Enterprise Bean参照の名前解決が必要です。正確には，Enterprise Beanに対応するEJBホームインタフェース，EJBローカルホームインタフェース，ビジネスインタフェースなどの名前解決をします。

EJBホームインタフェース，またはビジネスインタフェースの名前解決をするためには，次の2種類の作業が必要です。

参照側アプリケーションの作成時の作業

アプリケーションの作成時に参照用の名称を決め，Enterprise Beanやサーブレットなどのプログラム内でのlookupの引数に，その参照用の名称を指定します。また，java:comp/envを使用する場合は，DDの<ejb-ref>に，決めた参照用の名称を記載します。

参照側アプリケーションのデプロイ時の作業

作成したアプリケーションをJ2EEサーバ上にデプロイするときに，Enterprise Beanをカスタマイズして，参照用の名称と実際の名称をlinked-toで結び付けます。

この操作は，サーバ管理コマンドを使用して実行できます。

マッピングの仕組みは，参照側のアプリケーションと参照先のアプリケーションが同じJ2EEアプリケーションか，別のJ2EEアプリケーションかによって異なります。次に，EJBホームインタフェースの名前解決の例として，別のJ2EEアプリケーションのEnterprise Beanを参照する場合と，同じJ2EEアプリケーション内のEnterprise Beanを参照する場合の例を示します。

(a)　別のJ2EEアプリケーションのEnterprise Beanを参照する場合

J2EEアプリケーションから別のJ2EEアプリケーションに含まれるEnterprise Beanを参照する例を，次の図に示します。

図2‒1　J2EEアプリケーションから別のJ2EEアプリケーションに含まれるEnterprise Beanを参照する例

java:comp/envを使用する場合，参照側のプログラムのlookupに指定するjava:comp/env下の参照名と実際にJNDI名前空間に登録されているlookup名は，デフォルトで対応づけられます（linked-to）。なお，lookup名をJNDI名前空間に登録されている名称と異なる名称にする場合は，サーバ管理コマンドでカスタマイズする必要があります。図の場合は，PetShopEBをejb/PetShopBeanとして呼び出すようにカスタマイズします。

ユーザ指定名前空間機能を使用する場合，参照側のプログラムのlookupに別名を指定できます。<ejb-ref>の定義は不要です。

(b)　同じJ2EEアプリケーション内のEnterprise Beanを参照する場合

J2EEアプリケーションから同じJ2EEアプリケーションに含まれるEnterprise Beanを参照する例を，次の図に示します。

図2‒2　同じJ2EEアプリケーションに含まれるEnterprise Beanを参照する例

同じアプリケーション内のEnterprise Beanを呼び出す場合は，lookup名による参照の解決ではなく，<ejb-ref-name>とejb-nameを結び付けて解決します（linked-to）。なお，同一のJ2EEアプリケーションの場合，参照に必要な情報はアプリケーション開発時に判明しているので，DDの<ejb-link>タグに直接ejb-nameを書き込んでおくこともできます。

(2)　リソースを参照する仕組みと使い方（resource-ref）

J2EEサーバ内で実行するアプリケーションでリソースアダプタを利用する場合，lookupによるリソース参照の名前解決が必要です。正確には，リソースマネジャへのコネクションを作成するファクトリの名前解決をします。

リソースマネジャへのコネクションを作成するファクトリの名前解決をするためには，次の2種類の作業が必要です。

参照側アプリケーションの作成時の作業

アプリケーションの作成時に参照用の名称を決め，Enterprise Beanやサーブレットなどのプログラム内でのlookupの引数に，その参照用の名称を指定します。また，DDの<resource-ref>に，決めた参照用の名称を記載します。

参照側アプリケーションのデプロイ時の作業

作成したアプリケーションをJ2EEサーバ上にデプロイするときに，リソースをカスタマイズして，参照用の名称とJ2EEサーバ上に登録済みのリソースをlinked-toで結び付けます。

この操作は，サーバ管理コマンドを使用して実行できます。

次にDB Connector経由でデータベースにアクセスする場合の例を示します。

図2‒3　DB Connector経由でデータベースにアクセスする場合の例

この例では，リソースの参照名称とリソースの表示名称を結び付けています。

2.3.3　JNDI名前空間の確認方法

コマンドを使用して，CORBAネーミングサービスで認識されている名称を表示して確認できます。なお，J2EEリソースの別名やEJBローカルホームオブジェクトリファレンスの登録情報は確認できません。使用するコマンドは，nsutilコマンドです。nsutilコマンドの使用方法，使用条件などについては，マニュアル「Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド」を参照してください。

JNDI名前空間の「HITACHI_EJB/SERVERS/MyServer/EJB」の下位の一覧を表示する場合の表示例を次に示します。

# nsutil -VBJprop ORBInitRef=NameService=corbaname::localhost:900 list HITACHI_EJB/SERVERS/MyServer/EJB
Bindings in HITACHI_EJB/SERVERS/MyServer/EJB
Context: App1
Context: App2
Context: App3

2.3.4　cosminexus.xmlでの定義

ネーミング管理の機能の定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。cosminexus.xmlでのネーミング管理のための定義について次の表に示します。

表2‒5　cosminexus.xmlでのネーミング管理の機能の定義

指定するタグ

設定内容

<session>−<lookup-name>タグ

<entity>−<lookup-name>タグ

ルックアップ名称を指定します。

cosminexus.xmlについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

2.3.5　実行環境での設定

ネーミング管理機能を使用する場合，J2EEサーバの設定，サーバ管理コマンドのカスタマイズ，J2EEアプリケーションの設定が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。ネーミング管理機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでのネーミング管理機能の定義について次の表に示します。

表2‒6　簡易構築定義ファイルでのネーミング管理の機能の定義

項目

指定するパラメタ

設定内容

基本設定

ejbserver.naming.host※

CORBAネーミングサービスのホスト名を指定します。

ejbserver.naming.port※

CORBAネーミングサービスのポート番号を指定します。

ejbserver.naming.startupMode

CORBAネーミングサービスの起動モードを指定します。

ネーミングサービスの通信タイムアウト

ejbserver.jndi.request.timeout

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

注※　デフォルトの設定では，J2EEサーバはホスト名「localhost」，ポート番号「900」のCORBAネーミングサービスをインプロセスで自動起動して使用します。設定を変更したい場合に変更してください。

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

(2)　サーバ管理コマンドのカスタマイズ

サーバ管理コマンドの動作設定をカスタマイズできます。ここでは，サーバ管理コマンドが使用するCORBAネーミングサービスの設定について説明します。

ネーミング管理の機能を使用するためのサーバ管理コマンドのカスタマイズは，usrconf.properties（サーバ管理コマンド用システムプロパティファイル）で設定します。設定内容を次に示します。なお，キーの詳細，およびここで説明していないキーについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「5.　サーバ管理コマンドで使用するファイル」を参照してください。

表2‒7　ネーミング管理機能を使用するためのサーバ管理コマンドのカスタマイズ

項目

指定するキー

設定内容

CORBAネーミングサービスが動作するホスト名

ejbserver.naming.host

サーバ管理コマンドが使用するCORBAネーミングサービスが動作するホストを指定します。

CORBAネーミングサービスのポート番号

ejbserver.naming.port

サーバ管理コマンドが使用するCORBAネーミングサービスのポート番号を指定します。

CORBAネーミングサービスへのアクセスプロトコル

ejbserver.naming.protocol

サーバ管理コマンドが使用するCORBAネーミングサービスへのアクセスプロトコルを指定します。

(3)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。ネーミング管理の機能の定義には，Session Bean属性ファイルまたはEntity Bean属性ファイルを使用します。

これらの属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.3.4　cosminexus.xmlでの定義」を参照してください。

2.4　Portable Global JNDI名でのルックアップ

J2EEアプリケーションをデプロイすると，EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスのJNDIの名前に，Portable Global JNDI名が自動的にバインドされます。ルックアップ時には，バインドされた名前を使用します。

ここでは，Java EEで定義されている名前空間，Portable Global JNDI名でバインドされるオブジェクト，命名規則，DDでの定義，および実行環境での設定について説明します。

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

表2‒8　この節の構成（Portable Global JNDI名でのルックアップ）

分類

タイトル

参照先

解説

JNDI名前空間の種類

2.4.1

自動的にバインドされるオブジェクト

2.4.2

Portable Global JNDI名の命名規則

2.4.3

Portable Global JNDI名の登録抑止

2.4.4

CTMを使用する場合のPortable Global JNDI名のルックアップ

2.4.5

リソース参照の名称

2.4.6

アノテーションでのPortable Global JNDI名の指定

2.4.7

実装

DDでの定義

2.4.8

設定

実行環境での設定

2.4.9

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

2.4.1　JNDI名前空間の種類

Java EEで定義されているJNDI名前空間の種類とルックアップできる範囲について説明します。

JNDI名前空間の範囲を次の図に示します。

図2‒4　JNDI名前空間の範囲

java:global

すべてのJ2EEアプリケーションで共有される名前空間です。アプリケーションサーバでは，同じCORBAネーミングサービスを利用するすべてのJ2EEサーバまたはEJBクライアントアプリケーションで共有されます。

java:app

J2EEアプリケーション内で共有される名前空間です。一つのJ2EEアプリケーション内のすべてのコンポーネント（Enterprise Bean，サーブレット，JSP，フィルタ，およびリソースアダプタ）で共有されます。

java:module

各種モジュール（EJB-JAR，Webアプリケーションまたはリソースアダプタ）内で共有される名前空間です。一つのモジュール内のすべてのコンポーネント（Enterprise Bean，サーブレット，JSP，フィルタ，およびリソースアダプタ）で共有されます。

java:comp

各種コンポーネント（Enterprise Bean，サーブレット，JSP，フィルタ，またはリソースアダプタ）内で共有される名前空間です。一つのコンポーネント内でだけ共有されます。ただし，Webアプリケーションの場合は，Webアプリケーション内のすべてのサーブレットまたはJSPで共有されます。

ルックアップ対象のコンポーネントがルックアップ元と同じプロセス，アプリケーション，モジュールまたはコンポーネントに含まれているかによって，使用できる名前空間が異なります。ルックアップするコンポーネントとの関係と，名前空間ごとのルックアップ可否を次の表に示します。

表2‒9　名前空間ごとのルックアップ可否

項番

ルックアップするコンポーネントとの関係

ルックアップする名前空間

サーバ（プロセス）

アプリケーション

モジュール

コンポーネント

java:global

java:app

java:module

java:comp

1

同じ

同じ

同じ

同じ

○

○

○

○

2

同じ

同じ

同じ

異なる

○

○

○

△※1

3

同じ

同じ

異なる

異なる

○

○

×

×

4

同じ

異なる

異なる

異なる

○

×

×

×

5

異なる※2

異なる

異なる

異なる

○※3

×

×

×

（凡例）

○：ルックアップできる。

△：コンポーネントの種類によってルックアップできる。

×：ルックアップできない。

注※1

Webアプリケーション内のコンポーネント（サーブレット，JSPまたはフィルタ）の場合，ルックアップできます。

注※2

サーバ（プロセス）は異なるが，同一のCORBAネーミングサービスを利用している場合を指します。EJBクライアントアプリケーションからJ2EEサーバ内のJ2EEアプリケーションをルックアップする場合を含みます。

注※3

自動的にバインドされるEJBのリファレンスだけルックアップできます（アプリケーションサーバ独自の仕様）。

2.4.2　自動的にバインドされるオブジェクト

アプリケーションサーバでは，標準アプリケーション名，標準モジュール名およびEJBのリファレンスが，Java EEで定義されている名称に自動的にバインドされます。なお，アプリケーションサーバでは標準アプリケーション名，および標準モジュール名を次のように定義しています。

標準アプリケーション名

Java EE 6で導入されたJ2EEアプリケーションを一意に識別する名称です。アプリケーションサーバでは，application.xmlの<display-name>に指定する「J2EEアプリケーション名」または「アプリケーション表示名」とは区別して，「標準アプリケーション名」と呼びます。

標準モジュール名

Java EE 6で導入されたJ2EEアプリケーション内の各種モジュール（EJB-JAR，Webアプリケーションまたはリソースアダプタ）を一意に識別する名称です。アプリケーションサーバでは，EJB-JARファイルやWARファイルのファイル名を指す「モジュール名」と区別して，「標準モジュール名」と呼びます。

自動的にバインドされるオブジェクトと名称を次の表に示します。

表2‒10　自動的にバインドされるオブジェクトと名称

バインドされるオブジェクト

バインドされる名称

標準アプリケーション名（java.lang.String型）

java:app/AppName※1

標準モジュール名（java.lang.String型）

java:module/ModuleName※1

EJBのリファレンス※2

Session Beanのホームオブジェクト

java:global[/<標準アプリケーション名>]/<標準モジュール名>/<Enterprise Bean名>[!<完全修飾クラス名>]

java:app/<標準モジュール名>/<Enterprise Bean名>[!<完全修飾クラス名>]

java:module/<Enterprise Bean名>[!<完全修飾クラス名>]

Session Beanのビジネスインタフェース

java:global[/<標準アプリケーション名>]/<標準モジュール名>/<Enterprise Bean名>[!<完全修飾クラス名>]

java:app/<標準モジュール名>/<Enterprise Bean名>[!<完全修飾クラス名>]

java:module/<Enterprise Bean名>[!<完全修飾クラス名>]

注※1

EJB-JARまたはWebアプリケーションからの場合だけルックアップできます。

注※2

EJB 3.1仕様では，一つのEnterprise Beanに対してEJBのリファレンス（ホームオブジェクトやビジネスインタフェース）が一つの場合に，完全修飾クラス名を省略したクラス名省略書式でルックアップできます。

さらに，アプリケーションサーバでは，リファレンスが複数ある場合でも，次の優先順位で最初に登録されたものは，クラス名省略書式でルックアップできます。

1.　リモートホームオブジェクト

2.　ローカルホームオブジェクト

3.　ローカルビジネスインタフェース（ビジネスインタフェース省略時を含む）

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

ただし，リファレンスが複数ある場合のクラス名省略書式に関する仕様はJava EEで規定されていないため，クラス名省略書式でのルックアップは推奨しません。

HITACHI_EJBから始まる名称でルックアップできるオブジェクトがアプリケーション内にある場合は，Portable Global JNDI名でもルックアップできます。

なお，アプリケーションの開始時，Portable Global JNDI名は，バインドされたEJBリファレンスごとにメッセージKDJE47701-Iに出力されます。Enterprise Beanのクラス名を省略した書式やアプリケーション名を省略した書式が有効な場合は，ルックアップできるすべての書式がコンマと空白区切り（, ）で列挙されます。

2.4.3　Portable Global JNDI名の命名規則

Portable Global JNDI名には標準アプリケーション名，標準モジュール名，およびEnterprise Bean名が含まれています。これらの名前はJava EEで命名規則や使用できる文字が定義されています。

ここでは，Portable Global JNDI名に使用される標準アプリケーション名，標準モジュール名，Enterprise Bean名の命名規則，および使用できる文字について説明します。

(1)　標準アプリケーション名の命名規則

標準アプリケーション名は次の規則で設定されます。

表2‒11　標準アプリケーション名の命名規則

アプリケーションの前提条件

標準アプリケーション名

J2EEアプリケーション（EARファイル）

application.xmlがある

<application-name>タグがある

値がある

<application-name>タグの値※1

値が空文字※2

デフォルトの標準アプリケーション名※3

<application-name>タグがない

−

application.xmlがない

−

−

WARアプリケーション

（WARファイル）

cjimportwarコマンドの-nameオプションに指定がある

cjimportwarコマンドの-nameオプションの値※1

cjimportwarコマンドの-nameオプションに指定がない

デフォルトの標準アプリケーション名※3

（凡例）

−：該当なし。

注※1

値の前後の空白文字（半角スペース，タブ，改行）は除かれます。単語の間にある空白文字は除かれません。

注※2

長さが0の文字列を指します。空白文字だけで構成された値も空文字と判断されます。

注※3

デフォルトの標準アプリケーション名は，J2EEアプリケーションの形式によって異なります。デフォルトの標準アプリケーション名の命名規則を次の表に示します。

表2‒12　デフォルトの標準アプリケーション名の命名規則

アプリケーションの前提条件

デフォルトの標準アプリケーション名

J2EEアプリケーション

（EARファイル）

アーカイブ形式

EARファイルのファイル名から拡張子を除いた文字列。

ただし，ピリオド「.」がファイル名の先頭にしかない場合は拡張子を除かない。※

展開ディレクトリ形式

application.xmlがある場合

J2EEアプリケーション名（<display-name>タグの値）。

application.xmlがない場合

アプリケーションディレクトリのディレクトリ名。

WARアプリケーション

（WARファイル）

アーカイブ形式

WARファイルのファイル名から拡張子を除いた文字列。

ただし，ピリオド「.」がファイル名の先頭にしかない場合は拡張子を除かない。

展開ディレクトリ形式

WARディレクトリのディレクトリ名。

注※

運用管理ポータルからインポートする場合は，application.xmlの<application-name>タグの値を指定してください。

指定がない場合，Portable Global JNDI名でのルックアップができません。

標準アプリケーション名に指定できる値を次に示します。

<application-name>タグで指定する標準アプリケーション名

標準アプリケーション名は，半角英数字（0〜9，A〜Z，a〜z），および次の特殊文字の場合に登録されます。

スペース（ ），エクスクラメーションマーク（!），ダブルクォーテーション（"），シャープ（#），ドル記号（$），パーセント（%），アンパサンド（&），シングルクォーテーション（'），バーレン（(）（)），アスタリスク（*），プラス（+），コンマ（,），ハイフン（-），ピリオド（.），コロン（:），セミコロン（;），レスザン（<），イコール（=），グレーターザン（>），クエスチョン（?），単価記号（@），ブラケット（[）（]），円マーク（¥），キャレット（^），アンダースコア（_），バッククォート（`），ブレイス（{）（}），ストローク（|），およびチルダ（~）

ただし，次の名称は登録されません。

先頭または末尾がピリオド（.）の名称

ピリオド（.）だけの名称

文字列長が256文字以上の名称

「env」と一致する名称

<display-name>タグで指定する標準アプリケーション名

標準アプリケーション名（<display-name>タグの値）は，半角英数字（0〜9，A〜Z，a〜z），プラス（+），ハイフン（-），ピリオド（.），アンダースコア（_），およびキャレット（^）の場合に登録されます。

ただし，次の名称は登録されません。

先頭または末尾がピリオド（.）の名称

ピリオド（.）だけの名称

文字列長が1文字未満の名称

文字列長が256文字以上の名称

「env」と一致する名称

登録されない名称の例

foo/bar，.foo，.foobar.，env

標準アプリケーション名が登録できない名称の場合，アプリケーション開始時にKDJE47710-Wが出力され，アプリケーションの開始処理は続行されます。ただし，そのアプリケーションに含まれるすべてのオブジェクトに対してPortable Global JNDI名の登録はされないため，Portable Global JNDI名でのルックアップはできません。Portable Global JNDI名でのルックアップをする場合は，必要に応じて，DD，EARファイルのファイル名，またはアプリケーションディレクトリのディレクトリ名を命名規則に従って変更してください。

(2)　標準モジュール名の命名規則

標準モジュール名は次の規則で設定されます。

表2‒13　標準モジュール名の命名規則

モジュールの前提条件

標準モジュール名

EJB-JARモジュール（EJB-JARファイル）

ejb-jar.xml

がある

<module-name>タグがある

値がある

<module-name>タグの値※1

値が空文字※2

デフォルトの標準モジュール名※3

<module-name>タグがない

−

ejb-jar.xml

がない

−

−

Webモジュール（WARファイル）

web.xmlがある

<module-name>タグがある

値がある

<module-name>タグの値※1

値が空文字※2

デフォルトの標準モジュール名※3

<module-name>タグがない

−

web.xmlがない

−

−

リソースアダプタモジュール（RARファイル）

−

デフォルトの標準モジュール名※3

（凡例）

−：該当なし。

注※1

値の前後の空白文字（半角スペース，タブ，改行）は除かれます。単語の間にある空白文字は除かれません。

注※2

長さが0の文字列を指します。空白文字だけで構成された値も空文字と判断されます。

注※3

デフォルトの標準モジュール名は，モジュールおよびJ2EEアプリケーションの形式によって異なります。デフォルトの標準モジュール名の命名規則を次の表に示します。

表2‒14　デフォルトの標準モジュール名の命名規則

モジュール

J2EEアプリケーションの形式

デフォルトの標準モジュール名

EJB-JARモジュール（EJB-JARファイル）

アーカイブ形式

アプリケーションパッケージのルートディレクトリからEJB-JARファイルまでの相対パスから拡張子を除いた文字列。

ただし，ピリオド「.」がEJB-JARファイル名の先頭にしかない場合は拡張子を除かない。

パス区切り文字が「¥」の場合は「/」に変換する。

展開ディレクトリ形式

application.xmlがある場合

application.xmlの<module>/<ejb>タグで指定したパス。

application.xmlがない場合

アプリケーションディレクトリからEJB-JARディレクトリまでの相対パスから，末尾の「_jar」を除いた文字列。

パス区切り文字が「¥」の場合は「/」に変換する。

Webモジュール（WARファイル）

アーカイブ形式

アプリケーションパッケージのルートディレクトリからWARファイルまでの相対パスから，拡張子を除いた文字列。

ただし，ピリオド「.」がWARファイル名の先頭にしかない場合は拡張子を除かない。

パス区切り文字が「¥」の場合は「/」に変換する。

展開ディレクトリ形式

application.xmlがある場合

application.xmlの<module>/<web>/<web-uri>タグで指定したパス。

application.xmlがない場合

アプリケーションディレクトリからWARディレクトリまでの相対パスから，末尾の「_war」を除いた文字列。

パス区切り文字が（¥）の場合は（/）に変換する。

リソースアダプタモジュール

アーカイブ形式

アプリケーションパッケージのルートディレクトリからRARファイルまでの相対パスから，拡張子を除いた文字列。

ただし，ピリオド（.）がRARファイル名の先頭にしかない場合は拡張子を除かない。

パス区切り文字が（¥）の場合は（/）に変換する。

なお，標準モジュール名（<module-name>タグの値）は，半角英数字（0〜9，A〜Z，a〜z），および次の特殊文字の場合に登録されます。

スペース（ ），エクスクラメーションマーク（!），ダブルクォーテーション（"），シャープ（#），ドル記号（$），パーセント（%），アンパサンド（&），シングルクォーテーション（'），バーレン（(）（)），アスタリスク（*），プラス（+），コンマ（,），ハイフン（-），ピリオド（.），区切り文字としてのスラッシュ（/），コロン（:），セミコロン（;），レスザン（<），イコール（=），グレーターザン（>），クエスチョン（?），単価記号（@），ブラケット（[）（]），円マーク（¥），キャレット（^），アンダースコア（_），バッククォート（`），ブレイス（{）（}），ストローク（|），チルダ（~）

ただし，次の名称は登録されません。

先頭または末尾がスラッシュ（/）の名称

スラッシュ（/）だけの名称

スラッシュ（/）が連続する名称

先頭または末尾がピリオド（.）の名称

ピリオド（.）だけの名称

スラッシュ（/）とピリオド（.）が連続する名称

文字列長が256文字以上の名称

「env」と一致する名称

「env/」から始まる名称

「AppName」と一致する名称

「AppName/」から始まる名称

登録されない名称の例

/foo，/foobar/，/，foo//bar，bar.，.foobar.，foo/.bar，AppName，AppName/foo，env/foo/bar

標準モジュール名が登録できない名称の場合，アプリケーション開始時にモジュールごとにKDJE47711-Wが出力され，アプリケーションの開始処理は続行されます。ただし，そのモジュールに含まれるすべてのオブジェクトに対してPortable Global JNDI名での登録はされないため，Portable Global JNDI名でのルックアップはできません。Portable Global JNDI名でのルックアップをする場合は，必要に応じて，DD，アプリケーションのディレクトリ名などを命名規則に従って変更してください。

(3)　Enterprise Bean名の命名規則

Enterprise Bean名には，半角英数字（0〜9，A〜Z，a〜z），および次の特殊文字の場合に登録されます。

スペース（ ），エクスクラメーションマーク（!），ダブルクォーテーション（"），シャープ（#），ドル記号（$），パーセント（%），アンパサンド（&），シングルクォーテーション（'），バーレン（(）（)），アスタリスク（*），プラス（+），コンマ（,），ハイフン（-），ピリオド（.），コロン（:），セミコロン（;），レスザン（<），イコール（=），グレーターザン（>），クエスチョン（?），単価記号（@），ブラケット（[）（]），円マーク（¥），キャレット（^），アンダースコア（_），バッククォート（`），ブレイス（{）（}），ストローク（|），チルダ（~）

ただし，次の名称は登録されません。

先頭または末尾がピリオド（.）の名称

ピリオド（.）だけの名称

文字列長が256文字以上の名称

「ModuleName」と一致する名称

「env」と一致する名称

登録されない名称の例

.foo，.foobar.，ModuleName，env

Enterprise Bean名が登録できない名称の場合，アプリケーション開始時にEnterprise BeanごとにKDJE47712-Wが出力され，アプリケーションの開始処理は続行されます。ただし，そのEnterprise Beanに含まれるすべてのオブジェクトに対してPortable Global JNDI名での登録はされません。なお，Enterprise Bean名が登録できない名称の場合，Portable Global JNDI名でのルックアップはできませんが，それ以外のアプリケーションの機能は従来どおり動作します。

また，指定できる文字列長については，Enterprise Beanのインタフェース（ホームインタフェースまたはビジネスインタフェース）ごとにもチェックされます。例えば，次の文字列長が256文字以上の場合，インタフェースごとにKDJE47713-Wが出力され，そのインタフェース名を指定した形式のPortable Global JNDI名での登録はされません。

Enterprise Bean名の長さ+インタフェースのクラス名※の長さ+1

注※　パッケージ名を含む完全修飾クラス名

なお，EJB 3.1では，インタフェースが省略されている場合は，インタフェースのクラス名の代わりにEnterprise Beanのクラス名が適用されます。

(4)　標準アプリケーション名または標準モジュール名が重複した場合の動作

アプリケーションサーバでは，アプリケーション開始時に，すでに同じ標準アプリケーション名が名前空間に登録されていた場合，KDJE47720-Wが出力され，名前空間に登録されません。これと同様に，同一アプリケーション内ですでに同じ標準モジュール名が名前空間に登録されていた場合，次のメッセージが出力され，名前空間に登録されません。ただし，アプリケーションの開始処理は続行されます。

EJB-JAR場合：KDJE47721-W

Webアプリケーションの場合：KDJE47722-W

リソースアダプタの場合：KDJE47723-W

なお，アプリケーションサーバでは，次の順番でモジュールが登録されます。

リソースアダプタ

EJB-JAR

Webアプリケーション

登録済みの標準アプリケーション名や標準モジュール名と完全に一致していなくても，スラッシュ(/)で区切られた階層の単位で，登録済みのオブジェクトと名称が一致した場合は，重複していると判断されることがあります。次に例を示します。

例1

次の順番でアプリケーションを開始した場合，標準アプリケーション名が重複していると判断されます。

標準アプリケーション名が「foo/bar」のアプリケーションを開始

標準アプリケーション名が「foo」のアプリケーションを開始

例2

次の順番でアプリケーションを開始した場合，標準アプリケーション名が重複していると判断されます。

標準アプリケーション名が「foo」で，標準モジュール名が「bar」のアプリケーションを開始

標準アプリケーション名が「foo/bar」のアプリケーションを開始

2.4.4　Portable Global JNDI名の登録抑止

09-00以降のアプリケーションサーバで，Portable Global JNDI名でのルックアップをしない場合，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次の指定をします。この指定をした場合，アプリケーションの開始時にPortable Global JNDI名は登録されません。また，Portable Global JNDI名の登録に関する情報や警告も表示されません。

ejbserver.jndi.global.enabledパラメタにfalseを指定する。

2.4.5　CTMを使用する場合のPortable Global JNDI名でのルックアップ

CTMを使用したシステム構成の場合，EJBクライアントアプリケーションからCTMデーモンに接続されているCORBAネーミングサービスに対してルックアップすることで，EJBリモートホームオブジェクトを取得できます。EJBをルックアップする際には，HITACHI_EJBから始まる名称，Portable Global JNDI名およびユーザ指定名前空間機能を使用して付与した別名が使用できます。

CTMを使用する場合のEJBのルックアップでは，EJBに別名が指定されているときは別名が使用されます。別名が指定されていないときは，デフォルトのルックアップ名が使用されます。デフォルトのルックアップ名は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のejbserver.ctm.useGlobalJNDIパラメタで切り替えられます。

CTMを使用する場合のEJBのルックアップに使用される名称を次の表に示します。

表2‒15　CTMを使用する場合のEJBのルックアップに使用される名称

前提条件

ルックアップ名称

EJBの別名指定

ejbserver.jndi.global.enabledパラメタの値※1

ejbserver.ctm.useGlobalJNDIパラメタの値※2

Portable Global JNDI名の登録可否※3

あり

−

−

−

EJBの別名

なし

true（デフォルト）

true

登録できる

Portable Global JNDI名

登録できない

HITACHI_EJBから始まる名称

false（デフォルト）

−

false

−

−

（凡例）

−：該当なし

注※1

簡易構築定義ファイルのejbserver.jndi.global.enabledパラメタの指定値を示します。trueの場合，アプリケーションの開始時にPortable Global JNDI名を登録します。falseの場合，登録しません。

注※2

簡易構築定義ファイルのejbserver.ctm.useGlobalJNDIパラメタの指定値を示します。trueの場合，CTMを使用するシステム構成でのEJBのルックアップにPortable Global JNDI名を使用します。falseの場合，HITACHI_EJBから始まる名称を使用します。

注※3

EJBをPortable Global JNDI名で登録できるかどうかを示します。標準アプリケーション名や標準モジュール名が重複している場合や，登録できない文字列の場合は，Portable Global JNDI名を登録できません。

2.4.6　リソース参照の名称

Java EE 6以降，リソース参照の名称には，java:comp/envを使用した名称のほかにJNDI完全修飾名を指定できます。リソース参照の名称にJNDI完全修飾名を指定することで，一つのアプリケーション内のすべてのコンポーネント（Enterprise Bean，サーブレット，JSP，フィルタ，およびリソースアダプタ）で共有されるリソース参照や，EJB-JARまたはWebアプリケーション内のすべてのコンポーネントで共有されるリソース参照を定義できます。

また，DD（web.xml）の<lookup-name>タグ，または@Resourceアノテーションや@EJBアノテーションのlookup属性を指定することで，ほかのリソース参照をJNDI完全修飾名でルックアップできます。

ここでは，リソース参照の名称へのJNDI完全修飾名の指定，およびほかのリソース参照のルックアップについて説明します。

注意事項

ejbserver.jndi.global.enabledパラメタにfalseを指定してPortable Global JNDI名の登録抑止をしている場合は，リソース参照の名称に「java:」で始まる名称を指定しないでください。

(1)　リソース参照の名称へのJNDI完全修飾名の指定

アプリケーションサーバでは，Portable Global JNDI名の登録が有効な場合に，リソース参照の名称に「java:」から始まる名称を指定すると，JNDI完全修飾名が指定されたものと判断され，指定した名称がそのままJNDI名として扱われます。

Portable Global JNDI名の登録が無効な場合，または「java:」以外の文字列から始まる名称を指定した場合は，java:comp/envから始まる名称またはリソースアダプタの別名として扱われます。

DD（web.xml）で，リソース参照の名称にJNDI完全修飾名を指定できるリソース参照の種別を次の表に示します。

表2‒16　JNDI完全修飾名を指定できるリソース参照の種別（DD）

項番

リソース参照の種別

リソース参照の名称を指定するタグ

1

環境エントリ

<env-entry> - <env-entry-name>

2

リソース参照

<resource-ref> - <res-ref-name>

3

リソース環境変数参照

<resource-env-ref> - <resource-env-ref-name>

4

リモートEJB参照

<ejb-ref> - <ejb-ref-name>

5

ローカルEJB参照

<ejb-local-ref> - <ejb-local-ref-name>

6

永続化コンテキストの参照

<persistence-context-ref> - <persistence-context-ref-name>

7

永続化ユニットの参照

<persistence-unit-ref> - <persistence-unit-ref-name>

また，name属性にJNDI完全修飾名を指定できるリソース参照のアノテーションを次の表に示します。

表2‒17　JNDI完全修飾名を指定できるリソース参照の種別（アノテーション）

項番

リソース参照の種別

リソース参照の名称を指定するアノテーション

1

環境エントリ

@Resourceのname属性

2

リソース参照

3

リソース環境変数参照

4

リモートEJB参照

@EJBのname属性

5

ローカルEJB参照

6

永続化コンテキストの参照

@PersistenceContextのname属性

7

永続化ユニットの参照

@PersistenceUnitのname属性

Portable Global JNDI名の登録が有効な場合に，リソース参照の名称にJNDI完全修飾名を指定すると，指定する名前空間と，標準アプリケーション名や標準モジュール名が命名規則に反していないかの組み合わせによっては，アプリケーション開始時にKDJE47730-Eが出力され，アプリケーションの開始に失敗することがあります。

指定するJNDI完全修飾名の名前空間とアプリケーションの開始可否を次の表に示します。なお，「java:」から始まるが，指定できる名前空間ではない名称が指定された場合も，アプリケーション開始時にKDJE47730-Eが出力され，アプリケーションの開始に失敗します。

表2‒18　指定するJNDI完全修飾名の名前空間とアプリケーションの開始可否

前提条件

指定する名前空間

リソース参照を定義したアプリケーションの標準アプリケーション名

リソース参照を定義したEJB-JARまたはWebアプリケーションの標準モジュール名

java:comp

java:module

java:app

java:global

不正値または重複

−

○

×

×

○

正常

不正値または重複

○

×

○

○

正常

○

○

○

○

（凡例）

○：アプリケーションを開始できる。

×：アプリケーションを開始できない。

−：該当なし。

アプリケーションサーバでは，リソース参照の名称をJNDI完全修飾名で指定する場合，サブコンテキストの名称に制限はありません。ただし，すでに同名でコンテキストまたはオブジェクトが登録済みの場合は，アプリケーション開始時にKDJE47721-Wが出力され，アプリケーションの開始に失敗します。

なお，リソース参照の名称にPortable Global JNDI名を定義した場合でも，そのリソース参照を別プロセスのJ2EEサーバやEJBクライアントアプリケーションからルックアップできません。Portable Global JNDI名が定義された別プロセス上のリソース参照をルックアップした場合，NameNotFoundException例外が発生します。

(2)　ほかのリソース参照のルックアップ

アプリケーションサーバでは，java:comp/envから始まる名称で登録されたリソース参照に加え，web.xmlの<lookup-name>タグ，または@Resourceアノテーションや@EJBアノテーションのlookup属性を指定することで，EJB-JARまたはWebアプリケーション内で共有されるリソースやアプリケーション内で共有されるリソースについて，DIやリソース参照を介してルックアップできます。

例えば，Webアプリケーション内のweb.xmlで「java:app」名前空間に定義した環境エントリは，別のモジュールであるEJB-JAR内のEJBからもDIできます。

リソース参照からルックアップできる名称には，リソースアダプタの名称，EJBの別名が使用できます。

リソース参照からルックアップできる名称を次の表に示します。

表2‒19　リソース参照からルックアップできる名称

ルックアップ元のリソース参照

ルックアップできる名称

アノテーション

DD（web.xml）

@Resourceのlookup属性※1

<env-entry> - <lookup-name>※2

環境エントリの名称（JNDI完全修飾名）

<resource-ref> - <lookup-name>※1

リソース参照の名称（JNDI完全修飾名）

リソースアダプタの別名

<resource-env-ref> - <lookup-name>※1

リソース環境変数参照の名称（JNDI完全修飾名）

@EJBのlookup属性

<ejb-ref> - <lookup-name>

EJBリモート参照の名称（JNDI完全修飾名）

EJBリモートオブジェクトのPortable Global JNDI名

EJBリモートオブジェクトの別名

<ejb-local-ref> - <lookup-name>

ローカルEJB参照の名称（JNDI完全修飾名）

ローカルEJBオブジェクトのPortable Global JNDI名

ローカルEJBオブジェクトの別名

注※1

Java EEの仕様に従い，注入先のデータ型またはweb.xmlの<resource-ref-type>タグや<resource-env-ref-type>タグに設定されたデータ型が次のどれかの場合，@Resourceアノテーションのlookup属性または<lookup-name>タグの設定は無視されます（未設定時と同じ動作になります）。

org.omg.CORBA.ORB

org.omg.CORBA_2_3.ORB

javax.ejb.EJBContext

javax.ejb.SessionContext

javax.ejb.TimerService

javax.transaction.UserTransaction

javax.validation.Validator

javax.validation.ValidatorFactory

javax.enterprise.inject.spi.BeanManager

注※2

Java EEの仕様に従い，<env-entry-value>タグに値が設定されている場合，@Resourceアノテーションのlookup属性または<lookup-name>の設定は無視されます（未設定時と同じ動作となります）。

なお，属性ファイルの<linked-to>タグ，<linked-queue>タグ，<linked-adminobject>タグや，@ResourceアノテーションのmappedName属性が指定されている場合は，@Resourceアノテーションのlookup属性およびweb.xmlの<lookup-name>タグの設定は無視されます。

注意事項

ルックアップ先のリソース参照をルックアップ元自身にしたり，循環参照にしたりしないでください。循環参照となるようなリソース参照が定義された場合，アプリケーションからルックアップしたとき，またはDIが実行されたときに，無限再帰呼び出しとなりjava.lang.StackOverflowError例外が発生し，アプリケーションからの応答が返らなくなります。

循環参照となる例を次に示します。

<env-entry>

<env-entry-name>java:app/env/sample1</env-entry>

<lookup-name>java:app/env/sample2</env-entry>

</env-entry>

<env-entry>

<env-entry-name>java:app/env/sample2</env-entry>

<lookup-name>java:app/env/sample1</env-entry>

</env-entry>

この定義に対して，アプリケーションから「java:app/env/sample1」をルックアップすると，無限再帰呼び出しとなり，java.lang.StackOverflowError例外が発生します。

2.4.7　アノテーションでのPortable Global JNDI名の指定

アプリケーションサーバでは，Java EEの仕様に従い@EJBアノテーションのlookup属性およびmapped属性に，Portable Global JNDI名を指定できます。これによって，直接EJBのビジネスインタフェースのリファレンス，またはホームオブジェクトのリファレンスを注入することができます。

@EJBアノテーションに次の条件に一致する指定をした場合，注入するSession Beanの種別に関係なく，ビジネスメソッドの呼び出し，またはタイムアウトコールバックメソッドの呼び出しのたびにDIが実施されます。

beanName属性に<module-name>/<bean-name>の形式で指定した場合

lookup属性にPortable Global JNDI名を指定した場合

mappedName属性にPortable Global JNDI名を指定した場合

2.4.8　DDでの定義

Portable Global JNDI名でのルックアップをする場合に必要なDDの定義について説明します。

Portable Global JNDI名でのルックアップの定義は，application.xml，ejb-jar.xml，およびweb.xmlに指定します。

Portable Global JNDI名でのルックアップに関するDDでの定義について次の表に示します。

表2‒20　DDでのPortable Global JNDI名でのルックアップの定義

DDの種類

タグ名

設定内容

application.xml

<application> - <application-name>

標準アプリケーション名を指定します。

ejb-jar.xml

<ejb-jar> - <module-name>

標準モジュール名を指定します。

web.xml

<web-app> - <module-name>

標準モジュール名を指定します。複数回指定された場合は，最初に指定されたタグの指定値が適用され，2回目以降の値は無視されます。

<web-app> - <env-entry> - <lookup-name>

ほかのenv-entryを参照するPortable Global JNDI名を指定します。

<web-app> - <resource-ref> - <lookup-name>

ほかのresource-refを参照するPortable Global JNDI名を指定します。

<web-app> - <resource-env-ref> - <lookup-name>

ほかのresource-env-refを参照するPortable Global JNDI名を指定します。

<web-app> - <ejb-ref> - <lookup-name>

ほかのejb-refを参照するPortable Global JNDI名，またはリモートビジネスインタフェースがバインドされたPortable Global JNDI名を指定します。

<web-app> - <ejb-local-ref> - <lookup-name>

ほかのejb-local-refを参照するPortable Global JNDI名，またはローカルビジネスインタフェースがバインドされたPortable Global JNDI名を指定します。

注意事項

cosminexus.xmlやアプリケーション統合属性ファイルにある<module-name>タグおよび<lookup-name>タグと，上記のejb-jar.xmlまたはweb.xmlで指定する<module-name>タグおよび<lookup-name>タグは指定する内容が異なります。

2.4.9　実行環境での設定

Portable Global JNDI名でルックアップをする場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Portable Global JNDI名でのルックアップの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの設定を次の表に示します。

表2‒21　簡易構築定義ファイルでのPortable Global JNDI名でルックアップをするための定義

項目

指定するパラメタ

設定内容

Portable Global JNDI名の登録

ejbserver.jndi.global.enabled

アプリケーションの開始時に，ネーミングサービスに対してPortable Global JNDI名を登録するかどうかを指定します。

CTMを使用する場合のデフォルトのルックアップ名

ejbserver.ctm.useGlobalJNDI

CTMを使用する場合に，EJBに別名を指定していないときに使用する，デフォルトのルックアップ名を指定します。

参考

Portable Global JNDI名を登録する設定にした場合，アプリケーションの開始時に登録された名称の情報や標準アプリケーション名の重複などの警告がコンソールに表示されます。

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

2.5　HITACHI_EJBから始まる名称でのルックアップ

ここでは，HITACHI_EJBから始まる名称について説明します。J2EEアプリケーションをデプロイすると，EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスのJNDIの名前に，HITACHI_EJBから始まる名称が自動的にバインドされます。ルックアップ時には，バインドされた名前を使用します。

なお，JNDI名前空間のマッピングの仕組みと使い方については，「2.3.2　JNDI名前空間のマッピングとルックアップ」を参照してください。

注意事項

HITACHI_EJBから始まる名称は，ローカルインタフェース使用時にはバインドされません。ほかの方法でルックアップしてください。

2.5.1　EJBホームオブジェクトリファレンスが自動的にバインドされる名称

J2EEアプリケーションを開始（デプロイ）したとき，Enterprise BeanのEJBホームオブジェクトリファレンスは，次に示す名称で，JNDIの名前にバインドされます。

HITACHI_EJB/SERVERS/<サーバ名>/EJB/<J2EEアプリケーション名>/<Enterprise Bean名>

<サーバ名>

J2EEサーバのサーバ名称

<J2EEアプリケーション名>

J2EEアプリケーションのルックアップ名称

<Enterprise Bean名>

Enterprise Beanのルックアップ名称

J2EEアプリケーション間のEnterprise Beanの呼び出しや，EJBクライアントアプリケーションからのEnterprise Beanの呼び出しのとき，クライアントはバインドされたJNDIの名前でEJBホームオブジェクトリファレンスをルックアップします。

次に示す図では，下記の条件でJ2EEアプリケーションを開始したとき，"CartHome"インタフェースを実装したEJBホームオブジェクトが生成され，そのリファレンスがJNDIの名前"HITACHI_EJB/SERVERS/MyServer/EJB/CartApp/CartEB"にバインドされることを示しています。

条件

Enterprise Bean："CartBean"

リモートインタフェース名："Cart"

ホームインタフェース："CartHome"

サーバ名："MyServer"

J2EEアプリケーションのルックアップ名："CartApp"

Enterprise Beanのルックアップ名："CartEB"

図2‒5　EJBホームオブジェクトリファレンスのJNDI名前空間へのバインド

次に，HITACHI_EJBから始まる名称を利用してEJBホームオブジェクトのリファレンスをルックアップする場合のルックアップとオブジェクトの取得の流れを示します。

図2‒6　HITACHI_EJBから始まる名称を利用したルックアップとオブジェクトの取得の流れ

2.5.2　ビジネスインタフェースのリファレンスが自動的にバインドされる名称

J2EEアプリケーションを開始（デプロイ）したとき，ビジネスインタフェースのリファレンスは，次に示す名称でJNDIの名前にバインドされます。

HITACHI_EJB/SERVERS/<サーバ名>/EJBBI/<J2EEアプリケーション名>/<Enterprise Bean名>

<サーバ名>

J2EEサーバのサーバ名称

<J2EEアプリケーション名>

J2EEアプリケーションのルックアップ名称

<Enterprise Bean名>

Enterprise Beanのルックアップ名称

J2EEアプリケーション間のEnterprise Beanの呼び出しや，EJBクライアントアプリケーションからのEnterprise Beanの呼び出しのとき，クライアントはバインドされたJNDIの名前でビジネスインタフェースのリファレンスをルックアップします。

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

Enterprise BeanまたはJ2EEリソースに対して，ユーザが別の名称を付けてJNDI名前空間に登録する機能を，ユーザ指定名前空間機能といいます。この機能によって，Enterprise BeanまたはJ2EEリソースを，設定した任意の名称でルックアップできるようになります。

なお，別名を付与するためには，サーバ管理コマンドの動作設定のカスタマイズが必要です。設定方法については，「2.6.7　実行環境での設定」を参照してください。

注意事項

Java EEの仕様では，java:comp/envを利用した名称でのルックアップが推奨されています。

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

表2‒22　この節の構成（ユーザ指定名前空間機能）

分類

タイトル

参照先

解説

別名を付けられる対象

2.6.1

別名の付与規則

2.6.2

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

2.6.3

クライアントからの検索

2.6.4

実装

Enterprise Beanの別名の設定

2.6.5

J2EEリソースの別名の設定

2.6.6

設定

実行環境での設定

2.6.7

注意事項

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

2.6.8

注　「運用」について，この機能固有の説明はありません。

2.6.1　別名を付けられる対象

ここでは，別名を付けられる対象について説明します。

別名は，Enterprise BeanまたはJ2EEリソースに付けられます。

(1)　Enterprise Beanに対する別名

別名を付けられるのは，次のインタフェースを持つEnterprise Beanです。

リモートホームインタフェース

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

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

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

なお，以降，リモートホームインタフェースとリモートビジネスインタフェースをあわせて，リモートインタフェースといいます。また，ローカルホームインタフェースとローカルビジネスインタフェースをあわせてローカルインタフェースといいます。

参考

リモートインタフェースとローカルインタフェースの別名は，異なる属性として設定します。詳細は，「2.6.5　Enterprise Beanの別名の設定」を参照してください。

(2)　J2EEリソースに対する別名

別名を付与できるのは，次の表に示すJ2EEリソースです。

表2‒23　別名を付与できるJ2EEリソース

J2EEリソースの種別

別名付与の可否

リソースアダプタ

DB Connector

○※1

DB Connector for Reliable Messaging

○

Reliable Messaging

○※2

TP1 Connector

○

TP1/Message Queue - Access

○※2

そのほかのリソースアダプタ

○※3

メールコンフィグレーション

○

JavaBeansリソース

○

（凡例）　○：別名を付けられる

注※1　クラスタコネクションプール機能（互換機能）を使用する場合，メンバリソースアダプタには別名を付けられません。

注※2　属性ファイルの<resource-env-ref>に指定するjavax.jms.ConnectionFactoryオブジェクトに別名を付けられます。<resource-env-ref>に指定するjavax.jms.Destinationオブジェクトには別名を付けられません。

注※3　Connector 1.5仕様に準拠するリソースアダプタの場合，管理対象オブジェクトに別名は付与できません。

2.6.2　別名の付与規則

ここでは，Enterprise BeanおよびJ2EEリソースに別名を設定する場合の付与規則について説明します。

(1)　指定できる名称

別名に指定できる文字，および指定する場合の制約について説明します。

(a)　別名に指定できる文字

別名には，次の文字を使用した名称を指定できます。

英数字（A〜Z，a〜z，0〜9）

アンダースコア（_）

スラッシュ（/）

ピリオド（.）

ハイフン（-）

ただし，スラッシュは，パスの区切り文字として使用する場合だけ，名前に使用できます。

(b)　別名を指定するときの制約

次に示す名前は，別名として指定できません。指定した場合，J2EEアプリケーションまたはJ2EEリソースを開始できません。

名前の先頭または名前の末尾に，スラッシュ（/）またはピリオド（.）を指定した名前。

スラッシュ（/）だけ，またはピリオド（.）だけの名前。

スラッシュ（/）が連続している名前。

スラッシュ（/）とピリオド（.）が連続している名前。

「HITACHI_EJB」で始まる名前（大文字・小文字を区別する）。

文字列長が255バイトよりも長い名前。

このほか，J2EEリソースの場合，同じ名称が指定されたときには，あとから指定されている定義が有効になります。

(2)　別名の重複

Enterprise BeanおよびJ2EEリソースに別名を付ける場合の別名の重複可否を次の表に示します。

表2‒24　Enterprise BeanおよびJ2EEリソースの別名の重複可否

別名を付ける対象

リモートインタフェースを持つEnterprise Bean

ローカルインタフェースを持つEnterprise Bean

J2EEアプリケーションに含まれるリソースアダプタ

J2EEリソース※1

リモートインタフェースを持つEnterprise Bean

×

○※2

×

×

ローカルインタフェースを持つEnterprise Bean

○※2

△

△

×

J2EEアプリケーションに含まれるリソースアダプタ

×

△

△

×

J2EEリソース※1

×

×

×

×

（凡例）

○：重複できる

△：J2EEアプリケーションが異なる場合は重複できる

×：重複できない

注※1　J2EEアプリケーションに含まれるリソースアダプタを除きます。

注※2　ローカル呼び出し最適化機能を使用するかどうかに関係なく重複できます。

なお，重複できない組み合わせの場合，名称が完全に一致していなくても指定できないことがあります。

例を使用して説明します。

例

ネーミング管理機能では，CORBAネーミングサービスに登録されるオブジェクトを名前で管理しています。オブジェクトに付与された名前は「/」を階層構造の区切りとして解析し，ツリー構造で管理されます。ツリーのなかで，子ノードを持つノードでは，そのノードの下に新しくオブジェクトを登録できます。

次の図の，ノードA，B，C，Fは子ノードを持つノードです。このため，これらのノードの下には新しくオブジェクトを登録できます。

図2‒7　名称が完全に一致していなくても指定できない例

この状態で，別名「A/B/D」がすでに使用されている場合は，別名「A/B/I」を指定できます。

しかし，D，E，G，Hのようなノードには，新しくオブジェクトを登録することはできません。このため，別名「A/B/D/I」を指定することはできません。

重複できない別名を指定した場合，別名を指定した対象ごとに，次のタイミングでエラーが発生します。

Enterprise Beanの場合は，J2EEアプリケーションの開始に失敗します。

メールコンフィグレーション以外のJ2EEリソースの場合は，リソースの開始に失敗します。

メールコンフィグレーションの場合は，属性設定時にエラーが発生します。

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

ここでは，Enterprise BeanまたはJ2EEリソースに対する別名の設定方法，別名が登録されるタイミング，および別名が削除されるタイミングについて説明します。

(1)　Enterprise Beanの別名が登録または削除されるタイミング

Enterprise Beanのオブジェクトに指定した別名が名前空間に登録されるのは，J2EEアプリケーションを開始した時，またはJ2EEサーバを起動した時です。

Enterprise Beanのオブジェクトに指定した別名が名前空間から削除されるのは，J2EEアプリケーションを停止した時，またはJ2EEサーバを停止した時です。

参考

ログレベルを「Warning」にしている場合，別名が登録または削除されたことをメッセージログで確認できます。

別名登録時：KDJE47605-Iが出力されます。

別名削除時：KDJE47606-Iが出力されます。

ただし，デフォルトのログレベルの設定では，これらのメッセージは出力されません。ログレベルの設定については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「3.3.6　J2EEサーバのログ取得の設定」を参照してください。

(2)　J2EEリソースの別名が登録または削除されるタイミング

J2EEリソースの別名が名前空間に登録されるのは，J2EEリソースを開始した時です。

J2EEリソースの別名が名前空間から削除されるのは，J2EEリソースを停止した時です。

参考

別名が登録または削除されたことは，メッセージログで確認できます。

別名登録時：KDJE47602-Iが出力されます。

別名削除時：KDJE47603-Iが出力されます。

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

ここでは，別名を付けたEnterprise BeanまたはJ2EEリソースをクライアントから検索する方法について説明します。

(1)　クライアントのソースと検索先オブジェクトの設定の関係

別名を付けたEnterprise BeanまたはJ2EEリソースを検索する場合のクライアントのソースでの指定方法と，検索先オブジェクトでの設定方法について説明します。

クライアントのソースには，ルックアップする名称として，検索先のオブジェクトの別名を指定します。検索先のオブジェクトには，アノテーションまたは属性ファイルを使用して，対応する別名を設定します。

検索元のソースの記述と，検索先オブジェクトの設定の関係を次の図に示します。

図2‒8　クライアントのソースと検索先オブジェクトの設定の関係

(2)　Enterprise Beanの検索

別名を使用してEnterprise Beanを検索する場合の，クライアントのコーディング例を次に示します。この例では，「MyCart」という別名を設定したEJBホームオブジェクトを検索します。

  ：
javax.naming.Context ctx = new javax.naming.InitialContext();
Object obj = ctx.lookup("MyCart");
SampleHome home =
(SampleHome)javax.rmi.PortableRemoteObject.narrow(obj, SampleHome.class);
Sample mybean = home.create();   //リモートオブジェクトの生成
String name = mybean.ping();     //ビジネスメソッドの実行
  ：

EJBホームオブジェクト取得後の操作は，別名を使用しないで取得したEJBホームオブジェクトに対する操作と同じです。

EJBホームオブジェクトのリファレンスをルックアップする場合の，ルックアップおよびオブジェクト取得の流れを次の図に示します。

図2‒9　EJBホームオブジェクトのリファレンスのルックアップとオブジェクト取得の流れ

(3)　J2EEリソースの検索

別名を使用してJ2EEリソースを検索する場合の，クライアントのコーディング例を次に示します。この例では，「jdbc/DBOpt」という別名を設定したJ2EEリソースを検索します。

Context initCtx = new InitialContext();
DataSource ds = (DataSource) initCtx.lookup("jdbc/DBOpt");

なお，J2EEリソースのオブジェクト取得後の操作は，別名を使用しないで取得したオブジェクトに対する操作と同じです。

注意事項

EJBクライアントアプリケーションからは，J2EEリソースを検索できません。検索した場合は，javax.naming.NameNotFoundException例外が発生します。

2.6.5　Enterprise Beanの別名の設定

ここでは，Enterprise Beanに別名を設定する方法について説明します。

Enterprise Beanの別名は，次の2種類の方法で設定できます。

cosminexus.xmlで設定する方法

アノテーションで指定する方法

それぞれの方法について説明します。

なお，この機能を使用する場合は，サーバ管理コマンドのusrconf.propertiesで別名を使用するかどうかを指定しておく必要があります。設定方法については，「2.6.7　実行環境での設定」を参照してください。

(1)　cosminexus.xmlで設定する方法

Enterprise Beanの別名を設定するには，cosminexus.xmlの<ejb-jar>タグ内に指定します。cosminexus.xmlでのEnterprise Beanの別名の設定について次の表に示します。

表2‒25　cosminexus.xmlでのEnterprise Beanの別名を設定

項目

指定するタグ

設定内容

リモートインタフェース

<session>−<optional-name>タグ

Session Beanのリモートインタフェースの別名を指定します。

<entity>−<optional-name>タグ

Entity Beanのリモートインタフェースの別名を指定します。

ローカルインタフェース

<session>−<local-optional-name>タグ

Session Beanのローカルインタフェースの別名を指定します。

<entity>−<local-optional-name>タグ

Entity Beanのローカルインタフェースの別名を指定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

参考

Enterprise Beanの別名は，アノテーションで設定することもできます。アノテーションによって別名が設定されている場合に，サーバ管理コマンドで異なる別名を設定すると，サーバ管理コマンドで設定した値が有効になります。

詳細は，「(3) サーバ管理コマンドとアノテーションの両方で別名を設定した場合」を参照してください。

(2)　アノテーションで指定する方法

@Stateless，@Stateful，または@SingletonのmappedName属性で指定します。

アノテーションで別名を指定する場合のコーディング例を次に示します。この例は，@StatelessのmappedName属性にStateless Session Beanの別名「MyFoo」を設定する場合の例です。

@Stateless(mappedName="MyFoo")
public class FooEB implements FooIF {
    ...
}

public interface FooIF {
...
}

@Stateless，@Stateful，または@SingletonのmappedName属性に指定した別名は，Session Bean属性ファイルの<hitachi-session-bean-property><mapped-name>タグに設定されます。

(3)　サーバ管理コマンドとアノテーションの両方で別名を設定した場合

@Stateless，@Stateful，または@SingletonのmappedName属性を指定して別名を指定している場合に，cosminexus.xmlで<optional-name>タグまたは<local-optional-name>タグに別名を設定したときには，<optional-name>タグおよび<local-optional-name>タグの指定が有効になります。

サーバ管理コマンドとアノテーションの両方で別名を指定した場合に有効になるタグについて，次の表に示します。

表2‒26　サーバ管理コマンドとアノテーションの両方で別名を指定した場合に有効になるタグ

別名の設定対象

@Stateless，@Stateful，@SingletonのmappedName属性だけを指定

<optional-name>タグ，<local-optional-name>タグだけを指定

@Stateless，@Stateful，@SingletonのmappedName属性および<optional-name>タグ，<local-optional-name>タグの両方を指定した場合

リモートインタフェース

<mapped-name>タグ※

<optional-name>タグ

<optional-name>タグ

ローカルインタフェース

<mapped-name>タグ※

<local-optional-name>タグ

<local-optional-name>タグ

注※　@Stateless，@Stateful，@SingletonのmappedName属性に指定した値が設定されるタグです。

2.6.6　J2EEリソースの別名の設定

ここでは，J2EEリソースに別名を設定する方法について説明します。

J2EEリソースの別名は，cosminexus.xmlで設定できます。

なお，この機能を使用する場合は，サーバ管理コマンドのusrconf.propertiesで別名を使用するかどうかを指定しておく必要があります。設定方法については，「2.6.7　実行環境での設定」を参照してください。

J2EEリソースの別名を設定するには，cosminexus.xmlの<rar>タグ内に指定します。cosminexus.xmlでのJ2EEリソースの別名の設定について次の表に示します。

表2‒27　cosminexus.xmlでのJ2EEリソースの別名を設定

項目

指定するタグ

設定内容

リソースアダプタ

<resource-external-property>−<optional-name>タグ

リソースアダプタの別名を指定します。

注　メールコンフィグレーションおよびJavaBeansリソースの別名は，属性ファイルを使用して設定します。設定方法については，「2.6.7　実行環境での設定」を参照してください。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

2.6.7　実行環境での設定

ユーザ指定名前空間機能を使用するためには，サーバ管理コマンドのカスタマイズ，J2EEアプリケーションの設定が必要です。

(1)　サーバ管理コマンドのカスタマイズ

サーバ管理コマンドの動作設定をカスタマイズできます。ここでは，サーバ管理コマンドが使用するユーザ指定名前空間機能の設定について説明します。

サーバ管理コマンドのカスタマイズは，usrconf.properties（サーバ管理コマンド用システムプロパティファイル）で設定します。設定内容を次に示します。

表2‒28　ユーザ指定名前空間機能を使用するためのサーバ管理コマンドのカスタマイズ

項目

指定するキー

設定内容

EJBホームオブジェクトリファレンスの別名付与（ユーザ指定名前空間機能）

ejbserver.cui.optionalname.enabled

EJBホームオブジェクトの別名を指定するかどうかを指定します。

また，EJBホームオブジェクトに別名を付与するためには，このキーの指定に加えて，EJBホームオブジェクトの別名※を指定する必要があります。

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

ejbserver.cui.optionalname.enabled

J2EEリソースの別名を指定するかどうかを指定します。

J2EEリソースに別名を付与するためには，このキーの指定に加えて，J2EEリソースの別名※を指定する必要があります。

注※　サーバ管理コマンドを使用してJ2EEアプリケーションのプロパティを定義するときに別名を指定します。JNDI名前空間に登録される名称の参照と変更については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.13　JNDI名前空間に登録される名称の参照と変更」を参照してください。

(2)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。Enterprise Beanの別名の設定とJ2EEリソースの設定に分けて説明します。なお，ここで説明するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「2.6.5　Enterprise Beanの別名の設定」または「2.6.6　J2EEリソースの別名の設定」を参照してください。

(a)　Enterprise Beanの別名の設定

Enterprise Beanに別名を付与するための設定には，Session Bean属性ファイルまたはEntity Bean属性ファイルを使用します。インタフェースの種別によってタグ名が異なります。インタフェースの種別ごとに使用する属性ファイルとタグを次に示します。

リモートインタフェースの別名

Session Beanの場合はSession Bean属性ファイル，Entity Beanの場合はEntity Bean属性ファイルの<optional-name>タグに指定します。

ローカルインタフェースの別名

Session Beanの場合はSession Bean属性ファイル，Entity Beanの場合はEntity Bean属性ファイルの<local-optional-name>タグに指定します。

属性ファイルでの別名の指定例を次に示します。この例は，SessionBean属性ファイルを使用して，Stateful Session Beanに別名を設定する場合の例です。

<hitachi-session-bean-property>
  <display-name>MyAdder</display-name>
  <session-type>Stateful</session-type>
  <transaction-type>Container</transaction-type>
  <runtime>
    <lookup-name>MyAdder</lookup-name>
    <optional-name>user/Adder</optional-name>
    <local-optional-name>user/localAdder</local-optional-name>
    <maximum-sessions>0</maximum-sessions>
    <stateful>
      <maximum-active-sessions>0</maximum-active-sessions>
      <inactivity-timeout>0</inactivity-timeout>
      <removal-timeout>0</removal-timeout>

この例の場合は，リモートインタフェースの別名として「user/Adder」，ローカルインタフェースの別名として「user/localAdder」が設定されます。

(b)　J2EEリソースの別名の設定

J2EEリソースに別名を付与するための設定は，DB Connector，メールコンフィグレーション，またはJavaBeansリソースの属性として設定します。設定に使用するコマンドおよび属性ファイルは，リソースの種別ごとに異なります。リソースの種別と別名を設定するコマンドおよび属性ファイルを次の表に示します。

表2‒29　リソースの種別と別名を設定するコマンドおよび属性ファイル

リソースの種別

コマンド

属性ファイル

指定するタグ

リソースアダプタ

cjsetrarpropコマンド

Connector属性ファイル

<resource-external-property>−<optional-name>タグ

メールコンフィグレーション

cjsetrespropコマンド

メール属性ファイル

JavaBeansリソース

cjsetjbpropコマンド

JavaBeansリソース属性ファイル

<resource-env-external-property>−<optional-name>タグ

注　メールコンフィグレーションおよびJavaBeansリソースについては，cosminexus.xmlでは設定できません。属性ファイルで設定してください。

属性ファイルでの別名の指定例を次に示します。この例は，Connector属性ファイルを使用して，リソースアダプタに別名を設定する場合の例です。

<hitachi-connector-property>
  <description></description>
  <display-name>DB_Connector_for_Oracle</display-name>
  <icon />
  <vendor-name>Hitachi, Ltd.</vendor-name>
  :
  <connector-runtime>
    <resource-external-property>
    <description></description>
    <optional-name>jdbc/TestDB1</optional-name>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-external-property>
  </connector-runtime>
</hitachi-connector-property>

この例の場合は，DB Connectorの別名として「jdbc/TestDB1」が設定されます。

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

ここでは，ユーザ指定名前空間機能を使用する場合の注意事項について説明します。

(1)　別名を使用した検索を実行する場合の注意

ローカルインタフェースを持つEnterprise Beanは，J2EEアプリケーション外から検索できません。

ローカルインタフェースを持つEnterprise Beanの別名に対して，ネーミングコンテキスト単位の検索はできません。

リモートインタフェースを持つEnterprise Beanとローカルインタフェースを持つEnterprise Beanには，同じ別名を設定できます。ただし，この場合に重複している別名をルックアップすると，必ずローカルインタフェースを持つEnterprise Beanがルックアップされます。

(2)　ネーミングサービスについての注意

複数のJ2EEサーバで，一つのCORBAネーミングサービスを共用している場合，ユーザ指定名前空間機能は使用できません。

J2EEサーバとCORBAネーミングサービスは同じタイミングで起動・停止するようにしてください。

J2EEサーバまたはCORBAネーミングサービスのどちらか一方がダウンした場合は，J2EEサーバとCORBAネーミングサービスを共に再起動してください。

CORBAネーミングサービスを共有する場合，ユーザ指定名前空間機能で指定する別名として「Cosminexus」は使用できません。

(3)　J2EEリソースの別名を指定する場合の注意

別名を登録したJ2EEリソースを停止，削除，または属性変更（JavaMailセッションの場合）する場合は，J2EEサーバ上で開始されているすべてのJ2EEアプリケーションを先に停止してください。

J2EEリソースのユーザ指定名前空間機能を使用する場合，J2EEアプリケーションで生成するInitialContextで指定しているプロバイダURL（java.naming.provider.url）のホスト名と，J2EEサーバ側のサーバ定義に指定するejbserver.naming.hostキーの値は同じ文字列にしてください。なお，次の条件に当てはまる場合は，J2EEアプリケーションで生成しているInitialContextに対して，プロバイダURLを指定する必要はありません。

J2EEサーバ用ユーザプロパティファイルのejbserver.naming.hostキーに「localhost」（デフォルト値）を指定する。

同一J2EEサーバ上のネーミングサービスへ接続する。

ejbserver.naming.hostキーに「localhost」を指定していて，J2EEアプリケーションで生成しているInitialContextのプロバイダURLを指定する場合は，プロバイダURLのホスト名に次のAPIで取得できる値を指定してください。java.net.InetAddress.getLocalHost().getHostName();

J2EEリソースのユーザ指定名前空間機能では，別名の中に"/"文字を含めた場合も，ネーミングコンテキスト単位で検索できません。ルックアップ名称として使用できる文字列は，指定した別名だけです。

別名として"jdbc/TestDB"を付与してデプロイおよび開始しているJ2EEリソース（DB Connector）の場合に，使用できるJNDIのルックアップ名称と使用できないルックアップ名の例を次に示します。

使用できるルックアップ名の例

DataSource ds = (DataSource) initCtx.lookup("jdbc/TestDB");

使用できないルックアップ名の例

Context ctx = (Context) initCtx.lookup("jdbc");

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

複数のCORBAネーミングサービスに登録されている同一名称（別名）のEJBホームオブジェクトまたはビジネスインタフェースのリファレンスを，ラウンドロビンポリシーに従ってルックアップできます。これを，ラウンドロビン検索といいます。

JNDIの名前空間から該当する名前でEJBホームオブジェクトまたはビジネスインタフェースのリファレンスをラウンドロビン検索した場合，クライアントアプリケーションは複数のCORBAネーミングサービス上に存在するEJBホームオブジェクトまたはビジネスインタフェースのリファレンスから，ラウンドロビンのポリシーで選択されたEJBホームオブジェクトまたはビジネスインタフェースのリファレンスを取得できます。これによって，J2EEサーバをクラスタ構成で開始して，負荷を分散できます。また，EJBクライアントからは，クラスタ構成を意識しないで，J2EEサーバのEnterprise Beanを呼び出すことができます。

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

表2‒30　この節の構成（ラウンドロビンポリシーによるCORBAネーミングサービスの検索）

分類

タイトル

参照先

解説

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

2.7.1

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

2.7.2

設定

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

2.7.3

ラウンドロビン検索機能を使用する場合の推奨する設定

2.7.4

注意事項

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

2.7.5

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

ポイント

ラウンドロビン検索をする場合，検索対象となるEJBホームオブジェクトまたはビジネスインタフェースのリファレンスは同じ名称でCORBAネーミングサービスに登録されている必要があります。このため，ユーザ指定名前空間機能を使用して，それぞれのEJBホームオブジェクトまたはビジネスインタフェースのリファレンスに同じ名称を指定してください。

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

JNDIによるラウンドロビン検索の対象範囲は，論理ネーミングサービス内のグループとなります。

論理ネーミングサービスは一つ以上のグループで構成されます。1グループにつき一つ以上のCORBAネーミングサービスを含みます。論理ネーミングサービスの構成を次の図に示します。

図2‒10　論理ネーミングサービスの構成

複数のグループで，グループのメンバに同一のCORBAネーミングサービスを指定できます。

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

クライアントプログラムからのラウンドロビン検索時の動作について次に示す図で説明します。

なお，図中の各CORBAネーミングサービスには，ラウンドロビン検索の対象となるEJBホームオブジェクトが「MyBean」という名前で登録されていると仮定します。検索対象となる複数のEJBホームオブジェクトには，ユーザ指定名前空間機能によって，同一の名称が設定されています。

図2‒11　ラウンドロビン検索時の動作

上記の図について説明します。

クライアントアプリケーションは，検索対象の論理ネーミングサービスのグループ名を引数にして，ラウンドロビン用のInitialContextインスタンスを生成します。

クライアントアプリケーションは，生成したラウンドロビン用のInitialContextインスタンスに，「MyBean」という名前を指定して検索を要求します。

ラウンドロビン検索機能は，ラウンドロビンポリシーで検索対象のグループに属するCORBAネーミングサービスの検索先を決定します。

検索に成功すると，クライアントアプリケーションに結果を返します。

なお，検索に失敗した場合は，グループに属する別のCORBAネーミングサービスを検索します。

クライアントアプリケーションは，検索されたEJBホームオブジェクトにアクセスします。

注意事項

InitialContextの初回発行時は，すべてのグループのプロバイダURLに接続を試みます。このため，接続できないプロバイダURLの記載がある場合，遅延などが発生することがあります。

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

ラウンドロビン検索をするために必要な設定とグループ名の命名規則などについて説明します。

ラウンドロビン検索をする場合，次の設定が必要です。

ラウンドロビン検索の対象になる論理ネーミングサービスのグループ

各グループに属するCORBAネーミングサービスのルート位置

InitialContextFactoryの実装を委譲しているクラス

ラウンドロビン検索機能を使用するためには，システムプロパティに設定します。なお，InitialContextFactoryの実装を委譲しているクラスについては，システムプロパティの設定に加えて，各アプリケーションのInitialContext生成時に引数で指定することもできます。また，InitialContext生成時の引数では，システムプロパティに指定した論理ネーミングサービスのグループのうち，特定のネーミングサービスを選択して指定することもできます。

なお，システムプロパティだけで設定している場合は，特定のグループを指定したラウンドロビン検索はできません。論理ネーミングサービス上にある全グループのネーミングサービスが検索の対象となります。

ここでは，それぞれの設定方法の概要について説明します。

(1)　システムプロパティの設定によるグループとグループに属するCORBAネーミングサービスのルート位置の特定

ラウンドロビン検索を実行する場合，システムプロパティに，ラウンドロビン検索の対象になる論理ネーミングサービスのグループと，グループに属するネーミングサービスのルート位置を指定します。また，InitialContextFactoryの実装を委譲しているクラスとして，java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactoryを指定する必要があります。

システムプロパティは，ラウンドロビン検索機能を利用するアプリケーションの種類ごとに，次の個所に設定方法が異なります。

(2)　J2EEサーバで動作するJ2EEアプリケーション（Enterprise Beanまたはサーブレット）の場合

J2EEサーバのプロパティをカスタマイズして設定します。設定は，簡易構築定義ファイルの，J2EEサーバ用のユーザプロパティに設定します。

ラウンドロビン検索をするための定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでのラウンドロビン検索をするための定義について次の表に示します。

表2‒31　簡易構築定義ファイルでのラウンドロビン検索をするための定義

指定するパラメタ

設定内容

ejbserver.jndi.namingservice.group.list

CORBAネーミングサービスのグループを指定します。

ejbserver.jndi.namingservice.group.<Specify group name>.providerurls

各グループに属する，CORBAネーミングサービスのルート位置を指定します。

java.naming.factory.initial

InitialContextFactoryの実装をデレゲートしているクラスを指定します。

なお，ラウンドロビン検索は，ユーザ指定名前空間機能を使用していることが前提になります。ユーザ指定名前空間機能を使用する場合，サーバ管理コマンドの動作設定のカスタマイズと，J2EEアプリケーションのプロパティの定義が必要です。設定方法については，「2.6.7　実行環境での設定」および「2.6.5　Enterprise Beanの別名の設定」を参照してください。

(3)　J2EEサーバ以外で動作するEJBクライアントアプリケーションの場合

次のどちらかの方法で設定します。

EJBクライアントアプリケーション起動時にプロパティとして設定する。

System.setPropertyメソッドを使用してアプリケーション内で設定する。

なお，EJBクライアントアプリケーションのプロパティの設定方法は，EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのプロパティの設定方法が異なります。EJBクライアントアプリケーションのプロパティの設定方法および指定例を説明します。

(a)　EJBクライアントアプリケーションのプロパティの設定方法

プロパティの設定方法は，cjclstartapコマンドを使用する場合とvbjコマンドを使用する場合で異なります。

cjclstartapコマンドの場合

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）でプロパティを設定します。なお，指定できるプロパティについては，「(2)　J2EEサーバで動作するJ2EEアプリケーション（Enterprise Beanまたはサーブレット）の場合」を参照してください。

vbjコマンドの場合

vbjコマンドを使用する場合は，バッチファイル/シェルスクリプトファイル，またはコマンドの引数で，プロパティを設定します。

(b)　プロパティの指定例

指定例を次に示します。この例は，プロパティをusrconf.propertiesで指定する場合の指定例です。なお，それぞれのキーの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

# 論理ネーミングサービスの構成を定義
ejbserver.jndi.namingservice.group.list=g1;g2;g3
ejbserver.jndi.namingservice.group.g1.providerurls=corbaname::hostA:900;corbaname::hostB:900
ejbserver.jndi.namingservice.group.g2.providerurls=corbaname::hostD:700;corbaname::hostE:700
ejbserver.jndi.namingservice.group.g3.providerurls=corbaname::hostF:800;corbaname::hostG:800
# InitialContextFactoryの実装を委譲するクラスを指定
java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactory
　　：

指定例の中のejbserver.jndi.namingservice.group.listキー，ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキー，およびjava.naming.factory.initialキーには，それぞれ次の内容を指定します。

ejbserver.jndi.namingservice.group.listキー

ラウンドロビン検索をする場合に，検索対象になる論理ネーミングサービスのグループを定義します。指定する各グループ名は，論理ネーミング内で一意に識別できる名称にします。

ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキー

各グループに属するネーミングサービスのルート位置をプロバイダURLで指定します。<Specify group name>には，ejbserver.jndi.namingservice.group.list内に指定したグループ名を指定します。

java.naming.factory.initialキー

InitialContextFactoryの実装を委譲しているクラスを指定します。

java.naming.factory.initialキーに，"com.hitachi.software.ejb.jndi.GroupContextFactory"を指定した場合，ラウンドロビン検索が実施されます。指定しなかった場合，J2EEサーバがネーミングサービスとして利用するCORBAネーミングサービスが検索の対象になります。

なお，「(4)　InitialContext生成時の引数指定による検索対象グループの選択」に示す方法でInitialContext生成時の引数にjava.naming.factory.initialキーを設定する場合，システムプロパティでこのキーに値を指定する必要はありません。

(4)　InitialContext生成時の引数指定による検索対象グループの選択

ラウンドロビン検索を実行する設定になっている場合に，クライアントアプリケーション内でInitialContext生成時の引数に特定のグループを指定することによって，ラウンドロビン対象でのルックアップ対象になるグループを選択できます。なお，InitialContext生成時の引数の指定は任意です。

指定例を次に示します。

　　　　　：
Hashtable env = new Hashtable();
env.put("ejbserver.jndi.namingservice.groupname", "g1");
env.put("java.naming.factory.initial",
                 "com.hitachi.software.ejb.jndi.GroupContextFactory");
InitialContext ic = new InitialContext(env);
　　　　　：

指定例の中のejbserver.jndi.namingservice.groupnameキーおよびjava.naming.factory.initialキーには，それぞれ次の内容を指定します。

ejbserver.jndi.namingservice.groupnameキー

検索対象となるグループ名を「gl」部分に指定します。グループ名は，システムプロパティ（usrconf.propertiesのejbserver.jndi.namingservice.group.listキー）で，すでに定義されているものを指定してください。なお，ejbserver.jndi.namingservice.groupnameキーにデフォルト値はありません。指定しなかった場合，システムプロパティで設定した，すべてのグループを検索の対象とします。

java.naming.factory.initialキー

InitialContextFactoryの実装を委譲しているクラスを指定します。java.naming.factory.initialキーに，"com.hitachi.software.ejb.jndi.GroupContextFactory"を指定した場合，ラウンドロビン検索が実施されます。システムプロパティのjava.naming.factory.initialキーの指定を省略した場合に，引数でこのキーの指定を省略すると，ejbserver.jndi.namingservice.groupnameキーで指定したグループの検索は実施されないで，J2EEサーバがネーミングサービスとして利用するCORBAネーミングサービスが検索の対象になります。

(5)　グループ名の命名規則

グループ名に使用できる文字を次に示します。

英数字（A〜Z，a〜z，0〜9）

アンダースコア（_）

なお，グループ名は，論理ネーミングサービス内で一意となる名称にしてください。

(6)　プロパティでの設定内容

EJBクライアントアプリケーションのプロパティは，JavaアプリケーションからEnterprise Beanを呼び出す場合に使用されます。J2EEアプリケーションの内容に応じて，必要なプロパティを設定してください。設定できるプロパティについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

プロパティで設定できる内容の一例

EJBクライアントアプリケーションのログの設定

ejbserver.client.logで始まるキーやejbserver.loggerで始まるキーなどで，システムが出力するシステムログと，EJBクライアントアプリケーションが出力するユーザログの出力先やログレベルなどを変更できます。システムログについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「3.8　EJBクライアントアプリケーションのシステムログ出力」，ユーザログについては，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.　アプリケーションのユーザログ出力」を参照してください。

EJBクライアントアプリケーションのトランザクションの設定

ejbserver.client.transactionで始まるキーで，EJBクライアントアプリケーションでトランザクションを使用するかどうか，トランザクションサービスが使用するクライアント名などを指定できます。なお，Clientを使用してEJBクライアント環境を構築する場合は，EJBクライアントアプリケーションのトランザクションは使用できません。詳細については，「3.19　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」を参照してください。

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

ejbserver.container.rebindpolicyキーに，EJBクライアント側でのコネクションの再接続動作とリクエストの再送動作を指定できます。

EJBクライアントアプリケーションからラウンドロビン検索を実行する設定

ejbserver.jndi.namingservice.group.listキー，ejbserver.jndi.namingservice.group.<Specify group name>.providerurlsキーおよびjava.naming.factory.initialキーに，CORBAネーミングサービスのグループ，各グループに属するCORBAネーミングサービスのルート位置，およびInitialContextFactoryの実装をデレゲートしているクラスを指定できます。なお，ラウンドロビン検索は，J2EEサーバのサーバ管理コマンドのカスタマイズでユーザ指定名前空間機能を使用する設定をしている場合に有効になります。

EJBクライアントアプリケーションからCTMへのリクエストの優先度の設定

ejbserver.client.ctm.RequestPriorityキーに，EJBクライアントアプリケーションからCTMに送信するリクエストの優先度を設定できます。

(7)　コマンドによって指定の要否が異なるプロパティ（EJBクライアントアプリケーションの場合）

ここでは，EJBクライアントアプリケーションのコマンド（vbjコマンド）によって指定の要否が異なるプロパティについて説明します。EJBクライアントアプリケーションのコマンドによって指定の要否が異なるプロパティのキーを次の表に示します。

表2‒32　EJBクライアントアプリケーションのコマンドによって指定の要否が異なるプロパティのキー

プロパティのキー

種別

コマンド

cjclstartap

vbj

org.omg.CORBA.ORBClass

固定

−

−

org.omg.CORBA.ORBSingletonClass

固定

−

−

javax.rmi.CORBA.UtilClass

固定

−

○

javax.rmi.CORBA.StubClass

固定

−

−

javax.rmi.CORBA.PortableRemoteObjectClass

固定

−

○

java.endorsed.dirs

可変

−

−

（凡例）

固定：該当するキーに対する値は固定で，指定する必要がある

可変：システムの実行環境に従って値を指定する必要がある

○：コマンドにキーを指定する必要がある

−：コマンドにキーを指定する必要がない

2.7.4　ラウンドロビン検索機能を使用する場合の推奨する設定

ラウンドロビン検索機能を使用するときには，ネーミングサービスの障害検知機能をあわせて使用することを推奨します。

ネーミングサービスの障害検知機能と組み合わせた設定例については，「2.9.4　実行環境の設定（障害検知機能を使用する場合）」を参照してください。

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

ここでは，ラウンドロビン検索をする場合の注意事項について説明します。

ラウンドロビン検索用に取得したコンテキストでは，lookupメソッドだけをサポートしています。javax.naming.Contextで定義されているほかのAPIは使用できません。

別名を使用したラウンドロビン検索を実行すると，次の順序でEnterprise Beanが検索されます。

検索を実行したJ2EEサーバの名前空間から，ローカルインタフェースを持つEnterprise Beanが検索されます。

1.で見つからなかった場合は，ラウンドロビン検索によってリモートインタフェースを持つEnterprise Beanが検索されます。

InitialContextFactoryの処理を委譲しているクラスごとの検索可否を次の表に示します。

表2‒33　InitialContextFactoryの処理を委譲しているクラスごとの検索可否

検索対象

GroupContextFactory

InsContextFactory

リモートインタフェースを持つEnterprise Bean

○※

○

リモートインタフェースを持つEnterprise Bean

（別名による検索）

○

○

ローカルインタフェースを持つEnterprise Bean

○※

○

ローカルインタフェースを持つEnterprise Bean

（別名による検索）

○

○

J2EEリソース

○※

○

J2EEリソース

（別名による検索）

×

○

（凡例）　○：検索できる　×：検索できない

注※　java:comp/envでのルックアップの場合，ラウンドロビン検索はしません。ルックアップを実行した自身のJ2EEサーバだけから検索されます。

InitialContextFactoryの実装を委譲しているクラスは，次の方法で指定します。両方指定した場合は引数で指定した方が有効になります。

usrconf.propertiesのjava.naming.factory.initialキーに指定する。

InitialContextを生成するときの引数(Hashtable)で，java.naming.factory.initialキーに指定する。

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

J2EEサービスのネーミング管理機能には，キャッシング機能があります。キャッシング機能とは，JNDIを介してEJBホームオブジェクトリファレンスを検索した場合に，該当オブジェクトをキャッシュに一時的に保存し，以降，同一のオブジェクトを検索するときには，キャッシュに保存されたオブジェクトを返す機能です。

この節では，キャッシングの流れ，およびキャッシュ領域のクリアについて説明します。

なお，ネーミング管理機能でのキャッシングをするための設定は，J2EEサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。

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

表2‒34　この節の構成（ネーミング管理機能でのキャッシング）

分類

タイトル

参照先

解説

キャッシングの流れ

2.8.1

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

2.8.2

設定

キャッシング機能を使用するための設定

2.8.3

注意事項

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

2.8.4

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

2.8.1　キャッシングの流れ

次の図に示すような流れで，ネーミングはキャッシングされます。

図2‒12　ネーミングのキャッシングの流れ

キャッシングの流れを説明します。この流れでは，同じJ2EEサーバ上の二つのJ2EEアプリケーションから，同じ名前「Count」でEJBホームオブジェクトのリファレンスをルックアップします。1.〜5.がJ2EEアプリケーション1から実行される処理，6.〜9.がJ2EEアプリケーション2から実行される処理です。

J2EEアプリケーション1が，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーション1が，javax.naming.InitialContextクラスのインスタンスに対して，EJBホームオブジェクトリファレンスの検索（ルックアップ）を要求します。このとき，名前に「Count」を指定します。

要求を受けたネーミング管理機能が，CORBAネーミングサービスの名前空間からEJBホームオブジェクトリファレンスを検索します。

ネーミング管理機能は，検索結果として，EJBホームオブジェクトのリファレンスを取得します。

ネーミング管理機能が，取得したEJBホームオブジェクトのリファレンスをキャッシュに保存します。

同じプロセス上にあるJ2EEアプリケーション2が，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーション2が，javax.naming.InitialContextクラスのインスタンスに対して，EJBホームオブジェクトリファレンスの検索（ルックアップ）を要求します。このとき，名前に，2.で指定した名前と同じ名前「Count」を指定します。

要求を受けたネーミング管理機能が，キャッシュから，EJBホームオブジェクトリファレンスを検索します。

ネーミング管理機能が，検索結果として，キャッシュからEJBホームオブジェクトのリファレンスを取得します。

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

ネーミングで使用しているキャッシュは，クリアできます。ただし，クリアするキャッシュサイズは設定できません。ここでは，キャッシュクリアが行われるタイミングと，クリアされる範囲について説明します。

(1)　キャッシュクリアのタイミング

キャッシュの内容は次のどちらかのタイミングでクリアされます。

JNDIおよびRMI-IIOPのAPIで例外が発生した場合，キャッシュのクリアを強制的に実施します。

システムプロパティに指定した値の間隔でキャッシュをクリアします（デフォルト値は0秒で，キャッシュはクリアされません）。

(2)　キャッシュクリアの範囲

ネーミングサービスでのキャッシュクリアの範囲について説明します。

キャッシュクリアの範囲は2とおりあります。

キャッシュ領域をすべてクリアします。

無効なキャッシュ領域だけをクリアします。

1.の場合，キャッシュの全領域をクリアします。一方，2.の場合は，定期的に，キャッシュに保存されたオブジェクトが有効かどうかを確認し，無効なオブジェクトだけをキャッシュからクリアします。また，2.の場合，キャッシュクリアと同じタイミングで，一度検索したCORBAネーミングサービスの状態を監視します。これによって，一度検索されたCORBAネーミングサービスの場合，CORBAネーミングサービスがダウンしたあとは，該当するCORBAネーミングサービスの検索を実施しません。また，CORBAネーミングサービスが再起動すると，該当するCORBAネーミングサービスの検索を自動的に開始します。

キャッシュクリアの設定方法は，「2.8.3　キャッシング機能を使用するための設定」を参照してください。

また，障害検知機能を使用する場合は，「2.9.4　実行環境の設定（障害検知機能を使用する場合）」を参照してください。

参考

EJBホームオブジェクトの再接続機能を使用している場合，J2EEサーバを再起動したあとでも，キャッシュは無効になりません。

このため，無効なキャッシュ領域だけをクリアする指定をしているときでも，CORBAネーミングサービスのEJBホームオブジェクトのオブジェクトリファレンスは，キャッシュ領域から削除されません。

EJBホームオブジェクトのリファレンスの検索（ルックアップ）で，削除されなかったキャッシュ上のオブジェクトリファレンスがそのまま使用できます。

2.8.3　キャッシング機能を使用するための設定

キャッシング機能を使用するための設定について説明します。J2EEアプリケーションの場合とEJBクライアントアプリケーションの場合で設定個所が異なります。

(1)　J2EEアプリケーションでキャッシング機能を使用する場合

J2EEアプリケーションでキャッシング機能を使用するための定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでのキャッシング機能を使用するための定義について次の表に示します。

表2‒35　キャッシング機能を使用するための定義

指定するパラメタ

設定内容

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>

(2)　EJBクライアントアプリケーションでキャッシング機能を使用する場合

EJBクライアントアプリケーション起動時にプロパティとして設定します。

EJBクライアントアプリケーションのプロパティの設定方法は，EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのプロパティの設定方法が異なります。

cjclstartapコマンドの場合

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）で，プロパティを設定します。

vbjコマンドの場合

vbjコマンドを使用する場合は，バッチファイル/シェルスクリプトファイル，またはコマンドの引数で，プロパティを設定します。

キャッシュを定期的にクリアするときの設定例を次に示します。

EJBクライアントのシステムプロパティ設定例

  ：
# キャッシュの設定
ejbserver.jndi.cache=on
ejbserver.jndi.cache.interval=60
ejbserver.jndi.cache.interval.clear.option=check

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

ネーミングのキャッシングに関する注意事項について説明します。

アプリケーションでEJBホームオブジェクトリファレンスやJDBCデータソースをキャッシングしている場合，ネーミングでのキャッシングを無効にすることを推奨します。

キャッシュを定期的にクリアするには，簡易構築定義ファイルで設定します。論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタで設定します。

ejbserver.jndi.cache.interval.clear.option

キャッシュをクリアする範囲を指定します。

ejbserver.jndi.cache

キャッシュを実行するかどうかを指定します。ここでは「ON」を設定してください。

ejbserver.jndi.cache.interval

キャッシュのクリア間隔を指定します。

論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，プロパティ「ejbserver.jndi.cache.interval.clear.option」に「check」を設定している場合，CORBAネーミングサービスの監視は，プロパティ「ejbserver.jndi.cache.interval」に指定したキャッシュクリアのタイミングだけで行われます。CORBAネーミングサービスの再起動後，CORBAネーミングサービスの回復を検知するためには，最大で，プロパティ「ejbserver.jndi.cache.interval」に設定した時間が必要です。

キャッシング機能を使用している場合，キャッシュにEJBホームオブジェクトのオブジェクトリファレンスが保存された状態で，EJBホームオブジェクトが保存されているJ2EEサーバがダウンするか，またはJ2EEアプリケーションの再デプロイが実行されると，キャッシュに保存されているEJBホームオブジェクトのオブジェクトリファレンスは無効な情報となります。この状態でEJBホームオブジェクトの検索要求（lookup）を受けると，キャッシュ上の無効なオブジェクトリファレンスが検索要求元に返却されます。このオブジェクトリファレンスに対して，javax.rmi.PortableRemoteObject.narrow()メソッド，またはcreateメソッドなどのメソッドを実行すると，CORBA例外（org.omg.CORBA.OBJECT_NOT_EXISTなど）が発生する場合があります。なお，CORBA例外が発生した場合，キャッシュ情報はすべて削除されます。次回の検索要求（lookup）ではCORBAネーミングサービスへ接続して有効な情報が取得されます。

CTMを使用している場合に，指定した値の間隔で無効なキャッシュ領域だけをクリアするとき，J2EEサーバやJ2EEアプリケーションが停止していても，グローバルCORBAネーミングサービスのEJBホームオブジェクトのオブジェクトリファレンスはキャッシュ領域からクリアされません。EJBホームオブジェクトの検索要求（lookup）を受けると，クリアされなかったキャッシュ上のオブジェクトリファレンスが検索要求元に返却されます。J2EEアプリケーションが再度開始されていた場合は，キャッシュしたオブジェクトリファレンスはそのまま使用できます。J2EEアプリケーションが再度開始されていない場合は，返却されたオブジェクトリファレンスに対して，createメソッドなどのメソッドを実行すると，CORBA例外（org.omg.CORBA.NO_IMPLEMENT）などが発生します。

なお，CORBA例外が発生した場合，キャッシュ情報はすべて削除されます。J2EEアプリケーションが再開始している場合は，次回の検索要求（lookup）でグローバルCORBAネーミングサービスに接続して有効な情報が取得されます。

ビジネスインタフェース使用時に，プロパティ「ejbserver.jndi.cache」に「on」を設定している状態でJ2EEサーバを再起動した場合，ビジネスメソッド実行時にjavax.ejb.EJBExceptionが発生する場合があります。

なお，javax.ejb.EJBExceptionが発生した場合，次回の検索要求（lookup）ではCORBAネーミングサービスへ接続して有効な情報が取得されます。

キャッシング機能では，内部処理でCORBAネーミングサービスのリファレンスをキャッシュしています。 キャッシング機能が無効な場合は，CORBAネーミングサービスのリファレンスをキャッシュしないで，javax.naming.InitialContextクラスのインスタンスを生成するたびに作成します。そのため，キャッシング機能を無効にして，頻繁にjavax.naming.InitialContextクラスのインスタンスを生成した場合，javaヒープが増加することがあります。その場合，キャッシング機能を有効にしてください。

2.9　ネーミングサービスの障害検知

ネーミングサービスの障害検知は，キャッシング機能のオプションとして使用します。

ネーミングサービスの障害検知機能を使用すると，ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できます。

この節では，ネーミングサービスの障害検知機能の概要，およびネーミングサービスの障害検知機能と併用して使用することを推奨する機能について説明します。

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

表2‒36　この節の構成（ネーミング管理の障害検知）

分類

タイトル

参照先

解説

ネーミング管理の障害検知機能とは

2.9.1

ラウンドロビン検索機能との併用

2.9.2

ネーミング管理の障害検知機能の挙動

2.9.3

設定

実行環境の設定（障害検知機能を使用する場合）

2.9.4

注意事項

ネーミング管理の障害検知機能の注意事項

2.9.5

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

2.9.1　ネーミングサービスの障害検知機能とは

ネーミングサービスの障害検知機能を使用すると，ネーミングサービスが停止したり，アプリケーションサーバなどでマシンの障害やネットワーク障害が発生したりした場合，J2EEサーバが障害を検知します。

ネーミングサービスの障害検知機能では，J2EEサーバがネーミングサービスの機能の状態を監視し，通信ができないと判断したネーミングサービスの機能を使用することを抑止できます。そのため，EJBクライアントではむだな通信をしないで済みます。

ネーミングサービスの障害検知機能を使用した場合の処理の流れを次の図に示します。

図2‒13　ネーミングサービスの障害検知機能を使用した場合の処理の流れ

ネーミングサービスの障害検知機能を使用しない場合，名前をルックアップするときには必ずネーミングサービスに通信します。このため，通信できないでエラーになるまでに時間が掛かることがあります。一方，ネーミングサービスの障害検知機能を使用している場合，障害が発生しているネーミングサービスに対する通信はしないで，エラーを検知できます。このため，時間が掛かりません。

2.9.2　ラウンドロビン検索機能との併用

ラウンドロビン検索機能とネーミングサービスの障害検知機能を併用すると，一つの系で障害が発生したときに，障害が発生した系を容易に切り離しできます。

次に，ラウンドロビン検索機能とネーミングサービスの障害検知機能を併用した場合の通信について図で説明します。

図2‒14　ラウンドロビン検索機能とネーミングサービスの障害検知機能を併用した場合の通信

名前をルックアップした場合に特定のネーミングサービスに障害が発生していることを検知した場合，ラウンドロビン検索機能によって，通信可能なネーミングサービスへの通信に切り替えられます。

2.9.3　ネーミングサービスの障害検知機能の挙動

ネーミングサービスの障害検知機能の挙動について説明します。

(1)　閉塞のタイミング

ネーミングサービスの障害検知では，次のタイミングでネーミングサービスの状態を確認し，応答がなかった場合に閉塞します。

sweepインターバル時間経過のタイミングに応答がなかった場合

RMI/IIOP通信エラーなどを契機にキャッシュの領域がすべてクリアされたあとや，キャッシュがない状態で，次の操作を最初に実行した時にネーミングサービスの応答がなかった場合

InitilalContextを生成した時

lookupをした時

キャッシュをすべてクリアしたあとのネーミングサービスに対する操作の挙動について表で説明します。

表2‒37　キャッシュをすべてクリアしたあとのネーミングサービスに対する操作の挙動

ネーミング管理の機能での操作

ラウンドロビン検索を使用している場合

ラウンドロビン検索を使用していない場合

InitialContextを生成したとき

EJBクライアントプロセス起動後の初回InitialContext生成時に，ネーミングサービスの稼働確認で応答がない場合は，閉塞される。

初回以外の場合は，閉塞されない。

生死確認をして，ネーミングサービスからの応答が検知できない場合，閉塞される。

lookupしたとき

lookupの発行時に通信しようとしているネーミングサービスに対してだけ，状態確認をする。

応答が検知できない場合は，閉塞される。例えば三つのネーミングサービスでラウンドロビン検索をしている場合には，ダウンしたネーミングサービスが閉塞されるのは最大で3回目のlookup時になる。

生死確認をして，ネーミングサービスからの応答が検知できない場合，閉塞される。

ネーミングサービスの障害検知機能では，閉塞されると同時にKDJE47111-Iメッセージをログに出力します。メッセージが出力されたあとに，稼働中のネーミングサービスの機能に対する通信はすべて抑止されて，javax.naming.NamingExceptionをスローされます。

(2)　閉塞した場合の挙動

ネーミングサービスの障害検知機能によって閉塞されたネーミングサービスに対して，EJBクライアントからInitialContextの生成，またはlookupした場合のネーミングサービスの挙動について説明します。

閉塞したネーミングサービスに対する操作について，ラウンドロビン検索機能を使用しているか，使用していないかに分けて表で示します。

表2‒38　閉塞したネーミングサービスに対する操作

EJBクライアントからの操作

ラウンドロビン検索を使用している場合

ラウンドロビン検索を使用していない場合

InitialContextを生成したとき

ラウンドロビン用のInitialContextを返す。

常に通信を抑止する。

EJBクライアントにjavax.naming.NamingExceptionを返す。

lookupしたとき

ラウンドロビングループに登録されている，別のネーミングサービスからオブジェクトを検索して返す。

常に通信を抑止する。

EJBクライアントにjavax.naming.NamingExceptionを返す。

(3)　ネーミングサービスの閉塞解除のタイミング

閉塞を解除するタイミングについて説明します。次に示すタイミングでネーミングサービスの状態確認をして，ネーミングサービスからの応答が検知できたときに閉塞を解除します。

sweepインターバル時間経過のタイミング

閉塞を解除すると同時に，KDJE47110-Iメッセージをログに出力します。メッセージが出力されたあとは，稼働中のネーミングサービスに対する通信は抑止されません。

2.9.4　実行環境の設定（障害検知機能を使用する場合）

ネーミングサービスの障害検知機能は，キャッシング機能のオプションです。このため，キャッシング機能の設定が前提となります。ネーミングサービスのキャッシング機能の設定については，「2.8.3　キャッシング機能を使用するための設定」を参照してください。

ネーミングサービスの障害検知機能を使用する場合は，次の表に示す値を設定してください。

表2‒39　ネーミングサービスの障害検知機能を使用する場合の設定

指定するパラメタ

値

ejbserver.jndi.cache

on

ejbserver.jndi.cache.interval

1〜2,147,483,647

ejbserver.jndi.cache.interval.clear.option

check

EJBクライアントのシステムプロパティの設定例を次に示します。この例は，usrconf.propertiesに設定した場合の例です。また，この例では，ラウンドロビン検索機能もあわせて設定しています。

EJBクライアントのシステムプロパティ設定例

  ：
# キャッシュの設定
ejbserver.jndi.cache=on
ejbserver.jndi.cache.interval=60
ejbserver.jndi.cache.interval.clear.option=check

# 論理ネーミングサービスの構成を定義
ejbserver.jndi.namingservice.group.list=g1;g2;g3
ejbserver.jndi.namingservice.group.g1.providerurls= corbaname::hostA:900;corbaname::hostB:900;corbaname::hostC:900
ejbserver.jndi.namingservice.group.g2.providerurls=
　　　　　　　　　　　　　corbaname::hostD:700;corbaname::hostE:700
ejbserver.jndi.namingservice.group.g3.providerurls=
  corbaname::hostF:800;corbaname::hostG:800;corbaname::hostH:800
  ：

2.9.5　ネーミングサービスの障害検知機能の注意事項

ネーミングサービスの障害検知機能の注意事項について説明します。

(1)　閉塞解除のタイミングについて

ネーミングサービスの障害検知機能を使用しない場合，障害が発生したネーミングサービスへのクライアントアプリケーションからの検索は，ネーミングサービスおよびJ2EEサーバが再起動した直後から成功します。

しかし，ネーミングサービスの障害検知機能を使用している場合，sweepインターバルのタイミングでしか閉塞の解除ができません。ネーミング管理機能では，ネーミングサービスが停止したあと，sweepインターバルが経過しないと実際のネーミングサービスに接続しません。つまり，ネーミングサービスの機能が回復したあとから検索に成功するまでに最大sweepインターバル時間を必要とします。ネーミングサービスの障害検知機能を使用する場合，sweepインターバルの設定時間（ejbserver.jndi.cache.intervalプロパティの値）に，短い時間（推奨値は60）を設定することを推奨します。

(2)　ネーミング管理の機能の生死確認

ネーミングサービスの障害検知機能を使って稼働状態の確認を実施した場合に，一時的なネットワーク障害，サーバ側高負荷やFullGC中などで応答がないときに，ネーミングサービスが停止したと判断されることがあります。

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

ネーミング管理機能では，JNDIを介して分散オブジェクトを検索するときに，JNDIが接続するCORBAネーミングサービスの切り替えができます。切り替えは，InitialContextクラスのインスタンスに対して，プリフィックス「corbaname:」を付与した名前をlookupメソッドの引数に渡すことで実現できます。

CORBAネーミングサービスの切り替えの流れを次の図に示します。

図2‒15　CORBAネーミングサービスの切り替えの流れ

ネーミングサービスの切り替えの流れを説明します。この流れでは，J2EEアプリケーションから，プリフィックス「corbaname:」を付与したルックアップを2回実行します。プリフィックスの後ろに指定したホスト名に応じて，接続するCORBAネーミングサービスが切り替えられます。

J2EEアプリケーションが，JNDIのjavax.naming.InitialContextクラスのインスタンスを生成します。

J2EEアプリケーションが，javax.naming.InitialContextクラスのインスタンスに対して，オブジェクトの検索（ルックアップ）を要求します。このとき，プリフィックス「corbaname:」を付与した名前「corbaname::MyHost:900#Count1」を指定します。

要求を受けたネーミング管理機能から「MyHost:900」のCORBAネーミングサービスへの接続が実行されます。接続後，ルックアップで指定した名前のEJBホームのオブジェクトリファレンス「Count1」が検索されます。

J2EEアプリケーションから，InitialContextクラスのインスタンスに対して，オブジェクトの検索（ルックアップ）を要求します。このとき，プリフィックス「corbaname:」を付与した名前「corbaname::MyHost:901#Count2」を指定します。

要求を受けたネーミング管理機能から「MyHost:901」のCORBAネーミングサービスへの接続が実行されます。接続後，ルックアップで指定した名前のEJBホームのオブジェクトリファレンス「Count2」が検索されます。

CORBAネーミングサービスの切り替えは，サーバ管理コマンドを使用した，Enterprise Beanリファレンスの解決で実行します。操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.　J2EEアプリケーションのプロパティ設定」を参照してください。

なお，CORBAネーミングサービスがローカルホスト上で動作する場合，ネーミングサービスのホスト名に関する設定では，"localhost"の文字列ではなく，マシン名またはIPアドレスを指定してください。

ネーミングサービスのホスト名の設定は，J2EEサーバのプロパティをカスタマイズして設定します。設定方法については，「2.3.5　実行環境での設定」を参照してください。

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

EJBホームオブジェクトへの再接続機能とは，J2EEサーバの障害などのあとで，J2EEサーバを再起動した場合やJ2EEアプリケーションを再開始した場合に，EJBクライアントアプリケーションが取得したEJBホームオブジェクトを再利用できる機能です。J2EEサーバの再起動後やJ2EEアプリケーションの再開始後に，EJBクライアントアプリケーションが取得したEJBホームオブジェクトを，再ルックアップしないでそのまま利用できます。

Session Bean（Stateless Session BeanまたはStateful Session Bean）のEJBホームオブジェクトのリファレンスに利用できます。

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

表2‒40　この節の構成（EJBホームオブジェクトへの再接続機能）

分類

タイトル

参照先

設定

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

2.11.1

注意事項

EJBホームオブジェクトリファレンスを再利用する場合の注意事項

2.11.2

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

2.11.1　実行環境での設定（J2EEサーバの設定）

EJBホームオブジェクトへの再接続機能を使用する場合，J2EEサーバの設定が必要です。J2EEサーバの設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのEJBホームオブジェクトへの再接続機能の定義について次の表に示します。

表2‒41　簡易構築定義ファイルでのEJBホームオブジェクトへの再接続機能の定義

指定するパラメタ

設定内容

ejbserver.container.ejbhome.sessionbean.reconnect.enabled

EJBホームオブジェクトへの再接続機能を有効にするかどうかを指定します。

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

2.11.2　EJBホームオブジェクトリファレンスを再利用する場合の注意事項

EJBホームオブジェクトへの再接続機能を使用する場合の注意事項を次に示します。

J2EEサーバの再起動やJ2EEアプリケーションの再開始の際に，J2EEアプリケーションを変更しないでください。J2EEアプリケーションを変更すると，EJBホームオブジェクトのリファレンスは再利用できません。

J2EEサーバの通信ポートを固定してください。また，J2EEサーバを再起動するときに，固定した値を変更しないでください。

定義方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.14.1　通信ポートの固定」，およびマニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.14.2　IPアドレスの固定」を参照してください。

Javaアプリケーション用ユーザプロパティファイルのリモートインタフェースでの通信障害発生時のEJBクライアントの動作（ejbserver.container.rebindpolicyキー）の値に，「VB_TRANSPARENT」を指定してください。

定義方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.13　EJBのリモートインタフェースの呼び出し」を参照してください。

EJB呼び出しで通信障害が発生した場合，通信障害発生時のEJBクライアントの動作（ejbserver.container.rebindpolicyキー）の値に「VB_TRANSPARENT」を指定していると，コネクションが再接続され，リクエストが再送されます。

そのため，EJBホームオブジェクトへの再接続機能は参照系のシステムでの使用を推奨します。

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

この章では，アプリケーションサーバが接続できるリソースと，リソースへの接続について説明します。また，リソース接続でのトランザクション管理についても説明します。

3.1　この章の構成

リソース接続とトランザクション管理の機能と参照先を次の表に示します。

表3‒1　リソース接続とトランザクション管理の機能と参照先

機能

参照先

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

3.2

リソース接続

3.3

トランザクション管理

3.4

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

3.5

データベースへの接続

3.6

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

3.7

OpenTP1とのOutboundでの接続（SPPまたはTP1/Message Queue）

3.8

OpenTP1とのInboundでの接続

3.9

CJMSプロバイダとの接続

3.10

SMTPサーバとの接続

3.11

JavaBeansリソースの利用

3.12

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

3.13

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

3.14

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

3.15

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

3.16

リソースへの接続テスト

3.17

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

3.18

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

3.19

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

J2EEサーバ上のJ2EEアプリケーションに含まれるEJB，サーブレット，JSPなどのJ2EEコンポーネントからは，データベースやOpenTP1などのリソースに接続できます。データベースやOpenTP1などのリソースに接続する場合は，リソースアダプタを使用します。アプリケーションサーバでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用できます。SMTPサーバやJavaBeansリソースなどのリソースに，リソースアダプタを使用しないで接続する機能も提供しています。

また，アプリケーションサーバでは，リソースに効率的かつ信頼性の高い方法でアクセスするために，コネクションプーリングやトランザクション管理の機能を提供しています。コネクションプーリングを使用すると，リソースに対するコネクションをプーリングして，効率的にコネクションを使用できます。また，障害が発生したコネクションを適切にコネクションプールから取り除きます。また，トランザクション管理の機能を使用すると，トランザクションマネージャが，EJBのメソッドごとに指定するトランザクション属性やJTAインタフェース（UserTransaction）による指示に基づいて，リソースアクセスのトランザクションを適切に制御します。複数のリソースに対してトランザクション管理をする場合には，グローバルトランザクションを使用します。グローバルトランザクションを使用すると，2フェーズコミットプロトコルによってトランザクションが管理されるため，リソース間で更新の整合性が確保されます。

コネクションプーリング，およびトランザクション管理の機能を使用したリソースへの接続の例を次の図に示します。

図3‒1　コネクションプーリングおよびトランザクション管理の機能を使用したリソースへの接続の例

3.3　リソース接続

この節では，リソースの種類ごとの接続方法と，接続に使用するリソースアダプタの種類について説明します。

また，リソースアダプタを使用する場合の説明として，リソースアダプタの使用方法，機能および注意事項についても説明します。

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

表3‒2　この節の構成（リソース接続）

分類

タイトル

参照先

解説

リソースへの接続方法

3.3.1

リソースアダプタの種類

3.3.2

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

3.3.3

リソースアダプタの機能

3.3.4

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

3.3.5

実装

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

3.3.6

設定

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

3.3.7

リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）

3.3.8

リソースアダプタの設定の流れ（J2EEアプリケーションに含めて使用する場合）

3.3.9

リソースアダプタの設定の流れ（Inboundで使用する場合）

3.3.10

リソースアダプタ以外を使用する接続の設定

3.3.11

注意事項

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

3.3.12

注　「運用」について，この機能固有の説明はありません。

3.3.1　リソースへの接続方法

アプリケーションサーバでは，リソースの種類によって，接続にリソースアダプタを使用するものと，リソースアダプタを使用しないものがあります。それぞれのリソースへの接続方法の概要を，リソースの種類ごとに説明します。

(1)　接続にリソースアダプタを使用するリソース

接続にリソースアダプタを使用するリソースを次に示します。

データベース

データベースと接続できます。データベースと接続するためには，リソースアダプタとしてDB Connectorを使用します。

DB Connectorで接続できるのは，次のデータベースです。

HiRDB

Oracle

SQL Server※

XDM/RD E2

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

データベースとの接続については，「3.6.1　DB Connectorによる接続の概要」を参照してください。

データベース上のキュー

Reliable Messagingで使用するデータベース上のキューと接続できます。データベース上のキューと接続するためには，リソースアダプタとしてDB Connector for Reliable MessagingおよびReliable Messagingを使用します。

DB Connector for Reliable MessagingおよびReliable Messagingで接続できるのは，次のデータベースです。

HiRDB

Oracle

データベース上のキューとの接続については，「3.7.1　DB Connector for Reliable MessagingとReliable Messagingによる接続の概要」を参照してください。

OpenTP1

OpenTP1のSPP，TP1/Message QueueとOutboundで接続できます。OpenTP1のSPPとOutboundで接続するには，リソースアダプタとしてTP1 Connectorを使用します。TP1/Message Queueと接続するには，リソースアダプタとしてTP1/Message Queue - Accessを使用します。

また，OpenTP1のSUPからアプリケーションサーバにInboundで接続することもできます。OpenTP1のSUPからInboundで接続するには，リソースアダプタとしてTP1インバウンドアダプタを使用します。

OpenTP1との接続の詳細については，接続に使用するリソースアダプタごとに説明しています。参照先を次の表に示します。

表3‒3　OpenTP1との接続の詳細説明の参照先

接続方法

参照先

TP1 Connectorを使用した接続

「3.8.1　TP1 Connectorによる接続」

TP1/Message Queue - Accessを使用した接続

「3.8.2　TP1/Message Queue - Accessによる接続」

TP1インバウンドアダプタを使用した接続

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

CJMSPブローカー

CJMSプロバイダの機能を使用する場合，CJMSPブローカーと接続できます。CJMSPブローカーと接続するためには，リソースアダプタとしてCJMSPリソースアダプタを使用します。

CJMSPリソースアダプタを使用したCJMSPブローカーとの接続については，「7.　CJMSプロバイダ」を参照してください。

そのほかのリソース

リソースの種類に関係なく，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタで接続できるリソースに接続できます。

使用できるリソースアダプタについては，「3.13　そのほかのリソースとの接続」を参照してください。また，Connector 1.5仕様に準拠したリソースアダプタを使用する場合に，アプリケーションサーバで使用できる機能については，「3.16　そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合）」を参照してください。

(2)　接続にリソースアダプタを使用しないリソース

接続にリソースアダプタを使用しないリソースについて次に示します。

SMTPサーバ

SMTPサーバと接続できます。SMTPサーバとの接続については，「3.11　SMTPサーバとの接続」を参照してください。

JavaBeans

リソースとしてJavaBeansリソースを利用できます。JavaBeansリソースの利用については，「3.12　JavaBeansリソースの利用」を参照してください。

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

アプリケーションサーバでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用できます。

ここでは，それぞれの仕様に準拠したリソースアダプタについて説明します。また，リソースアダプタのDDのスキーマの違いについても説明します。

(1)　Connector 1.0仕様に準拠したリソースアダプタ

アプリケーションサーバでは，次のリソースアダプタを使用できます。

DB Connector

DB Connector for Reliable MessagingおよびReliable Messaging

TP1 Connector

TP1/Message Queue - Access

これらのリソースアダプタでは，Connector 1.0仕様に対応する機能が使用できます。

なお，DB ConnectorおよびDB Connector for Reliable Messagingでは，Connector 1.0仕様に対応する機能に加えて，アプリケーションサーバで追加された機能を使用できます。使用できる機能については，「3.3.4　リソースアダプタの機能」を参照してください。

ポイント

アプリケーションサーバでは，これらのリソースアダプタ以外にも，標準仕様のConnector 1.0仕様に準拠したリソースアダプタを使用できます。ただし，標準仕様のConnector 1.0仕様に準拠したリソースアダプタを使用する場合，DD（ra.xml）の次のタグの設定内容は無視されます。

<security-permission>

セキュリティの設定にはserver.policyファイルを使用してください。

<authentication-mechanism>

設定内容に関係なく，BasicPasswordが適用されます。

(2)　Connector 1.5仕様に準拠したリソースアダプタ

アプリケーションサーバでは，Connector 1.5仕様に準拠したリソースアダプタを使用できます。アプリケーションサーバで使用できるのは，Connector 1.5仕様の規約のうち，次の規約に対応した機能です。

Lifecycle Management

Work Management

メッセージインフロー

トランザクションインフロー

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

TP1インバウンドアダプタ

CJMSPリソースアダプタ

使用できる機能については，「3.3.4　リソースアダプタの機能」を参照してください。

また，Connector 1.5仕様に準拠したリソースアダプタについては，「3.13.1　そのほかのリソースとの接続に使用するリソースアダプタ」を参照してください。

(3)　Connector 1.0仕様とConnector 1.5仕様のリソースアダプタのスキーマの違い

Connector 1.0仕様に準拠したリソースアダプタと，Connector 1.5仕様に準拠したリソースアダプタの，DDのスキーマの違いについて説明します。リソースアダプタのDDは，ra.xmlです。

Connector 1.0仕様のスキーマからConnector 1.5仕様のスキーマに対する主な変更点を次の表に示します。ここで示す以外の変更点については，Connector 1.5仕様を参照してください。

表3‒4　Connector 1.0仕様のスキーマからConnector 1.5仕様のスキーマに対する主な変更点

Connector 1.5仕様で変更になった内容

Connector 1.5仕様のDDの内容

javax.resource.spi.ResourceAdapterインタフェースの実装クラスの指定

<connector>-<resourceadapter>-<resourceadapter-class>タグ

<connector>-<resourceadapter>-<config-property>タグ

Outboundリソースアダプタの指定

<connector>-<resourceadapter>-<outbound-resourceadapter>タグ

Inboundリソースアダプタの指定

<connector>-<resourceadapter>-<inbound-resourceadapter>タグ

adminobjectの指定

<connector>-<resourceadapter>-<adminobject>タグ

Connector 1.5仕様で変更になった内容の概要を説明します。

javax.resource.spi.ResourceAdapterインタフェースの実装クラスの指定

javax.resource.spi.ResourceAdapterインタフェースの実装クラスと，そのコンフィグレーションプロパティを指定する要素が追加されました。javax.resource.spi.ResourceAdapterインタフェースの追加に伴って実現できる機能については，「3.16.1　リソースアダプタのライフサイクル管理」および「3.16.2　リソースアダプタのワーク管理」を参照してください。

Outboundリソースアダプタの指定

Outboundのリソースアダプタを明示的に定義するための要素が追加されました。

なお，Outboundリソースアダプタでは，一つのDD内にコネクション定義を複数指定できます。コネクション定義の複数指定については，「3.16.6　コネクション定義の複数指定」を参照してください。

Inboundリソースアダプタの指定

Inboundのリソースアダプタを明示的に定義するための要素が追加されました。

adminobjectの指定

管理対象オブジェクトについての情報を指定する要素が追加されました。

(4)　リソースアダプタごとのRARファイルの種類

プロパティを定義するリソースアダプタは，接続するリソースや使用するトランザクションの種類などによって異なります。ここでは，次の場合に使用するリソースアダプタについて説明します。

DB Connectorを使用する場合

DB Connector for Reliable MessagingとReliable Messagingを使用する場合

ほかのリソースアダプタを使用する場合

(a)　DB Connectorを使用する場合

DB Connectorは，接続するデータベースの種類や使用するトランザクションの種類によって，ファイルが異なります。DB Connectorの種類を次の表に示します。

表3‒5　DB Connectorの種類

RARファイル名

説明

DBConnector_HiRDB_Type4_CP.rar

HiRDB Type4 JDBC Driverを使用して，ローカルトランザクションまたはトランザクション管理なしで，HiRDB，XDM/RD E2に接続する場合に選択します。

DBConnector_HiRDB_Type4_XA.rar

HiRDB Type4 JDBC Driverを使用して，グローバルトランザクションで，HiRDBに接続する場合に選択します。

DBConnector_Oracle_CP.rar

Oracle JDBC Thin Driverを使用して，ローカルトランザクションまたはトランザクション管理なしで，Oracleに接続する場合に選択します。

DBConnector_Oracle_XA.rar

Oracle JDBC Thin Driverを使用して，グローバルトランザクションで，Oracleに接続する場合に選択します。

DBConnector_SQLServer_CP.rar

SQL Server JDBC Driverを使用して，ローカルトランザクションまたはトランザクション管理なしで，SQL Server （Windowsの場合だけ）に接続する場合に選択します。

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

(b)　DB Connector for Reliable MessagingとReliable Messagingを使用する場合

Reliable Messagingと連携してデータベースに接続する場合には，Reliable Messaging連携用のリソースアダプタ（DB Connector for Reliable Messaging）と，Reliable Messagingで提供するリソースアダプタの両方をインポートする必要があります。Reliable Messagingで提供するリソースアダプタについては，マニュアル「Reliable Messaging」を参照してください。

DB Connector for Reliable Messagingは，使用するトランザクションの種類や接続するデータベースの種類によって，ファイルが異なります。DB Connector for Reliable Messagingの種類を次の表に示します。

表3‒6　DB Connector for Reliable Messagingの種類

RARファイル名

説明

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

HiRDB Type4 JDBC Driverを使用して，ローカルトランザクションまたはトランザクション管理なしで，HiRDBに接続する場合に選択します。

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

HiRDB Type4 JDBC Driverを使用して，グローバルトランザクションで，HiRDBに接続する場合に選択します。

DBConnector_Oracle_CP_Cosminexus_RM.rar

Oracle JDBC Thin Driverを使用して，ローカルトランザクションまたはトランザクション管理なしで，Oracleに接続する場合に選択します。

DBConnector_Oracle_XA_Cosminexus_RM.rar

Oracle JDBC Thin Driverを使用して，グローバルトランザクションで，Oracleに接続する場合に選択します。

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

ポイント

DB Connector for Reliable MessagingとReliable Messagingを使用して同一トランザクション内でJDBCとJMSのアクセスを行う場合に，同じ物理コネクションを共有することで，ローカルトランザクションの適用，グローバルトランザクションの1相コミット決着ができます。1相コミット決着のための条件を次に示します。

DB Connector for Reliable MessagingとReliable Messagingで使用するデータベースシステムが同一であり，かつサインオン方式とセキュリティ情報（ユーザ名，パスワード）が同一である。

リソースアダプタを使用するJ2EEアプリケーションの属性ファイル（Session Bean属性ファイル，Entity Bean属性ファイルなど）で<res-sharing-scope>タグに「Shareable」を指定している。

(c)　ほかのリソースアダプタを使用する場合

OpenTP1のSPPとOutboundで接続する場合には，TP1 ConnectorおよびTP1/Client/Jの提供するリソースアダプタを使用します。詳細については，TP1 Connectorのドキュメント，およびマニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

OpenTP1のSUPからInboundで接続する場合には，TP1インバウンドアダプタを使用します。詳細については，「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」を参照してください。

また，CJMSプロバイダを使用する場合，CJMSPブローカーと接続するために，CJMSPリソースアダプタを使用します。詳細については，「7.　CJMSプロバイダ」を参照してください。

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

TP1/Message Queueと接続する場合には，TP1/Message Queue - Accessの提供するリソースアダプタを使用します。詳細については，マニュアル「OpenTP1 Version 7 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」を参照してください。

また，アプリケーションサーバでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用して，任意のリソースに接続できます。これらのリソースアダプタを使用する場合は，リソースアダプタのドキュメントを参照してください。

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

ここでは，リソースアダプタの使用方法について説明します。リソースアダプタを使用してリソースと接続する方法には，次の2種類があります。

J2EEリソースアダプタとしてデプロイして使用する方法

J2EEアプリケーションに含めて使用する方法

ここでは，それぞれの方法について説明します。

(1)　J2EEリソースアダプタとしてデプロイして使用する

J2EEサーバにインポートしたリソースアダプタを，共有スタンドアロンモジュールとしてデプロイします。そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションで使用できるようになります。J2EEサーバ上に配置されたリソースアダプタをJ2EEリソースアダプタといいます。

(2)　J2EEアプリケーションに含めて使用する

リソースアダプタをJ2EEアプリケーションに含めて使用します。同じJ2EEアプリケーションに含まれるEJBやWARから，リソースアダプタを使用できます。リソースアダプタをJ2EEアプリケーションに含めて使用する手順については，「3.3.9　リソースアダプタの設定の流れ（J2EEアプリケーションに含めて使用する場合）」を参照してください。

なお，J2EEアプリケーションに含めることができるリソースアダプタには，制限があります。詳細については，「(3)　使用方法ごとに使用できるリソースアダプタ」を参照してください。

(3)　使用方法ごとに使用できるリソースアダプタ

リソースアダプタは，Application Serverのバージョンに適したリソースアダプタに統一する必要があります。また，アプリケーションサーバでは，Connector 1.0仕様，およびConnector 1.5仕様に準拠したリソースアダプタをデプロイして使用できます。ただし，J2EEアプリケーションに含めて使用する場合，次のリソースアダプタは使用できません。

XATransactionに設定したリソースアダプタ

ネイティブライブラリを含むリソースアダプタ

起動順序の制御が必要なリソースアダプタ

アプリケーションサーバ独自の機能を使用しているリソースアダプタ

アプリケーションサーバが提供するリソースアダプタの使用方法を次の表に示します。

表3‒7　アプリケーションサーバが提供するリソースアダプタの使用方法

リソースアダプタ

使用方法

リソースアダプタをJ2EEリソースアダプタとしてデプロイして使用する

リソースアダプタをJ2EEアプリケーションに含めて使用する

DB Connector

NoTransactionまたはLocalTransactionに設定

○

○

XATransactionに設定

○

−

TP1 Connector

NoTransactionまたはLocalTransactionに設定

○

○

XATransactionに設定

○

−

TP1/Message Queue - Access

○

−

Reliable Messaging

Reliable Messaging（データベースなし）

○

−

Reliable Messaging（データベースあり）

○

−

DB Connector for Reliable Messaging

○

−

TP1インバウンドアダプタ

○

−

CJMSPリソースアダプタ

○

−

（凡例）　○：使用できる　−：該当しない

使用できないリソースアダプタに対して次の操作をすると，エラーメッセージが出力されて，操作に失敗します。

J2EEアプリケーションに含めてインポートする

J2EEアプリケーションに含めて接続テストまたは開始する

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

ここでは，次のリソースアダプタの機能について説明します。

DB Connector

DB Connector for Reliable Messaging

TP1インバウンドアダプタ

CJMSPリソースアダプタ

そのほかのConnector 1.5仕様に準拠したリソースアダプタ

なお，これ以外のリソースアダプタの機能については，使用するリソースアダプタのドキュメントを参照してください。

使用できる機能をリソースアダプタの種類ごとに次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。

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

機能

リソースアダプタの種類

参照先

DB Connector

DB Connector for Reliable Messaging

TP1インバウンドアダプタ

CJMSPリソースアダプタ

そのほかのConnector 1.5仕様に準拠したリソースアダプタ※1

コネクションプーリング

○

○

−

○

○

3.14.1

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

○

○

−

○

○

3.14.2

コネクション数調節機能

○

○

−

○

○

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

○

○

−

×

○

3.14.3

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

○

○

−

×

○

3.14.4

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

○

○

−

×

×

3.14.7

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

○

○

−

×

×

3.14.8

コネクションの障害検知

○

○

−

×

○

3.15.1

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

○

○

−

○

○

3.15.2

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

○

○

−

○

○

3.15.3

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

○

○

−

○

×

3.15.4

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

○

○

−

○

○

3.15.5

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

○

○

−

×

○

3.15.6

コネクションスイーパ

○

○

−

○

○

3.15.7

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

○

○

−

×

○

3.15.8

障害調査用SQLの出力

◎

◎

−

×

×

3.15.10

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

○

○

−

×

×

3.15.11

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

×

×

○

○

○

3.16.1

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

×

×

○

○

○

3.16.2

メッセージインフロー

×

×

○

○

○

3.16.3

トランザクションインフロー

×

×

○

×

×

3.16.4

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

×

×

−

○

○

3.16.5

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

×

×

−

○

○

3.16.6

リソースへの接続テスト

○

○

−

○

○

3.17

J2EEリソースへの別名付与

○

○

−

○

○

2.6

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

○

○

−

−

−

※2

（凡例）　◎：必ず有効になる　○：使用できる　×：使用できない　−：該当しない

注※1　この表で示しているのはアプリケーションサーバが提供する機能が使用できるかどうかです。リソースアダプタが提供する機能については，使用するリソースアダプタのドキュメントを参照してください。

注※2　マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.6　性能解析トレース」を参照してください。

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

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

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

表3‒9　リソースアダプタ以外の機能

機能

参照先

ライトトランザクション

3.14.5

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

3.14.6

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

3.15.8

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

3.15.9

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

アプリケーションからリソースに接続するには，Enterprise Beanやサーブレットでリソースへの参照を取得する必要があります。リソースへの参照を取得する方法として，ルックアップを使用する方法とDI（Dependency Injection）を使用する方法があります。

なお，EJB 3.0以降を使用する場合，DIを使用してリソースへの参照を取得してください。

(1)　ルックアップを使用してリソースへの参照を取得する方法

ルックアップを使用する場合，次の手順でアプリケーションからリソースに接続します。

リソースに接続するコネクションを取得するためのファクトリクラスを，JNDIを使用してルックアップします。

ルックアップする名前は，Enterprise BeanやサーブレットのDDで指定します。該当するタグは<resource-ref>タグ中の<res-ref-name>タグです。

コネクションのファクトリクラスを使用して，コネクションを取得します。

取得したコネクションを使用して，リソースに接続します。

使用済みのコネクションをクローズします。

コネクションプーリングを使用している場合は，手順2.でプーリングされているコネクションが取得され，手順4.でコネクションがプールに返却されます。ユーザプログラムでコネクションプーリングを意識したコーディングは必要ありません。

(2)　DIを使用してリソースへの参照を取得する方法

DIを使用してリソースへの参照を取得する場合，DDの定義は不要となります。DIの概要およびDI使用時の注意事項については，「17.4　DIの使用」を参照してください。

(3)　リソースへの接続を実装する場合の注意事項

ユーザプログラムでリソースへのコネクションを取得する場合の注意事項を次に示します。

使用後には必ずクローズしてください。具体的には，例外などが発生した場合にも必ずクローズするように，finally節でコネクションをクローズしてください。なお，finalizeメソッドが呼ばれるタイミングはJavaVMのGCのタイミングに依存するので，finalizeメソッドでコネクションをクローズする設計にはしないでください。ユーザプログラムでコネクションが正しくクローズされない場合，取得できるコネクションの最大数に達してしまい，それ以上のコネクションが取得できなくなるおそれがあります。

ほかのJ2EEコンポーネントで取得したコネクションを利用しないでください。J2EEコンポーネントにわたってコネクションを渡した場合の動作は保証しません。ほかのJ2EEコンポーネントと同一コネクションを使用したい場合は，コネクションシェアリングを使用して，そのJ2EEコンポーネント内でコネクションを取得してください。

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

リソースアダプタの設定方法には，次の二つの方法があります。

J2EEリソースアダプタとしてデプロイして設定する方法

リソースアダプタを，直接J2EEサーバにデプロイして設定する方法です。

J2EEアプリケーションに含めて設定する方法

J2EEアプリケーションに含めて使用するリソースアダプタに対して設定する方法です。

参考

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

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

注意事項

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

3.3.8　リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）

ここでは，リソースアダプタをJ2EEリソースアダプタとしてデプロイして使用する場合の，次の流れについて説明します。

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

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

リソースアダプタの入れ替えの流れ

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

(1)　リソースアダプタの新規設定の流れ

データベースやほかのリソースに接続する場合のリソースアダプタの新規設定の流れを次の図に示します。

図3‒2　リソースアダプタの新規設定の流れ

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

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

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

DB Connectorを使用してデータベースに接続する場合と，ほかのリソースアダプタを使用してOpenTP1などの各種リソースに接続する場合では，インポートするRARファイルが異なります。インポートするリソースアダプタについては，「3.3.2　リソースアダプタの種類」を参照してください。

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

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

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

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

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

使用する機能ごとに設定するリソースアダプタのプロパティについては，それぞれ次の個所を参照してください。

リソース接続とトランザクション管理機能を使用するための設定

「3.4.12　実行環境での設定」

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

「3.14.10　実行環境での設定」

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

「3.15.13　実行環境での設定」

J2EEリソースの別名の設定

「2.6.6　J2EEリソースの別名の設定」

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

cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。リソースごとの接続テストでの検証内容については，「3.17　リソースへの接続テスト」を参照してください。

注意事項

DB Connector for Reliable MessagingとReliable Messagingを使用してデータベースに接続する場合の接続テストには次のような順序があります。

DB Connector for Reliable Messagingを開始します。

Reliable Messagingの接続テストを実施します。

Reliable Messagingを開始します。

DB Connector for Reliable Messagingの接続テストを実施します。

DB Connector for Reliable Messagingの場合の，J2EEリソースアダプタの接続テストについては，マニュアル「Reliable Messaging」の「2.7　DB Connector for Reliable Messagingの機能」を参照してください。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.4　J2EEサーバで使用するリソース操作コマンド」を参照してください。属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

注意事項

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションのプロパティを定義するときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

参考

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

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

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

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

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

(2)　リソースアダプタの設定変更の流れ

デプロイ済みのリソースアダプタの設定を変更する場合の流れについて説明します。設定変更の流れを次の図に示します。

図3‒3　リソースアダプタの設定変更の流れ

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

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

cjstoprarコマンドを使用してリソースアダプタを停止します。なお，リソースアダプタを停止する前に，そのリソースアダプタを使用しているJ2EEアプリケーションをすべて停止してください。

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

リソースアダプタはデプロイ済みであるため，cjgetrarpropコマンドを使用して属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。

(3)　リソースアダプタの入れ替えの流れ

リソースアダプタを入れ替える場合の流れについて説明します。リソースアダプタの入れ替えの流れを次の図に示します。

図3‒4　リソースアダプタの入れ替えの流れ

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

J2EEサーバを停止します。

cjstopsvコマンドを使用してJ2EEサーバを停止します。

リソースアダプタを入れ替えます。

cjrarupdateコマンドを使用して，リソースアダプタを入れ替えます。

J2EEサーバを起動します。

cjstartsvコマンドを使用してJ2EEサーバを起動します。

cjrarupdateコマンドを使用しないでリソースアダプタを入れ替えることもできます。cjrarupdateコマンドを使用しないでリソースアダプタを入れ替えるときの流れを次の図に示します。

図3‒5　リソースアダプタの入れ替えの流れ（cjrarupdateコマンドを使用しない場合）

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

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

cjstoprarコマンドを使用して入れ替えるリソースアダプタを停止します。なお，リソースアダプタを停止する前に，そのリソースアダプタを使用しているJ2EEアプリケーションをすべて停止してください。

J2EEサーバを再起動します。

cjstopsvコマンドを使用してJ2EEサーバを停止し，cjstartsvコマンドを使用してJ2EEサーバを起動します。

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

リソースアダプタのプロパティ定義を引き継ぐ場合は，cjgetrarpropコマンド，またはcjgetrespropコマンドを使用して，リソースアダプタのConnector属性ファイルを取得します。

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

cjundeployrarコマンドを使用して，入れ替えるリソースアダプタをアンデプロイします。

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

cjdeleteresコマンドを使用して，入れ替えるリソースアダプタを削除します。

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

「(1)　リソースアダプタの新規設定の流れ」に従って，リソースアダプタを設定します。リソースアダプタのプロパティ定義を引き継ぐ場合は，3.で取得したConnector属性ファイルを使用します。

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

cjstartrarコマンドを使用してリソースアダプタを開始します。なお，リソースアダプタを開始したあとに，リソースアダプタを使用するJ2EEアプリケーションを開始してください。

3.3.9　リソースアダプタの設定の流れ（J2EEアプリケーションに含めて使用する場合）

リソースアダプタの設定には，サーバ管理コマンドを使用します。ここでは，リソースアダプタをJ2EEアプリケーションに含めて使用する場合のリソースアダプタの設定の流れについて説明します。

なお，リソースアダプタをアプリケーションに含めて使用する場合のリソースアダプタの設定方法には，次の二つの方法があります。

リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする方法

J2EEサーバにインポート済みのJ2EEアプリケーションにリソースアダプタを追加する方法

ここでは，それぞれの方法について説明します。

なお，J2EEアプリケーションに含められるリソースアダプタには，制限があります。J2EEアプリケーションに含められるリソースアダプタについては，「3.3.3　リソースアダプタの使用方法」を参照してください。

(1)　リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする方法

リソースアダプタのRARファイルを含めてJ2EEアプリケーションを作成して，そのEARファイルをJ2EEサーバにインポートする方法です。この方法の概要を次の図に示します。

図3‒6　リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする方法の概要

リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする流れを次の図に示します。

図3‒7　リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする流れ

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

サーバ管理コマンドを使用してリソースアダプタのRARファイルをJ2EEアプリケーションのEARファイルに追加します。

cjaddappコマンドを使用して，リソースアダプタのRARファイルをJ2EEアプリケーションのEARファイルに追加します。

EARファイルに含められるリソースアダプタには，制限があります。EARファイルに含められるリソースアダプタについては，「3.3.3　リソースアダプタの使用方法」を参照してください。

サーバ管理コマンドを使用してJ2EEアプリケーションをインポートします。

cjimportappコマンドを使用して，J2EEアプリケーションをインポートします。

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

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

使用する機能ごとに設定するリソースアダプタのプロパティについては，それぞれ次の個所を参照してください。

リソース接続とトランザクション管理機能を使用するための設定

「3.4.12　実行環境での設定」

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

「3.14.10　実行環境での設定」

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

「3.15.13　実行環境での設定」

J2EEリソースの別名の設定

「2.6.6　J2EEリソースの別名の設定」

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

cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。リソースごとの接続テストでの検証内容については，「3.17　リソースへの接続テスト」を参照してください。

(2)　インポート済みのJ2EEアプリケーションにリソースアダプタを追加する方法

リソースアダプタ（RARファイル）をJ2EEサーバにインポートしてから，同じJ2EEサーバにインポート済みのJ2EEアプリケーションにリソースアダプタを追加する方法です。この方法の概要を次の図に示します。

図3‒8　インポート済みのJ2EEアプリケーションにリソースアダプタを追加する方法の概要

インポート済みのJ2EEアプリケーションにリソースアダプタを追加する流れを次の図に示します。

図3‒9　インポート済みのJ2EEアプリケーションにリソースアダプタを追加する流れ

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

サーバ管理コマンドを使用してJ2EEアプリケーションをインポートします。

cjimportappコマンドを使用して，J2EEアプリケーションをインポートします。

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

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

サーバ管理コマンドを使用してリソースアダプタをJ2EEアプリケーションに追加します。

cjaddappコマンドを使用して，リソースアダプタをJ2EEアプリケーションに追加します。

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

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

使用する機能ごとに設定するリソースアダプタのプロパティについては，それぞれ次の個所を参照してください。

リソース接続とトランザクション管理機能を使用するための設定

「3.4.12　実行環境での設定」

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

「3.14.10　実行環境での設定」

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

「3.15.13　実行環境での設定」

J2EEリソースの別名の設定

「2.6.6　J2EEリソースの別名の設定」

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

cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。リソースごとの接続テストでの検証内容については，「3.17　リソースへの接続テスト」を参照してください。

3.3.10　リソースアダプタの設定の流れ（Inboundで使用する場合）

ここでは，メッセージインフローを実行する場合のリソースアダプタとJ2EEアプリケーションの設定の流れについて説明します。設定の流れは，リソースアダプタをJ2EEサーバに直接デプロイして使用するか，J2EEアプリケーションに含めて使用するかによって異なります。

(1)　リソースアダプタをJ2EEサーバに直接デプロイして使用する場合

リソースアダプタをJ2EEサーバに直接デプロイして使用する場合の設定の流れを次の図に示します。

図3‒10　リソースアダプタをJ2EEサーバに直接デプロイして使用する場合の設定の流れ

図中の1.〜5.について説明します。ここでは，サーバ管理コマンドによる操作を示します。

Connector 1.5仕様に準拠したリソースアダプタをインポートします。

cjimportresコマンドに-type rarを指定して実行します。

リソースアダプタをデプロイします。

cjdeployrarコマンドを実行します。

リソースアダプタのプロパティを定義します。

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

ここでは，管理対象オブジェクトを設定します。設定内容については，「3.16.8(2)　管理対象オブジェクトの設定」を参照してください。

Message-driven Beanを含むJ2EEアプリケーションをインポートします。

cjimportappコマンドを使用します。

J2EEアプリケーションのプロパティを定義します。

cjgetapppropコマンドに-type allを指定して実行し，アプリケーション統合属性ファイルを取得します。ファイル編集後に，cjsetapppropコマンドに-type allを指定して実行し，編集内容を反映させます。

ここでは，次の項目を設定します。

Message-driven Beanとリソースアダプタの対応づけ

設定内容については「3.16.8(3)　Message-driven Beanとリソースアダプタの対応づけの設定」を参照してください。

Message-driven Beanが使用するインタフェース

設定内容については「3.16.8(4)　Message-driven Beanが使用するインタフェースの設定」を参照してください。

ActivationSpecの設定

設定内容については「3.16.8(5)　ActivationSpecの設定」を参照してください。

(2)　リソースアダプタをJ2EEアプリケーションに含めて使用する場合

リソースアダプタをJ2EEアプリケーションに含めて使用する場合の設定の流れを次の図に示します。

図3‒11　リソースアダプタをJ2EEアプリケーションに含めて使用する場合の設定の流れ

図中の1.〜2.について説明します。なお，ここでは，サーバ管理コマンドによる操作を示します。

Message-driven Beanを含むJ2EEアプリケーションをインポートします。

cjimportappコマンドを使用します。

J2EEアプリケーションのプロパティを定義します。

cjgetapppropコマンドに-type allを指定して実行し，アプリケーション統合属性ファイルを取得します。ファイル編集後に，cjsetapppropコマンドに-type allを指定して実行し，編集内容を反映させます。

ここでは，次の項目を設定します。

管理対象オブジェクトの情報

設定内容については「3.16.8(2)　管理対象オブジェクトの設定」を参照してください。

Message-driven Beanとリソースアダプタの対応づけ

設定内容については「3.16.8(3)　Message-driven Beanとリソースアダプタの対応づけの設定」を参照してください。

Message-driven Beanが使用するインタフェース

設定内容については「3.16.8(4)　Message-driven Beanが使用するインタフェースの設定」を参照してください。

ActivationSpecの設定

設定内容については「3.16.8(5)　ActivationSpecの設定」を参照してください。

3.3.11　リソースアダプタ以外を使用する接続の設定

リソースアダプタ以外の，JavaBeansリソースやJavaMailを使用する場合の設定については，それぞれ次の個所を参照してください。

JavaBeansリソースを使用する場合

「3.12.4　JavaBeansリソースの設定」を参照してください。

JavaMailを使用する場合

メールコンフィグレーションはSMTPサーバとの接続だけで使用します。

メールの受信にはPOP3サーバを利用します。IMAPサーバは利用できません。

詳細は「3.11　SMTPサーバとの接続」を参照してください。

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

ここでは，リソースアダプタについての注意事項を説明します。

デプロイ方法によって使用できない機能

リソースアダプタをJ2EEアプリケーションに含めて使用する場合，J2EEアプリケーションに含めたリソースが更新されても，次の機能は有効になりません。

J2EEアプリケーションの更新検知

J2EEアプリケーションのリロード

詳細は，「18.8.13　リロードの注意事項および制限事項」を参照してください。

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

J2EEアプリケーション内のEJBやWARは，J2EEリソースアダプタとしてデプロイするリソースアダプタ，およびJ2EEアプリケーションに含めて使用するリソースアダプタを同時に使用できます。ただし，一つのJ2EEサーバで同じ表示名のリソースアダプタを二つ以上使用することはできません。一つのJ2EEサーバに同じ表示名のリソースアダプタを二つ以上使用しようとすると，エラーメッセージが出力されて，リソースアダプタの開始に失敗します。リソースアダプタの開始に失敗する手順の例を次に示します。

例1.

「Rar1」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

「Rar1」という表示名のリソースアダプタを含めたJ2EEアプリケーションをインポートする。

例2.

「Rar2」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

「Rar2」という表示名のリソースアダプタを，インポート済みのJ2EEアプリケーションに追加する。

例3.

「Rar3」という表示名のリソースアダプタを含めたJ2EEアプリケーションをインポートする。

「Rar3」という表示名のリソースアダプタをJ2EEサーバにデプロイする。

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

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

リソースアダプタの開始処理についての注意事項

J2EEサーバの起動途中でリソースアダプタが開始処理に失敗した場合，開始状態から停止状態に遷移します。この場合，J2EEサーバの次回起動時にも開始されません。また，該当のリソースアダプタを使用しているアプリケーションの開始に失敗します。

このような場合は，エラー情報を参照してエラーの原因を取り除いたあとに，次の対処をしてください。

リソースアダプタのトランザクションサポートレベルがLocalTransactionまたはNoTransactionの場合

停止状態に遷移したリソースアダプタを開始してください。

リソースアダプタを使用しているアプリケーションを開始してください。

リソースアダプタのトランザクションサポートレベルがXATransactionの場合

停止状態に遷移したリソースアダプタを開始してください。

未決着トランザクションをリカバリするため，J2EEサーバを再起動してください。

リソースアダプタを使用しているアプリケーションを開始してください。

そのほかの注意事項

URLコネクションのResource Factoryの参照機能は未サポートです。

3.4　トランザクション管理

この節では，トランザクション管理の概要について説明します。

リソース接続時のトランザクションを管理する方法には，アプリケーションサーバで管理する方法と，ユーザが直接管理する方法があります。

アプリケーションサーバでトランザクションを管理する場合，アプリケーションサーバのトランザクションマネージャを使用してトランザクションを管理できます。

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

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

分類

タイトル

参照先

解説

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

3.4.1

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

3.4.2

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

3.4.3

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

3.4.4

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

3.4.5

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

3.4.6

実装※

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

3.4.7

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

3.4.8

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

3.4.9

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

3.4.10

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

3.4.11

設定

実行環境での設定

3.4.12

注　「運用」について，この機能固有の説明はありません。

注※　EJBクライアントでのトランザクションの実装方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.5　EJBクライアントアプリケーションでのトランザクションの実装」を参照してください。

ポイント

リソースのうち，SMTPサーバおよびJavaBeansリソースについては，トランザクション管理の対象外です。

参考

EJBクライアントアプリケーションでもトランザクションを開始できます。EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項については，「3.19　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」を参照してください。

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

リソース接続でのトランザクションの管理方法には，アプリケーションサーバが管理する方法と，アプリケーションサーバが管理しない方法（ユーザが直接管理する方法）があります。ここでは，それぞれのトランザクションの管理方法について説明します。

(1)　アプリケーションサーバが管理するトランザクション

アプリケーションサーバのトランザクションマネージャ経由でトランザクションを管理する方法です。ユーザは，javax.transaction.UserTransactionインタフェースのAPIを操作するか，EJBメソッドのCMT属性を設定することで，トランザクションを管理します。

UserTransactionインタフェースによる管理

サーブレット，JSP，またはEJB（BMT）から，javax.transaction.UserTransactionインタフェースのAPIを発行することで，トランザクションを管理できます。BMTの詳細については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.2　BMT」を参照してください。

EJBのCMT属性による管理

EJB（CMT）のメソッド単位で指定するトランザクション属性によって，トランザクションを管理できます。CMTの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.7.3　CMT」を参照してください。

アプリケーションサーバがトランザクションを管理する場合，トランザクションの種類としてローカルトランザクションまたはグローバルトランザクションを選択できます。アプリケーションサーバが管理するトランザクションの種類については，「3.4.2　ローカルトランザクションとグローバルトランザクション」を参照してください。

(2)　ユーザが直接管理するトランザクション（アプリケーションサーバが管理しないトランザクション）

リソース固有のAPIによって，ユーザが直接トランザクションを管理する方法です。例えば，データベースにJDBCインタフェースで接続する場合，java.sql.ConnectionインタフェースのsetAutoCommit()，commit()，rollback()などのAPIをユーザが直接操作します。

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

アプリケーションサーバが管理するトランザクションを使用する場合，アプリケーションサーバのトランザクションマネージャと，リソースを管理するリソースマネジャ（DBMSなど）が連携して，トランザクションを管理します。この場合，トランザクションの種類として，ローカルトランザクションとグローバルトランザクションのどちらかを選択します。

ローカルトランザクションと，グローバルトランザクションについて説明します。

(1)　ローカルトランザクション

トランザクション管理を行うリソースが一つだけの場合に，ローカルトランザクションを使用します。ローカルトランザクションを使用する場合，トランザクションの決着はリソースマネジャが行います。

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

トランザクション管理を行うリソースが複数ある場合に，グローバルトランザクションを使用します。グローバルトランザクションを使用する場合，トランザクションマネージャが複数のリソースのトランザクションを調整し，整合性が崩れないように決着します。トランザクションの決着には，2フェーズコミットプロトコルが使用されます。なお，グローバルトランザクション使用時には，インプロセストランザクションサービスを使用します。インプロセストランザクションサービスについては，「3.14.6　インプロセストランザクションサービス」を参照してください。

グローバルトランザクションには比較的高い処理コストが掛かりますので，トランザクション管理を行うリソースが一つだけの場合には，ローカルトランザクションを使用することをお勧めします。

なお，デフォルトではライトトランザクション機能※が有効になっているため，グローバルトランザクションを使用することはできません。グローバルトランザクションを使用するには，ライトトランザクション機能を無効にする必要があります。

注※

ライトトランザクションの詳細については，「3.14.5　ライトトランザクション」を参照してください。

(3)　ライトトランザクション機能とトランザクションの管理方法の関係

ライトトランザクション機能とは，ローカルトランザクションに，最適化された環境を提供する機能です。

トランザクションの管理方法とライトトランザクションの対応を次の表に示します。

表3‒11　トランザクションの管理方法とライトトランザクションの対応

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

ライトトランザクション有効

ライトトランザクション無効

アプリケーションサーバが管理するトランザクション

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

○

○

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

×

○

アプリケーションサーバが管理しないトランザクション

○

○

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

ライトトランザクション機能については，「3.14.5　ライトトランザクション」を参照してください。

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

ここでは，次に示すリソースごとに使用できるトランザクションの種類について説明します。

データベース（接続方法：DB Connector）

データベース上のキュー（接続方法：DB Connector for Reliable MessagingとReliable Messaging）

OpenTP1（Outboundでの接続）（接続方法：TP1 ConnectorまたはTP1/Message Queue - Access）

OpenTP1（Inboundでの接続）（接続方法：TP1インバウンドアダプタ）

CJMSPブローカー（接続方法：CJMSPリソースアダプタ）

そのほかのリソース（接続方法：Connector 1.5仕様に準拠したリソースアダプタ）

それぞれのリソースで使用できるトランザクションの種類は，次の項目の設定内容によって決まります。

リソースアダプタ単位で設定するトランザクションサポートレベル

次に示す3種類のトランザクションサポートレベルごとに，使用できるトランザクションの種類が異なります。

NoTransaction

リソースをトランザクション管理しません。

LocalTransaction

リソースをローカルトランザクションでトランザクション管理します。

XATransaction

リソースをグローバルトランザクションでトランザクション管理します。

なお，トランザクションサポートレベルの設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，「3.4.12　実行環境での設定」を参照してください。

ライトトランザクション機能の有効／無効

ライトトランザクション機能を有効にしているか無効にしているかによって，使用できるトランザクションの種類が異なります。

(1)　データベース接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表3‒12　使用できるトランザクションの種類（データベース接続の場合）

接続方法

トランザクションサポートレベル

ライトトランザクション機能

有効

無効

DB Connector（DBConnector_HiRDB_Type4_CP.rar）

（DBConnector_Oracle_CP.rar）

（DBConnector_SQLServer_CP.rar）

NoTransaction

なし

なし

LocalTransaction

ローカル

ローカル

DB Connector（DBConnector_HiRDB_Type4_XA.rar）

（DBConnector_Oracle_XA.rar）

XATransaction

−

グローバル

（凡例）

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

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

なし：トランザクション管理なし

−：指定できない

(2)　データベース上のキューとの接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表3‒13　使用できるトランザクションの種類（データベース上のキューとの接続の場合）

接続方法

トランザクションサポートレベル

ライトトランザクション機能

有効

無効

DB Connector for Reliable MessagingとReliable Messaging

（DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar）

（DBConnector_Oracle_CP_Cosminexus_RM.rar）

NoTransaction

なし

なし

LocalTransaction

ローカル

ローカル

DB Connector for Reliable MessagingとReliable Messaging

（DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar）

（DBConnector_Oracle_XA_Cosminexus_RM.rar）

XATransaction

−

グローバル

（凡例）

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

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

なし：トランザクション管理なし

−：指定できない

(3)　OpenTP1接続の場合（Outboundでの接続）

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表3‒14　使用できるトランザクションの種類（OpenTP1接続の場合（Outboundでの接続））

接続方法

トランザクションサポートレベル

ライトトランザクション機能

有効

無効

TP1 Connector

NoTransaction

なし

なし

LocalTransaction

ローカル

ローカル

XATransaction

−

グローバル

TP1/Message Queue - Access

NoTransaction

なし

なし

LocalTransaction

ローカル

ローカル

XATransaction

−

グローバル

（凡例）

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

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

なし：トランザクション管理なし

−：指定できない

(4)　OpenTP1接続の場合（Inboundでの接続）

TP1インバウンドアダプタで使用できるトランザクションの種類については，「3.13.2　そのほかのリソースとの接続で使用できる機能」を参照してください。

(5)　CJMSPブローカー接続の場合

接続方法，トランザクションサポートレベルの対応で決定される，トランザクションの種類を次の表に示します。

表3‒15　使用できるトランザクションの種類（CJMSPブローカー接続の場合）

接続方法

トランザクションサポートレベル

ライトトランザクション機能

有効

無効

CJMSPリソースアダプタ

NoTransaction

なし

なし

LocalTransaction

ローカル

ローカル

XATransaction

−

−

（凡例）

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

なし：トランザクション管理なし

−：指定できない

(6)　そのほかのリソースの場合

Connector 1.5仕様に準拠したリソースアダプタで使用できるトランザクションの種類については，「3.13.2　そのほかのリソースとの接続で使用できる機能」を参照してください。

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

トランザクションサービスでは，次に示す機能を提供します。なお，アプリケーションサーバでは，トランザクションサービスはJ2EEサーバのインプロセスで起動します。

グローバルトランザクションの開始，コミット決着，ロールバック決着の制御

2フェーズコミットプロトコルによってトランザクション処理を制御します。2フェーズコミットプロトコルとは，同期点での処理をプリペア処理（資源のアップデート準備）とコミット処理（資源のアップデート処理）という2段階に分ける方法です。2フェーズコミットプロトコルでは，DBMSなどの複数のリソースオブジェクトに対して同期を取り，コミットまたはロールバックができます。また，2フェーズコミットプロトコルではトランザクション処理中に障害が発生した場合でも，すべてのリソースオブジェクトを矛盾なく自動的にロールバックできます。

トランザクションコンテキストの伝播（RMI-IIOPによるEnterprise Bean呼び出し）

グローバルトランザクションの状態を表すトランザクションコンテキストを管理します。例えば，サーブレット/JSPなどのクライアントがリモートのEnterprise Beanのメソッドを呼び出したとき，クライアント側のトランザクションコンテキストをサーバ側のEnterprise Beanに伝達します。

ステータスファイルを使用したトランザクション情報の管理と障害発生後のJ2EEサーバの再起動によるシステム回復

システム障害でJ2EEサーバが停止したときに実行中だったアプリケーションプログラムのトランザクション処理を回復して，ロールバックまたはコミットします。トランザクションをロールバックするか，コミットするかは，トランザクション処理がどこまで進んでいたかで決まります。トランザクション処理が，2フェーズコミットのうち，1フェーズ目の完了前まで進んでいる場合には，グローバルトランザクションをロールバックします。2フェーズコミットのうちの1フェーズ目が完了している場合には，ルートトランザクションブランチでの決定に従って，グローバルトランザクションをロールバック，またはコミットします。

ステータスファイルの二重化

ステータスファイルの二重化の機能を使用した場合，一方のステータスファイルが配置されているディスクで障害が発生すると，他方のステータスファイルでトランザクション回復処理が実行されます※。ただし，この機能を利用すると，二重にディスクアクセスするため，オンライン処理の応答時間は遅くなります。

注※

オンライン処理は継続できません。

リソースマネジャでのヒューリスティック決着時のエラー通知

データベースなどのリソースマネジャでのヒューリスティック決着を検知したとき，メッセージによってエラーを通知します。

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

EJB呼び出し時に，呼び出し先でシステム例外が発生したときの呼び出し元のトランザクションの挙動は，システム定義によって次のように変わります。

(1)　呼び出し元のトランザクションを呼び出し先が引き継ぐ場合（呼び出し先のトランザクション属性がCMTのRequired，Supports，Mandatoryの場合）

呼び出し先でシステム例外が戻ってきた場合，トランザクションはコンテナによってロールバックされます。この動作は，EJB仕様で規定されています。

(2)　呼び出し元のトランザクションを呼び出し先が引き継がない場合（呼び出し先のトランザクション属性がBMT，またはCMTのNotSupported，RequiresNew，Neverの場合）

呼び出し元，呼び出し先のトランザクションは，それぞれ次のように動作します。

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

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

ライトトランザクションが無効の場合：

トランザクションはOTSによってロールバックにマークされます。

ライトトランザクションが有効の場合：

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

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

usrconf.propertiesのejbserver.distributedtx.rollbackClientTxOnSystemExceptionキーの値によって動作が異なります。

trueの場合：

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

falseの場合：

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

EJBのローカルインタフェース呼び出し時

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

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

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

なお，ローカル呼び出しの最適化については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.13.1　EJBのリモートインタフェースでのローカル呼び出しの最適化」を参照してください。

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

トランザクションマネージャ（javax.transaction.TransactionManagerまたはjavax.transaction.Transaction）は，トランザクションを管理するためのAPIを提供します。トランザクションマネージャのAPIを使用するフレームワークを使用する場合は，JNDIを使用してトランザクションマネージャを取得できます。トランザクションマネージャを取得するには，「java:comp/TransactionManager」の名前でルックアップします。

アプリケーションサーバがサポートするトランザクションマネージャのAPI，およびSynchronizationを使用する場合の注意について説明します。

(1)　サポートするAPI

アプリケーションサーバがサポートするトランザクションマネージャのAPIを次の表に示します。

表3‒16　アプリケーションサーバがサポートするトランザクションマネージャのAPI

インタフェース

メソッド

使用可否

javax.transaction.TransactionManager

begin

○

commit

○

getStatus

○

getTransaction

○

resume

○

rollback

○

setRollbackOnly

○

setTransactionTimeout

○

suspend

○

javax.transaction.Transaction

commit

○

delistResource

−

enlistResource

−

getStatus

○

registerSynchronization

○

rollback

○

setRollbackOnly

○

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

注　使用できないメソッドを使用しようとすると，javax.transaction.SystemExceptionがスローされます。

(2)　トランザクションマネージャを使用する場合の注意事項

ルックアップで取得したトランザクションマネージャを使用する場合，トランザクション管理に含める処理（データベースのコネクションの取得，使用，解放など）は，トランザクションの開始後から決着前，または開始後から中断前および再開後から決着前の範囲内で実装してください。トランザクションの開始前や決着後，中断中に実装された処理はトランザクション管理に含まれません。

トランザクションマネージャを使用してトランザクションを制御するコンポーネントでは，UserTransactionを使用しないでください。

トランザクションマネージャ（javax.transaction.TransactionManager）のbeginメソッドで開始したトランザクションは，beginメソッドの呼び出し前にsetTransactionTimeoutメソッドでタイムアウト時間を指定した場合，指定された時間でタイムアウトします。setTransactionTimeoutメソッドを呼び出していない場合は，簡易構築定義ファイルの論理J2EEサーバのプロパティejbserver.jta.TransactionManager.defaultTimeOutの指定値（デフォルト180秒）でタイムアウトします。

(3)　Synchronizationを使用する場合の注意事項

トランザクション（javax.transaction.Transaction）のregisterSynchronizationメソッドで登録するSynchronization（javax.transaction.Synchronization）のbeforeCompletionメソッド，およびafterCompletionメソッドでは，J2EEサーバが提供するサービスを使用できません。使用できないサービスの例を次に示します。

リソースアクセス

UserTransactionまたはCMTによるトランザクション操作

EJBアクセス

JNDIアクセス

これらのサービスのうちリソースアクセスを行った場合，リソースアクセスでトランザクションマネージャが管理するトランザクションの一部として管理されないため，不整合が発生することがあります。リソースアクセスをする場合は，フレームワークの責任で，フレームワークがリソースに対して直接トランザクションを制御するようにしてください。

上記のような注意事項があるため，ユーザプログラムでSynchronizationを利用することは推奨しません。ユーザプログラムからトランザクション決着のタイミングを利用したい場合には，EJBのjavax.ejb.SessionSynchronizationを使用してください。

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

コンテナ管理のトランザクションを使用すれば，Enterprise Beanのビジネスメソッドが呼ばれる直前に自動的にトランザクションを開始し，ビジネスメソッドの処理が終了した直後に自動的にトランザクションをコミットできます。ユーザプログラムのコーディングとしてトランザクション管理処理をまったく記述する必要がなく，容易にリソースへのアクセスのトランザクションを管理できます。

コンテナ管理のトランザクションを使用する場合のシーケンスを示します。

図3‒12　コンテナ管理のトランザクション使用時のシーケンス

コンテナ管理のトランザクションを使用する場合，次の点に留意して実装してください。

コンテナ管理のトランザクションを使用する場合，Enterprise Beanのメソッドごとにトランザクション属性を指定できます。指定できるのは，Required，RequiresNew，Mandatory，Supports，NotSupported，Neverのどれかです。トランザクションを使用する場合，DDの<transaction-type>タグにContainerを指定し，メソッドごとのトランザクション属性は<trans-attribute>タグに指定します。また，DDを使用しないで，アノテーションで定義することもできます。トランザクション属性の詳細については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.3　CMT」を参照してください。アノテーションについては，マニュアル「アプリケーションサーバ リファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

トランザクションを開始したあとのビジネスメソッドの中でリソースにアクセスした場合には，そのリソースアクセスは自動的にトランザクション管理がされます。

トランザクション開始後に複数のリソースへアクセスする場合は，グローバルトランザクションに対応したリソースアダプタを使用し，リソースアダプタのトランザクションサポートレベルをXATransactionに設定する必要があります。

コンテナ管理のトランザクションを使用する場合，ユーザプログラムのコーディングとしてトランザクション管理のための処理を記述する必要はありません。

コンテナ管理のトランザクションはEnterprise Beanで使用できます。サーブレットおよびJSPでは使用できません。

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

UserTransactionインタフェースを使用すれば，ユーザプログラムからトランザクションマネージャに対して，トランザクションの開始，決着の指示を出すことができます。ユーザプログラムで，トランザクションの細かい制御をしたい場合には，この方法を使用します。

ユーザプログラムからトランザクションマネージャに対して，トランザクションの開始，決着を指示する手順を示します。

UserTransactionオブジェクトを取得します。

UserTransactionオブジェクトを取得するには，次の方法があります。

ネーミングサービスからJNDIを使用して"java:comp/UserTransaction"をルックアップする方法

EJBContextインタフェースのgetUserTransactionメソッドを呼び出して取得する方法

DIを使用して取得する方法

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

リソースにアクセスします。

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

UserTransactionインタフェースを使用する場合のシーケンスを示します。

図3‒13　UserTransactionインタフェース使用時のシーケンス

UserTransactionインタフェースを使用する場合，次の点に留意して実装してください。

UserTransactionインタフェースを使用する場合，DDの<transaction-type>タグにBeanを指定します。また，DDを使用しないで，アノテーションで定義することもできます。アノテーションについては，マニュアル「アプリケーションサーバリファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

トランザクションを開始後にリソースにアクセスした場合には，そのリソースアクセスは自動的にトランザクション管理されます。

トランザクション開始後に複数のリソースへアクセスする場合は，グローバルトランザクションに対応したリソースアダプタを使用し，リソースアダプタのトランザクションサポートレベルをXATransactionに設定する必要があります。

Enterprise Bean，サーブレット，およびJSPで使用できます。

UserTransactionインタフェースを使用して，ユーザプログラムで開始したトランザクションは，例外などが発生した場合にも，ユーザプログラムでcommitまたはrollbackを発行して決着させる必要があります。決着させなかった場合，リソースのロックが解放されない，または次のトランザクションが開始できないなどの問題が発生するおそれがあります。

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

リソース固有のインタフェースを使用して，ユーザプログラムが直接リソースのトランザクションを制御することもできます。例えば，DB Connectorであれば，ConnectionインタフェースのsetAutoCommitメソッド，commitメソッド，およびrollbackメソッドを使用して，ユーザプログラムが直接リソースのトランザクションを制御できます。

リソース固有のトランザクション管理インタフェースを使用する場合のシーケンスを示します。

図3‒14　リソース固有のトランザクション管理インタフェース使用時のシーケンス

リソース固有のトランザクション管理インタフェースを使用する場合，次の点に留意して実装してください。

トランザクションマネージャが提供するトランザクションタイムアウトなどの機能は使用できません。

複数のリソースへのアクセスをトランザクション管理することはできません。

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

リソースへのアクセスをトランザクション管理しないこともできます。リソースに対して参照しかしない場合などには，トランザクション管理のコストを削減するために，この方法を使用できます。

トランザクションを使用しない場合のシーケンスを示します。

図3‒15　トランザクション未使用時のシーケンス

トランザクションを使用しない場合，次の点に留意して実装してください。

Enterprise BeanのDDの<transaction-type>タグにContainerを指定して，<trans-attribute>タグにNotSupported，Neverのどちらかを指定すれば，トランザクションは使用されません。また，DDを使用しないで，アノテーションで定義することもできます。トランザクション属性の詳細については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.3　CMT」を参照してください。アノテーションについては，マニュアル「アプリケーションサーバ リファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

Enterprise BeanのDDの<transaction-type>タグにBeanを指定して，UserTransactionオブジェクトのbeginメソッドを呼び出さなければ，トランザクションは使用されません。また，DDを使用しないで，アノテーションで定義することもできます。アノテーションについては，マニュアル「アプリケーションサーバリファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

サーブレットおよびJSPでUserTransactionオブジェクトのbeginメソッドを呼び出さなければ，トランザクションは使用されません。

特定のリソースアダプタへのアクセスだけをトランザクションで管理しないこともできます。これを実現するには，トランザクションで管理しないリソースアダプタのトランザクションサポートレベルをNoTransactionに設定します。トランザクションサポートレベルをNoTransactionに設定したリソースアダプタでは，トランザクション開始後にリソースにアクセスしてもトランザクション管理の対象とはなりません。

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

JTAを使用してトランザクションを実装したプログラムの処理の内容，および動作を次の表に示します。

表3‒17　JTAの動作

処理の内容

動作

EJB呼び出しで，java.rmi.RemoteExceptionまたはjava.rmi.RemoteExceptionを継承した例外が発生した場合

CORBAのシステム例外が発生した場合

クライアント側のトランザクションをロールバックにマークするかしないかは，プロパティ（ejbserver.distributedtx.rollbackClientTxOnSystemException）の設定で変わります。プロパティの設定値とその動作については，「3.4.5　システム例外発生時のトランザクションの動作」を参照してください。

トランザクションタイムアウト発生後に，javax.transaction.UserTransaction.commitメソッドを呼び出した場合

javax.transaction.RollbackException例外が発生します。ただし，トランザクションタイムアウトが発生したあと，2回以上UserTransaction.commitメソッドを呼び出すと，2回目以降はjava.lang.IllegalStateException例外が発生します。

トランザクションタイムアウト発生後にjavax.transaction.UserTransaction.rollbackメソッドを呼び出した場合

例外は発生しません。

トランザクションタイムアウト後のjavax.transaction.UserTransaction.getStatusメソッドの戻り値

javax.transaction.Status.STATUS_ROLLEDBACKが返されます。ただし，UserTransaction.commitメソッド，またはUserTransaction.rollbackメソッドを呼び出したあとは，javax.transaction.Status.STATUS_NO_TRANSACTIONが返されます。

javax.ejb.SessionSynchronizationを実装したEJBのbeforeCompletionメソッド，またはafterCompletionメソッドからのEJB呼び出し

例外が発生することなく，呼び出すことができます。

3.4.12　実行環境での設定

リソース接続とトランザクション管理機能を使用する場合，J2EEサーバ，およびリソースアダプタの設定が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。リソース接続とトランザクション管理の機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの設定を次の表に示します。なお，トランザクション管理では，トランザクションのタイムアウトも指定できます。

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

トランザクションのタイムアウトについては，「3.15.8　トランザクションタイムアウトとステートメントキャンセル」を参照してください。

表3‒18　簡易構築定義ファイルでのリソース接続とトランザクション管理の機能を使用するための定義

項目

指定するパラメタ

設定内容

トランザクションの種類

ejbserver.distributedtx.XATransaction.enabled

ライトトランザクションを使用するか，グローバルトランザクションを使用するかどうかを指定します。デフォルトの設定では，ライトトランザクションが有効になっています。

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

ejbserver.distributedtx.rollbackClientTxOnSystemException

システム例外が発生したときにクライアントトランザクションをロールバックにマークするかどうかを指定します。

ステータスファイルの格納ディレクトリ

ejbserver.distributedtx.ots.status.directory1

ejbserver.distributedtx.ots.status.directory2

インプロセストランザクションサービスのステータスファイルとステータスファイルのバックアップを格納するディレクトリとして指定します。

障害検知のタイムアウト

ejbserver.connectionpool.validation.timeout

コネクション障害検知機能のタイムアウト時間およびコネクション数調節機能によるコネクション削除処理のタイムアウト時間を指定します。

注意事項

インプロセストランザクションサービスのステータスファイルとステータスファイルのバックアップを格納するディレクトリの指定について

インプロセストランザクションサービスでは，トランザクションの整合性を保証するため，ホスト名またはIPアドレスをJ2EEサーバの識別情報としてステータスファイル内に取り込みます。このため，J2EEサーバのコンフィグレーション定義でvbroker.se.iiop_tp.hostパラメタを設定していて値を変更する場合，またはvbroker.se.iiop_tp.hostパラメタを設定しないでJ2EEサーバを起動するマシンのIPアドレスを変更する場合は，次の手順に従ってください。

J2EEサーバ上でトランザクションが存在しない状態で，J2EEサーバを停止してください。

IPアドレス，またはvbroker.se.iiop_tp.hostパラメタの設定を変更してください。

ejbserver.distributedtx.ots.status.directory1パラメタで指定したディレクトリを削除してください。

J2EEサーバを起動してください。

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

実行環境でのリソースアダプタの設定は，サーバ管理コマンドおよび属性ファイルを使用します。トランザクション管理のための機能の定義には，Connector属性ファイルの<resourceadapter>タグに指定します。設定内容について，次の表に示します。

Connector属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

表3‒19　Connector属性ファイルでのトランザクション管理のための機能の定義

項目

指定するタグ

設定内容

トランザクションサポートレベル

<outbound-resourceadapter>−<transaction-support>タグ

トランザクションサポートレベルを設定します。

トランザクション管理なし（NoTransaction），ローカルトランザクション（LocalTransaction），またはグローバルトランザクション（XATransaction）を指定します。

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

リソースへのサインオンの方式として，次のどちらかの方式を選択できます。

コンテナ管理サインオン

アプリケーションサーバで自動的にサインオンする方式です。この方式を使用する場合，リソースアダプタごとにユーザ名とパスワードを設定しておけば，コネクション取得時に，アプリケーションサーバによって自動的にユーザ名とパスワードがリソースに伝達されます。

コンテナ管理サインオンを使用するには，Enterprise BeanやサーブレットのDDの，<resource-ref>タグ中の<res-auth>タグに，Containerを指定してください。

コンポーネント管理サインオン

ユーザプログラムでリソースにサインオンする方式です。この方式を使用する場合，コネクションを取得するときのユーザ名とパスワードをユーザプログラムで指定します。

（例）DB Connectorの場合

DataSourceクラスのgetConnectionを呼び出すときに，引数でユーザ名とパスワードを指定します。

コンポーネント管理サインオンを使用するには，Enterprise BeanやサーブレットのDDの<resource-ref>タグ中の<res-auth>タグに，Applicationを指定してください。

コネクションプーリングを使用する場合は，コネクションを効率良く再利用できるコンテナ管理サインオンの使用をお勧めします。

なお，セットアップウィザードを使用して構築したシステムの場合，ejbserver.connectionpool.applicationAuthentication.disabledにtrueが指定されているため，アプリケーション認証が使えません。

3.6　データベースへの接続

この節では，DB Connectorを使用してデータベースと接続する機能について説明します。

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

表3‒20　この節の構成（データベースへの接続）

分類

タイトル

参照先

解説

DB Connectorによる接続の概要

3.6.1

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

3.6.2

接続できるデータベース

3.6.3

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

3.6.4

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

3.6.5

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

3.6.6

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

3.6.7

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

3.6.8

Amazon RDS for Oracleに接続する場合の条件と設定

3.6.9

HiRDB Cloud Serviceに接続する場合の条件と設定

3.6.10

マネージドデータベースサービスがフェイルオーバーした場合のDB Connectorの動作

3.6.11

設定

実行環境での設定（リソースアダプタでの設定）

3.6.12

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

DB Connectorを使用して接続できるデータベースには，HiRDB，Oracle，SQL Server，XDM/RD E2があります。データベースと接続する場合，接続先のデータベースの種類によって，データベースの接続方法，使用できるJDBCドライバなどが異なります。ここでは，データベース接続の前提条件と，使用できる機能について説明します。

3.6.1　DB Connectorによる接続の概要

データベースと接続する場合，リソースアダプタとしてDB Connectorを使用できます。DB Connectorは，JDBCを利用したデータベースアクセスをするためのリソースアダプタです。DB Connectorは，J2EEアプリケーションからコネクションファクトリ（javax.sql.DataSourceインタフェース）をルックアップして使用します。

DB Connectorによる接続の概要を次の図に示します。

図3‒16　DB Connectorによる接続の概要

DB Connectorでのデータベース接続では，JDBCドライバに，HiRDB Type4 JDBC Driver，Oracle JDBC Thin Driver，またはSQL ServerのJDBCドライバを使用します。

DB Connectorの設定の詳細については，「3.6.12　実行環境での設定（リソースアダプタでの設定）」，およびマニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。

また，データベース上のキューと接続する場合の接続方法については，「3.7　データベース上のキューとの接続」を参照してください。

注意事項

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

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

ここでは，データベース接続で使用できる機能について説明します。

データベース接続で使用できるJ2EEコンポーネントおよび機能を，データベースごとに次の表に示します。

表3‒21　使用できるJ2EEコンポーネントおよび機能

項目

HiRDB

Oracle

SQL Server

XDM/RD E2

J2EEコンポーネント

Servlet/JSP

○

○

○

○

Stateless Session Bean

○

○

○

○

Stateful Session Bean

○

○

○

○

Singleton Session Bean

○

○

○

○

Entity Bean（BMP）

○

○

○

×

Entity Bean（CMP1.1）

○

×

×

×

Entity Bean（CMP2.0）

○※1

×

×

×

Message-driven Bean（onMessageメソッドからのデータベースアクセス）

○

○

○

○

使用できる機能

コネクションプーリング

○

○

○

○

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

○

○

○

○

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

○

○

○

○

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

○

○

○

○

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

○

○

○

○

コネクション数調節機能

○

○

○

○

コネクションスイーパ機能

○

○

○

○

コネクションプールの情報表示（cjlistpoolコマンド）

○

○

○

○

コネクションプールのクリア（cjclearpoolコマンド）

○

○

○

○

リソースへの接続テスト

○

○

○

○

コネクションの障害検知

○

○

○

○

コネクション障害検知のタイムアウト

○

○

○

○

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

○

○

○

○

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

○

○

○

○

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

○

○

○

○

コネクションプールの一時停止

○

○

×

○

コネクションプールの再開

○

○

×

○

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

○※2

○

○

○※2

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

○

○※3

○

○

ステートメントsetQueryTimeoutメソッド

○

○※3

○

×

J2EEリソースのオプショナル名機能

○

○

○

○

クライアントAPIで発生した例外の通知機能

○

○

○

○

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

○

○

×

○

障害調査用SQLの出力

○

○

○

○

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

注※1　CMP2.0の機能である，CMR機能は利用できません。

注※2　HiRDB自動再接続機能とステートメントプーリング機能の併用はできません。

注※3　Oracleに接続する場合の注意事項があります。注意事項については，「3.6.6　Oracleと接続する場合の前提条件と注意事項」を参照してください。

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

ここでは，DB Connectorを使用して接続できるデータベースについて説明します。

(1)　接続できるデータベースの種類

DB Connectorを利用して接続できるデータベースには，HiRDB，Oracle，SQL Server，XDM/RD E2があります。なお，SQL ServerおよびXDM/RD E2ではグローバルトランザクションは使用できません。

(2)　データベースとJDBCドライバの対応

DB Connectorを使用してデータベースに接続するためには，データベースに対応するJDBCドライバが必要です。接続先のデータベースと使用できるJDBCドライバの対応について次の表に示します。

表3‒22　接続先のデータベースと使用できるJDBCドライバ（データベース接続の場合）

データベース

JDBCドライバ

HiRDB Type4 JDBC Driver

Oracle JDBC Thin Driver

SQL ServerのJDBCドライバ

HiRDB

◎

×

×

Oracle

×

◎

×

SQL Server

×

×

○

XDM/RD E2

○

×

×

（凡例）

◎：使用できる。かつ使用を推奨する。

○：使用できる。

×：使用できない。

(3)　DB ConnectorがサポートするJDBC仕様

接続に使用するJDBCドライバとDB ConnectorがサポートするJDBC仕様を次の表に示します。ただし，接続に使用するJDBCドライバが，JDBC仕様で規定された機能をサポートしていない場合は，DB Connectorでその機能を使用できません。

表3‒23　接続に使用するJDBCドライバとDB ConnectorがサポートするJDBC仕様

接続に使用するJDBCドライバ

DB ConnectorがサポートするJDBC仕様

HiRDB Type4 JDBC Driver

JDBC 4.0

Oracle JDBC Thin Driver

JDBC 4.0

SQL Server JDBC Driver

JDBC 4.0

ポイント

Oracle JDBC Thin Driverは，JDBC 4.0の仕様で規定された範囲の機能をサポートしています。Oracleパッケージのクラスおよびインタフェースを使用したOracle拡張機能は使用できません。

また，アプリケーションサーバでOracle JDBC Thin Driverを使用してデータベースと接続する場合，Oracle JDBC Thin Driverの拡張機能である，文キャッシュおよび接続キャッシュ機能を利用することはできません。アプリケーションサーバで提供するステートメントプーリング，またはコネクションプーリングを使用してください。ステートメントプーリングまたはコネクションプーリングについては，「3.14　パフォーマンスチューニングのための機能」を参照してください。

なお，java.sql.Wrapperインタフェースは未サポートです。Wrapperインタフェースのメソッドを使用した場合，UnsupportedOperationException例外がスローされます。

注意事項

JDBC仕様のjava.sql.Statementインタフェースのメソッドのうち，次に示すものは未サポートです。

setCursorName(String name)

setFetchDirection(int direction)

DB Connectorを使用してデータベースに接続する場合，JDBC 4.1およびJDBC 4.2仕様で追加された機能およびインタフェース・メソッドはサポートしません。

try-with-resources文を使用したJDBCリソースの自動解放もサポートしません。従来どおりfinallyブロックで明示的にJDBCリソースをcloseしてください。

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

DB Connectorを使用してデータベースに接続する場合，使用するJDBCドライバに対応したRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。

JDBCドライバの種類と対応するRARファイルについて次の表に示します。

表3‒24　JDBCドライバとRARファイルの対応

JDBCドライバ

RARファイル

説明

HiRDB Type4 JDBC Driver

DBConnector_HiRDB_Type4_CP.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_HiRDB_Type4_XA.rar※

グローバルトランザクションを使用する場合に使用します。

Oracle JDBC Thin Driver

DBConnector_Oracle_CP.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_Oracle_XA.rar※

グローバルトランザクションを使用する場合に使用します。

SQL ServerのJDBCドライバ

DBConnector_SQLServer_CP.rar

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

注※　ライトトランザクション機能は有効にできません。

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

ここでは，HiRDBと接続する場合の前提条件と注意事項について説明します。HiRDBのバージョンによって，使用できるJDBCドライバが異なります。

(1)　前提条件

使用できるJDBCドライバ

使用できるJDBCドライバはHiRDB Type4 JDBC Driverとなります。

接続方法

次のどちらかのRARファイルを使用します。

DBConnector_HiRDB_Type4_CP.rar

DBConnector_HiRDB_Type4_XA.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒25　RARファイルごとに使用できるトランザクションサポートレベル

使用するDB Connector

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_HiRDB_Type4_CP.rar

NoTransaction

LocalTransaction

○

○

DBConnector_HiRDB_Type4_XA.rar

XATransaction

−

○

（凡例）　○：使用できる　　−：該当しない

(2)　HiRDBと接続するときの注意事項

HiRDBと接続する場合の注意を次に示します。

HiRDBの自動再接続機能を使用すると，データベースネットワーク障害などでHiRDBサーバとの接続が切断された場合に，コネクションが自動的に再接続されます。ただし，トランザクション中に接続が切断されると，SQLException例外が発生します。J2EEアプリケーションでSQLException例外を受け取ったときには，処理を続行しないでください。続けてDBMSにアクセスするとデータの不整合などの問題が発生するおそれがあります。

コネクションプール機能とステートメントプーリング機能を有効にして，Statement.cancel()を使用すると，SQLException例外が発生することがあります。この場合，コネクションプール機能，またはステートメントプーリング機能のどちらかを無効にすることをお勧めします。

J2EEアプリケーションが次の条件をすべて満たす場合は，コネクションが二つ使用され，HiRDBへの接続が同時に利用しているユーザ数の2倍になります。HiRDBのシステム共通定義のpd_max_usersオペランドに，同時に利用しているユーザ数の2倍の値を指定してください。pd_max_usersオペランドについては，マニュアル「HiRDB システム定義」を参照してください。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

アプリケーションサーバが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。

注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

J2EEアプリケーションが次の条件をすべて満たす場合は，エラーが発生します。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

アプリケーションサーバが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。

注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

次の条件をすべて満たす場合，同一コネクションを複数の異なるグローバルトランザクションに同時に参加させることはできません。トランザクションごとに使用するコネクションを分けてください。

トランザクションサポートレベルがXATrasactionのDB Connectorを使用する。

アプリケーションサーバが管理するトランザクション内でコネクション※を使ってデータベースにアクセスする。

2.のトランザクションが決着する前に，トランザクション外でコネクション※を使ってデータベースにアクセスする。

注※　このコネクションは1.のDB Connectorから取得したコネクションで，かつ同一コネクションです。

HiRDBのコネクション自動再接続機能およびステートメントプール機能を有効にすると，自動再接続機能によってコネクションが再接続されたあとのSQL実行でメッセージ「KFPA11901-E」を含んだSQLException例外が発生することがあります。トランザクションサポートレベルがLocalTransaction，またはNoTransactionのDB Connectorでステートメントプール機能を有効にしてHiRDBに接続する場合は，HiRDBのコネクション自動再接続機能は使用しないでください。障害が発生した場合は，コネクションの障害検知機能，またはcjclearpoolコマンドを実行してください。

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

ここでは，Oracleと接続する場合の前提条件と注意事項について説明します。

(1)　前提条件

使用できるJDBCドライバ

使用できるJDBCドライバはOracle JDBC Thin Driverとなります。

接続方法

次のどれかのRARファイルを使用します。

DBConnector_Oracle_CP.rar

DBConnector_Oracle_XA.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒26　RARファイルごとに使用できるトランザクションサポートレベル

使用するDB Connector

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_Oracle_CP.rar

NoTransaction

LocalTransaction

○

○

DBConnector_Oracle_XA.rar

XATransaction

−

○

（凡例）　○：使用できる　　−：該当しない

(2)　Oracleと接続する場合の注意事項

ここでは，Oracleに接続する場合の使用時の注意について説明します。

(a)　使用できるJ2EEコンポーネントの違い

Oracle JDBC Thin DriverでOracleに接続する場合に使用できるJ2EEコンポーネントを次に示します。

サーブレット/JSP

Stateless Session Bean

Stateful Session Bean

Entity Bean（BMP）

Message-driven Bean

(b)　日本語文字コード変換の相違点とOracle JDBC Thin Driverでの文字化けを回避するための設定

JDBCドライバでは，データをデータベースに格納するとき，およびデータベースからデータを取り出すときに，Unicodeとデータベース格納コードとの間で適宜，文字コードを変換します。ここでは，Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所を次の図に示します。

図3‒17　Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所

図中の場所ごとに実行される文字コード変換について，次の表に示します。

表3‒27　Oracle JDBC Thin Driverを使用する場合に文字コード変換が実施される場所

場所

実施される内容

1

ネットワーク，ファイルなどの外部データをJ2EEサーバで読み込む時に，外部データコードからUnicodeに変換されます。

2

J2EEサーバで読み込んだデータをOracleサーバに格納する時に，UnicodeからUTF-8に変換されます。J2EEサーバ上のJDBCドライバ部分で実施されるコード変換です。

3

Oracleサーバのコンバータによって，UTF-8からデータベース格納コードへの変換が実施されます。Oracleサーバ上で実施されるコード変換です。

4

Oracleサーバのコンバータによって，データベース格納コードからUTF-8への変換が実施されます。

5

OracleサーバからJ2EEサーバが格納したデータを取得する時に，UTF-8からUnicodeに変換されます。

6

J2EEサーバで取得したデータをネットワークやファイルなどに書き出す時に，Unicodeから外部データコードに変換されます。

Oracle JDBC Thin Driverを使用する場合，JavaVMとOracleサーバのコンバータがサポートしているマッピング規則の相違から，文字化けが発生することがあります。文字化けは，外部データの文字コードとデータベース格納コードの組み合わせや，文字コード変換を行うコンバータの組み合わせによって発生します。

文字化けを回避するためには，外部データの文字コードと，データベース格納コードを，次に示す組み合わせで使用してください。

外部データの文字コードがシフトJIS（CP932）の場合

データベース格納コードに「AL32UTF8」または「JA16SJISTILDE」を指定してください。なお，データベース格納コードに「JA16SJIS」を指定した場合，「〜」の文字で文字化けが発生しますのでご注意ください。

外部データの文字コードがSJISの場合

データベース格納コードに「AL32UTF8」を指定してください。なお，データベース格納コードに「JA16SJIS」を指定した場合，「¢」「£」「¬」「‖」「−」で文字化けが発生しますのでご注意ください。

外部データの文字コードがEUCの場合

データベース格納コードに「AL32UTF8」を指定してください。なお，データベース格納コードに「JA16EUC」を指定した場合，「¢」「£」「¬」で文字化けが発生しますのでご注意ください。

(c)　専用サーバ接続

専用サーバ接続の場合，次の機能は使用できません。次の機能を使用する場合は共有サーバ接続にしてください。詳細については，オラクルのサポートサービスにお問い合わせください。

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

クエリータイムアウト

(d)　JTAトランザクション決着処理中のselect文の戻り値

XAトランザクションでOracleを利用した場合に，JTAトランザクションの決着処理中に，トランザクション内で更新処理を実施した複数のデータベースに対し，Oracleのselect文を発行すると，各select文の戻り値が異なることがあります。これは，Oracleの分散読取り一貫性の制限に起因しています。

(e)　Oracle12c以降のJDBCドライバ使用時の設定

Oracle12c以降のJDBCドライバを使用する場合，以下のプロパティをusrconf.properties（J2EEサーバ用ユーザプロパティファイル）に設定してください。プロパティの詳細については，Oracleのドキュメントを参照してください。

oracle.jdbc.autoCommitSpecCompliant=false

(3)　Oracle RACを使用する場合

(a)　Oracle RACとの接続方法

Oracle RACへの接続は，Oracle用のDB Connectorが使用できます。接続できるトランザクションの種類はローカルトランザクションです。次のDB Connectorが使用できます。

DBConnector_Oracle_CP.rar

DBConnector_Oracle_CP_Cosminexus_RM.rar

負荷分散の設定については，Oracleのマニュアルを参照してください。

(b)　データベース障害発生時と回復時の動作

データベース障害が発生した場合，Oracle RAC機能によって障害が発生したインスタンスが切り離され，残っているインスタンスで処理が続行されます。

アプリケーションサーバのコネクションプールを使用している場合，データベース回復時には次のどちらかの操作を実行してください。コネクションプールがクリアされ，これ以降のアクセスが正常に分散されます。

cjclearpoolコマンドの実行

J2EEサーバの再起動

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

ここでは，SQL Serverと接続する場合の前提条件と注意事項について説明します。

(1)　SQL Serverの場合の前提条件

SQL Serverの場合の前提条件について示します。

使用できるJDBCドライバ

使用できるJDBCドライバはSQL ServerのJDBCドライバとなります。

注

J2EEサーバのユーザクラスパスに複数のSQL Server JDBC DriverのJARファイルを指定することはできません。

接続方法

DBConnector_SQLServer_CP.rarを使用します。使用するRARファイルは，接続するSQL Serverによって異なります。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒28　RARファイルごとに使用できるトランザクションサポートレベル（SQL Server）

使用するDB Connector

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_SQLServer_CP.rar

NoTransaction

LocalTransaction

○

○

（凡例）　○：使用できる

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

(2)　SQL Serverと接続する場合の注意事項

ここでは，SQL Serverに接続する場合の注意事項について説明します。

(a)　システムでの文字コード変換時の注意

SQL Server接続時，データベースに日本語文字コードを含むデータを格納する場合，システムでの文字コード変換について考慮する必要があります。ここでは，システムでの文字コード変換の概要と，文字化けを回避するために設定時に注意することについて説明します。

Javaでは日本語文字コードはUnicodeで表現されます。SQL Serverを使用する場合，Webクライアントとアプリケーションサーバ間，およびアプリケーションサーバとSQL Server間の処理で文字コード変換が実施されます。

SQL Serverを使用する場合の文字コード変換の概要を次の図に示します。

図3‒18　SQL Serverを使用する場合の文字コード変換の概要

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

アプリケーションサーバがWebクライアントからデータを受信する時に，外部文字コードからUnicodeに変換されます。

アプリケーションサーバがデータをSQL Serverに格納する時に，Unicodeからデータベース格納文字コードに変換されます。

SQL Serverに格納されたデータをアプリケーションサーバが取得する時に，データベース格納文字コードからUnicodeに変換されます。

アプリケーションサーバがデータをWebクライアントに送信する時に，Unicodeから外部文字コードに変換されます。

SQL Serverを使用する場合，外部文字コードとデータベース格納文字コードの組み合わせや，文字コード変換を実施する場合に使用されるコンバータの種類によっては，文字化けなどの問題が発生することがあります。このような文字化けを回避するためには，文字コードの設定に注意する必要があります。

SQL Serverでは次の表に示す文字データ型をサポートしています。SQL Serverを使用する場合，Unicodeデータ型を使用することによって，文字コード変換時に発生する文字化けを防ぐことができます。

表3‒29　SQL Serverでサポートする文字データ型

カテゴリ

文字データ型

Unicodeデータ型

nchar，nvarchar，ntext

非Unicode文字データ型

char，varchar，text

次に，SQL Serverでのデータベース格納文字コードとして，Unicodeデータ型を使用する場合と，非Unicodeデータ型を使用する場合の文字コード変換について説明します。

Unicodeデータ型を使用する場合

DB ConnectorのプロパティのsendStringParametersAsUnicodeキーにtrue（デフォルト値）を設定している場合，文字化けは発生しません。falseを設定した場合，外部文字コードにShift_JIS，EUC-JP，ISO-2022-JP，またはUTF-8を使用すると文字化けが発生することがあります。

非Unicode文字データ型を使用する場合

外部文字コードの設定によって，文字化けが発生することがあります。

外部文字コードにWindows-31Jを使用する場合

文字化けは発生しません。

外部文字コードにShift_JIS，EUC-JP，またはISO-2022-JPを使用する場合

次に示す文字などで文字化けが発生します。

外部文字コードにUTF-8を使用する場合

次に示す文字などで文字化けが発生します。

(b)　DB ConnectorのselectMethodプロパティ設定時の注意

DB ConnectorのselectMethodプロパティ（<config-property-name>の項目名）の値に「direct」を設定した場合の注意事項を次の表に示します。

表3‒30　 DB ConnectorのselectMethodプロパティ設定時の注意事項

条件

注意事項

コネクションの障害検知機能が有効

コネクションに障害が発生していても正常であると誤診することがあります。その結果，ユーザアプリケーションプログラムに障害が発生したコネクションを返すことがあるので，コネクションの障害検知機能を使用しないでください。障害が発生したら，cjclearpoolコマンドを実行してください。

Statement，PreparedStatement，CallableStatementを複数同時に生成

SQL ServerのJDBCドライバによって，同時に生成したステートメントごとにSQL Serverへの接続が生成されます。

また，ステートメントプーリング機能を使用する場合には，プールされているステートメントごとに接続が生成され，メモリを多く消費するので注意してください。

(c)　認証モード

SQL Serverの認証モードは，混合モード（Windows認証とSQL Server認証）に設定してください。認証モードの詳細は，SQL Serverのマニュアルを参照してください。

(d)　DB Connectorに設定できないプロパティ

次の設定は，DBConnector_SQLServer_CP.rarでは設定できません。

SQL Server JDBC Driver 2.0で新規に追加された設定

responseBuffering※

encrypt

hostNameCertificate

trustServerCertificate

trustStore

trustStorePassword

SQL Server JDBC Driver 3.0で新規に追加された設定

sendTimeAsDatetime

JDBC Driver 4.0 for SQL Serverで新規に追加された設定

authenticationScheme

JDBC Driver 4.1 for SQL Server以降で新規に追加された設定

新規に追加されたすべての設定

注※

responseBufferingのデフォルト値はadaptiveのため，アダプティブバッファリング機能は常に有効として動作します。詳細は，SQL Serverのマニュアルを参照してください。

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

ここでは，XDM/RD E2と接続する場合の前提条件と注意事項について説明します。

使用できるJDBCドライバ

使用できるJDBCドライバはHiRDB Type4 JDBC Driverとなります。

接続方法

DBConnector_HiRDB_Type4_CP.rarを使用します。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒31　RARファイルごとに使用できるトランザクションサポートレベル（XDM/RD E2）

使用するDB Connector

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_HiRDB_Type4_CP.rar

NoTransaction

LocalTransaction

○

○

（凡例）　○：使用できる

3.6.9　Amazon RDS for Oracleに接続する場合の条件と設定

Amazon RDS for Oracleに接続する場合の条件と設定について説明します。

(1)　Amazon RDS for Oracleに接続するための前提条件

J2EEサーバを推奨モードで使用する場合だけ接続をサポートします。V9互換モードの場合はサポート対象外です。

Amazon RDS for Oracleに接続する場合のサポート条件を次の表に示します。

表3‒32　Amazon RDS for Oracleに接続する場合のサポート条件

項目

条件

接続に使用できるJDBCドライバと接続先のAmazon RDS for OracleのDBMSバージョン

リリースノートの前提ソフトウェアの項目に記載されているAmazon RDS for Oracleに接続する場合の条件に従ってください。

接続に使用するDB Connector

DBConnector_Oracle_CP.rar

注意事項

接続に使用するDB ConnectorであるDBConnector_Oracle_CP.rarでは，グローバルトランザクションを利用できません。

DB Connectorの設定条件を次の表に示します。設定方法については，「（4）アプリケーションサーバの設定」を参照してください。

表3‒33　DB Connectorの設定条件

設定項目

設定条件

コネクションプーリング

有効

障害検知

コネクション取得要求時

(2)　Amazon RDS for Oracleの使用条件

アプリケーションサーバ稼働中のAmazon RDS for Oracleの操作実行可否を次の表に示します。なお，次の表で「Amazon RDS for Oracleの操作」列に存在しない操作についても，アプリケーションサーバの稼働中には実行できません。

表3‒34　アプリケーションサーバ稼働中のAmazon RDS for Oracleの操作実行可否

Amazon RDS for Oracleの操作

アプリケーションサーバ稼働中の操作実行可否

フェイルオーバー

○

バックアップの作成

○

DBインスタンスのメンテナンス

×

DBインスタンスのスケールアップおよびスケールダウン

×

DBインスタンスのストレージ容量のスケールアップ

×

DBインスタンスのストレージタイプの変更

×

DBインスタンスの名前変更

×

パラメータの変更

×

凡例　○：実行できる　×：実行できない

Amazon RDS for Oracleのリードレプリカとの接続については，利用者側で動作に問題がないことを十分確認することを前提にご利用ください。動作確認で問題があったDB Connectorの機能についてはサポート対象外になります。

(3)　使用できるアプリケーションサーバの機能

アプリケーションサーバにはデータベースを前提とする機能があります。Amazon RDS for Oracleと接続した場合の使用可否を次の表に示します。

表3‒35　データベースを前提とする機能の使用可否

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

使用可否

DB Connectorによるデータベース接続

○

Cosminexus Reliable Messaging

×

Entity Bean

×

アプリケーションサーバのJPAプロバイダ

×

V9互換モードでのCosminexus JPAプロバイダ

×

Java Batch機能

×

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

×

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

×

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

(4)　アプリケーションサーバの設定

Amazon RDS for Oracleに接続するために必要な，アプリケーションサーバに関する設定について説明します。

(a)　J2EEサーバ用ユーザプロパティの設定

Amazon RDS for Oracleに接続する場合は，J2EEサーバ用ユーザプロパティファイルに次のプロパティを設定してください。

設定先のファイル

<アプリケーションサーバのインストールディレクトリ>/CC/server/usrconf/ejb/<J2EEサーバ名>/usrconf.properties

設定するプロパティ

oracle.jdbc.autoCommitSpecCompliant=false

(b)　DB Connectorの設定

DB Connectorの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。ただし，インポートするDB Connectorと，DB Connectorのプロパティ定義は次の説明に従ってください。

インポートするDB Connector

DBConnector_Oracle_CP.rar

DB Connectorのプロパティ定義

Connector属性ファイルの<hitachi-connector-property>−<resourceadapter>−<outbound-resourceadapter>−<connection-definition>−<connector-runtime>−<property>タグに，次の表に示すDB Connectorの実行時プロパティを設定してください。

表3‒36　設定が必要なDB Connectorの実行時プロパティ

property-name

property-type

property-value

デフォルト値

MaxPoolSize

int

プール内のコネクションの最大数を指定します。1〜2147483647の整数値を設定してください。0以下の整数値は設定できません。

10

MinPoolSize

int

プール内のコネクションの最小数を指定します。1〜2147483647の整数値を設定してください。0以下の整数値は設定できません。

10

ValidationType

int

コネクション障害検知機能の障害検知のタイミングを指定します。1（コネクション取得要求時にチェック）を設定してください。

1

MaxPoolSizeおよびMinPoolSizeのプロパティを設定すると，コネクションプーリング機能が有効になります。コネクションプーリング機能の詳細は，「3.14.1　コネクションプーリング」を参照してください。また，ValidationTypeのプロパティを設定すると，コネクション障害検知機能が有効になります。コネクション障害検知機能の詳細は，「3.15.1　コネクションの障害検知」を参照してください。

(c)　Developer's Kit for Javaの設定

Amazon RDSのマルチAZ構成を利用する場合は，Java環境にドメインネームシステム（DNS）の名前解決結果のキャッシュ時間の設定が必要です。Amazon RDS for Oracleからの案内に従い，Developer's Kit for Javaに対してドメインネームシステム（DNS）の名前解決結果のキャッシュ時間を設定してください。設定先のファイルを次に示します。

<Developer's Kit for Javaインストールディレクトリ>/conf/security/java.security

(5)　データベースの設定

データベースおよび接続に使用するクライアントのタイムアウトを適切に設定してください。特に接続に使用するクライアントからの応答が返らなかった場合，アプリケーションサーバやDB Connectorが応答を待ち続けてしまうことがあるため注意してください。Amazon RDS for Oracle に接続する場合は，接続に使用するクライアントのタイムアウトとしてソケット読み込みタイムアウトを設定してください。

接続に使用するクライアントのタイムアウト値を検討する際には，アプリケーションサーバが持つ各タイムアウトの区間との内包関係を確認してください。各タイムアウトが適切に動作するために，タイムアウト値の大小関係に注意が必要です。タイムアウトを設定する場合の指針については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6　タイムアウトを設定する」を参照してください。Amazon RDS for Oracleに接続する場合に設定できるタイムアウトについては，Amazon RDS for OracleやOracle Databaseのドキュメントを参照してください。

(6)　Amazon RDS for Oracleでフェイルオーバーが発生した場合のDB Connectorの動作

Amazon RDS for Oracleでフェイルオーバーが発生した場合のDB Connectorの動作については，「3.6.11　マネージドデータベースサービスがフェイルオーバーした場合のDB Connectorの動作」を参照してください。

3.6.10　HiRDB Cloud Serviceに接続する場合の条件と設定

HiRDB Cloud Serviceに接続する場合の条件と設定について説明します。

(1)　HiRDB Cloud Serviceに接続するための前提条件

J2EEサーバを推奨モードで使用する場合だけ接続をサポートします。V9互換モードの場合はサポート対象外です。

HiRDB Cloud Serviceに接続する場合のサポート条件を次に示します。

表3‒37　HiRDB Cloud Serviceに接続する場合のサポート条件

項目

条件

接続に使用できるJDBCドライバと接続先のHiRDB Cloud ServiceのDBMSバージョン

リリースノートの前提ソフトウェアの項目に記載されているHiRDB Cloud Serviceに接続する場合の条件に従ってください。

接続に使用するDB Connector

DBConnector_HiRDB_Type4_CP.rar

注意事項

接続に使用するDB ConnectorであるDBConnector_Oracle_CP.rarでは，グローバルトランザクションを利用できません。

DB Connectorの設定条件を次の表に示します。設定方法については，「（4）アプリケーションサーバの設定」を参照してください。

表3‒38　DB Connectorの設定の条件

設定項目

設定の条件

コネクションプーリング

有効

障害検知

コネクション取得要求時

(2)　HiRDB Cloud Serviceの使用条件

アプリケーションサーバの稼働中に，HiRDBの停止を伴うHiRDB Cloud Serviceの操作をしないでください。ただし，HiRDB Cloud Serviceの系切り替えについては，アプリケーションサーバの稼働中に実行できます。

(3)　使用できるアプリケーションサーバの機能

アプリケーションサーバにはデータベースを前提とする機能があります。HiRDB Cloud Serviceと接続した場合の使用可否を次の表に示します。

表3‒39　データベースを前提とする機能の使用可否

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

使用可否

DB Connectorによるデータベース接続

○

Cosminexus Reliable Messaging

×

Entity Bean

×

アプリケーションサーバのJPAプロバイダ

×

V9互換モードでのCosminexus JPAプロバイダ

×

Java Batch機能

×

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

×

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

×

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

(4)　アプリケーションサーバの設定

HiRDB Cloud Serviceに接続するために必要な，アプリケーションサーバに関する設定について説明します。

(a)　DB Connectorの設定

DB Connectorの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。ただし，インポートするDB Connectorと，DB Connectorのプロパティ定義は次の説明に従ってください。

インポートするDB Connector

DBConnector_HiRDB_Type4_CP.rar

DB Connectorのプロパティ定義

Connector属性ファイルの<hitachi-connector-property>−<resourceadapter>−<outbound-resourceadapter>−<connection-definition>−<connector-runtime>−<property>タグに，次の表に示すDB Connectorの実行時プロパティを設定してください。

表3‒40　設定が必要なDB Connectorの実行時プロパティ

property-name

property-type

property-value

デフォルト値

MaxPoolSize

int

プール内のコネクションの最大数を指定します。1〜2147483647の整数値を設定してください。0以下の整数値は設定できません。

10

MinPoolSize

int

プール内のコネクションの最小数を指定します。1〜2147483647の整数値を設定してください。0以下の整数値は設定できません。

10

ValidationType

int

コネクション障害検知機能の障害検知のタイミングを指定します。1 (コネクション取得要求時にチェック) を設定してください。

1

MaxPoolSizeおよびMinPoolSizeのプロパティを設定すると，コネクションプーリング機能が有効になります。コネクションプーリング機能の詳細は，「3.14.1　コネクションプーリング」を参照してください。また，ValidationTypeのプロパティを設定すると，コネクション障害検知機能が有効になります。コネクション障害検知機能の詳細は，「3.15.1　コネクションの障害検知」を参照してください。

(b)　Developer's Kit for Javaの設定

HiRDB Cloud ServiceのHA構成を利用する場合は，Java環境にドメインネームシステム（DNS）の名前解決結果のキャッシュ時間の設定が必要です。HiRDB Cloud Serviceからの案内に従い，Developer's Kit for Javaに対してドメインネームシステム（DNS）の名前解決結果のキャッシュ時間を設定してください。

<Developer's Kit for Javaインストールディレクトリ>/conf/security/java.security

(5)　データベースの設定

データベースおよび接続に使用するクライアントのタイムアウトを適切に設定してください。特に接続に使用するクライアントからの応答が返らなかった場合，アプリケーションサーバやDB Connectorが応答を待ち続けてしまうことがあるため注意してください。

接続に使用するクライアントのタイムアウト値を検討する際には，アプリケーションサーバが持つ各タイムアウトの区間との内包関係を確認してください。各タイムアウトが適切に動作するために，タイムアウト値の大小関係に注意が必要です。タイムアウトを設定する場合の指針については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6　タイムアウトを設定する」を参照してください。HiRDB Cloud Serviceに接続する場合に設定可能なタイムアウトについては，HiRDB Cloud ServiceやHiRDBのドキュメントを参照してください。

(6)　HiRDB Cloud Serviceでフェイルオーバーが発生した場合のDB Connectorの動作

HiRDB Cloud Serviceでフェイルオーバーが発生した場合のDB Connectorの動作については，「3.6.11　マネージドデータベースサービスがフェイルオーバーした場合のDB Connectorの動作」を参照してください。

3.6.11　マネージドデータベースサービスがフェイルオーバーした場合のDB Connectorの動作

マネージドデータベースサービスで運用されているデータベースで障害などが発生してフェイルオーバーした場合，DB Connectorは「3.6.9　Amazon RDS for Oracleに接続する場合の条件と設定」または「3.6.10　HiRDB Cloud Serviceに接続する場合の条件と設定」で設定した内容に従い，自動的にフェイルオーバー先のデータベースに接続します。DB Connectorの動作の詳細は，「3.14　パフォーマンスチューニングのための機能」および「3.15　フォールトトレランスのための機能」を参照してください。

ここでは，マネージドデータベースサービスでフェイルオーバーが発生した時，コネクションプール内に未使用コネクションが存在する状態で，ユーザアプリケーションプログラムがコネクションの取得要求をした場合の動作例を示します。

ユーザアプリケーションプログラムがコネクションの取得を要求します。

コネクション障害検知機能が，コネクションプール内の引き渡し予定のコネクションに障害が発生していないかどうかをチェックします。マネージドデータベースサービスでフェイルオーバーが発生したため，これまで接続していたデータベースとの通信ができないので，コネクションに障害が発生していると判断します。このチェックには，コネクション障害検知のタイムアウト時間に設定した時間が掛かる場合があります。

チェックしたコネクションを破棄し，新たなコネクションの生成を試みます。

マネージドデータベースサービスのフェイルオーバーの状態に応じて次のように動作します。

フェイルオーバーが完了していない場合

フェイルオーバー先のデータベースに接続できないため，新たなコネクションの取得に失敗します。そのあとの動作は，コネクションの取得リトライ機能の設定に応じて次のようになります。

・コネクションの取得リトライ機能が有効な場合

コネクションの取得リトライ機能の設定に従い，コネクションの取得をリトライします。リトライしてもコネクションが取得できない場合は，ユーザアプリケーションプログラムに例外を通知します。

・コネクションの取得リトライ機能が無効の場合

ユーザアプリケーションプログラムに例外を通知します。

フェイルオーバーが完了している場合

フェイルオーバー先のデータベースとのコネクションを取得し，ユーザアプリケーションプログラムに返します。

上記で示した例のとおり，自動的にフェイルオーバー先のデータベースに接続する過程では，DB Connectorはコネクション取得要求の延長でコネクションごとに障害を検知し，コネクションを破棄します。コネクション取得要求を契機としたコネクションごとの破棄ではなく，一度にコネクションプール内のすべてのコネクションを破棄したい場合は，cjclearpoolコマンドを使用してください。cjclearpoolコマンドの詳細は，「3.15.5　コネクションプールのクリア」を参照してください。

3.6.12　実行環境での設定（リソースアダプタでの設定）

データベースに接続するための機能を使用する場合，属性ファイルの設定が必要です。

実行環境でのリソースアダプタの設定は，サーバ管理コマンドおよび属性ファイルを使用します。データベースに接続するための機能の定義には，Connector属性ファイルを使用します。

ここでは，使用する機能に関係なく，データベースに接続するために共通のDB Connectorの設定について説明します。

データベースコネクション確立までの待ち時間

<config-property>タグのloginTimeoutで，データベースコネクション確立までのJ2EEアプリケーションの待ち時間を指定します。

なお，データベースに接続するための設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」を参照してください。

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

この節では，DB Connector for Reliable MessagingとReliable Messagingを使用してデータベース上のキューと接続する機能について説明します。

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

表3‒41　この節の構成（データベース上のキューとの接続）

分類

タイトル

参照先

解説

DB Connector for Reliable MessagingとReliable Messagingによる接続の概要

3.7.1

DB Connector for Reliable MessagingとReliable Messagingによる接続の特徴

3.7.2

使用できる機能

3.7.3

接続できるデータベース

3.7.4

DB Connector for Reliable Messaging（RARファイル）の種類

3.7.5

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

3.7.6

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

3.7.7

設定

データベース上のキューに接続するための設定

3.7.8

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

データベース上のキューと接続するためには，リソースアダプタとしてDB Connector for Reliable MessagingとReliable Messagingを使用します。

Reliable Messagingの詳細については，マニュアル「Reliable Messaging」を参照してください。また，接続できるデータベースについては，「3.6　データベースへの接続」を参照してください。

3.7.1　DB Connector for Reliable MessagingとReliable Messagingによる接続の概要

DB Connector for Reliable Messagingは，Reliable Messagingと連携して，JMSインタフェースを使用してデータベースと接続するためのリソースアダプタです。

Reliable Messagingと連携することによって，サーブレット，JSP，Enterprise Bean（Session Bean，Entity Bean，Message-driven Bean）から，JMSインタフェースを使用してデータベース上のキューにアクセスできます。また，JDBCインタフェースを使用して，データベース上のテーブルにもアクセスできます。

JMSインタフェースとJDBCインタフェースを使用して同じデータベースにアクセスするとき，グローバルトランザクションを1フェーズコミットで処理できます。これによって，処理性能が向上します。また，JMSインタフェースとJDBCインタフェースによるデータベース接続に使用する物理コネクションを共通できるため，リソースを有効活用できるようになります。

DB Connector for Reliable MessagingとReliable Messagingによる接続の概要を次の図に示します。

図3‒19　DB Connector for Reliable MessagingとReliable Messagingによる接続の概要

DB Connector for Reliable MessagingとReliable Messagingによるデータベース接続では，JDBCドライバに，HiRDB Type4 JDBC DriverまたはOracle JDBC Thin Driverを使用します。

DB Connector for Reliable Messagingの設定の詳細については，マニュアル「Reliable Messaging」の「2.7　DB Connector for Reliable Messagingの機能」を参照してください。

3.7.2　DB Connector for Reliable MessagingとReliable Messagingによる接続の特徴

ここでは，DB Connector for Reliable MessagingとReliable Messagingによる接続の特徴について説明します。

(1)　DB Connector for Reliable MessagingおよびReliable Messagingによる処理の概要

DB Connector for Reliable Messagingを使用してReliable Messagingと連携することによって，データベース上のキューに対するJMSインタフェースによるメッセージの送受信や，メッセージによって起動されるMessage-driven Beanの呼び出しなどができます。

DB Connector for Reliable MessagingとReliable Messagingによってデータベースに接続する場合，JMSインタフェースとJDBCインタフェースによるアクセスで使用する物理コネクションを共有することによって次のことが実現できるため，処理性能が向上します。

ローカルトランザクションの適用

グローバルトランザクションの1フェーズコミット

サーブレット，JSP，または，Enterprise Beanから，JMSインタフェースとJDBCインタフェースを使用して，データベースにアクセスするときのDB Connector for Reliable MessagingおよびReliable Messagingの処理の概要を次の図に示します。

図3‒20　DB Connector for Reliable MessagingおよびReliable Messagingの処理の概要

JMSインタフェースによるアクセスはReliable Messagingを経由して，JDBCインタフェースによるアクセスはDB Connector for Reliable Messagingを経由して，データベースにアクセスします。なお，Reliable Messagingでは，キューをデータベース上に構築するため，内部的にJDBCインタフェースによるデータベースへのアクセスを使用します。そのため，JDBCドライバを経由してデータベースにアクセスします。

また，DB Connector for Reliable Messagingでは，Reliable Messagingを経由して，Reliable Messagingと物理コネクションを共有してデータベースにアクセスします。これらのリソースアダプタでは，Reliable Messaging用のコネクションプールを利用してコネクションを取得します。これによって，物理コネクションの共有を実現しています。

(2)　DB Connector for Reliable MessagingとReliable Messagingによるデータベース接続の構成

DB Connector for Reliable MessagingとReliable Messagingを使用して接続する場合のリソースの構成パターンについて説明します。ここでは，次に示す場合のリソースの構成について説明します。

JMSインタフェースだけを使用する場合

JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合

JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合

Message-driven Beanを使用する場合

なお，JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合と，Message-driven Beanを使用する場合は，コネクションの共有ができます。ただし，コネクションを共有するためには，次に示す前提条件を満たしている必要があります。

コネクション共有の前提条件

ユーザプログラムで，同一トランザクション内でJMSインタフェースによるデータベース上のキューへのアクセスと，JDBCインタフェースによるテーブルへのアクセスを実施する。

Reliable Messagingによってキューを構築するデータベースと，テーブルにアクセスするデータベースが同じである。

JMSインタフェースよるデータベース上のキューへのアクセスと，JDBCインタフェースによるデータベース上のテーブルへのアクセスで使用するセキュリティ情報（ユーザ名，パスワード）と，サインオンの方式が同じである。

DB Connector for Reliable MessagingとReliable Messagingへのリファレンスを設定しているJ2EEアプリケーションで，DDの<res-sharing-scope>タグの値に「Shareable」が設定されている。

注意事項

JDBCインタフェースだけを使用してデータベースにアクセスする場合，リソースアダプタとしてDB Connectorを使用してください。

コネクション共有の前提条件を満たさない場合，DB Connector for Reliable MessagingとReliable MessagingによってJMSインタフェースとJDBCインタフェースの両方を使用したデータベースへのアクセスはしないでください。この場合，「(c)　JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合」に示す構成にして，テーブルへのアクセスにはDB Connectorを使用してください。

(a)　JMSインタフェースだけを使用する場合

ユーザプログラムでデータベース上のキューに対してだけアクセスする場合，次の図に示す構成で使用します。

図3‒21　JMSインタフェースだけを使用する場合の構成

(b)　JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合

ユーザプログラムでJMSインタフェースとJDBCインタフェースを使用してデータベースにアクセスする場合，コネクション共有の前提条件を満たしているときは，2種類のインタフェースで同一のデータベースにアクセスできます。このとき，次の図に示す構成で使用します。

この構成にすることによって，コネクションの共有によるトランザクション処理性能の向上とリソースの有効利用を実現できます。

図3‒22　JMSインタフェースとJDBCインタフェースでアクセスするデータベースが同じ場合の構成

(c)　JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合

ユーザプログラムでJMSインタフェースとJDBCインタフェースを使用してデータベースにアクセスする場合，コネクション共有の前提条件を満たしていないときは，インタフェースごとに，異なるデータベースにアクセスする構成にする必要があります。このとき，次の図に示す構成で使用します。

図3‒23　JMSインタフェースとJDBCインタフェースでアクセスするデータベースが異なる場合の構成

データベース上のキューへのアクセスには，DB Connector for Reliable MessagingとReliable Messagingを使用します。また，データベース上のテーブルへのアクセスには，DB Connectorを別途用意して使用する必要があります。

(d)　Message-driven Beanを使用する場合

Message-driven Beanを使用する場合，次の図に示す構成で使用します。コネクションの共有条件を満たす場合には，DB Connector for Reliable MessagingのJDBCインタフェースを使用して，Message-driven BeanとJDBCインタフェースでコネクションを共有することができます。

なお，Message-driven Beanを使用する場合，関連づけるリソースアダプタがReliable Messaging 01-01以降のときは，グローバルトランザクションおよびローカルトランザクションを使用できます。Reliable Messaging 01-00のリソースアダプタを使用する場合は，グローバルトランザクションを使用する必要があります。このとき，ローカルトランザクションを使用することはできませんが，コネクション共有の前提条件を満たしていれば，グローバルトランザクションは1フェーズで決着されます。

図3‒24　Message-driven Beanを使用する場合の構成

3.7.3　使用できる機能

DB Connector for Reliable MessagingとReliable Messagingによる接続で使用できる機能の詳細については，マニュアル「Reliable Messaging」の「2.7　DB Connector for Reliable Messagingの機能」を参照してください。

なお，JDBCインタフェースを使用してデータベースに接続する場合，DB Connectorを使用して接続する場合と同じ機能を利用できます。利用できる機能の詳細については，「3.3.4　リソースアダプタの機能」を参照してください。

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

ここでは，DB Connector for Reliable MessagingとReliable Messagingを使用して接続できるデータベースについて説明します。

(1)　接続できるデータベースの種類

DB Connector for Reliable MessagingとReliable Messagingを使用して接続できるデータベースには，HiRDB，およびOracleがあります。なお，SQL Server，およびXDM/RD E2には接続できません。

(2)　データベースとJDBCドライバの対応

DB Connector for Reliable MessagingとReliable Messagingを使用してデータベースに接続するためには，データベースに対応するJDBCドライバが必要です。

接続先のデータベースと使用できるJDBCドライバについて次の表に示します。

表3‒42　接続先のデータベースと使用できるJDBCドライバ（データベース上のキューとの接続の場合）

データベース

JDBCドライバ

HiRDB Type4 JDBC Driver

Oracle JDBC Thin Driver

HiRDB

○

×

Oracle

×

○

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

(3)　注意事項

DB Connector for Reliable MessagingとReliable Messagingを使用してデータベースに接続する場合の注意事項を次に示します。

DB Connector for Reliable Messagingが提供するJDBCコネクション（java.sql.Connection. Connection）では，JDBC固有のトランザクション制御はできません。JDBC固有のトランザクション制御を行った場合，setAutoCommit(boolean)メソッドの引数falseでの呼び出しのときと，releaseSavepoint(SavePoint)メソッド，rollback(Savepoint)メソッド，setSavepoint()メソッド，およびsetSavepoint(String)メソッドの呼び出しのときに例外が発生します。JDBC固有のトランザクション制御を行う場合は，DB Connectorを使用してください。

DB Connector for Reliable Messagingの場合，性能解析トレースの取得ポイントおよびイベントIDがDB Connectorの場合と一部異なります。

JDBCコネクション（java.sql.Connection. Connection）に関しては，1回のアクセスでDB Connector for Reliable MessagingのJDBCコネクションと，DB ConnectorでのJDBCコネクションの二つのトレース取得ポイントで性能解析トレースが出力されます。

また，JDBCコネクションの生成物（java.sql.Statementなど）は，DB Connectorと同様のトレース取得ポイントで性能解析トレースが出力されます。java.sql.DataSourceは，DB Connector for Reliable Messaging用のトレース取得ポイントでだけ性能解析トレースが出力されます。

DB Connector for Reliable Messagingでは，稼働情報監視をした場合，DB Connector for Reliable Messagingのリソースアダプタの次の項目について，正しい値が出力されません。DB Connector for Reliable Messaging はコネクションをReliable Messaging経由で取得するため，連携するリソースアダプタの監視稼働情報はReliable Messaging側に累積され出力されます。

トランザクションサポートレベル

プール現在値（総数）

使用中のコネクション数

未使用のコネクション数

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行回数

ManagedConnectionのgetConnection()メソッドの実行回数

ManagedConnectionのcleanup()メソッドの実行回数

ManagedConnectionのdestroy()メソッドの実行回数

ConnectionManagerのallocateConnection()メソッドの実行時間

ManagedConnectionFactoryのcreateManagedConnection()メソッドの実行時間

ConnectionManagerのallocateConnection()メソッドの失敗回数

ManagedConnectionでFATALエラーが発生した回数

DB Connector for Reliable Messagingは，連携するReliable Messaging側のコネクションプールを共有します。そのため，DB Connector for Reliable Messagingには，コネクションプールの各機能の設定をする必要はありません。

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

3.7.5　DB Connector for Reliable Messaging（RARファイル）の種類

DB Connector for Reliable Messagingを使用してデータベースに接続する場合，使用するJDBCドライバに応じたRARファイルを使用します。RARファイルは，サーバ管理コマンドを使用して操作します。サーバ管理コマンドを使用してRARファイルを操作する方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」を参照してください。

JDBCドライバの種類と対応するRARファイルについて次の表に示します。

表3‒43　JDBCドライバとRARファイルの対応

JDBCドライバ

RARファイル

説明

HiRDB Type4 JDBC Driver

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar※

グローバルトランザクションを使用する場合に使用します。

Oracle JDBC Thin Driver

DBConnector_Oracle_CP_Cosminexus_RM.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

DBConnector_Oracle_XA_Cosminexus_RM.rar※

グローバルトランザクションを使用する場合に使用します。

注※　ライトトランザクション機能は有効にできません。

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

ここでは，HiRDBのキューに接続する場合の前提条件について説明します。

(1)　前提条件

使用できるJDBCドライバ

使用できるJDBCドライバはHiRDB Type4 JDBC Driverとなります。

接続方法

次のどちらかのRARファイルを使用します。

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒44　RARファイルごとに使用できるトランザクションサポートレベル

使用するDB Connector for Reliable Messaging

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

NoTransaction

LocalTransaction

○

○

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

XATransaction

−

○

（凡例）　○：使用できる　　−：該当しない

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

ここでは，Oracleのキューに接続する場合の前提条件について説明します。

使用できるJDBCドライバ

使用できるJDBCドライバはOracle JDBC Thin Driverとなります。

接続方法

DBConnector_Oracle_CP_Cosminexus_RM.rarまたはDBConnector_Oracle_XA_Cosminexus_RM.rarを使用します。

RARファイルの種類に応じて，指定できるトランザクションサポートレベルが異なります。また，ライトトランザクションを使用できるかどうかも異なります。

RARファイルごとに指定できるトランザクションサポートレベルを次の表に示します。

表3‒45　RARファイルごとに使用できるトランザクションサポートレベル

使用するDB Connector for Reliable Messaging

（RARファイル）

トランザクションサポートレベル

ライトトランザクション

有効

無効

DBConnector_Oracle_CP_Cosminexus_RM.rar

NoTransaction

LocalTransaction

○

○

DBConnector_Oracle_XA_Cosminexus_RM.rar

XATransaction

−

○

（凡例）　○：使用できる　　−：該当しない

3.7.8　データベース上のキューに接続するための設定

データベース上のキューに接続するための設定については，マニュアル「Reliable Messaging」の「2.7　DB Connector for Reliable Messagingの機能」を参照してください。

3.8　OpenTP1とのOutboundでの接続（SPPまたはTP1/Message Queue）

この節では，OpenTP1（SPPまたはTP1/Message Queue）とOutboundで接続する機能について説明します。

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

表3‒46　この節の構成（OpenTP1とのOutboundでの接続（SPPまたはTP1/Message Queue））

分類

タイトル

参照先

解説

TP1 Connectorによる接続

3.8.1

TP1/Message Queue - Accessによる接続

3.8.2

設定

OpenTP1とOutboundで接続するための設定

3.8.3

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

アプリケーションサーバでは，OpenTP1 SPPまたはTP1/Message Queueと接続できます。OpenTP1との接続には，次のリソースアダプタを使用します。

OpenTP1 SPPとの接続の場合，TP1 Connectorを使用します。

TP1/Message Queueとの接続の場合，TP1/Message Queue - Accessを使用します。

ここでは，OpenTP1との接続について説明します。

3.8.1　TP1 Connectorによる接続

J2EEサーバとOpenTP1 SPPの接続には，リソースアダプタとしてTP1 ConnectorとTP1/Client/Jを組み合わせて利用します。

OpenTP1との連携について次の図に示します。

図3‒25　TP1 Connectorを利用したOpenTP1との連携

TP1 Connectorは，TP1/Client/JのRPCを使用してOpenTP1と接続し，OpenTP1のSPPにアクセスします。これによって，J2EEサーバでは，OpenTP1のSPPと連携することができます。

注意事項

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

TP1 Connectorの設定項目の詳細については，TP1 Connectorのドキュメントを参照してください。TP1/Client/Jの設定項目の詳細については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

また，サーバ管理コマンドを使用したリソースアダプタの設定方法については，TP1 Connectorのドキュメント，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」，およびマニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.3　そのほかのリソースと接続するための設定」を参照してください。

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

アプリケーションサーバとTP1/Message Queueの接続には，リソースアダプタとしてTP1/Message Queue - Accessを利用します。

TP1/Message Queue - Accessを利用したTP1/Message Queueとの連携について次の図に示します。

図3‒26　TP1/Message Queue - Accessを利用したTP1/Message Queueとの連携

TP1/Message Queue - Accessでは，JMSインタフェースを提供しています。このJMSインタフェースを利用して，J2EEサーバはTP1/Message Queueと接続します。

注意事項

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

TP1/Message Queue - Accessの設定項目の詳細については，マニュアル「OpenTP1 Version 7 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」を参照してください。

また，サーバ管理コマンドを使用したリソースアダプタの設定方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.3　そのほかのリソースと接続するための設定」を参照してください。

3.8.3　OpenTP1とOutboundで接続するための設定

TP1 Connectorによって接続する場合の設定については，TP1 Connectorのドキュメント，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」，およびマニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.3　そのほかのリソースと接続するための設定」を参照してください。

TP1/Message Queue - Accessによって接続する場合の設定については，マニュアル「OpenTP1 Version 7 メッセージキューイングアクセス機能 TP1/Message Queue - Access 使用の手引」，およびマニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「4.3　そのほかのリソースと接続するための設定」を参照してください。

3.9　OpenTP1とのInboundでの接続

OpenTP1を使用したレガシーシステム上のSUPから，アプリケーションサーバのJ2EEサーバ上で動作している業務プログラムを呼び出す場合，OpenTP1とJ2EEサーバの接続には，リソースアダプタとしてTP1インバウンドアダプタを使用します。

TP1インバウンドアダプタは，Connector 1.5仕様に準拠したリソースアダプタです。また，次の機能を備えています。

OpenTP1のスケジュールサービスの代替機能

OpenTP1とRPC通信を実行するための機能

これらの機能を使用することで，OpenTP1のSUPからは，OpenTP1のSPPを呼び出す場合と同様の手順でJ2EEサーバ上の業務プログラムを呼び出せます。

TP1インバウンドアダプタを使用したOpenTP1との接続の詳細については，「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」を参照してください。

注意事項

TP1インバウンド連携機能はSUP，SPPおよびMHPからの呼び出しが可能ですが，このマニュアルでは，SUPからの呼び出しを例に説明します。

3.10　CJMSプロバイダとの接続

アプリケーションサーバが提供するJMSプロバイダの機能を使用する場合，メッセージの送信先の管理にCJMSPブローカーというプロセスを使用します。J2EEサーバとCJMSPブローカーとの接続には，CJMSPリソースアダプタを使用します。

CJMSPリソースアダプタを使用することで，PTPメッセージングモデルまたはPub/Subメッセージングモデルでのメッセージの送受信を実現できます。

CJMSPリソースアダプタとCJMSPブローカーとの接続の詳細については，「7.　CJMSプロバイダ」を参照してください。

3.11　SMTPサーバとの接続

J2EEアプリケーションは，JavaMailを使用して，SMTPサーバにメールを送信できます。

SMTPサーバとの接続の設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「6.3　メールコンフィグレーションの設定」を参照してください。

3.12　JavaBeansリソースの利用

この節では，JavaBeansリソースの利用について説明します。

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

表3‒47　この節の構成（JavaBeansリソースの利用）

分類

タイトル

参照先

解説

JavaBeansリソースの機能

3.12.1

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

3.12.2

実装

JavaBeansリソースの実装

3.12.3

設定

JavaBeansリソースの設定

3.12.4

JavaBeansリソースの入れ替え

3.12.5

注　「運用」について，この機能固有の説明はありません。

3.12.1　JavaBeansリソースの機能

JavaBeansリソースでは，J2EEアプリケーションを稼働させるための設定値などを一括して保持，管理できます。J2EEアプリケーションからJNDIを使用してJavaBeansリソースをルックアップすることで，設定値を取得できます。

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

J2EEサーバで，複数のJavaBeansリソースを開始状態にできます。サーバ管理コマンドを使用した場合の，JavaBeansリソースの開始処理の流れを次の図に示します。

図3‒27　JavaBeansリソースの開始処理の流れ

JavaBeansリソースをインポートして，開始する。

サーバ管理コマンドを使用して，J2EEサーバにJavaBeansリソースをインポートして開始します。

ネーミングサービスにJavaBeansリソースのリファレンスを登録する。

JavaBeansリソースの開始時に，ネーミングサービスのJ2EEリソース用の名前空間にJavaBeansリソースのリファレンスを登録します。

J2EEアプリケーションからネーミングサービスにルックアップする。

JavaBeansリソースを利用するJ2EEアプリケーションから，ネーミングサービスにルックアップを行います。ルックアップ処理の延長でJavaBeansリソースのsetメソッドが呼ばれて，JavaBeansリソース属性ファイルに指定したプロパティ値が設定されます。

取得したリファレンスを使用して，JavaBeansリソースのgetメソッドを呼び出す。

ルックアップして取得したリファレンスを使用して，JavaBeansリソースのgetメソッドの呼び出しを行い，setメソッドで設定した値をgetメソッドで取得します。

JavaBeansリソースの実装クラスは，単独のクラスで構成される場合はクラスファイルの形式で，JavaBeansリソースのクラスと関連クラスのように複数のクラスで構成される場合はJARファイルの形式で利用できます。

3.12.3　JavaBeansリソースの実装

JavaBeansリソースの実装手順を，例を用いて説明します。

(1)　インポート時の設定

サーバ管理コマンド（cjimportjbコマンド）でJavaBeansリソースをインポートするときに必要な設定と注意事項を示します。

(a)　JavaBeansリソース属性ファイルの設定

JavaBeansリソース属性ファイルは，次に示す点に留意して作成してください。

<res-type>タグおよび<class-name>タグには，JavaBeansリソースのクラス名，実装クラス名を指定します。<res-type>タグおよび<class-name>タグで同じ値を設定する場合は<res-type>タグは省略できます。

<property-name>タグには，setメソッドおよびgetメソッドのメソッド名称を指定します。

<property-type>タグには，setメソッドの引数の型を指定します。

<property-type>タグの値と実際の該当setメソッドの引数型と合わない場合はlookup時にエラーになります。

<property-value>タグには，setメソッドの引数に渡す値を指定します。

JavaBeansリソース属性ファイルの設定例を示します。

<!DOCTYPE hitachi-javabeans-resource-property PUBLIC '-//Hitachi, Ltd.//DTD JavaBeans Resource Property 7.0//EN'
'http://localhost/hitachi-javabeans-resource-property_7_0.dtd'>

<hitachi-javabeans-resource-property>
  <description></description>
  <display-name>JavaBean_resource</display-name>
    <class-name>com.mycompany.mypackage.MyJavaBean</class-name>
    <runtime>
      <property>
        <property-name>UserName</property-name>
        <property-type>java.lang.String</property-type>
        <property-value>Hitachi</property-value>
      </property>
      <property>
        <property-name>UserID</property-name>
        <property-type>java.lang.String</property-type>
        <property-value>01234567</property-value>
      </property>
    </runtime>
</hitachi-javabeans-resource-property>

JavaBeansリソース属性ファイルのテンプレートファイル（jb_template.xml）は，次のディレクトリに格納されています。

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

(b)　-dオプションの使い方

インポート時に-dオプションを使用することで，アーカイブを作成しないで，ディレクトリ構成のままインポートできます。-dで指定するディレクトリは，インポートするディレクトリの最上位を指定します。

インポートするときの-dオプションの指定例を次に示します。この指定例では，パッケージ名がcom.mycompany.mypackageのMyJavaBeanクラスをインポートします。

-dで指定するディレクトリ¥
  └ com¥
     └ mycompany
        └ mypackage
             └ MyJavaBean.class

-dオプションは指定されたディレクトリ下に存在するものをすべてインポートするので，不要なファイルはディレクトリ内に含めないでください。

複数のJavaBeansリソースをインポートする場合の注意

インポート済みのJavaBeansリソースと同じ実装クラス名のJavaBeansリソースはインポートできません。先にインポートしたJavaBeansリソースを削除してからインポートするか，実装クラス名を変更し，作成し直してからインポートしてください。

(2)　JavaBeansリソースの実装クラスの作成

JavaBeansで管理するデータ（プロパティ）を操作するメソッドを宣言します。データを登録する場合，setメソッド（set＋プロパティ名）を設定します。データを参照する場合，getメソッド（get＋プロパティ名）を設定します。

次に，JavaBeansリソースを登録，参照するクラスの実装例を示します。

package com.mycompany.mypackage;
public class MyJavaBean {
    private String username;
    private String userid;

    public void setUserName(String user_name) {
        this.username = user_name;
    }
    public void setUserID(String user_id) {
        this.userid = user_id;
    }
    public String getUserName() {
        return this.username;
    }
    public int getUserID() {
        return this.userid;
    }
}

(3)　アプリケーションの設定

JavaBeansリソースを利用するときに，アプリケーション側で必要な実装および定義について説明します。

(a)　lookupの実装（JavaBeansリソース）

JavaBeansリソースを，ルックアップまたはDIを使用して取得します。ここでは，"java:comp/env"形式でルックアップする方法を示します。

Context initCtx = new InitialContext();
MyJavaBean jb = (MyJavaBean) initCtx.lookup("java:comp/env/bean/myJB");

JavaBeansリソースをルックアップできる範囲は，ほかのリソース同様に，同じJ2EEサーバプロセス内のアプリケーションです。

(b)　DDの定義内容（JavaBeansリソース）

ルックアップを使用してJavaBeansリソースを取得する場合，ルックアップする名前や実装クラス名の情報をDD（ejb-jar.xmlまたはweb.xml）に定義します。設定するタグを次に示します。

<resource-env-ref-name>タグに，ルックアップで"java:comp/env"形式に指定する値を指定します。

<resource-env-ref-type>タグに，JavaBeansリソースの実装クラス名を指定します。

また，作成したアプリケーションをJ2EEサーバ上にデプロイするときに，ルックアップでの参照用の名称と実際の名称をlinked-toで結び付けます。この操作をするには，サーバ管理コマンド（cjsetapppropコマンド）を使用します。

cjgetapppropで該当アプリケーションの属性ファイルを取得します。

<resource-env-ref>タグに<linked-to>タグを追加して，利用するJavaBeansリソースの表示名を指定します。

cjsetapppropで該当アプリケーションの属性ファイルを設定します。

次に，cjsetapppropで渡す属性ファイルの<resource-env-ref>タグの例を示します。

<resource-env-ref>
  <resource-env-ref-name>bean/myJB</resource-env-ref-name>
  <resource-env-ref-type>com.mycompany.mypackage.MyJavaBean</resource-env-ref-type>
  <linked-to>JavaBean_resource</linked-to>
</resource-env-ref>

(4)　アプリケーションの開始と終了

JavaBeansリソースを利用するアプリケーションの開始，終了は，サーバ管理コマンドまたはManagement Serverで操作します。アプリケーションの開始方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.1　J2EEアプリケーションの開始」を参照してください。アプリケーションの終了方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.2　J2EEアプリケーションの停止」を参照してください。

アプリケーションサーバでは，JavaBeansリソースのサンプルプログラムを提供します。サンプルプログラムの概要および実行方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録L.5　JavaBeansリソースのサンプルプログラム」を参照してください。

3.12.4　JavaBeansリソースの設定

ここでは，JavaBeansリソースの設定について説明します。

サーバ管理コマンドを使用してJavaBeansリソースのプロパティを設定し，JavaBeansリソースをインポートします。

JavaBeansリソースの設定には，サーバ管理コマンドを使用します。

ここでは，JavaBeansリソースの新規設定の流れ，設定変更の流れ，および入れ替えの流れについて説明します。

(1)　JavaBeansリソースの新規設定の流れ

JavaBeansリソースの新規設定の流れを次の図に示します。

図3‒28　JavaBeansリソースの新規設定の流れ

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

JavaBeansリソース属性ファイルを作成し，JavaBeansリソースのプロパティを定義します。

JavaBeansリソース属性ファイルのテンプレートを使用してJavaBeansリソース属性ファイルを作成して，JavaBeansリソースのプロパティを定義してください。JavaBeansリソース属性ファイルのテンプレートは次のディレクトリに格納されています。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/admin/templates/jb_template.xml

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

サーバ管理コマンドを使用して，JavaBeansリソースをインポートします。

1.で設定したJavaBeansリソース属性ファイルと，JavaBeansリソースを含むJARファイルのパスを引数に指定し，cjimportjbコマンドを使用して，JavaBeansリソースをインポートします。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.4　J2EEサーバで使用するリソース操作コマンド」を参照してください。属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.2　JavaBeansリソース属性ファイル」を参照してください。

参考

JavaBeansリソースを複数インポートする場合，インポート済みのJavaBeansリソースと同じ実装クラス名のJavaBeansリソースはインポートできません。先にインポートしたJavaBeansリソースを削除してからインポートするか，または実装クラス名を変更して再作成したあとでインポートしてください。

また，JavaBeansリソースの実装クラス以外にほかのクラスファイルを使用している場合，ほかのクラスファイルに関してはチェックされません。

インポート時にcjimportjbコマンドに-dオプションを使用すると，アーカイブを生成しないで，ディレクトリ構成のままインポートできます。ディレクトリは，インポートしたいディレクトリの最上位を指定します。

なお，指定したディレクトリがディレクトリ構成でない場合は，指定したディレクトリ直下のファイルをすべてインポートします。

指定したディレクトリ下にあるすべてのファイルをインポートするため，不要なファイルをディレクトリに含めないでください。

注意事項

JavaBeansリソースを使用する場合，J2EEアプリケーションからJavaBeansリソースへのリファレンスを解決しておく必要があります。JavaBeansリソースを使用しているJ2EEアプリケーションのプロパティを定義するときに，J2EEアプリケーションからJavaBeansリソースへのリファレンスを解決しておいてください。

(2)　JavaBeansリソースの設定変更の流れ

JavaBeansリソースの設定変更の流れを次の図に示します。

図3‒29　JavaBeansリソースの設定変更の流れ

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

サーバ管理コマンドを使用して，JavaBeansリソースを停止します。

cjstopjbコマンドを使用してJavaBeansリソースを停止します。なお，JavaBeansリソースを停止する前に，そのJavaBeansリソースを使用しているJ2EEアプリケーションをすべて停止してください。

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

cjgetjbpropコマンドを使用してJavaBeansリソース属性ファイルを取得し，ファイル編集後に，cjsetjbpropコマンドで編集内容を反映させます。

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

(3)　JavaBeansリソースの入れ替えの流れ

JavaBeansリソースの入れ替えの流れを次の図に示します。

図3‒30　JavaBeansリソースの入れ替えの流れ

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

サーバ管理コマンドを使用して，JavaBeansリソースを停止します。

cjstopjbコマンドを使用して入れ替えるJavaBeansリソースを停止します。なお，JavaBeansリソースを停止する前に，そのJavaBeansリソースを使用しているJ2EEアプリケーションをすべて停止してください。

J2EEサーバを再起動します。

cjstopsvコマンドを使用してJ2EEサーバを停止し，cjstartsvコマンドを使用してJ2EEサーバを再起動します。

サーバ管理コマンドを使用して，JavaBeansリソースを削除します。

cjdeletejbコマンドを使用して，入れ替えるJavaBeansリソースを削除します。

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

cjimportjbコマンドを使用して，新しいJavaBeansリソースをインポートします。

(4)　JavaBeansリソースのプロパティ定義で設定できること

JavaBeansリソースのプロパティを新規に設定する場合は，JavaBeansリソース属性ファイルのテンプレートを使用してJavaBeansリソース属性ファイルを作成して，プロパティを定義します。また，設定変更の場合は，サーバ管理コマンドでJavaBeansリソース属性ファイルを取得して，プロパティを定義します。cjgetjbpropコマンドでJavaBeansリソース属性ファイルを取得して，ファイル編集後に，cjsetjbpropコマンドで編集内容を反映させてください。

JavaBeansリソースのプロパティ定義で設定できる主な内容を次の表に示します。

表3‒48　JavaBeansリソースのプロパティ定義で設定できる主な内容

分類

項目

設定内容

実行時プロパティ

リソースのタイプ

<res-type>タグにJavaBeansリソースのクラス名を指定します。

プロパティ情報

<property>タグ下の次のタグに設定します。

<property-name>タグにJavaBeansリソースのsetメソッド，getメソッドのメソッド名を指定します。

<property-type>タグにJavaBeansリソースのsetメソッドの引数の型を指定します。

<property-value>タグにJavaBeansリソースのsetメソッドの引数に渡す値を指定します。

別名情報

別名

JavaBeansリソースに別名を付与する場合，<resource-env-external-property>−<optional-name>タグにJavaBeansリソースの別名を指定します。

別名の設定については，「2.6.6　J2EEリソースの別名の設定」を参照してください。

参考

DD（ra.xml）の<resource-ref>タグで指定していた<res-auth>属性と，<res-sharing-scope>属性は，JavaBeansリソース属性ファイルの<resource-env-external-property>タグには指定できません。

3.12.5　JavaBeansリソースの入れ替え

ここでは，JavaBeansリソースを入れ替える手順について説明します。JavaBeansリソースは，J2EEアプリケーションおよびJavaBeansリソースを停止して，J2EEサーバを再起動してから入れ替えます。JavaBeansリソースの入れ替えには，サーバ管理コマンドを使用します。

手順を次に示します。

入れ替えるJavaBeansリソースを使用しているJ2EEアプリケーションを停止します。

J2EEアプリケーションを停止するには，cjstopappコマンドを実行します。cjstopappコマンドの実行形式と実行例を次に示します。

実行形式

cjstopapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstopapp MyServer -name App1

入れ替えるJavaBeansリソースを停止します。

JavaBeansリソースを停止するには，cjstopjbコマンドを実行します。cjstopjbコマンドの実行形式と実行例を次に示します。

実行形式

cjstopjb <サーバ名称> -resname <JavaBeansリソース表示名>

実行例

cjstopjb MyServer -resname javabeansname

J2EEサーバを再起動します。

いったん開始したJavaBeansリソースを削除するには，J2EEサーバを再起動する必要があります。J2EEサーバを停止するには，cjstopsvコマンドを実行します。cjstopsvコマンドの実行形式と実行例を次に示します。

実行形式

cjstopsv <J2EEサーバ名>

実行例

cjstopsv MyServer

J2EEサーバを停止したあと，もう一度開始します。J2EEサーバを開始するには，cjstartsvコマンドを実行します。cjstartsvコマンドの実行形式と実行例を次に示します。

実行形式

cjstartsv <J2EEサーバ名>

実行例

cjstartsv MyServer

入れ替えるJavaBeansリソースを削除します。

JavaBeansリソースを削除するには，cjdeletejbコマンドを実行します。cjdeletejbコマンドの実行形式と実行例を次に示します。

実行形式

cjdeletejb <サーバ名称> -resname <JavaBeansリソース表示名>

実行例

cjdeletejb MyServer -resname MyJavaBeans

入れ替え後のJavaBeansリソースをインポートします。

JavaBeansリソースをインポートするには，cjimportjbコマンドを実行します。cjimportjbコマンドの実行形式と実行例を次に示します。

実行形式

cjimportjb <サーバ名称> -f <JARファイルパス> -c <JavaBeansリソース属性ファイルパス>

実行例

cjimportjb MyServer -f Myjavabeans.jar -c Myjavabeansprop.xml

JavaBeansリソースを開始します。

JavaBeansリソースを開始するには，cjstartjbコマンドを実行します。cjstartjbコマンドの実行形式と実行例を次に示します。

実行形式

cjstartjb <サーバ名称> -resname <JavaBeansリソース表示名>

実行例

cjstartjb MyServer -resname javabeansname

J2EEアプリケーションを開始します。

J2EEアプリケーションを開始するには，cjstartappコマンドを実行します。cjstartappコマンドの実行形式と実行例を次に示します。

実行形式

cjstartapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjstartapp MyServer -name App1

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

ここでは，これまでの節で説明したリソース以外のリソースとの接続について説明します。

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

アプリケーションサーバでは，Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタを使用して，任意のリソースに接続できます。

Connector 1.5仕様では，J2EEサーバとリソースアダプタ間の通信モデルとして，次の2種類のモデルが決められています。アプリケーションサーバでは，これらの通信モデルに対応したリソースアダプタを使用できます。

Outbound

J2EEサーバからリソースアダプタにアクセスする通信モデルです。

Inbound

リソースアダプタからJ2EEサーバにアクセスする通信モデルです。

アプリケーションサーバでは，Connector 1.5仕様の次の規約に対応しています。

Lifecycle Management

リソースアダプタの開始処理または終了処理を管理するための規約です。

Work Management

リソースアダプタがスレッドを扱うための規約です。

メッセージインフロー

EISからのメッセージを受信して，リソースアダプタからMessage-driven Beanを使用するための規約です。

トランザクションインフロー

メッセージインフローで，トランザクションを扱うための規約です。

これらの規約に基づいたアプリケーションサーバの機能については，「3.16.1　リソースアダプタのライフサイクル管理」，「3.16.2　リソースアダプタのワーク管理」，「3.16.3　メッセージインフロー」および「3.16.4　トランザクションインフロー」を参照してください。

また，既存の次の規約に対してConnector1.5仕様で追加された機能についても，アプリケーションサーバで対応しています。

Connection Management

不正コネクションを検知できます。

不正コネクションを検知する機能については，「3.15.1　コネクションの障害検知」を参照してください。

Common Client Interface

メッセージインフローに関連したAPIを使用できます。このAPIに対してアプリケーションサーバで独自に規定した仕様については，「3.16.7　アプリケーションサーバ独自のConnector 1.5 API仕様」を参照してください。

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

Connector 1.5で規定された機能のうち，アプリケーションサーバで使用できる機能について説明します。使用できる機能は，Outboundの場合とInboundの場合で異なります。なお，Connector 1.5仕様に準拠したリソースアダプタで使用できるアプリケーションサーバの機能については，「3.3.4　リソースアダプタの機能」を参照してください。

(1)　Outboundで使用できる機能

Outboundでは，次の機能が使用できます。

ローカルトランザクションおよびグローバルトランザクションによるトランザクション管理

メッセージキューの使用

(2)　Inboundで使用できる機能

Inboundでは，Non-Transacted Delivery（EISがトランザクションに参加しないメッセージ配信）およびTransacted Delivery（EISがアプリケーションサーバのグローバルトランザクションに参加するメッセージ配信）を使用できます。

参考

トランザクションインフロー（Message-driven Beanの呼び出しがEISのトランザクションに参加するメッセージ配信）は，TP1インバウンド連携機能でだけ対応しています。

(3)　リソースアダプタの利用方法とトランザクションレベルの対応

リソースアダプタをOutboundで使用する場合に指定できるトランザクションレベルを次の表に示します。

表3‒49　Outboundで使用する場合に指定できるトランザクションレベル

利用する通信モデル

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

トランザクション属性

トランザクションサポートレベル

NoTransaction

LocalTransaction

XATransaction※

Outbound

CMT

Required

RequiresNew

Supports

NotSupported

Mandatory

Never

○

○

○

BMT

−

○

○

○

（凡例）

○：使用できる　−：該当しない

注※　リソースアダプタをJ2EEアプリケーションに含める場合は，XATransactionは使用できません。

ポイント

リソースアダプタをInboundで使用する場合に指定できるトランザクション属性を次の表に示します。

表3‒50　Inboundで使用する場合に指定できるトランザクション属性

利用する通信モデル

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

トランザクション属性

Inbound

CMT

Required※

NotSupported

BMT

−

（凡例）

−：該当しない

注※　CJMSPリソースアダプタまたはFTPインバウンドアダプタの場合は指定できません。

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

この節では，パフォーマンスチューニングのための機能について説明します。

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

表3‒51　この節の構成（パフォーマンスチューニングのための機能）

分類

タイトル

参照先

解説

コネクションプーリング

3.14.1

コネクションプーリングで使用できる機能

3.14.2

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

3.14.3

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

3.14.4

ライトトランザクション

3.14.5

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

3.14.6

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

3.14.7

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

3.14.8

実装

cosminexus.xmlでの定義

3.14.9

設定

実行環境での設定

3.14.10

注　「運用」について，この機能固有の説明はありません。

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

サーブレット，JSP，EJBなどのJ2EEコンポーネントからのリソースアクセス量に応じて，リソースコネクション（JDBCコネクション，およびリソースアダプタのコネクション）をプーリングする機能です。コネクションをプーリングすることによって，ユーザアプリケーションからのリソース接続要求を高速に処理します。

(1)　前提条件

コネクションプーリング機能は，リソースの種類，接続方法の組み合わせによって，使用できる場合とできない場合があります。コネクションプーリング機能の使用について次の表に示します。

表3‒52　コネクションプーリング機能の利用可否

リソースの種類

接続方法

利用可否

データベース

DB Connector

○

データベース上のキュー

DB Connector for Reliable MessagingとReliable Messaging

○

OpenTP1

TP1 Connector

○

TP1/Message Queue - Access

○

SMTPサーバ

メールコンフィグレーション

×

JavaBeansリソース

−

×

そのほかのリソース

Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ

○

（凡例）　○：使用できる　×：使用できない　−：該当しない

(2)　コネクションプールの生成および初期化

コネクションプールが生成・初期化されるタイミングは，リソースのスタート処理時です。コネクションプールのウォーミングアップ機能を有効にした場合，この時点でコネクションを生成します。コネクションプールのウォーミングアップ機能を無効にした場合，リソースのスタート時にコネクションは生成されず，最初のコネクション取得要求の発生時にコネクションを生成します。

コネクションプールの生成単位は次のとおりです。

Connector 1.0仕様に対応したリソースアダプタを使用する場合，リソース単位に一つのコネクションプールが生成されます。

Connector 1.5仕様に対応したリソースアダプタを使用する場合，コネクション定義ごとに一つのコネクションプールが生成されます。

(3)　コネクションプールの終了処理

リソースのアンデプロイ時やJ2EEサーバの終了時は，コネクションプール内のすべてのコネクションを削除し，コネクションプール自体も削除します。なお，コネクションプールの終了処理では，コネクションに関するトランザクションなどがすべて決着済みのものとして処理します。

(4)　例外が発生したコネクションの破棄

データベース障害などが発生すると，コネクションプールに格納しているコネクションは使えなくなるため，コネクションプールから速やかに破棄する必要があります。

アプリケーションサーバは，コネクション，またはStatementのようなコネクションからの生成物に対する処理で例外が発生すると，コネクションクローズ時に該当コネクションをコネクションプールから破棄します。ただし，ローカルトランザクションの決着処理が正常終了した場合には，コネクションが正常であると判断するため破棄しません。

コネクションが正常に維持している状態で，コネクションやコネクションからの生成物で例外が発生すると，グローバルトランザクションを使用している場合には，トランザクションの決着処理が正常終了してもアプリケーションサーバはコネクションをコネクションプールに戻さないで破棄します。そのため余分なコネクション生成が発生して性能に影響を与えることがあります。

なお，トランザクションタイムアウト発生時には，トランザクション種別に関係なくコネクションをコネクションプールから破棄します。

(5)　コネクションプール利用上の注意事項

コネクションプールを利用する場合の注意事項について説明します。

データベースサーバ側から強制的に切断する機能（タイムアウトなど）を利用しないでください。

コネクションプールで管理するコネクションは，取得時に使用した認証情報（ユーザ名，パスワードなど）を保持するため，サインオンの形態によっては注意が必要です。

コンテナ管理でのサインオンの場合

一つのコネクションプールに対して，コネクション取得要求時に使用する認証情報は常に一つとなるため，特に注意は必要ありません。

コンポーネント管理でのサインオンの場合

複数のユーザ名とパスワードの組み合わせを利用する場合に注意が必要です。コネクションプールはリソースごとに一つであるため，一つのリソースに対して複数のユーザが利用する場合，複数のユーザで一つのコネクションプールを共有することになります。この場合，一人のユーザが，コネクションプールの最大値に設定した数までコネクションを利用できないことがあります。

また，コネクションプール内の未使用コネクションの中に，認証情報が一致するコネクションがない場合，プール内のコネクション総数によって，次のように動作します。

コネクション総数が，指定したコネクションプールの最大値に達している場合，未使用状態のコネクションを破棄して，新規にコネクションを生成します。

コネクション総数が，指定したコネクションプールの最大値に達していない場合，新規にコネクションを生成します。

(6)　コネクションプーリングの動作

リソースアダプタのコネクションプーリングの動作を次の表に示します。

表3‒53　コネクションプールの状態と動作

ユーザアプリケーションプログラム処理

コネクションプールの状態

コネクションプールの動作

コネクションの取得要求

プール内に未使用状態のコネクションがある

未使用状態の時間がいちばん長いコネクションが選択され，ユーザアプリケーションプログラムに渡されます。選択されたコネクションは，プール内で使用中状態になります。

プール内に未使用状態のコネクションがなく，プール内のコネクションの総数が「MaxPoolSize」の値未満

新規にコネクションを確立します。確立したコネクションはユーザアプリケーションに渡され，コネクションはプール内で使用中状態となります。

プール内に未使用状態のコネクションがなく，プール内のコネクションの総数が「MaxPoolSize」の値に達している

ユーザアプリケーションプログラムに例外が通知され，コネクションの取得は失敗します。再取得するためには，「Retry Count」と「Retry Interval」を設定します。

プール内に未使用状態のコネクションがあるが，認証情報が一致するコネクションがない

プール内のコネクションの総数によって次の処理が実施されます。

プール内のコネクションの数が「MaxPoolSize」の値未満の場合

新規にコネクションを確立し，ユーザアプリケーションに引き渡されます。

プール内のコネクションの数が「MaxPoolSize」の値に達している場合

使用されていないコネクションのうち，最初にプーリングされたコネクションが破棄されたあと，新しいコネクションが作成されて，ユーザアプリケーションに引き渡されます。

コネクションを解放

解放したコネクションに異常がなく，再利用できる

このコネクションはプール内で未使用状態に戻ります。

解放したコネクションが再利用できない

このコネクションは破棄されます。

−

コネクションプールのウォーミングアップ機能を使用

リソースアダプタの開始時またはリソースアダプタを開始済みの状態でのサーバ起動時に，「MinPoolSize」の値までコネクションが生成されてプールされます。

コネクションプールのウォーミングアップ機能を使用するためには，「Warmup」を設定します。

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

コネクションプールにコネクションが最大数プールされていて利用できるコネクションがプールにない状態（コネクション枯渇）のときに，コネクションの取得要求を待ち状態にできます。

待ち状態になっているコネクション取得要求は，コネクションが解放されるとすぐにコネクションを取得できます。

コネクション枯渇時のコネクション取得待ちは，「RequestQueueEnable」「RequestQueueTimeout」で設定します。

（凡例）　−：該当なし

なお，コネクションプールのウォーミングアップ機能を使用する場合は，次の表に示す注意事項があります。

表3‒54　コネクションプールのウォーミングアップ機能を使用する場合の注意事項

条件

注意事項

コンテナ認証用の認証情報（ユーザ名，パスワードなど）の設定※

コンポーネント管理でのサインオンで，複数のユーザ名とパスワードの組み合わせで利用する場合に注意が必要です。コネクションプールはリソースごとに一つであるため，一つのリソースに対して複数のユーザが利用する場合，複数のユーザで一つのコネクションプールを共有することになります。この場合，一人のユーザが，コネクションプールの最大値に設定した数までコネクションを利用できないことがあります。

コンテナ管理でのサインオンの場合は，一つのコネクションプールに対して，コネクション取得要求時に使用する認証情報は常に一つとなるため，特に注意は必要ありません。

「MinPoolSize」の設定

次のような場合，MinPoolSizeに指定した値よりもプールされているコネクションが少なくなることがあります。

コネクションスイーパによってコネクション解放処理が実行されたとき

cjclearpool（コネクションプール内のコネクション削除）コマンドを実行したとき

コネクションに障害が発生したとき

リソースの開始時にMinPoolSize分のコネクションが生成されるため，コネクションプールのウォーミングアップ機能を使用しない場合に比べてサーバの起動またはリソースアダプタの開始に時間が掛かります。

また，このときに「bufSizeに指定した値 × 生成したコネクション数分のメモリ」をJavaヒープ領域に確保します。

MinPoolSizeに必要以上に大きな値を設定してウォーミングアップ機能を使用すると，メモリを確保したときにJavaヒープを使い切り，OutOfMemoryErrorが発生するおそれがあります。

このため，MinPoolSizeの値は，使用するリソースマネジャの最大同時接続数以下に設定してください。

注※　コネクションプールで管理するコネクションは，ウォーミングアップ機能の動作時に使用したコンテナ認証用の認証情報（ユーザ名，パスワードなど）を保持します。

3.14.2　コネクションプーリングで使用できる機能

コネクションプーリング機能を使用すると，さらに次に示す機能も使用できます。

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

コネクションプールのウォーミングアップとは，サーバ起動時またはリソースアダプタのスタート時に実行されるリソースのスタート処理で，あらかじめ，コネクションを，コネクションプールの設定で定義した最小値までプーリングする機能です。これによって，コネクションプールの使用を開始した直後の，コネクション要求のレスポンスを向上できます。

コネクションプールのウォーミングアップは，リソースアダプタの属性（プロパティ）として設定します。リソースアダプタのプロパティ定義で設定できることについては，「3.14.10　実行環境での設定」を参照してください。

(2)　コネクション数調節機能

コネクション数調節機能とは，コネクションプール内の不要なコネクションを指定したコネクションプールの最小値から最大値の範囲で段階的に減少させる機能です。この機能を有効にすると，実際の稼働実績に適した数までプール内のコネクション数を徐々に減らせるため，指定したコネクションプールの最小値を超えた場合のコネクション生成コストの削減やリソース資源の節約ができます。

また，コネクション数の調節時のコネクション削除処理に対して，応答時間にタイムアウトを設定できます。サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション削除処理に対しても応答が返らなくなることがあります。このように，リソースから応答が返らない場合でも，タイムアウトを設定することでコネクション削除処理を終了し，処理を継続できます。

コネクション数調節機能の動作

コネクション数調節機能を使用すると，プール内のコネクション数は，前回コネクション数を調節したときから今回コネクション数を調節するまでの間に同時に使用されたコネクションの最大数で調節されます。コネクション数の調節時に，プール内コネクション数が同時に使用されたコネクションの最大数より多い場合は，コネクションの削除処理が動作します。例えば，現在，プール内にあるコネクション数が8の場合で，前回のコネクション数調整から今回のコネクション数調節までの間に同時に使用されたコネクションの最大数が5のときは，プール内のコネクション数が3多いため，コネクションプールから3コネクションが削除され，調節後のコネクション数は5となります。

なお，コネクション数調節機能は一定間隔で動作します。

コネクション数調節機能の設定については，「3.14.10　実行環境での設定」を参照してください。

コネクション削除処理のタイムアウト

コネクション数調節機能のコネクション削除処理に対して，その応答時間にタイムアウトを設定できます。なお，コネクション削除処理のタイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキーに，任意の時間を指定できます（デフォルト値は5秒）。

ただし，コネクションプールの最大数が無制限の場合，コネクション削除処理のタイムアウトは無効になります。

また，コネクション削除処理のタイムアウトにはコネクション管理スレッドを使用するため，コネクション削除処理のタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費します。設定する場合は，必要なメモリ使用量を適切に見積もってください。

コネクション管理スレッドについては，「3.15.1　コネクションの障害検知」を参照してください。

(3)　コネクションスイーパの動作

一定間隔でコネクションプール内の未使用コネクションを破棄するための，コネクションスイーパ機能は，次のように動作します。

前回のコネクションスイーパの動作が終了してから「SweeperInterval」の値の経過後，コネクションスイーパが動作します。

コネクションスイーパは，プール内の未使用状態のコネクションを監視します。

最後に利用した時点からの経過時間が「ConnectionTimeout」の値以上の未使用状態コネクションを破棄します。未使用状態コネクションで，最後に利用した時点からの経過時間が「ConnectionTimeout」の値未満のコネクションについては，何もしません。

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

コネクションシェアリングとコネクションアソシエーションは，コネクション共有機能です。コネクション共有機能を利用することで，リソースを効率的に使用し，パフォーマンスを向上できます。必要に応じて，コネクションアソシエーション機能を有効にしてください。

ローカルトランザクションでトランザクション管理を行っている場合，一つのリソースコネクションだけでデータベースなどのリソースにアクセスする必要があります。コネクション共有機能を使用するとユーザアプリケーションで意識することなく，一つのリソースコネクションだけでリソースアクセスができます。

グローバルトランザクションの場合も同様に，一つのリソースコネクションしかトランザクションに参加しない場合は，1フェーズコミットに最適化されるため，トランザクションの決着コストを下げることができます。

(1)　物理コネクションと論理コネクション

物理コネクションとは，接続先リソースのコネクションを指します。通常，サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作することはなく，コンテナが操作します。例えば，リソースアダプタの場合はManagedConnection（javax.resource.spi.ManagedConnection）です。

論理コネクションとは，サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作するコネクションを指します。例えば，リソースアダプタの場合はjavax.resource.cci.Connectionやリソースアダプタが独自に提供するコネクションです。

物理コネクションと論理コネクションの関係は，一般的に，物理コネクションから論理コネクションを生成するという関係になります。物理コネクションはコネクションプールで管理され，コネクションプールが物理コネクションの取得およびクローズを行います。

サーブレットやEnterprise BeanなどのJ2EEコンポーネントからのコネクション取得要求に対しては，コネクションプールが物理コネクションから論理コネクションを生成して返却します。コネクション解放要求に対しては，論理コネクションだけをクローズし，物理コネクションはクローズしないでプール管理します。

(2)　コネクションシェアリング

コネクションアソシエーション機能が有効でない場合，アプリケーションサーバが管理するトランザクション内でコネクションシェアリングが行われます。トランザクション内コネクションシェアリングは，リソースコネクションを最も効率的に使用します。トランザクション内のコネクションシェアリングについて次の図に示します。

図3‒31　論理コネクションと物理コネクションの関係（トランザクション内コネクションシェアリング）

コネクションアソシエーション機能が有効な場合，およびアプリケーションサーバが管理するトランザクションの外でのコネクションシェアリングは，サーブレットやEnterprise BeanなどのJ2EEコンポーネントインスタンス内でコネクションシェアリングが行われます。コンポーネント内のコネクションシェアリングについて，次の図に示します。

図3‒32　論理コネクションと物理コネクションの関係（コンポーネント内コネクションシェアリング）

(a)　コネクションシェアリングの条件

コネクションシェアリングをするためには，次の条件をすべて満たす必要があります。

同一のJ2EEサーバ内であること

同一のリソースであること

サインオンの方法とセキュリティ情報（ユーザ名とパスワード）が同じであること

標準DDの<res-sharing-scope>にShareableが指定されていること

同一のアプリケーションサーバが管理するトランザクション内であること※

注※

アプリケーションサーバが管理するトランザクションの外でもコネクションシェアリングを行うことができます。

アプリケーションサーバが管理するトランザクションの外でコネクションシェアリングを有効にする場合は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.14.10　実行環境での設定」を参照してください。

なお，リソースアダプタのトランザクションサポートレベルにNoTransactionを指定した場合は，コネクションシェアリングは行われません。

なお，コネクションシェアリングの定義については，「3.14.9　cosminexus.xmlでの定義」を参照してください。

(b)　コネクションシェアリングの定義

コネクションを共有するかどうかは，サーブレットやEnterprise Beanの標準DDまたはcosminexus.xmlの<res-sharing-scope>タグで指定します。リソース参照ごとに指定できます。コネクションの共有はデフォルトで有効になっています。無効にする場合は，<res-sharing-scope>にUnshareableを指定します。

J2EEアプリケーションの設定については，「3.14.9　cosminexus.xmlでの定義」を参照してください。

(c)　注意事項

java.sql.Connectionを，複数のトランザクション間で再利用することはできません。

java.sql.Connectionをトランザクション内で利用する場合には，トランザクションごとに，javax.sql.DataSourceからgetConnection()メソッドを使用してコネクションを取得してください。

なお，java.sql.Connectionは，トランザクション内とトランザクション外との間でも再利用することはできません。

(3)　コネクションアソシエーション

トランザクション範囲を超えた永続性を持つコネクションを使用する場合，トランザクション内コネクションシェアリングを使用できません。その場合は，コネクションアソシエーション機能を有効にしてください。

コネクションアソシエーションは，論理コネクションと物理コネクションの関係を切り替えて，一つのリソースコネクションによるリソースアクセスを実現します。

図3‒33　論理コネクションと物理コネクションの関係（コネクションアソシエーション）

図3‒34　論理コネクションと物理コネクションの関係（コネクションアソシエーションとコネクションシェアリングの併用時）

(a)　コネクションアソシエーションの条件

コネクションアソシエーションをするためには，次の条件のすべてを満たす必要があります。

コネクションアソシエーション機能が有効であること

同一のJ2EEサーバ内であること

同一のリソースであること

サインオンの方法とセキュリティ情報（ユーザ名とパスワード）が同じであること

標準DDの<res-sharing-scope>にShareableが指定されていること※

同一のアプリケーションサーバが管理するトランザクション内であること

注※

usrconf.propertiesのejbserver.connectionpool.association.enabledDespiteUnshareableSettingキーに「true」を設定すると標準DDの<res-sharing-scope>にUnshareableが指定されていてもコネクションアソシエーションを行います。

このプロパティは下位互換性のためだけに提供されています。

(b)　コネクションアソシエーションの定義

コネクションアソシエーションはデフォルトで無効になっています。

コネクションアソシエーションを有効にするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.14.10　実行環境での設定」を参照してください。

(c)　注意事項

java.sql.Connectionからの生成物（例：java.sql.Statement）をトランザクションの範囲を超えて使用することはできません。

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

DB Connectorを使用した場合，JDBCドライバから取得するjava.sql.PreparedStatementとjava.sql.CallableStatementのオブジェクトを保持して再利用を行うプーリング機能を使用できます。ステートメントプーリング機能によって，PreparedStatementとCallableStatementを使用した場合のパフォーマンス向上が図れます。なお，PreparedStatementとCallableStatementのプールサイズは，DB Connectorの設定で指定します。ステートメントプーリングを使用する際のプールサイズ設定の指針については，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.5.2　ステートメントプーリングを使用する」を参照してください。また，DB Connectorのプロパティ定義については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。

ステートメントプーリング機能では，ステートメントを再利用する際にステートメントを初期化します。初期化する内容はJ2EEサーバのプロパティをカスタマイズして設定します。ステートメントプーリング機能の設定については，「3.14.10　実行環境での設定」を参照してください。

ステートメントプーリング機能を利用するには，コネクションプーリング機能を使用する必要があります。また，トランザクションサポートレベルにグローバルトランザクションを指定した場合，HiRDBのバージョンによっては利用できないことがあります。

注意事項

HiRDB Type4 JDBC Driverを使用する場合，PreparedStatement，CallableStatementのプールサイズに制限があります。指定できるプールサイズについては，マニュアル「アプリケーションサーバ リファレンス定義編(アプリケーション／リソース定義)」の「4.1.10　DB Connectorに設定する<config-property>タグに指定できるプロパティ」を参照してください。

なお，ステートメントプーリング機能を使用しない場合は，PreparedStatement，およびCallableStatementのプールサイズを両方とも0にしてください。

(1)　前提条件

トランザクションサポートレベル，コネクションプーリング使用の有無，使用するデータベースの種類との対応による，ステートメントプーリング利用について次の表に示します。

表3‒55　ステートメントプーリングの利用

トランザクションサポートレベル

コネクションプーリングを使用する

コネクションプーリングを使用しない

HiRDB※1

Oracle

SQL Server

XDM/RD E2

HiRDB／Oracle／SQL Server

トランザクションなし（NoTransaction）

○

○

○

○

×

ローカルトランザクション（LocalTransaction）

○

○

○

○

×

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

○※2

○

×

×

×

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

注※1　ステートメントプーリング機能を使用した状態で，定義SQLを実行しないでください。定義SQLを実行する場合，ステートメントプーリング機能は使用できません。また，定義SQLを実行する場合は，HiRDBのクライアント環境変数として「PDDDLDEAPRP=YES」を設定する必要があります。

注※2　JDBCのDatabaseMetaData#supportsStatementPooling()の戻り値がtrueの場合に，利用できます。

なお，XDM/RD E2を使用する場合はXDM/RD E2 11-03以降のバージョンとHiRDB Type4 JDBC Driver 08-02以降を使用するときにだけステートメントプーリング機能を使用できます。ステートメントプーリング機能の設定については，「3.14.10　実行環境での設定」を参照してください。

(2)　ステートメントプーリングの動作

リソースアダプタのコンフィグレーションプロパティで設定するステートメントプーリングの動作について説明します。

ステートメントプーリング機能の動作を，次の表に示します。

表3‒56　ステートメントプールの状態と動作

ユーザアプリケーションプログラム処理

ステートメントプールの状態

ステートメントプールの動作

PreparedStatement，CallableStatementの生成を要求

プール内に未使用状態のPreparedStatement，CallableStatementがある

プール内で未使用状態のPreparedStatement，CallableStatementの一つが選択され，ユーザアプリケーションプログラムに渡されます。選択されたPreparedStatement，CallableStatementは，プール内で使用中状態になります。

プール内に未使用状態のPreparedStatement，CallableStatementがなく，プール内のPreparedStatement，CallableStatementの総数が「PreparedStatementPoolSize」，「CallableStatementPoolSize」の値に満たない

新規にPreparedStatement，CallableStatementを生成します。生成したPreparedStatement，CallableStatementはユーザアプリケーションに渡され，PreparedStatement，CallableStatementはプール内で使用中状態となります。

プール内に未使用状態のPreparedStatement，CallableStatementがなく，プール内のPreparedStatement，CallableStatementの総数が「PreparedStatementPoolSize」，「CallableStatementPoolSize」の値以上

タイムスタンプが最も古い※PreparedStatement，CallableStatementをプールから削除したあと，新規にPreparedStatement，CallableStatementを生成します。生成したPreparedStatement，CallableStatementはユーザアプリケーションに渡され，PreparedStatement，CallableStatementはプール内で使用中状態となります。

PreparedStatement，CallableStatementを解放

−

PreparedStatement，CallableStatementはプール内で未使用状態に戻ります。

（凡例）　−：該当なし

注※　プール内のPreparedStatement，CallableStatementのタイムスタンプが更新されるタイミングは，次のとおりです。

新規に生成したPreparedStatement，CallableStatementがプールに追加されるとき

プール内のPreparedStatement，CallableStatementが使用中状態になるとき

(3)　ステートメントプーリング機能を使用する場合の注意事項

ステートメントプーリング機能を使用する場合の注意事項を次の表に示します。

表3‒57　ステートメントプーリング機能を使用する場合の注意事項

条件

注意事項

−

ステートメントプーリング機能を使用しない場合と比べて，プールされているPreparedStatement，CallableStatementの数だけメモリが消費されます。各ステートメントのメモリ使用量については，使用するJDBCドライバのマニュアルを参照してください。

ステートメントプールは，コネクションプール内のコネクションごとにあるため，プールされるPreparedStatement，CallableStatementの最大数は，「MaxPoolSize」×（「PreparedStatementPoolSize」＋「CallableStatementPoolSize」）となります。

ステートメントオブジェクトを保持することで，JDBCドライバやDBサーバへ与える影響については，ご利用のDBサーバの仕様を確認してください。

−

ステートメントプーリング機能をコネクション数調節機能またはコネクション障害検知機能と併用した場合，コネクションプールから取り除かれた未使用コネクションは，コネクションプール内のコネクション数としてカウントされません。このため，プールされているPreparedStatement，CallableStatementの数がコネクションプールの最大値×PreparedStatementPoolSize，およびコネクションプールの最大値×CallableStatementPoolSizeを一時的に超える場合があります。

ステートメントプーリング機能を使用してステートメントを再利用する場合，setMaxFieldSizeの設定値が初期化されないことがあります。

初期化されないのは，次の条件がすべて重なるときです。

・Oracle JDBC Thin Driverに対応したDB Connectorを使用した

・setMaxFieldSizeメソッドを使用して，java.sql.PreparedStatement，またはjava.sql.CallableStatementの値を変更した

OracleまたはSQL Serverに接続

ステートメントプーリング機能と，コネクションの障害検知機能を併用する場合

コネクションの障害検知に使用されるPreparedStatementがコネクションごとに一つプーリングされます。そのため，PreparedStatementPoolSize，CallableStatementPoolSizeを決定する際には，コネクションの障害検知用のPreparedStatementもリソース数の見積もりに加えて，CallableStatementPoolSizeを最大ステートメント数未満に設定してください。※

ステートメントプーリング機能と，コネクションプールのウォーミングアップ機能を併用する場合

コネクションが生成されてプーリングされるときに，コネクションの障害検知に使用されるSQLで生成したPreparedStatementがコネクションごとに一つプーリングされます。

ステートメントプーリング機能と，リザルトセットの保持機能を併用する場合

Oracle接続でリザルトセットの保持機能を使用する場合，Connection.prepareStatement()メソッドまたはprepareCall()メソッドの引数にリザルトセットの保持機能を指定してください。Connection.setHoldability()メソッドでは，リザルトセットの保持機能は指定できません。

（凡例）　−：該当なし

注※

コネクションの障害検知機能を使用する場合には，CallableStatementPoolSizeを最大ステートメント数未満に設定してください。

コネクションの障害検知機能を使用すると，プーリングされているCallableStatementの数が最大ステートメント数に達したとき，コネクションの障害検知が実行されます。このとき，CallableStatementPoolSize=＜最大ステートメント数＞と設定していると，JDBCドライバの一つのコネクションで利用できるリソース数の最大値を超えるため，例外が発生します。例外が発生すると障害が発生したと判断されるので，そのコネクションはコネクションプールから削除され，同時にステートメントプールも破棄されます。つまり，ステートメントプーリング機能を使用する意味がなくなってしまいます。

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

ライトトランザクションとは，ローカルトランザクションに最適化された環境を提供する機能です。これによって，良好なローカルトランザクション処理性能を得られます。ライトトランザクションは，ローカルトランザクションだけを使用する場合に適用できます。ライトトランザクション機能を有効にした場合，呼び出し先がBMTのときだけ，トランザクション中のEJBリモート呼び出しができます。

ライトトランザクション機能は，デフォルトでは有効となっています。ライトトランザクション機能を有効にした状態で，グローバルトランザクションを使用するとエラーになります。このため，グローバルトランザクションを使用する場合には，ライトトランザクション機能を無効にする必要があります。

ライトトランザクション機能を有効にするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.4.12　実行環境での設定」を参照してください。

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

アプリケーションサーバでは，トランザクションサービスをJ2EEサーバのインプロセスで起動できます。インプロセスでトランザクションサービスを起動すると，トランザクション処理をJ2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムを実現できます。

インプロセストランザクションサービスは，CORBAで規定されたOTS1.3の仕様をサポートしています。

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

J2EEアプリケーションからデータベースにアクセスする場合，JNDIインタフェースを使用してjavax.sql.DataSource型のオブジェクト（以降，DataSourceオブジェクト）の検索を要求します。J2EEサーバのデフォルトの動作では，該当するDataSourceが登録されている場合に，DataSourceオブジェクトのインスタンスを生成してアプリケーションに返します。

このとき，DataSourceオブジェクトのキャッシングを使用すると，J2EEサーバは，登録されているDataSourceオブジェクトのインスタンスをキャッシングして，検索の要求に対して同じインスタンスを返します。DataSourceオブジェクトのキャッシングを使用すると，DataSourceオブジェクトの検索時間が短くなります。

DataSourceオブジェクトのキャッシングをするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.14.10　実行環境での設定」を参照してください。

(1)　前提条件

DataSourceオブジェクトのキャッシング機能は，Enterprise Beanのビジネスメソッド，およびサーブレット/JSPのサービスメソッド内でDataSourceをルックアップし，該当するインスタンスをメンバ変数などに保持しない場合に有効です。

ビジネスメソッドやサービスメソッド内でルックアップしたDataSourceオブジェクトをメンバ変数に保持し，ほかのメソッドでも利用する場合は有効ではありません。また，Enterprise BeanのejbCreateメソッドやサーブレット/JSPのinitメソッドなどの初期化メソッド内でルックアップしたDataSourceオブジェクトをメンバ変数に保持し，ビジネスメソッドやサービスメソッドで使用する場合も有効ではありません。

(2)　注意事項

DataSourceオブジェクトのキャッシング機能を使用する場合に，次に示すようなリソースアダプタを使用すると，動作時に属性ファイルの<resource-ref>の定義が有効にならないことがあります。

同一J2EEコンポーネントから同一リソースに対して複数の<resource-ref>タグを定義し，それぞれの<resource-ref>タグにある<res-sharing-scope>タグや<res-auth>タグに異なる値を指定した，リソースアダプタを使用する。

同一J2EEコンポーネントで複数の<resource-ref>タグを定義する場合は，別のリソース（デプロイ単位が別になるリソースアダプタ）を使用するようにしてください。

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

DB Connectorでは，コンテナ管理のサインオンとコンポーネント管理のサインオンをサポートしています。

それぞれの方法の特徴を次に示します。

コンテナ管理でのサインオンの場合

コンテナ管理のサインオンを使用する場合，DB Connectorで設定するユーザ名とパスワードを使用して，データベースにアクセスします。

コンポーネント管理でのサインオンの場合

コンポーネント管理でのサインオンを使用する場合，コネクションファクトリのgetConnectionメソッドに渡されたユーザ名とパスワードを使用してデータベースにアクセスします。

なお，DBConnector_DABJ_XA.rarを使用する場合（グローバルトランザクションを使用する場合），XAOpen文字列に指定されたユーザ名とパスワードだけが有効となります。このため，getConnectionメソッドでユーザ名とパスワードを指定して利用する，コンポーネント管理でのサインオンはできません。

コンテナ管理のサインオンをするときに，サインオンの最適化機能を使用すると，コンテナ管理でのサインオン動作が最適化され，データベースとのコネクション取得のパフォーマンスが向上します。

DB Connectorのコンテナ管理でのサインオンの最適化をするための設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.14.10　実行環境での設定」を参照してください。

注意事項

コンテナ管理でのサインオンの最適化は，コンポーネント管理のサインオンをしない場合に使用してください。コンテナ管理でのサインオンの最適化をすると，コンポーネント管理でのサインオンは利用できなくなります。

3.14.9　cosminexus.xmlでの定義

パフォーマンスチューニングのための機能のうち，コネクションシェアリングの定義は，cosminexus.xmlの<rar>タグ内に指定します。cosminexus.xmlでのパフォーマンスチューニングのための機能の定義について次の表に示します。

表3‒58　cosminexus.xmlでのパフォーマンスチューニングのための機能の定義

指定するタグ

設定内容

<resource-external-property>−<res-sharing-scope>タグ

取得したコネクションを共有するかどうかを設定します。

cosminexus.xmlについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

3.14.10　実行環境での設定

パフォーマンスチューニングのための機能を使用する場合，J2EEサーバの設定，リソースアダプタの設定，およびJ2EEアプリケーションの設定が必要です。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。パフォーマンスチューニングの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのパフォーマンスチューニングのための機能の定義について，次の表に示します。

表3‒59　簡易構築定義ファイルでのパフォーマンスチューニングのための機能の定義

項目

指定するパラメタ

設定内容

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

ejbserver.connectionpool.sharingOutsideTransactionScope.enabled

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

コネクションアソシエーション

ejbserver.connectionpool.association.enabled

コネクションアソシエーション機能を使用するかどうかを指定します。

ejbserver.connectionpool.association.enabledDespiteUnshareableSetting

システムプロパティには，リソースの非共有を設定している場合※も，コネクションアソシエーション機能を使用するかどうかを指定します。

ステートメントプーリング機能のステートメントの初期化

ejbserver.connector.statementpool.clear.backcompat

ステートメントプーリング機能でステートメントを再利用する際に初期化するステートメントの内容を指定します。

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

ejbserver.jndi.cache.reference

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

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

ejbserver.connectionpool.applicationAuthentication.disabled

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

障害検知のタイムアウト

ejbserver.connectionpool.validation.timeout

コネクション障害検知機能のタイムアウト時間およびコネクション数調節機能によるコネクション削除処理のタイムアウト時間を指定します。

注※　WAR属性ファイル，Entity Bean属性ファイル，Session Bean属性ファイル，またはMessage-driven Bean属性ファイルの<res-sharing-scope>タグで，Unshareable（リソースを共有しない）を指定している場合のことです。

ライトトランザクションの設定については，「3.4.12　実行環境での設定」を参照してください。

なお，インプロセストランザクションサービスは，デフォルトの設定で使用される機能です。設定は不要です。

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

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

実行環境でのリソースアダプタの設定は，サーバ管理コマンドおよび属性ファイルを使用します。パフォーマンスチューニングのための機能の定義には，Connector属性ファイルを使用します。

Connector属性ファイルでのパフォーマンスチューニングのための機能の定義について次の表に示します。

表3‒60　Connector属性ファイルでのパフォーマンスチューニングのための機能の定義

分類

項目

指定するタグ

設定内容

コネクションプーリング

コネクションの最小値と最大値

<property>タグのMinPoolSizeとMaxPoolSize

コネクションプールにプールするコネクションの最小値と最大値を指定します。

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

<property>タグのWarmup

コネクションプールのウォーミングアップ機能を使用する指定をします。

コネクション管理スレッド

<property>タグのNetworkFailureTimeout

コネクション管理スレッドを使用するかどうかを指定します。

コネクション管理スレッドを使用する場合，コネクションの障害検知機能，およびコネクション数調節機能のタイムアウトが有効になります。タイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキーに，任意の時間を指定できます（デフォルト値は5秒）。

コネクション数調節機能

<property>タグのConnectionPoolAdjustmentInterval

コネクション数調節機能が動作する間隔を指定します。

なお，コネクション数調節機能にタイムアウトを設定する場合には，NetworkFailureTimeoutでコネクション管理スレッドの使用を有効にします。※1

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

PreparedStatementのプールサイズ※2

<config-property>タグのPreparedStatementPoolSize

PreparedStatementのプールサイズを指定します。

CallableStatementのプールサイズ※2

<config-property>タグのCallableStatementPoolSize

CallableStatementのプールサイズを指定します。

注※1　コネクションの障害検知機能のタイムアウトと同じキーです。このため，コネクションの障害検知機能でタイムアウトを使用する場合は，コネクション数調節機能でもタイムアウトを使用する設定となります。

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

Connector属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

(3)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。パフォーマンスチューニングのための機能の定義には，WAR属性ファイル，Session Bean属性ファイル，Entity Bean属性ファイルまたはMessage-driven Bean属性ファイルを使用します。

これらの属性ファイルで指定するタグは，cosminexus.xmlまたはDDと対応しています。なお，cosminexus.xmlでの定義については，「3.14.9　cosminexus.xmlでの定義」を参照してください。

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

この節では，フォールトトレランスのための機能について説明します。

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

表3‒61　この節の構成（フォールトトレランスのための機能）

分類

タイトル

参照先

解説

コネクションの障害検知

3.15.1

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

3.15.2

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

3.15.3

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

3.15.4

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

3.15.5

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

3.15.6

コネクションスイーパ

3.15.7

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

3.15.8

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

3.15.9

障害調査用SQLの出力

3.15.10

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

3.15.11

実装

cosminexus.xmlでの定義

3.15.12

設定

実行環境での設定

3.15.13

注　「運用」について，この機能固有の説明はありません。

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

コネクションプーリングを使用している場合，リソースダウン・ネットワーク障害などが発生すると，ユーザプログラムのコネクション取得要求に対し，障害が発生したコネクションを返すおそれがあります。コネクションの障害検知機能を使用すると，プーリングされているコネクションに障害が発生していないかをチェックし，障害が発生したコネクションをなるべく返さないようにできます。

コネクション障害検知機能は，コネクション取得リトライ機能と併用できます。この場合，ユーザプログラムのコネクション取得要求時にコネクション障害を検知すると，新しいコネクション取得のリトライを実施し，障害が復旧した時点でコネクションをユーザプログラムに返すことができます。

なお，新しいコネクションを作成して返すことは，コネクションの障害検知のタイミングを「コネクション取得要求時」に設定している場合だけ有効になります。

コネクションの障害検知のタイミングについては，「(2)　障害検知を実施するタイミング」を参照してください。

(1)　前提条件

コネクションの障害検知機能の利用可否を次の表に示します。

表3‒62　コネクションの障害検知機能の利用可否

リソース

接続方法

利用可否

データベース

DB Connector

○

データベース上のキュー

DB Connector for Reliable MessagingとReliable Messaging

○

OpenTP1

TP1 Connector

　 ×※1

TP1/Message Queue - Access

　 ×※1

SMTPサーバ

メールコンフィグレーション

×

JavaBeansリソース

−

×

そのほかのリソース

Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ

　 △※2

（凡例）○：使用できる　×：使用できない　△：条件によって異なる　−：該当なし

注※1　アプリケーションサーバが提供するコネクションの障害検知機能は使用できませんが，TP1 ConnectorまたはTP1/Message Queue - Accessでは，コネクションの障害検知機能と同様の機能が提供されています。

注※2　Connector 1.5仕様に準拠したリソースアダプタを使用している場合に，リソースアダプタがValidatingManagedConnectionFactoryインタフェースのgetInvalidConnectionsメソッドを実装しているときに使用できます。

(2)　障害検知を実施するタイミング

コネクションの障害を検知するタイミングは，表に示したタイミングのどちらかを選択できます。

表3‒63　コネクションの障害検知のタイミング

障害検知のタイミング

内容

コネクション取得要求時

コネクション取得時に，毎回，障害検知を実施します。この場合，コネクション取得要求のレスポンス性能が劣化しますが，障害が発生したコネクションを取得する確率は低くなります。コネクション取得要求の頻度が少ない場合や，障害が発生したコネクションの取得がほとんど許容されない場合に有用です。

一定間隔

一定時間の間隔で，障害検知を実施します。障害検知の間隔をある程度長くすることで，障害検知処理による性能劣化を少なくできます。ただし，障害が発生したコネクションを取得する確率は高くなります。コネクション取得要求の頻度が多い場合や，障害が発生したコネクションの取得がある程度許容される場合に有用です。

なお，デフォルトでは，コネクション取得要求時に障害検知を実施する設定となっています。コネクションの障害検知を実施しない設定もできます。

コネクション障害検知の有効・無効の切り替えや，検知するタイミングの設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，「3.15.13　実行環境での設定」を参照してください。

(3)　障害検知のタイムアウト

コネクション障害検知に対する応答時間にタイムアウトを設定できます。

サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション障害検知の実行に対しても応答が返らなくなることがあります。タイムアウトを設定することで，リソースからの応答が返らない場合も，コネクションのチェックを終了して，処理を継続できます。なお，障害検知のタイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキーに，任意の時間を指定できます（デフォルト値は5秒）。

コネクション障害検知のタイムアウトは，コネクション管理スレッドを使用して動作します。コネクション管理スレッドは，コネクションプールのコネクション数の最大値に応じてリソースアダプタ開始時にシステム内で作成されます。コネクション管理スレッドの数と，コネクションプールのコネクション数の最大値の関係を次に示します。

コネクション管理スレッド数 = コネクションプールのコネクション数の最大値×2

このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費します。必要なメモリ使用量を適切に見積もってください。

また，コネクションプールのコネクション数の最大値の設定が無制限の場合，メッセージが出力されて，コネクション障害検知のタイムアウトが無効になります。

なお，コネクション障害検知のタイムアウトを有効にする場合の注意事項の詳細については，「(5)　注意事項」を参照してください。

コネクション障害検知のタイムアウトの有効・無効は，リソースアダプタのプロパティをカスタマイズして設定します。リソースアダプタのプロパティの設定については，「3.15.13　実行環境での設定」を参照してください。

(4)　チェック時の動作

コネクション障害検知をコネクション取得要求時に実施する場合と，一定間隔で実施する場合の動作について説明します。

コネクション障害検知をコネクション取得要求時に実施する場合

コネクション障害検知をコネクション取得要求時に実施する場合の動作を次に示します。

コネクションプールから未使用コネクションが取得されます。

コネクションチェックメソッドによって，コネクションに障害が発生していないかどうかチェックされます。

コネクション障害検知のタイムアウトが無効な場合，このチェックはコネクション取得要求の延長で実施されます。

コネクション障害検知のタイムアウトが有効な場合，このチェックはコネクション管理スレッドで実施されます。サーバ障害やネットワーク障害などでチェックメソッドの応答がタイムアウト時間以内に返らないときは，コネクションに障害が発生していると判断されます。このとき，メッセージが出力されます。

なお，リソースアダプタにコネクションチェックメソッドが実装されていない場合，コネクションの状態はチェックされません。

コネクションに障害が発生している場合，チェックに使用したコネクションが破棄されて，新たに作成されたコネクションがユーザプログラムに返されます。

コネクションに障害が発生していない場合，チェックに使用したコネクションがユーザプログラムに返されます。

コネクション障害検知を一定間隔で実施する場合

コネクション障害検知を一定間隔で実施する場合の動作を次に示します。

コネクションプールから未使用コネクションが一つ取得されて，そのコネクションが有効であるかどうかがチェックされます。

ただし，未使用コネクションがプーリングされていない場合は，チェックされません。

コネクション障害検知のタイムアウトが無効な場合，コネクションチェックメソッドによって，コネクションに障害が発生していないかどうかのチェックが一定間隔で実施されます。

コネクション障害検知のタイムアウトが有効な場合，コネクション管理スレッドで，チェックが一定間隔で実施されます。サーバ障害やネットワーク障害などでチェックメソッドの応答がタイムアウト時間以内に返らないときは，コネクションに障害が発生していると判断されます。このとき，メッセージが出力されます。

なお，リソースアダプタにコネクションチェックメソッドが実装されていない場合，コネクションの状態はチェックされません。

コネクションに障害が発生している場合に，コネクション障害検知のタイムアウトが無効のときは，コネクションチェックに使用されたコネクションが破棄されて，コネクションプール内の使用中コネクションが再利用不可にマークされます。また，未使用コネクションが破棄されます。

コネクション障害検知のタイムアウトが有効のときは，コネクションチェックに使用したコネクションが破棄されて，コネクション管理スレッドによってコネクションプール内の使用中コネクションが再利用不可にマークされます。また，未使用コネクションが，コネクションプールから取り除かれて，破棄されます。

コネクションに障害が発生していない場合は，コネクションチェックに使用されたコネクションがコネクションプールに返却されます。

(5)　注意事項

障害検知機能についての注意事項を説明します。

(a)　パラレルサーバ構成のリソースを使用する場合の注意事項

コネクション障害検知を一定間隔で実施する場合，コネクションプール内のコネクションをサンプリングチェックするため，一部のサーバに障害が発生しても検知できないことがあります。

(b)　コネクション障害検知のタイムアウトを有効にした場合の注意事項

コネクション障害検知のタイムアウトを有効にした場合の注意事項を次に示します。

コネクション障害検知にタイムアウトを設定した場合，システム内で，コネクションプールのコネクション数に応じた障害検知用のスレッドが生成されます。このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費するので注意が必要です。

障害検知用のスレッドは，コネクションプールの最大コネクション数の2倍の数だけ作成されます。必要なメモリ使用量を適切に見積もってください。

サーバ障害やネットワーク障害などが繰り返し発生する場合にシステムの運用を続けると，コネクションチェックメソッドを実行中のコネクション管理スレッドが増え続け，システム側が用意したすべてのコネクション管理スレッドを使い切るおそれがあります。使用できるコネクション管理スレッドがない場合，メッセージが出力されて，コネクション取得要求がエラーとなります。

コネクション障害検知を実施する場合，コネクションプールから取り除いた未使用コネクションは，コネクションプール内のコネクション数としてカウントされません。そのため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールのコネクション数の最大値を一時的に超える場合があります。

(c)　障害検知機能を利用できないリソースを使用する場合の注意事項

障害検知機能を利用できないリソースに対しては，Connector属性ファイルで次のパラメタを指定して，コネクション管理スレッドを使用しない設定にしてください。

コネクションの障害検知のタイムアウト

<property>タグのValidationType=0

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

コネクションがコネクションプールに指定した最大コネクション数までプールされていて，利用できるコネクションがプール中にない状態を，コネクション枯渇といいます。

コネクション枯渇状態のときには，コネクション取得要求を待ち状態にできます。待ち状態になっているコネクション取得要求は，コネクションが解放されるとすぐにコネクションを取得できます。これによって，コネクション枯渇時に，効率良くコネクションを取得できます。コネクション枯渇時の取得待ちについて，次の図で説明します。

図3‒35　コネクション枯渇時のコネクション取得待ち

この図では，コネクションプールの最大数は2となっています。このため，四つのgetConnectionからコネクション取得要求があっても，二つまでしか処理できません。最初の二つのコネクションの取得要求については，コネクションプールにコネクションがあるため，コネクションの取得ができます。残りの二つについては，コネクション枯渇の状態になるため，コネクション取得待ちのキューに入り，コネクションが解放されるのを待ちます。

なお，コネクション取得待ちは，コネクションプールを利用している場合に設定できます。

コネクション取得待ちをする場合には，リソースアダプタのプロパティとして，次の二つの内容を設定する必要があります。

コネクション枯渇時にコネクションの取得待ちをするかどうか

コネクション取得待ちの最大時間

リソースアダプタの設定については，「3.15.13　実行環境での設定」を参照してください。

(1)　コネクション枯渇時の動作

コネクション取得待ちを設定している場合，コネクション枯渇時のコネクション取得要求は待ち状態になります。コネクション取得要求の待ち時間が最大待ち時間を越えた場合，ユーザプログラムに例外をスローします。

また，コネクション取得要求を再開するタイミングは，次のどちらかになります。

コネクションが解放されて，未使用コネクションができたとき

コネクションが破棄されて，コネクション数が最大数未満になったとき

なお，コネクション取得要求の再開後にエラーが発生した場合，コネクション取得のリトライ機能が有効になっているときは，リトライ処理が実施されます。

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

コネクション取得リトライは，使用できるコネクションがコネクションプールにない場合や，物理コネクションの確立に失敗した場合に，自動的にコネクションの取得をリトライする機能です。コネクション取得リトライ機能を使用することで，コネクション取得に失敗した場合に，ユーザプログラムでリトライをする必要がなくなります。

次の条件のどちらかに当てはまる場合に，コネクション取得をリトライできます。

次のすべての条件を満たし，使用できるコネクション（未使用状態のコネクション）がコネクションプールにない場合

コネクション枯渇時のコネクション取得待ち行列が無効。

コネクションプールのコネクション総数がプーリングするコネクションの最大数に達している。

次の条件のどれかで物理コネクションの確立に失敗した場合

コネクションプールのコネクション総数がプーリングするコネクションの最大数に達していて，認証情報が一致する未使用状態のコネクションがない。

コネクションプールのコネクション総数がプーリングするコネクションの最大数に達していない。

コネクションプーリングが無効。

なお，リトライしてもコネクションが取得できない場合は，アプリケーションプログラムに例外が通知され，コネクションの取得は失敗します。

コネクションプールが枯渇したときの動作は，「3.15.2　コネクション枯渇時のコネクション取得待ち」に従います。

コネクション取得リトライを実施する場合には，リソースアダプタのプロパティとして，次の二つの内容を設定する必要があります。

リトライの回数

リトライする回数を設定します。

リトライまでの間隔

次のリトライまでの間隔を秒単位で設定します。

なお，リトライの回数，およびリトライまでの間隔を大きくすると，コネクション取得処理が重なった場合に，待ちが発生するおそれがあります。

リソースアダプタの設定については，「3.15.13　実行環境での設定」を参照してください。

(1)　前提条件

コネクション取得のリトライ機能を使用するための前提条件を次の表に示します。

表3‒64　コネクション取得のリトライ機能の利用

リソース

接続方法

利用可否

データベース

DB Connector

○

データベース上のキュー

DB Connector for Reliable MessagingとReliable Messaging

○

OpenTP1

TP1 Connector

○

TP1/Message Queue - Access

○

SMTPサーバ

メールコンフィグレーション

×

JavaBeansリソース

−

×

そのほかのリソース

Connector 1.0仕様またはConnector 1.5仕様に準拠したリソースアダプタ

○

（凡例）○：使用できる　×：使用できない　−：該当なし

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

コネクションプール内のコネクションの情報は，cjlistpoolコマンドを使用して表示できます。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistpool（コネクションプールの一覧表示）」を参照してください。

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

データベースサーバのダウンなどによって，コネクションが切断された場合，プールされているコネクションはコネクションプール内に残ってしまいます。これらのコネクションは，cjclearpoolコマンドによって削除できます。

なお，コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjclearpool（コネクションプール内のコネクション削除）」を参照してください。

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

ユーザプログラムがオープンしたリソースのコネクションは，ユーザプログラムでクローズする必要があります。例外発生などの理由で，ユーザプログラムがコネクションをクローズすることができない場合，WebコンテナやEJBコンテナが自動的にコネクションをクローズする機能があります。

コネクション自動クローズ機能は，機能によって有効と無効を切り替えることができます。コネクションの自動クローズの方法と切り替えについて次の表に示します。

表3‒65　コネクション自動クローズの方法と機能の切り替え

自動クローズの方法

有効と無効の切り替え

備考

Webコンテナによるコネクション自動クローズ

○※1，※2

−

EJBコンテナによるコネクション自動クローズ

×※1

常に有効になります。

（凡例）○：切り替えできる　×：切り替えできない　−：該当しない

注※1　対象リソースは，リソースアダプタのコネクションとなります。

注※2　Webコンテナによるコネクションの自動クローズ機能は，デフォルトでは有効となっています。無効にする場合は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.15.13　実行環境での設定」を参照してください。

(1)　Webコンテナによるコネクション自動クローズ

サーブレットやJSPのサービスメソッド内で，取得・オープンされたJDBCコネクションのうち，メソッドの実行完了時にクローズが実行されていないコネクションに対して，J2EEコンテナ側で自動的にコネクションをクローズします。これによって，オープンされたまま蓄積しているコネクションを自動でクローズできます。

なお，コネクションの自動クローズ機能は，サーブレット内部の別のメソッド，または外部のクラスでコネクションを取得・利用した場合にも有効です。

Webコンテナによるコネクション自動クローズは，サーブレットやJSPのserviceメソッドが完了したときに実行されます。

(2)　EJBコンテナによるコネクション自動クローズ

例外発生などの理由で，EJB内で取得したリソースのコネクションをユーザがクローズできない場合に，EJBコンテナが自動的にコネクションをクローズして解放する機能です。

EJBコンテナによるコネクションの自動クローズは，次のタイミングで実施されます。

EJBが破棄されるとき

Stateless Session Beanで，ビジネスメソッドがリターンするとき

Stateful Session Beanがパッシベイトされるとき

Singleton Session Beanで，ビジネスメソッドがリターンするとき

なお，@Asynchronousアノテーションを指定したSingleton Session BeanまたはStateless Session Beanでは，次のタイミングでコネクションの自動クローズが実行されます。

Singleton Session BeanまたはStateless Session Beanのインスタンスが破棄された時

Singleton Session BeanまたはStateless Session Bean内の@Asynchronousアノテーションを指定したメソッドの実行が完了した時

(3)　コネクション自動クローズが実行されたことを確認する方法

コネクション自動クローズが実行されたことは，メッセージログまたはPRFトレースで確認できます。

テスト実行時や障害調査時など，性能を考慮しなくてよい場合は，メッセージログによって確認することをお勧めします。実運用時に確認したい場合は，PRFトレースによって確認することをお勧めします。

(a)　メッセージログで確認する方法

ログレベルを「Warning」に設定してください。

コネクション自動クローズが実行された場合は，J2EEサーバのメッセージログにKDJE31010-Wが出力されます。

ログレベルの設定方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「3.3.6　J2EEサーバのログ取得の設定」を参照してください。

(b)　PRFトレースでの確認方法

JCAコンテナの機能レイヤのPRFトレース取得レベルを「詳細」に設定してください。

コネクション自動クローズが実行された場合は，PRFトレースファイルに次のイベントIDが出力されます。

0x8B84

0x8B85

PRFトレースの取得レベルの設定方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「3.3.6　J2EEサーバのログ取得の設定」を参照してください。また，機能レイヤごとのPRFトレース取得レベルの設定方法については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cprflevel（PRFトレース取得レベルの表示と変更）」またはマニュアル「アプリケーションサーバ リファレンス コマンド編」の「cprfstart（PRFデーモンの開始）」を参照してください。

(4)　注意事項

Servlet/JSPでユーザが生成したスレッド（ユーザスレッド）で取得したコネクションは，自動クローズされません。

自動クローズの際に，未決着のJDBCトランザクションがあった場合，JDBCトランザクションはロールバックされます。また，ユーザプログラムでコネクションをクローズした際に，未決着のJDBCトランザクションがあった場合，暗黙的にコミットされます。

3.15.7　コネクションスイーパ

コネクションスイーパは，一定間隔でコネクションプールを監視し，一定時間使用していない未使用コネクションを破棄する機能です。該当コネクションを最後に利用した時点からの経過時間が，指定された時間以上の場合に，コネクションを破棄します。この機能は，アプリケーションサーバとデータベースサーバ間にファイアウォールなどのゲートウェイが存在し，コネクションが一定時間で切断されるケースなどに使用できます。

コネクションスイーパ機能は，デフォルトでは無効になっています。なお，コネクションスイーパ機能の設定は，リソースアダプタのプロパティとして設定します。リソースアダプタの設定については，「3.15.13　実行環境での設定」を参照してください。

なお，コネクションスイーパを使用する場合，Connector属性ファイルの<property>タグでConnectionTimeoutとSweeperIntervalの合計値がコネクション切断時間未満になるように設定してください。また，ConnectionTimeoutを長めに設定することで，コネクションを保持する期間を長くできます。

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

トランザクションタイムアウト機能とは，トランザクションの開始時点からの経過時間を監視し，指定された時間が経過した時点※でトランザクションをロールバックする機能です。監視期間は，トランザクションの開始完了時点から，トランザクションの決着開始時点までです。トランザクションタイムアウトが発生したあと，該当するトランザクションでのJTA，およびJDBCインタフェースへのアクセスは例外が通知されます。

トランザクションタイムアウト機能は，アプリケーションサーバが管理するトランザクションの場合に有効です。

なお，BMT，サーブレット，またはJSPの場合，トランザクションタイムアウトが発生したあと，該当するトランザクションに対してUserTransaction.commit/rollbackを発行すると，JTA，およびJDBCインタフェースにアクセスできるようになります。

注※　タイムアウトしたかどうかを1秒ごとに確認するため，トランザクションタイムアウトの設定時刻に対して最大1秒の誤差が発生します。

(1)　トランザクションタイムアウトの設定

トランザクションタイムアウトの設定は，J2EEサーバ，UserTransactionインタフェース，またはEJBのCMT属性で設定できます。

(a)　J2EEサーバでの設定

J2EEサーバでの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.15.13　実行環境での設定」を参照してください。

(b)　UserTransactionインタフェースでの設定

UserTransactionインタフェースのsetTransactionTimeoutメソッドを使用して，デフォルト値から変更できます。

(c)　EJBのCMT属性での設定

EJBのCMT属性で設定するには，サーバ管理コマンドを使用して設定します。設定単位は，Bean単位，インタフェース単位，およびメソッド単位の三つから選択できます。設定が有効になるメソッドは，次のどちらかです。

トランザクション属性が「Required」に設定され，EJBコンテナがトランザクションを開始するメソッド

トランザクション属性が「RequiresNew」に設定されたメソッド

クライアントから伝播するトランザクションで動作するSupports属性およびMandatory属性の場合，トランザクションを使用しないNotSupported属性およびNever属性の場合は，タイムアウトの設定は無効になります。なお，トランザクション属性については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.3　CMT」を参照してください。

なお，設定の優先順位は，次のとおりです。

メソッド単位での設定

インタフェース単位での設定

Bean単位での設定

J2EEサーバでの設定

Bean単位のトランザクションタイムアウトの設定は，J2EEアプリケーションに含まれるSession Bean，Entity BeanまたはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，「3.15.13　実行環境での設定」を参照してください。

(2)　トランザクションタイムアウト発生時のステートメントキャンセル

実行中のSQL処理が返ってこない状態でトランザクションタイムアウトが発生すると，ステートメントがキャンセルされます。

ステートメントのキャンセルを有効にする場合，DB ConnectorのCancelStatementプロパティにtrueを設定する必要があります。リソースアダプタの設定については，「3.15.13　実行環境での設定」を参照してください。

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

J2EEサーバやリソースマネジャの障害で，プリペア状態またはヒューリスティック完了状態となった2フェーズトランザクションを決着させる機能です。グローバルトランザクションを使用する場合に有効になります。

J2EEサーバを開始すると，インポートされているリソースに対して，無条件にトランザクションの全面回復処理を実行します。また，トランザクション実行中にリソースマネジャがダウンした場合にも，部分回復処理をします。

なお，トランザクションの状態は，インプロセストランザクションサービスを使用している場合，サーバ管理コマンドのcjlisttrnコマンドで表示できます。また，停止中のJ2EEサーバのステータスファイルに残っている，未決着トランザクション情報はcjlisttrnfileコマンドで表示できます。

ライトトランザクションが有効なときには，トランザクションリカバリ機能は使用できません。

注意事項

J2EEサーバ再起動によるトランザクションリカバリをしない場合，トランザクションの回復は各リソースの回復手順に従い，ユーザ責任で手動回復してください。

(1)　J2EEサーバ終了時の未決着トランザクションの確認とタイムアウトの設定

J2EEサーバを正常停止する時，J2EEサーバは未決着のトランザクションがないことを確認してから停止します。未決着のトランザクションがあるときは，それらが完了するまで無限に待ちます。また，そのトランザクションが決着するまでリソースを削除できません。

これに対して，システム開発時など，トランザクションを早急に解決する必要がない場合は，未決着トランザクションの確認時間にタイムアウトを設定できます。タイムアウトが発生した場合は，未決着のトランザクションの確認処理が完了していなくても，J2EEサーバの停止処理がされます。ただし，タイムアウトは，J2EEアプリケーション開発時などに設定してください。J2EEアプリケーション運用時には，トランザクションの信頼性を保証するために，タイムアウトを設定しないことをお勧めします。

タイムアウトの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.15.13　実行環境での設定」を参照してください。

(2)　注意事項

トランザクションリカバリについての注意事項を説明します。

(a)　J2EEサーバ起動時にリソースアダプタの開始に失敗した場合の注意

J2EEサーバ起動時にXATransactionを利用するリソースアダプタの開始に失敗した場合，J2EEサーバはトランザクションリカバリを実行しないで，メッセージKDJE48605-Eを出力して強制停止します。この場合は，リソースアダプタの開始処理が失敗する原因を取り除いてから，J2EEサーバを再起動してください。これによって，プリペア状態またはヒューリスティック状態のトランザクションは決着されます。

(b)　J2EEサーバを再起動する時の注意

J2EEサーバが強制終了または異常終了したあと，リソースを削除するとリカバリできなくなります。このため，再起動時にリソースの構成を変更しないでください。

強制終了または異常終了前の受信ポートと同じポートで再起動する必要があります。このため，簡易構築定義ファイル内の<configuration>タグ内のパラメタ「ejbserver.distributedtx.recovery.port」の値を変更しないでください。なお，Management Serverを利用しないでシステムを構築する場合は，usrconf.propertiesのejbserver.distributedtx.recovery.portキーを変更しないでください。

(c)　トランザクションリカバリを実行するための権限

リカバリはリソース（XADataSourceなど）に設定したデフォルトユーザで実行します。リソースマネジャによっては，未決着トランザクションの走査に特別な権限や設定が必要になります。また，複数のユーザでサインオンする場合，デフォルトユーザにそのほかのユーザのトランザクションを決着できるリソースマネジャでの適正な権限を付与する必要があります。なお，詳細については，各リソースのマニュアルを参照してください。

Oracleでリカバリをする場合で，JDBCドライバにOracle JDBC Thin Driverを使用するときは，ユーザに次の権限が必要です。

SYS.DBA_PENDING_TRANSACTIONSへのSELECT権限

FORCE ANY TRANSACTION権限

SYS.DBMS_SYSTEMをEXECUTEする権限

Oracleを使用する場合の設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「4.1.7　データベース接続環境を設定する（Oracleの設定）」を参照してください。

(d)　使用するコネクション数

トランザクションリカバリをする場合に使用するコネクション数に注意してください。

J2EEサーバでは，トランザクションサポートレベルがXATransactionの一つのリソースアダプタに対して，次のコネクションを確立します。

コネクションプールにプーリングされるコネクション

リカバリ用のコネクション（一つ）

同一のリソースマネジャで必要となる最大コネクション数は，次の式で示す値になります。リソースマネジャにコネクション数の上限がある場合は，注意してください。

同一のリソースマネジャで必要となる最大コネクション数＝IR(1) + … + IR(N) + N

IR(i)

i番目のリソースアダプタのプール設定値の最大コネクション数。

1≦i≦Nです。

N

Connector 1.0仕様に準拠したリソースアダプタの場合は，同一のリソースマネジャに接続するリソースアダプタ数。

Connector 1.5仕様に準拠したリソースアダプタの場合は，同一のリソースマネジャに接続するリソースアダプタ内のコネクション定義数の総数。

対象になるのは，開始状態で，かつトランザクションサポートレベルがXATransactionのリソースアダプタです。

(3)　トランザクション情報の確認手順

ここでは，稼働中および停止中のJ2EEサーバのトランザクションの情報を確認する方法について説明します。稼働中のJ2EEサーバでのトランザクションの状態や，停止中のJ2EEサーバでの未決着のトランザクションの有無などの情報を確認できます。

(a)　稼働中のトランザクションの確認手順

J2EEサーバで稼働中のトランザクションの情報を確認できます。トランザクションの状態，グローバルトランザクションID，経過時間，ブランチの種類などの情報を確認できます。

稼働中のトランザクションの確認には，cjlisttrnコマンドを使用します。実行形式と実行例を次に示します。

実行形式

cjlisttrn [<サーバ名称>] -bqual

実行例

cjlisttrn MyServer -bqual

また，未決着のトランザクションの状態も確認できます。未決着のトランザクションについての情報を確認するときは，引数に「-pending」を指定します。未決着のトランザクションについての情報を確認する場合の実行形式と実行例を次に示します。

実行形式

cjlisttrn [<サーバ名称>] -pending -bqual

実行例

cjlisttrn MyServer -pending -bqual

cjlisttrnコマンド，および取得できる情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlisttrn（稼働中のJ2EEサーバのトランザクション情報の表示）」を参照してください。

(b)　停止中のトランザクションの確認手順

停止中のJ2EEサーバのトランザクションの情報を確認できます。トランザクションの状態，グローバルトランザクションID，経過時間，ブランチの種類等の情報を確認できます。また，未決着のトランザクションが残っているかどうかも確認できます。

停止中のトランザクションの確認には，cjlisttrnfileコマンドを使用します。実行形式と実行例を次に示します。

実行形式

cjlisttrnfile [<サーバ名称>] -bqual

実行例

cjlisttrnfile MyServer -bqual

J2EEサーバが停止中の状態で未決着のトランザクションが存在する場合は，必要に応じて次の処理を実行して，トランザクションを決着させてください。

J2EEサーバを再起動する（cjstartsvコマンド）

J2EEサーバをリカバリモードで起動する（cjstartrecoverコマンド）

cjlisttrnfileコマンド，および取得できる情報の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlisttrnfile（停止中のJ2EEサーバのトランザクション情報の表示）」を参照してください。

3.15.10　障害調査用SQLの出力

デッドロックやスローダウンなどの障害が発生した場合，発行したSQLが障害の要因となった可能性があります。そこで，発行したSQLをログに出力することによって，障害要因の解析が容易になります。ログに出力されるSQLの情報を障害調査用SQLと呼びます。

(1)　出力されるタイミング

障害調査用SQLは，次のタイミングで出力されます。

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

J2EEアプリケーションの強制停止実行時

メソッドキャンセルコマンド実行時

メソッドタイムアウト発生後のメソッドキャンセル実行時

(2)　出力先

障害調査用SQLは，リソースアダプタの稼働ログ，および性能解析トレースに出力されます。

リソースアダプタの稼働ログでは，KDJE50080-Wのメッセージに出力されます。詳細については，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「KDJE50080-W」を参照してください。

性能解析トレースでは，0x8C41のイベントIDに出力されます。詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.　性能解析トレースのトレース取得ポイントとPRFトレース取得レベル」を参照してください。

(3)　出力内容

出力対象のコネクションでSQLを発行している場合，物理コネクションがSQLを保持しています。この物理コネクションが保持しているSQLが，障害調査用SQLとして出力されます。

SQLを保持する物理コネクション

障害調査用SQLが出力されるタイミングごとに，SQLを保持している物理コネクションを示します。

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

トランザクションに参加しているコネクションに対応する物理コネクション。

J2EEアプリケーションを強制停止した時，メソッドキャンセルコマンド実行時，またはメソッドタイムアウト発生後のメソッドキャンセル実行時

トランザクション処理中の場合，トランザクションに参加しているコネクションに対応する物理コネクション。

トランザクションを使用していない場合，アプリケーション強制停止またはメソッドキャンセルを実行するインスタンスで使用中のコネクションに対応する物理コネクション。なお，クローズしたコネクションは，障害調査用SQL出力の対象外になります。

SQLを保持するAPI

ユーザアプリケーションで次のAPIが呼び出されたとき，引数で渡されたSQLを物理コネクションに保持します。保持するSQLは物理コネクションごとに一つです。APIが呼び出されるたびに，最新のSQLが上書きされます。SQLを保持するAPIを次の表に示します。

表3‒66　SQLを保持するAPIの一覧

インタフェース

メソッド

java.sql.Connection

prepareCall(String sql)

prepareCall(String sql, int resultSetType, int resultSetConcurrency)

prepareCall(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)

prepareStatement(String sql)

prepareStatement(String sql, int autoGeneratedKeys)

prepareStatement(String sql, int[] columnIndexes)

prepareStatement(String sql, int resultSetType, int resultSetConcurrency)

prepareStatement(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)

prepareStatement(String sql, String[] columnNames)

java.sql.Statement

addBatch(String sql)

execute(String sql)

execute(String sql, int autoGeneratedKeys)

execute(String sql, int[] columnIndexes)

execute(String sql, String[] columnNames)

executeBatch()※1

executeQuery(String sql)

executeUpdate(String sql)

executeUpdate(String sql, int autoGeneratedKeys)

executeUpdate(String sql, int[] columnIndexes)

executeUpdate(String sql, String[] columnNames)

java.sql.PreparedStatement

java.sql.Statementから継承した表示対象メソッド

addBatch()※2

execute()※2

executeQuery()※2

executeUpdate()※2

java.sql.CallableStatement

java.sql.PreparedStatementから継承した表示対象メソッド

注※1　executeBatch()メソッドを実行した場合は，最後にaddBatch(String sql)メソッド， addBatch()メソッドで加えられたSQLを物理コネクションに保持します。

注※2　addBatch()メソッド，execute()メソッド，executeQuery()メソッド，executeUpdate()メソッドを実行した場合，java.sql.ConnectionのprepareStatementメソッド，prepareCallメソッドの引数で与えられたSQLを物理コネクションに保持します。ただし，SQLのINパラメタプレースホルダー（"？"）は，置換しないで"？"のまま出力します。

(4)　注意事項

障害調査用SQLの出力機能についての注意事項を説明します。

DB Connectorを使用している場合，この機能は常に有効になります。DB Connector以外を使用している場合は無効になります。

リソースアダプタの稼働ログの障害調査用SQLログに出力されるメッセージが4キロバイトを超えた場合，4キロバイトまでのメッセージだけが出力されます。

コネクションシェアリング，コネクションアソシエーションによって共有されたコネクションは，物理コネクションが一つのため，障害調査用SQLログは一つだけ出力されます。

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

ユーザプログラムでオープンしたStatementオブジェクトなどは，ユーザプログラムでクローズする必要があります。ただし，ユーザプログラムでクローズしなかった場合，DB Connectorは，ユーザハンドル（java.sql.Connection）から生成された，次のオブジェクトを自動的にクローズできます。

Statementオブジェクト

PreparedStatementオブジェクト

CallableStatementオブジェクト

各種ステートメントやDatabaseMetaDataから生成されたResultSetオブジェクト

3.15.12　cosminexus.xmlでの定義

フォールトトレランスのための機能のうち，CMTのトランザクションタイムアウトの定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。cosminexus.xmlでのフォールトトレランスのための機能の定義について次の表に示します。

表3‒67　cosminexus.xmlでのフォールトトレランスのための機能の定義

指定するタグ

設定内容

<message>−<ejb-transaction-timeout>タグ

<entity>−<ejb-transaction-timeout>タグ

<session>−<ejb-transaction-timeout>タグ

CMTの場合のトランザクションをタイムアウトする時間を指定します。

cosminexus.xmlについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

3.15.13　実行環境での設定

ここでは，フォールトトレランスのための機能を使用する場合の設定について説明します。

なお，次に示す機能については事前に設定する必要はありません。

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

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

障害調査用SQLの出力

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

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。フォールトトレランスの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのフォールトトレランスのための機能の定義について，次の表に示します。

表3‒68　簡易構築定義ファイルでのフォールトトレランスのための機能の定義

分類

プロパティ

設定内容

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

ejbserver.webj2ee.connectionAutoClose.enabled

Webアプリケーションでコネクションを自動クローズするかどうかを指定します。

トランザクションタイムアウト（J2EEサーバ単位）※1

ejbserver.jta.TransactionManager.defaultTimeOut

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

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

ejbserver.distributedtx.recovery.port

グローバルトランザクションを使用する場合に，トランザクションのリカバリで使用する固定ポート番号を指定します。

未決着トランザクションの確認時間のタイムアウト※2

ejbserver.distributedtx.recovery.completionCheckOnStopping.timeout

J2EEサーバ停止時に行われるトランザクション仕掛かり完了確認のタイムアウト時間を指定します。

障害検知のタイムアウト

ejbserver.connectionpool.validation.timeout

コネクション障害検知機能のタイムアウト時間およびコネクション数調節機能によるコネクション削除処理のタイムアウト時間を指定します。

注※1　CMTの場合，Enterprise Bean，インタフェース，メソッド単位の設定もできます。Enterprise Bean，インタフェース，メソッド単位に設定する場合には，J2EEアプリケーションの設定時にサーバ管理コマンドを使用して属性ファイルに設定します。J2EEアプリケーションの設定については，「3.15.12　cosminexus.xmlでの定義」を参照してください。

注※2　アプリケーション開発時にタイムアウトを設定してください。J2EEアプリケーション運用時には，トランザクションの信頼性を保証するために，タイムアウトを設定しないことをお勧めします。

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

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

実行環境でのリソースアダプタの設定は，サーバ管理コマンドおよび属性ファイルを使用します。フォールトトレランスのための機能の定義には，Connector属性ファイルを使用します。

Connector属性ファイルでのフォールトトレランスのための機能の定義について次の表に示します。

表3‒69　Connector属性ファイルでのフォールトトレランスのための機能の定義

項目

指定するパラメタ

設定内容

コネクションの障害検知

<property>タグのValidationTypeおよびValidationInterval

コネクションの障害を検知するタイミングおよび障害を検知する間隔を指定します。

なお，コネクションの障害検知にタイムアウトを設定する場合には，NetworkFailureTimeoutでコネクション管理スレッドの使用を有効にします。※1

コネクション管理スレッド

<property>タグのNetworkFailureTimeout

コネクション管理スレッドを使用するかどうかを指定します。

コネクション管理スレッドを使用する場合，コネクションの障害検知機能，およびコネクション数調節機能のタイムアウトが有効になります。タイムアウト時間は簡易構築定義ファイルのJ2EEサーバで指定するキーに，任意の時間を指定できます（デフォルト値は5秒）。

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

<property>タグのRequestQueueEnable

コネクション枯渇時のコネクション取得待ちを有効にするかどうかを指定します。

<property>タグのRequestQueueTimeout

コネクション取得の待ち時間を指定します。

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

<property>タグのRetryCount

コネクション取得に失敗した場合のリトライ回数を指定します。

<property>タグのRetryInterval

コネクション取得に失敗した場合のリトライ間隔を指定します。

コネクションスイーパ

<property>タグのSweeperInterval※2

コネクションの自動破棄（コネクションスイーパ）が動作する間隔を指定します。

<property>タグのConnectionTimeout※2

コネクションの最終利用時刻からコネクションを自動破棄するかどうかを判定するまでの時間を指定します。

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

<config-property>タグのCancelStatement

トランザクションタイムアウト発生時のステートメントキャンセルを有効にするかどうかを指定します。

注※1　コネクションの障害検知機能とコネクション数調節機能のタイムアウトを同じキーで設定します。このため，コネクションの障害検知機能でタイムアウトを使用する場合は，コネクション数調節機能でもタイムアウトを使用する設定となります。

注※2　設定値が3600秒未満の場合，KDJE48604-Wが出力されます。

Connector属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

(3)　J2EEアプリケーションの設定

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。パフォーマンスチューニングのための機能の定義には，Session Bean属性ファイル，Entity Bean属性ファイルまたはMessage-driven Bean属性ファイルを使用します。

これらの属性ファイルで指定するタグは，cosminexus.xmlと対応しています。cosminexus.xmlでの定義については，「3.15.12　cosminexus.xmlでの定義」を参照してください。

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

この節では，「3.14　パフォーマンスチューニングのための機能」，および「3.15　フォールトトレランスのための機能」で説明する機能以外のリソースアダプタの機能について説明します。

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

表3‒70　この節の構成（そのほかのリソースアダプタの機能（Connector 1.5仕様に準拠するリソースアダプタの場合））

分類

タイトル

参照先

解説

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

3.16.1

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

3.16.2

メッセージインフロー

3.16.3

トランザクションインフロー

3.16.4

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

3.16.5

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

3.16.6

実装

アプリケーションサーバ独自のConnector 1.5 API仕様

3.16.7

設定

Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定

3.16.8

属性ファイルの指定例

3.16.9

注意事項

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

3.16.10

注　「運用」について，この機能固有の説明はありません。

これらの機能は，Connector 1.5仕様に準拠したリソースアダプタで使用できます。アプリケーションサーバで使用できるConnector 1.5仕様に準拠したリソースアダプタについては，「3.3.2(2)　Connector 1.5仕様に準拠したリソースアダプタ」を参照してください。

参考

Connector 1.5仕様に準拠したリソースアダプタなど，「3.3.2(1)　Connector 1.0仕様に準拠したリソースアダプタ」で示したリソースアダプタ以外のリソースアダプタを使用する場合には，リソースアダプタの処理の入り口と出口で，トレースを出力することをお勧めします。出力したトレースは，障害が発生したときの要因を切り分けるために使用します。

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

Connector 1.5仕様に準拠したリソースアダプタを利用する場合，J2EEサーバによってリソースアダプタのライフサイクルを管理できます。

リソースアダプタのライフサイクル管理とは，リソースアダプタの開始処理と停止処理を，J2EEサーバで管理する機能です。

(1)　前提条件

リソースアダプタのライフサイクル管理は，リソースアダプタが次の条件を満たす場合に有効になります。

リソースアダプタに，「(2)　ライフサイクル管理に使用するクラス」で示すクラスが実装されている。

DD（ra.xml）の<connector>-<resourceadapter>-<resourceadapter-class>に，javax.resource.spi.ResourceAdapterインタフェースを実装したJavaBeansのクラス名を指定している。

なお，DDの<connector>-<resourceadapter>-<resourceadapter-class>の指定が省略されている場合，リソースアダプタのライフサイクル管理は実行されません。

(2)　ライフサイクル管理に使用するクラス

リソースアダプタのライフサイクル管理に使用するクラスについて説明します。使用するクラスには，リソースアダプタでの実装が必要なクラスと，J2EEサーバが提供するクラスがあります。

(a)　リソースアダプタで実装が必要なクラス

リソースアダプタでは，次のクラスの実装が必要です。なお，これらのクラスはJavaBeanとして実装することが，Connector 1.5仕様で規定されています。

javax.resource.spi.ResourceAdapterインタフェースの実装クラス

javax.resource.spi.ManagedConnectionFactoryインタフェースの実装クラス

AdminObject（管理対象オブジェクト）の実装クラス

詳細な実装については，Connector 1.5仕様を参照してください。

(b)　J2EEサーバが提供するクラス

J2EEサーバは，次のクラスを提供します。

javax.resource.spi.work.WorkManagerインタフェースの実装クラス

このクラスには，doWork(Work)メソッド，scheduleWork(Work)メソッド，startWork(Work)メソッドなどが実装されています。

javax.resource.spi.BootstrapContextインタフェースの実装クラス

このクラスには，createTimer()メソッド，getWorkManager()メソッド，およびgetXATerminator()メソッドが実装されています。

なお，アプリケーションサーバでは，BootstrapContextインタフェースのgetXATerminatorメソッドを呼び出した場合，nullが返却されるように実装されています。

(3)　ライフサイクル管理の制御

ここでは，ライフサイクル管理の対象になる，リソースアダプタの開始処理と停止処理の制御について説明します。

リソースアダプタの開始処理および停止処理は，次のタイミングで実行されます。

J2EEリソースアダプタを開始または停止したとき（cjstartrarコマンドまたはcjstoprarコマンドを実行したとき）

J2EEサーバを起動または停止したとき（cjstartsvコマンドまたはcjstopsvコマンドを実行したとき）

リソースアダプタを含むアプリケーションを開始または停止したとき（cjstartappコマンドまたはcjstopappコマンドを実行したとき）

(a)　リソースアダプタの開始処理を実行した場合の制御

リソースアダプタの開始処理を実行した場合の制御の流れを次の図に示します。

図3‒36　リソースアダプタの開始処理を実行した場合の制御の流れ

リソースアダプタの開始処理によって実行される制御について説明します。なお，項番は図中の数字と対応しています。

WorkManager（javax.resource.spi.work.WorkManagerインタフェースの実装クラス）が生成されます。

BootstrapContext（javax.resource.spi.BootstrapContextインタフェースの実装クラス）が生成されます。

ResourceAdapterJavaBean（javax.resource.spi.ResourceAdapterインタフェースの実装クラス）が生成されます。

ResourceAdapterJavaBeanとして生成される実装クラスは，リソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<resourceadapter-class>に指定したクラスです。

このタグで指定したクラスのインスタンス化に失敗した場合，リソースアダプタの開始が失敗します※。このとき，KDJE48589-Eのメッセージが出力されます。

ResourceAdapterJavaBeanにプロパティが設定されます。

DD（ra.xml）の<connector>-<resourceadapter>-<config-property>に指定した値は，3.で生成されたResourceAdapterJavaBeanに設定されます。設定は，JavaBeanの仕様に従い，setterメソッドで実行されます。setterメソッドの呼び出しで例外が発生した場合は，KDJE48594-Wのメッセージが出力されます。ただし，処理は継続されます。

javax.resource.spi.ResourceAdapterインタフェースのstartメソッドが呼び出され，リソースアダプタが開始されます。

このメソッドの呼び出しによって例外がスローされた場合は，リソースアダプタの開始が失敗します※。このとき，KDJE48590-Eのメッセージが出力されます。

ResourceAdapterJavaBeanとManagedConnectionFactoryJavaBeanが関連づけられます（Outboundの場合）。

ライフサイクル管理機能を使用する場合，javax.resource.spi.ManagedConnectionFactoryインタフェースの実装クラスはjavax.resource.spi.ResourceAdapterAssociationインタフェースを実装しています。ResourceAdapterJavaBeanとManagedConnectionFactoryの関連づけは，javax.resource.spi.ResourceAdapterAssociationインタフェースのsetResourceAdapter(ResourceAdapter)メソッドで実行されます。

また，次の場合には，リソースアダプタの開始が失敗します※。このとき，KDJE48591-Eが出力されます。

ManagedConnectionFactoryJavaBeanがjavax.resource.spi.ResourceAdapterAssociationインタフェースを実装していなかった場合

setResourceAdapterメソッドの呼び出しに対して例外がスローされた場合

AdminObjectJavaBean（管理対象オブジェクト）が生成され，プロパティが設定されます。

AdminObjectJavaBeanとして生成される実装クラスは，リソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<adminobject>-<adminobject-class>に指定したクラスです。このタグで指定したクラスのインスタンス化に失敗した場合，リソースアダプタの開始が失敗します※。このとき，KDJE48597-Eのメッセージが出力されます。

また，DD（ra.xml）の<connector>-<resourceadapter>-<adminobject>-<config-property>で指定した値が，AdminObjectJavaBeanに設定されます。設定は，JavaBeanの仕様に従い，setterメソッドで実行されます。AdminObjectJavaBeanのsetterメソッドの呼び出しで例外が発生した場合は，KDJE48598-Wのメッセージが出力されます。ただし，処理は継続されます。

注※

アプリケーションに含まれるリソースアダプタの場合，リソースアダプタの開始が失敗したときには，そのリソースアダプタを含むアプリケーションの開始処理も失敗します。

(b)　リソースアダプタの停止処理を実行した場合の制御

リソースアダプタの停止処理を実行した場合の制御を次の図に示します。

図3‒37　リソースアダプタの停止処理を実行した場合の制御

リソースアダプタの停止処理によって実行される制御について説明します。なお，項番は図中の数字と対応しています。

停止するリソースアダプタを参照しているEJB，サーブレット，Message-driven Beanがすべて停止していることが確認されます。

次の要素が使用されていないことが確認されます。

Inboundリソースアダプタ

コネクションファクトリ

管理対象オブジェクト

これらが使用されていた場合は，リソースアダプタの停止処理が中止されます。

AdminObjectJavaBean（管理対象オブジェクト）が破棄されます。

javax.resource.spi.ResourceAdapterインタフェースのstopメソッドが呼び出され，リソースアダプタが停止します。

このメソッドの呼び出しによって例外がスローされた場合は，KDJE48590-Eのメッセージが出力されて，リソースアダプタの停止処理が失敗します。

ResourceAdapterJavaBeanが破棄されます。

(c)　リソースアダプタの状態遷移

リソースアダプタは，リソースアダプタの開始処理または停止処理が実行されたタイミングで，「開始状態」または「停止状態」に遷移します。

リソースアダプタの状態遷移を次の図に示します。

図3‒38　リソースアダプタの状態遷移

(4)　ライフサイクル管理機能を使用するときの注意

ライフサイクル管理機能を使用する場合は，次の点に注意してください。

J2EEサーバにデプロイされているリソースアダプタが複数ある場合，開始および停止処理が実行される順序は不定です。また，アプリケーションに含まれるリソースアダプタが複数ある場合，開始および停止処理が実行される順序は不定です。実行順序に依存する処理がある場合，動作は保証されません。

アプリケーションに含まれるリソースアダプタの場合，アプリケーション内に含まれるEJBやServletの開始処理よりも前に，リソースアダプタの開始処理が実行されます。また，アプリケーション内に含まれるEJBやServletの停止処理よりもあとで，リソースアダプタの停止処理が実行されます。

ResourceAdapter.stopの処理では，次に示す処理を適切に実行してください。

BootstrapContext.createTimerで生成したTimerの破棄(Timer#cancel)

WorkManagerに登録したWorkオブジェクトへの終了指示(Work#release)

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

Connector 1.5仕様に準拠したリソースアダプタを使用する場合，リソースアダプタが使用するスレッドをJ2EEサーバによって管理できます。

リソースアダプタのワーク管理とは，リソースアダプタがマルチスレッドで動作する場合に，スレッドを適切に使用するための機能です。J2EEサーバは，スレッドをプールに管理しておき，必要なリソースアダプタに割り当てます。

注意事項

ワーク管理の対象になるWorkを実行するスレッドは，J2EEアプリケーションの実行時間監視の対象にはなりません。

J2EEアプリケーションの実行時間監視については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。

(1)　前提条件

リソースアダプタのワーク管理機能は，リソースアダプタのライフサイクルが管理されている場合に使用できます。リソースアダプタのライフサイクル管理については，「3.16.1　リソースアダプタのライフサイクル管理」を参照してください。

(2)　ワーク管理に使用するクラス

リソースアダプタのワークを管理する場合に使用するクラスについて説明します。使用するクラスには，リソースアダプタでの実装が必要なクラスと，J2EEサーバが提供するクラスがあります。なお，J2EEサーバが提供するクラスは，ライフサイクル管理で使用するクラスと同じです。「3.16.1(2)　ライフサイクル管理に使用するクラス」を参照してください。

(a)　リソースアダプタで実装が必要なクラス

リソースアダプタでは，次のクラスの実装が必要です。

javax.resource.spi.work.Workインタフェースの実装クラス

このクラスのrunメソッドには，実行する処理を実装しておく必要があります。

なお，ワークの登録，ワークのスレッドへの割り当て，およびワークの終了のタイミングをリソースアダプタで管理したい場合は，javax.resource.spi.work.WorkListenerインタフェースの実装クラスも実装してください。

(3)　ワーク管理の流れ

ここでは，ワーク管理の処理の流れについて説明します。

ワーク管理の概要を次の図に示します。

図3‒39　ワーク管理の概要

図で示した流れについて説明します。

Workの登録

リソースアダプタは，Work（javax.resource.spi.work.Workインタフェースの実装クラス）を生成して，WorkManagerに登録します。

このとき，WorkManagerのインスタンスは，BootstrapContext経由でリソースアダプタに渡されます。WorkManagerについては，「3.16.1　リソースアダプタのライフサイクル管理」を参照してください。

また，Workの登録と同時に，WorkManagerにWorkListener（javax.resource.spi.work.WorkListener）も登録すると，以降，Workの登録が完了したとき（1.が実行されたとき），Workにスレッドが割り当てられたとき（2.が実行されたとき），およびWorkの処理が完了したとき（3.が実行されたとき）に，それぞれイベント(javax.resource.spi.work.WorkEventインタフェースの実装クラス)を取得できます。

空きスレッドへのワークの割り当て

J2EEサーバは，WorkManagerに登録されたWorkに対して，空きスレッドを割り当てて，Workで実装されているrunメソッドを実行します。

Workの終了とスレッドの回収

J2EEサーバは，処理が完了したWorkに割り当てたスレッドを，スレッドプールに回収します。

回収されたスレッドは，スレッドプーリングでの設定に従って，プールに戻って待機状態になるか，解放されます。

なお，この流れの中で，javax.resource.spi.work.Workインタフェースまたはjavax.resource.spi.work.WorkListenerインタフェースのメソッドで例外が発生した場合は，それぞれKDJE48592-EまたはKDJE48593-Eのメッセージが出力されます。

WorkManagerに登録されたWorkの状態遷移を，次の図に示します。

図3‒40　Workの状態遷移

なお，WorkManagerにWorkを登録する時に使用するメソッドによって，メソッドがリターンするタイミングが異なります。それぞれのメソッドがリターンするタイミングを次の表および図に示します。なお，リターンするタイミング以外，これらのメソッドの処理に違いはありません。

表3‒71　メソッドがリターンするタイミング

メソッド

リターンするタイミング

scheduleWork

Workを登録して，すぐにリターンします。

startWork

Workにスレッドが割り当てられたタイミングでリターンします。

doWork

Workの処理が完了したタイミングでリターンします。

図3‒41　scheduleWorkメソッドがリターンするタイミング

図3‒42　startWorkメソッドがリターンするタイミング

図3‒43　doWorkメソッドがリターンするタイミング

(4)　スレッドプーリング

スレッドプーリングは，ワークに割り当てるスレッドを，スレッドプールで管理する機能です。

(a)　スレッドプーリングの設定

スレッドプーリングの設定は，リソースアダプタをJ2EEサーバにインポートしたあとで，Connector属性ファイルの<hitachi-connector-property>-<resourceadapter-runtime>-<property>タグに指定して，リソースアダプタごとのプロパティとして設定します。設定手順については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「5.4　リソースアダプタのプロパティ定義」を参照してください。

スレッドプールに設定できる値を次の表に示します。

表3‒72　スレッドプールに設定できる値

設定できる値（プロパティ名）

説明

同時に実行される最大のスレッド数（MaxTPoolSize）

WorkManagerで同時に実行される最大のスレッド数を設定します。

Workが登録されたときに空きスレッドがない場合，WorkManagerで実行中のスレッドの数がこの値未満であれば，新規にスレッドが生成されて，Workに割り当てられます。

実行中のスレッドの数がこの値以上のときには，Workの受け付けは拒否されて，javax.resource.spi.work.WorkRejectedExceptionがスローされます。

スレッドプールの最小スレッド数（MinTPoolSize）

スレッドプールにプールする最小スレッド数を設定します。

WorkManagerにWorkがまったく登録されていない場合でも，この値分のスレッドは常にプールされます。

また，この値に0を指定した場合は，Workが登録されるまで，スレッドは生成されません。

Workが割り当たっていないスレッドが解放されるまでの最大生存期間［単位：秒］（TPoolKeepalive）

Workが割り当てられていないスレッドが，スレッドプールから解放されるまでの期間を秒単位で設定します。

空きスレッドになってからTPoolKeepalive秒経過してもWorkが割り当てられなかった場合，そのスレッドは解放されます。

ただし，スレッドプールに存在するスレッド数がMinTPoolSizeの値分しかない場合は，解放されません。

指定方法および指定できる値の詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

なお，ライフサイクル管理機能が有効でない場合（リソースアダプタのDD（ra.xml）に<resourceadapter-class>が指定されていない場合），スレッドプーリングを設定するプロパティの値は無視されます。

(b)　ワーク管理で使用するスレッドのライフサイクル

ワーク管理機能で使用するスレッドのライフサイクルを次に図に示します。

スレッドのライフサイクルは，スレッドプールと実行中スレッドの状態によって異なります。

図3‒44　スレッドのライフサイクル（スレッドプールに空きスレッドがなく，実行中のスレッド数がMaxTPoolSize未満の場合）

図3‒45　スレッドのライフサイクル（スレッドプールに空きスレッドがある場合）

図3‒46　スレッドのライフサイクル（スレッドプールに空きスレッドがなく，実行中のスレッド数がMaxTPoolSizeに達している場合）

スレッドが生成されるのは，リソースアダプタによってscheduleWorkメソッド，startWorkメソッドまたはdoWorkメソッドが呼び出された場合に，次の状態の両方に当てはまるときです。

スレッドプールに空きスレッドがない。

WorkManagerで実行中のスレッド数がMaxTPoolSize未満である。

スレッドは，Workの処理が完了するとスレッドプールで実行待ち状態になります。次のWorkが登録されると，再度実行状態になります。

スレッドプール内で，TPoolKeepaliveで指定した秒数が経過してもWorkが割り当てられなかった場合，スレッドは解放されます。ただし，そのスレッドを解放することでスレッドプール内のスレッド数がMinTPoolSize未満になる場合は，解放されません。

(c)　Message-driven Beanのインスタンスプールとスレッドプーリングとの関係

リソースアダプタがWorkを使用してMessage-driven Beanを呼び出す場合の動作は，Message-driven Beanのインスタンスプールの最大数と，リソースアダプタのMaxTPoolSizeの関係によって異なります。

Message-driven Beanのインスタンスプールの最大数とリソースアダプタのMaxTPoolSizeの関係ごとの動作を次の表に示します。これは，一つのリソースアダプタから一つのMessage-driven Beanを呼び出す場合の動作です。

表3‒73　リソースアダプタがWorkによってMessage-driven Beanを呼び出すときの動作

Message-driven Beanのインスタンスプールの最大数とリソースアダプタのMaxTPoolSizeの関係

動作

MaxTPoolSize>Message-driven Beanのインスタンスプールの最大数

Message-driven Beanのインスタンスプールの最大数に達するまで，WorkからMessage-driven Beanを実行できます。

Message-driven Beanのインスタンスプールの最大数を超える数のWorkは，Message-driven Beanのインスタンスの取得待ちの状態になります。

MaxTPoolSize=Message-driven Beanのインスタンスプールの最大数

Message-driven Beanのインスタンスプールの最大数に達するまで，WorkからMessage-driven Beanを実行できます。

Message-driven Beanのインスタンスプールの最大数を超える数のWorkに対しては，javax.resource.spi.work.WorkRejectedException例外がスローされます。インスタンスの取得待ちにはなりません。

MaxTPoolSize<Message-driven Beanのインスタンスプールの最大数

同時に使用できるMessage-driven Beanのインスタンス数は，MaxTPoolSizeの数になります。実行中のWorkの数がMaxTPoolSizeに達するまで，WorkからMessage-driven Beanを実行できます。

MaxTPoolSizeを超える数のWorkに対しては，javax.resource.spi.work.WorkRejectedException例外がスローされます。実行待ちにはなりません。

ポイント

ワーク管理機能のスレッドプーリングはリソースアダプタ単位に設定します。一方，Message-driven BeanのインスタンスプールはMessage-driven Bean単位に設定します。

リソースアダプタが複数のMessage-driven Beanを呼び出す場合，リソースアダプタのMaxTPoolSizeには，それぞれのMessage-driven Beanで必要なスレッド数を考慮して，合計した値を設定してください。

(5)　ワーク管理の開始処理と終了処理

ワーク管理の開始処理および終了処理は，ライフサイクル管理機能の開始処理および終了処理のタイミングで実行されます。

それぞれの処理で実行されることを次に示します。

(a)　開始処理

ワーク管理の開始処理では，スレッドプーリングの設定に応じて，スレッドの生成が実行されます。MinTPoolSizeが1以上に設定されている場合は，MinTPoolSize分のスレッドが生成されて，空きスレッドとしてスレッドプールに格納されます。

(b)　終了処理

終了処理で実行される内容は，正常終了の場合と，異常終了または強制終了の場合とで一部異なります。なお，異常終了とは，ResourceAdapterインタフェースのstopメソッド実行時に例外がスローされる場合のことです。また，強制終了とは，cjstopapp -forceコマンドまたはcjstopapp -cancelコマンド実行の延長で実行される終了処理のことです。

参考

cjstopsv -fコマンドを実行した場合は，リソースアダプタの終了処理が実行されないでJ2EEサーバが停止されます。このため，ここで説明する処理は実行されません。

J2EEサーバからResourceAdapterインタフェースのstopメソッドが呼び出され，リソースアダプタに対して，停止処理が指示されます。

また，この処理の延長でWorkのreleaseメソッドが呼び出されて，Workが解放されます。

リソースアダプタによって，新規のWorkの受け付けが停止されます。

1.の処理を実行したあとなので，通常，Workの登録要求はありません。Workの登録要求があった場合，例外として，javax.resource.spi.work.WorkRejectedExceptionがスローされます。

Workの処理完了が待機されます。

実行中のWorkのrunメソッドの実行がすべて完了するまで待機されます。

ポイント

Workから呼び出しているMessage-driven Beanに対してメソッドキャンセルが実行されると，Message-driven Beanは強制終了します。ただし，その場合，実行中のWorkの処理は停止されません。

WorkからMessage-driven Beanを呼び出している場合，リソースアダプタよりも先にMessage-driven Beanが終了します。Message-driven Bean停止後にWorkからMessage-driven Beanを呼び出したり，javax.resource.spi.endpoint.MessageEndpointFactoryのcreateEndpointメソッドを呼び出したりすると，例外がスローされます。

詳細は，「3.16.3　メッセージインフロー」を参照してください。

(6)　ワーク管理機能を使用するときの注意

WorkおよびWorkListenerのメソッド内では，J2EEサーバの機能として，メッセージインフロー規約に基づくMessage-driven Beanの呼び出しだけが使用できます。

WorkおよびWorkListenerのメソッドは，スレッドセーフにしてください。

WorkListenerのメソッドには，実行スレッドに依存した処理を実装しないでください。実行スレッドに依存した処理がある場合，動作は保証されません。

3.16.3　メッセージインフロー

メッセージインフローは，リソースアダプタとMessage-driven Bean間の規約です。Connector 1.5仕様のリソースアダプタは，EISなどのメッセージプロバイダからのメッセージを受け付けて，アプリケーションサーバ上のメッセージエンドポイント（Message-driven Bean）を動作させることができます。メッセージエンドポイントでは，メッセージプロバイダから送信されたメッセージを，非同期に処理します。

アプリケーションサーバでは，メッセージの配信方法として，次の2種類の方法を使用できます。

Non-Transacted Delivery

Transacted Delivery

これらは，呼び出し元のEISがトランザクションに参加するかどうかが異なります。

(1)　前提条件

メッセージインフローは，リソースアダプタおよびMessage-driven Beanが次の条件を満たす場合に有効になります。

メッセージインフローで呼び出されるMessage-driven Beanは，EJB 2.1以降に準拠している必要があります。

EJB 2.1以降では，Message-driven Beanはjavax.jms.MessageListenerだけではなく，任意のメッセージリスナを実装できます。メッセージリスナは，リソースアダプタとMessage-driven Bean間のメッセージ配送に使用するリスナです。リソースアダプタがサポートしているメッセージリスナをMessage-driven Beanに実装することで，汎用的なメッセージ受信を実現できます。

EJB 2.0のMessage-driven Beanでメッセージインフローを実行しようとした場合，アプリケーション開始時にエラーになり，開始に失敗します。この場合は，KDJE42088-Eのメッセージが出力されます。

メッセージインフローを実行する場合，リソースアダプタおよびMessage-driven Beanの属性として，次の設定が必要です。

管理対象オブジェクトに設定する情報（リソースアダプタ）

Message-driven Beanとリソースアダプタの対応づけ（Message-driven Beanおよびリソースアダプタ）

ActivationSpecに設定する情報（Message-driven Bean）

Message-driven Beanが使用するインタフェース（Message-driven Beanおよびリソースアダプタ）

メッセージインフローの処理を実行する場合のリソースアダプタとJ2EEアプリケーションの設定については，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」を参照してください。

また，Transacted Deliveryは，次の表に示す条件を満たす場合に有効になります。

表3‒74　Transacted Deliveryが有効になる条件

J2EEサーバの設定

Message-driven Beanの設定

トランザクション管理種別<transaction-type>がContainer

トランザクション管理種別<transaction-type>がBean

トランザクション属性<trans-attribute>がRequired

トランザクション属性<trans-attribute>がNotSupported

ejbserver.distributedtx.XATransaction.enabled

true

○

×

×

false

△

×

×

（凡例）

○：メッセージを配信するEISをグローバルトランザクションに含めてトランザクションを開始する。

△：メッセージを配信するEISをトランザクションに含めないでローカルトランザクションを開始する。

×：トランザクションを開始しない。

また，Transacted Deliveryを使用する場合は，Connector 1.5仕様に準拠し，Transacted Deliveryに対応したリソースアダプタを使用する必要があります。設定の詳細については，ご使用のリソースアダプタのドキュメントを参照してください。

(2)　メッセージインフローの制御の流れ（Non-Transacted Deliveryの場合）

Non-Transacted Deliveryとは，メッセージを配信するEISがトランザクションに参加しないメッセージ配信です。

Non-Transacted Deliveryでメッセージインフローを使用する場合の制御の流れを次の図に示します。

図3‒47　Non-Transacted Deliveryでメッセージインフローを使用する場合の制御の流れ

Non-Transacted Deliveryでメッセージインフローを使用した場合に実行される制御について説明します。なお，項番は図中の数字と対応しています。

アプリケーションの開始処理によって，リソースアダプタのActivationSpecJavaBeanにプロパティが設定されます。

Message-driven Beanの属性の<activation-config>に指定した内容が設定されます。

J2EEサーバからendpointActivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの開始が通知されます。

EISからメッセージが送信されます。

リソースアダプタからMessageEndpointFactoryに対して，createEndpointメッセージが呼び出されます。

MessageEndpointFactoryがエンドポイントのプロキシを生成します。

リソースアダプタからエンドポイントのプロキシに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

エンドポイントのプロキシからMessage-driven Beanに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

処理が完了したら，J2EEサーバからendpointDeactivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの停止が通知されます。

(3)　メッセージインフローの制御の流れ（Transacted Deliveryの場合）

Transacted Deliveryとは，メッセージを配信するEISがトランザクションに参加するメッセージ配信です。

Transacted Deliveryでメッセージインフローを使用する場合の制御の流れを次の図に示します。

図3‒48　Transacted Deliveryでメッセージインフローを使用する場合の制御の流れ

Transacted Deliveryでメッセージインフローを使用した場合に実行される制御について説明します。なお，項番は図中の数字と対応しています。

アプリケーションの開始処理によって，リソースアダプタのActivationSpecJavaBeanにプロパティが設定されます。

Message-driven Beanの属性の<activation-config>に指定した内容が設定されます。

J2EEサーバからendpointActivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの開始が通知されます。

EISからメッセージが送信されます。

リソースアダプタからMessageEndpointFactoryに対して，createEndpointメッセージが呼び出されます。

MessageEndpointFactoryがエンドポイントのプロキシを生成します。

リソースアダプタからエンドポイントのプロキシに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

呼び出されたエンドポイントのプロキシからトランザクションマネージャに対して，トランザクションの開始指示が呼び出されます。

トランザクションマネージャによってstartメソッドが呼び出され，トランザクションが開始されます。

エンドポイントのプロキシからMessage-driven Beanに対して，onMessageメソッドなどのメッセージリスナのメソッドが呼び出されます。

エンドポイントのプロキシからトランザクションマネージャに対して，トランザクションの決着が指示されます。

トランザクションマネージャによってprepareメソッド，commitメソッドなどのトランザクション決着メソッドが呼び出され，トランザクションが決着します。

処理が完了したら，J2EEサーバからendpointDeactivationメソッドが呼び出されます。これによって，リソースアダプタにメッセージエンドポイントの停止が通知されます。

(4)　メッセージエンドポイントのデプロイとアンデプロイ

ここでは，メッセージエンドポイントのデプロイとアンデプロイで実行される処理について説明します。

(a)　メッセージエンドポイントのデプロイ

メッセージエンドポイントのデプロイ時に実行される処理について説明します。メッセージエンドポイントのデプロイは，リソースアダプタが開始済みの状態で，Message-driven Beanを含むアプリケーションを開始したときに実行されます。

メッセージエンドポイントのデプロイ時の処理を次の図に示します。

図3‒49　メッセージエンドポイントのデプロイ時の処理

メッセージエンドポイントのデプロイで実行される処理について説明します。項番は図中の番号に対応しています。

リソースアダプタが開始済みの状態で，Message-driven Beanを含むJ2EEアプリケーションを開始します。

J2EEサーバが，MessageEndpointFactoryを生成します。

MessageEndpointFactoryは，J2EEサーバが提供するjavax.resource.spi.endpoint.MessageEndpointFactoryのインスタンスです。javax.resource.spi.endpoint.MessageEndpointFactoryはリソースアダプタにエンドポイントのインスタンスを提供するファクトリクラスです。

J2EEサーバが，ActivationSpecを生成します。

ActivationSpecは，Message-driven Bean（エンドポイント）の開始に必要な情報を設定するJavaBeanです。

J2EEサーバが，ActivationSpecのプロパティを設定します。

ActivationSpecのプロパティに設定する情報は，Message-driven Beanを含むアプリケーションの属性として設定した情報です。

J2EEサーバが，javax.resource.spi.ResourceAdapter#endpointActivation(MessageEndpointFactory, ActivationSpec)メソッドを呼び出します。

このとき，引数として，生成・設定したMessageEndpointFactoryとActivationSpecのインスタンスが指定されます。なお，endpointActivationメソッドの呼び出しで例外が発生した場合は，KDJE43174-Eのメッセージが出力され，アプリケーションの開始が中止されます。

リソースアダプタは，5.のメソッドが呼び出されると，メッセージプロバイダからのメッセージ受信に対する準備をします。

(b)　メッセージエンドポイントのアンデプロイ

メッセージエンドポイントのアンデプロイ時に実行される処理について説明します。メッセージエンドポイントのアンデプロイは，Message-driven Beanを含むアプリケーションを停止したときに実行されます。

メッセージエンドポイントのアンデプロイ時の処理を次の図に示します。

図3‒50　メッセージエンドポイントのアンデプロイ時の処理

メッセージエンドポイントのアンデプロイで実行される処理について説明します。項番は図中の番号に対応しています。

Message-driven Beanを含むJ2EEアプリケーションを停止します。

J2EEサーバが，javax.resource.spi.ResourceAdapter#endpointDeactivation(MessageEndpointFactory, ActivationSpec)を呼び出します。

このとき，引数として，デプロイ時に指定したMessageEndpointFactoryとActivationSpecと同じインスタンスが指定されます。なお，このメソッドの呼び出しで例外が発生した場合，メッセージKDJE43175-Wが出力されます。ただし，例外が発生した場合も，アプリケーションの停止処理は続行されます。

リソースアダプタは，2.のメソッドが呼び出されると，メッセージプロバイダからのメッセージ受信終了の処理をします。

(c)　メッセージ配送をするときのリソースアダプタの処理

ここでは，メッセージ配送をするときのリソースアダプタの処理について説明します。

リソースアダプタからのメッセージエンドポイント（Message-driven Bean）の呼び出しは，メッセージエンドポイントのプロキシを使用して実行されます。このプロキシは，リソースアダプタからjavax.resource.spi.endpoint.MessageEndpointFactoryのcreateEndpointメソッドを呼び出すことで得られます。

注意事項

アプリケーションの停止後にMessageEndpointFactoryのメソッドを呼び出すと，javax.resource.spi.UnavailableException例外がスローされます。このとき，メッセージKDJE43177-Eが出力されます。また，メッセージエンドポイントのメソッドを呼び出した場合は，java.lang.IllegalStateException例外がスローされます。このとき，メッセージKDJE43177-Eが出力されます。

Transacted Deliveryの場合，メッセージ配信中にJ2EEアプリケーションを停止すると，トランザクションがロールバックされることがあります。その際にKDJE31011-EまたはKDJE31012-Eエラーが発生することがあります。J2EEサーバの停止時に動作するJ2EEアプリケーションの停止でも，これらのエラーが発生することがあります。

3.16.4　トランザクションインフロー

トランザクションインフローとは，アプリケーションサーバ上のメッセージエンドポイント（Message-driven Bean）をメッセージプロバイダのトランザクションに参加させる際のリソースアダプタとアプリケーションサーバ間の規約です。

メッセージエンドポイント（Message-driven Bean）は，メッセージプロバイダのトランザクション識別子に関連づけられトランザクションに参加します。

なお，トランザクションインフローは，TP1インバウンド連携機能でだけ使用できます。

トランザクションインフローの制御の流れを次に示します。

図3‒51　トランザクションインフローの制御の流れ

図中の処理の流れについて説明します。なお，項番は図中の数字と対応しています。

EISからTP1インバウンドアダプタへメッセージが送信されます。

TP1インバウンドアダプタは，トランザクションマネージャへEISのトランザクション識別子を伝播します。

TP1インバウンドアダプタがMessage-driven Beanを実行します。

Message-driven Beanから，SQLを実行してDBを更新します。

Message-driven Bean実行後，TP1インバウンドアダプタからEISへ実行結果が送信されます。

実行結果を受けて，EISがTP1インバウンドアダプタへトランザクションの決着指示を送信します。

TP1インバウンドアダプタから，トランザクションマネージャへトランザクション決着指示が送信されます。

トランザクションが決着します。

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

管理対象オブジェクト（AdminObject）をルックアップによって取得できます。管理対象オブジェクトは，J2EEアプリケーションの中からメッセージを送信したり，同期受信したりする場合に，メッセージの送信先の情報を得るために必要です。管理対象オブジェクトをルックアップするためには，リソースアダプタとJ2EEアプリケーションの設定が必要です。ここでは，設定の概要について説明します。

参考

管理対象オブジェクトの仕様は，リソースアダプタの仕様に依存します。詳細は，使用するリソースアダプタの仕様に従ってください。

(1)　ルックアップの対象にする管理対象オブジェクトの設定

ルックアップの対象にする管理対象オブジェクトの情報は，リソースアダプタのプロパティとして設定します。リソースアダプタのプロパティは，Connector属性ファイルで設定します。

管理対象オブジェクトをルックアップの対象にする場合は，<adminobject-name>タグに管理対象オブジェクト名を必ず指定してください。管理対象オブジェクト名は，管理対象オブジェクトがリソースアダプタごとに複数定義された場合に，管理対象オブジェクトを一意に識別するために使用されます。

設定項目については，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」を参照してください。

(2)　J2EEアプリケーションの設定

管理対象オブジェクトをルックアップするJ2EEアプリケーションの設定は，属性ファイルまたはアノテーションで設定できます。

(a)　属性ファイルを使用する場合

<resource-env-ref>タグ下の次の要素を設定します。

<resource-env-ref-name>タグ下にルックアップで使用する名称を指定します。<resource-env-ref-type>タグ下に参照する管理対象オブジェクトの型を指定します。<linked-adminobject>タグ下にリソースアダプタの管理対象オブジェクトの名前，リソースアダプタの表示名を指定します。

注意事項

EJB 2.1以降で管理対象オブジェクトを参照するための要素として規定されている<message-destination-ref>タグは，アプリケーションサーバでは使用できません。

設定については，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」を参照してください。

(b)　アノテーションを使用する場合

@ResourceのmappedName属性に，ルックアップする管理対象オブジェクト名を指定します。次の形式で指定します。リソースアダプタの表示名と管理対象オブジェクト名を区切る区切り文字には「!#」を使用します。

@Resource(mappedName="リソースアダプタの表示名!#管理対象オブジェクト名")

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

Connector 1.5仕様に準拠したリソースアダプタを使用する場合，一つのリソースアダプタに対して複数のコネクション定義を指定できます。コネクションプールやログ出力などについての設定は，コネクション定義ごとに設定できます。

リソースアダプタ内のコネクション定義の識別には，コネクション定義識別子を使用します。コネクション識別子は，DD内の<connectionfactory-interface>の指定値です。<connectionfactory-interface>の値は，リソースアダプタ内のコネクション定義ごとに一意の値を持っています。

なお，リソースアダプタに含まれるコネクション定義ごとのコネクション定義識別子については，次のサーバ管理コマンドに-outboundオプションを指定して実行すると確認できます。

cjlistappコマンド（アプリケーションに含まれるRARファイルの場合）

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistapp（アプリケーションの一覧表示）」を参照してください。

cjlistresコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistres（リソースの一覧表示）」を参照してください。

cjlistrarコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistrar（リソースアダプタの一覧表示）」を参照してください。

ここでは，コネクション定義に指定できる要素と指定個所について説明します。また，コネクション定義を複数指定する場合に留意することについて説明します。

(1)　コネクション定義に指定できる要素と指定個所

ここでは，コネクション定義に指定できる要素と指定個所について説明します。

(a)　DDでの指定個所とコネクション定義に指定できる要素

コネクション定義は，Connector 1.5仕様に対応したDDの，<connection-definition>下に指定します。<connection-definition>の下に指定する要素を次に示します。

<managedconnectionfactory-class>

<config-property>

<connectionfactory-interface>

<connectionfactory-impl-class>

<connection-interface>

<connection-impl-class>

(b)　Connector属性ファイルの階層構造とコネクション定義の対応

DD（ra.xml）の階層構造の変更に合わせて，属性ファイルにもコネクション定義に対応する階層が追加されます。

J2EEサーバにインポート済みのリソースアダプタの場合，リソースアダプタのプロパティの変更には，Connector属性ファイルを使用します。Connector属性ファイルに定義した値は，サーバ管理コマンドを使用してJ2EEサーバ上のリソースアダプタに反映します。属性ファイルによるプロパティの設定手順については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「3.5　属性ファイルによるプロパティの設定」を参照してください。

なお，リソースアダプタの動作に関連するプロパティには，コネクション定義ごとに定義する項目と，リソースアダプタ全体に定義する項目があります。コネクション定義ごとに指定する項目については，Connector属性ファイルの<outbound-resourceadapter>-<connection-definition>下に指定します。リソースアダプタ全体に対して指定する項目については，<resourceadapter-runtime>-<property>下に指定します。

指定方法の詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.1　Connector属性ファイルの指定内容」を参照してください。

(c)　J2EEアプリケーションでのリンク解決の定義方法（<resource-ref>-<linked-to>，<cmp-map>-<datasource-name>またはmappedNameでの指定方法）

Connector 1.5仕様に準拠したリソースアダプタを参照するJ2EEアプリケーションでは，リンク解決のために，J2EEアプリケーションがどのコネクション定義を参照するかを定義する必要があります。

定義は，次のどれかの方法で指定します。

J2EEアプリケーションの属性ファイル（WAR属性ファイル，Session Bean属性ファイル，Entity Bean属性ファイルまたはMessageDrivenBean属性ファイル）の<resource-ref>-<linked-to>

J2EEアプリケーションの属性ファイル（Entity Bean属性ファイル）の<cmp-map>-<datasource-name>

アノテーション@ResourceのmappedName属性

注意事項

参照先のリソースがConnector 1.5仕様に準拠したリソースアダプタの場合は，必ずコネクション定義識別子を指定してください。指定を省略した場合，リンク解決に失敗します。また，参照先のリソースがConnector 1.0仕様に準拠したリソースアダプタの場合は，コネクション定義識別子を指定しないでください。指定した場合，リンク解決に失敗します。

コネクション定義識別子を含む参照先のリソースは，次の形式で指定します。

<リソースアダプタの表示名>!<コネクション定義識別子>

指定内容について説明します。

<リソースアダプタの表示名>

参照先のリソースアダプタのDD（ra.xml）の<connector>-<display-name>要素の値です。

<コネクション定義識別子>

参照先のリソースアダプタのDD（ra.xml）の<connector>-<resourceadapter>-<outbound-resourceadapter>-<connection-definition>-<connectionfactory-interface>要素の値です。

なお，リソースアダプタの表示名およびコネクション定義識別子は，次のサーバ管理コマンドでも確認できます。

cjlistappコマンド（アプリケーションに含まれるRARファイルの場合）

cjlistresコマンド

cjlistrarコマンド

(2)　コネクションプールを使用する場合の留意事項

複数のコネクション定義が指定されているリソースアダプタでは，コネクションプールをコネクション定義単位で管理できます。コネクションプールについての定義は，Connector属性ファイルの<outbound-resourceadapter>-<connection-definition>-<connector-runtime>-<property>下の要素で指定して設定してください。

次に，コネクションプールが複数になる場合の留意事項について説明します。

(a)　コネクションプールを対象にしたコマンドの実行

コネクションプールを対象にしたサーバ管理コマンドを実行するときには，どのコネクションプールを対象にするかを指定する必要があります。

次のコマンドを実行する場合には，コネクション定義識別子の指定が必要です。コネクション定義識別子は，これらのコマンドのオプションで指定します。

cjclearpoolコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjclearpool（コネクションプール内のコネクション削除）」を参照してください。

cjlistpoolコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistpool（コネクションプールの一覧表示）」を参照してください。

(b)　コネクションプールのウォーミングアップ処理

コネクションプールのウォーミングアップ処理は，コネクション定義ごとに実行されます。

コネクションプールのウォーミングアップ処理が実行される場合に，特定のコネクション定義に対応するコネクションプールのウォーミングアップに失敗しても，それ以外のコネクションプールに対するウォーミングアップ処理は継続されます。

(3)　トランザクションリカバリをする場合の留意事項

トランザクションリカバリは，コネクション定義ごとに実行されます。このため，コネクション定義を複数指定した場合，OTSにはコネクション定義ごとにリソースが登録されます。

(4)　リソースへの接続テストをする場合の留意事項

リソースアダプタの接続テストを実行する場合，特定のコネクション定義に対する接続テストでエラーが発生した場合も，処理は中止されません。すべてのコネクション定義に対して接続テストが実行されます。ただし，どれかのコネクション定義でエラーが発生した場合，コマンドの戻り値は異常終了を示す戻り値になります。

(5)　稼働情報およびリソース枯渇監視情報を出力する場合の留意事項

コネクション定義が複数指定されている場合，稼働情報およびリソース枯渇監視情報は次のように出力されます。

稼働情報（稼働情報ファイルに出力される情報）

一つ目のコネクション定義についての情報だけが出力されます。一つ目のコネクション定義とは，DD（ra.xml）で最初に定義されているコネクション定義です。

稼働情報（運用管理コマンドを使用して出力する情報）

出力できません。Connector 1.5仕様に準拠したリソースアダプタについての稼働情報を出力しようとした場合，出力内容は保証されません。

リソース枯渇監視情報

リソースアダプタに指定されているすべてのコネクション定義の情報が出力されます。

(6)　リソースアダプタの稼働ログを出力する場合の留意事項

Connector 1.5仕様に準拠したリソースアダプタの稼働ログを出力する場合，出力ファイルのファイル名は，次の形式になります。

<リソースアダプタの表示名>_<コネクション定義の並び順>_<ログファイルの通番>.log

<コネクション定義の並び順>は，DD（ra.xml）内で，対応する<connection-definition>が出現した順番（1，2，...）に対応します。

3.16.7　アプリケーションサーバ独自のConnector 1.5 API仕様

ここでは，Connector 1.5で仕様のインタフェースに対して，アプリケーションサーバ独自で規定した仕様について説明します。

(1)　javax.resource.spi.endpoint.MessageEndpointFactoryインタフェース

アプリケーションサーバでは，二つのメソッドの仕様を規定しています。

(a)　createEndpointメソッド

形式

public MessageEndpoint createEndpoint(XAResource xaResource) throws UnavailableException

アプリケーションサーバ独自の仕様

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでこのメソッドが呼び出された場合は，javax.resource.spi.UnavailableExceptionがスローされます。

このメソッドの中でMessage-driven Beanのインスタンス取得処理が実行されます。Message-driven Beanのインスタンスプールの上限に達していた場合は，Message-driven Beanのインスタンスを取得できるか，J2EEアプリケーションが停止するまで，メソッドがリターンされません。

例外

アプリケーションサーバで規定した例外の動作について示します。

例外

例外が発生するタイミング

javax.resource.spi.UnavailableException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでこのメソッドが呼び出した場合

Message-driven Beanのインスタンスの取得に失敗した場合

(b)　isDeliveryTransactedメソッド

形式

public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException

アプリケーションサーバ独自の仕様

J2EEサーバ用ユーザプロパティファイルのejbserver.distributedtx.XATransaction.enabledプロパティにtrueを指定すると，引数で渡されたメソッドのトランザクション属性にCMTのRequiredが指定されている場合に，trueを返却されます。

(2)　javax.resource.spi.endpoint.MessageEndpointインタフェース

アプリケーションサーバでは，三つのメソッドの仕様を規定しています。

(a)　beforeDeliveryメソッド

形式

public void beforeDelivery(Method method) throws NoSuchMethodException, ResourceException

アプリケーションサーバ独自の仕様

例外について規定しています。

例外

アプリケーションサーバで規定した例外の動作について示します。

例外

例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

javax.resource.spi.IllegalStateException

不正な順序で呼び出した場合（beforeDeliveryメソッド呼び出し後に再度beforeDeliveryメソッドを呼び出した場合。またはメッセージリスナのメソッドの呼び出し後にbeforeDeliveryメソッドを呼び出した場合）

javax.resource.spi.UnavailableException

予期しない例外が発生した場合

(b)　afterDeliveryメソッド

形式

public void afterDelivery() throws ResourceException

アプリケーションサーバ独自の仕様

例外について規定しています。

例外

アプリケーションサーバで規定した例外の動作について示します。

例外

例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

javax.resource.spi.IllegalStateException

不正な順序で呼び出した場合（Option B※のメッセージリスナのメソッド呼び出し後以外のタイミングでafterDelivery()を呼び出した場合）

javax.resource.spi.UnavailableException

予期しない例外が発生した場合

注※　Connector 1.5仕様に記述されているメッセージ配送オプションです。

(c)　releaseメソッド

形式

public void release()

アプリケーションサーバ独自の仕様

このメソッドを呼び出すと，エンドポイントに対応づけられたMessage-driven Beanのインスタンスが解放され，インスタンスプールに戻ります。

エンドポイントを使用し終わったら，必ずこのメソッドを呼び出して，Message-driven Beanをインスタンスプールに戻すように実装してください。

例外

アプリケーションサーバで規定した例外の動作について示します。

例外

例外が発生するタイミング

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

(3)　メッセージリスナのメソッド

インタフェースはメッセージリスナのインタフェースで定義されます。ここでは，アプリケーションサーバで規定した例外の動作について示します。

例外

例外が発生するタイミング

メッセージリスナのインタフェースに指定された例外

Message-driven Beanの実行時（システム例外が発生した時以外）

javax.ejb.EJBException

Message-driven Beanの実行時（システム例外が発生した時）

java.lang.IllegalStateException

EJBを含むJ2EEアプリケーションの停止処理を開始したあとでメッセージリスナのメソッドを呼び出した場合

release()メソッドがすでに呼び出されている場合

不正な順序で呼び出した場合（Option B※のメッセージ配送で，メッセージリスナのメソッドを呼び出したあと，続けてメッセージリスナのメソッドを呼び出した場合）

注※　Connector 1.5仕様に記述されているメッセージ配送オプションです。

3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定

ここでは，Connector 1.5仕様に準拠したリソースアダプタを使用する場合のJ2EEアプリケーションとリソースアダプタの設定について説明します。

設定は，それぞれアプリケーション統合属性ファイル※とConnector属性ファイルに指定します。

注※

この項の説明は，すべてアプリケーション統合属性ファイルを使用する場合の説明です。cjgetapppropコマンドでMessage-driven Bean属性ファイルを取得した場合は，Message-driven Bean属性ファイルに指定できます。Message-driven Bean属性ファイルを使用する場合は，「アプリケーション統合属性ファイルの<hitachi-connector-property>タグ下」を「Message-driven Bean属性ファイル」に読み替えてください。

(1)　設定できる項目

Connector 1.5仕様に準拠したリソースアダプタを使用する場合に設定できる項目について説明します。

(a)　J2EEアプリケーションの設定

J2EEアプリケーションに設定できる内容を次の表に示します。

表3‒75　J2EEアプリケーションの設定（Connector 1.5仕様に準拠するリソースアダプタを使用する場合）

機能

項目

対象

設定内容

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

管理対象オブジェクトのルックアップで使用する情報

WAR，Session Bean，Entity Bean，Message-driven Bean

<resource-env-ref>タグ下の次のタグに設定します。

<resource-env-ref-name>タグに，ルックアップで使用する名前を指定します。

<resource-env-ref-type>タグに，管理対象オブジェクトの型を指定します。

<linked-adminobject>−<resourceadapter-name>タグに，管理対象オブジェクトが含まれるリソースアダプタの表示名を指定します。

<linked-adminobject>−<adminobject-name>タグに，管理対象オブジェクトのオブジェクト名を指定します。

メッセージインフロー※

リソースアダプタとの対応づけ

Message-driven Bean

<message-ref>−<connection-destination>タグ下の<resource-adapter>タグに，対応づけるリソースアダプタの表示名を指定します。

Message-driven Beanが使用するインタフェース

Message-driven Bean

<messaging-type>タグに，Message-driven Beanが実装するインタフェースを指定します。

ActivationSpecの設定

Message-driven Bean

<activation-config>−<activation-config-property>タグ下の<activation-config-property-name>タグおよび<activation-config-property-value>タグに，ActivationSpecに設定するプロパティを指定します。

注※　設定値の一部は，使用するリソースアダプタの設定値と合わせる必要があります。

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

リソースアダプタのプロパティとして設定する項目のうち，Connector 1.5仕様に準拠したリソースアダプタで設定できる主な項目と，その項目の設定方法について説明します。なお，ここでは，Connector 1.5仕様に準拠したリソース固有の内容を説明します。

Connector 1.5仕様に準拠したリソースアダプタのプロパティとして設定できる内容を次の表に示します。

表3‒76　Connector 1.5仕様に準拠したリソースアダプタのプロパティ定義で設定できる内容

分類

項目

設定内容

管理対象オブジェクト

管理対象オブジェクト名※1

<adminobject>−<adminobject-name>タグ※2にルックアップで使用するオブジェクト名を指定します。管理対象オブジェクトをルックアップの対象にする場合は必ず指定してください。オブジェクト名には，連続したアンダースコア"__"を含めてはいけません。

なお，管理対象オブジェクトをルックアップする場合には，J2EEアプリケーションの設定も必要です。「(a)　J2EEアプリケーションの設定」を参照してください。

インタフェース

<adminobject>−<adminobject-interface>タグに使用するインタフェースを指定します。javax.jms.Queue，javax.jms.Topicなどを指定します。

実装クラスとプロパティ

<adminobject-class>タグに実装クラスを指定します。

<config-property>タグ下に管理対象オブジェクトのプロパティを設定します。

注※1　メッセージインフローで使用する管理対象オブジェクトの場合，指定する必要はありません。

注※2　DD（ra.xml）には存在しないタグです。

(2)　管理対象オブジェクトの設定

メッセージインフローで使用する管理対象オブジェクトの設定は，Connector属性ファイルに記述します。

管理対象オブジェクトに設定する内容は，リソースアダプタに依存します。使用するリソースアダプタのドキュメントを参照してください。

管理対象オブジェクトは，Message-driven Beanと対応づけて使用します。対応づけについては，「(5)　ActivationSpecの設定」を参照してください。

(3)　Message-driven Beanとリソースアダプタの対応づけの設定

Message-driven Beanとリソースアダプタの対応づけは，アプリケーション統合属性ファイルの<resource-adapter>タグに指定します。リソースアダプタの表示名を指定してください。

<resource-adapter>の階層を次に示します。

<hitachi-message-bean-property>
  <message-ref>
    <connection-destination>
      <resource-adapter>

これらのタグは，DD（ejb-jar.xml）には存在しない要素です。ただし，<hitachi-message-bean-property>はDDの<message-driven>に対応します。

リソースアダプタとの対応づけは，Message-driven Beanを含むJ2EEアプリケーションを開始したときに実行されます。なお，次の場合には，Message-driven Beanを含むJ2EEアプリケーションの開始が失敗します。この場合は，KDJE42359-Eのメッセージが出力されます。

<resource-adapter>タグにリソースアダプタの表示名が指定されていない場合

<resource-adapter>タグに指定した表示名のリソースアダプタが開始されていない場合

<resource-adapter>タグに指定した表示名のリソースアダプタが見つからない場合

Message-driven Beanは，管理対象オブジェクトとも対応づける必要があります。対応づけについては，「(5)　ActivationSpecの設定」を参照してください。

参考

アプリケーションサーバでは，<message-driven>−<message-destination-link>タグの情報は指定できません。

(4)　Message-driven Beanが使用するインタフェースの設定

Message-driven Beanが使用するインタフェースは，アプリケーション統合属性ファイルの<messaging-type>タグに記述します。Message-driven Beanが実装するインタフェース名を指定してください。

<messaging-type>の階層を次に示します。

<hitachi-message-bean-property>
  <messaging-type>

<hitachi-message-bean-property>はDD（ejb-jar.xml）の<message-driven>に対応します。

Message-driven Beanが使用するインタフェースには，リソースアダプタがサポートしているインタフェースを指定する必要があります。リソースアダプタがサポートするインタフェースは，リソースアダプタのDD（ra.xml）の<messagelistener-type>タグに指定されています。このタグに指定されている以外のインタフェースを指定した場合は，Message-driven Beanを含むJ2EEアプリケーションの起動が失敗します。この場合は，KDJE43167-Eのメッセージが出力されます。

リソースアダプタがサポートしているインタフェースは，サーバ管理コマンドの次のコマンドでも確認できます。これらのコマンドの引数に，-resnameおよび-inboundを指定して実行してください。

cjlistresコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistres（リソースの一覧表示）」を参照してください。

cjlistrarコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistrar（リソースアダプタの一覧表示）」を参照してください。

cjlistappコマンド

詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistapp（アプリケーションの一覧表示）」を参照してください。

なお，<messaging-type>タグの指定を省略した場合は，デフォルト値としてjavax.jms.MessageListenerインタフェースが使用されます。

参考

javax.jms.MessageListenerインタフェースは，EJB2.0まで固有のメッセージリスナインタフェースとして使用されていたインタフェースです。

(5)　ActivationSpecの設定

ActivationSpecとは，Message-driven Beanを活性化するために必要な設定を持つJavaBeansです。ActivationSpecには，リソースアダプタの設定に合わせて設定が必要なプロパティがあります。

(a)　ActivationSpecの設定の概要

ActivationSpecに設定する値は，アプリケーション統合属性ファイルの<activation-config>タグ下に記述します。プロパティ名とプロパティ値を指定してください。複数指定できます。

<activation-config>の階層を次に示します。

<hitachi-message-bean-property>
  <activation-config>
    <activation-config-property>
      <activation-config-property-name>
      <activation-config-property-value>

ActivationSpecについてのデフォルトの設定値は，リソースアダプタのDD（ra.xml）に設定できます。<resourceadapter>−<config-property>タグに設定した値が，デフォルト値として使用されます。デフォルト値を記載している場合にアプリケーション統合属性ファイルでActivationSpecの値を設定したときには，<hitachi-message-bean-property>タグ下で指定した値で上書きされます。

ActivationSpecのプロパティとして必ず設定しなくてはいけないプロパティについては，「(b)　設定が必要なプロパティ」で説明します。

(b)　設定が必要なプロパティ

ActivationSpecの設定では，リソースアダプタのDD（ra.xml）の<activationspec>−<required-config-property>タグに指定されているプロパティの値を設定する必要があります。設定が必要なプロパティは，サーバ管理コマンドの次のコマンドでも確認できます。これらのコマンドの引数に，-resnameおよび-listenertypeを指定して実行してください。

cjlistresコマンド

cjlistrarコマンド

cjlistappコマンド

このほか，ActivationSpecに設定できるプロパティはリソースアダプタに依存します。使用するリソースアダプタのドキュメントを参照してください。

(c)　JMSをサポートするメッセージリスナを使用する場合に設定が必要なプロパティ

JMSをサポートするメッセージリスナ（javax.jms.MessageListenerインタフェースを使用するメッセージリスナ）を使用する場合，ActivationSpecに次のプロパティが必要です。<activation-config>タグ下に指定してください。

destination

destinationType

なお，アプリケーションサーバでは，これらのプロパティが指定されているかどうかのチェックは実施されません。プロパティ設定が適切かどうかは，リソースアダプタが提供するActivationSpec#validateメソッドで確認してください。

参考

EJB 2.0で<message-driven>タグ下の要素として指定していた次の項目は，EJB 2.1以降では削除されています。

<message-selector>

<acknowledge-mode>

<message-driven-destination>−<subscription-durability>

Connector 1.5仕様では，これらの要素を<activation-config>下のプロパティとして指定できることが推奨されています。ただし，指定できるかどうかは使用するリソースアダプタに依存します。

JMSをサポートするメッセージリスナを使用する場合のActivationSpec仕様の詳細については，Connector 1.5仕様のドキュメントを参照してください。

(d)　ActivationSpecの生成・設定で発生するエラー

ActivationSpecを生成，設定するときに，次の表に示す状態になった場合，エラーが発生します。エラーが発生すると，J2EEアプリケーションの開始は失敗します。

エラーが発生する場合と出力されるメッセージを次の表に示します。

表3‒77　エラーが発生する場合と出力されるメッセージの対応

エラーが発生する場合

出力されるメッセージ

ActivationSpecの実装クラスのインスタンス生成に失敗した場合

KDJE43168-E

ActivationSpecに指定したクラスがjavax.resource.spi.ActivationSpecインタフェースを実装していなかった場合

KDJE43172-E

<activation-config-property-name>タグに対応するプロパティのsetterメソッドが，ActivationSpecにない場合

KDJE43169-E

ActivationSpecに各プロパティを設定したあとで，設定が適切であるかをチェックするメソッド(ActivationSpec#validateメソッド)の呼び出しで例外がスローされた場合

KDJE43170-E

リソースアダプタのDD（ra.xml）で指定したプロパティ<required-config-property>タグに対応する設定項目が，アプリケーション統合属性ファイルの<activation-config>タグとして記述されていない場合

KDJE43171-E

ActivationSpecのsetResourceAdapterメソッドで例外がスローされた場合※

KDJE43173-E

注※　setResourceAdapterメソッドはjavax.resource.spi.ResourceAdapterAssociationインタフェースで定義するメソッドです。javax.resource.spi.ResourceAdapterAssociationインタフェースは，javax.resource.spi.ActivationSpecインタフェースのスーパーインタフェースです。

3.16.9　属性ファイルの指定例

ここでは，メッセージインフローを実行する場合の属性ファイルの指定方法について，例を使用して説明します。

Connector属性ファイルとアプリケーション統合属性ファイルでは，次の図に示す個所の設定を合わせる必要があります。

図3‒52　Connector属性ファイルとアプリケーション統合属性ファイルで同じ値を指定する個所

それぞれの指定内容は次のとおりです。

aには，Message-driven Beanが使用するインタフェースを指定します。

bには，ActivationSpecと管理対象オブジェクトの対応づけを指定します。

cには，Message-driven Beanとリソースアダプタの対応づけを指定します。

以降，a〜cに指定する内容を中心に説明します。

(1)　javax.jms.MessageListenerインタフェースを使用したMessage-driven Beanおよびリソースアダプタの場合

メッセージリスナのインタフェースとしてjavax.jms.MessageListenerインタフェースを使用する場合の属性ファイルの指定例を示します。

ここでは，次の図に示す構成を例にして説明します。JMSに対応した二つのMessage-driven Beanが，それぞれ別の管理オブジェクト（javax.jms.Queue）からメッセージを受信する例です。

図3‒53　javax.jms.MessageListenerインタフェースを使用したMessage-driven Beanおよびリソースアダプタの構成例

アプリケーション統合属性ファイルの指定例を次に示します。

図3‒54　アプリケーション統合属性ファイルの指定例（javax.jms.MessageListenerインタフェースを使用する場合）

図の説明：

図中の(3)〜(5)は，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」での説明の項番と対応しています。また，a，b-1，b-2，cは，それぞれ次の設定を示します。

a：Message-driven Beanが使用するインタフェース

b-1，b-2：ActivationSpecと管理対象オブジェクトの対応づけ

c：Message-driven Beanとリソースアダプタの対応づけ

なお，a，b-1，b-2，cの設定値は，図3-56と対応しています。

Connector属性ファイルの指定例を次の図に示します。

図3‒55　Connector属性ファイルの指定例（javax.jms.MessageListenerインタフェースを使用する場合）

図の説明：

図中の(2)〜(4)は，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」での説明の項番と対応しています。また，a，b-1，b-2，cは，それぞれ次の設定を示します。

a：Message-driven Beanが使用するインタフェース

b-1，b-2：ActivationSpecと管理対象オブジェクトの対応づけ

c：Message-driven Beanとリソースアダプタの対応づけ

なお，a，b-1，b-2，cの設定値は，図3-57と対応しています。

(2)　任意のメッセージリスナインタフェースを使用したMessage-driven Beanおよびリソースアダプタの場合

メッセージリスナのインタフェースとして任意のインタフェースを使用する場合の属性ファイルの指定例を示します。

ここでは，次の図に示す構成を例にして説明します。

図3‒56　任意のメッセージリスナインタフェースを使用したMessage-driven Beanおよびリソースアダプタの構成例

この例では，リソースアダプタが次に示す二つの独自のインタフェースに対応しています。

examples.Listener1は管理対象オブジェクトと独立して使用するメッセージリスナインタフェースです。

examples.Listener2は管理対象オブジェクトと関連づけて使用するメッセージリスナインタフェースです。

アプリケーション統合属性ファイルの指定例を次の図に示します。

図3‒57　アプリケーション統合属性ファイルの指定例（任意のメッセージリスナインタフェースを使用する場合）

図の説明：

図中の(3)〜(5)は，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」での説明の項番と対応しています。また，a-1，a-2，b，cは，それぞれ次の設定を示します。

a-1，a-2：Message-driven Beanが使用するインタフェース

b：ActivationSpecと管理対象オブジェクトの対応づけ

c：Message-driven Beanとリソースアダプタの対応づけ

なお，a-1，a-2，b，cの設定値は，図3-59と対応しています。

Connector属性ファイルの指定例を次の図に示します。

図3‒58　Connector属性ファイルの指定例（任意のメッセージリスナインタフェースを使用する場合）

図の説明：

図中の(2)〜(4)は，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」での説明の項番と対応しています。また，a-1，a-2，b，cは，それぞれ次の設定を示します。

a-1，a-2：Message-driven Beanが使用するインタフェース

b：ActivationSpecと管理対象オブジェクトの対応づけ

c：Message-driven Beanとリソースアダプタの対応づけ

なお，a-1，a-2，b，cの設定値は，図3-60と対応しています。

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

Connector 1.5仕様に準拠したリソースアダプタを使用する場合の注意事項について説明します。注意事項はリソースアダプタの使用方法によって異なります。

(1)　共通の注意事項

Connector 1.5仕様に準拠するリソースアダプタに関する稼働情報は，運用管理ポータルまたはmngsvrutilコマンドを使用しても取得できません。

運用管理ポータルまたはmngsvrutilコマンドを使用して，Connector 1.5仕様に準拠するリソースアダプタのステータス情報を取得した場合，リソースアダプタが稼働していても，停止を示す情報が返されます。

(2)　J2EEリソースアダプタとしてデプロイして使用する場合（J2EEアプリケーションに含めないで使用する場合）

管理対象オブジェクトをアノテーションで指定する場合は，コンテナ拡張ライブラリに管理対象オブジェクトのインタフェースを追加する必要があります。

コンテナ拡張ライブラリについては，「19.　コンテナ拡張ライブラリ」を参照してください。

(3)　J2EEアプリケーションに含めて使用する場合

リロード機能を使用する場合は，次のクラス（インタフェース）をコンテナ拡張ライブラリに追加する必要があります。

javax.resource.spi.ActivationSpecインタフェースの実装クラス

リソースアダプタがサポートするメッセージリスナのインタフェース

管理対象オブジェクトをアノテーションで指定する場合は，コンテナ拡張ライブラリに管理対象オブジェクトのインタフェースを追加する必要があります。

Inboundのリソースアダプタを使用した場合，グローバルトランザクションは使用できません。

コンテナ拡張ライブラリについては，「19.　コンテナ拡張ライブラリ」を参照してください。

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

リソースアダプタのプロパティ設定後，設定した内容が正しいかどうか，検証することができます。これを接続テスト機能といいます。接続テストで検証される内容は，接続するリソースごとに異なります。リソースごとの接続テストでの検証内容を，次の表に示します。

なお，接続テストの実行手順や，リソースアダプタの設定については，「3.3.8　リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）」，および「3.3.9　リソースアダプタの設定の流れ（J2EEアプリケーションに含めて使用する場合）」を参照してください。

表3‒78　接続テストでの検証内容

リソースの種類

接続方法

接続テストでの検証内容

データベース

DB Connector

指定されたトランザクションサポートレベルが使用できること※1，※2

DB Connectorの設定が正しいこと

使用するJDBCドライバの設定が正しいこと

データベースとの接続を確立できること

SQL発行が成功すること

データベース上のキュー

Reliable Messaging

指定されたトランザクションサポートレベルが使用できること※1

Reliable Messagingの設定が正しいこと

連携するDB Connector for Reliable Messagingが開始していること

連携するDB Connector for Reliable Messagingの設定が正しいこと

使用するデータベースとの接続を確立できること

DB Connector for Reliable Messaging

DB Connector for Reliable Messagingの設定が正しいこと

DB Connector for Reliable Messagingが開始していること

連携するReliable Messagingの設定が正しいこと

連携するReliable Messagingが開始していること

使用するJDBCドライバの設定が正しいこと

使用するデータベースとの接続を確立できること

SQL発行が成功すること

OpenTP1

TP1/Message Queue - Access

指定されたトランザクションサポートレベルが使用できること※1

TP1/Message Queue - Accessの設定が正しいこと

TP1/Message Queue - Accessが，TP1/Message Queueとの接続を確立できること

TP1 Connector

指定されたトランザクションサポートレベルが使用できること※1

TP1 Connectorの設定が正しいこと

TP1インバウンドアダプタ

Inboundでの通信のため，接続テストはできません。接続テストをしようとすると，KDJE48606-Eのメッセージが出力されます。

CJMSPブローカー

CJMSPリソースアダプタ

CJMSPブローカーとの接続を確立できること

SMTPサーバ

メールコンフィグレーション

SMTPサーバへの接続を確立できること

そのほか

この製品が提供しているリソースアダプタ以外のリソースアダプタ

リソースへの接続を確立できること※3

（javax.resource.spi.ManagedConnectionFactoryの実装クラスのcreateManagedConnectionメソッド呼び出しが成功することによって，リソースとの接続が確立できたものとします）。

Connector1.5に準拠したリソースアダプタの場合は，リソースアダプタを開始していないときに，開始と停止ができること（javax.resource.spi.ResourceAdapterの実装クラスのstartメソッドおよびstopメソッド呼出しが成功することによって，リソースアダプタを開始・停止できたものとします）。

注※1　リソースアダプタのトランザクションサポートレベルにグローバルトランザクション（XATransaction）が指定されている場合は，usrconf.propertiesのejbserver.distributedtx.XATransaction.enabledキーがtrueになっていれば使用できます。なお，トランザクションサポートレベルについては，「3.4.3　リソースごとに使用できるトランザクションの種類」を参照してください。

注※2　接続先のデータベースがXDM/RD E2のときは，グローバルトランザクション（XATransaction）は使用できません。トランザクションリカバリ用の物理コネクションの取得に失敗するため，DB Connectorの開始ができません。

注※3　Outboundの通信をする場合にリソースとの接続に必要なコネクション定義がないときは，メッセージKDJE48606-Eが出力されてテストに失敗します。

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

ファイアウォールをシステムに組み込んで運用する場合，通信に使用するポートを固定し，固定したポートを使用した通信だけを許可する必要があります。

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

表3‒79　この節の構成（ファイアウォール環境での運用のための機能）

分類

タイトル

参照先

解説

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

3.18.1

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

3.18.2

設定

ファイアウォール環境での運用のための設定

3.18.3

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

参考

コネクションスイーパによる通信性能低下の回避

ファイアウォールには，一定時間以上無通信のセッションを強制切断する機能を持つものがあります。ファイアウォールがアプリケーションサーバとデータベースサーバの間に配置されていて，コネクションプールが有効の場合には，しばらくの間使用されなかったコネクションがファイアウォールによって切断されることがあります。その後の切断されたコネクションの使用は，長時間の待ちが発生します。この現象は，ファイアウォールの無通信切断時間よりも早い時間で未使用コネクションを破棄するようにコネクションスイーパ機能を設定することで回避できます。

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

グローバルトランザクションを使用する場合，トランザクションリカバリ処理用の通信ポートを使用します。ファイアウォールをシステムに組み込んで運用する場合，ファイアウォールの構成によっては，このポートの通信を許可する必要があります。デフォルトではポート番号として20302が使用されますが，変更することもできます。

トランザクションリカバリ用通信ポートの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.18.3　ファイアウォール環境での運用のための設定」を参照してください。

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

TPBrokerのスマートエージェント（OSAgent）は通信ポートを使用します。ファイアウォールをシステムに組み込んで運用する場合，ファイアウォールの構成によっては，このポートを使用する通信を許可する必要があります。

スマートエージェントが使用する通信ポートの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「3.18.3　ファイアウォール環境での運用のための設定」を参照してください。

なお，J2EEサーバのプロパティに設定した通信ポートは，環境変数OSAGENT_PORTにも指定する必要があります。J2EEサーバのプロパティと，環境変数OSAGENT_PORTには，必ず，同じ値を設定してください。

3.18.3　ファイアウォール環境での運用のための設定

ファイアウォール環境で運用する場合，J2EEサーバの設定が必要です。簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次の表に示す項目を設定します。

表3‒80　簡易構築定義ファイルでのファイアウォール環境での運用のための設定

項目

設定するパラメタ

設定内容

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

ejbserver.distributedtx.recovery.port

トランザクションのリカバリで使用する固定ポート番号を指定します。

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

vbroker.agent.port

スマートエージェントが使用する通信ポートを指定します。

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

この節では，EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項について説明します。

ポイント

EJBクライアントアプリケーションでトランザクションを開始できるのは，EJBクライアントマシンにアプリケーションサーバをインストールしている場合です。ClientをインストールしたEJBクライアントマシンでは，EJBクライアントアプリケーションでトランザクションを開始することはできません。

EJBクライアントアプリケーションでトランザクションを開始した場合，グローバルトランザクションを使用してアプリケーションサーバ側のEJBを呼び出せます。このとき，トランザクションマネージャとトランザクションサービスは，EJBクライアントとアプリケーションサーバ間でトランザクションを伝播し，最終的に2フェーズコミットを実行します。

EJBクライアントアプリケーションで開始したトランザクション内では，アプリケーションサーバ上の複数のEJBを呼び出せます。アプリケーションサーバ側では，複数のリソースにアクセスできます。なお，EJBクライアントアプリケーションからリソースに直接アクセスすることはできません。

ここでは，EJBクライアントアプリケーションでトランザクションを開始する場合に注意することについて説明します。

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

EJBクライアントアプリケーションでトランザクションを開始する場合に，アプリケーション開発時に注意することを次に示します。EJBクライアントアプリケーションでのトランザクションの実装については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.5　EJBクライアントアプリケーションでのトランザクションの実装」を参照してください。

EJBクライアントアプリケーションでグローバルトランザクションを使用するには，EJBクライアントアプリケーション起動直後に，EJBクライアントアプリケーションで使用するサービスを初期化するための処理をユーザプログラムから呼び出す必要があります。この初期化処理を呼び出すことで，トランザクションマネージャとトランザクションサービスが初期化されます。初期化処理としては，EJBClientInitializerクラスのinitialize()メソッドを呼び出してください。

トランザクション処理中にEJBクライアントアプリケーションが異常終了した場合も，サービスを初期化するための処理をユーザプログラムで呼び出すことによって，トランザクションのリカバリ処理が開始できるようになります。なお，リカバリ処理はバックグラウンドで実行されるため，initialize()メソッドはリカバリ処理の完了を待たないでリターンします。EJBクライアントアプリケーションの再起動によってグローバルトランザクションのリカバリ処理が開始するように，EJBクライアントアプリケーションを設計してください。

EJBクライアントアプリケーションでトランザクションを開始している場合，必ずすべてのトランザクションを決着させてから，EJBクライアントアプリケーションが停止するように設計してください。トランザクションの決着処理を待たないでEJBクライアントアプリケーションが停止すると，未決着トランザクションがトランザクション内に残留するおそれがあります。この状態になると，アプリケーションサーバの正常停止やリソースアダプタの停止ができなくなったり，リソースのロックが解除されなくなったりする場合があります。

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

ここでは，システム構築時に注意することと設定について説明します。

(1)　システム構築時の注意

EJBクライアントアプリケーションでトランザクションを開始する場合に，システム構築時に注意することを次に示します。EJBクライアントアプリケーションのトランザクションの設定については，「(2)　EJBクライアントアプリケーションでトランザクションを使用するための設定」を参照してください。

EJBクライアントアプリケーションでトランザクションを開始する場合，グローバルトランザクションを使用するために，アプリケーションサーバ側でライトトランザクション機能を無効に設定する必要があります（デフォルトでは有効になっています）。

呼び出されるEJBを，EJBコンテナで管理するトランザクション（CMT）でMandatory属性，Required属性，Supports属性などに指定すると，EJBクライアントアプリケーション側で開始したトランザクションの範囲内で実行されます。

(2)　EJBクライアントアプリケーションでトランザクションを使用するための設定

ここでは，EJBクライアントアプリケーションでトランザクションを使用するための設定について説明します。

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，EJBクライアントアプリケーションのトランザクションは使用できません。

EJBクライアントアプリケーションでトランザクションを使用するためには，次の設定が必要です。

JARファイルの設定

プロパティの設定

UserTransactionの取得の設定

UserTransactionの取得の設定は，J2EEアプリケーション開発時の設定内容です。EJBクライアントアプリケーションでトランザクションを使用するために，EJBクライアントアプリケーションからUserTransaction（javax.transaction.UserTransaction）を取得するための設定が必要です。設定方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「3.5　EJBクライアントアプリケーションでのトランザクションの実装」を参照してください。

ここでは，EJBクライアントアプリケーションでトランザクションを使用するためのJARファイルとプロパティの設定について説明します。

(3)　JARファイルの設定

EJBクライアントアプリケーションでトランザクションを使用するために，次のJARファイルをクラスパスに設定します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥TPB¥lib¥tpotsinproc.jar

<Application Serverのインストールディレクトリ>¥CC¥lib¥ejbserver.jar※

UNIXの場合

/opt/Cosminexus/TPB/lib/tpotsinproc.jar

/opt/Cosminexus/CC/lib/ejbserver.jar※

注※　

クラスパスの設定で，ejbserver.jarはHiEJBClientStatic.jarよりも後ろに設定してください。

クラスパスへのJARファイルの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

(4)　プロパティの設定

EJBクライアントアプリケーションでトランザクションを使用するために設定が必要なキーについて説明します。プロパティの設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「3.3.5　EJBクライアントアプリケーションのプロパティの設定」を参照してください。各キーの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

EJBクライアントアプリケーションでトランザクションを使用するためには，次のキーを設定します。

(a)　必須のプロパティ

ejbserver.client.transaction.enabled

「true」を指定して，EJBクライアントアプリケーションでのトランザクションの使用を有効にします。

ejbserver.distributedtx.recovery.port

グローバルトランザクションを使用するとき，トランザクションリカバリで使用する固定ポート番号を指定します。EJBクライアントのプロセスごとに別のポート番号を指定してください。また，同一マシン上で動作するアプリケーションサーバのリカバリ用ポート番号とは別のポート番号を指定してください。

ejbserver.client.transaction.clientName

トランザクションサービスが使用するクライアント名を指定します。ここでは，EJBクライアントのプロセスごとに別の名前を指定してください。また，同一マシン上で動作するJ2EEサーバ名とは別の名前を指定してください。

ejbserver.distributedtx.ots.status.directory1

トランザクションサービスが使用するステータスファイルや，そのバックアップを配置するディレクトリを指定します。EJBクライアントのプロセスごとに別のディレクトリを指定してください。また，J2EEサーバに指定したステータスファイルのディレクトリとは別のディレクトリを指定してください。

(b)　任意のプロパティ

ejbserver.jta.TransactionManager.defaultTimeOut

トランザクションタイムアウトが発生するまでの時間を指定します。

ejbserver.distributedtx.ots.status.directory2

トランザクションサービスが使用するステータスファイルや，そのバックアップを配置する二つ目のディレクトリを指定します。EJBクライアントのプロセスごとに別のディレクトリを指定してください。また，J2EEサーバに指定したステータスファイルのディレクトリとは別のディレクトリを指定してください。

(5)　注意事項

EJBクライアントアプリケーションのトランザクションの設定での注意事項を次に示します。

グローバルトランザクションを使用するためには，アプリケーションサーバ側でライトトランザクション機能を無効にする必要があります。デフォルトの設定では，ライトトランザクション機能が有効になっています。J2EEサーバのusrconf.propertiesのejbserver.distributedtx.XATransaction.enabledキーで「true」を指定すると，ライトトランザクション機能が無効となり，グローバルトランザクションが利用できるようになります。

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

EJBクライアントアプリケーションでトランザクションを開始した場合に，運用時に注意することを次に示します。

EJBクライアントアプリケーションの停止後に，アプリケーションサーバやリソースアダプタを停止できない場合は，未決着トランザクションがトランザクション内に残留しているおそれがあります。この場合，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を実施してください。

なお，リカバリ処理は，EJBクライアントアプリケーション内で，再起動後にサービスの初期化処理を呼び出されることで実行されます。

トランザクション処理中に障害などの理由でEJBクライアントマシンがダウンした場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を実施する必要があります。

EJBクライアントアプリケーションで開始したトランザクションは，メソッドキャンセル機能を使用して強制決着させることはできません。

サービスの初期化処理で例外が発生した場合，EJBクライアントアプリケーションの実行時のシステムプロパティなどが正しく設定されていないおそれがあります。例外メッセージに従って対処してください。

EJBクライアントアプリケーションでトランザクションを開始した場合，JTAやOTSが出力する性能解析トレースにルートアプリケーション情報やクライアントアプリケーション情報が含まれません。リクエストをトレースする場合には，スレッドのハッシュコードやXIDの情報を使用してください。

また，トランザクションタイムアウトが発生した時に出力されるメッセージには，ルートアプリケーション情報の代わりに，トランザクションを開始したスレッドのハッシュコードが含まれています。この情報を使用してトレースすることもできます。

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

この章では，OpenTP1システムで動作するSUPからアプリケーションサーバ上のJ2EEアプリケーションをInboundで呼び出す機能である，TP1インバウンド連携機能について説明します。

なお，この機能を使用できる製品については，「4.3　TP1インバウンド連携機能の前提条件」を参照してください。

4.1　この章の構成

この章では，TP1インバウンド連携機能について説明します。

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

表4‒1　この章の構成（TP1インバウンド連携機能）

分類

タイトル

参照先

解説

TP1インバウンド連携機能の概要

4.2

TP1インバウンド連携機能の前提条件

4.3

TP1インバウンド連携機能で使用するメモリの見積もり

4.4

OpenTP1の機能との対応

4.5

コネクション管理機能

4.6

RPC通信機能

4.7

スケジュール機能

4.8

トランザクション連携機能

4.9

実装

Message-driven Bean（サービス）の実装

4.10

OpenTP1のアプリケーションプログラムの作成

4.11

設定

アプリケーションサーバの実行環境での設定

4.12

OpenTP1での設定

4.13

OpenTP1とアプリケーションサーバ間のタイムアウトの設定

4.14

運用

TP1インバウンドアダプタとMessage-driven Bean（サービス）の開始と終了

4.15

性能解析トレース情報の引き継ぎ

4.16

注意事項

TP1インバウンドアダプタで発生するRPCエラー応答

4.17

4.2　TP1インバウンド連携機能の概要

TP1インバウンド連携機能は，OpenTP1システム上で動作するユーザアプリケーションプログラムから，アプリケーションサーバ上で動作するJ2EEアプリケーションを業務として呼び出すための機能です。この機能によって，OpenTP1を使用したレガシーシステムを運用している場合に，新たに追加する業務をJ2EEアプリケーションとして実装して，既存のシステムに組み込んで使用できます。また，OpenTP1システム上で動作するユーザアプリケーションプログラムで開始されたトランザクションに，アプリケーションサーバのMessage-driven Bean（CMT）で実行する処理を参加させられます。

TP1インバウンド連携機能では，OpenTP1のユーザアプリケーションプログラムからの呼び出しをアプリケーションサーバ上で動作するTP1インバウンドアダプタで受け付け，J2EEサーバ上のMessage-driven Beanで業務処理を実行します。TP1インバウンドアダプタは，Connector 1.5仕様に準拠したリソースアダプタです。

トランザクション連携機能を使用する場合のTP1インバウンド連携機能の概要について示します。

なお，TP1インバウンド連携機能は，ユーザアプリケーションプログラムのうちSUP，SPP，およびMHPからの呼び出しが可能ですが，このマニュアルでは，SUPからの呼び出しを例に説明します。

図4‒1　TP1インバウンド連携機能の概要

TP1インバウンド連携機能を使用する場合，クライアントとなるSUPからは，OpenTP1システムのSPPを呼び出す場合と同様の手順でアプリケーションサーバ上の業務を呼び出します。また，SPPの呼び出し時と同様にデータをやり取りできます。

さらに，トランザクション連携機能を使用することで，SUPからのリソース更新と，Message-driven Beanからのリソース更新を同期できます。

TP1インバウンドアダプタは，SPPと同様の手順での業務の呼び出しを実現するために，次の4種類の機能を備えています。

コネクション管理機能

OpenTP1とアプリケーションサーバ間のコネクションの接続，切断，およびプーリングを制御する機能です。これによって，コネクションを接続したままでOpenTP1と通信できます。また，コネクションの接続と切断に伴うボトルネックを削減でき，通信効率を向上できます。なお，OpenTP1とアプリケーションサーバとの間のコネクション数がしきい値に達すると，コネクションを切断（一時クローズ処理）します。

RPC通信機能

OpenTP1で扱うRPC電文を解析し，応答電文を生成して，RPC通信を実行する機能です。JCAコンテナを介してMessage-driven Beanを呼び出します。

スケジュール機能

RPC要求のスケジューリングを実行する機能です。OpenTP1のスケジュールサービスと同様の処理を実現するために使用します。

トランザクション連携機能

OpenTP1のSUPで開始されたトランザクションにMessage-driven Bean（CMT）で実行した処理を参加させる機能です。

ただし，TP1インバウンドアダプタでは，OpenTP1のネームサービスの代替機能は提供しません。このため，TP1インバウンドアダプタを使用するためには，クライアントとなるOpenTP1側でユーザサービスネットワーク定義によるスケジューラダイレクト機能を利用する必要があります。

4.3　TP1インバウンド連携機能の前提条件

TP1インバウンド連携機能は，次のどれかの製品で利用できます。

TP1/Server Base Version 5以降

uCosminexus TP1/Server Base Version 7以降

uCosminexus TP1/LiNK Version 7以降

4.4　TP1インバウンド連携機能で使用するメモリの見積もり

TP1インバウンド連携機能を使用する際に追加で必要となるメモリ所要量（単位：メガバイト）は，次の計算式に従って見積もってください。

TP1インバウンド連携機能を使用する際に追加で必要となるメモリ所要量

=2+1.8×MDB最大インスタンス数の合計

＋RPC要求電文の最大サイズ×（最大同時接続数+スケジュールキュー長の合計+MDBの最大インスタンス数の合計）

＋RPC応答電文の最大サイズ×MDB最大インスタンス数の合計

4.5　OpenTP1の機能との対応

この節では，TP1インバウンド連携機能とOpenTP1の機能との対応について説明します。

4.5.1　クライアントでサポートするOpenTP1の機能

アプリケーションサーバを呼び出すOpenTP1のクライアントでのOpenTP1の機能の使用可否を次の表に示します。なお，OpenTP1のそれぞれの機能の詳細については，マニュアル「OpenTP1 解説」およびマニュアル「OpenTP1 プログラム作成の手引」を参照してください。

表4‒2　クライアントでのOpenTP1の機能の使用可否

機能の分類

OpenTP1の機能

使用可否

ユーザアプリケーションプログラムの種類

SUP

○

SPP

○

MHP

○

RPCの種類

同期応答型RPC

○

非同期応答型RPC

×

非応答型RPC

×

連鎖RPC

×

トランザクショナルRPC

○

認証RPC

×

呼び出し先のRPC受信形態

キュー受信型サーバ

○

ソケット受信型サーバ

×

リモートAPI機能

リモートAPI機能

×

RPCのサービス要求方式

ユーザサービスネットワーク定義によるスケジューラダイレクト機能

○

dc_rpc_call_to関数によるスケジューラダイレクト機能

○

ネームサービス機能

×

ドメインネームシステム機能

×

グローバル検索機能

×

マルチスケジューラ機能

×

電文操作

ユーザデータ電文の圧縮機能

×

ユーザ電文

ユーザ電文長8メガバイト拡張

○

そのほか

コネクションの保持

○

テストモード

×

要求用TCP/IPコネクションの接続リトライ

○

詳細エラーコード取得機能

×

（凡例）

○：使用できる　×：使用できない

各機能に対するTP1インバウンドアダプタでの対応について，機能の分類ごとに説明します。

(1)　ユーザアプリケーションプログラムの種類

TP1インバウンドアダプタでは，SUP（サービス利用プログラム），SPP（サービス提供プログラム），およびMHP（メッセージ処理プログラム）からの処理を受け付けます。

(2)　RPCの種類

TP1インバウンドアダプタでは，OpenTP1で使用できるRPC形態のうち，同期応答型RPCおよびトランザクショナルRPCを使用できます。

非同期応答型RPCまたは非応答型RPCを使用してTP1インバウンドアダプタを呼び出した場合，クライアントにはエラーが返されます。

連鎖RPCとは，RPCを複数回実行する場合に，各RPC呼び出しを必ず同じプロセスで実行することを保証するOpenTP1の機能です。TP1インバウンドアダプタでは，連鎖RPCを保証しません。クライアントで連鎖RPCを有効にしてRPC通信を実行した場合は，エラーが返されます。

なお，TP1インバウンドアダプタでは，認証RPCはサポートしません。

(3)　呼び出し先のRPC受信形態

TP1インバウンドアダプタでは，キュー受信型サーバだけを使用できます。

TP1インバウンドアダプタでは，必ずスケジュールキューを経由してサービス要求を受信します。このため，スケジュールキューを経由しないで直接サービス要求を受信する形態であるソケット受信型サーバ機能は使用できません。

(4)　リモートAPI機能

TP1インバウンドアダプタでは，リモートAPI機能は使用できません。

リモートAPI機能とは，OpenTP1のSPP側でRPCの代理実行をする機能です。OpenTP1では，リモートAPIを使用することで，ファイアウォールの内側にあるUAPに対してサービスを要求できます。TP1インバウンドアダプタを使用する場合，ファイアウォールの内側のUAPに対するサービス要求はできません。

(5)　RPCのサービス要求方式

TP1インバウンドアダプタでは，ユーザサービスネットワーク定義によるスケジューラダイレクト機能を利用して，SUPからSPPを呼び出します。ユーザサービスネットワーク定義によるスケジューラダイレクト機能とは，あらかじめ，ユーザサービスネットワーク定義にサービス情報を静的に定義しておくことで，ネームサービスを参照しないで，直接スケジュールサービスにアクセスするための機能です。TP1インバウンドアダプタを呼び出す場合，必ずこの機能を使用してください。

ユーザサービスネットワーク定義に複数のホストを記載することで，OpenTP1の機能によってランダムに決定されたノードにサービス要求を転送することができます。一度決定した転送先ノードは，基本的には固定されます。また，オプションの定義によって，ノード決定を定期間隔で再決定できるようにチューニングできます。

TP1インバウンドアダプタでは，OpenTP1のネームサービスを代替する機能は使用できません。このため，ネームサービスを使用したサービス情報の参照はできません。ユーザサービスネットワーク定義によるスケジューラダイレクト機能を使用する設定がない場合，SUPでサービス情報を取得できないため，TP1インバウンドアダプタを呼び出せません。

なお，TP1インバウンドアダプタでは，ネームサービスの代替機能を使用できないため，ネームサービスの付加機能である次の機能も使用できません。

ドメインネームシステム機能

グローバル検索機能

また，TP1インバウンドアダプタでは，OpenTP1のマルチスケジューラ機能を使用できません。マルチスケジューラ機能とは，複数のスケジューラを起動して複数のRPCを同時に受け付ける機能です。ただし，TP1インバウンドアダプタのスケジュール機能では，受け付けた要求をマルチスレッドで処理するため，すでに電文を処理している場合も，新たに受け付けた別のRPCを同時に処理できます。

参考

OpenTP1のネームサービス機能

OpenTP1では，ネームサービスを使用して，各ノードにあるサービスに関する情報を検索できます。

OpenTP1でSUPからSPPを呼び出す通常の手順では，SUPでdc_rpc_call関数を実行する際に，ローカル環境のOpenTP1システム中のネームサービスに対してサービス情報の検索を実行します。ローカル環境のネームサービスは，ほかのノードのネームサービスと情報連携して，各ノードに存在するサービス情報を保持しています。検索実行後，ネームサービスから目的のサービスグループに対応するサービスの情報（スケジュールサービスのあるホストおよびポート番号の情報）が返されます。SUPでは，返却された情報を基に，スケジュールサービスにRPC通信を実行します。

(6)　電文操作

TP1インバウンドアダプタでは，ユーザデータ電文圧縮機能を使用できません。

ユーザデータ電文圧縮機能とは，RPCによってネットワーク上に送信されたユーザ電文を圧縮することによって，パケット数を削減し，ネットワークの混雑を緩和するOpenTP1の機能です。

TP1インバウンドアダプタでは，ユーザデータが圧縮されていた場合，エラーを返却します。

(7)　ユーザ電文

RPC通信で，8メガバイトまでのユーザ電文を送受信できます。

(8)　そのほか

TP1インバウンドアダプタでは，表4-2で「そのほか」に分類した機能のうち，コネクションの保持，および要求用TCP/IPコネクションの接続リトライを実行できます。コネクションの保持では，ノード間で確立したコネクションを保持できます。また，要求用TCP/IPコネクションの接続リトライは，RPC要求時にコネクションの確立に失敗した場合に，コネクションの確立をリトライするOpenTP1の機能です。

次の機能は使用できません。

テストモードは有効にできません。テストモードが有効になっている場合は，エラーを返却します。

詳細エラーコード取得機能は使用できません。なお，詳細エラーコード出力機能とは，エラーが発生した場合に，OpenTP1の呼び出し元に返却されるエラーコードを詳細化する機能です。

4.5.2　OpenTP1のサーバの機能との対応

TP1インバウンドアダプタは，「4.5.1　クライアントでサポートするOpenTP1の機能」で示した機能のうち，TP1インバウンドアダプタで使用できる機能を使用して送信されたRPCを受け付ける機能を備えています。ただし，OpenTP1のSPPおよびスケジュールサービスで提供されているすべての機能を同じように使用できるわけではありません。

TP1インバウンドアダプタを使用して実現できることの詳細については，「4.7　RPC通信機能」および「4.8　スケジュール機能」で説明します。

ここでは，TP1インバウンドアダプタとOpenTP1のサーバで動作するSPPの機能との対応を次の表に示します。また，機能差または代替機能がある場合にその概要についても説明します。なお，OpenTP1の機能の詳細については，マニュアル「OpenTP1 解説」およびマニュアル「OpenTP1 プログラム作成の手引」を参照してください。

表4‒3　OpenTP1のサーバの機能との対応

機能の分類

OpenTP1の機能

使用可否

機能差または代替機能の概要

受け付け可能なRPC形態

同期応答型RPC

○

機能差はありません。

非同期応答型RPC

×

使用できません。

非応答型RPC

×

連鎖RPC

×

トランザクショナルRPC

○

機能差はありません。

RPC機能

ネストを使用したコール

×

TP1インバウンドアダプタでは，別のOpenTP1のSPPへのネストコールは実行できません。

ただし，TP1/ClientなどのOpenTP1にOutboundでの接続をするための機能によって，ネストコールを実現できます。

また，リモートEJB呼び出しなど，アプリケーションサーバ間でネストの呼び出しは実現できます。

リカーシブコール

×

使用できません。

コールバック※

×

リモートAPI機能

リモートAPIの受け付け

×

サービス

サービスリトライ機能

×

サービス実行のタイマ監視

△

アプリケーションサーバ独自の方式でのタイマ監視を実行できます。詳細は，「4.8.4　サービス実行のタイムアウト」を参照してください。

サービスの並列処理

○

スレッドを使用してサービスを並列処理できます。

サービスグループ閉塞

×

使用できません。

サービス閉塞

×

サービスの同時実行数制御

○

アプリケーションサーバ独自の方式で同時実行数を制御できます。詳細は，「4.8.3　Message-driven Bean（サービス）の同時実行数の制御」を参照してください。

電文操作

電文の圧縮

×

常に非圧縮の状態で応答します。TP1インバウンドアダプタが圧縮された電文を受け取った場合は，エラーを返却します。

スケジュールサービス

サービス単位のスケジュールキュー

×

使用できません。

サービスグループ単位のスケジュールキュー

○

機能差はありません。

スケジュール閉塞

×

使用できません。

スケジュールプライオリティ制御

×

サービスのスケジュール方式

△

サービスのスケジュールは常にFIFO方式で制御されます。

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

△

アプリケーションサーバ独自の方式でスケジュールキューの滞留を監視できます。

負荷バランス

マルチサーバ負荷バランス

△

アプリケーションサーバでは，プロセスではなくスレッドを使用します。

また，アプリケーションサーバ独自の機能を使用して，負荷に応じてスレッド数を調整できます。詳細は，「4.8.3　Message-driven Bean（サービス）の同時実行数の制御」を参照してください。

マルチスケジューラ

×

使用できません。

ただし，アプリケーションサーバではマルチスレッドでリクエストを処理するため，マルチスケジューラ機能を使用しなくても一つのスケジュールサービスで複数のリクエストを処理できます。

ノード間負荷バランス

×

使用できません。

アプリケーションサーバでは，負荷情報は管理しません。

ノード間の振り分けには，ユーザサービスネットワーク定義による，ランダムなサービス要求だけが使用できます。

コネクション

コネクション確立/通信制御データのタイマ監視

△

アプリケーションサーバ独自の方式でのタイマ監視を実行できます。詳細は，「4.8.4　サービス実行のタイムアウト」を参照してください。

コネクション確立要求のキュー

△

アプリケーションサーバ独自の方式で管理するキューを使用できます。詳細は，「4.7　RPC通信機能」を参照してください。

一時クローズ処理機能

○

機能差はありません。

応答用TCP/IPコネクションの接続リトライ

○

使用できます。

詳細は，「4.7　RPC通信機能」を参照してください。

性能/障害調査

同期型dc_rpc_call関数のタイムアウト時のサーバ負荷軽減機能

×

アプリケーションサーバでは，クライアント側のタイムアウトに関係なく，サービス応答を実行します。

性能トレース取得機能

○

使用できます。

ただし，出力ファイルおよびファイルの内容は，アプリケーションサーバの性能解析トレースとしてのものになります。

OpenTP1デバッグ情報取得機能

×

OpenTP1独自のログは使用できません。

アプリケーションサーバでは，性能解析トレースまたはメッセージログを使用してデバッグを実行する必要があります。

RPCトレース

×

OpenTP1独自のログは使用できません。

アプリケーションサーバでは，通信トレースに相当するログは取得できません。ただし，クライアントのOpenTP1側のRPCトレースや，性能解析トレースを使用してリクエストの調査は実現できます。

統計情報取得

×

OpenTP1独自のログは使用できません。

ただし，アプリケーションサーバの稼働統計情報は取得できます。

監査ログ

×

OpenTP1独自の監査ログは使用できません。

ただし，アプリケーションサーバの監査ログは使用できます。

そのほか

MCFサービス

×

使用できません。

XATMIインタフェース(X/Open準拠)を使った通信

×

TXインタフェース(X/Open準拠)を使った通信

×

TxRPCインタフェース(X/Open準拠) を使った通信

×

OSI TPプロトコルを使った通信

×

（凡例）

○：使用できる

×：使用できない

△：使用できるが機能差がある

注※

dc_rpc_call関数で呼び出されたSPP内で，呼び出し元のサービスに対してee_rpc_call関数を発行する機能です。

4.6　コネクション管理機能

この節では，コネクション管理機能について説明します。

4.6.1　コネクション管理機能の概要

コネクション管理機能は，OpenTP1とTP1インバウンドアダプタ間のコネクションの接続，切断，およびプーリングを制御する機能です。コネクションを接続したままで，OpenTP1とTP1インバウンドアダプタの間で通信できます。そのため，コネクションの接続・切断に伴うボトルネックを削減し，通信効率が向上します。

コネクション管理機能が管理するコネクションは2種類あります。コネクション管理機能が管理するコネクションの種類，および役割について次の表に示します。

表4‒4　コネクション管理機能が管理するコネクションの種類および役割

コネクションの種類

コネクションの役割

RPC受信コネクション

OpenTP1からのRPC要求を受信します。

RPC送信コネクション

OpenTP1へのRPC応答を送信します。

また，トランザクション連携機能を使用している場合，OpenTP1との同期点処理の送受信をします。

なお，一時クローズ処理の送受信では，どちらのコネクションも使用します。一時クローズ処理については，「4.6.6　一時クローズ処理によるコネクション数の調整」を参照してください。

TP1インバウンドアダプタでのコネクション管理機能の概要と位置づけについて次の図に示します。

図4‒2　コネクション管理機能の位置づけ

OpenTP1からの接続要求をRPC待ち受けポートで受け付けます。受け付けた要求は，RPC受信監視スレッド内にあるRPC受信コネクションが受信します。RPC受信監視スレッドがRPC受信コネクションの受信を検知すると，RPC通信機能のリクエスト受け付けスレッドへリクエストを送信します。

コネクション管理機能は，次の要素で構成されています。

RPC待ち受けポート

OpenTP1からのRPC要求を受信する際にコネクションの接続要求を待ち受けるポートです。TP1インバウンドアダプタの開始時に開き，終了時に閉じます。

RPC監視スレッド

RPC受信コネクションに電文が送信されてきているかどうかを監視するスレッドです。RPC受信コネクションで電文の受信を検知すると，RPC通信機能のリクエスト受け付けスレッドに電文受信処理を渡します。

TP1インバウンドアダプタの開始時に作成し，終了時に消滅します。

同期点待ち受けポート

RPC応答を送信したRPC送信コネクションが切断済みの場合に，同期点待ち受けポートを利用してOpenTP1からRPC送信コネクションを接続します。

すでにRPC応答を送信したコネクションがある場合はそのコネクションを使って同期点処理を実行します。

TP1インバウンドアダプタの開始時に開き，終了時に閉じます。

同期点監視スレッド

RPC送信コネクションに電文が送信されてきているかどうかを監視するスレッドです。RPC送信コネクションでの電文の受信を検知すると，トランザクション連携機能の同期点電文送受信スレッドに電文受信処理を渡します。

TP1インバウンドアダプタの開始時に作成し，終了時に消滅します。

コネクション数調整スレッド

OpenTP1とのコネクションの接続数を監視し，一定のしきい値に達した場合に一時クローズ処理によって未使用のコネクションを切断するスレッドです。

コネクション数調整スレッドは，RPC受信コネクションとRPC送信コネクションをまとめて監視するため，TP1インバウンドアダプタごとに1スレッドが動作します。

コネクション数調整スレッドは，TP1インバウンドアダプタの開始時に作成し，終了時に消滅します。

一時クローズ処理については，「4.6.6　一時クローズ処理によるコネクション数の調整」を参照してください。

コネクション管理機能は，OpenTP1とアプリケーションサーバ間の通信で必要となる，コネクションに関する次の処理を制御します。

コネクション接続要求の受信

電文の受信

コネクション接続要求の送信

電文の送信

一時クローズ処理によるコネクション数の調整

コネクション接続要求または電文送信失敗時のリトライ

4.6.2　コネクション接続要求の受信

OpenTP1とTP1インバウンドアダプタ間で通信する際，接続済みのコネクションがあれば利用し，なければOpenTP1からTP1インバウンドアダプタへコネクション接続要求を送信してコネクションを接続します。

OpenTP1からのコネクションの接続要求は，RPC待ち受けポート，または同期点待ち受けポートで受け取ります。それぞれのポートが，OpenTP1からのコネクションの接続要求を受け取ったときの動作，およびコネクション接続要求に関する設定について説明します。

(1)　RPC待ち受けポートがコネクション接続要求を受信した際の動作

TP1インバウンドアダプタのRPC待ち受けポートが，コネクション接続要求を受信した際の動作を次に示します。

図4‒3　RPC待ち受けポートがコネクション接続要求を受信した際の動作

OpenTP1がRPC待ち受けポートに対してコネクション接続要求を送信します。コネクション接続要求は，TP1インバウンドアダプタが動作するOSのListenキュー（backlog）に格納されます。

TP1インバウンドアダプタのコネクション管理機能では，RPC監視スレッドがListenキューのコネクション接続要求を受信し，OpenTP1とのコネクションを確立します。

RPC監視スレッドは，確立したコネクションがOpenTP1から電文を受信しているかどうか監視を始めます。

(2)　同期点待ち受けポートがコネクション接続要求を受信した際の動作

TP1インバウンドアダプタの同期点待ち受けポートが，コネクション接続要求を受信した際の動作を次に示します。

図4‒4　同期点待ち受けポートがコネクション接続要求を受信した際の動作

OpenTP1の同期点処理は，RPC応答を受信したコネクションを使用します。このコネクションが切断されていた際に，TP1インバウンドアダプタの同期点待ち受けポートにOpenTP1がコネクション接続要求をします。

OpenTP1が，同期点待ち受けポートに対してコネクション接続要求を送信します。コネクション接続要求は，TP1インバウンドアダプタが動作するOSのListenキュー（backlog）に格納されます。

TP1インバウンドアダプタのコネクション管理機能では，同期点監視スレッドがListenキューのコネクション接続要求を受信し，OpenTP1とのコネクションを確立します。

同期点監視スレッドは，確立したコネクションがOpenTP1から電文を受信しているかどうか監視を始めます。

(3)　コネクション接続要求に関する設定

コネクション接続要求に関する設定のうち，Connector属性ファイルに指定する項目は次のとおりです。

Listenキューの長さ

backlog_countプロパティ

コネクション接続要求を受信するポート番号

scd_portプロパティ

trn_portプロパティ

コネクションの最大同時接続数

max_connectionsプロパティ

trn_max_connectionsプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

コネクション接続要求に関する設定のうち，IPアドレス（バインド先アドレス）については，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）のejbserver.jca.adapter.tp1.bind_hostプロパティに設定します。

バインド先アドレスを指定すると，TP1インバウンドアダプタが動作するホストが複数の物理ネットワークインタフェースを持つ場合に，特定のIPアドレスだけを使用するように設定できます。この設定をしない場合は，システムによって自動的に選択されたローカルアドレスが使用されます。指定方法の詳細については，「4.12.1　J2EEサーバの設定」を参照してください。

(4)　コネクション接続要求に失敗する原因およびOpenTP1での動作

TP1インバウンドアダプタが次に示す条件に当てはまる場合，OpenTP1からのコネクション接続要求に失敗します。コネクション接続要求に失敗する原因，およびOpenTP1での動作について説明します。

表4‒5　コネクション接続要求に失敗する原因およびOpenTP1での動作

コネクション接続要求に失敗する原因

OpenTP1での動作

TP1インバウンドアダプタが起動していない

TP1インバウンドアダプタで通信障害が発生している

OpenTP1のdc_rpc_call関数，または同期点処理がエラーを返します。※

OSのListenキューにコネクション接続要求が上限まで滞留している状態で，OpenTP1が新たなコネクション接続要求を送信した（Listenキューあふれ）

新たなコネクション接続要求は，OSのListenキューによって拒否されます。OpenTP1のdc_rpc_call関数，または同期点処理がエラーを返します。※

コネクションの接続数がコネクション管理機能の最大同時接続数の設定値に達している

コネクション接続要求は，コネクションの接続数が最大同時接続数未満になるまでOSのListenキューに滞留します。OpenTP1のdc_rpc_call関数，または同期点処理は最大応答待ち時間に達してからエラーを返します。※

注※

エラーコードについては，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

4.6.3　電文の受信

OpenTP1からの接続要求を受け，TP1インバウンドアダプタで電文を受信します。

TP1インバウンドアダプタがOpenTP1から受信する電文は，RPC要求，および同期点処理です。それぞれの電文を受信したときの動作について説明します。

(1)　RPC要求受信時の動作

TP1インバウンドアダプタがRPC要求を受信したときの動作を次に示します。

図4‒5　RPC要求受信時の動作

コネクション管理機能のRPC監視スレッドは，電文受信中でないRPC受信コネクションがOpenTP1からの電文を受信していないかを監視します。

RPC監視スレッドがOpenTP1からの電文の受信を検知します。RPC監視スレッドは該当するコネクションで電文の受信が開始したことをRPC通信機能に通知します。RPC監視スレッドは，ほかのRPC受信コネクションがOpenTP1からの電文を受信していないかどうか監視を続けます。RPC通信機能の詳細は，「4.7　RPC通信機能」を参照してください。

RPC通信機能のリクエスト受け付けスレッドは，電文の受信開始が通知されたコネクションから，順次OpenTP1からの電文を受信します。

リクエスト受け付けスレッドは，OpenTP1からの電文の受信を完了すると，該当するコネクションでの受信が完了したことをコネクション管理機能に通知します。これによって，RPC受信監視スレッドは該当するコネクションで次の電文を受信していないかどうかの監視を始めます。

(2)　同期点処理の受信時の動作

TP1インバウンドアダプタが同期点処理を受信したときの動作を次に示します。

図4‒6　同期点処理の受信時の動作

コネクション管理機能の同期点監視スレッドは，電文受信中でないRPC送信コネクションがOpenTP1からの電文を受信していないかどうか監視します。

同期点監視スレッドがOpenTP1からの電文の受信を検知すると，同期点監視スレッドは該当するコネクションで電文の受信が開始したことをトランザクション管理機能に通知します。同期点監視スレッドは，ほかのRPC送信コネクションがOpenTP1からの電文を受信していないかどうかの監視を続けます。詳細は，「4.9　トランザクション連携機能」を参照してください。

トランザクション連携機能の同期点電文送受信スレッドは，電文の受信開始が通知されたコネクションから，順次OpenTP1からの電文を読み込みます。

同期点電文送受信スレッドは，OpenTP1からの電文の受信を完了すると，使用しているコネクションでの受信が完了したことをコネクション管理機能に通知します。これによって，同期点監視スレッドは該当するコネクションで次の電文を受信していないかどうかの監視を始めます。

(3)　電文の受信に関する設定

電文の受信に関する設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

電文受信時のTCP/IPのバッファサイズ

receive_buffer_sizeプロパティ

受信タイムアウト時間

tcp_receive_timeoutプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

4.6.4　コネクション接続要求の送信

TP1インバウンドアダプタがOpenTP1と通信する際に，送信先のOpenTP1と接続済みのコネクションがある場合は，接続済みのコネクションを利用します。接続済みのコネクションがない場合は，コネクション接続要求を送信してコネクションを接続します。

TP1インバウンドアダプタからOpenTP1へのコネクションの接続要求には，RPC応答，および同期点処理の2種類があります。それぞれのコネクション接続要求を送信したときの動作について説明します。

(1)　RPC応答および同期点処理でのコネクション接続要求送信時の動作

RPC応答および同期点処理でのコネクション接続要求送信時の動作について，次の図に示します。

図4‒7　RPC応答および同期点処理でのコネクション接続要求送信時の動作

それぞれの動作の流れについて，(a)および(b)で説明します。

(a)　RPC応答でのコネクション接続要求送信時の動作

RPC応答でのコネクション接続要求は，RPC通信機能のリクエスト受け付けスレッド，スケジュール機能のMessage-driven Bean（サービス）呼び出しスレッド，およびMessage-driven Bean（サービス）の停止処理を実行するスレッドが送信します。コネクション接続要求をOpenTP1に送信する際の流れを次に示します。

TP1インバウンドアダプタからOpenTP1へコネクション接続要求を送信します。コネクション接続要求は，OpenTP1が動作するOSのListenキュー（backlog）に格納されます。

OpenTP1がListenキューのコネクション接続要求を受信し，TP1インバウンドアダプタとのコネクションを確立します。

コネクションが確立したら，同期点監視スレッドは，OpenTP1への電文の送信と並行してOpenTP1からの電文を受信できるようにRPC送信コネクションがOpenTP1から電文を受信しているかどうかの監視を始めます。

(b)　同期点処理でのコネクション接続要求送信時の動作

同期点処理でのコネクション接続要求は，トランザクション連携機能の同期点電文送受信スレッドが送信します。コネクション接続要求をOpenTP1に送信する際の流れを次に示します。

TP1インバウンドアダプタからOpenTP1へコネクション接続要求を送信します。コネクション接続要求は，OpenTP1が動作するOSのListenキュー（backlog）に格納されます。

OpenTP1が，Listenキューのコネクション接続要求を受信し，TP1インバウンドアダプタとのコネクションを確立します。

コネクションが確立したら，同期点監視スレッドは，OpenTP1への電文の送信と並行してOpenTP1からの電文を受信できるように，RPC送信コネクションがOpenTP1から電文を受信しているかどうかの監視を始めます。

(2)　コネクション接続要求の送信に関する設定

コネクション接続要求の送信に関する設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

コネクションの最大同時接続数

max_connectionsプロパティ

trn_max_connectionsプロパティ

コネクション接続失敗時のリトライ

send_retry_countプロパティ

send_retry_intervalプロパティ

コネクション接続時のタイムアウト時間

connection_timeoutプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

(3)　コネクション接続要求に失敗する原因およびTP1インバウンドアダプタでの動作

OpenTP1が，TP1インバウンドアダプタからのコネクション接続要求の受信に失敗する原因，およびTP1インバウンドアダプタでの動作を次に示します。

表4‒6　コネクション接続要求に失敗する原因およびTP1インバウンドアダプタでの動作

コネクション接続要求に失敗する原因

TP1インバウンドアダプタでの動作

OpenTP1に障害が発生している

通信障害が発生している

TP1インバウンドアダプタは，コネクション接続要求をリトライします。※1

リトライしてもコネクションを接続できなかった場合は，エラーメッセージ（KDJE58400-E）を出力して未送信の電文を破棄します。

OSのListenキューにコネクション接続要求が上限まで滞留している状態で，TP1インバウンドアダプタが新たなコネクション接続要求を送信した（Listenキューあふれ）

TCP送信コネクション接続タイムアウトが発生した

TP1インバウンドアダプタは，エラーメッセージ（KDJE58400-E）を出力して未送信の電文を破棄します。

コネクションの接続数が最大同時接続数に達している

TP1インバウンドアダプタは，コネクションの接続数が最大同時接続数未満になるまでコネクション接続要求の送信を待機します。※2

注※1

コネクション接続要求のリトライについては，「4.12.2　リソースアダプタの設定」を参照してください。

注※2

どのコネクションからも一時クローズ処理の応答が返ってこない場合に，コネクションを切断できなかったとき，指定した一時クローズ応答の待ち時間が経過すると，TP1インバウンドアダプタは一時クローズ要求の応答を待つコネクションを強制的に切断します。このため，コネクション接続要求の送信を待ち続けることはありません。

4.6.5　電文の送信

TP1インバウンドアダプタがOpenTP1へ電文を送信する際の動作を次に示します。

図4‒8　電文の送信する流れ

(1)　RPC応答と同期点処理送信時の動作

RPC応答は，RPC通信機能のリクエスト受け付けスレッド，受信タイマ監視スレッド，スケジュール機能のMessage-driven Bean（サービス）呼び出しスレッド，およびMessage-driven Bean（サービス）の停止処理を実行するスレッドが送信します。同期点処理は，トランザクション連携機能の同期点電文送受信スレッドが送信します。

次にRPC応答と同期点処理をOpenTP1に送信するときの流れを示します。

OpenTP1へ電文を送信する際，コネクション管理機能から送信先のOpenTP1とのコネクションを取得します。

コネクションを取得したスレッドは，取得したコネクションを使用してOpenTP1へ電文を送信します。

(2)　電文の送信時の設定

電文の送信時の設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

電文送信時のTCP/IPのバッファサイズ

send_buffer_sizeプロパティ

送信リトライ

send_retry_countプロパティ

send_retry_intervalプロパティ

送信タイムアウト時間

tcp_send_timeoutプロパティ

TCP_NODELAYオプション

ipc_tcpnodelayプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

4.6.6　一時クローズ処理によるコネクション数の調整

OpenTP1とTP1インバウンドアダプタでは，コネクション接続時のオーバーヘッドを削減するために，一度接続したコネクションを切断しないで次回の通信で再利用します。そのため，コネクション管理機能の最大同時接続数の設定よりも多くの接続を受け付けるシステムでは，コネクションの接続数がすぐに最大同時接続数に達してしまいます。

これを防ぐために，コネクションの接続数が一定のしきい値に達したところで未使用のコネクションを切断する機能（一時クローズ処理）を使用します。

一時クローズ処理によってコネクション数を調整することで，コネクションを枯渇させることなく，効率良くコネクションを管理できます。

一時クローズ処理は，OpenTP1側から実行する場合と，TP1インバウンドアダプタ側から実行する場合の2種類があります。どちらの場合も，接続先に一時クローズ処理要求を送信して，接続先から一時クローズ処理応答を受信したタイミングでコネクションを切断します。一時クローズ処理要求の送信と一時クローズ処理の応答の受信は，非同期に処理されます。

なお，OpenTP1とTP1インバウンドアダプタ間のコネクションが一時クローズ処理中であっても，新しいRPC要求を受け付けることができます。また，新たなコネクションを接続することでRPC応答を送信することができるため，一時クローズ処理によってOpenTP1やTP1インバウンドアダプタでの処理がエラーになることはありません。

(1)　一時クローズ処理対象とするコネクション数の指定

処理開始のしきい値には，TP1インバウンドアダプタが一時クローズ処理を開始するコネクション数の割合をパーセンテージで指定します。指定したしきい値に応じて，コネクションの種類ごとに次の条件で一時クローズ処理を開始します。

RPC受信コネクションの一時クローズ処理開始の条件

RPC受信コネクション数 ≧

RPC受信コネクションの最大同時接続数 ×

RPC受信コネクションの一時クローズ処理開始のしきい値 ／ 100

RPC送信コネクションの一時クローズ処理開始の条件

RPC送信コネクション数 ≧

RPC送信コネクションの最大同時接続数 ×

RPC送信コネクションの一時クローズ処理開始のしきい値 ／ 100

(2)　一時クローズ処理の対象外とするコネクション数の指定

一時クローズ処理の対象外とするコネクション数の割合をパーセンテージで指定します。

RPC受信コネクションの一時クローズ処理非対象コネクション数の算出

RPC受信コネクションの一時クローズ処理非対象コネクション数＝

RPC受信コネクションの最大同時接続数 ×

RPC受信コネクションの一時クローズ処理非対象とするコネクション数の割合／100

RPC送信コネクションの一時クローズ処理非対象コネクション数の算出

RPC送信コネクションの一時クローズ処理非対象コネクション数＝

RPC送信コネクションの最大同時接続数 ×

RPC送信コネクションの一時クローズ処理非対象とするコネクション数の割合／100

(3)　コネクション数が最大に達した際の一時クローズ処理の応答待ち時間の指定

一時クローズ処理では，コネクションを接続したOpenTP1とTP1インバウンドアダプタ間で，どちらかから一時クローズ処理の要求を送信したあと，その応答を受信してからコネクションを切断します。一時クローズ処理の応答を受信するまでコネクションを切断することはできません。

一時クローズ処理要求後にどのコネクションからも応答が返ってこなければ，コネクション数に空きができないため，新たなコネクションを接続することができなくなります。これを防ぐため，TP1インバウンド連携機能では，一時クローズ応答の待ち時間を指定することで，コネクション数が最大に達してからコネクション数に空きができるまでの時間を監視します。指定した一時クローズ応答の待ち時間を経過してもコネクション数が最大値のままの場合，エラーメッセージを出力してコネクションを切断します。

RPC受信コネクション，および送信コネクションでのコネクション数の監視について説明します。

(a)　RPC受信コネクションでのコネクション数の監視

RPC受信コネクションが最大RPC受信コネクション数に達してから，一時クローズ処理によってコネクション数に空きができるまでの時間を監視します。

指定した一時クローズ応答の待ち時間を経過しても，コネクション数が最大RPC受信コネクション数のままの場合は，エラーメッセージ（KDJE58501-E）を出力し，RPC受信コネクションをすべて切断します。

(b)　RPC送信コネクションでのコネクション数の監視

RPC受信コネクション同様に，RPC送信コネクションが最大RPC送信コネクション数に達してから，一時クローズ処理によってコネクション数に空きができるまでの時間を監視します。

指定した一時クローズ応答の待ち時間を経過しても，コネクション数が最大RPC送信コネクション数のままの場合は，エラーメッセージ（KDJE58501-E）を出力し，RPC送信コネクションをすべて切断します。

(4)　一時クローズ処理に関する設定

一時クローズ処理に関する設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

RPC受信コネクションの一時クローズ処理

rpc_sockctl_highwaterプロパティ

rpc_sockctl_lowwaterプロパティ

RPC送信コネクションの一時クローズ処理

trn_sockctl_highwaterプロパティ

trn_sockctl_lowwaterプロパティ

一時クローズ応答の待ち時間

ipc_sockctl_watchtimeプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

4.6.7　コネクション接続要求または電文送信失敗時のリトライ

コネクション管理機能では，OpenTP1へのコネクション接続要求に失敗した場合，または電文送信に失敗した場合に，リトライします。コネクション接続要求に失敗した場合は，再度コネクション接続要求を試みます。電文送信に失敗した場合は，コネクションを切断して，新たなコネクションを接続してから再度送信を試みます。

ただし，コネクション接続要求時または電文送信時にタイムアウトが発生した場合は，リトライしません。コネクションのタイムアウトについては「4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定」を参照してください。

(1)　リトライ時に出力されるメッセージ

コネクション管理機能では，初回のリトライ時にだけ警告メッセージを出力します。リトライ時に出力する警告メッセージについて次に示します。

表4‒7　リトライ時に出力する警告メッセージ

リトライの種別

メッセージ

コネクション接続要求のリトライ

KDJE58402-W

電文送信のリトライ

KDJE58403-W

コネクション接続要求が設定したリトライ回数分失敗した場合，未送信の電文を破棄します。

また，電文送信のリトライが設定したリトライ回数分失敗した場合，コネクションを切断して未送信の電文を破棄します。これらの場合，最後のリトライの種別に応じて次のエラーメッセージを出力します。

表4‒8　リトライ回数までリトライしても失敗した場合のエラーメッセージ

リトライの種別

メッセージ

コネクション接続要求のリトライ

KDJE58400-E

電文送信のリトライ

KDJE58401-E

(2)　コネクション接続要求または電文送信失敗時のリトライに関する設定

コネクション接続要求または電文送信失敗時のリトライの設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

コネクション接続要求または電文送信失敗時のリトライ

send_retry_countプロパティ

send_retry_intervalプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

4.7　RPC通信機能

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

4.7.1　RPC通信機能の概要

RPC通信機能は，OpenTP1から受信したRPC要求を解析・組み立てし，OpenTP1に送信するRPC応答を生成・分割する機能です。

TP1インバウンドアダプタでのRPC通信機能の位置づけを次の図に示します。

図4‒9　RPC通信機能の位置づけ

RPC通信機能は，次の要素で構成されます。

リクエスト受け付けスレッド

OpenTP1からのRPC要求を受け付けるスレッドです。

TP1インバウンドアダプタの開始時に最大同時接続数分だけ作成し，TP1インバウンドアダプタ終了時に消滅します。最大同時接続数の設定については，「4.7.5　最大同時RPC要求受け付け数および受信タイムアウト」で説明します。

受信タイマ監視スレッド

RPC要求の受信タイムアウトを監視するスレッドです。TP1インバウンドアダプタごとに1スレッドが動作します。

受信タイマ監視スレッドは，TP1インバウンドアダプタの開始時に作成し，終了時に消滅します。

RPC通信機能では，OpenTP1とアプリケーションサーバ間でRPC通信によって電文を送受信するための次の処理を制御します。

RPC要求の受信と組み立て

RPC要求のチェック

RPC応答の生成から送信まで

最大同時RPC要求受け付け数および受信タイムアウト

OpenTP1では，電文を分割して送受信します。このため，TP1インバウンドアダプタでは，RPC通信の際に，受信した電文の組み立ておよび送信する電文の分割処理を実行します。

なお，RPC要求の受信とRPC応答の送信には，別のコネクションを使用します。

4.7.2　RPC要求の受信と組み立て

コネクションの確立後，OpenTP1からのRPC要求が，32キロバイトずつに分割された電文として送信されます。

RPC通信機能のリクエスト受け付けスレッドは，コネクション管理機能によって割り当てられたコネクションを使用して，分割された電文を順次受信し，一つの要求電文として組み立てます。

電文の受信と組み立ての流れを次の図に示します。

図4‒10　電文の受信と組み立ての流れ

TP1インバウンドアダプタでは，分割された電文を受信すると，データチェックを実行します。データチェックで正常と判定した電文について，組み立てを実行します。組み立て後，次の電文を受信します。最後の電文の場合は，最後のデータチェックを実行し，電文受信を終了します。なお，データチェックで電文の異常を検知した場合は，エラー応答を送信します。

要求電文の受信中に，ネットワーク障害やOpenTP1の障害などによってコネクションが切断された場合，TP1インバウンドアダプタはエラーメッセージ（KDJE58354-E）を出力して電文の受信処理を中断します。なお，OpenTP1では，コネクションの切断を検知すると，再度コネクションを確立して，送信の途中だった電文の送信をリトライします。TP1インバウンドアダプタでは，OpenTP1からのリトライに備え，受信済みの電文を電文組み立てリストに保持します。電文組み立てリストは，最大同時接続数分保持できます。このリストは，残りの電文をすべて受信し終えるか，またはRPC要求の受信タイムアウトが発生するまで保持されます。

コネクション障害が頻発することによって電文組み立てリストが蓄積して電文の組み立てができなくなると，新たなRPC要求の受信ができなくなります。この場合，エラーメッセージ（KDJE58359-E）が出力されます。また，呼び出し元のdc_rpc_call関数にはRPCエラー（トランザクショナルRPCでない場合はDCRPCER_NO_BUFS(-304)，トランザクショナルRPCの場合はDCRPCER_NET_DOWN(-323)）が返されます。

電文組み立てリストが不足した状態は，OpenTP1から残りの電文がすべて再送されるか，またはRPC要求の受信タイムアウトが発生すると，解消します。

RPC要求の受信時のエラー，および電文組み立てリストが不足した場合のエラーについては，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

また，最大同時接続数，および要求電文の受信処理のタイムアウトの設定は，Connector属性ファイルに指定します。指定する項目は次のとおりです。

最大同時接続数

max_connectionsプロパティ

要求電文の受信処理のタイムアウト

rpc_receive_timeoutプロパティ

指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

4.7.3　RPC要求のチェック

RPC通信機能では，受信した電文の形式と内容をチェックします。チェック内容および不正を検知した場合の動作を次に示します。

電文形式のチェック

受信したRPC要求がOpenTP1から送信された電文かどうかをチェックします。

不正を検知した場合は，エラーメッセージ（KDJE58355-E）を出力して，コネクションを切断します。応答送信はしません。エラーの詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

TP1インバウンドアダプタで使用できない機能を使用していないかのチェック

TP1インバウンドアダプタで使用できないOpenTP1の機能を使用していないかどうかをチェックします。TP1インバウンドアダプタで使用できる機能については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

不正を検知した場合は，エラーメッセージ（KDJE58356-E）を出力して，コネクションを切断します。また，呼び出し元のdc_rpc_call関数にRPCエラーを応答します。エラーの詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

dc_rpc_call関数の引数チェック

呼び出し元のdc_rpc_call関数の引数が適切に指定されているかどうかをチェックします。

不正を検知した場合は，エラーメッセージを出力して，コネクションを切断します。また，呼び出し元のdc_rpc_call関数にRPCエラーを応答します。

引数チェックでチェックされる内容，不正検知時に出力されるエラーメッセージ，およびRPCエラー応答について次の表に示します。

表4‒9　dc_rpc_call関数の引数チェック

引数

チェック内容

不正検知時のエラーメッセージ

不正検知時のRPCエラー応答

group

引数に指定したサービスグループ名が，TP1インバウンドアダプタのサービスグループ名（Connector属性ファイルに指定したservice_groupプロパティ）と一致しているか。

KDJE58357-E

DCRPCER_SERVICE_NOT_UP(-314)

service

引数に指定したサービス名が，TP1インバウンドアダプタが呼び出すサービス名（Message-driven Bean（サービス）のActivationSpecのserviceプロパティ）の中に存在するか。

KDJE58362-E

DCRPCER_NO_SUCH_SERVICE(-311)

flags

引数に指定したRPC形態が，TP1インバウンドアダプタで利用できる次のどちらかの形態か。

DCNOFLAGS（同期応答型RPC）

DCNOFLAGS|DCRPC_TPNOTRAN（同期応答型，かつトランザクションを引き継がないRPC）

KDJE58356-E

DCRPCER_TIMED_OUT(-307)

エラーの詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

4.7.4　RPC応答の生成から送信まで

ここでは，RPC応答の生成から送信までの処理について説明します。

(1)　応答電文生成

RPC通信機能が呼び出し元に送信する電文を生成します。

(2)　応答電文の分割と送信

RPC通信機能では，一つのRPC応答電文を32キロバイトごとに分割して順次送信します。

送信にはコネクション管理機能のコネクションを使用します。応答電文の送信処理には，リトライやタイムアウトを設定できます。設定方法については，「4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定」を参照してください。

4.7.5　最大同時RPC要求受け付け数および受信タイムアウト

最大同時RPC要求受け付け数および受信タイムアウトを指定する項目は次のとおりです。

OpenTP1から受信したRPC要求の最大同時RPC要求受け付け数

rpc_max_thread_countプロパティ

Connector属性ファイルの指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

RPC要求受信のタイムアウト時間

詳細については，「4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定」を参照してください。

4.8　スケジュール機能

この節では，スケジュール機能について説明します。

4.8.1　スケジュール機能の概要

スケジュール機能は，RPC通信機能によって受信したRPC要求電文をJ2EEサーバで効率良く処理するための機能です。TP1/Server Baseのスケジュールサービスの一部の機能に相当します。

TP1インバウンドアダプタでのスケジュール機能の位置づけを次の図に示します。

図4‒11　スケジュール通信機能の位置づけ

スケジュール機能は，次の要素で構成されます。

スケジュールキュー

RPC通信機能によって受信したRPC要求を保持するキューです。RPC要求は，FIFO方式で保持します。

スケジュールキューは，Message-driven Bean（サービス）開始時にMessage-driven Bean（サービス）ごとに一つ作成され，Message-driven Bean（サービス）の終了時に削除されます。

Message-driven Bean（サービス）実行制御スレッド

スケジュールキューからRPC要求を取り出して，空いているMessage-driven Bean（サービス）呼び出しスレッドに処理を委譲します。

Message-driven Bean（サービス）実行制御スレッドは，Message-driven Bean（サービス）開始時に，Message-driven Bean（サービス）ごとに一つ作成され，Message-driven Bean（サービス）の終了時に削除されます。

Message-driven Bean（サービス）呼び出しスレッド

Message-driven Bean（サービス）を実行するスレッドです。Connector 1.5仕様に準拠したWorkManagerによって管理されます。

Message-driven Bean（サービス）実行制御スレッドがRPC要求をスケジュールキューから取り出して受け付けたときにWorkManagerによって割り当てられます。

RPC応答後は，Message-driven Bean（サービス）呼び出しスレッドはWorkManagerに返されます。WorkManagerが管理するスレッドは，TP1インバウンドアダプタを開始したときに生成され，TP1インバウンドアダプタ終了時に削除されます。

スレッドの詳細については，「4.8.3　Message-driven Bean（サービス）の同時実行数の制御」を参照してください。

Message-driven Bean（サービス）

業務処理を実行するサービスとなるMessage-driven Beanです。OpenTP1のSPPに相当します。

スケジュール機能の処理の流れを次に示します。

Message-driven Bean（サービス）を開始した時に，Message-driven Bean単位にスケジュールキューおよびMessage-driven Bean（サービス）実行制御スレッドが作成されます。

RPC通信機能でのRPC要求受信後，受信したRPC要求はスケジュールキューに格納されます。

スケジュールキューに格納されたRPC要求がMessage-driven Bean（サービス）実行制御スレッドによって取り出されます。このタイミングで，Connector 1.5仕様に準拠したWorkManagerによって，Message-driven Bean（サービス）呼び出しスレッドが割り当てられます。

Message-driven Bean（サービス）実行制御スレッドがMessage-driven Bean（サービス）呼び出しスレッドにRPC要求を委譲します。

Message-driven Bean（サービス）呼び出しスレッドによって，Message-driven Beanが実行されます。

なお，TP1インバウンドアダプタでは，OpenTP1の機能であるスケジュールの優先順位（ユーザサービス定義のschedule_priority）を指定したRPC要求を受信した場合も，優先順位は無視します。優先順位を指定したRPC要求を受信した場合も，優先順序が設定されていないRPC要求と同じように扱い，受信した順番で処理を実行します。

スケジュール機能では，これらの処理をする際に，次の項目を制御できます。

スケジュールキューの制御

Message-driven Bean（サービス）の同時実行数の制御

サービス実行のタイムアウト

4.8.2　スケジュールキューの制御

スケジュールキューの制御では，スケジュールキューの長さを設定できます。また，スケジュールキューに滞留しているRPC要求の数がキュー長に近づいていることを検知するために，スケジュールキューを監視できます。

(1)　スケジュールキューの長さの設定

スケジュールキューの長さは，Message-driven Bean（サービス）ごとに設定できます。

設定は，Message-driven BeanのActivationSpecのqueue_max_lengthプロパティに設定します。設定を省略した場合は，スケジュールキューの長さは100になります。ActivationSpecの設定については，「4.10.5　ejb-jar.xmlの定義」を参照してください。

スケジュールキューに滞留しているRPC要求の数がキュー長に達している状態で新たにRPC要求が送信されると，スケジュール機能では，エラーメッセージ（KDJE58360-E）を出力します。呼び出し元のdc_rpc_call関数にはRPCエラー(DCRPCER_NO_BUFS(-304))が返されます。エラーの詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

スケジュールキューのキュー長をRPC要求数に対して小さい値を設定していると，キューあふれによってRPCエラーが発生するおそれがあります。そのため，RPC要求に正常に応答するためには，OpenTP1から同時に送信されるRPC要求数と同程度のキュー長を設定してください。ただし，スケジュールキューに保持するRPC要求はメモリ上に保持するため，多くのRPC要求がスケジュールキューに滞留し，メモリ使用量が増加するおそれがあります。TP1インバウンドアダプタのメモリ使用量については，「4.4　TP1インバウンド連携機能で使用するメモリの見積もり」を参照してください。

(2)　スケジュールキューの監視

スケジュール機能では，Message-driven Bean（サービス）ごとにしきい値を設定してスケジュールキューを監視することで，滞留しているRPC要求の数がキュー長に近づいていることを事前に検知できます。しきい値を設定しておくと，スケジュールキューに滞留しているRPC要求の数がしきい値を超えたときに，警告メッセージ（KDJE58361-W）が出力されます。なお，スケジュールキューの監視は，RPC通信機能のリクエスト受け付けスレッドによってRPC要求がスケジュールキューに登録されたタイミングで実行されます。

また，一度しきい値を超えたことを示すメッセージが出力されてから，再度メッセージを出力するまでの間隔（警告メッセージ抑止時間）も設定できます。

これらの設定は，Message-driven BeanのActivationSpecの次のプロパティに指定します。

stay_watch_queue_rateプロパティ

滞留数のしきい値を指定します。監視しない場合は0を指定します。

stay_watch_check_intervalプロパティ

警告メッセージの出力抑止時間を指定します。

ActivationSpecの設定については，「4.10.5　ejb-jar.xmlの定義」を参照してください。

4.8.3　Message-driven Bean（サービス）の同時実行数の制御

スケジュールキューに滞留しているRPC要求は，Message-driven Bean（サービス）実行制御スレッドによって順次取り出され，Connector 1.5仕様に準拠したWorkManagerによって管理されているMessage-driven Bean（サービス）呼び出しスレッドに委譲されます。RPC要求を委譲されたMessage-driven Bean（サービス）呼び出しスレッドによって，Message-driven Bean（サービス）が実行されます。

スケジュール機能では，WorkManagerのMessage-driven Bean（サービス）呼び出しスレッド数と，Message-driven Bean（サービス）のインスタンスプール数によって，同時に実行するRPC要求の数を制御します。

Message-driven Bean同時実行数の制御の概要を次の図に示します。

図4‒12　Message-driven Bean同時実行数の制御の概要

Message-driven Bean（サービス）の同時実行数を制御するプロパティについて，次の表に示します。これらの値を適切に設定しないと，正しく同時実行数を制御できません。

表4‒10　Message-driven Bean（サービス）の同時実行数を制御するプロパティ

設定項目

設定対象

（設定個所）

指定するタグ名

指定する内容

Message-driven Bean（サービス）の同時実行数

TP1インバウンドアダプタ

(Connector属性ファイル)

<hitachi-connector-property>下の<resourceadapter-runtime><property>の<MaxTPoolSize>

Message-driven Bean（サービス）呼び出しスレッドの最大数

<hitachi-connector-property>下の<resourceadapter-runtime><property>の<MinTPoolSize>

Message-driven Bean（サービス）呼び出しスレッドの最小数

Message-driven Bean（サービス）のインスタンスプール数

Message-driven Bean

(cosminexus.xml

または

MessageDrivenBean属性ファイル)

<pooled-instance><maximum>

Message-driven Bean（サービス）のインスタンスプール数の最大数

<pooled-instance><minimum>

Message-driven Bean（サービス）のインスタンスプール数の最小数（ただし，指定しても常に1とみなされます）

TP1インバウンドアダプタ単位の最大同時実行数は，WorkManagerのスレッドプール（MaxTPoolSize）に指定します。また，個々のMessage-driven Bean（サービス）単位の最大同時実行数は，Message-driven Beanのインスタンスプール（maximum）で指定します。

これらの最大値は，次の関係になるように指定してください。

Message-driven Bean（サービス）呼び出しスレッドの最大数（MaxTPoolSize）≧
それぞれのMessage-driven Bean（サービス）のインスタンスプール（maximum）の総和

注

指定した値がこの式の関係になっていない場合，Message-driven Bean（サービス）開始時に警告メッセージ（KDJE58452-W）が出力されます。

Message-driven Bean（サービス）実行制御スレッドでは，Message-driven Bean（サービス）呼び出しスレッド数がMessage-driven Bean（サービス）のインスタンスプールの最大値（maximum）の総和を超えることがないよう，Message-driven Bean（サービス）呼び出しスレッドの実行数を制御します。MaxTPoolSizeとmaximumの関係が上記の式の関係になっていない場合，RPC要求時にMessage-driven Bean（サービス）呼び出しスレッドまたはMessage-driven Bean（サービス）のインスタンスが不足することがあります。この場合，RPC要求はスケジュールキューに滞留した状態になります。

4.8.4　サービス実行のタイムアウト

Message-driven Bean（サービス）の実行にタイムアウトを設定することで，業務処理で無限ループやデッドロックが発生した場合などに，タイムアウトによって業務を強制的に停止できます。タイムアウトによる業務処理の強制停止には，アプリケーションサーバのメソッドキャンセル機能を使用します。

TP1インバウンドアダプタでのサービス実行のタイムアウトの概要を次の図に示します。

図4‒13　TP1インバウンドアダプタでのサービス実行のタイムアウト

Message-driven Bean（サービス）の実行時間を監視することによって，障害が発生して応答がない場合，業務を強制停止して，Message-driven Bean（サービス）呼び出しスレッドでタイムアウトを検知できます。タイムアウトを検知したMessage-driven Bean（サービス）呼び出しスレッドは，OpenTP1にRPCエラー応答を返します。

なお，Message-driven Beanでの処理の実行状態によっては，メソッドキャンセル機能で強制停止を実行できないことがあります。この場合，業務処理の終了後，TP1インバウンドアダプタは呼び出し元のOpenTP1にRPC応答送信を試みます。呼び出し元がRPC最大応答待ち時間の経過によってすでに応答を待っていなかった場合には，応答送信のコネクション確立に失敗するため，エラーメッセージ（KDJE58400-E）が出力されます。

タイムアウトの詳細については，「4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定」を参照してください。

4.9　トランザクション連携機能

この節では，トランザクション連携機能について説明します。

4.9.1　トランザクション連携機能の概要

トランザクション連携機能は，OpenTP1のSUPが開始したトランザクションにアプリケーションサーバのMessage-driven Bean（サービス）が開始したトランザクションを参加させる機能です。これによって，OpenTP1のSUPでのリソース更新と，アプリケーションサーバのMessage-driven Bean（サービス）でのリソース更新の同期を取り，データの整合性を保てます。

TP1インバウンドアダプタでのトランザクション連携機能の位置づけを次の図に示します。

図4‒14　トランザクション連携機能の位置づけ

同期点監視スレッドが，OpenTP1からの同期点処理を受け付けます。RPC送信コネクションは，トランザクション連携機能の同期点電文送受信スレッドに対して，リクエストを送信し，処理を同期します。

トランザクション通信機能は，次の要素で構成されます。

同期点電文送受信スレッド

OpenTP1からの同期点処理（プリペア・コミット・ロールバック）を受信して，トランザクションマネージャ（JTA・OTS）に対してトランザクションの同期点処理を委譲するスレッドです。このスレッドは，TP1インバウンドアダプタの開始時に最大同時同期点処理数分作成し，終了時に消滅します。最大同時同期点処理数の指定方法については「4.12.2　リソースアダプタの設定」を参照してください。

トランザクション連携機能では，次の処理を制御します。

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

グローバルトランザクションへのMessage-driven Bean（サービス）の参加条件

トランザクショナルRPCの受信と応答

同期点処理

同期点処理の最適化

トランザクション連携機能の設定

トランザクション障害発生時の対処

4.9.2　グローバルトランザクションの範囲

トランザクション連携機能で実現できるグローバルトランザクションの範囲について説明します。

グローバルトランザクションとは，OpenTP1のアプリケーションプログラムで開始したトランザクションと，そのトランザクションに参加するRPC通信先のOpenTP1またはアプリケーションサーバのトランザクションの集合であり，データの整合性を確保する範囲となります。

トランザクション連携機能でのグローバルトランザクションの範囲を次の図に示します。

図4‒15　トランザクション連携機能でのグローバルトランザクションの範囲

この図の中で示しているすべてのリソースに対して，データの整合性が確保されます。

4.9.3　グローバルトランザクションへのMessage-driven Bean（サービス）の参加条件

OpenTP1のアプリケーションプログラムが開始したトランザクションに，アプリケーションサーバのMessage-driven Bean（サービス）が参加できる条件は二つあります。それぞれについて説明します。

アプリケーションサーバのライトトランザクション機能が無効な場合

ライトトランザクション機能が無効な場合，Message-driven Bean（サービス）はグローバルトランザクションに参加できます。一方，ライトトランザクション機能が有効になっている場合，アプリケーションサーバのトランザクションマネージャを使用できません。このため，ライトトランザクション機能が有効な場合にTP1インバウンドアダプタがOpenTP1からトランザクショナルRPCを受信したときは，エラーメッセージ（KDJE58363-E）を出力し，OpenTP1がRPCエラー（DCRPCER_TRNCHK_EXTEND（-372））を返します。

Message-driven Bean（サービス）のトランザクション属性がRequiredの場合

OpenTP1のトランザクションに参加できるMessage-driven Bean（サービス）について次の表に示します。

表4‒11　OpenTP1のトランザクションに参加できるMessage-driven Bean（サービス）

Message-driven Bean（サービス）のトランザクションの設定

OpenTP1のトランザクションへの参加

タイプ

属性

CMT

Required

○

NotSupported

×

BMT

−

×

（凡例）

○：OpenTP1のトランザクションに参加できます。

×：OpenTP1のトランザクションに参加できません（Message-driven Bean（サービス）の呼び出しはできます）。この場合，OpenTP1ではノーアクセス最適化が適用されます。

−：該当しません。

4.9.4　トランザクショナルRPCの受信と応答

OpenTP1のSUPがトランザクション処理中にRPC通信をすると，RPC通信先はトランザクションブランチとしてOpenTP1のグローバルトランザクションに参加します。この場合のRPC通信をトランザクショナルRPCと呼びます。

TP1インバウンドアダプタがトランザクショナルRPCを受信して，OpenTP1へ応答を送信するまでの流れを次の図に示します。

図4‒16　トランザクショナルRPCの受信と応答

OpenTP1のアプリケーションプログラムがTP1インバウンドアダプタに対してトランザクショナルRPCを送信します。

TP1インバウンドアダプタでは，コネクション管理機能がOpenTP1からの電文を検知して，RPC通信機能のリクエスト受け付けスレッドが電文を受信します。詳細は，「4.6.2　コネクション接続要求の受信」を参照してください。

RPC通信機能のリクエスト受け付けスレッドは，受信した電文がトランザクショナルRPCの場合，OpenTP1とトランザクション連携が可能な設定になっているかどうか（アプリケーションサーバのライトトランザクション機能が無効になっているか）を判定します。なお，受信した電文がトランザクショナルRPCでなければ判定しません。

OpenTP1とトランザクション連携が可能な設定については，「4.9.3　グローバルトランザクションへのMessage-driven Bean（サービス）の参加条件」を参照してください。

OpenTP1とトランザクション連携が可能な設定と判定した場合，リクエスト受け付けスレッドは，トランザクション識別子を生成し，RPC要求に関連づけて，そのRPC要求をスケジュール機能のスケジュールキューに登録します。スケジュール機能の詳細は，「4.8　スケジュール機能」を参照してください。

スケジュール機能のMessage-driven Bean（サービス）実行制御スレッドは，スケジュールキューからRPC要求を取り出し，そのRPC要求に関連づいたトランザクション識別子をトランザクションマネージャに登録します。トランザクションマネージャは，登録されたトランザクション識別子をアプリケーションサーバのトランザクション識別子とマッピングします。これによって，アプリケーションサーバのトランザクションが開始します。

Message-driven Bean（サービス）実行制御スレッドは，Message-driven Bean（サービス）呼び出しスレッドにRPC要求の処理を委譲します。Message-driven Bean（サービス）呼び出しスレッドはMessage-driven Bean（サービス）を実行します。

Message-driven Bean（サービス）が，データベースなどのリソースを更新します。

Message-driven Bean（サービス）呼び出しスレッドは，2.で生成したトランザクション識別子をRPC応答に含めてOpenTP1に送信します。この際，送信に使用するコネクションはRPC送信コネクションになります。

TP1インバウンドアダプタからRPC応答を受信したOpenTP1は，RPC応答に含まれているトランザクション識別子をトランザクションブランチの識別子として管理し，その後の同期点処理のトランザクション識別子として使用します。

4.9.5　同期点処理

同期点処理では，OpenTP1からのトランザクション処理（コミット・プリペア・ロールバック）を実行します。同期点処理は，トランザクション連携機能の同期点電文送受信スレッドが送受信します。トランザクション連携機能を使用した同期点処理の流れを次の図に示します。

図4‒17　同期点処理の流れ

OpenTP1のSUPが，グローバルトランザクションをコミット（dc_trn_unchained_commit関数）します。

OpenTP1は，TP1インバウンドアダプタからのRPC応答を受信したコネクションを使用して，TP1インバウンドアダプタへプリペア（更新準備処理）を送信します。RPC応答を受信したコネクションが切断している場合，OpenTP1では，新たにTP1インバウンドアダプタとコネクションを接続してからプリペアを送信します。コネクションの接続は，「4.6.2(2)　同期点待ち受けポートがコネクション接続要求を受信した際の動作」を参照してください。

コネクション管理機能の同期点監視スレッドでは，OpenTP1からの電文の受信を検知すると，該当するコネクションにトランザクション連携機能の同期点電文送受信スレッドを割り当てます。

コネクションを割り当てられた同期点電文送受信スレッドは，OpenTP1からのプリペアを受信します。

同期点電文送受信スレッドは，トランザクションマネージャに対してプリペアを実行します。トランザクションマネージャのプリペアが完了すると，同期点電文送受信スレッドは，プリペアを受信したコネクションを使用して，OpenTP1へプリペアの応答を送信します。

OpenTP1は，TP1インバウンドアダプタからプリペアの応答を受信すると，同じコネクションを使用してTP1インバウンドアダプタへコミットまたはロールバック（更新処理）を送信します。プリペアの応答を受信したコネクションが切断している場合，OpenTP1では，新たにTP1インバウンドアダプタとコネクションを接続してからコミットまたはロールバックを送信します。コネクションの接続は，「4.6.2(2)　同期点待ち受けポートがコネクション接続要求を受信した際の動作」を参照してください。

コネクション管理機能の同期点監視スレッドでOpenTP1からの電文の受信を検知すると，同期点監視スレッドは該当するコネクションにトランザクション連携機能の同期点電文送受信スレッドを割り当てます。

コネクションを割り当てられた同期点電文送受信スレッドは，OpenTP1からのコミットまたはロールバックを受信します。

同期点電文送受信スレッドは，トランザクションマネージャに対してコミットまたはロールバックを実行します。

トランザクションマネージャのコミット・ロールバックが完了すると，同期点電文送受信スレッドは，コミット・ロールバックを受信したコネクションを使用してOpenTP1へコミット・ロールバックの応答を送信します。

ポイント

2相コミットによるトランザクションの決着

OpenTP1では，グローバルトランザクションに参加しているRPC通信先のOpenTP1，またはアプリケーションサーバのトランザクションの決着には2相コミットを使用しています。

2相コミットとは，アプリケーションサーバのトランザクションの決着処理をプリペアと，コミット・ロールバックの2段階に分ける方式です。これにより，複数のトランザクションを矛盾なく更新できます。

2相コミットの詳細については，マニュアル「OpenTP1 解説」の2相コミットに関する説明を参照してください。

4.9.6　同期点処理の最適化

OpenTP1では，トランザクションを効率良く決着するために，同期点処理を最適化しています。OpenTP1の最適化の種類と，TP1インバウンドアダプタのトランザクション連携機能での使用可否の対応を次の表に示します。

なお，それぞれの最適化処理の詳細については，マニュアル「OpenTP1 プログラム作成の手引」のトランザクションの最適化に関する説明を参照してください。

表4‒12　トランザクション連携機能を使用した際に適用できるOpenTP1の最適化の種類

OpenTP1の最適化の種類

概要

トランザクション連携機能での使用可否

1相コミット最適化

アプリケーションサーバが更新するリソースが一つの場合，アプリケーションサーバの同期点処理だけで済ませます。

これによって，2回分の同期点処理の通信が不要になります。

○

リードオンリー最適化

アプリケーションサーバがリソースを更新しない場合，またはリソースにアクセスしていない場合，OpenTP1で同期点処理の2相目（コミット／ロールバック）を実行しません。

これによって，2回分の同期点処理の通信が不要になります。

OpenTP1との機能差

OpenTP1では，リソースにアクセスしていない場合にはノーアクセス最適化が適用されますが，TP1インバウンド連携機能では，リードオンリー最適化が適用されます。

△

ノーアクセス最適化

トランザクション属性がNotSupported，またはトランザクション管理種別がBMTのMessage-driven Bean（サービス）をトランザクショナルRPCで呼び出した場合，OpenTP1で同期点処理を実行しません。

これによって，4回分の同期点処理の通信が不要になります。

OpenTP1との機能差

OpenTP1では，リソースにアクセスしていない場合にノーアクセス最適化が適用されます。

コミット最適化

アプリケーションサーバで実行する同期点処理の2相目（コミット／ロールバック）をOpenTP1で実行します。

×

ロールバック最適化

アプリケーションサーバでロールバック処理を実行した場合，ほかのトランザクションブランチと同期を取らないでロールバックします。

プリペア最適化

アプリケーションサーバで実行する同期点処理の1相目（プリペア）を，OpenTP1で実行します。

非同期プリペア最適化

アプリケーションサーバのMessage-driven Bean（サービス）の実行が終了した時点でプリペアを実行します。

（凡例）

○：使用できます。

×：使用できません。

△：使用できますが機能差があります。

4.9.7　トランザクション連携機能の設定

トランザクション連携機能で指定する項目は次のとおりです。

OpenTP1と送受信する同期点処理の最大同時同期点処理数

trn_max_thread_countプロパティ

Connector属性ファイルの指定方法の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

Message-driven Bean（サービス）のトランザクションタイムアウト

詳細については「4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定」を参照してください。

4.9.8　トランザクション障害発生時の対処

OpenTP1とアプリケーションサーバ間のトランザクション連携中にサーバに障害が発生した場合や，サーバを強制停止した場合，通常はサーバを再起動すればOpenTP1とアプリケーションサーバの自動決着機能によってトランザクションは自動的に決着します。しかし，タイミングによっては，再起動してもトランザクションが自動的に決着しないで，仕掛かり中のまま残ることがあります。

また，OpenTP1とアプリケーションサーバ間で一時的な通信障害が発生した場合でも，通常はOpenTP1とアプリケーションサーバの通信リトライによってトランザクションは自動的に決着します。しかし，障害が発生したタイミングや復旧までに掛かった時間によっては，トランザクションが自動的に決着しないで，仕掛かり中のまま残ることがあります。このような場合，コマンドを使用して，仕掛かり中のトランザクションを決着する必要があります。

ここでは，次に示す障害発生時での，仕掛かり中のトランザクションへの対処方法を示します。

OpenTP1に障害が発生，または強制停止した場合

アプリケーションサーバに障害が発生，または強制停止した場合

OpenTP1とアプリケーションサーバに障害が発生した場合

通信障害が発生した場合

OpenTP1に障害が発生した場合（再開始できない場合）

アプリケーションサーバに障害が発生した場合（再起動できない場合）

OpenTP1とアプリケーションサーバに障害が発生した場合（再開始または再起動できない場合）

仕掛かり中トランザクションの手動決着の順序

(1)　OpenTP1に障害が発生，または強制停止した場合

トランザクション連携中にOpenTP1に障害が発生した場合や，強制停止した場合，次に示す手順で仕掛かり中のトランザクションの有無を確認し，トランザクションを決着してください。

OpenTP1の再開始

障害発生，または強制停止した原因を取り除き，OpenTP1を再開始します。OpenTP1を再開始できない場合の対処は，「4.9.8(5)　OpenTP1に障害が発生した場合（再開始できない場合）」を参照してください。

OpenTP1とアプリケーションサーバの仕掛かり中トランザクションの決着

OpenTP1の再開始後に，「4.9.8(8)　仕掛かり中トランザクションの手動決着の順序」に従ってOpenTP1とアプリケーションサーバの仕掛かり中のトランザクションを決着してください。

アプリケーションサーバだけに残っている仕掛かり中トランザクションの決着

手順2.の完了後，30〜45秒経過後にアプリケーションサーバのメッセージログにKFCB40136-Wメッセージが出力される場合は，アプリケーションサーバ側だけに仕掛かり中のトランザクションが残っています。この場合，KFCB40136-Wメッセージの対処に従ってトランザクションを決着してください。KFCB40136-Wについては，マニュアル「アプリケーションサーバメッセージ(構築／運用／開発用)」の「17.4　KFCB40000からKFCB49999までのメッセージ」を参照してください。

(2)　アプリケーションサーバに障害が発生，または強制停止した場合

トランザクション連携中にアプリケーションサーバに障害が発生した場合や，強制停止した場合，次に示す手順で仕掛かり中のトランザクションの有無を確認し，トランザクションを決着してください。

アプリケーションサーバの再起動

障害発生，または強制停止した原因を取り除き，アプリケーションサーバを再起動します。

アプリケーションサーバを再起動できない場合の対処は，「4.9.8(6)　アプリケーションサーバに障害が発生した場合（再起動できない場合）」を参照してください。

OpenTP1とアプリケーションサーバの仕掛かり中トランザクションの決着

アプリケーションサーバの障害発生，または強制停止したあとに，OpenTP1の標準出力にKFCA00991-WおよびKFCA00960-Iメッセージが出力された場合は，OpenTP1またはアプリケーションサーバに仕掛かり中のトランザクションが残っているおそれがあります。この場合は，「4.9.8(8)　仕掛かり中トランザクションの手動決着の順序」に従ってOpenTP1とアプリケーションサーバの仕掛かり中のトランザクションを決着してください。

(3)　OpenTP1とアプリケーションサーバに障害が発生した場合

トランザクション連携中にOpenTP1とアプリケーションサーバの両方に障害が発生した場合，次に示す手順で，仕掛かり中のトランザクションの有無を確認し，トランザクションを決着してください。

アプリケーションサーバの再起動とOpenTP1の再開始

障害発生の原因を取り除き，アプリケーションサーバを再起動して，OpenTP1を再開始してください。

アプリケーションサーバを再起動できない場合の対処は，「4.9.8(6)　アプリケーションサーバに障害が発生した場合（再起動できない場合）」を参照してください。OpenTP1を再開始できない場合の対処は，「4.9.8(5)　OpenTP1に障害が発生した場合（再開始できない場合）」を参照してください。

アプリケーションサーバの再起動とOpenTP1の再開始の順序に決まりはありません。

OpenTP1とアプリケーションサーバの仕掛かり中トランザクションの決着

OpenTP1の再開始後に，「4.9.8(8)　仕掛かり中トランザクションの手動決着の順序」に従ってOpenTP1とアプリケーションサーバの仕掛かり中のトランザクションを決着してください。

アプリケーションサーバだけに残っている仕掛かり中トランザクションの決着

手順2.完了後，30〜45秒経過後にアプリケーションサーバのメッセージログにKFCB40136-Wメッセージが出力される場合は，アプリケーションサーバ側だけに仕掛かり中のトランザクションが残っています。

この場合，KFCB40136-Wメッセージの対処に従ってトランザクションを決着してください。KFCB40136-Wについては，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「17.4　KFCB40000からKFCB49999までのメッセージ」を参照してください。

(4)　通信障害が発生した場合

トランザクション連携中にOpenTP1とアプリケーションサーバ間，または，アプリケーションサーバとリソース間で通信障害が発生した場合，次に示す手順で，仕掛かり中のトランザクションの有無を確認し，トランザクションを決着させてください。

通信路の復旧

通信障害の原因を取り除き，通信路を復旧します。

OpenTP1とアプリケーションサーバの仕掛かり中トランザクションの決着

OpenTP1の標準出力にKFCA00991-WおよびKFCA00960-Iメッセージが出力されている場合は，OpenTP1またはアプリケーションサーバに仕掛かり中のトランザクションが残っているおそれがあります。この場合は，「4.9.8(8)　仕掛かり中トランザクションの手動決着の順序」に従ってOpenTP1とアプリケーションサーバの仕掛かり中のトランザクションを決着します。

アプリケーションサーバだけに残っている仕掛かり中トランザクションの決着

手順2.完了後，30〜45秒経過後にアプリケーションサーバのメッセージログにKFCB40136-Wメッセージが出力される場合は，アプリケーションサーバ側だけに仕掛かり中のトランザクションが残っています。

この場合，KFCB40136-Wメッセージの対処に従ってトランザクションを決着します。KFCB40136-Wについては，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「17.4　KFCB40000からKFCB49999までのメッセージ」を参照してください。

(5)　OpenTP1に障害が発生した場合（再開始できない場合）

トランザクション連携中にOpenTP1に障害が発生し，すぐに再開始できない場合は，次に示す手順で，仕掛かり中のトランザクションの有無を確認し，トランザクションを決着させてください。

トランザクションの決着状態の確認

トランザクション処理を開始して30〜45秒経過後，アプリケーションサーバのメッセージログにKFCB40136-Wメッセージが出力される場合は，アプリケーションサーバ側に仕掛かり中のトランザクションが残っています。

この場合，KFCB40136-Wメッセージの内容を確認して，OpenTP1に関連づいたリソースがコミット決着したかロールバック決着したかを確認してください。

トランザクションの決着

手順1.の確認結果に応じてアプリケーションサーバ側のトランザクションをcjcommittrnコマンドまたはcjrollbacktrnコマンドで決着してください。

(6)　アプリケーションサーバに障害が発生した場合（再起動できない場合）

トランザクション連携中にアプリケーションサーバに障害が発生し，すぐに再起動できない場合は，cjlisttrnfileコマンドとアプリケーションサーバのPRFトレースを使用して，次に示す手順で仕掛かり中のトランザクションの有無を確認し，トランザクションを決着させてください。

アプリケーションサーバに残っている仕掛かり中トランザクションの有無の確認

アプリケーションサーバに障害が発生している場合は，cjlisttrnコマンドを使用できないため，cjlisttrnfileコマンドで仕掛かり中トランザクションの有無を確認します。

確認結果の出力例を次に示します。

> cjlisttrnfile
[Global transaction information(status file)]
status file1: C:¥Program Files¥HITACHI¥Cosminexus¥CC¥server¥public¥ejb¥MyServer¥
otsstatus¥transaction_1.status
host       (recorded in status file): "apsv1"
J2EE server(recorded in status file): "Myserver"

Status    GlobalTransactionId                                      BranchType
--------- -------------------------------------------------------- ----------
Prepared  d13800010000000000000000000000fefb58e6480000000000000001 Sub
Prepared  d13800010000000000000000000001fefb58e6480000000000000002 Sub

total count: 2

アプリケーションサーバ側のトランザクションの決着状態の確認

手順1.で出力されたトランザクションについて，アプリケーションサーバに関連するリソースがコミット決着またはロールバック決着したかを確認します。

なお，トランザクションの一貫性が保たれていない場合は修復してください。

アプリケーションサーバに関連するリソースのトランザクションの決着状態の確認方法，およびトランザクションの修復方法については，リソースのマニュアルを参照してください。

OpenTP1のトランザクショングローバル識別子の特定

アプリケーションサーバのPRFトレースの内容を基に，OpenTP1のトランザクショングローバル識別子を特定します。トランザクショングローバル識別子の特定方法の例を次の図に示します。

図4‒18　OpenTP1のトランザクショングローバル識別子の特定

0x9400のOPT（ASCII列）が手順1.の出力例の「GlobalTransactionId」部分と一致するPRFトレースを特定します。0x9400と同じルートAP情報の0xAA00のOPT（ASCII列）の5文字目から20文字目までの文字列が，OpenTP1のトランザクショングローバル識別子となります。

OpenTP1側のトランザクションの決着状態の確認

手順3.で特定したOpenTP1のトランザクショングローバル識別子について，OpenTP1に関連するリソースがコミット決着またはロールバック決着したかを確認します。トランザクションの一貫性が保たれていない場合は，修復してください。

(7)　OpenTP1とアプリケーションサーバに障害が発生した場合（再開始または再起動できない場合）

トランザクション連携中にOpenTP1とアプリケーションサーバに障害が発生し，すぐに再開始または再起動できない場合は，「4.9.8(6)　アプリケーションサーバに障害が発生した場合（再起動できない場合）」の手順に従って仕掛かり中のトランザクションの有無を確認し，仕掛かり中のトランザクションがあれば決着してください。

(8)　仕掛かり中トランザクションの手動決着の順序

OpenTP1とアプリケーションサーバ間のトランザクション連携中に障害が発生すると，OpenTP1またはアプリケーションサーバに仕掛かり中のトランザクションが残っているおそれがあります。この場合，次に示す手順で仕掛かり中のトランザクションの有無を確認し，トランザクションを決着させてください。仕掛かり中のトランザクションが複数ある場合は，次に示す手順を繰り返してください。

OpenTP1の仕掛かり中トランザクションの状態確認

OpenTP1のtrnlsコマンドを実行し，OpenTP1のトランザクションの状態を確認します。このとき，-tオプションを指定します。

> trnls -t
TRNGID                 TRNBID             状態                       PID    サーバ   サービス
cab9TP1S0000074f       TP1STP1S0000074f   HEURISTIC_FORGETTING(p,n)  0   TP1S

OpenTP1の仕掛かり中トランザクションの強制終了

手順1.の実行結果の「状態」部分が"HEURISTIC_FORGETTING"以外の場合は，手順3.へ進みます。「状態」部分が"HEURISTIC_FORGETTING"の場合は，OpenTP1のtrnfgtコマンドを実行し，OpenTP1のトランザクションを強制終了します。このとき，-Tオプションに手順1.の実行結果の「TRNGID」部分を指定します。

> trnfgt -T cab9TP1S0000074f

トランザクションの実行状態によっては，trnfgtコマンドは正常終了してもOpenTP1のトランザクションを強制終了できていなかったり，trnfgtコマンドがKFCA00970-Eを出力して異常終了していたりすることがあります。この場合は手順3.に進み，アプリケーションサーバの仕掛かり中トランザクションをすべて決着してから，手順5.を実施してください。

アプリケーションサーバの仕掛かり中トランザクションの特定

アプリケーションサーバのcjlisttrnコマンドを実行し，手順1.の実行結果の「TRNGID」部分と，cjlisttrnコマンドの実行結果の「TP1TRNGID」部分が一致するトランザクションを特定します。このとき，-tp1オプションと-pendingオプションを指定します。

なお，この例では，決着するアプリケーションサーバの仕掛かり中トランザクションの「Status」部分は"Prepared"となります。

> cjlisttrn MyServer -tp1 -pending
[Global transaction information]
Status            GlobalTransactionId                                      ElapsedTime BranchType TP1TRNGID        TP1TRNBID
----------------- -------------------------------------------------------- ----------- ---------- ---------------- ----------------
Prepared          d13800010000000000000000000000fefb58e6480000000000000001          30 Sub        cab9TP1S0000074f @@@@TP1S0000074f

total count: 1

アプリケーションサーバの仕掛かり中トランザクションの決着

手順1.の実行結果の「状態」部分が"HEURISTIC_FORGETTING"，または"COMMIT"だった場合

アプリケーションサーバのcjcommittrnコマンドを実行し，アプリケーションサーバの仕掛かり中トランザクションをコミットで決着します。このとき，-gidオプションに手順3.で特定したアプリケーションサーバの仕掛かり中トランザクションの「GlobalTransactionId」部分を指定します。

> cjcommittrn MyServer -gid d13800010000000000000000000000fefb58e6480000000000000001

「状態」部分が"ROLLBACK"だった場合

アプリケーションサーバのcjrollbacktrnコマンドを実行し，アプリケーションサーバの仕掛かり中トランザクションをロールバックで決着します。このとき，-gidオプションに手順3.で特定したアプリケーションサーバの仕掛かり中トランザクションの「GlobalTransactionId」部分を指定します。

> cjrollbacktrn MyServer -gid d13800010000000000000000000000fefb58e6480000000000000001

コマンドで決着できないOpenTP1の仕掛かり中トランザクションの強制終了

手順1.の実行結果の「状態」部分が"COMMIT"，または，手順2.のtrnfgtコマンドを実行しても強制終了できなかった"HEURISTIC_FORGETTING"のトランザクションは，コマンドを使った手動決着ができません。

そのため，すべての仕掛かり中のトランザクションに対して手順1.〜4.を実施したあと，再度OpenTP1のtrnlsコマンドを実行します。コマンド実行後，「状態」部分に"COMMIT"または"HEURISTIC_FORGETTING"のトランザクションが残っている場合は，OpenTP1を強制停止してから強制正常開始してください。

4.10　Message-driven Bean（サービス）の実装

TP1インバウンドアダプタを利用したMessage-driven Bean（サービス）の実装手順を次に示します。

Message-driven Bean（サービス）の実装の準備

TP1インバウンドアダプタを開始します。

Message-driven Bean（サービス）の作成

TP1インバウンドアダプタから呼び出すMessage-driven Bean（サービス）を作成します。

次の作業を実施してください。

クラスパスの設定

リスナインタフェースの実装

onMessageメソッドでの業務ロジックの実装

ejb-jar.xmlの定義

cosminexus.xmlの定義

Message-driven Bean（サービス）の開始

Message-driven Bean（サービス）を含むJ2EEアプリケーションを開始します。

参考

アプリケーションサーバでは，TP1インバウンドアダプタから呼び出すMessage-driven Bean（サービス）のサンプルプログラムを提供しています。サンプルプログラムは，次に示すディレクトリに格納されています。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/examples/tp1inbound

4.10.1　Message-driven Bean（サービス）の実装の準備

Message-driven Bean（サービス）を実装する前にJ2EEサーバの設定，およびTP1インバウンドアダプタの開始を実施します。

(1)　トランザクション連携機能を使用する場合のJ2EEサーバの設定

トランザクション連携機能を使用する場合にJ2EEサーバの設定が必要です。

トランザクション連携機能では，グローバルトランザクションを利用します。そのため，トランザクション連携機能を使用する場合は，J2EEサーバのライトトランザクション機能を無効にする必要があります。

J2EEサーバのライトトランザクション機能を無効にするプロパティについて次に示します。なお，トランザクション連携機能を使用しない場合は，次のプロパティの設定は，有効または無効のどちらでもかまいません。

ejbserver.distributedtx.XATransaction.enabled

ライトトランザクションを使用するか，グローバルトランザクションを使用するかを指定します。trueを指定した場合，グローバルトランザクションを利用できます。

(2)　TP1インバウンドアダプタの開始

TP1インバウンドアダプタを開始する手順を示します。

TP1インバウンドアダプタをインポートします。

cjimportresコマンドを実行して，TP1インバウンドアダプタをインポートします。アプリケーションサーバでは，TP1インバウンドアダプタ（TP1InboundAdapter.rar）をConnector1.5仕様に準拠したインバウンドリソースアダプタとして提供しています。

実行形式を次に示します。

cjimportres <サーバ名> -type rar -f <ファイルパス>

<ファイルパス>には，TP1インバウンドアダプタのパスとして，次のパスを指定してください。

Windowsの場合

"<Application Serverのインストールディレクトリ>¥CC¥adapters¥OpenTP1¥TP1InboundAdapter.rar"

UNIXの場合

/opt/Cosminexus/CC/adapters/OpenTP1/TP1InboundAdapter.rar

TP1インバウンドアダプタをデプロイします。

cjdeployrarコマンドを実行して，インポートしたTP1インバウンドアダプタをデプロイします。

実行形式を次に示します。

cjdeployrar <サーバ名> -resname TP1_Inbound_Adapter

TP1インバウンドアダプタを定義します。

TP1インバウンドアダプタのConnector属性ファイルを編集して，TP1インバウンドアダプタのConnector属性を定義します。

TP1インバウンドアダプタのConnector属性の定義の詳細については，「4.12.2　リソースアダプタの設定」を参照してください。

TP1インバウンドアダプタを開始します。

cjstartrarコマンドを実行して，TP1インバウンドアダプタを開始します。

実行形式を次に示します。

cjstartrar <サーバ名> -resname TP1_Inbound_Adapter

4.10.2　クラスパスの設定

TP1インバウンドアダプタのリスナインタフェースクラスはejbserver.jarに含まれています。

Message-driven Bean（サービス）を作成する環境でejbserver.jarのクラスパスを設定してください。

Windowsの場合

set CLASSPATH=%CLASSPATH%;%COSMINEXUS_HOME%¥CC¥lib¥ejbserver.jar

UNIX（sh）の場合

CLASSPATH=${CLASSPATH}:/opt/Cosminexus/CC/lib/ejbserver.jar
export CLASSPATH

UNIX（csh）の場合

setenv CLASSPATH ${CLASSPATH}:/opt/Cosminexus/CC/lib/ejbserver.jar

4.10.3　リスナインタフェースの実装

Message-driven Bean（サービス）に，TP1インバウンドアダプタのリスナインタフェースを実装してください。

TP1インバウンドアダプタのリスナインタフェースを次に示します。

TP1MessageListener

Message-driven Bean（サービス）にリスナインタフェース（TP1MessageListener）を実装する例を次に示します。

public class SampleMDB
implements TP1MessageListener,MessageDrivenBean
{
  ・・・
}

4.10.4　onMessageメソッドでの業務ロジックの実装

onMessageメソッドに，次に示す業務ロジックを実装します。

public TP1OutMessage onMessage(TP1InMessage in)
{
  //入力パラメタ取得
  byte[] inputdata = in.getInputData();
  ・・・
  //出力データオブジェクトの生成
  TP1OutMessage out = in.createOutMessage();
  ・・・
  ・・・
  //出力データ格納領域の長さを取得
  int outLen = out.getMaxOutputLength();
  ・・・
  try {
    ・・・
    //出力データ格納領域の取得
    byte[] outputdata = out.getOutputData(outLen);
    ・・・
    //業務処理
    //outputdata中に出力データを格納
    ・・・
  } catch(Exception e) {
    //errorLenにエラー処理用の出力データ長を設定
    //エラー処理用の出力データ格納領域の取得
    byte[] outputdata = out.getOutputData(errorLen);
    ・・・
    //outputdata中にエラー情報を格納
    ・・・
  }
  return out;
}

TP1InMessageからユーザデータを取得して業務処理を実行します。

実行結果の出力データをTP1OutMessageのgetOutputDataメソッドで取得したbyte配列中に格納して返します。

getOutputDataメソッドの引数outLenには，応答の長さを指定します。応答の長さは，0〜（TP1OutMessageインタフェースのgetMaxOutputLengthメソッドの戻り値）以下の範囲で指定してください。

onMessageメソッドの戻り値がnullの場合，またはgetOutputDataメソッドを呼び出していない場合は，出力データが未設定（null）のため，TP1インバウンドアダプタはエラーメッセージを出力して，RPCエラー(DCRPCER_SYSERR_AT_SERVER(-316))を返します。この場合，呼び出し元のdc_rpc_call関数はRPCエラー(トランザクショナルRPCでない場合はDCRPCER_SYSERR_AT_SERVER(-316)，トランザクショナルRPCの場合はDCRPCER_SYSERR_AT_SERVER_RB(-325))を返します。

業務処理では例外をすべてキャッチして，エラー時もエラー情報をTP1OutMessageインタフェースのgetOutputDataメソッドで取得したbyte配列にエラー情報を格納して返してください。業務処理で発生した例外をキャッチしなかった場合，またはnullを返した場合は，エラーメッセージ（KDJE58459-E）が出力されて，RPCエラー(DCRPCER_SYSERR_AT_SERVER(-316))になります。この場合，呼び出し元のdc_rpc_call関数はRPCエラー(トランザクショナルRPCでない場合はDCRPCER_SYSERR_AT_SERVER(-316)，トランザクショナルRPCの場合はDCRPCER_SYSERR_AT_SERVER_RB(-325))を返します。RPCエラー応答の詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

Message-driven Bean（サービス）のコーディング例は，トランザクション連携機能を使用しない場合と，トランザクション連携機能を使用する場合の2種類があります。Message-driven Bean（サービス）のコーディング例を次に示します。

トランザクション連携機能を使用しない場合のコーディング例

import java.sql.Connection;
import java.sql.PreparedStatement;
import javax.ejb.EJBException;
import javax.ejb.MessageDrivenBean;
import javax.ejb.MessageDrivenContext;
import javax.naming.InitialContext;
import javax.sql.DataSource;
import javax.transaction.UserTransaction;

import com.hitachi.software.ejb.adapter.tp1.TP1InMessage;
import com.hitachi.software.ejb.adapter.tp1.TP1MessageListener;
import com.hitachi.software.ejb.adapter.tp1.TP1OutMessage;

public class SampleMDB
implements TP1MessageListener, MessageDrivenBean {

    private MessageDrivenContext context;
    public TP1OutMessage onMessage(TP1InMessage in) {
        //入力パラメタ取得
        byte[] inputdata = in.getInputData();

        //出力データオブジェクトの生成
        TP1OutMessage out = in.createOutMessage();

        //出力データ格納領域の長さを取得
        int outLen = out.getMaxOutputLength();

        UserTransaction ut = null;
        Connection con = null;
        PreparedStatement prepStmt = null;
        try {
            //DB更新する業務処理を実装
            InitialContext ic = new InitialContext();
            DataSource ds = (DataSource)ic.lookup(
                                "java:comp/env/jdbc/SampleDB");
            ut = context.getUserTransaction();
            ut.begin();
            con = ds.getConnection();
            prepStmt = con.prepareStatement(
                              "update sample set name = ? where id = 1");
            prepStmt.setString(1, new String(inputdata));
            prepStmt.executeUpdate();
            ut.commit();
            byte[] result ="update complete.".getBytes();
            //出力データ格納領域の取得
            byte[] outputdata = out.getOutputData(outLen);

            //業務処理の結果を出力データにコピー
            System.arraycopy(result,0,outputdata,0,result.length);
        } catch(Exception e) {
            //エラー処理
            try {
                if(ut != null) {
                    ut.rollback();
                }
            } catch(Exception ex) {
            }
            byte[] wk = "An error occurred.".getBytes();

            //エラー処理用の出力データ格納領域の取得
            byte[] outputdata = out.getOutputData(wk.length);
            //エラー処理の内容を出力データにコピー
            System.arraycopy(wk,0,outputdata,0,wk.length);
        }
        finally {
            if(prepStmt != null) {
                try {
                    prepStmt.close();
                } catch(Exception exp) {
                }
            }
            if(con != null) {
                try {
                    con.close();
                } catch(Exception exp) {
                }
            }
        }
        return out;
    }

    public void ejbCreate() {
    }
    public void ejbRemove() throws EJBException {
    }
    public void setMessageDrivenContext(MessageDrivenContext ctx)
            throws EJBException {
        this.context = ctx;
    }
}

トランザクション連携機能を使用する場合のコーディング例

import java.sql.Connection;
import java.sql.PreparedStatement;
import javax.ejb.EJBException;
import javax.ejb.MessageDrivenBean;
import javax.ejb.MessageDrivenContext;
import javax.naming.InitialContext;
import javax.sql.DataSource;

import com.hitachi.software.ejb.adapter.tp1.TP1InMessage;
import com.hitachi.software.ejb.adapter.tp1.TP1MessageListener;
import com.hitachi.software.ejb.adapter.tp1.TP1OutMessage;
public class SampleMDB
implements TP1MessageListener, MessageDrivenBean {
    public TP1OutMessage onMessage(TP1InMessage in) {
        //入力パラメタ取得
        byte[] inputdata = in.getInputData();

        //出力データオブジェクトの生成
        TP1OutMessage out = in.createOutMessage();

        //出力データ格納領域の長さを取得
        int outLen = out.getMaxOutputLength();
        Connection con = null;
        PreparedStatement prepStmt = null;
        try {
            //DB更新する業務処理を実装
            InitialContext ic = new InitialContext();
            DataSource ds = (DataSource)ic.lookup(
                                "java:comp/env/jdbc/SampleDB");
            con = ds.getConnection();
            prepStmt = con.prepareStatement(
                              "update sample set name = ? where id = 1");
            prepStmt.setString(1, new String(inputdata));
            prepStmt.executeUpdate();
            byte[] result ="update complete.".getBytes();

            //出力データ格納領域の取得
            byte[] outputdata = out.getOutputData(outLen);
            //業務処理の結果を出力データにコピー
            System.arraycopy(result,0,outputdata,0,result.length);
        } catch(Exception e) {
            //エラー処理
            byte[] wk = "An error occurred.".getBytes();

            //エラー処理用の出力データ格納領域の取得
            byte[] outputdata = out.getOutputData(wk.length);

            //エラー処理の内容を出力データにコピー
            System.arraycopy(wk,0,outputdata,0,wk.length);
        }
        finally {
            if(prepStmt != null) {
                try {
                    prepStmt.close();
                } catch(Exception exp) {
                }
            }
            if(con != null) {
                try {
                    con.close();
                } catch(Exception exp) {
                }
            }
        }
        return out;
    }

    public void ejbCreate() {
    }
    public void ejbRemove() throws EJBException {
    }
    public void setMessageDrivenContext(MessageDrivenContext ctx)
            throws EJBException {
    }
}

4.10.5　ejb-jar.xmlの定義

Message-driven Beanのejb-jar.xmlを定義します。

定義項目を次に示します。

Message-driven Bean（サービス）が実装するリスナインタフェース

<messaging-type>タグに次の値を設定します。

com.hitachi.software.ejb.adapter.tp1.TP1MessageListener

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

<transaction-type>タグに次のどちらかを設定します。

Bean

Container

トランザクションの属性

<transaction-type>タグに「Container」を指定した場合，Message-driven Beanのメソッドの属性として，<trans-attribute>タグに次のどちらかを設定します。

Required

NotSupported

ActivationSpecの設定

ActivationSpecに設定する値を<activation-config>タグの下の<activation-config-property>タグ内で定義します。プロパティ名とプロパティ値を指定してください。

<activation-config-property>タグ内で指定する値を次に示します。

activation-config-property-name※

データ型

activation-config-property-value

service

java.lang.String

Message-driven Bean（サービス）のサービス名を1〜31文字で指定します。

1文字目は英字（A〜Z　a〜z），2文字目以降は英数字（A〜Z　a〜z　0〜9）またはアンダースコア（_）で指定してください。

一つのサービスグループ内で一意のサービス名を指定してください。

queue_max_length

java.lang.Integer

サービスごとのスケジュールキューの長さを1〜65535の整数で指定します。デフォルト値は100です。

stay_watch_queue_rate

スケジュールキューの滞留監視でのしきい値として，メッセージを出力するキューの滞留数の割合を，0〜100の整数で指定します。デフォルト値は70です。

指定値が0の場合は滞留監視をしません。

stay_watch_check_interval

スケジュールキューの滞留監視での警告メッセージの抑止時間を1〜2147483647「秒」の整数で指定します。デフォルト値は60秒です。

注※　ActivationSpecの設定では，リソースアダプタのDD（ra.xml）の<activationspec>-<required-config-property>タグに指定されているプロパティを設定する必要があります。

ActivationSpecの設定の詳細については，「3.16.8　Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定」を参照してください。

4.10.6　cosminexus.xmlの定義

cosminexus.xmlに，Message-driven Bean（サービス）に関連する項目を定義します。

次に定義項目を示します。

使用するTP1インバウンドアダプタの表示名

<resource-adapter>タグにConnector属性ファイルの<display-name>タグの値と同じ値を指定します。

プール内のインスタンスの設定

<pooled-instance>タグの下で，プール内のインスタンスを定義します。

minimum（Message-driven Bean（サービス）のインスタンスプールの最小数）

この値は変更できません。常に「1」です。

maximum（Message-driven Bean（サービス）のインスタンスプールの最大数）

定義項目の詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2　アプリケーション属性ファイル（cosminexus.xml）で指定する各属性の詳細」を参照してください。

4.10.7　Message-driven Bean（サービス）の開始

次に，Message-driven Bean（サービス）を開始する手順を示します。

Message-driven Bean（サービス）をインポートします。

cjimportappのコマンドを実行して，Message-driven Bean（サービス）を含むJ2EEアプリケーションをインポートします。

実行形式を次に示します。

cjimportapp <サーバ名> -f "<J2EEアプリケーションのファイルパス>"

J2EEアプリケーションを開始します。

cjstartappコマンドを実行して，インポートしたJ2EEアプリケーションを開始します。

実行形式を次に示します。

cjstartapp <サーバ名> -name <J2EEアプリケーション名>

4.11　OpenTP1のアプリケーションプログラムの作成

ここでは，C言語でプログラムを作成する場合を例にして，TP1インバウンドアダプタを呼び出すアプリケーションプログラムの作成について説明します。

OpenTP1のアプリケーションプログラムからのTP1インバウンドアダプタの呼び出しは，dc_rpc_call関数を使用します。dc_rpc_call関数の各引数に指定する値を次の表に示します。

表4‒13　dc_rpc_call関数の引数に指定する値

引数

指定する値

group

TP1インバウンドアダプタのConnector属性ファイルの<service_group>タグで定義したサービスグループ名を指定します。

service

Message-driven Bean（サービス）のActivationSpecの<service>タグで定義したサービス名を指定します。

in

サービスの入力パラメタを指定します。詳細は，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

in_len

サービスの入力パラメタ長を指定します。詳細は，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

out

応答を格納する領域を指定します。詳細は，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

out_len

応答の長さを指定します。詳細は，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

flags

RPCの形態を指定します。指定可能な値については「4.13.3　トランザクションの設定」を参照してください。

コーディング例は，トランザクション連携機能を使用しない場合と，トランザクション連携機能を使用する場合の2種類があります。

TP1インバウンドアダプタを呼び出すアプリケーションのSUPのコーディング例を次に示します。なお，この例はSUP固有のもので，SPP，MHPには該当しません。

トランザクション連携機能を使用しない場合のコーディング例

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <dcrpc.h>
#include <dctrn.h>
#include <dcadm.h>

main ()
{

  static char    in_buf[1024];
  static DCLONG  in_buf_len;
  static char    out_buf[1024];
  static DCLONG  out_buf_len;
  int rc;

  rc = dc_rpc_open(DCNOFLAGS);
  if (rc != DC_OK) {
    printf("SUP01:dc_rpc_openに失敗しました。CODE = %d¥n", rc);
    goto PROG_END;
  }

  rc = dc_adm_complete(DCNOFLAGS);
  if (rc != DC_OK) {
    printf("SUP01:dc_adm_completeに失敗しました。CODE = %d¥n", rc);
    goto PROG_END;
  }

  strcpy(in_buf, "SUP01:DATA OpenTP1!!");
  in_buf_len = strlen(in_buf) + 1;
  out_buf_len = 1024;
  rc = dc_rpc_call("spp01grp", "svr01", in_buf, &in_buf_len, out_buf,
      &out_buf_len, DCNOFLAGS | DCRPC_TPNOTRAN);
  if (rc != DC_OK) {
    printf("SUP01:サービス要求に失敗しました。CODE = %d¥n", rc);
  }
  printf("SUP01:SERVICE FUNCTION RETURN = %s¥n", out_buf);

  PROG_END:
  dc_rpc_close(DCNOFLAGS);
  printf("SUP01:処理を終了しました。¥n");
  exit(0);
}

トランザクション連携機能を使用する場合のコーディング例

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dcadm.h>
#include <dcrpc.h>
#include <dctrn.h>

main()
{

  static char     in_buf[1024];
  static DCULONG  in_buf_len;
  static char     out_buf[1024];
  static DCULONG  out_buf_len;
  int rc;

  rc = dc_rpc_open(DCNOFLAGS);
  if (rc != DC_OK) {
    printf("SUP01:dc_rpc_openに失敗しました。CODE = %d¥n", rc);
    goto PROG_END;
  }

  rc = dc_adm_complete(DCNOFLAGS);
  if (rc != DC_OK) {
    printf("SUP01:dc_adm_completeに失敗しました。CODE = %d¥n", rc);
    goto PROG_END;
  }

  rc = dc_trn_begin();
  if (rc != DC_OK) {
    printf("SUP01:dc_trn_beginに失敗しました。CODE = %d¥n", rc);
    goto TRAN_END;
  }

  strcpy(in_buf, "SUP01:DATA OpenTP1!!");
  in_buf_len = strlen(in_buf) + 1;
  out_buf_len = 1024;
  rc = dc_rpc_call("spp01grp", "svr01", in_buf, &in_buf_len, out_buf,
                  &out_buf_len, DCNOFLAGS);
  if (rc != DC_OK) {
    printf("SUP01:サービス要求に失敗しました。CODE = %d¥n", rc);
    goto TRAN_END;
  }
  printf("SUP01:SERVICE FUNCTION RETURN = %s¥n", out_buf);

  TRAN_END:
  rc = dc_trn_unchained_commit();
  if (rc != DC_OK) {
    printf("SUP01:dc_trn_unchained_commitに失敗しました。CODE = %d¥n", rc);
  }

  PROG_END:
  dc_rpc_close(DCNOFLAGS);
  printf("SUP01:処理を終了しました。¥n");
  exit(0);
}

4.12　アプリケーションサーバの実行環境での設定

TP1インバウンド連携機能を使用する場合，J2EEサーバの設定とリソースアダプタの設定が必要です。

4.12.1　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。TP1インバウンド連携機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの定義を次の表に示します。

表4‒14　TP1インバウンド連携機能を使用するための簡易構築定義ファイルの定義

項目

指定するパラメタ

設定内容

通信に使用するIPアドレス

ejbserver.jca.adapter.tp1.bind_host

TP1インバウンド連携機能の通信（受信および送信）に使用するIPアドレスを指定します。ホスト名も指定できます。

指定がない場合，またはホスト名のアドレスが解決できない場合，システムによって自動的に選択された有効なローカルアドレスが使用されます。

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

4.12.2　リソースアダプタの設定

TP1インバウンド連携機能の定義には，TP1インバウンドアダプタのConnector属性ファイルを使用します。

次にTP1インバウンドアダプタのConnector属性ファイルの設定について説明します。

(1)　TP1インバウンドアダプタのRARファイル

TP1インバウンドアダプタのRARファイルは次のディレクトリに格納されています。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥adapters¥OpenTP1¥TP1InboundAdapter.rar

UNIXの場合

/opt/Cosminexus/CC/adapters/OpenTP1/TP1InboundAdapter.rar

(2)　Connector属性ファイルの取得と設定

Connector属性ファイルを取得して，値を編集してからTP1インバウンドアダプタに設定します。ここでは，取得と設定の手順について説明します。

参考

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

Connector属性ファイルのテンプレートファイルの格納先を次に示します。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/admin/templates/TP1InboundAdapter_cfg.xml

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

Connector属性ファイルの取得

cjgetrarpropコマンドを実行して，TP1インバウンドアダプタのConnector属性を取得します。

実行形式を次に示します。

cjgetrarprop <サーバ名> -resname TP1_Inbound_Adapter -c <rar属性ファイルのファイルパス>

Connector属性ファイルの設定

cjsetrarpropコマンドを実行して，編集後のTP1インバウンドアダプタのConnector属性ファイルを設定します。TP1インバウンドアダプタのConnector属性の編集内容については，「4.12.2(3)　Connector属性の定義」を参照してください。

実行形式を次に示します。

cjsetrarprop <サーバ名> -resname TP1_Inbound_Adapter -c <rar属性ファイルのファイルパス>

(3)　Connector属性の定義

TP1インバウンドアダプタのConnector属性ファイルを定義します。

TP1インバウンドアダプタのプロパティの設定

次の表に，TP1インバウンドアダプタのプロパティの設定内容を示します。

表4‒15　Connector属性ファイルでのTP1インバウンド連携機能の定義

項目

指定するタグ

設定内容

Deployツール上に表示されるリソースアダプタの名称

<display-name>

「TP1_Inbound_Adapter」を指定します。

リソースアダプタのコンフィグレーションプロパティの定義

<resourceadapter>-<config-property>

リソースアダプタのコンフィグレーションプロパティのプロパティ名とプロパティ値を指定します※1。

リソースアダプタの実行時プロパティの定義

<resourceadapter-runtime>-<property>

リソースアダプタの実行時プロパティのプロパティ名とプロパティ値を指定します※2。

注※1　リソースアダプタのコンフィグレーションプロパティのプロパティ名とプロパティ値を表4-16に示します。

注※2　リソースアダプタの実行時プロパティのプロパティ名とプロパティ値を表4-17に示します。

表4‒16　リソースアダプタのコンフィグレーションプロパティ

config-property-name

config-property-value

backlog_count

RPC要求を待ち受けるポートのListenキューの長さを指定します。

connection_timeout

RPC要求の応答を送信する時のコネクション確立処理のタイムアウト時間を指定します。

ipc_sockctl_watchtime※

一時クローズ処理要求の応答待ち時間を指定します。

ipc_tcpnodelay※

OpenTP1とのコネクションの接続で使用するソケットにTCP_NODELAYオプションを使用するかどうかを指定します。

max_connections※

RPC要求を待ち受けるポートへの最大同時接続数を指定します。

node_id※

ノード識別子を指定します。

receive_buffer_size※

受信時の受信バッファサイズを指定します。

rpc_close_after_send※

コネクションを切断します。

rpc_max_thread_count※

最大同時RPC要求受け付け数を指定します。

rpc_receive_timeout

RPC要求の受信のタイムアウト時間を指定します。

rpc_receive_timeout_interval

RPC要求の受信のタイムアウトの監視間隔を指定します。

rpc_sockctl_highwater※

RPC受信コネクションの一時クローズ処理開始のしきい値を指定します。

rpc_sockctl_lowwater※

RPC受信コネクションの一時クローズ処理非対象とするコネクション数の割合を指定します。

scd_port

RPC要求を待ち受けるポートのポート番号を指定します。

send_buffer_size※

応答時の送信バッファサイズを指定します。

send_retry_count

サーバの応答送信時のTCP/IPコネクションの接続でエラーが発生したときのリトライ回数を指定します。

send_retry_interval

サーバの応答送信時のTCP/IPコネクションの接続でエラーが発生したときのリトライ間隔を指定します。

service_group※

TP1インバウンドアダプタのサービスグループ名を指定します。

tcp_receive_timeout

コネクションを接続してから，もしくはデータを受信してから次のデータを受信するまでのタイムアウト時間を指定します。

tcp_send_timeout

RPC要求の応答を送信する際の，1回のデータ送信ごとのタイムアウト時間を指定します。

tcp_send_timeout_interval

RPC要求の応答を送信する際の，一回のデータ送信のタイムアウトの監視間隔を指定します。

なお，08-53以降ではこのプロパティの設定は無視されます。

trn_max_connections※

RPC応答または同期点電文の送受信で使用するコネクションの最大同時接続数を指定します。

trn_max_thread_count※

最大同時同期点処理数を指定します。

trn_port

同期点電文を待ち受けるポートのポート番号を指定します。

trn_sockctl_highwater※

RPC送信コネクションの一時クローズ処理開始のしきい値を指定します。

trn_sockctl_lowwater※

RPC送信コネクションの一時クローズ処理非対象とするコネクション数の割合を指定します。

注※

プロパティに設定する値の考え方については，「4.12.2(4)　config-property-nameの説明」を参照してください。

表4‒17　リソースアダプタの実行時プロパティ

property-name

property-value

MaxTPoolSize

Message-driven Bean（サービス）呼び出しスレッドの最大数を指定します。

MinTPoolSize

Message-driven Bean（サービス）呼び出しスレッドの最小数を指定します。

TPoolKeepalive

空いているMessage-driven Bean（サービス）呼び出しスレッドの最大生存時間を指定します。

(4)　config-property-nameの説明

リソースアダプタのコンフィグレーションプロパティに設定するプロパティ値について説明します。

なお，各プロパティの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.10(4)　TP1インバウンドアダプタに設定する<config-property>に指定できるプロパティ」を参照してください。

(a)　サービスグループ名（service_group）

OpenTP1でのサービスグループ名とは，サービスをまとめた単位であり，ネットワークで接続されるすべてのOpenTP1システムの中で一意な識別子です。OpenTP1のユーザサービス定義のservice_group句に設定します。

TP1インバウンドアダプタでのサービスグループ名とは，TP1インバウンドアダプタが呼び出すMessage-driven Bean（サービス）のグループです。OpenTP1と同様にネットワークで接続されるすべてのOpenTP1システムの中で一意な識別子にしてください。サービスグループ名はConnector属性ファイルのservice_groupプロパティに設定します。

(b)　ノード識別子（node_id）

OpenTP1でのノード識別子とは，OpenTP1のセットアップ単位に一意に割り当てる4文字の識別子のことです。OpenTP1のシステム共通定義のnode_id句に設定します。

TP1インバウンドアダプタのノード識別子とは，OpenTP1と同様にネットワークで接続されるすべてのOpenTP1システムの中で一意に割り当てる4文字の識別子です。Connector属性ファイルのnode_idプロパティに設定します。

なお，ノード識別子は，トランザクションの障害が発生し，コマンドを使ってトランザクションを強制決着する際にノードを特定するための情報です。そのため，トランザクション連携機能を使用する場合，OpenTP1システムの中で重複しない一意な文字列を設定しておくことを推奨します。トランザクション連携機能を使用しない場合，TP1インバウンドアダプタのノード識別子はデフォルトの設定値のままで問題ありません。

(c)　RPC要求の同時実行数（max_connections，rpc_max_thread_count）

RPC要求の同時実行数は，次の表に示すConnector属性ファイルのプロパティに設定します。

表4‒18　RPC要求の同時実行数の設定で使用するプロパティ

設定項目

Connector属性ファイルのプロパティ

RPC受信コネクションの最大同時接続数

max_connections

最大同時RPC要求受け付け数

rpc_max_thread_count

max_connectionsプロパティには，TP1インバウンドアダプタに同時にRPC要求を送信するOpenTP1のプロセス数を設定します。

rpc_max_thread_countプロパティには，TP1インバウンドアダプタで処理するRPC要求の処理時間とスループットから算出したスレッド数を設定します。

例えば，RPC要求の処理時間が50ms，RPC要求のスループットが200TPSを実現する場合に必要なスレッド数は，CPU使用率を100%としたときに，0.05（秒）×200（TPS）＝10（スレッド）となります。RPC要求の処理時間は，各システムでの実測値とします。また，CPU100%以下を想定する場合は，それに応じた安全係数を考慮してください。

(d)　RPC応答と同期点処理の同時実行数（trn_max_connections，trn_max_thread_count）

RPC応答と同期点処理の同時実行数は，次の表に示すConnector属性ファイルのプロパティに設定します。

表4‒19　RPC応答と同期点処理の同時実行数の設定

設定項目

Connector属性ファイルのプロパティ

RPC送信コネクションの最大同時接続数

trn_max_connections

最大同時同期点処理数

trn_max_thread_count

trn_max_connectionsプロパティには，TP1インバウンドアダプタからOpenTP1へRPC応答を送信するコネクションの最大同時接続数を設定します。設定値は，RPC受信コネクションの最大同時接続数（max_connectionsプロパティ）と同じ値を設定してください。

trn_max_thread_countプロパティには，TP1インバウンドアダプタのトランザクション連携機能を使用する場合に指定する同期点処理の同時処理数を設定します。設定値は，最大同時RPC要求受け付け数（rpc_max_thread_countプロパティ）と同じ値を設定してください。トランザクション連携機能を使用しない場合は，値はデフォルトのままで問題ありません。

(e)　一時クローズ処理（rpc_sockctl_highwater，rpc_sockctl_lowwater，trn_sockctl_highwater，trn_sockctl_lowwater，ipc_sockctl_watchtime）

一時クローズ処理は，次の表に示すConnector属性ファイルのプロパティに設定します。TP1インバウンドアダプタとOpenTP1の一時クローズ処理の設定項目の対応を次の表に示します。

表4‒20　一時クローズ処理の設定項目の対応

設定項目

TP1インバウンドアダプタのConnector属性ファイルのプロパティ

OpenTP1のシステム共通定義の定義句

RPC受信コネクションの一時クローズ処理開始のしきい値（%）

rpc_sockctl_highwater

ipc_sockctl_highwater※

RPC受信コネクションの一時クローズ処理非対象とするコネクション数の割合（%）

rpc_sockctl_lowwater

ipc_sockctl_highwater※

RPC送信コネクションの一時クローズ処理開始のしきい値（%）

trn_sockctl_highwater

ipc_sockctl_highwater※

RPC送信コネクションの一時クローズ処理非対象とするコネクション数の割合（%）

trn_sockctl_lowwater

ipc_sockctl_highwater※

一時クローズ応答の待ち時間（秒）

ipc_sockctl_watchtime

ipc_sockctl_watchtime

注※

一時クローズ処理のしきい値と一時クローズ処理非対象とするコネクション数の割合をコンマ区切りで指定します。

rpc_sockctl_lowwaterプロパティには，rpc_sockctl_highwaterプロパティの設定値以下の値を設定してください。rpc_sockctl_highwaterプロパティよりも大きい値を設定した場合は，rpc_sockctl_highwaterプロパティと同じ値が設定されます。

trn_sockctl_lowwaterプロパティには，trn_sockctl_highwaterプロパティの設定値以下の値を設定してください。trn_sockctl_highwaterプロパティよりも大きい値を設定した場合は，trn_sockctl_highwaterプロパティと同じ値が設定されます。

また，コネクションの最大同時接続数および一時クローズ処理のしきい値には，小さい値を指定しないでください。コネクションの最大同時接続数（max_connectionsプロパティとtrn_max_connectionsプロパティ）の設定値，および一時クローズ処理のしきい値（rpc_sockctl_highwaterプロパティとtrn_sockctl_highwaterプロパティ）に小さい値を指定すると，一時クローズ処理が多発し，性能に影響を与えたり，通信障害が発生したりするおそれがあります。

(f)　TCP/IPの通信バッファサイズ（receive_buffer_size，send_buffer_size）

TCP/IPの受信バッファサイズは，Connector属性ファイルのreceive_buffer_sizeプロパティに設定します。また，TCP/IPの送信バッファサイズは，Connector属性ファイルのsend_buffer_sizeプロパティに設定します。

バッファサイズを調整する場合，receive_buffer_sizeプロパティの設定値は，OpenTP1のユーザサービス定義のipc_sendbuf_sizeオペランドの設定値に合わせることを推奨します。また，send_buffer_sizeプロパティの設定値は，OpenTP1のユーザサービス定義のipc_recvbuf_sizeオペランドの設定値に合わせることを推奨します。

なお，設定したバッファサイズは，Java SEの仕様上，設定したサイズどおりにならない場合があります。詳細はJava SEのAPIドキュメントを参照してください。

(g)　コネクション切断オプション（rpc_close_after_send）

OpenTP1とTP1インバウンドアダプタ間のコネクションを接続すると，デフォルトの設定ではRPC通信および同期点処理後も接続したままとなります。

RPC通信および同期点処理後にコネクションを切断するには，TP1インバウンドアダプタとOpenTP1のコネクション切断オプションを設定します。

コネクション切断オプションは次のように設定します。

アプリケーションサーバのConnector属性ファイルのrpc_close_after_sendプロパティにtrueを指定

OpenTP1のシステム共通定義のrpc_close_after_send句にYを指定

なお，OpenTP1のrpc_close_after_send句は，ユーザサービス定義にも指定できます。OpenTP1システム全体にコネクション切断オプションを有効にする場合はシステム共通定義に設定してください。サービス単位に有効にする場合はユーザサービス定義に設定してください。

OpenTP1のシステム共通定義とユーザサービス定義の詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

(h)　TCP_NODELAYオプション

OpenTP1とのコネクションの接続で使用するソケットにTCP_NODELAYオプションを使用するかどうかを指定します。TCP_NODELAYオプションを使用すると，Nagleアルゴリズムが無効になるので，送信済みデータの応答待ちの状態でも遅延させることなくデータを送信できます。ただし，TCP_NODELAYオプションを使用することで，INETドメイン通信時の送信効率が低下し，ネットワークの負荷が大きくなる場合があります。

TCP_NODELAYオプションの設定は，Connector属性ファイルのipc_tcpnodelayプロパティに指定します。

なお，このプロパティを指定する場合は，receive_buffer_sizeプロパティ，send_buffer_sizeプロパティ，ネットワークの帯域などを考慮し，この機能の必要性を十分に検討してください。

4.13　OpenTP1での設定

ここでは，次のOpenTP1での設定について説明します。

ユーザサービスネットワーク定義によるスケジューラダイレクトの設定

性能解析トレースの設定

トランザクションの設定

OpenTP1に関する詳細な設定や作業については，OpenTP1のマニュアルを参照してください。

4.13.1　ユーザサービスネットワーク定義によるスケジューラダイレクトの設定

TP1インバウンドアダプタをユーザサービスネットワーク定義によるスケジューラダイレクト機能を使って呼び出すために，次の定義を設定します。

ユーザサービスネットワーク定義

OpenTP1のユーザサービス定義

(1)　ユーザサービスネットワーク定義

ユーザサービスネットワーク定義の設定項目を次の表に示します。

表4‒21　ユーザサービスネットワーク定義の設定項目

設定項目

設定する値

サービスグループ名

TP1インバウンドアダプタのConnector属性ファイルのservice_groupプロパティで定義したサービスグループ名を指定します。

ホスト名

アプリケーションサーバのホスト名を指定します※。

ポート番号

TP1インバウンドアダプタのConnector属性ファイルのscd_portプロパティで定義したポート番号を指定します。

注※　アプリケーションサーバのホスト名については，次の注意事項を参照してください。

注意事項

OpenTP1では，RPC送信元と送信先のIPアドレスを比較し，同一マシンであればUNIXドメイン通信，異なるマシンであればINETドメイン通信を実施します。TP1インバウンドアダプタでは，INETドメイン通信だけをサポートするため，OpenTP1とTP1インバウンドアダプタを同一マシンで利用する場合は，ユーザサービスネットワーク定義のホスト名にはIP alias機能によって割り振った送信元とは異なるIPアドレスを指定してください。

ユーザサービスネットワーク定義の例を次に示します。

dcsvgdef -g ＜サービスグループ名＞ -h ホスト名[:ポート番号]

(2)　OpenTP1のユーザサービス定義

ユーザサービス定義のrpc_destination_modeにdefinitionを設定します。definitionを設定することで，dc_rpc_call関数を呼び出すときに，ユーザサービスネットワーク定義の指定値から宛先を検索するようになります。

ユーザサービス定義の例を次に示します。

set rpc_destination_mode = definition

4.13.2　性能解析トレースの設定

TP1インバウンドアダプタでOpenTP1の性能解析トレース（PRF）の情報を引き継ぐため，システム共通定義に性能解析トレース（PRF）の定義を次の表に示す内容で設定してください。

表4‒22　性能解析トレース（PRF）の設定

設定内容

説明

set prf_trace=Y

性能検証用トレース情報を取得します。

set rpc_prf_trace_level=00010001

OpenTP1のPRF情報をアプリケーションサーバに伝播するために設定します。

4.13.3　トランザクションの設定

トランザクション連携機能を使用する場合，OpenTP1にはTP1インバウンドアダプタとの連携でトランザクションを発生させるように設定する必要があります。

一方，トランザクション連携機能を使用しない場合は，OpenTP1にTP1インバウンドアダプタとの連携でトランザクションを発生させないように設定する必要があります。それぞれのトランザクションの設定について，SUPまたはSSPの場合，およびMHPの場合に分けて表に示します。

表4‒23　トランザクションの設定（SUPまたはSPPの場合）

トランザクション連携の有無

設定内容

説明

ユーザサービス定義

dc_rpc_call関数

トランザクション連携機能を使用する

set atomic_update=Y

引数flagsにDCNOFLAGSを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させ，TP1インバウンドアダプタをトランザクションに含めます。

トランザクション連携機能を使用しない

set atomic_update=Y

引数flagsにDCNOFLAGS | DCRPC_TPNOTRANを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させますが，TP1インバウンドアダプタをトランザクションに含めません。

set atomic_update=N

引数flagsにDCNOFLAGSまたは，DCNOFLAGS | DCRPC_TPNOTRANを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させません。

注　OpenTP1のユーザサービス定義やdc_rpc_call関数の詳細は，マニュアル「OpenTP1 システム定義」またはマニュアル「OpenTP1 プログラム作成の手引」を参照してください。

表4‒24　トランザクションの設定（MHPの場合）

トランザクション連携の有無

設定内容

説明

アプリケーション属性定義

ユーザサービス定義

dc_rpc_call関数

トランザクション連携機能を使用する

mcfaalcapコマンドの-nオプションのtrnmodeオペランドに"trn"を指定します。※

set atomic_update=Y

引数flagsにDCNOFLAGSを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させ，TP1インバウンドアダプタをトランザクションに含めます。

トランザクション連携機能を使用しない

mcfaalcapコマンドの-nオプションのtrnmodeオペランドに"trn"を指定します。※

set atomic_update=Y

引数flagsにDCNOFLAGS | DCRPC_TPNOTRANを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させますが，TP1インバウンドアダプタをトランザクションに含めません。

mcfaalcapコマンドの-nオプションのtrnmodeオペランドに"nontrn"を指定します。

set atomic_update=Y

またはset atomic_update=N

引数flagsにDCNOFLAGSまたはDCNOFLAGS | DCRPC_TPNOTRANを指定します。

呼び出し元のOpenTP1のサービスグループのプロセスでトランザクションを発生させません。

注　OpenTP1のアプリケーション属性定義，ユーザサービス定義やdc_rpc_call関数の詳細は，マニュアル「OpenTP1 システム定義」またはマニュアル「OpenTP1 プログラム作成の手引」を参照してください。

注※　mcfaalcapコマンドの-nオプションのtrnmodeオペランドに"trn"を設定し，set atomic_update=Nを設定した場合，MHPは設定誤りのため異常終了します。

4.14　OpenTP1とアプリケーションサーバ間のタイムアウトの設定

TP1インバウンドアダプタでは，次のタイムアウトを設定できます。

RPC要求受信およびRPC応答送信時のタイムアウト

トランザクションに関するタイムアウト

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

4.14.1　RPC要求受信およびRPC応答送信時のタイムアウト

TP1インバウンドアダプタでは，RPC要求受信およびRPC応答送信時のタイムアウトを設定できます。これにより，ネットワークの障害やOpenTP1の障害などが発生し，RPC通信が待ち状態となった場合に，通信タイムアウトが発生することで障害を検知できます。

また，TP1インバウンドアダプタではMessage-driven Bean（サービス）の実行時間タイムアウトも設定できます。これにより，業務処理で無限ループやデッドロックが発生した場合などに，実行時間タイムアウトによって強制的に業務処理を終了できます。

タイムアウトが設定できるポイントとタイムアウトの有効範囲を次の図に示します。

図4‒19　タイムアウトが設定できるポイントとタイムアウトの有効範囲

次に，この図のタイムアウトが設定できるポイントでのタイムアウトの設定方法について説明します。

(1)　OpenTP1での設定

図4-19の1のポイントと7のポイントのタイムアウトの設定は，OpenTP1で実施します。タイムアウトの設定方法を次の表に示します。

表4‒25　OpenTP1でのタイムアウトの設定方法

図中番号

設定項目

設定ファイル

説明

1

RPC最大応答待ち時間

ユーザサービス定義※

（watch_time）

RPC要求を送信してからサービスの応答が返るまでの待ち時間を秒単位で指定します。

7

TCP受信タイムアウト

ユーザサービス定義※

（ipc_header_recv_time）

データを受信してから通信制御用のデータを受信するまでのタイムアウト時間を秒単位で指定します。

注　タイムアウトが発生した場合，dc_rpc_call関数にはエラーが返されます。タイムアウトが発生した場合のTP1インバウンドアダプタのRPCエラー応答の詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

注※　詳細については，マニュアル「OpenTP1 システム定義」のユーザサービス定義の説明を参照してください。

(2)　アプリケーションサーバの実行環境での設定

図4-19の2のポイントから6のポイントまでのタイムアウトの設定は，アプリケーションサーバの実行環境で実施します。タイムアウトの設定方法を次の表に示します。

表4‒26　アプリケーションサーバの実行環境でのタイムアウトの設定方法

図中番号

設定項目

設定ファイル※1

説明

2

RPC要求の受信タイムアウト

Connector属性ファイル

（rpc_receive_timeoutプロパティ）

OpenTP1から最初の要求電文を受信し始めてから，すべての要求電文の受信を完了するまでのタイムアウト時間を秒単位で指定します。なお，すべての要求電文を受信する前にコネクションが切断されたRPC要求もタイムアウトの対象に含まれます※2。

3

TCP受信タイムアウト

Connector属性ファイル

（tcp_receive_timeoutプロパティ）

要求電文の受信（read）を開始してから完了するまでのタイムアウト時間を秒単位で指定します。

4

サービス実行タイムアウト※3

cosminexus.xml

（<ejb-method-observation-timeout>タグ）

Message-driven Bean（サービス）の実行時間を秒単位で指定します。

cosminexus.xml

（<method-observation-recovery-mode>タグ）

「thread」を指定します。

5

TCP送信コネクション確立タイムアウト

Connector属性ファイル

（connection_timeoutプロパティ）

電文を送信する際，新たにコネクションを接続する場合のコネクション確立処理のタイムアウト時間※4を秒単位で指定します。

6

TCP送信タイムアウト

Connector属性ファイル

（tcp_send_timeoutプロパティ）

応答電文の送信（write）を開始してから完了するまでのタイムアウト時間を秒単位で指定します。

注　タイムアウトが発生した場合，エラーメッセージが出力されます。また，dc_rpc_call関数にはエラーが返されます。タイムアウトが発生した場合のTP1インバウンドアダプタのRPCエラー応答の詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

注※1　属性ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

注※2　分割された要求電文の受信中はTCP受信タイムアウトのチェックが優先されるため，RPC要求の受信タイムアウトは発生しません。また，Connector属性ファイルのrpc_receive_timeout_intervalプロパティに指定した時間の分，タイムアウトの発生が遅れる場合があります。

注※3　サービス実行のタイムアウトには，アプリケーションサーバのメソッドキャンセル機能を使用します。タイムアウトが発生した場合，Message-driven Bean（サービス）は，EJB仕様で定められたシステム例外が発生した場合と同等の動作をしたあとで，OpenTP1にRPCエラーを応答します。

注※4　RPC応答送信時のコネクション確立処理のタイムアウト時間は，Connector属性ファイルのconnection_timeoutプロパティに設定します。タイムアウト発生時，コネクション確立処理はリトライしないでRPC応答送信を終了します。ただし，OSに設定されているTCP通信のタイムアウト値によっては，Connector属性ファイルのconnection_timeoutプロパティの設定時間よりも早くコネクション確立処理がタイムアウトすることがあります。この場合，Connector属性ファイルのsend_retry_countプロパティとsend_retry_intervalプロパティの設定値に従って，コネクション確立処理をリトライします。TCP通信のタイムアウトについては，OSのドキュメントを参照してください。

4.14.2　トランザクションに関するタイムアウト

TP1インバウンドアダプタでは，トランザクションを開始してから決着処理を開始するまでのタイムアウトを設定できます。タイムアウトを設定しておくことで，ネットワークの障害やOpenTP1の障害などが発生して，トランザクションが決着できない場合に，自動でロールバックできます。

OpenTP1での設定，およびトランザクションに関するタイムアウトの有効範囲と設定方法を次に示します。

図4‒20　トランザクションに関するタイムアウトの有効範囲

(1)　OpenTP1での設定

図4-20の1のポイントから3のポイント，および6のポイントのタイムアウトの設定は，OpenTP1で実施します。タイムアウトの設定方法を次の表に示します。

表4‒27　OpenTP1でのタイムアウトの設定方法

図中番号

設定項目

設定ファイル※

説明

1

トランザクション完了限界時間

ユーザサービス定義

（trn_completion_limit_time）

トランザクションの開始から終了までの時間を指定します。

2

トランザクションブランチ限界経過時間

ユーザサービス定義

（trn_expiration_time）

トランザクションの開始から同期点処理を開始するまでの時間を指定します。

3

RPC最大応答待ち時間

ユーザサービス定義

（watch_time）

RPC要求を送信してからサービスの応答が返るまでの待ち時間を秒単位で指定します。

6

トランザクション同期点処理時の最大通信待ち時間

ユーザサービス定義

（trn_watch_time）

トランザクションの同期点処理で，トランザクションブランチ間の通信の受信待ち時間を指定します。

注　タイムアウトが発生した場合，dc_rpc_call関数にエラーが返されます。タイムアウトが発生した場合のTP1インバウンドアダプタのRPCエラー応答の詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

注※　ユーザサービス定義の詳細については，マニュアル「OpenTP1 システム定義」のユーザサービス定義の説明を参照してください。

(2)　アプリケーションサーバの実行環境での設定

図4-20の4のポイントおよび5のポイントのタイムアウトの設定は，アプリケーションサーバの実行環境で実施します。タイムアウトの設定方法を次の表に示します。

表4‒28　アプリケーションサーバの実行環境でのタイムアウトの設定方法

図中番号

設定項目

設定ファイル※1

説明

4

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

cosminexus.xml

（<ejb-transaction-timeout>タグ）

アプリケーションサーバ内でのトランザクション開始からトランザクション決着処理開始までの時間を指定します。

J2EEサーバ用ユーザプロパティファイル

（ejbserver.jta.TransactionManager.defaultTimeOut）

5

サービス実行タイムアウト※2

cosminexus.xml

（<ejb-method-observation-timeout>タグ）

Message-driven Bean（サービス）の実行時間を秒単位で指定します。

cosminexus.xml

（<method-observation-recovery-mode>タグ）

「thread」を指定します。

注　タイムアウトが発生した場合，エラーメッセージが出力されます。また，dc_rpc_call関数にエラーが返されます。タイムアウトが発生した場合のTP1インバウンドアダプタのRPCエラー応答の詳細については，「4.17　TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

注※1　cosminexus.xmlの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。なお，J2EEサーバ用ユーザプロパティファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

注※2　サービス実行タイムアウトは，アプリケーションサーバのメソッドキャンセル機能を使用します。メソッドキャンセル機能の詳細は，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.2　J2EEアプリケーション実行時間の監視とは」を参照してください。

4.15　TP1インバウンドアダプタとMessage-driven Bean（サービス）の開始と終了

TP1インバウンドアダプタとMessage-driven Bean（サービス）の開始と終了は，次の手順で実施してください。

TP1インバウンドアダプタを開始します。

Message-driven Bean（サービス）を開始します。

Message-driven Bean（サービス）を終了します。

TP1インバウンドアダプタを終了します。

ここでは，TP1インバウンドアダプタとMessage-driven Bean（サービス）の開始と終了について説明します。

4.15.1　TP1インバウンドアダプタの開始と終了

TP1インバウンドアダプタの開始と終了について説明します。

(1)　TP1インバウンドアダプタの開始

TP1インバウンドアダプタは，cjstartrarコマンドで開始します。

TP1インバウンドアダプタを開始すると，Connector属性ファイルの定義内容が読み込まれます。

service_groupプロパティが不正な場合，エラーメッセージを出力してTP1インバウンドアダプタの開始処理を終了します。出力するメッセージを次に示します。

service_groupプロパティが指定されていない場合

エラーメッセージ（KDJE58302-E）

設定範囲外の値を指定した場合

エラーメッセージ（KDJE58300-E）

すでに同じ名前のサービスグループ名のTP1インバウンドアダプタが開始済みの場合

エラーメッセージ（KDJE58303-E）

そのほかのConnector属性ファイルの定義が不正な場合

警告メッセージ（KDJE58301-W）を出力し，デフォルト値を適用してTP1インバウンドアダプタの開始処理を続行します。

TP1インバウンドアダプタの開始によって，リソースアダプタのConnector属性ファイルに指定した番号のポートが開かれ，RPC通信の待ち受けが開始されます。

指定した番号のポートが開けない場合，エラーメッセージが出力されて，TP1インバウンドアダプタの開始に失敗します。Connector属性ファイルに指定するプロパティについては，「4.12.2　リソースアダプタの設定」を参照してください。

なお，TP1インバウンドアダプタを開始した時点では，RPC通信を待ち受けるポートは開いていますが，Message-driven Bean（サービス）は開始していません。Message-driven Bean（サービス）が開始していない状態で，OpenTP1からRPC要求を受信した場合は，エラーメッセージが出力されてRPCエラーが返されます。

(2)　TP1インバウンドアダプタの終了

TP1インバウンドアダプタは，cjstoprarコマンドで終了します。

TP1インバウンドアダプタを終了する場合，TP1インバウンドアダプタを使用しているすべてのMessage-driven Bean（サービス）をあらかじめ停止しておいてください。

TP1インバウンドアダプタは，次に示す手順に沿って終了してください。

TP1インバウンドアダプタを使用しているすべてのMessage-driven Bean（サービス）を停止します。

Message-driven Bean（サービス）が使用していたすべてのOutboundのリソースアダプタ（DBConnector）を停止します。

TP1インバウンドアダプタを終了します。

TP1インバウンドアダプタの終了時にMessage-driven Bean（サービス）が起動されている場合は，エラーメッセージ（KDJE48547-E）が出力され，TP1インバウンドアダプタの終了に失敗します。なお，正常に終了した場合は，ログファイルにKDJE58351-Iが出力されます。

トランザクション連携機能を使用している場合，手順3.を手順2.の先に実施すると，OpenTP1とアプリケーションサーバに未決着のトランザクションが残ってしまうおそれがあります。この場合，TP1インバウンドアダプタを再開始し，未決着のトランザクションを決着させてください。詳細は「4.9.8(4)　通信障害が発生した場合」を参照してください。

4.15.2　Message-driven Bean（サービス）の開始と終了

Message-driven Bean（サービス）の開始と終了について説明します。

注意事項

TP1インバウンド連携機能使用時にMessage-driven Beanをリロードする場合は，OpenTP1からのRPCの発行を止めてからリロードしてください。リロード中にRPCを発行した場合は，Message-driven Beanは終了していると見なされ，RPCの発行元にはエラー応答が返ります。

(1)　Message-driven Bean（サービス）の開始

TP1インバウンドアダプタを使用するJ2EEアプリケーションをcjstartappコマンドで起動すると，Message-driven Bean（サービス）は開始します。

ActivationSpecの設定値が不正な場合，エラーメッセージが出力され，Message-driven Bean（サービス）の起動は失敗します。ActivationSpecの設定については，「4.10.5　ejb-jar.xmlの定義」を参照してください。

(2)　終了

Message-driven Bean（サービス）は，TP1インバウンドアダプタを使用するJ2EEアプリケーションが次のどちらかで停止した場合に終了します。

cjstopappコマンドで通常停止した場合

cjstopappコマンドの-forceオプションまたは-cancelオプションを指定して強制停止した場合

Message-driven Bean（サービス）の終了処理中は，新たなRPC電文を受け付けないようにスケジュールキューは停止されます。また，未処理のRPC要求と実行中のMessage-driven Bean（サービス）は次のように処理されます。

新たに受信した未処理のRPC要求

リクエスト受け付けスレッドが受け付けたRPC要求です。RPC要求を破棄して，OpenTP1にRPCエラーを応答します。

RPCエラーコードとしてDCRPCER_NO_SUCH_SERVICE（-311）が返され，エラーメッセージが出力されます。

受信済みの未処理のRPC要求

スケジュールキューに登録済みのRPC要求です。RPC要求を破棄して，OpenTP1にRPCエラーを応答します。

RPCエラーコードとしてDCRPCER_SERVICE_TERMINATING（-313）が返され，エラーメッセージが出力されます。

実行中のMessage-driven Bean（サービス）

停止種別によって処理が次のように異なります。

通常停止の場合

終了するまで待機します。

強制停止の場合

強制終了（メソッドキャンセル）されます。

RPCエラーコードにDCRPCER_TIMED_OUT（-307）が返され，エラーメッセージが出力されます。

強制終了（メソッドキャンセル）は，Message-driven Bean（サービス）実行中にだけ実行できます。なお，保護区では強制終了（メソッドキャンセル）できません。

参考

正常に開始／終了した場合は，ログファイルにメッセージが出力されます。

4.16　性能解析トレース情報の引き継ぎ

TP1インバウンドアダプタを使用してOpenTP1のSUPからアプリケーションサーバ上の業務を呼び出す場合に，OpenTP1のSPPを呼び出す場合と同様に性能解析情報を引き継ぎ，OpenTP1とアプリケーションサーバの処理を突き合わせることができます。

この節では，性能解析情報を引き継ぐための準備，OpenTP1とアプリケーションサーバの性能解析情報の対応，および性能解析情報を突き合わせる方法について説明します。

4.16.1　性能解析情報を引き継ぐための準備

性能解析情報を引き継ぐ場合，OpenTP1のシステム共通定義に次の設定が必要です。

set prf_trace=Y

set rpc_prf_trace_level=00010001

これらの定義がある場合，OpenTP1，アプリケーションサーバ間で性能解析情報が引き継がれます。

性能解析情報の引き継ぎ有無と性能解析情報で確認できる処理の範囲を次の図に示します。

図4‒21　性能解析情報の引き継ぎ有無と性能解析情報で確認できる処理の範囲

4.16.2　性能解析情報の対応

TP1インバウンドアダプタのRPC通信機能では，性能解析情報の引き継ぎが有効な場合，RPC要求電文を解析するときにOpenTP1のRPC要求電文に設定されている性能解析情報を取得して，アプリケーションサーバの性能解析情報として使用します。具体的には，TP1インバウンドアダプタの処理の延長で出力されるRootAP IPとRootAP CommNo.に，OpenTP1の呼び出し元のIPとルートRPC通信番号がそれぞれ引き継がれます。

引き継がれる情報の対応を次の表に示します。

表4‒29　引き継がれる情報の対応

アプリケーションサーバの性能解析情報

引き継ぎ元のOpenTP1の性能解析情報

RootAP IP

呼び出し元のOpenTP1のIP

RootAP PID

0000（固定）

RootAP CommNo.

呼び出し元のOpenTP1のルートRPC通信番号

また，TP1インバウンドアダプタの入り口で出力されるPRFトレース（0xAA00）では，RootAP IPとRootAP CommNo.に加えて，オプション文字列（OPT）にOpenTP1のルートRPCノード識別子などが出力されます。

PRFトレース（0xAA00）で出力される情報を次の表に示します。

表4‒30　PRFトレース（0xAA00）で出力される情報

アプリケーションサーバの性能解析情報

引き継ぎ元のOpenTP1の性能解析情報

RootAP IP

呼び出し元のOpenTP1のIP

RootAP PID

0000（固定）

RootAP CommNo.

呼び出し元のOpenTP1のルートRPC通信番号

INT

サービスグループ名

OPR

サービス名

OPT

呼び出し元のOpenTP1のルートRPCノード識別子（4文字）。なお，トランザクショナルRPCの場合は，ノード識別子のあとにトランザクショングローバル識別子。

これらの情報を使用して性能解析情報を突き合わせることで，OpenTP1とアプリケーションサーバ間での処理を追跡できます。

また，性能解析トレース情報の引き継ぎはトランザクション連携機能を使用する場合と使用しない場合とで異なります。それぞれの場合の性能解析トレース情報の引き継ぎについて説明します。

4.16.3　トランザクション連携機能を使用しない場合の性能解析トレース情報の引き継ぎ

トランザクション連携機能を使用しない場合の性能解析トレース情報の引き継ぎについて説明します。ここでは，アプリケーションサーバの性能解析情報と引き継ぎ元のOpenTP1の性能解析情報を突き合わせることによって，OpenTP1とアプリケーションサーバ間でのRPC通信を追跡する例を示します。

RPCの実行によって突き合わせ可能な範囲を次の図に示します。

図4‒22　RPCの実行によって突き合わせ可能な範囲

OpenTP1のdc_rpc_call関数でのサービス要求の送信直前，およびdc_rpc_call関数のリターン直前のPRFトレースと，アプリケーションサーバのPRFトレースの突き合わせの例を次の図に示します。

図4‒23　突き合わせの例

OpenTP1のルートOpenTP1識別子は，アプリケーションサーバのPRFトレースの0xAA00，0xAA06のOPT（ASCII列）に出力されます。

なお，OpenTP1のルート通信番号とアプリケーションサーバのRootAP情報は，通信番号のけたが異なります。このため，数値は同じですが，文字列としては一致しません。

4.16.4　トランザクション連携機能を使用する場合の性能解析トレース情報の引き継ぎ

トランザクション連携機能を使用する場合の性能解析トレース情報の引き継ぎについて説明します。ここでは，アプリケーションサーバの性能解析情報と引き継ぎ元のOpenTP1の性能解析情報を突き合わせることによって，OpenTP1とアプリケーションサーバ間でのRPC通信を追跡する例を示します。

RPCおよび同期点処理の実行によって突き合わせ可能な範囲を次の図に示します。

図4‒24　RPCおよび同期点処理の実行によって突き合わせ可能な範囲

次に示す性能解析トレース情報を突き合わせて，トレース情報を追跡します。

RPC要求を受信したときのOpenTP1とTP1インバウンドアダプタ間の性能解析トレース情報

アプリケーションサーバの性能解析情報と引き継ぎ元のOpenTP1の性能解析情報を突き合わせます。詳細は「4.16.3　トランザクション連携機能を使用しない場合の性能解析トレース情報の引き継ぎ」を参照してください。

同期点処理時のOpenTP1とTP1インバウンドアダプタ間の性能解析トレース情報

トランザクショングローバル識別子を突き合わせます。詳細は「4.16.4(1)　同期点処理でのOpenTP1とTP1インバウンドアダプタ間の性能解析トレース情報の突き合わせ」を参照してください。

アプリケーションサーバ内でのRPC要求受信時と同期点処理時の間の性能解析トレース情報

PRFトレース（0xAA00）で出力したトランザクショングローバル識別子，および同期点処理時に出力するトランザクショングローバル識別子を突き合わせます。詳細は「4.16.4(2)　RPC要求と同期点処理間の性能解析トレース情報の突き合わせ」を参照してください。

(1)　同期点処理でのOpenTP1とTP1インバウンドアダプタ間の性能解析トレース情報の突き合わせ

同期点処理では，OpenTP1から引き継がれるトランザクショングローバル識別子を突き合わせます。アプリケーションサーバの性能解析情報と引き継ぎ元のOpenTP1の性能解析情報を突き合わせることによって，OpenTP1とアプリケーションサーバ間での同期点処理を追跡する例を示します。

図4‒25　同期点処理でのPRFトレースの突き合わせの例

OpenTP1のPRF（プリペアメッセージの送信時の場合は0x4000）のTrnの先頭16文字と，0xAA14のOPT（ASCII列）を突き合わせます。

また，0xAA14のRootAP情報のIPアドレス，およびINTに出力する送信元のノード識別子もOpenTP1のPRFと突き合わせます。

応答も同様に0xAA14のOPT（ASCII列）とOpenTP1のPRF（プリペア完了メッセージの受信時であれば0x4003）のTrnの先頭16文字と突き合わせます。

(2)　RPC要求と同期点処理間の性能解析トレース情報の突き合わせ

RPC要求と同期点処理間のPRFトレースは，0xAA00で出力したOPT（ASCII列）の5文字目から20文字目のトランザクショングローバル識別子と，同期点処理時に出力される0xAA14のOPT（ASCII列）のトランザクショングローバル識別子を突き合わせます。

RPC要求と同期点処理間のPRFトレースの突き合わせの例を次に示します。

図4‒26　RPC要求と同期点処理間のPRFトレースの突き合わせの例

4.17　TP1インバウンドアダプタで発生するRPCエラー応答

この節では，それぞれのRPCエラー応答について説明します。

なお，ここで説明しているエラー応答の一覧には，TP1インバウンドアダプタに対してRPC要求が送信された場合に発生するものだけを記載しています。OpenTP1側で発生するエラー応答については，マニュアル「OpenTP1 プログラム作成リファレンス C言語編」のdc_rpc_callのリターン値に関する説明を参照してください。

TP1インバウンドアダプタのRPCエラー応答一覧を次の表に示します。

表4‒31　RPCエラー応答一覧

dc_rpc_call関数の戻り値

発生原因

TP1インバウンドアダプタの出力メッセージ

DCRPCER_NO_BUFS(-304)

TP1インバウンドアダプタの電文組み立てリストが不足している状態で，TP1インバウンドアダプタへトランザクショナルRPCではないRPC要求を送信した場合

KDJE58359-E

TP1インバウンドアダプタのスケジュールキューの電文滞留数が最大キュー長（Message-driven Bean（サービス）のDDのqueue_max_lengthプロパティ）に達している状態で，TP1インバウンドアダプタへRPC要求を送信した場合

KDJE58360-E

DCRPCER_NET_DOWN(-306)

TP1インバウンドアダプタへRPC要求を送信する際にコネクションを確立できなかった場合

−

TP1インバウンドアダプタのbacklog_countプロパティの設定数だけListenキューにコネクション確立要求が滞留している状態で，TP1インバウンドアダプタへRPC要求を送信した場合

−

TP1インバウンドアダプタへRPC要求を送信中にコネクションが切断された場合

KDJE58354-E

OpenTP1のスケジューラダイレクト機能を使用しないでTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58355-E 詳細情報：

Scheduler direct function is not used.

TP1インバウンドアダプタの電文組み立てリストが不足している状態で，TP1インバウンドアダプタへRPC要求を送信した場合

KDJE58359-E

TP1インバウンドアダプタへRPC要求を送信中に，TP1インバウンドアダプタの電文読み込み処理がタイムアウトした場合

KDJE58354-E

TP1インバウンドアダプタへRPC要求を送信中に，TP1インバウンドアダプタのRPC要求を受信し始めてから受信し終わるまでの時間がタイムアウトした場合

KDJE58358-E

TP1インバウンドアダプタがOpenTP1からのRPC要求ではない電文を受信した場合（プロトコルエラー）

KDJE58355-E 詳細情報：

It is not the first request data.

DCRPCER_TIMED_OUT(-307)

TP1インバウンドアダプタへRPC要求を送信中に，TP1インバウンドアダプタの電文読み込み処理がタイムアウトした場合

KDJE58354-E

TP1インバウンドアダプタへRPC要求を送信中に，TP1インバウンドアダプタのRPC要求を受信し始めてから受信し終わるまでの時間がタイムアウトした場合

KDJE58358-E

Message-driven Bean（サービス）の実行中にMessage-driven Bean（サービス）の実行時間タイムアウトが発生した場合

KDJE58457-E

TP1インバウンドアダプタがOpenTP1へRPC応答を送信する際のコネクション確立要求でタイムアウトが発生した場合

KDJE58400-E

TP1インバウンドアダプタがOpenTP1へRPC応答を送信する際の電文書き込み処理でタイムアウトが発生した場合

KDJE58401-E

dc_rpc_call関数の引数flagsにDCNOFLAGSかDCRPC_TPNOTRAN以外を指定してTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58356-E 詳細情報：

The value of the flags argument of the dc_rpc_call function is illegal.

OpenTP1のスケジューラダイレクト機能を使用しないでTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58355-E 詳細情報：Scheduler direct function is not used.

Message-driven Bean（サービス）の実行中にMessage-driven Bean（サービス）を強制終了（cjstopappコマンドの-force， -cancelオプション）した場合

KDJE58455-E

TP1インバウンドアダプタへRPC要求を送信中にコネクションが切断された場合

KDJE58354-E

TP1インバウンドアダプタがOpenTP1へRPC応答を送信する際にコネクションを確立できなかった場合

KDJE58400-E

TP1インバウンドアダプタがOpenTP1へRPC応答を送信する際の電文書き込み処理でエラーが発生した場合

KDJE58401-E

TP1インバウンドアダプタがOpenTP1からのRPC要求ではない電文を受信した場合（プロトコルエラー）

KDJE58355-E 詳細情報：

It is not the first request data.

DCRPCER_NO_SUCH_SERVICE(-311)

dc_rpc_call関数の引数serviceに不正なサービス名を指定してTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58362-E

Message-driven Bean（サービス）が開始していない，または終了中にTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58362-E

DCRPCER_SERVICE_TERMINATING(-313)

Message-driven Bean（サービス）が開始していない，または終了中にTP1インバウンドアダプタのスケジュールキューに登録されていたRPC要求が処理された場合

KDJE58456-E

DCRPCER_SERVICE_NOT_UP(-314)

dc_rpc_call関数の引数groupに不正なサービスグループ名を指定してTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58357-E※

DCRPCER_SYSERR_AT_SERVER(-316)

未サポートバージョンのOpenTP1からTP1インバウンドアダプタへトランザクショナルRPCではないRPC要求を送信した場合

KDJE58356-E 詳細情報：

Version of OpenTP1 is not supported.

OpenTP1でユーザデータ圧縮機能（システム共通定義のrpc_datacompオペランドにY）を使用してTP1インバウンドアダプタへトランザクショナルRPCではないRPC要求を送信した場合

KDJE58356-E 詳細情報：

User data compression function is not supported.

TP1インバウンドアダプタへトランザクショナルRPCではないRPC要求をした際に，Message-driven Bean（サービス）の実行中に例外が発生した場合，またはMessage-driven Bean（サービス）の実行結果に出力データを設定していない，もしくはJ2EEサーバでシステム例外が発生した場合

KDJE58459-E

DCRPCER_NO_BUFS_RB(-323)

TP1インバウンドアダプタの電文組み立てリストが不足している状態で，TP1インバウンドアダプタへトランザクショナルRPC要求を送信した場合

KDJE58359-E

DCRPCER_SYSERR_AT_SERVER_RB(-325)

未サポートバージョンのOpenTP1から，TP1インバウンドアダプタへトランザクショナルRPC要求を送信した場合

KDJE58356-E 詳細情報：

Version of OpenTP1 is not supported.

OpenTP1でユーザデータ圧縮機能（システム共通定義のrpc_datacompオペランドにY）を使用してTP1インバウンドアダプタへトランザクショナルRPC要求を送信した場合

KDJE58356-E 詳細情報：

User data compression function is not supported.

TP1インバウンドアダプタへトランザクショナルRPC要求をした際に，Message-driven Bean（サービス）の実行中に例外が発生した場合，または，Message-driven Bean（サービス）の実行結果に出力データを設定していない，または，J2EEサーバでシステム例外が発生した場合

KDJE58459-E

DCRPCER_TESTMODE(-366)

OpenTP1でオンラインテスタを使用してTP1インバウンドアダプタへRPC要求を送信した場合

KDJE58356-E 詳細情報：

TP1/Online Tester is not supported.

DCRPCER_TRNCHK_EXTEND(-372)

OpenTP1とのトランザクション連携でライトトランザクション（usrconf.propertiesのejbserver.distributedtx.XATransaction.enabledプロパティがfalse）の場合

−

（凡例）　−：該当なし

注※

サービスグループ名が不正の場合，OpenTP1はRPC要求を再送します。そのため，このエラーメッセージは，OpenTP1から再送された回数分だけ出力されます。

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

この章では，JPAの概要とアプリケーションサーバでのJPAの利用について説明します。

5.1　この章の構成

JPAとは，データベース関連処理の設計およびコーディングの簡略化を目的として，Javaのオブジェクトとリレーショナルデータベースとのマッピング（O/Rマッピング）に関して定められた仕様です。JPAを使用することで，ユーザはデータベースの持つ情報をJavaのオブジェクト（エンティティ）として操作できるため，効率良くシステムを構築できます。

この章では，JPAの概要と，アプリケーションサーバでのJPAの利用について説明します。この章の構成を次の表に示します。

表5‒1　この章の構成（アプリケーションサーバでのJPAの利用）

分類

タイトル

参照先

解説

JPAの特長

5.2

アプリケーションサーバで使用できるJPAの機能

5.3

EntityManagerとは

5.4

永続化コンテキストとは

5.5

実装

コンテナ管理のEntityManagerを取得する方法

5.6

アプリケーション管理のEntityManagerを取得する方法

5.7

persistence.xmlでの定義

5.8

persistence.xmlの配置

5.9

注意事項

アプリケーション設定時の注意事項

5.10

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

5.2　JPAの特長

ここでは，JPAを使用したアプリケーションの特長について説明します。

5.2.1　JPAを使用したアプリケーションの利点

JPAを利用したアプリケーションを使用すると，次に示すことが実現できます。

O/Rマッピングやデータベースアクセス処理の隠蔽によって，ユーザプログラミングが容易になります。

アノテーションを利用することで，定義ファイル作成コストを削減し，POJO（Plain Old Java Object）によるコーディングが実現します。

デフォルト値の設定によって，ユーザのコーディング量が削減できます。

ここでは，JPAを使用しない場合とJPAを使用する場合のデータアクセスモデルを比較して，JPAを使用したアプリケーションの利点を説明します。

(1)　JPAを使用しない場合のデータアクセスモデル

JPAを使用しない場合，J2EEアプリケーションからデータベースにアクセスするには，一般的に，次の図に示すようなデータアクセスモデルを使用してアプリケーションを作成します。

図5‒1　JPAを使用しない場合のデータベースアクセスモデル

上記の図について説明します。

図の場合のデータアクセスモデルでは，SQLをビジネスロジックから隠蔽するために，テーブルに対応するDAOと呼ばれるクラスを作成します。DAOクラスの中に，JDBCインタフェースでSQLを発行する処理を作成します。図の流れについて説明します。

ビジネスロジックを記述してあるEJBでは，DAOを使用してデータベースからデータを読み出します。

取得したデータをDTOと呼ばれるオブジェクトに格納します。

DTOオブジェクトをWebコンポーネントに返します。Webコンポーネントではデータベースから取得したデータをWebページに出力します。

このようなデータアクセスモデルでは，データベースのデータモデルが大きく複雑になると，作成しなければならないDAO，SQL，DTOクラスの量も多くなります。DAO，SQL，およびDTOの作成は単調な手作業のため，アプリケーション開発の生産性を低下させる原因となります。

(2)　JPAを使用した場合のデータアクセスモデル

JPAを使用した場合のデータアクセスモデルは次に示す図のようになります。

図5‒2　JPAを使用した場合のデータベースアクセスモデル

JPAを使用した場合，データベースのテーブルの行に対応したクラスを作成します。これを，エンティティクラスといいます。ビジネスロジックを記述してあるEJBでは，このエンティティクラスのオブジェクトを直接データベースに格納するかのように，処理を記述できます。

図について説明します。

JPAプロバイダと呼ばれるJPAのエンジンがデータベースに対してSQLを発行します。また，JPAプロバイダがエンティティオブジェクトとデータベースのテーブルの状態を自動的に同期を取ります。

エンティティオブジェクトは，取得したデータをそのままWebコンポーネントに渡すことができます。

このように，JPAを使用するとDTOを作成する必要はありません。また，エンティティクラスは，Eclipseなどの開発ツールを使用してデータベースのテーブルスキーマから自動的に生成することもできます。従来のデータアクセスモデルで生産性を低下させる原因となっていたDAO，SQL，DTOを作成する必要がないため，従来よりもアプリケーションの生産性を向上させることができます。

なお，エンティティクラスおよびJPAプロバイダについては，「5.2.2　エンティティクラスとは」および「5.2.3　JPAプロバイダとは」を参照してください。

5.2.2　エンティティクラスとは

JPAを使用する場合，アプリケーションではデータの入れ物となるクラスを作成します。これをエンティティクラスといいます。通常，エンティティクラスを作成する際には，エンティティクラスの一つのオブジェクトがデータベースのテーブルの一行に対応するように作成します。エンティティクラスは，普通のJavaクラス（POJO）で作成します。特別なインタフェースをインプリメントする必要はありません。

エンティティクラスのフィールドの値をデータベーステーブルのどのカラムに格納するのかといったマッピングは，エンティティクラスのフィールドなどにアノテーションを使用して指定します。ただし，JPAには開発容易性を向上させるためにCoCの考え方が取り入れられており，マッピングを明示的に指定しなくてもデフォルトでマッピングが行われるルールがあります。例えば，フィールドのマッピングを明示的に指定していない場合，フィールド名から対応するカラムが推定されてマッピングされます。

5.2.3　JPAプロバイダとは

JPAプロバイダとは，次に示すマッピング機能，API，およびクエリ言語を提供するJPA実装です。JPAプロバイダでは次の機能を提供しています。

Javaオブジェクトとデータベースのマッピング機能

データベースへの処理をカプセル化したAPI

JPA仕様で共通に使用できるクエリ言語

JPAプロバイダを使用すると，データベースとのやり取りに関する処理を意識しないでアプリケーションを設計できるという利点があります。また，JPAプロバイダで利用できるJPQLというクエリ言語を使用することで，データベースに詳しくなくてもクエリを送信できるという利点もあります。

JPAプロバイダが提供するマッピング機能について次の図に示します。

図5‒3　JPAプロバイダが提供するマッピング機能の概要

図について説明します。

アプリケーション内にエンティティクラスを用意し，エンティティクラスからエンティティオブジェクトを生成します。ユーザは，エンティティオブジェクトの内容を変更することで，データベースの内容を変更します。これによって，データベースへの処理を意識しないで，データベースの内容を更新できます。

JPAプロバイダは，エンティティオブジェクトをデータベースのレコードとマッピングします。ユーザが実施した検索，挿入，削除，または更新の処理をデータベースに対して実行します。

生成されたエンティティオブジェクトはEntityManagerの管理下に置かれます。エンティティオブジェクトのフィールドの値が変更されると，EntityManagerは変更を自動的に検知して，変更をデータベースのテーブルに反映します。

EntityManagerは次の処理をするときに呼び出されます。

エンティティクラスのオブジェクトのデータをデータベースのテーブルに追加する。

データベースにすでに格納されているデータを検索してエンティティクラスのオブジェクトとして取り出す。

EntityManagerの詳細については，「5.4　EntityManagerとは」を参照してください。

5.3　アプリケーションサーバで使用できるJPAの機能

ここでは，JPAを利用する場合に，アプリケーションサーバで使用できるJPAプロバイダ，コンポーネント，リソースアダプタなどについて説明します。

5.3.1　使用できるJPAプロバイダ

JPAプロバイダとはEntityManagerの機能を提供するエンジンのことです。

JPA仕様でJPAプロバイダとアプリケーションサーバの間のインタフェースが明確にされているため，アプリケーションサーバではほかのベンダが提供しているJPA 2.1仕様に準拠したJPAプロバイダを利用することもできます。

アプリケーションサーバからほかのベンダのJPAプロバイダを利用する場合は，次の設定が必要になります。

JARファイルの指定

次のどちらかの方法でJPAプロバイダの実装が含まれるJARファイルを指定します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ下にJARファイルを指定します。JARファイルを指定するには，<param-name>タグにadd.class.path，<param-value>タグにJARファイルを指定します。なお，簡易構築定義ファイルおよび指定するパラメタの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

ライブラリとしてJ2EEアプリケーションに含めます。

persistence.xmlでの定義

persistence.xmlの<provider>タグに，利用するJPAプロバイダが提供するjavax.persistence.PersistenceProviderの実装クラス名を指定します。詳細については，「5.8.2(2)　<provider>タグ」を参照してください。

また，アプリケーションサーバで提供するJ2EEアプリケーション実行時間の監視機能を使用する場合は，JPAプロバイダのクラスおよびエンティティクラスを保護区リストに追加する必要があります。保護区リストへの追加方法については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「2.2.5　criticalList.cfg（保護区リストファイル）」を参照してください。

参考

JPAを使用したアプリケーションの実行では，アプリケーションサーバで提供する性能解析トレース機能を使用できます。なお，アプリケーションサーバでは，javax.persistenceパッケージのEntityManagerFactory，EntityManager，EntityTransaction，およびQueryのAPIで性能解析トレースを出力します。

性能解析トレースの概要については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.2.1　アプリケーションサーバの性能解析トレースの概要」を参照してください。性能解析トレースの出力ポイントについては，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.　性能解析トレースのトレース取得ポイントとPRFトレース取得レベル」を参照してください。

5.3.2　使用できるコンポーネント

アプリケーションサーバでは，EJB，WebアプリケーションでJPAを使用できます。また，Webアプリケーションからユーザスレッドを使用した場合も，JPAを使用できます。なお，次に示す環境またはライブラリではJPAを使用できません。

EJBクライアントアプリケーション環境

J2EEアプリケーションクライアント環境

コンテナ拡張ライブラリ

JPAを使用できるコンポーネントを次の表に示します。

表5‒2　JPAを使用できるコンポーネント

コンポーネント

JPAの使用

EJB

Stateless Session Bean（EJB3.0以降）※1

○

Stateful Session Bean（EJB3.0以降）※1

○

Stateless Session Bean（EJB3.0より前）

×

Stateful Session Bean（EJB3.0より前）

×

Singleton Session Bean

×

EJBに関連づくインターセプタ※1※3

○

Message-driven Bean

×

Entity Bean

×

CDI Managed Bean（EJBに注入される場合）と，それに関連づくインターセプタ※4

○

Webアプリケーション

サーブレット，フィルタ，イベントリスナ（Servlet2.5以降）

○

JSP，JSPのタグハンドラ，JSPのイベントリスナ，JSPのタグライブラリイベントリスナ※2（Servlet2.5以降）

○

サーブレット，フィルタ，イベントリスナ（Servlet2.5より前）

×

JSP，JSPのタグハンドラ，JSPのイベントリスナ，JSPのタグライブラリイベントリスナ（Servlet2.5より前）

×

CDI Managed Bean（Webコンポーネントに注入される場合）と，それに関連づくインターセプタ※4

○

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

注※1　アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，@PersistenceUnitや@PersistenceContextなどのアノテーションを使用して，永続化ユニットや永続化コンテキストの参照を定義してください。

注※2　アプリケーションサーバでは，JSPタグライブラリイベントリスナでのアノテーションの使用はできません。JSPタグライブラリイベントリスナでJPAの機能を使用する場合は，web.xmlの<persistence-unit-ref>タグや<persistence-context-ref>タグを使用して永続化ユニットや永続化コンテキストの参照を定義してください。

注※3　AroundConstructに関する非サポート機能については，「15.4　非サポート機能」を参照してください。

注※4　詳細は「5.3.3　CDI Managed BeanでのJPA利用」を参照してください。

注意事項

Servlet 2.5以降のweb.xmlのmetadata-complete属性にtrueが設定されている場合，Webコンポーネントのアノテーションが読み込まれません。このため，アノテーションを使用して，永続化コンテキストまたは永続化ユニットの参照を定義することはできません。ただし，web.xmlに参照を定義することはできます。

5.3.3　CDI Managed BeanでのJPA利用

11-10以降では，EJBやWebコンポーネントに注入されるCDI Managed BeanでのJPAの利用をサポートします。ただし，シングルトンセッションビーンに注入されるCDI Managed BeanでのJPAの利用はサポートしません。

サポート範囲を次の表に示します。

EntityManagerFactory/EntityManagerの取得方法

11-10

11-20以降（ejbserver.jpa.cdiEnabledがfalse）

11-20以降（ejbserver.jpa.cdiEnabledがtrue）

EntityManagerFactory

javax.persistence.Persistenceインタフェースの使用

○

○

○

DDによる参照の定義

EJB（ejb-jar.xml）

×

×

×

Webコンポーネント（web.xml）

△

△

△

@PersistenceUnitによる注入

×

×

○

EntityManager

DDによる参照の定義

EJB（ejb-jar.xml）

×

×

×

Webコンポーネント（web.xml）

△

△

△

@PersistenceContextによる注入

×

×

○

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

サポート範囲の詳細を次に示します。

(1)　javax.persistence.Persistenceインタフェースの使用

javax.persistence.Persistenceインタフェースを利用して，EntityManagerFactoryを取得できます。

(2)　DDによる参照の定義

EJB

EJB3.0のejb-jar.xmlがサポートされないため，ejb-jar.xmlによる永続化ユニット，永続化コンテキストの参照を定義できません。

Webコンポーネント

web.xmlのpersistence-unit-refタグやpersistence-context-refタグを利用して，永続化ユニット，永続化コンテキストの参照を定義し，その定義を利用できます。このとき，injection-targetタグを利用したインジェクションは利用できません。

(3)　@PersistenceUnitや@PersistenceContextによる注入

11-10以前では，CDI Managed Bean（それに関連づくインターセプタ含む）で@PersistenceUnitや@PersistenceContextでの定義はできません。

11-20以降では，ejbserver.jpa.cdiEnabledプロパティがtrue（デフォルトでtrue）の場合，CDI Managed Bean（それに関連づくインターセプタ含む）で@PersistenceUnitや@PersistenceContextでの定義ができます。

(a)　指定できる永続化ユニット

@PersistenceUnitや@PersistenceContextのunitName属性で指定できる永続化ユニットは，CDI Managed Beanが含まれるモジュールによって次のように分かれます。なお，どの永続化ユニットが使用されるかは「5.10.2　永続化ユニット名の参照スコープ」のルールが適用されます。

WAR内のCDI Managed Bean

unitName属性で次の永続化ユニットを指定できます。それ以外の永続化ユニットを指定した場合，EntityManagerFactoryやEntityManagerは注入されません。

そのCDI Managed Beanを含むWARに定義した永続化ユニット

EARに定義した永続化ユニット

EJB-JAR内のCDI Managed Bean

unitName属性で次の永続化ユニットを指定できます。それ以外の永続化ユニットを指定した場合，EntityManagerFactoryやEntityManagerは注入されません。

そのCDI Managed Beanを含むEJB-JARに定義した永続化ユニット

EARに定義した永続化ユニット

ライブラリJAR内のCDI Managed Bean

unitName属性で次の永続化ユニットを指定できます。それ以外の永続化ユニットを指定した場合，EntityManagerFactoryやEntityManagerは注入されません。

EARに定義した永続化ユニット

(4)　注意事項

SecurityManagerを使用する場合，CDI Managed Bean上でEntityManagerFactory/EntityManagerを参照できません。CDI Managed Beanで生成したEntityManagerFactory/EntityManagerを使用する場合は，CDI Managed Bean以外のクラスからオブジェクトを参照してください。

CDI Managed Beanに定義した@PersistenceContextのtype属性にPersistenceContextType.EXTENDEDを指定した場合，EntityManagerは注入されません。

CDI Managed Beanで@PersistenceUnitや@PersistenceContextでの定義をした場合，name属性の名前はJNDI名前空間（java:comp/env）に登録されません。そのため，name属性の名前でJNDIを使用してEntityManagerFactoryやEntityManagerをルックアップできません。

5.3.4　サポートするアプリケーションの形式

JPAを使用したJ2EEアプリケーションは，次のどちらかの形式でアプリケーションサーバにデプロイします。

アーカイブ形式のJ2EEアプリケーション

展開ディレクトリ形式のJ2EEアプリケーション

また，デプロイ済みのJPAを使用したJ2EEアプリケーションを入れ替えることもできます。アーカイブ形式の場合はリデプロイ機能を，展開ディレクトリ形式の場合はリロード機能を使用してください。

なお，リロード機能を使用する場合，O/Rマッピングファイルは更新検知の対象になりません。ただし，リロードされるタイミングで，O/Rマッピングファイルは再読み込みされます。次の表に，更新検知の対象およびリロード時の再読み込みについて示します。

表5‒3　リロード実行時の更新検知および再読み込みの対象

対象となるクラスおよびファイル

更新検知

再読み込み

エンティティクラス

○

○

マップドスーパークラス

○

○

埋め込みクラス

○

○

persistence.xml

○

○

O/Rマッピングファイル

（META-INFの下にorm.xmlを配置する場合）

×

○

O/Rマッピングファイル

（persistence.xmlの<mapping-file>タグに指定した場所にorm.xmlを配置する場合）

○

○

（凡例）○：対象になる　×：対象にならない

アーカイブ形式のJ2EEアプリケーション，および展開ディレクトリ形式のJ2EEアプリケーションについては，「18.　J2EEアプリケーションの形式とデプロイ」を参照してください。

注意事項

展開ディレクトリ形式でJPAを使用したアプリケーションを利用する場合，アプリケーション動作中はクラスやライブラリJARを削除しないでください。削除した場合，アプリケーションサーバやJPAプロバイダが予期しない動作をするおそれがあります。

5.3.5　サポートするクラスローダ構成

JPAを使用したJ2EEアプリケーションでは，次の表に示すクラスローダをサポートしています。

表5‒4　JPAを使用したJ2EEアプリケーションでサポートするクラスローダ

クラスローダ

サポート

デフォルトのクラスローダ構成

○

ローカル呼び出し最適化をしているとき※のクラスローダ構成

○

下位互換用のクラスローダ構成

×

（凡例）○：サポートする　×：サポートしない

注

下位互換用のクラスローダ構成はベーシックモードだけの使用となるため，サポートしていません。

注※　

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のように指定しているときを示します。

<param-name>ejbserver.rmi.localinvocation.scope</param-name>

<param-value>all</param-value>

5.3.6　使用できるリソースアダプタ

JPAを使用したJ2EEアプリケーションを実行する場合，アプリケーションサーバでは，コネクションファクトリインタフェースがjavax.sql.DataSourceであるリソースアダプタを使用できます。アプリケーションサーバで提供するリソースアダプタでは，DB Connectorを使用できます。

また，リソースアダプタを使用するには，J2EEリソースアダプタとしてデプロイする必要があります。JPAを使用したJ2EEアプリケーションの場合，リソースアダプタをJ2EEアプリケーションに含めてデプロイすることはできません。

アプリケーションサーバで使用できるリソースアダプタを次の表に示します。

表5‒5　アプリケーションサーバで使用できるリソースアダプタ

コネクションファクトリインタフェース

リソースアダプタのデプロイ形式

JPAからの使用

javax.sql.DataSource

J2EEリソースアダプタとしてデプロイする

○

J2EEアプリケーションに含めてデプロイする

×

javax.sql.DataSource以外

−

×

（凡例）○：使用できる　×：使用できない　−：該当しない

5.4　EntityManagerとは

EntityManagerはデータベースに対してエンティティを登録したり，削除したりするためのインタフェースを持つオブジェクトです。ここでは，EntityManagerの概要について説明します。

5.4.1　EntityManagerで提供するメソッド

EntityManagerではメソッドを提供しています。代表的なメソッドを次に示します。

persistメソッド（SQLのINSERTに相当）

アプリケーションでnewを実行したエンティティオブジェクトをデータベースに追加するためのメソッドです。

findメソッド（SQLのSELECTに相当）

エンティティオブジェクトをデータベースから検索するためのメソッドです。

removeメソッド（SQLのDELETEに相当）

エンティティオブジェクトをデータベースから削除するためのメソッドです。

EntityManagerからfindメソッドで検索したエンティティオブジェクトや，persistメソッドでEntityManagerに渡したエンティティオブジェクトは，EntityManagerの管理下に置かれます。EntityManagerの管理下にあるエンティティオブジェクトについてフィールドの値が変更されると，EntityManagerは変更を自動的に検知して，変更をデータベースのテーブルに反映します。

JPAでは，EntityManagerの管理下にあるエンティティオブジェクトのことをmanaged状態のエンティティといいます。なお，デフォルトではトランザクションが決着したときに，エンティティはEntityManagerの管理下から外れます。EntityManagerの管理下から外れたエンティティのことをdetached状態のエンティティと呼びます。

5.4.2　EntityManagerの種類

EntityManagerの種類には，コンテナ管理のEntityManagerおよびアプリケーション管理のEntityManagerの2種類があります。それぞれ説明します。

(1)　コンテナ管理のEntityManager

EntityManagerの作成や破棄をコンテナに任せる方法です。コンテナ管理のEntityManagerを使用すると，EntityManagerの生成や破棄を意識しないでアプリケーションをコーディングできます。コンテナ管理のEntityManagerを取得する方法と破棄する方法を説明します。

取得する方法

コンテナ管理のEntityManagerを取得するには，アプリケーションでDIまたはJNDIルックアップを使用します。この方法で取得するEntityManagerは，コンテナによって作成されたEntityManagerです。アプリケーションのコードでは，コンテナから取得したEntityManagerをそのまま使うことができます。

なお，アプリケーションからコンテナ管理のEntityManagerを取得する方法については，「5.6　コンテナ管理のEntityManagerを取得する方法」を参照してください。

破棄する方法

アプリケーション内で，EntityManagerの作成や破棄をコーディングする必要はありません。

(2)　アプリケーション管理のEntityManager

EntityManagerの作成や破棄をアプリケーションが明示的に行う方法です。アプリケーションのコードによって明示的にライフサイクルが管理されます。アプリケーション管理のEntityManagerを取得する方法と破棄する方法を説明します。

取得する方法

EntityManagerFactoryを使用して，アプリケーションでEntityManagerを作成します。EntityManagerFactoryを取得するには，アプリケーションでDIまたはJNDIルックアップを使用します。

なお，アプリケーション管理のEntityManagerを取得する方法については，「5.7　アプリケーション管理のEntityManagerを取得する方法」を参照してください。

破棄する方法

EntityManagerのcloseメソッドを呼んで，EntityManagerを破棄します。

5.4.3　トランザクションの制御とEntityManager

トランザクションの制御方法によって，EntityManagerには次の2種類があります。

JTAエンティティマネージャ

トランザクションがJTAによって制御されるEntityManagerです。

リソースローカルエンティティマネージャ

トランザクションがEntityTransaction APIによって制御されるEntityManagerです。

EntityManagerの種類とトランザクションの制御方法の関係について次の表に示します。

表5‒6　EntityManagerの種類とトランザクションの制御方法の関係

EntityManagerの種類

トランザクションの制御方法

JTA

リソースローカル

コンテナ管理のEntityManager

○※1

×

アプリケーション管理のEntityManager※2

○

○

（凡例）

○：制御できる

×：制御できない

JTA：JTAエンティティマネージャ

リソースローカル：リソースローカルエンティティマネージャ

注※1　トランザクションは必ずJTAによって制御されます。

注※2　トランザクションをJTAによって制御するか，またはアプリケーションが明示的にEntityTransactionというAPIを使用して制御するかを選択できます。EntityTransaction APIを使用する場合は，そのトランザクションはリソースローカルトランザクションとなります。JTAトランザクションが存在した場合でも，JTAトランザクションとは無関係に制御されます。

JTAエンティティマネージャを使用するかリソースローカルエンティティマネージャを使用するかは，永続化ユニットの定義で指定します。永続化ユニットでの定義方法については，「5.8.1(2)　transaction-type属性」を参照してください。

5.4.4　永続化ユニットとは

アプリケーションからJPAを使用する場合，次のような情報を定義する必要があります。

アプリケーション内のエンティティクラスの情報

エンティティクラスとデータベーステーブルとのマッピング情報

JPAプロバイダがデータベースコネクションを取得するためのデータソースの情報

これらの情報を定義したものを永続化ユニットといいます。

永続化ユニットは，persistence.xmlで定義します。Java EE環境でJPAを使用する場合，persistence.xmlはユーザがアプリケーションをパッケージングするときに，EJB-JAR，WAR，またはEARの中の決められた場所に配置します。

persistence.xmlファイルの中には，永続化ユニットの定義を複数含めることができます。また，一つのアプリケーションの中に複数のpersistence.xmlを含めることもできます。これによって，一つのアプリケーションの中に，複数の永続化ユニットを定義できます。アプリケーション内に複数の永続化ユニットが定義されている場合，アプリケーションがどの永続化ユニットを使用するかは，@PersistenceContextのunitName属性で指定します。なお，アプリケーション内に一つだけ永続化ユニットが定義されている場合など，使用する永続化ユニットを一意に特定できる場合には，unitName属性は省略できます。

5.5　永続化コンテキストとは

EntityManagerは更新するエンティティオブジェクトや検索されたエンティティオブジェクトをキャッシングします。永続化コンテキストは，EntityManagerでキャッシングされたエンティティオブジェクトのキャッシュです。

5.5.1　EntityManagerと永続化コンテキスト

EntityManagerと永続化コンテキストの関係を次の図に示します。

図5‒4　EntityManagerと永続化コンテキストの関係

EntityManagerは，永続化コンテキストの中にmanaged状態のエンティティオブジェクトを入れて管理しています。アプリケーションがエンティティオブジェクトをpersistメソッドに渡したときや，managed状態のエンティティオブジェクトについてフィールドの値を更新すると，永続化コンテキスト内のエンティティオブジェクトの状態が変更されます。EntityManagerは，トランザクションがコミットされる直前に，永続化コンテキスト内のエンティティオブジェクトとデータベースのテーブルの状態を同期させます。永続化コンテキスト内のエンティティオブジェクトの状態をデータベースのテーブルに反映するために，このときにまとめて更新SQLを発行します。これによって，データベースのロックの期間を短くできるので，同時実行性を向上したり，効率良くデータを更新したりできます。

(1)　EntityManagerの種類

永続化コンテキストとトランザクションの関係によって，コンテナ管理のEntityManagerとするか，アプリケーション管理のEntityManagerにするかを決めます。

永続化コンテキストがJTAトランザクションとともに自動的に伝播する必要がある場合

コンテナ管理のEntityManagerを使用します。コンテナ管理のEntityManagerを使用すると，永続化コンテキストがJTAトランザクションとともに自動的に伝播されます。このため，一つのJTAトランザクションの中で複数のコンポーネントが呼ばれた場合に，同じJTAトランザクションの中で使用されるEntityManagerは同じ永続化コンテキストに関連づけることができます。

これによって，アプリケーションはEntityManagerのリファレンスを，コンポーネントから別のコンポーネントに呼び出すときの引数に渡す必要がありません。

アプリケーションがJTAトランザクションとは独立した永続化コンテキストを使用する必要がある場合

アプリケーション管理のEntityManagerを使用します。アプリケーション管理のEntityManagerを使用すると，同じJTAトランザクションの中で別のEntityManagerを使用したときでも，これらのEntityManagerは永続化コンテキストを共有しないで，独立した永続化コンテキストを持ちます。

(2)　永続化コンテキストの種類

永続化コンテキストは生存区間によって次の2種類があります。

トランザクションスコープの永続化コンテキスト

拡張された永続化コンテキスト

コンテナ管理のEntityManagerの場合，永続化コンテキストの種類を選択できます。永続化コンテキストの種類は，@PersistenceContextのtype属性で指定します。デフォルトはトランザクションスコープの永続化コンテキストとなります。

なお，アプリケーション管理のEntityManagerの場合，常に拡張された永続化コンテキストとなります。永続化コンテキストの種類は選択できません。

5.5.2　コンテナ管理のEntityManagerを使用する場合の永続化コンテキスト

コンテナ管理のEntityManagerを使用する場合，永続化コンテキストのライフサイクルはコンテナによって管理され，JTAトランザクションとともに自動的に伝播されます。永続化コンテキストのライフサイクルの種類として，トランザクションスコープの永続化コンテキスト，または拡張された永続化コンテキストを選択できます。

それぞれの永続化コンテキストについて説明します。

(1)　トランザクションスコープの永続化コンテキスト

JPA仕様では，トランザクションと同じライフサイクルの永続化コンテキストのことをトランザクションスコープの永続化コンテキストといいます。

EntityManagerのライフサイクルは，デフォルトでトランザクションのライフサイクルと同じです。このため，EntityManagerが持つ永続化コンテキストにキャッシュされた更新は，トランザクションがコミットするときにデータベースに反映されます。

(a)　永続化コンテキストのライフサイクル

トランザクションスコープの永続化コンテキストのライフサイクルを次に説明します。

永続化コンテキストの作成

トランザクションスコープの永続化コンテキストは，コンテナ管理のEntityManagerが，JTAトランザクションの中で初めて呼び出されたときに作成されます。

作成された永続化コンテキストはJTAトランザクションに関連づけられます。

その後，同じJTAトランザクションの中でコンテナ管理のEntityManagerを使用した場合には，この永続化コンテキストが使用されます。

永続化コンテキストの破棄

JTAトランザクションがコミットまたはロールバックするときに，トランザクションスコープの永続化コンテキストは破棄されます。

コンテナ管理のEntityManagerがトランザクションの外で呼び出された場合には，EntityManagerのメソッド呼び出しが終了した時点で，データベースからロードされたすべてのエンティティは即座にdetached状態となります。

(2)　拡張された永続化コンテキスト

Java EE環境では，Stateful Session BeanからEntityManagerを使用する場合には，永続化コンテキストの生存期間をStateful Session Beanの生存期間と同じにできます。この場合，更新はトランザクションがコミットするたびにデータベースに反映されますが，永続化コンテキスト内で管理されているエンティティオブジェクトは，複数のトランザクションにわたってmanaged状態のまま保持されます。Stateful Session Beanと同じライフサイクルの永続化コンテキストのことを，JPAでは拡張永続化コンテキストと呼びます。

拡張された永続化コンテキストは，Stateful Session Beanが作成されるのと同時に作成され，そのStateful Session Beanに関連づけされます。その後，Stateful Session Beanが破棄されるのと同時に破棄されます。

Stateful Session Beanが別のStateful Session Beanを作成する場合で，作成する側と作成される側が共に拡張永続化コンテキストを使用するように定義されている場合には，作成する側の永続化コンテキストが，作成される側に引き継がれます。この引き継ぎは，Stateful Session Beanを作成する時点でトランザクションがアクティブであるかどうかにかかわらず実施されます。Stateful Session Beanの作成時に永続化コンテキストの引き継ぎが行われた場合には，その永続化コンテキストを共有するすべてのStateful Session Beanが破棄されるときに，永続化コンテキストも破棄されます。

(3)　拡張された永続化コンテキストとトランザクション

拡張された永続化コンテキストは，EntityManagerのインスタンスが作成されたときからクローズされるまで存在します。複数のトランザクションとEntityManagerのトランザクション外の呼び出しに対応しています。

トランザクションとの関連を次に示します。

EntityManagerがトランザクションの範囲内で呼び出されるか，永続化コンテキストがバインドしているstateful session beanがトランザクションのスコープで呼び出されると，EntityManagerで管理されたエンティティがトランザクションに参加します。

トランザクションが実行中かどうかにかかわらず，persist，remove，merge，refresh操作が行われることがあります。この場合，EntityManagerがトランザクションに参加して，トランザクションがコミットするときにデータベースに反映されます。

トランザクションがコミットされたあとでも，エンティティオブジェクトへの参照は保持されます。エンティティオブジェクトはEntityManagerに管理され，トランザクション間では，管理されているオブジェクト（managed状態のエンティティ）として更新されます。

(4)　永続化コンテキストの伝播

コンテナ管理のEntityManagerを使用する場合，永続化コンテキストはJTAトランザクションによって伝播され，複数のEntityManagerと関連づくことがあります。ただし，永続化コンテキストが伝播するのは，同じアプリケーションサーバ内だけです。リモートのアプリケーションサーバに永続化コンテキストが伝播されることはありません。

次に，永続化コンテキストの伝播についてコンポーネントが呼び出されたときの状態ごとに説明します。

コンポーネントが呼び出されたときに，JTAトランザクションが存在しないか，またはJTAトランザクションに永続化コンテキストが関連づいていない場合

永続化コンテキストは伝播されません。このコンポーネントからEntityManagerが呼び出したときの動作は，次のようになります。

トランザクションスコープの永続化コンテキストを使用するEntityManagerが呼び出された場合には，新しい永続化コンテキストが作成されます。

拡張永続化コンテキストを使用するEntityManagerが呼び出された場合には，呼び出されたStateful Session Beanに関連づいている拡張永続化コンテキストが使用されます。

EntityManagerが呼び出されたときに，JTAトランザクションが存在する場合には，JTAトランザクションに永続化コンテキストを関連づけます。

コンポーネントが呼び出されたときに，JTAトランザクションが伝播され，JTAトランザクションに永続化コンテキストが関連づいている場合

このコンポーネントからEntityManagerを呼び出したときの動作は次のようになります。

コンポーネントがすでに拡張永続化コンテキストを持っているStateful Session Beanにもかかわらず，JTAトランザクションに別の永続化コンテキストが関連づいている場合は，コンテナによってEJBExceptionがスローされます。

トランザクションスコープの永続化コンテキストを使用するEntityManagerが呼び出された場合，伝播してきたJTAトランザクションに関連づいている永続化コンテキストが使用されます。

5.5.3　アプリケーション管理のEntityManagerを使用する場合の永続化コンテキスト

アプリケーション管理のEntityManagerを使用する場合，アプリケーションがJPAプロバイダのEntityManagerFactoryを直接呼び出して，EntityManagerのライフサイクルおよび永続化コンテキストの作成や破棄を管理します。アプリケーション管理の永続化コンテキストのライフサイクルは，複数のトランザクションにわたったライフサイクルを管理できます。

(1)　EntityManagerのライフサイクルの管理

アプリケーションではEntityManagerのcloseメソッドやisOpenメソッドを使用して，アプリケーション管理のEntityManagerのライフサイクルを管理します。EntityManagerのcloseメソッドが呼ばれると，EntityManager，EntityManagerに関連づいた永続化コンテキストやそのほかのリソースが解放されます。closeメソッドを呼び出したあとは，アプリケーションではEntityManagerのgetTransactionメソッドとisOpenメソッド以外のメソッドを呼び出さないでください。呼び出した場合は，IllegalStateExceptionがスローされます。トランザクションがアクティブのときにcloseメソッドを呼び出した場合は，トランザクションが決着するまで永続化コンテキストは保持されたままとなります。EntityManagerのisOpenメソッドは，EntityManagerがクローズされるまではtrueを返し，クローズされたあとはfalseを返します。

(2)　永続化コンテキストのライフサイクル

アプリケーション管理の永続化コンテキストのライフサイクルを次に示します。

永続化コンテキストの作成

EntityManagerFactoryのcreateEntityManagerメソッドが呼ばれたときに作成されます。

永続化コンテキストの破棄

EntityManagerのcloseメソッドが呼ばれたときに破棄されます。

アプリケーション管理の永続化コンテキストは，トランザクションとは独立した永続化コンテキストです。このため，JTAトランザクションとともに伝播されることはありません。

(3)　JTAエンティティマネージャを使用する場合の注意

アプリケーション管理のEntityManagerでJTAエンティティマネージャを使用する場合，アプリケーションがEntityManagerをJTAトランザクションのスコープの外で作成するときは，EntityManagerのjoinTransactionを呼ぶのはアプリケーションの責任になります。アプリケーションはEntityManagerにトランザクションが開始されたことを通知する必要があるので，トランザクション開始後にEntityManagerのjoinTransactionメソッドを呼んでください。

5.6　コンテナ管理のEntityManagerを取得する方法

コンテナ管理のEntityManagerをJ2EEアプリケーションから取得するには，次の2種類の方法があります。

DIを使用してアプリケーションのフィールドやsetterメソッドにEntityManagerをインジェクトする方法

アプリケーションからJNDIを使用してEntityManagerをルックアップする方法

それぞれの方法について説明します。

5.6.1　アプリケーションにEntityManagerをインジェクトする方法

アプリケーションのフィールドやsetterメソッドにEntityManagerをインジェクトする場合，さらに次の2種類の方法があります。

@PersistenceContextをインジェクト先のフィールドまたはメソッドに付加する方法

DD（web.xml）の<persistence-context-ref>タグで定義する方法

ただし，アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，EJBでJPAを使用する場合は，1.の方法で定義してください。

それぞれの方法について説明します。

(1)　@PersistenceContextを使用する方法

@PersistenceContextを使用してEntityManagerをインジェクトする場合，インジェクト先のフィールドやsetterメソッドに@PersistenceContextを付加します。@PersistenceContextに指定できる属性について，次に示します。

(a)　unitName属性

unitName属性には，persistence.xmlで定義された永続化ユニットの名前を指定します。ただし，EJB-JARやWAR，EAR内に一つだけ永続化ユニットが定義されている場合など，使用する永続化ユニットが一意に特定できる場合には，unitName属性を省略できます。unitName属性を省略した場合に，どの永続化ユニットが使用されるかについては，「5.10.2　永続化ユニット名の参照スコープ」を参照してください。

(b)　type属性

type属性には，永続化コンテキストのライフサイクルの種類を指定します。指定できる種類は，PersistenceContextType.TRANSACTIONまたはPersistenceContextType.EXTENDEDです。

PersistenceContextType.TRANSACTIONを指定した場合

トランザクションスコープの永続化コンテキストが使用され，トランザクションの生存期間と永続化コンテキストの生存期間が同じになります。

PersistenceContextType.EXTENDEDを指定した場合

拡張永続化コンテキストが使用され，Stateful Session Beanの生存期間と永続化コンテキストの生存期間が同じとなります。

なお，type属性にPersistenceContextType.EXTENDEDを指定した@PersistenceContextは，Stateful Session Beanのフィールドまたはメソッドにだけ付けることができます。

type属性を省略した場合のデフォルトは，PersistenceContextType.TRANSACTIONです。

(c)　properties属性

properties属性には，永続化ユニットを設定するためのJPAプロバイダ用のプロパティを指定できます。ここに指定したプロパティは，JPAプロバイダからEntityManagerを取得するときに，JPAプロバイダに渡されます。

(d)　name属性

インジェクションを使用する場合，通常name属性を指定する必要はありませんが，指定した場合には，name属性に指定した名前でEntityManagerがJNDI名前空間（java:comp/env）に登録されます。@PersistenceContextを使用してEntityManagerをインジェクトする例を次に示します。

@Stateless
public class InventoryManagerBean implements InventoryManager {
  @PersistenceContext(unitName="myUnit")
  private EntityManager em;
  ・・・
}

(2)　DDの<persistence-context-ref>を使用する方法

DDを使用してEntityManagerをインジェクトする場合，DDの<persistence-context-ref>タグに次に示すタグを定義します。

(a)　<description>タグ

<description>タグには，定義するEntityManagerリファレンスの説明をユーザが自由に記述できます。このタグを指定した場合でも，指定した内容がアプリケーションの動作に影響を与えることはありません。また，このタグは省略できます。

(b)　<persistence-context-ref-name>タグ

<persistence-context-ref-name>タグには，EntityManagerがJNDI名前空間に登録されるときの名前を指定します。指定する名前は，java:comp/envからの相対パスです。EntityManagerのJNDI登録名は必須ではありませんが，JPA仕様では，java:comp/env/persistence以下にすることが推奨されています。

(c)　<persistence-unit-name>タグ

<persistence-unit-name>タグには，persistence.xmlに定義された永続化ユニットの名前を指定します。EJB-JARやWAR，EAR内に一つだけ永続化ユニットが定義されている場合など，使用する永続化ユニットを一意に特定できる場合には，<persistence-unit-name>タグは省略できます。<persistence-unit-name>タグを省略した場合に，どの永続化ユニットが使用されるかについては，「5.10.2　永続化ユニット名の参照スコープ」を参照してください。

(d)　<persistence-context-type>タグ

<persistence-context-type>タグには，永続化コンテキストのライフサイクルの種類を指定します。「Transaction」または「Extended」を指定します。

「Transaction」を指定した場合

トランザクションスコープの永続化コンテキストが使用され，トランザクションの生存期間と永続化コンテキストの生存期間が同じになります。

「Extended」を指定した場合

拡張永続化コンテキストが使用され，Stateful Session Beanの生存期間と永続化コンテキストの生存期間が同じとなります。

なお，<persistence-context-type>タグに「Extended」を指定した<persistence-context-ref>タグは，Stateful Session Beanに対してだけ定義できます。

<persistence-context-type>タグを省略した場合のデフォルトは，「Transaction」になります。

(e)　<persistence-property>タグ

<persistence-property>タグには，永続化ユニットを設定するためのJPAプロバイダ用のプロパティを指定できます。ここに指定したプロパティは，JPAプロバイダからEntityManagerのファクトリを取得するときに，JPAプロバイダに渡されます。このタグは省略できます。

(f)　<injection-target>タグ

<injection-target>タグの<injection-target-class>タグにはインジェクト先のクラスを指定します。<injection-target>タグの<injection-target-name>タグには，インジェクト先のフィールド名またはsetterメソッド名を指定します。web.xmlに<persistence-context-ref>タグを定義してEntityManagerをインジェクトする例を次に示します。

...
<web-app>
  ...
  <servlet>
    <display-name>InventoryManagerServlet</display-name>
    <servlet-name>InventoryManagerServlet</servlet-name>
    <servlet-class>com.hitachi.InventoryManagerServlet</servlet-class>
  </servlet>
  ...
  <persistence-context-ref>
    <description>
      Persistence context for the inventory management application.
    </description>
    <persistence-context-ref-name>persistence/InventoryAppMgr
    </persistence-context-ref-name>
    <persistence-unit-name>InventoryManagement</persistence-unit-name>
    <persistence-context-type>Transaction</persistence-context-type>
    <injection-target>
      <injection-target-class>
        com.hitachi.InventoryManagerServlet
      </injection-target-class>
      <injection-target-name>em</injection-target-name>
    </injection-target>
  </persistence-context-ref>
  ...
</web-app>
...

5.6.2　アプリケーションからEntityManagerをルックアップする方法

JNDIを使用してアプリケーションからEntityManagerをルックアップする場合，さらに次の2種類の方法があります。

EntityManagerをルックアップするクラスに@PersistenceContextを付加して，EntityManagerのリファレンスを定義する方法

DD（web.xml）で<persistence-context-ref>タグを定義して，EntityManagerのリファレンスを定義する方法

ただし，アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，EJBでJPAを使用する場合は，1.の方法で定義してください。

それぞれの方法について説明します。

(1)　@PersistenceContextを使用する方法

@PersistenceContextを使用してEntityManagerのリファレンスを定義する場合，ルックアップを実行するクラスに@PersistenceContextを付加します。

@PersistenceContextに指定できる属性について，次に説明します。

(a)　name属性

name属性には，アプリケーションのコードがEntityManagerをルックアップするときのルックアップ名を指定します。指定するルックアップ名は，java:comp/envからの相対パスです。EntityManagerのルックアップ名は，必須ではありませんが，JPA仕様では，java:comp/env/persistence以下にすることが推奨されています。

@PersistenceContextのそのほかの属性については，「5.6.1　アプリケーションにEntityManagerをインジェクトする方法」と同じです。なお，拡張スコープのEntityManagerのルックアップは，Stateful Session Beanだけできます。また，一つのクラスに複数の@PersistenceContextを付加する場合には，クラスに@PersistenceContextsを付加し，そのvalue属性として@PersistenceContextの配列を指定してください。次に，@PersistenceContextを使用してSessionContextからEntityManagerをルックアップする例を示します。

@Stateless
@PersistenceContext(name="persistence/OrderEM")
public class MySessionBean implements MyInterface {
  @Resource SessionContext ctx;
  public void doSomething() {
    ・・・
    EntityManager em = (EntityManager)ctx.lookup("persistence/OrderEM");
    ・・・
  }
}

次に，@PersistenceContextを使用してInitialContextからEntityManagerをルックアップする例を示します。

@Stateless
@PersistenceContext(name="persistence/InventoryAppMgr")
public class InventoryManagerBean implements InventoryManager {
  public void updateInventory(...) {
    ・・・
    Context initCtx = new InitialContext();
    EntityManager em = (EntityManager)
      initCtx.lookup("java:comp/env/persistence/InventoryAppMgr");
    ・・・
  }
}

(2)　DDの<persistence-context-ref>を使用する方法

DDを使用してEntityManagerのリファレンスを定義する場合，DDの<persistence-context-ref>タグに次に示すタグを定義します。

(a)　<persistence-context-ref-name>タグ

<persistence-context-ref-name>タグには，アプリケーションのコードがEntityManager をルックアップするときのルックアップ名を指定します。指定するルックアップ名は，java:comp/envからの相対パスです。EntityManagerのルックアップ名は，必須ではありませんが，JPA仕様ではjava:comp/env/persistence以下にすることが推奨されています。

<persistence-context-ref>タグのそのほかのタグについては，「5.6.1　アプリケーションにEntityManagerをインジェクトする方法」と同じです。ただし，JNDIルックアップでEntityManager を取得する場合，<injection-target>は指定しません。なお，拡張スコープのEntityManagerのルックアップは，Stateful Session Beanからできます。

次に，web.xmlに<persistence-context-ref>を定義する例を示します。

...
<web-app>
  ...
  <servlet>
    <display-name>InventoryManagerServlet</display-name>
    <servlet-name>InventoryManagerServlet</servlet-name>
    <servlet-class>com.hitachi.InventoryManagerServlet</servlet-class>
  </servlet>
  ...
  <persistence-context-ref>
    <description>
      Persistence context for the inventory management application.
    </description>
    <persistence-context-ref-name>
      persistence/InventoryAppMgr
    </persistence-context-ref-name>
    <persistence-unit-name>InventoryManagement</persistence-unit-name>
    <persistence-context-type>Transaction</persistence-context-type>
  </persistence-context-ref>
  ...
</web-app>
...

5.6.3　DDによる@PersistenceContext定義のオーバーライド

@PersistenceContextをアプリケーションに記載している場合に，DDで<persistence-context-ref>タグを定義していると，アノテーションで定義した内容はDDで定義した内容で上書きされます。この場合，アノテーションとDDとの対応は，@PersistenceContextのname属性と，DDの<persistence-context-ref>タグ下にある<persistence-context-ref-name>タグの対応で判断されます。なお，@PersistenceContextでname属性が明示的に指定されていない場合でも，name属性にはデフォルト値が存在するので注意が必要です。

次に@PersistenceContextに指定した属性がDDのタグでオーバーライドされるときの注意について説明します。

(1)　<persistence-unit-name>タグとunitName属性

DDの<persistence-unit-name>タグは@PersistenceContextのunitName属性をオーバーライドします。通常，永続化ユニット名を変更すると，アプリケーションは動作しなくなるので，DDおよびアノテーションを定義する際には注意してください。

(2)　<persistence-context-type>タグとtype属性

DDの<persistence-context-type>タグは@PersistenceContextのtype属性をオーバーライドします。通常，永続化コンテキストのライフサイクルの種類を変更すると，アプリケーションは動作しなくなるので，DDおよびアノテーションを定義する際には注意してください。

(3)　<persistence-property>タグとproperties属性

DDの<persistence-property>に指定されたプロパティは，@PersistenceContextのproperties属性に指定されたプロパティに追加されます。ただし，プロパティ名が同じ場合には，プロパティ値がオーバーライドされます。

(4)　<injection-target>タグ

インジェクションターゲットをオーバーライドすることはできません。なお，DDに<injection-target>タグを記述する場合には，@PersistenceContextが付加されたフィールドやメソッドを正確に指定してください。

5.7　アプリケーション管理のEntityManagerを取得する方法

アプリケーション管理のEntityManagerを使用する場合，アプリケーションはEntityManagerFactoryを使用してEntityManagerを作成します。アプリケーションがEntityManagerFactoryを取得するには，次の2種類の方法があります。

DIを使用してアプリケーションのフィールドやsetterメソッドにEntityManagerFactoryをインジェクトする方法

アプリケーションからJNDIを使用してEntityManagerFactoryをルックアップする方法

それぞれの方法について説明します。

5.7.1　アプリケーションにEntityManagerFactoryをインジェクトする方法

アプリケーションのフィールドやsetterメソッドにEntityManagerFactoryをインジェクトする場合，さらに次の2種類の方法があります。

@PersistenceUnitをインジェクト先のフィールドまたはメソッドに付加する方法

DD（web.xml）の<persistence-unit-ref>タグで定義する方法

ただし，アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，EJBでJPAを使用する場合は，1.の方法で定義してください。

それぞれの方法について説明します。

(1)　@PersistenceUnit を使用する方法

@PersistenceUnitを使用してEntityManagerFactoryをインジェクトする場合，インジェクト先のフィールドやsetterメソッドに@PersistenceUnitを付加します。@PersistenceUnitに指定できる属性について説明します。

(a)　unitName属性

unitName属性には，persistence.xmlで定義された永続化ユニットの名前を指定します。ただし，EJB-JARやWAR，EAR内に一つだけ永続化ユニットが定義されている場合など，使用する永続化ユニットが一意に特定できる場合には，unitName属性を省略できます。unitName属性を省略した場合に，どの永続化ユニットが使用されるかについては，「5.10.2　永続化ユニット名の参照スコープ」を参照してください。

(b)　name属性

インジェクションを使用する場合，通常name属性を指定する必要はありませんが，指定した場合には，name属性に指定した名前でEntityManagerがJNDI 名前空間（java:comp/env）に登録されます。次に，@PersistenceUnit を使用してEntityManagerFactory をインジェクトする例を示します。

@Stateless
public class InventoryManagerBean implements InventoryManager {
  @PersistenceUnit(unitName="myUnit")
  private EntityManagerFactory emf;
  ・・・
}

(2)　DDの<persistence-unit-ref>タグを使用する方法

DDを使用してEntityManagerFactoryをインジェクトする場合，DDの<persistence-unit-ref>タグに次に示すタグを定義します。

(a)　<persistence-unit-ref-name>タグ

<persistence-unit-ref-name>タグには，EntityManagerFactoryがJNDI名前空間に登録されるときの名前を指定します。指定する名前は，java:comp/envからの相対パスです。

EntityManagerFactoryのJNDI登録名は必須ではありませんが，JPA仕様では，java:comp/env/persistence以下にすることが推奨されています。

(b)　<description>タグ

<description>タグには，定義するEntityManagerFactoryリファレンスの説明をユーザが自由に記述できます。このエレメントを指定した場合でも，指定した内容がアプリケーションの動作に影響を与えることはありません。また，このタグは省略できます。

(c)　<persistence-unit-name>タグ

<persistence-unit-name>タグには，persistence.xmlに定義された永続化ユニットの名前を指定します。EJB-JARやWAR，EAR内に一つだけ永続化ユニットが定義されている場合など，使用する永続化ユニットを一意に特定できる場合には，<persistence-unit-name>タグは省略できます。<persistence-unit-name>タグを省略した場合に，どの永続化ユニットが使用されるかについては，「5.10.2　永続化ユニット名の参照スコープ」を参照してください。

(d)　<injection-target>タグ

<injection-target>タグの<injection-target-class>タグにはインジェクト先のクラスを指定します。<injection-target>タグの<injection-target-name>タグには，インジェクト先のフィールド名またはsetterメソッド名を指定します。次に，web.xmlに<persistence-unit-ref>を定義してEntityManagerFactory をインジェクトする例を示します。

...
<web-app>
  ...
  <servlet>
    <display-name>InventoryManagerServlet</display-name>
    <servlet-name>InventoryManagerServlet</servlet-name>
    <servlet-class>com.hitachi.InventoryManagerServlet</servlet-class>
  </servlet>
  ...
  <persistence-unit-ref>
    <description>
      Persistence unit for the inventory management application.
    </description>
    <persistence-unit-ref-name>persistence/InventoryAppDB
    </persistence-unit-ref-name>
    <persistence-unit-name>InventoryManagement</persistence-unit-name>
    <injection-target>
      <injection-target-class>
        com.hitachi.InventoryManagerServlet
      </injection-target-class>
      <injection-target-name>emf</injection-target-name>
    </injection-target>
  </persistence-unit-ref>
  ...
</web-app>
...

5.7.2　アプリケーションからEntityManagerFactoryをルックアップする方法

JNDIを使用してアプリケーションからEntityManagerFactoryをルックアップする場合，さらに次の2種類の方法があります。

EntityManagerFactoryをルックアップするクラスに@PersistenceUnitを付加して，EntityManagerFactoryのリファレンスを定義する方法

DD（web.xml）で<persistence-unit-ref>タグを定義して，EntityManagerFactoryのリファレンスを定義する方法

ただし，アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，EJBでJPAを使用する場合は，1.の方法で定義してください。

それぞれの方法について説明します。

(1)　@PersistenceUnitを使用する方法

@PersistenceUnitを使用してEntityManagerFactoryのリファレンスを定義する場合，ルックアップを行うクラスに@PersistenceUnitを付加します。@PersistenceUnitに指定できる属性について説明します。

(a)　name属性

name属性には，アプリケーションのコードがEntityManagerFactoryをルックアップするときのルックアップ名を指定します。指定するルックアップ名は，java:comp/envからの相対パスです。EntityManagerFactoryのルックアップ名は，必須ではありませんが，JPA 仕様ではjava:comp/env/persistence以下にすることが推奨されています。

@PersistenceUnitのそのほかの属性については，「5.7.1　アプリケーションにEntityManagerFactoryをインジェクトする方法」と同じです。なお，一つのクラスに複数の@PersistenceUnitを付加する場合には，クラスに@PersistenceUnitsを付加し，そのvalue属性として@PersistenceUnitの配列を指定してください。次に，@PersistenceContextを使用してSessionContextからEntityManagerFactoryをルックアップする例を示します。

@Stateless
@PersistenceUnit(name="persistence/InventoryAppDB")
public class InventoryManagerBean implements InventoryManager {
  @Resource SessionContext ctx;
  public void updateInventory(...) {
    ・・・
    EntityManagerFactory emf = (EntityManagerFactory)
      ctx.lookup("persistence/InventoryAppDB");
    EntityManager em = emf.createEntityManager();
    ・・・
  }
}

次に，@PersistenceContextを使用してInitialContextからEntityManagerFactoryをルックアップする例を示します。

@Stateless
@PersistenceUnit(name="persistence/InventoryAppDB")
public class InventoryManagerBean implements InventoryManager {
  public void updateInventory(...) {
    Context initCtx = new InitialContext();
    EntityManagerFactory emf = (EntityManagerFactory)
      initCtx.lookup("java:comp/env/persistence/InventoryAppDB");
    EntityManager em = emf.createEntityManager();
    ・・・
  }
}

(2)　DDの<persistence-unit-ref>タグを使用する方法

DDを使用してEntityManagerFactoryのリファレンスを定義する場合，DDの<persistence-unit-ref>タグを定義します。

(a)　<persistence-unit-ref-name>タグ

<persistence-unit-ref-name>タグには，アプリケーションのコードがEntityManagerFactoryをルックアップするときのルックアップ名を指定します。指定するルックアップ名は，java:comp/envからの相対パスです。EntityManagerFactoryのルックアップ名は，必須ではありませんが，JPA仕様でjava:comp/env/persistence以下にすることが推奨されています。

<persistence-unit-ref>のそのほかのタグについては，「5.7.1　アプリケーションにEntityManagerFactoryをインジェクトする方法」と同じです。ただし，JNDIルックアップでEntityManagerFactoryを取得する場合，<injection-target>タグは指定しません。次に，web.xmlに<persistence-unit-ref>を定義する例を示します。

...
<web-app>
  ...
  <servlet>
    <display-name>InventoryManagerServlet</display-name>
    <servlet-name>InventoryManagerServlet</servlet-name>
    <servlet-class>com.hitachi.InventoryManagerServlet</servlet-class>
  </servlet>
  ...
  <persistence-unit-ref>
    <description>
     Persistence unit for the inventory management application.
    </description>
    <persistence-unit-ref-name>
      persistence/InventoryAppDB
    </persistence-unit-ref-name>
    <persistence-unit-name>InventoryManagement</persistence-unit-name>
  </persistence-unit-ref>
  ...
</web-app>
...

5.7.3　DDによる@PersistenceUnit定義のオーバーライド

@PersistenceUnitをアプリケーションに記載している場合に，DDで<persistence-unit-ref>タグを定義していると，アノテーションで定義した内容はDDで定義した内容で上書きされます。この場合，アノテーションとDDとの対応は，@PersistenceUnitのname属性とDDの<persistence-unit-ref>タグ下にある<persistence-unit-ref-name>タグの対応で判断されます。@PersistenceUnitでname属性が明示的に指定されていない場合，name属性にはデフォルト値が存在するので注意が必要です。

次に@PersistenceUnitに指定した属性がDDのタグでオーバーライドされるときの注意について説明します。

(1)　<persistence-unit-name>とunitName属性

DDの<persistence-unit-name>は@PersistenceUnitのunitName属性をオーバーライドします。通常，永続化ユニット名を変更すると，アプリケーションは動作しなくなるので，変更には注意が必要です。

(2)　<injection-target>タグ

DDでインジェクションターゲットをオーバーライドすることはできません。DDに<injection-target>を記述する場合には，@PersistenceContextが付加されたフィールドやメソッドを正確に指定しなければなりません。

5.8　persistence.xmlでの定義

永続化ユニットの情報はpersistence.xmlの<persistence-unit>タグを使用して定義します。ここでは，<persistence-unit>タグの属性および<persistence-unit>タグ下に指定するタグについて説明します。

なお，<persistence-unit>タグの属性および<persistence-unit>タグ下に指定するタグに指定した値の先頭および末尾に付加された空白文字や改行文字は無視されます。

persistence.xmlのタグの詳細については，JavaEEの標準仕様を参照してください。

5.8.1　<persistence-unit>タグに指定する属性

<persistence-unit>タグにはname属性とtransaction-type属性を指定します。

(1)　name属性

定義する永続化ユニットの名前を指定します。ここで指定した名前は，アノテーションの場合，@PersistenceUnitまたは@PersistenceContextのunitName属性から参照されます。また，DDの場合は，<persistence-context-ref>タグ下または<persistence-unit-ref>タグ下の<persistence-unit-name>タグから参照されます。

name属性は省略できません。また，アプリケーションサーバでJPAを使用する場合，name属性には空文字を指定できません。1文字以上の文字列を指定してください。

(2)　transaction-type属性

定義する永続化ユニットで，トランザクションをJTAによってコントロールするか，javax.persistence.EntityTransactionを使用してアプリケーションがコントロールするかを指定します。

トランザクションをJTAによってコントロールする場合

transaction-type属性には「JTA」を指定します。「JTA」を指定した場合には，同時に<jta-data-source>タグも指定する必要があります。

EntityTransactionを使用してアプリケーションがトランザクションをコントロールする場合

transaction-type属性には「RESOURCE_LOCAL」を指定します。「RESOURCE_LOCAL」を指定した場合には，<non-jta-data-source>タグも同時に指定する必要があります。

なお，transaction-type属性を省略した場合，デフォルトは「JTA」となります。

5.8.2　<persistence-unit>タグ下に指定するタグ

<persistence-unit>タグ下には，次の表に示すタグを指定します。

表5‒7　<persistence-unit>タグ下に指定するタグ

指定するタグ

設定内容

<description>タグ

永続化ユニットの説明を記載します。

<provider>タグ

使用するJPAプロバイダを指定します。

<jta-data-source>タグ

<non-jta-data-source>タグ

JPAプロバイダで使用するJTAデータソースまたは非JTAデータソースを指定します。

<mapping-file>タグ

使用するO/Rマッピングファイルを指定します。

<jar-file>タグ

entityクラス，embeddableクラス，mappedsuperクラスを含むJARファイル名を指定します。

<class>タグ

entityクラス，embeddableクラス，mappedsuperクラスを指定します。

<exclude-unlisted-classes>タグ

Persistenceクラスとして扱うかどうかを指定します。

<shared-cache-mode>タグ

永続化ユニットの二次キャッシュを利用する方法を指定します。

<validation-mode>タグ

自動で妥当性検査を実施するかどうかを指定します。

<properties>タグ

JPAプロバイダ固有のプロパティを指定します。

それぞれのタグについて説明します。

(1)　<description>タグ

ユーザが永続化ユニットの説明を自由に記述できます。ここに指定した内容がアプリケーションの動作に影響を与えることはありません。なお，このタグは省略できます。

(2)　<provider>タグ

永続化ユニットで使用するJPAプロバイダを指定します。JPAプロバイダのjavax.persistence.spi.PersistenceProviderインタフェースの実装クラス名を，パッケージ名を含めた完全修飾名で指定します。このタグは省略できます。

このタグを省略した場合，簡易構築定義ファイルで指定したデフォルトのJPAプロバイダが使用されます。

なお，アプリケーションが特定のJPAプロバイダの機能や挙動に依存している場合は，<provider>タグを必ず指定してください。

ポイント

簡易構築定義ファイルでデフォルトのJPAプロバイダを指定するには，論理J2EEサーバの<param-name>タグにejbserver.jpa.defaultProviderClassNameを指定して，<param-value>タグにデフォルトのJPAプロバイダクラス名を指定します。

なお，簡易構築定義ファイルで，論理J2EEサーバの<param-name>タグにejbserver.jpa.overrideProviderパラメタが指定されているときは，ejbserver.jpa.overrideProviderパラメタの<param-value>タグに指定されているJPAプロバイダクラス名が，<provider>タグやejbserver.jpa.defaultProviderClassNameパラメタに指定した値よりも優先して使用されます。

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

永続化ユニットで使用されるJPAプロバイダを決定する優先順位を次の表に示します。

表5‒8　永続化ユニットで使用されるJPAプロバイダを決定する優先順位

優先度

使用するJPAプロバイダ

1

簡易構築定義ファイルのejbserver.jpa.overrideProviderプロパティに指定された値

2

persistence.xmlの<provider>タグに指定された値

3

org.eclipse.persistence.jpa.PersistenceProvider

（簡易構築定義ファイルのejbserver.jpa.defaultProviderClassNameパラメタを使用して変更することもできる）

(3)　<jta-data-source>タグ，<non-jta-data-source>タグ

JPAプロバイダが使用するJTAデータソースまたは非JTAデータソースを指定します。ここに指定する値は，JPA仕様上は製品依存となっていますが，アプリケーションサーバでは次のようにデータソースの参照を定義します。

Connector 1.0に準拠したリソースアダプタを参照する場合

「<リソースアダプタの表示名>」または「<リソースアダプタの別名>」を指定してください。

Connector 1.5に準拠したリソースアダプタを参照する場合

「<リソースアダプタの表示名>!<コネクション定義識別子>」または「リソースアダプタの別名」を指定してください。

指定した値は「<リソースアダプタの表示名>」または「<リソースアダプタの表示名>!<コネクション定義識別子>」として解釈され，該当するリソースアダプタを検索します。該当するリソースアダプタが存在しない場合，指定した値は「<リソースアダプタの別名>」として解釈され，該当するリソースアダプタを検索します。

また，参照するリソースアダプタは，J2EEリソースアダプタとしてデプロイする必要があります（スタンドアロンモジュールとしてデプロイする方法）。リソースアダプタは，永続化ユニットを含むアプリケーションを開始するより前に，開始してください。

<jta-data-source>タグ，<non-jta-data-source>タグは省略できます。省略した場合には，簡易構築定義ファイルのejbserver.jpa.defaultJtaDsNameパラメタまたはejbserver.jpa.defaultNonJtaDsNameパラメタに指定した値が使用されます。ただし，これらのプロパティにはデフォルト値がありません。

ejbserver.jpa.overrideJtaDsNameパラメタまたはejbserver.jpa.overrideNonJtaDsNameパラメタに値が指定されている場合は，<jta-data-source>タグ，<non-jta-data-source>タグに指定された値や，ejbserver.jpa.defaultJtaDsNameパラメタ，ejbserver.jpa.defaultNonJtaDsNameパラメタに指定された値よりも優先して使用されます。

なお，<jta-data-source>タグに指定するリソースアダプタのトランザクションサポートレベルには，LocalTransactionまたはXATransactionを指定する必要があります。また，<non-jta-data-source>に指定するリソースアダプタのトランザクションサポートレベルには，NoTransactionを指定する必要があります。

永続化ユニットで使用されるJTAデータソースおよび非JTAデータソースを決定するときの優先順位を次の表に示します。

表5‒9　永続化ユニットで使用されるJTA データソースおよび非JTAデータソースを決定する優先順位

優先度

使用するJPAプロバイダ

1

簡易構築定義ファイルのejbserver.jpa.overrideJtaDsNameプロパティまたはejbserver.jpa.overrideNonJtaDsNameプロパティに指定された値

2

persistence.xml の<jta-data-source>または<non-jta-data-source>エレメントに指定された値

3

簡易構築定義ファイルのejbserver.jpa.defaultJtaDsNameプロパティまたはejbserver.jpa.defaultNonJtaDsNameプロパティに指定した値

注意事項

persistence.xmlの<jta-data-source>タグまたは<non-jta-data-source>タグで，半角英数字およびアンダースコア(_)以外の文字が含まれているリソースアダプタの表示名を指定する場合，その文字をアンダースコア（_）に置き換えて指定してください。ただし，置き換えたあとの表示名の文字列がほかのリソースアダプタの表示名や別名と重複した場合，永続化ユニットは意図しないデータソースを使用して動作をしてしまう場合があるので注意してください。

(4)　<mapping-file>，<jar-file>，<class>，<exclude-unlisted-classes>タグ

永続化ユニットに含めるエンティティクラス，埋め込み可能クラス，マッピングされたスーパークラスを指定するには次の二つの方法があります。

O/Rマッピングファイルや<class>タグを使用して明示的に指定する方法

明示的には指定しないでJPAプロバイダによる自動検索を使用する方法

ここでは，1.の方法について説明します。

(a)　O/Rマッピングファイルを使って指定する

永続化ユニットルートのMETA-INFの下，または永続化ユニットから<jar-file>タグで参照している別のJARファイル内のMETA-INFの下に，「orm.xml」という名前のXMLファイルが配置されている場合，<mapping-file>タグに指定しなくても自動的にO/Rマッピングファイルとして扱われます。さらに，<mapping-file>タグにクラスパス上でロードできるXMLファイル名を指定した場合，そのXMLファイルもO/Rマッピングファイルとして扱われます。一つの永続化ユニットに複数のO/Rマッピングファイルが含まれている場合，すべてのO/Rマッピングファイルからマッピング情報が読み込まれます。ただし，複数のO/Rマッピングファイルの間で，重複してマッピングを定義している場合の動作は規定されていません。

(b)　パシステンスクラスを検索するJARファイルを指定する

<jar-file>タグには，パシステンスクラスやO/Rマッピングファイルを含んだJARファイルを指定できます。<jar-file>タグに指定されたJARファイルからは，@Entity，@Embeddable，@MappedSuperclassが付加されたクラスが検索され，マッピング情報が自動的に取得されます。指定したJARファイル内にMETA-INF/orm.xmlが存在する場合，orm.xmlからもマッピング情報が取得されます。なお，<jar-file>タグと<mapping-file>タグを併用することもできます。

<jar-file>タグで指定できるJARファイルは，クラスパスに含まれている必要があります。指定できるのは次に示すJARファイルとなります。

EARのルートに置いたJARファイル

EARのライブラリディレクトリに置いたJARファイル

EJB-JAR

WARの中のWEB-INF/libに置いたJARファイル

ただし，EARレベルまたはEJB-JARレベルに定義された永続化ユニットの<jar-file>タグに，WARの中のWEB-INF/libに置いたJARファイルを指定することはできません。これは，WARの中のWEB-INF/libに置いたJARファイルはWEBアプリケーション用のクラスローダでロードされるので，WARの中のコンポーネント以外からは参照できないためです。

また，WARレベルに定義された永続化ユニットの<jar-file>タグからは，同じWARの中に含まれたJARファイルだけが指定できます。これは，同じWAR以外の場所に配置されたJARファイルに含まれるクラスは，WARレベルに定義された永続化ユニットのデプロイメントが行われるよりも前にクラスローダによってロードされるおそれがあるためです。このような場合，JPAプロバイダによるバイトコードの変換が正しく実施されないおそれがあります。

<jar-file>タグには，永続化ユニットルートからJARファイルへの相対パスを指定します。指定例を次に示します。

例1

次の図に示す場合の相対パスの指定について説明します。

EARのlibにエンティティクラスを格納したmyEntities.jarがある。

EARのルートに置いたEJB-JARのMETA-INF/persistence.xmlの<jar-file>タグでmyEntities.jarを指定する。

この図の場合，永続化ユニットのルートはEJB-JARそのものになるので，EJB-JARからmyEntities.jarへの相対パスを指定します。相対パスは，「lib/myEntities.jar」です。このため，<jar-file>タグに「lib/myEntities.jar」と指定します。

例2

次の図に示す場合の相対パスの指定について説明します。

EARのルートにエンティティクラスを格納したmyEntities.jarがある。

EARのlib/myPersistenceUnit.jarのMETA-INF/persistence.xmlの<jar-file>タグでmyEntities.jarを指定する。

この図の場合，永続化ユニットのルートはmyPersistenceUnit.jarになるので，myPersistenceUnit.jarからmyEntities.jarへの相対パスを指定します。相対パスは，「../myEntities.jar」です。このため，<jar-file>タグには「../myEntities.jar」と指定します。

例3

次の図に示す場合の相対パスの指定について説明します。

WARのWEB-INF/libにエンティティクラスを格納したmyEntities.jarがある。

WARのWEB-INF/classes/META-INF/persistence.xmlの<jar-file>タグでmyEntities.jarを指定する。

この図の場合，永続化ユニットルートはWARのWEB-INF/classesになるので，WEB-INF/classesからmyEntities.jarへの相対パスを指定します。相対パスは「../lib/myEntities.jar」です。このため，<jar-file>タグには「../lib/myEntities.jar」と指定します。

(c)　パシステンスクラスのリストを明示的に指定する

<class>タグを使用すると，パシステンスクラスのリストを明示的に指定できます。マッピング情報は，指定されたクラスに付加されたアノテーションから取得されます。なお，<class>タグは，<mapping-file>タグや<jar-file>タグと併用することもできます。

(d)　アノテーションを付加したパシステンスクラスを永続化ユニットのルートに配置する

永続化ユニットのルートからは，@Entity，@Embeddable，@MappedSuperclassの付加されたパシステンスクラスが自動的に検索されます。マッピング情報はクラスに付加されたアノテーションから取得されます。永続化ユニットのルートに配置したアノテーションの付加されたクラスを永続化ユニットに加えたくない場合には，<exclude-unlisted-classes>タグを指定しておく必要があります。

(5)　<shared-cache-mode>タグ

永続化ユニットの二次キャッシュを利用する方法を指定します。エンティティとエンティティに関連づいた状態がキャッシュされます。指定がない場合や，UNSPECIFIEDが指定された場合には，永続化プロバイダのデフォルトで動作します。

(6)　<validation-mode>タグ

自動で妥当性検査を実施するかどうかを指定します。デフォルトはAUTOです。

(7)　<properties>タグ

JPAプロバイダのベンダ特有のプロパティを指定できます。JPAプロバイダが理解できないプロパティを指定した場合は，単に無視されます。なお，「javax.persistence」で始まるプロパティを<properties>に指定することはできません。

システムプロパティとして，プロパティ名がプレフィックス「ejbserver.jpa.emfprop.」で始まるプロパティを指定しておくと，プレフィックスを除去したプロパティが，永続化ユニットのプロパティに追加されます。

5.9　persistence.xmlの配置

persistence.xmlはEJB-JAR，WAR，EARの中に配置します。persistence.xmlは必ずMETA-INFの下に置いてください。META-INFの下にpersistence.xmlを持つパスを永続化ユニットのルートと呼びます。

persistence.xmlを配置できる場所を次に示します。

EJB-JARのMETA-INF/persistence.xml

WARのWEB-INF/classes/META-INF/persistence.xml

WARのWEB-INF/libの下に置いたjarファイルの中のMETA-INF/persistence.xml

EARのルートディレクトリに置いたjarファイルの中のMETA-INF/persistence.xml

EARのライブラリディレクトリに置いたjarファイルの中のMETA-INF/persistence.xml

一つのpersistence.xmlには複数の永続化ユニットを定義できます。永続化ユニットには名前を付ける必要があります。ただし，一つのEJB-JAR，WAR，EAR内には，重複した名前の永続化ユニットを複数定義することはできません。

EAR内に定義した永続化ユニットで管理されるクラスは，アプリケーションのクラスローダでロードされ，アプリケーション内のすべてのコンポーネントから参照できます。

また，別々のEJB-JARやWAR内のコンポーネントから，同じエンティティクラスを参照する場合，仮に永続化ユニットが別々であったとしても参照されるクラスは同じ一意なクラスとなります。

5.10　アプリケーション設定時の注意事項

ここでは，アプリケーションサーバ上で動作させるJPAを利用したアプリケーションを設定するときの注意事項を説明します。

5.10.1　エンティティクラス配置時の注意

アプリケーションサーバでは，エンティティクラスはEAR，EJB-JAR，またはWARの中のJPA仕様で定められた場所にパッケージングしてください。なお，エンティティクラスは，システムクラスパスに追加しないでください。

エンティティクラスは，アプリケーションのクラスローダまたはWebアプリケーションのクラスローダでローディングされるときに，Lazyフェッチなどを実現するために，JPAプロバイダによってクラスのバイトコード変換が行われることがあります。エンティティクラスがシステムクラスパスに含まれていると，エンティティクラスがシステムクラスローダでローディングされてしまうため，バイトコード変換が動作しません。このため，JPAプロバイダが正しく動作できなくなります。

5.10.2　永続化ユニット名の参照スコープ

アプリケーションに含まれるEJBやサーブレットなどのコンポーネントは，@PersistenceUnitや@PersistenceContextのunitName属性，DDに定義した<persistence-context-ref>タグ下または<persistence-unit-ref>タグ下の<persistence-unit-name>タグで永続化ユニット名を指定して，使用する永続化ユニットを参照します。ただし，各コンポーネントから参照できる永続化ユニットのスコープは，次のとおりになります。

EJB-JARまたはWARの中に定義した永続化ユニットは，EJB-JARまたはWARに含まれているコンポーネントから参照できます。

EARの中に定義した永続化ユニットは，EARに含まれるすべてのコンポーネントから参照できます。

EARで定義した永続化ユニットの名前と，EJB-JARまたはWARで定義した永続化ユニットの名前が重複している場合，EJB-JARまたはWAR内のコンポーネントからは，より狭い範囲で定義された永続化ユニットが優先されます。例えば，EARとWAR内に同じ名前の永続化ユニットが定義されている場合，WARに含まれているコンポーネントからは，WARで定義した永続化ユニットが優先して見えます。EARの中にある永続化ユニットは見えません。

(1)　永続化ユニット名を省略した場合に使用される永続化ユニット

アプリケーションサーバでJPAを使用する場合，コンポーネントが参照する永続化ユニット名を省略すると，次に示すルールで使用する永続化ユニットが決定されます。

コンポーネントが含まれるEJB-JARまたはWARの中に，永続化ユニットが一つだけ定義されている場合は，その永続化ユニットが使用されます。

コンポーネントが含まれるEJB-JARまたはWARの中に，永続化ユニットが一つも定義されていなく，EAR内に永続化ユニットが一つだけ定義されている場合は，EAR内の永続化ユニットが使用されます。

なお，次の条件に該当する場合は，使用する永続化ユニットを一つに特定できないため，永続化ユニット名は省略できません。

コンポーネントが含まれるEJB-JARまたはWARの中に，永続化ユニットが二つ以上定義されている場合

コンポーネントが含まれるEJB-JARまたはWARの中に，永続化ユニットが一つも定義されていなく，EAR内に永続化ユニットが二つ以上定義されている場合

(2)　「#」文法を使用したEARレベル永続化ユニットの明示的な参照

EARで定義した永続化ユニットの名前と，EJB-JARまたはWARで定義した永続化ユニットの名前が重複している場合，EJB-JARまたはWAR内のコンポーネントからは，より狭い範囲で定義された永続化ユニットが優先して見えます。ただし，永続化ユニットの参照名に「#」文法を使用することで，EARに定義した永続化ユニットを明示的に参照することもできます。「#」文法を使用する場合，永続化ユニット名は次のとおり指定します。

「コンポーネントが含まれるEJB-JARやWARから永続化ユニットルートへの相対パス」#「永続化ユニット名」

例えば，EARのejbs/myEjbs.jarに含まれたEJBから，EARのlib/persistenceUnitRoot.jarに含まれた永続化ユニット「myPersistenceUnit」を参照する場合，参照する永続化ユニット名は「../lib/persistenceUnitRoot.jar#myPersistenceUnit」になります。

5.10.3　アプリケーションのデプロイ時にチェックされる項目

JPAを利用したアプリケーションをJ2EEサーバにデプロイするとき，次の項目がチェックされます。

永続化ユニット定義のチェック

EntityManagerやEntityManagerFactoryのリファレンスのチェック

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

(1)　永続化ユニット定義のチェック

永続化ユニット定義でチェックされる内容を説明します。

(a)　persistence.xmlのバリデーション

アプリケーションに含まれるpersistence.xmlがpersistence_1_0.xsd，persistence_2_0.xsd，またはpersistence_2_1.xsdスキーマに従っているかを検証します。検証でエラーが発見された場合は，エラーメッセージKDJE56526-Eを出力してデプロイを中止します。

(b)　永続化ユニット名のチェック

永続化ユニット名が空文字ではないことをチェックします。永続化ユニット名が空文字である場合，エラーメッセージKDJE56505-Eを出力してデプロイを中止します。

また，アプリケーションのEARや，一つのEJB-JARまたはWARの中に，重複した名前の永続化ユニットが定義されていないかをチェックします。重複した名前の永続化ユニットが定義されている場合には，警告メッセージKDJE56500-Wを出力し，デプロイを継続します。なお，この場合は実際にデプロイされる永続化ユニットは一つだけです。

(c)　永続化ユニットが参照するデータソースの存在チェック

永続化ユニットのトランザクションタイプによってチェックされる内容が異なります。

永続化ユニットのトランザクションタイプがJTAの場合

チェックされる内容とチェック時にエラーが発生したときの動作を次の表に示します。

表5‒10　チェックされる内容とチェック時にエラーが発生したときの動作（トランザクションタイプがJTAの場合）

チェックされる内容

チェック時にエラーが発生したときの動作

永続化ユニットで使用するJTAデータソース（persistence.xmlの<jta-data-source>タグに指定されたもの，またはシステムプロパティで指定したデフォルト値）が指定されていること。

エラーメッセージKDJE56527-Eを出力して，デプロイを中止します。

JTAデータソースを提供するリソースアダプタが存在すること。

エラーメッセージKDJE56529-Eを出力して，デプロイを中止します。

JTAデータソースを提供するリソースアダプタが開始されていること。

リソースアダプタのトランザクションサポートレベルが，LocalTransactionまたはXATrasnactionになっていること。

エラーメッセージKDJE56531-Eを出力して，デプロイを中止します。

リソースアダプタのコネクションファクトリインタフェースが「javax.sql.DataSource」であること。

エラーメッセージKDJE56533-Eを出力して，デプロイを中止します。

永続化ユニットのトランザクションタイプがRESOURCE_LOCALの場合

チェックされる内容とチェック時にエラーが発生したときの動作を次の表に示します。

表5‒11　チェックされる内容とチェック時にエラーが発生したときの動作（トランザクションタイプがRESOURCE_LOCALの場合）

チェックされる内容

チェック時にエラーが発生したときの動作

永続化ユニットで使用する非JTAデータソース（persistence.xmlの<non-jta-data-source>タグに指定されたもの，またはシステムプロパティで指定したデフォルト値）が指定されていること。

エラーメッセージKDJE56528-Eを出力して，デプロイを中止します。

非JTAデータソースを提供するリソースアダプタが存在すること。

エラーメッセージKDJE56530-Eを出力して，デプロイを中止します。

非JTAデータソースを提供するリソースアダプタが開始されていること。

リソースアダプタのトランザクションサポートレベルが，NoTransactionになっていること。

エラーメッセージKDJE56532-Eを出力して，デプロイを中止します。

リソースアダプタのコネクションファクトリインタフェースが「javax.sql.DataSource」であること。

エラーメッセージKDJE56533-Eを出力して，デプロイを中止します。

(d)　永続化ユニットに指定されたプロバイダクラスのチェック

永続化ユニットが使用するJPAプロバイダのクラス（persistence.xmlの<provider>タグに指定されたクラス）を，アプリケーションからロードできることをチェックします。ロードに失敗した場合には，エラーメッセージKDJE56503-Eを出力して，デプロイを中止します。

(e)　永続化ユニットが参照するJARファイルの存在チェック

永続化ユニットが参照するJARファイル（persistence.xmlの<jar-file>タグに指定されたJARファイル）が存在するかをチェックします。JARファイルが存在しない場合には，エラーメッセージKDJE56506-Eを出力して，デプロイを中止します。

(f)　JPAプロバイダによる永続化ユニットの定義内容のチェック

JPAコンテナが解析したpersistence.xmlの内容からJPAプロバイダが永続化ユニットを生成します。永続化ユニットの定義に問題があり，JPAプロバイダがエラーを返した場合，エラーメッセージ（KDJE56539-E）を表示してデプロイメントを中止します。

(2)　EntityManagerやEntityManagerFactoryのリファレンスのチェック

EntityManagerやEntityManagerFactoryのリファレンスでチェックされる内容を説明します。

(a)　永続化ユニットの存在チェック

EJBやWebコンポーネントで定義したEntityManagerやEntityManagerFactoryのリファレンスで，指定した永続化ユニット名が実際に参照できる永続化ユニット名であるかをチェックします。また，永続化ユニット名が省略されている場合は，使用する永続化ユニットを特定できるかをチェックします。このチェックでエラーが発見された場合には，エラーメッセージKDJE56501-Eを出力して，デプロイを中止します。

(b)　コンテナ管理のEntityManagerを使用する場合のトランザクションタイプのチェック

コンテナ管理のEntityManagerを使用する場合は，永続化ユニットのトランザクションタイプがJTAになっていることをチェックします。このチェックでエラーが発生した場合は，エラーメッセージKDJE56534-Eを出力して，デプロイを中止します。

(c)　拡張永続化コンテキストがStateful Session Bean以外から使用されていないことをチェック

EntityManagerのリファレンスでは，永続化コンテキストのタイプにEXTENDEDが指定されている場合，そのリファレンスが定義されている場所がStateful Session Beanであることをチェックします。Stateful Session Bean以外の場所で定義されている場合には，エラーメッセージKDJE56535-Eを出力して，デプロイを中止します。

5.10.4　アプリケーションサーバでJPAを使用するときの注意事項

アプリケーションが取得できるEntityManagerの型は，JPAプロバイダのEntityManagerオブジェクトではなく，アプリケーションサーバが提供するEntityManagerのプロキシクラスです。

EntityManagerオブジェクトは，インジェクション，JNDIルックアップ，またはEntityManagerFactoryで取得できます。

なお，インジェクションを使用してEntityManagerを取得する場合には，EntityManagerをインジェクトするフィールドまたはメソッド引数の型は，javax.persistence.EntityManagerにしてください。

また，インジェクション，JNDIルックアップ，またはEntityManagerFactoryで取得したEntityManagerは，JPAプロバイダのEntityManagerの実装クラスにキャストできません。

JPAプロバイダのEntityManagerオブジェクトを取得する必要がある場合は，インジェクション，JNDIルックアップ，またはEntityManagerFactoryで取得したEntityManagerプロキシオブジェクトのgetDelegateメソッド，もしくはEntityManagerプロキシオブジェクトのunwrapメソッドを使用してください。

5.10.5　JPA機能を使用しないときの注意事項

JPA機能では，アプリケーションにpersistence.xmlが含まれている場合，デフォルトの設定では，JPA機能を使用するかどうかに関係なくpersistence.xmlの読み込みが実行されます。アプリケーションサーバでpersistence.xmlの解釈ができない場合，アプリケーションの開始に失敗します。

この状況を避けるため，アプリケーションにpersistence.xmlが含まれ，かつJPA機能を使用しない場合には，J2EEサーバのejbserver.jpa.disableプロパティに「true」を設定してください。これによって，アプリケーションサーバではpersistence.xmlの読み込みを実行しなくなります。

5.11　JPAのインタフェースについての注意事項

ここでは，JPAのインタフェースについての注意事項について説明します。

5.11.1　javax.persistence.EntityManagerインタフェース

javax.persistence.EntityManagerインタフェースの注事事項を説明します。

トランザクションスコープの永続化コンテキストを使用している場合，persist，merge，remove，refreshメソッドは，トランザクションコンテキスト内で呼び出す必要があります。トランザクションコンテキストが存在しない場合，javax.persistence.TransactionRequiredExceptionがスローされます。

find，getReferenceメソッドは，トランザクションコンテキスト外で呼び出すこともできます。トランザクションスコープの永続化コンテキストを使用している場合，結果のエンティティはdetached状態になります。拡張永続化コンテキストを使用している場合，結果のエンティティはmanaged状態になります。

EntityManagerから取得したQueryとEntityTransactionオブジェクトは，EntityManagerがオープンされている間，使用できます。

createQueryメソッドの引数が有効なJPQL（Java Persistence Query Language）でない場合，IllegalArgumentExceptionがスローされるか，クエリの実行が失敗します。ネイティブクエリが正しくない場合や，結果セットの定義がクエリの結果と互換性がない場合には，クエリが実行される時にPersistenceExceptionがスローされ，クエリの実行が失敗します。PersistenceExceptionは，可能な場合はデータベースの例外をラップしたものになっています。

EntityManagerインタフェースのメソッドでランタイム例外がスローされる場合，トランザクションはロールバックします。

close，isOpen，joinTransaction，getTransactionはアプリケーション管理のEntityManagerを管理するためのメソッドです。

EJB仕様では，Stateless Session Beanで，EntityManagerのメソッドを呼び出せるのは次のメソッドです。

ビジネスインタフェースまたはコンポーネントインタフェースのビジネスメソッド

ビジネスメソッド

インターセプタメソッド

タイムアウトコールバックメソッド

コンストラクタや，DIのセッターメソッド（setSessionContextメソッドを含む），ライフサイクルコールバックメソッド（PostConstructやPreDestroy）では，EntityManagerのメソッドを呼び出せません。許可されていない場所でEntityManagerのメソッドを呼び出した場合，KDJE56538-Eメッセージが出力され，java.lang.IllegalStateExceptionがスローされます。

EJB仕様では，Stateful Session BeanでEntityManagerのメソッドを呼び出せるのは，次のメソッドです。

ライフサイクルコールバックメソッド（PostConstructやPreDestroy）

ビジネスインタフェースまたはコンポーネントインタフェースのビジネスメソッド

ビジネスメソッド

インターセプタメソッド

SessionSynchronizationのafterBeginおよびbeforeCompletionメソッド

コンストラクタや，DIのセッターメソッド，SessionSynchronizationのafterCompletionメソッドでは，EntityManagerのメソッドを呼び出せません。許可されていない場所でEntityManagerのメソッドを呼び出した場合，KDJE56538-Eメッセージが出力され，java.lang.IllegalStateExceptionがスローされます。

なお，アプリケーションサーバでJPAを使用する場合は次の点にも注意してください。

アプリケーションがインジェクト，JNDIでのルックアップ，およびEntityManagerFactoryを使用して取得したEntityManagerは，JPAプロバイダが提供するEntityManagerオブジェクトではなく，アプリケーションサーバが提供するEntityManagerのプロキシクラスになっています。このプロキシクラスのgetDelegate()を使用すると，JPAプロバイダが提供するEntityManagerオブジェクトを取得できます。ただし，コンテナ管理のEntityManagerを使用する場合，EntityManagerのライフサイクルはコンテナが管理しているので，getDelegate()を使用して取得したEntityManagerオブジェクトのclose()をアプリケーションから呼ばないでください。

トランザクションスコープの永続化コンテキストを使用する場合で，トランザクションが存在しないときにEntityManagerのgetDelegate()を呼び出すと，コンテナは返されたEntityManagerをクローズできません。この場合には，アプリケーションでEntityManager.close()を呼び出す必要があります。

5.11.2　javax.persistence.EntityManagerFactoryインタフェース

javax.persistence.EntityManagerFactoryインタフェースの注事事項を説明します。

createEntityManagerに渡すマップには，JPAプロバイダのベンダ特有プロパティを含めることができます。JPAプロバイダが認識できないプロパティは，単に無視されます。

EJB仕様では，Stateless Session BeanでEntityManagerFactoryのメソッドを呼び出せるのは，次のメソッドです。

ライフサイクルコールバックメソッド（PostConstructやPreDestroy）

ビジネスインタフェースまたはコンポーネントインタフェースのビジネスメソッド

ビジネスメソッド

インターセプタメソッド

タイムアウトコールバックメソッド

コンストラクタや，DIのセッターメソッド（setSessionContextメソッドを含む）では，EntityManagerFactoryのメソッドを呼び出せません。

EJB仕様では，Stateful Session BeanでEntityManagerFactoryのメソッドを呼び出せるのは，次のメソッドです。

ライフサイクルコールバックメソッド（PostConstructやPreDestroy）

ビジネスインタフェースまたはコンポーネントインタフェースのビジネスメソッド

ビジネスメソッド

インターセプタメソッド

SessionSynchronizationのafterBeginおよびbeforeCompletionメソッド

コンストラクタや，Dependency Injectionのセッターメソッド，SessionSynchronizationのafterCompletionメソッドでは，EntityManagerFactoryのメソッドを呼び出せません。

6　JPA 2.2の利用

この章では，アプリケーションサーバでのJPA 2.2の利用について説明します。

6.1　この章の構成

この章では，JPA 2.2の機能について説明します。この章の構成を次の表に示します。

表6‒1　この章の構成

分類

タイトル

参照先

解説

JPA 2.2の概要

6.2

前提環境

6.3

JPA 2.2のサポート範囲

6.4

実装

アプリケーション実装時の注意事項

6.5

設定

クラスパスの設定

6.6

接続先のデータソースの設定

6.7

運用

障害対応用の情報の出力および確認

6.8

6.2　JPA 2.2の概要

JPAとは，データベース関連処理の設計およびコーディングの簡略化を目的として，Javaのオブジェクトとリレーショナルデータベースとのマッピング（O/R マッピング）に関して定められた仕様です。JPAを使用することで，ユーザはデータベースの持つ情報をJavaのオブジェクト（エンティティ）として操作することができるため，効率良くシステムを構築できます。

アプリケーションサーバでは，JSR 338 Java Persistence API（JPA） 2.2準拠のJPAプロバイダを提供し，J2EEサーバでの使用をサポートします。ただし，一部非サポートの機能があります。

6.3　前提環境

アプリケーションサーバが提供するJPAプロバイダは，次に示すデータベースと接続できます。

HiRDB

Oracle

JPAプロバイダは，DB Connectorを使用してデータベースを更新します。DB Connector はトランザクションタイプごとに種類が分かれます。アプリケーションサーバのJPAプロバイダで使用できるDB Connectorを次の表に示します。

表6‒2　JPAプロバイダで使用できるDB Connector

接続するデータベース

トランザクションタイプ

使用できるDB Connector

HiRDB

LocalTransaction

NoTransaction

DBConnector_HiRDB_Type4_CP.rar

XATransaction

DBConnecotr_HiRDB_Type4_XA.rar

Oracle

LocalTransaction

NoTransaction

DBConnector_Oracle_CP.rar

XATransaction

DBConnector_Oracle_XA.rar

6.4　JPA 2.2のサポート範囲

アプリケーションサーバでは一部の機能をサポートしていません。サポートしていない機能を使用した場合の動作は保証しません。

JPA 2.2対応ではサポートしていない機能を次の表に示します。

表6‒3　JPA 2.2対応ではサポートしていない機能

機能

JPA 2.2仕様書の該当個所

詳細

EntityListeners

3.5.1

EntityListenerへのCDIインジェクション

Stored Procedures※

3.10.17

[API]

javax.persistence.StoredProcedureQueryインタフェース

javax.persistence.ParameterMode列挙型

javax.persistence.NamedStoredProcedureQueriesアノテーション

javax.persistence.NamedStoredProcedureQueryアノテーション

javax.persistence.StoredProcedureParameterアノテーション

ParameterExpression Interface※

6.3.25

[API]

javax.persistence.criteria.CrteriaBuilderのparameterメソッド

javax.persistence.criteria.CrteriaBuilderのgetParametersメソッド

javax.persistence.criteria.ParameterExpressionインタフェース

Parameter Expressions※

6.5.10

Container-managed Persistence Contexts

7.6

SynchronizationType.UNSYNCHRONIZED

Java EE Deployment

9.1

BeanManagerの永続化プロバイダへの引き渡し

Schema Generation

9.2.1

[API]

javax.persistence.PersistenceのgenerateSchemaメソッド

javax.persistence.PersistenceのcreateEntityManagerFactoryメソッドに対し，引数のMapに以下のキーを指定する使用方法

javax.persistence.schema-generationから始まるキー

Schema Generation

9.4

References to EntityManager and EntityManagerFactory

10.5

[API]

javax.persistence.SynchronizationType列挙型

注※　接続するデータベースがHiRDBの場合だけ，サポートしていません。

さらに，Cosminexus Version 9以前のCosminexus JPAプロバイダ（CPJAプロバイダ）でサポートしていた日立独自の機能は使用できません。ただし，上記の表以外のJPA 2.2仕様で規定されている機能は使用できます。

6.5　アプリケーション実装時の注意事項

アプリケーションサーバが提供するJPAプロバイダの接続先DBMSにHiRDBを使用した場合の注意事項を次に示します。

6.5.1　主キーの生成方式に関する注意事項

ここで説明する機能は，Entityオブジェクトを用いてレコードを挿入するときに，ユーザが主キー値を指定しなくても一意の値が格納されるようにする機能です。ユーザアプリケーションのEntityクラスに定義する@GeneratedValueのstrategy要素に設定する値によって主キーの生成方法が異なります。この機能はJPA規約で規定された生成パターンを提供しますが，サポートするパターンは各データベースに依存します。HiRDB使用時に，@GeneratedValueのstrategy要素に設定する値による主キーの生成方式の違いを次の表に示します。

表6‒4　@GeneratedValueのstrategy要素に設定する値による主キーの生成方式の違い

Strategy要素の定義値

HiRDB使用時の処理内容

標準仕様の概要

GenerationType.TABLE

主キー値を保持しておくためのテーブルを使用して，主キー値を生成します。

主キー値を保存しておくためのテーブルを使用して，主キー値を割り当てます。

GenerationType.SEQUENCE

TABLEと同じ処理をします。

データベースのシーケンス機能を使用し，主キー値を割り当てます。

GenerationType.IDENTITY

TABLEと同じ処理をします。

データベースのidentity列を使用して主キー値を割り当てます。

GenerationType.AUTO

TABLEと同じ処理をします。

使用しているデータベースに適した生成方法を選択する方法です。

6.5.2　JPQLの注意事項

JPQLを使用する場合の注意事項を次に示します。

位置パラメタおよび名前パラメタを指定できないJPQLの関数

次に示すJPQLの関数には，位置パラメタおよび名前パラメタを指定できません。指定した場合の動作は保証しません。これらの関数の機能を使用したい場合は，ネイティブSQLを使用してください。

ABS

CONCAT

IS [NOT] NULL

LENGTH

LOCATE

LOWER

MOD

SQRT

SUBSTRING

TRIM

UPPER

動作を保証しない例を次に示します。

（例）
Query query1 = em.createQuery(
"SELECT  o FROM TestEntity o "+
                "WHERE o.name=TRIM(LEADING FROM ?1)")
              .setParameter(1, "  HitachiTaro");

null値の指定

WHERE句またはHAVING句に位置パラメタや名前パラメタを使用する場合，値にnullを指定できません。指定した場合の動作は保証しません。

動作を保証しない例を次に示します。

（例）
int no_A=2;
int no_B=4;
Query query2 = em.createQuery(
"SELECT  o FROM TestEntity o WHERE o.id = ?1 + ?2")
               .setParameter(1, no_A)
               .setParameter(2, no_B);

？パラメタの指定

四則演算子（＋，−，＊，／）の両側に，？パラメタは指定できません。また，比較演算子（=，>，>=，<，<=，< >）の両側に？パラメタを指定すること，片側に？パラメタを指定してもう一方にリテラルを指定することはできません。指定した場合の動作は保証しません。JPQLの中で四則演算や比較演算をしないで，四則演算や比較演算の操作をしてからJPQLを使用してください。

動作を保証しない例を次に示します。

（例）
int cmp_no=3;
Query query3 = em.createQuery(
"SELECT  o FROM TestEntity o WHERE o.id = ?1 AND ?1 < 9")
               .setParameter(1, cmp_no);

6.5.3　時間を扱う際の注意事項

データベースに対してエンティティオブジェクトの登録，検索などの操作をする際に，次の条件をすべて満たすと，java.sql.SQLExceptionが発生するおそれがあります。

HiRDBのTIMESTAMP型の時刻の精度が，9けた以上の小数秒まで対応していない。

エンティティオブジェクトのフィールドや検索条件に，時間を格納するクラス※のオブジェクトが指定されていて，かつ，そのオブジェクトの小数秒部分にマイクロ秒より精度の高い値が指定されている。

注※

時間を格納するクラスは次のどれかです。

java.sql.Timestamp

java.time.LocalTime

java.time.OffsetTime

java.time.LocalDateTime

java.time.OffsetDateTime

java.sql.SQLExceptionが発生する場合は，小数秒部分のナノ秒を切り捨ててマイクロ秒にしてください。

ナノ秒を切り捨ててマイクロ秒にする例を次に示します。

（例1）java.time.LocalTimeクラスの小数秒部分のナノ秒を切り捨ててマイクロ秒にする場合

LocalTime lt = LocalTime.now();
lt = lt.truncatedTo(java.time.temporal.ChronoUnit.MICROS);

（例2）java.sql.Timestampクラスの小数秒部分のナノ秒を切り捨ててマイクロ秒にする場合

Timestamp ts = Timestamp.valueOf(java.time.LocalDateTime.now());
int before_nanos = ts.getNanos();
// ナノ秒部分を”000”に変換する。
int after_nanos = before_nanos/1000*1000;
ts.setNanos(after_nanos);

6.6　クラスパスの設定

アプリケーションサーバが提供するJPAプロバイダは，デフォルトではクラスパスに入っていません。アプリケーションサーバが提供するJPAプロバイダを使用する場合は，J2EEサーバのusrconf.cfg（Javaアプリケーション用オプション定義ファイル）のadd.class.pathキーを使用して，次のJARファイルをクラスパスに追加する必要があります。

add.class.path=<cosminexus.home>/CC/javaee/1100/lib/jpa-provider.jar

このJARファイルをクラスパスに追加しない場合は，ユーザ側で用意した任意のJPA 2.2対応JPAプロバイダを使用できます。

6.7　接続先のデータソースの設定

persistence.xmlのデータソースの指定では，DB Connectorを参照するリソース参照名，またはユーザ指定名前空間機能を使用して付けたDB Connectorの別名を設定できます。

persistence.xmlに指定するDB Connectorには，Connector属性ファイルを用いてDB Connectorの別名を設定してください。Connector属性ファイルに設定するタグを次の表に示します。

表6‒5　Connector属性ファイルに設定するタグ

設定するタグ

設定内容

<resource-external-property>−<optional-name>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合は，persistence.xmlに指定したデータソース名と同じものを指定します。

リソースアダプタの別名を使用しない場合は設定不要です。

<resource-external-property>−<res-auth>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合は，リソースの認証方式として必ず「Container」を指定してください。

<resource-external-property>−<res-auth>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合は，リソース接続を共有するかどうかの指定として必ず「Shareable」を指定してください。

<property>−<property-name>タグ

<property>−<property-value>タグ

データベースへの接続情報を指定します。

ユーザ名の指定

<property-name>タグにUserを，<property-value>タグにデータベース接続で使用するユーザ名を指定してください。

パスワードの指定

<property-name>タグにPasswordを，<property-value>タグにデータベース接続で使用するパスワードを指定してください。

<connection-definition>−<transaction-support>タグ

トランザクションのサポートレベルを指定します。

ここに指定する値は，persistence.xmlの<persistence-unit>タグのtransaction-type属性に指定した値と合わせてください。

6.7.1　Connector属性ファイル設定時の注意事項

Connector属性ファイルの設定時の注意事項を次に示します。

(1)　ステートメントプール機能を使用しない

JPAプロバイダとDBMSを接続する場合は，ステートメントプール機能を使用しないことを推奨します。

次に示す<config-property>タグの<config-property-value>タグに0を指定して，ステートメント機能を抑止してください。

PreparedStatementPoolSize

CallableStatementPoolSize

(2)　コネクション数に応じてコネクションプールの値を設定する

JPAプロバイダ機能とDBMSを接続する場合は使用するコネクション数に応じてコネクションプールの値を設定する必要があります。

次に示す<property>タグの<property-value>タグに値を設定することでコネクションプールの数を設定できます。

MinPoolSize

MaxPoolSize

コネクション数の見積もり方法

JPAプロバイダ機能を使用しDBMSと接続するコネクション数

　=　JPAプロバイダ機能を利用するアプリケーションの同時実行数※

注※

JPAプロバイダ機能を利用したアプリケーションで，複数の永続化ユニットのEntityManagerを利用する場合や，ビジネスメソッド呼び出しでEntityManagerの利用するトランザクションが異なる場合，EntityManagerごとにそれぞれコネクションが必要となります。

なお，JPA 2.2機能とは別にコネクションを取得する場合，コネクションシェアリング機能を利用することで，コネクション数を削減できます。コネクションシェアリング機能の詳細については，「3.14.3　コネクションシェアリング・アソシエーション」を参照してください。

6.8　障害対応用の情報の出力および確認

JPA 2.2を使用したアプリケーションで障害が発生した場合，一部のログは「OSSが出力するメッセージ」として出力されます。詳細は，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「OSSが出力するメッセージ」を参照してください。

7　CJMSプロバイダ

この章では，CJMSプロバイダを使用してメッセージを送受信する機能について説明します。CJMSプロバイダは，JMS仕様に準拠したメッセージの送受信を実現するための機能です。

7.1　この章の構成

この章では，CJMSプロバイダの機能について説明します。

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

表7‒1　この章の構成（CJMSプロバイダ機能）

分類

タイトル

参照先

解説

CJMSプロバイダの概要

7.2

CJMSPリソースアダプタとCJMSPブローカーの配置

7.3

メッセージングモデルの種類

7.4

メッセージの構成

7.5

メッセージセレクターによる受信メッセージの選択

7.6

メッセージ配信の高信頼性確保の仕組み

7.7

CJMSPブローカーの機能

7.8

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

7.9

Message-driven Beanの呼び出し

7.10

実装

アプリケーション実装時の制限事項

7.11

DDでの定義

7.12

設定

実行環境の構築の流れ

7.13

CJMSPブローカーの設定

7.14

CJMSPリソースアダプタの設定

7.15

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

7.16

運用

CJMSプロバイダを使用する場合のシステムの開始と停止

7.17

障害対応用の情報の確認

7.18

注意事項

CJMSプロバイダ使用時の注意事項

7.19

7.2　CJMSプロバイダの概要

この節では，CJMSプロバイダの概要について説明します。

7.2.1　CJMSプロバイダとは

CJMSプロバイダは，メッセージの送受信を実現するためのアプリケーションサーバの機能です。JMS 1.1の仕様に準拠しています。

CJMSプロバイダで送受信するメッセージは，プロデューサーによって作成され，送信されます。送信されたメッセージは，CJMSプロバイダが管理する送信先（キューまたはトピック）に登録されます。その後，コンシューマーに配信され，処理が実行されます。

CJMSプロバイダを使用したメッセージの送受信の概要を次の図に示します。

図7‒1　CJMSプロバイダを使用したメッセージの送受信の概要

送信先を介してメッセージをやり取りする仕組みによって，メッセージの送信側と受信側での非同期処理を実現します。

7.2.2　CJMSプロバイダのアプリケーションサーバ内での位置づけ

CJMSプロバイダは，CJMSPブローカーとCJMSPリソースアダプタという二つのコンポーネントで構成されます。CJMSPブローカーは，メッセージの送信先の管理をするためのコンポーネントです。J2EEサーバとは別のプロセスとして動作します。CJMSPリソースアダプタは，J2EEサーバからCJMSPブローカーに接続するためのリソースアダプタです。

これらのコンポーネントは，アプリケーションサーバだけで使用できます。

CJMSプロバイダのアプリケーションサーバ内での位置づけについて，次の図に示します。

図7‒2　CJMSプロバイダのアプリケーションサーバ内での位置づけ

CJMSプロバイダを使用するJ2EEアプリケーションは，サーブレット，JSP，Enterprise Beanなどで構成されます。J2EEアプリケーションは，CJMSPリソースアダプタを経由して，CJMSPブローカーの機能を使用します。

CJMSプロバイダを使用してメッセージを送受信するプロデューサーおよびコンシューマーには，J2EEサーバ上のJ2EEアプリケーションが該当します。メッセージの送信側であるプロデューサーでは，サーブレット，JSP，Enterprise Beanなどが動作します。また，受信側であるコンシューマーでは，Message-driven Beanが動作します。送信側と受信側のJ2EEサーバが別のマシンにある場合は，両方のマシンにCJMSPリソースアダプタが必要です。

なお，JMSの機能を使用するJ2EEアプリケーションをJMSアプリケーションともいいます。

7.2.3　CJMSプロバイダの機能の概要

CJMSプロバイダでは，JMS仕様に準拠したメッセージ送受信を実現するための機能や，送受信を効率的に実現するための管理機能や監視機能などを提供しています。

CJMSプロバイダの機能の概要を次の表に示します。機能の詳細については，参照先の説明を参照してください。

表7‒2　CJMSプロバイダの機能

機能

概要

参照先

JMS仕様に準拠したメッセージの送受信

PTPメッセージングモデルまたはPub/SubメッセージングモデルでJMSメッセージを送受信します。Pub/Subメッセージングモデルでは，永続化サブスクライバーも使用できます。

受信側では，メッセージセレクターを使用して受信するメッセージを選択できます。

メッセージングモデルの種類

7.4

メッセージの構成

7.5

メッセージセレクターによる受信メッセージの選択

7.6

メッセージ配信の高信頼性確保の仕組み

JTAトランザクションの利用や，メッセージの種類ごとの流量制御の実施によって，メッセージ配信の高信頼性を確保します。

7.7

CJMSPブローカーの機能

メッセージの送信先を管理します。また，永続化したメッセージも管理します。

そのほか，CJMSPブローカーは，コネクションやルーティングの管理や，性能監視などをするための機能も備えています。

7.8

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

J2EEサーバ上のJ2EEアプリケーションとCJMSPブローカーを接続します。

7.9

Message-driven Beanの呼び出し

Message-driven Beanをメッセージのコンシューマーとして，業務を実行します。

7.10

このほか，CJMSプロバイダでは，実運用時に必要な運用管理のための機能や障害に対応するための機能も備えています。これらの機能によって，信頼性の高いメッセージングシステムを構築・運用できます。

7.3　CJMSPリソースアダプタとCJMSPブローカーの配置

この節では，CJMSPリソースアダプタとCJMSPブローカーの配置について説明します。CJMSPリソースアダプタとCJMSPブローカーは，同じマシンまたは異なるマシンに配置できます。

一つのCJMSPブローカーに対して，CJMSPリソースアダプタは複数配置できます。ただし，一つのJ2EEサーバにデプロイできるCJMSPリソースアダプタは一つです。

CJMSPリソースアダプタおよびCJMSPブローカー以外のコンポーネントの配置については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.8　サーバ間で非同期通信をする場合の構成を検討する」を参照してください。なお，CJMSPブローカーが管理する永続化メッセージは，CJMSPブローカーと同じマシンにファイルとして保存されます。

7.3.1　一つのCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成

CJMSPリソースアダプタとCJMSPブローカーを一つずつ配置する構成です。CJMSPブローカーは，J2EEサーバと同じマシンまたは異なるマシンに配置します。CJMSPブローカーが管理する永続化メッセージおよび管理情報はファイルで管理されます。

一つのCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成を次の図に示します。

図7‒3　一つのCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成

7.3.2　複数のCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成

複数のCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成です。CJMSPブローカーは，J2EEサーバと同じマシンまたは異なるマシンに配置します。CJMSPリソースアダプタは，J2EEサーバごとに一つデプロイできます。

この構成では，複数のCJMSPリソースアダプタによって，一つのCJMSPブローカーが管理する送信先やリソースが共有されます。CJMSPブローカーが管理する永続化メッセージおよび管理情報はファイルで管理されます。

複数のCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成を次の図に示します。

図7‒4　複数のCJMSPリソースアダプタに対して一つのCJMSPブローカーを配置する構成

7.4　メッセージングモデルの種類

メッセージの送受信の方法は，メッセージングモデルによって異なります。

CJMSプロバイダでは，次の2種類のメッセージングモデルに対応しています。

PTPメッセージングモデル

Pub/Subメッセージングモデル

ここでは，それぞれのメッセージングモデルでのメッセージ送受信の概要について説明します。

なお，これらのメッセージングモデルは，JMS仕様に準拠しています。

7.4.1　PTPメッセージングモデル

PTPメッセージングモデルは，ポイント・ツー・ポイント（Point-to-Point）方式でメッセージを送受信するためのモデルです。

(1)　PTPメッセージングモデルによるメッセージの送受信

PTPメッセージングモデルでは，メッセージを作成して送信する送信側のクライアント（プロデューサー）をセンダーといいます。また，メッセージを受信する側のクライアント（コンシューマー）をレシーバーといいます。

センダーから送信されたメッセージは，キューという送信先に登録されます。キューに格納されたメッセージは，レシーバーが受け取ると，キューから削除されます。

PTPメッセージングモデルでのメッセージの流れを次の図に示します。

図7‒5　PTPメッセージングモデルでのメッセージの流れ

メッセージは，センダーから送信され，キューに登録されます。キューに登録されたメッセージは，その時に起動しているレシーバーのどれかに配信されます（メッセージ1，メッセージ2）。レシーバーに配信されたメッセージは，キューから削除されます。配信先のレシーバーがない場合，メッセージはキューに滞留します（メッセージ3）。

なお，メッセージが登録されたキューの状態は，JMS仕様で規定されているキューブラウザーを使用して確認できます。キューブラウザーについては，JMS仕様を参照してください。

(2)　PTPメッセージングモデルの特徴

PTPメッセージングモデルの特徴を次に示します。

メッセージの送信〜処理実行までの特徴

PTPメッセージングモデルでのメッセージの送信から処理実行までの特徴について説明します。

一つまたは複数のセンダーからキューにメッセージを送信できます。

レシーバーは，メッセージを送信したセンダーがどれかに関係なく，メッセージを受け取り，処理します。

一つのメッセージは，一つのレシーバーだけで処理されます。

センダーとレシーバーが処理を実行するタイミングに依存性はありません。センダーがメッセージを送信したときにレシーバーが起動していなくても，レシーバーは次に起動したときにメッセージを受け取ることができます。

複数のレシーバーが同じキューからメッセージを受け取る場合に，メッセージの順序性が重要でないときには，それぞれのレシーバーで処理が実行されます。

メッセージは，センダーが送信した順序でキューに登録されます。

メッセージの処理順序は，メッセージの有効期限，メッセージに設定された優先順位，およびレシーバーが使用しているメッセージセレクターによって決定され，この順序に従ってレシーバーが呼び出されます。

レシーバーがまったく起動していない場合，送信されたメッセージはキューで保管されます。

システムの特徴

センダーとレシーバーは，動的に追加・削除できます。これによって，使用状況に応じてシステムを拡張，縮小できます。

CJMSプロバイダとの接続で使用するコネクションは，複数のセンダーで共有できます。また，CJMSプロバイダが管理するコネクションは，複数のレシーバーで共有できます。例えば，センダー1とセンダー2でコネクションを共有したり，レシーバー1とレシーバー2でコネクションを共有したりできます。コネクションについては，「7.8.1　コネクションサービス」を参照してください。

7.4.2　Pub/Subメッセージングモデル

Pub/Subメッセージングモデルは，パブリッシュ・サブスクライブ（Publish-Subscribe）方式でメッセージを送受信するためのモデルです。

(1)　Pub/Subメッセージングモデルによるメッセージの送受信

Pub/Subメッセージングモデルでは，メッセージを作成して送信する送信側のクライアント（プロデューサー）をパブリッシャーといいます。また，メッセージを受信する側のクライアント（コンシューマー）をサブスクライバーといいます。

パブリッシャーから送信されたメッセージは，トピックという送信先に登録されます。トピックに登録されたメッセージは，そのトピックに対して配信を申し込んでいた一つまたは複数のサブスクライバーに配信されます。

Pub/Subメッセージングモデルでのメッセージの流れを次の図に示します。

図7‒6　Pub/Subメッセージングモデルでのメッセージの流れ

メッセージは，パブリッシャーから送信され，トピックに登録されます。図の場合，トピック1にはサブスクライバー1，トピック2にはサブスクライバー2とサブスクライバー3が登録されています。このとき，トピック1に登録されたメッセージ1とメッセージ2はサブスクライバー1に配信されます。トピック2に登録されたメッセージ3はサブスクライバー2とサブスクライバー3に配信されます。

(2)　Pub/Subメッセージングモデルの特徴

Pub/Subメッセージングモデルの特徴を次に示します。

メッセージの送信〜処理実行までの特徴

一つまたは複数のパブリッシャーから，メッセージをトピックに登録できます。

一つまたは複数のサブスクライバーが，トピックからメッセージを取り出して処理できます。

サブスクライバーは，配信を申し込んだトピックに登録されたすべてのメッセージについて，受信して処理できます。ただし，メッセージセレクターで設定した基準に該当しないメッセージ，または受信する前にメッセージの有効期限が過ぎたメッセージについては受信できません。

メッセージは，パブリッシャーが送信した順序でトピックに登録されます。ただし，サブスクライバーで処理される順序は，それぞれのメッセージの有効期限，優先順位，またはサブスクライバーで設定されたメッセージセレクターの内容によって決まります。

パブリッシャーとサブスクライバーが処理を実行するタイミングには依存性があります。トピックに登録されたメッセージは，メッセージが登録される前に開始されていたサブスクライバーだけに配信されます。

サブスクライバーの属性に「NoLocal」を指定した場合，サブスクライバーが使用しているコネクションと同じコネクションで送信されたメッセージの受信を抑止できます。この属性のデフォルトは「false」です。

システムの特徴

パブリッシャーとサブスクライバーは動的に追加・削除できます。これによって，使用状況に応じてシステムを拡張，縮小できます。

CJMSプロバイダとの接続で使用するコネクションは，複数のプロデューサーで共有できます。なお，コネクションを共有しているかどうかに関係なく，複数のプロデューサーから同じのトピックにメッセージを送信できます。

CJMSプロバイダとの接続で使用するコネクションは，複数のサブスクライバーで共有できます。なお，コネクションを共有しているかどうかに関係なく，複数のサブスクライバーから同じトピックに接続できます。

(3)　永続化サブスクライバーの利用

トピックに登録されたメッセージは，メッセージ登録時に開始されていたサブスクライバーだけが受信できます。通常のサブスクライバーは，停止していた期間に登録されたメッセージは受信できません。

これに対して，サブスクライバーを永続化することで，停止していた期間に登録されたメッセージも受信できるようになります。永続化したサブスクライバーを永続化サブスクライバーといいます。

永続化サブスクライバーが登録されたトピックのメッセージは，次のどちらかの状態になるまで削除されません。

永続化サブスクライバーに配信された場合

メッセージの有効期限が過ぎた場合

永続化サブスクライバーを利用する場合，そのサブスクライバーに固有の識別子と名称を登録します。登録した情報は，CJMSPブローカーによって保持されます。永続化サブスクライバーが停止しているときに登録されたメッセージは，登録した識別子および名称のサブスクライバーが再開されたときに，そのサブスクライバーに配信されます。

永続化サブスクライバーを利用した場合のメッセージの送受信の流れを次の図に示します。

図7‒7　永続化サブスクライバーを利用した場合のメッセージの送受信の流れ

永続化サブスクライバーを利用した場合のメッセージの送受信の流れについて説明します。なお，説明の番号は図中の番号と対応しています。

サブスクライバー1を永続化サブスクライバーとしてトピックに登録します。

識別子（ClientID）は，「1」とします。

パブリッシャー1が，メッセージ1をトピックに登録します。

サブスクライバー1は，メッセージ1をトピックから受信します。

サブスクライバー1を停止します。

停止した状態になると，トピックに登録されたメッセージは受信できません。

パブリッシャー2が，メッセージ2をトピックに登録します。サブスクライバー1は停止中のため，メッセージ2を受信できません。ただし，サブスクライバー1は永続化サブスクライバーとして登録されているため，このメッセージは登録された永続化サブスクライバーがメッセージを受信するまでトピックで保管されます。

サブスクライバー2を永続化サブスクライバーとしてトピックに登録します。このとき，識別子（ClientID）を「1」として，サブスクライバーの名称はサブスクライバー1と同じ値にします。

永続化サブスクライバーの情報を保持しているCJMSPブローカーは，識別子と名称からサブスクライバー2は登録済みの永続化サブスクライバーが再開したものと判断します。

トピックに保管されていたメッセージ2がサブスクライバー2に配信されます。

永続化サブスクライバーの指定を解除する場合は，次のどちらかの方法で解除してください。

cjmsicmd destroy durコマンドを実行する

unsubscribeメソッドを使用する

cjmsicmd destroy durコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjmsicmd destroy dur（永続化サブスクライバーの破棄）」を参照してください。

unsubscribeメソッドを使用すると，サブスクライバーのために保持されたトピックの状態を解除できます。ただし，このメソッドは，次のタイミングでは使用しないでください。

永続化サブスクライバーの指定を解除する対象のトピックに対して，開始されているサブスクライバーがある場合

トピックに配信されたメッセージが，未決着のトランザクションである場合

そのセッションでの配信が承認されていない場合

なお，確認応答モードが「CLIENT_ACKNOWLEDGE」のセッションによって永続化サブスクライバーが作成された場合に，メッセージ受信が確認されていない状態でunsubscribeメソッドが実行されたときには，メッセージは送信先に残ってしまいます。この状況を避けるため，unsubscribeメソッドを使用する場合，事前にcjmsicmd purge durコマンドを実行して，永続化サブスクライバーに関連づけられているすべてのメッセージを削除してください。

注意事項

一時的な送信先として作成したトピックに対して，永続化サブスクライバーは登録できません。作成しようとすると，例外がスローされます。

7.5　メッセージの構成

CJMSプロバイダで扱うメッセージは，次に示す要素で構成されます。

メッセージヘッダー

メッセージプロパティ

メッセージボディ

これらの要素については，JMSの仕様として規定されています。詳細は，JMSの仕様を参照してください。

7.6　メッセージセレクターによる受信メッセージの選択

コンシューマーは，受信するメッセージをメッセージセレクターによって選択できます。メッセージセレクターを使用したコンシューマーでは，送信先に登録されたメッセージのうち，必要なものだけを受信できます。

メッセージセレクターでは，選択対象の指定にメッセージプロパティの値を使用します。コンシューマーは，メッセージセレクターに指定した選択条件とメッセージプロパティの値を比較し，条件に一致するメッセージだけを受信します。

メッセージセレクターを使用した受信メッセージの選択の概要を次の図に示します。

図7‒8　メッセージセレクターを使用した受信メッセージの選択の概要

この図では，コンシューマー2に「Color=red」という選択条件を指定しています。コンシューマー1にはメッセージセレクターは指定しません。

プロデューサーからColorプロパティが異なる四つのメッセージを送信した場合，メッセージセレクターを使用していないコンシューマー1はすべてのメッセージを受信します。コンシューマー2は選択条件に一致する二つのメッセージだけを受信します。

なお，メッセージセレクターの選択条件は，コンシューマーで動作するMessage-driven Beanの属性，またはJMSのAPIで指定します。属性の詳細については，「7.12　DDでの定義」を参照してください。また，選択条件の構文およびAPIについては，JMS仕様を参照してください。

参考

メッセージセレクターは，キューブラウザーでも使用できます。

7.7　メッセージ配信の高信頼性確保の仕組み

この節では，CJMSプロバイダを使用したメッセージ配信で高信頼性を確保するための仕組みについて説明します。

7.7.1　メッセージ配信時に発生するトラブルの種類と信頼性を確保する方法

メッセージは，次の2段階で配信されます。

プロデューサーからCJMSPブローカーが管理する送信先への配信

CJMSPブローカーが管理する送信先からコンシューマーへの配信

この間，次のタイミングでトラブルが発生した場合に，メッセージが失われるおそれがあります。

メッセージ転送時

プロデューサーからCJMSPブローカーが管理する送信先へのメッセージ転送時

CJMSPブローカーが管理する送信先からコンシューマーへのメッセージ転送時

CJMSPブローカーの障害発生時

これらの場合に信頼性を確保する方法について，次に示します。

メッセージ転送時にトラブルが発生した場合

メッセージ転送時のメッセージの信頼性を確保する方法としては，JMS仕様で規定されている，メッセージ配信の確認応答（Acknowledge Mode）の仕組みを使用できます。

また，トランザクションの利用によって，メッセージの送信から受信までにトラブルが発生した場合に，システムの整合性を保つことができます。

CJMSPブローカーに障害が発生した場合

CJMSPブローカーに障害が発生した場合に送信先に登録されていたメッセージを保持するためには，メッセージを永続化しておくことが必要です。CJMSプロバイダでは，メッセージをファイルに保存して永続化できます。

この節では，これらの方法のうち，トランザクションの利用によって信頼性を確保する方法について，「7.7.2　トランザクションの利用」で説明します。

また，メッセージ配信時には，送受信されるメッセージの量によって，メモリリソースの問題が発生することもあります。メモリリソースを適切に運用するためにメッセージの流量を制御する方法については，「7.7.3　メッセージの流量制御」で説明します。

なお，メッセージ配信の確認応答の詳細については，JMS仕様を参照してください。なお，CJMSPブローカーによるファイルの永続化については，「7.8.4　管理情報およびメッセージの永続化サービス」で説明します。

7.7.2　トランザクションの利用

トランザクションを利用すると，メッセージの作成から処理の実行までを一連の処理としてまとめることができます。トランザクションに含まれるすべての操作は，クライアント側のアプリケーション（メッセージを送信したアプリケーション）がトランザクションをコミットしたときに完了します。

CJMSプロバイダでは，JTAトランザクションを利用できます。

JTAトランザクションは，アプリケーションサーバのトランザクション管理用API（JTA）によって管理されます。トランザクション内の操作が失敗した場合，アプリケーションサーバによって例外が処理され，トランザクション内の処理がリトライまたはロールバックされます。ローカルトランザクションの管理には，BMTまたはCMTを使用できます。BMTまたはCMTによるトランザクションの管理については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7　Enterprise Beanでのトランザクション管理」を参照してください。

注意事項

CJMSプロバイダでは，JTAトランザクションを利用する場合，コンテナがBeanの代わりにJMSセッションのトランザクションを管理します。このため，次のメソッドの引数「transacted」の値に「true」は指定しないでください。

createSession(boolean transacted, int acknowledgeMode)メソッド

createQueueSession(boolean transacted, int acknowledgeMode)メソッド

createTopicSession(boolean transacted, int acknowledgeMode)メソッド

「true」を指定した場合は，無視され，警告メッセージが出力されます。

なお，EJBアプリケーションを使用する場合，トランザクション内でJMSの承認メソッドを使用しないでください。承認メソッドを指定していないトランザクションコンテキスト内では，コンテナによってメッセージの承認が管理されます。

また，一つのトランザクション内で，大量のメッセージを送信すると,メッセージの配信確認に関する情報を管理しているファイルの容量が増え，ディスク容量を圧迫するおそれがあります。大量のメッセージを送信する場合，性能テストを実施して，必要なファイルサイズを見積もってください。

7.7.3　メッセージの流量制御

ここでは，メッセージの流量制御について説明します。

CJMSプロバイダを使用したメッセージの送受信では，プロデューサーからコンシューマーに送信するメッセージのほか，CJMSプロバイダが使用する制御用のメッセージも送受信されます。これらのメッセージの送受信は，お互いに影響します。例えば，プロデューサーからコンシューマーに送信したメッセージに対するCJMSPブローカーでの確認応答の承認が遅れた場合などは，制御用のメッセージの送受信も遅れてしまうことになり，システム全体のパフォーマンスが低下してしまいます。

コネクション上のこれらのメッセージの流量を制御することで，メッセージ送受信の信頼性を高め，システムのパフォーマンスを向上させることができます。

CJMSプロバイダでは，メッセージの流量を制御するために，コンシューマーごとに送信するメッセージの流量を制限できます。

例えば，PTPメッセージングモデルでメッセージを送受信している場合，それぞれのコンシューマーの処理速度が低いときには，コンシューマー単位に配信するメッセージを制限します。これによって，複数のコンシューマーを使用してラウンドロビン方式で処理を実行し，システム全体の処理性能を向上させることができます。コンシューマー単位のメッセージの流量には，複数のコンシューマーに分散してメッセージを配信するためのオーバーヘッドの増加との関係を考慮して，適切な値を決定してください。

コンシューマー単位の制限値（consumerFlowLimit）については，送信先ごとにcjmsicmd create dstコマンドで設定します。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjmsicmd create dst（物理的送信先の作成）」を参照してください。なお，consumerFlowLimitの値は，コンシューマーで動作しているMessage-driven Bean単位の同時実行数（プールの最大インスタンス数）との関係も考慮して設定する必要があります。設定のパターンの例を次に示します。

「consumerFlowLimitの値＜Message-driven Beanのプールの最大インスタンス数」と設定した場合

Message-driven Beanでは，consumerFlowLimitで指定した数のスレッドで処理が実行されます。

「consumerFlowLimitの値＝Message-driven Beanのプールの最大インスタンス数」と設定した場合

プロデューサーから送信されたメッセージの数がconsumerFlowLimit以下の場合は，一つのコンシューマーですべての処理が実行されます。

プロデューサーから送信されたメッセージの数がconsumerFlowLimitを超える場合は，複数のコンシューマーで処理が実行されます。

consumerFlowLimitの設定による流量制御の概要を次の図に示します。

図7‒9　consumerFlowLimitの設定による流量制御の概要

この例では，コンシューマー単位の制限値として，consumerFlowLimitを「10」と設定しています。プロデューサーから12個のメッセージが送信された場合，送信先からコンシューマー1には制限値である10個のメッセージが送信され，残りのメッセージはコンシューマー2に送信されます。各コンシューマーでは，Message-driven Beanの最大インスタンス数で設定した数以下のスレッドを使用して処理が実行されます。

7.8　CJMSPブローカーの機能

この節では，CJMSPブローカーの機能について説明します。

CJMSPブローカーの主な機能を次に示します。

コネクションサービス

送信先の管理とルーティングサービス

CJMSPブローカーの性能監視

管理情報とメッセージの永続化サービス

なお，このほか，CJMSPブローカーはログ出力の機能も備えています。CJMSPブローカーのログ出力については，「7.18　障害対応用の情報の確認」を参照してください。

7.8.1　コネクションサービス

コネクションサービスは，TCP層上でのCJMSPブローカーとCJMSPリソースアダプタの接続（jmsコネクション），およびCJMSPブローカーとシステムの管理ユーザの接続（adminコネクション）を管理するためのサービスです。

(1)　コネクションサービスの種類

CJMSプロバイダが提供するコネクションサービスには，次の2種類があります。

jmsサービス

CJMSPリソースアダプタからCJMSPブローカーへの接続を管理するサービスです。メッセージを送受信する際，CJMSPリソースアダプタがCJMSPブローカーに接続するときにこのサービスを使用します。

adminサービス

システムの管理ユーザからCJMSPブローカーへの接続を管理するサービスです。管理ユーザがコマンドの実行によって次のような操作をする場合にこのサービスを使用します。

物理的送信先の作成

送信先またはCJMSPブローカーの問い合わせ

コネクションサービスでは，ポートマッパーによって静的または動的に割り当てられた，専用のポートを使用します。

ポートマッパーによるコネクションサービスへのポートの割り当ての概要を次の図に示します。

図7‒10　コネクションサービスへのポートの割り当ての概要

ポートマッパーは，デフォルトでは7676のポートを使用します。これ以外のポートを使用する場合は，CJMSPブローカーのimq.portmapper.portプロパティで設定してください。

ポートの割り当ての流れを次に示します。

ポートマッパーに対して，CJMSPリソースアダプタからjmsサービスでの接続をするためのリクエストを送信します。または管理ユーザからadminサービスでの接続をするためのリクエストを送信します。

ポートマッパーがコネクションサービスの要求に対して，ポートを動的に割り当てます。ただし，事前にCJMSPブローカーのプロパティとしてimq.jms.tcp.portプロパティまたはimq.admin.tcp.portプロパティを指定した場合は，コネクションサービスごとに指定したポートが割り当てられます。

なお，ポートマッパーがコネクションを接続するためのリクエストを複数同時に受け付けた場合，処理待ちのリクエストはOSのバックログに格納されて待機します。

コネクションサービスで使用する各プロパティの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.3　config.properties（CJMSPブローカー個別プロパティファイル）」を参照してください。

(2)　コネクションサービスのスレッドプール管理

コネクションサービスはマルチスレッドで動作するため，複数のコネクションを同時に管理できます。コネクションサービスで使用するスレッドは，CJMSPブローカーが管理するスレッドプールで管理されています。

なお，コネクションサービスのスレッドプールは，処理性能を向上させるために，独自の方式で管理されています。一つのコネクションでは，メッセージ受信用および送信用の二つのスレッドを使用します。

7.8.2　送信先の管理とルーティングサービス

ここでは，CJMSPブローカーによる送信先の管理，およびルーティングサービスについて説明します。

CJMSPブローカーは，物理的な送信先として，キューやトピックをシステムのメモリ内に作成・管理します。

ルーティングサービスは，リソースを効率的に使用しながら，プロデューサー，コンシューマーと送信先間での確実で円滑なメッセージの送受信を実現するためのサービスです。

(1)　送信先の種類

送信先は，作成方法および存在期間によって，次の2種類に分類できます。

コマンドで作成する送信先

APIで作成される一時的な送信先

それぞれの送信先の特徴について説明します。

コマンドで作成する送信先

システムを管理するユーザがコマンドで明示的に作成した送信先です。

コマンドで作成した送信先は，明示的にコマンドで削除するまで削除されません。

APIで作成される一時的な送信先

J2EEアプリケーション内のAPIによって作成される送信先です。プログラムの中でメッセージの送受信に必要な送信先が作成され，削除されます。一時的な送信先は，送信先を作成したコネクションの中だけで保持されます。また，メッセージの永続化はできず，CJMSPブローカーを再起動しても再作成はされません。

注意事項

一時的送信先を使用するコンシューマーは，その一時的送信先を作成したコネクションだけで作成できます。

また，通常のメッセージ送受信に使用する送信先以外に，デッドメッセージキューというCJMSPブローカーによって自動的に作成される送信先があります。

デッドメッセージキューは，CJMSPブローカーを最初に起動したタイミングで作成されます。この送信先には，CJMSPブローカーによって，次のメッセージ（デッドメッセージ）が登録されます。

処理できないメッセージ

有効期限を過ぎたメッセージ

デッドメッセージキューには，ほかの送信先で処理できずに廃棄されたメッセージが格納されるため，メッセージ送受信で発生した問題についての調査などに利用できます。

デッドメッセージキューの管理については，「(3)　デッドメッセージキューの管理」を参照してください。

(2)　送信先の設定と管理

CJMSPブローカーでは，送信先を設定・管理するために，次の処理を実行できます。

送信先の作成・休止・再開・削除

すべての送信先の一覧表示

個々のメッセージ，およびCJMSPブローカーで管理するメッセージ全体の制限値管理

メッセージの最大数の管理

送信先の状態およびプロパティの表示

永続化メッセージを格納するディスクの圧縮

デッドメッセージキューの管理

これらの処理は，コマンドで実行できます。詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「5.3　CJMSPブローカー管理のコマンドの詳細」を参照してください。

(3)　デッドメッセージキューの管理

デッドメッセージキューは，すべての送信先で必ず使用する設定になっています。

メッセージがデッドメッセージキューに登録された場合の処理については，メッセージごとのメッセージプロパティに設定します。

メッセージプロパティに設定できる内容を次の表に示します。

表7‒3　デッドメッセージキューに登録する際の処理としてメッセージプロパティに設定できる内容

プロパティ

データ型

説明

CJMS_PRESERVE_UNDELIVERED※

Boolean

メッセージが配信できなかった場合の処理を設定します。

「true」を設定した場合，メッセージはデッドメッセージキューに登録されます。

「false」を設定した場合，メッセージはデッドメッセージキューには登録されません。

CJMS_LOG_DEAD_MESSAGES※

Boolean

メッセージが送信先から削除されてデッドメッセージキューに登録されたことをログに出力するかどうかを設定します。

「true」を設定した場合，ログに出力します。

「false」を設定した場合，ログに出力しません。

CJMS_TRUNCATE_MSG_BODY※

Boolean

デッドメッセージキューに登録するメッセージのメッセージボディを削除するかどうかを設定します。

「true」を設定した場合，メッセージボディを削除してからデッドメッセージキューに登録します。

「false」を設定した場合，メッセージボディを削除しないでデッドメッセージキューに登録します。

注※　CJMSプロバイダではサポートしていません。

また，デッドメッセージキューに登録されたデッドメッセージには，CJMSPブローカーによってプロパティが設定されます。設定されたプロパティの情報によって，メッセージがデッドメッセージキューに登録された要因と，要因となった処理を確認できます。

CJMSPブローカーによってデッドメッセージに設定されるプロパティについて，次の表に示します。

表7‒4　CJMSPブローカーによってデッドメッセージに設定されるプロパティ

プロパティ

データ型

説明

JMSXDeliveryCount

Integer

特定のコンシューマーに対して配信されたメッセージの最大数が設定されます。

この値は，CJMS_DMQ_UNDELIVERED_REASONプロパティにERRORまたはUNDELIVERABLEと設定されたプロパティの場合にだけ設定されます。

CJMS_DMQ_UNDELIVERED_TIMESTAMP

Long

デッドメッセージキューに登録された時刻がミリ秒で設定されます。

CJMS_DMQ_UNDELIVERED_REASON

String

デッドメッセージキューに登録された要因を示す値が設定されます。設定されるのは次の値です。

OLDEST

最も古いメッセージだったため処理されなかったことを示します。

LOW_PRIORITY

優先順位が低かったため処理されなかったことを示します。

EXPIRED

メッセージの有効期限が過ぎたため処理されなかったことを示します。

UNDELIVERABLE

配信されなかったことを示します。

ERROR

エラーが発生したことを示します。この要因が設定されたメッセージは，内部的な要因で処理ができなかったため，プロデューサーからメッセージを送信し直す必要があります。

なお，複数の要因が該当した場合は，どれか一つの要因だけが設定されます。

CJMS_DMQ_PRODUCING_BROKER

String

このメッセージを作成したCJMSPブローカーの名前およびポート番号が設定されます。「null」が設定された場合は，ローカルで動作するCJMSPブローカーであることを示します。

CJMS_DMQ_DEAD_BROKER

String

デッドメッセージキューを管理しているCJMSPブローカーの名前およびポート番号が設定されます。「null」が設定された場合は，ローカルで動作するCJMSPブローカーであることを示します。

CJMS_DMQ_UNDELIVERED_EXCEPTION

String

例外の発生が原因で配信されなかったメッセージの場合に，アプリケーションまたはCJMSPブローカーで発生した例外名が設定されます。

CJMS_DMQ_UNDELIVERED_COMMENT

String

メッセージが送信されなかった付加的な要因がある場合に設定されます。

CJMS_DMQ_BODY_TRUNCATED

Boolean

デッドメッセージキューへの登録時にメッセージボディが削除されたかどうかが設定されます。

「true」の場合，メッセージボディは削除されています。

「false」の場合，メッセージボディは削除されていません。

7.8.3　CJMSPブローカーの性能監視

CJMSPブローカーでは，CJMSPブローカーの性能情報（メトリクス）を監視できます。

CJMSPブローカーの性能情報には，ヒープサイズ，接続状況，受信メッセージの割合，送信メッセージの割合などの情報が含まれます。これらの情報は，コンソールに表示されて，ログファイルに出力されます。

CJMSPブローカーの性能情報の出力方法は，imq.metrics.intervalプロパティで指定します。このプロパティに指定した出力間隔で性能情報が出力されます。なお，デフォルトの設定は0（出力しない）です。

CJMSPブローカーの性能情報の出力例を次に示します。

KDAN24558-I Displaying broker metrics :
Connections: 10    JVM Heap: 13082624 bytes (1501448 free) Threads: 22 (14-1010)

      In: 3001 msgs (631149 bytes)  4297 pkts (795219 bytes)
     Out: 1253 msgs (263099 bytes)  5495 pkts (690645 bytes)
 Rate In: 298 msgs/sec (62622 bytes/sec)  419 pkts/sec (77978 bytes/sec)
Rate Out: 125 msgs/sec (26271 bytes/sec)  540 pkts/sec (66573 bytes/sec)

出力項目について，次の表に示します。

表7‒5　CJMSPブローカーの性能情報に出力される項目

出力項目

説明

Connections

接続状態のコネクション数です。

JVM Heap

使用しているJavaVMのヒープサイズと使用可能なメモリ量です。

Threads

使用されているスレッド数です。

なお，出力例では22となっています。特定の時間だけCJMSPブローカーに接続している場合，使用されているスレッド数は自動で更新されます。

（　）内はスレッドプール値の最小値と最大値です。

最小値（14）

最小のスレッドプール値を示します（jmsサービスの最小値は10，adminサービスの最小値は4です。このため，最小値は14になります）。

最大値（1010）

最大のスレッドプール値を示します（jmsサービスの最大値は1000，adminサービスの最大値は10です。このため，最大値は1010となります）。

In

CJMSPブローカーの受信メッセージ数です。

Out

CJMSPブローカーから送信されたメッセージ数です。

Rate In

CJMSPブローカーの受信メッセージの割合です。また，1秒間のメッセージ数と1秒当たりのメッセージパケットが表示されます。

Rate Out

CJMSPブローカーから送信されたメッセージの割合です。また，1秒間のメッセージ数と1秒当たりのメッセージパケットが表示されます。

7.8.4　管理情報およびメッセージの永続化サービス

CJMSPブローカーに障害が発生した場合，回復には，障害発生前のメッセージ送受信操作の状態を示す情報が必要です。CJMSPブローカーでは，回復に必要な状態についての情報をファイルに保存して管理します。障害が発生した場合，保存された情報を基にCJMSPブローカーの状態を回復して，操作を再開できるため，メッセージ配信の信頼性を確保できます。

CJMSPブローカーは，次のような情報をファイルに保存して管理します。

送信先の情報

永続化サブスクライバーの情報

メッセージの情報

トランザクションの情報

メッセージ配信の確認応答についての情報

障害発生後にCJMSPブローカーを再起動すると，保存していた各情報を基に，送信先と永続化サブスクライバーの再作成，永続化メッセージの回復，トランザクションのロールバックが実施され，未配信のメッセージのためのルートが再作成されます。その後，メッセージ配信が再開されます。

(1)　管理情報およびメッセージの永続化の仕組み

CJMSPブローカーでは，永続化する情報の種類ごとにファイルを作成して管理します。保存用のファイルは，CJMSPブローカーが作成されたときに自動的に作成されます。情報の種類ごとに保存先のファイルは異なります。

しきい値（1メガバイト）以下のサイズのメッセージは，メッセージごとに一つの可変長のファイルに保存されます。また，しきい値を超えるサイズのメッセージは，ファイルプールの複数のファイルで管理されます。ファイルプールの各ファイルのサイズは1メガバイトです。

(2)　ファイルプールの利用

CJMSPブローカーが管理するファイルプールの概要を次の図に示します。

図7‒11　CJMSPブローカーが管理するファイルプールの概要

ファイルプールの特徴を次に示します。

不要になったファイルは，フリーファイルとしてファイルプールに返却されます。ファイルプールは，送信先ごとに管理されています。

ファイルプールで管理するファイル数の最大値は100です。ファイル数が最大値を超えた場合，不要になったファイルはプールに返却されないで削除されます。

ファイルプール内のファイルは，CJMSPブローカーを停止して再起動したあとも残ります。

(3)　ファイルへの書き込みのタイミング

ファイルへのデータの書き込みは，OSの機能で実行します。このとき，書き込みを同期・非同期のどちらで実行するかをimq.persist.file.sync.enabledプロパティで選択できます。なお，デフォルトでは書き込みは非同期で実施されます。

同期書き込み・非同期書き込みの利点と欠点を次の表に示します。

表7‒6　ファイルへの同期書き込み・非同期書き込みの利点と欠点

書き込みのタイミング

利点

欠点

非同期

書き込み処理による処理性能への影響がありません。

障害が発生したときに，一部のデータが失われることがあります。

同期

障害発生時点までのデータが保存されているため，障害発生直前の状態からCJMSPブローカーの処理を再開できます。

書き込み処理による処理性能への影響があります。

(4)　ファイルの格納先

CJMSPブローカーが管理する永続化データを保存したファイルは，デフォルトでは次のディレクトリに保存されています。なお，varディレクトリの格納先は，cjmsbrokerコマンドの-varhomeオプションで変更できます。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥instances¥<CJMSPブローカーの名称>¥fs370

UNIXの場合

/opt/Cosminexus/CC/cjmsp/var/instances/<CJMSPブローカーの名称>/fs370

fs370ディレクトリ下の構成を次に示します。

表7‒7　fs370ディレクトリ下の構成

ディレクトリ・ファイル名

説明

messageディレクトリ

このディレクトリ下に，送信先名ごとのサブディレクトリが作成されます。それぞれのサブディレクトリ内に，メッセージごとの個別のファイルが格納されています。

interestファイル

コンシューマーの情報が格納されています。

destinationファイル

送信先の情報が格納されています。

propertyファイル

内部情報が格納されています。

txnファイル

トランザクションIDが格納されています。

txnackファイル

すべてのトランザクションIDに対する配信確認が格納されています。

configrecordファイル

内部情報が格納されています。

このディレクトリの内容は，不正にアクセスされないよう，OSのアクセス権などを設定して適切に管理してください。

注意事項

fs370ディレクトリ下のファイルを移動したり，ファイルの属性を読み取り専用に変更したりしないでください。CJMSPブローカーが正しく動作しなくなるおそれがあります。

ネットワークドライブや，ネットワーク上のファイルを使用することはできません。cjmsbrokerコマンドの-varhomeオプションでvarディレクトリの格納先を変更する場合は，CJMSPブローカーと同じマシン上のディレクトリを選択するようにしてください。

一つのトランザクションの中で大量のメッセージを処理すると，txnackファイルのファイルサイズが大幅に増加することがあります。大量のメッセージを送信する場合，性能テストを実施して，必要なファイルサイズを見積もってください。

(5)　ファイルのバックアップ

永続化データのバックアップを取得する場合は，CJMSPブローカー単位で取得します。varディレクトリ下のinstancesディレクトリをほかの場所にコピーして保存してください。

回復する場合は，まず，CJMSPブローカーを停止します。バックアップしておいたinstancesディレクトリ以下のファイルをvarディレクトリ下に上書きしてから，CJMSPブローカーを再起動してください。

7.9　CJMSPリソースアダプタの機能

CJMSPリソースアダプタは，J2EEサーバとCJMSPブローカーを接続するためのリソースアダプタです。J2EEサーバのWebコンテナまたはEJBコンテナ上で動作するJ2EEアプリケーションとCJMSPブローカー間のメッセージの送受信を実現します。

CJMSPリソースアダプタの動作はConnector属性ファイルに設定します。なお，属性の設定個所に応じて，指定した内容の影響範囲が異なります。指定個所と影響範囲について次の表に示します。

表7‒8　Connector属性ファイルの指定個所と指定内容

Connector属性ファイルのタグ※

指定内容

<resourceadapter>

CJMSPリソースアダプタ全体の動作に影響する属性を指定します。

<connection-definition>

コネクションインタフェースごとの設定を指定します。

注※　JavaBeanの実装と対応しています。

7.10　Message-driven Beanの呼び出し

Message-driven Beanは，コンシューマーとして動作し，メッセージの非同期処理を実行するためのEnterprise Beanです。送信先にメッセージが到着したタイミングでアクティブになり，メッセージを受け取って処理します。

この節では，コンシューマーであるMessage-driven Beanの動作について説明します。

7.10.1　Message-driven Beanによるメッセージ処理の特徴

Message-driven Beanは，クライアントアプリケーションであるプロデューサーから直接呼び出すことはできません。プロデューサーは，送信先にメッセージを送信することで，Message-driven Beanを間接的に呼び出します。

Message-driven Beanは基本的に状態を保持せず，また特定のクライアントアプリケーションと関連づけられて処理を実行されることがありません。このため，送信されたメッセージは複数のMessage-driven Beanによって同時に並行処理できます。

注意事項

Message-driven Beanの複数のインスタンスの同時実行によって，複数のメッセージは並行処理されます。Message-driven Beanクラスのインスタンスによって実行される処理の順序性は保証されません。

大量のメッセージをMessage-driven Beanに配信しようとしたときに，RejectedExecutionException例外が発生することがあります。この例外が発生した場合，一部のメッセージはMessage-driven Beanに配信されません。この状況を避けるためには，CJMSPリソースアダプタの実行時属性として，スレッドプールの最大数をMessage-driven Beanのインスタンス数以上に設定してください。

Message-driven Beanのインスタンス数やエンドポイント数を設定することによって，メッセージの送信が遅れることがあります。この問題を防ぐために，CJMSPリソースアダプタで実行するスレッド数，Message-driven Beanのインスタンス数，およびエンドポイント数を次の式に従って設定してください。式を示します。

Message-driven Beanのインスタンス数の総数<=CJMSPリソースアダプタで実行するスレッド数

Message-driven Beanのインスタンス数>=Message-driven Beanのエンドポイント数

なお，Message-driven Beanのインスタンス数は，cosminexus.xmlまたはMessageDrivenBean属性ファイルで定義します。Message-driven Beanのエンドポイント数は，DDで定義します。CJMSPリソースアダプタのスレッド数の定義はConnector属性ファイルで定義します。

cosminexus.xmlの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。MessageDrivenBean属性ファイルの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「3.6　MessageDrivenBean属性ファイル」を参照してください。Connector属性ファイルの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1　Connector属性ファイル」を参照してください。

CJMSプロバイダを使用して，Message-driven Beanにメッセージを配信する場合，メッセージ配信中にCJMSPブローカーを停止すると，CJMSPブローカーを再起動してもメッセージは配信されません。CJMSPブローカーを停止した場合は，J2EEサーバを再起動してください。

7.10.2　Message-driven Beanを呼び出す流れ

メッセージの送信元となるアプリケーションにとって，Message-driven Beanはメッセージのコンシューマーです。アプリケーションからMessage-driven Beanにとってのメッセージリスナである送信先にメッセージを送信すると， Message-driven Beanがメッセージを受け取り，コンシューマーとして処理を実行します。

メッセージが到着すると，Message-driven Beanのメッセージリスナメソッドであるjavax.jms.MessageListener#onMessageメソッドがJ2EEコンテナによって呼び出されます。メッセージリスナメソッドに含まれるビジネスロジックによって，処理が実行されます。

Message-driven Beanを動作させる流れを次の図に示します。

図7‒12　Message-driven Beanを動作させる流れ

なお，送信元のJ2EEアプリケーションのJNDI名前空間には，Message-driven Beanを動作させるための送信先が設定されている必要があります。

Message-driven Beanと送信先であるキューまたはトピックは，Message-driven Beanを含むJ2EEアプリケーションをJ2EEサーバにデプロイしたときに関連づけられます。

7.10.3　Message-driven Beanで必要な設定

Message-driven Beanの動作は，Message-driven Beanの属性として設定します。送信先の情報，メッセージの確認応答モード，およびメッセージセレクターなどが設定できます。属性は，DDまたはMessageDrivenBean属性ファイルの<activation-config>タグで設定します。詳細は，「7.12　DDでの定義」およびマニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「3.6　MessageDrivenBean属性ファイル」を参照してください。

ここでは，主な設定項目について説明します。

(1)　送信先の設定

Message-driven Beanと関連づける送信先の種類として，キュー（javax.jms.Queue）またはトピック（javax.jms.Topic）のどちらかを設定します。トピックと設定した場合は，さらに永続化サブスクライバーを使用するかどうかも設定します。

送信先をキューとした場合，または永続化サブスクライバーを使用する設定にした場合は，Message-driven Beanが動作するJ2EEアプリケーションが動作していないときなどには送信先がメッセージを保持します。

送信先をトピックとして永続化サブスクライバーを使用しない設定にした場合は，Message-driven Beanが動作するJ2EEアプリケーションが動作していないときに送信されたメッセージはMessage-driven Beanに配信されません。

送信先の種類や永続化サブスクライバーについては，「7.4　メッセージングモデルの種類」を参照してください。

(2)　メッセージの確認応答モードの設定

メッセージの確認応答モードとして，AUTO_ACKNOWLEDGEまたはDUPS_OK_ACKNOWLEDGEのどちらかを設定します。それぞれのモードの詳細については，JMS仕様を参照してください。

メッセージの確認応答は，コンテナが実行します。トランザクションをCMTで管理している場合，確認応答はトランザクションをコミットする処理の一部として実行されます。BMTで管理している場合は，トランザクションとは別に，コンテナによって承認処理が実行されます。なお，確認応答をAPIで実行する実装はしないでください。

(3)　メッセージセレクターの設定

メッセージセレクターとして，Message-driven Beanが受信するメッセージの選択基準を設定します。これによって，メッセージプロパティに特定の値が設定されたメッセージだけを受信して，Message-driven Beanを動作させることができます。

メッセージセレクターについては，「7.6　メッセージセレクターによる受信メッセージの選択」を参照してください。

7.10.4　トランザクションコンテキストの設定

Message-driven Beanのメッセージリスナ，およびタイムアウトコールバックメソッドを呼び出すトランザクションのスコープを示す，トランザクションコンテキストを設定します。

トランザクション管理にCMTを使用する場合は，NOT_SUPPORTED属性を指定してください。

なお，BMTを使用するMessage-driven Beanがjavax.transaction.UserTransactionインタフェースを使用してトランザクションを管理する場合，メッセージの受信はトランザクションの処理に含まれません。

7.11　アプリケーション実装時の制限事項

この節では，CJMSプロバイダを使用してアプリケーションを実装する際の制限事項について説明します。

CJMSプロバイダはJMS1.1仕様に準拠していますが，一部のインタフェースおよびメソッドは使用できません。アプリケーションで使用できないインタフェースまたはメソッドを使用すると，JMSException例外がスローされるおそれがあります。

使用できないインタフェースを次に示します。

javax.jms.ServerSession

javax.jms.ServerSessionPool

javax.jms.ConnectionConsumer

すべてのjavax.jms XAインタフェース

また，次の表に示すインタフェースの一部のメソッドは，アプリケーションクライアントコンテナで実行するアプリケーションで使用するメソッドです。CJMSプロバイダでは使用できません。

CJMSプロバイダで使用できないメソッドをインタフェースごとに次の表に示します。

表7‒9　CJMSプロバイダで使用できないメソッド

インタフェース

使用できないメソッド

javax.jms.Session

setMessageListener(MessageListener listener)

getMessageListener()

run()

javax.jms.Connection

setExceptionListener(ExceptionListener listener)

stop()

setClientID(String clientID)

トランザクション処理されるSessionオブジェクトを作成するメソッド

（例えば，createSessionメソッドの一つ目の引数「transacted」に「true」を指定することができません）。

javax.jms.QueueConnection

createConnectionConsumer(Queue queue, String messageSelector, ServerSessionPool sessionPool, int maxMessages)

トランザクション処理されるQueueSessionオブジェクトを作成するメソッド

（例えば，createQueueSessionメソッドの一つ目の引数「transacted」に「true」を指定することができません）。

javax.jms.TopicConnection

createConnectionConsumer(Topic topic, String messageSelector, ServerSessionPool sessionPool, int maxMessages)

createDurableConnectionConsumer(Topic topic, String subscriptionName, String messageSelector, ServerSessionPool sessionPool, int maxMessages)

トランザクション処理されるTopicSessionオブジェクトを作成するメソッド

（例えば，createTopicSessionメソッドの一つ目の引数「transacted」に「true」を指定することができません）。

また，WebコンテナまたはEJBコンテナで動作するアプリケーションのコンポーネントでは，一つの接続で複数のアクティブなセッションオブジェクトを作成してはいけません。すでにアクティブなセッションオブジェクトがある場合に，createSessionメソッドでオブジェクトを作成しようとした場合，JMSException例外がスローされることがあります。

7.12　DDでの定義

この節では，Message-driven BeanのDDで定義する項目について説明します。

Message-driven BeanのDDでは，<activation-config>タグ下の属性で次の表に示す項目を設定します。

表7‒10　<activation-config>タグ下の属性で指定する項目

属性

データ型

指定可能値

省略値

説明

destination

String

−

−

Message-driven Beanにメッセージを送信する，送信先の名称を指定します。この属性には，CJMSPリソースアダプタの管理対象オブジェクトのNameに設定した名称を設定してください。

destinationType

String

javax.jms.Queue

javax.jms.Topic

−

送信先の種類として，キュー（javax.jms.Queue）またはトピック（javax.jms.Topic）を指定します。

messageSelector

String

−

−

受信するメッセージを選択するためのメッセージセレクターを指定します。

subscriptionName

String

−

−

永続化サブスクライバーの名称を指定します。

subscriptionDurability属性に「Durable」を指定した場合は，必ず指定してください。

subscriptionDurability

String

Durable

NonDurable

NonDurable

永続化サブスクライバーにするかどうかを指定します。

永続化サブスクライバーにする場合は「Durable」，しない場合は「NonDurable」を指定します。

この属性は，destinationType属性に「javax.jms.Topic」を指定した場合にだけ有効になります。

また，「Durable」と指定した場合，次の属性も必ず指定してください。

subscriptionName

clientId

clientId

String

−

−

CJMSPブローカーに接続するための永続化サブスクライバーの識別子を指定します。

subscriptionDurability属性に「Durable」を指定した場合は，必ず指定してください。

acknowledgeMode

String

Auto-acknowledge

Dups-ok-acknowledge

Auto-acknowledge

確認応答モードを指定します。指定するモードの詳細はJMS仕様を参照してください。

endpointExceptionRedeliveryAttempts

Integer

1〜2147483647

6

メッセージ配信中に例外が発生した場合に再配信する回数を指定します。

sendUndeliverableMsgsToDMQ

Boolean

true

false

true

Message-driven Beanが実行時例外をスローした場合で，再配信した回数がendpointExceptionRedeliveryAttempts属性に指定した回数を超えたときに，配信されなかったメッセージをデッドメッセージキューに登録するかどうかを指定します。

登録する場合は「true」，しない場合は「false」を指定します。

「false」を指定した場合，該当するメッセージはCJMSPブローカーによって，有効なコンシューマーに再配信されます（再度同じMessage-driven Beanに配信される場合もあります）。

endpointPoolMaxSize

Integer

1〜2147483647

1

エンドポイントのプールの最大値を指定します。

endpointPoolSteadySize

Integer

0〜2147483647

1

エンドポイントのプールの最小値を指定します。

endpointExceptionRedeliveryInterval

Integer

1〜2147483647

500

例外が発生した場合にエンドポイントにメッセージを再配信する間隔をミリ秒で指定します。

（凡例）

−：指定可能値の制限または省略値はなし

7.13　実行環境の構築の流れ

この節では，CJMSプロバイダを使用する場合の実行環境の構築の流れについて説明します。

メッセージの送受信を実行するJ2EEアプリケーションの実行環境については，あらかじめ運用管理ポータル（Management Server）を使用して構築しておいてください。J2EEアプリケーションの実行環境の構築手順の詳細は，マニュアル「アプリケーションサーバ運用管理ポータル操作ガイド」の「3.　J2EEアプリケーションを実行するシステムの構築と削除」を参照してください。

なお，CJMSPブローカーは，Management Serverの管理対象になりません。このため，CJMSPブローカーの構築・運用は，コマンドおよび定義ファイルで実行します。

ポイント

CJMSプロバイダを使用する場合のユースケースについては，「付録D　CJMSプロバイダのユースケース」を参照してください。

実行環境の構築の流れを次の図に示します。

図7‒13　実行環境の構築の流れ

操作の流れを説明します。説明の番号は図中の番号と対応しています。

前提環境の準備として，Application Serverのインストールと初期設定を実行します。

CJMSPブローカーとJ2EEサーバを異なるマシンに構築する場合は，それぞれのマシンにApplication Serverをインストールしてください。

Application Serverのインストールと初期設定については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「2.2.1　Application Serverのインストールについて」を参照してください。

CJMSPブローカーの共通プロパティと管理コマンドのプロパティを設定します。

同じマシン内に作成するすべてのCJMSPブローカーに共通するプロパティを設定します。また，管理コマンドのログ出力に関するプロパティを設定します。設定方法については，「7.14.1　CJMSPブローカーの共通プロパティと管理コマンドのプロパティの設定」を参照してください。

CJMSPブローカーを作成します。

作成方法については，「7.14.2　CJMSPブローカーの作成」を参照してください。

CJMSPブローカーの個別プロパティを設定します。

それぞれのCJMSPブローカーに対して，個別のプロパティを設定します。設定方法については，「7.14.3　CJMSPブローカーの個別プロパティの設定」を参照してください。

CJMSPブローカーを起動します。

起動方法については，「7.14.4　CJMSPブローカーの起動」を参照してください。

各CJMSPブローカーに送信先を作成します。

作成方法については，「7.14.5　送信先の作成」を参照してください。

CJMSPリソースアダプタを設定して，開始します。

CJMSPリソースアダプタへの属性の設定には，Connector属性ファイルを使用します。

属性の設定後，CJMSPリソースアダプタを開始します。

設定および開始方法については，「7.15　CJMSPリソースアダプタの設定」を参照してください。

J2EEアプリケーションを設定して，開始します。

プロデューサーおよびコンシューマーとなるJ2EEアプリケーションをそれぞれインポートして属性を設定します。なお，コンシューマーとなるJ2EEアプリケーションのMessage-driven Beanに属性を設定する場合は，DD，cosminexus.xmlまたはMessageDrivenBean属性ファイルを使用します。

設定および開始方法については，「7.16　J2EEアプリケーションの設定」を参照してください。

ポイント

CJMSプロバイダに関するファイルは，インストール時に次のディレクトリに格納されます。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp

注意事項

CJMSPリソースアダプタを開始する前に，CJMSPブローカーを起動しておく必要があります。CJMSPリソースアダプタの開始中にCJMSPブローカーが停止した場合，CJMSPリソースアダプタは，120秒ごとにCJMSPブローカーへの接続をリトライします。

7.14　CJMSPブローカーの設定

この節では，CJMSPブローカーの設定について説明します。

なお，CJMSPブローカーへのプロパティの設定方法には，2種類の方法があります。複数の設定方法で異なる値を指定した場合，次の表に示す番号の順で設定が優先されます。すべてのCJMSPブローカーに共通の設定をする場合は，commonconfig.propertiesに設定することをお勧めします。

表7‒11　 CJMSPブローカーへのプロパティの設定方法

優先順位

設定方法

設定個所

プロパティの有効範囲

1

CJMSPブローカー個別プロパティファイルを使用する設定方法

config.properties※1

個別のCJMSPブローカーだけに有効です。

2

CJMSPブローカー共通プロパティファイルを使用する設定

commonconfig.properties※2

同じマシン内のすべてのCJMSPブローカーに有効です。

注※1　デフォルトでは次のディレクトリに格納されます。なお，varディレクトリはCJMSPブローカーを最初に起動したあとで使用できるディレクトリです。CJMSPブローカー個別プロパティファイル（config.properties）については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「6.2.3　config.properties（CJMSPブローカー個別プロパティファイル）」を参照してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥instances¥<CJMSPブローカーの名称>¥props

UNIXの場合

/opt/Cosminexus/CC/cjmsp/var/instances/<CJMSPブローカーの名称>/props

注※2　次のディレクトリに格納されています。なお，CJMSPブローカー共通プロパティファイル（commonconfig.properties）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.2　commonconfig.properties（CJMSPブローカー共通プロパティファイル）」を参照してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥lib¥props¥broker

UNIXの場合

/opt/Cosminexus/CC/cjmsp/lib/props/broker

また，管理コマンド（cjmsicmd）のログの出力方法についてのプロパティは，admin.propertiesに指定します。admin.propertiesは，次のディレクトリに格納されています。

admin.properties（管理コマンドプロパティファイル）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.1　admin.properties（管理コマンドプロパティファイル）」を参照してください。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp/var/admin/config

注意事項

CJMSPブローカーの設定をする場合，cjmspディレクトリ下のファイルのうち，次のファイル以外は編集しないでください。

config.properties

commonconfig.properties

admin.properties

また，これらのファイルに対しても，OSの機能によるアクセス権の変更はしないでください。

なお，ファイアウォールを使用するシステムの場合，CJMSプロバイダによるポートの利用を許可する設定が必要です。

例えば，Windowsの場合，次のコマンドの実行によって利用を許可できます。

netsh firewall add allowedprogram program= "<COSMINEXUS_HOME>/jdk/bin/java.exe" name="Java Virtual Machine" mode=ENABLE.

CJMSプロバイダが利用するポート番号は，次のとおりです。（ ）内はそのポート番号を設定するプロパティです。config.propertiesで設定できます。

CJMSPブローカーのポートマッパーが使用するポート番号（imq.portmapper.port）

jmsサービスが使用するポート番号（imq.jms.tcp.port）

adminサービスが使用するポート番号（imq.admin.tcp.port）

7.14.1　CJMSPブローカーの共通プロパティと管理コマンドのプロパティの設定

CJMSPブローカーのプロパティには，デフォルト値が設定されています。必要に応じて，commonconfig.propertiesを編集してすべてのCJMSPブローカーに設定するプロパティの値を変更してください。

また，admin.propertiesを編集して，管理コマンドのログの出力に関するプロパティを設定してください。

7.14.2　CJMSPブローカーの作成

CJMSPブローカーは，cjmsbrokerコマンドを実行して作成します。

手順を次に示します。

cdコマンドでカレントディレクトリを次のディレクトリに移動します。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp/bin

cjmsbrokerコマンドを実行します。

CJMSPブローカーの名前を-nameオプションに指定して実行します。

実行例（名前「MyBroker」を指定してCJMSPブローカーを作成する場合）

cjmsbroker -name MyBroker

cjmsicmd shutdown bkrコマンドを実行します。

作成したCJMSPブローカーを停止します。以降で個別のCJMSPブローカーのプロパティを設定するためです。

実行例

cjmsicmd shutdown bkr

手順2.でcjmsbrokerを実行したときに，varディレクトリ下のinstances下に指定した名前（実行例の場合は「MyBroker」）のディレクトリが作成されます。名前を指定しなかった場合は，デフォルトのCJMSPブローカーが起動します。

なお，varディレクトリの格納場所はcjmsbrokerコマンドの-varhomeオプションで指定します。

注意事項

-varhomeオプションでディレクトリを指定した場合は，2回目以降のCJMSPブローカー起動時にも，-varhomeオプションで同じ値を指定してください。

2回目以降の起動時に-varhomeオプションを指定しなかったり，別の場所を指定したりすると，-nameオプションに同じ名前を指定しても，指定したvarディレクトリまたはデフォルトディレクトリ下に新しいインスタンスが作成されます。

7.14.3　CJMSPブローカーの個別プロパティの設定

ここでは，CJMSPブローカーの個別プロパティの設定について説明します。

CJMSPブローカーの個別のプロパティは，config.propertiesの指定で設定できます。ただし，config.propertiesを指定できるのは，一度cjmsbrokerコマンドで起動され，varディレクトリ以下が作成されているCJMSPブローカーだけです。

config.propertiesを使用したプロパティの指定例を次に示します。

config.propertiesを使用したプロパティの指定例

imq.portmapper.port=7777

broker.logger.MessageLogFile.filenum=4

指定内容の意味

CJMSPブローカーのポートマッパーが使用するポート番号は7777です。

メッセージログファイルの面数は4です。

注意事項

複数のCJMSPブローカーを起動するシステムの場合は，必ずimq.portmapper.portプロパティの値を変更してください。デフォルトポート（7676）を使用しているCJMSPブローカーがあると，新しいCJMSPブローカーは作成できません。

7.14.4　CJMSPブローカーの起動

ここでは，CJMSPブローカーの起動について説明します。

手順を示します。カレントディレクトリは次のディレクトリに移動していることを前提とします。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp/bin

cjmsbrokerコマンドを実行します。

ここでは，「MyBroker」を起動する実行例を示します。

実行例（「MyBroker」を起動する場合）

cjmsbroker -name MyBroker

7.14.5　送信先の作成

ここでは，CJMSPブローカーで管理する送信先の作成について説明します。

手順を示します。カレントディレクトリは次のディレクトリに移動していることを前提とします。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp/bin

cjmsicmd create dstコマンドを実行します。

ここでは，キューを作成する実行例とトピックを作成する実行例を示します。

実行例（キュー「Queue1」を作成する場合）

cjmsicmd create dst -t q -n Queue1

実行例（トピック「Topic1」を作成する場合）

cjmsicmd create dst -t t -n Topic1

なお，送信先は，コマンドで作成するほか，アプリケーション内でAPIによって作成する方法があります。詳細は，「7.8.2　送信先の管理とルーティングサービス」を参照してください。

7.15　CJMSPリソースアダプタの設定

CJMSPリソースアダプタは，次のディレクトリ下に，cjmsra.rarとして格納されています。デフォルトの名称は，「Cosminexus_JMS_Provider_RA」です。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/cjmsp/lib

リソースアダプタのインポートから開始までの手順については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.3　リソースの設定手順」を参照してください。

CJMSPリソースアダプタには，属性として，次の項目が設定できます。

ConnectionFactoryや送信先など，管理対象オブジェクトの属性

トランザクションサポートレベル

ログ出力に関する属性

これらの属性を変更する場合は，CJMSPリソースアダプタに設定するConnector属性ファイルを編集してください。

CJMSPリソースアダプタの属性には，リソースアダプタ単位に指定する項目と，ManagedConnectionFactoryクラス単位に指定する項目があります。CJMSPリソースアダプタで指定する主な属性を次の表に示します。

表7‒12　CJMSPリソースアダプタで指定する主な属性

対象

Connector属性ファイルのタグ

指定する項目

リソースアダプタ単位の属性

<resourceadapter>下の<config-property>

CJMSPリソースアダプタ全体に影響する属性

connectionURL

reconnectEnabled

reconnectAttempts

reconnectInterval

ログに関する属性

MsgLogLevel

MsgLogFileNum

MsgLogFileSize

ExpLogFileNum

ExpLogFileSize

ManagedConnectionFactoryクラス単位の属性

<connection-definition>下の<config-property>

コネクションインタフェースごとの属性

clientId

reconnectEnabled

reconnectAttempts

reconnectInterval

管理対象オブジェクトの属性

<adminobject>下の<adminobject-name>，<adminobject-interface>，<adminobject-class>

管理対象オブジェクトの名称，送信先の種類，およびクラスの情報

<adminobject>下の<config-property>

送信先の名前（Message-driven Beanのdestination属性に指定する値）

Name

なお，CJMSプロバイダでは，Connector属性ファイルのテンプレートファイルを提供しています。必要に応じて使用してください。テンプレートファイルの格納先については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.13　Connector属性ファイルのテンプレートファイル」を参照してください。

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

CJMSプロバイダを使用するJ2EEアプリケーションをインポートします。

J2EEアプリケーションのインポートから開始までの手順については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「3.4　J2EEアプリケーションの設定手順」を参照してください。

J2EEアプリケーションに設定する属性は，DDまたはcosminexus.xmlに指定できます。CJMSプロバイダを使用する場合にDDに必要な設定については，「7.12　DDでの定義」を参照してください。なお，cosminexus.xmlを含まないJ2EEアプリケーションに対して，J2EEサーバにインポートしたあとで属性を設定する場合は，属性ファイルを使用して，サーバ管理コマンドで設定ください。

7.17　CJMSプロバイダを使用する場合のシステムの開始と停止

この節では，CJMSプロバイダを使用する場合のシステムの開始手順と停止手順について説明します。

7.17.1　システムの開始手順

CJMSプロバイダを使用するシステムは，次の手順で開始します。なお，手順1.と手順2.は順不同です。

注意事項

CJMSPリソースアダプタを開始する前に，必ずCJMSPブローカーを起動してください。CJMSPブローカー起動前にCJMSPリソースアダプタを開始することはできません。また，CJMSPリソースアダプタが開始した状態でJ2EEサーバを停止し，CJMSPブローカーを停止してからJ2EEサーバを再起動すると，再起動後のCJMSPリソースアダプタの再開始には失敗します。

J2EEサーバを含むJ2EEアプリケーションの実行環境の各プロセスを起動します。

Smart Composerで構築したシステムの場合は，一括起動ができます。詳細は，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.1　システムの起動手順」を参照してください。

注意事項

この時点でCJMSPリソースアダプタおよびJ2EEアプリケーションは開始しません。

CJMSPブローカーを起動します。

ここでは，CJMSPブローカー「MyBroker」を起動する場合の実行例を示します。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥bin¥cjmsbroker -name MyBroker

UNIXの場合

/opt/Cosminexus/CC/cjmsp/bin/cjmsbroker -name MyBroker

なお，CJMSPブローカーを起動する際，必要に応じてCJMSPブローカーが使用するJavaヒープサイズを変更してください※。

CJMSPリソースアダプタを開始します。

サーバ管理コマンドを使用した実行例を次に示します。この例では，J2EEサーバの名称は「cmx_MyWebSystem_unit1_J2EE_01」，CJMSPリソースアダプタの名称は「CJMS_Provider_RA」とします。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥bin¥cjstartrar "cmx_MyWebSystem_unit1_J2EE_01" -resname "CJMS_Provider_RA"

UNIXの場合

/opt/Cosminexus/CC/admin/bin/cjstartrar "cmx_MyWebSystem_unit1_J2EE_01" -resname "CJMS_Provider_RA"

メッセージを送受信するJ2EEアプリケーションを開始します。

サーバ管理コマンドを使用した実行例を次に示します。なお，J2EEサーバの名称は「cmx_MyWebSystem_unit1_J2EE_01」，J2EEアプリケーションの名称は「JMSSampleApp」とします。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥bin¥cjstartapp "cmx_MyWebSystem_unit1_J2EE_01" -name "JMSSampleApp"

UNIXの場合

/opt/Cosminexus/CC/admin/bin/cjstartapp "cmx_MyWebSystem_unit1_J2EE_01" -name "JMSSampleApp"

注※　CJMSPブローカーが使用するJavaヒープサイズの考え方

CJMSPブローカーは，デフォルトの設定では，192メガバイトのJavaヒープを使用する設定になっています。この値は，大量のメッセージを扱うには小さ過ぎるため，必要に応じて増加させてください。

使用するJavaヒープのメモリサイズが小さ過ぎると，空きメモリを確保するためにJ2EEアプリケーションとのコネクションをクローズする必要が発生し，処理できるメッセージの量が少なくなります。

ただし，CJMSPブローカーで使用できるJavaヒープサイズの最大値を大きくし過ぎると，システムの物理メモリに影響が出て，システムにOutOfMemoryErrorを発生させる要因になります。OutOfMemoryErrorが発生すると，システムの処理性能を低下させるほか，予想外の状態でCJMSPブローカーに障害が発生したり，ほかのアプリケーションやサービスの実行に影響を及ぼしたりします。

これらを考慮し，実行する環境に応じて，適切な値を設定してください。

CJMSPブローカーが使用するJavaヒープのサイズは，CJMSPブローカーを起動するときにcjmsbrokerコマンドの-vmargsオプションで指定できます。

実行例を示します。

実行例

cjmsbroker -vmargs "-Xms256m -Xmx1024m"

この例では，CJMSPブローカーは，CJMSPブローカーの起動時には256メガバイトのメモリを使用し，最大で1ギガバイトのJavaヒープを使用するように設定しています。

7.17.2　システムの停止手順

CJMSプロバイダを使用するシステムは，次の手順で停止します。なお，手順3.と手順4.は順不同です。

メッセージを送受信するJ2EEアプリケーションを停止します。

サーバ管理コマンドを使用した実行例を次に示します。この例では，J2EEサーバの名称は「cmx_MyWebSystem_unit1_J2EE_01」，J2EEアプリケーションの名称は「JMSSampleApp」とします。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥bin¥cjstopapp "cmx_MyWebSystem_unit1_J2EE_01" -resname "JMSSampleApp"

UNIXの場合

/opt/Cosminexus/CC/admin/bin/cjstopapp "cmx_MyWebSystem_unit1_J2EE_01" -resname "JMSSampleApp"

CJMSPリソースアダプタを停止します。

サーバ管理コマンドを使用した実行例を次に示します。なお，J2EEサーバの名称は「cmx_MyWebSystem_unit1_J2EE_01」，CJMSPリソースアダプタの名称は「CJMS_Provider_RA」とします。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥bin¥cjstoprar "cmx_MyWebSystem_unit1_J2EE_01" -resname "CJMS_Provider_RA"

UNIXの場合

/opt/Cosminexus/CC/admin/bin/cjstoprar "cmx_MyWebSystem_unit1_J2EE_01" -resname "CJMS_Provider_RA"

CJMSPブローカーを停止します。

CJMSPブローカー「MyBroker」を停止する場合の実行例を示します。

実行例

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥bin¥cjmsicmd shutdown bkr

UNIXの場合

/opt/Cosminexus/CC/cjmsp/bin/cjmsicmd shutdown bkr

ポイント

CJMSPブローカーを停止する場合は，ホスト名とポート番号によって対象にするCJMSPブローカーを特定します。ポート番号を指定しないでcjmsicmd shutdown bkrコマンドを実行すると，デフォルトの7676のポートを使用しているCJMSPブローカーが停止処理の対象となります。ほかのポートを使用しているCJMSPブローカーを停止する場合は，-bオプションでホスト名とポート番号を指定してください。実行例を次に示します。

実行例（7777のポートを使用しているCJMSPブローカーを停止する場合）

cjmsicmd shutdown bkr -b localhost:7777

詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjmsicmd shutdown bkr（CJMSPブローカーの停止）」を参照してください。

J2EEサーバを含むJ2EEアプリケーションの実行環境の各プロセスを停止します。

Smart Composerで構築したシステムの場合は，一括停止ができます。詳細は，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「4.1.3　システムの停止手順」を参照してください。

7.17.3　CJMSPブローカーの状態の確認

ここでは，CJMSPブローカーの状態遷移および状態の確認方法について説明します。CJMSPブローカーには，3種類の状態があります。コマンドの実行などによって状態が遷移します。

CJMSPブローカーの状態は，cjmsicmd list bkrコマンドを使用して確認できます。詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjmsicmd list bkr（CJMSPブローカーの一覧表示）」を参照してください。

コマンド実行によるCJMSPブローカーの状態遷移を次に示します。

図7‒14　CJMSPブローカーの状態遷移

表7‒13　 CJMSPブローカーの状態

CJMSPブローカーの状態

説明

OPERATING

CJMSPブローカーがメッセージを処理できる状態です。

cjmsbrokerコマンドによってCJMSPブローカーを起動するとこの状態になります。なお，OPERATINGの状態のCJMSPブローカーに対してcjmsicmd pause bkrコマンドを実行した場合，状態は変わりません。

SHUTDOWN_STARTED

CJMSPブローカーが停止処理（シャットダウン）を開始した状態です。直後または数分後に，CJMSPブローカーはシャットダウンされます。

cjmsicmd shutdown bkrコマンドを実行するとこの状態になります。

SHUTDOWN_COMPLETE

CJMSPブローカーの停止（シャットダウン）処理が完了した状態です。すべてのリソースは解放されています。CJMSPブローカーがシャットダウンされるかどうかは，実行中のプロセスがあるかどうかに依存します。

cjmsicmd shutdown bkrコマンドを実行するとこの状態になります。

7.18　障害対応用の情報の確認

この節では，CJMSプロバイダ使用時に障害が発生した場合に使用する，障害対応用の情報について説明します。

CJMSプロバイダでは，次の3種類のコンポーネントがログを出力します。

CJMSPリソースアダプタ

CJMSPブローカー

管理コマンド（cjmsicmd）

これらのコンポーネントは，メッセージログと例外ログを出力します。メッセージログと例外ログは，コンポーネントごとのログファイルに出力されます。

ログの形式は，トレース共通ライブラリ形式です。

メッセージログ

メッセージログには，J2EEアプリケーションから実行された操作が原因で発生した状態が出力されます。

出力するメッセージの種類は，ログレベルによって設定します。

CJMSプロバイダでのログレベルの意味を次の表に示します。

表7‒14　CJMSプロバイダでのログレベルの意味

ログレベル

意味

ERROR

システムの障害につながる深刻な問題が発生したことを示すメッセージのログレベルです。

エラーと例外の情報だけの，最小限の情報が出力されます。

このログレベルを指定した場合は，ERRORレベルに該当するメッセージだけがログ出力されます。

WARNING

システムの障害にはつながらないものの，注意が必要な状態であることを示すメッセージのログレベルです。

処理が正常終了し，状態に問題がある場合に出力されます。

このログレベルを指定した場合は，ERRORレベルとWARNINGレベルに該当するメッセージがログ出力されます。

INFO

メトリクスやそのほかのメッセージを出力するログレベルです。

処理の流れや，通常処理でどのように操作が行われているかを示す情報が出力されます。

このログレベルを指定した場合は，ERRORレベル，WARNINGレベルおよびINFOレベルに該当するメッセージがログ出力されます。

注

重要なメッセージについては，ログレベルの設定に関係なく，コンソールまたはログファイルに出力されることがあります。

例外ログ

例外ログには，J2EEアプリケーション実行時にエラーまたは例外が発生した場合の情報（例外メッセージ）が出力されます。

ログファイルに出力されるメッセージの詳細については，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」の「4.　KDAN（CJMSプロバイダで出力されるメッセージ）」を参照してください。また，トレース共通ライブラリ形式については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.2.1　トレース共通ライブラリ形式のログの出力形式と出力項目」を参照してください。

参考

CJMSプロバイダでは，PRFトレースも取得できます。CJMSプロバイダ使用時のPRFトレースの取得ポイントについては，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.　性能解析トレースのトレース取得ポイントとPRFトレース取得レベル」を参照してください。

CJMSPブローカーがJavaVMの障害で停止した場合は，次のディレクトリにスレッドダンプまたはcoreファイルが出力されます。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥cjmsp¥var¥instances

UNIXの場合

/opt/Cosminexus/CC/cjmsp/var/instances

7.19　CJMSプロバイダ使用時の注意事項

この節では，CJMSプロバイダ使用時の注意事項について説明します。

7.19.1　デフォルトの設定でのCJMSプロバイダの動作

デフォルトの設定では，CJMSプロバイダは次のように動作します。

CJMSPブローカーが管理しているメッセージの数またはメッセージの容量が，すべての物理的送信先に対して設定した最大値に到達した場合，CJMSPブローカーはメモリリソースを確保するために，最新のメッセージの受け付けを拒否します。また，そのメッセージが永続化メッセージの場合にだけ，メッセージを送信したクライアントに受け付けを拒否したことを通知します。

デッドメッセージキューに送信された有効期限を過ぎたメッセージは，60秒間保留されます。この期間を過ぎたメッセージをデッドメッセージキューから回復することはできません。

使用されなくなった一時的送信先は，120秒後に破棄されます。

永続化データのファイルへの格納は，非同期で実行されます。このため，突然CJMSPブローカーが故障したり停止したりした場合，データが失われることがあります。

7.19.2　メッセージ処理の優先順位についての注意事項

CJMSプロバイダのメッセージ送信では，優先順位の高いメッセージが最初に実行されることが保証されません。例えば，優先順位を1，2，3と設定した「メッセージ1」「メッセージ2」および「メッセージ3」というの三つのメッセージをプロデューサーから送信した場合に，コンシューマーでは「メッセージ1」「メッセージ3」「メッセージ2」のように異なる順番で処理が実行されることがあります。

優先順位と処理順の相違は，次のような要因で発生します。

プロデューサーが先に優先順位の低いメッセージを送信したあとで，優先順位が高いメッセージを送信した場合，あとから送ったメッセージが届く前にコンシューマーではすでに優先順位の低いメッセージを受信し，処理を開始していることがあります。

コンシューマーが優先順位の高いメッセージを受信する前に，そのメッセージの有効期限が過ぎた場合，優先順位の高いメッセージの処理は実行されません。

プロデューサーが優先順位に沿ってメッセージを送信した場合も，内部処理の遅延などによって，コンシューマーに送信される順序が変わることがあります。

優先順位が高いメッセージが永続化メッセージでない場合，CJMSPブローカーに障害が発生すると，そのメッセージは失われます。この場合，CJMSPブローカーが再起動したあとでは，優先度が低い永続化メッセージの処理だけが実行されます。

7.19.3　有効期限が過ぎたメッセージの扱い

送信先があるマシンのシステム時間を変更した場合，クライアントは期限切れのメッセージを受信することがあります。

メッセージの有効期限は，JMSExpirationヘッダフィールドにメッセージを送信したメソッドによって設定されます。もし，誤ってシステムの時間設定が変更されていた場合，有効期限が過ぎたメッセージがコンシューマーに送信されるおそれがあります。

7.19.4　メッセージプロパティの順序性

メッセージプロパティの処理順序は保証されません。

メッセージプロパティは，順序性を維持した構造で管理されていません。このため，例えば，「プロパティ1」「プロパティ2」「プロパティ3」というプロパティがある場合に，この順序で送信先に送信しても，同じ順序で処理されるとは限りません。ただし，プロパティとその値は，送信前と受信時で変わりません。

7.19.5　メッセージプロパティでのバイトメッセージの扱い

メッセージプロパティでは，バイトメッセージを使用しないでください。

バイトメッセージでは，すべてのデータ型のデータを読み出すことができます。例えば，long型の値を含むメッセージをshort型のメソッドで呼び出して処理した場合，意味的には不正な値ですが，最初の2バイトの読み出しには成功してしまいます。これは，ほかのメッセージのデータ型では禁止されている処理です。

CJMSプロバイダでは，データのデータ型を保持し，正しい変換規則の適用に対応するよう，データを管理しています。

7.19.6　BytesMessageインタフェースでのメッセージの扱い

BytesMessageインタフェースのwriteUTF()メソッドを使用した場合，65,535バイトより大きいメッセージを書き込まないでください。writeUTF()メソッドに文字列長が65,535バイトより大きい文字列を渡した場合，例外が発生します。

7.19.7　デッドメッセージキューでのメッセージの扱い

デッドメッセージキューから受け取ったメッセージに対してロールバックを繰り返すと，そのメッセージは送信されない状態になり，そのままデッドメッセージキューに残ります。デッドメッセージキューに残ったメッセージを再度受信するためには，CJMSPブローカーを再起動してください。

8　JavaMailの利用

この章では，SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティ，POP3プロバイダ独自のセッションプロパティ，およびJavaMailを利用する場合の注意事項について説明します。

8.1　この章の構成

この章では，SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティ，およびPOP3プロバイダ独自のセッションプロパティについて説明します。

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

表8‒1　この章の構成（セッションプロパティ）

分類

タイトル

参照先

実装

セッションプロパティ

8.2

注意事項

JavaMailを利用する場合の注意事項

8.3

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

8.2　セッションプロパティ

JavaMailでは，javax.mail.Sessionクラス作成時に，メールの送受信に関する設定をセッションプロパティとして設定します。

セッションプロパティには，次に示す種類があります。

JavaMail APIで提供するセッションプロパティ

JavaMail仕様で定められたSMTPプロバイダおよびSMTPSプロバイダが提供するセッションプロパティ

JavaMail仕様で定められたPOP3プロバイダが提供するセッションプロパティ

SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティ

POP3プロバイダ独自のセッションプロパティ

セッションプロパティの指定値は，「"」で囲み文字列として指定する必要があります。

なお，ここではSMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティ，およびPOP3プロバイダ独自のセッションプロパティについて説明します。

8.2.1　SMTPサーバに接続するためのセッションプロパティ

ここでは，SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティについて説明します。

SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティの一覧を次の表に示します。なお，使用するプロトコルとして"smtps"を指定した場合は，プロパティ名の"smtp"の部分は"smtps"となります。

表8‒2　SMTPプロバイダおよびSMTPSプロバイダ独自のセッションプロパティの一覧

項番

プロパティ

デフォルト値

有効な指定値

無効な値を指定した場合の動作

1

mail.smtp.allow8bitmime

false

true，false

（大文字と小文字の区別はなし）

メールサーバへの送信処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

2

mail.smtp.auth

false

true，false

（大文字と小文字の区別はなし）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

3

mail.smtp.connectiontimeout

0

（無限待ち）

0〜2147483647

（単位:ミリ秒）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

4

mail.smtp.dsn.notify

なし

SUCCESS，FAILURE，DELAYのうち一つ，または複数を「,」で区切って指定

NEVER

指定した値をそのまま使用します。

メールサーバ側で不正と見なした場合は，RCPTコマンドが失敗し，メール送信処理が中断します。

メールサーバの処理は，メールサーバに依存します。

5

mail.smtp.dsn.ret

なし

FULL，HDRS

指定した値をそのまま使用します。

メールサーバ側で不正と見なした場合は，MAILコマンドが失敗し，メール送信処理が中断します。

メールサーバの処理は，メールサーバに依存します。

6

mail.smtp.ehlo

true

true，false

（大文字と小文字の区別はなし）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

7

mail.smtp.from

<mail.form>に指定した値

文字列

JavaMail，またはメールサーバから例外が返る可能性があります。メールサーバがどのような場合に例外を返すかは，メールサーバに依存します。

8

mail.smtp.localhost

java.net.InetAddress.getLocalHost().getHostName()の戻り値

文字列

指定した値をそのまま使用します。

9

mail.smtp.noop.strict

true

true，false

（大文字と小文字の区別はなし）

javax.mail.Transportオブジェクト取得時にメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

10

mail.smtp.quitwait

false

true，false

（大文字と小文字の区別はなし）

javax.mail.Transportオブジェクト取得時にメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

11

mail.smtp.saslrealm

なし

文字列

指定した値をそのまま使用します。

12

mail.smtp.sendpartial

false

true，false

（大文字と小文字の区別はなし）

メールサーバへの送信処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

13

mail.smtp.timeout

0

（無限待ち）

0〜2147483647

（単位:ミリ秒）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

それぞれのプロパティについて，以降で説明します。

(1)　mail.smtp.allow8bitmime

quoted-printableやbase64エンコーディングを使用するメッセージのテキスト部分を，8ビットエンコーディングへ変換するかどうかを指定します。

trueを指定した場合，次の条件を満たしていれば，quoted-printableやbase64エンコーディングを使用するメッセージのテキスト部分は8ビットエンコーディングへ変換されます。

サーバが8ビット転送をサポートしている

quoted-printableやbase64エンコーディングを使用するメッセージのテキスト部分がRFC2045に準拠している

falseを指定した場合は，8ビットエンコーディングへは変換しません。

(2)　mail.smtp.auth

AUTHコマンドを使用したユーザ認証をするかどうかを指定します。

trueを指定した場合，AUTHコマンドを使用してユーザ認証をします。falseを指定した場合，AUTHコマンドを使用したユーザ認証はしません。

(3)　mail.smtp.connectiontimeout

コネクション確立までのタイムアウト時間（単位：ミリ秒）を指定します。

0を指定すると，無限に待ち続けます。

このプロパティが指定されている場合，スレッドを使用してタイムアウト時間を監視します。ポリシーやシステムの制限でスレッドが作成できない場合は，タイムアウト時間を監視しません。

タイムアウト時間が，OSのTCPの再送タイマによるタイムアウト時間より大きいか，またはタイムアウト監視をしない設定の場合，TCPの再送タイマによるタイムアウト時間が有効となります。なお，再送タイマによるタイムアウトは，OSによって異なります。

(4)　mail.smtp.dsn.notify

RCPTコマンドのNOTIFYオプションを指定します。

このオプションはDSN（Delivery Status Notification：配送状態通知）を生成する条件を指定します。コンマを区切りにして，次の表に示す値を組み合わせて指定できます。

表8‒3　mail.smtp.dsn.notifyに指定できる値

項番

値

指定される内容

1

NEVER

配送状態に関係なく，送信者にDSNを返さない。

2

SUCCESS

メッセージの配送が成功した場合，DSNを生成する。

3

FAILURE

メッセージの配送が失敗した場合，DSNを生成する。

4

DELAY

メッセージの配送が遅延した場合，DSNを生成する。

指定しない場合のDSN生成については，RFC1891ではNOTIFY=FAILUREまたはNOTIFY=FAILURE,DELAYとして指定されたと解釈してよいとされており，サーバの実装に依存します。

(5)　mail.smtp.dsn.ret

MAILコマンドのRET追加パラメタ値を指定します。

次の表に示す値を組み合わせて指定できます。

表8‒4　mail.smtp.dsn.ret指定できる値

項番

値

指定される内容

1

FULL

配送失敗通知メッセージに送信メッセージ全体を含める。

2

HDRS

配送失敗通知メッセージに送信メッセージのヘッダだけを含める。

プロパティを指定しない場合，配送失敗通知メッセージに何が含まれるかは，サーバの実装に依存します。

(6)　mail.smtp.ehlo

EHLOコマンドを使用するかどうかを指定します。

trueを指定した場合，EHLOコマンドを使用します。EHLOコマンドでエラーが発生した場合，代替にHELOコマンドを使用します。falseを指定した場合，EHLOコマンドは使用しません。

(7)　mail.smtp.from

SMTPおよびSMTPSのMAILコマンドのreverse-pathに使用する電子メールアドレスを指定します。

(8)　mail.smtp.localhost

SMTPおよびSMTPSのHELOコマンドまたはEHLOコマンドで使用されるローカルホストのドメイン名を指定します。

JDKおよびネームサービスが適切に定義されている場合，指定する必要はありません。

(9)　mail.smtp.noop.strict

メールサーバとのコネクション状態を確認する場合，接続状態と判定するレスポンスを変更する時に使用します。

trueを指定した場合は，NOOPコマンドに対するメールサーバからのレスポンスが250の時に接続状態と見なします。falseを指定した場合は，NOOPコマンドに対するメールサーバからのレスポンスが，421を除く正の整数値の時に接続状態と見なします。

(10)　mail.smtp.quitwait

QUITコマンドに対する応答を待つかどうかを指定します。

trueを指定した場合は，QUITコマンドに対する応答を待ちます。falseを指定した場合は，QUITコマンド送信直後にコネクションをクローズします。

(11)　mail.smtp.saslrealm

DIGEST-MD5認証で使用するレルムを指定します。

省略した場合，サーバからのチャレンジに含まれる最初のレルムを使用します。チャレンジにレルムが含まれていない場合，接続先ホスト名をレルムとして使用します。

(12)　mail.smtp.sendpartial

メッセージに指定されている電子メールアドレスに，正しくない電子メールアドレスが含まれている場合の動作を指定します。

trueを指定した場合は，メッセージを送信した上で，エラーになった電子メールアドレスをSendFailedExceptionで報告します。falseを指定した場合は，メッセージを送信しません。

(13)　mail.smtp.timeout

SMTPサーバとの通信（read）のタイムアウト時間（単位：ミリ秒）を指定します。

0を指定すると，無限に待ち続けます。

タイムアウト時間が，OSのTCPの再送タイマによるタイムアウト時間より大きいか，またはタイムアウト監視をしない設定の場合，TCPの再送タイマによるタイムアウト時間が有効となります。なお，再送タイマによるタイムアウトは，OSによって異なります。

8.2.2　POP3サーバに接続するためのセッションプロパティ

ここでは，POP3プロバイダ独自のセッションプロパティについて説明します。

POP3プロバイダ独自のセッションプロパティの一覧を次の表に示します。

表8‒5　POP3プロバイダ独自のセッションプロパティの一覧

項番

プロパティ

デフォルト値

有効な指定値

無効な値を指定した場合の動作

1

mail.pop3.connectiontimeout

0

（無限待ち）

0〜2147483647

（単位:ミリ秒）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

2

mail.pop3.rsetbeforequit

false

true，false

（大文字と小文字の区別はなし）

javax.mail.Storeオブジェクト取得時にメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

3

mail.pop3.timeout

0

（無限待ち）

0〜2147483647

（単位:ミリ秒）

メールサーバとの接続処理でメッセージKDJE59100-Wを出力します。

値は，デフォルト値を使用します。

それぞれのプロパティについて，以降で説明します。

(1)　mail.pop3.connectiontimeout

コネクション確立までのタイムアウト時間（単位：ミリ秒）を指定します。

0を指定すると，無限に待ち続けます。

タイムアウト時間が，OSのTCPの再送タイマによるタイムアウト時間より大きいか，またはタイムアウト監視をしない設定の場合，TCPの再送タイマによるタイムアウト時間が有効となります。なお，再送タイマによるタイムアウトは，OSによって異なります。

(2)　mail.pop3.rsetbeforequit

フォルダを閉じる場合に，QUITコマンドの前にRSETコマンドを発行するかどうかを指定します。

trueを指定した場合，QUITコマンドの前にRSETコマンドを発行し，メッセージに付けた削除マークを取り除きます。自動的に削除マークが付けられるようなサーバの場合に，ユーザのリクエストなしにメッセージが削除されることを防げます。

falseを指定した場合，QUITコマンドの前にRSETコマンドを発行しません。

(3)　mail.pop3.timeout

POP3サーバとの通信（read）のタイムアウト時間（単位：ミリ秒）を指定します。

0を指定すると，無限に待ち続けます。

タイムアウト時間が，OSのTCPの再送タイマによるタイムアウト時間より大きいか，またはタイムアウト監視をしない設定の場合，TCPの再送タイマによるタイムアウト時間が有効となります。なお，再送タイマによるタイムアウトは，OSによって異なります。

8.3　JavaMailを利用する場合の注意事項

この節では，JavaMailを利用する場合の注意事項について説明します。

8.3.1　メソッドの例外発生について

次のクラスのメソッドでは，JavaMail仕様どおりに例外が発生しません。

項番

クラス名

メソッド名

1

javax.mail.Message

setFlag，setFlags

2

javax.mail.Folder

setFlags

READ_ONLYを設定したjavax.mail.Folderオブジェクトから取得したjavax.mail.Messageオブジェクトに対して，表中に示したメソッドでフラグの値を変更しても，READ_WRITEを設定したときと同様に正しくフラグが設定されます。

ただし，POP3の場合，READ_ONLYでフォルダをオープンし，メッセージにDELETEDフラグを設定しても，実際にはメールは削除されません。

8.3.2　POP3でのSEENフラグの動作について

JavaMail仕様ではMessageのgetInputStreamメソッドとgetContentメソッドを使用した場合，SEENフラグが設定される仕様となっていますが，実際にはSEENフラグは設定されません。

8.3.3　JavaMailのプロバイダについて

アプリケーションサーバで使用できるJavaMailのプロバイダは，アプリケーションサーバがデフォルトで提供するSMTP，SMTPSおよびPOP3のプロバイダだけです。javamail.providersファイルを使用して別のプロバイダに差し替えた場合の動作は保証しません。

8.3.4　レスポンスコードについて

JavaMailが不正と見なすレスポンスコードは厳密なRFC仕様とは異なり，RFC仕様で不正と見なすレスポンスコードを不正と見なさない場合があります。そのため，RFC仕様以外の不正なレスポンスを受け取ったことを示すメッセージ（KDJE59111-EまたはKDJE59112-E）ではなく，異常値のレスポンスコードを受け取ったことを示すメッセージ（KDJE59107-E，KDJE59108-E，KDJE59109-EまたはKDJE59110-E）を出力する場合があります。

8.3.5　アプリケーションでメールサーバとの接続およびメールの受信をしたときの注意

アプリケーションでメールサーバとの接続およびメールの受信をしたあとに，次のメソッドを呼ばないでアプリケーションの停止またはリロードを実行すると，KDJE59106-Eメッセージを出力する場合があります。

javax.mail.Storeクラスのcloseメソッド

javax.mail.Folderクラスのcloseメソッド

この場合，それぞれのcloseメソッドを呼んでいるかどうかを確認してください。

なお，KDJE59106-Eメッセージは出力しますが，アプリケーションの停止およびリロードの処理には影響ありません。また，JavaMailの動作にも影響はありません。

8.3.6　JavaMailの仕様との相違点について

メールのヘッダで，Reply-Toヘッダフィールドに「Reply-To:」だけが指定され，アドレスの指定がない場合，アプリケーションサーバのJavaMailでは，javax.mail.MimeMessageクラスのgetReplyToメソッドに，getFromメソッドの戻り値を返さないで，長さ0のjavax.mail.Addressオブジェクトの配列を返します。

8.3.7　MimeUtility APIの挙動差について

javax.mail.internet.MimeUtilityクラスのencodeメソッドでエンコード方式に"base64"を用いた場合，Component Containerのバージョンおよび戻り値として得たOutputStreamに対するcloseメソッドの実行有無により，末尾への改行（"¥r¥n"）付与の有無が次のように異なります。

Component Containerのバージョン

OutputStream.closeメソッドの実行の有無

末尾への改行付与

09-00以前

有

付与しない

無

付与しない

09-50以降

有

付与する

無

付与しない

MimeUtility.encodeメソッドの戻り値として得たOutputStreamの末尾に不要な改行が存在する場合は，改行文字を削除してください。

8.4　実行環境での設定

8.4.1　J2EEサーバの設定

ここでは，システムプロパティについて説明します。システムプロパティの一覧を次の表に示します。

表8‒6　システムプロパティの一覧

項番

プロパティ

デフォルト値

有効な指定値

無効な値を指定した場合の動作

1

mail.mime.charset

なし

文字列

（文字セッ

ト）

文字セットとして存在しない値を指定した場合，指定した値を使用して処理を続行します。

2

mail.mime.encodeeol.strict

false

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

3

mail.mime.decodetext.strict

true

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

4

mail.mime.encodefilename

false

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

5

mail.mime.decodefilename

false

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

6

mail.mime.multipart.ignoremissingendboundary

true

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

7

mail.mime.multipart.ignoremissingboundaryparameter

true

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

8

mail.mime.encodeparameters

false

true，false

（大文字と小文字の区別はなし）

メッセージを出力し，値はデフォルト値を使用します。

9

mail.mime.decodeparameters

false

true，false

（大文字と小文字の区別はなし）

値はデフォルト値を使用します。

それぞれのプロパティについて，以降で説明します。

(1)　mail.mime.charset

JavaMailで使用するデフォルトの文字セットを指定します。指定がない場合，J2SEのfile.encodingプロパティが使用されます。このプロパティによってメッセージを送信するとき，ファイルで使用されるデフォルトの文字セットと異なる文字セットをデフォルトとして使用できます。

(2)　mail.mime.encodeeol.strict

データが次の条件をすべて満たす場合に，改行コードをCRLFへ変換するかどうかを選択できます。falseが設定された場合，変換を行います。

ASCIIで表示可能な文字しか含まない。

CR，LFを含む。

(3)　mail.mime.decodetext.strict

エンコードされたテキストの開始に区切り文字を含まないRFC2047に違反した不正なメールヘッダに対してデコードを行うかどうかを切り替えます。

RFC2047に違反したエンコードの不正とは，次のものを指します。

プロパティにtrueを設定した場合，デコードを行わない。

プロパティにfalseを設定した場合，RFCに違反したメールヘッダであってもデコードする。

(4)　mail.mime.encodefilename

標準仕様書を参照してください。

(5)　mail.mime.decodefilename

標準仕様書を参照してください。

(6)　mail.mime.multipart.ignoremissingendboundary

標準仕様書を参照してください。

(7)　mail.mime.multipart.ignoremissingboundaryparameter

標準仕様書を参照してください。

(8)　mail.mime.encodeparameters

標準仕様書を参照してください。

(9)　mail.mime.decodeparameters

標準仕様書を参照してください。

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

この章では，CDIの機能概要，実装方法，および注意事項について説明します。

9.1　CDIの概要

●CDIとは

CDIは，Dependency Injection（DI）の仕様の一つです。アプリケーションサーバでは，CDI 2.0に対応しています。

CDIを利用すると，アプリケーションのオブジェクトのDIや，DI対象のオブジェクトの生成から破棄までのライフサイクルを管理できます。アプリケーションサーバでは，次に示すCDIの機能を提供します。

クラスの型によるBeanの解決

名前（文字列）によるBeanの解決

アノテーションによって指定されたコンテキストに基づくインスタンスの生成，および破棄

EL（式言語）やアノテーションで指定されたほかのBeanインスタンスの自動的なインジェクション（注入）

ライフサイクルコールバックインターセプタやインターセプタ

ポイント

CDIは，アプリケーションのリソース間でのインジェクション（注入）を実現することで，アプリケーション開発時の開発容易性を高める機能です。実現するためには，アプリケーションの任意のリソースを注入できるようにJ2EEサーバのセキュリティの設定を変更する必要があります。

●Bean Validationとの連携

アプリケーションサーバでは，CDIアプリケーションでの入力値の検証処理を簡略化するために，Bean Validationの機能を利用できます。

Bean Validationの利用に関しては，「10.　アプリケーションサーバでのBean Validationの利用」を参照してください。

9.2　この章の構成

この章では，CDIの機能について説明します。この章の構成を次の表に示します。

表9‒1　この章の構成（アプリケーションサーバでのCDIの利用）

分類

タイトル

参照先

解説

CDIの概要

9.1

CDIを利用したアプリケーションの開発

9.3

注意事項

CDIを利用する場合の注意事項

9.4

注　「運用」について，この機能固有の説明はありません。

9.3　CDIを利用したアプリケーションの開発

ここでは，CDIを利用したアプリケーションを開発するために必要なbeans.xmlファイルや，アプリケーションのバージョンについて説明します。

9.3.1　CDIの対象となるアプリケーション

CDI 2.0仕様では，beans.xmlファイルの有無に関係なく，CDI管理対象クラスを含んだすべてのアーカイブがCDIの管理対象になります。このとき，メッセージKDJE59300-I，KDJE59301-I，KDJE59302-Iは出力されません。ただし，ejbserver.javaee.cdi.beansXmlRequiredにtrue（大文字小文字は区別しない）を指定した場合，CDI 1.0仕様と同様にbeans.xmlファイルが存在するアーカイブだけがCDIの管理対象になり，アーカイブごとにbeans.xmlの有無に応じてメッセージKDJE59300-I，KDJE59301-I，KDJE59302-Iが出力されます。

なお，WARファイル※内のWEB-INF/lib以下のJARファイルをCDIの管理対象にするには，次のどちらかの条件を満たす必要があります。

ejbserver.javaee.cdi.webInfLibJarsEnabledがtrue，かつejbserver.javaee.cdi.beansXmlRequiredがfalse

ejbserver.javaee.cdi.webInfLibJarsEnabledがtrue，かつejbserver.javaee.cdi.beansXmlRequiredがtrueで，META-INF/beans.xmlが存在する

注※　展開ディレクトリ形式の場合，WARファイルはWARディレクトリを意味します。

このときメッセージKDJE42412-I，およびKDJE59330-Iが出力される場合があります。

メッセージKDJE42412-Iは，WARファイルごとに次の条件をすべて満たす場合だけ出力されます。

ejbserver.javaee.cdi.webInfLibJarsEnabledがtrueである

WARファイル内のWEB-INF/classesまたはWEB-INF/lib以下のJARファイルのどれかがCDIの管理対象である

メッセージKDJE59330-Iは，WARファイル内のWEB-INF/lib以下のJARファイルごとに次の条件をすべて満たす場合だけ出力されます。

ejbserver.javaee.cdi.webInfLibJarsEnabledがtrueである

JARファイルがCDIの管理対象である

bean-discovery-modeがallである，またはbean-discovery-modeがannotatedでJARファイル内にCDI Beanが存在する

また，ejbserver.javaee.cdi.webInfLibJarsEnabledがtrueの場合，デプロイ性能に影響します。そのため，WARファイル内のWEB-INF/lib以下のJARファイルをCDIの管理対象にする必要がない場合は，ejbserver.javaee.cdi.webInfLibJarsEnabledをfalseにして，デプロイ性能への影響を抑えることができます。

J2EEモジュールの種類ごとに，beans.xmlファイルの格納先を示します。

表9‒2　J2EEモジュールの種類ごとのbeans.xmlの格納先

J2EEモジュールの種類

beans.xmlの格納先

EJB-JAR

META-INF/beans.xml

ライブラリJAR

META-INF/beans.xml

WAR（WEB-INF/classes）

WEB-INF/beans.xml

WAR（WEB-INF/lib以下のJAR）

META-INF/beans.xml※

注※　ejbserver.javaee.cdi.webInfLibJarsEnabledがtrueの場合だけサポートします。

CDIの対象にできるコンポーネントのバージョン，およびCDIを使用できるオブジェクトについて次の表に示します。

表9‒3　CDIの対象にできるコンポーネントのバージョン，およびCDIを使用できるオブジェクト

コンポーネントの種類

サポートしているコンポーネントのバージョン

使用できるオブジェクト

EJB

EJB3.1以降

（ejb-jar.xmlのバージョンが3.1以降）

Session Bean

Servlet

Servlet3.0以降

（web.xmlのバージョンが3.0以降）

Servlet

Listener

Filter

JSP

JSP2.1以降

（web.xmlのバージョンが3.0以降）

ELの構文に対応するオブジェクト

JSF

JSF2.1以降

（web.xmlのバージョンが3.0以降，およびアプリケーションサーバがサポートするJSFフレームワーク）

ELの構文に対応するオブジェクト

JAX-RS

JAX-RS 2.0以降

（アプリケーションサーバが提供するJAX-RSエンジンに限る）

ルートリソースクラス

プロバイダ

Applicationのサブクラス

Java Batch

Java Batch 1.0以降

Batch Artifact

WebSocket

WebSocket 1.0以降

ServerEndpoint

注　JAX-WS，JPAなど，上記以外のコンポーネントを使用する場合は，CDIの対象にできません。

9.3.2　CDIの対象となるJ2EEモジュールの注入関係

CDIの対象となるJ2EEモジュールの注入関係について説明します。

CDIの対象となるJ2EEモジュールの注入関係について，次の図に示します。

図9‒1　CDIの対象となるJ2EEモジュールの注入関係

CDIの対象として注入できる関係，および注入できない関係について次に示します。

CDIの対象として注入できる関係

1. WARのWEB-INF/classesから，同じWAR内のWEB-INF/classesへの注入

2. ライブラリJARに含まれるクラスから，ほかのライブラリJARに含まれるクラスへの注入

3. ライブラリJARに含まれるクラスから，同じライブラリJARに含まれるクラスへの注入

4. EJB-JARに含まれるクラスから，ほかのEJB-JARに含まれるクラスへの注入

5. EJB-JARに含まれるクラスから，同じEJB-JARに含まれるクラスへの注入

6. ライブラリJARに含まれるクラスから，EJB-JARに含まれるクラスへの注入

7. ライブラリJARに含まれるクラスから，WAR内のWEB-INF/classesへの注入

8. EJB-JARに含まれるクラスからWAR内のWEB-INF/classesへの注入

ejbserver.javaee.cdi.webInfLibJarsEnabledがtrueの場合だけ，CDIの対象として注入できる関係

9. WARのWEB-INF/classesに含まれるクラスから，同じWAR内のWEB-INF/lib以下のJARに含まれるクラスへの注入

10. WARのWEB-INF/lib以下のJARに含まれるクラスから，同じWAR内のWEB-INF/classesに含まれるクラスへの注入

11. WARのWEB-INF/lib以下のJARに含まれるクラスから，同じWAR内のWEB-INF/lib以下のJARに含まれるクラスへの注入

12. ライブラリJARに含まれるクラスから，WAR内のWEB-INF/lib以下のJARに含まれるクラスへの注入

13. EJB-JARに含まれるクラスからWAR内のWEB-INF/lib以下のJARに含まれるクラスへの注入

CDIの対象として注入できない関係

14. WAR（WEB-INF/classesおよびWEB-INF/lib以下のJAR）に含まれるクラスから，EJB-JARに含まれるクラスへの注入

15. WAR（WEB-INF/classesおよびWEB-INF/lib以下のJAR）に含まれるクラスから，ライブラリJARに含まれるクラスへの注入

16. EJB-JARに含まれるクラスから，ライブラリJARに含まれるクラスへの注入

9.3.3　開発時の注意事項

CDIを利用したアプリケーションを開発する際の注意事項を次に示します。

CDIを使用するアプリケーションでのコンストラクタの取り扱い

CDIのアノテーションを使用するEJBのBeanクラス，Servletクラス，Listenerクラス，およびFilterクラスのコンストラクタに引数は指定できません。

9.4　CDIを利用する場合の注意事項

CDIを利用する場合の注意事項を次に示します。

CDIの拡張インタフェース（Portable Extension API）

アプリケーションサーバでは次のCDIの拡張インタフェース（Portable Extension API）は使用できません。

javax.enterprise.inject.spiパッケージ

javax.enterprise.inject.spi.configuratorパッケージ

アプリケーションサーバでCDIを利用する場合の注意事項（標準仕様との違い）

Servlet3.0の機能とCDIを組み合わせて利用した場合の，アプリケーションサーバでのサポート範囲について説明します。

CDIアノテーションは，web.xmlで定義したServlet，Listener，Filter,およびアノテーションで定義したServlet，Listener，Filterで利用できます。

サーブレットリスナのjavax.servlet.ServletContextListenerのcontextInitializedメソッドで，javax.servlet.ServletContextの次に示すメソッドを利用して動的に定義したServletおよびFilterでだけ，CDIのアノテーションを利用できます。

・addFilter(java.lang.String filterName, java.lang.Class<? extends Filter> filterClass)

・addFilter(java.lang.String filterName, java.lang.String className)

・addServlet(java.lang.String servletName, java.lang.Class<? extends Servlet> servletClass)

・addServlet(java.lang.String servletName, java.lang.String className)

これら以外のAPIを使って動的に定義したServlet，Filter，およびListenerでのCDIのアノテーションの利用はサポートしていません。

JavaVMのクラスパスで指定したMETA-INFディレクトリ内にbeans.xmlを配置している場合，JavaVMのクラスパス内のクラスはCDIの管理対象にはなりません。

リソースアダプタ（RAR）のMETA-INFディレクトリにbeans.xmlを配置している場合，beans.xmlは読み込まれず，リソースアダプタはCDIのモジュールとは認識されません。

ejbserver.javaee.cdi.webInfLibJarsEnabledがfalseの場合に，WARのWEB-INF/lib内に配置したJAR内のMETA-INFディレクトリにbeans.xmlを配置しているとき，beans.xmlは読み込まれず，JARファイルはCDIのモジュールとは認識されません。

なお，WEB-INF/lib以下に格納されたJARファイル内にある，META-INF/resourcesに含まれるJSPに対しては，ManagedBeanを注入できます。WEB-INF/lib以下のJARファイルがCDIの対象となる条件の詳細は，「9.3.1　CDIの対象となるアプリケーション」を参照してください。

CDIのManagedBeanでは，@PersistenceContextおよび@PersistenceUnitの利用は，次の条件をすべて満たす場合にサポートしています。

・ejbserver.jpa.cdiEnabledがtrue（デフォルト）

・フィールドまたはメソッドに，@PersistenceContextまたは@PersistenceUnitを指定

次についてはサポートしていません。

・クラスに指定（@PersistenceContexts，@PersistenceUnitsでの複数指定を含む）した参照の宣言

@EJBおよび@Resourceの利用は，フィールドに指定した場合だけサポートしています。次についてはサポートしていません。

・setterメソッドに指定したDependency Injection

・クラスに指定（@EJBs, @Resourcesでの複数指定を含む）した参照の宣言

@WebServiceRefの利用はサポートしていません。

@Dependentスコープのオブジェクトで，@Producesアノテーション，および@Disposesアノテーションが付与されている場合，同じクラスの中でプロデューサーメソッドを参照することはできません。もし，このようなアプリケーションを作成した場合，再帰的に注入が行われ，StackOverflowExceptionが発生する場合があります。

@Producesアノテーション，または@Disposesアノテーションを付与したBeanでは，@PostConstructアノテーションもしくは@PreDestroyアノテーションを利用できません。

EJBで，@EJB，@Resource，@PersistenceContextまたは@PersistenceUnitによる注入と，@Injectによる注入とを同時に利用する場合，@Injectによる注入の方がほかのアノテーションによる注入よりも先に実行されます。

CDIのJava SE機能をサポートしません。そのため，javax.enterprise.inject.seパッケージのAPIを使用することはできません。

JSR 375 JavaEE Security APIをサポートしません。そのため，CDIではjavax.security.enterprise.SecurityContextインタフェースを使用してアクセス制御をすることはできません。

javax.annotation.Priorityアノテーションとbeans.xmlの両方で有効化したデコレータまたはインターセプタは，CDI 2.0の標準仕様どおり，javax.annotation.Priorityアノテーションの優先度で一度だけ実行されます。beans.xmlによる有効化は無視されます。

トランザクションがロールバックにマークされている場合でも，イベント発生時，javax.enterprise.event.TransactionPhase.BEFORE_COMPLETIONのオブザーバメソッドに通知されません。

CDI Beanを実装しているアプリケーションをアンデプロイしたあとは，そのCDI Beanをほかのアプリケーションから参照できません。なお，参照した場合に発生する例外は，CDI 2.0の標準仕様で定められているIllegalStateExceptionとは異なる場合があります。

Java EEコンポーネントのクラスのうち，CDI 2.0の標準仕様で定義しているBean以外のクラスには，デコレータを適用できません。

Common Annotations 1.2仕様のjavax.annotation.Priorityアノテーションはメソッドの引数には付与できない仕様ですが，CDI 2.0仕様のオブザーバーメソッドでPriorityアノテーションを使用する場合に限り，Common Annotations 1.3仕様相当としてメソッドの引数にもPriorityアノテーションを付与できます。

CDIを使用時のセッション情報引き継ぎ機能に関する注意事項

CDIが有効なアプリケーションに対して，アプリケーションのリロード機能と，各種セッションフェイルオーバ機能は使用できません。リロード機能とセッションフェイルオーバ機能を使用するJ2EEサーバでは，「9.3.1　CDIの対象となるアプリケーション」に記載のプロパティejbserver.javaee.cdi.beansXmlRequiredにtrueを指定してください。また，beans.xmlファイルを含んだアプリケーションをリロードやセッションフェイルオーバの対象にしないでください。

アプリケーション開始性能についての注意事項

CDIアプリケーションに含まれるbeans.xmlのJARファイルの数が増えると，そのJARファイルの増分と比較してデプロイ時間が極端に増加します。

Managed Beanを利用した場合の注意事項

javax.enterprise.context SessionScopedアノテーションを指定されたManaged Beanのインスタンスは，明示管理ヒープには格納されません。

beans.xmlをWEB-INF/classes/META-INF/beans.xmlに配置しても無視されます。

@PostConstructのコールバック完了後にリクエストコンテキストは破棄されません（CDI 1.0と同様の動作となります）。

Serializableを実装したStateless/Singleton Session BeanだけがPassivation可能です。

CDI Conversation Filterという名称のサーブレットフィルタは使用できません。

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

この章では，Bean Validationの機能概要，実装方法について説明します。

10.1　この章の構成

この章では，Bean Validation の機能について説明します。

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

表10‒1　この章の構成（アプリケーションサーバでのBean Validationの利用）

分類

タイトル

参照先

解説

Bean Validationの概要

10.2

Bean Validationの適用可能な範囲

10.3

実装

Bean Validationの機能およびBean Validationの動作

10.4

Bean Validationの利用手順

10.5

デバッグ用ログ（開発調査ログ）の利用

10.6

運用

validation.xmlの内容が不正な場合の情報の出力

10.7

注意事項

Bean Validation実装時の注意事項

10.8

注　「設定」について，この機能固有の説明はありません。

10.2　Bean Validationの概要

この節では，Bean Validationの概要について説明します。

Bean Validationは，JavaBeansのプロパティにアノテーションで指定したプロパティ値の有効範囲に対して，実際にアプリケーションに入力された値が有効範囲内であるかを検証する機能です。

Bean Validationの目的は，アプリケーションでの入力値の検証処理を簡略化することです。

Bean Validationは，ユーザアプリケーション上で利用できます。また，JSF，CDIを使用したアプリケーションでは，標準仕様で定義された連携機能を利用できます。

JSFとCDIについての詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「3.2　JSFおよびJSTLの概要」，および「9.1　CDIの概要」を参照してください。

10.3　Bean Validationの適用可能な範囲

Bean Validationとの連携で適用可能な範囲は，JSF，CDIおよびユーザアプリケーションです。

参照ライブラリおよびコンテナ拡張ライブラリは使用できません。

10.4　Bean Validationの機能およびBean Validationの動作

この節では，Bean Validationの機能およびBean Validationの動作について説明します。

Bean Validationの機能を次の表に示します。

表10‒2　Bean Validationの機能

項番

機能

概要

1

入力値の検証

JavaBeanに設定した値を指定したバリデーション定義で検証する機能です。

グループ管理機能

検証をグループ化する機能です。

メッセージ管理機能

検証結果がエラーの場合に返却するメッセージの管理を行う機能です。

ペイロード管理機能

検証結果をカテゴリ分割する機能です。※

2

カスタムバリデータ作成機能

独自の検証処理を作成する機能です。

3

ブートストラップ機能

Bean Validationプロバイダを変更できる機能です。

注※

Bean ValidationをJSFと連携して利用した場合，ペイロード管理機能を使用できません。

Bean Validationの機能は，アノテーションの指定によって利用できます。Bean Validation機能が提供するアノテーションクラス，指定可能な変数の型，および指定できない変数の型にアノテーションを指定した場合の動作を次の表に示します。

表10‒3　Bean Validation機能が提供するアノテーションクラスとその変数の型

項番

アノテーションクラス

指定可能な変数の型

指定できない変数の型にアノテーションを指定した場合の動作

備考

1

Null

すべての型に指定可能

−

−

2

NotNull

すべての型に指定可能

−

−

3

AssertTrue

boolean/java.lang.Boolean

javax.validation.UnexpectedTypeExceptionがスローされます。

−

4

AssertFalse

boolean/java.lang.Boolean

javax.validation.UnexpectedTypeExceptionがスローされます。

−

5

Min

java.math.BigDecimal

java.math.BigInteger

byte/java.lang.Byte

short/java.lang.Short

int/java.lang.Integer

long/java.lang.Long

float/java.lang.Float

double/java.lang.Double

java.lang.String

javax.validation.UnexpectedTypeExceptionがスローされます。

−

6

Max

java.math.BigDecimal

java.math.BigInteger

byte/java.lang.Byte

short/java.lang.Short

int/java.lang.Integer

long/java.lang.Long

float/java.lang.Float

double/java.lang.Double

java.lang.String

javax.validation.UnexpectedTypeExceptionがスローされます。

−

7

DecimalMin

java.math.BigDecimal

java.math.BigInteger

java.lang.String

byte/java.lang.Byte

short/java.lang.Short

int/java.lang.Integer

long/java.lang.Long

float/java.lang.Float

double/java.lang.Double

javax.validation.UnexpectedTypeExceptionがスローされます。

value属性に対して

java.math.BigDecimalで解析できない値を指定した場合，javax.validation.ValidationExceptionがスローされます。

8

DecimalMax

java.math.BigDecimal

java.math.BigInteger

java.lang.String

byte/java.lang.Byte

short/java.lang.Short

int/java.lang.Integer

long/java.lang.Long

float/java.lang.Float

double/java.lang.Double

javax.validation.UnexpectedTypeExceptionがスローされます。

value属性に対して

java.math.BigDecimalで解析できない値を指定した場合，javax.validation.ValidationExceptionがスローされます。

9

Size

java.lang.String

java.util.Collection

java.util.Map

配列

javax.validation.UnexpectedTypeExceptionがスローされます。

max属性とmin属性に対して負の値を指定した場合，javax.validation.ValidationExceptionがスローされます。

minの値にmaxより大きい値をした場合，javax.validation.ValidationExceptionがスローされます。

10

Digits

java.math.BigDecimal

java.math.BigInteger

java.lang.String

byte/java.lang.Byte

short/java.lang.Short

int/java.lang.Integer

long/java.lang.Long

float/java.lang.Float

double/java.lang.Double

javax.validation.UnexpectedTypeExceptionがスローされます。

integer属性とfraction属性に対して負の値を指定した場合，javax.validation.ValidationExceptionがスローされます。

11

Past

java.util.Date

java.util.Calendar

javax.validation.UnexpectedTypeExceptionがスローされます。

−

12

Future

java.util.Date

java.util.Calendar

javax.validation.UnexpectedTypeExceptionがスローされます。

−

13

Pattern

java.lang.String

javax.validation.UnexpectedTypeExceptionがスローされます。

regexp属性に対して指定した値が正規表現として誤っていた場合，javax.validation.ValidationException例外がスローされます。

正規表現の妥当性はjava.util.regex.Patternの仕様に依存します。

（凡例）−：該当しない。

上記の表に記載がないアノテーションについては，Bean Validation標準仕様に依存します。各仕様に依存するアノテーションについては，各仕様のドキュメントを参照してください。

10.5　Bean Validationの利用手順

この節では，Bean Validationの利用手順について説明します。

10.5.1　JSFからBean Validationの利用手順

ここでは，JSFからBean Validationを利用するための手順を示します。

(1)　使用前提条件

JSFでBean Validationによる検証処理を行うためには，次の条件を満たす必要があります。

WebページはFaceletsで作成してください。

ManagedBeanの中でBean Validationのアノテーションを利用して，制約を定義してください。

(2)　検証処理の動作

Bean Validationの検証処理の動作は，JSFが提供するコンテキストパラメタの値によって異なります。javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATORの設定値とBean Validationのアノテーションを定義しているManagedBeanに対する<f:validateBean>タグの有無によって，次の表に示すように動作が変わります。

表10‒4　javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATORの設定値と検証処理の関係

javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATORの設定値

入力値

<f:validateBean>タグの指定の有無（disabled属性を指定していない場合）

Bean Validationによる検証処理の有無

true

あり

あり

なし

なし

false

あり

あり

なし

あり

値を指定しなかった場合（デフォルト）

falseの場合と同様

falseの場合と同様

<f:validateBean>タグの使用方法の詳細に関しては，JSFの標準仕様を参照してください。ManagedBeanの変数に対するバリデーション定義の方法は，Bean Validationの標準仕様を参照してください。

(3)　実装例

JSFからBean Validationを使用する場合の実装例を示します。

まず，検証が必要な情報を登録するFaceletsページの実装例を示します。

  <f:view>
    <h:form>
        IDの入力<br/>
        <h:inputText id="IDBox" value="#{personalData.id}" /><br/>
        <h:message for="IDBox"/><br/>
        <br/>
      <f:validateBean disabled="true">
        名前の入力（検証処理は行いません）<br/>
        <h:inputText id="NameBox" value="#{personalData.name}" /><br/>
      </f:validateBean >
        <br/>
        年齢の入力<br/>
        <h:inputText id="AgeBox" value="#{personalData.age}" /><br/>
        <h:message for="AgeBox"/><br/>
        <br/>
      <br/>
　　　　：
　　　　：
    </h:form>
  </f:view>

注意事項

<f:validateBean disabled="true">を指定している<inputText>タグは，対応するManagedBeanの変数にバリデーションの定義をしていますが，検証処理は行われません。

次に，検証対象のデータを格納するManagedBeanに対するバリデーション定義の実装例を示します。

@ManagedBean(name="personalData")
@SessionScoped
public class PersonalData
{
    @Size(min=8,max=12, message="8から12文字までの文字列を入力してください。")
    private String id = "";

    @Size(min=1,message="名前を入力してください。")
    private String name = "";

    @Max(value = 150, message="年齢の入力が正しいか確認して下さい。")
    @Min(value = 0, message="０歳以上の年齢を入力してください。")
    private int age = 0;
　　　：
setter/gettterメソッド
　　　：
}

10.5.2　CDIからBean Validationの利用手順

ここでは，CDIからBean Validationを利用するための手順を示します。

(1)　利用前に必要な手順

CDIでBean Validationによる検証処理を行うためには，次の手順が必要になります。

ユーザアプリケーションクラスで@Injectアノテーションを使って，ValidatorFactoryを注入してください。

例:@Inject private ValidatorFactory validatorFactory

Validatorオブジェクトを得るために，Bean ValidationからユーザアプリケーションのvalidatorFactory.getValidator()を呼びます。

最後に，ユーザアプリケーションからvalidator.validate()メソッドを呼び，検証するBeanクラスを渡します。

(2)　実装例

CDIからBean Validationを使用する場合の実装例を示します。

まず，検証が必要な情報を登録するサーブレットの実装例を示します。

public class EmployeeServBv extends HttpServlet{
@Inject  private ValidatorFactory validatorFactory;
@Inject BV_CDI bean;

   public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException{
   Validator validator = validatorFactory.getValidator();
      validator.validate(bean);
   }
}

この例では，BV_CDI beanでBean Validationのアノテーションを適用しています。

検証対象のデータを格納するBeanに対する検証定義の実装例を次に示します。

import javax.validation.constraints.NotNull;
public class BV_CDI{
        @NotNull
        private String name;
        public String getName(){
                return name;
        }
        public void setName(String name){
                this.name = name;
        }
}

10.6　デバッグ用ログ（開発調査ログ）の利用

この節では，Bean Validationのデバッグ用ログ（開発調査ログ）について説明します。

Bean Validationでは，開発に関するメッセージが開発調査ログに出力されます。アプリケーションで利用しているBean Validationのデバッグをする場合に確認が必要なメッセージは，メッセージに出力されたクラス名から判断できます。メッセージを出力するクラス名について，次の表に示します。

表10‒5　Bean Validationの開発調査ログに出力されるクラス名

コンポーネント名

出力されるクラス名

出力内容

Bean Validation

com.hitachi.software.beanvalidation〜

障害に関するメッセージ

機能の動作状況に関するメッセージ

内部状態に関するメッセージ

なお，開発調査ログはデフォルトの設定では出力されません。必要に応じて設定を変更してください。

10.7　validation.xmlの内容が不正な場合の情報の出力

この節では，Bean Validationとの連携でvalidation.xmlの内容が不正な場合に出力されるメッセージについて説明します。

Bean Validationと連携するアプリケーション別に，出力されるメッセージIDと内容，および出力先と対処方法について次の表に示します。

表10‒6　validation.xmlの内容が不正な場合に出力されるメッセージ，出力先，および対処方法

Bean Validationと連携するアプリケーション

出力されるメッセージID，および内容

出力先，および対処方法

JSFアプリケーション

WebコンテナからKDJE39056-Eが出力されます。そのメッセージには，リソース名と例外名が出力されています。

出力先：

web_servletログ

対処方法：

validation.xmlの内容を確認し，問題点を修正してください。

CDIアプリケーション

KDJE59312-Eが出力されます。そのメッセージには，例外の詳細が出力されています。

出力先：

cjexceptionログ

対処方法：

validation.xmlの内容を確認し，問題点を修正してください。

ユーザアプリケーション（Webアプリケーション）

WebコンテナからKDJE39045-Eが出力されます。そのメッセージには，J2EEアプリケーション名とコンテキストルート名が出力されています。

出力先：

web_servletログ

対処方法：

validation.xmlの内容を確認し，問題点を修正してください。

ユーザアプリケーション（EJBアプリケーション）

−

出力先：

cjexceptionログ

対処方法：

validation.xmlの内容を確認し，問題点を修正してください。

（凡例）

−：該当しない。

10.8　Bean Validation実装時の注意事項

この節では，Bean Validation実装時の注意事項について説明します。

Bean Validation 1.0仕様での注意事項

Bean Validation 1.0仕様では，クラスパス上に配置できるvalidation.xmlは一つだけです。J2EEアプリケーションのクラスパス上に複数のvalidation.xmlを配置しないでください。

Bean Validation 2.0仕様での注意事項

java:comp/ValidatorFactoryのルックアップや@ResourceアノテーションによるValidatorFactoryの取得と，java:comp/Validatorのルックアップや@ResourceアノテーションによるValidatorの取得はできません。ValidatorFactoryやValidatorオブジェクトを取得する場合はCDIの@Injectアノテーションを用いて注入してください。

Webアプリケーション内にvalidation.xmlを含めることはできません。代わりにアプリケーション内のライブラリJAR内にvalidation.xmlを格納してください。Webアプリケーション内にvalidation.xmlを含めた場合，validation.xmlの指定値が適用されないで，デフォルトの動作となるおそれがあります。

次のライブラリをユーザアプリケーションに含めることや，コンテナ拡張ライブラリとしてクラスパスに追加することはできません。また，一部を除き，ユーザアプリケーションから直接参照することもできません。ユーザアプリケーション，およびコンテナ拡張ライブラリとして使用できないライブラリを次の表に示します。

表10‒7　ユーザアプリケーション，およびコンテナ拡張ライブラリとして使用できないライブラリ

ライブラリ名

パッケージ名

参照可否

Hibernate Validator

org.hibernate.validator

不可

Java ClassMate

com.fasterxml.classmate

不可

上記の表のライブラリは製品側で提供しています。ユーザ側で追加しても製品提供クラスが優先されるため，ライブラリのバージョンの差異などによって，アプリケーションが意図しない動作となるおそれがあります。

Message Interpolatorのデフォルトのメッセージに関する注意事項

Message Interpolatorのデフォルトのメッセージは，標準仕様に記載されている内容と異なります。アプリケーションサーバにおけるMessage Interpolatorのメッセージのデフォルト値を，次の表に示します。

表10‒8　アプリケーションサーバにおけるMessage Interpolatorのメッセージのデフォルト値

メッセージプロパティのキー

デフォルト値

javax.validation.constraints.AssertFalse.message

must be false

javax.validation.constraints.AssertTrue.message

must be true

javax.validation.constraints.Digits.message

numeric value out of bounds (<{integer} digits>.<{fraction} digits> expected)

javax.validation.constraints.Future.message

must be in the future

javax.validation.constraints.Max.message

must be less than or equal to {value}

javax.validation.constraints.Min.message

must be greater than or equal to {value}

javax.validation.constraints.NotNull.message

may not be null

javax.validation.constraints.Null.message

must be null

javax.validation.constraints.Past.message

must be in the past

javax.validation.constraints.Pattern.message

must match "{regexp}"

javax.validation.constraints.Size.message

size must be between {min} and {max}

11　Java Batch

この章では，Java Batchの概要とアプリケーションサーバでのJava Batchの利用について説明します。

11.1　この章の構成

この章では，Java Batchについて説明します。この章の構成を次の表に示します。

表11‒1　この章の構成（Java Batch）

分類

タイトル

参照先

解説

Java Batchの概要

11.2

前提環境

11.3

実装

アプリケーション実装時の注意事項

11.4

設定

ジョブリポジトリの設定

11.5

アプリケーションタグの設定

11.6

Java Batch実行用スレッドプールの設定

11.7

DB Connector属性ファイルの設定

11.8

ジョブリポジトリ自動生成の設定

11.9

運用

SQLファイル

11.10

ジョブリポジトリ管理機能

11.11

障害対応用の情報の出力および確認

11.12

注意事項

クラスタ構成

11.13

11.2　Java Batchの概要

JSR 352 Batch Application for the Java Platform（Java Batch） 1.0をサポートします。

11.3　前提環境

Java Batch標準仕様では，Java Batchのジョブの実行状態を永続化するために，「ジョブリポジトリ」と呼ばれるデータベースが必要となります。ジョブの実行ごとに，実行状態や実行結果などをジョブリポジトリに書き込むことで，ジョブの実行状態や実行結果をあとから確認したり，J2EEサーバを再起動後でも停止したジョブおよび失敗したジョブを再開させたりできます。

アプリケーションサーバのJava Batch 1.0では，ジョブリポジトリの永続化DBMSとして，HiRDB Version 10であることが前提となります。

ジョブリポジトリを更新するためのトランザクションと，ジョブ内で処理される業務のトランザクションは一貫性を保つ必要があります。そのため，ジョブリポジトリのデータソースと，ジョブ内の業務で使用するデータソースは，ともにXAデータソースを使用し，グローバルトランザクションである必要があります。

ジョブリポジトリはJobOperator取得前にHiRDB SQL Executerを使用して作成する必要があります。作成時に実行するSQLは「11.10　SQLファイル」を参照してください。アプリケーションの開発用途に限りジョブリポジトリの自動生成機能を使用できます。ただし，使用できるアプリケーションや環境に条件があります。詳細は「11.5　ジョブリポジトリの設定」を参照してください。

ジョブリポジトリに指定するパラメタのサイズ，およびジョブステップ間で受け渡すデータのサイズは64KB以下になるよう設計してください。64KBより大きな値を格納した場合，バッチジョブの実行元にJobStartExceptionがスローされ，例外ログに原因となったSQLExceptionを含むスタックトレースが出力されます。HiRDBで使用するテーブル情報は，「11.10.1　Java Batchのデータベーステーブル」を参照してください。

また，サポートするデータベース以外をジョブリポジトリに指定してバッチジョブを実行した場合，KDJE60519-Eをメッセージログに出力し，バッチジョブ実行元にはジョブリポジトリに接続できなかった場合と同様に，IllegalStateExceptionがスローされます。

11.4　アプリケーション実装時の注意事項

Java Batch 1.0標準仕様では，Batch Artifactから例外が挙がった場合の挙動が規定されていないため，各ベンダのアプリケーションサーバによって動作が異なるおそれがあります。

アプリケーションサーバでBatch Artifactから例外が挙がった場合の挙動と，ベンダ間ポータビリティ確保のためにアプリケーションに求められる注意事項を次に示します。

closeメソッド内の処理は，openメソッドが必ず呼ばれていることを前提とした処理にしないでください。ItemReaderのopenメソッドが呼び出される前に，同じItemReaderのcloseメソッドが呼び出されることがあります。

closeメソッド内の処理は，openメソッドが必ず呼ばれていることを前提とした処理にしないでください。ItemWriterのopenメソッドが呼び出される前に，同じItemWriterのcloseメソッドが呼び出されることがあります。

closeメソッドが必ず1度だけ呼び出されることを前提とした処理にしないでください。ItemReaderまたはItemWriterのcloseメソッドが2回以上呼び出されることがあります。

beforeReadメソッドの処理は，afterReadメソッドが呼び出されることを前提とした処理にしないでください。ItemReadListenerのbeforeReadメソッドが呼び出されたあとに，同じItemReadListenerのafterReadメソッドが呼び出されないことがあります。

beforeProcessメソッドの処理は，afterProcessメソッドが呼び出されることを前提とした処理にしないでください。ItemProcessListenerのbeforeProcessメソッドが呼び出されたあとに，同じItemProcessListenerのafterProcessメソッドが呼び出されないことがあります。

beforeWriteメソッドの処理は，afterWriteメソッドが呼び出されることを前提とした処理にしないでください。ItemWriteListenerのbeforeWriteメソッドが呼び出されたあとに，同じItemWriteListenerのafterWriteメソッドが呼び出されないことがあります。

beforeChunkメソッドの処理は，afterChunkメソッドが呼び出されることを前提とした処理にしないでください。ChunkListenerのbeforeChunkメソッドが呼び出されたあとに，同じChunkListenerのafterChunkメソッドが呼び出されないことがあります。

onErrorメソッド内の処理は，beforeChunkメソッドが必ず呼ばれていることを前提とした処理にしないでください。ChunkListenerのbeforeChunkメソッドが呼び出される前に，同じChunkListenerのonErrorメソッドが呼び出されることがあります。

ChunkListenerのafterChunkメソッドとonErrorメソッドのどちらか一方だけが呼び出されることを前提とした処理にしないでください。両方呼び出されることがあります。

beginCheckPointメソッドの処理は，endCheckPointメソッドやcheckPointInfoメソッドが呼び出されることを前提とした処理にしないでください。CheckpointAlgorithmのbeginCheckPointメソッドが呼び出されたあとに，同じCheckpointAlgorithmのendCheckPointメソッドや，ItemReader,ItemWriterのcheckPointInfoメソッドが呼び出されないことがあります。

afterPartitionedStepCompletionメソッド内の処理は，beforePartitionedStepCompletionメソッドまたはrollbackPartitionedStepメソッドが呼ばれていることを前提とした処理にしないでください。PartitionReducerのbeforePartitionedStepCompletionメソッドまたはrollbackPartitionedStepメソッドが呼び出される前に同じPartitionReducerのafterPartitionedStepCompletionメソッドが呼び出されることがあります。

PartitionReducerの各メソッドの処理は，rollbackPartitionedStepメソッドが呼び出されることを前提とした処理にしないでください。PartitionReducerの各メソッドで例外が発生した場合に，rollbackPartitionedStepメソッドが呼び出されないことがあります。

beforeStepメソッドの処理は，afterStepメソッドが呼び出されることを前提とした処理にしないでください。StepListenerのbeforeStepメソッドが呼び出されたあとに，同じStepListenerのafterStepメソッドが呼び出されないことがあります。

11.5　ジョブリポジトリの設定

ジョブリポジトリの永続化先となるデータソースとして，DB Connectorを開始しておく必要があります。

DB Connectorには，ユーザ指定名前空間機能を用いてJNDI名前空間に別名を指定し，その別名を次のユーザプロパティに指定してください。

ejbserver.javaee.batch.jobRepository.jndiName

上記のプロパティが未定義の場合は，「jdbc/__BatchPool」というJNDI名が使用されます。ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

JNDI名が不正な場合は，J2EEサーバ起動後の初回のjavax.batch.runtime.BatchRuntimeのgetJobOperatorメソッドの呼び出し時に，KDJE60514-Eがメッセージログに出力され，getJobOperatorメソッドの呼び出し元にランタイム例外が挙がります。

11.6　アプリケーションタグの設定

ジョブリポジトリでは，各ジョブの発行元J2EEサーバとアプリケーションとを識別するために，「アプリケーションタグ」という識別子を用います。デフォルトのアプリケーションタグは「<J2EEサーバ名>:<J2EEアプリケーション名>」であり，J2EEサーバ名とJ2EEアプリケーション名のペアで一意としています。クラスタ構成やHA構成を組むケースなど，複数のJ2EEサーバでジョブリポジトリを共有したい場合は，次のユーザプロパティでアプリケーションタグを任意に指定できます。

ejbserver.javaee.batch.<J2EEアプリケーション名>.appTag

<J2EEアプリケーション名>部分には，アプリケーション開始時にJ2EEサーバのメッセージKDJE42108-Iに出力されるJ2EEアプリケーション名を指定します。J2EEアプリケーション表示名（display-name）ではありませんので注意してください。

ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

11.7　Java Batch実行用スレッドプールの設定

ジョブを実行するスレッドは，Java Batch専用のスレッドプールを使用します。ジョブの実行に使用するスレッドプールの設定はデフォルトのままでも動作しますが，同時実行スレッド数の制御や，受け入れジョブ数の制御のために，スレッドプールの設定をアプリケーションごとにチューニングできます。また，複数のアプリケーション同士でスレッドプールを共有することもできます。

次のユーザプロパティで，ジョブの実行に使用するスレッドプールのJNDI名をアプリケーションごとに指定してください。

ejbserver.javaee.batch.<J2EEアプリケーション名>.executorService.jndiName

<J2EEアプリケーション名>部分には，アプリケーション開始時にJ2EEサーバのメッセージKDJE42108-Iに出力されるJ2EEアプリケーション名を指定します。J2EEアプリケーション表示名（display-name）ではありませんので注意してください。

なお，設定先J2EEサーバ内のすべてのアプリケーションに適用する場合は，次のように<J2EEアプリケーション名>に「*」を指定してください。

ejbserver.javaee.batch.*.executorService.jndiName

どちらも未定義の場合は，JNDI名「concurrent/__BatchExecutorService」のスレッドプールが使用されます。

各スレッドプールのチューニングをするユーザプロパティを次の表に示します。

表11‒2　Java Batch実行用スレッドプールのチューニングプロパティ

プロパティ名

指定内容

デフォルト値

ejbserver.javaee.batch.executorService.<JNDI名>※.minThreads

最小スレッド数

0

ejbserver.javaee.batch.executorService.<JNDI名>※.maxThreads

最大スレッド数

2147483647

ejbserver.javaee.batch.executorService.<JNDI名>※.queueSize

キューに待機可能なタスクの最大数

2147483647

ejbserver.javaee.batch.executorService.<JNDI名>※.keepAliveTime

最小スレッド数を超えた使用後のスレッドを再利用するまで待機する最長時間

（単位：秒）

60

注※

<JNDI名>はJava Batch実行用スレッドプールのJNDI名

ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

Java Batch実行用スレッドプールのチューニングプロパティ設定値は，J2EEサーバ起動時にメッセージログに出力されるメッセージKDJE60511-Iで確認できます。

JNDI名の重複や不正値の使用などによって，Java Batch実行用スレッドプールのJNDI名前空間への登録に失敗した場合は，J2EEサーバ起動時にメッセージログにKDJE60512-Eが出力されます。スタックトレースが例外ログに出力されますが，J2EEサーバの起動処理は続行します。

Java Batch実行用スレッドプールは，該当するスレッドプールを使用するジョブの初回実行時に初期化され，初期スレッド数に指定した数のスレッドが生成されます。生成されるスレッドは，スレッド名が「＜JNDI名＞-managedThreadFactory」から始まる名称となります。

何らかの理由によって初期化に失敗した場合はメッセージログにKDJE60513-Eが出力されます。バッチの開始時（startメソッド）であればjavax.batch.operations.JobStartExceptionが，バッチの再開時（restartメソッド）であればjavax.batch.operations.JobRestartExceptionが呼び出し元にスローされます。

スレッドプールはJ2EEサーバの停止時に破棄されます。

11.8　DB Connector属性ファイルの設定

Java Batch 1.0ではジョブリポジトリの永続化先DBMSと接続するためにDB Connectorの設定が必要になります。

Java Batch 1.0で使用できるDB ConnectorはDBConnector_HiRDB_Type4_XA.rarだけです。

なお，Java Batch 1.0で使用するDB Connectorとジョブ内の業務で使用するDB Connectorは分けて別々にデプロイしてください。

Java Batch 1.0で使用するDB Connectorで使用できる機能を次の表に示します。使用できない機能を有効にした場合の動作は保証しません。

表11‒3　Java Batch 1.0で使用するDB Connectorで使用できる機能

機能名

使用可否

コネクションプーリング

使用できる。必ず有効にしてください。

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

使用できる。必ず有効にしてください。

コネクション数調節機能

使用できる。必ず有効にしてください。

コネクションシェアリング

使用できる。

アソシエーション

使用できない。

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

使用できない。

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

使用できる。

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

使用できる。

コネクションの障害検知

使用できる。必ず有効にしてください。

コネクション障害検知のタイムアウト

使用できる。必ず有効にしてください。

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

使用できる。必ず有効にしてください。

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

使用できる。

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

使用できる。

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

使用できる。

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

使用できる。必ず有効にしてください。

コネクションスイーパ

使用できる。

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

使用できない。

障害調査用SQLの出力

使用できる。

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

使用できる。

リソースへの接続テスト

使用できる。

J2EEリソースへの別名付与

使用できる。

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

使用できる。

ステートメントsetQueryTimeoutメソッド

使用できる。

クライアントAPIで発生した例外の通知機能

使用できる。

Java Batch 1.0で使用するDB Connector のConnector属性ファイルに設定する内容を次の表に示します。記載されていない項目は，設定不要です。

表11‒4　Connector属性ファイルに設定する内容

指定するタグ

設定内容

<config-property>タグのdescription

データベースへの接続に必要な接続付加情報を設定します。

<config-property>タグのDBHostName

接続するHiRDBのホスト名を設定します。

<config-property>タグのXAOpenString

XAオープン文字列を設定します。

<config-property>タグのHiRDBCursorMode

HiRDBがコミットした場合にResultSetクラスのオブジェクトを有効とするかどうかの設定です。falseを指定してください※1。

<config-property>タグのPreparedStatementPoolSize

PreparedStatementプール数の設定です。0（ステートメントをプールしない）を指定してください。

<config-property>タグのCallableStatementPoolSize

CallableStatementプール数の設定です。0（ステートメントをプールしない）を指定してください。

<config-property>タグのCancelStatement

ステートメントをキャンセルするかどうかの設定です。false（実行中のSQLをキャンセルしません）を指定してください。

<property>タグのMaxPoolSize

プール内のコネクションの最大数を指定します※2。

<property>タグのMinPoolSize

プール内のコネクションの最小数を指定します。

<property>タグのUser

ユーザ名を指定します。

<property>タグのPassword

パスワードを指定します。

<resource-external-property>-<optional-name>タグ

リソースの別名を設定します。ユーザプロパティ（ejbserver.javaee.batch.jobRepository.jndiName）と同じ値を設定してください。

注※1

Java Batch機能ではHiRDBのホールダブルカーソル機能は使用できません。

注※2

Java Batch機能のコネクションはジョブ実行処理とジョブ情報取得処理に使用されます。次に示す二つの同時実行数の合計を基にコネクション数を算出してください。

・ジョブの最大同時実行数（PartitionまたはSplitで並列化する場合は，並列処理スレッド数も加算）

・ジョブ情報取得処理（javax.batch.runtime.JobExecutionのgetBatchStatusメソッドなど）の最大同時実行数

11.9　ジョブリポジトリ自動生成の設定

アプリケーションの開発用途に限り，ジョブリポジトリの自動生成機能を使用できます。ただし，次の条件を満たす必要があります。

javax.batch.runtime.BatchRuntimeクラスのgetJobOperatorメソッドの実行時に，JTAトランザクションが開始されていないこと。

接続先データベースがアプリケーション開発環境用であること。

ジョブリポジトリの生成方法は，次のプロパティで自動または手動に切り替えることができます。

ejbserver.javaee.batch.jobRepository.autoCreate.enabled

このプロパティのデフォルトはfalseです。trueを設定するとgetJobOperatorメソッドの呼び出し時に「11.10.1　Java Batchのデータベーステーブル」のジョブリポジトリが自動生成されます。

ジョブリポジトリとejbserver.javaee.batch.jobRepository.autoCreate.enabledプロパティの組み合わせを次の表に示します。

表11‒5　ジョブリポジトリとejbserver.javaee.batch.jobRepository.autoCreate.enabledプロパティの組み合わせ

ジョブリポジトリ

ejbserver.javaee.batch.jobRepository.autoCreate.enabled

true

false

存在する

新たにジョブリポジトリの作成は行われません。存在するジョブリポジトリが使用されます。

存在するジョブリポジトリが使用されます。

存在しない※

ジョブリポジトリが作成され，作成されたジョブリポジトリが使用されます。

ジョブリポジトリの作成に失敗した場合は次の動作をします。

JTAトランザクションが開始されている場合

KDJE60518-Eをメッセージログに出力し，java.sql.SQLNonTransientExceptionを原因とするjava.util.ServiceConfigurationErrorをスローします。

JTAトランザクションが開始されていない場合

java.sql.SQLExceptionをスローします。

getJobOperatorメソッドの呼び出し時にKDJE60517-Eをメッセージログに出力し，java.sql.SQLNonTransientExceptionを原因とするjava.util.ServiceConfigurationErrorをスローします。

注※

ジョブリポジトリの作成に失敗し，テーブルなどが残存している場合は，「11.10.2　HiRDB用のSQLファイル」のDROP文を実行し，テーブルをクリアしたあとに，ジョブリポジトリを作成してください。

11.10　SQLファイル

手動でテーブルを作成するSQLをjsr352-hirdb.sqlファイルで提供しています。getJobOperatorメソッド実行前にジョブリポジトリを作成してください。getJobOperatorメソッド実行後に作成した場合，バッチジョブの実行結果は削除されます。テーブルを格納する領域を指定したいなど，テーブルのチューニングをする場合にはSQLファイルを編集できます。jsr352-hirdb.sqlファイルの格納場所を次に示します。

<Application Serverのインストールディレクトリ>¥CC¥javaee¥1100¥templates¥sql¥jsr352-hirdb.sql

SQLファイルの詳細は「11.10.2　HiRDB用のSQLファイル」を参照してください。

また，Java Batch機能が不要になった場合は，上記SQLファイルに記載されているDROP文を実行することで，テーブルを削除できます。

11.10.1　Java Batchのデータベーステーブル

Java Batch機能でHiRDBに作成するテーブル情報を次に示します。

(1)　JOBINSTANCEDATAテーブル

テーブル名：JOBINSTANCEDATA

レコード数：バッチジョブ実行回数

表11‒6　JOBINSTANCEDATAに格納するデータ

カラム名

データ型

属性

概要

jobinstanceid

DECIMAL(19)

PRIMARY KEY

ジョブインスタンスID

SEQUENTIALIDINFOテーブルで採番された値を格納します。

name

VARCHAR(512)

n/a

ジョブ名

apptag

VARCHAR(512)

n/a

アプリケーションタグ

(2)　EXECUTIONINSTANCEDATAテーブル

テーブル名：EXECUTIONINSTANCEDATA

レコード数：バッチジョブ実行回数＋エラー発生後の再実行回数

表11‒7　EXECUTIONINSTANCEDATAに格納するデータ

カラム名

データ型

属性

概要

jobexecid

DECIMAL(19)

PRIMARY KEY

ジョブ実行ID

SEQUENTIALIDINFOテーブルで採番された値を格納します。

jobinstanceid

DECIMAL(19)

n/a

ジョブインスタンスID

createtime

TIMESTAMP(4)

n/a

ジョブ作成日時

starttime

TIMESTAMP(4)

n/a

ジョブ実行日時

endtime

TIMESTAMP(4)

n/a

ジョブ終了日時

updatetime

TIMESTAMP(4)

n/a

ジョブ更新日時

parameters

BINARY(65536)

n/a

ジョブ実行時に指定したパラメタオブジェクト

batchstatus

VARCHAR(512)

n/a

バッチの状態

exitstatus

VARCHAR(512)

n/a

終了状態

(3)　STEPEXECUTIONINSTANCEDATAテーブル

テーブル名：STEPEXECUTIONINSTANCEDATA

レコード数：バッチジョブ中のジョブステップ数×（バッチジョブ実行回数＋エラー発生後の再実行回数）

表11‒8　STEPEXECUTIONINSTANCEDATAに格納するデータ

カラム名

データ型

属性

概要

stepexecid

DECIMAL(19)

PRIMARY KEY

ステップ実行ID

SEQUENTIALIDINFOテーブルで採番された値を格納します。

jobexecid

DECIMAL(19)

n/a

ジョブ実行ID

batchstatus

VARCHAR(512)

n/a

バッチの状態

exitstatus

VARCHAR(512)

n/a

終了状態

stepname

VARCHAR(512)

n/a

ステップ名

readcount

DECIMAL(11)

n/a

読み込み回数

writecount

DECIMAL(11)

n/a

書き込み回数

commitcount

DECIMAL(11)

n/a

コミット回数

rollbackcount

DECIMAL(11)

n/a

ロールバック回数

readskipcount

DECIMAL(11)

n/a

読み込みスキップ回数

processskipcount

DECIMAL(11)

n/a

処理スキップ回数

filtercount

DECIMAL(11)

n/a

フィルタ回数

writeskipcount

DECIMAL(11)

n/a

書き込みスキップ回数

startTime

TIMESTAMP(4)

n/a

開始日時

endTime

TIMESTAMP(4)

n/a

終了日時

persistentData

BINARY(65536)

n/a

ジョブ実行に使用するユーザデータを格納したオブジェクト

(4)　JOBSTATUSテーブル

テーブル名：JOBSTATUS

レコード数：バッチジョブの実行回数

表11‒9　JOBSTATUSに格納するデータに格納するデータ

カラム名

データ型

属性

概要

id

DECIMAL(19)

PRIMARY KEY

ジョブインスタンスID

obj

BINARY(65536)

n/a

ジョブの実行状態を管理するオブジェクト

(5)　STEPSTATUSテーブル

テーブル名：STEPSTATUS

レコード数：バッチジョブ中のジョブステップ数×（バッチジョブ実行回数＋エラー発生後の再実行回数）

表11‒10　STEPSTATUSに格納するデータ

カラム名

データ型

属性

概要

id

DECIMAL(19)

PRIMARY KEY

ステップ実行ID

obj

BINARY(65536)

n/a

ステップの実行状態を管理するオブジェクト

(6)　CHECKPOINTDATAテーブル

テーブル名：CHECKPOINTDATA

レコード数：バッチジョブ中のチェックポイント数×（バッチジョブ実行回数＋エラー発生後の再実行回数）

表11‒11　CHECKPOINTDATAに格納するデータ

カラム名

データ型

属性

概要

id

VARCHAR(512)

n/a

チェックポイントデータのキー名

"ジョブインスタンスID,ステップ名,チェックポイントデータストリーム名"

obj

BINARY(65536)

n/a

チェックポイントデータの値

(7)　SEQUENTIALIDINFOテーブル

テーブル名：SEQUENTIALIDINFO

レコード数：3

FIX表かつWITHOUT ROLLBACKオプションを指定して作成することで，トランザクションのコミットを待たないでテーブルの更新が確定します。

表11‒12　SEQUENTIALIDINFOに格納するデータ

カラム名

データ型

属性

概要

name

CHAR(64)

n/a

採番するID名

id

DECIMAL(19)

n/a

次に採番するIDの値

1から開始します。

11.10.2　HiRDB用のSQLファイル

HiRDB用に提供するSQLファイル（jsr352-hirdb.sql）の内容を次に示します。

DROP PROCEDURE SEQUENTIALIDINFO_NEXTID;
DROP TABLE SEQUENTIALIDINFO;
DROP INDEX CHK_INDEX;
DROP TABLE CHECKPOINTDATA;
DROP TABLE STEPSTATUS;
DROP TABLE JOBSTATUS;
DROP TABLE STEPEXECUTIONINSTANCEDATA;
DROP TABLE EXECUTIONINSTANCEDATA;
DROP TABLE JOBINSTANCEDATA;

CREATE TABLE JOBINSTANCEDATA(
  jobinstanceid   DECIMAL(19) PRIMARY KEY,
  name            VARCHAR(512),
  apptag          VARCHAR(512)
);

CREATE TABLE EXECUTIONINSTANCEDATA(
  jobexecid       DECIMAL(19) PRIMARY KEY,
  jobinstanceid   DECIMAL(19),
  createtime      TIMESTAMP(4),
  starttime       TIMESTAMP(4),
  endtime         TIMESTAMP(4),
  updatetime      TIMESTAMP(4),
  "parameters"    BINARY(65536),
  batchstatus     VARCHAR(512),
  exitstatus      VARCHAR(512),
  CONSTRAINT JOBINST_JOBEXEC_FK FOREIGN KEY (jobinstanceid) REFERENCES JOBINSTANCEDATA
);

CREATE TABLE STEPEXECUTIONINSTANCEDATA(
  stepexecid          DECIMAL(19) PRIMARY KEY,
  jobexecid           DECIMAL(19),
  batchstatus         VARCHAR(512),
  exitstatus          VARCHAR(512),
  stepname            VARCHAR(512),
  readcount           DECIMAL(11),
  writecount          DECIMAL(11),
  commitcount         DECIMAL(11),
  rollbackcount       DECIMAL(11),
  readskipcount       DECIMAL(11),
  processskipcount    DECIMAL(11),
  filtercount         DECIMAL(11),
  writeskipcount      DECIMAL(11),
  startTime           TIMESTAMP(4),
  endTime             TIMESTAMP(4),
  persistentData      BINARY(65536),
  CONSTRAINT JOBEXEC_STEPEXEC_FK FOREIGN KEY (jobexecid) REFERENCES EXECUTIONINSTANCEDATA
);

CREATE TABLE JOBSTATUS (
  id  DECIMAL(19) PRIMARY KEY,
  obj BINARY(65536),
  CONSTRAINT JOBSTATUS_JOBINST_FK FOREIGN KEY (id) REFERENCES JOBINSTANCEDATA ON DELETE CASCADE
);

CREATE TABLE STEPSTATUS(
  id  DECIMAL(19) PRIMARY KEY,
  obj BINARY(65536),
  CONSTRAINT STEPSTATUS_STEPEXEC_FK FOREIGN KEY (id) REFERENCES STEPEXECUTIONINSTANCEDATA ON DELETE CASCADE
);

CREATE TABLE CHECKPOINTDATA(
  id  VARCHAR(512),
  obj BINARY(65536)
);

CREATE INDEX CHK_INDEX ON CHECKPOINTDATA(id);

CREATE FIX TABLE SEQUENTIALIDINFO(
  name CHAR(64),
  id   DECIMAL(19)
) WITHOUT ROLLBACK;
INSERT INTO SEQUENTIALIDINFO VALUES('jobinstanceid', 1);
INSERT INTO SEQUENTIALIDINFO VALUES('jobexecid', 1);
INSERT INTO SEQUENTIALIDINFO VALUES('stepexecid', 1);

CREATE PROCEDURE SEQUENTIALIDINFO_NEXTID(
  IN  seq_name CHAR(64),
  OUT next_id  DECIMAL(19)
)
  BEGIN
    DECLARE update_id DECIMAL(19);
    DECLARE cr1 CURSOR FOR
      SELECT id FROM SEQUENTIALIDINFO
        WHERE name=seq_name
        FOR UPDATE;
    OPEN cr1;
    FETCH cr1 INTO update_id;
    SET next_id=update_id;
    UPDATE SEQUENTIALIDINFO SET id=update_id+1
      WHERE CURRENT OF cr1;
    CLOSE cr1;
  END
END_PROC;

11.11　ジョブリポジトリ管理機能

ジョブリポジトリ管理機能としてcjdeljbatchjobsコマンドを提供しています。cjdeljbatchjobsコマンドは，ジョブリポジトリ内で増加し続けるジョブデータを削除するコマンドです。

11.11.1　cjdeljbatchjobsコマンドの格納先

cjdeljbatchjobsコマンドの格納先を次に示します。

<Application Serverのインストールディレクトリ>¥CC¥admin¥bin¥cjdeljbatchjobs.bat

11.11.2　cjdeljbatchjobsコマンド仕様

ジョブリポジトリ管理機能で提供するcjdeljbatchjobsコマンドの仕様を次に示します。

形式1

cjdeljbatchjobs [<サーバ名称>] [-nameserver <プロバイダURL>] -list
-name <J2EEアプリケーション名> -day <日数> [-all] -f <削除対象一覧ファイルの絶対パス>

形式2

cjdeljbatchjobs [<サーバ名称>] [-nameserver <プロバイダURL>] -delete
-f <削除対象一覧ファイルの絶対パス> [-t <トランザクションタイムアウト時間>]

機能

形式1の場合，引数によって指定した範囲のジョブリポジトリ中のジョブデータを，削除対象一覧ファイルとして出力します。

形式2の場合，形式1のコマンド実行によって出力された削除対象一覧ファイルに記載されているジョブデータを，ジョブリポジトリから削除します。

引数

サーバ名称を指定する場合，コマンド名の直後でなければなりません。サーバ名称以外の引数は，サーバ名称より後ろ（サーバ名称省略時はコマンド名の後ろ）であれば順序は任意です。

サーバ名称

接続先サーバ名称を指定します。省略時はホスト名がサーバ名称となります。

-nameserver プロバイダURL

プロバイダURLを指定します。省略時はNamingSeviceが返すデフォルト値が仮定されます。

-list

指定したJ2EEアプリケーションが作成したジョブリポジトリ中のジョブデータを，削除対象一覧ファイルとして出力します。-deleteと併用することはできません。

-delete

削除対象一覧ファイルに記載されているジョブデータをジョブリポジトリから削除します。-listと併用することはできません。

-name J2EEアプリケーション名

削除対象のジョブを実行したアプリケーション名を指定します。アンデプロイされたアプリケーションのアプリケーション名も指定できます。

-day <日数>

現在より何日以前のジョブデータを削除対象とするかを指定します。<日数>日前の23:59:59.999以前のジョブデータが削除対象となります。0を指定した場合，現在時刻以前のジョブデータが削除対象となります。指定できる値は0〜366の整数です。

-all

再開できるジョブを削除対象とする場合に指定します。指定しない場合，再開できないジョブが削除対象となります。指定した場合，再開できないジョブに加えて再開できるジョブも削除対象となります。

-f 削除対象一覧ファイルの絶対パス

-listオプションを指定する場合，削除対象一覧ファイルの出力先を指定します。出力先は，絶対パスで指定します。ただし，絶対パスに含まれるディレクトリは存在する必要があります。出力先ディレクトリに，出力する削除対象一覧ファイルと同じ名前のファイルが存在してはなりません。

-deleteオプションを指定する場合，-listオプション指定時に出力された削除対象一覧ファイルのパスを指定します。削除対象一覧ファイルのパスは絶対パスで指定してください。

-tトランザクションタイムアウト時間

-deleteオプションを指定する場合に，コマンド実行中にJ2EEサーバからジョブリポジトリ（DB）にアクセスするときに使用されるトランザクションタイムアウト時間（秒）を指定します。指定しない場合や0を指定した場合，（J2EEサーバの「ejbserver.jta.TransactionManager.defaultTimeOut」プロパティの値）が設定されます。指定できる値は0〜2147483647の整数です。

終了コード

0：正常終了

1：異常終了

2：排他エラーによるコマンド実行不可

11.11.3　ジョブデータの削除手順

一定期間経過し，指定した条件に合致するジョブデータの削除手順を次の図に示します。

図11‒1　ジョブデータの削除手順

ジョブデータの削除手順を次に示します。削除手順の番号は，図11-1の番号に対応しています。

削除条件を指定します。

cjdeljbatchjobsコマンドの-listオプション形式で削除条件を指定することで，一定期間経過し，削除条件に合致する削除対象ジョブデータの情報を取得します。

削除対象を確認します。

1.で出力された削除対象一覧ファイルにはcjdeljbatchjobsコマンドの-listオプション形式で実行したときのパラメタ情報が格納されています。

削除対象一覧ファイルのパラメタ情報を参照し，意図したとおりのパラメタを指定したかどうかを確認します。確認する項目を次の表に示します。

表11‒13　削除対象一覧ファイルの確認項目

確認項目

確認個所（パラメタ情報）

J2EEサーバ名

server-name

アプリケーション名

application-name

アプリケーションタグ

apptag

日数※

delete-timestamp

全削除するかどうか

all

注※

cjdeljbatchjobsコマンドの日数は数値で指定するため，指定が正しいことを削除起点時刻で確認してください。

削除します。

1.で出力した削除対象一覧ファイルを指定し，cjdeljbatchjobsコマンドを-deleteオプション形式で実行することで，削除対象一覧ファイルにあるジョブデータを削除します。

なお，ジョブリポジトリ管理機能によってジョブデータを削除するときの注意事項を次に示します。

DB Connectorを開始しており，コネクションプールに空きが一つ以上あることが前提となります。

削除手順の1.〜3.の間は，削除対象ジョブリポジトリに変更が加わらないよう，削除対象ジョブリポジトリにアクセスしないでください。具体的には，ジョブ実行，ジョブリポジトリの変更，SQLの発行などをしないでください。

削除手順の1.〜3.の間は，J2EEサーバのシステム時刻を変更しないでください。

対象のアプリケーションのJ2EEサーバが起動している状態で実行してください。

コマンドを実行するホストと，対象のアプリケーションのJ2EEサーバを同一にしてください。

11.12　障害対応用の情報の出力および確認

Java Batchを使用したアプリケーションで障害が発生した場合，一部のログは「OSSが出力するメッセージ」として出力されます。詳細は，マニュアル「アプリケーションサーバ メッセージ（構築／運用／開発用）」の「OSSが出力するメッセージ」を参照してください。

11.13　クラスタ構成

Java Batch 1.0を使用する場合，J2EEサーバを冗長化したクラスタ構成をサポートしません。

12　JSON-P

この章では，JSON-Pの概要について説明します。

12.1　この章の構成

この章では，JSON-Pの概要について説明します。この章の構成を次の表に示します。

表12‒1　この章の構成

分類

タイトル

参照先

解説

JSON-Pの概要

12.2

12.2　JSON-Pの概要

JSR 374 Java API for JSON Processing（JSON-P） 1.1をサポートします。

詳細は，JSON-Pの標準仕様書を参照してください。

13　JSON-B

この章では，JSON-Bの概要について説明します。

13.1　この章の構成

この章では，JSON-Bの概要について説明します。この章の構成を次の表に示します。

表13‒1　この章の構成

分類

タイトル

参照先

解説

JSON-Bの概要

13.2

13.2　JSON-Bの概要

JSR 367 Java API for JSON Binding（JSON-B） 1.0をサポートします。

詳細は，JSON-Bの標準仕様書を参照してください。

14　Concurrency Utilities

この章では，Concurrency Utilitiesの概要について説明します。

14.1　この章の構成

この章では，Concurrency Utilitiesについて説明します。この章の構成を次の表に示します。

表14‒1　この章の構成

分類

タイトル

参照先

解説

Concurrency Utilities for Java EEの概要

14.2

実装

非サポート機能

14.3

設定

ManagedExecutorServiceの設定

14.4

ManagedScheduledExecutorServiceの設定

14.5

ManagedThreadFactoryの設定

14.6

実行時間監視機能の設定

14.7

運用

ManagedExecutorServiceの動作

14.8

ManagedScheduledExecutorServiceの動作

14.9

ManagedThreadFactoryの動作

14.10

14.2　Concurrency Utilities for Java EEの概要

JSR 236 Concurrency Utilities for Java EE（Concurrency Utilities） 1.0をサポートします。ただし，一部非サポートの機能があります。

14.3　非サポート機能

次に示す機能は，非サポートです。この機能を使用した場合の動作は保証しません。

ContextService機能

javax.enterprise.concurrent.ContextServiceオブジェクトを，ルックアップまたは@Resourceアノテーションで注入しようとした場合，javax.naming.NameNotFoundExceptionが挙がり，ルックアップまたは注入に失敗します。

14.4　ManagedExecutorServiceの設定

アプリケーションサーバがデフォルトで登録する「java:comp/DefaultManagedExecutorService」は，「concurrent/ __defaultManagedExecutorService」というJNDI名であらかじめ定義されています。それ以外にユーザ定義のManagedExecutorServiceを作成する場合は，次に示すプロパティに，ルックアップに使用するJNDI名を半角コンマ区切りで指定します。

ejbserver.javaee.concurrent.managedExecutorService.jndiNames

デフォルトで登録されているJNDI名「concurrent/__defaultManagedExecutorService」および上記のプロパティでユーザが定義したJNDI名のManagedExecutorServiceに対して，ManagedExecutorServiceのチューニングをするユーザプロパティを次の表に示します

表14‒2　ManagedExecutorServiceのチューニングプロパティ

プロパティ名

指定内容

デフォルト値

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.corePoolSize

初期スレッド数

16

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.maxPoolSize

最大スレッド数

16

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.taskQueueCapacity

キューに待機可能なタスクの最大数

2147483647

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.hungAfterSeconds

longRunningTasksがfalseの場合に，無応答と判断されるまでのスレッド実行時間（単位：秒）。0以下の場合は無応答と判断されません。

0

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.longRunningTasks

長時間実行用のタスクかどうかを指定します。

falseの場合，タスク実行開始からhungAfterSeconds経過してもタスクが終了していないときは無応答と判定されます。trueの場合は判定しません。

false

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.threadLifeTimeSeconds

利用しなくなったスレッドを破棄するまでの時間（単位：秒）。0の場合は破棄しません（常に再利用します）。

0

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.threadPriority

生成したスレッドのPriorityを1〜10の範囲で指定します。

5

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.keepAliveSeconds

最小スレッド数を超えた使用後のスレッドを，再利用するまで待機する最長時間（単位：秒）。

60

ejbserver.javaee.concurrent.managedExecutorService.<JNDI名>※.awaitTerminationSeconds

2EEサーバ停止時に実行中のタスクが終了するまで待機する最大待機時間（単位：秒）。0を指定した場合はタスクの終了を待たないで強制終了します。

0

注※

<JNDI名>は，「concurrent/__defaultManagedExecutorService」またはユーザが定義したManagedExecutorServiceのJNDI名

ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

14.5　ManagedScheduledExecutorServiceの設定

アプリケーションサーバがデフォルトで登録する「java:comp/DefaultManagedScheduledExecutorService」は，「concurrent/ __defaultManagedScheduledExecutorService」というJNDI名であらかじめ定義されています。それ以外にユーザ定義のManagedScheduledExecutorServiceを作成する場合は，次に示すプロパティに，ルックアップに使用するJNDI名を半角コンマ区切りで指定します。

ejbserver.javaee.concurrent.managedScheduledExecutorService.jndiNames

デフォルトで登録されているJNDI名「concurrent/__defaultManagedScheduledExecutorService」および上記のプロパティでユーザが定義したJNDI名のManagedScheduledExecutorServiceに対して，ManagedScheduledExecutorServiceのチューニングをするユーザプロパティを次の表に示します。

表14‒3　ManagedScheduledExecutorServiceのチューニングプロパティ

プロパティ名

指定内容

デフォルト値

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.corePoolSize

初期スレッド数

16

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.hungAfterSeconds

longRunningTasksがfalseの場合に，無応答と判断されるまでのスレッド実行時間（単位：秒）。0以下の場合は無応答と判断されません。

0

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.longRunningTasks

長時間実行用のタスクかどうかを指定します。

falseの場合，タスク実行開始からhungAfterSeconds経過してもタスクが終了していないときは無応答と判定されます。trueの場合は判定しません。

false

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.threadLifeTimeSeconds

利用しなくなったスレッドを破棄するまでの時間（単位：秒）。0の場合は破棄しません（常に再利用します）。

0

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.threadPriority

生成したスレッドのPriorityを1〜10の範囲で指定します。

5

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.keepAliveSeconds

最小スレッド数を超えた使用後のスレッドを再利用するまで待機する最長時間（単位：秒）。

60

ejbserver.javaee.concurrent.managedScheduledExecutorService.<JNDI名>※.awaitTerminationSeconds

J2EEサーバ停止時に実行中のタスクが終了するまで待機する最大待機時間（単位：秒）。0を指定した場合はタスクの終了を待たないで強制終了します。

0

注※

<JNDI名>は，「concurrent/__defaultManagedScheduledExecutorService」またはユーザが定義したManagedScheduledExecutorServiceのJNDI名

ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

14.6　ManagedThreadFactoryの設定

アプリケーションサーバがデフォルトで登録する「java:comp/DefaultManagedThreadFactory」は，「concurrent/ __defaultManagedThreadFactory」というJNDI名であらかじめ定義されています。それ以外にユーザ定義のManagedThreadFactoryを作成する場合は，次に示すプロパティに，ルックアップに使用するJNDI名を半角コンマ区切りで指定します。

ejbserver.javaee.concurrent.managedThreadFactory.jndiNames

デフォルトで登録されているJNDI名「concurrent/__defaultManagedThreadFactory」および上記のプロパティでユーザが定義したJNDI名のManagedThreadFactoryに対して，ThreadFactoryのチューニングをするユーザプロパティを次の表に示します。

表14‒4　ManagedScheduledExecutorServiceのチューニングプロパティ

プロパティ名

指定内容

デフォルト値

ejbserver.javaee.concurrent.managedThreadFactory.<JNDI名>※.threadPriority

生成したスレッドのPriorityを1〜10の範囲で指定します。

5

注※

<JNDI名>は，「concurrent/__defaultManagedThreadFactory」またはユーザが定義したManagedThreadFactoryのJNDI名

ユーザプロパティの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

14.7　実行時間監視機能の設定

longRunningTasksプロパティの指定値がfalse，かつhungAfterSecondsプロパティの指定値が1以上のManagedExecutorServiceまたはManagedScheduledExecutorServiceが，J2EEサーバ内に一つでも存在した場合，該当するJ2EEサーバの起動時に実行時間監視スレッドが開始され，一定間隔で定期的に実行時間が監視されます。実行時間監視スレッドが開始されると，メッセージログにKDJE60817-Iが出力されます。

監視間隔は次に示すプロパティに秒数で指定します。デフォルトは60秒間隔です。

ejbserver.javaee.concurrent.hungCheckIntervalSeconds

指定秒数ごとに，実行時間がhungAfterSeconds指定値を超えているタスクは無応答と判断され，無応答のタスク個数分KDJE60818-Wがメッセージログに出力されます。実行が完了したタスクに対しては出力されません。監視間隔を短くすると，その分KDJE60818-Wの出力回数も増えます。

14.8　ManagedExecutorServiceの動作

ManagedExecutorServiceのチューニングプロパティ設定値は，J2EEサーバ起動時にメッセージログに出力されるメッセージKDJE60811-Iで確認できます。

JNDI名の重複や不正値の使用などによって，ManagedExecutorServiceのJNDI名前空間への登録に失敗した場合は，J2EEサーバ起動時にメッセージログにKDJE60812-Eが出力され，スタックトレースが例外ログに出力されますが，J2EEサーバの起動処理は続行します。

ManagedExecutorServiceのスレッドプールは，該当するスレッドプールを使用するタスクの初回実行時に初期化され，corePoolSizeに指定した数のスレッドが生成されます。生成されるスレッドは，スレッド名が「＜JNDI名＞-managedThreadFactory」から始まる名称で，生成された順に通番が付きます。

スレッドプール内のスレッド数は，Java SE API「java.util.concurrent.ThreadPoolExecutor」の仕様に従い，corePoolSize, maxPoolSize, taskQueueCapacityの指定値に応じて自動的に調整されます。

実行中のスレッド数がcorePoolSize未満の場合は，新規タスクはすぐに開始されます。

実行中のスレッド数がcorePoolSize 以上maxPoolSize未満の場合は，新規タスクはキューに貯められ，スレッドプールが空くまで待機します。

キューが満杯になると新しいスレッドが作成されて，キューの先頭からタスクが実行されます。作成されるスレッドは最大でmaxPoolSizeまでとなります。

実行中のスレッド数がmaxPoolSizeに達していて，かつキューが満杯の場合は，新規タスクは拒否され，javax.enterprise.concurrent.ManagedExecutorServiceインタフェースのexecuteメソッドまたはsubmitメソッドからjava.util.concurrent.RejectedExecutionExceptionがスローされます。

corePoolSize と maxPoolSize を同じ値に設定すると，固定サイズのスレッドプールが作成されます。デフォルトではcorePoolSizeとmaxPoolSizeがともに16のため，プール数が16個固定のスレッドプールが生成されます。

ManagedExecutorServiceのスレッドプールはJ2EEサーバ停止時に破棄されます。破棄が完了するとメッセージログにKDJE60823-Iが出力されます。破棄処理時に何らかの例外が発生した場合は，メッセージログにKDJE60824-E，例外ログにスタックトレースが出力され，J2EEサーバ停止処理を続行します。

J2EEサーバ停止処理中に実行中のタスクが残っていた場合は，awaitTerminationSecondsの値に応じて，次の動作をします。

awaitTerminationが0の場合

メッセージログにKDJE60822-Wが出力され，実行中のタスクは強制停止されます。

awaitTerminationが1以上の場合

メッセージログにKDJE60820-Iが出力され，awaitTermination設定時間分待機します。awaitTermination設定時間経過後も実行中のタスクが残った場合は，メッセージログにKDJE60821-Wが出力され，残っていたタスクは強制停止されます。

14.9　ManagedScheduledExecutorServiceの動作

ManagedScheduledExecutorServiceのチューニングプロパティ設定値は，J2EEサーバ起動時にメッセージログに出力されるメッセージKDJE60813-Iで確認できます。

JNDI名の重複や不正値の使用などによって，ManagedScheduledExecutorServiceのJNDI名前空間への登録に失敗した場合は，J2EEサーバ起動時にメッセージログにKDJE60814-Eが出力され，スタックトレースが例外ログに出力されますが，J2EEサーバの起動処理は続行します。

ManagedScheduledExecutorServiceのスレッドプールは，該当するスレッドプールを使用するタスクの初回実行時に初期化され，corePoolSizeに指定した数のスレッドが生成されます。生成されるスレッドは，スレッド名が「＜JNDI名＞-managedThreadFactory」から始まる名称で，生成された順に通番が付きます。

ManagedScheduledExecutorServiceのスレッドプールはJ2EEサーバ停止時に破棄されます。破棄が完了するとメッセージログにKDJE60828-Iが出力されます。破棄処理時に何らかの例外が発生した場合は，メッセージログにKDJE60829-E，例外ログにスタックトレースが出力され，J2EEサーバ停止処理を続行します。

J2EEサーバ停止処理中に実行中のタスクが残っていた場合は，awaitTerminationSecondsの値に応じて，次の動作をします。

awaitTerminationが0の場合

メッセージログにKDJE60827-Wが出力され，実行中のタスクは強制停止されます。

awaitTerminationが1以上の場合

メッセージログにKDJE60825-Iが出力され，awaitTermination設定時間分待機します。awaitTermination設定時間経過後も実行中のタスクが残った場合は，メッセージログにKDJE60826-Wが出力され，残っていたタスクは強制停止さます。

14.10　ManagedThreadFactoryの動作

ManagedThreadFactoryのチューニングプロパティ設定値は，J2EEサーバ起動時にメッセージログに出力されるメッセージKDJE60815-Iで確認できます。

JNDI名の重複や不正値の使用などによって，ManagedThreadFactoryのJNDI名前空間への登録に失敗した場合は，J2EEサーバ起動時にメッセージログにKDJE60816-Eが出力され，スタックトレースが例外ログに出力されますが，J2EEサーバの起動処理は続行します。

ThreadFactory生成されるスレッドは，スレッド名が「＜JNDI名＞」から始まる名称で，生成された順に通番が付きます。

15　Interceptors

この章では，Interceptorsの概要について説明します。

15.1　この章の構成

この章では，Interceptorsについて説明します。この章の構成を次の表に示します。

表15‒1　この章の構成

分類

タイトル

参照先

解説

この章で使用する用語の定義

15.2

Interceptorsの概要

15.3

非サポート機能

15.4

日立で独自に明確化する仕様

15.5

15.2　この章で使用する用語の定義

この章で使用する用語の定義について説明します。

表15‒2　この章で使用する用語の定義

用語

定義

ターゲットクラス

インターセプタの適用対象となるコンポーネントのクラスです。EJBの実装クラスやCDIのBeanクラスがあります。

インターセプタクラス

ターゲットクラス自体とは別に，インターセプタメソッドを持つクラスです。ターゲットクラスやターゲットクラスのメソッド・コンストラクタに関連づけることができます。

インターセプタメソッド

ターゲットクラスのメソッド呼び出し，コンストラクタ呼び出し，またはライフサイクルイベントの前後に割り込むメソッドです。

ビジネスメソッドインターセプタメソッド

ビジネスメソッド呼び出しの前後に割り込むAroundInvokeメソッドのことです。

タイムアウトメソッドインターセプタメソッド

タイムアウトメソッド呼び出しの前後に割り込むAroundTimeoutメソッドのことです。

ライフサイクルコールバックインターセプタメソッド

ライフサイクルイベントの前後に割り込むメソッドです。AroundConstructメソッドはターゲットクラスのコンストラクタ呼び出しに割り込みます。PostConstructメソッドはターゲットクラスのインスタンス生成とDIが終わった直後に呼び出されます。PreDestoryメソッドはコンテナによるインスタンスの破棄に割り込みます。EJB仕様ではPostActivateメソッドとPrePassivateメソッドも定義されています。

DI

Dependency Injectionの略称です。

EJBインターセプタ

Interceptorsアノテーションで，ターゲットクラスまたはそのメソッド・コンストラクタに関連づけられたインターセプタクラスです。Interceptors仕様が定まる以前はEJB3.0仕様で定義されていたインターセプタです。

CDIインターセプタ

InterceptorBinding型のアノテーションとInterceptorアノテーションを宣言したインターセプタクラスです。Interceptors仕様が定まる以前はCDI1.0仕様で定義されていたインターセプタです。

15.3　Interceptorsの概要

JSR318 Interceptors 1.2をサポートします。サポート内容は次のとおりです。

AroundConstructメソッドをサポートします。

javax.interceptor.InvocationContext.getConstructor()メソッドをサポートします

javax.interceptor.Interceptor.Priorityクラスをサポートします。

EJBインターセプタとCDIインターセプタを同時に利用できます。

インターセプタのインスタンスで@InjectによるDIが利用できます。

PostConstruct/PreDestoryメソッドでgetMethod()メソッドを呼び出した場合，ターゲットクラス上で宣言されたPostConstruct/PreDestoryメソッドを取得できます。

15.4　非サポート機能

次に示す機能は非サポートです。

AroundTimeoutメソッドはサポートしません。@AroundTimeoutを指定しても無視します。

InvocationContext.getTimer()メソッドは，AroundTimeoutアノテーションをサポートしないため，必ずnullを返します。

EJB3.1仕様では，Singleton Session BeanのPostConstruct/PreDestroyメソッドにトランザクション属性を付与できると規定されていますが，アプリケーションサーバでは無視します。また，EJB3.2仕様では，Stateful Session BeanのPostConstruct/PreDestroyメソッドにトランザクション属性を付与できると規定されていますが，アプリケーションサーバではEJB3.2をサポートしないため，無視します。

EJBに関連づけられたEJBインターセプタのAroundConstructメソッド呼び出し前のインスタンスと，CDI Beanに関連づけられたEJBインターセプタのインスタンスに，@EJBまたは@ResourceによるDIは実行されません。

また，CDIインターセプタのsetterメソッドに，@EJBまたは@Resourceを指定した場合のDIは実行されません。CDIインターセプタのクラスに@EJBまたは@Resourceを指定する（@EJBsまたは@Resourcesでの複数指定を含む）ことによる参照の宣言はできません。

EJBに関連づけられたインターセプタのAroundConstructメソッド呼び出し前のインスタンスに，@PersistenceUnit，@PersistenceContext, または@WebServiceRefによるDIは実行されません。

CDI Beanに関連づけられたインターセプタのインスタンスに，@WebServiceRefによるDIは実行されません。

ejbserver.jpa.cdiEnabledがfalse（デフォルトでtrue）のとき，CDI Beanに関連づけられたインターセプタのインスタンスに，@PersistenceUnit，@PersistenceContextによるDIは実行されません。

DD（ejb-jar.xml）およびEJB-JAR属性ファイルで設定されたインターセプタで，AroundConstructメソッドの使用は非サポートです。そのほかのインターセプタメソッドの使用方法は，マニュアル「アプリケーションサーバ 機能解説基本・開発編(EJBコンテナ)」の「2.15　インターセプタの使用」を参照してください。

ejbserver.javaee.cdi.webInfLibJarsEnabledがfalseの場合に，WARのWEB-INF/lib以下のJARにCDIインターセプタを配置したとき，そのインターセプタを有効にできません。javax.annotation.Priorityアノテーションによるインターセプタの有効化もできません。

15.5　日立で独自に明確化する仕様

インターセプタクラスの配置場所について標準仕様では明確な規定はありませんが，日立独自仕様として，インターセプタの対象となるクラスと同じアーカイブおよびライブラリJARにインターセプタクラスを配置できます。対象のクラスやインターセプタクラスがCDIの管理対象の場合は，J2EEモジュールの注入関係が適用されます。J2EEモジュールの注入関係については，「9.3.2　CDIの対象となるJ2EEモジュールの注入関係」を参照してください。

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

この章では，アプリケーションの属性管理について説明します。アプリケーションを作成するに当たり，アプリケーションを構成する要素である，EJB-JAR属性，WAR属性，リソースなどを定義する必要があります。

アプリケーションサーバでは，ぞれぞれの属性ファイルにアプリケーションを使用する場合に必要な情報を定義します。また，cosminexus.xmlにアプリケーションサーバ独自の情報を定義してアプリケーションに含めることで，標準DDの定義とアプリケーションサーバ独自の定義を別々に管理できます。アプリケーションを設定するに当たって必要な属性ファイル，およびcosminexus.xmlを使ったアプリケーションの運用などについて説明します。

16.1　この章の構成

アプリケーションの属性管理で説明する内容と参照先を次の表に示します。

表16‒1　アプリケーションの属性管理で説明する内容と参照先

機能

参照先

属性の管理

16.2

cosminexus.xmlを含むアプリケーション

16.3

DDの省略

16.4

16.2　属性の管理

アプリケーションサーバでは，DDとアプリケーションサーバ独自の情報を定義するファイル（cosminexus.xml）を使ってアプリケーションを定義できます。

アプリケーションサーバでのDDのサポート範囲を次の表に示します。

表16‒2　アプリケーションサーバでのDDのサポート範囲

DDの種類

バージョン

サポート有無

application.xml

1.2

△※

1.3

△※

1.4

○

5.0

○

6.0

○

7.0

○

DDなし（5.0）

○

DDなし（6.0）

○

ejb-jar.xml

1.1

△

2.0

○

2.1

○

3.0

○

3.1

○

3.2

〇

DDなし（3.0）

○

DDなし（3.1）

○

web.xml

2.2

△

2.3

○

2.4

○

2.5

○

3.0

○

3.1

○

DDなし（2.5）

○

DDなし（3.0）

○

ra.xml

1.0

○

1.5

○

（凡例）

○：サポートする。

△：サポートするが，インポート時にDDのバージョンを書き換える。

注※

application.xmlのバージョンが1.2または1.3の場合，<context-root>がEARファイル内で一意でないときにも，インポート時にバージョンとして1.4が設定されます。

注意事項

バージョン6.0のapplication.xmlに指定できる要素

バージョン5.0以前から指定できる要素と，Java EE 6で追加された/application/application-nameだけを指定できます。ほかの要素や属性は指定しても無視されます。

バージョン7.0のapplication.xmlに指定できる要素

バージョン6.0のapplication.xmlに指定できる要素と同じ要素だけが指定できます。

アプリケーションの動作はバージョン6.0の場合と同様になります。

バージョン3.0のejb-jar.xmlに指定できる要素

EJB-JARの<display-name>，インターセプタに関する要素，およびアプリケーション例外に関する要素が指定できます。これら以外の要素や属性を指定しても，無視されます。

具体的には，次の要素を指定できます。

/ejb-jar/display-name

/ejb-jar/assembly-descriptor/interceptor-binding，およびその配下の要素

/ejb-jar/assembly-descriptor/application-exception，およびその配下の要素

ejb-name要素に*を指定したinterceptor-binding要素が複数ある場合，いちばん上に記述された内容だけが使用されます。2番目以降の内容は無視されます。

<ejb-name>，<named-method>，およびその配下の要素すべてが一致する<interceptor-binding>が複数存在する場合，いちばん上に記述された内容だけが使用されます。2番目以降の内容は無視されます。

バージョン3.1のejb-jar.xmlに指定できる要素

バージョン3.1のejb-jar.xmlでは，バージョン3.0のejb-jar.xmlで指定できる要素に加え，次の要素が指定できます。

/ejb-jar/module-name

バージョン3.2のejb-jar.xmlに指定できる要素

バージョン3.1のejb-jar.xmlに指定できる要素と同じ要素だけが指定できます。

アプリケーションの動作はバージョン3.1の場合と同様になります。

バージョン3.1のweb.xmlに指定できる要素

バージョン3.0以前から指定できる要素だけを指定できます。ほかの要素や属性は指定しても無視されます。

アプリケーションの動作はバージョン3.0の場合と同様になります。

アプリケーションサーバでは，DDとcosminexus.xmlを別々に管理してJ2EEアプリケーションに含めることができます。cosminexus.xmlをJ2EEアプリケーションに含めることで，アプリケーションをインポートしたあとの属性ファイルの設定が不要になります。そのため，cosminexus.xmlを含むアプリケーションは，インポートしたあとそのまま開始して使用できます。

また，アプリケーションサーバでは，アプリケーションの属性を定義するDD（application.xml，ejb-jar.xmlおよびweb.xml）を省略できます。

16.3以降では，cosminexus.xmlを含むアプリケーションの作成のしかたおよび運用のしかたについて説明します。また，16.4以降では，DDの省略について説明します。

16.3　cosminexus.xmlを含むアプリケーション

この節では，cosminexus.xmlを含むアプリケーションの概要について説明します。

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

表16‒3　この節の構成（cosminexus.xmlを含むアプリケーション）

分類

タイトル

参照先

解説

cosminexus.xmlとは

16.3.1

cosminexus.xmlを含むアプリケーションを使用する利点

16.3.2

cosminexus.xmlを含むアプリケーションの作成

16.3.3

実装

cosminexus.xmlの作成

16.3.4

cosminexus.xmlの作成例

16.3.5

運用

cosminexus.xmlを含むアプリケーションの運用

16.3.6

cosminexus.xmlを含まないアプリケーションから移行する手順

16.3.7

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

16.3.1　cosminexus.xmlとは

cosminexus.xmlは，アプリケーションに関するアプリケーションサーバ独自の定義情報を記載する属性ファイルです。cosminexus.xmlは，アプリケーションごとに作成できます。

cosminexus.xmlをアーカイブ形式のアプリケーションに含めてインポートまたはリデプロイしたり，展開ディレクトリ形式のアプリケーションに含めてアプリケーションを開始したりすることで，アプリケーションサーバ独自の定義情報を設定した状態でアプリケーションを実行できます。

cosminexus.xmlを含むアプリケーションの場合，DDの情報とアプリケーションサーバ独自の情報が別々に管理されます。そのため，アプリケーションサーバ独自の情報を編集したときに，DDの情報を編集する必要がありません。cosminexus.xmlを含むアプリケーションでは，J2EEサーバ上でのコマンドによるアプリケーションの属性の設定が不要です。

cosminexus.xmlを含むアプリケーションの概念を図に示します。

図16‒1　cosminexus.xmlを含むアプリケーションの概念図

cosminexus.xmlとDDの定義を関連づける例を次の図に示します。

図16‒2　cosminexus.xmlとDDの定義を関連づける例

図について説明します。この例では，cosminexus.xmlによって，EJB-JARからのリソースの参照を解決して，リソースのプロパティを設定します。なお，説明の番号は図中の番号と対応しています。

<module-name>で対象とするEJB-JARを特定します。ここでは，adder.jarが対象になります。

adder.jarのDD（ejb-jar.xml）とcosminexus.xmlを関連づけます。ここでは，<ejb-name>で対象となるSession Bean（MyAdder）を特定します。

Session Bean（MyAdder）で参照しているリソース（MyRef）のリソース参照を解決します。<res-ref-name>に指定した名称に対する参照先として，リソースの表示名（DBC）を<linked-to>に指定します。

リソース（DBC）に対するプロパティを設定します。なお，cosminexus.xmlで設定できるのは，J2EEアプリケーションに含まれるリソースアダプタのプロパティです。

このcosminexus.xmlをJ2EEアプリケーションに含めてインポートすることで，J2EEサーバ上でのリソース参照解決やリソースアダプタのプロパティ設定が不要になります。

16.3.2　cosminexus.xmlを含むアプリケーションを使用する利点

cosminexus.xmlを含むアプリケーションを使用する利点を次に示します。

(1)　定義情報を最小限にできる

cosminexus.xmlを含むアプリケーションには，アプリケーションサーバ独自の定義情報のうち，ユーザがカスタマイズしたい情報だけを記述します。省略した場合はデフォルト値が使用されます。

(2)　アプリケーションのインポートから開始までの手順を簡略化できる

アプリケーションをインポートしたあと，アプリケーションの属性設定コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）による操作をしないでアプリケーションを実行できます。

cosminexus.xmlを含むアプリケーションとcosminexus.xmlを含まないアプリケーションでのアプリケーションのインポートから開始までの流れについて図で示します。

図16‒3　cosminexus.xmlを含むアプリケーションとcosminexus.xmlを含まないアプリケーションのインポートから開始までの流れ

(3)　DDを変更した際の属性ファイルの変更が不要

cosminexus.xmlを含まないアプリケーションの場合，標準DDを変更してアプリケーションを入れ替えた場合，サーバ管理コマンドを使ってアプリケーションサーバ独自の定義を設定し直す必要があります。しかし，cosminexus.xmlを含むアプリケーションの場合，アプリケーションサーバ独自の定義はDDと別のファイルで管理されているため，実行環境でサーバ管理コマンドを使って設定し直す必要がありません。

ただし，次に示す場合には，cosminexus.xmlを変更する必要があります。

アプリケーションサーバ独自の定義情報と標準DDおよびアノテーションの定義情報を関連づける情報（J2EEリソースのモジュール名など）を変更した場合

アプリケーションを開始するためにリンク解決が必要な定義情報（リソースなど）を追加した場合

cosminexus.xmlに記述した定義情報と，標準DDおよびアノテーションの定義情報を関連づける定義情報およびリンク解決が必要な定義情報については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

16.3.3　cosminexus.xmlを含むアプリケーションの作成

ここでは，cosminexus.xmlを含むアプリケーションの作成について説明します。cosminexus.xmlを含むアプリケーションを作成するには，あらかじめクラスファイル，DD，およびcosminexus.xmlを作成する必要があります。cosminexus.xmlを含むアプリケーションを作成する流れを図で示します。

図16‒4　cosminexus.xmlを含むアプリケーションを作成する流れ

なお，WARファイルまたはWARディレクトリを指定してインポートしたWARアプリケーションの場合，図16-4は次のようになります。WARアプリケーションの詳細については，「18.9　WARアプリケーション」を参照してください。

展開ディレクトリ形式の場合

アプリケーションはWARディレクトリ内に配置します。

アーカイブ形式の場合

アプリケーションはWARのアーカイブを作成します。

クラスファイルの作成，DDの作成，およびcosminexus.xmlを含むアプリケーションの作成についてはマニュアル「アプリケーションサーバ アプリケーション開発ガイド」を参照してください。

16.3.4以降では，cosminexus.xmlの作成について説明します。

16.3.4　cosminexus.xmlの作成

cosminexus.xmlを含むアプリケーションを作成するには，あらかじめ作成したcosminexus.xmlをアプリケーションに含める必要があります。cosminexus.xmlを作成する方法を次に示します。

図16‒5　cosminexus.xmlを作成する方法

cosminexus.xmlを作成する方法には，DeveloperのWTPを使って作成する方法とテキストエディタを使って作成する方法があります。それぞれの方法を，図中の（1）〜（3）に沿って説明します。

(1)　Developerを使って作成する方法

アプリケーションサーバでは，DeveloperのWTPを使ってcosminexus.xmlを作成できます。DeveloperのWTPを使ってcosminexus.xmlを作成する方法については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「5.3.1　cosminexus.xmlの作成」を参照してください。

(2)　テンプレートを使って作成する方法

テキストエディタを使ってcosminexus.xmlを作成する場合，テンプレートファイルを使用すると容易に作成できます。

テンプレートの格納場所を次に示します。

テンプレートの格納場所

Windowsの場合

<Application Serverのインストール先>¥CC¥admin¥templates¥cosminexus.xml

UNIXの場合

/opt/Cosminexus/CC/admin/templates/cosminexus.xml

テンプレートをコピーしてアーカイブファイルまたは展開先ディレクトリ内に格納します。

cosminexus.xmlの格納先を次に示します。

EARファイルをインポートする場合

EAR内の格納先（アーカイブ形式のアプリケーションの場合）

<EARのルート>/META-INF/cosminexus.xml

アプリケーションディレクトリ内の格納先（展開ディレクトリ形式のアプリケーション場合）

展開ディレクトリ形式のアプリケーションでのcosminexus.xmlの格納先については，「18.4.2　アプリケーションディレクトリの構成」を参照してください。

WARファイルをインポートする場合

cosminexus.xmlの格納先は，cjimportwarコマンドで指定します。cjimportwarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjimportwar（WARアプリケーションのインポート）」を参照してください。

注意事項

テンプレートには，DOCTYPE要素に指定するスキーマ定義ファイルの格納先として，アプリケーションサーバのインストール先の書き換えを前提としたURI「file:///<アプリケーションサーバのインストール先>/CC/admin/dtds/cosminexus_8_0.dtd」が記載されています。J2EEサーバはこのURIを参照しないため，書き換える必要はありません。ただし，XMLエディタなどで使用する場合は，使用する環境に合わせてこのURIを書き換えてください。

(3)　テンプレートを使わないで作成する方法

テンプレートを使わないでcosminexus.xmlを作成する場合は，マニュアルを基に，テキストエディタを使ってアプリケーションサーバ独自の情報を定義します。テキストエディタを使ってcosminexus.xmlの作成する場合に必要なDOCTYPE要素，およびcosminexus.xmlの定義内容については，マニュアル「アプリケーションサーバリファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

16.3.5　cosminexus.xmlの作成例

テキストエディタを使ったcosminexus.xmlの作成例を示します。ここでは，次のDDの定義内容を基にcosminexus.xmlを作成します。

標準DDの定義内容

Webアプリケーションのモジュール名：war/webapp.war

Servlet名：MyServ

Servlet（MyServ）から参照するリソース名：DB_Connector_for_Oracle

cosminexus.xmlの作成例を図で説明します。

図16‒6　cosminexus.xmlの作成例

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

テンプレートファイルを基に，cosminexus.xmlを作成する。

テンプレートファイルをコピーしてEARまたはアプリケーションディレクトリ内に格納します。コピーしたテンプレートファイルは，テキストエディタを使って編集します。

EJB／Servletおよびリンク解決を特定するキー（モジュール名やリソース名）を設定する。

DDで定義した情報と関連づけるキーを設定します。ここでは，Webアプリケーションのモジュール名，および参照しているリソース名を設定しています。

リンク解決したいリソース名を設定する。

2.で設定したキーのリンク解決をするリソースを設定します。

なお，cosminexus.xmlの定義内容の詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.1　アプリケーション属性ファイル（cosminexus.xml）の指定内容」を参照してください。

16.3.6　cosminexus.xmlを含むアプリケーションの運用

ここでは，cosminexus.xmlを含むアプリケーションの運用について説明します。

(1)　cosminexus.xmlを含むアプリケーションを新規作成する流れ

cosminexus.xmlを含むアプリケーションを新規で作成する流れについて説明します。

cosminexus.xmlを含むアプリケーションは，開発環境で作成します。作成したアプリケーションを実行環境へインポートし，アプリケーションを開始します。

開発環境でのcosminexus.xmlを含むアプリケーションの作成から，実行環境でのアプリケーションの開始までの流れを図で説明します。

図16‒7　cosminexus.xmlを含むアプリケーションの作成から実行環境でのアプリケーションの開始までの流れ

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

cosminexus.xmlを含めたアプリケーションの作成

クラスファイル，標準DDおよびcosminexus.xmlを作成し，アプリケーションの形式に合わせてアーカイブしたりアプリケーションディレクトリに配置したりします。クラスファイル，DD，およびcosminexus.xmlを含むアプリケーションの作成については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」を参照してください。また，テキストエディタを使ったcosminexus.xmlの作成については，「16.3.4　cosminexus.xmlの作成」を参照してください。

アプリケーションのインポート

開発環境で作成したアプリケーションを実行環境へインポートします。アプリケーションのインポートについては，「(2)　アプリケーションのインポート」を参照してください。

アプリケーションの開始

インポートしたアプリケーションを開始します。アプリケーションの開始方法については，「(3)　アプリケーションの開始」を参照してください。

(2)　アプリケーションのインポート

cosminexus.xmlを含むアプリケーションのインポートについて説明します。

cosminexus.xmlを含むアプリケーションの場合，インポートするタイミングでcosminexus.xmlの情報が読み込まれます。J2EEアプリケーションをインポートするには，cjimportappコマンドを実行します。cjimportappコマンドの詳細については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjimportapp（J2EEアプリケーションのインポート）」を参照してください。J2EEアプリケーションのインポートに関する注意事項については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「8.1　J2EEアプリケーションのインポート」を参照してください。

WARアプリケーションをインポートするにはcjimportwarコマンドを実行します。cjimportwarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjimportwar（WARアプリケーションのインポート）」を参照してください。WARアプリケーションについては，「18.9　WARアプリケーション」を参照してください。

(3)　アプリケーションの開始

cosminexus.xmlを含むアプリケーションの開始について説明します。

cosminexus.xmlを含むアプリケーションを開始する手順は，cosminexus.xmlを含まないアプリケーションを開始する手順と変わりません。アプリケーションを開始するにはcjstartappコマンドを実行します。cjstartappコマンドの詳細については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjstartapp（J2EEアプリケーションの開始）」を参照してください。また，J2EEアプリケーションの開始に関する注意事項については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.1　J2EEアプリケーションの開始」を参照してください。

cosminexus.xmlを含むアプリケーションを実行環境で開始したあとで一度アプリケーションを停止し，再度，アプリケーションを開始する場合のアプリケーションの動作について説明します。

ここでは，アプリケーションを再開始した際のアプリケーションの形式が，アーカイブ形式の場合，展開ディレクトリ形式の場合，cosminexus.xmlを含まないアプリケーションの場合に分けて説明します。

アーカイブ形式のアプリケーションの場合

アーカイブ形式のアプリケーションにcosminexus.xmlが含まれている場合，アプリケーションに含まれているcosminexus.xmlの情報が読み込まれます。アーカイブ形式のアプリケーションには，停止する前のアプリケーションに対するサーバ管理コマンドを使った定義情報の変更は反映されません。

展開ディレクトリ形式の場合

展開ディレクトリ形式のアプリケーションにcosminexus.xmlが含まれている場合，アプリケーションを開始するときに，実行環境で変更したアプリケーションサーバ独自のアプリケーションに関する情報を上書きします。つまり，展開ディレクトリ形式のアプリケーションの場合には，サーバ管理コマンドを使った定義情報の変更がファイルに反映されます。

アプリケーションにcosminexus.xmlが含まれていない場合

アプリケーションにcosminexus.xmlが含まれていない場合は，前回アプリケーションを開始した際のアプリケーションサーバ独自の定義内容でアプリケーションを開始します。

(4)　アプリケーションの開始後に定義情報を変更する流れ

開発環境からインポートしたアプリケーションを実行環境で開始したあとで，アプリケーションの定義情報を変更したい場合の手順について説明します。

cosminexus.xmlを含むアプリケーションの定義を変更する場合，アプリケーションの形式がアーカイブ形式か，または展開ディレクトリ形式かによって手順が異なります。

アプリケーションの形式ごとに，定義内容の変更手順について説明します。

参考

cosminexus.xmlを含まないアプリケーションと同じように，サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使ったアプリケーションの定義内容の変更もできます。

注意事項

cosminexus.xmlを含むアプリケーションの定義情報を変更する場合の注意事項を示します。

アプリケーションサーバ独自の定義情報をすべてデフォルト値に戻したい場合は，cosminexus.xmlのファイルから，<cosminexus-app>要素以外すべての要素を削除してください。

サーバ管理コマンドを使ってアプリケーションの定義を変更した場合の注意事項を，アプリケーションの形式ごとに説明します。

アーカイブ形式の場合

リデプロイ機能による定義情報の変更では，アプリケーションサーバのアプリケーションの実行時情報をいったんデフォルトに戻したあとで，入れ替え後のcosminexus.xmlに定義されている情報を読み込みます。そのため，サーバ管理コマンドで設定した定義情報はすべて失われます。

注意事項

WARアプリケーションの場合はリデプロイ機能で定義情報の変更はできません。サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使用してください。

展開ディレクトリ形式の場合

サーバ管理コマンドを使用して変更したアプリケーションの属性の内容は，そのままアプリケーションディレクトリ内のcosminexus.xmlに反映されます。

なお，リロード機能では，cosminexus.xmlの定義情報は読み込まれません。変更した定義情報を反映したい場合は，アプリケーションの再開始が必要です。アプリケーション統合属性ファイルとサーバ管理コマンドを使用して定義情報を変更する場合については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「9.　J2EEアプリケーションのプロパティ設定」を参照してください。

(a)　アーカイブ形式の場合

cosminexus.xmlを含むアプリケーションがアーカイブ形式の場合の変更手順について説明します。なお，cosminexus.xmlを含むアプリケーションの定義情報は，ここで示した手順だけでなく，サーバ管理コマンドと属性ファイルを使う手順でも実行できます。

cosminexus.xmlを含むアプリケーションを実行環境で開始したあとで，定義内容を変更したい場合は，開発環境でアプリケーションの定義内容を変更します。開発環境で定義内容を変更してアーカイブし直したあと，再度アプリケーションを実行環境へインポートし，アプリケーションを入れ替えます。

また，稼働中のJ2EEアプリケーションを実行時情報付きZIP形式にしてエクスポートできます。実行時情報付きZIP形式のアプリケーションの操作手順は，cosminexus.xmlを含むアプリケーションとcosminexus.xmlを含まないアプリケーションとで差異はありません。アプリケーションのエクスポートについては「(6)　アプリケーションのエクスポート」を参照してください。

cosminexus.xmlを含むアプリケーションの定義内容の変更手順について図で説明します。

図16‒8　cosminexus.xmlを含むアプリケーションの定義内容の変更手順（アーカイブ形式の場合）

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

cosminexus.xmlの編集

cosminexus.xmlを含むアプリケーションを実行環境へインポートしたあとで，定義情報を変更する場合，開発環境でcosminexus.xmlを編集します。cosminexus.xmlの編集については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「5.3.2　cosminexus.xmlエディタの操作方法」を参照してください。

EARの再アーカイブ

編集したcosminexus.xmlをアプリケーションに含めてアーカイブします。

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

開発環境で作成し直したアプリケーションを，実行環境で使用しているアプリケーションと入れ替えます。アプリケーションの入れ替えについては，「(5)　アプリケーションの入れ替え」を参照してください。

アプリケーションの開始

アプリケーションを開始します。アプリケーションの開始方法については，「(3)　アプリケーションの開始」を参照してください。

ポイント

サーバ管理コマンドを使ってcosminexus.xmlの定義情報を変更した場合，アプリケーションを入れ替えたときに入れ替え後のJ2EEアプリケーションに含まれるcosminexus.xmlの定義情報が上書きされます。cosminexus.xmlの定義情報を変更する場合は，開発環境でcosminexus.xmlを編集し，アプリケーションをリデプロイまたは再度インポートし直してください。

サーバ管理コマンドを使用して定義情報を変更する方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.　J2EEアプリケーションのプロパティ設定」を参照してください。

(b)　展開ディレクトリ形式の場合

cosminexus.xmlを含むアプリケーションが展開ディレクトリ形式の場合の変更手順について説明します。

cosminexus.xmlを含むアプリケーションの定義内容の変更手順について図で説明します。

図16‒9　cosminexus.xmlを含むアプリケーションの定義内容の変更手順（展開ディレクトリ形式）

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

cosminexus.xmlの編集

cosminexus.xmlを含むアプリケーションを実行環境へインポートしたあとで，定義情報を変更する場合，開発環境でcosminexus.xmlを編集します。cosminexus.xmlの編集については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「5.3.2　cosminexus.xmlエディタの操作方法」を参照してください。

アプリケーションディレクトリへの配置

編集したcosminexus.xmlをアプリケーションディレクトリへ配置します。アプリケーションディレクトリへ配置については，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「1.4.1　展開ディレクトリ形式のJ2EEアプリケーション」を参照してください。

アプリケーションの停止

実行環境で使っているアプリケーションを停止します。アプリケーションの停止については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.2.2　J2EEアプリケーションの停止」を参照してください。

アプリケーションの開始

インポートしたアプリケーションを開始します。アプリケーションの開始については「(3)　アプリケーションの開始」を参照してください。

(5)　アプリケーションの入れ替え

cosminexus.xmlを含むアプリケーションの入れ替えについて説明します。

アーカイブ形式のアプリケーションを入れ替えるには，リデプロイ機能を使用します。リデプロイ機能を使ってアプリケーションを入れ替える場合，入れ替え後のアプリケーションに含まれるcosminexus.xmlの情報が再度読み込まれます。開発環境でcosminexus.xmlを変更し，EARファイルにアーカイブし直してリデプロイを実行することで，アプリケーションサーバ独自の定義情報が変更されます。

注意事項

WARアプリケーションの場合，アプリケーションの入れ替えによる定義情報の変更はできません。サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使用してください。

なお，入れ替えるアプリケーションにcosminexus.xmlが含まれていない場合，入れ替え前のcosminexus.xmlの定義情報を引き継ぎます。※

リデプロイ機能を使用するには，cjreplaceappコマンドを使用します。cjreplaceappコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreplaceapp（アプリケーションの入れ替え）」を参照してください。また，リデプロイ機能に関する注意事項については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.5.1　アーカイブ形式のアプリケーション」を参照してください。

注※　入れ替えるアプリケーションのcosminexus.xmlの有無にかかわらず，DDの入れ替えはできません。

注意事項

アーカイブ形式のアプリケーションを入れ替える場合の注意事項を示します。

cosminexus.xmlを含むアプリケーションに対して，サーバ管理コマンドでアプリケーションサーバ独自の定義情報を変更したあとでリデプロイ機能を使用すると，サーバ管理コマンドで変更したアプリケーションサーバ独自の情報は失われます。

アプリケーションサーバ独自の情報をすべてデフォルト値に戻したい場合は，cosminexus.xmlから<cosminexus-app>以外の要素をすべて削除してから，cosminexus.xmlを含むアプリケーションを入れ替えてください。

(6)　アプリケーションのエクスポート

cosminexus.xmlを含むアプリケーションのエクスポートについて説明します。

アプリケーションをエクスポートするには，cjexportappコマンドを使用します。cjexportappコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjexportapp（J2EEアプリケーションのエクスポート）」を参照してください。また，アプリケーションのエクスポートに関する注意事項については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「8.2　J2EEアプリケーションのエクスポート」を参照してください。

注意事項

WARアプリケーションの場合，アプリケーションのエクスポートはできません。

cosminexus.xmlを含むアプリケーションをアーカイブ形式でエクスポートした場合，エクスポートされたEARファイルにはcosminexus.xmlが含まれます。エクスポートの対象となるアプリケーションおよびエクスポートされたEARファイルの組み合わせを次に示します。

表16‒4　エクスポートの対象となるアプリケーションおよびエクスポートされたEARファイルの組み合わせ

エクスポートの対象となるアプリケーションの形式

エクスポートされたEARファイルの形式

cjexportappコマンドに-normalオプションを指定した場合

cjexportappコマンドに-rawオプションを指定した場合

cosminexus.xmlを含むアプリケーション

cosminexus.xmlを含む実行時情報付きZIP形式

cosminexus.xmlを含むEAR

cosminexus.xmlを含まないアプリケーション

cosminexus.xmlを含まない実行時情報付きZIP形式

cosminexus.xmlを含まないEAR

注意事項

エクスポートしたアプリケーションに含まれるcosminexus.xmlに関する注意事項を示します。

コメントは保持されません。

文字エンコードはUTF-8になります。

DOCTYPEに記載されたDTDのバージョンが古いバージョンのcosminexus.xmlを含むJ2EEアプリケーションをエクスポートした場合，DTDのバージョンはアプリケーションサーバでサポートされる最新のバージョンに変更されます。

エクスポートしたEAR/ZIPに含まれるのはJ2EEサーバが最後に読み込みに成功したcosminexus.xmlです。J2EEサーバがcosminexus.xmlを読み込んだあとにアプリケーションディレクトリ内のcosminexus.xmlを変更しても，変更後の定義情報はエクスポートしたEAR/ZIPに含まれません。例えば，展開ディレクトリ形式のアプリケーションをインポートしたあと，アプリケーションディレクトリ内のcosminexus.xmlを書き換え，アプリケーションを開始しないでアプリケーションをEAR形式でエクスポートした場合，EARにはインポートした時と同様のcosminexus.xmlが含まれます。インポート後に更新したアプリケーションディレクトリ内のcosminexus.xmlは含まれません。

(7)　アプリケーションからのJ2EEリソースの削除

アプリケーションからJ2EEリソースを削除する場合，cosminexus.xmlに削除するJ2EEリソースの情報が含まれていても，その情報は削除されません。

アプリケーション内にない要素をカスタマイズする定義情報がcosminexus.xmlにある場合，cosminexus.xmlを読み込むサーバ管理コマンドの実行時に警告メッセージが出力されます。

16.3.7　cosminexus.xmlを含まないアプリケーションから移行する手順

ここでは，cosminexus.xmlを含まないアプリケーションからcosminexus.xmlを含むアプリケーションに移行する手順について説明します。

次の手順でアプリケーションを移行してください。

移行前のアプリケーションからアプリケーション統合属性ファイルを取得します。

取得にはサーバ管理コマンド（cjgetappprop）を使用します。

cosminexus.xmlを作成します。

cosminexus.xmlとアプリケーション統合属性ファイルの対応については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.1　アプリケーション統合属性の詳細」を参照してください。

EAR（アーカイブ形式の場合）またはアプリケーションディレクトリ（展開ディレクトリ形式の場合）に手順2.で作成したcosminexus.xmlを含めます。

アプリケーションを入れ替えます。

正しくアプリケーションについての定義情報が移行できているかを検証します。

入れ替え後のアプリケーションからアプリケーション統合属性ファイルを取得して，手順1.で取得したファイルと比較することで検証できます。

16.4　DDの省略

アプリケーションサーバでは，application.xml，ejb-jar.xmlおよびweb.xmlを省略できます。ただし，モジュールやDDのバージョンの組み合わせによっては省略できないものもあります。

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

表16‒5　この節の構成（cosminexus.xmlを含むアプリケーション）

分類

タイトル

参照先

解説

アプリケーションサーバで実行できるアプリケーションの構成

16.4.1

application.xmlの有無による機能の違い

16.4.2

application.xmlがある場合のモジュールの決定規則

16.4.3

application.xmlがない場合のモジュールの決定規則

16.4.4

web.xmlを省略したWebアプリケーションに対する操作

16.4.5

DDを省略した場合に設定される表示名

16.4.6

application.xmlを省略した場合にapplication.xmlが作成される操作

16.4.7

注意事項

application.xmlを省略した場合にJ2EEアプリケーションにリソースを追加するときの注意

16.4.8

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

16.4.1　アプリケーションサーバで実行できるアプリケーションの構成

アプリケーションサーバでは，次のDDを省略できます。

Java EE 5以降のapplication.xml

EJB 3.0以降のejb-jar.xml

Servlet 2.5以降のweb.xml

application.xmlのDDのバージョンとDDの省略，および各モジュールのDD（ejb-jar.xml，web.xml，ra.xml）のバージョンとDDの省略の組み合わせを表で示します。

表16‒6　DDの組み合わせ

DDの種別

application.xml

1.4以前※1

Java EE 5

Java EE 6

Java EE 7

Java EE 8

DDなし

ejb-jar.xml

2.0以前※1

○

○

○

○

○

○

2.1

○

○

○

○

○

○

3.0

×

○

○

○

○

○

3.1

×

×

○

○

○

○

3.2

×

×

×

○

○

○

DDなし（3.0以降）

○

（3.0）

○

（3.0）

○

（3.1）

○

（3.2）

○

（3.2）

○

（3.2）※2

web.xml

2.3以前※1

○

○

○

○

○

○

2.4

○

○

○

○

○

○

2.5

×

○

○

○

○

○

3.0

×

×

○

○

○

○

3.1

×

×

×

○

○

○

4.0

×

×

×

×

○

○

DDなし（2.5以降）

×

○

（2.5）

○

（3.0）

○

（3.1）

○

（4.0）

○

（4.0）※2

ra.xml

1.0

○

○

○

○

○

○

1.5

○

○

○

○

○

○

（凡例）○：サポートする　×：サポートしない

注※1　バージョンアップ，またはバージョンアップしたあとのサーバ管理コマンド実行時に，次に示すバージョンに変更になります。

注※2　08-70以前のアプリケーションサーバでインポート済みのJ2EEアプリケーションは，09-00以降にアップグレードしても，ejb-jar.xmlのバージョンは3.0，web.xmlのバージョンは2.5として動作します。

表16‒7　DDのバージョンアップ

DD

バージョンアップ前のバージョン

バージョンアップ後のバージョン

application.xml

1.2

1.4

1.3

ejb-jar.xml

1.1

2.0

web.xml

2.2

2.3

参考

次のコマンドを実行したとき，J2EEアプリケーションがサポートしていない構成の場合はメッセージKDJE42361-Eを出力し，エラーとなります。

cjimportapp

cjreplaceapp

cjaddapp

16.4.2　application.xmlの有無による機能の違い

application.xmlを省略した場合，コマンドを実行したときのアセンブル機能およびデプロイ機能に違いが出ます。J2EEアプリケーションにapplication.xmlがある場合，およびapplication.xmlがない場合に分けて，サーバ管理コマンドの機能の違いを説明します。

表16‒8　application.xmlの有無による機能の違い一覧

J2EEアプリケーションを操作するコマンド

application.xmlあり

application.xmlなし

cjimportapp

モジュールの決定

application.xmlによってモジュールを決定します。

J2EEアプリケーションの表示名

application.xmlの<display-name>タグによって決定します。<display-name>タグがなければEARファイル名によって決定します。

EJB-JARディレクトリ，WARディレクトリの決定

展開ディレクトリ形式（-aオプション指定）の場合，application.xmlの<module>タグに記述されたパス名から拡張子を除いた名称がとなります。

モジュールの決定

ファイルの位置，拡張子，およびファイルの内容によってモジュールを決定します。

J2EEアプリケーションの表示名

EARファイル名によって決定します。

EJB-JARディレクトリ，WARディレクトリの決定

展開ディレクトリ形式の場合，EJB-JARディレクトリ名の最後は「_jar」，WARディレクトリ名の最後は「_war」となります。

cjexportapp

application.xmlありのJ2EEアプリケーションをエクスポートします。

application.xmlなしのJ2EEアプリケーションをエクスポートします。

cjaddapp

J2EEアプリケーションへリソースを追加します。application.xmlにモジュールの情報を追加します。追加できるリソースファイルの拡張子に制限はありません。

J2EEアプリケーションへリソースを追加します。その際，リソースファイルの拡張子がapplication.xml省略時のJava EE仕様に準拠していない場合はエラーとなります。

cjsetappprop

属性ファイルに指定した内容を設定します。

属性ファイルに指定した内容を設定します。設定する内容によってapplication.xmlを作成します。

cjrenameapp

J2EEアプリケーション名を変更します。

J2EEアプリケーション名を変更します。application.xmlを作成します。

参考

次に示すサーバ管理コマンドの機能には，application.xmlがある場合とapplication.xmlがない場合とで差異はありません。

cjdeleteapp

cjstartapp

cjstopapp

cjchmodapp

cjgencmpsl

cjgetappprop

cjgetstubsjar

cjimportlibjar

cjdeletelibjar

cjlistlibjar

cjlistapp

cjreloadapp

cjreplaceapp

16.4.3　application.xmlがある場合のモジュールの決定規則

アプリケーション内にapplication.xmlがある場合，ライブラリJAR以外はJava EE仕様に従ってapplication.xmlの内容からモジュールを決定します。ただし，application.xmlのバージョンが1.4以前の場合，ライブラリJARはアプリケーションサーバ独自の仕様に従って決定します。ライブラリJARは，application.xmlのバージョンがJava EE 5以降の場合と，J2EE1.4以前の場合とでモジュールの決定規則が異なります。ライブラリJARのモジュールの決定規則について，application.xmlのバージョンがJava EE 5以降の場合と，J2EE1.4以前の場合とに分けて説明します。

(1)　application.xmlのバージョンがJava EE 5以降の場合

application.xmlのバージョンがJava EE 5以降の場合，次に示すファイルを除いて，ライブラリディレクトリ直下と，J2EEアプリケーションのルート直下にあるJARファイル（拡張子が小文字の.jarのファイル）がライブラリJARと見なされます。

除外されるファイル

META-INFディレクトリ直下のapplication.xmlの<module>タグに書かれているファイル

J2EEアプリケーションのルート直下のhitachi-runtime.jar

application.xmlのバージョンがJava EE 5以降の場合のモジュールの決定規則を次に示します。

表16‒9　application.xmlのバージョンがJava EE 5以降の場合のモジュールの決定規則

<library-directory>タグの値

ライブラリJAR※

存在するディレクトリ

/

<ファイル名>.jar

/以外

<ファイル名>.jar

<library-directory>タグの値/<ファイル名>.jar

存在しないディレクトリ

<ファイル名>.jar

存在するファイル

インポート時にKDJE42360-Eを出力してエラーにする。

空文字

<ファイル名>.jar

タグ自体が存在しない

<ファイル名>.jar

/lib（小文字）/<ファイル名>.jar

注※

「除外されるファイル」で示したファイルは除きます。

(2)　application.xmlのバージョンがJ2EE1.2，1.3，1.4の場合

次に示すファイル以外のJARファイル（拡張子が小文字の.jarのファイル）がライブラリJARと見なされます。

META-INFディレクトリ直下のapplication.xmlの<module>タグに書かれているファイル

J2EEアプリケーションのルート直下のhitachi-runtime.jar

(3)　ライブラリJARとして扱われるJARファイルの例

META-INFディレクトリ直下のapplication.xmlの<module>タグに<ライブラリディレクトリ>/<ファイル名>.jarと書いた場合，そのJARファイルはライブラリJARと認識されません。また，hitachi-runtime.jarもライブラリJARとして認識されません。ライブラリJARとして扱われるJARファイルの例を次に示します。

表16‒10　ライブラリJARとして扱われるJARファイルの例

EARファイル内のパス

application.xmlのバージョン

J2EE1.4

Java EE 5以降

<library-directory>の値

lib

library

タグなし

lib1.jar

ライブラリJAR

ライブラリJAR

ライブラリJAR

ライブラリJAR

lib/lib2.jar

ライブラリJAR

ライブラリJAR

−

−

library/lib3.jar

ライブラリJAR

−

ライブラリJAR

−

（凡例）−：該当なし

16.4.4　application.xmlがない場合のモジュールの決定規則

J2EEアプリケーションにapplication.xmlが存在しない場合のモジュールの決定規則について説明します。J2EEアプリケーションにapplication.xmlが存在しない場合は，アプリケーションの形式ごとにライブラリJARの決定規則が異なります。アプリケーションの形式ごとにモジュールの決定規則を説明します。

(1)　アーカイブ形式または-dオプションを指定してインポートした展開ディレクトリ形式のアプリケーションの場合

application.xmlが含まれていないアプリケーションを，アーカイブ形式でインポートした場合，または展開ディレクトリ形式（cjimportappコマンドに-dオプションを指定）でインポートした場合，Java EE仕様に従ってモジュールが決定されます。モジュールが決定される順番を示します。

ファイルの拡張子が.warのファイルすべてを，Webモジュールと見なします。

ファイルの拡張子が.rarのファイルすべてをリソースアダプタと見なします。

libディレクトリをライブラリディレクトリと見なします。

libディレクトリ以下を除き，ファイルの拡張子が.jarのファイルについては次のように決定します。

META-INF/ejb-jar.xmlファイルを含む，またはEJBコンポーネントアノテーションを含むJARファイルはEJBモジュールと見なします。

「hitachi-runtime.jar」を除いたJ2EEアプリケーションのルート直下のJARファイルをライブラリJARと見なします。

これらのルールに該当しないすべてのファイルは無視されます。

ポイント

Webモジュールのコンテキストルート

Webモジュールのコンテキストルートは，アプリケーションパッケージのルートからWARファイルへの相対パス名から，拡張子である.warを除いたものになります。

このため，application.xmlを省略する場合，WARファイルへのパスのディレクトリ名，およびWARファイル名は，URI（RFC3986）で使用できる文字で指定してください。

Webモジュールの構成とコンテキストルートの例を次の図に示します。

図16‒10　Webモジュールの構成とコンテキストルートの例（アーカイブ形式または-dオプションを指定してインポートした展開ディレクトリ形式のアプリケーションの場合）

なお，WARファイルへのパス名によっては，複数のWARファイルに対するコンテキストルートが重複することがあります。例えば，「sub/.war」という名称のWARファイルと，「sub.war」という名称のWARファイルがある場合，どちらのコンテキストルートも「sub」になります。

(2)　-aオプションを指定してインポートした展開ディレクトリ形式のアプリケーションの場合

application.xmlが含まれていないアプリケーションを，展開ディレクトリ形式（cjimportappコマンドに-aオプションを指定）でインポートした場合，次の規則に従って順番にWARディレクトリ，EJB-JARディレクトリ，モジュールが決定されます。次に，モジュールが決定する順番を記します。

アプリケーションディレクトリのルート以下の階層に「_war」で終わるディレクトリがある場合，そのディレクトリをWARディレクトリと見なします。ただし，次の条件に当てはまる場合は，WARディレクトリとは見なしません。

WARディレクトリ以下のディレクトリ

EJB-JARディレクトリ以下のディレクトリ

libディレクトリ

アプリケーションディレクトリのルート以下の階層に「_jar」で終わるディレクトリがある場合，そのディレクトリをEJB-JARディレクトリと見なします。ただし，次の条件に当てはまる場合は，EJB-JARディレクトリとは見なしません。

WARディレクトリ以下のディレクトリ

EJB-JARディレクトリ以下のディレクトリ

libディレクトリおよびlibディレクトリ以下のディレクトリ

WARディレクトリ以下，およびEJB-JARディレクトリ以下のファイルを除いて，ファイル名の拡張子が.rarのファイルすべてをリソースアダプタと見なします。

libディレクトリをライブラリディレクトリと見なします。

WARディレクトリ以下，EJB-JARディレクトリ以下，およびlibディレクトリ以下のファイルを除き，ファイル名の拡張子が.jarのファイルについては「hitachi-runtime.jar」を除いたJ2EEアプリケーションのルート直下のJARファイルをライブラリJARと見なします。

これらのルールに該当しないすべてのファイルは無視されます。

ポイント

Webモジュールのコンテキストルート

Webモジュールのコンテキストルートは，アプリケーションディレクトリからWARディレクトリへの相対パス名の後ろから，「_war」を除いたものになります。

このため，application.xmlを省略する場合，WARディレクトリへのパスのディレクトリ名，およびWARディレクトリ名は，URI（RFC3986）で使用できる文字で指定してください。

Webモジュールの構成とコンテキストルートの例を次の図に示します。

図16‒11　Webモジュールの構成とコンテキストルートの例（-aオプションを指定してインポートした展開ディレクトリ形式のアプリケーションの場合）

なお，WARディレクトリへのパス名によっては，複数のWARディレクトリに対するコンテキストルートが重複することがあります。例えば，「sub/_war」という名称のWARディレクトリと，「sub_war」という名称のWARディレクトリがある場合，どちらのコンテキストルートも「sub」になります。

(3)　EARファイル内またはアプリケーションディレクトリのライブラリディレクトリの扱われ方

ここでは，application.xmlがない場合のEARファイル内またはアプリケーションディレクトリのライブラリディレクトリの扱われ方について示します。ライブラリディレクトリの扱われ方は，EARファイル内またはアプリケーションディレクトリに，libというディレクトリまたはファイルがある場合と，どちらもない場合で異なります。

表16‒11　application.xmlがない場合のEARファイル内またはアプリケーションディレクトリのライブラリディレクトリの扱われ方

EARファイル内のlibまたはアプリケーションディレクトリ内のlib

扱われ方

ディレクトリがある場合

libがライブラリディレクトリとして扱われます。

ファイルがある場合

インポート時にKDJE42360-Eが出力され，エラーになります。

ディレクトリまたはファイルがない場合

ライブラリディレクトリはないものとして動作します。

（ほかの個所にあるlibは，ライブラリディレクトリとして扱われません）。

16.4.5　web.xmlを省略したWebアプリケーションに対する操作

web.xmlを省略した場合，サーバ管理コマンドでのWebアプリケーションに対する操作に制限があります。web.xml省略時のWebアプリケーションに対する操作の可否について，次の表に示します。

表16‒12　web.xml省略時のWebアプリケーションに対する操作の可否

操作

操作の可否

コマンド

引数

操作内容

cjaddapp

-type filter

フィルタの追加

×※1

-type war

WARファイルの追加

○

cjcopyres

-type war

WARファイルのコピー

○

cjdeleteapp

-type filter

フィルタの削除

×※2

-type war

WARファイルの削除

○

なし

アプリケーションの削除

○

cjdeleteres

-type war

WARファイルの削除

○

cjexportapp

-raw

アプリケーションのエクスポート（実行時情報を含まない）

○※3

-normal

アプリケーションのエクスポート（実行時情報を含む）

○※3

cjgetappprop

-type war

WARファイルの属性の取得

○

-type all

アプリケーションの属性の取得

○

cjgetresprop

-type war

WARファイルの属性の取得

○

cjimportapp

J2EEアプリケーションのインポート

○※4

cjimportres

-type war

WARファイルのインポート

○※4

cjlistapp

-type war

WARファイルの一覧表示

○

cjlistres

-type war

WARファイルの一覧表示

○

cjreloadapp

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

○

cjreplaceapp

-replaceDD

アプリケーションの入れ替え（DDの定義を引き継がない）

○

なし

アプリケーションの入れ替え（DDの定義を引き継ぐ）

○

cjsetappprop

-type war

属性設定

標準DDに関する情報

×※5

実行時情報

○

-type all

属性設定

標準DDに関する情報

×※5

実行時情報

○

cjsetresprop

-type war

属性設定

標準DDに関する情報

×※5

実行時情報

○

cjstartapp

アプリケーションの開始

○

cjstopapp

アプリケーションの停止

○

（凡例）　○：操作できる　×：操作できない

注※1　コマンド実行時にエラーが発生し，メッセージKDJE37606-Eが出力されます。

注※2　web.xmlを省略したアプリケーションにはフィルタを追加できないため，フィルタの削除もできません。

注※3　エクスポートしたファイルにweb.xmlを含みません。

注※4　インポートしたWARは，JSPおよび静的コンテンツだけが使用できます。

注※5　読み取り専用の属性として扱われるため，設定が無視されます。

16.4.6　DDを省略した場合に設定される表示名

アプリケーションサーバでは，DDを省略した場合インポートしたタイミングで表示名が補完されます。また，J2EEサーバが表示名の妥当性確認を実施します。インポート時の表示名の補完規則，および表示名の妥当性の確認について説明します。

(1)　インポート時の表示名の補完規則

EJB-JAR，WAR，RAR，またはEARの各J2EEコンポーネントのDDの<display-name>タグが設定されていない場合，J2EEサーバによって表示名が設定されます。表示名は，J2EEコンポーネントのファイル名，およびディレクトリ名を基に決められます。DDを省略した場合も同様にJ2EEサーバによって設定されます。その場合にファイル名，およびディレクトリ名として使用できる文字は半角英数字（0〜9，A〜Z，a〜z），およびアンダースコア（_）です。EJB-JAR，WAR，RAR，またはEARの表示名を特定したい場合は，<display-name>タグを設定することをお勧めします。

(2)　表示名の妥当性の確認

J2EEアプリケーション，EJB-JAR，WAR，RARおよびその構成要素（Enterprise Bean，Servlet，JSP， Filter）のlang属性「en」の表示名に使用できる文字は，英数字（0〜9，A〜Z，a〜z），およびアンダースコア（_）です。J2EEサーバは表示名に半角英数字以外の文字が含まれている場合は，その文字をアンダースコア（_）に変換して使用します。J2EEサーバはJ2EEアプリケーション，EJB-JAR，WAR，RARをインポートする際に表示名の妥当性を確認して，表示名に使用できない文字列が使用されている場合は警告メッセージKDJE42374-Wメッセージを出力します。

ただし，表示名が「TP1/Message Queue - Access」の場合は警告メッセージを出力しません。

表示名の妥当性を確認するサーバ管理コマンドについて説明します。

cjimportappコマンド

アプリケーションの表示名およびアプリケーションに含まれるJ2EEリソース（EJB-JAR，WAR，RAR，Enterprise Bean，Servlet/JSP，Filter）の表示名の妥当性が確認されます。実行時情報付きZIP形式では妥当性は確認されません。

cjimportwarコマンド

アプリケーションに含まれるJ2EEリソース（WAR，Servlet/JSP，Filter）の表示名の妥当性が確認されます。

cjimportresコマンド

J2EEリソース（EJB-JAR，WAR，RAR，Enterprise Bean，Servlet/JSP，Filter）の表示名の妥当性が確認されます。実行時情報付きRAR形式では妥当性は確認されません。

妥当性の確認が実施される表示名を次の表に示します。

表16‒13　妥当性の確認を行う表示名の一覧

項番

表示名を表すDDの要素

定義の種別

1

<application><display-name>

application.xmlの定義

2

<ejb-jar><display-name>

ejb-jar.xmlの定義

3

<ejb-jar><enterprise-beans><session><display-name>

ejb-jar.xmlの定義

4

<ejb-jar><enterprise-beans><entity><display-name>

ejb-jar.xmlの定義

5

<ejb-jar><enterprise-beans><message-driven><display-name>

ejb-jar.xmlの定義

6

<web-app><display-name>

web.xmlの定義

7

<web-app><filter><display-name>

web.xmlの定義

8

<web-app><servlet><display-name>

web.xmlの定義

9

<connector><display-name>

ra.xmlの定義

16.4.7　application.xmlを省略した場合にapplication.xmlが作成される操作

インポートしたJ2EEアプリケーションにapplication.xmlがない場合でも，次の操作を実行すると，application.xmlが作成されます。

cjsetapppropコマンドによって，各属性ファイルの次のどれかのタグの値を変更した場合

アプリケーション属性ファイル

<hitachi-application-property>/<description>

<hitachi-application-property>/<icon>/<small-icon>

<hitachi-application-property>/<icon>/<large-icon>

WAR属性ファイル

<hitachi-war-property>/<war-runtime>/<context-root>

cjrenameappコマンドを実行した場合

16.4.8　application.xmlを省略した場合にJ2EEアプリケーションにリソースを追加するときの注意

インポート済みのEJB-JARファイル，WARファイル，またはRARファイルをapplication.xmlを省略したJ2EEアプリケーションに追加する場合の注意事項を説明します。

J2EEアプリケーションにapplication.xmlが存在しない場合，リソースファイルの拡張子はJava EE仕様によって次のように決められています。

EJB-JARファイルの拡張子は.jar

WARファイルの拡張子は.war

RARファイルの拡張子は.rar

リソースファイルの拡張子がこれらの拡張子ではない場合，J2EEアプリケーションへの追加はできません。追加時にメッセージKDJE42366-Eを出力し，エラーとなります。

17　アノテーションの使用

この章では，アノテーションの機能について説明します。

Servlet 2.5以降またはEJB 3.0以降のアプリケーションでアノテーションを使用する場合に参照してください。

17.1　この章の構成

アノテーションとは，ソースコードにクラスやメソッドの付加情報などを埋め込むための記述方式です。アノテーションを使用することで，従来，DD（web.xmlまたはejb-jar.xml）で指定していた情報を，ServletやEnterprise Beanのソースコード上に指定できます。

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

表17‒1　この章の構成（アノテーションの使用）

タイトル

参照先

アノテーションの指定

17.2

ロード対象のクラスとロード時に必要なクラスパス

17.3

DIの使用

17.4

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

17.5

アノテーションで定義した内容の更新

17.6

アノテーション使用時の注意事項

17.7

17.2　アノテーションの指定

この節では，アプリケーションサーバで指定できるアノテーションの種類，およびアノテーションを指定したアプリケーションの実装のポイントについて説明します。

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

表17‒2　この節の構成（アノテーションの指定）

分類

タイトル

参照先

解説

アノテーションを使用するメリットと指定できるアノテーション

17.2.1

アノテーションを宣言したライブラリJARのクラスの使用

17.2.2

実装

アノテーションを指定する場合のEnterprise Beanの実装

17.2.3

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

17.2.1　アノテーションを使用するメリットと指定できるアノテーション

ここでは，アノテーションを使用するメリットと指定できるアノテーションについて説明します。

(1)　アノテーションを使用するメリット

アノテーションを使用するメリットを次に示します。

ソースコードとDDに分散していた情報を，ソースコード上に集約できます。

WebアプリケーションやEnterprise BeanのDDを作成する必要がありません。

DIによって，ほかのEnterprise Beanやリソースへの参照を取得できます。

DIについては，「17.4　DIの使用」を参照してください。

(2)　Webアプリケーションで指定できるアノテーション

Webアプリケーションにアノテーションを指定できるのは，Servlet 2.4以降の場合です。ただし，指定できるアノテーションは，Servletのバージョンによって異なります。

指定できるアノテーションについては，マニュアル「アプリケーションサーバ リファレンス API編」の「2.1　アノテーションのサポート範囲」を参照してください。

なお，@Resourceアノテーションで指定できるリソースのタイプについては，「17.4.1　@Resourceアノテーションで指定できるリソースのタイプ」を参照してください。また，@EJBおよび@Resourceアノテーションのname属性は，web.xmlのタグの要素と対応しています。対応については，標準仕様を確認してください。

ポイント

Servlet 2.3以前のバージョンのweb.xmlがある場合，アノテーションの指定は無効になります。

(3)　Enterprise Beanで指定できるアノテーション

Enterprise Beanにアノテーションを指定できるのは，EJB 3.0の場合です。

指定できるアノテーションについては，マニュアル「アプリケーションサーバ リファレンス API編」の「2.1　アノテーションのサポート範囲」を参照してください。

なお，@RemoteHomeまたは@LocalHomeアノテーションを使用してホームインタフェースを指定する場合，指定されたホームインタフェースのcreateメソッドの戻り値がコンポーネントインタフェースとみなされます。

17.2.2　アノテーションを宣言したライブラリJARのクラスの使用

ライブラリJARに含まれるクラスは，各コンポーネントから使用されます。ライブラリJARのクラスに記述できるのは，そのクラスを使用するコンポーネントでサポートされているアノテーションです。

ライブラリJARで指定できるアノテーションには，次の制限があります。

ライブラリJARでは，コンポーネントを宣言するアノテーションは指定できません。指定しても無視されます。

ライブラリJAR内のコンポーネントであるクラスに定義されたアノテーションは，サポート対象外とします。

次のEJB-JARやWARから参照された場合，ライブラリJARで宣言されているアノテーションは無視されます。

EJB 2.1以前のモジュールを含むEJB-JAR

Servlet 2.4以前のモジュールを含むWAR

J2EE 1.4のJ2EEアプリケーションに含まれるEJB 3.0（DDなし）から参照された場合，ライブラリJARで宣言されているアノテーションは無視されます。

ライブラリJAR内のアノテーションを記述したクラスの使用例を次の図に示します。

図17‒1　ライブラリJAR内のアノテーションを記述したクラスの使用例

EJB 3.0以降またはServlet 2.5以降から参照した場合，ライブラリJARに含まれる「@Resource」や「@EJB」が有効になります。EJB 2.1以前またはServlet 2.4以前のコンポーネントから参照した場合，ライブラリJARに含まれる「@Resource」や「@EJB」は無視されます。ただし，参照元のJ2EEアプリケーションのバージョンは，Java EE 5以降であることが前提です。

17.2.3　アノテーションを指定する場合のEnterprise Beanの実装

Enterprise Beanの場合，アノテーションは，Session Beanで指定できます。ここでは，アノテーションを指定して，Stateless Session Bean，またはStateful Session Beanを実装する場合のポイントについて説明します。

(1)　Stateless Session Beanの実装

Enterprise Beanの種類（Stateless Session Bean）は，@Statelessアノテーションで指定するか，またはDD（ejb-jar.xml）に指定します。

ビジネスインタフェースを使用してSession Beanを実装できます。

javax.ejb.SessionBeanインタフェースをインプリメントすることは，必須ではありません。

インターセプタクラスは，必要に応じて実装します。

Stateless Session Beanには，次のコールバックを定義できます。

@PostConstruct

@PreDestroy

コールバック，またはメソッドが呼び出されるタイミングについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.2.3　Enterprise Beanのライフサイクル」を参照してください。

(2)　Stateful Session Beanの実装

Enterprise Beanの種類（Stateful Session Bean）は，@Statefulアノテーションで指定するか，またはDD（ejb-jar.xml）に指定します。

ビジネスインタフェースを使用してSession Beanを実装できます。

javax.ejb.SessionBeanインタフェース，およびjava.io.Serializableインタフェースをインプリメントすることは，必須ではありません。

インターセプタクラスは，必要に応じて実装します。

次のコールバックを定義できます。

@PostConstruct

@PreDestroy

実装クラスのメソッドに@Initアノテーションおよび@Removeアノテーションを指定できます。

コールバック，またはメソッドが呼び出されるタイミングについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.2.3　Enterprise Beanのライフサイクル」を参照してください。

17.3　ロード対象のクラスとロード時に必要なクラスパス

アノテーション情報は，次のような操作を実行したときに読み込まれます。

リソースの追加（cjaddapp）※

インポート時（cjimportapp）

インポート時（cjimportwar）

インポート時（cjimportres）

インポート時（cjimportlibjar）※

開始時（cjstartapp）

リプレース時（cjreplaceapp）

リロード時（cjreloadapp）

注※

対象となるのはライブラリJARのクラスです。

アノテーション情報を読み込むためには，まずクラスをロードする必要があります。

アノテーション情報を読み込むためにロードするクラスを次の図に示します。

図17‒2　アノテーション情報を読み込むためにロードするクラス

なお，EJB-JAR（ejb-jar.xmlのバージョンが2.1）に含まれるクラスファイルまたはWAR（web.xmlのバージョンが2.4）に含まれるクラスファイルからアノテーション情報を読み込む場合のアノテーションは，アプリケーションサーバ独自の仕様です。ただし，この機能は，旧バージョンとの互換機能です。詳細は，マニュアル「アプリケーションサーバ機能解説 互換編」の「19.1　EJB 2.1とServlet 2.4でのアノテーションの利用」を参照してください。

なお，J2EE 1.4以前に準拠したJ2EEアプリケーションの場合，EJB-JAR（ejb-jar.xmlのバージョンが2.1，またはejb-jar.xmlが省略されたもの）やWAR（web.xmlのバージョンが2.4）からライブラリJARを使用することはできません。指定しても無視されます。

アノテーション情報を取得するためにクラスをロードするかどうかは，各モジュールのバージョン，およびDD内の属性定義に依存します。

モジュールのバージョンがEJB-JAR（3.0）またはWAR（2.5）の場合のアノテーション情報を取得するかどうかの条件を次の表に示します。

表17‒3　モジュールのバージョンがEJB-JAR（3.0）またはWAR（2.5）の場合

モジュール

DDのmetadata-completeタグ

DD省略

falseまたはタグを省略

true

EJB-JAR（3.0）

○

−

○

WAR（2.5）

○

−

○

（凡例）

○：アノテーション情報を取得する

−：アノテーション情報を取得しない

ライブラリJARのアノテーション情報を取得するかどうかを次の表に示します。

表17‒4　ライブラリJARの場合

モジュール

Java EE 5以降に準拠するJ2EEアプリケーション

J2EE 1.4以前に準拠するJ2EEアプリケーション

DDのmetadata-completeタグ

DD省略※

DDのmetadata-completeタグ

DD省略

falseまたはタグを省略※

true

falseまたはタグを省略

true

EJB-JAR（3.0）

○

−

○

×

×

−

WAR（2.5）

○

−

○

×

×

×

（凡例）

○：アノテーション情報を取得する（J2EEアプリケーションに一つでも該当するモジュールが含まれている場合，取得する）

−：アノテーション情報を取得しない

×：サポートされていない組み合わせである

注※　プロパティejbserver.deploy.annotations.load_libjars.enabledの値にfalseが設定されている場合，ライブラリJARのクラス内のアノテーション情報を取得しません。

注意事項

アノテーション情報を読み込むために必要なクラスが不足している場合，または不正なクラスがある場合は，アノテーション情報の取得処理中に例外が発生します。クラスのロード時に例外が発生した場合は，例外ログ，およびメッセージKDJE42380-Wを出力し処理を続行します。なお，例外が発生した場合にエラーにしたいときは，プロパティejbserver.deploy.annotations.load_check.enabledの値をfalseからtrueへ変更してください。

17.4　DIの使用

Dependency Injection（DI）とは，EJBやインターセプタクラスのフィールドやsetterメソッドに，@EJBや@Resourceアノテーションを指定することで，Enterprise Beanやリソースへの参照をEJBコンテナが自動的にセットする機能です。DIを使用すると，Enterprise Beanやリソースへの参照を，JNDIを使用してルックアップする必要がなくなります。ここでは，@Resourceアノテーションで指定できるリソースのタイプ，@Resourceアノテーションを使用したリソースの参照解決，およびDIに関する注意事項について説明します。

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

表17‒5　この節の構成（DIの使用）

分類

タイトル

参照先

解説

@Resourceアノテーションで指定できるリソースのタイプ

17.4.1

@Resourceアノテーションを使用したリソースの参照解決

17.4.2

DI失敗時の動作

17.4.3

注意事項

注意事項

17.4.4

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

17.4.1　@Resourceアノテーションで指定できるリソースのタイプ

@Resourceアノテーションを使用して，リファレンスを定義できます。@Resourceアノテーションで指定できるリソースのタイプを次の表に示します。

表17‒6　@Resourceアノテーションで指定できるリソースのタイプ

リソースのタイプ

指定可否

javax.sql.DataSource※1

○

javax.mail.Session

○

java.net.URL

×

javax.jms.ConnectionFactory

○

javax.jms.QueueConnectionFactory※2

○

javax.jms.TopicConnectionFactory

○

javax.jms.Queue※2

○

javax.jms.Topic

○

javax.resource.cci.ConnectionFactory※3

○

javax.resource.cci.InteractionSpec

×

javax.transaction.UserTransaction

○※4

org.omg.CORBA_ 2_3.ORB

○※5

javax.xml.rpc.Service

×

javax.xml.ws.Service

×

javax.jws.WebService

×

javax.ejb.EJBContext

○※6

javax.ejb.SessionContext

○※6

javax.ejb.TimerService

○※6※7

JavaBeansリソース独自

○

java.lang.String

○※8

java.lang.Character

○※8

java.lang.Integer

○※8

java.lang.Boolean

○※8

java.lang.Double

○※8

java.lang.Byte

○※8

java.lang.Short

○※8

java.lang.Long

○※8

java.lang.Float

○※8

（凡例）　○：指定できる　×：指定できない

注※1　DB Connectorが該当します。

注※2　TP1/Message Queue - Access，Reliable Messagingが該当します。

注※3　TP1 Connectorが該当します。

注※4　CMTで動作するEnterprise Beanまたはインターセプタでは使用できません。

注※5　ORBのshareable属性はtrueが指定されているものとして動作します。なお，注入されるORBオブジェクトは，ほかのコンポーネントでも使用される共有のインスタンスです。

注※6　Webコンテナ上で動作するクラスでは使用できません。

注※7　Stateful SessionBeanやStateful SessionBeanに適用されたインターセプタでは使用できません。

注※8　<env-entry-value>タグに，DIまたはルックアップで取得できる値を設定できません。

17.4.2　@Resourceアノテーションを使用したリソースの参照解決

@Resourceアノテーションを使用してリソースの参照解決をする方法には，次の2種類があります。

name属性にリソースの別名を指定する方法

mappedName属性に参照先リソースを指定する方法

@Resourceアノテーションに属性を指定しない場合は，cosminexus.xmlまたはcosminexus.xml以外の属性ファイルによってリンクを解決する必要があります。ここでは，それぞれの方法について説明します。

(1)　@Resourceアノテーションのname属性で指定する方法

@Resourceアノテーションのname属性にリソースの別名を指定します。

@Resourceアノテーションのname属性に指定できるリソースを次に示します。

javax.sql.DataSource

javax.jms.ConnectionFactory

javax.jms.QueueConnectionFactory

javax.jms.TopicConnectionFactory

javax.resource.cci.ConnectionFactory

コーディング例を次に示します。この例は，@Resourceアノテーションのname属性に別名「jdbc/ds」を設定する場合の例です。

package sample;

@Stateless public class MySessionBean implements MySession {
 @Resource(name="jdbc/ds") public DataSource customerDB;
    ...
}

@Resourceアノテーションのname属性にリソースアダプタの別名を指定した場合，参照解決が自動で実施されます。そのため，属性ファイルを編集する必要はありません。属性ファイルを取得した場合は，次のようになります。

<resource-ref>
  <description xml:lang="en"></description>
  <res-ref-name>jdbc/ds</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
  <injection-target>
     <injection-target-class>sample.MySessionBean</injection-target-class>
     <injection-target-name>customerDB</injection-target-name>
  </injection-target>
  <linked-to></linked-to>
</resource-ref>

(2)　@ResourceアノテーションのmappedName属性で指定する方法

@ResourceアノテーションのmappedName属性にリソースの表示名やキュー表示名を指定します。

@ResourceアノテーションのmappedName属性に記述したリソース表示名が参照解決に使用されます。

コーディング例を次に示します。この例は，@ResourceアノテーションのmappedName属性にリソース表示名「DB_Connector_for_Oracle」を設定する場合の例です。

package sample;

@Stateless public class MySessionBean implements MySession {
 @Resource(mappedName="DB_Connector_for_Oracle") public DataSource customerDB;
    ...
}

ここでは，@Resourceのname属性を省略しているため，デフォルト値「クラス名/フィールド名」が使用されます。この場合のデフォルト値は「sample.MySessionBean/customerDB」となります。属性ファイルを取得した場合は，次のようになります。

<resource-ref>
  <description xml:lang="en"></description>
  <res-ref-name>sample.MySessionBean/customerDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
  <mapped-name>DB_Connector_for_Oracle</mapped-name>
  <injection-target>
     <injection-target-class>sample.MySessionBean</injection-target-class>
     <injection-target-name>customerDB</injection-target-name>
  </injection-target>
  <linked-to></linked-to>
</resource-ref>

(3)　cosminexus.xmlまたはそれ以外の属性ファイルで指定する方法

@Resourceアノテーションの属性を指定しない場合，cosminexus.xmlやcosminexus.xml以外の属性ファイルを使って参照解決をする必要があります。cosminexus.xml，またはcosminexus.xml以外の属性ファイルの<linked-to>に，リソースの表示名を指定します。参照先リソースがキューの場合は，<linked-queue>にリソースアダプタの表示名とキュー表示名を記述します。参照先リソースが管理対象オブジェクトの場合は，<linked-adminobject>にリソースアダプタの表示名と管理対象オブジェクト名を記述します。

コーディング例を次に示します。この例では，@Resourceアノテーションのname属性を省略しているため，別名としてデフォルト値の「クラス名/フィールド名」が使用されます。ここでは，「sample.MySessionBean/customerDB」が設定されます。

package sample;

@Stateless public class MySessionBean implements MySession {
 @Resource public DataSource customerDB;
    ...
}

cosminexus.xmlで参照解決をする場合は，<link-to>，<linked-queue>または<linked-adminobject>にリソースの表示名を指定してから，アプリケーションをインポートします。cosminexus.xml以外の属性ファイルで参照解決をする場合は，アプリケーションをインポートしたあとで，属性ファイル（アプリケーション統合属性ファイルなど）を取得します。取得した属性ファイルに，<linked-to><linked-queue>または<linked-adminobject>に参照先となるリソース表示名を記述します。

属性を設定したあとで属性ファイルを取得した場合は，次のようになります。

<resource-ref>
  <description xml:lang="en"></description>
  <res-ref-name> sample.MySessionBean/customerDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
  <injection-target>
     <injection-target-class>sample.MySessionBean</injection-target-class>
     <injection-target-name>customerDB</injection-target-name>
  </injection-target>
  <linked-to>DB_Connector_for_Oracle</linked-to>
</resource-ref>

(4)　参照解決方法の優先順位

@Resourceアノテーションを使用してリソースの参照解決をする場合に，複数の方法を同時に設定したときには，次の優先順位で設定が有効になります。

cosminexus.xmlまたはcosminexus.xml以外の属性ファイルによる設定

@ResourceアノテーションのmappedName属性の設定

@Resourceアノテーションのname属性の設定

J2EEリソースに異なる別名が同時に設定された場合に有効となる別名の設定について表に示します。

表17‒7　複数の方法を同時に設定した場合に有効となる参照先の設定

name属性の設定の有無※1

mappedName属性の設定の有無

属性ファイル※2の<linked-to>などの設定の有無

有効となる別名の設定※3

あり

あり

あり

属性ファイル※2の<linked-to>などの設定

なし

@ResourceアノテーションのmappedName属性の設定

なし

あり

属性ファイル※2の<linked-to>などの設定

なし

@Resourceアノテーションのname属性の設定

なし

@Resourceアノテーションがフィールド・メソッドに指定されていればデフォルト値が使用されて，「あり」の場合と同様になります※4。

また，@Resourceアノテーションがクラスに指定された場合は，@Resourceアノテーションのname属性は省略できません。クラスに指定された@Resourceのname属性がない場合，アノテーションの読み込みに失敗して，インポート時にエラーになります。※5

（凡例）

あり：アノテーションや属性ファイルで属性が設定されていることを示します。

なし：「なし」の場合の説明を次に示します。

@Resourceアノテーションのname属性および@ResourceアノテーションのmappedName属性そのものの記述がない場合を示します。または，cosminexus.xmlまたはcosminexus.xml以外の属性ファイルの<linked-to>のタグそのものがない場合を示します。

属性またはタグに指定された値がない（空文字）場合を示します。

注※1　@Resourceアノテーションのname属性に対応する標準DDの<resource-ref>または<res-ref-name>にもリソースの別名を指定できます。@ResourceアノテーションのmappedName属性，および属性ファイルの<linked-to>などに指定がない場合は，標準DDの<resource-ref>または<res-ref-name>に指定した別名を持つリソースが参照先となります。

注※2　cosminexus.xmlおよびcosminexus.xml以外の属性ファイルが該当します。

注※3　別名の設定がない場合，アプリケーションの開始に失敗します。

注※4　@ResourceアノテーションのmappedName属性と属性ファイル（cosminexus.xmlおよびcosminexus.xml以外の属性ファイル）の<linked-to>などに指定がなく，name属性のデフォルト値，またはクラスに指定した@Resourceアノテーションのname属性の値とリソースの別名が一致した場合は，その別名を持つリソースが参照先となります。

注※5　mappedName属性と属性ファイル（cosminexus.xmlおよびcosminexus.xml以外の属性ファイル）の<linked-to>などに指定がなく，クラスに指定した@Resourceのname属性の値とリソースの別名が一致した場合は，その別名を持つリソースが参照先となります。

17.4.3　DI失敗時の動作

DIが失敗した時の動作について説明します。

DDの<injection-target-class>タグに指定したクラスがない場合，または<injection-target-name>タグに指定したメソッドおよびフィールドがない場合，DIに失敗します。この場合のアプリケーション開始時，およびDI実行時の挙動を次に示します。

(1)　DDの<injection-target-class>タグに指定したクラスがない場合

挙動を次に示します。

アプリケーション開始時

メッセージ（KDJE53905-W）を出力します。アプリケーション開始処理は続行します。

DI実行時

<injection-target-class>タグに指定したクラスがないため，DIは実行できません。

(2)　DDの<injection-target-name>タグに指定したメソッドおよびフィールドがない場合

挙動を次に示します。

アプリケーション開始時

メッセージ（KDJE53905-W）を出力します。アプリケーション開始処理は続行します。

DI実行時

メッセージ（KDJE53900-E）を出力して，DIに失敗します。

17.4.4　注意事項

DIを使用した場合の注意事項を示します。

DIを使用した場合の，Stateful Session Beanのリファレンス取得時の注意事項を次に示します。

J2EEアプリケーションがサーブレットからStateful Session Beanを呼び出す構成の場合，サーブレットでStateful Session Beanのリファレンスを取得するときは，DIを使用しないで，JNDI経由で行ってください。

J2EEアプリケーションがStateless Session BeanまたはSingleton Session BeanからStateful Session Beanを呼び出す構成の場合に，DIを使用してStateful Session BeanのビジネスインタフェースをStateless Session Beanに注入するとき，Stateless Session Beanのビジネスメソッド呼び出し，またはタイムアウトメソッド呼び出しのたびにDIが実行されます。

@Resourceアノテーションで指定できないリソースのタイプを指定した場合，インポート時に例外が発生します。

@EJBおよび@Resourceアノテーションのname属性は，次の表に示すejb-jar.xmlのタグの要素と対応しています。このため，アノテーションでEnterprise Beanおよびリソースへの参照を定義する場合は，@EJBおよび@Resourceアノテーションのname属性と，name属性に対応するejb-jar.xmlのタグに指定する要素は，重複しないように設定してください。name属性に対応するejb-jar.xmlのタグを次の表に示します。

表17‒8　name属性に対応するejb-jar.xmlのタグ

アノテーションと属性

name属性に対応するejb-jar.xmlのタグ

@EJB　name()

<ejb-ref>タグ下の<ejb-ref-name>タグ

<ejb-local-ref>タグ下の<ejb-ref-name>タグ

@Resource　name()

<env-entry>タグ下の<env-entry-name>タグ

<resource-ref>タグ下の<res-ref-name>タグ

<resource-env-ref>タグ下の<resource-env-ref-name>タグ

DIを使用するWebアプリケーションのリロード時には，例外が発生することがあります。例外が発生する場合を次に示します。

DIターゲット（DI機能を使用して参照を注入する対象）を定義しているクラス，または参照先クラスのロードに失敗した場合

DIターゲット名に対応したフィールド，メソッドがリロード後に削除されて，存在しない場合

例外が発生すると，メッセージログにKDJE53904-Wのメッセージが出力され，処理が続行されます。処理は続行されますが，対象となるインスタンスに対するDIが実行できない状態になり，対象のインスタンスへのリクエストが実行できなくなります。このため，このメッセージが出力された場合は，Webアプリケーションを修正して再度リロードを実施してください。

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

この節では，アノテーションの参照抑止機能について説明します。

アノテーション参照抑止機能を使用すると，アノテーションを使用していないモジュールに対する解析処理を抑止できます。これによって，不要なオーバーヘッドや不要な解析エラーの発生を防げます。

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

表17‒9　この節の構成（アノテーション参照抑止機能）

分類

タイトル

参照先

解説

アノテーション参照抑止機能の目的と適用範囲

17.5.1

アノテーションを参照するタイミング

17.5.2

実装

DDでの定義（モジュール単位の設定）

17.5.3

運用

アノテーション参照抑止機能の設定変更

17.5.4

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

17.5.1　アノテーション参照抑止機能の目的と適用範囲

ここでは，アノテーション参照抑止機能の目的と適用範囲について説明します。

(1)　アノテーション参照抑止機能の目的

アノテーション参照抑止機能は，J2EEアプリケーション中のアノテーションの参照（解析処理）を実施するかどうかを設定する機能です。モジュール内のアノテーションの有無を判断するためには，アプリケーションの解析が必要です。しかし，すべてのアプリケーションを解析すると，アノテーションを使用していないアプリケーションの場合，不要なオーバーヘッドが発生します。また，リソースやほかのアプリケーションを参照するアプリケーションの場合，アノテーション解析時にクラスファイルの参照エラーが発生して，デプロイに失敗することがあります。

アノテーション参照抑止機能を使用すると，アノテーションを使用しない場合に，アノテーションの解析処理を抑止できます。

アノテーションの参照抑止機能は，Servlet 2.5以降の場合に使用できます。EJB 3.0以降の場合，アノテーション参照抑止機能は使用できません。

Servlet 2.5以降の場合の動作を次に示します。

Servlet 2.5以降の場合

Java EE 5以降のアプリケーションでは，標準仕様でアノテーションを使用できます。Servlet 2.5以降のDDには，アノテーションの参照を抑止するための属性であるmetadata-complete属性が追加されています。metadata-complete属性を使用して，モジュール単位にアノテーションの参照を抑止できます。ただし，web.xmlでmetadata-complete属性を使用しても，CDIアノテーションの参照は抑止しません。

また，DDが省略されているアプリケーションの場合は，モジュール定義情報を読み込むために必ずアノテーションが参照されるため，参照抑止機能は使用できません。

モジュール単位のアノテーション参照抑止機能は，Java EE 5以降の標準仕様に準拠した機能です。

参考

アプリケーションサーバでは，EJB 3.0のDDには<display-name>要素のほか，インターセプタおよびアプリケーション例外に関する定義だけが定義できます。EJB 3.1ではこれらに加え，<module-name>要素が定義できますが，それ以外のEJB 3.0またはEJB 3.1のモジュール定義情報は，すべてアノテーションで定義する必要があります。このため，EJB 3.0以降ではアノテーション参照抑止機能を使用できません。

注意事項

アノテーションを記述したEJB 2.1またはServlet 2.4のモジュールを含むJ2EEアプリケーションがインポートされた状態で，アノテーション参照抑止機能を無効から有効に変更した場合，次の現象が発生します。

属性ファイルにアノテーション情報が出力される

@Resourceまたは@Resourcesを使用していた場合，属性ファイルの設定およびJ2EEアプリケーションの開始に失敗する

(2)　適用範囲

アノテーション参照抑止機能の適用範囲は，アノテーションを含むモジュールの種類によって異なります。

アノテーション抑止機能の適用範囲を次の表に示します。

表17‒10　アノテーション抑止機能の適用範囲

モジュールのバージョン

DDの有無と指定内容

参照抑止の範囲

J2EEサーバ単位

モジュール単位

EJB

1.1，2.0

DDあり（metadata-complete属性なし）

−

−

2.1※1

DDあり（metadata-complete属性なし）

○※2

−

3.0以降

DDなし

×

○

DDあり（metadata-complete属性あり）

省略

×

○

指定あり

×

○※3

Servlet

2.2，2.3

DDあり（metadata-complete属性なし）

−

−

2.4※1

DDあり（metadata-complete属性なし）

○※2

−

2.5以降

DDなし

×

○※4

DDあり（metadata-complete属性あり）

省略

×

○※4

指定あり

×

○※4

（凡例）○：有効になる　×：使用できない　−：該当しない

注※1　EJB 2.1およびSevlet 2.4でのアノテーションの利用は，旧バージョンとの互換用の機能です。詳細は，マニュアル「アプリケーションサーバ 機能解説 互換編」の「19.1　EJB 2.1とServlet 2.4でのアノテーションの利用」を参照してください。

注※2　有効にすると，アノテーションを記述したEJB 2.1またはServlet 2.4のモジュールを含むJ2EEアプリケーションは使用できなくなります。

注※3　値にtrueは指定できません。trueを指定した場合，J2EEサーバへのアプリケーションのインポートおよびリデプロイに失敗します。

注※4　Servlet3.0で追加された@HandlesTypesアノテーションはアノテーション参照抑止機能の対象になりません。

モジュール単位の設定はDDのmetadata-complete属性で設定します。J2EEサーバ単位の設定は，ejbserver.deploy.applications.metadata_completeプロパティで設定します。モジュール単位の設定とJ2EEサーバ単位の設定の組み合わせた場合にアノテーションが参照されるかどうかを次の表に示します。

表17‒11　J2EEサーバ単位の設定とモジュール単位の設定の組み合わせ

モジュールのバージョン

モジュール単位の設定

J2EEサーバ単位の設定

プロパティの指定なし

ejbserver.deploy.applications.metadata_completeプロパティ

false

true

EJB 3.0以降

DDなし

○

○

○

DDあり（metadata-complete属性あり）

省略

○

○

○

false

○

○

○

true

−※

−※

−※

Servlet 2.5以降

DDなし

○

○

○

DDあり（metadata-complete属性あり）

省略

○

○

○

false

○

○

○

true

×

×

×

（凡例）○：参照する　×：参照しない　−：対象外

注※　DDのmetadata-complete属性にtrueを指定したEJB 3.0を含むアプリケーションは，インポートおよびリデプロイに失敗します。

17.5.2　アノテーションを参照するタイミング

アノテーションを参照するタイミングを，アプリケーション参照抑止機能を使用する場合としない場合に分けて次の表に示します。なお，J2EEサーバ単位，モジュール単位どちらの参照抑止機能でも，アノテーションを参照するタイミングは同じです。

表17‒12　アノテーションを参照するタイミング

タイミング

（実行したコマンド）

参照抑止機能の設定

アプリケーションの形式

アーカイブ形式

展開ディレクトリ形式

インポート時（cjimportapp）

使用する

×

×

使用しない

○

○

インポート時（cjimportwar）

使用する

×

×

使用しない

○

○

インポート時（cjimportres※1）

使用する

×

−

使用しない

○

−

開始時（cjstartapp※2）

使用する

×

×

使用しない

○※3

○

リプレース時（cjreplaceapp）

使用する

×

−

使用しない

△

−

リロード時（cjreloadapp）

使用する

−

×

使用しない

−

○

属性取得時

（cjgetappprop）

使用する

×

×

使用しない

×

×

属性設定時

（cjsetappprop）

使用する

×

×

使用しない

×

×

（凡例）

使用しない：アプリケーション参照抑止機能を使用しない設定

使用する：アプリケーション参照抑止機能を使用する設定

○：アノテーションを参照する

×：アノテーションを参照しない

△：アノテーションを参照するが変更は反映されない

−：該当しない

注※1　

cjimportresコマンドに引数「-type ejb」または「-type war」を指定して実行した場合です。

注※2　

J2EEサーバの再起動時も含みます。

注※3　

その前にJ2EEサーバを起動したときと設定が異なる場合だけアノテーションをロードします。

参考

展開ディレクトリ形式のアプリケーションをインポートしたあとでアノテーション情報を変更した場合，cjgetapppropコマンドによって属性ファイルを取得しても変更後のアノテーション情報は取得できません。これは，属性ファイルを取得する時にはアノテーション情報がクラスファイルからロードされないためです。

変更後のアノテーション情報を属性ファイルに取得するためには，cjstartappコマンドなど，アノテーション情報をクラスファイルからロードするコマンドを実行してから，属性ファイルを取得してください。

17.5.3　DDでの定義（モジュール単位の設定）

Servlet 2.5以降のモジュールに対するアノテーション参照抑止機能の定義は，web.xmlに指定します。なお，EJB 3.0以降の場合，<ejb-jar>タグのmetadata-complete属性にはfalseだけが指定できます。

DDでのアノテーション参照抑止機能の定義について次の表に示します。

表17‒13　DDでのアノテーション参照抑止機能の定義

項目

DDの種類

指定するタグおよび属性

設定内容

Servlet 2.5以降

web.xml

<web-app>タグのmetadata-complete属性

アノテーション参照を抑止する場合はtrueを設定します。

アノテーションを参照する場合はfalseを設定します。

web.xmlでmetadata-complete属性を使用しても，CDIアノテーションの参照は抑止しません。

EJB 3.0以降

ejb-jar.xml

<ejb-jar>タグのmetadata-complete属性

アノテーションを参照する場合はfalseを設定します。

設定例を次に示します。

設定例（Servlet 2.5の場合）

<web-app metadata-complete="true"
  xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  version="2.5">
  ：
</web-app>

背景色付きの太字の部分がアノテーション参照抑止機能の設定です。

DDのmetadata-complete属性の指定を省略した場合，またDDを省略した場合は，metadata-complete属性にfalseを指定した場合と同様に動作します。

17.5.4　アノテーション参照抑止機能の設定変更

モジュール単位の設定（DDのmetadata-complete属性の値）を変更する場合は，metadata-complete属性を変更したアプリケーションを作成して，J2EEサーバに再度インポートする必要があります。

metadata-complete属性を変更した場合，リデプロイ機能（-replaceDDオプションを指定したcjreplaceappコマンド）によってアプリケーションを入れ替えようとすると，エラーになり，入れ替え処理は中断されます。

17.6　アノテーションで定義した内容の更新

この節では，アノテーションで定義した内容の更新方法について説明します。

アノテーションを更新した場合，アプリケーションをインポートし直すか，リロード機能を使用することで，アプリケーションに変更を反映できます。また，Java EE 5以降の標準仕様では，アノテーションで定義した情報を標準DDで上書きできることが決められています。アプリケーションサーバでは，標準DDによるアノテーションでの定義内容の上書き，およびサーバ管理コマンドを使用した定義内容の更新ができます。

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

表17‒14　この節の構成（アノテーションで定義した内容の更新）

分類

タイトル

参照先

解説

アノテーションの更新

17.6.1

DDによるアノテーションの上書き

17.6.2

サーバ管理コマンドを使用した定義の参照と更新

17.6.3

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

17.6.1　アノテーションの更新

アノテーションの定義内容を更新した場合は，次のどちらかの方法でアプリケーションに反映できます。

アプリケーションをインポートし直す方法

通常の入れ替えによって更新内容を反映する方法です。アプリケーションを停止してから入れ替えます。

リロード機能を使用する方法（展開ディレクトリ形式のアプリケーションの場合）

更新検知またはcjreloadappコマンドの実行によって，デプロイ済みのアプリケーションの内容を動的に入れ替える方法です。展開ディレクトリ形式のアプリケーションの場合に使用できます。

ただし，リロード機能で更新できるアノテーションには制限があります。各アノテーションのリロード機能での更新可否を次の表に示します。

表17‒15　各アノテーションのリロード機能での更新可否

アノテーション名

更新可否

@PostConstruct

○

@PreDestroy

○

@Resource

×

@Resources

×

@RunAs

×

@DeclareRoles

○

@RolesAllowed

×

@PermitAll

○

@DenyAll

○

@Stateless

×

@Stateful

×

@Singleton

×

@DependsOn

○

@Startup

○

@AccessTimeout

○

@Lock

○

@ConcurrencyManagement

○

@Init

○

@Remove

○

@AfterBegin

○

@BeforeCompletion

○

@AfterCompletion

○

@Remote

×

@Local

×

@RemoteHome

×

@LocalHome

×

@LocalBean

×

@TransactionManagement

○

@TransactionAttribute

○

@PostActivate

○

@PrePassivate

○

@Interceptors

○

@AroundInvoke

○

@ExcludeDefautInterceptors

○

@ExcludeClassInterceptors

○

@Timeout

×

@Schedule

×

@Schedules

×

@Asynchronous

○

@ApplicationException

○

@EJB

×

@EJBs

×

@WebService

○

@WebServiceProvider

○

@PersistenceContext

○

@PersistenceContexts

○

@PersistenceProperty

○

@PersistenceUnit

○

@PersistenceUnits

○

@WebEndpoint

×

@WebServiceRef

×

（凡例）○：更新できる　×：更新できない

17.6.2　DDによるアノテーションの上書き

アノテーションに定義した情報は，DDで上書きできます。DDによって上書きできるのは，Servlet 2.5以降およびEJB3.0以降のモジュールに定義されたアノテーションです。

アノテーションを上書きする方法には，次の2種類があります。

DDを編集して上書きする方法

DDを直接編集する方法です。

サーバ管理コマンドを使用して属性を変更して上書きする方法

J2EEサーバにインポート後のアプリケーションに対して，cjsetapppropコマンドまたはcjsetrespropコマンドを使用して属性を変更する方法です。ただし，この方法で上書きできるアノテーションには条件があります。詳細については「17.6.3　サーバ管理コマンドを使用した定義の参照と更新」を参照してください。

参考

アプリケーションサーバにインポートするEJB 3.0以降のDDには次の定義ができます。

<display-name>要素

<interceptor-binding>要素，およびその配下の要素（インターセプタに関する定義）

<application-exception>要素，およびその配下の要素（アプリケーション例外に関する定義）

注意事項

@WebServletアノテーションのname属性には，別の@WebServletアノテーションと同じ値を設定できません。また，@WebFilterアノテーションのfiltername属性には，別の@WebFilterアノテーションと同じ値を設定できません。別のアノテーションと同じ値を設定した場合，DDでの上書き時に次のメッセージが出力され，該当するアノテーションは無視されます。

アノテーション

属性

メッセージ

@WebServlet

name属性

KDJE42397-W

@WebFilter

filtername属性

KDJE42398-W

上書き方法は，対象となるDDの要素および子要素が複数回出現できる要素かどうかによって異なります。

DDの要素が0回（出現なし）または1回しか出現しない要素の場合

アノテーションの情報はDDの情報で上書きされます。

DDの要素が0回以上または1回以上出現する要素の場合

DDとアノテーションを関連づける要素（キー）の有無，およびDDの要素内の子要素の出現回数で上書き規則が異なります。

ここでは，DDによるアノテーションの上書き規則を次の四つのパターンに分けて説明します。

表17‒16　DDによるアノテーションの上書き規則のパターン

パターン

アノテーションと対応するDDの要素の出現回数

キーの有無

DDの子要素の出現回数

参照先

パターン1

0回または1回

キーがない場合

−

(1)

パターン2

0回以上または1回以上

キーがない場合

−

(2)

パターン3

キーがある場合

0回または1回

(3)

パターン4

0回以上または1回以上

(4)

（凡例）−：キーの有無による違いがない

アノテーションとDDの要素の対応，各要素のキーの有無，およびキーとなる要素については，標準仕様を参照してください。

それぞれのパターンについて説明します。

(1)　パターン1（0回または1回出現する要素の場合）

出現回数が0回または1回出現する要素の場合は，アノテーションに対応する要素がDDに定義されているかどうかで上書きするかどうかが決まります。キーの値は関係ありません。

アノテーションに対応する要素がDDに定義されている場合

DDの定義でアノテーションの定義が上書きされます。

アノテーションに対応する要素がDDに定義されていない場合

アノテーションの定義が有効になります。

出現回数が0回または1回の要素の例を次の図に示します。キーがある場合の例です。

図17‒3　0回または1回出現する要素の例

(2)　パターン2（0回以上または1回以上出現する要素でキーがない場合）

DDとアノテーションの両方の定義が有効になります。

キーがない場合の例を次の図に示します。「@DeclareRoles」で定義したセキュリティロールに加えて，DDで新しいセキュリティロールを定義します。

図17‒4　キーがない場合の例

この例では，アノテーションで「admin」「adminadmin」および「adminadminadmin」の三つのセキュリティロールを定義しています。これに加えて，DDで定義した「admin2」が追加されてマージ後のDDに反映されます。なお，「adminadmin」はアノテーションおよびDDの両方で定義されているセキュリティロールです。アプリケーションは，マージ後のDDが定義されたものとして動作します。

なお，このパターンに該当する場合，アノテーションの定義はサーバ管理コマンドで変更できません。アノテーションに対応する情報を属性ファイルで削除・変更してcjsetapppropコマンドを実行しても，そのあとでcjgetapppropコマンドによって取得した属性ファイルには，アノテーションで定義された情報が出力されます。

(3)　パターン3（0回以上または1回以上出現する要素で子要素が0回または1回出現する場合）

DDの要素内の子要素が0回または1回出現する場合は，キーの値によって上書きの方法が異なります。

キーの値がDDとアノテーションで一致している場合

アノテーションの定義にDDの要素を上書きします。

キーの値がDDとアノテーションで一致しない場合

上書きされません。DDとアノテーションの両方の定義が有効になります。

図17‒5　子要素が0回または1回出現する例

この例では，「res1」の環境エントリの値をアノテーションで定義した「TEST」からDDで定義した「RUNNING」に変更します。アプリケーションは，マージ後のDDが定義されたものとして動作します。

(4)　パターン4（0回以上または1回以上出現する要素で子要素が0回以上または1回以上出現する場合）

DDの要素内の子要素が0回以上または1回以上出現する場合は，キーの値によって上書きの方法が異なります。

キーの値がDDとアノテーションで一致している場合

アノテーションの定義にDDの要素が追加されます。

キーの値がDDとアノテーションで一致しない場合

上書きされません。DDとアノテーションの両方の定義が有効になります。

図17‒6　子要素が0回以上または1回以上出現する例

この例では，アノテーションの定義に対して，DDで定義した要素「injection-target」が追加されます。アプリケーションは，マージ後のDDが定義されたものとして動作します。

17.6.3　サーバ管理コマンドを使用した定義の参照と更新

アノテーションで定義した要素は，サーバ管理コマンドのcjgetapppropコマンドまたはcjgetrespropコマンドを使用して参照できます。また，一部の定義はcjsetapppropコマンドまたはcjsetrespropコマンドを使用して更新できます。

(1)　アノテーションで定義した要素を参照・更新した場合の動作

サーバ管理コマンドを使用してアノテーションで定義した要素を参照・更新した場合の動作について次の表に示します。動作は，DDがある場合とない場合で異なります。

表17‒17　サーバ管理コマンドを使用してアノテーションで定義した要素を参照・更新した場合の動作

要素の種類

cjgetapppropまたはcjgetrespropによる参照

cjsetapppropまたはcjsetrespropによる更新

DDがある場合

DDで定義した要素

DDで定義した内容が出力されます。

DDの内容が更新されます。

アノテーションで定義した要素

アノテーションで定義した内容が出力されます。

更新はできません。

アノテーションの定義をDDで上書きした要素

アノテーションとDDの定義をマージした結果が出力されます。

「(2) サーバ管理コマンドによる定義の更新」を参照してください。

DDがない場合

アノテーションで定義した要素

アノテーションで定義した内容が出力されます。

更新はできません。

(2)　サーバ管理コマンドによる定義の更新

cjsetapppropコマンドまたはcjsetrespropコマンドを使用してアノテーションで定義した属性を上書き更新できるかどうかは，更新する情報がどこに定義されているかによって異なります。

定義されている場所と上書き可否の対応を次の表に示します。

表17‒18　定義されている場所と上書き可否の対応

定義されている場所

上書き可否

DDだけに定義されている要素

可

アノテーションだけに定義されている要素

不可

アノテーションの定義をDDで上書きされている要素

可※

注※　更新後にアプリケーションをエクスポートした場合，エクスポートしたアプリケーションに含まれるWARファイル内のDD（web.xml）に，アノテーションとDDで定義した内容がマージされて出力されます。展開ディレクトリ形式のアプリケーションの場合は，<WARディレクトリ>/WEB-INF/web.xmlに，アノテーションとDDで定義した内容がマージされて出力されます。

注意事項

アノテーションの定義をDDで上書きした要素を，cjsetapppropコマンドまたはcjsetrespropコマンドを使用して上書き更新した場合，アプリケーションディレクトリ内のDDにはDDとアノテーションの情報がマージされて出力されます。この場合，アノテーションで定義した内容がDDに反映されるため，それ以降にクラスファイル内のアノテーションを変更したときは，DDに残っている定義が優先されて変更したアノテーションの定義は有効になりません。

このような場合，DDに反映されているアノテーションの定義を削除して，アプリケーションを再インポートすることでアノテーションの定義が有効になります。また，属性ファイルで定義を追加，変更した場合は，アプリケーションを再インポートする必要はありません。

17.7　アノテーション使用時の注意事項

アノテーションを使用する場合の注意事項を示します。

17.7.1　インポート時の注意

クラスに宣言されたアノテーションが，外部のアーカイブファイルのクラスを参照していると，それらを単体でインポートできません。

EJB（ejb-jar.xmlのバージョン2.1以降またはejb-jar.xmlなし）

Servlet（web.xmlのバージョン2.4以降またはweb.xmlなし）

ライブラリJAR

外部参照は，次のどれかの方法で実施してください。

参照するクラスをすべてEARに含めてインポートする。

参照するクラスをすべてアプリケーションディレクトリに含めてインポートする。

外部参照しているクラスが含まれるJARファイルをコンテナ拡張ライブラリとして設定する。また，インポートするプロセスのクラスパスにも設定する。

操作方法ごとの設定例を示します。

例1：サーバ管理コマンドによって操作する場合

J2EEサーバ用オプション定義ファイルのキー（add.class.path）に参照しているJARファイルを指定します。また，サーバ管理コマンド用オプション定義ファイルのキー（USRCONF_JVM_CLASSPATH）に参照しているJARファイルを指定します。

例2：Management Serverによって操作する場合

運用管理ポータルによる論理J2EEサーバのJ2EEコンテナの設定で，拡張パラメタに"add.class.path=<参照しているJARファイル>"を指定します。

また，adminagentuser.cfgのadd.class.pathキーに参照しているJARファイルを指定します。さらに，サーバ管理コマンド用オプション定義ファイルのキー（USRCONF_JVM_CLASSPATH）に参照しているJARファイルを指定します。

次の場合はサーバ管理コマンド実行時にエラーになります。

@Resourceの要素type()にアプリケーションサーバでサポートしていないJava Typeを設定した場合。

EJB-JARにejb-jar.xmlがなく，かつ@Statelessまたは@Statefulアノテーションを宣言したクラスが一つもない場合。

DDのスキーマ定義の出現回数を上回るアノテーションを宣言していた場合。

WARファイルからEJB-JARファイルを参照している場合，WARファイルとEJB-JARファイルの両方を含んだアプリケーションにしてからインポートしてください。ただし，参照するインタフェースをWARファイルに含めている場合は，WARファイルを個別にインポートすることもできます。

アノテーションの属性にライブラリJAR内のクラスを記述している場合，ライブラリJARを含んだ形のアプリケーションとしてインポートしてください。

ほかのEJB-JARを参照するEJB-JARが存在する場合，両方のEJB-JARを含んだ形のアプリケーションとしてインポートしてください。ただし，参照する側のEJB-JARに，参照される側のインタフェースを含めている場合は，EJB-JARごとにインポートすることもできます。

17.7.2　@Resourceのmapped-name属性指定時の注意

アプリケーションサーバでは，@Resourceで指定されたmapped-name属性だけ処理対象とします。@Resourceに指定したmapped-name属性は，属性ファイルの<resource-ref>タグ下の<linked-to>タグ，<resource-env-ref>タグ下の<linked-to>タグ，および<resource-env-ref>タグ下の<linked-queue>タグに対応するものとして処理します。ただし，属性ファイルの<linked-to>タグおよび<linked-queue>タグとmapped-name属性が両方指定されていた場合は，<linked-to>タグおよび<linked-queue>タグの指定値を優先します。

17.7.3　EJBのリンク解決に関する注意

@EJBはDDの<ejb-ref>タグに対応するアノテーションです。同一アプリケーションの範囲内でEJBのリンクを解決します。@EJBにbeanName属性が指定されている場合，対応するEJB名を持つEJBを検索してリンクを解決します。EJB名とはejb-jar.xmlの場合，<session>タグ，<entity>タグ，および<message-driven>タグ下の<ejb-name>タグを指します。また，アノテーションであれば@Statelessおよび@Statefulのname属性で指定されたものを指します。

@EJBにbeanName属性が指定されていない場合，@EJBのbeanInterface属性と適合する型のEJBを検索してリンクを解決します。@EJBのbeanInterface属性と適合する型のEJBを次に示します。

@EJBのbeanInterface属性で指定したものと同じクラス型のホームインタフェースを持つEJB

@EJBのbeanInterface属性で指定したものと同じクラス型のビジネスインタフェースを持つEJB

一つのビジネスインタフェースを複数のEJBが実装しているようなケースでは，@EJBおよび@EJBsに適合するEJBが複数存在することがあります。参照先を一つに絞り込めない場合はリンクを解決しません。

17.7.4　@RemoteHomeまたは@LocalHome使用時の注意

アプリケーションサーバでは，@RemoteHomeまたは@LocalHomeで指定したホームインタフェースのcreateメソッドの戻り値の型となるインタフェースは，コンポーネントインタフェースと見なされます。ホームインタフェースとビジネスインタフェースの組み合わせでは使用できません。

17.7.5　@PostConstructまたは@PreDestroy使用時の注意

@PostConstructまたは@PreDestroyの定義がJava EE仕様に沿っているかどうか，Webアプリケーション開始時にチェックされます。Java EE仕様に沿わない定義があった場合は，アノテーションに関するメッセージが出力され，Webアプリケーションの開始が中断されます。

web.xmlで<post-construct>または<pre-destroy>タグを指定している場合，Webアプリケーション開始時にメソッドがチェックされます。指定されたクラス，メソッドが見つからない場合は，KDJE39332-Eが出力されエラーとなります。

一つのクラス内で二つ以上のメソッドに@PostConstructまたは@PreDestroyを指定した場合，Webアプリケーションの開始時にKDJE39327-Eが出力されてエラーとなります。

アプリケーションサーバでは，@PostConstructまたは@PreDestroyを指定したメソッド定義をする場合，次の表に示す仕様に注意してください。@PostConstructまたは@PreDestroyを指定したメソッド定義をする場合の仕様について，次の表に示します。

表17‒19　@PostConstructまたは@PreDestroyを指定したメソッド定義をする場合の仕様

メソッド定義の仕様

Java EE仕様との違い

説明

引数を持てません。

−

引数を持つメソッドの場合，Webアプリケーション開始時にKDJE39328-Eのメッセージが出力され，エラーとなります。

検査例外をスローできます。非検査例外と同様に扱われます。

Java EE仕様では，検査例外をスローできません。

throwsの定義があるメソッドの場合，Webアプリケーション開始時にKDJE39329-Wのメッセージが出力されます。

インスタンスメソッドおよびクラス（static）メソッドで使用できます。

Java EE仕様では，staticメソッドでは指定できません。

staticメソッドの場合，Webアプリケーション開始時にKDJE39330-Wのメッセージが出力されます。

戻り値があるメソッドを使用できます。

Java EE仕様では，戻り値はvoidに限定する必要があります。

戻り値があるメソッドの場合，Webアプリケーション開始時にKDJE39331-Wのメッセージが出力されます。

public，protected，パッケージプライベート，privateのどれかを指定できます。

−

−

finalとして宣言できます。

−

−

（凡例）−：なし

@PostConstructアノテーションを指定したメソッドで例外が発生した場合，メッセージKDJE53906-Eが出力され，例外の発生したインスタンスが破棄されます。

Webアプリケーション開始後に初期化するクラスの場合，初期化に失敗してもクラスを使用するたびに初期化が試行されます。例えば，サーブレットへの初回リクエスト時に，@PostConstructを指定したメソッドで例外が発生した場合，次に同じサーブレットへアクセスする際にもサーブレットの初期化が試行されます。

@PreDestroyアノテーションを指定したメソッドで例外が発生した場合，メッセージKDJE53907-Wが出力され，Webコンテナからのオブジェクトの破棄処理が継続されます。

17.7.6　そのほかの注意

@TimeoutをEJBの複数のメソッドに指定した場合，どのメソッドが対象となるかは特定できません。

インターセプタとして指定したクラスのアノテーション情報が取得できない場合は，属性ファイル設定時にエラーになります。アノテーション情報を取得するには，対象のクラスとそのスーパークラス・インタフェース，およびそれらのクラス上で宣言されたすべてのフィールド・メソッドについて情報が取得できるようにクラスパスを指定する必要があります。

@HandlesTypesアノテーションはアノテーション参照抑止機能の対象になりません。アノテーション参照抑止機能が有効な場合でも処理されます。

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

この章では，J2EEサーバで実行できるJ2EEアプリケーションの形式と，形式ごとに実行できるJ2EEアプリケーションのデプロイ，アンデプロイおよび入れ替え機能について説明します。

18.1　この章の構成

J2EEアプリケーションの形式とデプロイの機能と参照先を次の表に示します。

表18‒1　J2EEアプリケーションの形式およびデプロイ機能と参照先

機能

参照先

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

18.2

アーカイブ形式のJ2EEアプリケーション

18.3

展開ディレクトリ形式のJ2EEアプリケーション

18.4

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

18.5

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

18.6

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

18.7

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

18.8

WARアプリケーション

18.9

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

J2EEサーバ上で実行できるアプリケーションを，J2EEアプリケーションといいます。WAR形式のWebアプリケーション，またはEJB-JAR形式のEJBアプリケーションをJ2EEサーバで実行するためには，J2EEアプリケーションとしてデプロイする必要があります。

J2EEサーバ上で実行できるJ2EEアプリケーションは，次に示す2種類です。

アーカイブ形式のJ2EEアプリケーション

EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションです。

展開ディレクトリ形式のJ2EEアプリケーション

EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションです。

なお，J2EEサーバではWARファイルまたはWARディレクトリを指定してインポートできます。インポートしたアプリケーションをWARアプリケーションといい，J2EEアプリケーションとしてデプロイできます。WARアプリケーションについては，「18.9　WARアプリケーション」を参照してください。

18.3以降で，それぞれの形式のJ2EEアプリケーションのデプロイについて説明します。また，J2EEアプリケーションの実行機能として，J2EEアプリケーションのリデプロイ，J2EEアプリケーションの更新検知とリロードについても説明します。

UNIXの場合，LANG環境変数の設定が，J2EEアプリケーションの開発環境と実行環境で異なると，J2EEサーバの起動時に，java.text.ParseException: Unparseable date例外がスローされることがあります。そのあとのJ2EEサーバの動作には影響ありません。

モジュール化したアプリケーション，およびアプリケーションからのモジュール化したライブラリは使用できません。cjclstartap(Javaアプリケーションの開始)コマンドから，Java EEの機能を使用しないアプリケーションを実行する場合だけ，モジュール化したライブラリを使用できます。

なお，システムの運用を開始したあとでJ2EEアプリケーションの運用中に使用する機能については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.　J2EEアプリケーションの運用」を参照してください。

18.3　アーカイブ形式のJ2EEアプリケーション

この節では，アーカイブ形式によるJ2EEアプリケーションのデプロイについて説明します。

J2EEサーバ上で実行できるアプリケーションの形式の一つに，アーカイブ形式のJ2EEアプリケーションがあります。アーカイブ形式のJ2EEアプリケーションは，EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つアプリケーションです。アーカイブ形式のJ2EEアプリケーションを次の図に示します。

図18‒1　アーカイブ形式のJ2EEアプリケーション

アーカイブ形式のJ2EEアプリケーションでは，アプリケーションの実体はJ2EEサーバ上にあり，J2EEサーバの作業ディレクトリ下にアプリケーションの構成要素を保持します。

通常，アーカイブ形式のJ2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションの停止，新しいJ2EEアプリケーションのインポート，デプロイなどの作業が発生します。このとき，リデプロイ機能を使用すると，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。

リデプロイ機能を使用したJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションの属性情報を引き継ぐことができ，J2EEサーバ上で動作しているJ2EEアプリケーションの停止，新しいJ2EEアプリケーションのインポート，デプロイなどの作業が不要になります。リデプロイ機能については，「18.7　J2EEアプリケーションのリデプロイ」を参照してください。

注意事項

アプリケーションのバージョンがJava EE 5以降の場合，EARファイル内のエントリ名にアプリケーションパッケージのルートよりも上位を指定することはできません。指定した場合は，J2EEアプリケーションのインポート時にKDJE42387-Eのメッセージが出力され，エラーになります。

18.4　展開ディレクトリ形式のJ2EEアプリケーション

この節では，展開ディレクトリ形式によるJ2EEアプリケーションのデプロイについて説明します。

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

表18‒2　この節の構成（展開ディレクトリ形式のJ2EEアプリケーション）

分類

タイトル

参照先

解説

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

18.4.1

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

18.4.2

設定

展開ディレクトリ形式のJ2EEアプリケーションを使用するための設定（セキュリティの設定変更）

18.4.3

注意事項

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

18.4.4

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

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

ここでは，展開ディレクトリ形式の概要，デプロイおよびアンデプロイの方法について説明します。

(1)　展開ディレクトリ形式のJ2EEアプリケーションとは

J2EEサーバ上で実行できるアプリケーションの形式の一つに，展開ディレクトリ形式のJ2EEアプリケーションがあります。展開ディレクトリ形式のJ2EEアプリケーションは，EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つアプリケーションです。アプリケーションディレクトリというルートディレクトリを作成し，アプリケーションディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素が格納されていれば，J2EEアプリケーションとして動作できます。アプリケーションディレクトリについては，「18.4.2　アプリケーションディレクトリの構成」を参照してください。

展開ディレクトリ形式のJ2EEアプリケーションを次の図に示します。

図18‒2　展開ディレクトリ形式のJ2EEアプリケーション

展開ディレクトリ形式のJ2EEアプリケーションが保持するのは，DDとアプリケーションディレクトリへのパス情報です。J2EEサーバの作業ディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素を保持しません。

展開ディレクトリ形式のJ2EEアプリケーションの特長について説明します。

(a)　J2EEアプリケーションの入れ替えの容易化

展開ディレクトリ形式のJ2EEアプリケーションでは，構成要素をEAR形式にアーカイブする必要はありません。このため，アーカイブ形式のJ2EEアプリケーションと比べて，少ない手順でJ2EEアプリケーションの入れ替えができます。

また，リロード機能を使用することで，さらに少ない手順でJ2EEアプリケーションを動的に入れ替えられます。リロード機能では，J2EEアプリケーションを構成するファイルの更新を検知し，更新したJ2EEアプリケーションをリロードします。リロード機能を使用することで，J2EEサーバを再起動することなく，デプロイ済みのサーブレット，JSPやEJB-JARを動的に入れ替えられるようになります。リロード機能については，「18.8　J2EEアプリケーションの更新検知とリロード」を参照してください。

(b)　複数のJ2EEサーバでのアプリケーションディレクトリの共有

展開ディレクトリ形式のJ2EEアプリケーションでは，複数のJ2EEサーバでアプリケーションディレクトリを共有できます。

例えば，アーカイブ形式のJ2EEアプリケーションを使用している場合に，同じ内容のJ2EEアプリケーションを複数のJ2EEサーバで実行させるときは，複数のJ2EEサーバ上に，EARファイル／ZIPファイルをそれぞれ配置する必要があります。また，インポートしたJ2EEアプリケーションを入れ替える場合には，J2EEサーバの数だけ，再インポートや再デプロイが必要になります。

しかし，展開ディレクトリ形式のJ2EEアプリケーションでは，DDとアプリケーションディレクトリへのパス情報だけを保持するため，アプリケーションディレクトリ以下にあるEJB-JAR，Webアプリケーションなどの構成要素を，複数のJ2EEサーバで共有できます。

例えば，J2EEサーバをクラスタ構成で配置している場合にそれぞれのJ2EEサーバで同じJ2EEアプリケーションを使用するときは，同一のディレクトリをアプリケーションディレクトリとして指定できます。同一のアプリケーションディレクトリを参照しているため，J2EEアプリケーションに変更が発生した場合には，そのアプリケーションディレクトリでクラスファイルなどを更新するだけで，すべてのJ2EEアプリケーションの入れ替えができるようになります。アプリケーションディレクトリの共有の例を次の図に示します。

図18‒3　アプリケーションディレクトリの共有の例

なお，J2EEアプリケーションを共有する場合には，それぞれのJ2EEサーバから参照できる環境（共有ディスク装置など）にアプリケーションディレクトリを配置してください。

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

アプリケーションディレクトリは，展開ディレクトリ形式のJ2EEアプリケーションのルートディレクトリです。展開ディレクトリ形式のJ2EEアプリケーションを作成する場合には，アプリケーションディレクトリを作成し，アプリケーションディレクトリ下に，EJB-JAR，Webアプリケーションなどの構成要素を格納します。アプリケーションディレクトリの構成を次の表に示します。

表18‒3　アプリケーションディレクトリの構成

ディレクトリ

ディレクトリの説明

<アプリケーションディレクトリ>

展開ディレクトリ形式のJ2EEアプリケーションのルートディレクトリです。アプリケーションディレクトリの名称は任意です。

META-INF

J2EEアプリケーションのDDおよびcosminexus.xmlの格納ディレクトリです。このディレクトリの直下に，application.xmlおよびcosminexus.xmlが格納されます。

<EJB-JARディレクトリ>

EJBアプリケーションのルートディレクトリです。

META-INF

EJB-JARのDDの格納ディレクトリです。このディレクトリの直下に，ejb-jar.xmlが格納されます。

<パッケージ名>

EJB-JARのクラスファイルやプロパティファイルを格納するディレクトリです。

（例）

MyEJB.class

MyEJBHome.class

MyEJBRemote.class

MyResource.properties

<WARディレクトリ>

Webアプリケーションのルートディレクトリです。

なお，このディレクトリの直下に，JSPファイルが格納されます。

（例）

index.jsp

WEB-INF

WebアプリケーションのDDの格納ディレクトリです。このディレクトリの直下に，web.xmlが格納されます。

classes

サーブレットクラスファイルやプロパティファイルを格納するディレクトリです。

（例）

MyServlet.class

lib

タグライブラリなどのJARファイルを格納するディレクトリです。

（例）

MyTagLibrary.jar

RARファイル※

J2EEアプリケーションで使用するリソースアダプタです。

<ライブラリディレクトリ>

ライブラリJARを格納するディレクトリです。アプリケーションのバージョンがJava EE 5以降の場合，このディレクトリの直下にライブラリJARが格納されます。

注※　リソースアダプタ（RARファイル）をJ2EEアプリケーションに含めて使用する場合に配置します。RARファイルは，アーカイブファイルのまま格納します。リソースアダプタをJ2EEリソースアダプタとしてデプロイする場合は，アプリケーションディレクトリにリソースアダプタを格納する必要はありません。

アプリケーションディレクトリの留意事項を次に示します。

<EJB-JARディレクトリ>，<WARディレクトリ>，およびRARファイルを配置する場合の留意点をapplication.xmlがある場合とapplication.xmlがない場合とに分けて説明します。

application.xmlがある場合には，それぞれapplication.xmlの<module>タグ以下に記述した相対パスに従って作成してください。また，EJB-JARディレクトリとWARディレクトリの名称もapplication.xmlの記述と合わせてください。application.xmlの<module>タグ以下に記述したEAR上の相対パス（EJB-JARファイル名，またはWARファイル名）から拡張子（「.jar」または「.war」）を除いたものが，EJB-JARディレクトリとWARディレクトリの名称になります。

application.xmlがない場合には，ディレクトリ名の最後は「_jar」または「_war」となります。

application.xmlの<module>/<ejb>，<module>/<web>，<module>/<connector>タグの値に（../）を含む相対パスは記述できません。記述した場合エラーになります。

application.xmlの<module>タグ以下で，EJB-JARとWARのモジュールが，「.jar」または「.war」以外の拡張子で宣言されていた場合，アプリケーションのインポートに失敗します。

ライブラリJARの扱われ方は，アプリケーションのバージョンによって異なります。

アプリケーションのバージョンがJ2EE1.4以前の場合

アプリケーションディレクトリ以下のJARファイルのうち，application.xmlの<module>タグ以下で定義していない，拡張子が小文字（.jar）のJARファイルは，ライブラリJARとして扱われます。

アプリケーションのバージョンがJava EE 5以降の場合

サブディレクトリを含まないライブラリディレクトリの直下，またはアプリケーションディレクトリの直下に置かれていて，application.xmlの<module>タグに定義されていないJARファイルがライブラリJARとして扱われます。ライブラリディレクトリには（../）を含むパスの記述はできません。記述した場合はアプリケーションをインポートするタイミングでエラーになります。

アプリケーションディレクトリにないJARを指定する場合は，参照ライブラリを使用します。

アプリケーションディレクトリを変更する場合には，「(2)　アプリケーションディレクトリの変更」に示す規則に従ってください。

(1)　アプリケーションディレクトリの作成例

アプリケーションディレクトリの作成例を次に示します。

ここでは，EJB-JARディレクトリが「subdir/converter」，WARディレクトリが「MyWebApp」，RARファイルが「rardir/DBConnector_DABJ_CP.rar」の場合のアプリケーションディレクトリの構成例，application.xmlの記述例を示します。

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

この例でのアプリケーションディレクトリの構成を次に示します。

application.xmlの記述例

この例でのapplication.xmlを次に示します。

<?xml version="1.0" encoding="Shift_JIS" ?>
<application xmlns="http://java.sun.com/xml/ns/j2ee"
             version="1.4"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                        http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
  <display-name>converter</display-name>
  <module>
    <ejb>subdir/converter.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>MyWebApp.war</web-uri>
      <context-root>/</context-root>
    </web>
  </module>
  <module>
    <connector>rardir/DBConnector_DABJ_CP.rar</connector>
  </module>
</application>

(2)　アプリケーションディレクトリの変更

アプリケーションディレクトリを変更する場合，変更の対象となるディレクトリやファイルの種類と操作の内容によって，変更できなかったり，変更後にアプリケーションの再インポートが必要になったりします。次に，アプリケーションディレクトリを変更した場合に必要となる作業について説明します。

（例）

ディレクトリの削除／名称変更

アプリケーションディレクトリ，EJB-JARディレクトリ，およびWARディレクトリは削除できません。また，ディレクトリ名は変更できません。削除した場合や名称を変更した場合には，アプリケーションを再インポートする必要があります。

JARファイルの追加／変更／削除

ライブラリJARの追加，削除，およびファイル名の変更はできません。ライブラリJAR（application.xmlで宣言していないJARファイル）を追加しても，そのJARファイルは読み込まれません。アプリケーションのインポート時に存在したライブラリJARのファイル名を変更した場合や，ライブラリJARを削除した場合には，アプリケーションを再インポートする必要があります。

なお，WARディレクトリ/WEB-INF/libディレクトリでは，JARファイルの追加／変更／削除はできます。

DDの変更

ユーザがアプリケーションディレクトリに存在するDDを変更しても，J2EEサーバは更新を検知しません。DDの定義を変更する場合，開発環境で定義を変更してからアプリケーションをインポートし直してください。または，サーバ管理コマンドを使用してください。ただし，クラスファイルに記述されたアノテーションまたはcosminexus.xmlは，次回J2EEアプリケーションを開始したときのクラスファイルの再読み込みで，更新を反映させることができます。

なお，サーバ管理コマンド実行時にアプリケーションディレクトリの構成がチェックされます。

アプリケーションディレクトリの変更可否を次の表に示します。

表18‒4　アプリケーションディレクトリの変更可否

対象

ディレクトリおよびファイル

ディレクトリおよびファイルへの操作

アプリケーションの状態

説明

停止

開始

J2EEアプリケーション

アプリケーションディレクトリ

追加

−

−

−

内容変更

−

−

−

名称変更

△

×

アプリケーションの構成変更はできない。

削除

△

×

アプリケーションの構成変更はできない。

application.xml

追加

−

−

−

内容変更

○

×

DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更

−

−

−

削除

△

×

−

cosminexus.xml

追加

◎

○

−

内容変更

◎

○

−

名称変更

−

−

−

削除

◎

○

−

EJBアプリケーション

EJB-JARディレクトリ

追加

△

−

−

内容変更

−

−

−

名称変更

△

×

アプリケーションの構成変更はできない。

削除

△

×

アプリケーションの構成変更はできない。

EJBを構成するクラスファイル

追加

◎

×

クラスを追加したあとで，サーバ管理コマンドで属性を編集する必要がある。

内容変更

◎

×

DDにメソッド情報（container-transactionやmethod-permission）が記述されている場合には，DDの情報と同期を取って修正する必要がある。

名称変更

△

×

クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除

◎

×

クラスを削除したあとで，サーバ管理コマンドで属性を編集する必要がある。

ほかのクラスファイル

追加

◎

×

−

内容変更

◎

×

−

名称変更

△

×

クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除

◎

×

−

ejb-jar.xml

追加

−

−

−

内容変更

○

×

DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更

−

−

−

削除

△

×

−

Webアプリケーション

WARディレクトリ

追加

△

−

−

内容変更

−

−

−

名称変更

△

×

アプリケーションの構成変更はできない。

削除

△

×

アプリケーションの構成変更はできない。

WEB-INF/classes下のクラスファイルやプロパティファイル

追加

◎

×

−

内容変更

◎

×

−

名称変更

−

−

クラスファイルの内容を変更しないでクラスファイル名を変更しようとした場合，次回クラスローダ時にエラーになる。

削除

◎

×

−

WEB-INF/lib下のJARファイル

追加

◎

×

−

内容変更

◎

×

−

名称変更

◎

×

−

削除

◎

×

−

web.xml

追加

−

−

−

内容変更

○

×

DDの直接編集はできない。DDの定義の更新にはサーバ管理コマンドを使用する。※1

名称変更

−

−

−

削除

△

×

−

JSPファイル，

タグファイル，

静的コンテンツ（HTMLやJavaScriptなど），

JSPファイルまたはタグファイルが依存するファイル※2，

JSPコンパイル結果

追加

◎

×

−

内容変更

◎

×

−

名称変更

−

−

−

削除

◎

×

−

ライブラリ

ライブラリJAR

追加

△

×

アプリケーションの構成変更はできない。ライブラリJARを追加しても無視される。

内容変更

◎

×

−

名称変更

△

×

アプリケーションの構成変更はできない。

削除

△

×

アプリケーションの構成変更はできない。

参照ライブラリ

追加

◎

×

サーバ管理コマンド（cjsetappprop）で定義を変更する。

内容変更

◎

×

−

名称変更

−

−

サーバ管理コマンド（cjsetappprop）で定義を変更する。開始状態では変更できない。

削除

○

×

サーバ管理コマンド（cjsetappprop）で定義を変更する。開始状態では削除できない。

参照ライブラリのディレクトリ

追加

◎

×

−

内容変更

◎

×

−

名称変更

◎

×

−

削除

◎

×

−

リソースアダプタ

RARファイル

追加

△

×

−

内容変更

○

×

RARファイルを直接変更できない。サーバ管理コマンドを使用してプロパティを変更する。

名称変更

△

×

−

削除

△

×

−

（凡例）

「アプリケーションの状態」が「停止」の場合

アプリケーションが停止状態の場合，ディレクトリおよびファイルの種類や操作の内容によって，アプリケーションの再インポートの要否が異なります。

◎：再インポートは不要（次回アプリケーション開始時に操作が反映される）。

○：条件を満たす場合には，再インポートは不要。条件は「説明」を参照。

△：再インポートが必要。

−：該当しない。

「アプリケーションの状態」が「開始」の場合

アプリケーションが開始状態でリロード機能が無効の場合，ディレクトリおよびファイルの種類や操作の内容によって，操作を許可するかどうかが異なります。

○：操作できる。

×：操作できない。

−：該当しない。

注※1

DDを変更してもJ2EEサーバは更新を検知しないで，操作は無視されます。

次に示すコマンドを次回，実行したときに上書きされます。

cjsetappprop

cjaddapp（-type filterオプション指定時）

cjdeleteapp（-type filterオプション指定時）

cjrenameapp

cjstartapp

注※2

依存するファイルは，JSPファイルまたはタグファイルのincludeディレクティブでインクルードされるファイルや，web.xmlの<include-prelude>または<include-coda>でインクルードされるファイルのことです。

18.4.3　展開ディレクトリ形式のJ2EEアプリケーションを使用するための設定（セキュリティの設定変更）

ここでは，展開ディレクトリ形式のJ2EEアプリケーションを使用するために必要な設定について説明します。

展開ディレクトリ形式のJ2EEアプリケーションを使用する場合には，次のどちらかの方法でセキュリティの設定を変更することをお勧めします。

SecurityManagerの解除

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

それぞれの方法について説明します。

(1)　SecurityManagerを解除する場合

J2EEサーバを起動するときに，cjstartsvコマンドに-nosecurityオプションを指定し，SecurityManagerを解除します。

# cjstartsv <サーバ名称> -nosecurity

注意事項

SecurityManagerを解除することで，リソースアクセス時の権限チェックのオーバーヘッドを削減できますが，J2EEアプリケーションは任意のリソースへのアクセスができるようになるため，セキュリティが低下します。

(2)　セキュリティポリシーの設定を変更する場合

アプリケーションディレクトリ以下のJARファイルやクラスファイルに，リソースに対するアクセス権を与えるために，server.policyを次のように編集します。

grant codeBase "file:/D:/MyApplicationDir/Web.war/-"{
    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.*";
};

server.policyは，Smart Composer機能のコマンドでシステムを構築したあとに設定してください。

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

展開ディレクトリ形式を使用する場合の注意事項を次に示します。

展開ディレクトリ形式のJ2EEアプリケーションでは，アーカイブ形式のJ2EEアプリケーションと比べて，次の作業ができません。

EJB-JAR／WAR／RARの追加

EJB-JAR／WAR／RARの削除

ライブラリJARの追加

ライブラリJARの削除

展開ディレクトリ形式のJ2EEアプリケーションでこれらの作業を実施したい場合には，次の手順で実施してください。

J2EEサーバから展開ディレクトリ形式のJ2EEアプリケーションを削除します。

アプリケーションディレクトリを修正します。

修正した展開ディレクトリ形式のJ2EEアプリケーションをインポートします。

展開ディレクトリ形式のJ2EEアプリケーションを使用する場合には，J2EEアプリケーションが任意のリソースへアクセスできるように，セキュリティの設定を変更することをお勧めします。セキュリティの設定の変更については，「18.4.3　展開ディレクトリ形式のJ2EEアプリケーションを使用するための設定（セキュリティの設定変更）」を参照してください。

展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合に，アプリケーションディレクトリのパスとしてUNC名を含むパスは指定できません。UNC名を含むパスを指定した場合には，コマンドの実行エラーになります。

J2EEサーバの起動処理中やサーバ管理コマンドの実行中にアプリケーションディレクトリ以下のファイルおよびディレクトリを追加／削除／上書きしないでください。

application.xmlに<alt-dd>タグが指定されているJ2EEアプリケーションは，展開ディレクトリ形式で使用できません。展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合，またはEARファイルや，J2EEサーバからエクスポートしたZIPファイルを展開ディレクトリ形式でインポートする場合に，J2EEアプリケーションのapplication.xmlに<alt-dd>タグが指定されているときは，コマンドの実行エラーになります。

J2EEサーバ内で，複数のJ2EEアプリケーションが同一のディレクトリをアプリケーションディレクトリとして指定することはできません。展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合，またはEARファイルや，J2EEサーバからエクスポートしたZIPファイルを展開ディレクトリ形式でインポートする場合に，指定したディレクトリがすでにほかのJ2EEアプリケーションのアプリケーションディレクトリであるときは，コマンドの実行エラーになります。

次のディレクトリをアプリケーションディレクトリまたはWARディレクトリとして持つJ2EEアプリケーションが，すでにJ2EEサーバ内に存在する場合，インポートでコマンドの実行エラーになります。

cjimportappコマンドの-aオプション，または-dオプションに指定したディレクトリの上位にあるディレクトリ

cjimportappコマンドの-aオプション，または-dオプションに指定したディレクトリの下位にあるディレクトリ

cjimportappコマンドの-aオプションにWindowsのドライブ直下（C:¥など）のディレクトリ，またはUNIXのルートディレクトリ（/）を指定してインポートする場合は，application.xmlファイルの<display-name>タグにアプリケーション名を指定してください。

インポート時に指定したJARファイル名は，作業ディレクトリ中のディレクトリ名として用いられます。作業ディレクトリのパス長がプラットフォームの上限に達しないようにJARファイル名を指定してください。作業ディレクトリのパス長の見積もりについては，マニュアル「アプリケーションサーバシステム構築・運用ガイド」の「付録C.1　J2EEサーバの作業ディレクトリ」を参照してください。

アプリケーションディレクトリ以下にJavaソースファイルを置くような構成は推奨しません。同じディレクトリに置かれているクラスファイルとJavaソースファイルの同期が取れていない場合，アプリケーションの開始やリロードに失敗する場合があります。

次の半角記号はエスケープ文字として扱われるため，アプリケーションディレクトリ名およびモジュール名には指定しないでください。

!　#　%　+

アプリケーションディレクトリ以下に置かれているJARファイルはライブラリJARとして扱われます。このため，アプリケーションディレクトリ以下には，cjgetstubsjarコマンドで取得したスタブおよびインタフェースを置かないでください。

展開ディレクトリ形式のJ2EEアプリケーションをインポートする際，EJB-JARディレクトリとWARディレクトリを除くアプリケーションディレクトリ以下を対象にライブラリJARが検索されます。このため，EJB-JARディレクトリとWARディレクトリを除くアプリケーションディレクトリ以下に多数のファイルがある場合，インポートに時間が掛かることがあります。

アプリケーションの開始時，インポート時に展開されるWARファイル，EJB-JARファイル，またはEARファイルに含まれるエントリの展開後のファイル絶対パスが，それぞれのルートディレクトリ内にない場合，KDJE42389-Eのエラーメッセージを出力して，ファイルの展開処理を中断します。

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

この節では，J2EEアプリケーションのデプロイとアンデプロイについて説明します。

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

表18‒5　この節の構成（J2EEアプリケーションのデプロイとアンデプロイ）

分類

タイトル

参照先

解説

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

18.5.1

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

18.5.2

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

18.5.3

設定

J2EEアプリケーションへのプロパティの設定

18.5.4

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

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

アーカイブ形式のJ2EEアプリケーションのデプロイとアンデプロイについて説明します。

(1)　J2EEアプリケーションのデプロイ

Webアプリケーション，またはEJBアプリケーションをJ2EEサーバで実行するためには，J2EEアプリケーションとしてデプロイする必要があります。J2EEアプリケーションを実行するJ2EEサーバにEARファイルをインポートしてください。

(2)　J2EEアプリケーションのアンデプロイ

アーカイブ形式のJ2EEアプリケーションを削除する場合は，J2EEアプリケーションに対してアンデプロイを実行します。アンデプロイの処理完了後に，J2EEサーバからJ2EEアプリケーションが削除されます。

18.5.2　展開ディレクトリ形式のJ2EEアプリケーションのデプロイとアンデプロイ

展開ディレクトリ形式のJ2EEアプリケーションのデプロイとアンデプロイについて説明します。

(1)　J2EEアプリケーションのデプロイ

展開ディレクトリ形式のJ2EEアプリケーションをJ2EEサーバ内にインポートしてクライアントから実行可能な状態にするためには，デプロイが必要です。J2EEアプリケーションを実行するJ2EEサーバに，展開ディレクトリ形式のJ2EEアプリケーションをインポートしてください。アプリケーション開始時に生成される各クラスローダは，クラスパスとしてアプリケーションディレクトリを保持して動作します。

(2)　J2EEアプリケーションのアンデプロイ

展開ディレクトリ形式のJ2EEアプリケーションを削除する場合は，展開ディレクトリ形式のJ2EEアプリケーションに対してアンデプロイを実行します。アンデプロイの処理完了後に，J2EEサーバへのJ2EEアプリケーションの登録が解除されます。なお，アプリケーションディレクトリは削除されません。

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

EARファイルや，J2EEサーバからエクスポートしたZIPファイルを，展開ディレクトリ形式でJ2EEサーバにインポートできます。この機能を使用することで，作成済みのEARファイル／ZIPファイルを，展開ディレクトリ形式のJ2EEアプリケーションとして動作させることが容易になります。

(1)　EARファイル／ZIPファイルの展開

EARファイル／ZIPファイルの内容を任意のディレクトリに展開して，展開ディレクトリ形式のJ2EEアプリケーションとしてJ2EEサーバにインポートします。EARファイル／ZIPファイルの展開を次の図に示します。

図18‒4　EARファイル／ZIPファイルの展開

インポートするときに，コマンドの引数として，EARファイル／ZIPファイルと，アプリケーションディレクトリとなる展開先のディレクトリを指定します。J2EEサーバは，展開先のディレクトリのパス情報をコマンドから受け取り，そのパス情報を基にアプリケーションディレクトリを生成して，アプリケーションディレクトリ下にEARファイル／ZIPファイルの内容を展開します。

(2)　ディレクトリ名の生成規則

EARファイル／ZIPファイルを展開ディレクトリ形式としてインポートする場合，ディレクトリ名の衝突が発生することがあります。ディレクトリ名の生成規則は，ディレクトリ名の衝突パターンによって異なります。EARファイル／ZIPファイルを展開する場合の，EJB-JARディレクトリとWARディレクトリのディレクトリ名の生成規則を表に示します。

表18‒6　EARファイル／ZIPファイルを展開する場合の，EJB-JARディレクトリとWARディレクトリのディレクトリ名の生成規則

ディレクトリ名の衝突パターン

ディレクトリ名の生成規則

application.xmlがあり，EARファイル内のディレクトリと衝突しない。

EJB-JARファイルとWARファイルから拡張子（「.jar」または「.war」）を除いたものが，EJB-JARディレクトリとWARディレクトリの名称になる。

EJB-JARファイルとWARファイルに拡張子がない場合は，ファイル名がそのままディレクトリ名になる。

EJB-JARファイルとWARファイルで衝突する。

EAR内のディレクトリと衝突する。

EJB-JARファイルとWARファイルの拡張子（「.jar」または「.war」）をそれぞれ「_jar」または「_war」に置き換えたものが，EJB-JARディレクトリとWARディレクトリの名称になる。

「_jar」または「_war」に置き換えても衝突する。

「_jar」または「_war」の後ろに通し番号（1〜2147483647）が付加される。

ディレクトリ名の衝突が発生する場合のEARファイルの構成と，生成されるアプリケーションディレクトリの構成を次の図に示します。

図18‒5　ディレクトリ名の衝突の例

注意事項

cjimportappコマンドの-dオプションを使用してEARファイル／ZIPファイルを展開して作成されたアプリケーションディレクトリが，次に示す条件のどれかに合致する場合，そのアプリケーションディレクトリをcjimportappコマンドの-aオプションでインポートして展開ディレクトリ形式のアプリケーションディレクトリとして使用できません。

EJB-JARのモジュール名が「.jar」で終わっていない。

WARのモジュール名が「.war」で終わっていない。

モジュールの拡張子を除いた名称が，ほかのモジュールの拡張子を除いた名称と重複する。

モジュールの拡張子を除いた名称が，EARファイル内のディレクトリと重複する。

18.5.4　J2EEアプリケーションへのプロパティの設定

J2EEアプリケーションのプロパティ設定には，サーバ管理コマンドを使用します。

なお，ここでは，アーカイブ形式のJ2EEアプリケーション（EAR形式／ZIP形式）や展開ディレクトリ形式のJ2EEアプリケーションが作成済みであることを前提に，J2EEアプリケーションの設定方法について説明します。J2EEアプリケーションは，WTPなどを使用して，アプリケーション開発時に作成しておいてください。アプリケーションの作成については，マニュアル「アプリケーションサーバアプリケーション開発ガイド」の「4.　Eclipseを使用したJ2EEアプリケーションの開発」を参照してください。

参考

サーバ管理コマンドでは，作成済みのEJB-JARファイルやWARファイルから，アーカイブ形式のJ2EEアプリケーションを作成することもできます。サーバ管理コマンドでのアーカイブ形式のJ2EEアプリケーションの作成については，「18.3　アーカイブ形式のJ2EEアプリケーション」を参照してください。

J2EEアプリケーションの設定の流れを次の図に示します。

図18‒6　J2EEアプリケーションの設定の流れ

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

サーバ管理コマンドを使用してJ2EEアプリケーションをインポートします。

cjimportappコマンドを使用して，J2EEアプリケーションをインポートします。

アーカイブ形式のJ2EEアプリケーションをインポートする場合には，-fオプションにEAR形式／ZIP形式のファイルを指定します。

展開ディレクトリ形式のJ2EEアプリケーションをインポートする場合には，-aオプションにアプリケーションディレクトリを指定します。

EAR形式／ZIP形式のファイルを展開ディレクトリ形式でインポートする場合には，-fオプションにEAR形式／ZIP形式のファイルを，-dオプションにアプリケーションディレクトリとなる展開先のディレクトリを指定します。

サーバ管理コマンドを使用してJ2EEアプリケーションにサーブレットフィルタを追加します。

サーブレットフィルタを追加する場合は，WARファイルにフィルタを登録したあと，フィルタのマッピングを定義します。サーブレットフィルタの追加については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.9　フィルタの設定」を参照してください。

サーバ管理コマンドを使用してJ2EEアプリケーションのプロパティを定義します。

cjgetapppropコマンドで各属性ファイルを取得し，ファイル編集後に，cjsetapppropコマンドで編集内容を反映させます。プロパティの設定内容については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.1　J2EEアプリケーションのプロパティ設定の概要」を参照してください。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.3　J2EEアプリケーションで使用するコマンド」を参照してください。属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「3.　J2EEアプリケーションの設定で使用する属性ファイル」を参照してください。

参考

次のような場合，実行時情報を含んだJ2EEアプリケーションをエクスポート・インポートすることで，効率良くJ2EEアプリケーションを設定できます。

開発環境で作成したJ2EEアプリケーションをエクスポートして，運用環境にインポートして使用する場合

運用環境ですでに動いているJ2EEアプリケーションをエクスポートして，増設したJ2EEサーバにインポートして使用する場合

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

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

システムの運用を開始したあとで，J2EEアプリケーションのバージョンアップやメンテナンスを実施するために，J2EEアプリケーションを入れ替えることがあります。

通常，J2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し，新しいJ2EEアプリケーションをインポート，デプロイする必要があります。

通常のJ2EEアプリケーションの入れ替え手順については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.6　J2EEアプリケーションの入れ替え」を参照してください。

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

リデプロイとは，少ない手順で高速にJ2EEアプリケーションを入れ替えられるデプロイ方法です。この節では，リデプロイ機能を使用したJ2EEアプリケーションの入れ替えについて説明します。

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

表18‒7　この節の構成（J2EEアプリケーションのリデプロイ）

分類

タイトル

参照先

解説

リデプロイによるJ2EEアプリケーションの入れ替え

18.7.1

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

18.7.2

注意事項

リデプロイによるJ2EEアプリケーションの入れ替えの注意事項

18.7.3

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

リデプロイ機能を使用したJ2EEアプリケーションの入れ替えでは，J2EEアプリケーションのすべての属性の情報を引き継ぐことができます。リデプロイ機能でのJ2EEアプリケーションの入れ替えは，次のような場合に利用できます。

J2EEアプリケーションのテスト時のロジックの修正による入れ替え

テスト実施中，J2EEアプリケーション内のロジックに問題を発見してJ2EEアプリケーション内のEJB-JARファイルやWARファイルなどを修正した場合に，テスト中のアプリケーションを修正後のJ2EEアプリケーションと入れ替えるときに使用できます。

運用中のJ2EEアプリケーションと開発環境でテストしたJ2EEアプリケーションとの入れ替え

開発環境にあるJ2EEアプリケーションを，すでに運用中のJ2EEアプリケーションと入れ替えるときに使用できます。

ただし，運用環境と開発環境のアプリケーションの構成は同じで，ロジックだけが異なるJ2EEアプリケーションの場合に入れ替えできます。

リデプロイ機能を使用する場合には，通常のJ2EEアプリケーションの入れ替えを実施するときに必要となる，入れ替え前のJ2EEアプリケーションの停止と削除，入れ替えるJ2EEアプリケーションのインポートとデプロイなどの手順が不要になります。このため，通常のJ2EEアプリケーションの入れ替えに比べて，少ない手順で入れ替えができるようになります。

なお，リデプロイ機能を使用したJ2EEアプリケーションの入れ替えができるのは，アーカイブ形式のJ2EEアプリケーションです。展開ディレクトリ形式のJ2EEアプリケーションでは，リデプロイ機能は使用できません。

参考

リデプロイを実行する前に，JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は，Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし，クラスファイルを生成する機能です。あらかじめ，クラスファイルの生成までを実施しておくので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

18.7.1　リデプロイによるJ2EEアプリケーションの入れ替え

ここでは，リデプロイによるJ2EEアプリケーションの入れ替えについて説明します。

リデプロイとは，アーカイブ形式のJ2EEアプリケーションを入れ替える場合に，少ない手順で高速に入れ替えられるデプロイ方法です。ロジックだけを変更したJ2EEアプリケーションを入れ替えたい場合などに利用できます。リデプロイは，サーバ管理コマンドを使用して実行できます。

リデプロイを実行できる条件を次に示します。

リデプロイを実行できる条件

入れ替えられるのは，実行時情報を含まないJ2EEアプリケーションだけです。実行時情報を含むJ2EEアプリケーション（ZIPファイル）はリデプロイできません。

入れ替え前と入れ替え後のJ2EEアプリケーションの構成が同じである必要があります。J2EEアプリケーションに含まれるEJB-JAR，リソースアダプタおよびWARの数が異なったり，それらのファイル名称が異なったりする場合は，リデプロイはできません。また，J2EEアプリケーションの名称も同じである必要があります。

入れ替え前と入れ替え後のJ2EEアプリケーションに含まれるEJB-JAR内のホームインタフェース（ローカル，リモート），コンポーネントインタフェース（ローカル，リモート），ビジネスインタフェース（ローカル，リモート）のメソッド定義，およびアノテーションの値が同じである必要があります。

ランタイム属性だけを引き継ぐ設定をしている場合に，アプリケーション開発環境で設定済みのDDファイル（application.xml，ejb-jar.xml，ra.xmlおよびweb.xml）の定義内容が同じである必要があります。

また，J2EEアプリケーションを入れ替える時に，入れ替え前のJ2EEアプリケーションを別な名称に変更して退避しておくと，名称によるJ2EEアプリケーションの世代管理が実現できます。ここでは，J2EEアプリケーションの名称変更についてもあわせて説明します。

リデプロイでは，入れ替え前のJ2EEアプリケーションの情報を，入れ替え後のJ2EEアプリケーションに引き継げます。デフォルトの設定の場合，入れ替え後のJ2EEアプリケーションには，入れ替え前のJ2EEアプリケーションのすべての属性が引き継がれます。ランタイム属性※だけを引き継ぎたい場合は，オプションを指定してcjreplaceappコマンドを実行する必要があります。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreplaceapp（アプリケーションの入れ替え）」を参照してください。

注※

属性ファイルには，DD(application.xml，ejb-jar.xml，ra.xml，web.xml)の定義と属性ファイル独自の定義が設定できます。属性ファイル独自の定義のことを，ランタイム属性といいます。

注意事項

入れ替えるJ2EEアプリケーションにcosminexus.xmlが含まれている場合，入れ替える前のアプリケーションサーバ独自の定義情報をいったんデフォルト値に戻してから，cosminexus.xmlの定義情報を読み込みます。入れ替えるアプリケーションにcosminexus.xmlが含まれていない場合，入れ替え前のcosminexus.xmlの定義情報を引き継ぎます。

リデプロイを実行するとき，J2EEアプリケーションは開始，停止どちらの状態でもかまいません。開始状態のJ2EEアプリケーションを入れ替えた場合，J2EEアプリケーションは入れ替え後に自動的に開始されます。ただし，プールやキャッシュに格納されていたJ2EEアプリケーション関連のオブジェクトは破棄されます。停止状態のJ2EEアプリケーションを入れ替えた場合は，入れ替え後のJ2EEアプリケーションも停止した状態になります。J2EEアプリケーションの状態とリデプロイの関係については，「18.7.2　J2EEアプリケーションの状態と入れ替え」を参照してください。

ポイント

J2EEアプリケーションが開始されている状態でリデプロイを実行した場合，リデプロイ処理の中でJ2EEアプリケーションは停止され，入れ替え後に再開始されます。このとき，停止処理の実行時間がサーバ管理コマンド（cjreplaceapp）で設定したタイムアウト時間を超過した場合，J2EEアプリケーションの強制停止が実行されます。タイムアウト時間を指定しなかった場合は，デフォルトのタイムアウト時間である60秒を超過すると，強制停止が実行されます。強制停止実行後にさらにタイムアウト時間を超過した場合は，コマンドが異常終了します。

また，入れ替え後にJ2EEアプリケーションを再開始するとき，開始処理の実行時間がサーバ管理コマンド用のusrconf.propertiesのejbserver.rmi.request.timeoutキーに指定したタイムアウト時間を超過した場合も，コマンドが異常終了します。

入れ替え作業の実行形式と実行例を次に示します。

実行形式

cjreplaceapp <J2EEサーバ名> -name <J2EEアプリケーション名> -f <入れ替えるEARファイルのパス>

実行例

cjreplaceapp MyServer -name App1 -f App1.ear

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

リデプロイ機能では，J2EEアプリケーションが開始・停止の状態に関係なく入れ替えできます。

開始状態のアプリケーションを入れ替えた場合，および停止状態のアプリケーションを入れ替えた場合について説明します。

(1)　開始状態のJ2EEアプリケーションを入れ替えた場合

開始状態のJ2EEアプリケーションを入れ替えた場合，入れ替え後のJ2EEアプリケーションも開始状態になります。

開始状態のJ2EEアプリケーションをリデプロイすると，次のような流れで入れ替え処理が実施されます。

J2EEアプリケーションを停止する

J2EEアプリケーションを入れ替える

J2EEアプリケーションを開始する

それぞれの処理については，タイムアウトがあります。

停止時のタイムアウト

J2EEアプリケーションの停止処理の実行時間が，サーバ管理コマンドでタイムアウトとして設定した時間を超えた場合，J2EEアプリケーションは強制停止されます。強制停止を実施後，強制停止で設定したタイムアウト値の時間を超えてもJ2EEアプリケーションが停止しない場合は，サーバ管理コマンドは異常終了します。

タイムアウトの設定については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreplaceapp（アプリケーションの入れ替え）」を参照してください。

なお，タイムアウトの時間には，次に示す順序で，最初に取得できた値が適用されます。

サーバ管理コマンドに設定されたタイムアウト値

デフォルト値（60秒）

入れ替え時および開始時のタイムアウト

入れ替え処理，および開始処理の実行時間でタイムアウト値として設定した時間を超えた場合，サーバ管理コマンドは異常終了します。なお，タイムアウト値は，RMI-IIOP通信のタイムアウトに設定した時間が適用されます。RMI-IIOP通信のタイムアウトについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。

(2)　停止状態のJ2EEアプリケーションを入れ替えた場合

停止状態のJ2EEアプリケーションを入れ替えた場合，入れ替え後のJ2EEアプリケーションも停止状態になります。停止状態のJ2EEアプリケーションのリデプロイでは，アプリケーションの入れ替え処理だけが実施されます。

18.7.3　リデプロイによるJ2EEアプリケーションの入れ替えの注意事項

リデプロイによるJ2EEアプリケーションの入れ替えの注意事項について説明します。

入れ替え処理実行時に，J2EEサーバ上に同じ名称のJ2EEアプリケーションがない場合は，エラーになります。入れ替えはできません。

リデプロイによるJ2EEアプリケーションの入れ替えでは，入れ替え前のJ2EEアプリケーションの実行時情報を，入れ替え後のJ2EEアプリケーション（新しいJ2EEアプリケーション）に引き継ぐため，入れ替え後のJ2EEアプリケーションに実行時情報が含まれていると入れ替えができません。入れ替えをしようとすると，エラー終了します。

デフォルトの設定の場合，入れ替え後のJ2EEアプリケーションには，入れ替え前のJ2EEアプリケーションのすべての属性が引き継がれます。ランタイム属性※だけを引き継ぐ場合は，オプションを指定してcjreplaceappコマンドを実行する必要があります。コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjreplaceapp（アプリケーションの入れ替え）」を参照してください。

J2EEアプリケーションについて，入れ替え前と入れ替え後で次に示す内容に差異があると，入れ替え処理でエラー終了します。

J2EEアプリケーション内のEJB-JARファイルの数，リソースアダプタの数，およびWARの数が異なる。

J2EEアプリケーション内のEJB-JARファイル名，RARファイル名，およびWARファイル名が，入れ替え前と入れ替え後とで異なる。

EJB-JARファイル内のホームインタフェース（ローカル／リモート），コンポーネントインタフェース（ローカル／リモート），およびビジネスインタフェース（ローカル／リモート）のメソッド定義が異なる。

ランタイム属性※だけを引き継ぐ設定をしている場合に，DD（application.xml，ejb-jar.xml，ra.xml，web.xml）の定義が異なる。

設定しているアノテーションの値を変更した。

また，-replaceDDオプションを指定した場合に，DDファイル（application.xml，ejb-jar.xml，ra.xml，web.xml）も入れ替えるときには，さらに次の条件に一致するとエラーとなります。

DDファイル（application.xml，ejb-jar.xml，ra.xml，web.xml）のタグが異なる。

DDファイル（application.xml，ejb-jar.xml，web.xml）が存在しなくなる。または存在しなかったDDファイルが存在するようになる。

開始状態のJ2EEアプリケーションを入れ替えした場合，プールやキャッシュに格納されたJ2EEアプリケーション関連のオブジェクトは破棄されます。

application.xmlのバージョンが1.4以前の場合と，Java EE 5以降の場合とではライブラリJARと判断する条件が異なります。ライブラリJARなどのモジュールの決定規則については「16.4.3　application.xmlがある場合のモジュールの決定規則」を参照してください。

入れ替え後のJ2EEアプリケーションが，cosminexus.xmlを含んでいて，CMP2.0を利用する場合，cjreplaceappコマンドはJ2EEアプリケーションが停止状態の時に実行する必要があります。また，このコマンドを実行したあと，デプロイ前にcjgencmpsqlコマンドを実行する必要があります。

注※

属性ファイルには，DD（application.xml，ejb-jar.xml，ra.xml，web.xml）の定義と属性ファイル独自の定義が設定できます。属性ファイル独自の定義のことをランタイム属性といいます。

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

展開ディレクトリ形式のJ2EEアプリケーションの場合，構成するファイルを更新すると，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，J2EEサーバを再起動することなく，デプロイ済みのサーブレット，JSPやEJB-JARを動的に入れ替えられるようになります。

また，リロード機能を使用する場合には，通常のJ2EEアプリケーションの入れ替えで必要となる，入れ替え前のJ2EEアプリケーションの停止と削除，入れ替えるJ2EEアプリケーションのインポートとデプロイなどの手順が不要になります。このため，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。

リロード機能は，アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合に利用できます。

この節では，J2EEアプリケーションの更新検知とリロードについて説明します。

なお，cosminexus.xmlを含むアプリケーションの場合，J2EEアプリケーションの更新検知とリロードを実行してもcosminexus.xmlの情報は更新されません。

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

表18‒8　この節の構成（J2EEアプリケーションの更新検知とリロード）

分類

タイトル

参照先

解説

J2EEアプリケーションのリロード方法

18.8.1

リロードの適用範囲

18.8.2

リロード時のクラスローダの構成

18.8.3

エラー発生時の動作

18.8.4

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

18.8.5

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

18.8.6

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

18.8.7

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

18.8.8

JSPのリロード

18.8.9

ほかの機能との関係

18.8.10

コマンドによるJ2EEアプリケーションのリロード

18.8.11

設定

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

18.8.12

注意事項

リロードの注意事項および制限事項

18.8.13

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

18.8.1　J2EEアプリケーションのリロード方法

J2EEアプリケーションのリロードには，更新検知によるリロードと，コマンドによるリロードの2種類の方法があります。

(1)　更新検知によるリロード

更新検知によるリロードは，J2EEアプリケーション開発時のテストを支援する機能として利用できます。更新検知によるリロードを次の図に示します。

図18‒7　更新検知によるリロード

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）が更新された場合に，J2EEサーバがJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視し，構成ファイルの更新を検知すると，J2EEアプリケーションのリロードを実行します。J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図18‒8　更新検知によるリロードの処理の流れ

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

J2EEアプリケーションの構成ファイルを更新します。

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。

J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視していて，構成ファイルが更新されると更新を検知します。J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔は，更新検知インターバルとして設定します。更新検知インターバルについては，「18.8.6　J2EEアプリケーションの更新検知インターバル」を参照してください。

更新を検知したあと，更新するファイルをロードします。このとき，ファイルのコピー中にロードが開始されてしまい，ロードに失敗することがあります。これを回避するため，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間を構成ファイル更新用インターバルとして設定しておくことができます。構成ファイル更新用インターバルについては，「18.8.7　J2EEアプリケーションの構成ファイル更新用インターバル」を参照してください。

JSPを更新した場合には，JSPの再コンパイル，またはクラスファイルの監視によって更新が検知されます。JSPのリロードについては，「18.8.9　JSPのリロード」を参照してください。

リクエスト処理を閉塞します。

構成ファイルの更新を検知し，構成ファイル更新用インターバルで指定した時間を経過すると，J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。

EJBアプリケーション（EJB-JAR）の場合

新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。

Webアプリケーション（WAR）の場合

新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。このとき，リロード遅延実行機能を使用すると，リロードの開始処理を遅らせることができます。リロード遅延実行については，「18.8.8(1)　Webアプリケーションのリロード遅延実行」を参照してください。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「18.8.10(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

J2EEアプリケーションの終了処理をします。

リロードを実行するために，J2EEアプリケーションを終了します。終了処理では，次の処理が実施されます。

リロード前のクラスローダにローディングされたサーブレットのインスタンスが破棄されます。サーブレットがdestroyメソッドを実装している場合，destroyメソッドが実行されます。また，JSPファイルから生成されたサーブレットのインスタンスも破棄されます。このとき，JSPファイルがjspDestroyメソッドを実装していると，jspDestroyメソッドが実行されます。

javax.servlet.ServletContextに登録されたオブジェクトは破棄されます。

リロード前のクラスローダにローディングされたEJBのインスタンスが破棄されます。このとき，次のEJBのコールバックメソッドが実行されます。

分類

実行されるメソッド

Stateless Session Beanの場合

ejbRemove

PreDestroy

Stateful Session Beanの場合

ejbRemove

PreDestroy

Entity Beanの場合

unsetEntityContext

Message-driven Beanの場合

ejbRemove

セッション情報をシリアライズし，セッション情報ファイルに出力します。

Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を，リロード後も継続して利用できます。セッション情報の引き継ぎについては，「18.8.8(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ」を参照してください。

J2EEアプリケーション単位のクラスローダを新規に作成します。

J2EEアプリケーションのリロード処理が実行されると，J2EEアプリケーション単位のクラスローダが新たに作成され，リロード後のリクエスト処理で使用されます。

セッション情報ファイルからセッション情報を読み込み，デシリアライズします。

Webアプリケーションをリロードする場合は，セッション情報ファイルに出力されたセッション情報を新しいクラスローダに読み込みます。

セッション情報ファイルを削除します。

J2EEアプリケーションの開始処理をします。

リロード後は，初回アクセス時に更新後のサーブレットのインスタンスが作成され，initメソッドが実行されます。

開始処理では，プールの最小値分のEJBを生成してプーリングします。このとき，次のEJBのコールバックメソッドが実行されます。

分類

実行されるメソッド

Stateless Session Beanの場合

setSessionContext

ejbCreate

PostConstruct

Entity Beanの場合

setEntityContext

Message-driven Beanの場合

setMessageDrivenContext

ejbCreate

リクエストの閉塞を解除し，リクエストの処理を再開します。

3.で実行待ちにしていたリクエストの処理を再開します。

(2)　コマンドによるリロード

コマンドによるリロードは，J2EEアプリケーション開発時のテストを支援する機能，またはシステムの運用時にJ2EEアプリケーションの入れ替えを支援する機能として利用できます。コマンドによるリロードを次の図に示します。

図18‒9　コマンドによるリロード

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJBアプリケーション（EJB-JAR）やWebアプリケーション（WAR）を更新した場合に，ユーザがcjreloadappコマンドを実行します。J2EEサーバは，cjreloadappコマンドを契機にJ2EEアプリケーションの更新を検知し，更新後のEJB-JARやWARを自動的にリロードします。

J2EEアプリケーションの更新からリロードまでの処理の流れを次の図に示します。

図18‒10　コマンドによるリロードの処理の流れ

図中の1.〜4.について説明します。5.以降の手順については，更新検知によるリロードの場合と同じです。5.以降の手順については，「(1)　更新検知によるリロード」を参照してください。

J2EEアプリケーションの構成ファイルを更新します。

展開ディレクトリ形式のJ2EEアプリケーションを構成するEJB-JARやWARを更新します。

cjreloadappコマンドを実行します。

cjreloadappコマンドを契機に，J2EEサーバがJ2EEアプリケーションの構成ファイルの更新を検知します。

リクエスト処理を閉塞します。

J2EEアプリケーションのリロードを実行するためにリクエスト処理を閉塞します。

EJBアプリケーション（EJB-JAR）の場合

新規リクエストが来たらエラーを返します。処理中のリクエストがある場合には，処理を続行します。ただし，Stateless Session Beanの場合は，CTMを使用することで，新規リクエストを実行待ちにできます。

Webアプリケーション（WAR）の場合

新規リクエストが来たら実行待ちになります。処理中のリクエストがある場合には，処理を続行します。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。リロードとJ2EEアプリケーション実行時間の監視との関係については，「18.8.10(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

18.8.2　リロードの適用範囲

リロードの対象として指定できるアプリケーションの種類を次の表に示します。

表18‒9　リロードの対象として指定できるアプリケーションの種類

アプリケーションの種類

適用の有無

制限事項

EJBアプリケーション（EJB-JAR）

Stateless Session Bean

△

リロード中の新規リクエストはエラーになります。なお，CTMを利用している場合は，リロード中の新規リクエストは実行待ちになります。

Stateful Session Bean

△

リロード中の新規リクエストはエラーになります。また，リロードするとアプリケーションの状態が破棄されるため，アプリケーション開始前の状態になります。

Singleton Session Bean

△

リロードするとBeanのインスタンスが破棄され，新しいインスタンスが作り直されるため，インスタンスの状態は保持されません。

Entity Bean

△

リロード中の新規リクエストはエラーになります。

Message-driven Bean

△

Webアプリケーション（WAR）

サーブレット

○

−

JSP

○

−

ライブラリJAR

−

○

−

（凡例）

○：リロードの対象として指定できる

△：リロードの対象として指定できるが，制限事項がある

−：該当しない

リロードの適用範囲は，次の範囲で指定できます。

app：EJBアプリケーション（EJB-JAR）とWebアプリケーション（WAR）をリロードの対象とする。

web：Webアプリケーション（WAR）だけをリロードの対象とする。

jsp：JSPだけをリロードの対象とする。

注　app，web，jspは，usrconf.propertiesのejbserver.deploy.context.reload_scopeキーの指定値です。なお，noneを指定した場合は，リロード機能は無効になります。

appを指定した場合

EJBアプリケーションを更新すると，EJBアプリケーション，サーブレット，およびJSPがリロードされます。

サーブレットを更新するとサーブレットとJSPがリロードされます。

JSPを更新するとJSPがリロードされます。

webを指定した場合

サーブレットを更新するとサーブレットとJSPがリロードされ，JSPを更新するとJSPがリロードされます。

サーブレットがあってJSPがない場合は，サーブレットだけがリロードされます。JSPがあってサーブレットがない場合は，JSPだけがリロードされます。

EJBアプリケーションを更新してもリロードは動作しません。

jspを指定した場合

JSPを更新するとJSPがリロードされます。

EJBアプリケーションまたはサーブレットを更新しても，リロードは動作しません。

なお，リロード機能の有効／無効は，usrconf.propertiesのejbserver.rmi.localinvocation.scopeキーで指定するローカル呼び出し最適化機能の適用範囲と，リロード機能の適用範囲の組み合わせによって決まります。ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応を次の表に示します。

表18‒10　ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応

項目

ejbserver.rmi.localinvocation.scopeキーの値

all

app

none

ローカル呼び出し最適化の範囲

同一J2EEサーバ内となります。

同一アプリケーション内となります。

範囲はありません。

ejbserver.deploy.context.reload_scopeキーの値

app

×※

○

○

web

○

○

○

jsp

○

○

○

none

×

×

×

（凡例）○：リロード機能を使用できる　×：リロード機能を使用できない

注※　設定に誤りがあります。ejbserver.rmi.localinvocation.scope=allの場合にejbserver.deploy.context.reload_scope=appを指定すると，J2EEサーバを起動するときにメッセージが出力されて起動に失敗します。

18.8.3　リロード時のクラスローダの構成

リロード時のクラスローダの構成は，ローカル呼び出し最適化の範囲によって異なります。ローカル呼び出し最適化の範囲とクラスローダの構成の対応を次の表に示します。なお，クラスローダの構成については，「付録B　クラスローダの構成」を参照してください。

表18‒11　ローカル呼び出し最適化の範囲とクラスローダの構成の対応

項目

ejbserver.rmi.localinvocation.scopeキー※の値

all

app

none

ローカル呼び出し最適化の範囲

同一J2EEサーバ内となります。

同一アプリケーション内となります。

範囲はありません。

クラスローダ構成

ローカル呼び出し最適化時のクラスローダ構成になります。

デフォルトのクラスローダ構成になります。

デフォルトのクラスローダ構成になります。

注※　usrconf.propertiesに指定するキーです。

リロード機能では，ApplicationClassLoader以下，またはWebappClassLoader以下のクラスローダを入れ替えます。EJB-JARをリロードする場合，デフォルトのクラスローダ構成で，次のファイルをロードします。

ApplicationClassLoaderでは，J2EEアプリケーションに含まれるEJB-JAR，ライブラリJAR，および参照ライブラリをロードします。

WebappClassLoaderでは，J2EEアプリケーションに含まれるWARをロードします。

JasperLoaderでは，J2EEアプリケーションに含まれるJSPをロードします。

EJB-JARをリロードするためにApplicationClassLoaderを入れ替える場合は，下位にあるWebappClassLoader，およびJasperLoaderも入れ替える必要があります。したがって，EJB-JAR，ライブラリJAR，参照ライブラリをリロードする場合は，WARを含めたリロードになります。

18.8.4　エラー発生時の動作

リロード機能の使用中にエラーが発生した場合の動作を次の表に示します。

表18‒12　リロード機能でのエラー発生時の動作

エラーの内容

結果

リロード中（アプリケーション内で処理しているリクエストがない状態）にリクエストがサーバに来た場合

EJB-JARの場合はクライアントにエラーが返ります。WARの場合，新規リクエストはリロードが完了するまで実行待ちとなります。

リロード中に例外が発生した場合（クラスファイルのロードの失敗を含む）

更新検知は停止しないで，アプリケーションを停止します。更新を検知した場合，停止したJ2EEアプリケーションは再び開始されます。

リロード以外の処理（更新チェック中，構成ファイル更新用インターバル中，リロード遅延実行中）で例外が発生した場合

更新検知は停止しないで，J2EEアプリケーションは開始状態のまま監視を続けます。

J2EEアプリケーションのメソッドがハングアップなどで終了しない場合

J2EEアプリケーション実行時間の監視でメソッドをキャンセルしないとリロードできません。また，cjreloadappコマンドを使用しないとリロードできません。

J2EEアプリケーション実行時間の監視については，「18.8.10(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

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

クラスローダによってロードされるファイルのうち，監視対象のファイルが更新されたときに，J2EEサーバが更新を検知してリロードが実行されます。更新検知の対象となるタイミングは，J2EEアプリケーションの開始時です。

ただし，クラスローダでロードされていないファイルは，更新検知の対象になりません。アプリケーションディレクトリ以下にあってもロードされていないファイルや，アプリケーションディレクトリを使用していないJ2EEアプリケーションのファイルは，更新検知の対象になりません。また，DD（ejb-jar.xml，web.xml）は，更新検知の対象になりません。

また，展開ディレクトリ形式で，更新後のJSPファイルの更新日付が古い場合はJSPの再コンパイルが実行されません。

(1)　更新検知の対象ファイル

更新検知の対象ファイルを次の表に示します。

表18‒13　更新検知の対象ファイル

種別

更新検知の対象ファイル

リロードの適用範囲※1

app

web

jsp

アプリケーションディレクトリ以下のファイル

ライブラリJAR

○

−

−

EJB-JARディレクトリ以下のEJBアプリケーション（EJB-JAR）のファイル

クラスファイル

java.util.ResourceBundleによってロードされたプロパティファイル

○

−

−

WARディレクトリ以下のWebアプリケーション（WAR）のファイル

サーブレット

クラスファイル

JARファイル

java.util.ResourceBundleによってロードされたプロパティファイル

○

○

−

JSP

JSPファイル

○※2

○※2

○※2

タグファイル

タグライブラリ記述子

○※3

○※3

○※3

JSPコンパイル結果

タグファイルコンパイル結果

○※4

○※4

○※4

静的コンテンツ

○※5

○※5

○※5

アプリケーションディレクトリ以外のファイル

参照ライブラリ

○

−

−

（凡例）○：更新検知の対象になる　−：更新検知の対象にならない

注※1　リロードの適用範囲のapp，web，jspは，usrconf.propertiesのejbserver.deploy.context.reload_scopeキーの指定値です。

注※2　JSPの事前コンパイルがされていない状態で，ロード済みの場合に，更新検知の対象になります。

注※3　JSPの事前コンパイルがされていない状態で，ロード済みのJSPファイルまたはタグファイルで使用されている場合に，更新検知の対象になります。

注※4　JSPの事前コンパイルがされている場合に，更新検知の対象になります。

注※5　JSPファイルまたはタグファイルが依存するファイルの場合に，更新検知の対象になります。依存するファイルは，JSPファイルまたはタグファイルのincludeディレクティブでインクルードされるファイルや，web.xmlの<include-prelude>または<include-coda>でインクルードされるファイルのことです。

(2)　更新検知の対象ファイルの例

アプリケーションディレクトリ以下のファイルのうち，更新検知の対象となるファイルの例を次の表に示します。

表18‒14　更新検知の対象ファイルの例

ディレクトリ

ディレクトリ下のファイル

更新検知の対象

<アプリケーションディレクトリ>

ライブラリJAR例：MyLibrary.jar

○

META-INF

J2EEアプリケーションのDD（application.xml）

アプリケーション属性ファイル（cosminexus.xml）

−

<EJB-JARディレクトリ>

−

−

META-INF

EJB-JARのDD（ejb-jar.xml）

−

<パッケージ名>

Enterprise Beanクラス

例：MyEJB.class

○

ホームインタフェースクラス

例：MyEJBHome.class

○

コンポーネントインタフェースクラス

例：MyEJBRemote.class

○

ビジネスインタフェースクラス

例：MyBusiness.class

○

EJBから利用されるクラス

例：MyClass.class

○

java.util.ResourceBundleによってロードされたプロパティファイル

例：MyResource.properties

○

<WARディレクトリ>

JSPファイル

例：MyJsp.jsp

○

静的コンテンツ

例：MyStatic.jspf

○

HTMLファイル

例：MyIndex.html

−

META-INF

−

−

WEB-INF

WebアプリケーションのDD（web.xml）

−

タグライブラリ記述子ファイル

例：MyTaglib.tld

○

Webアプリケーションプロパティファイル（hitachi_web.properties）

−

classes

−

−

<パッケージ名>

java.util.ResourceBundleによってロードされたプロパティファイル

例：MyResource.properties

○

サーブレットクラス

例：MyServlet.class

○

lib

JARファイル

例：MyLibrary.jar

○

tags

タグファイル

例：MyTag.tag

○

<JSPワークディレクトリ>

JSPコンパイル結果

例：MyJsp$jsp.class

○

WEB-INF

tags

タグファイルコンパイル結果

例：MyTag$tag.class

○

<アプリケーションディレクトリ以外のディレクトリ>

参照ライブラリ

例：MyRef.jar

○

（凡例）　○：更新検知の対象になる　−：更新検知の対象にならない

(3)　リロードの対象となる操作

監視対象のファイルを変更した場合に，更新が検知されてリロードが実行されるかどうかは，ファイルへの操作によって異なります。リロードの対象となる操作を次の表に示します。

表18‒15　リロードの対象となる操作

更新検知の対象ファイル

ファイルへの操作

注意点

追加

削除

更新

アプリケーションディレクトリ以下のファイル

ライブラリJAR

×

×

○

アノテーションも読み込まれます。※1

ライブラリJARの名称は変更できません。

ライブラリJARの構成は変更できます。

アプリケーション属性ファイル

×

×

×

リロードを実行する際，cosminexus.xmlの内容が変更または削除されている場合は，定義情報の再読み込みは実施しません。

EJB-JARディレクトリ以下のEJBアプリケーション（EJB-JAR）のファイル

EJBを構成するクラスファイル

×

×

○

アノテーションも読み込まれます。※1

クラス名の変更はできません。

これまで参照していなかったクラスを参照するように更新した場合，参照先のクラスファイルもリロードの対象となります。

ほかのクラスファイル

×

×

○

アノテーションも読み込まれます。※1

これまで参照していなかったクラスを参照するように更新した場合，参照先のクラスファイルもリロードの対象となります。

WARディレクトリ以下のWebアプリケーション（WAR）のファイル

クラスファイル

△

○

○

−

JARファイル

○

○

○

−

プロパティファイル

△

○

○

−

JSPファイル

△

○※2

○※2

−

タグファイル

△

○※2

○※2

JARファイル内にあるタグファイルは除きます。

JSPファイルまたはタグファイルが依存するファイル

△

○※2

○※2

−

静的コンテンツ

△

×

×

リロード機能を使用した場合には，キャッシュが無効になります。

JSPコンパイル結果（JSP，タグファイルをコンパイルして生成されたクラスファイル）

△

○

○

JSPの事前コンパイル機能が有効である必要があります。

アプリケーションディレクトリ以外のファイル

参照ライブラリ

×

×

○

参照ライブラリの名称は変更できません。

参照ライブラリが指すJARファイルの構成およびクラスパス内のファイルの更新はできます。

スタブおよびコンテナ生成クラスの再生成が必要な場合には，再生成されます。

（凡例）

○：リロードが実行される

△：操作はできるが，リロードは実行されない

×：リロードが実行されない

−：該当しない

注※1　更新できるアノテーションと更新できないアノテーションがあります。アノテーションについては，「17.6.1　アノテーションの更新」を参照してください。

注※2　JSPの事前コンパイル機能が有効な場合は，△になります。

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

J2EEサーバは，J2EEアプリケーションの構成ファイルを定期的に監視していて，構成ファイルが更新されると更新を検知します。J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔は，更新検知インターバルとして設定します。更新検知インターバルを次の図に示します。

図18‒11　更新検知インターバル

更新検知インターバルの値を大きくすると，構成ファイルを監視する間隔が長くなり，ファイル更新後のリロードの反映が遅くなります。また，値を小さくすると，リロードの反映が早くなります。

ポイント

更新検知の対象となるファイル数が増えると，更新検知処理のオーバーヘッドが大きくなり，CPU使用率が高くなります。このような場合は，更新検知インターバルを変更することによって，性能への影響が小さくなります。更新検知インターバルの値は大きくすることをお勧めします。

更新検知インターバルは，J2EEアプリケーション，Webアプリケーション，およびJSPでそれぞれ設定できます。設定値の関係を次に示します。

EJBアプリケーションの場合

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）が使用されます。なお，J2EEアプリケーションの更新検知インターバルに0を指定している場合，EJBアプリケーションは更新検知されません。

サーブレットの場合

WebアプリケーションまたはJ2EEアプリケーションの更新検知インターバルが使用されます。優先順位を次に示します。

Webアプリケーションの更新検知インターバル（webserver.context.check_interval）

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）

なお，Webアプリケーションの更新検知インターバルを指定していない場合には，J2EEアプリケーションの更新検知インターバルが使用されます。

また，Webアプリケーションの更新検知インターバルに0を指定している場合，サーブレットは更新検知されません。

JSPの場合

JSPまたはJ2EEアプリケーションの更新検知インターバルが使用されます。優先順位を次に示します。

JSPの更新検知インターバル（webserver.jsp.check_interval）

J2EEアプリケーションの更新検知インターバル（ejbserver.deploy.context.check_interval）

なお，JSPの更新検知インターバルを指定していない場合には，J2EEアプリケーションの更新検知インターバルが使用されます。

また，JSPの更新検知インターバルに0を指定している場合，JSPは更新検知されません。

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

J2EEサーバは，構成ファイルの更新を検知すると処理中のリクエスト数の監視を開始し，処理中のリクエストの処理が完了するとファイルをロードします。ファイルの容量が大きい場合，ネットワークを経由した場合や，ファイルが複数ある場合には，ファイルコピーなどの処理時間が長くなることがあります。このとき，ファイルコピーが完了する前に処理中のリクエストがなくなると，ファイルコピー中にロードが開始されて，ロードに失敗するおそれがあります。これを回避するため，ファイルコピーに掛かる時間を考慮し，コピーが完了してからロードが開始されるように，構成ファイル更新用インターバルを設定しておくことができます。構成ファイル更新用インターバルでは，構成ファイルの更新を検知してから処理中のリクエスト数の監視を開始するまでの時間を設定します。構成ファイル更新用インターバルを次の図に示します。

図18‒12　構成ファイル更新用インターバル

ポイント

構成ファイル更新用インターバルには，実際に掛かるコピー時間にゆとりを持たせた時間を設定することをお勧めします。

複数のファイルを同時に更新する場合は，複数のファイルの更新に掛かる時間を算出して，構成ファイル更新用インターバルを設定してください。

構成ファイル更新用インターバルは，J2EEアプリケーション，Webアプリケーション，およびJSPでそれぞれ設定できます。設定値の関係を次に示します。

EJBアプリケーションの場合

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）が使用されます。

サーブレットの場合

WebアプリケーションまたはJ2EEアプリケーションの構成ファイル更新用インターバルが使用されます。優先順位を次に示します。

Webアプリケーションの構成ファイル更新用インターバル（webserver.context.update.interval）

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）

Webアプリケーションの構成ファイル更新用インターバルを指定していない場合には，J2EEアプリケーションの構成ファイル更新用インターバルが使用されます。

JSPの場合

JSPまたはJ2EEアプリケーションの構成ファイル更新用インターバルが使用されます。優先順位を次に示します。

JSPの構成ファイル更新用インターバル（webserver.jsp.update.interval）

J2EEアプリケーションの構成ファイル更新用インターバル（ejbserver.deploy.context.update.interval）

JSPの構成ファイル更新用インターバルを指定していない場合には，J2EEアプリケーションの構成ファイル更新用インターバルが使用されます。

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

Webアプリケーションをリロードする場合には，リロード遅延実行機能を使用することで，J2EEアプリケーションのサービス停止期間を最小限に抑えることができます。また，Webアプリケーションのリロードでは，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用することができます。ここでは，Webアプリケーションのリロード遅延実行とセッション情報の引き継ぎについて説明します。

(1)　Webアプリケーションのリロード遅延実行

デフォルトでは，構成ファイルの更新を検知すると，次のような手順でリロード処理を実行します。

Webアプリケーションのリクエスト処理を閉塞します。

構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，次のようにリクエストを処理します。

新規リクエスト：実行待ちにします。

処理中のリクエスト：処理を続行します。

処理中のリクエストの処理が完了すると，リロードを実行します。

この場合，処理中のリクエストの処理時間が長くなるほど，新規リクエストの処理開始時間が遅くなり，新規リクエストに対するアプリケーションのサービス停止期間が長くなります。これを回避するために，リロード遅延実行を設定しておくことをお勧めします。リロード遅延実行機能を使用すると，処理中のリクエストの実行待ち時間を減らして，アプリケーションのサービス停止期間を最小限に抑えられます。

リロード遅延実行機能では，この機能を使用するかどうか，およびリロード処理を開始するまでの時間（最大遅延時間）を設定します。リロード遅延実行機能を使用すると，処理中のリクエストの処理が終わるまで，新規リクエストを受け付けることができます。処理中のリクエスト数が0になると，リロード処理を開始して新規リクエストを実行待ちにします。ただし，処理中のリクエスト数が0になるかどうかは，アクセス状況に依存します。リクエストが途切れない場合には，リロード処理を開始できません。このような場合には，構成ファイルの更新を検知してから，新規リクエストを実行待ちにするまでの最大遅延時間を設定します。最大遅延時間を経過すると，それ以降の新規リクエストは実行待ちとなり，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。

リロード遅延実行を設定した場合と設定しない場合の，アプリケーションのサービス停止期間の違いを，次の図に示します。

図18‒13　アプリケーションのサービス停止期間の違い

リロード遅延実行の最大遅延時間を設定している場合には，構成ファイルの更新を検知して構成ファイル更新用インターバルで指定した時間を経過すると，処理中のリクエスト数の監視を開始し，リロード遅延実行の最大遅延時間のカウントを開始します。例えば，最大遅延時間を5分と設定していた場合，アクセス状況によってリロード処理の開始時間が次のように異なります。

最大遅延時間を経過する前に処理中のリクエストが0になった場合

最大遅延時間のカウントを開始してから3分後に，処理中のリクエストが0になった場合には，その時点でリロード処理を開始します。また，新規リクエストを実行待ちにします。

最大遅延時間を経過した場合

リクエストが途切れないため処理中のリクエストが0にならない場合には，最大遅延時間のカウントを開始してから5分後に，新規リクエストを実行待ちにします。処理中のリクエストの処理が完了したら，リロード処理を開始します。

参考

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。J2EEアプリケーション実行時間の監視については，「18.8.10(2)　リロードとJ2EEアプリケーション実行時間の監視との関係」を参照してください。

(2)　Webアプリケーションのリロード時のセッション情報の引き継ぎ

Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用します。

(a)　セッション情報ファイル

Webアプリケーションをリロードする場合，セッション情報（javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクト）をシリアライズし，セッション情報ファイルに出力します。セッション情報ファイルからセッション情報を読み込み，リロード後のクラスローダ上でデシリアライズします。なお，シリアライズ処理，およびデシリアライズ処理の時間は，リロードを実行しているWebアプリケーション上で生成されたセッション数，javax.servlet.http.HttpSessionオブジェクトに登録したオブジェクトの容量などに依存します。

注意事項

シリアライズ対象となるセッションに登録したオブジェクトのクラス，およびそこから参照されるオブジェクトのクラスを，デシリアライズできない構成に更新してリロードを実行した場合，セッションのデシリアライズに失敗します。デシリアライズに失敗すると，Webアプリケーション上のすべてのセッション情報が破棄されます。

セッション情報ファイルは，リロード処理開始時に作成され，リロード処理完了時に削除されます。リロード実行時にセッションが存在しない場合でもセッション情報ファイルは作成されます。

セッション情報ファイルには，Webコンテナが自動生成する情報（2キロバイト）とセッション情報が出力されます。セッション情報は，セッション数とセッションに登録したセッション情報（オブジェクト）に依存します。

セッション情報ファイルのファイル容量は，リロード時に出力されるシリアライズ処理完了のメッセージからファイル容量を確認し，セッション数に応じて算出してください。シリアライズ処理完了時のメッセージの出力例を次に示します。

KDJE39168-I The serialization of session objects has finished. (J2EE application = app1, context root = /examples, number of sessions = 10, session information file size(byte) = 12345)

この出力例では，コンテキストルート名が「examples」のWebアプリケーション「app1」上に10個のセッションがあり，セッション情報ファイルのサイズは，12,345バイトです。

(b)　セッション情報を引き継ぐ場合の注意事項

リロード時のセッション引き継ぎ機能を使用する場合，javax.servlet.http.HttpSessionに登録するセッション情報は，シリアライズできるオブジェクトである必要があります。

HttpSessionオブジェクトに登録したオブジェクトから参照するオブジェクトは，transientで宣言されているか，またはシリアライズできるオブジェクトである必要があります。以降，参照するオブジェクトも同様です。シリアライズできるオブジェクトについての詳細は，J2SEの仕様書を参照してください。

セッション情報としてシリアライズできないオブジェクトを登録した場合は，エラーが発生します。エラーの内容はオブジェクトによって異なります。

javax.servlet.http.HttpSessionに登録したオブジェクトの場合

HttpSessionオブジェクトに登録したオブジェクトが，シリアライズできないオブジェクトである場合，該当するオブジェクトだけを破棄します。破棄されたオブジェクトは，リロードが完了したあとに使用することはできません。また，該当するオブジェクトが，javax.servlet.http. HttpSessionBindingListenerインタフェースを実装していても，Webコンテナからアンバインドされたイベントは通知されません。

javax.servlet.http.HttpSessionに登録したオブジェクトから参照されるオブジェクトの場合

HttpSessionに登録したオブジェクトから参照されるオブジェクトがシリアライズできないオブジェクトの場合，すべてのセッション情報が破棄されます。HttpSessionに登録したオブジェクトから参照されるオブジェクトが，HttpSessionに登録したオブジェクトの場合も同様に，すべてのセッション情報が破棄されます。

18.8.9　JSPのリロード

JSPを更新した場合には，JSPの再コンパイル，またはクラスファイルの監視によって更新が検知され，JSPがリロードされます。JSPのリロード方法を次に示します。

JSPの再コンパイルによるリロード

Webコンテナは，ロードされたJSPファイル，タグファイル，JSPファイルまたはタグファイルが依存するファイルが更新されているかどうかをチェックし，更新日時がロード時と異なる場合には，再コンパイルしてJSPをリロードします。

更新を検知してJSPの構成ファイル更新用インターバルを経過したあとに，ファイルを再コンパイルします。コンパイルが完了し，処理中のリクエストがなくなったことを検知したら，リロード処理を開始します。

クラスファイルの監視によるリロード

Webコンテナは，WebコンテナにロードされたJSPファイルから生成されたクラスファイルが更新されているかどうかをチェックし，更新日時がロード時と異なる場合に，JSPをリロードします。

更新を検知してJSPの構成ファイル更新用インターバルを経過したあとに，処理中のリクエストがなくなったことを検知したら，リロード処理を開始します。

クラスファイルの更新のタイミングは次のどちらかです。

JSP事前コンパイルのコマンドを実行し，JSPファイルをコンパイルしてクラスファイルを生成したとき

JSP事前コンパイルでコンパイルされたクラスファイルを，JSPワークディレクトリにコピーして上書きしたとき

JSPの事前コンパイルについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

JSPのリロード方法の差異を次の表に示します。

表18‒16　JSPのリロード方法の差異

項目

JSPの再コンパイルによるリロードの場合

クラスファイルの監視によるリロードの場合

JSPの事前コンパイル機能使用の有無

JSP事前コンパイル機能は無効となります。

JSP事前コンパイル機能は有効となります。

更新検知の対象ファイル※

JSPファイル

タグファイル

JSPファイルまたはタグファイルが依存するファイル

JSP事前コンパイルで生成されたクラスファイル

更新検知後の処理

ファイルをコンパイルし，リロードします。

クラスファイルをリロードします。

注※　Webコンテナにロードされていないファイル，または更新検知の対象ではないファイルを更新しても検知されません。

どちらのリロード方法の場合でも，ファイルの更新を検知するために，JSPの更新検知インターバルとJSPの構成ファイル更新用インターバルを指定できます。更新検知インターバルについては，「18.8.6　J2EEアプリケーションの更新検知インターバル」を参照してください。構成ファイル更新用インターバルについては，「18.8.7　J2EEアプリケーションの構成ファイル更新用インターバル」を参照してください。

注意事項

ロード済みのJSPの破棄のタイミング，およびJSPのリロード機能の監視対象について

Webアプリケーションのリロード機能とJSPのリロード機能を併用した場合にWebアプリケーションのリロード機能が実行されたとき，ロード済みのJSPが破棄されます。また，JSPのリロード機能の監視対象はWebアプリケーションのリロード機能実行時にロードされたJSPファイルだけになります。

WebコンテナおよびWebアプリケーションの再起動をしたとき，ロード済みのJSPが破棄されます。また，JSPのリロード機能の監視対象はWebアプリケーションの開始後にロードされたJSPファイルだけになります。

18.8.10　ほかの機能との関係

リロード機能と次の機能との関係について説明します。

同時実行スレッド数制御

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

(1)　リロードと同時実行スレッド数制御との関係

Webアプリケーションのリロード機能での新規リクエストの実行待ちと，同時実行スレッド数制御との関係について説明します。なお，同時実行スレッド数の制御については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.13　同時実行スレッド数の制御の概要」を参照してください。

(a)　Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御を使用する場合

リロード機能での新規リクエストの実行待ちは，Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御の実行待ちキューとは，別に制御されます。

Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されている場合

Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されているWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。

リロード機能で実行待ちとなった新規リクエストは，Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されません。それらの実行待ちキューのサイズの上限に関係なく，実行待ちとなります。

Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されたリクエストがある場合は，それらの実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。

リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されます。それらの実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。

Webアプリケーション単位の同時実行スレッド数制御が設定されていない場合

Webアプリケーション単位の同時実行スレッド数制御が設定されていないWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。

リロード機能で実行待ちとなった新規リクエストは，デフォルトの実行待ちキューに登録されません。デフォルトの実行待ちキューサイズの上限に関係なく，実行待ちとなります。

デフォルトの実行待ちキューに登録されたリクエストがある場合は，その実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。

リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，デフォルトの実行待ちキューに登録されます。デフォルトの実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。

(b)　Webコンテナ単位の同時実行スレッド数制御を設定する場合

Webコンテナ単位の同時実行スレッド数制御を設定している場合，リロード処理開始後に，Webコンテナ単位の同時実行スレッド数制御で実行できることになった，新規リクエストの処理スレッドが実行待ちとなります。

このため，リロード機能で実行待ちとなった新規リクエスト数がWebコンテナ単位の最大同時実行スレッド数まで達した場合，リロード処理を開始したWebアプリケーション以外のWebアプリケーションへのリクエストも，Webコンテナ単位の同時実行スレッド数制御機能によって実行待ちとなります。

(2)　リロードとJ2EEアプリケーション実行時間の監視との関係

処理中のリクエストの処理が完了しない場合には，cjreloadappコマンドで-tオプションを指定することで，処理中のリクエストを強制的に終了させて，リロード処理を開始できます。ただし，処理中のリクエストを強制的に終了できるのは，J2EEアプリケーション実行時間の監視機能のメソッドタイムアウトの適用対象メソッドだけです。また，メソッドタイムアウトの発生後にメソッドキャンセルが動作するように設定している場合は，タイムアウトの発生によって処理中のリクエストがキャンセルされて，リロードを開始できます。

J2EEアプリケーション実行時間の監視の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。J2EEアプリケーション実行時間の監視の設定については，「18.8.12　J2EEアプリケーションの更新検知とリロードの設定」を参照してください。

(a)　EJBアプリケーションの場合

EJBアプリケーションをリロードする場合について説明します。

構成ファイル更新用インターバルを経過すると，J2EEサーバは，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図18‒14　メソッドキャンセル機能によるリロード（EJBアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋処理中のリクエストの実行待ち時間（秒）

(b)　Webアプリケーションの場合

Webアプリケーションをリロードする場合について説明します。

リロード遅延実行を設定している場合，指定した最大遅延時間を経過すると，J2EEサーバは，新規リクエストを実行待ちにし，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図18‒15　メソッドキャンセル機能によるリロード（Webアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋リロード遅延実行の最大遅延時間（秒）＋処理中のリクエストの実行待ち時間（秒）

18.8.11　コマンドによるJ2EEアプリケーションのリロード

ここでは，リロードによるJ2EEアプリケーションの入れ替え方法について説明します。

リロードとは，少ない手順で展開ディレクトリ形式のJ2EEアプリケーションの入れ替えを実行できる機能です。リロードによるJ2EEアプリケーションの入れ替えでは，既存のJ2EEアプリケーションの停止，削除，入れ替え後のJ2EEアプリケーションのアーカイブ，インポート，再開などの作業が不要です。クラスファイルを更新してリロードを実行するだけでJ2EEアプリケーションを更新できるため，メンテナンスが頻繁に発生するシステムの運用などで特に有効な機能です。

なお，リロードによるJ2EEアプリケーションの入れ替えを実行するには，事前に設定が必要です。設定方法の詳細については，「18.8.12　J2EEアプリケーションの更新検知とリロードの設定」を参照してください。

リロードによるJ2EEアプリケーションの入れ替えは，サーバ管理コマンド（cjreloadappコマンド）を使用して実行できます。cjreloadappコマンドの詳細については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.5.2　展開ディレクトリ形式のアプリケーション」を参照してください。

リロードは，次の手順で実行します。

メンテナンスの内容に従ってJavaソースファイルを編集，または作成して，クラスファイルにコンパイルします。

J2EEアプリケーションのリロードを実行します。

cjreloadappコマンドを実行します。実行形式と実行例を次に示します。

実行形式

cjreloadapp <J2EEサーバ名> -name <J2EEアプリケーション名>

実行例

cjreloadapp MyServer -name App1

注意事項

リロードに失敗したアプリケーションを削除するには，リロードの成功後，アプリケーションを停止，削除するか，J2EEサーバを再起動したあとにアプリケーションを削除してください。

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

アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。

この項では，展開ディレクトリ形式のJ2EEアプリケーションの更新検知とリロードをするための設定について説明します。コマンドやファイルのキーについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」，およびマニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

展開ディレクトリ形式のJ2EEアプリケーションをリロードするために必要な設定は，構成ファイルの更新を検知してリロードするか，コマンドを実行してリロードするかによって異なります。展開ディレクトリ形式のJ2EEアプリケーションをリロードするために必要な設定を次の表に示します。

表18‒17　リロードするために必要な設定

設定項目

更新検知によるリロードの場合

コマンドによるリロードの場合

リロード機能の適用範囲の設定

○

○

更新検知インターバルの設定

○

−

構成ファイル更新用インターバルの設定

○

−

リロード遅延実行の設定

○

−

セッション情報ファイル格納先ディレクトリの変更

△

△

JSP事前コンパイルの設定

△

△

J2EEアプリケーション実行時間の監視の設定

△

△

（凡例）　○：設定する　△：必要に応じて設定する　−：該当しない

(1)　リロード機能の適用範囲の設定

リロード機能の適用範囲の設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

ejbserver.deploy.context.reload_scope

リロード機能を使用するかどうか，またリロードの対象を指定します。

app：EJBアプリケーション（EJB-JAR）とWebアプリケーション（WAR）をリロードの対象とする。

web：Webアプリケーション（WAR）だけをリロードの対象とする。

jsp：JSPだけをリロードの対象とする。

none：リロード機能を使用しない。

デフォルトの設定では，リロード機能は無効になっています。リロード機能を使用するためには，リロード機能を有効にして，適用範囲を設定する必要があります。

なお，リロード機能の有効／無効は，usrconf.propertiesのejbserver.rmi.localinvocation.scopeパラメタで指定するローカル呼び出し最適化機能の適用範囲と，リロード機能の適用範囲の組み合わせによって決まります。ローカル呼び出し最適化機能の適用範囲とリロード機能の適用範囲の対応については，「18.8.2　リロードの適用範囲」を参照してください。

(2)　更新検知インターバルの設定

更新検知インターバルの設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの更新検知インターバルの設定について次の表に示します。

表18‒18　簡易構築定義ファイルでの更新検知インターバルの設定

指定するパラメタ

設定内容

ejbserver.deploy.context.check_interval

J2EEアプリケーションの構成ファイルを監視して更新を検知する間隔（秒）を指定します。

webserver.context.check_interval

Webアプリケーションの構成ファイルを監視して更新を検知する間隔（秒）を指定します。

webserver.jsp.check_interval

JSPの構成ファイルを監視して更新を検知する間隔（秒）を指定します。

更新検知インターバルの設定値の関係を次に示します。

EJBアプリケーションの場合

ejbserver.deploy.context.check_intervalの値が使用されます。なお，ejbserver.deploy.context.check_intervalに0を指定している場合，EJBアプリケーションは更新検知されません。

サーブレットの場合

webserver.context.check_intervalまたはejbserver.deploy.context.check_intervalの値が使用されます。優先順位を次に示します。

webserver.context.check_intervalの値

ejbserver.deploy.context.check_intervalの値

なお，webserver.context.check_intervalを指定していない場合には，ejbserver.deploy.context.check_intervalの値が使用されます。

また，webserver.context.check_intervalに0を指定している場合，サーブレットは更新検知されません。

JSPの場合

webserver.jsp.check_intervalまたはejbserver.deploy.context.check_intervalの値が使用されます。優先順位を次に示します。

webserver.jsp.check_intervalの値

ejbserver.deploy.context.check_intervalの値

なお，webserver.jsp.check_intervalを指定していない場合には，ejbserver.deploy.context.check_intervalの値が使用されます。

また，webserver.jsp.check_intervalに0を指定している場合，JSPは更新検知されません。

(3)　構成ファイル更新用インターバルの設定

構成ファイル更新用インターバルは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの構成ファイル更新用インターバルの設定について次の表に示します。

表18‒19　簡易構築定義ファイルでの構成ファイル更新用インターバルの設定

指定するパラメタ

設定内容

ejbserver.deploy.context.update.interval

J2EEアプリケーションの構成ファイルのコピーに必要な時間（秒）を指定します。

webserver.context.update.interval

Webアプリケーションの構成ファイルのコピーに必要な時間（秒）を指定します。

webserver.jsp.update.interval

JSPの構成ファイルのコピーに必要な時間（秒）を指定します。

構成ファイル更新用インターバルの設定値の関係を次に示します。

EJBアプリケーションの場合

ejbserver.deploy.context.update.intervalの値が使用されます。

サーブレットの場合

webserver.context.update.intervalまたはejbserver.deploy.context.update.intervalの値が使用されます。優先順位を次に示します。

webserver.context.update.intervalの値

ejbserver.deploy.context.update.intervalの値

webserver.context.update.intervalを指定していない場合には，ejbserver.deploy.context.update.intervalの値が使用されます。

JSPの場合

webserver.jsp.update.intervalまたはejbserver.deploy.context.update.intervalの値が使用されます。優先順位を次に示します。

webserver.jsp.update.intervalの値

ejbserver.deploy.context.update.intervalの値

webserver.jsp.update.intervalを指定していない場合には，ejbserver.deploy.context.update.intervalの値が使用されます。

(4)　リロード遅延実行の設定

リロード遅延実行は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.context.reload_delay_timeout

Webアプリケーションをリロードする場合にリロード遅延実行を使用するかどうかを指定します。また，リロード遅延実行を使用する場合に，リロード処理を開始するまでの時間を設定するときは，最大遅延時間（秒）を指定します。

(5)　セッション情報ファイル出力先の変更

Webアプリケーションをリロードする場合は，リロード実行前に生成したセッション情報を引き継いで，リロード後も継続して利用します。セッション情報は，セッション情報ファイルに出力されます。

セッション情報ファイルの出力先

セッション情報ファイルは，デフォルトでは次の場所に出力されます。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥server¥repository¥<サーバ名>¥web¥<コンテキストルート名>¥cjwebsession.dat

UNIXの場合

/opt/Cosminexus/CC/server/repository/<サーバ名>/web/<コンテキストルート名>/cjwebsession.dat

Webアプリケーション単位のディレクトリ名

Webアプリケーション単位のディレクトリは，コンテキストルート名を基に規則に従ったディレクトリ名となります。コンテキストルート名にスラッシュ（/），ドル記号（$），パーセント（%），プラス記号（+）が含まれる場合は，次に示す文字に変換します。

変換前の文字

変換後の文字

/

$2f

$

$24

%

$25

+

$2b

出力先となるコンテキストルート名のディレクトリは，Webアプリケーションの開始時に作成されます。ただし，コンテキストルートがルートコンテキストの場合は，出力先ディレクトリのコンテキストルートは「$2f」として作成されます。作成されたディレクトリは，Webアプリケーションの終了時に削除されます。

セッション情報ファイルの出力先を変更する場合には，簡易構築定義ファイルで設定します。論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタを設定します。

ejbserver.deploy.session.work.directory

Webアプリケーションのセッション情報ファイルの出力先を指定します。

ejbserver.deploy.session.work.directoryパラメタで指定したディレクトリ下に，「web¥<コンテキストルート名>」というディレクトリが作成されて，そのディレクトリ下にセッション情報ファイルが出力されます。

（例）セッション情報ファイルの出力先の設定例

<configuration>
  <logical-server-type>j2ee-server</logical-server-type>
  <param>
    <param-name>ejbserver.deploy.session.work.directory</param-name>
    <param-value>C:¥tmp¥session_work</param-value>
  </param>
  ：
</configuration>

この設定例の場合，コンテキストルート名が「examples」のWebアプリケーションのセッション情報ファイルは，次の場所に出力されます。

C:¥tmp¥session_work¥web¥examples¥cjwebsession.dat

(6)　JSP事前コンパイルの設定

JSP事前コンパイルでJSPファイルから生成されたクラスファイルを更新した場合も，J2EEアプリケーションの構成ファイルの更新を検知し，リロードが実行されます。

cjstartappコマンドに-jspcオプションを指定してJSP事前コンパイルを実行する場合には，usrconf.propertiesでJSPワークディレクトリなどを設定しておく必要があります。JSP事前コンパイルの設定については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「2.5.8　実行環境での設定（J2EEサーバの設定）」を参照してください。

なお，アプリケーション開発時にcjjspcコマンドを使用してJSP事前コンパイルを実行する場合には，JSPワークディレクトリなどはコマンドのオプションで指定します。cjjspcコマンドを使用したJSPの事前コンパイルについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「2.5　JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

(7)　J2EEアプリケーション実行時間の監視の設定

構成ファイルの更新を検知した場合，処理中のリクエストの処理が完了するとリロード処理を開始しますが，処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実施することで，リロード処理を開始できます。

必要に応じて，J2EEアプリケーション実行時間の監視を設定してください。J2EEアプリケーション実行時間の監視の設定については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.9　実行環境での設定」を参照してください。

18.8.13　リロードの注意事項および制限事項

リロードに関する注意事項および制限事項を次に示します。

(1)　リロード機能の使用に関する注意事項

J2EEアプリケーションの削除について

リロードに失敗しているJ2EEアプリケーションを削除する場合は，次のどちらかの方法で削除してください。

更新検知によるリロード，またはcjreloadappコマンドによるリロードを再度実行してください。リロードが成功したら，J2EEアプリケーションを停止して削除してください。

J2EEサーバを再起動したあとで，J2EEアプリケーションを削除してください。

削除後，J2EEアプリケーションを再インポートしてください。

メモリ不足の発生について

リロード処理では，クラスローダを再作成してクラスをロードし直すため，メモリを多く消費します（消費するメモリ使用量は，J2EEアプリケーションの実装に依存します）。このため，例えば，複数のWebアプリケーションで同時にリロード処理を繰り返すとメモリ不足が発生する可能性があります。また，リロード処理によって不要となったリソースがJavaVMから解放されるタイミングは，JavaVMのGCの実行タイミングに依存します。リクエストのピーク時など，負荷が高いときにリロードを繰り返すと，GCを実行するタイミングがなく，メモリ不足が発生する可能性が高くなります。

このため，リクエストのピーク時など負荷が高い場合には，リソースの更新は避けてください。

Metaspace領域のメモリサイズについて

リロードを使用する場合，Metaspace領域に空きがない状態で新しいクラスをロードしようとすると，java.lang.OutOfMemoryErrorが発生します。そのため，リロード実行前に，Metaspace領域に更新するアプリケーションが使用するサイズ以上の空き領域が確保されていることを確認する必要があります。十分な空き領域がない場合は，Metaspace領域が不足しているおそれがあるので，Metaspace領域の最大値を再設定してください。

リロード実行時には，アプリケーションのクラスローダを破棄し，新しいクラスローダを生成します。そのとき，JavaVMの仕様とクラスローダの実装によって，破棄されたクラスローダは直ちに解放されないことがあります。その結果，リロード実行後は一時的にアプリケーションが必要とするサイズ以上にMetaspace領域が占有されます。そのため，リロード機能が必要とするMetaspace領域は，アプリケーションが必要とするMetaspace領域の3倍程度に見積もることをお勧めします。

Metaspace領域の見積り式を次に示します。

A＝B＋C＋（D×3）＋G

A：J2EEサーバが必要とするMetaspace領域

B：コンテナが必要とするMetaspace領域（120メガバイト）

C：コンテナ拡張ライブラリが必要とするMetaspace領域

コンテナ拡張ライブラリに含まれるclassファイルのサイズの和となります。

G：JDK提供のclassファイルのサイズ（90メガバイト）

D：アプリケーションが必要とするMetaspace領域

クラスローダにロードされたクラスのclassファイルのサイズとなります。ただし，JARファイルに圧縮されているclassファイルは，解凍後のサイズで見積もる必要があります。また，アプリケーションにJSPが含まれている場合，JSP事前コンパイルを実行してclassファイルを作成し，サイズを見積もる必要があります。見積もり式を次に示します。

D＝E＋F＋H

・E：コンテナが作成するクラスのMetaspace領域（アプリケーション開始後のMetaspace領域−アプリケーション登録前のMetaspace領域）。実際にJ2EEサーバを起動し，Metaspace領域を確認して算出してください。

・F：作成したJ2EEアプリケーションのclassファイルのサイズ（J2EEアプリケーションを構成するclassファイルのサイズ＋JARに含まれるclassファイルのサイズ＋JSP事前コンパイルによって作成されたclassファイルのサイズ）

・H：ライブラリJAR，参照ライブラリを利用している場合に追加するJARファイルに含まれるclassファイルのサイズ

Metaspace領域の見積り例と変更例

各Metaspace領域のメモリサイズが次の表に示す値の場合に，Metaspace領域の最大値を変更する例を示します。

見積もり対象となるMetaspace領域

メモリサイズ（単位：メガバイト）

コンテナが必要とするMetaspace領域

120

追加するJARファイルが必要とするMetaspace領域

16

アプリケーションが必要とするMetaspace領域

32

JDK提供のclassファイルのサイズ

90

この例では，J2EEサーバが必要とするMetaspace領域は，次の式で算出します。

120＋16＋（32×3）＋90＝322（メガバイト）

したがって，リロード機能を使用する場合は，割り当てるMetaspace領域の最大値のデフォルト（128m）を，usrconf.cfgのadd.jvm.argキーで次のように変更する必要があります。

add.jvm.arg=-XX:MaxMetaspaceSize=322m

Metaspace領域の確認方法

Metaspace領域のメモリサイズは，JavaVMログファイルを出力するか，またはリソース枯渇監視機能を使用するか，どちらかの方法で確認してください。

メソッドキャンセルの実行について

処理中のリクエストの処理が完了しない場合には，J2EEアプリケーション実行時間の監視のメソッドタイムアウトおよびメソッドキャンセルを実行することで，リロード処理を開始できます。メソッドキャンセルを実行しても，処理をキャンセルできない場合には，J2EEサーバを再起動してください。

実行待ちとなっているリクエスト処理の再開について

J2EEアプリケーションのリロードでEJBアプリケーションの開始，または停止に失敗した場合，Webアプリケーションのリロード処理開始以降の新規リクエストは実行待ちとなります。実行待ちとなっているリクエスト処理を再開するためには，EJBアプリケーションを更新してリロードを実行し，リロード処理を成功させてください。Webアプリケーションを更新しても，リロードは実行されません。

J2EEアプリケーションに含まれるRARファイルについて

アプリケーションディレクトリにRARファイルを含めている場合，RARファイルはリロード機能の対象にはなりません。RARファイルを更新した場合は，更新したRARファイルを含むJ2EEアプリケーションを，サーバ管理コマンドを使用して入れ替えてください。サーバ管理コマンドを使用してJ2EEアプリケーションを入れ替える手順については，マニュアル「アプリケーションサーバ機能解説 運用／監視／連携編」の「5.6　J2EEアプリケーションの入れ替え」を参照してください。

CDI機能を使用したJ2EEアプリケーションのリロードについて

J2EEアプリケーション内のコンポーネント（EJB-JAR，ライブラリJAR，WAR）にCDIの機能を含む場合，更新検知によるリロードはできません。リロードを実行するには，cjreloadappコマンドを使用してください。更新検知によるリロードが有効な設定の場合，CDIの機能を使用したJ2EEアプリケーションの開始時にKDJE42393-Wが出力され，更新検知によるリロードが無効であることが通知されます。

CDIの機能を使用したJ2EEアプリケーションをリロードするには，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，ejbserver.deploy.context.reload_scopeパラメタに「app」を設定してください。リロードを実行すると，更新したファイルがWARファイルまたはJSPファイルの場合でも，J2EEアプリケーションすべてがリロードされます（WAR単位，またはJSP単位でのリロードはできません）。このとき，更新したファイルがWARファイルまたはJSPファイルの場合，KDJE42395-Iが出力され，J2EEアプリケーションすべてがリロードされることが通知されます。

CDIの機能を使用したJ2EEアプリケーションに対してcjreloadappコマンドを実行してリロードした際に，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で，ejbserver.deploy.context.reload_scopeパラメタに「web」または「jsp」を指定していた場合は，KDJE42394-Eが出力され，リロードに失敗します。

CDIの機能を使用したJ2EEアプリケーションに，cjreloadappコマンドを実行してリロードした場合の実行結果を次の表に示します。

表18‒20　cjreloadappコマンドの実行結果（CDIの機能を使用したJ2EEアプリケーション）

更新したファイルを含むコンポーネント

ejbserver.deploy.context.reload.scopeパラメタの値

cjreloadappコマンドの実行結果

EJB-JARまたはライブラリJAR

app

J2EEアプリケーションすべてがリロードされる。

web

KDJE42394-Eが出力され，コマンドの実行に失敗する。

jsp

WAR

app

KDJE42395-Iが出力され，J2EEアプリケーションすべてがリロードされる。

web

KDJE42394-Eが出力され，コマンドの実行に失敗する。

jsp

JSP

app

KDJE42395-Iが出力され，J2EEアプリケーションすべてがリロードされる。

web

KDJE42394-Eが出力され，コマンドの実行に失敗する。

jsp

Inboundリソースアダプタについて

アプリケーションのリロード中は，Inboundリソースアダプタからメッセージを送信しないでください。

Message-driven Beanのリロードについて

TP1インバウンド連携機能使用時にMessage-driven Beanをリロードする場合は，OpenTP1からのRPCの発行を止めてからリロードしてください。リロード中にRPCを発行した場合は，Message-driven Beanは終了していると見なされ，RPCの発行元にはエラー応答が返ります。

(2)　EJBアプリケーション（EJB-JAR）の注意事項

リロード後にEJBを呼び出す場合には，クライアント側のソースコードでEJBHomeやビジネスインタフェースを取得し直す必要があります。リロード前に取得したインタフェース経由でEJBにアクセスした場合は例外が返ります。また，リロード実行中にEJBにアクセスした場合も例外が返ります。

リモートインタフェースまたはリモートビジネスインタフェースを入れ替えた場合，クライアント側ではスタブを取得し直す必要があります。

リロードを実行すると，Stateful Session Beanのクライアントとのセッションの状態は失われます。

非同期メソッドを展開ディレクトリ形式のJ2EEアプリケーションでリロード機能を使用する場合，次の点に注意してください

非同期メソッドが実行中の場合，非同期メソッドの処理が完了するまで，リロード処理は待機します。

リロード処理では，クリーンアップ処理が実行されるため，リロード処理前に取得したFuture<V>オブジェクトによる操作は実行できなくなります。

Singleton Session Beanを含む展開ディレクトリ形式のJ2EEアプリケーションをリロードする場合，次の点に注意してください。

@Startupアノテーションが指定されたSingleton Session Beanは，アプリケーション開始時と同様に，リロード時にも初期化処理が実行されます。

リロード処理の間，リロード対象のJ2EEアプリケーション内のSingleton Session Beanのインスタンスはコンテナによって破棄されます。

@DependsOnアノテーションの定義によって，リロードするSingleton Session Beanの依存関係を変更できます。ただし，循環依存があった場合も，リロード処理ではエラーになりません。このため，リロードの対象となるSingleton Session Beanでは，循環依存を避けるため，@DependsOnアノテーションの使用を避けることをお勧めします。@DependsOnアノテーションを使用して，循環依存があった場合，動作は保証されません。

Writeロックを取得待ちの状態のスレッドの処理は，リロード処理によって中断されません。

(3)　EJBアプリケーション（EJB-JAR）の制限事項

これまでjavax.ejb.TimedObjectインタフェースを実装していなかったEJBで，javax.ejb.TimedObjectインタフェースを実装するように変更して，リロードすることはできません。リロードした場合には，次のようになります。

更新検知スレッドは停止させないで，J2EEアプリケーションを停止します。

更新を検知した場合，停止したJ2EEアプリケーションは再び開始されます。

CMRを使用したアプリケーションはリロードできません。

Singleton Session Beanの@DependsOnアノテーションの設定値を変更してリロードした場合，設定された依存関係が循環関係になっているときはリロードできません。

(4)　Webアプリケーション（WAR）の注意事項

タグライブラリ記述子ファイルのlistenerタグの変更内容は，リロード後に反映されません。

リロード時に利用できるサーブレットとJSPは，リロード後も状態を継続して利用できます。永久的に利用できないとされている場合は，リロード後も永久的に利用できません。一時的に利用できない場合は，リロードの実行とは関係なく，指定した期間後に利用できるようになります。

Webアプリケーションでリロード監視対象になっているファイルを削除した場合，そのファイルは監視対象外となります。このため，再度ファイルを追加しても更新検知によるリロードは実行されません。ただし，/WEB-INF/lib下にJARファイルを追加した場合は，そのJARファイルが削除後に再度追加されたかどうかに関係なく，コマンドによるリロードまたは更新検知によるリロードを実行できます。

JSPのリロード処理中にJ2EEアプリケーションを停止した場合，またはWebアプリケーションをリロードした場合，JSPのリロード処理は中止されます。

JSPのリロード処理開始時，ログの出力レベルがErrorの場合は，メッセージKDJE39310-Iに，更新されたファイル名とリロードを実行するJSPファイルのファイル数が出力されます。ログの出力レベルがWarningの場合は，メッセージKDJE39312-Iに，リロードを実行するすべてのJSPファイル名が出力されます。

リスナクラスのロード，インスタンス生成時に例外が発生した場合，Webコンテナは例外が発生したリスナを無効としてリロード処理を続行します。例外が発生したリスナを有効にするには，該当のリスナを修正して再度リロードを実行してください。

フィルタクラスのロード，インスタンス生成，initメソッド実行で例外が発生した場合，Webコンテナは例外が発生したフィルタを無効としてリロード処理を続行します。例外が発生したフィルタを有効にするには，該当のフィルタを修正して再度リロードを実行してください。

Webアプリケーションのリロード処理を実行すると，次の表に示すリスナインタフェースのメソッドが実行されます。

表18‒21　Webアプリケーションのリロード処理で実行されるリスナのメソッド

インタフェース名

メソッド名

javax.servlet.ServletContextListener

contextDestroyed()

contextInitialized()

javax.servlet.ServletContextAttributeListener

attributeRemoved()

attributeAdded()

javax.servlet.http.HttpSessionActivationListener※

sessionWillPassivate()

sessionDidActivate()

注※　javax.servlet.http.HttpSessionオブジェクトが存在しないときは実行しません。

リロード処理時間は，Webアプリケーションの実装に大きく依存します。このため，次の点に注意が必要です。

セッション情報の容量は，シリアライズ処理時間，デシリアライズ処理時間に大きく影響します。シリアライズ対象となるセッション情報は，必要十分な容量にしてください。

リロード処理では，Webアプリケーションの終了処理，初期化処理が実行されます。終了処理，初期化処理が長い場合，リロードの処理時間も長くなり，Webアプリケーションのサービス停止期間にも影響があるため注意してください。ただし，リロード処理で初期化処理が実行されるのは，web.xmlの<load-on-startup>タグを設定したサーブレットやJSPだけです。<load-on-startup>タグを設定していないサーブレットやJSPの初期化処理は，リロード完了後の初回アクセス時に実行されます。

Webアプリケーションのリロード機能は，Webアプリケーション単位のクラスローダを入れ替えることによって，サーバ起動中のWebアプリケーションの入れ替えを実現しています。そのため，リロード後にリロード前のWebアプリケーション単位のクラスローダ，またはWebアプリケーション単位のクラスローダでロードされたクラスが参照されるとメモリリークが発生します。

次に，該当する場合を示します。リロード機能を使用する場合は，Webアプリケーション内でこれらのことをしないでください。

スレッドの生成

スレッドはコンテキストクラスローダを保持しますが，デフォルトでは親スレッドのコンテキストクラスローダを保持します。Webアプリケーション実行時のスレッドは，Webアプリケーション単位のクラスローダをコンテキストクラスローダとしているため，生成されたスレッドはWebアプリケーション単位のクラスローダをコンテキストクラスローダとします。そのため，リロード後も該当スレッドが存在すると，リロード前のWebアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

java.lang.Threadクラスまたはその派生クラスのインスタンス生成

java.lang.Threadクラスまたはその派生クラス（以降，スレッドクラス）のインスタンスを作成すると，所属するスレッドグループから該当スレッドクラスのインスタンスが参照されます。スレッドグループからの参照は，スレッドの実行を終了（runメソッドの完了）すると解放されます。そのため，Webアプリケーション内でスレッドクラスのインスタンスを生成し，runメソッドを実行しなかった場合は，該当スレッドクラスのインスタンスが解放されません。また，スレッドはコンテキストクラスローダとしてWebアプリケーション単位のクラスローダを保持しているため，Webアプリケーション単位のクラスローダが解放されないでメモリリークが発生します。

スレッドローカル変数の使用

Webコンテナではリクエストを処理するスレッドはプールされていて，Webコンテナ終了時まで終了しません。そのため，スレッドローカル変数にWebアプリケーションに含まれるクラスのインスタンスを格納すると，メモリリークが発生します。

JSP事前コンパイル機能を使用している場合，JSPファイルまたはタグファイルが依存するファイルは更新検知対象となったあと，次のどれかの条件を満たすときに更新検知対象から除外されます。

JSPファイルまたはタグファイルを，依存するファイルを使用しないように変更したクラスファイルに更新し，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

JSPファイルまたはJSPファイルが依存するファイルから生成されたクラスファイルを更新し，JSPファイルから生成されたクラスのロードでエラーが発生した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

該当するファイルが更新検知対象から除外された場合，メッセージログにKDJE39319-Iが出力されます。

なお，cjjspcコマンドを実行すると依存するファイルを使用しているJSPファイルまたはタグファイルも再度コンパイルされます。クラスファイルを展開ディレクトリ以外で作成したあとに更新する場合は，cjjspcコマンドで生成されたクラスファイルをすべて更新してください。

JSP事前コンパイル機能を使用していない場合，JSPファイルまたはタグファイルが依存するファイルは更新検知対象となったあと，次のどれかの条件を満たすときに更新検知対象から除外されます。

JSPファイルまたはタグファイルを，依存するファイルを使用しないように修正し，コンパイルが正常に完了した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

JSPファイル，またはJSPファイルが依存するファイルを更新し，JSPファイルのコンパイルエラーが発生した際，依存するファイルを使用するJSPファイルまたはタグファイルがほかにはない場合

該当するファイルが更新検知対象から除外された場合，メッセージログにKDJE39318-Iが出力されます。また，JSPファイルのコンパイルエラーが発生し，かつ次の条件を満たすときは，更新検知対象から除外されたファイルだけを修正することで，コンパイルエラーとなったJSPファイルを修正しないで，JSPのリロードを実行できます。

依存するファイルがタグファイルの場合

タグファイルの記述内容とタグファイルを使用するファイルの記述内容が矛盾している。タグファイルの次の属性のどれかが不正である。

tagディレクティブに定義した属性：body-content，またはdynamic-attributes

attributeディレクティブに定義した属性：name，required，fragment，rtexprvalue，またはtype

variableディレクティブに定義した属性：name-given，variable-class，declare，またはscope

依存するファイルがweb.xmlの<include-prelude>，または<include-coda>に指定した暗黙的にincludeされるファイルの場合

暗黙的にincludeされたファイルの記述内容が，includeするJSPファイルの記述内容と矛盾している。

依存するファイルがincludeディレクティブに指定したファイルの場合

includeディレクティブに指定されたファイルの記述内容が，includeディレクティブを指定したJSPファイルまたはタグファイルの内容と矛盾している。

依存するファイルがタグライブラリ・ディスクリプタ（TLD）ファイルの場合

TLDファイルの記述内容とJSPファイルの記述内容が矛盾している。

この場合，該当するファイルは更新検知の対象外となっているため，依存するファイルを更新したあと，次のどれかを実行しJSPのリロードを実行する必要があります。

依存するファイルを使用するJSPファイルにブラウザなどからアクセスする。

依存するファイルを使用するJSPファイルまたはタグファイルの更新日時を更新する。

implicit.tldは更新検知対象ファイルではありません。implicit.tldとは，Servlet2.5仕様で定義されたタグファイルのバージョンを示すTLDファイルです。implicit.tldはJSP，またはタグファイルのリロード時に同時に再読み込みされます。

Webアプリケーションのリロードでは，アノテーション情報は読み込みません。Webアプリケーションのクラスに定義したアノテーション情報だけを更新した場合，その更新情報を反映するには，J2EEアプリケーションをいったん停止して再度開始してください。

18.9　WARアプリケーション

J2EEサーバでは，WARファイルまたはWARディレクトリを指定してインポートできます。インポートしたアプリケーションをWARアプリケーションといいます。WARアプリケーションはJ2EEアプリケーションとしてデプロイできます。

WARアプリケーションの機能と参照先を次の表に示します。

表18‒22　この節の構成（WARアプリケーション）

機能

参照先

WARアプリケーション操作コマンドのサポート範囲

18.9.1

実行できるWARアプリケーションの形式

18.9.2

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

18.9.3

WARアプリケーションのアプリケーション名

18.9.4

コンテキストルートの決定

18.9.5

cosminexus.xmlファイルの読み込み

18.9.6

18.9.1　WARアプリケーション操作コマンドのサポート範囲

J2EEアプリケーションに対して実行できる操作コマンドのうち，WARアプリケーションで実行できる操作コマンドには制限があります。

WARアプリケーションに対する操作コマンドのサポート範囲を次の表に示します。

表18‒23　WARアプリケーションに対する操作コマンドのサポート範囲

操作コマンド

サポート有無

実行結果

cjaddapp

×

KDJE42400-Eのメッセージが出力されます。

cjchmodapp

×

KDJE42400-Eのメッセージが出力されます。

cjdeleteapp

△

-type war，または-type filterを指定してコマンドを実行した場合，KDJE42401-Eのメッセージが出力されます。そのほかの場合は，J2EEアプリケーションに対して実行した場合と同じです。

cjdeletelibjar

×

−

cjexportapp

×

KDJE42400-Eのメッセージが出力されます。

cjgencmpsql

×

−

cjgetappprop

○

J2EEアプリケーションに対して実行したときと同じ。

cjgetstubsjar

×

−

cjimportapp

×

−

cjimportwar

○

WARディレクトリまたはWARファイルをインポートします。

cjimportlibjar

×

KDJE42400-Eのメッセージが出力されます。

cjlistapp

○

WARアプリケーションの場合，コンテキストルートが表示されます。

cjreloadapp

○

J2EEアプリケーションに対して実行したときと同じ。

cjrenameapp

×

KDJE42400-Eのメッセージが出力されます。

cjreplaceapp

△

cosminexus.xmlの再読み込みができません※。

cjsetappprop

○

J2EEアプリケーションに対して実行したときと同じ。

cjstartapp

○

J2EEアプリケーションに対して実行したときと同じ。

cjstopapp

○

J2EEアプリケーションに対して実行したときと同じ。

cjlistlibjar

×

−

cjlistpool

×

−

cjtestres

×

−

cjclearpool

×

−

（凡例）○：サポートあり　△：一部サポートあり　×：サポートなし　−：該当なし

注※　アプリケーションの属性を変更したい場合は，サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使用してください。

WARアプリケーションに対する操作の制限

WARアプリケーションでは，次の操作は実行できません。

リソースの追加・削除

・WARアプリケーションへのEJB-JAR／WAR／RARの追加

・WARアプリケーションからWARの削除

・WARアプリケーションへのライブラリJARの追加

・WARアプリケーションへのフィルタの追加

・WARアプリケーションからフィルタの削除

テストモード

アプリケーションのエクスポート

アプリケーション名の変更

参考

リソースを追加・削除する場合，WARアプリケーションを削除して，EARファイルのJ2EEアプリケーションを作成してください。

18.9.2　実行できるWARアプリケーションの形式

WARアプリケーションは，アーカイブ形式または展開ディレクトリ形式でインポートできます。アプリケーションの形式については，「18.2　実行できるJ2EEアプリケーションの形式」を参照してください。

アーカイブ形式のWARアプリケーション

インポートするWARファイルは，cjimportwarコマンドを実行するユーザの読み込み権限が必要です。

なお，インポート時に指定したWARファイル名は作業ディレクトリ中のディレクトリ名として用いられます。作業ディレクトリのパス長がプラットフォームの上限に達しないようにWARファイル名を指定してください。作業ディレクトリのパス長の見積もりについては，マニュアル「アプリケーションサーバシステム構築・運用ガイド」の「付録C.1　J2EEサーバの作業ディレクトリ」を参照してください。

展開ディレクトリ形式のWARアプリケーション

展開ディレクトリ形式のWARアプリケーションは，WARディレクトリというルートディレクトリを作成して，展開ディレクトリ形式のアプリケーションとしてインポートします。WARアプリケーションをインポートすると，WARディレクトリ下にWebアプリケーションなどの構成要素が格納されます。なお，展開ディレクトリ形式のWARアプリケーションはリモート環境では実行できません。

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

展開ディレクトリ形式を使用する場合の注意事項を次に示します。

展開ディレクトリ形式のWARアプリケーションをインポートする場合に，WARディレクトリのパスとしてUNC名を含むパスは指定できません。UNC名を含むパスを指定した場合，コマンドの実行エラーになります。

Windowsのドライブ直下（C:¥など）のディレクトリ，またはUNIXのルートディレクトリ（/）を示すパス（相対パスも含む）をWARディレクトリに指定できません。cjimportwarコマンドの-aオプションにドライブ直下のディレクトリ，またはルートディレクトリを示すパスをWARディレクトリとして指定した場合，コマンドの実行エラーになります。

cjimportwarコマンドの-aオプションに指定したディレクトリと同一のディレクトリを持つWARアプリケーションが，すでにJ2EEサーバ内にある場合，インポートでコマンドの実行エラーになります。

次のディレクトリをアプリケーションディレクトリまたはWARディレクトリとして持つJ2EEアプリケーションが，すでにJ2EEサーバ内に存在する場合，インポートでコマンドの実行エラーになります。

・cjimportwarコマンドの-aオプションに指定したディレクトリの上位にあるディレクトリ

・cjimportwarコマンドの-aオプションに指定したディレクトリの下位にあるディレクトリ

18.9.3　WARアプリケーションの入れ替え

WARアプリケーションは既存のJ2EEアプリケーション（EAR形式）と同じように，リデプロイ機能を使用して，開発環境にあるWARファイルをすでに運用中のWARアプリケーションと入れ替えることができます。J2EEアプリケーションの入れ替えについては，「18.7　J2EEアプリケーションのリデプロイ」を参照してください。

注意事項

WARアプリケーションをリデプロイで入れ替える場合，cosminexus.xmlファイルの再読み込みはできません。WARアプリケーションのアプリケーション属性を変更する場合は，サーバ管理コマンド（cjgetapppropコマンドおよびcjsetapppropコマンド）を使用してください。

18.9.4　WARアプリケーションのアプリケーション名

アプリケーション名をcjimportwarコマンドの-nameオプションで指定します。-nameオプションに指定できる文字列は，application.xmlの<application>タグ下の<display-name>タグに指定できる文字列と同じです。使用できる文字については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjimportwar（WARアプリケーションのインポート）」を参照してください。使用できない文字が使用されている場合，KDJE37206-Eメッセージが出力されます。

cjimportwarコマンドに-nameオプションを指定していない場合，J2EEサーバはWARファイル名（アーカイブ形式の場合），またはWARディレクトリ名（展開ディレクトリ形式の場合）を基に，使用できない文字をアンダースコア(_)に置き換えてアプリケーション名を設定します。なお，J2EEサーバが設定したアプリケーション名がJ2EEサーバ内で重複する場合，アプリケーション名がJ2EEサーバ内で一意となるように，そのアプリケーション名の末尾に通し番号（1〜2147483647）が追加されます。

アプリケーション名の設定例を次に示します。

表18‒24　アプリケーション名の設定例（アーカイブ形式のWARアプリケーションの場合）

cjimportwarコマンドの-nameオプション

WARファイル名

アプリケーション名

SampleTP

SampleWeb.war

SampleTP

（指定なし）

SampleWeb.war

SampleWeb

表18‒25　アプリケーション名の設定例（展開ディレクトリ形式のWARアプリケーションの場合）

cjimportwarコマンドの-nameオプション

WARアプリケーションのディレクトリ名

アプリケーション名

SampleTP

SampleWeb

SampleTP

（指定なし）

SampleWeb

SampleWeb

18.9.5　コンテキストルートの決定

コンテキストルートをcjimportwarコマンドの-contextrootオプションで指定します。-contextrootオプションは，URI（RFC3986）で使用できる文字を指定してください。URI（RFC3986）で使用できる文字以外，またはejb/，web/，/ejb/，および/web/から始まる文字列を指定した場合，KDJE37206-Eメッセージが出力されます。cjimportwarコマンドの詳細については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjimportwar（WARアプリケーションのインポート）」を参照してください。

cjimportwarコマンドに-contextrootオプションを指定していない場合，J2EEサーバはWARファイル名（アーカイブ形式の場合），またはWARディレクトリ名（展開ディレクトリ形式の場合）を基に，次のようにコンテキストルートを決定します。

拡張子を取り除いた文字列がejb，またはwebだったときは，それぞれejb1，web1に変換します。

ejbまたはweb以外の文字列のときは，使用できない文字をアンダースコア(_)に置き換えてコンテキストルートを決定します。

コンテキストルートの決定例を次に示します。

表18‒26　コンテキストルートの決定例（アーカイブ形式のWARアプリケーションの場合）

cjimportwarコマンドの-contextrootオプション

WARファイル名

コンテキストルート

example/Servlet

SampleWeb.war

example/Servlet

（指定なし）

SampleWeb.war

SampleWeb

表18‒27　コンテキストルートの決定例（展開ディレクトリ形式のWARアプリケーションの場合）

cjimportwarコマンドの-contextrootオプション

WARアプリケーションのディレクトリ名

コンテキストルート

example/Servlet

SampleWeb

example/Servlet

（指定なし）

SampleWeb

SampleWeb

cjlistappコマンドを実行すると，表示される文字列にコンテキストルートが表示されます。cjlistappコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistapp（アプリケーションの一覧表示）」を参照してください。

18.9.6　cosminexus.xmlファイルの読み込み

読み込むcosminexus.xmlファイルをcjimportwarコマンドの-cオプションで指定します。-cオプションを省略した場合，cosminexus.xmlファイルは読み込まれません。cjimportwarコマンドの詳細については，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjimportwar（WARアプリケーションのインポート）」を参照してください。

cosminexus.xmlを含むアプリケーションの運用については，「16.3.6　cosminexus.xmlを含むアプリケーションの運用」を参照してください。

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

この章では，コンテナ拡張ライブラリの機能について説明します。

アプリケーションサーバでは，Enterprise Beanやサーブレットから共通して使用するライブラリを，コンテナ拡張ライブラリとして利用できます。

19.1　この章の構成

コンテナ拡張ライブラリの機能と参照先を次の表に示します。

表19‒1　コンテナ拡張ライブラリの機能と参照先

機能

参照先

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

19.2

コンテナ拡張ライブラリの機能

19.3

サーバ起動・停止フック機能

19.4

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

19.5

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

19.6

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

この節では，コンテナ拡張ライブラリおよびサーバ起動・停止フック機能の概要について説明します。

アプリケーションサーバでは，EJB-JARとWAR間で共通に利用したい処理がある場合や，異なるEAR間で共通に利用したい処理がある場合に，ユーザ作成のライブラリを利用できます。ユーザ作成のライブラリを利用することで，サーブレット，JSP，およびEnterprise Beanの機能を拡張できます。

サーブレット，JSP，およびEnterprise Beanが共通に利用できるライブラリをコンテナ拡張ライブラリといいます。このライブラリを利用することで，Enterprise Bean，サーブレット，JSPから共通して，ユーザ作成のライブラリを呼び出せるようになります。

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

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

コンテナ拡張ライブラリの設定については，「19.3.3　コンテナ拡張ライブラリの機能を使用するための設定」を参照してください。

19.3　コンテナ拡張ライブラリの機能

この節では，コンテナ拡張ライブラリの機能について説明します。

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

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

分類

タイトル

参照先

解説

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

19.3.1

コンテナ拡張ライブラリの作成と利用の流れ

19.3.2

設定

コンテナ拡張ライブラリの機能を使用するための設定

19.3.3

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

注2　コンテナ拡張ライブラリを利用する場合の制限事項については，「19.6　コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項」を参照してください。

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

処理の種類に応じて検討する方法と，処理の内容に応じて検討する方法について説明します。

(1)　処理の種類による検討

まず，処理を次の3種類に分類し，コンテナ拡張ライブラリを利用するかどうかを検討します。コンテナ拡張ライブラリを利用しない場合は，EJB-JARファイル，WARファイル，またはライブラリJARに共通のライブラリを含めます。

業務処理

業務ごとに処理が異なるため，EJB-JARファイル，またはWARファイルに含めます。コンテナ拡張ライブラリを利用する必要はありません。

EJB-JARファイルおよびWARファイル間の共通処理

複数のEJB-JARファイルやWARファイルに含まれる，Enterprise Bean，サーブレット，JSP，業務処理が共通に利用できる処理がある場合，ライブラリJARを利用します。ライブラリJARを利用できない場合は，共通処理のクラスを作成して，コンテナ拡張ライブラリを利用します。

EAR間の共通処理

複数のEARに含まれる，EJB-JAR，WARが共通に利用できる処理がある場合，ライブラリJARを利用します。ライブラリJARを利用できない場合は，共通処理のクラスを作成して，コンテナ拡張ライブラリを利用します。

(2)　処理の内容による検討

Enterprise Bean，サーブレット，JSPでの操作内容を次のように分類し，それぞれコンテナ拡張ライブラリを使用するかどうかを検討します。コンテナ拡張ライブラリを利用するかどうかの指針を次の表に示します。

表19‒3　操作内容ごとのコンテナ拡張ライブラリの利用の指針

操作内容

コンテナ拡張ライブラリ

EJB-JARファイルまたはWARファイル

ライブラリJAR

ファイルやディレクトリへのアクセス操作

○

×

×

JNIの利用による操作※

○

×

×

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

○

×

×

J2EEコンテナ機能の操作

×

○

×

EJB-JARファイルおよびWARファイル内のクラス参照

×

−

×

（凡例）　○：含める　　×：含めない　　−：該当しない

注※　J2EEアプリケーションまたはWebアプリケーションで同一のネイティブライブラリをロードしようとした場合，JNIの仕様によってUnsatisfiedLinkErrorがスローされます。これは，アプリケーションで共通に使用するネイティブライブラリをコンテナ拡張ライブラリとして登録することで，回避できます。

注意事項

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

java.security.AllPermission

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

19.3.2　コンテナ拡張ライブラリの作成と利用の流れ

コンテナ拡張ライブラリの作成と利用の流れを次に示します。

ユーザ作成のクラスを実装，コンパイルします。

サーバ起動・停止フック機能を使用する場合は，<Application Serverのインストールディレクトリ>¥CC¥lib¥ejbserver.jarをクラスパスに指定してコンパイルします。なお，サーバ起動・停止フック機能を使用する場合は，IDEを使用しない方法で実装，コンパイルしてください。

また，サーバ起動・停止フック機能では，TPBrokerが提供するスマートエージェント経由のCORBAオブジェクトを呼び出す処理を実装することもできます。

作成したクラスを，JARファイルにアーカイブします。

ユーザが作成したクラスを，コンテナ拡張ライブラリ用のJARファイルにアーカイブします。EJB-JARファイルやWARファイルには含めないでください。

アーカイブしたJARファイルを，J2EEサーバのシステムクラスパスに指定します。

コンテナ拡張ライブラリを利用する場合，この手順のほかにJ2EEサーバでの設定（定義ファイルの指定など）が必要になります。

J2EEサーバでの設定については，「19.3.3　コンテナ拡張ライブラリの機能を使用するための設定」を参照してください。

19.3.3　コンテナ拡張ライブラリの機能を使用するための設定

ここでは，コンテナ拡張ライブラリを使用するための設定について説明します。なお，コンテナ拡張ライブラリがJNIを利用する場合は，サーバ起動・停止フック機能を使用します。

コンテナ拡張ライブラリを使用するためには，次の設定が必要です。

コンテナ拡張ライブラリ用のJARファイルを作成します。

コンテナ拡張ライブラリの利用については，「19.2　コンテナ拡張ライブラリの利用」を参照してください。

簡易構築定義ファイルで，論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタを指定します。

add.class.path

add.class.pathの設定値には，手順1.で作成したJARファイルのパスをJ2EEサーバのシステムクラスパスを指定します。

add.class.pathは，簡易構築定義ファイルのJ2EEサーバの拡張パラメタに設定します。

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

add.library.path

add.library.pathの設定値には，JNI用ライブラリの検索パスを指定します。

ejbserver.application.InitTermProcessClasses

ejbserver.application.InitTermProcessClassesの設定値には，サーバ起動・停止フック機能のクラス名を指定します。

add.library.pathおよびejbserver.application.InitTermProcessClassesは，簡易構築定義ファイルの，J2EEサーバの拡張パラメタに設定します。

サーバ管理コマンド用のファイルのキーにコンテナ拡張ライブラリ用のJARファイルを指定します。

指定するファイルおよびキーは，OSによって異なります。

Windowsの場合

usrconf.batのUSRCONF_JVM_CLASSPATHキー

UNIXの場合

usrconfのUSRCONF_JVM_CLPATHキー

コンテナ拡張ライブラリからJNI機能を使用する場合は，サーバ管理コマンド用のファイルのキーで，JNI用ライブラリの検索パスを指定します。

複数指定する場合は，セミコロン（;）で区切ってください。

指定するファイルは，OSによって異なります（キーは共通です）。

Windowsの場合

usrconf.batのUSRCONF_JVM_LIBPATHキー

UNIXの場合

usrconfのUSRCONF_JVM_LIBPATHキー

ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」およびマニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「5.2.2　usrconf.bat（サーバ管理コマンド用オプション定義ファイル）」を参照してください。

簡易構築定義ファイルおよびユーザ定義ファイルの設定例を次に示します。この例では，コンテナ拡張ライブラリのJARファイルは「extended_container.jar」で，そのコンテナ拡張ライブラリがJNIを使用して「extended_container.dll」（UNIXの場合，extended_container）を呼び出します。

Windowsの場合

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

<configuration>
  <logical-server-type>j2ee-server</logical-server-type>
  <param>
    <param-name>add.class.path</param-name>
    <param-value>c:¥jar¥extended_container.jar</param-value>
    <param-name>add.library.path</param-name>
    <param-value>c:¥lib</param-value>
  </param>
  ：
</configuration>

サーバ管理コマンド用のusrconf.batの設定例

rem system classpath
set USRCONF_JVM_CLASSPATH=c:¥jar¥extended_container.jar

rem library path
set USRCONF_JVM_LIBPATH=c:¥lib

UNIXの場合

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

<configuration>
  <logical-server-type>j2ee-server</logical-server-type>
  <param>
    <param-name>add.class.path</param-name>
    <param-value>/work/classes/extended_container.jar</param-value>
    <param-name>add.library.path</param-name>
    <param-value>/work/lib</param-value>
  </param>
  ：
</configuration>

サーバ管理コマンド用のusrconfの設定例

#!/bin/csh -f
# system classpath
set USRCONF_JVM_CLPATH=/work/classes/extended_container.jar

# library path
set USRCONF_JVM_LIBPATH=/work/lib

19.4　サーバ起動・停止フック機能

この節では，サーバ起動・停止フック機能について説明します。

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

表19‒4　この節の構成（サーバ起動・停止フック機能）

分類

タイトル

参照先

解説

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

19.4.1

実装

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

19.4.2

設定

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

19.4.3

注1　「運用」について，この機能固有の説明はありません。

注2　サーバ起動・停止フック機能を利用する場合の制限事項については，「19.6　コンテナ拡張ライブラリおよびサーバ起動・停止フック機能利用時の制限事項」を参照してください。

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

サーバ起動・停止フック機能を複数登録した場合の，サーバ起動・停止フック処理の呼び出し順序について説明します。

(1)　正常に起動，停止した場合

J2EEサーバ起動時には，登録されたクラス順にサーバ起動フック処理を行うserverInitializingメソッドが呼び出されます。また，J2EEサーバ停止時には，登録された逆順にサーバ停止フック処理を行うserverTerminatingメソッドが呼び出されます。

J2EEサーバが正常起動した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。

図19‒1　サーバ起動・停止フック処理の呼び出し順序（正常起動時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。サーバ起動フック処理では，正常に呼び出されると，クラスA，クラスB，クラスCの順でクラスが呼び出されます。サーバ停止フック処理では，クラスC，クラスB，クラスAの順でクラスが呼び出されます。

(2)　サーバ起動フック処理中に例外が発生した場合

サーバ起動フック処理の実行中に例外が発生した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。

図19‒2　サーバ起動・停止フック処理の呼び出し順序（起動フック処理中の例外発生時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。クラスBのサーバ起動フック処理（serverInitializingメソッド）の実行中に例外が発生した場合は，クラスCのサーバ起動フック処理は呼び出されません。また，クラスCのサーバ停止フック処理（serverTerminatingメソッド）は呼び出されないで，クラスB，クラスAの順序でサーバ停止フック処理が呼び出されます。

(3)　サーバ起動フック処理後に例外が発生した場合

サーバ起動フック処理の実行後に例外が発生した場合の，サーバ起動・停止フック機能の呼び出し順序を次の図に示します。

図19‒3　サーバ起動・停止フック処理の呼び出し順序（起動フック処理後の例外発生時）

サーバ起動・停止フック処理を実装したA，B，Cの三つのクラスがあり，クラスA，クラスB，クラスCの順でクラスが登録されていることとします。クラスBのサーバ起動フック処理（serverInitializingメソッド）の実行後に例外が発生した場合は，クラスCのサーバ起動フック処理は呼び出されません。また，サーバ停止フック処理は呼び出されません。

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

サーバ起動・停止フック機能は，com.hitachi.software.ejb.application.InitTermProcessインタフェースを実装することで利用できます。サーバ起動フック処理はserverInitializingメソッド，停止フック処理はserverTerminatingメソッドに実装します。次に，InitTermProcessインタフェースの実装例を示します。

package sample;

import com.hitachi.software.ejb.application.InitTermProcess;
import com.hitachi.software.ejb.application.InitTermException;

public class AppInitTerm implements InitTermProcess {
    public void serverInitializing() throws InitTermException {
        try {
            // サーバ起動フック処理
        } catch (Exception e) {
            throw new InitTermException("詳細メッセージ");
        }
    }
    public void serverTerminating() throws InitTermException {
        try {
            // サーバ停止フック処理
        } catch (Exception e) {
            throw new InitTermException("詳細メッセージ");
        }
    }
}

J2EEサーバは，起動時にデフォルトコンストラクタを使用してサーバ起動・停止フック機能のインスタンスを生成します。このため，クラスおよびデフォルトコンストラクタのアクセス指定子には，publicを指定してください。

サーバ停止フック処理が呼び出されるタイミングは，アプリケーションの停止処理後になります。J2EEサーバでは，スレッドの停止処理を行っていないため，処理スレッドは残りますが，サーバ停止フック処理後に，新たにアプリケーションは実行されません。

ユーザ定義ファイル（usrconf.properties）のサーバ起動・停止フック機能用のプロパティキー（ejbserver.application.InitTermProcessClasses）に，サーバ起動・停止フックのクラス名を指定します。また，サーバ起動・停止フックのクラス名は複数指定できます。ユーザ定義ファイル（usrconf.properties）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

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

サーバ起動・停止フック機能を利用する場合，JARファイルのパスを，J2EEサーバのシステムクラスパスに追加する必要があります。システムクラスパスの追加は，ユーザ定義ファイル（usrconf.cfg）に指定します。

システムクラスパスの追加の方法については，「19.3.3　コンテナ拡張ライブラリの機能を使用するための設定」を参照してください。また，ユーザ定義ファイル（usrconf.cfg）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

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

コンテナ拡張ライブラリを利用することで，J2EEアプリケーションまたはWebアプリケーションがTPBrokerを使用して，スマートエージェント経由でCORBAオブジェクトを呼び出すことができます。スマートエージェントを利用してCORBAオブジェクトのオブジェクトリファレンスを取得し，メソッドを呼び出すときには，スマートエージェントが起動済みとなっており，スマートエージェントに，該当するCORBAオブジェクトのオブジェクトリファレンスが登録されている必要があります。また，コンテナ拡張ライブラリには，J2EEアプリケーションまたはWebアプリケーションからCORBAオブジェクトを呼び出す処理を含めます。

この節では，スマートエージェント経由でのCORBAオブジェクトの呼び出しについて説明します。

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

表19‒5　この節の構成（スマートエージェント経由でのCORBAオブジェクトの呼び出し）

分類

タイトル

参照先

実装

CORBAオブジェクト呼び出し処理の実装時の注意事項

19.5.1

CORBAオブジェクト呼び出し処理のパッケージ化の注意事項

19.5.2

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

次に，CORBAオブジェクト呼び出し処理の実装時の注意事項，およびCORBAオブジェクト呼び出し処理のパッケージ化の注意事項を示します。

19.5.1　CORBAオブジェクト呼び出し処理の実装時の注意事項

CORBAオブジェクトの呼び出し処理を実装するときには，次の点に注意してください。

プロパティを使用して，org.omg.ORBをカスタマイズするには，org ORB init(String[] args, Properties props)メソッドのpropsパラメタにプロパティを指定してください。

なお，J2EEサーバのシステムプロパティに指定できるキーは，vbroker.agent.port，vbroker.agent.enableLocator，およびvbroker.agent.addrキーだけです。

TPBrokerのサーバ機能は利用できません。また，J2EEサーバ上で，CORBAオブジェクトを活性化することはできません。

TPBrokerのインターセプタは利用できません。

TPBrokerのDII機能は利用できません。

19.5.2　CORBAオブジェクト呼び出し処理のパッケージ化の注意事項

CORBAオブジェクトの呼び出し処理をパッケージ化するときには，次の点に注意してください。

org.omg.CORBA配下のパッケージにあるインタフェース，クラスを利用するクラスは，EJB-JARファイルまたはWARファイルには含めないでください。これらのクラスは，コンテナ拡張ライブラリ用のJARファイルに含めます。

IDL定義から生成されたインタフェース，クラス，およびそれらを利用するクラスは，EJB-JARファイルまたはWARファイルには含めないでください。これらのクラスは，コンテナ拡張ライブラリ用のJARファイルに含めます。

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

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能を利用する場合の制限事項を示します。

アプリケーションのポータビリティについて

コンテナ拡張ライブラリはJ2EEの仕様外の機能です。したがって，コンテナ拡張ライブラリを使用した場合は，アプリケーションとしての移行性は低下します。

コンテナ拡張ライブラリの呼び出しについて

コンテナ拡張ライブラリは，サーブレット，JSP，およびEnterprise Beanから呼び出されることを前提としています。次に示す利用形態は適用できないので，注意してください。

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，EJB-JARファイル，WARファイルを参照する（EJB-JARファイル，WARファイルのクラスが，コンテナ拡張ライブラリのクラスを継承することも含む）。

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，J2EEコンテナの機能を利用する（Enterprise Bean，JNDI，JDBCなどのAPIを呼び出す）。

EJB-JARファイルおよびWARファイルのクラスから，直接サーバ起動・停止フック機能を参照する（コンテナ拡張ライブラリのクラスが，EJB-JARファイル，WARファイルのクラスを継承することも含む）。

ファイル，ディレクトリのアクセスについて

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能から，次に示すファイルやディレクトリを操作しないでください。

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

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

JNI機能の利用について

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能からJNI機能を利用する場合，J2EEサーバでは，ネイティブメソッドでの処理を管理できません。例えば，ネイティブメソッドでメモリアクセス違反があった場合，J2EEサーバは，JavaVMのプロセスごと異常終了します。

TPBrokerの利用について

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能では，TPBrokerのサーバ機能を利用できません。これは，J2EEサーバ上にTPBrokerのCORBAオブジェクトを活性化できないためです。

TPBrokerのDII機能は利用できません。

インストール型オプションパッケージの使用について

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能は，インストール型オプションパッケージとして使用してはいけません。インストール型オプションパッケージとは，次のディレクトリに置かれたファイルです。

<Application Serverのインストールディレクトリ>¥jdk¥jre¥lib¥extに置かれたJARファイル

<Application Serverのインストールディレクトリ>¥jdk¥jre¥binに置かれたネイティブコードバイナリ

シャットダウンフックの登録について

コンテナ拡張ライブラリおよびサーバ起動・停止フック機能では，シャットダウンフックを登録しないでください。

コンテナ拡張ライブラリとして使用できないライブラリについて

次の表に示すライブラリをコンテナ拡張ライブラリとしてクラスパスに追加することはできません。ただし，JBoss Loggingだけは，ユーザアプリケーションから直接参照できます。

表19‒6　コンテナ拡張ライブラリとしてクラスパスに追加できないライブラリ

ライブラリ名

パッケージ名

参照可否

JBoss Logging

org.jboss.logging

可

EclipseLink JPA

org.eclipse.persistence

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jpa-provider.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

Jersey

com.sun.research.ws

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jaxrs-impl.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

jersey.repackaged

org.glassfish.jersey

HK2

org.glassfish.hk2

org.jvnet.tiger_types

org.jvnet.hk2

Javassist

javassist

Jackson

com.fasterxml.jackson

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jaxrs-jackson.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

GlassFish

org.glassfish.cdi.transaction

不可

Google Guava

com.google.common

Hibernate Validator

org.hibernate.validator

Java ClassMate

com.fasterxml.classmate

Java Batch Reference Implementation (jbatch)

com.ibm.jbatch

JBoss classfilewriter

org.jboss.classfilewriter

JSR 236 (Concurrency Utilities for Java EE) RI

org.glassfish.enterprise.concurrent

JSR 374 (JSON Processing) RI

org.glassfish.json

JSR 367 (JSON Binding) RI

org.eclipse.yasson

Mojarra

com.sun.faces

Unified Expression Language RI

com.sun.el

Weld

org.jboss.weld

Tyrus

org.glassfish.tyrus

ハンドラ関数の設定について（Windowsの場合）

Windowsでコンテナ拡張ライブラリを使用してプロセスのハンドラ関数を設定する場合，CTRL+BREAK信号を処理するハンドラ関数では，TRUEを返したり，DLLの終了処理をしたり，ExitProcess関数などを呼び出してプロセスを終了したりしないでください。

J2EEサーバ，Component Containerを利用するほかのプログラムなどが動作しなくなるおそれがあります。

C++ライブラリについて（Linuxの場合）

Linuxでコンテナ拡張ライブラリをC++で実装している場合，そのライブラリは，Red Hat Enterprise Linux 4以降でビルドしておく必要があります。Red Hat Enterprise Linux 3でビルドしたC++のライブラリは実行できません。

20　アプリケーション実装時の注意事項

この章では，アプリケーション実装時の注意事項について説明します。

20.1　スレッドローカル変数使用時の注意事項

スレッドローカル変数へ格納したJ2EEアプリケーションのクラスのインスタンスを，J2EEアプリケーションの停止までに削除しないと，J2EEアプリケーションを停止してもクラスローダへの参照が残ることになり，メモリリークが発生します。

java.lang.ThreadLocal.remove()メソッドでスレッドローカル変数へ格納したJ2EEアプリケーションのクラスのインスタンスを削除してください。

フレームワークなどが格納したインスタンスをJ2EEアプリケーションで削除できない場合は，J2EEアプリケーションの開始および停止を繰り返さないでください。J2EEアプリケーションの開始および停止を繰り返す場合は，J2EEサーバを再起動してください。

20.2　Developer's Kit for Javaに関する注意事項

ここでは，Developer's Kit for Javaに関する共通の注意事項，JDKのバージョンの仕様差異に関する注意事項について説明します。

20.2.1　アプリケーションサーバのバージョン共通の注意事項

アプリケーションサーバのバージョンで共通のDeveloper's Kit for Javaに関する注意事項について説明します。

(1)　OS共通の場合

OSで共通の注意事項について説明します。

Java SEの旧バージョンとの互換性について

Java SE 6は，Java SE（J2SE）の旧バージョンと，一部の機能に互換性がありません。詳細は，該当ページ（http://www.oracle.com/technetwork/java/javase/compatibility-137541.html）を参照してください。

Java SE 6でのそのほかの変更点について

Java SE 6でのそのほかの拡張および変更点については，該当ページ（http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html）を参照してください。

JVMPIとJVMDIについて

JVMPIとJVMDIを廃止しました。これらの代わりにJVM TIを利用してください。

GCメモリ情報を取得する機能について

GCメモリ情報を取得するJP.co.Hitachi.soft.jvm.MemoryInfoクラスは，Developer's Kit for Javaで利用できます。ほかの製品では利用できません。

URLClassLoaderでのクラスのローディングについて

URLClassLoader経由でjarファイルからクラスをローディングする場合，ローディング処理中にJavaVMの内部で作成されるオブジェクトが，JavaVM終了時まで削除されないことがあります。適宜，Javaアプリケーションを再起動してください。

Java2Dの使用について

Java2DのDirectDrawおよびDirect3Dの問題を回避するため，DirectDrawとDirect3Dを無効にする，sun.java2d.noddrawプロパティに「true」を指定してください。

メソッド長の上限について

JavaVMの仕様によって，1メソッドのバイトコードは，64キロバイト以内にする必要があります。

64キロバイトを超えると，クラスファイル生成時にエラーとなるか，またはクラスのロード時にjava.lang.LinkageError例外が発生します。

また，64キロバイト以内であっても，非常に複雑で行数が多い場合は，次のような弊害が発生することがあります。

GC処理の実行に非常に時間が掛かる。

JITコンパイルに非常に時間が掛かる。

JITコンパイルに非常に多くのメモリを消費する。

さらに，ローカル変数情報出力機能が有効な場合は，次の弊害も発生することがあります。

拡張スレッドダンプの出力に時間が掛かる。

スレッドスタックトレースの取得に時間が掛かる。

例外発生時の例外オブジェクト生成処理に時間が掛かる。

そのため，Javaソース上の1メソッドの行数は，コメントや空行を除いて，およそ500行以内にすることをお勧めします。

直列化バージョンUID（serialVersionUID）について

JDK 1.4以降では，直列化可能な入れ子クラスにクラスオブジェクト（例えば，Class c = Object.class;）への明示的な参照が含まれている場合，入れ子クラスとそのクラスを包含するクラスの両方で，デフォルトの直列化バージョンUIDの値が，JDK 1.4より前のバージョンと異なります。これは，JDK 1.4で実施されたjavacコマンドの変更によるものです。これらの条件をすべて満たす場合には，直列化可能クラスに直列化バージョンUID（serialVersionUID）を追加してください。

ファイルディスクリプタのクローズについて

java.lang.Runtime.exec()，およびjava.lang.ProcessBuilder.start()で起動した子プロセスは，Process.getInputStream，getErrorStream，またはgetOutputStreamのそれぞれのメソッドで取り出したストリームを通じてプロセス間通信をします。

親プロセスでは，これらのメソッドを使わない場合でも三つのファイルディスクリプタを消費することに注意してください。

ファイルディスクリプタをクローズするのは次の場合です。

Processオブジェクトのファイナライズが完了した場合

Process.destroy()を呼び出した場合

これらストリームに対して明示的にclose()メソッドを呼び出した場合

システムプロパティjava.library.pathについて

システムプロパティjava.library.pathには，ユーザのネイティブライブラリの検索パスを指定します。デフォルト値を次に示します。

Windowsの場合

"<JDKインストールディレクトリ>¥bin，<システムディレクトリ>，<Windowsディレクトリ>，%PATH%，カレントディレクトリ"

AIXの場合

環境変数LD_LIBRARY_PATHの設定値，JDK下のネイティブライブラリのディレクトリ，"/usr/lib:/lib"

Linuxの場合

JDK下のネイティブライブラリのディレクトリ，環境変数LD_LIBRARY_PATHの設定値，"/usr/lib64:/lib64:/lib:/usr/lib"

ポジティブDNSキャッシュの保持時間について

JDKは，DNSへのホスト名解決の問い合わせ結果をキャッシュする機能を持ちます。キャッシュ機能には，解決成功の結果を保持するポジティブキャッシュと，解決失敗の結果を保持するネガイティブキャッシュがあります。

このうち，セキュリティマネージャが無効な場合だけ，DNSへの問い合わせ結果のポジティブキャッシュのデフォルト保持期間が，「永久にキャッシュ」から「実装依存」へ変更になりました。JDK 5.0と同様の挙動にする場合は，セキュリティプロパティnetworkaddress.cache.ttlの値を「-1」にしてください。詳細は，該当ページ（http://docs.oracle.com/javase/6/docs/api/java/net/InetAddress.html）を参照してください。

インストゥルメンテーション機能が出力するメッセージについて

インストゥルメンテーション機能の処理中にメモリ不足になった場合，次のメッセージが出力され，インストゥルメンテーション機能の処理が失敗することがあります。詳細は，該当ページ（http://docs.oracle.com/javase/jp/1.5.0/api/java/lang/instrument/package-summary.html）を参照してください。

メッセージの内容

*** java.lang.instrument ASSERTION FAILED ***

java.net.Socket.connect()のタイムアウトについて

java.net.Socket.connect()でのソケットの接続が，OSに設定されているTCP通信のタイムアウト値によってタイムアウトすることがあります。TCP通信のタイムアウト値になると，java.net.Socket.connect()に指定したタイムアウト値よりも前でも，タイムアウト値を指定していないときでも，接続がタイムアウトします。

TCP通信のタイムアウト値でタイムアウトした場合，次の詳細メッセージを含むjava.net.ConnectException例外がスローされます。

メッセージの内容

Connection timed out: connect [errno=10060, syscall=select]

TCP通信のタイムアウトについては，OSのドキュメントを参照してください。

クラスロードのタイミングについて

Javaでのクラスファイルのメモリへの読み込み（クラスロード処理）は，プログラムの実行中に，そのクラスが初めて必要となったタイミングで実行されます。そのため，ある処理の初回実行でクラスロードの回数が多くなると，2回目以降と比較して，処理時間が長くなることがあります。この場合，処理の実行に必要なクラスを事前にロードすることで，処理時間が改善します。

異なるOS間で発生する文字化けについて

文字コードのUnicodeへのマッピングは，OSによって異なることがあります。このため，次の場合に文字化けが発生することがあります。文字化けが発生する代表的な文字には，—，〜，‖，−，¢，£，¬があります。

UTF-8などのUnicodeのエンコーディングを使用して，異なるOS間で上記文字データを受け渡す場合

上記文字を含む文字列リテラルがあるソースプログラムから作成したクラスファイルを，異なるOS上でリコンパイルしないでそのまま実行する場合

Java APIで使用するファイルについて

Java APIで使用するポリシーファイルや，ログイン構成ファイルなどのコンフィグレーションファイルは，UTF-8エンコーディング方式でエンコーディングする必要があります。

JNI関数で文字列操作をする場合のUTF-8エンコーディングについて

JNIの場合，次の文字列操作をする関数で使用するエンコーディングは，標準UTF-8ではなく，Modified UTF-8です。

NewStringUTF

GetStringUTFLength

GetStringUTFChars

ReleaseStringUTFChars

GetStringUTFRegion

if文の判定でジャンプできる長さの上限について

JavaVMの仕様によって，if文の判定でジャンプできる長さは32キロバイトまでです。ジャンプ先が32キロバイトを超える場合は，java.lang.LinkageErrorとなります。

ファイルサイズの上限について

java.util.zip，java.util.jarパッケージでは，4ギガバイトを超えるJARファイルやZIPファイルはサポートしていません。

java.nio.channels.FileChannelクラスのmap，transferFrom，およびtransferToメソッドについて

mapメソッドでは，2ギガバイトを超えるファイルはサポートしていません。

また，transferFromおよびtransferToメソッドでのcount指定では，2ギガバイト以上の値はサポートしていません。

スレッドのスタックサイズについて

JNI関数AttachCurrentThread()などを使用して，ネイティブスレッドをJavaVMに接続する場合は，-Xssオプションの指定値よりも大きなスタックサイズのスレッドで接続してください。

JavaプロセスがSSL/TLS通信のクライアントとして動作する場合の注意点について

SSL/TLSを使った通信相手のプロトコルを変更した場合，通信に失敗するおそれがあります。

通信相手（サーバ）側で使用できるSSL/TLSプロトコルバージョンを変更したあと，クライアント側のJavaプロセスを再起動しないでSSL/TLSを使った通信をしようとした場合，クライアント側のJavaプロセスで例外が発生して通信に失敗するおそれがあります。

これは，既知の接続先に対して以前接続に成功したプロトコルの情報がクライアント側に残っていると，そのプロトコルバージョンでSSL/TLS通信を試みる，という挙動によるものです。

通信相手が使用できるSSL/TLSプロトコルバージョンを変更する場合は，クライアント側のJavaプロセスを再起動してください。

また，通信相手（サーバ）側で使用できるSSL/TLSプロトコルバージョンを変更したあと，クライアント側のJavaプロセスを再起動しないで通信が失敗した場合は，対象のJavaプロセスを再起動してください。

(2)　Windowsの場合

Windowsでの注意事項について説明します。

AWTコンポーネントでのJIS X0213:2004の第三水準，第四水準文字の非サポートについて

AWTコンポーネントはJIS X0213:2004の第三水準，第四水準文字をサポートしていません。AWTコンポーネントが出力する情報で該当する文字の部分は文字化けします。Windows環境で該当する文字を扱う場合には，Swingコンポーネントを使用してください。

JavaVMログファイルのGC経過時間について

JavaVMログファイルのGC経過時間は，秒単位で小数点以下第7位（100ナノ秒）まで出力されます。

Windowsの場合，08-70より前では，小数点以下第7位（100ナノ秒）まで有効な数値が出力されていました。08-70以降では，小数点以下第6位（1マイクロ秒）まで有効な数値が出力され，小数点以下第7位（100ナノ秒）には常に0が出力されます。

JNIプログラム中で使用できないライブラリについて

JavaVM内で管理している情報が不正に更新されることがあるため，JNIプログラム中で次のライブラリは使用できません。

setjmp()

longjmp()

java.io.tmpdirプロパティについて

java.io.tmpdirプロパティには，書き込み権限があり，かつ存在するディレクトリを指定してください。java.io.tmpdirプロパティの初期値は，Windows APIのGetTempPath()関数で得られるディレクトリです。

また，Java RMIの動的クラスローディング機能やJava APIのjava.io.File.createTempFile()では，java.io.tmpdirプロパティで指定されたディレクトリに一時ファイルを作成します。これらの機能を正常に動作させるため，JavaVMプロセス起動中は一時ファイルの作成先を削除しないでください。

管理者特権が必要な独立プロセスの起動について

管理者特権のないユーザで起動したjavaアプリケーションから，java.lang.Runtime.exec()，またはjava.lang.ProcessBuilder.start()で，管理者特権のある独立プロセスを起動する場合は，次の手順で起動してください。

管理者特権として起動するコマンドにマニフェストを追加します。マニフェストの追加方法については，OSのドキュメントを参照してください。

Windowsのcmd.exeを介してプロセスを起動します。

例えば，sample.exeを起動する場合には次のようになります。

・Runtime.getRuntime().exec("cmd.exe", "/c", "sample.exe");

・new ProcessBuilder("cmd.exe", "/c", "sample.exe").start();

このjavaアプリケーションを起動すると，［ユーザー アカウント制御］ダイアログが表示されるので，［続行］をクリックしてアプリケーションを続行してください。

java.util.prefs.Preferences.systemNodeForPackageによるデータ共有について

管理者特権のないユーザが，java.util.prefs.Preferences.systemNodeForPackageを使用した場合，異なるユーザ間でのデータ共有機能は使用できません。

例えば，同一のキーを引数に指定した場合，異なるユーザ間では異なったデータが返ります。

デフォルトエンコーディングについて

アプリケーションサーバのデフォルトエンコーディングはwindows-31j（別名：MS932）です。

エンコーディング時に発生する文字化けについて

次に示す文字をjavaプログラムで扱う場合，エンコーディングにMS932，windows-31j，cswindows31jのどれかを指定してください。それ以外のエンコーディングを指定した場合，文字化けすることがあります。

（例）

このプログラムは，IBM拡張文字をeucjisでエンコーディングしているため，実行すると次のように文字化けします。

java encode_eucjis
???

文字化けを回避するためには，MS932，windows-31j，cswindows31jのどれかを指定してエンコーディングしてください。

JavaがサポートするUTF-8エンコーディングについて

JavaがサポートするUTF-8エンコーディングは，BOMなしのUTF-8です。Windowsのテキストエディタ（メモ帳）で「文字コード」に「UTF-8」を指定して保存したデータは，BOMありのUTF-8となるため，Javaでは扱えません。

(3)　UNIX共通の場合

UNIXで共通の注意事項について説明します。

forkシステムコールについて

JNIやJVMTIで呼び出されるネイティブメソッド，またはネイティブコードで，fork()システムコール発行だけで現行プロセスのコピーの子プロセスを生成，または実行した場合，その親子プロセスの動作は保証できません。fork()システムコール発行による子プロセス生成後は，必ずexec()システムコールで新規プログラムをローディングしてから起動してください。また，Java環境下で子プロセスを生成する場合には，Javaクラスライブラリのjava.lang.Runtime.exec()メソッドを使用することをお勧めします。

シグナルについて

JNIやJVMTIで呼び出されるネイティブメソッド，またはネイティブコードで，次のシグナルに対してシグナルハンドラを登録した場合，動作は保証しません。

SIGHUP，SIGINT，SIGQUIT，SIGILL，SIGFPE，SIGBUS，SIGSEGV，SIGPIPE，SIGTERM，SIGUSR2，SIGCHLD，SIGXCPU，SIGXFSZ，（_SIGRTMAX-2）番のシグナル

システムライブラリ関数やシステムコール呼び出し中のシグナル受信について

システムライブラリ関数やシステムコール呼び出し中に，次のシグナルを受信することがあります。

SIGHUP，SIGINT，SIGQUIT，SIGILL，SIGFPE，SIGBUS，SIGSEGV，SIGPIPE，SIGTERM，SIGUSR2，SIGCHLD，SIGXCPU，SIGXFSZ，（_SIGRTMAX-2）番のシグナル

システムライブラリ関数やシステムコールを呼び出す場合，該当する関数の処理が，これらのシグナル受信によって中断されて，エラーリターン（errno値にEINTRが設定されるなど）することがあります。この場合は，適切な処置（例えば，再実行など）を実施してください。

JNIプログラム中で使用できないライブラリについて

JavaVM内で管理している情報が更新されて不正な情報となる場合があるため，JNIプログラム中で次のライブラリは使用できません。

setjmp()

longjmp()

_setjmp()

_longjmp()

sigsetjmp()

siglongjmp()

Windowsとの文字データの受け渡しについて

Windowsとの文字データの受け渡しをする場合には，エンコーディングにMS932，windows-31j，cswindows31jのどれかを指定してください。

Shift_JISやSJISを指定すると，次の文字が不正な文字コードに変換されます。

生成できるスレッド数の上限値について

システム全体で生成できるスレッド数の上限は，/proc/sys/kernel/threads-maxです。また，1ユーザ当たりの生成できるスレッド数の上限は，/etc/security/limits.confのnprocの値（ulimit -uと同じ）となります。システムに応じて，これらの値を調整してください。

通知待ちのモニタ数について

JVMTIインタフェースを使用して取得した，通知待ちのモニタ情報が不正となる場合があります。

(4)　AIXの場合

AIXでの注意事項について説明します。

Runtime.execの例外メッセージについて

Runtime.execで例外が発生した場合，エラーメッセージが文字化けすることがあります。

java.security.SecureRandomクラスについて

SecureRandomクラスが使用するOSの乱数生成器のデフォルトは/dev/urandomファイルです。java.security.egdプロパティにfile:/dev/randomを指定すると，/dev/randomファイルを使用できます。ただし，/dev/randomファイルを使用した場合，OSの乱数生成速度には限度があります。このため，SecureRandomクラスが/dev/randomファイルから乱数を取得する，次の処理を短い時間間隔で実施すると，OSによる乱数生成完了まで処理が完了しないので注意してください。

SecureRandomクラスのgenerateSeed()メソッド呼び出し時

SecureRandomクラスのgetSeed()メソッド呼び出し時

java.security.egdプロパティについては，該当ページ（http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html）を参照してください。

java.awt.printによる印刷サポートについて

Developer's Kit for Javaのjava.awt.printパッケージ印刷APIがサポートするAIX印刷サブシステムは，System V印刷サブシステムです。印刷APIを使用する場合は，次の方法でSystem V印刷サブシステムを設定してください。

smit printerコマンドを実行します。

［印刷スプーリング］−［現在の印刷サブシステムの変更／表示］−［現在の印刷サブシステム］を選択し，TabキーでSystemVに変更します。

環境変数LANGについて

環境変数LANGに次の値以外の値を指定している場合，java.nio.channelsパッケージで出力される例外メッセージが文字化けすることがあります。

C

POSIX

java.io.tmpdirプロパティについて

java.io.tmpdirプロパティには，書き込み権限があり，かつ存在するディレクトリを指定してください。java.io.tmpdirプロパティの初期値は/tmpです。

また，Java RMIの動的クラスローディング機能やJava APIのjava.io.File.createTempFile()では，java.io.tmpdirプロパティで指定されたディレクトリに一時ファイルを作成します。これらの機能を正常に動作させるため，JavaVMプロセス起動中は一時ファイルの作成先を削除しないでください。

デフォルトエンコーディングについて

アプリケーションサーバのデフォルトエンコーディングを次に示します。

LANGがCまたはPOSIXのとき：ISO8859_1

LANGがja_JP，ja_JP.IBM-eucJPのどちらかのとき：Cp33722C

LANGがJa_JP，Ja_JP.IBM-943のどちらかのとき：Cp943C

LANGがJa_JP.IBM-932のとき：Cp942C

LANGがJA_JP，JA_JP.UTF-8のどちらかのとき：UTF8

(5)　Linuxの場合

Linuxでの注意事項について説明します。

半角カタカナについて

JIS X 201で制定されている文字のうち，半角カタカナはJavaSEのAPIを使用したGUIの実装では利用できません。

java.security.SecureRandomクラスについて

/dev/randomファイルがあるプラットフォームでは，SecureRandomクラスの一部のAPIで/dev/randomファイルからOSが生成した乱数を取得します。/dev/randomファイルから乱数を取得するのは，次の条件がすべて重なる場合です。

java.security.egdプロパティまたはjava.securityファイル中のsecurerandom.sourceにfile:/dev/random/を指定する

SecureRandomクラスのgenerateSeed()メソッドまたはgetSeed()メソッドを呼び出す

OSの乱数生成速度には限度があります。このため，短い間隔で乱数の取得処理を実行すると，OSによる乱数生成完了まで処理が完了しないので注意してください。

java.io.tmpdirプロパティについて

java.io.tmpdirプロパティには，書き込み権限があり，かつ存在するディレクトリを指定してください。java.io.tmpdirプロパティの初期値は/tmpです。

また，Java RMIの動的クラスローディング機能やJava APIのjava.io.File.createTempFile()では，java.io.tmpdirプロパティで指定されたディレクトリに一時ファイルを作成します。これらの機能を正常に動作させるため，JavaVMプロセス起動中は一時ファイルの作成先を削除しないでください。

デフォルトエンコーディングについて

アプリケーションサーバのデフォルトエンコーディングを次に示します。

LANGがCまたはPOSIXのとき：US-ASCII（別名ASCII）

LANGがjp_JP，jp_JP.eucJP，ja_JP.ujis，japanese，japanese.eucのどれかのとき：x-euc-jp-linux（別名EUC_JP_LINUX）

LANGがja_JP.utf8のとき：UTF-8（別名UTF8）

20.2.2　アプリケーションサーバ Version 8で提供していたJDK 5.0との仕様差異に関する注意事項

アプリケーションサーバ Version 8で提供していたJDK 5.0との仕様差異に関する注意事項について説明します。

(1)　OS共通の場合

OSで共通の注意事項について説明します。

クラスファイルの変更点について

クラスファイル形式の拡張に伴い，javacコマンドのデフォルトのコンパイルで生成されるクラスファイルのバージョンが49.0から50.0となります。また，このクラスファイルをJDK 5.0以前の実行環境で実行すると，java.lang.UnsupportedClassVersionErrorがスローされます。

java.io.Fileの変更点について

java.io.File.deleteOnExit()の実装を変更しました。Java VM終了時に削除するファイル情報を保持するヒープ領域が，Cヒープ領域からJavaヒープ領域に変更になりました。

javaアプリケーション起動ツールの非標準オプションについて

次のオプションは，JDK 6からサポートしていません。

-Xrunhprof

-Xdebug

これらのオプションを指定した場合の動作は保証されません。指定しないようにしてください。なお，オプションを指定した場合はエラーにならないで実行されます。

javacコマンドの変更点について

javacコマンドを実行したときのリターンコードのうち，コンパイル対象ソースが見つからない場合のリターンコードが変更（JDK 5.0では1，JDK 6では2）されました。

UDPソケット数の上限について

セキュリティマネージャが有効な場合，JavaVMプロセス当たり26以上のUDPソケットを同時に使用することはできません。

26以上のUDPソケットを作成しようとした場合は，java.net.SocketExceptionがスローされます。

(2)　UNIX共通の場合

UNIXで共通の注意事項について説明します。

AWTの変更点について

AWTの実装をMotifベースのMAWTからX Window SystemベースのXAWTに変更しました。

(3)　AIXの場合

AIXでの注意事項について説明します。

スタックサイズ（-Xssオプション）の初期値について

JDK 5.0では，Javaスレッドのスタックサイズの初期値は512キロバイトでしたが，JDK 6以降では，Javaスレッドのスタックサイズの初期値は1メガバイトとなっています。

20.3　sun.rmiから始まるロガー使用時の注意事項

J2EEサーバでは，RMIレジストリを使用しています。

また，RMI実装ログを取得するため次の名称のロガーを使用しています。

sun.rmi.transport.tcp

sun.rmi.server.call

sun.rmi.client.call

J2EEアプリケーションで，これらのロガーを使用する場合は，次の点に注意してください。

J2EEサーバのRMI実装ログが出力されます。

J2EEサーバでは，java.util.logging.LoggerクラスのsetUseParentHandlers(boolean)メソッドを使用して，これらのロガーの出力を親ロガーに送信しないように設定しています。そのため，親ロガーによるRMI実装ログの出力はできません。

J2EEサーバでは，ログレベルFINERでRMI実装ログを出力しています。これらのロガーのログレベルを変更する場合，次のログレベルは設定しないでください。

SEVERE

WARNING

INFO

CONFIG

FINE

OFF

20.4　ユーザアプリケーションに含めるライブラリの注意事項

次の表に示すライブラリをユーザアプリケーションに含めることはできません。ただし，JBoss Loggingだけは，ユーザアプリケーションから直接参照できます。

表20‒1　ユーザアプリケーションに含めることができないライブラリ

ライブラリ名

パッケージ名

参照可否

JBoss Logging

org.jboss.logging

可

EclipseLink JPA

org.eclipse.persistence

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jpa-provider.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

Jersey

com.sun.research.ws

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jaxrs-impl.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

jersey.repackaged

org.glassfish.jersey

HK2

org.glassfish.hk2

org.jvnet.tiger_types

org.jvnet.hk2

Javassist

javassist

Jackson

com.fasterxml.jackson

可

ただし，<cosminexus.home>/CC/javaee/1100/lib/jaxrs-jackson.jarをクラスパスに追加している場合は，ユーザアプリケーションからの直接参照不可。

GlassFish

org.glassfish.cdi.transaction

不可

Google Guava

com.google.common

Hibernate Validator

org.hibernate.validator

Java ClassMate

com.fasterxml.classmate

Java Batch Reference Implementation (jbatch)

com.ibm.jbatch

JBoss classfilewriter

org.jboss.classfilewriter

JSR 236 (Concurrency Utilities for Java EE) RI

org.glassfish.enterprise.concurrent

JSR 374 (JSON Processing) RI

org.glassfish.json

JSR 367 (JSON Binding) RI

org.eclipse.yasson

Mojarra

com.sun.faces

Unified Expression Language RI

com.sun.el

Weld

org.jboss.weld

Tyrus

org.glassfish.tyrus

付録

付録A　文字コード

HTTPは，主にWebサーバからブラウザへデータをダウンロードするために用いられるプロトコルですが，HTMLのフォームの場合などではデータのアップロードにも使われます。

ダウンロードするコンテンツの文字コードをWebサーバからブラウザに伝えるための規格は，Servlet APIでも明確に規定されています。しかし，過去のServlet API（Servlet API 2.2以前）では，HTTPクエリ文字列とHTTPリクエストボディの文字コードの扱いが明確ではなかったため，ベンダによって扱いが異なっていました。

Servlet API 2.3からは，Servlet APIを通してHTTPクエリ文字列やHTTPリクエストボディを参照するときに，文字コードを指定できるようになりました（ただし，エンコードタイプがmultipart/form-dataのHTTPリクエストボディを除きます）。これらのデータは，指定された文字コードのデータと見なされてJavaの内部表現であるUnicodeに変換されてからアプリケーションに渡されます。リソースの文字コードやUnicodeへの文字コード変換が間違っていると，「文字化け」を引き起こす原因になるため，アプリケーション開発時には，実行プロセスやリソースの文字コードを考慮する必要があります。

ここでは，アプリケーションで使用する文字コードと注意事項を示します。また，ブラウザとデータをやり取りする場合の，文字コード変換の注意事項についても示します。

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

アプリケーションの構成を基に，文字コード変換の流れを示します。

図A‒1　アプリケーションの文字コード変換の流れ

図中の番号（（1）〜（5））は，文字コードを考慮する必要のあるプログラムやリソースを表します。また，図中の英字（A〜E）は文字コード変換時のデータの流れを示します。プログラム，リソースで扱う文字コードと注意事項，および文字コード変換の動作と注意事項を，それぞれ表に示します。

表A‒1　プログラム，リソースで扱う文字コードと注意事項

プログラム，リソース名

項目

扱う文字コードおよび注意事項

（1）入力ページ

URLのパス

URLのパスの文字コードは，ISO-8859-1である必要があります。シフトJISなどの非ASCII文字は記述できません。

クエリ文字列

HTMLの<FORM>タグを使用して送信される文字は，フォームを表示しているHTMLページと同じ文字コードでURLエンコードされて送出されます。

POSTデータ

（2）JSP

JSP

任意の文字コードで作成できます。

Webアプリケーションのバージョン2.4以降（JSP 2.0仕様以降）で，JSPドキュメントの文字エンコードを指定する場合は，XML宣言で文字エンコードを指定してください。

JSP 1.2仕様では，JSPの文字コードは，pageディレクティブのpageEncoding属性に記述する必要があります。

（3）HTML

HTML

任意の文字コードで作成できます。

（4）データベース

データベース

データベースに格納するデータの文字コードは，ブラウザに表示する文字コードを考慮して決定してください。

（5）出力ページ

レスポンスヘッダ

ISO-8859-1である必要があります。非ASCII文字を使用する場合は，URLエンコードする必要があります。

レスポンスボディ

ユーザプログラムで任意の文字コードを使用できます。

表A‒2　文字コード変換の動作と注意事項

変換個所

対象

文字コード変換時の動作および注意事項

A　ブラウザ〜J2EEサーバ

URLのパス

Webコンテナでは，URLのパスの文字コードはISO-8859-1として処理されます。

クエリ文字列

クエリ文字列またはPOSTデータの文字コードは，アプリケーションで任意に決められます。サーブレット，JSPではUnicodeで扱われるので，アプリケーション内で矛盾のないように文字コードを変換してください。

POSTデータ

B　J2EEサーバ内

JSPファイル

pageディレクティブのpageEncoding属性に記述されたエンコーディングでファイルが読み込まれます。pageEncoding属性が省略されている場合は，contentType属性が使用されます。

HTMLファイル

HTMLファイルの文字コードのままブラウザに送信されます。

C　J2EEサーバ〜データベース

データベース

JDBCドライバによって，Unicodeがデータベース格納文字コードに変換されます。

D　データベース〜J2EEサーバ

データベース

JDBCドライバによって，データベース格納文字コードがUnicodeに変換されます。

E　J2EEサーバ〜ブラウザ

レスポンスヘッダ

Webコンテナによって，レスポンスヘッダの文字コードがISO-8859-1に変換されます。

レスポンスボディ

サーブレットの場合

ServletResponseクラスのsetContentTypeメソッドによって文字コードを指定します。

JSPの場合

pageディレクティブのcontentType属性で文字コードを指定します。

参考

「文字化け」について

アプリケーションの実行環境では，文字コードはUnicodeとして扱われます。このため，ブラウザから送信された文字列は一度Unicodeに変換されます。また，データベースへのアクセス時にはUnicodeとデータベース格納文字コード間の文字コード変換，レスポンス時にはUnicodeからレスポンスの文字コードへの変換をする必要があります。これらの文字コード変換時に適切な変換をしないと，文字化けする原因になります。

これはシフトJISと呼ばれる文字コードに機種依存文字が含まれることや，同じ文字でもUnicodeへの変換結果がほかの文字コードと異なっているもの※があるために発生します。例えば，ブラウザから機種依存文字を含んだ文字データが送信され，これをUnicodeに変換した場合，レスポンス時にこの文字列をシフトJISに変換すると，文字化けする結果となります。

クライアントのOSをWindowsに限定できる場合は，文字コードをシフトJISではなくMS932またはWindows-31Jと指定することで，文字化けを避けられます。

注※

−，〜，‖，¢，£，¬などの文字が該当します。

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

ブラウザとアプリケーション間で文字コード変換をするときに使用するメソッド，およびJSPとJavaScriptの実装時の注意事項について説明します。

(1)　ブラウザとアプリケーション間の文字コード変換で使用するメソッド

ブラウザを使用して送信されたクエリ文字列，POSTデータは，HttpServletRequestクラスのメソッドを使用して取得します。HttpServletRequestクラスのうち，文字コード変換に関係のあるメソッドと使用時の注意事項を示します。

(a)　setCharacterEncodingメソッド

リクエストのメッセージボディで使われている文字コードを設定します。このメソッドは，getParameterメソッドや，getReaderメソッドを使って入力ストリームから読み込む前に実行されなければなりません。

(a) setCharacterEncodingメソッド

リクエストのメッセージボディ，およびGETリクエストのクエリで送信されたパラメタに使われている文字コードを設定します。このメソッドは，getParameterメソッドや，getReaderメソッドを使って入力ストリームから読み込む前に実行されなければなりません。

setCharacterEncodingメソッドで設定した文字コードが使用される範囲を次の表に示します。

表A‒3　setCharacterEncodingメソッドで設定した文字コードが使用される範囲

メソッド

HTMLのフォームから送信されたデータ（クエリも含む）

左記以外のメッセージボディ

getParameter

○

−

getParameterNames

○

−

getParameterValues

○

−

getParameterMap

○

−

getInputStream

×

×

getReader

×

△

getQueryString

×

−

（凡例）

○：取得した値はsetCharacterEncodingメソッドで設定した文字コードとしてUnicodeに変換される。

△：文字データはsetCharacterEncodingメソッドで設定した文字コードに変換される。

×：エンコードされたままの文字列が取得される。

−：取得できない。

(b)　getParameterメソッド

パラメタの名称を指定して，リクエストに含まれるパラメタの値を取得します。取得した値はURLデコードされ，Unicodeに変換されます。パラメタの名称やパラメタの値を取得する前に，setCharacterEncodingメソッドを用いて文字コードを指定する必要があります。指定しなかった場合，ISO-8859-1としてUnicodeに変換されます。HttpServletRequestクラスのgetParameterNamesメソッド，getParameterValuesメソッド，getParameterMapメソッドも同様です。

(c)　getInputStreamメソッド

リクエストのメッセージボディに含まれているバイナリデータを読み込むためのストリームを取得します。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります

(d)　getReaderメソッド

リクエストのメッセージボディにBufferedReaderクラスを使い，文字データとして取り出します。文字データはメッセージボディと同じ文字コードに変換されます。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります。

(e)　getQueryStringメソッド

リクエストされたURLのパスの後ろに含まれているクエリ文字列を返します。HTMLのフォームから送信されたデータからはエンコードされたままの文字列が取得されるので，取得した文字列を適切な文字コードでデコードする必要があります。

(2)　JSPのファイルインクルード時の注意事項

JSPファイルのincludeディレクティブでファイルをインクルードする場合には，インクルード元となるJSPファイルでcontentType属性を使用してエンコードを指定してください。また，JSPファイルの文字コードはpageEncoding属性に指定してください。指定しない場合はインクルード先の文字が正常に表示されない場合があります。

(3)　JavaScriptを使用してクエリ文字列を作成する場合の注意事項

JavaScriptのencodeURI関数およびencodeURIComponent関数※を使用すると，UTF-8でURLエンコードできます。この関数を用いて変換した文字列をクエリ文字列として使用してください。この場合，J2EEサーバ側でUTF-8としてUnicodeに変換すると，日本語の文字列データを取得できます。

注※

encodeURI関数とencodeURIComponent関数の相違は，「,/?:@&=+$,#」などの特殊文字を変換するかどうかです。encodeURI関数は「,/?:@&=+$,#」などの特殊文字を変換しません。

JavaScriptのescape関数はブラウザの種類やバージョンによって動作が異なります。escape関数で変換された文字列は，サーバ側で正常に扱えないため，escape関数を使用しないで，encodeURI関数またはencodeURIComponent関数を使用するようにしてください。

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

アプリケーションサーバのクラスローダ構成には，デフォルトのクラスローダ構成，ローカル呼び出し最適化機能を使用したときのクラスローダ構成，および下位互換用のクラスローダ構成の3種類があります。それぞれのクラスローダ構成およびクラスローダに設定されるクラスパスについて説明します。

また，クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにするライブラリ競合回避機能についても説明します。

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

新規インストール後のデフォルトのクラスローダ構成を次に示します。

図B‒1　デフォルトのクラスローダ構成

各クラスローダの内容を次に示します。

システムクラスローダ

Application Serverのコンポーネントが提供するクラスをロードします。

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

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

コネクタクラスローダ

単体デプロイされたリソースアダプタに含まれるクラスをロードします。J2EEサーバ内に一つだけ存在します。

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

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

JavaBeansクラスローダ

JavaBeansリソースのクラスをロードします。

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

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

アプリケーションクラスローダ

アプリケーション内のEJB-JAR，ライブラリJAR，リソースアダプタに含まれるクラスをロードします。アプリケーションごとに存在します。クラス名はcom.hitachi.software.ejb.server.ApplicationClassLoaderです。

生成タイミング：J2EEアプリケーション開始時

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE42143-Iが出力されます（「?」はログの面数）。

破棄タイミング：J2EEアプリケーション停止時

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE42144-Iが出力されます（「?」はログの面数）。

Webアプリケーションクラスローダ

J2EEアプリケーション内のWARファイルに含まれるクラスをロードします。WARファイルごとに存在します。クラス名はorg.apache.catalina.loader.WebappClassLoaderです。

生成タイミング：J2EEアプリケーション開始時（Webアプリケーション開始時）

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE39219-Iが出力されます（「?」はログの面数）。

破棄タイミング：J2EEアプリケーション停止時（Webアプリケーション停止時）

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE39220-Iが出力されます（「?」はログの面数）。

JSPクラスローダ

JSPファイルおよびタグファイルをコンパイルしたときに生成されたクラスをロードします。JSPごとに存在します。

生成タイミング：JSPクラスロード時

破棄タイミング：J2EEアプリケーション停止時（Webアプリケーション停止時）

ポイント

リソースアダプタのロードについて

J2EEリソースアダプタとしてデプロイしたリソースアダプタは，コネクタクラスローダでロードされます。J2EEアプリケーションに含めて使用するリソースアダプタは，アプリケーションクラスローダでロードされます。

注意事項

クラスローダの破棄について

J2EEアプリケーションの停止後，Webアプリケーションクラスローダまたはアプリケーションクラスローダのファイナライズ処理※（finalizeメソッドの処理）が実行されたタイミングで，KDJE39220-IまたはKDJE42144-Iのメッセージが出力されます。

このメッセージが出力されたあと，FullGCが発生したタイミングで，クラスローダとアプリケーションはヒープから解放されます。

注※　ファイナライズ処理は，ファイナライズ処理専用のスレッド（ファイナライザスレッド）で実行されます。ファイナライザスレッドは，JavaVM実行時に常に一つあり，他のJavaスレッドと並行して動作して，オブジェクトのfinalize()メソッドを一つずつ処理します。

KDJE39220-IまたはKDJE42144-Iのメッセージが出力されない場合，次の原因が考えられます。

原因

(C-1)：アプリケーションクラスローダやアプリケーションへのソフト参照が残っている。

(C-2)：Explicitヒープに配置されたオブジェクトからアプリケーションクラスローダやアプリケーションへの参照が残っている。

(C-1)〜(C-2)の原因について，それぞれ次の(I-1)〜(I-2)の原因の切り分けを実施して，メッセージが出力されるか確認してください。

原因の切り分け

(I-1)：-XX:SoftRefLRUPolicyMSPerMB=0を指定して実行する。

なお，SoftRefLRUPolicyMSPerMBオプションについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.9　Javaヒープ内のMetaspace領域のメモリサイズの見積もり」を参照してください。

(I-2)：明示管理ヒープ機能が有効の場合は，明示管理ヒープ機能を無効(-XX:-HitachiUseExplicitMemory)にする。

なお，明示管理ヒープ機能については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.2　JavaVM拡張オプションの詳細」を参照してください。

(C-1)〜(C-2)の原因のどれにも該当しない場合で，アプリケーションの開始または停止を繰り返してもKDJE39220-IまたはKDJE42144-Iメッセージが出力されないときは，メモリリークが発生しているおそれがあります。

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

ローカル呼び出し最適化機能を利用する場合，デフォルトのクラスローダとはクラスローダ構成が異なります。ローカル呼び出し最適化機能は，別のアプリケーションのEnterprise Beanを高速で呼び出すことができる機能です。

ローカル呼び出し最適化機能を使用するには，J2EEサーバ用ユーザ定義ファイル（<Application Serverのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties）に次の設定をします。

ejbserver.rmi.localinvocation.scope=all

ローカル呼び出し最適化時のクラスローダ構成を次に示します。

図B‒2　ローカル呼び出し最適化時のクラスローダ構成

各クラスローダの内容を次に示します。

システムクラスローダ

Application Serverのコンポーネントが提供するクラスをロードします。

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

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

コネクタクラスローダ

単体デプロイされたリソースアダプタに含まれるクラスをロードします。J2EEサーバ内に一つだけ存在します。

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

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

JavaBeansクラスローダ

JavaBeansリソースのクラスをロードします。

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

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

J2EEコンテナクラスローダ

すべてのアプリケーションクラスローダの親クラスローダとなり，すべてのアプリケーションクラスローダが持つクラスパスが設定されます。J2EEコンテナクラスローダは，J2EEサーバ内に一つだけ存在します。

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

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

アプリケーションクラスローダ

アプリケーション内のEJB-JAR，ライブラリJAR，およびリソースアダプタに含まれるクラスをクラスパスに持ちます。アプリケーションごとに存在します。ローカル呼び出し最適化時には親クラスローダであるJ2EEコンテナクラスローダにも，アプリケーションクラスローダが持つクラスパスが設定されているため，このクラスローダでは何もロードされません。クラス名はcom.hitachi.software.ejb.server.ApplicationClassLoaderです。

生成タイミング：J2EEアプリケーション開始時

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE42143-Iが出力されます（「?」はログの面数）。

破棄タイミング：J2EEアプリケーション停止時

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE42144-Iが出力されます（「?」はログの面数）。

Webアプリケーションクラスローダ

J2EEアプリケーション内のWARファイルに含まれるクラスをロードします。WARファイルごとに存在します。クラス名はorg.apache.catalina.loader.WebappClassLoaderです。

生成タイミング：J2EEアプリケーション開始時（Webアプリケーション開始時）

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE39219-Iが出力されます（「?」はログの面数）。

破棄タイミング：J2EEアプリケーション停止時（Webアプリケーション停止時）

cjmessage?.log（J2EEサーバの稼働ログ）にKDJE39220-Iが出力されます（「?」はログの面数）。

JSPクラスローダ

JSPファイルおよびタグファイルをコンパイルしたときに生成されたクラスをロードします。JSPごとに存在します。

生成タイミング：JSPクラスロード時

破棄タイミング：J2EEアプリケーション停止時（Webアプリケーション停止時）

クラスローダの破棄についての注意事項は，「付録B.1　デフォルトのクラスローダ構成」を参照してください。

ポイント

リソースアダプタのロードについて

J2EEリソースアダプタとしてデプロイしたリソースアダプタは，コネクタクラスローダでロードされます。J2EEアプリケーションに含めて使用するリソースアダプタは，アプリケーションクラスローダでロードされます。

注意事項

プロパティにejbserver.rmi.localinvocation.scope=allを設定して実行するときには，次の点に注意してください。

J2EEアプリケーションが持つEJB-JARやライブラリJARは同一のクラスローダでロードされるため，同名のクラスはJ2EEアプリケーション間で共有されます。内容の異なる同名クラスが存在する場合は，Javaの仕様上，先にロードされたクラスだけが有効となります。なお，WAR内のクラスはWAR単位に存在するクラスローダによってロードされますので共有の対象外となります。

J2EEアプリケーションのEJB-JARやライブラリJARを入れ替える場合は，J2EEアプリケーションを停止したあとにJ2EEサーバを再起動してください。再起動後に有効となります。

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

クラスローダに設定されるクラスパス，およびクラスローダがクラスをロードするときのクラスの検索順序を示します。

コネクタクラスローダ

コネクタクラスローダは単体RARのクラスをロードするクラスローダです。単体デプロイ済みRARファイルに含まれているJARファイルを，クラスパスに設定します。

J2EEコンテナクラスローダ

J2EEコンテナクラスローダは，ejbserver.rmi.localinvocation.scope=all（ローカル呼び出し最適化機能を使用する）を指定したときに有効になるクラスローダです。すべてのアプリケーションクラスローダの親クラスローダとなり，開始状態にあるすべてのアプリケーションクラスローダのクラスパスを自分のクラスパスに持ちます。

アプリケーションクラスローダ

アプリケーションクラスローダは，J2EEアプリケーション内のEJB-JAR，ライブラリJAR，およびコンテナ生成クラスをロードします。設定されるクラスパスの順序を次に示します。

J2EEアプリケーションに含まれるRARに含まれているJARファイル

J2EEアプリケーションに含まれるEJB-JAR

参照方式のライブラリ

J2EEアプリケーションに含まれるライブラリJAR

Naming切り替え機能によって参照している別アプリケーションのEJB-JARファイル（参照先のアプリケーションが同一J2EEサーバに存在する場合）

付録B.4　ライブラリ競合回避機能

ここでは，ライブラリ競合回避機能について説明します。

(1)　ライブラリ競合回避機能の概要

ライブラリ競合回避機能は，クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能です。この機能を使用すると，ユーザアプリケーションに含めることができないライブラリを，ユーザアプリケーションに含めることができます。ユーザアプリケーションに含めることができないライブラリについては，「20.4　ユーザアプリケーションに含めるライブラリの注意事項」を参照してください。

注意事項

この機能を使用するときの注意事項を次に示します。

V9互換モードではこの機能は使用できません。

この機能は，デフォルトのクラスローダ構成の場合にだけ有効になります。デフォルトのクラスローダ構成については「付録B.1　デフォルトのクラスローダ構成」を参照してください。

ローカル呼び出し最適化時のクラスローダ構成の場合，この機能は無効になります。ローカル呼び出し最適化時のクラスローダ構成については「付録B.2　ローカル呼び出し最適化時のクラスローダ構成」を参照してください。

「java.」から始まるパッケージのクラスは，この機能では検索できません。

(2)　クラス・リソースの検索順序

ライブラリ競合回避機能のクラス・リソースの検索順序を次の図に示します。

図B‒3　クラス・リソースの検索順序

この図では，JSP以外のクラスを検索する場合の検索順序を示しています。JSP以外のクラスを検索する場合，親クラスローダに委譲します。親クラスローダでクラスが見つからなかったときも，JSPクラスローダでは検索しません。JSPのクラスを検索する場合，JSPクラスローダは，親クラスローダに委譲せずJSPクラスローダだけを検索します。

(3)　クラス・リソースの検索処理

ライブラリ競合回避機能の有効・無効の設定および検索対象によって，クラス・リソースの検索処理が変わります。詳細を次の表に示します。

表B‒1　クラス・リソースの検索処理

有効・無効の設定

検索対象

検索処理

無効

クラス

アプリケーションクラスローダの場合

親クラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでクラスを検索します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

Webアプリケーションクラスローダの場合

検索対象が「java.」から始まる場合，システムクラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

親クラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでクラスを検索します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

リソース

親クラスローダに，検索を委譲します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでリソースを検索します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，nullを返します。

有効

対象パッケージから始まるクラス

自身のクラスローダでクラスをロードします。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

親クラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

対象パッケージ以外から始まるクラス

アプリケーションクラスローダの場合

親クラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでクラスを検索します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

Webアプリケーションクラスローダの場合

検索対象が「java.」から始まる場合，システムクラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

親クラスローダに，検索を委譲します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでクラスを検索します。

検索に成功した場合，クラスを返し処理を終了します。

検索に失敗した場合，ClassNotFoundExceptionをスローします。

対象パッケージのファイル（リソースとして取得する場合），または対象リソース

自身のクラスローダでリソースを検索します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

親クラスローダに，検索を委譲します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，nullを返します。

対象パッケージのファイル（リソースとして取得する場合）と対象リソース以外

親クラスローダに，検索を委譲します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，次の処理を実施します。

自身のクラスローダでリソースを検索します。

検索に成功した場合，リソースを返し処理を終了します。

検索に失敗した場合，nullを返します。

(4)　設定方法

ライブラリ競合回避機能の有効・無効の設定，対象パッケージおよび対象リソースは，J2EEサーバのusrconf.propertiesのシステムプロパティで設定します。各設定項目のシステムプロパティを次の表に示します。

表B‒2　ライブラリ競合回避機能のシステムプロパティ

設定項目

システムプロパティ

有効・無効

ejbserver.deploy.LibraryConflictAvoid.<J2EEアプリケーション名>.enabled

対象パッケージ

ejbserver.deploy.LibraryConflictAvoid.<J2EEアプリケーション名>.package

対象リソース

ejbserver.deploy.LibraryConflictAvoid.<J2EEアプリケーション名>.resource

システムプロパティの詳細は，「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.3(5)(j)　ejbserver.deployから始まるキー」を参照してください。

(5)　設定が有効になった場合の通知

アプリケーションクラスローダ生成時にライブラリ競合回避機能が有効な場合，ライブラリ競合回避機能が有効であることを示すメッセージ「KDJE42411-I」をアプリケーションごとにメッセージログに出力します。

付録C　JPAプロバイダとEJBコンテナ間の規約

ここでは，JPAプロバイダとEJBコンテナ間の規約について説明します。

付録C.1　ランタイムに関する規約

ランタイムに関する規約には，コンテナ側の責任とJPAプロバイダ側の責任があります。

(1)　コンテナ側の責任

トランザクションスコープの永続化コンテキストに関する規約

トランザクションスコープの永続化コンテキストが使用されている場合に，JTAトランザクションにエンティティマネージャが関連づいていないときには，コンテナは次の処理を実行します。

コンテナは次の場合に，EntityManagerFactory.createEntityManagerを呼び出して新しいエンティティマネージャを作成します。

JTAトランザクションのスコープ内のビジネスメソッドで，トランザクションスコープの永続化コンテキストを使用するエンティティマネージャのメソッドが初めて呼び出された場合

JTAトランザクションが決着（コミットまたはロールバック）したあとに，コンテナはEntityManager.closeを呼び出して，エンティティマネージャをクローズします。

また，コンテナは次の条件をすべて満たすと，TransactionRequiredExceptionをスローします。

トランザクションスコープの永続化コンテキストが使用されている場合

トランザクションがアクティブでない場合

アプリケーションからEntityManagerのpersist，remove，merge，refreshメソッドが呼び出された場合

拡張永続化コンテキストに関する規約

拡張永続化コンテキストが使用されている場合は，コンテナは次の処理を行います。

コンテナは次の場合に，EntityManagerFactory.createEntityManagerを呼び出して新しいエンティティマネージャを作成します。

Stateful Session Beanのインスタンスが作成された際に，拡張永続化コンテキストを使用するエンティティマネージャへの参照が定義されている場合

コンテナは次のタイミングで，EntityManager.closeを呼び出してエンティティマネージャをクローズします。

エンティティマネージャを作成したStateful Session Bean，および同じ永続化コンテキストを引き継いだStateful Session Beanが削除されたとき

コンテナ管理のトランザクションを使用するStateful Session Beanのビジネスメソッドの呼び出し時に，エンティティマネージャがJTAトランザクションと関連づけられていない場合には，コンテナはエンティティマネージャをJTAトランザクションに関連づけ，EntityManager.joinTransactionを呼び出します。JTAトランザクションにすでに別のエンティティマネージャが関連づけられている場合には，コンテナはEJBExceptionをスローします。

ビーン管理のトランザクションを使用するStateful Session Beanのビジネスメソッド内でUserTransaction.beginが呼び出された場合には，コンテナはエンティティマネージャをJTAトランザクションと関連づけ，EntityManager.joinTransactionを呼び出します。なお，ビーン管理のトランザクションについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.2　BMT」を参照してください。

コンテナ管理のエンティティマネージャに関する規約

コンテナ管理のエンティティマネージャを使用している場合に，アプリケーションがEntityManager.closeを呼び出すと，コンテナはIllegalStateExceptionをスローします。

@PersistenceCotnextまたはDDの<persistence-context-ref>タグで，プロパティが指定された場合には，コンテナはEntityManagerFactory.createEntityManager(Map map)メソッドを使用してエンティティマネージャを作成し，指定されたプロパティをmap引数に含めてJPAプロバイダに渡します。

コネクションの自動クローズ機能について

アプリケーションサーバの場合，Session BeanやWebコンポーネントの延長でJPAプロバイダが取得したコネクションは，コンテナの自動クローズ機能によって自動的にクローズされることがあります。コネクションの自動クローズ機能とは，コネクションのリークを防止するための機能です。

コネクションは，次の条件を満たすと自動クローズの対象となります。

Stateless Session Beanで取得したコネクションは，ビジネスメソッドからリターンするときに，自動クローズの対象となります。

Stateful Session Beanで取得したコネクションは，Stateful Session Beanが破棄されるときに，自動クローズの対象となります。

Webコンポーネントで取得したコネクションは，サービスメソッドからリターンするときに，自動クローズの対象となります。

ただし，これらの条件に当てはまる場合でも，コネクションがJTAトランザクションに参加しているときには，JTAトランザクションがコミットするまで自動クローズが保留されます。

(2)　JPAプロバイダ側の責任

アプリケーションで使用するエンティティマネージャが，トランザクションスコープの永続化コンテキストを使用するように定義されているか，拡張永続化コンテキストを使用するように定義されているかは，JPAプロバイダには伝わりません。JPAプロバイダでの責任は，コンテナが要求したときにエンティティマネージャを作成し，トランザクションからトランザクションの決着の通知を受け取るためのSynchronizationをトランザクションに登録することです。

コンテナがEntityManagerFactory.createEntityManagerを呼び出したときには，JPAプロバイダは新しいエンティティマネージャを作成し，それをコンテナに返す必要があります。JTAトランザクションがアクティブである場合は，JPAプロバイダはSynchronizationをJTAトランザクションに登録する必要があります。

コンテナがEntityManager.joinTransactionを呼び出したときには，JPAプロバイダはSynchronizationをJTAトランザクションに登録する必要があります。ただし，以前にjoinTransactionが呼び出されていて，JTAトランザクションにSynchronizationを登録済みの場合には，何もする必要はありません。

JTAトランザクションがコミットされるときには，JPAプロバイダはすべての変更されたエンティティの状態を，データベースにフラッシュする必要があります。

JTAトランザクションがロールバックされるときには，JPAプロバイダは，すべてのmanaged状態のエンティティをdetached状態にする必要があります。

JPAプロバイダがトランザクションのロールバックの原因になる例外をスローする場合には，JPAプロバイダがトランザクションをロールバックにマークする必要があります。

コンテナがEntityManager.closeを呼び出した場合，そのエンティティマネージャが関係したすべての未解決トランザクションが決着されたあとに，JPAプロバイダはすべての確保したリソースを解放する必要があります。エンティティマネージャがすでにクローズされている場合には，JPAプロバイダはIllegalStateExceptionをスローする必要があります。

コンテナがEntityManager.clearを呼び出した場合，JPAプロバイダはすべてのmanaged状態のエンティティをdetached状態にする必要があります。

(3)　javax.transaction.TransactionSynchronizationRegistryインタフェース

JPAプロバイダは，トランザクションにSynchronizationを登録したり，トランザクションをロールバックにマークしたりするために，TransactionSynchronizationRegistryインタフェースを使用できます。TransactionSynchronizationRegistryのインスタンスは，JNDIを使用して「java:comp/TransactionSynchronizationRegistry」という名前でルックアップできます。

インタフェース定義は標準仕様書を参照してください。

付録C.2　デプロイメントに関する規約

デプロイメントに関する規約には，コンテナ側の責任とJPAプロバイダ側の責任があります。

(1)　コンテナ側の責任

デプロイメント時に，コンテナはアプリケーション内の決められた場所にパッケージングされたpersistence.xmlを検索します。アプリケーション内にpersistence.xmlが存在する場合には，コンテナはpersistence.xmlに定義された永続化ユニットの定義を処理します。なお，コンテナが検索する場所については，「5.8　persistence.xmlでの定義」を参照してください。

コンテナはpersistence.xmlファイルを指定されたバージョンのpersistence.xmlスキーマで検証します。検証の結果，エラーが発生した場合にはユーザに通知します。persistence.xmlにプロバイダやデータソースの情報が指定されていない場合には，デフォルト値が使用されます。使用されるデフォルト値については，「5.8　persistence.xmlでの定義」を参照してください。コンテナが永続化ユニットのエンティティマネージャファクトリを作成するときには，JPAプロバイダにプロパティを渡すことがあります。

コンテナは，persistence.xmlで永続化ユニットごとに定義されたjavax.persistence.spi.PersistenceProviderの実装クラスのインスタンスを作成し，createContainerEntityManagerFactoryメソッドを呼び出して，コンテナ管理のエンティティマネージャを作成するためのEntityManagerFactoryを取得します。永続化ユニットのメタデータは，PersistenceUnitInfoオブジェクトとして，createContainerEntityManagerFactoryメソッドの引数でJPAプロバイダに渡されます。コンテナは一つの永続化ユニット定義に対して，一つだけEntityManagerFactoryを作成し，そのEntityManagerFactoryから複数のEntityManagerを作成します。

永続化ユニットが再デプロイされる場合には，コンテナはすでに取得したEntityManagerFactoryのcloseメソッドを呼び出したあと，createContainerEntityManagerFactoryを新しいPersistenceUnitInfoとともに呼び出します。

コンテナはvalidation-modeでNONE以外が指定された場合，createContainerEntityManagerFactoryに引き渡すMapにValidatorFactoryのインスタンス（javax.persistence.validation.factoryキー）を格納します。

(2)　JPAプロバイダ側の責任

JPAプロバイダはPersistenceProvider SPIを実装し，PersistenceProviderのcreateContainerEntityManagerFactoryメソッドが呼ばれたときに，引数で渡される永続化ユニットのメタデータ（PersisetnceUnitInfo）を使用して，EntityManagerFactoryを作成し，コンテナに返す必要があります。

JPAプロバイダは，永続化ユニットに含まれるマネージドクラス（エンティティクラスなど）のメタデータアノテーションを処理します。また，永続化ユニットでO/Rマッピングファイルが使用されている場合には，JPAプロバイダが解釈する必要があります。このとき，O/Rマッピングファイルを，指定されたバージョンのO/Rマッピングスキーマを使用して検証し，エラーが発生した場合はユーザに通知する必要があります。

(3)　javax.persistence.spi.PersistenceProviderインタフェース

JPAプロバイダは，javax.persistence.spi.PersistenceProviderインタフェースを実装する必要があります。このインタフェースはコンテナによって呼び出されるものであり，アプリケーションから呼び出すものではありません。PersistenceProviderの実装クラスは，publicで引数のないコンストラクタを持っている必要があります。

インタフェース定義は標準仕様書を参照してください。

(4)　javax.persistence.spi.PersistenceUnitInfoインタフェース

インタフェース定義は標準仕様書を参照してください。

参考

アプリケーションサーバでは，永続化ユニットでJTAデータソース，非JTAデータソースが定義されていない場合には，getJtaDataSource()またはgetNonJtaDataSource()はnullを返します。永続化ユニットでJTAデータソース，非JTAデータソースが定義されていない場合とは，次の状態を指します。

persistence.xmlで<jta-data-source>，<non-jta-data-source>が省略されていて，かつデフォルト値がシステムプロパティejbserver.jpa.defaultJtaDsName，ejbserver.jpa.defaultNonJtaDsNameで定義されていない場合

システムプロパティejbserver.jpa.overrideJtaDsName，ejbserver.jpa.overrideNonJtaDsNameも定義されていない場合

付録D　CJMSプロバイダのユースケース

ここでは，CJMSプロバイダを使用する場合のユースケースについて説明します。なお，ここで説明するユースケース以外の運用をした場合の動作は保証しません。

CJMSプロバイダを使用する場合は，ここで説明する手順に従って，環境構築および運用を実行してください。ここで示す以外の手順での構築・運用を実行した場合，CJMSプロバイダが正しく動作しないおそれがあります。

説明するユースケースの種類を次の表に示します。

表D‒1　CJMSプロバイダのユースケースの種類

分類

作業

作業内容

作業詳細

参照先

構築

新規環境構築

新規に環境を構築します。

CJMSプロバイダを使用する場合の環境構築

付録D.3

環境再構築

環境を再構築します。

CJMSプロバイダを使用するアプリケーションの追加

付録D.4

CJMSプロバイダを使用するアプリケーションの削除

付録D.5

運用

定期運用

CJMSプロバイダを使用する場合に定期的（日々またはその他の運用タイミング）で必要となる運用を実行します。

CJMSプロバイダサービスの開始（初回起動時）

付録D.6

CJMSプロバイダサービスの開始（稼働中システムの再起動時）

付録D.7

CJMSPリソースアダプタとCJMSPブローカーの状態確認

付録D.8

メッセージ配信状況の確認と滞留時の対処（CJMSPブローカーを一時停止する方法）

付録D.9

メッセージ配信状況の確認と滞留時の対処（アプリケーションを停止する方法）

付録D.10

CJMSプロバイダサービスの終了

付録D.11

非定期運用

CJMSプロバイダを使用する場合に非定期で必要となる運用を実行します。

送信先の圧縮

付録D.12

送信先サイズの変更

付録D.13

永続化サブスクライバーの削除

付録D.14

監視作業

CJMSプロバイダで使用されるリソースを監視します。

CJMSPブローカーの状態監視

付録D.15

CJMSPブローカーの詳細情報確認

付録D.16

送信先の状態確認

付録D.17

永続化サブスクライバーの状態確認

付録D.18

障害編

障害解析手順

CJMSプロバイダを使用中に障害が発生した場合に障害要因を解析します。

CJMSPリソースアダプタに問題が発生した場合の解析

付録D.19

CJMSPブローカーが障害によって停止したときの解析

付録D.20

CJMSプロバイダサービス無応答時の解析

付録D.21

障害回復手順

CJMSプロバイダを使用中に障害が発生した場合に回復します。

CJMSPリソースアダプタに問題が発生した場合の回復

付録D.22

CJMSPブローカーが障害によって停止したときの回復

付録D.23

CJMSプロバイダサービス無応答時の回復

付録D.24

削除

環境削除

CJMSプロバイダの環境を削除します。

CJMSプロバイダサービスインスタンスの削除

付録D.25

付録D.1　すべてのユースケースに共通の前提条件

すべてのユースケースに共通の前提条件を次に示します。

CJMSプロバイダに関連するコマンドの操作でユーザ確認をしないで強制的に実行したい場合，cjmsbrokerコマンドの場合は-forceオプション，cjmsicmdコマンドの場合は-fオプションを指定してください。

CJMSプロバイダに関連するコマンドの操作はCJMSPブローカーが起動しているマシンで実行してください。

CJMSプロバイダを使用する場合には，ユーザ権限にAdministrator権限が必要となります。

CJMSプロバイダに関連するコマンドの操作は複数同時に実行しないでください。

CJMSプロバイダのコマンドラインツール（cjmsbroker，cjmsicmd）に関するヘルプを表示するには，-hオプションまたは-helpオプションを指定してください。

J2EEサーバの起動オプションはセキュリティマネージャを使用しない設定にしてください。使用するに設定した場合，CJMSPリソースアダプタからリソースアクセスした際に権限不正のエラーが発生します。

J2EEサーバで使用するコマンドの操作でプロバイダURLを指定する場合は，次の例に従ってください。

実行形式

cjlistrar <サーバ名称> -nameserver <プロバイダURL>

実行例

cjlistrar MyServer -nameserver corbaname::localhost:900

<プロバイダURL>には，<プロトコル名称>::<ホスト名称>:<ポート番号>を指定します。

説明中に記述されているコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」を参照してください。

付録D.2　前提とするプロセスモデル

ユースケースが前提とするプロセスモデルを次の図に示します。

図D‒1　ユースケースが前提とするプロセスモデル

一つのCJMSPブローカーに対して，複数のJ2EEサーバからアクセスできます。

一つのJ2EEサーバに定義できるCJMSPリソースアダプタは一つとします。

付録D.3　CJMSプロバイダを使用する場合の環境構築

CJMSプロバイダを使用する場合の環境構築手順を次の図に示します。

図D‒2　CJMSプロバイダを使用する場合の環境構築手順

(1)　前提条件

運用管理ポータル（Management Server）によって，Application ServerのインストールおよびJ2EEサーバの構築が完了していること。

CJMSプロバイダは，アプリケーションサーバのインストール完了後，次のディレクトリにインストールされていること。

<COSMINEXUS_HOME>/CC/cjmsp

手順実行前に，このディレクトリがあることを確認してください。

(2)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが未起動（インポートされていない状態）であること。

CJMSPブローカープロセスが未起動であること。

アプリケーションが未起動（インポートされていない状態）であること。

(3)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。重なる場合には-nameオプションを指定し，存在しない任意の名称を付与してください。

(A2)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

CJMSPブローカーの状態が「OPERATING」であることを必ず確認してください。

注意事項

CJMSPブローカーが正常に起動されていない状態でCJMSPリソースアダプタを開始すると，例外が発生してCJMSプロバイダを使用することができません。

(A3)

<Queue名>，<Topic名>

Queue名またはTopic名

<最大メッセージ数>

QueueまたはTopicに格納できる最大メッセージ数

<メッセージトータルバイト数>

QueueまたはTopicの最大トータルメッセージバイト数

<最大プロデューサー数>

送信先の最大プロデューサー数

<最大コンシューマーフローリミット数>

一つの処理単位でコンシューマーに配送可能な最大メッセージ数

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A4)

<Queue名>，<Topic名>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)で作成した送信先が，指定したプロパティで正しく作られていることを確認してください。(A3)で指定した各引数と，表示内容の対応は次のとおりです。

maxNumMsgs → Max Number of Messages

maxNumProducers → Max Number of Producers

maxTotalMsgBytes → Max Total Message Bytes

consumerFlowLimit → Consumer Flow Limit

プロパティの表示例を次に示します。この例は，Queueを作成した場合の実行例です。

Destination Name                      TestQueue
Destination Type                      Queue
Destination State                     RUNNING
Created Administratively              true

Current Number of Messages
    Actual                            0
    Held in Transaction               0
Current Message Bytes
    Actual                            0
    Held in Transaction               0
Current Number of Producers           0
Current Number of Active Consumers    0

Max Number of Messages                unlimited (-1)
Max Total Message Bytes               unlimited (-1)
Max Number of Producers               unlimited (-1)

Consumer Flow Limit                   100

KDAN34151-I Successfully queried the destination.

(A5)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSP_HOME>

<Application Serverのインストールディレクトリ>/CC/cjmsp

(A6)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A7)

Connector属性ファイルは，テンプレートファイルをコピーして編集します。テンプレートファイルは，<CJMSP_HOME>/lib/templates/Cosminexus_JMS_Provider_RA_cfg.xmlを使用します。

送信先を使用するため，CJMSPリソースアダプタが提供する管理対象オブジェクトについての定義を行います。

設定例を次に示します。背景色付きの太字で番号を振っているタグを指定してください（番号は実際の定義には含まれません）。

    <config-property>
      <description xml:lang="en"></description>
      <config-property-name>ConnectionURL</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
(1)    <config-property-value>mq://localhost:7676/</config-property-value>
    </config-property>

     <config-property>
          <description xml:lang="en"></description>
          <config-property-name>clientId</config-property-name>
          <config-property-type>java.lang.String</config-property-type>
(2)      <config-property-value>Test</config-property-value>
     </config-property>

    <adminobject>
(3)  <adminobject-name>myQueue</adminobject-name>
(4)  <adminobject-interface>javax.jms.Queue</adminobject-interface>
(5)  <adminobject-class>com.cosminexus.jmsprovider.messaging.Queue</adminobject-class>
      <config-property>
        <description xml:lang="en"></description>
        <config-property-name>Name</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
(6)    <config-property-value>TestQueue</config-property-value>
      </config-property>
      <config-property>
        <description xml:lang="en"></description>
        <config-property-name>Description</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
    </adminobject>

各番号の指定内容を示します。

CJMSPブローカーを起動するホスト名およびポート番号を指定します。

クライアント識別子を指定します。永続化サブスクライバーを使用する場合に必要になります。

<adminobject-name>に管理対象オブジェクト名を指定します。CJMSPリソースアダプタ内でユニークである必要があります。

<adminobject-interface>に管理対象オブジェクトのクラスが実装するインタフェースを指定します。

Queueを使用する場合は，javax.jms.Queueを設定します。

Topicを使用する場合は，javax.jms.Topicを設定します。

<adminobject-class>に管理対象オブジェクトのクラスを設定します。

Queueを使用する場合は，com.cosminexus.jmsprovider.messaging.Queueを設定します。

Topicを使用する場合は，com.cosminexus.jmsprovider.messaging.Topicを設定します。

(A3)で指定した送信先の名前を設定します。

使用する送信先数分，<adminobject>タグを作成します。

注意事項

Message-driven Beanを使用する場合は，次の2点を設定してください。

次に示す(a)の値が(b)の値以上になるように設定してください。

デプロイしているすべてのMessage-driven Beanの(a)の合計数の値が，次に示す(c)の値以下になるように設定してください

アプリケーションプロパティファイルのMessage-driven Beanのインスタンスプール最大数

<pooled-instance>

<minimum>1</minimum>

(a) <maximum>2</maximum>

</pooled-instance>

アプリケーションプロパティファイルのEndpointのインスタンスプール最大数

<activation-config-property>

<activation-config-property-name>endpointPoolMaxSize</activation-config-property-name>

(b) <activation-config-property-value>1</activation-config-property-value>

</activation-config-property>

CJMSPリソースアダプタのConnector属性ファイルのWorkManagerのスレッドプール最大数

<property>

<property-name>MaxTPoolSize</property-name>

<property-type>int</property-type>

(c) <property-value>10</property-value>

<property-default-value>10</property-default-value>

</property>

(A8)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

<Connector属性ファイルパス>

属性ファイルの入力元パス

(A9)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

CJMSPリソースアダプタの接続テストでは，CJMSPブローカーとの接続を確立できることを確認しています。

(A10)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A11)

<サーバ名>

Management Serverで構築したサーバ名

「running <CJMSPリソースアダプタ表示名>」と表示されていることを確認します。

(A12)

アプリケーションのプロパティに，CJMSPリソースアダプタのコネクションファクトリ，管理対象オブジェクトを関連づける設定をします。

設定例を次に示します。背景色付きの太字で番号を振っているタグを編集してください（番号は実際の定義には含まれません）。

   <resource-ref>
(1)  <res-ref-name>jms/qcf</res-ref-name>
(2)  <res-type>javax.jms.QueueConnectionFactory</res-type>
(3)  <res-auth>Container</res-auth>
(4)  <res-sharing-scope>Unshareable</res-sharing-scope>
(5)  <linked-to>Cosminexus_JMS_Provider_RA!javax.jms.QueueConnectionFactory</linked-to>
   </resource-ref>
   <resource-env-ref>
(6)  <resource-env-ref-name>jms/TestQueue</resource-env-ref-name>
(7)  <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
        <linked-adminobject>
(8)  <resourceadapter-name>Cosminexus_JMS_Provider_RA</resourceadapter-name>
(9)  <adminobject-name>myQueue</adminobject-name>
        </linked-adminobject>
   </resource-env-ref>

各番号の指定内容を示します。

<res-ref-name>にリソース参照の名称を指定します。

<res-type>にリソース参照のタイプを指定します。コネクションファクトリの種類を指定します。

<res-auth>にリソースを使用するための認証をアプリケーション上で行うか，コンテナに任せるかを指定します。指定できる文字列を次に示します。

Application

Container

<res-sharing-scope>にリソース接続を共有するかどうかを指定します。指定できる文字列を次に示します。

Shareable

Unshareable

<linked-to>に対応するCJMSPリソースアダプタの表示名を指定します。次の文字列を指定します。

<CJMSPリソースアダプタ表示名>!<コネクション定義識別子>

<resource-env-ref-name>にリソース環境変数参照の名称を指定します。

<resource-env-ref-type>に管理対象オブジェクトの型として，送信先のインタフェースの種類を指定します。

<resourceadapter-name>にCJMSPリソースアダプタの表示名を指定します。

<adminobject-name>に(A7)の(3)で設定した，管理対象オブジェクト名を指定します。

(A13)

特にありません。

(A14)

特にありません。

付録D.4　CJMSプロバイダを使用するアプリケーションの追加

稼働中のシステムに対して新規にアプリケーションを追加する場合の手順を次の図に示します。

図D‒3　稼働中のシステムに対して新規にアプリケーションを追加する手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが未起動（インポートされていない状態）であること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

運用管理ポータル（Management Server）機能でアプリケーションを停止します。

(A2)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A3)

Connector属性ファイルは，テンプレートファイルをコピーし，編集します。

テンプレートファイルは，<CJMSP_HOME>/lib/templates/Cosminexus_JMS_Provider_RA_cfg.xmlを使用します。

送信先を使用するため，CJMSPリソースアダプタが提供する管理対象オブジェクトについての定義を行います。

設定例を次に示します。背景色付きの太字で番号を振っているタグを指定してください（番号は実際の定義には含まれません）。

    <config-property>
      <description xml:lang="en"></description>
      <config-property-name>ConnectionURL</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
(1)   <config-property-value>mq://localhost:7676/</config-property-value>
    </config-property>
     <config-property>
          <description xml:lang="en"></description>
          <config-property-name>clientId</config-property-name>
          <config-property-type>java.lang.String</config-property-type>
(2)   <config-property-value>Test</config-property-value>
    </config-property>

   <adminobject>
(3)    <adminobject-name>myQueue</adminobject-name>
(4)    <adminobject-interface>javax.jms.Queue</adminobject-interface>
(5)    <adminobject-class>com.cosminexus.jmsprovider.messaging.Queue</adminobject-class>
    <config-property>
      <description xml:lang="en"></description>
      <config-property-name>Name</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
(6)    <config-property-value>TestQueue</config-property-value>
    </config-property>
    <config-property>
     <description xml:lang="en"></description>
     <config-property-name>Description</config-property-name>
     <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
   </adminobject>

各番号の指定内容を示します。

CJMSPブローカーを起動するホスト名およびポート番号を指定します。

クライアント識別子を指定します。永続化サブスクライバーを使用する場合に必要になります。

<adminobject-name>に管理対象オブジェクト名を指定します。CJMSPリソースアダプタ内でユニークである必要があります。

<adminobject-interface>に管理対象オブジェクトのクラスが実装するインタフェースを指定します。

Queueを使用する場合は，javax.jms.Queueを設定します。

Topicを使用する場合は，javax.jms.Topicを設定します。

<adminobject-class>に管理対象オブジェクトのクラスを設定します。

Queueを使用する場合は，com.cosminexus.jmsprovider.messaging.Queueを設定します。

Topicを使用する場合は，com.cosminexus.jmsprovider.messaging.Topicを設定します。

送信先の名前を設定します。

使用する送信先数分，<adminobject>タグを作成します。

注意事項

Message-driven Beanを使用する場合は下記の2点を設定してください。

次に示す(a)の値が(b)の値以上になるように設定してください。

デプロイしているすべてのMessage-driven Beanの(a)の合計数の値が，次に示す(c)の値以下になるように設定してください

アプリケーションプロパティファイルのMessage-driven Beanのインスタンスプール最大数

<pooled-instance>

<minimum>1</minimum>

(a) <maximum>2</maximum>

</pooled-instance>

アプリケーションプロパティファイルのEndpointのインスタンスプール最大数

<activation-config-property>

<activation-config-property-name>endpointPoolMaxSize</activation-config-property-name>

(b) <activation-config-property-value>1</activation-config-property-value>

</activation-config-property>

CJMSPリソースアダプタのConnector属性ファイルのWorkManagerのスレッドプール最大数

<property>

<property-name>MaxTPoolSize</property-name>

<property-type>int</property-type>

(c) <property-value>10</property-value>

<property-default-value>10</property-default-value>

</property>

(A4)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

<Connector属性ファイルパス>

属性ファイルの入力元パス

(A5)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

CJMSPリソースアダプタの接続テストでは，CJMSPブローカーとの接続を確立できることを確認しています。

(A6)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A7)

<Queue名>，<Topic名>

Queue名またはTopic名

<最大メッセージ数>

QueueまたはTopicに格納できる最大メッセージ数

<メッセージトータルバイト数>

QueueまたはTopicの最大トータルメッセージバイト数

<最大プロデューサー数>

送信先の最大プロデューサー数

<最大コンシューマーフローリミット数>

一つの処理単位でコンシューマーに配送できる最大メッセージ数

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<Queue名> または<Topic名>には，(A3)の(6)で設定した，送信先の名前を入力する。

(A8)

<Queue名>，<Topic名>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A7)で作成した送信先が指定したプロパティで正しく作られていることを確認してください。(A7)で指定した各引数と，表示内容の対応は次のとおりです。

maxNumMsgs → Max Number of Messages

maxNumProducers → Max Number of Producers

maxTotalMsgBytes → Max Total Message Bytes

consumerFlowLimit → Consumer Flow Limit

指定したプロパティは次の表示で出力されます。この例は，Queueを作成した場合の実行例です。

Destination Name                      TestQueue
Destination Type                      Queue
Destination State                     RUNNING
Created Administratively              true

Current Number of Messages
    Actual                            0
    Held in Transaction               0
Current Message Bytes
    Actual                            0
    Held in Transaction               0
Current Number of Producers           0
Current Number of Active Consumers    0

Max Number of Messages                unlimited (-1)
Max Total Message Bytes               unlimited (-1)
Max Number of Producers               unlimited (-1)

Consumer Flow Limit                   100

KDAN34151-I Successfully queried the destination.

(A9)

アプリケーションのプロパティに，CJMSPリソースアダプタのコネクションファクトリ，管理対象オブジェクトを関連づける設定をします。

設定例を次に示します。背景色付きの太字で番号を振っているタグを指定してください（番号は実際の定義には含まれません）。

   <resource-ref>
(1)     <res-ref-name>jms/qcf</res-ref-name>
(2)     <res-type>javax.jms.QueueConnectionFactory</res-type>
(3)     <res-auth>Container</res-auth>
(4)     <res-sharing-scope>Unshareable</res-sharing-scope>
(5)     <linked-to>Cosminexus_JMS_Provider_RA!javax.jms.QueueConnectionFactory</linked-to>
   </resource-ref>
   <resource-env-ref>
(6)     <resource-env-ref-name>jms/TestQueue</resource-env-ref-name>
(7)     <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
        <linked-adminobject>
(8)       <resourceadapter-name>Cosminexus_JMS_Provider_RA</resourceadapter-name>
(9)       <adminobject-name>myQueue</adminobject-name>
        </linked-adminobject>
   </resource-env-ref>

各番号の指定内容を示します。

<res-ref-name>にリソース参照の名称を指定します。

<res-type>にリソース参照のタイプを指定します。コネクションファクトリの種類を指定します。

<res-auth>にリソースを使用するための認証元を，アプリケーション上で行うか，コンテナに任せるかを指定します。

指定できる文字列を次に示します。

Application

Container

<res-sharing-scope>にリソース接続を共有するかどうかを指定します。

指定できる文字列を次に示します。

Shareable

Unshareable

<linked-to>に対応するCJMSPリソースアダプタ表示名を指定します。

次の文字列を指定します。

<CJMSPリソースアダプタ表示名>!<コネクション定義識別子>

<resource-env-ref-name>にリソース環境変数参照の名称を指定します。

<resource-env-ref-type>に管理対象オブジェクトの型をします。送信先のインタフェースの種類を指定します。

<resourceadapter-name>にCJMSPリソースアダプタの表示名を指定します。

<adminobject-name>に(A3)の(3)で設定した，管理対象オブジェクト名を指定します。

(A10)

特にありません。

(A11)

特にありません。

付録D.5　CJMSプロバイダを使用するアプリケーションの削除

稼働中のシステムからアプリケーションを削除する場合の手順を次の図に示します。

図D‒4　稼働中のシステムからアプリケーションを削除する場合の手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

特にありません。

(A2)

運用管理ポータル（Management Server）機能によってアプリケーションを削除します。

(A3)

<種別>

q(Queue)またはt(Topic)

<送信先名>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A4)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)で削除した送信先が正しく削除されていることを確認してください。

(A5)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A6)

特にありません。

(A7)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタの表示名>

CJMSPリソースアダプタ表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A8)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

付録D.6　CJMSプロバイダサービスの開始（初回起動時）

システム構築直後など，初回起動時にCJMSプロバイダのサービスを起動する手順について説明します。この手順で開始した場合は，「付録D.11　CJMSプロバイダサービスの終了」で終了できます。

この手順に従って，CJMSPリソースアダプタの起動とアプリケーションの起動をした場合，J2EEサーバを再起動したときにはCJMSPリソースアダプタおよびアプリケーションはどちらも起動状態となります（ただし，前提条件としてCJMSPブローカーが先に起動されていることが必須条件となります）。

CJMSプロバイダサービスの開始手順（初回起動時）を次の図に示します。

図D‒5　CJMSプロバイダサービスの開始手順（初回起動時）

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが未起動であること。

CJMSPブローカープロセスが未起動であること。

アプリケーションが未起動であること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

管理コマンドプロパティファイルは，<CJMSP_HOME>/var/admin/config/admin.propertiesに格納されています。

設定できるプロパティ名と説明を次に記述します。ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.1　admin.properties（管理コマンドプロパティファイル）」を参照してください。

admin.logger.MessageLogFile.trace.level

管理コマンドのメッセージログレベルを指定します。

admin.logger.MessageLogFile.filepath

管理コマンドのメッセージログを出力するファイルパスを指定します。

admin.logger.MessageLogFile.filenum

管理コマンドで作成される最大メッセージログファイル数を指定します。

admin.logger.MessageLogFile.filesize

管理コマンドのメッセージログファイルの最大サイズを指定します。

admin.logger.ExceptionLogFile.filepath

管理コマンドの例外ログを出力するファイルパスを指定します。

admin.logger.ExceptionLogFile.filenum

管理コマンドで作成される最大例外ログファイル数を指定します。

admin.logger.ExceptionLogFile.filesize

管理コマンドの例外ログファイルの最大サイズを指定します。

(A2)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定し存在しない任意の名称を付与してください。

<ディレクトリパス>

VAR_HOMEを出力したいパスを指定します。

モードによるオプションの違い

通常モード

オプション指定は行いません（状態をリセットしないで，継続状態でCJMSプロバイダのサービスを起動します）。

永続データストアリセットモード

永続化メッセージ，永続化サブスクライバーが消去されます。

永続メッセージクリアモード

すべての永続化メッセージが消去されます。

永続サブスクリプションクリアモード

すべての永続化サブスクライバーが消去されます。

(A3)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号を指定します。

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A4)

CJMSPブローカープロパティファイルは，<VAR_HOME>/instances/<インスタンス名>/props/config.propertiesに格納されています。

このファイルは初めてCJMSPブローカーを起動した時に作成されます。そのため，(A2)(A3)の手順が必要になります。

設定できるプロパティ名と説明を次に記述します。ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.3　config.properties（CJMSPブローカー個別プロパティファイル）」を参照してください。

一時送信先を作成した場合，imq.autocreate.queue.consumerFlowLimitまたはimq.autocreate.topic.consumerFlowLimitの値が送信先のプロパティとして設定されます。

imq.hostname

すべての接続サービスのデフォルトのホスト名，またはIPアドレスを指定します。

imq.portmapper.port

CJMSPブローカーのポートマッパー用のポート番号を指定します。

imq.jms.tcp.port

jmsサービスのポート番号を指定します。

imq.admin.tcp.port

adminサービスのポート番号を指定します。

imq.persist.file.sync.enabled

ディスク書き込み操作を同期にするか，または非同期にするかのフラグを指定します。

imq.autocreate.queue.consumerFlowLimit

一つの処理単位でQueueのコンシューマーに配送可能な最大メッセージ数を指定します。

imq.autocreate.topic.consumerFlowLimit

一つの処理単位でTopicのコンシューマーに配送可能な最大メッセージ数を指定します。

imq.metrics.interval

メトリクス情報をログとコンソールに出力する時間間隔を秒単位で指定します。

broker.logger.MessageLogFile.trace.level

CJMSPブローカーのメッセージログレベルを指定します。

broker.logger.MessageLogFile.filenum

CJMSPブローカーで作成される最大メッセージログファイル数を指定します。

broker.logger.MessageLogFile.filesize

CJMSPブローカーのメッセージログファイルの最大サイズを指定します。

broker.logger.ExceptionLogFile.filenum

CJMSPブローカーで作成される最大例外ログファイル数を指定します。

broker.logger.ExceptionLogFile.filesize

CJMSPブローカーの例外ログファイルの最大サイズを指定します。

imq.instanceconfig.version

コンフィグプロパティのバージョンを指定します。

(A5)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定し存在しない任意の名称を付与してください。

<ディレクトリパス>

VAR_HOMEを出力したいパスを指定します。

<引数>

-Xms（最大ヒープサイズ），-Xmx（最小ヒープサイズ），-XX:+HitachiVerboseGC（GCが発生したときの拡張verbosegc情報を出力するオプション）などJavaVMオプションを指定します。

(A6)

Stateが「OPERATING」であることを確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A7)

<サーバ名>

Management Serverで構築したサーバ名

(A8)

特にありません。

付録D.7　CJMSプロバイダサービスの開始（稼働中システムの再起動時）

稼働中システムの再起動時にCJMSプロバイダのサービスを起動する手順について説明します。この手順で開始した場合は，「付録D.11　CJMSプロバイダサービスの終了」で終了できます。

CJMSプロバイダサービスの開始手順（稼働中システムの再起動時）を次の図に示します。

図D‒6　CJMSプロバイダサービスの開始手順（稼働中システムの再起動時）

(1)　プロセス前提条件

J2EEサーバプロセスが未起動であること。

CJMSPリソースアダプタが未起動であること。

CJMSPブローカープロセスが未起動であること。

アプリケーションが未起動であること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

管理コマンドプロパティファイルは，<CJMSP_HOME>/var/admin/config/admin.propertiesに格納されています。

設定できるプロパティ名と説明を次に記述します。ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.1　admin.properties（管理コマンドプロパティファイル）」を参照してください。

admin.logger.MessageLogFile.trace.level

管理コマンドのメッセージログレベルを指定します。

admin.logger.MessageLogFile.filepath

管理コマンドのメッセージログを出力するファイルパスを指定します。

admin.logger.MessageLogFile.filenum

管理コマンドで作成される最大メッセージログファイル数を指定します。

admin.logger.MessageLogFile.filesize

管理コマンドのメッセージログファイルの最大サイズを指定します。

admin.logger.ExceptionLogFile.filepath

管理コマンドの例外ログを出力するファイルパスを指定します。

admin.logger.ExceptionLogFile.filenum

管理コマンドで作成される最大例外ログファイル数を指定します。

admin.logger.ExceptionLogFile.filesize

管理コマンドの例外ログファイルの最大サイズを指定します。

(A2)

CJMSPブローカーのプロパティファイルは，<VAR_HOME>/instances/<インスタンス名>/props/config.propertiesに格納されています。

設定できるプロパティ名と説明を次に記述します。ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.3　config.properties（CJMSPブローカー個別プロパティファイル）」を参照してください。

一時送信先を作成した場合，imq.autocreate.queue.consumerFlowLimitまたはimq.autocreate.topic.consumerFlowLimitの値が送信先のプロパティとして設定されます。

imq.hostname

すべての接続サービスのデフォルトのホスト名，またはIPアドレスを指定します。

imq.portmapper.port

CJMSPブローカーのポートマッパー用のポート番号を指定します。

imq.jms.tcp.port

jmsサービスのポート番号を指定します。

imq.admin.tcp.port

adminサービスのポート番号を指定します。

imq.persist.file.sync.enabled

ディスク書き込み操作を同期にするか，または非同期にするかのフラグを指定します。

imq.autocreate.queue.consumerFlowLimit

一つの処理単位でQueueのコンシューマーに配送可能な最大メッセージ数を指定します。

imq.autocreate.topic.consumerFlowLimit

一つの処理単位でTopicのコンシューマーに配送可能な最大メッセージ数を指定します。

imq.metrics.interval

メトリクス情報をログとコンソールに出力する時間間隔を秒単位で指定します。

broker.logger.MessageLogFile.trace.level

CJMSPブローカーのメッセージログレベルを指定します。

broker.logger.MessageLogFile.filenum

CJMSPブローカーで作成される最大メッセージログファイル数を指定します。

broker.logger.MessageLogFile.filesize

CJMSPブローカーのメッセージログファイルの最大サイズを指定します。

broker.logger.ExceptionLogFile.filenum

CJMSPブローカーで作成される最大例外ログファイル数を指定します。

broker.logger.ExceptionLogFile.filesize

CJMSPブローカーの例外ログファイルの最大サイズを指定します。

imq.instanceconfig.version

コンフィグプロパティのバージョンを指定します。

(A3)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定し存在しない任意の名称を付与してください。

<ディレクトリパス>

VAR_HOMEを出力したいパスを指定します。

<引数>

-Xms（最大ヒープサイズ），-Xmx（最小ヒープサイズ），-XX:+HitachiVerboseGC（GCが発生したときの拡張verbosegc情報を出力するオプション）などJavaVMのオプションを指定します。

モードによるオプションの違い

通常モード

オプション指定は行いません（状態をリセットしないで，継続状態でCJMSプロバイダのサービスを起動します）。

永続データストアリセットモード

永続化メッセージ，永続化サブスクライバーが消去されます。

永続メッセージクリアモード

すべての永続化メッセージが消去されます。

永続サブスクリプションクリアモード

すべての永続化サブスクライバーが消去されます。

(A4)

Stateが「OPERATING」であることを確認します。

(A5)

運用管理ポータル（Management Server）機能によってJ2EEサーバを起動します。

CJMSPリソースアダプタとアプリケーションはJ2EEサーバ起動時に開始されます。

付録D.8　CJMSPリソースアダプタとCJMSPブローカーの状態確認

CJMSプロバイダのサービスが使用できる状態であるかどうかを確認する手順について説明します。

J2EEサーバとアプリケーションの状態については運用管理ポータル（Management Server）機能で確認してください。

CJMSPリソースアダプタとCJMSPブローカーの状態確認手順を次の図に示します。

図D‒7　CJMSPリソースアダプタとCJMSPブローカーの状態確認手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A2)

<サーバ名>

Management Serverで構築したサーバ名

CJMSPサービス起動状態

CJMSPブローカーが「OPERATING」かつCJMSPリソースアダプタが「running」の場合にCJMSプロバイダのサービスは開始されている状態です。

(A1)の結果例を次に示します。

----------------------
 Address       State
----------------------
localhost:7676   OPERATING

(A2)の結果例を次に示します。

running CJMS_Provider_RA

付録D.9　メッセージ配信状況の確認と滞留時の対処（CJMSPブローカーを一時停止する方法）

CJMSプロバイダのメッセージ配信状況を確認するとともに，メッセージが滞留していた場合は対処する手順について説明します。

この方法では，CJMSPブローカーの一時停止後にアプリケーションでタイムアウトが発生することによって例外が発生する場合があります。

安全にメッセージを削除したい場合は，「付録D.10　メッセージ配信状況の確認と滞留時の対処（アプリケーションを停止する方法）」を参照してください。

メッセージ配信状況の確認と滞留時の対処手順（CJMSPブローカーを一時停止する方法）を次の図に示します。

図D‒8　メッセージ配信状況の確認と滞留時の対処手順（CJMSPブローカーを一時停止する方法）

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

送信先（または永続化サブスクライバー）名とメッセージ数を確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<Topic名>

確認しようとしている永続化サブスクライバーが存在するTopic名

(A2)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)

jmsサービスが「PAUSED」の状態になっているか確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

出力例を次に示します。

-----------------------------------------------
Service Name    Port Number       Service State
-----------------------------------------------
admin           1248 (dynamic)         RUNNING
jms                0 (dynamic)         PAUSED

KDAN34113-I Successfully listed services.

(A4)

<種別>

q(Queue)またはt(Topic)

<名称>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<初期タイムアウト値>

デフォルトの初期タイムアウト値は10秒に設定されています。デフォルト値で処理がタイムアウトしてしまう場合には値を調節してください。

<永続化サブスクライバー名>

(A1)で確認した永続化サブスクライバー名

<クライアントID>

(A1)で確認したクライアントID

(A5)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A6)

jmsサービスが「RUNNING」の状態になっているかを確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

出力例を次に示します。

-----------------------------------------------
Service Name    Port Number       Service State
-----------------------------------------------
admin           1248 (dynamic)         RUNNING
jms             1337 (dynamic)         RUNNING

KDAN34113-I Successfully listed services.

付録D.10　メッセージ配信状況の確認と滞留時の対処（アプリケーションを停止する方法）

CJMSプロバイダのメッセージ配信状況を確認するとともに，メッセージが滞留していた場合に対処する手順について説明します。

アプリケーションを停止したくない場合は，「付録D.9　メッセージ配信状況の確認と滞留時の対処（CJMSPブローカーを一時停止する方法）」を参照してください。

メッセージ配信状況の確認と滞留時の対処手順（アプリケーションを停止する方法）を次の図に示します。

図D‒9　メッセージ配信状況の確認と滞留時の対処手順（アプリケーションを停止する方法）

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

送信先（または永続化サブスクライバー）名とメッセージ数を確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<Topic名>

確認しようとしている永続化サブスクライバーが存在するTopic名

(A2)

特にありません。

(A3)

<種別>

q(Queue)またはt(Topic)

<名称>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<初期タイムアウト値>

デフォルトの初期タイムアウト値は10秒に設定されています。デフォルト値で処理がタイムアウトしてしまう場合には値を調節してください。

<永続化サブスクライバー名>

(A1)で確認した永続化サブスクライバー名

<クライアントID>

(A1)で確認したクライアントID

付録D.11　CJMSプロバイダサービスの終了

CJMSプロバイダのサービスの終了の手順について説明します。

この手順で停止した場合は，「付録D.7　CJMSプロバイダサービスの開始（稼働中システムの再起動時）」の手順によって再起動できます。

CJMSプロバイダのサービスの終了手順を次の図に示します。

図D‒10　CJMSプロバイダのサービスの終了手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

特にありません。

(A2)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

付録D.12　送信先の圧縮

CJMSプロバイダで使用する送信先の圧縮手順について説明します。

送信先の圧縮手順を次の図に示します。

図D‒11　送信先の圧縮手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

送信先名とメッセージ数を確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A2)

特にありません。

(A3)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A4)

<種別>

q(Queue)またはt(Topic)

<名称>

Queue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

<初期タイムアウト値>

デフォルトの初期タイムアウト値は10秒に設定されています。デフォルト値で処理がタイムアウトしてしまう場合には値を調節してください。

(A5)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

付録D.13　送信先サイズの変更

CJMSプロバイダで使用する送信先のサイズ変更手順について説明します。

送信先サイズの変更手順を次の図に示します。

図D‒12　送信先サイズの変更手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

特にありません。

(A2)

<種別>

q(Queue)またはt(Topic)

<送信先名>

削除するQueue名またはTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)

<種別>

q(Queue)またはt(Topic)

<送信先名>

再作成するQueue名またはTopic名

<最大メッセージ数>

QueueまたはTopicに格納される最大メッセージ数

<メッセージトータルバイト数>

QueueまたはTopicに格納されるメッセージのトータルバイト数

<最大プロデューサー数>

送信先の最大プロデューサー数

<最大コンシューマーフローリミット数>

一つの処理単位でコンシューマーに配送可能な最大メッセージ数

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

実行結果の例を示します。

例：メッセージ最大数を100000，メッセージのトータルバイト数を12メガバイト，最大プロデューサー数を1000，最大コンシューマーフローリミット数を1000でQueueを作成した場合の例

C:¥>cjmsicmd create dst -t q -n Queue1 -o "maxNumMsgs=100000" -o "maxTotalMsgBytes=12m" -o "maxNumProducers=1000" -o "consumerFlowLimit=1000" -b localhost:7676
KDAN34140-I Successfully created the destination.

(A4)

特にありません。

付録D.14　永続化サブスクライバーの削除

CJMSプロバイダで使用する，永続化サブスクライバーの削除手順について説明します。

永続化サブスクライバーの削除手順を次の図に示します。

図D‒13　永続化サブスクライバーの削除手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<Topic名>

確認しようとしている永続化サブスクライバーが存在するTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

表示例を次に示します。

-----------------------------------------------------------------------
Durable Sub. Name   Client ID   Number of Messages   Durable Sub. State
-----------------------------------------------------------------------
DurableSUB1         clientId    9998                 INACTIVE
KDAN34323-I Successfully listed durable subscriptions.

(A2)

特にありません。

(A3)

<永続化サブスクライバー名>

(A1)で確認した永続化サブスクライバー名

<クライアントID>

(A1)で確認したクライアントID

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

付録D.15　CJMSPブローカーの状態監視

デバッグ，障害解析などによって，CJMSPブローカーを監視モードで起動する場合の手順について説明します。

この手順でCJMSPブローカーを再起動することによって，CJMSPブローカーを実行したコマンドプロンプト上にメトリクス情報が出力されます。

この監視状態を終了する場合には，「付録D.7　CJMSプロバイダサービスの開始（稼働中システムの再起動時）」を参照して，通常モードでCJMSPブローカーを再起動してください。

CJMSPブローカーの状態監視手順を次の図に示します。

図D‒14　CJMSPブローカーの状態監視手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

特にありません。

(A2)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)

CJMSPブローカーのプロパティファイルは，<VAR_HOME>/instances/<インスタンス名>/props/config.propertiesに格納されています。

状態監視モードでCJMSPブローカーを起動する場合は，次のプロパティを設定してください。

なお，詳細はマニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「6.2.3　config.properties（CJMSPブローカー個別プロパティファイル）」を参照してください。

imq.metrics.interval

メトリクス情報をログとコンソールに出力する時間間隔を秒単位で指定します。

(A4)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には，名称が重ならないように注意する必要があります。

重なる場合には，-nameオプションを指定し存在しない任意の名称を付与してください。

状態監視モードの表示例を次に示します。

 Connections: 0    JVM Heap: 2932736 bytes (731352 free) Threads: 0 (14-1010)
      In: 0 msgs (0 bytes)  0 pkts (0 bytes)
     Out: 0 msgs (0 bytes)  0 pkts (0 bytes)
 Rate In: 0 msgs/sec (0 bytes/sec)  0 pkts/sec (0 bytes/sec)
Rate Out: 0 msgs/sec (0 bytes/sec)  0 pkts/sec (0 bytes/sec)

(A5)

特にありません。

付録D.16　CJMSPブローカーの詳細情報確認

CJMSPブローカーの最新の詳細情報を確認する手順について，次の図に示します。

図D‒15　CJMSPブローカーの詳細情報確認手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

表示例を次に示します。

Instance Name                                                                    cjmsbroker
Primary Port                                                                       7676
Broker is Embedded                                                            false
Instance Configuration/Data Root Directory                     D:¥Hitachi¥CC¥cjmsp¥var
Current Number of Messages in System                           843
Current Total Message Bytes in System                           177030
Current Number of Messages in Dead Message Queue    0
Current Total Message Bytes in Dead Message Queue     0
KDAN34295-I Successfully queried the broker.

付録D.17　送信先の状態確認

送信先の最新状態を確認する手順について，次の図に示します。

図D‒16　送信先の状態確認手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

-tmpオプションを使用すると，一時送信先の状態を確認できます。

一時送信先の状態の確認ができるのは，アプリケーションを開始して一時送信先が有効になっている期間だけです。

-tmpオプション使用時の表示例を次に示します。

------------------------------------------------------------------------
   Name     Type    State   Producers  Consumers           Msgs
                                         Total    Count  UnAck  Avg Size
------------------------------------------------------------------------
Queue1         Queue  RUNNING  0          0          0      0      0.0
mq.sys.dmq  Queue  RUNNING  0          0          0      0      0.0
temporary_destination://queue/10.209.10.192/2139/1  Queue (temporary) 0          1          0      0      0.0
KDAN34110-I Successfully listed destinations.

付録D.18　永続化サブスクライバーの状態確認

永続化サブスクライバーの最新状態を確認する手順について，次の図に示します。

図D‒17　永続化サブスクライバーの状態確認手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<Topic名>

確認しようとしている永続化サブスクライバーが存在するTopic名

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

表示例を次に示します。

-----------------------------------------------------------------------
Durable Sub. Name   Client ID   Number of Messages   Durable Sub. State
-----------------------------------------------------------------------
DurableSUB1         clientId    9998                 INACTIVE
KDAN34323-I Successfully listed durable subscriptions.

付録D.19　CJMSPリソースアダプタに問題が発生した場合の解析

CJMSPリソースアダプタで問題が発生した状態からの解析手順について，次の図に示します。

図D‒18　CJMSPリソースアダプタに問題が発生した場合の解析手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<Application Serverのインストールディレクトリ>/CC/server/public/ejb/<サーバ名>/logs/cjms/<コネクタ名>下のログを確認し，問題の解析を行います。

(A2)

「付録D.22　CJMSPリソースアダプタに問題が発生した場合の回復」の手順に従って，CJMSプロバイダのサービスを回復してください。

付録D.20　CJMSPブローカーが障害によって停止したときの解析

CJMSPブローカーが障害によって停止した状態からの解析手順について，次の図に示します。

図D‒19　CJMSPブローカーが障害によって停止した状態からの解析手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<Application Serverのインストールディレクトリ>/CC/cjmsp/var/instances/<インスタンス名>/log下のログを確認し，問題の解析を行います。

(A2)

「付録D.23　CJMSPブローカーが障害によって停止したときの回復」の手順に従って，CJMSプロバイダのサービスを回復します。

付録D.21　CJMSプロバイダサービス無応答時の解析

CJMSプロバイダのサービス無応答時の解析手順を次の図に示します。

図D‒20　CJMSプロバイダサービス無応答時の解析手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

PRFトレースを採取します。

(A2)

J2EEサーバのスレッドダンプを採取します。

(A3)

<Application Serverのインストールディレクトリ>/CC/server/public/ejb/<サーバ名>/logs下のログを確認し，障害を切り分けます。

(A4)

CJMSPブローカーのスレッドダンプを採取します。

Windowsの場合

CJMSPブローカーのスレッドダンプの取得方法は二つあります。

JavaVMのコマンドjheapprofを使用します。

このコマンドの使用方法については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「jheapprof（クラス別統計情報付き拡張スレッドダンプの出力）」を参照してください。

CJMSPブローカーを起動しているコマンドプロンプト上で［Ctrl］+［Break］キーを入力します。

この場合，スレッドダンプを取得したあとにCJMSPブローカーを停止すると，「バッチジョブを終了しますか(Y/N)?」と表示されます。その際，「N」を指定してください。

UNIXの場合

killコマンドを使用します。

実行例

kill -3 <プロセスID>

(A5)

<Application Serverのインストールディレクトリ>/CC/server/public/ejb/<サーバ名>/logs/cjms/<コネクタ名>下のログを確認して，障害を切り分けます。

(A6)

<VAR_HOME>/instances/<インスタンス名>/log下のログを確認して，障害を切り分けます。

(A7)

「付録D.24　CJMSプロバイダサービス無応答時の回復」の手順に従って，CJMSプロバイダのサービスを回復します。

付録D.22　CJMSPリソースアダプタに問題が発生した場合の回復

CJMSPリソースアダプタに問題が発生した場合の回復手順を次の図に示します。

図D‒21　CJMSPリソースアダプタに問題が発生した場合の回復手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動中であること。

アプリケーションが未起動であること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

「付録D.19　CJMSPリソースアダプタに問題が発生した場合の解析」を参照して，障害を解析します。

(A2)

特にありません。

(A3)

特にありません。

(A4)

<サーバ名>

Management Serverで構築したサーバ名

「running <CJMSPリソースアダプタ表示名>」と表示されていることを確認します。

付録D.23　CJMSPブローカーが障害によって停止したときの回復

CJMSPブローカーが障害によって停止したときの回復手順を次の図に示します。

図D‒22　CJMSPブローカーが障害によって停止したときの回復手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが未起動であること。

アプリケーションが起動済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

「付録D.20　CJMSPブローカーが障害によって停止したときの解析」を参照して，障害を解析します。

(A2)

特にありません。

(A3)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A4)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定し存在しない任意の名称を付与してください。

(A5)

Stateが「OPERATING」であることを確認します。

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A6)

<サーバ名>

Management Serverで構築したサーバ名

<CJMSPリソースアダプタ表示名>

CJMSPリソースアダプタの表示名

CJMSプロバイダの場合は，デフォルトで「Cosminexus_JMS_Provider_RA」が設定されています。

(A7)

<サーバ名>

Management Serverで構築したサーバ名

「running <CJMSPリソースアダプタ表示名>」と表示されていることを確認します。

(A8)

特にありません。

付録D.24　CJMSプロバイダサービス無応答時の回復

CJMSプロバイダのサービス無応答状態からの回復手順について説明します。

CJMSプロバイダサービス無応答時の回復手順を次の図に示します。

図D‒23　CJMSプロバイダサービス無応答時の回復手順

(1)　プロセス前提条件

J2EEサーバプロセスが起動済みであること。

CJMSPリソースアダプタが開始済みであること。

CJMSPブローカープロセスが起動済みであること。

アプリケーションが開始済みであること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

「付録D.21　CJMSプロバイダサービス無応答時の解析」を参照して，障害を解析します。

(A2)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

(A3)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定して存在しない任意の名称を付与してください。

(A4)

特にありません。

(A5)

<ホスト名>:<ポート番号>

CJMSPブローカーを起動しているホスト名およびポート番号

CJMSPブローカーの起動時にポート番号を省略した場合にはデフォルトの7676が使用されています。その場合，-bオプションの指定は省略できます。

Stateが「OPERATING」であることを確認します。

(A6)

<サーバ名>

Management Serverで構築したサーバ名

「running <CJMSPリソースアダプタ表示名>」と表示されていることを確認します。

付録D.25　CJMSプロバイダサービスインスタンスの削除

CJMSプロバイダのサービスの稼働中のインスタンスを削除する手順について説明します。

インスタンス名を変更したために以前のインスタンスが不要になった場合などに行います。

注意事項

この操作によって，送信先に存在するすべての情報が削除されます。

この操作を実行する前に，未処理の永続メッセージおよび永続サブスクライバーの情報が存在しないことを確認してください。

CJMSプロバイダのサービスインスタンス削除手順を次の図に示します。

図D‒24　CJMSプロバイダのサービスインスタンス削除手順

(1)　プロセス前提条件

J2EEサーバプロセスが未起動であること。

CJMSPリソースアダプタが未起動であること。

CJMSPブローカープロセスが未起動であること。

アプリケーションが未起動であること。

(2)　実行に必要な情報および補足説明

(A1)などの記述は，図中の記述と対応しています。

(A1)

<インスタンス名>

省略した場合は，デフォルトで「cjmsbroker」を使用します。

複数インスタンスを使用したい場合には名称が重ならないように注意する必要があります。

重なる場合には-nameオプションを指定し存在しない任意の名称を付与してください。

<ディレクトリパス>

削除したいインスタンスが存在するVAR_HOMEのパス

CJMSPブローカーインスタンス名に該当するディレクトリ（デフォルト名はcjmsbroker）を削除します。

この処理を行うと，propとlogディレクトリ以外，すべてのインスタンスに関連するファイルとディレクトリを削除します。

インスタンスのディレクトリ自体が不要な場合，エクスプローラなどで次のディレクトリへ移動して，手動で削除してください。

<VAR_HOME>/instances

次回CJMSPブローカー起動時に削除したインスタンス名を使用して再度CJMSPブローカーを起動した場合には，インスタンスが再作成されます。

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

ここでは，11-20よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-20での主な機能変更については，「1.4　アプリケーションサーバ 11-20での主な機能変更」を参照してください。

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

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

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

付録E.1　11-10での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

このマニュアル

付録B.4

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JSP2.3への対応

JSP2.3に対応しました。

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

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

このマニュアル

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

このマニュアル

15章

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

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

表E‒3　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

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

2.22

付録E.2　11-00での主な機能変更

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

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

表E‒4　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒6　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録H

(4)　そのほかの目的

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

表E‒7　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録E.3　09-87での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

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

機能解説 保守／移行編

9章

付録E.4　09-80での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能におけるラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

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

機能解説 保守／移行編

9章

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

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

表E‒10　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録G

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録G

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録G

付録E.5　09-70での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでの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)　運用性の維持・向上

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

表E‒12　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

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

表E‒13　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録E.6　09-60での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

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

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.18

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

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

表E‒15　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.16

(3)　そのほかの目的

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

表E‒16　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

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

14.2

付録E.7　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表E‒17　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

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

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

表E‒18　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

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

1.1.2

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒20　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

システム設計ガイド

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)　運用性の維持・向上

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

表E‒21　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　そのほかの目的

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

表E‒22　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

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

付録E.8　09-00での主な機能変更

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

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

表E‒23　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

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

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

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

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒25　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

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

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

表E‒26　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　そのほかの目的

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

表E‒27　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

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

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

付録E.9　08-70での主な機能変更

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

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

表E‒28　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（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)　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒30　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

機能解説 拡張編

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

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

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

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

機能解説 拡張編

7.11

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

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

表E‒31　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

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

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

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

表E‒32　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

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

2.1

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

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

付録E.10　08-53での主な機能変更

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

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

表E‒33　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

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

2章，3章，5章

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

このマニュアル

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

このマニュアル

8章

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

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

表E‒35　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，9章

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

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

表E‒36　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

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

1.3，2.1

(5)　そのほかの目的

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

表E‒37　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

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章

（凡例）−：該当なし。

付録E.11　08-50での主な機能変更

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

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

表E‒38　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒40　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

機能解説 拡張編

7章

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

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

機能解説 拡張編

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバ監視し，障害の発生を検知できるようになりました。

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

−

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

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

表E‒41　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，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)　そのほかの目的

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

表E‒42　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。

機能解説 保守／移行編

9.8

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。

9.9

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

クラス別統計情報をCSV形式で出力できるようになりました。

9.10

論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え

Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。

機能解説 運用／監視／連携編

18.4.3，18.5.3，16.2.2，16.3.3，16.3.4

ホスト単位管理モデルを対象とした系切り替えシステム

クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。

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を使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

機能解説 拡張編

−

付録E.12　08-00での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表E‒43　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

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

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

このマニュアル

16.3

(2)　標準機能への対応

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

表E‒44　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表E‒45　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

機能解説 拡張編

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，FullGC発生を抑止できるようになりました。

機能解説 拡張編

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

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

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

表E‒46　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

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

1.1.3

(5)　そのほかの目的

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

表E‒47　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効な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で削除された機能です。

付録F　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

@Resourceアノテーションで指定できるリソースのタイプ[1]

@ResourceアノテーションのmappedName属性で指定する方法[1]

@Resourceアノテーションのname属性で指定する方法[1]

@Resourceアノテーションを使用したリソースの参照解決[1]

<persistence-unit>タグに指定する属性[1]

-dオプションの使い方[1]

数字

09-80での主な機能変更[1]

09-87での主な機能変更[1]

11-10での主な機能変更[1]

A

ActivationSpecの設定[1]

adminサービス[1]

afterDeliveryメソッド[1]

Amazon RDS for Oracleに接続する場合の条件と設定[1]

APIで作成される一時的な送信先[1]

application.xmlがある場合のモジュールの決定規則[1]

application.xmlがない場合のモジュールの決定規則[1]

application.xmlの有無による機能の違い[1]

application.xmlを省略した場合にapplication.xmlが作成される操作[1]

application.xmlを省略した場合にJ2EEアプリケーションにリソースを追加するときの注意[1]

B

Bean Validation実装時の注意事項[1]

Bean Validationの概要[1]

Bean Validationの機能およびBean Validationの動作[1]

Bean Validationの適用可能な範囲[1]

Bean Validationの利用手順[1]

beforeDeliveryメソッド[1]

C

CallableStatementのプールサイズ[1]

CDI Managed BeanでのJPA利用[1]

CDIからBean Validationの利用手順[1]

CJMSPブローカー[1]

CJMSPリソースアダプタ[1]

CJMSプロバイダ[1]

CJMSプロバイダの機能[1]

cjreloadappコマンド[1]

Concurrency Utilities[1]

Concurrency Utilities for Java EEの概要[1]

Connector 1.0仕様とConnector 1.5仕様のリソースアダプタのスキーマの違い[1]

Connector 1.0仕様に準拠したリソースアダプタ[1]

Connector 1.5仕様に準拠したリソースアダプタ[1]

Connector 1.5仕様に準拠したリソースアダプタを使用する場合の設定[1]

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

CORBAオブジェクト呼び出し処理の実装時の注意事項[1]

CORBAオブジェクト呼び出し処理のパッケージ化の注意事項[1]

CORBAネーミングサービス[1]

CORBAネーミングサービスの切り替え[1]

cosminexus.xmlとは[1]

cosminexus.xmlの作成[1]

cosminexus.xmlの作成例[1]

cosminexus.xmlまたはそれ以外の属性ファイルで指定する方法[1]

cosminexus.xmlを含まないアプリケーションから移行する手順[1]

cosminexus.xmlを含むアプリケーション[1]

cosminexus.xmlを含むアプリケーションの運用[1]

cosminexus.xmlを含むアプリケーションの作成[1]

cosminexus.xmlを含むアプリケーションを使用する利点[1]

createEndpointメソッド[1]

D

DataSourceオブジェクトのキャッシング[1]、[2]

DB Connector（RARファイル）の種類[1]

DB Connector for Reliable Messaging[1]

DB Connector for Reliable Messaging（RARファイル）の種類[1]

DB Connector for Reliable MessagingとReliable Messagingによる接続[1]

DB Connector for Reliable MessagingとReliable Messagingによる接続の特徴[1]

DB Connector for Reliable MessagingとReliable Messagingによるデータベース接続の構成[1]

DB Connector for Reliable MessagingとReliable Messagingを使用する場合[1]

DB ConnectorがサポートするJDBC仕様[1]

DB Connectorによる接続[1]

DB ConnectorのselectMethodプロパティ設定時の注意[1]

DB Connectorのコンテナ管理でのサインオンの最適化[1]、[2]

DDでの定義（モジュール単位の設定）[1]

DDによる@PersistenceUnit定義のオーバーライド[1]

DDによるアノテーションの上書き[1]

DDの省略[1]

DDの定義内容（JavaBeansリソース）[1]

DDを省略した場合に設定される表示名[1]

DI[1]

DI失敗時の動作[1]

DIの使用[1]

DIを使用してリソースへの参照を取得する方法[1]

E

EARファイル／ZIPファイルの展開[1]

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

ejbserver.client.transaction.clientName[1]

ejbserver.client.transaction.enabled[1]

ejbserver.connectionpool.applicationAuthentication.disabled[1]

ejbserver.connectionpool.association.enabled[1]

ejbserver.connectionpool.association.enabledDespiteUnshareableSetting[1]

ejbserver.connectionpool.sharingOutsideTransactionScope.enabled[1]

ejbserver.connectionpool.validation.timeout[1]、[2]、[3]

ejbserver.connector.statementpool.clear.backcompat[1]

ejbserver.container.ejbhome.sessionbean.reconnect.enabled[1]

ejbserver.cui.optionalname.enabled[1]、[2]

ejbserver.deploy.context.check_interval[1]

ejbserver.deploy.context.reload_scope[1]

ejbserver.deploy.context.update.interval[1]

ejbserver.deploy.session.work.directory[1]

ejbserver.distributedtx.ots.status.directory1[1]、[2]

ejbserver.distributedtx.ots.status.directory2[1]、[2]

ejbserver.distributedtx.recovery.completionCheckOnStopping.timeout[1]

ejbserver.distributedtx.recovery.port[1]、[2]、[3]

ejbserver.distributedtx.rollbackClientTxOnSystemException[1]

ejbserver.distributedtx.XATransaction.enabled[1]

ejbserver.jca.adapter.tp1.bind_host[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]、[2]

ejbserver.naming.host[1]、[2]

ejbserver.naming.port[1]、[2]

ejbserver.naming.protocol[1]

ejbserver.naming.startupMode[1]

ejbserver.webj2ee.connectionAutoClose.enabled[1]

EJBアプリケーションの場合[1]

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

EJBコンテナによるコネクション自動クローズ[1]

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

EJBホームオブジェクトリファレンスの別名付与[1]

EJBホームオブジェクトリファレンスを再利用する場合の注意事項[1]

Enterprise Beanで指定できるアノテーション[1]

Enterprise Beanに対する別名[1]

Enterprise Beanの検索[1]

Enterprise Beanの別名の設定[1]

Enterprise Beanを参照する仕組みと使い方（ejb-ref）[1]

EntityManagerで提供するメソッド[1]

EntityManagerと永続化コンテキスト[1]

EntityManagerとは[1]

EntityManagerの種類[1]

EntityManagerのライフサイクルの管理[1]

G

getInputStreamメソッド[1]

getParameterメソッド[1]

getQueryStringメソッド[1]

getReaderメソッド[1]

H

HiRDB Cloud Serviceに接続する場合の条件と設定[1]

HiRDBと接続するときの注意事項[1]

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

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

HITACHI_EJBから始まる名称でのルックアップ[1]

I

Inbound[1]

Inboundで使用できる機能[1]

Interceptors[1]

isDeliveryTransactedメソッド[1]

J

J2EEアプリケーション実行時間の監視の設定[1]

J2EEアプリケーションに含めて使用する[1]

J2EEアプリケーションの入れ替え[1]

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

J2EEアプリケーションの形式とデプロイの機能[1]

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

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

J2EEアプリケーションの更新検知とリロードの設定[1]

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

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

J2EEアプリケーションのデプロイとアンデプロイ[1]

J2EEアプリケーションのリデプロイ[1]

J2EEアプリケーションのリロード方法[1]

J2EEアプリケーションへのプロパティの設定[1]

J2EEサーバの設定[1]

J2EEリソースアダプタ[1]、[2]

J2EEリソースアダプタとしてデプロイして使用する[1]

J2EEリソースに対する別名[1]

J2EEリソースの検索[1]

J2EEリソースの別名が登録または削除されるタイミング[1]

J2EEリソースの別名の設定[1]

J2EEリソースの別名付与[1]

java:comp/envを使用した名称でのルックアップ[1]

java.naming.factory.initial[1]

JavaBeansリソース属性ファイルの設定[1]

JavaBeansリソースの入れ替え[1]

JavaBeansリソースの入れ替えの流れ[1]

JavaBeansリソースの開始処理の流れ[1]

JavaBeansリソースの機能[1]

JavaBeansリソースの実装[1]

JavaBeansリソースの実装クラスの作成[1]

JavaBeansリソースの新規設定の流れ[1]

JavaBeansリソースの設定[1]

JavaBeansリソースの設定変更の流れ[1]

JavaBeansリソースのプロパティ定義で設定できること[1]

JavaBeansリソースの利用[1]

JavaMailの機能[1]

JavaScriptを使用してクエリ文字列を作成する場合の注意事項[1]

javax.jms.MessageListenerインタフェースを使用したMessage-driven Beanおよびリソースアダプタの場合[1]

javax.persistence.EntityManagerFactoryインタフェース[1]

javax.persistence.EntityManagerインタフェース[1]

javax.resource.spi.endpoint.MessageEndpointFactoryインタフェース[1]

javax.resource.spi.endpoint.MessageEndpointインタフェース[1]

JMSアプリケーション[1]

JMSインタフェースだけを使用する場合[1]

JMSインタフェースとJDBCインタフェースで異なるデータベースにアクセスする場合[1]

JMSインタフェースとJDBCインタフェースで同一データベースにアクセスする場合[1]

jmsサービス[1]

JNDI[1]、[2]

JNDI名前空間の確認方法[1]

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

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

JPAの特長[1]

JPAプロバイダとEJBコンテナ間の規約[1]

JPAプロバイダとは[1]

JPAを使用したアプリケーションの利点[1]

JPAを使用した場合のデータアクセスモデル[1]

JPAを使用しない場合のデータアクセスモデル[1]

JSFからBean Validationの利用手順[1]

JSP事前コンパイルの設定[1]

JSPのファイルインクルード時の注意事項[1]

JSPのリロード[1]

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

L

lookupの実装（JavaBeansリソース）[1]

M

ManagedExecutorServiceの設定[1]

ManagedExecutorServiceの動作[1]

ManagedScheduledExecutorServiceの設定[1]

ManagedScheduledExecutorServiceの動作[1]

ManagedThreadFactoryの設定[1]

ManagedThreadFactoryの動作[1]

Message-driven Bean（サービス）[1]

Message-driven Bean（サービス）実行制御スレッド[1]

Message-driven Bean（サービス）呼び出しスレッド[1]

Message-driven Beanが使用するインタフェースの設定[1]

Message-driven Beanとリソースアダプタの対応づけの設定[1]

O

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

OpenTP1とOutboundで接続するための設定[1]

OpenTP1とのInboundでの接続[1]

OpenTP1のSPP[1]

Oracle RACを使用する場合[1]

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

Oracleと接続する場合の注意事項[1]

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

Outbound[1]

Outboundで使用できる機能[1]

P

Portable Global JNDI名[1]

Portable Global JNDI名でのルックアップ[1]

PreparedStatementのプールサイズ[1]

PTPメッセージングモデル[1]

Pub/Subメッセージングモデル[1]

R

releaseメソッド[1]

Reliable Messaging[1]

RPC通信機能[1]、[2]

S

SecurityManagerを解除する場合[1]

setCharacterEncodingメソッド[1]

SMTPサーバとの接続[1]

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

SQL Serverと接続する場合の注意事項[1]

SQL Serverの場合の前提条件[1]

Synchronizationを使用する場合の注意事項[1]

T

TP1/Message Queue[1]

TP1/Message Queue - Accessによる接続[1]

TP1 Connectorによる接続[1]

TP1インバウンドアダプタ[1]

TP1インバウンド連携機能[1]

U

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

USRCONF_JVM_CLASSPATH[1]

USRCONF_JVM_CLPATH[1]

USRCONF_JVM_LIBPATH[1]、[2]

V

validation.xmlの内容が不正な場合の情報の出力[1]

vbroker.agent.port[1]

W

web.xmlを省略したWebアプリケーションに対する操作[1]

webserver.context.check_interval[1]

webserver.context.reload_delay_timeout[1]

webserver.context.update.interval[1]

webserver.jsp.check_interval[1]

webserver.jsp.update.interval[1]

Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御を使用する場合[1]

Webアプリケーションで指定できるアノテーション[1]

Webアプリケーションの場合[1]

Webアプリケーションのリロード[1]

Webアプリケーションのリロード時のセッション情報の引き継ぎ[1]

Webアプリケーションのリロード遅延実行[1]

Webコンテナ単位の同時実行スレッド数制御を設定する場合[1]

Webコンテナによるコネクション自動クローズ[1]

X

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

あ

アーカイブ形式のJ2EEアプリケーション[1]、[2]

アーカイブ形式のJ2EEアプリケーションのデプロイとアンデプロイ[1]

アノテーション[1]

アノテーション参照抑止機能の設定変更[1]

アノテーション参照抑止機能の目的と適用範囲[1]

アノテーション使用時の注意事項[1]

アノテーションで定義した内容の更新[1]

アノテーションの機能[1]

アノテーションの更新[1]

アノテーションの参照抑止[1]

アノテーションの参照抑止機能[1]

アノテーションの指定[1]

アノテーションの使用[1]

アノテーションを参照するタイミング[1]

アノテーションを指定する場合のEnterprise Beanの実装[1]

アノテーションを使用するメリットと指定できるアノテーション[1]

アノテーションを宣言したライブラリJARのクラスの使用[1]

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

アプリケーションからEntityManagerFactoryをルックアップする方法[1]

アプリケーションからEntityManagerをルックアップする方法[1]

アプリケーション管理のEntityManagerを取得する方法[1]

アプリケーション管理のEntityManagerを使用する場合の永続化コンテキスト[1]

アプリケーションサーバ 11-20での主な機能変更[1]

アプリケーションサーバが管理するトランザクション[1]

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

アプリケーションサーバでJPAを使用するときの注意事項[1]

アプリケーションサーバで実行できるアプリケーションの構成[1]

アプリケーションサーバで使用するBean Validationの機能[1]

アプリケーションサーバで使用するCDIの機能[1]

アプリケーションサーバで使用するJPAの機能[1]

アプリケーションサーバで使用できるJPAの機能[1]

アプリケーションサーバ独自のConnector 1.5 API仕様[1]

アプリケーションで扱う文字コード[1]

アプリケーションディレクトリ[1]

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

アプリケーションディレクトリの作成例[1]

アプリケーションディレクトリの変更[1]

アプリケーションにEntityManagerFactoryをインジェクトする方法[1]

アプリケーションにEntityManagerをインジェクトする方法[1]

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

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

アプリケーションの属性管理[1]、[2]

アプリケーションのデプロイ時にチェックされる項目[1]

い

一時クローズ処理によるコネクション数の調整[1]

インプロセストランザクションサービス[1]

インポート済みのJ2EEアプリケーションにリソースアダプタを追加する方法[1]

え

永続化コンテキストの種類[1]

永続化サブスクライバー[1]

永続化ユニットとは[1]

永続化ユニット名の参照スコープ[1]

エラー発生時の動作[1]

エンティティクラスとは[1]

お

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

か

開始状態のJ2EEアプリケーションを入れ替えた場合[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]、[2]

コネクションアソシエーションの条件[1]

コネクションアソシエーションの定義[1]

コネクション管理機能[1]、[2]

コネクション管理スレッド[1]、[2]

コネクション枯渇時のコネクション取得待ち[1]、[2]

コネクションシェアリング[1]

コネクションシェアリング・アソシエーション[1]

コネクションシェアリングの条件[1]

コネクションシェアリングの定義[1]

コネクション自動クローズが実行されたことを確認する方法[1]

コネクション障害検知のタイムアウトを有効にした場合の注意事項[1]

コネクションスイーパ[1]、[2]

コネクションスイーパの動作[1]

コネクション数調節機能[1]、[2]

コネクション定義識別子[1]

コネクション定義に指定できる要素と指定個所[1]

コネクション定義の複数指定[1]

コネクションの最小値と最大値[1]

コネクションの自動クローズ[1]、[2]

コネクションの取得リトライ[1]、[2]

コネクションの障害検知[1]、[2]

コネクションプーリング[1]

コネクションプーリングで使用できる機能[1]

コネクションプーリングの動作[1]

コネクションプールのウォーミングアップ[1]、[2]

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

コネクションプールの終了処理[1]

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

コネクションプールの生成および初期化[1]

コネクションプール利用上の注意事項[1]

コネクションプールを使用する場合の留意事項[1]

コマンドで作成する送信先[1]

コマンドによるJ2EEアプリケーションのリロード[1]

コマンドによるリロード[1]

コンシューマー[1]

コンテナ拡張ライブラリ[1]、[2]

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

コンテナ拡張ライブラリの機能[1]、[2]

コンテナ拡張ライブラリの機能を使用するための設定[1]

コンテナ拡張ライブラリの作成と利用の流れ[1]

コンテナ拡張ライブラリの利用[1]

コンテナ拡張ライブラリ利用の検討[1]

コンテナ管理サインオン[1]

コンテナ管理でのサインオン[1]

コンテナ管理のEntityManager[1]

コンテナ管理のEntityManagerを取得する方法[1]

コンテナ管理のEntityManagerを使用する場合の永続化コンテキスト[1]

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

コンポーネント管理サインオン[1]

コンポーネント管理でのサインオン[1]

さ

サーバ管理コマンドを使用した定義の参照と更新[1]

サーバ起動・停止フック機能[1]、[2]

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

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

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

サブスクライバー[1]

サポートするアプリケーションの形式[1]

サポートするクラスローダ構成[1]

参照解決方法の優先順位[1]

し

システム運用時の注意事項[1]

システム構築時の注意事項[1]

システムでの文字コード変換時の注意[1]

システムの目的と機能の対応[1]

システム例外発生時のクライアントトランザクションの動作[1]

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

実行環境での設定[1]

実行時間監視機能の設定[1]

実行できるJ2EEアプリケーションの形式[1]

受信タイマ監視スレッド[1]

障害検知のタイムアウト[1]、[2]、[3]、[4]

障害検知を実施するタイミング[1]

障害調査用SQL[1]

障害調査用SQLの出力[1]

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

使用できるJPAプロバイダ[1]

使用できる機能[1]

使用できるコンポーネント[1]

使用できるリソースアダプタ[1]

使用方法ごとに使用できるリソースアダプタ[1]

す

スケジュール機能[1]、[2]

スケジュールキュー[1]

ステータスファイルの格納ディレクトリ[1]

ステートメントキャンセル[1]、[2]、[3]

ステートメントプーリング[1]

ステートメントプーリング機能のステートメントの初期化[1]

ステートメントプーリング機能を使用する場合の注意事項[1]

ステートメントプーリングの動作[1]

スマートエージェントが使用する通信ポート[1]、[2]

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

スレッドプーリング[1]

スレッドプール[1]

せ

セキュリティポリシーの設定を変更する場合[1]

セッション情報ファイル[1]、[2]

セッション情報ファイル出力先の変更[1]

セッション情報を引き継ぐ場合の注意事項[1]

接続できるデータベース[1]、[2]

接続テスト機能[1]

接続にリソースアダプタを使用しないリソース[1]

接続にリソースアダプタを使用するリソース[1]

センダー[1]

そ

送信先[1]

属性の管理[1]

属性ファイルの指定例[1]

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

そのほかのリソースとの接続[1]

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

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

つ

通信に使用するIPアドレス[1]

て

停止状態のJ2EEアプリケーションを入れ替えた場合[1]

停止中のトランザクションの確認[1]

データベースコネクション確立までの待ち時間[1]

データベース上のキューとの接続[1]

データベースへの接続[1]

デッドメッセージ[1]

デッドメッセージキュー[1]

デバッグ用ログ（開発調査ログ）の利用[1]

デフォルトのクラスローダ構成[1]

デプロイメントに関する規約[1]

展開ディレクトリ形式のJ2EEアプリケーション[1]、[2]

展開ディレクトリ形式のJ2EEアプリケーションのデプロイとアンデプロイ[1]

展開ディレクトリ形式のJ2EEアプリケーションを使用するための設定（セキュリティの設定変更）[1]

展開ディレクトリ形式の概要[1]

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

電文組み立てリスト[1]

と

トピック[1]

トランザクショナルRPC[1]

トランザクションインフロー[1]

トランザクション管理[1]

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

トランザクションサポートレベル[1]、[2]

トランザクション情報の確認[1]

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

トランザクションタイムアウト（J2EEサーバ単位）[1]

トランザクションタイムアウトの設定[1]

トランザクションの種類[1]、[2]

トランザクションの制御とEntityManager[1]

トランザクションのリカバリ[1]、[2]

トランザクションマネージャの取得[1]

トランザクションマネージャを使用する場合の注意事項[1]

トランザクションリカバリ[1]

トランザクションリカバリ用通信ポート[1]

トランザクションリカバリをする場合の留意事項[1]

トランザクション連携機能[1]

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

に

任意のメッセージリスナインタフェースを使用したMessage-driven Beanおよびリソースアダプタの場合[1]

ね

ネーミング管理[1]、[2]

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

ネーミング管理の概要[1]

ネーミング管理の機能[1]、[2]

ネーミングサービス[1]、[2]

ネーミングサービスの障害検知[1]

ネーミングサービスの障害検知機能とは[1]

ネーミングサービスの障害検知機能の挙動[1]

ネーミングサービスの障害検知機能の注意事項[1]

ネーミングサービスの通信タイムアウト[1]

ネーミングでのキャッシングの注意事項[1]

は

パフォーマンスチューニングのための機能[1]

パブリッシャー[1]

ふ

ファイアウォール環境での運用のための機能[1]

ファイアウォール環境での運用のための設定[1]

フォールトトレランスのための機能[1]

複数のJ2EEサーバでのアプリケーションディレクトリの共有[1]

物理コネクション[1]

ブラウザとアプリケーション間の文字コード変換[1]

ブラウザとアプリケーション間の文字コード変換で使用するメソッド[1]

フリーファイル[1]

プロデューサー[1]

へ

別名が登録または削除されるタイミング[1]

別名の重複[1]

別名の付与規則[1]

別名を付けられる対象[1]

ま

マネージドデータベースサービスがフェイルオーバーした場合のDB Connectorの動作[1]

み

未決着トランザクションの確認時間のタイムアウト[1]

め

メッセージインフロー[1]

メッセージインフローの制御の流れ（Non-Transacted Deliveryの場合）[1]

メッセージインフローの制御の流れ（Transacted Deliveryの場合）[1]

メッセージエンドポイントのアンデプロイ[1]

メッセージエンドポイントのデプロイ[1]

メッセージセレクター[1]

メッセージ配送をするときのリソースアダプタの処理[1]

メッセージリスナのメソッド[1]

も

文字コード[1]

ゆ

ユーザが直接管理するトランザクション（アプリケーションサーバが管理しないトランザクション）[1]

ユーザサービスネットワーク定義によるスケジューラダイレクト機能[1]

ユーザ指定名前空間機能[1]、[2]、[3]、[4]

ユーザ指定名前空間機能を使用する場合の注意事項[1]

ユーザ指定名前空間機能を利用して付与した別名でのルックアップ[1]

よ

用語解説[1]

ら

ライトトランザクション[1]

ライトトランザクション機能[1]

ライフサイクル管理機能を使用するときの注意[1]

ライフサイクル管理に使用するクラス[1]

ライブラリ競合回避機能[1]

ラウンドロビン検索[1]

ラウンドロビン検索機能との併用[1]

ラウンドロビン検索機能を使用する場合の推奨する設定[1]

ラウンドロビン検索の動作[1]

ラウンドロビン検索の範囲[1]

ラウンドロビン検索をするために必要な設定[1]

ラウンドロビン検索をする場合の注意事項[1]

ラウンドロビンポリシーによるCORBAネーミングサービスの検索[1]

ランタイムに関する規約[1]

り

リクエスト受け付けスレッド[1]

リソースアダプタ以外の機能[1]

リソースアダプタ以外を使用する接続の設定[1]

リソースアダプタごとのRARファイルの種類[1]

リソースアダプタについての注意事項[1]

リソースアダプタの入れ替えの流れ[1]

リソースアダプタの機能[1]

リソースアダプタの種類[1]

リソースアダプタの使用方法[1]

リソースアダプタの新規設定の流れ[1]

リソースアダプタの設定の流れ（Inboundで使用する場合）[1]

リソースアダプタの設定の流れ（J2EEアプリケーションに含めて使用する場合）[1]

リソースアダプタの設定の流れ（J2EEリソースアダプタとしてデプロイして使用する場合）[1]

リソースアダプタの設定変更の流れ[1]

リソースアダプタの設定方法[1]

リソースアダプタのライフサイクル管理[1]、[2]

リソースアダプタの利用方法とトランザクションレベルの対応[1]

リソースアダプタのワーク管理[1]、[2]

リソースアダプタをJ2EEアプリケーションに含めて使用する場合[1]

リソースアダプタをJ2EEサーバに直接デプロイして使用する場合[1]

リソースアダプタを含めたJ2EEアプリケーションをJ2EEサーバにインポートする方法[1]

リソース固有のトランザクション管理インタフェースを使用する場合の処理概要と留意点[1]

リソース接続[1]

リソース接続でのトランザクション管理の方法[1]

リソース接続とトランザクション管理[1]

リソース接続とトランザクション管理の概要[1]

リソース接続とトランザクション管理の機能[1]

リソースに接続するための実装[1]

リソースへのサインオン方式[1]

リソースへの接続テスト[1]

リソースへの接続テストをする場合の留意事項[1]

リソースへの接続方法[1]

リソースを参照する仕組みと使い方（resource-ref）[1]

リデプロイ[1]

リデプロイによるJ2EEアプリケーションの入れ替え[1]

リデプロイによるJ2EEアプリケーションの入れ替えの注意事項[1]

リモートインタフェース[1]

リロード[1]

リロード機能の適用範囲の設定[1]

リロード時のクラスローダの構成[1]

リロード遅延実行の設定[1]

リロードとJ2EEアプリケーション実行時間の監視との関係[1]

リロードと同時実行スレッド数制御との関係[1]

リロードの対象となる操作[1]

リロードの注意事項および制限事項[1]

リロードの適用範囲[1]

る

ルックアップで使用する名称の種類[1]

ルックアップの対象にする管理対象オブジェクトの設定[1]

れ

例外が発生したコネクションの破棄[1]

レシーバー[1]

ろ

ローカルインタフェース[1]

ローカルトランザクション[1]

ローカル呼び出し最適化時のクラスローダ構成[1]

ロード対象のクラスとロード時に必要なクラスパス[1]

論理コネクション[1]

論理ネーミングサービス[1]

わ

ワーク管理機能を使用するときの注意[1]

ワーク管理の開始処理と終了処理[1]