FAQ: EJB

Q. create() メソッドまたは find() メソッドから、ポリモフィック型の応答がないのはなぜですか。

A. EJB 仕様ではこの動作は許されていません。weblogic.ejbc コンパイラは、この動作を厳密にチェックして、create() メソッドまたは find() メソッドからポリモフィック型の応答が戻るのを防止しています。

create() メソッドと find() メソッドがポリモフィックでない理由は、Java でコンストラクタがポリモフィックでない理由とほぼ同じです。派生クラスは、通常、基本クラスを認識しないか、正しく初期化することができません。

Q. EJB はクラスタ全体に均一にデプロイする必要がありますか。なぜでしょうか。

A. はい。WebLogic Server バージョン 6.0 から、EJB は以下の理由によりクラスタ全体に均一にデプロイされなければなりません。

A. フリープールとは、EJB コンテナが所定の Bean タイプの匿名インスタンスをキャッシュするために使用するデータ構造です。フリープールは、できる限りオブジェクトの再利用やコンテナコールバックのスキップをすることでパフォーマンスを改善しています。

Q. どのバージョンの EJB 仕様が WebLogic Server でサポートされていますか。

A. WebLogic Server バージョンでサポートされている EJB 仕様のバージョンを下表にまとめました。

WebLogic Server バージョン	EJB バージョン
4.5.x	1.0
5.1	1.1
6.0	1.1 および 2.0 (PFDI)
6.01	1.1 および 2.0
7.0	1.1 および 2.0

Q. max-beans-in-free-pool は、ステートレス Bean については、どのように設定すべきですか。

Q. initial-beans-in-free-pool は、ステートレス Bean については、どのように設定すべきですか。

Q. ステートレス EJB がパッシベーションされるのはいつですか。

A. ステートレス EJB は決してパッシベーションされません。ステートレス EJB は状態 (ステート) を持たないため、パッシブにする必要がありません。ステートレス EJB は、各メソッド呼び出しの後、他の要求に応えられるようにするため、フリープールに戻されます。

Q. ステートレスセッション Bean の remove() を呼び出せますか。

A. はい。ステートレスセッションBean での remove() は現在は何もしません (noop です)。

Q. ステートレス EJB では、いつ ejbCreate および ejbRemove が呼び出されますか。

A. ステートレス Bean が EJB コンテナによって作成されるときに ejbCreate が、削除されるときに ejbRemove が呼び出されます。これはステートレスホームへの作成および削除の呼び出しと対応しているわけではないことに留意してください。initial-beans-in-free-pool 設定によっては、Bean はフリープールに置かれるポイントでデプロイメント時にコンテナに作成されることがあります。デプロイメント時を除いて、Bean は、フリープール内のすべてのBean が使用中であり、かつ、max-beans-in-free-pool 制限に達していない場合にのみ、要求に応えるために作成されるだけです。ステートレス Bean は、アンデプロイメント時に EJB コンテナにより削除されます。

Q. パッシベーション/アクティベーションを説明できますか。

A. ステートフルセッション EJB 起動時に LockTimedOutException を受け取る場合には、以下の 2 つのうちの 1 つが発生しています。

A. NRU キャッシュは、可能な限り多くのパッシベーションを回避することで機能します。ステートフルセッションインスタンスは、メモリが圧迫されている (キャッシュ内の Bean の数が max-beans-in-cache サイズに近づいている) ときにのみパッシベーションされます。これは、weblogic-ejb-jar.xml 内の「NRU」オプションで、デフォルトの動作です。LRU キャッシュは、idle-timeout-seconds に達した後に Bean がパッシベーションされることで機能します。したがって、max-beans-in-cache が 1000 でメモリ中に 10 Bean しかない場合には、タイムアウト期限が切れた後もさらに 10 Bean はディスクに書き出されます。これが weblogic-ejb-jar.xml の「LRU」オプションです。これは 5.1 と 6.x で追加されました。タイムアウトの動作に依存するアプリケーションを作成していた顧客がいたからです。デフォルトの動作は 3.1-4.5 にもありました。

