Unico Hommes <[EMAIL PROTECTED]> writes: > > 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. > > 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.
Cool, in our case, for much of our data, we know we can, in theory, repopulate the cache the moment after the data is invalidated (which is the moment before the new version is committed). However, we need to do this asynchronously if possible. We haven't started to look at this issue, but it sounds like this might be the way to go? > > 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. > <snip on interface question/>
