2

いくつかのリレーショナル DB テーブルは、プロセス内に存在する単一のオブジェクト キャッシュによって管理されます。キャッシュがコミットされると、テーブルが更新されます。DB リレーショナル テーブルは通常の SQL クエリによって更新されますが、休止状態のような複雑なものではありません。

最終的に、他のプロセスは、互いに通信せずにこのオブジェクトを変更するビジネスに入りました。つまり、各プロセスはこのオブジェクトを初期化し（DBから読み取り）、更新します（DBにコミットします）。他のプロセスは、それが保持されていることを知りません古いキャッシュ。

このワークフローを修正する必要があります。私はいくつかの方法を考えました。1 つは、このオブジェクトを mBean にすることです。そのため、オブジェクトは 1 つのプロセスに存在し、すべてのプロセスは最終的に mBean メソッドの呼び出しによってそのプロセス内のオブジェクトを変更します。

ただし、このアプローチにはいくつかの問題があります。1) このキャッシュによって返されるすべてのオブジェクトは mBean であるため、メソッドの呼び出しがかなりおしゃべりになる可能性があります。2) また、すべてのプロセスが DB の一貫したデータ モデル (キャッシュ) を参照する必要があり、可能であればその内容を DB にマージする必要があります。（トランザクションのように）。DB が他のプロセスによって大幅に更新された場合、マージが失敗しても問題ありません。

Java のどのテクノロジーがこの問題の解決に役立つでしょうか?

4

3 に答える 3

3

Terracottaをご覧ください。それらには、複数の JVM (異なるサーバー上にある可能性がある) を統一されたように見せるテクノロジがあります。1 つの JVM でオブジェクトを更新すると、Terracotta はクラスタ内のすべての JVM で安全な方法でインスタンスを透過的に更新します。

于 2009-12-21T19:44:48.397 に答える
0

オブジェクト モデルを維持したい場合は、コミットする前に集中ストレージにJava オブジェクト キャッシュを使用できます。または、 Zookeeperを使用して共有ロックを維持することもできます。

しかし、セルフマネージド キャッシュを本当に放棄する必要があるようです。あなたが言及した休止状態または別のJPA実装を使用してください。JPA はキャッシュの問題に対処し、L2 共有キャッシュを維持するため、これについて考えました。

于 2009-12-21T19:51:07.093 に答える
0

ジョンに同意します-クラスタリングをサポートする休止状態で第2レベルのキャッシュを使用します。簡素化されたデータ アクセス モデルを使用してデータを管理し、Hibernate に詳細を管理させる、はるかに簡単な方法。

Terracotta Ehcache はそのようなキャッシュの 1 つです。JBoss、Coherence なども同様です。

Hibernate Second Level Cacheの詳細については、ここと第 19 章の Hibernate の公式ドキュメントを参照してください。 Swarm Cache? その最後のリリースは 2003 年でした)

于 2009-12-23T01:09:23.270 に答える