Java – Forcing Cache Refresh

cachingdesignjava

I'm updating an existing tomcat web application to read certain resources from a REST API. Currently the application reads them from flat files. Since the application is very critical, I added a caching layer so that the objects returned by REST API are always available.

In the service layer of API client, if the request item is not found in the Cache, the request will be sent to the actual API, the response is put in MapDB cache and returned to caller. The startup listener calls a bunch of APIs with different parameters so that all data is now in MapDB cache. I do not set a expiration on the items in cache because I want them to always available unless I refresh on demand.

The problem is Web App and API client are different projects. Since API client decides to read from Cache or API, I'm not able to force refresh cache value from the application.

Should I add another parameter to function calls I make to API client or

Object obj = ServiceFactory.getLanguageService()
                    .getLanguagesFromApi(env.getName(),
                            env.getEnvironmentType(),
                            env.getPhase().toString(), null, true);

The last "true" parameter indicates forcing cache refresh.

Should I get the existing value in cache to a temporary variable, delete the entry, make API call, if no value is returned because of some error, put the entry back into the cache.

        String key = ClientUtils.concatenateList(
                Arrays.asList(ClientConstants.RESOURCE_LANGUAGE,
                        env.getName(), env.getEnvironmentType(),
                        env.getPhase(), null),
                ClientConstants.CACHE_KEY_SEPERATOR,
                ClientConstants.NULL_STRING);

        Object cachedElement = ClientCache.getCache().get(key);
        if (cachedElement != null) {
            ClientCache.getCache().delete(key);
        }

        Object obj = ServiceFactory.getLanguageService()
                .getLanguagesFromApi(env.getName(),
                        env.getEnvironmentType(),
                        env.getPhase().toString(), null);

        if (obj == null) {
            ClientCache.getCache().put(key, cachedElement);
        }

What is the cleaner way to do this ? I feel adding parameters about caching to function makes it clumsy and add dependencies – like getUsers(String country, boolean forceAPIrequest). But deleting and adding same entries may also waste resources and heap space, causing GC over time. Also, App will directly access Client Cache to do these operations.

All this is based on strong assumption that our REST API is unreliable. Web App should not have any down time.

Best Answer

If I understand correctly, caching is in place mainly for realiability in case of unavailability of REST service, not for performance.

In that case, you could call REST service every time you receive request from the client, if you get a response (REST service is working) you update the MapDB cache and return the response to API client. If REST service is down and you don't get the response, simply return cached value from MapDB.

This way your clients get always as up-to-date possible version as possible while keeping the reliability requirement.

You could include a flag in the response to your clients indicating whether the response is from cache or up-to-date. This might be useful for clients which absolutely require up-to-date response to the point that it is preferable to fail than to work with old data.

Related Solutions

Best Ways to Understand How to Cache Domain Objects in Java

To be useful a cache must provide access to data faster than it can be retrieved from the database. Given that most database calls involve a network roundtrip it makes sense to cache whenever it is known that the output (value) will not change for the same input (key) over a known dimension (time, size, etc).

Thus if the inputs are unpredictable, or undecipherable, so cannot be bound to a single key then caching may not be the best solution - you'll just end up trying to write (and maintain) a poor quality database. Invest the money in a faster network instead.

It doesn't really matter if your cache contains more than one copy of a particular object so long as the key is useful to a downstream consumer. The objective of the cache is to improve performance for different consumers of the data which may approach the underlying dataset from different standpoints (say Customer-centric or Invoice-centric).

In terms of implementation at a small scale, you might want to look at the Cache classes in the Guava library instead of EhCache. A typical example of a self-populating cache would be:

LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder()
       .maximumSize(1000)
       .expireAfterWrite(10, TimeUnit.MINUTES)
       .removalListener(MY_LISTENER)
       .build(
           new CacheLoader<Key, Graph>() {
             public Graph load(Key key) throws AnyException {
               return createExpensiveGraph(key);
             }
           });

As you can see it is very straightforward to work with and Guava provides a wide variety of cache eviction strategies (size, reference, age etc). The Guava library also provides a wealth of useful utility classes that augment those found in the JDK so your overall codebase will benefit.

Thus your approach of decorating your DAO methods with a class that combines a dedicated cache and the DAO resultset with a derived key is sound. Each call to the method causes an initial local key lookup before returning which is what you appear to be looking for. Couple this with an appropriate eviction strategy tuned for each method and you have a simple to understand and maintain solution that should scale well.

Shared Cache – Invalidation Best Practice

Is unanswerable, except to say it depends. There are a lot of factors which will determine which approach is going to be the best in your case, e.g.: Is it normal for created objects to be retrieved shortly after they are created? What's the ratio of updates to accesses?
Re. deciding you need a cache: If you're optimising without data then yes, it's technically premature optimisation. I say technically since experience/conventional wisdom may tell you you're going to need a cache of some sort. Re. deciding how the cache will best work: yes, it's definitely premature optimisation.
- Optimisation often isn't about finding the best/most optimal solution. It should go as follows:
  1. Find the bottlenecks in the system.
  2. Find where you can make the biggest difference with the least amount of work.
  3. Do the least amount of work!
  4. Is it fast enough yet? If not, go to #1.
  5. Done!
- Honestly, neither of the approaches you describe sound complicated. Why not implement both and see which works best?
- Step 3 in approach #2 could be changed to "Object A gets updated -> store in database, update entry in cache".

Best Answer

Related Solutions

Best Ways to Understand How to Cache Domain Objects in Java

Shared Cache – Invalidation Best Practice

Related Topic