cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@hns.com>
Subject RE: [C2] storing extension
Date Mon, 18 Jun 2001 20:34:49 GMT
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.

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


Mime
View raw message