HibernateまたはTopLinkの代替品ですか？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/413131

質問

Hibernateの実行可能な代替手段はありますか？ JPAに基づかないものが望ましい。

問題は、複雑な（多くのオブジェクトが相互に参照する）ステートフルRIAシステムを構築していることです。 Hibernateは主に一時的なアプリケーション（JSFなど）で使用されるように設計されているようです。

問題は主に遅延読み込みの問題です。初期化と実際の遅延コレクションのロードの間には複数のHTTPリクエストが存在する可能性があるため、トランザクションごとのセッションは問題外です。トランザクションがスナッグに到達して例外をスローすると、セッション全体が無効になり、遅延ロードされたオブジェクトが破損するため、長時間のセッション（アプリケーションごとに1つ）もうまく機能しません。それから、私たちにはうまくいかないあらゆる種類のものがあります（初期化されたトランザクションの外部からのデータの暗黙的なデータ永続化など）。

私の悪い説明はさておき、一番下の行は、Hibernateが私たちが好きではない魔法をするということです。 TopLinkの方が優れているわけではなく、EJBの上に記述されているようです。

したがって、ステートレス永続層（またはオブジェクト指向のデータベース抽象化層）が最も必要なものです。

何か考えがありますか、それとも存在しないものを求めていますか？

編集：あいまいな用語でごめんなさい。訂正と洞察に満ちた答えをありがとう。私を修正した人、あなたはすべて正しいです、EJBではなくJPAを意味しました。

役に立ちましたか？

解決

前述のとおり、JPA <！> lt; <！> gt; EJB、それらは関係さえありません。 EJB 3はたまたまJPAを活用していますが、それだけです。 JPAを使用するものがたくさんありますが、EJBの実行に近づいていません。

あなたの問題はテクノロジーではなく、あなたのデザインです。

または、あなたのデザインは、現代のほとんどのフレームワークに簡単に適合するものではありません。

具体的には、複数のHTTPリクエストにわたってトランザクションを存続させようとしています。

当然、ほとんどの一般的なイディオムは、各リクエストがそれ自体で1つ以上のトランザクションであり、各リクエストがより大きなトランザクションの一部であるということです。

用語<！> quot; stateless <！> quot;を使用した場合も明らかな混乱があります。および<！> quot; transaction <！> quot;同じ議論で、トランザクションは本質的にステートフルです。

あなたの大きな問題は、単にトランザクションを手動で管理することです。

トランザクションが複数のHTTPリクエストで発生し、それらのHTTPリクエストがたまたま<！> quot; very quick <！> quot;で実行されている場合、実際の問題は発生しないはずです。データベーストランザクション機能を活用するために、HTTPリクエストが同じDB接続を使用していることを確認する必要があります。

つまり、簡単に言えば、DBへの接続を取得してセッションに挿入し、トランザクションの期間中、すべてのHTTPリクエストが同じセッションだけでなく、実際の接続がまだ有効であるような方法。具体的には、あるマシンから別のマシンへのフェイルオーバーまたはロードバランシングを実際に乗り切る市販のJDBC接続があるとは思わない。

したがって、単純に、DBトランザクションを使用する場合は、必ず同じDB接続を使用する必要があります。

今、長時間実行されるトランザクションに<！> quot;ユーザーインタラクション<！> quotがある場合、その中で、つまり、DBトランザクションを開始して、ユーザーが<！> quot;何かをする<！> quot;するのを待つと、非常に簡単に、その設計はすべて間違っています。特に対話型環境での長命のトランザクションは単に悪いだけなので、あなたはそれをしたくありません。 Like !!! quot; Crossing The Streams <！> quot;悪い。しないでください。バッチトランザクションは異なりますが、インタラクティブな長期トランザクションは不良です。

あなたは、インタラクティブなトランザクションを実用的な限り短命に保ちたい。

今、トランザクションに同じDB接続を使用できるかどうかを確認できない場合、おめでとうございます。独自のトランザクションを実装できます。つまり、バックエンドにトランザクション機能がないかのように、システムとデータフローを設計できるようになります。

それは本質的に、<！> quot; commit <！> quot;に独自のメカニズムを考え出す必要があることを意味します。データ。

これを行うための良い方法は、データを1つの<！> quot; transaction <！> quot;に段階的に構築することです。ドキュメント、次にそのドキュメントを<！> quot; save <！> quot;にフィードします。実際の作業の多くを行うルーチン。同様に、データベースに行を保存し、<！> quot; unsaved <！> quot;としてフラグを立てることができます。すべての行でそれを行い、最後に保存したすべてのデータを実行するルーチンを呼び出し、すべてを<！> quot; saved <！> quotとしてマークします。単一のトランザクションミニバッチプロセスで。

