2

I am wondering about the following scenario - it's in the land of Spring/AOP and Ehcache.

Happens in REST Web Application - REST/Service/DAO layers - I have objects in cache (@Repository + @Cacheable). Upon particular REST request (let's call it /notUpdateRelated) execution, after the request completes successfully (in this case it's enough not to throw an exception), I have to update the cache. Calls on the /notUpdateRelated endpoint may happen from different threads.

So I've researched a couple of options:

  1. The direct approach would be to expose thread-safe cache eviction method and modify the /notUpdateRelated service code. This way, before the controller returns from execution of the /notUpdateRelated request, I can trigger the cache eviction.

What I don't like about this approach is that, as you might have guessed, it's not responsibility of the /notUpdateRelated service to evict the cache. Sadly the cache eviction is required only for this service call and there's no chance for other services to have to do it.

  1. I can use AOP's @After annotation (After returning advice) and do the same as above. This way the modification of the /notUpdateRelated service will be minimal.

What I don't like about this approach is that this is not a true cross-cutting concern for the application classes.

  1. I can use Interceptor/Filter on the response of /notUpdateRelated and trigger the cache eviction there, but this feels like misuse of the above objects.

    There are possible approaches I am not familiar with. I will be happy to consider anything better. What do you think is the best approach in this situation?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.