How to make use of element versioning in an EHCache instance?

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 wit开发者_JS百科h 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?

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.