LRUCache

About this page

This page exists as a place to document and discuss LRUCache. This page is not a substitute for JavaDoc. Some documentation is appropriate in the source code itself as source comments, as JavaDoc, as package level JavaDoc. This page can be used for collaborating on preparing that kind of documentation, but the real value of this page is in doing a different kind of documentation: the discussion, commenting, and contribution collection that Wikis are good at.

About LRUCache

Some concerns

This email noted some concerns about LRUCache which are reproduced here.

Regarding using LRUCache in a case where we want to guarantee expiry of stale cache entries:

LRUCache may be more than adequate.

However, reading the code, LRUCache may not provide the guarantees we want
here.

LRUCache only removes entries in response to being over-full. In the case
where its maxSize has not been exceeded, it will continue to cache entries
forever.

public void sweepCache() {
    ...
    while ( size() > maxSize )
    {

LRUCache will return entries in respose to get() even if they have not
been touched for longer than the set expiration period.

public synchronized Object get (Object key) {
    ValueWrapper valueWrapper = (ValueWrapper)super.get(key);
    if (valueWrapper != null) {
        // Update timestamp
        valueWrapper.resetLastReferenceTime();
        return valueWrapper.getValue();
    }
    else
      return  null;
  }

Touching entries resets their timestamp, reducing the likelihood that they
will be removed.

So I'm concerned that LRUCache may not be the cache for the job here. It
is possible under LRUCache that a particular user's cached
RestrictedPerson could be cached forever. This could happen because it is
frequently touched or because the cache is swept relatively frequently and
grows relatively slowly such that
cache entries with keys that are returned late in the iterator over the
keyset never need to be purged to get under the size limit.

A particular entry not being purged for a long time would have the result
of the uPortalnot becoming aware of changes to dynamic attributes for the
affected user.

The LRUCache would eliminate this cache as a potential memory leak,
however, by imposing a cap on its size.

Note: these concerns don't necessarily mean LRUCache isn't appropriate to other uses, it just means that it's likely not the right cache for cases where expiry needs to be gauranteed.