jakarta-jcs-users 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 Sat, 24 May 2003 12:57:04 GMT
>I agree with you that the signature should be Serializable and not Object.
>But only because the CacheAccess implementation already forces that the
objects
>have to be Serializable or a ClassCastException  is thrown.
>It would be better if the check is done at compile time and not at run
time.

What you are saying is we should change to Serializable because of the
existing JCS implementation.  I am not sure if that's a very good reason,
but anyway I am glad you agree with the change.

The "compile-time" argument does help make the system runtime behavior more
"predictable", taking advantage of help from the compiler.  However, suppose
the API is changed to Serializable, although one now gets rid of the
ClassCastException, there is always the possibility that one will get a
"NotSerailizableException".  The reason is the Serialzable API will then
require ONLY the object directly passed to it to implement the Serializable
interface.  If any composite part (eg member object fields) of such object
didn't implement the Serializable interface and didn't have the transient
modifier specified, the compiler won't be able to help and an exception will
be thrown.

>The Cache pattern is for SHARED objects. 
>If an object is not designed to be shareble or thread-safe then it can't be
cached.
>Pool, Factory or other patterns have to be used.

Suppose the change is made to Serializable, if an object is NOT designed to
be sharable or thread-safe, of course it CAN still be cached if the user
knows what he is doing and explicitly specify the "by reference" caching
attribute.  In such case the cached item will be SHARED objects.  The point
is the user must make it explicit to do so before taking on the onus of
concurrency.  The reasonable default for a caching system, however, must
provide thread-safe cached items.

>It can't be the job of an implementation to correct design errors.

You are absolutely right.  If the API is not designed right, the
implementation is forever handicapped.

That's the point.

Hanson

-----Original Message-----
From: Heinz Drews [mailto:heinz@drews.tc]
Sent: Saturday, May 24, 2003 6:55 AM
To: Turbine JCS Users List
Subject: Re: Why a cached object must be Serializable


Hanson,

I agree with you that the signature should be Serializable and not Object.
But only because the CacheAccess implementation already forces that the
objects
have to be Serializable or a ClassCastException  is thrown.
It would be better if the check is done at compile time and not at run time.

For the remaining part of you proposal regarding the cloning I absolutely
disagree.
The Cache pattern is for SHARED objects.
If an object is not designed to be shareble or thread-safe then it can't be
cached.
Pool, Factory or other patterns have to be used.

It can't be the job of an implementation to correct design errors.

Best regards,
Heinz


---------------------------------------------------------------------
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