緩存不適用於Spring 3.0，Hibernate 3.6和EhCache 2.6.6

Question

我們正在嘗試使緩存在我們的應用程序中工作，並且很難使其真正起作用。 至少在應用程序的這一部分，我們沒有非常復雜的配置，所以它確實令人沮喪，我最終不得不讓自己屈服於StackOverflow社區。

首先，目前，我們只停留在Spring 3.0和Hibernate 3.6上，因此使用新的Spring 3.1 @Cacheable批注以及所有其他內容對我們來說不是一個選擇。

我已經將堆棧的版本放入主題中，並且所擁有的是該堆棧的非常典型的配置：

• 我們的Hibernate實體僅通過@Entity定義，DAO通過@Repository定義，服務通過@Service
• 事務邊界是通過@Transactional設置的
• 我通過將ehcache-core添加到pom.xml並將以下屬性添加到Hibernate屬性映射中來添加緩存：

<prop key="hibernate.cache.use_second_level_cache">true</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory</prop>

然后，我將@Cache注釋添加到我的實體類中，如下所示：

@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "config")
public class Configuration extends AbstractHibernateEntity implements Serializable {

老實說，我以為我完成了。 是的，我如此輕松地配置了緩存！ 您會看到它正在運行，隨着緩存聯機，日志中有很多消息。 那很棒！

只有事實證明，緩存已經聯機，並且沒有任何緩存。 我現在已經花了兩天時間，不知道為什么我的對象沒有被緩存。 我嘗試將<cache name="..."/>到ehcache.xml中 ，在@Cache批注中指定區域，檢查緩存統計信息，等等。為net.sf添加了調試日志記錄。 ehcache和org.hibernate.cache軟件包。 我只是看不到是什么使它無法將對象保存到緩存並在那里訪問它們。

意識到我們的Web應用程序不是緩存后，我回到了依賴庫中，意識到它們也沒有緩存（我在單元測試中添加了緩存，以確保緩存不會破壞單元測試；它不會不是，但這也許只是因為它沒有緩存）。 因此，我一直在研究我們的一個較低級別的依賴項，以弄清楚如果我能弄清楚如何使其在該級別上工作，我可以將其提升到Web應用程序級別。 這是一個很棒的理論，除了我什至無法使其在較低的水平上起作用！

在我的日志中，我收到很多消息。 因此，這是net.sf.ehcache的調試輸出的示例 ：

14:03:20,795  INFO                           net.sf.ehcache: 284 - CACHE HITS:  0
14:03:20,796  INFO                           net.sf.ehcache: 284 - IN-MEM HITS: 0
14:03:20,796  INFO                           net.sf.ehcache: 284 - CACHE MISS:  0
14:03:20,796  INFO                           net.sf.ehcache: 284 - IN-MEM MISS: 0
14:03:20,796  INFO                           net.sf.ehcache: 284 - EVICTIONS:   0
14:03:20,797  INFO                           net.sf.ehcache: 284 - MEM OBJ CT:  0
14:03:20,886 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration_data value: 5643835231789056
14:03:20,890 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration value: 5643835231805440
14:03:20,891 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration_data value: 5643834986045441
14:03:20,891 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration value: 5643834986045441
14:03:20,897 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration_data value: 5643835231834112
14:03:20,898 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration value: 5643835231838208
14:03:20,898 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration_data value: 5643834986078209
14:03:20,899 DEBUG bernate.regions.EhcacheGeneralDataRegion: 211 - key: xhbm_configuration value: 5643834986078209

在org.hibernate.cache日志中，我得到了很多類似的東西：

14:47:26,077 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration_data]
14:47:26,081 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration]
14:47:26,082 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration_data], timestamp: 5643845820751872
14:47:26,082 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration], timestamp: 5643845820751872
14:47:26,089 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration_data]
14:47:26,091 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration]
14:47:26,092 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration_data], timestamp: 5643845820792832
14:47:26,092 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration], timestamp: 5643845820792832
14:47:26,125 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration_data]
14:47:26,130 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Pre-invalidating space [xhbm_configuration]
14:47:26,131 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration_data], timestamp: 5643845820952576
14:47:26,132 DEBUG rg.hibernate.cache.UpdateTimestampsCache: 168 - Invalidating space [xhbm_configuration], timestamp: 5643845820952576

我真的不知道從這里還能說什么。 完整的代碼既可以從https://bitbucket.org/rherrick/nrg_config上的 Bitbucket存儲庫（它是Mercurial，而不是git）中獲得，也可以從Dropbox中以https://dl.dropboxusercontent.com/u/42711610/的zip格式獲得。 nrg_config.zip 。 您應該能夠使用以下命令從Maven運行單元測試：

mvn clean install

如果有人可以幫助我弄清楚這里到底出了什么問題，我會欣喜若狂！ 難道你不希望我欣喜若狂嗎？ 我知道我會做:)

認真地說，在此問題上的任何幫助，在此先要多謝，之后再多謝。

Answer 1

據我了解，僅當您在Session上調用load get ， list等時，才會使用對象的二級緩存。 我在您的代碼中看不到此類調用。

僅當您對Query或Criteria對象調用setCacheable時，才使用查詢緩存。 再說一次，您永遠不會在代碼中調用該方法。

Answer 2

亞歷山大，

您走在正確的道路上，但這只是造成問題的少數幾個因素之一。 確實存在三個因素：

1. 我們的代碼實際上是在調用load（），get（），list（）等，但是大部分都封裝在我們的框架代碼中。 我仔細研究了一下這些代碼，以明確地強制在那里緩存。 那開始了一些緩存。
2. JPA /休眠實體永遠不要初始化任何東西！ 我們有一個基類，它在實例化上設置了幾個標志和時間戳。 檢索對象時，這最終使該對象看起來很臟，需要完全耗盡數據庫。 對於我們的框架，這確實是最大的。
3. 設置瞬態屬性時，請注意事務邊界。 當您進入然后退出標記為@Transactional的方法時，對對象的任何更改都將保留，無論您是否在該對象上調用了session.save（）， 如此處所述 。 這導致對象始終無法與緩存版本匹配（盡管我本以為對象的修改版將與緩存匹配，但這似乎沒有發生）。

最后，這實際上很難診斷，主要是因為它不是一個單一的因素，而是由許多不同的因素共同造成的！