Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <7917C9BA5323D3118091009027856EA906A451BC@exchange.net.tallan.com>
From: "Baum, Karl" <Karl.Baum@Tallan.com>
To: 'Turbine JCS Users List' <turbine-jcs-user@jakarta.apache.org>
Subject: RE: Why a cached object must be Serializable
Date: Fri, 23 May 2003 23:18:42 -0400
MIME-Version: 1.0
Content-Type: text/plain

I think cloning ALL objects by default is taking thread safety  a little too
far.  Giving java programmers the option to clone objects returned from the
cache allows for more flexibility.

For example... there is no reason to clone a String stored in the cache.  A
string is immutable.  Cloning it would be redundant as there is no legal way
to modify the state of this object.  


-----Original Message-----
From: Hanson Char [mailto:HChar@realm.com] 
Sent: Friday, May 23, 2003 11:16 PM
To: 'Turbine JCS Users List'
Subject: RE: Why a cached object must be Serializable

>All my deployed uses of JCS cache only immutable objects.

Interetly, how do you know/guarantee that they are actually immutable ?  Are
all member fields of your deployed objects declared final and none of them
contain any further composite structure with potentially mutable components
?  If not, how can you absolutely ascertain some code someday somewhere
wouldn't "mutate" your "immutable" objects retrieved from cache concurrently
while you are accessing them, relying on their immutability for
mission-critical systems ?

>Your proposed 'cloning' solution would add some extra safety at the cost of
performance. 

I see this feature as something very basic and fundamental, not anything
extra at all !  A user shouldn't be expected to handle
unnecessary/unexpected concurrency whenever an object is retrieved from a
caching system, unless he explicitly indicated so with full knowledge of the
risk, cost and subtleties.  Performance comes secondary when otherwise it
can easily lead to chaos.

>It still has potential for confusion. Users still need to
>understand what the cache is doing -- specifically that modifying the item
>they get back will not change what is in the cache, the cache item is still

>immutable.

Almost anything has potential for confusion.  It's a matter of whether the
potential is of reasonable size when designing/exposing an API.  In this
case, which side has higher potential for confusion ?  Is it more confusing
to:
1)require a user to expect/handle the potential of multiple threads
concurrently accessing/modifying every single object he retrieved from a
caching system; or
2)require a user to expect an idempotent behavior of always retrieving the
same thread-safe copy from a caching system with the same key, unless (of
course) there had been an intermediate "put" with a different value ?

In short, is it more confusing to have a thread-safe object retrieved from a
caching system, or have a non-thread-safe object ?

>I have no problem adding this as a feature, but I don't think it should be
the norm.

Unfortunately just adding the "by value" as a nice-to-have "feature" is
vastly insufficient.   JCS will never mature as a powerful and reliable
caching system for any serious application without having thread-safety as
the default behavior for the cached items retrieved.

>Also, I still object to changing the signature. Sometimes you want to cache
>things which are not serializable. 

Serializable is just a marker interface.  Nothing more and nothing less.  No
overhead is incurred per se just because some objects implement this
interface.  (The overhead entirely depends on the implementation behind the
API.  That's where JCS should shine, not via compromising the API.)

However, without it JCS can never guarantee thread safety for cached items.

>JCS is supposed to have a generic API for caching, while the serializable
constraint results 
>from a specific way of implementing the cache.

The idea of a generic API is a deception if any such generic API cannot even
provide thread safety as a necessary default behavior.  Conversely, just
because an object implements a marker interface X doesn't make it loss any
"genericity".  On the contrary, requiring the cached items to implement such
zero overhead interface in the API signature opens up the possibility that
the service provided behind the API can truly provide an absolutely
thread-safe behavior.  A guarantee fully indicated by the API per se which
is impossible otherwise.

Ironically, the deceptively generic Object signature currently used actually
constraints the API to such an extent that no such thread-safety behavior
can ever be guaranteed or delivered by JCS.  A sad but true corollary.

Hanson

-----Original Message-----
From: James Taylor [mailto:james@jamestaylor.org]
Sent: Friday, May 23, 2003 7:46 PM
To: Turbine JCS Users List
Subject: Re: Why a cached object must be Serializable


Hanson Char <HChar@realm.com> writes:

> Sure, but that's the special/trivial case rather than general case.  
>
> How many users of JCS intend to cache ONLY immutable objects ?  

All my deployed uses of JCS cache only immutable objects.

Your proposed 'cloning' solution would add some extra safety at the cost of
performance. It still has potential for confusion. Users still need to
understand what the cache is doing -- specifically that modifying the item
they get back will not change what is in the cache, the cache item is still
immutable.

I have no problem adding this as a feature, but I don't think it should be
the norm.

Also, I still object to changing the signature. Sometimes you want to cache
things which are not serializable. JCS is supposed to have a generic API
for caching, while the serializable constraint results from a specific way
of
implementing the cache.

-- jt


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