2 stage group conversion:
1. Use the element attributes to store the group
name.
Convert all getgroup funtions to look in the
element attributes.
2. If needed implement a group id map for lookups.
Do all the work in composite cache. Store the groupid
map in the same region as the elements. Give it some
special property so it will not fall off the lru or
write the code such that if it falls off, we can
revert to the iteration through the kesy method and
rebuild the map. This may be best.
Aaron
--- 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]
