> -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 01, 2002 8:46 AM > To: Turbine Developers List > Subject: RE: a few things -- RE: cvs commit: jakarta-turbine-stratum/src/ > java/org/apache/stratum/jcs/engine/control/group GroupAttrName.java > > > I think non String keys will be ignored. If you want to use string keys > > then you can use this hierarchical / partial removal. It is extremely > > useful. I think I mentioned it in some of the documentation. > > If they are not ignored they can be =] > > > > I have a List that I would like to cache. The objects that are in the > > > list depend on a set of other objects. So I make the set of objects > the > > > key. Not sure how I can use a String to accomplish this easily and I > > > cannot force the positions of colons. I guess I could make sure to > > > remove any colons from any strings that are generated. What is the > > > overhead of groups that makes all this work attractive? > > My understanding of the partial removals is that the colons don't matter > until you actually try to do a partial removal, so as long as you don't > use them colons are not a problem. Aaron? Ya. I was just saying that if you use non-string keys you loose this ability and we need to make sure that using non-string keys doesn't cause any oddities. I don't think it should. Also, the cache prevents you from adding an element if the key ends in the special character. > > > > I was assuming CacheException would be the main/general exception > thrown > > > by jcs. I'm all for moving it to the top level. For that matter I > > > think the interfaces should be top level with implementations pushed > > > further down. > > I agree. I think the interfaces are a little intimidating. Pushing the > key interfaces down where they are useful, and removing them where they > are not, would make JCS much easier to understand. > Most of the key stuff is engine and engine behavior directory. I am concerned with users more than developers. I'd just like to move all of the interfaces that a user will need into one directory. All the classes the user ever needs to use are the cache access, the element attributes and the cache attributes. This should be more than enough. > Aaron, do you have any thoughts on merging the regular and group caches? > Specifically what might the performance implications of such a move be? > The group cache was built entirely on top of the normal cache in order to provide session replication. Most grouping needs, except getting a list of all the elements, can be handled by partial removal. I don't like the group functionality much in its current form. I think it adds too much overhead. I'd like to keep it separate and make it better first. I'd like to work on better group functionality along with a remote locking mechanism. I think the two should be done together. > Thanks, > James > > > -- > To unsubscribe, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]>
