jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honig, Daniel" <DHo...@tiaa-cref.org>
Subject RE: Why a cached object must be Serializable
Date Wed, 28 May 2003 20:49:15 GMT
Some random comments on this thread, I'm far behind and haven't the proper
time to catch up:

1.) I thiink the argument of pass by reference (Objects) or pass by
value(Serializable) is best left configurable.  In most applications I
probably would intend to have all my cached objects serializeable.  But I
would like JCS to be flexible for the odd moments that this isn't possible.
2).  Does anyone know how commercial cache's such as Tangosol or
SpiritSoft's cacheing products function?  
3).  One of the things I have considered is figuring out how to use JCS with
JMS for a truely high performance cache that complies fully to J2EE
standards.  Lateral TCP caching(sockets) is reaching outside the spec.  For
this use, having the ability to only cache Serializable objects is
neccessary as JMS will only allow objects that are serializable to be sent. 
In general I side that thread safety is the resonsibility of the
application.  The cache should not introduce threading issues.  I don't like
components that spawn threads by default. I'd prefer the cache to be
entirely single threaded until I configure it not be so because I need XX


-----Original Message-----
From: Hanson Char [mailto:HChar@realm.com]
Sent: Wednesday, May 28, 2003 8:57 AM
To: 'Turbine JCS Users List'
Subject: RE: Why a cached object must be Serializable

Cloneable per se is indeed a marker interface just like Serializable.
However, according to the JDK API,

"A class implements the Cloneable interface to indicate to the
Object.clone() method that it is legal for that method to make a
field-for-field copy of instances of that class."

And if you check out the Object.clone() API:

"The method clone for class Object performs a specific cloning operation.
First, if the class of this object does not implement the interface
Cloneable, then a CloneNotSupportedException is thrown. Note that all arrays
are considered to implement the interface Cloneable. Otherwise, this method
creates a new instance of the class of this object and initializes all its
fields with exactly the contents of the corresponding fields of this object,
as if by assignment; the contents of the fields are not themselves cloned.
Thus, this method performs a "shallow copy" of this object, not a "deep
copy" operation."

The shallow copy is not good enough in general for thread safety.  Hence my
conclusion of it not being as good as Serializable.  These 2 interfaces both
have the potential of throwing some kind of runtime exception (not cloneable
or not serializable) and therefore they don't really differentiate much from
each other based on the runtime exception throwing behavior.

Assuming no exception is thrown, however, in general Serializable provides
possible deep clone implementation which Cloenable does not.   Hence
Serialziable is better for thread saftey purposes.


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


> Interesting idea but Cloneable won't work as Cloneable only suggests
> "shallow copy" (like the Object.clone() behavior) which is insufficient to
> provide thread safety if there are composite modifiable parts in the
> item.
Cloneable is a marker interface which indicates that an Object accepts to
get clone()
invoked.  No conclusion about the implementation of clone() can be made.

> Serializable is better.
What gets you to the idea that serializing/deserializing would provide
always a clone of the object?
Beside the facts you mentioned yourself that any object can throw
NotSerializable which
would screwup the cloning in a pretty way nothing can prevent that
readResolve() is implemented.
And in readResolve() it would be possible to retrieve an object reference
from the cache and
return it instead of the expensively constructed copy.

The reason why I use a cache is to have a managed container for
objects which are expensive to construct.
But the cache is not the final container because objects can be simply
removed from
the cache when the cache manager applies the defined strategy.
A backup of a cache into an auxiliary storage is an optional way to increase
the cache capacity.
And a solution which requires careful consideration because it might be
faster to construct the
object again from the real source then using the generic approach
implemented in an aux cache.

As Les wrote feel free to implement a solution which provides the behavior
you so strongly desire.  This allows that everybody can use it if wanted.
If the cloning would be made the default behavior I would only see two
options for my projects:
- Looking for a real cache implementation to replace JCS
- Removing the @*# from the JCS sources
Open source is a wonderful thing.

Can you please go back to square one and describe your problem instead of
discussing an assumed generic solution for a problem only you have?
If not then this will be my last comment to the topic.

Best regards,

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

This message, including any attachments, contains confidential information intended for a
specific individual and purpose, and is protected by law.  If you are not the intended recipient,
please contact sender immediately by reply e-mail and destroy all copies.  You are hereby
notified that any disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.

View raw message