3

Struts 1.1 と EJB 2 を組み合わせたアプリケーションがありますが、現在、hibernate 3.2 で新しい部分を導入しています。休止状態の DAO は、純粋な JDBC を使用する EJB 2 セッション Bean DAO と並行して実行されます。この場合、jdbc 接続管理が心配です。EJB 2.0 にはコンテナ管理の接続とトランザクションがあります。しかし、休止状態の場合、休止状態のトランザクションを開始してコミットします。このアーキテクチャに問題はないと想定しても安全でしょうか。

分析の助けが必要です。

午後

トランザクションがセッション Bean によって管理されている JDBC DAO によって使用されている既存のテーブルにアクセスする可能性のある休止状態モジュールの場合、同じ問題について考えていました。しかし、ここに私のアプローチがあります：

  1. EJB セッション Bean を呼び出すデリゲートを作成します。この Bean はトランザクションの管理を担当するため、休止状態の DAO を作成し、このセッション Bean からそれらを呼び出しますが、問題はないと想定しています。

  2. このアプリケーションの休止状態セッション ファクトリは、struts 構成 xml の一部となる休止状態プラグインを使用して一度インスタンス化され、サーブレット コンテキストの一部として保存されます。その後、アクション クラスは、EJB セッション Bean デリゲートからこの sessionfactory インスタンスを渡します。休止状態の DAO に。

  3. トランザクションは Websphere にデプロイされた EJB セッション Bean によって管理されるため、これはクリーンなアプローチになると思います。JDBC 接続プールの管理は websphere で構成され、データソースを使用してアクセスされるため、hibernate はこれについて心配する必要はありません。

私の仮定で正しい道を進んでいるなら、私を助けてください。

4

3 に答える 3

0

これが可能な解決策の1つです

一般的なJNDIデータソース。EJBとHibernateの両方で使用されます。

于 2010-12-06T18:27:01.880 に答える
0

Hibernate は、CMT (または BMT) セッション Bean で問題なく使用でき、接続プールを JDBC コードと共有し、同じトランザクションに参加できます。

セクション11.2全体を参照してください。データベース トランザクションの境界、特に11.2.2。JTA の使用。

明確でないのは、Hibernate モジュールが JDBC を介して管理されるエンティティから「分離」されるかどうかです。両方の API を介して同じテーブルにアクセスする場合は、いくつかの予防策を講じる必要があります。

  • Hibernate エンティティのグラフに JDBC エンティティを混在させることを期待しないでください (逆も可能です)。
  • JDBC を介して行を更新するときに、Hibernate の楽観的同時実行戦略を尊重し、模倣する
  • Hibernate の API をバイパスしてもキャッシュの更新はトリガーされず (2 番目のレベルのキャッシュを使用している場合)、その場合は自分でトリガーする必要があります。
于 2010-11-10T08:59:35.757 に答える
0

トランザクションは作業の論理単位を区切るため、本質的に分離されています。しかし、なぜ両方の組み合わせが必要なのか疑問に思っています。すでに EJB2 + JDBC を使用している場合は、これにこだわってみませんか?

于 2010-11-09T16:10:12.350 に答える