2 stage group conversion:
1. Use the element attributes to store the group
name.
--- Aaron Smuts <asmuts@xxxxxxxxx> 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:
> turbine-jcs-dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail:
> turbine-jcs-dev-help@xxxxxxxxxxxxxxxxxx
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
|
| 