その間、他のすべてのSQL <！> quot; ignores <！> quot; <！> quot; saved <！> quot;ではないデータ。いくつかのタイムスタンプを投入し、刈り取りプロセスを清掃します（本当に気にしたい場合は、ボリュームに応じて、DBにデッドローを残すほうが実際に安くなる場合があります）、これらのデッド<！> quot; unsaved <！ > quot;行。これらは<！> quot; uncomitted <！> quot;トランザクション。

見た目ほど悪くはありません。本当にステートレスな環境が必要な場合、これは私には聞こえますが、このようなことをする必要があります。

マインド、このすべてにおいて、永続化技術は本当に私とは何の関係もありませんt。問題は、技術ではなくトランザクションの使い方です。

他のヒント

別のJPAプロバイダーをお探しの場合（Hibernateはこれらの1つです）、 EclipseLink 。 TopLink EssentialsのJPA 1.0リファレンス実装よりもはるかに完全に機能します。実際、EclipseLinkはGlassfish V3 Finalに同梱されるJPA 2.0リファレンス実装になります。

JPAは、コンテナの内側と外側の両方で使用できるため、優れています。 JPAを使用して効果を発揮するSwingクライアントを作成しました。 EJB 2.0 / 2.1に付属していたのと同じスティグマとXMLの荷物はありません。

さらに軽量なソリューションをお望みの場合は、 ibatis を検討してください。 Javaプラットフォームに最適な永続化テクノロジーになりました。軽量で、SQLに依存しています（ORMユーザーがORMで優れたSQLを生成するのにどれだけの時間を費やしているのかは驚くべきことです）。また、JPAの90〜95％を実行します（必要に応じて関連エンティティの遅延読み込みを含む）。

いくつかの点を修正するだけです：

  • JPAはEJBの永続層であり、EJB上に構築されていません。
  • 適切なJPAプロバイダーはすべて、大量のキャッシュを実行しているため、すべてを把握するのは難しい場合があります（これは<！> quot; Why Simplicity So Complex？<！> quot;の良い例でしょう）。 。あなたが指示していないことをしているのでなければ、例外は管理オブジェクトの問題ではないはずです。ランタイム例外は通常、トランザクションをロールバックします（Springのトランザクション管理を使用している場合、誰がそれをしないのですか？）。プロバイダーは、ロードまたは永続化されたオブジェクトのキャッシュされたコピーを保持します。エンティティマネージャーの外部で更新する場合（明示的なキャッシュフラッシュまたはEntityManager.refresh()の使用が必要）、これは問題になる可能性があります。

apache cayenne をご覧ください。これは<！> quot; big <！> quot;フレームワーク。適切なモデラーにより、学習曲線は優れたドキュメントによって短縮されます。

昨年 SimpleORM を見て、その軽量で魔法のないデザインに非常に感銘を受けました。現在、バージョン3があるようですが、私はそのバージョンを使用した経験がありません。

Ebean ORM（ http://www.avaje.org ）

使用するのは、よりシンプルで直感的なORMです。

  • マッピングにJPAアノテーションを使用（@ Entity、@ OneToManyなど）
  • セッションレスAPI-HibernateセッションまたはJPAエンティティマネージャーなし
  • 遅延読み込みは機能します
  • パフォーマンス向上のための部分オブジェクトのサポート
  • <！> quot; Autofetch <！> quot;による自動クエリ調整
  • 春の統合
  • 大規模なクエリのサポート
  • バッチ処理の優れたサポート
  • バックグラウンドフェッチ
  • DDL生成
  • 必要に応じて生のSQLを使用できます（Ibatisと同様）

  • LGPLライセンス

  • ロブ。

BEA Kodo（以前のSolarmetric Kodo）も別の選択肢です。 JPA、JDO、およびEJ3をサポートしています。高度な設定が可能で、積極的なプリフェッチ、オブジェクトのデタッチ/アタッチなどをサポートできます。

ただし、これまで説明してきたことから、Toplinkは問題を処理できるはずです。ほとんどの場合、リクエストの開始および終了に応じて、永続層からオブジェクトをアタッチ/デタッチできるようにする必要があるようです。

参照のため、OPの設計が彼の最大の問題である理由：トランザクションを複数のユーザーリクエストにまたがるということは、アプリに接続しているユーザーと同じ数のオープントランザクションを持つことができることを意味します。コミット/ロールバックされます。同時に何千人ものユーザーが接続する場合、これは潜在的に数千の接続を意味します。ほとんどのデータベースはこれをサポートしていません。

HibernateもToplink（EclipseLink）もEJBに基づいていません。どちらもPOJO永続フレームワーク（ORM）です。

前の答えに同意します：iBatisはORMフレームワークの優れた代替手段です。つまり、SQLを完全に制御し、優れたキャッシュメカニズムを備えています。

もう1つのオプションはTorqueです。上記のオプションのいずれよりも優れているとは言いませんが、それはもう1つのオプションです。 現在、かなり古くなっていますが、要件の一部に適合する場合があります。

トルク

tox のようなパラダイムを完全に破ることを検討してください。 Javaクラスが必要な場合、XML結果を JDOM にロードできます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top