問題タブ [second-level-cache]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
3119 参照

hibernate - lazy=false である Hibernate の第 2 レベルのキャッシュ オブジェクトは、デフォルトの fetch=join になります。どこかに文書化されていますか?

次の明らかに文書化されていない問題が発生しました。

  1. 私は何か悪いことをした
  2. 誰かが同じ問題に遭遇しましたか?
  3. 本当にどこにも文書化されていませんか?または私は何かを逃しましたか?

動作はこれです 次のマッピングを想定します

まず、背景として、多対 1 のリレーションのfetch属性の Hibernate のデフォルト値は「 select」である必要があります。これは少なくとも文書化されているものです (見つけたらここにリンクを追加します)。

ただし、これは、参照されるクラスが lazy="true" である場合にのみ当てはまります。

したがって、明らかに上記のマッピングは次のように変換されます (Bar は lazy="false" であるため):

では、なぜそれが問題になるのでしょうか。2 つの選択の代わりに、Hibernate は非遅延参照をその「親」を使用して単一の選択でロードします (単一の選択で Bar を使用して Foo をロードします)。

オブジェクトは遅延していないので、これは実際に理にかなっています。ロードしないのはなぜですか?

答えはこうです: Bar が第 2 レベルのキャッシュにある場合はどうなりますか?

その答えは、何も変わらないということです。

どうやら、Hibernate はこのタイプのオブジェクトをロードしてはならないことを理解できるほどスマートであると想定するでしょうが、デフォルトのフェッチが select から join に変更されたため、Hibernate には選択の余地がありません (実際のテーブルを第 2 レベルのキャッシュ、まだ)

そのため、Hibernate は指示されたとおりに実行し、結合を使用して、既に第 2 レベルのキャッシュにあるデータベースからオブジェクトをフェッチします。

私が見つけた解決策は、文字通りマッピングを fetch="select" に変更することです

Bar の 2 番目の選択が実行されようとすると、Hibernate はそれがデータベースに送信されるべきではないことを認識し、キャッシュからフェッチします。1つのクエリのみが実行されます(ウォームアップ後)

0 投票する
3 に答える
6644 参照

hibernate - Hibernate クエリ キャッシュ - 第 2 レベルのキャッシュにないオブジェクトの場合 - 危険ですか? 使える?悪い習慣?

この質問に関連する

前提:

これらは、私の読書、経験、理解に基づく私の仮定です。間違っている可能性があります。間違っている場合は、コメントしてください。質問を編集します。

  • クエリ キャッシュは、主に第 2 レベルのキャッシュと共に優れています
  • クエリ キャッシュは、クエリ + パラメータの識別子の結果をキャッシュします
  • データベースが変更され、キャッシュに反映されていない場合、クエリキャッシュは危険です

質問:

第 2 レベルのキャッシュにないオブジェクトがあります。不適切なプログラミングまたはその他の制約により、オブジェクトをロードするコードが同じ休止状態セッションで複数回呼び出されています。検索はHQL検索クエリを使用しています。

クエリ キャッシュを追加する前に、上記のコードが同じ Hibernate セッション内で N 回呼び出された場合、データベースへのヒット数は N 回でした。

次に、クエリ キャッシュを追加するとどうなるかを確認したかったのです。

クエリキャッシュを追加したとき、同じセッション中に、休止状態がデータベースに N 回ヒットせず、セッションごとに 1 回だけヒットすることに気付きました。

  1. したがって、私の最初の仮定は、Hibernate が最初にセッション キャッシュを検索し、次に 2 番目のレベルのキャッシュを検索するということです。この仮定は正しいですか?
  2. Fooまた、第 2 レベルのキャッシュにないオブジェクト ( ) がデータベースで変更された場合、クロス セッション スコープのクエリ キャッシュが間違った識別子を返すため、間違ったオブジェクトが返されることも想定しています。あれは正しいですか?
  3. 2L キャッシュされていないオブジェクトであっても、不変の情報を含むクエリにクエリ キャッシュを使用することは、良い習慣であると言えますか? (例: where 句に常に同じ結果を返す条件が含まれるクエリ。例: "select p.ser_num where p.id = ?" ser_num と id の組み合わせが一度作成されると変更されない場合)

