1

Hibernate を使用して Java SE (注: Java EE ではない) アプリケーションを作成していますが、実行スレッドごとに Hibernate への異なる接続を提供する必要があります。これらの接続はプールする必要があり、それぞれに少なくとも異なる認証があり、場合によっては異なる JDBC URL があります。接続は再利用されます (プーリング要件から推測できます)。

Hibernate/C3P0/et al のどの部分をオーバーライドする必要がありますか? これはこれらのツールで実現できますか? それとも、独自のプーリング データ ソースを作成する必要がありますか?

4

2 に答える 2

1

ここで 2 つの質問があります。

  1. 接続はスレッド セーフではないため、各スレッドには独自の接続が必要です。Hibernate を使用しているため、アプリケーションが実際に見るのは、SessionFactory から取得したセッションです。これを利用するには、SessionFactory#getCurrentSession() メソッドを呼び出し、hibernate.cfg.xml で現在のセッション コンテキストを構成します。 
    <property name="current\_session\_context\_class">スレッド</property>
    hibernate.cfg.xml で適切にスレッド プーリングを構成した場合 (c3po または任意のプーリング メカニズムを使用)、各スレッドはそのプールから接続を取得します。
  2. アプリケーションが処理する必要のある複数のデータ ソースを維持するには、アクセスする JDBC URL ごとに個別の SessionFactory を構成する必要があります。アプリケーションでは、選択する必要がある SessionFactory で選択するいくつかの手段が必要です (「クライアント ID」など)。これを使用して、マップまたはそのようなデータ構造 (Java 内) で各 SessionFactory インスタンスを管理できます。 JNDI から参照を取得する EE アプリ)。

要約 (および一般化) すると、基本的に SessionFactory は、本質的に DataSource (および付随する接続プール) の巨大なラッパーです。読み取り専用 (したがってスレッド セーフ)、重量級、静的であり、一度構築され、特定の DataSource について必要なすべてを認識します。

一方、セッションは、本質的に接続の軽量ラッパーです。これはスレッドセーフではなく、多くの場合寿命が短く、使用後に破棄することを意図しています。

お役に立てれば！

于 2009-04-24T01:13:39.667 に答える
1

SessionFactoryおそらくプールされた接続を使用して、データソースごとに作成するのが最善の方法だと思います-それが彼の答えで提案されている eqbridges です。

現在、Hibernate にはフックがあるため、現在の実行スレッドといくつかの追加パラメーターに応じて、さまざまなデータ ソースに s をConnectionProvider返す実装を作成できると思います。Connection理論的には、カスタム実装SessionFactoryによって提供される、異なるデータベースへの異なる接続を使用する 1 つのインスタンスを持つことができます。ConnectionProviderしかし、SessionFactoryかなりの量のデータを保持し、そのデータは Hibernate によって内部で使用されSession、作業単位のために が開かれます。さらに、それに関連付けられた第 2 レベルのキャッシュもあります。

残念ながら、ファクトリとSessionそこから開いた s が、そのようなプロバイダの前でどのように動作するかは誰にもわかりません。私にはハックのように感じますSessionFactory.. あらゆる種類の、場合によっては非常に微妙なバグやデータの破損につながる可能性があります。

別の注意点として、複数作成する場合のコストを正確に測定しSessionFactoriesてください。思ったほど高くないかもしれません。必要な JDBC 接続を開くだけのコストと比較してください。どのような結果が得られるかはわかりませんが、よりハックなソリューションに頼る前に、パフォーマンスについて確認する必要があると思います。

于 2009-04-24T19:35:13.420 に答える