jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hanson Char <hanson.c...@gmail.com>
Subject Re: Serializing question about JCS in a Lateral Cache config
Date Tue, 13 Sep 2005 00:52:15 GMT
How about providing automatic Serialization via XStream, without requiring 
the client class to implement Serializable ? Zero cache configuration 
required.

Hanson

On 9/13/05, Smuts, Aaron <Aaron.Smuts@travelocity.com> wrote:
> 
> Yes, they can have the same hashCode and be different, but they cannot
> have a different hashCode and be equal.
> 
> We could therefore end up with many cases where the object was not
> removed even though it was different.
> 
> A reasonable hashCode function will not create the same hashCode for
> different version of the same class. It's more likely that an object of
> a different class will have the same hashCode, but this will not happen
> in a cache region where the objects are retrieved by key. I thought it
> might be safe to use hashCode for this reason. The cache would lookup
> the object by the key and then compare the hashCodes. (This would be a
> configuration option.) I don't have a better idea right now that would
> be nearly as efficient.
> 
> If they want to be assured of correctness, then they should configure
> the cache to serialize the object.
> 
> Do you have any suggestions?
> 
> Aaron
> 
> 
> > -----Original Message-----
> > From: Hanson Char [mailto:hanson.char@gmail.com]
> > Sent: Monday, September 12, 2005 5:28 PM
> > To: JCS Users List
> > Subject: Re: Serializing question about JCS in a Lateral Cache config
> >
> > But it's incorrect to rely on hashcode to determine if two objects
> have
> > the
> > same value. Two objects can be completely different but have the same
> > hascode. (Even md5 is broken for that matter). My 2 cents.
> >
> > Hanson
> >
> > On 9/13/05, Smuts, Aaron <Aaron.Smuts@travelocity.com> wrote:
> > >
> > > I'm going to put those options in yes. I'll have them in a few days.
> > > It's fairly easy.
> > >
> > > Also, I'm going to add remove on put for the client. It will pass in
> > > the hashcode of the object. If configured, the receiver can compare
> the
> > > hashcode of the item to remove with the hashcode passed in. If they
> are
> > > the same, it will assume that the object has the same values, and it
> > > will not remove it. This will solve the evil remove-get-remove-get
> > > problem I describe previously. You will have the option to make this
> > > work by providing a useful hashcode function.
> > >
> > > > -----Original Message-----
> > > > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > > > Sent: Monday, September 12, 2005 4:29 PM
> > > > To: 'JCS Users List'
> > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> config
> > > >
> > > > Aaron,
> > > >
> > > > I did some testing of OSCache, and I was incorrect. OSCache will
> only
> > > > issue
> > > > flushes across the cluster when a remove() is called on the cache,
> > > _not_
> > > > when an object is updated.
> > > >
> > > > I think with the allowPut=false and allowGet=false options, JCS
> would
> > > work
> > > > exactly as OSCache.
> > > >
> > > > I noticed you have commited some code for an upcoming release
> > > candidate
> > > > for
> > > > miscellaneous features. Will you be adding the allowPut config
> > > parameter
> > > > at
> > > > some point after the RC release?
> > > >
> > > > Ian.
> > > >
> > > > -----Original Message-----
> > > > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > > > Sent: Friday, September 09, 2005 6:07 PM
> > > > To: 'JCS Users List'
> > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> config
> > > >
> > > >
> > > > > This model runs into the problem I described earlier. If the
> same
> > > > > object is retrieved over and over on different machines, then it
> > > will
> > > > > be deleted and inserted each time. You'd potentially get a 0 hit
> > > rate
> > > > > if the usage was identical on two nodes!
> > > >
> > > > I might be completely missing your point, but retrieving an object
> > > from
> > > > the
> > > > cache will not cause it to be deleted and inserted each time. Only
> > > when a
> > > > write occurs will the object need to be deleted and inserted.
> Assuming
> > > > this
> > > > is true, and the usage of an application requires, conservatively,
> 20
> > > > reads
> > > > for every write, how would the 0 hit rate occur? Unless what
> you're
> > > > talking
> > > > about is....
> > > >
> > > > > If you described what a flush is in os, then the model of os is
> > > > > extremely flawed.
> > > >
> > > > I've only briefly looked into the OSCache code. It seems that
> > > different
> > > > types of events are triggered: FLUSH, ADDED, UPDATED, and REMOVED.
> In
> > > the
> > > > simple testing we did with OSCache, we didn't notice the problem
> you
> > > > described earlier where when an object is flushed from A, and then
> B
> > > loads
> > > > the object and causes A to flush, and so on. I'm not sure what
> magic
> > > > they've
> > > > put in place to handle that scenario, but it certainly seems to
> work
> > > > correctly.
> > > >
> > > > > I'll get the option in there. It's simple.
> > > >
> > > > Thanks again!
> > > >
> > > > > The replication model is much more efficient. Removes with gets
> is
> > > even
> > > > > better. . . . JCS also allows you to setup nodes that can just
> > > > > broadcast but never receive. . . ..
> > > >
> > > > Based on your input, we'll discuss this option and see if it fits
> in
> > > with
> > > > our app.
> > > >
> > > >
> > > > Thanks,
> > > > Ian.
> > > >
> > > > -----Original Message-----
> > > > From: Smuts, Aaron [mailto:Aaron.Smuts@travelocity.com]
> > > > Sent: Friday, September 09, 2005 5:03 PM
> > > > To: JCS Users List
> > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> config
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > > > > Sent: Friday, September 09, 2005 4:49 PM
> > > > > To: 'JCS Users List'
> > > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> > > config
> > > > >
> > > > > In OSCache, a flush event seems to occur whenever a key is
> removed
> > > or
> > > > put
> > > > > into the cache.
> > > >
> > > > This model runs into the problem I described earlier. If the same
> > > object
> > > > is
> > > > retrieved over and over on different machines, then it will be
> deleted
> > > and
> > > > inserted each time. You'd potentially get a 0 hit rate if the
> usage
> > > was
> > > > identical on two nodes!
> > > >
> > > >
> > > >
> > > > A Jgroups multicast is issued that contains the key that
> > > > > was
> > > > > flushed, and all listeners remove that key from the cache. This
> > > > handles
> > > > > putting a new version of an old object into the cache as well; a
> > > flush
> > > > is
> > > > > sent. I think I understand now that JCS doesn't have the idea of
> > > > > "flushes", but instead issues put, removes, and gets.
> > > > >
> > > >
> > > > If you described what a flush is in os, then the model of os is
> > > > extremely flawed.
> > > >
> > > > > The configuration you proposed should be all we would need.
> Setting
> > > > > allowPut=false and allowGet=false should do the trick (as long
> as a
> > > > remove
> > > > > doesn't try to serialize the object across the lateral :). Our
> > > > abstraction
> > > > > layer would handle peeking into the cache first on a put and
> issuing
> > > a
> > > > > remove first.
> > > > >
> > > >
> > > > I'll get the option in there. It's simple.
> > > >
> > > > The replication model is much more efficient. Removes with gets is
> > > even
> > > > better. . . . JCS also allows you to setup nodes that can just
> > > > broadcast but never receive. . . ..
> > > >
> > > > >
> > > > > Thanks,
> > > > > Ian.
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Smuts, Aaron [mailto:Aaron.Smuts@travelocity.com]
> > > > > Sent: Friday, September 09, 2005 3:15 PM
> > > > > To: JCS Users List
> > > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> > > config
> > > > >
> > > > >
> > > > > Can you explain to me what that means? The os description you
> gave
> > > me
> > > > is
> > > > > extremely vague. What is a flush event? How does it know that
> > > > content is
> > > > > stale?
> > > > >
> > > > > Does that mean when an item is expired and removed, then it is
> > > removed
> > > > > from
> > > > > all? JCS does that.
> > > > >
> > > > > Are they ever sent to all the others? If not then that sucks.
> > > > >
> > > > > Basically you just want to broadcast removes, never try to get,
> and
> > > > never
> > > > > try to send?
> > > > >
> > > > > If you want to only send removes, then I'll have to expose a
> > > parameter
> > > > > called allowPut. You could set allowPut=false and
> allowGet=false,
> > > so
> > > > it
> > > > > could only remove.
> > > > >
> > > > > What about if you put a new version of an item over an old? Is
> that
> > > a
> > > > > flush
> > > > > event? Does that mean it is stale?
> > > > >
> > > > > Then, you will need to check if an item exists before you put it
> in
> > > > the
> > > > > cache, if it does, call remove, then put it. This way you could
> > > just
> > > > send
> > > > > invalidation messages.
> > > > >
> > > > > Basic
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Zabel, Ian [mailto:IZabel@cirqit.com]
> > > > > > Sent: Friday, September 09, 2005 11:29 AM
> > > > > > To: 'JCS Users List'
> > > > > > Cc: Garno, Craig; Arul Muruganandam; Klanke, Ed
> > > > > > Subject: RE: Serializing question about JCS in a Lateral Cache
> > > > config
> > > > > >
> > > > > > Aaron,
> > > > > >
> > > > > > Thanks for putting so much thought into this!
> > > > > >
> > > > > > What we would like to accomplish with our caching
> implementation
> > > is
> > > > > > exactly what OSCache provides (described here:
> > > > > > http://www.opensymphony.com/oscache/wiki/Clustering.html ).
> > > > > >
> > > > > > Here is their description of their clustering:
> > > > > > "Caches across a cluster only broadcast messages when flush
> events
> > > > > occur.
> > > > > > This means that the content of the caches are built up
> > > independently
> > > > > on
> > > > > > each
> > > > > > server, but whenever content becomes stale on one server it
is
> > > made
> > > > > stale
> > > > > > on
> > > > > > them all. This provides a very high performing solution since
> we
> > > > never
> > > > > > have to pass cached objects around the cluster. And since
> there is
> > > > no
> > > > > central
> > > > > > server that is in charge of the cluster, the clustering is
> very
> > > > > robust."
> > > > > >
> > > > > > This is the desired behavior in our application.
> Unfortunately,
> > > > while
> > > > > > OSCache meets our clustering needs, it does not meet our
> > > > configuration
> > > > > and
> > > > > > tuning needs.
> > > > > >
> > > > > > Is there any similar clustering configuration supported in
> JCS?
> > > > > >
> > > > > > Any further insight or suggestion would be much appreciated!
> > > > > >
> > > > > > Thanks,
> > > > > > Ian.
> > > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message