WebLogic Server FAQ 集
|
 |
 |
|
Q. create() メソッドまたは find() メソッドから、ポリモフィック型の応答がないのはなぜですか。
A. EJB 仕様ではこの動作は許されていません。weblogic.appc コンパイラは、この動作を厳密にチェックして、create() メソッドまたは find() メソッドからポリモフィック型の応答が戻るのを防止しています。
create() メソッドと find() メソッドがポリモフィックでない理由は、Java でコンストラクタがポリモフィックでない理由とほぼ同じです。派生クラスは、通常、基本クラスを認識しないか、正しく初期化することができません。
Q. EJB はクラスタ全体に均一にデプロイする必要がありますか。なぜでしょうか。
A. はい。WebLogic Server 6.0 以降では、EJB は以下の理由によりクラスタ全体に均一にデプロイされなければなりません。
A. フリー プールとは、EJB コンテナが所定の Bean タイプの匿名インスタンスをキャッシュするために使用するデータ構造です。フリー プールは、できる限りオブジェクトの再利用やコンテナ コールバックのスキップをすることでパフォーマンスを改善しています。
A. Sun の EJB サイトからダウンロードできます。
Q. どのバージョンの EJB 仕様が WebLogic Server でサポートされていますか。
A. WebLogic Server バージョンでサポートされている EJB 仕様のバージョンを下表にまとめました。
Q. max-beans-in-free-pool は、ステートレス Bean については、どのように設定すべきですか。
A. この件については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「ステートレス セッション EJB のプール」を参照してください。
Q. initial-beans-in-free-pool は、ステートレス Bean については、どのように設定すべきですか。
A. この件については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「ステートレス セッション EJB のプール」を参照してください。
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. パッシベーションとアクティベーションは、ステートフル セッション Bean のライフサイクルの標準的な一部です。詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「ステートフル セッション EJB のキャッシュとパッシベーション」を参照してください。
Q. 例外 LockTimedOutException を受け取るのはなぜですか。
A. ステートフル セッション EJB 起動時に LockTimedOutException を受け取る場合には、以下の 2 つのうちの 1 つが発生しています。
weblogic-ejb-jar.xml 記述子内の <allow-concurrent-calls> を「true」に設定してあり、呼び出しが処理されるのを待っている間にタイムアウトした。この場合に使用されるタイムアウトは weblogic-ejb-jar.xml 記述子の <trans-timeout-seconds> 要素の値またはそのデフォルト値の 30 秒です。 <allow-concurrent-calls> を「true」に設定せずに、別のリクエストを処理しているビジー状態のステートフル セッション Bean を呼び出そうとした。この場合には、2 番目の呼び出しではブロックされずに直ちに LockTimedOutException が送出されます。Q. NRU キャッシュと LRU キャッシュの違いは何ですか。
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 使用時にはフィールドは常にゆるやかに (lazily) ロードされます。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」に設定することを推奨します。詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「データベース挿入の遅延」を参照してください。
Q. エンティティ Bean を複数のテーブルにマップできますか。
A. WLS 8.1 では、エンティティ Bean を複数のテーブルにマップすることは可能ですが、制約がいくつかあります。具体的には、各テーブルに同一の主キー カラムを含める必要があります。これらのカラムはテーブルが異なれば異なる名前を持てますが、その値は同じでなければなりません。新しい Bean が 1 つ作成されると、1 行 (row) が各テーブルに挿入されます。そして、Bean が 1 つ削除されると、各テーブルから 1 行が削除されます。各テーブルの行は、主キーの値を介して関連付けられています。特定のエンティティ Bean にマップされた行は、常に同一の主キー値を持ちます。『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「コンテナ管理による関係 (CMR) の使用」を参照してください。
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 コメント (http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd) を参照してください。
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 を送出した理由は何ですか。
"The coordinator has rolled back the transaction.
No further JDBC access is allowed within this transaction."
WebLogic JTS JDBC ドライバがこの例外を送出するのは、現在の JDBC 接続トランザクションが JDBC 呼び出しの前または途中でロールバックされた場合です。この例外は、JDBC 接続が関わっていたトランザクションが JDBC 呼び出しの前または途中でロールバックされたことを示します。
ロールバックはトランザクションの一部である EJB の呼び出しで発生したか、トランザクションのタイムアウトが原因で発生しています。どちらの場合でも、トランザクションはロールバックされ、接続はプールに戻り、データベース リソースは解放されます。処理を進めるには、JTS JDBC 接続を閉じて、新しいトランザクションで再び開く必要があります。
|
|
|