The 'Bitter Session States' chapter looks at the advantages and disadvantages of stateful session beans. The chapter defines session state, reviews the true purpose of the stateful session bean in managing session state and discusses how session state can be stored in servlets. It also identifies common antipatterns when stateful session beans are misused.

Download and Review 'Bitter Session States' from the book-in-review, 'Bitter EJB'

This is a good chapter with lots of useful advice. Well worth reading if you've got to manage state. On page 16 it reads "Stateful session beans are not intended to survive in the event of an EJB server crash. Don't let the advanced clustering and failover support offered by some EJB server vendors lull you into thinking otherwise." I wonder how the vendors would respond.

-Scott

This is a good chapter, and I enjoyed reading it. It's good to see a pragmatic approach to session state management: the EJB specification pushes stateful beans too hard, implying that they are the norm and that stateless beans are the exception.

I look in greater detail at many of these issues, and session state limitations in real application servers, in my book, Expert One-on-One J2EE Design and Development. Chapters 1, 7 and 10 address session state management, among other issues. Chapter 10 takes a close look at SFSBs.

Regards,
Rod

> It's good to see a pragmatic approach to session
> state management: the EJB specification pushes stateful
> beans too hard, implying that they are the norm and
> that stateless beans are the exception.

Thanks, Rod. My goal was to provide a fair and balanced look at the tools avaiable for managing session state. I'm glad to hear that you found the chapter to be pragmatic.

Thanks for taking the time to review our book!

Mike
mike@clarkware.com

Hi Scott,

>
> On page 16 it reads "Stateful session beans are not
> intended to survive in the event of an EJB server crash.
> Don't let the advanced clustering and failover support
> offered by some EJB server vendors lull you into thinking
> otherwise." I wonder how the vendors would respond.
>

Me too. :-)

Seriously, as an example of one vendor's response, the article by Tyler Jewell referenced in the chapter is also critical of reliance on SFSB replication techniques.

My intent was to remind readers that clustering and failover are vendor value-add features, not inherent properties of stateful session beans. They merely eliminate single points of failure, not failure altogether.

Thanks for recommending it as a worthy read!

Mike
mike@clarkware.com

Hi from Boulder...

1. You might want to mention earlier on that a reference or handle must be kept by the client of the stateful session bean. This is especially important when a web client is involved, because effectively you must have both HttpSession state AND stateful session bean state. Of course you may off load your HttpSession to the client browser using an EJB handle (not reference!), but is that advisable? Anyway, many would suggest that having both HttpSession state and EJB session state is necessary when using EJB stateful session beans.

2. You may want to suggest that another advantage to using HttpSession state is that the HttpSession can be scaled in a more cost-effective way then the EJB tier. For example, it is not uncommon for a web tier to be outfitted with Apache and Tomcat (free), while an EJB tier will be an expensive solution from BEA or IBM. While I believe in JBoss, many Fortune companies will prefer to do exactly as noted -- free web, costly EJB.

3. Your suggestion that database (6.5.5) backed session are better may be missing an important point. While I tend to agree with you on this, it does require that the user be logged in to use the solution you describe. This may be a downside for online shoppers who want to just start picking stuff off the catalog and not sign on until it's time to pay. So your business requirements team may shoot you down before you ever start designing a cart persistence strategy. While you can store state in the database based on the user that has not yet signed on, you may have a strategy that is no better than volitle state of web and stateful session beans. Just some more confusion to throw at your readers... but definiely worthy of thought.

Overall I really like your writing style. It's very readable, and the illustration of backcountry travel gets the gray matter working before thinking of technology!

Vaughn -- vaughn@jubatus.com

Hi Vaughn,

> 1. You might want to mention earlier on that a reference
> or handle must be kept by the client of the stateful
> session bean. This is especially important when a web
> client is involved, because effectively you must have
> both HttpSession state AND stateful session bean state.

Good observation. Somehow I missed stating that clearly. I'll make a point to clarify it.

> 2. You may want to suggest that another advantage to
> using HttpSession state is that the HttpSession can be
> scaled in a more cost-effective way then the EJB tier.

Excellent point!

> 3. Your suggestion that database (6.5.5) backed session
> are better may be missing an important point. While I tend
> to agree with you on this, it does require that the user
> be logged in to use the solution you describe.

Perhaps I should expand the solution a bit. Ideally, users that don't log in are considered guests. As such their cart's contents are only stored in the HttpSession. That is, their cart is volatile in the sense that its lifetime is tied to the length of their session. Once a user logs in, however, the state of their cart in the session is replicated to the database. The session is then just a local cache. In other words, guests don't enjoy the benefits offered by a database backed session.

Does that help?

> Overall I really like your writing style. It's very
> readable, and the illustration of backcountry travel
> gets the gray matter working before thinking of technology!

Thanks for those kind words! We chose to start each chapter with a fun adventure story as a metaphor for the antipattern themes. We hope they break up the monotony that all too often plagues technical books. Your feedback helps confirm that they add something valuable and unique to the book. I certainly enjoyed writing these stories.

Many thanks for your input!

Mike
mike@clarkware.com