This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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 .
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...
SCJP 1.4<br />SCBCD 5
Joined: Feb 07, 2005
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.
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).
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 ]
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.
SCJP5 | SCBCD5 | SCEA5 Part 1
subject: Why use Stateful session bean as opposed to a HTTP session ?