Cosminexus V11 アプリケーションサーバ 機能解説 基本・開発編（EJBコンテナ）

解説書

3021-3-J06-60

前書き

対象製品

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

輸出時の注意

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

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

商標類

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

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

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

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

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

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

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

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

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

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

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

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

発行

2024年 9月 3021-3-J06-60

著作権

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

変更内容

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

追加・変更内容

変更個所

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

1.4

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

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & 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コンテナ)※2

EJBクライアント

Enterprise Bean実装時の注意事項

ネーミング管理

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

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

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

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

この節では，Enterprise Beanを実行するためのそれぞれの機能をどのようなシステムの場合に使用するとよいかを示します。機能ごとに，次の項目への対応を示しています。

信頼性

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

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

性能

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

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

運用・保守

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

拡張性

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

そのほか

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

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

1.2.1　EJBコンテナの機能

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

表1‒2　EJBコンテナの機能とシステムの目的の対応

機能

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

Enterprise Beanの実行

−

−

−

−

−

○

○

2.2

EJB仕様準拠のチェック

−

−

−

−

−

○

○

2.3

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

−

−

−

−

−

○

○

2.4

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

−

−

−

○

−

○

○

2.5

外部リソースとの接続

−

−

−

○

−

○

−

2.6

Enterprise Beanでのトランザクション管理

−

−

−

−

−

○

○

2.7

Entity Beanのキャッシュモデル（コミットオプション指定）

−

○

−

−

−

○

−

2.8

Stateless Session Bean，Entity Beanのプールの管理

−

○

−

−

−

○

○

2.9

Enterprise Beanへのアクセス制御

○

−

−

−

−

○

−

2.10

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

−

○

−

−

−

○

○

2.11

Timer Serviceの機能

−

−

−

−

−

○

○

2.12

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

−

○

−

−

−

○

○

2.13

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

○

−

−

−

−

−

○

2.14

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

−

−

−

−

−

○

○

2.15

ローカルビジネスインタフェースの省略（No-Interface viewの利用）

−

−

−

−

−

○

−

2.16

Session Beanの非同期呼び出し

−

−

−

−

−

○

−

2.17

Session Synchronizationのアノテーションでの指定

−

−

−

−

−

○

−

2.18

Singleton Session Beanの利用

−

−

−

−

−

○

−

2.19

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

注

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

注※

ネーミング管理を利用して実現します。

1.2.2　EJBクライアントの機能

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

表1‒3　EJBクライアントの機能とシステムの目的の対応

機能

システムの目的

Java EE標準への準拠

参照先

信頼性

性能

運用・

保守

拡張性

そのほか

標準

拡張

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

−

−

−

○

−

○

○

3.3

Enterprise Beanの呼び出し

−

−

−

○

−

○

○

3.4

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

−

−

−

○

−

○

○

3.5

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

−

−

−

○

−

○

○

3.6

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

−

−

−

○

−

○

○

3.7

EJBクライアントアプリケーションのシステムログ出力

−

−

−

○

−

○

○

3.8

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

注

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

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

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

1.3.1　分類の意味

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

解説

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

実装

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

設定

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

運用

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

注意事項

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

1.3.2　分類を示す表の例

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

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

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

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

分類

タイトル

参照先

解説

○○機能とは

X.1

実装

アプリケーションの実装

X.2

DDおよびcosminexus.xml※での定義

X.3

設定

実行環境での設定

X.4

運用

○○機能を使用した運用

X.5

注意事項

○○機能使用時の注意事項

X.6

注※

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

ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

接続できるデータベースにAmazon RDS for SQL Serverを追加

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

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

3.6

マニュアルに「アプリケーションサーバでのSpringの利用」の章を追加

マニュアルに，アプリケーションサーバでのSpring Framework 6の利用方法について記載を追加しました。

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

21章

2　EJBコンテナ

この章では，Enterprise Beanの実行基盤である，EJBコンテナで利用できる機能について説明します。EJBコンテナの機能は，Enterprise Beanを使用したJ2EEアプリケーションを実行する場合に使用します。

なお，EJBコンテナの機能のうち，JNDI名前空間機能，Enterprise Beanでのトランザクション設定やアクセス制御では，J2EEサービスの機能も利用します。マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」もあわせて参照してください。

2.1　この章の構成

EJBコンテナは，Enterprise Beanの実行を制御し，Enterprise Beanに各種のサービスを提供する実行環境です。

EJBコンテナの機能と参照先を次の表に示します。

表2‒1　EJBコンテナの機能と参照先

機能

参照先

Enterprise Beanの実行

2.2

EJB仕様準拠のチェック

2.3

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

2.4

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

2.5

外部リソースとの接続

2.6

Enterprise Beanでのトランザクション管理※2

2.7

Entity Beanのキャッシュモデル

2.8

Enterprise Beanのプールの管理

2.9

Enterprise Beanへのアクセス制御

2.10

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

2.11

Timer Serviceの機能

2.12

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

2.13

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

2.14

インターセプタの使用

2.15

ローカルビジネスインタフェースの省略（No-Interface viewの利用）

2.16

Session Beanの非同期呼び出し

2.17

Session Synchronizationのアノテーションでの指定

2.18

Singleton Session Beanの利用

2.19

注※1

J2EEサービスのネーミング管理機能の利用によって実現します。管理機能の概要については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.　ネーミング管理」を参照してください。

注※2

J2EEサービスのトランザクション管理機能の利用によって実現します。J2EEサービスのトランザクション管理の概要については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

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

また，EJBクライアントで使用できる機能については，「3.　EJBクライアント」を参照してください。

2.2　Enterprise Beanの実行

この節では，Enterprise Beanを実行する機能について説明します。

Enterprise Beanは，ビジネスロジックをEJBアーキテクチャに従って作成したプログラムです。業務処理プログラムに該当します。Enterprise Beanは，EJBコンテナ上で動作します。

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

表2‒2　この節の構成（Enterprise Beanの実行）

分類

タイトル

参照先

解説

Enterprise Beanの種類

2.2.1

Enterprise Beanのインタフェース

2.2.2

Enterprise Beanのライフサイクル

2.2.3

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

2.2.1　Enterprise Beanの種類

アプリケーションサーバで提供しているEJBコンテナでは，次の表に示すEnterprise Beanを実行できます。

表2‒3　EJBコンテナで実行できるEnterprise Beanの分類

大分類

小分類

Session Bean

Stateless Session Bean

Stateful Session Bean

Singleton Session Bean

Entity Bean

BMP（Bean Managed Persistence）

CMP（Container Managed Persistence）

Message-driven Bean

なし

ここでは，それぞれのEnterprise Beanの特徴について説明します。

(1)　Session Bean

Session Beanは，クライアントからのセッション単位に生成され，クライアントが終了すると消滅するEnterprise Beanです。Session Beanのライフサイクルが，ユーザがシステムの利用を開始してから終了するまでの範囲内を超えることはありません。Session BeanはStateless Session Bean，Stateful Session Bean，Singleton Session Beanに分類されます。

(a)　Stateless Session Bean

セッションの状態を管理しないモデルです。クライアントからの1セッションはBeanのビジネスメソッドの1回の呼び出しで完結させる必要があります。

(b)　Stateful Session Bean

セッションの状態を管理するモデルです。EJBコンテナが状態管理をします。クライアントからの1セッションがEJBの複数のビジネスメソッドを呼び出す場合でも，ビジネスメソッドの呼び出し間で状態が保存されます。

(c)　Singleton Session Bean

複数のクライアントでセッションの状態を共有するモデルです。アプリケーションに対して，すべてのセッションで共有されるインスタンスが一つ作成されます。アプリケーションに合わせてBeanのライフサイクルを決定する必要があります。

アプリケーションサーバで利用できるSingleton Session Beanの詳細は，「2.19　Singleton Session Beanの利用」を参照してください。

(2)　Entity Bean

Entity Beanは，エンティティを表現し，データベースに保存（永続化）されることを前提としています。そのため，クライアントが終了してもEntity Beanの状態はデータベースに存在し続けます。Session Beanと比較してライフサイクルが長いEnterprise Beanです。EJB仕様では，次の二つの管理モデルを規定しています。

(a)　BMP（Bean Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化を管理するモデルです。データベースへの接続，SQLの組み立てや実行などの処理は，Enterprise Beanの開発者が実装しなければなりません。

(b)　CMP（Container Managed Persistence）

EJBコンテナがデータの永続化を管理するモデルです。データベースへの接続とデータの保存はEJBコンテナによって実行されるので，Enterprise Beanのビジネスメソッドで実行する必要はありません。Enterprise Bean内のデータと格納先データベースのテーブルおよびカラムの対応をEJBコンテナが提供する方法で定義します。一方，接続先データベースのホスト名やポート番号などの接続情報をリソースアダプタまたはデータソースに定義します。EJBコンテナは，これらの定義情報を参照してSQL文を組み立て，接続先データベースのテーブルにデータの参照および格納をします。

なお，EJB 2.0で追加されたCMP 2.0では，EJB QLによって，使用するデータベースに依存することなく，データベースの検索処理をSQLのような構文でDDに記述できます。また，Entity Bean同士に関連を持たせるCMR（Container-managed relationship）によって，Entity Bean間の関連をDDで設定し，EJBコンテナで管理できます。

アプリケーションサーバで提供するEJBコンテナのCMP機能でのEntity BeanのJavaデータ型とデータベースのSQLデータ型の対応については，「2.4.2　CMPフィールドとデータベースのマッピング」を参照してください。

(3)　Message-driven Bean

Message-driven Beanは，JMSと連携するメッセージ駆動タイプのBeanです。EJBコンテナはJMSのDestinationからのJMSメッセージ受信を契機にBeanを起動します。Session BeanまたはEntity Beanと異なり，ホームインタフェース，コンポーネントインタフェースを持たないため，クライアントから直接呼び出されません。

Message-driven Beanは，EJB 2.0の場合とEJB 2.1以降の場合で実装するインタフェースが異なります。

EJB 2.0の場合は，次のインタフェースを実装します。

javax.ejb.MessageDrivenBeanインタフェース

javax.jms.MessageListenerインタフェース

EJB 2.1以降の場合は，次のインタフェースを実装します。

javax.ejb.MessageDrivenBeanインタフェース

EISが提供する任意のメッセージリスナのインタフェース

EJB 2.0とEJB 2.1以降では，それぞれ対応するConnectorのバージョンが異なります。EJBとConnectorのバージョンの対応を次の表に示します。

表2‒4　EJBとConnectorのバージョンの対応

EJBのバージョン

Connectorのバージョン

Connector 1.0

Connector 1.5

EJB 2.0

○

×

EJB 2.1以降

○

◎

（凡例）

○：Reliable MessagingまたはTP1/Message Queue - Accessから送信されたメッセージを受信できる。

◎：任意の形式のリスナインタフェースを使用して送信されたメッセージを受信できる。

×：該当するリソースアダプタから送信されたメッセージを受信できない。

また，EJB 2.0とEJB 2.1以降では，次の表に示す機能差があります。

表2‒5　EJB 2.0とEJB 2.1以降の機能差

機能

EJB 2.0

EJB 2.1以降

Connector 1.0の機能を使用する場合

Connector 1.5の機能を使用する場合

接続できるリソースアダプタ

Connector1.0仕様に準拠したリソースアダプタ。

Connector1.0仕様に準拠したリソースアダプタ。

Connector 1.5仕様に準拠し，Inboundが定義されているリソースアダプタ。

使用できるEIS

Reliable Messaging

TP1/Message Queue - Access

Reliable Messaging※2

TP1/Message Queue - Access※2

Connector 1.5をサポートする任意のEIS（JMSを含みます）。※1

キューの定義方法

キュー定義ファイルに定義します。

キュー定義ファイルに定義します。

リソースアダプタのDD（ra.xml）内の管理対象オブジェクトに定義します。

JMSのバージョン

JMS1.0.2b

JMS1.0.2b

JMS1.1

メッセージリスナでのコネクションの管理方法

アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。

アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。

使用するリソースアダプタによって異なります。

注※1

Reliable MessagingまたはTP1/Message Queue - AccessはConnector 1.5仕様に対応していないため，Connector 1.5の機能は使用できません。

注※2

EJB2.1 のDeployment Descriptorでは<message-selector>タグの指定ができません。メッセージセレクタを使用する場合には，CJMSプロバイダからメッセージを受信するようにしてください。

2.2.2　Enterprise Beanのインタフェース

Enterprise Beanの実装で利用できるインタフェースについて説明します。利用できるインタフェースの一覧を次の表に示します。

表2‒6　利用できるインタフェースの一覧

インタフェース名

説明

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

EJB仕様1.1以降で規定されている，javax.ejb.EJBHomeを継承した，リモートクライアント用のインタフェースです。主に，Enterprise Beanインスタンスの取得のために使用します。

リモートコンポーネントインタフェース※2

EJB仕様1.1以降で規定されている，javax.ejb.EJBObjectを継承した，リモートクライアント用のインタフェースです。主に，ビジネスメソッドを定義します。

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

リモートクライアントからEnterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。規定されたインタフェースを継承する必要はありません。

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

EJB仕様2.0以降で規定されている，javax.ejb.EJBLocalHomeを継承した，ローカルクライアント用のインタフェースです。主に，Enterprise Beanインスタンスの取得のために使用します。

ローカルコンポーネントインタフェース

EJB仕様2.0以降で規定されている，javax.ejb.EJBLocalObjectを継承した，ローカルクライアント用のインタフェースです。主に，ビジネスメソッドを定義します。

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

ローカルクライアントからEnterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。規定されたインタフェースを継承する必要はありません。

注※1

EJB仕様1.1ではホームインタフェースと呼ばれるインタフェースです。

注※2

EJB仕様1.1ではリモートインタフェースと呼ばれるインタフェースです。

なお，このマニュアルの説明では，複数のインタフェースをまとめた総称を使用することがあります。説明で使用するインタフェースの総称を次に示します。

表2‒7　インタフェースの総称

インタフェースの総称

説明

ホームインタフェース

次のインタフェースの総称です。

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

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

コンポーネントインタフェース

次のインタフェースの総称です。

リモートコンポーネントインタフェース

ローカルコンポーネントインタフェース

ビジネスインタフェース

次のインタフェースの総称です。

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

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

リモートインタフェース

次のインタフェースの総称です。

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

リモートコンポーネントインタフェース

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

ただし，リモートコンポーネントインタフェース，リモートビジネスインタフェースだけを指すこともあります。

ローカルインタフェース

次のインタフェースの総称です。

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

ローカルコンポーネントインタフェース

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

ただし，ローカルコンポーネントインタフェース，ローカルビジネスインタフェースだけを指すこともあります。

これらのインタフェースは，Session BeanまたはEntity Beanの場合に実装します。Message-driven Beanの場合はこれらのインタフェースを持ちません。

Session Beanの場合，ローカルインタフェースからの呼び出しにNo-Interface viewを使用できます。この場合は，インタフェースの実装を省略できます。No-Interface viewについては，「2.16　ローカルビジネスインタフェースの省略（No-Interface viewの利用）」を参照してください。

(1)　リモートインタフェース

リモートインタフェースではJava RMIのインタフェースの規定に従い，RMI-IIOP通信によってEnterprise Beanの呼び出しをします。クライアントが異なるJavaVMに存在するEnterprise Beanを呼び出すことができますが，実行時に通信上のオーバーヘッドが発生します。メソッド実行時の引数および戻り値は値渡し（pass by value）になります。

(2)　ローカルインタフェース

ローカルインタフェースの場合，Enterprise Beanの呼び出しはJavaのメソッド呼び出しで実行され，通信が発生しません。クライアントは同一J2EEアプリケーションに存在する場合にだけ，このインタフェースを利用できます。また，ローカルインタフェースを利用する場合には，リモートインタフェースと異なり，メソッド実行時の引数および戻り値は参照渡し（pass by reference）になります。

(3)　ビジネスインタフェースに対応する機能

ビジネスインタフェースを使用した場合でも，次の機能を使用できます。

ローカル呼び出し最適化機能

機能の詳細については，「2.13.1　EJBのリモートインタフェースでのローカル呼び出しの最適化」を参照してください。

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

機能の詳細については，「2.13.2　EJBのリモートインタフェースの値の参照渡し」を参照してください。

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

機能の詳細については，「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。

通信タイムアウトの設定は，定義ファイルまたはAPIで設定します。ビジネスインタフェースを使用した場合のタイムアウトの設定についての注意事項を次に示します。

定義ファイルで設定する場合

DI機能を使用するときに，EJBコンテナ内でJNDIを使用するため，JNDIの通信タイムアウトのプロパティも有効になります。

APIで設定する場合

スレッドには設定できますが，オブジェクトには設定できません。

また，タイムアウトの発生時には，ビジネスインタフェースがjava.rmi.Remoteを継承している場合はjava.rmi.RemoteException(org.omg.CORBA.TIMEOUT)，java.rmi.Remoteを継承していない場合はjavax.ejb.EJBException(RemoteException(org.omg.CORBA.TIMEOUT))が送出されます。

EJBのチェック機能

機能の詳細については，「2.3　EJB仕様準拠のチェック」を参照してください。

J2EEアプリケーションの実行時間監視のメソッドタイムアウト機能

機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3.2　J2EEアプリケーション実行時間の監視とは」を参照してください。

アノテーションを指定したEJBのメソッド呼び出し処理では，次の表に示すメソッド単位にタイムアウト値を適用できます。

表2‒8　タイムアウトの適用範囲

インタフェース

メソッド

Stateless

Session Bean

Stateful

Session

Bean

Singleton Session Bean

Message

Driven

Bean

PersistenceAPI

ビジネスインタフェース

ビジネスメソッド※1

○

○

○

−

−

ホームまたはコンポーネントインタフェース※2

create

×

○

−

−

−

ビジネスメソッド

○

○

−

−

−

remove

×

○

−

−

−

javax.ejb.TimedObject

ejbTimeout

○

−

○

−

−

（凡例）　○：適用される。　×：適用されない。　−：該当なし。

注※1

@Timeoutアノテーション，@Removeアノテーションが付いたメソッドを含みます。

注※2

@RemoteHomeまたは@LocalHomeを使用したインタフェースを指します。

(4)　ビジネスインタフェースのEnterprise Bean呼び出し

ここでは，同一J2EEサーバ内のほかのJ2EEアプリケーションで動作するビジネスインタフェースを呼び出す場合と，ほかのJ2EEサーバで動作するビジネスインタフェースを呼び出す場合について説明します。

どちらの場合も，呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先のEnterprise Beanのビジネスインタフェース，およびインタフェースで使用するユーザ作成クラスを含めます。また，自動的にバインドされる名称（Portable Global JNDI名またはHITACHI_EJBから始まる名称），またはユーザ指定名前空間機能で設定した別名を使用してルックアップします。ルックアップで使用する名称については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.5　HITACHI_EJBから始まる名称でのルックアップ」を参照してください。

同一J2EEサーバ内のほかのJ2EEアプリケーションで動作するビジネスインタフェースのEnterprise Beanを呼び出す場合

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先のEnterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めてください。

また，J2EEサーバ用ユーザプロパティファイルのejbserver.rmi.localinvocation.scopeキーが「none」の場合は，呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドを使用してスタブを取得し，呼び出し元のEARファイルに含めてください。※

ほかのJ2EEサーバで動作するビジネスインタフェースのEnterprise Beanを呼び出す場合

呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドを使用してスタブを取得し，呼び出し元のEARファイルに含めてください。※

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用する場合は，スタブを含める必要はありません。ただし，ダイナミッククラスローディング機能は，性能上，推奨しません。

2.2.3　Enterprise Beanのライフサイクル

Enterprise Beanのライフサイクルについて，Enterprise Beanの種類ごとに説明します。

(1)　Session Beanのライフサイクル

Session Beanのライフサイクルは，次に示す場合によって異なります。

(a)　Stateless Session Beanの場合

Stateless Session Beanのライフサイクルを次の図に示します。

図2‒1　Stateless Session Beanのライフサイクル

does not exist：

Stateless Session Beanが存在しない状態

method-ready pool：

Stateless Session Beanが実行可能状態としてmethod-readyプール内に存在する状態

(b)　Stateful Session Beanの場合

Stateful Session Beanのライフサイクルを次の図に示します。

図2‒2　Stateful Session Beanのライフサイクル

does not exist：

Stateful Session Beanが存在しない状態

method-ready：

Stateful Session Beanがアクティベイトされ，実行可能状態としてmethod-readyプール内に存在する状態（トランザクションなし）

method-ready in TX：

Stateful Session Beanがアクティベイトされ，実行可能状態としてmethod-readyプール内に存在する状態（トランザクションあり）

(c)　Singleton Session Beanの場合

Singleton Session Beanのライフサイクルを次の図に示します。

図2‒3　Singleton Session Beanのライフサイクル

does not exist：

Singleton Session Beanが存在しない状態

method-ready：

Singleton Session Beanが実行可能な状態

Singleton Session Beanの初期化は，EJBコンテナによって実行されます。なお，初期化のタイミングは，アノテーションの指定によって，アプリケーション開発時に明示的に定義できます。

アプリケーションの開始処理内でSingleton Session Beanを初期化したい場合は，Singleton Session Beanクラスに@Startupアノテーションを指定します。これによって，外部のクライアントからリクエストが送信される前に初期化処理が実行されます。

@DependsOnアノテーションを指定すると，Singleton Session BeanとほかのSingleton Session Beanのコンポーネントの作成順序を定義できます。

Singleton Session Beanのインスタンスは，初期化されると，アプリケーションが停止するまで存在します。Singleton Session Beanが破棄されるタイミングでのEJBコンテナの動作は次のとおりです。

PreDestroy処理を実行するコールバックインターセプタメソッドが存在する場合は，該当のメソッドを呼び出します。このメソッドが呼び出されている間，EJBコンテナはDependOnによって依存関係が指定されたすべてのBeanが利用できるように，状態を保持します。

PreDestroy処理の完了後，EJBコンテナによってSingleton Session Beanのインスタンスが削除されます。

(2)　Entity Beanのライフサイクル

Entity Beanのライフサイクルを次の図に示します。

図2‒4　Entity Beanのライフサイクル

does not exist：

Entity Beanが存在しない状態

pool：

Entity Beanがパッシベイトされ，passiveプール内に存在する状態

ready：

Entity Beanがアクティベイトされ，readyプール内に存在する状態

(3)　Message-driven Beanのライフサイクル

Message-driven Beanのライフサイクルを次の図に示します。

図2‒5　Message-driven Beanのライフサイクル

does not exist：

Message-driven Beanが存在しない状態

method-ready pool：

Message-driven Beanがmethod-ready状態で，ServerSessionプール内に存在する状態

2.3　EJB仕様準拠のチェック

EJBコンテナでは，J2EEアプリケーションの開始時に，各Enterprise Beanに対して，EJBの仕様に準拠しているかどうかをチェックします。このチェックの結果，仕様に準拠しないEnterprise Beanがあった場合は，Enterprise Beanを含むJ2EEアプリケーションの開始に失敗します。このとき，エラーメッセージが出力されます。

EJBのチェック処理は，次のタイミングで動作します。

J2EEアプリケーションをJ2EEサーバに最初にインポートして開始する時。

J2EEアプリケーションの構成を変更して（リデプロイ機能による変更を含む）開始する時。

アップグレードインストールをしたあと，最初にJ2EEサーバを起動する時。

これらのタイミングで開始に成功すると，以降のJ2EEアプリケーションの開始と停止では，EJBチェック処理は動作しません。

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

この節では，CMPフィールドとデータ型のマッピングについて説明します。

CMPフィールドでは，Javaデータ型ごとに，指定できる範囲とプライマリキーへの指定可否が決まっています。また，Javaデータ型とデータベースのSQLデータ型の対応は，データベースの種類ごとに異なります。

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

表2‒9　この節の構成（CMPフィールドとデータ型のマッピング）

分類

タイトル

参照先

解説

CMPでサポートするJavaデータ型の範囲

2.4.1

CMPフィールドとデータベースのマッピング

2.4.2

注意事項

CMPを使用する場合の注意事項

2.4.3

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

2.4.1　CMPでサポートするJavaデータ型の範囲

EJBコンテナのEntity BeanのCMPでサポートするJavaデータ型の範囲と，プライマリキーへの指定の可否を次の表に示します。

表2‒10　CMPでサポートするJavaデータ型の範囲

Javaデータ型

値の範囲

プライマリキーへの指定

boolean

true，false

×

java.lang.Boolean

○

byte

-128〜127

×

java.lang.Byte

○

char

'¥u0000'〜'¥uffff'(0〜65535)

×

java.lang.Character

○

short

-32768〜32767

×

java.lang.Short

○

int

-2147483648〜2147483647

×

java.lang.Integer

○

long

-9223372036854775808〜9223372036854775807

×

java.lang.Long

○

float※

±1.40239846e-45〜±3.40282347e+38

×

java.lang.Float※

○

double※

±4.94065645841246544e-324〜±1.79769313486231570e+308

×

java.lang.Double※

○

byte[]

1Byte〜2147483647Byte

×

java.lang.String

−

○

java.math.BigDecimal

−

×

java.sql.Date

−

×

java.sql.Time

00:00:00〜23:59:59

×

java.sql.TimeStamp

−

×

Serializableな型

−

×

（凡例）

○：プライマリキーに指定できる。

×：プライマリキーに指定できない。

−：該当しない。

注※

浮動小数点を扱う場合，丸めが発生することがあります。

2.4.2　CMPフィールドとデータベースのマッピング

ここでは，CMPフィールドとデータベースのマッピングについて説明します。マッピングは，データベースの種類ごとに異なります。

(1)　HiRDBの場合のマッピング

HiRDBの場合のCMPフィールドとデータベースのマッピングについて，次の表に示します。

なお，表中の「Javaデータ型」はCMPがサポートするJavaのデータ型，「JDBCデータ型」はJavaのデータ型に対応するJDBCのjava.sql.Types.のデータ型，「SQLデータ型」はJavaデータ型とのマッピングで推奨するDBカラムの型となります。

表2‒11　CMPでのフィールドとデータベースのマッピング（HiRDB使用時）

Javaデータ型

JDBCデータ型

SQLデータ型

boolean

SMALLINT

SMALLINT

java.lang.Boolean

byte

SMALLINT

SMALLINT

java.lang.Byte

char※1

CHAR

CHAR(4)

java.lang.Character※1

short

SMALLINT

SMALLINT

java.lang.Short

int

INTEGER

INTEGER

java.lang.Integer

long

DECIMAL

DECIMAL(22)

java.lang.Long

float

REAL

REAL，SMALLFLT

java.lang.Float

double

FLOAT

DOUBLE PRECISION

java.lang.Double

byte[]※2

LONGVARBINARY

BLOB

java.lang.String※1

VARCHAR

VARCHAR(m)

CHAR(n)

MVARCHAR(m)

MCHAR(n)

NVARCHAR(x)

NCHAR(y)※3

java.math.BigDecimal

DECIMAL

DECIMAL(m,n)※4

java.sql.Date

DATE

DATE※5

java.sql.Time

TIME

TIME

java.sql.TimeStamp※6

CHAR

CHAR(29)

Serializableな型※2

LONGVARBINARY

BLOB

注※1

固定長文字列のSQL型を使用する場合の注意については，「2.4.3　CMPを使用する場合の注意事項」を参照してください。

注※2

[HiRDB BLOB最大値] 2147483647バイト

ただし，扱えるデータサイズの上限はJDBCドライバの上限に依存します。

HiRDB Type4 JDBC Driverを使用する場合は，JDBCドライバによる制限はありません。

注※3

m，n，x，yの範囲はそれぞれ次のとおりです。

m：1〜32000，n：1〜30000，x：1〜16000，y：1〜15000

注※4

m，nの範囲はそれぞれ次のとおりです。

m：1〜29，n：1〜29

注※5

DATEの範囲は，0001/01/01〜9999/12/31です。

注※6

「yyyy-mm-dd hh:mm:ss.fffffffff」（JDBC日付エスケープ）形式の文字列として格納します。

(2)　Oracleの場合のマッピング一覧

Oracleの場合のCMPフィールドとデータベースのマッピングについて，次の表に示します。

なお，表中の「Javaデータ型」はCMPがサポートするJavaのデータ型，「JDBCデータ型」はJavaのデータ型に対応するJDBCのjava.sql.Types.のデータ型，「SQLデータ型」はJavaデータ型とのマッピングで推奨するDBカラムの型となります。

表2‒12　CMPでのフィールドとデータベースのマッピング（Oracle使用時）

Javaデータ型

JDBCデータ型

SQLデータ型

boolean

NUMERIC

NUMBER(38)

java.lang.Boolean

byte

NUMERIC

NUMBER(38)

java.lang.Byte

char※1

CHAR

CHAR(4)

java.lang.Character※1

short

NUMERIC

NUMBER(38)

java.lang.Short

int

NUMERIC

NUMBER(38)

java.lang.Integer

long

NUMERIC

NUMBER(22)

java.lang.Long

float

NUMERIC

NUMBER

java.lang.Float

double※2

FLOAT

FLOAT(126)

java.lang.Double※2

byte[]※3

LONGVARBINARY

LONG RAW

java.lang.String※1

VARCHAR

VARCHAR(m)

CHAR(n)

LONG※4

java.math.BigDecimal

NUMERIC

NUMBER(m,n)※5

java.sql.Date

DATE

DATE※6，※7

java.sql.Time

CHAR

CHAR(8)※8

java.sql.TimeStamp

TimeStamp

DATE※7，※9

Serializableな型※3

LONGVARBINARY

LONG RAW

注　

java.sql.Types.BLOBにマッピングされるBLOB，およびjava.spl.Types.CLOBにマッピングされるCLOBは扱えません。

注※1

固定長文字列のSQL型を使用する場合の注意については，「2.4.3　CMPを使用する場合の注意事項」を参照してください。

注※2

[Oracle FLOAT(126)の範囲] 1E-125〜9.9・・・9E125

ただし，丸めが発生するおそれがあります。

注※3

[Oracle LONG RAW最大値] 2ギガバイト。

ただし，扱えるデータサイズの上限はJDBCドライバの上限に依存します。

注※4

m，nの範囲はそれぞれ次のとおりです。

m=1〜4000，n=1〜2000

また，""（長さゼロの空文字）をOracleに格納するとNULLに変換されます。

注※5

m，nの範囲はそれぞれ次のとおりです。

m=1〜38，n=-84〜127

注※6

DATEの範囲は，-4712/01/01〜9999/12/31です。

注※7

紀元前データはJava-JDBCドライバ間でマイナス値が正しく扱えないため，値は保証されません。

注※8

「hh:mm:ss」（JDBC日付エスケープ）形式の文字列として格納します。

注※9

DATEの範囲は，-4712/01/01 00:00:00〜9999/12/31 23:59:59です。

2.4.3　CMPを使用する場合の注意事項

アプリケーションサーバのEJBコンテナでCMPを使用する場合の注意事項について説明します。

固定長文字列のSQL型をCMPフィールドに用いる場合

固定長文字列のSQL型（Oracle，HiRDBのCHAR型）を用いる場合，データベース格納時にけた数に満たない文字数を空白で埋めるため，作成時のデータの後ろに空白が挿入されることがあります。したがって，使用するときは十分に注意してください。

固定長文字列のSQL型をプライマリキーに用いる場合

固定長文字列のSQL型（Oracle，HiRDBのCHAR型）をキーに用いる場合，データベース格納時にけた数に満たない文字数を空白で埋めるため，作成時のデータと値が異なり，対象Entity Beanを取得できないおそれがあります。したがって，使用するときは十分に注意してください。

removeメソッドで例外が発生した場合の対応

removeメソッド実行中に例外が発生すると，データベース上にデータが残ります。手動で削除してください。

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

この節では，EJBコンテナのJNDI名前空間へのリファレンス登録について説明します。

EJBコンテナでは，java:comp/env名前空間へのリファレンスの登録をサポートしています。

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

表2‒13　この節の構成（EJBコンテナのJNDI名前空間へのリファレンス登録）

分類

タイトル

参照先

解説

java:comp/env名前空間へのリファレンスの登録

2.5.1

実装

cosminexus.xmlでの定義

2.5.2

設定

実行環境での設定

2.5.3

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

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

2.5.1　java:comp/env名前空間へのリファレンスの登録

EJBコンテナでは，java:comp/env名前空間へのリファレンスの登録をサポートしています。なお，該当するリファレンスは，（）内に示す名前空間に登録することを推奨しています。

環境エントリ（java:comp/env）

EJBホームオブジェクトリファレンス（java:comp/env/ejb）

ビジネスインタフェースのリファレンス（java:comp/env/ejb）

JMS（java:comp/env/jms）

JDBCデータソース（java:comp/env/jdbc）

JavaMailセッション（java:comp/env/mail）

TP1 Connector（java:comp/env/eis）

JavaBeansリソース（java:comp/env/bean）

これによって，java:comp/envのJNDI名前空間を使用して，間接的なルックアップができます。

2.5.2　cosminexus.xmlでの定義

リファレンスマッピングの定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。

java:comp/envを使用する場合，参照元のアプリケーションでリファレンスマッピングを定義する必要があります。設定するタグは，設定対象になるEnterprise Beanの種類ごとに異なります。

cosminexus.xmlでのリファレンスマッピングの定義について次の表に示します。

表2‒14　cosminexus.xmlでのリファレンスマッピングの定義

項目

指定するタグ

設定内容

リソースへのリファレンスの解決

Session Beanの場合

<session>-<resource-ref>タグ

<session>-<resource-env-ref>タグ

Entity Beanの場合

<entity>-<resource-ref>タグ

<entity>-<resource-env-ref>タグ

Message-driven Beanの場合

<message-driven>-<resource-ref>タグ

<message-driven>-<resource-env-ref>タグ

<resource-ref>タグに，リソースの情報を設定します。

<resource-env-ref>タグに，リソース環境の情報を設定します。

指定するタグの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.2.2　EJB-JAR属性の詳細」を参照してください。

2.5.3　実行環境での設定

リファレンスマッピングは，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リファレンスマッピングの定義には，次の属性ファイルを使用します。

表2‒15　リファレンスマッピングの定義に使用する属性ファイル

設定対象

属性ファイル

Session Bean

Session Bean属性ファイル

Entity Bean

Entity Bean属性ファイル

Message-driven Bean

Message-driven Bean属性ファイル

属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。なお，Enterprise Beanへのリファレンスを解決するか，リソースへのリファレンスを解決するかによって，指定するタグは異なります。

cosminexus.xmlでの定義については，「2.5.2　cosminexus.xmlでの定義」を参照してください。

2.6　外部リソースとの接続

EJBコンテナで使用できるリソース，およびJ2EEリソースの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

2.7　Enterprise Beanでのトランザクション管理

この節では，Enterprise Beanでのトランザクション管理について説明します。

Enterprise Beanのトランザクションには，Enterprise Beanで管理する方法とEJBコンテナで管理する方法があります。

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

表2‒16　この節の構成（Enterprise Beanでのトランザクション管理）