Q. いつ、ステートフルセッション Bean を使うべきですか。また、サーブレットセッションはいつ使うべきですか。

A. この質問への答えは非常にアプリケーション固有であり、どのアプローチが機能するかは状況次第です。ステートフルセッション Bean は、クラスタ内のセカンダリへのフェイルオーバだけでなく、宣言的トランザクションおよびセキュリティチェックを提供しています。

Q. ステートフルセッションBean 用のキャッシュはどのくらい大きくすべきですか。

A. ステートフルセッションBean 用のキャッシュは通常、その Bean の並行クライアントの最大数と等しくします。これは一般には、サーバ内の実行スレッド数よりもずっと大きな値です。それゆえ、ステートフルセッション Bean はサーバリソースを多めに使用します。

Q. エンティティ Bean は JMS メッセージ用のリスナになれますか。

A. いいえ。 JMS メッセージを消費するにはメッセージ駆動型 Bean が使われます。

Q. CMP フィールドはいつロードされますか。そのタイミングは常に finders-load-bean 設定で決まっていますか。デフォルトの動作は何ですか。

A. Finders-load-bean はデフォルトでは「true」です。Bean を取得するためにfindXXX() メソッドを呼び出す場合は、 Bean は明示的にファインダ経由で検索されます。一方、cmr-field getXXX メソッド経由で Bean を検索する場合には暗黙的に検索されます。いずれの場合でも、その Bean 用の finders-load-bean が「true」であれば、Bean のフィールドのロードを期待していることになります。

ファインダを呼び出さずに、別のトランザクションで獲得した参照を介して Bean にアクセスしようとするだけの場合、2.0 CMP 使用時にはフィールドは常にゆるやかにロードされます。ejbLoad 中は getXXX() メソッドが呼び出されたとき以外は DBMS からは読み出されません。フィールドグループを定義しない場合、デフォルトでは、シングルフィールドグループが 1 つだけあり、そこにはすべてのフィールドが入っています。したがって、cmp-field getXXX() メソッドの呼び出しは、デフォルトでは、永続状態の Bean のすべてをロードします。

Q. delay-database-insert-until デプロイメント記述子要素の目的は何ですか。

A. この設定により、CMP Bean 作成時に、どの時点でデータベース挿入を行うかを指定できます。データベース内の非 null 外部キー制約のため、関係を使用する CMP Bean の作成が複雑になる可能性があります。この設定を使用すると、開発者は非 null 外部キー制約を満たすための一層の柔軟性が得られます。この設定は、WLS 7.0 で追加された一括挿入機能を有効にするためにも必要です。一括挿入機能を有効にするには、また、いかなる非 null 外部キー制約をも満たすように最大限の柔軟性を提供するには、delay-database-insert-until オプションを「commit」に設定することを推奨します。このオプションに関する詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs70/ejb/EJB_environment.html#1118482 を参照してください。

Q. エンティティ Bean を複数のテーブルにマップできますか。

A. WLS 7.0 では、エンティティ Bean を複数のテーブルにマップすることは可能ですが、制約がいくつかあります。具体的には、各テーブルに同一の主キーカラムを含める必要があります。これらのカラムはテーブルが異なれば異なる名前を持てますが、その値は同じでなければなりません。新しい Bean が 1 つ作成されると、1 行が各テーブルに挿入されます。そして、Bean が 1 つ削除されると、各テーブルから 1 行が削除されます。各テーブルの行は、主キーの値を介して関連付けられています。特定のエンティティ Bean にマップされた行は、常に同一の主キー値を持ちます。

Q. 1 対多関係を実装するために結合または中間テーブルを利用できますか。

A. 現在ではサポートされていません。1 対多関係の実装には、その関係 (リレーションシップ) の「多」側の Bean に、そのうちの 1 つのテーブル内で外部キーを 1 つ含めることが必要です。

Q. トランザクションをコミットした後も cmr-field (コンテナ管理による関係) コレクションを持ち続け、それを使用することができないのはなぜですか。

