Java Reference
In-Depth Information
Here, items like the identity of the customer and the list of items in the
cart must be preserved between method invocations. Obviously, it is possible
to present such an interface through a stateless bean by creating some sort of a
session identifier token and passing that in to every method, thus allowing the
stateless session bean to save this data to a database and then load it back, but
the primary advantage of a stateful session bean is that this work is done for
you through the setting of the bean's context .
So, the primary advantage of stateful session beans is that the server side
can keep track of client data for you. The primary disadvantage is that the
container will try its best to keep an instance of the Bean around for every
client, so it must sometimes swap an idle instance out to make room for an ac-
tive instance, which is an expensive operation. But—and this is important to
keep in mind—it is much less expensive than reading and writing this data on
every call to a stateless bean! You have to understand what is happening under
the hood if you want to produce an optimal design. If you need state between
method calls, a stateful bean is likely to be the most effective way to go.
21.2.2.2
Entity Beans
What they are. An entity bean is often described as an object that represents
a row in a database table. This is the most typical case, but it isn't always so.
We have worked on a J2EE application where the entity bean represented an
XML document in the filesystem.
The general idea is that enterprise applications tend to work on lists of
similar things: customers, employees, locations, accounts, servers, inventory
items, and so on. An entity bean is an object that represents a single item in
such a list. In other words, it is an interface to a data item. And, yes, in practice
there is one entity bean class for a table and one instance of the class for
each row.
Obviously, a J2EE container doesn't maintain an in-memory instance for
every row of every table. In fact, you can think of both entity beans and session
beans as ways to automate keeping the optimal balance between in-memory
instances for speed and data storage for memory utilization.
Entity beans can be written to manage the persistent storage itself, using
code added to the bean implementation by the bean author (this is known as
bean-managed persistence , or BMP), or they may be written to allow the
container to automatically manage the data in the underlying database for you
(this is known as container-managed persistence , or CMP). Which you use may
Search WWH ::




Custom Search