分類

タイトル

参照先

解説

Enterprise Beanでのトランザクション管理方法の種類

2.7.1

BMT

2.7.2

CMT

2.7.3

実装

cosminexus.xmlでの定義

2.7.4

設定

実行環境での設定

2.7.5

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

なお，アプリケーションサーバで使用できるトランザクション管理機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4　トランザクション管理」を参照してください。

2.7.1　Enterprise Beanでのトランザクション管理方法の種類

EJBコンテナがサポートしているEnterprise Beanのトランザクション管理方法には，次の2種類があります。

BMT（Bean-Managed Transaction）

CMT（Container-Managed Transaction）

これらの機能は，J2EEサービスのトランザクション管理機能によって実現されます。

なお，トランザクション管理方法は，J2EEアプリケーションに含まれるSession BeanまたはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，「2.7.4　cosminexus.xmlでの定義」を参照してください。

トランザクション管理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」を参照してください。

2.7.2　BMT

Enterprise Beanでトランザクション管理をするモデルです。BMTは，Session BeanおよびMessage-driven Beanが対象です（Entity Beanは対象外で，常にCMTになります）。

BMTでは，Enterprise Beanのビジネスメソッドでjavax.transaction.UserTransactionを利用し，次の操作をします。

トランザクションを開始

リソースマネジャを更新

トランザクションをコミットまたはロールバック

Stateless Session Beanでは，1ビジネスメソッド内で1トランザクションを決着（コミットまたはロールバック）させる必要があります。また，Message-driven Beanでは，次のメソッド内で，トランザクションを決着（コミットまたはロールバック）させる必要があります。メソッドはEJBのバージョンごとに異なります。

onMessageメソッド（EJB 2.0の場合）

任意のメッセージリスナのメソッド（EJB 2.1以降の場合）

一方，Stateful Session Beanでは，複数のビジネスメソッドを一つのトランザクションスコープに含めることができます。このとき，EJBコンテナは，Beanインスタンスとトランザクションの関係を保持します。BMTでのStateful Session Beanを次の図に示します。

図2‒6　BMTでのStateful Session Bean

表2‒17　BMTのトランザクション制御

クライアント側トランザクション

Beanインスタンスのトランザクション

メソッドに結び付くトランザクション

なし

なし

なし

T1

なし

なし

なし

T2

T2

T1

T2

T2

（凡例）

なし：トランザクションを開始しない，またはトランザクションが関連づかない。

T1：クライアント側で開始するトランザクション。

T2：Bean側で開始するトランザクション。

注意事項

トランザクションが決着していないときに，UserTransaction.beginメソッドを使って新しいトランザクションを開始した場合，EJBコンテナはjavax.transaction.NotSupportedExceptionを送出します。

2.7.3　CMT

EJBコンテナでトランザクション管理をするモデルです。CMTは，Session Bean，Entity Bean，Message-driven Beanが対象です。CMTでは，Beanのメソッド単位でトランザクションの属性を指定します。なお，トランザクション属性は，J2EEアプリケーションに含まれるSession Bean，Entity Bean，またはMessage-driven Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，「2.7.4　cosminexus.xmlでの定義」を参照してください。

トランザクションがコミットできない場合，EJBコンテナは次の処理をします。

アプリケーションエラーのロギング

トランザクションのロールバック

Beanインスタンスの破棄

リモートコンポーネントインタフェースで呼び出すクライアントにはjava.rmi.RemoteException，ローカルコンポーネントインタフェースまたはビジネスインタフェースで呼び出すクライアントにはjavax.ejb.EJBExceptionを送出。ただし，リモートビジネスインタフェースがjava.rmi.Remoteを継承している場合には，java.rmi.RemoteExceptionを送出

(1)　トランザクション属性の種類と振る舞い

トランザクション属性の振る舞いについて，トランザクション属性の種類ごとに図に示して説明します。

NotSupported属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Bean側には伝播しません。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したときも，トランザクションコンテキストはEnterprise Beanには伝播しません。

NotSupported属性の振る舞いを次の図に示します。

図2‒7　NotSupported属性

Required属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，Enterprise Bean側で新しいトランザクションが開始されます。

Required属性の振る舞いを次の図に示します。

図2‒8　Required属性

Supports属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Beanに伝播しません。

Supports属性の振る舞いを次の図に示します。

図2‒9　Supports属性

RequiresNew属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナは新しいトランザクションを開始します。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したときも，同様に新しいトランザクションがEJBコンテナによって開始されます。

RequiresNew属性の振る舞いを次の図に示します。

図2‒10　RequiresNew属性

Mandatory属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストがEnterprise Bean側に伝播し，Enterprise Beanのビジネスメソッドは呼び出し側のトランザクションスコープ内に入ります。また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナはクライアントに次の例外を送出します。

ビジネスインタフェースを使用している場合，javax.ejb.EJBTransactionRequiredExceptionを送出します。ただし，java.rmi.Remoteを継承しているリモートビジネスインタフェースの場合は，javax.transaction.TransactionRequiredExceptionを送出します。

リモートコンポーネントインタフェースを使用している場合，javax.transaction.TransactionRequiredExceptionを送出します。

ローカルコンポーネントインタフェースを使用している場合，javax.ejb.TransactionRequiredLocalExceptionを送出します。

Mandatory属性の振る舞いを次の図に示します。

図2‒11　Mandatory属性

Never属性

クライアントがトランザクションスコープ内でEnterprise Beanのビジネスメソッドを呼び出したとき，EJBコンテナはクライアントに次の例外を送出します。

ビジネスインタフェースを使用している場合，javax.ejb.EJBExceptionを送出します。ただし，java.rmi.Remoteを継承しているリモートビジネスインタフェースの場合は，java.rmi.RemoteExceptionを送出します。

リモートコンポーネントインタフェースを使用している場合，java.rmi.RemoteExceptionを送出します。

ローカルコンポーネントインタフェースを使用している場合，javax.ejb.EJBExceptionを送出します。

また，クライアントがトランザクションスコープ外でEnterprise Beanのビジネスメソッドを呼び出したとき，トランザクションコンテキストはEnterprise Beanに伝播しません。

Never属性の振る舞いを次の図に示します。

図2‒12　Never属性

(2)　Enterprise Beanの種別ごとに指定できるトランザクション属性

Enterprise Beanの種別ごとに指定できるトランザクション属性およびデフォルト値を次の表に示します。EJB仕様ではBean種別ごとに指定できるトランザクション属性が規定されています。CMP 2.0については，EJB仕様でオプションとされている，ほかのトランザクション属性は指定できません。デフォルト値についてはEJB仕様では規定されていません。アプリケーションサーバの場合，EJBのDDでCMTの指定があり，トランザクション属性の指定がない場合のデフォルト設定は，次の表のようになります。

表2‒18　Enterprise Beanの種別ごとに指定できるトランザクション属性およびデフォルト値

種別

指定できるトランザクション属性

デフォルト値

Stateless Session Bean

Stateful Session Bean

（SessionSynchronization以外）

Entity Bean（BMP，CMP 1.1）

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Supports

Stateful Session Bean

（SessionSynchronization）

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Required

Singleton Session Bean

（PostConstruct/PreDestroyを除く）※1

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Required

Entity Bean（CMP 2.0）

Required

RequiresNew

Mandatory

Required

Message-driven Bean（Connector 1.0に準拠したリソースアダプタを使用する場合）

Required

NotSupported

Required

Message-driven Bean（Connector 1.5に準拠したリソースアダプタを使用する場合）

Required※2

NotSupported

Required※2

アノテーションを使用した，DDを持たないSession Bean

Supports

NotSupported

Required

RequiresNew

Mandatory

Never

Required

注

DDを持たないEnterprise Beanの場合，デフォルト値（Required）が規定されています。

注※1

アプリケーションサーバでは，Singleton Session Beanのライフサイクルコールバックメソッド（PostConstructまたはPreDestroy）でトランザクション属性を指定しても無効になります。

注※2

CJMSPリソースアダプタまたはFTPインバウンドアダプタの場合は指定できません。

(3)　Stateful Session Bean（SessionSynchronization）のトランザクション属性

SessionSynchronizationは，トランザクションの開始および停止に同期してメッセージを通知するためのインタフェースです。EJB仕様では，SessionSynchronizationを実装したStateful Session Beanのトランザクション属性に指定できるのは，Required，RequiresNewまたはMandatoryと規定されています。これに対して，アプリケーションサーバでは，Supports，NotSupportedおよびNeverも指定できます。

ここでは，指定したトランザクション属性とメソッド呼び出しの有無の対応，およびコールバックメソッドを呼び出すタイミングについて説明します。なお，コールバックメソッドとは，次のメソッドのことです。

afterBeginメソッド

次のどちらかのメソッドです。

javax.ejb.SessionSynchronizationインタフェースのafterBeginメソッドを実装したメソッド

@AfterBeginを指定したメソッド

beforeCompletionメソッド

次のどちらかのメソッドです。

javax.ejb.SessionSynchronizationインタフェースのbeforeCompletionメソッドを実装したメソッド

@BeforeCompletionを指定したメソッド

afterCompletionメソッド

次のどちらかのメソッドです。

javax.ejb.SessionSynchronizationインタフェースのafterCompletionメソッドを実装したメソッド

@AfterCompletionを指定したメソッド

なお，アノテーションの利用については，「2.18　Session Synchronizationのアノテーションでの指定」を参照してください。

(a)　トランザクション属性とメソッド呼び出しの有無

SessionSynchronizationを実装したStateful Session Beanのトランザクション属性と，ビジネスメソッドまたはコールバックメソッドの呼び出し有無の対応について，次の表に示します。

表2‒19　ビジネスメソッドまたはコールバックメソッドでのメソッド呼び出し有無

トランザクション属性

クライアントのトランザクション有無

ビジネスメソッドの呼び出し

SessionSynchronizationのコールバックメソッド呼び出し

Supports

あり

○※1

○※1

なし

○※1

×

NotSupported

あり

○※1

×

なし

○※1

×

Required

あり

○

○

なし

○

○

RequiresNew

あり

○

○

なし

○

○

Mandatory

あり

○

○

なし

×※2

×

Never

あり

×※2

×

なし

○※1

×

（凡例）

○：メソッドを呼び出す。

×：メソッドを呼び出さない。

注※1

アプリケーションサーバ独自の動作です。

注※2

EJB仕様で規定された例外がスローされます。

(b)　コールバックメソッドを呼び出すタイミング

同一のEnterprise Beanのビジネスメソッドを複数回呼び出す場合，トランザクションに最初にEntprise Beanが参加するタイミングで，コールバックメソッドであるafterBeginメソッドが呼び出されます。

afterBeginメソッドを呼び出すタイミングの例として，トランザクションに参加しないビジネスメソッド実行後にトランザクションに参加するビジネスメソッドを実行した場合の動作を次の図に示します。

図2‒13　コールバックメソッドを呼び出すタイミングの例

2.7.4　cosminexus.xmlでの定義

Enterprise Beanのトランザクション管理方法の定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。設定するタグは，設定対象になるEnterprise Beanの種類ごとに異なります。

cosminexus.xmlでのEnterprise Beanのトランザクション管理方法の定義について次の表に示します。

表2‒20　cosminexus.xmlでのEnterprise Beanのトランザクション管理方法の定義

項目

指定するタグ

設定内容

Enterprise Beanでのトランザクション管理方法（BMTまたはCMT）の選択※

Session Beanの場合

<session>-<transaction-type>タグ

Message-driven Beanの場合

<message-driven>-<transaction-type>タグ

Bean（BMT）またはContainer（CMT）のどちらを選択するかを指定します。

メソッドに割り当てるトランザクション属性（CMTの場合）

Session Beanの場合またはEntity Beanの場合

<assembly-descriptor>-<container-transaction>-<trans-attribute>

Message-driven Beanの場合

<message-driven>-<container-transaction>-<trans-attribute>

メソッドに割り当てるトランザクション属性を指定します。

注※

BMTを選択した場合，トランザクションの制御は，API（javax.transaction.UserTransactionクラスのメソッドなど）で実行する必要があります。

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

2.7.5　実行環境での設定

Enterprise Beanのトランザクション管理方法は，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リファレンスマッピングの定義には，次の属性ファイルを使用します。

表2‒21　Enterprise Beanのトランザクションの管理方法の定義に使用する属性ファイル

設定対象

属性ファイル

Session Bean

Session Bean属性ファイル

Entity Bean

Entity Bean属性ファイル

Message-driven Bean

Message-driven Bean属性ファイル

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

2.8　Entity Beanのキャッシュモデル

この節では，Entity Beanのキャッシュモデルについて説明します。

Entity Beanでは，3種類のキャッシュモデルをサポートしています。

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

表2‒22　この節の構成（Entity Beanのキャッシュモデル）

分類

タイトル

参照先

解説

Entity Beanのキャッシュモデルの種類

2.8.1

実装

cosminexus.xmlでの定義

2.8.2

設定

実行環境での設定

2.8.3

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

2.8.1　Entity Beanのキャッシュモデルの種類

Entity Beanでは，次に示す3種類のCMPフィールドのキャッシュ方法，およびEntity Beanの状態遷移をサポートしています。

Full caching（commit option A）

Caching（commit option B）

No caching（commit option C）

なお，コミットオプションは，J2EEアプリケーションに含まれるEntity Beanの属性（プロパティ）として設定します。J2EEアプリケーションの設定については，「2.8.2　cosminexus.xmlでの定義」を参照してください。

(1)　Full caching（commit option A）

Full cachingは，参照系のEntity Bean用のキャッシュモデルです。トランザクション開始時にデータベースからEntity Beanインスタンスにデータが読み込まれません。このため，Entity Beanが前回のトランザクションコミット時と同じ状態のままでトランザクションが開始されます。

例えば，前回のトランザクションコミット時からトランザクション開始時の間にほかのJ2EEサーバがEntity Beanを更新した場合，Entity Beanの状態の一貫性が保たれません。

(2)　Caching（commit option B）

Cachingは，更新系のEntity Beanのキャッシュモデルです。トランザクション開始時にデータベースからEntity Beanインスタンスにデータが読み込まれます。このため，Entity Beanがデータベースの最新状態と同じ状態でトランザクションが開始されます。

(3)　No caching（commit option C）

No cachingは，更新系のEntity Beanのキャッシュモデルです。トランザクションコミット時にEntity Beanが非活性化されます。トランザクション開始時には，一度活性化され，データベースからEntity Beanインスタンスにデータが読み込まれます。このため，Entity Beanがデータベースの最新状態と同じ状態でトランザクションが開始されます。このため，多数のEntity Beanを利用する場合に適用するキャッシュモデルです。

2.8.2　cosminexus.xmlでの定義

Entity Beanのキャッシュモデルのコミットオプションの定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。

指定するタグ

<entity>-<caching-model>タグ

設定内容

CMPフィールドのキャッシュ方法を指定します。

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

2.8.3　実行環境での設定

Entity Beanのキャッシュモデルのコミットオプションの定義は，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。Entity Beanのキャッシュモデルのコミットオプションの定義には，Entity Bean属性ファイルを使用します。

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

2.9　Enterprise Beanのプールの管理

この節では，Enterprise Beanのプールの管理について説明します。

EJBコンテナでは，Enterprise Beanの種類ごとに，プールを作成して管理します。

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

表2‒23　この節の構成（Enterprise Beanのプールの管理）

分類

タイトル

参照先

解説

Stateless Session Beanのプーリング

2.9.1

Entity Beanのプーリング

2.9.2

Message-driven Beanのプーリング

2.9.3

実装

cosminexus.xmlでの定義

2.9.4

設定

実行環境での設定

2.9.5

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

2.9.1　Stateless Session Beanのプーリング

Stateless Session Beanのプーリングは，クライアント側からのアクセス量に応じてStateless Session Beanをプーリングする機能です。EJBコンテナではStateless Session Beanごとにプールを作成して管理します。最大値※，最小値を指定することで，プーリングの動作をカスタマイズできます。

J2EEアプリケーション開始時には，最小値分のStateless Session Beanが生成され，プーリングされます。プーリングされたStateless Session Beanはmethod-ready状態で，クライアントからアクセスされるとすぐに実行されます。プーリングされるStateless Session Beanの数は，クライアントからのアクセス量に応じて，最大値と最小値の間になります。

このStateless Session Beanに対するクライアント要求数が最大数を超えると，インスタンスが使用できるようになるまで実行が待たされます。

注※

Stateless Session Beanでのプーリングの最大値は，クライアントが同時に確立できる最大セッション数となります。

2.9.2　Entity Beanのプーリング

Entity Beanのプーリングは，クライアント側からのアクセス量に応じてEntity Beanをプーリングする機能です。EJBコンテナでは，Entity Beanごとにプールを作成して管理します。最大値，最小値を指定することで，プーリングの動作をカスタマイズできます。

J2EEアプリケーション開始時には，最小値分のEntity Beanが生成され，プーリングされます。プーリングされるEntity Beanの数は，クライアントからのアクセス量に応じて，最大値と最小値の間になります。

さらに，プーリングされたEntity Beanの状態には，ready状態とpool状態の二つがあります。

ready状態のEntity Bean

データがデータベース上からインスタンス中に読み込まれた状態のもので，Entity Beanとしてのアイデンティティを持っています。ready状態のものは，クライアントからアクセスされた時点ですでに実行可能状態になっています。

pool状態のEntity Bean

データがデータベース上からインスタンス中に読み込まれていない状態のもので，Entity Beanとしてのアイデンティティを持っていません。pool状態のものは，一度活性化され，ready状態になってから実行可能状態になります。

ready状態のEntity Beanが多くなると，幾つかが非活性化され，pool状態になります。ただし，このとき，ready状態のEntity Beanの中でトランザクション中のものについては，非活性化の対象になりません。

2.9.3　Message-driven Beanのプーリング

Message-driven Beanのプーリングは，メッセージの数に応じてMessage-driven Beanをプーリングする機能です。最大値を指定することで，プーリングの動作をカスタマイズできます。

JMSからの要求に従って，プール内のインスタンスの最大数に指定した値分のインスタンスが，デプロイ時に生成されます。

インスタンスは，JMSからの要求に従って破棄されます。

2.9.4　cosminexus.xmlでの定義

Enterprise Beanのプール管理の定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。設定するタグは，設定対象になるEnterprise Beanの種類ごとに異なります。

cosminexus.xmlでのEnterprise Beanのプール管理の定義について次の表に示します。

表2‒24　cosminexus.xmlでのEnterprise Beanのプール管理の定義

項目

指定するタグ

設定内容

Stateless Session Beanのプーリング

<session>-<stateless>-<pooled-instance>タグ

プールするインスタンス数の最大値と最小値を指定します。

Entity Beanのプーリング

<entity>-<pooled-instance>タグ

Message-driven Beanのプーリング

<message>-<pooled-instance>タグ

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

2.9.5　実行環境での設定

Enterprise Beanのプール管理の定義は，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リファレンスマッピングの定義には，次の属性ファイルを使用します。

表2‒25　Enterprise Beanのトランザクションの管理方法の定義に使用する属性ファイル

設定対象

属性ファイル

Session Bean

Session Bean属性ファイル

Entity Bean

Entity Bean属性ファイル

Message-driven Bean

Message-driven Bean属性ファイル

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

2.10　Enterprise Beanへのアクセス制御

この節では，Enterprise Beanへのアクセス制御について説明します。

EJBコンテナでは，J2EEサービスのセキュリティ管理機能によって，クライアントからEnterprise Beanへのアクセスを制御できます。

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

表2‒26　この節の構成（Enterprise Beanへのアクセス制御）

分類

タイトル

参照先

解説

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

2.10.1

設定

実行環境での設定

2.10.2

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

なお，Enterprise Beanへのアクセス制御以外のセキュリティ管理の機能については，マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」を参照してください。

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

EJBコンテナでは，J2EEサービスのセキュリティ管理機能によって，Enterprise Beanへのアクセスを制御できます。また，J2EEサーバのデフォルトの動作で，アプリケーションがアクセス制御の機能を利用していない場合でも，アクセス制御のための基本処理が動作します。

これに対して，Enterprise Beanへのアクセス制御を抑止するオプション（Enterprise Beanへのアクセス制御の抑止オプション）を使用すると，ビジネスメソッド呼び出し時に呼び出し元の実行権限のチェックを抑止できます。チェックを抑止すると，EJBコンテナではアクセス制御のための処理がまったく実施されないため，Enterprise Beanのビジネスメソッドの呼び出し処理が軽くなります。このため，アクセス制御の機能を利用しない場合は，抑止オプションを使用することをお勧めします。

ただし，アクセス制御の抑止オプションを利用したJ2EEサーバから，異なるJ2EEサーバ上のアクセス制御機能を利用したEnterprise Beanを呼び出す場合は，エラーが発生するので注意してください。

Enterprise Beanへのアクセス制御の抑止の設定は，J2EEサーバのプロパティをカスタマイズして設定します。

2.10.2　実行環境での設定

Enterprise Beanへのアクセス制御を使用する場合，J2EEサーバの設定が必要です。

簡易構築定義ファイルでのEnterprise Beanへのアクセス制御の抑止の定義は，論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルのJ2EEサーバのJavaVMのシステムプロパティに設定します。

パラメタ名と設定内容は次のとおりです。

指定するパラメタ名

ejbserver.container.security.disabled

設定内容

Enterprise Beanへのアクセス制御機能を抑止するかどうかを指定します。

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

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

この節では，EJBコンテナでのタイムアウトの設定について説明します。

EJBコンテナでは，次に示すタイムアウトを設定できます。

Stateful Session Beanのタイムアウト

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

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

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

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

表2‒27　この節の構成（EJBコンテナでのタイムアウトの設定）

分類

タイトル

参照先

解説

タイムアウトの種類

2.11.1

Stateful Session Beanのタイムアウト

2.11.2

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

2.11.3

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

2.11.4

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

2.11.5

実装

cosminexus.xmlでの定義

2.11.6

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

2.11.7

設定

実行環境での設定

2.11.8

注意事項

通信のタイムアウト設定時の注意事項

2.11.9

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

2.11.1　タイムアウトの種類

EJBコンテナで設定できるタイムアウトの種類，タイムアウト機能の概要，および参照先を次の表に示します。

表2‒28　タイムアウトの種類

タイムアウトの種類

タイムアウトの概要

Stateful Session Beanのタイムアウト

Stateful Session Beanが最後にアクセスされた時点からのタイムアウト時間を設定します。指定された時間が経過したものを削除します。

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

非活性化されたEntity Beanに結び付くEJBオブジェクトにタイムアウト時間を設定します。指定された時間が経過したものを削除します。

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

EJBクライアント−CORBAネーミングサービス間，およびEJBクライアント−Enterprise Bean間の通信にタイムアウト時間を設定します。

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

Stateless Session Bean，Entity Beanに，リクエスト受信時のインスタンス取得の待ち時間にタイムアウト時間を設定します。

2.11.2　Stateful Session Beanのタイムアウト

Stateful Session Beanが最後にアクセスされた時点からの経過時間を監視し，指定された時間が経過してもクライアントからアクセスされない場合，タイマによってStateful Session Beanを削除する機能です。EJBコンテナでは，タイムアウト時間を指定できます。ただし，トランザクション中のStateful Session Beanについては，削除の対象になりません。

なお，タイムアウトによって削除されたStateful Session Beanを呼び出すと，インタフェースの種類によって，次の例外が送出されます。

リモートコンポーネントインタフェースの場合

java.rmi.NoSuchObjectExceptionが送出されます。

ローカルコンポーネントインタフェースの場合

java.ejb.NoSuchObjectLocalExceptionが送出されます。

ビジネスインタフェースの場合

javax.ejb.NoSuchEJBExceptionが送出されます。ただし，ビジネスインタフェースがjava.rmi.Remoteを継承している場合は，java.rmi.NoSuchObjectExceptionが送出されます。

Stateful Session Beanのタイムアウトの設定は，J2EEアプリケーションに含まれるSession Beanの属性（プロパティ）として設定します。設定方法については，「2.11.6　cosminexus.xmlでの定義」を参照してください。

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

非活性化されたEntity Beanに結び付くEJBオブジェクトのうち，指定された時間が経過したものを削除する機能です。EJBコンテナでは，タイムアウト時間を指定できます。なお，タイムアウトによってEJBオブジェクトを削除されたEntity Beanを呼び出した場合，例外（java.rmi.NoSuchObjectException）が発生します。

ローカルインタフェースのEJBローカルオブジェクトも同様にタイムアウトによる削除対象になります。Entity BeanがEJBオブジェクト，EJBローカルオブジェクトの両方を持つ場合，非活性化されたEntity Beanに対するアクセスが，指定された時間内にどちらのインタフェースからもないときは，EJBオブジェクト，EJBローカルオブジェクトを削除します。削除されたEJBローカルオブジェクトを呼び出した場合，例外（javax.ejb.NoSuchObjectLocalException）が発生します。

Entity BeanのEJBオブジェクトのタイムアウトの設定は，J2EEアプリケーションに含まれるEntity Beanの属性（プロパティ）として設定します。設定方法については，「2.11.6　cosminexus.xmlでの定義」を参照してください。

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

EJBコンテナは，リクエストを受け付けるとインスタンスの割り当てをします。割り当て時に，インスタンスプール（Stateless Session Beanのmethod-readyプールおよびEntity Beanのpoolプール）に最大値が指定されている場合で，すべてのインスタンスでほかのリクエストを処理しているときには，インスタンスの取得待ちが発生します。この待ち時間に，タイムアウトを設定できます。

タイムアウトを設定していると，設定した時間内にインスタンスが取得できない場合は，クライアントに例外が返ります。

インスタンス取得待ちのタイムアウトの設定は，J2EEアプリケーションに含まれるSession BeanまたはEntity Beanの属性（プロパティ）として設定します。設定方法については，「2.11.6　cosminexus.xmlでの定義」を参照してください。

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

EJBクライアント−CORBAネーミングサービス間，EJBクライアント−Enterprise Bean間の通信に対して，タイムアウトを設定できます。また，EJBクライアントとJ2EEサーバの間にCTMを配置している場合，通信タイムアウトは，EJBクライアント−CTM間，およびCTM−J2EEサーバ間に設定できます。

RMI-IIOPの通信のタイムアウトには，EJBコンテナがRMI-IIOPの通信基盤として利用するTPBrokerのリクエストタイムアウト機能を利用します。

タイムアウトの設定は，設定する範囲によって，定義ファイルのプロパティ，またはアプリケーションサーバが提供するAPIのどちらかで行います。

(1)　タイムアウトを設定できるRMI-IIOP通信

タイムアウトを設定できるRMI-IIOP通信を，CTM連携ありの場合となしの場合について図に示し，タイムアウトの設定範囲について説明します。

図2‒14　タイムアウトを設定できる通信（CTM連携ありの場合）

図2‒15　タイムアウトを設定できる通信（CTM連携なしの場合）

RMI-IIOP通信のタイムアウトは，図のA，B，Cの3か所に設定できます。

Aの場合

項番1.〜6.のRMI-IIOP通信すべてにタイムアウトが有効になります。タイムアウトの設定は，定義ファイルで行います。定義ファイルでの設定方法については，「2.11.8(1)　RMI-IIOP通信のタイムアウトの設定（J2EEサーバおよびEJBクライアントアプリケーションの設定）」を参照してください。

Bの場合

項番1.，2.のCORBAネーミングサービスとの通信にタイムアウトが有効になります。タイムアウトの設定は，定義ファイルで行います。定義ファイルでの設定方法については，「2.11.8(1)　RMI-IIOP通信のタイムアウトの設定（J2EEサーバおよびEJBクライアントアプリケーションの設定）」を参照してください。

Cの場合

項番4.〜6.のAPIの通信にタイムアウトが有効になります。

EJBクライアントアプリケーションでのcreate〜ビジネスメソッド〜removeまでのAPIの通信のタイムアウト時間の設定は，アプリケーション開発時にAPI（RequestTimeoutConfigFactoryクラスおよびRequestTimeoutConfigクラスのメソッド）によって設定します。APIでの設定方法については，「2.11.7　RMI-IIOP通信のタイムアウトの実装」を参照してください。

(2)　通信タイムアウトの設定範囲とタイミング

この機能による通信タイムアウトは，ORBに対して設定します。つまり，ORB配下のすべてのRMI-IIOP通信に対して設定されます。

設定のタイミングは，クライアント起動後の最初のnew javax.naming.InitialContext()実行時です。

CORBAネーミングサービスを利用しない場合でも，この機能を利用するときは，new javax.naming.InitialContext()をクライアントの処理の最初で実行してください。

(3)　通信タイムアウト発生時のクライアントの処理

クライアントからのリクエストに対してプロパティ指定値以内にレスポンスが返らない場合，該当リクエストはタイムアウトとしてキャンセルされます。この機能によって通信タイムアウトが発生した場合，java.rmi.RemoteException（org.omg.CORBA.TIMEOUT）の例外が発生します。この機能を利用するクライアントでは，Enterprise Beanのビジネスメソッド呼び出しなどで，この例外が発生することを考慮する必要があります。

2.11.6　cosminexus.xmlでの定義

EJBコンテナでのタイムアウトの設定のうち，Stateful Session Bean，およびEntity BeanのEJBオブジェクトまたはインスタンス取得待ちのタイムアウトの定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。設定するタグは，設定対象になるEnterprise Beanの種類ごとに異なります。

cosminexus.xmlでのEJBコンテナでのタイムアウトの定義について次の表に示します。

表2‒29　cosminexus.xmlでのEJBコンテナでのタイムアウトの定義

項目

指定するタグ

設定内容

Stateful Session Beanのタイムアウト

<session>-<stateful>-<removal-timeout>タグ

セッションが削除されるまでに非アクティブ状態に保持しておく時間を指定します。

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

<entity>-<entity-timeout>タグ

EJBオブジェクトの存在時間を指定します。

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

Session Beanの場合

<session>-<stateless>-<instance-timeout>タグ

Entity Beanの場合

<entity>-<instance-timeout>タグ

インスタンス取得タイムアウト時間を指定します。

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

2.11.7　RMI-IIOP通信のタイムアウトの実装

RMI-IIOP通信のタイムアウトは，APIで設定できます。

APIで設定できるのは，「図2-14　タイムアウトを設定できる通信（CTM連携ありの場合）」または「図2-15　タイムアウトを設定できる通信（CTM連携なしの場合）」のCです。APIで設定する場合，com.hitachi.software.ejb.ejbclientパッケージのAPIを利用します。com.hitachi.software.ejb.ejbclientパッケージのAPIの機能と文法については，マニュアル「アプリケーションサーバリファレンス API編」の「4.　EJBクライアントアプリケーションで使用するAPI」を参照してください。

RMI-IIOPの通信タイムアウトは，クライアントのプロセス起動後の，最初のInitialContext生成時にプロパティに指定した値が設定されます。ネーミングサービスを利用しない場合でも，RMI-IIOPの通信タイムアウトを設定する場合は，InitialContextを生成する必要があります。

ネーミングサービスの通信タイムアウトを設定する場合は，InitialContext生成やlookupなどの，JNDIのAPI呼び出し時にプロパティに指定した値が設定されます。

2.11.8　実行環境での設定

EJBコンテナでのタイムアウトのうち，RMI-IIOP通信のタイムアウトは，クライアントプロセスであるJ2EEサーバまたはEJBクライアントアプリケーションで設定できます。

また，Stateful Session Bean，Entity BeanのEJBオブジェクトまたはインスタンス取得待ちのタイムアウトは，J2EEアプリケーションで設定できます。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合に参照してください。

(1)　RMI-IIOP通信のタイムアウトの設定（J2EEサーバおよびEJBクライアントアプリケーションの設定）

設定できるのは，「図2-14　タイムアウトを設定できる通信（CTM連携ありの場合）」または「図2-15　タイムアウトを設定できる通信（CTM連携なしの場合）」のAまたはBです。

プロパティで設定する場合，タイムアウトの設定方法はEnterprise Beanがどこから呼び出されるか（EJBクライアントの形態）によって異なります。設定は，呼び出し元（EJBクライアント側）のJ2EEサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。

(a)　EJBクライアントの形態がEnterprise Bean，JSPまたはサーブレットの場合

設定は，クライアント側のEnterprise Bean，JSPまたはサーブレットが動作するJ2EEサーバに設定します。J2EEサーバの設定は，簡易構築定義ファイルで実施します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定してください。

指定するパラメタ

ejbserver.rmi.request.timeout

設定内容

RMI-IIOP通信のクライアントとサーバ間の通信タイムアウト時間を指定します。

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

(b)　EJBクライアントの形態がEJBクライアントアプリケーションの場合

EJBクライアントアプリケーションに，EJBクライアントアプリケーションの実行時に有効なプロパティとして設定します。

usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）に，次のキーを指定してください。

指定するキー

ejbserver.rmi.request.timeoutキー

設定内容

RMI-IIOP通信のクライアントとサーバ間の通信タイムアウト時間を指定します。

usrconf.propertiesおよびキーについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

(2)　Stateful Session Bean，Entity BeanのEJBオブジェクトまたはインスタンス取得待ちのタイムアウトの定義

Stateful Session Bean，Entity BeanのEJBオブジェクトまたはインスタンス取得待ちのタイムアウトの定義は，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リファレンスマッピングの定義には，次の属性ファイルを使用します。

表2‒30　Stateful Session Bean，Entity BeanのEJBオブジェクトまたはインスタンス取得待ちのタイムアウトの定義に使用する属性ファイル

設定対象

属性ファイル

Session Bean

Session Bean属性ファイル

Entity Bean

Entity Bean属性ファイル

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

2.11.9　通信のタイムアウト設定時の注意事項

通信タイムアウト設定時の注意事項について説明します。

通信タイムアウトの定義が重複している場合の注意事項

「図2-14　タイムアウトを設定できる通信（CTM連携ありの場合）」または「図2-15　タイムアウトを設定できる通信（CTM連携なしの場合）」のAの範囲とBの範囲の両方に通信タイムアウトを設定している場合，およびAの範囲とCの範囲に通信タイムアウトを設定している場合は次のように動作します。

Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合の動作

Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合，通信タイムアウトは次の図のようになります。

図2‒16　Aの範囲とBの範囲の両方に通信タイムアウトを設定している場合の動作

Aの範囲とCの範囲の両方に通信タイムアウトを設定している場合の動作

Aの範囲とCの範囲の両方に通信タイムアウトを設定している場合，Cの範囲の通信タイムアウト設定が有効となります。

クライアント実装時の注意事項

RMI-IIOPの通信タイムアウト，ネーミングサービスの通信タイムアウトと同時に，クライアントからのリクエストに対して指定値以内にレスポンスが返らない場合，該当するリクエストはタイムアウトとしてキャンセルされます。このとき，例外java.rmi.RemoteException（org.omg.CORBA.TIMEOUTなど）やjavax.naming.NamingExceptionが送出されます。通信タイムアウトを利用するクライアントを実装する場合，Enterprise Beanのメソッド呼び出しやJNDIのAPIなどでこれらの例外が発生することを考慮してください。

