java - ehcache 是否尊重 serialVersionUID？

我们在一个带有 RMI 复制和更新服务器的集群中运行 ehcache 1.5(想想顶部的负载均衡器/代理和零停机更新)。

我们通常不关心 serialVersionUID 。问题是，如果复制缓存中有一个实体的两个版本，可能会发生非常糟糕的事情(直至中断)。也就是说，如果运行旧代码的服务器之一将元素复制到其类已更改的新服务器。

我们通常通过为不同端口上的更新服务器启动新集群来解决这个问题，但它非常丑陋和脆弱。

所以，问题是:集群的、复制的 ehcache 是否正确尊重 serialVersionUID？也就是说，如果本地类的版本不同，它是否不会尝试复制实体？

感谢您的直观猜测，但我正在寻找尽可能硬的数据，首选官方文档。

最佳答案

Ehcache 不支持您建议的方式 serialVersionUID。我在运行独立和通过 Terracotta 分发的 Ehcache 时亲 body 验过您在上面描述的场景，如果版本 UID 不匹配，则会在客户端上抛出异常。

理想情况下(我假设这就是您正在寻找的)与 serialVersionUID 不匹配的对象只会错过缓存，但不幸的是，这不受支持。

如果您正在寻找针对此问题的稍微更优雅的解决方案，请尝试在更改缓存实体时更改缓存区域名称，也许将其与 serialVersionUID 链接。您需要更新您的 ehcache 配置文件以添加新的缓存区域，但是它会强制资源仅从包含它们支持的版本的缓存中请求实体。这在分布式环境中非常有用，因为您无法同时使用新版本更新所有资源并且不想使缓存过期。

关于java - ehcache 是否尊重 serialVersionUID？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7099133/