如何在 EHCache 实例中使用元素版本控制?

发布于 2024-09-07 06:22:33 字数 956 浏览 6 评论 0原文

我正在缓存以异步方式发送到我的组件的对象。换句话说,这些对象到达的顺序是不可预测的。为了避免任何问题,我在我的对象中包含了一个版本属性(基本上是一个时间戳)。这个想法是,任何到达的对象的版本早于已缓存的版本,都可以被丢弃。

EHCache 的“Element”类(将对象包装在 EHCache 中)似乎促进了这一点:除了键和值之外,构造函数还可以采用(基于长的)版本。但我无法让这项工作按照我期望的方式进行。以下代码片段演示了我的问题(使用 EHCache 2.1.1):

public static void main(String[] args) {
    final CacheManager manager = CacheManager.create();
    final Cache testCache = new Cache(new CacheConfiguration("test", 40));
    manager.addCache(testCache);

    final String key = "key";
    final Element elNew = new Element(key, "NEW", 2L);
    testCache.put(elNew);
    final Element elOld = new Element(key, "OLD", 1L);
    testCache.put(elOld);

    System.out.println("Cache content:");
    for (Object k : testCache.getKeys()) {
        System.out.println(testCache.get(k));
    }
}

我希望上面的代码会导致缓存的值成为“NEW”,而不是打印“OLD”。如果您稍微调整一下元素的插入顺序,您会发现最后插入的元素将保留在缓存中。版本控制似乎被忽略了。

我是否没有正确使用版本控制功能,或者它可能不打算用于此目的?有人可以推荐替代品吗?

I am caching objects that are being sent to my component in an asynchronous way. In other words, the order in which these objects arrive is unpredictable. To avoid any issues, I have included a version attribute to my objects (which basically is a timestamp). The idea is that any object that arrives with a version that's older than the one that has already been cached, it can be discarded.

The "Element" class of EHCache (which wraps objects in an EHCache) seems to facilitate this: apart from a key and value, the constructor can take a (long-based) version. I cannot make this work in the way I'd expect it to work though. The following code snippet demonstrates my problem (Using EHCache 2.1.1):

public static void main(String[] args) {
    final CacheManager manager = CacheManager.create();
    final Cache testCache = new Cache(new CacheConfiguration("test", 40));
    manager.addCache(testCache);

    final String key = "key";
    final Element elNew = new Element(key, "NEW", 2L);
    testCache.put(elNew);
    final Element elOld = new Element(key, "OLD", 1L);
    testCache.put(elOld);

    System.out.println("Cache content:");
    for (Object k : testCache.getKeys()) {
        System.out.println(testCache.get(k));
    }
}

I'd expect the code above to cause the cached value to be "NEW", instead, "OLD" is printed. If you play a bit with the order in which elements are inserted, you'll find that the last one that has been inserted is the one that will remain in cache. Versioning seems to be ignored.

Am I not using the versioning-feature properly, or is it perhaps not intended to be used for this purpose? Can anyone recommend alternatives?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

花伊自在美 2024-09-14 06:22:33

EhCache 显然忽略了 version 字段的值——它的含义是由用户定义的。因此,EhCache 会在不知道版本号含义的情况下用版本 1L 覆盖您的版本 2L

请参阅 1) http://jira.terracotta.org/jira/browse/EHC-765< /a>

我们决定提供内部版本控制方案
给所有用户带来不必要的开销。相反,我们现在离开
版本值保持不变,因此它完全在控制范围内
用户。

2) http://jira.terracotta.org/jira/browse/EHC-666< /a>

[...] 我更喜欢 Marek 提出的解决方案,我们授予
用户完全控制版本属性并且不改变它
完全在内部。这可以防止出现任何性能影响
适合广大用户,并让用户灵活使用
他们认为合适的。 [...]

正如通过电子邮件与格雷格达成的协议,我将其修复为
根据我最后的评论。


我想使用 version 字段可能会导致竞争条件,导致一个线程用一些较旧的版本覆盖缓存项的最新版本。因此,在我的应用程序中,我有一个计数器来跟踪数据库的最新版本,并且当我加载 version 字段与最新数据库版本不同的缓存值时-value,我知道缓存的值可能已过时并忽略它。

EhCache apparently ignores the value of the version field — its meaning is defined by the user. So EhCache overwrites your version 2L with version 1L without knowing what the version numbers mean.

See 1) http://jira.terracotta.org/jira/browse/EHC-765

it was decided that providing an internal versioning scheme would
cause unnecessary overhead for all users. Instead we now leave the
version value untouched so that it is entirely within the control of
the user.

And 2) http://jira.terracotta.org/jira/browse/EHC-666

[...] I would much prefer the solution proposed by Marek, that we grant the
user complete control over the version attribute and to not mutate it
at all internally. This prevents there being any performance impact
for the bulk of users, and allows the user the flexibility to use it
as they see fit. [...]

As agreed with Greg via email I fixed this as
per my last comment.


I suppose using the version field might lead to race conditions, resulting in one thread overwriting the up-to-date version of a cache item with a some what somewhat older version. Therefore, in my application, I have a counter that keeps track of the most recent version of the database, and when I load a cached value with a version field different from the most-recent-database-version-value, I know that the cached value might be stale and ignore it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文