jakarta ee - When to use Stateful session bean over Stateless session bean?

Question

A stateful session bean is defined as follows:

Stateful Session Beans The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.

A stateless session bean is defined as follows:

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’s instance variables may contain a state specific to that client, but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. Clients may, however, change the state of instance variables in pooled stateless beans, and this state is held over to the next invocation of the pooled stateless bean. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply accross all clients.

The advantage of using a stateless session bean over stateful session bean is as follows:

Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.

So the question that comes to mind is when one should use stateful session beans? To my naive understanding of the matter, one should stick to use a stateless session bean as he can.

What would be the candidates in which one should use stateful session bean? Any good examples?

Session Bean

Answer 1

First, you have to understand how the beans are created and handled on the server.

For stateless session beans the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request. That means if the client does two subsequent requests it is possible that two different instances of the stateless bean serve the requests. In fact, there is no conversational state between the two requests. Also if the client disappears, the stateless bean does not get destroyed and can serve the next request from another client.

On the other hand a stateful session bean is closely connected to the client. Each instance is created and bounded to a single client and serves only requests from that particular client. So happens that if you do two subsequent requests on a stateful bean, your request will be served always from the same instance of the bean. That means you can maintain a conversational state between the requests. At the end of the lifecycle, the client calls a remove method and the bean is being destroyed/ready for garbage collection.

When to use stateless or stateful?

That mainly depends on whether you want to maintain the conversational state. For example, if you have a method that adds up two numbers and return the result you use a stateless bean because it's a one-time operation. If you call this method a second time with other numbers you are not interested in the result of the previous addition anymore.

But if you want, for example, to count the number of requests a client has done, you have to use a stateful bean. In this scenario it is important to know how often the client has requested the bean method before, so you have to maintain a conversational state in the bean (e.g. with a variable). If you would use a stateless bean here, the request of the client would be served each time from a different bean, which messes up your results.