In listing 9.9, the query mapped statement getChildCategories takes advan-
tage of categoryCache via the cacheModel attribute, which identifies category-
Cache as its associated cache. As users peruse the categories of the shopping cart
application, the getChildCategories query mapped statement is called. This
causes any child results to be cached. As the cache reaches its size of 50, it begins
to remove any aged results from the cache. This causes constantly accessed lists of
child categories to remain in the cache longer and provides better performance
for the users. If an administrator performs an insert, update, or delete on the cat-
egories, a flush is triggered and the buildup of the cached results begins all over.
This combination of flushing and culling keeps the child categories fresh and up
to date while reducing the constant burden of unnecessary database hits.
Query mapped statement that uses the categoryCache
<select id="getChildCategories" parameterClass="Category"
<dynamic prepend="WHERE ">
parentCategoryId IS NULL
ORDER BY sequence, title
The removing process of the LRU cache can be fine-tuned by adjusting the size
property up or down to allow for more or fewer categories to be cached. Remember
that the goal of the LRU is to cache only items that are accessed constantly. Don't
set the size too high. If you do, you effectively make your LRU cache into a STRONG
memory cache—which would defeat the whole purpose of the LRU cache.
Now that we've discussed an effective means of caching long-term, read-only
data, let's consider another situation that you will often face when asking the “to
cache or not to cache” question: caching read-write data.
Caching read-write data
Suppose you want to cache objects that are of a changing nature. You must do this
with caution; if you have a high-transaction environment, you may find that your