cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: [C2] storing extension
Date Mon, 18 Jun 2001 21:27:04 GMT
On Mon, 18 Jun 2001, Vadim Gritsenko wrote:

> I think he meant these files:
>
> > > > > > > Store.hold():
> > > > > > > When holding a object in the memory, it will be simultaneously
written
> > > > > > > on to filesystem. The reason is, that when for example
the JVM is restartet
> > > > > > > all cached objects will be in persistent state on the filesystem.
That would
> > > > > > > increase the performance much.
> > > > > > > According to Carsten, only CachedEventObjects and CachedStreamObjects
> > > > > > > will be stored on the filesystem. Because they could be
made serializable.

Oh, these file have to be in the working directory for sure. Like every
other working files like the XSP generated java and class files.

Giacomo

>
> Regards,
> Vadim
>
> > -----Original Message-----
> > From: giacomo [mailto:giacomo@apache.org]
> > Sent: Monday, June 18, 2001 15:52
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: [C2] storing extension
> >
> >
> > On Mon, 18 Jun 2001, gerhard wrote:
> >
> > > ----- Original Message -----
> > > From: "giacomo" <giacomo@apache.org>
> > > To: <cocoon-dev@xml.apache.org>
> > > Sent: Sunday, June 17, 2001 1:09 PM
> > > Subject: Re: [C2] storing extension
> > > > On Sun, 17 Jun 2001, gerhard wrote:
> > > >
> > > > > > > Hi Team,
> > > > > > > following proposal for the storing extension:
> > > > > > >
> > > > > > > Store.hold():
> > > > > > > When holding a object in the memory, it will be simultaneously
written
> > > > > > > on to filesystem. The reason is, that when for example
the JVM is restartet
> > > > > > > all cached objects will be in persistent state on the filesystem.
That would
> > > > > > > increase the performance much.
> > > > > > > According to Carsten, only CachedEventObjects and CachedStreamObjects
> > > > > > > will be stored on the filesystem. Because they could be
made serializable.
> > > > > > > One question:
> > > > > > > The unique key, which is generated from those CachePiplines,
is it always
> > > > > > > the same key? I observe the key generation over several
JVM restarts and
> > > > > > > it seemed to be always the same key for every sitemap component.
> > > > > >
> > > > > > Key generation depends on what a component thinks is important
to
> > > > > > integrate into it. Usually they are file names or the last modified
> > > > > > dates of them (for the standard components we have). This will
change as
> > > > > > soon as we have documented how XSP can benefit from the caching
system
> > > > > > (by use of my halfway finished caching logicsheet).
> > > > > What does it mean now. Could you recover the objects over several
JVM restarts
> > > > > with this key or are they always invalid then? I want to keep my
component
> > > > > dull :-), because I think that is part of the caching classes...
> > > >
> > > > I cannot tell because I'm not too familiar with the hole key generation
> > > > algorithms but I think as you have investigated that keys will stay the
> > > > same accross JVM invokations.
> > > >
> > > > > > Another story is Validities (don't know if they gonna play a
> > > > > > role in here) If we introduce
> > > > > > something like a ExpirationValidity class to state how long
a cached
> > > > > > object can stay in the cache. But as I mentionend alreaady this
is not
> > > > > > key generation.
> > > > > I don't know too :-). But I have to made those ValidityObject's seriazable,
because
> > > > > the CachedEventObjects and CachedStreamObjects contains a Map with
> > > > > ValidityObject's. But I dont't know if we are speeking from the same.
> > > > > > > Store.get():
> > > > > > > When getting a object from the store, the method first
looks if the object
> > > > > > > is available in the memory. When the lookup fails, then
the method takes
> > > > > > > a look at the filesystem. If this lookup fails again, null
is returned.Otherwise
> > > > > > > the object, when the Object.liftime is valid.
> > > > > >
> > > > > > How about an indication if the object is on the filesystem.
This way you
> > > > > > can always stop searching when there isn't a mark in memory
for the
> > > > > > object one is looking for (file system access can be slow and
degrade
> > > > > > performance).
> > > > > Good idea, I will pay attention!
> > > >
> > > > Cool :)
> > > >
> > > > >
> > > > > Slowly but constant I understand the design of Cocoon2. Sorry that
I
> > > > > made some noise here with trivial questions last times...
> > > >
> > > > No problem. That's part of why this list here. Feel welcome.
> > > >
> > > > Giacomo
> > > Ok,
> > > then I will start with the implementation this week.
> > > One question still left:
> > > - where to store the files/files? My proposal: COCOON_WORKDIR/cache-files
> >
> > I've lost you here. Which files/files are you talking about?
> >
> > Giacomo
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message