>
> [EMAIL PROTECTED] wrote:
> >
> > > Raphael Luta wrote:
> > >
>
> I never wrote what is below. This quote is from Santiago. Please take
> care when quoting, misquotations make following the thread real
> difficult...
Sorry for that - I'll be more careful.
>
> > > That is a memory cache. The problem is that the PSML should be
> > > fetched/parsed atomically, and then stored in a memory cache such
> > > as the Turbine one, to avoid race conditions if we use frames. This
> > > is true of most external resources, that should be fetched
> > > atomically and then cached until they expire.
> > >
> > > With regards to the retrieval of external resources (basically URLs)
> > > Jetspeed needs an API that respect several requirements:
> > >
> > > - No resource will be fetched in parallel by more than one thread.
> > > One thread will fetch it and the others will wait until completion.
> > > - No resource will be fetched again until it expires.
> > > - A writable resource will expire as soon as it is written.
> > > - Calls to check availability, get a Reader and get a Writer on the
> > > resource.
> > > GetObject for non character stream objects.
> > > - I notice now that we need a hook for Fetching, depending on the
> > > type of object (e.g. parsing/unmarshalling XML is included in the
> > > process)
> >
> > This reminds me of the service concept we discussed some time ago.
> > Similarly to other services, we could define a CacheService interface
> > for which different implementations may exist.
> >
>
> 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.
>
> [ Quick aside: I didn't answer to your concerns on the MRU
> performance because the more I think about it, the more I feel this
> is barking at the wrong tree: if you're considering a high-performance
> high-spec setup you're also considering DBMS persistence of PSML
> and caching will be done at the element level, not a serialized XML
> file ]
[We were indeed thinking of putting XML elements in database table rows
initially, but the way JetSpeed processes PSML and given the fact that
the elements in the PSML can recursively contain each other led us to
the decision to persist entire PSML files as BLOBS. Thus, caching of
PSML object trees is relevant for us.]
>
> --
> Raphaël Luta - [EMAIL PROTECTED]
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
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]
