Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Gerhard Froehlich" <g-froehlich@gmx.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: cvs commit:  MRUMemoryStore.java FilesystemQueueObject.java
Date: Mon, 28 Jan 2002 21:39:35 +0100
Message-ID: <LDEKKGCNJLEPFDOEIHFDEECFCPAA.g-froehlich@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <76227803D20F654BA920161144532EB742D6@earth.centervilletech.com>

Hi,

>-----Original Message-----
>From: Britton, Colin [mailto:cbritton@metatomix.com]
>Sent: Monday, January 28, 2002 5:59 PM
>To: cocoon-dev@xml.apache.org
>Subject: RE: cvs commit: MRUMemoryStore.java FilesystemQueueObject.java
>
>
>For our application I want to not only cache from memory, but also store
>the objects on the fileSystem (as the cost of generation in our app can
>be high). With the change so that items are only written to the file
>system when the number of memory objects reaches max and this.free() is
>called it seems that we loose this capability unless we set the memory
>objects to a small number (which defeats the objective of the cache and
>having lots of memory). One of the benefits of the old way was that if
>the VM unexpectedly quits we had the file system cache for all the items
>that were in memory. Also all memory objects are lost after shutdown,
>maybe it would also be also a good idea to write the memory objects to
>disk on a formal shutdown (this was not needed with the old method) if
>the queue method is not returned.

You can't imagine how much thoughts I wasted for that issue. I will 
explain you them (again):

a) The old way stored every object twice. First in Memory, Second on the
Filesystem. That was a very _expensive_ operation. We needed an extra
thread which did all that serialization and he eated performance. 
The only real advantage was to have the objects persistent after a JVM
restart. Therefor I never had a good feeling about that. This are too
little advantages.

And besides, how often crashes the JVM. Every day, weekly, monthly. How long
does it take till the old caching status is reached? The first user gets
a slow page. The next a quick one.

I wanna have a clean implementation. This other issues are parts of the adaptive
caching or something else I say. It must be simple!

b) The new way behaves more like a normal OS cache. First everything is handeld
in memory. If this is running, old ones are swapped out to make room for others.

At least I see no way how to handle a formal shutdown. Did would be the
best. Then we could catch this event and save the memory store down to 
the Filesystem.

Maybe the others do have a idea here.

  Gerhard

+----------------------------------------------+
My parents have been visiting me for a few days. 
I just dropped them off at the airport. 
They leave tomorrow. 
+----------------------------------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org