【问题标题】:Hibernate - clustered cache and updating class versionsHibernate - 集群缓存和更新类版本
【发布时间】:2011-08-24 08:57:08
【问题描述】:

我们在集群中使用 Ehcache 作为 Hibernate 的 L2 缓存。由于我们一一更新服务器以避免停机,因此在某个时候,集群中可能有一台服务器运行旧版本的代码,而另一台服务器运行更新的版本。

我认为问题在于 Ehcache,但我将其范围缩小到了 Hibernate。 Hibernate 不会缓存整个实体,而是缓存字段值的数组。因此,如果您将具有不同架构的实体复制到缓存中,加载时会发生坏事,因为数组被盲目复制。

我无法在 Ehcache 级别上阻止它。我想在我的实体类上设置serialVersionUID,但这不适用于那些较低级别的数组。

如何向 Hibernate 指示实体版本已更改并且不应加载缓存中的值?

【问题讨论】:

    标签: java hibernate caching


    【解决方案1】:

    我认为在这种情况下您无法避免暂时降低容量,因为您在这里拥有的是一个运行具有不兼容代码库的服务器的系统。

    即使您可以评估实体格式的不兼容性以及它的缓存版本而不是从缓存中加载它,您最终会得到一些机器会读取/写入缓存,而有些机器会直接执行到数据库,这将导致不一致的数据访问,等等。基本上,这种方法是一团糟。

    有更好的解决方案。步骤包括:

    1. 将集群的一半从网络断开。您可以使用交换机或负载平衡器的管理或任何其他可用方式。
    2. 取下那一半,升级它,把它拿出来。
    3. 重新连接。
    4. 断开第二个。
    5. 重复 #2 和 #3。

    您在这里得到的是容量暂时下降,同时在升级时仍保持系统可用于满足客户请求。它可以在非高峰时间很好地工作。您可以通过将新请求路由到集群的升级部分来增强它,因为它变得越来越可用。还有其他变化,但想法是一样的——分而治之。

    唯一重要的是新旧集群不应该相互交谈。您需要操作方面的帮助,但这当然是可行的。

    希望这会有所帮助。

    斯拉瓦·伊梅舍夫

    Cacheonix: Reliable Distributed Java Cache

    【讨论】:

      猜你喜欢
      • 2012-11-05
      • 2021-12-08
      • 1970-01-01
      • 2014-07-15
      • 2012-03-05
      • 1970-01-01
      • 2019-07-19
      • 2020-10-23
      • 1970-01-01
      相关资源
      最近更新 更多