Does Anyone Actually Use Stateful Session Bean

Stateful session beans look plausible when you survey the J2EE literature and look at the shopping cart application example, but when it comes to doing the actual development, and especially if it's going to be a WEB application, aren't you going to front-end the system with a (for want of better term) direct client component anyway, which means that client state (ConversationalState?) is pushed out away from your EJB model, and Stateful session beans lose their appeal. For instance, if I'm developing a front end in JSP (servlet), then ConversationalState? is being provided for in the HTTP session abstraction. Given that, why bother with stateful beans?

I almost NEVER EVER use them. I've done it in only a couple of cases:

  1. When I needed the SessionSynchronization? interface to tie in a datasource that wasn't XA compliant into my transactions
  2. When I wanted to store more session data than the HTTPSession could comfortably store, but didn't care about failover.

By the way, Tyler Jewell from BEA has an article on the web that says nearly the same thing.

-- Kyle

My answer, in as few words as possible: "No." -- MichaelChermside

Could some one explain why it is bad to use SFSB. I am working on a project where we have three different layers,webserver, appserver and ruleserver. What we have is a three controller (a controller for each layer) and one state architecture. There is a web controller which has action classes (takes care of formating, client side validation and other webserver related stuff), the appserver controller which has a single worker class for each specific server side job to perform, and finally we have a rule controller in front of the ruleserver. There is only one single place in the system where the state is maintained and it is the usersession bean which is a SFSB. Any layer or any other subsystem who wants to update or request the current state of the user will interact with this sfsb. I used an entity bean which has currently logged in users (stores userid and usersession handle).

I had to use a stateful session bean for various reasons, I don't want to attach the state to the webserver, reason being that our staging and product sites vary in their setup. (Staging site uses dynamic loadbalancing for webservers and Production site uses static loadbalancing). I can't just do a simple RMI, I wanted to have full failover which is already provided by my appserver.

-- SeshKumar

Okay, I'll have a go. With the usual disclaimers that specific app's may have different requirements. This argument relates to the architectural issues surrounding distributed state. Generally, if logically coupled state is physically distributed, you have created a fragility. Entity beans also have a coupling problem, but that's for another day :).

A stateful session-bean is very tightly bound to the client using it, therefore you'll have as many session beans as you have clients. This stops the server from being able to limit resources to the number of active transactions. This prevents the most basic form of server efficiency.

A stateful session-bean usually cannot migrate from server to server. Therefore one cannot generally use multiple servers within a single client session. That means you drop all active sessions if any of the equipment between the client and the server fails.

The server-side has difficulty knowing if a client has gone away for any reason. A short timeout may throw away clients who are simply slow to respond for whatever reason. A long timeout tends to drag the server down with hung sessions.

That's enough for starters. -- RichardHenderson.

All the problems outlined above are more towards any distributed state management system, yes its true that when you distribute your state (using stateful session beans here) you have the problem of having this state being specific to a client (1), difficult to have failover to other server (2) and the third point about session time out.

So the question comes back, where do you put your conversation state, where the conversation state is not a simple shopping cart and when the conversation state is needed not just by one system but many remote systems in your architecture. Lets see all the options.. 

 1. If we push the state or current configuration back to database then you may have problems like,
  a) needs expensive database writes and reads for each change in the user state.
  b) if the database is a simple relational database, extra work is needed to reconstruct the
     user current state objects in the memory from this relational data.
 2. If we push the state to the webserver or jsp container then you may have problems like 
  a) the session state size is very limited.
  b) you are tied to the same webserver so your loadbalancer should be sticky.
  c) since servlets are not remote objects other system (like a ruleserver or appserver) can not
have access to current user state unless you send them to those systems on every call.
Eg:  RuleServer?.executeRule(currentConfig,somerule).
-- SeshKumar

I tend to put the state in a database if it's complex. How do you deal with the above issues? Particularly, how are you supporting failover? -- RIH

I feel that the above two alternatives for state distribution are two ends of a solution, we picked a middle ground to store the state in the appserver keeping the state close to where it is manipulated most. I will try to address the issues pointed out above. We are using InpriseAppServer (which is now BorlandAppServer?).

1. Server efficiency - server efficiency decreases as the number of clients increase, since it has to passivate more session beans and reactivate them, but with proper amount of RAM and necessary settings of stateful bean passivation time you can achieve a good balance between number of concurrent users and performance per user.

2. State full session failover - the appserver we are using uses an object oriented database (a small foot print inmemory data base) as session storage, we are doing a homogeneous clustering (all appservers are identical) to provide failover. We haven't achieved a complete seamless failover, but we can restore the state up to the last passivated state. see http://www.borland.com/devsupport/appserver/faq/Availability_Scalability_Performance.html

3. Session time out - a currently logged in users database, has the user id, his session handle and last request time, A simple thread can query this database for users whoes sessions are timed out, and will call the appserver to remove those session beans.

-- SeshKumar

Yes, and I regret that.

EditText of this page (last edited January 23, 2003) or FindPage with title or text search