[SNIPPED]
> > Turbine GlobalCacheService exists already we can easily provide
> > additional implementation if needed.
> >
> > However note that we don't want a single cache instance for
> the whole
> > application, we may need different cache instance of different
> > implementations running at the same time for caching different
> > kind of elements.
>
> That's the right way to go. Portals could then be tuned by
> replacing the default cache implementations for the different kinds
> of elements by cache implementations that are optimized for particular
> environments.
>
> > The Turbine service API does address this as such
> > since it's singleton based but it may be possible to extend it.
> > I don't know yet but it first require a careful analysis
> > of what needs to be cached and what are the desired caching
> properties
> > for each of these elements.
>
> This is a good approach. Maybe we can classify the elements by their
> lifetime, location (remote resource vs. local file system) and
> their associated entities (user, user-session, portal, portlet, etc.)
> Are there more parameters ? I'd expect that depending on the usage
> scenario of the portal, different caching policies will be appropriate
> for the different element classes. We should create up with a list of
> different usage scenarios against which we can validate our ideas.
[SNIPPED]
FYI, I think there was talk on the Turbine list about supporting multiple
cache singletons with different policies. Can't remember if these changes
were made yet. I'll try to check it out or someone could check the mail
lists.
jb
-----------------------------------------------------------------------
This message has been scanned for viruses with Trend Micro's Interscan VirusWall.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
