jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hanson Char <HC...@realm.com>
Subject RE: Why a cached object must be Serializable
Date Fri, 23 May 2003 04:28:09 GMT
The point is "these" are not the rare cases, but actually the normal cases
if JCS is to provide any correctness in program behavior.  Even for
immutable objects, how can JCS guarantee immutability if not via copying ?
If JCS cannot guarantee program correctness when used, it's pointless no
matter how fast JCS may seem to be.

Treating objects as references to objects in the cache is fundamentally
flawed.  No such assumption should be made by the users of the caching
system.  Users of JCS shouldn't care.

If a user of JCS only caches immutable objects, how can such user make sure
that he never changes the objects cached by accident ? 

If a user caches mutable objects, how can such user avoid concurrency chaos
?

All the answers point to the change proposed.  Correctness must first be
attained before performance.  Optimization/performance is really an
implementation issue for JCS.  The current API of using Object is flawed in
JCS regardless of the final performance attained.  For the API cannot
guarantee correctness.

Hanson

-----Original Message-----
From: Aaron Smuts [mailto:aasmuts@wisc.edu]
Sent: Thursday, May 22, 2003 11:13 PM
To: 'Turbine JCS Users List'; 'Baum, Karl'; ''Turbine JCS Developers
List' '
Subject: RE: Why a cached object must be Serializable


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


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message