Provide high-level cache API in Spring container [SPR-7308]

[spring-projects-issues]

Liu, Yinwei David opened SPR-7308 and commented

Hi, Do you have any plan to provide a high level cache API in Spring container? such as TransacationManager which manages different transaction resource.

Currently, we have a lot different cache implementations, e.g. EHCache, H2, and so on. Each cache needs a different api to get data from the underlying cache. It is a kind of barrier to disallow people easily switch from one cache to another cache, we always need a extra layer to decouple the our code with the actual cache.

I think it would be great if Spring can provide a high level cache api which can allow people easily choose a underlying cache.

Please let me know your thoughts, thanks.

David

---

Affects: 3.0.3

Issue Links:

• 10491 HTTP cache and conditional requests support in RestTemplate

6 votes, 11 watchers

[spring-projects-issues]

Juergen Hoeller commented

Yes, this is in consideration for Spring 3.1, actually. Thanks for reminding us that we haven't had a proper JIRA issue for it yet :-)

Juergen

[spring-projects-issues]

Liu, Yinwei David commented

Thanks Juergen! I am so glad to hear Spring is going to add a high level cache API. :-)

David

[spring-projects-issues]

Abhishek Gupta commented

Hi Juergen, It'd be really interesting to know your ideas about it as you go (before its too late to give suggestions that would work well for us :) ). Also your thoughts about how (the partly-dead) JSR107 would fit in with this.

Thanks, Abhi

[spring-projects-issues]

Liu, Yinwei David commented

Hi Juergen, I am wondering if you already read our thoughts on Spring Support Portal, so I copied it to this jira for your reference.

Specifically, our point of view is from the library owner perspective. Indeed, it is not that difficult to integrate a particular app with a particular cache product. But it seems a larger number of libraries could benefit from being integrated with a caching layer. So our request is more from a library author point of view. The lack of current nice, standard API leaves library authors with a couple of choices: -implement a custom internal caching (which is often OK, but never as flexible nor manageable etc than full caching products) -pick a particular caching products and integrate with it. Can be done with a few products as well. -create some kind of custom abstraction for caches to be pluggable.

Whatever the library author does, most likely it will not bother enough to make his library work with complex caching products, e.g. distributed caches etc. That doesn't necessarily mean it would not be very useful.

We think there would be many libraries that would integrate with a caching standard API. For example: -libraries dealing with complex user entitlements ( might want to control how long these are valid before we need to touch base with a centralized server) -libraries dealing with messaging (e.g. duplicate message filter interacting with an in-memory cache of prior messages) -libraries dealing with remote services -- caching some recent requests, etc.

(To some extent, by being stuck "in-progress" for a huge time the jcache JSR did more harm than good, since no one has stepped up to fill the void. We consider the jcache API somewhat outdated).

Nothing earth shattering here, but it seems to fit well into the spring philosophy. SpringSource has traditionally been quite strong at "filling the void" when an API is missing (often by virtue of being too "low-level"). Hence our request to see if there was any intent to do anything on that front. Maybe gemstone should get involved in jcache and finally get it done (seems like gemfire could actually benefit from this)?

The answer of the ticket can be either: -there is no intent at the moment, this is not on our roadmap. -we already have something being worked on (obviously this is not the case per your initial answer).

We're not trying to force this work. We wanted to test the waters. Essentially the answer you gave is pretty much what we were looking for: an idea of the current state around this.

[spring-projects-issues]

Eric Dalquist commented

Hello, I'm one of the authors of http://code.google.com/p/ehcache-spring-annotations/ and am wondering if you would be interested in some contributions from our project for the official spring caching abstraction? We've had a lot of user feedback for our library over the last year and it could be good to get those ideas included. Looking through the source currently in SVN a few issues that I think would be good to address:

• Allow KeyGenerator to optionally include information from the Method signature
• We have five existing key generation implementations which could be updated to for the Spring KeyGenerator API and allow users various ways to generate keys beyond basic hashCode generation. Our key generators also ensure keys that are generated are consistent across JVM restarts, instances and versions. Special handling is required for many core JDK classes to make sure generated keys behave in a logical manner.
• All of our key generators support the use of reflection to generate good keys for arguments that don't implement good hashCode, equals or toString methods.
• Some cache APIs such as EhCache have a "Self Populating" feature which we support. This construct results in concurrent requests for the same key to only be serviced once while all other threads wait for the one result. I'm not sure if you're interested in finding a way to support cache-specific features but it could be a very handy one.
• A @KeyGenerator annotation that allows the key generator to use for a specific @Cacheable method to be configured via annotations.
• An option on @Cacheable and @CacheEvict to specify a bean name to use for the KeyGenerator implementation

Nick (the other author) and I would be more than happy to sign over copyright for any code from our library you'd be interested in and we would also be happy in submitting patches or other contributions to this effort.

Thank you for your consideration -Eric

[spring-projects-issues]

Costin Leau commented

Hi Eric,

Thanks for the offer. Patches are definitely welcome - not sure how papers need to be signed but I can look it up.

For M1 we're trying to come out with a minimal set of features to gather feedback. We had some functionality pulled back simply because we were getting ahead of ourselves. It remains to be seen whether the KeyGenerator is still useful considering SpEL can do all that plus much more.Regarding the issues you mentioned, some quick answers:

1. We plan to do that though probably in some unwrapped form to try to prevent accidents from happening. The full context was passed to the generator but since a lot of things could have gone wrong, we allowed only the arguments for the time being.
2. This is an area we still haven't found any good implementations, in wide use hence the usage of hash code. We tried to avoid the use of reflection as much as possible for the speed sake.
3. This is something that can be done directly at cache level as it's implementation specific - for example it can't be done with a basic Map.
4. You can already do that through SpEL - one can invoke arbitrary methods on whatever beans/objects she wants. No need to implement the KeyGenerator interface (if you don't want to).
5. See above

[spring-projects-issues]

Eric Dalquist commented

Thanks for the quick response, from it I'm thinking the biggest thing we could find a way to contribute is the key generation implementations. We recently added a SpEL generator and register our other generators as static functions that can be called from within the SpEL. This allows for an expression like: "digest(args[0], args[1].id)" to generate a MessageDigest based key for the two objects resolved by the expression.

You can take a look at our existing key generators here: http://ehcache-spring-annotations.googlecode.com/svn/trunk/src/main/java/com/googlecode/ehcache/annotations/key/

I'm thinking that with the reliance on SpEL finding a way to provide these as easy to call functions in the expressions the user provides.

The big concerns with key generation are around arrays, Class and Enum objects. Their hashCodes are different on every JVM instance which makes things like clustering or persistent storage in the underlying cache impl non-functional because keys aren't stable.

All of our key generators support reflection but it is disabled by default specifically due to performance issues. Initially we didn't want to include it either but had enough demand from users dealing with objects out of their control. This may not be as necessary now that SpEL is the primary approach for key generation.

[spring-projects-issues]

Costin Leau commented

Guys,I'll close this issue since we introduced the caching abstraction in Spring 3.1 M1: http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/

Cheers,

[spring-projects-issues]

Liu, Yinwei David commented

Cool, thanks Costin!

David