Java Reference
In-Depth Information
High-frequency access and low-frequency access are part of the game when it
comes to caching. It doesn't matter which you experience as long as there is a true
benefit from the fact that it is or may be accessed more than once. Fine-tuning the
size is the only thing we need to be concerned with. Depending on the number of
people who are accessing the current popular purchases or past popular pur-
chases, we can set our cache size to accommodate.
Now that we have looked at the list of requirements and how the FIFO cache
fits with them, let's move on to configuring the cache model. Our cache model is
quite simple. As shown in listing 9.12, we want to display correct product informa-
tion for purchased products. This requires that we first set up the appropriate
<flushOnExcecute> tags to flush hotProductsCache when product data changes.
We only need to specify Product.update or Product.delete to flush the cache. We
do not include insert here because we don't care about products that don't exist.
If a product is added and then becomes a popular purchase, we will have no prob-
lem adding it to hotProductCache . It is only when the product is updated or
deleted that we need to worry at all about a flush. We would not want to display a
cached product that is no longer for sale (i.e., deleted). We would also not want to
display an old pricing on a product that has had a pricing update.
Listing 9.12
Cache model and mapped statement for hotProductsCache
<cacheModel id="hotProductCache" type="FIFO">
<flushOnExecute statement="Product.update"/>
<flushOnExecute statement="Product.delete"/>
<property name="size" value="12"/>
</cacheModel>
<select
id="getPopularProductsByPurchaseDate"
parameterClass="Product"
resultClass="Product" cacheModel="hotProductsCache">
SELECT count(productId) countNum, productId
FROM productPurchase
WHERE
purchaseDate
BETWEEN
#startDate#
AND
#endDate#
GROUP BY productId
ORDER BY countNum DESC
LIMIT 5
</select>
Search WWH ::




Custom Search