why stateful

[manish ahuja]

Hi All
Can someone tell when will we have a situation where it would be imperative to use Stateful Session Beans.
When it would be advantageous to use stateful session beans on the app server over HTTPSESSION on the WebServer/servlet JSP container

Rgrds

[Li Xin]

You cannot rely on http session if you have a non-web client, otherwise I think http session is enough in most situations.

[Alec Lee]

And, when we want biz logic locates on EJB rather than on Servlet/JSP. Recall this is what the EJB n-tier architecture want to do.

[Reid M. Pinchback]

HTTP Session has a number of problems not encountered with stateful session beans. For one thing, how a web container manages the lifecycle of the session is completely different from how an ejb container manages the lifecycle of a stateful session bean. If an ejb container crashes, a stateful bean isn't saved. When the container comes back up, any client requests have to use a new, clean, stateful session bean. A web container on the other hand can persist session information whenever it is in the mood to do so, and you can end up with stuff on disk that survives a crash that you really, really wouldn't want a client to try to use.
There are also design considerations. Web apps that depend heavily on HTTP session state tend to end up with a lot of rigid coupling in page workflows that you tend to avoid when using request-scoped page processing and stateful session beans.
There are also differences in how HTTP Sessions and Stateful session beans impact performance in clustered environments.

[manish ahuja]

Hi Reid
Thanks a lot for the reply
could you ellaborate a bit on this statement
******************
There are also differences in how HTTP Sessions and Stateful session beans impact performance in clustered environments.
**********************
or list some pointers to docs where i can find more info on the same
Rgrds

[Reid M. Pinchback]

My exposure to the issue is limited, but I'll take a shot at it.
When you cluster you have to decide what you are clustering. You can have a cluster of web containers (servers) completely independent of the notion of having a cluster of ejb containers (servers). People want clusters for two reasons:
1. scaling performance to enable more requests to be processed, and
2. creating fault-tolerance in case a server goes down.
The second reason is the more problematic one from a performance standpoint. It means that if a user U made requests that were processed by server S1 before S1 failed, U's requests should be transparently handled by some server S2 when the cluster manager re-routes the requests to S2.
This is dead easy for stateless session beans, entity beans, and message-driven beans. It isn't easy for web sessions or stateful session beans. The reason? Every time the state changes, those changes must be broadcast across the cluster. Synchronizing big session state, no matter where it is located, can be a performance problem for clusters. The solution is to keep the amount of state information small.
In both approaches, stateful bean versus web session, you could do either a good or a bad job of minimizing session state, but container callbacks like ejbActivate/ejbPassivate are obvious opportunities for a developer to make some memory-mangement/performance tradeoff decisions.
One other point, performance related but not cluster related. Web session data can result in poor performance relative to stateful session beans for another reason. If you are caching data in a web session to feed back into future method calls on remote interfaces, that data has to be marshalled/demarshalled when the remote interface methods are invoked. A stateful session bean doesn't have to serialize data it passes to other beans, if those beans are accessed via local references.