Geoff Howard wrote:
Unico Hommes wrote:I guess you are right that at the Cache level nothing really changes. I overlooked that fact. I will do some more research on what is required to accomplish that in the case of the Refresher, but my idea was that the cached response would be served until a newly generated one could replace the stale one. Since the Refresher talks to the Cache directly, given the correct Validity strategy it can exercise full control over it.
Hi gang :-)
A drawback I have been running into lately with eventcache mechanism is that it lacks the ability to remove heavy processing from the critical path. An event will simply remove a set of cached pipelines from the cache completely. Making the subsequent request for such a pipeline potentialy very slow. In applications where isolation is not a requirement this is an unnecessary drawback.
Below sounds interesting and good but I haven't understood how event cache is related. AFAICS the only difference with eventcache and the other validity types is that for the others an invalid response is found in cache, but not used because it is found invalid after retrieval, but the event cache removes the entry at invalidation time since it knows it will never be useful. Both cases mean that the next person to request that resource will have to wait for the full generation. Maybe because I've only glanced at the refresher stuff?
So, stale entries are served until they can be regenerated? I've looked for this in the past (someone called it the "I'm Sorry" pattern :) ) and at the time thought it might be better implemented by a pluggable strategy at the pipeline execution level. Currently we have:
- Assemble Pipeline - Gather key from Pipeline - Check cache for key - If object for key found, check its validity - If valid, serve the cached response - Else, execute pipeline and serve it.
the cache point pipeline, and the non-caching pipeline are other implementations of different strategies, but are accomplished by inheritance instead of composing a Strategy. I haven't ever thought it through carefully but it seems like making those last 5 steps (as a group) a pluggable strategy would allow things like this "I'm Sorry" pattern, as well as more powerful concepts like Stefano's proposed adaptive cache. Just raw thoughts at this point...
Bottom line for me at moment is: do you foresee a need to modify the eventcache API to accomodate this need? I'm getting ready to start a discussion on changing the eventcache unstable status -- should I hold off?I don't think my current work will influence the eventcache API directly. Although I am not sure if
the eventcache stuff can be considered stable enough. I still have some doubts about the ease of use of parts of it especially the way events are associated with cached objects. But lets discuss that separately.
Ah, good. Ok, I'll pick up on another thread.
Geoff
