Extend caching for collections

Question

Extend caching for collections

Closed this issue 5 years ago · 17 comments

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 extra CollectionCacheableCacheAnnotationParser and CollectionCacheInterceptor only worked via a BeanFactoryPostProcessor
No consisderation of sync (might be possible, but is harder to implement)
The CacheAspectSupport (which I extended in CollectionCacheInterceptor) has only some methods protected, which required me to copy some of the code from CacheAspectSupport in CollectionCacheInterceptor

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 #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: The CacheAspectSupport class is hard to extend for my PoC. The same holds for CollectionCacheableCacheAnnotationParser, which is extending SpringCacheAnnotationParser. 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!

Answer 1 · 2019-07-09T06:42:25.000Z

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?

Answer 2 · 2019-07-10T10:03:50.000Z

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 a BeanFactoryPostProcessor (BFPP) which adds a BeanPostProcessor to modify the AOP advisor BeanFactoryCacheOperationSourceAdvisor, 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 as AbstractCachingConfiguration is used as a base class for this configuration. Also replacing the CacheInterceptor 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 implementing CacheAnnotationParser. 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 own CacheInterceptor. 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.

Answer 3 · 2019-07-30T09:26:35.000Z

@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?

Answer 4 · 2019-08-02T17:16:53.000Z

@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.

Answer 5 · 2019-10-15T06:08:05.000Z

@snicoll Are you going to have a look at this or should this issue be closed?

Answer 6 · 2019-10-15T06:57:58.000Z

@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.

Answer 7 · 2019-10-15T19:23:35.000Z

@neisen if you happen to create a library out of this, please share the URL. I it would be highly useful for me as a user

Answer 8 · 2020-05-07T09:22:42.000Z

mark to learn

Answer 9 · 2020-09-16T14:54:38.000Z

@snicoll ... so what are we supposed to do then?

Today I just discovered Spring's caching feature for the needs of our project, and this usage of the cache (i.e. easier handling of Collection of cached/cacheable objets - particularly for pre-loading the cache) seems repeatedly asked for by many, seeing the continuous amount of questions on SO over the years (and probably more I didn't found):

Answer 10 · 2020-09-16T15:01:20.000Z

esp. if you're willing to put some cache in a server-side GraphQL Dataloader Pattern context...