What is a Session bean
A session bean is the
enterprise bean that directly interact with the user and contains the business
logic of the enterprise application. A session bean represents a single client
accessing the enterprise application deployed on the server by invoking its
method. An application may contain multiple sessions depending upon the number of
users accessing to the application. A session bean makes an interactive session only
for a single client and shields that client from complexities just by
executing the business task on server side.
For example, whenever a client wants to perform any of these actions such as
making a reservation or validating a credit card, a session bean should be used.
The session bean decides what data is to be modified. Typically, the session
bean uses an entity bean to access or modify data. They implement business
logic, business rules, algorithms, and work flows. Session beans are relatively
short-lived components. The EJB container may destroy a session bean if
its client times out.
A session bean can neither be shared nor can persist
(means its value can not be saved to the database) its value. A session bean can have only one
client. As long as the client terminates, session bean associated with this client is
also terminated and the data associated with this bean is also destroyed.
The above figure shows how Session Bean interacts
with the clients as well as with the Entity Beans.
Session beans are divided into two parts.
- Stateless Session Beans:
A stateless session bean does not maintain a conversational state with the
client. When a client invokes the methods of a stateless bean, the
bean variables may contain a state specific to
that client only for the duration of a method invocation. Once the method is
finished, the client-specific state should not be retained i.e. the EJB
container destroys a stateless session bean.
These types of session beans do
not use the class variables (instance variables). So they do not persist
data across method invocation and therefore there is no need to passivates
the bean's instance. Because stateless session beans can support multiple
clients, they provide the better scalability for applications that require
large numbers of clients.
- Stateful Session Beans:
These types of beans use the
instance variables that allows the data persistent across method invocation
because the instance variables allow persistence of data across method invocation.
The client sets the data to these variables which he wants to
persist. A stateful session bean retains its state across multiple method
invocations made by the same client. If the stateful session bean's state is
changed during a method invocation, then that state will be available to the
same client on the following invocation. The state of a client bean is
retained for the duration of the client-bean session. Once the client
removes the bean or terminates, the session ends and the state disappears.
Because the client interacts with its bean, this state is often called the conversational
For example, consider a customer using a debit card at an ATM
machine. The ATM could perform various operations like checking an account
balance, transferring funds, or making a withdrawal. These operations could
be performed one by one, by the same customer. So the bean needs to keep
track its state for each of these operations to the same client.
Thus Stateful session beans has the extra overhead for the
server to maintain the state than the stateless session bean.
The user interface calls methods of session
beans if the user wants to use the functionality of the session bean. Session
beans can call to other session beans and entity beans.
When to use session beans:
beans are used in the following circumstances:
- When there is only one client is accessing the beans
instance at a given time.
- When the bean is not persistent that means the bean
is going to exist no longer.
- The bean is implementing the web services.
Stateful session beans are useful in the following
- What the bean wants to holds information about the
client across method invocation.
- When the bean works as the mediator between the
client and the other component of the application.
- When the bean have to manage the work flow of
several other enterprise beans.
Stateless session beans are appropriate in the
circumstances illustrated below:
- If the bean does not contain the data for a specific
- If there is only one method invocation among all the
clients to perform the generic task.
Life Cycle of a Stateless Session Bean:
the Stateless session bean does not passivates across method calls therefore
a stateless session bean includes only two stages. Whether it does not exist or
ready for method invocation. A stateless session bean starts its life cycle when
the client first obtains the reference of the session bean. For this, the container
performs the dependency injection before invoking the annotated @PreConstruct
method if any exists. After invoking the annotated @PreConstruct method the bean
will be ready to invoke its method by the client.
The above figure demonstrates how the Stateless Session Beans
The container calls the annotated @PreDestroy method
while ending the life cycle of the session bean. After this, the bean is ready
for garbage collection.
Life Cycle of a Stateful Session Bean:
Stateful session bean starts its life cycle when the client first gets the
reference of a stateful session bean. Before invoking the method annotated @PostConstruct
the container performs any dependency injection after this the
bean is ready. The container may deactivate a bean while in ready state
(Generally the container uses the least recently use algorithm to passivates a
bean). In the passivate mechanism the bean moves from memory to secondary
memory. The container invokes the annotated @PrePassivate method before
passivating the bean. If a client invokes a business method on the passivated
bean then the container invokes the annotated @PostActivate method to let come
the bean in the ready state.
The above image shows the various states of the Stateful
While ending the life cycle of the bean, the client calls the annotated @Remove
method after this the container calls the annotated @PreDestroy method which
results in the bean to be ready for the garbage collection.