Can you explain more ?
Sure. My pardons, if arguments are not very objective, but I'm personally avoid using SFSB.
1. They have state, so they must have unique per-client instance.
2. App. server cache for SFSB is limited. Probably, it is big enough, but there is always a limit.
3. According to 1 & 2 server has to passivate SFSB from time to time. Often this means serialization to disk file. Obviously, this is comparably slow process. And SFSB tend to have quite large / complex internal structure to describe state -- otherwise, what it is for?
4. In cluster server has to synchronize state of SFSB. Slow as previous + cost of calls via network.
5. Even if there is a certain "exit" point in your SFSB, it is not called always
. For example, client closes his browser without logout. Nothing passed to web tier. So nothing could force SFSB removal. It stays in memory until timeout. As well as all pre-allocated resources. And it is more heavyweight comparing to HttpSession.
Now consider all the above in regard to heavy load scenario. Server will start juggling SFSB to/from disk via serialization. Probably, broadcasting updates to other cluster nodes as well. Will be this a top of performance?
Obvious, that "Add more memory!" panacea could be applied here. But I'm not sure that will help much with clustering.
Personally, I'm using following SFSB-replacement receipts:
1. If you have web tier, maintain state in HttpSession
2. If you have rich client, maintain state on client
3. If other EJB have to access state and state getting very complicated -- then make it persistent, i.e. place in database or other storage. It's much simpler to clean-up storage on regular intervals via quite straightforward batch procedures rather then orchestrate all that SFSB jazz.
More on this topic: Stateful Session EJBs: Beasts of Burden
and the follow-up An attack on stateful session beans