[EMAIL PROTECTED] wrote:
> >
> > [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.
>
Location is not meaningful for me. It should be transparent. I would change it
by cacheable vs non-cacheable. I would specify most (but maybe not all) local
objects as non-cacheable. Conversely, a user PSML can be stored in a remote
server, but still be non-cacheable.
There is also the writable attribute. For instance, JetspeedContent files are
writable, and also user PSML files once the Customizer works.
Another distinction, done by Avalon, is CharacterStream versus Object. For
instance, the remote channels are currently recovered as streams, while the
user PSML would be better hadled as an object, i.e. parsed before caching.
They really speak about ByteStreams, but we would need the distinction to
avoid i18n problems later on, as the character encoding of a URLConnection
gets lost once the cache encapsulates it as a InputStream.
I would not use the entities, but have a distinction between Objects and
CharacterStreams or ByteStreams, and have Objects used implement some
interface, that would have unmarshall( Stream/Reader ) and marshall (if they
are writable) as methods. So, the service could cache an object given the
class and a url. Also, if the object is writable, the copy could be modified
and saved back to the given url.
>
> >
> > [ 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]
--
--------------------------------------------------------------
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]
