You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by gerhard <g-...@gmx.de> on 2001/06/16 15:04:12 UTC
[C2] storing extension
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.
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.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] storing extension
Posted by gerhard <g-...@gmx.de>.
> > Ok,
> > then I will start with the implementation this week.
> > One question still left:
> > - where to store the files/file? My proposal: COCOON_WORKDIR/cache-files
>
> I've lost you here. Which files/files are you talking about?
Sorry,
I meant where to store the cached objects on the fs or should it be
configurable?
Cheers
Gerhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2] storing extension
Posted by giacomo <gi...@apache.org>.
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" <gi...@apache.org>
> > > To: <co...@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
RE: [C2] storing extension
Posted by Vadim Gritsenko <vg...@hns.com>.
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" <gi...@apache.org>
> > To: <co...@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
Re: [C2] storing extension
Posted by giacomo <gi...@apache.org>.
On Mon, 18 Jun 2001, gerhard wrote:
> ----- Original Message -----
> From: "giacomo" <gi...@apache.org>
> To: <co...@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
Re: [C2] storing extension
Posted by gerhard <g-...@gmx.de>.
----- Original Message -----
From: "giacomo" <gi...@apache.org>
To: <co...@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
Cheers
Gerhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] storing extension
Posted by giacomo <gi...@apache.org>.
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: 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] storing extension
Posted by gerhard <g-...@gmx.de>.
> > 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: 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
Re: [C2] storing extension
Posted by giacomo <gi...@apache.org>.
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: 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