You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-dev@jakarta.apache.org by Aaron Smuts <as...@yahoo.com> on 2004/07/19 21:19:53 UTC
groups
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@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: groups
Posted by Aaron Smuts <as...@yahoo.com>.
2 stage group conversion:
1. Use the element attributes to store the group
name.
--- Aaron Smuts <as...@yahoo.com> 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@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
__________________________________
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@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: groups
Posted by Aaron Smuts <as...@yahoo.com>.
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 <as...@yahoo.com> 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@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
__________________________________
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@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org