ところで、関連する質問では、クエリ キャッシュはセッション キャッシュ スコープでは機能しないと主張されています。私はその主張を誤解していますか、それとも何か他のものですか?

0 投票する
1 に答える
978 参照

hibernate - JPQL更新ステートメントを実行すると、Hibernateの第2レベルのキャッシュが無効になりますか?

JPQLの更新または削除クエリを実行する場合、Hibernateは、変更されたエンティティの第2レベルのキャッシュを無効にするのに十分スマートですか?

考案された例:

あなたはJPQLを持っています:

そのステートメントの実行時に現在第2レベルのキャッシュに製品がある場合、Hibernateはキャッシュからすべての製品を無効にしますか、それともキャッシュに何もせず、第2レベルのキャッシュの製品は無効になりますか?

参考までに...HibernateとJBossCacheでJBoss5.1を使用しています

0 投票する
1 に答える
352 参照

c - CPU-コアスレッド分類機能

プロセス間の超大量のメッセージ配信のためのマルチスレッド共有メモリメッセージングシステムを作成します。メッセージは、Webサーバーのワーカースレッドから発信されます。同じCPU共有をコアとするCPUキャッシュの局所性を活用したいと思います。そのため、このIPCシステムの受信側でワーカースレッドをウェイクアップするときに、同じCPUでスレッドをウェイクアップします。

Linux(一般的にはPOSIX)とWindowsが必要です。API呼び出しとビットマスキングを使用して、実行中のスレッドIDを分類できるようにする情報を抽出します。このスレッドのコンテキストから次の構造体を使用します。 :

両方のプラットフォームの機能が高く評価されます。これがシステムコール、つまりコンテキストスイッチなしで実行できることを望んでいます。

- 編集 -

現在はx86に焦点を当てていますが、他のアーキテクチャも同様に役立つでしょう。

0 投票する
1 に答える
1912 参照

java - SwarmCacheHibernate構成

クラスター(分散キャッシュ)で動作するようにHibernate用にSwarmCacheを構成する方法を教えてもらえますか?おそらく他の選択肢がいくつかあります(JBoss Cacheを提案しないでください)?

0 投票する
1 に答える
892 参照

hibernate - Hibernate-クエリキャッシング/第2レベルのキャッシュは、サブアイテムを含む値オブジェクトでは機能しません

私は次の問題に苦しんでいます:
異なるパネルを含む値オブジェクトがあります。各パネルにはフィールドのリストがあります。

マッピング:

次の基準を使用して、値オブジェクトを取得します。

私が見るように、クエリキャッシュにはメインセレクトのみが含まれています

RACountryPanelsとRAFieldVOの両方が第2レベルでキャッシュされます。第2レベルのキャッシュコンテンツを確認すると、RAFieldsとRACountryPanelsも含まれていることがわかります。また、クエリキャッシュ領域のCTRYからのselect .. where ctry_cd_id=...も確認できます。

サーブレットを呼び出すと、キャッシュを使用しているように見えますが、2回目は使用していません。 JMXを使用してキャッシュの内容を確認すると、すべて問題ないように見えますが、オブジェクトのアクセス時間を測定すると、必ずしもキャッシュを使用しているとは限らないようです。

乾杯ゾルタン

0 投票する
2 に答える
1012 参照

asp.net - NHibernate +ASP.NET+ビューでセッションを開く+L2Cache

Open Session in ViewNHibernateセッションを処理するためによく知られているCodeProjectを使用しています。それはうまく機能しLevel 2 Cacheますか?誰かがそれを成功させましたか?NH.Burrow代わりに使用する必要がありますか?asp.netのベストプラクティスでのl2キャッシュに関するアドバイスをいただければ幸いです。

