• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Web user state (thoughts needed!)

 
W. Walden
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In regards to web user state, if there is no way of planning for what type of network infrastructure will be used, how can I be positive that using Stateful Session Beans or HttpSession will work?
The largest problem being if the web and application servers are load-balanced per request? Wouldn't I lose state in either implementation?
It seems to me, without knowing for sure about the network configuration, that minimal amounts of state should be tracked for a web user. Small enough to be stored appropriately in browser cookies and POST variables specifically. So, what I started with is something like this:
Users hold their Customer ID's in a browser cookie. Each request sends back the ID, which means for web users, every request would start with a call to pull data from the database and create a Customer object (Java clients would simply hold this object is memory and send it to the EJB layer with each request).
However, as I am working on my sequence diagrams, I start to realize that the web users are going to be doing a large amount of database calls. For example, if a web user selects an itinerary with 3 flight segments, the web user will most likely POST back the 3 flight segment ID's which means the segments need to all be pulled from the database before actions such as "pricing" and "get available seating" can occur.
So I seem to be in a design catch 22 - neither approach seems optimal. Any thoughts? Thanks.
 
W. Walden
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone have any comments? Please help.
 
Aanand Joshi
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You shdnot worry about losing state Leave it to container container shd manage state for you in web or ejb tier.
 
manoj pillai
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As EJB tier is where most of the load is going to be, as it has to support both web and standalone clinets, it is going to be the first candidate for load balancing than the web tier. In that situation web session management issue is void, assuming load balancing at ejb tier only. Again even in case of web tier load balancing, there are mechanisms inlcuding session affinity cookie, and distributed session mechanism as supported by some app servers. But our assignment being pure J2EE may not be dependent on one of those custom solutions. As such both http session failover and SFSB session failover are not covered under J2EE spec. So Maybe we need not be bothered at all. Anyways, this being a pure ideal world J2EE application, maybe you should stick to SFSB - it is the suggested session management solution per J2EE blueprints. And it covers both web and standalone clients in one shot, web code remains light weight, no client specifc service interfaces either at ejb tier.
HTH
 
W. Walden
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the replies.
You guys are probably right. I don't suspect I would be penalized for using something specifically built into J2EE to support state.
I don't think I will use SFSB for Java clients though. I don't see a need since they can hold state objects locally. From a purest sense, I suppose this means I should use HttpSession since only web clients need server-side session state, but I suspect SFSB may offer better performance because of passivation.
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a bit simpler than that. Since the Agent GUI is most likely a Swing implementation, it will not use HTTP protocol. Hence,Stateful Session Beans are not needed, i.e., the Swing client will hold state instead. Swing GUI will communicate with the Stateless session Beans using TCP/IP over IIOP. Therefore, the Web Client can happily use HttpSession to store state. Supporting Fail-over and load-balancing for Stateless session beans is much easier than Stateful session beans.
Regards.
Bharat
 
Cindy Li
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the state should be stored in SFSB, even for Java Client. If you use Swing client to store states, it takes lots of overhead to transfer the heavy weight objects.
Use SFSB, the state transfer is avoided. all states are maintained by ejb container. Only the lightweight stub is returned to client.
So i think both web client and java client should use SFSB
 
Cindy Li
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And I just checked with SUN people. They mentioned that high end server like E10k supports clustering.
It can be assumed that load balance and failover is supported also for ejb components.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic