Geoff Howard wrote:

Unico Hommes wrote:

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?


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.

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.


I am looking at the excellent CachedSource stuff that is in the scratchpad area ATM and am wondering how it fits together with the eventcache stuff. One thing I am looking into right now is to write an EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source wrapper that can cache a its delegate. Refreshing can be done either synchronously or asynchronously but currently only based upon a specified time-out. What I'd like to do is generalize this a bit in order to add the ability to externally trigger invalidation.

For this however I think a modification to the Refresher interface is needed.



BTW, how does CachedSource accomplish something different from the caching point pipeline (which seems to accomplish more, though I've never used it).


I never used it either. So I really don't know. Perhaps someone else could comment on this?

Cheers,
Unico




Reply via email to