[Jpolycache-users] FW: More on caching RE: Cache in Turbine and Velocity

[Aaron S. <aar...@ve...>]

-----Original Message-----
From: Aaron Smuts [mailto:aar...@ve...]
Sent: Thursday, May 24, 2001 10:56 PM
To: tur...@ja...
Cc: as...@th...
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:jo...@la...]
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" <sky...@ho...> 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: tur...@ja...
For additional commands, e-mail: tur...@ja...


---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...