jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shamir Karkal" <shamir.kar...@mphasis.com>
Subject RE: Why a cached object must be Serializable
Date Mon, 26 May 2003 04:43:08 GMT
Dear All,

Rather than having a setting in the .ccf file, I think it would be better to extend the existing
api with a new one that uses  Serializable. This way, we can specify the behaviour of the
new api in the javadoc, where its hard for anybody to miss. A user can decide which api to
use, the thread-safe or the "traditional" one, based on his requirements. It seems to me that
this gives maximum flexibility without breaking existing code. 

BTW, its "SingleThreadModel".

Regards

S H A M I R
MphasiS India 
139 / 1, "Aditya Complex",
Hosur Road, Koramangala,
Bangalore - 560 095, India.
Phone : 80-552 2713/14 Extn. 2387
Fax : 80-552 2719
Architecting Value 
SEI Level 5 ISO 9001 



> -----Original Message-----
> From: Hanson Char [mailto:HChar@realm.com]
> Sent: Sunday, May 25, 2003 12:46 AM
> To: 'Turbine JCS Users List'
> Subject: RE: Why a cached object must be Serializable
> 
> 
> >I don't see the requirement that a caching system HAS to provide
> thread-safe objects.
> >This is the job of design and implementation of the object.
> 
> Not that a caching system has to provide thread-safe objects, 
> but to most
> users, a caching system that provides thread-safe objects by 
> default is a
> less confusing behavior than otherwise.    Without changing the API to
> Serializable, however, any such caching system simply cannot provide
> thread-safe objects no matter what implementation is behind the API.
> 
> >If an object is immutable then the cloning is unnecessary.
> 
> Of course.  I agree.  Changing the API does NOT mean the 
> implementation
> should clone all the time.  Not at all.  My suggestion of 
> cloning is just a
> rough and quick way to illustrate how such thread-safety can be easily
> achieved.  More sophisticated implementation is conceivable, 
> provided the
> API allows it.
> 
> >Assume now thread 1 retrieves the clone A' of object A, 
> thread 2 clone A''.
> >Both clones are modified an put back into the cache which 
> modification will
> >survive?
> 
> The one put later in time will overwrite the one put previously.  It's
> logically correct as long as the put operations are atomic 
> and done in FIFO,
> similar to atomic database update operations.
> 
> >But the API for a cache is correctly done in JCS.
> 
> Not quite if thread-safety is considered an important behavior of the
> retrieved cached items, as the current API in JCS constrains the
> implementation in such a way that thread-safe objects are 
> just not possible
> except in the most trivial cases (such as the use of 
> immutable objects with
> all final fields and no possibly modifiable composite parts.)
> 
> I would say the API is correctly designed only if at least it 
> opens up the
> possibility for the implementation to provide thread-safe 
> cached items.  The
> current API fails to do so.
> 
> >Servlet is not implemented thread-safe then this is simply a bug.
> >Nobody to blame then the implementor, no way to complain 
> because Servlets
> >are specified as shared objects.
> 
> Even the Servlet API provides the option of allowing a 
> servlet object to be
> made thread-safe by implementing a marker interface (something like
> "SingleThreadedModel"?).  JCS API simply does not provide 
> thread-safe cached
> items except for the trivial case indicated above.
> 
> >If an object is cached then it has to be thread-safe if it 
> is shared or it
> >hast to be exclusively owned.
> 
> A cached item does NOT have to be thread-safe,.  By default 
> it should.  At
> the very least the thread-safety feature should be 
> specifiable by the users
> of the caching system.  It's just impossible to do so with 
> the current JCS
> API.
> 
> Hanson
> 
> -----Original Message-----
> From: Heinz Drews [mailto:heinz@drews.tc]
> Sent: Saturday, May 24, 2003 11:45 AM
> To: Turbine JCS Users List
> Subject: Re: Why a cached object must be Serializable
> 
> 
> > >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.
> 
> I think that it is a good reason.  If a method requires a 
> Serializable then
> it should
> publish it in the signature instead of implicitely assuming that the
> argument is
> correct and suffering an exception.
> 
> > 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.
> 
> I don't see the requirement that a caching system HAS to 
> provide thread-safe
> objects.
> This is the job of design and implementation of the object.
> 
> The cloning would open quite a can of worms.
> 
> If an object is immutable then the cloning is unnecessary.
> 
> If an object is modifiable and cached then cloning would 
> produce a disaster.
> Modified objects would have to be put back into the cache.
> Assume now thread 1 retrieves the clone A' of object A, 
> thread 2 clone A''.
> Both clones are modified an put back into the cache which 
> modification will
> survive?
> 
> If the modification to the clones are not put back then 
> caching was the
> wrong pattern,
> a Factory would be the correct one.
> Using serialization via JCS to act as the Factory is 
> definitely not the
> fastest possible implementation.
> 
> > >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.
> 
> But the API for a cache is correctly done in JCS.
> 
> > That's the point.
> 
> I would say the point is to choose the correct pattern.
> 
> If e.g. a Servlet is not implemented thread-safe then this is 
> simply a bug.
> Nobody to blame then the implementor, no way to complain 
> because Servlets
> are specified as shared objects.
> 
> If an object is cached then it has to be thread-safe if it is 
> shared or it
> hast to be exclusively owned.
> 
> 
> 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
View raw message