Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <00bb01c32511$a0debed0$7801a8c0@fsConnect.org>
From: "Heinz Drews" <heinz@drews.tc>
To: "Turbine JCS Users List" <turbine-jcs-user@jakarta.apache.org>
References: <C26EEF8D62108C4F86C695323A563F2F024E9D89@nyc0601.realpulse.com>
Subject: Re: Why a cached object must be Serializable
Date: Wed, 28 May 2003 07:06:53 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hanson,

First:
> Interesting idea but Cloneable won't work as Cloneable only suggests
> "shallow copy" (like the Object.clone() behavior) which is insufficient to
> provide thread safety if there are composite modifiable parts in the
cached
> item.
Cloneable is a marker interface which indicates that an Object accepts to
get clone()
invoked.  No conclusion about the implementation of clone() can be made.

Second:
> Serializable is better.
What gets you to the idea that serializing/deserializing would provide
always a clone of the object?
Beside the facts you mentioned yourself that any object can throw
NotSerializable which
would screwup the cloning in a pretty way nothing can prevent that
readResolve() is implemented.
And in readResolve() it would be possible to retrieve an object reference
from the cache and
return it instead of the expensively constructed copy.

Third:
The reason why I use a cache is to have a managed container for
objects which are expensive to construct.
But the cache is not the final container because objects can be simply
removed from
the cache when the cache manager applies the defined strategy.
A backup of a cache into an auxiliary storage is an optional way to increase
the cache capacity.
And a solution which requires careful consideration because it might be
faster to construct the
object again from the real source then using the generic approach
implemented in an aux cache.

Fourth:
As Les wrote feel free to implement a solution which provides the behavior
you so strongly desire.  This allows that everybody can use it if wanted.
If the cloning would be made the default behavior I would only see two
options for my projects:
- Looking for a real cache implementation to replace JCS
- Removing the @*# from the JCS sources
Open source is a wonderful thing.

Fifth:
Can you please go back to square one and describe your problem instead of
discussing an assumed generic solution for a problem only you have?
If not then this will be my last comment to the topic.


Best regards,
Heinz