Bitter beans - Bitter Java - page 243

8.6 EJBs and caching

Programmers often use a design pattern called the ValueObject, which works
like a small spot-cache to reduce round-tripping. Programming ValueObjects
can be tedious and they must be coded for every instance, so a programmer
may neglect them when working under a tight schedule. I prefer to spend
more time on a general-purpose or a prepackaged cache.
When EJB application servers are deployed on major system boundaries,
they too are targets for caching. This problem is unique to the EJB client
machine. Because the model can keep data resident between calls, the cache
between the EJB model and database is usually not necessary at the EJB server.
Further, since many EISs have aggressive caching built in, a cache upstream of
the EJB is generally not necessary. Nevertheless, we could benefit from a cache
in certain circumstances:
Models that don't use entity beans or stateful session beans are possible
targets for a client-side and server-side cache, depending on the factors
outlined in chapter 5, in the section “Solution 2: Cache commands.”
If the controller and JSP are deployed on separate hardware, the interface
between the controller and the facade is an appropriate place for a cache.
See the next section, “Implementing a cache with a facade,” for details.
For some EISs, such as transaction monitors, a cache can provide per-
formance boosts upstream of the EJB server.

8.6.1 Implementing a cache with a facade

In this chapter, we have not yet considered a cache between the EJB server and
the web application server. If we decide to deploy both the EJB server and the
web application server on the same box, we won't need a cache. With other
deployments, a cache will almost certainly provide some performance benefits
by reducing the communication between the EJB client and server boxes.
Let's look at three caching alternatives.

Command pattern within a session bean
One solution is to implement the Command design pattern with a session
bean. This interface would be easy to cache for the same reasons as our origi-
nal command: a series of set methods for input parameters, an initialize
method to establish connections and do validations, an execute method to
access the model, and a series of get methods to obtain the results of the com-
mand. We'd have a built-in key in a concatenation of the set parameters of the