search

iyuohz / ehcache-spring-annotations

Automatically exported from code.google.com/p/ehcache-spring-annotations
0 stars 0 forks source link

Enhancement Proposal #55

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi,

I see the need for adding an 'interval refreshing self populating cache' to the 
main trunk. I have attach a patch for it here (maybe be it could be of use ?).

@Cacheable(cacheName="somecache",decoratedCacheType=DecoratedCacheType.REFRESHIN
G_SELF_POPULATING_CACHE,refreshInterval=1000*60)

Br,
Uffe Heerfordt.

Original issue reported on code.google.com by uheerfo...@gmail.com on 21 Nov 2010 at 6:15

GoogleCodeExporter commented 9 years ago 
My biggest concern with this patch is that you're simply storing the 
MethodInvocation in a Map that is never cleaned out. As a result EVERY argument 
of EVERY method call will be stored in memory for the life of the application. 
What would need to happen is the MethodInvocation for a particular cache entry 
would need to be stored in the targeted Ehcache. Perhaps create a simple 
wrapper object like:

class RefreshableCacheEntry {
  public final MethodInvocation mi;
  public volatile Object value;
}

Then to refresh the cache you iterate through the entries that currently exist 
in the EHCache instance get the RefreshableCacheEntry from the Entry and re-run 
the method invocation and update the value. Then there is external control over 
the clearing of those method invocation objects.

The rest of the patch looks pretty good. We'll have a new release cut in the 
next few days. If you can update the patch to work in the latest release and 
make the change to how the MethodInvocations are stored we can get this 
included.

Original comment by eric.dalquist on 19 Apr 2011 at 9:29

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 

I have updated the patch so it should be compatible with the trunk version.

Original comment by uheerfo...@gmail.com on 20 Apr 2011 at 11:02

Attachments:

GoogleCodeExporter commented 9 years ago 
The patch looks good and I'm working on applying it. One thing I'll have to see 
if I can figure out is what to do about the use of the Spring 3.0 TaskScheduler 
interface. We still want to maintain Spring 2.5 compatibility which means we 
can't rely on any APIs that are new in Spring 3.0. The SpELCacheKeyGenerator is 
an exception here but that is only a problem if a developer tries to actually 
use that generator in a Spring 2.5 application. The code affected by this patch 
is always used so having a dependency on TaskScheduler won't work.

Original comment by eric.dalquist on 20 Apr 2011 at 5:20

GoogleCodeExporter commented 9 years ago 
Great, looks good.  

Thank you for taking the time to include at feature like this.

Original comment by uheerfo...@gmail.com on 23 Apr 2011 at 9:13

GoogleCodeExporter commented 9 years ago 
This is fixed in trunk and will be in 1.2.0

I was wondering if you'd be able to put together a short page of documentation 
for the feature. We'd incorporate it into the manual on the site.

Thanks,
-Eric

Original comment by eric.dalquist on 25 Apr 2011 at 6:03

GoogleCodeExporter commented 9 years ago

Original comment by eric.dalquist on 25 Apr 2011 at 6:04

GoogleCodeExporter commented 9 years ago 
can we use the ehcache spring annotation ( REFRESHING_SELF_POPULATING_CACHE ) 
with spring 2.5

Original comment by chbalaji...@gmail.com on 22 Nov 2012 at 12:32