Java Reference
In-Depth Information
on a relational database. We have no need for the robust transactional sup-
port, either. It's much better to build a light implementation with a more
basic technology.
8.4.4
Mini-antipattern: Entities for Read Only
A more specialized case of the Entity Beans for Lightweight Functions anti-
pattern is the large list that is read but not written. In some cases, we have sta-
ble data that will seldom (or never) change. In these cases, a full entity bean is
overkill. Some examples of objects that are read but not written are lists of
states in a nation, cities in states, tax tables, and
ZIP
codes. In these cases, we
can use a session bean like the one in the previous section as a lightweight
wrapper around a database table. Or we may decide to load such data into a
shared hash table once in a client-side cache.
8.4.5
Mini-antipattern: Entity Beans for Write but Not Read
Believe it or not, occasionally we might need to record data that will probably
never be read. That concept seems strange to me, but there are examples of
data that should be recorded, where the
expected case
is that the data will never
be accessed. Transaction logs, audit files, and system logs are good examples
of this type of data.
Clearly, the use of entity beans is overkill for these situations; a more prim-
itive construct than a database is called for. We should optimize the expected
case: writing the data. We may opt for file services, since the data organization
doesn't need to be optimized for frequent random access.
8.4.6
Troublesome scrollable lists
Scrollable lists present interesting challenges to
EJB
developers. Instead of
returning an entire list, many web pages display some subset of the result and
allow users to navigate the entire list with links. The problem is that the list
can change while the user navigates the list. If we do a full database query
every time to populate the list, performance can suffer. For this reason, man-
agement of such a request can be difficult.
The stateful session bean is ideal for this type of problem. When model-
related conversation state (the list contents) is required only for the duration
of a session, a stateful session is a better candidate. This bean can serve as a
facade, and the list data and user's current location in the list can be stored in
the bean. Implementations vary, and some implementations may prove prob-
lematic in solutions deploying application server clusters. Capabilities in this
area are changing rapidly, so check with your vendor to be sure.
