Re: [JCS] Performance of invalidating a group in LRUMemoryCache

[Thomas Vandahl]

On 20.06.12 23:51, Joseph A Calzaretta wrote:
 Are we doing something wrong?  Is the behavior we're seeing intended or is it 
 a bug?  If it is by design, should it perhaps be documented somewhere that 
 the performance of invalidateGroup is O(n) and not O(1)?

Obviously, the feature was not implemented with your use-case in mind.
Right now, JCS is just a map on steroids with some group support. You
are, however, free to put maps of objects into your cache to implement
what you want. Even better, submit a proposal for a patch to get this
resolved via JIRA and we try to put it in (we prefer unified patches).

Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[JCS] Performance of invalidating a group in LRUMemoryCache

[Joseph A Calzaretta]

Hello,

I couldn't find anything in the archives about this topic; please let us know 
if our questions have been answered elsewhere.

We are using JCS 1.3 and have run into a problem with the performance of 
JCS.invalidateGroup(String) when using an LRUMemoryCache.  When there are 
millions of objects in a region, the time to invalidate a group in the region 
is prohibitively long (on the order of a second per invalidation).   Looking 
into the code we found that the following block of 
LRUMemoryCache.remove(GroupId) is being called:

//---
for ( Iterator itr = map.entrySet().iterator(); itr.hasNext(); )
{
Map.Entry entry = (Map.Entry) itr.next();
Object k = entry.getKey();
if ( k instanceof GroupAttrName  ( (GroupAttrName) k ).groupId.equals( 
key ) )
{
itr.remove();
list.remove( (MemoryElementDescriptor) entry.getValue() );
removed = true;
}
}
//-

This looks for all the world like the LRUMemoryCache is doing a linear search 
of the entire region and individually discarding elements if they are found to 
be members of the group.  We would have thought that a group would be 
represented as a subcache ( something like MapString, MapString, 
Serializable groupCache ) and that invalidating a group would be a 
constant-time operation (something like groupCache.remove(groupName)).

For now we have given up on using groups because without fast invalidation 
there doesn't seem to be an advantage to using groups over just using a 
combined key we make ourselves.

Are we doing something wrong?  Is the behavior we're seeing intended or is it a 
bug?  If it is by design, should it perhaps be documented somewhere that the 
performance of invalidateGroup is O(n) and not O(1)?

Thanks in advance for your advice.

Yours,

Joe