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 functionality. -Daniel -----Original Message----- From: Hanson Char [mailto:[EMAIL PROTECTED] 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. Hanson -----Original Message----- From: Heinz Drews [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 7:07 AM To: Turbine JCS Users List Subject: Re: Why a cached object must be Serializable Hanson, First: > 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 cached > 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. Second: > 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. Third: 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. Fourth: 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. Fifth: 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, Heinz --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** 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. TIAA-CREF ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
