Java Reference
In-Depth Information
total of your application's overall caching. If you are exploring an overall caching
strategy, there is a lot to consider and the discussion reaches beyond the scope of
this topic. However, it is important to determine what part
iBATIS
caching can play
in your overall caching strategy.
When caching data on the data access layer, you will be working with either a
dedicated or a shared database. With a dedicated database, all access to that data-
base will take place through the application you are developing. With a shared
database, multiple applications will access the database and be capable of making
alterations to the data.
If your application connects to a database that has a variety of other applications
accessing it and altering its data, you will likely want to avoid caching much of it.
Using
<flushOnExecute>
will not be an effective strategy if the underlying data has
long since expired because another application has made changes to your data-
base. You can still take advantage of caching the more static read-only data that will
not impact your read/write data. Examples include time-based report data that
does not change, shopping cart page data, or static drop-down list data.
On the other hand, if you are caching for a database that is accessed only
through a single application, you can be much more aggressive about your use of
iBATIS
caching. In a dedicated application,
<flushOnExecute>
becomes much
more valuable. You know that the execution of certain mapped statements will
force cached data to be invalid and therefore can affect your flush strategies.
Suppose you want more granular control over when certain items are released
from the cache, or you want a clustered cache.
IBATIS
by itself provides no means
of caching in this manner, but it can be combined with the
OSCACHE
cache type
(section 9.5.4) to provide this type of robust functionality. However, the same
rules apply here as stated earlier. You can be much more aggressive about your
use of caching when you know that access to your database is limited to one
application. But exercise caution when your application is not the dedicated
access to the database.
In the next few sections, we look at some case studies of cache use, as well as
some code snippets that illustrate how to get started implementing them.
9.6.1
Caching read-only, long-term data
Often read-only, long-term data is what we cache. It is easy to cache because it
doesn't change often. We can place such data into the cache and forget about it
until an interval expires for flushing or a mapped statement is executed that trig-
gers a flush. Let's revisit our shopping cart application and step through setting
up a read-only cache.
