Java Reference
In-Depth Information
} catch (Exception e) {
log.log(Level.SEVERE, "Could not acquire message", e);
throw new MotdException(
"Failed to retrieve message from the database.", e);
} finally {
if (p != null) {
try {
p.close();
} catch (SQLException e) {
log.log(Level.WARNING,
"Could not close ostensibly open statement.", e);
}
}
if (c != null) {
try {
c.close();
} catch (SQLException e) {
log.log(Level.WARNING,
"Could not close ostensibly open connection.", e);
}
}
}
}
Some of this can be trimmed down; there are various techniques that allow you to reduce
the boilerplate code for opening connections and logging problems, but the basic logic that
pulls the object instance from the
ResultSet
becomes more complex as the object itself does.
Once the object includes references to other objects—or worse yet, other collections of
objects—these “manual” techniques start to look more and more flawed.
EJBs As a Persistence Solution
So why not just use EJBs to retrieve data? Entity beans are, after all, designed to represent,
store, and retrieve data in the database.
Strictly speaking, an entity bean is permitted two types of persistence in an EJB server:
bean-managed persistence (BMP) and container-managed persistence (CMP). In BMP, the
bean itself is responsible for carrying out all of the SQL associated with storing and retrieving
its data—in other words, it requires the author to create the appropriate JDBC logic, complete
with all the boilerplate from Listing 1-3. CMP, on the other hand, requires the container to
carry out the work of storing and retrieving the bean data. So why doesn't that solve the prob-
lem? Here are just a few of the reasons:
•
CMP entity beans require a one-to-one mapping to database tables.
•
They do not directly support inheritance relationships.
•
They are (by reputation, at least) slow.
Search WWH ::
Custom Search