On Sat, 16 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).
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.
> 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).
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]
