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 <[EMAIL PROTECTED]> 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:[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] > > > > > > >
