Java Reference
In-Depth Information
statistics in a call center application, or a stock ticker that provides statistics from
previous hours/days/months. To summarize the attributes of the data, we could
say that it becomes less relevant as time goes on. It is not a large set of data; it is
accessed with high frequency early on and with less frequency as time goes by. The
data does not change, or in other words it is “static.”
Our JGameStore application does not have this type of requirement, but we
will continue with the shopping cart analogy. Let's say that we need to collect sta-
tistics on the top five products that guests are purchasing every hour. We'll then
use this data on the home page of the cart to tell shoppers what the hot items are
on an hourly basis. Let's also say that we provide a drop-down list that allows users
to choose previous hours to see previous hot-product purchases. Once product
purchases take place, they do not change. If five copies of the newest 3D block-
buster are purchased in the last hour, then that will remain true into the future.
With these simple requirements, let's see how we might use iBATIS caching to
ensure enhanced performance.
Due to the fact that this data becomes less relevant over time and is of an aging
nature, FIFO comes to mind as a prime candidate cache. Our description of the
FIFO cache mentioned that it is an “aging” cache. Any data that is placed into it
will “age out” as the size limits are exceeded. So, as the hours tick away and items
are added to the cache, the product listings that are not the most current will be
accessed less and less. Those items will eventually be discarded as newer product
lists are cached each hour. If we set the FIFO cache size to 24, then our list will
only retain the last 24 hours' worth of items; anything past that will be discarded.
Let's move on and see how the other requirements fit with the FIFO cache.
Since the product purchases will remain the same over time, we can safely
assume they are static. Storing static data in the FIFO cache works well. The static
data will eventually age out and does not require the use of constant flushing to
subvert the aging process. The only time we would need to flush the cache is
when there are updates to products. Since this is not a constant occurrence, we
can simply allow processes to flow as needed and push the items on through the
FIFO cache.
The five products we will be storing each hour should have a small memory
footprint. Since FIFO only discards when the specified size is exceeded, it is unde-
sirable to place large memory-consuming objects into it. The FIFO cache will not
discard items if memory restrictions become strained, which could ultimately
result in an out-of-memory exception. In the case of our product listings, we
should be perfectly safe.
Search WWH ::




Custom Search