> -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
