Java Reference
In-Depth Information
into our infrastructure. For common usage patterns, many of these requests
may be unnecessary, because most of the requests are probably for data that
has recently been retrieved.
Table 5.1 Caching has important benefits but requires an understanding of key issues for
successful implementation. To cache Java applications, you must solve some or all of these basic
problems.
Issue
Description
When should we cache?
Decision points are based on the operation cost, volatility
of data store, access patterns of the data store, and size
of data store.
How do we manage updated data?
Incorrect data must be invalidated and updated appropri-
ately.
How do we manage old data?
Sometimes, stale data is acceptable, but often a strategy
is required to flush it over time.
How do we manage concurrent
access to our cache?
Concurrent access can be protected with synchronized
methods, but this may be too restrictive.
Caching solutions for static content are well developed. Caching proxy servers
can dramatically reduce load times near the client. Various nodes on the Inter-
net network already cache. Edge servers, such as firewalls and hardware
caches, are extremely efficient at serving static content, and they can handle
most requests before they even reach our web and application server layers.
Today's web servers also have strong caching extensions built in, but most
caching servers so far have been dedicated to static content. Dynamic content
also shows potential for caching.
5.2
Antipattern: The Cacheless Cow
Figure 5.2 shows the same example, with aggressive caching throughout the
network. In addition to Dr. Conner's original assumptions, I've accounted for
a 70 percent hit rate in our command cache. This number is fairly conservative
for our message board application. Even so, the results are dramatic. Each
layer makes a significant impact on the overall system performance. As we
explained earlier, because several of the requests are for repeated content,
most of the work that many applications do is unnecessary.
After I started my consulting company, I worked with a customer that
served an extremely popular bulletin board. As is typical, hundreds of posts