タイムアウト発生後のサーバ側の動作についての注意事項

クライアントからのリクエストがサーバ（ネーミングサービスやEnterprise Bean）に到着したあとに，サーバ側の処理中にタイムアウトが発生すると，クライアントに例外が返されます。ただし，タイムアウト発生後もサーバ側では正常に処理が継続されるため，Enterprise Beanのインスタンスの破棄や，リソースコネクションなどの資源の解放はされません。

2.12　Timer Serviceの機能

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

Timer Serviceは，指定した時刻，経過時間，または間隔でEJBコンテナがEnterprise Beanを呼び出す機能です。

Timer Serviceは，EJB 2.1以降で使用できます。バージョンごとに使用できる機能の詳細はEJBの仕様を確認してください。

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

表2‒31　この節の構成（Timer Serviceの機能）

分類

タイトル

参照先

解説

Timer Serviceの概要

2.12.1

EJBタイマの生成とコールバック実行時の動作

2.12.2

EJBタイマの自動生成

2.12.3

EJBタイマの削除

2.12.4

Timer Serviceの運用機能

2.12.5

EJBタイマとコールバックの動作

2.12.6

実装

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

2.12.7

Timer Service実装時の注意事項

2.12.8

設定

実行環境での設定

2.12.9

注意事項

Timer Serviceを利用する場合の注意事項

2.12.10

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

2.12.1　Timer Serviceの概要

Timer Serviceとは，指定した時刻，経過時間，または間隔でEnterprise Beanを呼び出す機能です。この機能はEJBコンテナが提供します。Timer Serviceを使用すると，マシン負荷が低い時間を指定したバッチ処理や，一定間隔での日次処理など，時刻を指定した処理を容易に実行できます。

ここでは，Timer Serviceで設定できるタイムアウトの内容や，タイムアウトを設定するEJBタイマの動作，Timer Serviceの運用などについて説明します。

Timer Serviceで設定できるタイムアウトやTimer Serviceのサポート範囲，Timer Serviceでのトランザクション管理について説明します。

(1)　Timer ServiceとEJBタイマ

Timer Serviceは，Java EEに規定されたAPIを使用して，Enterprise Beanから操作します。時刻を指定した処理を行うには，EJBタイマを生成します。EJBタイマにはタイムアウト時刻を指定します。生成されたEJBタイマは，EJBコンテナに管理され，タイムアウト時刻になると，EJBコンテナによってEnterprise Beanのメソッドがコールバックされます。この際にコールバックされるメソッドを，タイムアウトメソッドと呼びます。

Timer Serviceの処理の概要を次の図に示します。

図2‒17　Timer Serviceの処理の概要

(2)　EJBタイマの種別

EJBタイマに設定できるタイマ種別には次の種類があります。

single-eventタイマ

タイムアウトメソッドを1回だけ実行するためのEJBタイマです。

タイムアウトの設定には，タイムアウトメソッドを実行する時刻を指定する方法と，EJBタイマ生成メソッドを呼び出してからタイムアウトメソッドを実行するまでの時間を指定する方法があります。

javax.ejb.TimerServiceインタフェースの次のメソッドで生成できます。

createTimer(long duration, Serializable info)メソッド

createTimer(Date expiration, Serializable info)メソッド

createSingleActionTimerメソッド

intervalタイマ

一定間隔で，繰り返しタイムアウトメソッドを実行するためのEJBタイマです。

タイムアウトの設定には，1回目のタイムアウトメソッドを実行する時刻を指定する方法と，EJBタイマ生成メソッドを呼び出してから1回目のタイムアウトメソッドを実行するまでの時間を指定する方法があります。また，この設定のほかに，2回目以降のタイムアウトメソッドを実行するためのタイムアウトの間隔を指定します。この間隔は，タイムアウトから次のタイムアウトまでの間隔です。

javax.ejb.TimerServiceインタフェースの次のメソッドで生成できます。

createTimer(long initialDuration, long intervalDuration, Serializable info)メソッド

createTimer(Date initialExpiration, long intervalDuration, Serializable info)メソッド

createIntervalTimerメソッド

calendar-basedタイマ

カレンダー形式で指定した日時にタイムアウトメソッドを実行するためのEJBタイマです。一つまたは複数の値を指定できます。また，ワイルドカードや範囲の指定もできます。calendar-basedタイマの指定方法の詳細は，「2.12.7(3)　カレンダー形式でスケジュールを指定する場合の指定方法」を参照してください。

javax.ejb.TimerServiceインタフェースの次のメソッドで生成できます。

createCalendarTimerメソッド

また，@Scheduleアノテーションを使用して作成することもできます。詳細は，「2.12.3　EJBタイマの自動生成」を参照してください。

EJBタイマに設定できるタイマ種別と設定できる例を次の表に示します。

表2‒32　EJBタイマに設定できるタイマ種別と設定できる例

タイマ種別

設定できる例

説明

single-event

2006/4/15　12：00

2006/4/15　12：00にタイムアウトメソッドを1回だけ実行します。

24時間後

EJBタイマが生成されてから24時間後に，タイムアウトメソッドを1回だけ実行します。

interval

2006/4/1　12：00から24時間間隔

2006/4/1　12：00に1回目のタイムアウトメソッドを実行します。そのあと，24時間間隔でタイムアウトメソッドを繰り返し実行します。

24時間後から10時間間隔

EJBタイマが生成されてから24時間後に，1回目のタイムアウトメソッドを実行します。そのあと，10時間間隔でタイムアウトメソッドを繰り返し実行します。

calendar-based

毎月1日　12：00

毎月1日の12時になるとタイムアウトメソッドを実行します。

EJBタイマのうち，single-eventタイマとintervalタイマの動作を次の図に示します。この図では，2：00にタイムアウトメソッドを1回だけコールバックするsingle-eventタイマと，2：00から2時間間隔でタイムアウトメソッドをコールバックするintervalタイマの動作を示しています。

図2‒18　single-eventタイマとintervalタイマの動作

(3)　Timer Serviceのサポート範囲

Java EEの仕様で規定されている，Timer Serviceの機能のサポート状況を次の表に示します。

表2‒33　Java EEの仕様で規定されているTimer Serviceの機能のサポート状況

Java EEの仕様で規定されているTimer Serviceの機能

サポート状況

トランザクション

○

EJBタイマ永続性

×※

TimerServiceオブジェクトの取得（DI，JNDIルックアップ，EJBContext）

○

タイムアウトメソッドの指定(アノテーション，TimedObject実装)

○

タイムアウトメソッドの指定（DDによる指定）

×

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

注※

@Scheduleアノテーションのpersistent属性の指定も有効になりません。

障害などでJ2EEサーバを再起動したときは，再起動前に使用していたEJBタイマは引き継がれません。J2EEサーバ起動時にEJBタイマを自動で生成する場合は，「2.12.3　EJBタイマの自動生成」を参照してください。

Enterprise Beanの種別ごとに，Timer Serviceの機能のサポート状況を次の表に示します。

表2‒34　Enterprise Beanの種別ごとの，Timer Serviceの機能のサポート状況

Timer Serviceの機能

Message-driven Bean

Session Bean

Entity Bean

Stateful Session Bean

Stateless Session Bean

Singleton Session Bean

TimerServiceオブジェクトの取得

×

−

○

○

×

Timer Serviceに関するオブジェクト（TimerService，Timer，TimerHandle）の操作

×

○

○

○

×

アノテーションによるタイマの自動生成

×

−

○

○

×

（凡例）　○：利用できる。　×：利用できない。　−：利用できない（Java EE仕様）。

(4)　Timer Serviceでのトランザクション管理

Timer Serviceは，トランザクションをサポートしています。具体的には，EJBタイマの生成，EJBタイマの削除，およびタイムアウトメソッドがトランザクションに対応しています。ここでは，タイムアウトメソッドのトランザクション管理について説明します。

EJBタイマの生成については，「2.12.2　EJBタイマの生成とコールバック実行時の動作」を，EJBタイマの削除については，「2.12.4　EJBタイマの削除」を参照してください。

(a)　タイムアウトメソッドに設定できるトランザクション属性

タイムアウトメソッドには，トランザクション管理にBMTまたはCMTを選択できます。

CMTの場合に，タイムアウトメソッドに指定できるトランザクション属性を次に示します。

Required属性

RequiresNew属性

NotSupported属性

これ以外の属性が指定された場合，J2EEアプリケーションの開始に失敗します。

(b)　タイムアウトメソッドのコールバックに対するトランザクション管理

タイムアウトメソッドに，CMTでRequired属性またはRequiresNew属性を指定した場合，タイムアウトメソッドのコールバック中にトランザクションがロールバックすると，コールバックをリトライします。コールバックのリトライについては「2.12.5(2)　タイムアウトメソッドのコールバックリトライ」を参照してください。

2.12.2　EJBタイマの生成とコールバック実行時の動作

Timer Serviceによって指定した時刻に処理を実行するには，EJBタイマを生成します。また，EJBタイマによる処理の実行を停止するには，EJBタイマを削除します。EJBタイマの生成，削除のタイミングは，EJBタイマの種別や，トランザクションの管理下で処理が実行されるかどうかによって異なります。ここでは，EJBタイマの生成と削除のタイミング，およびEJBタイマの生成時と削除時のタイムアウトメソッドのコールバックの動作について説明します。

EJBタイマ生成では，EJBタイマ生成メソッド（javax.ejb.TimerServiceオブジェクトのcreateTimerメソッド）によって，EJBタイマが一つ生成されます。EJBタイマが生成されると，指定した時刻にタイムアウトが発生してタイムアウトメソッドがコールバックされます。

(1)　タイムアウト時刻のカウント

EJBタイマ生成時に，EJBタイマを呼び出してから1回目のタイムアウトメソッドを実行するまでの時間を指定しているEJBタイマの場合，時間のカウントは，EJBタイマ生成メソッドが呼ばれた時刻を基点に開始されます。EJBタイマの生成とカウントの開始について次の図に示します。

図2‒19　EJBタイマの生成とカウントの開始

(2)　EJBタイマ生成とタイムアウトメソッドのコールバック実行のタイミング

EJBタイマが生成されるタイミングおよびタイムアウトメソッドがコールバックされるタイミングは，EJBタイマ生成がトランザクションの管理下で行われるかどうかによって異なります。

EJBタイマ生成がトランザクションの管理下で行われる場合

EJBタイマは，トランザクションがコミットした時に生成されます。

タイムアウトメソッドのコールバックが実行されるタイミングは，トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合と，トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合とで異なります。なお，トランザクションがロールバックされた場合は，EJBタイマの生成は取り消されます。

トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合

指定した時刻どおりにタイムアウトメソッドがコールバックされます。EJBタイマ生成とコールバックの実行について次の図に示します。

図2‒20　EJBタイマ生成とコールバックの実行（トランザクションがコミットしたあとにタイムアウト時刻となるEJBタイマの場合）

この図では，EJBタイマ生成メソッドが呼ばれた時点から，タイムアウト時刻までのカウントが開始され，指定した時刻どおりにタイムアウトメソッドがコールバックされます。EJBタイマが生成されるのは，トランザクションコミット時です。

トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合

トランザクションがコミットした直後にタイムアウトメソッドがコールバックされます。EJBタイマ生成とコールバックの実行について次の図に示します。

図2‒21　EJBタイマ生成とコールバックの実行（トランザクションがコミットする前にタイムアウト時刻となるEJBタイマの場合）

この図では，EJBタイマ生成メソッドが呼ばれた時点から，タイムアウト時刻までのカウントが開始され，トランザクションコミットの前にタイムアウト時刻になります。トランザクションコミット時までEJBタイマは生成されないため，タイムアウト時刻になってもタイムアウトメソッドはコールバックされません。トランザクションがコミットした直後にコールバックされます。

EJBタイマ生成がトランザクションの管理下で行われない場合

EJBタイマはEJBタイマ生成メソッドが呼ばれた直後に生成されます。

トランザクションの管理下でない場合のEJBタイマ生成について次の図に示します。

図2‒22　EJBタイマ生成とコールバックの実行（トランザクションの管理下でない場合）

この図では，EJBタイマ生成メソッドが呼ばれた直後にEJBタイマが生成されます。そのあと，指定した時刻どおりにタイムアウトメソッドがコールバックされます。

2.12.3　EJBタイマの自動生成

EJBタイマを自動で生成する方法について説明します。EJBタイマの自動生成には次の方法があります。

@Scheduleアノテーションを指定する方式

EJBタイマを生成するEnterprise Beanに@Scheduleアノテーションを指定する方法です。EJB 3.1以降で使用できます。

サーブレット方式

サーブレット内で，EJBタイマの自動生成処理を実装する方法です。

Managementイベント方式

Managementイベントを使用してEJBタイマを自動生成する方法です。J2EEサーバの起動時に出力されるメッセージを契機に発生するManagementイベントとして，EJBタイマの自動生成を設定します。

EJBタイマを生成するEnterprise Beanを呼び出すEJBクライアントプログラムを作成している場合は，J2EEアプリケーションの修正は不要です。

@Scheduleアノテーションを指定する方式およびサーブレット方式では，アプリケーション開始時にEJBタイマを自動生成できます。アプリケーションの自動起動を有効にしておくことによって，J2EEサーバ起動時に自動生成することもできます。Managementイベント方式では，J2EEサーバ起動時にEJBタイマを自動生成できます。

(1)　J2EEサーバ起動時のEJBタイマの自動生成（@Scheduleアノテーションを指定する方式）

EJB 3.1のStateless Session BeanおよびSingleton Session Beanの場合に使用できる方式です。アプリケーション開始時に，EJBコンテナがSession Beanのクラスに指定された@Scheduleアノテーションの定義に基づいて，自動的にタイマを生成します。

タイマは，タイマによる処理を実行するBeanクラスまたはその親クラスのメソッドに，@Scheduleアノテーションを指定することで生成できます。複数のタイマを起動する場合は@Schedulesアノテーションを指定します。

(2)　J2EEサーバ起動時のEJBタイマの自動生成（サーブレット方式）

EJBタイマの自動生成処理をサーブレットで実装する場合の，EJBタイマ自動生成の流れと設定について説明します。

(a)　EJBタイマの自動生成の流れ

サーブレット方式では，次のような流れでEJBタイマが自動生成されます。

図2‒23　EJBタイマの自動生成の流れ（サーブレット方式）

J2EEサーバを再起動する。

J2EEアプリケーションが自動で開始する。

J2EEサーバ停止時に開始状態だったJ2EEアプリケーションが自動で開始されます（アプリケーションの自動起動を有効にしておく必要があります）。

initメッドが実行される。

J2EEアプリケーションが開始するとサーブレットがロードされ，initメッドが実行されます。initメソッドでは，Enterprise Beanを生成してビジネスメソッドを呼び出します。

EJBタイマが生成される。

Enterprise Beanのビジネスメソッドで，Timer ServiceオブジェクトからEJBタイマが生成されます。

(b)　EJBタイマを自動生成するための設定

サーブレットでEJBタイマを自動生成するには，次の設定をします。

Enterprise BeanにEJBタイマを生成するビジネスメソッドを作成する。

サーブレットを作成する。

initメソッドで，手順1.で作成したビジネスメソッドを呼び出すようにします。

J2EEアプリケーションの開始時に，手順2.で作成したサーブレットをロードさせる。

DD（web.xml）で，手順2.で用意したサーブレットの<load-on-startup>タグの値を0以上に設定します。

J2EEサーバ起動時に，アプリケーションの自動起動を有効にする。

(3)　J2EEサーバ起動時のEJBタイマの自動生成（Managementイベント方式）

EJBタイマの自動生成処理をManagementイベントとして設定する場合の，EJBタイマ自動生成の流れと設定について説明します。

(a)　EJBタイマの自動生成の流れ

Managementイベント方式では，次のような流れでEJBタイマが自動生成されます。

図2‒24　EJBタイマの自動生成の流れ（Managementイベント方式）

J2EEサーバを再起動する。

メッセージが出力される。

J2EEサーバの起動が完了するとメッセージKDJE30028-Iが出力されます。このメッセージが出力されることで，Managementイベントが発生します。

Managementアクションが実行される。

Managementイベントを受けて，Managementアクションが実行されます。Managementアクションでは，バッチファイルが実行されます。

バッチファイルが実行される。

バッチファイルで，EJBクライアントアプリケーションが実行されます。

EJBクライアントアプリケーションでビジネスメソッドが呼ばれる。

EJBクライアントアプリケーションで，Enterprise Beanを生成してビジネスメソッドを呼び出します。

EJBタイマが生成される。

Enterprise Beanのビジネスメソッドで，Timer ServiceオブジェクトからEJBタイマが生成されます。

(b)　EJBタイマを自動生成するための設定

Managementイベントを使用してEJBタイマを自動生成するには，次の設定をします。

Enterprise BeanにEJBタイマを生成するビジネスメソッドを作成する。

EJBクライアントアプリケーションを作成する。

手順1.で作成したビジネスメソッドを呼び出すようにします。

手順2.で作成したEJBクライアントアプリケーションを実行する環境，およびバッチファイルを作成します。

Managementイベントの自動実行を設定する。

Managementイベントを有効にします。J2EEサーバ開始完了時に出力されるKDJE30028-IをManagementイベントに設定し，このManagementイベントに対するManagementアクションとして，手順3.で準備したバッチファイルを設定します。

Managementイベントの詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「9.　Managementイベントの通知とManagementアクションによる処理の自動実行」を参照してください。

2.12.4　EJBタイマの削除

EJBタイマを削除するには，EJBタイマキャンセルを行います。

なお，single-eventタイマの場合は，タイムアウトメソッドのコールバック完了時にEJBタイマが削除されます。intervalタイマの場合，EJBタイマキャンセルが行われるまでEJBタイマは削除されません。

EJBタイマキャンセルでは，EJBタイマキャンセルメソッド（javax.ejb.Timerオブジェクトのcancelメソッド）によって，EJBタイマが一つ削除されます。EJBタイマが削除されると，それ以降のコールバックは実行されません。EJBタイマキャンセルによってEJBタイマが削除されるタイミングは，EJBタイマキャンセルがトランザクションの管理下で行われるかどうかによって異なります。

EJBタイマキャンセルがトランザクションの管理下で行われる場合

EJBタイマは，トランザクションのコミット時に削除されます。そのため，EJBタイマキャンセルメソッドが呼ばれてから，トランザクションがコミットするまでの間にタイムアウト時刻になることがあります。

トランザクションがロールバックされた場合は，EJBタイマキャンセルは取り消されます。

EJBタイマキャンセルがトランザクションの管理下で行われない場合

EJBタイマは，EJBタイマキャンセルメソッドが呼ばれた直後に削除されます。

参考

J2EEアプリケーションの停止時には，停止対象のJ2EEアプリケーションのEJBタイマはすべて削除されます。J2EEサーバの停止または異常終了時には，J2EEサーバ上のEJBタイマはすべて削除されます。

2.12.5　Timer Serviceの運用機能

Timer Serviceの運用で使用する機能について説明します。運用機能には次の二つがあります。

タイムアウトメソッドのコールバックスレッド数制御機能

タイムアウトメソッドのコールバックリトライ機能

これらの機能は，J2EEサーバのプロパティをカスタマイズして設定します。設定するプロパティについては，「2.12.9　実行環境での設定」を参照してください。

(1)　タイムアウトメソッドのコールバックスレッド数制御機能

タイムアウトメソッドのコールバックを処理するスレッドを，J2EEサーバ全体で同時に幾つ実行するかを設定します。これをコールバック最大スレッド数といいます。

複数のEJBタイマが同時にタイムアウトした場合，タイムアウトメソッドのコールバックの最大スレッド数の設定によって，次のような動作になります。

コールバック最大スレッド数：1（デフォルト）の場合

コールバック処理は順次行われます。そのため，EJBタイマに設定した時刻よりも遅れてコールバック処理が開始されることがあります。

コールバック最大スレッド数：2以上の場合

設定した数だけ並行してコールバック処理が実行されます。最大スレッド数を増加させた場合，その分だけリソースを消費するため，並行に実行させたいスレッド数を適切に設定してください。

コールバック最大スレッド数の設定とコールバック処理の関係について次の図に示します。

図2‒25　コールバック最大スレッド数の設定とコールバック処理の関係

この図の場合，EJBタイマ1のタイムアウトの1分後に，EJBタイマ2のタイムアウトになる設定にしています。コールバック最大スレッド数を1に設定した場合は，EJBタイマ1のコールバック処理が終了したあと，EJBタイマ2のコールバック処理が開始されます。コールバック最大スレッド数を2に設定した場合は，二つのコールバックを並行して処理できるため，設定どおりにEJBタイマ1の1分後にEJBタイマ2のコールバック処理が開始されます。

注意事項

コールバックのスレッド数に余裕がある場合でもEnterprise Beanのインスタンスが不足していると，インスタンスが解放されるのを待ってコールバック処理が行われます。そのため，コールバックするインスタンス数を考慮してEnterprise Beanインスタンスプールを設定してください。

(2)　タイムアウトメソッドのコールバックリトライ

タイムアウトメソッドのコールバックに失敗した場合は，コールバックをリトライします。

コールバックが失敗する要因として次のケースが考えられます。

タイムアウトによるコールバック時に，非検査例外（java.lang.RuntimeException，java.lang.Errorおよびそれらのサブクラス）がスローされた場合

タイムアウトメソッドがCMTのRequired属性またはRequiresNew属性で，そのトランザクションがロールバックした場合

コールバックのリトライを行うには，次の二つを設定します。

リトライ回数

リトライする回数を設定します。0を設定した場合は，リトライしません。また，リトライ実行回数が設定したリトライ回数に達すると，そのタイムアウトでのリトライは行いません。

リトライの実行間隔

コールバックが失敗してから，リトライのコールバックを行うまでの時間を設定します。

2.12.6　EJBタイマとコールバックの動作

次の場合のEJBタイマの動作およびコールバックの動作について説明します。

EJBタイマに過去の時刻が指定された場合

一つのEnterprise Beanのクラスで複数のEJBタイマを設定している場合

タイムアウト時に，前回のコールバックが終了していない場合

複数スレッドからEJBタイマキャンセルが呼ばれた場合

コールバック実行中にEJBタイマキャンセルが呼ばれた場合

コールバック時に，EJBタイマキャンセルを行った未決着トランザクションがある場合

(1)　EJBタイマに過去の時刻が指定された場合

タイマの種類によって動作が異なります。

(a)　single-eventタイマまたはintervalタイマの場合

EJBタイマに過去の時刻が指定された場合，single-eventタイマのときはEJBタイマの生成直後に1回タイムアウトメソッドをコールバックします。intervalタイマの場合は，EJBタイマ生成後の時刻に発生するタイムアウト時にタイムアウトメソッドをコールバックします。EJBタイマに過去の時刻が指定された場合の動作を次の図に示します。

図2‒26　EJBタイマに過去の時刻が指定された場合の動作

single-eventタイマの場合

2：00にタイムアウトが発生するsingle-eventタイマが，すでにタイムアウトの時刻を過ぎた4：15に生成された場合，生成直後に1回タイムアウトメソッドをコールバックします。

intervalタイマの場合

2：00から2時間間隔でタイムアウトが発生するintervalタイマが，すでにタイムアウトの時刻を過ぎた4：15に生成された場合，それ以降の時刻に発生するタイムアウト時（1回目は6：00）にタイムアウトメソッドをコールバックします。

(b)　calendar-basedタイマの場合

カレンダー形式で過去の日時を指定した場合，または日時として不正な値（2/31など）を指定した場合などの動作を次に示します。

APIで生成するタイマに過去の日時を指定した場合

アプリケーションは開始しますが，タイマは生成されないで，KDJE43206-Wメッセージが出力されます。

アノテーションで生成するタイマに過去の日時を指定した場合

アプリケーションは開始しますが，タイマは生成されないで，KDJE43220-Wメッセージが出力されます。

タイマに日時として不正な値（2/31など）を指定した場合

アプリケーションは開始しますが，タイマは生成されません。

期限が過ぎる直前のTimerオブジェクトでgetNextTimeoutメソッドを呼び出した場合

getNextTimeoutメソッドを呼び出したときにKDJE43211-Wが出力されます。

(2)　一つのEnterprise Beanのクラスで複数のEJBタイマを設定している場合

一つのEnterprise Beanクラスに対して，複数のEJBタイマがある場合に，それらの複数のEJBタイマのコールバックが重なったときは，コールバック処理が並列に行われます。ただし，並列に処理できるコールバックスレッドやEnterprise Beanインスタンスがある場合に限ります。このようなコールバックスレッドやインスタンスがない場合は，スレッドやインスタンスが解放されるまで待ちます。

(3)　タイムアウト時に，前回のコールバックが終了していない場合

一つのEJBタイマで同時に実行できるコールバックは一つだけです。タイムアウトメソッドの処理は，処理内容によっては時間が長く掛かることがあります。そのため，intervalタイマの場合，コールバック処理の実行中に次のタイムアウトの時刻を過ぎてしまい，一つのコールバックが完了するまでに複数のタイムアウト時刻を経過することがあります。この場合，タイムアウトの時刻どおりに実行されなかったコールバック処理は行わないで，前回のコールバックが終了した時刻よりあとに発生するタイムアウトのコールバック処理を行います。

コールバック時に，前回のコールバックが終了していない場合の動作を次の図に示します。

図2‒27　コールバック時に前回のコールバックが終了していない場合の動作

この図の場合，1分間隔でタイムアウトが発生してコールバック処理を実行する設定にしています。1回目のコールバックの処理中に，2回目と3回目のタイムアウトの時刻を過ぎてしまった場合，1回目のコールバック処理が終了したあとの，次のタイムアウト時刻（予定では4回目のタイムアウトの時刻）に2回目のコールバック処理を行います。タイムアウト時刻を過ぎてしまった2回分のコールバック処理は行われません。

(4)　複数スレッドからEJBタイマキャンセルが呼ばれた場合

同時に複数のスレッドから，同一EJBタイマのEJBタイマキャンセルメソッドが呼ばれた場合，キャンセルの処理は順次行われます。

ただし，トランザクション管理下でEJBタイマキャンセルが行われた場合，トランザクションが決着するまでは，EJBタイマが削除されるかどうかを確定できません。そのため，そのほかのスレッドが同じEJBタイマのキャンセルを行うと，排他待ちとなります。

同時に複数のスレッドから，同一のEJBタイマのキャンセルが呼ばれた場合の動作を次の図に示します。

図2‒28　複数スレッドからのEJBタイマのキャンセル

(5)　コールバック実行中にEJBタイマキャンセルが呼ばれた場合

EJBタイマのキャンセル時に，タイムアウトメソッドのコールバックが実行中の場合，次のような動作になります。

EJBタイマキャンセルメソッドの呼び出しは正常終了します。

タイムアウトメソッドのコールバック処理は継続して実行されますが，コールバック完了後に次の動作をします。

タイムアウトメソッドがCMTのトランザクションを使用している場合，そのトランザクションはロールバックされます。

タイムアウトメソッドがCMTのトランザクションを使用していない場合，コールバック中に行われたトランザクションの決着には関与しません。

通常ではコールバックをリトライする次のケースで終了した場合でも，リトライしません。

CMTのトランザクションがロールバックされた場合

非検査例外がスローされた場合

コールバック完了時に，メッセージログにメッセージが出力されます。

タイムアウトメソッドがCMTのトランザクションを使用している場合，KDJE43161-Wが出力されます。

タイムアウトメソッドがCMTのトランザクションを使用していない場合は，KDJE43160-Wが出力されます。

CMTのトランザクションを使用するタイムアウトメソッドのコールバック実行中に，別のトランザクションからEJBタイマキャンセルが行われた場合と，CMTのトランザクションを使用するタイムアウトメソッドの中でEJBタイマキャンセルが行われた場合では動作が異なります。

CMTのトランザクションを使用するタイムアウトメソッドのコールバック実行中に，別のトランザクションからEJBタイマキャンセルが行われた場合の動作を次の図に示します。

図2‒29　コールバック実行中のキャンセル

CMTトランザクションを使用するタイムアウトメソッドの中でEJBタイマキャンセルが行われた場合の動作を次の図に示します。

図2‒30　タイムアウトメソッドでのEJBタイマキャンセル

この図の場合，実際にEJBタイマがキャンセルされるのは，タイムアウトメソッド完了後です。このため，トランザクションがコミットした場合，EJBタイマはキャンセルされます。トランザクションがロールバックした場合，EJBタイマは存続します。

(6)　コールバック時に，EJBタイマキャンセルを行った未決着トランザクションがある場合

EJBタイマキャンセルを行った未決着のトランザクションAが存在する場合，タイムアウトメソッドのコールバックの処理は，コールバック完了時からトランザクションAが決着するまで排他待ちとなります。したがって，タイムアウトメソッドがCMTのトランザクションの管理下にある場合，そのトランザクションの決着は，トランザクションAが決着するまで待ちます。この場合の流れを次の図に示します。

図2‒31　キャンセルを行った未決着トランザクションがある場合のコールバックの動作

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

Timer Serviceを使用する場合のアプリケーションの実装内容として，APIを使用した実装と，アノテーションを使用した実装について説明します。また，カレンダー形式でスケジュールを指定する場合の指定方法についても説明します。

(1)　APIを使用した実装内容

次の内容を実装します。

タイムアウトメソッドの指定

次に示すどちらかの方法で，コールバックするタイムアウトメソッドを指定します。

タイムアウトメソッドとして利用するメソッドに，Timeoutアノテーションを指定します

Enterprise BeanにTimedObjectインタフェースを実装します。この場合，TimedObjectインタフェースで定義されているejbTimeoutメソッドがタイムアウトメソッドとなります。

javax.ejb.TimerServiceオブジェクトの取得

DIやEJBContextインタフェースのgetTimerServiceメソッドや，JNDIのlookupメソッドなどを使用して，TimerServiceオブジェクトを取得します。

EJBタイマ（Timer）の生成

TimerServiceオブジェクトの次のどれかのメソッドを呼び出し，Timerを生成するコードを実装します。

createTimer()

createSingleActionTimer()

createIntervalTimer()

createCalenderTimer()

EJBタイマ（Timer）のキャンセル

キャンセルする処理が必要な場合は，Timerをキャンセルするコードを実装します。Timerは，javax.ejb.TimerServiceやjavax.ejb.TimerHandleから取得します。

これらの処理を実装した例と，実装時の注意事項を示します。

(a)　DIを使用した場合の実装例（タイムアウトメソッドをTimeoutアノテーションで指定）

アノテーションを使用した場合の実装例を示します。この例では，Timeoutアノテーション（@Timeout）でタイムアウトメソッド（myTimeout）を指定しています。

@Stateless public class TimerSessionBean{
  @Resource TimerService timerService;

  public void createMyTimer(long intervalDuration){
    Timer timer = timerService.createTimer
                           (intervalDuration, "MyTimer");
  }

  @Timeout public void myTimeout(Timer timer) {
    System.out.println("TimerSessionBean: myTimeout ");
  }

  public void cancelTimers(){
    Collection<Timer> timers = timerService.getTimers();
    for(Timer timer: timers) {
      timer.cancel();
    }
  }
}

(b)　EJBContextを利用した場合の実装例（TimedObjectインタフェースを実装）

EJBContextのサブクラスであるSessionContextを利用して，TimerServiceオブジェクトを取得する例を示します。この例では，TimedObjectインタフェースをインプリメントして実装しています。

public class TimerSessionBean implements SessionBean, TimedObject{
  private SessionContext context;

  public void createMyTimer(long intervalDuration) {
    System.out.println("TimerSessionBean: start createTimer ");
    TimerService timerService = context.getTimerService();
    Timer timer = timerService.createTimer
                             (intervalDuration, "MyTimer");
  }

  public void ejbTimeout(Timer timer) {
    System.out.println("TimerSessionBean: ejbTimeout ");
  }

  public void setSessionContext(SessionContext sc) {
    context = sc;
  }
}

(c)　lookupを利用した場合の実装例（TimedObjectインタフェースを実装）

JNDIを使用して，TimerServiceオブジェクトを取得する例を示します。この例では，TimedObjectインタフェースをインプリメントして実装しています。

public class TimerSessionBean implements SessionBean, TimedObject{
  private SessionContext context;

  public void createMyTimer(long intervalDuration) {
    System.out.println("TimerSessionBean: start createTimer ");
    InitialContext context = new InitialContext();
    TimerService timerService =
      (TimerService)context.lookup("java:comp/TimerService");
    Timer timer = timerService.createTimer
                             (intervalDuration, "MyTimer");
  }

  public void ejbTimeout(Timer timer){
    System.out.println("TimerSessionBean: ejbTimeout ");
  }
}

(2)　アノテーションを利用した実装内容

@Scheduleアノテーションを使用して，タイマを自動生成できます。

例を示します。

(a)　@Scheduleアノテーションの指定例

@Scheduleアノテーションを指定する例を示します。この例では，一つのタイマを生成します。

// @Scheduleアノテーションで毎月1日1時に
// generateMonthlyAccountStatementsメソッドを実行する設定の例です。
@Schedule(hour="1", dayOfMonth="1",info="AccountStatementTimer")
public void generateMonthlyAccountStatements() { ... }

@Scheduleアノテーションのinfo属性には，任意の文字列を指定します。指定された文字列は，関連するTimerオブジェクトのgetInfoメソッドで取得できます。

(b)　@Schedulesアノテーションの指定例

@Schedulesアノテーションを指定する例を示します。この例では，複数のタイマを生成します。

// @Schedulesアノテーションで月曜日〜木曜日の12時と
// 金曜日の11時にsendLunchNotificationメソッドを実行する設定の例です。
@Schedules (
     {  @Schedule(hour="12", dayOfWeek="Mon-Thu"),
        @Schedule(hour="11", dayOfWeek="Fri")
      }
)
public void sendLunchNotification() { ... }

@Schedulesアノテーションを使用することで，複数のタイマが一つのコールバックメソッドから呼び出されます。

(3)　カレンダー形式でスケジュールを指定する場合の指定方法

カレンダー形式のコーディングでは次のように値を使用します。

なお，指定できる値などは，標準仕様に準拠しています。

一つの値の指定

秒（second）や月（month）などで，一つの値を指定する場合は，次のように指定します。

例

second = "10"

month = "Sep"

ワイルドカード

次のようにワイルドカードを指定できます。

例

second = "*"

dayOfWeek = "*"

複数指定

「,」を使用することで，複数の値を指定できます。

例

second = "10,20,30"

dayOfWeek = "Mon,Wed,Fri"

minute = "0-10,30,40"

範囲指定

「-」を使用することで，一定期間の値を指定できます。

例

second="1-10"

dayOfWeek = "Sat-Mon"

また，次に示す例は，ある月の27日から次の月の3日までを表します。最初の「-」は，開始時と終了時の間隔を表します。

例

dayOfMonth = "27-3"

この例では日にちに関する指定ですが，ある時間の秒（second），分（minutes），または時間（Hours）の場合も同じように指定できます。

