Bitter cache management - Bitter Java - page 127

new one as before, following the set, initialize, and execute protocol to pre-
pare the command for use by the controller and JSP layers.
In general, in order for a cache strategy to be useful, our application should
have several properties:
Our solution should have a logical partitioning of cacheable units.
Examples are URL s, documents, policies, customers, and pages. The
command gives us an ideal partitioning of cacheable units.
The units should have a value that's stable enough to make the cache
worthwhile. We want to have a relatively high probability of finding
data in the cache. Several factors come into play, including:
The volatility of the data. Higher volatility means that we are less
likely to use the data before it changes. In such cases, we'll need a
very high access frequency to make the cache worthwhile, but these
cases do exist (for example, a popular stock price).
The size of the database. If a database is very large, it may be difficult
to cache enough data to have repeat requests, unless the requests are
not uniformly distributed.
The distribution of data requests. If a database is too large, a uniform
distribution will inhibit caching.
The size of the cache. If we can cache more data, we have a higher like-
lihood of a hit for any individual request.
The frequency of access. If the data volatility is high and the frequency
is low, a cache strategy may not be appropriate. If the database is very
large, the resources for the cache are constrained, and the distribu-
tion of requests is spread uniformly across the data, then the cache
would probably not provide meaningful benefit. In most cases,
though, a cache can add exceptional value.
There should be a convenient way to handle cache data that has changed
(referred to as stale cache data ). One solution is to simply expire cache data
after a certain period of time. We may instead explicitly invalidate cached data
through the commands that change the data. Alternatively, we may use a pub-
lish / subscribe pattern to automatically notify the cache when a change occurs.
Table 5.2 shows three requirements for caching to make sense.