@Cachable condition should allow referencing return value [SPR-8871]

[spring-projects-issues]

Oliver Drotbohm opened SPR-8871 and commented

Currently the condition attribute of the @Cacheable annotation does not allow referring to the value returned by the method invocation. Thus, it's impossible to define something along "don't cache null values returned from the method invocation".

---

Affects: 3.1 RC1

Issue Links:

• Using Spring beans as a part of key in cache annotations (@Cacheable etc.) doesn't work [SPR-9578] #14212 Using Spring beans as a part of key in cache annotations (@Cacheable etc.) doesn't work

Referenced from: commits 8c2ace3

12 votes, 10 watchers

[spring-projects-issues]

Thomas Hackel commented

For a working implementation/example see the ehcache-spring-annotations project. http://code.google.com/p/ehcache-spring-annotations/
It's implementation of the annotation allows @Cachable(cacheNull=false).
http://code.google.com/p/ehcache-spring-annotations/source/browse/trunk/core/src/main/java/com/googlecode/ehcache/annotations/Cacheable.java

[spring-projects-issues]

Costin Leau commented

That's because the condition is evaluated before the method executes and uses only the input (which means the given params). What you seem to want is a post condition, that gets executed after the method gets executed. Besides the specific, don't cache null, I'm not sure how useful such a post condition is.
Note that don't cache null is not really valuable since this forces the method to be executed every time (only to get null instead) which defeats the purpose of @Cacheable.
However we might add something like this to @CachePut (which is a proper cache insert w/o any method side-effects).

[spring-projects-issues]

Oliver Drotbohm commented

Well I don't think it defeats the purpose as I don't want to skip caching entirely but only return values with a given criteria. Imagine the returned object has a property we need to inspect to decide whether it should be cached. But yes the method call would be repeated for a second call but that call might return (for my example) a none null value which would be cached then.

[spring-projects-issues]

Costin Leau commented

@Cacheable skips method execution (by caching the return value). If you want to inspect the return value, you need to execute the method first which automatically disable method caching. The whole point of the condition, in its current form, is to decide whether or not caching applies - by using the return value I pass this completely.
Hence my suggestion of maybe adding a post condition...

One more thing, caching works great for idempotent operations (think REST) - no matter the number of calls, the same input results in the same output. If that doesn't apply, the caching is bad since you're basically changing the behaviour of the method.

All in all, seems to me that a cache filter/decorator is much more useful since then you can decide how to wrap/unwrap/add things added to the cache - after all, if there's no value in the cache, the cache advice will force the method to be executed so you end up with the desired behaviour without adding contradicting features.

[spring-projects-issues]

Thomas Hackel commented

If others are also in desperate need of this feature and use EhCache as cache implementation, they can use the listener mentioned here:
https://gist.github.com/1196809

It should be possible to avoid caching of null results of the called method directly within the annotation, so its independent from the underlying cache implementation.

[spring-projects-issues]

Frederik De Milde commented

Thx for the pointer for EhCache.

I believe also it would add value to be able to apply some post condition to veto the caching of a certain return value (could be much broader than just null value)

[spring-projects-issues]

Mike Kaplan commented

Using a condition from the return value would be extremely helpful in this example: if the returned data has a date property, only cache results that are less than [x] years old. This would be helpful if older data were accessed less frequently, and thus didn't need to be cached.

[spring-projects-issues]

Emerson Farrugia commented

Another use case is a proxy server that caches responses for identical requests. If the target server returns an error response because of an intermittent problem, the proxy server can evaluate the post condition and veto caching if the response from the target server contains an erroneous status.

[spring-projects-issues]

Sylvain LAURENT commented

Any hope to see this implemented for spring 3.2 ?

[spring-projects-issues]

DontSay commented

Yes, that would be nice to have a postcondition or wrapper.

[spring-projects-issues]

Stevo Slavić commented

So @Cacheable needs two condition properties, (existing) one for getting things out of cache, and other one for conditional putting things in cache.

[spring-projects-issues]

Phil Webb commented

Stevo Slavić,

Initial thoughts are to add an unless EL expression:

@Cacheable(value="book",
    condition="#name.length < 32",
    unless="#result.hardback")

Some initial work is here:
#220