在Ehcache复制设置中使用timeToIdleSeconds参数

时间:2014-09-16 20:48:17

标签: java hibernate caching replication ehcache

我们使用具有两个节点的复制Tomcat Web服务器设置。我们使用Ehcache作为Web应用程序的Hibernate 2级缓存提供程序。 所以我们通过官方文档中描述的RMI复制配置了Ehcache设置: http://ehcache.org/documentation/user-guide/rmi-replicated-caching

我们现在使用 timeToLiveSeconds 参数进行缓存条目,并希望切换到 timeToIdleSeconds ,因为它似乎更有效。但后来我们遇到了这个问题(http://ehcache.org/documentation/user-guide/cache-topologies):

  

使用空闲时间

     

Time To Idle与复制的缓存不一致。时间与空闲之   由于某些节点,某些节点上的某些条目比其他节点的寿命长   缓存使用模式。但是,缓存条目“最后一次触摸”   时间戳不跨节点复制。不要使用空闲时间   复制缓存,除非您不关心不一致的数据   跨节点。

它们的意思是“跨节点的数据不一致” - 如果访问不同的节点,您会看到不同的数据吗?但这怎么可能发生呢?因此,如果用户使用一个节点 - 他经常访问某些条目 - 由于 TTI ,它们会保留在该节点的缓存中。同时,相同的条目可能在第二个节点的缓存上到期。但是,当在第二个节点上访问时,它们是不是只能从数据库中重新获取? 在这方面与 TTL 的主要区别是什么?

1 个答案:

答案 0 :(得分:2)

每个SessionFactory驻留在一个节点上,并具有自己的二级缓存。

空闲时间取决于当前节点请求模式,并且由于上次访问时间未被复制,因此您可能最终在节点上使用旧实体版本而在另一个节点上使用刷新版本。

虽然Hibernate可以在使用HQL或JPQL it cannot do that for queries时检测到实体更改,但它只会使所有二级缓存区域无效。所以,这个用例是真实可信的。

当您在分布式系统上进行缓存时,维护strict consistency非常困难,这就是为什么在所有其他选项都已用尽时最好采用它。