jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hanson Char <hc...@apache.org>
Subject [SOURCE] Issue #JCSS1 modified
Date Fri, 23 May 2003 04:25:30 GMT

Issue JCSS1 has just been modified by user hchar

You can view the issue detail at the following URL:

The following modifications were made to this issue:

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

Such is the correct behavior one should expect from any such caching API.

View raw message