増分指定

「/」を使用することで，増分を指定できます。増分として指定した値が増えるごとに，処理が実行されます。

次に示す例は，5分ごとに実行することを表します。

例

minute = "*/5"

この例は，「minute = "0,5,10,15,20,25,30,35,40,45,50,55"」と指定する場合と同じです。

また，次に示す例は，毎分30秒から10秒ごとに実行することを表します。

例

second = "30/10"

この例は，「second = "30,40,50, ..."」と指定する場合と同じです。

注意事項

createCalendarTimerメソッドの引数が不正な場合，IllegalArgumentException例外がスローされ，KDJE43209-Eが出力されます。

2.12.8　Timer Service実装時の注意事項

Timer Serviceを実装するときの注意事項を示します。

(1)　createTimerメソッドの引数infoの指定

TimerオブジェクトのgetInfoメソッドは，TimerServiceオブジェクトのcreateTimerメソッドの引数infoまたはTimerConfigオブジェクトのコンストラクタメソッドの引数infoに指定されたオブジェクト自体を戻り値とします。そのため，getInfoメソッドの戻り値がcreateTimerメソッドなどの実行時のオブジェクトと異なる状態である場合があり，トラブルが生じやすくなっています。

これを防ぐために，createTimerメソッドで引数infoに指定するオブジェクトはStringやIntegerなどの不変オブジェクトにする，または引数infoに指定したオブジェクトの状態を変更しないことを推奨します。変更した場合には，getInfoメソッドの戻り値は変更後のオブジェクトになります。

(2)　DDおよび属性ファイルでのタイムアウトメソッド指定

DDや属性ファイルで<method>タグにタイムアウトメソッドを指定する場合は，次のどちらかとしてください。

<method>タグ直下に<method-intf>タグの定義を追加しない。

<method-intf>タグの要素を空にする。

(3)　Timer Serviceオブジェクトをサポートしていない種別のBeanからTimer Serviceオブジェクトを取得しようとした場合の動作

Timer Serviceをサポートしない取得手段を次の表に示します。Timer Serviceをサポートしない種別のBeanやサーブレットからTimerServiceオブジェクトを取得しようとした場合，手段によって次のような動作をします。

表2‒35　Timer Serviceオブジェクトをサポートしていない種別のBeanからTimer Serviceオブジェクトを取得しようとした場合の動作

TimerServiceオブジェクトの取得手段

動作

EJBContext#getTimerService

IllegalStateExceptionをスローします。

JNDIのルックアップ

NamingExceptionをスローします。

DI

デプロイに失敗します。

Timer Serviceをサポートしている種別のBeanは，タイムアウトメソッドを実装しているかどうかに関係なく，TimerServiceオブジェクトを取得できます。

(4)　TimerServiceが提供するAPIの動作仕様

TimerServiceが提供するAPIを呼び出したときの動作のうち，EJB仕様書で明確に示されていない動作仕様があります。ここでは，javax.ejb.TimerServiceおよびjavax.ejb.Timerのアプリケーションサーバでの動作仕様を示します。

javax.ejb.TimerService

javax.ejb.TimerServiceのメソッドを呼び出したBeanがタイムアウトメソッドを実装している場合，およびタイムアウトメソッドを実装していないときの動作を，次の表に示します。

表2‒36　Beanからjavax.ejb.TimerServiceのAPIを利用したときの動作

タイムアウトメソッドの実装

javax.ejb.TimerServiceのメソッドの種類

createTimer，

createCalendarTimer，

createIntervalTimer，

createSingleActionTimer

getTimers

実装している場合※

EJBタイマ生成処理を実行します。

EJBタイマのコレクションを返します。

実装していない場合

IllegalStateExceptionをスローします。

空のコレクションを返します。

注※

タイムアウトメソッドを実装している場合は，EJBの仕様どおりに動作します。

javax.ejb.TimerのAPI

タイムアウトメソッドが実行している場合，および実行していない場合に，javax.ejb.Timerに対してメソッドを呼び出したときの動作を，次の表に示します。

表2‒37　javax.ejb.TimerのAPIを利用したときの動作

タイムアウトメソッドの実行

javax.ejb.Timerのメソッドの種類

cancel

getHandle，getInfo，isCalendarTimer，getSchedule

getNextTimeout

getTimeRemaining

isPersistent

実行していない場合※

「2.12.6　EJBタイマとコールバックの動作」を参照してください。

仕様どおりに動作します。

次のタイムアウトが起こる時刻を返します。

次のタイムアウトまでの時間を返します。

EJBタイマの永続性はサポートしていないため，常にfalseを返します。

実行している場合

実行中のタイムアウトの開始予定時刻として登録されていた時刻を返します。

0を返します。

注※

タイムアウトメソッドを実行していない場合は，EJBの仕様どおりに動作します。

参考

アプリケーションサーバでは，Timer Serviceのサンプルプログラムを提供しています。サンプルプログラムの概要および実行方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録L　アプリケーションサーバが提供するサンプルプログラム」を参照してください。

(5)　タイムアウトメソッド実装時の注意事項

タイムアウトメソッドは，次のどちらかの形式で実装してください。これらの形式で実装していない場合，アプリケーションの開始に失敗します。

void <メソッド名>()

void <メソッド名>(Timer timer)

タイムアウトメソッドでは，アプリケーション例外をスローしないでください。アプリケーション例外をスローする実装にした場合は，アプリケーションの開始に失敗します。

タイムアウトメソッドでは，finalまたはstaticを宣言しないでください。

2.12.9　実行環境での設定

TimerServiceを使用する場合，J2EEサーバの設定が必要です。

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

簡易構築定義ファイルでのTimerServiceの定義について次の表に示します。

表2‒38　簡易構築定義ファイルでのTimerServiceの定義

項目

指定するパラメタ

設定内容

リトライ最大回数

ejbserver.ejb.timerservice.retryCount

Timer Serviceのタイムアウトメソッドのコールバックをリトライする最大回数を指定します。

リトライ間隔

ejbserver.ejb.timerservice.retryInterval

Timer Serviceのタイムアウトメソッドのコールバックをリトライする間隔を秒単位で指定します。

タイムアウトメソッドをコールバックする最大スレッド数

ejbserver.ejb.timerservice.maxCallbackThreads

J2EEサーバ全体でのTimer Serviceのタイムアウトメソッドをコールバックする最大スレッド数を指定します。

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

2.12.10　Timer Serviceを利用する場合の注意事項

Timer Serviceを利用する場合の注意事項について説明します。

Timer Serviceを利用した場合，EJBタイマに指定した時刻と，実際にタイムアウトメソッドがコールバックされる時刻に差が生じることがあります。この場合，次の要因が考えられます。

GCの実行

EJBタイマで指定した時刻に，JavaVMでGCが実行された場合，GCの処理が優先されます。GCが終了してからタイムアウトメソッドがコールバックされるため，指定した時刻との差異が生じることがあります。

プラットフォームやハードウェア環境

Timer Serviceでは，JavaVMの時間を使用します。JavaVMの時間は，プラットフォームやハードウェア環境に依存します。コールバックもJavaVMの時間に従って実行されるため，指定した時刻との差異が生じることがあります。

J2EEサーバが稼働するマシンで，NTPクライアントソフトウェアなどによってシステム時刻が修正された場合，登録済みのEJBタイマのタイムアウト時刻は次のような動作になります。

single-eventタイマの場合

修正前のシステム時刻が継続されているものとして，タイムアウトが発生します。

intervalタイマの場合

修正後，修正前のシステム時刻が継続されているものとして1回目のタイムアウトが発生します。2回目以降は，修正後のシステム時刻に従ってタイムアウトが発生します。

calendar-basedタイマの場合，または@Scheduleアノテーションを指定する方式の場合

指定された日時に一度だけコールバックされる設定のときには，修正前のシステム時刻が継続されているものとしてタイムアウトが発生します。

定期的にコールバックされる設定のときには，修正後，修正前のシステム時刻が継続されているものとして1回目のタイムアウトが発生します。2回目以降は，修正後のシステム時刻に従ってタイムアウトが発生します。

次の図に，システム時刻を変更しない場合，システム時刻を戻した場合，およびシステム時刻を進めた場合のコールバックのタイミングの例を示します。

図2‒32　コールバックのタイミングの例

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

この節では，EJBのリモートインタフェースの呼び出しについて説明します。

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

表2‒39　この節の構成（EJBのリモートインタフェースの呼び出し）

分類

タイトル

参照先

解説

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

2.13.1

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

2.13.2

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

2.13.3

設定

cosminexus.xmlでの定義

2.13.4

実行環境での設定

2.13.5

注意事項

EJBのリモートインタフェースの呼び出しに関する注意事項

2.13.6

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

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

ここでは，EJBのリモートインタフェースでのローカル呼び出しの最適化について説明します。

EJBのリモートインタフェースに定義されるメソッドの呼び出しは，RMI-IIOPで行われますが，この呼び出しについてローカル呼び出し最適化を適用できます。

なお，EJBのローカルインタフェースに定義されるメソッドの呼び出しについては，RMI-IIOPを利用しない，通常のJavaのメソッド呼び出しとなるため，この機能は適用外となります。

リモートインタフェースでのローカル呼び出しの最適化では，ローカル呼び出しを最適化する範囲を選択できます。最適化する範囲は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「2.13.5　実行環境での設定」を参照してください。

次に，ローカル呼び出し最適化機能の範囲および動作と，J2EEサーバのプロパティ（usrconf.properties）のキーの指定値の対応を次の表に示します。

表2‒40　ローカル呼び出し最適化機能の範囲と動作

項目

ejbserver.rmi.localinvocation.scopeキー※の値

all

app

none

ローカル呼び出し最適化の範囲

同一J2EEサーバ内となります。

同一アプリケーション内となります。

範囲はありません。

スレッド構成

CallerとCalleeは常に同一スレッドとなります。

同一アプリケーション内でだけCallerとCalleeは同一スレッドとなります。

CallerとCalleeは常に別スレッドとなります。

クラスローダ構成

EJBはコンテナクラスローダ（J2EEサーバ単位）でロードされます。

EJBはアプリケーションクラスローダ（アプリケーション単位）でロードされます。

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

J2EEサーバ内で利用できます。

同一アプリケーション内で利用できます。

同一J2EEコンポーネント内で利用できます。

注※

usrconf.propertiesに指定するキーです。

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

通常，リモートインタフェースを持つEJBメソッドを呼び出すとき，引数や戻り値をコピーして値を渡しますが（pass by value），引数や戻り値を参照で返すこともできます（pass by reference）。値を参照で渡す場合は，値をコピーして渡す場合より，負荷の軽減が図れます。

ただし，値を参照で渡す場合は，引数や戻り値を直接参照するため，引数および戻り値の変更や，参照渡しをするクライアントとアプリケーションの配置には注意が必要です。

java.io.Serializableインタフェースを実装したオブジェクトを，メソッドの引数や戻り値に定義している場合，EJBのリモートインタフェースの値の参照渡しを適用することで，負荷の軽減を期待できます。オブジェクトの数やサイズが大きければより効果を期待できます。

設定方法には次の二つがあります。どちらか一つの方法で設定していれば，値の参照渡しが有効になります。

EJB単位で設定する方法

EJB単位で機能の有効/無効を，Session BeanまたはEntity Beanの属性として定義します。

J2EEサーバ単位で設定する方法

J2EEサーバ単位で機能の有効/無効を，J2EEサーバのプロパティとして，一括して定義します。

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

EJBクライアントからリモートインタフェースとして定義されたEJBメソッドが呼び出しを実施している際に通信障害が発生したときのクライアント側の動作を次のどちらかから選択できます。

コネクションを再接続して，リクエストを再送信する

コネクションの再接続も，リクエストの再送信もしない

この機能を使用するための設定は，J2EEサーバまたはEJBクライアントアプリケーションのプロパティとして設定します。

なお，EJBクライアントアプリケーションの場合は，API（java.lang.SystemクラスのsetPropertyメソッドなど）で設定することもできます。java.lang.System.setPropertyメソッドで定義する場合は，EJBクライアントアプリケーションのプロセス起動後，最初にEnterprise Beanのメソッドを呼び出す前に定義してください。

(1)　設定が有効になる通信

通信障害発生時の動作は，リモートインタフェースとして定義されたEJBメソッドの呼び出しで通信障害が起きた場合に有効になります。EJBメソッドの呼び出しとは，次の呼び出しを指します。

WebアプリケーションからのEJBの呼び出し

EJBクライアントからのEJBの呼び出し

EJBからのEJBの呼び出し

設定が有効となる通信を次の図に示します。

図2‒33　設定が有効になる通信

なお，次の場合は無効になるので注意してください。

ローカルインタフェースとして定義されたEJBメソッドの呼び出し

ローカル呼び出し最適化が有効となる範囲での，リモートインタフェースとして定義されたEJBメソッドの呼び出し

ネーミングサービスの呼び出し

(2)　推奨する設定

システムの形態によって，次のように設定することをお勧めします。

検索および参照系のシステムの場合

コネクションを再接続して，リクエストを再送信する設定にすることをお勧めします。これによって，リクエストを失敗させることなく，結果を取得できるようになります。

更新系のシステムの場合

コネクションの再接続も，リクエストの再送信もしない設定にすることをお勧めします。更新系のシステムの場合，コネクションの再接続およびリクエストの再送信ありの設定をすると，リクエストの二重送信をするおそれがあります。

2.13.4　cosminexus.xmlでの定義

EJBのリモートインタフェース呼び出し機能のうち，どのEnterprise BeanでEJBのリモートインタフェースの参照渡し機能を有効にするかの設定は，cosminexus.xmlで定義します。

定義は，cosminexus.xmlの<ejb-jar>タグ内に指定します。設定するタグは，設定対象になるEnterprise Beanの種類ごとに異なります。

cosminexus.xmlでのEJBコンテナでのタイムアウトの定義を次に示します。

指定するタグ

Session Beanの場合

<session>-<pass-by-reference>タグ

Entity Beanの場合

<entity>-<pass-by-reference>タグ

指定内容

Enterprise Bean単位でEJBのリモートインタフェースでの値の参照渡しを有効にするかどうかを指定します。

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

2.13.5　実行環境での設定

EJBのリモートインタフェース呼び出し機能のうち，次の機能の設定は，J2EEサーバで設定する必要があります。

EJBのリモートインタフェースのローカル呼び出し最適化機能の範囲

EJBのリモートインタフェースの参照渡し機能を有効にするかどうかの設定

EJBのリモートインタフェースでの通信障害発生時のEJBクライアントの動作※

注※

EJBクライアントの形態がEJBクライアントアプリケーションの場合は，EJBクライアントアプリケーションのプロパティで設定します。

また，どのEnterprise BeanでEJBのリモートインタフェースの参照渡し機能を有効にするかの設定は，J2EEアプリケーションで設定できます。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合に参照してください。

(1)　J2EEサーバの設定

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

簡易構築定義ファイルでのEJBのリモートインタフェース呼び出し機能の定義について次の表に示します。

表2‒41　簡易構築定義ファイルでのEJBのリモートインタフェース呼び出し機能の定義

項目

指定するパラメタ

設定内容

ローカル呼び出し最適化機能の範囲

ejbserver.rmi.localinvocation.scope

EJBのリモートインタフェースでのローカル呼び出しの最適化の範囲を指定します。

リモートインタフェースの参照渡し機能

ejbserver.rmi.passbyreference※

リモートインタフェースの参照渡し機能を有効にするかどうかを指定します。

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

ejbserver.container.rebindpolicy

指定先のJ2EEサーバがほかのJ2EEサーバのクライアントである場合に，EJBクライアント側でのコネクションの再接続動作とリクエストの再送動作を指定します。

注※

J2EEアプリケーションでは，Enterprise Beanごとに参照渡し機能を有効にするかどうかを設定できます。J2EEサーバまたはEnterprise Beanのどちらかで有効を指定していれば，参照渡し機能は有効になります。

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

(2)　EJBクライアントアプリケーションの設定

EJBクライアントの形態がEJBクライアントアプリケーションの場合は，EJBのリモートインタフェースでの通信障害発生時のEJBクライアントの動作をEJBクライアントアプリケーションのプロパティで設定します。

指定するキー

ejbserver.container.rebindpolicyキー

設定内容

EJBクライアント側でのコネクションの再接続動作とリクエストの再送動作を指定します。

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

Enterprise BeanごとのEJBのリモートインタフェースの参照渡し機能を有効にするかどうかの設定は，実行環境で設定することもできます。J2EEサーバにインポートしたJ2EEアプリケーションに設定します。cosminexus.xmlを含まないJ2EEアプリケーションのプロパティを設定または変更する場合にだけ実行してください。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リファレンスマッピングの定義には，次の属性ファイルを使用します。

表2‒42　Enterprise Beanのトランザクションの管理方法の定義に使用する属性ファイル

設定対象

属性ファイル

Session Bean

Session Bean属性ファイル

Entity Bean

Entity Bean属性ファイル

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

2.13.6　EJBのリモートインタフェースの呼び出しに関する注意事項

EJBのリモートインタフェースの呼び出しに関する注意事項について説明します。

(1)　ローカル呼び出しの最適化適用時の注意事項

同一アプリケーション内での処理で，EJBのリモートインタフェースのローカル呼び出し最適化を適用する場合（usrconf.propertiesに「ejbserver.rmi.localinvocation.scope=app」を指定する場合），次のプロバイダURLには同じホストを指定してください。

J2EEサーバで使用するプロバイダURLのホスト

J2EEアプリケーションから使用するプロバイダURLホスト

ホストの指定が異なると，ローカル呼び出しの最適化が行われません。

また，同じホストを指定している場合でも，ホスト名に指定した文字列が異なると，ローカル呼び出しの最適化は行われません。例えば，大文字と小文字の違いや，IPアドレス指定とホスト名指定の違いなどがあると，ローカル呼び出しの最適化は行われません。

J2EEサーバが使用するプロバイダURLは次の優先順位で決定されます。

ejbserver.naming.startupMode=inprocessの場合

vbroker.se.iiop_tp.hostプロパティの値

InetAddress.getLocalHost().getHostName()の値

ejbserver.naming.startupMode=automaticの場合

InetAddress.getLocalHost().getHostName()の値

ejbserver.naming.startupMode=manualの場合

ejbserver.naming.hostプロパティの値

InetAddress.getLocalHost().getHostName()の値

J2EEアプリケーションから使用するプロバイダURLは次の優先順位で決定されます。

ネーミング切り替え機能使用時にlookupに渡す引数部分

InitialContext生成時に指定するjava.naming.provider.urlプロパティ

J2EEサーバが使用するプロバイダURL

(2)　EJBのリモートインタフェースの通信障害発生時の動作設定時の注意事項

システムプロパティのejbserver.container.rebindpolicyキーで"NO_RECONNECT"（再接続なし／再送なし）を選択した場合，通信障害によってコネクションが切断されると，再接続が抑止されているため該当するオブジェクトリファレンスは再利用できなくなります。このため，EJBクライアントでは，次回Enterprise Beanのメソッド呼び出しをする場合には，EJBホームオブジェクトのときはlookupメソッド，EJBオブジェクトのときはcreateメソッドを再実行したあと，メソッド呼び出しを実行してください。なお，Enterprise Beanのメソッド呼び出し中にコネクションが切断された場合，メソッドは次のどちらかの例外を送出します。

java.rmi.RemoteException

detailフィールドがorg.omg.CORBA.REBINDのインスタンス

java.rmi.MarshalException

detailフィールドがorg.omg.CORBA.COMM_FAILUREのインスタンス

これらの例外をキャッチするクライアントのコーディング例を次に示します。

try {
     //JNDI.lookup()
     //EJBHome.create()
     //EJBObject.invoke()
    } catch (java.rmi.MarshalException e) {
      if (e.detail instanceof org.omg.CORBA.COMM_FAILURE) {
        //通信障害に対応する処理
      }
    } catch (java.rmi.RemoteException e) {
      if (e.detail instanceof org.omg.CORBA.REBIND) {
        //通信障害に対応する処理
      }
    }

(3)　複数スレッド実行時の注意事項

リモートインタフェースとして定義されたEJBメソッドを（一つのクライアントから）複数スレッドで呼び出す場合，サーバへのコネクションは一つだけで，複数スレッドでそのコネクションを共有します。一つのEJBの呼び出しでタイムアウトが発生してコネクションがクローズした場合，ほかのEJBの呼び出しは通信障害となります。クライアントの動作として「コネクションを再接続して，リクエストを再送信する」を選択している場合，再度EJBの呼び出しが実行されます。

タイムアウト発生時のコネクションクローズを抑止したい場合，EJBの呼び出し元（クライアント側）のusrconf.properties（J2EEサーバ用ユーザプロパティファイル，バッチサーバ用ユーザプロパティファイル，またはJavaアプリケーション用ユーザプロパティファイル）には，次の内容を設定してください。詳細については，マニュアル「TPBroker 運用ガイド」を参照してください。

内容

vbroker.ce.iiop.ccm.htc.readerPerConnection=true
vbroker.ce.iiop.ccm.htc.threadStarter=true

上記の内容を設定した場合，起動するスレッドが追加されます。スレッド数の見積もりについては，マニュアル「アプリケーションサーバ システム設計ガイド」の「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照してください。

(4)　ネーミング管理機能でのキャッシング機能を有効にしている場合の注意事項

ネーミング管理機能でのキャッシング機能を有効にしている場合，コネクション切断後にlookupメソッドを実行すると，キャッシュ上の無効なオブジェクトリファレンスが取得されます。この場合，取得したオブジェクトリファレンスを使用してjavax.rmi.PortableRemoteObject.narrowメソッドやcreateメソッドを実行したときに，CORBA例外（org.omg.CORBA.OBJECT_NOT_EXISTなど）が発生することがあります。

コネクション切断後の無効なキャッシュはクリアしてください。手順については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.8.2　ネーミングで使用したキャッシュのクリア」を参照してください。

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

この節では，EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション）について説明します。

J2EEサーバ経由でTPBrokerのオプションを定義することで，EJBコンテナの通信ポート，およびIPアドレスを固定して運用できます。使用するポートを最小限にしてシステムのセキュリティを高める場合は，ポート固定の設定を強く推奨します。TPBrokerのオプションの詳細については，マニュアル「TPBroker ユーザーズガイド」を参照してください。

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

表2‒43　この節の構成（EJBコンテナの通信ポートとIPアドレスの固定（TPBrokerのオプション））

分類

タイトル

参照先

解説

通信ポートの固定

2.14.1

IPアドレスの固定

2.14.2

設定

実行環境での設定

2.14.3

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

2.14.1　通信ポートの固定

EJBコンテナの通信ポートは，デフォルトではTPBrokerによってランダムな値が割り当てられています。

これに対して，TPBrokerのオプションとして任意の値を指定して，J2EEサーバ単位で通信ポートを固定できます。ポート番号については，ほかのプログラムなどと重複しないようにしてください。

2.14.2　IPアドレスの固定

EJBコンテナのIPアドレスは，デフォルトではTPBrokerによって実行環境のマシンのシステムから取得して割り当てられています。

これに対して，TPBrokerのオプションとして任意の値を指定して，J2EEサーバ単位でIPアドレスを固定できます。

2.14.3　実行環境での設定

EJBコンテナの通信ポートとIPアドレスを固定する場合，J2EEサーバの設定が必要です。

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

EJBコンテナの通信ポートとIPアドレスを固定するための簡易構築定義ファイルでの定義について次の表に示します。

表2‒44　簡易構築定義ファイルでのEJBコンテナの通信ポートとIPアドレスを固定するための定義

項目

指定するパラメタ

設定内容

EJBコンテナの通信ポート

vbroker.se.iiop_tp.scm.iiop_tp.listener.port

EJBコンテナの通信ポートを指定します。

IPアドレスまたはホスト名を固定するかどうか

vbroker.se.iiop_tp.host

EJBコンテナの使用するIPアドレスまたはホスト名を固定するかどうかを指定します。

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

2.15　インターセプタの使用

この節では，インターセプタの使用について説明します。

アプリケーションサーバでは，DD，属性ファイル，またはアノテーション（デフォルトインターセプタを除く）で設定できます。

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

表2‒45　この節の構成（インターセプタの使用）

分類

タイトル

参照先

解説

インターセプタの使用の概要

2.15.1

上位レベルインターセプタの呼び出し抑止

2.15.3

インターセプタの実行順序

2.15.4

実装

アノテーションまたはDDでの定義

2.15.2

設定

実行環境での設定

2.15.5

注意事項

インターセプタに関する注意事項

2.15.6

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

2.15.1　インターセプタの使用の概要

アプリケーションサーバでは，次のインターセプタを使用できます。

デフォルトインターセプタ

EJB-JARに含まれるすべてのコンポーネントに適用されるインターセプタです。クラスレベルインターセプタ，およびメソッドレベルインターセプタの上位レベルのインターセプタとなります。DDまたは属性ファイルを使用して設定します。

クラスレベルインターセプタ

指定したクラスに適用されるインターセプタです。メソッドレベルインターセプタの上位レベルのインターセプタとなります。アノテーション，DD，または属性ファイルを使用して設定します。

メソッドレベルインターセプタ

指定したビジネスメソッドに適用されるインターセプタです。アノテーション，DD，または属性ファイルを使用して設定します。

2.15.2　アノテーションまたはDDでの定義

インターセプタは，アノテーションで指定するか，DDまたは属性ファイルを使用してEJB-JARの属性として設定します。

(1)　デフォルトインターセプタの定義

デフォルトインターセプタは，EJB-JARに含まれるすべてのコンポーネントに適用されるインターセプタです。ここでは，DDを使用したデフォルトインターセプタを設定する方法，および実行環境でEJB-JAR属性ファイルを使用してデフォルトインターセプタを設定する方法について説明します。

DDで，<ejb-jar>タグ下の<interceptor-binding>タグを記述することで，デフォルトインターセプタの情報を指定できます。

<interceptor-binding>タグ下に指定する要素を次の表に示します。

表2‒46　DDを使用する場合に<interceptor-binding>タグ下に指定する要素（デフォルトインターセプタ）

タグ名

必須／任意

指定内容

<description>

任意

任意の情報を指定します。

<ejb-name>

必須

"*"（ワイルドカード）を指定します。

<interceptor-class>

必須

要素にインターセプタクラスのクラス名を指定します。

これ以外のタグで指定した要素の値は，反映されません。

デフォルトインターセプタを使用する場合のDDの記述例を次に示します。

<ejb-jar>
　…(略)…
  <assembly-descriptor>
   <interceptor-binding>
     <description xml:lang="en">Default Interceptor</description>
     <ejb-name>*</ejb-name>
     <interceptor-class>test.ejb30.MyDefaultIC</interceptor-class>
     <interceptor-class>test.ejb30.MyDefaultIC2</interceptor-class>
   </interceptor-binding>
  </assembly-descriptor>
　…(略)…
</ejb-jar>

この記述例では，デフォルトインターセプタクラスとして，「test.ejb30.MyDefaultIC」と「test.ejb30.MyDefaultIC2」の二つのクラスを指定しています。

インターセプタクラスの指定規則

<interceptor-class>タグでのクラス名の指定方法は，EJB 3.0仕様に準じます。次の規則に従って指定してください。

一つの<interceptor-class>タグに指定できるインターセプタクラスのクラス名は一つです。

<interceptor-class>タグは複数記述できます。<interceptor-class>タグを複数記述した場合は，記述した順序でインターセプタが呼び出されます。

<interceptor-class>タグで指定したインターセプタクラスには，次に示すアノテーションを使用してインターセプタメソッドを指定できます。

・@AroundInvoke

・@PostConstruct

・@PreDestroy

アノテーションについての詳細は，マニュアル「アプリケーションサーバ リファレンス API編」の「2.　アプリケーションサーバで使用するアノテーションおよびDependency Injection」を参照してください。

(2)　クラスレベルインターセプタの定義

クラスレベルインターセプタは，指定したクラスに適用されるインターセプタです。ここでは，DDを使用したクラスレベルインターセプタを設定する方法，および実行環境でEJB-JAR属性ファイルを使用してクラスレベルインターセプタを設定する方法について説明します。

DDで，<ejb-jar>タグ下の<interceptor-binding>タグを記述することで，クラスレベルインターセプタの情報を指定できます。

<interceptor-binding>タグ下に指定する要素を次の表に示します。

表2‒47　DDを使用する場合に<interceptor-binding>タグ下に指定する要素（クラスレベルインターセプタ）

タグ名

必須／任意

指定内容

<ejb-name>

必須

EJB名を指定します。

<interceptor-class>

必須

要素にインターセプタクラスのクラス名を指定します。

なお，<method>タグには要素を指定しません。

(3)　メソッドレベルインターセプタの定義

メソッドレベルインターセプタは，指定したビジネスメソッドに適用されるインターセプタです。ここでは，DDを使用したメソッドレベルインターセプタを設定する方法，および実行環境でEJB-JAR属性ファイルを使用してメソッドレベルインターセプタを設定する方法について説明します。

DDで，<ejb-jar>タグ下の<interceptor-binding>タグを記述することで，メソッドレベルインターセプタの情報を指定できます。

<interceptor-binding>タグ下に指定する要素を次の表に示します。

表2‒48　DDを使用する場合に<interceptor-binding>タグ下に指定する要素（メソッドレベルインターセプタ）

タグ名

必須／任意

指定内容

<ejb-name>

必須

EJB名を指定します。

<interceptor-class>

必須

要素にインターセプタクラスのクラス名を指定します。

<method-name>

必須

要素にメソッド名を指定します。

<method-params>

任意

要素にメソッドの引数リストを指定します。

<method-name>タグにビジネスメソッドを指定し，<method-params>タグの指定値を省略した場合，または<method-params>タグに引数リストを指定した場合の，メソッドレベルインターセプタが定義されるビジネスメソッドの範囲を次の表に示します。なお，<method-name>タグに"*"（ワイルドカード）を指定した場合，メソッドレベルインターセプタの定義は使用されません。

表2‒49　メソッドレベルインターセプタが定義されるビジネスメソッドの範囲

<method-params>タグの指定値

メソッドレベルインターセプタが定義されるビジネスメソッドの範囲

省略する

メソッド名が完全一致したすべてのビジネスメソッドに対してインターセプタが定義されます。

引数リストを指定する

メソッド名と引数リストが完全一致したビジネスメソッドに対してインターセプタが定義されます。

引数リストを指定した場合，アノテーションで指定した情報をDDで上書きできます。

メソッドレベルインターセプタの適用規則

ビジネスメソッドが実行される際に使用するメソッドレベルインターセプタの定義は，次の順序で決定されます。

実行するビジネスメソッドと，<method-name>タグに指定したメソッド名と<method-params>タグに指定した引数リストが完全一致する定義があれば，そのメソッドレベルインターセプタの定義が使用されます。

実行するビジネスメソッドと<method-name>タグに指定したメソッド名が一致し，<method-params>タグに引数リストを指定しない定義があれば，そのメソッドレベルインターセプタの定義が使用されます。

実行するビジネスメソッドと<method-name>タグに指定したメソッド名が一致するメソッドレベルインターセプタの定義がない場合，メソッドレベルインターセプタの定義は使用されません。

なお，実行するビジネスメソッドが，<method-name>タグに指定したメソッド名と<method-params>タグに指定した引数リストが完全一致する定義，および<method-name>タグに指定したメソッド名が一致し，<method-params>タグに引数リストを指定しない定義の両方に該当する場合は，メソッド名と引数リストが完全一致する定義が使用されます。

また，アノテーションで指定されたメソッドレベルインターセプタは，メソッド名と引数リストが完全一致する定義として扱われます。アノテーションで指定されたメソッドレベルインターセプタをDDで上書きする場合は，メソッド名と引数リストが完全一致する定義でDDに記載する必要があります。

2.15.3　上位レベルインターセプタの呼び出し抑止

クラスレベルインターセプタ，メソッドレベルインターセプタでは，アノテーション，またはDDで上位レベルのインターセプタの実行を抑止できます。

インターセプタの実行を抑止できる範囲を次の表に示します。

表2‒50　上位レベルインターセプタの実行を抑止できる範囲

インターセプタの種別

抑止する対象

デフォルトインターセプタ

クラスレベルインターセプタ

メソッドレベルインターセプタ

デフォルトインターセプタ

×

×

−

クラスレベルインターセプタ

○※

×

−

メソッドレベルインターセプタ

○

○

−

（凡例）

○：上位レベルのインターセプタの呼び出しを抑止できる。

×：上位レベルに該当しないため，呼び出し抑止の定義をしても無視される。

−：上位レベルのインターセプタの呼び出しの定義はできない。

注※

クラスレベルインターセプタでデフォルトインターセプタの呼び出し抑止の定義が指定された場合，メソッドレベルインターセプタでの定義に関係なく，デフォルトインターセプタの呼び出しを抑止します。

2.15.4　インターセプタの実行順序

インターセプタの実行順序は，デフォルトでは次の規則に従って決定されます。

EJB 3.0仕様の実行順序

EJB 3.0仕様で次の実行順序が規定されています。

デフォルトインターセプタ

クラスレベルインターセプタ

メソッドレベルインターセプタ

Beanクラスに指定されたインターセプタメソッド

同一レベルのインターセプタが複数ある場合の規則

同一レベルのインターセプタが複数ある場合，アノテーション，またはDDで記述された順番に実行されます。

インターセプタクラスに親クラスがあり，親クラスにインターセプタメソッドが定義されている場合

親クラスから実行されます。

上位レベルインターセプタの呼び出し抑止の定義による規則

上位レベルのインターセプタの呼び出しを抑止する定義を指定した場合，指定されたレベルのインターセプタは呼び出されません。

<interceptor-order>タグでの順序制御

次のビジネスメソッドを実行する場合，DDまたは属性ファイルの<interceptor-order>タグを定義したインターセプタよりも上位のインターセプタは呼び出されません。

<interceptor-order>タグで実行順序を定義したクラスレベルインターセプタが適用されている，Enterprise Beanクラスのビジネスメソッド

<interceptor-order>タグで実行順序を定義したメソッドレベルインターセプタが適用されているビジネスメソッド

<interceptor-order>タグを使用しているインターセプタの中で，いちばん低いレベルのインターセプタの定義とそれより下位のレベルのインターセプタが実行されます。

なお，ここで示したデフォルトのインターセプタの実行順序は，次の方法で変更できます。

@ExcludeDefaultInterceptorsアノテーションまたはDDの<exclude-default-interceptors>タグでデフォルトインターセプタクラスの実行を対象外にできます。

@ExcludeClassInterceptorsアノテーションまたはDDの<exclude-class-interceptors>タグでクラスレベルインターセプタクラスの実行を対象外にできます。

すべてのレベルのインターセプタクラスについて，DDの<interceptor-order>タグを記述することで順番を入れ替えることができます。

これらの規則と，DDによるアノテーションの上書きの規則を組み合わせた実行順序を(1)〜(4)で説明します。DDによるアノテーションの上書きについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.6.2　DDによるアノテーションの上書き」を参照してください。

