Java Reference
In-Depth Information
cause they do not store any state, their performance overhead is quite low. A com-
mon usage scenario for an SLSB would be a stateless service responsible for re-
trieving objects from a database.
•
Stateful session beans
(
SFSB
): SFSB supports conversational services with
tightly coupled clients. A stateful session bean accomplishes a task for a particu-
lar client and it cannot be shared between multiple callers. It maintains the state
for the duration of a client session. After session completion, the state is not re-
tained. The container may decide to passivate (serialize and store for future us-
age) a stale SFSB. This is done to save resources of the application server or in
some cases, to support SFSB failover mechanism in a domain of application serv-
ers (this is the case in JBoss AS 7 and WildFly). Starting from EJB 3.2, it is pos-
sible to disable passivation for a specific SFSB, although it may affect the server's
stability and failover capability. A shopping cart could serve as a simple use case
for an SFSB.
•
Singleton EJB
: This is essentially similar to a stateless session bean; however, it
uses a single instance to serve client requests. So, you can guarantee the use of the
same instance across invocations. Singletons can use a richer life cycle for a set of
events, along with the possibility to control when a bean is initialized. Also, a
more strict locking policy to control concurrent access to the instance can be en-
forced, so that the shared state of the singleton bean can be used by multiple cli-
ents. If the application is distributed on multiple nodes of a domain, then every
running JVM will have its own instance of the singleton bean. We will discuss
this a little further in
Chapter 11
,
Clustering WildFly Applications
. Because of
their special characteristics, singletons can be used to save the state of the applic-
ation, cache, or initialize some resources during the application's startup.
As we mentioned earlier, the container manages the instances of the beans, but the clients
should call them through business interfaces. There are three types of a session bean's
views available:
•
Local business interface
: This session bean is used when the bean and its client
are in the same container. It uses the pass-by-reference semantic, so the return
values and method parameters are based on references and not copies of the ob-
jects.
•
Remote business interface
: In this session bean, the locations of the client and
the bean are independent (the client may reside in another container or without a
container at all, for example, as a standalone application). Every parameter and
return value is serialized and copied.
