Stateless Session Bean

Session beans provide the generic components of an application that represent tasks or business processes. Session beans perform actions on behalf of a single client and serve as the entry for the client to the enterprise application. A client interacts with the application by invoking session bean methods defined in the remote interface, which access the functional behavior and services of the application.

Stateless session beans do not maintain any conversational state. Each method
is completely independent and uses only data passed in its parameters. Stateless session beans provide the highest performance in terms of throughput and resource consumption compared to entity and stateful session beans because only a few stateless session bean instances are needed to serve hundreds, possibly thousands of clients.

Stateless session beans have longer lives because they don’t retain any conversational state and are not dedicated to one client, but they still aren’t saved in a database because they don’t represent any data. Once a stateless session bean has finished a method invocation for a client, it can be reassigned to any other EJB object to service a new client. A client can maintain a connection to a stateless session bean’s EJB object, but the bean instance itself
is free to service requests from any client. Because it doesn’t contain any state information, there’s no difference between one client and the next. Stateless session beans may also have a timeout period and can be removed by the client, but the impact of these events is different than with a stateful session bean. With a stateless session bean, a timeout or remove operation simply invalidates the EJB object reference for that client; the bean instance is not destroyed and is free to service other client requests.

A stateless session bean is very efficient and relatively easy to develop. Stateless session beans require few server resources because they are neither persistent nor dedicated to one client. Because they aren’t dedicated to one client, many EJB objects can share a few instances of a stateless bean. A stateless session bean does not maintain conversational state relative to the client it is servicing, so it can be swapped freely between EJB objects. As soon as a stateless instance services a method invocation, it can be swapped to another EJB object immediately. Because there is no conversational state, a stateless session bean doesn’t require passivation or activation, further reducing the overhead of swapping. In short, they are lightweight and fast. Stateless session beans often perform services that are fairly generic and reusable. The services may be related, but they are not interdependent. This means that everything a method needs to know has to be passed via the method’s parameters. This provides an interesting limitation. Stateless session beans can’t remember anything from one method invocation to the next, which means that they have to take care of the entire task in one method invocation.


Some important points

1)Stateful Session Bean are dedicated to one client. But Stateless session beans are not dedicated to one client. Because it is in Pool.

2)Once a stateless session bean has finished a method invocation for a client, it can be reassigend to any other EJB object to service a new client.

3) In the stateless session bean the ejbRemove() is called, the bean instance is not destroyed and is free to service other client requests.

4) Stateless session bean defines instance pooling in their life cycle but Stateful session bean do not.

5) The ejbCreate() method of Stateless session bean is only invoked once in the life cycle of an instance- when it is transitioning from DoesNotExist state to the Method-Ready Pool it isn't remvoed every time a client requests a remote reference to the bean.

6) The ejbRemove() method , the SessionContext() is still available to the bean instance.

7) In the instance pool, the bean instance might be swapped in to service an many EJB object.

8) If ejbRemove(), it place the object back in pool or have object destroyed. Client still have reference, but object doesn't have to exist.