Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@envision.asiaconnect.com.my
Message-ID: <38BC7A5E.3FA42EF7@localbar.com>
Date: Wed, 01 Mar 2000 10:03:11 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Memory Store and JDK 1.2
References: <000001bf820b$c91968c0$0c00000a@trantor>
 <38BBD488.C9207AD9@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> Ouch, this is not that useful. I like the newer system in 1.7 that calls
> the cache-cleanup if an OutOfMemory error is caught.

There is one problem with this strategy though.
OutOfMemoryError is not an Exception, and for good reasons. It may occur, theoretically at any instruction
of the JVM, not necessarily at well-defined spots. There are many instances where there is no way to
recover after such an ERROR has occurred, and the application should fail to avoid further grievance.

The SoftReferences are not particularly good either, since they are all reclaimed in a single go, since
the GC has no clue of which would be the best to keep.

BUT, as far as I know, there are ways to hook into the JVM's GC and/or heap manager to be notified of
GC events and low memory conditions. I don't know at this time if it is documented, but the RMI subsystem
uses it even in JDK 1.1.

Niclas