2 stage group conversion: 1. Use the element attributes to store the group name.
--- Aaron Smuts <[EMAIL PROTECTED]> wrote: > The JCS hierarchical remove is more powerful than > groups. JCS grouping needs an overhaul. > > The old JCS grouping was designed for fast removal > and > gets, faster than hierarchical removal. We stored > the > keys for groups in a hashtable in the systemgroupid > region. This allowed for quick lookups of group > keys > and fast removal. To get the keys for a group, the > map for the group ids was retrieved and all the > values > were spit out. This didn't require locking the > entire > map for a region to retrieve group keys. > > There were some synchronization problems in the old > group implementation, so it was changed. Currently, > the systemgroupid region is not used. Groups are > referenced by a special key. When you want a list > of > the keys in a group, the cache iterates through all > the keys in a region. The current implementation > does > not allow grouped items to be retrieved by their key > alone. As a result, groups function as mini regions > with slow removal times. It would be better to use > another region than the current groups. > Alternatively, the hierarchical removal can do most > of > what you need. > > Ideally, none of the auxiliaries needs to know about > groups. The CompositeCache should be able to manage > it all. > > > The group functionality needs to be changed. > > Items in a group within a region should be able to > be > referenced by the key alone. We can make this > happen > by putting an object, CacheKey, in the CacheElement > and have it equal an object with a similar key in a > GroupAttrName, but this adds some complexity. > > One alternative is to completely remove groups until > we work out a way to bring back the group key map. > > Another option, if we only want to support single > groups, is to add a groupname or a list of group > names > to the ElementAttributes. We could continue to > iterate through the map for group reference. We > could > allow for multiple groups this way, but it would > have > the same slowness problems. It would allow grouped > items to be retrieved by their common keys. All in > all, I think this is the best alternative for now. > > Let's scrap the GroupAttrName and just put the group > information in the ElementAttributes until, or if, > we > decide to use the group key maps again. This does > still require the auxiliaries to be able to handle > getGroupKeys requests. > > > Aaron > > > > __________________________________ > Do you Yahoo!? > Vote for the stars of Yahoo!'s next ad campaign! > http://advision.webevents.yahoo.com/yahoo/votelifeengine/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
