MockQuestion - httpSession vs. stateful session bean

[Christian Nicoll]

Hello

I found the following question (http://www.quizover.com/question/response/stateful-vs-stateless-beans?qsr=)

You are responsible for architecting an application for car agents. The application should save a lot of effort to its users. Instead of traversing about 30 commerce sites to check the new car offers, the application will collect these offers and render the list to the agent in one page. The agent will also be able to buy the car through this application directly.
You expect a limited number of users to get access to the application. And for performance reasons you have to cache huge amount of data collected from the various commerce sites that must be maintained during the user session that spans the regular day working hours.

What is recommended to use in this case to maintain the user session?

1) httpSession
2) stateful session bean
3) entity bean
4) stateless session bean

I don't see here the requirement of using an stateful session bean and have chosen httpSession, which is false. What have I overseen?

Kind regards,
Christian

[K. Tsang]

Stateless session bean and entity bean are out.

Now the question mentioned "huge" amount of data. Now HTTP session is in the web tier, and stateful session bean in the EJB tier.

Having such data stored in HTTP session will most likely reduce (network) performance because of transfer the data back and forth each time.

Stateful session bean is better because the data don't need to travel to web tier per se (or limited for display purpose) and SFSS can make use of passivation. The SFSS here in this particular case somewhat act like a shopping cart since the app allows users to "buy" the car directly.

[Christian Nicoll]

Hello K. Tsang

thanks for your fast response.

K. Tsang wrote:Stateless session bean and entity bean are out.

Now the question mentioned "huge" amount of data. Now HTTP session is in the web tier, and stateful session bean in the EJB tier.

Sa far, I'm totally with you. I've the same understanding

K. Tsang wrote:Having such data stored in HTTP session will most likely reduce (network) performance because of transfer the data back and forth each time.

I don't understand this point. Why should the data being transferred back and forth each time? Do you mean between the Web tier and the client? My understanding is that only the session ID will be exchanged between the client and the server, but the session data will be stay on the server. Further with just using the httpSession I don't see the need to have an EJB container, therefore I don't see there also not a potential data transfer way. I would be happy if you could explain this point a bit more.

Regards,
Christian

[K. Tsang]

Simply put, if you have data stored in some object and the client needs access to this data, you either put this data in HTTP session (hence transfer to client from web tier to client over network) or some other means. The data needs to be transferred over network before the client can see it.

Therefore, such data in the HTTP session is accessible in JSP views, the direction is server to client more than the other way round.

If you don't use HTTP session but say EJB, you need some POJO to store this data and again need to transfer this POJO to client.

[Christian Nicoll]

Thanks for your response!

I've the same understanding. Based on this, the statement "Having such data stored in HTTP session will most likely reduce (network) performance because of transfer the data back and forth each time. " doesn't make much sense for me, because also the (same) POJO data of the EJB would have to been transferred to the client. Further if the Web container and the EJB container runs on two different machines additional network traffic would be required between those two machines that would not be required if the httpSession would be used instead of a stateful session bean.

To sum it up, I still find it hard to find good reasons in this case to use an EJB instead of the httpSession.

[Tim Holloway]

K. Tsang wrote:
Having such data stored in HTTP session will most likely reduce (network) performance because of transfer the data back and forth each time.

Sorry. Did I miss something? The HttpSession object - and beans stored in its dictionary (J2EE session-scope objects) are NOT transferred back and forth. The HttpSession itself is stored in internal dictionary within the J2EE/JEE server. The map uses the jsessionId value as its key so that all that must be transported back and forth is the key (jsession), not the data. and that's not very big.

There are frameworks where shoving the entire session back and forth is done. It's an option for JSF, for example, although not the default option. Certainly there are compelling reasons not to do so in most cases:

1. As mentioned, it can really add to network traffic
2. Unless secure transport is being used, middlemen can snoop and exploit detail data (the jsessionId enjoys certain protections that raw data does not).
3. Data that's sent to the client can be mangled on the client before turning it back again to the server. Thus, even a secure channel can be ruthlessly exploited.

The HTTPSession is created and managed by the J2EE server, and in all cases I know of, if you're using the J2EE container security system, it will be created even when you login, even if you store no objects in session scope. You can see this in that to logout, historically, you'd invoke session.invalidate().

So unless you're going with a pure ReST approach, you'd almost certainly be anchoring a stateful session EJB in an HttpSession object.

On the other hand, if you need a general-purpose session, for example, when providing services using non-J(2)EE servers, an EJB session object has the advantage that it doesn't depend on an HTTP environment.

I'm unclear who the "user" is supposed to be in the question. If it's the webapp, serving as the consolidated client for the various remote data sources, a stateful session EJB seems like a reasonable choice. Then again, potentially so does an application-scope J2EE object.

If, however, the "user" is the webapp's own remote users (clients), then the advantage is less clear to me.