servlet vs stateful session bean

[Chiang Guo]

Some question in mock test for scea prefers using servlet to control session than stateful session bean, even when the web application is transaction-based. I feel that it would make more sense to use stateful session bean as EJB clearly states that it's best used for transactional, persistence based and distributed applications. Does anyone here have similiar thought?

[Sujatha Kumar]

I do Agree.

[Bijan Mohanty]

It really depends upon the architecture of the application. If you are having a Webapp and planning to deploy your web tier as well as the business tier on the same server, it'll be better to use HttpSession. If you want to have the business tier deployed on a separate app server than the web tier, it probably makes sense to have a stateful session bean.
Using a Stateful session bean adds complexity since you need to store the handle of that in the HttpSession. In a clustered application now you need to worry about the in-memory replication of both the HttpSession as well as Stateful session bean in case of failover. Usually most of the app servers handle that for you though.
My .02 cents.
Bijan

[Denis Wang]

Stateful session beans are heavy in nature. They don't scale well due to the memory consumption and/or I/O burdens caused by activation/passivation.

[Xie Ruchang]

Hi,
In a recent article written by Gavin King, the inventor of Hibernate, studies have shown that Stateful Session Beans is a better candidate for state management than HttpSession. There have been some misconceptions about this whole issue. Please read it. Good stuff.
Best Regards

[Denis Wang]

this is an interesting topic. You have the following choices:
1) no session state cached anywhere other than a sessionId in a cookie or embeded in url. end user re-submit all information again and again for the following requests. it is something like, when you are in phone call with somebody, everytime you say something beginning with, 'this is denis speaking, previously we just talked about step1, now i am going to talk about step2."
2) cached in web application using HttpSession
3) cached using stateful session beans
4) write it into database (or any permenant resource)
There are cases when 1) and 4) are definitely better choices.
Now let's just suppose you DO HAVE to cache your conversational status either in web layer or ejb layer.
httpSession is a straightforward solution with serialization. Stateful session beans are heavy because they have services for transaction, security, instance pooling, and etc. why not split their functionalities into two parts: httpSession takes care of the state-caching part and stateless sessionbeans take care of the transaction, security....
I have no clue why the author of the article make the following comments:
"Indeed, it seemed that the use of stateful beans should actually improve performance, since we would no longer need to wear the cost of serializing state relating to the application transaction to and from either the web tier or database upon each request."
Is activation/passivation coming free? Anyway the bottom line is stateful session beans have to use techniques similar to serizalization to cache the state if memory is not enough when hundreds of users hit the server simultaneously.
Forgive me if i am biased. Once I switched stateful ones into stateless ones to boost performance dramatically with weblogic6.1. i'd rather trust my real experience.

[Bharat Ruparel]

Hello All,
May be I am missing something, but I don't think we have a choice. The Agents are supposed to have a rich-client interface and the customers are supposed to have a thin-client interface. If you maintain your state entirely in the HttpSession, then what about the rich-client application interface for the agents? Are you designing your sytem so that you don't maintain any state at all for the business-tier in case of the rich-client application interface? To me, that implies having to use "stateful" session-beans to maintain the "business" state in the business tier and the presentation tier related state in the HttpSession for the thin-client interface and the rich-client application or applet whatever you decide to go forward with.
Let me know your thoughts.
Regards.
Bharat

[Xie Ruchang]

Hi Dennis,
Suppose you keep your state in the Web Tier, you have tons on session coming in, the Web Tier will run out of memory and cannot handle it. On the contrary, the EJB tier can handle it with activation and passivation. Does the Web Tier do activation and passivation when it runs out of memory because of too many sessions? Whatever that are kept in the Web Tier for session has to be passed to the EJB Tier for processing. There will be a price for passing the information from the Web Tier to the EJB Tier, this is what the author is pointing out. So, why not store the information in the EJB tier right from the beginning and avoid that price. The assumption here is the Web tier runs on one machine and the EJB tier on another.
The previous post also highlight that the client may be rich clients and will bypass the web tier to the ejb tier directly. So session information should be kept in the ejb tier in view of expansion for rich clients. In the Part 2 exam, where it is stated that there will be two kinds of clients, browser and rich clients, what choice do we have?
Best regards,
[ April 30, 2004: Message edited by: Frankie Cha ]

[Chiang Guo]

Thanks for your good points!
Another point I think is SFSB would be better for controlling transactions, though servlets could also do transaction.

[Jim Ra]

As I see it, we do have a choice. If (and that's a big if) we decided to go with session state in HttpSession exclusively, then we will probably use stateless session beans to expose business interface. Transactions will be handled by SLSB, so this part works out nicely. Since we designed the state to be held in presentation layer, naturally the Swing client would have to keep the state, I don't think this pose a problem for it.
The argument that SFSB can save session state to disk in case of memory shortage is an interesting point, but this would only matter if the session state is very large or concurrent user count is very high (or both). I don't think these are true for this assignment.
IMHO, both SFSB and HttpSession are valid choices for the assignment. There is one interesting issue though. The assignment dictates the hardware setup for us, one application server, two web server (I thought we as architects should decide this, not the CEO :-). So if we're going to use HttpSession, we'd have to do session replication in web tier; there's no need to do this if we put the session in SFSB.

[Denis Wang]

Originally posted by Bharat Ruparel:
May be I am missing something, but I don't think we have a choice. The Agents are supposed to have a rich-client interface and the customers are supposed to have a thin-client interface. If you maintain your state entirely in the HttpSession, interface for the agents? Are you designing your sytem so that you don't maintain any state at all for the business-tier in case of the rich-client application interface?

ejB tier: stateless
presentation tier {web app. server & rich gui): maintain states
browser=>web app=>ejb
gui => ejb

[Denis Wang]

Originally posted by Chiang Guo:
Thanks for your good points!
Another point I think is SFSB would be better for controlling transactions, though servlets could also do transaction.

transaction control and conversational status are totally independent, as far as i know

[Denis Wang]

thanks for a lot of good replies. I didn't explain clearly previously.
Choice one: SFSB
Good: if hundreds of concurrent invocation, activation/passivation can be used to save memory usage at the expense of I/O operations.
Bad: the burden is centralized in ejb server.
Choice two: HttpSession or session cached in GUI client
Good: the two web servers and the GUI java clients will share the burden for caching status
Bad1: No mechanism in servlet to activate/passivate HttpSession
Bad2: session replication is a problem. considering the nature of a ticketing system, session failover will not be supported. (Anyway to lose a booking status in rare cases is not a disaster.) all requests from the same IP will be routed to the same web server. there are other tricks to walk around this limitation.
It's your choice.
Best,
denis

[Bharat Ruparel]

Hello Jim and Denis,
Thanks for the clarification.
Regards.
Bharat

[tom lau]

Hi,
While I was fighting for SCEA Part II, I also have the same question about how to handle session state. I once asked one of the chief architect of our project. I told him that I prefered to use SFSB to store user state, just like Blueprint tells us. However, he told me sersiouly that EJB is a very heavyweight component. If there are too many users use the system concurrently, nightmare will be come! Since our project applies Swing, a lot of user state is stored in Rich client side.
However, in the exam like this, I think using the SFSB to store user state will be more reasonable and good-looking. No matter what, just make you answer clear & depict it detail, then, it is ok.