Java Reference
In-Depth Information
Table 5.2 If data can be partitioned into cacheable units, values are reasonably stable, and
detecting change and age is practical, then caching is a viable enhancement.
Requirement
Description
Data must have cacheable units.
The application must have a partitioning that lends
itself well to caching. A partition of elements that
are close to the same size and practical to store are
keys for effective caching.
Values must be stable.
If a value does not stay stable long enough to be
read more than once for the expected case, a cache
is not practical. For example, a stock value may not
be considered stable for a pool of 10 users who use
a ticker occasionally, but it might be stable enough
for thousands of interested traders on a single
server.
Detecting change and age must be
practical.
We need a convenient way to handle critical data
changes that must be detectable, or some reason-
able definition of what constitutes stale data.
Our example has cacheable units. Our database is small and the distribution
far from uniform, because the most interesting posts will be viewed most fre-
quently. It's likely that our entire database will fit in memory. Our invalidation
is also simple; so far, we write posts to the database in only one place. For us, a
cache makes sense.
5.3.3
Adding a cache to our BBS
In this example, we'll add a cache object for the
ShowBoardCommand
and
ShowThreadCommand
classes. We'll call them
BoardCacheCommand
and
Thread-
CacheCommand
, respectively. The techniques for each are identical, so we'll
show only the
BoardCacheCommand
in listing 5.2.
Listing 5.2
The BBS example with an added cache
package bbs;
import java.io.*;
B
Imports
import java.util.*;
import bbs.AddPostValidationException;
import bbs.ShowBoardCommand;
public class BoardCacheCommand {
protected String board = null;
C
Cache key field
