Unico Hommes wrote:
Hi gang :-)Although you actually don't need my confirmation as it's not my
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.
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.
Instead of:
Refresher { refresh(key,uri,timeout); periodicallyRefresh(key,uri,timeout); }
I'd like to remove timeout semantics from the interface:
Refresher { refresh(key,uri,params); }
I don't think there is currently a reason for there being two the separate methods. So I think we can safely combine them into one. But I guess I am looking at Carsten for confirmation... :-)
but *our* source, here it is :)
I think this makes sense and I think we should also move this
out of the scratchpad afterwards as well.
I'd also like to change the protocol URL a little bit. Since the timeout parameter will only be applicable to the delay refresher implementation and not to the event aware one I think it would be better to specify it with a query parameter instead.
Current syntax: cache://[EMAIL PROTECTED]@http://www.apache.org/
Proposed syntax: cache:http://www.apache.org/?cache-expires=60&cache-name=main
The protocol:subprotocol syntax is also more in line with well established conventions such as in jdbc for instance.
Let me know if you have any objections or comments.
Unico
