Hi Hanson.
I saw this a long time ago. I think there may have been some discussion
on the issue. I can't remember. I bet there are some instances of
cloning items taken from the cache before modification (in your and my
old code base). I assumed that everyone would treat the objects as
references to objects in the cache, but I see how this could lead to
some serious problems if people didn't know this. Hmmn.
I'd hate to clone everything that went into the cache for these rare
cases. I wonder what the performance penalty might be. Maybe it could
be a configuration option for a region, if this could be implemented.
Perhaps adding a deep clone method might do the trick. An element
attribute that the get method checks might do the trick. What do you
think?
Chers,
Aaron
> -----Original Message-----
> From: Hanson Char [mailto:HChar@realm.com]
> Sent: Thursday, May 22, 2003 11:00 PM
> To: 'Baum, Karl'; Hanson Char; ''Turbine JCS Developers List' ';
> ''turbine-jcs-user@jakarta.apache.org' '
> Subject: RE: Why a cached object must be Serializable
>
> >A user of JCS may want to cache immutable objects.
>
> Sure, but that's the special/trivial case rather than general case.
>
> How many users of JCS intend to cache ONLY immutable objects ?
>
> Are they aware of the fact that if the objects they put into the cache
are
> not immutable but are indeed accidentally changed, the behavior of
such
> changes are unpredictable in a concurrent environment ?
>
> What good is a high-performance caching system if the behavior is
> unpredictable whenever there is concurrent use of the cached items,
unless
> such cached items are immutable ?
>
> What measures do JCS provide to guarantee that the objects put to the
> cache
> are immutable to avoid concurrency chaos ?
>
> -----Original Message-----
> From: Baum, Karl [mailto:Karl.Baum@Tallan.com]
> Sent: Thursday, May 22, 2003 10:33 PM
> To: 'Hanson Char '; ''Turbine JCS Developers List' ';
> ''turbine-jcs-user@jakarta.apache.org' '
> Subject: RE: Why a cached object must be Serializable
>
>
> A user of JCS may want to cache immutable objects. I don't think it
makes
> sense to make copies of immutable objects each time they are retrieved
> from
> the cache. This only hurts performance. For example, many
applications
> deal with product data which is never modified by the application.
Should
> we be cloning this product data each time?
>
> -----Original Message-----
> From: Hanson Char
> To: 'Turbine JCS Developers List';
'turbine-jcs-user@jakarta.apache.org'
> Sent: 5/22/2003 11:20 PM
> Subject: Why a cached object must be Serializable
>
> About 6 months ago I proposed to the JCS project that the caching API
> should
> be changed such any object to be cached or retrieved from the cache
> should
> be passed as Serializable rather than Object.
>
> Recently I've come across a situation that further justifies such
> proposal.
> (A situation that arises from our "sister project" - a remote caching
> system
> used extensively in our production environment.)
>
> Basically, if access to a cached object is by reference, any
concurrent
> access by multiple threads to the same cached item will result in
chaos,
> except in the most trivial cases where only a single thread can access
> the
> same cache item at ALL time.
>
> Therefore, an item put into the cache must be by value, and an item
> retrieved from the cache must also be by value. In order to achieve
> this, a
> cache item must be deeply cloned into copies. The best way to do so
is
> by
> serializing and deserializing.
>
> Suppose the proposed change to the API is made. The implementation
> would
> then become possible to enforce that whenever an object is put into
the
> cache, a copy of such object is put into cache rather than the object
> per
> se. Similarly, whenever an object is "get" from the cache, a copy of
> such
> object is returned rather than the actual object that currently exists
> in
> the cache. In other words, clients retrieving objects from the cache
> would
> then always get their own private copies. To change an object in the
> cache,
> one must then explicitly "put" the changed object to the cache (of the
> same
> key).
>
> Such is the correct behavior one should expect from any such caching
> API.
>
> One potential side effect of such proposed change, however, is that
> previously objects put into cache with non-serializable parts will
fail
> fast
> when put into cache (unless marked with transient of course.)
>
> Hanson
|