Java Reference
In-Depth Information
3.2. Stateless session beans
As we noted, a stateless session bean doesn't maintain any conversational state, and service
tasks must be completed in a single method call. This certainly doesn't limit a stateless ses-
sion bean to containing only one method. On the contrary, stateless session beans usually
group together several closely related business service API methods. Of the session bean
types, stateless session beans have the best performance characteristics.
In this section you'll learn more about developing stateless session beans. You'll imple-
ment some key pieces of the ActionBazaar application using stateless session beans. This
will help reinforce key features of session beans and provide you with some practical code
to use. You'll learn how to use the
@Stateless
annotation and the various types of busi-
ness interfaces and lifecycle callbacks supposed by stateless session beans.
3.2.1. When to use stateless session beans
The obvious case for stateless session beans is stateless business API services. There are a
few other scenarios where stateless session beans might make sense. Generally, you don't
need the DAO/repository layer to be an EJB. But in some cases you might want to take ad-
vantage of pooling, security, or transactions at the DAO layer. As we'll discuss in the next
section, pooling can be an important scalability technique applied not just at the service tier
but also at the DAO tier for greater resilience. For many applications developed using rapid
application development (RAD), there isn't an immediate need for the service tier because
the UI layer accesses data repositories directly. In this case, DAO/repository objects can be
stateless session beans so that they're thread-safe and transactional. As we also mentioned
earlier, you can directly use stateless session beans as JSF-backing beans with CDI.
Like other EJBs, stateless session beans should be used sparingly. For example, it doesn't
make much sense to use stateless session beans for utilities. You should also avoid stateless
session beans if your API requires any state maintenance. In theory, it's possible to roughly
simulate singletons by using static fields in stateless session beans. The problems with
this are two-fold. First, although individual stateless session bean instances are thread-safe,
static fields wouldn't be safe because stateless beans can be used by multiple concurrent
clients at once. In contrast, there's only one singleton bean instance and it's accessed in a
thread-safe manner by all concurrent clients. The second problem occurs when a cluster is
introduced. In a cluster, stateless session beans on different clustered machines would have
different static field values.
