SFSB or SLSB?

[Syd Bar]

If one is storing the client's state in the web layer's HttpSession, do
we need to use SFSB? Why the answer for this question is SFSB and not SLSB?

Q:"In your web application, your Servlet will need to cache the bean stub as an attribute in the HttpSession object. The HTTP session's state will therefore be tracked and stored in the bean instance. If the client invokes method calls against the same bean stub, the calls are always tunneled to the same bean instance in the container."

[Jeanne Boyarsky]

That seems silly to me. They might as well store data in the session.

[Rishi Shehrawat]

If you are storing state in HttpSession then SFSB is not required. However if you are using SFSB & the client of SFSB is web layer then you will need to keep the handle of SFSB in HttpSession to ensure that all requests are routed to the same SFSB.

[Sharma Ashutosh]

If you are storing state in HttpSession then SFSB is not required. However if you are using SFSB & the client of SFSB is web layer then you will need to keep the handle of SFSB in HttpSession to ensure that all requests are routed to the same SFSB.

What if the presentation tier and business tier are on different JVMs and SFSB on one of the nodes of the cluster fails? Do you still think that all requests will be routed to the same SFSB? Essentially speaking what you are mentioning isn't it session affinity?

[Rishi Shehrawat]

It should work even if web tier & business tier are running on different JVM's even though I have not tried with this configuration.

The session affinity/sticky session part will need to be taken care by the web server. By this I mean that the web server running in front of app server will handle this. Session affinity will ensure that the request will always go to the server handling the users request. This will get interesting if the server crashes. In case session replication is supported the session will be availaible on another node which will take over, however am not very sure if SFSB handles are serializable & will be replicated to the other node.

[Syd Bar]

Thanks all for your answers.

However if you are using SFSB & the client of SFSB is web layer then you will need to keep the handle of SFSB in HttpSession to ensure that all requests are routed to the same SFSB.

Does web layer has identity? Does web layer independently need to maintain session with SFSB? I thought both HttpSession and SFSB are independent solution of maintaining session with the later being more sophisticated and there is no need to mix them, may be i am wrong.

[Rishi Shehrawat]

The web layer needs to ensure that subsequent requests from a client are routed to the SFSB that was created when the initail request came in. The only way that web layer can maintain state across multiple user requests is via HttpSession. This means that the SFSB handle or the "EJB object" will need to be stored in HttpSession.

Yes HttpSession is an alternative to SFSB , but using SFSB in web layer means that we also need to use HttpSession.

[Syd Bar]

Thank you Rishi and all. I understand, we can keep a HttpSession and store the bean and ensure that the subsequent client call lands into that very same bean. We can do it if we want. But i am still thinking is it not redundant? Isn't this a 2 level session tracking mechanism? May be required for some process, i am not aware of. Can you give me a practical example where we do this? I haven't work much in web/UI layer and planning to write the SCEA 1 ( before Aug 1 deadline...... ). Thanks Ranchers.

[Rishi Shehrawat]

Shopping cart is an example. If you have decided to implement shopping cart using stateful session bean. You will need to ensure that all the items added by the user are added to the same cart. Which means that the web application should add all items to the same stateful bean. In this case the web application will need to keep handle to the stateful bean in HttpSession.

Frankly in terms of using stateful beans i have personally not come across a application where stateful beans are used. A major factor is that that stateful beans don't scale very well.