オンラインモールのホームページには人気のある製品があるため、これらの製品のクリックレートは非常に高くなっています。ユーザーが人気のある製品をクリックすると、Taobaoのように製品の詳細情報ページを入力する必要があります。その後、クリックするたびに、製品の詳細情報を照会するにはバックグラウンドに移動する必要があり、対応するSQLステートメントが送信されます。詳細なページを更新するたびに、SQLステートメントも送信します。このようにして、パフォーマンスは間違いなく大きな影響を受けます。次に、Hibernateの二次キャッシュを使用すると、この問題を解決できます。
一部の人々は、リダイレクトを使用できると考えるかもしれません。このようにして、ユーザーが最初に訪問するとき、彼らは情報を見つけてセッションに入れることができます。将来的には、ユーザーがリフレッシュするたびにセッションに行くことができるため、データベースでクエリする必要はありません。これは理にかなっていますが、上記の問題を解決することはできません。なぜなら、私たちが解決したいのは、複数のユーザーが同じ製品にアクセスして同じ製品をクリックすることだからです。リダイレクトは、同じユーザーがクリックまたは更新されることのみを確認できます。しかし、セカンダリキャッシュはこれらの問題を解決できます。
まず、hibernate4.3に基づいて二次キャッシュテクノロジーを詳細に説明し、次にこのプロジェクトに特定の構成を作成しましょう。
1。Hibernate4.3レベル2キャッシュの基本設定
Hibernate3とは異なり、Hibernate4.3のコアパッケージにはキャッシュ関連クラスがありません。セカンダリキャッシュを使用する場合は、キャッシュジャーパッケージを追加する必要があります。 Hibernate-Release-4.3.11.Finalの公式ダウンロードから、セカンダリキャッシュに必要なJARパッケージがあり、最初にプロジェクトに追加する必要があります。次のように：
次に、hibernate.cfg.xmlでセカンダリキャッシュ関連の構成を構成します。
<hibernate-configuration> <session-factory> <プロパティ名= "dialect"> org.hibernate.dialect.mysqldialect </property> <property name = "show_sql"> true </property> <！ - セカンダリキャッシュプロバイダーを構成します。 name = "hibernate.cache.region.factory_class"> org.hibernate.cache.ehcacheregionfactory < /property> <mapping />> <mapping /> <mapping /> <！ - サポートキャッシュを構成するクラス？これは主にホームページに人気のある製品を表示するため、製品クラスはキャッシュをサポートします - > <class-cache usage = "read-only"/> </session-factory> </hibernate-configuration>
次に、Tomcatサーバーを開き、ホームページにアクセスし、人気のある製品をクリックすると、バックグラウンドにSQLステートメントが送信されません。セカンドレベルのキャッシュは簡単なのだろうかと思うかもしれません。これら2つのアイテムを構成するだけですか？実際、レベル2キャッシュがこれまでに有効になった理由は、デフォルトの構成があることです。上記のehcache-core-2.4.3.jarには、既にデフォルトの構成があるehcache-failsafe.xmlファイルがあります。後で詳細に分析します。最初に、Hibernateのクエリ戦略を分析しましょう。
2。Hibernate4.3クエリ戦略
Hibernateは、セッションクエリとHQLクエリの2つのクエリ方法をサポートしています。
セッションにsession.save（）update（）delete（）get（）load（）およびその他のメソッドがあります。このメソッドは1つのレコードでのみ動作し、デフォルトは構成なしでレベル2キャッシュをサポートすることです。したがって、読み取り専用の構成はセッションに効果的です。読み取り専用がセッション中のセカンダリキャッシュで構成されている場合、session.update（）およびdelete（）操作は両方とも失敗します。成功したい場合は、read-writeを構成する必要があります。ただし、save（）およびget（）load（）が成功します。
HQL：このメソッドは、list（）やexecuteUpdate（）メソッドなど、デフォルトで複数のレコードを操作するために使用されます。このメソッドは、読み取り専用を含むセカンダリキャッシュ構成にデフォルトであり、無効です。 HQLのリスト（）は複数のレコードを照会し、データベースを直接照会し、クエリの結果をセカンダリキャッシュに渡し、get（）とload（）の呼び出しを容易にします。 ExecuteUpdateは二次キャッシュをサポートせず、データベースに直接更新されます。 Hibernateは、データベースとキャッシュが同期されることを保証します。注：HQLにはsave（）メソッドがありません。データを挿入する必要がある場合は、session.save（）メソッドのみを呼び出すことができます。
[注]： Hibernateの第1レベルのキャッシュ（デフォルトで存在する）は、セッションレベルのキャッシュとも呼ばれ、パフォーマンスを改善するためではなく、トランザクションを処理するために使用されます。セカンドレベルのキャッシュはセッションファクターキャッシュであり、これはすべてのセッションに有効であり、そのライフサイクルはセッションファクトリーと同じです（SessionFactoryはシングルトンであり、プロジェクトの開始時に作成されます）。
特定のクエリ戦略については、次の写真を見てみましょう。
【注：写真のテキストが小さすぎる場合は、画像を新しいウィンドウにドラッグして表示できます〜
上記は、冬眠のクエリ戦略です。引き続きセカンダリキャッシュの構成を見てみましょう。
3。Hibernate4.3レベル2キャッシュ高度な構成
上記のように、hibernate.cfg.xmlで2つの項目を構成した後にレベル2キャッシュを使用できる理由は、デフォルトの構成があるためです。最初にこのデフォルトの構成を見てみましょう：
<ehcache xmlns：xsi = "http://www.w3.org/2001/xmlschema-instance" xsi：nonamespacesschemalocation = "../ config/ehcache.xsd"> <！ - キャッシュメモリがオーバーフローする場合、それはハードディスクスペースに保存されます - > <> <> <> <> <> path = "java.io.tmpdir"/> <defaultcache maxelementsinmemory = "10000"：<！ - メモリによってサポートされるオブジェクトの最大数 - > eterming-> "false"：<！ - オブジェクトが永続的に有効かどうか、次の2つのパラメーターがfalseであることをお勧めします。秒。つまり、60秒後に誰もこのオブジェクトを使用しない場合、それは事前に破壊されます - > TimeTolivesConds = "120"：<！ - オブジェクトのライフサイクルは秒です - > Overflowtodisk = "true"：<！ - ハードディスクへのオーバーフローがサポートされています。 MemoryStoreEvictionPolicy = "lru"：<！ - オブジェクト置換ポリシー - > /> < /ehcache>
デフォルトの構成に関する関連する説明は、すでに上記のコメントにあります。 Hibernate 4.3のセカンドレベルのキャッシュを正しく実行できるのは、まさにこのデフォルトの構成のために正確にあることを知っています。ここで、キャッシュを自分で構成する場合は、SRCディレクトリに新しいehcache.xmlファイルを作成してから、上記の構成アイテムを再構成する必要があります。次に、各構成をテストする必要があります。テストの前に、ホームページに表示される状況を投稿して番号を作成します。テスト時に後で説明しましょう：
上記は、ホームページに表示されるコンテンツの一部です。 Hibernateは、データベースから表示情報を見つけて表示されています。番号を付けますが、後でキャッシュをテストするときに分析する方が簡単になります。上記のキャッシュ構成項目のテストを開始しましょう。
テスト1：メモリ内のオブジェクトの数をテストします。構成を次の状況に変更します。
<DefaultCache MaxElementsInmemory = "6" <！ - 設定6キャッシュのみをサポートします - > etersal = "true" overflowtodisk = "false" memorystoreevictionpolicy = "fifo"：<！ - first-out - > /> /> />
構成が完了したら、サーバーを再起動してホームページを開きます。構成は6つあるため、キャッシュにある最後の6つのレコードのみが保存されます。つまり、3〜8番です。 3-8の製品をクリックして、製品の詳細ページを入力します。バックグラウンドのコンソールはクエリ情報を出力しないことに注意してください。つまり、SQLステートメントは送信されません。ただし、製品番号2をクリックすると、SQLステートメントがバックグラウンドで送信されます。つまり、データベースがクエリになります。製品2を再度バックしてクリックしましたが、SQLステートメントは送信されません。つまり、キャッシュに入れられましたが、キャッシュは6つのデータのみをサポートしています。設定されたオブジェクト置換戦略が最初に最初に登場するため、キャッシュの3番は削除されたばかりです。 3をクリックして、SQLステートメントを送信しました。そのため、テストが完了し、2番目のレベルのキャッシュ実行が正常です。
テスト2：テストオブジェクトのライフサイクル。構成を次の状況に変更します。
<DefaultCache MaxElementsInmemory = "100" ETERNAL = "FALSE" <！ - 次のライフサイクルを設定できます - > TimetOidLeseConds = "20" TimetoliveseConds = "40" Overflowtodisk = "false" memorystoreevictionPolicy = "fifo" />>
キャッシュ時間は40秒として構成され、20秒で動作がない場合は削除されます。 100のレコードを割り当てているため、上記の1〜8の数字はすべてキャッシュに含まれています。サーバーを有効にすると、任意のサーバーをクリックします。たとえば、8番をクリックすると、SQLステートメントが発行されません。通常、20秒後、8番をクリックしてSQLステートメントを送信し、構成したライフサイクルが有効になっていることを示します。ここでは、Tomcatには開始に数秒かかるため、10秒など、構成が短すぎることはないことに注意してください。構成が少ない場合、テストの前に時間があった可能性があります...それは機能しません。
テスト3：セカンダリキャッシュがハードディスクストレージをサポートするかどうかをテストします。
<DefaultCache MaxElementsInMemory = "4" ETERNAL = "FALSE" <
サポートハードディスクストレージをTrueに設定し、セカンダリキャッシュの最大ストレージ容量を4に設定します。サーバーを再起動します。セカンダリキャッシュは最大4つのレコードを保存するため、5-8に番号を付ける必要があります。 5-8をクリックするとSQLステートメントは絶対に送信されませんが、1-4をクリックしてもSQLステートメントは送信されません。ハードディスクストレージのサポートを設定しているため、Hibernateはハードディスクにクエリ結果を保存するため、SQLステートメントを送信せずにデータを直接取得できます。
テスト4：レベル2キャッシュの交換戦略をテストする
<DefaultCache <！ - FIFOが排除され、再び使用されません... LRU：少なくとも最近アクセスされたアルゴリズム（時間ポリシー）はアクセス周波数を無視し、最も遠い時期にアクセスしたものはLFUに置き換えられます：最近使用されたアルゴリズム（頻度測定）にアクセスします。 maxelementsinmemory = "3" eter = "false" <！ - falseとして構成されている場合のみ、次のライフサイクルを設定できます - > TimetoidLeseConds = "100" TimetoliveseConds = "200" Overflowtodisk = "false" <！
名前が示すように、LRUとLFUはそれぞれ最後のアクセス時間と頻度に焦点を当てています。例としてLFUを取り上げましょう。次に、最大ストレージを3つのレコード、つまり6〜8に設定します。次に、6番に3回、2回、2回、番号8にアクセスし、SQLステートメントを発行しません。もう一度7番にアクセスし、SQLステートメントを発行します。現在、7番はキャッシュに含まれており、アクセスの数が少ないため、8番が削除されています。もう一度番号8をクリックしてテストし、SQLステートメントを発行すると、テストが成功します。 LRUの場合、削除された6番は6番です。
この時点で、誰もがセカンダリキャッシュの使用を習得しており、セカンダリキャッシュのテストはここで終了したと思います。オンラインモールプロジェクトの構成を作成しましょう。
4.オンラインモールプロジェクトの実際の構成
セカンダリキャッシュ内の最大レコード数を1000に設定し、ライフサイクルを120秒、インターバルサイクルを60秒に設定します。ハードディスクストレージをサポートし、ユーザーのクリックレートが高い場合はセカンダリキャッシュに配置する必要があるため、周波数優先度（LFU）交換戦略を使用します。
<ehcache xmlns：xsi = "http://www.w3.org/2001/xmlschema-instance" xsi：nonamespacesschemalocation = "../ config/ehcache.xsd"> <！ - キャッシュメモリがオーバーフローしている場合、ハードディスク= "> <diskstore path. <DefaultCache MaxElementsInMemory = "1000" ETERNAL = "FALSE" TIMETOIDLESECONDS = "60" TimetOlivesConds = "120" OverflowTodisk = "True" MemoryStoreEvictionPolicy = "LFU" /> < /ehcache>
さて、オンラインモールプロジェクトと組み合わせて、Hibernate 4.3のセカンドレベルのキャッシュの構成と使用が導入されています。
元のアドレス：http：//blog.csdn.net/eson_15/article/details/51405911
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。