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 (
@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:
- The direct approach would be to expose thread-safe cache eviction method and modify the
/notUpdateRelatedservice code. This way, before the controller returns from execution of the
/notUpdateRelatedrequest, 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.
- I can use AOP's
@Afterannotation (After returning advice) and do the same as above. This way the modification of the
/notUpdateRelatedservice 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.
I can use
Filteron the response of
/notUpdateRelatedand 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?