問題タブ [second-level-cache]

NHibernate 2.1.1.4000 に対してビルドされた s#arp を使用していますが、NHibernate.Caches.SysCache を第 2 レベルのキャッシュとして使用したいと考えています。ただし、Nhibernate contrib キャッシュは NHibernate 2.1.2.4000 に対して構築されているため、明らかに問題が発生します。

NHibernate 2.1.1.4000 に対してビルドされた NHibernate.Caches.SysCache.dll をダウンロードできる URL を教えてください。

または、実装が簡単で、NHibernate 2.1.1.4000 に対して構築された別の第 2 レベルのキャッシュ プロバイダーがありますか?

ありがとう

ASP.NET キャッシュを使用してクエリ結果を NHibernate 2nd Level Caching の上にキャッシュし、パフォーマンスを向上させることを検討する必要がありますか?

私のアプリケーションには、クライアント、Web 層 (負荷分散)、アプリケーション層 (負荷分散)、およびデータベース層が含まれています。Web 層はサービスをクライアントに公開し、呼び出しをアプリケーション層に転送します。次に、アプリケーション層はデータベースに対して (NHibernate を使用して) クエリを実行し、結果を返します。

データはほとんどが読み取られますが、特に新しいデータがシステムに入力されると、書き込みがかなり頻繁に発生します。多くの場合、データは集約され、元のデータではなく、それらの集約がクライアントに返されます。

通常、ユーザーは最近のデータ (たとえば、過去 1 週間) の集計に関心があります。したがって、過去 7 日間のすべてのデータを含むキャッシュを導入することは理にかなっています。ある範囲のエンティティを集約する必要があり、その範囲はフィルタなどの他の複雑さとともにクライアントによって決定されるため、エンティティがロードされたときにエンティティをキャッシュすることはできません。特定の時間範囲で、その範囲内のすべてのデータがキャッシュにあるかどうかを知る必要があります。

私の理想的なファンタジーの世界では、サービスをまったく変更する必要はありません。

NHibernate にフックし、キャッシュに対して HQL/基準クエリを実行できるかどうかをインテリジェントかつ透過的に判断し、必要な場合にのみデータベースにアクセスする別のフィルタリング レイヤーが存在します。すべてのデータがキャッシュにある場合は、インメモリ データベースのように、キャッシュされたデータ自体にクエリを実行します。

しかし、最初の調査では、NHibernate の 2 番目のレベルのキャッシュ メカニズムは私のニーズに適していないようです。私ができるようにしたいのは：

1. 過去 7 日間分のデータが常にキャッシュにあるように構成します。例えば。「このテーブルでは、このフィールドが 7 日前から現在までの間にあるすべてのレコードをキャッシュします。」
2. キャッシュを手動で維持する機能があります。新しいデータがシステムに入ると、キャッシュが無効になるまで待つのではなく、直接キャッシュに入れることができればいいのにと思います。同様に、データが期間外になると、キャッシュからプルできるようにしたいと考えています。
3. NHibernate に、データベースにまったくアクセスするのではなく、キャッシュから直接クエリを提供できるタイミングをインテリジェントに理解させます。例えば。ユーザーが過去 3 日間のデータの集計を要求した場合、その集計は DB にアクセスするのではなく、キャッシュから直接計算する必要があります。

今、私は #3 があまりにも多くを求めていると確信しています。キャッシュに必要なすべてのデータを取り込むことができたとしても、NHibernate はそのデータを効率的にクエリする方法を知りません。クエリに関連するものを区別するために、文字通りすべてのエンティティをループする必要があります (正直なところ、これで問題ないかもしれません)。また、データベースではなくオブジェクトに対して実行する NHibernate のクエリ エンジンの実装が必要になります。しかし、私は夢を見ることができますよね？

#3 の要求が多すぎると仮定すると、サービスに次のようなロジックが必要になります。

これは理想的ではありません。これは、各サービスがキャッシュを認識する必要があり、集計ロジックを複製する必要があるためです。1 回は NHibernate を介してデータベースをクエリするため、もう 1 回はキャッシュをクエリするためです。

とはいえ、少なくとも関連データを NHibernate の第 2 レベルのキャッシュに格納できればいいのですが。そうすることで、(集約を行わない) 他のサービスが透過的にキャッシュの恩恵を受けることができます。また、システムの他の場所で第 2 レベルのキャッシュが必要であると判断した場合に、キャッシュされたエンティティ (第 2 レベルのキャッシュに 1 回、自分の別のキャッシュに 1 回) を 2 倍にしないようにします。

実行時に の実装を把握できればICache、メソッドを呼び出しPut()てデータをキャッシュに入れるだけでよいのではないかと思います。しかし、これは危険な地面を踏んでいる可能性があります...

私の要件のいずれかが NHibernate の第 2 レベルのキャッシュ メカニズムによって満たされるかどうかについて、誰か洞察を提供できますか? それとも、独自のソリューションをロールバックして、NHibernate の第 2 レベルのキャッシュを完全に放棄する必要がありますか?

