Forums Register Login

Why use Stateful session bean as opposed to a HTTP session ?

+Pie Number of slices to send: Send
Hi ,
Why would I use a Stateful session bean at the application server level as opposed to a HTTP session at the web server level , basically does it really make sense to hold data at the application server level ? Is it worth the overhead of round trips to the application server ? Also stateful session beans are not as good at Stateless Session beans . Can some on give a real life example where Statefull session beans are actually better off than a HTTP session and statless Session beans .

Many thanks
+Pie Number of slices to send: Send
Click Here
+Pie Number of slices to send: Send
SFSB's are designed for managed client state over multiple calls to the same session bean (i.e. a conversation). If you look at JBoss Seam, you will see that there is very heavy use of SFSB's for conversation context.

In EJB3, there is no such thing as "stateless is better than stateful session beans". For example, one provides a service like a credit card processor (stateless) and one provides processing for a multi-screen wizard use case (stateful).

Managing state using HttpSession and stateless session beans is very difficult and problematic.

Read about Seam...
+Pie Number of slices to send: Send
If you use HttpSession then you have to worry about thread safety.Because HttpSession is not thread safe.But if you use Sessionfull beans you dont have to worry about thread safety.Because Sessionfull beans are not shared between different clients.
In future if you changes front end with some other front end then you have to maintain HttpSession in changed front again.
If you have transaction then it is better to use statefull session beans as compare to HttpSession.
In short HttpSession should be used for presentation layer not for business logic layer.
+Pie Number of slices to send: Send
I wouldn't count thread safety as a big point against HTTP sessions. That should be relatively easy to handle, especially in an application where most of the logic is part not of the servlet layer, but of the EJB layer.

But HTTP sessions rely on HTTP as the access protocol. As Gowher said, it can be used for the presentation layer, but not the business layer. Because the business layer may be also be used by non-HTTP clients (e.g., desktop applications or web services).
+Pie Number of slices to send: Send
Thanks guys ,
So as long as my persentation layer is going to be for sure only the browser I would be fine using HTTP session but as we can never be sure of this and what happens the next day , I can see from the responses that its best to use stateful session beans .

Many Thanks
[ April 08, 2008: Message edited by: Meherdad Bomanbehram ]
+Pie Number of slices to send: Send
Hi All,

Correct me if I'm wrong but, in all case, you need to store the reference to the Stateful SB in a client session (HTTP for example) as each lookup to the Stateful SB returns a new instance.

For me, the great thing of EJB3 Stateful SB is the extended Persistence Context: you can do CRUD operations in a "wizard" way (the same conversation on many screens) and a commit/rollback at the end.
It's really easy.
For my next trick, I'll need the help of a tiny ad ...
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 4688 times.
Similar Threads
Stateful or stateless session bean?
Question on Statefull Session bean
http session object,ejb session bean
ejb fresher
Can we maintain state with a stateless session bean
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 10:51:28.