commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph A Calzaretta <jc...@MIT.EDU>
Subject [JCS] Performance of invalidating a group in LRUMemoryCache
Date Wed, 20 Jun 2012 21:51:48 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message