ページの先頭行へ戻る
Interstage Application Server V12.0.0 Java EE 7 設計・構築・運用ガイド
FUJITSU Software

14.2.5 EJBアプリケーション/JNDIについて

Enterprise Beanインスタンスのキャッシング

Java EE 5におけるStateful Session Beanでは、チューニング項目「SFSB持続性のタイプ」でBeanインスタンスのキャッシングが変更できるようになっています。デフォルトは「none」が設定されており、Beanインスタンスをファイルシステムに格納することを抑止するため、ユーザーは不要となったファイルの削除を意識する必要がありません。

Java EE 7では、チューニング項目「SFSB持続性のタイプ」は提供されておらず、Java EE 5で「SFSB持続性のタイプ」を「file」に設定した場合と同じ動作になります。以下の点に注意してください。

Stateful Session Beanインスタンスの無通信時間監視機能

Java EE 5におけるStateful Session Beanインスタンスの無通信時間監視機能は、「SFSB持続性のタイプ」の設定内容により、動作が異なります。デフォルトである「none」の場合、キャッシュアイドルタイムアウトで設定した一定時間を超過してもビジネスメソッドが実行されなかったBeanインスタンスはメモリから削除されます。削除したBeanに対して要求が発行されると、例外をクライアントに通知します。

Java EE 7の場合、Java EE 5で「SFSB持続性のタイプ」を「file」に設定した場合と同じ動作になっており、以下の2段階で監視が行われます。

  1. Beanインスタンスの対話状態を一時的にファイルシステムに保存(passivate)

    キャッシュアイドルタイムアウトで設定した一定時間を超過してもビジネスメソッドが実行されなかったBeanインスタンスはファイルシステムにpassivateされ、メモリから削除されます。passivateされた Beanに対して要求が発行されると、コンテナは対話状況をファイルシステムから読み込みBeanを回復(activate)します。コンテナは passivateとactivate処理を正常に行った場合は、メッセージを出力しません。

  2. 保存した対話状態をファイルシステムから削除

    削除タイムアウトで設定した一定時間を超過してBeanに対してビジネスメソッドが実行されなかった場合、コンテナが該当のインスタンス、またはpassivateによりファイルシステムに保存した対話状況を削除します。削除したBeanに対して要求が発行されると、例外をクライアントに通知します。JNDI から新しいStateful Session Beanの参照を取得し対話をし直してください。

オブジェクトリファレンスのキャッシュ

オブジェクトリファレンスのキャッシュは、lookupメソッド実行時に取得されるオブジェクトリファレンスがコンテナ内でキャッシュされる機能でJava EE 5で提供されています。アプリケーションでリクエストの度にlookupを実施している場合、2回目のlookupは、コンテナ内にキャッシュされているオブジェクトリファレンスが返却されます。

Java EE 7にはキャッシュ機能がありません。キャッシュ機能がないことで、性能劣化が懸念されるため、性能試験を実施して問題がないことを確認してください。システムの構成上、リクエストの度にlookupを実施する必要がないのであれば、アプリケーション内でオブジェクトリファレンスをキャッシュすることを検討してください。

Entity Beanの使用について

Java EE 7はEntity Beanをサポートしません。Entity Beanの代わりにJPA機能を使用してください。

環境ネーミングコンテキストのリソース参照名

deployment descriptorファイルのリソース参照(resource-refタグ)でJDBCリソースまたはJMS接続ファクトリのリソース参照名を定義しているがJNDI名との対応付けを定義しなかった場合の動作が異なります。

Java EE 5では、リソース参照名と同じJNDI名に対応付けられます。

Java EE 7では、デフォルトのJDBCリソースまたはデフォルトのJMS接続ファクトリに対応付けられます。デフォルトのJDBCリソースのJNDI名は「jdbc/__default」です。デフォルトのJMS接続ファクトリのJNDI名は「jms/__defaultConnectionFactory」です。

IPCOMを利用したIIOP通信の負荷分散

IPCOMを利用したIIOP通信で利用できる負荷分散方式が異なります。

Java EE 5では以下の負荷分散方式が利用できます。

IPCOM連携

使用するロードバランス機能

使用する

EJBディスパッチ機能によるロードバランス

グループ管理サービスによるロードバランス

ロードバランス機能を使用しない ()

Java EE 7では以下の負荷分散方式が利用できます。

IPCOM連携

使用するロードバランス機能

使用する

ロードバランス機能を使用しない ()

注意

注) IPCOMの設定としてはJava EE 5/Java EE 7どちらも「メソッド呼び出し単位の負荷分散」を設定しますが、呼び出される側のサーバの設定と動作に以下の差異があります。

  • 設定

    呼び出される側のサーバのIIOPリスナーのネットワークアドレスに指定する値が異なります。

    Java EE 5: IPCOMの仮想ホスト名を指定

    Java EE 7: 呼び出される側のサーバの実IPアドレスまたはホスト名を指定

  • 動作

    Java EE 5: IIOP通信は、すべてIPCOM経由で行われます。

    Java EE 7: EJBのlookup呼び出し実行後は、lookupの実行が割り振られたサーバマシンと直接通信します。

また、IPCOMを利用したIIOP通信を行う場合に、アプリケーション作成時に必要な設定が異なります。

Java EE 5ではアプリケーション作成時にモジュールに含むInterstage deployment descriptorファイルのunique-idタグにIJServerクラスタ内で一意のIDを指定する必要があります。

Java EE 7ではアプリケーション作成時にモジュールに含むInterstage deployment descriptorファイルのunique-idタグを指定する必要がありません。


IPCOMを利用したIIOP通信の負荷分散については「2.25 IPCOMを利用したIIOP通信の負荷分散」を参照してください。