Java Reference
In-Depth Information
tags.
<flushOnExecute>
specifies that stored results will be flushed when a particu-
lar cache is accessed. It's important to note that all of the cache contents are
cleared. This means that if you have several mapped statements that use the same
cache model, then all of the results of those mapped statements will be flushed.
The final tag to notice is named
<property>
. Each type of cache model has prop-
erties that can be specified for custom configuration of the cache model. The
name
attribute is the name of the property that will be set. The
value
, of course,
provides the assigned value to the defined property.
As you can see, the
iBATIS
cache is quite simple. The most work you will expe-
rience is discovering the properties that are available for each of the cache model
types. We will take time in this chapter to explain what cache models are available
and provide some direction on when and how to use them after we take a quick
look at the
iBATIS
caching philosophy.
9.2
i
BATIS's caching philosophy
Most caching that developers incorporate into their apps is for long-term, seem-
ingly unchanging data. This is the type of data you usually see in drop-down or
selection lists. Data like states, cities, and countries are prime candidates for this
type of caching. But caching can reach beyond long-term read-only data and can
be used to cache objects that are read/write as well.
The difficulties at this point often have to do with the manual process of check-
ing to see whether the data exists in the cache and then storing it into the cache
yourself. Another difficulty with a cache is figuring out how to know whether the
data contained within is either stale or fresh. It's easy enough to write simple rules
like timed cache flushes, but it is not so easy when the execution of several proc-
esses should invalidate a cache's contents. Once dependencies between executing
code become important to maintaining the integrity of your cached objects,
things begin to get difficult. Often when caching reaches this point of complexity,
the
performance-to-effort
ratio can become less than convincing or at minimum be
seen as a very annoying task. This is why
iBATIS
has focused itself on providing
caching implementations and strategies for the data access layer only. This focus
on the data access layer enables the framework to manage the cache in accor-
dance with an easy-to-manage configuration.
Consider the philosophy of the
iBATIS
caching framework and how it differs
from other persistence solutions. This can often be a sore point for some who are
used to how traditional
O/RM
solutions perform caching.
IBATIS
is built on the
idea of mapping
SQL
to objects, not mapping
database tables
to objects. This is an