(1)　デフォルトインターセプタ，およびクラスレベルインターセプタの呼び出し抑止の定義が指定されている場合

デフォルトインターセプタ，およびクラスレベルインターセプタの呼び出し抑止の定義が指定されている場合の，インターセプタの実行順序を次の表に示します。この表では，各項番の「<interceptor-order>の使用」に○×で示した組み合わせの場合の実行順序を，「インターセプタの実行順序」のDDまたはアノテーションの表記の前にある数字で示しています。

表2‒51　インターセプタの実行順序（デフォルトインターセプタ，およびクラスレベルインターセプタの呼び出し抑止の定義が指定されている場合）

項番

<interceptor-order>の使用

インターセプタの実行順序

デフォルト

クラスレベル

メソッドレベル

デフォルト

クラスレベル

メソッドレベル

インターセプタメソッド

1

○

○

○

−

−

1.　DD

2.　アノテーション

2

○

○

×

−

−

1.　アノテーション

2.　DD

3.　アノテーション

3

○

×

○

−

−

1.　DD

2.　アノテーション

4

○

×

×

−

−

1.　アノテーション

2.　DD

3.　アノテーション

5

×

○

○

−

−

1.　DD

2.　アノテーション

6

×

○

×

−

−

1.　アノテーション

2.　DD

3.　アノテーション

7

×

×

○

−

−

1.　DD

2.　アノテーション

8

×

×

×

−

−

1.　アノテーション

2.　DD

3.　アノテーション

（凡例）

デフォルト：デフォルトインターセプタ

クラスレベル：クラスレベルインターセプタ

メソッドレベル：メソッドレベルインターセプタ

インターセプタメソッド：Beanクラスに指定されたインターセプタメソッド

○：<interceptor-order>タグを使用して実行順序を指定している。

×：<interceptor-order>タグを使用して実行順序を指定していない。

−：実行されない。

DD：DDで指定されたインターセプタが実行される。

アノテーション：アノテーションで指定されたインターセプタが実行される。

(2)　デフォルトインターセプタの呼び出し抑止の定義が指定されている場合

デフォルトインターセプタの呼び出し抑止の定義が指定されている場合の，インターセプタの実行順序を次の表に示します。この表では，各項番の「<interceptor-order>の使用」に○×で示した組み合わせの場合の実行順序を，「インターセプタの実行順序」のDDまたはアノテーションの表記の前にある数字で示しています。

表2‒52　インターセプタの実行順序（デフォルトインターセプタの呼び出し抑止の定義が指定されている場合）

項番

<interceptor-order>の使用

インターセプタの実行順序

デフォルト

クラスレベル

メソッドレベル

デフォルト

クラスレベル

メソッドレベル

インターセプタメソッド

1

○

○

○

−

−

1.　DD

2.　アノテーション

2

○

○

×

−

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

3

○

×

○

−

−

1.　DD

2.　アノテーション

4

○

×

×

−

1.　アノテーション

2.　DD

3.　アノテーション

4.　DD

5.　アノテーション

5

×

○

○

−

−

1.　DD

2.　アノテーション

6

×

○

×

−

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

7

×

×

○

−

−

1.　DD

2.　アノテーション

8

×

×

×

−

1.　アノテーション

2.　DD

3.　アノテーション

4.　DD

5.　アノテーション

（凡例）

デフォルト：デフォルトインターセプタ

クラスレベル：クラスレベルインターセプタ

メソッドレベル：メソッドレベルインターセプタ

インターセプタメソッド：Beanクラスに指定されたインターセプタメソッド

○：<interceptor-order>タグを使用して実行順序を指定している。

×：<interceptor-order>タグを使用して実行順序を指定していない。

−：実行されない。

DD：DDで指定されたインターセプタが実行される。

アノテーション：アノテーションで指定されたインターセプタが実行される。

(3)　クラスレベルインターセプタの呼び出し抑止の定義が指定されている場合

クラスレベルインターセプタの呼び出し抑止の定義が指定されている場合の，インターセプタの実行順序を次の表に示します。この表では，各項番の「<interceptor-order>の使用」に○×で示した組み合わせの場合の実行順序を，「インターセプタの実行順序」のDDまたはアノテーションの表記の前にある数字で示しています。

表2‒53　インターセプタの実行順序（クラスレベルインターセプタの呼び出し抑止の定義が指定されている場合）

項番

<interceptor-order>の使用

インターセプタの実行順序

デフォルト

クラスレベル

メソッドレベル

デフォルト

クラスレベル

メソッドレベル

インターセプタメソッド

1

○

○

○

−

−

1.　DD

2.　アノテーション

2

○

○

×

1.　DD

−

2.　アノテーション

3.　DD

4.　アノテーション

3

○

×

○

−

−

1.　DD

2.　アノテーション

4

○

×

×

1.　DD

−

2.　アノテーション

3.　DD

4.　アノテーション

5

×

○

○

−

−

1.　DD

2.　アノテーション

6

×

○

×

1.　DD

−

2.　アノテーション

3.　DD

4.　アノテーション

7

×

×

○

−

−

1.　DD

2.　アノテーション

8

×

×

×

1.　DD

−

2.　アノテーション

3.　DD

4.　アノテーション

（凡例）

デフォルト：デフォルトインターセプタ

クラスレベル：クラスレベルインターセプタ

メソッドレベル：メソッドレベルインターセプタ

インターセプタメソッド：Beanクラスに指定されたインターセプタメソッド

○：<interceptor-order>タグを使用して実行順序を指定している。

×：<interceptor-order>タグを使用して実行順序を指定していない。

−：実行されない。

DD：DDで指定されたインターセプタが実行される。

アノテーション：アノテーションで指定されたインターセプタが実行される。

(4)　上位レベルインターセプタの呼び出し抑止の定義が指定されていない場合

上位レベルインターセプタの呼び出し抑止の定義が指定されていない場合の，インターセプタの実行順序を次の表に示します。この表では，各項番の「<interceptor-order>の使用」に○×で示した組み合わせの場合の実行順序を，「インターセプタの実行順序」のDDまたはアノテーションの表記の前にある数字で示しています。

表2‒54　インターセプタの実行順序（上位レベルインターセプタの呼び出し抑止の定義が指定されていない場合）

項番

<interceptor-order>の使用

インターセプタの実行順序

デフォルト

クラスレベル

メソッドレベル

デフォルト

クラスレベル

メソッドレベル

インターセプタメソッド

1

○

○

○

−

−

1.　DD

2.　アノテーション

2

○

○

×

−

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

3

○

×

○

−

−

1.　DD

2.　アノテーション

4

○

×

×

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

5.　DD

6.　アノテーション

5

×

○

○

−

−

1.　DD

2.　アノテーション

6

×

○

×

−

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

7

×

×

○

−

−

1.　DD

2.　アノテーション

8

×

×

×

1.　DD

2.　アノテーション

3.　DD

4.　アノテーション

5.　DD

6.　アノテーション

（凡例）

デフォルト：デフォルトインターセプタ

クラスレベル：クラスレベルインターセプタ

メソッドレベル：メソッドレベルインターセプタ

インターセプタメソッド：Beanクラスに指定されたインターセプタメソッド

○：<interceptor-order>タグを使用して実行順序を指定している。

×：<interceptor-order>タグを使用して実行順序を指定していない。

−：実行されない。

DD：DDで指定されたインターセプタが実行される。

アノテーション：アノテーションで指定されたインターセプタが実行される。

2.15.5　実行環境での設定

インターセプタは，実行環境で設定することもできます。実行環境で設定する場合，J2EEサーバにインポートしたJ2EEアプリケーションに設定します。

実行環境でのJ2EEアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。インターセプタの定義には，EJB-JAR属性ファイルを使用します。なお，J2EEアプリケーションに含まれないEJB-JARファイルに対して，サーバ管理コマンド（cjsetresprop -type ejbコマンド）を使用して設定することはできません。

EJB-JAR属性ファイルで指定するタグは，DDと対応しています。DD（ejb-jar.xml）での定義については，「2.15.2　アノテーションまたはDDでの定義」を参照してください。

2.15.6　インターセプタに関する注意事項

<ejb-name>タグに"*"（ワイルドカード）を指定した<interceptor-binding>タグが複数ある場合は，いちばん上に記述された<interceptor-binding>タグの内容が有効になります。2番目以降の内容は設定されません。

属性ファイルの場合，<ejb-name>タグの値と，<named-method>タグおよびその配下の要素すべてが一致する<interceptor-binding>タグが複数存在する場合，いちばん上に記述された<interceptor-binding>タグの内容が有効になります。2番目以降の内容は設定されません。

DDの場合，<ejb-name>タグの値と，<method>タグおよびその配下の要素すべてが一致する<interceptor-binding>タグが複数存在する場合，いちばん上に記述された<interceptor-binding>タグの内容が有効になります。2番目以降の内容は設定されません。

2.16　ローカルビジネスインタフェースの省略（No-Interface viewの利用）

EJB 3.1では，Session Beanでローカル呼び出しを実行する場合に，ローカルビジネスインタフェースを作成することなくEJBを作成できます。この場合，クライアントからは，No-Interface viewとして公開された，すべてのビジネスメソッドを呼び出せます。ローカルビジネスインタフェースの実装を省略できるため，EJBの開発やメンテナンスが従来よりも容易になります。

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

表2‒55　この節の構成（ローカルビジネスインタフェースの省略（No-Interface viewの利用））

分類

タイトル

参照先

解説

No-Interface viewの概要

2.16.1

実装

No-Interface viewを使用するための定義

2.16.2

使用できないメソッド

2.16.3

注意事項

開発時の注意事項

2.16.4

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

2.16.1　No-Interface viewの概要

Session Beanは，次の3種類のクライアントからアクセスされます。

リモートクライアント

リモートビジネスインタフェース（またはリモートホームインタフェース）を使用してビジネスメソッドを呼び出すクライアントです。Session Beanのリモートクライアントビュー（remote client view）で提供されたメソッドを呼び出します。

ローカルクライアント

ローカルインタフェースを使用してビジネスメソッドを呼び出すクライアントです。Session Beanのローカルクライアントビュー（local client view）で提供されたメソッドを呼び出します。

Webサービスクライアント

Webサービスを使用してビジネスメソッドを呼び出すクライアントです。Session BeanのWebサービスクライアントビュー（WebService client view）で提供されたメソッドを呼び出します。

No-Interface viewは，ローカルクライアントビューの一つです。EJB 3.1以降で使用できます。

No-Interface viewを使用することで，ローカルビジネスインタフェースの定義が不要になります。アプリケーションでリモートクライアントビュー，ローカルクライアントビューまたはWebサービスクライアントビューのどれも実装していない場合，EJBコンテナによってNo-Interface viewが作成されます。また，アプリケーションでどれかのビューが実装されている場合も，明示的に@LocalBeanアノテーションを指定することで，No-Interface viewが使用できるようになります。Session BeanでNo-Interface viewを使用するための特別なインタフェースを実装する必要はありません。

No-Interface viewを使用すると，Session Beanのすべてのpublicメソッドがクライアントから使用できるようになります。クライアントからNo-Interface viewへの参照は，DIまたはJNDIのルックアップで取得できます。

No-Interface viewは，アプリケーション開始時に作成され，アプリケーションが停止するまで使用できます。

注意事項

クライアントからNo-Interface viewで公開されたメソッドを呼び出す場合，public以外のアクセス修飾子を指定したメソッドは呼び出せません。public以外のアクセス修飾子を指定したメソッドを呼び出した場合は，javax.ejb.EJBExceptionが発生します。

2.16.2　No-Interface viewを使用するための定義

No-Interface viewは，次のどちらかに該当する場合に，EJBコンテナによって作成されます。

Session Beanで次のビューが実装されていない場合

ローカルクライアントビュー

リモートクライアントビュー

Webサービスクライアントビュー

なお，java.io.Serializableインタフェース，java.io.Externalizableインタフェースおよびjavax.ejbパッケージ内のインタフェースは，上記のビューが実装されているかどうかの判定から除外されます。

Session Beanで@LocalBeanアノテーションを定義した場合

2.16.3　使用できないメソッド

No-Interface viewを使用する場合は，次のメソッドはビジネスメソッドとして使用しないでください。これらのメソッドを使用すると，コンパイルエラーが発生し，アプリケーションの開始に失敗します。

public void init(Hashtable)

public void init(Object)

public void init(String, Hashtable)

public void initializeBIInstance()

public Throwable convertRemoteException(Throwable)

public Throwable unwrapServerException(Throwable)

また，java.lang.Objectクラスで定義された次のメソッドも使用しないでください。

equals(Object)

hashCode()

toString()

clone()

finalize()

2.16.4　開発時の注意事項

No-Interface viewを使用するSession Beanを開発する際の注意事項を次に示します。

ローカルビジネスインタフェースを省略したSession Beanのメソッドには，java.rmi.RemoteExceptionを含めないでください。

ただし，javax.ejbパッケージ内のインタフェースを実装したメソッドの場合は，throws節にjava.rmi.RemoteExceptionが含まれていても，エラーにはなりません。

javax.ejbパッケージ内のインタフェースを実装したSession Beanのメソッドは，ビジネスメソッドとしてみなされません。No-Interface viewを使用する場合は，クライアントからこれらのメソッドを呼び出さないでください。

Beanクラスやその親クラスのすべてのメソッドでfinalは宣言できません。finalを宣言したメソッドは，No-Interface viewでは呼び出せません。

Session Beanのメソッドにstaticまたはfinalが宣言されている場合，これらのメソッドはビジネスメソッドとは見なされません。No-Interface viewを使用する場合，クライアントからこれらのメソッドは呼び出さないでください。

通常のビジネスインタフェースでは，@AroundInvokeアノテーションを使用すると，ビジネスメソッドの実行がデプロイメントエラーになります。しかし，No-Interface viewを使用する場合は，@AroundInvokeアノテーションをpublicメソッドで使用すると，エラーにはなりません。ビジネスメソッドとして扱われます。

標準仕様では，@Removeアノテーションはビジネスメソッドで使用されます。しかし@PreDestroyアノテーションがあわせて設定されているビジネスメソッドで@Removeアノテーションを指定すると，クライアントからメソッドを呼び出したときにjavax.ejb.NoSuchObjectLocalExceptionがスローされます。

2.17　Session Beanの非同期呼び出し

EJB3.1では，Session Beanのビジネスメソッドを非同期で呼び出せます。これによって，複数の処理を並行して実行できるようになります。

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

表2‒56　この節の構成（Session Beanの非同期呼び出し）

分類

タイトル

参照先

解説

Session Beanの非同期呼び出しの適用範囲

2.17.1

非同期呼び出しでのトランザクションの扱い

2.17.2

非同期呼び出しでのアプリケーション情報の扱い

2.17.3

実装

非同期呼び出しのためのアノテーションの定義

2.17.4

非同期メソッドの戻り値の指定

2.17.5

Future<V>オブジェクトによる非同期メソッドの実行状態および実行結果に対する操作

2.17.6

cosminexus.xmlでの定義

2.17.7

注意事項

非同期メソッド実装時のアノテーションに関する注意事項

2.17.8

非同期メソッドの動作に関する注意事項

2.17.9

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

2.17.1　Session Beanの非同期呼び出しの適用範囲

Session Beanに対して非同期呼び出しを実行した場合，EJBコンテナはSession Beanの処理を待たないで，すぐに呼び出し元であるクライアントに制御を返します。非同期呼び出しを受けたメソッドは，呼び出し元とは異なるスレッドで処理を実行します。クライアントでは，結果を待たないで次の処理を進められるため，アプリケーションのスループットを向上させられます。

非同期呼び出しができるのは，EJB 3.1に対応した，次のインタフェースまたはビューを持つSession Beanです。

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

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

No-Interface view

非同期呼び出しは，@Asynchronousアノテーションによって実現できます。

Stateless Session BeanまたはSingleton Session Beanのすべてのpublicメソッドは，@Asynchronousアノテーションによって，非同期メソッドとして実行できます。

なお，非同期メソッドは，Stateful Session Beanのメソッドでは実装できません。これは，非同期呼び出しを実行しているときのセッションの詳細やトランザクションの状態が保持されないためです。

また，非同期呼び出しをした場合のセキュリティ情報の伝播は，同期呼び出しの場合と同じです。

2.17.2　非同期呼び出しでのトランザクションの扱い

Session Beanの非同期呼び出しでは，次のトランザクション属性だけが指定できます。

Required属性

RequiresNew属性

NotSupported属性

ただし，呼び出し元であるクライアントのトランザクションコンテキストは，非同期メソッドでは伝播されません。アプリケーション開発者は，伝播されたトランザクションコンテキストがないものとして扱う必要があります。例えば，Required属性が非同期メソッドに定義されていても，EJBコンテナではRequiresNew属性を指定した場合と同様に処理されます。

クライアントで指定した非同期メソッドでのトランザクション属性の指定と対応するトランザクションを次の表に示します。

表2‒57　クライアントで指定した非同期メソッドでのトランザクション属性の指定と対応するトランザクション

メソッドに指定したトランザクション属性

クライアントのトランザクション

非同期メソッドに関連づくトランザクション

NOT_SUPPORTED

なし

なし

T1

なし

REQUIRED

なし

T2

T1

T2

REQUIRES_NEW

なし

T2

T1

T2

SUPPORTS

なし

なし

T1

なし

NEVER

なし

なし

T1

なし

MANDATORY

なし

エラー

T1

エラー

（凡例）

なし：トランザクションの指定がない，またはトランザクションがない

T1：呼び出し元のクライアントが設定したトランザクション

T2：EJBコンテナによって開始された新しいトランザクション

2.17.3　非同期呼び出しでのルートアプリケーション情報の扱い

EJBコンテナは，非同期メソッドをコールバックする直前に出力するPRFトレースのイベントID（0x84C0）で，呼び出し元のルートアプリケーション情報をオプションに出力します。このルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができます。

2.17.4　非同期呼び出しのためのアノテーションの定義

非同期呼び出しをする場合は，Session Beanのビジネスメソッドまたはクラスに対して，@Asynchronousアノテーションを指定します。@Asynchronousアノテーションをクラスに指定した場合，そのクラスに含まれるすべてのビジネスメソッドに@Asynchronousアノテーションを指定したことになります。

@Asynchronousアノテーションを指定して送られたクライアントからのリクエストは，Daemonスレッドとして，新しいスレッドで実行されます。

2.17.5　非同期メソッドの戻り値の指定

非同期メソッドでは，戻り値として次のどちらかを選択できます。

void

java.util.concurrent.Future<V>（Vは戻り値の型）

以降の説明ではFuture<V>と表記します。

なお，voidを選択した場合，アプリケーション例外は宣言できません。Future<V>を選択した場合は，アプリケーション例外を宣言できます。なお，リモートインタフェースから呼び出した場合，処理結果にアクセスするためのFuture<V>オブジェクトはEJBコンテナで保持されます。

非同期メソッドでは，Future<V>の実装クラスであるjavax.ejb.AsyncResult<V>を使用することで，メソッドの処理結果オブジェクトを呼び出し元に渡すことができます。

@Asynchronousアノテーションを使用したコーディング例として，戻り値にFuture<V>を指定した場合とvoidを指定した場合の例を次に示します。

// Enterprise Bean Business method

//戻り値にFuture<V>を指定した例
@Asynchronous
public Future<Integer> performCalculation(...) {
    // ... do calculation
    Integer result = null;
    if (ejb_context.wasCancelCalled()) {
        return new AsyncResult<Integer>(-1);
    }
    ...
    return new AsyncResult<Integer>(result);
}
//戻り値にvoidを指定した例
@Asynchronous
public void performAddition (...) {
    Integer result = null;
    // ... do addition
}

2.17.6　Future<V>オブジェクトによる非同期メソッドの実行状態および実行結果に対する操作

非同期メソッドの戻り値にFuture<V>を指定した場合，Future<V>オブジェクトのメソッドを使用して次の処理ができます。これらの処理は，戻り値がvoidの場合は実行できません。

非同期呼び出し処理のキャンセル

非同期呼び出し処理の実行結果の取得

非同期呼び出し処理の実行状態の確認

非同期呼び出し処理で例外が発生した場合の要因取得

(1)　非同期呼び出し処理のキャンセル

Future<V>オブジェクトのcancelメソッドを使用して，処理をキャンセルできます。

キャンセルに成功した場合は，メソッドの戻り値としてtrueが返却されます。キャンセルできなかった場合は，戻り値としてfalseが返却されます。

非同期呼び出しがキャンセルできなかった場合は，cancelメソッドのmayInterruptIfRunningパラメタの指定によって，処理が中断されるか，処理がそのまま実行されるかが決まります。

(2)　非同期呼び出し処理の実行結果の取得

Future<V>オブジェクトのgetメソッドを使用して，実行結果を取得できます。

処理が成功して処理結果が戻り値として取得できた場合，またはExecutionExceptionが発生した場合は，処理が完了しています。これ以降に同じFuture<V>オブジェクトを使用して実行結果を取得した場合，同じ結果を取得できます。

なお，アプリケーションサーバでは，Future<V>オブジェクトのメソッド呼び出しでタイムアウトが発生した場合，EJBコンテナによってEJBExceptionがクライアントに対してスローされます。

(3)　非同期呼び出し処理の実行状態の確認

非同期呼び出し処理の実行が完了したかどうか，キャンセルされたかどうかを確認できます。状態は，Future<V>オブジェクトの次のメソッドで確認できます。

isDoneメソッド

処理が正常に完了している場合，例外が発生している場合，およびキャンセルされた場合にtrueが返されます。

isCancelledメソッド

処理のキャンセルが成功している場合にtrue，キャンセルできなかった場合にfalseが返されます。

また，非同期メソッドの側で，クライアントからcancelメソッドが呼び出されたかどうかは，次のメソッドで確認できます。

wasCancelCalledメソッド

cancelメソッドによって非同期呼び出し処理の実行のキャンセルが呼び出された場合に，cancelメソッドのmayInterruptIfRunningパラメタにtrue（実行中の処理を停止する）が指定されていたときはtrue，false（実行中の処理を完了させる）が指定されたときはfalseが返されます。

(4)　非同期呼び出し処理で例外が発生した場合の要因取得

ビジネスインタフェースのメソッドでシステム例外が発生した場合，呼び出し元のクライアントには，javax.ejb.EJBExceptionなどの代わりに，java.rmi.RemoteExceptionが返されます。非同期呼び出し処理でシステム例外を受け取った場合，クライアントでは，非同期メソッドが実行されなかったと判断できます。この場合は，再度非同期メソッドの呼び出しを実行できます。

アプリケーション例外など，システム例外以外の例外が発生した場合，クライアントはEJBコンテナによって非同期処理が実行された上で，非同期処理の中で例外が発生したと判断できます。この場合は，例外オブジェクトを使用して，要因を取得できます。

非同期呼び出し時に例外が発生した場合に例外オブジェクトのgetCauseメソッドを呼び出して，原因を取得するコーディング例を次に示します。

// Bean Client
Future future = asynSessionBean.performCalculation();
while (!future.isDone()) {
    Thread.currentThread().sleep(10000);
    future.cancel(true);
    break;
}
if (future.isCancelled() == false) {
    Integer answer = null;
    try{
        answer  = (Integer)future.get();
    }  catch(ExecutionException e){
        System.out.println("caught exception: " +e.getCause());
    }
    System.out.println("Answer=" + answer.toString());
}
asynSessionBean.performAddition();

2.17.7　cosminexus.xmlでの定義

cosminexus.xmlでは，次の項目を設定できます。

非同期呼び出し処理を同時に実行できるスレッド数およびスレッドの保存期間

非同期メソッドの処理結果保持期間のタイムアウト

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

(1)　非同期呼び出し処理を同時に実行できるスレッド数およびスレッド保存期間

同時に実行できるスレッド数や，スレッドの保存期間などの属性は，cosminexus.xmlに定義します。設定するパラメタを次に示します。

max-thread-pool-size

プールに生成できるスレッドの最大数を指定します。

min-thread-pool-size

プール内で使用していないスレッドを幾つまで保存できるかを指定します。

thread-pool-keep-alive

使用していないスレッド数がmin-thread-pool-sizeで指定した数を超えている場合に，スレッドを終了するまでに保存しておく時間を設定します。

(2)　非同期メソッドの処理結果保持期間のタイムアウト

リモートインタフェースを使用した非同期メソッド呼び出しの処理結果を取得するためのFuture<V>オブジェクトの保持期間に，タイムアウトを設定します。タイムアウトを設定しないと，アプリケーションが停止するまで処理結果が保持されるため，処理結果が多い場合などにはメモリ使用量が増え，OutOfMemoryエラーが発生するおそれがあります。これを防ぐために，結果を保持する期間の最大値を設定します。設定するパラメタを次に示します。

result-timeout-value

処理結果を保持する期間（単位：分）を指定します。この期間を超えた処理結果は，EJBコンテナから削除され，参照できなくなります。

削除後に，削除された処理結果を示すFuture<V>オブジェクトのメソッドを呼び出した場合，文字列「KDJE43202-I」をメッセージに含むEJBExceptionがスローされます。例外メッセージに「KDJE43202-I」があるかどうかを確認して，タイムアウトによる削除が発生したかどうかを判断できます。

ただし，ローカルクライアントの場合，Future<V>オブジェクトはローカルに保持されているため，例外は発生しないで，メソッドは正常に終了します。

次に，非同期呼び出しを実行する場合のJavaヒープの見積もり，およびJavaヒープのチューニングをするときのポイントについて示します。

(a)　非同期呼び出しを実行する場合のJavaヒープの見積もり

リモートインタフェースを使用して非同期処理を呼び出した場合，処理結果を示すFuture<V>オブジェクトは，EJBコンテナが動作するJavaVM上で保持されます。このため，リクエスト数が多い場合，JavaVMでOutOfMemoryエラーが発生しないように留意する必要があります。

非同期呼び出しを実行する場合，非同期メソッドごとに必要なJavaヒープサイズを次の見積もり式によって見積もってください。

一つの非同期メソッドで必要なJavaヒープサイズ（単位：キロバイト）

=(1+A)×(B+C+1)×D

（凡例）

A：ユーザアプリケーションに依存するオブジェクトサイズ（キロバイト）

B：非同期メソッド実行時間の平均値（分）

C：cosminexus.xmlに指定したresult-timeout-valueの値

D：1分間に呼び出される非同期メソッドの平均実行回数

非同期メソッドごとに算出した値を合計して，全体として必要なJavaヒープサイズを割り出してください。

ポイント

この見積もり式で算出するのは，リモートインタフェースで非同期メソッドを呼び出す場合に必要なJavaヒープサイズです。ローカルインタフェースで呼び出す場合，EJBコンテナで結果が保持されないため，見積もりは不要です。

「ユーザアプリケーションに依存するオブジェクトサイズ」とは，処理結果オブジェクトのサイズです。通常，ユーザアプリケーションの処理結果オブジェクトのサイズについて意識する必要はありませんが，サイズが大きい場合は，テストプログラムなどで使用するサイズを測定した上で，必要に応じてJavaヒープサイズを変更してください。

(b)　タイムアウト時間のチューニングのポイント

タイムアウト時間のチューニングでは，次のポイントを考慮して検討してください。

タイムアウト時間には，アプリケーションでFutureオブジェクトのisDoneメソッドが実行される間隔よりも長い値を指定してください。また，Futureオブジェクトのgetメソッドが呼び出されてから非同期メソッドが呼び出されるまでの期間よりも長い値を指定してください。

リソースの使用量を少なくしたい場合は，result-timeout-valueの値を小さくしてください。ただし，その場合，期間を超え，削除された処理結果にはアクセスできなくなることを考慮してください。

result-timeout-valueの定義は，非同期メソッドの実行時間の平均値，非同期メソッドの実行時間および1分間の実行回数の平均値を考慮して，Javaヒープメモリを消費し過ぎないサイズを算出した上で設定してください。

2.17.8　非同期メソッド実装時のアノテーションに関する注意事項

非同期メソッドをクラス単位に指定した場合（クラスに対して@Asynchronousアノテーションを指定した場合），クラスに含まれるすべてのメソッドの戻り値として，voidまたはFuture<V>を指定する必要があります。異なる型を指定した場合，アプリケーションの開始に失敗します。

非同期メソッドをメソッド単位に指定した場合（メソッドに対して@Asynchronousアノテーションを指定した場合），@Asynchronousアノテーションを指定したメソッドの戻り値として，voidまたはFuture<V>を指定する必要があります。異なる型を指定した場合，アプリケーションの開始に失敗します。

2.17.9　非同期メソッドの動作に関する注意事項

非同期呼び出しを実行するSession Beanでは，メソッドキャンセル機能は実行できません。メソッドキャンセルを実行しようとした場合，KDJE52703-Wメッセージが出力されますが，メソッドキャンセルは実行されません。

非同期メソッドをキャンセルしたい場合は，Future<V>オブジェクトのメソッドを使用してください。

アプリケーション停止時には，クリーンアップ処理が実行されます。実行中のすべての処理が完了するまで，クリーンアップ処理は完了しません。すべての処理が完了すると，クリーンアップ処理が完了し，アプリケーションが停止します。

リモートインタフェースを使用してSession Beanの非同期処理を呼び出した場合，サーバ運用中のFullGCの発生要因となるオブジェクトが生成されます。このため，FullGCの発生を抑止したい場合，リモートインタフェースを使用して非同期処理を呼び出さないでください。

2.18　Session Synchronizationのアノテーションでの指定

トランザクションの開始・終了前後で実行する処理（Session Synchronization）は，javax.ejb.SessionSynchronizationインタフェースを実装するほかに，アノテーションを使用することでも定義できます。

この節では，CMTでトランザクションを管理している場合に，トランザクションの開始・終了の前後で実行する処理をアノテーションで設定する方法について説明します。

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

表2‒58　この節の構成（トランザクションの開始・終了の前後で実行する処理の設定）

分類

タイトル

参照先

解説

Session Synchronizationをアノテーションで設定する方法

2.18.1

実装

実装時の規則

2.18.2

注意事項

実装時の注意事項

2.18.3

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

2.18.1　Session Synchronizationをアノテーションで設定する方法

CMTでトランザクションを管理している場合，トランザクションの管理はコンテナによって実行されます。この場合，トランザクションの開始や終了を実装することなくアプリケーションを開発できます。コンテナによる管理では，メソッドの開始直前にトランザクションが開始され，メソッドの終了直後にトランザクションがコミットして終了します。

コンテナによるトランザクションの開始・終了の前後に特定の処理を実行したい場合は，Session Synchronizationの機能を使用します。Session Synchronizationの機能は，次のどちらかの方法で使用できます。

javax.ejb.SessionSynchronizationインタフェースを実装する方法

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

アノテーションを指定する方法は，EJB 3.1以降で使用できます。アノテーションを指定すると，javax.ejb.SessionSynchronizationインタフェースの実装をしないで，トランザクションの開始・終了前後で処理を実行するタイミングを設定できるため，アプリケーションの開発が容易になります。

ここでは，アノテーションを使用する場合の指定について説明します。使用できるアノテーションを次に示します。

@AfterBegin

新しいトランザクションが開始されたことを通知するアノテーションです。このアノテーションを指定した処理は，トランザクションの開始後，ビジネスメソッドを呼び出す直前にコンテナによって呼び出されます。

@BeforeCompletion

ビジネスメソッドの実行が完了したことを通知するアノテーションです。このアノテーションを指定した処理は，ビジネスメソッドの完了後，トランザクションがコミットする直前に呼び出されます。ビジネスメソッドで実施した処理をロールバックしたい場合は，このタイミングでsetRollbackOnlyメソッドを呼び出す必要があります。

@AfterCompletion

トランザクションが完了したことを通知するアノテーションです。このアノテーションを指定した処理は，トランザクションの完了直後に呼び出されます。

このアノテーションには，パラメタとして，trueまたはfalseを指定できます。trueを指定した場合，トランザクションがコミットすると処理が実行されます。falseを指定した場合，トランザクションがロールバックすると処理が実行されます。

これらのアノテーションは，Stateful Session Beanのクラス（またはその親クラス）に指定できます。それぞれのSession Beanでは，これらのアノテーションを種類ごとに一つずつ指定できます。

2.18.2　実装時の規則

アノテーションを指定するメソッドは，次の規則に沿って指定してください。正しく指定していない場合，アプリケーション開始時にエラーになります。

この機能を使用できるのは，CMTでトランザクションを管理している，Stateful Session Beanだけです。Stateless Session BeanおよびSingleton Session Beanでは使用できません。また，BMTの場合は，トランザクション処理のタイミングをSession Beanで管理できるため，この機能を使用する必要はありません。

アノテーションを指定するメソッドにfinalおよびstaticは宣言しないでください。

アノテーションを指定するメソッドの戻り値はvoid型にしてください。

@AfterBeginおよび@BeforeCompletionにはパラメタを指定しないでください。

@AfterCompletionのパラメタには，boolean型の値を一つだけ指定してください。

2.18.3　実装時の注意事項

実装時の注意事項を次に示します。

afterBeginメソッド，beforeCompletionメソッドまたはafterCompletionメソッドは，対象とするSession Bean（またはその親クラス）でjavax.ejb.SessionSynchronizationインタフェースを実装するか，またはSession Beanでアノテーションを指定した場合だけ，コンテナによって呼び出されます。

Session Beanの開発時にjavax.ejb.SessionSynchronizationインタフェースの実装とアノテーションの指定を両方実施した場合，インタフェースの実装が優先されます。

同じアノテーションをSession Beanのクラスで複数回指定した場合，複数回指定されたafterBeginメソッド，beforeCompletionメソッドまたはafterCompletionメソッドのうち，どのメソッドがコンテナによって呼び出されるかは保証されません。

アノテーションに規則外のパラメタを指定した場合，アプリケーションの開始に失敗し，KDJE42039-Eメッセージが出力されます。

@AfterBeginアノテーション，@BeforeCompletionアノテーションまたは@AfterCompletionアノテーションによって処理のタイミングを設定したメソッドは，ほかのビジネスメソッドと同様に，クライアントから直接呼び出すことができます。ただし，一般的に，コールバックメソッドはビジネスメソッドとしてクライアントに公開されるべきではありません。このため，これらのメソッドのアクセス修飾子には，public以外を宣言することをお勧めします。

2.19　Singleton Session Beanの利用

ここでは，アプリケーションサーバで利用できるSingleton Session Beanの詳細について説明します。

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

表2‒59　この節の構成（Singleton Session Beanの利用）

分類

タイトル

参照先

解説

Singleton Session Beanの排他制御

2.19.1

Singleton Session Beanでのエラー処理

2.19.2

注意事項

Singleton Session Bean利用時の注意事項

2.19.3

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

2.19.1　Singleton Session Beanの排他制御

Singleton Session Beanの排他制御には，次の二つの方法があります。

Container-Managed Concurrency

EJBコンテナでメソッドレベルのインスタンスの処理状況を管理します。

Bean-Managed Concurrency

