Stateless beans offer better performance than stateful beans. Activation and passivation are expensive operations. The EJB container might occasionally write a stateful session bean to secondary storage. However, stateless session beans are never written to secondary storage. To support the same number of clients, an application typically requires fewer stateless session beans than stateful session beans. Whenever possible, choose stateless session beans instead of stateful session beans.
A client should explicitly remove a stateful session bean by calling the remove() method of the component interface. Otherwise, the container keeps the stateful bean until it times out. This wastes resources such as memory, secondary storage, and so on.
A client should be prepared to re-create a new session object if it loses the one it is using. The client could lose the session bean because the container may terminate a session bean instance's life after a specified timeout or as a result of an EJB shutdown or crash.
Stateless session beans are ideal components for clustering because they do not maintain state. This provides high-availability to applications designed with stateless session beans. Stateful session beans can be clustered with more effort and design considerations.