FAQ: EJB

 

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

• Bean 管理の永続性メカニズムでは WebLogic JTS ドライバを使用する必要がありますか。

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

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

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

JDBC コードは次の例外を送出する場合があります。

"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 接続を閉じて、新しいトランザクションで再び開く必要があります。

Bean 管理の永続性メカニズムでは WebLogic JTS ドライバを使用する必要がありますか。

Bean 管理の永続性には TxDataSource を使用することをお勧めします。

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

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

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

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

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

• クラスタ化 EJB をシンプルに保つため。

• クロス サーバ呼び出しを回避することによって能率を上げるため。EJB がすべてのサーバにデプロイされていない場合、クロス サーバ呼び出しが発生する可能性が高まります。

• すべてのEJBがローカルに使用できるようにするため。

• すべてのクラスタがデプロイ不可能な方法でロードされるようにするため。

• 各サーバは、ローカル JNDI ツリーにバインドされるよう各 EJB のクラスにアクセスしなければなりません。サーバのサブセットだけが EJB をデプロイした場合、他のサーバはその Bean のクラスをそれぞれのシステム クラスパスにロードする必要があります。これにより、Bean をアンデプロイすることができなくなります。