Enterprise BeanですべてのBeanインスタンスの処理状況を管理します。

Singleton Session Beanを開発する場合，どちらの方法で排他制御を管理するかを決める必要があります。両方の方法を同時に使用することはできません。

(1)　Container- Managed Concurrency

EJBコンテナによって排他制御が実行されます。それぞれのビジネスメソッドやタイムアウトメソッドは，ReadロックまたはWriteロックによって制御されます。Readロックを設定したメソッドの場合，複数のメソッドの処理を同時に実行できます。Writeロックを設定したメソッドの場合，一つのメソッドの処理が完了するまで，ほかのメソッドの呼び出しは実行されません。

ロックの種類は，Session Beanのクラス，またはオーバーライドしたクラスのメソッドに対して，アノテーションで指定します。明示的に指定しない場合は，Writeロックを指定した場合と同じように動作します。

なお，排他制御実行時に，処理実行待ちのタイムアウト時間を設定できます。タイムアウト時間は，@AccessTimeoutアノテーションによって指定できます。タイムアウトが発生した場合は，EJBコンテナによって，呼び出し元のクライアントに対してjavax.ejb.ConcurrentAccessTimeoutExceptionがスローされます。

(2)　Bean-Managed Concurrency

Bean-Managed Concurrencyを指定した場合，EJBコンテナによってSingleton Session Beanに対する排他制御は実行されません。アプリケーション開発時に，排他制御に関する実装が必要です。目的に応じて，Java言語のSynchronizedやvolatileを使用して実装してください。

2.19.2　Singleton Session Beanでのエラー処理

Singleton Session Beanの初期化時に，次のようなエラーが発生することがあります。

DIの失敗

コンストラクタメソッドでのシステム例外の発生

ライフサイクルコールバックメソッド（PostConstructまたはPreDestroy）での例外の発生

Singleton Session Beanの初期化に失敗した場合，Singleton Session Beanのビジネスインターフェースメソッドの呼び出しに対して，javax.ejb.NoSuchEJBExceptionが発生します。

初期化に成功すると，アプリケーションが停止するまで，Singleton Session Beanのインスタンスは維持されます。Singleton Session Beanのビジネスメソッドまたはコールバックメソッドからシステム例外がスローされた場合も，Singleton Session Beanのインスタンスは破棄されません。

注意事項

アプリケーションサーバでは，Singleton Session BeanのPostConstructメソッドからSingleton Session Beanの非同期メソッドを呼び出すことはできません。

2.19.3　Singleton Session Bean利用時の注意事項

Writeロックを取得待ちの状態のスレッドの処理は，アプリケーションの停止によって中断されません。

@DependsOnアノテーションで循環依存が指定されていた場合，アプリケーションの開始時のデプロイ処理でエラーになります。

アプリケーションサーバでは，異なるEJB-JARファイルのSingleton Session Beanに対する@DependsOnアノテーションの指定はできません。

Singleton Session Beanのライフサイクルコールバックメソッド（PostConstructまたはPreDestroy）では，@TransactionAttributeアノテーションのトランザクション属性の指定は無効になります。

3　EJBクライアント

この章では，EJBクライアントで使用できる機能について説明します。EJBクライアントは，Enterprise Beanを呼び出すクライアントプログラムです。

3.1　この章の構成

EJBクライアントとは，J2EEサーバ上のEJBコンテナで実行されているEnterprise Beanを呼び出すクライアントプログラムです。

EJBクライアントには，次の種類があります。

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

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーションとは，J2EEサーバ上で実行されるEnterprise Beanを呼び出すクライアントアプリケーションのことです。

EJBクライアントの機能と参照先を次の表に示します。

表3‒1　EJBクライアントの機能と参照先

機能

参照先

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

3.2

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

3.3

Enterprise Beanの呼び出し

3.4

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

3.5

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

3.6

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

3.7

EJBクライアントアプリケーションのシステムログ出力

3.8

なお，この章では，EJBクライアントアプリケーションの機能を中心に説明します。

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

EJBクライアントで使用できる機能について，次の表に示します。それぞれの機能の詳細については，参照先の説明を参照してください。なお，「参照先マニュアル」に示したマニュアル名の「アプリケーションサーバ」は省略しています。

表3‒2　EJBクライアントで使用できる機能

分類

機能概要

参照先マニュアル

参照個所

JNDI

基本機能

EJBホームオブジェクトリファレンスおよびビジネスインタフェースのリファレンスの検索，取得ができます。

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

2章

拡張機能

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

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

EJB

EJBコンテナで実行されているEnterprise Beanを呼び出せます。

このマニュアル

2.2，3.4※，3.7※

EJB呼び出し実行時に通信障害が発生した場合に，送信動作を選択できます。

このマニュアル

2.13.3

トランザクション

EJBクライアントでトランザクションを開始・決着できます。

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

3章

Security

J2EEサーバで定義されたユーザとパスワードを使用してユーザ認証ができます。EJBクライアントからログインして，セキュリティロールが設定されたEJBのビジネスメソッドを呼び出せます。

このマニュアル

3.6※

機能解説 セキュリティ管理機能編

6章

そのほか

EJBクライアントとネーミングサービス間，およびEJBクライアントとJ2EEサーバ間の通信で，通信タイムアウトを設定できます。

このマニュアル

2.11

EJBクライアントの性能解析トレースを出力できます。

機能解説 保守／移行編

4.6

注※　アプリケーションの実装方法について説明しています。

EJBクライアントアプリケーションで使用できる拡張機能について，次の表に示します。なお，それぞれの機能の詳細については，参照先の説明を参照してください。なお，EJBクライアントアプリケーションでは，データソース（JDBC）およびコネクタ（Connector）は使用できません。

表3‒3　EJBクライアントアプリケーションで使用できる拡張機能

分類

機能概要

機能についての参照先

トランザクション

EJBクライアントアプリケーションでUserTransactionを取得し，トランザクションを開始・決着できます。UserTransactionの取得方法には次の2種類の方法があります。

UserTransactionFactoryクラスを使用する方法

ルックアップを使用する方法

なお，Application Serverでは，1.の方法を推奨しています。

3.5

そのほか

EJBクライアントのログを出力できます。

3.8※

EJBクライアントアプリケーションをコマンド（cjclstartapコマンド）で開始できます。

3.3.1

注※　このマニュアルでは，EJBクライアントアプリケーションのシステムログについて説明しています。EJBクライアントアプリケーションが出力するユーザログについては，マニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.　アプリケーションのユーザログ出力」を参照してください。

次の節以降では，EJBクライアントアプリケーションの機能について説明しています。

3.3　EJBクライアントアプリケーションの開始

この節では，EJBクライアントアプリケーション開始について説明します。

EJBクライアントアプリケーションは，コマンドを使用して開始します。

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

表3‒4　この節の構成（EJBクライアントアプリケーションの開始）

分類

タイトル

参照先

解説

EJBクライアントアプリケーション開始に使用するコマンド

3.3.1

cjclstartapコマンドの場合

3.3.2

vbjコマンドの場合

3.3.3

設定

EJBクライアントアプリケーションの実行に必要な環境変数の設定

3.3.4

EJBクライアントアプリケーションのプロパティの設定

3.3.5

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

この節では，EJBクライアントアプリケーションの開始に使用するコマンド，および使用するコマンドごとのEJBクライアントアプリケーションの開始の流れについて説明します。

3.3.1　EJBクライアントアプリケーション開始に使用するコマンド

EJBクライアントアプリケーションの開始に使用するコマンドを次の表に示します。

表3‒5　EJBクライアントアプリケーションの開始に使用するコマンド

コマンド名

説明

cjclstartap

cjclstartapコマンドは，EJBクライアントアプリケーションの実行に必要なオプションやプロパティを，あらかじめオプション定義ファイルやプロパティファイルに記述しておくことができます。なお，各ファイルでオプションやプロパティの指定を省略した場合には，デフォルト値が適用されてコマンドが実行されます。

Application Serverでは，トラブルシュート機能を強化したcjclstartapコマンドでのEJBクライアントアプリケーションの運用をお勧めします。

また，cjclstartapコマンドを使用すると，Javaアプリケーションも開始できます。

コマンドの格納場所を次に示します。

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/client/bin

vbj

vbjコマンドは，EJBクライアントアプリケーションの実行に必要なオプションやプロパティをコマンドの引数として指定する必要があります。オプションやプロパティの省略はできません。

vbjコマンドは，旧バージョン互換用のコマンドです。従来の方法でvbjコマンドを使用してEJBクライアントアプリケーションを実行したい場合に使用してください。

コマンドの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥TPB¥bin¥vbj

UNIXの場合

/opt/Cosminexus/TPB/bin/vbj

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，格納ディレクトリの「<Application Serverのインストールディレクトリ>¥CC」を，「<Application Serverのインストールディレクトリ>¥CCL」と読み替えてください。

それぞれのコマンドによるEJBクライアントアプリケーションの開始の流れについて以降の項で説明します。

3.3.2　cjclstartapコマンドの場合

cjclstartapコマンドによるEJBクライアントアプリケーションの開始の流れを次に示します。

EJBクライアントアプリケーションの実行に必要な環境変数を設定します。

EJBクライアントアプリケーションの実行に必要な環境変数のうち，cjclstartapコマンドでの実行に必要な環境変数を設定してください。必要な環境変数については，「3.3.4　EJBクライアントアプリケーションの実行に必要な環境変数の設定」を参照してください。

EJBクライアントアプリケーションのオプション定義ファイル（usrconf.cfg）に，JavaのオプションやJARファイルのクラスパスを指定します。

usrconf.cfgの格納場所

usrconf.cfgのひな型が次の場所に格納されていますので，このひな型ファイルを任意の場所にコピーして，使用してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥client¥templates¥usrconf.cfg

UNIXの場合

/opt/Cosminexus/CC/client/templates/usrconf.cfg

JavaVM起動オプションの指定

usrconf.cfgのadd.jvm.argキーに指定します。指定できるオプションの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.　JavaVM起動オプション」を参照してください。

JARファイルのクラスパスの指定

usrconf.cfgのadd.class.pathキーに指定します。クラスパスへの設定が必要なJARファイルについては，「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）に，プロパティを指定します。

usrconf.propertiesの格納場所

usrconf.propertiesのひな型が次の場所に格納されていますので，このひな型ファイルを任意の場所にコピーして，使用してください。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥client¥templates¥usrconf.properties

UNIXの場合

/opt/Cosminexus/CC/client/templates/usrconf.properties

プロパティの指定

プロパティで指定できる内容については，「3.3.5　EJBクライアントアプリケーションのプロパティの設定」を参照してください。また，必要に応じて，「3.5.3　EJBクライアントアプリケーションでのトランザクション実装時の注意事項」，「3.8　EJBクライアントアプリケーションのシステムログ出力」，およびマニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.10　EJBクライアントアプリケーションのユーザログ出力の設定（cjclstartapコマンドを使用する場合）」を参照してください。

指定できるプロパティの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

usrconf.cfgとusrconf.propertiesをcjclstartapコマンドを実行するカレントディレクトリ以外に格納した場合，環境変数「CJCLUSRCONFDIR」で，usrconf.cfgとusrconf.propertiesの格納場所の絶対パスを指定します。

作成したusrconf.cfgとusrconf.propertiesを同じディレクトリに格納して，そのディレクトリの絶対パスを環境変数「CJCLUSRCONFDIR」で指定してください。

なお，usrconf.cfgとusrconf.propertiesをcjclstartapコマンドを実行するカレントディレクトリに格納した場合はこの作業は必要ありません。手順5.に進んでください。

cjclstartapコマンドを使用してEJBクライアントアプリケーションを開始します。

cjclstartapコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjclstartap（Javaアプリケーションの開始）」を参照してください。

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，格納ディレクトリの「<Application Serverのインストールディレクトリ>¥CC」を，「<Application Serverのインストールディレクトリ>¥CCL」と読み替えてください。

なお，ejb.client.directory.shareableにfalseが設定されている場合，cjclstartapコマンドを実行すると，コマンドが使用するワークファイルが作成されます。ワークファイルが破損した場合，cjclstartapコマンド，またはcjcldumpapコマンドの動作は保証されません。ワークファイルの出力先，およびファイル名を次に示します。

Windowsの場合

<カレントディレクトリ>¥.cjclstartap.lock

<ejb.client.log.directory>¥.ejbclientlog.lock

<カレントディレクトリ>¥cjclstartap.pid

UNIXの場合

<カレントディレクトリ>/.cjclstartap.lock

<ejb.client.log.directory>/.ejbclientlog.lock

<カレントディレクトリ>/cjclstartap.pid

<カレントディレクトリ>/.COSMINEXUS_CC_EJBCLIENT_プロセスID

参考

cjclstartapコマンドを使用すると，Javaアプリケーションも開始できます。cjclstartapコマンドを使用したJavaアプリケーションの開始方法については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjclstartap（Javaアプリケーションの開始）」を参照してください。

3.3.3　vbjコマンドの場合

vbjコマンドによるEJBクライアントアプリケーションの開始の流れを次に示します。なお，バッチファイルまたはシェルスクリプトファイルを使用してEJBクライアントアプリケーションを実行する場合は，バッチファイルまたはシェルスクリプトファイルにこれらの内容を記述できます。

EJBクライアントアプリケーションの実行に必要な環境変数を設定します。

EJBクライアントアプリケーションの実行に必要な環境変数のうち，vbjコマンドでの実行に必要な環境変数を設定してください。必要な環境変数については，「3.3.4　EJBクライアントアプリケーションの実行に必要な環境変数の設定」を参照してください。

JavaVM起動オプションを指定します。

vbjコマンドに適切なJavaVM起動オプションを指定します。指定できるオプションの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「14.　JavaVM起動オプション」を参照してください。

JARファイルのクラスパスを指定します。

vbjコマンドに適切なクラスパスを指定します。必要なクラスパスについては，「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

プロパティを指定します。

プロパティで指定できる内容については，「3.3.5　EJBクライアントアプリケーションのプロパティの設定」を参照してください。また，必要に応じて，「3.8　EJBクライアントアプリケーションのシステムログ出力」，「3.5.3　EJBクライアントアプリケーションでのトランザクション実装時の注意事項」，およびマニュアル「アプリケーションサーバ 機能解説 拡張編」の「8.11　EJBクライアントアプリケーションのユーザログ出力の実装と設定（vbjコマンドを使用する場合）」を参照してください。

指定できるプロパティの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

vbjコマンドを使用してEJBクライアントアプリケーションを開始します。

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，格納ディレクトリの「<Application Serverのインストールディレクトリ>¥CC」を，「<Application Serverのインストールディレクトリ>¥CCL」と読み替えてください。

3.3.4　EJBクライアントアプリケーションの実行に必要な環境変数の設定

この節では，EJBクライアントアプリケーションの環境変数の設定について説明します。EJBクライアントアプリケーションの実行に必要な環境変数を次に示します。

なお，スタンドアロンプログラム実行機能としてcjclstartapコマンドを使用する場合も，環境変数の指定が必要です。

表3‒6　EJBクライアントアプリケーションの実行に必要な環境変数（Windowsの場合）

環境変数

値

コマンド

cjclstartap

vbj

PATH※1

<Application Serverのインストールディレクトリ>¥jdk¥bin

−

○

<Application Serverのインストールディレクトリ>¥TPB¥bin

○

−

<Application Serverのインストールディレクトリ>¥PRF¥bin

−

○

VBROKER_ADM

<Application Serverのインストールディレクトリ>¥TPB¥adm

○

○

PRFSPOOL※2

<Application Serverのインストールディレクトリ>¥PRF¥spool

▲

▲

TZ

JST-9　など

○

○

（凡例）

○：コマンドに環境変数を指定する必要がある。設定は必須である。

▲：インストーラによって設定される。設定は任意である。

−：設定する必要がない。

注※1

環境変数「PATH」の先頭に「<Application Serverのインストールディレクトリ>¥jdk¥bin」を指定してください。

注※2

インストーラによって設定されるPRFSPOOL環境変数配下には，Performance Tracerのログが出力されますが，EJBクライアントアプリケーションを実行するマシンにPRFデーモンを配置しない場合，モジュールトレースが単調増加してしまいます。

PRFデーモンを配置しない場合は，PRFSPOOL環境変数を設定しないでください。具体的には次のどちらかの方法を実行してください。

・システム環境変数からPRFSPOOL環境変数を削除する。

・EJBクライアント実行時に，PRFSPOOL環境変数を無効にする。

表3‒7　EJBクライアントアプリケーションの実行に必要な環境変数（UNIXの場合）

環境変数

値

コマンド

cjclstartap

vbj

LIBPATH，またはLD_LIBRARY_PATH※1

/opt/Cosminexus/TPB/lib

/opt/Cosminexus/PRF/lib

○

○

PATH※2

/opt/Cosminexus/jdk/bin

−

○

/opt/Cosminexus/TPB/bin

○

−

/bin

/usr/bin

−

○

VBROKER_ADM

/opt/Cosminexus/TPB/adm

○

○

PRFSPOOL※3

/opt/Cosminexus/PRF/spool

△

△

TZ

JST-9　など

○

○

（凡例）

○：コマンドに環境変数を指定する必要がある。設定は必須である。

△：設定は任意である。

−：設定する必要がない。

注※1

OSによって，使用する環境変数名が異なります。

LIBPATH：AIXの場合

LD_LIBRARY_PATH：Linuxの場合

注※2

環境変数「PATH」の先頭に「/opt/Cosminexus/jdk/bin」を指定してください。

注※3

PRFSPOOL環境変数配下にはPerformance Tracerのログが出力されますが，EJBクライアントアプリケーションを実行するマシンにPRFデーモンを配置しない場合，モジュールトレースが単調増加してしまいます。

PRFデーモンを配置しない場合はPRFSPOOL環境変数を設定しないでください。具体的には，EJBクライアント実行時に，PRFSPOOL環境変数を無効にしてください。

実行環境がAIXの場合は，上記の表に示す環境変数とは別に，AIX固有の環境変数を設定する必要があります。詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「付録H.2　AIX固有の環境変数」を参照してください。

3.3.5　EJBクライアントアプリケーションのプロパティの設定

EJBクライアントアプリケーションでは，使用する機能に応じたプロパティを設定できます。EJBクライアントアプリケーションで設定できるプロパティについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

3.4　Enterprise Beanの呼び出し

この節では，EJBクライアントアプリケーションからEnterprise Beanを呼び出す方法，およびメソッドの呼び出しで通信障害が発生したときの，クライアント側の動作設定について説明します。

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

表3‒8　この節の構成（Enterprise Beanの呼び出し）

分類

タイトル

参照先

解説

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

3.4.1

実装

Enterprise Beanを呼び出すための実装

3.4.2

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

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

EJBホームオブジェクトのリファレンスを検索，取得する場合を例に，Enterprise Beanを呼び出す流れを示します。

図3‒1　EJBクライアントアプリケーションからホームインタフェースを利用してEnterprise Beanを呼び出す流れ

EJBクライアントアプリケーションからホームインタフェースを利用してEnterprise Beanを呼び出すには，JNDIを利用してEJBホームオブジェクトのリファレンスを取得することで実現します。したがって，EJBクライアントアプリケーションでJNDIネーミングコンテキストを生成し，EJBホームオブジェクトのリファレンスを検索できるように実装する必要があります。Enterprise Beanの呼び出しの詳細については，「3.4.2　Enterprise Beanを呼び出すための実装」を参照してください。また，EJBクライアントアプリケーションは通信手段にRMI-IIOPを利用するため，RMI-IIOPのスタブやインタフェースを参照できるようにしておく必要があります。RMI-IIOPのスタブやインタフェースの取得については，「3.7　RMI-IIOPスタブ，インタフェースの取得」を参照してください。

3.4.2　Enterprise Beanを呼び出すための実装

EJBクライアントアプリケーションからEnterprise Beanを呼び出すには，JNDIを利用します。ここでは，EJBホームオブジェクトのリファレンスをルックアップする場合，およびビジネスインタフェースのリファレンスをルックアップする場合に分けて，Enterprise Beanを呼び出す方法を説明します。

(1)　EJBホームオブジェクトのリファレンスを検索してEnterprise Beanを呼び出す方法

EJBホームオブジェクトのリファレンスをルックアップしてEnterprise Beanを呼び出す方法を，実装例を基に説明します。

(a)　JNDIネーミングコンテキストの生成

EJBホームオブジェクトのリファレンスのルックアップに利用するJNDIネーミングコンテキストを生成します。

javax.naming.Context ctx = new javax.naming.InitialContext();

(b)　EJBホームオブジェクトのリファレンスの検索と取得

生成したJNDIネーミングコンテキストを利用して，EJBホームオブジェクトのリファレンスを取得します。EJBホームオブジェクトのリファレンスを取得するには，自動的にバインドされる名称（Portable Global JNDI名またはHITACHI_EJBから始まる名称），またはユーザ指定名前空間機能を利用して付与した名称でルックアップします。次の例では，ユーザ指定名前空間を利用してルックアップして，取得しています。ルックアップの方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.3　JNDI名前空間へのオブジェクトのバインドとルックアップ」を参照してください。

String ejbName = "MySample";
java.lang.Object obj = ctx.lookup(ejbName);
SampleHome sampleHome =
  (SampleHome)javax.rmi.PortableRemoteObject.narrow(obj, SampleHome.class);

(c)　Enterprise Beanの生成とメソッドの呼び出し

EJBホームオブジェクトのcreateメソッドによって，Enterprise Beanのインスタンスを生成します。これによって，アプリケーションに必要となるEnterprise Beanのメソッドを呼び出せるようになります。

Sample remoteSample = sampleHome.create(); //Enterprise Beanインスタンスの生成
String result = remoteSample.getData("data"); //ビジネスメソッドの呼び出し

なお，Entity BeanでCollection型が返されるfindメソッドを利用する場合は，コレクションから取り出したオブジェクトに対して，Enterprise Beanのクラスでナロウする必要があります。

Collection c = home.findByXXX(keyValue);
Iterator i=c.iterator();
while (i.hasNext()) {
  Sample remoteSample=(Sample)javax.rmi.PortableRemoteObject.narrow(i.next(), Sample.class);
                //RemoteSampleに対してビジネスメソッドを呼び出します。
}

(2)　ビジネスインタフェースのリファレンスを検索してEnterprise Beanを呼び出す方法

ビジネスインタフェースのリファレンスをルックアップしてEnterprise Beanを呼び出す方法を，実装例を基に説明します。

(a)　InitialContextの生成

ビジネスインタフェースを使用してEnterprise Beanを呼び出すには，最初にInitialContextを生成します。

// InitialContextを生成
InitialContext ctx = new InitialContext();

(b)　ビジネスインタフェースのリファレンスの検索と取得

生成したInitialContextを利用して，ビジネスインタフェースのリファレンスを取得します。ビジネスインタフェースのリファレンスを取得するには，自動的にバインドされる名称またはユーザ指定名前空間機能を利用して付与した名称でルックアップします。自動的にバインドされる名称を使用したビジネスインタフェースのルックアップの方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.5　HITACHI_EJBから始まる名称でのルックアップ」を参照してください。

// ビジネスインタフェースのリファレンスを取得
Sample sample = (Sample)ctx.lookup("HITACHI_EJB/SERVERS/MyServer/EJBBI/SampleApp/Sample");

(c)　メソッドの呼び出し

ビジネスインタフェースのリファレンスを取得したことで，ビジネスメソッドを呼び出せるようになります。

// ビジネスメソッドの呼び出し
String result = sample.getData("data");

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

この節では，EJBクライアントアプリケーションでのトランザクションの実装について説明します。

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

表3‒9　この節の構成（EJBクライアントアプリケーションでのトランザクションの実装）

分類

タイトル

参照先

実装

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

3.5.1

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

3.5.2

注意事項

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

3.5.3

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

ポイント

「解説」と「設定」については，それぞれ次の説明を参照してください。

解説：

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.　リソース接続とトランザクション管理」

設定：

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.19　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，EJBクライアントアプリケーションのトランザクションは使用できません。

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

ここでは，EJBクライアントでトランザクションを使用する場合の手順を説明します。

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よりも後ろに追加してください。

EJBクライアントアプリケーション起動時に必要なシステムプロパティを追加します。

システムプロパティの追加方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.19　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」を参照してください。

EJBクライアントアプリケーションのプロセスの起動直後に，EJBクライアントアプリケーションに実装したユーザコードから，サービスの初期化処理を実行します。

サービスの初期化処理を実行するには，EJBClientInitializerクラス（com.hitachi.software.ejb.ejbclient.EJBClientInitializer）を呼び出します。

なお，EJBClientInitializerクラスのinitializeメソッドを呼び出す前に，javax.naming.InitialContextを生成した場合や，UserTransactionFactoryクラスのgetUserTransactionメソッドを呼び出した場合は，その時点で初期化処理が行われます。このため，EJBClientInitializerクラスによる初期化処理は不要です。

EJBClientInitializerクラスの文法や機能については，マニュアル「アプリケーションサーバ リファレンス API編」の「4.2　EJBClientInitializerクラス」を参照してください。

UserTransactionオブジェクトを取得します。

UserTransactionの取得方法には，次の2種類があります。

UserTransactionFactoryクラスを使用する

com.hitachi.software.ejb.ejbclient.UserTransactionFactoryクラスのgetUserTransactionメソッドを使用して取得します。UserTransactionFactoryクラスの文法や機能については，マニュアル「アプリケーションサーバリファレンス API編」の「4.5　UserTransactionFactoryクラス」を参照してください。

ルックアップを使用する

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

EJBクライアントでは，UserTransactionFactoryクラスを使用する方法を推奨しています。ただし，他社のアプリケーションサーバからの移行などによって，EJBクライアントアプリケーションのソースコードを変更できない場合は，ルックアップを使用します。

Enterprise Beanを呼び出すスレッドから，UserTransactionインタフェースのbeginメソッドを呼び出し，トランザクションを開始します。

サーバ上のEnterprise Beanを呼び出します。

Enterprise Beanを呼び出したスレッドから，UserTransactionインタフェースのcommitメソッドまたはrollbackメソッドを呼び出して，トランザクションを決着します。

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

EJBクライアントアプリケーションからUserTransactionをルックアップする場合に指定する検索文字列を示します。

HITACHI_EJB/SERVERS/<サーバ名称>/SERVICES/UserTransaction

ルックアップの結果によって得られるオブジェクトは，java.lang.Object型であるため，javax.transaction.UserTransaction型にキャストして使用します。

また，ルックアップに失敗した場合，javax.naming.NamingException例外が発生します。

UserTransaction型へのキャストや例外については，J2EEサーバ上のWebアプリケーションやEnterprise BeanからUserTransactionをルックアップする場合と同様の仕様となります。

注意事項

次に示す環境でのUserTransactionのルックアップはサポートされません。

CTM連携時に使用するグローバルネーミングサービスに対するUserTransactionのルックアップ

ラウンドロビン検索機能などで使用されるユーザ指定名前空間管理機能を使用したUserTransactionのルックアップ

この環境でUserTransactionを使用する場合は，UserTransactionFactoryクラスを使用してUserTransactionを取得してください。

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

EJBクライアントでトランザクションを実装する場合の注意事項を示します。

サービスの初期化処理で例外が発生した場合は，システムプロパティが正しく設定されていない可能性があります。例外のメッセージに従って対処してください。

呼び出されるEnterprise Beanを，コンテナ管理のトランザクション（CMT）でmandatory，required，supportsなどの属性にすれば，EJBクライアントアプリケーションで開始したトランザクションの範囲内で実行されます。

EJBクライアントアプリケーションが，トランザクション処理中に障害などの理由でダウンした場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を行う必要があります。EJBクライアントアプリケーションの再起動後に，EJBClientInitializerクラスのinitializeメソッドを呼び出し，グローバルトランザクションのリカバリ処理が開始するように設計してください。なお，リカバリ処理はバックグラウンドで実行されるため，initializeメソッドはリカバリ処理の完了を待たないでリターンします。

EJBクライアントアプリケーションでトランザクションを開始している場合は，必ずすべてのトランザクションを決着してから，EJBクライアントアプリケーションのプロセスが停止するように設計してください。トランザクションの決着処理を待たないでEJBクライアントアプリケーションのプロセスを停止すると，プリペア状態のトランザクションが決着されないまま残るおそれがあります。この状態になると，アプリケーションサーバの正常停止やリソースアダプタの停止ができなくなります。また，リソースのロックが解放されない場合があります。

万一，プリペア状態のトランザクションが残ってしまった場合は，EJBクライアントアプリケーションを再起動して，グローバルトランザクションのリカバリ処理を行う必要があります。

EJBクライアントアプリケーションでは，JTAやOTSが出力する性能解析トレースに，ルートアプリケーション情報やクライアントアプリケーション情報が含まれていません。リクエストをトレースする場合は，スレッドのハッシュコードやXIDの情報を使用してください。なお，トランザクションタイムアウトが発生した時に出力されるメッセージには，ルートアプリケーション情報の代わりに，トランザクションを開始したスレッドのハッシュコードが含まれています。

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

この節では，EJBクライアントアプリケーションでのセキュリティの実装について説明します。

EJBクライアントアプリケーションでは，J2EEサーバで定義されたユーザとパスワードを使用してユーザを認証できます。EJBクライアントアプリケーションからユーザを認証してログインすると，セキュリティロールが設定されたEnterprise Beanのメソッドを呼び出せます。

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

表3‒10　この節の構成（EJBクライアントアプリケーションでのセキュリティの実装）

分類

タイトル

参照先

実装

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

3.6.1

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

3.6.2

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

ポイント

「解説」については，次の説明を参照してください。

解説：

マニュアル「アプリケーションサーバ 機能解説 セキュリティ管理機能編」の「6.　アプリケーションの設定による認証」

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

EJBクライアントアプリケーションでのセキュリティは，Application Serverが提供するAPIを使用して実装します。ここでは，セキュリティを実装する場合の前提条件および実装方法を示します。APIの機能と文法については，マニュアル「アプリケーションサーバリファレンス API編」の「4.　EJBクライアントアプリケーションで使用するAPI」を参照してください。

セキュリティを実装する前に，次の前提条件を満たしているか確認してください。

J2EEサーバ側にユーザが登録されている必要があります。

登録されているユーザにセキュリティロールが設定されている必要があります。

(1)　セキュリティの実装方法

EJBクライアントアプリケーションでセキュリティを実装する場合，次の手順で処理を実装します。

セキュリティAPIのパッケージをインポートします。

セキュリティAPIを利用するために，次に示すパッケージをインポートします。

import com.hitachi.software.ejb.security.base.authentication.*

LoginInfoManagerのオブジェクトを取得します。

Enterprise Beanのメソッドを呼び出すプログラム上でLoginInfoManagerオブジェクトを取得します。取得にはLoginInfoManagerオブジェクトに用意されているスタティックメソッドのgetLoginInfoManagerメソッドを使用します。

LoginInfoManager  lm = LoginInfoManager.getLoginInfoManager();

ユーザ名とパスワードでログインします。

LoginInfoManagerオブジェクト取得後，loginメソッドを呼び出します。

lm.login(username, password);

Enterprise Beanのメソッドを呼び出します。

loginメソッド成功後，Enterprise Beanのメソッドを呼び出します。

ログアウトします。

Enterprise Beanのメソッド呼び出しが終了したあと，logoutメソッドでJ2EEサーバからログアウトします。

lm.logout();

注意事項

EJBクライアントアプリケーションでセキュリティを実装する場合，HiEJBClientStatic.jarをクラスパスに追加してコンパイルする必要があります。

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

Enterprise Bean名がaccountの場合に，getAccountIDメソッドを呼び出すサンプルプログラムを次に示します。

import com.hitachi.software.ejb.security.base.authentication.*;
    :
  try {
    LoginInfoManager lm = LoginInfoManager.getLoginInfoManager();
    String userName = System.getProperty("username");
    String password = System.getProperty("password");
    if(lm.login(userName , password)) {
      try {
        System.out.println("user:" + userName + "login success");
        Context ctx = new InitialContext();
        java.lang.Object obj = ctx.lookup(appUnitPath + "Account");
        AccountHome aHome =
           (AccountHome)PortableRemoteObject.narrow(obj,AccountHome.class);
        Account account  = aHome.create();
        account.getAccountID();
      } finally {
        lm.logout();
      }
    }
  } catch(NotFoundServerException e) {
    System.out.println("not found server");
  } catch(InvalidUserNameException e) {
    System.out.println("invalid user name");
  } catch(InvalidPasswordException e) {
    System.out.println("invalid password");
  } catch(Exception e) {
    e.printStackTrace();
  }

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

この節では，RMI-IIOPスタブ，およびインタフェースの取得について説明します。

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

表3‒11　この節の構成（RMI-IIOPスタブ，インタフェースの取得）

分類

タイトル

参照先

解説

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

3.7.1

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

3.7.2

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

3.7.3

設定

EJBクライアントアプリケーションのクラスパスへのJARファイルの設定

3.7.4

注意事項

Client使用時の注意

3.7.5

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

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

EJBクライアントアプリケーションは，TPBrokerのRMI-IIOPの機能を利用してアプリケーションを呼び出します。

EJBホームオブジェクトのリファレンスを検索，取得する場合，EJBクライアントアプリケーションは次に示すスタブおよびクラスを参照できるようにする必要があります。

Enterprise BeanのEJBオブジェクトのスタブ

Enterprise BeanのEJBホームオブジェクトのスタブ

スタブが利用する各種クラス

また，EJBクライアントアプリケーションからは，次に示すインタフェース，および各種クラスを参照できるようにする必要があります。

リモートインタフェース

ホームインタフェース

インタフェースが参照する各種クラス

ビジネスインタフェースを使用してEnterprise Beanを呼び出す場合は，ビジネスインタフェース，およびビジネスインタフェースを呼び出すためのクラスを参照できるようにする必要があります。

これらのクラス（RMI-IIOPスタブ，RMI-IIOPインタフェース）は，サーバ管理コマンドまたはダイナミッククラスローディングを使用してダウンロードします。

注意事項

サーバ管理コマンドとダイナミッククラスローディングの使い分け

ダイナミッククラスローディングを使用するよりも，サーバ管理コマンドを使用して呼び出しに必要なクラスをダウンロードした方が性能上優れています。したがって，実運用ではサーバ管理コマンドの使用を推奨します。一方，開発，テスト時にはスタブの取得と更新に手間の掛からない，ダイナミッククラスローディングの使用を推奨します。

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

サーバ管理コマンドのcjgetstubsjarコマンドでRMI-IIOPスタブおよびRMI-IIOPインタフェースをダウンロードできます。cjgetstubsjarコマンドの使用方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「10.7　RMI-IIOPスタブとインタフェースの取得」を参照してください。

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

RMI-IIOPスタブをクラスパスに指定しないで，EJBクライアントアプリケーションを開始します。EJBクライアントアプリケーションがEnterprise Beanを呼び出したときにRMI-IIOPスタブおよびRMI-IIOPインタフェースが自動的に読み込まれます。

