• Post Reply Bookmark Topic Watch Topic
  • New Topic

Maintaining State in SFSB for Web Clients  RSS feed

 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am not in to discuss the pros and cons of keeping state in HttpSessions or SFSB.

Browser <-> Servlet(Controller) <-> SLSB(Business Facade) <-> SFSB(State)
My scenario is one where the state is kept in a SFSB. The client is a web browser. There is a servlet to handle the requests of the client. On the ejb tier, there is a SLSB which authenicates and creates a SFSB. My problem is how to associate subsequent requests from the browser back to the SFSB where the state is kept.
Is this possible? If yes, I need some conceptual explanation on this.
Thank you very much!
[ May 04, 2004: Message edited by: Frankie Cha ]
 
Roland Barcia
author
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to keep a serialized handle to the STSB in Http Session, however, why not keep state in Http Session since it's associated with the user. App Servers usually do a better job of clustering Http Session. Also avoids extra passivation and activation in high volume scenarios.
 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Roland,
Thank you for your response. In SFSB, there is activation and passivation to handle high volume of states. Is there something equivalent for HttpSessions. Under high volume, will AppServer unable to function using HttpSessions as there is no activation and passivation for HttpSessions?
The reason why I am considering SFSB to handle states is because the clients could be rich clients and browsers. Would there be any other alternatives to this. The rich clients bypass the web tier and go straight to the Business Tier which is where the EJB resides. There is no firewall constraints because the rich clients are deployed within the organisation.
Best Regards,
Frankie
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two other options spring to mind.
1. Writing to a database (not as fast as using a stateful bean)
2. Using the client to store the state by passing the conversational state into each method call on the stateless bean (can use a lot of bandwidth)
 
Roland Barcia
author
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Passing conversational state from the client back to a stateless session bean is a good option. Conversational state should be small, it should be a set of keys needed to get to real data. If you need performence benefits of data caching, use data cache technology, not state management technology. Whole workflow systems work on this concept.
You want to keep the conversational state at the highest level closest to the client because the client is interacting with the highest level. In essense, both web clients and thick clients have to maintain some sort of state anyway when using stateful session beans (The EJB handle). The reason to cache state is to avoid extra IO, so the thick client still needs to make remote calls back to the EJB, so at that point why even bother.
 
Roland Barcia
author
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Frank,
The spec does not define how Http Session is pooled but generally speaking, every new user gets its own HttpSession (with some global max sessions setting) while EJB's are pooling is defined. Http Session is not a remotable object, it is only a storing mechanism.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!