Add @Cacheable attribute to use getWithLoader (cache defined CacheLoader)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Define a CacheLoaderFactory on a cache.
2. Use that cache in a @Cacheable call
3. In case of cache-miss, CacheLoader is not invoked.

What is the expected output? What do you see instead?

I would like to be able to use the CacheLoader functionality offered by 
Ehcache, via the Cacheable annotation.

Original issue reported on code.google.com by jonloru...@gmail.com on 30 Jan 2011 at 3:53

[GoogleCodeExporter]

Sorry this should be an enhancement request, not a defect.

Original comment by jonloru...@gmail.com on 30 Jan 2011 at 6:27

[GoogleCodeExporter]

Could you supply a unit test that demonstrates this flaw? Any Ehcache specific 
configuration should still work

Original comment by eric.dalquist on 1 Feb 2011 at 4:37

[GoogleCodeExporter]

I've attached a unit test called CacheLoaderTest. I've tried to model the way 
you've set up your unit tests as closely as possible.  

Modifying EhCacheInterceptor.invokeCacheable, replacing:

     final Element element = cache.get(cacheKey);

with:

     final Element element = cache.getWithLoader(cacheKey, null, null);

will get the test to pass.

Original comment by jonloru...@gmail.com on 1 Feb 2011 at 6:34

Attachments:

• loader-unittest.zip

[GoogleCodeExporter]

Eric,

We're you able to get the unit test working? 

Original comment by jonloru...@gmail.com on 5 Feb 2011 at 10:38

[GoogleCodeExporter]

I haven't had a chance to look yet ... finishing up putting a new floor in my 
basement right now :)

Without looking at the code my two thoughts are:
* Can we just call getWithLoader instead of get all the time without and bad 
side-effects or extra overhead? If so we can just do that.
* If we can't call getWithLoader all the time it shouldn't be too hard to add 
an additional option to @Cacheable to tell the interceptor to call 
getWithLoader instead of just get.

I'll try and take a look this week.

Thanks again for the patch!

Original comment by eric.dalquist on 6 Feb 2011 at 12:58

• Changed state: Accepted
• Added labels: Milestone-Release1.2.0, Milestone-Release2.0.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I haven't had a chance to look yet ... finishing up putting a new floor in my 
basement right now :)

Without looking at the code my two thoughts are:
* Can we just call getWithLoader instead of get all the time without and bad 
side-effects or extra overhead? If so we can just do that.
* If we can't call getWithLoader all the time it shouldn't be too hard to add 
an additional option to @Cacheable to tell the interceptor to call 
getWithLoader instead of just get.

I'll try and take a look this week.

Thanks again for the patch!

Original comment by eric.dalquist on 6 Feb 2011 at 12:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Eric,

From the javadocs:

http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#getWithLoader(java.lang.Obj
ect, net.sf.ehcache.loader.CacheLoader, java.lang.Object)

It appears that with a null loader in the method call, and a no loader defined 
in ehcache.xml the method will just return null.

That said, it might also make sense to add an additional option to the 
annotation, in case you would like to explicitly skip the cacheLoader. What do 
you think?

Original comment by jonloru...@gmail.com on 8 Feb 2011 at 4:26

[GoogleCodeExporter]

Sorry, to be clear, my vote would be to default to use getWithLoader, but 
provide a means to skip the use of the cacheloader via an attribute on the 
annotation.

If the annotation attribute is not possible, it would still be possible to do 
this via configuration in ehcache.xml.

Original comment by jonloru...@gmail.com on 10 Feb 2011 at 5:03

[GoogleCodeExporter]

It looks like I can use getWithLoader by default. There doesn't appear to be 
any real performance difference between the two. I also chose to pass in the 
MethodInvocation as an argument to the cache loader.

Thanks again for the unit tests!

Original comment by eric.dalquist on 19 Apr 2011 at 10:42

• Changed state: Fixed

[GoogleCodeExporter]

Hi,

Apologies if this is not the right place to post / process to report an issue, 
but I believe I'm having problems with this change in conjunction with the 
latest ehcache APIs.

More specifically, I want to use both the @Cacheable annotation and a 
BlockingCache Decorator Adapter.

The problem here is that BlockingCache.getWithLoader is coded to always throw 
an Exception, with the message "This method is not appropriate to use with 
BlockingCache".

If I use the 1.1.3 spring annotations jar this problem goes away, but I'm 
nervous that I'm losing out on important changes / bug fixes by using an older 
version.

Am I missing something here / should I be using a different approach to 
achieving the functionality of a blocking cache when using the @Cacheable 
annotation?

Tim

Original comment by supp...@yospace.com on 7 Nov 2012 at 9:34