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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > > > 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:[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] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
