The SquizLog

The Return of the Stateful Session Bean?

Why not use Stateful Session Beans to manage web application state?

It's a question that I've pondered from time to time. I remember vague warnings not to use SFSBs due to poor performance but never really got to the bottom of the issue. And over the last few years there has been a reaction against EJB 2.1 in general (e.g. in the Spring community). In my own case the system that I've been working on for the last year or so has been deployed in Tomcat so EJBs have been out of the picture.

More recently I have been encouraged by the emergence of EJB 3. Earlier this year when I heard Rima Patel from Sun speak about EJB 3 and recalled my own painful experiences developing with EJBs I could understand her excitement. EJB3 appears to make everything so much simpler.

In the last few days I have been learning about how Seam unifies the JSF 1.2 and EJB 3 component models, emphasising the use of Stateful Session Beans bound directly into JSF views. Seam certainly looks worth exploring, not least because it "provides multiple stateful contexts of different granularity from the conversation scope to the business process scope, liberating developers from the limitation of HTTP sessions".

And then today InfoQ alerted me to Rod Coffin's article in which he compares Spring and EJB 3.0, noting that the main difference was in the way they managed state. As he pointed out, Spring's use of prototype beans to manage state involves more work to achieve the equivalent of stateful session beans. So now that EJB 3.0 has simplified development of EJBs, why not use SFSBs? At the very least it would make sense to me to experiment with them using JBoss Application Server or GlassFish.

And what of that supposed performance problem with SFSBs? It would seem to be a myth that was dispelled nearly four years ago!

Posted to Software Development by Keith Pitty