Why a cached object must be Serializable

[Hanson Char <HC...@realm.com>]

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