編集:CodeProjectの記事へのリンク:http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

0 投票する
2 に答える
2572 参照

hibernate - Grailsで読み取り専用の第2レベルキャッシュ休止戦略を一時的に無効にする方法は?

私の grails アプリケーションでは、一部のドメイン クラスはユーザーによって変更されることはありません。

ただし、メンテナンス作業が必要な場合があり、管理者は時々 (年に 2 回としましょう) 少数のインスタンスを作成/編集できる必要があります。

これらのドメイン クラス ( ) に対して読み取り専用の第 2 レベル キャッシュ戦略を設定したいとstatic mapping = { cache usage: 'read-only' }考えています。また、Grails スキャフォールディングを介して一部のインスタンスを更新するために、読み取り専用戦略を (非常に特殊な状況で) '無効' にできるようにしたいと考えています。ビューを編集します。

出来ますか?あなたは私に何をするようにアドバイスしますか?

編集:私が実装しているソリューションは、パスカルとバートの回答を組み合わせたものです(コメントを参照)。どちらの回答も素晴らしく、役に立ちます。だから、受け入れられた答えを選ぶのにジレンマがありました!とにかくありがとうございました。

0 投票する
3 に答える
860 参照

asp.net-mvc - トラフィックの多い Web サイトでのキャッシュに関する質問

消費者がキーワードを入力して製品を検索できる E コマース サイトを構築しているとします。最大で 200,000 個の製品があり、何百万人もの消費者がシステムを使用しているとします。product テーブルがかなり頻繁に更新されるとしましょう。製品の数はそれほど多くないため、製品テーブル全体をメモリに保存して、データベースにアクセスする代わりに検索できる可能性があります。同じデータを格納するが異なるサーバーに存在する分散キャッシュを作成したいと考えています (高可用性とパフォーマンス上の理由から)。これらのキャッシュ間でデータを同期し、製品テーブルが変更されたときにキャッシュを無効にする必要があります。

私たちのアプリケーションは、ASP.NET MVC と NHibernate を使用して構築されています。NHibernate のレベル 2 キャッシングが私の状況に役立つかどうかを理解しようとしています。皆さんがこれに光を当てることができれば、本当に感謝しています。

レベル 2 キャッシュがクエリ結果のキャッシュに役立つことを理解しています。そのため、2 人の異なるユーザーが同じキーワードを使用して検索している場合、L2 キャッシュはデータベースではなくキャッシュから結果を提供します。しかし、製品テーブルが頻繁に更新され、キャッシュされた結果が古くなるため、あまり役に立ちません。私の質問は、L2 キャッシングを正しく理解しているか、キャッシュを希望どおりに管理するのに役立つものが存在するかどうかです (複数のキャッシュ、同じデータ、キャッシュ間の同期とキャッシュの無効化)。どんな考えでも大歓迎です。

0 投票する
1 に答える
9078 参照

java - Hibernate で遅延ロードされたコレクションに二次キャッシュを使用する方法は?

と の 2 つのエンティティがあるEmployeeとしSkillます。すべての従業員は一連のスキルを持っています。インスタンスを介してスキルを遅延ロードするとEmployee、キャッシュは の異なるインスタンスのスキルには使用されませんEmployee

次のデータセットを考えてみましょう。

Employee - 1 の後に Employee - 2 をロードするとき、休止状態でスキルを取得するためにデータベースにアクセスせず、代わりSkillにキャッシュで既に使用可能なインスタンスを使用します。これは可能ですか?もしそうなら、どのように?

休止状態の構成

インポート、ゲッター、セッターが削除されたエンティティ

2 番目の従業員とそのスキルをロードするための SQL

とにかく最初のクエリは避けられないので、特に2番目のクエリを避けたいと思っています。