ありがとう

PS。キューブを使用して集計計算をより迅速に行うことを既に検討しましたが、それでもデータベースがボトルネックとして残ります。キャッシュに加えてキューブを使用することもできますが、キャッシュがないことが今の私の主な関心事です。

内部でnHibernateを使用するWCFを使用して作成されたデータサービスがあります。このWCFデータサービスは、Tcpチャネルを使用してWebサーバーに展開されたAsp.Netアプリケーションによって使用されます。

nHibernate Dataサービスのパフォーマンスを向上させるために、nHibernateの第2レベルのキャッシュを実装したいと思います。このシーンでは、どの第2レベルのキャッシュプロバイダーが適していますか？SysCacheはAsp.netキャッシュを使用しているので、おそらくWCFサービス内では使用できませんか？

上記のWCFデータサービスは、アプリケーションのスケーラビリティを向上させるために、異なるサーバー上に複数のインスタンスを持つことができます。

パフォーマンスが良くないシステムで nHibernate 1.2 を使用しています。最新バージョンの nHibernate に移行すると、パフォーマンスが向上しますか?

全体として、最新バージョンの nHibernate に移行することは良い考えですか?

編集:パフォーマンスを向上させるために、次の機能を使用したいと思います。
1. 二次キャッシュ。2. 結合されたテーブル。3. クエリをバッチ処理するマルチクエリ。

NHとFNHのトランクバージョンを入手しました。2次キャッシュを追加しようとすると、NHibernateの一部が選択されたsqldialectを忘れてしまいます。

初期構成：

有罪のカスタムクエリ：

構成を次のように変更すると：

クエリがエラーをスローします（WITHmssql2008で句が追加されました）：

クエリは「SELECT」または「SELECTDISTINCT」で始まる必要があります

[NotSupportedException：クエリは「SELECT」または「SELECTDISTINCT」で開始する必要があります] NHibernate.Dialect.MsSql2000Dialect.GetAfterSelectInsertPoint（SqlString sql）+179 NHibernate.Dialect.MsSql2000Dialect.GetLimitString（SqlString querySqlString、Int32 offset、Int32 limit）+119 NHibernate .Dialect.MsSql2005Dialect.GetLimitString（SqlString querySqlString、Int32 offset、Int32 last）+127 NHibernate.Loader.Loader.PrepareQueryCommand（QueryParameters queryParameters、Boolean scroll、ISessionImplementor session）+725 NHibernate.Loader.Loader.DoQuery（ISessionImplementor session、QueryParameters queryParameters 、ブールreturnProxies）+352 NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections（ISessionImplementorセッション、QueryParameters queryParameters、ブールreturnProxies）+114NHibernate.Loader。Loader.DoList（ISessionImplementorセッション、QueryParameters queryParameters）+205

nhibernateを正確に混乱させるアイデアとそれを修正する方法はありますか？

有罪のNHibernateコード（NHibernate / Dialect / MsSql200Dialect.cs内）：

.SetMaxResults(123)これを引き起こすように見えます。幸いなことに、私はそのクエリのバインドを解除できます。

うまくいけば、それはこれを修正するでしょう。

コードを介してNHibernateの第2レベルのキャッシュ全体をクリアしたいと思います。使用されているキャッシュプロバイダーに依存しない、これを行う方法はありますか？（同じアプリケーション内でmemcacheとsyscacheの両方を使用しているお客様がいます）。

データベースの外部で変更が発生した可能性があるため、キャッシュ全体をクリアしたいと考えています（また、影響を受けたテーブル/エンティティについては保証されていないため、最悪の事態を想定する必要があります）。

同じセッションで頻繁にアクセスされる大きなエンティティがいくつかあります。たとえば、私のアプリケーションには、動的に生成されたチャート画像で構成されるレポート ページがあります。このページのチャート画像ごとに、クライアントは対応するコントローラーにリクエストを行い、コントローラーはいくつかのエンティティを使用して画像を生成します。これらのエンティティを「キャッシュ」するために asp.net のセッション ディクショナリを使用するか、たとえばキャッシュされたクエリを使用して nhibernate の第 2 レベルのキャッシュ サポートに依存することができます。

あなたの意見は何ですか？

ところで、共有ホスティングを使用しますが、nhibernate の 2 次キャッシュ ホスティングは使いやすいですか?

ありがとう。

データベースにエンティティを追加すると、正常に動作します。しかし、リストを取得すると、古いエンティティが取得されます。追加した新しいエンティティは、アプリケーションをアンデプロイして再度デプロイするまで表示されません。これは、エンティティがデフォルトでキャッシュされることを意味しますか? ただし、persistence.xml などのファイルでエンティティをキャッシュするための設定は行っていません。

私は、flush()、refresh()、およびmerge()を呼び出してみました。それでも、古いエンティティのみが表示されます。何か不足していますか？私を助けてください。