We then check to see if we're adding a top-level post or a reply to an existing
thread. If it is a top-level thread, we need to invalidate the cache for board-
Cache . If it's a reply to a thread, we have to invalidate the cache for the thread.
In either case, we won't write the new value to the cache until it's fetched
again. The slight performance penalty is more than compensated for by the
improvement in readability.
The usage of these commands is identical; only the name of the command
is different. Here, we show the revised controller statements in our new con-
troller, FastShowBoardController :
String board=request.getParameter ("board");
BoardCacheCommand postList = new BoardCacheCommand();
The changes in FastShowThreadController are identical.
Possible enhancements to cached commands
In “Scaling Up E -business Applications with Caching,” the authors define a
dynamic cache manager. This section describes some natural extensions to our
cache example. The following list represents the enhancements that we'd
likely want to make for a robust cache manager:
Refactor. First, the generic command methods should be promoted to
an interface. This would give us flexibility in initializing and executing
Extend our commands to have a generic key attribute.
Add a time stamp and timeout to our commands, to allow us to period-
ically expire old cache items.
Record the key values for any command dependencies that we might
have (to use in invalidation schemes).
Generalize the cache management functions in BoardCacheCommand and
ThreadCacheCommand to a general CommandCache class. This class would
handle caching of systemwide commands and invalidation.
Establish various levels of validation and the protocols that application
developers might use to support them. Some elements would be fully
automatic, such as a timeout mechanism. Some would be more
advanced—an automatic notification scheme, for example. Some would
be simple but tedious and bug prone, such as the manual invalidation
scheme we used in this example.