Enterprise Beanインスタンスのキャッシング
Java EE 5におけるStateful Session Beanでは、チューニング項目「SFSB持続性のタイプ」でBeanインスタンスのキャッシングが変更できるようになっています。デフォルトは「none」が設定されており、Beanインスタンスをファイルシステムに格納することを抑止するため、ユーザーは不要となったファイルの削除を意識する必要がありません。
Jakarta EE 8では、チューニング項目「SFSB持続性のタイプ」は提供されておらず、Java EE 5で「SFSB持続性のタイプ」を「file」に設定した場合と同じ動作になります。以下の点に注意してください。
GlassFish Serverクラスター停止状態でStateful Session Beanを配備解除した場合、「セッション格納位置」配下の資産は削除されません。このときはアプリケーション配備解除後にユーザーが資産を削除してください。
GlassFish Serverクラスター起動状態でStateful Session Beanを配備解除した場合、「セッション格納位置」配下の資産は削除されます。GlassFish Serverクラスター起動状態では「セッション格納位置」配下の資産の削除をユーザーは行わないでください。
passivateする時には Beanインスタンスを直列化してファイルシステムに格納します。このため、Beanインスタンスから参照するオブジェクトが直列化できる (java.io.Serializableインターフェイスを実装するなど)必要があります。Beanインスタンスが直列化できない場合には java.io.NotSerializableException例外が発生してpassivateに失敗し、そのBeanインスタンスは削除されます
EJBコンテナはGlassFish Serverクラスターの停止時にキャッシュしている全Beanインスタンスをpassivateします。ただしGlassFish Serverクラスターを強制停止した場合は、EJBコンテナはpassivateせずに終了します。
Stateful Session Beanインスタンスの無通信時間監視機能
Java EE 5におけるStateful Session Beanインスタンスの無通信時間監視機能は、「SFSB持続性のタイプ」の設定内容により、動作が異なります。デフォルトである「none」の場合、キャッシュアイドルタイムアウトで設定した一定時間を超過してもビジネスメソッドが実行されなかったBeanインスタンスはメモリから削除されます。削除したBeanに対して要求が発行されると、例外をクライアントに通知します。
Jakarta EE 8の場合、Java EE 5で「SFSB持続性のタイプ」を「file」に設定した場合と同じ動作になっており、以下の2段階で監視が行われます。
Beanインスタンスの対話状態を一時的にファイルシステムに保存(passivate)
キャッシュアイドルタイムアウトで設定した一定時間を超過してもビジネスメソッドが実行されなかったBeanインスタンスはファイルシステムにpassivateされ、メモリから削除されます。passivateされた Beanに対して要求が発行されると、コンテナは対話状況をファイルシステムから読み込みBeanを回復(activate)します。コンテナは passivateとactivate処理を正常に行った場合は、メッセージを出力しません。
保存した対話状態をファイルシステムから削除
削除タイムアウトで設定した一定時間を超過してBeanに対してビジネスメソッドが実行されなかった場合、コンテナが該当のインスタンス、またはpassivateによりファイルシステムに保存した対話状況を削除します。削除したBeanに対して要求が発行されると、例外をクライアントに通知します。JNDI から新しいStateful Session Beanの参照を取得し対話をし直してください。
オブジェクトリファレンスのキャッシュ
オブジェクトリファレンスのキャッシュは、lookupメソッド実行時に取得されるオブジェクトリファレンスがコンテナ内でキャッシュされる機能でJava EE 5で提供されています。アプリケーションでリクエストの度にlookupを実施している場合、2回目のlookupは、コンテナ内にキャッシュされているオブジェクトリファレンスが返却されます。
Jakarta EE 8にはキャッシュ機能がありません。キャッシュ機能がないことで、性能劣化が懸念されるため、性能試験を実施して問題がないことを確認してください。システムの構成上、リクエストの度にlookupを実施する必要がないのであれば、アプリケーション内でオブジェクトリファレンスをキャッシュすることを検討してください。
環境ネーミングコンテキストのリソース参照名
deployment descriptorファイルのリソース参照(resource-refタグ)でJDBCリソースまたはJMS接続ファクトリのリソース参照名を定義しているがJNDI名との対応付けを定義しなかった場合の動作が異なります。
Java EE 5では、リソース参照名と同じJNDI名に対応付けられます。
Jakarta EE 8では、デフォルトのJDBCリソースまたはデフォルトのJMS接続ファクトリに対応付けられます。デフォルトのJDBCリソースのJNDI名は「jdbc/__default」です。デフォルトのJMS接続ファクトリのJNDI名は「jms/__defaultConnectionFactory」です。
IPCOMを利用したIIOP通信の負荷分散
IPCOMを利用したIIOP通信で利用できる負荷分散方式が異なります。
Java EE 5では以下の負荷分散方式が利用できます。
IPCOM連携 | 使用するロードバランス機能 |
|---|---|
使用する | EJBディスパッチ機能によるロードバランス |
グループ管理サービスによるロードバランス | |
ロードバランス機能を使用しない (注) |
Jakarta EE 8では以下の負荷分散方式が利用できます。
IPCOM連携 | 使用するロードバランス機能 |
|---|---|
使用する | ロードバランス機能を使用しない (注) |
注意
注) IPCOMの設定としてはJava EE 5/Jakarta EE 8どちらも「メソッド呼び出し単位の負荷分散」を設定しますが、呼び出される側のサーバーの設定と動作に以下の差異があります。
設定
呼び出される側のサーバーのIIOPリスナーのネットワークアドレスに指定する値が異なります。
Java EE 5: IPCOMの仮想ホスト名を指定
Jakarta EE 8: 呼び出される側のサーバーの実IPアドレスまたはホスト名を指定
動作
Java EE 5: IIOP通信は、すべてIPCOM経由で行われます。
Jakarta EE 8: EJBのlookup呼び出し実行後は、lookupの実行が割り振られたサーバーマシンと直接通信します。
また、IPCOMを利用したIIOP通信を行う場合に、アプリケーション作成時に必要な設定が異なります。
Java EE 5ではアプリケーション作成時にモジュールに含むInterstage deployment descriptorファイルのunique-idタグにIJServerクラスタ内で一意のIDを指定する必要があります。
Jakarta EE 8ではアプリケーション作成時にモジュールに含むGlassFish deployment descriptorファイルのunique-idタグを指定する必要がありません。
IPCOMを利用したIIOP通信の負荷分散については「2.25.1 IPCOMを利用したIIOP通信の負荷分散」を参照してください。
