Have you checked out the caching discussion that is currently going on in the commons? If we can, I think working with those guys to get a project neutral caching system is the way forward!! James -----Original Message----- From: Aaron Smuts [mailto:[EMAIL PROTECTED]] Sent: 25 May 2001 03:56 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: More on caching RE: Cache in Turbine and Velocity In a template system it is nice to be able to control caching apart from an expiration of time to live period. An interface to manually delete caching is often helpful. Oh, I'm almost done with a conversion of my caching sytem into somehting closer to the ocs4j specification. There are a few issues and differences. 1. element vs region attributes: My original cache was regionally defined. Each entry required a very minimal wrapper. The osc4j spech is an element driven model where each element is fully configurable. This could lead to a slight performance penalty, but it is a richer model, where elements can inherit or have there own attributes. So I'm converting the entire thing into element centered. 2. lateral broadcast vs. remote consitency The oracle model is a laterally distributed model with no centralized control. My model has the option for lateral braodcast ( which will need to be made more efficient ) and a remote store that coordinates consitency. Local caches send data to the remote store which then notifies other local caches of changes to "regions" ( cashes ) that are registered. An update is never broadcast from the remote only via the lateral caches if this is set up. This way each local cache is a relatively separate realm with remotely configurable regions that stay in synch without overriding the user habits of a machine. If you broadcast changes to all servers then every server must be ready for every user. The usage patterns of a user on one box can effect the whole. With a remote store the local caches are primed to take on similar patterns by talking to the remote store, but aren't flooded with the elements form another machine. This significantly cuts down on traffic. I'll work on ful lateral searching later, thought I don't think this is a good model. Before that I'll build in the concept of failover. It should be relatively simple to cluster the remote caches and create hot standbys. 3. put vs. replace The difference between put and replace is not present in my cache by default. The overhead associated is tremendous. There will be an alternate "safe-put" method to deal with special caches. 4. nulls vs errors If started to support ObjectNotFoudExceptions for failed gets but the overhead and cumbersome coding needed to surroud a simple get method is ridiculous. 5. cache loaders I'm not supporting cache loaders at this time. There are more but I don't have time and this probably isn't the place. Since I'm making significant revisions the version I'll come out with next week may seem to be a little ad hoc, but it can be improved with time. I'll have something mid week for evaluation, but I'm not sure where to send or put it. Aaron -----Original Message----- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 3:48 PM To: Turbine-user Subject: Re: Cache in Turbine and Velocity on 5/23/01 11:19 AM, "Sky Torch" <[EMAIL PROTECTED]> wrote: > Hello, > > if same xyz.vm template is accessed twice, is it going > to cached somewhere, i.e. the second request doesn't > need the template to parsed again ? > > i guess it depends on service impl of that template > in Turbine. if so, can someone point out what services > are doing this, what not? > > also, if it does cache, it's using cache service to > do this ? There are several levels of caching you need to consider: Template caching is handled by Velocity. Configure that in TR.props through the Velocity Service configuration. Module instance caching (ie: Screens, Actions, Layouts, Pages, Navigations) is also configured in the TR.props file. Look for module.cache I belive. Template path's are also cached. In other words, Turbine does lookups to find the right template to execute. This lookup is also cached. This is also controlled in the TR.props file. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous <http://jakarta.apache.org/velocity/ymtd/ymtd.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
