jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Baum, Karl" <Karl.B...@Tallan.com>
Subject RE: Why a cached object must be Serializable
Date Fri, 23 May 2003 03:33:09 GMT
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