2012-10-23 1 views
6

Java 1.6、Spring 2.5、Hibernate 3.3.1およびehcache 2.6.0を使用しています。プログラムは2つのデータベースに接続されています。 2つのehcache構成がありますが、この場合は1つだけが使用されます。 は、バッチの終わりにプログラムがこのエラーを返す:ソフトロックされたキャッシュエントリはすでに削除されています。不安定なロック/アンロックシーケンス?

2012-10-23 15:44:43,406 ERROR (AbstractReadWriteEhcacheAccessStrategy.java:159) - Cache dao.data.MyObject Key dao.data.MyObject#28 Lockable : null 
A soft-locked cache entry was removed already. Out of balance lock/unlock sequences ? 

このエラーを生成することができますか?

+0

hibernate 3.6.10Finalと同じ問題(これはehcache 2.xとの互換性があります) – ratm

答えて

3

私はこの時点で打たれているので、私は自分の所見を共有します。

まず、いくつかの背景:私たちは、使用

  • にHibernate 3.5.2 & Ehcacheの2.7.0
  • 唯一のデータベース(、別の1が読み取り専用でアクセスされますが、何もキャッシュはそこに使用されていないがあります
  • この問題は、InheritanceType.JOINEDおよびCacheConcurrencyStrategy.READ_WRITEでマップされたエンティティの更新時に発生します(ただし、NONSTRICT_READ_WRITEに切り替えると発生しません)。また、コード検査から判断すると、削除時にも発生します。 (AbstractReadWriteEhcacheAccessStrategy中)にehcacheの実装がためのマッピングを変更し

    1. HibernateのEntityUpdateAction(中(実行))EntityRegionAccessStrategy.lockItemを(呼び出し)
    2. :私はHibernateとEhcacheのコードをデバッグすることで見つけた

キャッシュされたエンティティからロックに与えられたキー

  • Hibernateはエンティティが2つ以上のテーブルにマップされていることを検出するため、キャッシュの無効化が必要です(AbstractEntityPersister.isCacheInvalidationRequired()を参照)
  • persister.getCacheAccessStrategy()。remove()を呼び出すと、EhCacheの実装では、指定されたキャッシュキーのマッピングが削除されます。しかし、Hibernateはキャッシュされたエンティティを実際に削除することを期待していますが、EhCacheを使用すると、ロックを削除します(ステップ2でそこに格納されています)。
  • トランザクションの完了後、EntityUpdateAction.doAfterTransactionCompletion()指定されたキャッシュキーのマッピングが存在しない場合に失敗し、unlockItem()を呼び出すと、エラーメッセージが表示されます。
  • これは、lockItem()のEhCache実装で問題になると思われます。 (READ_WRITEの場合)unlockItem()を呼び出します。実際のアイテムをロックで置き換えるのではなく、ロックを別々に保管すべきです。少なくとも、このシナリオではHibernateとEhCacheは100%互換性がないと言うことができます。

    少数の最終ノート:

    • このエラーは無害であり、安全のlog4jの設定を経由して抑えることができるようです。
    • 私は別のシナリオでこれを繰り返すことができました(これは同じロック/解除/ロック解除シーケンスになります)。今度は、継承継承の代わりに、ネイティブSQLが削除をトリガーしていました。それ以外はほぼ同じです。
    • HibernateおよびEhCacheコードの関連ビット:EntityRegionAccessStrategy、EntityAction、CollectionRegionAccessStrategy、CollectionActionおよび関連する実装/拡張コンクリートクラス。

    HTH

    2

    私はcreateSQLQuery(ネイティブSQLクエリ)を使用していたとき、私は同じ問題を持っています。このImpact of native sql queries on hibernate's second level cacheのおかげで、私は私の問題を修正しました。

    リンクの主な理由は、ネイティブクエリが第2レベルのキャッシュを無効にすることができることです。ネイティブSQLクエリを使用しているときに、ハイバネートがL2キャッシュを無効にするのを防ぐために、リンクの最下部に解決策もあります。

    +0

    Reneは、この問題はまだhibernate 4.xで実際に発生していますか? – Johnny

    関連する問題