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
>
> Cheers
> Gerhard
> >
> > Giacomo
> >
> > > Store.free():
> > > The same behavior as now. The object is will be removed from memory
> > > but not from the filesystem.
> > >
> > > Store.remove():
> > > The object will be removed from the memory and from the filesystem.
> > >
> > > Comments?
> > >
> > > cheers
> > > Gerhard
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