A. これは EJB 2.0 仕様で禁止されています。これが許されていない理由は、トランザクションが一度コミットされると、cmr-field コレクションを戻す DBMS データは予測できない方法で変更可能となるからです。これらの変更を追跡することは困難であり、アプリケーションが予期しないときに cmr-field コレクションの内容が変わってしまう結果となりかねないからです。肝心なのは、開発者が単一トランザクション内部で検索してから cmr-field にアクセスする必要があるということです。

Q. データベース内の外部キーカラムを cmp-field と cmr-field の両方にマップすることはできますか。

A. はい。これは、WLS 6.0 SP1 以降サポートされています。cmp-field が主キーフィールドのとき、cmr-field は読み込み専用であることに注意してください。つまり、setXXX メソッドは cmr-field に対しては使えません。この場合、主キーの値は、普通は初期化されるはずです。逆に、cmp-field が主キーフィールドでない場合には、cmp-field が読み込み専用です。基底のカラムは cmr-field 経由で更新され、cmp-field は外部キーの読み出し専用ビューを提供するだけです。

Q. ejbCreate 中に cmr-field に対して setXXX メソッドを呼び出せないのはなぜですか。

A. これは EJB 2.0 仕様で許されていません。その理由は、カレント Bean の主キーは ejbCreate 中に知られる必要がないからであり、また、それをするにはリレーションシップが基底の DBMS にどのようにマップされるかに依存する必要が出るおそれがあるからです。Bean の生成中に関係を設定する必要がある場合には、cmr-field 設定メソッドは ejbCreate の代わりに ejbPostCreate で呼び出すことになります。

Q. cmr-field にマップされた外部キーに関して、NOT NULL 制約違反を回避するのはどうすればできますか。

A. WLS 7.0 では、delay-database-insert-until を「commit」に設定でき、現在のトランザクションをコミットする前に cmr-field に値を割り当てることができます。また、delay-database-insert-until を「ejbPostCreate」に設定して、ejbPostCreate 中に cmr-field に値を割り当てることもできます。

Q. WebLogic は、エンティティ Bean について、主キー自動生成をサポートしていますか。

A. はい。この機能は WLS 6.1 で追加されました。詳細については、<automatic-key-generation> 要素の DTD コメントを参照してください。ブラウザで次の URL を参照してください。

Q. JMS 接続時に MDB が使用するのは、どのセキュリティプリンシパルですか。

A. WLS 6.1 SP2 時点では、MDB は JMS 接続とメッセージ処理とで同じプリンシパルを使います。これは、プリンシパルが、Bean に固有の run-as ロールにマップされるか、または run-as ロールが指定されていない場合に「guest」にマップされるかのいずれかです。WLS 6.1 SP2 より前は、この動作は明確には定義されていませんでした。

Q. EJB コンテナのトランザクションに JDBC 接続が参加するには、どのようにして JDBC 接続を取得すべきですか。

A. TxDataSource または JTS ドライバから JDBC 接続を取得する必要があります。普通の DataSource または直接 JDBC ドライバから JDBC 接続を取得すると、その JDBC 接続はEJB 接続トランザクションに参加しません。

JTS ドライバに直接アクセスするよりは、TxDataSources を推奨します。TxDataSources は、DBC 2.0 では接続プール用の標準機構で、2PC/XA トランザクションをサポートしています。

Q. トランザクションを中止しましたが、データベースの変更はロールバックされませんでした。

A. 前の質問を参照してください。TxDataSource から JDBC 接続を取得する必要があります。

Q. JDBC コードがロールバックの SQLException を送出した理由は何ですか。

WebLogic JTS JDBC ドライバがこの例外を送出するのは、現在の JDBC 接続トランザクションが JDBC 呼び出しの前または途中でロールバックされた場合です。この例外は、JDBC 接続が関わっていたトランザクションが JDBC 呼び出しの前または途中でロールバックされたことを示します。

ロールバックはトランザクションの一部である EJB の呼び出しで発生したか、トランザクションのタイムアウトが原因で発生しています。どちらの場合でも、トランザクションはロールバックされ、接続はプールに戻り、データベースリソースは解放されます。処理を進めるには、JTS JDBC 接続を閉じて、新しいトランザクションで再び開く必要があります。