私はいくつかのソースからのライブデータを消費し、定期的にレポートを作成するアプリケーションを設計しています。消費されたデータはEhcacheキャッシュに追加され、レポートはそれを照会します。ライブデータが消費されたら、復旧目的でのみ保持する必要があります。アプリケーションが再起動すると、ライブデータソース（新しいデータをキューに入れる）に接続する前に、DBからの履歴データでキャッシュをプライミングします。DBパーシスタンスデザインのEhcache
私はJDBCのキャッシングとキャッシュとして-SORとしてそれを実装するに傾いています：
1.ソース
2からのデータを受信は
4.確認の領収書をキャッシュするために
3. [追加]をDBへの永続しますソースを使用して
2-4をJTAトランザクションでラップします。
Ehcacheを2次キャッシュとしてHibernateを調べましたが、それは適切ではないようです。
私はEhcacheには比較的新しいので、正しいデザインに関するアドバイスをしたいと思います。
"キャッシュアサイド"ではなく、リードスルーと一部のキャッシュライタ（ライトスルーまたはライトビハインド）を使用するようにキャッシュを構成することをお勧めします。 http://ehcache.org/documentation/user-guide/concepts#cache-as-sor オーバーヘッドが本当にXAトランザクションリカバリが必要な場合を除いてオーバーヘッドになる恐れがあり、フォールトトレラントなアプローチを選択することになるので、私はJTAを避けたいと思います。非同期永続性（write-behind）を選択した場合は、Terracottaを使用してキャッシュをクラスタリングします（WriteBehind Queueは自動的に永続性があり、回復可能であり、複数のノードが利用可能であればHAでも可能です） SoR ...あなたの必要に応じてすべて私は推測する。
Ehcacheを使用すると、単純にread-&ライトスルーキャッシュを使用して、クラスタ化されていない単一のノードから始めることができます。これにより、SLAを満たすために成長し微調整できます。データが大きくなると、クラスタ化されたキャッシュと非同期ライター（書き込みが問題になるはずです）に移動したり、キャッシュサイズを大きくすることができます。明らかに、ボトルネックが何を予知しているかを知る（または少なくとも知っている）必要があります。しかし、RDBMSの前にCacheを置くことは、これらの「より遅い」ストアへの読み取り（および書き込み）アクセスを拡大するための一般的でよく理解されているパターンです...
キャッシュにデータを格納したい場合、Hibernateは過剰使用のようです。キャッシュの初期化とデータベースへのデータの定期的な保存のためにキャッシュローダーを実装するために必要なのは、JDBCだけです。または、ディスクに永続化するようにキャッシュを設定するだけです。
オブジェクトがかなり複雑であるため、Hibernateは純粋JDBCの痛み。ディスクへの永続性は機能しますが、ホスト/ディスクの障害から回復する必要がある場合にはオプションではありません。 –
私は知っていますが、あなたのソリューションは頻繁に変更されたデータに対してうまくいくとは思いません。 JPA/Hibernateを介してデータベースに書き込むだけで、Ehcacheが役に立ちますが、私は懐疑的です。そして、ORMから最高のパフォーマンスを期待しないでください。 私はファイルに順番にデータを書き込もうとしていますが、復旧時に最後のレコードを読み込みます。 マシン障害を回避する必要がある場合は、分散ストレージと処理フェイルオーバーを考慮する必要があります。 –
次に、Ehcache + Hibernateは解決策ではありません。ここで説明するのは、非同期イベント処理システムです。このシステムでは、リスナーの1人が「正常に処理されたイベント」を維持することを待機しています。
この場合、リレーショナルデータベースに厳密に頼る必要がない限り、NoSQLデータベースははるかに優れたオプションです。
Cache-asideは考慮に値しませんでしたが、write-behindを使用してキャッシュとしてキャッシュするのは良い考えです。私はwrite-behind能力を完全に忘れてしまった！要素が保持されているときにコールバックがあるので、発行者に領収書を送付することができますか？ TerracottaとNoSQLのソリューションは、このプロジェクトにとって過度のものです。 –
あなたはCacheWriter.write（All）メソッドで本を保持できるはずです。 putが発生したときにキーが「保留中」であることを確認し、ライターが正常に書き込まれたときにクリアするようにしたデコレーションされたキャッシュを持つと、私は推測します。 –