Like, I suppose, many Java developers, I have so often read about the supposed scalability problems associated with stateful session beans, that I simply accepted that these problems were real, and refused to even consider using stateful beans. I guess this was laziness, but we don't have time to verify everything we read - and I'd never had cause to doubt that what I read was correct.
A few months ago, as Christian and I were nailing down our notion of application transactions
in a hotel room in Kohn Kaen, Thailand, it really struck me hard that a stateful bean is the perfect place to keep state associated with the application transaction. (An application transaction is a unit of work /from the point of view of the user/; it spans multiple database/JTA transactions.) For example, you could keep a dedicated Hibernate session for the lifetime of the stateful bean, obviating the need for detaching and reattaching the object graph at every request.
This made me wonder about the cause of the scalability problems that everyone talks about. Once I really started thinking about this, it just didn't add up! A stateful bean without failover is quite equivalent to a HttpSession with server affinity, a design that is commonly understood to scale acceptably well. Similarly, failover for stateful beans should be no more difficult to implement than HttpSession failover.
Indeed, it seemed that the use of stateful beans should actually improve performance, since we would no longer need to wear the cost of serializing state relating to the application transaction to and from either the web tier or database /upon each request/. It seems far more natural to keep the state right there, in the middle tier, along with the business logic, where it belongs.
The conclusion I came to at that time was that the scalability problems must be due to implementation problems in existing appservers.
Well, I was talking about this with a friend who works for one of the other J2EE vendors the other day and she pointed me to this excellent paper:
HTTP Session Object vs Stateful EJB
which really debunks that particular superstition.
Actually, there is a lot of nonsense written about the desirability of so-called stateless
architectures. It certainly might be true that a truly stateful design has some nice scalability characteristics. The trouble is that a stateless application can't really /do/ anything of consequence. In a real life application, the state /has to live somewhere/. Serializing it to and from the web tier is just a waste of breath. Serializing it to the database is even worse.
In future, I think I'll find myself using stateful beans all the time.
Lesson: beware J2EE folklore!
Putting a POJO on the HTTP session is a lot simpler than implementing an EJB. If you find that you need to reuse your business logic from a non-web client, wrap your POJO with a stateful session facade.
Such an approach definitely sounds appealing, especially in light of the upcoming simplification of the EJB spec in version 3.0.
What I am wondering about is what would the lifespan of such a bean be in relation to HttpSession and HTTP requests? I see 2 options:
1. Keep the SFSB alive for the duration of the HttpSession and have the web app issue beginTransaction() and commitTransaction() requests to the bean before and after each HTTP request.
2. Create and destroy SFSB's before and after each HTTP request. A new transaction would be started by the bean in its ejbCreate() and committed in its ejbDestroy().
Thanks!
Eli
Ant is a tool, I use it all the time. Hibernate is a tool, I use it all the time. Eclipse is a tool.... Java is a tool...
Or are you having English comprehension problems with respect to the phrase "all the time"? FYI, in common English usage, it means simply "often".
Most applications I have ever worked on have some kind of application transactions. It seems to me that if stateful session beans are a great way to model application transactions, then they deserve to be commonly used.
"... and she pointed me to this excellent paper: HTTP Session Object vs Stateful EJB"
Using the same logic you can that HTTP Session implementation used in the test was not any good and, if replaced or improved, HTTP Session would outperform SFSB.
Please DO NOT tie Hibernate to an EJB container! At the very least, announce your intention early on HB forums and have a wide discussion about it. BTW, thanks for the great product, HB rocks!
I am struggling with the decision of whether to cache in HttpSession or stateful session bean. I think I should re-evaluate my strategy after reading your blog.
You stated that
"you could keep a dedicated Hibernate session for the lifetime of the stateful bean, obviating the need for detaching and reattaching the object graph at every request."
In the program level, do you achieve that by disconnecting a session at the end of one request and reconnecting at the beginning of next one? If not, will you risk run out of db connections? My understanding is that each active session has a dedicated db connection associated with it.
Thanks!
Chao
This is just as much nonsense as saying you should never use stateful beans. Stateful beans are a tool. One should always use the most appropriate tool for the job at hand. And one should always remember that every choice has its own set of trade-offs. It is up to the craftsman to make the most appropriate decision given the set of circumstances he or she is faced with.
S
I think it is a good idea to store hibernate session in statefull bean and to use SessionSynchronization callback to close it,
but it is not a good idea to store statefull session bean in HTTP session.
It is the same problem as with hibernate session in http session (resource leaks and thread unsafe code).
The spec itself doesn't mandate awkward non-performant usage ANYWHERE. It's just vendors who will more often than not just implement it in the most naive and childish way possible.
Sadly, users judge the spec by its implementors, hence the bad rep.
The article URL has moved and it's now available here.
Also note that three years later we are calling an application transaction a Conversation, and that the whole Seam framework was build around this concept.