9

永続性マッピングファイルにcomposite-idがマッピングされているHibernateの第2レベルのキャッシュにオブジェクトをキャッシュしようとしています。ログには、クエリを初めて実行したときに、composite-idとしてマップされたクラスがキャッシュに入れられたことが示されています。ただし、クエリを2回実行すると、オブジェクトはキャッシュからプルされません。代わりに、クエリを再度実行しています。

Hibernateには第2レベルのキャッシュ複合IDに問題がありますか？

関連情報：

  1. Hibernate 3.1、ehcache2.4.2を使用する
  2. 複合IDクラスはシリアライズ可能を実装します
  3. クエリを2回実行するときに、新しいHibernateセッションを使用しています
  4. オブジェクトを取得するためにhibernateTemplate.load（Class、ID）を使用しています

これは、IDを作成し、クエリを実行する方法です。

CompositeId id = new CompositeId(date, sessionId);
UserDetails user = (UserDetails) hibernateTemplate.load(UserDetails.class, id);

そして、これが私の永続性マッピングファイルが上記を定義する方法です：

<class name="com.entities.UserDetails"
        table="USER_DETAILS" 
        lazy="false">
    <cache usage="read-write"/>

    <composite-id name="userId" class="com.entities.CompositeId" unsaved-value="undefined">
        <key-property name="userSessionId" column="SESSION_ID" />
        <key-property name="dateCreated" column="DATE_CREATED" type="date" />
    </composite-id>

編集：プロットが厚くなる...

これを読み取り専用キャッシュポリシーに変更すると、正常に機能しました。トランザクションキャッシュの動作は非常に予測できないようです。上記が読み取り/書き込みキャッシュで発生したのに、読み取り専用で正常に機能した理由を誰かが説明できますか？このテーブルは更新されていないため、トランザクションセマンティクスがそのインスタンスで物事を変更する理由がわかりません。

4

1 に答える 1

0

これはHibernateで報告されたバグのようです。回避策として、複合キーの同じインスタンスを使用すると、キャッシュを正常にヒットできるようです.equals()。

バグ レポートにはパッチもあります。おそらく自分で適用して、パッチを適用した独自の Hibernate ビルドを展開することもできます。

于 2013-03-26T13:42:40.247 に答える