Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <C26EEF8D62108C4F86C695323A563F2F024E9D8D@nyc0601.realpulse.com>
From: Hanson Char <HChar@realm.com>
To: 'Turbine JCS Users List' <turbine-jcs-user@jakarta.apache.org>
Subject: RE: Why a cached object must be Serializable
Date: Wed, 28 May 2003 08:02:18 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32519.5E732380"

------_=_NextPart_001_01C32519.5E732380
Content-Type: text/plain;
	charset="iso-8859-1"

Implementation is easy when it is the right idea.  Arriving to the right
idea, however, is hard.  And getting the right idea across to others
sometimes is harder.

Hanson

-----Original Message-----
From: Les Hazlewood [mailto:lhazlewood@transdynatlanta.com]
Sent: Tuesday, May 27, 2003 9:27 AM
To: 'Turbine JCS Users List'
Subject: RE: Why a cached object must be Serializable


I wholeheartedly agree.  This enables more power/control of performance and
memory to the developer using JCS, albeit with a little extra work.  I
prefer power and flexibility rather than a "blanket" solution.  _I_ want to
control how my cache is used. 

Hanson, if you still disagree, you can always code a threadsafe
implementation of JCS and submit it to the JCS folks for incorporation.  If
you continue to feel as strongly as you do about this feature, you can help
everyone using JCS by contributing back to the project.  Then one could turn
on a switch in their ccf file to use threadsafe/cloning or not, depending on
their preferences.

This is what makes open source great.  If you feel your ideas would benefit
the project, give back to it by making an effort :)

Les

 
> Hanson,
> 
> I can only repeat my opinion that it is not the job of a cache
> implementation to make an object
> thread-safe, it is the job of the application to put only thread-safe
> objects into the cache or
> ensure single-thread processing.

------_=_NextPart_001_01C32519.5E732380--