> > 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...
> 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!
Slowly but constant I understand the design of Cocoon2. Sorry that I
made some noise here with trivial questions last times...
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]
