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 Map<String, Map<String,
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
