Java Reference
In-Depth Information
cache is overburdened and effectively useless. The reason for this is that an
attempt to keep high-transaction data cached would require that you flush the
cache often. Flushing the cache too often could create a twofold burden. First,
your application would constantly be in a state of checking the cache, clearing the
cache, and repopulating the cache on every request to the database. Conse-
quently, if the cache is constantly being cleared, this means that the database is
also being hit to retrieve fresh results. You'll come to a point where it is simply bet-
ter for performance if you use database techniques such as indexing and table
pinning and avoid application-based caching.
Even though you need to be careful when caching data that may change, it
also makes sense to do so when the data is of a less volatile state. In the
JGameStore application, we find a good example of this with caching products.
With many storefronts, there is a need for administrators to enter new products,
update existing ones, mark others as sale items, and similar tasks. These kinds of
activities will produce a mild level of volatility. Since this is not a high-transaction
environment, caching can play a role in improving overall application perfor-
mance. As long as the cache has time to build up and provide users with improved
performance over a span of time, you will avoid the sinkhole described previously.
When examining the nature of the data that you want to cache, consider sev-
eral factors:
The number of products will likely be significant.
■
The products data is of a changing nature.
■
The products that are most often accessed will change throughout the day
depending on consumer habits.
■
In our example, we decide to use the
WEAK
memory cache because it is a less
restrictive means of caching. Unlike
LRU
, which requires a certain level of predict-
ability for determining the number of results that should be cached, the
WEAK
memory cache allows us to decide which items to retain and discard before a pre-
determined artificial limit is met. Since the cache uses the
java.lang.ref.Refer-
ence
implementations to store data in the cache, it can remove or retain results
based on internal analytics. When using the
WEAK
reference type with the
MEMORY
cache, the results are wrapped with a
WeakReference
(
java.lang.ref.WeakRefer-
ence
) and stored in the cache. Then, the garbage collector is able to handle the
wrapped results at its discretion.
Now let's move on to configuring the
<cacheModel>
tag. As expected, the
cacheModel
type attribute is specified as
MEMORY
. Note that we are setting the