RMI-IIOPスタブのダイナミッククラスローディングを利用する場合の手順を示します。

簡易構築定義ファイルを編集します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，ejbserver.DynamicStubLoading.Enabledパラメタで「true」を指定します。

該当するJ2EEサーバを再開始します。

J2EEサーバを開始します。J2EEアプリケーションが開始済みの場合は，一度停止してから再開始してください。

注意事項

ダイナミッククラスローディング使用上の注意事項を次に示します。

ダイナミッククラスローディングを使用する場合，同じJ2EEサーバ内で，同じパッケージ名称，インタフェース名称のEnterprise Beanを持つJ2EEアプリケーションを複数開始できません。なお，インタフェースの継承元となる親クラス名称が同じ場合もJ2EEアプリケーションを複数開始できません。ここでの継承元となる親クラスとは，ユーザが作成するクラスであり，J2SEやJ2EEが提供するクラスではありません。

クライアントプログラムのクラスパスにスタブを指定していない場合，シリアライズされたEnterprise BeanオブジェクトのHandle（javax.ejb.Handle）を復元できません。

CTMのグローバルCORBAネーミングサービスをルックアップする場合には，ダイナミッククラスローディング機能は使用できません。

cjstartsvコマンドに-nosecurityオプションを指定してJ2EEサーバを起動した場合，J2EEサーバ上で動作するJ2EEアプリケーションがEJBクライアントとして動作するとき，ダイナミッククラスローディングは使用できません。

3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定

ここでは，EJBクライアントアプリケーションのクラスパスへのJARファイルの設定方法について説明します。EJBクライアントアプリケーションの開始に使用するコマンドによって，クラスパスへのJARファイルの設定方法が異なります。

cjclstartapコマンドの場合

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのオプション定義ファイル（usrconf.cfg）で，クラスパスにJARファイルを設定します。

usrconf.cfg（Javaアプリケーション用オプション定義ファイル）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.1　usrconf.cfg（Javaアプリケーション用オプション定義ファイル）」を参照してください。

vbjコマンドの場合

vbjコマンドを使用する場合は，バッチファイル/シェルスクリプトファイル，またはコマンドの引数で設定します。

EJBクライアントアプリケーションの実行に必要なJARファイルを次の表に示します。

表3‒12　EJBクライアントアプリケーションの実行に必要なJARファイル

JARファイル名

［種別］※JARファイルの配置場所

含まれる内容

コマンド

cjclstartap

vbj

hitj2ee.jar

［固定］

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/lib

製品提供クラス

−

○

HiEJBClientStatic.jar

［固定］

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/client/lib

製品提供クラス

−

○

vbjorb.jar

vbsec.jar

［固定］

Windowsの場合

<Application Serverのインストールディレクトリ>¥TPB¥lib

UNIXの場合

/opt/Cosminexus/TPB/lib

製品提供クラス

−

○

cprf.jar

［固定］

Windowsの場合

<Application Serverのインストールディレクトリ>¥PRF¥lib

UNIXの場合

/opt/Cosminexus/PRF/lib

製品提供クラス

−

○

hntrlibMcsmj64.jar

［固定］

Windowsの場合

<Application Serverのインストールディレクトリ>¥common¥lib

UNIXの場合

/opt/Cosminexus/CC/common/lib

製品提供クラス

−

○

tpotsinproc.jar

［トランザクション使用］

Windowsの場合

<Application Serverのインストールディレクトリ>¥TPB¥lib

UNIXの場合

/opt/Cosminexus/TPB/lib

製品提供クラス

−

△

ejbserver.jar

［トランザクション使用］または［J2EEサーバ例外］

Windowsの場合

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

UNIXの場合

/opt/Cosminexus/CC/lib

△

△

stubs.jar

［RMI-IIOPのスタブ］

J2EEサーバからダウンロード，またはダイナミッククラスローディング

RMI-IIOPのスタブ

EJBオブジェクトのスタブ

EJBホームオブジェクトのスタブ

スタブが参照するクラス

△

△

<数字>.jar

［RMI-IIOPのインタフェース］

J2EEサーバからダウンロード

RMI-IIOPのインタフェース

リモートインタフェース

ホームインタフェース

インタフェースが参照するクラス

○

○

ユーザ作成のJARファイル

ユーザ作成のクラス

EJBクライアントアプリケーションで利用するユーザ作成のクラスです。

ユーザが作成した独自のFilterクラス，Formatterクラス，またはHandlerクラスをEJBクライアントアプリケーションのユーザログ機能で使用する場合には，そのクラスもクラスパスに指定してください。※3

○

○

（凡例）

○：クラスパスに指定する必要がある。

△：必要に応じてクラスパスに指定する。

−：クラスパスに指定する必要がない。

注※

種別には，次に示すものがあります。

［固定］

EJBクライアントアプリケーションから呼び出すアプリケーションの数，内容に関係なく，指定するJARファイルのファイル名と配置場所は固定です。

［トランザクション使用］

EJBクライアントアプリケーションでトランザクションを使用する場合に，該当するJARファイルを指定します。詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.19　EJBクライアントアプリケーションでトランザクションを開始する場合の注意事項」を参照してください。

［RMI-IIOPのスタブ］

EJBクライアントアプリケーションから呼び出すアプリケーション単位に該当するJARファイルを指定します。ダイナミッククラスローディングを利用する場合は，指定する必要はありません。

［RMI-IIOPのインタフェース］

RMI-IIOPのインタフェースをEJBクライアントアプリケーション側に取得していない場合，アプリケーション単位に該当するJARファイルをダウンロードして指定します。すでにRMI-IIOPのインタフェースをEJBクライアントアプリケーション側に取得している場合は，取得済みのクラスまたはJARファイルを指定します。

［J2EEサーバ例外］

J2EEアプリケーションが受け取った例外をそのままEJBクライアントアプリケーションへ伝播するようなアプリケーション構成では，該当するJARファイルが必要となる場合があります。ただし，このようなアプリケーションの構成は推奨されません。J2EEアプリケーションで発生した例外を伝播する場合は新たにEJBクライアントアプリケーションに向けた例外を再作成して返却するように設計してください。

注意事項

Clientを使用してEJBクライアント環境を構築する場合は，格納ディレクトリの「<Application Serverのインストールディレクトリ>¥CC」を，「<Application Serverのインストールディレクトリ>¥CCL」と読み替えてください。

Clientを使用してEJBクライアント環境を構築する場合は，EJBクライアントアプリケーションのトランザクションは使用できません。

クラスパスでJARファイルを設定する場合，JARファイルの設定順序に注意してください。

トランザクションを使用する場合，クラスパスには，tpotsinproc.jarとejbserver.jarを設定します。このとき，ejbserver.jarよりも先に，HiEJBClientStatic.jarを設定してください。

性能解析トレース機能を利用する場合，クラスパスには，cprf.jarを設定します。このとき，HiEJBClientStatic.jarよりも先にcprf.jarを設定してください。

逆の順序で設定した場合は，性能解析トレースの初期化に失敗します。また，逆の順序で設定した場合に，EJBクライアントアプリケーションのログレベルをWarning以上に設定しているときは，KDJE51008-Wのメッセージが理由コード「-4」で出力されます。なお，性能解析トレースの初期化に失敗した場合は，性能解析トレースは出力されませんが，EJBクライアントアプリケーションの処理は継続できます。

3.7.5　Client使用時の注意

Clientにはcjgetstubsjarコマンドは含まれていないため，サーバ管理コマンドで取得できません。ClientでRMI-IIOPのスタブを手動で取得する場合の手順を次に示します。

Application Serverが稼働するマシンでcjgetstubsjarコマンドを実行し，RMI-IIOPのスタブとインタフェースのファイルを任意のディレクトリに置きます。

Clientが稼働するマシンからApplication Serverが稼働するマシンにアクセスし，ファイル転送などの方法でRMI-IIOPのスタブとインタフェースのファイルをダウンロードします。

3.8　EJBクライアントアプリケーションのシステムログ出力

この節では，EJBクライアントアプリケーションのシステムログ出力について説明します。

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

表3‒13　この節の構成（EJBクライアントアプリケーションのシステムログ出力）

分類

タイトル

参照先

解説

EJBクライアントアプリケーションのシステムログの概要

3.8.1

システムログの出力先のサブディレクトリ

3.8.2

設定

システムログの出力先や出力レベルの変更

3.8.3

複数プロセスでのログ出力先のサブディレクトリの共有

3.8.4

ログ出力先ディレクトリのアクセス権の設定

3.8.5

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

3.8.1　EJBクライアントアプリケーションのシステムログの概要

EJBクライアントアプリケーションのシステムログでは，メッセージログ，例外ログ，保守用ログの3種類のログが出力されます。EJBクライアントアプリケーションでは，必要に応じて，システムログの出力先や出力レベル，出力先のサブディレクトリの設定を変更できます。

3.8.2　システムログの出力先のサブディレクトリ

EJBクライアントアプリケーションのシステムログは，EJBクライアントアプリケーションのプロセス単位で出力されます。システムログでは，複数のプロセスでログ出力先のサブディレクトリを共有することができます。この動作モードのことをサブディレクトリ共有モードといいます。

サブディレクトリ共有モードの動作を次の表に示します。

表3‒14　サブディレクトリ共有モードの動作

項目

サブディレクトリ共有モード

複数のプロセスでのサブディレクトリ共有の可否

共有できます。

ログ管理ファイル作成

作成されます。

ejbserver.client.ejb.logキー※のデフォルト値

system

ejbserver.client.log.appidキー※のデフォルト値

ejbcl

ejbserver.client.log.directorynumキー※の指定

常に無効です。

ejbserver.logger.channels.define.<チャネル名>.filenumキー※に指定できる面数

1〜64

ejbserver.logger.channels.define.<チャネル名>.filesizeキー※に指定できる容量（バイト）

4,096〜16,777,216

注※　EJBクライアントアプリケーションの開始時に指定するシステムプロパティです。

注意事項

cjclstartapコマンドでEJBクライアントアプリケーションを実行する場合は，サブディレクトリ共有モードを使用してください。

EJBクライアントアプリケーションのユーザログ機能を使用する場合は，サブディレクトリ共有モードを使用してください。

動作モードの指定

サブディレクトリ共有モードを使用するためのクラスパスの指定については，「3.7.4　EJBクライアントアプリケーションのクラスパスへのJARファイルの設定」を参照してください。

サブディレクトリの共有

サブディレクトリ共有モードを使用している場合は，ログ出力先のサブディレクトリを共有できます。サブディレクトリの共有については，「3.8.4　複数プロセスでのログ出力先のサブディレクトリの共有」を参照してください。

3.8.3　システムログの出力先や出力レベルの変更

(1)　システムログの設定方法

EJBクライアントアプリケーションの開始に使用するコマンドによって，EJBクライアントアプリケーションのシステムログの設定方法が異なります。

cjclstartapコマンドの場合

cjclstartapコマンドを使用する場合は，EJBクライアントアプリケーションのプロパティファイル（usrconf.properties）で，システムログのプロパティを設定します。

vbjコマンドの場合

vbjコマンドを使用する場合は，バッチファイル/シェルスクリプトファイル，またはコマンドの引数で，システムログのプロパティを設定します。

(2)　システムログの出力先や出力レベルの設定

Javaアプリケーション用オプション定義ファイル（usrconf.cfg），またはJavaアプリケーション用ユーザプロパティファイル（usrconf.properties）をカスタマイズすることで，EJBクライアントアプリケーションのシステムログの属性を変更できます。変更できる項目と，変更を設定するプロパティのキーを次の表に示します。また，この表では，EJBクライアントアプリケーションの実行コマンドに指定するプロパティの指定の要否についても説明します。

表3‒15　EJBクライアントアプリケーションのシステムログの出力先や出力レベルを変更するキー

変更できる項目

Javaアプリケーション用オプション定義ファイルのキー

Javaアプリケーション用ユーザプロパティファイルのキー

種別

ログの出力先※1

ejb.client.log.directory

ejbserver.client.log.directory

可変

EJBクライアントアプリケーション単位で作成されるログ出力先ディレクトリ名※1

ejb.client.ejb.log

ejbserver.client.ejb.log

選択可変

EJBクライアントアプリケーションのプロセス単位で作成されるログ出力先サブディレクトリ名※1

ejb.client.log.appid

ejbserver.client.log.appid

選択可変

標準出力へのメッセージ出力停止※2

ejb.client.log.stdout.enabled

−

選択可変

ログファイル面数

−

ejbserver.logger.channels.define.<チャネル名※3>.filenum

選択可変

ログファイルサイズ

−

ejbserver.logger.channels.define.<チャネル名※3>.filesize

選択可変

ログの出力レベル※4

−

ejbserver.logger.enabled.*

選択可変

TPBrokerのトレースファイルの出力先

−

vbroker.orb.htc.tracePath

選択可変

TPBrokerのトレースファイルの個数

−

vbroker.orb.htc.comt.fileCount

選択可変

TPBrokerのトレースファイル1個当たりのエントリ数

−

vbroker.orb.htc.comt.entryCount

選択可変

（凡例）

可変：システムの実行環境に従って値を指定する必要がある。

選択可変：システムの実行環境に従って値を指定するか，または指定を省略する。

−：設定できない。

注※1

usrconf.cfgでは，稼働ログ，ログ稼働ログ，障害発生時の例外情報，および保守情報の設定を変更できます。

また，usrconf.cfgとusrconf.propertiesで同じ項目が設定された場合，usrconf.propertiesで設定した内容が優先されます。

注※2

稼働ログ，cjclstartapコマンドログ，および起動プロセス標準出力情報のメッセージを標準出力に出力しないように設定できます。

注※3

チャネル名として，ログの種類を示す次の名称が設定されます。

ClientMessageLogFile（稼働ログ）（ファイル名：cjclmessage[n].log）

ClientExceptionLogFile（障害発生時の例外情報）（ファイル名：cjclexception[n].log）

ClientMaintenanceLogFile（保守情報）（ファイル名：cjclmaintenance[n].log）

注※4

シェルスクリプトを使用してシステムプロパティを設定する場合，ログの出力レベル（ejbserver.logger.enabled.*キー）は指定できません。

システムプロパティを指定できるかどうかは，EJBクライアントアプリケーションの使用形態によって異なる場合があります。EJBクライアントアプリケーションの使用形態とシステムプロパティの関係を次の表に示します。なお，表3-16と表3-17の番号は対応しています。

表3‒16　EJBクライアントアプリケーションの使用形態

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

EJBクライアントアプリケーションの同時起動の多重度

1多重

2〜8多重

9〜16多重

1種類

1.

2.

3.

2種類以上

4.

5.

6.

表3‒17　EJBクライアントアプリケーションの使用形態とシステムプロパティ

システムプロパティの指定

EJBクライアントアプリケーションの使用形態

1.

2.

3.

4.

5.

6.

ejbserver.client.ejb.log

可能

可能

必須

必須

必須

必須

ejbserver.client.log.appid

可能

不可

不可

可能

不可

不可

ejbserver.client.log.directorynum

可能

可能

必須

可能

可能

必須

上記表の番号について説明します。

ejbserver.client.ejb.logキーは，デフォルトディレクトリでもかまいません。

ejbserver.client.log.appidキーを指定した場合は，ejbserver.client.log.directorynumキーの指定は無効となります。

ejbserver.client.ejb.logキーは，デフォルトディレクトリでもかまいません。

複数同時に起動するため，ejbserver.client.log.appidキーは指定しないでください。ejbserver.client.log.directorynumキーを指定する場合は，必ずejbserver.client.ejb.logキーを指定してください。

ejbserver.client.ejb.logキーをEJBクライアントアプリケーションごとに必ず指定してください。複数同時に起動するため，ejbserver.client.log.appidキーを指定しないでください。ejbserver.client.log.directorynumキーの値を多重度に合わせて指定してください。

ejbserver.client.ejb.logキーをEJBクライアントアプリケーションごとに必ず指定してください。

ejbserver.client.log.appidキーを指定した場合は，ejbserver.client.log.directorynumキーの指定は無効となります。

ejbserver.client.ejb.logキーをEJBクライアントアプリケーションごとに必ず指定してください。複数同時に起動するため，ejbserver.client.log.appidキーを指定しないでください。

ejbserver.client.log.directorynumキーを指定する場合は，必ずejbserver.client.ejb.logキーを指定してください。

ejbserver.client.ejb.logキーをEJBクライアントアプリケーションごとに必ず指定してください。複数同時に起動するため，ejbserver.client.log.appidキーを指定しないでください。ejbserver.client.log.directorynumキーの値を多重度に合わせて指定してください。

3.8.4　複数プロセスでのログ出力先のサブディレクトリの共有

サブディレクトリ共有モードを使用している場合は，ログ出力先のサブディレクトリを共有できます。

EJBクライアントアプリケーションのシステムログは，EJBクライアントアプリケーション単位に作成されるログ出力先ディレクトリ（ejbserver.client.log.directoryキー，およびejbserver.client.ejb.logキーに指定したディレクトリ）下のサブディレクトリに格納されます。なお，サブディレクトリ名は，ejbserver.client.log.appidキーで指定できます。

サブディレクトリ共有モードを使用する場合，ログ出力先ディレクトリを指定するejbserver.client.ejb.logキーには，サブディレクトリ専有モードを使用する場合とは異なる値を指定してください。サブディレクトリ専有モードと同じ値を指定した場合には，サブディレクトリ専有モードでのログ出力先のサブディレクトリ数が管理できなくなります。なお，サブディレクトリ専有モードは旧バージョンとの互換用のモードです。

サブディレクトリ共有モードで動作するEJBクライアントがログの稼働情報（cjlogger.logファイル）にKDJE90002-Eメッセージを出力して終了する場合，またはKDJE90003-Eメッセージを出力する場合は，次に示すログファイルの排他に失敗しているおそれがあります。

稼働ログ

ユーザ出力ログ

ユーザエラーログ

障害発生時の例外情報

保守情報

ejbserver.client.log.lockRetryCount，およびejbserver.client.log.lockIntervalキーを使用してリトライ回数とリトライ間隔を大きくすることで，ログファイルの排他の失敗を回避できます。

また，cjclstartapコマンドが，KDJE40016-E（errnoが22），KDJE30043-E，KDJE40052-Eメッセージを標準エラー出力に出力した場合，次に示すログファイルの初期化時の排他処理に失敗しているおそれがあります。

cjclstartapコマンドの稼働ログ

起動プロセス標準出力情報

起動プロセス標準エラー情報

この場合，ejb.client.log.lockRetryCount，ejb.client.log.lockIntervalキーを使用して排他取得の総試行回数やリトライ間隔，タイムアウト時間を大きくすることで，ログファイルの排他処理の失敗を回避できます。

EJBクライアントアプリケーションのシステムログの取得については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.5　EJBクライアントアプリケーションのシステムログ」を参照してください。

注意事項

EJBクライアントアプリケーションを初回起動時に複数同時に起動すると，同時刻に起動したほかのEJBクライアントアプリケーションとログディレクトリ生成処理が衝突し，KDJE51003-Eメッセージを出力して異常終了する場合があります。EJBクライアントアプリケーションの初回起動時には複数同時に起動しないようにするか，あらかじめログ出力先ディレクトリを作成してください。

3.8.5　ログ出力先ディレクトリのアクセス権の設定

UNIXの場合，複数ユーザアカウントで同じログ出力先ディレクトリを使用してEJBクライアントアプリケーションを実行するときは，ログ出力先ディレクトリのアクセス権を設定する必要があります。

ログ出力先ディレクトリのモードを，グループやほかのすべてのユーザに対して書き込みを許可するように設定し，umaskを0に設定してからEJBクライアントアプリケーションを実行してください。

4　Enterprise Bean実装時の注意事項

この章では，Enterprise Beanを実装するときの注意事項について説明します。

4.1　この章の構成

この章では，アプリケーションサーバ上で動作するアプリケーションのプログラムとして，Enterprise Beanを実装するときの注意事項について説明します。

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

表4‒1　この章の構成（Enterprise Bean実装時の注意事項）

分類

タイトル

参照先

Enterprise Bean共通の注意事項

Enterprise Beanおよび関連するクラスの命名規則

4.2.1

リソースのコネクションの取得と解放

4.2.2

ローカルインタフェースとリモートインタフェースの使い分け

4.2.3

ローカル呼び出し最適化機能の利用について

4.2.4

ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法

4.2.5

ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法

4.2.6

クラスローダの取得に関する注意

4.2.7

URLConnectionクラス使用時の注意

4.2.8

ネイティブライブラリのロードに関する注意

4.2.9

Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて

4.2.10

Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について

4.2.11

javax.ejb.EJBContextインタフェースメソッドについての注意事項

4.2.12

Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて

4.2.13

EJBの仕様に関する注意

4.2.14

マルチバイト文字について

4.2.15

EJB3.0のAPIに関する注意

4.2.16

EJB 3.0以降のejb-jar.xmlに関する注意

4.2.17

ジェネリクスの使用に関する注意

4.2.18

EJB 3.1使用時の注意

4.2.19

getCause()メソッドについて

4.2.20

リソース参照の名称に関する注意

4.2.21

アプリケーションサーバのライブラリに関する注意

4.2.22

J2EEサーバとEJBクライアント間でJava SEのバージョンが異なる場合の注意事項

4.2.23

Enterprise Beanの種類ごとの注意事項

Stateless Session Bean実装時の注意事項

4.3.1

Stateful Session Bean実装時の注意事項

4.3.2

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

4.3.3

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

4.3.4

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

4.3.5

Singleton Session Bean実装時の注意事項

4.3.6

注　この章には，注意事項以外の説明はありません。

4.2　Enterprise Bean共通の注意事項

Enterprise Beanを実装するときの共通の注意事項を示します。

4.2.1　Enterprise Beanおよび関連するクラスの命名規則

Enterprise Beanクラス，ホームインタフェース，コンポーネントインタフェース，ビジネスインタフェース，インターセプタクラス，およびそれらで使用するクラスを実装する場合は，次に示す命名規則に従ってください。

Enterprise Beanおよび関連するクラスのクラス名と同じ名前で始まるパッケージに，それらのクラスを配置しないでください。

例えば，「Example.Example」のように，パッケージ名と同じ名称を持つクラスは配置できません。

「Wrappers.」で始まるパッケージ名は使用できません。

Enterprise Beanクラス，ホームインタフェース，コンポーネントインタフェース，およびビジネスインタフェースの名称では，英数字および記号を使用します。アンダースコア（_）で始まるメソッド名，およびメンバ変数名は使用できません。

次に示すメソッドをビジネスメソッドとして使用しないでください。使用した場合，アプリケーションの開始時にコンパイルエラーとなったり，EJBが不正に動作することがあります。

java.lang.Objectで定義された次のメソッド

equals(Object)，hashCode()，toString()，clone()，finalize()

javax.ejb.EJBObject，javax.ejb.EJBLocalObjectで定義された次のメソッド

getEJBHome()，getEJBLocalHome()，getHandle()，getPrimaryKey()，isIdentical(EJBLocalObject)，isIdentical(EJBObject)，remove()

Entity BeanのCMPではアンダースコア（_）で始まるCMPフィールド名，およびCMRフィールド名は指定できません。

大文字，小文字の違いだけのパッケージ名称，およびクラス名称は利用できません。RMI-IIOPでは大文字，小文字が区別されないため，Enterprise Beanに正常にアクセスできなくなるおそれがあります。

JARファイル中にあるホームインタフェースなど，java.rmi.Remoteを実装したクラスがあると，スタブは作業ディレクトリ内に生成されます。作業ディレクトリのパス長がプラットフォームの上限に達しないようにjava.rmi.Remoteを実装したクラスのパッケージ名やクラス名を指定してください。作業ディレクトリのパス長の見積もりについては，次に示すマニュアルの個所を参照してください。

J2EEサーバの場合

マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録C.1　J2EEサーバの作業ディレクトリ」

バッチサーバの作業ディレクトリ

マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録C.2　バッチサーバの作業ディレクトリ」

EJB-JARファイルが別の場合でも，同じアプリケーション内では，クラスが重複しないようにしてください。

Enterprise Beanのリモートインタフェース，リモートコンポーネントインタフェースのクラス名は，VisiBrokerの予約名を使用しないでください。なお，VisiBrokerの予約名には，「Helper」,「Holder」,「Package」,「Operations」,「POA」,および「POATie」があります。VisiBrokerの予約名については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス」を参照してください。

デフォルトパッケージにEnterprise Beanクラスを作成する場合，次に示す文字列で終わるクラスをデフォルトパッケージに作成しないでください。

_LocalHomeImpl

_LocalComponentImpl

_RemoteHomeImpl

_RemoteComponentImpl

_LocalBIProxyImpl

_LocalBIClientSideProxyImpl

_RemoteBIProxyInterface

_RemoteBIProxyImpl

_RemoteBIClientSideProxyImpl

_CallbackWrapperImpl

_InvocationContextImpl

4.2.2　リソースのコネクションの取得と解放

Enterprise BeanでJDBC，JMSなどのJ2EEリソースのコネクションを使用する場合，Connectionクラスのcloseメソッドでコネクションを解放してください。コネクションを解放しないと，予期しないうちにリソースを消費し尽くしてしまいます。このような状況を避けるため，次のような点を考慮して実装してください。

コネクションをEnterprise Beanクラスのメンバ変数に保持しないようにします。

コネクションをメンバ変数に保持していると，Beanの実行に関係なくコネクションが使用状態のままになり，パフォーマンスが低下します。そのため，SQL実行時にコネクションの取得と解放をするようにしてください。

コネクションプールを設定します。

コネクションプールを設定すると，物理的コネクションを再利用するためコネクション取得のオーバーヘッドを削減できます。また，JTAのトランザクション配下で実行する場合はコネクションプールの設定をする必要があります。

4.2.3　ローカルインタフェースとリモートインタフェースの使い分け

EJB 2.0仕様で追加されたローカルインタフェースを利用すると，RMI-IIOP通信処理のオーバーヘッドを削減できますが，ローカルインタフェースだけを持つEnterprise Beanはリモート呼び出しができません。また，ローカルインタフェースを使用する場合，メソッドの引数，戻り値がpass by referenceで動作できる必要があります。次に示すローカルインタフェースの使用条件を参考に，ローカルインタフェースとリモートインタフェースを使い分けてください。

ローカルインタフェースの使用が推奨される場合

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）が同じJ2EEアプリケーションに含まれている場合，ローカルインタフェースの使用が推奨されます。

ローカルインタフェースの使用が必須の場合

CMP2.xのCMRは，ローカルインタフェースの使用が前提のため，ローカルインタフェースを使用してください。

ローカルインタフェースが使用できない場合

次の場合は，ローカルインタフェースが使用できません。

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）が別のJ2EEアプリケーションに含まれている場合。

Enterprise Beanとクライアント（Enterprise BeanまたはJSP/サーブレット）がほかのJ2EEサーバ（別のJavaVM）で実行される場合。

EJB 1.1ですでに実装されている場合。

4.2.4　ローカル呼び出し最適化機能の利用について

リモートインタフェース使用時にローカル呼び出し最適化機能を利用すると，RMI-IIOP通信処理のオーバーヘッドを削減できます。ローカル呼び出しは，メソッド呼び出しとほぼ同等の呼び出し形式になりますが，メソッドの引数，戻り値はpass by valueで処理されます。

4.2.5　ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法

同一J2EEサーバ内にある場合と，ほかのJ2EEサーバ内にある場合に分けて，ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースで呼び出す方法を示します。

(1)　同一J2EEサーバ内のほかのアプリケーションで動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのリモートホームインタフェース，リモートインタフェースおよび各インタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルに次に示すプロパティを指定します。

usrconf.propertiesのejbserver.deploy.stub.generation.scopeキーに「app」を指定します。

usrconf.propertiesについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「12.2.2　usrconf.properties（Javaアプリケーション用ユーザプロパティファイル）」を参照してください。

ネーミングの切り替え機能を使用してcorbanameで始まる，ほかのJ2EEアプリケーション内のEnterprise Beanのルックアップ名を指定します。

指定方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.3.1　ほかのEnterprise Beanのリファレンス定義」を参照してください。

指定例を次に示します。

corbaname::NamingHost:900#HITACHI_EJB/SERVERS/MyServer/EJB/MyApplication/MyBean

(2)　ほかのJ2EEサーバ上で動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのリモートホームインタフェース，リモートインタフェースおよび各インタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルに次に示すプロパティを指定します。

usrconf.propertiesのejbserver.deploy.stub.generation.scopeキーに「app」を指定します。

ネーミングの切り替え機能を使用してcorbanameで始まるほかのJ2EEアプリケーション内のEnterprise Beanのルックアップ名を指定します。

指定方法については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.3.1　ほかのEnterprise Beanのリファレンス定義」を参照してください。

指定例を次に示します。

corbaname::NamingHost:900#HITACHI_EJB/SERVERS/MyServer/EJB/MyApplication/MyBean

4.2.6　ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法

同一J2EEサーバ内にある場合と，ほかのJ2EEサーバ内にある場合に分けて，ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースで呼び出す方法を示します。

(1)　同一J2EEサーバ内のほかのアプリケーションで動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めます。

J2EEサーバ用ユーザ定義ファイルのejbserver.rmi.localinvocation.scopeキーが「none」の場合は，呼び出し先のEnterprise Beanに対して，cjgetstubsjarコマンドでスタブを取得し，呼び出し元のEARファイルに含めます。※

Enterprise BeanはEJB参照を使用しないでルックアップします。ルックアップ名を指定する形式を示します。

「HITACHI_EJB/SERVERS/<サーバ名> /EJBBI/<J2EE APP名>/<Enterprise Bean名>」

<サーバ名>：J2EEサーバのサーバ名称

<J2EE APP名>：J2EEアプリケーションのルックアップ名称

<Enterprise Bean名>：Enterprise Beanのルックアップ名称

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用すればスタブを含める必要はありませんが，ダイナミッククラスローディング機能は性能上推奨しません。

(2)　ほかのJ2EEサーバ上で動作するEnterprise Beanの場合

次の手順で呼び出します。

呼び出し元のEJB-JARファイルまたはWARファイルに，呼び出し先Enterprise Beanのビジネスインタフェースおよびインタフェースで使用するユーザ作成クラスを含めます。

呼び出し先のEnterprise Beanに対してcjgetstubsjarコマンドでスタブを取得し，呼び出し元のEARファイルに含めます。※

Enterprise BeanはEJB参照を使用しないで，ネーミングサービスの切り替え機能を使用してルックアップします。ルックアップ名を指定する形式を示します。

「corbaname：：<名前空間のホスト名>：<名前空間のポート番号>#HITACHI_EJB/SERVERS/<サーバ名> /EJBBI/<J2EE APP名>/<Enterprise Bean名>」

<名前空間のホスト名>：Enterprise Beanが使用する名前空間が動作するホスト名称

<名前空間のポート番号>：Enterprise Beanが使用する名前空間が動作するポート番号

<サーバ名>：J2EEサーバのサーバ名称

<J2EE APP名>：J2EEアプリケーションのルックアップ名称

<Enterprise Bean名>：Enterprise Beanのルックアップ名称

注※

アプリケーション間のビジネスインタフェース呼び出しで，ダイナミッククラスローディング機能を使用すればスタブを含める必要はありませんが，ダイナミッククラスローディング機能は性能上推奨しません。

4.2.7　クラスローダの取得に関する注意

J2EEアプリケーション内のコードからComponent Containerのクラスローダを取得して，次に示すAPIを使用する場合に，java.net.JarURLConnectionクラスが使用されます。

getResource(String).openConnection().getInputStream();

getResource(String).openStream()

上記メソッドの延長でjava.net.JarURLConnectionクラスのopenConnectionメソッドが呼び出され，該当するURLに指定されたJARファイルがオープンされます。JARファイルに対する操作が必要でjava.net.JarURLConnectionクラスのopenConnectionメソッドを使用する場合には，java.net.JarURLConnectionのgetJarFileメソッドが返すJarFileインスタンスのcloseメソッドを必ず呼び出すようにしてください。明示的にcloseメソッドを呼ばないかぎり，オープンされたままになり削除できません。また，上記メソッドはJ2EEアプリケーション内で使用しないでください。

4.2.8　URLConnectionクラス使用時の注意

java.net.URLConnectionクラスはsetUseCaches(boolean)メソッドを使用して，指定されたURLに対してコネクションを取得するときにキャッシュの情報を利用するかどうかを指定できます。URLConnectionクラスに対してsetUseCaches(false)メソッドを指定した場合に，コネクションごとに対象のオブジェクトが生成されます。J2EEアプリケーション内のコードから使用する場合には，J2EEサーバのJavaVMがメモリリークするおそれがあります。

4.2.9　ネイティブライブラリのロードに関する注意

System.loadLibraryメソッドを使用して，Enterprise Beanからネイティブライブラリをロードしないでください。Enterprise Beanでネイティブライブラリをロードすると，JNI仕様の制約によって，java.lang.UnsatisfiedLinkErrorが発生することがあります。ネイティブライブラリのロードが必要な場合は，System.loadLibraryメソッドを呼び出すコンテナ拡張ライブラリを作成し，Enterprise Beanからコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「19.　コンテナ拡張ライブラリ」を参照してください。

4.2.10　Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて

Entity Bean（CMP，BMP）を使用する場合，同一プライマリキーのEntity Beanに対するアクセスには排他が掛かります。同時に同一のプライマリキーのEntity Beanに対してアクセスし，処理時間が掛かる場合は，排他待ちが行われます。排他待ちの結果，排他を取得できなかった場合は，タイムアウト（デフォルト45秒）で例外IllegalStateExceptionが発生します。この場合，J2EEサーバ用ユーザ定義ファイル（/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties）のejbserver.server.mutex.invocation.timeoutキーにタイムアウト時間を指定してタイムアウトを発生させないようにすることができます。ejbserver.server.mutex.invocation.timeoutキーについては，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

4.2.11　Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について

アプリケーションサーバでは，Entity Beanのトランザクション処理にデータベースのトランザクション機能を使用しています。データベースへのアクセスの順番，データの排他にかかわるテーブルの設定，データベースのシステムの設定，および呼び出すSQL文によっては，デッドロックが発生する場合があります。詳細は使用しているデータベースのマニュアルを参照してください。

4.2.12　javax.ejb.EJBContextインタフェースメソッドについての注意事項

javax.ejb.EJBContextインタフェースのgetUserTransactionメソッド，getRollbackOnlyメソッド，setRollbackOnlyメソッドについては，Enterprise Beanのトランザクション管理モデルによっては発行できません。また，Enterprise Beanのメソッドのうち，EJB仕様で"Unspecified transaction"で動作するとされるものでは，発行できません。発行できない場合，EJBコンテナはjava.lang.IllegalStateExceptionを送出します。各メソッドの発行可否についてそれぞれの表に示します。

表4‒2　トランザクション管理モデル別の発行可否

javax.ejb.EJBContextメソッド

発行可否

BMT

CMT

getUserTransaction

○

×

getRollbackOnly

×

