jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smuts, Aaron" <Aaron.Sm...@travelocity.com>
Subject RE: Serializing question about JCS in a Lateral Cache config
Date Fri, 09 Sep 2005 21:03:08 GMT


> -----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


Mime
View raw message