statement several times in the same session, then you would get the benefit of the
caching. However, each time a session calls a cached query mapped statement for
the first time, the database will be hit.
The final combination of these attributes is readOnly=true and serial-
ize=true . This combination is functionally identical to setting readOnly as false
and serialize as true. The problem here is the semantic that it expresses. It does
not make any sense to create a readOnly result that you would want to serialize.
The intention of serialize is that you expect or plan for the objects contained in
the cache to be serialized. So, to serialize a read-only cache is quite absurd.
Now that you have a philosophical understanding of the cache, let's dig into
setting it up and using it.
9.4 Using tags inside the cache model
Before we examine the different types of cache model implementations that are
available, you should become familiar with the common tags that are used within
the body of the <cacheModel> tag. These tags are used to define common behav-
iors for flushing caches as well as specifying property values relevant only to the
particular cache model implementation.
Each cache implementation shares a common set of tags for flushing their con-
tents. When thinking through your caching, determine how and when you want
objects to be removed from the cache. By default, each cache model type has a
means of managing the cached data on a granular level. They can remove individ-
ual objects based on memory, recent access, or age. Beyond each cache model's
inherent behavior you can further give them instruction on when to the flush their
entire contents. The flush tags are made available to provide such functionality.
There are two flush tags, as shown in table 9.4.
Flush tags, which define rules for clearing items from the cache
Defines query mapped statements whose execu-
tion should flush the associated cache
Defines a recurring timed flush of the cache
Let's look at each of these flush tags in more depth.