○

setRollbackOnly

×

○

（凡例）○：発行できる。　×：発行できない。

表4‒3　EJBのメソッド別の発行可否

Bean種別

メソッド

発行可否

SessionBean

コンストラクタ

×

setSessionContext

×

ejbCreate

×

ejbRemove

×

ejbPassivate

×

ejbActivate

×

ビジネスメソッド

○

afterBegin

○

beforeCompletion

○

afterCompletion

×

EntityBean

コンストラクタ

○

setEntityContext

×

unsetEntityContext

×

ejbCreate

○

ejbPostCreate

○

ejbRemove

○

ejbHome

○

ejbPassivate

×

ejbActivate

×

ejbLoad

○

ejbStore

○

ビジネスメソッド

○

Message-driven Bean

コンストラクタ

×

ejbCreate

×

onMessage

○

メッセージリスナのメソッド

○

ejbRemove

×

（凡例）○：発行できる。　×：発行できない。

4.2.13　Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて

Entity Bean属性ファイルの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，次のように動作します。

Entity Bean（CMP）の場合

デプロイ時にエラーメッセージKDJE42039-Eが出力され，デプロイ処理はエラーで終了します。

Entity Bean（BMP）の場合

クラスを指定したときと同様，デプロイおよび実行できます。

4.2.14　EJBの仕様に関する注意

EJB仕様に従っていない記述をした場合，エラー（例外）が発生することがあります。以前のバージョンでエラーが発生しなくても，バージョンアップをしたときにエラーになることがあります。エラーが発生した場合は，エラーの内容を確認し，EJB仕様に従って変更してください。

4.2.15　マルチバイト文字について

EJBを構成するクラスで，クラス（パッケージ）名，ビジネスメソッド，コールバックメソッド，インターセプタメソッドなどのメソッド名，戻り値の型，引数（型，名称），throws節に宣言した例外の名称にマルチバイト文字を使用しないでください。

4.2.16　EJB 3.0のAPIに関する注意

EJB 3.0で追加された次のAPIはサポートしていません。

javax.ejb.EJBContext#lookup(java.lang.String)

javax.ejb.SessionContext#getBusinessObject(java.lang.Class)

4.2.17　EJB 3.0以降のejb-jar.xmlに関する注意

08-70以降のアプリケーションサーバでは，次の要素をEJB3.0以降のejb-jar.xmlに記述できます。

<display-name>要素

<interceptor-binding>要素，およびその配下の要素（インターセプタに関する定義）

<application-exception>要素，およびその配下の要素（アプリケーション例外に関する定義）

<module-name>要素

4.2.18　ジェネリクスの使用に関する注意

ジェネリクスは，J2SE 5.0以降で使用できる機能です。ジェネリクスを使用すると，さまざまな型のオブジェクトを型やメソッドで使用する場合に，コンパイル時に型の安全性を保証できます。また，ジェネリクスを使用することで，データの型に依存しない，型そのものをパラメタとして扱うプログラミングを実現できます。

型を変数化することを型変数といいます。型変数は，ジェネリクスを使用したクラス，インタフェース，メソッドまたはコンストラクタの宣言時に使用します。「List<E> extends Collection<E>」という定義の場合，<E>の部分が型変数に該当します。

また，ジェネリクスを使用したクラス，インタフェース，メソッド，またはコンストラクタに対して，具体的なパラメタの型を指定することをパラメタ化といいます。例えば，「List<String>」，「Collection<Integer>」などが，パラメタ化されたクラスです。

(1)　型変数を使用できるインタフェース

インタフェースでは，メソッドの引数，戻り値，および例外で型変数を使用できます。使用する型変数は，インタフェース定義で宣言します。

(a)　型変数を使用できるインタフェースの種類

型変数を使用できるインタフェースの種類をEnterprise Beanの種別ごとに次の表に示します。

表4‒4　型変数を使用できるインタフェースの種類

インタフェースの種類

Enterprise Beanの種別

Session Bean

Entity Bean

Message-driven Bean

ビジネスインタフェース

△

−

−

Homeインタフェース

×

×

−

Componentインタフェース

×

×

−

メッセージリスナインタフェース

−

−

○

その他(任意のインタフェース)

○

○

○

（凡例）

○：使用できる。

△：使用できる。ただし，宣言した型変数はビジネスインタフェースでパラメタ化する必要がある。パラメタ化しなかった場合，エラーが発生するか，保証されない動作になる。

×：使用できない。

−：使用できない（Java EE仕様）。

(b)　ビジネスインタフェースで型変数を使用した場合の注意事項

インタフェースで定義した型変数をビジネスインタフェースでパラメタ化した際に，パラメタ化したビジネスインタフェースのメソッドを再定義した場合，型変数を使用した個所とインタフェース種別の組み合わせによって，エラーになることがあります。エラーが発生した場合は，再定義したメソッドを削除して対処してください。

ビジネスインタフェースでメソッドを再定義した場合にエラーとなる組み合わせを次の表に示します。

表4‒5　ビジネスインタフェースでメソッドを再定義した場合にエラーとなる組み合わせ

型変数を使用した個所

ローカルインタフェース

リモートインタフェース

戻り値

○

○

引数

×

×

例外

○

○

（凡例）

○：アプリケーションの開始に成功する。

×：アプリケーションの開始時にエラーが発生する。

エラーが発生するのは，次の項目の両方に該当する場合です。

インタフェースで定義した型変数をパラメタ化している。

型変数をパラメタ化したインタフェースを継承したインタフェース内で，メソッドを再定義している。

エラーが発生するコーディングの例を次に示します。この例の場合，エラーを回避するためには，MyInterfaceの定義からメソッド「String get(Float args)」の定義を削除する必要があります。

public interface SuperInterface<T> {
String get(T args);
}

// SuperInterfaceをパラメタ化して継承したメソッドを再定義している。
public interface MyInterface
extends SuperInterface<Float> {
// エラー回避のためには，次の再定義したメソッド定義を削除する必要がある。
    String get(Float args);
}

(2)　型変数を使用できるクラス

クラスでは，メソッドのシグネチャおよびメソッド内で型変数を使用できます。

型変数を使用できるクラスの種類をEnterprise Beanの種別ごとに次の表に示します。

表4‒6　型変数を使用できるクラスの種類

クラスの種類

Enterprise Beanの種別

Session Bean

Entity Bean

Message-driven Bean

Enterprise Beanクラス

○

○

○

インターセプタクラス

○

−

−

その他(任意のクラス)

○

○

○

（凡例）

○：使用できる。

−：使用できない（アプリケーションサーバでのサポート外の組み合わせである）。

(3)　その他

ジェネリックメソッドやジェネリックコンストラクタにアプリケーションサーバが対応するアノテーション※は指定できません。指定した場合は無視されます。

ジェネリックメソッド，ジェネリックコンストラクタの例を次に示します。

注※　アプリケーションサーバが対応するアノテーションについての詳細は，マニュアル「アプリケーションサーバ リファレンス API編」の「2.1　アノテーションのサポート範囲」を参照してください。

class MyClass{

// ジェネリックコンストラクタ
<T1> MyClass(Collection<T1> c){};

// ジェネリックメソッド
<T2> void MyMethod(Collection<T2> c){};

}

4.2.19　EJB 3.1使用時の注意

EJB 3.1使用時の注意事項を示します。

組み込み可能EJBコンテナはサポートしません。

@StatefulTimeoutアノテーションおよび@AroundTimeoutアノテーションはサポートしません。@AccessTimeoutアノテーションは，Stateful Session Beanでは使用できません。

WARへのEJBのパッケージングはサポートしません。EJBコンポーネント定義アノテーション（@Stateless／@Stateful／@Singleton）が付与されたクラスファイルをWARのWEB-INF/classesまたはWEB-INF/lib下のJARファイル内に格納すること，およびWEB-INF/ejb-jar.xmlを配置することはサポートしません。そのような構成のアプリケーションの動作は保証しません。

Singleton Session BeanではWebサービスクライアントビューは使えません。

EJB3.1で追加された機能を使う場合，次の機能とは組み合わせて使用できません。

JPA

JAX-WS

JAX-RS

EJB 3.1で追加されたjavax.ejb.EJBContextインタフェースのgetContextDataメソッドは，EJBコンテナではサポートしません。

4.2.20　getCause()メソッドについて

リモートインタフェース，Entity Bean，Message-driven Beanはサポートしていません。

4.2.21　リソース参照の名称に関する注意

リソース参照の名称で文字列の末尾にスラッシュ（/）を設定できません。アプリケーションサーバ 08-70以前で利用していたアプリケーション（Session Bean）でこの設定をしている場合，アプリケーションサーバ 09-00以降ではアプリケーションの開始に失敗します。

4.2.22　アプリケーションサーバのライブラリに関する注意

アプリケーションサーバのライブラリをJ2EEアプリケーションに含めると，ライブラリのバージョン不整合などが原因で，アプリケーションのインポートや開始，実行で不正な動作になることがあります。そのため，製品が使用方法として明示している場合を除いて，アプリケーションサーバのライブラリはJ2EEアプリケーションに含めないようにしてください。

4.2.23　J2EEサーバとEJBクライアント間でJava SEのバージョンが異なる場合の注意事項

EJBを動作させるJ2EEサーバとEJBクライアントとでJava SEのバージョンが異なる場合，低い方のJava SEのバージョンに合わせてクラスファイルを作成してください。

特にcjgetstubsjarコマンドで取得する<数字>.jarを利用する場合，<数字>.jarは，ユーザが作成したEJB-JARファイルと同一であるため，次のクラス・インタフェースについては低い方のJava SEのバージョンに合わせてコーディング，コンパイルしてください。

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

リモートコンポーネントインタフェース

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

上記から参照するクラス，インタフェース

4.3　Enterprise Beanの種類ごとの注意事項

Enterprise Beanの種類ごとの注意事項を示します。

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

Stateless Session Beanを実装するときの注意事項を示します。

(1)　removeメソッドによるリファレンスの解放

ホームインタフェースを使用してStateless Session Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Session Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出してリファレンスを解放してください。リファレンスを解放しない場合，J2EEサーバ上のメモリを消費したままの状態になります。

また，removeメソッド呼び出しを不要にするオプションを指定することで，Stateless Session BeanのEJBオブジェクトに対する，removeメソッドの呼び出しが不要になります。このオプションを有効にすると，removeメソッド呼び出しのあとに，ビジネスメソッドの呼び出しができます。

このオプションを無効にしている場合は，removeメソッドを呼び出す必要があります。また，removeメソッド呼び出しのあとにビジネスメソッドを呼び出した場合，java.rmi.NoSuchObjectException例外が呼び出し元に返ります。

removeメソッド呼び出しを不要にするオプションは，usrconf.propertiesのejbserver.rmi.stateless.unique_id.enabledキーに指定し，J2EEサーバ単位に定義します。キーの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「2.2.3　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」を参照してください。

(2)　ejbCreateメソッドおよび@PostConstructアノテーションを指定したメソッドでのリソースマネジャへのアクセスについて

EJB仕様では，ejbCreateメソッドまたは@PostConstructアノテーションを指定したメソッドで，リソースマネジャへアクセスすることは許されていません。

(3)　Beanクラスの共有についての注意

同じSession Beanを同じJ2EEアプリケーション内でStateful Session Bean，およびStateless Session Beanとして同時に利用しないでください。

(4)　ejbRemoveメソッドまたは@PreDestroyアノテーションを指定したメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

Stateless Session BeanのejbRemoveメソッドまたは@PreDestroyアノテーションを指定したメソッドでは，javax.transaction.UserTransactionのbeginメソッドを呼び出せる場合がありますが，EJBの仕様上，呼び出して使用することはできません。呼び出さないようにしてください。

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

Stateful Session Beanを実装するときの注意事項を示します。

(1)　removeメソッドまたは@Removeアノテーションを指定したメソッドによるEJBインスタンスの削除とリファレンスの解放

ホームインタフェースを使用してStateful Session Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Session Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出して，EJBインスタンスの削除とリファレンスを解放してください。

ビジネスインタフェースを使用してStateful Session Beanを呼び出す場合，ビジネスメソッドの呼び出しが完了したあとに，必ず@Removeアノテーションを指定したメソッドを呼び出して，EJBインスタンスを削除し，リファレンスを解放してください。

EJBインスタンスの削除およびリファレンスの解放をしない場合，J2EEサーバ上のメモリを消費したままの状態になります。

(2)　Beanクラスの共有についての注意

同じSession Beanを同じJ2EEアプリケーション内でStateful Session Bean，およびStateless Session Beanとして同時に利用しないでください。

(3)　SessionSynchronizationのインスタンスの破棄についての注意

SessionSynchronizationのbeforeCompletionメソッドおよびafterCompletionメソッドでシステム例外が発生した場合，EJBコンテナでは該当するSession Beanのインスタンスを破棄しません。

(4)　setSessionContextメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて

Stateful Session BeanのsetSessionContextメソッドでは，javax.transaction.UserTransactionのbeginメソッドを呼び出せる場合がありますが，EJBの仕様上，呼び出して使用することはできません。呼び出さないようにしてください。

(5)　afterCompletionメソッドからのEnterprise Beanの呼び出しについて

Stateful Session BeanのafterCompletionメソッドからほかのEnterprise Beanを呼び出せる場合がありますが，EJBの仕様上，Stateful Session BeanのafterCompletionメソッドからほかのEnterprise Beanを呼び出せないので，呼び出さないようにしてください。

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

Entity Bean（BMP）を実装するときの注意事項を示します。

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

EJB 1.1仕様およびEJB 2.0仕様では，setEntityContextメソッドでのリソースマネジャへのアクセスは許されていません。

(2)　プライマリキークラスへのインタフェース指定について

BMP Entity BeanのDDの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，クラスを指定したときと同様に，デプロイおよび実行ができます。

(3)　removeメソッドによるリファレンスの解放

ホームインタフェースを使用してEntity Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Entity Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出してリファレンスを解放してください。

リファレンスを解放しない場合，J2EEサーバ上のメモリを消費したままの状態になります。

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

Entity Bean（CMP）を実装するときの注意事項を示します。

(1)　setEntityContextメソッドでのリソースマネジャへのアクセスについて

EJB 1.1仕様およびEJB 2.0仕様では，setEntityContextメソッドでのリソースマネジャへのアクセスは許されていません。

(2)　ユーザ定義型のCMPフィールドの使用についての注意

プライマリキーとして複合プライマリキーを使用する以外で，ユーザ定義型のCMPフィールドを使用できません。

(3)　CMRフィールド使用時のトランザクションに関する注意

Collection型のCMRフィールドやCollection型のCMRフィールドのIteratorを使用する場合，CMRフィールドを取得したときのトランザクションの範囲内で，CMRフィールドやIteratorへアクセスできます。次のコーディング例のcallTeamメソッドでは，CMRフィールドのgetterメソッドであるgetPlayersメソッドと，それに続くIteratorを使用した操作をすべて同一トランザクション内で実行する必要があります（［a］から［b］の間）。

   public void callTeam() {
             ：
     //[a]
     Collection playersInTeam = team.getPlayers();
     Iterator i = playersInTeam.iterator();
     while (i.hasNext()) {
       LocalPlayer p = (LocalPlayer) i.next();
             ：
     }
     //[b]
   }

このコーディング例をトランザクション外で実行した場合は，IllegalStateException例外が発生します。これを避けるために，トランザクション内で実行されるようにCMTなどで設定してください。

(4)　CMRのcascade-deleteの使用についての注意

CMRのcascade-deleteを使用する場合，次の制限があります。

cascade-deleteでEntity Beanをremoveする場合，呼び出し元となるクライアントプログラムは，最初にremoveされるBeanのremoveメソッドのメソッドパーミッションだけでなく，cascade-deleteの対象となるすべてのBeanでの，コンポーネントインタフェースのremoveメソッドのメソッドパーミッションを持つように設定されている必要があります。

cascade-deleteの対象となるすべてのBeanでの，コンポーネントインタフェースのremoveメソッドのトランザクション属性は，Requiredに設定してください。

cascade-deleteを指定している関係が複数のBeanを循環するように設定されている場合，循環した関係にあるすべてのBeanでremoveメソッドの実行は保証されません。

(5)　プライマリキークラスへのインタフェース指定について

CMP Entity BeanのDDの<prim-key-class>タグにインタフェースおよび抽象クラスを指定した場合，デプロイ時にエラーメッセージKDJE42039-Eが出力され，デプロイ処理はエラー終了されます。

(6)　removeメソッドによるリファレンスの解放

ホームインタフェースを使用してEntity Beanを呼び出す場合，ホームインタフェースのcreateメソッドを呼び出してリファレンスを取得しますが，Entity Beanの呼び出しが完了したあとに，必ずremoveメソッドを呼び出してリファレンスを解放してください。

リファレンスを解放しない場合，J2EEサーバ上のメモリを消費したままの状態になります。

(7)　EJB QLのfinderメソッドまたはselectメソッドに関する注意

EJB QLのfinderメソッドまたはselectメソッドの引数の型として，配列を指定できません。

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

Message-driven Beanを実装するときの注意事項を示します。

(1)　Message-driven Beanのトランザクション設定時の注意（Connector 1.0に準拠したリソースアダプタを使用する場合）

Message-driven Beanへのメッセージ配信とMessage-driven Bean内のデータベースアクセス処理をトランザクションで同期を取る場合，Message-driven Beanのトランザクション設定はCMTでRequiredに設定します。これによって，トランザクションがロールバックした場合にMessage-driven Beanへメッセージが再配信されます。しかし，トランザクションのロールバックが繰り返されると再配信も繰り返されるため，Message-driven Bean側でjavax.jms.MessageクラスのgetJMSRedeliveredメソッドを使用して再配信を確認するなどの対処が必要になります。CMTのNotSupported設定，またはBMTではいったんMessage-driven Beanでメッセージを受信すると，トランザクションがロールバックしても再配信されなくなります。

(2)　Message-driven Beanのトランザクション設定時の注意（Connector 1.5に準拠したリソースアダプタを使用する場合）

TP1インバウンド連携機能を使用したOpenTP1とMessage-driven Bean内のリソースアクセス処理で，グローバルトランザクションを使用する場合，Message-driven Beanのトランザクション管理方法はCMTを選択してください。また，トランザクション属性はRequiredを設定してください。

そのほかのMessage-driven Beanにメッセージを配信するEISとMessage-driven Bean内のリソースアクセス処理で，グローバルトランザクションを使用する場合も，Message-driven Beanのトランザクション管理方法は，CMTを選択してください。また，トランザクション属性はRequiredに設定してください。

ただし，CJMSPリソースアダプタまたはFTPインバウンドアダプタを使用する場合は，Message-driven Beanへのメッセージ配信とMessage-driven Bean内のリソースアクセス処理で，グローバルトランザクションを使用して同期を取ることはできません。このため，CJMSPリソースアダプタまたはFTPインバウンドアダプタからのメッセージを受信する場合，Message-driven Beanのトランザクション管理方法をBMTにするか，またはCMTにしてトランザクション属性をNotSupportedに設定してください。

4.3.6　Singleton Session Bean実装時の注意事項

Singleton Session Beanを実装する場合，javax.ejb.SessionSynchronizationインタフェースは実装しないでください。また，Session Beanでは，SessionSynchronizationに関するアノテーション（@AfterBeginアノテーション，@BeforeCompletionアノテーションまたは@AfterCompletionアノテーション）を指定しないでください。

付録

付録A　Client

Clientは，EJBクライアントアプリケーションの実行環境（EJBクライアント環境）を構築するための製品です。アプリケーションサーバ上で動作しているJ2EEアプリケーション内のEnterprise Beanを，Webサーバ経由ではなく，クライアントマシン上のプログラムから直接呼び出すシステムを構築したい場合に，クライアントとして使用できます。

なお，Clientの対象OSはWindowsだけです。

Clientは，Application Serverに含まれるコンポーネントのうち，クライアント環境に必要なコンポーネント，またはそのサブセットに当たるコンポーネントによって構成されています。

ここでは，Clientの機能とインストール方法について説明します。

付録A.1　Clientの機能

Clientには，次の機能があります。

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

Session BeanなどをRMI-IIOP通信で呼び出すJavaアプリケーションである，EJBクライアントアプリケーションを実行できます。また，Javaアプリケーションを開始できます。

性能解析トレース出力

EJBクライアントアプリケーションからリクエストを送信するときの性能解析情報を出力できます。出力した性能解析情報は，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて分析できます。

付録A.2　インストール手順

ここでは，Clientのインストール手順について説明します。

製品のインストールには，インストーラを使用します。

Clientのインストール手順を次に示します。

Clientをインストールします。

インストール後のClientのディレクトリ構成については，「付録A.3　Clientのディレクトリ構成」を参照してください。

環境変数を設定します。

Clientで設定が必要な環境変数については，「3.3.4　EJBクライアントアプリケーションの実行に必要な環境変数の設定」を参照してください。

リソースの見積もりと設定をします。

Clientをインストールしたマシンで使用するリソースの見積もりと設定をします。使用するリソースの見積もりについては，次に示すマニュアルの個所を参照してください。

J2EEアプリケーション実行基盤の場合

マニュアル「アプリケーションサーバ システム設計ガイド」の「5.　使用するリソースの見積もり（J2EEアプリケーション実行基盤）」

バッチアプリケーション実行基盤の場合

マニュアル「アプリケーションサーバ システム設計ガイド」の「6.　使用するリソースの見積もり（バッチアプリケーション実行基盤）」

インストールが完了したら，EJBクライアントアプリケーションを開始します。EJBクライアントアプリケーションの動作は，直接設定ファイルを編集したり，環境変数を設定したりして設定します。

EJBクライアントアプリケーションは，cjclstartapコマンドなどを使用して開始します。手順については，「3.3　EJBクライアントアプリケーションの開始」を参照してください。

ポイント

Clientを使用してEJBクライアント環境を構築する場合は，各ユーザ定義ファイルの格納ディレクトリは，「<Application Serverのインストールディレクトリ>¥CCL」になります。

注意事項

Windows環境では，ログの出力先としてC:¥Program Files以下のディレクトリを指定している場合，EJBクライアントアプリケーションは，管理者特権で実行する必要があります。管理者特権のないユーザが，ログの出力先としてC:¥Program Files以下のディレクトリを指定して，EJBクライアントアプリケーションを実行した場合には，ログは保存されません。この場合，ログは次に示すディレクトリに保存されます。

C:¥Users¥<ユーザ名>¥AppData¥Local¥VirtualStore

管理者特権で実行する方法については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「1.6　Windows使用時の注意事項」を参照してください。

付録A.3　Clientのディレクトリ構成

Clientと，その構成ソフトウェアであるComponent Container - Clientのディレクトリ構成を次の図に示します。

図A‒1　Clientのディレクトリ構成

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

ここでは，11-50よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-50での主な機能変更については，「1.4　アプリケーションサーバ 11-50での主な機能変更」を参照してください。

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

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

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

付録B.1　11-40での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

Java SE 17への対応

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

システム設計ガイド

2.1

機能解説 保守／移行編

9章

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

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

システム設計ガイド

7.17

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

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

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

3.6.18

付録B.2　11-30での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JDBC4.3への対応

JDBC4.3に対応しました。

アプリケーションサーバ & BPM/ESB基盤 概説

4.6.2

接続できるデータベースにMySQL，PostgreSQLを追加

DB Connectorを使用して接続できるデータベースに，MySQL，PostgreSQLを追加しました。

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

3.6

パッケージ名変換機能の追加

jakartaパッケージ名を前提とするアプリケーションをアプリケーションサーバで動作させる機能を追加しました。

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

20章

付録B.3　11-20での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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章

付録B.4　11-10での主な機能変更

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

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

表B‒4　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

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

付録B.4

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JSP2.3への対応

JSP2.3に対応しました。

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

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

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

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

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

15章

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

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

表B‒6　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

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

2.22

付録B.5　11-00での主な機能変更

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

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

表B‒7　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表B‒9　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録D

(4)　そのほかの目的

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

表B‒10　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録B.6　09-87での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

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

機能解説 保守／移行編

9章

付録B.7　09-80での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能におけるラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

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

機能解説 保守／移行編

9章

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

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

表B‒13　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録C

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録C

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録C

付録B.8　09-70での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでの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)　運用性の維持・向上

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

表B‒15　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

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

表B‒16　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録B.9　09-60での主な機能変更

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

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

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.18

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

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

表B‒18　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.16

(3)　そのほかの目的

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

表B‒19　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

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

14.2

付録B.10　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表B‒20　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

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

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

表B‒21　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

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

1.1.2

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表B‒23　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

システム設計ガイド

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)　運用性の維持・向上

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

表B‒24　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　そのほかの目的

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

表B‒25　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

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トレースのルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができるようになりました。

このマニュアル

2.17.3

付録B.11　09-00での主な機能変更

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

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

表B‒26　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

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

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

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

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0への対応

Servlet 3.0に対応しました。

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

8章

EJB 3.1への対応

EJB 3.1に対応しました。

このマニュアル

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)　信頼性の維持・向上

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

表B‒28　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

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

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

表B‒29　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　そのほかの目的

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

表B‒30　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

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

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

付録B.12　08-70での主な機能変更

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

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

表B‒31　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（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)　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

ejb-jar.xmlの指定項目の追加

ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。

このマニュアル

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)　信頼性の維持・向上

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

表B‒33　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

機能解説 拡張編

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

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

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

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

機能解説 拡張編

7.11

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

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

表B‒34　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

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

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

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

表B‒35　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

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

2.1

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

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

付録B.13　08-53での主な機能変更

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

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

表B‒36　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

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

2章，3章，5章

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

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

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

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

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

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

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

8章

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

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

表B‒38　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，

9章

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

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

表B‒39　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

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

1.3，2.1

(5)　そのほかの目的

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

表B‒40　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

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章

（凡例）−：該当なし。

付録B.14　08-50での主な機能変更

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

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

表B‒41　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　標準機能・既存機能への対応

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

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

項目

変更の概要

参照先マニュアル

参照個所

OpenTP1からの呼び出しへの対応

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。

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

4章

JMSへの対応

JMS 1.1仕様に対応したCJMSプロバイダ機能を使用できるようになりました。

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

7章

Java SE 6への対応

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

機能解説 保守／移行編

5.5，5.8.1

ジェネリクスの使用への対応

EJBでジェネリクスを使用できるようになりました。

このマニュアル

4.2.18

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

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

表B‒43　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

機能解説 拡張編

7章

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

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

機能解説 拡張編

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバの障害を監視して，障害が発生した仮想サーバを停止するための設定を追加しました。

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

−

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

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

表B‒44　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，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)　そのほかの目的

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

表B‒45　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

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を指定できるようになりました。

このマニュアル

2.7.3

OutOfMemory発生時の運用管理エージェントの強制終了

Java VMでOutOfMemoryが発生したときに，運用管理エージェントが強制終了するようになりました。

機能解説 保守／移行編

2.5.5

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

TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

機能解説 拡張編

−

付録B.15　08-00での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表B‒46　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

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

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

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

16.3

(2)　標準機能への対応

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

表B‒47　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

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)　信頼性の維持・向上

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

表B‒48　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

機能解説 拡張編

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，FullGC発生を抑止できるようになりました。

機能解説 拡張編

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

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

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

表B‒49　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

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

1.1.3

(5)　そのほかの目的

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

表B‒50　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効な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で削除された機能です。

付録C　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

数字

09-80での主な機能変更[1]

09-87での主な機能変更[1]

11-00での主な機能変更[1]

11-10での主な機能変更[1]

11-20での主な機能変更[1]

11-30での主な機能変更[1]

11-40での主な機能変更[1]

A

afterCompletionメソッドからのEnterprise Beanの呼び出しについて[1]

B

Beanクラスの共有についての注意[1]、[2]

BMP[1]

BMT[1]

C

Caching（commit option B）[1]

cjclstartap[1]

CMP[1]

CMRのcascade-deleteの使用についての注意[1]

CMRフィールド使用時のトランザクションに関する注意[1]

CMT[1]

E

EJB QLのfinderメソッドまたはselectメソッドに関する注意[1]

ejbserver.container.rebindpolicy[1]

ejbserver.container.security.disabled[1]

ejbserver.ejb.timerservice.maxCallbackThreads[1]

ejbserver.ejb.timerservice.retryCount[1]

ejbserver.ejb.timerservice.retryInterval[1]

ejbserver.rmi.localinvocation.scope[1]

ejbserver.rmi.passbyreference[1]

ejbserver.rmi.request.timeout[1]

EJBクライアント[1]

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

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

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

EJBクライアントアプリケーションのクラスパスへのJARファイルの設定[1]

EJBクライアントアプリケーションの実行に必要な環境変数の設定[1]

EJBクライアントアプリケーションの使用形態[1]

EJBクライアントアプリケーションの使用形態とシステムプロパティ[1]

EJBコンテナでのタイムアウトの設定[1]

EJB仕様準拠のチェック[1]

EJBタイマキャンセル[1]

EJBタイマ生成[1]

EJBタイマの自動生成[1]

EJBの仕様に関する注意[1]

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

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

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

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

EJBホームオブジェクトのリファレンスの検索と取得[1]

EJBホームオブジェクトのリファレンスを検索してEnterprise Beanを呼び出す方法[1]

Enterprise Bean[1]

Enterprise Beanおよび関連するクラスの命名規則[1]

Enterprise Bean共通の注意事項[1]

Enterprise Beanでのトランザクション管理[1]

Enterprise Beanのインタフェース[1]

Enterprise Beanの実行[1]

Enterprise Beanの種別ごとに指定できるトランザクション属性[1]

Enterprise Beanの種類[1]

Enterprise Beanの生成とメソッドの呼び出し[1]

Enterprise Beanのプールの管理[1]

Enterprise Beanのライフサイクル[1]

Enterprise Beanへのアクセス制御[1]

Enterprise Beanへのアクセス制御の抑止[1]

Enterprise Beanへのアクセス制御の抑止オプション[1]

Entity Bean[1]

Entity Bean（BMP）実装時の注意事項[1]

Entity Bean（CMP，BMP共通）使用時のデッドロックの発生について[1]

Entity Bean（CMP，BMP共通）属性ファイルの<prim-key-class>タグについて[1]

Entity Bean（CMP，BMP共通）のアクセス排他のタイムアウトについて[1]

Entity Bean（CMP）実装時の注意事項[1]

Entity BeanのEJBオブジェクトのタイムアウト[1]

Entity Beanのキャッシュモデル[1]

Entity Beanのプーリング[1]

Entity Beanのライフサイクル[1]、[2]

F

Full caching（commit option A）[1]

I

IPアドレスの固定[1]

J

javax.ejb.EJBContextインタフェースメソッドについての注意事項[1]

JNDIネーミングコンテキストの生成[1]

M

Mandatory属性[1]

Message-driven Bean[1]

Message-driven Bean実装時の注意事項[1]

Message-driven Beanのトランザクション設定時の注意（Connector 1.0に準拠したリソースアダプタを使用する場合）[1]

Message-driven Beanのトランザクション設定時の注意（Connector 1.5に準拠したリソースアダプタを使用する場合）[1]

Message-driven Beanのプーリング[1]

Message-driven Beanのライフサイクル[1]、[2]

N

Never属性[1]

No caching（commit option C）[1]

NotSupported属性[1]

No-Interface view[1]

No-Interface viewの概要[1]

No-Interface viewを使用するための定義[1]

P

pool状態のEntity Bean[1]

R

ready状態のEntity Bean[1]

removeメソッドによるリファレンスの解放[1]、[2]、[3]

Required属性[1]

RequiresNew属性[1]

RMI-IIOP通信のタイムアウト[1]

S

Session Bean[1]

Session Beanの非同期呼び出し[1]

Session Beanの非同期呼び出しの適用範囲[1]

Session Beanのライフサイクル[1]

Session Synchronizationのアノテーションでの指定[1]

SessionSynchronizationのインスタンスの破棄についての注意[1]

Session Synchronizationをアノテーションで設定する方法[1]

setEntityContextメソッドでのリソースマネジャへのアクセスについて[1]、[2]

setSessionContextメソッドでのjavax.transaction.UserTransactionのbeginメソッドの呼び出しについて[1]

Singleton Session Bean[1]

Singleton Session Bean実装時の注意事項[1]

Singleton Session Beanでのエラー処理[1]

Singleton Session Beanの排他制御[1]

Singleton Session Beanのライフサイクル[1]

Stateful Session Bean[1]

Stateful Session Bean実装時の注意事項[1]

Stateful Session Beanのタイムアウト[1]

Stateful Session Beanのライフサイクル[1]

Stateless Session Bean[1]

Stateless Session Bean実装時の注意事項[1]

Stateless Session Beanのプーリング[1]

Stateless Session Beanのライフサイクル[1]

Supports属性[1]

T

Timer Service[1]

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

U

URLConnectionクラス使用時の注意[1]

V

vbj[1]

vbroker.se.iiop_tp.host[1]

vbroker.se.iiop_tp.scm.iiop_tp.listener.port[1]

あ

アプリケーションサーバ 11-50での主な機能変更[1]

い

インスタンス取得待ちのタイムアウト[1]

インターセプタ[1]

インターセプタの実行順序[1]

か

開発時の注意事項（No-Interface view）[1]

外部リソースとの接続[1]

型変数[1]

く

クラスレベルインターセプタ[1]

クラスローダの取得に関する注意[1]

さ

サブディレクトリ共有モード[1]

し

システムログの出力先や出力レベルの変更[1]

使用できないメソッド（No-Interface view）[1]

た

タイムアウトメソッド[1]

タイムアウトを設定できるRMI-IIOP通信[1]

つ

通信ポートの固定[1]

て

デフォルトインターセプタ[1]

と

トランザクション属性の種類[1]

ね

ネイティブライブラリのロードに関する注意[1]

は

パラメタ化[1]

ひ

ビジネスインタフェースに対応する機能[1]

ビジネスインタフェースのEnterprise Bean呼び出し[1]

ビジネスインタフェースのリファレンスを検索してEnterprise Beanを呼び出す方法[1]

非同期メソッド実装時のアノテーションに関する注意事項[1]

ふ

プライマリキークラスへのインタフェース指定について[1]、[2]

ほ

ほかのJ2EEアプリケーション内にあるEnterprise Beanをコンポーネントインタフェースによって呼び出す方法[1]

ほかのJ2EEアプリケーション内にあるEnterprise Beanをビジネスインタフェースによって呼び出す方法[1]

め

メソッドレベルインターセプタ[1]

ゆ

ユーザ定義型のCMPフィールドの使用についての注意[1]

り

リソースのコネクションの取得と解放[1]

リモートインタフェース[1]

リモートインタフェースでの通信障害発生時のEJBクライアントの動作[1]

リモートインタフェースの参照渡し機能[1]

る

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

ろ

ローカルインタフェース[1]

ローカルインタフェースとリモートインタフェースの使い分け[1]

ローカルビジネスインタフェースの省略[1]

ローカル呼び出し最適化機能の範囲[1]

ローカル呼び出し最適化機能の利用について[1]