Improper uses of Stateful Session Beans
Stateful Session Beans are the least use type of EJBs. I saw a few usages of Stateful Session Beans but most of them were improper. Stateful Session Beans are the least understood type of EJBs. What are they for? Or better: show me use cases where Stateful Session Beans are essential solution! The internet gives several answers but not always proper. We will investigate those answers.
Stateful EJB can manage state between Client invocations, or rather that Stateful can manage state between transactions. Actually it is not the same.
The most commonly presented example of usage of Stateful EJB is Shopping Card. For instance, client is thick and communicates with server-side business layer. Client do shopping. It maintains a set of selected items, a Shopping Card. A Shopping Card is a server-side Stateful EJB. When a client picks a item from the store, the item is added to the Shopping Card by invoking appropriate business method. When the client is ready to complete the shopping, it invokes appropriate method: payment, order and shipping are being done, and bean is destroyed. The essential key is that a state, i.e. picked items in a Shopping Card, is server-side.
The term state is important. It says there is a conversation between a client and a server. The conversation consists of multiple requests and responses. And there are non trivial business data sent. The data personalize and affect the service and actually are the state. From a service point of view a stateless service do not admit conversations, each request is treated separately, and a stateful service do admit conversations.
In the above example a stateful service is used and the state is held by Stateful Session Bean. But the problem of internet shopping can be solve without Stateful Session Bean. We can keep the state client-side. I.e. instead of Stateful Session Bean, a thick client accumulates picked items. And when shopping is done then the whole state is sent in one request. In my opinion it is even better solution.
Actually most of stateful conversations can be replaced by stateless services with a client-side state. Can be replaced effectively. There must be non obvious state, if replacement is not effective. The serious threat of using Stateful Session Bean is number of instances. That is why if Stateful Session Beans can be replaced by Stateless Session Beans or Singletons then they should be replaced.
Other proposal of Stateful Session Beans usage is involved with Http Session. Usually http clients keep their data in HttpSession. It is proposed to keep data in Stateful Session Bean. Obviously HttpSession must hold Business Interface pointing to its Stateful Session Bean. This way Stateful Session Bean takes HttpSession’s responsibilities of holding client data on the server side, HttpSession is thin, holds only Business Interface, Stateful Session Bean is thick. Reason to replace HttpSession with Stateful Session Bean is Stateful Session Beans are more effective while working with large number of instances. Because of passivation, Stateful Session Beans save memory.
Such combining Stateful Session Beans and Http Session is actually example of a bad practice. For several reasons:
- Stateful Session Beans lives longer than Http Session. Abandoned instances occupies memory. In EJB 3.1 the application provider can configure the timeout of inactivity when instance should be destroyed. The timeout is set per component. If the timeout is as short as Http Session timeout then the problem of abandoned instances is solved. In EJB pre 3.1 the application provider must develop application level mechanisms.
- Passivation is not costless.
- If you optimise usage of Stateful Session Beans then Stateful Session Beans work better then HttpSessions. But the profit is so little it can be ignored
- Architecture expands. It is less readable and maintainable.
- Claims that Stateful Session Bean can be replicated are not appropriate. I mean, Stateful Session Beans are replicable but to use it also HttpSession should be replicated. There is no profit if Stateful Session Bean and Http Session are replicated, because there is no difference if the data are replicated with Stateful Session Bean or Http Session.
Maybe there can be circumstances when such usage of Stateful Session Beans is more profitable. But there are more serious reasons against such practice:
- It is not proper use of Stateful Session Bean. Stateful Session Bean is a service! And as a service should be treated. The core of any service are business methods. Stateful Session Bean is not data container, especially is not container for data not involved with business methods. Stateful Session Bean cannot simply replace Http Session, because their purposes are different.
- It is not proper use of Stateful Session Bean. Stateful Session Bean is intended to be used with a scenario. Usage should be a sequence of invocations and compose a process. A scenario, a process, should have a purpose. In particular should have beginning and finish. When using Stateful Session Bean potentially infinitely, it is a candidate for a bad practice.
- It is not proper use of Stateful Session Bean.This way EJB is a part of web tier!
Advanced EJB 