jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <aasm...@wisc.edu>
Subject RE: Why a cached object must be Serializable
Date Fri, 23 May 2003 04:12:38 GMT
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


Mime
View raw message