spring cache does work w/ nested method

Question

I has one method to call another @Cacheable method like this:

public ItemDO findMethod2(long itemId) {
    this.findMethod1(itemId);
    ...
}

@Cacheable(value = "Item", key="#itemId", unless="#result == null")
public ItemDO findMethod1(long itemId) {
    ...
}

The cache works well if I call the findMethod1() directly. However, when I call findMethod2() the the cache on findMethod1() is totally ignored.

Could it be the trick made by JVM which inline the findMethod1() into findMethod2()?

Does anyone come across similar issue?

Thanks!

Answer 1

It's no JVM trick, i.e. findMethod1() is not being inlined inside findMethod2() or anything of that nature.

The problem is your code is bypassing the "Proxy" that Spring is creating around your application class (containing findMethod1()) for the @Cacheable annotation.

Like Spring's Transactional annotations and underlying infrastructure, given an interface, by default Spring will create a JDK Dynamic Proxy (AOP style) to "intercept" the method call and apply the "advice" (as determined by the type of annotation, in this case, caching). However, once the target object is invoked from the interceptor (Proxy) acting on behalf of the target object to apply the advice, the Thread is now executing in the context of the target object so any subsequent method invocations from within the target object are occurring directly on the target object itself.

It looks a little something like this...

caller -> Proxy -> findMethod2() -> findMethod1()

Ideally what you want is this...

caller -> Proxy -> findMethod2() -> Proxy -> findMethod1()

However, the Thread is already executing in the context of the "target" object once inside findMethod2(), so you end up with the first call stack.

The Spring doc explains it better here.

The document goes on to point out solutions to this problem, the most favorable is refactoring your code to ensure the caller is going through the Proxy interceptor for the 2nd method invocation (i.e. findMethod1()).

I also gather another solution to this problem would be to use full-blown AspectJ, using a compiler and byte-code weaver during your application build process to modify the actual target object so that subsequent invocations from within the target object intercept and apply the advice accordingly.

See the Spring docs on the trade-offs between Spring AOP and full AspectJ, as well as how to use full AspectJ in your Spring applications.

Hope this helps.

Cheers!