2012-03-21 11 views
3

トランザクションをサポートする単純なキャッシュが必要です。シンプルでは、​​スタートアップ時にすべてのデータを読み込み、エビクションがないようにする必要があるだけです。 (単純なマップが行う)。キャッシュとJavaのトランザクション

しかし、データベースへの変更に失敗した場合、キャッシュに対する変更もロールバックされるため、トランザクションをサポートする必要があります。

私はJTAについて聞いたことがありますが、私が必要とするものはあまりにも多いようです。データベーストランザクションでSQLExceptionがスローされた場合は、キャッシュを手動でロールバックすると問題ありません。

オプションはありますか?

もし誰かがJTAに関する良いチュートリアルを教えてくれないのですか?例えば。例と必要なパッケージ/クラス。注:アプリケーションコンテナなしでスタンドアロンで実行できるように、フレームワークを作成しています。

EDIT:

は1非常に重要な問題を忘れていた:

キャッシュされたオブジェクトは不変です!更新は、古いものと等しい新しいオブジェクト(idに基づくequalsメソッド)で置き換えることを意味します。

EDIT 2:私は2つのエンティティタイプを持っている

説明シンプルな地図が動作しない理由:

EDIT 3 ...ではなくJTAのJPAを書きました。私はそれらを化合物と要素と呼ぶことにする。化合物は、複数の要素からなり、各要素は複数の化合物に現れることができます。 要素は私のフレームワークによって管理されます。例えば、化合物のみを直接加えることができる。ユーザーは要素を指定して新しい化合物を追加します。次に、フレームワークは要素を選択して終了し、それを新しい化合物と関連付け、または新しい要素を作成します。

私はすべての要素をキャッシュしています。各要素には、要素が含まれる複合IDのコレクションが含まれています。この理由は、フレームワークが特別な種類の検索(サブグラフ同型写像など)を行うということです。そのような検索ごとに、全体が!!!データセット(すべての要素)はデータベース、したがってキャッシュからロードする必要があります。

したがって、新しいコンパウンドが追加または更新された場合、キャッシュ内の影響を受ける要素も更新する必要があります。

ソリューション:

が何をしたか、私がコメントで言った: - idを保つメモリ内のすべての変更されたオブジェクトの(=整数)とデータベーストランザクションのコミット後にのみ変更したものを更新します。

private void updateSearchCache(Collection<String> changedIds, 
     Connection connection) { 

    synchronized (searchCache) { 
     for (String id : changedIds) { 
      Object myObject = getSearchObject(id, connection); 
      searchCache.put(id, myObject); 
     } 
    } 
} 

答えて

2

トランザクションがデータベースにコミットされた後、Mapにデータを入れることはできませんか?

したがって、Mapにはすでにデータベースに入っているデータのみが含まれます。

+0

一般的には本当ですが、私の場合はうまくいかないでしょう。物事は私が非常に重いオブジェクトを扱っているとアプリケーションは、例としてファイルからそれらの多くを一度に追加することができる必要があります。だから私はファイルから(スレッド1)と挿入(スレッド2)同時にBlockignQueueを使用してメモリ内のオブジェクトの数を制限しています。トランザクションがコミットすると、私はキャッシュに何を挿入するのか分かりません。それ以上に、このアプローチを妨げることもあります。 –

+0

@beginner_ DBにコミットされているオブジェクトのIDを保存できますか?はいの場合、ファイル全体が処理された後、計算の開始前にDBから読み込むことができます。コミットされたオブジェクトの合計サイズがアプリのヒープに収まる場合にのみ、これはもちろん機能します。 –

+0

キャッシュされていない場合は、すでにコミットされた最後のN個のアイテムだけをキャッシュに保存することができます。 –

0

Berkeley DBin-memory tablesを作成するために使用されるとtransactional supportを持ってすることができます。

保存したいものがblob-> blobマッピングであればいいですが、オブジェクトキャッシュではありません。

+0

これは、HSQLDBメモリテーブルとどのように似ていますか?しかし、私たちはどちらも、単純なマップアクセスよりもずっと遅いことに同意すると思います。それは読書のために非常に速くなければならない! –

0

でトランザクションキャッシングが可能です。クラスタ化されたキャッシュとして設計されていますが、easily run on one machineにすることができます。 cache-apiはjava.util.Mapを継承し、使いやすいです。

+0

ちょうど私の質問にJTAの代わりにJPAを書いた。 JPAは私のユースケースではかなり重いようですが、おそらく私は間違っているので、私はそれを避けたいと思います。 –

関連する問題