Description
I'd like to use the Spring Caching abstraction in a way that I can also ask for a bunch of items via a list of provided IDs, and then put the result into the cache, as if I had asked for each item one by one.
As an example, consider the following snippet:
@Cacheable("myCache")
public String findById(String id) {
// ... access DB backend and return item
}
@CollectionCacheable("myCache") // let's suppose this exists and does the magic :D
public Map<String, String> findByIds(Collection<String> ids) {
// ... access DB backend, return map of id to item
}
Then usage would be:
// suppose the following call has happened before the examples below
findById("key1")
// example1: uses "key1" from cache, never calls findByIds
findByIds(Arrays.asList("key1"))
// example2: calls findByIds(["key2"]) and uses value for "key1" from cache,
// puts value for "key2" into cache
findByIds(Arrays.asList("key1", "key2"))
// example3: calls findByIds(["key3", "key4"]) as there's nothing in the cache
// puts value for "key3" and for "key4" separately into cache
findByIds(Arrays.asList("key3", "key4"))
I've implemented this functionality in a proof-of-concept Spring Boot application here: https://github.com/neiser/spring-collection-cacheable The main implementation can be found in CollectionCacheInterceptor#handleCollectionCacheable
The PoC lacks the following:
- Modifying the
BeanFactoryCacheOperationSourceAdvisor
to account for my extraCollectionCacheableCacheAnnotationParser
andCollectionCacheInterceptor
only worked via aBeanFactoryPostProcessor
- No consisderation of
sync
(might be possible, but is harder to implement) - The
CacheAspectSupport
(which I extended inCollectionCacheInterceptor
) has only some methods protected, which required me to copy some of the code fromCacheAspectSupport
inCollectionCacheInterceptor
Still, the tests in MyRepositoryIntTest
show that the PoC works 👍
My questions to you folks are:
- Do you have a better idea how to "modify" the
BeanFactoryCacheOperationSourceAdvisor
in order to support my custom@CollectionCacheable
? - Do you think the annotation
@CollectionCacheable
could be officially integrated in Spring's caching layer (of course with some more polishing)? I've seen some discussions on Stackoverflow and in particular in Insert all elements of a returned list into a Cache [SPR-15213] #19777 but they lack the "partial" invocation feature as in example 2 above (they proposes to use the Cache/CacheManager interfaces to achieve the desired functionality). - If you don't want to integrate something like
@CollectionCacheable
: TheCacheAspectSupport
class is hard to extend for my PoC. The same holds forCollectionCacheableCacheAnnotationParser
, which is extendingSpringCacheAnnotationParser
. Would you mind to make this easier for my use case?
I'm happy to contribute a PR once I know what your opinion on this feature is. I can also polish the PoC further following your recommendations. I appreciate any feedback!
Activity
snicoll commentedon Jul 9, 2019
Thanks for sharing the idea and building a prototype. I don't think such contract is a good fit for a low-level framework abstraction and I've already expressed some concern in #19777 indeed (thought your use case looks different to me).
Having said that, we can look at what makes it hard for you to build such aspect in your own code. Can you share the specifics?
neiser commentedon Jul 10, 2019
Hi @snicoll, thanks for your feedback. I can totally understand that integrating
@CollectionCacheable
completely would be too much. So, let's go for making the Caching Abstraction better to extend for my use case:The first step would be to make changing the provided
ProxyCachingConfiguration
easier. I've introduced aBeanFactoryPostProcessor
(BFPP) which adds aBeanPostProcessor
to modify the AOP advisorBeanFactoryCacheOperationSourceAdvisor
, see https://github.com/neiser/spring-collection-cacheable/blob/master/src/main/java/com/example/springcollectioncacheable/CollectionCacheableProxyCachingConfiguration.java As the method emitting the BFPP is not static, I get a warning when running the application that some features like autowiring don't work. That indicates to me that this modification is rather hacky, and making the method static is hard asAbstractCachingConfiguration
is used as a base class for this configuration. Also replacing theCacheInterceptor
was not simply done by defining a bean implementing the interface. I suppose it has to do with the fact that the beans I'm trying to replace are infrastructure beans? Maybe I'm also missing the point how to extend this correctly and you have some better idea.It would be nice if not only the the
SpringCacheAnnotationParser
is used for finding caching annotations, but all beans implementingCacheAnnotationParser
. It looks like there's some support in the code for this, but I did not find a way to achieve getting my own caching annotation and operation added easily.Last part is reusing and extending the
CacheAspectSupport
class to write your ownCacheInterceptor
. Some things were simply private where I would have wished they were protected. Those are little things I guess and I could do them once we have a plan for a PR I'm also happy to work on.szantopeter commentedon Jul 30, 2019
@neiser this looks really promising (I am not a Spring team member, just a developer who found this ticket). While the Spring team is deciding to include it or not would you mind creating a library, that can be accessed from maven central?
neiser commentedon Aug 2, 2019
@szantopeter I'm reluctant to create a library without having discussed the integration parts as mentioned above. The final solution would be that some of Spring's caching abstraction are changed such that my code can integrate a bit more seamlessly, and then a library could be created I guess.
I hope that the Spring team will find some time soon to work on this.
If you desperately need this feature now, feel free to simply copy the code in the PoC project I mentioned above.
neiser commentedon Oct 15, 2019
@snicoll Are you going to have a look at this or should this issue be closed?
snicoll commentedon Oct 15, 2019
@neiser thanks for the nudge and sorry for the late reply. We discussed this one at the team meeting and I forgot to share the outcome of the discussion.
CacheAspectSupport
is internal and is not really meant to be reused externally so I am afraid I'd recommend rolling out your own arrangement for this.19 remaining items