ismorodin / ehcache-spring-annotations

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

Enhancement : Passthru cache response and invoke and put in background #77

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
The idea would be that:

Given parameter in annotation when method is invoked and, for instance, a 
special variable is in the local thread, then the interceptor returns the value 
in cache if present but also invokes target and puts value in cache. 

This would be very useful to avoid having a window between @TriggersRemove and 
a call to a @Cachable method when they execution time of this methods takes a 
long time.

Original issue reported on code.google.com by jgalleg...@gmail.com on 18 Jul 2011 at 3:05

GoogleCodeExporter commented 9 years ago

Original comment by eric.dalquist on 20 Sep 2011 at 1:57

GoogleCodeExporter commented 9 years ago
Maybe allow dispatching the cache refresh in another thread while letting the 
first request come back from cache? 

Original comment by osborn.j...@gmail.com on 23 Jan 2012 at 7:26

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I think  that starting a second thread that calls the real method and populates 
the cache is the obvious solution.

The scenario for this enhancement request is very usual:

You have a costly process that you cache but need to refresh sometimes. 

You want that refresh to happen under your control as an administrator. 

You do not want just to clean the cache and let the next unlucky normal user 
that calls the method to populate because his request would be too slow. 

Even worse, if the method is called concurrently you will have a number of 
threads competing to populate the cache!

Original comment by jgalleg...@gmail.com on 24 Jan 2012 at 3:25

GoogleCodeExporter commented 9 years ago
I think it would be relatively trivial to keep a list of thread Future objects 
keyed by the cache hash code to indicate that a 're-population' is in progress 
for a particular hash entry by key. Also, using a thread pool, the number of 
simultaneous requests could be controlled/configured.

Original comment by osborn.j...@gmail.com on 24 Jan 2012 at 4:53